대부분의 AI 비서는 질문을 기다립니다. Claude Duet은 반대로 움직입니다. 연결된 앱을 주기적으로 확인하고, 중요하다고 판단한 일을 먼저 알려주고, 사용자가 자리를 비운 동안에도 전용 가상 머신에서 작업을 이어갑니다.
2026년 10월 21일 Anthropic이 공개한 Claude Duet은 미국 Pro·Max 사용자를 대상으로 한 research preview입니다. 대기자 명단을 통해 순차적으로 열리고, iOS·Android 앱과 claude.ai에서 사용할 수 있습니다. 이 글에서 중요한 것은 “AI가 먼저 연락한다”는 기능 목록이 아닙니다. 에이전트가 상시 권한을 가지게 될 때, 어디에 승인 경계를 두고 무엇을 측정할지입니다.
확인된 것과 아직 확인되지 않은 것
Anthropic의 발표는 기능과 안전 설계를 함께 설명합니다. 다만 이는 제조사의 설명이며, 실제 정확도나 오탐률을 독립적으로 검증한 자료는 이번 조사에서 확인하지 못했습니다.
| 항목 | 확인된 내용 | 해석 |
|---|---|---|
| 제공 형태 | research preview, 미국 Pro·Max 대기자 명단 | 일반 제공이 아님 |
| 모델 | Claude Opus 5.5 기반 | 모델 교체 가능성은 별도 확인 필요 |
| 실행 환경 | 전용 가상 머신과 자체 브라우저 | 노트북이 꺼져 있어도 작업 가능 |
| 확인 주기 | 연결 앱을 몇 시간마다 확인 | 연속 감시가 아님 |
| 연결 | 6,000개 이상의 커넥터·플러그인 | 앱별 권한 범위는 별도 확인 |
| 승인 | 메시지 발송·결제·서명·삭제 전 승인 | 승인 UI의 구체 동작은 미검증 |
| 금지 | 증권 거래, 계좌 간 자금 이동은 승인해도 불가 | 정책 범위는 변경될 수 있음 |
| 비밀번호 | 자격증명을 직접 보지 않는 설계 | Anthropic의 설명 |
| 제한 | 브라우저 화면을 아직 보여주지 않음, 개인 잡무는 상대적으로 약함 | preview의 명시적 한계 |
“몇 시간마다 확인”은 비용과 주의를 절충한 선택입니다. Anthropic은 연결 계정을 끊임없이 확인하면 플랜 한도를 훨씬 빨리 소모한다고 설명합니다. 백그라운드 확인도 사용량 한도에 포함됩니다. 즉, 더 자주 확인하는 것이 더 좋은 에이전트가 아니라, 확인 빈도와 알림 품질을 함께 설계해야 합니다.
구조: 대화창 뒤에 있는 다섯 계층
Claude Duet을 “말을 거는 챗봇”으로만 보면 놓치는 것이 많습니다. 최소한 다음 계층을 분리해서 봐야 합니다.
| 계층 | 역할 | 실패했을 때 |
|---|---|---|
| 컨텍스트 | Claude의 memory, skills, 연결 앱을 이어받음 | 오래된 선호나 잘못된 맥락을 반복 |
| 관찰 | 연결 앱을 주기적으로 확인 | 중요한 일을 놓치거나 사소한 일로 알림 폭주 |
| 실행 | 전용 VM과 브라우저에서 작업 | 외부 서비스에 의도하지 않은 변경 |
| 승인 | 민감한 행동 전에 사용자 확인 | 승인 피로, 잘못된 승인, 승인 UI 피싱 |
| 감사 | 어떤 앱에 어떤 행동을 했는지 기록 | 사고 후 원인 추적 불가 |
Anthropic은 신뢰할 수 있는 에이전트 프레임워크, Claude Managed Agents의 자격증명 처리, auto mode classifier, 브라우저 사용 연구에서 가져온 prompt injection 방어를 언급합니다. 또한 외부 업체의 침투 테스트와 버그 바운티를 운영한다고 합니다. 이는 설계 의도와 테스트 범위에 대한 설명이지, 모든 연결 앱에서 동일한 안전성이 보장된다는 뜻은 아닙니다.
승인 경계를 행동 단위로 쪼개기
“중요한 행동은 승인받는다”는 문장은 너무 넓습니다. 실제로는 행동을 읽기, 초안 작성, 외부 전송, 결제, 서명, 삭제로 나누고 각각 다른 규칙을 둬야 합니다.
| 행동 | 기본 정책 | 승인 시 보여줘야 할 것 | 주의점 |
|---|---|---|---|
| 읽기 | 자동 | 접근한 앱과 범위 | 최소 권한 계정 사용 |
| 초안 작성 | 자동 | 초안과 출처 | 초안에 민감정보가 섞일 수 있음 |
| 외부 메시지 발송 | 건별 승인 | 수신자, 본문, 첨부파일 | “전체 승인” 금지 |
| 결제 | 건별 승인 | 금액, 판매자, 카드/지갑, 환불 조건 | 한도와 예산을 별도로 설정 |
| 서명 | 건별 승인 | 문서, 당사자, 효력 발생 조건 | 법무 검토가 필요한 문서는 별도 |
| 삭제 | 건별 승인 | 대상, 복구 가능성, 백업 | 휴지통과 영구 삭제를 구분 |
| 증권 거래·계좌 이체 | 거부 | — | 승인해도 허용되지 않는다고 발표 |
이 표는 제품 설정이 아니라 도입 조직이 합의해야 할 정책의 예시입니다. 핵심은 “에이전트가 승인을 요청했다”와 “사용자가 그 행동을 이해하고 승인했다”가 같지 않다는 점입니다. 승인 화면이 길고 복잡하면 사람은 읽지 않고 누르게 됩니다. 승인 피로는 안전장치를 장식으로 만듭니다.
그래서 승인 등급을 두 단계로 나누는 편이 낫습니다.
- 낮은 위험: 여러 건을 묶어 요약하고, 일괄 승인할 수 있게 한다. 대신 각 건의 원문을 펼쳐 볼 수 있어야 한다.
- 높은 위험: 한 건씩, 수신자·금액·문서·삭제 대상이 명확히 보일 때만 승인한다. 승인 후에도 취소 가능 시간을 둔다.
“먼저 연락한다”의 비용
Proactive agent의 품질은 작업 완료율만으로 측정할 수 없습니다. 사용자의 주의를 얼마나 가져가는지도 비용입니다. 매일 아침 브리핑이 길어지고, 하루에 알림이 여러 번 오면 에이전트는 유용한 비서가 아니라 또 하나의 알림 피드가 됩니다.
Anthropic은 아침 브리핑과 하루 중 중요한 일에 대한 메시지를 강조합니다. 하지만 “무엇이 중요한가”의 판단은 사용자와 조직마다 다릅니다. 발표에서도 알림 판단을 계속 조정하고 있다고 밝힙니다. 도입 전에는 알림의 정확도와 함께 알림이 없어야 할 때 침묵하는 능력을 봐야 합니다.
도입 전에 측정할 것
파일럿은 “연결해 보고 편한가”로 끝내면 안 됩니다. 최소한 다음 지표를 2주 이상 기록하는 편이 좋습니다.
| 지표 | 측정 방법 | 좋은 방향 |
|---|---|---|
| 유효 알림 비율 | 알림 중 실제로 조치한 비율 | 높을수록 좋지만 표본이 작으면 해석 주의 |
| 오탐 알림 수 | 사용자가 “중요하지 않다”고 표시한 건수 | 낮을수록 좋음 |
| 승인 거부율 | 승인 요청 중 거부·수정한 비율 | 너무 높으면 판단이 약함 |
| 승인까지 걸린 시간 | 알림에서 승인/거부까지 | 짧다고 좋은 것만은 아님 |
| 무개입 완료율 | 사람이 중간에 개입하지 않고 끝난 작업 | 작업 난이도와 함께 봐야 함 |
| 권한 범위 | 연결된 앱, 계정, 데이터 접근 범위 | 작을수록 좋음 |
| 사고 후 복구 시간 | 잘못된 행동을 되돌리는 데 걸린 시간 | 짧을수록 좋음 |
특히 승인 거부율이 높다는 것은 에이전트가 “일을 못한다”기보다 “무엇을 승인받아야 하는지”를 잘못 배웠다는 신호일 수 있습니다. 반대로 승인 거부율이 지나치게 낮으면 사용자가 내용을 읽지 않고 누르고 있을 가능성을 의심해야 합니다.
정책은 모델 밖에 있어야 한다
프롬프트에 “결제 전에 물어봐”라고 쓰는 것만으로는 승인 경계가 되지 않습니다. 모델이 잊거나, 도구 호출 형식이 바뀌거나, prompt injection이 지시를 덮어쓸 수 있기 때문입니다. 승인은 모델 외부의 도구 게이트웨이에서 강제해야 합니다.
아래는 제품 설정이 아니라 정책 설계를 설명하기 위한 미실행 예시입니다.
# Illustrative policy, not a Claude Duet configuration file.
actions:
read_connected_app:
mode: auto
constraints:
least_privilege: true
audit_log: true
draft_message:
mode: auto
constraints:
external_side_effect: false
send_message:
mode: require_approval
preview: [recipient, body, attachments]
allow_bulk_approval: false
make_payment:
mode: require_approval
preview: [amount, merchant, funding_source]
limits:
per_transaction: 0
daily: 0
sign_document:
mode: require_approval
preview: [document, parties, effective_date]
delete_data:
mode: require_approval
preview: [object, backup_status, recoverability]
trade_securities:
mode: deny
move_money_between_accounts:
mode: deny
실제 제품에서는 승인 UI, 권한 모델, 감사 로그, 결제 제공자 정책이 함께 맞물립니다. 정책 파일만으로 안전이 완성되지는 않습니다. 그래도 “어떤 행동이 자동이고 어떤 행동이 멈춰야 하는가”를 문서로 고정해 두면, 모델이나 커넥터가 바뀌어도 기준을 재사용할 수 있습니다.
출시 전에 확인할 질문
- 에이전트가 접근하는 계정이 개인 주계정인가, 업무용 최소 권한 계정인가.
- 메시지 발송과 결제가 실제 외부 서비스에서 일어나는가. 테스트 환경에서 먼저 검증했는가.
- 승인 화면에 수신자, 금액, 문서, 삭제 대상이 원문으로 보이는가.
- 연결 앱을 즉시 해제할 수 있는가. 해제 후 예약된 작업과 캐시는 어떻게 되는가.
- 프롬프트 injection이 들어 있는 이메일·문서를 읽었을 때 외부 전송으로 이어지지 않는가.
- 백그라운드 확인이 플랜 한도를 얼마나 쓰는지 측정했는가.
- 감사 로그를 기존 SIEM이나 티켓 시스템으로 내보낼 수 있는가.
- 오탐 알림과 놓친 알림을 사용자가 어떻게 피드백하는가.
Anthropic은 Duet이 아직 스레드를 잘못 읽거나 긴급도를 잘못 판단할 수 있다고 명시합니다. 개인 잡무보다 업무 중심으로 설계됐고, 브라우저 화면도 아직 보여주지 않습니다. 이 한계를 파일럿 범위에 반영해야 합니다.
결론: 먼저 일하는 에이전트에는 상시 권한이 따라온다
Claude Duet의 차별점은 “AI가 먼저 말을 건다”가 아닙니다. 사용자가 자리를 비운 동안에도 일이 이어지고, 그 일이 외부 서비스에 실제 효과를 만들 수 있다는 점입니다. 그 순간 에이전트는 채팅 상대가 아니라 상시 권한을 가진 대리인이 됩니다.
도입 판단은 기능 수보다 승인 경계에서 갈립니다. 어떤 행동을 자동으로 허용할지, 어떤 행동은 건별로 멈출지, 승인 화면이 실제로 읽히는지, 잘못된 행동을 되돌릴 수 있는지를 먼저 정하세요. 그다음에 연결 앱과 알림 주기를 늘리는 편이 안전합니다.
함께 읽으면 좋은 글
- OpenAI Dots란? Chatbot에서 '항상 일하는 AI'로 넘어가는 변화
- OpenAI 에이전트가 모니터링을 약화시킨 두 사고: 작업 성공과 안전 준수를 분리하는 법
- 자율 에이전트 시대의 사용 정책: 무엇을 허용하고 무엇을 기록할까
참고 자료
이 주제를 직접 따라가며 배우고 싶다면
자동 처리할 판단과 사람이 검토할 판단을 나누는 일은 프롬프트 문구보다 정책 설계에 가깝습니다. 확신도, 중단 조건, 사람 승인을 함께 설계하는 연습을 하고 싶다면 이 강의가 출발점이 될 수 있습니다.