저장된 비밀번호는 대화에 쓰지 않고, 허용된 자동 입력으로 로그인에 사용한다.
3장에서 모델을 연결했다면 이제 로그인된 웹에서 할 일을 준비할 차례다. 여기서 가장 먼저 떠오르는 질문은 단순하다. AI에게 사이트 일을 맡기려면 비밀번호도 알려 줘야 할까? 어사이드의 Aside Vault는 비밀번호 원문을 에이전트에 전달하지 않고 로그인 양식에 자동 입력하는 방식을 안내한다. 이번 장에서는 그 방식과 접근 정책, 추가 인증, 로그인 이후의 확인 범위를 나눠 살펴본다.
4.1 비밀번호를 모르는 AI가 어떻게 로그인할까?
사람이 직접 로그인할 때도 비밀번호를 매번 읽거나 외워서 입력하지는 않는다. 비밀번호 관리자가 사이트에 맞는 항목을 찾아 채워 주면 사람은 로그인 결과를 확인한다. 어사이드가 설명하는 방식도 이 구분에서 이해할 수 있다. 에이전트는 로그인 동작을 요청하고, 비밀번호 관리자는 대상 주소와 접근 설정을 확인한 뒤 허용된 항목을 웹사이트에 채운다. 공식 문서는 이 과정에서 에이전트가 저장된 비밀번호 원문을 받지 않는다고 밝힌다. 핵심은 비밀 문자열을 대화로 전달하는 대신, 정해진 조건 아래 자격 증명을 사용하는 동작을 허용한다는 데 있다.
다만 “비밀번호를 AI가 보지 않는다”는 설명은 저장된 비밀번호를 자동 입력하는 경로에 관한 것이다. 사용자가 비밀번호를 채팅에 직접 붙여 넣거나, 비밀값이 드러난 화면을 캡처해 보내는 행위까지 같은 보호를 받는다는 뜻은 아니다. 또 로그인한 뒤의 화면에는 계정 정보나 업무 자료가 나타날 수 있다. 비밀번호 원문을 감추는 기능과 로그인 이후 무엇을 읽고 처리하게 할지는 별개의 문제다. 두 범위를 구분하면 이 기능을 과장하지 않고 유용하게 사용할 수 있다.
4.2 로그인 준비에서 무엇을 먼저 확인할까?
첫 번째는 대상 사이트다. 평소 이용하던 공식 주소나 직접 확인한 북마크에서 출발한다. 로그인 화면처럼 보인다는 이유만으로 저장 항목을 채우도록 요청하지 않는다. 공식 안내에 따르면 Aside는 로그인 항목의 자동 입력 데이터를 준비하기 전에 대상 URL을 확인한다. 사용자도 서비스 이름만 보지 말고 주소와 계정의 관계를 함께 확인하면 된다.
두 번째는 계정이다. 개인용과 업무용 계정이 함께 있다면 “업무용 계정으로, 특정 프로젝트 목록만 확인해 줘”처럼 역할과 범위를 덧붙인다. 계정을 특정하기 위해 비밀번호를 전달할 필요는 없다. 여러 항목이 맞을 수 있으면 선택 전에 확인해 달라는 조건을 넣는다.
4.3 자동 입력과 AI 접근 정책은 어디서 설정할까?
기본 설정 위치는 Settings > Passwords다. 공식 도움말은 기본 비밀번호 관리자 선택, Autofill, URL 일치 방식, Excluded domains를 이곳에서 확인하도록 안내한다. Aside가 비밀번호를 관리하게 하려면 Use default password manager 설정도 함께 살펴본다. 제외한 도메인에서는 채우지 않도록 관리할 수 있으므로, 자동 입력이 보이지 않을 때 저장 항목이 없다고 바로 결론 내리기보다 이 설정을 먼저 확인한다.
AI가 저장 항목을 사용할 수 있는 조건은 Settings > Passwords > Access policy for AI agents에서 정한다. 공식 문서에 나오는 선택지는 Always allow, While unlocked, Never다. 이 정책은 비밀번호를 에이전트에 읽어 주는 설정이 아니라 저장된 자격 증명을 사용할 수 있는 조건을 정하는 설정이다. 자동 입력 기능이 켜져 있다는 사실과 에이전트 사용이 허용돼 있다는 사실을 하나로 취급하지 않는 것이 중요하다.
| 정책 | 의미 | 함께 볼 조건 |
|---|---|---|
| Always allow | 잠금 해제 상태만으로 제한하지 않고 에이전트의 저장 항목 사용을 허용하는 정책 | 대상 URL과 항목별 정책 등 다른 조건도 적용 |
| While unlocked | 보관함이 잠금 해제된 동안 사용 허용 | 사용 시점에 보관함이 열려 있는지 |
| Never | 에이전트의 저장 항목 사용을 허용하지 않음 | 이미 로그인된 사이트의 세션과는 별개 |
공식 도움말의 기본값은 Always allow다. 다만 직접 바꾼 설정이나 가져온 항목별 정책이 있을 수 있으므로 현재 값을 확인한다. 문서는 가져온 항목이 전역 정책을 항목별로 덮어쓸 수 있다고 설명한다. 전체 정책과 실제 사용할 항목의 조건을 함께 살펴본다.
처음 로그인 작업을 익히는 사람이라면 While unlocked를 검토할 수 있다. 보관함을 잠금 해제한 상태에서만 에이전트가 저장 항목을 사용할 수 있도록 경계를 두는 선택이다. 이는 모든 사람에게 적용할 정답이나 이 책이 대신 변경한 설정이 아니다. 사람이 자리를 비운 동안에도 로그인이 필요한 업무라면 실행 조건과 편의의 균형을 별도로 판단해야 한다. 아직 로그인 작업을 맡기지 않으려면 Never를 선택하는 방법도 있다. 기능을 쓸지 말지뿐 아니라 언제 쓸 수 있게 할지를 정하는 과정으로 이해하자.
Never는 저장된 비밀번호 관리자 항목을 에이전트가 사용하는 것을 제한하는 정책이지, 이미 로그인된 웹사이트에서 자동으로 로그아웃시키는 명령은 아니다. 화면 접근과 업무 수행 범위까지 제한하려면 작업 권한과 사이트 세션을 별도로 살펴봐야 한다. 보관함 접근, 브라우저의 로그인 상태, 로그인 후 행동을 세 가지로 나눠 보면 설정의 목적을 혼동하지 않을 수 있다.
4.4 Touch ID와 추가 인증은 어떤 역할을 할까?
공식 Vault 안내는 지원 기기에서 macOS의 Touch ID와 Windows의 Windows Hello로 보관함을 잠금 해제할 수 있다고 설명한다. 지원되는 기기에서 처음 잠금을 해제할 때 설정 안내가 나타나며 Enable을 선택해 설정하거나 Not now로 미룰 수 있다. 나중에 Settings > Passwords에서 켤 수도 있다. 이번 장에서는 실제 기기의 생체 인증 설정을 변경하지 않고 공식 절차만 안내한다.
생체 인증은 보관함을 여는 방법이다. 열고 난 뒤 에이전트가 무엇을 할 수 있는지를 결정하는 접근 정책과는 다르다. 공식 문서도 While unlocked 정책은 잠금을 어떤 방식으로 해제했든 그대로 적용된다고 설명한다. 따라서 Touch ID를 쓴다는 사실만으로 매번 모든 로그인에 지문 승인이 필요하다고 해석해서도 안 되고, 반대로 한 번 인증했으니 이후 모든 동작이 허용된다고 해석해서도 안 된다. 보관함 잠금 해제와 웹사이트 인증, 작업 승인은 각각 확인할 대상이다.
웹사이트가 요구하는 추가 인증도 따로 있다. MFA는 비밀번호 외에 추가 수단으로 본인임을 확인하는 절차다. 기기 승인, 패스키 확인, 일회용 코드 입력 등 사이트마다 방식이 다르다. Aside Vault는 사이트가 요청하는 패스키·FIDO2·TOTP 관련 흐름을 지원한다고 안내하지만, 이것이 모든 사이트의 인증을 사람 없이 완료한다는 보장은 아니다. 공식 도움말도 추가 인증이나 본인 확인 때문에 사용자의 단계가 필요할 수 있다고 설명한다.
사용자의 인증이 필요하면 요청된 동작을 확인하고 해당 기기나 공식 화면에서 처리한다. 원격 작업에서도 이런 단계가 생길 수 있다. 인증 수단을 사용할 수 없을 때는 보안 기능을 끄거나 우회하기보다 사람이 확인할 단계로 남겨 둔다.
4.5 기존 비밀번호 관리자는 꼭 바꿔야 할까?
기존 관리자를 쓰는 독자는 “Aside Vault로 가져오기”와 “외부 관리자를 계속 사용하기”를 구분해서 보면 된다. 가져오기는 보관된 항목을 Aside 쪽에 옮기는 절차이고, 외부 관리자 확장을 사용하는 것은 원래 관리자의 동작을 어사이드 브라우저 안에서 이용하는 경로다. 가져오기 목록에 이름이 있다고 해서 그 제품과의 실시간 동기화나 모든 에이전트 동작이 보장된다는 뜻은 아니다. 자신이 선택한 경로에서 잠금 해제, 자동 입력, 접근 허용을 각각 확인해야 한다.
공식 가져오기 목록에는 1Password, Apple Passwords, Bitwarden, Chrome, Dashlane, Edge, Firefox, LastPass CSV, 일반 CSV가 나온다. 경로는 Settings > Passwords > Import다. 원래 관리자에서 내보낸 뒤 가져오기 출처와 파일을 선택하고 결과를 검토하는 순서로 안내돼 있다. 화면이 출처별 추가 절차를 요청하면 그 안내를 따른다. 모든 출처의 형식을 하나의 CSV 구조로 바꿔야 한다고 가정하지 않는다.
비밀번호 내보내기 파일은 특히 조심해서 다룬다. 형식에 따라 비밀번호 원문이 담길 수 있으므로 이메일 첨부, 공개 공유 폴더, 일반 채팅으로 전달하지 않는다. 가져오기가 끝나면 필요한 항목과 사이트 주소가 옮겨졌는지 확인하고, 파일을 계속 보관할 이유가 있는지 판단한다. 백업이 필요하다면 보호된 위치와 접근 범위를 정하고, 필요 없는 임시 내보내기 파일은 정리한다. 파일을 휴지통에 넣었다는 사실만으로 클라우드 사본이나 백업까지 모두 없어졌다고 가정하지 않는 것도 중요하다.
외부 관리자 확장에 관한 별도 안내도 있다. 공식 문제 해결 문서는 1Password 확장이 동작하지 않을 때 1Password 앱에서 Aside를 추가 브라우저로 등록하고 연결 파일을 확인하는 절차를 설명한다. Apple Passwords 확장 문제에는 해당 스킬로 연결 상태를 확인하도록 요청하는 방법을 제시한다. 이는 문제가 있을 때 참고할 경로이지, 정상 작동하는 관리자를 모든 독자가 바꿔야 한다는 뜻은 아니다. 이 장에서는 외부 확장을 새로 설치하거나 개인 보관함을 옮기지 않았다.
동기화와 로컬 저장도 구분한다. 공식 설정 안내는 보관함 데이터를 암호화한 뒤 동기화한다고 설명하고, 개인정보처리방침은 동기화를 켜면 암호화된 보관함 기록이 동기화 시스템에 저장된다고 밝힌다. 따라서 저장 비밀번호를 AI에 보여 주지 않는다는 설명을 “어떤 형태의 데이터도 기기 밖으로 나가지 않는다”는 뜻으로 확대하지 않는다.
가져오기 메뉴 가까이에 있더라도 Clear vault data는 가져오기 실패를 가볍게 되돌리는 버튼으로 생각하면 안 된다. 공식 안내에 따르면 로컬 항목과 보관함 키, 보관함을 삭제하고 새 Personal 보관함을 만든 뒤 초기화 상태를 동기화한다. 문제가 생겼을 때는 먼저 대상과 설정을 확인하고, 삭제나 초기화는 복구 방법과 영향을 이해한 뒤 별도로 결정한다.
4.6 자동 입력이 안 되면 어떤 순서로 볼까?
로그인 화면에서 진행되지 않는다고 해서 곧바로 비밀번호를 대화에 적을 필요는 없다. 먼저 어디에서 멈췄는지 나눈다. 저장 항목을 찾지 못한 것인지, 정책 때문에 사용할 수 없는 것인지, 입력은 됐지만 추가 인증을 기다리는 것인지에 따라 다음 단계가 다르다. 아래 표는 비밀번호를 노출하지 않고 확인할 순서다.
| 확인 순서 | 비밀값 없이 살펴볼 것 |
|---|---|
| 1. 대상과 계정 | 공식 주소인지, 지정한 계정이나 작업 공간이 맞는지 |
| 2. 관리자와 자동 입력 | 선택한 기본 관리자, Autofill, Excluded domains, URL 일치 조건 |
| 3. AI 접근 조건 | Always allow / While unlocked / Never 및 항목별 정책 |
| 4. 보관함과 세션 | 필요한 잠금 해제 여부, 시크릿 세션인지 |
| 5. 사이트 추가 인증 | 패스키·MFA·본인 확인 등 사용자가 처리할 단계인지 |
| 6. 로그인 후 결과 | 의도한 계정의 페이지에 도달했는지, 요청 범위 안인지 |
시크릿 모드는 특히 두 설명을 구분해야 한다. 비밀번호 설정에는 시크릿 창에서 자동 입력을 허용할지 정하는 항목이 있지만, 공식 문서는 에이전트가 시크릿 세션에서 비밀번호 관리자 접근을 사용할 수 없다고 별도로 명시한다. 자동 입력 옵션 하나를 켜면 에이전트 접근 제한도 함께 풀린다고 해석하지 않는다. 로그인 작업을 설계할 때는 창의 모드와 에이전트의 사용 조건을 함께 확인한다.
4.7 로그인 사용 기록과 업무 결과는 어떻게 확인할까?
공식 Vault 소개는 자격 증명의 사용 기록을 남기며 무엇을 언제 왜 사용했는지 확인할 수 있다고 설명한다. 이 기능은 어떤 로그인 항목이 업무에 쓰였는지 돌아보는 데 의미가 있다. 다만 이번 집필에서는 개인 접근 기록 화면을 열어 실제 표시 항목이나 메뉴 위치까지 실측하지 않았다. 따라서 존재를 확인한 공식 기능 설명과 실제 계정에서 확인해야 할 기록 화면을 구분한다. 이 책에 개인 로그처럼 보이는 가상 캡처를 넣지 않는 이유이기도 하다.
자격 증명을 사용한 기록과 업무 완료는 다른 증거다. 자동 입력이 이루어져도 인증 오류가 날 수 있고, 로그인에 성공해도 잘못된 계정의 화면이거나 필요한 자료가 없는 경우가 있다. 따라서 로그인 후에는 올바른 계정과 페이지인지, 요청한 항목이 실제로 확인됐는지를 살펴본다. “로그인 버튼을 눌렀다”보다 “지정한 계정의 목록에서 요청한 항목을 확인했다”가 사용자가 필요한 결과에 가깝다.
4.8 로그인 허용은 어디까지의 허용일까?
로그인을 맡겼다는 것은 그 계정으로 가능한 모든 행동을 승인했다는 뜻이 아니다. 예를 들어 청구 내역을 확인하는 일과 결제 수단을 바꾸는 일, 답변을 초안으로 만드는 일과 고객에게 보내는 일은 구분해야 한다. 요청에 조회할 대상과 결과를 적고, 게시·발송·결제·설정 변경 전에 멈출 조건을 함께 두면 일을 이어 가면서도 중요한 결정은 사용자가 잡을 수 있다.
비밀번호 접근 정책 외에도 작업 권한이 있다. 공식 보안 문서는 도구의 Allow·Ask·Deny 규칙과 작업별 권한을 구분하고, Deny가 Ask와 Allow보다 우선한다고 설명한다. Full access는 파일 접근 범위를 넓히는 모드이지 저장된 비밀번호 원문을 에이전트에 보여 주는 옵션이 아니다. 다만 요청문에 “승인해 달라”고 적는 것과 제품의 권한 설정을 구성하는 것은 같은 조작이 아니다. 필요한 동작을 실제로 제한하는 규칙은 11장에서 더 자세히 다룬다.
로그인된 화면의 자료도 별도로 판단해야 한다. 개인정보처리방침은 호스팅된 모델 제공자에게 작업에 필요한 문맥이 전달될 수 있다고 밝힌다. 따라서 비밀번호가 에이전트에 보이지 않는다고 해서 이후 읽는 고객 자료나 문서까지 모두 외부 처리와 무관하다는 뜻은 아니다. 업무에 필요한 항목만 요청하고 조직의 자료 처리 규칙을 적용한다. 비밀번호 보호는 중요한 출발점이지만 전체 업무의 정보 보호를 대신하지 않는다.
4.9 첫 로그인 과제는 작고 분명하게
첫 과제는 허용된 계정에서 민감하지 않은 목록을 읽는 일로 잡는다. 기존 사이트 하나의 정확한 주소, 계정 역할, 읽을 항목을 정한다. 처음부터 다른 사람의 계정이나 결제·개인정보가 많은 화면으로 범위를 넓히지 않는다.
내가 지정한 사이트의 업무용 계정으로 접속해 줘. 이미 로그인돼 있으면 계정과 작업 공간부터 확인해 줘. 새 로그인이 필요하면 허용된 저장 항목으로 자동 입력해 줘. 여러 계정이 맞을 수 있으면 선택 전에 물어봐 줘. 비밀번호나 인증 코드를 답변에 표시하지 마. 내 확인이 필요한 인증 단계에서는 멈추고 알려 줘. 공지 목록의 제목과 날짜만 표로 정리해 줘. 게시·발송·결제·계정 설정 변경은 하지 마.
결과를 받으면 사이트와 계정, 지정한 목록이 맞는지 확인한다. 인증을 기다린다면 사용자가 처리할 단계인지 살펴본다. 확인할 수 없는 부분은 미확인으로 남긴다. 위 예시는 독자용 요청 틀이며 집필 중 개인 계정에서 실습한 기록은 아니다.
이번 장의 핵심은 비밀번호를 AI와 공유하는 대신 사용할 조건을 정하는 것이다. 사이트와 계정, 보관함 접근 정책, 추가 인증, 로그인 후 행동을 구분하면 로그인된 웹에서 일을 맡기는 범위가 더 명확해진다. 다음 장에서는 한 번 설명한 업무 맥락을 이어 가는 메모리를 살펴본다. 비밀번호 같은 비밀값을 기억시키는 것이 아니라, 반복해서 필요한 업무의 기준을 정리하는 방법이다.
확인한 공식 자료
2026년 9월 26일 확인. Aside Vault와 AI 접근 정책 · 자동 입력·가져오기·동기화 설정 · 작업 권한과 비밀번호 경계 · 추가 인증과 외부 관리자 문제 해결 · Vault 공식 기능 소개 · 개인정보처리방침. 화면과 지원 범위는 업데이트로 달라질 수 있다.
다음 글: 5장 · 메모리: 맥락을 가르치는 법
이전 글: 3장 · 모델 연결과 크레딧
『Aside 브라우저 사용설명서』 연재 목록
공식 자료와 공개 화면을 확인하고 AI의 도움을 받아 작성·편집했습니다. 집필을 위해 개인 보관함·비밀번호·접근 기록을 열거나 설정을 변경하지 않았습니다. 암호화 구현을 독립적으로 검증한 보안 감사가 아닙니다. 초판 선공개 원고 v1.0.