OpenAI Agents SDK를 이용한 멀티 에이전트 개발

2025년 06월 25일 4 분 소요

OpenAI Agents SDK는 이전에 실험적으로 개발했던 Swarm에서 업그레이드 버전으로 에이전트 기반 AI 애플리케이션을 가볍고 사용하기 쉬운 패키지로 구축할 수 있도록 해 준다. 특히, 불필요한 추상화를 최소화한 구조로 Agents, Handoffs, Guardrails 로 구성되어 있고, 강력한 멀티 에이전트 워크플로우 구축용 프레임워크이다.

특정 제공 업체에 종속되지 않으며, OpenAI의 Responses 및 Chat Completions API 뿐만 아니라 100 개 이상의 다양한 LLM도 지원한다. 한편, OpenAI Multi-Agents SDK는 OpenAI가 실험적으로 개발 중인 멀티 에이전트 시스템 프레임워크로, 다양한 AI 에이전트들이 협업하여 복잡한 작업을 수행할 수 있도록 설계된 SDK이다. 따라서, 이번 노트에서는 그동안 OpenAI Agents SDK를 사용하면서 느낀 점을 한번 정리해보겠다.

1. 멀티 에이전트 SDK의 목적

하나의 강력한 AI가 아닌, 여러 협력하는 AI가 함께 문제를 해결하도록 만드는 것.
- 여러 개의 특화된 AI 에이전트가 서로 소통하고 조정하며 작업을 분할하여 수행
- 복잡한 문제 해결을 위한 조율(Coordinator) 중심의 설계
- 실시간 상호작용, 멀티턴 의사결정, 역할 기반 협업 등 지원

2. 주요 구성 요소

구성 요소	설명
Agent	독립적인 행동 단위를 가진 에이전트. 특정 역할(예: 분석, 탐색, 요약 등)을 담당
Coordinator (Orchestrator)	전체 작업의 흐름을 관리하며, 어떤 에이전트가 어떤 순서로 호출될지 결정
Message Passing	에이전트 간 커뮤니케이션 지원 (텍스트, 명령, 상태 등 주고받음)
Memory / Context Sharing	에이전트 간 공유되는 상태 정보 또는 결과 저장소
Tools / Functions	각 에이전트가 활용할 수 있는 외부 기능 (예: 웹 검색, 코드 실행 등)

3. Deep Research 실행 데모

데모 동영상 설명
- “NVIDIA H200과 B200에 대한 사양과 특성, 장단점을 비교하는 테이블을 작성”하라고 프롬프트 명령을 내렸더니, 자동적으로 에이전트 시스템이 검색과 리포트를 한글로 생성하는 모습을 볼 수 있음.
- 무료 검색 도구인 DuckDuckGo 검색 엔진을 그대로 사용했고, 첫 버전에서 랙이 발생이 발생하는 버그(?)를 잡았음.
- PDF 파일로 저장하는 것을 markdown 파일 저장하는 것으로 변경했음. 그 이유는 두 개의 기능을 비교하는 테이블 작성 시 PDF에서 너무 까다롭고 복잡하기 때문.
에이전트 내부 동작 원리
- search_agent: 사용자가 명령한 주어진 질문 또는 쿼리에 대해 외부 소스(웹, 문서 등)를 검색하여 관련 정보를 수집하는 역할
- query_agent: 사용자의 질문을 구체적이고 실행 가능한 서브 쿼리(sub-queries)로 분해 역할
- synthesis_agent: 수집된 정보를 종합하여 최종적인 응답 또는 보고서를 생성하는 역할

4. 멀티 에이전트 워크플로우

멀티 에이전트 워크플로 패턴
- 도구로서의 에이전트(agents-as-tools) 방식: 오케스트레이터(Orchestrator)-서브에이전트(Subagent) 패턴
- 핸드오프(handoffs) 방식: 에이전트들이 서로에게 제어 권한을 넘겨주는 방식
DuckDuckGo 사용 시 지연(latency) 처리 방식
- 메서드나 외부 API 호출 코드 보다 검색은 OpenAI function-calling 기반 tools 호출을 통해 처리되는 비동기(async) 구조
- 지연 시간(latency)은 비동기 처리로 완화되며, 검색 결과를 병렬적으로 가져올 수 있도록 설계되어 있음.
- DuckDuckGo가 명시적으로 쓰이지 않았으며, 아마도 OpenAI의 자체 검색 기능이나 외부 검색 API가 tool_calling을 통해 추상화되어 있을 가능성이 큼.
한국어 외 다른 언어 처리
- 사용자 프롬프트의 쿼리를 생성할 때, 언어에 대한 명시적 처리 하지 않음
  - 사용자 프롬프트에서 “한글 리포트를 작성해줘” 라고 지시 명령 -> GPT-4o-mini 모델은 모델은 기본적으로 OpenAI API 기반으로 추정되며, multilingual capability는 모델 자체에 의존하기 때문.
  - 언어에 대한 명시적 처리 로직은 없음, 즉 한국어 외 언어를 다루는 것은 기본적으로 LLM(OpenAI)의 다국어 처리 능력에 전적으로 의존하고 있음.
- 사용자의 질문이 어떤 언어로 들어오든, LLM이 그에 맞춰 추론하도록 설계되어 있음.

agents-as-tools → handoff 방식 전환 시 성능 및 유지보수성 영향

query_agent, search_agent, follow_up_agent, synthesis_agent를 함수처럼 호출함. → 이는 central orchestrator (오케스트레이터) 구조로, 각 에이전트를 도구처럼 다룸.
예상되는 변화 및 영향 (handoff 방식으로 전환 시)

항목	변화	영향
구조	제어 흐름이 한 에이전트에서 다른 에이전트로 직접 이동	더 동적인 구조 가능, 단 디버깅 어려워짐
성능	일부 병렬 처리 어려움, 직렬적인 흐름 가능성 증가	오케스트레이터 방식보다 지연 증가 가능
유지보수성	흐름 추적 어려움: “누가 다음 에이전트 호출하는가?”	코드 복잡도 증가, 문서화 중요
유연성	상황에 따라 에이전트 흐름을 유연하게 바꿀 수 있음	고급 제어 가능하나, 설계 난이도 증가

5. 멀티 에이전트 개발 시 주의사항

에이전트 간의 역할 충돌 및 중복
- 여러 에이전트가 비슷한 기능을 수행하게 되면, 혼란을 일으키고 결과가 비효율적으로 될 수 있음
- 명확한 역할 분담이 필수: 각 에이전트의 책임 범위와 입력/출력 정의를 분명히 해야 함
의사소통 실패 / 컨텍스트 전달 부족
- 하나의 에이전트가 수집한 정보를 다른 에이전트에 잘 전달하지 않으면, 전체 시스템이 어긋남
- 해결책
  - 통일된 컨텍스트 객체 사용
  - 에이전트 간 명시적 인터페이스 설계
  - 필요 시 상태(state) 공유 구조 설계
무한 루프 또는 불필요한 반복
계속 “추가 조사 필요”라고 판단 → 끝나지 않는 반복 발생
해결책
- 최대 반복 횟수 제한 (max_iterations)
- 중복 정보 탐지 로직 삽입
- 정보 포괄률(coverage score) 기반 종료 조건 사용
정보 왜곡 및 누락
- 에이전트 간 정보가 잘못 전달되면 최종 리포트를 모아서 정리해주는 agent 응답이 왜곡될 수 있음
- 해결책
  - 중간 요약(logs or summaries) 보존
  - 정보 출처 추적 (source tracing)
에이전트 간 지연 및 성능 저하
- 각 에이전트가 LLM 호출을 포함하면 전체 응답 속도가 느려질 수 있음
- 해결책
  - 병렬 처리 가능성 탐색 (async 키워드 구조)
  - 캐싱 또는 이전 결과 재사용
Hand-off vs. Tools 기반 혼용 시 혼란
- handoff 방식과 agents-as-tools 방식이 섞이면 흐름 추적이 어려워짐
- 한 워크플로우 내에서는 일관된 구조를 유지하는 것이 좋음

6. 개발 시 점검 사항

체크포인트	질문
역할 정의	각 에이전트는 무엇을 책임지는가?
입력/출력	어떤 데이터를 주고받는가?
종료 조건	언제 멈추는가?
상태 관리	정보를 어디에 저장하고 공유하는가?
오류 처리	예상치 못한 응답이 오면 어떻게 대응하는가?

7. 차기 버전 고려

상용 Bing (Azure Search) 이나 Google Search 로 사용
레거시 RDB 검색 또는 RAG로 비정형 데이터 시스템과 연동
MCP 서버와의 연동으로 외부 API 사용 검토

Twitter Facebook LinkedIn