Linear가 이달 발표한 수치가 하나 있습니다.

AI 코딩을 팀 전체로 확산한 뒤, 테스트 수가 약 4배 늘었습니다. 그런데 CI 파이프라인 대기 시간은 6분에서 5분 남짓으로, 1분 줄어드는 데 그쳤습니다. 팀은 이 1분을 줄이기 위해 CI 전체를 재설계해야 했습니다.

이 비율이 이상합니다. 생성이 4배 빨라졌는데 왜 대기가 1분밖에 안 줄었을까요?

병목은 사라지지 않는다 — 다른 곳으로 내려갈 뿐이다

AI 코딩 도구가 개발 속도를 올리면 자연스럽게 산출물이 늘어납니다. 코드가 더 많이, 더 빠르게 생산됩니다. 문제는 그 코드를 검증하는 속도는 자동으로 따라오지 않는다는 점입니다.

Microsoft는 GitHub Copilot 핵심 런타임을 AI 에이전트를 활용해 TypeScript 43만 줄에서 Rust 80만 줄로 이식했습니다. 코드 양 기준으로 약 1.9배입니다. 이식이 완료된 뒤 팀이 검증해야 할 표면 또한 1.9배가 됐습니다.

생성 속도가 올라갈수록, 검증 표면이 커집니다. 그리고 검증 표면이 커지면 병목이 이동합니다.

Rails World 2026에서 DHH는 개발자의 역할이 바뀌고 있다고 설명했습니다. 코드를 직접 작성하는 일에서 원하는 결과를 정의하고 생성 과정을 개선하는 일로 이동한다는 것입니다. 이 말은 역할의 소멸이 아니라 역할의 이동입니다. 병목이 이동한 자리에 사람이 가야 한다는 뜻이기도 합니다.

두 층으로 갈라진 병목

같은 날 GeekNews에는 두 개의 코드 이해 도구가 동시에 올라왔습니다. Whiteboard는 AI가 만든 코드의 구조와 변경 이유를 캔버스와 의미 기반 diff로 보여주는 도구이고, Archify는 코드베이스를 아키텍처 다이어그램으로 바꿔주는 도구입니다.

이런 도구가 동시에 주목을 받는다는 건, 검토 대역폭이 여전히 막혀 있다는 신호입니다. AI가 만든 것을 사람이 따라갈 수 없다는 불안이 도구 카테고리 하나를 만들어냈습니다.

병목은 두 층으로 갈라졌습니다.

상단: 무엇을 만들어야 하는지, 완료의 기준이 무엇인지 정의하는 자리입니다. AI는 지시를 실행하지만 무엇이 맞는지는 스스로 알지 못합니다. 이 층의 병목은 여전히 사람이 결과를 정의하는 속도에 달려 있습니다.

하단: 만들어진 것을 사람이 이해하고 검증하는 자리입니다. Linear의 테스트 4배 증가, Microsoft의 1.9배 검증 표면, Whiteboard와 Archify의 등장이 모두 이 층의 이야기입니다.

PM이 서야 할 자리

이 두 층은 자동으로 해결되지 않습니다. 상단은 누군가 결과와 합격 기준을 명확히 써야 하고, 하단은 누군가 검증 파이프라인 설계를 맡아야 합니다.

Linear가 CI를 재설계한 것은 개발자의 실수가 아닙니다. 생성 속도가 올라갔을 때 검증 구조를 먼저 설계하지 않았던 결과입니다. 테스트가 4배 늘기 전에 CI가 그 속도를 감당할 수 있는지 설계 기준을 세운 사람이 없었다는 뜻입니다.

PM은 기능 명세서를 쓰는 사람이 아닙니다. 어떤 상태가 완료인지 정의하고, 그 기준이 코드 검토 전에 세워져 있도록 만드는 사람입니다. 상단의 병목(결과 정의)과 하단의 병목(검증 기준)은 둘 다 PM이 없으면 늦게 발견됩니다.

생성 속도가 올라간 지금, 검증 구조를 누가 설계하고 있는지 물어야 할 때입니다.

당신의 팀에서 AI가 만든 코드의 검증 기준을 처음 쓴 사람은 누구입니까?