출처: https://www.youtube.com/watch?v=eSP7PLTXNy8 · 채널 Claude (Anthropic) · 길이 22:03 포맷 Code w/ Claude 워크숍 — Maya Nielan(Anthropic Applied AI 팀, Member of Technical Staff)의 단독 발표 + 라이브 데모(터미널, claude.ai/code, GitHub) 원본 자막:
raw/transcripts/2026-07-12-proactive-agent-workflow-claude-code.en.srt(en 자동자막)
한눈에 보는 요약
- 문제의식: 프로액티브 에이전트를 직접 만들려면 ①어디서 실행할지(호스팅·영속성·인증), ②언제 실행할지(트리거 인프라), ③사람이 어떻게 개입할지(헤드리스 세션은 사실상 보이지 않는다)라는 세 가지 인프라 부담을 스스로 져야 한다.
- Routines는 프롬프트·저장소·커넥터·트리거만 정의하면 나머지는 Claude Code가 처리하는, Anthropic 클라우드에서 지속 실행되는 자동화 기능이다. 상시 가용(노트북과 무관), 커스터마이즈 가능한 트리거(스케줄/GitHub 이벤트/웹훅), 웹·CLI·데스크톱에서 열람·개입·재개 가능한 세션이라는 세 원칙으로 설계됐다.
- 어떤 루틴이든 설계 시 트리거(언제)·컨텍스트(무엇을 알아야)·스티어링(어떻게 정직하게 유지할지) 세 결정을 내려야 한다는 프레임을 제시하고, 각각을 Anthropic 내부의 문서 자동화 루틴으로 실증한다.
- 실사례: 새해 이후 Claude Code 주간 PR이 200% 늘며 문서 담당 엔지니어가 과부하됐고, 그가
/schedule한 줄로 “주간 소스-문서 diff → PR 생성” 루틴을 만든 뒤, GitHub 이슈를 트리거로 하는 두 번째 루틴까지 라이브로 만들고 실행해 보인다. - 마지막으로 deploy verifier · on-call investigator · backlog triager 등 각자의 워크플로우에 적용할 수 있는 루틴 아이디어를 제시하며 “프로액티브가 리액티브를 이긴다”로 마무리한다.
핵심 한 줄: Claude Code Routines는 트리거·컨텍스트·스티어링 세 가지만 설계하면 인프라 없이 “도구”를 “팀원”으로 바꿔주는 클라우드 자동화 기능이다.
장면별 상세 설명
[00:00] 1. 발표자 소개 — Applied AI 팀의 Maya Nielan
Maya Nielan(Anthropic Applied AI 팀, Member of Technical Staff)이 발표자다. 근무 시간의 절반은 Anthropic 자체 제품·기능 개발에, 나머지 절반은 고객이 Anthropic 모델 위에 자체 제품·기능·에이전트를 만들도록 돕는 데 쓴다고 자신을 소개한다. 오늘 주제는 “Claude Code로 프로액티브 에이전트 워크플로우 만들기”이며, 청중에게 곧바로 “Claude Code 안의 routines 기능을 써본 사람?”이라고 물으며 시작한다.
[01:10] 2. “Claude Code를 cron으로 돌려본 사람?”
이어서 “Claude Code를 cron 위에서 돌려본 사람?”을 묻고, 그 인프라를 만들고 유지보수하는 게 즐거웠는지까지 되묻는다. 손을 든 사람이 거의 없다는 반응에 Maya는 “Anthropic 내부에서도 프로액티브 에이전트를 개발하며 똑같은 고통을 느꼈고, 그래서 뭔가 조치하기로 했다”고 문제의식을 공유한다.
[02:15] 3. 핵심 명제 — “도구가 아니라 팀원을 만들자”
이번 발표의 명제는 “코딩 에이전트는 여러분이 엔터를 누를 때까지 기다리면 안 된다” 다. 지금의 Claude Code는 강력한 코딩 도구지만, 이를 강력한 코딩 팀원으로 바꾸고 싶다는 것. 팀원은 무언가 깨진 걸 스스로 알아채고 조치하지만, 도구는 사람이 프롬프트를 입력하고 엔터를 눌러야만 움직인다. 오늘 발표는 이 전환을 가능하게 하는 신기능 Routines를 소개하는 것이며, 4부로 구성된다 — ① 프로액티브 에이전트를 직접 만들 때의 어려움, ② Routines 기능 소개, ③ Anthropic이 내부적으로 문서 자동화에 Routines를 쓴 실제 사례, ④ 이를 각자의 워크플로우에 적용하는 법.
[03:00] 4. 프로액티브 에이전트를 만들 때의 세 가지 어려움
직접 만드는 게 불가능하진 않지만, 다음 세 가지가 번거롭다.
- 어디서 실행할까(Where to run): 로컬 머신에 두면 노트북을 닫거나 배터리가 죽는 순간 세션이 끝난다. 결국 호스팅·데이터 영속성·인증까지, “프롬프트 바깥의 모든 것”을 직접 인프라로 쌓아야 한다.
- 언제 실행할까(When to run): PR이 열리거나 알림이 울렸을 때 세션을 깔끔하게 띄울 방법이 없다. cron을 만들거나 직접 엔드포인트를 세워야 한다.
- 어떻게 함께 일할까(How to partner): 헤드리스로 띄운 세션은 지금 뭘 하는지 실시간으로 알기 어렵다. 지켜보거나, 조종하거나, 범위를 제한하거나, 재개할 방법이 마땅치 않다.
[04:50] 5. Routines란 무엇인가
이 세 문제에 답하기 위해 만든 것이 Routines, Claude Code의 신기능이다. 프롬프트, 연결할 저장소, 사용 가능한 커넥터, 트리거만 정의하면 나머지는 Claude Code가 처리하는 자동화다. 화면의 실제 예시(“Telegram Channel Improver”)를 보면 연결된 저장소 목록, cron 반복 주기, Datadog·Google Drive·Growthbook·PubMed·Slack 같은 커넥터, 상세 지시문, 최근 실행 세션 로그가 한 화면에 정리돼 있다 — 원격 Claude Code 세션을 이 조합 하나로 계속 트리거할 수 있다는 뜻이다.
[05:10] 6. Routines의 설계 원칙 세 가지
Routines를 만들며 지킨 세 가지 원칙이다.
- 관리형 인프라로 상시 가용 — Claude Code의 클라우드에서 실행되며 호스팅·세션 상태·커넥터 인증을 전부 처리한다. 노트북이 켜져 있을 필요가 없다.
- 커스터마이즈 가능한 트리거로 프로액티브하게 동작 — 시간 기반 스케줄뿐 아니라 임의의 HTTP 호출, 또는 GitHub 이벤트로 킥오프할 수 있고 이벤트 페이로드가 컨텍스트로 자동 로드된다.
- 상호작용·조종 가능한 에이전트 팀원 — 모든 실행은 그냥 Claude Code 세션이라서, 웹·CLI·데스크톱에서 열어보고 지켜보고 후속 지시를 하고 일시정지할 수 있다.
[06:30] 7. 내부 사례 도입 — “문서 자동화를 어떻게 할까”
Anthropic 내부에서 Routines를 실제로 어떻게 쓰는지 보여주기 위해, 새해 이후 Claude Code 주간 PR 건수가 200% 증가했다는 데이터로 시작한다. 엔지니어링 팀의 생산성엔 반가운 일이었지만, 이 여파를 고스란히 받은 사람은 Claude Code와 Agent SDK 문서를 유지보수하는 담당 엔지니어였다. Routines가 출시되자 그는 곧바로 열혈 얼리어답터가 되어 문서 자동화 루틴 두 개를 직접 만들었다.
[07:40] 8. 데모① /schedule로 첫 루틴 만들기
터미널에서 Claude Code를 열고 /schedule 뒤에 원하는 자동화를 그대로 문장으로 적으면 된다. 담당 엔지니어가 실제로 입력한 프롬프트:
/schedule Once a week review all the new changes merged to main against
claude-code-docs and create a PR to update docs.
이렇게 입력하면 Claude가 몇 가지를 되묻는다 — 매주 몇 시에 실행할지, PR을 만든 뒤 Slack으로 알려줄지 등. 답변을 마치면 Claude가 알아서 루틴을 완성한다.
[08:55] 9. 루틴을 만들 때 내려야 할 세 가지 결정
어떤 루틴을 만들든 반드시 세 가지를 결정해야 한다.
- Trigger — 언제 실행되는가?
- Context — Claude가 성공하려면 무엇을 알아야 하는가?
- Steering — Claude를 어떻게 정직하게(honest) 유지하는가?
이 세 축을 하나씩 문서 자동화 사례로 짚어간다.
[09:45] 10. 결정① 트리거 — 스케줄/릴리스/라벨 기반
트리거는 크게 시간 기반과 이벤트 기반으로 나뉜다.
- Schedule-based: 매주 문서 관련 GitHub 이슈나 변경을 리뷰(앞서 본 예시가 이 방식).
- Release-based: 릴리스가 컷되는 시점에 릴리스 브랜치를 문서와 diff해 새 기능·동작 변경에 맞춰 문서 PR이 필요한지 확인.
- Label-based: 엔지니어가 PR에 “need docs” 같은 라벨을 붙이면, 그 라벨이 붙은 PR이 머지되는 순간 루틴을 킥오프.
[10:45] 11. 결정② 컨텍스트 — 레포·커넥터·마케팅 자료
에이전트가 성공하려면 무엇을 알아야 하는지 생각해야 한다.
- Codebase repositories: 소스 코드 자체에 접근해 플래그·기본값·사용법 같은 세부사항을 파악해야 한다. 문서 자동화에는 소스 저장소뿐 아니라 문서 저장소도 함께 붙여야 Claude가 실제로 PR을 낼 수 있다.
- Connectors: 관련 툴·데이터소스에 연결한다. 이 사례에선 PR을 만든 뒤 Slack으로 알리도록 Slack 커넥터를 붙였다.
- Marketing briefs: 기존 마케팅 자료의 어투·용어를 참고해 문서가 “우리 목소리”처럼 들리게 하려고 Google Drive 커넥터로 관련 자료를 연결했다.
Maya는 “Claude가 가진 컨텍스트가 곧 Claude가 성공할 수 있는 천장(ceiling)“이라고 강조한다.
[12:15] 12. 결정③ 스티어러빌리티 — 품질을 어떻게 보장하는가
Claude의 산출물 품질을 지키는 세 가지 방법이다.
- Agent-on-agent review: 멀티에이전트 시스템에서 흔한 “생성자-비평가(generator-critiquer)” 패턴을 빌려왔다. 한 루틴이 문서 PR을 만들면, 그 PR 생성을 트리거로 삼는 또 다른 루틴이 사람이 보기 전에 먼저 리뷰 댓글을 남기게 할 수 있다.
- Human in the loop, not at the keyboard: 사람을 루프 밖에 두는 게 목표지만, 필요하면 웹이나 CLI에서 라이브 세션을 열어 지금 뭘 하고 있는지 묻거나 계획을 중간에 바꿀 수 있다.
- Verification: 결과를 실제로 실행해서 확인한다. 문서 예시라면 Claude Code CLI를 실행해 변경된 문서 페이지를 렌더링하고, 산출물이 기대한 것과 일치하는지 눈으로 확인한다.
[14:10] 13. 데모② 실제 운영 중인 루틴 열람
claude.ai/code의 Routines 패널에서 앞서 만든 루틴 “Weekly docs sync: claude-code-source-code → claude-code-documentation”를 연다. 상태는 Active, 다음 실행은 5월 25일 오전 10시, 연결된 저장소는 소스 코드·문서 두 개, 매주 월요일 오전 10시(GMT+1)에 실행되며 GitHub MCP와 Slack 커넥터가 붙어 있다. 지시문에는 “지난 7일간 main에 머지된 커밋을 GitHub MCP로 조회 → 사용자 노출(user-facing) 변경만 필터링(내부 리팩터·테스트 전용 변경은 건너뛰고, 애매하면 건너뛰는 쪽을 택함) → 이미 문서에 반영됐는지 확인 → 확신이 서는 경우에만 문서 PR 초안을 작성” 같은 상세한 판단 규칙이 담겨 있다.
[15:20] 14. 데모③ 세션이 실제로 만든 결과 확인
이 루틴이 어제 실제로 실행된 세션 로그를 열어보면, Claude가 지난 7일간 커밋 3개를 검토해 그중 Ls 툴 추가(0.3.2, 사용자 노출 변경)를 문서에 반영해야 한다고 판단하고 tools.mdx·changelog.mdx 두 파일을 수정했다. PR을 연 뒤 Slack #claude-code-doc-updates 채널에 요약과 PR 링크를 게시했고, “PR 작성자 계정이라 GitHub API로 리뷰 요청은 걸 수 없었지만 Slack 태그로 알림은 대신했다”는 것까지 스스로 보고한다 — 트리거·컨텍스트·검증이 실제로 맞물려 돌아가는 모습이다.
[16:20] 15. 데모④ 두 번째 루틴 — GitHub 이슈를 트리거로
이번엔 스케줄이 아니라 GitHub 이벤트로 킥오프하는 두 번째 문서 자동화 루틴을 라이브로 만든다. 이름은 “CwC Routine - Github docs creation”, 지시문은 “이 세션을 트리거한 이슈를 조사해 문서 갭인지 판단하고, 갭이면 PR을 열어 고치고 Slack 채널에 올린 뒤 나(Maya Nielan)를 태그하라. PR은 draft로 열어라”다. 트리거 선택 화면에는 Schedule·GitHub event·API 세 옵션이 있고, 여기서는 “GitHub 웹훅 이벤트가 발생하면 실행”하는 GitHub event를 선택한다. GitHub MCP와 Slack 커넥터가 이미 붙어 있으며, “커넥터의 모든 툴을 실행 중 승인 없이 쓸 수 있다”는 경고 문구도 함께 뜬다.
[17:00] 16. 데모⑤ 실제 GitHub 이슈로 트리거 발동시키기
트리거가 실제로 작동하는지 확인하려고 GitHub에서 새 이슈를 직접 만든다. 제목 “CwC Example - Missing docs for new version”, 본문 “Missing docs for new update. Figure out what tools are missing from docs in 0.3.2.” — 이 이슈가 문서 저장소에 등록되는 순간 issues.opened 이벤트가 발동해 방금 만든 루틴이 새 세션을 킥오프한다.
[17:40] 17. 데모⑥ 실시간으로 세션 조종하기
새 이슈가 등록되자 곧바로 루틴이 “Running” 상태로 잡힌다. 세션 안에는 <github-trigger-context> 블록으로 어떤 이벤트(issues.opened)가, 어느 저장소·이슈에서 발생했는지가 컨텍스트로 자동 주입돼 있고, Claude는 이슈를 읽으며 두 저장소를 동시에 탐색하는 중이다. 그런데 Maya는 같은 문제로 이미 PR을 열어둔 상태를 알고 있어서, 입력창에 “stop this session, I’ve already made these changes”라고 직접 타이핑해 실행 중인 세션을 그 자리에서 멈춰 세운다. 앞서 말한 “human in the loop, not at the keyboard” 원칙 — 웹이나 CLI에서 언제든 실행 중인 세션에 끼어들 수 있다는 것 — 을 실제로 보여주는 장면이다.
[18:10] 18. 다른 워크플로우로의 확장 — 배포 검증기·온콜·백로그 트리아저
문서 자동화 말고도 Routines로 옮길 만한 개발자 업무들을 트리거·컨텍스트·스티어링 프레임으로 짚어본다.
- Deploy verifier: CD 파이프라인이 배포마다 웹훅으로 POST하는 걸 트리거로 삼는다. 컨텍스트로는 방금 배포한 서비스의 소스 코드, 그리고 Datadog·Grafana 같은 모니터링 툴 접근 권한을 준다. 뭔가 이상하면 Slack·이메일·(Twilio 같은) 문자로 알리도록 커넥터를 붙인다. 스티어링은 단계적으로 넓힌다 — 처음엔 Claude가 조사만 하고 롤백 여부의 go/no-go 판단을 사람에게 넘기면, 사람이 웹에서 분석을 읽고 필요하면 Claude와 함께 롤백을 진행한다. Claude의 판단을 지켜보며 신뢰가 쌓이면, 점차 모니터링 데이터를 근거로 Claude가 스스로 롤백까지 하도록 맡길 수 있다.
- On-call investigator: 알리미(alerting)가 페이로드를 루틴에 POST하도록 해, 사람이 노트북을 열기 전에 먼저 상황을 조사(triage)하게 한다.
- Backlog triager: GitHub 이슈나 Slack 채널에 쌓인 백로그를 시간 기반 트리거로 매주 훑어, 중요한 이슈부터 PR을 열게 한다.
[21:13] 19. 마무리 — 세 가지 결론
발표를 세 문장으로 정리한다.
- 프로액티브가 리액티브를 이긴다 — “에이전트를 연다”에서 “에이전트가 PR을 연다”로.
- 인프라가 아니라 도메인·프로세스 전문성에 집중하라 — 인프라 유지보수는 Routines가 대신 처리해준다.
- 오늘 직접 루틴을 만들어 보라 —
/schedule명령 하나면 첫 번째 루틴을 만들 수 있다.
부록 — 실전 체크리스트
- 매번 수동으로 트리거하는 반복 작업 하나를 골라
/schedule <프롬프트>로 첫 루틴을 만들어본다. - 루틴을 설계하기 전에 트리거(언제)·컨텍스트(무엇을 알아야)·스티어링(어떻게 정직하게 유지할지) 세 가지를 먼저 문장으로 적어본다.
- 자동 생성된 PR·산출물은 사람이 보기 전에 다른 루틴으로 먼저 리뷰(agent-on-agent review)하게 하는 걸 검토한다.
- 배포 알림·온콜 알림·백로그처럼 반복되는 운영 업무를 deploy verifier / on-call investigator / backlog triager 패턴에 대입해본다.
- 처음엔 사람이 최종 판단(예: 롤백 여부)을 내리게 하고, Claude의 판단이 신뢰를 쌓으면 점진적으로 자동 실행 범위를 넓힌다.
원문 인용 모음
- [01:46] “We believe that coding agents shouldn’t wait for you to press enter to get started.”
- [01:57] “We want to take Claude Code and turn it into a really powerful coding teammate. A teammate notices when something breaks and does something about it.”
- [04:33] “It’s an automation where you can kick off a remote Claude Code session by only defining the prompt, what repos you want to connect it to, what connectors it has available to work with, and a trigger. Claude Code handles the rest.”
- [09:03] “Whatever context Claude has, that’s the ceiling of how successful Claude will be.”
- [12:12] “One thing that I think is quite interesting is to actually invest in agent-on-agent review… this is something that we’ve borrowed [from the generator-critiquer pattern].”
- [21:13] “Proactive agents beat reactive agents.”
- [21:33] “We built routines so you don’t have to focus on maintaining all of this infra, but instead you can actually concentrate on your domain and process expertise.”
- [21:54] “You’re a single slash schedule command away from creating your very first routine.”
관련 노트
- 2026-04-15-claude-code-routines — Routines 기능 출시 발표(HN 기사 기반) 종합 정리. 이 노트는 그 뒤 공개 워크숍에서 Anthropic이 직접 설계 원칙·내부 사례를 밝힌 1차 자료.
- moc-claude-code — Claude Code 종합 MOC
- 같은 컨퍼런스의 다른 워크숍 노트: 2026-07-10-how-we-claude-code, 2026-07-10-agents-that-remember, 2026-07-11-building-the-future-of-agentic-infrastructure, 2026-07-12-elicit-aepl-verifiable-agentic-workflows, 2026-07-12-fighting-financial-crime-with-claude-cowork