AI Agent란 무엇인가: 챗봇과 무엇이 다른가

RUDA DIRECTOR · AI Agent — 30 DAYS / 90 ARTICLES · Day 01 · Learn 01

30초 답변: AI Agent는 단순히 “답을 생성하는 Model”이 아니라, Goal을 기준으로 다음 Action을 선택하고, Tool 또는 Environment에서 Observation을 받아, Context와 State를 갱신하며, Stop Condition까지 반복 실행하는 시스템이다. Tool이 하나 붙었다고 Agent가 되는 것도 아니고, 대화가 여러 Turn 이어진다고 Agent가 되는 것도 아니다.

핵심 정의: Agent의 최소 구조는 무엇인가

OpenAI Agents SDK는 Agent를 Instructions와 Tools를 가진 LLM을 중심으로 설명하고, Handoff, Guardrail, Structured Output 같은 Runtime Behavior를 추가할 수 있게 한다. 실제 실행에서는 Runner가 Turn, Tool Execution, Handoff, Session 등을 관리할 수 있다.

이를 설계 관점에서 더 풀어보면 Agent는 다음 6개 층으로 보는 것이 유용하다.

Layer질문없으면 생기는 문제
Goal무엇을 완료해야 하는가?긴 작업에서 목적이 흔들린다
Instructions어떤 규칙과 판단 기준을 따르는가?행동 기준이 모호해진다
Tools / Action Space무엇을 실제로 할 수 있는가?설명만 하고 외부 상태를 바꾸지 못한다
Context / State지금까지 무엇을 알고·시도했는가?중복 작업과 맥락 손실이 생긴다
Agent LoopObservation을 보고 다음 Action을 어떻게 바꾸는가?한 번의 생성으로 끝난다
Control언제 멈추고, 승인받고, 실패로 처리하는가?무한 Loop·중복 Side Effect·위험 실행이 생긴다

Chatbot, Tool-using Assistant, Workflow, Agent는 어디서 갈리는가

ChatbotTool-using AssistantWorkflowAgent
주된 목적대화·답변답변 + 제한된 Tool 사용정해진 절차 실행Goal 달성
다음 단계 결정대개 AnswerModel 또는 AppCode가 주로 결정Model이 Observation에 따라 결정
경로 변화낮음제한적미리 정의된 BranchRuntime에서 동적으로 변화
State 변화대화 Context 중심Tool Result 반영Workflow StateContext + Environment State
대표 Risk잘못된 답변잘못된 Tool Call잘못 설계된 BranchError 누적·비용·Side Effect·Control 실패

경계는 제품마다 다를 수 있다. 중요한 것은 이름이 아니라 누가 다음 Action을 결정하고, Observation이 그 결정을 실제로 바꾸는지다. Tool을 한 번 호출하는 Assistant도 유용하지만, 그 자체가 반드시 Agent일 필요는 없다.

Mechanism: Agent는 실제로 어떻게 움직이나

GOAL
  ↓
MODEL DECISION
현재 Context에서 다음 Action 선택
  ↓
ACTION
Tool Call / Handoff / Ask / Final Output
  ↓
OBSERVATION
Tool Result / Environment Feedback
  ↓
STATE UPDATE
무엇을 알았고 무엇이 바뀌었는가
  ↓
STOP?
  ├─ No → 다음 Decision
  └─ Yes → Final Output / Commit

Agent의 핵심은 “Model이 여러 번 생각한다”가 아니다. Action의 결과가 다음 Decision을 바꾸는 Feedback 구조다. Anthropic도 Agent를 설명할 때 Tool을 Loop 안에서 자율적으로 사용하는 구조와, Runtime마다 Context를 관리하는 문제를 강조한다.

Worked Example: “출시 전 경쟁사 변화를 확인해줘”

이 요청을 단순 Chatbot이 처리하면 이미 알고 있는 경쟁사 정보를 요약할 수 있다. Agent라면 중간 결과에 따라 경로가 달라진다.

Goal
출시 전 경쟁사 변경사항 검증
   ↓
Search
공식 Release / Pricing / Docs 확인
   ↓
Observation
경쟁사 A 가격 변경 발견
   ↓
Decision
가격만 바뀐 건가, Packaging도 바뀐 건가?
   ↓
Search
Pricing + Product docs 재확인
   ↓
Observation
기능 제한도 변경됨
   ↓
Decision
우리 Launch Risk에 영향 있음
   ↓
Output
변경사항 / Evidence / 영향 / 확인 불가 항목 분리

여기서 중요한 건 Search Tool이 아니다. 첫 Observation이 두 번째 질문을 만들었다는 점이다. 이 구조가 없다면 Tool Calling은 있어도 Agentic behavior는 약하다.

Agent라고 부르지만 실제로는 잘못 설계된 5가지 경우

Failure Mode왜 실패하나설계 방향
Tool-enabled ChatbotTool은 있지만 결과가 다음 Action을 바꾸지 않는다Observation → Decision 연결 확인
Prompt-only Control“조심해라”를 Prompt에만 맡기고 실행 제한이 없다Guardrail·Approval·Code-level Gate 사용
State Amnesia이전 시도와 실패를 기억하지 못해 같은 일을 반복한다State / Session / Progress 기록
Unlimited AutonomySend·Delete·Publish 같은 Side Effect를 바로 실행한다Human Approval·Permission Boundary
No Stop Condition충분함의 기준이 없어 Tool Thrashing과 Cost 증가Completion Criteria·Max Turns·Evaluation

Agent를 쓰면 무엇을 얻고 무엇을 잃는가

얻는 것함께 늘어나는 것
경로의 유연성비결정성
다양한 Tool 활용Permission / Security surface
긴 작업 수행Context / State 관리 비용
Error recovery 가능성Retry·Loop 설계 복잡도
복합 Goal 처리Latency·Token·Cost·Observability 부담

언제 Agent를 쓰지 않는 편이 나은가

정해진 계산, Format 변환, 단순 Validation, 고정된 승인 절차처럼 다음 단계가 이미 알려져 있는 작업은 일반 Code나 Workflow가 더 낫다. Anthropic도 성공적인 Agent 구현에서 복잡한 Framework보다 단순하고 조합 가능한 Pattern을 먼저 사용하라고 권한다.

또한 OpenAI Agents SDK 자체도 모든 문제에 Agent Runtime을 강제하지 않는다. Loop, Tool Dispatch, State Handling을 직접 소유하고 싶거나 짧은 Workflow라면 더 낮은 수준의 API를 직접 사용하는 선택지가 있다.

실무 Checklist: Agent를 설계하기 전 7문장

  1. 이 시스템의 Goal은 한 문장으로 정의되는가?
  2. Model이 선택할 수 있는 Action Space는 어디까지인가?
  3. Tool Result 중 무엇을 다음 Context에 넣을 것인가?
  4. 어떤 정보는 State로 지속되어야 하는가?
  5. 어떤 Action은 반드시 Human Approval을 거치는가?
  6. 무엇을 만족하면 Stop할 것인가?
  7. 실패했을 때 무엇을 Trace / Evaluate할 수 있는가?

Design Rule: Agent는 “Tool을 쓰는 AI”가 아니라, Observation에 따라 다음 Action을 바꾸면서 Goal을 닫는 실행 시스템이다.


다음 글
AI Agent와 Workflow의 차이: 언제 Agent가 필요한가

이어 읽기
Agent Loop란 무엇인가: AI Agent가 한 번의 답변으로 끝나지 않는 이유
Multi-Agent에서 Direction·Orchestration·Execution을 왜 분리하는가

공식 참고 자료
OpenAI Agents SDK — Agents
OpenAI Agents SDK — Overview
Anthropic — Building effective agents
Anthropic — Effective context engineering for AI agents


다른 글 보기 · 주제 탐색 · 작성자와 편집 기준 · 문의·정정 요청

RUDA DIRECTOR에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기