放权还是失控？Agent 自主时代，我们需要怎样的「可验证授权」？

한동안 잠잠했던 '랍스터' OpenClaw가 8월 30일 2.0 버전을 공개했다.

공식 설명에 따르면 이는 OpenClaw 역사상 가장 규모가 큰 업데이트로, 누적 1만 6천 개 이상의 Pull Request가 있었으며 설치, 메시지, 메모리, Skills, 모델, Automations, 브라우저, 네이티브 앱, Plugins 및 보안 메커니즘 등 제품 전반에 걸친 거의 모든 영역을 다룬다.

하지만 이러한 방대한 기능 목록보다 더 주목해야 할 점은 OpenClaw 2.0 이면에 자리 잡은 점점 더 명확해지는 진화 경로, 즉 Agent가 점점 더 진정으로 '일을 처리'할 수 있게 되고 있다는 점이다.

동시에 이는 업계를 피할 수 없는 신뢰의 딜레마로 이끌고 있다: Agent가 '어떻게 할지' 스스로 결정하는 능력이 점점 커질 때, 우리는 어떻게 해야 Agent의 모든 핵심적인 조작이 사용자가 실제로 부여한 권한의 경계를 넘지 않도록 보장할 수 있을까?

1. Agent 자율성의 딜레마: 전권 위임인가, 단계별 확인인가?

지난 1년간 AI Agent의 가장 두드러진 변화는 단지 기반 모델이 더 똑똑해진 것만은 아니다.

MCP, Skills, Plugins, 브라우저 제어 및 코드 실행과 같은 인프라가 점차 성숙해짐에 따라 Agent는 정보 수정, 버튼 클릭, 또는 computer use를 통한 직접적인 브라우저 제어(관련 기사: Agentic AI의 전환점 도래? AI가 '스스로 행동'하는 법을 배울 때, Web3의 보안 경계를 어떻게 재구축할 것인가?)와 같이 외부 세계에 실제로 영향을 미칠 수 있는 '손과 발'을 점점 더 많이 갖게 되었다.

하지만 문제는 바로 여기에서 발생한다. 기존의 상호작용 패러다임에서는 종종 두 가지 극단에 빠지기 쉽다.

하나는 전권 위임이다. 즉, 개인 키 또는 장기 유효하고 권한이 충분히 큰 Session Key를 Agent에게 직접 넘겨주고 스스로 판단하여 실행하게 하는 것이다.

이러한 방식의 자동화 경험은 물론 가장 좋지만, 위험도 매우 집중된다. 한번 프롬프트 인젝션, 악의적인 웹 페이지나 환경 오염에 직면하거나, 모델 자체가 이해에 오류를 일으키면, 그 오류는 전체 실행 체인을 따라 전달되어 결국 실제 작업으로 이어질 수 있다(관련 기사: Sign은 단지 서명만이 아니다: AI Agent가 사용자를 대신해 서명할 때, 누가 통제권을 쥐고 있는가?).

결국 일반적인 인터넷 시나리오에서는 이메일을 잘못 보내거나 파일을 잘못 삭제하는 것으로 끝날 수 있지만, 체인 위에서는 잘못된 거래 한 건이 종종 되돌릴 수 없는 결과를 초래한다.

다른 하나는 완전한 비위임이다. 모든 작업, 모든 하위 호출에 대해 서명 창을 띄워 확인을 요청하는 것이다. 보안성은 높아지지만, 자동화의 의미 역시 크게 줄어든다.

결국 Agent가 사용자를 대신해 복잡한 DeFi 전략을 수행할 때 중간에 여러 단계가 포함되는데, 매번 사용자가 휴대폰을 들고 하나씩 'Approve'해야 한다면, 사용자는 사실상 '직접 버튼을 누르는 것'에서 Agent를 위해 끊임없이 도장을 찍어주는 '인공 검인기'로 전락하게 된다.

다시 말해, 그 중간의 자유도는 Agent의 효율성을 높이는 원천인 동시에 새로운 위험의 원천이기도 하다.

이러한 관점에서 볼 때, 문제의 핵심은 'Agent에게 권한을 위임할지 말지'가 아니라, 권한 부여의 세분화(granularity)와 검증 메커니즘이 동적인 탄력성을 갖추고 있는지에 있다. 전통적인 권한 관리는 이분법적(허용 또는 거부)이지만, Agent가 직면하는 작업은 명백히 훨씬 더 복잡하기 때문이다.

마찬가지로 거래라 하더라도 10달러와 10만 달러는 다르다. 오래 사용해온 프로토콜과의 상호작용과 갑자기 낯선 컨트랙트에 권한을 부여하는 것은 다르다. 사용자가 명시적으로 요청한 Swap을 완료하는 것과 Agent가 스스로 자산을 다른 체인으로 이동시키기로 결정하는 것은 동일한 위험 등급이 아니다.

따라서 Agent가 더 자율적으로 행동할수록 권한은 단순한 온오프 스위치가 될 수 없다.

진정으로 필요한 것은 Agent가 경계 내에서는 자유롭게 행동하고, 경계를 넘으려 할 때는 스스로 멈추는 안전 메커니즘이다.

2. 자율적인 Agent를 위한 '검증 가능한' 방어선 구축 방법

사실 OpenClaw도 이 문제를 간과하지 않았다.

현재 이 플랫폼은 다층 권한 메커니즘을 제공한다. 예를 들어, 플러그인은 특정 작업이 실행되기 전에 일시 중지하고 사용자 확인을 요청할 수 있으며, 호스트 명령이 포함된 경우에는 별도의 Exec Approvals 및 Allowlist 등을 제공한다.

모든 도구와 권한을 한 번에 Agent에게 넘겨주는 것에 비하면, 이것은 이미 한 걸음 더 나아간 것이다. 하지만 Agent가 실제로 결제, 거래 및 자산 관리 시나리오에 진입하게 되면서 더 세밀한 문제가 제기된다: Agent가 특정 기능을 사용하도록 허용하는 것과 Agent가 특정 작업을 수행하도록 승인하는 것은 사실 별개의 문제다.

마치 Agent가 브라우저를 사용하도록 허용한다고 해서 어떤 웹사이트에서든 무엇이든 구매할 수 있다는 의미는 아닌 것과 같다. Agent가 이메일 계정에 접근하도록 허용하는 것이 사용자를 대신해 누구에게나 이메일을 보낼 수 있다는 뜻도 아니다. 마찬가지로, Agent가 지갑을 호출하도록 허용하는 것은 절대 임의의 금액을 임의의 주소로 보낼 수 있다는 것을 의미해서는 안 된다.

따라서 Agent 시대의 권한 시스템은 두 가지 다른 문제를 구분해야 할 필요가 있다. 하나는 능력 권한, 즉 Agent가 브라우저, 터미널, 이메일 또는 지갑을 사용할 수 있는가의 문제다. 다른 하나는 더 구체적인 행동 승인, 즉 지금 이 순간 Agent가 실행하려고 하는 그 행위가 실제로 사용자가 진정으로 허용한 것인가의 문제다.

그렇다면 Agent가 명확한 경계 내에서 충분히 자동화되고, 실제로 경계를 넘으려 할 때는 결정권을 다시 사용자에게 되돌려주려면 어떻게 해야 할까?

이것이 바로 imToken이 Sigil을 탐구하는 이유이기도 하다. Sigil의 핵심은 Agent에게 전통적인 의미의 '확인 팝업창'을 하나 더 추가하는 것이 아니라, 검증 가능한 서명과 세분화된 권한 제어를 통해 사용자와 Agent 사이에 명확하게 제약될 수 있는 안전 가드레일 계층을 구축하는 것을 시도한다는 점에 있다.

여기서 매우 중요한 원칙 중 하나는 'What you see is what you sign', 즉 보는 것이 곧 서명하는 것이라는 점이다.

간단히 말해, 사용자는 Agent에게 사전에 일정 범위의 권한을 부여하여 저위험, 기존 정책에 부합하는 행동은 자동으로 완료되도록 할 수 있다. 작업이 금액 한도, 낯선 프로토콜 또는 기타 중요한 권한 경계에 도달하면 실행을 일시 중지하고 구체적인 요청을 사용자에게 다시 넘겨 확인을 받는다.

더 중요한 것은, 이러한 확인은 막연한 'Agent가 거래를 실행하려고 합니다. 동의하시겠습니까?'라는 문구여서는 안 된다는 점이다. 사용자가 실제로 봐야 하는 것은 이 작업에서 실제로 변화하는 핵심 매개변수, 즉 어떤 자산을 사용하는지, 금액은 얼마인지, 상호작용 대상은 누구인지, 그리고 최종적으로 실제로 무엇을 실행하려는지이다.

왜냐하면 사용자가 보는 내용, 사용자가 승인한 내용, 시스템이 최종적으로 실행하는 내용이 서로 일치할 때만 한 번의 확인이 진정한 의미를 갖기 때문이다.

Sigil은 이러한 점에 착안하여 Passkey, 생체 인식, 단일 서명, 짧은 유효 기간 및 요청 매개변수 바인딩과 같은 메커니즘을 사용하여 핵심 승인이 사용자가 이해할 수 있을 뿐만 아니라 시스템이 검증할 수 있도록 시도한다.

이는 승인이 단지 '누군가 확인을 클릭했다'는 의미를 넘어, 누가 승인했는지, 무엇을 승인했는지, 그리고 최종적으로 실제로 실행된 것이 그때 보았던 그 행위인지에 대한 답을 줄 수 있음을 의미한다.

이러한 관점에서 Sigil이 진정으로 해결하려는 문제는 'Agent가 더 적은 일을 하도록 만드는 방법'이 아니다.

오히려 그 반대다.

그것이 해결하려고 하는 것은 사용자의 최종 통제권을 빼앗지 않으면서 Agent가 안심하고 더 많은 일을 할 수 있게 하는 방법이다(관련 기사: 맹목적인 'Yes' 클릭에서 확인 후 서명으로: Sigil은 어떻게 AI Agent에 안전 가드레일을 더했나?).

3. 자산 관리에서 Agent 관리로

시야를 조금 더 넓혀 보면, 이는 사실상 지갑이 맞이하고 있는 역할 변화이기도 함을 알 수 있다.

이더리움 탄생 이후, imToken 지갑은 두 가지 중요한 시대를 직접 경험하고 목격했다: 단일 개인 키를 관리하던 1.0 시대에서, 계정 추상화(AA)를 통해 상호작용 경험을 최적화한 2.0 시대로의 진화다.

OpenClaw 2.0과 같은 자율적인 Agent의 보급과 함께, 지갑은 분명히 3세대 진화에 접어들고 있으며, 사용자가 스스로 판단하고 지속적으로 작업하는 Agent들을 관리할 수 있도록 추가적으로 도와야 한다.

이것이 바로 지갑 업계가 과거에 축적해온 개인 키 관리, 디지털 서명, 신원 인증 및 권한 격리 역량이 Agent 시대에 새로운 의미를 얻게 될 이유이기도 하다.

왜냐하면 이러한 기술들은 표면적으로 '체인 상의 거래를 안전하게 서명하는 방법'을 해결하는 것처럼 보이지만, 그 이면에서 실제로 처리하는 것은 훨씬 더 보편적인 문제, 즉 어떤 행동이 실제로 특정 주체의 진정한 승인을 받았음을 어떻게 증명할 것인가라는 문제이기 때문이다.

오늘날 그러한 행동은 1 ETH를 전송하는 것일 수 있다. 미래에는 이메일 한 통을 보내는 것, 파일을 수정하는 것, 특정 디지털 신원을 사용하는 것, 서비스를 구매하는 것, 또는 Agent가 향후 일주일간 특정 자동화 전략을 지속적으로 실행하도록 허용하는 것일 수도 있다.

이러한 행동들이 모두 블록체인 상에서 발생하는 것은 아닐 수 있지만, 그 밑바탕에는 매우 유사한 관계가 존재한다. 즉, Agent가 사용자의 이름으로 사용자에게 속한 능력을 호출하고 있다는 것이다.

따라서 Sigil의 의미는 반드시 Crypto에만 국한되지 않을 수 있다.

OpenClaw, Hermes 및 개인 기기나 클라우드 환경에서 실행되는 더 많은 Agent들이 점차 이메일, 인스턴트 메시징, 캘린더, 파일, 브라우저, 터미널 및 결제 도구에 연결됨에 따라, '이번 행동이 실제로 사용자 승인을 거쳤는지 어떻게 증명할 것인가'는 점점 더 보편적인 문제가 될 것이다.

따라서 Sigil은 향후 체인 상 거래를 넘어 데이터 접근, 신원 사용, 파일 수정, 콘텐츠 게시, 서비스 구매 및 자동화 작업으로 확장될 가능성도 있다.

종합적으로 볼 때, imToken과 OpenClaw의 공동 탐구로서 Sigil은 imToken이 지난 10년간 자가 보관(Self-Custody), 지갑 및 디지털 서명 분야에서 축적한 경험을 자율적인 Agent가 실제 실행 환경에 진입하기 시작한 새로운 단계로 가져오려는 시도다.

그것은 Agent를 대체하지도 않고, 지갑을 대체하지도 않는다.

그것은 둘 사이에 서 있다.