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

2026-06-11 · 2026-06-11_apache-burr-reliable-ai-agents.md

#ai-agents #framework #apache #python #state-machine #observability

원문 출처

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

한 줄 요약

Apache Burr는 Apache 인큐베이터 프로젝트로, Python 기반의 AI 에이전트 프레임워크인데, 핵심 차별점은 명시적인 상태 관리와 내장된 관측성(observability)을 제공한다는 것이다. LangChain, LangGraph, CrewAI 같은 기존 프레임워크들과 달리, YAML이나 전용 DSL(도메인 특화 언어) 없이 순수 Python 함수와 데코레이터만으로 에이전트 워크플로우를 정의할 수 있다.

핵심 내용

Apache Burr가 무엇인가

Apache Burr는 Apache 소프트웨어 재단(Apache Software Foundation, ASF)의 인큐베이터 프로젝트이다. 인큐베이터란 아직 ASF의 정식 프로젝트로 승인은 받지 않았지만, ASF의 감시 아래 개발 중인 프로젝트를 말한다. GitHub 스타 1,759개, PyPI 다운로드 464만 회, Discord 회원 617명 이상의 커뮤니티를 보유하고 있다.

Burr의 핵심 철학은 "신뢰할 수 있는 AI 애플리케이션"을 만드는 것이다. 여기서 '신뢰할 수 있다'는 것은 에이전트가 실행 중 오류가 나도 상태를 저장해두고, 나중에 중단된 곳에서 다시 시작할 수 있다는 것을 의미한다. 또한 실행 과정의 모든 단계를 추적하고 시각화할 수 있는 내장 UI를 제공한다.

주요 기능

1. 순수 Python API

Burr는 YAML 설정 파일이나 전용 DSL이 필요 없다. 표준 Python 함수와 데코레이터로 에이전트 워크플로우를 정의한다. 예를 들어 @action(reads=["messages"], writes=["messages"]) 같은 데코레이터로 각 단계가 어떤 상태를 읽고 쓰는지 명시한다. 이렇게 하면 각 단계가 서로 어떻게 연결되는지가 코드 자체에서 명확하게 드러난다.

from burr.core import action, State, ApplicationBuilder

@action(reads=["messages"], writes=["messages"])
def chat(state: State, llm_client) -> State:
    response = llm_client.chat(state["messages"])
    return state.update(
        messages=[*state["messages"], response]
    )

app = (
    ApplicationBuilder()
    .with_actions(chat)
    .with_transitions(("chat", "chat"))
    .with_state(messages=[])
    .with_tracker("local")
    .build()
)

app.run(halt_after=["chat"], inputs={"llm_client": client})

위 코드는 간단한 챗봇 애플리케이션인데, chat이라는 액션이 메시지 목록을 읽고, LLM에 질문한 후, 응답을 메시지 목록에 추가하는 구조이다. ApplicationBuilder로 액션을 등록하고, 전이(transition) 규칙을 설정하며, 초기 상태를 정의한다.

2. 내장 관측성(Observability)

Burr는 실행 중인 에이전트의 상태를 실시간으로 모니터링할 수 있는 내장 UI를 제공한다. 각 단계에서 어떤 상태가 변경되었는지, 어떤 LLM 호출이 이루어졌는지, 얼마나 시간이 걸렸는지를 시각적으로 확인할 수 있다. LangChain 같은 프레임워크는 LangSmith 같은 별도 서비스에 의존해야 하지만, Burr는 자체적으로 이 기능을 제공한다.

3. 상태 지속성(Persistence)

에이전트 실행 중 중단되어도 상태를 디스크나 데이터베이스에 저장해두고, 나중에 중단된 지점부터 다시 시작할 수 있다. 이는 장시간 실행되는 에이전트나 여러 단계에 걸쳐 작업을 처리하는 에이전트에게 매우 중요한 기능이다.

4. 인간-인-더-루프(Human-in-the-Loop)

에이전트 실행 중간에 사람을 기다리게 할 수 있다. 예를 들어, 중요한 결정을 내리기 전에 사용자의 승인을 기다리거나, 사용자가 직접 입력을 제공해야 하는 워크플로우를 구현할 수 있다.

5. 분기 및 병렬 처리

여러 액션을 동시에 실행하거나, 조건에 따라 다른 경로로 분기할 수 있다. 팬-아웃/팬-인(fan-out/fan-in) 패턴과 복잡한 DAG(방향성 비순환 그래프)를 지원한다. 또한 하위 애플리케이션을 구성하여 모듈식 설계를 할 수 있다.

6. 테스트 및 재생(Replay)

과거 실행 기록을 다시 재생하거나, 개별 액션을 단위 테스트로 검증할 수 있다. 상태 전이가 예상대로 이루어지는지 확인할 수 있어 시스템 신뢰도를 높일 수 있다.

기존 스택과의 통합

Burr는 특정 LLM 제공업체나 프레임워크에 종속되지 않는다. OpenAI, Anthropic, Instructor 같은 LLM 라이브러리와 함께 사용할 수 있고, LangChain, Hamilton, Haystack 같은 기존 프레임워크와도 호환된다. UI/서빙 측면에서는 Streamlit, FastAPI와 연동되며, 데이터 저장에는 PostgreSQL을, 유효성 검증에는 Pydantic을 사용할 수 있다.

커뮤니티 평가

실제 사용자의 평가를 보면:

  • Peanut Robotics의 CTO: "다른 복잡한 LLM 프레임워크를 평가한 후, Burr의 우아한 상태 관리 솔루션이 AI 로봇을 구동하는 데 강력한 해법이었다"
  • Watto.ai의 설립자: "모듈식 AI 애플리케이션을 구축하려면 Burr가 당연한 선택. 특히 UI가 디버깅을 매우 쉽게 만들어준다"
  • TaskHuman의 DS 아키텍트: "LangChain에서 Burr로 넘어온 것이 게임 체인저. 몇 시간 만에 시작할 수 있었는데, LangChain은 며칠, 몇 주가 걸렸다"

커뮤니티 반응 (Hacker News)

HN에서 178점, 93개 댓글을 기록하며 뜨거운 반응을 보였다. 댓글을 크게 세 가지 관점으로 정리할 수 있다.

1. 웹사이트 디자인에 대한 부정적 반응 (가장 많음)

가장 많은 댓글이 웹사이트 디자인을 비판하는 내용이었다. 여러 사용자가 홈페이지가 AI 생성된 템플릿을 사용한 것처럼 보인다고 지적했다.

  • iririririr: "당연히 페이지는 Claude Code로 만든 일회용 쓰레기고, JavaScript 없이 동작하려는 시도조차 안 했다. 적어도 브랜드 일관성은 있다"
  • eranation: "이 페이지가 performativeUI로 만든 건지 궁금하다. AI 생성 랜딩 페이지의 전형적인 클리셰를 가능한 한 전부 밟고 있다. 아니면 일부러 풍자한 건가"
  • redlewel: "2시간도 안 걸려 만든 vibeslopped 랜딩 페이지를 본 후 더 이상 읽지 않았다. 또한 '700+ Discord Members'는 기술이나 서비스에 대한 어떤 종류의 추천도 아니다"
  • vanuatu: "vibe coded landing page, reddit user testimonial, framework is for state machines, why man.."

이러한 비판은 Burr 프로젝트의 기술적 내용과는 별개로, 마케팅과 브랜딩 측면에서의 문제를 지적하는 것이다. Apache 프로젝트라는 정통성과 AI 생성 템플릿이라는 비공식적 디자인이 대비되어 불일치를 느끼는 사용자들이 많았다.

2. 에이전트 프레임워크 자체에 대한 회의적 시각

에이전트 프레임워크의 필요성 자체에 의문을 제기하는 댓글들도 있었다.

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

이 의견은 핵심적으로 "에이전트 프레임워크가 오히려 추상화 오버헤드를 만든다"는 주장이다. 실제로 drchaim이라는 사용자는 "클라이언트를 위해 MVP 챗봇을 만들었는데 프레임워크를 쓰지 않았다. Claude/codex가 에이전트 루프, 도구, 스트리밍을 다 작성해줬고 잘 작동하고 있다"고 말했다.

3. 긍정적 평가와 실제 사용 사례

실제로 Burr를 사용해본 사용자들은 긍정적이었다.

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

이 사용자는 Burr를 실제 MCP(Model Context Protocol)와 연동하여 사용하고 있으며, AI 스킬을 상태 기계로 변환하는 작업을 진행 중이라고 밝혔다. 이는 Burr의 상태 관리 기능이 실제 프로덕션 환경에서도 유용하게 쓰이고 있음을 보여준다.

기타 질문들

  • g42gregory: "Pydantic AI와 비교했을 때 장단점은 무엇인가"
  • hbarka: "dspy.ai와 비교하면 어떤가"
  • mooreds: "에이전트는 어떻게 인증되는가. 문서에서 인증과 MCP를 검색했지만 결과가 없었다"
  • hmokiguess: "strandsagents.com와 비교하면 어떤가. Bedrock + Serverless on Agent Core가 쉬운 안내 경로처럼 느껴지지만 플랫폼 종속은 마음에 들지 않는다"

이 질문들은 Burr가 경쟁 프레임워크들과 어떻게 다른지, 그리고 보안/인증 측면에서 어떤 기능을 제공하는지에 대한 관심을 보여준다.

새로운 시각

상태 기계 접근법의 의미

Burr가 강조하는 '상태 기계(state machine)' 접근법은 다른 에이전트 프레임워크들과 근본적으로 다른 철학을 반영한다. LangGraph가 그래프 기반 오케스트레이션을 강조한다면, Burr는 명시적인 상태 전이에 초점을 맞춘다. 이는 에이전트 실행을 '상태 A → 상태 B → 상태 C'로 명확하게 추적할 수 있게 한다.

이 접근법의 장점은 디버깅과 테스트가 훨씬 쉬워진다는 것이다. 각 상태 전이가 코드에서 명시적으로 정의되어 있으므로, 에이전트가 왜 특정 결정을 내렸는지 추적하기 쉽다. 반면, LangChain처럼 암묵적인 상태 관리를 하는 프레임워크는 디버깅이 훨씬 어렵다.

Apache 인큐베이터의 의미

Burr가 Apache 인큐베이터 프로젝트라는 점은 중요한 차별자이다. Apache 프로젝트는 오픈소스 거버넌스의 금자탑으로, 기업에 종속되지 않은 중립적인 개발 환경을 보장한다. 이는 특히 기업 사용자가 특정 벤더에 종속되지 않으려는 상황에서 매력적이다. AWS의 Bedrock Agent Core나 OpenAI Agents SDK 같은 플랫폼 종속 솔루션과는 대비된다.

빌더 패턴과 데코레이터에 대한 논쟁

tcdent라는 사용자는 Burr가 사용하는 빌더 패턴과 데코레이터 사용 방식에 대해 기술적 비판을 제기했다. Python의 데코레이터는 함수에 '필터'를 적용하는 용도로 가장 적합하지만, Burr는 데코레이터를 등록과 흐름 제어에 사용한다는 것이다. 또한 빌더 패턴은 Rust에서 이름 있는 키워드 인자가 없어서 생긴 관례인데, Python은 이미 이름 있는 인자를 지원하므로 빌더 패턴이 필요 없다는 주장이다.

이 논쟁은 Python 커뮤니티에서 오랫동안 존재해 온 논의인데, FastAPI가 데코레이터를 라우트 등록에 사용하면서 이 패턴이 널리 퍼졌다. Burr도 비슷한 패턴을 따르고 있다.

자녀/미래 영향

아인, 석현, 은한이 성장하는 시대에 AI 에이전트는 일상적인 도구가 될 것이다. Burr 같은 프레임워크가 제공하는 '신뢰할 수 있는' 에이전트 개념은 단순히 기술적 문제를 넘어, AI가 우리의 중요한 결정을 도와줄 때 얼마나 신뢰할 수 있는지에 대한 질문과 연결된다.

에이전트 프레임워크 논쟁에서 핵심은 '제어 vs 자율'의 균형이다. Burr는 명시적인 상태 관리를 통해 제어를 강조하지만, 다른 프레임워크들은 더 많은 자율성을 제공한다. 자녀들이 이 분야에서 일할 때, 어떤 접근이 더 적합한지는 사용 사례에 따라 달라질 것이다. 중요한 것은 AI 에이전트의 내부 작동 방식을 이해하고, 필요에 맞는 도구를 선택할 수 있는 능력이다.

실용적으로 말하면, AI 에이전트 개발은 아직 '정답'이 없는 분야이다. 여러 프레임워크를 시도해보고, 각각의 장단점을 이해하는 것이 가장 좋은 학습 방법일 것이다. Burr의 상태 기계 접근법, LangGraph의 그래프 기반 오케스트레이션, CrewAI의 역할 기반 협업 등 다양한 패러다임을 경험해보는 것이 도움이 될 것이다.

관련 노트

  • [[2026-06-11_llm-agent-frameworks-landscape]] — 2026년 AI 에이전트 프레임워크 비교 분석 (향후 작성 예정)