2주 프로젝트 회고

Sunmin

Published in

Hello, world?

5 min readJul 12, 2020

많이 배웠지만, 아쉬움도 그만큼 많은 2주였다.

내가 발표했던 장기, 단기 목표를 함께 관리하는 to do list 아이디어가 감사하게 채택 되었고, 3명의 팀원분들의 동의 하에 팀장을 맡았다.

실력은 제일 부족하지만 팀장이기에 전체적인 흐름을 언제나 파악하고 있어야 했고, 팀원분들간의 소통을 돕는 역할이 아주 중요했는데 그래서 재미있으면서도 곤란한 상황들이 종종 있었다.

아쉬운 점과 배운 점을 쭉 생각해보았는데 어찌보면 당연하겠지만 공통되는 항목들이 대부분이었다. 그 점들을 복기해보면서 다음 프로젝트는 더 재미있고 알찬 결과물을 만들어내고 싶다.

1. 초기 기획은 아무리 자세해도 지나치지 않다.

우리 팀은 운이 무척 좋았다. 백엔드, 프론트엔드에 실력이 좋은 분이 한 분씩 계셔서 많이 의지할 수 있었다. 특히 백엔드의 원준님 덕분에 스키마의 구조를 잘 잡을 수 있었다.

하지만 초기에 상세페이지 등을 자세하게 나누지 않아서 (물론 그 당시에는 이 정도면 자세하다고 생각했다) 이 부분의 데이터가 어떤 테이블로 이동하는지, 저 부분을 클릭하면 어떤 데이터가 렌더되야하는지 등에 대해 서로 다른 생각을 가지고 있음을 알게 되었고, 뒤늦게서야 다시 긴 회의를 했다. 결국 화요일에 킥오프를 받고, 일부 수정한 스키마를 목요일이 되어서 다시 한번 완전히 뒤집었다.

다음 프로젝트 때에는 페이지의 모든 기능에 대해 와이어프레임을 상세하게 그려두고 진행할 것이다.(너무 당연한 이야기여서 민망할 지경)

2. task card의 적절한 분배

우리의 db table은 크게 users, plans로 나눌 수 있었고, 각각의 단계를 task card로 작성해보긴 했는데 그것을 어떻게 나눌지가 관건이었다.
그래서 태스크도 users, plans로 나누어서 assignee를 지정했는데 프로젝트를 진행할수록 users에 비해 plans의 업무량이 너무나 많았다. 내가 맡은 백엔드의 users 부분은 지난 주 금요일에 이미 다 마쳐서, 혹시 plans 부분을 함께 할 것이 있는지에 대해 의견을 나누었지만 로컬에 하는 mysql작업인만큼 업무 분할이 쉽지 않았다. 그래서 상대적으로 내 역할이 조금 붕 떴다. 그래서 프론트를 함께 하기로 했는데 우리의 어플리케이션 특성상 daily, weekly, monthly, annually가 모두 긴밀하게 엮여 있었고, 이미 프론트의 plans가 진행되고 있었어서 중간에 발을 담그기가 어려웠다.(지나고보니 모두 핑계이긴 하다)

그래서 나는 소셜로그인, 목표의 성취 여부를 조절하는 체크박스와 그로부터 데이터를 얻어 성취도를 그래프로 나타내는 것을 구현하기로 했다. 소셜로그인은 비교적 간단하게 구현했지만, 체크박스와 성취도는 plans의 get 메소드가 구현이 되어야 작업할 수 있었고 이미 프론트의 팀원분이 모든 페이지의 post와 get을 함께 작업 중이셨기에 기다리는 수밖에 없어 아쉬웠다.

다음 프로젝트 때에는 users파트는 빠른 시간 내에 진행하고, 메인이 되는 파트의 태스크 카드를 최대한 상세하게 분리하고, 사용가능한 시간과 능력에 맞추어 assignee를 지정할 수 있도록 최대한 많은 이야기를 나눌 것이다.

3. 소통은 아무리 해도 지나치지 않다.

분명 충분히 소통을 한 것 같지만 그럼에도 부족했다. 소통이 되지 않는 부분이 있을수록 태스크의 진척도를 한 눈에 파악하기 어려웠고, 그러다보니 코드 리뷰를 할 때에는 너무 많은 코드가 쌓여있어서 코드를 짠 당사자 외에는 흐름을 이해하기 힘들었고, 결국 pull을 하면 수많은 conflicts가 발생했다.

그리고 말을 할 때는 상대방을 존중하는 말투도 꼭 필요하다. 꼭………….!!!!!

4. 코드리뷰는 comment기능을 이용

github의 comment 기능을 상대적으로 늦게 인지했기에 코드 리뷰가 효율적이지 못했다. 원래는 같은 포지션끼리 서로의 origin을 추가해서 하려했는데 pull이 안 되어서 upstream에 새로운 브랜치를 만들어서 코드리뷰를 했으나(차마 dev에 바로 올리기에는 겁이 났다) 승재님의 조언으로 코멘트 기능을 이용하기 시작했다. 특히 상대적으로 프론트의 코드 리뷰가 원할하지 못했던 것은 무척 아쉽다. 그리고 그것이 하루 이틀 쌓이니 결국 효율적인 리뷰가 이루어지지 못했다.

다음 프로젝트 때에는 팀원분들과 상의를 해서 어떠한 주기로 코드리뷰를 할 것인지 초기 기획 때 꼼꼼하게 결정을 하고, 반드시 모든 팀원이 코드리뷰를 하고, 그에 따라 merge, pull의 시점을 결정해서 충돌이 발생할 가능성을 최대한 낮추고 싶다.

5. 배운 것

1–4의 목록들도 다 배운 것들이지만, 추가적으로 git flow(쓰면 쓸수록 놀라운 깃헙이여) 와 markdown 문법에 이전보다 익숙해졌다.
wiki 작성도 낯설었고, 특히 admin의 권한으로 repository를 다룬 것은 처음이어서 잘 감이 안 왔었는데, 이번에 경험을 했으니 다음 프로젝트 때는 실수를 줄일 수 있을 것 같다.

6. 결론

‘당연’의 사전적 의미는 ‘그렇게 해야 하는 것’이다.
지난 2주간의 시간동안 당연하다고 생각했던 것들이 ‘무의식적으로 그렇게 해오던 것'이 아닌 ‘그렇게 하도록 노력해야 하는 것' 이라고 느껴지는 순간이
많았다. 특히 팀장으로서 중재자의 역할을 해야했기에 소통이 중요하다는 것을 가장 많이 느꼈다.

또한 ‘같이 일하고 싶은 사람'의 자질에 대해 많이 배울 수 있는 감사한 시간이었다.

지난 2주간 겪고, 느낀 점들을 발판삼아 앞으로의 4주는 보다 애자일한 개발을 하고 싶다. 4주가 지나고 아쉬운 점들은 분명 남을 것이지만, 그 과정을 통해 한 단계씩 성장하는 것일테니 나를 믿고 정직하게 달려갈 것이다.