기획 목차 D--8 오픈 2026-09-16
기획

기획 목차

무엇을 만들지 정의하는 문서 10편. 여기 적히지 않은 기능은 9/16까지 만들지 않습니다.

왜 이 순서인가

문서 순서는 의존성 순서입니다. 앞 문서가 흔들리면 뒤 문서가 전부 흔들리도록 배치했습니다. 그래서 01~05를 9/04까지 얼려버리는 것이 이 프로젝트에서 가장 중요한 일정 장치입니다.

01 서비스 개요   무엇을·누구에게        ← 여기가 바뀌면 전부 다시
   └ 02 범위     이번에 어디까지         ← 9/16 안에 들어갈 것만
       └ 03 아키텍처  어떤 구조로
           └ 04 ERD      데이터가 어떻게 생겼나   ← 9/04 FREEZE
               └ 05 API 계약  프론트·앱이 뭘 받나  ← 9/04 발행 → 병렬 착수 가능
                   ├ 06 AI 에이전트
                   ├ 07 디자인 시스템
                   └ 08 인프라 → 09 QA·릴리스 → 10 리스크
기획서 v6 대조가 남아 있습니다

각 문서 하단에는 「기획서 v6 대조」 항목이 있습니다. REMAKE_DAY_기획서_v6.md 원문을 이 레포 _plan/_source/ 에 넣고, 해당 항목을 채워야 그 문서가 확정 상태가 됩니다. 확정되지 않은 문서에 기대어 만든 기능은 되돌아올 수 있으니, 착수 전에 반드시 상태를 확인하세요.

문서 10편

01 서비스 개요 기획서 v6 반영
REMAKE DAY 는 루프물 대화 게임이자, 저항이 상태로 모델링된 에이전트 레퍼런스 구현입니다.
담당 류준 (Team Lead · AI Agent Engineer) · 확정 기한 2026-09-03
02 범위 & 우선순위 방어선 확정
우선순위는 우리가 정하지 않았습니다. 기획서 12.3 의 절대 방어선 5개가 그대로 MUST 입니다.
담당 류준 (Team Lead · AI Agent Engineer) · 확정 기한 2026-09-04
03 시스템 아키텍처 기획서 9장 반영
헥사고날 + DDD. 포트는 세 곳만. 어댑터 위 계층 전체가 BeyondBob Engine 입니다.
담당 장민석 (AI Evaluation Engineer) · 확정 기한 2026-09-04
04 데이터 · ERD 9/04 FREEZE
판정 로그가 이 프로젝트의 산출물입니다. 게임 상태보다 로그 설계가 먼저입니다.
담당 장민석 (AI Evaluation Engineer) · 확정 기한 2026-09-04
05 API 계약 인증·허들 추가 9/16
프론트가 화면 5장을 만들 수 있는 최소 계약. 9/16부터 구글 로그인과 과잉 사용 방지 허들이 붙었습니다.
담당 장민석 (AI Evaluation Engineer) · 확정 기한 2026-09-04
06 AI 에이전트 설계 모델 확정 9/17
Planner · Agent · Advisor · Re-plan · Evaluator · Memory. 도구는 딱 두 개. 민석만 메모리 정책이 다릅니다.
담당 신채연 (Full-stack Engineer · Game Frontend) · 확정 기한 2026-09-04
07 디자인 시스템 화면 5장 확정
전면 텍스트. 화면은 다섯 장. 연출 원칙이 곧 디자인 규칙입니다.
담당 김충식 (Scenario Director · Content) · 확정 기한 2026-09-04
08 인프라 & 배포 LLM 비용 확정 9/17
공개 투표 트래픽을 받아내는 것과, LLM 비용이 터지지 않게 하는 것. 이 둘이 인프라의 전부입니다.
담당 류준 (Team Lead · AI Agent Engineer) · 확정 기한 2026-09-06
09 QA & 릴리스 방어선 기준
오픈 조건은 하나입니다 — 절대 방어선 5개가 실제로 동작하는가.
담당 류준 (Team Lead · AI Agent Engineer) · 확정 기한 2026-09-11
10 리스크 관리 9/17 갱신
터질 만한 것을 미리 적고, 트리거와 대응을 정해둡니다.
담당 류준 (Team Lead · AI Agent Engineer) · 확정 기한 2026-09-03

문서 규칙

  • 결정만 적는다. 논의 과정은 데브로그에, 결론은 기획 문서에 둡니다.
  • 바꿀 때는 이유를 남긴다. 각 문서 하단 「결정 로그」에 날짜·변경·이유를 한 줄로 추가합니다.
  • 확정 후 변경은 PM 승인. 특히 04(ERD)와 05(API)는 9/04 이후 변경 시 마이그레이션·클라이언트 대응이 따라옵니다.
  • 모르면 비워두지 말고 「미정」이라 쓴다. 빈칸은 합의된 걸로 착각되지만, 「미정」은 누군가 물어보게 만듭니다.