5월 19일 베를린에서 개최된 European Identity and Cloud Conference 2026(EIC 2026)에서의 키노트 스피치 트랜스클립션의 일본어 번역을 아래에 게재합니다. 슬라이드는 문장에 PDF를 게재해 둡니다.
소프트웨어가 단순한 도구가 아닌 시대
여러분, 안녕하세요.
우리는 이제 소프트웨어가 단순한 도구가 아닌 시대에 들어가고 있습니다.
오랫동안 소프트웨어는 명령을 실행하는 것이 었습니다. 서식을 처리하고, 레코드를 이동하고, 계산하고, 워크플로우를 강제하고, 시스템과 시스템을 연결할 수 있었습니다.
그러나 이제 소프트웨어는 직원처럼 행동하기 시작했습니다.
인간 직원이 아닙니다. 법인도 아닙니다. 인간적인 의미에서 동료도 아닙니다.
직원처럼 행동하는 디지털 행위자입니다.
우리는 그들에게 임무와 임무를 주고, 권한을 부여하고, 도구를 제공합니다. 그리고 이들이 실사회에서 조정을 하고 의사결정을 하고 상층부에 보고하고 권한을 위양하며 성과를 창출할 것을 기대하고 있습니다.
소프트웨어를 거기까지 할 수 있게 되면 거버넌스 문제는 모습을 바꿉니다.
질문은 더 이상 "모델이 올바르게 대답 할 수 있습니까?"만이 아닙니다.
"애플리케이션은 안전하게 API를 호출할 수 있습니까?"뿐만 아니라.
묻는 것은 :
- 이 작업을 누가 승인했습니까?
- 누구의 의도가 반영되는가?
- 어떤 권한이 위임되었는가?
- 실행 과정에서 무엇이 변경되었는지?
- 누가 이것을 멈출 수 있습니까?
- 그리고 결과가 생겼을 때 누가 책임을 지는가?
- 것입니다.
소프트웨어 as 직원 및 정체성
검토할 때, 나는 먼저 간단한 명제로 시작하고 싶습니다 :
소프트웨어가 직원이 될 때 정체성은 거버넌스의 기둥이됩니다.
에이전틱 AI가 제기하는 것은 모델의 안전만의 문제가 아닙니다. 응용 프로그램 보안에만 문제가 없습니다. 그 중심에 있는 것은 위임된 권한 문제입니다.
권한 위임에는 항상 정체성, 소유권, 관리, 증거, 책임 및 신뢰와 같은 문제가 수반됩니다.
전통적인 응용 프로그램은 일반적으로 정의된 인터페이스 범위 내에서 작동했습니다. 어플리케이션은 지시를 받고, 함수를 실행해, 결과를 돌려줍니다.
그러나 에이전트는 다릅니다.
대리인은 대략적인 목표를 부여받고 그 달성 방법을 스스로 결정합니다. 도구를 선택하고, API를 호출하고, 하위 태스크를 작성하고, 다른 에이전트와 연동하고, 상황에 맞게 적응하고, 조직의 범위를 벗어나 행동할 수 있습니다.
그래서"디지털 직원"라는 말은 유용합니다.
물론 요원이 인간이기 때문이 아닙니다.
대략적인 목표를 주어져 그 달성 방법을 스스로 결정해 실행해 나간다는 것은, 종래 직원에게 기대해 온 것이기 때문입니다.
우리는 그들에게 일을 할당하고, 권한을 부여하고, 결과를 기대합니다. 그리고 결국 누군가가 그들의 행동에 대해 책임을 져야 합니다. 그들이 마치 부하인 것처럼.
이 패턴은 인간과 에이전트 사이에만 국한되지 않습니다. 상담원에서 상담원으로도 나타나기 시작했습니다. 의뢰를 받는 에이전트가 자신에게 무엇을 할 수 있는지, 어디에서 도달할 수 있는지, 어떤 스킬을 가지는지, 어떤 인증이 필요한지를 표명하고, 의뢰자 측은 그것을 보고 일을 의뢰한다——그런 패턴이 태어나고 있습니다.
이러한 의뢰처의 메타데이터를 발견하는 기능을 발견 기능이라고 합니다. 이 경우에도 검색 기능은 유용합니다.
그러나 메타데이터의 발신자가 관리 관할을 넘은 순간, 「그렇다고 신용할 수 있는 것」이라는 문제가 생기기 시작합니다.
그 요원이 말하는 것이 옳은지, 그 요원 뒤에 누가 있는지 말하는 것은 분명하지 않습니다.
혹시 테러지원 국가가 배후에 있을지도 모른다.
아니, 그 이전에, 어제 이야기를 한 에이전트와, 지금 접속하고 있는 에이전트는 동일 인물인가? 라는 문제가 나옵니다.
에이전트 아이덴티티의 연속성과 일관성
여기에서 첫 번째 난문으로 들어갑니다.
에이전트가 "같은 에이전트"라는 것은 무엇입니까?
인간의 직원이라면, 정체성에는 연속성·일관성(제일성)이 있습니다. 사람은 배우고, 역할을 바꾸고, 경험을 쌓아도, 책임이라는 관점에서는 같은 인물로 계속합니다.
그러나 AI 에이전트의 경우 연속성과 일관성은 그다지 분명하지 않습니다.
모델이 바뀌면 같은 에이전트입니까?
시스템 프롬프트가 변경되면 동일한 에이전트입니까?
메모리가 재설정, 통합 또는 공유되면 같은 에이전트입니까?
툴체인이 바뀌면. 공급자가 정책을 변경하면. 런타임이 바뀌면. 하위 에이전트가 교체되면. 임무가 한 실행자로부터 다른 실행자에게 이어지면——우리가 신뢰하고 있는 “그것”이란, 도대체 무엇일까요.
그리고 그 행위에 책임을 지는 "주인"은 누구입니까?
그래서 다음과 같은 의문이 떠오릅니다.
에이전트의 소유자, 실질적 지배자는 누구인가?
권한을 가지고 행동하는 모든 상담원은 책임있는 소유자가 필요합니다.
나는 이것을"얼티밋 봇 오너(UBO)"와 呼 ん で い ます.
UBO.
이 표현은 의도적입니다. 마네론 규제에서는 실질적 지배자라는 개념이 중요합니다. Ultimate Business Owner, UBO라고 합니다. 여기서 제가 말하는 UBO는 이 UBO에 걸고 있습니다. UBO가 중요한 것은, 어카운빌리티를 명목만의 법인으로 중단시키지 말아야 하기 때문입니다. 작업을 요청하기 전에 무엇이 무엇인지 파악해야 합니다.
그렇지 않으면 배포하는 전체 에이전트 네트워크가 허용되지 않는 위험에 노출됩니다. 이는 공급망의 위험을 억제하는 데 필요합니다.
사명
이 강연에서 소개하고 싶은 또 다른 측면은 "미션"입니다.
이것은 "프롬프트"와 다릅니다. "프롬프트"는 지시입니다.
세션과도 다릅니다. 세션이란에이전트가 작업을 계속할 수 있는 곳입니다.. 임무는 그것과 다릅니다.
임무는 어떤 목적을 달성하기 위해 사람과 그룹에게 주어진 관리된 위임입니다. 상담원이 계속 일할 수 있는 이유입니다. 여기에는 목표, 제약, 권한, 자원, 기간, 적용되는 정책, 증거 요건, 그리고 하나 이상의 주체가 행동하는 책임 책임의 틀이 포함된다.
임무, 상담원 및 세션은 서로 독립적인 개념이며 혼동해서는 안 됩니다. 임무는 에이전트보다 오래 지속될 수 있거나 에이전트가 종료되기 전에 종료될 수 있습니다. 임무가 끝나면 세션이 아직 진행 중이면 세션이 종료되는 것이 적절할 수 있습니다.
에이전트의 액션과 세션은 미션에 의해 제한됩니다. 상담원은 임무를 달성하기 위해서만 활동해야 합니다.
미션에는 명확한 범위가 정해져 있지 않은 경우, 검증 가능하지 않은 경우, 일시 정지가 가능하지 않은 경우, 그 임무에는 근거가 수반되어야 한다.
그렇지 않으면 에이전트 유형 시스템은 단순히 작업을 수행하는 데 그치지 않고 권한이 어디에서 왔는지에 대한 신뢰할 수있는 기록없이 권한을 이전합니다.
인간이 요원에게 임무를 준다.
에이전트는 위임된 실행 재량에서 작업을 형성하고 행동을 결정합니다.
대리인은 대부분의 경우 책임을 질 수 없기 때문에 승인을 얻기 위해 인간을 프로세스에 끌어들여야 합니다.
인간의 감독은 중요합니다.
영향이 큰 행동, 법적 조치, 규제 대상이 되는 결정, 자금의 송금, 대외적인 커뮤니케이션, 혹은 되돌릴 수 없는 정보공개 등에 있어서는 인간의 판단이 필수적인 경우가 있습니다.
규모 문제
하지만 이 모든 일을 하려고 한다면 우리는 규모의 문제에 직면하게 될 것입니다.
한 명의 작업자가 수십, 수백 명의 요원을 가질 수 있습니다. 하나의 조직이라면 수천.
인간은 모든 단계를 의미있는 형태로 승인 할 수 없습니다. 원래, 하나의 에이전트만을 상대로 해도, 1 태스크당 3번째로부터의 확인은 명목화해 버린다고 하는 논문도 나오고 있을 정도입니다.
이것이 1인당 100명의 대리인으로부터 차례차례로 승인을 요구받으면 타성에 의한 승인이 되지 않을 수 없을 것이다.
이 규모에서는 감독을 인간의 검토에만 맡길 수 없습니다. "휴먼 인 더 루프"는 반드시 의미있는 거버넌스는 아닙니다.
시간적 압박에 노출되고 불완전한 정보하에 이루어지는 승인 행위는 진정한 의미에서 의사 결정이 아닙니다. 이 상황을 평가하고 Claude Code가 말한 적이 있습니다.
그것은 인간의 판단을 가장한 "자동 처리"입니다.
우리는 AI 에이전트의 도움이 필요합니다. 프린시펄인 위임자 측에 서는 감독 에이전트입니다.
이 에이전트는 증거와 위험의 징후를 평가하고 불필요한 정보를 제거한 다음 필요에 따라 관련 정보를 위임자에게보고합니다. 그리고 그것은 원래 일을 위임한 사람이나 조직의 측면에 서 있어야 합니다. 태스크를 완수하려는 시스템이 아니라 위임자에게 충실해야 합니다.
실행 에이전트는 무언가를 실행하는 "의도"를 형성하고 런타임에 구조화된 보고서를 모니터링 에이전트에 전송해야 합니다. 예외. 변경. 결과.
Shared Signals 유형의 이벤트는 이 신경계의 일부가 될 수 있습니다. 하지만 그러한 구조화된 리포팅을 구현하기 위한 구체적인 표준이 있는가?
あ り ま せ ん.
그리고 신호는 킬 스위치가 아닙니다.
그것은 시그널링 레이어의 일부일 뿐입니다. 우리는 컨트롤 플레인도 필요합니다.
제어 플레인은 개입할 수 있어야 합니다. 임무를 일시 중지하고 권한을 좁히고 도구를 무효화하고 위임을 차단하고 자격 증명을 해지하고 메모리를 격리하고 사람에게 에스컬레이션하거나 임무 자체를 종료합니다.
이것들을 위한 표준 프로토콜이 있습니까? 없습니다.
Agentic AI 시스템은 분산 트랜잭션 시스템입니다.
에이전틱 시스템에는 또 다른 포착 방법이 있습니다.
그것은 분산 오브젝트 시스템과 분산 트랜잭션 시스템으로 캡처하는 방법입니다.
미션이 시작된다. 에이전트가 도구를 호출합니다. API를 부른다. 하위 에이전트에게 위임합니다. 상태를 다시 씁니다. 메시지를 보냅니다. 그리고 외부에 결과를 일으킬지도 모른다.
전통적인 분산 시스템에서 장기적인 트랜잭션 처리가 어렵다는 것은 널리 알려져 있습니다. Saga 모델은 장기적인 트랜잭션을 단일 단위로 실행하면서도 하위 트랜잭션으로 분할할 수 있는 것으로 간주합니다.
에이전틱 인공지능에도 같은 문제가 있습니다.
코디네이터는 부분적으로 비결정적일 수 있다. 실행자는 모델에 의존할 수 있다. 다음 단계는 컨텍스트에 따라 달라질 수 있습니다.
그러므로, 서브에이전트의 태스크도, 툴도, 스킬도, 모두 스스로의 귀결의 시멘틱스를 선언해야 합니다.
취소할 수 있을까. 보상할 수 있을까. 전진 복구할 수 있을까. 아니면 돌이킬 수 없는가.
사내용 초안을 보내는 것은 취소할 수 있습니다. 예약 취소는 보상할 수 있습니다. 워크플로 복구는 전진 복구할 수 있습니다. 그러나 기밀 데이터의 공개는 돌이킬 수 없습니다.
어떤 부분이 아직 되감을 수 있을지 모르는 채, 미션을 통치할 수 없습니다.
에이전틱 AI는 분산 트랜잭션을 분산 결정으로 바꿉니다.
그리고 그 판단은, 경계 붙이고, 관측할 수 있어, 끼어들 수 있는 것이 아니면 안됩니다.
에이전트 카드로 메타데이터 광고
이제 에이전트 카드에 스포트라이트가 닿습니다.
에이전트 카드는 에이전트 이름, 공급자, 엔드포인트, 능력, 기술, 인증 체계, 상호작용 요구 사항에 대한 자체 설명입니다. 그리고 언젠가 되감을 수 있을지 등 트랜잭션 특성까지 표현할 수 있게 될지도 모릅니다.
이들은 탐지, 기능 선언, 엔드포인트 탐지 및 프로토콜 선택에 중요합니다. 그러나 그들이 무엇을 해결하고 무엇을 해결하지 않는지에 대해서는 정확하게 파악해야합니다.
에이전트 카드는 에이전트가 무엇을 할 수 있다고 주장하는지 알려줄 수 있습니다. 그러나 그 자체는 그 요원이
- 이 임무에 합당하다는 것을 증명하지 않습니다.
- 런타임이 신뢰할 수 있음을 증명하지 않습니다.
- 모델, 프롬프트, 메모리 및 정책 버전도 증명하지 않습니다.
- Ultimate-Bot-Owner도 증명하지 않습니다. 그리고,
- 릴레이 파티가이 거래에서이 에이전트를 신뢰할 수 있다는 것을 증명하지 않습니다.
자기 선언의 에이전트 카드는 거버넌스 측면에서 불충분합니다.
서명이 있는 Agent Card조차 한 걸음 앞으로 나아가기만 하면 됩니다. 서명이 가르쳐주는 것은 한 열쇠가 무언가에 서명했다는 것뿐입니다.
검증자는 서명자, 키, 발행자, 트러스트 프레임워크를 이 목적으로 받아들일 수 있는지 결정해야 한다.
- 식별은 신뢰가 아니다.
- 발견은 권한이 아니다.
- 메타데이터는 어카운터빌리티를 대체하지 않는다.
SPIFFE/SPIRE 패턴
이러한 것을 생각할 때, SPIFFE와 SPIRE의 패턴은 참고가 됩니다.
SPIFFE 및 SPIRE는 에이전트 거버넌스의 표준 표준이 아닙니다. 그러나 이것들은 우리가 배워야 할 패턴을 보여줍니다.
워크로드는 단순히 자신이 누구인지 선언하지 말아야 합니다. 인증을 거친 후 신원을 부여해야 합니다.
그러나 Agentic AI의 경우 Workload Identity는 출발점에 불과합니다.
죽음은 "무슨 일이 일어나고 있는가?"라는 질문에 대한 대답이 될 수 있습니다.
하지만 죽음에서는 다음 질문에 대답 할 수 없습니다.
- 누구의 임무가 실행되고 있습니까?
- 어떤 권한이 위임되었는가?
- 어떤 모델이나 프롬프트가 사용되었는가?
- 어떤 정책이 적용되었는지?
- 그 액션에 대해 보상은 가능한가?
- 최종 수혜자(UBO)는 누구인가?
따라서 워크로드 증명 외에도 임무 증명, 권한 증거, 트랜잭션 의미론 및 모니터링 보고서가 필요합니다.
페더레이션을 통한 신뢰 프레임 워크 형성
여기서 「페더레이션」이 등장합니다.
에이전트 카드는 무엇이 주장되는지를 나타냅니다.
증명서는 무엇이 실행되고 있는지에 대한 정보를 제공합니다.
페더레이션은 어떤 주장과 감정을 신뢰해야 하는지를 결정하는 데 도움이 됩니다.
OpenID 페더레이션은 상호 연동하려는 엔티티가 "트러스트 앵커"라고 하는 신뢰할 수 있는 제1자를 통해 신뢰 관계를 설정하는 방법을 정의합니다. 이는 여러 계층의 권한을 지원하며 하나의 엔터티가 여러 페더레이션에 속할 수 있습니다. 또한 동적이고 분산된 신뢰 네트워크를 구축하기 위한 기술적 신뢰 인프라 구성 요소를 제공합니다.
페더레이션을 통해 서명 키가 우리가 승인하는 트러스트 프레임워크의 엔티티에 속하는지, 유효한 트러스트 체인이 존재하는지, 메타데이터 정책이 적용되는지, 트러스트 마크가 이 종속 당사자에게 의미 있는지 여부를 확인할 수 있습니다.
에이전트의 거버넌스에서 이것은 매우 중요합니다.
모든 당사자가 모든 에이전트, 공급자, 레지스트리, 증명서 발행자, UBO에 대해 하나씩 수동으로 수락할지 여부를 결정합니다. 그런 세상은 바람직하지 않습니다.
트러스트 체인과 메타데이터 정책이 필요합니다. 권한이 행사되기 전에 누구의 주장을 받아들이는지를 결정하는 구조가 필요합니다. 그 때문에 페더레이션의 구조는 매우 유용합니다.
표준 이용의 중요성
이러한 것을 실현하는데 유용한 컴퍼넌트는 벌써 다수 존재합니다. OpenID 관련의 사양군만으로도, 여기에 준 것 같은 것이 있습니다.
- OpenID Connect
- OpenID4VCI/VP
- AuthZEN
- OpenID Federation
- OpenID Shared Signals and Events Framework
- 등
대부분은 보안 관점에서 수학적으로 형식적으로 검증되었습니다.
물론 이들만으로는 충분하지 않습니다. 그러나 재사용할 수 있는 것은 재사용해야 하며, 정말로 필요한 것만을 구축해야 한다.
Liability 및 보험 수리적 과제
마지막으로, 거버넌스가 마지막으로 꽤 도착하는 질문을 올립니다.
손실을 지는 것은 누군가.
에이전트가 데이터를 유출하고, 지불을 오송하고, 워크플로우를 조작하고, 잘못된 지시를 보내거나, 유해한 체인을 야기할 때, 책임은 궁극적으로 어디에 진정할 것인가?
이 관점에서도 Ultimate-Bot-Owner는 중요합니다.
그리고 흔적이 중요해집니다. 흔적이 없으면 어카운터빌리티가 약해진다. 책임의 소재는 추측의 역을 나오지 않게 되어 보험은 해당 추량에 지나지 않게 됩니다.
현재, Agentic AI의 위험에 대한 보험 수리적 근거는 여전히 미숙한 단계에 있습니다. 그렇다고 기다리는 이유는 아닙니다. 이제 측정 인프라를 구축해야 합니다.
보험은 슬로건만으로 이루어지는 것은 아니다. 위험 노출, 발생 빈도, 피해 심각도, 관리 효능, 인과 관계 및 손해 데이터가 필요합니다.
소프트웨어는 직원이되고 있습니다.
이들에 대한 거버넌스가 필요해지고 있습니다.
활용할 수 있는 표준 규격은 존재합니다.
그러나 거버넌스가 효과적인 에이전트 인프라를 구축하는 것만으로는 충분하지 않습니다. 채워야 할 격차가 많이 있습니다.
Identerati 여러분, 신뢰할 수 있는 에이전트 에코시스템을 구축하는 여행은 아직 시작되었습니다.
모두가 힘을 합쳐 지금 만들기 시작합시다.