"우아한테크코스에 입학한 지도 벌써 2달이 지났다." - 1레벨 회고

라고 말한지 4달이 지났다. 시간 정말 빠르다.

3레벨에선 팀원들과 보따리라는 앱을 출시했다. 이 프로젝트는 단순한 기술 성장을 넘어, 나를 오랫동안 괴롭혔던 완벽주의라는 고질병에서 벗어나게 해준 고마운 경험이었다.

이번 레벨은 함께 일하는 방법을 많이 시도해보고 배웠다. 매번 API를 완성하고 누군가의 작업을 하염없이 기다리는, 익숙한 분업에 지쳤다면 이 글이 좋은 인사이트가 될 수 있을 것 같다.

완벽주의라는 착각, 실체는 두려움

완벽주의라 표현했지만, 실은 '미완성인 내 결과물을 남에게 보여주는 것에 대한 두려움' 이 더 정확한 표현이다. 이런 두려움 때문에 내 코드엔 버그가 없어야 했고, 누군가 지적하면 "아, 그거 알고 있어요. 실수예요"라며 둘러댄 적도 있었다. 당연히 결과물을 내놓기까지의 시간은 하염없이 길어졌다.

완벽한 주제는 없었다

(위) 주제 어필의 흔적들

두 달 넘게 할 프로젝트이니 주제부터 완벽해야 했다. 사용자도 많아야 할 것 같았다. 내 아이디어가 채택되지 않을까 봐 발표 자료 준비에 엄청나게 공을 들였다.

하지만 팀원들의 생각은 저마다 조금씩 달랐다. 모두의 의견을 반영하다 보니 "이런 서비스를 만들 수는 있나?"라는 근본적인 의문이 들었다. 더군다나 우아한테크코스는 학습을 위한 환경인 만큼, 파트별 기술 도전 욕구도 무시할 수 없었기에 주제 선정에는 꽤 많은 시간이 걸렸다.

결국 깨달았다. 완벽한 주제란 없다.

우아한테크코스라는 공간에서 만큼은 각자 원하는 방향을 솔직하게 공유하고 합의점을 찾는 과정이 더 중요하다고 느꼈다. 그렇게 '보따리'가 탄생했다. 만약 그때도 완벽한 주제를 찾아 헤맸다면, 우린 아직도 기획만 하고 있었을 거다.

분업과 협업 사이

요약: 4인 페어 → 2인 페어 → API 협업

프로젝트 시작 전, 내가 팀에 제안 하나를 던졌다.

"우리, 4인 짝 프로그래밍으로 시작하면 어떨까?"

내가 제시한 이유는 아래와 같다.

- 이전 레벨에서 경험한 짝 프로그래밍의 연장선, 이게 진짜 협업 아닐까?
- '너는 게시판, 나는 로그인' 이건 협업이 아니라 분업이다.
- 서로 다른 코드 컨벤션을 통일해서 일관성 있는 코드를 만들자.

팀원 모두가 동의했고, 우린 1~2주간 4명이 한 화면을 보며 코드를 작성했다.
처음엔 한 화면을 보며 같이 코드를 짜는 게 어색했지만, 금방 웃으면서 의견을 주고받는 게 자연스러워졌다.

어느 날 코치와 면담 중 질문을 받았다.

"현재 작업은 어떻게 나누어 진행하고 있나요?"

우리는 자신만만하게 답했다.

"저희는 이런 이유로 4인 짝 프로그래밍을 하고 있습니다."

하지만 돌아온 코치의 반응은 우려였다.

"그러면 작업 속도가 더디지 않나요?"

순간 모두가 멈칫하며 서로를 바라봤다... 그전까지는 전혀 문제라고 생각지 못했다. 4명이 같은 맥락을 공유하고 일관성 있는 코드를 작성하는 것이 멋지고 이상적인 협업이라 믿었다. 하지만 객관적인 결과물을 보니, 진행 속도가 생각보다 느리다는 것을 깨달았다.

그러면 작업을 나눠서 진행해야 할 것 같은데, 처음에는 의문이 먼저 들었다. "작업을 나누면 순서 의존성 문제는 어떻게 해결하지?"

예를 들어, 게시판 기능(A)이 완전히 완성되어야만 댓글이나 신고 기능(B)을 개발할 수 있다고 생각했다. 만약 두 짝이 A와 B를 동시에 작업하다 나중에 합칠 때 코드가 엉키거나 충돌이 나면, 그걸 해결하는 데 시간을 뺏겨 오히려 더 비효율적일 거라고 예상했기 때문이다.
(돌아보면 충돌이 나거나 코드가 엉망이 되는 것을 두려워했던 것 같다. 고치면 되는데..)

하지만 이건 우리의 착각이었다. B 기능을 개발하는 데 필요한 것은 완성된 A 기능 전체가 아니었다.

단지 '게시물이 존재한다'는 약속, 즉 최소한의 데이터 구조만 있어도 기능을 구현할 수 있고, 충돌 역시 두려워할 대상이 아니었다.

이 깨달음을 바탕으로 우리는 2:2 짝으로 나뉘고, 코드 리뷰를 활성화하기로 했다. 서로 다른 작업을 하니, 코드 리뷰를 통한 동기화가 필수적이라 느꼈기 때문이다. 변화는 성공적이었다. 작업 속도는 눈에 띄게 빨라졌고, 코드 리뷰를 통해 배우는 점도 많아졌다. 이제 속도와 협업, 두 마리 토끼를 다 잡았다고 생각했다.

물론 모든 작업을 그렇게 진행하지 않았다. 엔티티 설계처럼 충돌 가능성이 매우 높고 전체 구조에 영향을 미치는 작업은 다 함께 논의했고, 이후 구현 작업부터 병렬적으로 처리하여 유연하게 진행했다.

여전히 분업이었다.

하지만 진짜 문제는 다른 곳에 있었다. 어느 날 받은 피드백이 정곡을 찔렀다.

"혹시 백엔드는 API 다 만들고, 앱은 화면 다 만든 다음에 합치면서 서로 고생하고 있지 않나요?"

정확했다. 백엔드는 RESTful한 URI 구조를 위해 고민하는데, 앱에서는 "그냥 API 하나로 처리해주면 안 돼요?" 또는 "이 API에 이것도 추가해주세요." 처럼 부딪히는 경험이 꽤 있었다. 각자 파트에서 최선이라 생각한 결과물이, 합치는 과정에서 수많은 수정 요청과 불필요한 비용을 발생시켰다.

"왜 일을 따로 하나요? 처음부터 같이 만들면 고칠 일이 없지 않을까요?"

지금까지는 팀이었지만 파트라는 이름으로 경계가 뚜렷했고, 서로의 과정보다는 연동 시점의 결과물만을 중시했다. 그 결과, 실제 연동 단계에 들어서야 서로의 생각 차이를 발견하게 되었고, 충돌과 수정이 반복되곤 했다.

다른 협업 방법 도입

문제를 개선하기 위해 다른 협업 방식을 고민했다.

1. 백엔드 + 안드로이드 짝을 이뤄 하나의 기능을 완성한다.

• 하나의 이슈(기능)를 서로 다른 파트원끼리 짝을 이룬다.
• 기능 구현에 대한 결정권은 해당 짝이 갖는다.
• 작업이 끝나면 각 파트 내에서 코드 리뷰를 진행한다.

처음엔 다른 파트와 짝을 맺으니 낯설었지만, 내가 만든 API가 바로 눈앞 화면에 연결되는 걸 보며 성취감을 함께 느낄 수 있었다.

(위) 서로 다른 파트 협업 이슈

화면이나 기능 단위로 작업을 나누어 할당하고, 내부적으로 작게 쪼개어 기능을 구현했다.

2. 서로의 작업이 끝나길 기다리지 않는다.

• 서로의 로컬 환경을 동일하게 구성한다.
• 백엔드 코드가 코드 리뷰를 기다리고 있을 때, 안드로이드 팀원은 해당 브랜치를 가져와 로컬에서 작업한다.
• 안드로이드 기기가 없는 팀원은 단순히 기다리는 것이 아니라, 애뮬레이터로 앱을 사용한다.

개발 서버에만 의존하지 않아도 된다는 점은 충분히 매력적이었다. 서버에 문제가 있거나 반영이 지연될 때도, 기다림 대신 그 시간을 적극적으로 활용할 수 있었기 때문이다.

3. 코드 충돌(Conflict)을 두려워하지 않는다.

• "충돌 나면 어떡하지?" 대신 "일단 만들고, 충돌 나면 고치자" 는 마인드를 장착했다.

자연스럽게 작업을 더 작게 나누는 연습이 된 것 같다.

도입 후 결과

(위) 서로 다른 파트 협업 도입 시점 전후의 완료 PR 개수 변화 (각 1개월)

PR의 크기는 서로 다르겠지만, 이 지표는 우리 팀이 훨씬 민첩해졌음을 명확히 보여준다.

잦은 충돌은 오히려 빠른 해결 능력을 길러주었던 것 같다. 추가로 자동 테스트 및 배포 파이프라인이 잘 구축되어 있어서 더 쉽게 충돌을 확인하거나 해결할 수 있었다.

민첩함의 그림자, 작업 공유의 중요성

앞서 소개한 협업 방식은 팀의 생산성을 폭발적으로 높였지만, 지식의 사일로화(Silo)를 일으켰다.

팀원 각자가 맡은 기능에 깊게 몰입하다 보니, 다른 팀원이 진행한 작업의 세부 내용을 놓치는 일이 자연스럽게 발생한다. 예를 들어, A가 팀의 편의를 위해 멋진 배포 자동화 파이프라인을 구축했다. B는 그저 'PR 머지만 하면 배포가 되니 편하다'고 생각하며 사용할 뿐, 그 내부 원리나 구조, 문제가 생겼을 때의 대처법을 알기 어렵다.

단기적으로는 문제가 없다. 오히려 각자 작업에 집중하니 효율적이다. 하지만 이런 나만 아는 지식이 쌓이면 팀의 '버스 팩터(Bus Factor)'가 극도로 낮아진다.

🚌 버스 팩터 (Bus Factor) 란?

팀의 핵심 멤버가 갑자기 버스에 치여 사라졌을 때(...) 팀원 중 예측 불가능한 이유로 업무 불능 상태가 되었을 때, 특정 업무가 중단되기까지 필요한 최소 인원수를 나타내는 지표입니다. 이 지수는 팀의 지식 집중도와 업무 위험도를 표현하며, 지수가 낮으면 소수의 인원에 대한 의존도가 높아 프로젝트 진행에 취약성을 가집니다.

N명이 팀을 구성한다 라고 하면 1과 N사이의 값을 갖게 되는데, 만약 특정 업무를 진행하는데에 있어서 팀원들중 1명만이 맥락을 이해하고 있다면, 해당 1명이 사라지면 업무가 진행 될 수 없기 때문에, 이 경우 이 팀은 (이 업무는) 1이라는 버스 지수 값을 갖습니다. 출처

만약 파이프라인을 만들었던 팀원이 휴가를 가거나 갑자기 아프기라도 하면 어떻게 될까? 배포 과정에 문제가 생겼을 때, 남은 팀원들은 그가 돌아올 때까지 기다리거나, 수많은 설정 파일과 코드를 역으로 파헤치며 귀한 시간을 낭비해야 한다. 우리가 애써 얻어낸 민첩함이 한순간에 무너진다고 생각한다.

어떻게 개선할까?

우리는 이 문제를 해결하기 위해 GitHub Wiki와 Notion을 단순한 기록 보관소가 아닌, 살아있는 지식 베이스로 활용할 수 있게 노력했다.

결과가 아닌 '과정'을 기록

단순히 '무엇을 만들었다'가 아닌, '왜 이런 기술적 결정을 했는지', '어떤 문제를 해결하려 했는지' 와 같은 의사결정 과정을 기록하자.

예를 들어, 특정 기술을 선택한 이유, API 설계 시 고려했던 점, 지금의 아키텍처가 나오기까지의 고민 등을 가볍게라도 남겨 히스토리를 공유하자.

• 기술 스택 및 버전 선택 이유
• 모니터링 도구 선택 이유
• 운영 서버 인프라 아키텍처
• 팀 보따리 변경 사항 실시간 반영 구현 검토

'암묵지'를 '형식지'로 바꾸다

작업 내용 반영 방법, 배포 자동화 파이프라인, 로그 전략 및 로그 파일 저장 위치 관련 설정 등 특정 담당자만 알고 있던 '암묵적인 지식(암묵지)'을 누구나 따라 할 수 있는 '형식적인 문서(형식지)'로 만들자.

• 개발 서버 작업 내용 반영 방법
• 개발 서버 배포 자동화 파이프라인
• 로그 전략 및 로그 파일 저장 위치 관련 설정

지금 생각해보면 자주 발생하는 에러에 대한 트러블슈팅 가이드도 있다면 팀의 시간을 크게 절약해줄 것 같다.

문서를 '살아있게' 유지하다

어려운 규칙이다.

문서는 한 번 만들고 끝이 아니라 Pull Request를 올릴 때 관련 문서 링크를 첨부하거나, 기능 변경 시 관련 문서를 함께 수정해야 한다. 문서가 방치되는 것을 막고, 항상 최신 상태를 유지할 수 있어야 한다고 생각한다.

작업 공유는 단순히 인수인계를 위한 보험이 아니라고 느꼈다. 팀 전체의 기술적 체력을 함께 키우고, 누가 없어도 흔들리지 않는 회복탄력성 있는 팀을 만드는 중요한 과정이라고 생각한다.

마무리

• 완벽주의는 두려움의 다른 이름이었다. 미완성이라도 드러내고 피드백을 받아야 성장할 수 있었다.
• 협업은 단순한 분업이 아니다. 결과물이 아니라 과정을 공유해야 불필요한 충돌을 줄이고 진짜 협업이 된다.
• 속도와 협업은 대립하지 않는다. 방식을 바꾸니 더 빨라졌고, 더 많이 배울 수 있었다.
• 민첩함의 뒷면엔 지식 공유가 필요하다. 사일로를 깨고 과정을 기록해야 팀 전체의 체력이 유지된다.
• 정답은 없지만, 더 나은 방식을 찾아가는 과정 자체가 성장이었다.

돌이켜보면 최근 블로그를 쓰지 못했던 이유도 완벽주의 때문이었다. 더 좋은 주제를 찾아야 한다는 강박이 글쓰기 자체를 막아버렸다. 항상 정답은 없겠지만, 현재 상황에서 더 나은 협업 방식을 찾는 과정에서 많이 배웠다. 이 모든 여정을 함께한 보따리 팀원들에게 감사를 전한다.

여러분은 어떤 협업 방식을 시도하고 계신가요?