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

> Clean Markdown view of GeekNews topic #30388. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30388](https://news.hada.io/topic?id=30388)
- GeekNews Markdown: [https://news.hada.io/topic/30388.md](https://news.hada.io/topic/30388.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-06-11T10:53:38+09:00
- Updated: 2026-06-11T10:53:38+09:00
- Original source: [burr.apache.org](https://burr.apache.org/)
- Points: 1
- Comments: 1

## Topic Body

- **Apache Burr**는 간단한 챗봇부터 복잡한 멀티 에이전트 시스템까지 의사결정형 AI 애플리케이션을 Python으로 구성하는 프레임워크임
- 애플리케이션은 **액션과 전이** 집합으로 정의되며, DSL이나 YAML 없이 Python 함수와 데코레이터로 작성됨
- Burr UI는 실행 단계별 **모니터링·디버깅·추적**을 제공하고, 상태 변화를 실시간으로 확인할 수 있음
- 상태를 디스크, 데이터베이스, 커스텀 백엔드에 저장하고 중단 지점부터 재개할 수 있으며, 사람 입력 대기와 병렬 실행도 지원함
- OpenAI, Anthropic, LangChain, FastAPI, PostgreSQL 등 기존 도구와 통합되며, 잠금 효과나 래퍼 없이 사용 가능함

---

### 신뢰할 수 있는 AI 에이전트와 애플리케이션 구축
- [Apache Burr](https://burr.apache.org/)는 의사결정을 수행하는 애플리케이션 개발을 쉽게 만드는 Apache Incubating Project임
- 대상 범위는 단순 챗봇부터 복잡한 **멀티 에이전트 시스템**까지 확장됨
- 구현 방식은 순수 Python이며, “no magic”을 내세움
- 공개 지표로 GitHub Stars 1,641개, PyPI Downloads 379k+, Discord Members 457+가 표시됨

### 간단하고 강력한 Python API
- Burr는 챗봇부터 멀티 에이전트 시스템까지 구성할 수 있는 **조합 가능한 인터페이스**를 제공함
- 예시 코드는 `burr.core`의 `action`, `State`, `ApplicationBuilder`를 사용해 `chat` 액션을 정의함
- `@action(reads=["messages"], writes=["messages"])`는 읽는 상태와 쓰는 상태를 지정함
- `ApplicationBuilder()`는 액션, 전이, 초기 상태, 로컬 트래커를 설정한 뒤 애플리케이션을 빌드함
- 실행 예시는 `app.run(halt_after=["chat"], inputs={"llm_client": client})` 형태로 LLM 클라이언트를 입력으로 전달함

### AI 애플리케이션 구축에 필요한 요소
- **Simple Python API**는 애플리케이션을 액션과 전이의 집합으로 정의하며, DSL이나 YAML 없이 Python 함수와 데코레이터만 사용함
- **Built-in Observability**는 Burr UI로 애플리케이션의 모든 단계를 실시간 모니터링, 디버깅, 추적할 수 있게 함
- **Persistence & State Management**는 상태를 디스크, 데이터베이스, 커스텀 백엔드에 자동 저장하고 중단 지점부터 재개할 수 있게 함
- **Human-in-the-Loop**는 어느 단계에서든 실행을 멈추고 사람 입력을 기다릴 수 있어 승인 워크플로와 상호작용형 에이전트에 적합함
- **Branching & Parallelism**은 병렬 액션 실행, fan out / fan in, 복잡한 DAG 구축, 하위 애플리케이션 조합을 지원함
- **Testing & Replay**는 과거 실행 재생, 개별 액션 단위 테스트, 상태 전이 검증을 통해 AI 시스템에 대한 확신을 높임

### 기존 스택과의 통합
- Burr는 이미 사용하는 도구와 프레임워크에 통합되며, **잠금 효과**나 래퍼를 요구하지 않음
- LLM 통합 항목으로 OpenAI, Anthropic, Instructor가 표시됨
- 프레임워크 통합 항목으로 LangChain, Hamilton, Haystack이 표시됨
- UI와 서빙 통합 항목으로 Streamlit과 FastAPI가 표시됨
- 검증과 저장소 통합 항목으로 Pydantic과 PostgreSQL이 표시됨
- 전체 통합 목록은 [문서](https://burr.apache.org/docs)에서 확인할 수 있음

### 개발자와 팀의 사용 경험
- Peanut Robotics 후기는 여러 LLM 프레임워크를 평가한 뒤 Burr의 **상태 관리**가 AI 의사결정 기반 로봇 배포에 강력한 답이었다고 평가함
- Watto.ai 후기는 모듈형 AI 애플리케이션을 만들기 쉽고, UI가 디버깅을 쉽게 만든다고 평가함
- Paxton AI 후기는 AI라는 이유만으로 이상하고 난해한 개념을 쓰지 않는다는 점을 강조함
- Provectus 후기는 상태 스냅샷 생성, 디버깅, 재생, 평가 케이스 구축에 Burr의 상태 관리가 유용하다고 평가함
- CognitiveGraphs 후기는 LangChain, CrewAi, AutoGen, Agency Swarm 등 여러 agentic LLM 플랫폼과 비교해 Burr가 복잡한 동작 설계에 더 견고한 프레임워크를 제공한다고 평가함
- TaskHuman 후기는 LangChain에서 Burr로 이동한 뒤 몇 시간 만에 시작했고, 전체 코드베이스를 Burr로 전환했다고 평가함

### 커뮤니티와 프로젝트 상태
- 커뮤니티는 도움 요청, 프로젝트 공유, Burr의 미래 기여를 위한 공간으로 구성됨
- 참여 경로는 [Discord](https://discord.gg/6Zy2DwP4f3), [GitHub](https://github.com/apache/burr), [Twitter / X](https://x.com/burr_framework)로 제공됨
- 프로젝트 리소스는 문서, 예제, YouTube, 로드맵, 변경 로그로 연결됨
- Apache Burr는 Apache Software Foundation에서 인큐베이션 중인 프로젝트이며, Apache Incubator가 후원함
- 인큐베이션 상태는 코드의 완성도나 안정성을 반드시 반영하지 않지만, ASF의 완전한 승인을 아직 받지 않았음을 나타냄

## Comments



### Comment 59404

- Author: neo
- Created: 2026-06-11T10:53:39+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48477400) 
- 에이전트 프레임워크는 아직 판단을 유보 중이고, 에이전트 성격에 따라 쓸모가 달라짐. 예를 들어 **3초 안에 충분히 괜찮은 응답**을 돌려줘야 하는 경우와, 한 문제를 3시간 동안 풀어야 하는 경우는 다름  
  결국 에이전트는 맥락 구성, LLM 호출, 요청된 도구 호출 실행, 최종 모델 출력 파싱, 프런트엔드 반환으로 압축됨. 메모리나 비동기 도구 호출 같은 확장은 있지만 전통적인 소프트웨어 엔지니어링 관점에서는 그렇게 복잡하지 않음  
  모두가 자기 에이전트 프레임워크를 만들고 싶어 하지만, 특정 에이전트를 만들어야 한다면 그 에이전트에 맞춘 **1:1 코드**가 훨씬 쉽고 유지보수도 낫다고 봄. 프레임워크의 추상화는 핵심 로직을 가리고 방해하는 경우가 많고, 결국 프레임워크가 고른 추상화에 맞춰야 해서 실제 목표와 어긋날 때가 있음
  - 에이전트형 시스템의 핵심은 에이전트를 쓰는 것이 아니라, 정말 필요할 때만 쓰는 데 있다고 봄. 작동하는 시스템에는 다단계 흐름을 표현하는 **파이프라인/레시피**, 여러 에이전트 작업자 풀에서 모델과 사람 개입 단계를 안정적으로 실행하는 운영 체계, 가능한 많은 일을 코드로 처리하는 두꺼운 스킬의 관리·배포·보안·권한, 적절한 세션에 적절한 맥락을 넣는 맥락 관리가 필요함  
    그 외에도 티켓·의존성·진척·멈춘 티켓 재시작을 다루는 프로젝트 관리, 대화 기록 저장과 메모리·꿈꾸기·누적 학습 기능, 비용과 사용량을 보는 관측성, 프롬프트 평가와 자동 조정, 모델 제공자 교체와 모델 버전 고정, 실제 세션을 돌릴 샌드박스가 필요함  
    한 공급자에게서 전부 받을 필요는 없지만, 대부분의 경우 단일 모델 제공자에 갇히지 말고, **자기 맥락**과 **누적 학습**은 직접 소유해야 한다고 봄
  - 대부분의 에이전트 프레임워크에서 가장 심각한 부분은 **핵심 로직을 가리는 것**임. 실제 언어 모델에 무엇이 보내지고 무엇이 돌아오는지 명확히 보여야 함  
    에이전트형 애플리케이션의 모든 것은 결국 토큰 시퀀스나 제공자 호출로 실현되므로, 앱의 거의 모든 계층에서 그 모습이 분명해야 함
  - 수십 개의 프런트엔드 프레임워크에도 비슷한 생각을 했음. 미래에 올 것 같지만 오지 않을 보상을 위해 거대한 **추상화와 복잡도**를 떠안기는 식임  
    그래도 사람들은 할 일이나 재미있는 장난감이 필요하고, “다음 사람”은 대개 그리 중요하게 여겨지지 않으니, 유급 놀이 시간의 결과물을 떠넘겨도 상관없다고 여기는 듯함
  - 특정 에이전트에 맞춘 **1:1 코드**를 만드는 방식에는 어느 정도 동의함. 다만 새 에이전트에서 새 기법이나 방식을 만들었을 때, 오래된 에이전트를 어떻게 업데이트할지와 업데이트하고 싶은지가 유지보수 측면에서 고민됨  
    예를 들어 Apache Burr가 플러그인 가능한 벡터 RAG 시스템을 지원하거나 앞으로 지원할 것 같지만, 필요한 것은 문서를 맥락에 추가하고 업데이트된 시스템 프롬프트의 일부로 유지하면서 그 과정에 아주 구체적인 조정을 넣는 방식임. 기존 개념인 RAG를 맞춤형으로 쓰는 방식이라 특정 프레임워크와 잘 맞지 않음  
    내 용도에서는 맞춤 구현이 맞지만, 오래된 에이전트를 갱신하기 위한 엔지니어링 선택은 여전히 남아 있음
  - 프레임워크의 장점은 실제 에이전트 작성이 쉬워지는 데 있는 게 아니라 **도구와 관측성** 등에 있음. LangChain도 비판받을 점은 많지만, 이 점은 초기에 아주 분명히 보여줬음  
    챗봇을 처음부터 직접 만드는 건 쉽거나 더 쉬울 수 있지만, 관측성이나 추적을 추가해야 하면 이야기가 달라짐. 환경 변수 하나만 추가해서 모든 추적을 UI에서 거의 추가 작업 없이 훑어볼 수 있다면, 직접 만든 해법은 경쟁하기 어려움

- 이 페이지가 [https://vorpus.github.io/performativeUI/](<https://vorpus.github.io/performativeUI/>)로 만든 건지 궁금함  
  **AI 생성 랜딩 페이지**의 전형적인 클리셰를 가능한 한 전부 밟고 있음. 아니면 일부러 풍자한 건가 싶음

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

- [https://strandsagents.com/](<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 없이 동작하려는 시도조차 안 함. 적어도 **브랜드 일관성**은 있음

- 이름의 명시적인 근거는 못 찾았지만, 궁금한 사람을 위해 Hamilton 예제가 있음: [https://github.com/apache/burr/tree/main/examples/multi-agen...](<https://github.com/apache/burr/tree/main/examples/multi-agent-collaboration/hamilton>)
  - Burr는 미국 건국의 아버지이자 제3대 부통령, 그리고 Alexander Hamilton의 살해자이자 숙적인 **Aaron Burr**에서 따온 이름임  
    Hamilton과의 연결점은 DAGWorks가 Hamilton 라이브러리 다음으로 공개한 두 번째 오픈소스 라이브러리라는 데 있음. Burr와 Hamilton이 조화를 이루고 차이를 넘어 더 나은 연방을 만들었다면 어땠을지 상상한 이름임  
    원래 Burr는 Hamilton DAG 실행 사이의 상태를 다루는 장치로 만들었음. DAG에는 순환이 없기 때문임. 이후 적용 범위가 넓다는 걸 깨닫고 더 넓게 공개했음  
    [https://pypi.org/project/burr/](<https://pypi.org/project/burr/>)

- 코딩 에이전트 **오케스트레이션 도구나 플랫폼** 중 추천할 만한 것이 있는지 궁금함. 여러 머신에서 codex나 claude 에이전트를 실행·관리·모니터링하고 싶음  
  가능하면 자체 호스팅 가능하거나 오픈소스면 좋겠음. claude code가 내부적으로 그런 기능을 많이 갖고 있는 건 알지만, claude 전용임
  - 문서를 보니 Burr에는 이걸 시작할 수 있는 에이전트 쿡북이 있고, **여러 머신 워크플로**도 처리할 수 있음. 찾던 게 이게 아닌지 궁금함  
    스킬 등과 어떻게 통합해서 쓰는지는 확실하지 않지만, 보기에는 동작할 것 같음  
    [https://burr.apache.org/docs/examples/agents/](<https://burr.apache.org/docs/examples/agents/>)