AI 빌더에게 작동하는 로그인 플로우를 만들어 달라고 요청해 보세요 — 폼, 유효성 검사, 라우트, 데이터베이스 확인까지. 보통 diff가 나타나기까지 35초에서 90초 정도 기다리게 됩니다. 이 요청을 처음부터 끝까지 프로파일링해 보면, 모델 자체, 즉 실제로 토큰을 생성하는 부분은 그중 약 3~4초에 불과합니다. 네트워크 왕복이 1~2초를 더합니다. 나머지 30초 이상, 즉 여러분이 "AI가 생각 중"이라고 느끼는 부분은 거의 전부 다른 무언가입니다. 에이전트 팀이 파일을 읽고, 빌드를 실행하고, 결과를 보여주기 전에 자체적으로 작업을 검토하는 시간입니다.
이 비율은 이 분야를 직접 만드는 엔지니어들을 포함해 대부분의 사람들이 처음 측정 결과를 보면 놀라는 부분입니다. 더 크고 느린 모델이 병목일 것이라는 직관 때문에, 빌드가 느리면 더 빠른 모델을 쓰면 해결될 것이라 생각하기 쉽습니다. 때로는 맞는 말이지만, 대부분의 경우는 그렇지 않습니다. 그 이유를 이해하면 프롬프트 크기, 프로젝트 크기, 그리고 빌드가 "멈춘" 것처럼 느껴질 때 무엇을 기대해야 하는지에 대한 사고방식이 달라집니다.
실제로 시간을 채우는 것
"기능 추가" 요청 하나를 단계별로 나눠보면 패턴이 바로 드러납니다. 모델은 짧고 저렴한 구간에서 시간을 씁니다 — 다음에 무엇을 할지 결정하고, 도구 호출을 작성하고, 결과를 읽는 식입니다. 반면 비용이 크고 느린 부분은 그 사이사이, 즉 디스크와 셸에서 일어납니다.
| 단계 | 전체 시간에서 차지하는 일반적인 비율 | 실제로 일어나는 일 |
|---|---|---|
| 모델 추론(생성) | 5–10% | 토큰이 생성되는 단계 — 계획, 코드, 도구 호출 인자 |
| 파일 읽기 / 컨텍스트 구성 | 10–15% | 기존 파일, 이전 실행 기록, 프로젝트의 관례를 불러오는 단계 |
| 도구 실행(쓰기, 셸, 패키지 설치) | 35–45% | 실제로 파일을 변경하고, 린터를 실행하고, 의존성을 설치하는 단계 |
| 빌드 / 컴파일 단계 | 15–25% | 프레임워크 빌드, 타입 체크, 번들링 — 프롬프트 크기가 아닌 프로젝트 크기에 비례해 늘어납니다 |
| 검증 에이전트 | 15–20% | 결과를 보여주기 전에 diff가 요청한 대로 작동하는지 확인하는 2차 검토 |
| 네트워크 / 스트리밍 오버헤드 | 2–5% | 모델, 샌드박스, 브라우저 간의 왕복 통신 |
이 표를 나란히 놓고 보기 전에는 잘 드러나지 않는 두 가지 사실이 있습니다. 첫째, 빌드 단계는 프롬프트 크기가 아니라 프로젝트 전체 크기에 비례해 늘어납니다 — 400개 파일짜리 앱에서의 한 줄짜리 CSS 수정이 새 프로젝트에 추가한 5개 파일짜리 기능보다 검증에 더 오래 걸릴 수 있습니다. 컴파일러가 확인해야 할 양은 어느 쪽이든 많기 때문입니다. 둘째, 가장 큰 지렛대는 모델이 전혀 아닙니다. 바로 얼마나 많은 부분이 건드려지는가입니다.
이런 착각이 유지되는 이유
스트리밍 인터페이스도 어느 정도 원인이지만, 좋은 의미에서 그렇습니다. 첫 토큰은 보통 1초 안에 나타나므로 UI는 즉시 반응하는 것처럼 느껴집니다 — 계획이 세워지고, 문장이 타이핑되고, 도구 호출이 스크롤되는 모습이 보이니까요. 사람들이 "AI의 속도"로 체감하는 것은 바로 이 첫 토큰 지연 시간입니다. 잘 보이지 않는 부분은, 모델이 무엇을 할지 결정을 마치고 나면 언어 모델링과는 전혀 관련 없는 빌드 파이프라인으로 작업이 넘어간다는 점입니다. `docker build`, `npm install`, import 그래프를 따라가는 타입 체커 — 이런 것들은 GPT-5가 GPT-4를 대체했다고, 혹은 Sonnet의 최신 버전이 이전 버전을 대체했다고 해서 빨라지지 않습니다. 누군가 의존성 레이어를 캐싱하거나 불필요한 검사를 건너뛰었을 때 빨라집니다.
저는 빌더들이 "느린" 빌드를 고치겠다고 프로젝트 중간에 모델을 바꾸는 모습을 본 적이 있습니다 — 같은 주에 두 번이나요. 실제 병목은 저장할 때마다 증분 검사가 아닌 전체 타입 체크를 다시 실행하는 검증 단계였다는 것을 나중에야 깨달았죠. 모델을 바꿔도 아무것도 달라지지 않았습니다. 모델은 애초에 느린 부분이 아니었으니까요.
실제로 문제가 되는 지점
실제로 이런 결과는 몇 가지 예측 가능한 곳에서 나타납니다:
- 크고 복잡한 프롬프트는 유독 느리게 느껴집니다 — 모델이 이를 파싱하는 데 어려움을 겪어서가 아니라, 12개 파일을 건드리는 요청이 12번의 파일 읽기, 12번의 쓰기, 그리고 이 모든 것을 조정해야 하는 빌드를 유발하기 때문입니다.
- 프로젝트가 커질수록 반복 작업이 느려집니다. 각 프롬프트 자체는 단순하게 유지되더라도, 빌드와 검증 단계는 전체 프로젝트 크기에 비례해 늘어나기 때문입니다.
- "멈췄다"는 것은 모델이 멈춘 경우가 거의 없습니다. 대부분은 빌드 단계가 패키지 레지스트리를 기다리고 있거나, 검증 에이전트가 다시 실행할 필요가 없는 검사를 재실행하고 있는 것입니다.
- 큰 요청 하나를 여러 개의 작은 요청으로 나누면 전체적으로 더 빨리 끝나는 경우가 많습니다. 각각의 작은 요청이 더 좁은 범위의 빌드와 가벼운 검증 단계를 유발하기 때문입니다. 개별 단계를 더 많이 기다리게 되더라도 말이죠.
저희 디스코드의 한 메이커는 이렇게 표현했습니다: "저는 계속 더 빠른 두뇌를 요청하고 있었는데, 사실 필요했던 건 더 작은 diff였습니다."
실제로 대기 시간을 줄이는 방법
진짜 해결책 중에 더 큰 모델이 필요한 것은 없습니다. 전체 프로젝트가 아니라 변경된 부분만 다시 컴파일하는 증분 빌드는 빌드 단계 비중을 크게 줄여줍니다 — 이것이 활용 가능한 단연 가장 큰 지렛대로, 다른 모든 최적화를 합친 것보다 더 큰 효과를 내는 경우가 많습니다. 실행 사이에 의존성 설치를 캐싱하면 특정 프롬프트와 무관한 도구 실행 단계의 상당 부분이 사라집니다. 매번 전체 코드베이스를 다시 확인하는 대신 실제 diff에 맞춰 검증 범위를 좁히면, 이 단계가 존재하는 전체 코드가 아니라 변경된 부분에 비례하게 됩니다. 그리고 서로 관련 없는 도구 호출을 순차적으로가 아니라 병렬로 실행하는 것 — 예를 들어 관련 없는 파일 세 개를 순서대로가 아니라 동시에 읽는 것 — 은 모델을 전혀 건드리지 않고도 파일 입출력 단계에서 실제 시간을 줄여줍니다.
이 중 화려한 것은 하나도 없습니다. 하지만 바로 이것이 두 빌더가 같은 날 같은 플랫폼에 거의 동일한 프롬프트를 입력하고도 "똑똑함"이나 "빠름"을 완전히 다르게 체감하는 이유입니다 — 실제 차이는 모델 품질이 아니라 프로젝트의 형태에서 비롯됩니다. 여러분이 지켜보고 있던 시계는 사실 모델이 아니었습니다. 그저 그렇게 보였을 뿐입니다.
