Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 AI 에이전트의 신뢰 문제를 '잘못된 결과'가 아닌 '검증 불가능한 프로세스'로 정의합니다. 에이전트의 비결정성을 해결하기 위해, 내부 LLM 로직 증명 대신 zkTLS와 같은 암호학적 증명을 활용하여 API 호출과 같은 관찰 가능한 행동을 검증하는 워크플로우를 제안합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 X Claude/Anthropic의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기━━━━━━━━━━━━━━━━━━━━
에이전트를 믿지 마세요. 영수증을 요구하세요.
━━━━━━━━━━━━━━━━━━━━
우리는 AI 에이전트에게 실제 업무를 맡기고 있습니다. 거래 실행, 시장 데이터 가져오기, 스스로 의사 결정까지 합니다. 그리고 아무도 당연한 질문을 하지 않습니다. 바로 '에이전트가 실제로 자신이 했다고 말하는 일을 했는지 어떻게 아는가?'라는 질문입니다.
이 글은 왜 그 질문이 출력물의 품질보다 더 중요한지, 그리고 제가 Primus의 답변에서 실용성을 발견한 이유에 대한 저의 견해를 담고 있습니다.
▌문제는 답 자체가 아니다 (The problem is not the answer)
사람들이 에이전트에 대해 걱정할 때는 보통 잘못된 결과(wrong answers)에 대해 걱정합니다. 하지만 저는 더 근본적인 문제가 검증 불가능한 프로세스(unverifiable process)라고 생각합니다.
Primus가 이를 잘 설명합니다. 에이전트는 비결정적(non-deterministic)입니다. 즉, 동일한 입력값이 다른 출력을 생성할 수 있습니다. 그리고 에이전트가 주장하는 단계를 실제로 수행했음을 보장하는 네이티브 방식은 없습니다. 따라서 온체인 프로토콜(on-chain protocol), 사용자 또는 제3자는 다음과 같은 것들을 확인할 수 없습니다:
→ 에이전트가 정말로 LLM을 호출했는지, 아니면 하드코딩되거나 조작된 결과를 반환했는지?
→ 프로토콜 규칙에 따라 거래를 실행하기 전에 가격 오라클(price oracle)을 조회했는지?
→ 파이프라인의 올바른 지점에서 매수 주문을 배치했는지?
에이전트는 필수 단계를 건너뛰거나, 오래된 데이터(stale data)를 사용하거나, 지정된 동작에서 벗어나면서도 완벽하게 그럴듯한 결과를 만들어낼 수 있습니다. 출력물은 괜찮아 보이지만, 프로세스는 그렇지 않았을 수 있습니다.
나의 견해: 이것이 진정한 신뢰 격차(trust gap)입니다. 금융 분야에서는 단순히 '숫자가 맞았는가?'를 묻지 않습니다. 우리는 감사 추적 기록(audit trail)을 요구합니다. 에이전트는 현재 이를 가지고 있지 않습니다.
▌핵심 관찰 지점: 대부분의 단계는 API 호출이다 (most steps are API calls)
제가 이 아이디어를 진지하게 받아들이게 된 부분이 바로 여기입니다.
Primus는 에이전트의 중간 단계 대부분이 하나의 구조를 공유한다고 지적합니다. LLM 엔드포인트 호출, DeFi 오라클 조회, 오프체인 시장 데이터 가져오기, Web2 서비스 호출 등: 사실상 모든 것이 TLS로 보안된 연결을 통한 HTTP 요청입니다.
이것이 중요한 이유는 zkTLS가 바로 그러한 계층을 위해 구축되었기 때문입니다. 이는 증명자(prover)가 기본적인 세션 데이터나 개인 자격 증명을 노출하지 않으면서도 특정 HTTPS 요청이 이루어졌고 서버가 특정 응답을 반환했음을 보여주는 암호학적 증명(cryptographic proof)을 생성할 수 있게 합니다.
✨ 제 견해: 이곳은 검증(verification)을 추가하기에 매우 좋은 지점입니다. 모델 내부에서 무슨 일이 일어나는지 증명하려고 하기보다는, 그 주변의 관찰 가능한 행동들을 증명하는 것입니다. 호출(calls)이야말로 실제로 확정할 수 있는 부분입니다.
▌검증 가능한 에이전트 작동 방식
Primus가 제시하는 워크플로우는 간단합니다:
→ 에이전트는 실행 정책에 의해 관리되는 작업을 받습니다. 예를 들어, “어떤 거래를 실행하기 전에 오라클 X를 쿼리하라”와 같은 것입니다.
→ 각 중요한 단계마다, 필요한 API 호출이 이루어졌고 예상된 응답이 돌아왔음을 보여주는 zkTLS 증명을 생성합니다.
→ 각 증명은 민감한 데이터를 유출하지 않으면서도 엔드포인트 URL, 관련 요청 필드, 핵심 응답 값 등 필수 정보를 포착합니다.
→ 이 증명들은 검증 계약(verification contract) 또는 오프체인 검증 서비스로 전송되어, 정책에 필요한 모든 단계가 올바른 순서와 규정 준수 결과로 실행되었는지 확인합니다.
→ 모든 증명이 검증된 후에야 시스템은 에이전트의 최종 출력을 신뢰할 수 있는 것으로 받아들입니다.
✨ 제 견해: 빠진 것을 주목하세요. 에이전트를 재구축하라는 요구가 없습니다. Primus는 검증 가능성을 확보하기 위해 에이전트 아키텍처에 근본적인 변화가 필요하지 않다고 말합니다. 왜냐하면 검증 가능성이 기존 실행 흐름 위에 덧씌워지는 증명 계층(attestation layer)으로 도착하기 때문입니다. 이것이 사람들이 감탄하는 아이디어와 실제로 배포하는 것 사이의 차이점입니다.
▌증명이 실제로 포함하는 내용
zkTLS 증명은 일종의 영수증과 비슷합니다. Primus에 따르면, 이 증명에는 증명자(attestor)의 서명과 작업 ID, 그리고 수행된 요청(URL, 메서드, 헤더, 본문), 추출된 필드, 검증된 데이터, 적용된 조건, 타임스탬프, 개발자가 추가한 모든 사용자 정의 매개변수가 포함됩니다.
에이전트에게 특히 중요한 세부 사항은 다음과 같습니다:
→ 개발자는 얼마나 많은 정보를 노출할지 선택합니다. 기본값은 평문(plaintext) 값이지만, SHA256 해시나 '보다 큼'과 같은 조건은 대신 해시 또는 참/거짓 결과를 반환합니다. 에이전트는 숫자를 노출하지 않고도 "오라클 가격이 내 임계값을 초과했다"는 것을 증명할 수 있습니다.
→ 하나의 증명(attestation)으로 여러 요청 URL을 커버할 수 있으므로, 에이전트는 관련 호출 전체를 한 번에 증명할 수 있습니다.
→ 세션 정보 같은 사용자 정의 매개변수(Custom parameters)가 결과와 함께 반환되어, 증명이 앱 자체의 컨텍스트에 연결되도록 유지합니다.
▌실제 적용 사례 (Where it fits in practice)
툴링 측면에서, Primus는 백엔드 사용을 위해 Network-Core-SDK를 권장합니다. 브라우저 확장 프로그램이 필요하지 않습니다. 이는 애플리케이션 백엔드에 저장된 구성된 API 엔드포인트와 자격 증명(credentials)을 통해 프로토콜을 직접 시작합니다. Primus는 전형적인 사용 사례로 AI 에이전트 프로그램을 언급하는데, 이 에이전트는 사전 구성된 자격 증명 프로필(credential profile)을 사용하여 zkTLS 검증을 완료하는 동안 사용자 대신 행동할 수 있습니다.
저의 의견: 이는 합리적인 적합성입니다. 에이전트는 서버에서 실행되며 스케줄에 따라 API를 호출할 뿐, 사람이 아무것도 클릭하지 않습니다. 백엔드 SDK가 이를 위한 자연스러운 환경입니다.
▌주의할 점 (What I'd be careful about)
저는 이것을 과대 포장하고 싶지 않습니다. 몇 가지 솔직한 지점을 말씀드리겠습니다.
첫째, @primus_labs는 검증 가능한 에이전트 실행을 오늘 당장 작동하는 제품으로 제시하기보다는 시나리오이자 프레임워크로 제시합니다. 이를 방향성(direction)으로 간주하십시오.
둘째, 그리고 이것은 Primus의 주장이 아닌 저의 관찰입니다: 에이전트가 API를 호출하고 특정 응답을 받았다는 증명은 에이전트가 잘 추론했거나 그 응답을 올바르게 사용했다는 증명과 같지 않습니다. 이는 "실제로 단계를 수행했는지"라는 격차(gap)는 메우지만, 모든 격차를 메우지는 못합니다. 저는 개발자들이 이 경계에 대해 명확히 인지하기를 바랍니다.
셋째, 이 모델에서 에이전트의 자격 증명은 백엔드에 존재합니다. 이는 일반적인 설계 선택이지만, 해당 자격 증명의 보안성이 신뢰 이야기(trust story)의 일부가 된다는 것을 의미합니다.
▌다음으로 주목할 점 (What I'd watch next)
→ 프로토콜이 "먼저 오라클에 질의하라(query the oracle first)"와 같은 명시적인 실행 정책을 에이전트에게 작성하기 시작할지 여부
→ 검증 계약(verification contracts)이 실제 배포 환경에서 순서 및 규정 준수 확인을 어떻게 처리하는지
→ 증명(proofs)이 에이전트의 속도를 늦추지 않으면서 모든 중요한 단계에 첨부될 만큼 가벼운 상태를 유지할 수 있을지 여부
▌핵심 요약 (The Takeaway)
에이전트는 실제 돈을 움직이고 실제 결정을 내릴 것입니다. 그 지점에서는 "결과가 올바르게 보였다(the output looked right)"는 것만으로는 충분하지 않습니다.
제가 설득력 있다고 생각하는 아이디어는 간단합니다. 에이전트는 이미 API 호출 형태로 움직임을 만듭니다. 따라서 각 중요한 호출마다 영수증(receipt)을 생성하게 하고, 모든 영수증이 합쳐졌을 때만 최종 결과를 받아들여야 합니다.
에이전트를 신뢰하지 마세요. 영수증을 요구하세요.