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

개발자가 깊은 구조적 감독 없이 자연어 프롬프트를 통해 대규모 언어 모델(LLMs)에 의존하여 전체 애플리케이션을 생성하는 "바이브 코딩 (vibe coding)"의 시대가 한계에 부딪히고 있습니다. LLMs는 보일러플레이트(boilerplate) 생성, 단위 테스트(unit tests) 작성, 또는 레거시 코드 리팩토링(refactoring)에는 탁월하지만, 근본적으로는 확률론적 엔진(probabilistic engines)입니다. 이들은 결정론적 상태 관리(deterministic state management), 지속적 메모리(persistent memory), 그리고 엄격한 안전 제약 조건(hard safety constraints)이 부족합니다.

프로토타이핑에서 프로덕션급 AI 통합으로 이동함에 따라, AI 에이전트의 아키텍처는 진화해야 합니다. 우리는 더 이상 LLM을 마법 같은 블랙박스(black box)로 취급할 수 없습니다. 대신, 생성 모델의 창의성과 전통적인 소프트웨어 엔지니어링의 엄격함을 결합하여 **회복 탄력적인 AI 에이전트 (resilient AI agents)**를 설계해야 합니다. 이 글에서는 현대 AI 엔지니어링의 세 가지 요소인 결정론적 제어 흐름을 위한 유한 상태 머신 (Finite State Machines, FSMs), 데이터 보안을 위한 로컬 개인정보 보호 계층 (Local Privacy Layers), 그리고 경제적 생존 가능성을 위한 **비용 제어 (Cost Controls)**를 탐구합니다.

순수 생성형 아키텍처의 문제점

전형적인 "바이브 코딩 (vibe-coded)" 시나리오에서 에이전트는 다음과 같은 시스템 프롬프트(system prompt)를 받을 수 있습니다:

system_prompt = "당신은 유능한 비서입니다. 사용자가 항공권을 예약하도록 도와주세요. 사용자가 목적지를 언급하면 항공권을 검색하세요. 사용자가 날짜를 언급하면 예약하세요."

이러한 접근 방식은 세 가지 결정적인 이유로 프로덕션 환경에서 실패합니다:

이러한 접근 방식은 세 가지 결정적인 이유로 프로덕션 환경에서 실패합니다:

1. 비결정성 (Non-Determinism): LLM이 항공편 번호를 환각(hallucinate)하거나, 단계를 건너뛰거나, '예약'을 '나중에 보류 예약'으로 해석하여 예약을 거부할 수 있습니다. 금융 또는 의료 상황에서 이는 용납될 수 없습니다.
2. 무상태성 (Statelessness): LLM은 컨텍스트 창에 명시적으로 전달되지 않는 한 턴(turn) 간의 상태를 유지하지 못합니다. 대화 기록을 관리하는 것은 컨텍스트 블로트(context bloat), 지연 시간 증가, 그리고 기하급수적인 비용 증가를 초래합니다.
3. 보안 위험 (Security Risks): 민감한 사용자 데이터(PII, 기업 비밀)를 공개 LLM API에 직접 전송하는 것은 심각한 개인 정보 보호 및 규정 준수 취약점(GDPR, HIPAA, SOC2)을 야기합니다.

회복 탄력적인 에이전트를 구축하려면, 우리는 LLM을 결정론적 아키텍처로 감싸야 합니다. 바로 이 지점에서 유한 상태 기계(Finite State Machines, FSMs), 로컬 처리, 그리고 엄격한 비용 제어가 중요해집니다.

1. 유한 상태 기계를 이용한 결정론적 제어 (Deterministic Control with Finite State Machines, FSMs)

FSM은 계산의 수학적 모델입니다. 이는 유한한 수의 상태(states), 그 상태들 간의 전이(transitions), 그리고 행동(actions)으로 구성됩니다. AI 에이전트의 맥락에서 FSM은 '뇌' 또는 오케스트레이터 역할을 하며, LLM은 사용자 의도를 해석하고 응답을 생성하는 '감각 기관' 역할을 합니다.

왜 FSM인가?

• 예측 가능성 (Predictability): 각 상태에서 허용되는 행동을 정확하게 정의할 수 있습니다. LLM이 FSM에 의해 정의된 경로를 벗어날 수 없습니다.
• 오류 처리 (Error Handling): 만약 LLM이 필요한 정보를 추출하는 데 실패하면, FSM은 불완전한 데이터로 진행하기보다 에이전트를 '명확화(clarification)' 상태로 되돌릴 수 있습니다.
• 디버깅 용이성 (Debuggability): 상태 전이를 기록할 수 있어, 에이전트가 특정 결정을 내린 이유를 추적하기 쉽습니다.

Python에서 FSM 구현하기

FSM을 사용하여 간단한 '항공권 예약 에이전트'를 만들어 보겠습니다. transitions와 같은 라이브러리를 사용하거나 가벼운 상태 머신을 수동으로 구현할 수 있습니다.

from enum import Enum
import json

...

고급 FSM 패턴

더 복잡한 에이전트의 경우, 다음 패턴들을 고려해 보세요:

1. 계층적 상태 머신 (Hierarchical State Machines, HSMs): 관련 상태들을 그룹화합니다. 예를 들어, Domestic(국내) 및 International(국제) 하위 상태를 가진 Booking(예약) 상위 상태(superstate)를 만드는 방식입니다. 이는 대규모 시스템에서의 복잡성을 줄여줍니다.
2. 가드 조건 (Guard Conditions): 특정 조건이 충족되는 경우에만 전이(transition)를 허용합니다. 예를 들어, 검색 결과가 반환된 경우에만 SEARCHING_FLIGHTS(항공편 검색 중)에서 CONFIRMING_BOOKING(예약 확인 중)으로 전이할 수 있습니다.
3. 외부 트리거 (External Triggers): 사용자 입력뿐만 아니라 외부 이벤트(예: Stripe를 통한 결제 확인)가 상태 전이를 트리거할 수 있도록 허용합니다.

2. 로컬 개인정보 보호 계층 (Local Privacy Layers): 데이터를 온프레미스(On-Premise)에 유지하기

사용자 데이터를 공개 LLM API로 전송하는 것은 주요한 개인정보 보호 위험입니다. 회복 탄력적인 에이전트를 구축하려면 민감한 데이터가 인프라를 절대 벗어나지 않도록 보장하는 **로컬 개인정보 보호 계층 (Local Privacy Layer)**을 구현해야 합니다. 여기에는 세 가지 핵심 전략이 포함됩니다:

A. 데이터 삭제 및 익명화 (Data Redaction and Anonymization)

데이터를 LLM으로 보내기 전에 PII (개인 식별 정보, Personally Identifiable Information)를 제거하십시오. Presidio와 같은 라이브러리나 커스텀 정규 표현식(regex) 규칙을 사용하여 다음 항목을 탐지하고 삭제하십시오:

• 이름
• 이메일 주소
• 전화번호
• 신용카드 번호
• 사회보장번호 (Social Security Numbers)

import re

def redact_pii(text: str) -> str:
...

B. 로컬 LLM 추론 (Local LLM Inference)

최대의 개인정보 보호를 위해 Llama 3, Mistral 또는 Gemma와 같은 오픈 소스 모델을 사용하여 LLM을 로컬에서 실행하십시오. 이는 다음과 같은 프레임워크를 사용하여 수행할 수 있습니다:

• Ollama: 실행이 간편한 로컬 LLM.
• LangChain Local: 로컬 모델 통합 지원.
• vLLM: 고처리량(high-throughput) 로컬 추론.

로컬에서 실행하면 다음 사항이 보장됩니다:

• 데이터가 서버를 절대 벗어나지 않습니다.
• 모델 업데이트 및 보안 패치에 대해 완전한 제어권을 갖습니다.
• 벤더 종속성 (vendor lock-in)을 피할 수 있습니다.

C. 하이브리드 아키텍처 (Hybrid Architecture)

모든 작업에 로컬 처리가 필요한 것은 아닙니다. 하이브리드 접근 방식을 사용하십시오:

1. 로컬 레이어 (Local Layer): 민감한 데이터 처리, 개인정보(PII) 탐지 및 기본적인 의도 분류 (Intent Classification)를 담당합니다.
2. 클라우드 레이어 (Cloud Layer): 복잡한 추론 (Reasoning), 창의적 글쓰기 또는 방대한 지식 베이스가 필요한 작업에는 공개 LLM을 사용합니다.

이를 통해 민감하지 않은 데이터만 클라우드로 전송되도록 보장함으로써, 성능을 유지하면서도 개인정보 보호 위험을 줄일 수 있습니다.

3. 비용 제어 (Cost Controls): 요금 폭탄 방지

LLM API는 비용이 많이 들 수 있으며, 특히 사용자 상호작용당 여러 번의 호출을 수행하는 에이전트의 경우 더욱 그렇습니다. 엄격한 비용 제어가 없다면 애플리케이션은 빠르게 상당한 비용을 발생시킬 수 있습니다.

A. 토큰 예산 책정 (Token Budgeting)

LLM으로 전송되는 토큰 수를 제한하십시오. 여기에는 다음이 포함됩니다:

• 시스템 프롬프트 (System Prompt): 간결하게 유지하십시오.
• 컨텍스트 윈도우 (Context Window): 관련 있는 대화 기록만 전송하십시오. 컨텍스트 크기를 줄이기 위해 요약 (Summarization)을 사용하십시오.
• 출력 길이 (Output Length): 제어되지 않는 응답을 방지하기 위해 API 호출 시 max_tokens를 지정하십시오.

response = client.chat.completions.create(
    model="gpt-4",
    messages=messages,
...

B. 캐싱 및 프롬프트 최적화 (Caching and Prompt Optimization)

• 프롬프트 캐싱 (Prompt Caching): 많은 LLM 제공업체가 반복되는 시스템 프롬프트 및 대화 시작 문구에 대해 프롬프트 캐싱을 제공합니다. 이를 사용하여 비용을 절감하십시오.
• 더 작은 모델 (Smaller Models): 간단한 작업에는 더 작고 빠른 모델 (예: GPT-4o-mini, Claude Haiku)을 사용하고, 복잡한 추론에는 더 큰 모델을 예약해 두십시오.
• 배치 처리 (Batching): 여러 항목을 처리하는 경우, API 오버헤드를 줄이기 위해 요청을 배치 처리하십시오.

C. 모니터링 및 알림 (Monitoring and Alerts)

다음 사항을 추적하기 위해 실시간 모니터링을 구현하십시오:

• 토큰 사용량 (Token Usage): 요청당 입력 및 출력 토큰을 모니터링합니다.
• 요청당 비용 (Cost per Request): 각 상호작용의 비용을 계산합니다.
• 이상 탐지 (Anomaly Detection): 토큰 사용량이나 에러율의 비정상적인 급증 시 알림을 보냅니다.

LangSmith 또는 Arize Phoenix와 같은 도구를 사용하여 LLM 사용량을 시각화하고 모니터링하십시오.

삼각 편대의 통합: 프로덕션 준비가 된 에이전트 아키텍처

FSM (Finite State Machines, 유한 상태 기계), 로컬 개인정보 보호, 그리고 비용 제어를 결합하면 견고하고 프로덕션 준비가 된 (production-ready) AI 에이전트를 구축할 수 있습니다. 다음은 상위 수준의 아키텍처입니다:

1. 사용자 입력 (User Input): 애플리케이션에 의해 수신됩니다.
2. 로컬 개인정보 보호 계층 (Local Privacy Layer):
   • PII (개인 식별 정보)를 삭제(Redact)합니다.
   • 의도 분류 (intent classification)가 필요한 경우 로컬 LLM을 실행합니다.
3. FSM 오케스트레이터 (FSM Orchestrator):
   • 현재 상태를 결정합니다.
   • FSM 규칙에 따라 다음 동작을 결정합니다.
4. LLM 서비스 (로컬 또는 클라우드):
   • 로컬인 경우: 추론 (reasoning)을 위해 로컬 모델을 실행합니다.
   • 클라우드인 경우: 엄격한 토큰 제한과 함께 비식별화된 데이터를 클라우드 API로 전송합니다.
5. 응답 생성 (Response Generation):
   • FSM 상태에 따라 응답 형식을 지정합니다.
   • 비용 제어 (예: 가능한 경우 결과 캐싱)를 적용합니다.
6. 상태 업데이트 (State Update):
   • FSM 상태를 업데이트합니다.
   • 모니터링을 위한 메트릭 (metrics)을 기록합니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: 비결정론적인 (non-deterministic) LLM 출력과 함께 FSM을 사용할 수 있나요?
A: 네, 하지만 LLM 출력을 신뢰할 수 없는 데이터로 취급해야 합니다. FSM은 예상되는 스키마 (예: JSON schemas)에 따라 LLM 출력을 검증해야 하며, 오류를 유연하게 처리해야 합니다. LLM이 직접 상태 전이 (state transitions)를 수행하도록 절대 신뢰해서는 안 됩니다.

Q: 개인정보 보호와 방대한 지식 베이스의 필요성 사이에서 어떻게 균형을 맞추나요?
A: 하이브리드 접근 방식을 사용하십시오. 민감한 데이터는 로컬에 유지하고, PII에 민감한 작업에는 로컬 모델을 사용합니다. 방대한 지식이 필요한 작업의 경우 클라우드 모델을 사용하되, 전송하기 전에 데이터가 익명화(anonymized) 또는 집계(aggregated)되었는지 확인하십시오. 데이터를 온프레미스 (on-premise)에 유지하기 위해 로컬 벡터 저장소 (vector stores)와 RAG (Retrieval-Augmented Generation, 검색 증강 생성)를 사용하는 것을 고려하십시오.

Q: LLM이 타임아웃 (timeout) 내에 응답하지 않으면 어떻게 되나요?
A: FSM에 타임아웃 메커니즘이 있어야 합니다. LLM이 응답하지 않을 경우, 에이전트는 기본 응답으로 대체(fallback)하거나, 요청을 재시도하거나, 사람 운영자에게 에스컬레이션 (escalate)할 수 있습니다. 이를 통해 외부 서비스가 실패하더라도 시스템의 회복 탄력성 (resilience)을 보장할 수 있습니다.

결론

AI 엔지니어링의 미래는 단순히 LLM (Large Language Models)의 생성 능력에만 의존하는 것이 아닙니다. 그것은 확률적 모델 (probabilistic models)을 결정론적 아키텍처 (deterministic architectures)와 결합하여 회복 탄력성 (resilience)을 엔지니어링하는 것에 관한 것입니다. 제어 흐름 (control flow)을 위한 유한 상태 머신 (Finite State Machines, FSM), 데이터 보안을 위한 로컬 개인정보 보호 계층 (Local Privacy Layers), 그리고 경제적 생존 가능성을 위한 엄격한 비용 제어 (Cost Controls)를 구현함으로써, 우리는 신뢰할 수 있고 안전하며 확장 가능한 AI 에이전트를 구축할 수 있습니다.

업계가 "바이브 코딩 (vibe coding)"을 넘어 나아감에 따라, 이 세 가지 요소(triad)를 숙달한 엔지니어들이 차세대 프로덕션급 (production-grade) AI 애플리케이션을 구축하는 데 가장 유리한 위치를 점하게 될 것입니다. LLM은 도구일 뿐, 건전한 소프트웨어 엔지니어링 원칙을 대체하는 것이 아닙니다.

AI 엔지니어링 및 프로덕션 준비 완료된 시스템에 대한 더 많은 통찰력을 얻으려면 Tamiz's Insights를 방문하세요.