제333호

에이전트마다 컴퓨터 한 대, 이제 문제는 열쇠예요

메타·오픈AI·Grok Bot·구글이 같은 그림을 그렸어요. 남은 질문은 로그인과 패스키예요

비즈니스

안광섭 (오스왈드)· INLEVEL9 글쓴이·편집자

구글 검색 선호 출처로 추가
에이전트마다 컴퓨터 한 대, 이제 문제는 열쇠예요

두 달 전의 비유가 제품 설명서가 됐어요

지난 8월 「에이전트는 GPU로 생각하고 CPU로 일해요」에서 이런 문장을 썼어요. 에이전트 하나를 고용하는 건 그 에이전트가 쓸 컴퓨터를 한 대 내어주는 것과 비슷하다고요. 그때는 비유였어요.

두 달 사이 이 문장이 제품 설명서로 옮겨 갔어요. 8월 11일 Grok Bot이 베타로 나왔고, 9월 8일 메타가 뮤즈(Muse)를, 9월 29일 오픈AI가 데브데이에서 닷(dots)을 발표했어요. 세 제품 모두 소개 첫머리에 같은 말을 적어요. 에이전트가 자기 컴퓨터와 자기 브라우저를 갖고, 사용자가 앱을 닫아도 그 컴퓨터에서 계속 일한다는 거예요. 10월 22일에는 구글 클라우드가 이런 에이전트를 받쳐 온 내부 인프라, 에이전트 컴퓨트 엔진(Agent Compute Engine)의 설계를 18분짜리 글로 공개했어요. 클라우드플레어는 “에이전트에게 컴퓨터를 주라”는 소개 문구를 단 오픈소스 저장소를 운영하고 있고요.

저는 이게 이제 표준이 되어가고 있다고 봐요. 각자 Secure VM, 클라우드 컴퓨터, 마이크로VM처럼 다르게 부르지만, 에이전트에게 컴퓨터를 내주고 거기서 일을 시킨다는 골격은 같아요. 그래서 질문이 한 칸 옮겨 가요. 그 컴퓨터 안의 브라우저로 사람이 쓰던 웹사이트에 들어가려면 로그인을 해야 하는데, 비밀번호와 각종 인증, 특히 패스키는 어디에 두느냐는 거예요.

이름은 달라도 골격은 하나예요

먼저 다섯 곳이 내놓은 것을 한 표에 놓아볼게요. 공식 발표문과 문서에서 확인한 내용만 적었어요.

제품공개 시점컴퓨터를 주는 단위로그인·결제를 다루는 방식
Grok Bot2026.8.11 베타사용자 계정당 1대, 그 계정의 모든 Bot이 공유비밀번호·패스키·2단계 인증·결제는 사람이 화면을 넘겨받아 직접 처리
메타 뮤즈2026.9.8, 미국사람마다 전용 VM(Muse Secure VM)자격증명은 VM 안 보안 저장소에 두고, 에이전트는 보지 못한 채 사용
오픈AI 닷2026.9.29닷마다 클라우드 컴퓨터와 브라우저비밀번호 관리자 연동을 별도 권한으로 관리, 사용자의 기존 로그인은 넘어오지 않음
구글 에이전트 컴퓨트 엔진2026.10.22 설계 공개, 수개월 내 프리뷰 목표에이전트 세션마다 하드웨어로 격리한 마이크로VM1자격증명을 샌드박스2 안에 두지 않고 바깥 게이트웨이에서 바꿔 끼움
클라우드플레어 Computer오픈소스(MIT)파일시스템을 상태로 보관하고, 실행 환경은 골라 붙임README에서는 확인하지 못함

표를 보면 “한 대씩”이라는 말에도 조금 차이가 있어요. Grok Bot은 Bot마다 컴퓨터를 주지 않아요. 계정 하나에 컴퓨터 한 대를 두고 Bot마다 화면을 따로 줘요. xAI 문서는 이 화면이 작업 공간일 뿐 보안 경계는 아니라고 적고 있어요. 그래서 브라우저 쿠키와 로그인 세션, 파일, 명령줄 자격증명이 계정 안의 모든 Bot에게 공유돼요. 이 컴퓨터는 커서(Cursor)의 클라우드에서 돌아가요.

클라우드플레어 쪽은 아예 VM이 아니에요. Durable Object라는 저장 단위 안에 SQLite로 파일시스템을 들고 있고, 실행은 리눅스 컨테이너나 가벼운 격리 환경 중에서 골라 붙이는 구조예요. 실행 환경 없이 파일시스템만 쓸 수도 있어요. 저장소는 패키지 전체는 운영에 써도 되지만 컨테이너 백엔드는 아직 실험 단계라고 밝혀 두었어요.

이 차이가 오히려 공통점을 보여줘요. 에이전트에게 필요한 컴퓨터는 결국 두 가지로 이뤄져 있어요. 오래 남는 작업 상태와, 그 상태를 가지고 무언가를 실행할 곳이에요. 구글과 메타는 둘을 한 대의 VM에 담았고, 클라우드플레어는 둘을 떼어 놓았을 뿐이에요.

왜 하필 컴퓨터 한 대였을까요

구글의 설명이 가장 자세해요. 제미나이 팀의 목표는 사용자마다 클라우드에서 돌아가는 개인 에이전트를 붙여주는 것이었어요. 사용자의 작업을 기억하고, 사용자가 자리를 비운 사이에도 일하는 에이전트요. 그러려면 에이전트마다 파일시스템, 언어 런타임, 브라우저, 네트워크가 있는 컴퓨터가 필요했다고 해요.

구글은 에이전트를 두 부분으로 나눠 설명해요. 모델을 부르고 다음 행동을 정하는 하네스3가 두뇌이고, 모델이 시킨 코드와 명령어와 브라우저를 실제로 돌리는 샌드박스가 손이에요. 손을 주려면 컴퓨터를 줘야 하는데, 기존 선택지가 둘 다 맞지 않았어요. 일반 VM은 켜고 멈추고 다시 띄우는 데 몇 초에서 몇 분이 걸리고, 컨테이너는 빠르지만 호스트의 커널을 나눠 써서 루트 권한까지 필요한 코딩 에이전트를 격리하기에는 약해요.

여기에 구글이 측정해서 얻은 관찰이 하나 더 있어요. 에이전트는 대부분의 시간을 기다리면서 보내요. 모델의 다음 답을 기다리고, 사용자의 답장을 기다려요. 그래서 도구 실행이 끝나 ‘생각’ 단계로 넘어가는 순간 상태를 저장해 두고 자원을 거의 쓰지 않게 내려놓았다가, 다음 도구 호출 때 바로 깨우는 방식을 택했어요.

지속성에 대한 예시도 와닿아요. 월요일에 스프레드시트 분석을 맡겼더니 에이전트가 파이썬 라이브러리 두 개를 깔고 스크립트를 짜서 차트를 저장했어요. 화요일에 후속 질문을 했는데 라이브러리를 다시 깔고 스크립트를 다시 써야 한다면, 사용자는 기다려야 하고 답이 달라질 수도 있어요. 그래서 에이전트에게 오래 가는 디스크가 필요했다는 거예요.

에이전트의 기억은 대화 기록만이 아니라는 얘기예요. 설치한 도구, 저장한 파일, 그리고 열어 둔 로그인 세션까지 기억에 들어가요. Grok Bot 문서도 브라우저 세션이 유지되니 작업마다 다시 로그인할 필요가 없다고 설명해요. 컴퓨터를 오래 살려 두는 순간, 그 안의 브라우저는 사용자의 계정에 로그인된 채로 남아 있게 돼요.

컴퓨터는 줬는데, 열쇠는 어디에 둘까요

브라우저를 쓰는 에이전트가 강한 이유는 API나 연동 도구가 없는 서비스도 사람처럼 화면으로 다룰 수 있어서예요. 그런데 사람용 화면에는 사람용 관문이 있어요. 로그인, 2단계 인증, 캡차, 결제 확인이요. 다섯 곳의 문서를 읽어 보면 이 관문을 다루는 방식이 크게 세 갈래로 나뉘어요. 한 제품이 여러 방식을 섞어 쓰기도 해요.

열쇠를 컴퓨터 안으로 들이지 않는 방식. 구글은 샌드박스 안의 모든 것을 공격자가 장악했다고 가정하고 설계를 시작했다고 써요. 예로 든 장면이 구체적이에요. 받은편지함을 관리하는 에이전트가 숨은 문구가 담긴 메일을 읽는데, 그 문구가 이 컴퓨터에서 API 키를 찾아 어떤 주소로 보내라고 지시하는 상황이에요. 모델은 대부분 무시하지만 가끔은 따를 수 있어요. 프롬프트 인젝션4이에요. 그래서 구글은 사용자 자격증명, API 키, OAuth 갱신 토큰5을 샌드박스의 메모리와 디스크에 아예 두지 않아요. 바깥으로 나가는 요청은 노드의 프록시를 거쳐 게이트웨이로 가고, 게이트웨이가 사용자 위임과 에이전트 신원과 노드 신원을 확인한 뒤에 필요한 자격증명을 요청에 끼워 넣어요. Grok Bot도 연결 앱의 OAuth 토큰은 컴퓨터가 아니라 커서의 백엔드에 두고, Bot은 토큰을 받지 않은 채 도구를 호출해요.

금고에 넣고 보지 못한 채 쓰게 하는 방식. 메타는 자격증명을 뮤즈의 VM 안에 보관한다고 밝혀요. 대신 보안 저장소에 넣어서 뮤즈가 내용을 보지 못한 채 쓰게 하고, 사용자가 브라우저에 직접 입력하는 비밀번호도 뮤즈는 볼 수 없다고 해요. 같은 VM 안에 뮤즈와 분리된 센티넬(Sentinel)이라는 감시 에이전트를 두고, 센티넬이 승인하지 않으면 뮤즈의 어떤 행동도 인터넷에 닿지 못하게 했어요. 결제는 Stripe의 Link가 일회용 카드 번호를 만들어 실제 카드 정보를 가리고, 1Password 연동은 곧 붙인다고 해요. 오픈AI는 기업 관리자 설정에서 닷의 비밀번호 관리자 사용을 클라우드 브라우저 권한과 따로 켜고 끄게 해 두었어요.

결정적인 순간만 사람이 직접 하는 방식. Grok Bot은 비밀번호, 패스키, 2단계 인증, 캡차, 결제 확인이 나오면 사람에게 컴퓨터 화면을 넘겨요. 사람이 그 단계만 처리하고 돌려주면 Bot이 이어서 일해요. 문서는 Bot이 자격증명을 입력하지 않고 비밀번호를 보지도 않는다고 적어요.

세 방식 모두 모델이 비밀을 직접 보지 않게 한다는 목표는 같아요. 갈리는 지점은 로그인한 뒤에 남는 세션이에요. 오픈AI 도움말은 닷의 클라우드 컴퓨터가 사용자의 VPN, 브라우저 로그인, 기기 정책을 물려받지 않으니 웹사이트에 따라 클라우드 컴퓨터에서 다시 로그인해야 할 수 있다고 안내해요. 한 번 로그인하면 그 세션은 내 노트북이 아니라 회사 클라우드의 컴퓨터에 남아요. Grok Bot은 그 세션이 계정 안 모든 Bot에게 열려 있고, Bot을 지워도 공유 컴퓨터의 파일과 브라우저 세션은 지워지지 않는다고 적어 두었어요. 내 계정에 로그인된 두 번째 컴퓨터가 남의 데이터센터에 한 대 생기는 셈이에요.

패스키가 유독 까다로운 이유

비밀번호는 금고에 넣을 수 있어요. 패스키는 사정이 달라요. 패스키6는 내 기기나 보안 키에 저장된 암호 자격증명이고, 얼굴 인식이나 지문, 기기 PIN, 보안 키 터치로 풀려요. 그 자리에 그 사람과 그 기기가 있다는 걸 증명하려고 만든 장치예요. 그런데 에이전트의 클라우드 컴퓨터는 내 기기가 아니고, 그 앞에 나는 없어요.

그래서 에이전트 컴퓨터에서 패스키를 쓰는 방법은 지금 두 방향으로 갈려요. 하나는 인증하는 순간을 사용자의 기기로 넘기는 거예요. Grok Bot은 사용자의 데스크톱에 꽂힌 하드웨어 보안 키를 클라우드 컴퓨터의 브라우저가 쓸 수 있게 해 두었어요. macOS와 윈도에서는 기본으로 켜져 있고 리눅스는 아직 지원하지 않으며, 쓸 때마다 사용자의 승인을 받아요. 패스키가 원래 뜻하는 바는 지키지만, 사용자가 잠든 새벽에 에이전트 혼자 끝낼 수 있는 일은 그만큼 줄어요.

다른 하나는 표준을 새로 만드는 거예요. FIDO 얼라이언스는 2026년 4월 28일 에이전트 인증 기술 작업반을 꾸렸어요. 검증 가능한 사용자 지시, 에이전트 인증, 상거래를 위한 신뢰할 수 있는 위임, 이 세 가지를 축으로 삼았고 구글은 에이전트 결제 프로토콜(AP2)을 기여했어요. 오픈AI도 같은 해 FIDO 이사회에 합류했어요. 큰 방향은 패스키로 사람이 있다는 걸 확인하고, 그 사람이 정한 범위만큼의 권한을 증명 가능한 형태로 에이전트에게 넘기는 쪽이에요. 아직 작업 중인 규격이라 오늘 나온 제품들이 기댈 수 있는 단계는 아니에요.

agent computers and keys제가 읽은 공식 문서 범위에서는 사용자의 패스키를 에이전트 컴퓨터에 저장해 두고 쓴다고 밝힌 곳은 없었어요. 비밀번호 관리로 유명한 1Password는 에이전트들이 사용할 새로운 기능을 내놓기 까지 했어요.

Introducing 1Password for Agents | 1PasswordIntroducing 1Password for Agents. Learn how 1Password helps supported personal AI agents sign in with your approval, without seeing your passwords or one-time codes.1password.com

오스왈드의 시선

에이전트에게 컴퓨터를 한 대씩 주는 방식은 이제 표준이 되어가고 있다고 봐요. 메타, 오픈AI, Grok Bot이 두 달 사이 같은 방식으로 제품을 내놨고, 구글과 클라우드플레어는 그 밑의 인프라를 다른 회사도 쓸 수 있게 내놓고 있어요. 그래서 이제 관건은 그 컴퓨터 안에서 벌어지는 브라우저 사용, 그리고 각종 인증과 패스키를 어떻게 저장하고 쓰느냐예요.

컴퓨터 쪽은 빠르게 서로 닮아 가고 있어요. 하드웨어 격리든 계정 단위 격리든, 사용자가 화면을 열어 지켜보다 언제든 끼어들 수 있다는 점까지 거의 같아요. 차이가 오래 남을 곳은 로그인된 상태를 누가, 어디에, 얼마나 오래 들고 있느냐예요. 같은 기능을 하는 에이전트 두 개가 있다면 사용자는 결국 내 은행과 메일의 로그인 세션을 어느 회사의 컴퓨터에 남겨 둘지를 고르게 될 거예요.

한국 서비스에서는 이 문제가 더 일찍, 더 자주 드러날 수 있어요. 휴대폰 본인확인, 간편인증 앱, 인증서처럼 사용자 손에 있는 휴대폰과 앱을 거쳐야 하는 절차가 많아서, 클라우드 컴퓨터에서 일하는 에이전트는 사람에게 화면을 넘기는 지점을 더 자주 만날 거예요. 에이전트 도입을 검토하는 국내 기업이라면 어떤 업무를 맡길지보다 그 업무가 어떤 로그인과 인증을 거치는지부터 적어 보는 편이 실제 범위를 더 정확하게 보여줄 거예요.

마치며

컴퓨터 한 대는 정해진 답이 되어가고 있어요. 열쇠를 두는 방식은 회사마다 다르고, 표준은 이제 만드는 중이에요. 다음에 새 에이전트 제품이 나오면 사양표의 CPU나 메모리보다 로그인과 결제를 다루는 문단을 먼저 읽어 보셔도 좋겠어요. 그 문단에 그 회사가 고른 방식이 적혀 있어요.

💬 구독자님은 에이전트에게 어디까지 로그인을 맡기실 수 있으세요? 메일은 되는데 은행은 안 된다처럼 나름의 선이 있다면 댓글로 들려주세요.

📨 에이전트 도입이나 계정 보안을 맡고 있는 동료가 있다면 이 글을 공유해 주세요.

여러분의 생각이 다음 호를 만듭니다

이번 호에서 가장 공감했거나, 다른 경험을 한 지점은 무엇인가요?

댓글은 무료 회원이면 누구나 남길 수 있어요.

커피 한 잔 보내기

이 관점이 좋았다면, 다음 글에 커피 한 잔

오스왈드에게 커피와 함께 짧은 쪽지를 보내주세요. 응원은 다음 취재와 집필에 보탭니다.

오스왈드에게

커피와 쪽지 보내기

“에이전트마다 컴퓨터 한 대, 이제 문제는 열쇠예요”을 읽고 떠오른 말을 남겨주세요. 메뉴 이름만큼의 응원금과 함께 전달됩니다.

어떤 커피로 보낼까요?

참고자료 & 더 읽기

핵심 출처

배경 지식

함께 읽으면 좋은 지난 호

안광섭(오스왈드) 프로필 일러스트

필자 안광섭 (오스왈드)은 세종대학교 겸임교수, INLEVEL9 전략 컨설턴트입니다. 경력, 연구, 저서와 최신 활동은 저자 소개에서 계속 갱신합니다. 최근 소식 · 2026년 8월: 2026 세종도서 교양부문 우수도서 선정.

📝 용어 설명

각주

  1. 마이크로VM (microVM): 꼭 필요한 기능만 남겨 아주 빨리 켜지도록 만든 작은 가상머신이에요. 컨테이너처럼 빠르면서 일반 VM처럼 하드웨어 수준에서 서로를 격리하는 걸 목표로 해요. ↩

  2. 샌드박스 (Sandbox): 프로그램을 바깥 시스템과 분리된 공간에서 실행하게 하는 격리 환경이에요. 그 안에서 무슨 일이 생겨도 밖으로 번지지 않게 하려는 장치예요. ↩

  3. 하네스 (Harness): 모델을 호출하고, 결과를 보고 다음에 어떤 도구를 쓸지 정하는 바깥 제어 코드예요. 구글은 이를 에이전트의 두뇌, 실제 실행 환경을 손에 비유해요. ↩

  4. 프롬프트 인젝션 (Prompt Injection): 웹페이지나 메일 안에 AI에게 보내는 지시를 몰래 심어, 그 내용을 읽은 AI가 원래 사용자의 지시 대신 그 지시를 따르게 만드는 공격이에요. ↩

  5. OAuth 갱신 토큰 (Refresh Token): 비밀번호 대신 앱에 접근 권한을 넘길 때 쓰는 OAuth 방식에서, 짧게 쓰는 접근 토큰을 계속 새로 받아올 수 있게 해주는 오래가는 토큰이에요. 유출되면 비밀번호 없이도 오랫동안 계정에 접근할 수 있어요. ↩

  6. 패스키 (Passkey): 비밀번호 대신 기기에 저장된 암호 키로 로그인하는 방식이에요. 키는 기기 밖으로 나가지 않거나 사용자의 계정 안에서만 동기화되고, 쓸 때마다 생체 인식이나 PIN 같은 본인 확인을 거쳐요. ↩

함께 읽으면 좋은 지난 호

제332호

1945년에 설계된 기계, 핵심은 저장이 아니었어요

버니바 부시의 메멕스는 책을 쌓아두는 기계보다 생각이 지나간 길을 남기는 기계에 가까웠어요

비즈니스
제330호

같은 PVC 수지인데 반덤핑 관세는 회사마다 달라요

세율표 한 줄마다 따로 맞춘 장부가 있어요

비즈니스
제329호

2026년, 크립토 잔혹사

가격은 남았는데 거래가 사라졌어요. 81개의 종료 공고를 겹쳐 읽으면 무엇이 죽었고 무엇이 살았는지가 보여요

비즈니스