왜 우리는 '식단'으로 시작했나
크리에이티브엔진은 AI 기능을 얹는 대신 제품 아래에서 매일 돌아가는 엔진을 만듭니다. 두 차례 시범서비스로 수요를 먼저 검증하고, LLM 생성에서 결정론+LLM 판단 구조로 진화시킨 밥비서 이야기.
AI를 “얹는” 시대에, 우리는 아래를 보기로 했다
데모는 쉽다. 화면 구석에 챗봇 하나를 붙이고, 버튼 하나로 LLM을 한 번 호출하고, “AI 기능 탑재”라고 적는 일은 하루면 된다. 어려운 건 그다음이다. 사용자가 매일, 같은 기대를 갖고 다시 찾아오는 제품 안에서 그 결과가 계속 쓸 만하게 나오도록 만드는 일.
우리는 그 간극에서 회사를 시작했다. 크리에이티브엔진의 입장은 한 문장으로 줄어든다 — 우리는 AI를 얹지 않는다. 제품 아래에서 돌아가는 엔진을 만든다. AI를 표면의 기능으로 보면 데모에서 멈추고, 엔진으로 보면 사용자의 조건을 읽고 제약을 풀고 결과를 만들어 제품에 끼워 넣는 한 덩어리의 시스템이 된다. 슬라이드로는 둘이 똑같아 보인다. 매일 굴려보면 완전히 갈린다.
그래서 우리는 슬라이드보다 검증을 먼저 했다. 앱을 짓기 전에 두 차례 시범서비스를 손으로 굴렸다.
왜 하필 식단이었나
엔진이 진짜인지 증명하려면, 엔진을 가장 혹독하게 부수는 도메인이 필요했다. 우리는 식단을 골랐다. 우연이 아니라, 식단이 엔진의 약한 고리를 한꺼번에 시험하기 때문이다.
식단은 세 가지를 동시에 요구한다. 사용자의 요구는 한 번에 굳지 않는다 — 끼니 수, 인원, 못 먹는 재료, 한식·양식 구성비 같은 조건은 설문으로 받아도 시간이 지나며 바뀐다. 제약은 딱딱하다 — 영양 균형, 예산, 조리 난이도는 타협이 안 되는 숫자와 사실이다. 그리고 결과는 매일 평가받는다 — 이번 주 식단이 별로였다는 건 다음 주에 사용자가 앱을 열지 않는 것으로 즉시 돌아온다.
게다가 우리 타겟은 가장 까다로운 쪽이었다. 바빠서 “오늘 뭐 먹지, 뭐 사지, 어떻게 만들지”를 고민할 여력이 없는 현실적인 초보 집밥러. 이들에게 필요한 건 더 똑똑한 대화 상대가 아니라, 생각 없이 따라 하면 만들고 먹을 수 있는 한 주치 집밥이다. 그래서 밥비서는 자유발화를 받는 챗봇이 아니다. 입력은 구조화된 설문과 별점·선호 피드백이고, 출력은 요일×끼니로 짜인 주 단위 식단이다.
엔진의 척추 — 생성에서 판단으로
처음 우리가 떠올린 그림은 단순했다. “일주일 식단 짜줘”를 LLM에 던지고 받는 것. 시범서비스를 두 번 돌리며 그 그림이 무너졌다. LLM 단독 생성은 정합성·비용·속도·편차에서 매번 흔들렸고, “완전 개인화를 매번 새로 생성”하는 것보다 좋은 기준 식단을 갖춰두고 필요한 만큼만 개인화하는 쪽이 현실적이었다.
그 깨달음이 엔진의 척추가 됐다. 우리는 식단 코어를 LLM 없이 도는 결정론 알고리즘으로 다시 세웠다. 하드 제약을 먼저 지키고, 소프트 선호는 그다음, 안 되면 완화해 재시도하는 단계 구조. 다양성·예산·구성비·준비시간 같은 축을 가중 점수로 다룬다. 핵심은 같은 입력이면 같은 결과가 나오고, 왜 그 식단이 나왔는지 설명할 수 있다는 점이다.
그렇다고 LLM을 버린 게 아니다. 역할을 옮겼다. 식단을 만드는 자리에서 빼내, 만들어진 결과를 판단하고 검증하는 자리에 두었다. 생성은 결정론이, 판단은 LLM이. 이 이동이 비용과 편차를 동시에 잡았다.
시범서비스가 가르친 것
가장 큰 교훈은 코드가 아니라 순서에서 나왔다. 우리는 앱부터 만들지 않았다. 설문 도구와 자동화 워크플로우, 가벼운 DB와 알림만으로 식단을 손수 만들어 소수에게 보냈고, 만족도와 실행 가능성과 유료 의향을 먼저 확인했다. 수요가 있다는 신호를 손에 쥔 뒤에야 앱을 지었다.
엔진도 한 번에 나오지 않았다. 식단 로직은 여러 번 갈아엎었다 — 그 폐기와 재설계의 회고는 이 시리즈 뒤 회차에서 숨기지 않고 풀 것이다. 자체 제품을 직접 운영한다는 건, 검증 안 된 결정이 있으면 외부 고객보다 우리가 먼저 아프다는 뜻이다. 이 구조가 우리를 정직하게 만든다.
엔진은 식단에만 머물지 않는다
식단은 출발점이지 목적지가 아니다. 우리가 식단에서 검증한 건 레시피가 아니라 엔진이다 — 변화하는 사용자 조건을 딱딱한 제약과 매일의 평가 사이에서 쓸 만한 결과로 바꾸고, 생성과 판단의 역할을 제대로 나눈 파이프라인. 이 구조는 도메인에 묶여 있지 않다.
이 시리즈는 그 깊이를 한 편씩 증명하는 기록이다. 다음 글부터 결정론 엔진과 LLM 판단의 경계를 하나씩 열어, 무엇이 작동했고 무엇을 다시 썼는지 적어가겠다.