Claude Code 명령어는 다 외웠는데 손이 멈추는 사람을 위한 첫 한 수

금요일 밤, 후배가 슬랙으로 이런 메시지를 보냈습니다. “Claude Code 명령어는 다 외웠는데, 다음에 뭘 입력해야 할지 몰라서 멈춰 있어요.” 그는 /init도 /clear도 claude -p도 말할 수 있습니다. 그런데 자기 저장소를 앞에 두면 손가락이 멈춰 버립니다.

이건 실력 문제가 아닙니다. 명령어 표는 그냥 “도구 이름” 목록일 뿐이라, “처음에 무엇을, 어디까지, 어떻게 확인하고 맡길지”까지는 적혀 있지 않습니다. 그래서 외우면 외울수록 오히려 움직이지 못하는 사람이 생깁니다.

이 글은 그 “외웠는데 손이 멈추는” 상태를 벗어나기 위한, 가장 작은 첫 한 수를 내는 법에 관한 이야기입니다.

핵심 요약

• 명령어를 외워도 멈추는 건 허용할 범위, 건드리지 말 파일, 되돌리는 법, 확인하는 법 이 네 가지가 정해지지 않았기 때문입니다.
• 첫 성과는 “한 문단만 고치기” “실패한 테스트의 의미만 설명시키기” 정도로 작아도 됩니다.
• 맡기기 전에 편집이 아니라 “계획만 돌려줘”라고 부탁하면 사고가 급격히 줄어듭니다.
• 확인은 사람 눈보다 git diff 같은 기계로 알 수 있는 명령을 먼저 정해 둡니다.
• 익숙해지면, 안전하다고 확인된 작업만 조금씩 자동으로 승격합니다.

왜 표를 외워도 멈추는가

명령어 목록은 지도로 치면 “도로 표지판 목록”입니다. 표지판 이름을 다 외워도, 목적지와 꺾을 지점이 정해지지 않으면 차는 출발하지 못합니다.

멈추는 사람에게 부족한 건 지식이 아니라, 이 네 가지를 말로 정리하는 습관입니다.

• 어떤 파일을 읽히고, 어디는 건드리지 않게 할 것인가
• 첫 변경을 얼마나 작게 자를 것인가
• 잘됐다고 말할 수 있는 조건은 무엇인가 (무엇을 보면 성공인가)
• 실패했을 때 어떻게 원래대로 되돌릴 것인가

저도 처음엔 “이 프로젝트 알아서 좋게 만들어 줘”라고 통째로 던졌다가, 30개 파일이 바뀐 변경분을 앞에 두고 멈춰 버렸습니다. 읽을 수 없는 변경분은 확인할 수 없습니다. 확인할 수 없는 변경은 무서워서 채택할 수 없습니다. 그래서 처음에는 웃길 만큼 작게 시작하는 게 정답입니다.

첫 한 수는 이 정도로 작아도 된다

“성과”라고 하면 큰 기능 추가를 떠올리기 쉽지만, 처음에는 이 수준으로 충분합니다.

• README 도입문을 3줄만 읽기 쉽게 고치기
• 글 하단 안내문을 한 문장만 추가하기
• 실패한 테스트의 의미를 “고치지 말고” 설명시키기

세 번째가 특히 추천입니다. 코드를 한 줄도 바꾸지 않으니 망가질 일이 없습니다. 그런데도 “Claude Code에 내 저장소를 읽히고, 답이 돌아왔다”는 첫 감각은 제대로 얻을 수 있습니다. 멈춰 있는 사람은 우선 여기서부터 손가락을 움직이면 좋습니다.

맡길 범위와, 사람이 정할 범위

Claude Code에 맡길 일과 사람이 쥐고 있어야 할 판단은, 처음부터 명확히 나눠 둡니다. 애매한 채로 돌리면 대개 사람이 판단해야 할 부분까지 멋대로 진행합니다.

상황	Claude Code에 맡긴다	사람이 정한다
범위 정하기	후보 파일을 찾아 제안	건드려도 되는 범위의 최종 결정
편집	문장·코드 초안	채택할지 여부
확인	테스트 실행·변경분 요약	공개해도 되는지 판단
위험 작업	방법 제안까지	삭제·운영 반영·과금 실행

핵심은 오른쪽 열입니다. 삭제, 운영 환경 반영, 돈이 움직이는 작업, git push --force처럼 되돌리기 어려운 작업은 처음에는 전부 “사람이 누른다”로 고정합니다. 안전하다고 스스로 확인한 것만 나중에 왼쪽으로 옮겨 갑니다. 이 순서만 지켜도, 한밤중에 식은땀 흘리는 횟수가 확 줄어듭니다.

우선 “계획만” 돌려받기

대뜸 편집시키지 않는 게 요령입니다. 첫 요청에서는 손을 못 움직이게 하고, 계획만 말하게 합니다. 아래 프롬프트를 그대로 붙여 쓸 수 있습니다.

이제부터 작은 변경 하나만 부탁합니다. 아직 편집은 하지 마세요.
먼저 다음 4가지를 글머리표로 돌려주세요.

1. 건드릴 파일 (하나만)
2. 건드리지 않을 파일 (.env 나 인증·과금 관련은 절대 건드리지 않음)
3. 변경 내용 (동작은 바꾸지 말고, 문장만 고침)
4. 변경 후 내가 확인할 명령 (git diff 등)

이 4가지에 내가 OK 하면, 그때 편집을 시작하세요.

돌아온 4가지를 보고, 건드릴 파일이 하나로 좁혀져 있고 확인 명령까지 적혀 있으면 요청의 입자 크기가 맞습니다. 반대로 “저장소 전체를 점검하겠습니다” 같은 답이면 아직 부탁 범위가 너무 넓다는 신호입니다. 범위를 좁혀서 같은 형식으로 다시 부탁합니다.

요청문을 잘 못 쓰겠다 싶으면 Claude Code 프롬프트 설계와 CLAUDE.md 작성법이 토대가 됩니다. 프로젝트 규칙을 먼저 건네 두면 계획의 품질이 한 단계 올라갑니다.

복사해서 쓰는, 첫 한 수 체크리스트

머릿속 네 가지를 매번 파일에 적어 내는 건 번거롭습니다. 그래서 답하기만 하면 “첫 한 수 메모”가 만들어지는 작은 스크립트를 둡니다. Node.js가 있으면 동작합니다.

// first-win.mjs — 첫 한 수를 1분 만에 말로 정리하는 메모 생성
// 사용법: node first-win.mjs

const plan = {
  목표: "Claude Code로 작은 변경 하나를 안전하게 통과시키기",
  건드릴파일: ["README.md"],            // 하나로 좁힌다
  건드리지않을파일: [".env", "인증", "과금", "운영DB"],
  첫명령: "git status --short",         // 지금 상태를 확인
  변경내용: "도입문을 3줄만 읽기 쉽게. 동작은 바꾸지 않음",
  확인방법: "git diff -- README.md",    // 변경분이 읽히는 범위인가
  되돌리는법: "git checkout -- README.md", // 안 되면 즉시 원복
};

// 체크: 건드릴 파일이 하나로 좁혀졌는가
if (plan.건드릴파일.length !== 1) {
  console.error("⚠ 건드릴 파일은 처음엔 하나로 좁히세요");
  process.exit(1);
}

console.log("=== 첫 한 수 메모 ===");
for (const [key, value] of Object.entries(plan)) {
  const text = Array.isArray(value) ? value.join(", ") : value;
  console.log(`${key}: ${text}`);
}
console.log("\n이 메모를 Claude Code에 붙이고 '편집 전에 계획을 돌려줘'라고 부탁");

실행은 이게 전부입니다.

node first-win.mjs

나온 메모를 그대로 Claude Code에 붙이고, 위의 “계획만 돌려줘” 프롬프트와 함께 씁니다. 건드릴 파일이 둘 이상이 되면 첫 줄에서 멈추도록 만들어 뒀으니, 욕심을 부릴 때의 제동 장치도 됩니다.

실제로 효과 있었던 쓸 자리 3가지

저나 주변 사람들이 “첫 한 수”로 골라서 제대로 앞으로 나아간 예를 셋 들겠습니다.

1. README 도입문 고치기. 명령어를 찾으러 온 독자를 위해, 처음 3줄만 쉽게 풀어 씁니다. 확인은 git diff만으로 끝나서, 변경분이 읽힌다는 실감을 최단으로 얻을 수 있습니다. 여기서 자신감이 붙습니다.

2. 글 하단 안내문을 한 문장 더하기. 설명이 빈약한 곳에 한 문장만 추가하고, 링크 대상이 살아 있는지 공개 URL로 열어 확인합니다. 문장만 바꾸는 거라 코드를 망칠 걱정이 없습니다.

3. 실패한 테스트의 의미를 설명시키기. 여기서는 고치게 하지 않습니다. “에러의 의미” “관련될 법한 파일” “다음에 사람이 볼 지점” 이 셋만 돌려받습니다. 코드를 한 줄도 안 건드리고 원인의 짐작을 잡는 연습이 됩니다.

세 가지에 공통된 건, 확인이 한 명령으로 끝나는 것과 실패해도 1초면 되돌릴 수 있다는 점입니다. 비개발자 분은 비개발자를 위한 Claude Code 활용도 함께 읽으면 문장 쪽 첫 한 수를 고르기가 쉬워집니다.

흔한 함정과 그 고치는 법

함정 1: 표를 본 직후 “이 저장소를 좋게 만들어 줘”라고 부탁한다. 범위가 너무 넓어서 돌아온 변경분을 읽을 수 없게 됩니다. 고치는 법은 단순합니다. “한 파일·한 문단”까지 좁히기. 좁힐수록 첫 성과는 확실해집니다.

함정 2: 확인 방법을 뒤로 미룬다. 무엇을 보면 성공인지 정하지 않고 돌리면, 그럴듯한 결과가 나와도 채택해도 되는지 알 수 없습니다. 요청문에 처음부터 git diff 같은 확인 명령을 적어 둡니다.

함정 3: 대뜸 위험 작업을 맡긴다. 파일 삭제나 운영 반영을 처음부터 자동으로 두면 되돌릴 수 없는 사고로 이어집니다. 처음엔 전부 “사람이 누른다”로 고정하고, 안전하다고 확인된 것만 자동으로 승격합니다.

자주 묻는 질문

Q. 명령어는 어느 정도 외운 뒤에 시작하면 되나요. A. 3개면 충분합니다. /init, /clear, 그리고 변경을 확인하는 git diff. 나머지는 쓸 상황이 왔을 때 찾아보면 늦지 않습니다. 외우기 전에 작게 움직여 보는 쪽이 결국 더 빨리 익힙니다.

Q. 첫 한 수에 가장 알맞은 작업은 무엇인가요. A. 실패한 테스트의 의미를 “설명만” 시키는 작업입니다. 코드를 바꾸지 않으니 망가질 일이 없고, 저장소를 읽히는 감각만 얻을 수 있습니다. 기본 흐름은 입문 가이드에도 정리해 뒀습니다.

Q. 계획을 부탁했는데 바로 편집을 시작해 버립니다. A. 프롬프트 맨 앞에 “아직 편집하지 마세요”를 두고, 끝에 “내 OK를 기다리세요”를 덧붙입니다. 그래도 진행되면 변경 범위가 애매한 경우가 많으니, 건드릴 파일을 이름 지정해 하나로 한정합니다.

Q. 확인은 사람 눈으로 보면 충분하지 않나요. A. 바쁜 날에 반드시 무너집니다. 글자 수, 변경분, 테스트 통과 여부처럼 기계로 알 수 있는 확인을 먼저 정해 두면 놓치는 게 줄어듭니다. 사람의 판단은 “채택할지 여부”에 집중시키는 게 요령입니다.

Q. 익숙해지면 다음엔 무엇을 하면 되나요. A. 같은 “첫 한 수 메모”를 조금 큰 작업으로 넓힙니다. 확인 명령이 늘어도, 위험 작업은 사람이 쥔다는 원칙은 바꾸지 않습니다. 작업을 빠르게 하는 방법은 생산성 높이는 팁이 참고가 됩니다.

실제로 시험해 본 결과

서두의 후배에게는 우선 “실패한 테스트의 의미만 설명시키기” 한 수를 시켜 봤습니다. 코드는 안 건드립니다. 돌아온 건 원인 파일 이름과, 다음에 봐야 할 함수의 위치였습니다. 그는 “이건 할 수 있겠다”며 그날 안에 README 3줄 고치기까지 진행했습니다.

저 자신도 통째로 던지기를 그만두고 “계획만 돌려줘”를 끼워 넣은 뒤로, 읽을 수 없는 변경분을 앞에 두고 멈추는 시간이 거의 사라졌습니다. git diff로 확인할 수 있는 범위만 부탁한다, 위험 작업은 사람이 누른다. 이 둘만 지켜도 첫 한 수는 놀랄 만큼 가볍게 낼 수 있습니다. 명령어를 다 외울 필요는 없습니다. 작게 움직이고, 되돌릴 수 있는 범위를 확인한다. 거기서부터 시작하면 충분합니다.

학습을 한 단계 더 진행하고 싶은 분은 교재 목록을, 회사 업무에 어떻게 넣을지 상담하고 싶은 분은 연수·상담을 보세요. 자세한 명령어 동작은 공식 문서가 일차 정보로 가장 확실합니다.