원문은 tamiz.pro에 게시되었습니다.

현재의 생성형 AI (Generative AI) 파도는 복잡한 작업을 자율적으로 계획, 실행 및 성찰한다고 주장하는 시스템인 "AI 에이전트 (AI Agents)"의 홍수를 일으켰습니다. 하이프 (Hype)는 실재하지만, 엔지니어링 측면의 현실은 종종 무질서합니다. LLM (Large Language Models)은 비결정론적 (Non-deterministic)이며, 비용이 많이 들고, 자신의 워크플로 로직 (Workflow logic)을 관리하도록 요청받을 때 환각 (Hallucination) 현상이 발생하기 쉽습니다. 가장 강력한 프로덕션 에이전트들은 다음에 무엇을 할지 결정하기 위해 LLM에 의존하지 않습니다. 대신, 엄격하고 결정론적인 제어 흐름 (Control flow) 내에서 특정 단계를 어떻게 실행할지 결정하는 데 LLM을 사용합니다.

이 지점에서 유한 상태 머신 (Finite State Machines, FSMs)과 그보다 더 표현력이 풍부한 사촌 격인 상태 차트 (Statecharts)가 필수적이 됩니다. 제어 로직을 명시적인 상태 관리 (State management)로 오프로딩 (Offloading)함으로써, 관찰 가능성 (Observability), 결정론 (Determinism), 그리고 상당한 비용 절감을 얻을 수 있습니다. 이 기사에서는 AI 에이전트를 위한 FSM 엔지니어링의 아키텍처 패턴, 구현 전략 및 트레이드오프 (Trade-offs)를 깊이 있게 다룹니다.

에이전트 시스템에서의 결정론 문제 (The Determinism Problem)

AI 에이전트의 신뢰성 위기의 핵심은 구조의 부재입니다. "경쟁사를 조사하고 보고서를 작성하라"는 과제를 맡은 간단한 에이전트를 생각해 보십시오. 단순한 구현 방식은 다음과 같은 지침 목록이 포함된 단일 시스템 프롬프트 (System prompt)를 사용할 수 있습니다:

1. 경쟁사 A를 검색합니다.
2. 경쟁사 B를 검색합니다.
3. 조사 결과 요약합니다.
4. 보고서를 작성합니다.

LLM은 도구 호출 (Tool-calling) 제약 조건을 무시하고 이 모든 것을 한 번의 턴 (Turn)에 수행하려고 시도할 수 있습니다. 주의가 분산되어 경쟁사 B에 대한 데이터를 환각 (Hallucinate)할 수도 있습니다. 보고서를 쓰기 전에 요약하는 것을 잊어버릴 수도 있습니다. "다음에 무엇을 해야 하는가"에 대한 상태가 LLM의 컨텍스트 윈도우 (Context window)와 내부 가중치 (Internal weights)에 인코딩되어 있기 때문에, 이는 일시적이고 취약합니다.

FSM은 상태를 외부화함으로써 이 문제를 해결합니다. 에이전트의 "두뇌" (LLM)는 현재 상태에 필요한 의미론적 이해와 생성만을 처리합니다. "골격" (FSM)은 흐름을 관리합니다. 이러한 관심사의 분리 (Separation of concerns)를 통해 다음과 같은 이점을 얻을 수 있습니다:

• 결정론적 실행 (Deterministic Execution): 상태 A에서 상태 B로의 전환은 확률이 아닌 코드로 보장됩니다.
• 비용 제어 (Cost Control): 모든 로직 체크마다 호출하는 것이 아니라, 필요한 경우(예: 텍스트 생성 시)에만 비용이 많이 드는 LLM을 호출합니다.
• 디버깅 가능성 (Debuggability): 길고 환각(Hallucination)이 섞인 대화 기록을 뒤지는 대신, 에이전트가 실패했을 당시의 정확한 상태를 조사할 수 있습니다.

핵심 개념: FSM vs. 상태 차트 (Statecharts)

"유한 상태 머신 (Finite State Machine)"이 일반적인 용어이지만, 현대적인 에이전트 프레임워크는 종종 상태 차트 (Statecharts) (Harel Statecharts)를 통해 이득을 얻습니다. FSM은 상태와 전이 (Transitions)로 이루어진 단순한 그래프입니다. 상태 차트는 계층적 상태 (Hierarchical states), 병렬 상태 (Concurrent states), 그리고 히스토리 상태 (History states)를 추가하며, 이는 복잡한 에이전트 워크플로우에 매우 중요합니다.

FSM 모델

기본적인 FSM은 다음으로 구성됩니다:

• 상태 (States): 에이전트 생명주기의 별도 단계들을 나타냅니다 (예: Idle, Searching, Analyzing, Writing).
• 전이 (Transitions): 이벤트(예: search_complete, analysis_error)에 의해 트리거되어 에이전트를 한 상태에서 다른 상태로 이동시키는 규칙입니다.
• 액션 (Actions): 상태에 진입하거나 전이 중에 실행되는 코드입니다.

상태 차트의 장점

AI 에이전트에게 계층적 상태는 매우 강력합니다. 예를 들어, WebSearch와 DocumentReview라는 자식 상태를 가진 Researching이라는 부모 상태를 가질 수 있습니다. 만약 DocumentReview가 실패하면, 에이전트 전체를 실패시키는 대신 Researching 레벨에서 오류를 포착하고 전체 조사 단계를 재시도할 수 있습니다. 이러한 수준의 세밀함(Granularity)은 평면적인(Flat) FSM으로는 달성하기 어렵습니다.

에이전트 FSM을 위한 아키텍처 패턴

FSM을 LLM과 통합하는 데에는 세 가지 주요 패턴이 있습니다. 각 패턴은 지연 시간 (Latency), 복잡성, 그리고 비용 측면에서 서로 다른 트레이드오프 (Trade-offs)를 가집니다.

패턴 1: 오케스트레이터 패턴 (The Orchestrator Pattern)

이 패턴에서 FSM은 중앙 컨트롤러 (Central Controller) 역할을 합니다. LLM은 FSM이 호출하는 "서비스 (Service)"입니다. FSM은 현재 상태를 기반으로 다음에 어떤 도구(Tool)나 LLM 작업을 호출할지 결정합니다.

# 단순화된 개념적 표현
agent_state = AgentState.IDLE

...

장점 (Pros): 최대의 제어권. 특정 전이 (Transitions) 단계에서 재시도 (Retries), 타임아웃 (Timeouts), 그리고 인간 참여 (Human-in-the-loop) 확인 절차를 삽입할 수 있습니다.
단점 (Cons): 더 높은 지연 시간 (Latency). FSM 루프가 오버헤드 (Overhead)를 추가하며, LLM 호출을 쉽게 병렬화할 수 없습니다.

패턴 2: 라우터 패턴 (The Router Pattern)

여기서 FSM은 최소한의 역할만 수행하며, 종종 Plan -> Execute -> Reflect와 같은 이진 또는 삼진 선택만을 수행합니다. LLM은 계획 (Plan)을 생성하는 책임을 지며, FSM은 해당 계획이 순차적으로 실행되도록 보장합니다. 이는 ReAct (Reasoning + Acting) 패턴에서 흔히 볼 수 있습니다.

장점 (Pros): 구현이 더 간단함. LLM의 계획 능력을 활용함.
단점 (Cons): 결정론적 (Deterministic) 성격이 낮음. 만약 LLM의 계획에 결함이 있다면, FSM은 잘못된 지침을 충실히 실행하게 됩니다.

패턴 3: 계층적 상태차트 패턴 (The Hierarchical Statechart Pattern)

이것은 엔터프라이즈급 (Enterprise-grade) 접근 방식입니다. 중첩된 상태 (Nested states)를 가진 상태차트 (Statechart)를 정의합니다. LLM은 특정 "리프 (Leaf)" 상태에서 호출됩니다. 상태 간의 전이는 코드로 처리됩니다.

예를 들어, SupportAgent는 Triage라는 상태를 가질 수 있습니다. Triage 내부에는 IntentRecognition 및 DataCollection을 위한 하위 상태 (Sub-states)가 있습니다. 만약 IntentRecognition이 실패하면, 에이전트는 DataCollection이 아닌 Escalate로 전이합니다.

장점 (Pros): 높은 확장성 및 유지보수성. 복잡한 워크플로우 (Workflows) 관리가 가능함.
단점 (Cons): 높은 초기 개발 비용. 견고한 상태차트 라이브러리가 필요함.

XState 및 LangGraph를 이용한 구현

JavaScript/TypeScript와 Python 환경에서 각각 이러한 패턴들을 구현하는 데 있어 두 가지 라이브러리가 시장을 주도하고 있습니다.

XState (JavaScript/TypeScript)

XState는 JS 환경에서 FSM을 위한 표준 (Gold standard)입니다. 상태 머신 (State machines)과 상태차트 (Statecharts)를 정의하는 선언적 (Declarative)인 방법을 제공합니다.

import { createMachine, interpret } from 'xstate';

const agentMachine = createMachine({
...

이 예시에서 LLM은 researching 상태 내에서 invoke 서비스로 호출됩니다. FSM은 LLM에게 "그게 잘 작동했나요?"라고 물어볼 필요 없이 결정론적(deterministically)으로 재시도 로직을 처리합니다.

LangGraph (Python)

LangChain을 기반으로 구축된 LangGraph는 상태 차트(statecharts)와 잘 부합하는 그래프 기반 접근 방식을 제공합니다. 이는 순환 그래프(cyclic graphs)를 허용하며, 이는 루프를 돌아야 할 수도 있는 에이전트(예: 검색 결과가 불충분한 경우)에게 필수적입니다.

from langgraph.graph import StateGraph, START, END
from typing import TypedDict

...

LangGraph의 강점은 사이클(cycles)과 조건부 엣지(conditional edges)를 자연스럽게 처리하는 능력에 있으며, 이는 LLM 출력에 따라 반복 작업이 필요한 에이전트에게 이상적입니다.

상태 관리를 통한 비용 최적화

FSM의 가장 간과되는 이점 중 하나는 비용 제어입니다. LLM 호출은 특히 컨텍스트 윈도우(context windows)가 클 때 비용이 많이 듭니다. FSM을 사용하면 다음과 같은 작업이 가능합니다:

1. 상태 캐싱 (Cache State): 에이전트가 이전 상태(예: retrying)로 다시 전환되는 경우, 초기 상태의 컨텍스트를 재사용하여 대규모 프롬프트를 다시 보내는 것을 방지할 수 있습니다.
2. 컨텍스트 윈도우 제한 (Limit Context Window): 작업을 개별적인 상태로 분리함으로써 상태 간에 대화 기록을 초기화할 수 있으며, 이를 통해 컨텍스트 윈도우를 작고 저렴하게 유지할 수 있습니다.
3. 무한 루프 방지 (Prevent Infinite Loops): 단순한 ReAct 루프는 "생각(think) -> 행동(act) -> 생각 -> 행동..."의 무한 루프에 빠져 수백 달러의 비용을 발생시킬 수 있습니다. 최대 깊이(maximum depth)나 명시적인 종료 조건이 있는 FSM은 이를 방지합니다.

비결정론 및 오류 처리

FSM을 사용하더라도 LLM은 비결정론적(non-deterministic)입니다. 상태 전환(state transitions) 시 LLM의 실패를 반드시 고려해야 합니다.

전환 시 검증 (Validation at Transitions)

LLM이 자신의 출력을 스스로 검증하도록 절대 신뢰하지 마세요. FSM 전환을 사용하여 검증 코드를 트리거하십시오. 예를 들어, 에이전트가 generating_sql 상태에 있는 경우, executing_sql로의 전환은 생성된 SQL이 정적 분석(static analysis) 검사를 통과했을 때만 이루어져야 합니다.

// XState에서는 가드(guards)를 사용할 수 있습니다
const machine = createMachine({
  states: {
...

Human-in-the-Loop (인간 참여형 루프)

FSM(유한 상태 머신)을 사용하면 인간의 승인 단계를 삽입하는 것이 매우 간단해집니다. 사용자 상호작용 이벤트가 수신될 때까지 실행을 일시 중단하는 awaiting_approval 상태를 추가할 수 있습니다. 이는 높은 이해관계가 걸린 에이전트(예: 이메일을 보내거나 코드를 배포하는 에이전트)에게 매우 중요합니다.

FSM을 사용하지 말아야 할 때

FSM은 만능 해결책(silver bullet)이 아닙니다. 다음과 같은 경우에는 사용을 피하십시오:

1. 단순 체이닝 (Simple Chaining): 단순히 하나의 LLM 출력을 다른 LLM으로 전달하기만 하면 된다면, 단순한 순차적 파이프라인(sequential pipeline)으로 충분합니다. FSM은 불필요한 복잡성을 더합니다.
2. 고도의 창의적 작업 (Highly Creative Tasks): 브레인스토밍이나 개방형 글쓰기와 같은 작업의 경우, 경직된 상태 구조는 창의성을 저해할 수 있습니다. FSM은 창의적인 콘텐츠 자체가 아니라 글쓰기의 과정(개요 -> 초안 -> 편집)을 위해 사용하십시오.
3. 실시간 스트리밍 (Real-Time Streaming): 1초 미만의 응답 시간이 필요한 경우, 상태 관리(state management)와 컨텍스트 스위칭(context switching)의 오버헤드가 너무 높을 수 있습니다. 더 단순한 프롬프트 엔지니어링(prompt engineering) 기법을 고려하십시오.

프로덕션을 위한 베스트 프랙티스 (Best Practices)

1. 상태 차트(Statechart) 시각화: XState Viz 또는 LangGraph Studio와 같은 도구를 사용하여 에이전트의 흐름을 시각화하십시오. 시각화할 수 없다면 디버깅할 수도 없습니다.
2. 상태 변경 로그 기록: 모든 전이(transition)는 입력, 출력 및 타임스탬프와 함께 로그로 기록되어야 합니다. 이것이 여러분의 주요 디버깅 도구입니다.
3. 상태를 원자적(Atomic)으로 유지: 각 상태는 단일하고 응집력 있는 작업 단위를 나타내야 합니다. working_on_thing_1_and_2와 같은 상태는 피하십시오.
4. 히스토리 상태(History States) 사용: 상태 차트(Statecharts)에서 히스토리 상태를 사용하여 하위 상태(sub-state)에서 멈춘 지점을 기억하게 함으로써, 중단 후에도 원활한 재개를 가능하게 하십시오.
5. 전이(Transitions) 테스트: LLM 통합과는 별개로 상태 머신 로직에 대한 단위 테스트(unit tests)를 작성하십시오. 이를 통해 LLM의 가변성을 다루기 전에 제어 흐름(control flow)이 올바른지 확인할 수 있습니다.

결론

AI 에이전트의 "하이프 (hype)"는 그 잠재력에 있지만, "엔지니어링 (engineering)"은 그 신뢰성에 있습니다. 유한 상태 머신 (Finite State Machines)과 상태 차트 (Statecharts)를 채택함으로써, 여러분은 취약하고 확률적인 프롬프트를 견고하고 결정론적인 (deterministic) 시스템으로 변환할 수 있습니다. 이를 통해 디버깅, 비용 최적화, 그리고 에이전트를 자신 있게 확장할 수 있는 능력을 얻게 됩니다. 산업이 성숙해짐에 따라, 살아남는 에이전트는 단순히 영리한 프롬프트가 아니라 탄탄한 아키텍처 기반 위에 구축된 에이전트가 될 것입니다.

프로덕션급 AI 엔지니어링에 대한 더 많은 통찰력을 얻으려면, 소프트웨어의 미래를 형성하는 도구와 패턴에 대한 심층 분석을 제공하는 Tamiz's Insights를 확인해 보세요.

자주 묻는 질문 (Frequently Asked Questions)

Q: 어떤 LLM 프레임워크와도 FSM을 사용할 수 있나요?
A: 네. FSM은 라이브러리가 아니라 디자인 패턴 (design pattern)입니다. LangChain, LlamaIndex, 또는 심지어 순수 API 호출에서도 구현할 수 있습니다. XState (JS) 및 LangGraph (Python)와 같은 라이브러리는 이를 더 쉽게 만들어주는 추상화 (abstractions)를 제공합니다.

Q: FSM에서 오래 걸리는 작업은 어떻게 처리하나요?
A: 비동기 전이 (asynchronous transitions)를 사용하십시오. XState에서는 Promise를 반환하는 서비스와 함께 invoke를 사용할 수 있습니다. FSM은 Promise가 해결(resolve)될 때까지 현재 상태에서 일시 중지되며, 그 시점에 적절한 전이를 트리거합니다.

Q: FSM이 단순한 ReAct 루프보다 나은가요?
A: 오류 처리 및 재시도가 필요한 복잡한 다단계 작업의 경우 그렇습니다. 단순한 단일 단계 쿼리의 경우, ReAct 루프나 심지어 단일 프롬프트만으로도 충분합니다. FSM은 제어와 신뢰성의 필요성에 의해서만 정당화되는 복잡성을 추가합니다.