1. 서론
본 프로젝트는 중고차 계약 관리 서비스 개발로, 고객사의 관리자가 차량 및 고객의 계약과 계약서를 쉽고 효율적으로 관리할 수 있는 서비스 제공을 목표로 하였다. 팀 단위로 진행되었으며, 이 프로젝트에서 난 계약서 파일의 업로드 및 다운로드, 계약 목록을 조회하는 API, 그리고 등록된 계약들에 대한 통계를 산출하여 도표로 표시해 주는 대시보드 API의 개발을 담당하였다.
2. 개인 담당 파트 및 역할
계약 목록 조회
- 등록된 계약 목록을 DB로부터 가져온 후, API 명세에 맞게 가공하여 반환
- 페이지네이션 가능
- 계약서명, 담당자명으로 검색 가능
계약서 파일 업로드 및 등록
- 유효한 확장자(jpg, png, pdf)의 파일만 업로드 가능
- 업로드 파일 개수, 용량 제한
- 계약서가 등록될 경우 고객에게 자동으로 계약서가 첨부된 이메일 발송
계약서 파일 다운로드
- 업로드 된 계약서 파일 중 일부 혹은 전체를 일괄 다운로드 가능
대시보드를 위한 통계 데이터
- 이달의 매출, 진행 중인 계약 수, 성사된 계약 수를 표시
- 차량타입별 계약수, 차량타입별 매출액을 표시
- 저장된 계약 및 차량 데이터 등을 DB 집계 함수를 통해 계산 및 가공하여 반환
3. 진행 과정
- 팀원 간 역할과 책임 정의, 일정 조율, 컨벤션 결정
- DB 스키마 설계
- 레이어드 아키텍처 설계 패턴을 적용하여 각 역할에 해당하는 기능 개발
- 리팩토링 및 버그 수정, 테스트
- 코드 품질관리 및 배포
- 프로젝트 마무리 후 발표
4. 배운 점
코드 리뷰 및 피드백의 중요성
- 초급 프로젝트에서도 느꼈지만, 프로젝트 진행 및 개발에 있어서 코드 리뷰 및 피드백은 더 나은 개발자가 되기 위해 너무나도 중요한 과정이다. 이번 중급 프로젝트에서는 Github의 Issue와 Pull Request가 이전 프로젝트보다 더 활발히 등록되었는데, 작성한 코드에 대한 문제점이나 개선점, 혹은 발견된 오류에 대해 어떻게 해결하면 될지 예시 코드를 제안받는 등 구글 검색이나 AI를 통한 배움과는 다른 맛이 있었다. 특히나 ‘프로젝트 완수’라는 공동의 목표를 갖고 있는 사람들이기에 열정을 갖고 개발에 임할 수 있었다.
Pre-commit Hook의 중요성
- 팀원 중 한 분이 프로젝트 초기 계획 된계에서 Husky와 Vitest를 이용하여 Pre-commit 단계에서 코드의 유효성을 검증하고, 단위 및 통합 테스트를 자동화하여 커밋 후에 발생할 수 있는 오류를 미연에 방지할 수 있도록 컨벤션을 구성하였다.
git commit커맨드를 실행하면 커밋 메시지 창이 뜨던 초급 프로젝트 때와는 다르게 미리 설정해 둔 테스트가 실행되는 것이 다소 어색했지만, 코드의 유효성을 검증한 다음 브랜치에 최종 병합되어 나중의 수고를 덜어주는 아주 중요한 역할을 하였다.
테스트의 중요성
- 위에서 언급한 Pre-commit Hook의 Task에 있었던 테스트는 Vitest라는 패키지를 활용하여 이뤄졌는데, 단위(Unit) 테스트, 통합(Integration) 테스트, 그리고 엔드투엔드(E2E) 테스트로 규모별로 나누어 진행하였다. 그중 엔드투엔드 테스트는 전체 애플리케이션의 처음부터 끝까지의 사용자 시나리오를 검증하는 테스트인데, 시간은 좀 걸리지만 앱 전체를 검증해주기에 사용자 경험을 향상시키고 잠재적인 문제를 조기에 발견하여 개발 효율성을 높이는 장점이 있다. 초급 프로젝트에서는 이런 테스트 도구를 전혀 사용하지 않고 개발자가 일일이 테스트를 했기 때문에, 버그를 발견하고 수정하기까지 시간이 오래 걸렸다.
5. 개선점
컨테이너화
- 팀원 중 한 분이 백엔드 서버를 Docker로 컨테이너화하여 배포 과정을 단순화하자고 제안하셨고, 실제 도커 설정 파일을 작성하고 도커 이미지까지 생성하긴 했다. 그러나 발표까지 시간이 촉박했기에 Docker를 충분히 활용하지 못했고, 아직 컨테이너 사용 경험이 별로 없어서 여러가지로 미숙했다. 개발을 마치고 서버에 배포하는 과정에서 환경변수의 설정이나 패키지 설치 등, 여러가지로 신경써야 할 부분이 많다. 그러나 컨테이너를 사용한다면 이러한 수고를 덜 수 있을 것이다.
타입 안정성
- 초급 프로젝트에서는 타입 안정성이 없는 JavaScript를 사용하였지만, 이번 프로젝트에선 TypeScript를 사용하였다. 타입 안정성을 위한 여러 가지 기능을 지원하는 TypeScript를 십분 활용하기 위해 Type, Interface 등을 최대한 많이 활용하려고 애썼으나, 타입과 인터페이스를 정의하고 DTO를 작성하는 것은 꽤나 수고로운 작업이었고, 결국 충분히 활용하지 못했다고 생각한다. 타입을 정의하는 것이 수고스러운 작업일지라도 JavaScript 대신 TypeScript가 현업에서 주류로 사용된다는 것을 보면 타입 안정성이 주는 장점은 내가 생각하는 것보다 훨씬 클 것이므로, 다음 프로젝트에서는 이를 유념하고 타입 안정성에 신경을 써야 할 것이다.
6. 결론
이번 팀 프로젝트는 타입스크립트를 사용한 첫 프로젝트인데, 사실 타입을 사용한다는 점을 제외하면 초급 프로젝트와 난이도는 큰 차이가 없다고 느꼈다.
그러나 좋은 팀을 만난 덕분에 여러가지를 배웠고, 발표 또한 성공리에 마무리할 수 있었다.
이번 프로젝트를 진행하면서 느낀 점 중 하나는, ‘팀 프로젝트’에 ‘팀’이 들어가는 이유는 팀원들끼리 서로 협력하고 돕기 때문이란 것이다. 당연한 말처럼 들리지만, 팀 프로젝트를 더 팀 프로젝트처럼 진행하기 위해서는 소통과 협력이 꼭 필요하고, 만약 그렇지 않다면 개인전과 크게 다르지 않다고 생각한다.
그렇기에 이번 프로젝트는 팀 프로젝트가 무엇인지 다시 생각하게 되는 좋은 경험이었다.