LLM 에이전트 종류, 세 가지 축으로 구분하기
LLM 에이전트는 통제 방식(워크플로·에이전트), 추론 패턴(ReAct·계획형·반성형), 규모(단일·멀티)의 세 축으로 나뉜다. Anthropic 정의와 2026년 7월 프레임워크 현황으로 각 종류의 차이와 선택 기준을 짚는다.
LLM 에이전트는 크게 세 축으로 나뉜다. 흐름을 누가 정하느냐로는 정해진 코드 경로를 따르는 '워크플로'와 모델이 다음 행동을 스스로 고르는 '에이전트'로 갈린다. 단일 에이전트의 추론 방식은 ReAct, 계획형(Plan-and-Execute), 반성형(Reflexion)으로 나뉘고, 규모로는 에이전트 하나로 처리하는 단일과 여러 에이전트가 나눠 맡는 멀티로 구분된다. Anthropic이 공개한 'Building Effective Agents' 문서는 첫 번째 축인 통제 방식의 차이를 종류 구분의 출발점으로 삼는다. 이 글은 2026년 7월 기준 텍스트 기반 LLM 에이전트의 소프트웨어 패턴만 다룬다. 특정 상용 서비스의 요금제나 물리 로봇 제어는 범위 밖이다.
워크플로와 에이전트는 무엇이 다른가
차이는 흐름을 코드가 정하느냐, 모델이 정하느냐다. Anthropic의 Building Effective Agents 문서는 워크플로를 "LLM과 도구가 미리 정해진 코드 경로로 조율되는 시스템"으로, 에이전트를 "LLM이 자신의 처리 과정과 도구 사용을 스스로 지휘하는 시스템"으로 정의한다. 워크플로는 분기가 코드에 박혀 있어 결과가 예측 가능하고 테스트하기 쉽다. 반면 에이전트는 모델이 매 단계 다음 수를 정하므로 새로운 상황에 유연하지만, 실패가 누적되고 비용과 지연이 커진다.
같은 문서는 워크플로를 다섯 형태로 정리한다. 프롬프트를 순서대로 이어 붙이는 프롬프트 체이닝, 입력을 분류해 알맞은 처리로 보내는 라우팅, 여러 하위 작업을 동시에 돌리는 병렬화, 중앙 LLM이 작업을 쪼개 하위 LLM에 맡기는 오케스트레이터-워커, 한 LLM이 답을 만들고 다른 LLM이 평가와 피드백을 주는 평가자-최적화다. Anthropic은 공식 엔지니어링 문서에서 워크플로로 충분한 작업에는 에이전트를 쓰지 말고, 유연성이 비용·지연·오류 누적을 넘어설 때만 에이전트로 올라가라고 권한다.
단일 에이전트의 세 가지 추론 패턴
에이전트 하나가 도는 방식은 크게 세 갈래다. Yao 등이 2022년 발표한 ReAct 논문은 '생각(Thought)→도구 호출(Action)→관찰(Observation)'을 한 루프에서 번갈아 반복하는 구조를 제안했다. ReAct는 여전히 단순한 도구 사용 에이전트의 사실상 기본값으로 자리 잡고 있다. 실제 실행 흐름은 이런 형태로 남는다.
Thought: 환율을 알아야 답할 수 있다
Action: get_exchange_rate("USD", "KRW")
Observation: 1380.5
Thought: 이제 답할 수 있다
Answer: 1달러는 약 1,380원
계획형(Plan-and-Execute)은 계획을 세우는 LLM이 먼저 전체 단계 목록을 만들고, 실행 LLM이 단계를 차례로 처리한다. 실행 도중 결과를 보고 계획을 다시 짤 수 있어 여러 단계가 얽힌 장기 작업에 강하다. 반성형은 Shinn 등이 2023년 발표한 Reflexion에서 나온 방식으로, 실행 결과를 스스로 비평한 뒤 그 비평을 다음 시도에 반영해 반복 개선한다. 세 패턴의 차이는 다음과 같다.
| 패턴 | 핵심 동작 | 잘 맞는 작업 |
|---|---|---|
| ReAct | 생각·도구 호출·관찰을 한 루프에서 반복 | 검색·계산 등 단순 도구 사용 |
| 계획형(Plan-and-Execute) | 계획 수립 뒤 단계별 실행, 필요 시 재계획 | 여러 단계가 얽힌 장기 작업 |
| 반성형(Reflexion) | 실행 결과를 스스로 비평하고 다시 시도 | 정답 검증이 가능한 반복 개선 |
멀티 에이전트는 언제 쓰나
에이전트 하나로 문맥이 넘치거나 작업을 병렬로 나눠야 할 때 멀티 에이전트를 고려한다. 무작정 여럿으로 쪼개면 대체로 손해다. 에이전트 수만큼 LLM 호출과 비용, 지연이 곱해지기 때문이다. Anthropic의 오케스트레이터-워커가 대표적 형태로, 중앙 에이전트가 작업을 나눠 하위 에이전트에 맡기고 결과를 합친다. OpenAI가 2025년 3월 공개한 Agents SDK는 '핸드오프(handoff)'를 핵심 개념으로 삼는다. 한 에이전트가 특정 조건에서 제어권을 다른 에이전트에 명시적으로 넘기는 방식이다.
병렬화는 두 갈래로 쓴다. 서로 독립적인 하위 작업을 나눠 동시에 돌리는 방식(sectioning)과, 같은 작업을 여러 번 돌려 결과를 투표로 모으는 방식(voting)이다. 화면을 직접 읽고 조작하는 브라우저 에이전트처럼 도구 조작이 무거운 작업에서는 역할을 나눈 멀티 구성이 단일 루프보다 관리하기 편할 때가 있다.
도구 연결 표준과 프레임워크
종류가 무엇이든 에이전트는 도구를 호출해야 일한다. 요즘 모델은 함수 호출(function calling)로 필요한 순간 JSON 형태의 도구 호출을 직접 내놓는다. 도구를 붙이는 방식 자체도 표준화됐다. Anthropic이 2024년 11월 공개한 모델 컨텍스트 프로토콜(MCP, 에이전트와 외부 데이터·도구를 잇는 개방형 표준)은 이후 OpenAI와 구글 딥마인드 등 주요 업체도 채택했다. 규격은 공식 사이트에 공개돼 있다.
패턴을 실제 코드로 옮길 때는 프레임워크를 고른다. LangChain의 LangGraph는 에이전트 흐름을 그래프로 표현하고 체크포인트로 상태를 저장해 되감기와 재시작을 지원한다. CrewAI는 역할을 부여한 에이전트 '크루'를 적은 코드로 구성한다. OpenAI Agents SDK는 앞서 말한 핸드오프 중심 구성이다. Microsoft AutoGen은 에이전트들이 여러 차례 대화를 주고받는 대화형 팀 구성을 제공한다. 에디터 안에서 에이전트를 직접 돌리는 흐름은 VS Code의 에이전트 호스트 같은 도구로도 자리 잡는 중이다.
종류를 고르는 순서
고르는 순서는 단순하다. 먼저 워크플로로 풀리는지 본다. 입력 분류나 정해진 단계 처리로 끝나는 작업이면 라우팅이나 프롬프트 체이닝으로 충분하고 결과도 더 안정적이다. 도구를 몇 개 쓰면서 스스로 판단이 필요하면 ReAct부터 시작한다. 단계가 열 개 안팎으로 길어지거나 중간에 계획을 바꿔야 하면 계획형을, 답을 검증할 수 있고 반복으로 품질을 올려야 하면 반성형을 얹는다. 멀티 에이전트는 한 에이전트의 문맥에 다 담기지 않거나 병렬 처리가 확실히 이득일 때만 꺼낸다. 종류를 늘릴수록 비용과 디버깅 난도가 함께 오른다는 점을 판단 기준의 맨 앞에 둔다.