# 코드 리뷰를 없애는 방법 > Clean Markdown view of GeekNews topic #27546. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27546](https://news.hada.io/topic?id=27546) - GeekNews Markdown: [https://news.hada.io/topic/27546.md](https://news.hada.io/topic/27546.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-16T10:05:02+09:00 - Updated: 2026-03-16T10:05:02+09:00 - Original source: [latent.space](https://www.latent.space/p/reviews-dead) - Points: 62 - Comments: 25 ## Summary AI가 만든 코드가 폭증하면서 **인간이 모든 diff를 읽는 방식**은 이미 한계에 도달했습니다. 리뷰의 초점은 코드가 아니라 **스펙과 수용 기준**으로 이동하고, 인간은 코드 이후가 아니라 **코드 이전의 제약조건을 정의**하는 역할을 맡게 됩니다. 개발자는 더 이상 승인 게이트를 지키는 심사관이 아니라, 다층 검증 구조의 첫 번째 필터를 설계하는 사람이 되어야 합니다. ## Topic Body - AI가 생성하는 코드의 양과 규모가 기하급수적으로 증가하면서, 기존의 **수동 코드 리뷰 방식**이 더 이상 유효하지 않은 상황 - AI 도입률이 높은 팀은 작업 완료량이 21% 증가하고 PR 병합은 98% 늘었지만, **PR 리뷰 시간은 91% 증가**하는 역설적 현상 발생 - 코드를 직접 검토하는 대신 **스펙과 수용 기준(Acceptance Criteria)** 을 리뷰하는 상류 검증으로 인간의 역할이 이동해야 함 - 단일 검증 게이트 대신 다중 에이전트 경쟁, 결정론적 가드레일, BDD, 권한 시스템, **적대적 검증 등 스위스 치즈 모델** 기반의 다층 신뢰 구조 필요 - "빠르게 배포하고, 모든 것을 관찰하고, 더 빠르게 되돌리는" 방식이 **느린 리뷰 후 프로덕션 디버깅**을 대체하는 새로운 패러다임 --- ### 인간은 이미 코드 리뷰를 감당하지 못하고 있음 - PR이 며칠씩 방치되고, 형식적 승인이 이루어지며, 리뷰어들이 **500줄짜리 diff를 훑어보는 것**이 현실 - 코드 리뷰는 품질 게이트로 여겨지지만, 라인별 리뷰 없이 수십 년간 소프트웨어를 출시해 온 팀이 존재하며, 코드 리뷰가 보편화된 것은 **2012~2014년경** - 리뷰가 있어도 장애는 발생하며, 이에 대응해 **feature flag, 점진적 롤아웃, 즉시 롤백** 같은 시스템을 구축해 옴 ### 모든 코드를 읽는 것을 포기해야 함 - AI 도입률이 높은 팀에서 **변경 건수와 변경 크기** 두 가지가 동시에 기하급수적으로 증가 중 - 10,000명 이상의 개발자, 1,255개 팀 데이터 기반(Faros 분석) - 개발자들은 AI 생성 코드 리뷰가 동료 코드 리뷰보다 **더 많은 노력**이 필요하다고 체감 - 수동 코드 리뷰로는 이 싸움에서 이길 수 없으며, 코드 리뷰는 현재 작업 형태와 맞지 않는 **과거의 승인 게이트** ### AI 코드 리뷰도 여전히 '리뷰'일 뿐 - AI가 코드를 작성하고 AI가 리뷰한다면, 예쁜 리뷰 UI를 띄울 이유가 없음 - AI 코드 리뷰 도구는 시간을 벌어줄 뿐이며, 이러한 리뷰는 **개발 주기의 왼쪽(shift left)** 으로 이동하게 될 것 - CI 리소스를 낭비하고 리뷰 사이클 사이에 버전 관리를 할 이유 없음 - 에이전트가 코드를 작성하는 환경에서 "**새로운 눈**"은 같은 맹점을 가진 또 다른 에이전트일 뿐이며, 가치는 승인 게이트가 아닌 **반복 루프**에 있음 - "한 번 AI가 멍청한 짓을 하는 걸 봤으니 항상 확인해야 한다"는 본능은, 수동 검증이 가능했을 때는 합리적이었지만 현재 규모에서는 **더 이상 실행 불가능** ### 코드 리뷰에서 의도(Intent) 리뷰로 전환 - 인간의 체크포인트를 **상류(upstream)** 로 이동해야 함 - 소프트웨어 개발에서 체크포인트가 이동한 선례 존재: **워터폴 사인오프 → 지속적 통합(CI)** - **스펙 기반 개발(Spec-driven development)** 이 AI 협업의 주요 방식으로 부상 중 - 인간은 스펙, 계획, 제약조건, 수용 기준을 리뷰해야 하며, 500줄짜리 diff를 리뷰할 필요 없음 - 새로운 패러다임에서 **스펙이 진실의 원천(source of truth)** 이 되고, 코드는 스펙의 산출물 - 코드를 리뷰하는 것이 아니라 단계(steps)와 **검증 규칙(verification rules)**, 코드가 이행해야 할 계약(contract)을 리뷰 - Human-in-the-loop 승인이 "이것을 올바르게 작성했는가?"에서 **"올바른 제약조건으로 올바른 문제를 풀고 있는가?"** 로 전환 - 가장 가치 있는 인간의 판단은 코드 생성 이후가 아닌 **첫 번째 줄이 생성되기 전**에 발휘됨 ### 다층 신뢰 구축 — 스위스 치즈 모델 - LLM은 명령을 잘 따르지 않고 빈번히 이탈하며, **자기 검증에도 신뢰할 수 없음**(코드가 타는 중에도 자신 있게 "작동한다"고 답변) - 해결책은 LLM에게 검증을 요청하는 것이 아니라, **검증하는 스크립트를 작성하게** 하는 것 — 판단에서 산출물로 전환 - 신뢰는 층층이 쌓이는 구조이며, **스위스 치즈 모델**에 따라 불완전한 필터를 겹겹이 쌓아 구멍이 정렬되지 않도록 함 #### Layer 1: 다중 옵션 비교 - 하나의 에이전트에게 정답을 요구하는 대신, **세 개의 에이전트가 서로 다른 방식으로 시도**하고 최선의 결과를 선택 - 선택은 수동일 필요 없으며, 가장 많은 검증 단계를 통과하는 것, 가장 작은 diff, **새로운 의존성을 추가하지 않는 것** 등 기준으로 순위 매김 가능 - 옵션의 비용이 소프트웨어 엔지니어링 역사상 **가장 낮은 수준** #### Layer 2: 결정론적 가드레일 - 작업을 검증하는 **결정론적 방법** 필요 — 테스트, 타입 체크, 계약 검증 등 의견이 아닌 사실만 다루는 것 - LLM에게 "이거 됐어?"라고 묻는 대신, 일련의 **pass/fail 산출물**을 생성하는 검증 단계를 정의 - 가드레일의 계층 구조: - **코딩 가이드라인** — 커스텀 린터로 구현 가능 - **조직 전체 불변 규칙** — 하드코딩된 자격증명, API 키, 토큰 금지 등 비협상 사항 - **도메인 계약** — 프레임워크, 서비스, 코드베이스 영역별 규칙 (예: 결제 도메인에서 모든 금액은 Money 타입 사용) - **수용 기준(Acceptance Criteria)** — 작업별 고유 기준 - 검증 단계는 코드 작성 전에 정의되어야 하며, 이미 있는 것을 확인하기 위해 사후에 만들면 안 됨 - 에이전트가 코드와 테스트를 모두 작성하면 **문제를 이동시킨 것**에 불과하며, 검증 기준은 구현이 아닌 **스펙에서** 나와야 함 #### Layer 3: 인간이 수용 기준을 정의 - 인간이 가치를 더하는 지점은 **상류에서 성공의 정의를 내리는 것** - **BDD(Behavior-Driven Development)** 가 새롭게 관련성을 가짐 - 자연어로 기대 행동을 기술하고 이를 테스트로 자동화하는 방식 - 과거에는 코드도 작성해야 했기에 스펙 작성이 추가 작업처럼 느껴졌지만, 에이전트 환경에서는 **스펙이 1차 산출물** - 인간이 스펙을 작성하면 에이전트가 구현하고, **BDD 프레임워크가 검증** — 실패하지 않는 한 구현을 읽을 필요 없음 - 인간이 잘하는 일: "**올바름**"의 정의, 비즈니스 로직과 엣지 케이스의 인코딩, 잘못될 수 있는 것에 대한 사고 - 인간이 작성하고 기계가 검증하는 **수용 기준이 실제로 중요한 게이트** #### Layer 4: 권한 시스템을 아키텍처로 - 에이전트가 무엇을 건드릴 수 있고 무엇이 **에스컬레이션**을 필요로 하는지가 아키텍처 결정이 되어야 함 - 대부분의 에이전트 프레임워크는 권한을 **올오어낫싱(all-or-nothing)** 으로 처리하지만, 세분화가 중요 - 유틸리티 함수 버그를 수정하는 에이전트에게 인프라 설정 접근 권한이 불필요 - 테스트 작성 에이전트에게 CI 파이프라인 수정 권한이 불필요 - 범위는 에이전트가 유용한 작업을 할 수 있는 한 **최대한 좁아야** 함 - 예: "utils/dates.py의 날짜 파싱 버그 수정" 작업이면 **해당 파일과 테스트 파일만** 접근 허용 - **에스컬레이션 트리거**도 중요: 인증 로직 수정, 데이터베이스 스키마 변경, 새 의존성 추가 등 특정 패턴은 에이전트의 확신도와 무관하게 **자동으로 인간 리뷰를 트리거** #### Layer 5: 적대적 검증 - 책임 분리: 하나의 에이전트가 작업하고, **다른 에이전트가 검증** — 서로를 신뢰하지 않는 것이 핵심 - QA 팀이 엔지니어링 매니저에게 보고하면 안 되고, 코드 작성자만이 리뷰하면 안 되는 것과 같은 **오래된 패턴** - 아키텍처적으로 강제 가능: 코딩 에이전트는 검증 에이전트가 무엇을 확인할지 모르고, 검증 에이전트는 코드를 수정할 수 없음 — **설계상 적대적** - 더 나아가 세 번째 에이전트가 첫 번째 에이전트가 만든 것을 **엣지 케이스와 실패 모드를 겨냥해 파괴 시도** — 레드팀/블루팀 자동화를 모든 변경에 적용 ### "좋은 코드"의 의미가 변하고 있음 - 에이전트 시스템의 인센티브는 단순: 주어진 작업을 완료하고, 지시한 사람을 만족시키는 것 — 장기적 정확성이나 **비즈니스 요구사항이 본질적 동기가 아님** - 이를 **제약조건에 인코딩하는 것**이 인간의 역할 - 에이전트가 생성하고 에이전트가 읽는 코드에서 "좋은 코드"의 형태는 **더 표준화**될 것이며, 새로운 코드베이스에서 제공해야 할 방향이 줄어듦 - 미래의 방향: "**빠르게 배포하고, 모든 것을 관찰하고, 더 빠르게 되돌림**" - 반대: "느리게 리뷰하고, 어차피 버그를 놓치고, 프로덕션에서 디버깅" - 기계를 더 많이 읽어서 이길 수 없으며, 결정이 실제로 중요한 **상류에서 기계를 능가하는 사고**가 필요 - 에이전트가 코드를 잘 처리할 수 있다면, 인간이 그 코드를 읽을 수 있는지 여부는 **더 이상 중요하지 않음** ## Comments ### Comment 53137 - Author: shlee1503 - Created: 2026-03-16T17:40:40+09:00 - Points: 5 코드 리뷰가 병목이니 리뷰를 하지 말자고 하는건 신박해서 웃기네요 ㅋㅋㅋㅋㅋㅋ ### Comment 53085 - Author: bbulbum - Created: 2026-03-16T10:27:54+09:00 - Points: 5 AI 이전에는 다들 코드리뷰가 잘 동작했는지가 궁금하네요. 코드리뷰를 빠르게 열심히 하는 조직은 굉장히 드물었거든요. 많은 개발자들이 AI 이전에도 코드리뷰가 게을렀고 밀렸고 엉성했어요. ### Comment 53090 - Author: snisper - Created: 2026-03-16T10:55:02+09:00 - Points: 2 - Parent comment: 53085 - Depth: 1 경험해본 바로는 미국 테크기업은 정석대로였고, 국내 포함 해외는 엉망이었습니다. 반대로 말하자면 리뷰가 철저할수록 업무스트레스가 심했고, 엉망인 리뷰는 상대적으로 널널 ### Comment 53188 - Author: hanje3765 - Created: 2026-03-17T10:58:47+09:00 - Points: 4 리뷰가 없어지는건 행동 보상의 결과라고 생각됩니다. 회사에서 요구하는게 낮은 에러율이라면 리뷰를 더 강력하게 요구할꺼고 빠른 기능 출시라면 리뷰는 점차 생략되겠죠 리뷰가 사라진다는 얘기는 기업에서 선호하는게 빠른 기능 출시라고 느껴지네요 근데 제가 투자자라도 그렇게 요구할 것 같습니다 허허 ### Comment 53114 - Author: vk8520 - Created: 2026-03-16T13:18:05+09:00 - Points: 4 잘 모르겠네요. 리뷰가 병목이 되었다고, 리뷰를 하지 말라고 하는 건 본분을 잊은 거 같다는 생각이 드네요. 차라리 구현시간이 준만큼 리뷰 시간을 의무적으로 할당하는게 좋은 방법이 될거라는 생각이 듭니다. ### Comment 54696 - Author: conpages - Created: 2026-04-05T20:45:38+09:00 - Points: 1 해볼만한 생각이긴 한데 아직은 이르다는 시각이 지배적인 것 같네요 ### Comment 53130 - Author: moregeek - Created: 2026-03-16T16:17:32+09:00 - Points: 3 블랙박스를 계속 쌓자고? ### Comment 53123 - Author: ahwjdekf - Created: 2026-03-16T15:06:44+09:00 - Points: 3 코드는 그냥 블랙박스처럼 만들어놓고 결과만 보자.. 뭐 이런건데...과연 이게 바람직한 방향일지.. 저는 언젠가 분명 기존 ai 작성 코드 다 뒤집어 엎는 시간이 올거라고 봅니다. ### Comment 53214 - Author: dhlee0305 - Created: 2026-03-17T14:29:49+09:00 - Points: 2 "FSD가 똑똑해졌으니 운전자는 잠자도 된다."라는 것과 비슷하게 생각해 볼 문제네요. 기술적으로는 점점 그런 시대가 올 것 같긴 한데 과연 책임이라는 턱을 어떻게 넘을 것인가가 중요할 듯 합니다. 전 코드리뷰가 최소한의 안전장치 아닐까 싶습니다. ### Comment 53211 - Author: brilliant08 - Created: 2026-03-17T14:19:07+09:00 - Points: 2 더 상위 개념이라는 의도 검증은 왜 사람이 하나요..? ### Comment 53144 - Author: adieuxmonth - Created: 2026-03-16T19:34:53+09:00 - Points: 2 사실 프로그래밍 언어로 코딩 시킬 필요도 없죠 ### Comment 53120 - Author: ewpes - Created: 2026-03-16T14:23:02+09:00 - Points: 2 Ai에 동일 프롬프트를 전달한다고 했을때, 그 결과물을 리뷰한다는건, 모델의 성능을 테스트하는 것과 비슷하지 않나 라는 생각이 드네요. ### Comment 53887 - Author: github88 - Created: 2026-03-26T13:43:16+09:00 - Points: 1 결론 정해놓고 llm한테 써달라고 한 듯. 궤변. 프로덕션 경험이 전혀 없는듯 ### Comment 53848 - Author: myc0058 - Created: 2026-03-26T02:17:15+09:00 - Points: 1 걍 꿈 같은 얘기네요. 시간이 지날수록 문서화도 의미 없고 엄격하게 리뷰하게 되던데? ### Comment 53678 - Author: fantajeon - Created: 2026-03-24T08:12:17+09:00 - Points: 1 그려~ 이런 논쟁을 만들어 생각한 글로만도 의도는 충분했구만 ### Comment 53615 - Author: gomjellie - Created: 2026-03-23T09:58:55+09:00 - Points: 1 번역글 입니다: https://rosetta.page/post/번역-코드-리뷰를-없애는-방법-QTVz6 ### Comment 53329 - Author: brainer - Created: 2026-03-19T09:15:36+09:00 - Points: 1 애초에 plan 단계에서 거를 수 있는 문제인데요 ### Comment 53248 - Author: foriequal0 - Created: 2026-03-17T21:52:05+09:00 - Points: 1 코드를 손으로 짜는 과정에서 개발자는 자연스럽게 기획도 하고, 설계도 하고, 탐색도 하고, 이해도 하고, 테스트도 하고, 자가리뷰도 하고, 문제가 발생했을 때 사후대응 할 과정을 암시적으로, 병렬적으로 하면서 자연스럽게 각 측면이 조정되기 마련입니다. 그러니까 테스트나, 리뷰가 부족해도 어느정도 돌아갔던거라고 생각합니다. 그런데 손으로 짜는 과정을 없애버리면 암시적으로 있던 과정들을 명시적으로 경계를 지어야 합니다. 코드를 작성한 주체와 검토의 주체가 더욱 더 분리되었기 때문에 소통의 비효율이 증가합니다. 코드 작성 주체의 신뢰가 더 떨어지기 때문에 검토 비용 역시 증가합니다. doorman's fallacy 라는 개념과 비슷한거 아닌가 싶습니다. ### Comment 53203 - Author: remin1994 - Created: 2026-03-17T13:32:51+09:00 - Points: 1 저도 회사에서 자주 고민하던 주제인데, 좋은데요 개인적으로 만들어보고 있는 하니스에도 도입 해 보아야겠어요 ### Comment 53199 - Author: jayhanx - Created: 2026-03-17T13:05:09+09:00 - Points: 1 리뷰는 점점 간소화하고 테스트를 빡세게 하는 방향으로 점차 이동하지 않을까 싶네요 ### Comment 53193 - Author: smoonsf - Created: 2026-03-17T11:34:32+09:00 - Points: 1 단순히 코드리뷰를 없애자가 아니라, 더 상위의 개념인 의도와 해당 의도가 제대로 동작했는지를 명시적으로 확인할 수 있는 산출물로 리뷰를 하자는 것 같네요. 현재 시점에서 설계, 아키텍처 레벨이 아닌 코드 구현의 디테일을 블랙박스로 유지하는 것은 바람직하다고 생각합니다. ### Comment 53546 - Author: moregeek - Created: 2026-03-22T13:34:18+09:00 - Points: 2 - Parent comment: 53193 - Depth: 1 그 블랙박스가 쌓여서 AI 조차 손을 제대로 못쓰는 지경까지 이어질 수도 있다고 생각합니다. 다들 편리함에 너무 취해있는 것 같아요. 언젠가 큰 사고가 터질거라고 생각합니다. ### Comment 53852 - Author: raykim - Created: 2026-03-26T07:15:50+09:00 - Points: 1 - Parent comment: 53193 - Depth: 1 저도 윗분 의견 동의합니다. 어느날 갑자기 모델이 인간 코드 중 어떤 부분을 잘못 학습한 부분이 발견되고 이게 여태 코드에 반영되었다는 걸 깨달았다면? 그 날이 다 뒤집는 날이 될 수도.. 아무리 최신 모델이 날고 기어도 swe 벤치마크 만점을 "항상" (6 nine, 0.999999) 받지 못한다면 가능성은 열려있다고 생각해요. ### Comment 53115 - Author: shakespeares - Created: 2026-03-16T13:19:43+09:00 - Points: 1 의도리뷰. 좋은 말이네요. ### Comment 53113 - Author: ljyda214 - Created: 2026-03-16T13:16:32+09:00 - Points: 1 AI 로 빨라지는 시대에 어떻게 대응해야 고민했는데 코드 리뷰에 대한 새로운 관점을 주는 좋은 글이에요!