Apache Burr: 신뢰할 수 있는 AI 에이전트와 애플리케이션 구축

에이전트 프레임워크는 아직 판단을 유보 중이고, 에이전트 성격에 따라 쓸모가 달라짐. 예를 들어 3초 안에 충분히 괜찮은 응답을 돌려줘야 하는 경우와, 한 문제를 3시간 동안 풀어야 하는 경우는 다름
결국 에이전트는 맥락 구성, LLM 호출, 요청된 도구 호출 실행, 최종 모델 출력 파싱, 프런트엔드 반환으로 압축됨. 메모리나 비동기 도구 호출 같은 확장은 있지만 전통적인 소프트웨어 엔지니어링 관점에서는 그렇게 복잡하지 않음
모두가 자기 에이전트 프레임워크를 만들고 싶어 하지만, 특정 에이전트를 만들어야 한다면 그 에이전트에 맞춘 1:1 코드가 훨씬 쉽고 유지보수도 낫다고 봄. 프레임워크의 추상화는 핵심 로직을 가리고 방해하는 경우가 많고, 결국 프레임워크가 고른 추상화에 맞춰야 해서 실제 목표와 어긋날 때가 있음

에이전트형 시스템의 핵심은 에이전트를 쓰는 것이 아니라, 정말 필요할 때만 쓰는 데 있다고 봄. 작동하는 시스템에는 다단계 흐름을 표현하는 파이프라인/레시피, 여러 에이전트 작업자 풀에서 모델과 사람 개입 단계를 안정적으로 실행하는 운영 체계, 가능한 많은 일을 코드로 처리하는 두꺼운 스킬의 관리·배포·보안·권한, 적절한 세션에 적절한 맥락을 넣는 맥락 관리가 필요함
그 외에도 티켓·의존성·진척·멈춘 티켓 재시작을 다루는 프로젝트 관리, 대화 기록 저장과 메모리·꿈꾸기·누적 학습 기능, 비용과 사용량을 보는 관측성, 프롬프트 평가와 자동 조정, 모델 제공자 교체와 모델 버전 고정, 실제 세션을 돌릴 샌드박스가 필요함
한 공급자에게서 전부 받을 필요는 없지만, 대부분의 경우 단일 모델 제공자에 갇히지 말고, 자기 맥락과 누적 학습은 직접 소유해야 한다고 봄

대부분의 에이전트 프레임워크에서 가장 심각한 부분은 핵심 로직을 가리는 것임. 실제 언어 모델에 무엇이 보내지고 무엇이 돌아오는지 명확히 보여야 함
에이전트형 애플리케이션의 모든 것은 결국 토큰 시퀀스나 제공자 호출로 실현되므로, 앱의 거의 모든 계층에서 그 모습이 분명해야 함

수십 개의 프런트엔드 프레임워크에도 비슷한 생각을 했음. 미래에 올 것 같지만 오지 않을 보상을 위해 거대한 추상화와 복잡도를 떠안기는 식임
그래도 사람들은 할 일이나 재미있는 장난감이 필요하고, “다음 사람”은 대개 그리 중요하게 여겨지지 않으니, 유급 놀이 시간의 결과물을 떠넘겨도 상관없다고 여기는 듯함

특정 에이전트에 맞춘 1:1 코드를 만드는 방식에는 어느 정도 동의함. 다만 새 에이전트에서 새 기법이나 방식을 만들었을 때, 오래된 에이전트를 어떻게 업데이트할지와 업데이트하고 싶은지가 유지보수 측면에서 고민됨
예를 들어 Apache Burr가 플러그인 가능한 벡터 RAG 시스템을 지원하거나 앞으로 지원할 것 같지만, 필요한 것은 문서를 맥락에 추가하고 업데이트된 시스템 프롬프트의 일부로 유지하면서 그 과정에 아주 구체적인 조정을 넣는 방식임. 기존 개념인 RAG를 맞춤형으로 쓰는 방식이라 특정 프레임워크와 잘 맞지 않음
내 용도에서는 맞춤 구현이 맞지만, 오래된 에이전트를 갱신하기 위한 엔지니어링 선택은 여전히 남아 있음

프레임워크의 장점은 실제 에이전트 작성이 쉬워지는 데 있는 게 아니라 도구와 관측성 등에 있음. LangChain도 비판받을 점은 많지만, 이 점은 초기에 아주 분명히 보여줬음
챗봇을 처음부터 직접 만드는 건 쉽거나 더 쉬울 수 있지만, 관측성이나 추적을 추가해야 하면 이야기가 달라짐. 환경 변수 하나만 추가해서 모든 추적을 UI에서 거의 추가 작업 없이 훑어볼 수 있다면, 직접 만든 해법은 경쟁하기 어려움

개인 프로젝트와 업무 프로젝트에서 이 프레임워크를 즐겨 쓰고 있음. AI 모델을 위한 신뢰할 수 있는 상태 있는 워크플로와 무료 관측성을 얻을 수 있어서 좋았음
Burr 상태 기계를 MCP로 마운트하는 도구를 엮었고, 에이전트에게 따라갈 레일을 주면서 상태 기계가 아무리 복잡해져도 MCP 도구는 상태 기계 탐색으로 제한됨: https://github.com/msradam/theodosia
지금은 스킬을 상태 기계로 변환하는 작업을 하고 있음. 인기 있는 많은 스킬이 이미 AI 모델이 따라갈 단계 형태로 작성되어 있어서, Burr의 명시적 기능을 활용하면 더 안정적으로 만들 수 있을 듯함

https://strandsagents.com/와 비교하면 어떤지 궁금함. 이 영역의 도구에 관심이 있고 아직 특정 도구에 묶여 있지는 않지만, Bedrock + Serverless on Agent Core가 “쉬운 안내 경로”처럼 느껴짐. 다만 플랫폼 종속은 마음에 들지 않음

다른 사용 경험이 궁금함. 이 스택을 써보고 있는데 Strands가 Agent Core와 함께 특별한 비법을 제공하는지 의문이 남음
지금까지는 그렇게 느껴지지 않고, 때로는 둘이 서로 충돌하는 것처럼 보이기도 함

여기서는 빌더 패턴과 데코레이터가 보임. Python에도 데코레이터가 있지만, 함수나 메서드에 적용하는 “필터”로 쓰는 게 가장 적절하다고 봄. 이 함수는 캐시하고, 이 함수의 출력은 항상 직렬화하고, 이 함수를 에이전트형 실행 장치의 도구로 준비하는 식임
등록이나 흐름 제어에 쓰는 것은 아니라고 봄. 동의하지 않을 수도 있지만 누군가는 말해야 함. FastAPI가 현대적인 데코레이터 사용을 너무 많이 잘못된 방향으로 끌고 갔음
빌더 패턴은 Rust에 이름 있는 키워드 인자가 없어서 생긴 관례에 가깝고, Python 함수는 이미 이름 있는 계약을 노출함. 설정 매개변수를 연쇄 메서드 호출로 순서대로 넘길 이유는 거의 없음
생성자나 팩토리에 아직 없는 상태를 추가해야 한다면 그건 빌더 패턴이 아니라 등록임. 빌더 패턴을 용인할 만한 곳은 질의 빌더 정도임. 개념을 반복적으로 쌓아 올리고, 메서드 이름과 키워드 인자라는 메타데이터 슬롯이 실제로 유용하기 때문임. 키워드 인자 대신 단일 매개변수를 받는 메서드를 쓰는 것은 잘못됐다고 봄

여기서 데코레이터는 구체적으로 함수에 메타데이터를 붙여 재사용 가능한 구성요소로 만들고, 빌더는 워크플로를 만듦. Hamilton에서는 순수 선언적 구성이라 전부 데코레이터로 처리하지만, 재사용성은 사실상 별도 문제임

빌더 패턴이 Rust에서만 쓰이는 건 아니지만, Python에서 쓰기에는 흉하다는 데 동의함

신뢰할 수 있는 AI 에이전트가 무엇인지에 대해 꽤 순진한 버전처럼 보임
신뢰성은 “맡긴 일을 끝낼 수 있는가”를 뜻하지, 상태 기계와는 딱히 관련이 없음

Burr는 처음 들어보는데, 왜 Apache에서 인큐베이션됐는지 궁금함

안 될 이유가 없음. ASF는 새로운 자유 오픈소스 프로젝트를 인큐베이션해 온 긴 역사가 있음
일부는 졸업해서 누구나 아는 이름이 되고, 일부는 실패해서 attic으로 감. ASF는 조직적 지원을 제공하고 대체로 좋은 공동체를 키워 줌

내가 제출했기 때문임. Apache 절차를 배우고 다른 일도 병행하느라 느린 과정이었지만, 이제는 어느 정도 동력이 생겼고 더 정기적인 릴리스를 시작하고 있음

페이지가 Claude Code로 만든 일회용 쓰레기처럼 보이고, JavaScript 없이 동작하려는 시도조차 안 함. 적어도 브랜드 일관성은 있음

Burr는 미국 건국의 아버지이자 제3대 부통령, 그리고 Alexander Hamilton의 살해자이자 숙적인 Aaron Burr에서 따온 이름임
Hamilton과의 연결점은 DAGWorks가 Hamilton 라이브러리 다음으로 공개한 두 번째 오픈소스 라이브러리라는 데 있음. Burr와 Hamilton이 조화를 이루고 차이를 넘어 더 나은 연방을 만들었다면 어땠을지 상상한 이름임
원래 Burr는 Hamilton DAG 실행 사이의 상태를 다루는 장치로 만들었음. DAG에는 순환이 없기 때문임. 이후 적용 범위가 넓다는 걸 깨닫고 더 넓게 공개했음 https://pypi.org/project/burr/

코딩 에이전트 오케스트레이션 도구나 플랫폼 중 추천할 만한 것이 있는지 궁금함. 여러 머신에서 codex나 claude 에이전트를 실행·관리·모니터링하고 싶음
가능하면 자체 호스팅 가능하거나 오픈소스면 좋겠음. claude code가 내부적으로 그런 기능을 많이 갖고 있는 건 알지만, claude 전용임