LLM은 확률적입니다. 당신의 워크플로우는 그렇지 않아야 합니다.

대부분의 AI 애플리케이션 데모는 동일한 실수를 저지릅니다. 모델을 애플리케이션 그 자체처럼 취급한다는 점입니다. 프롬프트(Prompt)를 입력하면 답변이 나오고, 몇 번의 도구 호출(Tool calls)이 이루어지면 끝입니다. 그러다 운영 환경(Production)에서 무언가 이상해지면 모두가 놀란 척을 합니다. 문제는 모델이 쓸모없다는 것이 아닙니다. 문제는 우리가 확률적(Probabilistic) 구성 요소에게 결정론적(Deterministic) 워크플로우 코드처럼 행동하라고 계속 요구하고 있다는 점입니다. 그것은 잘못된 경계 설정입니다. 더 나은 패턴은 더 간단합니다. 모델은 해석하게 두고, 소프트웨어는 검증하게 두며, 워크플로우가 상태(State)를 소유하게 하고, 고위험 작업에는 승인을 요구하십시오. 다른 것은 다 잊더라도 이것만은 기억하십시오. 모델이 되돌릴 수 없는 상태 전이(Irreversible state transitions)를 소유하게 하지 마십시오.

이것이 중요한 이유
신뢰성 문제는 더 이상 가설이 아닙니다. Stanford HAI의 2026 AI Index 보고서에 따르면, 새로운 정확도 벤치마크에서 26개의 상위 모델 전반에 걸친 환각(Hallucination) 비율은 22%에서 94% 사이였습니다. 동일한 보고서는 기록된 AI 사고가 2024년 233건에서 2025년 362건으로 증가했다고 밝혔습니다. 그럼에도 불구하고 도입은 계속 늘어나고 있습니다. 2026 AI Index 경제 챕터에 따르면, 설문에 참여한 조직의 88%가 2025년에 최소 하나 이상의 비즈니스 기능에서 AI를 사용하고 있다고 보고했으며, 79%는 최소 하나의 기능에서 정기적으로 생성형 AI(Generative-AI)를 사용한다고 보고했습니다. 즉, 팀들은 실제로 이러한 것들을 출시하고 있습니다. 하지만 같은 챕터는 확장된 AI 에이전트(AI-agent) 사용은 거의 모든 비즈니스 기능에서 여전히 한 자릿수에 머물러 있다고 말합니다. 이는 타당한 결과입니다. 사람들은 LLM이 데이터베이스, 규칙 엔진(Rules engine), 그리고 컴플라이언스(Compliance) 부서의 역할을 동시에 조용히 수행하게 만들지 않으면서도, LLM의 이점을 누리고 싶어 하기 때문입니다.

모델 벤더들조차 당신에게 이 말을 하고 있습니다.
Anthropic의 "Building Effective Agents"는 그들이 본 가장 성공적인 구현 사례들이 단순하고 결합 가능한(Composable) 패턴을 사용했다고 말하며, 다음과 같이 명확한 선을 긋습니다: LLM과 도구가 사전 정의된 코드 경로를 통해 오케스트레이션(Orchestrated)되는 워크플로우(Workflows), 그리고 모델이 자신의 프로세스와 도구 사용을 동적으로 지시하는 에이전트(Agents).
그들은 또한 가능한 한 가장 단순한 솔루션으로 시작하고, 필요할 때만 복잡성을 추가할 것을 권장합니다. OpenAI 역시 다른 방식으로 유사한 내용을 말하고 있습니다.

Structured Outputs 출시 당시, OpenAI는 모델의 동작이 본질적으로 비결정론적 (non-deterministic)이며, 모델 성능이 향상되더라도 개발자가 견고한 애플리케이션을 구축하는 데 필요한 신뢰성을 충족하기에는 여전히 부족하다고 명시했습니다. 그들의 해답은 "프롬프트를 더 강하게 작성하라"가 아니었습니다. 그것은 모델 출력 주변에 결정론적 제약 디코딩 (deterministic constrained decoding)을 적용하는 것이었습니다. 그것이 바로 패턴입니다. 확률이 허용되는 곳에는 모델을 사용하십시오. 정확성이 강제되어야 하는 곳에는 결정론적 엔지니어링 (deterministic engineering)을 사용하십시오.

여기서 제가 신뢰하는 아키텍처 규칙 (Architectural Rule)은 다음과 같습니다: LLM은 행동을 제안해야 합니다. 소프트웨어는 해당 행동이 허용되는지 결정해야 합니다. 즉, 모델은 다음과 같은 작업에 매우 유용합니다:

• 의도 추출 (intent extraction)
• 문서 이해 (document understanding)
• 요약 (summarization)
• 분류 (classification)
• 초안 작성 (drafting)
• 제한된 컨텍스트 내에서의 도구 선택 (tool selection in bounded contexts)

반면, 모델은 일반적으로 다음과 같은 사항에 대해 최종 권한을 가져서는 안 됩니다:

• 권한 (permissions)
• 가격 책정 (pricing)
• 결제 실행 (payment execution)
• 계정 상태 (account state)
• 환불 (refunds)
• 계약 해석 (contract interpretation)
• 컴플라이언스 게이트 (compliance gates)
• 파괴적 쓰기 (destructive writes)

만약 모델이 "이 주문을 환불하세요"라고 말한다면, 그것은 환불이 아닙니다. 그것은 권장 사항 (recommendation)입니다. 당신의 애플리케이션은 여전히 다음 사항을 확인해야 합니다: 주문이 존재하는가? 환불이 가능한가? 금액이 정책 범위 내에 있는가? 호출자에게 권한이 있는가? 이미 진행 중인 환불이 있는가? 이것이 사람의 승인을 필요로 하는가? 그러한 로직은 희망 (hope)이 아니라 코드 (code)에 속해야 합니다.

승리하는 지루한 아키텍처 (The Boring Architecture That Wins)
이것은 제가 프로덕션 환경에서 신뢰할 수 있는 스택입니다.

1. 해석기로서의 LLM (LLM as interpreter)
   모델은 비정형 입력을 후보 행동으로 변환합니다: { "intent" : "issue_refund" , "order_id" : "ord_123" , "reason" : "duplicate_charge" , "amount" : 49.0 }

2. 타입이 지정된 출력 계약 (Typed output contract)
   느낌 (vibes)을 파싱하지 마십시오. 스키마 (schema)를 파싱하십시오. OpenAI의 Structured Outputs 가이드가 존재하는 데는 이유가 있습니다. 모델의 품질이 향상되더라도, 출력 형태 (output shape)에 대한 결정론적 강제 (deterministic enforcement)가 여전히 필요하기 때문입니다.

3. 결정론적 검증기 (Deterministic validator)
   이제 실제 애플리케이션이 다음 검사들을 실행합니다: 스키마 검증 (schema validation), 권한 부여 (authz), 비즈니스 규칙 (business rules), 멱등성 (idempotency), 리소스 존재 여부 (resource existence), 임계값 확인 (threshold checks), 속도 제한 (rate limits)

4. 워크플로우 엔진 또는 상태 머신 (Workflow engine or state machine)
   모델은 상태 전이 (state transition)를 소유하지 않습니다.

워크플로우가 상태를 소유합니다. 예를 들어: 요청됨 (requested) -> 검증됨 (validated) -> 승인됨 (approved) -> 실행됨 (executed) -> 기록됨 (recorded). 검증 (validation)에 실패하면 워크플로우는 분기 (branch)합니다. 승인 (approval)이 필요하면 일시 중지 (pause)합니다. 실행 (execution)에 실패하면 재시도 (retry)하거나 데드 레터 (dead-letter) 처리합니다.

5. 범위가 지정된 도구 (Scoped tools)
   도구는 좁고, 명시적이며, 권한이 부여되어야 합니다. OpenAI의 에이전트 구축 실무 가이드 (practical guide to building agents)에서는 쓰기 권한 (write access), 가역성 (reversibility), 재무적 영향 (financial impact) 등을 기반으로 도구의 위험을 평가하고, 고위험 기능에 대해서는 중단하거나 사람에게 에스컬레이션 (escalating)할 것을 권장합니다. 이것은 컴플라이언스 연극 (compliance theater)이 아닙니다. 이것은 기본적인 아키텍처 (architecture)입니다.

6. 추적 (Tracing), 로그 (logs), 그리고 평가 (evals)
   어떤 프롬프트 (prompt), 도구 결과 (tool result), 검증 단계 (validation step), 그리고 분기 결정 (branch decision)이 특정 동작을 유도했는지 조사할 수 없다면, 당신은 시스템을 디버깅 (debugging)하고 있는 것이 아닙니다. 당신은 추측 (guessing)을 하고 있는 것입니다.

여기서 제가 신뢰하지 않는 안티 패턴 (Anti-Pattern)은 다음과 같습니다:
사용자 메시지가 에이전트 (agent)로 바로 전달됩니다. 에이전트가 비즈니스 규칙 (business rule)이 아마 이럴 것이라고 결정합니다. 에이전트가 데이터베이스 (database)에 기록합니다. 에이전트가 이메일을 보냅니다. 에이전트가 CRM을 업데이트합니다. 모두가 프롬프트가 충분히 좋았기를 바랍니다. 이것은 데모 (demo)에서는 모든 복잡성이 숨겨져 있기 때문에 빨라 보입니다. 하지만 프로덕션 (production) 환경에서는 모든 책임 소재 (accountability) 또한 숨겨져 있기 때문에 무너집니다.

무언가 잘못되었을 때, 당신은 실패의 원인이 다음 중 무엇인지 알 수 없을 것입니다:

• 잘못된 검색 (bad retrieval)
• 잘못된 프롬프트 가정 (bad prompt assumptions)
• 오래된 도구 데이터 (stale tool data)
• 누락된 권한 확인 (missing permission checks)
• 경합 조건 (race conditions)
• 중복 쓰기 (duplicate writes)
• 단순한 환각 (hallucination)

더 나쁜 것은, 돈이 이동하거나 고객에게 연락이 간 이후에야 이를 알게 될 수도 있다는 점입니다.

NIST는 기본적으로 설계도 (blueprint)를 건네주고 있습니다.
NIST의 AI 위험 관리 프레임워크 (AI Risk Management Framework)는 단순한 정책 문서가 아닙니다. 그렇게 읽는다면, 그것은 실질적인 엔지니어링 가이드 (engineering guidance)입니다.

빌더(builders)에게 가장 유용한 부분 중 일부는 다음과 같습니다: 인간과 AI의 역할을 정의하고 차별화하기, 지식의 한계와 출력물이 어떻게 감독될지 문서화하기, 배포 전 및 프로덕션(production) 환경에서 정기적으로 시스템 테스트하기, 프로덕션에서 기능과 동작을 모니터링하기, 시스템이 지식 한계를 벗어났을 때 안전하게 실패(fail safely)할 수 있도록 보장하기, 리스크, 통제 항목 및 제3자 의존성(third-party dependencies)을 문서화하기. 이것은 단지 더 나은 어휘를 사용한 훌륭한 소프트웨어 엔지니어링 (software engineering)일 뿐입니다. NIST의 생성형 AI 프로필 (Generative AI Profile)은 여기서 더 나아가, 생성형 AI에는 추가적인 인간의 검토, 추적, 문서화 및 관리 감독이 필요할 수 있다고 명시합니다. 이는 숙련된 팀들이 결국 첫 몇 번의 프로덕션 사고를 겪은 후에 발견하게 되는 사실과 정확히 일치합니다.

좋은 멘탈 모델 (Mental Model)
LLM을 트랜잭션 계층 (transaction layer)이 아닌 인지 계층 (perception layer)으로 생각하십시오. LLM은 무질서한 인간의 입력을 구조화된 후보군으로 변환하는 것을 도와줍니다. LLM이 당신 시스템의 핵심 불변량 (core invariants)을 재정의하게 두어서는 안 됩니다. 따라서 다음과 같은 방식 대신:
모델 (model) -> 동작 (action)
다음과 같이 구축하십시오:
모델 (model) -> 제안 (proposal) -> 검증 (validation) -> 정책 확인 (policy check) -> 승인 (approval, 필요한 경우) -> 실행 (execution) -> 감사 로그 (audit log)
이 추가적인 장치들은 관료주의가 아닙니다. 그것은 단순한 AI 기능 (AI feature)과 당신이 신뢰할 수 있는 AI 시스템 (AI system) 사이의 차이입니다.

내가 가장 먼저 구축할 것
만약 내가 오늘 AI 워크플로우 (workflow)를 구축한다면, 다음과 같은 순서로 시작할 것입니다:

1. 실제 고통(pain)이 존재하는 하나의 좁은 유스케이스 (use case)
2. 타입이 지정된 출력 (typed output)을 반환하는 하나의 모델 호출 (model call)
3. 명시적인 비즈니스 규칙을 가진 하나의 검증 계층 (validator layer)
4. 명확한 권한을 가진 하나의 작은 도구 세트 (set of tools)
5. 고위험 동작을 위한 하나의 승인 경로 (approval path)
6. 실행당 하나의 트레이스 (trace)
7. 합성된 낙관주의 (synthetic optimism)가 아닌 실제 실패 사례에 기반한 하나의 평가 세트 (eval set)

단순하게 시작하라는 Anthropic의 가이드는 옳습니다. OpenAI의 가드레일 (guardrail) 가이드도 옳습니다. 화를 입는 팀들은 대개 스테이징 (staging) 환경에서 모델이 좋아 보인다는 이유로 지루한 계층들을 건너뛰는 팀들입니다. AI를 도입한다고 해서 소프트웨어 아키텍처 (software architecture)의 필요성이 사라지는 것은 아닙니다. 오히려 아키텍처를 잘못 설계했을 때 치러야 할 대가가 높아질 뿐입니다. LLM이 강력한 이유는 모호함 (ambiguity)을 잘 처리하기 때문입니다.

그 모호함 (ambiguity)이 정확해야만 하는 시스템의 영역으로 흘러 들어가게 방치한다면, LLM은 위험해집니다. 모델이 읽게 하세요. 모델이 분류 (classify)하게 하세요. 모델이 초안을 작성 (draft)하게 하세요. 모델이 제안 (suggest)하게 하세요. 하지만 진실 (truth), 정책 (policy), 권한 (permissions), 상태 전이 (state transitions), 부작용 (side effects)은 결정론적 시스템 (deterministic systems)이 담당하게 하세요. AI가 실수를 한다는 사실이 AI를 활용한 구축을 피해야 할 이유는 아닙니다. 오히려 엔지니어처럼 그 주변부를 구축해야 하는 이유입니다. 출처: Stanford HAI, 2026 AI Index, Responsible AI chapter: https://hai.stanford.edu/ai-index/2026-ai-index-report/responsible-ai Stanford HAI, 2026 AI Index, Economy chapter: https://hai.stanford.edu/assets/files/ai_index_report_2026_chapter_4_economy.pdf Anthropic, "Building Effective Agents": https://www.anthropic.com/engineering/building-effective-agents/ OpenAI, "Introducing Structured Outputs in the API": https://openai.com/index/introducing-structured-outputs-in-the-api/ OpenAI, "A practical guide to building agents": https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/ NIST AI RMF Core: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ NIST Generative AI Profile (NIST-AI-600-1): https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf