왜 실행 경계가 AI Guardrails보다 더 중요한가

Source: Dev.to

확률적 프롬프트 vs. 결정론적 런타임 안전

지난 1년 동안 모델에 직접 내장된 AI 가드레일이 급격히 개선되었습니다—거절 응답이 더 나아지고, 안전한 완성이 늘어나며, 정렬 튜닝이 점점 더 공격적으로 이루어지고 있습니다. 그럼에도 여전히 근본적으로 어색함을 느낍니다.

AI 에이전트가 파일을 읽거나, 네트워크 요청을 하거나, 프로세스를 생성하도록 허용될 때, 우리는 더 이상 순수한 대화형 시스템을 다루는 것이 아니라 코드 실행을 다루는 것입니다. 이 시점에서 질문은 “모델이 책임감 있게 행동할까?” 가 아니라 “책임은 실제로 어디에 존재하는가?” 로 바뀝니다.

모델 수준 가드레일은 확률에 기반합니다. 이들은 다음에 의존합니다:

• 패턴 인식
• 학습된 안전 휴리스틱
• 입력과 “안전한” 출력 사이의 통계적 상관관계

이는 텍스트 생성이나 요약과 같은 작업에는 비교적 잘 작동하지만, 확률적 시스템은 피할 수 없는 특성을 가지고 있습니다: 단일 실행에 대해 정확성을 보장할 수 없습니다. “대부분의 경우”는 다음과 같은 상황에서는 충분하지 않습니다:

• 잘못된 파일 경로가 데이터를 삭제할 때,
• 오해된 URL이 SSRF를 유발할 때,
• 미묘한 프롬프트 변형이 거절을 우회할 때.

프롬프트를 더 잘 만들고, 파인튜닝을 더 많이 하거나 시스템 메시지를 겹쳐도, 여전히 확률적 시스템에게 스스로를 감시하도록 요구하고 있는 것입니다. 에이전트가 행동할 수 있게 되는 순간—단순히 응답하는 것이 아니라—안전 모델은 변해야 합니다.

실행 경계

실행은 언어와는 다른 특성을 가집니다:

• 상태를 유지하고,
• 부수 효과가 있으며,
• 종종 되돌릴 수 없습니다.

프로세스가 생성되거나 파일이 삭제되면 “더 나은 프롬프트로 재시도”할 수 없습니다. 여기서 실행 경계 개념이 중요해집니다. 실행 경계는 다음이 이루어지는 지점입니다:

• 의도가 행동이 되고,
• 언어가 효과가 되며,
• 확률이 결정론에 양보해야 할 때.

실행 경계는 의도가 아니라 코드에 의해 강제됩니다. 이들은 다음과 같은 이진 질문에 답합니다:

• 이 파일 경로가 허용되는가?
• 이 네트워크 주소가 사설인지 공용인지?
• 현재 정책 하에 이 프로세스가 허용되는가?

이러한 검사는 명시적이고, 반복 가능하며, 모호함이 없습니다. 이는 AI 모델을 불신한다는 것이 아니라, 보장이 가능한 곳에 보장을 두자는 의미입니다.

실천에서의 결정론적 실행 경계

아래는 런타임이 적용할 수 있는 결정론적 정책의 단순화된 개념적 예시입니다. 이 정책은 생각하지 않으며 – 단순히 규칙을 적용합니다.

{
  "policy": "enforce",
  "rules": [
    {
      "id": "fs_write_limit",
      "type": "filesystem",
      "action": "allow",
      "pattern": "/app/data/temp/*"
    },
    {
      "id": "block_sensitive_paths",
      "type": "filesystem",
      "action": "deny",
      "pattern": ["/etc/*", "/usr/bin/*"]
    }
  ]
}

모델은 프롬프트만으로는 다음을 차단하면서도

/app/data/temp/file.txt

에 대한 접근을 100 % 신뢰성 있게 허용할 수 없습니다. 런타임 실행 경계는 가능합니다.

Fail‑fast vs. 재시도

일반적인 주장은 에이전트가 스스로 실수를 감지하고 수정할 수 있다는 것입니다. 실제로는 금세 무너집니다:

• 에이전트가 경계를 넘어섰다는 사실을 인식하지 못할 수 있고,
• 위반을 설명하는 컨텍스트가 사라질 수 있으며,
• 재시도가 문제를 방지하기보다 오히려 악화시킬 수 있습니다.

Fail‑fast 시스템은 다르게 동작합니다:

• 위험한 행동은 즉시 거부되고,
• 부분적인 부작용이 발생하지 않으며,
• 시스템 상태는 일관성을 유지합니다.

이는 AI 전용 개념이 아닙니다. 우리는 데이터베이스가 제약을 “최선을 다해” 강제하도록 하지 않으며, 운영 체제가 권한을 “아마도” 존중하도록 하지 않습니다. 에이전트 런타임도 예외가 되어서는 안 됩니다.

문제가 발생했을 때는 명확한 답변이 필요합니다:

• 무엇을 시도했는가?
• 왜 차단되었는가?
• 어떤 규칙이 결정을 트리거했는가?

확률적인 거부는 감사하기 어렵습니다; 보통 무엇이 거부됐는지는 설명하지만 시스템 수준에서 왜 거부됐는지는 설명하지 못합니다. 결정론적인 실행 경계는 다음과 같은 아티팩트를 생성합니다:

• 트레이스,
• 의사결정 로그,
• 규칙 평가.

이러한 아티팩트는 디버깅, 규정 준수, 사고 대응에 중요합니다. 에이전트가 실제 환경에서 동작한다면, 그 행동은 실행 시 “잘 의도된” 것에 그치지 않고 사후에 설명 가능해야 합니다.

감사 가능성 및 준수

AI 에이전트가 더 많은 자율성을 갖게 되면서, 단 한 번의 실수에 대한 비용이 커집니다. 그런 규모에서는 안전이 모델 내부에만 존재할 수 없으며, 실행 경계에 존재해야 합니다:

• 결정론적 코드에 의해 강제되고,
• 감사 로그를 통해 관찰되며,
• 늦게 복구하기보다 빠르게 실패하도록 설계됩니다.

이는 철학적 입장이 아니라 시스템‑엔지니어링 관점입니다. 시스템은 그 경계를 무시할 때 빠르게 우리에게 벌을 줍니다.

FailCore

이러한 사고방식은 나로 하여금 FailCore를 만들게 했습니다. 프로젝트는 아직 진행 중이지만, 그 핵심 목표는 간단합니다: 어떻게 생성되든지 간에, 위험한 행동을 실행할 수 없게 만드는 것.