메타 뮤즈의 에이전트 경험에서 가져갈 둘, 의심할 하나
![]()
뮤즈가 영화관 좌석을 고르고 유모차를 장바구니에 담는 동안, 이용자는 대화창에서 "결제할까요?"라는 질문에 답하지 않습니다. 결제 승인은 대화가 아니라 앱 화면의 별도 대화상자로 뜨고, 이용자의 답은 뮤즈가 아니라 센티넬(Sentinel)이라는 다른 에이전트에게 곧바로 전달돼요. 유훈식 교수가 메타의 개인 에이전트 '뮤즈'의 경험 디자인을 정리한 칼럼에는 긴 대화, 선제성, 페르소나, 투명성, 승인, 아티팩트, 발견 가능성까지 여러 결정이 줄지어 나오는데, 저는 이 승인 장면 하나가 나머지 전부보다 무겁다고 봐요.
목록을 전부 따라가기보다 세 가지만 골랐습니다. 둘은 메타가 아닌 팀도 다음 주에 바로 가져갈 만한 결정이고, 하나는 칼럼의 결론과 달리 의심해봐야 할 결정입니다.
가져갈 것 하나 — 승인은 대화가 아니라 고정된 화면에서

뮤즈는 사용자마다 클라우드에 격리된 리눅스 환경, Muse Secure VM을 한 대씩 줍니다. 그 안에서 뮤즈는 행동을 '제안'할 뿐이고, 외부 서비스에 대한 행동과 모든 네트워크 전송은 시스템 수준에서 분리된 센티넬이 허용, 거부, 사용자에게 묻기 중 하나로 판정합니다. 비밀번호와 결제 정보는 별도 저장소에 들어가고 뮤즈는 대리 토큰만 봐요. 디자인팀은 승인 카드와 자격 증명 저장소를 결정론적(Deterministic) UI가 양보할 수 없는 영역으로 정했고, 그 결과 에이전트가 말로만 허락받았다고 주장할 여지가 구조적으로 사라졌습니다.
제가 이 결정을 첫째로 꼽는 이유는 대화형 AI의 가장 약한 고리를 정확히 찔렀기 때문입니다. 대화창 안에서 "네"라고 답한 기록은 에이전트가 해석하고 요약하는 텍스트일 뿐이에요. 프롬프트 인젝션 한 줄이면 '사용자가 동의했다'는 문장을 만들어낼 수 있습니다. 동의를 고정된 화면에서 받고 그 답을 행동을 실행하는 쪽이 아닌 다른 판정자에게 보내면, 에이전트가 아무리 설득력 있게 굴어도 승인을 위조할 수 없습니다.
승인을 얼마나 자주 묻느냐에 대한 고민도 구체적입니다. 사람들이 귀찮아서 무엇이든 승인해버리는 배너 무시(Banner blindness)를 경계해, 기본값은 일반적인 웹 탐색은 허용하고 되돌리기 어려운 행동에서만 멈추게 했어요. 승인 범위는 한 번, 세션, 작업, 기간 한정, 영구 중에서 고르고, 이메일처럼 읽기와 보내기가 나뉘는 서비스는 권한을 따로 줍니다. 결제는 가장 보수적으로, 스트라이프의 Link로 특정 가맹점과 금액에만 쓸 수 있는 일회용 카드를 발급하고 매번 사람의 승인을 받고요. 이 다섯 단계 범위와 읽기·쓰기 분리는 에이전트 기능을 붙이는 어느 제품이든 그대로 베낄 만한 설계입니다.
다만 베낄 때 놓치기 쉬운 게 하나 있습니다. '일반 탐색은 허용, 되돌리기 어려운 행동에서만 멈춤'이라는 기본값은 디자인 결정처럼 보이지만 사실은 회사가 감수할 위험의 수준을 정하는 결정이에요. 무엇이 되돌리기 어려운 행동인지를 누가 분류하고, 그 목록을 누가 언제 갱신하는지가 정해져 있지 않으면 기본값은 출시 일정에 맞춰 조용히 느슨해집니다. 저라면 이 목록을 디자인 문서가 아니라 보안 정책과 같은 무게로 관리하겠어요.
가져갈 것 둘 — 안 보이는 일을 보이게
뮤즈는 앱이 닫혀 있어도 일정에 따라, 혹은 관련 사건이 생기면 다음 단계를 진행합니다. 디자인팀은 이 능력이 동시에 불안을 만든다는 걸 인정하고 "볼 수 없는 것은 신뢰할 수 없다"는 원칙을 세웠어요. 그래서 활동 기록, 권한 화면, 설정, 그리고 사용자가 직접 읽고 고칠 수 있는 메모리 파일까지 투명성을 여러 층에 심었습니다. 오래 걸리는 과제가 쌓이자 뮤즈가 무엇을 추적하고 어떤 계획으로 가는지를 보여주는 목표(Goals) 탭도 생겼고요.

사란타코스가 든 사례가 이 설계의 가치를 보여줍니다. 아이들의 개학 준비를 맡겼더니, 학교 이메일 더미에 묻혀 있던 아들의 스포츠 입단 테스트 신청 마감이 12시간 남았다는 걸 찾아 비행기 탑승 직전에 알려줬다는 거예요. 자사 사례라는 점은 감안해야 하지만, 에이전트의 가치가 대신하는 일만큼 대신 알아차리는 일에 있다는 걸 잘 보여줍니다. 그리고 알아차린 일을 사용자가 확인할 수 있어야 그 가치가 신뢰로 바뀌죠. 저는 메모리를 사용자가 직접 읽고 고칠 수 있는 파일로 둔 결정을 이 층들 중 가장 과감한 선택으로 봐요. 에이전트가 나에 대해 무엇을 믿고 있는지 열어 보여주는 제품은 아직 드뭅니다.
의심할 것 하나 — 이름과 얼굴을 가진 에이전트

긴 대화를 나누다 보니 팀원들은 기업 로고와 이야기하는 게 어색하다고 느꼈고, 저마다 자기 뮤즈를 만들기 시작했습니다. 그래서 사용자는 뮤즈에 이름을 붙이고 아바타와 스타일, 소통 방식을 고를 수 있어요. 사란타코스는 자기 뮤즈에 지혜를 떠올리게 하는 산스크리트어 이름 '베다(Veda)'를 붙였다고 합니다. 아바타 아래에는 뮤즈가 지금 하는 일이 짧게 표시되고, 누르면 전체 활동 기록과 승인한 권한이 열려요. 얼굴이 있어야 지금 뭘 하냐고 물을 대상이 생긴다는 논리입니다.
아바타를 상태 표시판으로 쓴 건 좋은 디자인이라고 봅니다. 동의하기 어려운 건 칼럼의 결론 쪽이에요. 칼럼은 말풍선부터 아이디어 탭까지 모든 화면이 에이전트의 행동 방식에서 거꾸로 도출됐다고 정리하는데, 페르소나는 행동에서 나온 결정이 아닙니다. 팀원들의 어색함, 그리고 테크크런치가 짚은 대로 이용자가 에이전트와 더 연결돼 있다고 느끼게 해 메타에 대한 우려를 누그러뜨리려는 사업적 판단에서 나왔어요. 메타는 2011년 개인정보 약속 위반으로 FTC와 합의했고, 2019년에는 50억 달러 규모의 제재를 받았습니다.
앞의 두 결정은 신뢰를 구조로 만듭니다. 위조할 수 없는 승인, 열어볼 수 있는 기록. 페르소나는 신뢰를 감정으로 만들어요. 문제는 뮤즈가 사용자가 방문한 쇼핑몰이 그 방문을 근거로 인스타그램 광고를 띄울 수 있다는 간접 영향을 인정했고, 대화와 도구 호출 기록이 비식별 처리 뒤 기본값으로 모델 학습에 쓰인다는 점입니다. 이런 이해관계가 얽힌 에이전트일수록 '내 편 같은 이름과 얼굴'은 판단을 흐리게 하는 장치가 될 수 있습니다. 칼럼도 이 위험을 비판적으로 봐야 한다고 적었는데, 저는 그게 결론의 한 줄이 아니라 페르소나를 쓸지 말지를 가르는 기준이어야 한다고 봐요.
그 외에도 하나의 긴 대화와 사이드 채팅, 방해할 가치가 있을 때만 먼저 말을 거는 선제성의 기준, 텍스트 대신 일정표나 지출 추적기를 만들어주는 아티팩트, 빈 입력창 앞에서 멈칫하는 사용자를 위한 아이디어 탭도 다뤄지는데, 모두 좋은 결정이지만 앞의 셋만큼 다른 팀의 설계를 바꾸진 않을 것 같아요.
제 결론은 이렇습니다. 에이전트 기능을 설계하는 팀이 뮤즈에서 먼저 가져갈 건 '동의가 필요한 행동' 목록을 만들고 그 승인을 대화가 아닌 고정된 화면으로 받는 일입니다. 페르소나는 그다음, 그리고 에이전트가 사용자 말고 다른 누구의 이익과도 얽혀 있지 않다고 말할 수 있을 때만 붙여야 합니다.