LLM Wiki

코드는 다 읽을 수 없고, 코드 리뷰가 맡아온 책임은 사라지지 않는다

Properties2
descriptionAI가 코드 생성 속도가 검증 속도를 추월한 시대에 코드 리뷰를 5단계 시스템으로 재분배하고 의도·맥락·증거·책임을 사람이 소유해야 한다는 GeekNews 종합 정리
tagsai-coding, ai-agents, dev-tools

18 min read

개요

GeekNews 아티클 https://news.hada.io/article/code-outruns-review는 AI가 만든 코드량이 사람의 리뷰 대역폭을 추월한 현재를 진단한다. Faros AI(4,000팀·22,000명) 관찰 데이터와 300개 프로젝트 54,330 PR 분석, 207개 프로젝트 102만 PR 분석을 교차하며, 리뷰를 “사람 vs AI 대결”이 아니라 하나의 PR에 뒤섞인 검증/유지보수성/지식공유/게이트키핑/책임분산 을 누구에게 어떻게 나눌지의 문제로 재정의한다. 결론은 코드를 전부 읽는 관행을 버리고 의도·맥락·증거·책임 네 가지를 사람이 소유하는 5단계 시스템으로 전환하자는 것이다. 2026-08-23-ai-era-code-review-guide와 함께 읽으면 실무 적용까지 연결된다.

AI가 만든 근본 변화 — 생성 속도 > 검증 속도

  • 코드 생성량은 늘었지만 이해·검증·승인 시간은 함께 늘지 않음. 격차가 가장 먼저 드러난 곳이 코드 리뷰다.
  • Faros AI 텔레메트리: AI 도입도 낮은 팀 → 높은 팀으로 갈수록 중앙값 리뷰 소요 441.5% 증가, 리뷰 없이 머지된 PR 31.3% 증가. 단, 인과를 입증한 실험이 아니라 관찰 데이터이며, 분석 글은 “의도적 생략”보다 “물량을 못 따라가 읽히지 않은 채 머지”로 해석한다.
  • 긱뉴스 댓글 사례: 에이전트가 쏟아내는 방대한 코드를 리뷰하는 데 지쳐간다는 피로감이 현장 댓글에서도 반복된다.
  • 흔들리는 원칙: 코드를 만든 사람이 전부 읽고 다른 사람이 다시 읽은 뒤에야 머지한다를 계속 지킬 수 있는가? 없앤다면 무엇으로 대체하는가?

코드 리뷰는 원래 버그 찾기가 아니었다

  • 좋은 리뷰 사례로 구글 Critique: 완벽한 코드 요구보다 코드베이스 조금씩 개선, 스타일 논쟁 자동화, 작성자·리뷰어 지식 나눔이 핵심이었다.
  • 안티패턴 사례로 코드 리뷰 안티패턴들: 사소한 지적을 하나씩 꺼내는 왕복, 설계 문제를 마지막에 제기, 충돌하는 요구를 작성자에게 전가하는 권력화.
  • Google 사내 연구 종합 — 리뷰가 맡아온 5가지:
    1. 결함 탐지 검증
    2. 이해 가능성 유지보수성 확인
    3. 관례·과거 결정 전달 지식 공유
    4. 받아들일 변경을 정하는 게이트키핑
    5. 판단을 분산하는 책임 분산
  • 기존에는 이 전부를 사람이 diff를 읽는 방식으로 처리해 왔다.

병목은 원래부터 타이핑이 아니었다

  • 코드 작성은 절대 병목이 아니었음 / 코드 작성 속도가 문제라면 더 큰 문제가 있다: 병목은 리뷰·테스트·디버깅·지식이전·협업이었다. 생성이 쉬워질수록 이해와 검증 비용이 선명해진다.
  • GitClear: AI 매일 사용자가 비사용자 대비 4배 원시 산출량이지만 1년 전 자신 대비 생산성은 12% 수준. 다만 원래 생산성 높은 개발자가 AI 집단에 더 많이 포함된 선택 편향 가능성 있다.
  • AI 시대의 코드 리뷰의 프레임: 빨리 만들었다는 건 완료가 아니라 작동 증거를 만드는 단계로 책임을 넘긴 것 — 입증 책임이 뒤로 이동한다.

AI를 센서로 붙이기 — 처리량 늘리기

AI와 사람은 다른 것을 본다 — 54,330 PR / 278,790 대화 분석

대상: 에이전틱 코드 리뷰에서 인간-AI 시너지(300개 프로젝트, PR 54,330·인라인 대화 278,790)[https://news.hada.io/topic?id=32449]

  • 표본 내 전체 리뷰의 55.7%를 AI 에이전트가 시작 — GitHub 전체 대표치는 아니지만 AI 리뷰 일상화의 신호다.
  • AI 코멘트 95%+는 코드 개선·결함 탐지 집중. 인간은 구현 의도 질문, 테스트 방식 확인, 저장소 관례·과거 결정을 대화로 가져온다.
  • AI는 코드 안에서 답 찾기 vs 인간은 코드 밖 맥락 가져오기.
  • 수치
    • 수정안 채택률: AI 16.6% vs 인간 56.5%
    • AI 시작 리뷰의 85%+는 첫 코멘트 후 추가 응답 없이 종료 — 대화가 이어지지 않음
    • AI 계정이 만든 PR을 인간이 리뷰하면 대화 평균 11.8% 길어짐 (에이전트 계정 기준이라 인간의 AI 보조 작성 코드 전체로 확대 불가)
    • 반영된 AI 수정안은 인간 수정안보다 코드 크기·분기 복잡도를 더 늘리는 경향
  • 해석: AI 리뷰는 판결보다 결함 후보를 넓게 탐지하는 센서에 가깝다. loop-engineering의 작성자/검증자 분리 원칙과도 맞닿는다.

빠른 결정이 좋은 리뷰가 아니다 — 102만 PR 분석

대상: 인간 중심에서 에이전틱 코드 리뷰로(207개 프로젝트, 102만 PR)[https://news.hada.io/topic?id=32454]

  • 점진적 도입·에이전트 등장 후 빠른 확대 그룹: 리뷰 결정 빨라짐
  • 초기 LLM 리뷰어를 대부분 PR에 일괄 적용한 그룹: 속도 개선 없고 리뷰 안티패턴 오히려 증가
  • 빨리 결론 낸 그룹에서도 논문이 쓴 리뷰 품질 대리 지표는 함께 좋아지지 않음.
  • 같은 리뷰어 조합 반복 비율: LLM 참여 프로젝트 평균 60% vs 사람만 16% — 모든 PR에 같은 모델을 붙이면 리뷰어 수는 많아 보여도 관점은 하나로 고정.
  • 두 연구 모두 관찰 연구이며 실제 장애·결함률 대신 대리 지표를 썼고 인과를 입증하지 않는다. 공통 경고는 분명하다: AI 리뷰어를 붙이는 것만으로 좋은 리뷰 시스템이 만들어지지 않는다.

모든 코드를 읽는 것 포기하자는 주장과 사라진 의도

  • 코드 리뷰를 없애는 방법: 체크포인트를 생성 이후→이전으로 이동. 사람은 수백 줄 diff 대신 스펙/계획/제약/수용 기준을 검토하고 코드는 계약의 산출물로 본다.
  • AI 시대에 코드 리뷰, 어떻게 해야 할까: 모든 코드 읽기 주장과 의도 중심 검토 이동 주장을 함께 놓고 논쟁을 정리한다.
  • 에이전틱 코드 리뷰: 사라진 의도 문제 — 사람이 쓰면 버린 대안이 머릿속에 남아 리뷰가 판단을 점검했지만, 에이전트 diff엔 시도·버린 이유가 남지 않아 리뷰어가 의도를 재구성해야 한다.
  • 풀 리퀘스트는 죽었다, 풀 리퀘스트 만세: 리뷰어가 라이브러리 선택 이유를 물으면 개발자가 AI에 다시 물어 전달하는 중개인 현상.
  • 해법: 모델 내부 사고 보관 아니라 도구 호출·검토 대안·테스트 결과·판단 근거를 외부 검증 가능한 결정 로그로 남기기. 왜 이렇게 했나를 물어야 한다면 로그에 구멍이 있다는 신호다.

그래도 사람의 읽기는 남는다

  • 코드 리뷰에는 읽기가 필요하다: 테스트·플래그·가드레일·관측가능성은 불안은 줄여도 팀이 함께 이해하는 일까지 대신 못 한다. 장애·보안·데이터 삭제 판단의 공동 책임 측면도 있다.
  • 코드 리뷰의 주된 목적은 유지보수하기 어려운 코드 찾기: 리뷰어가 모든 버그를 찾을 순 없지만, 리뷰어가 이해 못한 코드는 미래 유지보수자도 이해하기 어렵다. 읽기는 증명이 아니라 이해·인수 가능성 확인이다.
  • 책임 분배: 작성자는 목적·근거 설명 책임, 팀은 한 사람 실수가 장애가 되지 않는 검증·복구 시스템 설계 책임. 어느 쪽이든 주체는 사람이다.

코드 밖을 보는 능력은 배울 수 있다

대상: 코드 리뷰도 배워야 하는 기술이다 — LLM이 놓치고 인간이 잡은 3가지 실제 사례

  • 여러 프로세스가 ~/.gitconfig 동시 수정 시 잠금 충돌·과거 성능 문제
  • CI의 오래된 AWS CLI가 새 옵션 미지원인 버전 호환성
  • tarball과 checksum을 따로 갱신할 때 생기는 비원자적 상태

세 문제 모두 한 줄 더 꼼꼼히 읽기로 드러나지 않는다. 과거 장애 경험·실제 운영 버전·분산 실패 모델 같은 diff 밖 기억이 필요했고, 두 건은 해당 코드를 잘 아는 작성자의 PR에서 다른 사람이 발견했다. 필요한 사실이 저장소에 없어서라기보다 모델이 컨텍스트에 접근·연결을 못한 것일 수도 있다.

학습 방법:

  • 소크라테스식 리뷰: 시니어가 답을 바로 주기보다 가정·판단 근거를 먼저 묻는다
  • near-miss 공유: 리뷰에서 막힌 버그를 작성자가 설명해 팀 경험으로 남긴다
  • 분리된 모델링: 코드를 안 본 사람이 시스템 모델을 만들고 구현자와 테스트 케이스를 맞춰본다

사람에게 어려운 판단만 남길수록, 판단할 사람을 기르는 일 자체가 리뷰 시스템이다.

하나였던 리뷰를 5단계로 나누기

AI 시대에도 모든 변경을 같은 방식으로 리뷰할 필요는 없다. 역할별로 흐름에 나눈다:

  1. 만들기 전 — 의도와 경계 : 무엇을/왜/하지 말아야 할지를 사람이 결정. 스펙·설계·데이터 모델·성능·보안 경계·수용 기준을 먼저 검토.
  2. 만드는 동안 — 반복 검증 자동화 : 타입·린트·테스트·정적분석·보안 스캔 자동화. AI 설명보다 실제 명령·결과를 증거로 남기고 테스트 자체 오류 가능성도 확인.
  3. PR 시 — AI를 센서로 : AI 리뷰어가 결함 후보·중복·누락 테스트·의심 변경을 선별. 판결 대신 사람이 볼 위치를 알려주는 역할.
  4. 머지 전 — 위험 기반 인간 읽기 : 모든 줄에 동일 비용 금지, 틀렸을 때 비용으로 강도 결정
    • 일회성 스크립트·저위험 변경: 테스트 + AI 리뷰 중심
    • 오래 유지할 핵심 로직: 설계·유지보수성까지 사람 검토
    • 인증/결제/권한/데이터 삭제/인프라: 시스템 소유자 직접 확인
    • 테스트가 많이 바뀐 diff는 assertion까지 바꿨는지 테스트 변경부터 확인
  5. 배포 후 — 관측과 복구 : 기능 플래그·점진 배포·관측 가능성·빠른 롤백. 리뷰를 대체하는 장치가 아니라 리뷰가 놓친 문제를 받는 마지막 안전망.

2026-08-23-ai-era-code-review-guide는 이 5단계를 개인/소규모팀/조직별 체크리스트와 도입 로드맵으로 구체화한 파일드 가이드다.

인간이 최종 소유해야 하는 것

AI가 코드를 쓰는 시대, antirez는 왜 여전히 C로 만드는가에서 antirez는 아이디어를 통제하라고 말한다 — 매일 수천 줄을 읽기보다 설계·정신모델·테스트에 시간을 쓰라는 주장이다.

긱뉴스 댓글의 한 줄: 과거 PR은 내가 만든 결과물을 내가 책임진다는 느낌이었지만, Vibe coder의 PR은 "내가 뭘 만들었는지도 모르겠고 어쨌든 결과물은 있으니 니가 평가해 문제점을 찾아라" 같다.

AI 시대 리뷰에서 사람이 소유해야 할 네 가지:

  • 의도 — 올바른 문제를 풀고 있는가
  • 맥락 — 코드 밖 제약·과거 결정을 반영했는가
  • 증거 — 실제로 작동하고 실패에 대비했는가
  • 책임 — 문제 생겼을 때 설명하고 되돌릴 수 있는가

코드를 전부 읽을 수 없게 됐다고 책임까지 자동화된 건 아니다. 사라지는 건 리뷰가 아니라 모든 변경을 같은 사람이 같은 방식으로 읽던 관행이다. 리뷰는 코드 승인 절차에서 변경을 이해·검증·책임지는 시스템으로 바뀌고 있다.

관련 페이지

출처

백링크