AI Agent 아키텍처: Tool Use, Planning, Memory 설계 패턴

AI Agent는 LLM에 도구 사용(Tool Use), 계획 수립(Planning), 기억(Memory) 능력을 결합하여 복잡한 작업을 자율적으로 수행하는 시스템입니다. 단순 질의응답을 넘어 "생각하고, 행동하고, 관찰하는" 루프를 반복합니다.

핵심 요약

• AI Agent는 LLM + Tool Use + Planning + Memory + Control Loop의 조합으로 구성됩니다.
• Tool Use는 LLM이 외부 시스템과 상호작용하는 인터페이스이며, MCP(Model Context Protocol)가 도구 연동 표준으로 자리잡고 있습니다.
• Planning 패턴은 단순한 ReAct(Think→Act→Observe)부터 Plan-and-Execute, Multi-Agent 오케스트레이션까지 복잡도에 따라 선택합니다.
• Memory는 단기(컨텍스트 윈도우), 작업(현재 추론 상태), 장기(세션 간 지속) 3계층으로 설계합니다.
• 프로덕션 환경에서는 도구 실행 안정성, 계획 실패 복구, 메모리 비용 관리가 핵심 운영 과제입니다.

1. AI Agent란 무엇인가

ChatGPT에게 "이번 달 AWS 비용을 확인하고 비정상적인 항목이 있으면 Slack으로 알려줘"라고 요청한다고 가정합니다. 단순 LLM은 이 요청을 처리할 수 없습니다. AWS Cost Explorer API를 호출하고, 결과를 분석하고, 판단 기준을 세우고, Slack API를 호출해야 합니다.

AI Agent는 이런 다단계 작업을 자율적으로 수행하는 시스템입니다. 핵심은 LLM이 "생각만 하는 존재"에서 "행동하는 존재"로 확장된다는 점입니다.

1.1 Agent와 Chatbot의 차이

구분	Chatbot	AI Agent
상호작용	질문 → 답변 (1회)	목표 → 계획 → 실행 → 관찰 (반복)
도구 사용	없음 또는 제한적	다양한 외부 도구를 자율 선택
상태 관리	대화 히스토리만 유지	작업 상태, 중간 결과, 장기 기억 관리
자율성	사용자 입력마다 반응	목표 달성까지 자율적으로 단계 진행
실패 처리	에러 메시지 반환	재시도, 대안 경로 탐색, 계획 수정

1.2 Agent의 4가지 핵심 구성 요소

AI Agent는 다음 4가지 요소의 조합으로 동작합니다.

구성 요소	역할	비유
LLM (추론 엔진)	상황을 판단하고 다음 행동을 결정	뇌
Tool Use (도구)	외부 시스템과 상호작용	손과 눈
Planning (계획)	복잡한 작업을 단계로 분해하고 순서를 결정	전략
Memory (기억)	과거 경험과 현재 상태를 유지	기억

이 위에 Control Loop(제어 루프)가 실행 흐름을 관리합니다. "다음에 무엇을 할지" 결정하고, 도구 호출 결과를 관찰하고, 목표 달성 여부를 판단하는 반복 구조입니다.

2. Agent 아키텍처 전체 구조

AI Agent 아키텍처 전체 구조

Agent의 실행 흐름은 다음과 같은 루프 구조를 따릅니다.

사용자 요청 → Planning(계획 수립) → Tool Selection(도구 선택) → Tool Execution(실행) → Observation(관찰) → 판단(완료/계속) → 응답 또는 다음 단계

이 루프에서 Memory는 모든 단계에 걸쳐 동작합니다. 이전 실행 결과를 기억하고, 현재 작업 상태를 추적하며, 장기적인 학습 결과를 저장합니다.

3. Tool Use 설계 패턴

Tool Use는 Agent가 외부 세계와 상호작용하는 인터페이스입니다. LLM 자체는 텍스트 생성만 할 수 있으므로, 실제 행동(API 호출, DB 쿼리, 파일 조작 등)은 모두 도구를 통해 수행합니다.

3.1 도구 호출 메커니즘

현재 주요 LLM 제공자들은 Function Calling(도구 호출) 기능을 네이티브로 지원합니다.

{
  "name": "get_aws_cost",
  "description": "지정 기간의 AWS 비용을 서비스별로 조회합니다",
  "parameters": {
    "type": "object",
    "properties": {
      "start_date": { "type": "string", "description": "조회 시작일 (YYYY-MM-DD)" },
      "end_date": { "type": "string", "description": "조회 종료일 (YYYY-MM-DD)" },
      "granularity": { "type": "string", "enum": ["DAILY", "MONTHLY"] }
    },
    "required": ["start_date", "end_date"]
  }
}

LLM은 도구의 이름, 설명, 파라미터 스키마를 보고 "언제, 어떤 도구를, 어떤 인자로 호출할지"를 결정합니다. 실제 실행은 Agent 런타임이 담당합니다.

3.2 도구 설계 원칙

운영 환경에서 도구를 설계할 때 고려할 점은 다음과 같습니다.

원칙	설명	예시
단일 책임	하나의 도구는 하나의 작업만 수행	search_documents와 update_document를 분리
명확한 설명	LLM이 선택 판단을 할 수 있도록 설명이 구체적	"DB에서 사용자 조회" ✗ → "user_id로 사용자 프로필을 조회합니다. 존재하지 않으면 null 반환" ○
안전한 기본값	위험한 작업은 확인 단계를 포함	삭제 도구에 dry_run 파라미터 추가
에러 표현	실패 시 LLM이 이해할 수 있는 에러 메시지 반환	스택 트레이스 대신 "권한 부족: IAM 정책에 s3:GetObject 추가 필요"
멱등성	같은 입력으로 여러 번 호출해도 동일 결과	재시도 시 중복 생성 방지

3.3 MCP(Model Context Protocol): 도구 연동 표준

Anthropic이 2024년 11월 25일에 공개한 MCP는 AI Agent와 외부 도구를 연결하는 오픈 표준입니다. 2025년에 OpenAI(Responses API에서 MCP 지원 + 운영위원회 합류)와 Google(2025년 4월 지원 발표)이 채택하면서 업계 표준으로 자리잡았고, 2025년 12월에는 Linux Foundation의 Agentic AI Foundation으로 이관되었습니다.

MCP의 핵심 아이디어는 N개의 AI 클라이언트와 M개의 도구 서버를 연결할 때, N×M개의 커스텀 통합 대신 N+M개의 표준 구현으로 줄이는 것입니다. IDE의 Language Server Protocol(LSP)이 에디터와 언어 서버를 분리한 것과 동일한 접근입니다.

구성 요소	역할
MCP Client	AI 애플리케이션 (Claude, ChatGPT, IDE 등)
MCP Server	외부 도구/데이터 제공자 (DB, API, 파일시스템 등)
Transport	클라이언트-서버 간 통신 (stdio, HTTP+SSE)

MCP 서버가 제공하는 3가지 프리미티브:

• Tools: Agent가 호출할 수 있는 함수 (API 호출, 쿼리 실행 등)
• Resources: Agent가 읽을 수 있는 데이터 (파일, DB 레코드 등)
• Prompts: 특정 작업에 최적화된 프롬프트 템플릿

3.4 Tool Use의 실무 시나리오

시나리오: 인프라 모니터링 Agent

DevOps팀에서 야간 온콜 대응을 자동화하려고 합니다. Agent에게 다음 도구를 제공합니다.

도구 목록:
- check_cloudwatch_alarm: 현재 활성 알람 조회
- get_pod_status: K8s Pod 상태 확인
- query_logs: CloudWatch Logs 쿼리
- restart_pod: 비정상 Pod 재시작
- send_slack_message: Slack 채널에 메시지 전송
- create_jira_ticket: Jira 티켓 생성

Agent는 알람을 확인하고, 원인을 진단하기 위해 로그를 조회하고, 자동 복구가 가능한 경우 Pod를 재시작하고, 결과를 Slack으로 보고합니다. 사람의 개입이 필요한 경우에는 Jira 티켓을 생성합니다.

이때 설계 결정이 필요합니다:

• restart_pod는 자동 실행을 허용할 것인가, 사람 승인을 요구할 것인가?
• 도구 호출 실패 시 재시도 횟수와 백오프 전략은?
• 동시에 여러 알람이 발생하면 우선순위를 어떻게 결정하는가?

4. Planning 설계 패턴

Planning은 Agent가 복잡한 목표를 달성하기 위해 작업을 분해하고 실행 순서를 결정하는 능력입니다. 실무에서 사용되는 주요 패턴은 3가지입니다.

4.1 ReAct 패턴 (Reasoning + Acting)

Agent Planning 패턴 비교

ReAct는 가장 기본적인 Agent 실행 패턴입니다. "생각 → 행동 → 관찰"을 반복하며, 한 번에 하나의 단계만 결정합니다.

Thought: AWS 비용 이상을 확인하려면 먼저 이번 달 비용을 조회해야 합니다.
Action: get_aws_cost(start_date="2026-06-01", end_date="2026-06-10", granularity="DAILY")
Observation: [결과: EC2 $1,200/day 평균, 6월 8일 $3,400 급증]

Thought: 6월 8일에 EC2 비용이 비정상적으로 높습니다. 어떤 인스턴스가 원인인지 확인해야 합니다.
Action: get_ec2_instances(filter="running", sort="cost_desc", date="2026-06-08")
Observation: [결과: i-abc123 (p4d.24xlarge) 이 $2,100 소비]

Thought: GPU 인스턴스가 예상 외로 실행 중입니다. Slack으로 알리겠습니다.
Action: send_slack_message(channel="#cost-alerts", message="...")
Observation: [결과: 메시지 전송 완료]

적합한 상황:

• 단계가 3~5개 이내인 작업
• 이전 단계의 결과에 따라 다음 행동이 달라지는 경우
• 탐색적 작업 (정답 경로가 미리 정해지지 않은 경우)

한계:

• 긴 작업에서 컨텍스트가 누적되어 비용 증가
• 초기에 잘못된 방향을 잡으면 전체 경로가 비효율적
• 병렬 실행이 불가능

4.2 Plan-and-Execute 패턴

복잡한 작업에서는 먼저 전체 계획을 수립하고, 그 계획에 따라 순차적으로 실행하는 방식이 효과적입니다.

[Planning Phase]
Goal: "새 마이크로서비스를 EKS에 배포하고 모니터링을 구성합니다"

Plan:
1. ECR 리포지토리 생성
2. Dockerfile 작성 및 이미지 빌드
3. Kubernetes Deployment/Service 매니페스트 작성
4. HPA 설정
5. Prometheus ServiceMonitor 구성
6. Grafana 대시보드 생성
7. Slack 알림 연동 확인

[Execution Phase]
Step 1 실행 → 결과 관찰 → Step 2 실행 → ...

이 패턴의 핵심은 계획 수정(Re-planning) 능력입니다. Step 3에서 네임스페이스가 없다는 에러가 발생하면, Planner가 "Step 2.5: 네임스페이스 생성"을 계획에 추가합니다.

적합한 상황:

• 5단계 이상의 복잡한 작업
• 전체 구조를 미리 파악할 수 있는 작업
• 사용자에게 계획을 보여주고 승인을 받아야 하는 경우

trade-off:

• 초기 계획 수립에 토큰을 추가로 소모
• 계획이 실행 중에 무효화될 수 있음 (환경 변화)
• 계획을 너무 세밀하게 세우면 유연성이 떨어짐

4.3 Multi-Agent 오케스트레이션

하나의 Agent로 처리하기 어려운 복잡한 작업은 여러 전문 Agent를 조합하여 해결합니다. Anthropic이 2025년에 공개한 멀티에이전트 리서치 시스템이 이 패턴의 대표 사례입니다.

패턴	구조	적합한 상황
Orchestrator-Worker	지휘자가 작업을 분배하고 결과를 취합	독립적인 하위 작업이 여러 개인 경우
Sequential Pipeline	Agent A의 출력이 Agent B의 입력	단계별 전문성이 필요한 경우 (코드 생성 → 리뷰 → 테스트)
Parallel Fan-out	동일 질문을 여러 Agent에게 동시 요청	다양한 관점 수집, 정보 병렬 검색
Evaluator-Optimizer	생성 Agent + 평가 Agent가 반복 개선	품질 기준이 명확한 결과물 생성

실무 시나리오: 코드 리뷰 파이프라인

Orchestrator Agent
├── Security Agent: 보안 취약점 검사
├── Performance Agent: 성능 이슈 분석
├── Style Agent: 코드 스타일 검사
└── Test Agent: 테스트 커버리지 확인
→ Orchestrator가 결과를 종합하여 최종 리뷰 작성

운영 고려사항:

• Agent 간 통신 비용 (토큰 + 지연 시간)
• 하위 Agent 실패 시 전체 워크플로우 처리 (Circuit Breaker)
• 결과 충돌 시 우선순위 결정 로직

4.4 패턴 선택 기준

기준	ReAct	Plan-and-Execute	Multi-Agent
작업 복잡도	낮음~중간	중간~높음	높음
병렬 처리	불가	제한적	가능
비용 (토큰)	낮음	중간	높음 (15~20x)
실패 복구	단순 재시도	계획 수정	Agent 수준 재시작
지연 시간	낮음	중간	높음
투명성	높음 (단계별 추적)	높음 (계획 공개)	중간 (내부 통신 복잡)

실무에서는 단순한 패턴으로 시작하여 필요에 따라 복잡도를 높이는 것이 권장됩니다. ReAct로 충분한 작업에 Multi-Agent를 적용하면 비용과 지연 시간만 증가합니다.

5. Memory 설계 패턴

Memory는 Agent가 상태를 유지하고 과거 경험을 활용하는 메커니즘입니다. 사람의 기억 체계와 유사하게, Agent Memory도 계층적으로 설계합니다.

5.1 Memory 계층 구조

AI Agent Memory 계층 구조

계층	지속 시간	저장 위치	용도
단기 기억 (Short-term)	현재 대화/세션	LLM 컨텍스트 윈도우	대화 히스토리, 최근 도구 호출 결과
작업 기억 (Working)	현재 작업 수행 중	컨텍스트 윈도우 + 외부 상태	현재 계획 상태, 중간 추론 결과, 변수 추적
장기 기억 (Long-term)	세션 간 지속	외부 저장소 (Vector DB, KV Store 등)	사용자 선호도, 과거 작업 결과, 학습된 패턴
에피소드 기억 (Episodic)	영구	외부 저장소	과거 작업의 전체 경험 (성공/실패 포함)

5.2 단기 기억: 컨텍스트 윈도우 관리

단기 기억의 물리적 한계는 LLM의 컨텍스트 윈도우 크기입니다. Claude Sonnet 4의 경우 기본 200K 토큰(API에서는 최대 1M 토큰까지 확장 가능), GPT-4o는 128K 토큰을 지원합니다.

컨텍스트가 가득 차면 다음 전략을 조합합니다:

전략	방법	장점	단점
슬라이딩 윈도우	오래된 메시지를 순서대로 제거	구현 간단	중요 정보 유실 가능
요약 압축	오래된 대화를 요약으로 치환	핵심 보존	요약 시 정보 손실
선택적 유지	중요도 기준으로 필터링	효율적	중요도 판단이 어려움
외부 위임	초과 정보를 외부 저장소로 이동	무제한 확장	검색 비용 발생

5.3 장기 기억: 세션 간 지속 설계

장기 기억은 Agent가 "학습"하는 것처럼 보이게 만드는 핵심 요소입니다. 구현 방식은 저장소 유형에 따라 나뉩니다.

저장소	적합한 데이터	검색 방식
Vector DB	비정형 지식, 과거 대화	의미 유사도 검색
Key-Value Store	사용자 설정, 명시적 팩트	정확한 키 조회
Knowledge Graph	엔티티 간 관계	그래프 순회, 관계 쿼리
Relational DB	구조화된 작업 이력	SQL 쿼리

실무 시나리오: 고객 지원 Agent

고객 지원 Agent가 장기 기억을 활용하는 방식:

[첫 번째 세션]
고객: "우리 회사는 EKS를 3개 클러스터로 운영하고 있어요"
→ 장기 기억 저장: {customer_id: "C-001", infra: "EKS 3 clusters"}

[한 달 후 세션]
고객: "Pod 스케일링 문제가 있어요"
→ 장기 기억 검색: 이 고객은 EKS 3개 클러스터 운영
→ Agent: "3개 클러스터 중 어떤 환경에서 발생하나요? HPA 설정을 확인해 보겠습니다."

5.4 Memory의 Read/Write 설계

Agent Memory는 단순 저장이 아니라 "언제 읽고, 언제 쓸지"를 설계해야 합니다.

Write 시점:

• 사용자가 명시적으로 정보를 제공할 때
• 작업이 성공/실패로 완료될 때
• Agent가 새로운 패턴을 발견할 때

Read 시점:

• 새 세션이 시작될 때 (사용자 컨텍스트 로드)
• 도구 선택 전 (과거 유사 상황에서의 선택 참조)
• 계획 수립 시 (이전 계획의 성공/실패 패턴 참조)

주의할 점:

• 모든 정보를 저장하면 노이즈가 증가하여 검색 품질이 떨어집니다.
• Memory에 민감 정보(credentials, PII)가 저장되지 않도록 필터링이 필요합니다.
• 오래된 정보가 현재 결정을 왜곡할 수 있으므로 유효기간(TTL) 설정을 고려합니다.

6. 프로덕션 설계 시 고려사항

6.1 안정성과 에러 처리

실패 유형	대응 전략
도구 호출 실패	재시도 (지수 백오프) + 대체 도구 경로
LLM 응답 파싱 실패	구조화된 출력 강제 (JSON Mode) + 재시도
무한 루프	최대 반복 횟수 제한 (일반적으로 10~25회)
계획 실패	Re-planning 또는 사용자에게 에스컬레이션
환각 기반 도구 호출	도구 입력 검증 (schema validation)

6.2 보안 설계

Agent는 도구를 통해 실제 시스템에 영향을 줄 수 있으므로 보안 설계가 중요합니다.

• 최소 권한: Agent에게 필요한 도구만 제공. 읽기 전용 도구와 쓰기 도구를 분리하고 쓰기 도구는 승인 게이트 추가
• 입력 검증: LLM이 생성한 도구 파라미터를 실행 전에 검증. SQL Injection, Path Traversal 등 방지
• 실행 격리: 도구 실행 환경을 샌드박스로 격리. 코드 실행 도구는 컨테이너 내부에서만 동작
• 감사 로그: 모든 도구 호출과 결과를 기록. 사후 분석과 이상 탐지에 활용
• Rate Limiting: Agent의 도구 호출 빈도를 제한하여 비정상 동작 시 피해 범위 축소

6.3 비용 최적화

Agent는 여러 번의 LLM 호출과 도구 실행을 반복하므로 단순 챗봇 대비 비용이 높습니다.

최적화 전략	효과
모델 라우팅	간단한 판단은 경량 모델, 복잡한 추론만 대형 모델 사용
도구 결과 캐싱	동일 입력의 도구 호출 결과를 캐시하여 중복 호출 방지
계획 캐싱	유사한 목표에 대해 이전 계획을 재활용
조기 종료	목표 달성을 즉시 감지하여 불필요한 추가 단계 방지
컨텍스트 압축	긴 도구 출력을 요약하여 다음 단계에 전달

6.4 관측성 (Observability)

Agent 시스템은 비결정적(non-deterministic)이므로 관측성이 특히 중요합니다.

• Trace: 각 실행의 전체 단계를 추적 (계획 → 도구 호출 → 관찰 → 판단)
• Metrics: 단계 수, 토큰 사용량, 도구 호출 성공률, 총 지연 시간
• Evaluation: 목표 달성률, 사용자 만족도, 도구 선택 정확도

7. 프레임워크와 도구 선택

현재 AI Agent를 구축할 때 선택 가능한 프레임워크는 크게 두 가지 계열로 나뉩니다.

계열	프레임워크	특징
오픈소스	LangGraph, CrewAI	커뮤니티 주도, 유연한 커스터마이징, 다양한 LLM 지원
빅테크 공식 SDK	OpenAI Agents SDK, Google ADK, AWS Strands Agents	해당 플랫폼 최적화, 관리형 인프라 연동

프레임워크 선택은 별도 글에서 상세히 다룹니다.

8. 관련 글

• RAG란 무엇인가
• AI 애플리케이션 보안 리스크: Prompt Injection과 데이터 유출
• AI 서비스 비용 최적화 전략

---

마무리

AI Agent 아키텍처는 "LLM에게 도구를 주면 알아서 하겠지"라는 단순한 접근으로는 프로덕션 수준에 도달하기 어렵습니다. Tool Use의 안전한 설계, Planning 패턴의 적절한 선택, Memory 계층의 효율적 관리가 조합되어야 안정적인 시스템이 됩니다.

설계 시 핵심 원칙을 요약하면:

• 단순하게 시작: ReAct로 시작하고, 복잡도가 필요할 때만 Multi-Agent로 확장
• 도구는 방어적으로: 모든 도구 호출에 검증과 제한을 적용
• Memory는 선택적으로: 모든 것을 기억하는 것보다 관련성 높은 정보만 유지
• 관측 가능하게: 비결정적 시스템일수록 추적과 평가가 중요
• 비용을 의식: 토큰 사용량과 도구 호출 횟수를 모니터링하고 제어