두 개의 계보, 하나의 프레임워크: AutoGen과 Semantic Kernel이 Microsoft 에이전트 프레임워크가 된 과정

Microsoft의 에이전트 프레임워크 이야기는 사실 서로 다른 문제를 해결하던 두 팀, 의견 차이로 인해 탄생한 커뮤니티 포크 (Fork), 그리고 주의를 기울이지 않으면 조용히 코드를 망가뜨릴 수 있는 패키징 위험에 관한 이야기입니다. 이 분야를 지켜봐 왔거나, 새로운 프로젝트를 위한 프레임워크를 선택하려 노력 중이라면, 여기 그 전체적인 흐름이 있습니다.

갈림길: 두 가지 문제, 두 가지 프로젝트

2023년 초까지, LLM (Large Language Model) 기반 애플리케이션을 구축하는 실질적인 과제는 아무도 깔끔하게 해결하지 못한 두 가지 별개의 문제로 나뉘어 있었습니다.

첫 번째는 엔터프라이즈 통합 (enterprise integration) 이었습니다. 적절한 의존성 주입 (dependency injection), 로깅 (logging), 텔레메트리 (telemetry), 그리고 재사용 가능한 도구 추상화 (tool abstractions)를 갖춘 기존 애플리케이션에 어떻게 LLM을 내장할 것인가 하는 문제였습니다. 두 번째는 멀티 에이전트 조정 (multi-agent coordination) 이었습니다. 사용자가 모든 오케스트레이션 (orchestration) 로직을 직접 작성하지 않고도, 어떻게 여러 전문화된 에이전트들이 협업하고, 논쟁하며, 업무를 인계하고, 목표에 수렴하도록 만들 것인가 하는 문제였습니다.

Microsoft는 결국 두 개의 별도 팀이 구축한 두 개의 별도 프로젝트를 갖게 되었으며, 각 프로젝트는 이 문제 중 하나를 해결했습니다. 이들은 결국 합쳐지기 전까지 수년간 내부적으로 경쟁했습니다.

Semantic Kernel (2023년 3월): 엔터프라이즈 SDK

Semantic Kernel은 2023년 3월 17일에 공개적으로 출시되었으며, 초기에는 C#/.NET으로 시작하여 이후 Python과 Java로 확장되었습니다. 이 프레임워크의 핵심 추상화는 Kernel 객체였습니다. 이는 플러그인 (plugins), 플래너 (planners), 메모리 (memory), 그리고 모델 커넥터 (model connectors)를 하나로 연결하는 허브 역할을 했습니다.

플러그인 (Plugins) (원래는 "스킬 (skills)"로 불림)은 LLM이 호출할 수 있는 네이티브 함수 (native functions)와 프롬프트 템플릿 (prompt templates)의 집합이었습니다. **플래너 (Planners)**는 사용자의 목표를 달성하기 위해 어떤 플러그인 함수들을 조합할지 모델에게 결정하도록 요청했습니다. 다만, Microsoft의 자체 문서가 언급하듯, 이 프레임워크는 이후 프롬프트 기반의 플래닝 (prompt-based planning)에서 네이티브 함수 호출 (native function calling) 방식으로 전환되었습니다. 이 핵심 요소 주변에는 엔터프라이즈 .NET 팀들이 기대하는 배관 작업(plumbing)들이 자리 잡고 있었습니다: 의존성 주입 (dependency injection), 필터 (filters), 텔레메트리 후크 (telemetry hooks), 그리고 벡터 스토어 (vector stores) 및 임베딩 서비스 (embedding services)에 대한 광범위한 커넥터 (connector) 지원 등이 그것입니다.

이는 진정으로 유용했습니다. 만약 기존의 엔터프라이즈 애플리케이션을 보유하고 있으면서, 아키텍처를 버리지 않고 LLM 기능을 추가하고 싶다면, Semantic Kernel은 이를 수행할 수 있는 구조화되고 테스트 가능한 방법을 제공했습니다.

하지만 Semantic Kernel이 제공하지 못한 것은 다중 에이전트 (multiple agents)에 대한 일급 시민 개념 (first-class concept)이었습니다. 커널 (Kernel)과 플래너를 결합하여 도구들을 구성할 수는 있었지만, 에이전트들이 서로 협상하거나, 실행 중간에 사람이 단계를 승인하거나, 코딩 에이전트가 결과를 리뷰 에이전트에게 전달하는 등의 과정을 위한 추상화는 없었습니다. 이후 Microsoft의 에이전트 프레임워크 개요 (Agent Framework overview)에서도 인정했듯이, Semantic Kernel은 "커넥터와 텔레메트리는 제공했지만, 다중 에이전트의 유연성은 부족했습니다."

AutoGen (2023년 8월): 프로그래밍 모델로서의 대화

AutoGen은 완전히 다른 방향에서 등장했습니다. Qingyun Wu, Gagan Bansal, Chi Wang 및 11명의 공동 저자가 작성한 기초 논문 — "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation" — 이 2023년 8월 16일 arXiv에 게시되었습니다. 이 논문의 논지는 명확했습니다: _대화 (conversation)_를 보편적인 프로그래밍 추상화 (programming abstraction)로 취급하는 것입니다.

명령형 오케스트레이션 로직 (imperative orchestration logic)을 작성하는 대신, 시스템 프롬프트 (system prompts)와 도구 (tools)를 갖춘 에이전트 (AssistantAgent, UserProxyAgent)를 정의하고, 이들을 GroupChatManager가 포함된 GroupChat에 배치하여 메시지를 교환하며 목표에 도달하게 했습니다. 코드 실행은 일급 시민 (first-class)이었습니다. UserProxyAgent는 모델이 생성한 Python 코드를 Docker 샌드박스 (sandbox)에서 실행하고 그 결과를 다시 대화에 전달할 수 있었습니다. 이 패턴은 놀라울 정도로 표현력이 풍부했습니다. 두 에이전트 간의 토론 (debate), 비평가와 코더의 루프 (critic-and-coder loops), 도구 사용 체인 (tool-use chains) 등이 모두 동일한 모델로부터 자연스럽게 도출되었습니다.

AutoGen은 프로토타이핑 (prototyping)이 쉽다는 점 덕분에 연구 커뮤니티에서 빠르게 확산되었습니다. 하지만 실제 운영 환경에서는 명확한 약점들이 있었습니다. GroupChat 매니저의 발화자 선택 (speaker-selection) 로직이 불투명했고, 동기식 실행 모델 (synchronous execution model)은 확장성이 부족했으며, 아키텍처 구조상 적절한 관찰 가능성 (observability)이나 비동기 워크플로 (async workflows)를 추가하기가 어려웠습니다.

분기 (The Fork): AG2가 AutoGen에서 분리되다

2024년 말, 기존 AutoGen 연구 저자들과 Microsoft의 제품 방향성 사이의 긴장은 임계점에 도달했습니다. 그 결과로 발생한 커뮤니티 포크 (community fork) — 논문의 주요 저자인 Chi Wang과 Qingyun Wu가 주도함 — 는 AG2가 되었으며, 초기에는 AutoGen 0.2.x 계보의 연속선상에 위치하도록 설정되었습니다. AG2는 GitHub의 ag2ai/ag2에서 운영되며, Apache 2.0 라이선스 하에 독립적으로 관리됩니다.

한편, Microsoft는 2025년 1월에 완전히 새로 작성된 AutoGen v0.4를 출시했습니다. 새로운 아키텍처는 깔끔한 3계층 API를 갖춘 비동기 이벤트 기반 액터 모델 (asynchronous, event-driven actor model)을 중심으로 구축되었습니다:

• autogen-core — 비동기 런타임 (async runtime), 메시지 전달 (message passing), 그리고 액터 프리미티브 (actor primitives)
• autogen-agentchat — v0.2에서 익숙했던 고수준의 AssistantAgent, GroupChat, 그리고 팀 추상화 (team abstractions)
• autogen-ext — 특정 모델, 도구 및 통합을 위한 확장 기능 (extensions)

이러한 계층적 설계(layered design)를 통해 사용자는 세밀한 제어(fine-grained control)를 위해 autogen-core로 내려가거나, 익숙한 대화형 API(conversational API)를 위해 autogen-agentchat에 머무를 수 있습니다. 하지만 이는 v0.2로부터의 파괴적 변경(breaking change)이었으며, 기존 AutoGen을 기반으로 구축해 온 팀들은 이제 선택해야 했습니다: Microsoft를 따라 v0.4로 갈 것인가, 아니면 원작자들을 따라 AG2로 갈 것인가.

⚠️ pip install autogen 패키징 위험 요소

더 진행하기 전에, 주의하지 않으면 맞닥뜨리게 될 구체적인 함정(gotcha)이 하나 있습니다.

PyPI 패키지 이름인 autogen은 Microsoft의 AutoGen이 아닙니다. 이는 분리(split) 이후 AG2 유지 관리자들이 등록한 커뮤니티 포크(community fork)인 AG2의 별칭(alias)입니다. 이를 설치하면 오류나 경고 없이 Microsoft의 것이 아닌 AG2의 API가 조용히 설치됩니다. 만약 Microsoft의 문서를 따르고 있다면, 디버깅하기 정말 혼란스러울 수 있는 API 불일치(API mismatch)를 경험하게 될 것입니다.

올바른 설치 명령어는 다음과 같습니다:

# Microsoft AutoGen v0.4 (agentchat layer)
pip install autogen-agentchat

...

이 문제는 실제 개발자들을 곤혹스럽게 만들었습니다. 만약 임포트(import)가 실패하거나 API가 문서와 일치하지 않는다면, 먼저 pip show autogen을 확인하십시오. 완전히 잘못된 패키지를 설치했을 가능성이 매우 높습니다. AG2 마이그레이션 가이드와 AutoGen v0.4 문서 모두 이 점을 명시적으로 언급하고 있지만, 빠르게 작업하다 보면 놓치기 쉽습니다.

Microsoft Agent Framework (2025년 10월): 통합

2025년 10월 1~2일, Microsoft는 Microsoft Agent Framework의 공개 미리보기(public preview)를 발표했습니다. 이는 PyPI에서는 agent-framework, NuGet에서는 Microsoft.Agents.AI로 제공됩니다. Microsoft 자체 문서는 이것이 무엇인지에 대해 명확히 밝히고 있습니다:

이 통합은 단순히 조직적인 결합이 아닌 아키텍처(architectural) 차원의 결합입니다. Agent Framework는 Semantic Kernel의 엔터프라이즈 기반 인프라(enterprise plumbing) — 세션 기반 상태 관리 (session-based state management), 타입 안정성 (type safety), 필터 (filters), 텔레메트리 (telemetry), 그리고 전체 커넥터 생태계 (connector ecosystem) — 를 가져와 AutoGen의 멀티 에이전트 오케스트레이션 (multi-agent orchestration) 패턴과 결합합니다. 그 토대 위에 두 선행 기술 모두에는 없었던 다음과 같은 기능들을 추가합니다:

타입 안정성이 보장되는 라우팅을 갖춘 그래프 기반 워크플로 (Graph-based workflows with type-safe routing). 에이전트는 유향 그래프 (directed graph)의 노드 (nodes)입니다. 노드 간의 전환 (transitions)은 타입이 지정되어 있어, 컴파일러 (.NET의 경우) 또는 런타임 (Python의 경우)이 새벽 2시에 발생하는 정체불명의 오류로 나타나기 전에 라우팅 오류를 잡아낼 수 있습니다.

체크포인팅 (Checkpointing) 및 재개 가능성 (resumability). 장시간 실행되는 워크플로를 영속화 (persisted)하고 재개할 수 있습니다. 이는 인간 참여형 (human-in-the-loop) 방식을 진정으로 실용적으로 만드는 기능입니다. 즉, 워크플로가 일시 중지되어 인간의 승인을 기다린 후, 정확히 멈췄던 지점부터 다시 시작할 수 있습니다.

일급 시민으로서의 인간 참여형 (First-class human-in-the-loop). UserProxyAgent라는 임시방편을 덧붙이는 대신, 프레임워크는 구성 가능한 승인 및 개입 패턴을 가진 명시적인 HumanInTheLoop 노드를 제공합니다.

통합된 관측성 (Unified observability). Semantic Kernel의 텔레메트리 훅 (telemetry hooks)과 AutoGen의 트레이싱 (tracing) 기능이 하나의 계측 레이어 (instrumentation layer)로 통합되었으며, 전반적으로 OpenTelemetry를 지원합니다.

Python SDK는 현재 프리뷰 (preview) 버전으로 사용할 수 있습니다. .NET SDK (Microsoft.Agents.AI)는 관용적인 (idiomatic) C# API를 통해 동일한 개념을 목표로 합니다.

지금 무엇을 사용해야 할까요?

현재 상황에는 세 가지 실질적인 선택지가 있습니다. 솔직한 분석은 다음과 같습니다:

Microsoft Agent Framework — 새로운 프로덕션 프로젝트를 위해, 특히 Microsoft/Azure 생태계에 있거나 엔터프라이즈 기능 (텔레메트리, 의존성 주입 (DI), 타입 안정 라우팅, 체크포인팅)이 필요한 경우에 이를 사용하십시오. 2025년 10월 기준으로 퍼블릭 프리뷰 (public preview) 상태이므로 API 변경 (churn)이 있을 수 있지만, 이것이 Microsoft가 투자하고 있는 방향입니다. 빠른 시작 (quickstart)이 시작하기에 적합한 곳입니다.

AG2 — 대화형 ConversableAgent 모델을 계속 사용하고 싶거나, 기존의 AutoGen 0.2.x 코드가 있거나, 또는 Microsoft의 로드맵 외부에서 관리되는 프레임워크를 원하는 경우 이를 사용하세요. 이는 Apache 2.0 라이선스 하에 원본 AutoGen 저자들에 의해 활발히 유지 관리되고 있으며, API가 안정적이고 커뮤니티가 활발하게 참여하고 있습니다. pip install ag2 또는 pip install autogen으로 설치할 수 있으며 — 두 명령 모두 동일한 패키지로 연결됩니다 — 하지만 ag2가 정식 명칭(canonical name)입니다.

AutoGen v0.4 — 비동기(async) 재작성은 견고한 엔지니어링 결과물이지만, 이제 Agent Framework가 공식적인 후속작으로 자리 잡았으므로 새로운 프로젝트는 아마도 그곳에서 시작하는 것이 좋을 것입니다. 이미 v0.4를 사용 중이라면 나쁜 상황은 아닙니다. 개념들이 Agent Framework와 깔끔하게 매핑되기 때문입니다. 하지만 마이그레이션(migration) 경로는 Agent Framework를 향하고 있습니다.

Semantic Kernel standalone — 여전히 유지 관리되고 있으며, 특히 .NET 환경에서 단일 에이전트(single-agent) 및 플러그인 중심의 애플리케이션에 여전히 유용합니다. 하지만 새로운 멀티 에이전트(multi-agent) 개발은 Semantic Kernel을 직접 사용하는 것이 아니라 Agent Framework로 가야 합니다.

출처: Semantic Kernel 출시 포스트 · AutoGen arXiv 논문 · Microsoft Agent Framework 개요 · AutoGen v0.4 퀵스타트 · AG2 마이그레이션 가이드 · Medium 첫인상