A fast answer and a coordinated one are not the same thing. When AI resolves a B2B customer issue without looping in the teams who have to deliver on it, you get confident responses nobody actually signed off on.

A new briefing paper from Harvard Business Review Analytic Services, sponsored by Front, examines the coordination gaps that open up when transactional AI tools meet multi-team B2B service, and how leading companies are using AI to close those gaps instead of widening them.

Read the briefing paper for the questions to ask before your next AI investment.

Read the Briefing Paper

메타(Meta)가 개인용 AI 에이전트 ‘Muse’를 내놨습니다. 출시 열흘 만에 미국 앱스토어 무료 앱 1위에 올랐다는 보도가 나올 만큼 초기 반응도 뜨겁습니다.

Muse가 관심을 끄는 이유는 ChatGPT나 Claude처럼 질문에 답하는 데서 멈추지 않기 때문입니다. 이메일을 보내고, 여행을 예약하고, 상품을 구매하고, 구독을 해지하는 등 온라인에서 사용자가 해야 할 일을 대신 끝내는 것을 목표로 합니다. 미국 온라인 매체 Axios는 Muse를 쇼핑과 가격 협상부터 일상의 디지털 잡무까지 대신 처리하는 에이전트라고 소개했습니다.

Muse를 실행하면 사용자마다 클라우드에 전용 컴퓨터 한 대가 생깁니다. Muse는 이 가상의 컴퓨터에서 브라우저를 열고, 이메일과 캘린더를 확인하고, 프로그램을 실행합니다. 필요한 도구가 없으면 스크립트나 커넥터를 직접 만들어 사용하고, 사용자가 앱을 닫은 뒤에도 맡은 일을 계속 처리합니다.

특히 눈길을 끄는 것은 ‘필요한 도구가 없으면 직접 만든다’는 대목입니다. 지금까지의 AI가 개발자가 미리 연결해 둔 도구 안에서 움직였다면, Muse는 작업 도중 빠진 기능을 발견했을 때 새로운 스크립트나 커넥터를 만들어 문제를 해결할 수 있습니다.

여기서 중요한 질문 하나가 떠오릅니다.

에이전트가 사용할 도구와 일하는 방법을 스스로 바꿀 수 있다면, 에이전트가 절대 손대지 못하게 해야 할 것은 무엇일까요?

Muse는 메타가 2026년 9월 공개한 개인용 AI 에이전트입니다. 현재 미국과 캐나다, 멕시코에서 제공되고 있고, 메타는 앞으로 다른 시장으로도 확대하겠다고 밝혔습니다. 한국 출시 일정은 아직 공개되지 않았습니다.

사용자가 달성하려는 목표를 말하면 Muse는 필요한 단계를 나누고 계획을 세웁니다. 웹사이트를 돌아다니고, 양식을 작성하고, 연결된 서비스에서 정보를 가져와 여러 단계의 작업을 처리합니다. 사용자의 판단이 필요하거나 문제가 생겼을 때만 돌아와 질문합니다.

오래 걸리는 일도 맡길 수 있습니다. 특정한 상품의 가격이 내려가는지 지켜보거나, 예약 가능한 자리가 생기는지 확인하고, 장기적인 목표가 계획대로 진행되는지 챙길 수 있습니다. 앱을 닫아도 작업은 클라우드에서 계속됩니다.

메타가 제시하는 Muse의 사용 범위는 상당히 넓습니다. 이메일 전송과 여행 예약 같은 일상적인 작업부터 자동차를 더 좋은 가격에 판매하기, 요금 낮추기, 새로운 사업 준비하기, 1년 동안 운동 계획 관리하기까지 포함됩니다.

여기까지 읽고 “이 정도는 이미 다른 AI로 할 수 있지 않았나?”라고 생각한 분도 많을 겁니다.

맞습니다. AI를 능숙하게 사용해온 사람들은 이미 ChatGPT나 Claude Cowork에 클라우드 브라우저와 커넥터, 코딩 에이전트와 자동화 도구를 연결해 이메일 정리, 일정 관리, 웹 조사, 예약과 구매, 반복 작업을 처리해왔습니다. Codex나 Claude Code, OpenClaw 같은 환경에 익숙한 사용자라면 필요한 도구를 직접 만들어 붙이는 방식도 낯설지 않습니다.

Muse가 처음 선보인 기능은 많지 않습니다. 대신 숙련 사용자가 여러 도구와 설정을 엮어 만들던 개인 에이전트 환경을 전용 클라우드 컴퓨터, 이메일·캘린더 연결, 지속적인 기억과 목표, 승인 화면과 활동 기록을 갖춘 하나의 소비자 제품으로 묶었습니다.

Muse가 가져온 변화는 능력의 갑작스러운 도약이라기보다 접근성의 변화에 가깝습니다. 일부 숙련 사용자의 실험적인 작업 방식이 일반 사용자도 앱이나 WhatsApp에서 바로 시작할 수 있는 제품이 됐습니다. 그렇기 때문에 Muse가 무엇을 할 수 있는지만큼, 그 권한을 어떻게 제한했는지가 중요합니다.

메타는 Muse를 공개한 지 약 2주 만에 전용 기기 ‘Muse Charm’도 선보였습니다. Muse Charm은 주머니에 넣거나 열쇠고리에 달 수 있는 작은 기기로, 스마트폰 잠금을 풀거나 앱을 열지 않고도 음성으로 Muse와 대화할 수 있는 전용 접점입니다.

Muse Charm은 새로운 AI 모델이라기보다 기존 Muse와 상호작용하는 방법을 하나 더 추가한 기기입니다. 메타는 연말 출하를 목표로 하고 있지만 디자인과 가격, 통신 방식과 배터리 같은 핵심 정보는 아직 확정해 공개하지 않았습니다.

메타는 Muse를 자사의 AI 안경에도 통합할 계획입니다. Muse가 AI 안경에 들어가면 대화 중 나온 내용을 장보기 목록에 추가하거나, 친구와 만날 시간을 찾아 캘린더에 넣고 초대장을 보내는 식의 작업을 음성으로 요청할 수 있습니다.

현재 제공되는 앱과 웹, WhatsApp에 AI 안경과 Muse Charm까지 더해지면 Muse는 하나의 앱이라기보다 여러 기기에서 사용자를 따라다니는 개인 에이전트 플랫폼에 가까워집니다.

이 움직임은 메타가 어디에서 Muse의 경쟁력을 찾고 있는지도 보여줍니다. 이메일을 읽고 웹사이트를 조작하고 백그라운드에서 작업하는 능력 자체는 다른 AI 도구에서도 찾아볼 수 있습니다. 하지만 메타는 이 기능을 자사의 메시징 서비스와 소셜 플랫폼, 웨어러블 기기와 전용 하드웨어에 걸쳐 빠르게 확산시킬 수 있습니다.

Humane AI Pin과 Rabbit R1이 새로운 하드웨어에서 출발했다면, 메타는 먼저 Muse를 앱과 WhatsApp에서 사용하게 한 뒤 같은 에이전트를 안경과 전용 기기로 확장하는 모양새입니다. 다만 Muse Charm이 스마트폰보다 편리한 고유한 쓰임새를 만들어낼 수 있을지는 아직 알 수 없습니다.

Muse와 접촉하는 시간과 일상적 맥락이 늘어날수록, 이미 부여한 권한을 얼마나 세밀하게 관리할지도 더 중요한 문제가 됩니다.

Muse의 사용 사례를 보면 개인용 에이전트가 일상에서 어떤 역할을 맡으려 하는지 조금 더 선명하게 드러납니다. 가족 일정과 받은편지함 정리, 저녁 모임 준비, 쇼핑처럼 우리가 자주 겪지만 직접 처리하기에는 번거로운 일들을 중심으로 살펴보겠습니다.

첫 번째 사례의 주인공인 클레어 보(Claire Vo)는 제품 기획 문서의 작성과 검토를 돕는 AI 서비스 ChatPRD의 창업자이자, 사람들이 실제 업무에서 AI를 어떻게 사용하는지 보여주는 팟캐스트 ‘How I AI’의 진행자입니다.

클레어는 주말 동안 Muse를 직접 사용하면서 가족 일정과 목표 관리, 쇼핑을 포함한 여러 작업을 시험했습니다. 그중 하나가 매일 아침 식탁에 올려둘 한 장짜리 가족 뉴스레터를 만드는 일이었습니다.

단순히 일정을 표로 정리해 달라는 요청은 아니었습니다. 일주일 동안의 가족 일정과 아이들의 활동, 부모가 기억해야 할 일, 샌프란시스코의 지역 행사, 날씨와 뉴스까지 한 장에 담아 온 가족이 함께 읽을 수 있는 PDF를 만들어 달라고 했습니다.

Muse는 연결된 이메일과 캘린더에서 가족 구성원과 주요 일정을 찾았습니다. 아이들이 주짓수와 농구, 피아노를 배우고 있다는 사실도 파악했습니다. 다만 찾아낸 정보를 곧바로 사용하지 않고, 앞으로 이런 정보를 활용해도 되는지 클레어에게 다시 물었습니다.

완성된 뉴스레터에는 가족 일정만 들어간 것이 아니었습니다. 주짓수 수업과 피아노 수업이 겹친다는 사실을 알려주고, 주말에 열리는 지역 행사를 추천했습니다. 아이들과 식탁에서 나눠볼 만한 질문도 덧붙였습니다.

일반적인 챗봇도 뉴스레터 문구를 쓸 수 있습니다. 그러나 이 경우 사용자가 이메일과 캘린더를 직접 뒤져 필요한 내용을 복사해줘야 할 때가 많습니다. Muse는 정보를 찾고, 일정 충돌을 발견하고, 결과물을 PDF로 완성하는 데까지 작업을 이어갔습니다.

AI가 만든 결과가 화면 안에 머물지 않고 가족이 하루를 시작하며 함께 읽는 작은 신문이 된 셈입니다.

두 번째 사례는 생성형 AI 제품을 꾸준히 취재해온 TechRadar의 기술 전문 기고자 에릭 할 슈워츠(Eric Hal Schwartz)의 경험입니다.

에릭은 Muse에게 받은편지함을 살펴보게 했습니다. Muse는 아직 에릭이 열어보지 않은 전력회사의 이메일에서 태양광 패널 점검을 위해 방문 날짜를 정해 달라는 요청을 발견했습니다.

Muse는 에릭이 시간을 낼 수 있는 날짜를 추려 선택해 달라고 했습니다. 날짜가 정해지자 전력회사에 보낼 답장을 작성하고 승인을 기다렸습니다. 에릭이 답장을 승인하자 받은편지함 한구석에 남아 있던 일 하나가 끝났습니다.

사소해 보이지만 기존 챗봇과는 경험이 다릅니다. 사용자가 이메일을 찾아 내용을 복사하고, 챗봇에게 답장을 부탁한 다음, 다시 메일 앱으로 돌아가 붙여넣을 필요가 없습니다. Muse가 먼저 맥락을 찾고, 꼭 필요한 선택만 사용자에게 물었습니다.

에릭은 이 경험을 편리하면서도 불편했다고 평가했습니다. 답장을 만드는 몇 분을 아낀 것은 좋았지만, 그 편의를 얻기 위해 메타의 에이전트에게 자신의 받은편지함을 보여줘야 했기 때문입니다.

어쩌면 당연한 이야기지만, Muse는 사용자에 대해 많이 알수록 유용해집니다. 그리고 많이 알수록 훨씬 더 민감한 시스템이 됩니다.

메타가 소개한 사례 중에는 일상생활에 더 가까운 것도 있습니다.

인스타그램에서 마음에 드는 요리 영상을 저장했다고 해보죠. Muse는 그 영상을 보고 장보기 목록을 만들 수 있습니다. 이어서 저녁 모임을 준비해 달라고 하면 메뉴를 짜고, 해산물 알레르기 같은 친구들의 식단 제한도 기억해 반영합니다. 초대 메시지를 작성한 뒤에는 보내기 전에 사용자의 승인을 기다립니다.

Muse가 하는 일을 하나씩 떼어놓으면 대단해 보이지 않을 수도 있습니다. 영상을 읽고, 레시피를 정리하고, 장보기 목록을 만들고, 친구들의 알레르기와 취향을 확인하고, 일정을 잡고, 초대장을 쓰는 일은 각각 지금의 AI도 할 수 있습니다.

하지만 이 조각들이 자연스럽게 이어지면 ‘저녁 모임 준비’라는 제법 큰 일이 됩니다. Muse가 노리는 것도 바로 이 연결입니다. 질문 하나에 멋진 답을 내놓는 데서 멈추지 않고, 여러 앱과 정보, 기억, 브라우저 작업을 엮어 하나의 용무를 끝내는 것입니다.

메타의 공식 시연 영상에서 Muse는 “여행용 유모차를 찾아 달라”는 요청을 받습니다. 여러 제품의 가격과 특징을 비교한 뒤, 평소 320달러에 팔리던 제품이 80달러로 할인 중이라며 하나를 추천합니다.

Muse는 주문까지 진행하지만 결제 버튼을 마음대로 누르지는 않습니다. 80달러 결제를 확정해야 하는 순간 작업을 멈추고 사용자의 승인을 기다립니다.

중요한 점은 Muse가 사용자의 비밀번호나 실제 카드번호를 직접 보지 않는다는 것입니다. 로그인 정보는 별도의 자격증명 저장소에 들어가고, Muse는 실제 비밀번호를 알지 못한 채 로그인된 브라우저를 이용합니다. 메타는 Stripe의 Link를 이용해 일회용 카드번호도 생성한다고 설명합니다.

물론 쇼핑이 언제나 매끄럽게 끝나는 것은 아닙니다. 클레어 보의 사용기에서 Muse는 특정한 색상의 운동화를 구매하는 과정에서는 브라우저 조작 도중 막혔지만, 조건이 명확한 IMAX 영화표 구매는 끝까지 처리했습니다.

Muse의 능력과 별개로 외부 서비스가 세우는 장벽도 있습니다. Muse 출시 후 얼마 지나지 않아 Amazon은 자사 서비스에 대한 Muse의 접근과 구매를 차단했습니다. 외부 에이전트가 고객 계정과 구매 과정을 다루려면 서비스 제공자의 동의를 받아야 한다는 이유였습니다.

AI가 브라우저를 조작할 수 있다고 해서 모든 웹사이트가 AI의 방문을 받아들여야 하는 것은 아닙니다. 에이전트 시대에는 기술적으로 가능한지가 아니라, 외부 서비스가 그 에이전트의 접근을 허용할 것인지도 새로운 경계가 됩니다.

Muse에서 기술적으로 가장 흥미로운 기능은 따로 있습니다. 사용하려는 서비스에 공식 연결 기능이 없더라도 API나 명령줄 인터페이스가 제공된다면, Muse가 그 서비스를 이용하기 위한 커스텀 커넥터를 만들 수 있습니다.

메타에 따르면 Muse는 코드를 작성하고 프로그램을 컴파일하며, 필요한 스킬을 만들고 여러 하위 에이전트를 동시에 실행할 수 있습니다.

이제 에이전트는 도구 상자에서 필요한 도구를 골라 쓰는 데서 그치지 않습니다. 적합한 도구가 없으면 작업에 필요한 도구를 직접 만들어 사용할 수 있습니다.

바로 이 지점에서 보안 문제의 성격도 달라집니다. Muse가 직접 만든 도구로 이메일과 캘린더, 여러 계정의 정보를 다룬다면 그 도구에 실제 권한을 내주는 결정은 누가 내려야 할까요?

메타는 Muse 사용자마다 전용 가상 머신을 제공합니다. Muse는 그 안에서 프로그램을 작성하고, 코드를 컴파일하고, 브라우저를 조작하며, 필요한 도구를 만들 수 있습니다.

다만 Muse가 움직이는 공간은 가상 머신 전체가 아닙니다. 가상 머신 안에 다시 분리된 리눅스 컨테이너가 있고, Muse는 이 컨테이너 안에서 실행됩니다.

Muse에게 자기만의 작업실을 내줬다고 생각하면 이해하기 쉽습니다. 작업실 안에서는 책상을 옮기고, 새 장비를 만들고, 작업 순서를 바꿀 수 있습니다. 하지만 건물의 전기 배전반과 출입 열쇠, 보안 데스크는 작업실 밖에 있습니다.

이 구조의 중심에는 ‘Sentinel’이 있습니다. 이름은 다소 거창하지만 역할은 명확합니다. Muse가 어떤 행동을 제안하면 Sentinel이 이를 허용할지, 거부할지, 사용자에게 물어볼지를 결정합니다. Muse는 Sentinel을 수정할 수 없습니다.

Muse에게 콘퍼런스 출장 준비를 맡겼다고 해보죠. Muse는 캘린더를 확인하고, 항공편을 검색하고, 주최 측이 보낸 이메일을 읽습니다. 그러다 메타가 아직 연결 기능을 제공하지 않는 서비스를 발견하고, 그 서비스를 이용하기 위한 작은 도구를 직접 만듭니다.

여기까지는 Muse의 작업 영역입니다. 하지만 서비스를 호출하는 프로그램을 작성할 수 있다는 것과 그 서비스를 실제로 이용해도 된다는 것은 별개의 문제입니다.

Muse가 외부로 보내는 네트워크 요청은 모두 Sentinel을 거쳐야 합니다. Sentinel은 요청이 향하는 목적지와 통신 방식, 경로를 확인하고, 암호화가 풀린 실제 요청 내용까지 검사할 수 있습니다.

권한 검사가 Muse가 수정할 수 있는 도구 안에 들어 있다면, 도구를 고치는 과정에서 권한 검사의 내용이나 범위도 바뀔 수 있습니다. 메타는 ‘무엇을 할 것인가’를 결정하는 능력은 Muse에 주되, ‘그 행동을 허용할 것인가’를 결정하는 권한은 Muse의 손이 닿지 않는 곳에 뒀습니다.

Muse가 사용자를 대신해 일하려면 Gmail과 캘린더, 여행 예약 서비스 같은 계정에 접근해야 합니다. 그렇다고 모델이 실제 비밀번호나 접근 토큰까지 알아야 할까요?

메타의 답은 ‘아니요’입니다.

실제 자격증명은 Muse의 작업 공간과 분리된 곳에 보관됩니다. Muse 안에서 실행되는 코드는 진짜 비밀번호나 접근 토큰 대신 메타가 ‘대리 토큰(surrogate token)’이라고 부르는 대체 값만 받습니다.

Muse가 외부 서비스에 요청을 보내면 Sentinel이 먼저 요청을 허용할지 판단합니다. 허용된 요청만 네트워크 경계로 넘어가며, 바로 그 지점에서 별도의 보호 서비스가 대리 토큰을 실제 자격증명으로 바꿉니다.

악성 웹페이지가 Muse에게 “구글 접근 토큰을 보여줘”라고 지시하더라도 Muse는 보여줄 토큰이 없습니다. 애초에 진짜 토큰을 본 적이 없기 때문입니다.

여기서는 서로 다른 두 가지 위험을 구분해야 합니다. 하나는 열쇠 자체를 훔치는 것이고, 다른 하나는 열쇠가 여는 문을 잘못된 목적으로 이용하게 만드는 것입니다.

대리 토큰 구조는 첫 번째 위험을 줄입니다. 그러나 공격자가 Muse를 속여 정상적인 연결을 엉뚱한 용도로 사용하게 만들 가능성까지 사라지는 것은 아닙니다. 자격증명을 숨기는 것과 자격증명이 사용되는 모든 행동을 올바르게 통제하는 것은 서로 다른 문제입니다.

Muse의 보안 구조에서 특히 흥미로운 부분은 정보가 지나온 경로까지 추적하려 한다는 점입니다.

날씨를 확인하는 프로그램을 생각해보죠. 인터넷에는 접속하지만 아직 민감한 정보는 다루지 않았습니다. 이번에는 다른 프로그램이 사용자의 비공개 캘린더를 읽은 뒤 어떤 웹사이트에 접속하려 한다고 해보겠습니다.

겉으로 보면 둘 다 인터넷 접속입니다. 그러나 두 번째 프로그램에는 사용자의 개인정보가 실려 있을 수 있습니다.

Muse는 이 차이를 추적합니다. 각 도구 프로세스는 깨끗한 상태에서 시작합니다. 사용자의 데이터를 읽는 순간 운영체제가 해당 프로세스에 ‘오염됨(tainted)’이라는 표시를 붙입니다.

Muse가 스스로 “이 정도는 괜찮다”고 판단하는 방식이 아닙니다. 에이전트 애플리케이션보다 아래에 있는 운영체제 계층에서 프로세스가 실제로 무엇을 읽었는지 살펴봅니다.

메타는 이를 ‘오염된 외부 통신(tainted egress)’이라고 부르며, eBPF와 리눅스 보안 모듈 훅 같은 기술을 사용해 구현한다고 설명합니다.

세부 기술보다 중요한 것은 질문이 달라진다는 점입니다.

“이 프로그램이 인터넷을 사용해도 되는가?”만 물어서는 부족합니다. “이 프로그램이 내 비공개 캘린더를 읽은 뒤에도 인터넷에 접속해도 되는가?”까지 물어야 합니다.

기밀문서에서 문구 하나를 복사해 구글에 검색해 달라고 했다고 생각해보죠. 에이전트가 한 일은 검색뿐이지만, 검색어에 담긴 기밀정보는 이미 외부로 전송됐습니다.

에이전트 보안에서는 지금 어떤 도구를 호출하고 있는지만 봐서는 부족합니다. 그 도구가 어떤 정보를 읽었고, 그 정보가 어디로 이동하려는지도 함께 살펴야 합니다.

Muse에게 이메일을 읽을 권한만 주고, 보낼 권한은 주지 않았다고 해보죠. 겉으로는 꽤 제한적인 권한처럼 보입니다.

하지만 받은편지함에는 비밀번호 재설정 링크와 일회용 인증번호, 비밀번호 없이 로그인할 수 있는 매직 링크가 들어옵니다. 이메일을 읽는 것만으로 다른 서비스에 로그인하거나 계정 정보를 변경할 수 있는 경우가 생깁니다.

A를 읽는 권한이 B를 수정하는 능력으로 이어지고, B에서 얻은 정보가 다시 C에서 행동할 수 있는 권한으로 바뀌는 것입니다.

메타는 Muse의 이메일 연결 기능에서 일회용 인증번호와 비밀번호 재설정 링크, 로그인 링크를 에이전트에게 보여주기 전에 걸러낸다고 설명합니다.

기존의 ‘읽기’와 ‘쓰기’ 체크박스만으로는 에이전트의 실제 권한을 충분히 설명하기 어렵다는 점을 반영한 설계입니다. 한 시스템에서 정보를 읽는 권한이 다른 시스템에서는 행동 권한으로 바뀔 수 있기 때문입니다.

Muse의 아키텍처를 살펴보다 보면 흥미로운 대목이 하나 있습니다. 코드를 작성하고, 하위 에이전트를 실행하고, 브라우저를 조작하고, 작업 환경까지 바꾸는 미래적인 시스템 아래에 컴퓨터 과학자들이 반세기 전에 제시한 보안 원칙이 자리하고 있다는 점입니다.

1975년 제롬 솔처(Jerome Saltzer)와 마이클 슈뢰더(Michael Schroeder)는 컴퓨터 보안의 토대가 된 논문 ‘The Protection of Information in Computer Systems’를 발표했습니다.

이 논문에는 ‘최소 권한(least privilege)’과 ‘완전 중재(complete mediation)’ 같은 원칙이 등장합니다.

최소 권한은 프로그램에 작업을 수행하는 데 필요한 만큼의 권한만 주라는 뜻입니다. 완전 중재는 보호 대상에 접근할 때마다 빠짐없이 권한을 확인해야 한다는 원칙입니다.

반세기가 지난 지금 이 원칙들이 다시 중요해진 이유는 우리가 원하는 AI 에이전트가 목표에 도달하는 정확한 경로를 미리 예측하기 어려운 프로그램이기 때문입니다.

그 예측 불가능성은 위험인 동시에 에이전트의 가치이기도 합니다. 사용자가 모든 행동과 방문할 웹사이트, 중간 단계를 일일이 지정해야 한다면 직접 하는 편이 나을 수 있습니다. 우리는 에이전트가 상황에 맞춰 방법을 바꾸고, 더 나은 경로를 찾고, 필요하다면 아직 없는 도구까지 만들어주기를 바랍니다.

그러려면 ‘방법을 찾을 자유’와 ‘실제로 행동할 권한’을 분리해야 합니다.

Sentinel도 정책과 모델, 분류기를 사용해 판단하므로 틀릴 수 있습니다. 메타 역시 Muse가 실수할 수 있으며, 프롬프트 인젝션은 여전히 방어해야 할 문제라고 인정합니다.

정보 흐름 추적도 필요하지만 완벽하지는 않습니다. 기준을 너무 느슨하게 잡으면 민감한 정보가 빠져나갈 수 있고, 너무 엄격하게 잡으면 에이전트가 사소한 행동을 할 때마다 승인을 요청합니다.

이 지점에서 기술의 문제는 다시 인간의 문제로 바뀝니다. 에이전트가 하루에도 수십 번씩 “이 행동을 허용할까요?”라고 묻는다면 사용자는 내용을 자세히 읽지 않고 승인 버튼을 누르기 시작할 수 있습니다. 이른바 ‘권한 피로(permission fatigue)’입니다.

메타는 이를 줄이기 위해 승인 요청을 Muse가 대화 형식으로 직접 작성하지 못하게 했습니다. 승인 화면은 Sentinel이 만들고, 이메일 전송이나 구매처럼 민감한 행동에는 사용자의 명시적인 동의를 받습니다.

권한의 범위도 나눴습니다. 한 번만 허용하거나, 현재 작업에서만 허용하거나, 일정 시간 동안 허용하거나, 앞으로 계속 허용하는 옵션을 선택할 수 있습니다.

그렇다고 권한 피로가 해결된 것은 아닙니다.

“이 출장을 준비해줘”라는 요청은 범위가 넓기 때문에 유용합니다. 반대로 “앞으로 11분 동안 지정된 웹사이트 7개와 캘린더 필드 3개, 이메일 한 통에만 접근해도 된다”고 제한하면 더 안전할 수 있지만, 이렇게 세세하게 지정해야 한다면 일을 맡기는 의미가 사라집니다.

에이전트에게 유용할 만큼 넓은 목표를 주면서도 위험한 행동은 정확한 순간에 멈추게 하는 것. 이 균형은 아직 풀리지 않은 문제입니다.

메타는 Muse가 ‘보안 가상 머신(secure virtual machine)’에서 실행된다고 설명합니다. 하지만 여기서 ‘보안’은 그 누구도 내부를 볼 수 없다는 뜻이 아닙니다. 여러 종류의 경계를 분리해 관리한다는 뜻에 가깝습니다.

에이전트의 보안을 평가할 때는 적어도 세 가지 질문을 구분해야 합니다.

첫 번째는 Muse와 보호 장치 사이의 경계입니다. Muse가 실행되는 공간과 Sentinel, 실제 자격증명을 보관하는 공간은 서로 분리돼 있습니다.

두 번째는 사용자와 사용자 사이의 경계입니다. 각 사용자의 Muse는 서로 분리된 전용 가상 머신에서 실행됩니다.

세 번째는 사용자와 가상 머신을 운영하는 회사 사이의 경계입니다. Muse의 가상 머신을 실제로 운영하는 곳은 메타입니다. 현재 구조에서는 서비스를 운영하거나 지원하는 데 필요한 경우 메타가 정해진 조건 아래 가상 머신 내부의 데이터에 접근할 수 있습니다.

메타는 이 구조를 개선하기 위해 ‘Muse Confidential VM’을 도입할 계획이라고 밝혔습니다. 가상 머신 전체를 사용자가 관리하는 키로 암호화해, 기반 인프라를 운영하는 메타조차 내부에서 무슨 일이 일어나는지 들여다볼 수 없게 한다는 구상입니다.

단, Confidential VM은 아직 도입되지 않았습니다.

개인용 에이전트가 이메일과 캘린더, 계정과 사적인 데이터를 폭넓게 다루기 시작하면 이 차이는 중요해집니다. 여러 시스템이 모두 자신을 ‘안전하다’고 설명하면서도 실제로는 전혀 다른 약속을 할 수 있기 때문입니다.

앞으로 어떤 회사가 자신의 에이전트가 안전하다고 말한다면 ‘누구로부터 안전하다는 뜻인지’를 반드시 물어야 합니다.

Muse는 작업에 맞춰 도구를 고르고, 필요한 스크립트와 커넥터를 만들고, 여러 하위 에이전트에게 일을 나눠줄 수 있습니다. 정해진 절차만 따르는 대신 목표에 도달할 방법을 작업 도중 새로 구성하도록 설계됐습니다.

하지만 Muse가 바꿀 수 있는 것은 일하는 방법까지입니다. 외부 통신을 검토하는 Sentinel은 수정할 수 없고, 보호된 저장소의 실제 자격증명도 볼 수 없습니다. 이메일 전송이나 구매처럼 민감한 행동은 별도의 승인을 받아야 합니다.

메타는 ‘작업 방법을 찾는 능력’과 ‘그 방법을 실행할 권한’을 분리했습니다. 에이전트가 목표에 이르는 모든 경로를 미리 정할 수는 없지만, 새로운 경로를 찾았다는 이유만으로 접근 권한까지 넓어질 필요는 없기 때문입니다.

이 구분은 기업이 에이전트를 도입할 때 더욱 중요해집니다. 고객정보와 계약서, 소스코드, CRM과 ERP 같은 공유 자산을 다루는 만큼, 에이전트의 능력이 커진다고 권한까지 함께 커지게 해서는 안 됩니다. 정책 집행과 자격증명, 정보 흐름, 승인과 감사 기능은 에이전트가 임의로 바꿀 수 없는 영역에 둬야 합니다.

물론 메타가 공개한 구조가 실제로 얼마나 효과적인지는 아직 충분히 검증되지 않았습니다. 현재 확인할 수 있는 근거는 메타의 기술 설명과 출시 초기 사용기가 대부분입니다. 실제 테스트에서는 브라우저 작업이 막히기도 했고, 프롬프트 인젝션과 권한 피로 문제도 남아 있습니다. 메타조차 가상 머신 내부를 볼 수 없게 한다는 Confidential VM도 아직 계획 단계입니다.

따라서 지금 Muse를 가장 뛰어난 개인 에이전트라고 평가하기는 이릅니다.

다만 에이전트가 자유롭게 바꿀 수 있는 작업 환경과, 에이전트조차 건드릴 수 없는 보호 장치를 하나의 소비자 제품 안에 함께 구현했다는 점은 눈여겨볼 만합니다.

Muse가 보여준 설계 원칙은 분명합니다.

에이전트는 일하는 방법을 바꿀 수 있어도, 자신에게 주어진 권한의 경계까지 바꿀 수는 없어야 합니다.

읽어주셔서 감사합니다. 친구와 동료 분들에게도 뉴스레터 추천해 주세요!