최근 몇 달 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