에이전트 프레임워크는 왜 해로울 수 있는가 — Rémi Louf, .txt

URL: https://www.youtube.com/watch?v=KHudyx5wW3U
날짜: 2026-08-22
처리일: 2026-08-23
채널: aiDotEngineer
발표자: Rémi Louf, .txt
길이: 20분 28초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트 애플리케이션을 거대한 그래프형 프레임워크의 추상화 안에 가두기보다, 이벤트·로그·타입·콘텐츠 주소 지정(content addressing)을 제공하는 작은 런타임 위에 선언적으로 쌓는 편이 더 단순하고 감사 가능하며 실제 자동화에 가깝지 않은가?==

• 잘 실행되는 백그라운드 에이전트는 사람이 리모컨으로 계속 조종하지 않아도 되는 로봇 잔디깎이처럼 작동해야 한다.
• 에이전트 사이의 연결은 코드로 유지하는 그래프보다 타입이 있는 이벤트의 발행·구독으로 표현할 수 있다.
• append-only 이벤트 로그, 인과 연결, 프롬프트 구성요소의 해시 주소 지정은 실패 원인·모델 컨텍스트·비용을 추적하고 과거 실행을 재현하게 한다.
• 런타임의 커널은 존재하지 않는 도구 호출이나 잘못된 에이전트 간 메시지를 단순히 드물게 만드는 것이 아니라 불가능하게 만들어야 한다.

Rémi Louf는 AI 회사 .txt의 CEO로서 15명 규모 팀의 아침 업무를 자동화하려고 2주 동안 직접 에이전트를 만들었다. 처음에는 프레임워크와 크론 작업으로 시작했지만, 중복 실행·유실·재시도·프롬프트 변경 추적 실패를 차례로 겪으면서 이벤트 런타임을 만들게 됐다. 이 작업의 결론은 에이전트 프레임워크를 더 많이 도입하라는 것이 아니라, 필요한 원시 기능을 먼저 직접 만들어 보고 그 위에서 정말 필요한 제품을 판단하라는 것이다.

1. 리모컨 없는 아침을 만들려는 실험

에이전트의 진짜 가치는 채팅창에서 사람의 주의를 계속 요구하는 데 있지 않고, 사람이 자리를 비운 동안 정해진 일을 수행한 뒤 결과를 전달하는 데 있다.

1.1. 에이전트가 충분히 좋아졌다고 느낀 순간

1. 2025년 12월 무렵의 질적 도약

   1. 에이전트의 단계적 향상: 12월 무렵 에이전트 품질이 갑자기 좋아지는 step function 같은 변화가 일어났고, 발표자는 이를 Opus 4.6이 나온 시점과 연결해 기억한다.
   2. 직업적 위치에서 느낀 확신: AI 분야에서 일하던 발표자는 그때 “이 일이 정말 일어나고 있다”고 판단했다.

2. 2주간의 몰입

   1. 작은 회사의 CEO가 시간을 비우다: 15명 규모 AI 회사 .txt의 CEO인 발표자는 CTO에게 말하고 2주를 통째로 떼어 에이전트가 무엇을 할 수 있는지 파고들었다.
   2. 자기 문제를 직접 해결하기: 거창한 제품 전략이 아니라 자신의 가려운 곳을 긁는 실험이었다. 실제로 쓸 수 있는 에이전트와 좋은 원시 기능(primitives)이 무엇인지, 이미 쓸 만한 것이 존재하는지를 알아보려 했다.

1.2. 로봇 잔디깎이와 아침 브리핑

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

   1. 배경에서 계속 작동하는 기계: 발표자의 사무실은 성(castle)에 있고, 그 주변에는 리모컨으로 계속 조종하지 않아도 하루 종일 혼자 일하는 로봇 잔디깎이가 있다.
   2. 원하는 자동화의 기준: 발표자는 아침에도 같은 방식으로 사람이 신경 쓰지 않아도 돌아가는 시스템을 원했다.

2. 반복되는 아침의 구성

   1. 정보 수집: 시장 뉴스와 업무 뉴스를 훑고, Linear 또는 Jira를 검토하며, CRM을 확인한다.
   2. 걷기와 음성 메모: 약 한 시간 아침 산책을 하며 긴 음성 메모를 녹음하고, 다음 한 시간 동안 걸으면서 남긴 생각을 처리한다.
   3. 최종 결과: 커피를 마실 때 아침 브리핑이 이미 도착해 있기를 바랐다. 이것이 몇 년 동안 “미래”라고 들어 온 모습이었다.

2. 채팅형 에이전트와 리모컨의 한계

현재의 에이전트는 놀라울 정도로 많은 일을 하지만, 사용자가 계속 화면을 지켜보며 방향을 바꿔 줘야 한다는 점에서 완전한 자동화와는 거리가 있다.

2.1. TUI라는 중간 단계

1. 코딩을 넘어선 에이전트

   1. 비개발 작업에도 유용함: 발표자는 코딩이 아닌 일을 에이전트에 시키기 시작했고, 에이전트가 이런 작업에도 매우 훌륭하다는 점을 인정한다.
   2. 하지만 인터페이스는 TUI: 코딩을 하지 않아도 사용자가 실제로 얻는 것은 오늘날 터미널 사용자 인터페이스(TUI)다.

2. 트랙터형 로봇의 비유

   1. 자율 주행하지만 계속 타고 있어야 함: 스스로 움직이는 트랙터형 잔디깎이가 있어도 사람이 계속 올라타 있어야 한다면 자동화의 감각이 사라진다.
   2. 주의력의 지속적인 점유: 에이전트가 여러 일을 해도 사용자는 계속 켜 두고 지켜봐야 한다. 발표자는 이 상태를 매우 답답한 중간 단계로 본다.

2.2. 모바일 앱은 ‘vibes가 얹힌 SSH’

1. 앱으로 확장된 에이전트

   1. 실험실의 다음 단계: AI 연구소들은 터미널을 벗어난 앱을 내놓았다. 발표자는 이를 “기본적으로 vibes가 얹힌 SSH(SSH with vibes)”라고 부른다.
   2. 긍정적인 변화: 휴대폰에서 더 이상 직접 SSH를 사용할 필요가 없다는 점에서 Codex 같은 앱은 훌륭하다.

2. 산책 중 휴대폰 조종

   1. 새로운 습관: 발표자는 산책하면서 휴대폰으로 에이전트에 일을 지시하고, 아침 산책 중 여러 에이전트를 실행하기 시작했다.
   2. 리모컨 비유의 반복: 에이전트가 옆에 서 있는 사람 없이도 일을 하기는 하지만, 사용자가 중간중간 궤도를 바꾸는 리모컨을 들고 있어야 한다. 사람들의 시선이 늘 휴대폰에 붙어 있는 모습도 이런 과도기적 상황의 부조리함을 보여 준다.

3. 코드보다 선언적 파일과 이벤트

발표자는 프레임워크의 내부 코드를 계속 편집하는 대신, 에이전트의 정의를 파일로 선언하고 런타임이 이벤트에 따라 실행하도록 만드는 방향으로 이동했다.

3.1. ‘가장 멍청하게 작동하는 것’부터 시작하기

1. 보드에게 들키고 싶지 않은 코딩

   1. 첫 구현: 회사 CEO로서는 다소 엉뚱하게, 보드에는 말하지 말아 달라는 농담과 함께 가장 멍청하면서도 작동할 수 있는 것을 코딩하기 시작했다.
   2. 토끼굴(rabbit hole): 단순한 실험은 점점 더 깊은 토끼굴로 변했다. 코드는 완벽하지 않지만 실제로 작동하며, 발표자는 저장소(repo)를 공개해 사람들이 살펴볼 수 있다고 말한다.

2. 프레임워크를 쓰며 발견한 문제

   1. 프레임워크 자체를 공격하지 않음: 특정 프레임워크의 이름을 거론하지 않는다. 각각의 프레임워크는 자기 방식의 장점과 결함이 있고, 그것은 괜찮다고 전제한다.
   2. 프롬프트 편집에 매몰됨: 실제 시간 대부분을 코드 안의 프롬프트를 수정하는 데 쓰고 있다는 사실을 깨달았다. 이것이 “프레임워크가 유용하지 않다”는 첫 신호였다.

3.2. 마크다운은 작은 선언적 인터페이스다

1. YAML을 싫어해도 선언적 파일을 선택함

   1. 버전 관리의 이점: 발표자는 다른 사람들처럼 YAML을 싫어한다고 농담하지만, 코드 없이 에이전트를 구현하는 방식은 버전 관리·diff·PR 리뷰가 쉽다.
   2. 낮은 진입장벽: 파일을 작성해 폴더에 넣기만 하면 런타임이 이를 발견하고 에이전트로 동작시킨다. 코드 작성보다 훨씬 단순한 인터페이스다.

2. 스케줄과 이벤트의 출발점

   1. 크론 작업: 아침 산책 중 시장 감시 작업을 돌리기 위해 기존에 널리 쓰이는 크론 작업(cron job)을 사용했다. 크론은 에이전트를 언제 실행할지를 지정한다.
   2. 이벤트 발행: 크론은 실행 결과를 이벤트로 발행한다. 마크다운과 크론은 내부 구현보다 “코드를 작성하지 않는다”는 외부 인터페이스가 핵심이다.

4. 크론에서 이벤트 기반 런타임으로

시간을 정하는 크론만으로는 시스템 안에서 실제로 발생한 사건에 반응할 수 없으므로, 에이전트는 입력 이벤트를 받고 출력 이벤트를 내보내는 프로세스가 되어야 한다.

4.1. ‘언제’와 ‘무슨 일이 일어났는가’의 차이

1. 크론의 한계

   1. 한 시점만 표현함: 크론 작업은 “언제 실행할지”는 표현하지만, 특정 사건이 발생했기 때문에 실행해야 한다는 의미는 표현하지 못한다.
   2. 산책 중 음성 메모와 맞지 않음: 발표자는 걸으면서 음성 메모를 남기므로, 일정 시각에 도는 작업보다 음성 메모가 시스템에 들어오는 순간을 감지하는 방식이 자연스럽다.

2. 사건에 따른 반응

   1. 음성 메모: 음성 메모가 시스템에 추가되면 이벤트가 발행되고, 이를 구독하는 에이전트가 반응한다.
   2. 업무 시스템의 변화: 새 이메일, CRM의 새 항목, 새로 열린 PR, 병합된 PR도 모두 이벤트다. 시스템은 시간표만 따라가는 것이 아니라 실제 변화를 따라간다.

4.2. 입출력 계약으로 연결되는 에이전트

1. 음성 메모 처리 에이전트

   1. 입력 계약: 에이전트는 음성 메모 이벤트를 받는다.
   2. 처리와 출력: 음성 메모를 전사하고, 장기 보존 가능한(durable) 노트로 바꾼 뒤 voice_note_processed 같은 새 이벤트를 발행한다.
   3. 구조화된 출력: 다음 에이전트가 안정적으로 소비할 수 있도록 structured output을 사용한다.

2. 매일의 브리핑 파이프라인

   1. 여러 결과의 결합: 시장 감시 크론 작업의 출력과 음성 메모 처리 에이전트의 출력이 daily brief 에이전트로 들어간다.
   2. Slack 전달: daily brief 에이전트는 결과를 매일의 브리핑으로 만들고, Slack 메시지를 게시하는 프로세스가 slack.message.post 이벤트를 구독해 발표자에게 보낸다.
   3. 실제 작동: 이 구조는 발표자의 실제 시스템에서 작동한다. 발표자는 휴대폰으로 그 결과를 보여 줄 수 있다고 말한다.

4.3. 그래프 대신 이벤트 토폴로지

1. 그래프가 필수라는 주장에 대한 반론

   1. 유지해야 할 간선이 없음: 코드 안에서 에이전트 그래프의 모든 엣지를 유지할 필요 없이, 이벤트만 있으면 된다.
   2. 구독으로 연결: 에이전트는 이벤트를 구독하고, 필요한 이벤트를 받아 새로운 이벤트를 발행한다.

2. 코드 없이 나타나는 구조

   1. 비개발자도 참여 가능: 시스템에 어떤 이벤트가 존재하는지만 알면 에이전트를 추가하거나 편집할 수 있다.
   2. fan-in과 fan-out: 여러 입력을 모으는 fan-in과 한 이벤트를 여러 소비자에게 보내는 fan-out이 별도 코드 없이 가능하다.
   3. 로그에서 토폴로지 출현: 파일을 하나 추가하면 시스템 로그에 기록된 실제 사건의 흐름을 따라 토폴로지가 자연스럽게 드러난다.

5. 실패가 런타임의 부품이 되다

첫 구현은 하루 만에 만들어졌지만, 실패를 관찰하고 그 원인을 다시 추적하려는 과정이 로그·큐·재시도·콘텐츠 주소 지정 시스템을 만들게 했다.

5.1. 첫 주의 실제 실패

1. 빠른 첫 구현

   1. 개발 속도: 발표자는 Codex의 도움을 받아 첫 번째 것을 일주일 중 하루 정도에 작성했다.
   2. 곧바로 고장: 실제로 실행하자 시스템은 금방 깨졌다. 발표자는 사례와 날짜가 화면에 있었지만, 모두 실제로 겪은 사건이라고 강조한다.

2. 세 가지 운영 문제

   1. 중복 브리핑: 첫날 daily brief가 Slack에 두 번 게시됐다.
   2. 유실: 수요일에는 음성 메모 하나가 완전히 사라졌다.
   3. 품질 하락과 변경 추적 실패: 주 후반 시장 브리핑은 엉망이 됐다. 일주일 내내 프롬프트를 만졌지만 버전 관리하지 않았고, 무엇을 바꿔서 결과가 쓸모없어졌는지 기억할 수 없었다.

5.2. 분산 시스템의 오래된 문제

1. 새로운 마법이 아닌 엔지니어링 목록

   1. 익숙한 실패 모드: 분산 시스템 엔지니어라면 이 문제 목록이 이미 익숙하다. 에이전트라는 이름이 붙었을 뿐, 세상에 완전히 새로운 문제는 아니다.
   2. 실패가 설계를 이끎: 각 실패 모드가 런타임의 한 부품을 만드는 직접적인 계기가 됐다.

2. 실패별 대응

   1. 유실된 노트 → 로그: 무엇이든 영원히 보존해 나중에 무슨 일이 있었는지 확인할 수 있도록 로그를 만들었다.
   2. 중복 → 큐와 재시도 관리: 여러 번 시도한 작업이 제대로 추적되지 않았고, 적절한 큐와 시도 횟수 카운터가 없었다. 재시도와 중복 처리는 명시적인 런타임 기능이 됐다.
   3. 나쁜 프롬프트 → 콘텐츠 주소 지정: 마지막 프롬프트 문제를 파고들다가 Git이나 Nix 같은 빌드 시스템처럼 구성요소를 내용(content)의 해시로 주소 지정하는 시스템을 만들었다.

6. 로그는 시스템의 기억이다

append-only 로그와 인과 관계는 에이전트가 무엇을 했는지뿐 아니라 어떤 사건이 어떤 사건을 유발했는지까지 보존해 디버깅 가능한 시스템을 만든다.

6.1. 관찰 가능하고 사라지지 않는 사건

1. append-only 이벤트 테이블

   1. 시스템의 기억: 로그는 시스템의 memory다. 아무것도 잃지 않고 모든 것을 관찰한다.
   2. 단일 공통 테이블: 왼쪽에는 하나의 append-only 이벤트 테이블이 있고, 모든 이벤트가 여기에 기록된다.

2. 인과 연결과 질의

   1. 원인 추적: 어떤 이벤트가 어떤 이벤트를 트리거했는지가 인과적으로 연결된다.
   2. 에이전트가 적어도 필요한 기능: 에이전트가 세네 개만 있어도 디버깅은 큰 골칫거리가 된다. 인과 연결은 어떤 실행이 왜 생겼는지 찾는 데 특히 유용하다.
   3. 쿼리 가능성: 모든 이벤트를 질의할 수 있어 과거 실행과 실패를 다시 조사할 수 있다.

7. 모델이 실제로 본 컨텍스트를 복원하기

채팅 UI에 보이는 대화는 모델에 전달된 실제 요청과 다를 수 있으므로, 관찰 가능성은 이벤트 로그를 넘어 프롬프트 구성 그래프까지 추적해야 완성된다.

7.1. 라이브 채팅 화면은 불완전한 증거다

1. 사용자가 보는 것과 모델이 본 것의 차이

   1. UI의 착시: Codex 같은 도구에서 보는 것은 라이브 채팅 세션처럼 보인다. 사용자는 그 화면이 모델이 본 전부라고 생각하기 쉽다.
   2. 실제 요청의 불확실성: 모델에 어떤 프롬프트가 전송됐는지, 대화가 어떤 형태로 압축됐는지 화면만으로 정확히 알 수 없다.

2. 차이를 만드는 요인

   1. 컨텍스트 압축(compaction): 긴 세션을 줄이는 과정에서 원래 화면과 모델 입력이 달라질 수 있다.
   2. 숨겨진 추론: OpenAI와 Anthropic 모두 thinking trace를 전부 공유하지 않으므로 모델 내부에서 무엇이 일어났는지 완전히 알 수 없다.
   3. 필요한 대안: 모델이 실제로 본 것을 내부적으로 재구성할 수 있는 별도의 시스템이 필요하다.

7.2. 프롬프트를 해시로 구성하는 빌드 시스템

1. 프롬프트의 구성요소

   1. 시스템 프롬프트: 에이전트 전체의 기본 지침이다.
   2. 스킬 설명: 첫 번째 스킬, 두 번째 스킬 등 각각의 설명이 독립된 구성요소다.
   3. 도구 설명: 모델이 사용할 수 있는 도구의 정의도 별도 구성요소다.
   4. 사용자 메시지: 모델에 던지는 실제 질문이나 작업 지시다.

2. 콘텐츠 주소 지정(content addressing)

   1. 해시 식별자: 각 구성요소를 저장하고 내용에서 계산한 hash를 식별자로 사용한다.
   2. 문자열 대신 해시 목록: 프롬프트를 바로 긴 문자열로 조립하기 전에 구성요소 해시의 목록으로 표현한다.
   3. 응답도 같은 방식으로 보존: 모델의 답변 역시 같은 시스템에 저장한다.

3. 정확한 컨텍스트 복원

   1. 역추적: 모델 답변에서 프롬프트로, 프롬프트에서 그 안에 들어간 모든 구성요소로 쉽게 거슬러 올라갈 수 있다.
   2. 디버깅과 감사 가능성: 어떤 도구·스킬·메시지가 모델에 들어갔는지 정확히 알 수 있어 에이전트가 왜 그 결과를 냈는지 설명할 수 있다.
   3. compaction과 KV 캐시: 문자열을 직접 잘라 붙이는 대신 그래프를 조작하므로 컨텍스트 압축이 쉬워지고, 간접적으로 KV cache 관리도 쉬워진다.

7.3. diff와 replay가 주는 공짜 기능

1. 실행 간 diff

   1. 변경점 확인: 두 실행 사이에 무엇이 달라졌는지 비교할 수 있다.
   2. 구성요소 단위 비교: 사용자 메시지만 바뀌었는지, 스킬이나 도구가 바뀌었는지 확인할 수 있다.
   3. 세션의 연속성: 화면에 보인 여러 메시지 가운데 일부는 실제로 같은 세션의 continuation이며, 어떤 구성요소가 동일한지 diff로 드러난다.

2. replay와 평가

   1. 비용 급증의 발견: 관찰 가능성을 확보하면 비용이 빠르게 증가한다는 사실도 곧바로 보인다.
   2. 오픈소스 모델 실험: 발표자는 오래된 요청을 다시 만들어 오픈소스 모델로 평가하고, 같은 결과가 나오는지 또는 만족스러운 결과인지 확인하려 했다.
   3. 동일 요청의 재전송: 콘텐츠 주소 지정 그래프가 있으면 과거 요청을 정확히 재구성해 그대로 replay할 수 있다.
   4. 모델 교체: 같은 요청을 다른 모델에 보내거나 요청 자체를 바꿔 보면서 결과를 비교할 수 있다. 이 기능들은 모두 콘텐츠 주소 지정 시스템을 구현한 결과로 따라왔다.

8. 프레임워크 위가 아니라 런타임 커널 위에서

프레임워크는 에이전트를 자기 추상화 안에 배치하지만, 런타임은 에이전트를 격리·스케줄링·기록하는 커널로 보고 선언 파일은 사용자 영역(userland)으로 남겨야 한다.

8.1. 라이브러리와 에이전트의 추상화

1. 프레임워크의 현재 모습

   1. 코드를 호출하는 라이브러리: 발표자가 조사했을 때 대부분의 도구는 라이브러리이자 프레임워크였고, 코드 호출을 중심으로 구성돼 있었다.
   2. 추상화 안의 에이전트: 에이전트는 프레임워크가 만든 추상화 안에 들어가며, 그 바깥에서 실행·감사·격리하기 어렵다.

2. 운영체제 커널 비유

   1. 에이전트는 프로세스: 운영체제 비유를 지나치게 좋아하지는 않지만, 커널이 프로세스를 실행한다는 정도의 비교는 유용하다. 에이전트가 무슨 일을 하는지는 커널의 관심사가 아니다.
   2. 커널의 책임: 런타임은 에이전트를 스케줄하고, 격리하고, 로그와 에이전트 정의를 함께 저널링한다.
   3. 마크다운은 userland: 마크다운 에이전트 정의는 사용자 영역에 해당한다. 런타임은 마크다운을 사용하지 않는 프런트엔드도 지원할 수 있으므로 마크다운은 시스템의 필수 내부 형식이 아니다.

8.2. 커널의 목적은 나쁜 행동을 불가능하게 하는 것

1. 발표자의 전문성과 dogfooding

   1. structured outputs 경험: 발표자의 회사는 구조화된 출력(structured outputs)을 전문으로 하며 3년 동안 이 분야를 다뤄 왔다.
   2. 자기 제품을 먹는 실험: 이 런타임은 자기 회사 소프트웨어를 실제로 사용해 보는 dogfooding 프로젝트가 됐다. 처음부터 자사 소프트웨어를 억지로 끼워 넣으려던 것은 아니었다.

2. 구조화된 출력이 만든 문제

   1. Anthropic의 초기 품질 문제: 당시 Anthropic의 structured outputs가 좋지 않아 이벤트의 약 20%가 잘못된 형식으로 생성되고 시스템에서 거부됐다.
   2. 도입 동기: 발표자가 이 기능을 만든 이유는 제품을 팔기 위해서가 아니라, 잘못된 이벤트가 시스템을 통과하는 문제를 해결하기 위해서였다.

3. 두 개의 안전 경계

   1. 도구 호출 경계: 에이전트가 존재하지 않는 도구를 호출하거나 도구의 형식을 어기는 일이 없도록 typed tool calls로 외부 세계와의 경계를 강제한다.
   2. 에이전트 간 경계: 에이전트 사이에는 typed events만 오가도록 한다. 이벤트 계약은 선택 사항이 아니라 non-negotiable이다.
   3. 핵심 원칙: 커널의 역할은 잘못된 행동을 단지 일어날 가능성이 낮게 만드는 것이 아니라, 애초에 불가능하게 만드는 것이다.

8.3. 실제 배포 결과

1. 회사 안에서의 확장

   1. 한 달 후의 상태: 런타임을 만든 뒤 회사에 배포했고, 한 달 동안 운영한 시점에 20개의 에이전트가 배치돼 있었다.
   2. 기술팀 밖의 기여: 이 에이전트들은 기술 담당자만 만든 것이 아니다. 마크다운 같은 선언적 인터페이스 덕분에 비개발자도 기여할 수 있었다.

2. 운영되는 애플리케이션

   1. 브리핑과 업무 흐름: 시장 감시, 음성 메모 처리, daily brief 같은 실제 업무가 런타임 위에서 돌아간다.
   2. ‘인터넷’으로 불리는 배포: 슬라이드 오른쪽에는 배포된 시스템이 “the internet”으로 표시돼 있었고, 브리핑을 비롯한 여러 실제 기능이 운영되고 있었다.

주요 발언 모음

“The log is the system's memory.” — 로그는 시스템의 기억이다.

“The job of the kernel is actually to make bad actions impossible, not just unlikely.” — 커널의 일은 나쁜 행동을 단지 드물게 만드는 것이 아니라 불가능하게 만드는 것이다.

“Fun and fan out are free. No code and it's just—drop a file and the topology emerges.” — fan-in과 fan-out은 공짜다. 코드를 쓰지 않고 파일 하나를 놓으면 토폴로지가 나타난다.

“What you see when you're using Codex is kind of a lie.” — Codex를 사용할 때 보이는 것은 일종의 거짓말이다.

“Please eat your own dog food.” — 이 분야의 프레임워크를 만드는 사람들은 자기 제품을 직접 사용해 보라.

핵심 데이터 & 수치

• 약 2025년 12월: 발표자가 에이전트 품질의 급격한 도약을 체감한 시점이며 Opus 4.6을 언급했다.
• 2주: 15명 규모 회사의 CEO인 Rémi Louf가 회사 업무를 떠나 에이전트를 직접 실험한 기간이다.
• 약 1시간: 아침 산책과 음성 메모 녹음에 사용되는 시간이다.
• 약 1일: Codex의 도움을 받아 첫 번째 런타임을 작성하는 데 든 시간이다.
• 20%: 발표자가 경험한 초기 structured outputs 이벤트 오류·거부 비율이다.
• 20개 에이전트: 회사에 런타임을 배포하고 약 한 달 뒤 운영 중이던 에이전트 수다.
• 20분 28초: 원본 영상 길이다.
• 2026-08-22: YouTube 메타데이터에서 확인한 실제 업로드 날짜다.

결론 및 시사점

1. 백그라운드 에이전트의 기준을 높여라: 잘 만든 에이전트는 사람이 계속 조종하는 채팅 상대가 아니라, 로봇 잔디깎이처럼 자율적으로 실행되고 받은 편지함에 더 나은 아침 브리핑을 남겨야 한다.
2. 문제의 본질은 새롭지 않다: 에이전트 오케스트레이션의 실패는 중복, 유실, 재시도, 버전 관리, 관찰 가능성이라는 오래된 소프트웨어·분산 시스템 문제다.
3. 그래프보다 이벤트를 먼저 검토하라: 에이전트의 연결을 수동으로 유지하는 그래프 대신 typed event의 발행·구독으로 fan-in과 fan-out을 표현하면 선언적이고 확장 가능한 토폴로지가 된다.
4. 로그와 콘텐츠 주소 지정은 기반 기능이다: append-only 로그는 실행의 기억을 남기고, 해시로 주소 지정된 프롬프트 그래프는 실제 모델 컨텍스트의 추적·diff·replay·모델 교체를 가능하게 한다.
5. 커널 경계는 선택 사항이 아니다: typed tool calls와 typed events로 외부 세계와 에이전트 사이를 방어하고, 잘못된 행동을 “가능하지만 드문 것”이 아니라 “불가능한 것”으로 만들어야 한다.
6. 구매 전 직접 만들어 보라: 인프라 카테고리는 아직 정착되지 않았으므로 작은 회사나 기술 CEO라면 먼저 작은 시스템을 직접 만들고, 실제 필요와 기존 제품의 한계를 파악한 뒤 구매하는 편이 낫다.
7. 프레임워크 제작자는 dogfood하라: 자기 업무에서 직접 사용하지 않는 오케스트레이션 프레임워크는 현실의 중복·유실·비용·재현성 문제를 놓칠 수 있다.
8. 현장 몰입이 전략을 바꾼다: 2주 동안 직접 실험한 일은 .txt의 회사 방향을 바꿨다. 다음 전략만 계속 생각하기보다 실제 업무에 에이전트를 깊이 적용해 볼 필요가 있다.
9. 오픈소스 모델은 충분할 수 있다: 발표자의 업무에서는 오픈소스 모델과 노트북의 로컬 모델도 충분했고, 3rd-party API를 더 이상 사용하지 않게 됐다. 코딩처럼 더 높은 품질이 필요한 영역에서는 별도 검증이 필요하다.
10. 공개된 결과를 재료로 삼아라: 런타임은 판매할 제품이 아니며 코드를 가져가도 되고, 관련 블로그 글도 공개할 예정이라는 것이 발표자의 마지막 제안이다.

핵심 요약 (20줄)

Rémi Louf는 에이전트 품질이 급상승한 뒤 15명 규모 회사의 업무를 직접 자동화하려고 2주간 몰입했다. 아침 브리핑은 시장 뉴스·Linear 또는 Jira·CRM·산책 중 음성 메모를 한데 모으는 실제 문제에서 출발했다. 로봇 잔디깎이는 사람이 리모컨으로 계속 조종하지 않아도 배경에서 일을 끝내는 자동화의 기준이 됐다. 현재의 TUI와 모바일 앱은 에이전트가 일하는 동안에도 사용자가 계속 방향을 바꿔야 하는 과도기적 리모컨에 가깝다. 가장 멍청하게 작동하는 구현은 Codex의 도움으로 약 하루 만에 작성됐지만 곧 운영 실패를 드러냈다. 크론 작업은 실행 시각을 정할 뿐 음성 메모·이메일·PR 같은 실제 사건에 반응하지 못한다. 이벤트 기반 런타임은 에이전트가 typed event를 받고 처리 결과를 새 이벤트로 발행하게 만든다. 음성 메모 처리 에이전트는 전사와 durable note 생성을 마친 뒤 voice_note_processed 이벤트를 내보낸다. Daily brief 에이전트는 시장 감시와 음성 메모 결과를 결합해 Slack 메시지로 전달한다. 이벤트 발행·구독은 유지해야 할 그래프 간선 없이 fan-in과 fan-out을 선언적으로 제공한다. 중복 브리핑·유실된 음성 메모·엉망이 된 프롬프트는 런타임의 설계를 이끈 구체적인 실패였다. Append-only 로그는 모든 사건을 보존하고 어떤 이벤트가 무엇을 트리거했는지 인과 관계를 남긴다. 채팅 화면은 compaction과 공개되지 않은 thinking trace 때문에 모델이 실제로 본 컨텍스트를 완전히 보여 주지 않는다. 콘텐츠 주소 지정은 시스템 프롬프트·스킬·도구·사용자 메시지를 해시로 저장해 요청을 그래프로 표현한다. 프롬프트 그래프는 정확한 컨텍스트 복원과 실행 간 diff를 가능하게 해 디버깅과 감사 가능성을 높인다. Replay는 과거 요청을 다시 구성해 오픈소스 모델이나 다른 모델로 평가할 수 있게 한다. 런타임 커널은 에이전트를 프로세스처럼 스케줄·격리·저널링하고 선언 파일은 userland로 남긴다. Typed tool calls와 typed events는 외부 도구와 에이전트 간 경계에서 나쁜 행동을 불가능하게 만드는 안전장치다. 약 20%의 구조화된 출력 오류는 발표자가 이 경계를 직접 구현하게 만든 실질적인 비용이었다. 한 달 뒤 20개 에이전트가 회사에서 운영됐고, 발표자는 프레임워크를 사기 전에 직접 만들고 반드시 dogfood하라고 권한다.

📁 Obsidian: /Users/flowkater/Obsidian/flowkater/flowkater/Study/YouTube다이제스트/2026-08-23-aiDotEngineer-Agent-Frameworks-Considered-Harmful.md