우리는 코드처럼 문화도 리팩토링한다

2 hours ago 2

팀 소개

커머스웹프론트개발팀(이하 “커머프팀”)은 배달의민족의 모든 커머스 서비스와 플랫폼은 물론, 백오피스부터 뒷단의 물류시스템에 이르기까지 웹 클라이언트 영역을 담당하는 거대한 규모의 팀입니다. 각기 다른 서비스를 담당하던 팀이 모여 하나의 큰 팀을 이루었고, 배달의민족이 꿈꾸는 커머스의 새로운 챕터를 열기 위한 힘찬 발걸음을 내디뎠습니다.

팀의 키를 잡은 초보 팀장은 얼마 못 가 혼자서는 이 거대한 조직의 복잡도를 감당해 내는 것이 불가능하다는 것을 깨닫게 됩니다. 하지만 다행히도 커머프팀에는 유능하고 팀을 돕고자 하는 팀원들이 많이 있었습니다. 팀을 이끄는 것은 사람이 아니라 함께 만들어가는 문화라는 것에 공감한 우리는, 이 문화를 코드처럼 지속적으로 리팩토링해나갈 “문화 리딩 그룹”을 꾸리게 됩니다.

오늘은 커머프팀과 문화 리딩 그룹이 함께 팀의 비효율을 걷어내고, 더 나은 구조를 만들기 위해 치열하게 고민했던 저희의 여정을 ‘조직 구조’, ‘소통 방식’, ‘기록 체계’ 관점에서 나누어 소개해 드리고자 합니다. 이제 막 팀을 꾸려 문화를 마련하고자 하는 팀, 혹은 레거시 코드처럼 단단히 굳어버린 비효율 때문에 리팩토링이 절실한 팀에게 저희의 시행착오가 조금이나마 도움이 되기를 바라며, 이야기를 시작해 보겠습니다.

하나의 목표, 유연한 조직: 경계가 없는 파트

커머프팀은 기술적 깊이를 추구하는 기능 조직의 일원인 동시에, 각 비즈니스 과제를 책임지는 목적 조직의 성격도 함께 가지고 있습니다. 이 두 가지 역할을 조화롭게 수행하는 것이 팀의 중요한 특징입니다.

하지만 거의 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인 페어(Pair)로 진행하거나 위클리 시간을 통해 ADR 내용을 공유했습니다. 이를 통해 담당자가 아니더라도 언제든 해당 과제의 맥락을 파악하고 투입될 수 있도록, 도메인 전환의 진입 장벽을 낮추는 노력을 병행했습니다.

파트 간 사일로화 방지

파트가 업무 분배 단위일 뿐임을 명확히 하고, 파트만의 별도 규칙을 만드는 것을 금지했습니다. 좋은 시도는 팀 전체로 빠르게 공유하여 모두가 함께 발전할 수 있도록 했습니다.

구조를 넘어, 소통의 리팩토링으로

결국 20명 규모 팀의 비효율성과 경직성을 해결하기 위해, 우리는 도메인 구분이 없는 파트와 “R&E”라는 파격적인 해답을 찾아냈습니다. 이 유연한 구조는 팀원 모두가 경계를 확장하고 지식을 교류하게 만들었으며, ONE COMMERCE와 같은 대형 프로젝트에서도 팀이 흔들리지 않도록 강력한 기동력을 제공했습니다.

그러나 조직 구조라는 하드웨어를 리팩토링했다고 해서 시스템이 완벽해진 것은 아니었습니다. 오히려 파트 간 경계가 사라지고 역할이 확장되자 구성원들이 알아야 할 맥락은 기하급수적으로 늘어났고, 이는 곧 소통과 협업의 새로운 병목이 되었습니다.

20명이 하나의 유기체처럼 움직이기 위해서는, 바뀐 구조에 걸맞은 새로운 소통 프로토콜이 필요했습니다. 우리는 다시 한번 리팩토링을 시작했습니다. 이번 대상은 조직도가 아니라, 우리가 “대화하고 일하는 방식”입니다.

리팩토링으로 인한 사이드 이펙트 해소

가장 먼저 해결해야 했던 부분은 맥락의 공유였습니다. 팀 구성원 간의 거리는 가까우면서도 때로는 멀게 느껴집니다. 같은 과제를 함께 풀어나가는 팀원 간에는 긴밀한 소통과 협업이 이뤄지지만 바로 옆에서 다른 과제를 하는 구성원 간에는 다른 팀이라고 해도 될 만큼 거리가 느껴질 수 있습니다.

주간 회의(a.k.a 위클리)는 팀을 연결해주는 중요한 요소입니다. 전통적인 분할 방식을 벗어나 R&E로의 책임 확장을 통해 각자가 알아야 할 맥락은 더 커졌습니다. 이때 위클리는 팀 구성원이 과제에서 마주친 문제와 고민 그리고 해결 과정을 온전히 공유할 수 있는 시간입니다.

그러나 문제는 위클리 시간이 길다는 것입니다. 대한민국 교육부의 교육과정에 따르면, 초·중·고 수업시간은 40분·45분·50분 입니다. 사람이 집중력을 잃지 않고 몰입할 수 있는 한계이지 않을까 싶습니다. 20명의 팀 구성원이 한마디씩 의견을 보태다 보면 위클리 시간은 2시간 반을 넘어가기 십상이고, 그러면 회의실에 산소가 부족해지고 집중력도 흐려집니다.

저희의 업무 메신저 Slack도 해결책이 되지 못했습니다. 길어지는 위클리를 단축시키기 위해 회의 진행자가 논의를 중재하고 Slack 스레드를 통해 이어갈 수 있도록 해보았지만, 위클리 만큼 뜨거운 논의가 진행될 수 없었습니다.

불판: 가장 뜨거워질 수 있는 곳

그래서 뜨겁게 논의를 불태워 보자는 의미로 만든 게 불판입니다. GitLab Issue를 불판이라는 이름과 함께 기술 논의 전용 공간으로 사용했습니다. 고민을 불판에 올리면 Slack 팀 채널로 알림이 오고 관심이 있는 구성원 누구나 자유롭게 참여할 수 있습니다.

처음엔 이게 될까 싶었습니다. GitLab Issue라고 다를게 있을까? 하지만 달랐습니다.

이유는 간단했습니다. 항상 코드 리뷰로 소통하던 저희에게 Gitlab Issue는 너무나 익숙한 공간이었습니다. Gitlab Issue는 표·영상·사진·인용구·코드 등 기본적인 에디팅 도구뿐만 아니라 담당자·라벨·마감일 등 다양한 컨텍스트를 제공합니다. 또한, Slack 스레드는 다른 스레드에 의해 밀려나고 휘발되지만 GitLab Issue는 항상 그 자리에 뜨겁게 남아있습니다.

불판의 장점 중 하나는 타이밍을 놓치지 않는 것입니다. 고민이 생긴 그 순간에 올리다보니, 회의 일정 잡을 필요도 없고 20명의 시간 맞출 필요도 없습니다. 그리고, 2~3일 간 논의된 내용을 주간 회의에서 잠깐 다루고 추가적인 논의는 또 불판에서 불태웁니다.

“지난주 이런 불판이 있었고, 이렇게 결론 났습니다. 궁금하신 분은 불판 링크 확인해주세요.”

덕분에 위클리 시간이 절반 가까이 줄었고, 다양한 관점에서 꼬리에 꼬리를 무는 논의로 끝없이 길어지던 위클리는 모두가 온전히 집중할 수 있는 시간이 되었습니다.

MR 리뷰 부탁드립니다.

저희 팀 Slack 채널에 매일 빠짐없이 올라오는 메시지로, MR(Merge Request) 코드 리뷰를 부탁한다는 얘기입니다. 적절한 코드 리뷰 문화를 찾는 과정은 대부분의 개발 팀이 마주하는 문제이지 않을까 싶습니다. 코드 리뷰는 서로 다른 과제의 맥락과 전체적인 서비스를 이해할 수 있게 돕기에, R&E 라는 팀 방향성을 이루기 위해서 반드시 해결해야 할 과제였습니다.

코질라: 바나나 하나 주면 안잡아 먹지

코드 리뷰에 “문화”라는 단어가 붙는다는 것은, 그 과정이 강제성만으로 이뤄질 수 없기 때문 이라고 생각합니다. 그래서 적절한 동기부여와 최소한의 강제성을 통해 이 문제를 해결하고자 했고 그 결과물이 코드 리뷰 Slack 봇 코질라(Code + Gozilla) 입니다.

코질라는 하루에 단 한 개의 코드 리뷰도 하지 않은 사람을 찾아내서 팀 채널에 알립니다. 누구도 뭐라하지 않지만 내 이름이 팀 채널에 올라오는 것만으로 충분한 동기부여를 가지게 됩니다.

하루에 한 개의 코드 리뷰를 하기 위해 모두가 쉬운 MR만 찾지 않도록, 난이도에 따른 보상 체계도 있습니다. MR 작성자는 High 라벨을 붙여 코드 리뷰 난이도가 어렵다는 것을 알릴 수 있습니다. 이때 누군가 High MR에 대해 코드 리뷰를 하면 바나나를 보상으로 받게 되고 다음날 1일 1코드 리뷰에서 면제됩니다.

코질라 덕분에, 실제로 미완료된 평균 MR 개수는 10개 내외로 줄고 MR 병합 시간도 2-3일 내로 단축되었습니다.

하지만 이게 정답이라고 생각하지 않습니다. 시간이 지나다 보면 리팩토링은 또 필요하기 마련입니다. 팀 채널에 이름이 올라오는 것쯤은 언제든 무감각해질 수 있으니까요. 그 때가 되면 팀 채널이 아니라 상위 조직 채널로 가야할 것입니다.

어제의 방식에 머물지 않는 팀

커머프팀은 기능 개발뿐 아니라 일하는 방식 자체도 계속 리팩토링하는 팀입니다. 업무 흐름이 익숙해질수록 비효율은 점점 잘 보이지 않게 숨어들고, “원래 이렇게 해왔어요”라는 말이 자연스럽게 튀어나오곤 합니다. 우리는 바로 그 지점을 가장 경계했습니다. 익숙함이라는 이유만으로 유지되는 구조나 프로세스를 의심하고, 손이 많이 가는 루틴과 기록 방식, 그리고 반복 업무를 하나씩 꺼내어 다시 설계하는 실험을 이어가고 있습니다.

루틴도 리팩토링합니다: 반복 업무의 재설계

루틴은 시간이 지나면 금방 굳어버리기 쉽습니다. 업무 주기인 스프린트나 매일 아침에 진행되는 데일리(일일 업무 공유 회의)도 마찬가지입니다. 처음엔 팀의 흐름을 맞춰 주는 중요역할을 했지만, 시간이 지나면서 어느 순간 형식만 남은 숙제처럼 변해버렸습니다.

팀에서 진행하는 정기적인 회고나 설문에서도 같은 신호가 나왔습니다. 제목만 말하고 끝나는 데일리, 일정이 들쭉날쭉한 회의, 사람마다 전부 다른 방식의 업무 공유, 실제 일정과 잘 맞지 않는 스프린트 운영까지. ‘늘 해오던 거니까’, 익숙하다는 이유만으로 방치했던 익숙한 루틴들이 어느새 팀의 속도를 떨어뜨리고 있었던 겁니다.

그래서 작은 부분을 손보는 대신, 아예 원점으로 돌아가 질문을 던졌습니다. “이걸 왜 하고 있지?” 스프린트는 외부 일정에 휘둘리지 않고 내부 리소스를 주도적으로 관리하는 단위여야 했고, 데일리는 보고를 하는 시간이 아니라 “도움이 필요하거나 막힌 지점을 찾아내는 시간”이어야 했습니다. 목적을 다시 정의하고 나니 남길 것과 버릴 것이 명확해졌고, 그 기준에 맞춰 루틴을 다시 설계할 수 있었습니다.

스프린트 운영 방식은 크게 두 번의 진화과정을 겪었습니다. 초기에는 서로 다른 팀의 방식들을 하나의 언어로 맞추는 데 집중했다면, 이번에는 실무자의 불편함을 해소하는 방향에 초점을 맞추었습니다.

우선, 추상적인 난이도 점수였던 스토리 포인트(SP)는 난이도가 아닌 ‘실제 투입 시간 (1SP=4시간)’으로 단순화했습니다. 다 함께 모여 난이도를 산정하느라 준비도 길고 효용성이 떨어지는 플래닝 포커(참고)는 과감히 없앴습니다. 대신 긴급하게 들어온 이슈도 이제는 예외가 아니라 스프린트 흐름 안에서 SP와 워크로그로 관리하게 했습니다. 규칙을 많이 만드는 것보다, 누구나 자연스럽게 따라갈 수 있는 단순함을 택한 것입니다.

데일리도 마찬가지였습니다. 사람마다 기대치가 다르다 보니 같은 회의를 하고 있는데도 서로가 전혀 다른 목적을 갖고 있었죠. 그래서 데일리를 ‘어제 완료한 일, 오늘 할 일, 일을 막는 장애 요소(어려운 점)’ 세 가지를 짧게 공유하는 시간으로 다시 정의했습니다. 도구도 파트별 Slack 스레드로 통일했고, 회의 시간은 15분으로 고정했습니다. 만약 깊은 논의가 필요하다면 파트 구분 없이 꼭 필요한 사람들끼리만 별도로 모여 해결하도록 했습니다. 매일 같은 말을 반복하더라도 단순히 ‘했다’가 아니라 ‘어떤 흐름으로 가고 있다’가 보이도록 하는 게 핵심입니다.

사소해 보일 수 있지만, 이 작은 변화들이 팀의 리듬을 다시 안정시켰습니다. 루틴은 한 번 굳어지면 아무도 말하지 않는 사이에 계속 무거워지기 마련입니다. 커머프팀은 “원래 이렇게 해왔어요”라는 말이 들리는 순간 다시 그 지점을 의심해봅니다. 그리고 필요하다면 언제든 익숙한 구조를 새롭게 재설계합니다.

기록 방식의 버전업: 1Pager에서 ADR로

문서의 양식을 바꾸게 된 계기는 아주 작은 불편함들이 쌓이면서부터였습니다. 오랫동안 팀의 표준으로 자리 잡았던 1pager(원페이저)는 처음엔 유용한 도구였습니다. 일반적으로 원페이저는 프로젝트 발의나 기획 용도로 쓰이지만, 우리팀은 일의 과정과 최종 결과, 성과 측정까지 모든 것을 이 문서 하나에 담아왔습니다. 하지만 시간이 지날수록 본래의 목적을 잃고 무거워졌습니다. 기획서 링크, 디자인 피그마 링크, API 문서, Slack에서 오간 긴 논의들이 뒤섞여 내용은 방대해졌고, 정작 “이 기능을 왜 이렇게 구현했지?”라는 단순한 질문에도 여러 문서를 뒤져야 했습니다.

그래서 먼저 1Pager를 가볍게 만드는 시도를 했습니다. 작업 목록을 나열하는 대신 ‘문제–해결–결과’ 중심으로 핵심만 남기도록 서식을 개편했습니다. 작업이 모두 끝난 시점에 회고하듯 정리하는 이 방식은 한동안 잘 작동했고, 실제로 가독성도 꽤 좋아졌습니다.

하지만 여러 차례 개편을 거치면서 오히려 더 명확해진 한계가 있었습니다. 1Pager는 ‘작업 요약’을 남기기에는 적합하지만, ‘왜 그런 기술적 선택을 했는가’를 남기기에는 맞지 않았습니다. 아키텍처 변경, 라이브러리 도입, 도메인 복잡도에 따른 기술적 타협 같은 결정들은 결과보다 문제의 배경과 고민의 흐름을 온전히 담은 ‘맥락’이 훨씬 중요합니다. 하지만 성과 보고 중심의 1Pager 틀 안에서는 그 치열했던 고민의 과정들이 자주 생략되곤 했습니다.

이 지점에서 우리는 Architectural Decision Record(ADR)이라는 새로운 방식을 도입하게 됩니다. ADR은 이름 그대로 기술적 판단과 맥락을 기록하는 데 최적화된 도구입니다. 이 형식을 팀에 맞게 다음과 같이 정의하여 사용하고 있습니다.

Context (맥락): 어떤 문제 상황에서 논의가 시작되었는가?
Decision (결정): 여러 선택지 중 무엇을 선택했고, 그 이유는 무엇인가?
Consequences (결과): 그 결정으로 얻는 이득과 감수해야 할 비용은 무엇인가?
Retrospective (회고): 진행하며 얻은 인사이트나 교훈은 무엇인가?

하나의 의사결정이 하나의 문서로 독립되어 남기 때문에 시간이 지나도 당시의 고민을 그대로 복기할 수 있습니다. 기존 문서를 덮어쓰는 대신 새로운 ADR을 차곡차곡 쌓는 방식 덕분에 의사결정의 히스토리를 자연스럽게 추적할 수 있게 되었습니다.

결국 1Pager 사용을 공식적으로 종료하고 ADR 기반의 기록 방식으로 완전히 전환했습니다. 흩어져 있던 기록의 파편들이 ADR이라는 체계 안에서 정리되었고, 이제 기술적 흐름을 팀 전체가 같은 시각으로 바라볼 수 있게 되었습니다. 기록은 더 이상 의무적으로 작성하는 귀찮은 문서가 아니라, 미래의 우리에게 길을 안내하는 팀의 기억 장치가 되었습니다.

우리는 귀찮음을 레거시로 남기지 않습니다: 자동화

자동화는 그저 편함을 쫓는 작업이 아닙니다. 반복적인 입력과 수작업을 줄여 사람이 해야 할 판단과 문제 해결에 집중할 수 있는 환경을 만들어내는 과정입니다. 반복 업무는 하루 단위로 보면 사소해 보이지만, 쌓이면 팀 전체의 리듬을 끊고 실수를 유발하며 중요한 순간의 대응 속도를 떨어뜨리는 부채가 됩니다. 그래서 “이 일을 굳이 사람이 계속해야 하나?”라는 질문이 나오면 주저 없이 자동화를 시도했습니다. 많은 자동화가 팀 속에 녹아 있지만 이 글에서는 대표적인 네 가지를 소개하고자 합니다.

수기 입력을 최소화한 Jira 이슈 관리

회사에서 이슈 관리 솔루션으로 사용하는 Jira는 강력한 도구지만, 관리 자체가 또 다른 업무처럼 느껴지는 때가 많았습니다. 시작일, 종료일, 릴리즈 연동, Story Point 등 다양한 필드는 모두 중요하지만 이를 매번 사람이 직접 입력하는 과정은 불필요한 에너지 소모를 일으켰습니다.

이를 해결하기 위해 Jira Automation을 도입했습니다. 작업자가 티켓을 ‘완료’ 상태로 변경하면 시스템이 종료일을 자동으로 기록하고, Story Point를 기입하면 예상 일정을 계산해 줍니다. 릴리즈 날짜를 지정하는 순간 해당 날짜의 릴리즈 버전이 생성되기도 합니다. 또한, 기한이 지난 티켓 목록은 주기적으로 Slack DM으로 알림이 발송되어 놓치는 업무 없이 챙길 수 있도록 돕습니다. 자세한 흐름은 다음의 기술블로그를 통해 확인하실 수 있습니다 👉Jira Automation으로 반복 업무를 효율적으로 관리해보자 | 우아한형제들 기술블로그

담당자를 스스로 찾아가는 장애 알림 시스템

장애를 감지하는 속도도 높였습니다. 모니터링 도구인 센트리(Sentry)를 최적화하여 특정 레벨 이상의 에러가 발생하면 즉시 팀 Slack 채널로 알림을 전송하고, 담당 파트를 자동으로 멘션하도록 구성했습니다. 덕분에 장애 발생 시 “누가 이거 확인할 수 있을까요?”라고 묻고 답하느라 허비하던 시간을 없애고 담당자가 즉시 문제를 인지하고 해결에 뛰어들 수 있게 되었습니다. 자세한 내용은 아래 기술블로그에서도 확인할 수 있습니다 👉선제적 장애 대응을 위한 Sentry 최적화 적용기 | 우아한형제들 기술블로그

골든타임을 사수하는 원터치 장애 선포

장애 대응 프로세스 중 장애 선포 과정에서도 자동화는 큰 역할을 합니다. 긴박한 상황에서 절차를 챙기는 건 쉽지 않습니다. 이제는 팀 채널에서 /선포 또는 /장애선포를 입력만 하면 회사 표준 포맷에 맞는 장애 채널이 생성되고 유관 부서 담당자들이 자동으로 초대됩니다. 1분 1초가 중요한 장애 상황에서 이 자동화는 대응의 속도와 정확도를 크게 개선하는 데 도움을 주었습니다.

배포 안정성을 높이는 릴리즈 노트 자동화

최근에는 배포 과정에도 자동화를 더했습니다. Jira 티켓에 배포 날짜가 지정되면 그 날짜를 기반으로 릴리즈 플랜 문서가 자동으로 생성됩니다. 이 문서는 배포 전 점검해야하는 항목을 구조화해서 보여주기 때문에, 담당자가 부재중이거나 급하게 배포해야 할 때에도 어떤 항목을 검토하고 유사시 어떻게 롤백해야 하는지 직관적으로 파악할 수 있어 배포 안정성을 크게 높였습니다.

이 모든 자동화는 반복은 기계에게 맡기고, 사람은 더 중요한 고민을 하자는 단순한 의지에서 출발했습니다. 작은 시도들이 모여 팀의 업무 흐름은 가벼워졌고, 우리는 더 가치 있는 문제 해결에 에너지를 쏟을 수 있게 되었습니다.

하지만 좋은 도구와 시스템만으로는 충분하지 않습니다. 자동화로 아낀 시간을 무엇으로 채울지, 리팩토링한 구조 위에서 어떻게 협업할지를 결정하는 것은 결국 ‘사람’과 ‘문화’이기 때문입니다. 효율적인 시스템이 ‘잘 달릴 수 있는 도로’라면 그 위를 달리는 것은 실패를 두려워하지 않고 핸들을 꺾어보는 팀원들의 ‘마음가짐’입니다. 커머프팀이 변화를 지속할 수 있었던 진짜 동력은 이러한 시스템 위에서 끊임없이 새로운 시도를 멈추지 않은 ‘도전적인 문화’에 있습니다. 물론 새로운 시도는 언제나 예상과 다른 결과를 만들 수 있고 모든 선택이 항상 최적의 답으로 이어지지는 않습니다.

실패가 아니라 과정입니다

그럼에도 커머프팀은 그런 시행착오를 ‘실패’로 단정 짓기보다는 더 나은 방향을 찾기 위한 과정의 일부로 받아들이고 있습니다. 다만 시도에는 언제나 명확한 목적과 근거가 필요하며, 결과에 대해서도 팀이 함께 책임지고 회고합니다. 이렇게 쌓인 경험들이 결국 팀의 기준이 되고 다음 선택을 더 단단하게 만드는 자산이 되고 있다고 믿습니다.

우리는 팀이 심리적으로 안전한 울타리가 되어야 한다고 생각합니다. 반대 의견을 냈다고 눈치를 보지 않아도 되고, 실수를 했다고 위축되지 않아도 되며, 당당하게 모른다고 말할 수 있는 분위기가 기본이 되었으면 합니다.

다만 이러한 튼튼한 울타리 안에서 가만히 머무는 팀이 되는 것은 경계합니다. 안전함에 안주하지 않고, 편안함에 정체되지 않도록 서로가 서로에게 건강한 자극이 되는 팀이 되고자 합니다.

“이 구조가 정말 최선일까”, “새롭게 시도해볼 수는 없을까”

이런 질문들을 누구든 가볍게 던질 수 있고 누구라도 가볍게 흘려보내지 않는 팀이 되기 위해, 의도적으로 함께 성장하고 함께 실험하는 구조를 만들고 있습니다.

질문이 스터디가 되는 팀

이처럼 업무를 하다 자연스럽게 생긴 기술적인 고민들과 문제 의식을 팀 전체로 끌어올리고, 함께 해결해나가는 구조를 만들기 위해 정기적으로 주제들을 모아서 팀 스터디를 진행하고 있습니다.

실제로 한 번은 팀 내에서 인프라 구조와 비용에 대한 이해가 충분하지 않다는 공감대가 형성된 적이 있었습니다. 현재 우리의 구조가 최선인지, 합리적인 비용을 사용하고 있는지 자신있게 설명하기 어려운 순간들이 반복되었기 때문입니다.

이러한 문제를 개인의 학습 과제로 남기지 않고, 팀 전체의 과제로 인식하여 AWS 스터디를 진행했습니다. 단순히 스터디를 진행하는 것을 넘어 우리가 사용하는 인프라 구조를 살펴보고, 더 나은 대안이 없을지 검토하며, 비용 청구서를 기반으로 더 비용을 절감할 수 있는 방법을 탐구했습니다.

그 결과, 인프라 구조에 대한 관점이 한층 단단해질 수 있었고 불필요한 비용 사용을 자체적으로 절감할 수 있었습니다. 이러한 변화는 단순한 학습을 넘어 스터디에 참여한 멤버 전원이 AWS 자격증을 취득할만큼 각자의 전문성을 끌어올리는 계기가 되었습니다.

물론 스터디의 결과물이 항상 자격증일 필요는 없습니다. 때로는 백오피스 서비스에 대한 이해를 높이기 위해 함께 모여 토론의 장을 열기도 하고, 데이터 분석 역량 강화를 위한 쿼리 작성 스터디가 자연스럽게 이루어지기도 합니다.

이 모든 시도는 우리가 더 일을 잘하는 팀이 되기 위한 과정이며, 편안함에 머무르지 않기 위한 선택입니다. 개인의 노력이 모여서 팀의 기반이 되고, 그 기반이 다시 새로운 방향성을 만들어냅니다.

조금 더 단단한 팀으로

커머프팀은 팀이라는 울타리가 제공하는 심리적 안전감(Psychological Safety)을 바탕으로 각자가 마음껏 도전하고 실패해볼 수 있는 환경을 만드는 것을 중요하게 생각합니다. 아이디어를 내는 것에서 그치지 않고 직접 적용해보고 시행착오를 겪는 경험이 성장을 만든다고 믿기 때문입니다.

누구나 자유롭게 불판을 통해 기술 토론을 제안할 수 있고, 스터디를 통해 함께 성장하며 배운 것을 실제 서비스에 옮겨볼 수 있습니다. 저희는 이 옮겨보는 과정 자체를 소중하게 여깁니다. 아이디어를 떠올리고 가능성을 검토하는 것까지는 비교적 쉽지만, 실제로 서비스에 적용해보는 과정에서 마주하는 수많은 변수와 문제를 몸으로 겪어보는 경험은 훨씬 값지기 때문입니다.

그래서 커머프팀에서는 누군가의 작은 문제의식이 바텀업 기술 과제로 이어지고, 하나의 아이디어가 TF로 확장되며, 그 시도들이 다시 서비스 개선으로 연결되는 흐름이 자연스럽게 만들어집니다.

팀이 만들어진 이후 팀원들은 커머스 서비스의 성능과 안정성을 높이기 위한 수많은 시도를 이어왔습니다. 그 치열했던 과정과 배움은 우아콘 세션을 통해 공유하기도 했습니다.

대규모 트래픽 환경에서의 성능개선 경험: 장보기⋅쇼핑 성능 최적화 고군분투기
품질을 지키는 자동화 전략: 로그 회귀 테스트 구축 세션

또한, 우리가 마주한 구체적인 문제 해결 과정과 새로운 시도들은 기술블로그를 통해 꾸준히 기록하며 공유해 왔습니다.

장애를 보다 빠르게 감지하고 대응하기 위한 Sentry 재정비
접근성 개선하기
웹과 네이티브의 공존을 위한 플로팅웹뷰 기술 도전
개발과 디자인 사이의 협업 방식을 개선하기 위한 디자인옵스 TF 활동
팀의 업무 효율을 개선하기 위한 자동화 여정

모든 시도들이 항상 성공적이었던 것은 아닙니다. 기대만큼 효과를 내지 못한 경우도 있었고, 되돌려야 했던 선택도 있었습니다. 그럼에도 이 시도들이 의미있었던 이유는 성공 여부와 관계없이 그 모든 경험이 팀의 자산으로 남았기 때문입니다.

우리는 결과만을 남기기보다 그 과정에서 어떤 판단을 했고 왜 그런 선택을 했는지를 더 중요하게 돌아봅니다.

그러한 고민들이 차곡차곡 쌓여 팀의 기준은 점점 더 단단해졌고, 선택의 순간마다 참고할 수 있는 경험의 두께도 자연스럽게 두터워졌습니다.

이 경험들이 모여 팀이라는 울타리를 단단하게 만들고 있다고 믿습니다.

마무리: 오늘의 정답이 내일의 레거시가 되지 않도록

지금까지 커머프팀이 걸어온 문화 리팩토링의 여정을 소개해 드렸습니다.

우리는 경직된 조직 구조를 경계 없는 파트로 리팩토링하여 유연한 아키텍처를 확보했고, 지식의 깊이를 더하는 ADR과 반복을 줄이는 자동화를 통해 시스템의 효율을 높였습니다. 또한 비대해진 소통 비용을 줄이기 위해 “불판”과 “코질라”라는 새로운 프로토콜을 도입했습니다. 그리고 이 모든 변화가 두려움 없이 지속될 수 있도록 “심리적 안전감”이라는 테스트 환경을 구축했습니다.

물론 공유한 이 방식들이 모든 팀의 정답은 아닐 것입니다. 심지어 우리 팀에게조차 영원한 정답은 아닙니다. 팀의 규모가 더 커지거나 비즈니스 상황이 변하면, 지금 우리가 자랑스럽게 여기는 R&E 문화나 비동기 소통 방식도 언젠가는 걷어내야 할 레거시가 될지 모릅니다.

하지만 이 과정을 통해 확인한 변하지 않는 사실이 하나 있습니다. 바로 마치 좋은 코드가 시스템을 견고하게 지탱하듯 건강한 문화가 팀을 지탱한다는 것입니다.

그렇기에 우리는 앞으로도 멈추지 않을 것입니다. 끊임없이 팀이라는 코드를 들여다보고, 비효율이라는 버그를 찾아내고 더 나은 구조로 개선해 나갈 것입니다. 코드 품질을 지속적으로 관리하듯이 우리의 문화도 매일 조금씩 더 나은 방향으로 지속적 배포(Continuous Deployment) 를 이어갈 것입니다.

지금 이 순간에도 조직의 성장통으로 고민하고 계신 분들이 있다면 거창한 개편이 아니어도 좋습니다. 팀을 무겁게 만드는 “문화 부채”가 무엇인지 찾아보는 작은 회고부터 시작해보는 건 어떨까요? 커머프팀의 문화 리팩토링 여정이 여러분의 팀을 디버깅하는 데 작은 힌트가 되었기를 바랍니다.

Read Entire Article