로컬 우선 모바일 앱 포트폴리오를 운영하는 인디 앱 개발자로서 제 핵심 철학은 늘 속도, 유용성, 비용 효율이었습니다. TinyRecipe의 목표는 간단했습니다. 지금 냉장고나 팬트리에 있는 재료만으로 실용적인 단계별 레시피를 만들어 사용자가 음식물 낭비를 줄이도록 돕는 것입니다.
모바일 클라이언트에 생성형 AI를 추가하면 설계를 신중히 하지 않을 경우 응답 지연, 예측할 수 없는 JSON 페이로드, 치솟는 API 비용으로 빠르게 이어질 수 있습니다. 다음은 Vertex AI의 Gemini를 기반으로 하는 Firebase AI Logic을 통합해, 운영 비용을 최소화하면서 빠르고 구조화된 레시피 생성을 제공한 방법입니다.
핵심 과제: LLM 제어하기
LLM에 레시피를 자유롭게 구성하도록 맡기면 곧바로 세 가지 문제가 나타납니다.
- 환각과 이상한 조합: 올리브 오일, 간장, 레몬으로 수프를 만들라고 제안할 수도 있습니다.
- 스키마 불일치: 자유 형식 텍스트나 구조화되지 않은 Markdown을 다시 네이티브 모바일 UI 컴포넌트로 파싱하면 클라이언트 쪽에서 쉽게 깨집니다.
- 높은 토큰 소비: 제한 없는 응답은 여러 단계의 조리 지침에서 토큰 예산을 빠르게 소진합니다.
이를 해결하기 위해 Firebase의 Vertex AI 백엔드 통합을 사용해 엄격한 시스템 지침과 구조화된 출력 파싱을 적용했습니다.
1. 시스템 프롬프트 가드레일과 JSON 스키마 강제
모델에 좋은 레시피를 요청하는 대신, 시스템 프롬프트가 모델을 엄격한 JSON 스키마 계약 안으로 제한합니다.
{
"title": "String",
"prep_time_minutes": "Number",
"difficulty": "Easy | Medium | Hard",
"matched_pantry_items": ["Array of Strings"],
"missing_staples_required": ["Array of Strings"],
"instructions": [
{
"step_number": 1,
"text": "String"
}
]
}두 가지 가드레일 덕분에 실제로 기능이 훨씬 유용해졌습니다.
- 기본 상비 재료 예외: 사용자가 팬트리 목록에서 소금, 후추, 수돗물, 식용유를 일일이 체크할 필요가 없어야 합니다. 시스템 프롬프트는 이런 기본 재료를 명시적으로 허용해 선택 UI의 불편을 없앱니다.
- 엄격한 재료 구분: 모델은 외부 재료를 추가로 제안하기 전에 사용자의 디지털 팬트리에서 사용 가능으로 표시된 재료를 우선합니다.
2. 클라이언트 측 최적화: 마찰 없는 UX
주방에서 모바일 키보드로 “닭가슴살 깍둑썰기 250g”을 입력하고 싶은 사람은 없습니다.
[사용자가 팬트리 태그 탭] -> [클라이언트가 배열 구성] -> [Firebase AI 요청] -> [네이티브 UI 렌더링]- 빠른 선택 카테고리 태그: UI는 흔한 냉장고·팬트리 재료를 카테고리별로 빠르게 켜고 끌 수 있는 태그로 보여 줍니다.
- 로컬 캐싱: Firebase AI Logic 요청을 보내기 전에 앱이 선택된 팬트리 배열을 해시합니다. 사용자가 짧은 시간 안에 같은 핵심 재료로 레시피를 요청하면 TinyRecipe는 추가 API 호출 없이 캐시된 결과를 즉시 제공합니다.
3. 배운 점과 다음 단계
Firebase AI Logic 덕분에 혼자 개발하는 사람도 생성형 AI 기능을 놀라울 만큼 쉽게 확장할 수 있었습니다. 모델 경계에서 엄격한 JSON 스키마를 강제하고 상태를 로컬에 유지함으로써 TinyRecipe는 다음을 달성합니다.
- 2초 이내의 생성 시간
- 파싱 실패 없이 예측 가능한 클라이언트 렌더링
- API 토큰 낭비 거의 없음
AI 팬트리 기능은 이제 iOS와 Android 모두에서 사용할 수 있습니다.