Post

AI Agent 완벽 가이드 2: Agent 성숙도 7단계

AI Agent 완벽 가이드 2: Agent 성숙도 7단계

AI Agent는 한 번에 복잡해지는 것이 아니다. 단순 LLM 호출에서 시작해 도구 사용, 순차 실행, 분기, 반복, 계획, 멀티 에이전트 구조로 점점 자율성과 운영 난도가 올라간다.

중요한 것은 높은 단계가 항상 좋은 선택은 아니라는 점이다. 성숙도 단계는 “더 복잡하게 만들기 위한 순서”가 아니라, 문제에 필요한 최소 복잡도를 고르기 위한 기준이다.

레벨이름핵심 차이적합한 상황
L0Simple LLM Call도구와 기억 없이 한 번 응답초안 작성, 설명, 단순 변환
L1Augmented LLM검색/API/DB를 한 번 호출최신 정보, 사내 문서, 계산 필요
L2Chained Agent정해진 단계대로 여러 작업 실행번역, 요약, 코드 생성 파이프라인
L3Router Agent입력에 따라 실행 경로 선택고객지원, 문서 분류, 작업 유형 분기
L4ReAct / Loop Agent관찰 결과를 보고 반복 실행리서치, 디버깅, 탐색형 작업
L5Planning Agent장기 목표를 계획하고 재계획보고서 작성, 경쟁사 분석, 장기 작업
L6Multi-Agent System역할이 나뉜 여러 에이전트 협업대규모 코드 작업, 복합 분석, 조직형 workflow
flowchart LR
    L0[L0: Simple LLM] --> L1[L1: Tool Use]
    L1 --> L2[L2: Chain]
    L2 --> L3[L3: Router]
    L3 --> L4[L4: ReAct Loop]
    L4 --> L5[L5: Planning]
    L5 --> L6[L6: Multi-Agent]

L0. Simple LLM Call

가장 기본적인 형태다. 사용자가 prompt를 넣으면 LLM이 한 번 응답한다. 외부 도구, memory, 검색이 없기 때문에 구현은 쉽지만 최신 정보나 사내 데이터에는 접근할 수 없다.

관점내용
흐름User prompt -> LLM -> Response
장점빠르고 단순하며 비용 예측이 쉬움
한계최신 정보 접근 불가, hallucination 위험
예시이메일 초안, 코드 리뷰 초안, 마케팅 카피

L1. Augmented LLM

LLM이 필요할 때 외부 도구를 한 번 호출한다. 검색, API, DB query, 계산기, code interpreter가 여기에 들어간다. Naive RAG도 이 단계로 볼 수 있다.

flowchart LR
    U[User Query] --> L[LLM]
    L --> T[Tool / Search / DB]
    T --> L
    L --> R[Response]
도구 유형
검색RAG, web search
API날씨, 주가, 업무 시스템
실행계산기, code interpreter

한 번의 cycle로 끝나기 때문에 결과가 부족해도 스스로 재검색하거나 계획을 바꾸지는 않는다.

L2. Chained / Sequential Agent

여러 단계를 미리 정의된 순서대로 실행한다. 앞 단계의 출력이 다음 단계의 입력이 되고, 중간에 gate를 넣어 품질을 확인할 수 있다.

flowchart LR
    A[Analyze] --> B[Process]
    B --> C{Gate}
    C -->|Pass| D[Output]
    C -->|Fail| B

예를 들어 문서 번역 파이프라인은 문맥 분석 -> 초벌 번역 -> 용어 검증 -> 최종 다듬기로 나눌 수 있다. 코드 생성 파이프라인은 요구사항 분석 -> 코드 생성 -> lint/test -> 리뷰/수정으로 구성할 수 있다.

이 단계는 agent처럼 보일 수 있지만, 전체 실행 흐름은 코드가 정한다. LLM은 각 단계의 작업자에 가깝다.

L3. Router / Branching Agent

입력을 분석해서 적절한 경로로 분기한다. LLM이 classifier 역할을 수행하거나, 규칙 기반 router와 함께 쓰인다.

flowchart LR
    I[Input] --> R[Router]
    R --> A[Simple Answer]
    R --> B[Search Pipeline]
    R --> C[Code Workflow]
    R --> D[Human Review]

고객지원 시스템에서는 환불 요청, 기술 문의, 일반 문의를 서로 다른 workflow로 보낼 수 있다. 이 구조는 모든 요청에 무거운 agent loop를 돌리지 않아도 되기 때문에 비용과 latency를 줄이는 데 유리하다.

L4. ReAct / Loop Agent

여기서부터 agent다운 구조가 시작된다. LLM이 상황을 판단하고, 도구를 선택하고, 결과를 관찰한 뒤 다음 행동을 다시 정한다.

flowchart LR
    T[Thought] --> A[Action]
    A --> O[Observation]
    O --> D{Done?}
    D -->|No| T
    D -->|Yes| R[Answer]

리서치 agent가 좋은 예다. 처음 검색 결과가 부족하면 query를 바꾸고, 다른 source를 확인하고, 필요한 경우 다시 검색한다. 이 구조에는 반드시 max_iterations, 비용 한도, tool permission, 실패 시 fallback이 필요하다.

L5. Planning Agent

실행 전에 전체 계획을 세우고, 하위 task로 나눈 뒤, 실행 결과를 보고 계획을 수정한다. long-horizon task에 적합하다.

flowchart TB
    G[Goal] --> P[Plan]
    P --> T1[Task 1]
    P --> T2[Task 2]
    P --> T3[Task 3]
    T1 --> E[Evaluate]
    T2 --> E
    T3 --> E
    E --> R{Need Re-plan?}
    R -->|Yes| P
    R -->|No| O[Final Output]

예를 들어 “경쟁사 분석 보고서 작성”은 경쟁사 리스트 확정, 재무 데이터 수집, 제품 비교, SWOT 분석, 보고서 작성으로 나눌 수 있다. 중간에 데이터가 부족하면 계획을 바꿔 다른 source를 찾는다.

L6. Multi-Agent System

여러 agent가 각자의 역할, 도구, prompt, context를 가지고 협업한다. orchestrator가 작업을 분배하고 결과를 통합하거나, agent 간 handoff로 진행할 수 있다.

패턴설명
Orchestrator-Worker중앙 agent가 작업을 나누고 결과를 통합Claude Code sub-agent 구조
Evaluator-Optimizergenerator가 만들고 evaluator가 평가코드 리뷰, 번역 개선
Debate / Adversarial서로 다른 관점의 agent가 주장과 반론 수행의사결정 지원

Multi-Agent는 context window 한계를 줄이고 역할 전문화를 만들 수 있지만, 디버깅과 관측 난도가 높다. 단일 agent로 충분한 문제에 먼저 multi-agent를 붙이면 비용과 실패 지점만 늘어난다.

단계별 비교

레벨자율성도구 사용흐름 결정대표 기술
L0없음없음코드기본 LLM 호출
L1낮음단일 턴코드 + LLMRAG, Function Calling
L2낮음순차코드Chains, Workflow
L3중간분기코드 + LLMRouter, Classifier
L4높음반복LLMReAct, Tool Use Loop
L5높음계획 + 반복LLMPlan-and-Execute
L6매우 높음분산다수 LLMCrewAI, AutoGen, Sub-agents

선택 기준

Agent 성숙도는 목표가 아니라 선택 기준이다. 복잡도를 올리기 전에는 세 가지를 먼저 확인한다.

  1. 이 문제는 단일 LLM 호출로 해결되지 않는가?
  2. 도구 호출이나 검색이 실제로 필요한가?
  3. 실행 중 재계획이나 반복이 품질을 유의미하게 높이는가?

이 질문에 답하지 못하면 높은 단계의 agent를 쓰는 것이 아니라, 디버깅하기 어려운 workflow를 만드는 것에 가깝다.

This post is licensed under CC BY 4.0 by the author.