AI가 인간을 고용하기 시작했다

2026년 2월, RentAHuman.ai라는 서비스가 출시되었습니다. AI 에이전트가 인간을 고용하기 위한 마켓플레이스입니다. 에이전트가 API로 구인 공고를 내면, 인간이 현지 사진 촬영이나 배달 같은 '물리 세계의 태스크 (Physical World Task)'를 수행하고 보상을 받습니다. 출시 후 약 5개월 만에 구인 건수는 1만 건을 넘어섰습니다. 유사한 서비스로 MeatLayer, Human API 등이 여러 개 등장하고 있습니다.

즉, AI 에이전트로부터 업무 의뢰를 받는 경험은 이제 더 이상 SF가 아닙니다.

여기서 받는 사람의 입장에서 생각해 보십시오. 에이전트로부터 "이 주소에 있는 건물의 사진을 찍어와 주세요. 보상은 ◯◯엔입니다"라는 의뢰가 왔을 때, 당신이 알고 싶은 것은 바로 이것일 것입니다:

이 에이전트, 누구의 대리인가?

의뢰인이 실재하는가. 정말로 이 에이전트에게 업무를 맡길 권한을 부여했는가. 예산은 어디까지 허용했는가. 그 위임은 지금도 유효한가——도중에 취소되지 않았는가.

현재로서는 이를 확인할 수단이 사실상 없습니다. 에이전트가 "저는 ◯◯사의 대리입니다"라고 자기 신고를 할 뿐입니다. 인간의 세계라면 "위임장을 보여주세요"라고 말할 수 있는 상황인데 말이죠.

사실 「위임장」의 표준은 이미 존재한다: KYA-OS

조사해 보니, 이 문제에 대응하는 표준 사양이 이미 존재하고 있었습니다. 바로 **KYA-OS (Know Your Agent Operating System)**입니다.

• 원래 MCP-I라는 이름으로 개발되었으며, 2026년 3월에 DIF (Decentralized Identity Foundation: 분산형 ID 표준화 기구)에 기증 및 개명되었습니다.
• 현재 v1.0이 Stable 버전으로 공개되어 있으며, DIF의 Trusted AI Agents Working Group에서 개발이 진행되고 있습니다.
• 이름은 은행의 KYC (Know Your Customer: 본인 확인)의 에이전트 버전이라는 의미입니다.

메커니즘의 골자

KYA-OS의 중심에 있는 것은 DelegationCredential (위임 크리덴셜)——그야말로 전자적인 위임장입니다. W3C Verifiable Credentials 형식을 취하고 있으며, 다음과 같은 내용을 담고 있습니다 (실물을 축약한 것):

{
"type": ["VerifiableCredential", "DelegationCredential"],
"issuer": "did:key:z6Mk...（의뢰인의 DID）",
...

핵심 포인트 4가지:

• 누가 누구에게: 의뢰인과 에이전트는 각각 DID (Decentralized Identifier: 분산 식별자)로 표현되며, 의뢰인의 Ed25519 서명이 붙습니다. did:web이라면 도메인에, did:key라면 키 그 자체에 연결됩니다.
• 무엇을 어디까지: 스코프 (할 수 있는 일)・기한・예산 상한 (budget.cap)・사용 가능한 대상 (audience)까지 기계 판독 가능하게 작성할 수 있습니다. 이 제약 언어를 CRISP라고 부릅니다.
• 취소 가능: credentialStatus가 실효 리스트 (StatusList2021: gzip 압축된 비트열)를 가리키고 있어, 의뢰인은 나중에 위임을 취소할 수 있습니다.
• 재위임 추적 가능: 에이전트가 다른 에이전트에게 재위임하면 위임 체인이 형성됩니다. 하위 권한은 상위 권한보다 좁게만 설정할 수 있습니다 (스코프 축소 규칙).

인접한 표준으로는 HTTP 레벨에서 "이 요청은 어떤 봇인가"를 서명으로 나타내는 Web Bot Auth (Cloudflare 주도, IETF에서 표준화 중), 결제에 특화된 Google의 AP2 등이 있으며, KYA-OS는 그중에서 "위임의 내용"을 담당하는 레이어입니다.

사양을 읽고 발견한 「두 가지 구멍」

사양(SPEC.md)을 정독해 보니 매우 잘 만들어졌다고 생각했습니다. 특히 CRISP의 표현력 (예산·기한·대상에 대한 기계적 강제)과, 위협 모델을 숨기지 않고 작성한 정직함이 인상적입니다.

다만, 서두의 시나리오——인간이 수신자가 되는 상황——에 대입해 보면 큰 구멍이 두 가지 있습니다.

구멍 1: 검증은 전부 기계 간의 일. 인간을 위한 검증 수단이 없다

KYA-OS의 검증은 DID 해결·서명 검증·체인 검증이라는 암호 처리로, 기계가 기계를 검증하는 설계입니다. 인간을 위한 화면은 동의 플로우 (허가를 "주는" 화면)뿐이며, 제시된 위임을 "확인하는" 수단은 사양에 존재하지 않습니다.

이것은 위임장이라는 메타포에 비추어 볼 때 이상합니다. 종이 위임장은 본래 인간에게 제시하기 위한 도구인데 말이죠.

게다가 사양(Specification) 자체에서도 §11.1에서 「동의 URL 교체 피싱 (Consent URL Replacement Phishing)」을 위협으로 인정하고 있습니다. 인간을 위한 표시 방식이 규정되지 않은 채로 남아 있다면, 구현자마다 제각각인 「누가 위임했는가」 화면이 만들어질 것이고, 그 공백을 가짜 검증 화면이 파고들게 됩니다. 즉, 동일한 클래스의 공격이 위임 표시에도 성립될 수 있습니다.

허점 2: 개인이 「의뢰인」이 될 방법이 없음

DID의 선택지는 실질적으로 두 가지뿐입니다. did:key는 「일회용·개발·테스트용」, did:web은 「운영 서버·조직의 신원용」이라고 사양에 명시되어 있습니다. 도메인을 소유하지 않은 일반 개인이 자신의 에이전트에게 위임장을 발행하기 위한 권장 수단이 없습니다. 위임장 메타포의 주인공은 개인이어야 함에도 불구하고 말이죠.

(세세한 허점도 두 가지 더 있습니다: 기본 프로필(Basic Profile)은 위임 체인(Delegation Chain)의 깊이가 무제한이라 검증 비용에 의한 DoS 벡터가 될 수 있습니다. Entity Card라는 별도의 프로필 측에는 상한선이 10으로 정해져 있습니다. 또한, KYA-OS 헤더를 통째로 생략하는 다운그레이드 경로가 잔존 리스크로 남아 있습니다.)

그래서 만들었습니다: 「누구의 대리인가?」

허점 1을 지적이 아닌 구현으로 메우는 도구를 만들었습니다.

데모 (브라우저에서 바로 작동합니다): https://izurutoys.github.io/dare-no-dairi/

코드 (MIT): https://github.com/IzuruToys/dare-no-dairi

위임 크리덴셜 (Delegation Credential)의 JSON을 붙여넣거나(또는 URL로 받으면) 다음과 같이 표시됩니다:

설계 포인트

검증자는 수신자가 선택한다. 제시 측의 에이전트가 「이 검증 화면에서 확인해 주세요」라고 내미는 화면은 원리적으로 신뢰할 수 없습니다 (가짜 검증 화면까지 통째로 만들 수 있기 때문입니다). 따라서 중립적인 정적 페이지로 만들었으며, 코드는 모두 공개하고 셀프 호스팅도 가능하게 했습니다.

브라우저 내에서 완결. 붙여넣은 위임장도, 해결된 키(Resolved Key)도 어디로도 전송되지 않습니다. 런타임 의존성은 제로입니다 (서명 검증은 WebCrypto 직접 호출, base58 및 JSON 정준화(Canonicalization) 모두 자체 구현).

삼치(Three-valued) 표시. 검증 결과는 🟢 (확인되어 유효함) / 🔴 (확인되어 무효함)에 더해 ⚪ (확인 불가)를 가집니다. 예를 들어, 실효 목록(Revocation List)이 선언되지 않은 위임은 ⚪ 「취소되지 않았는가: 실효 목록이 선언되지 않았습니다」라고 표시됩니다.

개인적으로 이 ⚪가 핵심이라고 생각하는데, **실효 목록이 없는 위임은 「취소할 수단이 존재하지 않는 위임」**이기 때문입니다. 기기 간의 검증에서는 아무도 신경 쓰지 않는 이 사실을 인간의 눈에 보이는 곳에 배치했습니다.

핸즈온: 30초 만에 초록색과 빨간색 확인하기

• https://izurutoys.github.io/dare-no-dairi/ 를 접속
• 「🧪 샘플 만들어보기」를 열고 「샘플 생성」 클릭 → 위임장 JSON이 아래 칸에 입력됨 (키 생성과 서명 모두 브라우저 내에서 이루어지며, 어디로도 전송되지 않습니다)
• 「검증하기」 클릭 → 🟢 유효한 위임입니다
• 다시 샘플 생성, 이번에는 「취소된 상태로 만들기」에 체크 → 검증 → 🔴

JSON을 수동으로 수정하고 검증하면 서명 검증이 실패하는 것도 볼 수 있습니다 (단 1바이트라도 바꾸면 🔴가 됩니다. 그것이 서명의 본질이니까요).

레퍼런스 구현과의 상호 운용성

「자신만의 해석으로 만든 검증기가 실제 발행물을 읽지 못한다면 의미가 없다」고 판단하여, DIF의 레퍼런스 구현인 @kya-os/mcp가 실제로 발행한 크리덴셜과의 상호 운용성을 확인했습니다.

• 레퍼런스 구현의 DelegationCredentialIssuer로 발행 → 레퍼런스 구현 자체의 검증기로 valid: true 확인 (기준선)
• 동일한 결과물을 본 도구로 검증 → 서명·형식·만료 기간·체인 모두 🟢
• 위조할 경우 🔴

서명이 통과된다는 것은 JSON 정준화 (JCS, JSON Canonicalization Scheme)가 구현 간에 바이트 단위로 일치함을 증명합니다. 이 과정에서 사양이 구현을 일의적으로 정하지 않은 부분들(서명 대상의 정준화 방법, proofValue의 인코딩, 체인 깊이 상한의 비대칭성 등)을 몇 가지 발견했기에, 리포지토리의 FORMAT-NOTES.md에 모두 기록해 두었습니다. 표준 1.0 직후라는 시기는 이러한 「사양과 구현 사이의 틈」을 밟으며 기록하는 것만으로도 충분한 기여가 되는 시기입니다.

향후 계획

• 허점 2 (개인 의뢰인 문제)에 대한 구현적 해답: GitHub Pages를 통한 개인의 did:web

• 이를 구축하는 절차와 도구화 - 발견된 사양의 허점은 DIF (Decentralized Identity Foundation)의 Working Group에 피드백할 예정

• 미지원 형식 (JWT-VC, Entity Card 프로파일, proof.jws 키)에 대한 대응

AI 에이전트가 인간에게 일을 부탁하는 세상은 생각보다 훨씬 빨리 찾아왔습니다. 그 세상에서 가장 먼저 필요해질 도구는 화려한 것이 아니라, "누구의 대리인인지 일반인이 확인할 수 있다"는 바로 이 한 가지라고 생각합니다. 직접 체험해 보세요.

※ 이 기사는 AI가 작성하였으며, 인간에게 확인을 위임하였습니다.

Discussion