4. 이것이 빌드가 자체 검증을 처음 통과해 실제로 작동하는 무언가를 만들어내는 대략적인 지점이다 — 작동하는 페이지, 작동하는 엔드포인트, 누군가를 로그인시키는 로그인 흐름. 11은 사람들이 완성됐다고 선언하고 배포하기까지 빌드가 쌓아 올리는 프롬프트 수의 중앙값이다. 68퍼센트는 첫 작동 버전 이후 전송된 모든 프롬프트 중 사용자가 눈치챌 만한 내부 로직 변화가 전혀 없는 비율이다. 30은 대부분의 사람들이 조용히 멈추는 지점인데, 제품이 완성되어서가 아니라 더 이상 할 말이 없어졌기 때문이다.
이 네 가지 숫자는 같은 패턴을 반복해서 보여준다: 빌드는 빠르게 작동하게 되고, 이후 남은 시간의 대부분을 재구축이 아니라 회자되는 데 쓴다.
벽은 예상한 곳에 있지 않다
이 부분을 주의 깊게 보기 전에 빌더들이 어디서 막히는지 물었다면, 통합 — 결제 제공업체, 인증 콜백, 검증된 발신자 ID가 필요한 SMS API — 이라고 답했을 것이다. 이것들은 실제 마찰 지점이지만, 프롬프트 수가 폭증하는 곳은 아니다. 보통 한두 번의 추가 턴이면 해결된다.
벽은 그것보다 나중에, 즉 작동한 이후에 나타난다. 빌드가 첫 깔끔한 검증 통과에 도달한다 — 페이지가 렌더링되고, 핵심 흐름이 처음부터 끝까지 실행되며, 아무 오류도 발생하지 않는다 — 그런데 멈추는 대신 프롬프트가 계속 이어진다. "헤더를 더 크게 만들어줘." "다른 강조 색을 써봐." "버튼을 좀 더 둥글게 할 수 있을까." "사실 그 첫 버전으로 다시 돌아가자." 이 중 어느 것도 데이터 모델, 라우트, 권한 검사를 건드리지 않는다. 전부 표면적인 것들이다.
왜 "완성"이 멈춤 지점처럼 느껴지지 않는가
이 현상의 일부는 반복 작업이 안에서 어떻게 느껴지는지에 관한 것이다. 빌드가 깨져 있을 때는 무엇을 요청해야 할지 정확히 안다 — 오류를 고치고, 빠진 필드를 추가하고, 연결되지 않은 것을 연결한다. 작동할 때는 목표가 사라진다. 파란색 색조가 틀렸다고 알려주는 오류 메시지는 없다. 이제 근거가 없는 취향 판단을 내리게 되고, 취향 판단은 버그와 달리 무한히 수정 가능하다.
또 다른 이유는 프롬프트 작성이 저렴하고 즉각적이어서, "하나만 더 시도해보자"의 순간적 비용이 거의 0으로 느껴진다는 점이다. 전체적으로는 결코 0이 아닌데도 말이다. 몇 분씩 걸리는 십여 번의 외형 수정은 결국 오후 한나절이 되지만, 그 십여 번 중 어느 한 번도 건너뛸 만큼 비싸게 느껴지지 않는다.
후반부 프롬프트가 실제로 바꾸는 것
| 프롬프트 범위 | 일반적인 대상 | 기능적 변경 여부 |
|---|---|---|
| 1–4 | 핵심 페이지, 데이터 모델, 주요 흐름 | 예 — 제품이 실제로 만들어지는 단계 |
| 5–7 | 예외 상황, 오류 상태, 누락된 필드 | 대개 예 — 실사용 중 발견된 실제 결함 |
| 8–15 | 레이아웃, 카피, 색상, 여백, 톤 | 거의 없음 |
| 16+ | 이전에 내렸던 디자인 결정을 되돌리거나 다시 시도하는 경우 | 거의 발생하지 않음 |
곱씹어볼 가치가 있는 건 바로 그 세 번째 줄이다. 디자인 완성도를 다듬는 작업이 시간 낭비라는 뜻은 아니다 — 평범해 보이는 빌드는 그렇지 않은 빌드보다 성과가 떨어지고, 디자인을 다듬는 과정은 실제로 중요하다. 문제는 그 작업에 여덟에서 열다섯 번의 개별 프롬프트가 필요한 경우가 드물다는 것이고, 그렇게 많은 프롬프트가 필요한 이유는 대개 반복 개선이 아니라 우유부단함 때문이다. 열한 번째 프롬프트 이후에 더 나은 답으로 수렴하고 있는 게 아니라, 아홉 번째 프롬프트에서 이미 만들어낸 두 가지 답 사이를 오가고 있을 뿐이다.
누군가 랜딩 페이지에서 콜투액션 버튼을 세 가지 위치로 옮기는 데 40분을 쓰고, 열네 번째 프롬프트에 이르러서야 첫 번째 위치가 최선이었다고 판단한 뒤, 빌드 에이전트에게 원래대로 되돌려 달라고 요청하는 걸 지켜본 적이 있다. 그 과정에서 에이전트가 잘못한 일은 하나도 없었다. 그 버튼은 애초에 열네 번의 의견이 필요하지 않았을 뿐이다.
20 대 30 격차가 실제로 말해주는 것
가장 놀라웠던 부분은 이거다: 열한 번째 프롬프트 근처에서 멈추는 빌드와 서른 번을 넘겨 이어지는 빌드는 품질 면에서 큰 차이가 없다는 것이다. 나는 더 많은 반복이 분명 더 다듬어진 결과물로 이어질 거라 기대하며 그 근거를 찾아봤지만, 대체로 찾지 못했다. 대신 발견한 것은, 더 일찍 멈추는 빌더들은 대개 처음부터 프롬프트 자체에서 취향에 관한 결정을 한 번에 끝낸다는 사실이었다("깔끔하고 미니멀하게, 포인트 컬러 하나, 스톡 사진 사용 금지"). 결과가 나온 뒤 스무 차례의 시행착오를 거치며 취향을 발견해가는 게 아니었다.
가장 오래 걸린 빌드들은 더 야심찬 시도가 아니었다. 원래 프롬프트에 결정되지 않은 부분이 가장 많이 남아 있던 경우들이었다 — 톤도, 참고 기준도, 명시된 타깃 사용자도 없었기 때문에, 첫 실행 전에 글로 한 번에 정리하는 대신 모든 빈틈을 작은 프롬프트 하나하나로 그때그때 메워야 했던 것이다.
실전에서 얻을 수 있는 결론
네다섯 번의 프롬프트만으로 정상적으로 작동한다면, 그건 중간 점검 지점이 아니라 실제 작업의 대부분이 끝났다는 뜻이다. 남은 일은 실재하지만 작다: 아무도 언급하지 않은 예외 상황을 확인하고, 카피를 한 번 더 점검하고, 여러 번의 탐색적 시도 대신 시각적 톤에 대해 한 번의 신중한 검토를 하는 것이다. 그리고 스무 번째 프롬프트에서도 여전히 모서리 둥글기(border-radius)를 만지작거리고 있다면, 그건 빌드가 미완성이라는 신호가 아니다. 대개는 앞선 프롬프트에서 처음부터 원하는 바를 명확히 말했어야 했다는 신호이며, 그 수정은 이번 빌드의 마흔 번째 프롬프트가 아니라 다음 빌드의 첫 메시지에 담겨야 한다.
