빌드 프롬프트에는 실제로 무엇이 들어가야 할까요?
네 가지이며, 이렇게 말할 수 있는 건 이런 프롬프트가 완성된 사이트로 바뀌는 걸 약 200번 정도 지켜본 뒤입니다: 무엇인지, 누구를 위한 것인지, 필수 요건, 그리고 선택적으로 분위기입니다. 그 외 나머지는 어차피 빌더가 기본값으로 채울 잡음입니다 — 진짜 필요한 기술은 더 많이 쓰는 게 아니라, 이 네 가지 중 실제로 의견이 있는 항목이 무엇인지 알아채고 그것만 말하는 겁니다.
먼저 "무엇인지"부터 시작하되, 스펙이 아니라 카테고리 수준으로 유지하세요. "요가 스튜디오를 위한 예약 사이트"가 "사람들이 시간을 보고 버튼을 눌러 자리를 예약하고 확인을 받는 사이트"보다 정보량은 적어도 더 낫습니다. 카테고리는 빌더가 이미 가진 기본값을 활성화합니다 — 일정은 일정처럼, 예약 흐름은 예약 흐름처럼 보이게 됩니다 — 반면 설명은 빌더가 처음부터 카테고리를 재구성하게 만듭니다.
대상을 명시해야 하나요?
꼭 그럴 필요는 없지만, 사람들이 생략해서는 안 되는데 생략하는 항목입니다. "스튜디오의 기존 수강생을 위한"과 "스튜디오를 처음 접하는 사람들을 위한"은 거의 모든 중요한 지점에서 다른 사이트를 만들어냅니다 — 카피 톤, 큰 마케팅 히어로 섹션이 있을지 아니면 바로 일정으로 넘어가는 레이아웃일지, 가격을 앞에 배치할지(신규 방문자에게 필요) 아니면 숨겨둘지(단골은 이미 알고 있음) 등. 여기 문장 하나가 기능 요청 페이지 전체로도 해결하지 못할 수백 가지 사소한 모호함을 해결할 수 있습니다. 대상이 정말로 일반적이라면 생략하세요 — 그 항목을 채우기 위해 억지로 만들어내지 마세요.
필수 요건은 몇 개나 나열해야 할까요?
두세 개입니다. 제가 쓰는 테스트는: 이게 없으면 첫 빌드를 거부하겠는가? "수업 일정, 온라인 결제, 강사 소개"는 요가 스튜디오에 대해 이 테스트를 통과합니다 — 일정이 없으면 사이트의 축소판이 아니라 다른 사이트입니다. "푸터에 뉴스레터 가입"은 거의 통과하지 못합니다. 그건 있으면 좋은 것이고, 있으면 좋은 것들은 계획을 본 뒤 후속 대화에 넣어야지, 중요한 것들과 경쟁하며 처음 프롬프트에 밀어 넣을 게 아닙니다.
솔직히 이 부분이 사람들이 양방향으로 가장 망치는 요소입니다. 필수 요건이 0개면 빌더가 추측하고, 때로는 틀립니다. 8개면 빌더가 8개 모두를 똑같이 중요하게 취급하고, 결과물은 웹사이트 탈을 쓴 기능 목록처럼 읽힙니다 — 위계도 없고, 숨 쉴 공간도 없습니다. 만약 딱 하나의 요소를 절대 생략하지 말라고 강조해야 한다면 바로 이겁니다. "이걸 당신다운 것으로 만드는 두 가지"라는 단 한 문장만으로도 거의 매번 한 라운드를 절약할 수 있습니다. 카테고리만으로는 빌더가 유추할 방법이 없는 유일한 정보이기 때문입니다.
분위기를 지정해야 할까요?
있는 경우에만 그렇습니다. 이 항목을 아예 생략하는 좋은 프롬프트도 많고, 그래도 괜찮습니다 — 디자인 디렉터는 무드를 지정하든 안 하든 아트 디렉션을 스스로 정합니다. "따뜻하고 손으로 그린 느낌", "임상적이고 빠른 느낌", "90년대 오락실 같은 느낌" 같은 두 단어짜리 무드는 그 결정이 향하는 방향을 카테고리의 기본값 대신 지정해줄 뿐입니다. 강한 취향이 있다면 — 크림색 배경과 따뜻한 세리프 서체를 원한다는 걸 알거나, 둥근 모서리가 싫다는 걸 안다면 — 그 한 문장을 아끼지 마세요. 참고로 "깔끔하고 모던하게"는 여기 해당하지 않습니다. 그건 무드가 아니라 무드의 부재이며, 자리를 차지하면서도 방향을 전혀 제시하지 않습니다.
생각하는 걸 전부 다 설명하면 안 되나요?
빌더가 그대로 따르기 때문입니다. 이게 실제 실패 원인이고, 사람들이 예상하는 것과는 다릅니다 — 정보가 너무 많아서 빌더가 혼란스러워지는 게 아니라, 여러분이 쓰는 모든 문장이 지시로 읽히기 때문입니다. 다시 보면 얼마든지 버릴 만한 반쯤 형성된 생각까지 포함해서요. "후기 섹션도 넣을까, 잘 모르겠지만"이라고 쓴 사람이 플레이스홀더 후기 세 개가 들어간 후기 섹션을 그대로 받는 걸 본 적이 있습니다. "넣을까, 잘 모르겠지만"은 사람이 읽으면 망설임이지만, 여러분의 말을 그대로 받아들이는 시스템에게는 기능 요청이기 때문입니다.
명세를 부족하게 하는 것이 비쌌다면 이건 문제가 되지 않았을 겁니다. 사람으로 구성된 개발팀과 함께 일할 때처럼, 모호함 때문에 잘못된 결과물이 나온 걸 2주 후에야 알게 되는 상황이라면요. 하지만 여기서는 비싸지 않습니다. 빌더는 빌드하기 전에 계획을 세우므로 — 코드가 확정되기 전에 구체적인 제안을 먼저 보게 됩니다 — 명세 부족은 채팅에서 5분짜리 수정 정도의 비용밖에 들지 않는 반면, 명세 과잉은 정보가 가장 부족한 바로 그 순간에 가장 미완성된 아이디어들을 전부 미리 반영해버립니다. 실제 요구사항 10단어가 의식의 흐름 200단어보다 낫습니다. 정보가 많은 게 원래 나쁘기 때문이 아니라, 바로 이 인터페이스에서는 한 단어 한 단어가 곧 약속이기 때문입니다.
더 조용한 대가도 있습니다: 우선순위가 사라진다는 것입니다. 기능 열두 개를 똑같은 비중으로 나열하면 빌더는 여러분이 실제로 무엇을 중요하게 여기는지 알 수 없어서, 열두 개 모두에 동일한 시각적 무게를 주거나(어수선해짐) 우선순위를 추측합니다(때로는 틀리고, 이제는 선호를 말하는 대신 추측을 디버깅하게 됩니다). 반드시 필요한 것 세 가지를 명확히 말하면 이 우선순위가 지켜집니다. 열두 개를 문단으로 나열하면 사라집니다.
좋은 프롬프트는 실제로 어떤 모습인가요?
| 프롬프트 | 왜 이게 잘 작동하는가 |
|---|---|
| "클라이머를 위한 트레이닝 로그 — 세션, 등급, 진행 차트." | 무엇을 만들지에 반드시 필요한 것 세 가지를 더해 총 10단어짜리 요구사항입니다. 대상 사용자 언급은 없는데, "클라이머가 자신의 훈련을 기록한다"는 것은 카테고리만 봐도 명백하기 때문입니다 — 아무런 역할도 하지 않는 유일한 요소를 정확히 생략한 사례입니다. |
| "도시 농업을 다루는 제 팟캐스트를 위한 랜딩 페이지, 따뜻하고 에디토리얼한 느낌, 에피소드 목록과 구독 폼 포함." | 무엇을(대상은 "제 팟캐스트"에서 암시됨), 무드, 기능 두 가지. 어떤 플레이어로 에피소드를 임베드할지, 한 페이지에 몇 개를 보여줄지는 언급하지 않습니다 — 이건 첫 프롬프트에서 다룰 질문이 아니라 2차 라운드 질문입니다. |
| "2인용 에어하키 게임, 실제 물리 엔진, 키보드 하나로 플레이." | 게임은 이 패턴을 명확하게 보여줍니다: 장르에 실제 플레이 감각을 결정짓는 제약 하나를 더한 것입니다. "실제 물리 엔진"과 "키보드 하나"는 기능이라기보다는 머릿속에 그리던 그 게임처럼 느껴지게 만드는 두 가지 결정입니다. 테이블 색상, 퍽 궤적, 스코어 UI는 빌더가 제안하고 여러분이 반응하면 됩니다. |
이 세 가지를 관통하는 것은 짧음 그 자체가 아니라, 모든 단어가 각자의 역할을 하고 있다는 점입니다. 팟캐스트 프롬프트에서 "따뜻하고 에디토리얼한"을 빼면 평범한 팟캐스트 페이지가 되고, "도시 농업"을 빼면 무드 단어가 겨냥할 대상이 사라집니다. 이게 프롬프트가 잘 구성됐는지 판단하는 진짜 기준입니다 — 단어 수가 아니라요. 저라면 억지로 짧게 줄여서 필수 요소를 슬쩍 빠뜨린 15단어짜리 프롬프트보다, 모든 절이 제 몫을 하는 40단어짜리 프롬프트를 택하겠습니다.
이미 브랜드 컬러나 실제 사진이 있다면요?
첨부하세요. 설명하지 마세요. 실제 브랜드 가이드가 데스크탑의 PDF 파일로 있는데도, 브랜드 팔레트를 헥스 코드에 가까운 언어로 — "짙은 포레스트 그린인데, 좀 탁한 느낌" — 신중하게 문단으로 풀어 쓰는 사람을 본 적이 있습니다. 설명된 색상은 빌더가 다시 재구성해야 하는 추측이지만, 첨부된 색상은 그냥 정확합니다. 실제 메뉴, 실제 사진, 브랜드 에셋 — 지식 및 참조 기능이 이를 빌드에 바로 반영해주며, 사실은 언제나 사실에 대한 설명을 이깁니다.
