AAB 377MB, 추천 0개, 죽어있던 cron — 냉장고털기 삽질 3제

냉장고털기는 보유 재료로 만들 수 있는 한식을 추천해주는 식재료 관리 앱이다. 190여 개 커밋을 지나 내부 테스트 단계까지 오면서 삽질을 꽤 했는데, 그중 셋은 교훈이 분명해서 기록으로 남긴다. 공통점: 원인이 전부 예상 밖의 곳에 있었다.

1. AAB가 377MB — 범인은 코드가 아니었다

첫 릴리스 번들을 뽑았더니 377MB. Play Store 등록은커녕 웃음이 나오는 크기였다. 코드를 의심하고, 의존성을 의심하고, 폰트를 의심했지만 전부 아니었다.

범인은 이미지였다. 재료 일러스트와 레시피 썸네일을 원본 해상도 PNG로 그대로 넣고 있었다. 조치는 교과서적이었다:

1. 표시 크기에 맞춰 리사이즈
2. pngquant로 압축
3. PNG → WebP 일괄 변환

결과: 377MB → 80MB, 약 79% 감량. 하루 만에 끝났다. 몇 주 걸릴 줄 알았던 문제가 파이프라인 스크립트 하나로 정리된 셈이다. 교훈: 번들이 크면 코드보다 에셋부터 봐라.

2. 추천이 자꾸 0개 — 알고리즘 탓이 아니었다

핵심 기능인 보유재료 추천이 자꾸 “추천할 레시피 없음”을 뱉었다. 매칭 임계값을 조정하고, 가중치를 바꾸고, 부분 매칭을 넣고 — 알고리즘을 몇 번을 갈아엎어도 개선이 미미했다.

문제는 알고리즘이 아니라 데이터의 두께였다. 식약처 공공 레시피 1,146건은 재료 구성이 복잡한 정식 요리가 많아서, 평범한 자취 냉장고(계란·파·김치·두부)로는 조건을 만족하는 레시피가 드물었다.

해법은 코드가 아니라 콘텐츠였다. 재료 3~5개짜리 간단 레시피 47개를 직접 큐레이션해서 시드에 넣었더니 같은 냉장고에서 매칭이 0개 → 50개로 뛰었다.

데이터가 얇으면 알고리즘으로 못 메꾼다.

이 한 줄이 이 프로젝트에서 배운 것 중 제일 비쌌다.

3. cron이 조용히 죽어 있었다

레시피 DB가 스스로 자라도록 식약처 API를 주간 pg_cron으로 동기화하는 파이프라인을 만들어뒀다. 붙였고, 첫 실행도 확인했고, 잊고 있었다.

몇 주 뒤 우연히 로그를 봤는데 — cron이 인증 설정 이슈로 언젠가부터 조용히 실패하고 있었다. 에러 알림도, 실패 카운트도 없었으니 알 방법이 없었다. DB 자동 성장은 그동안 멈춰 있던 거다.

되살리는 건 금방이었지만, 진짜 문제는 따로 있었다. “자동화를 붙였다”와 “자동화가 돌고 있다”는 완전히 다른 문장이라는 것. 이후로는 동기화 성공/실패를 계측하고, 마지막 성공 시각을 확인할 수 있게 했다. 침묵하는 자동화는 없는 자동화보다 나쁘다 — 있다고 믿게 만드니까.

정리

증상	의심한 곳	진짜 원인
번들 377MB	코드·의존성	원본 해상도 이미지
추천 0개	매칭 알고리즘	시드 데이터 부족
DB 성장 정지	(몰랐음)	조용히 실패하던 cron

셋 다 “당연히 여기겠지” 싶은 곳이 아니라 한 층 아래에 원인이 있었다. 디버깅의 절반은 자기 가설을 의심하는 일이라는 걸, 이 앱이 세 번 가르쳐줬다.

냉장고털기는 현재 Android 내부 테스트 중이다. 진행 상황은 포트폴리오에서.