우리는 코드처럼 문화도 리팩토링한다
Source: Woowahan Tech
팀 소개
커머스웹프론트개발팀(이하 “커머프팀”)은 배달의민족의 모든 커머스 서비스와 플랫폼은 물론, 백오피스부터 뒷단의 물류시스템에 이르기까지 웹 클라이언트 영역을 담당하는 거대한 규모의 팀입니다. 각기 다른 서비스를 담당하던 팀이 모여 하나의 큰 팀을 이루었고, 배달의민족이 꿈꾸는 커머스의 새로운 챕터를 열기 위한 힘찬 발걸음을 내디뎠습니다.
팀의 키를 잡은 초보 팀장은 얼마 못 가 혼자서는 이 거대한 조직의 복잡도를 감당해 내는 것이 불가능하다는 것을 깨닫게 됩니다. 하지만 다행히도 커머프팀에는 유능하고 팀을 돕고자 하는 팀원들이 많이 있었습니다. 팀을 이끄는 것은 사람이 아니라 함께 만들어가는 문화라는 것에 공감한 우리는, 이 문화를 코드처럼 지속적으로 리팩토링해나갈 “문화 리딩 그룹”을 꾸리게 됩니다.
오늘은 커머프팀과 문화 리딩 그룹이 함께 팀의 비효율을 걷어내고, 더 나은 구조를 만들기 위해 치열하게 고민했던 저희의 여정을 ‘조직 구조’, ‘소통 방식’, ‘기록 체계’ 관점에서 나누어 소개하고자 합니다. 이제 막 팀을 꾸려 문화를 마련하고자 하는 팀, 혹은 레거시 코드처럼 단단히 굳어버린 비효율 때문에 리팩토링이 절실한 팀에게 저희의 시행착오가 조금이라도 도움이 되기를 바라며 이야기를 시작합니다.
하나의 목표, 유연한 조직: 경계가 없는 파트
커머프팀은 기술적 깊이를 추구하는 기능 조직의 일원인 동시에, 각 비즈니스 과제를 책임지는 목적 조직의 성격도 함께 가지고 있습니다. 이 두 가지 역할을 조화롭게 수행하는 것이 팀의 중요한 특징입니다.
하지만 거의 20명 규모의 FE 개발자로만 구성된 개발팀이 비즈니스 과제와 티켓들을 효율적으로 처리하는 것은 언제나 난제였습니다. 팀원 모두가 한자리에 모여 업무 계획을 짜는 것은 집중력도 떨어지고, 물리적인 시간 소모도 너무 컸습니다. 단일 팀으로 운영하기엔 소통 비용이 한계에 다다른 것입니다. 결국 팀을 여러 파트로 나눠야 했지만, “어떻게” 나누느냐가 가장 큰 숙제였습니다.
비효율적인 분할 방식을 버리다
규모 있는 팀을 효율적으로 움직이기 위해 고민하던 당시, 우리 앞에는 “ONE COMMERCE”라는 거대한 목표가 놓여 있었습니다. 이는 배달의민족 내에 흩어져 있던 B마트, 배민스토어 등 다양한 커머스 서비스들을 기술적으로, 그리고 경험적으로 통합해내야 하는 수많은 과제들이 복잡하게 얽힌 미션이었습니다.
목표를 달성하기 위해 먼저 일반적인 조직 구성 방식을 검토했습니다. 하지만 곧 몇 가지 전통적인 분할 방식들이 오히려 우리가 목표로 하는 “통합”과 “유연성”을 저해한다는 사실을 발견했습니다.
- 프로젝트별 분할: 과제 발생 시기·규모가 불규칙해 특정 시기에 일부 파트에만 업무가 쏠리는 등 리소스 불균형이 심화되었습니다.
- 담당 페이지/퍼널 단위 분할: 퍼널(고객 단계별 경험) 기준으로 나누면 맡은 지면 외 영역에 대한 이해도가 낮아 전체 서비스 흐름을 파악하기 어렵습니다.
- 서비스 vs 백오피스 분할: 팀을 단순히 반으로 쪼개는 것에 불과해 상호 교류를 막고 시너지를 기대하기 어렵습니다.
이러한 문제들을 분석하며 우리는 한 가지 공통 원인을 찾았습니다. 바로 구성원을 특정 업무 도메인에 지나치게 강하게 묶어두고 있다는 점이었습니다. 특정 역할에 고정된 경직된 구조가 급변하는 비즈니스 상황과 통합 과제에 유연하게 대처하지 못하게 만드는 가장 큰 걸림돌이라고 판단했습니다.
이를 해결하기 위해 경계 없는 파트를 만들기로 했습니다. 특정 영역을 전담하는 칸막이를 없애고, 팀 전체가 “ONE COMMERCE”라는 하나의 목표를 향해 언제든 유연하게 움직일 수 있도록 도메인에 얽매이지 않는 구조를 도입했습니다.
R＆R을 넘어 R＆E로: 책임과 확장
경계 없는 파트가 제대로 작동하려면 기존의 R&R(Role & Responsibility) 방식을 개선해야 했습니다. 우리는 이를 대신할 R&E(Responsibility & Expandability) 라는 새로운 방향성을 정의했습니다.
“내 일의 경계를 두지 않고 문제를 끝까지 해결한다”는 우아한형제들의 일하는 원칙 Own It과 일맥상통합니다. 단순히 주어진 역할에 머무르지 않고, 책임을 넘어서 경계를 허물고 업무 영역을 확장해 서로를 돕는다는 의미입니다.
실제 업무 흐름은 다음과 같습니다.
- 업무 요청 → 팀장‑파트장 싱크업
- 3개 파트 중 적절한 파트에 배분
- 파트 내에서 경계 없는 협력을 통해 빈자리를 유동적으로 메움
조직의 목적과 부합한 성과
유연한 조직 구조는 “ONE COMMERCE” 목표를 현실로 만드는 핵심 열쇠가 되었습니다. 경계 없는 파트제는 모든 프로덕트를 아우르며 서비스 간 도메인 차이를 파악하고 실질적인 통합을 이뤄내는 데 매우 효과적이었습니다.
- B마트와 배민스토어의 상품 카드·상세 화면 통합, API 구조 맞추기 과정에서 강점이 드러났습니다.
- 서비스별 담당자가 따로 있었다면 레거시 코드 파악·스펙 조율에 상당한 시간이 소요됐을 것입니다.
- 경계 없는 파트를 통해 구성원 모두가 각 서비스의 도메인 맥락을 폭넓게 공유, 커머스 전체 관점에서 구조를 바라볼 수 있었습니다.
- 중복 로직을 과감히 제거하고 공통 모듈로 추상화해 코드베이스 일관성을 확보, 견고한 통합 아키텍처를 구축했습니다.
비즈니스 성과는 구성원 성장으로 이어졌습니다. 팀원들은 특정 서비스에 국한되지 않고 UX부터 어드민 데이터 흐름까지 전방위적인 도메인 지식을 동시에 학습했습니다. 이는 버스 팩터(Bus Factor) 를 크게 향상시켜, 특정 인원이 부재해도 누구든 맥락을 이어받을 수 있는 안전한 조직 구조를 완성했습니다.
또한, 파트 셔플과 폭넓은 코드 리뷰를 통해 다양한 동료와 협업하며 신선함과 학습을 지속할 수 있었습니다.
성장통과 그 극복 과정
실험적인 조직 구조가 완벽하지는 않았기에, 우리는 현실적인 문제들을 보완하기 위해 다음과 같은 노력을 병행했습니다.
지식의 파편화와 의존성
넓은 범위를 다루다 보니 모든 맥락을 기억하기 어려워졌고, 특정 인원에 대한 의존도가 높아질 우려가 있었습니다. 이를 해결하기 위해 ADR(Architectural Decision Record) 문화를 강화해 지식을 “사람”에서 “문서”로 옮겼습니다. 자세한 내용은 뒤에서 다시 다룹니다.
컨텍스트 스위칭의 어려움
잦은 과제 변경으로 인한 피로도를 줄이기 위해 연속성 있는 후속 과제는 가능한 같은 팀원이 이어가도록 배정에 신중을 기했습니다. 규모가 큰 과제는 2인 페어로 진행하거나 위클리 시간을 통해 ADR 내용을 공유해, 담당자가 아니더라도 언제든 맥락을 파악하고 투입될 수 있도록 했습니다.
파트 간 사일로화 방지
파트는 업무 분배 단위일 뿐이며, 파트만의 별도 규칙을 만드는 것을 금지했습니다. 좋은 시도는 팀 전체에 빠르게 공유해 모두가 함께 발전하도록 했습니다.
구조를 넘어, 소통의 리팩토링으로
20명 규모 팀의 비효율성과 경직성을 해결하기 위해 “경계 없는 파트”와 “R&E”라는 해답을 찾았습니다. 이 유연한 구조는 팀원 모두가 경계를 확장하고 지식을 교류하게 만들었으며, 대형 프로젝트에서도 강력한 기동력을 제공했습니다.
하지만 조직 구조라는 하드웨어를 리팩토링했다고 해서 시스템이 완벽해진 것은 아니었습니다. 파트 간 경계가 사라지고 역할이 확장되면서 구성원들이 알아야 할 맥락은 기하급수적으로 늘었고, 이는 새로운 소통·협업 병목을 초래했습니다.
20명이 하나의 유기체처럼 움직이기 위해서는, 바뀐 구조에 맞는 새로운 소통 프로토콜이 필요했습니다. 우리는 다시 한번 소통 방식을 리팩토링했습니다.
리팩토링으로 인한 사이드 이펙트 해소
가장 먼저 해결해야 했던 부분은 맥락 공유였습니다. 팀 구성원 간 거리는 가까우면서도 때로는 멀게 느껴집니다. 같은 과제를 함께 풀어가는 팀원은 긴밀히 소통하지만, 옆에서 다른 과제를 하는 구성원은 마치 다른 팀처럼 느껴질 수 있습니다.
전통적인 주간 회의(위클리)는 팀을 연결해주는 중요한 요소였습니다. 하지만 R&E로 책임이 확장되면서 위클리에서 다루어야 할 맥락이 늘었고, 회의 시간이 길어지는 문제가 발생했습니다. 20명이 한 사람씩 의견을 말하면 2시간 반을 넘기고, 집중력도 떨어졌습니다. Slack 스레드로 이어가려 해도 뜨거운 논의를 유지하기는 어려웠습니다.
불판: 가장 뜨거워질 수 있는 곳
우리는 불판이라는 이름으로 GitLab Issue를 기술 논의 전용 공간으로 활용했습니다. 고민을 불판에 올리면 Slack 채널에 알림이 가고, 관심 있는 구성원 누구나 자유롭게 참여할 수 있습니다.
GitLab Issue는 코드 리뷰와 친숙한 환경이며, 표·영상·사진·코드 등 다양한 편집 도구와 담당자·라벨·마감일 등 컨텍스트를 제공합니다. 또한, Slack 스레드와 달리 이슈는 언제든 확인 가능하고, 논의가 사라지지 않습니다.
불판의 장점
- 타이밍을 놓치지 않음: 즉시 올릴 수 있어 회의 일정 조율이 필요 없습니다.
- 위클리와 연계: 2~3일간 논의된 내용을 주간 회의에서 간단히 언급하고, 추가 논의는 불판에서 이어갑니다.
덕분에 위클리 시간이 절반 가까이 줄었고, 모두가 집중할 수 있는 회의가 되었습니다.
MR 리뷰 부탁드립니다
팀 Slack 채널에 매일 올라오는 “MR(Merge Request) 코드 리뷰 부탁합니다” 메시지는 대부분의 개발 팀이 마주하는 문제입니다. 코드 리뷰는 다른 과제의 맥락과 전체 서비스를 이해하게 해 주어, R&E 방향성을 실현하기 위해 반드시 해결해야 할 과제였습니다.
코질라: 바나나 하나 주면 안 잡아 먹지
코드 리뷰에 “문화”라는 단어가 붙는 이유는 강제성만으로는 지속되기 어렵기 때문입니다. 우리는 코질라(Code + Gozilla) 라는 Slack 봇을 만들어 동기부여와 최소한의 강제성을 결합했습니다.
- 하루에 코드 리뷰를 전혀 하지 않은 사람을 찾아 채널에 알림.
- 리뷰 난이도에 따라 High 라벨을 붙이면, 리뷰어가 리뷰를 수행하고 바나나 보상을 받음.
- 바나나를 받은 사람은 다음날 1일 1코드 리뷰 의무가 면제됨.
코질라 도입 후 평균 미완료 MR 수는 10개 내외로 감소했고, MR 병합 시간도 2–3일 내로 단축되었습니다. 하지만 시간이 지나면 이 메커니즘도 재조정이 필요합니다. 이름이 채널에 계속 올라가면 무감각해질 수 있기 때문에, 필요 시 상위 조직 채널로 확대하는 방안을 검토하고 있습니다.
어제의 방식에 머물지 않는 팀
커머프팀은 기능 개발뿐 아니라 일하는 방식 자체도 지속적으로 리팩토링합니다. 업무 흐름이 익숙해질수록 비효율은 숨겨지고, “원래 이렇게 해왔어요”라는 말이 자연스럽게 나오기 쉽습니다. 우리는 그 지점을 가장 경계합니다. 익숙함이라는 이유만으로 유지되는 구조·프로세스를 의심하고, 손이 많이 가는 루틴·기록 방식·반복 업무를 하나씩 꺼내어 다시 설계하는 실험을 이어갑니다.
루틴도 리팩토링합니다: 반복 업무의 재설계
루틴은 시간이 지나면 금방 굳어버리기 쉽습니다. 스프린트나 매일 아침 진행되는 데일리(일일 업무 공유 회의)도 마찬가지입니다. 처음엔 팀 흐름을 맞춰 주는 중요한 역할을 했지만, 시간이 지나면서 어느 순간 형식만 남게 됩니다. (이하 내용은 이후 업데이트 예정)