AI 생성 코드의 리뷰 소유권 설계

‘코드를 만들었는데 왜 아직 내 일이 남았을까?’ 생성과 소유의 경계

AI 코딩 도구가 함수, 테스트 초안, 리팩터링 제안, 풀 리퀘스트 설명까지 빠르게 만들면 팀은 쉽게 두 가지 착각에 빠집니다. 하나는 “모델이 만든 코드이니 사람의 책임은 줄었다”는 생각이고, 다른 하나는 “사람이 마지막에 한 번 읽었으니 책임이 생겼다”는 생각입니다. 둘 다 충분하지 않습니다. 책임은 키보드를 누른 사람에게 자동으로 붙는 이름표가 아니라, 변경이 깨뜨릴 수 있는 약속과 그 약속을 지키기 위해 확인한 근거를 설명할 수 있는 상태입니다.

GitHub는 Copilot의 에이전트·코드 리뷰 기능이 큰 변경이나 복잡한 코드에서 문제를 놓칠 수 있고, 잘못된 지적과 부정확하거나 안전하지 않은 제안이 나올 수 있다고 명시합니다. 따라서 AI 리뷰의 결과를 적용하기 전에는 신중한 인간 리뷰와 테스트가 보완돼야 합니다. 이 문장은 AI를 쓰지 말자는 경고가 아닙니다. 오히려 생성 속도가 빨라질수록 “검증을 누가 소유하는가”를 도구 기본값에 맡기면 안 된다는 운영 조건입니다.

Google Engineering Practices도 코드 리뷰의 중심을 문법 교정이 아니라 코드베이스의 장기적 건강에 둡니다. 변경의 설계가 맞는지, 사용자의 관점에서 기능이 타당한지, 테스트가 실제 고장을 잡는지, 동시성·보안처럼 전문 검토가 필요한 부분은 누가 맡는지를 보라고 권합니다. 이 기준은 AI 생성 코드에 더 중요해집니다. 생성 모델은 문맥을 넓게 흉내 낼 수 있지만, 우리 서비스가 지켜야 할 고객 약속과 예외 계약까지 자동으로 소유하지는 않기 때문입니다.

여기서 핵심은 AI가 만든 줄을 모두 의심하는 데 있지 않습니다. 어떤 변경이 어떤 증거 없이는 승인될 수 없는지를 미리 구분하는 데 있습니다. 그 구분이 없으면 속도는 늘어도 팀의 검토 대기열과 불확실성도 함께 커집니다.

‘리뷰어 한 명에게 모두 맡기면 왜 더 위험해질까?’ 변경을 네 개의 검증 경계로 나누는 법

AI 생성 변경은 표면상 작은 PR처럼 보여도, 여러 층의 가정을 한꺼번에 끼워 넣을 수 있습니다. 한 번의 제안 안에 API 계약 변경, 예외 처리, 권한 확인, 재시도 정책, 테스트 수정이 섞일 수 있다는 뜻입니다. 이때 “시니어 한 명이 꼼꼼히 보면 된다”는 방식은 확장되지 않습니다. 리뷰어는 줄 수가 아니라 위험 경계를 기준으로 역할을 나눠야 합니다.

첫째는 의도와 설계 경계입니다. 이 변경이 현재 제품 문제를 푸는가, 더 큰 추상화를 미리 끼워 넣지는 않았는가, 기존 모듈의 책임을 침범하지 않는가를 봅니다. 둘째는 계약과 데이터 경계입니다. API 호환성, 권한, 개인 정보, 데이터 마이그레이션, 결제·정산처럼 되돌리기 어려운 약속을 분리합니다. 셋째는 실행과 실패 경계입니다. 동시성, 재시도, 타임아웃, 리소스 상한, 롤백이 실제 실패에서 어떻게 동작할지를 봅니다. 넷째는 검증 경계입니다. 테스트가 단지 새 구현을 따라 쓴 것이 아니라, 잘못된 구현에서 실제로 실패하는지 확인합니다.

[AI 생성 패치]
       |
       +--> [의도·설계] ----> 변경의 목적과 모듈 경계
       +--> [계약·데이터] --> 호환성·권한·비가역성
       +--> [실행·실패] ----> 동시성·재시도·롤백
       +--> [검증] ---------> 실패하는 테스트·관측 신호
                                  |
                                  v
                         [승인 / 재작업 / 격리]

이 구조는 모든 PR에 네 명을 붙이라는 뜻이 아닙니다. 위험이 낮은 변경은 작성자가 짧은 근거를 남기고 일반 리뷰어가 확인할 수 있습니다. 반면 인증 흐름, 금액 계산, 대규모 삭제, 경쟁 상태가 있는 변경은 해당 경계를 이해하는 사람이 명시적으로 리뷰 범위를 맡아야 합니다. Google의 리뷰 가이드도 리뷰어가 자격을 갖추지 못한 영역이 있으면 보안·동시성·접근성 등 해당 전문성을 가진 검토자가 포함돼야 한다고 설명합니다.

그렇다면 리뷰 속도가 느려지는 것은 아닐까요? 오히려 불필요한 왕복을 줄일 수 있습니다. 저자는 PR을 열기 전에 “무엇을 바꾸는가”뿐 아니라 “무엇은 바꾸지 않는가”, “어떤 실패를 테스트했는가”, “언제 중단·롤백할 것인가”를 제출합니다. 리뷰어는 모델 출력의 모든 문장을 다시 작성하는 대신, 자신이 맡은 경계의 근거를 확인합니다. 의견이 취향인지 차단 조건인지도 분리됩니다.

‘테스트가 초록색인데 왜 승인할 수 없을까?’ 증거가 붙은 PR의 최소 단위

테스트 통과는 중요한 신호지만, 승인 그 자체는 아닙니다. 테스트는 설계된 조건만 검증합니다. 생성 도구가 테스트와 구현을 함께 바꾸면, 둘 다 같은 잘못된 가정을 공유할 수 있습니다. 그래서 시니어의 리뷰는 “테스트가 있나요?”에서 멈추지 않고 “이 테스트는 무엇이 망가지면 실패하나요?”까지 가야 합니다.

▲ 생성 코드의 최종 검토는 화면 속 제안 하나를 고르는 일이 아니라, 근거를 바탕으로 재작업과 릴리스 경로를 분리하는 공동의 판단이다.

이 표의 목적은 PR 템플릿을 길게 만드는 것이 아닙니다. 증거가 부족한 변경을 더 빨리 드러내는 것입니다. 예를 들어 단순 UI 문구 수정에 동시성 리뷰를 요구하면 비용만 늘어납니다. 반대로 권한 검증 함수를 AI가 공용 유틸로 바꿨다면, 코드가 짧아도 계약·보안·호환성 검토가 필요합니다. 리뷰 깊이는 코드 줄 수가 아니라 손상될 수 있는 약속의 크기에 비례해야 합니다.

여기서 커리어 차이가 생깁니다. 주니어는 생성 도구가 제안한 코드를 설명하는 연습을 통해 도메인과 실패 모드를 배웁니다. 시니어는 팀이 같은 설명을 반복 가능하게 하도록 PR 구조와 검토 경로를 설계합니다. Staff·Tech Lead는 이 경로가 병목이 되지 않게 위험 등급, 전문 리뷰 풀, 자동 검사, 예외 승인 규칙을 연결합니다. 즉 AI 시대의 성장 단위는 “더 많은 코드를 작성했다”가 아니라 “더 많은 사람이 안전한 변경을 설명하고 검증할 수 있게 했다”가 됩니다.

‘AI 리뷰가 있으니 사람 리뷰를 줄여도 될까?’ 자동화의 역할을 잘못 배치하는 안티패턴

첫 번째 안티패턴은 AI 리뷰를 최종 승인자로 쓰는 것입니다. AI 리뷰는 반복적인 실수, 스타일 불일치, 명백한 누락을 빨리 찾는 보조선으로 유용할 수 있습니다. 그러나 도구 제공자도 누락·오탐·불안전한 제안 가능성을 명시합니다. 자동화의 발견을 사람의 결정으로 바꾸는 연결 고리가 없다면, 팀은 경고 수를 늘렸을 뿐 품질을 높였다고 말할 수 없습니다.

두 번째 안티패턴은 사람 리뷰어가 생성된 코드를 처음부터 끝까지 손으로 재작성하는 것입니다. 이는 모델 사용의 이점을 지우고, 리뷰자의 주의를 줄 단위 작업에 소모하게 만듭니다. 대신 저자가 변경 의도와 실패 가설을 먼저 제시하고, 자동 검사는 기계적으로 확인 가능한 규칙을 맡고, 사람은 설계·계약·예외 판단에 집중해야 합니다.

세 번째는 “AI가 만들었으니 저자가 잘 모를 수 있다”는 이유로 소유권을 흐리는 것입니다. 이해하지 못한 변경을 병합하지 않는 것은 비난이 아니라 시스템 안전장치입니다. 저자가 설명할 수 없는 상태라면 생성 도구가 나쁜 것이 아니라, 변경 범위를 줄이거나 페어 검토를 붙이거나 실험 플래그 뒤로 숨길 때입니다.

두 스프린트 안에 리뷰 소유권을 작동시키는 3단계

도입 초기에 볼 지표는 자동 승인률이 아닙니다. 리뷰 대기 시간이 줄었는지, 반려 사유가 반복되는지, 배포 뒤 발견된 결함이 어떤 검증 경계를 빠져나갔는지, 저자가 변경을 스스로 설명할 수 있는지를 함께 봐야 합니다. DORA의 AI 지원 소프트웨어 개발 연구 역시 AI의 효과를 도구 도입 자체보다 이를 증폭하는 조직 역량과 함께 다룹니다. 즉 속도만 측정하면 팀의 품질·신뢰·협업 조건을 놓칠 수 있습니다.

AI는 코드를 더 빨리 제안할 수 있습니다. 그러나 고객과 운영 환경 앞에서 “이 변경을 왜 지금 배포해도 되는가”를 답하는 일은 여전히 엔지니어링의 중심입니다. 그 답을 특정 영웅의 직감에 두지 않고, 저자·리뷰어·전문가가 공유하는 증거와 경계에 남기는 팀이 AI의 속도를 지속 가능한 커리어 자산으로 바꿉니다.

AI 시대의 시니어 엔지니어는 더 많은 답을 생성하는 사람이 아니라, 팀이 어떤 답을 믿고 배포할지 판별하는 기준을 설계하는 사람이다.

공식 참고 자료

• GitHub Docs: Responsible use of GitHub Copilot agents
• GitHub Docs: About GitHub Copilot code review
• Google Engineering Practices: What to look for in a code review
• Google Engineering Practices: The Standard of Code Review
• DORA Publications: AI Capabilities Model and State of AI-assisted Software Development