사람 없이 도는 Claude Code: 자율 실행을 만드는 네 가지 축
코딩 에이전트를 써 본 분이라면 익숙한 장면이 있습니다. 프롬프트를 넣고, 응답을 읽고, 다음 지시를 넣고, 다시 기다리는 왕복입니다. 이 왕복은 강력하지만 사람을 계속 붙들어 둡니다. 최근 Anthropic이 공개한 자료들은 이 왕복을 끊어 내는 방향, 즉 Claude Code가 사람이 지켜보지 않아도 스스로 돌아가게 만드는 방법을 정리하고 있습니다. 이 글은 그 방법을 헤드리스 모드·훅·서브에이전트·스킬이라는 네 가지 축으로 나눠 설명하고, 각 축이 실제로 어떻게 작동하는지 ThakiCloud가 운용 중인 파이프라인으로 검증합니다.
헤드리스·훅·서브에이전트·스킬 네 축이 겹쳐 사람 없이 도는 자율 하네스를 형상화했습니다.
개요
Anthropic은 Claude Code를 대화형 CLI를 넘어 자동화 런타임으로 확장해 왔습니다. 관련 발표(“Enabling Claude Code to work more autonomously”)와 자동 모드 설계 글(“How we built Claude Code auto mode”), 그리고 조종 방법을 종합한 블로그(“Steering Claude Code”)가 그 흐름을 보여 줍니다. 핵심 메시지는 하나입니다. Claude Code를 자율적으로 굴리는 것은 더 똑똑한 모델을 기다리는 문제가 아니라, 주변 하네스를 어떻게 설계하느냐의 문제라는 것입니다.
이 관점은 ThakiCloud의 운영 원칙과 정확히 겹칩니다. 능력은 모델 자체가 아니라 그 모델을 감싸는 계약 구조, 즉 시스템 프롬프트·도구 정의·검증 게이트·라우팅 규칙에서 나온다는 것입니다. 아래 네 가지 축은 바로 그 하네스를 구성하는 부품들입니다.
무엇이 문제인가: 사람이 매번 붙어 있어야 하는 에이전트
단발 응답 에이전트의 한계는 명확합니다. 작업이 조금만 길어지면 사람이 매 스텝의 판단과 승인을 대신해야 하고, 반복 작업조차 매번 손으로 트리거해야 합니다. 여기서 필요한 것은 세 가지입니다. 첫째, 사람 없이 한 번에 실행을 시작하고 끝내는 방법. 둘째, 특정 시점에 반드시 어떤 동작이 일어나도록 강제하는 방법. 셋째, 복잡한 작업을 전문화된 일꾼에게 나눠 맡기고, 그 일꾼이 필요한 지식만 골라 쓰게 하는 방법입니다. 네 가지 축은 각각 이 요구를 하나씩 충족합니다.
cron · 이벤트 · 파이프라인] --> H[헤드리스 모드
claude -p, TTY 없음] H --> HK[훅
생명주기 결정론 제어] HK --> SA[서브에이전트
격리된 전문가 위임] SA --> SK[스킬
필요 시 로드하는 전문성] SK --> O[검증된 산출물] HK -.세션 시작 컨텍스트 주입.-> H HK -.종료 시 후처리.-> O SA -.모델 라우팅 haiku·sonnet·opus.-> SA
네 가지 축은 서로 겹쳐 하나의 자율 하네스를 이룹니다. 헤드리스가 실행을 열고, 훅이 생명주기를 강제하며, 서브에이전트가 작업을 나누고, 스킬이 그때그때 전문성을 공급합니다.
1. 헤드리스 모드: 사람 없이 한 번에 실행
헤드리스 모드는 Claude Code를 TTY 없이 한 번의 CLI 프로세스로 실행하는 방식입니다. claude -p "<프롬프트>" 형태로 호출하면 대화 없이 작업을 수행하고 종료합니다. 이 단순한 성질이 예약 작업, CI 파이프라인, 커밋 전 검사 같은 무인 통합을 가능하게 만듭니다. 중요한 점은 헤드리스 모드가 대화형 CLI와 동일한 설정·훅·권한 규칙을 그대로 재사용한다는 것입니다. 즉 대화형에서 검증한 하네스를 그대로 무인 환경으로 옮길 수 있습니다.
ThakiCloud는 이 방식을 이미 광범위하게 운용합니다. scripts/launchd/에는 35개의 launchd plist가 있고, 각 plist는 정해진 시각에 claude -p로 스킬 러너를 호출합니다. 지금 이 블로그 글을 만드는 파이프라인 자체가 헤드리스로 도는 러너의 한 예입니다. 트위터 타임라인에서 블로그 후보를 뽑아 큐에 넣고, 후보마다 초안을 쓰고 검증 게이트를 통과시켜 배포까지 이어지는 전 과정이 사람의 매 스텝 개입 없이 진행됩니다.
ThakiCloud에서 무인 자동화로 도는 launchd 스크립트는 35개입니다. 대화형 TTY 없이 claude -p 단일 프로세스로 실행하며, 종량 API 키 대신 구독 OAuth 토큰을 로드해 시크릿 노출을 막습니다.
무인 실행에서 반드시 챙겨야 할 것은 인증입니다. 종량 API 키를 디스크에 커밋하는 대신, 구독 OAuth 토큰을 별도 파일에 두고 러너가 이를 로드하는 방식이 안전합니다. Anthropic 문서 역시 무인 환경에서는 API 키를 시크릿 매니저에서 꺼내 오는 헬퍼를 쓰라고 권합니다. 자동화의 편리함이 곧 시크릿 노출로 새지 않도록, 인증 경로를 처음부터 무인 전제에 맞춰 설계하는 것이 핵심입니다.
2. 훅: 결정론적 생명주기 제어
훅은 Claude Code 생명주기의 특정 지점에서 코드를 실행하는 장치입니다. 파일 편집 후 자동 포매팅, 커밋 전 린트, 세션 시작 시 컨텍스트 주입, 종료 시 후처리처럼, 모델의 선택에 맡기지 않고 반드시 일어나야 하는 동작을 강제합니다. 훅의 가치는 결정론에 있습니다. 모델이 그때그때 기분에 따라 실행할지 말지를 정하는 것이 아니라, 규칙으로 못 박힌 동작이 항상 발생합니다.
ThakiCloud의 .claude/hooks/에는 12개의 훅이 배선돼 있습니다. 세션 시작 훅은 직전까지의 학습을 상주 브리프로 주입해 매 세션이 백지에서 시작하지 않게 합니다. 프롬프트 제출 훅은 요청을 분석해 관련 스킬 후보를 자동으로 띄웁니다. 종료 훅은 플래그 파일을 감지해 필요한 후처리, 예컨대 큐에 쌓인 블로그 후보 드레인이나 지식 베이스 재컴파일을 실행합니다. 특히 이 종료 훅은 플래그가 없으면 즉시 종료해 비용이 0에 수렴하고, 플래그가 있을 때만 무거운 작업을 도는 패턴을 씁니다. 매 턴이 아니라 생산자 턴 직후에만 비싼 작업을 트리거하는 이 구조가 자율 파이프라인의 비용을 통제하는 핵심입니다.
현재 배선된 생명주기 제어 훅은 12개입니다. 시작 훅은 컨텍스트를 주입해 백지 상태를 막고, 제출 훅은 스킬 후보를 띄우며, 종료 훅은 플래그가 있을 때만 무거운 작업을 돌려 불필요한 비용을 0에 수렴시킵니다.
3. 서브에이전트: 격리된 전문가 위임
서브에이전트는 특정 작업을 위한 격리된 보조 에이전트입니다. .claude/agents/의 마크다운 파일로 정의하며, 이름·설명과 함께 사용할 모델과 도구 접근 범위를 지정합니다. 메인 에이전트가 프런트엔드를 만드는 동안 서브에이전트가 백엔드 API를 병렬로 세우는 식의 분업이 가능합니다. 격리가 중요한 이유는 두 가지입니다. 서브에이전트는 자신의 작업에만 집중하므로 메인 컨텍스트를 오염시키지 않고, 결과만 요약해 되돌립니다.
ThakiCloud는 63개의 전문 서브에이전트를 정의해 두고 작업 성격에 맞춰 호출합니다. 여기에 모델 라우팅 규칙이 결합됩니다. 탐색·검색·파일 읽기처럼 가벼운 작업은 haiku로, 구현·리뷰·테스트 작성은 sonnet으로, 아키텍처 결정이나 복잡한 다단계 추론은 opus로 보냅니다. 이 라우팅이 없으면 모든 서브에이전트가 세션 기본 모델로 돌아 비용이 폭증합니다. 자율 하네스에서 서브에이전트는 단순한 병렬화 수단이 아니라, 작업마다 적절한 비용-품질 지점을 고르는 비용 통제 장치이기도 합니다.
정의된 전문 서브에이전트는 63개입니다. 메인 에이전트가 프런트엔드·백엔드·API로 팬아웃하되, 결과를 사용자에게 합치기 전 반드시 검증 게이트로 닫습니다. 검증 없는 병렬화는 환각을 누적합니다.
한 가지 규율을 덧붙이면, 팬아웃한 서브에이전트의 결과를 합치기 전에는 반드시 검증 스테이지로 닫아야 합니다. 병렬 에이전트를 여러 개 띄웠으면, 그 결과를 그대로 사용자에게 합치는 대신 적대적 검증을 한 번 거치는 것입니다. 검증 게이트 없는 팬아웃은 환각을 누적합니다.
4. 스킬: 필요할 때만 불러오는 전문성
스킬은 반복 가능한 전문 워크플로를 패키지로 묶은 것입니다. 도메인 지식·템플릿·검증 스크립트·실패 사례를 함께 담아, 요청이 트리거할 때만 로드합니다. 항상 로드하지 않는다는 점이 핵심입니다. 매 세션 컨텍스트에 상주시키면 토큰 비용을 계속 지불하지만, 온디맨드로 불러오면 필요한 순간에만 전문성을 공급합니다.
ThakiCloud의 .claude/skills/에는 1,751개의 스킬이 있습니다. 이 규모에서는 어떤 스킬을 언제 부를지가 곧 품질을 좌우합니다. 그래서 자연어 요청을 BM25 계열 어휘 검색으로 후보 스킬에 매핑하고, 상위 후보만 컨텍스트에 띄우는 라우터를 둡니다. 스킬이 1,700개를 넘어가면 사람이 일일이 고를 수 없으므로, 검색으로 후보를 좁히는 이 단계가 없으면 스킬 시스템 자체가 노이즈가 됩니다. 스킬은 프롬프트가 아니라 버전 관리되는 능력 상품이며, 여러 하네스를 가로질러 재사용된다는 점에서 단순 프롬프트와 구별됩니다.
ThakiCloud에 등록된 반복 가능한 전문 워크플로 패키지는 1,751개입니다. 이 규모를 매 세션에 상주시키면 토큰이 낭비되므로, BM25 검색으로 후보를 좁혀 필요할 때만 온디맨드로 불러옵니다.
ThakiCloud 제품 적용 시사점
이 주제는 에이전트 오케스트레이션 그 자체이므로 Paxis 렌즈가 정면으로 맞습니다. Paxis는 ThakiCloud의 Agent-Native Cloud 제어 평면으로, Skills·Tools·Policies·Audit Logs를 일급 리소스로 다룹니다. 위 네 가지 축은 Paxis가 제품 차원에서 제공하려는 능력과 일대일로 대응합니다. 헤드리스 실행은 NL Cron으로 예약된 무인 실행에, 훅은 정책 게이트와 감사 로그에, 서브에이전트는 DAG 멀티에이전트 오케스트레이션에, 스킬은 960개 이상 스킬을 BM25로 선택하는 Skill Harness에 각각 대응합니다.
Anthropic이 개별 기능으로 소개한 네 축은 Paxis에서 NL Cron, 정책 게이트와 감사 로그, DAG 오케스트레이션, 960개 이상 스킬을 BM25로 선택하는 Skill Harness로 각각 제품화됩니다.
핵심은 Anthropic이 개별 기능으로 소개한 네 축을 Paxis가 하나의 제어 평면으로 통합해 제품화한다는 점입니다. 개별 개발자가 손으로 배선하던 헤드리스 러너·훅·라우팅·스킬 선택을, 격리 샌드박스 실행과 정책 게이트·감사 로그로 감싸 거버넌스 가능한 형태로 올리는 것입니다. 온프레미스와 소버린 환경을 요구하는 국내 고객에게는 이 거버넌스 계층이 특히 중요합니다. 자율 에이전트가 무엇을 실행하고 어떤 시크릿에 접근했는지 전부 감사 로그로 남아야, 규제 환경에서 자율성을 실제로 켤 수 있기 때문입니다.
인프라 측면에서 ai-platform 렌즈도 함께 맞습니다. 헤드리스 러너와 서브에이전트 팬아웃은 결국 K8s 위에서 도는 워크로드이고, 모델 라우팅에 따른 haiku·sonnet·opus 호출은 서빙 비용으로 환산됩니다. 저비용 서빙 기반(ai-platform)이 있어야 자율 에이전트를 상시로 굴리는 경제성(Paxis)이 성립합니다.
한계 및 반론
자율성을 높일수록 통제와 검증의 부담이 커진다는 점을 직시해야 합니다. 첫째, 헤드리스 무인 실행은 실패가 조용히 누적될 위험이 있습니다. 사람이 지켜보지 않으므로, 인증 만료나 한도 초과 같은 문제가 여러 러너에 걸쳐 동시에 터질 수 있습니다. 실패를 즉시 감지해 알림을 보내는 후처리가 없으면, 자율성은 곧 조용한 고장으로 이어집니다.
둘째, 훅과 라우팅을 잘못 설계하면 매 턴 비용이 선형으로 늘어납니다. 상시 로드되는 규칙이 비대해지거나, 폴링성 작업을 에이전트 핫루프에 넣으면 자율화가 오히려 비용 폭증으로 돌아옵니다. 반복 모니터링은 에이전트가 아니라 cron으로 빼는 것이 원칙입니다.
셋째, 자동화가 사고를 대체하는 것이 아니라 보조하는 도구라는 점을 잊으면 안 됩니다. 루프가 깊어질수록 사람이 결과를 신뢰하고 검토를 멈추는 경향이 생깁니다. 핵심 산출물은 주기적으로 사람이 표본 검토해야 하고, 검증 게이트는 통과 편향이 아니라 반증 지향으로 설계해야 합니다. 아무것도 걸러 내지 못하는 검증기는 고장 신호로 봐야 합니다.
결론적으로 Claude Code의 자율 실행은 더 강한 모델이 아니라 잘 설계된 하네스에서 나옵니다. 헤드리스·훅·서브에이전트·스킬이라는 네 축은 각각 실행·강제·분업·전문성 공급을 담당하며, 이들을 검증 게이트와 감사 로그로 감쌀 때 비로소 규제 환경에서도 켤 수 있는 자율성이 됩니다.