"자동화" 태그로 연결된 5개 게시물개의 게시물이 있습니다.

또 한 단계 올라갔다​

Skills로 명령어를 통합하고, Routines로 예약 실행을 붙이고, Auto 모드로 권한 판단까지 AI에게 넘기더니, 이번엔 Claude가 오케스트레이션 스크립트를 직접 짜서 서브에이전트 수백 개를 한 세션에서 병렬로 돌리는 Dynamic Workflows가 2026년 5월 28일 Opus 4.8과 함께 공개됐어요.

지금까지의 서브에이전트는 Claude가 대화 턴마다 하나씩 띄우고 결과를 자기 컨텍스트로 받아오는 방식이었습니다. 몇 개까지는 괜찮지만, 500개 파일을 동시에 손봐야 하는 작업에서는 컨텍스트가 먼저 터집니다. Dynamic Workflows는 그 한계를 넘으려고 나온 기능입니다. (Anthropic 발표, TechCrunch)

주의: 이 글의 내용은 전부 리서치 프리뷰 기준입니다. 동작 방식, 한도, 요금 모두 정식 출시 전에 바뀔 수 있습니다. Claude Code v2.1.154 이상이 필요합니다.

한 줄 정의​

공식 문서의 정의는 명확합니다.

"A dynamic workflow is a JavaScript script that orchestrates subagents at scale." — Claude Code Docs

워크플로우는 Claude가 작성하는 자바스크립트 오케스트레이션 스크립트입니다. 사용자가 작업을 설명하면 Claude가 그 작업에 맞는 스크립트를 쓰고, 런타임이 그 스크립트를 백그라운드에서 실행합니다. 스크립트가 도는 동안 대화 세션은 그대로 응답 가능한 상태로 남습니다.

중요한 차이는 누가 계획을 들고 있느냐에 있습니다.

서브에이전트/스킬과 무엇이 다른가​

셋 다 멀티스텝 작업을 처리할 수 있습니다. 차이는 계획의 주체와 중간 결과의 저장 위치입니다.

서브에이전트와 스킬에서는 Claude가 오케스트레이터입니다. 무엇을 띄울지 턴마다 판단하고, 모든 결과가 Claude 컨텍스트로 돌아옵니다. 워크플로우는 그 루프와 분기, 중간 결과를 스크립트 안으로 옮깁니다. 그 결과 Claude 컨텍스트에는 최종 답만 남습니다. 그래서 컨텍스트가 터지지 않습니다.

어떻게 도는가​

작업을 워크플로우로 넘기면 세 단계를 거칩니다.

대화 세션은 이 흐름 내내 자유롭습니다. /workflows를 실행하면 진행 중인 런의 진행 화면이 뜨고, 단계별 에이전트 수와 토큰 사용량, 경과 시간을 볼 수 있습니다.

패턴 1: Fan-Out​

워크플로우가 시작되면 Claude가 프롬프트를 기준으로 계획을 세우고, 작업을 서브태스크로 쪼갠 뒤 여러 에이전트에 병렬로 펼칩니다. 이걸 fan-out이라 부릅니다. 한 런에서 수십에서 수백 개의 에이전트가 동시에 돕니다.

예를 들어 라우트 디렉토리 전체에서 인증 누락을 감사하라고 하면, 엔드포인트마다 에이전트 하나씩 붙여 동시에 점검합니다.

Run a workflow to audit every API endpoint
under src/routes/ for missing auth checks

프롬프트에 트리거 키워드를 넣으면 Claude Code가 그 단어를 강조 표시하고, 턴 단위로 처리하는 대신 워크플로우 스크립트를 작성합니다. 발표 직후에는 workflow가 트리거였지만, 2026년 6월 2일 v2.1.160에서 트리거 키워드가 ultracode로 바뀌었습니다. 이제 workflow라는 단어만으로는 런이 시작되지 않습니다. 다만 평소 쓰는 말로 워크플로우를 요청하는 건 그대로 동작합니다. (Claude Code Changelog)

패턴 2: 어드버서리얼 검증​

여기가 단순히 에이전트를 더 많이 돌리는 것과 갈리는 지점입니다. 워크플로우는 반복 가능한 품질 패턴을 적용합니다.

에이전트가 발견한 내용을 그냥 보고하지 않습니다. 다른 에이전트가 그 발견을 반박하는 임무를 맡습니다. 한 에이전트가 "이 함수에 race condition이 있다"고 주장하면, 다른 에이전트는 그 주장을 깨는 일을 맡습니다. 반박을 거치고도 살아남은 주장만 사용자에게 전달됩니다.

번들로 제공되는 /deep-research 워크플로우가 이 패턴을 그대로 씁니다. 여러 각도로 웹 검색을 펼치고, 찾은 출처를 서로 교차검증하고, 각 주장에 투표한 뒤, 교차검증을 통과하지 못한 주장은 걸러낸 인용 리포트를 돌려줍니다.

패턴 3: 수렴 반복​

고정된 단계의 파이프라인이 아닙니다. 워크플로우는 답이 더 이상 바뀌지 않을 때까지 반복합니다. 에이전트 수와 반복 횟수는 작업이 실제로 요구하는 바에 따라 실시간으로 정해집니다.

이 수렴 방식 덕분에 단일 패스로는 도달할 수 없는 결과까지 갑니다. 한 번 훑고 끝내는 게 아니라, 발견과 반박을 답이 안정될 때까지 돌리는 구조입니다.

실제 사례: Bun을 Zig에서 Rust로​

가장 인상적인 사례는 Jarred Sumner가 Bun 런타임을 Zig에서 Rust로 포팅한 작업입니다. 약 75만 줄 코드를 11일 만에 옮겼습니다. 파일마다 에이전트를 붙여 수백 개를 병렬로 돌렸고, 파일당 리뷰어를 두 명씩 뒀습니다. (Anthropic 발표)

Anthropic은 이 기능의 목표를 "코드베이스 규모의 마이그레이션을 킥오프부터 머지까지, 기존 테스트 스위트를 합격 기준으로 삼아 수행"하는 것으로 잡았습니다. (TechCrunch) 기존 테스트가 통과 여부를 판정하니, 사람이 일일이 검수하지 않아도 합격선이 정의됩니다.

발표의 표현을 빌리면 분기 단위로 계획하던 일이 며칠 만에 끝납니다. 다만 이건 잘 풀린 사례입니다. 테스트 커버리지가 부실한 코드베이스라면 합격 기준 자체가 흔들립니다.

한도와 제약​

런타임에는 다음과 같은 제약이 있습니다.

수백 개 병렬이라는 표현과 동시 16개가 충돌하는 것처럼 보이지만, 동시 실행은 16개로 묶이고 누적 총량이 런당 최대 1,000개라는 뜻입니다. (Claude Code Docs, MarkTechPost)

권한 측면도 짚어둘 만합니다. 세션 권한 모드와 무관하게, 워크플로우가 띄우는 서브에이전트는 항상 acceptEdits 모드로 돌고 파일 편집은 자동 승인됩니다. 긴 런에서 셸 명령이나 MCP 도구로 중간에 멈추고 싶지 않다면, 시작 전에 필요한 명령을 allowlist에 넣어두는 편이 낫습니다.

어떻게 켜고 끄는가​

워크플로우를 작성하게 하는 방법은 두 가지입니다.

발표 시점의 트리거 키워드는 workflow였으나 v2.1.160(2026년 6월 2일)에서 ultracode로 바뀌었습니다. 예전 글이나 영상에서 workflow라고 적으라는 안내를 봤다면 키워드만 바꿔 읽으면 됩니다.

ultracode는 xhigh effort(추론 강도)와 자동 워크플로우 오케스트레이션을 묶은 설정입니다. 켜두면 Claude가 작업마다 워크플로우가 필요한지 알아서 판단합니다. 한 요청이 여러 워크플로우로 갈라질 수도 있습니다. 코드 이해용 하나, 변경용 하나, 검증용 하나 식으로. 그만큼 토큰과 시간을 더 씁니다.

마음에 드는 런이 나오면 /workflows에서 그 런을 골라 s 키로 명령어로 저장할 수 있습니다. 프로젝트의 .claude/workflows/에 두면 저장소를 받은 모두가 쓰고, 홈의 ~/.claude/workflows/에 두면 저만 써요.

끄는 방법도 명확합니다.

• /config에서 Dynamic workflows 토글 끄기
• ~/.claude/settings.json에 "disableWorkflows": true
• 환경변수 CLAUDE_CODE_DISABLE_WORKFLOWS=1
• 조직 전체는 managed settings의 "disableWorkflows": true

요금과 가용성​

• 리서치 프리뷰. Claude Code v2.1.154 이상 필요
• 유료 플랜 전체에서 사용 가능 (Pro는 /config에서 켜야 함). 발표 기준 Max, Team, Enterprise는 기본 활성화
• Anthropic API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry 지원
• 토큰 소비가 일반 세션보다 크게 많습니다. 에이전트를 수십~수백 개 띄우니 당연합니다

비용 관리 팁도 문서에 있습니다. 큰 런 전에 /model을 확인하고, 강한 모델이 필요 없는 단계는 작은 모델로 라우팅하도록 작업 설명에 명시하면 됩니다.

함께 나온 Opus 4.8은 자기 작업의 불확실성을 더 적극적으로 드러내고, 근거 없는 주장을 덜 한다는 평가입니다. 어드버서리얼 검증 패턴과 맞물려 보면, 모델이 스스로 의심을 표하는 성향이 강해진 게 수백 개 에이전트를 신뢰하는 데 보탬이 됩니다. Fast 모드는 2.5배 속도로 동작하면서 이전 모델보다 3배 저렴해졌습니다. (Anthropic Opus 4.8 발표)

운영자 시각에서 한마디​

Dynamic Workflows의 본질은 에이전트를 더 많이 돌리는 게 아니라 계획을 코드로 옮기는 데 있습니다. 오케스트레이션이 읽고 다시 돌릴 수 있는 스크립트로 굳으면, 매 브랜치마다 같은 리뷰를 같은 방식으로 돌릴 수 있습니다. 일회성 마법이 아니라 반복 가능한 프로세스가 된다는 뜻입니다.

다만 지금은 리서치 프리뷰입니다. 한도도 동작도 바뀔 수 있고, 토큰 비용은 만만치 않습니다. 처음 쓴다면 작은 작업으로 범위를 좁혀 토큰 사용 패턴부터 감을 잡으라는 게 공식 권고입니다.

그래도 방향은 분명해요. 75만 줄 마이그레이션을 11일에 끝냈다는 사례가 과장이 아니라면, 분기 단위 작업의 정의가 다시 쓰이는 중이에요. Skills, Routines, Auto 모드에 이어 이번엔 오케스트레이션 자체가 자동화됐습니다. 따라가는 것만으로도 벅차지만, 한 번쯤 직접 /deep-research부터 돌려보는 게 감을 잡는 가장 빠른 길입니다.

참고 자료​

• Orchestrate subagents at scale with dynamic workflows — Claude Code Docs
• Introducing dynamic workflows in Claude Code — Anthropic Blog
• Introducing Claude Opus 4.8 — Anthropic
• Anthropic releases Opus 4.8 with new 'dynamic workflow' tool (TechCrunch)
• Anthropic Ships Claude Opus 4.8 Alongside Dynamic Workflows, Capped at 1,000 Subagents (MarkTechPost)

또 새 기능이다​

Claude Code를 쓰다 보면 이런 경험이 있을 거예요. 파일 하나를 수정할 때마다 "Allow?" 프롬프트가 뜨고, bash 명령을 실행할 때마다 또 떠요. 장시간 작업할 때는 Y 키를 누르는 게 일이 돼요.

그래서 나온 게 Auto 모드입니다. 2026년 3월 24일, 리서치 프리뷰로 공개됐습니다.

Auto mode lets Claude handle permission prompts automatically — Claude checks each tool call for risky actions and prompt injection before executing.

쉽게 말하면, 권한 승인을 AI가 대신 판단해 주는 모드입니다.

기존 권한 모드 복습​

Auto 모드를 이해하려면 기존 모드부터 알아야 합니다. Shift+Tab으로 전환할 수 있는 모드들입니다.

핵심 차이:

• default/acceptEdits: 사람이 판단
• auto: AI 분류기가 판단
• bypassPermissions: 아무도 판단 안 함 (위험)

어떻게 동작하나​

Auto 모드는 2단계 파이프라인으로 각 도구 호출의 안전 여부를 판단합니다.

1단계: 입력 검사와 프롬프트 인젝션 탐지​

도구 실행 결과가 에이전트의 컨텍스트에 들어가기 전에, 서버 측에서 프롬프트 인젝션 시도를 스캔합니다. 파일이나 웹페이지에 숨겨진 악성 지시를 감지하면 경고를 붙입니다.

2단계: 출력 검사와 트랜스크립트 분류기​

실제 도구 호출 전에 Claude Sonnet 4.6 기반 분류기가 행동의 위험성을 평가합니다.

Stage 1: 빠른 1토큰 Yes/No 필터
  ↓ (위험 가능성 있으면)
Stage 2: Chain-of-thought 추론으로 정밀 판단
  ↓
결과: 승인 또는 차단

• Stage 1에서 대부분의 안전한 작업이 바로 통과
• 의심스러운 것만 Stage 2로 넘어가서 정밀 검토
• 분류기는 사용자 메시지, 도구 호출, CLAUDE.md 내용을 참조
• 도구 실행 결과는 분류기에게 보이지 않음 (인젝션 방지)

뭘 막고 뭘 허용하나​

기본 차단 항목​

• curl | bash 같은 다운로드 후 실행 패턴
• 외부 엔드포인트로 민감 데이터 전송
• 프로덕션 배포 및 마이그레이션
• 클라우드 스토리지 대량 삭제
• IAM/리포 권한 변경
• main에 직접 push 또는 force push
• 세션 이전에 존재하던 파일의 비가역적 삭제

기본 허용 항목​

• 작업 디렉토리 내 로컬 파일 작업
• 매니페스트에 선언된 의존성 설치
• .env 읽기 및 해당 API로의 인증 정보 전송
• 읽기 전용 HTTP 요청
• 시작 브랜치 또는 Claude가 생성한 브랜치에 push

차단 시 동작​

분류기가 차단하면 Claude는 이유를 전달받고 다른 접근법을 시도합니다. 연속 3회 또는 세션 내 20회 차단되면 Auto 모드가 일시 중단되고 사용자에게 직접 물어봅니다.

정확도는​

Anthropic이 공개한 수치:

17%의 미탐(false negative)이 눈에 띕니다. Anthropic도 이걸 숨기지 않고 공개했습니다. "완벽하지 않다"는 걸 솔직하게 인정한 것입니다.

즉, 100번 중 17번은 위험한 행동이 통과할 수 있습니다. 그래서 격리된 환경에서의 사용을 계속 권장하는 것입니다.

요금과 제한​

• Pro 플랜: 사용 불가
• Max, Team, Enterprise, API: 사용 가능
• 분류기 호출이 토큰 사용량에 포함되어 약간 더 비쌈
• 읽기와 작업 디렉토리 내 파일 편집은 분류기를 건너뛰므로 추가 비용 없음
• 셸 명령, 네트워크 작업에서 주로 추가 비용 발생
• Claude Code v2.1.83 이상 필요

주의할 점​

컨텍스트 압축 문제​

대화 중에 "main에 push하지 마" 같은 경계를 설정해도, 컨텍스트 압축(compaction)이 해당 메시지를 날려버리면 분류기가 그 경계를 인식하지 못합니다.

해결하려면 대화로 경계를 설정하지 말고, 명시적 deny 규칙을 설정 파일에 넣어야 합니다.

상속된 권한 문제​

Auto 모드의 분류기는 개별 행동을 평가하지, 전체 맥락에서의 의도를 파악하지는 못합니다. IAM 수정이나 curl | bash 같은 패턴은 차단하지만, 개별적으로는 무해해 보이는 여러 행동이 합쳐져서 위험해지는 경우는 놓칠 수 있습니다.

이전 취약점 이력​

Claude Code에는 이미 보고된 CVE가 있습니다.

• CVE-2025-59536: 악성 .claude/settings.json을 통한 원격 코드 실행
• CVE-2026-21852: 악성 MCP 서버를 통한 API 키 유출

Auto 모드가 이런 공격 벡터를 완전히 차단하지는 못합니다.

bypassPermissions 대신 Auto를 써야 하는 이유​

이전에 장시간 작업을 위해 bypassPermissions(또는 --dangerously-skip-permissions)를 쓰던 사람들이 있습니다. Auto 모드는 그 대안입니다.

공식 문서에서도 이렇게 말합니다.

"For background safety checks without prompts, use auto mode instead."

활성화 방법​

# CLI 플래그
claude --permission-mode auto

# 또는 실행 중 Shift+Tab으로 전환

# 기본값으로 설정
# settings.json에서:
# "permissions": { "defaultMode": "auto" }

Team/Enterprise 플랜에서는 관리자가 먼저 활성화해야 사용자가 접근할 수 있습니다.

커뮤니티 반응​

GeekNews(news.hada.io)에서도 Auto 모드 소식이 다뤄졌습니다. 댓글 반응이 인상적입니다.

"하루가 다르게 발전하는군요"

"일상이 바뀔 수 있을 정도의 파급력이 있는 기능이 하루 걸러 하나씩 나와버리네요"

저도 공감해요. Anthropic의 릴리즈 속도는 정말 따라가기 벅찰 정도예요.

마무리​

Auto 모드는 "매번 Y를 누르는 귀찮음"과 "아무 검사 없이 전부 실행하는 위험함" 사이의 중간 지점입니다.

편리합니다. 하지만 17%의 미탐률이 있고, 컨텍스트 압축 문제가 있고, 격리 환경에서 쓰라는 권장 사항이 있습니다. 리서치 프리뷰인 만큼 앞으로 개선될 여지가 있지만, 지금은 편리함과 위험 사이의 트레이드오프를 이해하고 쓰는 것이 중요합니다.

개인 프로젝트에서 장시간 코딩 세션을 돌릴 때라면 충분히 쓸 만해요. 프로덕션 인프라에 접근 가능한 환경이라면 아직은 아니에요.

이 글은 2026년 4월 기준 리서치 프리뷰 상태를 바탕으로 작성했어요. 정식 출시 후 동작, 정확도, 요금이 변경될 수 있어요.

참고 자료​

• Auto mode for Claude Code (Anthropic Blog)
• Claude Code auto mode: a safer way to skip permissions (Anthropic Engineering)
• Choose a permission mode (Claude Code Docs)
• Claude Code Auto Mode 공개 (GeekNews)
• Anthropic hands Claude Code more control (TechCrunch)
• What Auto Mode Means for AI Agent Privilege Management (Apono)

또 나왔다​

Anthropic이 자꾸 뭔가를 내놓네요.

Claude Code 데스크톱 앱이 나왔나 싶더니, 이번엔 Routines라는 기능이 2026년 4월 14일에 리서치 프리뷰로 공개됐습니다. Claude Code에서 프롬프트를 한 번 짜두면, 정해진 시간에 혹은 특정 이벤트가 발생할 때 알아서 실행되는 자동화 기능입니다.

쉽게 말하면 "AI cron job"입니다.

주의: 이 글에서 다루는 내용은 전부 리서치 프리뷰 기준입니다. API, 실행 한도, 동작 방식 모두 정식 출시 전에 바뀔 수 있습니다. "오 좋은데?" 하고 프로덕션에 넣었다가 다음 달에 스펙이 바뀌면 본인 책임입니다.

Routines가 뭔데​

루틴은 Claude에게 시킬 작업을 담은 프롬프트, 작업 대상 코드베이스인 GitHub 저장소, Slack, Linear, Google Drive 같은 외부 서비스를 잇는 MCP 커넥터를 하나로 묶습니다.

이걸 한 번 설정하면 Anthropic 클라우드 VM에서 실행됩니다. 제 노트북이 꺼져 있어도 돌아갑니다. 퇴근하고 자는 동안에도 돌아갑니다.

어떻게 실행되나​

트리거는 세 종류입니다.

하나의 루틴에 여러 트리거를 동시에 걸 수 있습니다. 예를 들면:

• 매일 밤 11시 + PR 열릴 때 + Sentry 알림 API 호출 → 같은 루틴이 세 가지 상황에서 모두 실행

활용 예시​

• 매일 밤 이슈 트래커를 읽어서 라벨 붙이고 Slack에 요약 보고
• PR 열릴 때 팀 코드 리뷰 체크리스트 자동 적용
• 에러 알림 임계값 초과 시 수정 PR 초안 자동 생성
• 배포 후 스모크 테스트 자동 실행
• 주간 스캔으로 API 변경 사항을 반영한 문서 업데이트 PR 생성

꽤 그럴듯합니다. 그럴듯한데, 아직 베타입니다. 잊지 말아야 합니다.

요금은​

• 루틴 실행은 기존 구독 사용량에 포함됩니다
• "Extra Usage" 활성화 시 한도 초과분은 추가 과금으로 계속 실행됩니다
• Free 플랜은 사용할 수 없습니다

하루 5회가 많아 보이지 않을 수 있지만, 잘 설계된 루틴 하나가 수동 작업 30분을 대체한다면 충분할 수도 있습니다.

ChatGPT Tasks랑 뭐가 다른데​

이런 류의 기능하면 ChatGPT Tasks가 먼저 떠오를 수 있습니다. 근데 성격이 꽤 다릅니다.

ChatGPT Tasks는 "내일 아침에 이거 확인해"라고 알려주는 알람 앱입니다. Claude Routines는 "내일 아침에 이거 확인하고 PR까지 만들어놓을게"라고 하는 자동화 에이전트입니다.

방향 자체가 다릅니다.

좋은 점​

알림만 보내는 데 그치지 않고 코드 수정, PR 생성, Slack 메시지까지 실제로 수행하는 진짜 자동화입니다. 스케줄, API, GitHub 이벤트를 하나의 루틴에 동시에 설정하는 다중 트리거도 지원합니다. 클라우드 실행이라 로컬 머신에 의존하지 않습니다. 퇴근해도 돌아갑니다. MCP 커넥터에는 Slack, Linear, Google Drive 등 외부 서비스 연동 기능이 내장되어 있습니다.

우려되는 점​

여기서부터가 진짜 중요합니다.

리서치 프리뷰라는 것​

정식 출시가 아닙니다. API 스펙, 실행 한도, 트리거 동작 방식 전부 바뀔 수 있습니다. Anthropic도 공식 문서에서 이 점을 명시하고 있습니다. 프로덕션 워크플로우에 넣기에는 이릅니다.

개인 계정에 묶인다​

루틴은 개인 claude.ai 계정에 귀속됩니다. 팀원과 공유할 수 없고, 루틴이 만든 커밋/PR은 해당 개인 이름으로 찍힙니다. 팀 단위 운영이 어렵습니다.

보안 이슈​

자율 실행 중 문서에 숨겨진 악성 지시를 따를 수 있는 프롬프트 인젝션 위험이 있습니다. Anthropic 자체 보고로 공격 성공률은 ~1%입니다. CVE 2건도 보고됐습니다. RCE 취약점(CVE-2025-59536)과 API 키 유출(CVE-2026-21852)입니다. 데이터 학습의 경우 Pro/Max 플랜은 AI 학습을 위한 데이터 사용이 기본 ON이고, Enterprise만 OFF입니다.

벤더 락인​

루틴 설정이 Anthropic 클라우드에 저장됩니다. git에 백업되지 않습니다. 나중에 다른 도구로 갈아타고 싶어도 이식할 방법이 없습니다.

사내에서 쓸 수 있을까​

솔직히 말하면, 지금 당장 프로덕션에 넣기는 이르다고 봐요.

가능한 부분​

• Team/Enterprise 플랜에서 사용 가능
• SOC 2 Type 2, ISO 27001 인증 있음
• Enterprise는 클라우드 세션 감사 로그 지원
• 네트워크 프록시로 개인 계정 차단 가능 (Enterprise)

아직 안 되는 부분​

현실적 접근법​

먼저 Team 플랜으로 파일럿을 진행합니다. 비규제, 비프로덕션 환경에서 테스트하는 방식입니다.

MCP 커넥터는 제한해야 합니다. 읽기 전용이면서 관리자가 승인한 것만 허용합니다.

정식 출시를 기다리는 방법도 있습니다. GA 후 Enterprise 세일즈와 감사 로그/권한 제어를 확인합니다.

규제 데이터는 금지합니다. PII, 금융, 의료 데이터에는 절대 사용하지 않습니다.

마무리​

Anthropic이 정말 쉬지 않고 무언가를 내놓고 있습니다. Subagents가 나왔나 싶더니 Agent Teams가 나오고, 이제는 Routines까지 나왔습니다. 따라가는 것만으로도 바쁩니다.

Routines의 컨셉 자체는 매력적입니다. "AI가 밤새 일한다"는 말이 과장이 아닌 시대가 정말 오고 있습니다. 하지만 지금은 리서치 프리뷰입니다. 흥미롭게 지켜보되, 프로덕션에 넣는 것은 아직 참아야 합니다.

한 가지 확실한 건, AI 도구의 변화 속도가 이전과는 차원이 다르다는 거예요. 정신 차리고 따라가야 해요. 아니면 어느 날 제 자리에서 루틴이 일하고 있을지도 모르겠어요.

이 글의 내용은 2026년 4월 16일 기준 리서치 프리뷰 상태를 바탕으로 작성되었습니다. 정식 출시 후 기능, 요금, 제한 사항이 달라질 수 있습니다.

참고 자료​

• Automate work with routines — Claude Code Docs
• Introducing routines in Claude Code — Anthropic Blog
• Security — Claude Code Docs
• Claude Code routines promise mildly clever cron jobs — The Register
• Claude Code Routines: Automate Dev Workflows — DEV Community

이 글은 Obsidian CLI 시리즈의 세 번째 글이에요.

1. Obsidian CLI 입문: 터미널에서 노트를 다루는 새로운 방법
2. Obsidian CLI 비교: 공식 CLI vs URI vs 직접 파일 조작
3. Obsidian CLI 자동화: 스크립트와 워크플로우 실전 가이드 ← 현재 글

왜 자동화하는가​

노트를 꾸준히 쓰기는 어렵습니다. 데일리 노트를 열고, 양식을 채우고, 태스크를 옮기는 작업은 반복적이고 귀찮습니다. 귀찮으면 안 하게 되고, 안 하면 쌓이고, 쌓이면 포기합니다.

자동화의 핵심은 반복적인 부분을 제거해서 본질(기록)에만 집중하게 만드는 것입니다.

Obsidian CLI 덕분에 이 반복 작업을 셸 스크립트로 만들 수 있습니다.

셸 별칭과 함수​

~/.zshrc에 추가해두면 매일 쓰게 되는 것들:

기본 별칭​

# 데일리 노트 단축키
alias dn="obsidian daily"
alias dna="obsidian daily:append"

# 빠른 검색
alias qs="obsidian search"

# 태그 현황
alias tags="obsidian tags counts"

memo() 빠른 메모​

타임스탬프와 함께 데일리 노트에 한 줄 메모를 추가합니다.

memo() {
  local timestamp=$(date +%H:%M)
  obsidian daily:append content="- **${timestamp}** $*"
}

# 사용
memo "내일 블로그 배포 일정 확인할 것"
memo "obsidian CLI 포스트 초안 완성"

# 데일리 노트에 이렇게 추가된다:
# - **14:23** 내일 블로그 배포 일정 확인할 것
# - **15:10** obsidian CLI 포스트 초안 완성

til() TIL 노트 자동 생성​

오늘 배운 것(Today I Learned)을 빠르게 기록합니다.

til() {
  local today=$(date +%Y-%m-%d)
  local slug=$(echo "$1" | tr ' ' '-' | tr '[:upper:]' '[:lower:]')
  obsidian create name="TIL/${today}-${slug}" content="---
tags: [til]
date: ${today}
---
# $1

$2"
}

# 사용
til "Obsidian CLI" "터미널에서 데일리 노트를 관리할 수 있다"

cron으로 정기 작업​

반복 스케줄이 정해진 작업은 cron에 맡깁니다.

매일 아침 데일리 노트 자동 생성​

# crontab -e
0 9 * * * obsidian daily

매일 오전 9시에 데일리 노트가 자동 생성됩니다. Obsidian을 열면 이미 오늘 노트가 준비되어 있습니다.

주간 리뷰 노트​

# 매주 금요일 오후 5시에 주간 리뷰 노트 생성
0 17 * * 5 obsidian create name="Review/$(date +\%Y-W\%V)" template="Templates/weekly-review"

전일 태스크 알림​

# 매일 오전 9시 30분에 어제 미완료 태스크 확인
30 9 * * * obsidian tasks daily --offset=-1

주의: cron에서 Obsidian CLI가 동작하려면, Obsidian 데스크톱 앱이 이미 실행 중이어야 합니다. macOS라면 로그인 시 Obsidian이 자동 실행되도록 설정해두면 됩니다.

macOS sleep 함정: 노트북이 sleep 상태일 때는 cron 자체가 발사되지 않습니다. 데스크톱이라면 무관하지만 노트북에서 매일 9시 데일리 노트가 안 만들어지면 이 때문입니다. caffeinate -s로 일시 차단하거나, 아예 launchd (launchctl)의 StartCalendarInterval로 옮기면 sleep 후 깨어났을 때 한 번 따라잡습니다.

vault 경로: Obsidian CLI는 OBSIDIAN_VAULT 환경변수 또는 ~/.obsidian-cli/config.json의 vault 항목으로 vault 위치를 찾습니다. cron 환경은 셸 환경변수를 자동 상속받지 않으므로, crontab 상단에 OBSIDIAN_VAULT=/Users/<you>/Documents/MyVault 한 줄을 명시해야 안전합니다.

tmux 연동​

tmux를 쓰고 있다면, Obsidian CLI와의 조합이 강력합니다.

작업용 레이아웃​

tmux 패널 하나를 Obsidian 전용으로 쓰면, 코드를 쓰면서 노트를 바로 확인할 수 있습니다.

┌──────────────────┬──────────────────┐
│ Neovim           │ obsidian read    │
│                  │                  │
├──────────────────┼──────────────────┤
│ Shell            │ obsidian search  │
│                  │                  │
└──────────────────┴──────────────────┘

좌상: 코드 편집, 우상: 노트 확인, 좌하: 빌드/테스트, 우하: 검색

자동화 스크립트​

프로젝트 시작 시 tmux 워크스페이스를 한 번에 구성하는 스크립트입니다.

#!/bin/bash
# obsidian-workspace.sh

SESSION="obsidian-work"

tmux new-session -d -s $SESSION

# 왼쪽: 에디터
tmux send-keys -t $SESSION "nvim" C-m

# 오른쪽: Obsidian 노트
tmux split-window -h -t $SESSION
tmux send-keys -t $SESSION "obsidian read path='Projects/current.md'" C-m

# 하단: 터미널
tmux split-window -v -t $SESSION:0.0
tmux send-keys -t $SESSION "obsidian daily" C-m

tmux attach -t $SESSION

tmux에서 빠른 메모​

tmux의 아무 패널에서 memo 함수를 실행하면 작업 흐름을 끊지 않고 메모를 남길 수 있습니다. 에디터를 떠나지 않아도 됩니다.

Git 연동​

커밋 로그를 데일리 노트에 자동 기록​

git의 post-commit hook을 활용합니다.

#!/bin/bash
# .git/hooks/post-commit

COMMIT_MSG=$(git log -1 --pretty=format:"%s")
REPO_NAME=$(basename $(git rev-parse --show-toplevel))

obsidian daily:append content="- **commit** \`${REPO_NAME}\`: ${COMMIT_MSG}"

hook에 실행 권한을 부여합니다.

chmod +x .git/hooks/post-commit

이제 커밋할 때마다 데일리 노트에 자동으로 기록됩니다.

- **commit** `blog-repo`: Obsidian CLI 시리즈 포스트 추가
- **commit** `blog-repo`: 오타 수정

하루가 끝나면 데일리 노트에 오늘의 작업 이력이 쌓여 있습니다.

프로젝트 노트 자동 생성​

새 프로젝트를 시작할 때 git repo와 Obsidian 노트를 동시에 만드는 함수입니다.

new-project() {
  local name=$1
  mkdir -p ~/Projects/$name && cd ~/Projects/$name
  git init
  obsidian create name="Projects/$name" template="Templates/project"
  echo "프로젝트 '$name' 생성 완료 — git repo + Obsidian 노트"
}

실전 워크플로우 예제​

아침 루틴 스크립트​

매일 아침 실행하는 스크립트 하나로 하루를 시작합니다.

#!/bin/bash
# morning.sh — 아침 루틴

echo "☀️ 아침 루틴 시작"

# 1. 오늘 데일리 노트 생성
obsidian daily
echo "✓ 데일리 노트 생성"

# 2. 어제 미완료 태스크 확인
echo ""
echo "📋 어제 미완료 태스크:"
obsidian tasks daily --offset=-1

# 3. 태그 현황
echo ""
echo "🏷️ 태그 현황:"
obsidian tags counts

# 실행
chmod +x morning.sh
./morning.sh

프로젝트 대시보드 생성​

볼트의 현재 상태를 요약하는 대시보드 노트를 자동 생성합니다.

#!/bin/bash
# dashboard.sh — 프로젝트 대시보드 갱신

VAULT=~/Documents/MyVault
TODAY=$(date +%Y-%m-%d)

# 통계 수집
TOTAL_NOTES=$(find $VAULT -name "*.md" | wc -l | tr -d ' ')
TODO_COUNT=$(grep -rc "\- \[ \]" $VAULT --include="*.md" | awk -F: '{sum+=$2} END{print sum}')
DONE_COUNT=$(grep -rc "\- \[x\]" $VAULT --include="*.md" | awk -F: '{sum+=$2} END{print sum}')

# 최근 수정된 노트 (상위 5개)
RECENT=$(find $VAULT -name "*.md" -mtime -1 -exec basename {} .md \; | head -5 | sed 's/^/- /')

# 대시보드 노트 갱신
obsidian create name="Dashboard" content="---
tags: [dashboard]
---
# 프로젝트 대시보드
> 마지막 갱신: ${TODAY}

## 통계
| 항목 | 수 |
|------|-----|
| 전체 노트 | ${TOTAL_NOTES} |
| 미완료 태스크 | ${TODO_COUNT} |
| 완료 태스크 | ${DONE_COUNT} |

## 최근 수정된 노트
${RECENT}
"

cron으로 매일 실행하면 항상 최신 상태의 대시보드를 유지할 수 있습니다.

마치며​

Obsidian CLI의 진짜 가치는 명령어 자체보다 자동화 가능성에 있습니다.

셸 별칭으로 매일 쓰는 명령을 줄이고, cron으로 반복 작업을 없애고, tmux와 결합해 워크플로우에 녹여넣고, git hook으로 기록을 자동화합니다. 이 모든 것이 CLI가 있기 때문에 가능해졌습니다.

터미널에서 Neovim으로 코드를 쓰고, tmux로 세션을 관리하고, Obsidian CLI로 노트까지 다뤄요. GUI로 전환할 이유가 하나 줄었어요.

참고 자료​

• Obsidian CLI 공식 도움말
• crontab Linux man page
• Git Hooks 공식 문서
• Obsidian 시리즈 1편: CLI 입문
• Obsidian 시리즈 2편: CLI vs URI vs 직접 파일 조작 비교

이 글은 Obsidian CLI 시리즈의 두 번째 글입니다.

1. Obsidian CLI 입문: 터미널에서 노트를 다루는 새로운 방법
2. Obsidian CLI 비교: 공식 CLI vs URI vs 직접 파일 조작 ← 현재 글
3. Obsidian CLI 자동화: 스크립트와 워크플로우 실전 가이드

세 가지 접근법​

Obsidian을 터미널에서 제어하는 방법은 크게 세 가지입니다.

1. 공식 CLI: Obsidian v1.12부터 내장된 커맨드라인 도구
2. URI scheme: obsidian:// 프로토콜로 앱에 명령을 전달
3. 직접 파일 조작: 볼트가 마크다운 디렉토리라는 점을 이용

각각 동작 방식이 다르고, 잘하는 것과 못하는 것이 다릅니다.

공식 CLI​

1편에서 자세히 다뤘습니다. 핵심만 정리하면 다음과 같습니다.

동작 방식​

obsidian 명령어 → 로컬 소켓 → Obsidian 프로세스 → 볼트 조작

Obsidian 내부 API를 직접 호출합니다. 파일을 이동하면 위키링크가 자동 업데이트되고, 속성 변경은 인덱스에 즉시 반영됩니다.

강점은 기능이 온전하다는 데 있습니다. 데일리 노트, 태스크, 검색, 태그, 템플릿 등 Obsidian 기능을 그대로 쓸 수 있고, 변경이 캐시와 그래프에 즉시 반영되며, 파일을 옮기거나 이름을 바꿔도 위키링크가 자동으로 따라 업데이트됩니다. Templater나 Dataview 같은 플러그인과도 호환됩니다.

대신 앱에 묶입니다. Obsidian 데스크톱 앱이 켜져 있어야 하고, 그래서 SSH로 접속한 원격 서버에서는 쓸 수 없습니다. 기능 자체가 v1.12 이상에서만 제공되므로 이전 버전 사용자는 업데이트가 필요합니다.

대표 명령어​

obsidian daily:append content="메모 내용"
obsidian search query="키워드"
obsidian create name="노트명" template="템플릿"
obsidian tags counts

Obsidian URI Scheme​

obsidian://로 시작하는 URL을 통해 Obsidian에 명령을 전달하는 방법입니다.

동작 방식​

open "obsidian://..." → OS URL 핸들러 → Obsidian 앱 → 동작 실행

macOS에서는 open 명령어, Linux에서는 xdg-open을 사용합니다.

기본 URI​

# 특정 노트 열기
open "obsidian://open?vault=MyVault&file=Projects/blog"

# 새 노트 생성
open "obsidian://new?vault=MyVault&name=Meeting/standup&content=회의%20메모"

# 검색
open "obsidian://search?vault=MyVault&query=TODO"

URL이므로 특수문자는 퍼센트 인코딩이 필요합니다. 한글도 마찬가지:

# 한글 포함 시
open "obsidian://open?vault=MyVault&file=$(python3 -c 'import urllib.parse; print(urllib.parse.quote("프로젝트/일정"))')"

Advanced URI 플러그인​

obsidian-advanced-uri 플러그인을 설치하면 URI의 기능이 크게 확장됩니다.

# 데일리 노트에 클립보드 내용 추가
open "obsidian://adv-uri?vault=MyVault&daily=true&clipboard=true&mode=append"

# 특정 헤딩 아래에 내용 추가
open "obsidian://adv-uri?vault=MyVault&filepath=Projects/blog.md&heading=TODO&data=새%20항목&mode=append"

# Obsidian 커맨드 실행
open "obsidian://adv-uri?vault=MyVault&commandid=editor:toggle-bold"

URI 방식의 매력은 진입 장벽이 낮다는 데 있습니다. CLI를 따로 활성화하지 않아도 앱만 설치돼 있으면 동작하고, 브라우저나 Alfred, Raycast, Shortcuts 같은 외부 앱에서 호출할 수 있으며, macOS, Windows, Linux를 모두 지원합니다.

한계도 뚜렷합니다. 기본 URI로는 열기, 생성, 검색 정도만 가능하고, 한글이나 특수문자가 들어가면 URL 인코딩이 번거로워집니다. 무엇보다 명령을 보내기만 할 뿐 결과를 터미널로 받아올 수 없고, 고급 기능은 Advanced URI 플러그인에 의존합니다.

직접 파일 조작 (Vault as Code)​

Obsidian 볼트의 본질은 마크다운 파일이 들어 있는 디렉토리입니다. 따라서 표준 유닉스 도구로 직접 조작할 수 있습니다.

사용 예시​

# 볼트 구조 확인
ls ~/Documents/MyVault/

# 키워드 검색
grep -r "TODO" ~/Documents/MyVault/ --include="*.md"

# 특정 태그가 달린 파일 찾기
grep -rl "#project" ~/Documents/MyVault/ --include="*.md"

# 노트 생성
cat << 'EOF' > ~/Documents/MyVault/TIL/obsidian-cli.md
---
tags: [til, obsidian]
---
# Obsidian CLI
오늘 배운 것
EOF

# 일괄 태그 변경
find ~/Documents/MyVault -name "*.md" -exec sed -i '' 's/#old-tag/#new-tag/g' {} +

fzf와 조합​

# fzf로 노트 선택해서 Neovim으로 열기
find ~/Documents/MyVault -name "*.md" | fzf --preview 'head -20 {}' | xargs nvim

이 방식의 장점은 앱에서 완전히 자유롭다는 것입니다. Obsidian이 설치돼 있지 않아도, SSH로 접속한 원격 서버에서도 동작합니다. grep, sed, awk, find 같은 유닉스 도구를 전부 끌어다 쓸 수 있어 유연성이 가장 크고, 수백 개 파일을 일괄 수정하는 대량 처리도 간편합니다.

문제는 Obsidian을 거치지 않는다는 데서 그대로 나옵니다. 변경 사항은 앱을 다시 열거나 리로드해야 인덱스에 반영되고, 파일을 옮기거나 이름을 바꾸면 위키링크가 자동으로 따라오지 않습니다. Templater나 Dataview 같은 플러그인 기능도 적용되지 않으며, 프론트매터 YAML 포맷은 직접 맞춰야 합니다.

종합 비교​

이럴 때는 이것을​

• 터미널에서 빠르게 노트를 쓰고 싶다 → 공식 CLI
• 브라우저나 Alfred에서 Obsidian을 열고 싶다 → URI scheme
• 수백 개 파일의 태그를 일괄 수정하고 싶다 → 직접 파일 조작
• 서버에서 마크다운 파일을 관리하고 싶다 → 직접 파일 조작
• 데일리 노트를 자동으로 만들고 싶다 → 공식 CLI
• Shortcuts/Raycast에서 Obsidian 연동 → URI scheme

조합해서 쓰기​

실제로는 하나만 쓰기보다 상황에 따라 조합하는 편이 낫습니다.

예시 워크플로우는 다음과 같습니다.

# 1. 공식 CLI로 데일리 노트 작성 (인덱스 반영 + 템플릿 적용)
obsidian daily:append content="## 작업 로그"

# 2. grep으로 볼트 전체에서 미완료 태스크 카운트 (대량 검색에 강함)
grep -rc "\- \[ \]" ~/Documents/MyVault/ --include="*.md" | sort -t: -k2 -rn | head -5

# 3. URI로 특정 노트를 Obsidian GUI에서 열기 (그래프 뷰 등 GUI 기능 활용)
open "obsidian://open?vault=MyVault&file=Projects/dashboard"

각 방법의 강점을 살려서 쓰면 됩니다. CLI로 안 되는 대량 처리는 직접 파일 조작으로, 터미널에서 안 되는 GUI 기능은 URI로 보완합니다.

마치며​

세 방법은 맞고 틀리고의 문제가 아니라 각각 잘하는 것이 다르고, 상황에 따라 최적의 도구가 달라집니다.

일상적인 노트 작성에는 공식 CLI가 가장 편하고, 대량 처리에는 직접 파일 조작이, 외부 앱 연동에는 URI scheme이 낫습니다.

다음 글에서는 이 도구들을 활용한 실전 자동화 워크플로우를 정리해요. 셸 별칭, cron, tmux 연동, git hook까지 다룰게요.

참고 자료​

• Obsidian CLI (공식 도움말)
• Obsidian URI scheme (공식 도움말)
• Obsidian 시리즈 1편: CLI 입문
• Obsidian 시리즈 3편: 자동화 워크플로우