도구 사용법을 다 익혀도, '어떤 순서로 일을 시키느냐'에 따라 결과는 천차만별입니다. 이번 레슨은 클로드 코드를 오래 써 온 사람들의 워크플로우 철학을 모았습니다. 핵심은 '계획과 구현을 분리하고, 스스로 검증하고, 가정을 일찍 바로잡는 것'입니다.
계획 세션과 구현 세션을 분리하라
큰 작업을 한 세션에서 '계획부터 구현까지' 몰아서 하면, 구현에 들어갈 즈음엔 이미 컨텍스트가 계획 논의로 가득 차 있습니다. 부푼 책상 위에서 코딩하면 실수가 늘죠. 고수들은 plan 모드로 설계를 끝내고 검토한 다음, 새 세션(또는 /clear)에서 '신선한 책상'으로 구현을 시작합니다.
계획-구현 분리 루프
- plan 모드로 전환해 작업 계획을 세우게 한다. (파일은 안 건드림)
- 계획을 꼼꼼히 읽고, 이상한 가정이나 빠진 부분을 대화로 바로잡는다.
- 완성된 계획을 파일(예: docs/plan.md)로 저장하게 한다.
- /clear 또는 새 세션으로 컨텍스트를 비운다.
- 새 세션에서 '@docs/plan.md 이 계획대로 1단계만 구현해 줘'로 작게 시작한다.
- 테스트·실행으로 검증한다. 통과하면 커밋, 문제가 생기면 직전 커밋으로 되돌린다.
- 다음 단계를 같은 방식으로 반복한다.
작업은 잘게 쪼개라
"결제 시스템 전체를 만들어 줘" 같은 거대한 지시는 금물입니다. 한 번에 너무 많은 파일이 바뀌어 검토가 불가능해지고, 어디서 틀어졌는지 추적도 어렵습니다. "결제 웹훅 핸들러 하나만 구현"처럼, 한 번에 검토할 수 있는 크기로 나누세요.
사고 과정을 읽고, 틀리면 즉시 멈춰라
클로드는 작업 전 자신의 사고 과정(어떤 가정을 세우고 어떻게 접근할지)을 보여줍니다. 이걸 흘려보내지 마세요. 잘못된 가정 위에 쌓인 코드는 나중에 전부 버려야 합니다. 가정이 틀렸다 싶으면 Esc로 즉시 중단하고 바로잡는 것이, 다 만든 뒤 갈아엎는 것보다 훨씬 쌉니다. '10초 멈춤이 10분을 아낀다'고 생각하세요.
TDD 루프로 안전하게
작은 변경 -> 테스트 -> 통과 확인 -> 커밋. 이 짧은 루프를 반복하면 문제가 생겨도 바로 직전 커밋으로 안전하게 돌아올 수 있습니다. 커밋이 촘촘할수록 되돌리기의 손실이 작아집니다.
다른 AI에게 교차검증 시키기
한 모델의 시야에는 사각지대가 있습니다. 세운 계획을 /export로 내보내 다른 AI(다른 모델이나 다른 서비스)에게 '이 계획에서 놓친 점과 리스크를 지적해 줘'라고 물으면, 서로 다른 관점에서 허점이 드러납니다. 사람도 다른 사람에게 검토받으면 실수를 더 잘 찾는 것과 같습니다.
다른 AI에게 계획을 교차검증시키는 프롬프트
아래는 내가 세운 구현 계획이야. 너는 이 계획을 처음 보는 깐깐한 시니어 아키텍트라고 생각하고 비평해 줘.
- 이 계획이 놓치고 있는 엣지 케이스나 실패 시나리오
- 숨은 리스크 (보안, 성능, 데이터 정합성)
- 더 단순하게 갈 수 있는 대안
- 순서상 잘못된 단계나 빠진 전제
각 지적에 심각도(높음/중간/낮음)를 붙여 줘.
[계획]
(여기에 export한 계획 붙여넣기)이 교차검증 과정 자체를 커스텀 스킬이나 슬래시 명령으로 굳혀 두면, 앞으로 계획을 세울 때마다 한 번에 검증을 돌릴 수 있습니다.
WAT 프레임워크로 정리하기
지금까지의 원칙을 기억하기 쉽게 WAT라는 틀로 묶어 봅시다. Workflow, Agent, Tools의 앞 글자입니다.
| 글자 | 의미 | 실천 |
|---|---|---|
| W (Workflow) | 작업 흐름을 쉬운 말로 명확히 | "배포"가 아니라 "테스트 -> 커밋 -> 푸시 -> 상태확인"까지 풀어서 정의 |
| A (Agent) | 셀프힐링 + 서브에이전트 병렬 | 클로드가 스스로 오류를 고치게 하고, 독립 작업은 서브에 나눠 위임 |
| T (Tools) | 거대한 만능 스크립트보다 작은 도구 여러 개 | 한 가지 일만 하는 작은 스크립트를 여러 개 조합 |
계획 검토와 교차검증에 시간을 아끼지 마세요. 잘못된 계획으로 세 시간 코딩하는 것보다, 계획을 30분 검토해 방향을 바로잡는 것이 압도적으로 이득입니다. '느리게 계획하고 빠르게 구현하라'가 고수들의 공통된 리듬입니다.
"고쳤습니다", "테스트 통과했습니다"라는 클로드의 말을 그대로 믿지 마세요. 특히 교차검증 상황에선 두 AI 모두 '괜찮다'고 해도 실제 실행 결과가 다를 수 있습니다. 반드시 테스트를 직접 돌리거나 실행 로그 같은 '증거'를 요구하세요. 보고가 아니라 증거로 판단하는 것이 원칙입니다.
정리하면 고수의 워크플로우는 '느린 계획, 이른 개입, 잦은 검증'입니다. 계획과 구현을 분리하고, 가정이 틀리면 즉시 멈추고, 다른 시선으로 교차검증하며, 늘 증거로 확인하세요. 도구보다 이 리듬이 결과를 바꿉니다.