Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 07. 16:47

향후 6~12개월 내 AI 에이전트를 구축하는 방법: 결정론(Determinism), 스키마(Schemas)

요약

신뢰할 수 있는 AI 에이전트 구축을 위해 모델의 지능보다 결정론적(Deterministic)인 런타임 계층의 중요성을 강조합니다. 확률론적인 LLM 아래에 검증과 피드백 루프를 제공하는 실행 계층을 배치하여 시스템의 안정성을 확보하는 전략을 제시합니다.

핵심 포인트

  • 가장 신뢰할 수 있는 시스템은 똑똑한 모델이 아닌 결정론적 런타임을 가진 시스템임
  • 코딩 에이전트의 성공 비결은 컴파일러와 테스트 러너 같은 실행 계층의 존재임
  • 확률론적 모델 아래에 결정론적 실행 계층을 두어 불확실성을 피드백 루프로 전환해야 함
  • 인터프리터 계층을 통해 도구 조합과 상태 관리를 결정론적으로 처리 가능함

이제 모델은 차별화 요소가 아닙니다. 런타임(Runtime)이 차별화 요소입니다.

저는 지난 1년 동안 에이전트형 AI 플랫폼을 구축하는 데 시간을 보냈습니다. 음성 통화, 챗봇, 영업 에이전트, 워크플로 자동화 등 실제 운영 환경에서 실행되고, 실제 고객과 대화하며, 실제 데이터에 접근하는 시스템들 말입니다. 제가 보기에 자주 논의되지 않는 패턴이 계속 나타나는데, 아마도 AI 발전의 일반적인 서사에 그리 유리하지 않기 때문일 것입니다.

가장 신뢰할 수 있는 AI 시스템은 가장 똑똑한 모델을 가진 시스템이 아닙니다. 그 밑단에 가장 결정론적인(Deterministic) 런타임을 가진 시스템입니다.

§ 01 — 코딩 에이전트가 실제로 증명한 것

코딩 에이전트가 급부상한 것은 모델이 능력 임계치를 넘었기 때문이 아닙니다. LLM은 이미 2021년에 코드 생성 능력을 갖추고 있었습니다. 변화한 것은 **그 밑단의 런타임(Runtime)**이었습니다. 즉, 컴파일러(Compiler), 테스트 러너(Test runner), 그리고 모든 시도에 대해 모호하지 않은 피드백을 제공하는 인터프리터(Interpreter)가 등장한 것입니다.

2023년의 RAG(Retrieval-Augmented Generation) 열풍에는 그와 대등한 요소가 없었습니다. 검색(Retrieval) + 생성(Generation) 구조였으며, 실행 단계도 없었고 교정 신호(Correction signal)도 없었습니다. 모든 검증 부담은 인간에게 전가되었습니다. 코딩 에이전트는 그 부담을 기계로 옮겼습니다.

통찰: AI는 확신할 필요가 없습니다. 틀렸을 때 빠르게 바로잡을 방법이 필요할 뿐입니다.

flowchart LR
  subgraph RAG["RAG · 2023 — 막다른 길"]
    direction LR
...

확률론적 모델(Probabilistic model) 아래에 결정론적 실행 계층(Deterministic execution layer)을 배치하면, 모델의 불확실성은 더 이상 병목 현상이 되지 않습니다. 런타임이 검증을 처리하고, 모델은 계속해서 반복(Iteration)을 수행합니다.

이 패턴은 일반화될 수 있습니다. LLM에 결정론적 실행 계층을 연결할 수 있는 곳이라면 어디든, 추측을 피드백 루프(Feedback loop)로 전환할 수 있습니다. 코딩이 첫 번째였던 이유는 실행 계층이 이미 존재했기 때문입니다. 다음 파도는 다른 모든 도메인을 위해 이를 의도적으로 구축하는 것에 관한 것입니다.

§ 02 — 인터프리터 계층

LangChain의 DeepAgents는 QuickJS를 프로세스 내(In-process) 방식으로 출시했습니다. 즉, 에이전트 하네스(Harness) 내부에 JavaScript 인터프리터를 포함시킨 것입니다. 이제 AI는 외부 러너(Runner)로 왕복하는 방식이 아니라, 코드를 통해 일급 객체(First-class operation)로서 추론을 수행합니다.

flowchart LR
  subgraph harness["AGENT HARNESS"]
    direction LR
...

도구 조합 (Tool composition), 상태 관리 (State management), 컨텍스트 필터링 (Context filtering), 조건부 오케스트레이션 (Conditional orchestration): 이 모든 것은 결정론적 (Deterministic)이며, 모두 하네스 (Harness) 내부에서 이루어집니다.

QuotyAI에서 이러한 방식은 에이전트 지연 시간 (Latency)을 평균 약 2.5초에서 24ms 고정값으로 단축시켰습니다. 예약 검증 (Booking validation), 충돌 해결 (Conflict resolution), 에스컬레이션 규칙 (Escalation rules)과 같은 조건부 로직 (Conditional logic)을 LLM에서 분리하여 결정론적 코드 (Deterministic code)로 옮겼기 때문입니다.

에이전트 체인 (Agent chain)결정론적 런타임 (Deterministic runtime)
평균 지연 시간 (Average latency)~2,500ms24ms
...

LLM은 판단 (Judgment)을 담당하고, 런타임 (Runtime)은 사실 (Facts)을 담당합니다.

§ 03 — 에이전트는 "완료"가 어떤 모습인지 알아야 한다

대부분의 에이전트는 작업 완료 (Task completion)에 대한 개념이 없습니다. 그들은 응답을 생성하고 멈춥니다. 작업이 실제로 끝났는지 여부는 호출자 (Caller)의 몫으로 남겨집니다.

Claude Code는 /goal을 도입했습니다. 사용자가 목표를 사전에 정의하면, 에이전트는 반복 (Iterations)을 거치며 명시적으로 그 목표를 향해 작업합니다. LangChain은 DeepAgents를 위한 RubricMiddleware를 통해 한 발 더 나아갔습니다.

작동 방식은 다음과 같습니다: 채점자 서브 에이전트 (Grader sub-agent, 더 저렴한 모델 및 특정 도구 사용)가 실행이 종료되기 전, 타입화된 루브릭 (Typed rubric)에 따라 출력을 평가합니다. 만약 어떤 기준 (Criterion)이라도 실패하면, 채점자는 "다시 시도하세요"가 아니라 정확히 어떤 기준이 왜 실패했는지에 대한 기준별 피드백 (Per-criterion feedback)을 주입하며, 루프 (Loop)가 재실행됩니다.

flowchart LR
  R[request] --> A

...

from deepagents import RubricMiddleware, create_deep_agent

rubric = RubricMiddleware(
...

주의 깊게 살펴볼 두 가지 사항이 있습니다:

  1. 채점자는 메인 에이전트와 _다른, 더 저렴한 모델_을 사용합니다. 테스트 통과 여부를 확인하기 위해 Sonnet에 비용을 지불할 필요가 없습니다. run_test_suite를 통해 Haiku가 그 역할을 수행합니다.
  2. 피드백은 일반적이지 않고 기준별 (Per-criterion)로 제공됩니다. 에이전트는 단순히 "다시 시도하세요"라는 말을 듣는 것이 아니라, "기준 3 실패: 해시 불가능한 입력(Unhashable input)에서 충돌 발생"과 같은 피드백을 받습니다.

"완료(Done)"는 이제 느낌이 아니라 스키마 (Schema)입니다. 한 번 작성하면 끝납니다. 채점자 (Grader)는 결정론적 (Deterministically)으로 평가합니다. 반복 (Iteration) 1단계에서 기준 3을 충족하지 못하면, 에이전트는 해당 기준을 구체적으로 다시 목표로 설정합니다.

§ 04 — 2단계 애플리케이션 아키텍처 (Two-Phase Application Architecture)

대부분의 팀은 LLM을 연결하고, 도구 (Tools)를 부여하고, 시스템 프롬프트 (System Prompt)를 추가한 뒤 바로 출시합니다. 이는 데모용으로는 작동합니다. 하지만 프로덕션 (Production) 환경에서는 AI가 잘못된 함수를 호출하거나, 예상치 못한 형태 (Shapes)를 반환하거나, 결정론적이어야 할 결정들을 내리기도 합니다.

근본 원인: 두 개의 별개 단계를 하나로 취급했기 때문입니다.

flowchart LR
  subgraph P1["PHASE 1 · DESIGN TIME (human)"]
    direction TB
...

그 보상은 바로 **디버깅 가능성 (Debuggability)**입니다. 무언가 고장 났을 때: 계약 (Contract) 자체가 잘못된 것인가요 (Phase 1), 아니면 올바른 계약 내에서 모델이 잘못된 결정을 내린 것인가요 (Phase 2)? 버그의 종류가 다릅니다. 해결 방법도 다릅니다. 두 단계를 혼동하면 두 가지를 동시에 디버깅해야 함을 의미합니다.

QuotyAI에서 이것은 워크플로 에디터 (Workflow editor)로 구현됩니다: 타입이 지정된 JSON 페이로드 (Payload)로 트리거 → 명시적 로직이 포함된 조건 블록 (Condition block) → 정의된 출력 스키마 (Output schema)를 가진 액션 (Action). AI는 고객의 의도를 해당 구조에 매핑합니다. AI는 새로운 구조를 만들어낼 수 없습니다. 계약이 경계선 역할을 합니다.

§ 05 — 프로토콜 (Protocols)보다 계약 (Contracts)

MCP는 실제 문제에 대한 합리적인 해답입니다. AI를 외부 도구와 연결하는 표준이 존재하지 않았기 때문입니다. 제3자 도구 (Slack, GitHub, Notion)의 경우에는 유용합니다.

하지만 퍼스트 파티 (First-party) 애플리케이션 로직의 경우에는 잘못된 계층입니다.

MCP는 도구의 발견 (Discovery)과 호출 (Invocation)을 표준화합니다. 하지만 도구별 타입이 지정된 I/O 계약 (Typed I/O contracts), 버전 관리 (Versioning), 도메인별 에러 스키마 (Error schemas), 또는 강제된 출력 형태 (Enforced output shapes)를 제공하지는 않습니다.

MCP 도구 정의 (MCP tool definition):

{
  "inputSchema": {
    "type": "object",
...

타입 강제 (Type enforcement)가 없습니다. 에러 스키마도 없습니다. 버전도 없습니다. 무엇이든 들어올 수 있고, 무엇이든 나갈 수 있습니다.

타입이 지정된 스킬 계약 (Typed skill contract):

{
  "name":    "create_booking",
  "version": "2.1.0",
...

실행 계약 (Execution contract): AI가 구조화된 출력 (Structured output)을 생성 → 코드가 스키마에 따라 검증 → 불일치 시 에러 발생 및 재시도 (Retry) → 모호한 것이 비즈니스 로직 (Business logic)에 도달하지 않음.

MCP는 제3자 연결성 (third-party connectivity)을 위해 성장할 것입니다. 커스텀 계약 (Custom contracts)은 퍼스트 파티 로직 (first-party logic) 측면에서 승리할 것인데, 이는 AI 출력을 감사 가능하게 (auditable) 만드는 핵심 요소이기 때문입니다.

§ 06 — 모델 라우팅 (Model Routing)은 인프라다

모든 작업에 단 하나의 모델만 사용하는 것은 회계학적 실패입니다.

작업 (Task)모델 (Model)지연 시간 (Latency)호출당 비용 (Cost/call)
의도 분류 (Intent classification)claude-haiku-4-5~150ms$0.001
...

이들은 서로 동일한 제약 조건이 아닙니다. 모든 분류 호출에 Sonnet을 실행하는 것은 비용이 많이 들고 느립니다. 복잡한 추론 작업에 Haiku를 실행하면 확신에 찬 오답을 내놓게 됩니다.

MODEL_ROUTES = {
    "intent_classification": {
        "model": "claude-haiku-4-5",
...

flowchart LR
  T[task] --> R["router\ntask_type → model config"]
  R --> M1["intent classification\nhaiku · 150ms · $0.001"]
...

이것은 사용자에게 노출되는 기능이 아닙니다. 이는 어떠한 LLM 호출이 이루어지기 전의 라우팅 결정 (routing decision)입니다. 대부분의 팀은 프레임워크가 이를 강제하지 않기 때문에 이를 수행하지 않습니다. 하지만 규모가 커질수록 계층 간의 지연 시간 및 비용 격차는 무시하기에는 너무나 큽니다.

§ 07 — 이 토대 위에서 무엇이 구축되는가

2023년의 RAG 파도는 더 나은 검색을 구축했습니다. 그 한계치는 "더 나은 조회 (better lookup)"였습니다.

결정론적 토대 (deterministic foundation) 위에 구축되는 것은 질적으로 다릅니다. AI가 합성 (synthesises)하는 것이 아니라 실행 (executes)합니다.

스키마 우선 에이전트 프레임워크 (Schema-first agent frameworks). 현재 데이터베이스 스키마 (database schemas)를 정의하는 방식과 동일하게, 검증 (validation), 버전 관리 (versioning), 마이그레이션 도구 (migration tooling)를 갖춘 AI 계약 (AI contracts)을 정의하게 될 것입니다. 스키마 계층은 시스템 프롬프트 (system prompt)가 아닌 CLI 아티팩트 (CLI artifact)가 될 것입니다.

루브릭 기반 에이전트 CI/CD (Rubric-based agent CI/CD). 에이전트의 도구 세트 (tool set)나 모델 버전을 변경하여 병합하기 전에, 루브릭 테스트 스위트 (rubric test suite)가 실행됩니다. '통과 (Green)'는 에이전트가 여전히 정의된 완료 기준 (completion criteria)을 충족함을 의미합니다. 이는 에이전트의 행동에 적용된 유닛 테스트 (unit tests)와 동일한 패턴입니다.

관리 계층으로서의 모델 라우팅 (Model routing as a managed layer). 작업 유형 (Task-type)에서 모델 선택 (model selection)으로 이어지는 과정은 DNS가 HTTP 하위에 위치하는 방식처럼, 애플리케이션 계층 (application layer) 완전히 아래로 이동합니다. 귀하의 애플리케이션은 어떤 모델이 실행되었는지는 알지 못하며, 오직 계약 (contract)이 충족되었는지만 알게 될 것입니다.

더 중요한 핵심은 다음과 같습니다: 가치는 모델에 있지 않습니다. 모델은 지속적으로 개선되며, 가장 뛰어난 모델들은 점점 더 저렴해지고 있습니다. 가치는 모델의 출력을 실행에 옮길 수 있을 만큼 신뢰할 수 있게 만드는 런타임 (runtime)에 있습니다 — 즉, 타입이 지정된 계약 (typed contracts), 결정론적 실행 (deterministic execution), 그리고 검증 가능한 완료 (verifiable completion)가 그 핵심입니다.

그 런타임은 바로 지금 구축되고 있습니다. 대부분 조용하게 말이죠. 주로 첫 번째 파도에서 고배를 마셨던 사람들에 의해서 말입니다.

저는 음성, 채팅 및 비즈니스 자동화를 위한 에이전트형 AI (agentic AI) 플랫폼인 QuotyAI를 구축하고 있습니다. 만약 결정론적 에이전트 인프라 (deterministic agent infrastructure)를 작업하고 계신다면, 여러분이 무엇을 보고 있는지 듣고 싶습니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0