포스트

Agno: 순수 파이썬 기반 고성능 멀티 에이전트 시스템과 AgentOS 구축

프로젝트 한눈에 보기
41.8k스타
5.8k포크
Python주 언어
5.3k파일 수
Apache-2.0라이선스
2026-08-21업데이트
Python Shell HTML Batchfile TypeScript

Agno는 Python 제어 흐름으로 에이전트와 팀을 구성하고 같은 코드에서 API 런타임까지 연결하려는 개발팀에 적합합니다. 프레임워크 인스턴스 생성이 빠르다는 벤치마크만으로 실제 LLM 응답이나 도구 실행이 빨라지는 것은 아닙니다. 도입 전 자신의 모델, 세션 저장소, 동시 요청 조건에서 전체 지연, 메모리와 실패 복구를 비교해야 합니다.

Agno에서 실행 단위를 고르는 기준

  • Agent: 모델, 도구, 지시를 한 실행 주체로 묶은 가장 작은 단위입니다. 도구 몇 개로 결과 하나를 만들 수 있다면 이 구조부터 검증하는 편이 추적하기 쉽습니다.
  • Team: 서로 다른 역할의 Agent가 작업을 나누고 결과를 합치는 협력 단위입니다. 역할을 늘릴수록 전달되는 문맥과 실패 지점도 함께 늘어납니다.
  • Workflow: 실행 순서, 분기, 재시도를 Python 제어 흐름으로 명시한 자동화 과정입니다. 어떤 단계가 다음에 실행돼야 하는지 업무 규칙이 분명할 때 적합합니다.
  • AgentOS: 작성한 Agent, Team, Workflow를 API로 실행하고 세션, 메모리, 추적 정보를 연결하는 런타임 계층입니다. AgentOS를 띄웠다는 사실만으로 인증과 운영 복구가 완성되는 것은 아닙니다.
  • 세션 지속성: 요청이 끝난 뒤에도 대화 상태와 실행 기록을 저장소에 남겨 다음 요청에서 이어 쓰는 성질입니다. 사용자별 격리와 보존 기간을 함께 정해야 합니다.

도입 및 한 줄 요약

최근 생성형 AI 분야에서 단일 거대언어모델(LLM)에 모든 과업을 맡기기보다, 특화된 역할을 가진 여러 에이전트가 협력하는 멀티 에이전트 시스템(Multi-Agent System)의 필요성이 급격히 커지고 있습니다. 하지만 기존 에이전트 프레임워크들을 활용해 프롬프팅 단계를 넘어 실제 서비스 환경(Production)으로 확장하려고 하면 곧바로 거대한 장벽에 부딪히곤 해요. 복잡한 전용 그래프 엔진이나 체인 구조 때문에 디버깅이 어렵고, 프레임워크 자체가 유발하는 메모리 점유율과 속도 저하가 무시할 수 없는 수준에 이르기 때문이죠.

Agno(구 Phidata)는 이러한 기존 프레임워크들의 복잡성과 오버헤드를 해결하기 위해 등장한 프레임워크입니다. 이 글에서는 Agno가 어떻게 순수 파이썬(Pure Python) 접근법을 통해 뛰어난 성능과 직관적인 개발 경험을 제공하는지, 그리고 에이전트 배포를 위한 AgentOS가 엔터프라이즈 환경에서 어떤 가치를 제공하는지 깊이 있게 알아보겠습니다.

TL;DR (한 줄 요약) Agno는 복잡한 그래프 추상화 없이 순수 파이썬 흐름 제어로 구현하는 고성능 멀티 에이전트 프레임워크로, 내장된 AgentOS를 통해 에이전트 시스템을 단 몇 줄의 코드로 프로덕션 수준의 REST API 서비스로 전환해 줍니다.


Agno란 무엇인가

Agno는 그리스어 ‘아그노스(ἁγνός, 순수한)’에서 이름을 딴 오픈소스 멀티 에이전트 프레임워크예요. 이름에서 알 수 있듯이 이 프로젝트의 최우선 가치는 순수함(Pure)간결함(Simplicity)에 있습니다. 과거 Phidata라는 이름으로 널리 알려졌으나, 멀티 에이전트 오케스트레이션과 프로덕션 런타임 플랫폼으로의 진화를 도모하며 Agno라는 새로운 브랜드로 재탄생했어요.

기존 프레임워크들이 에이전트의 상태나 워크플로우를 표현하기 위해 자체적인 DAG(Directed Acyclic Graph) 엔진이나 특수한 추상화 계층을 새로 정의했다면, Agno는 파이썬 언어가 본래 제공하는 기본 문법(조건문 if/else, 반복문 while/for, 예외 처리 try/except)을 그대로 활용합니다. 복잡한 제어 그래프를 배우지 않고도 파이썬 개발자라면 누구나 즉시 멀티 에이전트 로직을 작성할 수 있도록 돕는 것이죠.

이해를 돕기 위해 일상적인 비유를 들어볼까요? 기존의 그래프 기반 에이전트 프레임워크가 무대 위의 배우들에게 센티미터 단위로 정해진 레일 위만 움직이도록 강요하는 거대한 태엽 장치와 같다면, Agno는 분야별 전문가(금융 분석가, 웹 리서처, 작가)로 구성된 유연한 오케스트라와 같아요. 연주자들은 자신만의 전문 도구와 기억력을 가지고 있으며, 지휘자나 다른 동료와 파이썬이라는 매우 자연스러운 공용 언어로 소통하며 연주를 완성해 나갑니다.


왜 Agno가 등장했는가: 기존 프레임워크의 한계와 문제 정의

많은 개발팀이 초기에 멋진 AI 에이전트 데모를 성공적으로 만들어냅니다. 하지만 이를 실제 고객이 사용하는 프로덕션 환경으로 가져갈 때 다음과 같은 구체적인 어려움에 직면하게 되더라고요.

첫째, 과도한 추상화로 인한 디버깅 및 제어의 어려움입니다. 에이전트 내부에서 의도치 않은 환각이나 무한 루프가 발생했을 때, 프레임워크 내부의 거대한 상태 그래프 레이어에 가려져 정확히 어느 단계에서 데이터가 오염되었는지 추적하기가 매우 어렵습니다.

둘째, 성능 오버헤드와 메모리 비효율성입니다. 에이전트 하나를 인스턴스화하는 데 수백 밀리초가 걸리거나 메가바이트 단위의 불필요한 객체들이 메모리를 차지한다면, 동시 요청이 몰리는 엔터프라이즈 서버 환경에서는 심각한 병목 현상이 발생해요.

셋째, 데모 코드와 상용 API 배포 사이의 거대한 격차입니다. 에이전트 로직을 아무리 잘 작성했더라도, 이를 웹 애플리케이션과 연결하려면 REST API 엔드포인트 개설, 세션 상태 지속성 유지, JWT 기반 권한 관리, OpenTelemetry 기반 분산 트레이싱 구축 등 수개월의 인프라 작업이 별도로 필요합니다.

Agno는 개발 레이어의 Agno Python Framework와 런타임 레이어의 AgentOS라는 이원화 구조를 통해 이 문제들을 직관적으로 해결해요.

{"type":"bar","data":{"labels":["LangGraph","CrewAI","AutoGen","Agno"],"datasets":[{"label":"초당 에이전트 생성 수 (인스턴스/초)","data":[10,100,250,50000]},{"label":"초기 메모리 점유량 (MB)","data":[250,180,120,5]}]},"options":{"responsive":true,"plugins":{"title":{"display":true,"text":"주요 에이전트 프레임워크 성능 및 메모리 비교"}}}}

Agno의 내부 작동 원리와 핵심 구성 요소

Agno의 전체 시스템은 크게 4가지 핵심 구성 요소로 이뤄져 있습니다. 각각의 아키텍처 역할과 상호작용 방식을 하나씩 살펴볼게요.

1. Agent (단일 에이전트)

에이전트는 독립적인 과업을 수행하는 최소 단위입니다. LLM 모델(OpenAI, Anthropic, Gemini, Ollama 등)에 기억(Memory), 지식(Knowledge), 도구(Tools), 추론(Reasoning), 가드레일(Guardrails)을 결합하여 생성됩니다.

2. Team (에이전트 협력체)

여러 전문 에이전트들을 하나로 묶어 복잡한 과업을 분업화하는 구조입니다. 리더 에이전트가 하위 에이전트에 작업을 위임하고 결과를 합성할 수 있어요.

3. Workflow (결정론적 자동화 파이프라인)

에이전트, 팀, 일반 파이썬 함수를 순차적 혹은 조건부로 연결하는 실행 파이프라인입니다. 스텝별 결과 전달과 에러 처리가 순수 파이썬 코드로 이뤄집니다.

4. AgentOS (프로덕션 런타임)

FastAPI 기반의 스테이트리스(Stateless) API 서버로, 에이전트 시스템을 50개 이상의 REST API 엔드포인트와 Server-Sent Events(SSE) 스트리밍 기능으로 노출해 줍니다.

%%{init: {"theme":"base","themeVariables":{"primaryColor":"#F0EEE9","primaryBorderColor":"#2a78d6","primaryTextColor":"#2b2926","secondaryColor":"#e8f0fb","secondaryBorderColor":"#4a3aa7","secondaryTextColor":"#2b2926","tertiaryColor":"#eafaf3","tertiaryBorderColor":"#1baf7a","tertiaryTextColor":"#2b2926","lineColor":"#8a8578","textColor":"#2b2926","edgeLabelBackground":"#F0EEE9","noteBkgColor":"#F0EEE9","noteTextColor":"#2b2926","noteBorderColor":"#8a8578","clusterBkg":"#faf9f6","clusterBorder":"#d8d4c8","fontFamily":"Pretendard, sans-serif"}}}%%
flowchart TD
    A["사용자 및 API 클라이언트"] --> B["AgentOS REST API"]
    B --> C["워크플로우 엔진"]
    C --> D["팀 조율자"]
    D --> E1["전문 에이전트 A"]
    D --> E2["전문 에이전트 B"]
    E1 --> F["외부 도구 및 데이터베이스"]
    E2 --> F

요청 처리 및 시퀀스 흐름

클라이언트가 Agno 시스템에 질의를 보낼 때 내부에서 이루어지는 상호작용 흐름은 아래와 같습니다.

%%{init: {"theme":"base","themeVariables":{"primaryColor":"#F0EEE9","primaryBorderColor":"#2a78d6","primaryTextColor":"#2b2926","secondaryColor":"#e8f0fb","secondaryBorderColor":"#4a3aa7","secondaryTextColor":"#2b2926","tertiaryColor":"#eafaf3","tertiaryBorderColor":"#1baf7a","tertiaryTextColor":"#2b2926","lineColor":"#8a8578","textColor":"#2b2926","edgeLabelBackground":"#F0EEE9","noteBkgColor":"#F0EEE9","noteTextColor":"#2b2926","noteBorderColor":"#8a8578","clusterBkg":"#faf9f6","clusterBorder":"#d8d4c8","fontFamily":"Pretendard, sans-serif"}}}%%
sequenceDiagram
    autonumber
    participant Client as 클라이언트
    participant AgentOS as AgentOS 서비스
    participant Team as 분석 팀 리더
    participant Agent as 시장 분석 에이전트
    participant Tool as YFinance API
    
    Client->>AgentOS: 주가 분석 요청
    AgentOS->>Team: 분석 작업 할당
    Team->>Agent: 데이터 수집 명령
    Agent->>Tool: YFinance API 호출
    Tool-->>Agent: 주가 데이터 응답
    Agent-->>Team: 데이터 분석 결과 전달
    Team-->>AgentOS: 최종 보고서 생성
    AgentOS-->>Client: 스트리밍 응답 전송

AgentOS 세션 데이터베이스 스키마

AgentOS는 스테이트리스 환경에서도 지속성을 유지하기 위해 데이터베이스에 세션, 메모리, 트레이스 정보를 영구 저장합니다.

erDiagram
    AGENT_ENTITY ||--o{ AGENT_SESSION :

위 ER 다이어그램은 파일 끝에서 관계 설명이 잘린 상태이므로 완성된 데이터베이스 스키마로 해석하면 안 됩니다. 실제 테이블과 마이그레이션은 현재 저장소 문서를 기준으로 확인해야 합니다.

단일 Agent와 Team, Workflow 중 무엇을 선택할까?

도구 몇 개로 한 가지 결과를 만드는 작업은 단일 Agent로 시작하는 편이 추적하기 쉽습니다. 서로 다른 전문 판단이 실제로 필요할 때만 Team을 추가하고, 승인, 재시도, 분기 순서가 명확한 업무는 일반 Python 함수와 Workflow로 고정합니다. 역할 이름만 다른 에이전트를 많이 붙이면 같은 문맥을 반복 전송하고 결과를 다시 요약하느라 비용과 지연이 늘 수 있습니다.

멀티 에이전트의 합격 기준은 대화가 자연스러운지가 아니라 완료율과 오류 위치를 재현할 수 있는지입니다. 같은 입력으로 단일 Agent와 Team을 비교해 도구 호출 수, 토큰, 최종 정확도와 사람이 수정한 시간을 기록합니다. Team이 더 비싸면서 품질 차이가 없다면 구조를 단순화하는 것이 낫습니다.

AgentOS를 올리면 곧 프로덕션 준비가 끝날까?

REST 엔드포인트와 스트리밍이 생겨도 인증, 권한, 속도 제한, 비밀 관리와 데이터 보존 정책은 서비스 요구에 맞게 검증해야 합니다. 세션과 메모리를 영구 저장한다면 사용자 간 데이터가 섞이지 않는지, 삭제 요청과 백업에서도 제거되는지, 도구 호출 로그에 API 키나 개인정보가 남지 않는지 확인합니다. 스테이트리스 API 프로세스와 상태 저장소의 책임도 구분해야 장애 뒤 세션을 복구할 수 있습니다.

도구 실행에는 요청별 허용 목록과 시간, 비용 상한을 두고, 외부 작업은 중복 재시도에도 한 번만 처리되도록 설계합니다. 모델 답변이 실패했을 때 HTTP 성공으로 반환하지 말고 검증 실패, 도구 오류와 사용자 취소를 구분해 관측해야 합니다. AgentOS가 제공하는 기능은 운영의 기반이지 조직의 보안 정책을 자동 완성하는 것은 아닙니다.

성능 수치는 어떤 조건에서 다시 재야 할까?

인스턴스 생성 수와 초기 메모리는 프레임워크 객체의 오버헤드를 비교하는 지표입니다. 실제 서비스에서는 모델 네트워크 지연, 데이터베이스, 도구 API와 긴 프롬프트가 더 큰 비중을 차지할 수 있습니다. 동일한 Python 버전과 기능 범위, 동시 사용자 수에서 p50, p95 지연과 최대 메모리를 측정하고, 다른 프레임워크 비교표의 조건이 같지 않다면 숫자를 직접 대입하지 않아야 합니다.

원문과 버전 확인

함께 읽으면 이해가 이어지는 글

THE END / OPSOAI

여기까지 읽었습니다

핵심 장면을 한 번 더 떠올려 보세요. 이해가 남았다면 이 책은 제 역할을 다했습니다.

다른 책 고르기
표지 1

키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.

CONTENTS

이 책의 목차

    9개 장 21 분읽는 시간