모델 외부로 실행 권한 이동하기

재현되지 않는 실행들
동일한 프롬프트, 동일한 입력 — 하지만 결과가 다릅니다. 모델 버전이 변경되었기 때문이 아닙니다. "이것이 실행하기에 충분한가?"라는 판단이 확률적 추론 (probabilistic reasoning) 내부에 존재하기 때문에, 온도 (temperature)나 컨텍스트 (context)의 미세한 차이만으로도 흔들립니다. 이것은 재현성 (reproducibility) 문제가 아니라, 제어 가능성 (controllability) 문제입니다.

원칙: 존재 기반 검증 (Presence-based Verification) (실행 시점의 스키마 검증 (schema validation))
AI가 스스로 "내가 충분히 알고 있는가?"를 판단하게 하는 대신, "정의된 스키마 (schema)에 따라 실행에 필요한 필드들이 존재하는가?"만을 확인합니다.

존재함 (알려짐) → 실행
부재함 (알려지지 않음) → 사용자에게 채워 넣도록 다시 전달

진정한 문제는 "에이전트가 실행을 한다는 사실 그 자체"가 아닙니다. 문제는 "무엇을 바탕으로 실행했는지 알 방법이 없고, 실패할 경우 처음부터 다시 시작해야 하며, 책임 소재를 추적할 흔적이 없다"는 것입니다.

실행 상태 (The Execution State)
실행 상태는 표준화된 JSON 구조를 사용하여 표현됩니다. 모든 선언된 요구 사항이 충족된 후에만 실행이 시작됩니다. 이 모델 하에서 생성되는 모든 실행 상태는 네 가지 원칙을 따릅니다:
분리 (Separation) → 검증 (Validation) → 강제 (Enforcement) → 추적 가능성 (Traceability)

분리 (Separation): 검증 결과는 실행 로직과 별도로 기록됩니다. 실행은 오직 기록된 상태만을 참조합니다.
검증 (Validation): 현재 입력이 각 필수 필드 (Required Field) 및 선언된 검증 제약 조건 (Validation Constraints)을 충족하는지 확인하고, 각 필드를 '알려짐 (Known)' 또는 '알려지지 않음 (Unknown)'으로 기록합니다.
강제 (Enforcement): '알려지지 않음 (Unknown)'으로 기록된 필드는 사용자가 채울 수 있도록 전달됩니다. 모든 필드가 '알려짐 (Known)' 상태가 되면 검증이 완료됩니다.
추적 가능성 (Traceability): 무엇이 알려져 있었는지, 무엇이 누락되었는지, 누가 값을 제공했는지, 그리고 왜 실행이 허용되었거나 보류되었는지를 모두 기록합니다.

AI는 질문을 직접 작성할 수 없습니다. 체크리스트는 실행 시점에 모델이 즉흥적으로 만드는 것이 아니라, 사전에 선언되어야 합니다. 그렇지 않으면 모델이 불필요하게 계속 질문을 던지거나, 모델 스스로 무엇을 질문해야 하는지에 대한 방향성을 잃게 됩니다.

변화하는 점: 결정 권한이 모델 외부로 이동합니다.
이전: 입력(input) → LLM 추론 ("이 정도면 충분한가?") → 실행 또는 질문
이후: 입력(input) → 스키마 차이(schema diff) → 알려짐/알려지지 않음 상태(Known/Unknown State) → 실행 또는 질문

스키마의 유일한 역할은 필수 필드를 선언하는 것이며, 검증(validation)은 단순히 현재 상태를 해당 선언과 비교하는 것입니다. 알려지지 않은 필드는 오직 사용자 입력을 통해서만 해결될 수 있습니다. 결과적으로, 실행 권한은 확률적인 모델의 판단에서 다시 사용자로 이동합니다.

체크리스트는 단일 검증 계층입니다.
체크리스트(Checklist)
├── ① 의도 확인 항목 (Intent-confirmation items) → 가드레일 전 단계 (pre-guardrail stage)
└── ② 정확성 및 안전성 항목 (Accuracy & Safety items) → 가드레일의 필수 필드

전통적인 가드레일은 정보가 누락되면 단순히 중단됩니다. 반면, 이 시스템은 누락된 정보와 사용자의 의도/문맥을 먼저 해결하여 실행 상태(Execution State)를 완성한 다음, 그제서야 가드레일을 통과하도록 합니다. 이것이 중요한 이유는 세 가지입니다:

1. 일관성 (Consistency) — 동일한 입력은 동일한 결과를 생성합니다. 모델을 교체하더라도 실행 여부는 변하지 않습니다.
2. 감사 가능성 (Auditability) — "왜 이것이 보류되었는가"를 추론 과정(reasoning trace)을 뒤져볼 필요 없이 JSON에서 직접 읽을 수 있습니다.
3. 확장성 (Extensibility) — 새로운 기능을 추가하는 것은 모델을 재학습하거나 프롬프트를 다시 작성하는 것이 아니라, 스키마 필드를 추가하는 것을 의미합니다.

안전의 중심축이 "더 똑똑한 모델"에서 "잘 정의된 스키마"로 이동합니다.

본 작업은 체크리스트에 무엇이 포함되어야 하는지를 규정하지 않습니다. 대신, 필요한 체크리스트가 무엇이든 명시적으로 선언되고, 결정론적(deterministically)으로 강제되며, 실행 상태(Execution State)의 일부로 기록되어야 한다고 제안합니다.

전체 체크리스트 구조와 적용 사례는 원문 게시물에 나열되어 있습니다.
비판과 질문은 언제나 환영합니다. 확신이 서지 않는다면 질문하십시오. 절대 추측하지 마십시오.

— AI Agent 사전 실행 체크리스트 (AI Agent Pre-Execution Checklist)를 LLM의 도움을 받아 번역 및 편집하였으며, /u/Jay299792458 님이 제출하였습니다. [link] [comments]