한국어
Manus 는 클라우드 브라우저에서 로그인 상태와 사용자 자격 증명을 어떻게 처리하나요?
이 글에서는 Manus 가 클라우드 브라우저에서 로그인 세션을 관리하는 방식, 에이전트 기반 인증의 보안 위험, 그리고 OAuth 및 자격 증명 보관함 같은 대안에 대해 다룹니다.
Guamian
Product & Design
Product & Design
이 글에서는 Manus 가 클라우드 브라우저에서 로그인 세션을 관리하는 방식, 에이전트 기반 인증의 보안 위험, 그리고 OAuth 및 자격 증명 보관함 같은 대안에 대해 다룹니다.
이렇게 상상해보세요: AI 에이전트에게 항공권을 예약하거나, 이메일을 확인하거나, CRM 을 업데이트하도록 요청합니다. 이를 위해서는 온라인 계정에 접근할 수 있어야 합니다. 그런데 어떻게 하면 비밀번호를 계속 요청하지 않고도 안전하게 로그인할 수 있을까요?
에이전트는 사용자 대신 여러 작업을 처리할 수 있습니다. 이를 위해 웹사이트, 데이터베이스, 외부 API 등 타사 서비스에 접속할 필요가 있습니다. 에이전트가 프로그래밍 방식으로 이들 서비스에 연결하는 경우도 있지만, 여전히 많은 작업이 전통적인 로그인 방식과 사용자 상호작용을 요구합니다.
이전 글에서는 브라우저가 사용자 자격 증명을 관리할 때 발생할 수 있는 보안 취약점 등 여러 위험성에 대해 다뤘습니다. https://blog.logto.io/agent-auth#chatgpt-operator-agent-auth-experience
이런 방식은 앞서 이야기한 바와 같이 확실히 보안 우려가 있지만, 사용자 입장에서 제공되는 편리함을 무시하기 어렵습니다. 사용성과 보안 간의 긴장 관계는 기술적으로 매우 흥미로운 연구 분야를 만듭니다.
이번 글에서는 제가 “브라우저 기반 로그인 및 인증” 문제를 이미 어떻게 해결하고 있는 몇몇 에이전트 사례를 살펴보겠습니다.
특히 Manus 가 이 문제에 어떻게 접근하는지, 남아 있는 위험은 무엇인지, 앞으로 에이전트 환경에서 인증은 어떻게 진화할지를 구체적으로 살펴볼 것입니다.
Manus 는 클라우드 브라우저라는 기능을 설계했는데, 이는 완전히 클라우드에서 실행되는 격리된 원격 컴퓨터처럼 동작합니다. 에이전트만의 사설 웹 브라우저라고 생각할 수 있죠. 핵심 특징은 무엇이든: 로그인 상태를 기억할 수 있어, 기기나 작업이 달라도 그대로 로그인 상태가 유지된다는 점입니다.
작동 방식은 다음과 같습니다:
마치 에이전트에게 어디서든 사용할 수 있는 안전한 키카드를 넘겨주는 것과 비슷하지만, 오직 자기 전용 잠긴 방에서만 쓸 수 있습니다.
이럴 수도 있겠죠: “이거 그냥 Chrome 쓰는 거랑 뭐가 달라? 에이전트 기반 클라우드 브라우저가 왜 더 위험해 보이지?” 직접적으로 하나씩 비교해 보겠습니다.
| 측면 | 로컬 브라우저(예: Chrome) | 일반적인 에이전트 클라우드 브라우저 |
|---|---|---|
| 위치 | 내 개인 기기에서 실행 | 클라우드에서 원격 실행 |
| 제어 | 완전히 내 통제 하에 있음 | 코드 또는 AI 에이전트가 제어 |
| UI 피드백 | 내가 직접 상호작용 (폼 필드, 자동완성 등 명확하게 보임) | UI 도 제공하며 사용자가 통제할 수 있지만, 대부분의 동작은 에이전트가 조용히 자동 처리 |
| 저장 방식 | OS 수준 암호화(예: macOS 키체인)로 자격 증명 보관 | 자격 증명 또는 쿠키가 메모리나 로그에 저장될 수 있어 노출 위험 증가 |
| 보안 경계 | OS + 브라우저 샌드박스로 보호 | 별도 격리 구현 필요, 에이전트가 악의적으로 동작하면 노출 위험 |
| 신뢰 모델 | Chrome 자체를 신뢰 (내가 직접 사용할 때, 인간 사용을 전제로 설계) | 에이전트 개발자를 신뢰해야 함 — 충분한 보안 조치가 적용되지 않을 수 있음 |
내가 직접 제어 Chrome 은 1st 파티 인터페이스이며, 내가 직접 입력하고 동작을 확인할 수 있으며, 내 컴퓨팅 환경에 속합니다. 비밀번호를 입력할 땐 항상 내가 원해서 입력하고, 브라우저는 가시적이고 검증 가능한 UI 를 제공합니다.
견고한 보안 통합 Chrome 과 같은 브라우저는 비밀번호를 OS 의 안전한 저장소에 보관하고(예: 바이오인증 또는 기기 로그인 필요), 자동완성도 인증받은 도메인 등 예상된 맥락에서만 동작합니다.
최소 위임 Chrome 에 비밀번호를 “넘기는” 것이 아니라, 내가 허락해서 잠깐 기억해 두는 겁니다. 항상 내가 주체로 동작하지, 제3자가 대신하는 것은 아님.
내 대신 동작하지만, 내 눈에 보이지 않음 클라우드 브라우저는 프로그램적으로 제어됩니다. 자격 증명을 입력하면 내 대신 로그인하고, UI 나 직접 피드백 없이 자동으로 처리됩니다. 이로 인해 가시성 (visibility)과 책임성 (accountability)에 간극이 생깁니다.
저장 리스크 자격증명을 평문으로 에이전트에 전달하면 로그, 캐시, 심지어 메모리에 남을 수 있습니다. 엄격한 접근 제어가 없으면 심각한 보안 문제로 이어지죠.
불명확한 신뢰 경계 에이전트 서비스 업체를 믿는 수밖에 없지만, Chrome 과 달리 OS 수준이나 물리적 보호를 기대할 수 없습니다. 서버나 에이전트 코드에 문제 생기면 당신의 자격 증명이 유출될 수 있습니다.
“1st 파티”와 “3rd 파티”가 실제로 무엇을 의미하고, 왜 Chrome 은 1st 파티로, 에이전트 클라우드 브라우저는 3rd 파티로 간주되는지 더 자세히 알아보겠습니다.
| 역할 | Chrome | 에이전트 클라우드 브라우저 |
|---|---|---|
| 사용자(You) | 1st 파티 오퍼레이터 | 자격 증명 소유자 |
| 브라우저/앱 | 1st 파티 인터페이스(직접 상호작용) | 사용자를 대신하는 3rd 파티 위임체 |
| 자격 증명 관리자 | OS + Chrome (강하게 결합된 로컬 신뢰 체인) | 외부 에이전트 서비스(느슨한 신뢰 경계) |
| 저장 방식 | OS 보호 하에 로컬 저장 | 클라우드 서버나 백엔드 인프라에 원격 저장 |
Chrome 에 비밀번호를 입력해도 안전한 이유는, 내가 통제하는 앱에 내가 직접 입력하고 내 OS 가 여러 방어막을 제공하기 때문입니다. 구글 역시 서버에 내 비밀번호를 따로 저장하지 않습니다.
그런데 Manus 가 설명하듯:
로그인 정보를 암호화된 파일 세트로 저장 후 저장소 서버로 안전하게 업로드합니다. 이 정보에는:
즉, 로그인 정보가 Manus 의 백엔드 서버에 저장된다는 의미입니다. 사용자는 에이전트 개발자를 신뢰해야 하고, 이는 표준 보안 모범 사례와 완전히 일치하지 않을 수 있습니다.
에이전트가 제어하는 클라우드 브라우저에 자격 증명을 주는 건 근본적으로 위임(delegation) 입니다. 수동으로 브라우저를 조작하더라도, 접속 서비스 관점에서는 여전히 3rd 파티에 해당합니다. 결국 당신은 남의 인프라, 보안 관행, 윤리 기준에 의존하며 신뢰와 안전 리스크가 생깁니다.
이런 상황에선, 단순한 브랜드 신뢰나 기업 약속이 아니라 프로그래밍적 프로토콜로 보안을 보장해야 합니다.
Manus 의 방식도 똑똑하지만, 이것만 있는 건 아닙니다. 대표적인 로그인 처리법도 함께 살펴봅니다:
에이전트가 사용자처럼 직접 ID 와 비밀번호를 입력하는 가장 단순한 방법입니다. 구현은 쉽지만, 유출 시 계정 탈취 등 매우 위험하므로 권장되지 않습니다. 이런 리스크 때문에 대부분 개발사는 이 방법을 피합니다.
그래도 사용할 경우엔 보관함(vault) 또는 시크릿 매니저 같은 도구와 함께 써서 쿠키나 자격 증명을 더 안전하게 처리하려 하죠.
위임형 액세스의 표준입니다. 사용자가 OAuth 인증 흐름을 완료하면, 에이전트는 제한된 권한의 토큰을 발급받습니다. 안전하고 세밀하며 쉽게 회수 가능하지만, 해당 사이트가 OAuth 를 지원해야만 적용할 수 있습니다.
일부 서비스는 직접 사용할 수 있도록 API 키 또는 접근 인증 정보를 제공합니다. 일반 비밀번호 입력보단 더 안전한 편이나, 권한이 크게 설정되는 경우가 많아 관리가 특히 중요합니다.
각 방법은 사용성과 보안 사이에서 타협점이 다릅니다. Manus 의 세션 리플레이는 OAuth 보다는 유연하지만, 본질적으론 덜 안전하다고 볼 수 있습니다.
이상적으로는, 이 브라우저 기반 시나리오에서 Manus 가 감지된 특정 사이트(예: 지원 사이트 목록)에 미리 통합되어, 사용자가 사전 동의를 하면 OAuth 토큰만으로 안전하게 동작하게 만드는 것이 좋겠습니다. 즉 자격 증명 대신 OAuth 나 세션만을 저장 및 재생하는 방식입니다.
에이전트가 더 강력해질수록, 스스로 사람인 척하지 않고도 인증할 수 있는 세련된 방법이 필요해집니다.
이 방향성은 다음과 같습니다:
정리하자면: 에이전트는 “도우미 봇”을 넘어 “인가받은 운영자” 역할로 진화하고, 이에 맞는 자격 증명이 필수화됩니다.
이 모든 걸 스스로 관리하라면 번거롭겠죠. 브라우저 자동화가 계속 발전하는 만큼, 전문가용 자격 증명 관리 도구와 반드시 함께 써야 합니다. 자격 정보, 보안, 세션 관리를 안전하고 투명하게 취급해주는 도구입니다.
그래서 Vault 나 암호화 키 관리(EKM) 시스템이 중요한 것입니다.
Vault 는 비밀(시크릿) 관리 솔루션으로, 팀이 다음을 할 수 있게 합니다:
에이전트 기반 환경에서 Vault 는 자격 증명 보안의 “두뇌” 역할입니다. 에이전트는 Vault에서 직접 비밀번호를 받지 않고 권한을 부여받아, 유출 위험이 있어도 곧 만료되고 진짜 키는 안전합니다.
Manus 는 사용자 중심 제어와 기기 간 안전한 세션 재생으로, 실용적이고 혁신적인 에이전트 로그인을 제시하고 있습니다. 한 발짝 전진이자 동시에, 로그인 흐름이 얼마나 민감한가를 상기시킵니다. 리플레이 공격, 샌드박스 이슈, 키 관리 등은 여전히 세심하게 다뤄야 할 주제입니다.
미래는 분명합니다: 에이전트가 더 많은 일을 대행하게 되지만, 이를 안전하게 하려면 자격 증명이 필수입니다. Vault 와 같은 도구는 시크릿 관리뿐 아니라 신뢰 보장에도 중요한 역할을 하게 될 것입니다.
AI 가 내 디지털 삶의 열쇠를 갖게 될 땐, 누가 그것을 나눠줬는지, 얼마나 쓸 수 있는지, 그 열쇠로 어디를 열 수 있는지 알아야 합니다.
Logto 는 외부 서비스(구글 소셜 계정, 원격 MCP 서버 등) 액세스를 위한 3rd 파티 API 토큰을 안전하게 저장하는 Vault 를 곧 도입할 예정입니다. 앞으로는 사용자 자격 증명, 키, 기타 민감 정보까지 보관 범위를 넓힐 계획입니다.
동시에 Logto 는 완전한 인증/인가/아이덴티티 관리 플랫폼이기도 합니다. 만약 AI 에이전트를 처음부터 구축 중이라면, Logto 는 AI 개발자를 위해 맞춤 설계되었습니다. 에이전트 기반 환경에서 아이덴티티를 관리할 때 필요한 보안, 유연성, 인프라를 모두 제공합니다.