전 세계 기업들이 챗봇 에이전트를 실험하고 있고, Anthropic의 Computer Use나 OpenAI의 Operator 같은 도구들은 에이전트를 외부 웹사이트에 연결해 주목을 받았습니다. LangGraph, CrewAI, LlamaIndex Workflows 같은 프레임워크들은 개발자들이 구조화된 에이전트를 구축하는 데 도움을 주고 있습니다. 그러나 이런 인기에도 불구하고, AI 에이전트는 아직 AI 생태계 밖에서 강한 존재감을 보여주지 못하고 있습니다. 소비자나 기업 사용자 사이에서 실질적으로 자리 잡은 에이전트는 많지 않은 상황입니다.

이 글에서는 Arize AI의 'AI Agents & Assistants Handbook' 시리즈를 바탕으로, AI 에이전트가 무엇이고 기존 AI 앱과 무엇이 다른지, 어떤 구성요소로 이루어져 있는지, 그리고 현재 사용 가능한 주요 프레임워크들은 무엇인지 정리합니다. 

☑️AI 에이전트란 무엇인가

LLM 기반 AI 에이전트는 원하는 결과를 달성하기 위해 LLM 호출을 포함한 여러 처리 단계를 연결하는 소프트웨어 시스템입니다. 조건부 로직이나 의사결정 기능을 갖추고 있으며, 단계 간에 접근할 수 있는 작업 메모리(Working Memory)를 보유합니다. 에이전트의 핵심 특성은 자율성입니다. 단일 프롬프트에 반응하고 끝나는 것이 아니라, 환경을 평가하고 새로운 정보가 들어오면 실시간으로 계획을 수정하며, 목표를 달성할 때까지 여러 턴에 걸쳐 자율적으로 일련의 행동을 수행합니다.

기존 LLM 앱과 무엇이 다른가

AI 에이전트를 이해하려면, 기존 LLM 기반 앱과의 차이를 구분하는 것이 도움이 됩니다.

• · 일반 챗봇은 사용자의 질문을 받아 LLM을 한 번 호출하고 응답을 반환합니다. 질문-응답의 단일 턴 구조이며, 도구를 사용하거나 스스로 다음 행동을 결정하지 않습니다.
• · RAG(검색 증강 생성) 앱은 사용자의 질문을 받으면 관련 문서를 검색하고, 그 문서를 컨텍스트로 포함하여 LLM을 호출합니다. 검색 → 생성이라는 고정된 2단계 파이프라인을 따릅니다. 경로가 사전에 정해져 있고, 상황에 따라 다른 행동을 선택하지 않습니다.
• · AI 에이전트는 이와 다릅니다. 에이전트에게는 사용할 수 있는 도구(API 호출, 검색, 코드 실행 등)가 주어지고, 라우터가 사용자의 입력과 현재 상태를 기반으로 어떤 도구를 어떤 순서로 사용할지 스스로 결정합니다. 한 단계의 결과에 따라 다음 행동이 달라지며, 필요하면 여러 단계를 반복하면서 목표에 도달합니다.

예를 들어 고객 지원 에이전트라면, 사용자의 질문을 받아 의도를 파악하고(라우팅), 계정 정보를 조회하고(API 호출), 관련 정책을 검색하고(RAG), 환불 처리를 실행하고(도구 호출), 결과를 요약하여 응답하는 일련의 과정을 자율적으로 수행합니다. 이 과정에서 어떤 단계를 밟을지는 사전에 고정되어 있지 않고, 상황에 따라 에이전트가 판단합니다.

☑️AI 에이전트의 핵심 구성요소

에이전트가 이러한 자율적 동작을 수행하려면, 몇 가지 핵심 구성요소가 필요합니다.

라우터 (Router)

라우터는 에이전트가 다음에 어떤 단계를 밟을지 결정하는 노드입니다. 에이전트는 실행 과정에서 이 라우터로 계속 돌아오며, 매번 업데이트된 정보를 가져옵니다. 라우터는 그 정보를 가능한 다음 단계들에 대한 기존 지식과 결합하여, 다음 행동을 선택합니다. 라우터는 보통 LLM 호출로 구동됩니다. 현재 대부분의 주요 LLM은 함수 호출(Function Calling)을 지원하며, JSON 형태의 함수 정의 목록에서 호출할 컴포넌트를 선택할 수 있습니다. 이 기능 덕분에 라우팅 단계의 초기 구축은 비교적 쉽습니다. 그러나 라우터는 에이전트에서 가장 많은 개선이 필요한 단계이기도 하므로, 초기 구축의 용이함이 내부 복잡성을 감출 수 있습니다.

컴포넌트 (Component)

에이전트가 수행할 수 있는 각 행동은 컴포넌트로 표현됩니다. 컴포넌트는 특정한 작은 작업을 수행하는 코드 블록입니다. LLM을 호출하거나, 여러 번의 LLM 호출을 수행하거나, 내부 API를 호출하거나, 일반적인 애플리케이션 코드를 실행할 수 있습니다. 프레임워크마다 이를 부르는 이름이 다릅니다. LangGraph에서는 노드(Node), LlamaIndex Workflows에서는 스텝(Step)이라고 합니다. 컴포넌트가 작업을 완료하면 라우터로 돌아가거나, 다른 의사결정 컴포넌트로 이동할 수 있습니다.

실행 분기 / 스킬 (Execution Branch / Skill)

에이전트의 복잡도에 따라 컴포넌트들을 실행 분기 또는 스킬로 그룹화하는 것이 유용합니다. 예를 들어 고객 지원 에이전트라면, 환불 처리 스킬, FAQ 응답 스킬, 계정 조회 스킬 등으로 구분할 수 있습니다. 각 스킬은 내부에 여러 컴포넌트를 포함할 수 있습니다.

☑️에이전트 아키텍처의 진화: ReAct에서 2세대로

1세대: ReAct 에이전트의 한계

에이전트라는 개념 자체는 새로운 것이 아닙니다. 1세대 에이전트들은 주로 ReAct(Reason, Act) 패턴을 기반으로 구축되었습니다. 가능한 한 많은 것을 추상화하도록 설계되었고, 폭넓은 결과물을 약속했습니다. 그러나 이 1세대 아키텍처는 실제로는 제대로 작동하지 않았습니다. 과도한 추상화는 사용을 어렵게 만들었고, 약속했던 것과 달리 실질적으로 할 수 있는 일이 많지 않았습니다. 이에 대한 반작용으로, 많은 사람들이 에이전트의 구조 자체를 재고하기 시작했습니다.

2세대: 더 작은 솔루션 공간, 더 강력한 성능

지난 1년간 에이전트 아키텍처는 크게 발전했습니다. 2세대 에이전트는 ReAct의 개방적 구조와 달리, 에이전트가 취할 수 있는 경로를 훨씬 엄격하게 정의하는 원칙 위에 구축됩니다. 프레임워크 사용 여부와 관계없이, 더 작은 솔루션 공간(즉, 각 에이전트가 할 수 있는 일의 범위를 축소하는 것)을 향한 흐름이 나타나고 있습니다. 솔루션 공간이 작을수록 에이전트를 정의하기 쉽고, 이는 곧 더 강력한 에이전트로 이어집니다. 현재 실제로 사용되는 대부분의 에이전트나 어시스턴트는 프레임워크 없이 코드로 직접 작성되어 있고, LLM 라우터 단계를 포함하며, 반복 루프(Iterative Loop) 방식으로 데이터를 처리합니다.

☑️에이전트 프레임워크란 무엇인가

앞서 설명한 라우터, 컴포넌트, 스킬 등의 구조를 직접 코드로 구현할 수도 있지만, 에이전트 프레임워크를 사용하면 이 과정을 체계적으로 관리할 수 있습니다. AI 에이전트 프레임워크는 모델 위의 제어 레이어 역할을 합니다. 작업의 실행 순서를 정하고, 도구를 언제 호출할지 결정하며, 상태 변화를 관리하고, 각 단계를 명확한 규칙에 따라 진행합니다. 프레임워크가 없으면 이런 라우팅 로직과 상태 관리를 개발자가 직접 구현해야 합니다. 프레임워크는 이 과정을 구조화하여, 환경에 관계없이 일관된 실행 경로를 제공하고 문제가 발생했을 때 디버깅할 수 있는 표면을 만들어 줍니다.

에이전트 프레임워크의 핵심 구성요소는 5가지입니다.

• · 플래너(Planner) — 다음 단계를 선택하고, 실행 순서를 정하며, 에이전트가 안정적인 경로를 유지하도록 합니다.
• · 워커(Worker) — 플래너가 선택한 단계를 실제로 수행하고, 해당 시점에 필요한 도구나 모델 작업을 실행합니다.
• · 세션 상태(Session State) — 에이전트가 진행 과정에서 생성한 값과 행동을 저장하여, 올바른 컨텍스트를 가지고 작업을 이어갈 수 있도록 합니다.
• · API 및 도구(APIs & Tools) — 에이전트의 요청을 필요한 API나 서비스로 라우팅하고, 결과를 사용 가능한 형태로 반환합니다.
• · 평가 및 테스트 후크(Evaluation/Testing Hooks) — 각 행동을 트레이스로 기록하고, 동작을 검사하거나 출력 품질을 측정할 수 있는 지점을 제공합니다.

☑️주요 에이전트 프레임워크

현재 AI 에이전트 프레임워크는 빠르게 성숙하고 있습니다. OpenAI, Google 같은 모델 제공사가 자체 프레임워크를 출시하고 있고, LangGraph나 CrewAI 같은 기존 프레임워크도 계속 발전하고 있습니다. 각 프레임워크는 서로 다른 사용 사례에 적합합니다.

CrewAI — 여러 에이전트가 협업하는 팀 구조

CrewAI는 단일 에이전트 루프가 아닌 에이전트 팀을 운영하기 위해 설계되었습니다. 명확한 역할과 도구를 가진 에이전트들을 정의하고, 이들을 하나의 "크루(Crew)"로 조직하여 워크플로우를 진행합니다. 각 에이전트가 좁은 범위의 작업을 담당하고, 프레임워크가 핸드오프를 조율합니다. 런타임이 위임, 재시도, 메모리 공유, 상태 전환을 처리합니다.

적합한 사용 사례: 리서치 파이프라인, 콘텐츠 생성 시스템, 여러 독립적인 의사결정자가 필요한 워크플로우

Mastra — 타입 안전성을 중시하는 워크플로우 기반 개발

Mastra는 타입이 지정된 워크플로우 기반 개발을 위한 TypeScript 프레임워크입니다. 각 단계가 입력과 출력을 정의하고, 프레임워크가 이를 순서대로 실행합니다. 인수가 스키마와 맞지 않으면 즉시 실패하여, 일관성 없는 상태나 추적되지 않는 오류를 방지합니다.

적합한 사용 사례: 안정성과 반복 가능성이 중요한 구조화된 파이프라인, 자동화, 다단계 프로세스. 개방형 계획이나 유연한 분기가 필요한 에이전트에는 덜 적합합니다.

OpenAI Agents SDK — GPT 모델 위의 가벼운 런타임

OpenAI의 Agents SDK는 무거운 프레임워크가 아니라 GPT 모델 위의 가벼운 런타임입니다. 에이전트, 핸드오프, 가드레일, 세션이라는 소수의 프리미티브를 제공하며, 루프와 도구 호출을 처리하면서 대화 상태를 한 곳에서 관리합니다.

적합한 사용 사례: GPT 모델을 주로 사용하는 환경에서 빠르게 에이전트를 구축해야 하는 경우. 자체 오케스트레이션 레이어를 구축하는 대신 핸드오프나 매니저 패턴을 활용할 수 있습니다.

Google ADK — Google 생태계와의 통합

Google ADK(Agent Development Kit)는 Google의 Gemini 모델 생태계와 긴밀하게 통합된 프레임워크입니다. Vertex AI의 인프라 위에서 에이전트를 구축하고 배포할 수 있으며, Google Cloud 서비스와의 연동이 자연스럽습니다.

적합한 사용 사례: Google Cloud 환경에서 Gemini 모델 기반의 에이전트를 구축하는 경우.

LangGraph — 복잡한 분기를 그래프로 표현

LangGraph는 LangChain 위에 구축된 프레임워크로, 에이전트를 방향 그래프(Directed Graph)로 표현합니다. 노드가 각 처리 단계를, 엣지가 단계 간 흐름을 나타냅니다.

적합한 사용 사례: 복잡한 분기, 병렬 처리, 조건부 경로가 많은 워크플로우.

어떤 프레임워크를 선택해야 하는가

올바른 프레임워크를 선택하면 안정적이고 빠른 MVP를 출시하는 데 도움이 되고, 프로덕션에서 에이전트가 어떻게 동작하는지 이해하는 데 필요한 옵저버빌리티와 명확성을 확보할 수 있습니다. 선택 시 고려할 점은 사용하는 LLM 모델, 필요한 복잡도 수준, 팀의 기술 스택(Python vs TypeScript), 그리고 단일 에이전트인지 멀티에이전트인지 등입니다.

☑️에이전트를 측정하는 핵심 지표

에이전트를 구축한 후에는 실제 환경에서 잘 작동하는지 파악해야 합니다. Arize AI는 에이전트의 성능을 판단하기 위한 6가지 핵심 지표를 제시합니다. 이 지표들을 초기에 추적하면, 확장이나 튜닝을 시작하기 전에 에이전트의 상태를 명확하게 파악할 수 있습니다.

• · 정확성 및 출력 품질 (Correctness) — 에이전트가 얼마나 자주 예상한 결과를 생성하거나 올바른 상태에 도달하는지를 측정합니다. 워크플로우가 기본적으로 작동하는지를 보여주며, 자신 있게 답변하지만 틀린 에이전트를 배포하는 것을 방지합니다.
• · 각 단계별 레이턴시 (Latency) — 계획, 도구 호출, 실행에 소요되는 시간을 측정합니다. 다단계 작업에서 누적되는 지연 지점을 파악하여, 사용자 경험에 영향을 주는 병목을 식별할 수 있습니다.
• · 도구 성공/실패율 (Tool Success and Failure Rates) — 도구가 사용 가능한 결과를 얼마나 자주 반환하는지, 또는 오류가 발생하는지를 측정합니다. 불안정한 API나 약한 연동이 일관성 없는 동작을 유발하기 전에 발견할 수 있습니다.
• · 루핑 또는 정체 행동 (Looping or Stuck Behaviour) — 에이전트가 단계를 반복하거나 특정 상태에서 빠져나오지 못하는 경우를 측정합니다. 제어 불능 실행, 비용 낭비, 사용자 대기를 방지합니다.
• · 시간 경과에 따른 컨텍스트 손실 (Context Rot) — 에이전트가 단계를 거치면서 중요한 정보를 유지하는지, 아니면 잃어버리는지를 측정합니다. 메모리나 상태 관리가 워크플로우를 깨뜨리는 시점을 감지할 수 있습니다.
• · 성공한 작업당 비용 (Cost per Successful Task) — 하나의 올바른 실행을 완료하는 데 필요한 총 비용을 측정합니다. 워크플로우가 지속 가능한지, 모델이나 도구 선택을 조정해야 하는지를 판단할 수 있습니다.

☑️마치며

AI 에이전트는 1세대 ReAct 패턴의 한계를 넘어, 더 엄격하게 정의된 경로와 작은 솔루션 공간을 기반으로 한 2세대 아키텍처로 발전하고 있습니다. 라우터, 컴포넌트, 스킬이라는 핵심 구성요소로 이루어져 있으며, CrewAI, LangGraph, OpenAI Agents SDK 등 다양한 프레임워크가 각기 다른 사용 사례에 맞게 제공되고 있습니다. 그런데 에이전트를 구축하는 것은 시작에 불과합니다. 앞서 살펴본 6가지 지표에서 알 수 있듯이, 에이전트는 정확성, 레이턴시, 도구 안정성, 루핑, 컨텍스트 유지, 비용 등 여러 축에서 동시에 관리되어야 합니다. 프로덕션 환경에서 에이전트가 올바르게 동작하는지 관찰하고, 체계적으로 평가하며, 지속적으로 개선하는 것이 진짜 과제입니다.

다음 편에서는 에이전트 옵저버빌리티와 트레이싱을 다룹니다. 에이전트의 내부 동작을 어떻게 추적하고, 멀티에이전트 환경에서 무엇을 관찰해야 하며, 어떻게 자기 개선 플로우를 구축할 수 있는지 살펴보겠습니다.