에스토니아는 AI 에이전트에게 공식 디지털 신원, 즉 "AI ID 코드"를 발급하려 한다. 크리스텐 미할(Kristen Michal) 총리실은 그 목표가 AI로 하여금 "명확하게 정의된 한계 안에서, 검증 가능하고 감사 가능한 방식으로 사람, 기업 또는 조직을 대신하여 행동"하게 하는 것이라고 밝혔다. 만약 실제로 출시된다면 에스토니아는 AI 에이전트에게 국가가 인정하는 신원을 부여하는 최초의 국가가 된다. 이는 진정으로 유용한 조치이며, 동시에 쉬운 부분이기도 하다. 어려운 부분은 그 ID가 담아야 할 모든 것이다.

나는 실제 자격 증명을 보유한 에이전트를 다루며 시스템을 만든다. 그래서 내 반응은 "이게 디스토피아인가"보다는 "그 ID가 실제로 무엇을 묶어야 하는가"에 가깝다. 식별자 그 자체는 숫자에 불과하다. 그것을 의미 있게 만드는 것은 거기에 붙이는 것이다. 권한, 위임 체인, 그리고 책임. 이를 잘못 다루면 매우 공식적으로 보이는 기본 키(primary key)를 출시한 셈이 된다.

에스토니아가 실제로 발표한 것

이 계획은 각 에이전트에게 식별자를 부여하는 것인데, 그 목적은 두 가지다. 식별, 그리고 에이전트가 할 수 있는 일의 범위를 제한하는 것이다. 미할 총리실의 표현이 정확하다. "누가 누구를 대신하여 어떤 권리로 행동하는지, 그리고 누가 궁극적으로 책임을 지는지가 명확해야 한다." Jumio의 디지털 신원 책임자 필립 포인트너(Philipp Pointner)는 이를 "에이전트가 개인을 대신하여 할 수 있는 일을 우리가 어떻게 감사해야 하는가"에 대한 선례라고 불렀으며, 이제 신원 시스템은 인간의 신원과 에이전트의 권한을 구별해야 한다고 강조했다.

바로 그 구별이 핵심 전부다. 인간의 신원은 "당신은 누구인가"에 답한다. 에이전트 ID는 더 어려운 질문에 답해야 한다. "누가 너에게 허락했고, 무엇을 하라고 했으며, 얼마나 오래 하라고 했는가."

이것이 단순한 행정 절차가 아닌 이유

LLM을 도구에 연결해 본 적이 있다면, 현재 기술 수준이 빌려온 자격 증명이라는 것을 이미 알고 있을 것이다. 에이전트는 service account로 실행되거나, 더 나쁘게는 사람의 OAuth token과 환경 변수에 복사해 둔 장기 유효 API key로 실행된다. 인간 중심의 IAM은 가끔 로그인하고, 동의 화면을 클릭하고, 인간의 속도로 행동하는 사람을 중심으로 만들어졌다. 에이전트는 결코 로그인하지 않고, 자신의 접근 권한을 다른 누군가로부터 건네받았으며, 분당 수천 번씩 행동한다.

그래서 에이전트가 무언가를 잘못하면, 로그는 service account가 했다고 말하거나 사람이 했다고 말한다. 요청에 실린 token이 그 주체의 것이기 때문이다. 행동은 실재하지만 책임 소재는 허구다. 에이전트에게 자신만의 신원을 주어 그 행동이 에이전트 자신에게 귀속되고 권한을 부여한 주체까지 추적되게 한다는 에스토니아의 직관은, 바로 메워야 할 그 간극이다. 직관은 옳다. 비용이 드는 곳은 구현이다.

에이전트 ID가 담아야 할 세 가지

1. 단순한 이름이 아니라 범위가 정해진 권한

"이것은 에이전트 X다"라는 사실만 증명하고 그 이상은 없는 ID는 이름표일 뿐이다. 가치는 거기에 묶인 권한에 있다. 어떤 시스템, 어떤 작업, 어떤 데이터를, 어떤 조건에서, 어떤 지출 또는 속도 한도로 할 수 있는가. 이것이 보도 자료가 "명확하게 정의된 한계"라고 손짓하는 부분이며, 제대로 만드는 데 몇 년이 걸리는 부분이다. 범위가 너무 넓으면 원래의 문제를 되살리고, 너무 좁으면 에이전트를 쓸모없게 만들기 때문이다. 우리는 이미 이를 위한 기본 요소들을 갖고 있다. OAuth scope, workload identity, capability token. 하지만 국가 차원의 ID 계층은 이들과 상호 운용되어야 하며, 네 번째로 경쟁하는 진실의 원천으로 그 위에 군림해서는 안 된다.

2. 실제로 따라갈 수 있는 위임 체인

"누가 누구를 대신하여 행동하는가"는 한 단계로 끝나지 않는다. 사람이 에이전트에게 권한을 부여하고, 에이전트가 도구를 호출하며, 도구가 하위 에이전트를 생성하고, 하위 에이전트가 제3자 API를 호출한다. 각 단계는 권한을 좁히거나 좁혀야 한다. ID가 이 체인을 포착하지 못하면, 고전적인 confused-deputy problem을 기계의 속도로 겪게 된다. 정당한 접근 권한을 가진 구성 요소가 다른 누군가의 목적을 위해 그 권한을 쓰도록 속아 넘어가고, 감사 로그에는 깨끗하고 정당한 호출로 남는다. 에이전트 ID는 최종 행위자만이 아니라 그 체인을 기록하고 제약하는 능력만큼만 쓸모가 있다.

3. 사람에게 도달하는 책임

여기가 기술로는 해결할 수 없는 부분이다. 에이전트에게 ID, 지갑, 그리고 권한 범위를 줄 수는 있다. 하지만 에이전트가 계좌를 비우거나 잘못된 계약에 서명할 때, 책임은 에이전트에서 멈추지 않는다. 책임은 사람이나 조직으로 거슬러 올라간다. ID는 그 역추적을 가능하게 하는 메커니즘이며, 이는 좋은 일이다. 그러나 ID가 누가 책임을 지는지를 결정하지는 않는다. 권한을 위임한 본인인지, 에이전트를 만든 개발자인지, 모델을 출시한 공급업체인지. 에스토니아는 이 질문을 일찍부터 공개적으로 끌어냄으로써 책임 있는 일을 하고 있다. 아직 누구도 깔끔한 답을 갖고 있지 않다.

신원은 필요하지만 충분하지 않다

관련 보도에서 인용된 최근 BCG의 한 문장이 더 깊은 쟁점을 짚는다. "가치는 규칙이 아니다. 가치는 수천 번의 인간적 결정을 통해 형성되고, 맥락과 예외와 선례에 의해 빚어진 믿음이자 원칙이다." ID 코드는 규칙을 인코딩할 수 있다. 판단은 인코딩할 수 없다. 완벽하고, 범위가 온전히 정해지고, 온전히 감사되는 신원을 가진 에이전트라도 기술적으로는 허용되지만 명백히 잘못된 행동을 여전히 할 수 있다. 신원은 귀속과 취소를 가능하게 한다. 신원이 좋은 행동을 보장하지는 않는다. 이 둘은 서로 다른 문제이며, 이를 뒤섞는 것이 바로, 멋진 배지를 달았다는 이유만으로 설계가 보장하는 것 이상으로 에이전트를 신뢰하게 되는 길이다.

에이전트로 시스템을 만든다면 이것이 의미하는 바

이 사고방식을 적용하기 위해 정부 등록부를 기다릴 필요는 없다. 에스토니아의 계획은 당신이 이미 내리고 있어야 할 선택들의 국가 규모 버전일 뿐이다.

  • 모든 에이전트에게 각자의 신원을 부여하라. 공유 service account가 아니라, 사람의 token이 아니라. 에이전트마다 하나의 주체(principal)를 두어, 그 행동이 오직 그 에이전트에게만 귀속되게 하라.
  • 작업에 맞게 범위를 정하고, 만료시켜라. 단기 유효하고 범위가 좁은 자격 증명은 언제나 장기 유효 key를 이긴다. 읽기만 하면 되는 에이전트는 쓰기가 가능한 token을 결코 보유해서는 안 된다.
  • 호출만이 아니라 위임 체인을 기록하라. 누가 어떤 범위로 에이전트에게 권한을 부여했는지 기록하라. 그래야 "누가 누구를 대신하여 행동하는가"가 포렌식 발굴이 아니라 질의(query)가 된다.
  • 취소를 즉각적으로 만들어라. 에이전트가 오작동할 때 가장 먼저 원하는 것은 하루가 걸리는 key 교체가 아니라 몇 초 만에 작동하는 차단 스위치다.
  • 의도적으로 사람을 책임지게 하라. 배포 전에, 누가 에이전트의 행동을 책임지는지 결정하라. 사고가 터진 도중에 조직도가 그 답을 찾아내게 두지 마라.

기계의 속도로 작동하는 에이전트에게 책임이 내장되어야 한다는 점에서 에스토니아는 옳고, 그 출발점이 신원이라는 점에서도 옳다. 다만 난이도의 순서를 분명히 해 두라. ID를 발급하는 것은 발표다. 권한을 묶고, 위임을 추적하며, 누가 에이전트에 대해 답하는지를 결정하는 것이 진짜 작업이다. 그리고 그것은 도구를 쓰는 모델을 연결하는 작은 팀이든, 에이전트 경제 전체에 코드를 발급하는 국가든 똑같은 작업이다.

다음으로 읽어 보세요

에이전트를 안전하게 운영하는 인프라와 플랫폼 측면에 관해서는 클라우드 현장 노트가 ercan.cloud에 있다. AI, 신원, 플랫폼 작업에 관한 컨설팅 문의나 그냥 인사를 건네고 싶다면 ercanermis.com에서 시작하라.