Claude Code로 좋은 결과를 얻는 핵심은 한 번의 완벽한 프롬프트가 아니라 짧은 사이클의 반복입니다. 이 수업에서는 탐색→계획→구현→커밋 워크플로, 테스트 주도 반복, 궤도 수정 기법, 컨텍스트 초기화 시점을 다룹니다.
탐색 → 계획 → 구현 → 커밋 사이클
공식 모범 사례가 권하는 기본 사이클은 네 단계입니다.
- 탐색(Explore). 관련 파일을 읽게 하되 아직 코드를 쓰지 말라고 명시합니다. "src/auth/ 를 읽고 로그인 흐름을 설명해라. 아직 수정하지 마라."
- 계획(Plan). 접근 방법을 세우게 합니다. 복잡한 문제일수록 사고를 깊게 요구하고, 플랜 모드(3.4)를 활용합니다.
- 구현(Implement). 계획 승인 후 구현을 진행합니다. 구현 중에도 각 단계에서 자기 검증(테스트 실행, 타입 체크)을 하도록 지시합니다.
- 커밋(Commit). 의미 있는 단위마다 커밋해 되돌릴 수 있는 체크포인트를 만듭니다. PR 생성과 설명 작성까지 맡길 수 있습니다.
이 순서가 중요한 이유는, 탐색·계획 없이 곧바로 구현을 시키면 Claude가 첫 인상으로 잡은 잘못된 접근에 코드를 계속 쌓기 때문입니다. 잘못된 방향의 코드 500줄보다 올바른 방향의 계획 10줄이 낫습니다.
작게 자르기도 같은 원리입니다. "결제 기능 전체를 만들어라"보다 "1) 결제 요청 스키마 정의, 2) 검증 로직, 3) API 핸들러, 4) 테스트" 순서로 단계를 나눠 각 단계 결과를 확인하며 진행하면, 문제를 조기에 발견하고 궤도를 수정할 수 있습니다.
검증 가능한 목표 주기 — 테스트 주도 반복
반복 개선이 작동하려면 각 반복의 성공 기준이 기계적으로 검증 가능해야 합니다. 가장 강력한 형태가 테스트 주도(TDD) 워크플로입니다.
- 기대 동작을 설명하고 실패하는 테스트를 먼저 작성하게 합니다. 이때 구현을 같이 만들지 말라고 명시합니다.
- 테스트가 실패하는 것을 실행으로 확인시킵니다.
- 테스트를 통과하는 구현을 작성하게 하고, 통과할 때까지 실행-수정을 반복하게 합니다.
- 통과 후 리팩터링을 요청합니다. 테스트가 안전망이 됩니다.
좋은 지시의 예:
"응모 마감일이 지난 공모는 목록에서 제외돼야 한다.
이 동작을 검증하는 테스트를 tests/filter.test.ts에 먼저 작성해라.
구현은 아직 만들지 마라. 테스트가 실패하는 것을 실행으로 확인해라."
테스트 외에도 검증 루프로 쓸 수 있는 것은 많습니다. 타입 체커(tsc), 린터, 빌드, 스크린샷 비교, 실제 실행 로그 확인 등 "Claude가 스스로 실행해 결과를 볼 수 있는 것"이면 모두 반복의 피드백 신호가 됩니다. 시험에서는 "출력이 맞는지 사람이 눈으로 확인한다"보다 "실행 가능한 검증 수단을 제공한다"가 항상 더 나은 선택지입니다.
주의할 함정은 테스트를 통과시키기 위한 편법 구현(테스트 삭제, 하드코딩)입니다. "테스트를 수정하지 말고 구현만 고쳐라"를 명시하고, 통과 후 구현을 리뷰하는 습관이 필요합니다.
궤도 수정과 컨텍스트 관리
반복 중 방향이 어긋났을 때 쓰는 도구들이 있습니다.
Escape로 중단. 진행 중인 응답이 잘못된 방향이면 Esc로 즉시 중단하고 지시를 수정합니다. 끝까지 기다렸다가 고치는 것보다 훨씬 쌉니다.
이전 시점으로 감기. Esc를 두 번 눌러 대화 히스토리의 이전 시점으로 돌아가 다른 지시로 분기할 수 있습니다. 코드 변경도 체크포인트에서 함께 되돌릴 수 있어, 잘못된 반복 몇 번을 통째로 무를 수 있습니다.
/clear로 초기화. 한 작업이 끝나고 다음 작업으로 넘어갈 때는 /clear로 컨텍스트를 비웁니다. 이전 작업의 흔적이 남아 있으면 무관한 맥락이 새 작업의 판단을 오염시키고 토큰도 낭비됩니다.
git 체크포인트. 의미 단위마다 커밋해 두면 어떤 반복이 실패해도 git reset으로 안전하게 돌아갑니다. "여러 번 시도하고 최선을 고르는" 실험적 반복은 브랜치나 워크트리(worktree)를 나눠 진행합니다.
# 실험 반복용 워크트리 분리
git worktree add ../experiment-a feature-a
# 실험이 실패하면 워크트리만 버리면 된다
경험적 규칙은 이렇습니다. 같은 문제를 세 번 이상 고쳐 달라고 반복하고 있다면, 반복을 멈추고 (a) 지시가 모호하지 않은지, (b) 컨텍스트가 오염되지 않았는지(/clear 후 재시작), (c) 문제를 더 작게 잘라야 하는지 점검할 시점입니다.
시험 함정
- 탐색·계획 단계를 생략하고 곧바로 구현시키는 것이 효율적이라고 생각하기 — 복잡한 작업일수록 선(先)계획이 총 비용을 줄입니다.
- TDD 워크플로에서 테스트와 구현을 동시에 작성하게 하기 — 실패하는 테스트를 먼저 확인하는 것이 핵심입니다.
- 사람 눈 검증을 자동 검증보다 우선하는 선택지 고르기 — 기계적으로 실행 가능한 피드백 루프가 정답 방향입니다.
- 작업 전환 시 /clear 없이 이어가는 것을 정상으로 보기 — 무관한 컨텍스트는 판단을 오염시킵니다.
- 잘못된 방향의 응답을 끝까지 기다리는 것 — Esc 중단·재지시가 표준 궤도 수정 방법입니다.
- 테스트 통과만 확인하고 편법 구현(하드코딩·테스트 수정)을 점검하지 않기.
실습 시나리오
실제 시험과 같은 형식의 시나리오 문제입니다.
Claude에게 버그 수정을 맡겼는데, 세 번 연속 '고쳤다'고 답했지만 실제로는 계속 같은 버그가 재현됩니다. 대화는 이미 길어진 상태입니다. 다음 행동으로 가장 적절한 것은?
빌드 연습 · TDD 사이클로 기능 하나 완성
약 60분1.탐색
구현 없이 관련 모듈을 읽고 현재 동작을 요약하게 합니다.
기대 결과 · 수정 없이 현재 구조 요약과 변경 지점 후보가 나옵니다.
2.실패하는 테스트 작성
새 기능의 기대 동작을 테스트로만 작성하게 하고 실행해 실패를 확인합니다.
기대 결과 · 구현 코드 없이 테스트 파일만 생기고, 실행 결과는 실패입니다.
3.구현 반복
'테스트를 수정하지 말고' 통과할 때까지 구현-실행을 반복하게 합니다.
기대 결과 · 테스트가 통과하고, 테스트 파일은 변경되지 않았습니다.
4.궤도 수정 연습
구현 중 일부러 잘못된 방향을 지시했다가 Esc로 중단하고 지시를 교정합니다.
기대 결과 · 중단-재지시 흐름을 체험하고 잘못된 코드가 쌓이기 전에 방향이 바뀝니다.
5.커밋과 초기화
완성 단위를 커밋한 뒤 /clear로 컨텍스트를 비우고 다음 작업을 시작합니다.
기대 결과 · 커밋 체크포인트가 남고 새 작업이 깨끗한 컨텍스트에서 시작됩니다.