1. 인스타그램 클론 코딩 마무리 ( ~04.21)
인스타그램 클론 코딩을 마무리했다. 프로젝트 구현에 필요한 비즈니스 로직을 포함한 모든 코드들은 월요일에 모두 작성하여, 화요일부터 목요일까지는 실전 프로젝트에 대비한 공부를 자율적으로 여유롭게 진행할 수 있을 것이라 생각했지만 오산이었다. 프로젝트 마감 기한까지 내내 FE의 요청사항을 반영해서 잘못된 코드를 수정하기에 급급했다. 인스타그램 클론 코딩을 하면서 느꼈던 점은 크게 다음과 같다.
1-1) API 명세서는 시간이 걸리더라도 꼼꼼하고 확실하게 적자.
프로젝트 초반에 API 명세서를 작성하면서, 특히 GET method에 해당하는 API의 response를 작성하는데 매우 큰 곤혹을 겪었다. response로 전달해야하는 데이터의 양과 종류가 많았기 때문이다. 그래서 우리 팀 BE 파트는 비즈니스 로직 구현을 다 완료한 이후에, FE 파트에서 swagger로 resonse를 조회할 수 있도록 하자고 결론을 지었고, FE 파트의 동의 아래에 해당 방식으로 API 명세서에 resonse를 작성하는 것을 중단하고 비즈니스 로직 구현에 돌입했다.
결과는 처참(?)했다. reponse로 전달할 데이터의 변수명이 API 명세서에 명시적으로 합의되어 있지 않으니, BE 파트에서도 resonse로 보낼 변수를 각기 다르게 선언했고, FE도 마찬가지의 상황이 벌어졌던 것이다. 화요일부터 목요일까지 진행한 디버깅의 가장 큰 원인 중 하나는 바로 이것이었다.
API 명세서는 반드시 시간이 좀 더 걸리더라도, BE/FE 파트 모두가 통일된 코드를 작성할 수 있게끔 꼼꼼하고 확실하게 작성하는 것이 중요하다.
1-2) 로직을 구현할 때는 최대한 세부적인 예외처리까지 함께 고민해서 구현하고, 테스트는 한 번 할 때 확실하게 하자.
TDD 방식으로 개발을 했더라면, 이런 일이 발생하지 않았겠지만, 아직 TDD를 주도적으로 도입할 실력이 되지 않아, 서버를 배포한 이후에도 구현한 API가 의도한 대로 작동하지 않는 경우가 빈번히 발생했다. 버그의 원인은 API에 예외처리가 포함되지 않았던 것, 알고보니 FE 파트의 코드가 잘못되었기 때문 등으로 다양했다. 당연히, 이러한 원인들을 파악하기 위해서 BE/FE 파트 모두가 모여 코드를 뜯어봐야했다.
즉, 로직에 대한 확신이 없기 때문에 팀 전체의 시간이 낭비된 것이다.
팀 전체의 시간이 낭비되는 만큼, 프로젝트의 퀄리티는 낮아질 수밖에 없다. 그래서 나는 이번 클론 코딩을 하면서, TDD 방식의 중요성을 다시 한번 실감했고, TDD 방식을 도입하지 않는 상황이라면, 내가 작성한 로직에서 부족한 점이 없는지, 어떤 예외처리가 필요한지 한번 더 고민해봐야 할 필요성을 크게 느꼈다.
2. 실전 프로젝트 시작.(04.22 ~ )
드디어 실전프로젝트가 시작했다. 나는 과분하게도 팀 리더라는 직책을 맡고 프로젝트에 참여하게 되었다. 6주라는 기간 동안 여태까지 구현한 프로젝트보다는 기술적으로, 기획적으로 더 높은 퀄리티의 결과물을 내야하기 때문에, 리더로서 프로젝트를 잘 리드하기 위해 어떻게 해야할 지를 계속 고민했다. 고민은 아직도 현재 진행형이다. 현재까지 프로젝트를 진행하면서 리더로서 팀에 도입한 것과 스스로의 리더로서 팀을 대하는 관점과 방식에 대해 고민한 것은 다음과 같다.
2-1) 협업의 기본 원칙, 팀 기본 룰 정하기
하나의 주제에 대해 100개의 다른 의견을 생각할 수 있는 게 사람이라는 존재다.
팀의 의사결정 속도를 높이고, 작은 일로 인해 팀원 간에 감정이 소모되는 일을 미연에 방지하기 위해서, 6주동안 팀원으로서 서로가 지키면 좋을 팀 기본 규칙을 먼저 정했다. 정해진 룰은 대략적으로 다음과 같다.
- 미팅은 모든 팀원이 참여! 시간은 매일 오전 10시.
- 이해가 느리다고 미워하지 말아요!
- 업무 진행 중 변경 사항은 즉각적으로 공유하기
기본 룰을 정하면서 자연스레 팀원들 간 아이스브레이킹도 할 수 있었는데, 덕분에 좀 더 부드럽고 즐거운 분위기 속에서 팀의 첫 시작을 할 수 있었던 것 같다.
2-2) 논의는 항상 단계적으로 진행하고, 현재 안건에 대해서만 말하자.
프로젝트 기획이 생각만큼 원활하게 이루어지진 않았다. 항해99의 최종적인 결과물인 만큼, 모두가 프로젝트를 대하는 태도가 간절하고 신중하기 때문이었던 것 같다.
프로젝트 '주제', 즉 어떤 서비스를 할 것인가에 대해서 정하는 데만 반나절이 걸렸다. 그리고 '러닝' 과 '환경'이 프로젝트의 테마로 결정된 이후에도, 서비스의 목표, 비즈니스 로직을 논의하는데 많은 시간이 걸렸다.
논의에 많은 시간이 걸렸던 이유 중 하나는 종종 논의 내용이 현재 안건과 다른 내용으로 잠시 샜었기 때문이라고 회고한다. 예를 들어, 어떤 과일을 파는 게 좋을지?에 대해 이야기하고 있던 와중에, A가 "근데 과일을 팔 거면, 가게 인테리어는 이래야 할까?"라고 질문을 던졌고, 팀원 모두의 관심이 그 질문에 대한 답으로 쏠린 것이다. 나 또한 마찬가지였다.
그래서 논의를 진행하면서, 이와 같이 현재 안건과 다른 주제의 의견이 제시되면, 오, A님 의견 너무 좋은데요? 그런데 이건 그 다음 안건에서 이야기해봐요 라는 식으로 다시 논의 주제를 환기시키곤 했다.
물론, 그럼에도 불구하고 프로젝트 기획 자체의 진도가 잘 나가지 않았기 때문에, 시간은 많이 소모되었지만, 조금이나마 이처럼 논의 주제를 환기시키는 것이 시간을 줄이는 데 도움이 되었던 것 같다.
하지만, 이처럼 팀원의 의견을 잠시 반려시키는 과정에서 나의 말투가 해당 팀원에게 어떻게 들렸을 지는 계속 신경이 쓰인다. 좀 더 부드러운 말투로 논의 주제를 환기시키는 것을 고민할 필요가 있는 것 같다.
2-3) 모두 귤이 아니라 오렌지를 이야기하고 있는 거 맞지? 논의에 대한 팀원들의 이해도 체크하기.
아마 프로젝트 기획 시간을 가장 길게 끌었던 이유 중에 가장 큰 이유가 아닌가 싶다. 하나의 주제에 대해 100개의 다른 의견을 가지고 있을 수밖에 없는 게 사람이라는 존재이기 때문에, 하나의 안건을 합의한 이후에, 그 합의 내용에 대한 팀원들의 생각이 조금씩 달랐던 현상이 발생했다.
예컨대, 회의에서 자! 우리 귤을 팔아봐요. 라고 결정이 되었는데, 나는 귤을 오렌지로 이해했고, A는 한라봉, B는 천혜향으로 이해한 것이다.
무르게 보자면, 귤, 오렌지, 한라봉, 천혜향 모두 먹어보면 비슷한 맛을 내는 과일이라고 할 수 있겠으나, 많은 양의 복잡한 로직들이 들어가는 하나의 웹 서비스에서는 팀원들의 이러한 작은 이해 차이들은 돌이킬 수 없는 문제의 원인으로 작용할 수밖에 없다.
또한 작은 이해 차이들이 모이고 모여, 팀의 의사결정 속도를 저해시킨다. 위 언급한 것처럼, 우리 팀은 작은 이해 차이들을 그 때마다 확인하고 해결하지 않아, 논의가 다시 되돌아가는 것을 반복하는 문제를 겪었다.
다행히, 그러한 문제를 겪으면서 나는 하나의 안건이 끝날 때마다, 팀원들이 해당 안건을 어떤 내용으로 이해했는지를 묻는 방식으로 이를 해결했다. 조금이나마 논의 속도가 빨라지는 데 기여했으리라 생각한다. 하지만 팀원들 한 명 한 명에게 안건에 대한 이해를 물어보는 것은 그 자체로도 시간이 많이 들고, 팀원도 썩 기분이 좋을 방식은 아니었을 것이란 생각이 든다.
그래서 다음부터는 논의를 진행하는 데 있어서 PPT, Figma, 텍스트 등 다양한 시각적 방식을 적극적으로 활용해서 최대한 논의 내용에 대한 이해 차이를 사전에 줄여야겠다고 생각 중이다.
2-4) 팀의 다음 스텝을 먼저 고민하자.
프로젝트의 방향성을 정하는 것만으로도 모든 팀원들이 진이 빠졌다. 팀원들이 지치지 않고 나아가기 위해서, 리더가 해야할 일 중 하나는 팀의 방향과 목표, 그리고 목표까지 남은 진행 상황을 팀원들에게 공유하는 것이라 생각한다. 리더가 자신 또한 지친다고 팀의 현재 위치와 다음 스텝을 고민하지 않는다면, 팀은 그야말로 망망대해에 표류하는 배의 처지에 놓일 수밖에 없기 때문이다.
그래서 나는 현재까지는 매일 아침에 팀이 오늘 해야할 to do list를 공유하고, 팀원들의 의견을 물어, to do list를 추가하거나 줄였다. 그리고 저녁에는 오늘 클리어한 과제들을 공유하는 방식으로 팀원들에게 팀의 방향과 속도를 계속 인지시키도록 노력했다.
앞으로는 이처럼 하루 단위의 스케줄 관리를 넘어서, 프로젝트 전체 단위, 주 단위, 하루 단위로 팀의 방향과 속도를 고민해나갈 것이다. 그래야 팀의 현재 상황을 즉각적으로 파악해서 언제 다가올 지 모르는 미지의 문제에 유연하게 대처할 수 있을 것이기 때문이다.
회고 요약
사실 이번주는 개발자로서 보다 프로젝트 리더로서 반성하고 배우고 느낀 점이 많은 것 같다. 기획을 하는 종종, 팀원들이 나말고 다른 사람을 팀 리더로 맞이하고 싶진 않았을까? 하는 생각이 들기도 한다. 이런 생각들을 바탕으로, 팀원들이 좀 더 의지할 수 있고, 믿을 수 있는 리더가 되기 위해 노력해야곘다.
