에이전트 프레임워크를 회사 업무에 붙이려는 개발자라면, 기능 목록보다 먼저 봐야 할 건 세 가지다. MCP 표준을 얼마나 붙일 수 있는지, 토큰·인프라 비용이 어디서 새는지, 그리고 툴 실행 권한이 어디까지 열려 있는지. 이 글은 LangGraph, CrewAI, Microsoft Agent Framework를 이 세 축으로만 자른다.
프레임워크 자체의 화려함은 도입 판단에서 후순위다. 2026년 기준으로 MCP(Model Context Protocol)는 이미 프레임워크 선택의 옵션이 아니라 기본 배선이 됐고, 자료 기준으로는 주요 파이썬 에이전트 프레임워크 대부분이 어떤 형태로든 MCP를 지원한다. 그래서 진짜 차이는 “MCP를 붙일 수 있느냐”가 아니라 “네이티브냐 커뮤니티 통합이냐”, 그리고 “그 툴 실행 경계를 누가 지키느냐”에서 갈린다.
세 프레임워크, 성격부터 다르다
LangGraph는 그래프 기반으로 상태와 흐름을 명시적으로 그리는 방식이다. 자료 기준으로 Uber, LinkedIn, Klarna 같은 곳이 1년 넘게 프로덕션에서 돌렸다고 언급되며, 2026년 시점에서 프로덕션 안정성 측면의 기본값으로 평가받는다. 대신 학습 곡선이 가장 가파르다. 그래프 사고에 익숙하지 않은 팀은 1~2주는 잡아야 실전 워크플로가 나온다는 지적이 반복된다.
CrewAI는 정반대 지점에 있다. “역할을 가진 에이전트들”이라는 직관적 모델이라, 아이디어에서 프로토타입까지 가장 빠르게 도달한다. MCP와 A2A(Agent-to-Agent) 프로토콜을 네이티브로 지원하는 점도 상호운용성 관점에서는 강점이다. 다만 자료 기준으로는 복잡한 프로젝트에서 6~12개월 지점에 한계가 드러난다는 관찰이 붙는다. 빠른 시작과 장기 확장성이 맞바꿔지는 구조다.
Microsoft Agent Framework 1.0은 AutoGen과 Semantic Kernel을 합친 결과물로, 2026년 4월 GA에 도달했다고 정리된다. .NET과 파이썬을 함께 지원하고, YAML 에이전트 정의, 체크포인팅이 있는 그래프 워크플로, MCP·A2A 네이티브 통합을 내세운다. 이미 Microsoft 스택(Azure, .NET) 위에 있는 팀이라면 도입 마찰이 가장 적은 선택지가 된다.
비교표: 도입 판단에 필요한 것만
| 항목 | LangGraph | CrewAI | Microsoft Agent Framework 1.0 |
|---|---|---|---|
| MCP 지원 | 통합/커뮤니티 경로 중심 | 네이티브 (MCP+A2A) | 네이티브 (MCP+A2A) |
| 성숙도 | 프로덕션 레퍼런스 다수 | 커뮤니티 규모 큼 | 2026-04 GA, 신규 통합 스택 |
| 학습 곡선 | 가파름 (1~2주) | 가장 완만 | 중간, MS 스택이면 낮음 |
| 강점 | 상태 관리·HITL·관측성 | 빠른 프로토타입·역할 모델 | .NET/파이썬 통합·엔터프라이즈 |
| 토큰 비용 레버 | Deep Agents 등 상위 추상화로 절감 여지 | 멀티에이전트 호출 누적 주의 | 워크플로 체크포인트로 재실행 절감 |
| 적합 상황 | 복잡한 그래프·승인 게이트 | 3~5개 에이전트 중간 난이도 | 기존 MS 인프라 위 확장 |
표는 선택을 대신해주지 않는다. 도입한다면 먼저 볼 부분은 “우리 팀이 지금 그래프 사고에 투자할 여유가 있는가”, 그리고 “이미 어떤 클라우드·언어 스택에 묶여 있는가”다. 이 두 질문이 세 후보 중 둘을 먼저 탈락시킨다.
비용은 라이선스가 아니라 토큰·재실행에서 샌다
세 프레임워크 모두 오픈소스라 라이선스 비용은 논점이 아니다. 실제 비용은 토큰 소비와 인프라에서 발생한다. 멀티에이전트 구조는 에이전트끼리 주고받는 메시지가 그대로 토큰이 되기 때문에, 에이전트 수가 늘면 호출당 컨텍스트가 곱셈으로 커진다. CrewAI처럼 역할 기반으로 에이전트를 늘리기 쉬운 구조는 이 지점을 방심하면 비용이 조용히 불어난다.
LangGraph 쪽에서는 2026년에 나온 상위 추상화(Deep Agents)가 기본 에이전트 턴의 입력 토큰 소비를 상당폭 줄였다는 자료가 있다(수치는 벤더 발표 기준이라 자기 워크로드로 재측정 권장). 핵심은 프레임워크 이름이 아니라, 반복 호출과 상태 저장/복원을 어떻게 설계하느냐가 비용을 좌우한다는 점이다. 체크포인팅은 실패 지점부터 재실행하게 해줘서 전체 재실행 대비 토큰을 아끼는 방향으로 쓸 수 있다.
인프라 비용은 관측성 도구와 샌드박스에서 붙는다. LangSmith 같은 관측 스택, MCP 서버를 격리 실행할 컨테이너, egress 통제용 네트워크 정책은 전부 운영 비용이다. 자료 기준으로는 이 관측·격리 계층을 생략한 팀일수록 사고가 났을 때 원인 추적 비용이 더 크게 튄다.
보안 경계가 진짜 갈림길이다
기능이 비슷해지는 지금, 실무 도입에서 가장 크게 갈리는 건 보안이다. 2026년 보안 자료들이 공통으로 지적하는 위험은 “과도한 권한(excessive agency)”이다. 각 에이전트가 넓은 권한을 쥐고 있으면, 조작된 지시 하나가 곧바로 파괴적 행동으로 이어질 수 있는데 그 사이를 검사하는 장치가 없는 경우가 많다는 것이다.
두 번째 위험은 앰비언트 권한 누수다. 에이전트는 실행 환경에서 자격증명, 네트워크 접근, 실행 권한을 그대로 물려받고, 그 권한이 툴 호출을 타고 전파된다. 샌드박스 안에서 에이전트가 돌더라도 그 에이전트가 트리거하는 CI/CD 워크플로는 더 넓은 권한 환경에서 실행돼, 결과적으로 권한 증폭 통로가 된다는 지적이 있다.
MCP 자체의 위험도 별도로 봐야 한다. OWASP MCP Top 10과 여러 벤더 자료가 공통으로 짚는 것이 툴 포이즈닝이다. 공격자가 툴 설명(description)이나 스키마 안에 악성 지시를 숨겨서 모델이 툴을 오용하거나 데이터를 유출하도록 유도하는 방식이다. rug pull(신뢰받던 서버가 나중에 악성으로 바뀜), 툴 섀도잉 같은 변형도 함께 언급된다. MCP를 붙인다는 건 편의만이 아니라 이 공격면을 함께 들여온다는 뜻이다.
실무 도입 전 보안 체크리스트
아래는 프레임워크와 무관하게, MCP 기반 에이전트를 업무에 붙이기 전에 확인할 항목이다. 자료 기준의 baseline 통제를 실무 순서로 정리했다.
- 최소 권한으로 시작한다. 처음엔 discovery 또는 read-only 스코프만 주고, 필요할 때만 권한을 추가한다. 시간 제한(time-bound) 권한을 기본값으로 둔다.
- 파괴적·외부 노출·금전 관련 툴은 명시적 승인을 강제한다. 메일 발송, 채팅 게시, 삭제, 결제, 이체 같은 행동은 자동 실행 금지.
- MCP 서버를 격리 샌드박스에서 실행한다. 컨테이너 격리와 egress 네트워크 정책을 함께 건다.
- 모든 툴 설명·스키마를 사용 전 검수한다. 서버를 특정 버전에 핀 고정하고, 재검토 없는 자동 업데이트를 막는다.
- 시크릿을 코드·로그에서 분리한다. 환경변수·시크릿 매니저를 쓰고, 툴 인자와 로그에 민감정보가 새지 않는지 확인한다.
- 보안 이벤트를 전부 로깅한다. 툴 discovery, 권한 요청, 툴 호출을 사용자·클라이언트·서버·툴명·스코프·타임스탬프·결과까지 남긴다.
- 툴 인자를 검증한다. 서명된 capability manifest, 필드 마스킹 같은 통제로 입력을 신뢰하지 않는다.
이 허브의 상위 운영 판단은 Codex QC 스킬 에이전트 운영 글에서 이어진다. 프레임워크 선택 이후 실제 에이전트 운영·검수 흐름은 그쪽을 함께 보는 걸 권한다.
실수·함정 TOP 5
첫째, MCP 지원 여부만 보고 고른다. 네이티브냐 커뮤니티 통합이냐, 그리고 그 위에 승인 게이트를 걸 수 있느냐가 실제 차이다. 지원 체크박스만 보면 나중에 보안 계층에서 막힌다.
둘째, 프로토타입 속도로 프로덕션을 판단한다. CrewAI로 하루 만에 데모를 만들었다고 6개월 뒤 복잡도까지 감당된다는 뜻은 아니다. 자료 기준으로 복잡 프로젝트의 한계 구간이 따로 언급된다.
셋째, 권한을 넓게 열고 시작한다. “일단 다 되게 해놓고 나중에 조인다”는 접근은 앰비언트 권한 누수의 정확한 원인이다. 좁게 시작해서 넓히는 방향이 맞다.
넷째, 관측성과 로깅을 나중으로 미룬다. 사고는 원인 추적이 되어야 수습되는데, 로그가 없으면 어떤 툴 호출이 문제였는지조차 재구성이 안 된다.
다섯째, 에이전트를 안 써도 되는 문제에 에이전트를 붙인다. 입력이 정해져 있고 분기가 단순한 작업은 스크립트나 단일 LLM 호출이 더 싸고 안전하다. 멀티에이전트는 상태·분기·도구 사용이 실제로 복잡할 때만 값을 한다.
언제 안 써도 되는지
에이전트 프레임워크 도입이 늘 정답은 아니다. 도입한다면 먼저 볼 부분은 “이 작업이 단일 프롬프트로 안 되는 이유가 무엇인가”다. 결정론적 파이프라인(고정된 순서, 명확한 입출력)이면 프레임워크 대신 워크플로 코드가 더 예측 가능하고 디버깅도 쉽다. 자료 기준으로도 복잡한 그래프·루프·승인 게이트가 실제로 필요할 때 LangGraph 같은 도구가 값을 한다고 정리된다.
반대로 조건 분기, 병렬 브랜치, 사람 개입(HITL), 여러 툴을 상황에 따라 다르게 쓰는 작업이라면 프레임워크가 관리 비용을 줄여준다. 판단 기준은 결국 하나다. 프레임워크가 없애주는 복잡도가 프레임워크가 새로 들여오는 보안·비용 부담보다 큰가. 이게 안 되면 도입은 미루는 게 맞다.
FAQ
Q. 셋 중 하나만 고른다면 기본값은 무엇인가? 프로덕션 안정성과 복잡한 상태 관리가 우선이면 LangGraph, 빠른 프로토타입과 낮은 학습 곡선이 우선이면 CrewAI, 이미 .NET/Azure 스택 위에 있으면 Microsoft Agent Framework가 마찰이 가장 적다. 절대적 우열이 아니라 팀의 스택과 복잡도가 정한다.
Q. MCP를 꼭 써야 하나? 필수는 아니다. 다만 2026년 기준으로 외부 시스템·툴 연결의 사실상 표준 커넥터가 됐다. 여러 툴·서버를 붙일수록 MCP 지원은 이득이지만, 툴 포이즈닝 같은 공격면도 함께 들어온다는 점을 감안해야 한다.
Q. 오픈소스면 비용이 안 드나? 라이선스는 무료지만 토큰과 인프라가 실제 비용이다. 멀티에이전트 메시지 교환, 관측성 스택, MCP 서버 격리 컨테이너가 운영비를 만든다. 도입 전 자기 워크로드로 토큰을 재측정하는 게 안전하다.
Q. 가장 흔한 보안 사고 유형은? 자료 기준으로는 과도한 권한과 앰비언트 권한 누수, 그리고 MCP 툴 설명·스키마를 통한 툴 포이즈닝이 반복 지적된다. 최소 권한·명시적 승인·툴 설명 검수 세 가지가 기본 방어선이다.
Q. 소규모 팀이 지금 바로 시작하려면? read-only 스코프의 MCP 서버 하나를 격리 컨테이너에서 붙이고, 파괴적 툴은 전부 수동 승인으로 두고, 로깅부터 켠 뒤 CrewAI나 LangGraph 중 팀 학습 여유에 맞는 쪽으로 프로토타입을 시작하는 순서를 권한다.
Q. 프레임워크를 나중에 갈아탈 수 있나? 에이전트 로직을 프레임워크 특화 API에 깊게 묶지 않고, 툴·프롬프트·상태 정의를 분리해두면 이전 비용이 줄어든다. MCP를 공통 툴 계층으로 두면 프레임워크 교체 시 툴 자산은 재사용하기 쉬워진다.
공식 출처
- OWASP MCP Top 10 (Model Context Protocol 보안 분류) — Cycode 정리
- MCP Security Risks, Real Incidents & Controls — Checkmarx
- Agentic MCP Security Best Practices — Cloud Security Alliance
- Microsoft Agent Framework 1.0 vs LangGraph vs CrewAI (2026) — Karmesh Gupta
- Security Risks in Tool-Enabled AI Agents (IEEE COMPSAC 2026 preprint) — arXiv
관련 글
이 글은 공개 자료와 벤더 발표 기준으로 정리한 도입 판단용 비교이며, 특정 제품 보증이나 보안 감사를 대체하지 않는다. 수치와 성숙도 평가는 자기 워크로드로 재검증하는 것을 권한다.