케어링 노트 팀 회고-1: 개발팀에 생긴 문제와 변화

케어링노트 프로젝트가 중반에 왔다. 우리는 디자인의 30%정도를 달성하였으며, 원래 기한의 4주를 딜레이 했다. (대개 풀타임 프로젝트가 아닌) 사이드 프로젝트에서는 기한의 딜레이가 흔히 일어나는 것으로 생각한다. 그저 2주가 지나면, 혹은 조금 더 여유가 주어지면 되지 않을까라고 생각하기 쉽다. 그러나, 사실은 지금까지의 느렸던 진행이 시간이 더 주어진다고 특별히 빨라지는 경우는 거의 없다. 나는 1주 지연에서부터 변화를 준비해왔고, 3주가 지연되었을 때 개발팀의 구조를 바꾸었다. 이 글에서는 왜 그러한 변화를 시도했는지, 어떻게 변화를 만들었는지에 대해서 서술한다.

프로젝트 초기 상황

우리 프로젝트는 초기 8명으로 이루어져 있었다. 기획/디자인 3명(팀장 포함)과 개발자 4명(백엔드 2명, 프론트엔드 2명), 의료 자문 1명으로 구성됐다. 특징적인 것은 의료/법 자문위원의 존재인데 개인정보에 관한 보안을 준수하는 것이 굉장히 중요한 프로젝트이기 때문이다. 그래서 의사 1명을 의료 자문과 법률 자문으로 했다. 프로젝트 시작 후 4주 동안, 프로젝트의 진행사항은 다음과 같았다.

• 2주차: 리서치
• 3주차: 릴리즈 2까지의 디자인 시스템 초안, 프로젝트 셋업
• 4주차: 인프라 및 배포 시스템

기술 스택은 다음과 같았다.

• 백엔드 Springboot, Spring JPA, Spring Security
• 프론트엔드 Vite + React, Tailwind CSS
• 배포 Kubernetes, Git Action, Ingress nginx

이 일정이 완료 되었을 때, 우리는 릴리즈 1까지 4주의 시간을 가지고 있었다. 이 문장을 보자마자 누군가는 느끼겠지만, 첫 릴리즈에 4주?라고 생각할 수도 있겠다. 그러나 우리는 딜레이를 상정하고 기한을 먼저 해두기로 했다.

Plus

• 디자이너들이 디자인 시스템 확립에 많은 노력을 기울였다. (색상표, 폰트, 컴포넌트화)
• 인프라와 배포 시스템을 빠르게 갖추었다. (깃 액션 기반 자동 배포)
• 많은 디자인이 이루어져 피드백 후 개발이 가능한 일정이 됐다.

Minus

• 프론트엔드가 프로젝트 셋업(디자인이 주어지기 전 준비)에 들인 노력이 부족했다.
• 디자인이 한꺼번에 많이 주어져 개발자들에게 부담이 됐다.
• 백엔드와 프론트엔드 개발자들이 각각 쪼개져서 활동했다.
• 개발의 매니징이 준비되지 않았다.

1차 릴리즈 기한

1차 릴리즈 기한의 첫 2주는 각 팀에서 평행하게 업무가 진행되었다.

• 기획/디자인: 디자인 피드백 반영, 2-3차 릴리즈 준비
• 백엔드: API 준비, DB 테이블 세팅, 데이터 크롤링
• 프론트엔드: 레이아웃, 라우팅, 컴포넌트

컴포넌트는 총 30개 정도이고, 첫 2주동안 완성된 컴포넌트 개수는 8개 정도였다. 그리고 이후는 컴포넌트 개발에 피로감과 일정상의 딜레이를 고려하여 페이지 개발과 함께 평행하게 컴포넌트 개발을 하는 방향성으로 변경되었다. 난이도가 있는 컴포넌트가 약 5개 정도 있었기 때문에, 이는 이해할 만한 결정이었다. 그러나, 이러한 결정 과정이 코드 피드백이나 자세한 설명 없이 일정에 치여 프론트엔드 개발자의 말을 듣고 넘어갔다. 백엔드에서 또한 크게 빠르지는 않아서, API 준비 자체는 70%정도 되었고, 여러 가지 테스트나 배포 안정화 등에 조금 더 관심을 기울였다.

그리고 2주가 끝날 때 첫 번째 가시적인 문제가 드러났다. 프론트엔드 개발자 간에 의사소통이 잘 없었고, 서로 PR의 관리와 피드백이 이루어지지 않고 있었다. 결정적으로 있었던 사건은 프론트엔드 리뷰 후에 머지가 되고 배포 프로세스가 돌았는데, 배포에서 실패했다. 이후 나는 revert를 요청했고, revert에 3일이 걸렸다. 이 사건으로 의사소통 문제가 수면 위로 드러났고, 개발팀에 대한 첫 번째 피드백이 이루어졌다.

• Tailwind Css가 프론트엔드 모두에게 처음
• 프로젝트 셋업과정에서 의사소통이 없었음
• 컴포넌트 제작 시에 제로베이스 개발이 이뤄짐(샘플 코드나 라이브러리 참조 X)
• 디자인 시스템 반영 X

나는 이 때부터 프론트엔드에 개입하게 되었고, 그 후 1주간 작업을 했다.

1. tailwind config color set 적용
2. shadcn/ui 도입
3. svg import

이와 함께 다른 백엔드 개발자가 개발 PM을 맡게 되었다.

그 후 2주는 페이지 개발에 전념했으나, 1차 릴리즈 기한이 다가왔을 때 프론트엔드는 UI의 절반 정도를 준비했다. API 연결은 이루어지지 않았고, 우리는 3주 연장을 우선 공식화했다. 디자인은 더 단순하고 통합된 디자인으로 프론트엔드의 짐을 덜어주려고 노력했다. 개발팀이 기한을 맞추기 위해서 조직적으로 필요한 해결책은 다음 세 가지였다.

1. 프론트엔드 개발자들 간의 의사소통
2. AI, 라이브러리 기반 생산성 향상 추진
3. 리액트-Tailwind CSS의 이해 향상

2번은 단기적으로 가장 빠르게 해결할 수 있는 부분이지만, 1번과 3번은 쉽게 해결되지 않는 문제이다. PM은 백엔드 개발자이기 때문에 코드적으로 간섭하기는 어려웠고, 결국 대부분의 의사소통 필요 지점은 현재 작업이 겹치는 부분에서 만들어지기 때문이다. 의사소통이 되어야 이해 향상을 좇을 수 있는데, 서로 코드를 피드백하고 더 나은 지점을 좇을 동기가 생기기 때문이다.

내가 작업한 1주일 뒤, 전체적인 레포의 상태는 개선되었으나, 의사소통 측면에서는 전혀 나아지지 않았다. 프론트엔드 두 사람은 서로 간에 얘기를 하고 개선하기보다 나와 소통하기 시작했다. 구조 상 팀장-PM-나-프론트엔드 두 사람이 되어 의사소통 구조에서 마지막까지의 거리가 3이 되었다.

이제 우리는 다시 한 번 총 4주를 가지고 있었고, 다시 페이지를 나아가야 했다.(못해도 API와의 연계가 2주는 필요하기 때문이다) 크리스마스, 신년 등이 겹치며 작업 속도는 더 느려졌고, 한 사람은 스트레스를 받으며 억지로 걸었고, 한 사람은 숨었다. 나는 새로운 사람을 찾고 있었다. 그렇게 우리는 새해를 맞이했다.

Plus

• 문제가 있음을 인정하고 수정 전략을 만들었다.
  • 팀장은 개발팀의 개개인의 의견을 더 자세하게 묻고 상황 파악에 집중했다.
  • 기획/디자인에서는 프론트엔드의 짐을 줄이기 위해 범위를 좁히고, 디자인 통합을 시도했다.
  • 개발팀에서는 개발의 관리자를 수립했다.
  • 프론트엔드에서는 문제사항을 받아들이고, 의견을 받아 이를 바탕으로 작업방식을 변경했다.
• 기한의 수정을 빠르게 했다.
• 개개인에 대한 책임전가를 하지 않았다.

Minus

• 개인에 대해 책임을 묻지 않았다.
• 현실적인 기한에 대해서 제대로 계산되지 않았다. (현재까지의 퍼포먼스를 바탕으로)
• 개발 PM이 코드적으로 개입하지 못 했다.
• 개인 간의 팀워크적인 면의 해결을 하지 못 했다.

팀의 변화

새해를 맞이함과 동시에, 나는 새로운 프로그래머를 섭외했다. 스타트업에서 프론트엔드 메인으로 풀 스택으로 개발하는 개발자를 데려왔는데, 이 때 중요하게 본 부분은 두 가지였다.

1. 누구와 대화하던 간에 자신의 의견을 명확하게 밝히는 사람.
2. 기술적으로 확실하게 기준을 잡고 리딩이 가능한 사람.

동시에 개발 PM을 프론트엔드에 참여하게 만들었다. 일을 할 사람을 늘려 생산성을 높이는 목표가 메인이지만, 궁극적으로는 프론트엔드 두 명의 직접적인 연결고리의 크기를 약화시키고 프론트엔드라는 일에서의 거미줄을 크게 늘려 누구와 소통하더라도 괜찮은 구조를 만들도록 했다. 이렇게 하면, 일부 개인간에 소통이 어렵더라도 전체적으로는 5명이 의사소통이 가능하면 앞으로 나아갈 수 있게 되었다.

이와 함께, 숨어버린 개발자를 수면 위로 올리는 작업이 필요했다. 의사소통에서 고립되었고 작업이 미진했기 때문에, 신뢰를 잃어가는 상황에서 다시 팀에 합류 시키기 위해서 다음과 같은 대화를 나눴다.

• 현재까지의 퍼포먼스 평가 (맨먼스 0.2)
• 왜 퍼포먼스가 나오지 않았는 가에 대한 고찰
• 앞으로 기대하는 퍼포먼스 평가 (맨먼스 0.4)
• 조직적으로 해결되거나 해결할 문제들
• 이 프로젝트에서 얻을 수 있는 것 (포트폴리오)

그리고 팀에는 개발팀의 명확한 퍼포먼스 지표를 얘기하고, 목표로 하는 속도와 개개인의 평가를 전달했다. 이로써, 과한 기대나 부담을 막고, 현재와 목표 대비 얼만큼의 성능을 내었는가를 피드백할 수 있는 구조로 바꾸고자 했다.

현재까지의 결론

프로젝트를 하면서 구멍이 없는 완벽한 프로젝트를 했던 경험은 굉장히 드물었던 것 같다. 다만, 성공에 있어서 중요한 건 1주일 전보다 1주일 후가 더 생산성이 잘 나오고, 조금씩 더 속도가 높아져야 한다는 부분이다. 기술적인 면에서는 대부분이 시간의 흐름에 따라 조금씩이라도 능력이 상승한다. 그러나, 의사소통 적인 면에서는 인간성이나 스트레스 등의 다양한 요소들이 영향을 미치고, 이를 해결해나가는 것은 때때로 훨씬 까다로울 때가 있다. 특히나, 이번 경험을 통해 하나 더 확실해진 점은, 커뮤니케이션은 저절로 해결되지는 않는다는 사실이다. 지금 이 변화가 팀에 긍정적으로 영향을 미치길 바라며, 이 글을 마친다.