Claude Code 첫 주 command map: 초보자가 순서대로 실행할 12개 명령

왜 별도 산출물로 만들어야 하는가

이 글은 Claude Code를 설치하고 차분한 첫 주가 필요한 초보자를 위한 첫 주 command map를 만든다. 흔한 실패는 단순하다. 새 사용자가 설치 직후 큰 요청으로 뛰어들고 어떤 명령으로 진행을 증명할지 모른다. Claude Code 작업은 자신감 있는 답변에서 끝나면 안 된다. 다른 사람이 확인할 수 있는 산출물을 남겨야 한다. 여기서 산출물은 repo 읽기에서 작은 변경 검증까지 이어지는 day-by-day command map이다.

이 산출물을 prompt, command line, public page 사이의 계약으로 다룬다. Claude Code가 무엇을 읽었고, 무엇을 바꿨고, 어떤 command로 증명했으며, 독자를 다음에 어떤 revenue path로 보낼지 보여야 한다. 이 주제는 harness engineering, getting started, permissions와 연결된다.

운영 루프

루프는 다섯 단계다. action을 정의하고, proof를 고르고, Claude Code가 가장 작은 유용한 일을 하게 하고, output을 검증하고, 다음 revenue action을 기록한다. 여기서 proof는 코드 실행만이 아니다. build 성공, 작은 diff, 승인 surprise 감소, 초보자 글의 PDF 시작를 본다. 이 필드가 보이면 추측으로 글을 고치지 않는다.

1. 1일차는 read-only로 파일, command, 위험 디렉터리를 먼저 파악한다.

2. 3일차는 되돌릴 수 있는 한 가지 수정만 허용하고 수정 전에 proof command를 고른다.

3. 5일차는 handoff note를 남겨 다음 세션이 기억이 아니라 증거에서 시작하게 한다.

복사해서 쓰는 starter

$checks = @(
  "git status --short",
  "rg --files | Select-Object -First 40",
  "npm.cmd run build"
)

foreach ($cmd in $checks) {
  Write-Host "NEXT:" $cmd
}

현장 예시 세 가지

예시 1. 1일차는 read-only로 파일, command, 위험 디렉터리를 먼저 파악한다.

예시 2. 3일차는 되돌릴 수 있는 한 가지 수정만 허용하고 수정 전에 proof command를 고른다.

예시 3. 5일차는 handoff note를 남겨 다음 세션이 기억이 아니라 증거에서 시작하게 한다.

셀프 리뷰 체크

이 workflow를 습관으로 만들기 전에 release note처럼 글을 다시 본다. 첫 번째는 scope다. 독자가 언제 첫 주 command map를 쓰고, 언제 더 작은 checklist로 충분한지 알아야 한다. 두 번째는 proof다. 모든 권장 사항은 command, URL, diff, metric 중 하나로 이어져야 한다. 세 번째는 routing이다. free PDF, Gumroad guide, consultation path가 서로 경쟁하지 말고 다른 긴급도에 답해야 한다.

작은 owner rule도 둔다. artifact owner, verification owner, next CTA experiment owner를 구분한다. solo workflow라면 같은 사람이어도 된다. 하지만 note에는 역할 이름을 남긴다. 이렇게 하면 Claude Code가 publishing, measuring, selling을 하나의 흐린 task로 다루기 어렵다. 다음 run도 어디서 이어갈지 더 쉽게 판단한다.

가장 실용적인 질문은 이것이다. 내일 아침 이 글을 더 쉽게 검증하게 만드는 것은 무엇인가? 답이 screenshot이면 저장한다. 답이 더 강한 prompt이면 prompt pack에 넣는다. 답이 더 명확한 boundary이면 setup note에 넣는다. repo 읽기에서 작은 변경 검증까지 이어지는 day-by-day command map는 다음 session에서 살아남을 때만 유용하다.

실패 사례

첫 번째 실패는 PV만 점수로 삼는 것이다. 두 번째는 proof command 없이 변경을 승인하는 것이다. 세 번째는 free PDF나 consultation이 더 맞는 독자에게도 같은 paid product만 보내는 것이다. CTA를 바꾸기 전에 routing rule을 쓰면 이 문제를 줄일 수 있다.

수익 경로

독자는 병목으로 나눈다. command fluency가 필요하면 free PDF 또는 free Gumroad cheatsheet로 보낸다. 같은 일을 매주 반복하면 50 Prompt Templates나 Setup Guide가 맞다. rollout, risk, revenue design이 문제라면 consultation이다. 이 글에서는 free cheatsheet는 매일 command 기억에, Setup Guide는 팀 규칙화에 맞다.

검증 지표

게시 후에는 HTTP 200만 보지 않는다. h1, canonical, hero image, 본문 첫 부분, CTA link, mobile layout, language를 확인한다. 그리고 build 성공, 작은 diff, 승인 surprise 감소, 초보자 글의 PDF 시작를 본다. 지표가 움직이지 않으면 전체 rewrite보다 첫 번째 구체 예시 근처의 CTA를 먼저 고친다.