-
Notifications
You must be signed in to change notification settings - Fork 2
협업 문화
우리 팀의 제1원칙은 '솔직하게 말하기'입니다. 우리는 좋은 점과 개선점 모두를 그 자리에서 터놓고 이야기하는 것이 오해를 줄이고 문제를 신속하게 해결하는 지름길이라고 믿었습니다. 이러한 솔직한 소통은 모든 팀원이 프로젝트에 깊은 애정을 가지게 만드는 원동력이 되었습니다.
우리 팀은 의문점이 생기면 즉시 Slack의 허들 기능을 활용해 논의하는 문화를 정착시켰습니다. 이러한 적극적인 토론 문화는 매 회고에서 'KEEP' 항목으로 꾸준히 언급될 만큼 팀의 핵심 강점이었습니다.
주차별 허들 현황을 보면 다음과 같습니다:
| 주차 | 오프라인 횟수 | 온라인 허들 횟수 | 온라인 허들 시간 |
|---|---|---|---|
| 1주차 | 3회 | 1회 | 2시간 9분 |
| 2주차 | 2회 | 2회 | 5시간 57분 |
| 3주차 | 2회 | 8회 | 10시간 53분 |
| 4주차 | 2회 | 4회 | 14시간 1분 |
| 5주차 | 2회 | 5회 | 14시간 24분 |
| 총계 | 11회 | 20회 | 47시간 24분 |
오프라인 활동을 제외하고, 온라인 활동 시에 진행한 주차별 허들 시간을 합산하면 47시간 24분입니다. 각 주차가 진행될수록 프로젝트를 위한 순수 허들 시간이 증가하는 것을 볼 수 있습니다.
특히 프로젝트 후반부로 갈수록 허들 시간이 증가했으며, 이는 복잡한 문제 해결과 품질 향상을 위한 심도 있는 논의가 필요했기 때문입니다. 특히 4주차와 5주차에는 각각 주당 약 14시간의 허들이 진행되어, 온라인 하루 평균 7시간 이상을 함께 소통하며 개발했습니다.
백엔드 개발을 시작하면서, 우리는 '효율성'을 위해 업무를 분담했습니다. questions, replies, users 모듈을 각자 맡아 개발하면 더 빠르게 진행될 것이라 판단했기 때문입니다. 첫 3주 동안은 전체 백엔드 이슈 9개 중 개발환경 설정 관련된 이슈 2개만 페어로 진행했습니다.
하지만 개별 개발 방식은 예상치 못한 문제들을 야기했습니다:
- API 응답 형식이 제각각
- Repository Layer의 중복 함수 발생
- 검증 방식의 일관성 부족 (Guard와 Service Layer의 검증 혼재)
이러한 문제들을 해결하기 위해 4주차부터 페어 프로그래밍으로 전환했습니다. 백엔드 백로그 전부를 세 명이 다 함께 페어프로그래밍을 통해 해결하였습니다.
특히 실시간 기능을 위해 socket.io와 API를 하이브리드로 개발해야 했고, 멀티 호스트를 위한 복잡한 인증 체계로 인해 더욱 긴밀한 소통이 필요했습니다. 이러한 복잡한 기능들은 한 사람이 개발하기에는 위험 부담이 컸기 때문에 자연스럽게 페어 프로그래밍으로 해결해 나갔습니다.
이러한 전환은 단순히 개발 방식의 변경이 아닌, 코드 품질과 일관성 확보를 위한 필연적인 선택이었습니다. 실제로 페어프로그래밍 도입 후에는 다음과 같은 성과를 얻을 수 있었습니다:
- 응답 형식 통일
- Guards를 통한 검증 일관성 확보
- 코드 스타일 통일 (단수/복수 표현 등)
프로젝트 시작 시 명확한 MVP를 정의하는 데 집중했습니다. 6주 프로젝트 중 5주간의 계획을 세워, 마지막 주에는 피드백과 개선을 위한 시간을 확보했습니다.
"정말 이 기능이 필요한가?" 라는 질문을 끊임없이 던지며 핵심 가치에 집중했습니다. 4주 차에 첫 데모를 성공적으로 마쳤고, 5주 차에는 사용자 니즈를 반영한 실질적인 기능들을 구현할 수 있었습니다:
- 채팅 저장 및 조회 기능
- 호스트 권한 위임 기능
이러한 MVP 중심의 접근은 단순히 기능을 줄이는 것이 아닌, 사용자에게 진정한 가치를 전달하는 것에 집중하게 해주었습니다. 처음의 솔직한 약속에서 시작해, 끊임없는 소통과 협력, 그리고 명확한 목표 설정을 통해 우리는 의미 있는 결과물을 만들어낼 수 있었습니다.