| name | menu-development-cycle |
| description | 외식 브랜드의 신메뉴를 기획부터 출시까지 단계별로 함께 개발하는 사용자 주도형 스킬. 사용자가 매 단계를 직접 확인·점검하고 동의해야 다음으로 넘어가며, 사용자 의견을 주요 안건으로 산출물에 기록한다. 무엇을 하는가. 1-1 기획에서 웹 리서치로 메뉴 후보를 도출해 사용자 동의를 받고(다른 의견이면 새 메뉴 재도출), 신메뉴 기획서 + 경쟁사 분석표(3~5곳)를 만든다. 2-1 시제품 개발에서는 보유 식재료·매장 기물류를 먼저 확인한 뒤 원가가 포함된 레시피 설계서 3~5안(재료 추가·삭제·사용량 조정 시 원가율 자동 재계산)을 제시한다. 이후 원가·수율, 경영진 시연, 표준화, 매뉴얼, 교육, 출시까지 같은 게이트 패턴으로 잇는다. 각 단계 산출물은 HTML 조각으로 채워 단일 HTML로 병합·전달한다. 언제 쓰는가. 사용자가 "신메뉴 개발", "메뉴 개발 시작", "메뉴 개발 사이클", "레시피 개발", "신메뉴 기획서 만들어줘", "경쟁사 분석표", "원가 레시피 설계", "시제품 개발", "사이클 진행", "처음부터 끝까지 개발", "/menu-development-cycle" 같은 표현을 쓰거나, 브랜드명(예: 바다한상, 어화락, 삼대미역)에 컨셉이나 메뉴 방향을 덧붙여 신메뉴 개발을 의뢰하면 반드시 이 스킬을 발동한다. 쓰지 않을 때. 이미 완성된 레시피의 단순 원가 계산만, 메뉴판 디자인이나 가격표 인쇄만, 일반 요리 레시피 질문(가정용·1회성), 식당 창업·상권 분석 전반, 마케팅 카피나 SNS 콘텐츠 제작은 이 스킬이 아니다. |
메뉴개발 사이클 (Menu Development Cycle) v3.0 · 사용자 주도형
이 스킬의 목적은 새 레시피를 개발할 때 사용자가 각 단계를 직접 확인·점검하며 과정 누락 없이 진행하도록 돕는 것이다.
자동 진행이 아니라 단계마다 사용자에게 의견을 묻고, 그 답변을 주요 안건으로 반영하는 사용자 주도형 프로세스다.
절대 원칙 (먼저 references/workflow.md를 읽어라)
신메뉴 개발은 현장 사정(보유 식재료, 기물, 브랜드 정체성, 목표 마진)을 가장 잘 아는 사람이 사용자이기 때문에, 모델이 앞서가면 그럴듯하지만 매장에서 못 쓰는 레시피가 나온다. 그래서 이 스킬은 자동 완주가 아니라 사용자 주도로 설계되었다.
- 사용자가 결정자다. 페르소나 토의(가상 5인)는 시야를 넓히는 참고 의견일 뿐이라 짧게만 제시하고, 단계의 최종 결정은 사용자 확인 게이트로 확정한다. 모델의 추천이 사용자 결정을 대체하지 않게 하기 위함이다.
- 단계 누락 금지. 원가 검토 없이 시연으로 넘어가거나 표준화 없이 출시하면 현장에서 사고가 나므로, 각 단계의 ✓점검표를 사용자와 함께 확인하고 빠진 항목이 있으면 넘어가지 않는다.
- 사용자 의견은 주요 안건. 사용자의 의견·제약·선호(예: 특정 식재료 금지, 목표 원가율)는 다음 단계에서 잊히기 쉬우므로, 산출물과 HTML의 "사용자 의견" 안건(
.user-voice)으로 명시 기록해 끝까지 추적한다.
- 확인 없이 다음 단계로 넘어가지 않는다. 되돌리는 비용이 뒤로 갈수록 커지므로, 각 단계 끝에 반드시 사용자 동의 게이트를 둔다.
시작 조건
- 브랜드명 (예: 어화락, 바다한상, 삼대미역)
- 대략적인 컨셉
둘 다 있으면 1-1을 시작, 없으면 묻는다.
공통 진행 패턴 (모든 단계)
① (필요 시) 웹 리서치 / 사용자 입력 수집
② 작업 수행 → 산출물 초안
③ 페르소나 토의 요약 (참고용, 짧게)
④ ✓점검표 사용자와 확인
⑤ 【사용자 확인 게이트】 "이대로 진행할까요? 수정할 부분 있으면 말씀해 주세요."
- 동의 → HTML 조각 채움·병합·전달 → 다음 단계
- 수정 의견 → 의견을 안건에 반영해 재작성 → 다시 ⑤
게이트는 ask_user_input_v0(예: ① 이대로 진행 ② 수정 의견 있음) 또는 평문 질문으로 제시하되, 사용자가 자유 의견을 낼 수 있게 한다.
1단계: 기획 (상세)
1-1 컨셉기획·시장조사
1. 브랜드 + 컨셉 확인 (없으면 질문)
2. 웹 리서치 (트렌드·경쟁사·식재료, 최근 6~12개월)
3. 메뉴 후보 도출 → 사용자에게 제시
【게이트 A】 "이 메뉴로 진행할까요? 다른 의견 있으면 말씀해 주세요."
- 다른 의견 → 그 의견을 토대로 합당한 새 메뉴를 다시 리서치·도출 → 【게이트 A】 반복
- 동의 → 다음
4. 확정 메뉴로 【신메뉴 기획서】 생성 (사용자 의견을 주요 안건으로 포함)
5. 기획서를 토대로 경쟁사 최소 3~5곳 조사 → 【경쟁사 분석표】 작성
6. ✓점검표 확인
【게이트 B】 "기획서와 경쟁사 분석표 확인해 주세요. 이대로 2단계로 갈까요?"
- 동의 → HTML 병합·전달 → 2-1
- 수정 → 반영 후 재확인
산출물 (★ 별도 HTML 문서 2종, 각 A4 3~4장 · 엑셀/워드/PDF 저장 가능)
- 신메뉴 기획서 (
assets/doc_planning.html): ① 기획 개요(기획배경·핵심전략·기획범위·기획 핵심 원칙) ② 매장 인근 시장 분석(인근 유사 메뉴 매장: 매장명·메뉴·가격·특징 + 우리 메뉴와의 차별점) ③ 유사 브랜드 운영 상황(브랜드명·메뉴·가격·특징 + 차별점)
- 경쟁사 분석표 (
assets/doc_competitor.html): STEP1 경쟁사 선정(3~5개) → STEP2 정보수집(배달앱·SNS·블로그) → STEP3 분석표(경쟁사·유사메뉴·가격·구성·대표매장 링크) → STEP4 인사이트(강점·약점·자사 도입가능 요소·전략)
두 문서는 사이클 HTML에 링크로 연결되며 독립 HTML로 저장한다. 각 문서 상단 툴바에서 엑셀(.xls)·워드(.doc) 저장 + PDF·인쇄가 가능하다(assets/doc_toolbar.js 인라인). present_files로 사이클 HTML + 두 문서를 함께 전달한다.
2단계: 개발 (상세)
2-1 시제품 개발 · 레시피 설계
1. 사용자에게 먼저 확인 (ask_user_input_v0 또는 평문):
① "보유 식재료" 현황
② "매장 기물류" 현황 (살라만더·튀김기·콤비오븐·스팀기·인덕션 등)
2. 보유 자원으로 만들 수 있는 【레시피 설계서 3~5안】 생성
- 카드형, 각 안에 재료·사용량·조리법·원가(식재료원가·판매가·원가율) 포함
- 사용자가 카드에서 재료 추가/삭제/사용량 조절 시 원가 자동 재계산 (인터랙티브 구현됨)
3. 페르소나 토의 요약 (참고용)
4. ✓점검표 확인
【게이트】 "어느 설계안으로 진행할까요? 재료·양을 조정하셔도 됩니다."
- 선택·조정 → 확정안 반영 → HTML 병합·전달 → 2-2
- 수정 → 반영 후 재확인
산출물: 레시피 설계서·테스트 기록지 겸용 문서(assets/doc_recipe.html, A4 4장). ① 설계 개요+보유 자원 ② 레시피 설계안 3~5(인터랙티브 원가 재계산) ③ 회차별 테스트 기록(관능 5점·평가자별·직전 대비 ▲▼·개선점→다음 회차 연결) ④ 표준화 확정. 상단 툴바로 엑셀·워드·PDF 저장.
레시피 설계 카드 채우는 법: assets/fragments/stage_2-1.html의 RECIPE_DATA 배열에 안마다 객체를 채운다.
price: 1-1 기획서의 목표 판매가ingredients[]: {name, qty, unit, per100, isUnitItem} (per100 = 원/100g, 개당 품목은 isUnitItem:true·per100=개당단가)- 원가율 = 식재료원가 ÷ 판매가. 33% 이하 정상, 40% 초과 빨강 자동 표시.
- 안은 최소 3개, 최대 5개.
이후 단계 (2-2 ~ 6-1)
같은 사용자 확인 게이트 패턴을 따른다. (상세 흐름은 추후 보강 예정.)
- 2-2 원가·수율 검토 / 3-1 경영진 시연(관능) / 3-2 도입 게이트 / 4-1 레시피 표준화(CCP) / 4-2 매뉴얼 / 5-1 교육 / 5-2 도입 / 6-1 출시 후 점검
- 각 단계: 작업 → 페르소나 참고 토의 → ✓점검표 → 사용자 확인 게이트 → 동의 시 다음
HTML 생성 (조각 관리 + 병합)
assets/
_shell.html 골격(스타일·헤더·진행바·스크립트)
merge.py 조각 → 단일 HTML 병합
build_fragments.py 2-2~6-1 빈 조각 생성기 (1-1·2-1 제외)
fragments/
phase_1~6.html 페이즈 헤더
stage_1-1.html ★ 기획서+경쟁사 분석표 (직접 작성)
stage_2-1.html ★ 인터랙티브 레시피 설계 카드 (직접 작성)
stage_2-2 ~ 6-1.html
_outputs.html BOM·레시피·알레르기·체크리스트·출처
병합:
python3 assets/merge.py --stages 1-1,2-1 --out /mnt/user-data/outputs/{브랜드}_{메뉴}_개발사이클.html
완료한 스테이지만 병합되어 단일 HTML이 된다. 매 단계 완료 시 같은 파일명을 덮어쓰고 present_files로 전달한다.
전 문서 공통 규칙 ★
- 저장·인쇄: 모든 산출 문서 + 개발사이클 HTML에 툴바(엑셀.xls·워드.doc·PDF·인쇄) 적용.
assets/doc_toolbar.js 인라인(/*__DOC_TOOLBAR_JS__*/ 자리), 사이클은 merge.py가 자동 주입.
- 분량: 모든 독립 문서는 A4 3~5장(
.doc-sheet)으로 통일, 인쇄 시 페이지 분할.
- 문서 템플릿:
doc_planning.html(기획서) · doc_competitor.html(경쟁사) · doc_recipe.html(레시피·테스트 겸용).
데이터·안전 규칙
- 원가·단가는 추정값임을 명시한다. per100(원/100g) 등 식재료 단가는 지역·시기에 따라 달라지므로, 사용자가 실제 매입 단가를 주지 않으면 시세 기반 추정값으로 채우고 "확인 필요" 표시를 남긴다. 정확한 숫자를 아는 척 단정하지 않는다.
- 빈칸을 임의로 메우지 않는다. 브랜드·컨셉·목표 판매가·보유 자원처럼 사용자만 아는 정보는 비어 있으면 묻는다. 모르는 값을 그럴듯하게 지어 넣으면 뒤 단계 계산이 전부 어긋난다.
- 경쟁사·시세 정보는 출처를 단다. 경쟁사 분석표의 가격·구성은 배달앱·SNS·블로그 등 확인 가능한 출처를 함께 기록하고, 확인 못 한 항목은 빈칸 대신 "미확인"으로 둔다.
- 위생·알레르기는 보조 정보다. CCP·알레르기 표기는 개발을 돕는 참고이며 식품 위생 법규 자문을 대체하지 않는다. 출시 전 관할 기준 확인이 필요함을 안내한다.
참조 파일
references/workflow.md · ★ 사용자 확인 게이트·1-1/2-1 상세 흐름 (먼저 읽기)references/stages.md · 스테이지 스펙 + ✓완료 점검표references/personas.md · 페르소나 프로파일 (참고용 토의)assets/_shell.html / assets/merge.py / assets/fragments/
