[팀 프로젝트] 아웃소싱 - 배달 어플리케이션 구현

1. 프로젝트 시작

 

이번 프로젝트는 배달 어플리케이션을 외주 받았다라는 상황을 가정하여 짧은 개발 기간동안 클라이언트의 요구사항에 맞게 프로그램을 개발하는 것이었습니다.

 

보통의 프로젝트와 다를바 없는 것 같지만, 이전의 일주일간 진행한 팀프로젝트와의 차별점은 필수적으로 구현해야하는 기능이 조금더 늘어나고, 새롭게 구성된 팀원과 협업을 통해 어떻게하면 짧은 시간에 최고의 효율을 낼 수 있는가 가 핵심포인트였다고 생각합니다. 또한 기존의 프로젝트는 회원, 게시글, 댓글 정도의 각 `테이블(Entity)` 간의 연관관계가 간단한 것이 아닌, 회원, 가게, 메뉴, 주문, 리뷰 등의 필수적인 5가지의 기능에서 각각의 엔티티간 매우 세세한 연관관계 설정이 필요했습니다.

그리고 추후에 추가될 기능에 따라 더 복잡한 연관관계가 구성되게 됩니다. 테이블을 추가하는 방법과, 관련있는 엔티티에 필드를 추가하는 방법이 있겠지만, 이번 프로젝트에서는 테이블을 추가하는 방식을 많이 사용한 것 같습니다.

 

2. 프로젝트 설계

팀원과 프로젝트를 설계하기 시작하면서 여러 의견 충돌이 있었던 것 같습니다. 처음에 발생했던 문제는 의견 충돌의 정도는 아니었고 엔티티의 연관관계를 얼마나 이을지에 대한 내용이었습니다. 리뷰와 회원을 가깝게 엮으면 URL 이 간소화 되겠지만 RESTful 한 지에 대한 의논이 오갔습니다.

 

사실 이 타이밍에 대화를 하다가 URL 설계를 `/members/{memberId}/stores/[storeId}` 의 식으로 가다보면 리뷰에서 URL 이 가지는 정보가 너무 많지 않겠는가? 라는 의문도 들었고 그렇지 않으면 RESTful 한 프로젝트 개발 법칙의 위배되지 않느냐? 라는 의견 충돌로 이어졌습니다. 이후에 연속적으로 발생한 의견충돌은 애초에 RESTful 한것이 옳은 것이 맞는가? 라는 질문이 나오게 되었고, 이 부분은 시니어개발자에게 상담을 요청하여 협의점을 정했습니다.

 

근거는 "RESTful 한것이 반드시 정답은 아니다" 였던 것 같습니다. 그래서 저희는 다양한 URL 설정방식이 있겠지만, 메인이 되는 정보만 @PathVariable 로 데이터를 전달하고, 부가적인 가게, 메뉴, 주문 등 상황에 따라 ID 값을 호출하는 것을 DTO 에 담아서 전달하자고 정했습니다.

 

이렇게 하니 확실히 URL 자체는 깔끔해졌다고 생각이 들지만 팀원들과 매번 URL 변경에 대한 잦은 논의가 발생했던것 같습니다.

최종적으로 저희 팀이 설계한 API 명세는 다음사진과 같습니다.

 

 

이 사진은 저희가 개발한 다양한 API 들중에 일부입니다. 보시는 바와 같이 메뉴를 생성하는데 URL 에서 가게를 참조하지 않고, Request Body 에서 요청하는 것을 볼 수 있습니다. 프로젝트의 규모가 커지고 연관관계가 복잡해짐에 따라 이런 방식으로 URL을 설계하는것도 필요할 것 같습니다.

 

그리고 `Entity Relationship Diagram` 에 대한 얘기를 했습니다.

처음에 필수적으로 구현해야하는 기능들만 해도 5개의 테이블을 연관지어야 했고, 이 부분에서 상당히 오래걸렸던 것 같습니다. 하지만 프로젝트 시작하기 앞서 가장 중요한 부분중 하나라고 생각하기 때문에 충분히 토론하고 디테일하게 필드들을 설정해 가며 프로젝트를 설계한 것 같습니다. 다음에 오는 사진은 `ERD`에 대한 내용인데, 현재는 다양한 기능들이 추가되면서 테이블들이 더 추가되어 상당히 복잡해 보이는 모습입니다.

 

 

 

처음부터 이 설계를 그리고 시작했다면 막막해서 도전 자체가 힘들었을거라고 생각합니다. 초기에는 클라이언트에게 요구받은 사항에 따라 필수적인 기능만 구현하고, 추가적으로 여러 테이블이 생겨난 것인데 테이블을 보니 프로젝트가 꽤 규모가 생기고 긴밀한 관계를 가지고 있구나 라는 생각이 들었습니다.

 

참고용 와이어프레임

 

3. 개발 시작

개발에 돌입하고 가장 가까운 날짜로 목표를 설정했습니다. 금요일에 프로젝트 설계를 마쳤고, 월요일 까지 모든 필수기능을 구현 완료하자라는 방식이었습니다. 사실 지금까지는 요구사항에 따른 필수구현까지만 하면 만족하는 경우도 있었는데 이번에는 최대한 욕심을 부려보고 싶었습니다.

 

그래서 개발시작하고 프로젝트 설계가 끝난 단 하루만에 모든 필수기능을 구현하자고 한 것인데, 생각보다 팀원들과 막힐때 마다 영상을 공유하고 소통하면서 코드 작성이 수월하게 이뤄진 것 같았습니다.

 

그리고 팀원이 5명이니 각각 개발하는 방식이나 스킬이나 역량이 다를 수 있는데, 다행히 프로젝트를 시작하기 전 팀 프로젝트에 진입하면 필요할 것 같은 기본적인 스킬 같은것을 서로 정보를 공유하고 코드 작성하는 방식을 알려주고 연습하고 했던 것이 많은 도움이 된 것 같습니다.

 

제가 맡은 파트는 리뷰 작성 수정 삭제 파트였는데, `Soft-Delete' 방식으로 데이터를 삭제해도 조회만 되지않게 설정하여 DB에는 남아있게 하도록 했습니다.

 

이후에 팀원들이 하나둘씩 기능을 완료하고나서 월요일 저녁, 화요일엔 모든 코드들을 병합하고 완성된 코드를 테스트 하자는 이야기가 나왔습니다. 테스트가 완료되고 나서는 지저분한 코드를 리팩토링 하는 과정을 거쳤고, 기능 완료가 모두 확인되고 나서 부가기능을 추가하자는 논의가 나왔습니다.

 

추후에 저는 배달 주문상태를 가게 사장님이 수락, 완료 등 상태변경 시, 이메일로 사용자에게 알림을 보내는 기능을 추가했습니다. 그리고 유저가 원하는 가게를 검색하고 목록을 요청할 때, 광고된 가게들은 맨위 상단에 `[Advertisement]` 라는 메세지와 함께 우선적으로 표시되는 기능을 추가하였습니다.

 

이 기능까지 구현하게 될거라고 생각하지는 못했는데 짧은 목표를 잡고 빠르게 달성해온 방식이 매우 효율적이었다는 생각이 듭니다.

 

4. 트러블 슈팅

프로젝트를 완성하고 또 빠질 수 없는 테스트 코드 작성 부분에서 문제가 발생했습니다. 테스트코드 작성을 해본 경험이 많지않아서 테스트 코드를 성공적으로 끝내려고 하다보니 테스트코드가 오히려 복잡해지는 상황이었습니다.

 

이렇게 테스트코드가 복잡하고 설정해야하는게 많다면, 과연 테스트코드의 의미가 있다고 볼 수 있을까? 하는 딜레마에 빠진것 같습니다.

 

그래서 이 부분에 대해서 팀원 및 시니어분들과 상담 후 테스트코드의 객체 설정 방식을 바꿔야한다라는 조언을 받고 시도해보려고 했지만 이 부분은 완벽하게 해결해내지 못한 것 같습니다.

 

그리고 팀에서 소통에 있어서의 문제도 발생했습니다. PR을 올려도 팀원들이 본인의 코드를 작성하느라 리뷰를 하지않고 승인도 하지않아서 최신화된 코드를 받아서 사용하는게 늦어지고 개발이 중단되는 상황이 발생했었는데, 이 부분은 코드리뷰를 가능한 빠르게 하고 자주하자. 라는 약속을 정해서 해결할 수 있었던 것 같습니다.

 

5. 프로젝트 마무리

완성된 프로젝트를 정리하여 발표하고 피드백 받기위해서 발표자료를 만들었습니다. 소소한 부분이지만, 원래 피피티를 만드는데 부담감이나 어려움은 없어서 자주 만들었는데 이번엔 영상도 살짝 편집해보면서 영상편집이 생각보다 별거아니라는 생각도 들게되었습니다. 다음에는 좀더 나은 자료로 프로젝트를 시연하거나 발표에서 녹여낼 수 있을 것 같아서 좋았습니다.

 

 

마지막 발표자료로 이런 자료를 만들었는데 어느정도 다른분이 만드신 템플릿을 참조했지만 깔끔하게 만들어진 것 같아서 다행이라는 생각이 듭니다.

 

6. 프로젝트 후 회고

프로젝트가 끝나고나서 하얗게 불태웠다..라는 마음으로 팀원들과 모여서 회고를 작성해보았습니다. KPT 회고라는 방식이 있는데 이것을 Figma 에서 눈에 쉽게 들어오는 방식으로 작성했습니다.

 

이런식으로 보드에 메모지를 붙인 형식으로 제작했는데 제가 작성한 회고는 빨간색 입니다. 글자가 작아서 보이진 않지만 주로 생각했던 내용을 정리해보겠습니다.

 

Keep

초기에 팀원들의 코딩 방식이나 스킬을 파악한 뒤, 같이 실력을 맞춰보고 공부하면서 프로젝트에 돌입하기전 기본기는 좀더 가다듬고 가는것이 좋았던 것 같습니다. 그리고 선택적인 추가기능을 도전할 때, 한번도 해보지 않았던 것을 과감히 도전한 부분이 좋았던 것 같아서 더 다양한 기능을 시도해보고 싶다는 생각이 들었습니다. 또한 Github 에서 프로젝트를 칸반보드로 정리하면서 진행했던 것이 깔끔하고 프로젝트의 상황을 판단하기 좋았던 것 같습니다.

 

Problem

스스로 맡은 부분이 빨리 끝낼 수 있는 부분이다 라는 생각이 은연중에 있어서 그런지 개발을 빨리 진행하지 않았던 것 같습니다. 목표한 월요일 저녁이 개발 끝 이었으면 월요일 저녁까지 맞춰서 개발하는게 아닌 월요일 오후에 개발을 끝내고 팀원들의 상황을 파악하며  도움을 줬더라면 모두가 좀더 편하지 않았을까 하는 생각이 들었습니다.

그리고 트러블 슈팅에 대한 내용을 세세하게 기록하지 않았던 것이 아쉽습니다. 최대한 5분기록보드를 활용하여 문제가 발생했을 때 그 부분에 대하여 기록을 하려고는 했으나 처음 해보는 기록방법이라 잘 되지 않았던 것 같습니다.

그리고 깃 컨벤션을 처음 완벽하게 설정한 후 팀원에게 100% 일치하게 통일해서 깃허브에서 여러 작성을 했더라면 좀더 프로젝트가 전반적으로 깔끔해 보였을텐데.. 라는 생각을 했습니다.

 

Try

이번에는 테스트코드에 대해서 아직 지식이 좀 부족하여 테스트코드 커버리지를 그리 높게 달성하지는 못한 것 같습니다. 다음 프로젝트에서는 최소 50% 이상의 테스트 커버리지를 보이고 싶습니다. 그리고 팀원들과 구현하기에 급급한 것이 아닌 작성된 코드를 같이보며 리뷰하고 토론하는 시간도 갖고싶습니다. 그런 대화를 하다보면 어려 컨벤션이나 코딩하는 방식에 대해 배울 수 있는 것 같습니다.

 

마지막으로 프로젝트를 통해 느낀점을 간략히 요약하자면, 역시 협업을 하면 못해낼 것이 없는 것 같습니다. 개발에 대한 지식이 있던 전공자든, 비전공자든 협업을 통해서 팀원이 모르는 부분은 알려주고, 내가 모르는 부분이나 막히는 부분은 물어보고 하는 방식으로 조언을 받으면 잘 안되던 문제도 쉽게 해결되는 것 같습니다. 특히 개발자라면 누구나 겪는 미세한 오타 하나로 제대로 돌아가지않는 프로그램을 팀원들과 같이 프로젝트를 보면 금방 찾아버려서 도움이 되는것 같습니다. 여러가지로 배울점이 많았던 프로젝트 같습니다.