AI는 코드 리뷰를 죽인 것이 아니라, ‘동작한다’는 증거를 더 명확히 요구하게 만들었다. 수동 검증과 자동화 테스트 같은 증거로 변경을 출고하고, 리뷰는 위험·의도·책임을 다루는 데 집중해야 한다. 1인 개발자는 AI 속도를 따라잡기 위해 자동화에 기대고, 팀은 리뷰로 공통 맥락과 소유권을 쌓는다.
URL: https://addyo.substack.com/p/code-review-in-the-age-of-ai
AI는 코드 리뷰를 죽이지 않았다. 대신 ‘입증 책임’을 명시적으로 만들었다. 수동 검증과 자동화 테스트 같은 증거와 함께 변경을 출고하고, 리뷰는 위험, 의도, 책임 소재를 다루는 데 사용하라. 1인 개발자는 AI의 속도를 따라잡기 위해 자동화에 기대고, 팀은 리뷰를 통해 공유된 맥락과 오너십을 구축한다.
PR에 “동작한다는 증거”가 없다면, 더 빠르게 출고하는 게 아니다. 그저 일을 다운스트림(뒤 공정)으로 미루는 것뿐이다.
2026년 초까지, 시니어 개발자의 30% 이상이 “대부분 AI가 생성한 코드”를 출고한다고 보고했다. 문제는? AI는 기능 초안을 잘 뽑지만 논리, 보안, 엣지 케이스에서 흔들린다. 특히 논리 오류만 놓고 봐도 오류가 75% 더 흔해진다. 이로 인해 워크플로가 갈라진다. 1인 개발자는 테스트 스위트를 안전망으로 두고 추론(inference) 속도로 “바이브(vibe)”를 타며 진행하는 반면, 팀은 맥락과 컴플라이언스를 위해 사람의 눈을 요구한다. 잘하는 경우 둘 다 AI를 가속기로 취급하지만, 결국 차이를 가르는 것은 검증(누가, 무엇을, 언제 확인했는가)이다.
전에 말했듯이: 코드가 “올바르게 동작하는 모습”을 본인이 직접 확인하지 않았다면, 그 코드는 동작하지 않는 것이다. AI는 이 규칙을 면제해주지 않는다. 오히려 더 강화한다.
워크플로와 마인드셋은 1인 개발인지, 아니면 다른 사람들이 유지보수하는 코드를 팀으로 만드는지에 따라 극적으로 달라진다.
1인 개발자는 AI가 생성한 코드를 점점 더 “바이브를 믿고” 진행한다. 핵심 부분만 훑고, 나머지는 테스트가 문제를 잡아주길 기대하며 기능을 빠르게 출고한다.
이 워크플로는 코딩 에이전트를 “강력한 인턴”처럼 취급한다. 거대한 리팩터링도 상당 부분 스스로 처리하게 한다. Peter Steinberger가 인정하듯 “나는 이제 코드를 많이 읽지 않는다. 스트림을 보고 가끔 핵심 부분만 보는데, 대부분의 코드는 읽지 않는다.” 병목은 타이핑이 아니라 추론 시간—AI가 출력을 생성할 때까지 기다리는 시간—이 된다.
하지만 함정이 있다. 강한 테스트 관행이 없으면, 체감 속도 향상은 사라진다. 먼저 그 기반을 만들라. 리뷰를 생략한다고 일이 없어지는 게 아니다. 미룰 뿐이다. AI로 높은 속도를 내며 성공하는 개발자는 AI를 맹신하는 사람이 아니라, 프로덕션에 닿기 전에 문제를 잡는 검증 시스템을 구축한 사람이다.
그렇다고 1인 개발자가 무모해지는 건 아니다. 책임감 있는 사람들은 광범위한 자동화 테스트를 안전망으로 활용한다. 높은 커버리지(종종 70%+)를 목표로 하고, AI로 테스트를 생성해 실시간으로 버그를 잡는다. 최신 코딩 에이전트는 꽤 정교한 E2E 테스트 설계도 놀랄 만큼 잘한다.
1인 개발자에게 게임 체인저는 언어 독립적이고 데이터 기반인 테스트다. 충분히 포괄적이라면, 에이전트가 어떤 언어로 구현(또는 수정)하든 진행 중에 검증할 수 있다. 나는 프로젝트를 시작할 때 AI가 spec.md를 초안 작성하게 하고 승인한 다음, 작성 → 테스트 → 수정 루프를 돈다.
중요하게도, 1인 개발자도 최종 제품에 대해 수동 테스트와 비판적 사고를 한다. 애플리케이션을 실행하고, UI를 클릭해보고, 기능을 직접 써보라. 위험이 큰 경우에는 더 많은 코드를 읽고 추가 체크를 넣어라. 그리고 빠르게 움직이더라도, 보기 싫은 코드를 발견하면 나중으로 미루지 말고 바로 고쳐서 쓰레기가 쌓이지 않게 하라.
이 최첨단 패러다임에서도: 당신의 일은 ‘동작한다고 입증한 코드’를 전달하는 것이다.
팀 환경에서 AI는 코드 리뷰를 돕는 강력한 조력자지만, 품질·보안·유지보수성에 필요한 인간의 판단을 대체할 수는 없다.
여러 엔지니어가 협업할 때는 실수의 비용과 코드의 수명(장기 유지)이 훨씬 더 큰 이슈다. 팀은 PR에 대해 AI 기반 리뷰 봇으로 1차 패스를 돌리기 시작했지만, 여전히 사람이 승인해야 한다. Graphite의 Greg Foster가 말하듯 “나는 [AI 에이전트가] 실제 인간 엔지니어가 PR을 승인하는 것을 대체할 것이라고는 전혀 보지 않는다.”
가장 큰 실무적 문제는 AI 리뷰어가 스타일 이슈를 놓친다는 게 아니다. AI가 볼륨을 폭발시키고 부담을 인간에게 전가한다는 점이다. AI 도입이 늘면서 PR이 더 커지고 (추가 라인이 ~18% 증가), PR당 인시던트는 ~24% 증가, 변경 실패율은 ~30% 증가하고 있다. 산출물이 검증 능력보다 빨리 늘면, 리뷰가 레이트 리미터가 된다. Foster의 말처럼: “동료 인간이 실제로 읽거나 이해하지 않은 코드를 출고한다면, 우리는 엄청난 위험을 감수하는 것이다.”
팀에서는 AI가 볼륨을 쏟아내므로 점진성을 강제하라. 에이전트의 산출물을 소화 가능한 커밋으로 쪼개라. 인간 승인(sign-off)은 사라지지 않는다. 대신 AI가 놓치는 것—로드맵 정렬, 조직의 제도적 맥락처럼 AI가 이해하지 못하는 것—에 집중하도록 진화한다.
사람의 감독이 절대 타협 불가능한 영역 중 하나는 보안이다. AI 생성 코드의 약 45%에는 보안 결함이 있다. 논리 오류는 인간 작성 코드 대비 1.75배, XSS 취약점은 2.74배 더 자주 발생한다.
코드 자체의 문제를 넘어, 에이전틱 도구와 AI 통합 IDE가 새로운 공격 경로를 만들었다. 프롬프트 인젝션, 데이터 유출, 심지어 RCE 취약점까지. AI는 공격 표면을 넓히므로, 하이브리드 접근이 이긴다: AI가 플래그를 세우고, 사람은 검증한다.
규칙: 코드가 인증(auth), 결제(payments), 시크릿(secrets), 또는 신뢰할 수 없는 입력(untrusted input)을 다룬다면, AI를 고속 인턴으로 취급하라. 머지 전에 인간의 위협 모델 리뷰 + 보안 도구 패스를 필수로 하라.
코드 리뷰는 팀이 시스템 맥락을 공유하는 방식이기도 하다. AI가 코드를 쓰고 아무도 설명할 수 없다면, 온콜 비용이 폭증한다.
개발자가 자신도 완전히 이해하지 못한 AI 생성 코드를 제출하면, 팀을 견고하게 만드는 지식 전달 메커니즘을 깨뜨리는 것이다. 원 작성자가 코드가 왜 동작하는지 설명할 수 없다면, 새벽 2시에 온콜 엔지니어가 어떻게 디버깅하겠는가?
OCaml 메인테이너가 13,000줄짜리 AI 생성 PR을 거절한 사례가 이를 극명하게 보여준다. 코드가 반드시 나빴던 건 아니지만, 그만큼 큰 변경을 리뷰할 여력이 아무에게도 없었다. 그리고 AI 생성 코드 리뷰는 인간 코드 리뷰보다 “더 피곤하다”. 교훈은 이렇다: AI는 코드를 홍수처럼 쏟아낼 수 있지만, 팀은 리뷰 병목을 피하기 위해 볼륨을 관리해야 한다.
AI 리뷰 도구에 대한 사용자 경험은 확실히 엇갈린다. 긍정적으로는 널 포인터 예외, 테스트 커버리지 누락, 안티패턴 등에서 어떤 경우 95%+의 버그를 잡았다고 보고한다. 부정적으로는 일부 개발자가 AI 리뷰 코멘트를 “텍스트 노이즈”—가치 없는 일반론—로 치부한다.
교훈: AI 리뷰 도구는 신중한 설정이 필요하다. 민감도(sensitivity)를 조정하고, 도움이 안 되는 코멘트 유형을 끄고, 명확한 옵트인/옵트아웃 정책을 마련하라. 제대로 설정하면 AI 리뷰어는 ‘쉬운 것’의 70~80%를 잡아 인간이 아키텍처와 비즈니스 로직에 집중할 수 있게 해준다.
많은 팀은 AI가 한 번에 거대한 변경을 할 수 있더라도 더 작고 쌓기 쉬운 PR을 권장한다. 일찍, 자주 커밋하라. 각 변경을 자체 완결적인 커밋/PR로 분리하고, 메시지를 명확히 하라.
중요한 점은 팀이 인간 책임(accountability)의 경계선을 단단히 유지한다는 것이다. AI가 얼마나 기여했든, 책임은 사람이 져야 한다. 오래된 IBM 교육 문구처럼: “컴퓨터는 결코 책임을 질 수 없다. 인간인 당신의 일이다.”
1인이든 팀이든, 떠오르는 베스트 프랙티스는 AI 생성 코드를 ‘도움되는 초안’으로 취급하되 반드시 검증해야 한다는 것이다.
가장 성공적인 팀들은 간단한 프레임워크로 수렴했다:
이건 관료주의가 아니다. 리뷰어 시간에 대한 존중이며, 작성자 책임을 강제하는 장치다. 이걸 채울 수 없다면, 남에게 승인해 달라고 요청할 만큼 변경을 이해하지 못하고 있다는 뜻이다.
약속이 아니라 증거를 요구하라. “동작하는 코드”를 기준선으로 만들어라. 에이전트에게 생성 후 코드를 실행하거나 유닛 테스트를 돌리게 프롬프트하라. 로그, 스크린샷, 결과 같은 증거를 요구하라. 새 테스트가 없거나 변경이 동작하는 데모가 없다면 PR을 올리지 말라.
AI는 1차 리뷰어로 쓰되, 최종 심판으로 두지 말라. AI 리뷰 출력은 권고사항으로 취급하라. 한 AI가 코드를 쓰고, 다른 AI가 리뷰하고, 사람은 수정과 결정을 오케스트레이션하는 대화로 보라. AI 리뷰는 편집자가 아니라 맞춤법 검사(spellcheck) 같은 것이다.
사람의 리뷰는 AI가 놓치는 것에 집중하라. 변경이 보안 구멍을 만들었나? 기존 코드와 중복(흔한 AI 결함)되나? 접근 방식이 유지보수 가능한가? AI는 쉬운 것을 분류(triage)하고, 사람은 어려운 것을 푼다.
점진적 개발을 강제하라. 작업을 작은 조각으로 쪼개라. AI가 만들기도 쉽고, 사람이 리뷰하기도 쉽다. 명확한 메시지를 가진 작은 커밋은 체크포인트가 된다. 설명할 수 없는 코드는 절대 커밋하지 말라.
높은 테스트 기준을 유지하라. 코딩 에이전트의 성과를 가장 잘 끌어내는 사람들은 테스트 관행이 강하다. AI에게 테스트 초안을 맡겨라. 사람이 생각 못한 엣지 케이스 테스트를 잘 만들어준다.
AI는 코드 리뷰를 라인 단위의 문지기(gatekeeping)에서 더 상위 수준의 품질 관리로 바꾸고 있다. 그러나 인간의 판단은 여전히 안전-중요(safety-critical) 구성요소다.
우리가 보는 것은 제거가 아니라 워크플로의 진화다. 이제 코드 리뷰는 코드 diff 자체만큼이나, AI와 작성자 사이의 대화 또는 _계획_을 리뷰하는 일이 됐다. 인간 리뷰어의 역할은 편집자나 아키텍트에 더 가깝다. 중요한 것에 집중하고, 자잘한 체크는 자동화에 맡긴다.
1인 개발자에게 앞으로의 길은 짜릿하다. 새로운 도구가 개발을 더 매끄럽게 만들 것이다. 그래도 현명한 개발자는 “신뢰하되 검증(trust but verify)”할 것이다.
대규모 팀에서는 AI 거버넌스의 중요성이 커질 것이다. 기업은 AI 기여에 대한 정책을 공식화하고, 코드가 직원에 의해 리뷰되었음을 요구하는 승인 절차를 둘 것이다. “AI 코드 감사관(AI code auditor)” 같은 역할이 생길 것이다. 엔터프라이즈 플랫폼은 멀티 리포지토리 맥락과 커스텀 정책 집행을 더 잘 제공하도록 진화할 것이다.
아무리 발전해도 핵심 원칙은 변하지 않는다: 코드 리뷰는 소프트웨어가 요구사항을 만족하고, 안전하며, 견고하고, 유지보수 가능함을 보장한다. AI는 그 본질을 바꾸지 않는다. 우리가 거기에 도달하는 방법만 바꾼다.
병목은 코드를 쓰는 데서 “동작을 입증하는 데”로 이동했다. AI 시대의 최고의 코드 리뷰어는 이 변화를 받아들일 것이다. AI가 기계적인 일을 가속하게 두되, 책임(accountability)만큼은 지켜낸다. AI가 프로세스를 가속하게 하되, 결코 위임(abdicate) 하지는 않는다. 엔지니어들이 배우고 있듯, 코딩은 _“바이브보다 증거(proof over vibes)”_의 문제다.
코드 리뷰는 죽지 않았다. 다만 더 전략적이 되고 있다. 새벽 2시에 배포하는 1인 해커든, 중요한 시스템 변경에 사인하는 팀 리드든, 한 가지 진실은 같다. AI가 무엇을 내놓든 최종 책임은 _인간_에게 있다.
AI를 받아들이되, 작업을 반드시 두 번 확인하라.
O’Reilly와 함께 새 AI 보조 엔지니어링 책을 출시했다는 소식을 전하게 되어 기쁘다. 관심 있다면 책 사이트에 무료 팁도 몇 가지 있다.
