5단계: 데이터 모델을 스케치하라

대부분의 앱은 실은 데이터에 관한 것이다: 무엇을 저장하고 조각들이 어떻게 관련되는가. 빠른 데이터 모델 스케치는 나중에 혼란스럽고 일관성 없는 코드로부터 당신을 구해준다. 데이터베이스 다이어그램은 필요 없다 — 필드 목록이면 충분하다.

책 트래커의 경우, 주된 것은 하나다 — Book:

Book
- id: unique string
- title: string
- author: string
- status: "to_read" | "reading" | "finished"
- rating: number 1–5 (only if finished)
- addedAt: date

이 작은 스케치조차 결정을 명시적으로 만든다: 평점은 완독한 책에만 존재하고, 상태는 정해진 세 값 중 하나이며, 모든 책에는 id가 있다. 이것을 AI에게 건네면, AI는 필드 이름 추측을 멈추고 일관되게 만든다.

이것을 일찍 못박아 두어야 하는 이유는 필드 이름이 사방으로 새어 나가기 때문이다. 일단 AI가 book.rating을 읽는 코드를 쓰면, 그 이름은 폼에도, 목록 뷰에도, 저장 계층에도, 그리고 나중에 추가하는 어떤 기능에도 나타난다. 그것이 떠다니게 두면 — 한 곳에서는 rating, 다른 곳에서는 stars, 또 다른 곳에서는 score — 쫓기 성가신 버그가 생긴다. 여섯 줄짜리 데이터 모델은 그것에 대한 가장 싼 보험이다.

짧고 복사해 붙일 수 있는 명세 블록은 AI에게 산문보다 더 잘 통하는 경향이 있다. 다음은 실제로 보낼 프롬프트로 쓴 같은 모델이다:

Use this exact data shape for a book. Don't add fields I didn't list,
and don't rename these:

Book {
  id        — unique string, generated on creation
  title     — string, required
  author    — string, required
  status    — one of: "to_read" | "reading" | "finished"
  rating    — integer 1–5, present ONLY when status is "finished"
  addedAt   — ISO date string, set when the book is added
}

If you think a field is missing, ask me before adding it.

마지막 줄 — 추가하기 전에 나에게 물어봐 — 가 진짜 일을 하고 있다. 그것은 AI를 추측꾼에서 협력자로 바꾸고, 데이터 모델을 당신의 것으로 유지한다.