Orchestration 길드 멤버인 Fukuyama입니다. Yahoo!プレイス(이하 Yahoo!플레이스)라는 서비스에서 프런트엔드 개발을 담당하고 있습니다.
먼저 Orchestration 길드를 소개하겠습니다. Orchestration 길드는 임원진이 선발한 엔지니어가 모여 AI를 활용하는 ‘현장 지식’을 전사적으로 공유하는 커뮤니티입니다. 워크숍에서 다룰 주제 제안, 실천할 수 있는 사용 사례 공유, 기술 관점에서 품질 조언 등을 담당하며, Orchestration Development Workshop 콘텐츠가 특정 개인에게 의존하지 않고 지속적으로 발전할 수 있도록 지원하는 역할을 맡고 있습니다.
이 글에서는 제가 팀에서 추진하고 있는 AI를 활용한 PR 리뷰 지원 활동을 바탕으로 Orchestration 길드에서 개최한 워크숍, ‘리뷰 정체를 해소하기 위한 AI와 체계화 실전 강의’ 내용을 소개합니다. 리뷰 효율화나 품질 유지에 어려움을 느끼는 분들을 위해 AI와 체계화를 조합해 팀과 조직을 변화시킨 방법을 전달할 예정입니다. ‘어디서부터 시작해야 할지’ 혹은 ‘어떤 지표로 결과를 측정해야 할지’ 고민이라면 구체적인 방안을 얻어가시길 바라며 시작하겠습니다.
PR 리뷰 정체 발생
2024년 하반기에 저는 Yahoo!플레이스의 백엔드 개발 팀 테크 리드를 맡고 있었습니다. 당시 리뷰 대응은 저와 다른 한 명의 팀원에게 집중됐는데 저 또한 구현을 담당하고 있었기에 코드를 작성하면서 리뷰도 처리하는 상황이 지속됐습니다. 개발 속도를 리뷰가 따라잡지 못해 리뷰 대기 중인 PR이 쌓이고 있었고, 리뷰한 뒤에는 ‘이 리뷰, 정말 충분할까? 놓치고 있는 버그는 없을까?’ 생각에 가슴 한편이 늘 불안했습니다. 리뷰에 쫓겨 제 코드에 집중할 수 없는 날이 이어졌고, 마감일이 다가올 때면 ‘시간이 더 있다면 더 꼼꼼하게 리뷰할 수 있을 텐데’라는 생각이 들며 개인의 노력만으로는 한계가 있음을 통감했습니다.
결국 다음과 같은 리뷰 정체가 발생했습니다.
- 리뷰 대기 PR이 쌓여 구현 담당자가 다음 작업으로 넘어가기 어려움
- 하루 작업의 대부분이 리뷰에 할애돼 자신의 업무가 뒤로 밀림
- 짧은 시간 안에 큰 규모의 PR을 리뷰해야 하므로 고품질의 리뷰를 수행하기 어려움
리뷰 요청이 일부 팀원에게 집중되는 취약성(single point of failure, SPOF)이 분명하게 드러난 상황이었습니다. 리뷰를 철저히 하면 품질은 높아지지만 개발 속도는 떨어지고, 효율을 우선하면 버그 누락이 늘어나는 ‘리뷰 효율과 품질의 트레이드오프’가 저희가 해결해야 할 과제였습니다.
이와 같은 상황에서 2025년에 Yahoo! 플레이스 리뉴얼 릴리스를 앞두고 프런트엔드 전문 팀이 출범했고, 이는 백엔드에서 겪었던 과제를 해결할 절호의 기회로 다가왔습니다.
지금까지의 내용을 타임라인으로 정리하면 다음과 같습니다.
- 2024년 후반
- Yahoo!플레이스 백엔드 개발 팀에서 테크 리드 담당
- 리뷰 대응 집중과 PR 정체 발생
- 리뷰 효율과 품질의 트레이드오프가 과제로 부상
- 2025년 전반
- Yahoo!플레이스 프런트엔드 팀 발족
- 프런트엔드 팀 발족을 리뷰 정체를 해결할 기회로 삼아 대응 시작
리뷰 정체를 해소하기 위해 AI 리뷰 지원 도입
Yahoo!플레이스의 프런트엔드 전문 팀을 출범하면서, 저희는 먼저 리뷰 프로세스를 체계화하는 일부터 시작했습니다. 2024년에 경험한 ‘리뷰 요청 집중’과 ‘코드 구현과 리뷰를 병행하는 어려움’ 같은 일을 반복하지 않으려면 체계를 갖출 필요가 있었기 때문입니다.
저희는 그 일환으로 AI를 활용한 리뷰 지원 도입을 검토했습니다.
처음 시도한 것은 PR 내용을 AI로 분석해 개요를 만들어 이를 바탕으로 리뷰하는 방식이었습니다. 시도 결과 변경 내용을 파악하는 것은 분명 쉬워졌지만 코드베이스를 따라 영향 범위를 조사하거나 잠재적 문제를 찾는 어려움은 크게 달라지지 않았습니다. 게다가 리뷰할 때마다 프롬프트를 AI에 붙여 넣어야 하는 일이 번거로워 약 2주 만에 사용하지 않게 되었습니다.
전환점은 2025년 여름 무렵 사내에 Claude Code가 도입되면서 찾아왔습니다. Claude Code는 특히 커스텀 명령어 기능이 매우 편리해서 리뷰용 명령어를 한 번 등록해 두면 매번 프롬프트를 준비할 필요가 없었습니다. 그 덕분에 AI를 활용한 스크리닝(screening) 리뷰가 현실적인 방식이 되었습니다.
AI 스크리닝 리뷰
AI 스크리닝 리뷰란 리뷰어가 본격적으로 리뷰하기 전에 AI가 사전 점검을 수행하는 것입니다.
기존 리뷰 프로세스에서는 리뷰어가 PR을 여는 순간부터 변경 내용 파악, 영향 범위 조사, 코딩 규칙 확인, 잠재적 문제 발견까지 모든 것을 처음부터 수행해야 했습 니다. AI 스크리닝 리뷰를 도입하면 AI가 이를 사전에 수행한 뒤 리뷰어에게 정리한 정보를 제공할 수 있습니다. 그 결과 리뷰어는 처음부터 이해하는 게 아니라 AI의 분석 결과를 확인하고 최종 판단을 내리는 방식으로 리뷰할 수 있게 됩니다. 기존의 ‘사람이 전부 보는 방식’에서 ‘AI가 1차 점검하고 사람이 최종 판단하는 2단계 방식’으로 전환함으로써, 리뷰어의 부담을 줄이면서도 품질을 유지할 수 있습니다.
AI 스크리닝 리뷰에서 사용한 Claude Code 커스텀 명령어
Claude Code 커스텀 명령어에서는 AI에 다음과 같은 지원을 요청합니다.
- 변경 내용과 영향 범위 자동 요약
- 코딩 규칙 및 명명 규칙 자동 확인
- 잠재적인 문제(버그나 성능 이슈) 지적
- 구현자에게 보낼 리뷰 코멘트 샘플 제안
저희는 AI가 단순히 사람의 판단을 대체하는 게 아니라 AI가 리뷰어의 사고를 지원하도록 만드는 데 주력했습니다. 프롬프트 설계와 코멘트 톤 최적화에 특히 시간을 들여서 팀 전체가 사용할 수 있는 수준으로 완성했으며, 특히 다음 세 가지에 신경썼습니다.
- 단계적인 리뷰 절차: ‘리뷰 요구 사항 확인 → PR의 전체적인 내용 파악 → 각 파일 상세 리뷰 → 코드베이스 전체 영향 조사 → 최종 판단’의 흐름으로 빠짐없이 리뷰
- 코드베이스 의존 관계 조사: 리뷰 대상 파일에 의존하는 다른 파일도 함께 확인해 이 수정 작업 때문에 문제가 발생하지 않는지 점검
- 리뷰어용 코멘트 제안: 지적 사항에 대해 리뷰어가 구현자에게 보낼 코멘트 문장을 구체적으로 제안해 리뷰 커뮤니케이션의 질을 향상
이 AI 스크리닝 리뷰는 리뷰어뿐 아니라 PR 작성자에게도 유효합니다. 리뷰어는 리뷰 시간을 단축하고 영향 범위를 파악하는 데 사용할 수 있고, PR 작성자는 리뷰 요청 전에 자체적으로 점검할 때 사용해 지적될 만한 부분을 사전에 해결할 수 있습니다.
결과적으로 리뷰에 소요되는 시간이 단축됐고, 구현에 집중할 수 있는 시간이 늘어난 것을 실감하고 있습니다.
Claude Code 커스텀 명령어 내용
실제로 사용하고 있는 리뷰용 커스텀 명령어는 다음과 같습니다(사외 공개용으로 일부 내용 조정). 커스텀 명령어 도입 방법은 Claude Code 문서를 참고하세요.
---
allowed-tools: Bash(git:*), Bash(gh:*), Read(*.md)
description: "인수로 지정한 PR을 리뷰합니다."
---
$ARGUMENTS를 리뷰해 주세요.
PR URL이 지정되지 않은 경우 현재 repository의 remote 정보와 current branch를 바탕으로 PR을 특정해 주세요.
또는 지정된 PR의 브랜치와 현재 브랜치가 일치하지 않는 경우 해당 브랜치로 checkout해 주세요.
만약 commit이나 파일 diff가 존재하면 중단해 주세요.
▼구체적인 절차
1. PR 내용과 현재 시점의 코멘트를 gh 커맨드로 가져와, 그 정보를 참고해 전체 개요를 설명한다.
・ 설명 내용: 어떤 배경이나 과제가 있어서 이렇게 변경했는지
2. 아래 항목에 대해 각 파일의 요약문을 표시한다.
・ before/after 수정 diff 해설
・ PR 목적에 비추어 적절한 수정인지 여부
3. 아래 항목에 대해 코드베이스를 확인한다.
・ 코드 스타일이 다른 파일과 동일한지
・ 리뷰 대상 파일에 의존하는 파일에서 변경 때문에 문제가 발생하지 않는지
4. 위 결과를 바탕으로 최종 리뷰 결과와 지적 사항을 표시한다.
5. 지적 사항에 대해 리뷰어가 구현자에게 보낼 코멘트 문장을 아래 조건에 따라 작성한다. (실제 전송 금지)
・ 구현자에 대한 존중을 잊지 않되, 문장은 짧고 간결하게 전달한다. 최대 3줄 정도
・ 코멘트 시작에는 라벨을 붙인다. 예: [must], [want], [imo], [ask], [nits], [info]
・ 파일 단위 코멘트를 우선하고, 코멘트를 표시할 위치를 명시한다.
・ 아래와 같은 경우가 발견되면 코멘트를 표시한다.
・ PR 목적에 부합하지 않는 구현
・ 보안 문제 발생
・ 코드 스멜 존재
・ 예상치 못한 부작용이나 기존 기능 파괴
・ API/DB를 불필요하게 호출, 처리 시간 증가, 메모리 누수 유발 요인 포함
・ 아래 케이스별로 섹션을 나눠 코멘트를 출력한다.
・ 수정 또는 확인이 필요한 부분
・ 수정은 필요 없지만 우려되는 부분
・ 테스트 추가 필요 여부는 코드베이스를 참고해 판단한다.
▼주의점
・ .github 폴더는 프로젝트 루트 바로 아래에 있습니다.
・PR 정보를 가져올 때는 아래 명령어를 모두 실행하는 것이 좋습니다.
・ PR 메타 정보: gh pr view --json title,body,files,url {pr_url}
・ PR 파일 diff: gh pr diff {pr_url}
・ PR 코멘트: gh pr view --comments {pr_url}
・ PR에서 파일 라인에 달린 코멘트 확인: gh api repos/{org}/{repository}/pulls/{prNumber}/comments | jq '.[] | {file: .path, user: .user.login, comment:.body}'
・ 파일 특정 라인에 코멘트하기: gh api \
repos/{org}/{repository}/pulls/{prNumber}/comments \
--raw-field body='[imo]\n이 줄의 처리는 조금 더 안전하게 작성할 수 있을 것 같습니다.'\
-f commit_id=$(git rev-parse HEAD) \
-f path='src/foo/bar.js' \
-F line=42 \
-F side=RIGHT
・ PR 브랜치 checkout: gh pr checkout {pr_url}
・ gh 명령 실행 시 author는 가져오면 안 됩니다.
・ 코멘트는 정중한 말투를 사용하고, 단정적인 표현은 피합니다. 예: “~처럼 보입니다”, “~일 수 있습니다”, “~라고 생각합니다”
스크리닝 리뷰에서 그치지 않는 리뷰 효율화 노력
AI 스크리닝 리뷰를 도입하고 어느 정도 성과를 거둔 후, 저희는 리뷰 효율을 더 높이기 위해 기술과 문화 양측에서 접근하는 통합 구조를 만들었습니다. 단순히 도구를 모으는 것이 아니라 ‘효율화의 핵심’ → ‘리뷰 정확도 향상의 기반’ → ‘문화 형성’ → ‘지속 개선 구조’라는 네 가지 축이 서로를 보완하는 패키지로 설계했습니다. 각 정책의 역할과 효과는 다음과 같습니다.
| 방법 | 주요 효과 | 역할 |
|---|---|---|
| AI 스크리닝 리뷰 | 리뷰 부담 절감 | 효율화의 핵심 |
| AI 기반 PR 작성 자동화 | 작업 효율화 및 정확도 향상 | AI 리뷰 정확도를 높이는 기반 |
| 리뷰 대기 알림 봇 | 누락 방지 및 촉진 | 문화 조성과 AI 활용 촉진 |
| 리뷰 효율 가시화 | 동기 부여 유지 | 지속 개선 및 팀 평가 |
정리하자면, 리뷰 정체를 해소하려면 아래와 같은 사이클로 지속적으로 개선하는 것이 중요하다고 판단했습니다.
AI로 PR 작성 자동화
PR을 작성할 때의 부담을 줄이기 위해 AI를 활용해 PR 작성을 자동화했습니다. 브랜치 생성과 커밋 생성, PR 생성에 이르는 일련의 Git 작업을 자동화하고, 더 나아가 AI가 아래 작업을 지원하는 방식입니다.
- 차분(diff)을 바탕으로 PR 설명 자동 생성: 커밋 차분을 분석해 변경 내용을 요약한 PR 제목과 설명문 생성
- 템플릿 자동 작성: PR 템플릿 항목(배경, 변경 내용 등)을 AI가 자동으로 채움
이를 통해 PR 작성자의 부담이 줄어들 뿐 아니라 PR 컨텍스트가 충실해져 AI 스크리닝 리뷰의 정확도도 높아집니다. 또한 PR 내용이 표준화되면서 팀 전체 리뷰 품질을 끌어올리는 효과도 있습니다.
Claude Code 커스텀 명령어 구현
실제로 사용하고 있는 리뷰용 커스텀 명령어는 다음과 같습니다(사외 공개용으로 일부 내용 조정).
---
allowed-tools: Bash(git:*), Bash(gh:*), Read(*.md)
description: "현재 브랜치의 코드로부터 PR을 생성합니다."
---
현재 브랜치의 코드로 PR을 생성해 주세요.
$ARGUMENTS에 대응 내용의 설명이 기재돼 있으므로 이 내용을 참고해 본문을 작성해 주세요.
기재가 없다면 파일 diff를 바탕으로 본문을 작성해 주세요.
▼구체적인 절차
1. PR 템플릿 파일이 있는지 확인한다.
・ 파일은 프로젝트 루트 또는 .github 폴더에 있으므로 해당 폴더를 확인한다.
2. 템플릿 파일 내용에 맞춰 본문과 PR 제목을 작성한다.
・ 현재 브랜치가 main 또는 develop 브랜치가 아닌지 확인한다. main 또는 develop 브랜치라면 브랜치를 생성한다.
・ 파일 변경이 있으나 commit되지 않은 경우, 관련 파일별로 commit한다.
・ PR 본문에는 해당 PR을 만들게 된 배경/과제와, 그에 대해 어떤 구현을 했는지를 간결하게 기재한다.
・ 템플릿이 없으면 뒤에 기재하는 PR 템플릿 포맷을 사용한다.
・ 본문과 제목을 작성한 뒤 사용자에게 보여 준다.
・ 사용자 승인을 얻기 전까지는 PR을 생성하면 안 된다.
3. 사용자 승인을 얻으면 PR을 생성한다.
・ 대상 브랜치가 remote repository에 존재하는지 사전에 확인하고, 없으면 push한다.
・ 명령 실행 전에 실행할 명령어를 사용자에게 보여 주고 최종 확인을 받는다.
・ 최종 확인이 되면 실행한다.
4. PR 생성이 완료되면 해당 PR의 URL을 표시한다.
▼PR 템플릿 파일
```markdown
# 개요
PR 내용을 한마디로 설명합시다.
## 배경이나 과제
PR을 만들게 된 배경이나 과제를 기재합시다.
# 구현 내용
배경이나 과제에 대해 어떤 구현을 했는지 항목 형태로 설명합시다.
```
리뷰 대기 알림 봇
리뷰 정체를 방지하기 위해 리뷰 대기 알림 봇을 도입했습니다. 이 시스템은 다음을 수행합니다.
- Slack 정기 알림: 리뷰 대기 중인 PR을 정기적으로 Slack에 알림
- 리뷰어 멘션: 할당된 리뷰어를 직접 멘션
- 정체 시간 표시: 각 PR이 얼마나 대기했는지 가시화
이 알림을 통해 리뷰 누락이 줄어들 뿐 아니라 ‘빨리 리뷰해 주자. 그 과정에서 AI 스크리닝 리뷰를 활용해 효율적으로 진행하자’는 문화가 형성됩니다. 또한 정기적인 알림은 팀 전체가 AI 리뷰를 활용하도록 뒷받침하고, 효율적인 리뷰 문화가 정착하도록 돕습니다.
리뷰 효율 가시화
개선 진행 상황을 정량적으로 파악하기 위해 리뷰 효율 가시화에도 힘썼습니다. 구체적으로는 PR 생성 후 48시간 내에 리뷰가 완료된 PR의 비율을 매주 계산해 팀과 공유하고 있습니다. 이 지표를 이용하면 리뷰 체계 개선이 어느 정도 효과를 내고 있는지 객관적으로 평가할 수 있습니다. 또한 가시화된 데이터는 팀의 동기 유지로 이어지고, 평가 프로세스에 반영되면서 지속적인 개선 사이클이 작동합니다. 성과가 수치로 보이기 때문에 ‘AI를 활용한 리뷰 개선이 실제로 효과가 있다’는 체감이 팀 전체에 공유되며 활동이 지속됩니다.
이와 같은 노력을 통해 기술 관점에서의 효율화뿐 아니라 팀 문화와 평가 구조까지 포함한 리뷰 프로세스 전체의 변화를 실현할 수 있었습니다. 또한 실전에서 얻은 지식을 사내에 확산하기 위한 워크숍 개최로 이어졌습니다.
'리뷰 정체를 해소하기 위한 AI와 체계화 실전 강의'를 주제로 첫 번째 워크숍 개최
워크숍 출범은 각 조직의 임원이 선발한 인원으로 구성한 Orchestration 길드의 정식 활동으로 시작됐습니다. Orchestration 길드에서는 전사적인 지식 공유와 실천 촉진을 목적으로 정기적인 워크숍 개최를 기획했는데요. 그 첫 주제로 ‘리뷰 정체를 해소하기 위한 AI 활용과 체계화 실전’을 다룬 계기는 Orchestration Development Workshop 프로젝트를 리드하는 DevRel 팀 Inoue 님의 제안이었습니다. Orchestration 길드 멤버 중에서도 리뷰 효율화에 적극적으로 힘써 왔던 제 경험이 첫 번째 주제로 적합하다고 판단돼 2025년 10월 30일에 Orchestration Development Workshop #1을 개최했습니다.
전체 엔지니어를 대상으로 한 이 워크숍에는 실시간으로 2,000명 이상이 참여했으며, ‘AI와 체계화로 리뷰 정체 해소’를 주제로 약 1시간의 프로그램을 진행했습니다. 목적은 AI 활용을 ‘남의 일’이 아니라 ‘우리 자신의 실천’으로 경험할 수 있는 장을 만드는 것이었습니다.
워크숍에서는 앞서 언급한 네 가지 방안을 다음과 같은 형식으로 소개했습니다.
| 방안 | 실천 방법 |
|---|---|
| AI 스크리닝 리뷰 | 핸즈온 |
| AI 기반 PR 작성 자동화 | 사례 소개 |
| 리뷰 대기 알림 봇 | 사례 소개 |
| 리뷰 효율 가시화 | 사례 소개 |
특히 핸즈온에서는 참가자들이 그 자리에서 직접 AI 스크리닝 리뷰를 체험할 수 있는 형식을 채택했습니다. 2,000명 이상이 참여한 대규모 워크숍이었지만 참가자 한 사람 한 사람이 직접 스크리닝 리뷰를 실행하고 AI가 생성한 리뷰 코멘트를 체험함으로써 ‘AI와 체계화를 결합했을 때의 효과’를 생생하게 느낄 수 있도록 했습니다.
워크숍을 마친 후 ‘우리 팀에서도 바로 써 보고 싶다’, ‘생각보다 쉽게 도입할 수 있을 것 같다’는 피드백을 받았고, 구현 방법이나 프롬프트에 대한 구체적인 질문도 많이 접수됐습니다.
워크숍 성과
워크숍 효과를 측정하기 위해 참가자를 대상으로 설문을 실시했습니다. 그 결과 AI를 활용한 코드 리뷰 지원의 활용 상황이 크게 변화했음이 분명해졌습니다.
| 활용 상황 | 워크숍 전 | 워크숍 후 | 변화 |
|---|---|---|---|
| 지속적으로 활용하고 있음 | 15.0% | 27.6% | +12.6pt |
| 일부 시험적으로 활용 중 | 30.0% | 40.9% | +10.9pt |
| 합계(어떤 형태로든 활용) | 45.0% | 68.5% | +23.5pt |
| 앞으로 사용해 보고 싶음 | 27.0% | 19.3% | -7.7pt |
| 활용 예정 없음 | 28.0% | 12.2% | -15.8pt |
주요 성과를 정리하면 다음과 같습니다.
- AI 활용률: 45.0% → 68.5%(+23.5포인트)
- 지속 활용자: 거의 두 배 증가(15.0% → 27.6%)
- 활용 예정 없음: 절반으로 감소(28.0% → 12.2%)
워크숍 이후 약 70%의 엔지니어가 어떤 형태로든 AI 리뷰 지원을 활용하게 되었고, 지속적으로 활용하고 있다’는 응답은 거의 두 배로 늘었습니다. 이는 체험형 접근을 통해 AI 리뷰의 효과를 체감하고 ‘우리 팀에서도 할 수 있다’는 확신을 얻었다는 것을 보여 줍니다.
또한 설문 코멘트란에는 ‘같은 문제 의식을 느끼고 있었고, 마침 해 보고 싶었던 내용이었다’는 의견이 다수 접수돼 많은 팀이 비슷한 고민을 안고 있음을 다시 한번 실감했습니다. 그 결과 여러 팀에서 AI 리뷰 지원을 도입했고 사내에서 AI 활용 사례로서의 인지도도 높아졌습니다.
이 성과는 사내에 그치지 않고, 2025년 10월 31일 자사 보도 자료(일본어)에도 소개됐습니다. 보도 자료에서는 사내 엔지니어 약 7,000명을 대상으로 한 ‘Orchestration 길드’ 활동 사례로 AI 코드 어시스턴트를 활용한 코드 리뷰 업무 최적화 소개됐습니다. 전사적인 AI 활용 추진의 일환으로 저희의 실천이 ‘생성형 AI를 전제로 하는 일하는 방식으로의 전환’의 구체적인 사례로 자리매김한 것은 이 활동의 의미를 다시금 실감하게 해 주는 계기가 되었습니다.
워크숍 진행 과정에서 얻은 인사이트
일련의 활동을 통해 AI를 활용한 개발 프로세스 개선에 대해 많은 것을 배웠습니다.
AI와 사람 간 역할 분담이 중요
무엇보다 AI와 사람 간 역할 분담이 중요하다는 것을 배웠습니다. AI는 코드 diff 분석, 영향 범위 조사, 잠재적 문제 지적과 같은 작업을 빠르고 폭넓게 수행할 수 있습니다. 반면 최종 판단이나 문맥을 고려한 의사결정은 사람이 수행합니다. 이렇게 명확히 역할을 분담함으로써 AI는 ‘사람을 대체하는 존재’가 아니라 ‘사람의 사고를 지원하는 파트너’로 기능합니다.
실제 운영에서도 다양한 형태로 이와 같은 역할 분담이 나타납니다. 예를 들어 AI가 제시한 코드 개선안을 리뷰어가 서비스 이용 상황이나 향후 확장성을 고려해 ‘현 시점에서는 필요하지 않다’고 판단하는 경우가 있습니다. 반대로 신규 기능 추가 리뷰에서는 성능 측면의 문제를 AI가 발견해 사전에 방지하는 경우도 있습니다.
더욱 흥미로웠던 점은 AI가 내놓은 결과를 출발점으로 한 대화를 통해 더 나은 해결책이 나온 사례였습니다. AI가 제안한 리팩터링안을 AI와 깊이 있게 논의하는 과정에서 원래 PR의 목적을 넘어 본질적인 개선으로 이어진 적도 있습니다. AI가 ‘정답을 제시하는 존재’가 아니라 ‘생각의 계기를 제공하는 존재’로 기능함으로써 엔지니어의 설계 역량이 성장하는 느낌을 받았습니다.
개발 문화의 변화
AI 도입은 기술 관점에서의 효율화뿐 아니라 팀의 개발 문화도 변화시켰습니다.
특히 인상적이었던 변화는 경험이 적은 멤버들이 리뷰에 참여하기 쉬워졌다는 점입니다. 이전에는 ‘내 지식으로는 부족하지 않을까?’하고 주저하던 멤버들도 AI의 지원을 받으면서 자신감을 갖고 리뷰 코멘트를 남길 수 있게 되었습니다. AI가 제안하는 리뷰 관점을 참고함으로써 점차 ‘무엇을 봐야 하는지’ 배울 수 있는 환경이 마련된 것입니다.
워크숍 이후 이전부터 AI 리뷰에 적극적으로 임해 온 분들을 인터뷰한 결과 AI 리뷰는 새로 배정된 개발자나 오랜 공백 후 복귀한 개발자의 조기 전력화에 효과적이라는 점도 알게 되었습니다. AI가 코드의 배경과 영향 범위를 요약해 주기 때문에 코드베이스에 익숙하지 않은 팀원도 빠르게 문맥을 이해하고 건설적인 리뷰 코멘트를 남길 수 있습니다. 이는 단순한 효율화를 넘어, 팀 전체의 지식 수준을 끌어올리는 데 기여하고 있습니다.
워크숍에서 배운 체험과 공유의 힘
워크숍을 통해 실감한 것은 체험과 지식 공유의 시너지 효과였습니다. AI 리뷰를 워크숍에서 참가자들이 직접 실행하고 체험하면서 훨씬 더 깊이 이해하게 됐고 도입 장벽이 크게 낮아졌습니다. 2,000명 이상이 참여하는 대규모 워크숍이었지만 각자 직접 명령어를 실행하고 AI 출력을 확인하면서 ‘우리 팀에서도 할 수 있다’는 확신이 생겼습니다.
워크숍 이후 설문에서도 ‘같은 문제의식을 느끼고 있었고, 마침 시도해 보고 싶었던 내용이었다’는 의견이 많이 접수돼 많은 팀이 비슷한 고민을 안고 있다는 점을 다시 한번 실감했습니다. 체험과 공유를 결합해 개인의 배움이 조직 전체의 지식으로 승화되어 가는 과정을 직접 목격한, 매우 값진 경험이었습니다.
이제 시작할 팀에게 추천하는 적용 방법
이 글의 내용을 한 번에 모두 도입하는 것은 쉽지 않기 때문에 저희 경험에 비춰 ‘우선 여기부터 시작하면 효과가 잘 나온다’고 느낀 단계를 세 가지로 정리했습니다.
- AI 스크리닝 리뷰 도입: 우선 리뷰어용 커스텀 명령어를 준비해 AI가 1차 점검하고 사람이 최종 판단하는 2단계 리뷰 형식을 만듭니다.
- PR 템플릿과 PR 자동 생성 정비: PR 템플릿을 정비해서 AI에게 PR 본문의 초안을 작성하게 합니다. 이를 통해 PR 컨텍스트를 표준화하는 동시에 작성 비용을 낮춥니다.
- 단순한 리뷰 지표 가시화: 처음부터 고도화된 대시보드를 만들 필요는 없습니다. ‘48시간 내에 리뷰 완료된 PR 비율’처럼 단순한 지표부터 시작해 효과를 확인합니다.
먼저 작게 이 세 가지를 시도해 보면서 각 팀에 맞는 형태로 커스터마이징해 가는 것을 추천합니다.
마치며: AI가 팀을 성장시키는 시대로
AI를 도입한 코드 리뷰 지원은 아직 발전 단계에 있지만, 현장에서 시행착오를 겪으며 ‘AI는 사람을 대체하는 것이 아니라 사람과 협업하는 것’이라는 개발 문화의 가능성은 실감하고 있습니다. 앞으로는 리뷰뿐 아니라 AI 코딩, 특히 질 높은 바이브 코딩(AI와 대화하며 코드를 작성하는 새로운 스타일)을 실천하는 방법도 확산해 나가고자 합니다. AI와 대화하며 코드를 작성하고 설계를 다듬어 가는 것, 이 새로운 개발 스타 일을 조직 전체가 익혀 나가는 것이 다음 단계라고 생각합니다.
AI 활용 방법을 모색하고 있는 분들에게 이 글이 좋은 참고 사례가 되기를 바랍니다. 완벽함을 목표로 하기보다는 작게 시작해 개선해 나가는 것, 그리고 무엇보다 ‘AI는 사람을 대체하지 않는다’는 신념을 계속 지켜 나가는 것이 성공의 열쇠라고 믿습니다.


