조건에 맞는 레시피 50개를 SQL로 거르는 건 통과/탈락일 뿐 순위가 아니다. 가까운 것을 빠르게 찾은 다음, 그중 무엇을 어떤 순서로 모델에게 먹이느냐가 답을 가른다. 랭킹·rerank·주입·환각의 기록.
글자가 0% 겹치는 돈전지와 앞다리살이 코사인 0.93으로 묶인다. 밥비서에서 흩어진 재료를 모으며 거리를 재고, 전부와 비교하지 않고 찾고, 도메인이 미리 잘라준 청크를 쓴 이야기.
돈전지와 앞다리살은 글자가 한 자도 안 겹치는데 같은 재료다. 밥비서에서 흩어진 재료를 하나로 묶으며, 우리는 임베딩과 의미 공간을 이름도 모른 채 먼저 썼다. 언어가 숫자가 되는 과정의 기록.
AI 품질에서 가장 위험한 문장은 "좋아진 것 같다"이다. 규칙 하나, 판단자 하나를 바꿀 때마다 같은 잣대로 다시 재고 회귀를 먼저 잡는 일 — 한국어 도메인 코퍼스에서 "좋아졌다"를 주장이 아니라 측정으로 바꾼 eval 하네스 이야기.
생성형 AI의 출력은 유창하지만 그게 곧 정확함은 아니다. 더 똑똑한 생성 대신, 우리는 LLM을 판단자 자리로 옮겼다. 코퍼스에 그럴듯한 허구가 쌓이지 않도록 생성과 판정을 분리하고, 판정을 데이터 승격 게이트로 세운 기록.
데이터에 태그를 붙이는 건 누구나 한다. 무엇으로 나눌지를 정하는 일은 다르다 — 분류 축의 선택이 곧 도메인 이해의 증거다. 계절·제철·난이도·구성 같은 축을 어떻게 설계하고, 같은 레시피에 매번 같은 라벨이 붙도록 일관성을 어떻게 지키는가.
한국어 레시피는 같은 재료·단위·조리법을 수십 가지로 적는다. 표기·단위·조리표현의 흔들림을 일관 형태로 모으는 정규화는 잡일이 아니라 "같다/다르다"의 경계를 긋는 의미 결정의 공정이다.
"데이터가 8할"은 누구나 말한다. 정작 그 8할이 무엇으로 이루어졌는지는 잘 말하지 않는다. 한국어 식문화 도메인에서 우리가 매일 굴리는 정제·태깅·검증·평가·grounding이라는 데이터 공정의 해부도, 그리고 이를 한 편씩 펼칠 시리즈의 출발점.
에이전트가 git 이력을 '기억'으로 읽기 시작하면, 한 레포에 쌓인 제품 이력과 운영 이력은 서로의 신호를 노이즈로 만든다. 운영 평면을 교체 가능한 control-store 포트로 떼어내고 과거는 동결하는, 에이전트 시대의 형상관리 원칙.
에이전트를 24시간 굴리는 데 무거운 워크플로 엔진은 필요 없었다. OS 스케줄러(launchd/cron) + 헤드리스 CLI + 파일=git 상태머신으로 재현·검사·크래시 안전한 상시 운영 런타임을 만든 이야기.
AI 회사 블로그인데 굴릴 서버가 없다. 이미지 변환은 CDN URL에 위임하고, 예약발행은 런타임 대신 빌드타임 게이트와 일일 스케줄 빌드로 풀었다. 백엔드를 '안 두는 것'도 설계라는 이야기.
좋은 AI UX는 사용자가 AI를 의식하지 않는 UX입니다. 밥비서는 챗봇이 아닙니다. 자유발화 대신 구조화 설문과 프리셋으로 의도만 받고, 그 아래 결정론 엔진이 식단을 짭니다. 입력 자유도를 줄여 신뢰를 올린 설계 이야기.
AI로 글을 한 번 뽑는 것과, 기획·작성·검증·발행을 멀티에이전트로 매일 운영하는 것은 다르다. 지금 읽는 이 글이 그 시스템의 산출물이다 — 검증 게이트와 사람 승인을 둔 이유.
에이전트로 코딩한다는 데모 말고, 매일 운영되는 제품을 SPEC 단위·에이전트 주도로 재구축한 경험과 실패. 초기 7개월은 손으로 짰고 2026년 봄에 전환했다. 무엇이 깨지고 무엇이 남았나.
규칙에서 그리디+재시도까지, 식단 엔진을 네 세대 다시 썼다. 매번 측정이 재작성을 강제했고, 코어에서 LLM을 빼 결정론으로 짠 이유 — 우리가 AI를 '어디에 쓰지 않을지'부터 설계하는 방식.
한국어 식문화 도메인에 LLM을 붙이는 일의 병목은 모델 선택이 아니라 코퍼스 품질이었다. 레시피 데이터를 정제·태깅·검증하고, LLM의 역할을 생성자에서 판단자로 옮긴 밥비서 도메인 적응의 기록.
크리에이티브엔진 기술블로그를 시작합니다. 무엇을, 왜, 어떻게 기록할지에 대한 첫 노트.