4주 프로젝트 회고
Published in
3 min readOct 16, 2019
- 프로젝트를 하면서 제일 잘 배웠다고 생각하는건 팀장으로서 잘 맞지 않는 팀원들과 이끌어나가는 방법이다. 이번 팀을 경험하고 나니 이전에 내가 대학교든 회사든 인연이 되었던 팀원들은 나랑 핏이 많이 잘 맞았었다고 지금은 평가할 수 있을것 같다. 이번은 프로젝트기간이 길어서 였을까. 아니면 정말로 핏이 안맞아서 그랬을까 충돌이 잦았다. 충돌이 나도 어찌하랴 그래도 프로젝트는 계속가야하고 포기는 있을 수 없다. 마음대로 풀지지 않고 마음이 억한 감정이 쌓이고 있을 즈음. 고통의 가치를 오히려 더 긍정적으로 활용할 수 있다는 조언을 들었고 그때 한번에 해소되는 감정을 느꼈다. 무너지지 않는 스킬을 배웠다. 처음엔 괴로웠지만 오히려 지금은 운이 좋았다고 생각한다.
- 하지만 그런 좋은 결과에 도달하기 전엔 후회했다. 이런 느낌이 사실 이게 처음은 아니다. 내가 하고 싶은게 있으니까 팀장을 자꾸 하게는 되지만 그게 관리적으로 부담이 커질때는 후회하게 된다. 나는 평소에 팔로잉을 하는편이냐 팔로워를 하는편이냐 물으면 팔로워라고 말을 한다. 실제로도 그렇다. 항상 따라간다. 그런데 일의 측면에 들어가면 또 팔로잉 하는걸 답답하게 여기는게 사실이니까. 그냥 팔자려니 하고 앞으로도 계속 이끌어가는 입장의 무게를 담담하게 받아들여야겠다.
- 인프라 셋팅의 순서가 중요하다. 깔끔하고 배려깊은 셋팅은 전반적인 관리코스트를 줄여주는 역할을 톡톡히한다. 처음에 길을 뚫는데 전념해야 한다. 처음에 집부터 짓고 도로를 지으면 안된다. 할 수 있다면 최상의 시나리오는 다음과 같다. 인프라 > 백엔드 > 프론트엔드. 이렇게 할 수 없다면 독립적인 부분부터 작업을 해야한다.
- 잘못쓰여진 코드는 아무런 도움이 안된다. 후속작업을 하는 사람이 똑같은 내용을 또 만들어야한다. 최악이다.
- 오버커뮤니케이션을 하면 못해도 미스가 나도 화가 나지는 않는다. 그래서 팀원들이 그렇게 하게끔했다. 그러고나니 조금 팀관리가 쉬워졌다. 다니던 회사 차장 님이 생각났다. 왜 그렇게 작업관리를 할때 화를 내시는지. 작업의 효용성을 떠나 통제가 안된다는 주관적 감각에 너무나 스트레스를 받으셨을것같다.
- 어디 유튜브에서 최단시간 클론 프로젝트를 하거나 반복적으로 숙달된 작업을 단축하는 용도가 아니라면 2차 라이브러리에 처음부터 의존하면 안된다. 나중에 자신의 작업이 어떤 단계에 있고 어떤 기능으로 확장할 수 있는지 가늠할 수 없는 문제에 봉착하게 된다. 예를 들어 ‘React-google-login’보다 구글의 JS클라이언트 SDK를 쓰자.
- 마지막으로 배포부터 하고 시작한다.
