Claude Code 완전 정복 4편 — 극한 활용법: 검증, 계획, 맥락 관리, 병렬 작업, 자동화

잘 될 때와 안 될 때의 차이

Claude Code를 쓰다 보면 어떤 날은 한 번에 기능 하나가 끝나고, 어떤 날은 같은 버그를 다섯 번 고쳐 달라고 해도 제자리입니다. 대부분 모델 성능보다 일을 맡기는 방식에서 차이가 납니다.

이 글은 Claude Code 시리즈 마지막 편으로, 공식 문서의 모범 사례를 바탕으로 Claude Code를 끝까지 활용하는 방법을 정리합니다. 작업 흐름, 맥락 관리, 병렬 작업, 자동화 순서로 다룹니다.

1. 확인할 수단을 먼저 준다

공식 문서가 가장 먼저 강조하는 원칙입니다. Claude는 작업이 "끝나 보이면" 멈춥니다. 테스트나 빌드처럼 성공·실패를 알려 주는 수단이 없으면, 그 판단은 결국 내가 해야 합니다.

이렇게 말하기보다	이렇게 말하기
이메일 검증 함수 만들어줘	validateEmail 함수를 만들어줘. user@example.com은 true, invalid는 false, user@.com은 false. 구현 후 테스트를 돌려줘
대시보드 좀 더 예쁘게 해줘	(시안 이미지 붙여 넣고) 이 디자인대로 구현하고, 결과를 스크린샷으로 찍어서 원본과 비교한 뒤 차이를 고쳐줘
빌드가 실패해	빌드가 이 에러로 실패해: [에러]. 고치고 빌드가 성공하는지 확인해줘. 에러를 숨기지 말고 원인을 고쳐줘

검증 수단이 있으면 Claude는 작업 → 확인 → 결과 읽기 → 수정을 스스로 반복합니다. 그리고 "고쳤습니다"라는 말 대신 테스트 출력이나 실행 결과 같은 증거를 보여 달라고 하면 확인이 훨씬 빨라집니다.

더 강하게 묶는 방법도 있습니다.

• /goal <조건>: 조건이 충족될 때까지 Claude가 여러 턴에 걸쳐 계속 작업합니다. 예: /goal 모든 테스트가 통과한다
• Stop 훅: 응답이 끝나는 시점에 검사 스크립트를 실행해서, 통과하지 못하면 끝내지 못하게 막습니다.

2. 탐색 → 계획 → 구현 → 커밋

바로 코드를 쓰게 하면 엉뚱한 문제를 풀 수 있습니다. 공식 문서가 권하는 흐름은 네 단계입니다.

1) 탐색 — Shift+Tab으로 plan 모드로 바꾸거나 claude --permission-mode plan으로 시작합니다. 이 모드에서는 Claude가 파일을 읽고 답만 하고, 고치지 않습니다.

1src/auth를 읽고 세션과 로그인을 어떻게 처리하는지 파악해줘.
2비밀값 환경 변수를 어떻게 관리하는지도 봐줘.

2) 계획 — 구현 계획을 세우게 합니다. Ctrl+G를 누르면 계획을 텍스트 에디터에서 직접 고칠 수 있습니다.

1Google OAuth를 추가하고 싶어. 어떤 파일을 바꿔야 하고,
2세션 흐름은 어떻게 돼? 계획을 세워줘.

3) 구현 — 계획을 승인하면 plan 모드가 풀립니다. 계획에 맞춰 구현하고 테스트까지 돌리게 합니다.

4) 커밋 — 설명이 담긴 메시지로 커밋하고 PR을 만들게 합니다.

다만 계획에도 비용이 듭니다. 오타 수정이나 변수 이름 변경처럼 diff를 한 문장으로 설명할 수 있는 작업이면 계획 없이 바로 시키는 것이 낫습니다. 계획은 접근 방법이 확실하지 않거나, 여러 파일을 바꾸거나, 처음 보는 코드를 다룰 때 효과가 큽니다.

3. 맥락(context)을 적극적으로 관리한다

Claude가 한 번에 기억할 수 있는 대화량(컨텍스트 윈도우)은 한정되어 있습니다. 관계없는 내용이 쌓이면 성능이 떨어지고 엉뚱한 데 신경을 씁니다. 공식 문서는 맥락을 가장 중요한 제약으로 봅니다.

상황	쓸 명령
관계없는 새 작업을 시작할 때	/clear — 대화를 비우고 새로 시작
같은 작업을 이어 가는데 대화가 길어졌을 때	/compact 이번 API 변경에 집중해서 요약해줘
지금 맥락이 얼마나 찼는지 볼 때	/context
잠깐 궁금한 걸 물어볼 때	/btw 질문 — 답이 대화 기록에 남지 않음
많이 읽어야 하는 조사	"서브에이전트로 조사해줘" — 별도 맥락에서 조사하고 요약만 받음

맥락이 한계에 가까워지면 Claude Code가 **자동으로 요약(compact)**하기 때문에 세션이 끊기지는 않습니다. 그래도 자동 요약에 맡기기보다 작업 단위로 /clear를 쓰는 편이 결과가 안정적입니다.

4. 실패 패턴을 알아 둔다

공식 문서가 꼽는 대표적인 실패 패턴입니다.

• 잡동사니 세션: 작업 A를 하다가 관계없는 B를 묻고, 다시 A로 돌아옵니다. 맥락이 쓸모없는 정보로 가득 찹니다. → 작업 사이에 /clear.
• 고치고 또 고치기: 틀린 걸 지적했는데 또 틀립니다. 실패한 시도가 맥락에 쌓여 방해가 됩니다. → 두 번 고쳐도 안 되면 /clear하고, 그동안 알게 된 내용을 담아 처음 요청을 다시 씁니다.
• 너무 긴 CLAUDE.md: 중요한 규칙이 묻혀서 절반은 무시됩니다. → 과감하게 줄이고, 강제가 필요한 건 훅으로.
• 믿고 넘어가기: 그럴듯해 보이지만 예외 상황을 처리하지 않은 코드. → 테스트, 스크립트, 스크린샷 같은 확인 수단을 항상 줍니다.
• 끝없는 탐색: 범위 없이 "조사해줘"라고 하면 수백 개 파일을 읽습니다. → 범위를 좁히거나 서브에이전트에 맡깁니다.

5. 되감기로 과감하게 시도한다

Claude Code는 메시지를 보낼 때마다 체크포인트를 만들고, 파일을 고치기 전 상태를 저장합니다. 입력창이 비어 있을 때 Esc를 두 번 누르거나 /rewind를 실행하면 이전 시점으로 돌아갈 수 있습니다. 대화만, 코드만, 또는 둘 다 되돌릴 수 있습니다.

덕분에 "이 방법이 될지 모르겠지만 일단 해 보자"가 가능해집니다. 안 되면 되감고 다른 방법을 시도하면 됩니다.

단, 주의할 점이 있습니다. 체크포인트는 Claude의 파일 편집 도구로 바꾼 내용만 추적합니다. Claude가 셸 명령(rm, mv 등)으로 바꾼 파일이나 외부에서 바뀐 파일은 되돌리지 못합니다. git을 대신하는 기능이 아니므로, 큰 작업 전에는 커밋해 두는 습관이 여전히 필요합니다.

6. 세션을 브랜치처럼 쓴다

대화는 내 Mac에 저장되기 때문에 나중에 이어 할 수 있습니다.

1claude --continue   # 이 폴더의 가장 최근 대화 이어 하기
2claude --resume     # 목록에서 골라 이어 하기

세션 안에서 /rename으로 oauth-작업, 결제-버그처럼 이름을 붙여 두면 작업 흐름마다 맥락을 따로 유지할 수 있습니다.

7. 병렬로 돌린다: worktree

Claude가 기능 A를 만드는 동안 나는 다른 세션에서 버그 B를 맡기고 싶을 수 있습니다. 같은 폴더에서 두 세션이 동시에 파일을 고치면 충돌합니다. 이때 git worktree를 씁니다.

1claude --worktree feature-auth

.claude/worktrees/feature-auth/에 별도 작업 폴더가 생기고, worktree-feature-auth 브랜치에서 Claude가 시작합니다. 세션마다 폴더와 브랜치가 분리되므로 서로 간섭하지 않습니다. 줄여서 -w도 됩니다.

여러 파일에 같은 종류의 변경을 해야 한다면 /batch가 있습니다. Claude가 작업을 5~30개의 독립된 단위로 나누고, 계획을 승인하면 단위마다 별도 worktree에서 병렬로 처리합니다.

8. 사람 없이 돌린다: 비대화형 모드

-p 옵션을 쓰면 Claude Code를 스크립트처럼 실행할 수 있습니다. 질문 하나를 처리하고 결과를 출력한 뒤 종료합니다.

1claude -p "이 프로젝트의 lint 에러를 모두 고쳐줘" \
2  --allowedTools "Read,Edit,Bash(yarn lint *)"

• --allowedTools: 승인 없이 쓸 도구를 미리 정합니다.
• --output-format json: 결과를 JSON으로 받습니다. 다른 스크립트로 넘기기 좋고, 비용 정보도 함께 들어 있습니다.
• --bare: 훅, 스킬, MCP, CLAUDE.md 같은 자동 로딩을 건너뛰어 빠르게 시작합니다. 공식 문서는 스크립트와 CI에서 이 옵션을 권장합니다.

파일 여러 개를 하나씩 처리하는 반복문도 만들 수 있습니다.

1for file in $(cat files.txt); do
2  claude -p "$file 을 새 API 형식으로 마이그레이션하고 OK 또는 FAIL만 출력해" \
3    --allowedTools "Read,Edit" \
4    --permission-mode dontAsk
5done

--permission-mode dontAsk는 미리 허용하지 않은 작업을 묻지 않고 거부합니다. 사람이 없는 상황에서 승인 창 때문에 멈추지 않게 해 줍니다. 처음에는 파일 2~3개로 시험해 보고, 프롬프트를 다듬은 뒤 전체에 돌리는 것이 안전합니다.

9. GitHub와 연결한다

Claude Code 안에서 아래 명령을 실행하면 GitHub 연동을 설정할 수 있습니다.

1/install-github-app

GitHub App 설치, 인증 시크릿 등록, 워크플로 파일이 담긴 PR 생성까지 안내해 줍니다. 그 PR을 머지하면 이슈나 PR 댓글에 @claude를 멘션해서 Claude에게 분석이나 수정을 맡길 수 있습니다. github.com 저장소에서만 동작하고, GitLab은 별도의 CI/CD 연동을 씁니다.

10. 반복 작업을 맡긴다: /loop

세션이 열려 있는 동안 같은 작업을 주기적으로 반복시킬 수 있습니다.

1/loop 5m 배포가 끝났는지 확인하고 결과를 알려줘

간격을 생략하면 Claude가 상황을 보고 간격을 정합니다. 내 Mac이 꺼져 있어도 돌아가야 하는 작업이라면 클라우드에서 실행되는 Routines나 데스크톱 앱의 예약 작업을 쓰는 편이 맞습니다.

11. 끝내기 전에 다른 눈으로 검토한다

오래 혼자 작업한 결과일수록 독립적인 검토가 중요합니다. 작업한 Claude가 스스로 채점하면 자기 판단을 그대로 믿기 쉽기 때문입니다.

• /code-review: 현재 변경 사항을 새로운 서브에이전트가 버그 관점에서 검토합니다.
• 직접 요청할 수도 있습니다.

1서브에이전트로 이번 변경을 PLAN.md와 대조해서 검토해줘.
2요구사항이 모두 구현됐는지, 예외 케이스에 테스트가 있는지,
3작업 범위 밖의 코드가 바뀌지 않았는지만 확인하고 빠진 점만 알려줘.

공식 문서에는 이런 주의도 있습니다. 문제를 찾으라고 시킨 검토자는 멀쩡한 코드에서도 뭔가를 찾아냅니다. 지적을 전부 반영하다 보면 쓸데없는 추상화와 방어 코드가 늘어납니다. 그래서 "정확성이나 요구사항에 영향을 주는 문제만" 보고하라고 범위를 정해 주는 것이 좋습니다.

핵심 한 줄

Claude Code를 잘 쓰는 핵심은 확인할 수단을 주고, 맥락을 깨끗하게 유지하고, 결과는 증거로 검증하는 것입니다. 여기에 plan 모드, 되감기, worktree, -p 자동화를 더하면 Claude Code는 옆에서 지켜봐야 하는 도구에서 맡겨 두고 다른 일을 할 수 있는 도구가 됩니다.

참고 자료

• 모범 사례
• 자주 쓰는 워크플로
• 체크포인트
• worktree로 병렬 작업
• 비대화형 모드
• GitHub Actions
• 예약 작업과 /loop