2차 프로젝트 - Airbnb 클로닝

1차 프로젝트, 삼천리 클로닝의 테마는 우리가 위코드에서 배웠던 것을 구현해보는 것이였다고 한다면 2차 프로젝트의 테마는 소셜 로그인과 전보다 조금 더 무거운 작업량을 배분하고 해결해나갈 수 있는지였던 것 같다.

회고에 대한 이야기를 하기 이전에 PM에 관한 개인적인 의견을 서술하고 싶다. 개인적으로 PM(Product Manager)라는 역할은 업무에 지장이 생겼을 때, 그걸 해결해 낼 수 있고 최대한 기한 내에 목표가 달성되게 할 수 있는 능력을 가진 사람이 맡아야 하는 역할이라고 생각한다. 하지만, 위코드에서는 멘토님들을 제외하고는 모두가 비슷한 수준의 능력을 가지고 있고, 프론트엔드와 백엔드 둘 다에게 도움을 줄 수 있는 인원이 없기 때문에 PM을 정하는 게 큰 의미가 있는가라는 생각이 있다. 그래서, 본인은 1,2차 프로젝트 모두 PM을 특정하지 않고 프로젝트를 진행했다. 물론, 회의 진행이나 비기술적 업무를 처리할 때는 본인이 리딩하여 나름 PM의 역할을 해냈다. 그런 부분에선 위에서 서술한 능력이 있다고 생각하기 때문에.

잘했다고 생각한 점

1. API 명세서

본인은 프론트엔드와 백엔드 간의 소통과 합의가 정말 중요하다고 생각한다. 그래서, 항상 데이터를 보낼 때도 어떤 Key값들이 필요한지 프론트엔드 개발자 분들에게 물어보고, 그걸 토대로 1차적인 API 명세서를 만들어 그 곳에 어떤 URL로, 어떤 method으로 요청을 보내야하며, 어떤 정보를 request headers와 request body에 담아 보내줘야 하는지, 그리고 그 결과로 어떻게 생긴 객체를 반환해 주는지를 상세히 적어주는 편이다. 후에 통신을 하며, 더 필요한 정보가 있으면 보내는 객체에 추가하고, 필요없는 정보를 보내주고 있으면 객체에서 제외하고 하며, API 명세서를 업데이트하면서 프론트엔드 개발자분들과 소통하는 것을 좋은 작업 방식이라고 생각하는데, 이번 프로젝트에선 그게 잘 이루어졌다. 1차 프로젝트와 달리 2차 프로젝트에선 혼자 모든 프론트엔드 개발자분들(4인)과 다른 API들로 통신을 했어야 했는데 API 명세서 덕분인지 그렇게 큰 문제나 충돌없이 모든 기능이 페이지와 연결되어 잘 통신되었고 기능 구현까지 잘 되는 것을 보며 만족스러웠다.

하지만, 2차 프로젝트는 좋았던 점보다는 아쉬웠던 점들이 훨씬 많았다.

아쉬웠던 점

1. 같은 파트 분업

1차 프로젝트 때 분업은 API 테마 기준으로 이루어졌었다. 예를 들어, 우리가 구현할 API가 사용자, 숙소, 그리고 결제, 이런 식으로 대분류가 되어있다면 팀원 A가 사용자, 결제를 맡고 팀원 B가 숙소를 맡는 식으로 말이다. 하지만, 이번 프로젝트에선 그 업무량의 차이가 극심했다. Airbnb는 숙소 중심적인 서비스를 제공하기 때문에 숙소에 관련된 API가 다른 테마보다 훨씬 많았다. 그래서, 처음에는 숙소 관련 테마를 다른 인원과 분업할 생각이였다. 하지만, 우리 인원 중에 기능 구현 외에 배포나 테스트, 그리고 로깅같은 부수적인 기능에 대해 깊게 파보고 싶다는 의지를 보인 인원이 있었고, 10일 남짓한 시간에 새로운 분업 방식, 거기서 파생된 conflict들을 고치는 과정, 그리고, 서로 다른 방식으로 설계된 Dao 단의 쿼리문을 이해하고 그걸 응용하여 service단, 그리고 controller단을 설계하는 과정을 한 명 없이 해내기에는 분명히 무리가 있었다. 본인이 숙소 관련 API들을 혼자 다 맡았을 때 다 만들어 낼 수 있을까에 대한 의구심이 조금은 들긴했지만, 할 수도 있지 않을까? 그리고, 제한된 기간에 어디까지 가능할까도 궁금하긴 했다. 그래서, 의지를 보인 인원을 믿고, 혼자 숙소 관련 API들을 다 해결하기로 했다. 그 과정에서 또 다른 인원이 S3를 이용한 이미지 업로드 미들웨어를 만들어주기도 했고, 미루지 않고 계획적으로 처리한 결과, 기능 구현에서 에러가 나거나, 사이트가 멈추지 않을 정도로는 작업을 해냈다. 하지만, 한 테마를 분업하는 것도 실무에선 비일비재한 일 일텐데, 그것을 경험해보지 못하고 기업협업을 나간다는 게 조금은 아쉽다.

2. 재난재해

이 부분은 워낙에 예측불허하고 말도 안되게 여러 재난이 겹친 문제라 짧게 무슨 일이 있었는지만 서술하겠다. 당초에 2주로 계획되어 있던 커리큘럼에서 추석으로 1일, 건물 내 화재로 2일, 태풍 경보로 1일, 총 4일 정도를 사무실을 사용하기 힘들어진 상황이 집중력도 흐트려놓고 작업 속도도 늦어지게 만들었다.

3. 테스트

2차 프로젝트는 1차 프로젝트와 달리 jest와 supertest를 사용하여 소스 코드의 완성도를 체크하는 과정이 필수적이였다. 이 과정에서 원래대로라면 테스트DB를 만들고, test.env파일에 그 DB를 연결하여 테스트 시작 전, 테스트용 데이터를 업로드하고, 테스트 후, 해당 데이터들을 삭제하고를 반복하여 진행해야 하는데 PR 리뷰와 리모트 merge에 걸리는 시간이 길어지며 테스트를 수정할 시간이 촉박해졌다. 그래서, 기한 내에 완벽한 테스트를 만들지 못한 게 아쉬웠다.

개선점

1번은 시간적 여유가 있거나, 한번 경험해본 인원이 있으면 쉽게 개선될 문제이고, 2번은 피할 수가 없는 상황이니 넘어가겠다. 요점은 3번의 개선점인데, 다음부터는 프로젝트용 DB와 테스트용 DB를 처음부터 만들고 시작해야 되겠다. 그리고, 모든 API를 만들고 테스트를 작성하는 것이 아니라 한 개의 API를 만들고, 그것에 대한 테스트를 만들고, 그 다음 API로 넘어가는 방식으로 작업을 진행해야겠다.