Claude Duet 분석: 먼저 알려주는 AI에게 맡길 일과 직접 챙길 일

Claude Duet에서 달라지는 것은 일을 꺼내는 주체다

Anthropic은 2026년 10월 21일 Claude Duet 연구 프리뷰를 발표했다. 연결 앱을 살피고 중요한 일을 먼저 알리며, 사용자가 자리를 비워도 자체 가상 컴퓨터에서 작업을 이어 가는 제품이다. 발표는 아침 브리핑과 작업 위임을 함께 설명한다. iOS·Android의 별도 앱과 claude.ai에서 제공하며, 기존 Claude와 플랜 사용 한도를 공유한다. 공식 발표

일반적인 대화에서는 사용자가 문제를 발견한 뒤 질문한다. 선제적으로 움직이는 에이전트에서는 문제를 발견하고 사람의 주의를 요청하는 단계도 제품이 맡는다. 예를 들어 일정표와 메일을 따로 보다가 놓친 충돌을 찾아 주면, 좋은 답변 하나를 받는 것 이상의 가치가 있다. 반대로 중요하지 않은 변화를 계속 알리면 확인할 장소만 하나 더 늘어날 수 있다.

그래서 이 글의 판단 대상은 모델 성능 순위가 아니다. 메일과 일정 확인을 얼마나 위임할 수 있는가다. 10월 23일 공식 문서를 확인한 분석이며, Duet 계정·앱·커넥터를 직접 사용하지 않았다. 아래 시각 자료와 사례는 실제 화면이나 실행 결과가 아닌 작성자의 업무 설계다.

먼저 확인할 이용 조건

현재 도움말은 미국의 Pro·Max 가입자 중 대기열 초대를 받은 사용자를 대상으로 안내한다. Team·Enterprise는 아직 대상이 아니다. 가입 신청이 즉시 접근이나 정해진 초대 날짜를 보장하지도 않는다. 따라서 한국 독자에게는 지금 바로 따라 하는 설치 가이드보다, 제공 범위가 달라졌을 때 어떤 일을 시험할지 정하는 자료에 가깝다. 접근 조건

제품 페이지는 Opus 5.5를 기반으로, 기존 계정의 기억·스킬·연결 앱을 이어받고 필요할 때 승인을 구하는 구조를 설명한다. 기억이 이어진다는 사실과 이번 자료가 최신이라는 사실은 별개다. 예전에 정한 회의 선호 시간은 도움이 되지만, 오늘 막 들어온 변경 메일을 읽었다는 증거가 되지는 않는다. 제품 설명

이용 가능 여부를 확인한 뒤에는 자기 업무에 필요한 연결이 실제로 가능한지 따져야 한다. 현재 도움말에는 Microsoft 365 미지원, 일부 Slack 연결의 제약이 명시돼 있다. 연결 서비스 이름만 보고 회사에서 쓰는 모든 자료를 다룰 수 있다고 가정하지 말자. 현재 제한

‘먼저 알려준다’와 ‘제때 알려준다’ 사이

공식 발표에 따르면 Duet는 연결 계정을 몇 시간마다 확인한다. 계속 확인하면 플랜 한도를 더 빨리 쓰기 때문이다. 정확한 고정 간격이나 최장 발견 시간의 보장은 제시하지 않는다. 백그라운드 확인도 사용량에 포함된다는 점에서, 추가 요금 없이 포함된 기능과 무제한 감시는 구별해야 한다. 확인 주기와 사용량 설명

업무에 적용할 때는 다음 네 시간을 나누면 좋다. 이는 Duet 내부 구현 명세가 아니라 맡길 업무를 고르는 계산 틀이다.

발견까지 기다리는 시간 + 초안을 준비하는 시간 + 사람이 승인하기까지의 시간 + 실제 실행 시간 < 마감까지 남은 시간

이 조건이 맞아도 성공이 보장되지는 않는다. 입력을 잘못 읽거나 외부 서비스가 실패할 수 있다. 다만 시간이 처음부터 부족한 업무를 구별하는 데에는 쓸 수 있다. 특히 사람의 승인을 0분으로 놓으면, 이동 중이거나 회의 중인 담당자에게 성립하지 않는 계획이 된다.

가상 사례: 오전 일정 변경을 점심에 발견한다면

작은 스튜디오의 담당자가 오전 11시에 고객과 만난다고 하자. 고객은 오전 9시 5분에 장소 변경 메일을 보낸다. 설명을 위해 앱 확인이 9시와 12시에 이뤄진다고 가정한다. 세 시간은 Duet의 실제 설정값이나 측정값이 아니다.

이 경우 발견까지 175분이 걸린다. 초안 준비 5분, 담당자 승인 대기 20분, 일정 수정과 전달 5분을 더하면 도착 후 총 205분, 즉 12시 30분이다. 메일 도착 때 마감까지 남은 시간은 115분이므로 90분 늦다. 답장 문구가 정확해도 이 업무는 제때 끝나지 않는다.

반면 다음 날 검토할 미수금 안내 초안을 모으는 일이라면 몇 시간 늦게 발견해도 여유가 있을 수 있다. 차이는 ‘일정 관리인가 회계인가’라는 분야보다 언제까지 사람이 결정해야 하며, 놓쳤을 때 되돌릴 수 있는가에 있다. 하루 뒤 초안도 고객에게 잘못 보내면 문제가 되므로 발견 여유와 발송 검토는 따로 남긴다.

첫 업무를 고르는 접수표

다음 표는 위 가상 스튜디오의 운영 제안이다. 실제 Duet가 각 경우를 성공했다는 시험 결과가 아니다. 첫 사용 때 자기 업무의 마감과 담당자를 넣어 바꿔 쓸 수 있다.

업무	먼저 맡길 결과	사람이 유지할 경로
내일 이후 회의 준비	참석자·쟁점·미확인 질문의 브리핑 초안	원문 일정과 최신 메일 대조
며칠 뒤 확인할 미수금	청구서별 근거와 안내문 초안	입금 반영 여부 확인 후 수신자별 발송 판단
오늘 몇 시간 안에 바뀔 장소·예약	확인된 변경을 정리하는 보조 자료	기존 캘린더 알림과 담당자의 직접 확인
수분 내 대응해야 하는 장애	사후 요약이나 참고 자료	별도 운영 경보·당직 체계

중요한 것은 ‘읽기만 허용하면 언제나 적합하다’는 결론이 아니다. 읽기 업무라도 회의 직전에 틀린 장소를 알려주면 손실이 생긴다. 반대로 충분한 검토 시간을 둔 초안 준비는 외부 행동 없이도 도움이 된다. 자동화의 첫 범위를 실패를 발견할 여유가 있는 결과물로 정하자는 제안이다.

아래는 이 사례를 맡길 때 사용할 수 있는 요청문이다. 앱에 설치되는 설정이나 실행을 확인한 프롬프트가 아니며, 정확한 확인 주기를 강제할 수 있다는 뜻도 아니다.

내일 이후 고객 회의를 준비하는 브리핑 초안을 만들어 줘.
지정한 캘린더와 고객 메일에서 근거를 찾고,
각 항목에 자료 시각·회의 시각·아직 확인하지 못한 내용을 적어 줘.
오늘 마감인 변경을 발견하면 그 마감과 발견 시각을 함께 알려 줘.
내가 답하지 않으면 외부에 보내지 말고 승인 대기 항목으로 남겨 줘.
이미 알린 일은 새 변경이 무엇인지 구분해서 알려 줘.
참석자에게 연락하거나 일정을 바꾸기 전에는 내용을 보여 줘.

여기서 자료 시각은 근거 문서가 언제 작성·갱신됐는지, 발견 시각은 에이전트가 언제 알아차렸는지를 뜻한다. 이를 함께 적으면 늦게 온 자료와 늦게 발견한 자료를 구별할 수 있다. 날짜만 있는 원문이라면 임의로 시·분을 채우지 말고 미확인으로 남긴다.

대화·Tasks·Make에서 각각 무엇을 확인할까

도움말은 주 대화에서 완료나 결정 요청을 받고, Tasks에서 진행 중인 일과 사용자 입력이 필요한 일을 확인하며, Make에서 완성된 산출물을 찾는다고 설명한다. 작업 완료 표시는 사용자가 결정한다. 현재는 에이전트의 브라우저를 보거나 조작권을 넘겨받을 수 없다고도 명시한다. 작업과 화면 역할

위 사례에 적용하면 대화에서는 “오늘 회의 장소가 달라졌다는 주장”을, Tasks에서는 “담당자 답을 기다리는 상태”를, Make에서는 “검토할 브리핑 파일”을 찾아야 한다. 파일이 있다는 이유로 연락까지 끝났다고 결론 내리지 않는 식이다. 이 구분은 문서에 근거한 역할 설명이며, 화면의 좌우 배치나 모바일 메뉴 위치를 직접 확인한 안내는 아니다.

휴대폰에서 짧게 검토할 때는 한 화면에서 판단할 단위를 줄이는 편이 낫다. 요청할 요약의 첫 부분에 할 일·마감·변경 근거·승인할 대상을 두고, 긴 원문과 비교 자료는 뒤에 붙여 달라고 할 수 있다. 큰 화면에서는 원문과 초안을 나란히 대조하는 방식이 유용하다. 이는 독자를 위한 검토 방법 제안으로, Duet가 제공하는 분할 화면 기능을 말하지 않는다.

승인 단계도 확인해야 한다. 공식 발표는 메시지 발송·결제·서명·삭제 전에 사용자에게 내용을 보여주고 승인을 기다리는 설계라고 설명한다. 이 보호 장치의 실제 성공률을 이 글에서 검증한 것은 아니다. 승인 설계

승인 요청이 왔을 때는 내용 외에 시점도 보자. 오전 10시에 유효했던 일정 수정이 오후에는 이미 끝난 회의일 수 있다. 이때 이전 요청을 그대로 승인하기보다 현재 상태를 다시 읽고 아직 필요한 행동인지 확인하도록 요청하는 것이 이 사례의 운영 규칙이다.

알림이 적다고 좋은 비서라고 판정하지 않는다

선제적 에이전트에는 조용히 놓친 일이 생길 수 있다. 알림을 받지 않았다는 사실만으로 처리할 일이 없었다고 결론 내릴 수 없다. 반대로 알림이 많이 왔다고 일을 많이 덜어 준 것도 아니다. 첫 업무를 평가할 때 아래 네 상황을 원래 업무 기록과 대조해 보자.

비교할 상황	남길 기록	다음 조정
필요한 알림이 제때 옴	근거 시각·발견 시각·사람의 결정	같은 종류의 업무를 더 맡길지 검토
알림은 맞지만 마감 뒤에 옴	원래 마감과 실제 발견 시각	더 이른 준비 업무로 범위 축소
같은 내용이 반복됨	새 정보가 있었는지·반복 확인 시간	변경이 있을 때 알릴 기준 구체화
나중에 사람이 누락을 발견함	원래 자료와 발견 경로·놓친 결정	해당 종류를 직접 확인 경로에 유지

누락은 받은 알림만 읽어서는 찾을 수 없다. 첫 회차에는 특정 고객이나 한 주의 일정처럼 범위를 제한하고, 원래 메일·일정과 대조할 사람이 있어야 한다. 이를 장기간 모든 계정에 반복하면 확인 비용이 커질 수 있으므로, 범위를 넓힐지는 그 비교 부담까지 보고 정한다.

효과도 “요약 몇 건”보다 줄어든 확인 시간에서 새로 든 검토·수정 시간을 뺀 값으로 보는 편이 업무에 맞다. 이 값은 아직 측정하지 않았다. 알림을 늦게 확인한 이유가 앱의 발견 지연인지, 담당자의 승인 대기인지 구별해야 다음 조치도 달라진다.

제공 범위가 열렸을 때의 첫 선택

자료가 여러 앱에 흩어져 있고, 놓치기 쉬운 준비 업무가 있으며, 사람이 검토할 여유가 있다면 Duet의 선제적 접근을 시험할 이유가 있다. 지금 가장 큰 문제가 수분 내 대응, 지원되지 않는 연결, 직접 보며 조작해야 하는 브라우저 작업이라면 먼저 그 조건을 해결해야 한다. 기능 소개만으로 모든 업무의 위임 가능성을 판단하기는 어렵다.

이 글의 접수표를 저장해 두고, 접근 권한을 얻은 시점의 공식 도움말과 대조해 한 가지 업무부터 정해 보자. 목표와 기억을 어떻게 전달할지가 남았다면 Muse의 목표·기억·승인 분석, 로컬 입력과 클라우드 작업의 관계가 궁금하다면 Dots의 작업 위치 분석으로 이어 읽을 수 있다. 검토 시간을 포함한 도입 판단은 에이전트의 업무 완료 비용에서 다룬다.