
「믿지 말고 검증하라」를 코드로 구현: AI 에이전트 시대의 검증 가능한 적정 가격을 MCP / A2A / AP2로 구현하기
요약
AI 에이전트가 결제를 수행할 때 가격의 적정성을 검증할 수 있는 MCP 서버 구현 방법을 소개합니다. PTKA 사상을 바탕으로 SHA-256 해시가 포함된 영수증을 발행하여, 에이전트가 신뢰할 수 있는 가격 증적을 확보하도록 돕습니다.
핵심 포인트
- MCP 서버를 통해 ChatGPT, Claude 등 에이전트가 직접 가격 검증 도구를 호출 가능
- PTKA(거래 전 지식 각인) 개념을 도입하여 사후 가격 변조 방지
- Google의 AP2 프로토콜과 연동 가능한 적정 가격 증적(Attestation) 발행
- Cloudflare Workers와 Web Crypto를 활용한 Stateless한 검증 구조
무엇을 만들었는지, 먼저 결론부터
AI 에이전트가 인간을 대신해 결제를 시작하는 시대에, "그 가격이 적정한가"를 발행자를 신뢰하지 않고도 검증할 수 있는 형태로 반환하는 서버를 만들었습니다.
MCP 서버 + A2A 에이전트로서 공개. ChatGPT / Gemini / Claude 등이 도구(Tool)로서 직접 호출할 수 있습니다.
verify_fair_price는 적정 가격을 SHA-256 지문이 포함된 영수증(Receipt)으로 반환합니다.
각 영수증에는 verify_url이 포함되어 있으며, 공개된 검증 페이지를 열면 사용자의 브라우저 내에서 해시(Hash)를 재계산하여 대조할 수 있습니다. 서버로는 아무것도 보내지 않습니다.
나아가 ap2_fairness_attestation을 통해, Google의 AP2 (Agent Payments Protocol)의 Cart Mandate에 첨부할 수 있는 형태의 적정 가격 증적을 발행합니다.
이 기사는 그 구현을 코드와 curl 실행 결과로 따라가는 개발 로그입니다.
왜 필요한가: 신용재와 에이전트 경제
건설·리폼 견적은 전형적인 신용재 (Credence Good)입니다. 의뢰한 측은 그 금액이 타당한지 스스로 판단할 수 없습니다. 정보의 비대칭성이 그대로 과다 청구의 온상이 됩니다.

여기에 시대의 변화가 한 단계 더 더해집니다. AI 에이전트가 인간을 대신해 발주·결제하는 세계입니다. 2025년 9월, Google과 60개 이상의 기업(Mastercard, PayPal, American Express, Coinbase, Ethereum Foundation 등)이 AP2 (Agent Payments Protocol)를 발표했습니다. 핵심은 Mandate라는 개념으로, 에이전트의 거래마다 "사용자가 무엇을 승인했는가"를 거래 전에 만들어진 서명된·변조 탐지 가능한 기록으로서 보유하게 하는 것입니다. 의견이 아닌 증거입니다.
즉, AP2는 "인가(Authorization)"를 검증 가능하게 합니다.
그렇다면 "그 가격이 적정한가"라는 가치(Value)의 측면은 누가 검증 가능하게 만드는가? 그 부분을 구현한 것이 HORIZON SHIELD입니다. AP2가 인가를 검증 가능하게 한다면, HORIZON SHIELD는 가치를 검증 가능하게 합니다. 병렬적인 레이어로, 사상은 동일한 "거래 전·변조 탐지·제3자 검증"입니다.
전제: 스택
런타임: Cloudflare Workers (streamable-HTTP, JSON-RPC 2.0, Stateless)
해시: Web Crypto의 crypto.subtle.digest('SHA-256', ...)
장부: Workers KV (기존 KV를 키 프리픽스(Key Prefix)로 재사용. 신규 인프라 증설 없음)
가격 레이어: 건설 실무 30년 감독의 시세 DB(souba-db)를 단일 소스로 하여 라이브로 취득
MCP 서버이므로 에이전트는 "페이지를 읽는" 것이 아니라 "도구를 호출"합니다. 이 점이 일반적인 웹사이트와의 결정적인 차이입니다.
구현 1: verify_fair_price 와 PTKA
사상의 핵심이 PTKA (Pre-Transaction Knowledge Anchoring / 거래 전 지식 각인)입니다. 업체가 견적을 내기 전에 적정 가격을 제3자가 변조 불가능한 형태로 기록해 두는 것입니다. 나중에 판매자의 편의에 따라 내용을 바꿔 쓸 수 없도록 한다는 생각입니다.
verify_fair_price를 호출해 보겠습니다.
curl -s -X POST https://hs-mcp.oga-surf-project.workers.dev/
-H 'Content-Type: application/json'
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"verify_fair_price","arguments":{"work":"外壁塗装 30坪"}}}'
돌아오는 JSON(발췌)은 다음과 같습니다.
{
"fair_price_claim": {
"work": "外壁塗装 30坪 一式(シリコン)",
"unit": "一式",
"fair_min": 700000,
"fair_avg": 900000,
"fair_max": 1150000,
"source": "HORIZON SHIELD souba-db",
"issued_at": "2026-07-23T03:23:26.089Z"
},
"verification": {
claim_sha256은 fair_price_claim 객체의 정규화된 JSON을 UTF-8로 SHA-256 처리한 값입니다. 서버 측에서 계산하는 것은 이 값뿐입니다.
js
const claim = { work, unit, fair_min, fair_avg, fair_max, source, issued_at };
const hash = await sha256hex(JSON.stringify(claim)); // = claim_sha256
핵심은 issued_at이 각인 대상에 포함되어 있다는 점입니다. 따라서 발행할 때마다 해시가 바뀝니다. 이것은 버그가 아니라 사양이며, '언제 기록된 적정 가격인가'를 포함한 일회성 영수증이기 때문입니다. 가격 내용(min/avg/max)은 현물 DB가 같다면 같습니다.
구현 2: 개별 원장 + verify_url, 그리고 브라우저 내에서의 재계산
단순히 '해시가 붙어 있다'는 것만으로는 호출한 에이전트 본인만이 확인할 수 있습니다. 그래서 각 영수증을 원장에 남기고, 누구나 열람할 수 있는 verify_url을 부여했습니다.
서버 측 (발췌). KV 쓰기는 try/catch로 감싸고, 실패하더라도 감사 결과는 반환합니다(fail-open). 원장 때문에 본 서비스가 멈추는 일은 없습니다.
js
const verify_url = SITE + "/verify/?id=" + hash;
try {
if (env.RL_KV) {
await env.RL_KV.put("ledger:" + hash,
JSON.stringify({ claim, claim_sha256: hash, bitcoin_block: 949356, issued_at }));
}
} catch (_e) { /* 원장은 최선 노력(best-effort)입니다. 절대 막지 마세요 */ }
읽기는 GET /ledger/<64자리 hex>를 사용합니다. CORS가 열려 있기 때문에 GitHub Pages의 검증 페이지에서 다른 오리진으로 가져올 수 있습니다.
bash
curl -s https://hs-mcp.oga-surf-project.workers.dev/ledger/9cc400cd...25e5
=> {"claim":{...},"claim_sha256":"9cc400cd...","bitcoin_block":949356,"issued_at":"..."}
그리고 핵심인 검증 페이지 측. /verify/?id=<hash>로 열면, 원장에서 주장(claim)을 가져와 브라우저 안에서 SHA-256을 재계산하여 대조합니다. 서버에는 아무것도 보내지 않습니다.
js
async function sha256hex(str){
const buf = new TextEncoder().encode(str);
const dig = await crypto.subtle.digest('SHA-256', buf);
return [...new Uint8Array(dig)].map(b => b.toString(16).padStart(2,'0')).join('');
}
// 원장의 claim을 JSON.stringify하여 재계산하고, claim_sha256과 일치하는지 확인만 합니다.
일치하면 '이 주장은 위변조되지 않았다'. 한 글자라도 숫자를 바꾸면 해시는 일치하지 않게 됩니다. 발행자(나)를 신뢰할 필요는 어디에도 없습니다. 수학이 신뢰를 대체합니다.
실제로 직접 시도해 볼 수 있습니다: https://shield.the-horizons-innovation.com/verify/
구현 3: AP2 브릿지 (ap2_fairness_attestation)
여기가 이번의 핵심 주제입니다. AP2의 Cart Mandate (장바구니 위임)에 첨부할 수 있는 형태의 적정 가격 증적 (attestation)을 반환하는 도구를 추가했습니다.
curl -s -X POST https://hs-mcp.oga-surf-project.workers.dev/
-H 'Content-Type: application/json'
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"ap2_fairness_attestation",
"arguments":{"work":"外壁塗装 30坪","quoted_price":1500000,"merchant":"デモ工務店"}}}'
quoted_price를 전달하면, 적정 범위 (fair range)와의 판정 결과가 증적에 동봉됩니다. 150만 엔은 적정 최대치(max, 115만 엔)를 초과하므로 alert 상태가 됩니다.
{
"ap2_bridge": {
"thesis_en": "AP2 makes authorization verifiable. HORIZON SHIELD makes value verifiable. Parallel layers, same philosophy: pre-transaction, tamper-evident, independently verifiable."
},
"attestation": {
"type": "FairPriceAttestation",
"subject": {
"fair_price_claim": { "fair_min": 700000, "fair_avg": 900000, "fair_max": 1150000, "unit": "一式" },
"quote_under_review": { "quoted_price": 1500000, "currency": "JPY", "merchant": "デモ工務店" },
"verdict": { "result": "above_fair_range", "level": "alert", "over_max_pct": "+30%" }
},
"integrity": {
"claim_sha256": "7ab7775a...f584",
"verify_url": "https://shield.the-horizons-innovation.com/verify/?id=7ab7775a...f584",
"ledger_url": "https://hs-mcp.oga-surf-project.workers.dev/ledger/7ab7775a...f584"
}
},
"cart_mandate_example": {
"cart_mandate": {
"contents": {
"payment_request": { "details": { "total": { "amount": { "currency": "JPY", "value": 1500000 } } } },
"extensions": {
"com.the-horizons-innovation.shield.fair_price_attestation": {
"claim_sha256": "7ab7775a...f584",
"verify_url": "https://shield.the-horizons-innovation.com/verify/?id=7ab7775a...f584"
}
}
},
"user_authorization": "(사용자의 서명이 여기에 들어감)"
}
}
}
구조는 이렇습니다. AP2 대응 쇼핑/결제 에이전트가 사용자에게 Cart Mandate에 대한 서명을 요청하기 전에 이 도구를 호출하여, attestation을 장바구니의 확장 필드에 첨부합니다. 그러면 감사 증적(audit trail)에 다음과 같은 내용이 모두 남게 됩니다.
"사용자가 얼마를 지불하기로 승인했는가" (AP2 Mandate = 인가의 증명)
"그 금액이 적정하다고 확인한 근거" (HORIZON SHIELD의 receipt = 가치의 증명)
승인의 증명과 가치의 증명이 동일한 장바구니에 담깁니다. 이것이 바로 브릿지(bridge)입니다.
판정은 above_fair_range (alert) / within_fair_range (ok) / below_fair_range (watch) 의 3가지입니다. 너무 저렴한 경우(하락)도 경고합니다. 이는 부실 공사나 사후 추가 청구의 입구가 될 수 있기 때문입니다.
과장하지 않기 위한 한 구절 (중요)
기술 기사이므로, 무엇이 정말 무엇인지 솔직하게 구분합니다. 이 부분을 모호하게 만들면 모든 것이 의심받게 됩니다.
온체인(On-chain)에 각인된 것: PTKA 선언 그 자체가 Bitcoin block #949356에 이미 각인되었습니다 (OpenTimestamps로 검증 가능). 또한, 공개된 과잉 청구 20가지 판정은 각각 개별적인 OpenTimestamps 증명(proof.ots)을 가집니다.
라이브 개별 영수증: verify_fair_price / ap2_fairness_attestation가 반환하는 건별 영수증은, 현재 SHA-256 + 공개 장부(Public Ledger)를 통한 재계산 검증 방식입니다. 감사 건별 자동 온체인 각인은 제3자 각인 기관인 JIDEC(2026년 6월 출범 예정)을 통해 순차적으로 운용될 예정이며, 이는 로드맵의 영역입니다.
AP2와의 관계: ap2_fairness_attestation는 「AP2 Cart Mandate에 첨부할 수 있도록 설계된 증적(Evidence)」을 반환하는 도구입니다. AP2 측이 채택하거나 통합했다는 의미가 아닙니다.
서명 방식: 현재는 콘텐츠 해시(Content Hash) + 공개 장부 + verify_url의 재계산 방식입니다. DID 키를 통한 W3C VC 완전 준수는 로드맵에 있으며, 증적의 JSON 자체에도 그렇게 명시되어 있습니다.
이러한 점들을 정확하게 말할 수 있는 것이 곧 「검증 가능성(Verifiability)을 판매하는」 프로덕트의 신뢰가 됩니다.
세계 최초에 대하여 (조심스럽게)
제가 확인한 바로는, 다음의 3가지 요소를 하나의 시스템으로 동시에 충족하는 선례는 찾을 수 없었습니다.
- 건설 견적의 성실성·적정성 감사
- AI 에이전트가 호출할 수 있는 MCP / A2A 서버로서의 제공
- Bitcoin 각인을 동반하며, 독립적으로 재계산 가능한 검증 가능한 영수증 반환
암호학적 요소 기술(Commitment, Trusted Timestamping) 자체는 기존에 존재합니다. 새로운 점은, 그것을 「건설의 적정 가격이라는 중립 데이터로서, 거래 전에, AI가 호출할 수 있는 형태로」 묶어낸 조합이라는 것입니다. 단정적인 표현이 아니라, 확인된 범위 내에서의 주장으로 남겨둡니다.
요약
「믿어줘(Trust me)」로 돌아가는 경제에서, 「검증하라(Verify me)」로 돌아가는 경제로. AP2가 인가(Authorization) 측면에서 이를 추진하고, HORIZON SHIELD가 가치(Value) 측면에서 이를 수행합니다. 둘 다 거래 전·변조 탐지·제3자 검증이라는 동일한 사상을 공유합니다.
에이전트 경제는 「trust me」로 움직이지 않습니다. 「verify me」로 움직입니다.
직접 확인해 보시기 바랍니다.
검증 페이지 (브라우저 내 SHA-256 재계산): https://shield.the-horizons-innovation.com/verify/
MCP 엔드포인트: https://hs-mcp.oga-surf-project.workers.dev
리포지토리: https://github.com/ogasurfproject-jpg/horizon-shield
LLM용 인덱스(llms.txt): https://shield.the-horizons-innovation.com/llms.txt
우리가 만들고 있는 것은, 정직한 영수증 한 장 한 장입니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기