레시피 · 장보기 앱
2026-09-15 식단을 날짜로: 홈은 이번 주·다음 주 열나흘을 세로로 늘어놓는
식단 화면이고, 날짜마다 "저녁 약속" 같은 메모를 적을 수 있습니다.
담기는 날짜를 물어 그 날짜로 바로 넣습니다. 장보기에서 체크한 항목은
맨 아래로 내려갑니다.
2026-09-10 UI/UX 개선: 담기는 즉시 처리, 장보기는 합친 목록이 기본입니다.
보유 재료 제외는 해당 주 목록에 저장합니다.
현재 사용법은 쓰는 법, 배포 전 필요한 마이그레이션은
배포 가이드를 확인하세요.
요리를 아는 사람이 자기 레시피를 모아두고, 장보기 전에 메뉴를 정해 장보기 목록을 뽑는 도구.
쓰는 법: docs/how-to-use.md
상태: v1 설계 완료, 개발 착수 단계
디자인 시스템: 여백(Yeobaek) — 라이트 기본
화면 시안: Figma 레시피·장보기 앱 v1 — 화면 흐름
🤖 Claude Code에게
docs/claude-code-brief.md 를 먼저 읽어라. 개발 지시서다 —
화면 3탭, 레시피 정리 파이프라인, 작업 순서 9단계가 여기 있다.
배경과 결정 이유가 궁금하면 docs/v1-spec.md 를 본다.
이유를 모르고 코드를 고치면 이미 검토해서 버린 선택지로 되돌아가게 된다.
반드시 지킬 것 (어기면 제품이 망가진다)
- 원문을 덮어쓰지 않는다.
recipe_ingredient.raw_name은 사용자가 보는 값이다. 표준화 결과는 ingredient_id에만 넣는다.
- 모르는 재료를 추측하지 않는다. 사전에 없으면
ingredient_id = NULL로 두고 unmapped_term에 쌓는다. LLM에게 "알아서 표준화해"라고 시키면 국간장과 진간장을 뭉갠다.
- 판정하지 말고 근거를 보여준다. "없음" 대신 "6일 전에 샀어요". 확신이 없으면
CHECK 버킷으로 보낸다.
- 원본(이미지·텍스트)을 절대 지우지 않는다.
source_asset에 parser_version과 함께 남긴다. 파서가 좋아지면 전부 재파싱한다.
- 새 입력을 요구하는 기능을 넣지 않는다. 기존 행동(장보기 체크, 요리 완료, 영수증)에 얹는다.
- 크롤링하지 않는다. 네이버 검색 결과, 인스타 저장함, 유튜브 영상 다운로드, 커머스 주문내역 전부 금지. 외부 검색은 링크만 열고 결과는 공유 인텐트로 받는다.
- 커머스 연동을 넣지 않는다. 중립성이 이 제품의 유일한 차별점이다.
새 기능 판단 기준
기존 입력을 재활용하는가, 새 입력을 요구하는가?
재활용이면 검토하고, 새 입력을 요구하면 뺀다. 판단이 애매하면 docs/v1-spec.md 3장의 "빼는 것" 표를 보라 — 이미 검토해서 버린 것일 가능성이 높다.
저장소 구성
핵심 설계 요약
전체는 스펙 문서에 있고, 여기서는 코드에 바로 영향을 주는 것만.
3층 파이프라인 — 한 덩어리로 만들지 말 것
[1] 수집 이미지 / 링크 / 붙여넣기 / 직접입력
↓ 원본 보관 (source_asset)
[2] 파싱 LLM → 원문 표기 그대로의 구조화 데이터
↓ 여기까지 LLM, 아래는 코드
[3] 정규화 표준 ID 매핑 · 택1 처리 · 확신도 판정
파서는 옮기기만 하고, 표준화는 코드가 사전을 보고 한다.
이렇게 나눠야 사전이 좋아질 때 재파싱 없이 재매핑만 하면 된다.
2패스 파싱
- 1차 재료 섹션만 (조리 단계는 보지 말라고 명시)
- 2차 1차 결과를 넣고 "이 목록에 없는 재료를 조리 단계에서 찾아라"
레시피 작성자가 재료 목록에 안 적고 조리 설명에만 쓰는 재료가 실측 5건 중 2건에서 나왔다 (고등어조림의 무, 제육볶음의 올리브유). 재료 섹션만 파싱하면 마트에서 무를 안 사고 집에 와서 요리를 못 한다.
2차에는 이미지를 다시 보내지 않는다. 1차 응답에 조리 단계 텍스트를 같이 받아 그것만 넘긴다. 원가 증가가 2.2배 → 1.2배.
재료 표기 규칙
표준명(원문) → 다진마늘(간마늘), 고춧가루(고추가루)
원문 == 표준명 → 괄호 숨김
탭하면 사용자가 직접 수정할 수 있어야 한다.
대체 불가 주의: 진간장 ≠ 국간장, 후추 ≠ 통후추. 뭉개면 안 된다.
재고를 추적하지 않는다
purchase 테이블은 재고가 아니라 구매 이벤트 로그다. 장보기에서 체크하면 자동으로 쌓이므로 별도 입력이 없고, "언제 샀는지"는 틀릴 수가 없는 데이터다.
BUY 구매 이력 없음 OR 경과일 > 유통기한
CHECK 경과일 > 유통기한/2 → "6일 전에 샀어요"
HAVE 그 외
레시피 상태
WISH 해보고 싶다 (저장 시점의 기본값) → 장보기 후보
GOOD 만들어봤고 괜찮았다 → 추천 풀
BAD 별로였다 → 숨김
저장 시점은 "맛있었다"가 아니라 "해보고 싶다"다. 평가는 별점이 아니라 "또 만들래요?" 예/아니오.
개발 순서
원본은 docs/claude-code-brief.md 8장이다.
여기엔 어디까지 왔는지만 적는다.
| # | 작업 | 완료 판단 | 상태 |
|---|
| 1 | 프로젝트 셋업 + DB 스키마 반영 | 마이그레이션 통과 | 완료 |
| 2 | 재료 사전 시드 투입 | CSV 47개 표기 반영 | 완료 |
| 3 | 레시피 목록 3탭 + 만들었어요(날짜 선택) | 데이터를 손으로 넣어 돌아감 | 완료 |
| 4 | 캡처 업로드 → 2패스 파싱 → 확인 화면 → 저장 | 캡처 1장이 레시피가 된다 | 완료 |
| 5 | 미분류 확인 | unmapped_term 10% 안쪽 | 미룸. 실제 레시피를 넣어봐야 안다 |
| 6 | 이번 주 담기 + 장보기 목록 3단 분류 | 담은 요리의 재료가 합산됨 | 완료 |
| 7 | 링크 파싱 + 캡처 폴백 | 링크 실패 시 안내가 뜬다 | 완료 |
| 8 | 냉장고 재료 가중치 | | 완료 |
| 9 | PWA + Web Share Target | 인스타 공유 시트에 앱이 뜬다 | 완료 |
3번까지가 최소 동작 앱이다. 4번이 이 제품의 심장이고 나머지는 그 위에 얹는다.
로그인·결제·온보딩·설정은 전부 나중이다.
5번은 실제 레시피를 넣어봐야 판단이 되는 단계라 뒤로 미뤘다.
지시서는 미분류가 절반을 넘으면 6번으로 넘어가지 말라고 하는데, 아직
재보지 않았으니 그 조건은 열려 있다. 캡처를 10~20건 넣은 뒤 확인한다.
SELECT raw_name, hit_count FROM unmapped_term
WHERE resolved_ingredient_id IS NULL ORDER BY hit_count DESC;
This is the beginning of the README. Read the rest at the original. Read the full README ↗
