정리와 연습

핵심 요점

• 스펙이 먼저였고 짧았다 — 실행 중인 앱에는 결코 드러나지 않는 워크플로 제약을 포함해, 중요한 제약을 짚은 한 단락이었다.
• 비밀값은 저장소에 닿지 않았다. 모든 프로젝트가 환경 변수나 대시보드에 설정한 암호화된 설정에서 키를 읽었다.
• 스택은 잘못될 여지가 적도록 선택됐다 — 관리형 인증, 관리형 데이터베이스, 정적 호스팅, 서버리스 함수.
• 장애물은 AI에게 정확한 증거를 먹여 해결됐다 — 실제 에러, 실제 코드, 배포 설정 — 그리고 수정 범위를 좁게 잡았다.
• 출시는 "컴파일됨"이 아니라 현실에 대한 진짜 테스트를 뜻했다: 실제 결제, 두 번째 계정, 배포된 사이트의 딥 링크.

직접 해보기

자신의 아이디어 하나를 골라, 이 네 사례처럼 한 단락짜리 스펙을 써라: 핵심 동작, 각 사용자가 볼 수 있는 데이터, 그리고 최소한 하나의 워크플로 제약(콘텐츠가 어떻게 게시되는지, 누가 무엇을 할 수 있는지)을 명시하라. 그런 다음 망가질 커스텀 코드를 줄이기 위해 기댈 관리형 빌딩 블록을 나열하라. 한 단락에 짧은 글머리표 목록 정도로 유지하라 — 그보다 커지면 과하게 명세하고 있는 것이다.

이 장의 프롬프트

I want to build: [one-paragraph description of the app].
Before any code, help me tighten this into a buildable spec.
1. Restate the single core action a user performs.
2. List the data each user can see — and what they must NOT see.
3. Name the workflow constraints that won't show up in the UI
   (e.g. "pushing a file should publish it", "only their own data").
4. Recommend a stack that MINIMIZES custom code: managed auth,
   managed database, static or serverless hosting where possible.
5. Flag the one part most likely to go wrong, and how we'll test it
   against reality (a real purchase, a second account, a deep link).
Keep the spec to a paragraph plus bullets. Push back if it's too big.