[AI Frontier] AI 에이전트 프레임워크 비교: OpenClaw, Hermes, 그리고 실무자가 봐야 할 도구들

[AI Frontier]

AI 에이전트 프레임워크를 고르는 일은 도구 취향의 문제가 아닙니다. 모델에게 무엇을 맡길지, 어디서 멈추게 할지, 누가 책임질지를 정하는 운영 설계의 문제입니다.

Image generated by OpenAI

새로운 개발 도구가 계속 늘어나는 것처럼 보이지만, 실제로는 질문이 바뀌고 있습니다. “어떤 모델이 더 똑똑한가”보다 “그 모델이 우리 조직 안에서 무엇을 해도 되는가”가 더 중요해집니다.

AI 에이전트 프레임워크는 이 질문을 다루기 위한 실행 기반입니다. 단순히 답변을 생성하는 챗봇이 아니라, 모델이 도구를 호출하고, 작업 순서를 나누고, 상태를 기억하고, 필요하면 다른 에이전트에게 일을 넘기는 구조를 만듭니다.

이 글에서는 AI 에이전트 프레임워크의 개념과 지향점을 먼저 정리합니다. 이어서 OpenClaw와 Hermes Agent를 비교하고, 커뮤니티에서 자주 언급되는 LangGraph, CrewAI, OpenAI Agents SDK, Google ADK, Microsoft Agent Framework, Mastra, Pydantic AI, Agno, LlamaIndex Workflows, DSPy까지 실무 관점에서 살펴보겠습니다.

PREMIUM SUMMARY

AI 에이전트 프레임워크는 모델을 업무 시스템 안으로 들여보내는 장치입니다. 따라서 성능보다 먼저 보셔야 할 것은 권한, 기록, 승인, 복구, 보안입니다.

OpenClaw는 여러 채팅 앱과 에이전트를 연결하는 게이트웨이 성격이 강하고, Hermes Agent는 지속 기억과 자기 개선 루프를 강조합니다.

실무 선택 기준은 간단합니다. 단발성 자동화인지, 장기 실행 업무인지, 사람이 중간에 승인해야 하는지, 실패했을 때 되돌릴 수 있는지를 먼저 보셔야 합니다.

AI 에이전트 프레임워크란 무엇인가요?

챗봇은 대체로 질문을 받고 답변합니다. 에이전트는 목표를 받고 움직입니다. 예를 들어 “이번 주 경쟁사 발표를 정리해 주세요”라는 요청이 들어오면, 에이전트는 검색하고, 출처를 확인하고, 중복을 제거하고, 문서를 작성하고, 경우에 따라 슬랙이나 이메일로 공유할 수 있습니다.

여기서 프레임워크가 맡는 일은 모델 호출만이 아닙니다. 작업 상태를 저장하고, 어떤 도구를 쓸지 정하고, 사람 승인 단계를 넣고, 실패한 지점부터 다시 시작하도록 돕습니다. 쉽게 말하면 모델은 두뇌이고, 프레임워크는 작업장입니다. 전기 배선, 안전문, 작업 지시서, CCTV가 함께 있어야 실제 업무가 돌아갑니다.

좋은 AI 에이전트 프레임워크는 모델이 더 많은 일을 하게 만드는 데서 끝나지 않습니다. 오히려 더 중요한 일은 모델이 어디서 멈춰야 하는지 정하는 것입니다. 특히 결제, 발송, 삭제, 배포, 외부 API 호출처럼 되돌리기 어려운 행동에는 별도의 통제선이 필요합니다.

실무 기준

에이전트를 도입하실 때 첫 질문은 “얼마나 자율적인가”가 아닙니다. “자율성이 실패했을 때 어디서 멈추는가”입니다.

왜 지금 AI 에이전트 프레임워크 비교가 어려워졌나요?

이 시장이 어려운 이유는 이름은 비슷한데 지향점이 다르기 때문입니다. 어떤 도구는 그래프 기반 워크플로를 잘 다룹니다. 어떤 도구는 여러 역할을 가진 에이전트 팀을 빠르게 구성합니다. 또 어떤 도구는 타입 안정성, 배포, 관찰 가능성, 권한 관리에 더 많은 힘을 줍니다.

그래서 “가장 좋은 프레임워크”라는 질문은 조금 위험합니다. 내부 자료를 검색하는 에이전트, 고객 문의를 분류하는 에이전트, 코드를 수정하는 에이전트, 임원 보고서를 작성하는 에이전트는 모두 다른 운영 조건을 가집니다. 같은 망치로 시계와 책상을 모두 고칠 수는 없습니다.

프리미엄 관점에서 보셔야 할 간극은 여기에 있습니다. 시장은 “자율 에이전트”를 말하지만, 조직은 “책임 가능한 자동화”를 원합니다. 이 둘 사이를 메우는 층이 바로 AI 에이전트 프레임워크입니다.

OpenClaw와 Hermes Agent는 무엇이 다른가요?

OpenClaw의 핵심 질문은 “에이전트를 어디서 부를 것인가”에 가깝습니다. 공식 문서 기준으로 OpenClaw는 여러 채팅 앱과 채널 표면을 연결하는 자체 호스팅 게이트웨이입니다. WhatsApp, Telegram, Slack 같은 일상적인 채널에서 에이전트를 호출하고, 게이트웨이를 통해 작업을 실행하는 그림에 가깝습니다.

Hermes Agent의 질문은 다릅니다. “에이전트가 시간이 지나며 사용자를 더 잘 이해할 수 있는가”에 가깝습니다. Nous Research의 공개 저장소는 Hermes Agent를 경험에서 기술을 만들고, 사용 중 기술을 개선하며, 과거 대화를 검색하고, 세션을 넘어 사용자를 더 깊이 이해하는 에이전트로 설명합니다.

비교 기준	OpenClaw	Hermes Agent
핵심 정체성	채팅 앱과 에이전트를 잇는 자체 호스팅 게이트웨이	지속 기억과 자기 개선 루프를 강조하는 개인형 자율 에이전트
비유	여러 메신저에 연결된 호출벨입니다. 사용자는 편한 채널에서 부르고, 뒤쪽 게이트웨이가 일을 이어받습니다.	오래 함께 일하는 비서에 가깝습니다. 지난 대화와 반복 업무를 바탕으로 점점 손에 익는 방식을 지향합니다.
강점	일상 채널에서 에이전트를 호출하기 쉽고, 자체 호스팅을 통해 실행 환경을 직접 통제할 수 있습니다.	장기 기억, 반복 작업 학습, 개인화된 업무 흐름에 강점이 있습니다.
주의할 점	메신저 명령이 실제 파일, 이메일, 일정, 외부 서비스로 이어질 수 있으므로 접근 통제와 로그가 중요합니다.	기억이 강점인 만큼 무엇을 저장하고, 언제 삭제하고, 누가 열람할 수 있는지 먼저 정하셔야 합니다.
잘 맞는 사용 사례	채팅 기반 업무 자동화, 개인 생산성 자동화, 내부 운영 실험, 개발자 중심 자체 호스팅 환경	장기 연구, 개인 비서형 자동화, 반복 작업 학습, 클라우드 가상머신 기반 상시 실행 에이전트

두 도구는 같은 선상에서 단순 비교하기 어렵습니다. OpenClaw는 에이전트를 부르는 입구를 넓히고, Hermes Agent는 에이전트가 시간이 지나며 쌓는 기억과 기술을 강조합니다. 따라서 도입 질문도 달라져야 합니다. “어느 쪽이 더 좋은가”보다 “우리 팀은 호출 채널이 문제인가, 장기 기억이 문제인가”를 먼저 보셔야 합니다.

커뮤니티에서 자주 언급되는 AI 에이전트 프레임워크는 어떻게 나눠 볼 수 있나요?

AI 에이전트 프레임워크 생태계는 하나의 지도처럼 보셔야 합니다. 왼쪽에는 “워크플로와 상태 관리”가 있고, 오른쪽에는 “제품화와 운영 관리”가 있습니다. 위쪽에는 “다중 에이전트 협업”이 있고, 아래쪽에는 “타입 안정성·평가·최적화”가 있습니다.

도구	성격	강한 장면	주의할 점
LangGraph	상태 기반 장기 실행 에이전트 오케스트레이션	재시작, 분기, 사람 승인, 복잡한 흐름이 있는 업무	초기 설계가 느슨하면 그래프가 금세 복잡해질 수 있습니다.
CrewAI	역할 기반 다중 에이전트 협업	리서처, 작성자, 검토자처럼 역할이 분명한 작업	역할을 많이 만들수록 책임선이 흐려질 수 있습니다.
OpenAI Agents SDK	애플리케이션 코드 안에서 에이전트, 도구, 승인, 상태를 관리하는 SDK	OpenAI 모델과 도구를 활용해 제품 기능으로 녹일 때	오케스트레이션 책임을 애플리케이션이 직접 가져가야 합니다.
Google ADK	기업 규모 에이전트 구축·디버그·배포를 위한 개발 프레임워크	Google Cloud, Gemini, Cloud Run 중심 운영 환경	클라우드 운영 체계와 함께 보셔야 장점이 분명해집니다.
Microsoft Agent Framework	Python과 .NET 기반 생산 등급 에이전트·다중 에이전트 워크플로	Microsoft 생태계, Azure, .NET 조직	AutoGen 사용 조직은 전환 경로를 함께 검토해야 합니다.
Mastra	TypeScript 기반 AI 애플리케이션·에이전트 프레임워크	React, Next.js, Node.js 기반 제품팀	Python 중심 데이터 팀과 협업할 때 경계면 설계가 필요합니다.
Pydantic AI	타입 안정성과 구조화 출력을 중시하는 Python 에이전트 프레임워크	정확한 데이터 형식, 검증, 평가가 중요한 백엔드·데이터 업무	복잡한 다중 에이전트 연극보다 안정적인 입출력 관리에 더 잘 맞습니다.
Agno	에이전트, 팀, 워크플로, 런타임, 관제까지 묶는 에이전트 플랫폼 지향 도구	추적, 일정 실행, 역할 기반 접근 제어, 감사 로그가 필요한 운영 환경	프레임워크라기보다 운영 플랫폼에 가까워 도입 범위를 먼저 정해야 합니다.
LlamaIndex Workflows	이벤트 기반 단계형 워크플로와 문서·검색 중심 에이전트 구성	문서 검색, 검색증강생성, 지식 기반 업무 자동화	데이터 인덱스 품질이 낮으면 에이전트 판단도 흔들릴 수 있습니다.
DSPy	프롬프트를 손으로 다듬기보다 구조화된 프로그램과 최적화로 AI 시스템을 만드는 프레임워크	평가, 최적화, 재현 가능한 AI 파이프라인	일반적인 “비서형 에이전트”보다는 AI 시스템 설계 도구로 보시는 편이 정확합니다.

실무자는 어떤 기준으로 선택해야 하나요?

선택 기준은 유행 순위가 아니라 업무 모양에서 출발해야 합니다. 단발성 질의응답이라면 프레임워크가 과할 수 있습니다. 반대로 여러 도구를 호출하고, 중간 결과를 저장하고, 사람이 승인해야 하며, 실패했을 때 다시 시작해야 한다면 프레임워크가 필요합니다.

아래처럼 나눠 보시면 판단이 쉬워집니다. 내부 검색과 문서 업무가 중심이면 LlamaIndex Workflows, LangGraph, Pydantic AI가 후보가 됩니다. 여러 역할이 함께 움직이는 콘텐츠·리서치 자동화라면 CrewAI가 이해하기 쉽습니다. 제품 기능으로 넣으려면 OpenAI Agents SDK, Mastra, Pydantic AI를 보실 수 있습니다. 운영 관제와 권한 관리가 중요하면 Google ADK, Microsoft Agent Framework, Agno 쪽을 더 깊게 검토하셔야 합니다.

DECISION CHECKLIST

작업이 단발성인지, 장기 실행인지 먼저 구분하셨습니까?
에이전트가 읽기만 하는지, 실제로 쓰고 실행하는지 확인하셨습니까?
사람 승인 단계가 필요한 행동을 따로 분리하셨습니까?
메모리에 저장할 정보와 저장하지 말아야 할 정보를 구분하셨습니까?
실패했을 때 재시도, 중단, 롤백, 알림이 가능합니까?
로그와 추적 기록을 보안팀, 법무팀, 운영팀 언어로 설명할 수 있습니까?

프리미엄 도입에서 놓치기 쉬운 리스크는 무엇인가요?

에이전트는 유용해지는 순간 위험해질 수 있습니다. 파일을 읽고, 브라우저를 열고, 명령을 실행하고, 외부 서비스에 접속할 수 있어야 진짜 일을 합니다. 그런데 바로 그 권한 때문에 공격 표면이 넓어집니다.

Microsoft Defender Security Research Team이 2026년 6월 공개한 AutoJack 사례는 이 지점을 잘 보여줍니다. 브라우징 에이전트가 신뢰되지 않은 웹 페이지를 열고, 동시에 로컬의 특권 서비스와 통신할 수 있다면 localhost도 더 이상 안전한 경계로만 볼 수 없습니다. 특정 도구 하나의 문제가 아니라, 웹 브라우징·로컬 실행·도구 호출이 만나는 구조에서 반복해서 확인해야 할 문제입니다.

따라서 실험 환경과 운영 환경은 분리하셔야 합니다. 브라우저 자동화, 셸 실행, 파일 접근, 외부 API 호출은 각각 별도 권한으로 다루셔야 합니다. 특히 메신저에서 들어온 명령이 회사 계정, 로컬 파일, 결제, 고객 데이터에 닿는 구조라면 “편하다”는 이유만으로 배포해서는 곤란합니다.

운영 질문

에이전트가 “할 수 있는 일”을 늘리기 전에, “하면 안 되는 일”과 “하기 전에 확인받아야 할 일”을 먼저 정하셔야 합니다.

도입보다 먼저 정해야 할 세 가지 질문

첫째, 어떤 데이터를 에이전트가 볼 수 있는지 정하셔야 합니다. 사내 문서 전체를 열어주는 것과 특정 폴더만 읽게 하는 것은 전혀 다른 결정입니다. 둘째, 어떤 행동에는 사람 승인이 필요한지 정하셔야 합니다. 초안 작성과 실제 발송은 같은 단계가 아닙니다.

셋째, 성과를 어떻게 설명할지 정하셔야 합니다. 에이전트가 일을 많이 했다는 기록만으로는 부족합니다. 검토 시간이 줄었는지, 오류가 줄었는지, 사람이 다시 손본 비율이 낮아졌는지, 실패했을 때 원인을 추적할 수 있었는지가 더 중요합니다.

결국 AI 에이전트 프레임워크의 선택은 기술 취향이 아니라 운영 약속입니다. 여러분의 팀이 어떤 권한을 줄 수 있는지, 어떤 로그를 남길 수 있는지, 어떤 실패를 감당할 수 있는지에 따라 답은 달라집니다.

SUMMARY

AI 에이전트 프레임워크는 모델이 실제 업무를 수행하도록 만드는 실행 기반입니다. 핵심은 자동화 자체가 아니라 권한, 상태, 승인, 기록, 복구를 어떻게 설계하느냐입니다.

OpenClaw는 채팅 채널과 에이전트를 잇는 게이트웨이에 가깝고, Hermes Agent는 시간이 지나며 기억과 기술을 축적하는 개인형 에이전트에 가깝습니다.

다음에 확인하실 지표는 두 가지입니다. 에이전트가 실패했을 때 어디서 멈췄는가. 그리고 사람이 결과를 검토하는 시간이 실제로 줄었는가.

FAQ

AI 에이전트 프레임워크는 챗봇 빌더와 무엇이 다른가요?

챗봇 빌더는 대화 경험을 만드는 데 초점이 있습니다. AI 에이전트 프레임워크는 모델이 도구를 호출하고, 여러 단계 업무를 수행하고, 상태를 유지하고, 사람 승인과 로그를 포함한 운영 흐름을 갖추도록 돕습니다.

OpenClaw와 Hermes Agent 중 무엇을 먼저 봐야 하나요?

채팅 앱에서 에이전트를 호출하고 자체 호스팅으로 통제하고 싶으시다면 OpenClaw를 먼저 보시는 편이 좋습니다. 장기 기억, 반복 업무 학습, 개인화된 비서형 에이전트가 궁금하시다면 Hermes Agent가 더 알맞은 출발점입니다.

기업에서는 어떤 프레임워크가 가장 안전한가요?

특정 프레임워크 하나가 항상 안전하다고 말하기는 어렵습니다. 기업에서는 권한 분리, 감사 로그, 사람 승인, 비밀정보 관리, 배포 환경 격리, 보안 검토 체계를 함께 보셔야 합니다.

LangGraph와 CrewAI는 어떻게 구분하면 되나요?

LangGraph는 상태가 있는 장기 실행 워크플로를 세밀하게 제어하는 데 강합니다. CrewAI는 역할을 나눈 여러 에이전트가 협업하는 구성을 빠르게 이해하고 만들 때 좋습니다.

처음 도입할 때 가장 작은 실험은 무엇인가요?

읽기 전용 업무부터 시작하시는 편이 안전합니다. 예를 들어 내부 문서 검색, 회의록 요약, 경쟁사 뉴스 정리처럼 실제 발송·삭제·결제·배포가 없는 업무가 첫 실험에 적합합니다.

TERMINOLOGY

오케스트레이션: 여러 에이전트, 도구, 단계, 승인 흐름을 순서에 맞게 조정하는 구조입니다.

상태 관리: 작업 중간 결과, 대화 맥락, 재시작 지점 등을 저장하고 이어가는 방식입니다.

사람 개입 단계: 에이전트가 중요한 행동을 하기 전에 사람이 확인하는 절차입니다.

관찰 가능성: 에이전트가 어떤 판단으로 어떤 도구를 호출했는지 추적하고 분석할 수 있는 능력입니다.

도구 호출: 모델이 검색, 파일 읽기, 코드 실행, 외부 API 같은 기능을 사용하는 행위입니다.

이 블로그 검색