먼저 말을 거는 AI 비서 Claude Duet, 어디까지 맡길 수 있을까

Claude Duet이 스스로 하는 일은 읽기와 초안 쓰기까지이고, 메시지 발송·결제·서명·삭제는 내용을 보여 주고 승인을 받은 뒤에만 하며, 증권 거래와 계좌 간 송금은 승인해도 하지 않습니다. 이 선이 어디에 그어져 있는지는 기능 목록보다 실제 일 하나를 따라가 볼 때 잘 보입니다. 그래서 아침 브리핑, 낮 동안의 확인, 독촉 메일 발송, 주문 결제의 네 장면을 차례로 걷고, 그 뒤에 일을 등급으로 나누고 연결을 끊었을 때 무엇이 남는지, 신청에서 첫 주까지 무엇을 만나는지를 적었습니다. 기준은 Anthropic이 10월 21일(UTC)에 올린 소개 글과 10월 23일의 안전·개인정보·보안 문서, 지원 문서이고, 모두 2026-10-27 UTC에 다시 열어 확인했습니다.

아침 7시, 읽지 않은 메일 사이에서 일정 충돌이 올라온다

Duet은 사용자가 말을 걸기 전에 먼저 움직이는 앱입니다. 매일 아침 이메일과 일정을 훑어 가장 중요한 것을 짧은 브리핑으로 보내고, 답장 초안 쓰기 같은 첫 단계는 먼저 시작해 둘 수 있습니다. 하나의 이어진 스레드에서 글이나 음성으로 대화하고, 주제별로 채널을 따로 열 수도 있으며 채널들은 기억을 공유합니다. 기반 모델은 Claude Opus 5.5이고 사용자가 모델을 고르는 설정은 없습니다. 모델은 일마다 노력 수준을 스스로 정합니다.

브리핑이 어떤 모양일지는 아래 예시가 가장 빠릅니다. 편집부가 흐름을 보이려고 만든 가상의 대화이고, 실제 화면이 아닙니다.

짧은 대화지만 두 가지가 들어 있습니다. 브리핑과 초안은 승인 없이 스스로 하는 일이고, 초안이 실제 메일이 되는 순간부터는 사람의 승인이 끼어듭니다. 지원 문서는 Duet이 숫자나 요약을 낼 때 근거가 된 메일·파일·스프레드시트를 함께 적는다고 밝힙니다. 브리핑의 한 줄을 믿기 전에 그 출처를 한 번 열어 보면 되는 구조입니다.

Anthropic이 소개한 시험 사용자 사례도 이 지점을 가리킵니다. 한 부동산 중개인은 아침 브리핑이 다른 날로 잘못 잡힌 매물 방문 일정을 짚어 주었고, 묻지 않고도 원하던 종류의 알림이라고 평했습니다. 직원이 약 110명인 한 사업주는 여러 매장의 회계, 고객 지원, 마케팅을 맡기며 탭을 100개 열 필요가 없어졌다고 했습니다. 모두 Anthropic이 고른 사례이므로 평균적인 결과가 아니라 설계가 노리는 쓰임으로 읽어야 합니다.

점심 직전에 온 메일은 언제 알려질까

“먼저 말을 건다”는 말에서 가장 흔한 오해는 메일이 오는 순간 알려 준다는 기대입니다. Duet은 연결된 계정을 몇 시간마다 확인하는 방식이고, Anthropic은 쉬지 않고 확인하면 플랜 한도가 훨씬 빨리 닳기 때문이라고 이유를 적었습니다. 지원 문서도 급한 항목이 다음 확인까지 기다릴 수 있다고 한계로 명시했습니다.

아래 그림은 확인 간격이 3시간이라고 가정하고 하루를 눈금에 얹은 것입니다. 파란 점이 확인 시각이고, 주황 사각형이 메일 도착 시각입니다.

그림 1. 확인 간격 3시간은 가정이고, 공식 표현은 “몇 시간마다”다

10시 6분에 온 메일은 13시 확인 때까지 거의 3시간을 기다리고, 12시 54분에 온 메일은 곧바로 걸립니다. 같은 간격이라도 도착 시각에 따라 대기 시간이 0에서 한 간격 사이로 달라진다는 뜻이고, 몇 분 단위로 대응해야 하는 장애 알림이나 보안 경보는 이 구조에 맡길 일이 아닙니다.

확인 주기를 길게 잡은 이유가 한도입니다. Duet에는 별도 가격이 없고, Pro·Max 한도를 채팅과 같은 비율로 소모합니다. 지원 문서는 5시간 세션 한도와 주간 한도 둘 다에 해당한다고 적었고, 아침 브리핑과 낮의 확인도 한도에 들어갑니다. 말을 걸지 않은 시간에도 한도가 조금씩 움직인다는 뜻입니다. 재무 모델이나 발표 자료처럼 큰 작업은 모델 호출과 백그라운드 작업이 더 필요해 더 많이 씁니다. 받을 주제와 빈도는 사용자가 고를 수 있으므로, 처음에는 좁게 열어 두는 편이 한도를 아끼는 길입니다.

독촉 메일 세 통이 나가기까지

세 번째 장면은 승인이 실제로 어떤 순서로 도는지 보는 자리입니다. Anthropic이 예시로 든 일 가운데 QuickBooks와 Stripe에서 아직 안 들어온 청구서를 찾아 독촉 메일 초안을 쓰는 작업이 있습니다. 아래는 그 일을 편집부가 순서도로 옮긴 것이고, 사용자의 말과 거래처 수는 가정입니다. 이 그림에서 볼 것은 화살표의 색입니다. 검은 화살표는 승인 없이 가고, 주황 화살표는 사람이 허락한 뒤에만 나갑니다.

그림 2. 읽기와 초안은 스스로, 발송은 승인 뒤. 세 통 중 한 통을 빼고 두 통만 나가는 가정

그림의 “OUTSIDE CHECK”는 10월 23일 안전 문서에 적힌 장치입니다. 행동마다 모델 바깥에서 별도의 자동 검사가 돌며 그 행동이 사용자의 의도와 맞는지 평가하고, Anthropic은 소개 글에서 행동 승인에 Claude와 Claude Code의 자동 모드 분류기가 쓰인다고 밝혔습니다. 승인 화면에는 행동, 목적지, 내용이 보이고, 메시지라면 모든 수신자가 보입니다. 세 통을 한꺼번에 승인하는 것이 아니라 어느 통을 빼야 하는지 눈으로 골라낼 수 있는 구조입니다.

사람이 바로 응답하지 못해도 일이 멈추지는 않습니다. 지원 문서에 따르면 Duet은 승인이 필요한 부분만 남겨 두고 나머지를 끝낸 뒤 승인 요청을 나중에 다시 가져옵니다. 자리를 비운 사이 돌아가는 루틴도 같은 안전장치를 쓴다고 합니다. 반복되는 승인을 줄이는 “다시 묻지 않기” 규칙도 있는데, 결제나 송금, 주문 삭제, 계정 만들기는 이 규칙에서 빠져 있어 매번 묻습니다. 소개 글만 보면 규칙이 고정이라고 읽히지만, 10월 23일 문서가 나오면서 일부 일은 사용자가 승인 빈도를 낮출 수 있다는 점이 분명해졌습니다.

카드 번호도 비밀번호도 지나가지 않는 주문

네 번째 장면은 돈이 오가는 일입니다. 구매는 Stripe의 Link 지갑을 통해 하고, Link가 가맹점 하나와 금액 하나로 한정된 일회용 가상 카드를 발급합니다. 실제 카드 번호는 Duet에도 가맹점에도 넘어가지 않습니다. 이 결제도 승인 대상이며, Shopify 스토어에서는 Shop Pay로 결제하는 길도 열려 있습니다. 주문 뒤의 문제는 책임이 갈리는데, 배송이나 환불은 그 가게에, Link 문제는 Link 지원에, Duet이 엉뚱한 상품이나 옵션을 골랐다면 Anthropic에 문의하라고 지원 문서가 안내합니다.

로그인이 필요한 사이트에서는 비밀번호가 어디로 가는지가 궁금해집니다. 아래 그림은 10월 23일 문서의 설명을 영역별로 나눈 것입니다. 눈여겨볼 곳은 에이전트 상자와 점선·실선으로 연결된 곳들입니다.

그림 3. 에이전트는 자리표시자만 본다. 비밀번호는 앱 안의 폼에서 브라우저 머신으로, 진짜 토큰은 바깥 프록시가 붙인다

비밀번호는 Claude 앱 안의 폼에 직접 입력하고, 일회용 키로 암호화되어 브라우저 머신으로 가며 모델은 값을 보지 못합니다. 로그인 폼은 사용자가 요청한 로그인 중에만 앱 안에 나타나고, 링크·문자·메일·다른 웹사이트로 오는 요청은 정당한 요청이 아니라고 문서가 경고합니다. 로그인 토큰은 에이전트가 자리표시자로만 다루고, 요청이 나가는 순간 에이전트 컴퓨터 바깥의 프록시가 진짜 값을 끼워 넣습니다. 브라우저는 전용 클라우드 가상 머신에서 열기·클릭·입력 같은 정해진 명령으로만 조종되며, 사이트의 코드와 쿠키는 브라우저 머신에 머뭅니다. 페이지의 글과 내려받은 파일은 에이전트에게 돌아옵니다.

이 구조는 Anthropic이 Duet의 자격 증명 처리가 따른다고 밝힌 Claude Managed Agents 문서와 같은 줄기입니다. 개발자 문서는 비밀 값을 금고에 한 번 등록하고, 에이전트 쪽에는 자리표시자만 두며, 허용한 호스트로 나가는 요청에서만 교체한다고 설명합니다. 같은 문서에는 한계도 적혀 있습니다. 교체는 나가는 방향뿐이라서, 비밀 값으로 받아 온 세션 토큰은 샌드박스에 그대로 들어오고, 에이전트는 키가 허용하는 모든 일을 할 수 있으니 키의 권한은 필요한 만큼만 주라는 것입니다. 사용자 쪽으로 옮기면 비밀번호를 못 본다는 말이 안심을 주지만, 연결한 앱의 권한 범위가 곧 에이전트가 닿을 수 있는 범위라는 뜻입니다.

오가는 글에도 검사가 하나 더 붙습니다. 별도의 분류기가 나가는 모든 메시지를 보고, 브라우저로 올리는 파일까지 검사합니다. 로그인 정보, 전체 카드·계좌 번호, 정부 발급 신분 번호는 사용자가 요청해도 공유하지 않습니다. 건강이나 재무 같은 다른 개인 정보는 동의가 있어야 하는데, 사용자 본인의 요청이 곧 동의로 인정됩니다. 막힌 메시지는 민감한 내용을 뺀 문장으로 고쳐 다시 승인을 구하기도 합니다. 문서는 이 분류기가 가끔 놓치거나 무해한 메시지를 막을 수 있다고도 적었습니다. 한편 브라우저 요청에는 구분되는 User-Agent가 붙고 Anthropic이 브라우징 IP 주소를 공개하는데, 일부 큰 사이트는 이를 막기로 했다고 합니다. 그런 사이트에서는 주문이 되지 않을 수 있습니다.

아홉 가지 일을 세 등급에 놓으면

네 장면에서 나온 일을 한 장에 놓으면 선이 어디에 있는지 한눈에 들어옵니다. 아래 표는 공식 문서에 이름이 적힌 행동만 골랐고, 칸이 진할수록 사람의 개입이 앞섭니다.

그림 4. 스스로 하는 일 둘, 승인받는 일 넷, 승인해도 하지 않는 일 셋

공통점은 되돌릴 수 있는가입니다. 초안은 버리면 그만이지만, 이미 나간 메일, 빠져나간 결제, 서명된 계약, 지워진 기록은 되돌리기 어렵습니다. 맨 아래 세 줄은 승인을 눌러도 거절하는 영역이어서 사람이 실수로 허락할 여지 자체를 없앴습니다. 반대로 위쪽의 읽기는 권한 안에서는 스스로 하므로, 연결 앱을 늘릴수록 읽을 수 있는 범위가 곧바로 넓어집니다. 한 안내 글이 지적했듯 받을 주제를 좁히는 필터는 일을 정의할 뿐이고, 커넥터가 가진 계정 권한을 줄여 주지는 않습니다.

연결을 끊어도 남는 기억

불안해서 앱 연결을 끊었다면 무엇이 달라지는지 알아야 합니다. 연결은 사용자가 직접 시작하고 언제든 해제할 수 있으며, Claude 설정에서 관리합니다. Claude에서 연결을 끄면 Duet에서도 꺼지고, 반대도 마찬가지입니다.

그래서 앱을 끊은 뒤에 그 앱에서 얻은 정보까지 지우려면 기억을 초기화하는 단계가 따로 필요합니다. 반대로 에이전트가 하는 일을 점검할 창구는 있습니다. 작업 목록과 작업별 페이지를 볼 수 있고, 진행 중인 작업의 방향을 바꿀 수도 있습니다. 다만 에이전트의 브라우저 화면을 보거나 넘겨받는 것은 아직 안 됩니다. 결과와 승인 화면만 보이므로, 승인 화면의 정보가 판단 재료의 대부분이 됩니다.

대기자 명단에 이름을 올리는 순서와 첫 제약

지금은 연구 프리뷰이고 초대 방식입니다. 일부 지역의 Pro·Max 계정이 대상이며, 신청은 다음 순서로 합니다.

1. Claude Duet 제품 페이지에서 대기자 명단 참가를 누릅니다.
2. 이름과 이메일을 적습니다. Claude를 쓴다면 Claude 계정의 이메일이어야 합니다.
3. 요금제와 휴대폰 종류(iPhone 또는 Android)를 고르고, 하는 일과 처음 맡기고 싶은 일은 선택으로 적습니다.
4. 제출하면 차례가 되었을 때 이메일이 옵니다. 초대는 순차적으로 나가므로 신청이 날짜를 보장하지는 않습니다.
5. 휴대폰에서 초대 메일을 열고 안내에 따라 Apple이나 Google 계정으로 연결합니다. 이 계정의 이메일은 명단에 적은 이메일과 같아야 합니다.

입장한 사용자에게는 혜택이 하나 있습니다. 입장할 때 5시간 세션 한도와 주간 한도를 한 번 전부 초기화해 주는데, 이 권리는 2026년 11월 30일까지 쓸 수 있다고 지원 문서가 적었습니다. 새 일을 시험해 보다가 한도가 빨리 닳아도 한 번은 처음부터 다시 쓸 수 있다는 뜻입니다.

첫 제약도 알아 두면 시행착오가 줄어듭니다. Team·Enterprise 요금제는 아직 대상이 아니며, 나중에 가져올 계획이라고 지원 문서가 적었습니다. Microsoft 365 커넥터는 아직 쓸 수 없고 일부 커넥터에는 한도가 있습니다. 전화나 문자 메시지는 보내지 못하고, 메일은 연결된 계정으로 승인을 받아 보냅니다. 큰 결과물은 Make 탭에 편집 가능한 파일(조사 브리프, 재무 모델, 발표 자료, 대시보드)로 돌아옵니다. 커넥터가 없는 사이트는 자체 클라우드 브라우저로 처리합니다. 연결은 사용자가 직접 시작한 것만 쓰고, 사용자의 컴퓨터에 있는 모든 프로젝트와 파일을 보는 것은 아니며 Claude 쪽 작업은 읽기만 합니다.

첫 주에 열어 둘 연결과 닫아 둘 연결

처음 며칠은 읽기 위주의 연결 두 곳으로 시작하는 편이 안전합니다. 메일과 일정이 좋은 출발점인 이유는 아침 브리핑이 바로 쓸모를 보이면서 쓰기 위험이 가장 낮기 때문입니다. 한 안내 글은 처음에는 실제 메일함 대신 가상의 내용만 담은 시험용 메일함으로 연습하라고 권합니다. 첫 승인 요청마다 수신자, 제목, 본문, 첨부, 보내는 계정을 끝까지 읽고 누르면, 브리핑의 긴급도 판단이 내 기준과 얼마나 맞는지도 그사이에 보입니다.

결제나 급여, 계약처럼 돈과 서명이 걸린 앱은 가장 나중에 붙이는 쪽이 낫습니다. 승인 화면이 아무리 잘 만들어져도 하루에 수십 번 반복되면 누르는 손이 먼저 습관이 되기 때문입니다. 비어 있는 브리핑이 “할 일 없음”인지 “읽기 실패”인지도 구분해야 합니다. 둘은 다른 상태이고, 어느 쪽도 자동으로 안전을 뜻하지 않습니다. 마감이 있는 일의 점검은 기존 방식대로 두는 것이 좋습니다.

경쟁 제품이 줄지어 나오는 시기라 모델 성능이나 연결 앱 개수로 고르고 싶어지지만, Duet을 보며 얻을 수 있는 기준은 조금 다릅니다. 이 도구가 스스로 하는 일과 승인을 거치는 일은 결국 되돌릴 수 있느냐로 갈립니다. 그렇다면 어떤 에이전트가 오든 물어볼 질문은 같습니다. 되돌릴 수 없는 행동 앞에 사람이 서 있는지, 서 있다면 그 사람이 화면에서 무엇을 볼 수 있는지입니다. 연결을 끊으면 접근은 멈추지만 이미 알게 된 것은 남는다는 점까지 보면, 처음 붙이는 앱 하나하나가 에이전트에게 열어 주는 범위를 정하는 일이 곧 설정의 대부분입니다.