AI 에이전트 프레임워크 선택 가이드 2026: SDK 이름보다 실행 경계·상태·승인 루프를 먼저 고정해야 하는 이유

발행일: 2026-06-20 | 카테고리: AI 활용법

1. 한 줄 문제 정의

핵심 한 줄: 2026년의 에이전트 도입 실패는 “어떤 모델이 더 똑똑한가”보다 “어떤 업무를 어디까지 자동 실행하게 할 것인가”를 정하지 못해서 생깁니다.

AI 에이전트 프레임워크가 빠르게 늘었습니다. OpenAI Agents SDK는 도구 호출과 handoff를 단순하게 시작하게 해주고, Microsoft Agent Framework 1.0은 .NET·Python 기반 엔터프라이즈 오케스트레이션을 강조합니다. Google ADK는 Google Cloud와 Gemini 생태계에서 agent scaffold, 평가, 배포 흐름을 연결하고, LangGraph는 오래 도는 상태ful 워크플로와 human-in-the-loop에 강합니다.

문제는 선택지가 많아졌다는 사실 자체가 아닙니다. 팀이 “우리는 무엇을 자동화하려는가”, “실패했을 때 어디서 멈출 것인가”, “사람 승인은 어느 단계에 들어갈 것인가”, “상태와 로그는 누가 책임질 것인가”를 정하지 않은 채 SDK부터 고르는 것이 문제입니다.

이 글은 사내 업무 자동화, 고객지원, 데이터 분석, 코딩 보조, 문서 처리 에이전트를 실제 제품이나 운영 도구로 붙이려는 개발자·PM·자동화 담당자를 위한 글입니다. 단순 데모 챗봇 제작법이 아니라, 프레임워크 선택 전에 고정해야 할 운영 기준을 다룹니다.

2. 먼저 결론

핵심 한 줄: 처음 고를 기준은 인기 순위가 아니라 실행 시간, 상태 복구, 사람 승인, 조직 스택입니다.

• 빠른 제품 실험: OpenAI Agents SDK처럼 시작 비용이 낮고 tracing·guardrail·handoff가 연결된 SDK가 좋습니다.
• Microsoft/Azure 중심 조직: Microsoft Agent Framework가 자연스럽습니다. 2026년 4월 3일 1.0이 공개됐고, .NET·Python, Semantic Kernel·AutoGen 계열, MCP·A2A 방향을 함께 봅니다.
• Google Cloud/Gemini 중심 조직: Google ADK가 맞습니다. Java 1.0.0 발표와 ADK 사이트 기준으로 scaffold, build, test, evaluate, deploy 흐름을 한 개발 경험으로 묶으려는 방향이 뚜렷합니다.
• 상태가 오래 유지되는 복잡한 업무: LangGraph가 유리합니다. durable execution, streaming, human-in-the-loop처럼 실패 후 재개가 중요한 능력을 전면에 둡니다.

제 판단은 이렇습니다. “어떤 프레임워크가 제일 좋나요?”라는 질문은 너무 늦은 질문입니다. 먼저 업무를 세 종류로 나누십시오. 10초 안에 끝나는 대화형 업무, 10분 이상 걸리는 장기 업무, 돈·권한·외부 발송이 걸린 승인형 업무입니다. 이 분류가 끝나면 프레임워크 선택은 훨씬 쉬워집니다.

3. 핵심 구조 분해

핵심 한 줄: 에이전트 프레임워크는 모델 래퍼가 아니라 모델, 도구, 상태, 승인, 관측성을 묶는 실행 껍질입니다.

초보 개발자 기준으로 에이전트를 “혼자 생각하고 도구를 쓰는 함수”라고만 이해하면 곧 막힙니다. 실제 운영에서는 아래 다섯 층을 봐야 합니다.

1. 모델 호출 층: OpenAI, Azure OpenAI, Gemini, Anthropic, 로컬 모델 같은 추론 공급자를 연결합니다. 여기까지만 있으면 똑똑한 함수 호출 도우미에 가깝습니다.
2. 도구 연결 층: 검색, DB, 파일, 브라우저, 사내 API, MCP 서버를 호출합니다. 위험한 동작은 여기서 시작됩니다.
3. 상태와 메모리 층: 대화 이력, 작업 중간 결과, 체크포인트, 장기 기억을 보관합니다. 장기 작업은 이 층이 없으면 실패 후 처음부터 다시 시작합니다.
4. 오케스트레이션 층: 여러 에이전트나 단계를 순서형, 병렬형, 조건 분기형, handoff 방식으로 연결합니다.
5. 운영 통제 층: tracing, 평가, 승인, rate limit, 권한, 감사 로그, 배포 전략을 담당합니다.

이 다섯 층 중 어떤 층이 가장 중요한지는 업무에 따라 달라집니다. 고객지원 답변 초안은 모델 호출과 도구 연결이 중요하지만, 환불 승인 자동화는 승인과 감사 로그가 더 중요합니다. 코딩 에이전트는 파일 시스템과 shell 권한을 다루기 때문에 샌드박스와 diff 검토가 핵심입니다.

4. 설계 의도 해설

핵심 한 줄: 2026년 프레임워크 경쟁은 “프롬프트를 쉽게 쓰게 해준다”에서 “업무 실행을 안전하게 오래 끌고 간다”로 옮겨갔습니다.

초기 에이전트 도구는 대부분 “LLM이 tool call을 잘 하게 해주는 얇은 래퍼”였습니다. 그러나 실무 업무는 한 번의 tool call로 끝나지 않습니다. 문서 100개를 읽고, 데이터베이스를 조회하고, 중간 결과를 저장하고, 사람에게 승인받고, 실패하면 재시도하고, 마지막에 외부 시스템에 기록해야 합니다.

Microsoft Agent Framework 1.0 발표가 production-ready, stable APIs, long-term support, multi-agent orchestration을 강조한 이유도 여기에 있습니다. Google ADK가 scaffold, test, evaluate, deploy 흐름을 강조하는 이유도 같습니다. LangGraph가 durable execution과 human-in-the-loop을 전면에 두는 것도 같은 방향입니다.

즉 프레임워크 선택은 “개발자가 코드를 얼마나 적게 쓰는가”보다 “팀이 운영 책임을 어디에 둘 것인가”의 문제입니다. 서버리스 함수 하나로 충분한 업무도 있고, 큐·워크플로 엔진·상태 저장소·승인 UI가 필요한 업무도 있습니다. 이 차이를 무시하면 좋은 SDK를 써도 운영은 불안정해집니다.

5. 근거 및 비교

핵심 한 줄: 비교 기준은 기능 수가 아니라 업무 유형과 실패 비용입니다.

Microsoft는 2026년 4월 3일 Agent Framework 1.0을 발표하며 .NET과 Python의 stable API, long-term support, multi-provider model support, A2A와 MCP를 통한 상호운용성을 강조했습니다. 같은 문서에서 graph-based workflow, checkpointing, hydration, human-in-the-loop approvals도 언급합니다.

Google은 ADK for Java 1.0.0을 발표했고, ADK 사이트는 agent를 scaffold, build, test, evaluate, deploy하는 개발 흐름을 내세웁니다. LangGraph 문서는 durable execution, streaming, human-in-the-loop을 핵심 능력으로 설명합니다. 이 셋의 공통점은 단순 prompt helper가 아니라 운영 가능한 실행 모델을 강조한다는 점입니다.

6. 실제 동작 흐름 / 단계별 실행 방법

핵심 한 줄: 프레임워크를 고르기 전 2시간짜리 선택 워크숍을 먼저 하십시오.

1. 업무 후보를 한 문장으로 씁니다.
   예: “고객 문의를 읽고 주문 상태를 조회한 뒤 답변 초안을 작성한다.” 업무가 한 문장으로 안 쓰이면 자동화 범위가 아직 큽니다.
2. 실행 시간을 표시합니다.
   10초 미만, 10초~10분, 10분 이상으로 나눕니다. 10분 이상이면 durable execution 또는 외부 워크플로 엔진이 필요할 가능성이 큽니다.
3. 도구 위험도를 표시합니다.
   읽기 전용, 내부 쓰기, 외부 발송, 결제·삭제·권한 변경으로 나눕니다. 외부 발송 이상이면 사람 승인 또는 정책 엔진이 기본값입니다.
4. 상태 복구 기준을 씁니다.
   실패 시 처음부터 다시 해도 되는지, 중간 단계부터 재개해야 하는지 정합니다. 재개가 필요하면 checkpoint가 선택 기준이 됩니다.
5. 평가 기준을 숫자로 씁니다.
   예: 답변 정확도 90% 이상, 출처 포함률 95% 이상, 승인 없는 외부 발송 0건, 실패 후 재개 성공률 98% 이상.

# 선택 매트릭스 예시
workflow: 고객 문의 답변 초안
runtime: 10초~2분
tools: 주문 조회(read-only), CRM 메모(write-internal)
human_gate: 외부 이메일 발송 전 승인 필수
state: 문의 ID 기준으로 재시도 가능
eval: 출처 포함률 95%, 잘못된 주문 상태 0건
fit: OpenAI Agents SDK 또는 Google ADK로 시작 가능, 발송 승인은 별도 UI 필요

이 매트릭스가 있으면 “요즘 뜨는 프레임워크” 논쟁이 줄어듭니다. 팀은 도구 이름이 아니라 업무 요구와 맞춰 선택하게 됩니다.

7. 실수/함정(Pitfalls)

핵심 한 줄: 에이전트 도입의 위험은 모델 환각보다 권한, 상태, 승인 누락에서 더 자주 터집니다.

1. 함정: 데모 성공을 운영 가능성으로 착각한다.
   예방: 데모에는 항상 실패 케이스 10개, 재시도 3회, 승인 거절 3회를 넣습니다.
   복구: 실제 로그에서 실패 유형을 분류하고 prompt 수정이 아니라 상태·도구·승인 경계를 먼저 고칩니다.
2. 함정: tool 권한을 너무 넓게 준다.
   예방: 읽기 도구와 쓰기 도구를 분리하고, 외부 발송·삭제·결제는 human gate 뒤에 둡니다.
   복구: tool 호출 로그를 기준으로 위험 도구를 임시 차단하고 최소 권한 토큰으로 재발급합니다.
3. 함정: 상태 저장 없이 장기 작업을 돌린다.
   예방: 10분 이상 작업은 checkpoint, job ID, 재개 가능한 step 이름을 필수로 둡니다.
   복구: 실패한 작업을 처음부터 재실행하지 말고 입력, 중간 산출물, tool 결과를 분리 저장하도록 바꿉니다.
4. 함정: 프레임워크가 평가까지 알아서 해준다고 믿는다.
   예방: 업무별 golden set, 금지 행동, 성공 기준, 회귀 테스트를 따로 둡니다.
   복구: 사고가 난 답변을 eval case로 승격하고 다음 배포 전 반드시 통과시킵니다.

8. 강점과 한계

핵심 한 줄: 에이전트 프레임워크는 반복 실행과 관측성을 빠르게 만들지만, 업무 책임과 권한 설계를 대신하지는 않습니다.

강점은 분명합니다. 첫째, tool call, handoff, streaming, tracing 같은 반복 구현을 줄입니다. 둘째, 여러 agent를 같은 실행 단위로 묶을 수 있습니다. 셋째, 사람이 중간에 개입하는 구조를 코드로 표현하기 쉬워집니다. 넷째, 평가와 로그를 붙이기 쉬워 배포 후 개선 루프를 만들 수 있습니다.

한계도 분명합니다. 프레임워크는 우리 회사의 환불 정책, 고객정보 접근권한, 법무 검토 기준, 브랜드 톤, 장애 대응 SLA를 모릅니다. 이 기준을 코드와 문서로 주지 않으면 에이전트는 “그럴듯한 실행”을 할 뿐입니다.

또 하나의 한계는 lock-in입니다. 특정 프레임워크의 memory, workflow, hosted runtime을 깊게 쓰면 나중에 바꾸기 어렵습니다. 그래서 처음부터 모든 것을 프레임워크 내부 객체로 넣기보다, 업무 상태와 감사 로그는 별도 저장소에 남기는 편이 안전합니다.

9. 더 깊게 공부할 포인트

핵심 한 줄: 다음 학습 순서는 SDK 문법이 아니라 workflow, checkpoint, approval, eval, telemetry입니다.

• OpenAI Agents SDK: agent, tools, handoffs, guardrails, tracing 개념을 먼저 확인합니다. 작은 제품 실험의 기본기를 잡는 데 좋습니다.
• Microsoft Agent Framework: 1.0 발표와 Learn 문서에서 workflow, middleware, memory, checkpoint, multi-agent orchestration을 봅니다.
• Google ADK: ADK 사이트와 Java 1.0.0 발표를 보고 scaffold, evaluate, deploy가 어떻게 연결되는지 확인합니다.
• LangGraph: durable execution, streaming, human-in-the-loop, state graph를 살펴봅니다. 장기 업무를 다룰 때 핵심입니다.
• 공통 운영 지식: OpenTelemetry, job queue, idempotency key, replay log, RBAC, audit log, eval dataset을 함께 공부해야 합니다.

10. 실행 체크리스트 + 작성자 관점

핵심 한 줄: 저는 에이전트 프레임워크 선택을 “SDK 비교”가 아니라 “업무 실행 계약서 작성”으로 시작해야 한다고 봅니다.

• 자동화할 업무가 한 문장으로 정의되어 있다.
• 실행 시간이 10초 미만, 10초~10분, 10분 이상 중 하나로 분류되어 있다.
• tool 권한이 읽기, 내부 쓰기, 외부 발송, 결제·삭제·권한 변경으로 나뉘어 있다.
• 사람 승인이 필요한 단계와 자동 실행 가능한 단계가 분리되어 있다.
• 실패 후 처음부터 재실행할지, 중간부터 재개할지 기준이 있다.
• trace ID, job ID, 사용자 ID, tool 호출 로그가 감사 가능하게 남는다.
• golden set과 금지 행동 목록으로 배포 전 회귀 평가를 돌린다.
• 프레임워크 내부 상태와 별개로 핵심 업무 결과는 별도 저장소에 남긴다.

Definition of Done: 대표 업무 3개에서 에이전트가 실패·승인 거절·재시도·권한 부족 상황을 모두 로그로 남기고, 사람 승인 없는 외부 발송 0건을 유지하며, 실패 후 재개 기준을 95% 이상 만족하면 1차 도입 완료로 봅니다.

제 추천: 새 팀은 OpenAI Agents SDK나 Google ADK처럼 시작 비용이 낮은 도구로 작게 검증하고, 장기 상태와 승인 흐름이 커지면 LangGraph나 기존 워크플로 엔진을 붙이는 식으로 넓히는 편이 좋습니다. Microsoft 생태계가 강한 조직은 Agent Framework 1.0을 바로 후보에 올리십시오. 반대로 단순 FAQ 챗봇이라면 무거운 multi-agent framework보다 검색 품질과 답변 평가부터 고치는 것이 더 낫습니다.

11. 참고자료

• OpenAI Developers - Agents SDK Guide (확인일: 2026-06-20)
• Microsoft Agent Framework Version 1.0 (발행일: 2026-04-03, 확인일: 2026-06-20)
• Microsoft Learn - Agent Framework Overview (확인일: 2026-06-20)
• Microsoft Agent Framework at BUILD 2026 (발행일: 2026-06, 확인일: 2026-06-20)
• Google Agent Development Kit (확인일: 2026-06-20)
• Google Developers Blog - ADK for Java 1.0.0 (발행일: 2026-04, 확인일: 2026-06-20)
• LangGraph Overview (확인일: 2026-06-20)