직접 만든 Claude 비서 3주, Duet과 뭐가 다를까

10월 21일, Anthropic이 AI 비서 Claude Duet을 리서치 프리뷰(research preview)로 공개했습니다. 미국의 Pro, Max 구독자가 대기 명단에 올라 순서대로 써 보는 단계라, 한국에서는 아직 쓸 수 없습니다. 저는 이미 Claude로 비슷한 비서를 만들어 쓰고 있었는데요.

제 비서는 평일 오전 9시 5분마다 회사 업무, 오픈소스 기여, 블로그와 커뮤니티를 확인하고 현황판에 정리합니다. 하지만 비서가 작성해준 현황판이 매번 완벽하진 않습니다. 가끔 할 일을 빼먹거나 중요 알림을 놓치기도 해서, 지금은 신입 비서 정도로 생각하고 쓰고 있습니다.

그럼 Anthropic이 만든 비서와 제가 만든 비서는 무엇이 다를까요? 지난 3주 동안 제 비서는 어디에서 얼마나 똑똑했고 어디에서 얼마나 멍청한 실수를 저질렀을까요?

AI 비서를 만들거나 업무에 들이려는 분들이 자동화 범위와 승인 기준을 정할 때 참고하시라고, 운영 중 발견한 실수와 개선 실험을 정리해봤습니다.

1. Claude 비서의 아침 브리핑

제 비서의 정체는 Claude 앱의 예약 작업(scheduled task)입니다. 모델은 Claude Opus 5.5이고 평일 오전 9시 5분에 실행됩니다.

주로 확인하는 영역은 4가지입니다.

업무 정보는 티켓 번호와 한 줄짜리 할 일만 현황판에 올리도록 제한했고, 회사 업무의 세부 내용은 이 글에서 다루지 않겠습니다.

비서는 확인한 결과를 JSON 파일 하나로 정리해 비공개 GitHub 저장소에 저장(커밋)합니다. Vercel에 배포한 현황판이 이 파일을 화면에 보여 주고, 전날과 달라진 내용이 있을 때만 휴대폰 알림을 보냅니다. 같은 상태가 며칠째 이어지는 항목은 ‘반복’으로 표시해서 매일 같은 알림이 오지 않게 했습니다.

연결한 도구는 PC 폴더 2개, Notion, Jira 커넥터, 웹페이지를 읽는 Chrome 확장입니다. 처음에는 Chrome으로 GitHub 웹 편집기를 조작해 커밋했는데, 토큰을 많이 쓰고 실수도 잦았습니다. 그래서 최근에는 PC에 내려받은 저장소에서 git으로 커밋하도록 바꿨습니다.

지시문도 역할별로 나눴습니다. 무엇을 어떤 순서로 할지와 금지 사항은 지시문에, 구체적인 작업 방식은 스킬 파일에, 자주 바뀌는 메모는 저장소의 마크다운 파일에 두고 있습니다. 규칙이 서로 부딪히면 지시문을 따르게 했습니다.

서버 대신 PC와 브라우저를 고른 이유

비서를 만들기 전, 웹에서 다른 사람들은 AI 비서를 어떻게 구현하는지 찾아봤습니다. 흔히 볼 수 있는 구조는 GitHub Actions에서 Python 스크립트를 실행해 GitHub 데이터를 수집하고, Claude API를 호출해 브리핑을 생성하는 방식이었습니다. 저는 조금 다른 방향을 선택했습니다. API를 직접 호출하는 대신, 제 계정으로 로그인된 Chrome 화면을 읽도록 했습니다. 서버에서 실행하는 대신, 제 PC에 설정한 예약 작업으로 비서를 움직이게 했습니다.

이유는 간단했습니다. 제가 확인하고 싶은 페이지 대부분이 로그인해야 볼 수 있는 곳이었기 때문입니다. GitHub 알림함이나 티스토리 관리자 통계처럼 로그인이 필요한 페이지가 대표적입니다. 하지만 이 방식에도 약점은 있었습니다. API는 정해진 형식으로 데이터를 반환하지만, 웹 화면은 사이트가 바뀌면 함께 바뀝니다. 로그인 세션이 만료되면 데이터에 아예 접근할 수 없기도 합니다.

3주간의 운영 기록

• 예약 작업을 만든 지 5주, 현황판에 기록을 남긴 지 3주
• 기록한 3주 동안 평일 15일 중 14일 실행 (공휴일 하루는 기록 없음)
• 일부 영역만 다시 돌린 것까지 포함해 실행 기록 23회, 데이터 커밋 48회
• 실행한 14일 중 11일은 오전 9시 16~26분 사이 현황판 갱신

2. 어디까지 알아서 하게 둘까?

비서에게 일을 맡기면서 가장 고민한 건 승인 기준이었습니다. 기준은 2가지입니다.

다른 사람에게 보이는 작업인가? 잘못했을 때 되돌리기 어려운가?

외부에 공개되는 작업은 비서가 문안을 작성해 현황판과 알림에 올리는 데까지만 진행합니다. 제가 내용을 확인하고 승인해야 실제로 게시됩니다.

추가 규칙도 하나 있습니다. 개인적인 오픈소스 활동과 업무가 섞이지 않도록, GitHub에 글을 쓰기 전에는 현재 로그인된 계정이 개인 계정인지 확인하고, 아니라면 작업을 중단하도록 했습니다.

3. 비서는 어디서 실수했을까?

3주간의 기록에서 회사 업무를 제외하고, 오픈소스 활동과 블로그 관리 중 발생한 실수 6개를 골랐습니다.

1) 스레드 흐름 놓치기

제가 참여한 GitHub 이슈에 메인테이너(maintainer)가 답변을 남겼는데, 비서가 이 알림을 놓쳐 나중에야 알게 되었습니다. 현황판만 믿고 있었다면 답변이 달렸다는 사실조차 모르고 지나갈 뻔했습니다. 원인을 살펴본 뒤, 이슈 타임라인 전체를 읽고 접혀 있는 댓글까지 펼쳐 확인하도록 바꿨습니다. GitHub 알림함도 별도로 열어 전날 이후 새 알림이 있으면 해당 스레드를 다시 확인하게 했습니다.

2) 기여 후보 상태 놓치기

zod #6657은 자동화 봇이 생성한 이슈였습니다. 비서는 이 이슈를 오픈소스 기여 후보로 등록했지만, 이틀 뒤 메인테이너가 PR #6661로 직접 수정하고 이슈를 닫았습니다. 제가 작업을 시작하기도 전에 기회가 사라진 겁니다. 이후에는 등록해 둔 기여 후보를 매일 다시 확인하도록 했습니다. 담당자가 정해졌는지, 연결된 PR이 생겼는지, 누군가 작업을 맡겠다는 댓글을 남겼는지 살펴보고, 이미 진행 중인 이슈는 후보 목록에서 제외하도록 했습니다.

3) 미완료 작업 멋대로 지우기

아침 점검 중 비서가 현황판에서 ‘네이버 서치어드바이저 캡처 보내기’라는 할 일을 삭제했습니다. 문제는 아직 보내지 않았다는 겁니다. 잘못 지운 항목을 복구하기까지 30분 가까이 걸렸습니다. 당시 비서는 실행할 때마다 할 일 목록을 처음부터 다시 구성하고 있었습니다. 그러다 보니 실제로 끝난 일과 끝나지 않은 일을 잘못 판단할 여지가 있었습니다. 그때는 일단 항목을 복구하는 데 그쳤습니다. 하지만 이 문제는 이후 5절에서 소개할 실험 2의 출발점이 됐습니다.

4) 댓글 작성 시각 못 읽기

비서는 댓글 옆에 표시되는 ‘3일 전’ 같은 상대 시간을 기준으로 새 댓글이 달렸는지 판단했습니다. 그런데 어느 날은 페이지에서 이 시간 표시를 하나도 찾지 못했습니다. 새로운 댓글이 있는지 확인할 근거 자체가 사라진 겁니다. 이후에는 화면에 표시되는 상대 시간 대신, 페이지 내부에 기록된 실제 작성 시각(createdAt)을 비교하도록 변경했습니다. 수정한 방식이 제대로 작동하는지 확인하기 위해 답을 이미 알고 있던 Vite 문서 번역 이슈를 테스트 대상으로 삼았습니다.

5) GitHub 검색에서 변경사항 놓치기

비서는 GitHub 검색을 이용해 제가 참여한 이슈에 새로운 움직임이 있는지 확인했습니다. 하지만 이날은 한 저장소에서 발생한 변화가 검색 결과에 나타나지 않았습니다. 저장해 둔 이슈 목록을 하나씩 열어 작성 시각을 비교하는 스크립트를 실행한 뒤에야 변화를 발견했습니다. 이후 검색의 역할을 나눴습니다. 새로운 PR과 이슈를 찾을 때는 검색을 활용하되, 이미 추적 중인 기여는 검색 결과에 의존하지 않고 직접 열어 확인하도록 했습니다.

6) 티스토리 통계 읽기 실패하기

티스토리 관리자 통계는 14일 중 6일 동안 읽지 못했습니다. 관리자 화면 대신 로그인 페이지가 나타났기 때문입니다. 매번 로그인 문제를 해결할 수는 없으니, 우선 통계를 읽지 못했을 때의 처리 방식을 바꿨습니다. 전날 수치를 유지하되 ‘어제 값’이라고 표시하고, 로그인 문제가 처음 발생한 날에만 알림을 보내도록 했습니다. 적어도 오래된 수치를 최신 데이터인 것처럼 보여 주거나, 같은 문제로 매일 알림이 쌓이는 일은 피할 수 있게 했습니다.

실수의 원인은 모델의 판단력만이 아니었다

6가지 사례를 살펴보면 원인이 조금씩 다릅니다. 1번, 4번, 5번, 6번은 페이지나 데이터를 제대로 읽지 못한 문제였습니다. 2번은 기여 상태를 계속 추적하지 못한 문제였고, 3번은 할 일 목록을 관리하는 방식에서 발생했습니다. 물론 모든 실수를 이렇게 명확하게 나눌 수 있는 건 아닙니다. 데이터를 제대로 읽지 못하면 판단도 틀릴 수 있고, 판단이 맞더라도 상태를 관리하는 방식 때문에 문제가 생길 수 있습니다.

그래도 기록을 돌아보며 확인한 건, 복잡한 추론을 잘못한 경우보다 화면이 예상과 다르게 나타나거나 필요한 정보를 읽지 못한 경우가 더 많았다는 점입니다. 특히 4번과 6번은 1절에서 설명한 화면 읽기 방식의 한계가 그대로 드러난 사례였습니다.

문제는 비서의 본 작업에서만 발생하지 않았습니다. 별도로 설정해 둔 일회성 알림 예약도 두 차례 실행되지 않은 채 꺼졌습니다. 기록을 확인해 보니 예약을 생성했던 대화 세션이 사라진 것이 원인이었습니다. 한 번은 그날 아침 점검 과정에서 이 문제를 발견했습니다. 이후에는 매번 새 세션에서 실행되는 예약으로 다시 설정했고, 이틀 뒤 정상적으로 실행되는 것을 확인했습니다.

4. Claude Duet과 다른 AI 비서 비교

Claude Duet은 미국의 Pro, Max 구독자를 대상으로 대기 명단을 받는 리서치 프리뷰로 공개된 상태입니다. 한국에서는 직접 써 보지 못해서 각 회사의 공식 도움말을 기준으로 비교했습니다. 아래 내용은 2026년 10월 29일 기준이고, 기능과 이용 조건은 바뀔 수 있습니다.

각 서비스의 공식 도움말을 기준으로 정리했고, 출처는 글 마지막에 있습니다.

Duet, Gemini, Copilot Cowork는 메시지를 보내거나 데이터를 바꾸고 지우는 일 앞에서 사람에게 묻습니다. 제가 정한 기준과도 비슷합니다. ChatGPT 예약 작업은 공식 도움말에서 그런 규칙을 찾지 못했고, 관리형 워크스페이스에서 관리자가 제한하면 승인이 필요할 수 있다는 안내만 있었습니다.

서비스마다 크게 갈리는 건 실행 시점입니다. 제 비서는 아침에 한 번 실행되지만, Copilot Cowork는 메일이나 Teams 메시지가 오면 바로 움직입니다. ChatGPT 예약 작업은 아직 웹훅 같은 이벤트 실행을 지원하지 않는다고 도움말에 적혀 있습니다. Duet은 정해진 간격으로 계정을 확인하고, 조용해진 대화를 다시 따라가 주며, 할 일의 완료 표시는 사용자만 할 수 있다는 점도 눈에 띄었습니다.

Duet도 Claude Opus 5.5로 돈다고 안내되어 있어서 제 비서와 모델이 같습니다. 그래서 둘의 차이는 모델보다 무엇을 확인하고 언제 사람을 부르도록 설계했느냐에서 나오는 것 같습니다. 근데 직접 써 본 비교가 아니라서 실제 성능까지 단정하지는 못하겠습니다.

5. Duet에서 아이디어를 가져와 개선해 보기

제 비서에 추가하고 싶은 규칙 2개를 골랐습니다.

• 오랫동안 답이 없는 기여를 다시 알려 주기
• 할 일의 완료 여부는 사용자가 정하기

새 규칙을 비서에 넣고 몇 주 기다리는 대신, 3주 동안 쌓인 현황판 데이터에 규칙을 적용해 봤습니다. 날짜별 마지막 버전을 기준으로 한 과거 기록 시뮬레이션이고, 실제 운영 결과는 아닙니다.

실험 1. 답이 없는 기여를 다시 알려 주기

측정 지표: 상대 답을 기다리는 열린 기여 중 N일 넘게 움직임이 없는 걸 비서가 먼저 짚은 수, 짚은 뒤 7일 안에 풀린 수

현재 비서는 새 움직임이 있을 때만 알립니다. 움직임이 없으면 아무리 오래 기다려도 ‘변화 없음’으로 넘어갑니다.

그래서 3주 넘게 답이 없는 기여가 5개(zod와 CDISC에 2개씩, getodk에 1개) 있었는데도 비서가 먼저 짚은 적은 없었습니다. 이 5개와 별개로 react-pdf 이슈는 알림 구독까지 꺼져 있어서, 답이 왔어도 모르고 지나갈 뻔했습니다.

새 규칙은 상대 답을 기다리는 열린 기여가 N일 동안 움직이지 않으면 할 일에 올리고, 정중한 댓글 초안을 붙이는 것입니다. 실제로 올리는 건 기존처럼 제가 승인한 뒤입니다.

7일 기준에서는 짚고 6일 만에 병합된 MDN 번역 PR도 짚게 됩니다. 가만히 둬도 풀렸을 기여까지 재촉하게 되는 셈입니다. 반면 14일 기준으로는 6개를 짚었고, 이 6개는 기록 마지막 날까지 모두 답이 없었습니다.

그래서 일단 14일을 기준으로 삼으려 합니다. 근데 표본이 10개, 기간이 3주뿐이고 저장소마다 답하는 속도도 달라서 더 지켜봐야 합니다.

실험 2. 할 일 완료는 사람이 표시하기

측정 지표: 끝나지 않았는데 현황판에서 빠진 할 일 수

현재 할 일 목록은 실행마다 처음부터 다시 만들어집니다. 이렇게 하면 실행할 때마다 결과가 새로 나와서 어제 상태와 꼬일 일이 없고 구조도 단순합니다. 대신 ‘아직 안 끝났다’나 ‘이건 안 할 거다’처럼 제가 정한 상태를 담아 둘 자리가 없습니다.

3주 동안 할 일 14개가 올라왔고 그중 10개가 중간에 목록에서 빠졌습니다. 끝났거나 더 이상 하지 않기로 한 일이 많았지만, 끝나지 않았는데 빠진 걸로 확인된 일도 1개 있었습니다.

그래서 비서가 만드는 항목과 제가 정한 상태를 따로 저장하기로 했습니다. 비서는 완료된 것 같다고 표시만 하고, 제가 ‘끝남’이나 ‘안 함’이라고 답해야 상태가 바뀝니다. ‘안 함’으로 처리한 일은 날짜와 이유도 남겨서 같은 일을 다시 제안하지 않게 했습니다.

과거 기록에 적용하면 끝나지 않은 일이 목록에서 빠지는 건 규칙상 0개가 됩니다. 대신 제가 직접 완료 여부를 확인해야 할 일이 3주 동안 10개 늘어납니다. 평일 하루 1개도 안 되니 감당할 만하다고 판단했습니다.

두 규칙 모두 아직 과거 기록에 적용해 본 단계입니다. 실제 비서에 반영한 뒤에도 같은 효과가 나는지는 다시 재 봐야 합니다.

마치며

3주간의 기록에서 자주 눈에 들어온 건 ‘어제 값’ 같은 표시였습니다.

비서가 똑똑하게 판단한 순간보다 무엇을 확인하지 못했는지 그대로 적어 둔 순간이 더 쓸모 있었습니다. 통계를 읽지 못했다면 전날 숫자라고 밝히고, 일이 끝난 것 같더라도 제가 확인하기 전에는 완료 처리하지 않는 식입니다.

AI 비서를 만들거나 업무에 들인다면, 자동으로 할 수 있는 일뿐 아니라 비서가 혼자 완료 처리하거나 삭제해도 되는 일도 함께 정해 두면 좋겠습니다.

Duet을 한국에서 쓸 수 있게 되면 같은 기록으로 다시 비교해 볼 생각입니다.

이 글은 AI의 도움을 받아 작성했습니다.

참고 자료

(모두 2026년 10월 29일 확인)

• Claude Duet 시작하기: https://support.claude.com/en/articles/17631495-get-started-with-claude-duet
• ChatGPT 예약 작업: https://help.openai.com/en/articles/10291617
• Gemini 예약 작업: https://support.google.com/gemini/answer/16316416
• Gemini 작업(Task) 모드: https://support.google.com/gemini/answer/17094507
• Copilot 예약 프롬프트: https://support.microsoft.com/en-us/microsoft-365-copilot/schedule-your-most-used-copilot-prompts
• Copilot Cowork 사용하기: https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/use-cowork

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.