Shopify의 CTO는 요즘 PR 리뷰에 집착한다고 공개적으로 밝혔다. 그의 팀은 이미 Claude Opus 토큰을 무제한으로 쓴다. 생성은 사실상 해결된 문제다. 그런데 왜 배포 사이클은 오히려 길어지고 있을까.
답은 불편하지만 단순하다. AI가 쓴 코드는 줄당 버그 밀도가 인간 코드보다 낮다. 하지만 절대 생산량이 폭발적으로 늘었기 때문에, 프로덕션에 도달하는 버그의 절대 수는 오히려 증가했다. dev.to에 공유된 Shopify 사례 분석이 정확히 짚은 지점이다. 생성이 병목이던 시대는 끝났다. 지금 막히는 곳은 리뷰·테스트·병합·배포 레이어 전체다.
Shopify가 내놓은 해법은 비쌌다. 한 에이전트가 코드를 쓰면 다른 모델이 비평하고, 다시 수정하는 크리틱 루프를 설계했다. 병렬 에이전트 스웜보다 느리지만 품질이 높다는 판단 아래, 자체 PR 리뷰 시스템까지 직접 만들었다. 시중 툴이 속도를 최적화할 때 그들은 깊이를 최적화했다. 토큰 예산 철학도 바뀌었다. 중요한 비율은 '생성된 토큰 수'가 아니라 생성 대 리뷰의 예산 분할이다.
검증 구조 문제는 툴링에서 끝나지 않는다. 더 근본적인 원인이 있다. AI는 당신이 묘사한 문제만 풀 수 있다. 당신이 실제로 가진 문제가 아니라. dev.to의 프롬프트 엔지니어링 분석 아티클이 1년간 수백 건의 AI 코드 평가를 거쳐 내린 결론이다. 실패 모드는 무작위가 아니다. 거의 모든 경우 명세의 공백으로 귀결된다.
실제로 코드 프롬프트에서 빠지는 정보는 네 가지 범주로 압축된다. 실행 환경(코루틴인지, 서버리스인지, 단일 스레드인지), 실패 케이스(네트워크 타임아웃, 널 입력, 캐시 미스), 비협상 제약(성능 플로어, 보안 요건, API 호환성), 완료 기준(어떤 테스트가 통과해야 "완성"인가). 이 네 가지를 빠뜨리면 모델은 통계적으로 가장 그럴듯한 기본값으로 공백을 채운다. 그 기본값이 OWASP LLM Top 10에 올라 있는 SQL 인젝션 패턴일 수 있다는 게 문제다.
그렇다고 프롬프트를 잘 쓰는 것만으로 검증 인프라 문제가 해결되지는 않는다. 세 번째 사례가 보여주는 지점이 여기다. GitHub Copilot이 버튼 컴포넌트 리팩터를 40초 만에 끝냈다. 코드는 우아했다. 테스트는 12개 터졌다. 설명도, 추적도, 이유도 없었다. '그냥 됐다.' 주니어는 왜 그렇게 짰는지 설명할 수 있고, 시니어는 그 결정을 방어할 수 있다. AI는 그냥 했다.
이 사례에서 진짜 문제는 Copilot이 테스트를 깼다는 사실이 아니다. 팀이 AI에게 '통과'가 무엇인지 알려주지 않았다는 것이다. AI는 예외를 만들지 않는다. 이미 존재하는 시스템을 지수적으로 증폭할 뿐이다. 좋은 패턴은 더 빠르게 좋은 코드가 되고, 정의되지 않은 표준은 더 빠르게 보이지 않는 버그가 된다. AI 도입이 잘 안 되는 팀은 도구가 예측 불가능해서가 아니라 표준이 AI가 볼 수 있는 곳에 없어서 실패한다.
해법은 느리게 가는 것이 아니라 다르게 가는 것이다. 에러 핸들링 패턴, 컴포넌트 구조, 추상화 기준을 먼저 정의하고, 그것을 린트 룰과 아키텍처 테스트로 인코딩한다. 위키에 사는 문서가 아니라 빌드 파이프라인 안에 사는 문서다. PR에 도달하기 전에 실행되는 규칙이다. 그때서야 AI는 빈 공간이 아니라 설명 가능한 경계 안에서 작동한다.
세 가지 사례가 하나의 결론으로 수렴한다. 생성 속도가 팀의 병목이던 시대는 끝났다. 지금 설계해야 할 것은 AI가 쏟아낸 코드를 얼마나 빨리 안전하게 인증할 수 있는가—즉 검증 처리량이다. 그 처리량은 세 층위에서 동시에 올라야 한다. 명세 단계에서 공백을 없애고, 파이프라인 단계에서 표준을 자동 실행하고, 리뷰 단계에서 비평 루프에 충분한 예산을 배분하는 것.
Shopify는 지금 분산 데이터베이스 엔지니어와 ML 인프라 전문가를 채용하고 있다. 머신 속도로 커밋이 밀려들 때 코드 저장소가 어떻게 작동해야 하는지를 재설계할 사람들이다. 이것이 실제 엔지니어링 과제가 이동한 방향을 그대로 보여준다. 생성은 해결됐다. 통합이 남았다. 테크 리드의 다음 설계 과제는 여기에 있다.