데모 AI와 매일 굴러가는 AI의 차이
데모에서 잘 돌던 AI도 제품에 들어오면 무너집니다. 빠름·정확·비용·자연스러움이 동시에 성립해야 하기 때문입니다. 밥비서를 매일 운영하며 LLM을 생성자에서 판단자로 옮긴, 운영이 만든 차이의 기록입니다.
데모에서 잘 되던 AI가 제품에 들어오면 무너진다
데모는 한 번의 좋은 출력이면 박수를 받는다. 한 사용자, 한 번의 호출, 운 좋은 입력 — 화면에 그럴듯한 한 주치 식단이 떠오르면 회의실은 설득된다. 우리도 그렇게 시작했다. 밥비서의 첫 그림은 “일주일 식단 짜줘”를 LLM에 던지고 받아오는 것이었고, 시범서비스의 데모에서는 그게 작동했다.
문제는 데모가 아니라 그다음이었다. 제품 안의 식단 생성은 한 사람을 위한 한 번의 출력이 아니다. 매주, 모든 사용자에게, 정해진 예산 안에서, 사용자가 AI를 의식하지도 못할 만큼 자연스럽게 나와야 한다. 데모에서는 공짜처럼 보이던 네 가지 조건 — 빠름·정확·비용·자연스러움 — 이 운영에 들어오는 순간 서로 충돌하기 시작했다. 데모는 이 충돌을 숨겨준다. 운영은 매주 그것을 청구서로 보낸다.
네 가지 제약이 동시에 성립해야 한다
밥비서의 식단 생성에서 네 축은 추상어가 아니라 구체적인 압력이다.
빠름. 사람이 손으로 짜면 한 끼 식단도 한참이다. 초기 파일럿에서 우리는 생성 시간을 수 시간 규모에서 수 분 규모로 끌어내렸다 — 다만 이건 소규모·초기 단계의 신호이지 보장된 벤치마크가 아니다. 정확. 영양 균형, 예산, 못 먹는 재료, 한식·양식 구성비 같은 제약은 타협이 안 되는 하드 조건이다. 한 끼라도 어기면 그 주 식단은 신뢰를 잃는다. 비용. 모든 사용자 × 매주 생성을 LLM 단독 호출로 감당하면 단가가 무너진다. 자연스러움. 우리 타겟은 바빠서 메뉴를 고민할 여력이 없는 초보 집밥러다. 이들에게 필요한 건 똑똑한 대화 상대가 아니라, 생각 없이 따라만 하면 되는 한 주치 식단이다.
데모에서는 이 넷을 따로따로 보여줄 수 있다. 운영에서는 한 번에 충족해야 한다. 빠르게 하려고 캐시를 키우면 정확이 흔들리고, 정확을 끝까지 밀면 비용과 속도가 무너진다.
운영이 강제한 결정 — LLM을 생성자에서 판단자로
네 제약이 동시에 걸리자, “AI가 식단을 통째로 써준다”는 매력적인 데모는 우리를 한 칸도 더 나아가게 해주지 못했다. LLM 단독 생성은 정합성·비용·속도·출력 편차에서 매번 흔들렸다. 같은 입력에도 결과가 달라졌고, 왜 그 식단이 나왔는지 설명할 수 없었으며, 하드 제약을 어겨도 모델은 천연덕스러웠다.
그래서 우리는 무대를 바꿨다. 레시피를 미리 만들어 태깅한 구조화 데이터를 깔고, 식단 코어 산출은 LLM 없이 도는 결정론 알고리즘으로 가져갔다. 하드 제약을 먼저 만족시키고, 소프트 선호는 그다음, 그래도 답이 없으면 제약을 완화해 재시도하는 단계 구조다. 다양성·예산·구성비·준비시간 같은 축을 가중 점수로 다룬다 — 중요한 건 숫자가 아니라 “하드 먼저, 소프트 나중, 안 되면 완화”라는 골격이다.
LLM은 버린 게 아니라 자리를 옮겼다. 만드는 자리에서 빼내, 만들어진 결과를 판단하고 검증하는 자리에 두었다. 생성은 결정론이 책임지니 빠르고 재현 가능하고 단가가 잡혔고, 판단은 LLM이 맡으니 결정론이 놓치는 결을 보완했다. 자연스러움은 챗봇 같은 대화에서 온 게 아니다. 계절과 날씨, 그날의 상황을 식단에 반영해 사용자가 따로 요청하지 않아도 맞아떨어지게 만든, 보이지 않는 조정에서 왔다.
한 번의 영리함이 아니라 반복된 재작성
이 구조는 한 번의 좋은 아이디어로 나오지 않았다. 식단 엔진은 v0에서 v3까지 여러 번 다시 쓰였다. 규칙 기반에서 출발해, 더 나은 탐색으로, 그리고 하드 제약을 보장하면서 빠른 그리디+재시도 구조로 — 매번 이전 버전을 버렸다. 각 재작성의 깊은 회고는 다음 회차의 몫이지만, 여기서 분명한 건 하나다. 데모를 운영으로 바꾸는 일은 한 번의 영리함이 아니라 측정과 재작성의 반복이었다.
그 반복을 굴리는 동력은 운영 루프다. 우리는 사용자의 별점과 선호·비선호 신호를 모아, 식단 품질을 주기적으로 되짚고 개선한다. 피드백이 즉시 개인 모델을 재학습하는 마법은 아니다 — 신호를 모아 알고리즘과 정책을 다음 사이클에 손보는, 느리지만 정직한 루프다. 그리고 이 무너지는 지점을 우리는 외부 고객보다 먼저 발견한다. 자체 제품을 매일 굴린다는 건, 검증 안 된 결정이 있으면 우리가 먼저 아프다는 뜻이기 때문이다.
데모가 아니라 운영을 맡긴다는 것
데모를 만드는 회사는 많다. 어려운 건 그 데모를 매일, 모든 사용자에게, 예산 안에서, 사용자가 눈치채지 못할 만큼 자연스럽게 굴리는 일이다. 우리는 자체 제품에서 그 네 제약의 충돌을 통과시켜 봤다 — LLM의 역할을 옮기고, 엔진을 여러 번 다시 쓰면서.
이 운영 역량은 식단에 묶여 있지 않다. 같은 네 제약은 어떤 도메인의 AI에도 똑같이 걸린다. 데모 수준이 아니라 매일 굴러가는 수준의 AI를 당신의 제품 아래로 옮기는 이야기가 궁금하다면 — partners@creativengine.ai.