원티드 프리온보딩 백엔드 - 2주차 과제

2주차의 두 번째 과제는 7월 4일 월요일부터 7월 8일 금요일까지 가계부 서비스의 api를 개발하는 것이었다.

페이히어에서 제시한 과제로, 기본적인 CRUD에 충실한 과제였다.

요구사항으로는, 유저관리 기능(회원가입, 로그인)과 유저이 소비내역을 기록, 수정, 삭제, 복구 하는 것이었다.

 

이번 과제는 지난 과제에 비해서 요구사항이 명확했기 때문에, 기능 분석에 대한 회의는 금방 끝났다.

회의에서 가장 길게 논의했던 내용은 모델링 이었다.

단순하게 요구사항을 충족시키기 위해서는 소비내역에 관한 모델과 유저에 관한 모델만 있으면 된다.

그러나 우리 팀은 '과제를 내준 기업 입장에서 이 기능을 어떻게 사용하고 싶을까'였다.

 

페이히어의 주요 서비스는 포스 앱이다. 그래서 주요 고객은 자영업을 하는 사장님들이다.

우리 팀은 이 부분에 초점을 맞추었고, 이 사장님들이 가계부 서비스를 이용할때의 상황을 가정했다.

일반적으로 가계부에는 월별로 소득, 지출에 관한 내역들을 기록한다.

두 개의 사업장을 가진 사람도 있을 수 있다.

위 두가지 상황을 만족시키기 위해, 우리는 모델링을 단순히 내역 모델 하나가 아니라,

가계부 모델과, 내역 기록 모델로 분리하였다.

아래가 최종 모델 ERD 이다.

AccountBook 모델을 통해 사업장이나 특정 달을 분리하여 내역을 관리할 수 있다.

이렇게 모델링이 되고 나서 api 개발은 담당해주었던 팀원들에 의해 수월하게 진행되었다.

이번 과제에서 나는 배포를 담당하였다.

엘리스 AI 트랙 과정 당시에, 배포를 진행한 프로젝트는 두 개의 팀 프로젝트들이었는데, 두번 다 내가 배포를 담당하지 않아서

서비스를 배포해본 경험은 없는것과 마찬가지였다.

그래서 이번 프로젝트에서는 내가 배포를 담당하겠다고 자원했다.

요즘은 도커를 쓰지 않고 배포하는 경우는 거의 없는것 같을 정도로, 도커를 많이 쓰고, 채용공고에서도 도커를 써본 경험이 있는지에 대한 항목이 자주 보였기 때문에, 이번 기회에 도커까지 사용해서 배포를 해보자 마음먹었다.

배포를 하면서 애를 먹었던 내용은 프로젝트 진행 당시에 글을 남겼던 것이 있어서 이 포스트에서는 다루지 않겠다.

👇

Django + Docker + NginX + gunicorn 배포

결론적으로는 성공적으로 서비스 배포를 할 수 있었다.

 

옛날에 처음 도커라는걸 알게 되었을때는 CLI 환경 자체도 익숙하지 않아서 도커가 더 어렵게 느껴졌는데, (물론 도커를 GUI로 다룰 수 있는 프로그램이 있긴 하지만, 도커의 이미지와 컨테이너의 개념이 정리되지 않아서 그것조차 다루기 어려웠다.)

이번에 한 번 성공 경험을 하고 나니까 자신감도 생기고, 앞으로 배포할때 어떤 준비와 과정을 거쳐야할지 정리가 된것 같았다.

---

프로젝트 회고 🤔

아무래도 두 번째 프로젝트이다 보니, 첫 번째에 비해서 전반적으로 팀원들간의 합이 조금씩 맞아간다는 느낌을 받았다.

 

첫 번째 프로젝트에서 아쉬웠던 점을 보완하기 위해 컨벤션을 더 상세히 정해서 내용을 업데이트 했는데, 덕분에 커밋 메세지들을 볼 때

개발 사항이나 수정사항등을 더 정확하게 받아들일 수 있었다.

그리고 이번 프로젝트에서는 초기 개발환경 셋팅을 맡아준 팀원이 새로운 기능을 추가해주셨다.

바로 pre-commit 이라는 건데, 커밋을 하기 전에 코드 스타일과 컨벤션이 기준에 잘 맞춰져 있는지 확인하는 기능이다.

pre-commit을 실행하면 sort, black, flake8 세 개의 라이브러리들이 코드들의 일관성을 검사해주고 자동으로 수정해준다.

(세 개의 라이브러리를 모두 사용한 이유는, 각 라이브러리들 마다 놓치는 사항들이 일정부분 있었기 때문에 그것들을 최대한 잡아내기 위해서이다.)

우리가 정한 컨벤션을 수동으로 지키면서도, 자동으로 코드 스타일을 다시 한번 더 맞춰주는 프로그램을 사용했더니 이전보다 훨씬 더 통일성 있는 개발을 할 수 있었다.

 

이번 프로젝트는 개발할 api가 어려개였기 때문에, pr에서 조금 더 깊이 있는 리뷰가 이루어졌던 좋은 경험을 할 수 있었다.

우리팀은 기능개발을 하고 pr을 생성했을 때 최소 2명의 리뷰와 승인이 있어야 머지가 가능했는데, 이 과정에서 다른 사람들의 코드를 보면서 이해가 되지 않는 점에 대해 리뷰로 질의응답을 할 수 있었다.

특정 코드라인에 대해서도 코멘트를 남길 수 있기 때문에 질문도, 답변도 명확하게 주고받을 수 있다고 느꼈다.

이렇게 코드 리뷰가 더 활발하게 이루어진 데에는, pre-commit의 공도 매우 크다고 생각한다.

코드 스타일이 일관되기 때문에, 다른 사람의 코드도 눈에 쉽게 들어오고 잘 읽히니까 질문도 가능했던것 같다.

(사실 이전 프로젝트에서는 pr 리뷰할 때, 잘 이해되지 않는 내용들에 대해서는 그냥 넘어갔던 경우도 있었다. 😅)

 

브랜치 전략에 대해서 새로운 의견이 나왔던게 있는데, 기존의 feature-main 전략에서 feature와 main 사이에 브랜치를 하나 더 추가하는게 어떨까하는 의견이었다.

기존의 브랜치 전략으로는 feature에서 기능 개발하고 바로 main으로 머지하기 때문에, 만약 지속적으로 개발과 통합, 배포가 이루어지는 상황이라면 적합하지 않다. feature에서 개발한 기능이 기존의 서비스에 문제 없이 잘 통합이 되는지에 대한 확인을 main에서 해야했기 때문이다.

모두가 기존 브랜치 전략에 대한 문제점에 동의하긴 했지만, 나는 개인적으로 기존의 방식을 이어가는게 좋을것 같다고 생각했다.

우선 제일 큰 이유로는 이제 겨우 두 번째 프로젝트이기 때문에, 기존의 방식에 더 익숙해질 수 있도록 이어가고 싶었다.

그리고 짧은 기한 안에 프로젝트를 완수해야하는 현 상황에서, 새로운 변경사항으로 인해 생길 수도 있는 문제들로 시간을 뺏기는것은 너무 큰 리스크라고 생각했다.

기존 방식으로도 pr과 코드 리뷰는 가능했기 때문에 우리의 경험적인 측면에서도 문제가 없다고 생각했다.

이러한 내 생각을 팀원들과 나누었고, 결국에는 기존 방식을 그대로 가져가는걸로 결정했다.

 

이번 프로젝트를 마무리 하고서는, 다음 프로젝트때 우리 팀이 얼마나 더 죽이 잘 맞을지 기대가 컸던것 같다.

프로젝트를 하면서 기술적으로 배우는것도 많지만, 팀으로 어떻게 뭉쳐야 하는지에 대해서도 많이 배우고 있고 즐거운 경험이다.

 

GitHub - pre-onboarding-3rd-team-H/02_Payhere_TeamH: 페이히어 기업과제 레포지토리입니다. 가계부를 생성하