문제는 속도가 아니다, 속도의 비대칭이다
AI 코딩 도구를 팀에 도입하고 나서 가장 먼저 체감하는 건 생산성 향상이 아니다. 리뷰 병목이다. Claude Code로 하루에 700줄짜리 diff를 뽑아내는 건 이제 어렵지 않다. 문제는 그 700줄을 책임감 있게 검토할 수 있는 사람의 주의력은 예전과 똑같이 제한돼 있다는 것이다.
dev.to에 올라온 Zenovay 빌더의 글이 이 감각을 정확히 짚는다. "Generation got cheap. Review did not." 코드 생성 비용은 거의 0에 수렴했지만, 리뷰 비용은 그대로다. 솔로 개발자 한 명이 팀 수준의 코드를 쏟아낼 수 있게 된 순간, 검토 용량은 여전히 한 명 분이다. 팀으로 넘어오면 이 비대칭은 더 심해진다. 에이전트는 지치지 않고, 사람은 지친다.
가장 위험한 코드는 '돌아가는 코드'다
AI가 생성한 코드의 실패 패턴은 컴파일 에러가 아니다. 해피패스 테스트는 통과하고, 권한 체크는 UI 레이어에만 있고, 재시도 로직이 이벤트를 중복 발행한다. 조용히 틀리는 코드다. Zenovay 개발자가 스스로 던지는 질문들이 이 위험을 정확히 열거한다. "Does this retry create duplicate events? Is the permission check happening at the API boundary, or only in the interface?" 이런 질문은 diff를 스크롤하다 보면 절대 안 보인다. 코드가 '어떻게 동작하는지'를 이미 알고 있어야 발견할 수 있다.
더 근본적인 문제는 이해의 지연이다. 빠르게 수락한 AI 코드 한 줄 한 줄은 미래의 부채가 된다. 6개월 뒤에 아무도 왜 그 함수가 그렇게 짜여 있는지 기억 못 한다. 코드는 빠르게 생성됐고, 이해는 이월됐다.
핵심 원칙: 생산자는 검증자가 될 수 없다
이 문제를 해결하는 설계 원칙은 새로운 게 아니다. 컴파일러, CI, 코드 리뷰, 뮤테이션 테스팅이 모두 같은 전제 위에 서 있다. 만든 것을 만든 쪽이 인증해선 안 된다. Producer is not Validator.
dev.to에 공개된 AI QA 파이프라인 사례(ai-qa-pipeline)는 이 원칙을 실제 Playwright 테스트 스위트에 구현한다. 구조는 단순하다. 각 단계의 출력물은 그것을 만들지 않은 다른 주체가 검토한다. Feature Reviewer는 테스트 가능성을 판단하고, Writer는 실제 코드를 생성하고, Judge는 다른 모델(기본값은 더 강력한 Opus)이 독립적으로 검토한다. 실제 Playwright 실행은 exit code로 판정한다—모델의 의견이 아니라.
특히 눈여겨볼 부분은 Debugger 에이전트의 계약이다. 로케이터나 대기 로직은 수정할 수 있지만, 어떤 어설션도 건드릴 수 없다. 그리고 파이프라인은 이 '말로 된 계약'을 믿지 않는다. 디버깅을 거친 스펙은 반드시 Judge를 다시 통과해야 한다. 어설션을 몰래 약화시켜 억지로 그린을 만든 코드는 이 단계에서 걸린다. 'pass를 위해 덜 주장하는 것'이 가장 흔한 에이전트 치트인데, 이걸 구조적으로 차단한다.
팀 워크플로우로 확장할 때 바뀌어야 하는 것
18개월간 AI 도구를 자신의 전체 업무에 dogfooding해온 솔로 빌더의 경험도 같은 방향을 가리킨다. 세션이 바뀔 때마다 컨텍스트가 리셋되는 문제, 모델이 컨텍스트를 잃으면 이미 고친 트랩을 다시 만드는 문제. 솔로에서도 이렇게 어렵다면, 팀에서는 구조 없이는 불가능하다.
팀 단위로 AI-First 워크플로우를 설계할 때 실질적으로 바꿔야 할 것들을 정리하면 이렇다.
첫째, 리뷰 단위를 줄여라. AI가 생성한 코드를 한꺼번에 리뷰하면 반드시 놓친다. Zenovay 개발자가 실천하듯, 각 변경을 리뷰 가능한 크기로 나눠 요청하는 것을 팀 컨벤션으로 박아야 한다. PR 크기 제한은 AI 시대에 더 중요해졌다.
둘째, 판단의 자리를 명시적으로 남겨라. 데이터 프라이버시 경계, 인가 로직, DB 마이그레이션, 빌링 로직—AI가 구현을 도울 수 있지만 규칙 자체는 사람이 결정해야 한다. 이 경계를 팀 문서로 명시하지 않으면 에이전트는 '가장 일반적인 답'을 골라버린다. 그게 당신 제품에 맞는 답이 아닐 수 있다.
셋째, 검증 파이프라인을 코드로 굳혀라. Producer-Validator 분리는 원칙이 아니라 구조여야 한다. AI가 쓴 테스트를 AI가 검토하는 닫힌 루프는 파이프라인 설계 단계에서 제거해야 한다. 다른 모델, 다른 벤더, 실제 런타임 실행—검증 레이어는 최소 하나 이상 생산 주체와 독립돼야 한다.
전망: 검증 설계가 팀의 진짜 경쟁력이 된다
앞으로 AI 코드 생성 속도는 더 빨라진다. 에이전트가 더 자율적으로 작동한다. 그 속도를 팀이 감당할 수 있느냐는 생성 도구의 문제가 아니라 검증 파이프라인 설계의 문제다.
AI-First 팀에서 테크 리드의 역할 변화가 여기서 나온다. 코드를 더 잘 짜는 사람이 아니라, 어떤 코드가 신뢰할 수 있는지 판별하는 구조를 설계하는 사람. 'AI가 짠 코드를 팀이 어떻게 믿을 것인가'라는 질문에 구조적으로 답하지 못하면, AI 도구 도입은 생산성 향상이 아니라 리뷰 부채 적립으로 끝난다.
"Could I explain this change to another developer without mentioning the AI?" Zenovay 개발자가 머지 직전에 스스로 던지는 이 질문—팀 리뷰 프로세스의 마지막 게이트로 삼을 만하다.