[번역] Code Review in the age of AI

AI & ML-ops•2026.01.24

원문: https://addyosmani.com/blog/code-review-ai/

Addy Osmani - 2025년 3월 20일

AI가 코드 리뷰(Code Review)를 없앤 것이 아닙니다. 오히려 증명에 대한 책임을 명확하게 만들었습니다. 수동 검증이나 자동화된 테스트와 같은 증거와 함께 변경 사항을 배포하고, 리뷰는 리스크 관리, 의도 파악, 그리고 책임 소재 확인을 위해 활용하십시오. 1인 개발자는 AI의 속도를 따라잡기 위해 자동화에 의존하는 반면, 팀은 공유된 컨텍스트(Context)와 소유권을 구축하기 위해 리뷰를 사용합니다.

만약 당신의 풀 리퀘스트(Pull Request, PR)에 코드가 작동한다는 증거가 포함되어 있지 않다면, 당신은 더 빨리 배포하고 있는 것이 아닙니다. 그저 할 일을 다음 단계로 미루고 있을 뿐입니다.

2026년 초까지, 시니어 개발자의 30% 이상이 주로 AI가 생성한 코드를 배포한다고 보고했습니다. 문제는 무엇일까요? AI는 기능을 초안하는 데는 뛰어나지만 논리, 보안, 그리고 에지 케이스(Edge case)에서는 실수를 범합니다. 논리적인 부분에서만 오류가 75% 더 흔하게 발생합니다. 이로 인해 워크플로우가 나뉩니다. 1인 개발자는 테스트 스위트(Test suite)를 안전장치 삼아 추론 속도에 맞춰 "느낌(Vibe)"대로 개발하는 반면, 팀은 컨텍스트와 규정 준수를 위해 사람의 눈을 요구합니다. 올바르게 수행된다면 양쪽 모두 AI를 가속기로 취급하지만, 검증을 '누가, 무엇을, 언제' 하느냐가 차이를 결정합니다.

제가 이전에도 말했듯이, 코드가 올바르게 작동하는 것을 직접 확인하지 않았다면 그것은 작동하는 것이 아닙니다. AI는 이 규칙을 증폭시킬 뿐, 면죄부를 주지 않습니다.

개발자들이 리뷰에 AI를 활용하는 방법

임시 LLM 체크: 커밋하기 전에 버그나 스타일을 빠르게 스캔하기 위해 Claude, Gemini 또는 GPT에 diff를 붙여넣습니다.

IDE 통합: 코딩 중 인라인 제안 및 리팩터링을 위해 Cursor, Claude Code 또는 Gemini CLI와 같은 도구를 사용합니다.

PR 봇 및 스캐너: PR에서 문제를 깃발 표시(Flag)하기 위해 GitHub Copilot이나 커스텀 에이전트를 사용하며, 보안을 위해 Snyk과 같은 정적/동적 분석 도구와 병행합니다.

자동화된 테스트 루프: AI를 사용하여 테스트를 생성하고 실행하며, 테스트 커버리지(Coverage) 70% 이상을 게이트(Gate)로 강제합니다.

멀티 모델 리뷰: 편향성을 잡기 위해 서로 다른 LLM(예: 생성은 Claude, 감사는 보안 중심 모델)을 통해 코드를 검토합니다.

워크플로우와 마음가짐은 당신이 혼자 일하는지, 아니면 다른 사람들이 당신의 코드를 유지보수하는 팀에서 일하는지에 따라 크게 달라집니다.

1인 개발자 vs. 팀: 빠른 비교

1인 개발자: "추론 속도"로 배포하기

1인 개발자들은 점점 더 AI가 생성한 코드의 "느낌"을 신뢰하고 있습니다. 핵심 부분만 리뷰하고 나머지는 테스트가 문제를 잡아낼 것이라 믿으며 기능을 빠르게 배포합니다.

이 워크플로우는 코딩 에이전트를 대규모 리팩터링을 스스로 처리할 수 있는 유능한 인턴처럼 취급합니다. Peter Steinberger가 인정했듯이: "저는 더 이상 코드를 많이 읽지 않습니다. 스트림을 지켜보다가 가끔 핵심적인 부분을 보긴 하지만, 대부분의 코드는 읽지 않습니다." 이제 병목 현상은 타이핑이 아니라 AI가 결과물을 생성하기를 기다리는 추론 시간(Inference time)이 되었습니다.

하지만 함정이 있습니다. 강력한 테스트 관행이 없다면 체감되는 속도 향상은 사라집니다. 테스트부터 구축하십시오. 리뷰를 건너뛴다고 해서 일이 없어지는 것이 아니라, 뒤로 미뤄지는 것뿐입니다. 높은 속도로 AI를 활용해 성공하는 개발자들은 AI를 맹목적으로 믿는 사람들이 아닙니다. 그들은 문제가 운영 환경에 도달하기 전에 잡아낼 수 있는 검증 시스템을 구축한 사람들입니다.

그렇다고 해서 1인 개발자들이 주의를 기울이지 않는다는 뜻은 아닙니다. 책임감 있는 개발자들은 광범위한 자동화 테스트를 안전망으로 활용합니다. 높은 커버리지(종종 70% 이상)를 목표로 하며, 실시간으로 버그를 잡기 위해 AI를 사용하여 테스트를 생성합니다. 현대의 코딩 에이전트들은 정교한 엔드 투 엔드(End-to-end) 테스트를 설계하는 데 놀라울 정도로 능숙합니다.

1인 개발자에게 게임 체인저는 언어에 구애받지 않는 데이터 기반 테스트입니다. 테스트가 포괄적이라면, 에이전트가 어떤 언어로든 구현체를 만들거나 수정하게 하고 진행 과정에서 이를 검증할 수 있습니다. 저는 AI가 초안을 작성한 spec.md로 프로젝트를 시작하고, 이를 승인한 뒤 '작성 → 테스트 → 수정'의 루프를 돌립니다.

결정적으로, 1인 개발자도 최종 제품에 대해 수동 테스트와 비판적 사고를 수행해야 합니다. 애플리케이션을 실행하고, UI를 클릭해보고, 기능을 직접 사용해 보십시오. 리스크가 큰 경우에는 코드를 더 많이 읽고 추가 체크를 더하십시오. 그리고 빠르게 움직이더라도, 지저분한 코드가 보이면 방치하지 말고 즉시 수정하십시오.

이러한 최첨단 패러다임에서도 변하지 않는 사실은, 당신의 업무는 작동함이 증명된 코드를 전달하는 것입니다.

팀: AI가 리뷰 병목 현상을 옮기다

팀 환경에서 AI는 코드 리뷰를 위한 강력한 조력자이지만, 품질, 보안 및 유지보수성을 위해 필요한 인간의 판단을 대체할 수는 없습니다.

여러 엔지니어가 협업할 때, 실수의 비용과 코드의 수명은 훨씬 더 중요한 고려 사항입니다. 팀들은 PR에 대한 1차 검토를 위해 AI 기반 리뷰 봇을 사용하기 시작했지만, 여전히 사람이 최종 승인을 해야 합니다. Graphite의 Greg Foster가 말했듯이: "AI 에이전트가 실제 인간 엔지니어가 풀 리퀘스트를 승인하는 것을 대신하게 될 것이라고는 전혀 생각하지 않습니다."

가장 큰 실제적인 문제는 AI 리뷰어가 스타일 문제를 놓치는 것이 아니라, AI가 작업량을 늘려 그 부담을 인간에게 전가한다는 점입니다. PR의 크기가 점점 커지고 있으며(AI 도입 이후 추가되는 코드가 약 18% 증가), PR당 장애 발생 건수는 약 24% 증가했고, 변경 실패율은 약 30% 증가했습니다. 결과물이 검증 역량보다 빠르게 증가하면 리뷰가 속도 제한 요소(Rate limiter)가 됩니다. Foster는 다음과 같이 지적합니다: "동료 인간이 실제로 읽거나 이해하지 못한 코드를 배포한다면, 우리는 엄청난 리스크를 감수하고 있는 것입니다."

팀에서는 AI가 쏟아내는 양이 방대하므로 점진주의를 강제해야 합니다. 에이전트의 결과물을 소화 가능한 단위의 커밋으로 나누십시오. 인간의 승인은 사라지지 않습니다. 대신 AI가 파악할 수 없는 로드맵 정렬이나 조직 내 컨텍스트와 같이 AI가 놓치는 부분에 집중하는 방식으로 진화하고 있습니다.

보안: AI의 예측 가능한 약점

인간의 감독이 절대적으로 타협 불가능한 영역 중 하나는 보안입니다. AI가 생성한 코드의 약 45%에 보안 결함이 포함되어 있습니다. 논리 오류는 사람이 작성한 코드보다 1.75배 더 많이 나타나며, XSS 취약점은 2.74배 더 높은 빈도로 발생합니다.

코드 자체의 문제 외에도, 에이전트 도구와 AI 통합 IDE는 프롬프트 인젝션, 데이터 유출, 심지어 원격 코드 실행(RCE) 취약점과 같은 새로운 공격 경로를 만들어냈습니다. AI는 공격 표면을 확장하므로 하이브리드 접근 방식이 승리합니다. AI가 깃발을 들고, 사람이 검증하는 방식입니다.

규칙: 코드가 인증(Auth), 결제, 비밀 정보(Secrets) 또는 신뢰할 수 없는 입력을 다룬다면, AI를 고속 인턴으로 취급하고 머지(Merge) 전에 인간의 위협 모델(Threat model) 리뷰와 보안 도구 검사를 반드시 거치십시오.

지식 전달로서의 리뷰

코드 리뷰는 팀이 시스템 컨텍스트를 공유하는 방법이기도 합니다. AI가 코드를 작성했는데 아무도 그것을 설명할 수 없다면, 온콜(On-call) 비용은 비싸집니다.

개발자가 완전히 이해하지 못한 AI 생성 코드를 제출하면, 팀을 회복 탄력성 있게 만드는 지식 전달 메커니즘을 깨뜨리는 것입니다. 원작자가 코드가 왜 작동하는지 설명할 수 없다면, 새벽 2시에 온콜 엔지니어가 어떻게 그것을 디버깅하겠습니까?

OCaml 메인테이너들이 13,000줄의 AI 생성 PR을 거절한 사례는 이 문제를 극명하게 보여줍니다. 코드가 반드시 나빴던 것은 아니지만, 그 거대한 변경 사항을 리뷰할 여력이 아무도 없었으며, AI가 생성한 코드를 리뷰하는 것은 인간의 코드를 리뷰하는 것보다 *"더 고된 일"*이기 때문입니다. 교훈은 이렇습니다: AI는 코드를 쏟아낼 수 있지만, 팀은 리뷰 병목 현상을 피하기 위해 그 양을 관리해야 합니다.

AI 리뷰 도구 활용하기

AI 리뷰 도구에 대한 사용자 경험은 확실히 엇갈립니다. 긍정적인 측면에서는 널 포인터 예외(Null pointer exception), 누락된 테스트 커버리지, 안티 패턴 등 버그의 95% 이상을 잡아냈다는 보고가 있습니다. 부정적인 측면에서는 일부 개발자들이 AI 리뷰 코멘트를 가치 없는 일반적인 관찰인 "텍스트 노이즈"라며 무시하기도 합니다.

교훈: AI 리뷰 도구는 세심한 설정이 필요합니다. 민감도를 조정하고, 도움이 되지 않는 코멘트 유형은 비활성화하며, 명확한 옵트인/옵트아웃(Opt-in/Opt-out) 정책을 수립하십시오. 적절히 설정된다면, AI 리뷰어는 단순한 문제들의 70~80%를 잡아낼 수 있으며, 이를 통해 인간은 아키텍처와 비즈니스 로직에 집중할 수 있게 됩니다.

많은 팀이 AI가 거대한 변경을 한 번에 할 수 있더라도 더 작고 쌓을 수 있는(Stackable) 풀 리퀘스트를 권장합니다. 일찍, 그리고 자주 커밋하십시오. 각각의 독립적인 변경 사항을 명확한 메시지가 담긴 별도의 커밋/PR로 취급하십시오.

중요한 것은, 팀이 인간의 책임이라는 엄격한 선을 유지한다는 점입니다. AI가 얼마나 많이 기여했든 상관없이, 인간이 책임을 져야 합니다. 오래된 IBM 교육 문구처럼 말입니다: "컴퓨터는 결코 책임을 질 수 없습니다. 그것은 루프 안에 있는 인간인 당신의 몫입니다."

PR 계약: 작성자가 리뷰어에게 지켜야 할 예의

1인 개발자든 팀이든, 새롭게 떠오르는 베스트 프랙티스는 AI가 생성한 코드를 반드시 검증해야 하는 유용한 초안으로 취급하는 것입니다.

가장 성공적인 팀들은 다음과 같은 간단한 프레임워크로 수렴되었습니다.

PR 계약

무엇을/왜(What/Why): 의도를 1~2문장으로 설명합니다.

작동 증명(Proof it works): 통과된 테스트, 수동 확인 단계(스크린샷/로그).

리스크 + AI의 역할: 리스크 등급과 어느 부분이 AI에 의해 생성되었는지 명시(예: 높음=결제 관련).

리뷰 집중 사항: 인간의 피드백이 필요한 1~2개 영역(예: 아키텍처).

이것은 관료주의가 아닙니다. 리뷰어의 시간에 대한 존중이며, 작성자의 책임을 강제하는 장치입니다. 이것을 채울 수 없다면, 당신은 다른 사람에게 승인을 요청할 만큼 자신의 변경 사항을 충분히 이해하지 못한 것입니다.

핵심 원칙

약속이 아닌 증거를 요구하십시오. "작동하는 코드"를 기본값으로 만드십시오. AI 에이전트가 생성 후 코드를 실행하거나 유닛 테스트를 수행하도록 유도하십시오. 로그, 스크린샷, 결과와 같은 증거를 요구하십시오. 새로운 테스트나 작동하는 데모 없이는 어떤 PR도 올리지 마십시오.

AI를 최종 결정자가 아닌 1차 리뷰어로 활용하십시오. AI 리뷰 결과물을 권고 사항으로 취급하십시오. 한 AI가 코드를 작성하고 다른 AI가 이를 리뷰하며, 인간이 수정을 조율하는 대화로 생각하십시오. AI 리뷰를 편집자가 아닌 맞춤법 검사기 정도로 여기십시오.

인간의 리뷰는 AI가 놓치는 것에 집중하십시오. 변경 사항이 보안 구멍을 만듭니까? 기존 코드를 중복해서 만듭니까(AI의 흔한 결함)? 접근 방식이 유지보수 가능합니까? AI는 쉬운 것들을 선별하고, 인간은 어려운 문제들을 해결합니다.

점진적 개발을 강제하십시오. 작업을 작은 조각으로 나누십시오. AI가 생성하기 쉽고 인간이 리뷰하기에도 좋습니다. 명확한 메시지가 담긴 작은 커밋들은 체크포인트 역할을 합니다. 설명할 수 없는 코드는 절대 커밋하지 마십시오.

높은 테스트 표준을 유지하십시오. 코딩 에이전트를 가장 잘 활용하는 사람들은 강력한 테스트 관행을 가지고 있습니다. AI에게 테스트 초안을 작성하게 하십시오. AI는 당신이 생각지 못한 에지 케이스 테스트를 생성하는 데 능숙합니다.

앞으로의 전망: 병목 현상이 이동했습니다

AI는 코드 리뷰를 한 줄 한 줄 검사하는 문지기 역할에서 더 높은 수준의 품질 관리로 변화시키고 있습니다. 하지만 인간의 판단은 여전히 안전에 직결된 핵심 요소로 남을 것입니다.

우리가 목격하고 있는 것은 워크플로우의 소멸이 아니라 진화입니다. 이제 코드 리뷰는 코드의 차이점(Diff)뿐만 아니라 AI와 작성자 사이의 대화나 계획을 검토하는 일을 포함합니다. 인간 리뷰어의 역할은 편집자나 아키텍트와 더 비슷해지고 있습니다. 중요한 것에 집중하고 일상적인 체크는 자동화에 맡기는 것입니다.

1인 개발자들에게 앞으로의 길은 매우 흥미롭습니다. 새로운 도구들이 개발을 더욱 간소화할 것입니다. 그럼에도 현명한 개발자는 "신뢰하되 검증"할 것입니다.

규모가 큰 팀에서는 AI 거버넌스(Governance)에 대한 강조가 커질 것으로 예상됩니다. 기업들은 AI 기여에 대한 정책을 공식화하고, 직원이 코드를 리뷰했다는 승인을 요구할 것입니다. "AI 코드 감사관"과 같은 역할이 등장할 수도 있습니다. 엔터프라이즈 플랫폼은 더 나은 멀티 리포지토리(Multi-repository) 컨텍스트와 커스텀 정책 강제 기능을 제공하는 방향으로 진화할 것입니다.

기술이 아무리 발전해도 핵심 원칙은 변하지 않습니다. 코드 리뷰는 소프트웨어가 요구사항을 충족하고, 안전하며, 견고하고, 유지보수 가능함을 보장하는 것입니다. AI는 이러한 근본을 바꾸지 않습니다. 단지 그곳에 도달하는 방식을 바꿀 뿐입니다.

병목 현상은 코드를 작성하는 것에서 그것이 작동함을 증명하는 것으로 옮겨갔습니다. AI 시대의 최고의 코드 리뷰어들은 이러한 변화를 받아들일 것입니다. 기계적인 작업은 AI가 가속하게 두되, 책임의 선은 끝까지 지키는 사람들입니다. 그들은 AI가 프로세스를 가속(Accelerate)하게 하되, 결코 책임을 포기(Abdicate)하게 하지 않을 것입니다. 엔지니어들이 배우고 있듯이, 코딩에서 중요한 것은 “느낌보다 증명(Proof over vibes)”입니다.

코드 리뷰는 죽지 않았습니다. 다만 더 전략적으로 변하고 있을 뿐입니다. 새벽 2시에 배포하는 1인 해커든, 중요한 시스템 변경을 승인하는 팀 리더든, 한 가지 진실은 변하지 않습니다. AI가 내놓은 결과물에 대한 최종 책임은 결국 인간에게 있습니다.

AI를 받아들이되, 작업물을 재확인하는 것을 절대 잊지 마십시오.