CCAR-P 개념 카드

■ 코딩 맡기는 흐름

explore → plan → implement → commit · pass/fail check7.2 본편

표시가 없는 문장은 공식 문서에서 확인한 내용이에요. 다른 표시는 읽는 법

왜 배우나 — 시험이 요구하는 것

시험 목표 7.2 개발 흐름 개선 · D7 개발팀 7%
Improve developer workflows using AI-assisted tooling

이 개념으로 푸는 판단 (할 수 있어야 하는 것)

  • 7.2① Claude 에게 코딩을 맡기는 흐름은? — 탐색 → 계획 → 구현 → 검증 루프를 어떻게 짜나

한눈에

Claude 에게 코딩을 맡길 때는 두 가지를 한다.

  • ⓐ 스스로 돌릴 합격/불합격 검사를 준다
  • ⓑ 탐색·계획을 구현과 떼어 놓는다

검사가 있으면 루프가 사람 없이 닫힌다

근본 제약은 컨텍스트 창이다. 창이 찰수록 앞선 지시를 잊고 실수가 늘어난다. 그래서 교정·탐색이 쌓이면 새로 시작한다

비유 terraform plan 뒤 apply, 그리고 CI 테스트 게이트와 같다. "숙련자는 plan 없이 바로 apply" 가 속이는 습관이다

코딩을 맡길 땐 탐색·계획을 구현과 떼어 놓고, 테스트 같은 합격/불합격 검사를 주면 Claude 가 통과할 때까지 스스로 반복해 루프가 닫힌다.
그림으로 보기 (AI 생성 · Codex · 누르면 크게)

ELI5

숙제를 맡길 때 "다 했어?" 대신 정답지를 같이 주는 거예요.

  • 정답지가 있으면 혼자 맞춰 보고 고쳐요.
  • 정답지가 없으면 매번 어른이 봐 줘야 해요.
  • 큰 숙제는 먼저 계획을 세우고, 한 줄짜리는 바로 해요.
  • 같은 걸 두 번 넘게 틀리면 새 종이에 다시 시작해요.

개념 설명

영상 — 밤새 맡긴 일, 누가 끝을 판정할까? (약 43초 · 소리 없음 · 자막). 멈춘 자리와 ②③ 의 결과 값은 그림용 가정 · 실측 아님 작은 화면에서는 전체화면(⛶)으로 보세요.

원리

멈추는 신호

  • Claude 는 일이 "끝나 보이면" 멈춘다. 돌릴 검사가 없으면 그것이 유일한 신호다. 그러면 사람이 검증 루프가 되고, 모든 실수가 사람이 알아챌 때까지 기다린다.
  • 합격/불합격을 돌려주는 검사(테스트 · 빌드 종료 코드 · 린터 · fixture diff · 스크린샷 비교)를 주면 아래 고리가 사람 없이 돈다.
    • 일한다
    • 검사한다
    • 결과를 읽는다
    • 고친다
  • 검사를 거는 세기는 계단이다. 아래로 갈수록 세다.
    • 한 프롬프트
    • /goal : 별도 평가자가 매 턴 재확인한다
    • Stop 훅 : 통과할 때까지 턴 종료를 막는다
    • 검증 서브에이전트 : 일한 쪽이 채점하지 않게 한다
  • 계단을 오를수록 설정 비용이 는다. 대신 사람이 덜 지켜봐도 된다.

탐색과 실행 떼기

  • 곧장 코딩하면 엉뚱한 문제를 푼다. 그래서 plan mode 로 먼저 읽고 계획만 한다. 계획 단계에서는 변경하지 않는다.
  • 대신 오버헤드가 있다. 그래서 기준은 "diff 를 한 문장으로 말할 수 있나" 다. 말할 수 있으면 범위를 이미 안다는 뜻이다. 그러면 바로 구현한다.

컨텍스트가 근본 제약이다

  • 대화, 읽은 파일, 명령 출력이 전부 창에 쌓인다. 창이 찰수록 앞선 지시를 잊고 실수가 늘어난다.
  • 그래서 아래처럼 한다.
    • ⓐ 조사는 서브에이전트에게 맡긴다(요약만 돌아온다)
    • ⓑ 관련 없는 작업 사이에 /clear 한다
    • ⓒ 같은 문제 교정이 두 번을 넘으면 실패한 시도가 컨텍스트를 더럽힌 것이다. 이때는 새로 시작하는 것이 대개 이긴다

핵심 질문은 두 개다

  • Claude 가 "됐다" 를 스스로 확인할 수단이 있나?
  • 이 변경을 한 문장으로 말할 수 있나?

규칙과 판단

diff 를 한 문장으로 설명할 수 있으면 바로 구현하고 아니면 plan mode 를 쓴다. 무인 실행은 /goal 이나 Stop 훅으로 검사 통과까지 끝내지 못하게 한다.
그림으로 보기 (AI 생성 · Codex · 누르면 크게)

갈림길

③④ 계획할까 [7.2①]

diff 를 한 문장으로 설명할 수 있나?오타 · 로그 한 줄 · 변수 이름
예

바로 구현

범위가 분명한 작은 수정은 바로 구현한다. plan mode 는 오버헤드다

아니오 (접근법 불확실 · 여러 파일 · 낯선 코드)

plan mode

탐색, 계획, 구현, 커밋 순서로 간다. 계획 단계는 읽고 답만 하고 변경하지 않는다. plan mode 는 쓰기를 막는 것이다. 컨텍스트 보호는 서브에이전트가 한다

①② 검사를 얼마나 세게 [7.2①]

돌릴 검사가 있나?
없다

검사부터 준다

테스트 · 빌드 종료 코드 · 린터 · fixture diff 스크립트 · 스크린샷 비교를 쓴다

있다
누가 지켜보나?무인 실행을 사람 없이 제대로 끝내는 것은 /goal·Stop 훅이다
내가 지켜보는 작업

한 프롬프트에

검사를 돌려 보며 고치라고 같은 메시지에 요청한다

무인 실행

/goal · Stop 훅

통과할 때까지 턴 종료를 막는다

거기에 다른 검토자 의견까지 (오래 혼자 돈 작업)

검증 서브에이전트

결과를 따져 본다. 일한 에이전트가 채점하지 않게 한다

⑥ 막혔을 때 [7.2①]

같은 문제를 몇 번째 교정하나?
두 번 넘었다

새로 시작

/clear 하고 배운 것을 넣은 더 구체적 프롬프트로 시작한다

그 전

바로 교정

Esc 로 멈추고 방향을 튼다. 되돌리기는 /rewind 로 한다

흐름

그림 속 이름·금액·시간·토큰 수는 예시예요. 공식 한도·동작은 카드 본문 값이 기준.

장면 글로 보기

칸 : 사람 → Claude → 검사

규칙 (검사) : 테스트 · 빌드 종료 코드 · 린터

질문 : "다 됐다" 는 누가 판정할까?

① 검사를 주면 루프가 닫힌다 ✓

  1. 시작 : 사람 — 말 : “결제 모듈 리팩터링해 줘. npm test 통과까지.”
  2. 맡기기 : 사람 → Claude : 검사 기준까지 같이 준다 — 쪽지 : 할 일: 리팩터링 / 완료: npm test 통과
  3. 실행 : Claude → 검사 : 테스트를 돌린다 — 쪽지 : $ npm test / 2 failed · 48 passed
  4. 읽기 : 검사 → Claude : 실패를 읽고 고친다 — 쪽지 : FAIL refund.test.ts / → 고치고 다시
  5. 통과 : Claude → 검사 : 다시 돌린다 — 쪽지 : $ npm test / 50 passed · exit 0
  6. 끝 : 검사가 통과할 때까지 스스로 반복한다. 사람이 검증 루프가 되지 않는다

② 검사가 없으면 사람이 검증 루프 ≠

  1. 시작 : 사람 — 말 : “대시보드 좀 좋게 해 줘.”
  2. 맡기기 : 사람 → Claude : 완료 기준이 없다 — 쪽지 : 할 일: 대시보드 개선 / 완료: ?
  3. 건너뜀 : 검사
  4. 멈춤 : Claude : "끝나 보인다" 가 유일한 신호다 — 말 : “다 된 것 같아요.”
  5. 넘기기 : Claude → 사람 : 실수는 사람이 알아챌 때까지 남는다 — 쪽지 : PR #214 / 검사 결과: 없음
  6. 끝 : 사람이 검증 루프가 된다. 모든 실수가 사람이 알아챌 때까지 기다린다

③ 같은 문제 교정 반복 ≠

  1. 시작 : 사람 — 말 : “날짜 형식 또 틀렸어.”
  2. 교정 : 사람 → Claude : 같은 문제를 세 번째 교정한다 — 쪽지 : 교정 1: 날짜 형식 / 교정 2: 날짜 형식 / 교정 3: 날짜 형식
  3. 쌓임 : Claude : 컨텍스트가 실패한 시도로 어지럽다 — 쪽지 : 시도 A 실패 / 시도 B 실패 / 교정 ×3 …
  4. 끝 : 두 번 넘게 교정했으면 /clear 하고, 배운 것을 넣은 더 구체적 프롬프트로 다시 시작한다

나머지 규칙

  1. 맡기는 말 : 맡길 때는 아래처럼 말한다

    • 파일·시나리오·테스트 선호를 지정한다
    • 답이 있는 소스를 지목한다
    • 기존 패턴을 가리킨다
    • 증상과 위치와 "고쳐진 모습" 을 말한다

    큰 기능은 Claude 가 먼저 인터뷰한다(AskUserQuestion). 그 결과로 SPEC.md 를 쓰고, 새 세션에서 실행한다. 좋은 스펙에는 관련 파일·인터페이스 이름, 범위 밖, end-to-end 검증 단계가 들어간다

  2. 끝났다고 치기 전에 새 컨텍스트로 리뷰한다. 자세한 것은 ■ AI 코드 리뷰 에 있다. 반복 작업을 무인으로 올리는 곳은 ■ 자동화 surface 고르기 에 있다

규칙 원문 ①②③④⑥ (갈림길로 그린 규칙)

  1. 검사를 준다 : Claude 는 일이 끝나 보이면 멈춘다. 돌릴 검사가 없으면 "끝나 보인다" 가 유일한 신호다. 그러면 사람이 검증 루프가 되고 모든 실수가 사람을 기다린다 [7.2①]

    검사는 아래와 같다

    • 테스트
    • 빌드 종료 코드
    • 린터
    • fixture 와 출력을 diff 하는 스크립트
    • 스크린샷 비교

    성공을 주장하지 말고 증거(테스트 출력 · 실행한 명령과 결과 · 스크린샷)를 보이게 한다

  2. 검사를 얼마나 세게 거나 : 설정 비용과 사람이 지켜보는 수고를 맞바꾼다

    방식어떻게언제
    한 프롬프트검사를 돌려 보며 고치라고 같은 메시지에 요청한다어떤 작업에나 오늘 바로
    세션 전체/goal 조건을 둔다. 별도 평가자가 매 턴 재확인한다무인 실행
    결정적 게이트Stop 훅이 검사를 스크립트로 돌려 통과할 때까지 턴 종료를 막는다무인 실행
    다른 검토자 의견검증 서브에이전트·동적 workflow 가 결과를 반박한다. 일한 에이전트가 채점하지 않게 한다오래 혼자 돈 작업

    무인 실행을 사람 없이 제대로 끝내는 것은 /goal·Stop 훅이다 (2026-09-28 조회)

  3. 4단계 : 순서는 탐색, 계획, 구현, 커밋이다. plan mode 로 탐색과 실행을 떼어 놓는다. 곧장 코딩하면 엉뚱한 문제를 풀기 때문이다 [7.2①]

    plan mode 는 Shift+Tab(상태 표시줄 ⏸ plan mode on)이나 claude --permission-mode plan 으로 켠다. 파일을 읽고 답만 하고 변경하지 않는다. Ctrl+G 로 계획을 편집기에서 고친다 (2026-09-28 조회)

  4. 계획을 건너뛸 때 : 범위가 분명한 작은 수정(오타 · 로그 한 줄 · 변수 이름)은 바로 한다

    계획이 쓸 만한 때는 아래와 같다

    • 접근법이 불확실하다
    • 여러 파일을 건드린다
    • 코드가 낯설다

    diff 를 한 문장으로 설명할 수 있으면 계획을 건너뛴다

  5. 교정 : 빗나가면 바로 교정한다. Esc 로 멈추고 방향을 튼다(컨텍스트는 유지된다). 되돌리기는 /rewind 로 한다

    같은 문제를 한 세션에서 두 번 넘게 교정했으면 컨텍스트가 실패한 시도로 어지럽다. 그러면 /clear 하고 배운 것을 넣은 더 구체적 프롬프트로 시작한다. 관련 없는 작업 사이에도 /clear 한다

    조사는 서브에이전트에게 맡긴다. 서브에이전트는 별도 컨텍스트에서 읽고 요약만 돌려준다(메인 컨텍스트 보호)

더 깊이 : 판단 규칙 · 상황 변수 (설명)

판단 규칙

조건답근거
돌릴 검사 없이 맡겼다검사부터 준다(테스트·빌드·린터·스크린샷)best-practices "Give Claude something that produces a pass or fail, and the loop closes on its own."
무인으로 끝까지 돌아야 한다/goal 조건이나 Stop 훅을 쓴다best-practices "The /goal and Stop hook versions are what let an unattended run finish correctly without you."
일한 에이전트의 자기 판정이 못 미덥다검증 서브에이전트가 반박한다best-practices "so the agent doing the work isn’t the one grading it"
접근법이 불확실하다 · 여러 파일 · 낯선 코드plan mode 를 쓴다(탐색, 계획, 구현, 커밋)best-practices
diff 를 한 문장으로 말할 수 있다계획을 건너뛰고 바로 구현한다best-practices "If you could describe the diff in one sentence, skip the plan."
같은 문제를 두 번 넘게 교정했다/clear 하고 배운 것을 넣은 더 구체적 프롬프트로 시작한다best-practices
조사가 수백 파일로 번진다조사 범위를 좁히거나 서브에이전트에게 맡긴다best-practices
큰 기능이고 요구가 흐리다Claude 가 인터뷰하고 스펙을 쓴다. 새 세션에서 구현한다best-practices
성공 보고를 받았다주장 말고 증거(테스트 출력·명령 결과)를 본다best-practices "Have Claude show evidence rather than asserting success"

상황 변수

변수값답 쪽근거
지켜보는 사람옆에서 본다한 프롬프트 안 검사로 충분하다best-practices
지켜보는 사람없다(밤새 · CI)/goal · Stop 훅 · 검증 서브에이전트best-practices · Skilljar cci 486938
변경 크기오타 · 로그 한 줄 · 이름 바꾸기바로 구현한다best-practices
변경 크기여러 파일 · 아키텍처 선택plan modebest-practices
작업 성격탐색적이다(무엇이 나올지 보고 싶다)계획 없이 한다. 막연한 프롬프트도 된다best-practices
세션 기록한 문제를 깊게 파는 중이고, 기록이 값지다컨텍스트를 쌓아 둬도 된다best-practices
세션 기록실패한 시도가 쌓였다/clear 하고 새로 시작한다best-practices
UI 변경검사를 코드로 할 수 없다스크린샷 비교를 검사로 쓴다best-practices

연습 문제

결제 모듈 리팩터링을 밤새 사람 없이무인 Claude 에게 맡긴다. 저장소엔 npm test 로 도는 테스트가 이미 있다검사 있음. 팀원은 "아침에 사람이 결과를 눈으로 확인하면 된다" 고 한다. 작업이 사람 없이 제대로 끝나게 하려면?

시험 대비

함정

  • "사람이 매번 결과를 눈으로 확인한다" 는 함정이다. 사람이 검증 루프가 된다. 검사를 준다
  • "모든 작업을 plan mode 로 한다" 는 함정이다. 작은 수정에는 오버헤드다. diff 가 한 문장이면 건너뛴다
  • "대시보드 좀 좋게" 한 줄만 주는 것은 함정이다. 스크린샷을 붙인다. 결과 스크린샷과 비교해 차이를 나열하고 고치게 한다
  • "빌드가 실패하면 오류를 억눌러 통과시킨다" 는 함정이다. 근본 원인을 고치고 빌드 성공까지 확인한다
  • "같은 세션에서 계속 교정한다" 는 함정이다. 두 번 넘으면 /clear 하고 새로 시작한다
  • "Claude 요약이 '완료' 라서 완료다" 는 함정이다. 증거(테스트 출력·명령 결과)를 본다
  • "탐색으로 컨텍스트가 차니 plan mode 를 쓴다" 는 함정이다. plan mode 는 쓰기를 막는 것이다. 컨텍스트 보호는 서브에이전트가 한다
  • 반대쪽 함정도 있다. "계획은 늘 건너뛴다" 와 "막연한 프롬프트는 늘 오답이다" 는 함정이다. 탐색적 작업은 계획 없이 한다. 막연한 질문이 맞을 때도 있다

신호

"Give Claude something that produces a pass or fail, and the loop closes on its own."

"Without a check it can run, “looks done” is the only signal available, and you become the verification loop"

"Separate research and planning from implementation to avoid solving the wrong problem."

"If you could describe the diff in one sentence, skip the plan."

"If you’ve corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches."

"Have Claude show evidence rather than asserting success"

보통은 검사를 주고 계획 뒤 구현하지만, diff 가 한 문장이면 바로, 목표만 한 문장이고 코드가 낯설면 계획 쪽, 밤새 무인이면 /goal 이나 Stop hook 으로 올린다.
그림으로 보기 (AI 생성 · Codex · 누르면 크게) — 자세한 조건은 아래 '더 깊이'에 있어요
더 깊이 : 뒤집히는 때 · 오답 재료 (설명)

뒤집히는 때

1. 계획은 늘 좋은 것? — 작은 수정이면 뒤집힘

  • 조건 : 변경이 파일 1개이고 한 문장으로 설명된다(예 "결제 재시도 횟수 상수를 3에서 5로").
  • 판단 : plan mode 는 오버헤드다. 이 조건이면 바로 구현이 공식 답이다. 지문이 "모든 변경에 계획을 강제" 하는 팀 규칙을 제안하면 그 보기는 오답 쪽이다.
  • 등급 : (best-practices)

2. 한 문장인데 코드가 낯설 때

  • 조건 : "로그인 토큰 갱신을 고친다" 처럼 한 문장이다. 하지만 건드릴 코드를 처음 본다.
  • 판단 : 공식의 계획 기준 셋 중 "낯선 코드" 에 걸린다. 한 문장 기준은 diff 를 말할 수 있냐이지 목표 를 말할 수 있냐가 아니다. 어느 파일의 무엇을 바꿀지 모르면 diff 를 한 문장으로 말하지 못한다. 그래서 계획(최소한 탐색) 쪽이다.
  • 등급 : 업계 일반 (공식 두 문장 "unfamiliar with the code" · "describe the diff in one sentence" 을 이어 읽은 해석이다. 둘을 함께 다룬 공식 문장은 없다)
  • 근거 : best-practices

3. "두 번 넘게 교정하면 새로" 가 안 맞을 때

  • 조건 : 교정이 여러 번이지만 매번 다른 문제다. 한 복잡한 문제를 깊게 파는 중이다.
  • 판단 : 공식 규칙은 "같은 문제" 를 두 번 넘게 교정한 경우다. 기록이 값진 깊은 작업이면 컨텍스트를 쌓아 두라는 공식 문장도 있다. 그래서 교정 횟수만 세서 /clear 하는 보기는 약하다.
  • 등급 : (best-practices)

4. 검사는 줬는데 무인 실행이 중간에 "끝났다" 고 멈출 때

  • 조건 : 프롬프트에 "테스트 돌리고 고쳐" 를 넣고 밤새 돌렸다. 아침에 보니 절반쯤에서 끝났다고 보고했다.
  • 판단 : 한 프롬프트 방식에서는 Claude 가 스스로 멈출 수 있다. 무인 실행은 /goal(매 턴 별도 평가)이나 Stop 훅(통과 전 턴 종료 차단)으로 올린다.
  • 등급 : (best-practices). Stop 훅의 연속 차단 상한 수치는 열람하지 않았다미해결 2.

오답 재료

오답왜 끌리나왜 틀리나근거
"사람이 매번 결과를 눈으로 확인한다"사람 검토가 가장 안전해 보인다사람이 검증 루프가 되고 실수가 전부 사람을 기다린다. 검사를 준다best-practices
"모든 작업을 plan mode 로"계획은 늘 좋아 보인다오버헤드다. diff 가 한 문장이면 건너뛴다best-practices
"더 길고 정중한 지시로 다시 쓴다"설명이 모자라서 틀린 것 같다필요한 것은 파일·시나리오·"고쳐진 모습" 과 돌릴 검사다. 교정이 쌓였으면 새로 시작한다best-practices
"빌드가 깨지면 오류를 억눌러 통과시킨다"초록불이 빨리 뜬다근본 원인을 고치고 빌드 성공까지 확인한다best-practices "address the root cause, don’t suppress the error"
"탐색으로 컨텍스트가 차니 plan mode 로"plan mode 가 신중 모드로 보인다plan mode 는 변경을 막는 것이다. 컨텍스트 보호는 서브에이전트가 한다best-practices
"Claude 가 '완료' 라고 요약했으니 머지"요약이 깔끔하다주장이 아니라 증거를 본다. 무인 실행이면 diff 부터 본다best-practices · Skilljar cci 486938
"같은 세션에 교정을 계속 쌓는다"맥락이 이어져 유리해 보인다실패한 시도가 컨텍스트를 더럽힌다. 두 번 넘으면 /clear 한다best-practices
"막연한 프롬프트는 늘 오답" (반대 함정)구체적 지시가 정답이라 외웠다탐색 중에는 막연한 질문이 모르는 것을 끌어낸다best-practices

참고

함께 보기

더 깊이 : CCA-F · 출처 · 상태 · 미해결 (참고)

CCA-F

겹침 (3.4 계획 모드 vs 직접 실행, diff 한 문장이면 직접 · 3.5 반복 개선, 예시·검사로 루프 닫기, 두 번 넘게 교정하면 /clear). 여기서는 팀이 일을 맡기는 흐름으로 묻는다. 검사를 어디에 얼마나 세게 거는지(프롬프트 · /goal · Stop 훅 · 검증 서브에이전트) 묻는다. 무인 실행을 무엇으로 끝내는지도 묻는다

출처

상태

  • 모든 줄을 공식 문서에서 확인

미해결

  1. 목록 영상 근거(Part 16 [08:55] "스킬·서브에이전트로 한정 작업 위임")는 유튜브 원문을 열지 않아 대조하지 않았다. 카드는 공식 원문만 쓴다.
  2. Stop 훅의 연속 차단 상한과 /goal 이 멈추는 조건 수치는 hooks·goal 문서를 열지 않아 카드에 넣지 않았다(best-practices이 링크만 준다).
  3. 권한 기본값 문장("v2.1.283 이상은 auto mode 가 기본", best-practices)은 버전 조건이다. 시험 시점(v1.0 가이드) 값과 다를 수 있어 카드에 넣지 않았다. Claude Code 버전별 날짜는 조회하지 않았다.