Claude Code 9단계 루프: 주니어가 아니라 시니어 엔지니어처럼 쓰는 법

Claude Code를 쓸 때 화면을 계속 들여다보고 계신가요? "이 파일 고쳐줘" → 편집 지켜보기 → 눈으로 확인 → 다시 "이번엔 저거 고쳐줘". 대부분의 개발자가 이렇게 씁니다. 이게 바로 주니어를 감독하듯 Claude Code를 쓰는 방식이에요.

그런데 같은 도구를 자율적으로 일하는 시니어 엔지니어처럼 굴리는 사람들이 있습니다. 차이는 도구가 아니라 운용 방식에 있어요. 2026-06-15에 0xMorty(@0xMortyx)가 X 롱폼 아티클에서 이걸 "9단계 루프"로 정리했는데, 솔직히 말하면 이건 0xMorty가 발명한 비법이 아닙니다. Anthropic 공식 문서에 흩어져 있던 검증된 워크플로우 4종을 한 사이클로 압축한 재구성이에요. 그래서 더 믿을 만하고요.

이 글에서는 그 9단계를 Anthropic 공식 문서 기준으로 하나씩 짚어보고, 한국 1인 기업이나 개발자가 당장 적용할 수 있는 포인트까지 정리해 드릴게요.

핵심부터: 검증을 사람의 눈이 아니라 시스템에 맡긴다

결론부터 말씀드리면, 주니어처럼 쓰기와 시니어처럼 쓰기의 본질 차이는 딱 하나입니다. 검증(verification)의 주체가 사람의 눈이냐, 시스템이냐.

주니어처럼 쓸 때는 사람이 매번 결과를 눈으로 확인합니다. 시니어처럼 쓸 때는 훅(hooks)·테스트·서브에이전트 같은 시스템이 대신 검증해요. 그래서 사람이 자리를 비워도 품질이 유지됩니다.

이건 제 의견이 아니라 Anthropic의 공식 입장입니다. Anthropic은 이렇게 명시해요.

"단 하나의 실천만 채택한다면 그것은 검증(verification) — Claude에게 자기 출력을 스스로 확인할 수단을 주는 것을 채택하라."

가장 영향력 큰 단일 팁으로 검증을 꼽은 거죠. 그리고 공식 에이전트 피드백 루프도 "맥락 수집 → 행동 → 작업 검증 → 반복(gather context → take action → verify work → repeat)"으로 정의되어 있는데, 이게 9단계 루프의 골격과 정확히 맞아떨어집니다.

즉, 9단계 루프는 "Claude가 스스로 자기 일을 검증하게 만드는 장치"를 단계별로 박아 넣은 흐름이라고 보시면 됩니다.

1~2단계: EXPLORE와 PLAN — 코딩 전에 읽고 계획부터

1단계 EXPLORE — 코드베이스 먼저 읽기

편집하기 전에 코드베이스를 먼저 읽습니다. Anthropic 공식 워크플로우 "Explore, plan, code, commit"의 첫 단계와 같아요.

Plan Mode에 들어가면 Claude는 파일을 읽고 질문에 답하되 변경을 가하지 않습니다. 곧장 코딩으로 점프하면 "엉뚱한 문제를 푸는 코드"가 나오기 쉽거든요. 그래서 탐색과 실행을 분리하는 걸 권장합니다.

실전에서는 Plan Mode로 진입한 뒤 "이 기능 관련 파일들을 먼저 읽고 구조를 설명해줘"로 시작하세요. 편집 권한 없이 맥락만 수집하게 하는 거예요.

2단계 PLAN — 아직 편집하지 말고 계획만

탐색이 끝나면 상세 구현 계획을 만들게 합니다. 아직 편집은 안 해요. 공식 docs 기준으로는 Ctrl+G로 플랜을 에디터에서 직접 편집한 뒤 진행할 수 있습니다.

여기서 한 가지 팁이 있어요. 계획을 PLAN.md 같은 파일로 남기게 하면, 나중에 REVIEW 단계에서 "PLAN.md 대비 구현 누락 점검"의 기준점이 됩니다. 계획을 머릿속이 아니라 파일에 박아두면 자동 검증의 닻이 되는 거죠.

3단계 STANDARDS — CLAUDE.md로 규칙을 못 박기

이 단계가 루프를 "주니어 감독"에서 "시니어 위임"으로 바꾸는 첫 번째 레버입니다.

CLAUDE.md는 프로젝트·개인·조직 단위의 영속 지시를 담는 마크다운 파일인데, 매 세션 시작 시 자동으로 로드됩니다. 큰 프로젝트는 .claude/rules/ 디렉터리로 규칙을 분할할 수도 있고요.

언제 CLAUDE.md에 적어야 할까요? Anthropic은 이렇게 권장합니다. "Claude가 같은 실수를 두 번 하거나, 코드리뷰가 Claude가 알았어야 할 것을 잡거나, 같은 정정을 또 타이핑하게 될 때." 한마디로 같은 설명을 두 번 하게 되는 순간 규칙으로 박으세요.

참고로 Claude Code에는 메모리 시스템이 두 개 있습니다. 사람이 직접 쓰는 CLAUDE.md와, Claude가 스스로 적는 Auto memory예요. 둘 다 매 세션 로드되고, Auto memory는 v2.1.59 이상에서 동작합니다.

1인 기업이라면 빌드 명령, 코드 스타일, 금지 패턴을 CLAUDE.md에 못 박아 "매번 재설명"을 제거하세요. 이게 자동화의 출발점입니다.

4단계 BUILD — 계획에 맞춰 변경 작성

이제 Plan Mode를 해제하고 합의된 계획에 따라 코딩합니다. 공식 워크플로우의 "Code" 단계예요.

Claude Code의 핵심 역량에는 코드 검색·읽기, 파일 편집, 테스트 작성·실행, 커밋·푸시, CLI 사용이 모두 포함됩니다. 그러니 2단계에서 합의한 PLAN.md를 근거로 변경하게 하고, "계획에 없던 범위는 건드리지 마"라는 제약을 함께 주세요. 범위가 새는 걸 막아줍니다.

5단계 HOOKS — 훅으로 검증을 자동 강제

여기서부터가 진짜 핵심입니다. 5단계부터 8단계가 바로 "검증을 시스템에 위임"하는 장치거든요.

Hooks는 Claude Code 라이프사이클의 특정 시점에 실행되는 사용자 정의 셸 명령입니다. 중요한 건 이거예요. "LLM이 실행하기로 선택하길 기대하는 대신, 특정 행동이 항상 일어나도록" 결정론적으로 제어합니다.

PreToolUse: 도구 호출 전에 발화하며, 호출을 **차단(deny)**할 수 있습니다.
PostToolUse: 도구 성공 후에 발화합니다. 단, 이미 실행된 작업은 되돌릴 수 없어요.

훅의 강제 지점이 모델 출력 파싱이 아니라 프레임워크/플랫폼 레벨에 있다는 게 핵심입니다. 그래서 프롬프트 인젝션으로 모델을 속여도 정책 검사 자체를 우회하지는 못해요. 지시(CLAUDE.md)는 뚫릴 수 있지만 훅은 결정론적으로 막습니다.

실전에서는 저장 시 자동 포맷(PostToolUse), 위험 명령 차단(PreToolUse deny), 그리고 종료 시 테스트·린트를 강제하는 Stop 훅을 거십니다. Anthropic도 "감사 가능한 워크플로에는 Stop 훅 기반 결정론 검사가 선호된다"고 명시하고 있어요.

6~8단계: TEST·REVIEW·FIX — 사람의 눈을 대체하는 검증 삼각형

6단계 TEST — 테스트로 작동을 증명

Anthropic은 TDD 워크플로우를 권장합니다. 테스트가 실패하면 Claude Code가 에러를 읽고, 코드를 고치고, 전체 스위트를 다시 돌려 모두 통과할 때까지 반복해요.

실제 사례도 있습니다. Anthropic 사내 Security Engineering 팀은 원래 "설계문서 → 엉성한 코드 → 리팩토링 → 테스트 포기" 흐름이었는데, 이걸 "Claude에게 의사코드 요청 → TDD로 유도 → 주기적 점검"으로 바꿔 더 신뢰성 있고 테스트 가능한 코드를 얻었다고 공식 보고했어요.

실전에서는 "먼저 실패하는 테스트를 쓰고, 통과시킬 때까지 구현하라"로 지시하세요. 테스트가 자동 검증 신호가 되어 사람의 눈 검사를 대체합니다.

7단계 REVIEW — 독립 리뷰로 자기검열 편향 제거

원본 다이어그램에는 이 단계가 "rubygem crits"라고 적혀 있었는데, 솔직히 의미가 불명확합니다. 추측을 사실로 단정하지 않고, **"독립 리뷰 / 서브에이전트 또는 루브릭(rubric) 기반 비평"**으로 일반화해서 보는 게 정확해요.

공식 패턴은 읽기 전용 code-reviewer 서브에이전트입니다. Edit/Write 권한이 없어서 코드를 수정 없이 검토만 해요. 검증 워크플로에서는 "서브에이전트로 diff를 PLAN.md와 대조 — 모든 요구사항이 구현됐는지, 엣지케이스 테스트가 있는지, 범위 밖 변경은 없는지" 점검하는 걸 권장합니다.

서브에이전트로 돌리면 좋은 점이 하나 더 있어요. 구현 세션이 갭을 직접 받아서, 사람이 창 사이로 결과를 복사하지 않고도 바로 고치고 재리뷰할 수 있습니다.

핵심은 maker(구현)와 checker(리뷰)를 분리하는 거예요. 자기가 짠 코드를 자기가 리뷰하면 편향이 생기니까요. "code-reviewer 서브에이전트로 이 diff를 PLAN.md 기준으로 검토해"라고 호출하세요.

8단계 FIX — 수정 후 재확인

7단계 리뷰에서 받은 갭, 6단계 테스트에서 나온 실패를 입력으로 받아 고치고 다시 확인합니다. 테스트 실패 시 Claude가 에러를 읽고 고친 뒤 다시 돌리고, CI(GitHub/GitLab) 파이프라인을 모니터링하며 수정을 자동 커밋해요.

서브에이전트 리뷰에서 받은 갭을 "고치고 재리뷰"하는 흐름이 7단계와 8단계의 공식 대응입니다. 통과할 때까지 6 → 7 → 8 사이클을 반복하는 거죠.

9단계 SHIP — 커밋/PR로 출하, 그리고 headless 무인 운용

마지막은 출하입니다. 공식 워크플로우의 "Commit" 단계예요. Claude는 약어 "pr"을 이해하고, diff와 맥락으로 적절한 커밋 메시지를 생성합니다. 진행 상황을 git에 서술형 커밋 메시지로 남기고 progress 파일에 요약을 쓰는 게 베스트프랙티스고요.

여기서 자동화의 끝판왕이 나옵니다. **headless 모드(claude -p)**예요. CI 파이프라인, 프리커밋 훅, 자동화 워크플로 통합용인데, UI로 사람에게 물어볼 수 없으니 안전 한도에 도달하면 프로세스를 종료하도록 설계되어 있습니다.

실전에서는 "커밋하고 PR 만들어"로 출하하고, 야간·반복 작업은 headless 모드 + Stop 훅 결정론 검사로 무인 운용하세요. 단, 배포나 PR 머지처럼 비가역적인 외부 작업은 안전 한도와 승인 게이트를 꼭 유지하시고요.

한국 1인 기업이 당장 적용할 순서

9단계를 다 외울 필요는 없어요. 1인 운영이라면 검증 자동화가 "사람이 매번 지켜보는 시간"을 제거하는 가장 큰 레버이니, 이 순서로 적용하시면 됩니다.

STANDARDS 먼저 — CLAUDE.md에 빌드 명령·금지 패턴·코드 스타일을 못 박아 매번 재설명을 제거하세요. 같은 정정을 두 번 타이핑하면 즉시 CLAUDE.md에 추가합니다.
HOOKS로 검증 자동화 — PreToolUse(위험 명령 차단), PostToolUse(자동 포맷), Stop 훅(종료 시 테스트·린트 결정론 강제). 지켜보는 시간을 시스템이 대신합니다.
REVIEW는 maker ≠ checker — 읽기 전용 code-reviewer 서브에이전트로 구현과 리뷰를 분리하고, PLAN.md 대비 갭을 점검하세요.
SHIP은 headless 후보 — 반복·야간 작업은 claude -p + Stop 훅 검사로 무인화하되, 외부 비가역 작업은 승인 게이트를 남깁니다.

CLAUDE.md → Hooks → Subagent review → headless ship. 이 네 가지만 갖춰도 Claude Code는 더 이상 옆에서 감독해야 하는 주니어가 아니라, 알아서 검증하고 출하하는 시니어 엔지니어가 됩니다.

마무리

9단계 루프의 핵심은 화려한 신기술이 아닙니다. 검증을 사람의 눈에서 시스템으로 옮기는 것 하나예요. EXPLORE와 PLAN으로 방향을 잡고, STANDARDS로 규칙을 박고, BUILD로 만들고, HOOKS·TEST·REVIEW·FIX로 검증을 자동화한 뒤, SHIP으로 출하하는 흐름이죠.

이게 0xMorty가 발명한 비법이 아니라 Anthropic 공식 워크플로우 4종(Explore-Plan-Code-Commit + CLAUDE.md + Hooks + Subagent)의 압축 재구성이라는 점이 오히려 안심입니다. 검증된 베스트프랙티스를 한 흐름으로 묶은 것이니까요.

오늘 당장 CLAUDE.md 한 줄, Stop 훅 하나부터 시작해 보세요. AI 코딩 에이전트를 시니어처럼 쓰는 첫걸음입니다.

자주 묻는 질문 (FAQ)

Q. 9단계 루프는 0xMorty가 만든 새로운 방법론인가요?

아닙니다. 9단계 루프는 0xMorty(@0xMortyx)가 2026-06-15에 정리한 것이지만, 내용은 Anthropic 공식 문서에 이미 있던 워크플로우 4종(Explore-Plan-Code-Commit, CLAUDE.md 메모리, Hooks 결정론적 강제, Subagent 검증)을 한 사이클로 압축 재구성한 것입니다. 신규 발명이라기보다 공식 베스트프랙티스의 실전 압축판으로 보시는 게 정확해요.

Q. 검증을 시스템에 맡긴다는 게 구체적으로 무엇인가요?

사람이 매번 눈으로 결과를 확인하는 대신, 훅(hooks)·테스트·서브에이전트가 대신 검증하게 만드는 겁니다. 예를 들어 Stop 훅으로 종료 시 테스트와 린트를 결정론적으로 강제하고, 읽기 전용 code-reviewer 서브에이전트로 diff를 PLAN.md와 대조하는 식이죠. Anthropic은 "단 하나의 실천만 채택한다면 검증을 채택하라"고 공식적으로 명시했습니다.

Q. CLAUDE.md와 Hooks의 차이는 무엇인가요?

CLAUDE.md는 사람이 쓰는 지시(규칙)로 매 세션 로드되지만, 모델이 따르길 "기대"하는 것이라 프롬프트 인젝션 등으로 뚫릴 수 있습니다. 반면 Hooks는 프레임워크/플랫폼 레벨에서 동작하는 결정론적 제어라, 모델을 속여도 정책 검사 자체를 우회하지 못합니다. PreToolUse는 도구 호출을 차단할 수 있고, PostToolUse는 도구 성공 후 발화합니다. 그래서 "반드시 일어나야 하는 강제"는 훅으로 거는 게 안전합니다.

Q. 1인 기업이라면 어디부터 시작해야 하나요?

STANDARDS(CLAUDE.md) → HOOKS → REVIEW(서브에이전트) → SHIP(headless) 순서를 추천합니다. 먼저 CLAUDE.md에 빌드 명령과 금지 패턴을 박아 재설명을 없애고, Stop 훅으로 테스트·린트를 자동 강제한 뒤, 읽기 전용 서브에이전트로 리뷰를 분리하세요. 반복·야간 작업은 headless 모드(claude -p)로 무인화하되, 배포·PR 머지 같은 비가역 작업은 승인 게이트를 유지하면 됩니다.

Claude Code 9단계 루프: 주니어가 아니라 시니어 엔지니어처럼 쓰는 법