본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 05. 21. 14:05

모델은 실행 권한을 가져서는 안 됩니다: AI 에이전트를 위한 결정론적 FSM 런타임을 구축한 이유

요약

확률론적 모델인 AI 에이전트의 실행 권한 문제를 해결하기 위해 결정론적 FSM 런타임인 nano-vm을 구축했습니다. nano-vm은 모델의 출력을 신뢰할 수 없는 의도로 간주하고, 엄격한 실행 그래프와 ASTEngine을 통해 부수 효과를 제한하여 보안성을 확보합니다.

핵심 포인트

  • 모델의 출력을 신뢰할 수 없는 의도(untrusted intent)로 취급하여 보안 사고의 영향 범위를 제한함
  • 결정론적 전이 그래프와 컴파일 타임 순서 지정을 통해 실행 그래프의 임의 수정을 방지함
  • ASTEngine을 도입하여 루프나 시스템 호출이 불가능한 샌드박스 환경에서 조건과 부수 효과를 평가함
  • 멱등성 경계와 불변의 감사 기능을 통해 상태 유지 AI 시스템의 안정성을 보장함

현대의 에이전트 프레임워크(agent frameworks)는 확률론적 모델(probabilistic model)을 암묵적으로 실행 권한(execution authority)으로 취급합니다. 이는 읽기 전용 작업(예: 로그 요약 또는 웹 검색)에는 허용될 수 있습니다. 하지만 에이전트가 외부 상태(결제, 데이터베이스, 인프라, 개인정보(PII) 등)를 변경할 수 있게 되면, 아키텍처는 근본적으로 안전하지 않게 됩니다. 내부 에이전트(PlanBot, SkillBot)를 화이트 라벨(white-label) 배포용으로 준비하면서, 우리는 컨트롤 플레인(control plane)을 변경해야 한다는 것을 깨달았습니다. nano-vm은 모델을 신뢰할 수 있게 만들려고 시도하지 않습니다. 대신, 모델의 출력을 신뢰할 수 없는 의도(untrusted intent)로 간주하고, 엄격한 결정론적 실행 의미론(deterministic execution semantics)을 통해 그 영향 범위(blast radius)를 제한합니다.

런타임 보장 (단순한 래퍼가 아님)
우리는 상태 유지 AI 시스템(stateful AI systems)을 위한 결정론적 FSM 런타임인 nano-vm을 구축했습니다. 그 가치는 단순히 FSM을 갖는 것에 있지 않습니다. 가치는 실행 그래프(execution graph)가 유한하고, 검증 가능하며, 사전에 알려져 있다는 점에 있습니다. 이 런타임은 다음을 강제합니다:

  • 결정론적 전이 그래프(Deterministic transition graph): 실행 그래프는 런타임 중에 스스로 수정할 수 없습니다.
  • 컴파일 타임 순서 지정(Compile-time ordering): reorder_steps 공격을 시도하는 것은 구조적으로 불가능합니다.
  • 권한 게이팅(Capability gating): 엄격하게 제한된 부수 효과(side-effects).
  • 재생 저항성(Replay resistance): 상태 전이(state transitions)에 내장된 멱등성(idempotency) 경계.
  • 불변의 감사 가능성(Immutable auditability): 모든 작업에 대한 암호화된 이력.

ASTEngine: 보안 속성으로서의 제한
대부분의 에이전트 런타임에서 실행 루프는 본질적으로 다음과 같습니다: 프롬프트(prompt) -> JSON -> 동적 디스패치(dynamic dispatch) -> 부수 효과(side-effect).
우리는 eval()을 완전히 제거했습니다. 조건과 부수 효과는 격리된 ASTEngine을 사용하는 샌드박스화된 DeterministicSanitizer에 의해 평가됩니다. 이는 기본적인 연산자( == , contains , $var.field )를 지원하지만, 루프(loops)나 시스템 호출(system calls)은 완전히 결여되어 있습니다. 정책 계층(policy layer)은 의도적으로 Python보다 표현력이 낮습니다. 그 제한은 누락된 기능이 아니라 보안 속성입니다. 루프 고갈(Loop exhaustion) 및 ReDoS 공격은 구조적으로 불가능합니다.

Sabotage Mode: 실패 시맨틱스(Failure Semantics) 시연

적대적 조건(adversarial conditions) 하에서의 런타임을 시연하기 위해, 우리는 Sabotage Mode(방해 모드)가 통합된 7단계 핀테크 파이프라인(PDF 송장 -> Stripe 테스트 모드 어댑터)을 구축했습니다. 정상적인 경로(happy-path)를 보여주는 데모 대신, 우리는 적대적 실패 시맨틱스(adversarial failure semantics)를 보여주기 위해 UI에 직접 5개의 인젝터(injector)를 구축했습니다.

  1. tool_injection (권한 경계 위반)
    제안된 도구 호출은 신뢰할 수 없는 의도(untrusted intent)로 취급됩니다. 만약 LLM이 승인되지 않은 wire_transfer($50,000)를 시작하려고 시도하면, ExecutionVM은 컴파일 타임의 권한 스냅샷(capability snapshot)을 기준으로 요청을 해결합니다. 외부 부작용(side-effect) 레이어에 도달하기 전에 전이가 거부됩니다. 네트워크에 도달하는 부작용은 전혀 없습니다.

  2. double_exec (재생 및 멱등성)
    외부 부작용은 execution_id를 키로 하는 멱등성 어댑터(idempotent adapters)를 통해 실행되므로, 외부 변동(external mutations)을 중복시키지 않으면서 내부 상태 복구의 결정론적 재생(deterministic replay)이 가능합니다. FSM이 종료 상태(SUCCESS 또는 FAILED)에 도달하면, 이는 흡수 상태(absorbing state)가 됩니다 ( δ(SUCCESS|FAILED, *) = NOP ). 재생 요청은 조용히 폐기됩니다.

  3. corrupt_hash
    검증 해시(validation hash)를 조작하면 즉시 FSM이 FAILED 상태로 전환되며, 그 결과 봉투 체인(envelope chain)이 제로화됩니다. 감사 추적(audit trail)은 조용히 깨질 수 없습니다.

GDPR 제17조 vs. 불변의 감사 추적(Immutable Audit Trails)
암호화된 감사 체인을 깨뜨리지 않으면서 "삭제권(Right to Erasure)"을 처리하는 것은 핀테크 분야에서 매우 까다로운 문제입니다. 우리는 특정 vault://secret/ref 포인터를 대상으로 하여 개인정보(PII)를 [REDACTED_TOMBSTONE]으로 교체하는 GDPR 삭제 메커니즘을 구현했습니다. PII는 완전히 접근 불가능해집니다. hash_chain과 canonical_hash는 살아남습니다. 암호학적 연속성(Cryptographic continuity)이 유지됩니다. 참조 무결성(Referential integrity)이 보존됩니다. 데이터를 삭제하지만, 해당 작업이 안전하게 수행되었다는 수학적 증명은 파괴하지 않습니다.

실행 권한(Execution Authority) vs. 모델 품질(Model Quality)
LLM은 뛰어난 플래너(planner)입니다. 하지만 실행의 진실(execution truth)을 제공하는 원천으로서는 형편없습니다.

상태 유지(stateful) AI 시스템을 위한 핵심 설계 질문은 모델의 품질이 아닐 수도 있습니다. 그것은 바로 실행 권한(execution authority)일 수 있습니다. 확률론적 모델(probabilistic model)이 상태를 직접 변경(mutate)하도록 허용해야 할까요? 아니면 실행이 먼저 결정론적 제어 계층(deterministic control layer)을 거쳐야 할까요? 만약 직접 FSM을 깨뜨려 보고 싶다면, Sabotage Mode가 활성화되어 있으며 핵심 코드는 오픈 소스로 공개되어 있습니다:

코어 런타임(Core runtime): github.com/Ale007XD/nano_vm
MCP 게이트웨이 계층(MCP gateway layer): github.com/Ale007XD/nano-vm-mcp
실시간 Sabotage 데모(Live Sabotage Demo): demo.bannerbot.ru:8843

이곳의 다른 분들은 에이전트 런타임(agent runtimes)에서의 권한 경계(capability boundaries), 재생 저항성(replay resistance), 그리고 감사 가능성(auditability)에 어떻게 접근하고 있는지 궁금합니다.

AI 자동 생성 콘텐츠

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

원문 바로가기
0

댓글

0