이전 기사에서 우리는 에이전트를 실용적인 방식으로 정의했습니다:

LLM 에이전트는 추론하고, 행동하고, 결과를 관찰하며, 다음에 무엇을 할지 결정할 수 있는 사이클 (cycle) 내에 있는 모델입니다.

이 정의는 정확합니다. 하지만 여전히 너무 추상적입니다.

오늘날 많은 사람들이 **바이브 코딩 (vibe coding)**으로 에이전트를 구축하고 있습니다. 모델에게 에이전트를 만들어 달라고 요청하고, 코드를 복사해서 실행하는 식입니다. 현재의 모델들은 코드를 작성하는 능력이 매우 뛰어나며, 이로 인해 그 과정이 마법처럼 느껴지기도 합니다.

문제는 기본 개념을 이해하지 못한 채 무언가를 구현하게 되는 경우가 많다는 점입니다.

개념을 이해하지 못하면, 모델이 필요 이상으로 복잡한 솔루션을 제안할 수 있습니다. 예를 들어, 단순한 **유한 상태 머신 (Finite State Machine, FSM)**만으로도 충분한 상황에서 **계층적 상태 머신 (Hierarchical State Machine, HSM)**을 제안할 수도 있습니다 (심지어 그것이 FSM인지 HSM인지조차 인지하지 못한 채 말이죠).

이것이 이 기사를 쓰는 이유입니다.

상황을 복잡하게 만들기 위해서가 아니라, 우리가 실제로 무엇을 구축하고 있는지 명확히 하기 위해서입니다.

핵심 질문은 다음과 같습니다:

에이전트의 사이클을 어떻게 명시적이고, 제어 가능하며, 확장 가능한 방식으로 모델링할 것인가?

그 답은 그것을 **상태 머신 (state machine)**으로 취급하는 것입니다.

상태 머신으로서의 Think-Act-Observe 사이클

에이전트의 가장 단순한 흐름을 상상해 봅시다:

1. 작업을 받음
2. 무엇을 할지 추론함
3. 도구를 사용할 필요가 있는지 결정함
4. 도구를 실행함
5. 결과를 관찰함
6. 종료할지 아니면 계속할지 결정함

이 흐름은 **유한 상태 머신 (Finite State Machine, FSM)**으로 완벽하게 모델링할 수 있습니다:

전환(transitions)은 각 단계의 결과에 따라 달라집니다.

이것이 바로 에이전트가 하는 일입니다.

단순한 상태 머신

여기 개념적인 예시(의사 코드)가 있습니다:

state = {
    "task": "CDK를 사용하여 API Gateway에 CORS 구현",
    "code": "",
...

이 패턴은 거의 모든 에이전트 프레임워크의 핵심입니다.

차이점은 상태 제어(state control)를 얼마나 명시적으로 수행하느냐에 있습니다.

Tools = 상태를 변화시키는 액션

도구(Tools)는 단순히 "추가적인 것"이 아닙니다.

도구는 관찰(observation)을 생성하며, 따라서 상태 머신의 상태를 변화시키는 액션입니다.

에이전트가 search_docs나 run_tests를 호출할 때, 실제로 수행하고 있는 작업은 다음과 같습니다:

1. thinking 상태에서 벗어남
2. acting 상태로 진입
3. 액션 실행
4. 관찰(observation) 수신
5. 상태 업데이트
6. 다음 전이(transition) 결정

도구를 이런 방식으로 생각하면 설계가 훨씬 더 명확해집니다:

• 잘 설계된 도구는 명확한 입출력 계약(contract)을 가집니다. 도구의 결과는 다음 전이를 결정하기 위해 해석될 수 있어야 합니다.
• 도구의 에러 처리(error handling)는 에러 상태(error state) 또는 복구 상태(recovery state)로의 전이가 됩니다.

머신이 복잡해질 때: 계층적 상태 머신 (Hierarchical State Machines)

평면적인 FSM(Finite State Machine)은 단순한 에이전트에게는 잘 작동합니다.

하지만 에이전트가 커지면 다음과 같은 문제들이 나타나기 시작합니다:

• 너무 많은 상태
• 추적하기 어려운 전이
• "조사 모드" 로직과 "구현 모드" 로직의 혼재
• 흐름의 일부를 재사용하기 어려움

여기서 **계층적 상태 머신 (Hierarchical State Machines, HSM)**이 등장합니다.

아이디어는 간단합니다: 하나의 상태가 또 다른 완전한 상태 머신을 포함할 수 있다는 것입니다.

예시:

resolver_tarea (상위 수준 상태)
├── investigar (조사)
│   ├── buscar_documentación (문서 검색)
...

각 하위 머신(sub-machine)은 자체적인 내부 상태를 가지지만, 부모 머신은 통합된 결과만을 봅니다.

이것은 숙련된 인간 개발자가 일하는 방식과 정확히 일치합니다. 모든 세부 사항을 동시에 생각하지 않습니다. "조사 모드"에 들어갔다가, 그 다음 "구현 모드"로 들어가는 식입니다.

LangGraph는 이를 어떻게 구현하는가

LangGraph는 실제로 이 접근 방식을 가장 깔끔하게 구현한 사례 중 하나입니다.

1. StateGraph = 상태 머신

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

...

• **State (상태)**는 공유되는 상태입니다.
• **nodes (노드)**는 상태를 업데이트하는 함수입니다.
• edges (엣지)(특히 조건부 엣지)는 전이(transitions)를 정의합니다.

2. Subgraphs = 계층적 상태 머신 (Hierarchical State Machines)

LangGraph는 하나의 그래프 전체를 다른 그래프의 노드로 삽입할 수 있게 해줍니다.

이것은 말 그대로 계층적 상태 머신 (Hierarchical State Machine)입니다.

두 가지 주요 패턴이 있습니다:

패턴 A - 공유 상태 (Shared State)

서브그래프 (subgraph)와 부모 그래프가 상태 키 (state keys)를 공유합니다.

# 서브그래프를 노드로 직접 추가합니다
builder.add_node("investigar", investigar_subgraph)

패턴 B - 격리된 상태 (Isolated State)

각 서브그래프는 고유한 스키마 (schema)를 가지며 명시적인 변환 과정을 거칩니다.

def call_investigar(state: AgentState):
    subgraph_input = {"query": state["task"]}
    result = investigar_subgraph.invoke(subgraph_input)
...

또한, LangGraph는 서브그래프별로 체크포인트 네임스페이스 (checkpoint namespaces)를 관리하여 다음을 가능하게 합니다:

• 각 서브 머신 (sub-machine)의 상태 격리
• 장애 발생 후 상태 복구
• 서브 프로세스 수준에서의 인간 참여 (human-in-the-loop) 구현

이는 데모 단계에서 실제 시스템으로 넘어갈 때 매우 강력한 힘을 발휘합니다.

언제 공식화(formalize)할 가치가 있을까요?

첫날부터 모든 것을 공식화할 필요는 없습니다.

하지만 흐름을 따라가기 어려워지기 시작할 때, 사이클을 상태 머신(state machine)으로(그리고 궁극적으로는 계층적 상태 머신으로) 변환하는 것이 자연스러운 다음 단계가 됩니다.

여기서 다시 처음의 논점으로 돌아갑니다. 만약 이러한 개념들이 명확하지 않다면, 실제로는 단순한 유한 상태 머신 (FSM)이 필요한 상황임에도 모델이 계층적 상태 머신 (HSM)을 제안하게 만들기 쉽습니다. 혹은 그 반대의 경우도 마찬가지입니다.

결론

Think Act Observe 사이클은 단순한 은유가 아닙니다.

그것은 상태 머신입니다.

**계층적 상태 머신 (Hierarchical State Machines)**은 시스템이 if문과 프롬프트의 미로로 변하지 않도록 하면서도, 그 아이디어를 확장할 수 있게 해줍니다.

그리고 LangGraph와 같은 프레임워크는 이를 깔끔하게 구현할 수 있는 정확한 프리미티브 (Primitives)를 제공합니다: StateGraph + Subgraphs.

요약:

에이전트는 단순히 도구 (Tools)를 가진 모델이 아닙니다.

그것은 상태 머신 (State Machine, 계층적일 수 있음) 내에서 작동하는 모델입니다.

이것을 이해하는 것은 우리가 에이전트를 설계하고, 디버깅(Debug)하며, 운영하는 방식을 상당히 변화시킵니다.