코드 리뷰 봇으로 시작된 팀 문화의 변화

WMS플랫폼팀은 B마트 서비스의 물류 플랫폼 중에서도 WMS(Warehouse Management System)를 담당하고 있습니다.

WMS는 창고의 상태를 가시화하고, 무엇이, 어디에, 얼마나 있는지를 신뢰할 수 있는 데이터로 관리하는 시스템입니다. 이 목적을 달성하기 위해 다양한 기능과 프로세스를 제공하고 있습니다. WMS에 대한 조금 더 자세한 설명은 전체 서비스를 관통하는 도메인 모듈을 안전하게 분리하기를 참고 해주세요.

팀에서는 하나의 스프린트를 2주로 산정하고 있습니다. 개발자들은 한 스프린트 안에 본인이 담당한 업무(티켓)의 개발 및 코드 리뷰를 완료하는 것을 목표로 하고 있습니다. 개발은 본인이 집중해서 끝내면 되지만, 코드 리뷰는 다른 팀원들의 도움이 필요합니다.

하지만 코드 리뷰가 빠르게 진행되지 않아 티켓이 스프린트 내에 완료되지 못하는 일이 반복되었습니다. 회고를 진행하다 보면, 개발은 끝났지만 리뷰를 기다리다가 스프린트를 넘기는 경우가 많았습니다. 팀은 이 문제를 어떻게 해결할지 고민하게 되었습니다.

이번 글에서는 팀의 코드 리뷰 문화가 어떻게 발전했고, 이를 위해 만들어진 코드 리뷰 봇이 팀 문화에 어떤 영향을 주었는지에 대해 리뷰해보려 합니다.

기존 코드 리뷰 프로세스

WMS플랫폼팀은 8명의 개발자로 구성되어 있었으며, 다음과 같은 코드 리뷰 규칙을 운영하고 있었습니다.

MR(merge request)이 생성되면 2명 이상의 리뷰어에게 승인(approve) 받아야 머지할 수 있다.

코드 리뷰는 놓치기 쉬웠기 때문에, GitLab의 Slack Integration 기능을 활용해 리뷰 알림을 발송하였습니다.
매일 출근 시간에 맞춰 Slack 채널로 현재 열려 있는 MR 리스트를 전달해,
리뷰가 잊히지 않고 꾸준히 진행되도록 하는 것이 목표였습니다.

Slack에서 MR을 확인할 수 있기 때문에 GitLab보다 접근성이 높았고, 이를 통해 빠른 리뷰가 진행될 수 것이라고 기대하였습니다.

하지만 빠르고 지속적인 코드 리뷰가 이루어지지 못했고, 담당자가 직접 리뷰를 요청해야 하는 경우가 잦아졌습니다.

리뷰 속도가 느려진 원인

문제가 반복되자 팀 내부에서 원인을 분석해 보았고, 아래 두 가지 주요 요인이 드러났습니다.

1️⃣ 모든 개발자를 리뷰어로 지정하는 방식

일부 MR은 특정 도메인에 대한 깊은 이해가 필요한 경우가 있어 필수 리뷰어를 지정할 수 있었습니다.
하지만 팀에서는 코드 리뷰를 단순한 승인 절차가 아닌 도메인 지식 전파의 기회로도 활용하고 있었습니다.
이러한 취지로 대부분의 MR은 모든 개발자를 리뷰어로 일괄 지정하는 방식을 택했습니다.

취지에 맞게 모두가 MR을 검토하며 도메인 지식을 쌓고, 빠른 리뷰가 이루어졌다면 이상적이었겠지만 실제로는 다른 결과가 나타났습니다.
리뷰어가 많을수록 “나는 지금 내 개발이 바쁘니 누군가 대신하겠지”라는 인식이 생겼고, 결국 늘 리뷰를 담당하던 일부 인원만 지속적으로 리뷰에 참여하게 되었습니다.

그 결과, 리뷰 참여가 특정인에게 편중되면서 도메인 지식 전파라는 본래의 의도도 충분히 실현되지 못했습니다.
또한 ‘8명 중 2명만 승인하면 된다’는 정책은 이런 현상을 더욱 고착화시켰습니다.
필수 리뷰어가 없는 구조 속에서 책임이 흐려지고, 학습 효과 역시 제한적이었던 셈입니다.

2️⃣ 알림은 있지만 ‘내가 리뷰해야 할 MR’이 보이지 않음

Slack 알림은 단순히 프로젝트 내에서 열려 있는 MR 목록만 보여줄 뿐이었습니다.
겉보기에는 “GitLab에 직접 들어가지 않아도 MR을 확인할 수 있다”라는 점에서 편리해 보였지만, 실제로는 “누가 무엇을 리뷰해야 하는지”를 구체적으로 알려주지 못했습니다.

특히 아래와 같은 정보는 전혀 구분되지 않았습니다.

• 내가 이미 리뷰한 MR 인지
• 아직 리뷰하지 않은 MR 인지
• 혹은 나와 무관한 MR 인지조차

결국 Slack 알림은 ‘모두에게 전달되지만 누구에게도 유효하지 않은 메시지가 되었고, 본래의 목적이었던 리뷰 활성화 도구로서의 기능을 완전히 수행하지 못했습니다.

첫 번째 개선 : 리뷰 독려 메시지

기존의 Slack 알림은 단순히 열려 있는 MR 목록을 보여줄 뿐, 내가 리뷰해야 할 MR이 무엇인지를 알려주지 못했습니다.

이 문제를 해결하기 위해, 리뷰어 개인에게 의미 있는 정보만 전달하는 봇을 만들기로 했습니다.

이번 기능의 목표는 다음과 같았습니다.

Slack에서 내가 리뷰해야 할 MR을 한눈에 볼 수 있게 하자.

복잡한 시스템이 필요하진 않았습니다.
가장 익숙한 Kotlin + Spring Boot로 빠르게 프로토타입을 만들었습니다.
GitLab API를 활용해 프로젝트의 MR을 조회하고,
각 리뷰어별로 아직 리뷰하지 않은 MR만 추려 Slack 메시지로 전송하는 간단한 구조였습니다.

새로운 봇은 매일 오전과 오후 두 차례,
각 리뷰어가 확인해야 할 MR 현황을 다음과 같이 채널에 전송했습니다.

배포 이후 열렬한(?) 환호도 얻을 수 있었습니다.

두 번째 개선 : 랜덤 리뷰어 할당

리뷰 독려 메시지를 통해 내가 리뷰해야 할 MR을 한눈에 볼 수 있게 되었지만,
리뷰어 지정 방식은 여전히 비효율적이었습니다.

당시에는 대부분의 MR에 모든 개발자를 리뷰어로 일괄 지정하는 방식이 사용되고 있었습니다.
도메인 지식 전파라는 취지는 좋았지만, “8명 중 2명만 승인하면 된다”라는 정책 아래에서는 자연스럽게 나는 바쁘니까 다른 사람이 하겠지라는 인식이 반복되었습니다.

이 문제를 해결하기 위해 리뷰어를 2명만 자동으로 랜덤 할당하는 방식으로 전환했습니다.
필수 리뷰어를 명확히 지정함으로써 책임을 분산시키지 않고, 특정인에게 리뷰가 몰리는 현상도 완화하고자 했습니다.

이번 기능의 목표는 아래와 같았습니다.

리뷰어를 모두 지정하지 말고, 머지에 필요한 필요한 최소 인원인 두 명을 자동으로 지정하자.

구현은 간단했습니다.
GitLab Merge Request API를 활용하여 현재 프로젝트의 모든 MR을 조회하고,
앞서 만든 리뷰 독려 메시지 기능을 확장해 개발자별 잔여 리뷰 개수를 계산했습니다.
그리고 잔여 리뷰가 적은 개발자 순으로 정렬해 부담이 적은 두 명을 자동으로 리뷰어로 지정하도록 했습니다.
이로써 리뷰가 한쪽으로 몰리지 않으면서도, 매번 수동으로 리뷰어를 선택해야 했던 번거로움이 사라졌습니다.

세 번째 개선 : 휴가자 리뷰어 후보군 제외

랜덤 리뷰어 자동 할당으로 리뷰 속도는 크게 개선되었지만, 한 가지 아쉬움이 남았습니다.
바로 휴가 중인 팀원이나 다음날 휴가 예정인 팀원에게도 리뷰가 자동 배정되는 경우가 있었던 것입니다.
휴가자가 리뷰어로 지정되면 빠른 리뷰 진행이 어려워지고, 결국 MR이 며칠씩 대기하는 상황이 발생했습니다.

그래서 리뷰어 자동 할당 로직에 휴가자 정보를 반영하기로 했습니다.

이번 기능의 목표는 아래와 같았습니다.

오늘 (혹은 내일) 휴가자는 리뷰어 후보에서 제외

휴가자 관리 API를 추가 연동하여, 팀 내 휴가자 정보를 받아올 수 있도록 구성하였습니다.
그리고 리뷰어 후보군에서 오늘이나 내일 휴가자를 필터링하는 방식으로 개발을 진행하였습니다.

최종적으로 완성된 리뷰어 할당 프로세스의 다이어그램은 아래와 같습니다.

개선 결과

2023년 하반기 코드 리뷰 봇이 최초 도입 된 이후 WMS플랫폼팀의 코드리뷰 소요시간은 꾸준히 개선 되고 있습니다.

주요 지표는 다음과 같습니다.

이외에도 리뷰 할당 배치 방식에서 webhook 방식으로 즉시 전환, 파트별 리뷰어 분리 등 추가 개선을 통해 팀의 코드 리뷰 문화는 지금도 발전해 나가고 있습니다.

처음에는 코드 리뷰의 효율을 높이기 위해 만들어진 작은 프로젝트 봇이었습니다. 하지만 시간이 지나면서 이 봇은 단순한 자동화 도구를 넘어,
팀 전체의 일하는 방식과 문화를 바꾸는 핵심으로 성장했습니다.

휴가자 알림

예전에는 누가 휴가인지 확인하기 위해 직접 구글 캘린더를 열어야 했고, 휴가자는 본인이 휴가인 걸 알리기 위해 캘린더에 수동으로 일정을 등록해야 했습니다.
이러한 불편함을 코드 리뷰 봇 개선을 위해 연동된 휴가자 API를 기반으로 해소하였습니다.
매일 아침 봇이 자동으로 팀 채널에 “오늘의 휴가자”를 알려주고, 누가 부재중인지 한눈에 확인할 수 있게 되었습니다.

스크럼 도우미

WMS플랫폼팀에서는 매 스프린트마다 스크럼 문서를 만들고 매일 스크럼 시간에 오늘 할 일 / 힘든 점 / 어려운 점을 작성하고 공유합니다.
문제는 이 문서를 매번 스크럼 마스터가 직접 생성하고, 팀원들이 매 스프린트마다 새로운 링크를 찾아야 한다는 점이었습니다.
이 반복적인 과정은 단순하지만 귀찮고, 자주 놓치게 되는 일이었습니다.

그래서 코드 리뷰 봇을 한 번 더 확장시켰습니다.
이번엔 Confluence API를 연동하여 다음과 같은 목표를 세웠습니다.

1️⃣ 스프린트가 시작되면 스크럼 문서를 자동으로 생성하자
2️⃣ 스크럼 시작 전에 팀 채널에 문서 링크를 공유하자

이를 통해 스크럼 마스터는 문서 생성이나 공지에 신경 쓸 필요 없이 오로지 스크럼 진행에만 신경 쓸 수 있는 환경이 만들어졌고, 팀원들도 더 이상 문서를 찾아야 하는 번거로움이 사라졌습니다.

온콜 담당자 교체 및 알림

WMS플랫폼팀은 서비스 안정성을 위해 매일 온콜(On-call) 담당자 제도를 운영하고 있습니다. 온콜 담당자는 서비스 이슈나 문의가 발생했을 때 우선적으로 대응하는 역할을 맡고 있습니다. 기존에는 온콜담당자를 알기 위해서는 캘린더에 등록된 온콜 담당자를 확인하는 수밖에 없었습니다. 문의가 발생했을 때 온콜 담당자를 찾는 데에 소요되는 시간도 상당히 소요되고는 했습니다.

이러한 불편함을 해소하기 위해 봇에 다음과 같은 기능을 추가하였습니다.

1️⃣ Slack 내 전용 온콜 그룹을 만들자
2️⃣ 매일 아침, 봇이 자동으로 오늘의 온콜 담당자를 갱신
3️⃣ 팀 채널에 그날의 담당자를 공지

온콜 업무대응 이력 서포터

온콜 업무를 하다 보면 빠르게 대응 가능한 업무도 있지만, 대응에 오랜 시간이 걸리고 다음 온콜을 위해서 이력을 남겨야 할 경우도 발생하곤 합니다.
코드 리뷰 봇은 Slack, Confluence와의 연동을 통해 Slack으로 온콜 대응 이력을 작성하면 Confluence에 자동으로 글을 작성할 수 있는 프로세스를 만들어 온콜 대응 이력을 관리해 주는 역할도 함께 맡고 있습니다.

코드 리뷰 봇은 처음부터 거창한 목표를 가진 프로젝트가 아니었습니다.
그저 “리뷰가 늦어진다”라는 작은 불편함을 해결해 보자는 단순한 문제의식에서 출발했습니다.
하지만 그 작은 시작이, 팀이 일하는 방식과 협업 문화를 바꾸는 전환점이 되었습니다.

프로젝트를 운영하며 가장 크게 느낀 점은, 이 봇이 ‘누군가의 개인 프로젝트’가 아니라는 것입니다.
누군가 아이디어를 내면 다른 사람이 기능을 보완하고, 팀원 모두가 필요한 기능을 제안하고 직접 개선했습니다.

그 과정에서 “팀이 함께 만들어가는 문화”란 무엇인지 체감할 수 있었습니다.

또한, 이 작은 프로젝트는 팀 개발자들에게 훌륭한 테스트 베드(Test Bed) 역할을 했습니다.
새로운 기술이나 아키텍처를 실험해 볼 수 있는 환경으로 활용되었고, 실제로 메인 프로젝트에 헥사고날 아키텍처를 도입하기 전,
이 프로젝트를 리팩토링하며 설계 방향을 검증할 수 있었습니다.

이제 코드 리뷰 봇은 단지 효율적인 코드 리뷰를 돕는 도구가 아니라, WMS-Supporter라는 이름으로 운영되고 있습니다.

작은 봇 하나가 문화를 바꾼 것처럼, 팀의 작은 불편함부터 개선을 진행해 보는 게 어떨까요?