새벽 3시, 당신의 AI 에이전트가 당신이 들어본 적도 없는 체인으로 500달러를 브릿징(bridge)해 버렸습니다.

로그에는 "최적의 경로를 찾았습니다(optimal route found)"라고 적혀 있습니다. 잔액은 0달러입니다. 에이전트는 왜 그랬는지 설명하지 못합니다.

이것이 바로 우리가 6개월 동안 해결하려고 노력했던 문제입니다.

우리는 Kuberna Labs를 구축했습니다. 이는 AI 에이전트에게 모든 블록체인에 걸쳐 안전한 실행 레일(execution rails)을 제공하는 MIT 라이선스 SDK입니다. 전체 프로젝트는 오픈 소스입니다: github.com/kawacukennedy/kuberna-labs

우리가 실제로 구축해야 했던 것들은 다음과 같습니다.

"에이전트 실행(agent execution)"의 실제 의미

대부분의 사람들은 "AI 에이전트"라고 하면 도구 접근 권한이 있는 챗봇을 떠올립니다. 하지만 우리가 만드는 것은 그것이 아닙니다.

API를 호출하는 에이전트와 금융 거래를 결제하는 에이전트는 근본적으로 다른 문제입니다. 전자는 HTTP 요청을 포맷팅하는 것에 관한 것이지만, 후자는 체인 간에 가치를 이동시키고, 발생한 일을 증명하며, 문제가 생겼을 때 분쟁을 해결하는 것에 관한 것입니다.

우리의 정의에 따른 에이전트 실행(Agent execution)은 다음을 의미합니다:

1. 에이전트가 **의도(intent)**를 형성합니다 ("Solana에서 1 ETH를 USDC로 스왑")
2. 해당 의도가 구조화되고 검증 가능한 형식으로 **파싱(parsed)**됩니다.
3. **실행자(Executors)**들이 최적의 가격으로 의도를 이행하기 위해 경쟁합니다.
4. **에스크로 계약(escrow contract)**이 조건이 충족될 때까지 자금을 보유합니다.
5. **TEE 증명(TEE attestation)**이 에이전트의 결정이 올바르게 내려졌음을 증명합니다.

위의 모든 레이어는 처음부터 구축해야 했습니다. 오픈 소스 에이전트 결제(settlement)를 위한 기성 솔루션은 존재하지 않았습니다.

의도 기반 실행(intent-based execution)이 직접 지갑을 사용하는 것보다 안전한 이유

에이전트에게 개인 키(private key)를 주는 것은 명백한 접근 방식입니다. 그리고 그것은 매우 공포스러운 일입니다.

에이전트가 키를 보유하면, 에이전트가 실행되는 어디에서든 그 키에 접근할 수 있습니다. 에이전트가 해킹당한다는 것은 지갑이 털린다는 것을 의미합니다. 중개자도 없고, 분쟁 기간도 없으며, 구제책도 없습니다.

우리의 아키텍처는 이를 뒤집습니다: 에이전트는 절대 키를 보유하지 않습니다. 에이전트는 의도(intents)를 게시합니다. 실행자들은 해당 의도를 이행하기 위해 경쟁합니다. 온체인 에스크로 계약은 조건이 충족될 때만 거래를 결제합니다.

const sdk = new KubernaSDK({ apiKey: process.env.KUBERNA_API_KEY })

const intent = await sdk.intents.create({
...

에이전트가 의도(intent)를 게시합니다. 나머지는 SDK가 처리합니다. 키(key)도, 수탁(custody)도, 단일 장애점(single point of failure)도 없습니다.

의도 파서(intent parser)의 체인 환각(hallucination)을 방지하는 방법

이것은 우리가 해결한 가장 어려운 기술적 문제였습니다.

우리는 자연어 의도(natural language intents)를 파싱하기 위해 GPT-4로 시작했습니다. 결과는 공포스러웠습니다:

// 입력: "bridge my ETH to Arbitrum"
// GPT-4 출력:
{ sourceChain: "Ethereum", destChain: "Arbitrum", token: "ARB" }

GPT-4는 목적지 **체인(chain)**을 **ARB 토큰(token)**과 혼동했습니다. 만약 에이전트가 이 파싱 결과를 실행했다면, 브릿징(bridging) 대신 ETH를 ARB로 스왑(swap)했을 것입니다. 이는 10,000달러짜리 환각(hallucination)입니다.

우리는 4단계 폴백(fallback) 시스템을 구축했습니다:

1. compromise.js — 완전히 오프라인에서 작동하는 의존성 없는 NLP(자연어 처리). 의도의 80%를 처리합니다.
2. 12개의 정규 표현식(regex) 패턴 — "X for Y on Z" 및 그 변형들을 매칭합니다. 결정론적(deterministic)이며 실패 모드가 없습니다.
3. GPT-4 폴백 — 1단계와 2단계의 신뢰도(confidence)가 0.6 미만일 때만 작동합니다. 약 15%의 사례에서 활성화됩니다.
4. RAG 메모리 — 과거의 파싱 결과로부터 학습합니다. 일반적인 패턴은 시간이 지남에 따라 2단계로 승격됩니다.

각 단계는 신뢰도 점수를 할당합니다. 우리는 점수가 0.6을 초과하는 첫 번째 단계에서 멈춥니다.

결과: 프로덕션 환경에서 환각된 체인이 발생하지 않았습니다. 모든 엣지 케이스(edge case)를 다루는 175개의 테스트를 통과했습니다.

AI 에이전트를 위한 온체인 에스크로(on-chain escrow)의 모습

신뢰가 필요 없는 결제(trustless settlement)를 위해서는 에이전트 특유의 엣지 케이스를 처리하는 에스크로 계약(escrow contract)이 필요합니다:

function assignExecutor(
  bytes32 intentId,
  address executor,
...

assignExecutor와 raiseDispute에 적용된 nonReentrant 수정자(modifier)는 재진입 공격(reentrancy attacks)을 방지합니다. 모든 의도에는 분쟁 기간(dispute window)이 있습니다. 만약 에이전트가 실행 결과에 동의하지 않으면, 자금은 해결될 때까지 묶여 있게 됩니다.

증명 가능한 결정을 위해 TEE 증명(attestation)이 중요한 이유

에이전트의 결정 추적(decision trace)은 증명 가능해야 합니다. 증명(attestation)이 없다면, 에이전트는 "무슨 일이 일어났는지 모른다"라고 주장할 수 있으며, 사용자는 이를 검증할 방법이 없습니다.

우리는 SGX 엔클레이브 내부에서 의사 결정을 수행합니다. 모든 추론(inference)은 암호화된 영수증을 생성합니다:

{
  "intentId": "0xabc...",
  "decision": "executor_selected",
...
}

이 영수증은 온체인(on-chain)에 저장됩니다. 누구나 에이전트가 특정 시점에 신뢰 실행 환경(trusted execution environment) 내부에서 주장하는 결정을 내렸는지 검증할 수 있습니다.

회로 차단기 문제 (The circuit breaker problem)

죽은 API를 계속 호출할 수 있는 에이전트는 돈을 태우는 에이전트입니다.

저희는 모든 OpenAI 호출 주변에 슬라이딩 윈도우 방식의 회로 차단기(circuit breaker)를 구현했습니다:

• CLOSED: 정상 작동
• 5분 동안 3회 실패 → OPEN
• 30초 간격으로 테스트 시도 → HALF_OPEN
• 테스트 성공 → CLOSED
• 테스트 실패 → 다시 OPEN

const circuit = new CircuitBreaker(intentParser, {
  threshold: 3,
  windowMs: 300_000,
...

회로가 열리면(open), 에이전트는 로컬의 compromise.js 파서로 폴백(fallback)합니다. API 호출이 필요 없습니다. 에이전트는 여전히 작동하며, 단지 더 간단한 결정을 내릴 뿐입니다.

점진적 저하(Graceful degradation) > 완벽한 가동 시간(perfect uptime).

무엇이 잘못되었는지 (솔직히 말하자면)

모든 것이 순조롭지는 않았습니다. 저희가 실수했던 부분은 다음과 같습니다:

가격 오라클로서의 Math.sin(). 저희 최초의 '시장 데이터 제공자'는 가짜 가격 데이터를 생성하기 위해 Math.sin()을 사용했습니다. 이는 일종의 플레이스홀더였는데, 어찌된 일인지 스테이징 환경까지 올라갔습니다. 실제 API 통합이었다면 이 문제를 더 일찍 잡아냈을 것입니다.

직접 지갑 통합(Direct wallet integration). 저희 최초 설계에서는 에이전트에게 지갑 접근 권한을 부여했습니다. 테스트 과정에서 아찔한 경험을 한 후 이를 되돌렸습니다. 의도 기반 아키텍처(intent-based architecture)는 구축하기가 더 어렵지만 근본적으로 더 안전합니다.

회로 차단기 부재. 저희는 API 호출에 대한 속도 제한(rate limiting) 없이 첫 버전을 배포했습니다. 에이전트는 우리가 알아차리기 전에 죽은 OpenAI 엔드포인트를 47번 호출했습니다. 호출할 때마다 돈이 들었습니다. 모든 호출은 아무것도 반환하지 않았습니다.

의도 파서의 환각 체인(Intent parser hallucinating chains). 위에서 언급된 GPT-4의 환각 문제는 저희에게 일주일간의 리팩토링 비용을 초래했습니다. 4계층 시스템은 실패로부터 탄생했습니다.

다음 목표는 어디인가

• zkTLS 통합 (zkTLS integration) — 민감한 데이터를 공개하지 않고 에이전트의 결정을 증명함
• Solana 지원 (Solana support) — 실행 계층 (execution layer)의 첫 번째 비 EVM 체인
• NEAR 인텐트 (NEAR Intents) — NEAR의 인텐트 인프라를 사용한 크로스체인 결제 (cross-chain settlement)

전체 프로젝트는 MIT 라이선스입니다. 175개의 테스트가 모두 통과(green)되었습니다. 만약 여러분이 크로스체인 결제 (cross-chain settlement)와 싸워 이겼거나(혹은 패배했거나) 경험이 있다면, 댓글로 들려주세요. PR (Pull Request)은 언제나 환영합니다.

이 시리즈의 다음 글: 왜 우리는 GPT-4가 금융 인텐트 (Financial Intents)를 파싱하도록 두지 않는가 (그리고 대신 무엇을 사용하는가)