계획 읽기 (그리고 바꾸기)

같은 30초짜리 화면 — 프롬프트와 빌드 사이에 나타나는 계획 카드 — 을 세 사람이 각각 다르게 잘못 다루는 걸 지켜봤고, 각자 다른 대가를 치렀습니다. 한 명은 재빌드로, 한 명은 낭비한 타이핑으로, 한 명은 정작 필요했던 기능을 갖추지 못한 제품으로 대가를 치렀습니다. 계획 카드는 전체 과정에서 마음을 바꾸기 가장 저렴한 순간이며, 그 점이 오히려 쉽게 지나쳐버리게 만드는 이유입니다.

실수 1: 그냥 도장 찍듯 승인하기

가장 흔한 실수입니다. 스켈레톤이 괜찮아 보이면 승인 누르고 넘어가는 것 — 저도 이 문제가 저를 물기 전까지 몇 주 동안 이렇게 했습니다. 그 습관을 깨뜨린 빌드는 Stripe에서 필요로 하는 계정 상태를 저장할 곳이 없는 정적 사이트에 Stripe 결제가 연결되어 돌아온 경우였습니다. 계획 카드에는 제품 유형: 정적 사이트라고 명확히 텍스트로 쓰여 있었지만, 페이지 목록이 괜찮아 보여서 서둘러 넘어가며 지나쳤습니다.

이 실수의 잔해는 항상 같은 형태를 띱니다: 계획 이후의 모든 것은 계획을 전제로는 정확하므로, 실패가 오류로 드러나지 않고 구조적으로 잘못된 정상 작동 빌드로 나타납니다. 아무것도 고장 나지 않았기 때문에 아무도 문제를 짚어내지 못합니다 — 결제 버튼이 달린 정적 사이트는 그냥 조용히 잘못된 일을 하거나, 실제 사용자가 "결제"를 누르는 그 순간에야 실패합니다. 그리고 그걸 알게 되는 곳은 리뷰 단계, 가장 비싼 대가를 치르는 곳입니다.

실수 2: 두 번째 라운드를 피하려고 과도하게 명세하기

반대되는 실수는 더 책임감 있어 보이지만 그렇지 않습니다. 실수 1로 한 번 데인 일부 사람들은 계획 단계에서 정확한 카피, 간격 선호도, 반드시 있어야/없어야 할 기능 등을 스펙 문서처럼 한 문단씩 써 내려가는 방향으로 과잉 교정합니다. 저도 이렇게 해본 적이 있는데, 지금 세부사항을 생략하면 나중에 빌드 라운드를 "낭비"하게 될 거라는 막연한 불안감 때문이었습니다.

이건 거꾸로 된 접근이며, 이유는 다음과 같습니다: 실제 페이지를 본 뒤에는 처음에 아무리 신경 써서 작성했든 계획이 다시 수정될 것입니다. 그리고 수정될 때 바뀐 부분의 차이(diff)를 받는 게 아니라, 수정 사항이 이미 반영된 완전히 새로운 카드를 받게 됩니다 — 패치 노트는 없습니다. 즉 1라운드에서 입력한 정밀함은 어차피 2라운드까지 온전히 유지되지 않으며, 결국 전체를 다시 읽어야 합니다. "아니, 이런 식으로"를 두세 번 반복하는 것이 하나의 방대한 브리프보다 — 브리프를 쓰는 동안은 더 효율적으로 느껴지더라도 — 실제 소요 시간 기준으로 더 나은 결과를 더 빠르게 만들어냅니다.

실제로 효과적인 평이한 언어 수정은 짧습니다:

• "블로그를 빼고 가격 페이지를 추가해줘" — 페이지 목록을 깔끔하게 교체합니다.
• "1인용 대신 2인용으로 만들어줘" — 겉보기보다 큰 변경입니다. 이제 참가자 한 명이 아니라 두 명을 추적하는 데이터 모델에 영향을 줄 수 있으며, 수정된 계획은 그 파급 효과를 숨기지 않고 그대로 보여줍니다.
• "이건 사용자 계정이 필요해" — 현재 계획이 정적 사이트라면, 이 한 문장이 제품 유형 질문을 곧바로 표면화시킵니다.

실수 3: 제품 유형을 유연한 항목으로 취급하기

이게 가장 비싼 실수인데, 카드의 다른 모든 항목은 실제로 되돌릴 수 있기 때문입니다. 페이지, 추론된 기능, 대부분의 분기 질문 — 빌드가 나온 뒤 버전 반복으로 모두 수정 가능합니다. 제품 유형은 그렇지 않습니다. 네 가지 범주가 있습니다:

정적 사이트 계획을 승인한 뒤 세 버전 지나서 로그인을 원하게 되면, 그건 버전 업이 아니라 다른 제품 유형으로부터의 재빌드이며, 다른 모든 부분에 대해 버전 기록이 제공하던 연속성을 잃게 됩니다.

사람들은 이 부분을 두 가지 방식으로 잘못합니다. 첫째, 자신의 프롬프트를 해당 항목과 대조 확인하지 않습니다 — 프롬프트에 "계정", "로그인", "저장", "업데이트되는 대시보드", "결제", "여러 사용자가 같은 것을 편집" 같은 표현이 있는데 카드에 서버 기반이라고 표시되어 있지 않다면, 승인 전에 반드시 수정해야 할 유일한 항목입니다, 예외는 없습니다. 둘째, 설치형 앱과 프레임워크 빌드를 혼동하는데, 둘 다 일상 대화에서는 "앱"처럼 느껴지기 때문입니다. 이 둘은 서로 바꿔 쓸 수 없습니다: 설치형 앱은 모든 상태가 사용자 기기에 저장되는 도구에 적합합니다 — 팁 계산기, 운동 타이머 같은 것입니다. 프레임워크 빌드는 더 많은 상호작용과 컴포넌트 구조를 의미하지만 여전히 세션이나 기기 간에 서버 측에 유지되는 것은 없습니다. 둘 다 계정과 기기 간 이어지는 데이터를 갖춘 의미의 "앱"은 아닙니다 — 서버 기반만이 그렇습니다. 그리고 포트폴리오 사이트나 문서 페이지에 "혹시 몰라서" 서버 기반으로 과잉 준비하는 것도 안전한 선택이 아닙니다 — 나중에 다운그레이드하는 것도 업그레이드만큼이나 재빌드입니다.

이 세 가지 실수를 피하고 나면 남는 것

제품 유형 항목을 대충 훑지 않고, 계획 단계에서 스펙을 쓰지 않고, 프롬프트 속 계정/데이터/결제 관련 표현을 협상 가능한 것으로 취급하지 않으면, 남는 건 빠르고 좁은 체크리스트입니다:

1. 제품 유형을 읽는다.
2. 프롬프트와 대조 확인한다.
3. 추론된 기능 목록을 훑어보며 한눈에 거부할 만한 것이 있는지 확인한다.

이 목록이 존재하는 이유는, "미용실용 예약 도구" 같은 프롬프트가 입력하지 않은 것들까지 끌어들이기 때문입니다 — 캘린더 뷰, 문자 알림, 고객 목록 등, 그중 일부는 의도한 것이고 일부는 통계적으로 함께 등장하는 경향 때문에 모델이 추가한 스코프 확장입니다. 빌드된 후가 아니라, 여기서 문장 하나로 필요 없는 것을 잘라내세요.

그 외 모든 것 — 카피, 간격, 강조색의 명도, 버튼에 "시작하기"라고 쓸지 "무료로 사용해보기"라고 쓸지 — 은 카드에 아예 없습니다, 의도적으로요. 이런 것들은 완성된 빌드에서 확인하고 고치기 저렴하므로 카드가 당신의 주의를 낭비하지 않으며, 당신도 그럴 필요가 없습니다. 카드를 읽는 데 걸리는 30초 중 실질적인 판단이 필요한 부분은 15초 정도입니다.