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 Loop | Observation을 보고 다음 Action을 어떻게 바꾸는가? | 한 번의 생성으로 끝난다 |
| Control | 언제 멈추고, 승인받고, 실패로 처리하는가? | 무한 Loop·중복 Side Effect·위험 실행이 생긴다 |
Chatbot, Tool-using Assistant, Workflow, Agent는 어디서 갈리는가
| Chatbot | Tool-using Assistant | Workflow | Agent | |
|---|---|---|---|---|
| 주된 목적 | 대화·답변 | 답변 + 제한된 Tool 사용 | 정해진 절차 실행 | Goal 달성 |
| 다음 단계 결정 | 대개 Answer | Model 또는 App | Code가 주로 결정 | Model이 Observation에 따라 결정 |
| 경로 변화 | 낮음 | 제한적 | 미리 정의된 Branch | Runtime에서 동적으로 변화 |
| State 변화 | 대화 Context 중심 | Tool Result 반영 | Workflow State | Context + Environment State |
| 대표 Risk | 잘못된 답변 | 잘못된 Tool Call | 잘못 설계된 Branch | Error 누적·비용·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 Chatbot | Tool은 있지만 결과가 다음 Action을 바꾸지 않는다 | Observation → Decision 연결 확인 |
| Prompt-only Control | “조심해라”를 Prompt에만 맡기고 실행 제한이 없다 | Guardrail·Approval·Code-level Gate 사용 |
| State Amnesia | 이전 시도와 실패를 기억하지 못해 같은 일을 반복한다 | State / Session / Progress 기록 |
| Unlimited Autonomy | Send·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문장
- 이 시스템의 Goal은 한 문장으로 정의되는가?
- Model이 선택할 수 있는 Action Space는 어디까지인가?
- Tool Result 중 무엇을 다음 Context에 넣을 것인가?
- 어떤 정보는 State로 지속되어야 하는가?
- 어떤 Action은 반드시 Human Approval을 거치는가?
- 무엇을 만족하면 Stop할 것인가?
- 실패했을 때 무엇을 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