By ByeongJu Choi in AI Agent — 25 Apr 2026

[AI Agent] AI Agent Preview (6주차)

LLM이 런타임에 다음 행동을 스스로 결정하는 AI Agent의 개념부터 설계까지 알아봅시다. AI Agent를 설계하는 것과 Workflow와의 차이, 4대 구성요소를 통해 Agent 구축의 기초를 다집니다.

현재의 AI Agent 개요

많은 개발자가 Cursor와 Claude Code 같은 코딩 에이전트를 매일 쓰고 있습니다.

ChatGPT와 Claude 내부에도 Agent 모드가 들어왔고 사내 업무 자동화에는 LangGraph, CrewAI 같은 오픈소스 프레임워크로 만든 멀티 에이전트가 점점 들어오고 있습니다.

표준화 흐름도 빠릅니다. Anthropic이 2024년 말에 공개한 MCP(Model Context Protocol)는 LLM과 외부 tool·데이터 소스를 잇는 오픈 표준입니다. 1년 반 만에 9천만 건이 넘는 설치를 기록. 2025년 말에는 Linux Foundation 산하 AAIF로 이관되며 사실상 "Agent ↔ Tool" 연결의 기본이 됐습니다.

앤트로픽의 MCP는 2026년 3월 25일 9,700만 설치를 돌파했습니다. 이는 AI 인프라 표준 중 가장 빠른 채택 곡선입니다.

https://www.anthropic.com/news/model-context-protocol
- Anthropic — Introducing the Model Context Protocol

Gartner는 2026년 말까지 엔터프라이즈 애플리케이션의 40%가 태스크 전용 AI Agent를 포함하게 될 것으로 예측합니다. 현재는 5% 미만입니다.

요약하면 이렇습니다.

"AI Agent는 이미 많은 곳에서 쓰이기 시작했고, 점점 더 많이 들어오고 있습니다."

그런데 이름만 자주 들을 뿐 Agent가 정확히 뭔지 설명해보라고 하면 막히는 경우가 많습니다. LLM을 한 번 호출하는 것과 뭐가 다른지, RAG와 뭐가 다른지, 만들려면 뭘 설계해야 하는지 간단하게 개요를 알아보겠습니다.

AI Agent란 무엇인가

"AI Agent는 LLM이 사용자의 요청(목적)을 수행하기 위해 스스로 다음 행동(tool 호출 또는 최종 응답)을 결정하며 작업을 진행하는 시스템입니다.”

핵심 단어를 나눠보면… → 사용자 요청 / LLM / 스스로 행동입니다.

기존 소프트웨어는 개발자가 실행 경로를 미리 다 정해둡니다. 사용자가 버튼을 누르면 어떤 함수가 호출되고, 그 함수가 어떤 DB를 조회하는지 코드로 고정돼 있습니다.

하지만 Agent는 그 경로를 "런타임에 LLM이 직접 선택"합니다.

Manus의 예

AI Agent 예시

말로만 설명하면 감이 잘 안 옵니다. 가장 단순한 Agent 패턴인 ReAct의 trace를 한 번 확인해보겠습니다.

2주차 프롬프트 엔지니어링 참고
- https://www.promptingguide.ai/kr/techniques/react

User: "서울의 오늘 날씨를 알려주고, 우산 필요한지 알려줘"

Thought: 날씨 정보가 필요하다. weather tool을 호출하자.
Action: weather(city="서울")
Observation: {"temp": 12, "rain_prob": 80, "condition": "비"}

Thought: 강수확률 80%이면 우산 필요. 답변을 만들자.
Final Answer: 서울은 현재 12도, 비 소식 있고 강수확률 80%입니다. 우산을 챙기세요.

세 가지가 존재합니다.. Thought / Action / Observation.

한 번의 LLM 호출로 끝나지 않습니다. 여러 번의 호출에 나뉘고, 매 번 LLM은 스스로 "지금 tool을 쓸지, 아니면 답할지"를 결정합니다.

Observation은 RAG의 retrieved context와 다릅니다. RAG에서 context는 항상 "검색 결과"로 고정돼 있지만, Agent의 Observation은 이번엔 weather API, 다음엔 DB 조회, 그 다음엔 파일 읽기처럼 그 때 그 때 판단한 tool의 출력을 가져오는 것 입니다.

종료 조건도 LLM이 스스로 판단합니다. 답변 가능한 정보가 충분하다고 판단되면 Tool을 종료하고 답변을 출력합니다.

AI Agent를 어떻게 구분할 수 있는가?

하지만 주의할 게 있습니다. 위 예시가 AI Agent로 적합하다고 생각하시나요?

조금 반전일 수 있는데 해석에 따라, 목적에 따라 Agent가 아닐 수도 있습니다.

날씨 앱에서 사용한다고 가정하면 "사용자 지역 날씨를 확인해서 우산 필요 여부를 알려준다"는 작업은 경로가 처음부터 정해져 있습니다.

언제나 날씨 정보를 가져와야겠다 생각하는게 아닌 앞선 로직에서 사용자 위치에 따라 weather 함수를 실행하고 결과를 읽은 뒤 우산 필요 여부만 LLM이 응답해도 되고 아니면 weather 자체에서 비/눈 → 우산 값을 던져주면 됩니다.

def handle(user_query: str) -> str:
    city = extract_city(user_query)
    weather = call_weather_api(city)
    return llm.summarize(user_query, weather)

흐름이 질문에 따라 바뀔 일이 없습니다. 이런 작업은 고정된 코드로 푸는 쪽이 더 빠르고, 싸고, 안정적이며 AI 조차 사용할 필요가 없죠.

하지만 다른 관점으로 보겠습니다.

“비가 오면 사용자의 하루 계획을 어떻게 바꿔야 하는가?”처럼 목표가 열려 있고, 여러 도구를 호출하며, 선택지가 달라지고, 실행까지 이어지면 Agent에 가까워집니다.

도메인	Agent가 되는 이유
여행 / 일정 관리	비, 폭염, 눈 예보에 따라 야외 일정을 실내 일정으로 바꾸고 예약/이동 경로까지 조정
농업	기상, 토양, 작물 상태를 보고 관수, 방제, 수확 시점을 판단
물류 / 배송	폭우, 폭설, 강풍에 따라 배송 경로, 출발 시간, 지연 안내를 조정
건설 / 현장 작업	강풍, 낙뢰, 폭염 기준에 따라 작업 중단, 인력 재배치, 안전 공지 수행
야외 행사 / 스포츠	우천 가능성에 따라 장소 변경, 취소 판단, 참가자 안내, 장비 준비
스마트홈 / 빌딩 관리	날씨와 실내 상태를 보고 냉난방, 창문, 제습, 에너지 사용을 최적화
보험 / 재난 대응	태풍, 홍수, 우박 위험 지역을 감지하고 고객 알림, 피해 접수, 대응 우선순위 결정
항공 / 해운 / 드론	기상 조건에 따라 운항 가능 여부, 경로, 대체 계획 판단. 단, 고위험 영역이라 human-in-the-loop 필요
커머스 / 수요 예측	날씨 변화에 따라 우산, 음료, 방한용품, 배달 수요 등을 예측하고 재고/프로모션 조정

즉 날씨를 의사결정의 수단으로 사용하는 도메인이죠.

이 구분을 Anthropic이 "Building Effective Agents"에서 명확히 합니다.

https://www.anthropic.com/research/building-effective-agents

Anthropic — Building Effective Agents

Workflow는 LLM과 tool이 미리 정해진 코드 경로로 orchestrate되는 시스템입니다.
Agent는 LLM이 자신의 프로세스와 tool 사용을 동적으로 지시하며, 태스크를 어떻게 수행할지에 대한 통제권을 유지하는 시스템입니다.

가장 단순한 솔루션부터 시작하세요. 필요할 때만 복잡도를 올리세요.
많은 경우 Agent는 좋지 않은 선택입니다.

Workflow의 예측 가능성과 통제 가능함 vs Agent의 유연성과 확장성의 대비라고 생각합니다.

Harness → 자율성 높은 Agent에서 규칙을 찾아 흐름을 부여하는 것(추상적)
- 공식 문서를 참조해서 작성하게 한다던가.
- 반드시 참고해야하는 문서를 확인한 뒤 답변하게 한다던가.

그러니까 "AI Agent로 적합한가?"라는 질문은 예시의 구조만 보고는 답할 수 없습니다.

목적과 범위를 함께 봐야 답이 나옵니다.

경로가 고정이면 Workflow로 충분합니다.
경로가 상황마다 달라져야 하면 Agent가 맞습니다.

같은 weather tool을 쓰더라도, 요청이 다음처럼 범위가 열려 있으면 Agent가 될 수 있다는 얘기죠.

"서울 날씨 확인 후 우산 여부"
- 고정 경로, Workflow
"오늘 일정을 보고 외출 시 필요한 것(날씨·교통·일정 충돌)을 정리해줘"
- 스텝 수와 tool 조합이 질문마다 바뀜, Agent

시스템 유형을 스펙트럼으로 정리하면 다음과 같습니다.

시스템 유형	의사결정 주체	실행 경로	종료 조건	대표 예시
Chatbot	사람	매 턴 사람이 결정	사람이 종료	단순 Q&A 봇
RAG	개발자	검색 → 생성 고정	답변 1회 생성	사내 문서 검색 봇
Workflow	개발자	미리 정한 그래프 경로	그래프 끝	Prompt chaining, Routing
Agent	LLM	런타임에 LLM이 선택	LLM이 "done" 선언	ReAct 루프

그렇다면 Agent는 어떻게 설계하는가

"이 문제는 Agent로 풀어야 한다"는 판단이 섰다는 전제 아래 Agent 설계는 무엇을 생각하게 하고. 무엇을 실행하게 하는지 원칙을 정의할 수 있습니다.

Anthropic이 제시한 원칙 세 가지으로 정리해보겠습니다.

Selective use — 필요할 때만 Agent를 씁니다.
- 경로를 그릴 수 있으면 Workflow로 시도해봅니다.
Simplicity — 가장 단순한 구조부터 시작합니다.
- Multi Agent는 지양합니다.
Agent's perspective — 디버깅은 "LLM이 보는 컨텍스트와 tool 설명" 하는 것
- 사람이 볼 때 자연스러운 설명이 LLM에게는 어려울 수 있습니다.

이 세 원칙을 체화한 뒤에 비로소 아래 구성을 하나씩 결정하는 일이 시작됩니다.

어떤 tool을 몇 개 제공하고, 각 tool의 설명을 어떻게 쓸지
System prompt에 역할·제약·종료 조건을 어떻게 담을지
대화 이력과 장기 기억을 어떻게 나눌지 (Memory)
언제 멈추게 할지 (Max iteration, Time budget, Token budget)
위험한 행동 앞에 사람을 개입할지 (Human-in-the-loop)
입력·출력·tool 호출, 데이터를 어떻게 보호할지 (Guardrails, Authenticate and authorize)
실패를 어떻게 관측하고 재현할지 (Observability)
이 전체를 어느 프레임워크 위에 얹을지 (실시간성, 배치성, 이벤트성)

이후 섹션에서는 Agent의 구성요소와 대표 패턴을 먼저 짚고, 그 다음 각 설계 축을 하나씩 풀어쓰겠습니다.

AI Agent의 4대 구성요소

Agent의 구성은 네 가지로 정리됩니다.

LLM — 추론. 다음 행동을 결정
Planning — 계획. 목표를 하위 태스크로 분해
Tool — 행동. 외부 세계와의 접점
Memory — 상태. 단기(Short Term - 대화 이력, 컨텍스트), 장기(Long Term - 사실·벡터 저장소)

각 축이 빠지면 실패 모양이 다르게 드러납니다.

빠지는 축	드러나는 증상
LLM 판단 흐림	엉뚱한 tool 선택, 같은 질문에 다른 경로
Tool 스키마 불명확	hallucinated tool call, 없는 파라미터 호출
Memory 없음	대화 맥락 유실, 이전 결과 반복, 상태 유실
Planning 없음	무한 루프, 중도 방향 상실

RAG 용어와 매핑해두면 이해가 쉽습니다. Retriever는 Agent 관점에서 "검색 tool 하나"입니다. Agent는 그 검색 tool 외에도 여러 tool을 함께 쓸 수 있고, tool을 쓸지 말지를 매 턴 LLM이 결정합니다.

RAG는 무조건 검색이 먼저지만, Agent는 "검색이 필요 없는 질문"이면 검색을 건너뜁니다.

구성 4가지를 AI 구성 요소로

4가지 구성 요소를 실제 AI 개발과 매칭해보겠습니다.

System prompt

Agent의 목표·제약·행동 가이드로 LLM, Planning 구성을 포함합니다.

역할과 목표 — 이 Agent가 달성해야 하는 것
제약 — 하지 말아야 할 것, 정책, 톤
사용 가능한 도구와 선호 순서 — 각 tool을 언제 쓰는지에 대한 힌트
종료 조건 — 언제 "done"이라고 선언할 것인가

Context, Database

Agent가 장기, 반복 실행 가능하게 결과를 저장하고 상태를 기록하는 구성입니다.

단기 메모리 → 이전 입/출력을 다음 AI 입력으로 넣음
- compression, 최근 N개의 턴만 자르기
장기 메모리 → Redis Vector Search, Vector 검색이 가능한 데이터베이스, 혹은 파일 자체
- https://aws.amazon.com/ko/blogs/tech/building-agentic-ai-with-agentcore-memory/
- https://manus.im/ko/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

차주 Multi Agent 패턴에서 자세히 확인해보겠습니다.

Tool

코드, 함수 그 자체를 의미 → 이름, 설명, 파라미터(입력), 반환 스키마(출력)

LLM이 tool의 내부 구현을 보지않고 함수에 필요한 입력을 넣고 실행하는 것
- 정확히 말하면 Tool은 AI가 직접 코드를 실행하는 것이 아닙니다.
- AI가 “어떤 함수를 어떤 인자로 호출할지”를 결정, 프레임워크 런타임이 해당 Python 함수 실행

프레임워크에서 Thought / Action / Observation을 단순 state로 구현한 것 뿐

state = initial_state

  while not framework.should_stop(state):
      state = agent.invoke(state)

  return stat

MCP & Tool 참고

지금까지 tool은 각 프레임워크가 정의한 함수 스키마
- LangChain의 Tool 객체, OpenAI function calling, AutoGen의 tool 인터페이스가 전부 다름
- Agent를 A 프레임워크에서 B 프레임워크로 옮기려면 tool 연결부를 전부 다시 짜야하는 번거로움
- MCP(Model Context Protocol)는 이 문제를 해결하며 쉬운 통합을 제공

AI Agent 패턴

Agent의 종류는 다양하고 툴의 종류도 다양합니다.

대표적인 것을 정리했습니다.

AI Agent의 한계

Agent는 아직 완성된 기술이 아니며 설계자, 구현하는 사람에 따라 품질이 크게 차이날 수 있습니다.

신뢰성, 일관성 — 같은 입력에 다른 경로, 같은 질문에 다른 답
비용·지연 — 한 답변에 LLM 호출 5~20회, latency 수 초에서 수십 초
루프·발산 — 종료 조건 설계 실패 시 무한 호출
관측성 부재 — 어디서 틀렸는지 모름

앞으로 남은 5주간 AI Agent를 직접 설계하고 구현하면서 본격적으로 진행해보겠습니다.

[AI Agent] AI Agent Preview (6주차)

현재의 AI Agent 개요

AI Agent란 무엇인가

AI Agent 예시

AI Agent를 어떻게 구분할 수 있는가?

그렇다면 Agent는 어떻게 설계하는가

AI Agent의 4대 구성요소

구성 4가지를 AI 구성 요소로

System prompt

Context, Database

Tool

AI Agent 패턴

AI Agent의 한계

Reference

[AI Agent] LLM Evaluation Review (5주차)

현재의 AI Agent 개요

AI Agent란 무엇인가

AI Agent 예시

AI Agent를 어떻게 구분할 수 있는가?

그렇다면 Agent는 어떻게 설계하는가

AI Agent의 4대 구성요소

구성 4가지를 AI 구성 요소로

System prompt

Context, Database

Tool

AI Agent 패턴

AI Agent의 한계

Reference

[AI Agent] LLM Evaluation Review (5주차)

You might also like...