초급 프로젝트 <SEVEN> 개별 개발 리포트

코드잇
이 글은 읽는데 약 4분이 걸립니다.
1. 서론

본 프로젝트는 사용자로 하여금 함께 운동하고, 그 기록을 공유하여 사용자 간 열정과 성취감을 나누도록 하며, 커뮤니티를 형성하여 함께 소통하고 유대감을 쌓는 웹 기반 운동 기록 소셜 네트워크 서비스의 제공을 목표로 하였다. 팀 단위로 진행되었으며, 본인은 운동 기록에 대한 순위 반환, 이미지 업로드 API의 개발과 전체적인 코드 리팩토링을 담당하였다.

2. 개인 담당 파트 및 역할

운동 기록 순위 조회

  • 특정 그룹에 속하는 운동 기록을 운동 시간을 기준으로 정렬하여 반환
  • duration(weekly 및 monthly) 쿼리 스트링을 받아 기간별 순위 조회 구현

이미지 업로드 기능

  • Multer 라이브러리를 통해 서버의 로컬 저장소에 이미지 파일 업로드 구현
  • 업로드된 이미지에 대한 메타데이터를 DB에 저장
  • 정적으로 접근 가능한 이미지 URL을 반환

코드 리팩토링

  • 프로젝트 중반까지 네이밍 컨벤션, 코드 스타일, 클래스 기반 설계 등이 제대로 이루어지지 않는 문제 발견
  • 전체적인 소스 코드를 통틀어 리팩토링을 진행하였고, 네이밍 컨벤션을 kebab-case로 통일, 각 모듈을 Class-based로 통일
3. 개발 과정
  1. 팀원 간 역할과 책임 정의
  2. Prisma ORM의 DB Scheme 설계
  3. 디렉토리 구조 설계 (router – controller – service – repository)
  4. 기능 개발
  5. 코드 리팩토링
  6. README 작성
  7. 프로젝트 마무리 후 발표
4. 배운 점

코드 리뷰의 중요성

  • 팀 프로젝트로 협업하는 과정에서 PR을 등록하고, 변경 사항에 대해 코드 리뷰를 받았다. 팀원 분께서 정말 세세하고 꼼꼼한 부분까지 자세하게 코드 리뷰를 해 주셨는데, 해당 리뷰를 보고 개선 사항을 코드에 반영할 때마다 더 나은 코드가 무엇인지에 대해 고민하고 학습하는 좋은 기회가 되었다.

코드 아키텍처의 중요성

  • 프로젝트 진행 초반에 디렉토리 및 파일 구조와 소스 코드를 어떻게 작성할지에 대해 고민하는 과정에서 멘토님의 도움을 받아 <Router – Controller – Service – Repository>의 네 단계로 구성하기로 했다. 디자인 패턴에서 자주 접할 수 있는 MVC 구조와 비교하면 Model과 Controller 사이에 Service가 하나 더 생긴 꼴인데, 비즈니스 로직과 Repository를 분리하는 것으로 더 깔끔하고 명확하면서 유지보수에 용이할 것이라는 생각을 직접 코드를 작성하면서 체감할 수 있었다.

리팩토링의 중요성

  • 프로젝트 중반에 멘토링을 진행했는데, 소스 코드에 전체적으로 리팩토링이 필요하다는 조언을 받았다. 코드 리팩토링을 내가 담당하게 되었는데, 비록 리팩토링이 완벽하게 되진 않았더라도 생각보다 어렵지 않게 진행할 수 있었다. 지금 생각해보니 그 이유는 API 명세서에 객체지향 설계를 도입하라는 요구사항이 있었고, 다행히도 나는 초반부터 객체지향 설계를 고려해서 코드를 작성했기에 다른 코드들도 같은 방식으로 변환하는 데 큰 어려움이 없었다.
  • 또한 Prisma 인스턴스 또는 다양한 계층의 클래스 인스턴스가 각자 코드에서 생성되는 것이 기능 확장 및 유지보수성 측면에서 좋지 않을 것이라 생각했는데, 같은 부분을 우려한 팀원분과 협력하여 각 계층의 모듈을 index.js에 모으고, 각 index.js를 하나의 container.js에서 불러와 의존성 주입 패턴을 적용했다.
5. 개선점

글로벌 에러 핸들러

  • 팀원 각자가 기능별 개발을 담당하다 보니, 공통적으로 오류가 발생하는 부분에 대해 글로벌 에러 핸들러를 적용할 여지가 있었다. 부분적으로 글로벌 에러 핸들러를 적용하긴 했지만, 더 깔끔하고 가독성 좋게 코드를 리팩토링할 수 있었다. 그러나 그러지 못한 점이 아쉽다.
6. 결론

이번 팀 프로젝트는 Git과 Github을 활용한 사실상 첫 협업이었기에 감회가 깊다.

처음 프로젝트를 시작할 때의 역할 분담과 스키마 설계 과정을 지나고부터는 어느 정도 원활하게 개발이 진행되었지만, 개발 도중 발생했던 팀원과의 미스커뮤니케이션이나 각종 에러, Git 경험 미숙으로 인한 커밋 충돌, 코드 리팩토링, 그리고 프론트엔드에서의 작동 확인에 애를 먹었다.

그러나 지나고 보면, 진행 과정에서 애먹었던 부분을 해결하는 과정에서 문제해결 능력을 기를 수 있었고, 몰랐던 부분을 충분히 익히는 기회가 되었다.

만약 나중에 같은 문제와 직면했을 때 큰 수고를 들이지 않고 해결할 수 있을 것이라는 자신감이 생겼으며, 지속적인 팀 프로젝트 경험을 통해 더 큰 문제와 맞딱드리고, 해결해보고 싶다는 생각마저 드는 귀중한 경험이었다.