유계 자율성: 소비자 측의 타입 지정 액션 계약이 엔터프라이즈 소프트웨어에서 대규모 언어 모델 오류를 차단합니다

문제는 무엇입니까?

엔터프라이즈 소프트웨어에서——CRM, ERP, 내부 도구, 고객 지원 플랫폼——AI 에이전트는 점점 더 결과가 있는 액션을 실행하고 있습니다: 레코드 업데이트, 이메일 발송, 워크플로우 트리거, 다른 클라이언트 워크스페이스 접근. 대규모 언어 모델 (LLM)이 보안 경계를 위반하는 방식으로 오류를 범할 때 문제가 발생합니다:

• 미승인 액션 — 에이전트가 사용자에게 권한이 없는 기능을 실행합니다
• 잘못된 형식의 요청 — 도구 호출 구조가 예상 형식을 위반하여 API가 중단됩니다
• 크로스 워크스페이스 실행 — 멀티 테넌트 환경에서 에이전트가 다른 클라이언트의 데이터를 건드립니다
• 미승인 권한 상승 — 에이전트가 사용자가 승인한 것보다 높은 권한 수준이 필요한 도구를 사용합니다

고전적 해결책은 「모델을 더 잘 훈련시키기」 또는 「프롬프트에 가드레일 추가하기」입니다. 둘 다 확률론적입니다——모델은 여전히 오류를 범할 수 있고, 단지 빈도가 낮을 뿐입니다. 오류가 GDPR 위반이나 클라이언트 신뢰 손실을 의미할 수 있는 엔터프라이즈 환경에서는 충분하지 않습니다.

논문이 제안하는 솔루션

2026년 4월 17일 arXiv에서 발표된 이 논문은 모델 외부에 결정론적 레이어를 제안합니다:

• 타입 지정 액션 계약은 에이전트가 어떤 액션을 실행할 수 있는지, 어떤 인수로, 어떤 컨텍스트에서, 어떤 전제 조건 하에서를 명시적으로 정의합니다
• 소비자 측 실행은 대규모 언어 모델 (LLM)이 액션을 직접 실행하지 않음을 의미합니다——모델은 구조화된 액션 요청을 생성하고 소비자 애플리케이션이 실행 전에 타입 계약에 대해 검증합니다
• 요청이 타입 검사를 통과하지 못하면 (잘못된 타입, 권한 없음, 잘못된 워크스페이스), 액션이 발생하지 않습니다——대규모 언어 모델 (LLM)이 무엇을 「생각했든」 관계없이

아키텍처적으로, 이것은 보안 부담을 확률론적 모델에서 결정론적 타입 시스템으로 이동시킵니다——런타임 기도가 아닌 정적 검사.

실제로는 어떻게 생겼습니까?

저자들은 엔터프라이즈 환경에서의 구체적인 예시를 제공합니다:

예시 1 — 워크스페이스 격리:

UpdateCustomerRecord(customerId: CustomerId, fields: CustomerFields)
  requires: caller.workspace == customer.workspace

대규모 언어 모델 (LLM)이 다른 워크스페이스의 고객을 업데이트하려고 하면, 타입 시스템이 실행 전에 거부합니다.

예시 2 — 권한:

SendExternalEmail(to: EmailAddress, body: String)
  requires: caller.permissions.includes(SEND_EXTERNAL)

모델이 완벽한 이메일을 작성할 수 있습니다——사용자에게 SEND_EXTERNAL 권한이 없으면 액션이 정적으로 실패합니다.

예시 3 — 시맨틱 제약:

DeleteRecord(id: RecordId)
  requires: record.createdBy == caller || caller.isAdmin

모델은 논리적으로 보여도 다른 사람의 레코드를 삭제할 수 없습니다.

왜 이것이 프롬프트 엔지니어링보다 낫습니까?

• 프롬프트 엔지니어링은 모델이 지시를 읽고 준수하는 것에 의존합니다. 모델이 경계 상황을 다르게 해석하거나 실수로 제약을 위반할 가능성이 항상 있습니다.
• 타입 계약은 컴파일러 수준의 검사입니다. 모델의 동작에 의존하지 않습니다. 올바르게 정의되면 커버하는 오류 클래스는 불가능합니다.

트레이드오프는 구현의 복잡성입니다. 타입 시스템은 과도하게 경직되지 않으면서 실제 시나리오를 커버하도록 신중하게 설계되어야 합니다. 논문은 여러 엔터프라이즈 도메인(판매, 지원, HR)의 예시를 포함하며 실제로 실행 가능함을 보여줍니다.

AI 도구 구축에 대한 시사점

엔터프라이즈 AI 통합을 구축하는 개발자들을 위해, 논문은 구체적인 설계 패턴을 제공합니다:

1. 에이전트가 실행할 수 있는 모든 액션을 명시적으로 정의합니다
2. 각 액션에 전제 조건이 있는 타입 계약을 작성합니다
3. 모델이 직접 실행하는 것이 아니라 구조화된 액션 요청을 생성하게 합니다
4. 검증은 모든 사이드 이펙트 전에 결정론적 타입 체커를 통과합니다

이 접근법은 자유 실행보다 구조화된 도구 호출을 추진하는 MCP(모델 컨텍스트 프로토콜) 트렌드와 일치합니다. MCP와 결합하면 MCP와 타입 계약 모두 다른 오류 클래스를 차단하는 다층 방어가 됩니다.

이 논문은 프리프린트이지만, 아이디어는 현재 엔터프라이즈 AI를 구축하는 팀이 공식 동료 심사 출판을 기다리지 않고 즉시 원칙을 적용할 수 있을 만큼 충분히 구체적입니다.