모든 API가 Agent에 의해 호출되어야 하는 것은 아니다

Collection is not Callability: PubFi는 왜 AI Agent를 위한 신뢰할 수 있는 crypto data gateway를 구축하는가

AI Agent가 진정으로 외부 세계에 접속하게 되면, 한 가지 문제가 점점 더 중요해집니다. Agent가 온체인(on-chain) 데이터가 필요할 때, 도대체 누구를 호출해야 할까요?

예를 들어 지갑 잔액, 토큰 가격(token price), 거버넌스 제안(governance proposals) 세트, 또는 특정 체인의 트랜잭션 활동을 조회하고 싶다고 가정해 봅시다. 겉보기에는 단순히 API를 찾는 것처럼 보이지만, 실제로는 전혀 간단하지 않습니다.

Crypto data의 문제는 데이터 소스가 없는 것이 아니라, 데이터 소스가 너무 많다는 것입니다. Subscan, DeFiLlama, CoinGecko, Alchemy, QuickNode, Dune, Covalent, Bitquery, The Graph 같은 이름들은 개발자들에게 익숙합니다. 문제는 각 제공자(provider)마다 자신만의 문서(documentation), 인증(authentication) 방식, 가격, 제한(limit), 반환 구조(return structure), 범위(coverage), 그리고 데이터 신선도(data freshness)를 가지고 있다는 점입니다.

인간 개발자는 문서를 천천히 읽고, 키(key)를 신청하고, 인터페이스를 테스트하고, 반환 값을 확인하며, 폴백(fallback)을 구현할 수 있습니다. 하지만 Agent가 매번 이 판단 과정을 반복해서 수행해서는 안 됩니다.

PubFi의 진입점은 바로 여기에 있습니다. PubFi는 단순히 API 모음집을 만드는 것도 아니고, 각 제공자에게 멋져 보이는 툴(tool) 레이어를 씌워주는 것도 아닙니다. PubFi가 진정으로 관심을 두는 것은 다음과 같습니다: 하나의 데이터 소스가 "발견"되어 "Agent가 안전하게 호출할 수 있는 상태"가 되기까지, 그 사이에 어떤 증거들이 결여되어 있는가.

한 문장으로 요약하자면: Collection is not Callability. 수집되었다고 해서, 호출 가능하다는 뜻은 아닙니다.

API 디렉토리는 Agent의 런타임(runtime) 문제를 해결할 수 없다

전통적인 API 디렉토리(directory)는 "존재 여부"에 집중합니다. 문서가 있는지, 엔드포인트(endpoint)가 있는지, 가격 페이지(pricing page)가 있는지, SDK가 있는지, 상태 페이지(status page)가 있는지 등을 따집니다.

물론 이것들도 가치가 있습니다. 하지만 Agent에게는 충분하지 않습니다.

Agent의 문제는 "세상에 특정 API가 존재하는가"가 아닙니다. Agent의 문제는 다음과 같습니다:

이 API를 지금 바로 내가 호출할 수 있는가?
호출하려면 어떤 키(key)가 필요한가?
현재 사용자에게 권한이 있는가?
비용이 발생하는가?
반환된 데이터가 충분히 최신인가?
이 제공자(provider)가 내가 원하는 체인(chain)과 데이터 타입(data type)을 실제로 커버하는가?
실패할 경우, 시스템은 어떻게 설명할 것인가?
호출에 성공했다면, 누가 이 호출이 발생했음을 기록할 것인가?

API가 발견되었다는 것은 단지 그것이 존재함을 의미할 뿐입니다. 문서가 파싱되었다는 것은 단지 인터페이스 설명이 있음을 의미할 뿐입니다. 제공자가 코퍼스(corpus)에 진입했다는 것은 단지 공공 정보로서의 가치가 있음을 의미할 뿐입니다. 이 모든 것들이 "이제 Agent가 호출할 수 있다"는 결론으로 자동 도출되지는 않습니다.

수집된 후보(collected candidate)에서 호출 가능한 경로(callable route)로 넘어가기 위해서는 자격 증명(credential), 정책(policy), 신선도(freshness), 어댑터 인증(adapter certification), 사용량 회계(usage accounting), 그리고 클레임 안전성(claim safety)이라는 단계가 사이에 놓여 있습니다.

이것이 바로 PubFi와 일반적인 API 디렉토리의 차이점입니다. 일반적인 디렉토리는 "존재"를 종착지로 보지만, PubFi는 "존재"를 시작점으로 봅니다.

PubFi의 3층 구조

PubFi를 이해하기 위해 먼저 세 가지 층으로 나누어 볼 수 있습니다: Discovery, Gateway, Route Intelligence.

Discovery는 입구입니다.

이는 인간, 검색 엔진, 답변 엔진(answer engine), 그리고 AI Agent를 대상으로 합니다. 여기에는 소스 페이지(source pages), 카테고리 허브(category hubs), 체인 허브(chain hubs), 비교 페이지(comparison pages)가 있으며, llms.txt, agents.md, Markdown 미러(mirrors), OpenAPI 내보내기(exports)도 포함됩니다.

하지만 Discovery는 단순한 SEO가 아닙니다. 그것은 일종의 수요 센서(demand sensor)에 가깝습니다. 누군가 "MCP crypto data API", "x402 crypto data API", "Subscan vs SubSquid", "Polkadot data API"를 검색할 때, 이러한 쿼리(query)는 단순한 트래픽 유입구가 아니라 PubFi에게 다음과 같은 정보를 전달합니다: 시장이 무엇을 묻고 있는지, 어떤 데이터 소스가 해석될 필요가 있는지, 어떤 역량의 공백이 다음 단계로 나아갈 가치가 있는지를 말입니다.

Gateway는 출구입니다.

만약 어떤 경로(route)가 실제로 호출 가능하다면, 그것은 Gateway를 통해 호출되어야 합니다. Gateway는 API 키(API key), 크레딧(credit), 제공자 어댑터(provider adapter), 업스트림 자격 증명 주입(upstream credential injection), 응답 정규화(response normalization), 그리고 사용 사실(usage facts)을 담당합니다.

이는 PubFi가 단순히 요청을 상위(upstream)로 전달하기만 하는 것이 아님을 의미합니다. 누가 호출하고 있는지, 권한이 있는지, 무엇을 소비했는지, 상위에서 어떤 상태를 반환했는지, 그리고 이번 호출이 어떻게 기록되었는지를 파악해야 합니다.

Route Intelligence는 중간 판단 계층(judgment layer)입니다.

Agent는 보통 "provider X의 endpoint Y를 호출해 주세요"라고 말하지 않습니다. 대신 "BTC 현물 가격을 알려줘", "이 지갑의 토큰 잔액을 확인해줘", "특정 거버넌스 제안서 데이터를 가져와줘"와 같이 말할 가능성이 높습니다.

Route Intelligence는 이러한 자연어 요구사항을 구조화된 의도(intent)로 변환한 다음, 후보를 찾고, 필터링하고, 순위를 매긴 후 최종 결정을 내립니다: 현재 호출 가능한 경로(route)가 있는지, 추가 정보가 필요한지, 단순히 수요 신호(demand signal)만 기록해야 하는지, 조달 검토(procurement review) 단계로 진입해야 하는지, 아니면 호출을 거절해야 하는지 등을 결정합니다.

진짜 어려운 점은 언제 호출하지 말아야 할지를 아는 것입니다

많은 agent 제품들이 "지능형 라우팅(intelligent routing)"을 하나의 모델 능력으로 설명하곤 합니다. 즉, 사용자 질문을 임베딩(embedding), 리랭커(reranker) 또는 LLM에 던진 뒤 가장 유사한 API를 선택하는 방식입니다.

하지만 실제 시스템에서는 의미론적 유사성(semantic similarity)만으로는 턱없이 부족합니다.

특정 provider의 문서가 사용자 요구사항과 매우 유사하다고 해서, 반드시 사용 가능한 자격 증명(credential)을 보유하고 있다는 뜻은 아닙니다. endpoint 이름이 올바르게 보인다고 해서 목표 네트워크(network)를 커버한다는 의미도 아닙니다. 특정 route가 코퍼스(corpus)에 등장한다고 해서 이미 어댑터 인증(adapter certification)을 통과했다는 뜻도 아닙니다. API가 유료 호출을 지원한다고 해서 시스템이 자동으로 조달하거나 결제할 수 있다는 의미도 아닙니다. 어떤 페이지에 MCP나 x402가 적혀 있다고 해서, 오늘 바로 라이브 MCP 도구(live MCP tool)나 라이브 x402 결제 실행(live x402 payment execution)이 가능하다는 뜻도 아닙니다.

따라서 PubFi의 route intelligence는 모델이 자유롭게 발휘하도록 두는 것이 아닙니다. 그 순서는 다음과 같아야 합니다:

요구사항을 먼저 정규화(normalize)합니다.
그다음 후보를 찾습니다.
먼저 하드 필터(hard filters)를 실행합니다.
그다음 랭킹(ranking)을 매깁니다.
모델 점수는 오직 투명한 입력값(input)으로만 사용됩니다.
증거가 불충분할 때는 반드시 기권(abstain)해야 합니다.

이는 매우 기초적이지만 중요한 공학적 윤리입니다. agent가 답을 원한다고 해서 시스템이 마치 능력이 있는 것처럼 가장해서는 안 됩니다.

Agent 인프라(infrastructure)에서 잘못된 가용성(availability) 정보는 일반 웹사이트의 과장된 문구보다 훨씬 더 위험합니다. 왜냐하면 agent는 실제로 그것을 사용하여 호출하고, 비용을 지불하고, 판단을 내리며, 심지어 다음 자동화 프로세스를 트리거할 수 있기 때문입니다.

Growth Loop: "호출 불가"를 다음 단계로 전환하기

만약 특정 route를 지금 호출할 수 없다면, PubFi는 단순히 실패로 끝내서는 안 됩니다. 실패를 제품의 신호(signal)로 바꿀 수 있습니다.

이것이 바로 Gateway Growth Loop의 의미입니다: 외부 API 발견(discovery), 문서 파싱(docs parsing), API 코퍼스(corpus), 통합 후보 큐(integration candidate queue), 어댑터 인증(adapter certification), 키워드 성장(keyword growth), SEO/GEO 추천, 이슈 아웃박스(issue outbox).

하나의 API가 발견되면, 처음에는 단순히 수집된 후보(collected candidate)일 뿐입니다. 문서 파싱에 성공하면 endpoint 사실(facts)이 됩니다. 코퍼스에 진입하면 공개적으로 안전한 프로필 증거(public-safe profile evidence)가 됩니다. 후보 큐(candidate queue)에 진입해야 비로소 어댑터를 만들 가치가 있는지 평가받을 수 있습니다. 인증(certification)을 통과해야 runtime enabled 될 기회를 얻습니다. 마지막으로 자격 증명(credential), 인증(auth), 사용량(usage), 청구 안전성(claim safety)이 모두 충족되었을 때 비로소 gateway available이라고 불릴 수 있습니다.

이 경로는 매우 절제되어 있습니다. "수집"을 "능력"으로 포장하지 않으며, "연구 프로토타입"을 "운영 가능(production-ready)"으로 포장하지도 않습니다.

PubFi 문서에는 이와 유사한 경계선이 반복적으로 등장합니다:

코퍼스 포함(corpus inclusion)이 gateway availability는 아닙니다.
크롤러 히트(crawler hit)가 AI 인용(AI citation)은 아닙니다.
llms.txt가 agent callability는 아닙니다.
x402 샌드박스 증명(sandbox proof)이 라이브 결제 실행(live payment execution)은 아닙니다.
소스 페이지가 존재한다고 해서 PubFi가 해당 소스를 호출할 수 있는 것은 아닙니다.
후보 큐(candidate queue)에 있는 provider가 이미 조달되거나 권한을 부여받았음을 의미하지는 않습니다.

이 문장들은 제한처럼 보이지만, 실제로는 제품의 신뢰성을 확보하는 원천입니다.

왜 이 일이 AI Agent 시대에 중요한가

Model Context Protocol (MCP)과 같은 표준은 AI 애플리케이션이 외부 데이터, 도구 및 워크플로우(workflow)에 더 쉽게 연결될 수 있도록 하고 있습니다. 공식 소개는 다음을 참조하세요: https://modelcontextprotocol.io/docs/getting-started/intro

x402와 같은 프로토콜은 machine-to-machine payment (기계 간 결제)와 HTTP 402를 다시 논의의 중심부로 가져옵니다. 공식 웹사이트는 다음을 참조하세요: https://www.x402.org/

이러한 트렌드는 에이전트(agent)가 외부 시스템을 더 쉽게 호출할 수 있게 만들겠지만, 동시에 오래된 문제를 증폭시킬 것입니다: 한 번의 호출이 정말로 안전한지, 권한이 있는지, 측정 가능한지, 그리고 설명 가능한지를 누가 판단할 것인가?

전통적인 애플리케이션에서 API integration (API 통합)은 보통 개발자에 의해 수행됩니다. 개발자는 인터페이스가 신뢰할 수 있는지, 키(key)가 유효한지, 가격이 합리적인지, 실패 시 복구가 가능한지를 판단합니다.

하지만 에이전트 네이티브 (agent-native) 애플리케이션은 이러한 판단을 런타임 (runtime) 단계로 미룹니다. 에이전트는 특정 유형의 데이터가 필요하다고 임시로 결정할 수 있고, 여러 제공자 (provider) 사이에서 선택해야 할 수도 있으며, 비용, 지연 시간 (latency), 신선도 (freshness), 권한에 따라 절충안을 찾아야 할 수도 있습니다. 또한 증거가 불충분할 경우 호출하지 않기로 선택할 수도 있습니다.

이 시점에서는 일반적인 API 디렉토리 (directory)만으로는 충분하지 않습니다. 에이전트에게 필요한 것은 "발견 가능성 (discoverable), 설명 가능성 (explainable), 호출 가능성 (callable), 거부 가능성 (rejectable), 감사 가능성 (auditable)"을 표현할 수 있는 데이터 계층입니다.

PubFi가 판매하는 것은 "더 많은 API"가 아니다

표면적으로만 보면 PubFi는 crypto data gateway (크립토 데이터 게이트웨이)처럼 보입니다. 하지만 더 정확하게 말하자면, PubFi는 에이전트 시대의 데이터 신뢰 계층 (data trust layer)을 구축하고 있습니다.

이 신뢰 계층은 다음과 같은 사항들을 포함합니다:

에이전트가 데이터 소스를 발견할 수 있도록 함;
에이전트가 어떤 데이터 소스가 어떤 문제에 적합한지 이해할 수 있도록 함;
실제로 사용 가능한 경로 (route)가 통합 게이트웨이 (gateway)를 통해 호출되도록 함;
매 호출마다 사용 사실 (usage facts)을 남김;
호출 불가능한 요구사항을 수요 (demand) 또는 조달 (procurement) 프로세스로 전환함;
공개된 주장 (public claim)이 실제 능력을 초과하지 않도록 함.

이는 "우리는 100개의 제공자 (provider)를 지원합니다"라고 말하는 것보다 더 어렵고, 또한 더 가치 있는 일입니다.

AI 에이전트 시대에는 정보 획득 비용이 점점 더 저렴해질 것이기 때문입니다. 진정으로 희소한 것은 판단력입니다: 무엇을 믿을 수 있는지, 무엇을 호출할 수 있는지, 그리고 언제 멈춰야 하는지 말입니다.

PubFi의 제품 성격은 바로 여기에 있습니다. 모든 것을 사용할 수 있다고 서둘러 말하는 대신, found (발견됨), documented (문서화됨), requestable (요청 가능함), contract ready (계약 준비됨), gateway available (게이트웨이 사용 가능), not supported (지원되지 않음)를 진지하게 구분합니다. 각 상태는 저마다의 가치를 지니지만, 서로를 사칭해서는 안 됩니다.

Collection is not Callability

“Collection is not Callability”는 그저 멋진 슬로건이 아닙니다. 이는 시스템 설계 원칙입니다.

이는 PubFi가 모든 단계에서 스스로에게 질문을 던지도록 요구합니다: 우리가 지금 정확히 무엇을 알고 있는가? 이 증거만으로 에이전트 호출(agent call)을 지원하기에 충분한가? 만약 부족하다면, 시스템은 '부족함'을 어떻게 정직하게 표현해야 하는가?

이는 아마 가장 화려하지 않은 AI 서사일지 모르지만, 에이전트가 실제로 프로덕션 환경에 진입하기 위해 반드시 보완되어야 할 부분입니다.

정보를 수집하는 것은 점점 쉬워지고 있습니다. 인터페이스 래퍼(interface wrapper)를 생성하는 것도 점점 쉬워질 것입니다. 모델이 제공자(provider)를 추측하게 만드는 것 또한 점점 쉬워질 것입니다.

어려운 점은, 자동화 시스템 내에서 여전히 다음 원칙을 고수해야 한다는 것입니다: 증거가 없으면 호출하지 않는다. 호출할 수 없다면 그 신호를 남겨야 한다. 그리고 호출할 수 있다면, 반드시 설명 가능(interpretable), 감사 가능(auditable), 추적 가능(traceable)해야 합니다.

이것이 PubFi가 하려는 일입니다: AI 에이전트에게 더 많은 진입점(entry point)을 제공하는 것이 아니라, 더 신뢰할 수 있는 출구(exit point)를 제공하는 것입니다.

Collection is not Callability: PubFi는 왜 AI Agent를 위한 신뢰할 수 있는 Crypto Data

요약

핵심 포인트