LLM Wiki

2026년 프로덕션 AI 에이전트 4대 설계 조건

4 min read

한 줄 정의

단순 툴 연동 챗봇이나 결정론적 워크플로와 달리, 제어 문제를 자율 루프(Event -> Policy -> Action -> State -> Guardrails -> Stop)로 해결하며 프로덕션 요구사항을 충족하기 위한 4가지 필수 필수 요구사항(구조화 상태, 라우팅 의사결정, 예산 제약, 내구성 복구)의 기술 명세이다.

핵심 요지

  • 에이전트 vs RAG vs 워크플로 구분: RAG는 무상태 지식 접근 문제, Workflow는 결정론적 순차 프로세스 문제인 반면, Agent는 제어(Control) 및 경로 탐색 문제다.
  • 4대 필수 조건 (Agent Specification):
    1. 단일 프롬프트를 넘어서는 구조화 State: TripContext처럼 목표, 툴 결과, 스크래치패드, 수집 데이터를 담은 정밀 Schema 객체 관리.
    2. State 기반 라우팅 및 액션 고르기: LLM을 단순 텍스트 생성기가 아닌 Policy Engine/Router로 활용하여 다음 행동(Tool call, Clarification, State update, Stop) 선택.
    3. 엄격한 예산 제약 (Built-in Budget): 무한 루프 방지용 max_steps(예: 10 steps), Timeouts, Cost(달러 상한선), Retries 예산 4종을 하드 캡으로 명시.
    4. Durable Checkpointing & Idempotency: Pod 재시작 시 DB(Postgres/Redis) 체크포인트에서 중단 지점 복구 및 Tool의 멱등성 보장.

상세

프로덕션 레벨 에이전트는 무상태 함수나 툴 챗봇 형태(“Bad Agent”)로 작성될 수 없다. pydantic-ai 및 logfire 환경 기반의 올바른 프로덕션 에이전트(“Better Agent”) 구축 패턴은 다음과 같다:

  1. 관측성 (Observability): Day 1부터 logfire.instrument_pydantic_ai()를 설정하여 의사결정, 툴 호출, 토큰 비용 자동 트레이싱.
  2. 타입 안전 구조화 출력 (Structured Output): 자유 텍스트 반환을 금지하고, TripItinerary처럼 Pydantic 모델을 출력 타입으로 지정. 검증 실패 시 ModelRetry 및 자동 피드백 재시도.
  3. 가드레일 내장 및 에이전트 고장 모드 방어:
    • 무한 루프: 하드 max_steps 캡 지정.
    • 툴 인자 오류: Pydantic/JSON Schema 사전 검증 및 피드백.
    • 비용 폭주: 지수 백오프(Exponential backoff) 및 서킷 브레이커.
    • 프롬프트 인젝션: Allowlist 도구 구성 및 파괴적 툴인 run_bash_command 등에 대한 승인 레이어 구축.

예시

  • Bad Agent (단순 툴 챗봇) 코드 한계: openai.chat.completions.create에 툴 1개 달아서 실행 시, 대화 1턴 후 즉시 이전 스텝을 잊어버려 멀티스텝 여행을 계획할 수 없고, max_steps 예산도 없으며, crash 시 모든 상태가 유실됨.
  • Better Agent (Pydantic AI) 수치/코드 구조:
    • deps_type=TripContext, output_type=TripItinerary
    • retries=2, temperature=0.3, max_tokens=4096
    • logfire 트레이싱으로 툴 호출 스팬 및 평균 단계 수 추적.

충돌

  • 자율성 vs 예산 및 제어 (Control): 에이전트의 완전 자율 탐색에 예산을 두지 않으면 토큰/비용 폭주 및 무한 루프에 빠진다. 자율 경로 선택을 허용하되 max_steps = 10과 멱등성 도구 가드레일 내에서만 동작하도록 상한선을 지정해야 한다.

관련 노트

그래프 뷰

백링크