코드 리뷰는 코드를 보는 일이 아니다

아침에 GitHub 알림을 열면 리뷰 요청이 줄지어 쌓여 있습니다. 양도 양이지만, 변경 규모가 예전과 다릅니다. 한 PR에 600줄, 800줄짜리 diff가 아무렇지 않게 올라옵니다. (작성자에게 물어보면 절반쯤은 에이전트가 만든 코드입니다.) 그런데 제가 그 PR을 리뷰하는 방식은 5년 전과 똑같습니다. 위에서 아래로 읽으며 오타와 버그를 찾고, LGTM을 누르죠. 결론부터 말씀드리겠습니다. 코드 리뷰의 초점을 문법과 결함 검출에서 의도·경계·시스템 영향으로 옮겨야 합니다. 검출은 기계에 넘기고, 사람은 기계가 못 보는 층을 봐야 합니다. 사실 코드 리뷰는 처음부터 코드를 읽는 일이 아니었습니다.

리뷰가 병목이 됐다

AI는 코드를 더 많이, 더 빨리 만듭니다. Stack Overflow의 2025 개발자 설문에서 응답자들은 자신이 커밋하는 코드의 약 42%가 AI의 도움을 받은 것이라고 답했습니다. 그런데 같은 조사에서 도구에 대한 신뢰는 오히려 떨어졌습니다. 쓰기는 어느 때보다 많이 쓰는데, 믿지는 못하는 상태. 이 간극이 전부 리뷰 단계로 떠넘겨집니다.

생산량이 늘면 품질도 같이 오를 것 같지만, 데이터는 반대를 가리킵니다. GitClear가 2억 1천만 줄 이상의 코드 변경을 분석한 2025년 보고서를 보면, 복사·붙여넣기로 분류된 코드는 2021년 8.3%에서 2024년 12.3%로 늘었고, 커밋 후 2주 안에 다시 손대는 코드의 비율은 3.1%에서 5.7%로 증가했습니다. 반대로 기존 코드를 옮기고 정리하는 리팩터링성 변경은 전체의 25%에서 10% 아래로 떨어졌습니다. 정리하면 이렇습니다. 코드는 쏟아지는데, 재사용과 정돈은 줄었습니다.

현장에서 이 변화는 한 가지 풍경으로 수렴합니다. 리뷰 큐는 길어지고, PR은 커지고, 사람은 지쳐서 LGTM을 누릅니다. 손은 키보드를 떠났는데, 눈이 감당해야 할 양은 폭증한 겁니다. ThoughtWorks는 2025년 기술 레이더에서 이 현상을 AI 생성 코드에 대한 안일함이라 부르며 ‘Hold’ 등급, 즉 신중히 다루라고 못 박았습니다. 문제는 분명한데, 정작 우리가 리뷰를 대하는 방식은 그대로입니다.

코드 리뷰는 원래 무엇이었나

해법을 찾기 전에, 코드 리뷰가 어디서 왔는지부터 짚어야 합니다. 코드 리뷰의 뿌리는 1976년 마이클 페이건이 IBM에서 정립한 코드 인스펙션입니다(Fagan, 1976). 결함을 가능한 한 이른 단계에서, 가능한 한 싸게 잡아내는 공정. 리뷰의 DNA는 처음부터 검사였습니다.

그런데 흥미로운 반전이 있습니다. 알베르토 바첼리와 크리스천 버드가 마이크로소프트에서 수백 개의 리뷰 코멘트를 직접 분류해 분석한 연구(Bacchelli & Bird, 2013)는, 개발자들이 “결함을 찾으려고” 리뷰한다고 말하지만 실제로 리뷰가 만들어내는 가치의 다수는 결함 검출이 아니라 지식 전달, 팀의 코드 인식, 그리고 대안 설계의 발견이라고 보고합니다. 그리고 리뷰의 가장 큰 난제로 지목된 것은 버그가 아니라 변경에 대한 이해(understanding)였습니다. 리뷰는 이미 오래전부터 검사보다 대화에 가까웠던 셈입니다.

게다가 사람을 결함 스캐너로 쓰는 일에는 명확한 물리적 한계가 있습니다. 스마트베어가 시스코에서 2,500건의 리뷰, 320만 줄을 분석한 고전적 연구를 보면, 한 번에 200~400줄을 넘기면 결함 검출률이 급격히 떨어지고, 60분이 지나면 리뷰어는 그냥 지쳐서 더 이상 결함을 찾지 못합니다. 우리는 600줄짜리 AI PR을 사람에게 던지면서, 사람이 결코 잘할 수 없는 일을 시키고 있는 겁니다.

그렇다면 사람이 잘하는 건 무엇일까요. 여기서 피터 나우르의 1985년 에세이 『프로그래밍은 이론 정립이다』가 결정적인 관점을 줍니다. 나우르는 프로그램의 본질이 코드 텍스트가 아니라 그것을 만든 사람들의 머릿속에 있는 이론이라고 봤습니다. 왜 이 구조를 택했는지, 무엇을 의도적으로 안 했는지, 어디를 건드리면 무엇이 무너지는지에 대한 살아 있는 모델 말입니다. 코드는 그 이론의 손실 압축된 투영일 뿐입니다. 이 구분은 의미심장합니다. AI는 투영(코드)을 능숙하게 만들어 내지만, 이론은 만들지 않기 때문입니다. 리뷰는 바로 그 빠진 이론을 다시 세우고 팀에 전달하는 자리입니다.

그래서 리뷰를 다시 설계한다

정리하면, 리뷰의 본질은 늘 이해의 전달이었고 결함 검출은 그 부산물이었습니다. AI는 이 사실을 가렸던 커튼을 걷어냈을 뿐입니다. 그러니 리뷰를 세 층으로 나눠 다시 설계하는 게 합리적입니다.

기계의 층. 포맷, 린트, 타입 체크, 테스트, 정적 분석, 보안 스캔, 그리고 AI 리뷰봇. 스타일과 명백한 결함, 컨벤션 위반은 전부 CI와 봇에게 넘깁니다. 사람이 세미콜론과 들여쓰기를 잡고 있는 건, 못 하나 박으려고 굴착기를 부르는 격입니다. 이 층은 자동화할수록 좋습니다.

사람의 층. 의도(왜 이 변경인가), 경계(이 변경이 닿는 시스템의 범위와 장애 반경), 도메인 적합성, 그리고 가역성(잘못됐을 때 되돌릴 수 있는가). 모든 테스트와 린트를 통과하지만 사람이 막아야 하는 것들이 여기 모입니다.

코드로 보겠습니다. AI가 만들고, 모든 정적 검사와 테스트를 통과하는 결제 처리 코드입니다.

def process_payment(order_id, amount):
    charge = payment_gateway.charge(amount)
    db.save_payment(order_id, charge.id)
    return charge

문법적으로 흠잡을 데가 없습니다. 봇도 통과시킵니다. 하지만 결제 도메인을 아는 사람이라면 즉시 멈칫합니다. 멱등성이 없습니다. 네트워크 타임아웃으로 클라이언트가 재시도하면, 같은 주문에 두 번 청구됩니다. AI는 정상 경로(happy path)를 그럴듯하게 짜는 데 능하지만, 재시도와 장애라는 현실의 경계는 도메인 맥락 없이는 보지 못합니다. 이건 문법의 문제가 아니라 의도와 경계의 문제이고, 정확히 사람의 층입니다.

여기서 한 가지 함정을 경계해야 합니다. 봇이 ‘OK’를 띄우면 사람도 ‘OK’를 누르기 쉽다는 것. 인지심리학에서 말하는 자동화 편향과 앵커링이 겹치는 지점입니다. 2025년 『AI & Society』에 실린 리뷰 논문은 자동화 편향이 앵커링 효과와 자주 맞물려, 초기 AI 제안이 이후 판단을 과도하게 끌어당긴다고 지적합니다. 봇의 통과는 출발점이지 결론이 아니라는 사실을 팀의 규칙으로 명시해야 하는 이유입니다.

세 번째 층은 더 근본적입니다. 제럴드 와인버그는 50여 년 전 에고리스 프로그래밍을 이야기하며, 리뷰는 사람이 아니라 코드를 검토하는 일이라고 했습니다. AI 시대에는 여기서 한 발 더 나가야 합니다. 검토 대상이 동료가 자기 이름을 걸고 쓴 코드가 아니라, 아무도 머릿속에 이론을 갖고 있지 않은 생성물일 때, ego는 빠졌지만 ownership도 함께 빠집니다. 그래서 저는 팀에 새로운 머지 기준을 둡니다. 이 변경을 작성자가 설명할 수 있는가. 작성자가 코드 뒤의 이론을 말로 풀어내지 못한다면, 그 PR은 아직 사람의 손을 거치지 않은 겁니다.

몇 년 전, 작은 익명 커뮤니티 서비스를 팀으로 만들던 시절이 떠오릅니다. 초기에는 코드 규칙이 잡히지 않아 머지할 때마다 충돌이 났고, 같은 패턴을 서로 다르게 짜는 통에 리뷰가 매번 싸움처럼 번졌습니다. 그때 리뷰를 결함 잡는 자리에서 기준을 합의하는 자리로 바꾸고 나서야 팀이 안정됐습니다. 돌이켜 보면 그 리뷰들의 진짜 산출물은 버그 수정이 아니라, 우리가 공유하게 된 판단의 기준이었습니다.

물론 트레이드오프가 있습니다. PR을 200줄 이하로 쪼개고 작성자에게 설명을 요구하면, AI가 한 번에 쏟아내는 속도를 의도적으로 늦추는 셈입니다. 단기 속도는 분명히 줄어듭니다. 하지만 앞서 이야기했던 코드 재수정 비율이 말해주듯, 검증을 건너뛴 속도는 2주 뒤 재작업으로 돌아옵니다. 속도의 청구서는 미뤄질 뿐, 사라지지 않습니다.

결론

코드 리뷰는 코드를 보는 일이 아닙니다. 코드 뒤에 있어야 할 이론과 의도를 보는 일입니다. 기계가 텍스트를 검사하는 능력이 좋아질수록, 사람의 리뷰는 검사에서 멀어지고 대화에 가까워집니다. 이건 리뷰가 약해지는 게 아니라, 원래 자리로 돌아가는 겁니다.

다음에 PR을 열 때, 첫 질문을 바꿔 보시기 바랍니다. “버그 있나”가 아니라, “이 변경을 작성자가 설명할 수 있나, 그리고 무엇이 무너질 수 있나.” 기계가 코드를 쓰는 시대에 사람이 지켜야 할 것은 문법이 아니라, 코드가 끝내 담지 못하는 이론입니다.

참고 자료

• Fagan, M. E. (1976). Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal.
• Bacchelli, A. & Bird, C. (2013). Expectations, Outcomes, and Challenges of Modern Code Review. ICSE / Microsoft Research.
• Naur, P. (1985). Programming as Theory Building.
• Weinberg, G. (1971). The Psychology of Computer Programming. (에고리스 프로그래밍)
• SmartBear / Cisco Systems. Best Kept Secrets of Peer Code Review (2,500 reviews, 3.2M LOC study).
• GitClear (2025). AI Copilot Code Quality Research — 4x Growth in Code Clones.
• ThoughtWorks Technology Radar (2025). Complacency with AI-generated code (Hold).
• Stack Overflow Developer Survey (2025).
• Hou & Zhang et al. (2025). Exploring automation bias in human–AI collaboration. AI & Society.