macOS 27 Passwords 앱, 이제 해킹된 로그인을 자동으로 수정합니다

이제 Mac이 해킹된 비밀번호를 스스로 변경할 수 있습니다 -- 그리고 진짜 중요한 질문은 과연 그걸 허용해야 하는가입니다. 2026년 6월 8일 WWDC에서 Apple은 macOS 27 Golden Gate의 Passwords 앱에 에이전트 기능이 추가된다고 발표했습니다. 저장된 자격 증명이 취약하거나, 여러 사이트에서 재사용되거나, 데이터 침해로 노출된 것으로 감지되면, 단 하나의 버튼만 눌러도 Apple Intelligence가 Safari에서 해당 사이트를 열고, 저장된 자격 증명으로 로그인한 뒤, 비밀번호 변경 페이지로 이동하고, 강력한 새 비밀번호를 생성해 사이트에 저장하고, 보관함의 항목까지 업데이트해 줍니다 -- 단 한 글자도 직접 입력할 필요 없이 말입니다. "Apple Intelligence"라는 이름 아래 Apple이 출시한 것 중 가장 실질적으로 자율적인 기능이며, 동시에 보안을 중시하는 사용자라면 한 번쯤 멈추고 생각해봐야 할 기능이기도 합니다. 사용자 계정에 로그인하고 자격 증명을 다시 쓸 수 있는 어시스턴트는, 바로 그 능력 때문에 위험하기도 합니다. 이 가이드는 기능이 정확히 어떻게 작동하는지, 어떤 사이트에서 사용 가능하고 불가능한지, 양쪽의 실제 보안 트레이드오프, 그리고 기능 전체를 제어하거나 비활성화하는 방법을 설명합니다.

Key Takeaways

• macOS 27의 Passwords 앱은 취약하거나 유출된 비밀번호를 자동으로 변경할 수 있습니다. Apple은 2026년 6월 8일 WWDC에서 iOS 27, iPadOS 27과 함께 이 기능을 발표했습니다. 2024년부터 Passwords 앱에 탑재된 보안 권장 사항 기능을 기반으로 합니다.
• 이것은 "에이전트형" AI입니다. Apple Intelligence와 Safari를 통해 어시스턴트가 사이트를 열고, 기존 저장 자격 증명으로 로그인하고, 비밀번호 변경 페이지를 찾아 새 비밀번호를 생성하고 사이트에 적용한 뒤, 보관함을 업데이트합니다 -- 단순한 제안이 아니라 사용자를 대신해 여러 단계의 작업을 수행합니다.
• 지원 범위는 Apple만의 문제가 아니라 웹 표준에 달려 있습니다. .well-known/change-password URL 표준을 구현하고 로그인 및 비밀번호 변경 양식이 잘 구성된 사이트가 최적의 대상입니다. 오래된 포털, 맞춤형 인증 흐름, 필수 CAPTCHA나 2FA 단계가 있는 사이트는 여전히 수동 처리가 필요할 수 있습니다.
• 보안 논쟁은 실재하며 아직 해결되지 않았습니다. 장점은 유출된 비밀번호를 수초 내에 교체한다는 것이고, 단점은 더 넓어진 공격 표면, 피싱 리디렉션 위험, 부분 실패 시 불확실한 동작입니다. Apple은 온디바이스 처리, Private Cloud Compute, 사용자 트리거 방식을 안전 장치로 제시하지만, 운영상의 세부 사항 중 공개되지 않은 것이 여전히 많습니다.
• 제어권은 사용자에게 있습니다. 이 작업은 플래그 표시된 항목에만 나타나며, 사용자가 직접 실행해야 합니다. 언제든지 거부하고 수동으로 변경할 수 있습니다. Passwords 앱은 이 기능을 전혀 사용하지 않아도 일반 비밀번호 관리자로 계속 작동합니다. 더 넓은 Apple Intelligence 출시의 일환으로 가용성은 단계적으로 확대될 수 있습니다.

What the Feature Actually Is

macOS 27의 새로운 점을 이해하려면 먼저 기존에 무엇이 있었는지 알아야 합니다. Apple은 2024년 iOS 18과 macOS Sequoia 15에서 독립적인 Passwords 앱을 출시하며 비밀번호 관리 기능을 설정 앱의 iCloud Keychain 섹션에서 전용 1급 앱으로 격상시켰습니다. 이 앱에는 이미 보안 권장 사항 섹션이 포함되어 있었는데, 저장된 자격 증명을 검사하고 세 가지 문제를 플래그 처리합니다. 짧거나 예측 가능하거나 엔트로피가 낮은 취약한 비밀번호, 여러 사이트에서 재사용된 비밀번호, 알려진 데이터 침해에 등장한 비밀번호입니다. 마지막 항목은 실제 비밀번호를 Apple에 읽기 가능한 형태로 보내지 않는 개인정보 보호 방식으로 유출된 비밀번호 목록과 비교해 확인합니다.

2024년 Passwords 앱이 하지 않았던 것은 문제를 직접 해결해 주는 것이었습니다. 은행 비밀번호가 다른 세 사이트에서 재사용되고 있다거나, 예전 포럼 로그인이 침해 사례에서 발견됐다고 알려줄 뿐, 실제 작업은 사용자에게 맡겼습니다. 사이트에 접속하고, 로그인하고, 계정 설정을 찾고, 비밀번호 변경 양식을 찾아서, 새 비밀번호를 생각해 내거나 앱의 제안을 받아 저장해야 했습니다. 대부분의 사람들에게 이 번거로움은 경고가 그냥 쌓여가는 이유가 되었고, 아무도 실행에 옮기지 않은 플래그 비밀번호 목록은 아무에게도 보안상 이점을 주지 못했습니다.

macOS 27의 업그레이드는 바로 그 간격을 메우는 부분입니다. Apple은 이를 취약하거나 유출된 비밀번호를 자동으로 수정하는 기능으로 설명합니다. 할 일 목록을 건네는 경고 대신, 플래그 표시된 항목에 이제 모든 작업을 대신 처리해 주는 버튼이 생겼습니다. Apple은 이를 보안 권장 사항의 자연스러운 진화로 표현합니다. 앱이 이미 어떤 비밀번호가 나쁜지 알고 있었으므로, 논리적인 다음 단계는 그것을 수리하게 하는 것이었습니다. 그 버튼 뒤의 메커니즘이 이 기능을 놀랍게 만들면서 동시에 논쟁을 일으키는 이유입니다.

이것은 업계에서 현재 사용하는 정확한 의미의 "에이전트형 AI"입니다. 에이전트는 질문에 답하는 챗봇이 아니라, 목표를 달성하기 위해 세상에서 일련의 행동을 취하는 시스템입니다. 항공편 예약, 경비 보고서 제출, 또는 이 경우처럼 실제 웹사이트에서 비밀번호 변경 -- 이 모든 것은 인터페이스를 탐색하고, 각 단계에서 결정을 내리고, 예상대로 되지 않을 때 회복해야 하기 때문에 에이전트형 작업입니다. macOS 27의 비밀번호 기능은 Apple이 출시한 최초의 소비자용 에이전트 기능 중 하나이며, 상상할 수 있는 가장 민감한 장소인 자격 증명 보관함 안에 자리 잡고 있습니다.

How the Agentic Auto-Change Works, Step by Step

Apple에 따르면 자동 변경 기능은 Apple Intelligence와 Safari를 함께 조율하여 작동합니다. 다음은 Apple이 설명한 대로, 에이전트가 사용자를 대신해 수행하는 개별 단계로 나눈 순서입니다.

1단계 -- 감지. 기존의 보안 권장 사항 엔진입니다. Passwords 앱은 저장된 자격 증명을 취약, 재사용, 침해 기준으로 지속적으로 평가하고 보안 섹션에 문제 항목을 표시합니다. 여기서 새로운 것은 없습니다. 나머지를 가능하게 하는 트리거입니다.

2단계 -- 사용자가 시작합니다. 중요한 점은 에이전트가 스스로 작동하지 않는다는 것입니다. 플래그 표시된 항목을 열면 자동으로 수정하는 옵션이 보입니다. 사용자가 그 버튼을 누릅니다. 이 인간 참여 트리거는 의도적인 설계 선택이며 Apple이 명시하는 핵심 안전 장치 중 하나입니다. 시스템은 결코 스스로 계정 로그인을 시작하기로 결정하지 않습니다.

3단계 -- Safari에서 사이트가 열립니다. 에이전트는 자격 증명과 연결된 웹사이트를 실행합니다. Apple이 Passwords 앱과 Safari 모두를 제어하기 때문에, 어시스턴트는 서드파티 앱을 스크립팅하는 대신 Apple 자체 브라우저 샌드박스 안에서 작동합니다.

4단계 -- 기존 자격 증명으로 로그인합니다. 에이전트는 보관함에 이미 저장된 현재 자격 증명 -- 오늘 앱이 자동 입력하는 것과 동일한 사용자 이름과 (유출된) 비밀번호 -- 을 사용해 인증합니다. 필요한 것을 이미 가지고 있으므로 사용자가 아무것도 입력할 필요가 없습니다.

5단계 -- 비밀번호 변경 페이지로 이동합니다. 이것이 어려운 부분이며, 웹 표준이 매우 중요한 부분입니다 (다음 섹션에서 자세히 다룹니다). 에이전트는 메뉴를 추측하며 탐색하는 대신 표준화된 URL을 따르는 방식으로 계정의 비밀번호 변경 인터페이스를 찾습니다.

6단계 -- 강력한 새 비밀번호를 생성합니다. 에이전트는 Passwords 앱이 이미 제공하는 보안 비밀번호 생성기와 동일한 것을 사용해 고엔트로피 대체 비밀번호를 생성하며, 감지 가능한 경우 사이트의 특정 요구 사항 (길이, 문자 종류 등)을 준수합니다.

7단계 -- 사이트에서 변경을 제출합니다. 에이전트는 비밀번호 변경 양식 -- 일반적으로 이전 비밀번호, 새 비밀번호, 확인 필드 -- 을 채우고 제출해 실제 서비스에서 변경을 완료합니다.

8단계 -- 보관함을 업데이트합니다. 마지막으로 에이전트는 새 비밀번호를 Passwords 앱 항목에 다시 기록하여 저장된 자격 증명이 사이트에서 실제로 사용되는 것과 일치하도록 합니다. 이 단계 없이는 계정에서 잠겨 나가게 되므로 흐름에 필수적입니다.

이 설계의 우아함은 개별 단계들이 이미 어떤 형태로든 존재했다는 점입니다 -- 자동 입력, 비밀번호 생성, 침해 감지, Safari 자동화 기본 요소 -- 그리고 에이전트 레이어가 단순히 이것들을 하나의 자율적인 순서로 연결합니다. 취약점은, 앞으로 보겠지만, 연결 고리 중 하나가 끊어지면 전체 프로세스가 불확실한 상태로 남을 수 있다는 것입니다.

The .well-known/change-password Standard and Which Sites Work

자동 변경 기능이 특정 사이트에서 작동하는지를 결정하는 가장 큰 단일 요소는 .well-known/change-password라는 작지만 실질적인 웹 표준입니다. 이것은 전체 기능의 기술적 핵심이며 종종 잘못 설명되기 때문에 정확하게 설명할 가치가 있습니다.

.well-known/ 디렉토리는 도메인 루트에 예약된 위치로, 더 넓은 IETF "well-known URIs" 프레임워크 (원래 RFC 5785 및 후속 문서)에 의해 정의됩니다. security.txt나 Apple App Site Association 파일을 지원하는 것과 동일한 메커니즘입니다. 아이디어는 단순합니다. 특정 표준화된 리소스는 항상 예측 가능한 경로에 존재하므로 소프트웨어가 어디서 찾아야 할지 추측할 필요가 없습니다. 알지 못하는 사이에 .well-known 경로를 거의 확실히 사용한 경험이 있을 것입니다.

특정 항목인 .well-known/change-password는 작은 사양 (W3C 커뮤니티 작업인 "비밀번호 변경을 위한 잘 알려진 URL")으로, 사이트가 이를 지원하면 https://example.com/.well-known/change-password에 요청했을 때 브라우저가 해당 사이트의 실제 비밀번호 변경 페이지로 리디렉션됩니다. 이것이 전체 표준입니다 -- 양식이 아니라 안내판입니다. 비밀번호를 직접 변경하지는 않습니다. 단지 비밀번호 관리자 (또는 이제는 에이전트)에게 그 작업을 위해 사용자를 어디로 보내야 하는지 알려줄 뿐입니다. Safari, Chrome, 그리고 여러 비밀번호 관리자들은 수년 전부터 이 URL 팔로우를 지원해 왔으며, 그 덕분에 기존 관리자가 올바른 설정 페이지로 바로 이동하는 "비밀번호 변경" 버튼을 제공하는 것을 보셨을 수도 있습니다.

macOS 27의 에이전트에게 이 표준은 신뢰할 수 있고 결정론적인 경로와 취약하고 화면을 긁는 추측 사이의 차이입니다. 사이트가 .well-known/change-password를 구현하면 에이전트는 비밀번호 변경 양식이 어디 있는지 정확히 알 수 있습니다. 구현하지 않으면 메뉴와 링크를 해석해 위치를 추론해야 하므로 훨씬 오류가 발생하기 쉽습니다. 따라서 현실적인 지원 범위는 대략 다음과 같이 구분됩니다:

사이트 특성	예상 결과
.well-known/change-password 구현, 표준적인 로그인 및 변경 양식, 흐름 중간에 필수 도전 없음	자동 작동 가능성 높음. 이 기능이 설계된 이상적인 경우.
Safari 자동 입력이 잘 통합된 주요 대형 서비스	자주 작동함. 잘 알려진 URL 없이도 잘 구조화된 양식을 사용하는 경향이 있음.
비밀번호 변경의 일부로 확인 이메일 또는 SMS 코드를 발송하는 사이트	중단되거나 수동 처리 필요 가능성 높음. 에이전트는 이메일이나 문자를 읽어 단계를 완료할 수 없음.
비밀번호 변경 흐름에 필수 CAPTCHA가 있는 사이트	실패 가능성 높음. CAPTCHA는 자동화된 에이전트를 차단하기 위해 존재함.
변경 중 2FA 프롬프트로 보호되는 계정	불확실함. Apple은 에이전트가 변경 도중 2FA 도전을 처리하는지, 처리한다면 어떻게 하는지 명시하지 않음.
오래된 포털, 소규모 포럼, 인트라넷 로그인, 맞춤형 또는 비표준 인증 흐름	수동 처리 필요 가능성 높음. 예측 불가능한 양식 구조가 자동화를 어렵게 함.
별도의 변경할 비밀번호가 없는 SSO 로그인 (예: "Google/Apple로 로그인")	해당 없음. 에이전트가 교체할 사이트별 비밀번호가 없음.

여기서 솔직한 표현은 고정된 목록이 아니라 범주 문제라는 것입니다. Apple은 공식적으로 지원되는 사이트 목록을 게시하지 않았으며, 우리가 임의로 만들어내지도 않겠습니다. 표준은 실재하고 이를 채택하는 주요 서비스들은 잘 작동할 가능성이 높습니다. 웹의 긴 꼬리는 이전의 모든 자동 비밀번호 변경 시도와 마찬가지로 들쑥날쑥할 것입니다.

Where the Feature Lives and How to Trigger It

자동 변경 작업은 별도의 앱이나 새 메뉴가 아닙니다. 이미 가지고 있는 Passwords 앱의 보안 영역 안에 있습니다. macOS 27에서 찾아서 사용하는 방법:

1. Passwords 앱을 엽니다 (응용 프로그램 폴더와 메뉴 막대 Spotlight 검색에 있습니다).
2. 앱이 항상 요구하듯이 Touch ID, Apple 계정 비밀번호, 또는 Mac 로그인 비밀번호로 인증합니다.
3. 사이드바에서 보안을 선택합니다. 이전에 "보안 권장 사항" 주위로 표시되던 섹션으로, 앱이 취약하거나 재사용되거나 데이터 유출에서 발견된 것으로 플래그 처리한 모든 자격 증명이 나열됩니다.
4. 플래그 표시된 항목을 클릭합니다. 플래그 처리된 이유에 대한 기존 설명 옆에 자동 수정 옵션이 보입니다.
5. 자동 변경을 시작하고 에이전트를 실행합니다. Safari가 단계를 수행하는 동안 전면에 나타나므로 진행 상황을 볼 수 있습니다.
6. 완료되면 항목의 경고가 지워지고 새 비밀번호가 이미 저장됩니다.

Apple이 이것을 모든 자격 증명에 노출하지 않고 기존 보안 섹션 뒤에 배치하기 때문에, 실제로 주의가 필요한 비밀번호에만 자동 변경이 제공됩니다. 전체 보관함에 걸쳐 한 번에 에이전트를 실행하는 "모두 변경" 버튼은 없으며, 이는 중요성을 감안할 때 합리적인 제약입니다.

더 넓은 출시 맥락도 언급할 가치가 있습니다. 에이전트형 비밀번호 기능은 macOS 27의 더 큰 Apple Intelligence 추진의 일환이며, Apple의 Apple Intelligence 기능은 역사적으로 단계적으로 출시되어 왔습니다. 개선된 대화형 Siri 같은 일부 기능은 대기 목록과 영어 우선, 지역 제한 출시 방식을 따랐습니다. 자동 변경 기능이 공개 출시 첫날 모든 적격 Mac에 즉시 제공된다고 가정하지 않는 것이 좋습니다. 가용성은 보장된 출시일 기능이 아니라 단계적 Apple Intelligence 확대의 일부로 취급하세요.

What Happens on Unsupported Sites

모든 플래그 표시된 비밀번호가 자동으로 수정 가능한 것은 아니며, 작업을 완료할 수 없을 때 기능이 어떻게 동작하는지가 더 중요한 실용적인 질문 중 하나입니다. 흐름이 구성된 방식을 기반으로, 지원되지 않거나 불완전한 시도는 몇 가지 다른 상태로 끝날 수 있으며, 각각을 어떻게 인식하는지 알아야 합니다.

가장 깔끔한 실패는 에이전트가 비밀번호 변경 양식을 찾거나 조작할 수 없는 경우입니다 -- 예를 들어 인식할 수 있는 것과 일치하지 않는 맞춤형 인증 흐름이 있는 사이트. 이 경우 예상되는 동작은 에이전트가 아무것도 변경하지 않고 중지되고, 원래 (유출된) 비밀번호가 사이트와 보관함 모두에 그대로 남아 있으며, 수동으로 변경해야 하는 상황이 됩니다. 이것은 아무것도 일치하지 않는 게 없어서 "안전한 실패"입니다. 단지 전보다 나아지지 않았을 뿐입니다.

더 까다로운 시나리오는 흐름 중간에 중단되는 경우입니다. 에이전트가 변경을 성공적으로 시작했지만 사이트가 제공할 수 없는 것을 요구하는 경우 -- 이메일 인증 코드, SMS 일회성 패스코드, CAPTCHA, 또는 2FA 프롬프트. 여기서 중요한 것은 도전 이전 또는 이후에 사이트가 변경을 커밋했는지 여부입니다. 비밀번호 변경 양식이 새 비밀번호를 수락하기 전에 도전을 요구한다면 변경이 진행되지 않고 안전한 상태로 돌아갑니다. 사이트가 잘못 설계되어 새 비밀번호는 수락되었지만 후속 확인이 필요한 경우, 이론적으로 사이트와 보관함이 불일치할 수 있는 시간대가 생깁니다.

이것이 바로 Apple이 충분한 세부 사항을 공개하지 않은 부분이며, 솔직히 말씀드리겠습니다. 부분 실패에 대한 문서화된 동작, 롤백 또는 재시도 메커니즘의 존재, 앱이 정확히 무엇을 변경했는지에 대한 감사 이력 여부 -- 이 모든 것이 현재 작성 시점에서 미해결 질문입니다. Apple이 명확히 할 때까지, 지원되지 않거나 중단된 사이트에서의 실용적인 방어 조치는 보관함의 항목이 올바르다고 신뢰하기 전에 직접 변경을 확인하는 것입니다 -- 새 비밀번호로 로그아웃 후 다시 로그인하거나, 사이트 자체의 "비밀번호 찾기" 복구를 정상 확인으로 사용하는 방법을 쓰세요.

The Security Case For It

이 기능을 순전히 위험 요소로만 취급하는 것은 실수입니다. 자동 비밀번호 변경에 찬성하는 보안 논거는 강력하며, 사람들이 자격 증명을 관리하는 방식에서 측정 가능한 실제 문제를 다룹니다.

유출된 비밀번호의 핵심 문제는 감지가 아닙니다 -- 침해 모니터링 도구는 몇 년 전부터 이를 잘 해왔습니다 -- 문제는 수정까지의 시간입니다. 비밀번호가 유출되면 활성 상태로 남아있는 매 시간이 공격자가 사용할 수 있는 시간이 됩니다. 특히 유출된 사용자 이름-비밀번호 쌍을 자동으로 수백 개의 다른 사이트에 대해 시도하는 자격 증명 채우기 공격에 취약합니다. 위험한 간격은 "비밀번호가 유출되었다는 통보를 받은 시점"과 "실제로 변경한 시점" 사이입니다. 대부분의 사용자에게 그 간격은 몇 시간이 아니라 몇 주, 몇 달, 또는 영원히가 됩니다. 수동 변경 과정이 귀찮아서 결국 하지 않기 때문입니다.

변경을 자동화하면 그 간격이 "언젠가 할 것"에서 "버튼을 누른 순간"으로 좁혀집니다. 이것은 진정하고 정당한 보안상의 이점입니다. 감지 후 수초 내에 적용된 강력하고 고유한 기계 생성 비밀번호는 조치되지 않은 경고보다 극적으로 낫습니다. 같은 논리가 재사용된 비밀번호에도 적용됩니다. 재사용된 비밀번호는 취약한 것보다 더 큰 시스템적 위험이라고 할 수 있습니다. 재사용된 단일 비밀번호는 하나의 침해를 공유 계정 모두의 마스터 키로 만들고, 자동 변경 기능은 그 자격 증명을 중복 제거하는 것을 거의 마찰 없이 만듭니다.

행동 배당도 있습니다. 마찰은 좋은 보안 위생의 적입니다. 모든 보안 전문가는 사람들이 따르지 않을 가장 안전한 프로세스가, 실제로 사용하는 약간 덜 안전한 프로세스보다 나쁘다는 것을 알고 있습니다. 나쁜 비밀번호를 교체할 때의 거의 모든 마찰을 제거함으로써, Apple은 더 많은 비밀번호가 실제로 수정될 것이라는 데 베팅하고 있습니다 -- 그리고 인구 규모에서 그 베팅은 아마 맞을 것입니다. 이 기능의 존재가 개별 변경을 수동으로 하는 것보다 더 안전하게 만들지는 않습니다. 변경이 실제로 일어나게 만드는 것이며, 대부분의 사용자에게 그것이 전체 싸움입니다.

The Security Concerns Against It

이제 반대 측으로, 보안 회의론적 렌즈가 그 역할을 하는 곳입니다. 발표 이후 보안 해설에서 여러 타당한 우려가 제기되었으며, 어느 것도 과도한 걱정이 아닙니다.

공격 표면이 커집니다. 자격 증명을 보유하고, 계정에 로그인할 수 있고, 자격 증명을 다시 쓸 수 있는 자율 에이전트를 도입하는 것 -- 그리고 그것에 사용자를 대신해 그렇게 할 권한을 부여하는 것입니다. 그렇게 강력한 능력은 정의상 고가치 표적입니다. 공격자가 에이전트를 장악하거나 잘못 행동하도록 속일 수 있다면 폭발 반경이 엄청납니다. 한 계정이 아니라 잠재적으로 전체 디지털 생활의 열쇠입니다. 이 기능이 이 위험을 아무것도 없는 곳에서 만들어내는 것은 아닙니다 (비밀번호 관리자는 이미 자격 증명을 보유합니다), 하지만 자격 증명에 행동하는 에이전트는 단순히 저장하는 보관함보다 의미 있게 더 큰 표적입니다.

피싱과 리디렉션 위험. 에이전트의 역할은 비밀번호 변경 페이지로 이동해 이전 및 새 비밀번호를 입력하는 것입니다. 손상된 DNS 항목, 악성 광고 네트워크, 하이재킹된 링크, 또는 교묘하게 오염된 .well-known 응답으로 인해 올바른 비밀번호 변경 양식처럼 보이지만 공격자가 제어하는 페이지로 리디렉션된다면 어떻게 될까요? 자동화된 에이전트가 피싱 양식에 현재 비밀번호를 입력하는 것은 어떤 면에서 인간보다 더 위험합니다. 빠르게 움직이는 에이전트가 잠시 멈추지 않을 수도 있는 반면, 인간은 주소 표시줄에서 잘못된 도메인을 알아챌 수 있기 때문입니다. 에이전트가 자격 증명을 입력하기 전에 모든 단계에서 진짜 예상된 도메인에 있는지 확인하는 방식이 얼마나 견고한지는 중요한 보안 속성이며, Apple이 완전히 상세하게 설명하지 않은 것입니다.

부분 실패 모호성. 위에서 논의한 바와 같이, 도중에 멈추는 에이전트 프로세스는 계정을 불확실한 상태로 남길 수 있습니다 -- 사이트에서는 변경되었지만 보관함에서는 그렇지 않거나, 또는 반대의 경우. 에이전트가 무엇을 했는지에 대한 명확하고 문서화된 감사 추적과 신뢰할 수 있는 복구 경로 없이는, 실패한 자동 변경이 최악의 순간에 중요한 계정에서 잠겨 나가게 만들 수 있습니다. 자동화의 편리함은 양날의 검입니다. 인간이 비밀번호를 변경하다 문제가 생기면 입력한 것을 기억하지만, 에이전트가 조용히 처리하면 새 비밀번호가 무엇이었는지조차 알지 못할 수 있습니다.

2FA 문제. 이중 인증은 유출된 비밀번호가 가능하게 하는 정확히 그 자격 증명 채우기 공격에 대한 가장 효과적인 단일 방어 수단입니다. 하지만 2FA 도전은 자동화된 에이전트가 어려움을 겪는 정확한 종류의 단계이기도 합니다. 기능이 변경 흐름에 2FA 도전이 없는 계정에서만 원활하게 작동한다면, 어색한 아이러니가 있습니다. 가장 필요성이 낮은 계정에서 가장 유능하고, 강력한 보호가 가장 중요한 계정에서 가장 막힐 가능성이 높습니다. Apple은 에이전트가 2FA와 어떻게 상호 작용하는지 명확히 하지 않았으며, 그 모호함은 기대를 제어해야 합니다.

이러한 우려 중 어느 것도 기능을 전면 거부할 이유가 되지 않습니다. 눈을 뜨고 사용하고, 작업을 확인하고, 복구 옵션을 그대로 유지해야 할 이유들입니다 -- 아래에서 다루는 모범 사례입니다.

Apple's Stated Safeguards and the Honest Unknowns

Apple의 일반적인 Apple Intelligence 아키텍처는 여러 관련 보호 기능을 제공하며, 확인된 설계 속성과 합리적인 추론 중 어느 것인지 정확히 구분하는 것이 중요합니다.

Apple이 설계상 명시하는 것: Apple Intelligence는 가능한 한 많이 온디바이스에서 실행되며, 요청이 Mac이 로컬에서 처리할 수 있는 것보다 더 많은 컴퓨팅이 필요할 때는 Private Cloud Compute -- Apple에 따르면 데이터를 보유하지 않고 처리하며 소프트웨어 이미지를 독립적으로 감사할 수 있는 Apple의 서버 아키텍처 -- 로 전송됩니다. 비밀번호 에이전트는 기존 온디바이스 자격 증명을 사용하므로 Mac에 이미 있는 데이터에서 작동하며 비밀번호를 새로운 곳으로 전송하지 않습니다. 작업은 사용자 트리거 방식이며 절대 자율적이지 않아서 에이전트가 스스로 계정을 돌아다니지 않습니다. 그리고 무제한 자동화 스크립트가 아닌 Apple의 강화된 브라우저 환경인 Safari의 샌드박스 안에서 실행됩니다.

이것들은 실질적이고 의미 있는 안전 장치이며, 대부분의 서드파티 자동화가 역사적으로 제공해 온 것보다 더 많습니다. 하지만 Apple이 공개하지 않은 것에 대해서도 솔직해야 합니다. 격차가 정확히 회의론자가 집중해야 할 곳이기 때문입니다:

• 실패 동작. 부분적이거나 실패한 변경에 대한 문서화된 응답과 롤백이 있는지 여부가 불분명합니다.
• 2FA 처리. 에이전트가 이중 인증 도전을 포함하는 흐름을 완료하는지, 어떻게 완료하는지가 명시되지 않았습니다.
• 감사 및 이력. 앱이 어떤 계정을 언제 어떻게 변경했는지에 대한 검토 가능한 로그를 유지하는지 상세히 설명되지 않았습니다.
• 도메인 유효성 검사. 에이전트가 자격 증명을 입력하기 전에 진짜 비밀번호 변경 페이지에 있음을 확인하는 정확한 메커니즘이 완전히 설명되지 않았습니다.
• 복구. 새 비밀번호가 생성되어 보관함에 저장되었지만 사이트 측 오류로 인해 서비스에서 실제로 적용되지 않은 경우 액세스가 어떻게 되는지.

이것들을 답을 주장하는 것이 아니라 미해결 질문으로 표시합니다. Apple의 개인정보 보호 아키텍처 실적은 강력하며, 온디바이스와 Private Cloud Compute 기반은 대안보다 진정으로 낫습니다. 하지만 "기반이 탄탄하다"는 것이 "모든 운영 엣지 케이스가 잘 처리된다"는 것과 같지 않으며, 자격 증명을 다루는 기능에서 엣지 케이스가 실제 위험이 사는 곳입니다.

How It Compares to 1Password and Dashlane Auto-Change

Apple이 자동 비밀번호 변경을 처음 시도하는 것이 아니며, 그 역사는 현실적인 기대치 설정에 교훈적입니다. 1Password와 Dashlane 모두 수년 전에 자동 비밀번호 변경 기능을 실험했으며, 그 노력들의 교훈은 냉정합니다.

Dashlane은 지원되는 사이트 세트에서 비밀번호를 자동으로 교체할 수 있는 "비밀번호 변경기" 기능을 출시했고, 1Password는 .well-known/change-password 표준에 의존해 사용자를 정확한 위치로 안내하는 유사한 자동 변경 도구 작업을 했습니다. 양쪽의 공통 주제는 사이트 지원 범위가 지속적인 병목이었다는 것입니다. 비밀번호 변경을 자동화하려면 관리자가 각 사이트의 특정 양식 구조, 필드 이름, 유효성 검사 규칙, 다단계 세부 사항을 이해해야 하는데 -- 그리고 웹은 끝없이 일관성이 없습니다. 사이트들이 계정 페이지를 재디자인하고, CAPTCHA를 추가하고, 새로운 확인 단계를 도입하고, 자동화를 지속적으로 파괴합니다. 웹의 의미 있는 부분에 걸쳐 신뢰할 수 있는 지원 범위를 유지하는 것은 정당화하기 어려운 러닝머신으로 판명되었고, 완전 자동화 야망은 더 신뢰할 수 있는 "올바른 페이지로 데려다주는" 동작을 위해 축소되었습니다.

Apple은 그 노력들이 없었던 두 가지 구조적 이점을 가져옵니다. 첫째, 비밀번호 관리자와 브라우저 모두를 제어하므로 에이전트가 외부에서 싸우는 대신 Safari 안에서 작동합니다. 둘째, 원칙적으로 사이트별 스크립트에 의존하는 대신 이전에 보지 못한 양식에 적응할 수 있는 사이트별 레시피를 수작업으로 유지하는 것이 아닌 범용 AI 에이전트를 가지고 있습니다. 이것은 실질적인 아키텍처적 우위이며, Apple의 시도가 이전에 있었던 스크립트 기반 접근보다 폭넓은 지원 범위를 달성할 더 나은 기회를 가지는 이유입니다.

하지만 근본적인 제약은 변하지 않았습니다. 웹은 여전히 일관성이 없고, CAPTCHA와 2FA는 여전히 자동화를 막기 위해 존재하며, 낯선 양식을 해석하는 AI 에이전트는 여전히 때때로 잘못 처리할 것입니다. 현실적인 기대치는 macOS 27의 기능이 잘 구조화된 주요 사이트에서는 인상적으로 잘 작동하고 긴 꼬리에서는 어려움을 겪을 것이라는 것입니다 -- 1Password와 Dashlane이 경험한 것과 동일한 형태의 결과, 단지 더 높고 더 적응 가능한 상한선을 가진. 보관함의 모든 비밀번호를 완벽하게 교체할 것이라고 기대하는 사람은 실망을 위해 자신을 설정하는 것입니다.

How to Control, Limit, or Avoid the Feature

보안 트레이드오프가 신중하게 만든다면 -- 합리적인 입장 -- 이 중 어느 것도 강제로 사용할 필요가 없습니다. 기능은 행동으로 옵트인됩니다. 플래그 표시된 항목에서 수정 버튼을 클릭할 때까지 아무것도 하지 않습니다. "신중하게 사용"부터 "절대 사용하지 않음"까지의 스펙트럼에 걸쳐 제어권을 유지하는 방법:

선택적으로 사용하세요. 가장 간단한 제어는 자제입니다. 에이전트에게 저위험 계정 -- 오래된 포럼 로그인, 일회용 서비스, 결제 정보나 민감한 데이터가 없는 사이트 -- 을 처리하게 하세요. 잘못된 변경이 아무 비용도 들지 않는 곳에서는 사용하고, 고위험 계정 (은행, 이메일, 기본 클라우드 계정, 금융 또는 신원 관련 모든 것)은 직접 변경하세요. 이메일 계정은 특히 수동 처리가 필요합니다. 다른 모든 것의 복구 앵커이므로 자동화된 프로세스가 근처에 있는 것을 원하지 않습니다.

거부하고 직접 수동으로 하세요. 플래그 표시된 항목에서 자동 수정을 무시하고 항목의 링크를 사용해 직접 사이트를 열어 전통적인 방식으로 비밀번호를 변경할 수 있습니다. Passwords 앱은 여전히 강력한 비밀번호를 생성하고 저장해 줍니다. 단지 탐색과 제출을 위해 인간을 루프에 유지하는 것뿐입니다.

일반 관리자로 계속 사용하세요. 에이전트 기능은 Passwords 앱의 핵심 기능을 변경하지 않습니다. 자동 변경 버튼을 클릭하지 않으면 앱은 2024년 이후와 정확히 같이 동작합니다 -- 스스로 행동하지 않고 자격 증명을 저장, 자동 입력, 플래그 처리합니다.

Apple Intelligence 게이팅에 주의하세요. 기능이 Apple Intelligence 출시의 일부이므로 Apple Intelligence를 활성화하지 않은 Mac에서, 또는 관련 기능이 아직 출시되지 않은 지역과 언어에서는 자동 변경 작업이 그냥 나타나지 않을 수 있습니다. 기능을 완전히 피하고 싶다면 Apple Intelligence를 비활성화하는 것이 에이전트가 절대 실행되지 않도록 하는 가장 철저한 방법입니다 -- 다른 Apple Intelligence 기능들을 포기하는 비용으로.

가장 건강한 자세는 "전부 또는 없음"이 아니라 "자동화를 위험도에 맞추는 것"입니다. 자동화는 도구입니다. 실수가 저렴한 곳에서 사용하고 실수가 비싼 곳에서는 직접 운전하세요.

Best Practices If You Do Use It

에이전트를 작동하도록 결정한다면, 소수의 습관이 편의성을 포착하면서 하방 위험을 커버하게 해줄 것입니다.

중요한 계정의 모든 변경을 확인하세요. 경고가 지워졌다고 성공을 가정하지 마세요. 중요한 계정에 대해서는 새 비밀번호로 로그아웃 후 다시 로그인하거나, 사이트가 최근 "비밀번호 변경됨" 알림을 표시하는지 확인하세요. 이것은 보관함과 사이트가 불일치하는 부분 실패 시나리오를 포착합니다.

복구 옵션을 최신 상태로 유지하세요. 에이전트가 비밀번호를 교체하기 전에, 계정의 복구 이메일, 전화번호, 그리고 -- 중요하게는 -- 모든 백업 또는 복구 코드가 최신 상태이고 안전한 곳에 저장되어 있는지 확인하세요. 복구 코드는 자동화된 변경이 잠겨 나가게 할 때의 탈출구이며, 필요할 때 없으면 쓸모가 없습니다.

백업을 유지하세요. Mac의 최신 Time Machine 백업은 로컬 Passwords/iCloud Keychain 데이터베이스를 보호합니다. iCloud가 여러 기기에 걸쳐 보관함을 동기화하지만, 로컬 백업은 macOS 27로의 전환 중 모든 로컬 손상에 대한 저렴한 보험입니다.

에이전트를 작동시키기 위해 2FA를 비활성화하지 마세요. 이중 인증 도전 때문에 에이전트가 계정에서 멈추면, 답은 그 비밀번호를 수동으로 변경하는 것입니다 -- 자동화가 실행될 수 있도록 계정 보호를 약화시키는 것이 아닙니다. 2FA는 정확히 그 역할을 하고 있습니다.

고가치 변경을 분산하세요. 업데이트해야 할 중요한 계정이 여러 개 있다면, 일괄 처리하는 것이 아니라 하나씩 처리하고 다음으로 넘어가기 전에 각각을 확인하세요. 문제가 생기면 즉시 진단할 수 있는 단일 계정에 국한되기를 원합니다.

이후에 침해 상태를 다시 확인하세요. 자동 변경이 정말로 성공했다는 좋은 신호는 다음 스캔에서 해당 항목이 보안 섹션에 더 이상 나타나지 않는 것입니다. 자격 증명이 계속 재플래그 처리된다면 변경이 완전히 이루어지지 않았다는 신호로 취급하고 수동으로 개입하세요.

Troubleshooting Common Issues

변경이 실패하거나 도중에 멈췄습니다. 먼저 당황하지 말고 비밀번호가 변경되었다고 가정하지 마세요. 사이트를 직접 열어 이전 비밀번호로 로그인을 시도하세요. 여전히 작동한다면 변경이 진행되지 않았고 보관함 항목은 변경되지 않았습니다 -- 재시도하거나 수동으로 변경할 수 있습니다. 이전 비밀번호가 거부된다면 사이트에서 변경이 성공했을 수 있습니다. Passwords 앱이 해당 항목에 새 비밀번호를 저장했는지 확인하고, 새 값을 복구할 수 없다면 사이트의 "비밀번호 찾기" 복구 흐름을 사용해 깔끔하게 재설정하세요.

사이트가 지원되지 않습니다. 에이전트가 변경을 완료할 수 없다고 보고하면 사이트가 비표준 인증 흐름, 에이전트가 조작할 수 없는 맞춤형 비밀번호 변경 페이지, 또는 통과할 수 없는 도전을 사용할 가능성이 높습니다. 수동으로 비밀번호를 변경하세요. 사이트를 열고, 계정 보안 설정으로 이동하고, Passwords 앱의 강력한 비밀번호 생성기를 사용해 새 비밀번호를 만들고, 보관함에 직접 저장하세요. 이것은 2026년 이전의 일반적인 워크플로우이며 여전히 완전히 지원됩니다.

변경 후 잠겨 나갔습니다. 이것이 복구 코드가 존재하는 시나리오입니다. 계정의 복구 흐름을 사용하세요 -- 일반적으로 복구 이메일이나 전화로 재설정을 보내거나 저장된 백업 코드를 입력하는 "비밀번호 찾기" 링크입니다. 액세스를 회복하면 알고 있는 비밀번호를 설정하고 Passwords 앱 항목을 수동으로 업데이트해 보관함이 일치하도록 하세요. 잠긴 계정이 이메일 자체라면 복구 옵션을 별도로 최신 상태로 유지하는 것이 얼마나 중요한지 바로 그 이유입니다.

변경 중 사이트가 2FA를 요구합니다. 에이전트가 이중 인증 프롬프트에서 멈추면 수동으로 변경을 완료해서 인증 앱이나 문자 메시지에서 직접 코드를 제공하세요. 에이전트를 수용하기 위해 2FA를 끄지 마세요. 직접 비밀번호를 변경한 후 새 값이 Passwords 앱에 저장되어 자동 입력이 계속 작동하는지 확인하세요.

자동 변경 옵션이 전혀 나타나지 않습니다. macOS 27을 실행 중인지, Mac에서 Apple Intelligence가 활성화되어 있는지, 그리고 보안 섹션에서 실제로 플래그 표시된 항목을 보고 있는지 확인하세요 (옵션은 플래그 표시된 자격 증명에만 표시됩니다). 기능이 단계적 Apple Intelligence 출시의 일부이므로 적격 하드웨어에서도 출시 시점에 모든 지역이나 언어에서 사용 가능하지 않을 수 있습니다.

FAQ

Passwords 앱이 묻지 않고 자동으로 비밀번호를 변경하나요? 아닙니다. 에이전트는 절대 스스로 행동하지 않습니다. 보안 섹션에서 플래그 표시된 자격 증명을 열고 수정을 명시적으로 트리거할 때만 실행됩니다. 백그라운드에서 비밀번호를 교체하는 프로세스도 없고, 전체 보관함에 걸쳐 모든 것을 한 번에 변경하는 단일 버튼도 없습니다.

모든 웹사이트에서 작동하나요? 아닙니다. .well-known/change-password 표준을 구현하고 잘 구조화된 로그인 및 비밀번호 변경 양식을 사용하는 사이트에서 가장 잘 작동합니다. 오래된 포털, 맞춤형 인증 흐름, 필수 CAPTCHA 또는 인증 코드 단계가 있는 사이트는 수동 처리가 필요할 수 있습니다. 폭넓은 지원 범위를 목표로 취급하되 보장으로 취급하지 마세요.

Apple의 AI가 은행 비밀번호를 처리하도록 두는 것이 안전한가요? 은행이나 기본 이메일 같은 고위험 계정은 수동으로 변경하고 에이전트는 저위험 로그인을 위해 예약하는 신중한 접근이 좋습니다. Apple의 온디바이스 및 Private Cloud Compute 아키텍처는 견고하지만, 여러 실패 모드와 복구 세부 사항이 아직 공개되지 않아 중요한 변경을 직접 확인하는 것이 현명합니다.

변경이 도중에 실패하면 어떻게 되나요? Apple은 부분 실패 동작을 완전히 문서화하지 않았습니다. 안전한 경우 에이전트는 중지하고 아무것도 변경하지 않습니다. 자신을 보호하기 위해 항상 새 비밀번호로 로그인해서 중요한 변경을 확인하고, 변경으로 인해 계정이 불확실한 상태가 되더라도 액세스를 회복할 수 있도록 복구 코드와 복구 연락처를 최신 상태로 유지하세요.

기능을 완전히 끌 수 있나요? 네. 자동 수정 작업을 트리거하지 않으면 됩니다 -- Passwords 앱은 그 외에는 일반 관리자로 작동합니다. 에이전트가 절대 실행되지 않도록 하려면 Mac에서 Apple Intelligence를 비활성화하면 되는데, 이는 더 넓은 Apple Intelligence 기능 세트도 끕니다.

Conclusion

macOS 27 Passwords 앱의 에이전트형 비밀번호 변경 기능은 진정으로 인상적인 공학 작품이며, 비밀번호가 유출되었다는 통보를 받고도 결코 수정하지 않는다는 실제적이고 오랫동안 지속된 문제에 대한 합리적인 답입니다. 그 수정 기간을 "언젠가"에서 "즉시"로 좁히는 것은 인구 규모에서 의미 있는 보안 이점이며, Apple의 구조적 이점 -- 관리자와 브라우저 모두를 소유하고, 취약한 사이트별 스크립트 대신 범용 에이전트를 사용하는 것 -- 은 이전에 있었던 1Password와 Dashlane 시도보다 폭넓은 지원 범위에서 더 나은 가능성을 줍니다.

하지만 능력과 위험은 동일한 기능의 두 면입니다. 계정에 로그인하고 자격 증명을 다시 쓸 수 있는 에이전트는 본질적으로 고가치 표적이자 새로운 실패 모드의 원천이며, 보안을 중시하는 사용자가 완전히 신뢰할 수 있도록 해줄 여러 운영 세부 사항 -- 실패 동작, 2FA 처리, 감사 이력, 도메인 유효성 검사, 복구 -- 이 현재 작성 시점에서 아직 공개되지 않았습니다. 올바른 자세는 반사적인 거부도 맹목적인 신뢰도 아닙니다. 실수가 저렴한 곳에서 사용하고, 디지털 생활을 고정하는 계정에는 직접 운전하고, 작업을 확인하고, 복구 옵션을 그대로 유지하세요.

이 기능을 더 넓은 출시 맥락에서 보려면 macOS 27 Golden Gate의 모든 것에 대한 전체 설명과 WWDC 2026 macOS 27 Siri 개선에 대한 미리 보기를 참조하세요. 이 기능은 같은 Apple Intelligence 추진의 일환입니다. 이 중 일부를 일찍 사용해볼지 고민 중이라면 macOS 27 Golden Gate 개발자 베타를 설치해야 하는지에 대한 가이드에서 알려진 문제를 정리했습니다. Apple의 더 넓은 보안 입장에 대해서는 macOS의 백그라운드 보안 개선 (BSI) 설명서를 읽어보시고, 현재 출시 브랜치는 macOS Tahoe 26.5 완전 업데이트 및 보안 가이드에서 오늘 알아야 할 CVE와 수정 사항을 다룹니다.