AI 코딩 시대에 우리가 리뷰해야 할 것들
최근 개발 환경의 변화를 지켜보면 AI가 코드를 작성하는 속도가 인간의 검토 속도를 아득히 추월하고 있다는 사실을 체감한다. 많은 개발자가 Claude Code 같은 도구를 활용해 생산성을 비약적으로 높였지만, 아이러니하게도 팀 전체의 속도는 오히려 정체되거나 느려지는 현상이 발생하고 있다. 한 조사에 따르면 AI 도입률이 높은 팀은 PR(Pull Request) 생성량이 98%나 증가했지만, 정작 리뷰에 소요되는 시간은 91%나 늘어났다고 한다. 이러한 불균형은 결국 코드 리뷰라는 전통적인 안전망이 AI 시대의 생산성을 감당하지 못한다는 걸 의미한다.
나는 예전부터 코드를 일일이 읽는 행위에 대해 회의적인 시각을 가지고 있었다. 이전 글에서도 언급했듯이, AI가 코드를 생성하는 시대에 모든 라인을 사람이 직접 검토하는 것은 불가능에 가깝다. 특히 AI는 한 번의 프롬프트로 수백 줄의 코드를 순식간에 만들어내는데, 인간의 집중력은 400줄이 넘어가는 시점부터 급격히 떨어진다는 통계가 있다. 즉, 대규모 PR을 앞에 둔 리뷰어는 코드를 꼼꼼히 살피기보다는 대충 훑어보고 'LGTM(Looks Good To Me)'을 날리는 도장 찍기 단계로 넘어가기 쉽다. 이는 보안 사고나 논리적 오류를 방치하는 위험한 결과를 초래한다.
이런 상황에서 우리가 직면한 가장 큰 문제는 에이전틱 엔지니어링의 안티패턴이다. 사이먼 윌리슨이 지적했듯이, 검토하지 않은 코드를 동료에게 떠넘기는 행위는 협업의 본질을 훼손한다. AI가 만들어준 수천 줄의 코드를 그대로 PR로 올리는 것은 사실상 동료에게 대신 일을 해달라고 요구하는 것과 다름없다. 올린 사람조차 코드를 완벽히 이해하지 못하는데 리뷰어가 이를 잡아내길 기대하는 것은 어불성설이다. 생성 비용이 0에 수렴할수록 가치의 중심은 생성이 아니라 검증으로 이동해야 한다. 코드를 만드는 건 AI가 더 잘할지 몰라도, 그 코드가 우리 시스템에 적합한지, 그리고 비즈니스 요구사항을 정확히 충족하는지 판단하는 것은 여전히 인간의 몫이다.
여기서 재미있는 비유가 하나 등장한다. 통신 이론 중 나이퀴스트-섀넌 표본화 정리라는 것이 있다. 신호를 정확히 복원하려면 최고 주파수의 2배 이상으로 샘플링해야 한다는 원리다. 이를 소프트웨어 개발에 적용해 보면, AI는 엄청나게 높은 주파수로 코드를 생산해내고 있는 반면, 인간의 수동 리뷰는 아주 낮은 주파수의 샘플링 메커니즘에 불과하다. 생산 속도가 검출 속도를 압도하면 결함은 단순히 이따금 발생하는 수준을 넘어 체계적으로 누적될 수밖에 없다. 이것이 바로 언더샘플링의 문제다. 우리가 피드백의 주기를 높이지 않고 생산량만 늘린다면, 결국 코드베이스는 통제 불가능한 괴물이 되어버릴 것이다.
그렇다면 해결책은 무엇일까? 일부에서는 사람이 코드를 리뷰하는 시대가 끝났다고 주장한다. StrongDM 같은 회사는 아예 인간이 코드를 쓰지도, 리뷰하지도 않는 ‘소프트웨어 팩토리’ 모델을 구축했다. 인간은 오직 의도를 정의하고 시나리오를 큐레이션하며 제약 조건을 설정한다. 이후의 과정은 에이전트들이 코드를 생성하고, 디지털 트윈 환경에서 검증하며, 통과할 때까지 반복한다. 여기서 코드 리뷰는 '검증 자동화’로 대체된다. 물론 보안 인프라를 만드는 회사가 이런 방식을 택했다는 점은 놀랍지만, 한편으로는 에이전트가 만들고 에이전트가 테스트한 결과물을 과연 누가 온전히 신뢰할 수 있느냐는 근본적인 질문이 남는다.
세일즈포스의 사례는 좀 더 현실적인 대안을 제시한다. 그들은 AI 보조 코딩 도입 후 PR의 규모가 감당할 수 없을 정도로 커지자 '의도 재구성(Intent Reconstruction)'이라는 접근법을 도입했다. 단순히 코드의 차이점(diff)을 보는 게 아니라, AI가 왜 이 코드를 이렇게 작성했는지 그 의도를 파악하고 요약해 주는 시스템을 만든 것이다. 이는 리뷰어의 인지 부하를 줄여주는 데 효과적이다. 하지만 나아갈 방향은 여기서 한 발 더 나아가야 한다. 바로 '코드 리뷰’에서 '의도 리뷰’로의 전환이다.
나는 코드 리뷰를 할 때 모델 여러 개를 활용해 크로스체크를 하는 방식이 인간 한 명의 리뷰보다 더 정교할 수 있다고 생각한다. 보안 전문가 역할을 하는 에이전트, 성능 최적화에 특화된 에이전트, 그리고 아키텍처 규칙을 감시하는 에이전트를 각각 배치하여 검토하게 하는 것이다. 하지만 여기서 절대 놓쳐서는 안 될 지점이 있다. 바로 도메인 지식과 암묵적인 룰, 즉 '부족 지식(Tribal Knowledge)'이다. 아무리 뛰어난 AI라도 우리 회사의 작년 히스토리나 특정 결제 모듈이 왜 그렇게 복잡하게 꼬여 있는지, 과거의 어떤 실패 경험 때문에 이런 제약 조건이 생겼는지는 알지 못한다. 이러한 맥락은 오직 인간만이 가지고 있는 고유한 자산이다.
따라서 미래의 엔지니어는 라인별 코드를 읽는 '독자’가 아니라, 전체적인 시스템을 설계하고 검증 레이어를 구축하는 '품질 보증자(QA)'가 되어야 한다. 나는 현재 내가 AI로 작성한 코드를 일일이 한 줄씩 읽지 않는다. 대신 그 코드가 의도한 대로 동작하는지 확인하기 위해 테스트 케이스를 촘촘하게 설계하고, 프로덕션과 유사한 환경에서 실제 시나리오를 돌려본다. 문제가 발생했을 때만 코드를 파고들어 원인을 분석한다. 즉, 구현의 세부 사항보다는 결과물의 동작과 비즈니스 로직의 정합성에 집중하는 것이다.
안킷 제인이 제안한 것처럼, 신뢰를 겹겹이 쌓는 '스위스 치즈 모델’을 적용해 볼 수 있다. 여러 에이전트가 다른 접근 방식으로 코드를 작성하게 하여 최선의 선택을 유도하는 것이 첫 번째 레이어라면, 테스트 코드와 정적 분석 도구 같은 결정론적 가드레일이 두 번째 레이어가 된다. 그리고 세 번째 레이어에서 인간이 수용 기준(Acceptance Criteria)을 사전에 정의하고 최종적으로 맥락을 검토한다. 이렇게 필터를 여러 겹 겹치면 단일 게이트가 놓칠 수 있는 구멍들을 효과적으로 막을 수 있다.
결국 AI 시대의 코드 리뷰는 '무엇을 썼는가’가 아니라 '무엇을 해결하려 하는가’를 확인하는 과정이어야 한다. diff가 아니라 스펙을 리뷰하고, 구문이 아니라 맥락을 리뷰해야 한다. 이전 시대의 개발자가 코드를 잘 타이핑하는 능력이 중요했다면, 지금은 AI가 만든 결과물을 비판적으로 평가하고 우리만의 특수한 비즈니스 도메인에 맞게 교정할 수 있는 능력이 훨씬 중요하다. 이는 엔지니어가 제품 매니저(PM)의 시각까지 갖춰야 함을 의미한다. 요구사항을 명확히 하고, 완료의 정의를 세밀하게 내리며, 시스템의 관찰 가능성을 확보하는 일 말이다.
과거에는 뛰어난 시니어 개발자 한 명이 밤을 새워 리뷰하며 퀄리티를 지탱했지만, 이제는 시스템적인 자동 검증 인프라를 구축하고, 인간은 그 시스템이 포착하지 못하는 고차원적인 결정과 책임의 영역에 머물러야 한다.
결론적으로 나는 AI를 활용한 크로스체크가 코드의 품질을 높이는 데 기여할 것이라고 확신한다. 하지만 그 책임의 주체는 변하지 않는다. 코드를 쓴 것이 AI라 할지라도, 그 코드를 머지하고 프로덕션에 내보내기로 결정한 주체는 인간이기 때문이다. 당신은 당신의 이름으로 배포된 코드에 대해 끝까지 책임을 질 수 있는가? 이 질문에 답할 수 있는 능력이 바로 AI 시대에 살아남는 엔지니어의 핵심 역량이 될 것이다.
관련 글
AI 코딩 시대에 우리가 리뷰해야 할 것들