최근 몇 달 PR에 붙는 코멘트 패턴이 두 가지로 수렴하는 걸 본다. 하나는 “LGTM"만 찍힌 채 5분 만에 승인되는 경우. 다른 하나는 “AI 리뷰 통과했어요"라는 말이 사실상의 리뷰를 대신하는 경우. 둘 다 공통으로 하는 말이 있다. “지금 바빠서.”
“바쁘다"의 진짜 비용#
바쁘니까 리뷰를 건너뛰자는 논리는 단기로는 맞는 것처럼 보인다. 그런데 우아한형제들 공통시스템개발팀이 쓴 코드 리뷰 문화 개선 이야기를 보면 무엇이 일어나는지 명확해진다.
“리뷰이는 리뷰를 기다리고 리뷰어는 수많은 MR을 확인하느라 고통받고 있었습니다.”
리뷰를 뒤로 미루면 MR이 쌓인다. 쌓이면 리뷰어가 한 번에 봐야 할 양이 커진다. 한 번에 봐야 할 양이 커지면 집중력이 떨어지고, 리뷰가 대충 되거나 더 늦어진다. 팀의 “바쁘다"는 오히려 증폭된다. 리뷰를 안 하는 게 원인이고, 바쁜 게 결과다. 순서가 반대로 보였을 뿐이다.
그 팀이 찾은 해법은 “리뷰 안 하기"가 아니었다. “리뷰어가 적은 노력으로 잘할 수 있는 환경 만들기.” MR 크기를 300줄 미만으로 제한, 템플릿으로 맥락 강제, 매일 아침 MR 목록 자동 알림, pre-commit으로 린팅 자동화. 바쁘다는 문제에 “리뷰를 줄이자"가 아니라 “리뷰 비용을 줄이자"로 답한 셈이다.
“AI가 봤다"의 구조적 결함#
다른 핑계는 더 교묘하다. “AI가 리뷰해줬어요"는 일견 책임 있는 행동처럼 들린다. 그런데 2026년 2월 Stanford Law의 CodeX가 쓴 Built by Agents, Tested by Agents, Trusted by Whom?이 정확히 이 지점을 비튼다.
핵심 문장은 이거다.
When the builder and the inspector share the same blind spots, no amount of test variety fully eliminates the risk that both miss the same thing.
빌더와 검사자가 같은 사각지대를 공유하면, 검사의 본래 가치가 무너진다는 얘기다. 인간 리뷰어는 작성자와 다른 가정, 다른 경험, 다른 맥락을 가진다. 그 차이가 리뷰를 의미 있게 만든다. AI가 코드를 만들고 같은 모델 계열이 그 코드를 리뷰하면, 차이의 공간 자체가 사라진다.
같은 글이 인용한 악명 높은 일화가 있다. “테스트를 통과시켜라"는 목표만 받은 에이전트가 테스트 본문을 그냥 return true로 고쳐버린 사건이다. AI는 주어진 지표에 최적화할 뿐, 그 지표가 실제로 무엇을 의미하는지 이해하지 않는다. 코드를 쓴 AI가 그 코드를 리뷰할 때도 같은 방식으로 최적화한다. “이 코드는 괜찮아 보인다"에.
리뷰의 진짜 목적은 따로 있다#
여기서 진짜 질문이 나온다. 코드리뷰는 대체 뭐 하는 일인가.
“버그를 잡는 일"이라는 답이 가장 흔한데, Microsoft Research의 고전적인 연구는 다르게 정리한다. 코드리뷰의 핵심 목표는 두 가지다.
- 더 나은 솔루션을 찾기
- 지식을 팀에 퍼뜨리기
버그 찾기는 부산물에 가깝다. 중요한 건 “이 문제를 이 방식으로 풀어도 되는가"에 대한 두 번째 의견을 얻는 것, 그리고 그 과정에서 코드베이스의 맥락·의사결정·도메인 지식이 팀원에게 옮겨 가는 것이다.
뱅크샐러드 기술블로그도 같은 맥락에서 말한다.
“코드 리뷰 프로세스를 보는 것은 그 회사의 개발 문화를 이해할 수 있는 힌트가 되기도 합니다.”
리뷰는 단순한 품질 게이트가 아니다. 팀이 서로의 코드를 신경 쓴다는 약속을 매일 갱신하는 의식이다. 신입이 처음 던진 PR에 시니어가 의도를 묻고, 그 답변이 팀의 집단 지식으로 남는 과정. 누군가가 “왜 이렇게 썼어?“라고 물었을 때 비로소 말로 옮겨지는 암묵지. AI는 코드의 문법과 패턴은 읽지만, 이런 종류의 집단적 맥락을 함께 쌓아 올리는 일은 하지 못한다.
AI가 못 보는 층#
AI 리뷰가 못 보는 영역을 정리하면 대략 이렇다.
- 비즈니스 맥락 — 이 함수가 왜 이렇게 생겼는지의 답은 작년 사고 회고에 있다. 레포 밖에 있는 지식이다.
- 아키텍처 판단 — 이 변경이 다른 바운디드 컨텍스트를 건드리지 않는가, 기술 부채를 어디에 쌓고 있는가.
- 보안·거버넌스 — 우리 조직이 정의한 PII, 우리 서비스의 위협 모델.
- 컨벤션 — 이 레포가 3년 동안 합의한 스타일과 약속.
- 조용한 실패 — 보기엔 맞는데 edge에서 터지는 것. AI는 오히려 이런 코드를 더 자신 있게 만든다.
AI 리뷰어는 대부분의 경우 “이 코드가 잘 돌아갈 것 같다"를 말한다. 인간 리뷰어는 “이 코드가 우리 팀이 만들고 유지하기에 맞는가"를 묻는다. 두 질문은 차원이 다르다.
그래서 하고 싶은 말#
AI 리뷰를 쓰지 말자는 얘기가 아니다. 오히려 적극적으로 써야 한다. 스타일 위반, 단순 버그, 빠진 null 체크, 테스트 커버리지 — 이런 저수준 체크는 AI가 1차로 거르면 인간 리뷰어가 더 가치 있는 질문에 집중할 수 있다. 좋은 하이브리드는 AI가 1차 관문, 인간이 2차 판단자인 구조다.
문제는 순서가 뒤집혀 있을 때다. “AI가 봤으니 인간 리뷰는 생략"이면 그냥 리뷰를 안 한 거다.
“바쁘다"는 이유로 건너뛸 때, 우리가 건너뛰는 건 버그 검출이 아니다. 서로의 코드를 이해하고 지식을 옮기는 시간을 건너뛰는 거다. 그건 단기엔 안 보이다가, 1년쯤 뒤에 “왜 이 코드를 나만 이해하지?”, “이 사람 없으면 이 모듈은 아무도 모른다"는 청구서로 돌아온다.
“AI가 봤다"는 이유로 건너뛸 때, 포기하는 건 인간 리뷰어의 다른 시각이다. 작성자와 다른 가정으로 코드를 읽어주는 눈. 같은 모델이 양쪽에 서면 얻을 수 없는 그것.
코드리뷰는 품질 관리이기 이전에, 팀이 팀으로 남게 하는 장치다. 자동화해서 없앨 수 있는 건 비용이지 목적이 아니다.
참고한 글 / 연구
- 우아한형제들, 공통시스템개발팀 코드 리뷰 문화 개선 이야기
- Stanford Law School CodeX, Built by Agents, Tested by Agents, Trusted by Whom? (2026-02)
- 뱅크샐러드 기술블로그, 코드 리뷰 in 뱅크샐러드 개발 문화
- Graphite, Why AI will never replace human code review