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

2024년과 2025년 초, 업계의 담론은 단 하나의 지표, 즉 파라미터 수(parameter count)에 의해 지배되었습니다. 우리는 LLM을 충분히 크게 만들고, 충분히 똑똑하게 만들며, 컨텍스트 윈도우(context-window)를 충분히 넓게 만들기만 하면 자율 에이전트(autonomous agents)가 자연스럽게 견고하고 신뢰할 수 있는 소프트웨어 구성 요소로 등장할 것이라고 믿었습니다. 우리는 LLM을 범용 논리 엔진(general-purpose logic engine)으로 취급하며, 이를 도구 호출(tool calls) 루프에 연결하고 결정론적인 결과(deterministic outcomes)를 기대했습니다.

그 실험은 실패했습니다. LLM이 강력하지 않아서가 아니라, 우리가 확률론적 기본 요소(probabilistic primitives)를 사용하여 결정론적 엔지니어링 문제를 해결하려 했기 때문입니다. 2026년까지 가장 신뢰할 수 있고 확장 가능하며 비용 효율적인 에이전트 아키텍처는 더 이상 기반 모델의 크기에 의해 정의되지 않고, 이를 둘러싼 아키텍처의 엄격함에 의해 정의될 것입니다. 승자들은 제어 흐름(control flow)을 강제하기 위해 유한 상태 머신(Finite State Machines, FSMs)을 사용하고, 컨텍스트를 관리하기 위해 정교한 인덱싱 레이어(indexing layers)를 사용하며, 실행을 제한하기 위해 엄격한 인프라 제약(infrastructure constraints)을 사용하고 있습니다.

이 글은 왜 "가공되지 않은 힘(raw power)"이 함정인지, 그리고 오늘날 프로덕션 환경에서 실제로 작동하는 에이전트를 어떻게 구축할 수 있는지 분석합니다.

확률론적 논리의 함정

초기 에이전트 설계의 근본적인 실수는 LLM이 복잡하고 다단계인 워크플로우(workflows)를 위한 주요 제어 평면(control plane) 역할을 할 수 있다는 가정이었습니다. LLM은 자기회귀적 다음 토큰 예측기(autoregressive next-token predictors)입니다. 이들은 패턴 매칭, 합성 및 창의적 생성에는 뛰어나지만, 결정론적인 상태 관리(state management), 오류 복구(error recovery) 또는 엄격한 논리적 분기(logical branching)에는 뛰어나지 않습니다.

간단한 금융 거래 에이전트를 생각해 보십시오. 2024년의 일반적인 아키텍처는 다음과 같았습니다:

1. 사용자가 송금을 요청합니다.
2. LLM이 금액, 수취인 및 계좌를 추출합니다.
3. LLM이 transfer_funds를 호출하기로 결정합니다.
4. LLM이 JSON을 형식화합니다.
5. 시스템이 실행합니다.

이 과정은 API가 402 Payment Required를 반환하는 예외 상황이나, 환각(hallucination)으로 인해 쉼표(comma)가 잘못 생성되어 JSON 파싱에 실패하는 경우, 혹은 LLM이 스스로 '그럴 것 같다'고 판단하여 transfer_funds를 두 번 호출하기로 결정하는 등의 엣지 케이스를 만날 때까지는 간단해 보입니다. 확률적 시스템에서 이러한 상황들은 버그가 아니라 통계적 가능성일 뿐입니다. 그리고 프로덕션 환경에서는 치명적입니다.

함정은 더 많은 토큰, 더 큰 컨텍스트 윈도우, 또는 고급 추론 모델(예: o1이나 유사한 아키텍처)이 이 문제를 해결해 줄 것이라고 믿는 것입니다. 그렇지 않습니다. 그것들은 단지 환각을 더 정교하게 만들고 지연 시간(latency)만 높일 뿐입니다. 결정론적(Determinism) 특성은 내부에서 생성되는 것이 아니라 외부에서 부과되어야 합니다.

유한 상태 기계 (Finite State Machines): 신뢰성의 핵심 기반

2026년 에이전트 설계에서 가장 중요한 아키텍처 변화는 '추론(reasoning)'을 '제어(control)'로부터 분리하는 것입니다. LLM은 더 이상 작동의 두뇌가 아닙니다. 그것은 감각 기관입니다. 두뇌는 결정론적인 유한 상태 기계(FSM) 또는 방향성 비순환 그래프(DAG) 오케스트레이터입니다.

FSM이 Chain-of-Thought를 능가하는 이유

Chain-of-Thought (CoT) 프롬프팅은 LLM에게 자신의 작업 과정을 보여주도록 강제하려는 시도입니다. 이는 취약합니다. LLM은 단계를 건너뛰거나, 반복하거나, 스스로 모순될 수 있습니다. 반면 FSM은 다음을 보장합니다:

1. 시스템이 항상 유효한 상태에 있다. 인증하지 않았다면 자금을 이체할 수 없습니다.
2. 전환(Transitions)이 명시적이다. State A에서 State B로의 모든 이동은 특정 조건에 의해 정의됩니다.
3. 복구(Recovery)가 구조화되어 있다. 단계가 실패하면, FSM은 '재고민'을 위해 LLM으로 돌아가는 것이 아니라 특정 오류 처리기(error handler)로 경로를 지정합니다.

제어 계층 FSM 구현하기

실제 사례에서 이것이 어떻게 보이는지 살펴보겠습니다. LLM에게 흐름을 결정하게 하는 대신, 우리는 흐름을 정의하고 LLM은 상태 전환을 위한 데이터 추출에만 사용합니다.

// types.ts
export type AgentState = 
  | { type: 'INIT' }
...```

여기서 복잡한 프롬프팅 (prompting)이 없다는 점에 주목하세요. LLM은 의도 추출 (intent extraction)이라는 단일하고 명확하게 정의된 작업에만 사용됩니다. 상태 전이 (state transitions)는 TypeScript 로직에 의해 처리됩니다. 이는 시스템을 디버깅 가능하고, 테스트 가능하며, 신뢰할 수 있게 만듭니다.

## 인덱싱 병목 현상: RAG는 만능 해결책이 아니다

FSM이 제어 문제를 해결하는 동안, 데이터 문제는 여전히 남아 있습니다. 초기 에이전트들은 단순한 검색 증강 생성 (RAG, Retrieval-Augmented Generation)에 의존했습니다. 즉, 텍스트를 청크 (chunk)로 나누고, 임베딩 (embed)한 뒤, 벡터 데이터베이스 (vector database)에 저장하고, 상위 k개의 결과 (top-k results)를 검색하는 방식입니다. 이 접근 방식은 2026년에는 실패하고 있는데, 그 이유는 구조, 관계, 그리고 시간적 역학 (temporal dynamics)을 무시한 채 모든 데이터를 동일하게 관련 있는 것으로 취급하기 때문입니다.

### 단순 벡터 검색의 실패

벡터 유사도 검색 (vector similarity search)은 의미론적 매칭 (semantic matching)에는 뛰어나지만, 정확한 매칭 (exact matching), 논리적 필터링 (logical filtering), 그리고 계층적 탐색 (hierarchical navigation)에는 취약합니다. 판례를 검색하는 법률 에이전트를 가정해 봅시다. "계약 분쟁 (Contract dispute)"은 의미론적으로 "고용 갈등 (employment conflict)"과 유사할 수 있지만, 법적으로는 별개의 개념입니다. 벡터 검색은 관련 없는 결과를 반환할 수 있으며, 이는 LLM이 잘못된 연결을 만들어내는 환각 (hallucination) 현상으로 이어질 수 있습니다.

### 고급 인덱싱 전략

새로운 표준은 **하이브리드 인덱싱 (Hybrid Indexing)**입니다. 이는 다음을 결합합니다:

1. **벡터 임베딩 (Vector Embeddings)**: 의미론적 이해를 위함.
2. **희소 키워드 검색 (Sparse Keyword Search, BM25)**: 정확한 용어 매칭 및 필터링을 위함.
3. **그래프 구조 (Graph Structures)**: 관계 매핑 (예: 엔티티-관계 그래프, Entity-Relationship graphs)을 위함.
4. **메타데이터 필터링 (Metadata Filtering)**: 엄격한 제약 조건 (예: 날짜 범위, 사용자 권한)을 위함.

#### 예시: 하이브리드 쿼리 실행

```python
# hybrid_retriever.py
from typing import List, Dict
import numpy as np
...

하이브리드 인덱싱을 사용하면 컨텍스트 윈도우 (context window) 내의 노이즈를 줄일 수 있습니다. 이를 통해 더 작고 저렴한 LLM도 더 높은 신호 (signal)를 가진 데이터를 공급받아 더 나은 성능을 발휘할 수 있습니다. 또한 LLM이 모호한 의미론적 매칭에 기반해 추측하지 않으므로 환각 발생률도 낮아집니다.

인프라 제약: 숨겨진 레버

현대 에이전트 아키텍처의 세 번째 기둥은 **인프라 제약 (infrastructure constraint)**입니다. 2024년에는 에이전트가 종종 최소한의 제한만 있는 상태로 배포되어, 통제 불가능한 토큰 소비, 무한 루프, 그리고 비용 초과 문제를 야기했습니다. 2026년의 인프라는 엄격한 경계(hard boundaries)를 강제하도록 설계됩니다.

1. 토큰 및 비용 예산 (Token and Cost Budgets)

모든 에이전트 호출(invocation)은 사전에 할당된 예산을 가져야 합니다. 여기에는 입력 토큰, 출력 토큰, 그리고 도구 호출(tool call) 토큰이 포함됩니다. 만약 에이전트가 예산을 초과하면, 해당 프로세스는 종료되며 결과는 검토를 위해 플래그(flag) 처리됩니다.

{
  "agent_id": "finance-bot-v1",
  "budgets": {
...

2. 도구 호출을 위한 서킷 브레이커 (Circuit Breakers for Tool Calls)

도구(API, 데이터베이스)는 외부 시스템입니다. 이들은 실패할 수 있고, 느릴 수 있으며, 속도 제한(rate-limited)이 걸릴 수 있습니다. 여러분의 에이전트 아키텍처에는 반드시 서킷 브레이커 (circuit breakers)가 포함되어야 합니다.

• 지연 시간 서킷 브레이커 (Latency Circuit Breaker): 도구 호출이 X ms보다 오래 걸리면, 중단하고 에러를 반환합니다.
• 에러 서킷 브레이커 (Error Circuit Breaker): 특정 시간 범위 내에서 도구가 Y% 이상의 에러를 반환하면, 해당 도구를 일시적으로 비활성화합니다.
• 속도 제한 서킷 브레이커 (Rate Limit Circuit Breaker): 지수 백오프 (exponential backoff)를 사용하여 API 속도 제한을 공격적으로 준수합니다.

3. 결정론적 폴백 (Deterministic Fallbacks)

LLM이 의도(intent)를 추출하는 데 실패하거나 도구가 실패할 경우, 결정론적 폴백 (deterministic fallbacks)이 필요합니다. 이는 단순히

1. 입력 계층 (Input Layer): 사용자 입력이 수신됩니다.
2. 제어 평면 (Control Plane (FSM)): 유한 상태 머신 (FSM)이 WAITING_FOR_INTENT 상태로 이동합니다.
3. 추론 계층 (Reasoning Layer (LLM)): 작고 빠르며 저렴한 LLM (예: 7B-13B 파라미터)이 의도 (intent)와 파라미터 (parameters)를 추출합니다. LLM은 흐름을 결정하지 않습니다.
4. 검증 계층 (Validation Layer (Deterministic)): FSM이 추출된 파라미터를 비즈니스 규칙에 따라 검증합니다.
5. 검색 계층 (Retrieval Layer (Hybrid Index)): 작업에 지식이 필요한 경우, 하이브리드 검색기 (hybrid retriever)가 관련 컨텍스트 (context)를 가져옵니다.
6. 실행 계층 (Execution Layer (Tools)): FSM이 적절한 도구 (tool)를 호출합니다. 인프라 제약 사항 (circuit breakers, 예산 등)이 여기서 강제됩니다.
7. 출력 계층 (Output Layer): FSM이 결과를 형식화하고 COMPLETING 상태로 이동합니다.

이 아키텍처는 **모듈형 (modular)**이며, **테스트 가능 (testable)**하고, **비용 효율적 (cost-effective)**입니다. 이는 LLM이 완벽하기를 기대하지 않습니다. 대신 LLM이 가장 잘하는 분야인 언어 이해에 집중하도록 합니다. 나머지는 결정론적인 소프트웨어 엔지니어링 원칙에 의해 처리됩니다.

결론: 과장된 광고보다 엔지니어링

"에이전트 아키텍처의 함정 (Agent Architecture Trap)"은 지능만으로 복잡성을 해결할 수 있다는 믿음입니다. 그렇지 않습니다. 복잡성은 구조를 통해 해결됩니다. 2026년까지 가장 성공적인 AI 애플리케이션은 가장 큰 모델을 가진 것이 아니라, 가장 뛰어난 아키텍처를 가진 애플리케이션이 될 것입니다. 이들은 로직을 강제하기 위해 FSM을 사용하고, 신호를 제공하기 위해 하이브리드 인덱싱 (hybrid indexing)을 사용하며, 안전을 보장하기 위해 인프라 제약 사항을 사용합니다.

만약 여러분이 오늘 에이전트를 구축하고 있다면, "내 LLM은 얼마나 커야 하는가?"라는 질문을 멈추십시오. 대신 다음과 같이 질문하기 시작하십시오:

• 제어 흐름 (control flow)이 어떻게 정의되어 있는가?
• 데이터를 어떻게 검색하고 필터링하는가?
• 문제가 발생했을 때 어떤 일이 일어나는가?

AI의 미래는 단순히 더 똑똑한 모델에 관한 것이 아닙니다. 그것은 더 나은 엔지니어링에 관한 것입니다. 그리고 그것은 우리가 해결 방법을 알고 있는 문제입니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: 이 아키텍처에서 거대 LLM (100B+ 파라미터)을 사용하는 것이 가치가 있을까요?
A: 특정 고난도 추론 작업(예: 복잡한 코드 생성, 창의적 글쓰기)의 경우 그렇습니다. 하지만 대부분의 에이전트 워크플로우(의도 추출 (intent extraction), 요약 (summarization), 데이터 포맷팅 (data formatting))에서는 견고한 FSM 및 인덱싱 레이어와 결합된 작고 미세 조정된 모델 (7B-13B)이 더 빠르고 저렴하며 종종 더 신뢰할 수 있습니다.

Q: FSM을 사용하여 멀티턴 대화 (multi-turn conversations)를 어떻게 처리하나요?
A: FSM은 "대화 기록 (conversation history)" 상태를 유지해야 합니다. 각 턴은 상태의 서브 그래프(예: ASK_QUESTION -> WAIT_FOR_ANSWER -> VALIDATE_ANSWER)를 통과하는 과정을 포함합니다. LLM은 다음 질문을 생성하거나 기록을 요약하는 데 사용되지만, 대화의 흐름은 FSM이 제어합니다.

Q: 에이전트용 FSM을 구축하는 데 가장 좋은 도구는 무엇인가요?
A: 인기 있는 선택지로는 XState (JavaScript/TypeScript), Stateflow (MATLAB), 그리고 LLM 노드를 사용하여 상태 그래프를 정의할 수 있는 LangGraph (Python/JS)가 있습니다. 순수하게 결정론적인 제어 (deterministic control)가 필요한 경우, 장기 실행되는 에이전트 프로세스를 위해 Temporal 또는 Airflow와 같은 워크플로우 엔진 (workflow engine) 사용을 고려하십시오.