BOOK_MAKER 개발기 #1 — 코드보다 먼저 제품을 설계했다

예전에는 아이디어가 떠오르면 바로 코드부터 짰다. 그런데 그렇게 시작한 프로젝트는 대개 중간쯤 가서 길을 잃었다. 이번엔 반대로 가보기로 했다. 코드 한 줄보다 먼저, 이 제품이 누구를 위한 것이고 왜 필요한지부터 정리했다. 대화로 문제를 좁히고, 문서로 고정하고, 기술 스택과 프로토타입까지 먼저 잡았다.

목표

  • BOOK_MAKER의 문제 정의와 MVP 범위를 문서로 확정
  • 실제 구현 전에 기술 스택, 데이터 모델, 프로토타입까지 정리

핵심 구현 포인트

1) 개인적인 문제를 제품 문제로 번역했다

이 프로젝트의 출발점은 단순했다. 예전에 인스타그램에 짧은 글을 자주 올렸는데, 시간이 지나면 언제 어떤 글을 썼는지 찾기 어렵고, 많이 써도 그게 원고처럼 쌓이지 않았다.

거기서 사용자 문제를 이렇게 정의했다.

SNS에 흩어져 흘러가던 나의 짧은 글들을,
나중에 책이 될 수 있는 원고 자산으로 쌓이게 만든다.

책을 쓰고 싶지만 늘 미루던 사람이,
짧은 기록부터 시작해 어느새 한 권의 초안에 닿게 만든다.

핵심은 “책을 쓰게 하는 앱”보다 “책을 미루지 않게 하는 앱” 으로 정의한 점이었다.

2) 문서부터 만들고, 기술은 그 다음에 확정했다

기획이 흔들리면 기술 선택도 취향 싸움이 된다. 그래서 먼저 제품 문서를 쌓고, 그다음에 기술 스택을 정했다.

정리한 결과는 다음과 같다.

Frontend: Nuxt 3 + Vue 3
Backend: NestJS
DB: PostgreSQL
Cache/Auth: Redis
Mobile: responsive web first
MongoDB: deferred

이 스택은 “써보고 싶은 기술”이 아니라 랜딩 + 웹 앱 + MVP 속도 + 향후 확장성 때문에 결정했다.

같은 흐름으로 아래 문서들을 먼저 만들었다.

  • PRODUCT_BRIEF.md
  • USER_JOURNEY.md
  • MVP_SCOPE.md
  • TECH_PLAN.md
  • TECH_DECISION.md
  • DATA_MODEL.md
  • BACKEND_API_PLAN.md
  • IMPLEMENTATION_PHASES.md

이후에는 Stitch 시안을 바탕으로 과한 요소를 덜어낸 정적 프로토타입도 만들었다.

트러블슈팅 / 고민 포인트

먼저 구현할 것인가, 먼저 정의할 것인가

  • 원인: 원래는 바로 Nuxt와 NestJS 프로젝트를 열고 구현에 들어가고 싶었지만, 그렇게 하면 결국 메모 앱인지 책 편집기인지 정체성이 흐려질 가능성이 컸다.
  • 해결: PM 문서, IA, 기술 의사결정, 데이터 모델, 로드맵을 먼저 쌓고 나서 구현 순서를 정했다. 덕분에 지금은 무엇을 만들지보다 무엇을 아직 만들지 말아야 하는지 가 더 분명해졌다.

결과

  • BOOK_MAKER의 제품 정의, 사용자 여정, MVP 범위, 기술 스택, 로드맵 문서 작성 완료
  • Stitch 시안을 기반으로 한 정적 프로토타입과 한글 UX 카피 가이드 작성 완료

다음 개선 아이디어

  • Nuxt 3 실제 프로젝트 초기화 및 한글 카피 기준으로 랜딩/앱 레이아웃 구현 시작
  • NestJS, PostgreSQL, Redis 기반 백엔드 스캐폴드와 인증/기록 API 구현 시작