냉장고털기

“냉장고에 뭐는 있는데… 오늘 뭐 해 먹지?” 이 한 문장에서 시작한 앱. 있는 재료로 만들 수 있는 한식을 골라주고, 유통기한을 챙겨주고, 요리를 끝내면 쓴 재료가 알아서 빠지는 — 한국 가정 부엌의 흐름을 그대로 옮긴 식재료 관리 앱이다.

왜 만들었나

마트에서 똑같은 재료를 또 사 오고, 냉장고 안쪽은 뭐가 있는지 기억이 안 나고, 결국 시들어서 버리는 반복이 싫었다. 시중 앱들은 대부분 “레시피를 검색”하게 하거나 “다이어트 칼로리”에 초점이 맞춰져 있었는데, 원한 건 정반대였다 — 사러 가지 말고, 지금 있는 걸로 해먹게 해줘. 그래서 핵심 가치를 “구매 유도”가 아니라 **“보유 재료 소비”**에 뒀고, 이 방향이 이후 모든 UX 결정의 기준이 됐다. (쿠팡 연동 같은 수익 동선도 이 정체성과 안 부딪히는 선에서만 붙였다.)

핵심 기능

• 보유재료 기반 추천 — 식약처 공인 1,100여 개 + 자체 큐레이션 레시피에서, 지금 냉장고 재료로 만들 수 있는 한 끼를 매칭률 순으로
• 유통기한 알림 — 매일 정한 시각에 임박 재료를 모아 푸시 (김치(D-1), 두부(D-day) 외 N건)
• 요리 완료 자동 차감 — “완료” 한 번에 재료가 빠지고, 절약 금액·음식물쓰레기 감량 자동 기록
• 사진·영수증 등록 — 재료 사진을 AI가 인식 / 영수증을 on-device OCR로 읽어 자동 등록
• 주간 플래너 + 장보기 — 식단을 짜면 부족한 재료가 자동으로 장보기 리스트에, 쿠팡 원탭 연동
• 오프라인 우선 — 모든 데이터 기기 로컬(SQLite)에 저장, 인터넷 없어도 동작
• 화면 광고 없음 — 배너/전면 광고 없음. 쿠팡 링크 수수료만 (구매자 가격 동일)

기술 결정

영역	선택	이유
로컬 DB	Drift (SQLite)	오프라인 우선 원칙 + 자동 마이그레이션 백업
백엔드	Supabase (Edge Functions·Postgres·pg_cron)	식약처 레시피 데이터 주간 자동 동기화, AI 프록시
상태 관리	Riverpod + 코드젠	5탭 셸 구조에서 기능별 상태 분리
OCR	google_mlkit_text_recognition	on-device라 무료·오프라인

설계 원칙 하나 — DB는 “규모로 정면승부”하지 않고 저비용 자동 성장 구조로 짰다:

1. 식약처 COOKRCP01 주간 pg_cron 자동 동기화 (1,146건)
2. 사용자 미매칭 재료 익명 수집 → 검토 후 카탈로그 정식 등록 루프
3. AI/OCR 인식 이벤트 계측으로 개선 우선순위 판단

개발 여정에서 배운 것

• AAB 377MB → 80MB — 원인은 전부 이미지였다. WebP 변환 + 리사이즈로 79% 감량
• 추천이 자꾸 0개 뜨던 문제 — 알고리즘을 아무리 튜닝해도 안 풀렸는데, 원인은 데이터였다. 간단 레시피 47개를 큐레이션해서 매칭 0 → 50개로 해결. 데이터가 얇으면 알고리즘으로 못 메꾼다.
• 식약처 주간 cron이 조용히 죽어 있었다 — GUC/인증 이슈로 DB 자동 성장이 멈춰 있던 걸 뒤늦게 발견. “자동화를 붙였다”와 “자동화가 돈다”는 다르다는 걸 배운 지점
• 쿠팡 진입 동선 단순화 — “쿠팡 들어가기가 너무 깊다”는 피드백에, 홈 AppBar 장보기 아이콘(배지=살 것 개수) + 장보기 상단 원탭 버튼으로 정리. “쿠팡”을 직접 노출하는 대신 “장보기”로 감싸 정체성·정책 리스크를 피했다

지금 상태

v0.5.7+39, Android 내부 테스트 단계. 190여 개 커밋을 거치며 코어 루프 → 한식 “종이 톤” 리브랜딩 → 외부 레시피/OCR/AI 인식 → 견고화 순으로 다졌고, 최근엔 쿠팡 연동 동선을 다듬는 중이다.