studio.soluta
← Claude 시작하기

운영하기

반복 작업을 맡기고, 도구를 나누고, 회고로 다듬습니다.

실습 Hooks

Hooks — 자동 검수

파일을 고칠 때마다 포맷터를 돌렸는지, 테스트를 통과했는지 매번 손으로 확인하고 있지 않나요?

정해 둔 검수가 저절로 울립니다
정해 둔 검수가 저절로 울립니다

Skill로 절차를 정리해 두어도, 그 절차 끝에 항상 붙는 검사(포맷·테스트·오탈자)는 여전히 사람이 기억해서 실행해야 합니다. 파일을 여러 개 고치는 세션에서는 마지막에 검사를 깜빡하기 쉽고, 깜빡한 검사는 결과물에 그대로 남습니다.

Hooks는 PreToolUse(도구 실행 전)·PostToolUse(도구 실행 후)·SessionStart(세션 시작) 같은 정해진 시점에 지정한 명령을 자동으로 실행하는 장치입니다. .claude/settings.json에 등록해 두면 그 시점이 올 때마다 사람이 매번 확인 요청을 하지 않아도 등록해 둔 명령이 실행됩니다. 등록한 목록은 /hooks 명령으로 볼 수 있지만 이 명령은 읽기 전용 브라우징이고, 수정은 설정 파일을 직접 고치거나 Claude에게 요청해서 합니다.

개발 직군만 쓰는 기능은 아닙니다. 문서를 작성하는 직군이라면 파일을 저장할 때마다 포맷·오탈자 검사 스크립트가 자동 실행되게 걸어 둘 수 있고, 기획서를 다루는 직군이라면 필수 항목이 빠졌는지 확인하는 검사를 같은 방식으로 걸 수 있습니다. Hook을 검수가 아니라 실행 자체에 쓰는 방식은 안티패턴입니다. 커밋 직후 배포까지 자동으로 이어지는 Hook을 걸어 두면, 검수를 통과하지 못한 변경도 그대로 나갑니다. Hook은 확인 절차를 자동화하는 데 쓰고, 실행 여부의 최종 판단은 사람에게 남겨 둡니다.

아래 연습을 그대로 붙여넣어, 파일을 고칠 때마다 맞춤법 검사가 자동으로 돌게 hook을 걸어 보세요.

  1. 자동화할 검사를 하나 고릅니다 — 포맷터·문서 검사처럼 되돌리기 쉬운 것부터 시작합니다.
  2. .claude/settings.json에 Hook을 등록합니다.
  3. 실행 시점(이벤트)을 지정합니다 — 도구 실행 전(PreToolUse), 도구 실행 후(PostToolUse), 세션 시작 시(SessionStart) 등입니다.
  4. 파일을 하나 고쳐 등록한 검사가 자동으로 실행되는지 확인합니다.
  5. /hooks 명령으로 등록된 Hook 목록을 확인합니다 — 읽기 전용 브라우징이며, 수정은 설정 파일에서 합니다.
연습

hook을 건 뒤 파일을 실제로 하나 고쳐, 검사가 자동으로 실행되는지 확인해 보세요.

파일을 고친 직후 검사가 사람 개입 없이 자동으로 실행되면 통과입니다.

막히는 지점

Hook 스크립트에 실행 권한이 없거나 명령이 실패로 끝나면 command not found 또는 에러로 다음 작업 흐름이 막힙니다. 이때는 스크립트에 실행 권한을 주고 절대경로로 지정하며, 실패해도 안전한 가벼운 검수만 Hook에 올립니다. 배포·삭제처럼 되돌리기 어려운 작업을 Hook에 걸면 검토 없이 실행되어 되돌릴 수 없는 상태가 되고, Stop 이벤트를 반복 차단하는 Hook은 무한루프에 빠질 위험이 있어 Claude Code가 8회 연속 차단 시 강제로 진행시킵니다. 되돌리기 어려운 작업은 Hook에 걸지 않고, Stop Hook은 반복 여부를 스스로 확인해 멈추도록 만듭니다.

2026-07-13 기준 · 출처 · Claude Code — Hooks, Claude Code — Hooks Guide

실습 멀티도구

멀티도구 라우팅

설계·검토처럼 판단이 필요한 일과 초안 반복처럼 손이 많이 가는 실행까지 전부 혼자 처리하느라, 정작 중요한 판단에 쓸 시간이 부족하지 않나요?

일의 성격에 따라 도구를 나눕니다
일의 성격에 따라 도구를 나눕니다

설계 검토나 톤 결정처럼 판단이 필요한 일과, 초안을 여러 개 뽑거나 반복 수정하는 실행이 뒤섞이면 하루 대부분이 반복 작업으로 채워집니다. 실행에 시간을 쓰는 동안 정작 판단이 필요한 결정은 뒤로 밀립니다.

Claude Code는 터미널·IDE 확장·데스크톱 앱·웹처럼 여러 표면에서 쓸 수 있지만, 안에서 돌아가는 엔진은 하나입니다. 표면을 바꿔도 CLAUDE.md·설정·MCP 연결은 새로 맞추지 않고 그대로 이어집니다.

판단이 무거운 작업과 반복이 많은 실행 작업은 성격이 다릅니다. 아키텍처를 정하거나 애매한 요구를 좁히는 판단은 무거운 모델이 맡고, 정해진 절차를 반복하는 실행은 가벼운 실행자에게 넘기는 편이 비용과 속도 모두에서 유리합니다.

나누는 방법 하나는 서브에이전트입니다. 정의 파일에 model 필드를 sonnet·opus·haiku처럼 지정해 두면 그 서브에이전트가 맡은 반복 작업은 지정한 모델이 처리하고, 판단 담당은 결과만 검수합니다.

기획자라면 초안을 여러 안으로 늘려 보는 반복은 가벼운 모델에 맡기고 최종안을 고르는 판단은 직접 합니다. 마케터라면 카피 변형을 다량으로 뽑는 실행은 위임하고, 브랜드 톤에 맞는지 고르는 판단만 남깁니다.

위임 문장에 기준을 담지 않고 통째로 넘기는 방식이 안티패턴입니다. “알아서 해줘” 식 요청은 실행 담당이 임의로 채운 부분이 나중에 재작업으로 돌아옵니다. 위임할 때는 원하는 형식·범위·완료 조건을 문장에 넣습니다.

아래 연습을 그대로 붙여넣어, 지금 하는 작업을 판단과 실행으로 나눠 보세요.

  1. 지금 하는 작업을 판단(설계·검수)과 실행(반복·생성)으로 나눕니다.
  2. 실행 몫을 맡길 서브에이전트를 정하고, 정의 파일의 model 필드를 sonnet·opus·haiku 중 필요한 것으로 지정합니다.
  3. 위임 문장에 원하는 형식과 완료 조건을 명시해 요청합니다.
  4. 실행 담당이 낸 결과를 판단 담당이 검수합니다.
  5. 표면(터미널·IDE·데스크톱 등)을 바꿔 작업해도 CLAUDE.md·설정·MCP 연결은 다시 맞추지 않고 그대로 씁니다.
연습

위임한 결과를 받으면, 판단 담당인 본인이 원하는 기준에 맞는지 검수해 보세요.

판단이 필요한 부분과 반복 실행 부분을 구분해 다른 실행 주체에 나눠 맡길 수 있으면 통과입니다.

막히는 지점

위임 문장에 기준과 완료 조건을 담지 않으면, 실행 담당이 임의로 판단해 다시 고쳐야 하는 결과가 나옵니다. 이때는 원하는 형식과 범위를 문장에 명시해 재작업을 줄입니다. 짧은 일까지 전부 위임하면 왕복 비용이 직접 하는 것보다 커지고 검수할 사람도 사라지니, 판단이 필요한 만큼만 남기고 나머지만 넘깁니다.

2026-07-13 기준 · 출처 · Claude Code — Overview

실습 Runbook

운영 runbook · 회고

세션을 시작할 때마다 뭐부터 확인하고, 뭘 다시 설명해야 할지 매번 새로 떠올리고 있지 않나요?

절차대로 돌리고 회고로 다듬습니다
절차대로 돌리고 회고로 다듬습니다

세션마다 시작 절차가 다르면 지난번에 걸렸던 예외를 다시 만나고, 지난번에 정해 둔 승인 기준을 다시 설명해야 합니다. 기억에 의존한 시작은 사람이 바뀌거나 시간이 지나면 어긋나기 시작합니다.

runbook은 세션을 어떻게 시작하고, 무엇을 확인하고, 어떻게 끝낼지 적어 둔 절차 문서입니다. 설치부터 여기까지 익힌 흐름(요청·구조·Git·규칙 파일·Hooks·도구 분배)을 그대로 옮기면 됩니다.

runbook은 한 번 쓰고 끝나지 않습니다. 세션을 마칠 때마다 무엇이 막혔는지, 무엇을 자동화할 수 있었는지 짧게 남기고, 그 기록을 모아 정기적으로 runbook을 고칩니다. 회고는 길 필요가 없습니다 — 이번에 반복한 규칙 하나, 이번에 발견한 예외 하나를 적는 정도로도 다음 세션의 시작점이 달라집니다.

기획자라면 리서치 세션마다 반복하는 순서(출처 확인 → 초안 → 톤 검수)를 runbook에 적어 두고 다음 세션에서 그 순서부터 시작합니다. 마케터라면 캠페인 카피를 만들 때마다 확인하는 항목(금칙어·브랜드 톤)을 runbook에 남겨 둡니다.

runbook에 적어 둔 절차 중 매번 같은 순서로 반복하는 것은 예약 실행으로 옮길 수 있습니다. Routines는 컴퓨터가 꺼져 있어도 Anthropic 관리 인프라에서 실행되고, Desktop scheduled tasks는 로컬 파일이 필요한 작업에, GitHub Actions는 저장소 이벤트에 연동해 씁니다.

안티패턴은 runbook을 백과사전처럼 키우는 것입니다. 모든 예외를 다 적어 두면 아무도 처음부터 끝까지 읽지 않아 결국 지켜지지 않습니다. 자주 쓰는 절차만 남기고, 한 번뿐인 예외는 회고에만 적어 둡니다.

아래 연습을 그대로 붙여넣어, 오늘 세션에서 한 일을 바탕으로 다음 세션용 runbook 초안을 만들어 보세요.

  1. 세션 시작 체크리스트를 적습니다 — 무엇부터 확인하고 무엇을 로드할지.
  2. 진행 중 규칙(승인·검수 기준)을 기록합니다.
  3. 세션을 마칠 때 회고 한 줄을 남깁니다 — 막힌 지점 또는 자동화할 수 있었던 지점.
  4. 반복되는 절차가 보이면 예약 실행(Routines·Desktop scheduled tasks·GitHub Actions 등)으로 옮길지 검토합니다.
  5. 회고 기록을 모아 주기적으로 runbook을 갱신합니다.
연습

runbook 초안이 나오면, 다음 세션에 실제로 그 순서로 시작할 수 있는지 훑어보세요.

runbook을 보고 다음 세션을 시작할 수 있고, 한 가지 개선점을 회고에 적었으면 통과입니다.

막히는 지점

회고 없이 절차만 쌓이면 runbook이 실제 작업 방식과 어긋난 채로 낡습니다. 이때는 세션을 마칠 때마다 막힌 지점 한 줄을 남기고, 그 기록으로 정기적으로 갱신합니다. runbook이 한 페이지를 넘어가면 끝까지 읽히지 않아 지켜지지 않으니, 분량이 늘면 자주 쓰는 절차만 남기고 나머지는 정리합니다.

2026-07-13 기준 · 출처 · Claude Code — Common Workflows

다음 단계