Originally published on tamiz.pro.

생성형 AI(Generative AI)의 초기 약속은 간단했습니다: 지식 노동을 자동화하는 것이었습니다. 초기 구현체들은 종종 정교한 챗봇처럼 보였습니다—상태 비저장(stateless)이며, 반응적이고, 단일 프롬프트-응답 주기에 의해 구동되는 방식이었습니다. 그러나 산업이 성숙함에 따라 수요는 대화형 인터페이스에서 **에이전트 워크플로우(Agentic Workflows)**로 이동했습니다: 복잡하고 다단계적인 목표를 달성하기 위해 인식(perceive), 계획(plan), 행동(act), 관찰(observe)하는 시스템입니다.

챗봇에서 에이전트로의 전환은 단순한 아키텍처 업그레이드가 아닙니다. 이는 우리가 소프트웨어 신뢰성을 추론하는 방식에 대한 근본적인 변화입니다. 초기

1. 환각 루프 (The Hallucination Loop)

LLM은 결정론적 (Deterministic)이지 않고 확률적 (Probabilistic)입니다. 만약 도구 호출 (Tool call)이 실패하면 (예: 데이터베이스로부터의 500 에러), 단순한 에이전트는 에러 메시지를 유효한 데이터로 해석하거나, 더 나쁘게는 사용자를 만족시키기 위해 성공적으로 완료되었다고 환각 (Hallucinate)할 수 있습니다. 명시적인 상태 검증 (State validation)이 없다면, 에이전트는 동일한 잘못된 작업을 재시도하는 루프에 빠져 토큰을 소비하고 사용자의 의도(Intent)를 해결하는 데 실패하게 됩니다.

2. 무한 재귀 (Infinite Recursion)

복잡한 워크플로우 (Workflow)에서 에이전트는 더 많은 정보가 필요하다고 판단하여 도구를 호출하고, 그 후에도 여전히 더 많은 정보가 필요하다고 결정할 수 있습니다. 단계(Step)에 대한 엄격한 제한이나 종료 상태 (Terminal state)가 없다면, 에이전트는 도구 호출의 무한 루프에 빠질 수 있습니다. 이는 단순한 사용자 경험 (UX)의 실패가 아니라, 재정적 부채 (Financial liability)입니다. 토큰 생성의 무한 루프는 단 몇 분 만에 예산을 모두 소진할 수 있습니다.

3. 컨텍스트 윈도우 고갈 (Context Window Exhaustion)

에이전트 워크플로우의 모든 단계는 대화 컨텍스트 (Conversation context)에 이력을 추가합니다. 에이전트가 더 많은 단계를 수행할수록 컨텍스트 윈도우 (Context window)는 채워집니다. 윈도우가 가득 차면, LLM은 이전 대화 내용을 요약하거나 삭제해야 합니다. 이러한 컨텍스트의 손실은 에이전트가 원래의 목표나 이전 작업의 결과를 잊게 만들어, 단절되고 일관성 없는 동작으로 이어질 수 있습니다.

결정론적 핵심: 유한 상태 머신 (Finite State Machines, FSMs)

신뢰할 수 있는 에이전트를 구축하려면, 확률적 생성의 혼돈에 구조를 부여해야 합니다. 이를 위한 가장 효과적인 패턴은 **유한 상태 머신 (Finite State Machine, FSM)**입니다. FSM은 유한한 수의 상태 (States), 상태 간의 전이 (Transitions), 그리고 동작 (Actions)으로 구성된 계산의 수학적 모델입니다.

AI 에이전트의 맥락에서 FSM은 LLM을 대체하는 것이 아니라, LLM을 제어합니다. LLM은 상태 머신 _내부_의 구성 요소가 되어, 현재 상태와 입력을 바탕으로 다음 전이를 결정하는 역할을 담당합니다. 이러한 관심사의 분리 (Separation of concerns)는 매우 중요합니다:

• FSM은 로직을 처리합니다: 비즈니스 규칙을 강제하고, 입력을 검증하며, 에이전트가 유효한 다음 상태로만 이동하도록 보장합니다.
• LLM은 추론을 처리합니다: 자연어를 해석하고, 도구 호출 (Tool calls)을 생성하며, 최종 답변을 합성합니다.

아키텍처 패턴: 오케스트레이터 패턴 (The Orchestrator Pattern)

오케스트레이터 패턴 (Orchestrator pattern)은 에이전트를 위한 FSM의 일반적인 구현 방식입니다. 이 모델에서는 중앙 컨트롤러 (FSM)가 워크플로우를 관리합니다. 컨트롤러는 현재 상태를 유지하며, 다음에 어떤 서브 에이전트나 도구를 호출할지 결정합니다. LLM은 의사결정을 내리거나 콘텐츠를 생성해야 하는 필요한 경우에만 호출됩니다.

from enum import Enum
from typing import Optional, Dict, Any

...

FSM을 사용함으로써, 우리는 에이전트가 유효하지 않은 상태로 진입할 수 없음을 보장할 수 있습니다. 또한 FSM 수준에서 단계 제한 (Step limits)을 강제할 수 있어, LLM이 무엇을 결정하든 관계없이 무한 루프를 방지할 수 있습니다.

에이전트 워크플로우의 숨겨진 비용

엔지니어링 팀이 AI 에이전트의 생존 가능성을 평가할 때, 흔히 정확도 지표(예: "에이전트가 90%의 확률로 올바르게 답변하는가?")에만 집중하고 운영 비용은 간과하곤 합니다. 에이전트 워크플로우의 "숨겨진 비용"은 상당하며, 이는 성공적인 에이전트조차 경제적으로 실행 불가능하게 만들 수 있습니다.

1. 토큰 복잡성 및 지연 시간 (Token Complexity and Latency)

에이전트 워크플로우의 각 단계에는 LLM에 프롬프트를 보내는 과정이 포함됩니다. 만약 워크플로우가 10단계를 필요로 한다면, 당신은 10번의 별도 LLM 호출에 대한 비용을 지불하게 됩니다. 게다가 단계가 진행됨에 따라 컨텍스트 윈도우 (Context window)가 커지면서 입력 토큰 수가 증가하고, 이는 비용을 비선형적으로 상승시킵니다.

완화 방법: 라우팅 (Routing) 및 분류 (Classification) 작업에는 더 작고 특화된 모델을 사용하십시오. 비용이 많이 드는 대규모 컨텍스트 모델은 최종 합성 단계용으로 남겨두십시오. 과거의 상호작용을 요약하거나 벡터 검색 (Vector retrieval)을 사용하여 관련 컨텍스트만 가져오는 것과 같은 공격적인 컨텍스트 관리 (Context management)를 구현하십시오.

2. 실패의 비용

전통적인 소프트웨어 시스템에서 실패한 요청은 단일 API 호출에 불과합니다. 하지만 에이전트 시스템 (Agentic system)에서 실패한 목표는 토큰을 소비하는 여러 번의 도구 호출 (Tool calls)을 포함할 수 있습니다. 만약 에이전트가 5단계 후에 실패한다면, 당신은 아무런 가치 없이 5단계 분량의 연산 비용을 지불한 셈이 됩니다.

완화 방법 (Mitigation): 조기 종료 체크 (Early termination checks)를 구현하십시오. 각 도구 실행 후, 성공 기준 (Success criteria)에 따라 출력을 검증하십시오. 기준이 충족되지 않는다면, 토큰을 계속 낭비하며 진행하기보다 즉시 실패(Fail fast) 처리를 하고 에러를 반환하거나 사용자에게 명확한 설명을 요청하십시오.

3. 관찰 가능성 및 디버깅 오버헤드 (Observability and Debugging Overhead)

에이전트를 디버깅하는 것은 스크립트를 디버깅하는 것보다 기하급수적으로 어렵습니다. LLM의 의사결정 과정은 불투명하기 때문에, 단순히 console.log를 출력하여 실행 흐름을 추적할 수 없습니다. 에이전트가 실패했을 때, 당신은 다음 사항들을 알아야 합니다: 어떤 상태 (State)에 있었는가? 프롬프트 (Prompt)는 무엇이었는가? 도구 출력 (Tool output)은 무엇이었는가? LLM의 추론 (Reasoning)은 무엇이었는가?

완화 방법 (Mitigation): 첫날부터 관찰 가능성 (Observability)에 집중적으로 투자하십시오. LangSmith, Langfuse 또는 Arize Phoenix와 같은 트레이싱 (Tracing) 도구를 사용하여 모든 상태 전이 (State transition), 도구 호출 (Tool call), 그리고 LLM 응답을 기록하십시오. 의사결정 과정의 전체 컨텍스트 (Context)를 포함하도록 로그를 구조화하십시오.

프로덕션 환경에 적합한 에이전트를 위한 모범 사례 (Best Practices for Production-Ready Agents)

신뢰할 수 있는 에이전트를 구축하려면 단순히 FSM만으로는 부족합니다. 엔지니어링에 대한 총체적인 접근 방식이 필요합니다. 프로덕션 배포를 위한 주요 모범 사례는 다음과 같습니다:

1. 중요한 작업을 위한 인간 참여 (Human-in-the-Loop, HITL)

위험도가 높은 작업(예: 데이터베이스 레코드 삭제, 고객에게 이메일 전송)의 경우, 에이전트가 자율적으로 행동하게 두지 마십시오. FSM을 사용하여 PENDING_APPROVAL 상태로 전환하고, 사람이 명시적으로 해당 작업을 승인하도록 하십시오.

2. 구조화된 출력 및 스키마 검증 (Structured Output and Schema Validation)

LLM은 엄격한 형식을 준수하는 데 취약하기로 유명합니다. 파싱 에러 (Parsing errors)를 방지하려면 구조화된 출력 (Structured output)을 지원하는 LLM 제공업체(예: OpenAI의 JSON 모드, LangChain의 Pydantic 검증)를 사용하십시오. 모든 도구 입력과 출력에 대해 엄격한 스키마 (Schema)를 정의하십시오.

3. 멱등적 도구 설계 (Idempotent Tool Design)

에이전트가 사용하는 모든 도구가 멱등적 (Idempotent)이 되도록 보장하십시오. 만약 에이전트가 실패한 단계를 재시도할 경우, 해당 도구는 부작용(예: 중복 레코드 생성)을 일으키지 않고 동일한 결과를 생성해야 합니다. 이는 일시적인 오류 (Transient errors)로부터 복구하는 데 매우 중요합니다.

4. 폴백 메커니즘 (Fallback Mechanisms)

모든 에이전트는 폴백 경로 (Fallback path)를 가져야 합니다. 만약 LLM이 결정을 내리지 못하거나 도구 실행이 반복적으로 실패할 경우, 시스템은 우아하게 성능을 저하시켜야 (Gracefully degrade) 합니다. 이는 일반적인 에러 메시지를 반환하거나, 사람에게 에스컬레이션(Escalating)하거나, 정적이고 미리 정의된 답변을 제공하는 것을 의미할 수 있습니다.

결론: 마법이 아닌 엔지니어링 (Engineering Over Magic)

"마법 같은" AI의 시대는 끝났습니다. 신뢰할 수 있는 AI 에이전트를 구축하는 것은 더 이상 완벽한 프롬프트 (Prompt)를 찾는 문제가 아닙니다. 그것은 불확실성을 처리할 수 있는 견고한 시스템을 엔지니어링하는 문제입니다. 결정론적 로직 (Deterministic logic)을 강제하기 위해 유한 상태 머신 (Finite State Machines)을 통합하고, 숨겨진 비용을 추적하기 위해 엄격한 관측성 (Observability)을 구현하며, 처음부터 실패를 고려하여 설계함으로써, 우리는 취약한 프로토타입을 넘어 프로덕션급 에이전트 워크플로우 (Agentic workflows)로 나아갈 수 있습니다.

AI 엔지니어링의 미래는 LLM을 더 똑똑하게 만드는 것이 아니라, 그 주변의 시스템을 더 신뢰할 수 있게 만드는 데 있습니다. 다음 에이전트를 구축할 때 다음을 기억하십시오: LLM은 더 큰 결정론적 기계의 한 구성 요소일 뿐입니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: 어떤 LLM 제공업체와도 FSM을 사용할 수 있나요?

A: 네. FSM은 애플리케이션 코드(예: Python, TypeScript)에서 실행되는 아키텍처 패턴입니다. 이는 API 호출을 통해 LLM과 상호작용하므로 제공업체에 구애받지 않습니다 (Provider-agnostic). FSM 로직을 변경하지 않고도 OpenAI, Anthropic 또는 로컬 모델을 교체할 수 있습니다.

Q: 오래 걸리는 에이전트 워크플로우는 어떻게 처리하나요?

A: 몇 분 또는 몇 시간이 걸리는 워크플로우의 경우, 비동기 작업 큐 (Asynchronous task queues, 예: Celery, BullMQ)를 사용하고 FSM 상태를 데이터베이스에 영속화(Persist)하십시오. 이를 통해 시스템이 충돌로부터 복구하고 마지막 상태에서 재개할 수 있습니다.

Q: 오케스트레이터 (Orchestrator) 패턴이 멀티 에이전트 (Multi-Agent) 패턴보다 더 나은가요?

A: 상황에 따라 다릅니다. 오케스트레이터 (Orchestrator) 패턴은 워크플로우 (Workflow)에 대한 단일 진실 공급원 (Single source of truth)이 존재하기 때문에 일반적으로 더 결정론적 (Deterministic)이며 디버깅 (Debug)하기가 더 쉽습니다. 멀티 에이전트 (Multi-agent) 패턴 (에이전트들이 서로 대화하는 방식)은 더 유연하지만, 제어하고 디버깅하기가 훨씬 더 어렵습니다. 대부분의 사용 사례에서는 오케스트레이터 (Orchestrator)로 시작하십시오.