'AI가 코드를 짜면 사람이 검토하면 된다.' 얼핏 합리적으로 들린다. 그런데 이 문장에는 전제가 하나 빠져 있다. 인간이 그 코드를 실제로 제대로 검토할 수 있는가. softwaremaxims.com이 공개한 분석에 따르면, 이 전제는 생각보다 훨씬 빨리 무너진다.
코드 리뷰에 관한 경험적 연구들이 공통적으로 제시하는 한계가 있다. 효과적인 리뷰는 1회 세션 기준 1시간, 최대 400 LOC다. 이 임계치를 넘으면 피로와 집중력 저하로 결함 탐지 효율이 급격히 떨어진다. 산술은 단순하다. LLM이 400줄을 생성할 때마다 숙련 개발자 1시간이 필요하다. 현실적인 일일 처리량은 1,000 LOC 미만일 수 있고, 여기에는 보일러플레이트, 테스트, 설정 파일이 모두 포함된다. 단일 테스트 파일 하나가 400줄을 넘는 경우도 흔하다.
더 불편한 사실은 수치의 문제가 아니라 신뢰의 문제라는 점이다. 초기 연구에서 드러난 패턴이 있다. LLM이 생성한 코드를 검토한 사람은 더 적은 결함을 발견하면서도, 모든 결함을 찾았다는 확신은 오히려 더 강하게 보고한다. '검토했으니 됐다'는 확신이 실제 결함 탐지율보다 앞서는 구조다. AI가 생성한 코드가 사람이 짠 코드보다 리뷰하기 쉬운지에 대한 증거도 없다. 오히려 초기 데이터는 반대 방향을 가리킨다.
여기서 AI 에이전트 개발자 커뮤니티(dev.to)가 지적한 '보이지 않는 비용' 개념이 겹친다. 에이전트가 4줄짜리 diff를 만들어냈을 때, diff 자체는 깨끗하다. 테스트도 통과한다. 그런데 그 diff에는 에이전트가 거의 건드릴 뻔했던 코드가 기록되지 않는다. 설정 파일에서 필드 하나를 추가하다가 @requires_admin 데코레이터 바로 옆 라인을 스쳐 지나간 맥락, 에이전트가 선택하지 않은 오류 처리 전략의 대안—이 모든 것이 컨텍스트 윈도우 안에만 존재하고 리뷰어의 화면에는 도달하지 않는다. 리뷰어가 보는 건 결과뿐이다. '왜 이 방향을 선택했는가'는 보이지 않는다.
더 구조적인 모순도 있다. LLM 옹호론은 종종 '사람이 작성하기 고통스러운 코드를 도구가 대신 생산해준다'는 점을 장점으로 내세운다. Bash 스크립트를 예로 들어보자. 구두점 하나의 오타가 무해할 수도, 시스템 전체를 날릴 수도 있는 코드다. 이런 코드를 LLM에게 맡기고 인간이 검토하면 된다는 논리는, 검토하기 가장 어려운 코드를 가장 검토 효율이 낮은 방식으로 처리하겠다는 말이다. 문제를 해결하는 게 아니라 압축하는 것이다.
30년 경력의 IT 컨설턴트가 dev.to에 남긴 글은 이 문제를 다른 각도에서 짚는다. 그는 Claude Code와 작업하면서 패러다임의 전환을 체감했다고 말한다. '무엇을 어떻게 구현할지'를 지시하던 방식에서, '무엇을 왜 원하는지'를 설명하고 세부 구현을 넘기는 방식으로. 그런데 그가 솔직하게 인정하는 것이 있다. 수십 년간 쌓은 결정론적 사고 습관—정확히 이 경험이 강점인지, 지금 당장 버려야 할 반사 반응인지—을 자신도 아직 판단하지 못한다는 것이다.
이 고백이 중요한 이유가 있다. AI-First 워크플로우에서 '인간의 역할'을 논할 때, 흔히 나오는 답이 있다. '판단은 인간이 한다.' 그런데 무엇을 판단하는가. 검토 대상을 선별하는 판단, 리뷰의 깊이를 결정하는 판단, 에이전트가 보여주지 않은 맥락을 복원하는 판단—이것들이 실제로 요구되는 역할이다. 이를 제대로 수행하려면 코드베이스를 깊이 이해하고, 도메인 지식을 갖추고, 에이전트의 생성 로직을 역으로 추론할 수 있어야 한다. 코드를 덜 짜는 대신 덜 생각해도 된다는 뜻이 아니다.
실용적으로 정리하면 이렇다. AI 코드 리뷰 전략에서 팀이 먼저 답해야 할 질문은 세 가지다.
1. 무엇을 전면 리뷰하고, 무엇을 선택적으로 검토할 것인가. 400 LOC/시간이라는 한계는 고정이다. 리뷰 자원의 배분 기준을 '변경 범위'와 '의존성 깊이'로 명시화해야 한다. 표면적 추가(UI 필드, API 연결)와 횡단 관심사 변경(미들웨어, 권한 로직)을 동일한 깊이로 리뷰할 수 없다.
2. 에이전트가 선택하지 않은 것을 어떻게 가시화할 것인가. diff만 보는 리뷰는 에이전트의 컨텍스트를 복원하지 못한다. PR 템플릿에 '에이전트가 고려한 대안과 기각 이유'를 명시하도록 요구하거나, 에이전트 로그를 리뷰 컨텍스트로 첨부하는 구조를 설계해야 한다.
3. AI 생성 테스트를 얼마나 신뢰할 것인가. 에이전트가 짠 코드와 에이전트가 짠 테스트는 같은 컨텍스트 윈도우에서 나온다. 해피 패스는 통과하지만 프로덕션 실패 시나리오—네트워크 타임아웃, 동시 접근, 부분 쓰기—는 명시적으로 지시하지 않으면 포함되지 않는다.
결론적으로, AI가 코드를 짜는 팀에서 인간 리뷰어의 역할은 '더 빠른 검토'가 아니다. 에이전트가 볼 수 없는 것을 보는 것이다. 코드베이스 전체의 일관성, 도메인 비즈니스 로직의 의도, diff 뒤에 숨은 맥락의 복원. 이것들은 LLM이 아직 처리하지 못하는 영역이고, 동시에 인간 리뷰어가 400 LOC 한계 안에서 집중해야 할 진짜 작업이다. AI가 빠르게 쌓는 코드의 신뢰는, 더 많이 검토하는 것이 아니라 더 정확한 지점을 검토하는 것에서 온다.