Agent Frameworks Considered Harmful — Rémi Louf, .txt

한 줄 핵심

에이전트 프레임워크보다 중요한 것은 로그·이벤트·타입으로 에이전트의 실행을 통제하는 런타임이며, 작은 팀일수록 먼저 직접 만들어 보며 필요한 구조를 확인해야 한다는 이야기다.

시간별 요약

1. 0:00
   2주 동안 에이전트가 무엇을 할 수 있는지 확인하기 에이전트가 급격히 좋아졌다고 느낀 시점에 2주를 떼어 직접 써 보며, 실제로 유용한 원시 프리미티브가 무엇인지 확인하려는 실험이 시작된다. 배경은 매일 반복되는 아침 업무를 로봇 잔디깎이처럼 자동으로 처리하는 시스템을 만들고 싶다는 문제의식이다.
2. 1:57
   원하던 아침과 로봇 잔디깎이 목표는 커피를 마시며 시장 뉴스, CRM, 긴 음성 메모를 자동으로 요약해 주는 아침 브리핑이다. 단순히 코딩만이 아니라 일상 업무도 처리할 수 있지만, 지금의 경험은 여전히 자율성보다 원격 조종에 더 가깝다.
3. 2:49
   아직도 붙잡고 있어야 하는 터미널 terminal이나 SSH 대신 사용할 수 있는 앱이 나와도, 사용자는 여전히 에이전트가 움직이는 동안 옆에서 방향을 계속 조정해야 한다. 이동 중에 휴대폰으로 에이전트를 돌리기 시작하면 편리함은 커지지만, 아직도 과도기적인 방식이라는 한계가 분명해진다.
4. 4:30
   프롬프트가 코드가 아니라 markdown에 들어간 이유 프레임워크 안에서 코드를 계속 고치는 대신 prompt를 파일로 분리해 버전 관리와 diff, PR 리뷰가 쉬운 markdown 형식으로 두는 편이 훨씬 실용적이다. 또한 cron jobs 같은 스케줄러를 써서 언제 실행할지 정하고, 파일을 넣기만 하면 런타임이 동작하는 단순한 인터페이스를 만든다.
5. 6:11
   Cron은 실행 시점을, events는 실행 이유를 잡아준다 cron job은 '언제'를 정하지만, 음성 메모 저장·새 이메일·새 PR처럼 시스템 안에서 벌어지는 사건에 반응하는 '왜'를 표현하지 못한다. 그래서 음성 메모 처리기와 일일 브리프 같은 구성요소는 이벤트를 구독하고, structured outputs를 통해 입력과 출력을 명확히 정의하는 방식으로 연결된다.
6. 8:44
   첫 주에 무엇이 깨졌는가 일일 브리프가 두 번 발송되고, 음성 메모가 사라지고, prompt 변경 이력이 남지 않아 결과가 망가지는 등 실제 장애가 곧바로 드러난다. 이 실패들은 단순한 버그가 아니라 로그, 큐, 재시도, 변경 이력 관리 같은 런타임 요소가 필요하다는 신호였다.
7. 9:37
   로그: 아무것도 잃지 않고 모든 것이 인과적으로 연결된다 append-only log를 시스템의 기억으로 두면 모든 이벤트가 저장되고, 무엇이 무엇을 유발했는지 인과 관계까지 추적할 수 있다. 또한 사용자가 본 chat 화면은 실제 모델 입력과 다를 수 있으므로, 내부에서 모델이 본 prompt 자체를 정확히 재구성할 수 있어야 디버깅이 가능해진다.
8. 12:11
   prompt를 content addressing하고, diff와 replay를 공짜로 얻기 system prompt, tool 설명, user message 등을 각각 hash로 주소화해 prompt를 문자열이 아니라 해시 목록 그래프로 다루면 내부 상태를 정확히 복원할 수 있다. 이렇게 하면 diff로 실행 간 변경점을 비교하고, replay로 같은 요청을 다시 돌리거나 다른 모델·다른 설정으로 재평가할 수 있다.
9. 15:32
   프레임워크가 아니라 커널 기존 프레임워크는 에이전트가 그 안에 갇히는 구조였지만, 여기서는 커널이 프로세스를 스케줄하고 로그로 격리하는 방식에 가깝다. markdown은 사용자 공간의 표현일 뿐이고, 핵심은 표현 형식보다 실행·격리·기록을 책임지는 시스템 레이어다.
10. 16:25
    타입이 있는 호출과 타입이 있는 이벤트를 경계로 삼기 잘못된 행동을 단지 '덜 가능하게' 만드는 것이 아니라 '불가능하게' 만드는 것이 커널의 역할이며, 그 중심에는 type tool calls와 typed events가 있다. 실제로 Anthropic의 structured outputs 품질이 낮아 오류가 많았고, 이를 계기로 회사 내부에 배포해 20개의 에이전트를 운영하게 된다.
11. 18:05
    교훈과 구매보다 먼저 만들기 잘 만든 background agent는 아침 브리프처럼 자동으로 결과를 가져다주며, 어려움의 대부분은 새로운 AI 문제가 아니라 익숙한 소프트웨어 오케스트레이션 문제다. 작은 회사라면 먼저 직접 만들어 보며 필요한 것과 한계를 파악한 뒤 구매를 판단하는 편이 낫고, 프레임워크를 만드는 사람도 자기 제품을 실제로 써야 한다.

실무 인사이트

• 에이전트 품질을 높이려면 prompt만 손보는 대신 로그, 재시도, 큐, 이벤트 타입 같은 런타임 경계를 먼저 설계해야 한다.
• 실행 기록을 문자열이 아니라 해시 기반 그래프로 관리하면 diff, replay, 감사 추적이 쉬워져 디버깅과 평가 비용이 크게 줄어든다.
• 작은 조직에서는 프레임워크를 바로 도입하기보다 실제 업무 하나를 끝까지 구현해 보고, 그 과정에서 필요한 추상화만 구매하는 방식이 효율적이다.