에이전트 프레임워크는 해롭다고 봅니다: 이벤트 기반 런타임 설계

URL: https://www.youtube.com/watch?v=Nt2aeDlzk4U
날짜: 2026-08-24
채널: Tech Bridge
발화자: Rémi Louf
길이: 20분

---

📌 핵심 질문 / 에이전트 프레임워크가 가려버리는 것

==대화형 도구에 사람이 계속 붙어 있어야 하는 에이전트를 어떻게 신뢰할 수 있는 백그라운드 시스템으로 바꿀 것인가?== 핵심 답은 거대한 그래프 프레임워크가 아니라, 파일로 선언하는 에이전트 정의, 일정(Schedule), 타입이 있는 도구 호출과 이벤트, 추가 전용(append-only) 로그, 콘텐츠 주소 지정(content addressing), 구조화된 출력(structured output)이다.

• 2025년 12월 무렵 에이전트 능력이 단계적으로 좋아졌고, Rémi Louf는 이를 직접 확인하기 위해 2026년 1월 2주간 본업에서 떨어져 실험했다.
• 대화형 TUI와 휴대폰 원격 조작은 에이전트가 혼자 일하는 것처럼 보여도 사람이 계속 궤도를 수정해야 하는 과도기적 인터페이스다.
• 실제 운영에서 드러난 중복 게시, 유실, 프롬프트 회귀 문제는 새로운 AI 이론보다 큐, 버전 관리, 로그, 재현 가능한 빌드 시스템 같은 오래된 소프트웨어 공학으로 해결된다.
• 시스템의 목표는 나쁜 행동의 확률을 낮추는 데 그치지 않고, 타입 경계를 통해 나쁜 행동을 불가능하게 만드는 것이다.

에이전트는 독립적인 마법의 존재가 아니라 이벤트를 받아 작업하고 새로운 이벤트를 내보내는 프로세스다. 이 관점에서는 에이전트 사이의 연결선을 사람이 일일이 유지하는 그래프보다, 시스템에 존재하는 이벤트를 구독하는 단순한 토폴로지가 더 개방적이고 디버깅 가능하다. 관찰가능성을 확보하려면 모델에 실제로 전달된 컨텍스트를 해시로 추적하고, 실행 사이의 차이를 비교하며, 과거 요청을 다시 재생할 수 있어야 한다.

1. 2주간의 몰입: 원격 조작에서 백그라운드 에이전트로

에이전트를 직접 써보며 불편한 부분을 해결하려는 개인적 필요가 시스템 설계의 출발점이 됐다.

1.1. Opus 4.6과 2주 휴가

1. 능력의 단계적 변화

   1. 시점: 2025년 12월 무렵 에이전트가 갑자기 좋아지기 시작했다. Rémi Louf는 AI 분야에서 일하고 있었지만, Opus 4.6이 등장한 시점에 “이 일이 정말 일어나고 있다(This thing is really happening)”고 느꼈다.
   2. 실험의 동기: 막연히 AI 회사라는 사실을 되풀이하는 대신, 실제로 무엇을 얻을 수 있고 얼마나 효과적인지 알아보기로 했다.

2. 본업을 멈춘 실험

   1. 회사와 역할: Text라는 15명 규모 회사의 CEO로서 CTO에게 2주간 이 기술에 집중하겠다고 알렸다. 이사회에는 알리지 않은 채 공동창업자가 코딩을 시작한 “아주 멍청한 일”이었다는 농담도 덧붙였다.
   2. 탐구 범위: 에이전트를 실제 업무에 어떻게 활용할지, 에이전트를 만드는 좋은 기본 요소(primitives)가 무엇인지, 이미 쓸 만한 기술이 존재하는지를 직접 확인했다.

1.2. 로봇 잔디깎이와 아침 루틴

1. 사무실의 로봇 잔디깎이

   1. 무인 백그라운드 작업: 성(castle)에 있는 사무실을 임대해 쓰고 있으며, 사진 왼쪽에 보이는 작은 장치가 로봇 잔디깎이다. 사람의 리모컨 조작이나 지속적인 주의 없이 하루 종일 작동한다.
   2. 원하는 에이전트의 기준: 에이전트도 이 기계처럼 배경에서 자기 일을 끝내고, 사용자가 나중에 결과만 받기를 바랐다.

2. 매일 반복되는 첫 두 시간

   1. 업무 입력: 아침마다 시장 뉴스를 훑고, Linear나 Jira 같은 업무 시스템과 CRM을 검토한다.
   2. 산책과 음성 메모: 한 시간 정도 들판을 걸으며 생각을 긴 음성 메모로 녹음하고, 그다음 한 시간은 걸으면서 남긴 메모를 처리하는 데 쓴다. 원하는 결과는 커피와 함께 읽는 아침 브리핑이었다.

3. 현재의 인터페이스가 가진 모순

   1. TUI의 한계: 코딩을 하지 않아도 에이전트를 쓸 수 있게 됐지만, 당시 사용 경험은 사실상 TUI(Text User Interface)에 머물렀다. 코딩 외의 작업에는 에이전트가 특히 강력했지만, 사람이 계속 화면을 보고 있어야 했다.
   2. “SSH with vibes”: 연구소들이 내놓은 앱은 Rémi Louf가 “분위기를 입힌 SSH(SSH with vibes)”라고 부른 형태였다. 휴대폰에서 직접 SSH를 쓰지 않아도 된다는 점은 훌륭했지만, 산책하면서 계속 에이전트에게 지시하는 순간 사용자는 생각을 제대로 하지 못했다.
   3. 트랙터 비유: 스스로 달리는 잔디깎이 트랙터에 올라탄 채 운전하는 것과 비슷하다. 바로 옆에 붙어 있지 않아도 되지만, 여전히 리모컨을 들고 가끔 진행 방향을 바꿔야 한다.
   4. 과도기의 부조리: 사람들이 휴대폰을 계속 붙잡고 에이전트의 궤도를 수정하는 모습은 유용하면서도 부조리하다. “분명 과도기이며 여기서 멈추지는 않을 것”이라는 판단이 독립형 백그라운드 에이전트를 만들게 했다.

2. 코드 없는 선언과 이벤트 기반 토폴로지

프레임워크의 내부 추상화보다 파일·스케줄·이벤트 계약을 기본 단위로 삼으면, 에이전트의 존재와 연결을 코드 밖에서 관리할 수 있다.

2.1. 프레임워크에서 파일 정의로

1. 첫 번째 구현의 방향

   1. 작동하는 가장 단순한 것: Rémi Louf는 본인이 만든 저장소에 “코드는 훌륭하지 않지만 작동한다”고 말하며, 먼저 가능한 한 멍청하고 단순한 것을 만들었다.
   2. 프레임워크 사용의 문제: 특정 프레임워크 이름은 들지 않았다. 각 프레임워크가 저마다 좋은 흐름을 갖고 있다는 점은 인정했지만, 코드 안의 프롬프트를 계속 편집하는 일이 실제로는 유용하지 않다고 느꼈다.

2. YAML을 싫어해도 선언형 파일은 유용하다

   1. 코드 없는 에이전트: YAML을 좋아하지 않지만, 에이전트를 코드 없이 구현하는 편이 훨씬 쉬웠다. 파일을 작성해 폴더에 넣으면 런타임이 준비되는 순간 에이전트가 나타나 작동한다.
   2. 소프트웨어 공학의 이점: 파일은 버전 관리(version control), diff 비교, PR 리뷰가 가능하다. 프롬프트가 코드에 박혀 있을 때보다 변경의 원인과 영향 범위를 확인하기 쉽다.

2.2. 일정에서 이벤트로

1. 일정 기반 작업의 출발점

   1. 시장 시세 확인: 들판을 걷는 동안 매일 아침 시장을 감시하려면 cron job과 schedule을 사용해 에이전트가 실행될 시점을 정한다.
   2. 숨은 동작: 일정은 단순히 작업을 실행하는 데 그치지 않고 결과 이벤트를 게시한다. Markdown과 cron이라는 외부 인터페이스는 단순하지만 내부 런타임은 더 복잡하다.

2. cron job이 놓치는 사건

   1. 시점과 사건의 차이: cron은 “언제(when)”를 표현하지만, 음성 메모가 시스템에 들어오거나 이메일·CRM 항목·PR에 변화가 생기는 “무슨 일이 일어났는가(what happened)”를 표현하지 못한다.
   2. 반응형 처리: 새 이메일, CRM의 새 항목, 새 PR의 개방(open), PR 병합(merged) 같은 모든 사건이 이벤트를 발생시키고, 해당 이벤트를 구독한 에이전트가 반응한다.

3. 음성 메모 파이프라인의 계약

   1. 입력과 출력: 음성 메모 처리 에이전트는 “음성 메모(voice note)를 받는다”고 선언하고, 이를 전사(transcription)해 영구 메모(durable note)로 만든 뒤 새 이벤트를 반환한다.
   2. 구조화된 출력: 어떤 값을 받아들이고 어떤 이벤트를 반환하는지를 명시하기 위해 structured output을 사용한다. 자연어 응답을 다음 단계의 암묵적인 입력으로 넘기지 않고, 시스템이 검증할 수 있는 이벤트로 바꾼다.

4. 아침 브리핑의 실제 연결

   1. 여러 생산자의 결합: voice-note agent가 voice_note_processed 이벤트를 내보내고, 시장 감시 cron job도 결과를 내보낸다. daily brief agent는 두 종류의 결과를 받아 아침 브리핑을 만든다.
   2. Slack 게시: 브리핑은 Slack 메시지로 게시된다. slack.message.post 이벤트를 구독한 프로세스가 실제 Slack 메시지를 Rémi Louf에게 보낸다. 직접 작동하는 시스템이며 휴대폰으로 결과를 확인할 수 있을 정도로 운영 중이었다.

2.3. 그래프 대신 이벤트 구독

1. 프레임워크의 그래프 주장에 대한 반론

   1. 그래프 불필요: “이 경우 그래프는 필요하지 않다. 필요한 것은 이벤트뿐이다(You do not need graphs. In this case all you need is events).” 에이전트 사이의 모든 연결선(edge)을 별도로 관리할 필요가 없다.
   2. 구독 모델: 각 에이전트는 이벤트를 구독하고, 다른 사람이 들어와 파일을 수정해도 전체 그래프를 다시 설계할 필요가 없다. 코딩을 몰라도 시스템에 어떤 이벤트가 존재하는지만 알면 된다.

2. 파일과 로그로 토폴로지가 생긴다

   1. 선언의 효과: 에이전트 정의 파일을 폴더에 넣으면 런타임이 이를 발견하고 실행한다. 연결선이 먼저 있는 것이 아니라, 이벤트 흐름에 따라 토폴로지가 출현한다.
   2. 관찰의 효과: 무엇이 일어났는지는 로그에 기록된다. “재미는 공짜”라는 표현처럼, 코드와 명시적인 그래프를 늘리지 않고도 실행 흐름과 결과를 확인할 수 있다.

3. 실패 모드가 런타임을 만든 과정

첫 구현은 약 하루 만에 작성됐지만, 실제 사용 직후 드러난 실패가 시스템의 핵심 기능을 하나씩 요구했다.

3.1. 첫 주에 발생한 세 가지 사고

1. 중복 브리핑

   1. 사례: 첫날 daily brief가 Slack에 두 번 게시됐다.
   2. 원인: 여러 시도가 진행됐지만 각 시도를 제대로 추적하지 않았고, 적절한 큐(queue)와 시도 횟수(attempt count)를 두지 않았다.

2. 유실된 음성 메모

   1. 사례: 수요일에 녹음해 둔 음성 메모 하나가 완전히 사라졌다.
   2. 요구사항으로의 전환: 잃어버린 메모는 모든 입력과 중간 결과를 영구 보존하는 로그의 필요성을 만들었다. 나중에 돌아가 무엇이 일어났는지 조사하려면 유실 자체가 없어야 한다.

3. 망가진 시장 브리핑

   1. 사례: 주중 내내 프롬프트를 바꿔가며 놀았고, 주말이 되자 시장 분석 브리핑은 형편없는 결과가 됐다.
   2. 원인: 프롬프트 변경을 버전 관리하지 않아 어떤 수정이 결과를 망가뜨렸는지 기억할 수 없었다. 에이전트의 실패가 모델의 능력 부족인지, 프롬프트 회귀인지 구분할 방법도 없었다.

3.2. “새로운 것은 없다”는 분산 시스템의 쇼핑 목록

1. 오래된 해법의 재발견

   1. 분산 시스템 엔지니어의 익숙함: 잃어버린 데이터, 중복 실행, 재시도 추적, 큐, 버전 관리라는 문제 목록은 분산 환경을 다뤄본 엔지니어에게 익숙하다. “태양 아래 새로운 것은 없다(There is nothing new under the sun)”는 결론이다.
   2. 런타임의 구성: 각각의 실패 모드가 로그, 큐, 재시도 추적, 재현 가능한 프롬프트 빌드 같은 런타임 구성 요소 하나로 변했다.

2. 콘텐츠 주소 지정 시스템

   1. 아이디어: 마지막 프롬프트 문제를 파고들다가 content-addressed system을 만들었다. Git, Nix, 그 밖의 빌드 시스템처럼 콘텐츠 자체에서 얻은 해시를 주소이자 식별자로 사용한다.
   2. 의도와 결과: 처음부터 런타임을 설계하려던 것이 아니다. 에이전트가 작동하기만을 바랐고, 다른 일에서 잠시 벗어나는 산만함도 즐겼다. 오류가 보일 때마다 그때그때 부채를 갚듯 기능을 추가하다 보니 런타임이 만들어졌다.

3.3. 추가 전용 로그: 시스템의 기억

1. 유실을 없애는 저장 모델

   1. 핵심 문장: “로그는 시스템의 기억이다(The log is the system’s memory).” 아무것도 잃지 않고 모든 것을 관찰하려면 이벤트를 추가 전용(append-only) 저장 영역에 남겨야 한다.
   2. 전체 이벤트 보존: 명령 실행에서 발생한 이벤트를 모두 보존하면 입력, 처리, 결과를 나중에 다시 읽을 수 있다.

2. 인과 관계와 조회

   1. 인과 연결: 이벤트가 서로 인과적으로 연결되어 어떤 이벤트가 어떤 이벤트를 촉발했는지 알 수 있다. 음성 메모가 전사 이벤트를 만들고, 그것이 영구 메모와 브리핑으로 이어지는 흐름을 따라갈 수 있다.
   2. 디버깅과 확장: 모든 내용을 조회할 수 있다는 점은 디버깅에 특히 유용하다. 에이전트 세 개만 있어도 디버깅이 크게 어려워지므로, 원인과 결과를 연결하는 로그가 중요하다.

4. 모델이 실제로 본 것을 추적하는 관찰가능성

실행 로그만으로는 충분하지 않다. 대화창에 보이는 기록과 모델에 실제로 전달된 컨텍스트가 다르기 때문이다.

4.1. 라이브 채팅 화면의 오해

1. 보이는 대화와 실제 입력의 차이

   1. 가짜처럼 보이는 실행 기록: Codex를 사용하면 모델과 실시간 채팅을 하는 것처럼 보인다. 사용자는 화면의 대화가 모델이 본 전부라고 생각하기 쉽다.
   2. 실제 컨텍스트: 실제로 모델이 본 것은 화면에 보이는 것과 정확히 같지 않다. 컨텍스트 압축(compaction), 내부적인 여러 처리, 도구와 프롬프트의 조합이 차이를 만든다.

2. 사고 흔적의 비공개

   1. 모델 제공자의 한계: OpenAI와 Anthropic은 사고 과정(thinking trace)을 공유하지 않는다. 따라서 어떤 내부 입력과 사고가 결과에 영향을 줬는지 완전히 알 수 없다.
   2. 새로운 요구: 대략적인 감이 아니라 실제 컨텍스트를 되짚을 수 있는 시스템이 필요하다. 이것이 단순한 에이전트 제작에서 큰 추가 탐구로 이어졌다.

4.2. 프롬프트를 문자열이 아닌 그래프로 주소 지정하기

1. 프롬프트를 이루는 구성 요소

   1. 고정·도구 정보: 시스템 프롬프트, 첫 번째 스킬 설명, 두 번째 스킬 설명, 도구 설명이 각각 하나의 구성 요소다.
   2. 실행별 정보: 사용자 메시지, 즉 모델에 보내는 질문도 별도 구성 요소다. 모델의 답변도 같은 방식으로 저장한다.

2. 해시 기반 표현

   1. 저장과 식별: 각 구성 요소를 저장하고 해시(hash)를 식별자로 부여한다. 프롬프트를 곧바로 하나의 긴 문자열로 렌더링하지 않고, 해시 목록으로 표현한다.
   2. 컨텍스트 추적: 나중에 모델 답변에서 역으로 프롬프트를 따라가면, 모델 컨텍스트에 어떤 시스템 지침·스킬·도구·사용자 입력이 들어갔는지 정확히 알 수 있다.

3. 그래프 조작의 이점

   1. 문자열보다 안정적: 문자열을 통째로 다루는 대신 구성 요소 그래프를 조작하므로, 어느 부분이 바뀌었는지와 재사용 가능한 부분을 쉽게 파악할 수 있다.
   2. 압축과 KV 캐시: 컨텍스트 압축이 쉬워지고, 간접적으로 KV 캐시 관리도 단순해진다. 이미 저장된 동일 구성 요소를 재사용할 수 있기 때문이다.
   3. 감사 가능성(auditability): 특정 에이전트에 무슨 일이 일어났고 왜 그 결과를 반환했는지 정확히 설명할 수 있다. Rémi Louf가 이 방식의 가장 큰 장점으로 꼽은 부분이다.

4.3. 실행 간 diff와 replay

1. 무엇이 바뀌었는가

   1. 구성 요소 비교: 두 실행을 비교해 어떤 구성 요소가 달라졌는지 묻는다. 사용자 메시지만 바뀌었는지, 모델에 다른 스킬을 줬는지, 다른 도구를 부여했는지 확인할 수 있다.
   2. 세션의 연속성: 예시에서는 세 구성 요소가 동일하고 사용자 메시지 하나가 달랐다. 그 밖의 메시지는 하나의 세션이 이어지며 생성한 연속 컨텍스트였다.

2. 비용과 오픈 소스 모델 실험

   1. 관찰가능성의 비용: 시스템을 관찰하기 시작하면 비용이 매우 빠르게 증가하는 사실도 드러난다. 사용량과 요청을 기록하면서 비용 상승을 실제로 확인했다.
   2. 평가 재실행: 과거 평가용 요청을 다시 구성해 같은 결과가 나오는지, 만족스러운지, 무엇을 바꿔야 하는지 확인하고 싶었다. 오픈 소스 모델을 시험하려는 동기도 여기서 생겼다.

3. 그래프에서 요청을 재생성

   1. 정확한 replay: 콘텐츠 주소 지정 시스템이 있으면 그래프에서 과거 요청을 다시 구성해 동일하게 재생할 수 있다.
   2. 변형 실험: 같은 요청을 다시 보내거나 다른 모델로 보내거나, 요청 자체를 수정할 수 있다. 구현 비용은 들지만 평가·디버깅·모델 교체를 위한 기능을 한꺼번에 얻는다.

5. 프레임워크가 아니라 런타임과 커널

에이전트 추상화를 호출하는 라이브러리와, 에이전트를 스케줄링·격리·기록하는 런타임은 구분해야 한다.

5.1. 라이브러리와 런타임의 차이

1. 당시 생태계에 대한 관찰

   1. 라이브러리 중심: 작업을 시작했을 때는 많은 라이브러리가 있었지만, 대체로 프레임워크였다. 프레임워크는 코드를 호출하고, 에이전트는 프레임워크의 추상화 내부에 갇힌다.
   2. 필요한 층: 에이전트의 실제 작업 내용과 관계없이 실행을 예약하고, 격리하고, 정의와 로그를 함께 기록하는 시스템 층이 필요하다.

2. 운영체제 비유의 제한적 사용

   1. 프로세스 모델: 운영체제 커널이 프로세스를 실행한다고 가정하면, 에이전트는 하나의 프로세스처럼 볼 수 있다. 커널은 작업 내용을 알 필요 없이 스케줄링하고 격리한다.
   2. 저널링: 실행된 프로세스는 에이전트 정의와 로그를 함께 남긴다. 이 비유는 에이전트 자체보다 에이전트를 담는 운영 환경에 초점을 둔다.

3. Markdown은 사용자 영역

   1. 선택 가능한 프런트엔드: Markdown은 사용자 영역(user land)의 인터페이스다. 시스템의 프런트엔드가 Markdown을 사용하지 않더라도 런타임의 핵심 원리는 유지된다.
   2. 핵심과 표현의 분리: 파일로 선언하는 방식은 비기술 사용자와 기술 사용자가 모두 접근하기 쉽지만, Markdown 자체가 이벤트 런타임의 필수 구성 요소는 아니다.

5.2. 구조화된 출력과 “나쁜 행동의 불가능성”

1. 실험이자 dogfooding

   1. 전문 분야: Text는 3년 동안 structured output을 전문적으로 다뤄왔다. 따라서 에이전트 런타임 구축은 자사 소프트웨어를 써보는 대규모 dogfooding 프로젝트가 됐다.
   2. 처음부터 제품을 밀어붙인 것은 아님: 반드시 자사 소프트웨어를 사용하거나 특정 소프트웨어를 포크하려고 시작한 것이 아니다. 사용 중인 모델·도구의 구조화된 출력이 충분히 나쁘다는 실용적 문제가 출발점이었다.

2. 20%의 이벤트 거부

   1. 관찰된 수치: 구조화된 출력이 제대로 나오지 않아 이벤트의 약 20%가 잘못된 형태로 생성됐고 시스템에서 거부됐다.
   2. 설계의 필요성: 자연어 모델의 응답을 그대로 신뢰하는 대신, 이벤트가 시스템 경계를 통과하기 전에 타입으로 검증해야 했다.

3. 커널의 목표

   1. 확률이 아닌 불가능성: “커널의 일은 나쁜 행동이 일어날 가능성을 낮추는 것이 아니라, 나쁜 행동을 불가능하게 만드는 것이다(The job of the kernel is to make bad actions impossible, not just unlikely).”
   2. 두 개의 경계: 에이전트와 외부 세계 사이에는 타입이 있는 도구 호출(typed tool calls) 경계가 있고, 에이전트와 다른 에이전트 사이에는 타입이 있는 이벤트(typed events) 경계가 있다.
   3. 도구 호출 검증: 존재하지 않는 도구를 호출하지 않도록 도구의 이름과 입력 형식을 타입으로 제한한다.
   4. 에이전트 간 이벤트 검증: 한 에이전트가 다른 에이전트에게 보내는 이벤트의 형태를 양보할 수 없는 계약으로 둔다. 실제 오류 중 상당수가 이 경계에서 생겼기 때문이다.

6. 한 달 뒤 회사에 배포한 결과

실험용 런타임은 개인 자동화에 머물지 않고 Text의 내부 업무와 외부 게시물 생성에 사용됐다.

6.1. 28개 에이전트의 운영

1. 배포 규모

   1. 수치: 구축 후 회사에 배포한 지 한 달이 지난 시점에 28개의 에이전트가 운영됐다.
   2. 작성자 범위: 기술 전문가뿐 아니라 일반 구성원도 Markdown 파일을 작성해 에이전트를 추가할 수 있었다. 코드가 아닌 선언형 파일이 참여 장벽을 낮췄다.

2. 내부와 외부의 결과

   1. 내부 업무: 아침 브리핑과 여러 업무 자료가 생성됐다. 시장 정보, 음성 메모, 개인의 무작위 생각이 매일 처리되어 받은 편지함에 도착했다.
   2. 인터넷 배포: 오른쪽 영역에는 인터넷에 배포되는 브리핑과 여러 산출물이 놓였다. 에이전트가 단순한 개인 비서가 아니라 게시 파이프라인의 일부가 됐다.

6.2. 로봇 잔디깎이 같은 백그라운드 에이전트

1. 마법처럼 느껴지는 순간

   1. 무인성: 잘 실행된 백그라운드 에이전트는 로봇 잔디깎이와 같다. 사용자가 계속 원격 조종하지 않아도 일하고, 나중에 결과가 나타난다.
   2. 품질과 지속성: 매일 받은 편지함에 도착하는 아침 브리핑은 직접 수동으로 조사했을 때보다 나을 때도 있다. 산책 중 떠오른 무작위 생각도 자동으로 처리된다.

2. 마법의 정체

   1. 오래된 공학 문제: 운영 과정의 어려움은 새로운 AI 특유의 문제가 아니라 큐, 재시도, 로그, 스케줄링, 타입 검증 같은 전통적인 소프트웨어 오케스트레이션 문제다.
   2. 시스템 신뢰성의 원천: 모델이 항상 완벽해서가 아니라, 실패를 관찰하고 재현하며 경계에서 거부할 수 있기 때문에 백그라운드 작업이 신뢰할 만해진다.

7. 결론: 직접 만들어 보고, 회사의 방향을 바꿔라

구매 가능한 프레임워크를 선택하기 전에 실제 업무의 병목과 실패 모드를 직접 확인해야 한다.

7.1. 오픈 소스 모델과 “build before buy”

1. 모델 선택

   1. 오픈 소스 모델의 충분함: 현재는 모든 타사 API를 교체해 오픈 소스 모델만 사용한다. 노트북에서 실행하는 로컬 모델도 Rémi Louf의 업무에는 충분하다.
   2. 범위의 한계: 코딩에 같은 수준으로 충분한지는 모르지만, 본인이 구축한 업무 자동화에는 충분하다고 평가한다.

2. 구매 전 직접 구축

   1. 카테고리의 미성숙: 에이전트 인프라 카테고리는 아직 정립되지 않았다. 시판 제품을 먼저 고르면 실제 필요와 기존 시스템의 한계를 모른 채 추상화에 맞춰질 수 있다.
   2. 소규모 회사의 이점: 소규모 회사나 기술 CEO라면 엔지니어를 본업에서 떼어내지 않고도 직접 작은 프로토타입을 만들 수 있다. 먼저 build하고, 무엇이 필요한지 안 뒤 buy하라는 조언이다.

7.2. 프레임워크 제작자와 사용자에게 보내는 당부

1. 프레임워크는 직접 운영하라

   1. dogfooding 요청: 에이전트 오케스트레이션 프레임워크를 만드는 사람은 자신이 만든 프레임워크로 실제 업무를 운영해야 한다. 설계 문서와 데모만으로는 중복, 유실, 프롬프트 회귀, 비용 급증을 발견하기 어렵다.
   2. 사용 경험의 검증: 만든 도구가 실제 백그라운드 작업을 끝내고, 결과를 감사하고, 실패를 재현할 수 있는지 직접 확인해야 한다.

2. 개인의 몰입이 전략을 바꾼다

   1. 2주 휴가의 효과: 사업은 언제나 다음 할 일만 생각하게 만든다. AI 회사라는 이유만으로 AI를 깊이 써보는 시간을 자동으로 확보할 수는 없다.
   2. 실천 요청: 업무를 잠시 멈추고 이 분야에 몰입해, 자신의 회사에서 얼마나 유용한지 직접 확인하라는 당부다. Rémi Louf에게 2주 실험은 Text의 방향을 완전히 바꿨다.

7.3. 공개 가능한 출발점

1. 코드와 글
   1. 재사용: 구축한 코드는 판매하는 제품이 아니며 판매할 의향도 없다. 필요한 사람은 저장소의 코드를 살펴보고 가져다 쓸 수 있다.
   2. 추가 자료: 관련 블로그를 읽을 수 있으며, 아직 설명하지 않은 부분도 곧 게시할 예정이라고 밝혔다. 구조화된 출력과 타입 경계를 더 깊게 다룬 긴 글은 발표 화면의 QR 코드로 접근할 수 있다.

주요 발언 모음

“이 일이 정말 일어나고 있다(This thing is really happening).”

“분위기를 입힌 SSH(SSH with vibes)다.”

“이 경우 그래프는 필요하지 않다. 필요한 것은 이벤트뿐이다(You do not need graphs. In this case all you need is events).”

“로그는 시스템의 기억이다(The log is the system’s memory). 아무것도 잃지 않고 모든 것을 관찰한다.”

“문자열을 조작하는 게 아니라 그래프를 조작하는 것이다. 훨씬 쉽다.”

“커널의 일은 나쁜 행동이 일어날 가능성을 낮추는 것이 아니라, 나쁜 행동을 불가능하게 만드는 것이다(The job of the kernel is to make bad actions impossible, not just unlikely).”

“구매하기 전에 먼저 만들어 보라(Start building before you buy).”

“자신이 만든 프레임워크를 직접 사용해 보라. Eat your own dog food.”

“잘 실행된 백그라운드 에이전트는 정말 마법 같다(Well-executed background agents are really magical).”

핵심 데이터 & 수치

• 2025년 12월: 에이전트 능력이 단계적으로 좋아졌다고 체감한 시점.
• Opus 4.6: 급격한 변화를 체감하게 만든 모델 버전으로 추정.
• 2주: Rémi Louf가 Text의 CEO 업무에서 벗어나 직접 에이전트를 연구한 기간.
• 15명: Text의 회사 규모.
• 첫 구현 약 하루: Codex를 활용해 첫 작동 버전을 만든 데 걸린 시간.
• 20%: 구조화된 출력 오류로 시스템이 거부한 이벤트의 비율.
• 28개: 배포 한 달 뒤 Text에서 운영된 에이전트 수.
• 20분: 전체 길이.

결론 및 실용적 시사점

1. 에이전트 자동화의 최소 단위는 거대한 그래프가 아니라 이벤트를 받아 이벤트를 내보내는 프로세스다.
2. 정기 작업은 cron으로, 외부에서 발생한 사건은 typed event로 표현해 두 모델을 함께 사용한다.
3. 에이전트 정의를 파일로 분리하면 버전 관리, diff, PR 리뷰, 비기술 구성원의 참여가 가능해진다.
4. 유실을 막으려면 append-only 로그를 시스템의 기억으로 삼고, 이벤트의 인과 관계와 모든 실행 결과를 조회 가능하게 보존해야 한다.
5. 모델에 실제 전달된 프롬프트를 해시로 주소 지정하면 컨텍스트를 감사하고, 실행 간 diff를 만들며, 과거 요청을 replay할 수 있다.
6. 타입이 있는 도구 호출과 타입이 있는 이벤트를 경계로 두어 존재하지 않는 도구 호출과 잘못된 에이전트 간 메시지를 시스템 차원에서 거부해야 한다.
7. 오픈 소스·로컬 모델은 특정 업무에 충분할 수 있으므로, 제품을 구매하기 전에 작게 직접 만들어 실제 필요와 한계를 파악해야 한다.
8. 프레임워크의 가치는 데모가 아니라 제작자가 실제로 자신의 업무를 맡겨 중복·유실·회귀·비용 문제를 발견하고 해결했는지로 검증해야 한다.