에이전트 AI 종류 알고 덤비자 에이전트 ai 종류

🧭 에이전트 종류⏱ 9분 읽기

왜 이 글이 흥미로운가

"에이전트 종류 N가지" 나열은 그만. 분류 축 5개를 세우면 시중의 거의 모든 에이전트 제품을 좌표 위에 찍을 수 있습니다.

"에이전트 AI"라는 말이 요즘처럼 헐겁게 쓰이는 단어도 드뭅니다. 누군가에게는 프롬프트 몇 개를 순서대로 호출하는 자동화이고, 또 누군가에게는 며칠씩 혼자 돌아가며 코드를 고치는 자율 시스템입니다. 둘 다 "에이전트"라고 부르니, 막상 "우리 회사에 에이전트 도입하자"는 말이 나와도 정확히 무엇을 만들겠다는 건지 합의가 안 됩니다.

그래서 이 글은 "에이전트 AI 종류 N가지" 같은 나열식 정리 대신, 분류 축을 먼저 세우고 그 축 위에서 종류를 배치하는 방식으로 접근합니다. 실무자·개발자 입장에서 "우리 문제는 이 축의 어디쯤이고, 그러면 이 패턴을 써야 한다"까지 판단할 수 있게 하는 것이 목표입니다. 다루는 분류 축은 다섯 가지입니다.

워크플로우인가, 에이전트인가 (제어 흐름 기준)
자율성 수준은 어디까지인가
워크플로우형이라면 어떤 패턴인가
단일 에이전트의 추론 구조는 무엇인가
멀티 에이전트라면 어떤 위상(topology)인가

마지막에 수직(도메인) 에이전트와 선택 가이드를 덧붙입니다.

01 가장 중요한 구분: 워크플로우 vs 에이전트

가장 먼저, 그리고 가장 실무적으로 중요한 분류입니다. Anthropic은 LLM 기반 시스템을 통틀어 "에이전틱 시스템(agentic system)"으로 보되, 그 안에서 워크플로우와 에이전트를 구조적으로 구분합니다.

워크플로우(Workflow): LLM과 도구가 미리 정해진 코드 경로를 따라 오케스트레이션되는 시스템. 흐름은 개발자가 설계해 두었고, LLM은 그 안의 각 단계를 수행합니다.
에이전트(Agent): LLM이 자기 프로세스와 도구 사용을 스스로 결정하며, 어떻게 작업을 완수할지에 대한 제어권을 LLM이 직접 쥐는 시스템.

이 구분이 왜 중요하냐면, 실무에서 안정성과 비용을 결정하는 핵심 변수가 바로 "흐름을 누가 결정하는가"이기 때문입니다. 워크플로우는 경로가 고정되어 있어 예측 가능하고 디버깅이 쉽습니다. 에이전트는 유연하지만 어디서 무엇을 할지 런타임에 결정되므로 관측(observability)과 가드레일이 없으면 통제하기 어렵습니다.

실무 조언 하나를 미리 못박자면 — 대부분의 프로덕션 문제는 완전 자율 에이전트가 아니라 잘 설계된 워크플로우로 충분합니다. 가장 성공적인 구현들은 복잡한 프레임워크가 아니라 단순하고 조합 가능한 패턴을 썼다는 것이 Anthropic이 다수의 고객사와 작업하며 반복적으로 확인한 결론입니다.

02 자율성 수준으로 보는 스펙트럼

워크플로우 ↔ 에이전트는 사실 이분법이 아니라 연속 스펙트럼입니다. 자율성 수준으로 다시 그려 보면 종류가 한눈에 정렬됩니다.

수준	설명	흐름 결정 주체	예시
L0. 고정 자동화	LLM 없이 규칙·스크립트	개발자	기존 RPA
L1. 단일 LLM 호출	한 번의 프롬프트 + 응답	개발자	요약, 분류
L2. 워크플로우	정해진 경로 위의 다단계 LLM	개발자(경로) + LLM(단계)	프롬프트 체이닝, 라우팅
L3. 단일 에이전트	LLM이 루프 돌며 도구·다음 행동 결정	LLM	ReAct, 코딩 에이전트
L4. 멀티 에이전트	여러 에이전트가 역할 분담·협업	오케스트레이터 또는 분산	리서치 시스템, 에이전트 팀

여기서 핵심은 위로 올라갈수록 능력이 아니라 "위임의 폭"이 커진다는 점입니다. 자율성이 높을수록 한 번에 더 많은 것을 맡길 수 있지만, 그만큼 검증·롤백·예산 통제 같은 운영 부담도 커집니다. 종류를 고른다는 건 결국 이 표에서 우리 문제의 좌표를 찍는 일입니다.

03 워크플로우형 5대 패턴 (가장 자주 쓰는 종류)

L2 구간, 즉 워크플로우형은 실무에서 가장 자주 만나는 종류입니다. Anthropic이 정리한 다섯 가지 패턴이 사실상 표준 어휘처럼 쓰이고 있어, 이 다섯 개만 익혀도 대화가 통합니다.

3-1 프롬프트 체이닝 (Prompt Chaining)

복잡한 작업을 여러 단계로 쪼개고, 한 LLM 호출의 출력이 다음 호출의 입력이 되도록 직렬로 잇는 방식입니다. 중간 단계마다 프로그램적 검사(gate)를 넣어 품질을 검증할 수 있다는 게 장점입니다.

언제 쓰나 — 작업을 깔끔하게 순차 단계로 분해할 수 있을 때. 정확도를 높이는 대신 지연시간(latency)을 감수하는 트레이드오프.

활용 사례 — 마케팅 카피 작성 → 톤 검수 → 다국어 번역으로 잇는 콘텐츠 파이프라인, 개요 생성 후 본문 작성, 문서 초안 → 사실 검증 → 교정.

3-2 라우팅 (Routing)

입력을 먼저 분류한 뒤, 각 카테고리에 특화된 처리기(프롬프트/모델)로 보내는 방식입니다. 하나의 거대한 프롬프트에 모든 케이스를 욱여넣을 때 생기는 성능 저하를 피할 수 있습니다.

언제 쓰나 — 입력 유형이 뚜렷하게 구분될 때.

활용 사례 — 고객 문의를 환불/기술지원/일반문의로 분류해 각각 다른 경로로 보내는 CS 시스템, 쉬운 질문은 저렴한 소형 모델로·어려운 질문은 고성능 모델로 보내는 비용 최적화 라우팅.

3-3 병렬화 (Parallelization)

독립적인 하위 작업을 동시에 실행하는 방식입니다. 크게 두 갈래가 있습니다.

섹셔닝(sectioning): 작업을 여러 조각으로 나눠 동시에 처리 후 합치기.
투표(voting): 같은 작업을 여러 번 돌려 결과를 모아 신뢰도를 높이기.

언제 쓰나 — 속도가 중요하거나, 여러 관점의 교차 검증으로 신뢰도를 올려야 할 때.

활용 사례 — 긴 문서를 구간별로 나눠 동시 요약, 코드 리뷰에서 보안·성능·스타일을 각각 병렬 점검, 민감한 판단을 여러 번 평가해 다수결로 확정.

3-4 오케스트레이터-워커 (Orchestrator-Workers)

중앙 LLM(오케스트레이터)이 작업을 동적으로 분해해 워커 LLM들에게 위임하고, 결과를 종합합니다. 체이닝과 달리 하위 작업이 미리 정해져 있지 않습니다.

언제 쓰나 — 작업의 복잡도가 예측 불가능하고, 어떤 하위 작업이 필요할지 사전에 알 수 없을 때.

활용 사례 — GitHub 이슈 하나를 받아 여러 파일에 걸쳐 수정해야 하는 코딩 에이전트(어느 파일을 건드릴지 사전에 모름), 검색 쿼리를 상황에 따라 동적으로 분기하는 리서치 작업.

3-5 평가자-최적화자 (Evaluator-Optimizer)

한 LLM이 결과를 생성하고, 다른 LLM이 그것을 평가·피드백하는 루프를 돌려 점진적으로 개선하는 방식입니다.

언제 쓰나 — 명확한 평가 기준이 있고, 반복으로 품질이 확연히 올라가는 작업일 때.

활용 사례 — 번역 결과를 평가 모델이 채점해 재번역하는 루프, 생성된 글의 각 주장을 근거와 대조해 검증하는 팩트체크, 코드 생성 후 테스트 결과를 피드백으로 재생성.

이 다섯 패턴은 그대로 코딩 에이전트의 기본기이기도 합니다. Claude Code 같은 도구는 이 중 다수를 내부 기능(플랜 모드, 서브에이전트, Task 도구 등)으로 이미 구현해 두고 있습니다.

04 단일 에이전트의 추론 구조 (L3)

흐름 결정을 LLM에게 넘긴 순간부터 진짜 "에이전트"입니다. 이 단일 에이전트도 내부 추론 구조에 따라 종류가 갈립니다.

4-1 ReAct (Reasoning + Acting)

"생각(Thought) → 행동(Action) → 관찰(Observation)"을 번갈아 반복하는 가장 널리 쓰이는 패턴입니다. 각 결정이 실제 도구 호출 결과(현실 피드백)에 근거하므로 환각이 줄고, 추론 과정이 그대로 로그에 남아 감사(audit)가 가능합니다. 해석 가능성이 중요한 곳에서 여전히 표준에 가깝습니다.

활용 사례 — 검색·계산기·DB 조회 같은 도구를 상황에 맞게 골라 쓰는 질의응답 에이전트, 사내 시스템을 조회하며 답하는 업무 비서.

4-2 Plan-and-Execute (계획-실행 분리)

먼저 고수준 계획을 세운 뒤, 그 계획을 단계별로 실행하는 구조입니다. 계획과 실행을 분리하면 복잡한 다단계 작업을 더 효율적으로 처리할 수 있고, 실행 단계는 더 작고 저렴한 모델에 맡길 수 있다는 비용 이점이 있습니다.

활용 사례 — 여러 단계를 거치는 업무 자동화(일정 조율 → 메일 작성 → 시스템 등록), 리서치 계획을 먼저 세우고 각 항목을 수집·정리하는 작업.

4-3 Reflexion (자기 성찰)

에이전트가 자기 결과를 스스로 비평하고, 그 반성을 다음 시도에 반영해 개선하는 패턴입니다. 평가자-최적화자를 단일 에이전트 안으로 내재화한 형태로 볼 수 있습니다.

활용 사례 — 실패한 시도를 기억하고 전략을 바꿔 재시도하는 문제 해결 에이전트, 코드가 테스트를 통과할 때까지 스스로 수정하는 루프.

05 멀티 에이전트 아키텍처 (L4)

문제가 한 에이전트가 감당하기엔 너무 크거나, 전문성을 나눠야 할 때 여러 에이전트를 엮습니다. 이때는 위상(어떻게 연결하고 누가 지휘하는가)으로 종류가 갈립니다.

5-1 오케스트레이터-워커 / 계층형 (중앙집중)

가장 널리 쓰이고 프로덕션에서 가장 검증된 형태입니다. 하나의 오케스트레이터가 작업을 받아 하위 작업으로 쪼개고, 각각을 전문 워커 에이전트에게 배정한 뒤 결과를 취합합니다. 워커끼리는 직접 소통하지 않고 모든 조율이 오케스트레이터를 거치는 허브-앤-스포크 구조입니다. 오케스트레이터가 전역 상태를 쥐고 오류 복구와 종료 판단을 담당합니다.

지휘·라우팅·위임의 비중에 따라 supervisor, orchestrator, router 등 여러 이름으로 불리지만, 본질은 "중앙 통제"라는 점에서 같은 계열입니다.

활용 사례 — 리드 오케스트레이터가 여러 워커에게 검색·수집·정리를 나눠 맡기고 인용까지 종합하는 딥리서치 시스템(에이전트 수·도구 사용·추론 깊이를 예산으로 통제), 부서별 시스템을 가로지르는 업무 오케스트레이션.

5-2 스웜 / 분산형 (탈중앙)

중앙 지휘자 없이 자율 에이전트들이 P2P로 직접 소통하며 역할을 동적으로 협상하고, 분산 지능으로 문제를 푸는 방식입니다. 스웜(swarm) 또는 페더레이티드(federated)라고도 부르며, 통제보다는 창발적(emergent) 조율에 무게를 둡니다.

언제 쓰나 — 흐름을 미리 명세할 수 없는 탐색적·연구형 시스템. 프로덕션에서는 통제가 어려워 권장도가 낮은 편이고, 보통은 그래프나 계층형이 기본 선택지입니다.

활용 사례 — 정답 경로가 없는 탐색적 시뮬레이션, 다양한 전략을 자유 토론(debate)시켜 더 나은 결론을 끌어내는 실험.

5-3 파이프라인 (순차 연결)

에이전트들을 컨베이어처럼 직렬로 잇는 구조입니다. 제어가 강하고 흐름이 명확하지만, 가장 느린 단계가 전체 속도를 좌우하고 한 단계가 실패하면 전체가 막힌다는 약점이 있습니다.

활용 사례 — 수집 → 가공 → 검수 → 발행으로 이어지는 콘텐츠/데이터 처리 라인.

06 수직(도메인) 에이전트라는 또 하나의 축

위 분류가 "구조" 기준이라면, 시장에서 실제로 팔리고 쓰이는 종류는 도메인 기준으로 묶이는 경우가 많습니다. 같은 오케스트레이터-워커 구조라도 무엇을 자동화하느냐에 따라 전혀 다른 제품이 됩니다.

코딩 에이전트: 이슈를 받아 여러 파일을 수정하고 테스트를 돌립니다. 보통 오케스트레이터-워커 + ReAct/Reflexion 조합.
리서치 에이전트: 계획-위임-종합-인용을 거치는 멀티 에이전트가 전형적입니다.
고객지원(CS) 에이전트: 라우팅 + 도구 호출 중심. 분류 정확도가 품질을 좌우합니다.
음성 우선(Voice-first) 에이전트: 실시간 저지연 스트리밍이 핵심인 상담·응대용. 구조보다 지연시간 제약이 설계를 지배합니다.

수직 에이전트를 만들 때 잊지 말아야 할 두 가지 토대는 메모리와 잘 구조화된 데이터입니다. 메모리가 없는 에이전트는 그럴듯한 검색 도구에 불과합니다. 그리고 데이터에 소유자·상태·기한·우선순위 같은 명시적 속성이 붙어 있을 때, 에이전트는 추측하지 않고 "알고" 움직입니다. 데모에서만 멋진 에이전트와 실제 업무를 신뢰성 있게 처리하는 에이전트의 차이는 대개 여기서 갈립니다.

07 그래서 어떤 종류를 골라야 하나 — 선택 기준

종류를 외우는 것보다 고르는 기준을 갖는 게 실무에선 더 중요합니다. 다음 순서로 좁혀 가면 과설계를 피할 수 있습니다.

단일 LLM 호출로 되는가? → 되면 거기서 멈춥니다. 굳이 에이전트로 만들지 않습니다.
흐름이 예측 가능한가? → 예측 가능하면 워크플로우(체이닝·라우팅·병렬화). 자율 에이전트로 가지 않습니다.
하위 작업이 런타임에 결정되는가? → 그렇다면 오케스트레이터-워커.
품질을 반복으로 끌어올려야 하는가? → 평가자-최적화자 / Reflexion 루프를 얹습니다.
한 에이전트가 감당 못 할 만큼 크고 전문성이 갈리는가? → 그제서야 멀티 에이전트. 프로덕션이면 분산형(스웜)보다 계층형/그래프를 기본으로.

피해야 할 안티패턴도 짝지어 기억해 두면 좋습니다. 모든 걸 하나에 몰아넣은 거대 단일 에이전트(monolithic agent), 단순한 일을 거창한 계획 단계로 감싸는 과한 계획(over-engineered planning), 그리고 무엇보다 관측 부재(missing observability) — 에이전트가 무엇을 왜 했는지 로그가 없으면 운영이 불가능합니다.