RUDA DIRECTOR · AI Agent — 30 DAYS / 90 ARTICLES · Day 01 · Learn 02
30초 답변: 다음 단계가 미리 정해져 있고 결과의 재현성이 중요하면 Workflow가 기본값이다. Observation에 따라 다음 Action, Tool, 순서를 Runtime에서 바꿔야 할 때 Agent를 검토한다. 실무에서는 둘 중 하나를 고르는 것보다 Deterministic Shell + Agentic Core로 섞는 경우가 많다.
핵심 경계: “AI를 썼는가?”가 아니라 “누가 다음 단계를 결정하는가?”
Anthropic은 Workflow를 LLM과 Tool이 미리 정의된 Code Path를 따라 실행되는 구조, Agent를 LLM이 자신의 Process와 Tool Usage를 동적으로 결정하는 구조로 구분한다. OpenAI Agents SDK 역시 Orchestration을 LLM이 결정하는 방식과 Code가 결정하는 방식으로 나누고, 두 방식을 혼합할 수 있다고 설명한다.
WORKFLOW Input ↓ Code-defined Step ↓ Known Branch ↓ Known Step ↓ Output AGENT Goal ↓ Model Decision ↓ Action / Tool ↓ Observation ↓ Next Action changes at Runtime ↺ Done
Workflow와 Agent를 가르는 6가지 Decision Dimension
| Dimension | Workflow에 유리 | Agent에 유리 |
|---|---|---|
| Path Predictability | 경로가 거의 고정 | 중간 결과에 따라 경로가 달라짐 |
| Input Variability | 입력 형식이 안정적 | 문제 유형과 필요한 정보가 매번 다름 |
| Tool Choice | 어떤 Tool을 쓸지 미리 앎 | Runtime에서 Tool 선택이 필요 |
| Side Effect Risk | 높을수록 Workflow 선호 | Agent를 쓰면 Approval/Gate 필요 |
| Auditability | 강한 재현성·감사가 중요 | 유연성에 더 큰 가치가 있음 |
| Recovery | 예외를 사전에 열거 가능 | Error를 보고 Replanning이 필요 |
여기서 중요한 포인트는 Agent가 “고급 버전”이 아니라는 것이다. 오히려 Path Predictability가 높은 문제를 Agent로 만들면 Complexity만 증가한다.
Worked Example: 경쟁사 Launch Monitoring을 두 방식으로 설계하면
Workflow형은 조사 대상과 순서가 이미 정해져 있을 때 강하다.
매주 월요일 ↓ A/B/C 공식 Blog 확인 ↓ Pricing page 비교 ↓ Release note 비교 ↓ 변경사항 있으면 Summary ↓ 저장
이 구조는 빠르고 Audit하기 쉽다. 반대로 “어떤 경쟁사 변화가 우리 Launch Risk에 영향을 주는지 조사해줘”처럼 문제 경계가 열려 있다면 Agentic behavior가 유리할 수 있다.
Goal 우리 Launch에 영향을 줄 변화 탐색 ↓ Search 주요 경쟁사 공식 소스 확인 ↓ Observation 경쟁사 B의 가격 변경 발견 ↓ Decision Packaging 변화인지 확인 필요 ↓ Search Docs / Terms / Product page 추가 확인 ↓ Observation 사용량 제한까지 변경 ↓ Decision 우리 Positioning에 영향 있음 ↓ Output Evidence / Impact / Uncertainty 분리
둘 중 무엇이 “더 AI답다”는 질문은 의미가 없다. 핵심은 Runtime 판단이 실제 Business Value를 만드는지다.
실무 패턴: Deterministic Shell + Agentic Core
Side Effect가 있는 제품에서는 전체 흐름을 Agent에게 맡기기보다, 외곽의 위험한 구간은 Code/Workflow로 고정하고 판단이 필요한 안쪽 구간만 Agent에 맡기는 패턴이 유용하다.
[DETERMINISTIC]
Request validation
Permission / Risk check
↓
[AGENTIC CORE]
Search / Diagnose / Compare / Replan
↓
[DETERMINISTIC]
Validation
Human Approval if needed
Commit / Publish / Send
Audit log
이 구조에서는 Agent가 탐색과 판단의 유연성을 갖지만, Publish·Delete·Payment·Permission Change처럼 되돌리기 어려운 Action은 Deterministic Gate를 통과한다.
Agent로 과설계했을 때 나타나는 5가지 Failure Mode
| Failure Mode | 무슨 문제가 생기나 | Better Pattern |
|---|---|---|
| Agent Everywhere | 단순 Step까지 Model Call이 들어가 Cost·Latency 증가 | Deterministic Step로 되돌림 |
| Agentic Side Effect | 판단 Error가 바로 Publish·Delete로 이어짐 | Approval / Commit Gate 분리 |
| Hidden Branching | 왜 이 경로를 택했는지 Debug하기 어려움 | Tracing·Structured State |
| Long Agentic Core | Context가 커지고 Error가 누적됨 | Boundary 축소·Intermediate Validation |
| Workflow Disguised as Agent | Model이 판단할 필요가 없는데 Agent Runtime만 추가 | Code / Rules / Workflow 사용 |
Trade-off: Agent가 추가하는 것은 Intelligence만이 아니다
| 선택 | 장점 | 비용 |
|---|---|---|
| Workflow | 예측 가능·빠름·저렴·감사 쉬움 | 새 상황에 취약·Branch 증가 |
| Agent | 유연함·Replanning·다양한 Tool 전략 | Latency·Token·Cost·Observability·Security 부담 |
| Hybrid | 유연성과 Control 균형 | Boundary 설계가 어려움 |
언제 Agent를 쓰지 말아야 하나
- 계산식과 Business Rule이 이미 명확하다.
- 매번 같은 Input Schema와 같은 Output Schema가 요구된다.
- Auditability와 Reproducibility가 유연성보다 중요하다.
- Latency budget이 매우 작다.
- 실패 시 Side Effect가 크고 충분한 Approval 구조를 만들 수 없다.
- 몇 개의 Code Branch로 예외를 안정적으로 표현할 수 있다.
Decision Checklist: Workflow인가 Agent인가
- 다음 Step을 Code로 미리 정할 수 있는가?
- 새 Observation이 다음 Action을 실제로 바꾸는가?
- Tool 선택이 Runtime마다 달라지는가?
- Agent가 추가하는 Quality가 Cost·Latency보다 큰가?
- Failure를 Trace하고 재현할 수 있는가?
- 위험 Action에 Approval·Permission Boundary가 있는가?
- Agentic Core를 더 작게 만들 수는 없는가?
Design Rule: Workflow는 경로를 설계하고, Agent는 경로를 선택한다. 좋은 Architecture는 Agent가 판단해야 할 구간만 Agentic하게 만든다.
이전 글
AI Agent란 무엇인가: 챗봇과 무엇이 다른가
다음 학습
Agent Loop란 무엇인가: AI Agent가 한 번의 답변으로 끝나지 않는 이유
같이 읽기
Multi-Agent에서 Direction·Orchestration·Execution을 왜 분리하는가
공식 참고 자료
Anthropic — Building effective agents
OpenAI Agents SDK — Agent orchestration
OpenAI Agents SDK — Overview