PR을 더 느리게 만들기 위한 고민

요약: AI 도입 이후 코드 생산 방식은 바뀌었으나 PR을 다루는 방식은 과거에 머물러있습니다. 이천 줄짜리 PR 앞에서 approve를 누르는 손이 망설여진 적 있다면 이 글이 도움이 될 수 있습니다.

시작하며

PR을 올렸다. 이틀째 리뷰가 안 온다. 슬랙에 리마인드를 보낼까 말까 고민하다가 그냥 다음 작업을 시작한다.

다음 날 approve(승인)가 왔다. 코멘트는 “LGTM(Looks Good To Me, 승인) 👍” 하나. 800줄짜리 PR인데.

잘 지시했으니 잘 만들었겠지. 그 생각이 리뷰를 생략하게 만든다. AI가 만든 코드는 쏟아지는데 그걸 이해하는 속도는 여전히 사람의 몫이다.

우리 팀도 같은 문제를 겪었습니다. 그리고 접근법을 바꿔보기로 했습니다.

1. 세상이 바뀌었다

1.1 바이브 코딩(Vibe Coding)에서 확장된 접근법

AI에게 원하는 것을 말하면 코드가 빠르게 나옵니다. 처음에는 그것만으로 충분했습니다.

프로젝트가 커지면서 문제가 생겼습니다. AI가 맥락을 모르면 엉뚱한 코드를 만들게 되고 같은 프로젝트인데 파일마다 스타일이 다르고 이미 있는 유틸리티를 또 만들고 팀 컨벤션을 무시하는 경우가 생겼습니다.

그래서 AI에게 맥락을 미리 알려주는 방식이 자리 잡고 있습니다.

• 프로젝트 구조와 규칙을 AGENTS.md에 정리하고
• 반복 작업 패턴을 SKILL로 문서화하고
• 위험 요소를 Harness(안전 장치)로 관리한다

이 Context(맥락 정보)를 AI에게 넘긴 뒤 Plan(구현 계획)을 세우고, Subagent(세부 작업을 담당하는 AI 에이전트)에게 코드 생산을 위임합니다. “만들어줘”에서 “이 맥락(플랜)에서 이 방식으로 만들어줘”로 바뀐 것이죠.

1.2 대량 생산 시대의 새로운 병목

효과는 체감되었습니다. 예전에는 하루 종일 걸리던 기능 구현이 한 시간 두 시간이면 PR로 올라오는 것을 목격하고 있습니다.

문제는 그다음입니다.

PR은 올라오는데 리뷰할 사람은 바뀌지 않았습니다. 아침에 출근하면 리뷰 요청이 쌓여있고 각각 수백 줄인 경우가 많았습니다. 내 작업을 하다가 리뷰하고 다시 돌아오면 컨텍스트를 잃어버리게 되죠. (aka. 어디까지 했더라…)

결국 두 가지 중 하나를 선택하게 됩니다.

• 꼼꼼히 보느라 PR이 며칠씩 열려있거나
• 빠르게 훑고 approve를 누르거나

많은 팀이 후자를 선택하고 있고 우리도 그렇게 하는 경우가 종종 있습니다.

코드를 만드는 속도는 AI가 해결했지만, 코드를 이해하는 속도는 여전히 사람의 한계 안에 있습니다. 병목이 한쪽으로 치우쳐졌습니다.

2. 우리도 그랬다

이번에는 데이터로 봐볼까요?

2.1 빨라진 생산, 멈춰있는 리뷰

AI 도입 전후 비슷한 규모의 두 프로젝트를 비교했습니다.

1인당 생산성이 2배. 그런데 머지까지 걸리는 시간은?

PR은 2배 빨리 올라오는데, 머지는 여전히 반나절이 걸립니다. 주 리뷰어 1명이 63%를 담당하고 있어서 머지 시간은 사람의 가용성에 바운드됩니다.

PR 수가 24 → 38건으로 늘어난 것은 속도만의 결과가 아니라 같은 규모를 더 작게 쪼갠 결과이기도 합니다. 이 차이는 3.1에서 다루겠습니다.

프로젝트 A(4h 17m)보다 프로젝트 B(5h 24m)의 리드타임이 더 긴 이유도 AI 때문이 아닙니다. 프로젝트 A는 2명이 교차 리뷰했고, 프로젝트 B는 1명이 개발하고 리뷰어도 1명이었습니다.

2.2 아무도 건드리지 않는 공통 영역

리뷰가 밀리면서 또 다른 문제가 생겼습니다.

공통 모듈을 고치는 PR은 영향 범위가 넓어서 리뷰 부담이 커졌습니다.

• 리뷰 부담이 크면 → 미뤄진다
• 미뤄지면 → 충돌이 쌓인다
• 충돌이 쌓이면 → 아무도 안 건드린다

결국 “건드리면 안 되는 영역”이 생기게 됩니다. 이건 기술부채가 아니라 리뷰부채로 변하게 됩니다.

2.3 리뷰가 형식이 되어가는 걸 아무도 말하지 않는다

다들 느끼고 있습니다. approve를 누르기 전 코드를 제대로 읽지 않았다는 걸 말이죠.

꼼꼼히 보고 싶어도 볼 수가 없습니다. 800줄짜리 PR을 제대로 읽으려면 한 시간 또는 그 이상 시간이 필요합니다. 변경된 파일 14개의 맥락 파악, 영향 범위 추적, 설계 의도 이해가 모두 필요합니다. 내 작업도 밀려있는데 그 시간을 내기가 어렵게 됩니다.

결국 타협하게 되는 자신을 발견합니다. 전체를 훑고 눈에 띄는 것만 코멘트하고 나머지는 적당히 보게 됩니다. 게으른 게 아닙니다. PR이 크면 사람이 소화할 수 있는 범위를 넘어서게 됩니다.

이게 반복되니 리뷰의 의미가 퇴색됩니다. 리뷰가 품질 게이트가 아니라 머지 전 형식적 절차로 변질되었습니다. “누군가 봤으니 괜찮겠지”라는 착각이 팀 전체에 퍼지게 됩니다.

그리고 정작 중요한 PR(설계 판단이 필요하거나 트레이드오프가 있는) 도 같은 무게로 취급됩니다. 전부 똑같이 가볍게 넘어가게 됩니다. 우리는 이것을 바라지 않았고 지금도 원하지 않습니다.

3. 알고 보니 AI가 해법이었다

3.1 task를 작게 쪼개는 일은 AI가 더 잘한다

프로젝트 B에서는 코드를 쓰기 전에 AI와 함께 설계 문서를 작성했습니다.

설계 문서 → Task 분해 → JIRA subtask → PR

결과:

200줄 이하 PR 비율: 37% → 60% 500줄 이상 PR도 있었지만, 비즈니스 코드만 보면 100~350줄이었고 나머지는 테스트 변경 사항이었습니다.

AI가 이걸 잘하는 이유가 뭘까 고민했습니다. 설계를 문서로 꺼내면 어떻게 분해할지 방향이 보입니다. 사람이 머릿속으로만 하던 것을 AI가 문서화하면 각각 독립적으로 리뷰할 수 있는 단위로 만들기 쉽습니다. 여기서 끝나지 않았습니다. AI는 분해된 Task를 의존성 기반으로 정렬하는 것도 잘합니다. “이 Task는 저 Task가 끝나야 시작할 수 있다”를 파악해서 독립적인 것은 병렬로 의존적인 것은 차례로 배치합니다. 10개 Task를 5개 Phase로 나누고 각 Phase 안에서 어떤 순서로 구현해야 하는지까지 설계 문서에 포함하게 했습니다.

결과적으로 설계 문서 하나에서 Task와 Subtask가 계층적으로 분류되고 구현 시작 순서까지 정해진 상태로 만듭니다. 사람은 이 문서를 보고 “맞는지” 판단만 하면 됩니다.

3.2 PR 템플릿의 재정의

PR 템플릿을 체크리스트가 아닌 의사결정 문서로 바꿨습니다.

# 해결하려는 문제가 무엇인가요?
# 왜 해야 하나요?
# 어떻게 해결했나요?
# 이 PR의 한계 & 트레이드오프
# 기존 기능에 미치는 영향
# Edge Case & 실패 시나리오
# 검토한 대안과 선택 이유
# 리뷰 포인트 (파일/영역별 Risk 🔴🟡🟢)

이 중에서 가장 중요한 항목은 “왜 해결해야 하나요?” 이 부분입니다.

AI가 코드를 빠르게 만들어주니까 “할 수 있으니까 한다”라는 PR이 늘어납니다. 리네임도 할 수 있고, 구조 개선도 할 수 있고, 패턴 통일도 할 수 있습니다. AI한테 시키면 30분이면 충분합니다. 간단한 기술부채로 쌓아두었던 것들을 손쉽게 해결할 수 있습니다.

그런데 “이게 지금 해야 하는 건가?”라는 의문을 남기게 됩니다.

“왜?”를 쓰는 행위 자체가 “이걸 지금 해야 하는가?”를 검증하는 과정입니다. 답이 궁색하거나 왜 해결해야 하는지에 대한 의도가 빈약하다면 이 PR은 지금 진행하지 않아도 될 지점일 수 있습니다. 이건 리뷰어가 아닌 작성자 자신에게 던지는 질문이어야 합니다.

AI 시대 이전에는 구현 비용이 높아서 자연스럽게 필터링이 되었던 부분입니다. 하루 걸리는 작업을 시작하기 전에 “이게 지금 필요한가?”를 고민했었고, 지금은 그 비용이 30분 ~ 1시간으로 줄었습니다. 필터링이 사라진 자리를 “왜?”가 대신하게 됩니다.

“왜?”가 작성자를 위한 것이라면 나머지는 리뷰어를 위한 것입니다. “한계 & 트레이드오프”는 어디를 집중해서 봐야 하는지 알려줍니다. 비어 있으면 판단할 게 없다는 뜻이고 채워져 있으면 사람이 봐야 한다는 신호로 작용합니다. “리뷰 포인트”는 15개 변경된 파일 중 어디가 위험한지 작성자가 먼저 표시합니다. 리뷰어의 시간은 존중되어야 합니다.

AI 코딩 도구가 코드를 만들면서 동시에 이 템플릿을 채웁니다. 플랜을 세우고 플랜에 따라 구현 과정에서 내린 결정들이 자연스럽게 PR에 녹아들며 문서화됩니다. 리뷰어는 코드를 읽기 전에 “왜 이렇게 했는지”를 먼저 이해할 수 있게 됩니다.

3.2.1 템플릿 활용 사례

3.3 AI 리뷰어 조르깃

조르깃(Jorgit)은 연구개발 망에 있으며 보안 규정을 준수하는 클라우드 서비스를 활용하고 있습니다.

이 jorgit은 PR이 열리면 4단계 멀티스텝 리뷰를 자동 수행하는 AI 리뷰어입니다. (프로젝트마다 다른 설정을 두고 있습니다.)

PR opened → Step 1: 언어 관점
          → Step 2: 프레임워크/인프라
          → Step 3: 도메인/보안
          → Step 4: 최종 검증 → 인라인 코멘트 + 요약

모든 코멘트에 심각도 태그를 붙입니다.

• [r] 꼭 반영해 주세요
• [c] 웬만하면 반영해 주세요
• [a] 사소한 의견입니다

실제 [r] 코멘트 예시:

r: 예외 처리 누락 — Redis LPUSH 실패 시 warn 로그만 남기고 있는데, 이는 장애 후 복구 메커니즘이 동작하지 않는 심각한 상황입니다.

3.3.1 조르깃 코멘트

PR 전체 리뷰

인라인 코멘트 리뷰

3.3.2 AI와 사람은 다른 것을 본다

AI는 구조적 이슈를 넓게 스캔했고, 사람은 비즈니스 맥락 기반의 질문과 토론에 집중했습니다.

188개 코멘트 중 16%(30건)가 코드 수정으로 이어졌습니다. AI가 2분 만에 예외 처리 44건, null-safety(null 예외 방어) 24건을 지적하니 사람 리뷰어는 코드를 한 줄씩 따라가며 누락을 찾는 작업에서 벗어날 수 있었습니다. 사람의 #예외처리 코멘트는 4건, #null-safety는 2건. 해석하고 사고해야 하는 지점을 AI가 대신 처리하니 사람은 업무적인 판단 “이 기능이 요구사항에 맞는가?”, “이 설계를 우리 도메인에서 수용할 것인가?”에 집중할 수 있었습니다.

반영률 16%가 낮아 보일 수 있습니다. 하지만 중요한 건 나머지에도 가치가 있다는 것입니다.

거절된 8%는 의사결정 기록이 되었습니다. “왜 이렇게 구현했는지” 근거를 명시적으로 남기면서 AI 질문이 자연스럽게 설계 문서화를 유도한 것입니다.

응답 없이 넘어간 68% 중에는 오탐지도 있고 맥락상 해당하지 않는 지적도 있었습니다. 전부 유의미한 건 아니었습니다. 하지만 그중 일부는 “인지하고 넘어간 것”이고 그 기록이 남는다는 점에서 가치가 있다고 판단됩니다.

3.4 AI 리뷰 위에 사람 리뷰를 얹는 구조

AI 리뷰어가 아무리 빨라도 사람의 승인 없이는 머지할 수 없는 팀 룰이 있습니다.

PR 생성
  ↓ (2분)
jorgit — 구조적 품질 스캔
  ↓
작성자 1차 피드백 반영
  ↓ (2h 50m)
사람 리뷰어 — 비즈니스 판단 + 최종 승인
  ↓ (2h 40m)
머지

AI 리뷰가 머지 시간을 단축해 주진 않았습니다. 머지 시간은 여전히 사람의 가용성에 달려있습니다. 대신 사람이 집중해야 할 영역을 좁혀줬습니다.

리뷰어 피드백을 기다리는 2~3시간 동안 AI 피드백을 반영하면 사람이 리뷰하는 시점에는 기계적인 검토 지점들이 이미 정리된 상태가 됩니다. 사람은 코드를 열자마자 PR의 본질적인 판단을 할 수 있게 됩니다.

AI 리뷰어는 사람을 대체하지 않습니다. 사람이 보기 전에 먼저 훑어주는 동료입니다.

4. 느린 PR이 빠른 개발이다

4.1 모든 PR을 같은 무게로 다루지 않는다

Q: "AI리뷰어가 approve 할 수 없다"라고 했다. 그렇다면 모든 PR에 같은 무게의 사람 리뷰가 필요한가?
A: 아니다. 구분 기준은 단순하다.

“왜 이렇게 했는가”에 대한 답이 자명한가?

리네임 PR 있다고 가정해 봅시다. “왜 state를 statusCode로 바꿨는가”의 답은 “프로젝트 컨벤션”에 속합니다. 판단이 아니라 확인이 되어야 합니다.

VO 분리 PR이 있다고 가정해 봅시다. “왜 PK 조회를 추가했는가?” 이 답은 “영속성 안전성 vs 성능 트레이드오프”에 속하게 됩니다. 확인이 아니라 판단이 필요합니다.

PR 템플릿의 “한계 & 트레이드오프” 섹션이 비어 있으면, 판단할 게 없다는 뜻이 됩니다. 채워져 있다면, 사람이 봐야 한다는 신호로 작용하게 됩니다.

4.2 의도적으로 속도를 조절하는 방법

빠르게 흘려보낼 PR과 붙잡을 PR을 나눴으면 붙잡는 쪽을 어떻게 다룰 것인지 생각해봐야 합니다.

PR을 올린 뒤 빠르게 승인받는 것을 목표로 하기보다 PR 생성 전 단계 즉, 플랜과 구현단계에서 충분히 고민하고 정리하는 것이 더 중요합니다.

책임의 위치를 PR 올리기 전으로 이동해야 합니다.

구체적으로:

1. 설계 문서가 PR보다 먼저 나온다. 코드를 쓰기 전에 “왜”를 정리해야 하며 AI가 이 과정을 도와줍니다.
2. PR 본문이 의사결정 문서다. 리뷰어가 코드를 읽기 전에 맥락을 이해할 수 있어야 합니다. PR 템플릿에 “한계 & 트레이드오프” 섹션을 추가하면, 이 섹션이 비어 있는지 채워져 있는지만으로 리뷰어가 자신의 시간을 어디에 쓸지 결정할 수 있습니다.
3. 리뷰 포인트를 작성자가 명시한다. 어디를 집중적으로 봐야 하는지 안내합니다. 리뷰어의 시간을 존중해야 합니다.
4. 작게 쪼갠다. 158줄짜리 PR은 30분이면 리뷰할 수 있습니다. 800줄짜리는 감이 안 옵니다. 1 subtask = 1 PR 규칙을 세우면 됩니다.
5. AI 리뷰어를 도입한다. 예외처리 누락, null-safety 같은 기계적 지적을 AI가 먼저 처리하면, 사람은 “이게 맞나?”에만 집중할 수 있습니다.

PR의 모든 단계를 빠르게 처리하려는 접근이 오히려 병목을 만들고 있었습니다. 일부 단계를 의도적으로 느리게 설계해야 합니다.

마치며

AI가 코드를 만드는 속도를 해결해 줬습니다. 하루 걸리던 구현이 한 시간이면 PR로 올라오는 시대가 되었습니다. 1인당 생산성이 최소 2배가 되었습니다.

그런데 그 속도가 리뷰를 형식적인 절차로 만들고 있었습니다. PR은 쌓이고 리뷰는 밀리고 approve는 “LGTM” 한 줄로 끝나고 있었습니다. 병목이 코드를 만드는 곳에서 코드를 이해하는 곳으로 이동한 것을 인지하면서 이 고민이 시작되었습니다.

처음에는 리뷰를 더 빠르게 하는 방법을 찾았습니다. 하지만 방향이 틀렸다고 생각했습니다. 빠르게 리뷰하는 게 아니라 리뷰하기 쉬운 PR을 만드는 것이 먼저였습니다. 사실 이건 새로운 이야기가 아닙니다. “커밋은 의미 단위로 묶으면서 작게 유지하고 PR 크기도 작아야 하며 설계 의도를 본문에 남겨야 한다.” - AI 도입 전부터 모두가 알고 있던 방향입니다. 다만 현실과 이상은 다르듯이 지켜지지 않았을 뿐입니다.

구현에 하루가 걸리는데 그걸 다시 쪼개고 정리하는 데 반나절을 더 쓰기 어려웠습니다. AI가 바꾼 건 이 비용입니다. 쪼개고 정리하는 일을 AI가 작업 전에 대신하면서 원래부터 지키고 싶었던 원칙이 비로소 실현 가능해졌습니다.

느린 PR이 빠른 개발이라는 역설은 모든 PR을 느리게 하자는 게 아닙니다. 느려야 할 곳을 알고 그곳에서만 멈추자는 것입니다. 나머지는 빠르게 흘려보내면 된다고 봅니다.

다음 단계도 생각해 볼 수 있습니다. 리네임 PR이 리뷰 대기로 하루를 보내는 걸 보면서 이 PR에 정말 사람의 눈이 필요했는가를 생각하게 됩니다. AI 리뷰만으로 머지 가능한 PR을 팀 규칙으로 정의하고 리뷰어의 역할은 “모든 코드를 읽는 것”에서 “트레이드오프에 동의하는 것”으로 재정의할 수 있습니다. 아직 시도 전이지만 방향은 정해졌다고 봅니다. PR을 빠르게 통과시키는 것이 목표가 아니라 PR 이전에 충분히 생각하고 트레이드오프를 고민하는 것이 이전보다도 더욱더 중요한 구조로 바뀌어야 합니다.