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