모델 내부 실행 권한을 데이터 기반 검증으로 옮긴 실행 상태 모델 제안

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

에이전트가 실행할지 여부를 모델의 확률적 추론에 맡기면 동일 입력에서도 실행 결과가 달라지는 비결정적 문제가 발생하므로, 실행 전 필요한 필드의 존재 여부만을 검사하는 스키마 대조 방식으로 결정 권한을 이동시키는 방법이 제안됐다. 실행 상태를 표준화된 JSON으로 표현하고 각 필드를 Known/Unknown으로 검증한 뒤 Unknown은 사용자에게 반환하고 모든 검증 이력을 기록하면 실행의 일관성과 감사 가능성이 확보된다. 결정 로직을 코드·데이터로 옮기면 모델 교체나 프롬프트 변경 없이 기능 확장이 가능해 안전 설계의 중심이 스키마로 전환되며 이는 설계자의 스키마 품질이 곧 안전성의 핵심 제약이 됨을 의미한다.

실용적 조언

실행 전 검증 항목을 기능 설계자가 사전에 선언하여 스키마로 관리할 것을 권고했다; 이때 각 필드의 검증 제약을 명확히 기술하고 Known/Unknown을 결정하는 로직을 단일 레이어로 구현해야 한다. 검증 결과는 실행 로직과 분리된 기록으로 남겨야 감사와 원인 추적이 가능해진다. 또한 Unknown 항목은 사용자에게 반환해 명시적 보완을 받는 흐름을 설계해야 한다.
의도 확인 항목을 검증 체크리스트의 최우선으로 두어 사용자의 실제 행위 의도를 구조화된 값으로 확보해야 한다; 이 과정을 통해 에이전트가 필요 없는 정보를 반복적으로 요구하는 상황을 줄일 수 있다. 의도 확인과 안전 확인 항목을 분리해 선후관계를 명확히 하면 검증 지연을 최소화할 수 있다. 스키마 설계 시 어떤 값이 외부 입력으로만 확보되어야 하는지와 자동 채움이 가능한지를 구분해 정의하는 것이 실무 적용에서 중요하다.

섹션별 상세

동일한 프롬프트와 요청인데도 실행 결과가 달라지는 현상이 문제로 제기됐다; 이는 모델 버전이나 미세한 컨텍스트·temperature 차이로 인해 내부의 확률적 판단 경계가 흔들리기 때문에 발생한다고 기술됐다. 이 문제는 실험 재현성의 문제가 아니라 예측 가능성과 통제성의 문제로 규정됐다. 저자는 동일 입력에 대해 왜 다르게 결정했는지를 설명할 수 없는 상태가 운영상 큰 위험을 낳는다고 지적했다.

제시된 해결 원리는 존재 기반 검증으로서, 실행 시점에 입력이 선언된 스키마의 필수 필드를 모두 포함하는지 검사하는 방식으로 작동한다. 입력이 스키마의 요구사항을 만족하면 실행을 허용하고, 부족하면 사용자에게 보완을 요청하는 플로우가 기본 로직으로 채택됐다. 이 방식은 모델이 '충분한가'를 스스로 판단하는 대신 단순한 유무 대조로 결정을 고정해 예측 가능성을 높이는 효과를 목표로 한다.

실행 상태 모델은 표준화된 JSON 구조로 실행 전 상태를 표현하고 네 가지 원칙인 분리, 검증, 집행, 추적성을 따른다. 검증 단계에서 각 필드를 Known 또는 Unknown으로 표기하고 Unknown인 항목은 사용자에게 반환해 보완을 받는 방식으로 집행이 이뤄진다. 추적성은 어떤 필드가 왜 부족했는지, 누가 값을 제공했는지와 같은 모든 검증 이력을 기록하여 이후 감사와 원인 규명이 가능하도록 만든다.

모델이 실행 시점에 필요한 질문을 즉흥적으로 생성해서는 안 된다는 점이 강조됐다; 모델이 스스로 질문 목록을 생성하면 불필요한 재질문이 반복되거나 질문의 방향을 잃는 두 가지 실패 모드가 발생한다고 명시됐다. 따라서 필요한 검증 항목과 위험 조건은 기능 설계자가 사전에 선언해야 하며 에이전트의 역할은 그 목록과 현재 상태를 단순 대조(diff)하는 것으로 제한됐다. 이 접근법은 모델의 자의적 판단을 제거하고 의도된 제어 지점을 고정시키는 수단으로 제안됐다.

이 아키텍처의 주요 이득으로 일관성, 감사 가능성, 확장성을 들었으며 구체적 작동 원리는 결정 기준을 코드·데이터로 옮기는 것이다. 결정 로직이 모델 외부에 있으면 동일 입력은 항상 동일한 Known/Unknown 판정을 받으므로 모델 교체가 실행 여부에 영향을 주지 않으며, JSON 기록으로 '왜 중단됐는지'가 즉시 드러난다. 확장성 측면에서는 새 기능 추가 시 모델을 재훈련하거나 프롬프트를 재설계할 필요 없이 스키마에 필드를 추가하면 된다는 점이 안전 설계의 중심이 이동함을 의미한다.

용어 해설

스키마 검증(Schema Validation): — 실행 전에 입력 데이터가 요구되는 필드와 제약을 만족하는지 구조적으로 확인하는 절차로, 입력을 Known/Unknown으로 표기하고 검증 결과를 별도 레코드에 남긴다. 이 방식은 실행 판단을 모델의 추론이 아니라 정해진 데이터 규격과 대조하는 연산으로 대체하여 결정의 예측 가능성과 일관성을 확보한다. API 파라미터 검증과 유사하되 에이전트의 실행 전 판단 지점에 적용되는 것이 핵심이다.
실행 상태 모델(Execution State Model): — 에이전트가 실행하기 직전의 상태를 표준화된 JSON 구조로 표현한 데이터 모델로, 각 필드의 Known/Unknown 여부와 검증 제약, 값을 제공한 주체를 기록한다. 이 모델은 검증 결과와 실행 로직을 분리하여 실행 허용 여부를 외부 코드나 데이터가 결정하도록 만든다. 결과적으로 실행의 추적 가능성과 책임소재 확인이 가능해진다.
존재 기반 검증(Presence-based Verification): — 실행 허용 기준을 '모든 필수 필드가 스키마에 존재하는지'라는 단순한 기준으로 수렴시켜 모델의 주관적 판단을 배제하는 방법이다. 입력이 요구되는 필드를 모두 채웠는지 여부만 검사하고 부족하면 사용자에게 보완을 요청하여 결정의 일관성을 확보한다. 이 방식은 모델 내부의 확률적 경계가 실행 결과에 미치는 영향을 제거하는 데 목적이 있다.
의도 확인(Intent Confirmation): — 사용자가 의도한 행동을 구조적 항목으로 명시하여 에이전트가 실행 전 의도를 명확히 할 수 있도록 하는 필수 검증 항목 집합이다. 사전선언된 의도 확인 항목과의 대조로 오작동이나 의도 오해로 인한 실행을 방지하며, 의도 관련 값은 검증 레이어에서 우선적으로 체크된다. 이 항목들은 실행 멈춤 기준으로서 안전 제어에 직접 활용된다.

코드 예제

text

Before: input → LLM reasons "is this enough?" → execute or ask
After: input → diff against schema → Known/Unknown verdict → execute or ask

모델 내부 추론에 의존하던 실행 결정을 스키마 대조로 바꾸는 핵심 흐름을 비교한 간단한 의사표현이다. 왼쪽은 확률적 판단에 의존하는 기존 흐름을, 오른쪽은 스키마 기반 판정을 거쳐 실행 여부를 결정하는 절차를 나타낸다. 원문 맥락에서 구조적 변화의 요지를 직관적으로 전달하는 용도로 제시됐다.

text

Checklist (single validation layer) ├── ① Intent-confirmation items → pre-guardrail stage └── ② Safety-confirmation items → guardrail's required fields

단일 검증 레이어의 구성 항목을 간략히 나열한 텍스트로, 의도 확인 항목과 안전 확인 항목을 순서대로 구분한다. 이 체크리스트는 어떤 필드가 선행 검증 대상인지 우선순위를 정하는 설계 관점에서 사용될 수 있다. 원문은 단일 레이어에서 의도 확인을 먼저, 안전 확인을 그다음으로 검증하라고 권한다.

언급된 리소스

문서If unsure, ask. Never guess. — AI Agent Pre-Execution Checklist