3주간의 팀 프로젝트를 마치며
- 팀 프로젝트 기간: 2024-10-24 ~ 2024-11-20
- Youtube 동영상: 협업 관련 인터뷰
1. 회고
의견 조율에 대한 고민
개발자를 지망하는 우리가 한 팀이 되어 프로젝트를 진행할 때 직면한 문제는 우리 앞의 수많은 사안이 모두 논의 후 결정이 필요했다는 것이다. 예를 들어, 특정 기능을 세부적인 기능들로 나눌 때 어디까지를 기본 기능으로 구현하고 어디까지를 추가 기능 개념으로 백로그에 넣어둘지부터 시작해서 기능의 우선순위 정하기, 변수명 규칙, 하물며 커밋 메시지 title의 type을 적을 때 첫 글자를 대문자로 할지 소문자로 할지까지 말이다.
혼자 고민 후 결정해서 진행하다가 뭔가 마음에 들지 않으면 다시 롤백(Rollback)하는 솔로 프로젝트와는 다르게 팀 프로젝트는 사소한 모든 것들이 팀원 모두의 의견을 거쳐 찬/반의 형태로 결정이 된다. 개발 경력이 더 많은 팀장 또는 리더가 있어서 더 좋고 덜 좋은 것(혹은 나쁜 것)에 대한 뚜렷한 기준을 가지고 방향 설정을 해주는 것이 아닌, 모두가 동등한 위치에서 합의점을 찾아야 하는 상황이었기 때문이다. 운 좋게 모두가 동의하거나 동의하지 않는 아주 기본적이거나 원론적인 사안에 대해서는 빠르게 결정을 짓고 넘어가지만, 각자의 배경과 각자가 생각하는 프로젝트의 컨셉 및 방향에 따라 달라질 수 있는 내용에 대해서는 예상치 못한 시간이 결론을 내리는 데까지 걸리기도 했다. 모두가 프로젝트에 대해서 진심이었기 때문이 아닐까?
인원이 세 명이라서 의사 결정이 조금은 수월한 점도 있었다. 홀수 인원의 장점이라고 할까. 어떤 사안을 결정하는 데 있어서 정해둔 시간을 초과하였음에도 아직 결정되지 않았을 때는 현실적으로 최선의 의사결정 방법인 다수결의 원칙(팀 내 다수의 의견을 전체 의사로 보고 결정)을 도입할 수 있었기 때문이다. 물론, 해당 방법으로 인해 특정 소수의 의견이 반복적으로 묵살되는 경우가 있을 수 있지만, 최대한의 합의점을 찾으려고 노력했음에도 이견이 좁혀지지 않는 경우에 최후의 수단으로 사용했다.
기획 단계에서 이견 조율에 대해서 깊게 고찰하게 된 계기가 있었다. 어떤 사안에 대해서 내가 옳다고 생각하는 것을 다른 두 명의 팀원이 반대할 때, 나는 어느 정도의 선까지 내 의견을 어필해야 맞는 것인지에 대한 깊은 고민이었다. 구체적으로 설명하자면 그것은 Asynchronous Data Fetching에 대한 내용이었는데, 두 가지 To do의 우선순위에 있어서 나는 크롤링(crawling) 및 스크래핑(scraping) 자동화(cron job)보다도 클라이언트 단에서 Data fetching 시, isLoading(isPending) 상태 값을 활용한 UI/UX 대응이 더 중요하고 이는 de facto 와 다름 없다고 주장했었고 다른 두 명의 팀원은 반대의 입장이었다.
당시에 React Query를 사용한다면 분명 isPending 상태 값으로 간단하게 fallback 컴포넌트를 렌더링할 수도 있고, 클라이언트 단에서 서버 상태로 fetching이 끝난 idle 상태인지도 알 수 있지 않겠느냐는 생각에서 비롯된 주장을 펼쳤다. 또한, 크롤링과 스크래핑에 대한 자동화는 로드가 훨씬 더 많이 드는 작업이라고 생각했다. 이와 같이 모두 각자의 주장에는 각자의 기준에 따른 이유가 있고, 절대적인 옳고 그름을 떠나서 내가 생각하는 바에 대한 주장을 어느 선까지 하고, 어느 시점에서 합의를 보고 다수결에 수긍하고 갈 것인가에 대한 고민이 있었다.
이에 대한 해결책으로 내가 제시한 것은 당연한 이야기지만 기능에 대해 기술적인 논의를 하거나 PR(Pull Request)의 코드 리뷰를 할 때 최소한의 근거, 즉 레퍼런스를 가지고 의견을 내자는 것이었다. 혹은, 기술적인 논의를 하기에 앞서 해당 사안(matter)에 대한 모두의 이해도(sync)를 맞추기 위해, 5 ~ 10분의 시간을 들이더라도 해당 사안에 대한 기술이 무엇인지, 어떤 식으로 쓰는 것이 보편적인지 등은 빠르게 서칭해보자고 했다. 모두가 필요한 기술 스택에 대해서 아는 것이 아니었고 한 명만 안다던지 두 명만 안다던지 할 수 있기 때문이었다. 해당 방법이 이견 조율에 리소스를 덜 소모하는 방법이라고 생각했다.
실제로 우리 팀은 코드 리뷰 시 코멘트를 위해 의견을 뒷받침할 레퍼런스를 공식 문서에서 찾았다. 또한, 정기 미팅에서 더 나은 방법을 제시하기 위해 구체적인 예시가 나와 있거나 공감이 많은 블로그 글을 준비하기도 하고, 예시 코드를 준비하기도 하였다. 찾는 과정에서 내가 생각한 것이 잘못되었다는 것을 알기도 하고, 추가적인 사실을 더 알아가기도 했다. 누군가는 개발할 시간을 소모하는 불필요한 작업이라고 생각할 수 있으나, 의견을 뒷받침할 근거를 찾는 과정은 소모한 시간에 비해 굉장히 가성비 좋은 필수적인 effort였다고 생각한다.
팀플 중에 드는 개인적인 생각들에 대한 기록: 팀 프로젝트 때만 겪을 수 있는 귀한 경험이지 않은가
메타인지
메타인지란? 자기 생각을 판단하는 능력이다. 한마디로, 생각에 대해 생각하는 것이라고 표현할 수 있는데, 학습의 측면에서는 자기 인식(Self-awareness)을 통해 내가 무엇을 알고 있는지, 무엇을 모르는지를 이해하는 능력이라고 할 수 있다. 내가 어떤 개념을 아는 것처럼 느끼는 것인지 아니면 정말 알고 있는 것인지를 구분하게 한다.
아이러니하게도 팀 프로젝트였지만, 나 자신에 대해서 많이 배우고 되돌아볼 수 있는 계기가 되었다. 내가 어떤 주장을 펼칠 때나 알고 있는 개념에 관해서 상대방에게 설명할 때, 내가 정확히 알고 있다면 최소한 어느 정도는 상대방을 이해시킬 수 있어야 한다고 생각한다. 하지만, 팀 프로젝트를 하면서 내가 안다라고 생각한 것들을 팀원에게 설명하거나, 왜 그렇게 생각하나요? 라는 질문에 답변할 때, 내가 이 개념을 정말 알고 있는 것이 아니구나라고 느낀 적이 빈번히 있었다. 덕분에 시간이 지나며 금이 가버린 개념들을 다시 단단히 다질 수 있었다.
또한, 내가 어떤 면에서 부족함이 있고, 내가 잘하는 것은 무엇이고, 어떤 부분에서 다른 사람에게 쉽게 설득이 되는지를 알게 되었다. 회의록을 철저하고 꼼꼼하게 작성하는 팀원을 보며, 힘든 와중에도 본인만의 방식으로 감정을 잘 컨트롤하는 또 다른 팀원을 보며, 내가 부족한 것을 배우고 흡수하고자 하였다. 내가 어떤 상황에서 잘 설득이 되는지를 보고 나도 그런 방법으로 주장을 하려고 했다. 그 외에도, 세부 기능들을 기획할 때도 어느 정도는 기술적인 측면에서의 구현 가능성을 proof 하며 넘어가고자 하는 나를 발견할 수 있었다. 그리고 나는 중요도가 높은 것들이 완벽히 끝나지 않은 상황에서 비교적 중요도가 낮은 사안들을 논의할 때, 결과론적으로 어떤 것을 선택해도 플러스(+)는 없고, 그렇다고 마이너스(-)가 되지 않는 이상 이래도 저래도 상관없다는 스탠스를 취했다.
내가 어떤 개념에 대해서 완벽히 알고 있는지에 대해서 본인 스스로 테스트하고 싶다면 누군가에게 그것을 설명해 보라고 권하고 싶다. 설명하는 도중에 스스로 느낄 것이다. 내가 정말 알고 있구나. 혹은 내가 안다고 착각했구나.
2. 기술 스택
Tech Stack - Full Stack
3. 추후 업데이트 예정
겪은 기술적 문제
아쉬운 점
Reference
혹시 틀린 내용이 있다면 댓글 기능이 개발되기 전까지는 메일로 제보 부탁드립니다.