네트워크 한눈에
추천 네트워크 = 식재료 노드를 두 종류의 엣지로 잇는 무방향 그래프. 추천은 이 그래프 위를 걷는다 — 잘 먹는 것 → 곁들임(pair) → 사촌(bridge).
핵심 원칙 — 판단은 한 곳, 편지는 믿는다
데이터를 그래프에 넣을지 판정하는 곳은 빌드타임 단 한 곳. 수치만으로 자르지 않고, 증거를 펼친 엑셀을 사람(Claude)이 보고 결정한다. 편지 쓸 때는 이미 검증된 추천이라 그대로 믿고 쓴다.
grade · reason · verified 영속. 증분 체크포인트 = 신규 후보만 재검수.✗ 옛 구조 — 수치가 LLM을 덮어씀
LLM이 맨손(일반상식)으로 떡+달걀에 2점 → 그걸 cells<8 수치 게이트가 사후에 차단. 수치가 LLM을 이기는 구조라, 좋은 조합도 수치에 잘려나갈 위험.
✓ 새 구조 — 수치가 LLM을 무장시킴
같은 떡+달걀을 "실제 식판 4회·lift 0.72=우연 이하" 증거와 함께 보여주면 판정자가 스스로 거부. 수치는 게이트가 아니라 증거. 떡+달걀의 교훈은 "LLM 빼라"가 아니라 "데이터로 무장시켜라".
추천이 편지에 도착했을 땐 이미 검증된 것이어야 정상이다. 거기서 또 판단하면 같은 일을 두 번 하는 낭비이고, "재료=결정론, 문장=LLM 자유" 철칙을 스스로 깨는 것. 런타임에 남는 건 판단이 아니라 결정론 필터(이 아이 ageBand·알레르기 제외)뿐 — 그래서 편지는 가져온 추천을 믿고 쓴다.
왜 강화가 필요한가 — 3가지 구조적 약점
지금 네트워크는 좋지만, 2~6세에 치명적인 빈틈 3개가 있다. 데이터 강화는 이 3개를 정확히 겨냥한다.
연령 미스매치 — '또래'가 초등이다
pair의 '또래 빈도'가 초등 NEIS(6~12세) 식판. 레시피DB는 영아/유아/아동으로 이미 나뉘어 있는데 빌드 때 6개를 합쳐 연령 신호를 버린다. (검증: NEIS는 유치원 급식을 제공하지 않음 — 보유 유치원 7,036은 명부지 식단 아님)
→ 처방: 레시피DB 연령 가중 + 식약처 영유아 식단 API(15118061/15118065)로 freqMap·식판 lift 교체bridge(사촌)가 수기다 — 안 늘어난다
푸드체이닝의 핵심인 사촌 175쌍이 전부 손 큐레이션(basis:"맛·식감이 닮은 사촌" 단일 텍스트). 신규 식재료마다 사람이 또 손으로 추가해야 하고, 롱테일 고립 노드 ~40개가 어디에도 안 연결됨.
1차 신호 미활용 — 우리 아이들 데이터를 안 본다
앱이 매일 쌓는 아이별 수용/거부·노출 횟수·집vs급식을 네트워크가 안 본다. 모집단 동시출현만 보고 "우리 아이들이 실제로 받아들였나"는 무시. 거부를 boolean 한 칸으로만 봐서 식감거부·맛거부를 못 가른다.
→ 처방: 거부 원인 4분류 + (자녀×식재료) 노출 카운터 + 집/급식 비대칭 — 전부 보유 데이터, 수집비 0무엇을 부어 넣나 — 데이터 3티어
수집비용 순서로 — 이미 보유(0원) → 국가 공공데이터(무료 API) → 유사도 모델. 모든 후보는 §1의 grounded 판정 관문을 통과해야 그래프에 들어간다.
이미 보유 — 수집비용 0
즉시국가 공공데이터 — 무료 / OpenAPI
단기 1~2주data.go.kr 15118061·15118065 — 만1~5세 표준식단, 끼니 단위(재료·조리법·영양). 초등 freqMap을 영유아로 교체하는 1순위.koreanfood.rda.go.kr — 3,248개 표준 전통음식·식재료(파일 다운로드).dietary4u.mfds.go.kr 표준레시피(무염·잘게) + 영유아 채소 기호도(기피=가지·버섯·시금치).속성 / 유사도 모델 — bridge 자동화
중기 3~6주판정 엑셀 — 한눈에 결정하게
"수치만으로 자르지 말라"가 여기서 실현된다. 한 줄에 증거를 다 펼쳐 내가 한눈에 판정. 안전플래그는 코드가 빨갛게 미리 띄운다.
| a | b / 음식 | 종류 | 출처 | lift | cells | 동시N | 실제 식판/레시피 예시 | 안전플래그 | 초안 | 내 판정 | 사유 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 소고기 | 시금치 | pair | 조리기능사·식약처 | 1.8 | 21 | 47 | 시금치무침+불고기(식판 3건)… | – | strong | ✅ 승인 | 또래 식판 빈출 |
| 떡 | 달걀 | pair | 영양 코사인 | 0.72 | 4 | 4 | 같은 끼니 거의 없음 | 음성 lift | weak | ❌ 거부 | 우연 이하 |
| 견과 | 요거트 | bridge | flavor 유사도 | – | – | – | – | 질식(만3미만)·알레르겐 | – | ⚠️ 조건부 | 만3+·잘게만 |
| 두부 | 근대 | bridge | 영양∩감각 | – | – | — | 닮음: 부드러운 식감·결핍 철분 | – | medium | ✅ 승인 | 식감 사촌·결핍 동급 |
⛔ 안전플래그(질식·8대 알레르겐·음성 lift·꿀)는 코드가 자동 계산해 띄운다 → 놓칠 일 없음. 나머지("2~6세에 진짜 맛있고 자연스러운가")는 내가 증거 보고 판정. 이게 "LLM이 한번 더 보고 판단" — 단 편지 때가 아니라 DB 넣기 전, 엑셀에서. 증분 체크포인트로 신규 후보만 검수한다.
2~6세 전용 노드 메타데이터
추천이 괴식뿐 아니라 질식·발달 부적합까지 막으려면, 각 노드에 연령 안전·발달 층을 얹는다. 대부분 공공·무료 → 식재료 30~50종 표 정규화가 주 작업.
우선순위 로드맵
가장 큰 레버는 신규 수집이 아니라 이미 가진 것 — ①연령 분리 레시피를 합치지 말 것, ②앱 1차 신호를 네트워크에 먹일 것. 나머지는 그 위에 풍성함을 더한다.
판단은 빌드타임 한 곳(엑셀 → 내 터미널 검수 → DB). 수치는 후보를 만들고 안전 바닥을 깔고, 사람이 증거를 보고 판정한다. 편지는 검증된 추천을 믿고 쓰고, 런타임에 남는 건 연령·알레르기 결정론 필터(판단 아님)뿐. 떡+달걀의 교훈은 "LLM 빼라"가 아니라 "데이터로 무장시켜라"였다.