AI 트랜스포메이션을 함께: 우리가 일하는 방식

지난 11편은 거창한 비전 선언이 아니었다. 한 회사가 자기 제품을 가지고 무엇을 증명하려 했는지에 대한 기록이었다. 식단 엔진을 네 번 다시 쓴 회사, 코드를 에이전트가 쓰는 회사, 그리고 지금 당신이 읽는 이 블로그조차 기획부터 발행까지 에이전트가 굴리는 회사 — 그게 우리가 12주 동안 남긴 흔적이다.

우리는 그동안 “AI가 세상을 바꾼다”는 문장을 한 번도 쓰지 않으려 애썼다. 대신 매번 구체적인 결정 하나를 꺼내 놓고, 왜 그렇게 했고 무엇을 버렸는지를 적었다. 이 마지막 글은 새로운 폭로가 아니다. 흩어진 11개의 증거를 하나의 결론으로 묶는 일이다 — 우리는 AI 기능을 얹지 않는다. 그 아래에서 돌아가는 엔진을 만든다.

우리가 12주간 증명한 것

세 덩어리로 종합된다.

제품으로. 데모는 챗봇 하나를 화면 구석에 붙이면 끝나지만, 매일 같은 기대를 들고 돌아오는 사용자 앞에서 그 결과가 계속 쓸 만하게 나오는 건 다른 문제다(데모 AI와 매일 굴러가는 AI의 차이). 밥비서의 식단 엔진은 LLM에 “식단 짜줘”라고 던지지 않는다. 설문과 피드백으로 모은 조건을, 계절·상황을 반영해 결정론 알고리즘으로 최적화한다. 그 엔진을 네 번 다시 썼고, 그 아래에 한국어 도메인 데이터 파이프라인을 깔았다. 왜 식단이었는지는 첫 글에 있다.

방법으로. 그다음은 우리가 일하는 방식 자체를 소재로 삼았다. 제품 규모의 코드를 에이전트 오케스트레이션으로 구현했고, 이 블로그의 콘텐츠 공급망을 기획→작성→검증→발행으로 에이전트가 운영하게 했으며, 사용자가 AI를 의식하지 않도록 입력 부담을 덜어내는 UX를 설계했고, 백엔드 없는 정적 인프라 위에 이 모든 걸 올렸다.

방향으로. 마지막은 아직 진화 중인 테제였다. 에이전트가 개별 태스크를 넘어 워크스트림을 ‘소유’하는 자율 운영, OS 스케줄러로 에이전트를 상시 굴리는 가장 단순한 방법, 그리고 정적 RAG의 한계를 넘는 살아있는 컨텍스트. 이건 완성된 제품이 아니라 우리가 향하는 지평이다.

왜 ‘엔진’이고 왜 ‘함께’인가

기능을 얹는 접근은 빠르다. 슬라이드에서 멋지고, 데모에서 작동한다. 문제는 거기서 멈춘다는 것이다 — 매일 굴러가지 않는다. 엔진을 까는 접근은 그 반대다. 느리고, 비용이 들고, 무엇보다 우리 제품에 먼저 검증해야만 한다. 우리는 후자를 택했고, 그 대가를 12주 내내 지불했다.

그 선택이 “함께”라는 단어로 이어진다. 엔진의 원리는 이식할 수 있다. 결정론을 먼저 짜고 LLM은 게이트를 통과해야만 더하는 구조, 파괴적·비용 발생 행위를 승인 전까지 막는 확인 게이트, 컨텍스트 윈도우나 DB가 아니라 파일을 상태로 두어 재현·검사·크래시 안전을 얻는 방식 — 이건 도메인을 가리지 않는다. 컨슈머 앱이든 제조 현장의 AI 전환 같은 산업 카테고리든, 표면 기능을 운영 가능한 엔진으로 바꾸는 원리는 같다.

하지만 도메인과 운영 맥락은 고객 안에 있다. 그래서 AI 트랜스포메이션은 도구 납품이 아니라 동행이다. 우리는 원리를 들고 들어가고, 당신의 제품 안에서 그 원리가 매일 굴러가도록 함께 만든다.

12주가 우리에게 남긴 것

가장 큰 자산은 정직이었다. 우리는 자기 제품과 자기 운영으로 먼저 검증한다는 원칙을 지켰고, 그래서 검증 안 된 방법론을 남에게 권하지 않을 수 있게 됐다. 옵티마이저를 폐기한 일, vibe coding으로 실패한 일조차 숨기지 않고 방법론으로 자산화했다. 실패담이 신뢰의 핵심이라는 걸 12주가 가르쳐 줬다.

그리고 BUILDING은 BUILDING이라고 부른다. 자율 운영과 동적 컨텍스트는 우리가 향하는 방향이지 이미 끝난 제품이 아니다. 그 경계를 흐리지 않는 것 자체가 우리가 일하는 방식이다.

다음은, 같은 원리를 다른 도메인으로

엔진의 원리는 도메인을 가리지 않는다. 컨슈머든 B2B든, AI를 제품의 표면 기능이 아니라 매일 운영 가능한 엔진으로 만드는 일 — 우리가 먼저 우리 제품에 그렇게 해왔다.