코드 리뷰 언제까지 해야할까
우리는 AI가 쏟아내는 코드의 홍수 속에서 허우적대고 있다. 과거의 방식으로는 도저히 이 속도를 따라잡을 수 없다. 이제는 단순히 코드를 읽는 행위를 넘어, 개발의 패러다임 자체를 송두리째 바꿔야 할 시점이다. 기술의 발전 속도는 인간의 인지 능력을 추월했고, 우리가 신성시하던 코드 리뷰라는 절차는 이제 혁신의 발목을 잡고 있다.
최근 개발 환경의 변화를 지켜보면 AI가 코드를 작성하는 속도가 인간의 검토 속도를 아득히 추월하고 있다는 사실을 체감한다. 많은 개발자가 클라우드 기반의 AI 도구를 활용해 생산성을 비약적으로 높였지만, 아이러니하게도 팀 전체의 속도는 오히려 정체되거나 느려지는 현상이 발생하고 있다. 한 조사에 따르면 AI 도입률이 높은 팀은 PR(Pull Request) 생성량이 98%나 증가했지만, 정작 리뷰에 소요되는 시간은 91%나 늘어났다고 한다. 이러한 불균형은 결국 코드 리뷰라는 전통적인 안전망이 AI 시대의 생산성을 감당하지 못한다는 걸 의미한다. 인간은 인간이 코드를 작성하던 속도에 맞춰진 리뷰 프로세스조차 제대로 소화하지 못하고 있었다.
엔지니어링 조직들을 살펴보면 한 가지 공통적인 비밀이 있다. PR은 며칠씩 방치되고, 리뷰어들은 자기 일을 하느라 바빠서 500줄이 넘는 변경 사항을 대충 훑어본 뒤 도장을 찍듯 승인 버튼을 누른다. 우리는 이것을 품질 게이트라고 부르며 스스로를 위안하지만, 사실 수십 년 동안 팀들은 한 줄 한 줄 꼼꼼한 리뷰 없이도 소프트웨어를 출시해왔다. 코드 리뷰가 보편화된 것은 생각보다 그리 오래된 일이 아니다. 2012년에서 2014년 사이에나 대중화되었을 뿐이다. 게다가 리뷰를 거친다고 해서 버그가 생기지 않는 것도 아니다. 우리는 이미 리뷰만으로는 부족하다는 것을 알고 있었기에 기능 플래그, 점진적 배포, 즉각적인 롤백 시스템을 구축해왔다.
이제 우리는 모든 코드를 읽는 것을 포기해야 한다. 1,200개 이상의 팀과 1만 명 이상의 개발자 데이터를 보면 두 가지 수치가 지수적으로 상승하고 있다. 바로 코드 변경의 횟수와 그 규모다. 우리는 이 엄청난 양의 코드를 도저히 소비할 수 없다. 더 큰 문제는 개발자들이 동료의 코드보다 AI가 생성한 코드를 검토할 때 훨씬 더 많은 노력을 들여야 한다고 느낀다는 점이다. 생산량은 늘었는데 검토 비용은 더 크게 늘어나는 이 싸움에서 수동 코드 리뷰로는 절대로 승리할 수 없다. 코드 리뷰는 현재의 작업 형태와 더 이상 맞지 않는 역사적 산물이 되어버렸다.
혹자는 AI 코드 리뷰 도구가 해결책이 될 수 있다고 말한다. 하지만 AI가 코드를 쓰고 AI가 리뷰를 한다면, 굳이 화려한 UI를 통해 그 과정을 인간이 지켜볼 필요가 있을까? AI 리뷰 도구는 단지 시간을 벌어줄 뿐이다. AI 에이전트가 코드를 작성하는 시대에 '새로운 시각’을 가진 리뷰어라는 개념은 무의미하다. 에이전트의 시각은 결국 비슷한 사각지대를 가진 또 다른 에이전트의 시각일 뿐이다. 중요한 가치는 승인 게이트가 아니라 반복 루프 안에 있다. 에이전트가 완벽하지 않다는 것을 알기에 우리는 '한 번이라도 AI가 멍청한 실수를 하는 걸 봤으니 내가 직접 확인해야 한다’는 본능에 사로잡힌다. 하지만 수동 검증이 불가능할 정도로 규모가 커진 지금, 그 본능은 오히려 방해가 될 뿐이다.
해결책은 인간의 체크포인트를 상류로 옮기는 것이다. 코드를 리뷰하지 않는다는 생각이 두렵게 느껴질 수 있지만, 소프트웨어 개발 역사에서 체크포인트는 항상 이동해왔다. 폭포수 모델의 최종 서명 방식에서 지속적 통합(CI)으로 옮겨온 것처럼 말이다. 이제는 스펙 중심 개발(Spec-driven development)이 AI와 협업하는 주된 방식이 되어야 한다. 인간은 500줄의 코드 차이점을 읽는 대신 스펙, 계획, 제약 조건, 수용 기준을 리뷰해야 한다. 이 새로운 패러다임에서 스펙은 진실의 원천이 되고 코드는 스펙의 결과물이 된다. 코드가 아니라 단계를 리뷰하고, 검증 규칙을 리뷰하며, 코드가 충족해야 하는 계약을 리뷰해야 한다. 인간의 판단은 '이걸 제대로 썼는가’가 아니라 '우리가 올바른 제약 조건을 가지고 올바른 문제를 해결하고 있는가’에 집중되어야 한다.
신뢰는 한 번에 얻어지는 것이 아니라 겹겹이 쌓아 올리는 것이다. 안킷 제인은 이를 '스위스 치즈 모델’이라고 불렀다. 완벽한 필터는 없지만, 불완전한 필터를 여러 개 겹치면 구멍이 일직선으로 연결되지 않아 결함을 막을 수 있다는 원리다. 첫 번째 레이어는 여러 옵션을 비교하는 것이다. 한 명의 에이전트에게 정답을 요구하는 대신, 세 명의 에이전트에게 서로 다른 방식으로 시도하게 하고 가장 좋은 결과를 선택하게 하는 방식이다. 소프트웨어 공학 역사상 선택의 비용이 이토록 낮았던 적은 없다. 선택 역시 수동일 필요는 없다. 가장 많은 검증 단계를 통과하거나, 변경 사항이 가장 적거나, 새로운 종속성을 추가하지 않는 결과물을 자동으로 순위 매길 수 있다.
두 번째 레이어는 결정론적인 가드레일이다. 테스트, 타입 체크, 계약 검증처럼 의견이 아닌 사실에 기반한 확인 방식이 필요하다. AI에게 '이게 잘 작동해?'라고 묻는 대신, 작동 여부를 증명할 수 있는 스크립트를 작성하게 해야 한다. 에이전트는 실패하는 테스트와 협상할 수 없다. 명세에 부합하거나 그렇지 않거나 둘 중 하나다. 이러한 가드레일은 코딩 가이드라인, 전사적 불변 법칙(예를 들어 하드코딩된 자격 증명 금지), 도메인 계약 등으로 구성된다. 중요한 점은 검증 기준이 코드가 작성된 후에 만들어지는 것이 아니라, 스펙으로부터 먼저 정의되어야 한다는 것이다.
세 번째 레이어에서 비로소 인간이 수용 기준을 정의하며 가치를 더한다. 여기서 행동 주도 개발(BDD)이 다시 중요해진다. 자연어로 기대되는 동작을 기술하고 이를 테스트로 자동화하는 BDD는 과거에는 코드를 짜는 것 외에 추가적인 작업처럼 느껴져 외면받았다. 하지만 에이전트 시대에는 방정식이 뒤집힌다. 스펙은 더 이상 추가 작업이 아니라 기본 결과물이 된다. 인간이 스펙을 쓰고 에이전트가 구현하며 BDD 프레임워크가 검증한다. 무언가 실패하지 않는 한 우리는 구현을 읽을 필요가 없다. 이것이 인간이 잘하는 일이다. 무엇이 '옳음’인지 정의하고, 비즈니스 로직과 예외 상황을 설계하며, 발생할 수 있는 문제를 미리 생각하는 것 말이다.
네 번째 레이어는 아키텍처로서의 권한 시스템이다. 에이전트가 무엇을 건드릴 수 있는지, 어떤 상황에서 인간의 개입이 필요한지를 아키텍처 단계에서 결정해야 한다. 유틸리티 함수의 버그를 고치는 에이전트에게 인프라 설정 권한을 줄 필요는 없다. 작업에 필요한 최소한의 파일에만 접근 권한을 제한하는 세밀함이 필요하다. 또한 인증 로직을 건드리거나 데이터베이스 스키마를 수정하는 것과 같은 특정 패턴이 감지되면 에이전트의 자신감과 상관없이 자동으로 인간의 리뷰를 요청하는 에스컬레이션 트리거를 설정해야 한다.
마지막 다섯 번째 레이어는 적대적 검증이다. 책임을 분리하여 한 에이전트가 코드를 짜면 다른 에이전트가 이를 검증하게 하는 것이다. 이들은 서로를 믿지 않도록 설계되어야 한다. 이는 마치 보안의 레드팀과 블루팀처럼 작동한다. 코딩 에이전트는 검증 에이전트가 무엇을 확인할지 알 수 없고, 검증 에이전트는 자신의 작업을 편하게 하기 위해 코드를 수정할 권한이 없다. 이러한 적대적 구조를 시스템적으로 강제함으로써 우리는 더 견고한 신뢰를 구축할 수 있다.
결국 '좋은 코드’의 정의 자체가 변하고 있다. 에이전틱 시스템의 목표는 단순하다. 주어진 작업을 완료하고 사용자를 만족시키는 것이다. 에이전트의 성공은 본질적으로 장기적인 정확성이나 비즈니스 요구사항에 의해 추진되지 않는다. 따라서 그 제약 조건을 코드로 인코딩하는 것은 우리의 몫이다. 에이전트가 쓰고 에이전트가 읽는 코드의 시대에는 코드의 스타일이 더 표준화될 것이다. 우리는 기계를 읽기 능력으로 이기려 해서는 안 된다. 결정이 실제로 중요한 상류 지점에서 기계보다 더 깊이 생각해야 한다.
나는 예전부터 코드를 일일이 읽는 행위에 대해 회의적인 시각을 가지고 있었다. 이전 글에서도 언급했듯이, AI가 코드를 생성하는 시대에 모든 라인을 사람이 직접 검토하는 것은 불가능에 가깝다. 인간의 집중력은 400줄이 넘어가는 시점부터 급격히 떨어진다. 대규모 PR 앞에서 리뷰어는 결국 'LGTM’을 날리는 도장 찍기 단계로 넘어가기 쉽다. 이는 보안 사고나 논리적 오류를 방치하는 위험한 결과를 초래한다. 검토하지 않은 코드를 동료에게 떠넘기는 행위는 협업의 본질을 훼손하는 것이다. 생성 비용이 0에 수렴할수록 가치의 중심은 생성이 아니라 검증으로 이동해야 한다.
도메인 지식과 암묵적인 룰, 즉 부족 지식은 AI가 쉽게 대체할 수 없는 영역이다. 우리 회사의 작년 히스토리나 특정 결제 모듈이 왜 그렇게 복잡하게 설계되었는지, 과거의 어떤 실패 경험 때문에 이런 제약 조건이 생겼는지는 오직 인간만이 알고 있다. 이러한 맥락을 스펙과 검증 규칙에 녹여내는 것이 AI 시대 엔지니어의 핵심 역량이다. 단순히 코드를 잘 타이핑하는 시대는 끝났다. 이제는 AI가 만든 결과물을 비판적으로 평가하고 우리만의 특수한 비즈니스 상황에 맞게 교정할 수 있는 능력이 훨씬 중요하다.
결국 우리는 '무엇을 썼는가’가 아니라 '무엇을 해결하려 하는가’를 확인하는 과정으로 나아가야 한다. diff가 아니라 스펙을 리뷰하고, 구문이 아니라 맥락을 리뷰해야 한다. 미래는 빠르게 배포하고 모든 것을 관찰하며 더 빠르게 되돌리는 시대다. 천천히 리뷰하면서도 버그를 놓치고 프로덕션에서 디버깅하는 시대가 아니다. 당신의 이름으로 배포된 코드에 대해 끝까지 책임을 질 수 있는 능력을 갖추는 것, 그것이 AI 시대에 살아남는 유일한 길이다.
관련 글
코드 리뷰 언제까지 해야할까