--- type: WebPage title: 코드는 다 읽을 수 없고, 코드 리뷰가 맡아온 책임은 사라지지 않는다 description: "" resource: https://news.hada.io/article/code-outruns-review tags: [] timestamp: 2026-08-21T21:48:35.563813Z --- URL Source: https://news.hada.io/article/code-outruns-review Published Time: 2026-08-20T14:26:11+09:00 Markdown Content: **AI**가 소프트웨어 개발에 만든 가장 큰 변화는 코드를 더 잘 쓰게 된 것만이 아님 **사람이 코드를 읽고 검토할 수 있는 속도보다, 코드가 만들어지는 속도가 빨라진 것**이 더 근본적인 변화 그 격차가 가장 먼저 드러나는 곳이 **코드 리뷰** 코드 생성량은 늘었지만, 사람이 **변경을 이해하고 검증하고 승인하는 시간**은 함께 늘어나지 않음 이 변화는 일부 대규모 팀 데이터에서도 관찰됨 Faros AI가 4,000개 팀 22,000명의 2년치 텔레메트리를 분석한 결과, AI 도입도가 낮은 팀에서 높은 팀으로 갈수록 중앙값 리뷰 소요 시간은 **441.5% 증가**했고 리뷰 없이 머지된 PR도 **31.3% 증가**함 다만 이는 AI 도입이 변화를 직접 일으켰다고 입증한 실험이 아니라 개발 생산성 분석 업체가 수집한 관찰 데이터임 이를 분석한 글에선 리뷰를 생략하기로 했다기보다, 리뷰어가 늘어난 물량을 따라가지 못하면서 **읽히지 않은 코드가 머지되는 상황**으로 해석함 [에이전틱 코드 리뷰](https://news.hada.io/topic?id=30571)글 에서는 코드 생성량이 프로세스를 바꾸는 속도보다 빠르게 늘어난 결과로 이를 설명함 긱뉴스의 [한 댓글](https://news.hada.io/topic?id=32417#cid63373)에도 같은 장면이 보임 > 코드리뷰를 굉장히 좋아하는 편이었는데 에이전트가 쏟아내는 방대한 코드를 리뷰하는데에 지쳐갑니다 그동안 당연하게 여겼던 원칙이 흔들리기 시작함 > 코드를 만든 사람이 전부 읽고, 다른 사람이 다시 읽은 뒤에야 머지한다 이 원칙을 계속 지킬 수 있을까? 지킬 수 없다면 **코드 리뷰를 없애야 할까?** AI가 작성한 코드를 **다른 AI가 검토**하면 되는 걸까? 지난 몇 년간 긱뉴스에 올라온 **코드 리뷰** 글들과 최근의 대규모 연구를 함께 보면, 이 문제는 **사람과 AI 중 누가 더 잘 리뷰하는가**의 대결이 아님 하나의 PR에 뒤섞여 있던 **검증/이해/지식 전달/승인/책임**을 **누구에게 어떻게 나눌 것인가**의 문제에 가까움 ### 코드 리뷰는 원래 버그만 찾는 일이 아니었음 AI 이전에도 코드 리뷰는 완벽한 제도가 아니었음 [Critique - 구글이 개발자 만족도 97%로 코드 리뷰의 고통을 덜어주는 방법](https://news.hada.io/topic?id=12289)은 좋은 도구와 명확한 가이드가 리뷰 경험을 얼마나 바꿀 수 있는지 보여줌 완벽한 코드를 요구하기보다 **코드베이스를 조금씩 개선**하고, 스타일 논쟁은 **자동화**하며, 작성자와 리뷰어가 지식을 나누는 과정 반대로 [코드 리뷰 안티패턴들](https://news.hada.io/topic?id=16472)은 같은 제도가 어떻게 개발을 방해하는 권력으로 바뀌는지 보여줌 사소한 지적을 하나씩 꺼내 끝없는 왕복을 만들고, 설계 문제를 마지막에 제기하며, 서로 충돌하는 요구를 작성자에게 떠넘기는 등 좋은 코드 리뷰와 나쁜 코드 리뷰의 차이는 버그를 몇 개 찾았는지만으로 설명되지 않음 Google의 사내 연구와 이후의 논의를 합치면 리뷰가 맡아온 역할은 대략 다섯 가지로 정리됨 * 변경에서 결함을 찾는 **검증** * 다른 사람이 코드를 이해할 수 있는지 보는 **유지보수성 확인** * 프로젝트의 관례와 과거 결정을 전달하는 **지식 공유** * 무엇을 코드베이스에 받아들일지 정하는 **게이트키핑** * 문제가 발생했을 때 판단을 한 사람에게만 맡기지 않는 **책임 분산** 이 역할들을 **모두 사람이 diff를 읽으며 처리**해 온 것이 기존 코드 리뷰였음 ### 코드 작성이 빨라지자 원래의 병목이 드러남 [코드 작성은 절대 병목 지점이 아니었음](https://news.hada.io/topic?id=21799)은 소프트웨어 개발의 병목이 원래부터 타이핑이 아니라 리뷰/테스트/디버깅/지식 이전/협업에 있었다고 지적함 코드 생성이 쉬워질수록 **이해와 검증 비용**은 오히려 더 선명해짐 [코드 작성 속도가 문제라고 생각했다면, 더 큰 문제가 있는 것이다](https://news.hada.io/topic?id=27624)도 같은 문제를 조직 전체의 흐름에서 바라봄 한 단계의 생산량만 늘리면 리뷰 대기와 배포 지연이 커지고 전체 사이클 타임은 줄지 않을 수 있음 GitClear 데이터에서 AI를 매일 쓰는 개발자는 비사용자보다 약 **4배의 원시 산출량**을 냈지만, 1년 전 자신과 비교한 생산성 향상은 약 **12%** 였음 다만 **원래 생산성이 높은 개발자가 AI 사용 집단에 더 많이 포함**됐을 가능성이 있어, 이 수치에도 **선택 편향**이 남아 있음 기존 방식대로라면 늘어난 **코드의 검토 비용을 사람이 그대로 떠안는 구조** [AI 시대의 코드 리뷰](https://news.hada.io/topic?id=25625)에서는 이를 **입증 책임**의 문제로 정리함 코드를 빨리 만들었다는 것은 일을 끝낸 것이 아니라, **그 코드가 작동한다는 증거를 만드는 단계로 일을 넘긴 것**에 가까움 여기서 **AI를 하나 더 붙이는 접근**이 등장함 [AI 코드 리뷰: 작성자가 리뷰어가 되어도 될까?](https://news.hada.io/topic?id=20800), [Claude Code, 코드 리뷰 기능 공개](https://news.hada.io/topic?id=27362), [open-code-review - Alibaba의 AI 코드 리뷰 도구](https://news.hada.io/topic?id=30677)처럼 AI가 첫 검토를 맡는 도구나 방법이 계속 등장함 [코드 리뷰는 더 나아질 수 있음](https://news.hada.io/topic?id=22651), [Hunk - AI 에이전트 코드 리뷰를 위한 터미널 Diff 뷰어](https://news.hada.io/topic?id=29279)처럼 사람이 변경을 더 쉽게 읽게 만드는 인터페이스도 나옴 일부 도구는 실제 **리뷰 범위를 넓히기 시작**함 Anthropic 내부 측정에서는 실질적인 리뷰를 받는 PR 비율이 16%에서 54%로 늘었고, **GitHub 발표 기준으로는** 플랫폼 리뷰 5건 중 1건 이상에 에이전트가 관여함 코드가 많아지자 리뷰를 없애는 대신 **AI로 1차 리뷰의 처리량을 늘리는 단계**가 시작된 것 ### AI와 사람은 다른 것을 보고 있음 [에이전틱 코드 리뷰에서 인간-AI 시너지 - 인간과 AI는 다르게 리뷰한다](https://news.hada.io/topic?id=32449)는 300개 오픈소스 프로젝트의 PR 54,330개와 **인라인 리뷰 대화 278,790개**를 분석함 이 표본에서는 전체 리뷰의 **55.7%를 AI 에이전트가 시작**했음 GitHub 전체를 대표하는 수치는 아니지만, 적어도 이런 프로젝트에서 AI 리뷰는 이미 **일상적인 개발 과정의 일부**가 된 것 AI 리뷰 코멘트의 95% 이상은 코드 개선과 결함 탐지에 집중함 반면 인간은 **구현 의도**를 묻고, **테스트 방식을 확인**하며, **저장소 관례와 과거 결정**을 대화로 가져옴 AI는 **코드 안에서 답을 찾으려 했고**, 인간은 **코드 밖의 맥락을 가져왔음** * AI 리뷰어가 제안한 수정안의 채택률은 **16.6%**, 인간 리뷰어는 **56.5%** * AI가 시작한 리뷰의 85% 이상은 첫 코멘트 뒤 추가 응답 없이 종료 * 인간이 AI 에이전트 계정이 작성한 코드를 리뷰하면 대화가 평균 11.8% 길어짐 여기서 AI 작성 코드는 에이전트 계정이 만든 PR을 뜻하므로, 사람이 AI 도구를 이용해 작성한 모든 코드로 확대할 수는 없음 그래도 리뷰가 문제를 나열하는 일만이 아니라 **질문/반박/수정/확인**으로 이어지는 **대화**라는 차이는 드러남 실제로 반영된 AI 수정안도 인간 수정안보다 코드 크기와 분기 복잡도를 더 많이 늘리는 경향을 보였음 이를 실무적으로 해석하면 AI 리뷰는 판결보다 **결함 후보를 넓게 탐지하는 센서**에 가까움 ### 빠른 리뷰가 좋은 리뷰를 뜻하지는 않았음 [인간 중심에서 에이전틱 코드 리뷰로 - 더 빠른 결정이 더 나은 리뷰를 뜻하지는 않는다](https://news.hada.io/topic?id=32454)는 207개 프로젝트의 **102만 개 PR**을 인간 중심/LLM 보조/에이전틱 리뷰 시기로 나눠 분석함 AI 리뷰어를 점진적으로 도입했거나 에이전트 등장 이후 빠르게 확대한 프로젝트에서는 **리뷰 결정이 빨라짐** 반면 초기 LLM 리뷰어를 **대부분의 PR에 일괄 적용**한 프로젝트에서는 속도 개선이 없었고, 해당 그룹의 리뷰 안티패턴은 오히려 늘었음 빠르게 결론을 낸 프로젝트에서도 연구가 사용한 리뷰 품질 대리 지표는 함께 좋아지지 않음 LLM이 참여한 프로젝트에서는 같은 리뷰어 조합이 반복되는 비율이 평균 60%로, 사람만 참여한 경우의 약 16%보다 높았음 모든 PR에 같은 모델을 붙이면 리뷰어 수는 늘어난 것처럼 보여도 **관점은 하나로 고정될 수 있음** 두 연구는 모두 관찰 연구이며 실제 장애나 결함 발생률 대신 리뷰 과정의 대리 지표를 사용함 AI 도입이 결과를 직접 만들었다는 인과관계도 입증하지 않음 그럼에도 공통된 경고는 분명함 > **AI 리뷰어를 붙이는 것만으로 좋은 리뷰 시스템이 만들어지지 않음** 무슨 모델을 쓰는지만큼 어떤 변경에 배치하는지, 사람이 언제 개입하는지, 프로젝트 맥락을 어떻게 공급하는지가 중요함 ### 모든 코드를 읽는 것을 포기하자는 주장 AI가 작성하고 AI가 검토한 결과를 다시 사람이 전부 읽는다면 병목은 그대로 남음 [코드 리뷰를 없애는 방법](https://news.hada.io/topic?id=27546)은 인간의 체크포인트를 코드 생성 이후에서 이전으로 옮기자고 주장함 사람은 수백 줄의 diff보다 **스펙/계획/제약조건/수용 기준을 검토**하고, 코드는 이 계약에서 생성되는 산출물로 보는 방식 [AI 시대에 코드 리뷰, 어떻게 해야 할까?](https://news.hada.io/topic?id=27316)도 모든 코드를 읽어야 한다는 주장과 의도 중심 검토로 이동해야 한다는 주장을 함께 놓음 AI가 코드 생성량과 변경 빈도를 높였는데 리뷰와 테스트의 처리 속도가 그대로라면, 검증이 따라가지 못해 놓치는 변경이 늘어날 수밖에 없음 [에이전틱 코드 리뷰](https://news.hada.io/topic?id=30571)는 여기에 **사라진 의도**라는 문제를 추가함 사람이 코드를 쓰면 검토하고 버린 대안이 작성자 머릿속에 남아 있어 리뷰는 그 판단을 점검하는 일이었음 에이전트가 만든 diff에는 무엇을 시도했고 왜 버렸는지가 남지 않는 경우가 많아, 리뷰어가 기록되지 않은 의도를 다시 구성해야 함 [풀 리퀘스트는 죽었다, 풀 리퀘스트 만세](https://news.hada.io/topic?id=27700)는 이 문제가 리뷰 현장에서 나타나는 모습을 보여줌 리뷰어가 왜 이 라이브러리를 선택했는지 물으면 개발자가 AI에게 다시 물어 답변을 전달하고, 사람은 작성자가 아니라 **중개인**이 됨 해법은 모델의 내부 사고 과정을 보관하는 것이 아님 에이전트가 수행한 도구 호출, 검토한 대안, 테스트 결과와 최종 판단 근거를 **외부에서 검증 가능한 결정 로그**로 남기는 것 리뷰어가 "왜 이렇게 했나"라고 물어야 한다면 의사결정 로그에 빈 부분이 있다는 신호로 볼 수 있음 ### 그래도 사람의 읽기는 남음 의도와 테스트를 검토하면 사람은 코드를 읽지 않아도 될까 [코드 리뷰에는 읽기가 필요하다](https://news.hada.io/topic?id=30198)는 그렇지 않다고 답함 더 나은 테스트, 기능 플래그, 가드레일, 관측 가능성은 불안을 줄이지만 **팀이 변경을 함께 이해하는 일까지 대신하지는 못함** 리뷰는 장애/보안 문제/데이터 삭제에 대한 판단을 작성자 혼자 떠안지 않게 하는 과정이기도 함 [코드 리뷰의 주된 목적은 유지보수하기 어려운 코드를 찾는 것](https://news.hada.io/topic?id=31067)에서는 읽기의 목적을 조금 다르게 설명함 리뷰어가 코드만 보고 모든 버그를 찾을 수는 없지만, 리뷰어가 이해하지 못한 코드는 미래의 유지보수자도 이해하기 어려울 가능성이 큼 읽기는 무결성을 증명하는 행위가 아니라 **다른 사람이 이 변경을 이해하고 이어받을 수 있는지 확인하는 행위** **책임**은 작성자와 팀 중 하나만 고르는 문제도 아님 작성자는 **변경의 목적과 근거를 설명할 책임**이 있고, 팀은 한 사람의 실수가 곧 장애가 되지 않도록 **검증과 복구 시스템을 설계할 책임**이 있음 어느 쪽이든 **책임의 주체가 사람**이라는 전제는 바뀌지 않음 ### 코드 밖을 보는 능력은 배울 수 있음 [코드 리뷰도 배워야 하는 기술이다](https://news.hada.io/topic?id=32417)는 최신 LLM 리뷰가 놓치고 사람 리뷰어가 발견한 세 가지 실제 사례를 제시함 * 여러 프로세스가 `~/.gitconfig`를 동시에 수정할 때 생기는 잠금 충돌과 과거의 성능 문제 * CI에 설치된 오래된 AWS CLI가 새 옵션을 지원하지 않는 버전 호환성 문제 * tarball과 checksum을 따로 갱신할 때 두 객체 사이에 생기는 비원자적 상태 세 문제 모두 코드 한 줄만 더 꼼꼼히 읽는다고 쉽게 드러나는 유형이 아님 과거 장애 경험/실제 운영 버전/분산 시스템의 실패 모델처럼 **현재 diff 바깥의 기억**이 필요했음 세 사례 중 두 개는 **해당 코드를 잘 알던 개발자의 PR**이었고, 익숙한 작성자가 놓친 것을 다른 사람이 발견함 필요한 사실이 반드시 저장소에 없었던 것은 아님 리뷰 시점에 모델이 그 컨텍스트에 접근하거나 현재 변경과 연결하지 못했을 가능성도 있음 좋은 인간 리뷰어의 강점은 모든 줄을 더 정확히 읽는 능력만이 아니라, **어디가 위험한지 알고 코드에 적혀 있지 않은 질문을 꺼내는 능력** 그 능력 역시 저절로 생기지는 않음 **좋은 리뷰는 학습하고 가르칠 수 있는 기술**이며, 결과를 판정하는 자리가 아니라 **사고 과정을 공유하는 자리**로 만들어야 함 * 시니어가 답을 바로 알려주기보다 구현의 가정과 판단 근거를 먼저 묻는 **소크라테스식 리뷰** * 리뷰에서 막힌 버그를 작성자가 설명해 팀의 경험으로 남기는 **near-miss 공유** * 코드를 보지 않은 사람이 시스템 모델을 만들고 구현자와 테스트 사례를 맞춰보는 **분리된 모델링** 사람에게 어려운 판단만 남긴다면 그 **판단을 할 사람을 기르는 일도 리뷰 시스템의 일부**가 되어야 함 ### 하나였던 코드 리뷰를 여러 단계로 나누기 AI 시대에도 모든 변경을 같은 방식으로 리뷰할 필요는 없음 오히려 코드 리뷰가 맡던 역할을 **변경의 흐름에 맞춰 나누는 편이 현실적** 1. **코드가 만들어지기 전 - 의도와 경계** * 무엇을 만들지, 왜 필요한지, 하지 말아야 할 것은 무엇인지 **사람이 결정** * 스펙/설계/데이터 모델/성능 목표/보안 경계/수용 기준을 먼저 검토 2. **코드가 만들어지는 동안 - 반복 가능한 검증** * 타입 검사/린트/테스트/정적 분석/보안 스캔처럼 반복 가능한 검사는 자동화 * AI의 설명보다 실제 명령과 결과를 증거로 남기고, 테스트 자체가 잘못됐을 가능성도 함께 확인 3. **PR이 만들어질 때 - AI를 센서로 사용** * AI 리뷰어가 결함 후보/중복/누락된 테스트/의심스러운 변경을 먼저 선별 * 판결을 맡기기보다 사람이 신경써야 할 위치를 알려주는 역할 4. **머지하기 전 - 위험에 따라 사람이 읽음** * 모든 줄에 같은 검토 비용을 쓰지 않고 **틀렸을 때의 비용**으로 리뷰 강도를 결정 * 일회성 스크립트와 낮은 위험의 변경은 테스트와 AI 리뷰 중심 * 오래 유지할 핵심 로직은 설계와 유지보수성까지 사람 검토 * 인증/결제/권한/데이터 삭제/인프라는 시스템 소유자가 직접 확인 * 작성자가 사람인지 AI인지보다 **잘못됐을 때 어떤 일이 생기는지**가 리뷰 수준을 결정 * 테스트가 많이 수정된 diff에서는 새 동작에 맞춰 assertion까지 바꿨는지 테스트 변경부터 확인 5. **배포한 뒤 - 관측과 복구** * 기능 플래그/점진적 배포/관측 가능성/빠른 롤백을 함께 설계 * 배포 전 리뷰를 대신하는 장치가 아니라 리뷰가 놓친 문제를 받아내는 마지막 안전망 ### 인간이 최종적으로 소유해야 하는 것 [AI가 코드를 쓰는 시대, antirez는 왜 여전히 C로 만드는가](https://news.hada.io/article/antirez-controls-the-ideas)에서 antirez는 코드가 아니라 **아이디어를 통제**하라고 말함 생성된 코드를 매일 수천 줄씩 읽기보다 설계/정신 모델/테스트에 시간을 쓰자는 주장 그렇다고 코드가 더 이상 중요하지 않다는 뜻은 아님 모든 코드 줄에 똑같은 관심을 쓰지 말고, **중요한 결정과 실패 가능성에 사람의 주의를 집중하자**는 의미에 가까움 AI는 코드를 생성할 수 있고 다른 AI가 만든 코드에서 많은 결함을 찾을 수 있음 하지만 아무도 적지 않은 요구사항, 과거 장애가 남긴 경계, 조직이 감수할 수 있는 위험, 이 변경을 만들 가치가 있는지는 스스로 알 수 없음 장애가 발생했을 때 모델은 **온콜 담당자가 되어 장애 호출을 받고 대응할 수도**, 사용자에게 결정을 설명하거나 그 결과를 책임질 수도 없음 긱뉴스의 [한 댓글](https://news.hada.io/topic?id=27700#cid53512)은 이 변화를 짧게 정리함 > 과거 PR은 내가 만든 결과물을 내가 책임진다는 느낌이 있었지만, Vibe coder의 PR은 "내가 뭘 만들었는지도 모르겠고 어쨌든 결과물은 있으니 니가 평가해서 문제점을 찾아라" 같습니다 그래서 **AI 시대의 코드 리뷰**에서 사람이 **최종적으로 소유해야 할 것**은 모든 코드 줄이 아니라 다음 네 가지임 * **의도** - 올바른 문제를 풀고 있는가 * **맥락** - 코드 밖의 제약과 과거 결정을 반영했는가 * **증거** - 실제로 작동하고 실패에 대비했는가 * **책임** - 문제가 생겼을 때 이 변경을 설명하고 되돌릴 수 있는가 코드를 전부 읽을 수 없게 됐다고 해서 책임까지 자동화된 것은 아님 사라지는 것은 코드 리뷰가 아니라 **모든 변경을 같은 사람이 같은 방식으로 읽던 관행** **코드 리뷰**는 **코드에 대한 승인 절차**에서, **변경을 이해하고 검증하고 책임지는 시스템**으로 바뀌고 있음