[한영자막] 에이전트 프레임워크는 해롭다고 봅니다 — Rémi Louf

한 줄 핵심

에이전트 프레임워크를 그대로 사기보다, 로그·이벤트·타입 경계·재생 가능한 프롬프트를 직접 설계하는 편이 배경 에이전트를 안정적으로 만들 수 있다는 주장이다.

시간별 요약

1. 0:00
   에이전트로 할 수 있는 일을 알아보기 위해 비운 2주 에이전트 성능이 갑자기 좋아진 시점에 2주를 비워 직접 써보며, 실제로 무엇을 할 수 있고 어떤 기본 구성요소가 필요한지 확인하려 했다. 로봇 잔디깎이처럼 백그라운드에서 알아서 일하는 에이전트를 아침 업무에도 만들고 싶다는 문제의식이 출발점이 된다.
2. 1:45
   원했던 아침과 로봇 잔디깎이 아침마다 시장 뉴스, 업무 도구, 음성 메모를 처리하는 반복 업무를 커피와 함께 자동으로 요약해 주는 경험이 목표가 된다. 현재의 에이전트 도구는 유용하지만, 여전히 사용자가 계속 개입해야 해서 진짜 자동화와는 거리가 있다.
3. 2:37
   여전히 앞에 앉아 있어야 하는 터미널 터미널 기반 도구와 앱형 도구는 편해졌지만, 사용자가 계속 지켜보며 방향을 수정해야 하는 점은 크게 달라지지 않았다. 그래서 가장 단순하게 동작하는 것을 직접 만들기 시작했고, 그 과정에서 프레임워크보다 더 낮은 수준의 구조가 필요하다는 감을 잡게 된다.
4. 4:18
   프롬프트를 코드가 아닌 Markdown에 둔 이유 프롬프트를 코드에 박아두는 방식보다 Markdown 파일로 분리하면 버전 관리, diff, PR 리뷰가 쉬워져 에이전트 정의를 다루기 편하다. 실행 시점은 cron 같은 스케줄러가 담당하고, 에이전트는 파일을 넣기만 하면 나타나는 단순한 인터페이스로 구성된다.
5. 5:59
   Cron은 언제, 이벤트는 왜를 다룬다 cron은 단순히 실행 시점을 정할 뿐, 음성 메모가 도착했다는 사실이나 새 이메일·새 PR 같은 발생 이유를 표현하지 못한다. 이벤트를 기준으로 에이전트가 반응하게 만들면 음성 메모 처리와 일일 브리핑이 자연스럽게 연결되고, 그래프보다 이벤트 구독 구조가 더 단순하고 유연해진다.
6. 8:32
   첫 주에 망가진 것들 첫 주에는 Slack에 브리프가 두 번 올라가고, 음성 메모가 사라지고, 프롬프트 수정 이력을 남기지 않아 무엇이 망쳤는지 추적할 수 없었다. 이 실패들이 결국 로그, 재시도 추적, 프롬프트 버전 관리 같은 런타임 기능을 만들게 한 계기가 된다.
7. 9:25
   로그: 아무것도 잃지 않고 인과관계로 연결하기 로그는 모든 이벤트를 append-only로 저장해 무엇이 언제 일어났는지, 어떤 이벤트가 어떤 결과를 만들었는지 인과관계까지 추적하게 해 준다. 디버깅을 위해서는 현재 화면만 보는 것이 아니라, 실제로 모델에 들어간 입력과 실행 경로를 복원할 수 있어야 한다.
8. 11:59
   프롬프트의 content addressing, diff와 replay system prompt, tool 설명, 사용자 메시지 등을 각각 hash로 식별해 프롬프트를 문자열이 아니라 구성 요소 그래프로 다룬다. 이렇게 하면 두 실행의 차이를 diff로 보고, 같은 요청을 replay해 다른 모델이나 수정된 요청으로 재실험할 수 있어 평가와 비용 최적화가 쉬워진다.
9. 13:20
   프레임워크가 아닌 커널 프레임워크 안에 에이전트를 가두는 대신, 커널이 프로세스를 스케줄하고 격리하듯 에이전트 실행을 관리하는 구조가 더 적합하다. 이때 Markdown으로 쓰는 에이전트 정의는 사용자 영역일 뿐이며, 핵심은 실행·격리·기록을 책임지는 하위 계층이다.
10. 15:53
    타입이 있는 호출과 이벤트라는 경계 structured outputs를 활용해 도구 호출과 외부 세계와의 이벤트 경계를 타입으로 강하게 묶어, 존재하지 않는 도구 호출이나 잘못된 이벤트 전파를 줄인다. 실제로는 Anthropic의 structured outputs 한계 때문에 오류율이 높았고, 이를 계기로 회사 안에서 사용할 정도로 커널을 다듬게 된다.
11. 16:13
    배운 점: 구매하기 전에 먼저 만들어 보기 직접 만들어 보니 백그라운드 에이전트는 매우 유용하지만, 풀어야 할 문제는 대부분 기존 소프트웨어 오케스트레이션과 같은 공학 문제였다. 작은 조직일수록 먼저 만들어 보며 필요한 것을 파악한 뒤 도입하는 편이 낫고, 프레임워크를 만드는 사람이라면 자기 제품을 반드시 실제로 써봐야 한다.

실무 인사이트

• 에이전트 도입은 프레임워크 선택보다 로그·이벤트·프롬프트 버전 관리 같은 런타임 설계부터 시작해야 실패 원인을 빠르게 찾을 수 있다.
• 반복 업무 자동화는 cron만으로 부족하고, ‘언제 실행할지’와 ‘무엇이 일어났는지’를 분리한 이벤트 중심 구조로 짜야 확장성이 높다.
• 구매 전에 작은 범위로 직접 만들어 보면 필요한 기능과 한계를 빨리 파악할 수 있어, 불필요한 플랫폼 도입과 조직 내 시행착오를 줄일 수 있다.