Agentic AI 설계 패턴
Agentic AI는 LLM을 자율 에이전트로 운영하는 패러다임 전환이다. “LLM은 CPU, 에이전트는 프로세스, Agentic 프레임워크는 OS”라는 정신모델로 설계하며, 성공은 모델 크기나 프롬프트보다 아키텍처 설계에 달려 있다.
설명
2026년 생산 환경의 AI 실패는 대부분 모델 품질이 아니라 아키텍처 설계 결함에서 비롯된다:
- Unbounded autonomy (제약 없는 자율성)
- Poor state management (상태 관리 부족)
- Insufficient observability (옵저버빌리티 부족)
Agentic AI 설계는 이를 소프트웨어 엔지니어링 관점에서 해결한다.
4가지 핵심 패턴
1. Reflection (자체 검증)
언제 사용: 고위험 출력 (코드, 법률 문서, 재무 로직)
구조:
User Input
↓
LLM 1차 생성
↓
LLM 자체검증 ("이 답이 맞나?")
↓
검증 실패 시 재생성
↓
사용자 전달
비용: 토큰 2배 사용 효과: 환각(hallucination) 30-50% 감소
2. Tool Use (외부 실행)
핵심 규칙: “정확성이 중요하면 LLM이 계산하면 안 된다”
구현:
- 수학 → 계산기 API
- 검색 → 웹 검색 도구
- DB 조회 → SQL 실행
- 확인 가능한 작업은 모두 도구로 오프로드
이점:
- 정확성 보장
- 완전한 추적 가능성
- 일관성 (LLM은 자주 틀림)
3. Planning (명시적 계획)
지식 우선 vs 행동 우선:
| 접근 | 구조 | 최적 사용 |
|---|---|---|
| ReWOO (Knowledge-first) | 컨텍스트 수집 → 계획 수립 → 실행 | 연구, 복잡한 분석 |
| ReAct (Action-first) | 행동 → 관찰 → 반성 → 다음 행동 | 실시간 태스크, 상호작용 |
ReWOO의 이점: 불필요한 행동 줄임 → 토큰 소비 감소 → 비용 절감
4. Multi-Agent Systems (다중 에이전트)
계층 구조:
Supervisor Agent
├─ Domain Expert Agent (특정 분야)
├─ Tool Executor Agent (외부 시스템)
└─ Reflection Agent (품질 검증)
언제 사용:
- 단일 에이전트: 작은 범위, 명확한 경계
- 다중 에이전트: 복잡한 워크플로우, 책임 분리
2026년 Best Practices
7가지 Golden Rules
- 단일 답을 신뢰하지 말 것 — 항상 검증 또는 반성 추가
- 상태 > 프롬프트 — 명시적 상태 머신이 복잡한 프롬프트를 이김
- 토큰 > 도구 — 정확성이 중요한 작업은 도구로 오프로드
- 위험도 높음 = 반성 필수 — 비싸지만 실패보다는 나음
- 모듈화 선호 — 모놀리식 에이전트보다 작은 전문가 에이전트들
- 옵저버빌리티 강제 — 모든 결정이 추적 가능해야 함
- 자율성 제한 — 정책으로 에이전트가 할 수 있는 것을 명시적으로 제한
실행 체크리스트
- Agent lifecycle 명시 (init → plan → execute → reflect → store)
- 비용 인식 계획 (각 단계마다 토큰 예산)
- 옵저버빌리티 (trace-level logging)
- 재실행 가능성 (deterministic state transitions)
- Policy-as-code (YAML/JSON으로 제약 정의)
핵심 통찰
“2026년 성공은 더 큰 모델이나 더 좋은 프롬프트가 아니라 더 나은 에이전트 아키텍처다.”
이는 마이크로서비스가 모놀리식 아키텍처를 이긴 것과 동일한 원리:
- 단일 거대 시스템 → 다중 작은 전문가 시스템
- 지능형 프롬프트 → 체계적 아키텍처
관련 개념
- llmops-lifecycle-and-stack — Agentic 시스템 운영 및 모니터링
- ai-governance-and-compliance — 에이전트 자율성 제한 및 거버넌스