AI Agent의 구조: 모델, 도구, 루프가 만드는 자율적 시스템

Claude Code에 “이 프로젝트에서 버그를 찾아서 고쳐줘”라고 말하면, 흥미로운 일이 벌어집니다. 먼저 프로젝트 구조를 파악하기 위해 파일 목록을 읽고, 관련 코드를 grep으로 검색합니다. 문제가 될 만한 부분을 발견하면 코드를 직접 수정하고, 테스트를 실행해서 수정이 올바른지 확인합니다. 테스트가 실패하면 에러 메시지를 분석하고, 다시 수정한 뒤 테스트를 돌립니다. 이 전체 과정에서 사람은 아무런 개입도 하지 않습니다.

이건 단순히 질문에 답하는 챗봇이 아닙니다. 스스로 판단하고, 도구를 선택하고, 결과를 확인하며, 목표를 달성할 때까지 반복하는 시스템입니다. 이런 시스템을 AI 에이전트(AI Agent)라고 부릅니다.

이 글에서는 에이전트라는 개념이 어떻게 정의되어 왔는지, 그리고 에이전트를 구성하는 핵심 요소가 무엇인지를 Anthropic과 OpenAI의 공식 가이드를 중심으로 살펴봅니다.

에이전트 정의의 진화: 2023 → 2026

“AI 에이전트”라는 용어는 사용하는 사람마다 의미가 조금씩 다릅니다. 이 개념이 어떻게 구체화되어 왔는지 흐름을 따라가 보겠습니다.

2023: 네 개의 구성 요소

2023년 OpenAI의 연구원 Lilian Weng이 작성한 글 “LLM Powered Autonomous Agents”는 에이전트 개념을 체계적으로 정리한 첫 번째 레퍼런스로 꼽힙니다. 그녀는 에이전트를 네 가지 구성 요소로 정의했습니다.

Agent = LLM + Planning + Memory + Tool Use

• Planning: 큰 작업을 작은 하위 목표로 분해하고, 스스로의 행동을 반성(self-reflection)하며 개선
• Memory: 단기 기억(컨텍스트 윈도우)과 장기 기억(벡터 스토어 등 외부 저장소)
• Tool Use: 외부 API를 호출해서 모델의 지식만으로는 부족한 정보를 보완

이 정의는 당시 에이전트를 설계하려면 각 구성 요소를 명시적으로 엔지니어링해야 했던 현실을 반영합니다. Planning을 위해 별도의 프롬프트 체인을 설계하고, Memory를 위해 벡터 데이터베이스를 구축하고, Tool Use를 위해 함수 호출 스키마를 정의해야 했습니다.

2025: 본질만 남기기

2년이 지나면서 프론티어 모델의 능력이 급격히 올라갔습니다. GPT-4o, Claude Sonnet, Gemini 같은 모델들은 별도의 Planning 모듈 없이도 복잡한 작업을 단계적으로 분해할 수 있게 되었고, 긴 컨텍스트 윈도우(100K~1M 토큰)가 단기 기억의 한계를 크게 완화했습니다.

이런 변화 속에서 Simon Willison은 에이전트의 정의를 한 문장으로 압축했습니다.

“An LLM agent runs tools in a loop to achieve a goal.” Simon Willison

도구(Tools)를 루프(Loop) 안에서 실행하여 목표(Goal)를 달성하는 것. Planning과 Memory는 사라진 게 아니라, 프론티어 모델 자체에 내재된 능력이 되면서 별도의 아키텍처 컴포넌트로 설계할 필요가 줄어든 것입니다.

Anthropic의 정의: Workflow vs Agent

Anthropic은 “Building Effective Agents”에서 한 가지 중요한 구분을 추가합니다.

• Workflow: “systems where LLMs and tools are orchestrated through predefined code paths”
• Agent: “systems where LLMs dynamically direct their own processes and tool usage”

Workflow는 개발자가 미리 정해놓은 코드 경로를 따라 LLM이 실행됩니다. “이 단계에서는 이 도구를 호출하고, 그 결과를 다음 단계로 넘겨라”가 코드에 박혀 있는 것이죠. 반면 Agent는 LLM 스스로가 다음에 무엇을 할지, 어떤 도구를 쓸지, 언제 멈출지를 결정합니다.

실제로는 이 둘이 깔끔하게 나뉘지 않습니다. 대부분의 프로덕션 시스템은 워크플로우적 요소(고정된 파이프라인)와 에이전트적 요소(모델의 동적 판단)가 혼합되어 있습니다. Anthropic도 이 점을 인정하며, 이를 하나의 스펙트럼으로 봅니다.

Workflow                                              Agent
(predefined)                                    (LLM directs)
    |                                                 |
    v                                                 v
----+-----------+--------------+-------------+---------->
    |           |              |             |
  Prompt     Routing     Orchestrator   Autonomous
  Chaining                -Workers        Agent

에이전트의 세 가지 본질적 요소

정의의 진화를 관통하는 공통 요소가 있습니다. 어떤 정의를 따르든, 에이전트 시스템은 결국 세 가지로 구성됩니다.

1. 모델(Model): 판단의 주체

에이전트의 두뇌입니다. 사용자의 요청을 이해하고, 다음에 무엇을 할지 결정하고, 도구 호출의 결과를 해석합니다.

Anthropic은 이를 “Augmented LLM”이라는 개념으로 설명합니다. 날것의 LLM이 아니라, 도구와 검색과 메모리로 증강된 LLM이 에이전트의 기본 빌딩 블록이라는 것입니다.

┌──────────────────────────────┐
│       Augmented LLM          │
│                              │
│   ┌───────┐  ┌──────────┐   │
│   │ Tools │  │ Retrieval │   │
│   └───────┘  └──────────┘   │
│        ┌──────────┐         │
│        │  Memory  │         │
│        └──────────┘         │
│                              │
│        LLM (Core)            │
└──────────────────────────────┘

OpenAI의 가이드에서도 동일한 관점을 취합니다. 에이전트의 세 가지 기반 요소로 모델(model), 도구(tools), 지시문(instructions)을 제시하면서, 모델은 “에이전트의 의사결정 엔진”이라고 표현합니다.

2. 도구(Tools): 행동의 수단

LLM은 본질적으로 텍스트를 생성하는 모델입니다. 파일을 읽거나, 데이터베이스를 조회하거나, API를 호출하는 건 할 수 없습니다. 도구가 이 간극을 메웁니다.

도구는 에이전트가 외부 세계와 상호작용하는 인터페이스입니다. 모델이 “이 도구를 이 인자로 호출하겠다”고 결정하면, 실제 실행은 에이전트 하네스(harness)가 담당하고, 그 결과를 다시 모델에게 돌려줍니다.

프로덕션 에이전트가 사용하는 도구의 범위는 생각보다 넓습니다.

Claude Code는 약 26개의 내장 도구를 가지고 있고, Codex도 유사한 규모의 도구 세트를 제공합니다. 흥미로운 점은 이 도구들이 대부분 개발자가 일상적으로 사용하는 것들(grep, cat, bash)과 본질적으로 같다는 것입니다. 에이전트에게 특별한 초능력을 주는 게 아니라, 개발자가 쓰는 것과 같은 도구를 쓸 수 있게 해주는 것입니다.

3. 루프(Loop): 자율성의 원천

모델과 도구만으로는 에이전트가 아닙니다. 핵심은 루프, 즉 모델이 도구를 호출하고, 결과를 관찰하고, 다시 판단하는 반복 구조입니다.

이 루프가 에이전트와 단순 LLM 호출을 근본적으로 구분합니다. 단순 호출은 한 번 질문하고 한 번 답하면 끝입니다. 에이전트는 목표를 달성할 때까지 루프를 반복합니다.

User Request
      |
      v
+---------------------------+
|  Model: decide next action | <-----------+
+-------------+-------------+             |
              |                            |
        [text only?]                       |
         /        \                        |
       Yes         No (tool call)          |
        |           |                      |
        v           v                      |
    Response   Execute tools -----> collect results
                                           |
                                     (loop back)

이 패턴은 ReAct(Reasoning + Acting)로 알려져 있습니다. 생각하고(Reason), 행동하고(Act), 관찰하고(Observe), 다시 생각하는 순환입니다.

실제로 Claude Code와 Codex 모두 이 루프를 기반으로 동작합니다.

구현 방식은 다르지만 본질은 동일합니다. 모델이 도구 호출을 요청하면 실행하고, 결과를 모델에 돌려주고, 모델이 더 이상 도구 호출을 하지 않을 때까지 반복합니다. 이 루프 자체는 놀라울 정도로 단순합니다. 복잡한 것은 루프 주변의 인프라(컨텍스트 관리, 퍼미션, 에러 복구)이며, 이것은 이 시리즈의 뒤쪽 글들에서 자세히 다룰 예정입니다.

루프가 왜 그렇게 중요한가

루프의 힘을 보여주는 인상적인 수치가 있습니다. Andrew Ng이 HumanEval 코딩 벤치마크에서 측정한 결과입니다.

GPT-3.5에서 GPT-4로 모델을 업그레이드하면 48.1% → 67.0%로 약 19%p 개선됩니다. 하지만 GPT-3.5를 에이전트 루프 안에 넣으면 48.1% → 95.1%로 47%p가 개선됩니다. 약한 모델 + 루프가 강한 모델의 단일 호출을 크게 앞지르는 것입니다.

Andrew Ng은 이를 이렇게 비유합니다. zero-shot 호출은 에세이를 백스페이스 없이 처음부터 끝까지 한 번에 타이핑하는 것과 같습니다. 에이전트 루프는 초안을 쓰고, 읽어보고, 고치고, 다시 읽는 과정을 반복하는 것입니다. 당연히 후자가 나을 수밖에 없습니다.

이 관찰에서 Andrew Ng은 네 가지 에이전틱 디자인 패턴을 제시했습니다.

1. Reflection: 모델이 자신의 출력을 검토하고 개선점을 찾는다
2. Tool Use: 외부 도구를 활용해 정보를 수집하거나 행동한다
3. Planning: 복잡한 작업을 단계적으로 분해하고 실행한다
4. Multi-Agent Collaboration: 여러 에이전트가 역할을 나눠 협업한다

이 패턴들은 서로 배타적이지 않습니다. 프로덕션 에이전트는 보통 이 중 여러 개를 조합합니다. Claude Code는 네 가지를 모두 사용합니다. 도구를 호출하고(Tool Use), 결과를 검증하고(Reflection), 복잡한 작업을 단계적으로 수행하며(Planning), 서브에이전트에게 작업을 위임합니다(Multi-Agent).

Anthropic의 다섯 가지 워크플로우 패턴

Andrew Ng의 네 가지 패턴이 에이전트의 능력에 초점을 맞췄다면, Anthropic은 에이전트 시스템의 구조를 다섯 가지 패턴으로 분류합니다. 각 패턴은 복잡도가 다르고, 적합한 상황이 다릅니다.

Anthropic은 이 패턴들에 대해 한 가지 원칙을 강조합니다.

“단순한 프롬프트로 시작하고, 포괄적인 평가로 최적화하고, 단순한 솔루션이 부족할 때만 멀티 스텝 에이전트 시스템을 추가하라.”

가장 단순한 Prompt Chaining으로 충분한 문제에 Orchestrator-Workers를 도입하면 복잡성만 늘고 디버깅이 어려워집니다. 복잡도는 필요할 때만 올려야 합니다.

에이전트의 한계와 Trade-off

에이전트가 강력한 패러다임인 건 분명하지만, 모든 문제에 에이전트가 적합한 것은 아닙니다.

비용과 지연 시간

에이전트 루프는 여러 번의 LLM 호출을 수반합니다. 하나의 작업을 처리하는 데 10~50번의 모델 호출이 필요할 수 있고, 각 호출마다 비용과 지연 시간이 발생합니다. 단순 번역, 요약, 감정 분석처럼 한 번의 호출로 충분한 작업에 에이전트 루프를 도입하면 비용만 늘어납니다.

OpenAI의 가이드는 이 점을 직접적으로 언급합니다. “번역, 전사, 라벨링, 감정 분석, 요약 생성 같은 단일 단계 ML 작업에는 에이전트를 사용하지 마라.”

예측 불가능성

에이전트는 본질적으로 비결정적(non-deterministic)입니다. 같은 요청에 대해 다른 경로를 택할 수 있고, 같은 도구를 다른 순서로 호출할 수 있습니다. 이건 유연성의 원천이기도 하지만, 디버깅과 테스트를 어렵게 만드는 요인이기도 합니다. 결과가 정확히 재현 가능해야 하는 시스템에는 고정된 워크플로우가 더 적합합니다.

에이전트가 적합한 경우 vs 아닌 경우

프로덕션 에이전트의 현실

지금까지 에이전트의 개념적 구조를 살펴봤습니다. 그런데 실제로 프로덕션에서 동작하는 에이전트를 보면, 루프 자체는 전체 시스템에서 아주 작은 부분에 불과합니다.

Claude Code의 아키텍처를 분석한 연구에서 흥미로운 수치가 있습니다. Claude Code 전체 코드베이스에서 AI가 판단하는 로직은 1.6%에 불과합니다. 나머지 98.4%는 퍼미션 관리, 컨텍스트 관리, 도구 라우팅, 에러 복구 같은 결정론적 인프라입니다.

이 사실은 에이전트 시스템의 진짜 엔지니어링 과제가 어디에 있는지를 보여줍니다.

• 컨텍스트 관리: 유한한 토큰 윈도우 안에서 관련 정보를 어떻게 유지하고, 불필요한 정보를 어떻게 압축할 것인가
• 퍼미션과 안전성: 에이전트에게 어디까지 자율성을 줄 것인가, 위험한 행동을 어떻게 차단할 것인가
• 에러 복구: 도구 실행이 실패했을 때, 모델이 같은 실수를 반복할 때 어떻게 대응할 것인가
• 비용 관리: 프롬프트 캐싱을 통해 O(n²)으로 증가하는 비용을 어떻게 선형으로 유지할 것인가

이것이 이 시리즈에서 하나씩 풀어갈 주제들입니다.

마치며

에이전트의 본질은 결국 세 가지입니다. 판단하는 모델, 행동하는 도구, 그리고 이 둘을 연결하는 루프. 개념 자체는 단순하지만, 이것을 프로덕션에서 안정적으로 동작하게 만드는 것은 전혀 다른 수준의 엔지니어링 문제입니다.

다음 글에서는 Anthropic이 제시한 다섯 가지 워크플로우 패턴을 하나씩 깊이 들어가면서, 각 패턴이 실제 프로덕션 에이전트에서 어떻게 구현되는지를 살펴보겠습니다.

참고자료

• Building Effective Agents (Anthropic)
• A Practical Guide to Building Agents (OpenAI)
• LLM Powered Autonomous Agents (Lilian Weng)
• Agentic Design Patterns (Andrew Ng)
• What is an AI agent? (Simon Willison)