DeFi 인프라에서 탄생하여 이제 AI 시스템에 적용되는 설계 프로토콜

문제점

당신은 AI 에이전트(AI agent)를 구축했습니다. 그것은 작동하며 — 때로는 훌륭하게 작동합니다.

하지만 그러다 보면 당신이 요청하지 않은 일들을 하기 시작합니다.

• 스스로 가정을 하고 그에 따라 행동합니다.
• "모르겠습니다"라고 말하는 대신 누락된 데이터를 임의로 채워 넣습니다.
• 단지 관찰(observe)만을 요청했는데 최적화(optimize)를 시도합니다.
• 거절해야 할 상황에서 확신에 찬 답변을 내놓습니다.

이것은 모델(model)의 문제가 아닙니다. 이것은 아키텍처(architecture)의 문제입니다.

당신의 에이전트에는 경계 계약(boundary contract)이 없습니다.

이 아이디어의 기원

나는 Aave v3를 위한 DeFi 리스크 옵저버(risk observer)를 구축했습니다. 이는 온체인(on-chain) 포지션을 감시하고 청산 리스크(liquidation risk)를 실시간으로 보고하는 시스템입니다.

가장 어려웠던 설계 결정은 데이터 모델(data model)이나 상태 머신(state machine)이 아니었습니다.

그것은 바로 이 질문이었습니다:

시스템이 아무것도 출력하지 않고 거절해야 하는 시점은 언제인가?

DeFi에서 잘못된 답변은 단순히 쓸모없는 것이 아니라 — 실제 금융 손실을 초래할 수 있습니다. 그래서 나는 다음과 같은 것들을 명시적으로 분리하는 시스템을 설계했습니다:

• 무엇이 검증되었는지 (protocol에서 직접 가져온 것)
• 무엇이 유도되었는지 (검증된 데이터로부터 계산된 것)
• 무엇이 추정되었는지 (근사치이며, 그렇게 라벨링된 것)
• 무엇을 거절해야 하는지 (불확실하거나, 일관성이 없거나, 보여주기에 안전하지 않은 것)

내가 이 동일한 철학을 콘텐츠 자동화(content automation)를 위해 구축하던 AI 에이전트에 적용했을 때 — 이는 DeFi와는 완전히 무관한 것이었습니다 — 에이전트의 과잉 행동(overreach)이 현저히 감소했습니다.

원칙은 전이되었습니다. 경계 계약(boundary contract)은 효과가 있었습니다.

핵심 원칙

불확실성보다는 거절을. 예측보다는 경계를. 자동화보다는 관찰 가능성(observability)을.

대부분의 AI 시스템은 항상 출력을 생성하도록 설계되어 있습니다. 침묵은 실패처럼 느껴집니다. 불확실성은 매끄럽게 다듬어집니다. 공백은 그럴듯하게 들리는 콘텐츠로 채워집니다.

그 결과: 확신에 차서 잘못된 일을 수행하는 에이전트가 탄생합니다.

경계 계약(boundary contract)은 이러한 기본 설정을 뒤집습니다.

네 가지 계층

모든 AI 출력은 네 가지 신뢰 계층 중 하나로 분류될 수 있습니다:

1. VERIFIED (검증됨)

직접적으로 관찰 가능합니다. 시스템이 신뢰할 수 있는 출처로부터 이를 검색했으며, 이를 확인할 수 있습니다.

"해당 기사는 2026년 6월 1일에 발행되었습니다."

2. CONSISTENT (일관됨)

검증된 데이터로부터 결정론적 (deterministically)으로 도출됩니다. 논리가 투명하고 반복 가능합니다.

"발행일을 기준으로 볼 때, 이는 30일 이내의 기간에 해당합니다."

3. ESTIMATED (추정됨)

근사치입니다. 유용하지만, 명시적으로 그렇게 라벨링(labeling)됩니다. 사실로 취급해서는 안 됩니다.

"읽는 시간은 약 4분입니다."

4. REFUSED (거부됨)

시스템이 신뢰할 수 있는 출력을 생성할 수 없습니다. 잘못된 정보를 제공하기보다 아무것도 말하지 않습니다.

출력 보류됨. 사유: 소스 데이터 불일치.

상태 모델 (The State Model)

신뢰 계층을 관찰 가능한 상태와 쌍으로 묶으십시오:

상태	의미
STABLE	안전한 경계 내에서 작동 중
...

이것들은 오류가 아닙니다. 거부(REFUSAL)는 실패가 아니라 기능(feature)입니다.

이를 AI 에이전트에 적용하기

실제적인 예시를 들어보겠습니다. 당신의 에이전트가 최근 뉴스 기사를 요약한다고 가정해 봅시다.

경계 계약(boundary contract)이 없는 경우:

• 기사 누락 → 에이전트가 그럴듯한 내용을 지어냄 (hallucination)
• 오래된 데이터 → 에이전트가 이를 최신 정보인 것처럼 제시함
• 상충하는 소스 → 에이전트가 하나를 선택하고 다른 하나는 무시함

경계 계약(boundary contract)이 있는 경우:

• 기사 누락 → 사유와 함께 REFUSED 처리: "소스를 사용할 수 없음"
• 오래된 데이터 → 라벨과 함께 ESTIMATED 처리: "데이터가 오래되었을 수 있음"
• 상충하는 소스 → 라벨과 함께 DEGRADED 처리: "소스가 일치하지 않음"

에이전트는 자신이 무엇을 알고 무엇을 모르는지에 대해 정직해집니다.

시스템 프롬프트 패턴 (The System Prompt Pattern)

다음은 시스템 프롬프트에서의 최소한의 구현 예시입니다:

당신은 관찰자 에이전트(observer agent)입니다. 당신의 역할은 행동하는 것이 아니라 상태를 보고하는 것입니다.

모든 출력에 대해, 다음 중 하나로 분류하십시오:
...

이 단 한 줄의 추가가 제가 시도했던 그 어떤 프롬프트 엔지니어링 (prompt engineering) 기법보다 제 에이전트들의 동작을 더 많이 변화시켰습니다.

이것이 작동하는 이유

근본적인 원리는 간단합니다:

프로토콜은 상태(states)가 아니라 전이(transitions)를 제한합니다.

AI 에이전트는 잘못된 데이터, 모호한 입력, 충돌하는 컨텍스트와 같은 외부 상황을 통해 좋지 않은 상태(bad state)에 빠질 수 있습니다. 이는 피할 수 없는 일입니다.

당신이 제어할 수 있는 것은, 에이전트가 해당 상태를 인지하고 이를 명시적으로 처리할 것인지, 아니면 자신감 있어 보이는 출력으로 이를 대충 덮어버릴 것인지 여부입니다.

경계 계약(Boundary Contract)은 에이전트의 인식 상태(epistemic state)를 당신과 다운스트림 시스템(downstream systems)이 읽을 수 있게 만듭니다.

공개 내용

저는 이를 문서로 공식화했습니다:

AI 시스템을 위한 경계 계약(Boundary Contract for AI Systems) v0.1

포함된 내용은 다음과 같습니다:

• 전체 신뢰 계층 사양 (VERIFIED / CONSISTENT / ESTIMATED / REFUSED)
• 전이 규칙(transition rules)이 포함된 상태 모델
• 일반적인 에이전트 패턴을 위한 시스템 프롬프트 템플릿
• 비자문 무결성 조항 (Non-Advisory Integrity Clause, 에이전트가 절대 해서는 안 되는 행동)
• 트리거 조건이 포함된 거부 프로토콜 (Refusal protocol)

Gumroad에서 확인 가능: https://arcthree.gumroad.com/l/etb-boundary-contract

마지막 생각

제가 본 가장 신뢰할 수 있는 AI 시스템들은 한 가지 공통점을 가지고 있습니다:

그들은 자신이 무엇을 모르는지 알고 있다는 점입니다.

그러한 인식을 내부에 구축하려면 명시적인 설계가 필요합니다. 기본적으로 이루어지는 것이 아닙니다.

경계 계약은 이를 의도적으로 만드는 방법입니다.

UEH (Universal Exchange Adapters) 설계 철학을 기반으로 구축되었습니다.
본래 DeFi 리스크 관측 인프라를 위해 개발되었습니다.
_GitHub: github.com/ueh-labs/ueh-observer