Claude Code 초보자의 하루 15분 루틴: 아침에 돌리는 안전한 작업 순서

금요일 밤, 저는 Claude Code에게 “이 프로젝트에서 신경 쓰이는 부분 전부 고쳐 놔” 하고 던지고 잠들었습니다.

다음 날 아침, 바뀐 파일은 23개. 돌아가는 코드도 있었습니다. 그런데 무엇이 진짜로 고쳐진 건지, 무엇을 확인하면 되는지 저 자신조차 도무지 설명할 수가 없었습니다. 변경 내역을 위에서 아래까지 읽기만 하는 데 1시간이 걸렸고, 결국 무서워서 한 줄도 커밋하지 못했습니다.

똑똑한 AI에게 크게 맡겼는데, 앞으로 나아가기는커녕 뒤로 물러난 셈이죠. 이게 초보자가 가장 먼저 빠지는 함정입니다.

원인은 Claude Code의 성능이 아닙니다. 작업을 “어떻게 끝낼지”를 정해 두지 않았을 뿐입니다. 오늘은 제가 매일 아침 커피를 내리는 동안 하는 15분짜리 순서를, 그대로 넘겨 드리겠습니다.

핵심 요약

• “전부 고쳐”는 사고의 근원입니다. 매일 하는 건 “한 문장으로 정한 작은 일 하나”뿐으로 합니다.
• 편집을 시작하기 전에, 끝났는지 아닌지를 판정할 확인 명령어를 먼저 정해 둡니다.
• 작업 후에는 “바뀐 파일”, “확인 명령어 결과”, “다음에 할 한 수” 세 가지만 남기면 충분합니다.
• AI에게 맡기는 건 손을 움직이는 부분입니다. 범위를 정하고 공개 버튼을 누르는 건 사람이 합니다.
• 아래 스크립트를 복붙하면 매일 아침 확인을 자동으로 나란히 돌릴 수 있습니다.

왜 “작게 끝내기”가 초보자에게 잘 듣는가

Claude Code를 막 만지기 시작했을 무렵의 저는, 매번 목표가 흐릿했습니다. “느낌 좋게 해 줘”, “읽기 쉽게 해 줘”. 이러면 AI가 무엇을 어디까지 했는지, 끝난 뒤에도 알 수가 없습니다.

사람 신입에게도 똑같은 말이 적용됩니다. “이 자료, 적당히 잘 부탁해”라는 부탁을 받은 사람은 대개 곤란해합니다. 반대로 “3페이지 숫자를 최신판으로 바꾸고, 표가 깨지지 않았는지 봐 줘”라는 지시를 받은 사람은 바로 움직일 수 있고, 끝났는지 아닌지도 스스로 판단할 수 있습니다.

매일의 루틴에서 중요한 건, 똑똑한 지시를 한 방에 써내는 게 아닙니다. 작게 끊고, 끝을 판정할 수 있는 형태로 만드는 것입니다. 이게 되면 초보자도 “오늘은 여기까지 나아갔다”라고 매일 말할 수 있게 됩니다.

참고로 이 사고방식의 토대는 다른 글인 Claude Code 시작하기와 권한 관리의 기본으로 이어집니다. 먼저 그쪽에서 환경을 정돈한 뒤에 이 습관을 얹으면 잘 듣습니다.

15분 동안 하는 건, 단 4단계

제가 매일 아침 하는 건 다음 네 가지뿐입니다. 순서도 매번 똑같이 합니다. 순서를 고정하면 생각하지 않아도 몸이 움직이니까요.

1. 오늘의 최소 작업을 한 문장으로 쓴다. “README 도입부를 3줄만 다시 쓴다”처럼, 끝이 보이는 단위로 정합니다. 큰 일은 일부러 오늘은 하지 않습니다.
2. 확인 명령어를 먼저 정한다. “npm run build가 통과하면 OK”, “테스트 1건이 초록불이 되면 OK”처럼, 편집을 시작하기 전에 목표의 형태를 정해 둡니다.
3. 작업하고, 변경 내역 → 빌드 → 공개 URL 순으로 확인한다. 곧장 공개하지 말고, 기계로 알 수 있는 곳부터 차례로 봅니다.
4. 다음번을 위해 한 줄만 남긴다. “남은 위험”과 “다음 최소 작업”을 메모합니다. 이게 다음 날 아침의 출발점이 됩니다.

핵심은 2번입니다. 확인 명령어를 먼저 정하지 않고 편집을 시작하면, “고쳐진 것 같긴 한데 확신이 없는” 그 금요일 밤으로 되돌아갑니다. 결승선 테이프를 쳐 놓고 달린다. 이것만으로 매일의 작업이 훨씬 가벼워집니다.

AI에게 맡길 범위와, 사람이 정할 범위

초보자가 가장 헷갈려하는 게 바로 여기라고 생각합니다. 뭐든 AI에게 통째로 던져도 되는 게 아니고, 전부 직접 할 거면 쓸 이유도 없죠. 선을 긋는 기준을 표로 정리했습니다.

장면	AI에게 맡긴다	사람이 정하고 누른다
범위 결정	후보를 뽑게 한다	오늘 할 한 문장을 확정한다
편집	코드나 글을 쓴다	무엇을 고칠지에 대한 방침
확인	빌드나 테스트 실행	어떤 확인을 목표로 삼을지
공개	변경 내역 요약을 낸다	공개 버튼을 누른다
위험 작업	”해도 되는지” 묻는다	삭제·운영 반영의 최종 판단

망설일 때의 기준은 단순합니다. 되돌릴 수 있는 작업은 AI에게, 되돌릴 수 없는 작업은 사람에게. 파일 편집은 얼마든지 다시 할 수 있으니 맡깁니다. 운영 환경 공개나 파일 삭제는 처음에는 반드시 직접 누릅니다. 익숙해진 조작만 나중에 조금씩 자동으로 승격합니다. 권한의 세부 설정은 Claude Code 공식 문서에 한 차례 정리되어 있으니, 선 긋기가 헷갈리면 한번 훑어 두면 안심됩니다.

복붙해서 쓰는 의뢰문 템플릿

매번 맨바닥에서 의뢰를 쓰면 단위가 흔들립니다. 저는 이 템플릿을 메모 앱에 붙여 두고, 매일 아침 빈칸을 채웁니다.

오늘의 최소 작업: （여기에 한 문장. 예: README 도입부 3줄을 다시 쓴다）
건드려도 되는 범위: （예: README.md만. 다른 파일은 변경 금지）
완료 확인 방법: （예: npm run build가 성공할 것）

진행 방법:
1. 먼저 변경하지 말고, 현재 상태를 읽고 요약해 주세요.
2. 위 범위만 편집해 주세요. 범위 밖은 건드리지 마세요.
3. 편집 후, 변경한 파일 이름과 확인 방법의 결과를 보고해 주세요.
4. 삭제·운영 반영·외부 전송이 필요하면, 실행하지 말고 먼저 확인해 주세요.

“범위 밖은 건드리지 않는다”, “위험한 조작은 먼저 확인” 이 두 줄을 넣어 두는 것만으로, 서두의 23파일 사고는 거의 일어나지 않게 됩니다. AI에게 자유를 주는 게 아니라, 안전한 상자를 건네는 이미지입니다.

복붙하면 돌아가는 확인 스크립트

매일 아침 확인을 손으로 치면 잊어버립니다. 저는 이 스크립트를 morning-check.mjs로 두고, 커피를 내리기 전에 돌립니다. Node.js가 깔려 있으면 동작합니다.

// morning-check.mjs : 매일 아침 확인을 순서대로 나란히 실행한다
import { execSync } from "node:child_process";

// 확인하고 싶은 명령어를 위에서부터 차례로 나열한다. 프로젝트에 맞춰 바꿔 쓴다.
const checks = [
  { label: "변경된 파일", cmd: "git status --short" },
  { label: "빌드가 통과하는가", cmd: "npm run build" },
];

let allOk = true;

for (const { label, cmd } of checks) {
  console.log(`\n=== ${label} : ${cmd} ===`);
  try {
    // 결과를 그대로 화면에 출력한다. 에러면 아래 catch로.
    const out = execSync(cmd, { encoding: "utf8" });
    console.log(out.trim() || "(출력 없음)");
  } catch (e) {
    allOk = false;
    console.log("실패:", e.message.split("\n")[0]);
  }
}

console.log("\n--- 오늘의 마무리 ---");
console.log(allOk ? "확인 OK. 다음 최소 작업을 한 줄로 남기자." : "확인이 멈췄다. 고치고 나서 다음으로.");

실행은 이것뿐입니다.

node morning-check.mjs

checks 안의 내용을 자기 프로젝트에 맞춰 바꿔 쓰는 게 요령입니다. 테스트가 있으면 npm test를, 정적 사이트라면 공개 URL 확인을 더합니다. 매일 아침 같은 명령어가 같은 순서로 흐르는 것만으로 확인 누락이 거의 사라집니다. 저는 여기에 “마지막에 커밋하지 않고 멈춰 있지는 않은가”라는 확인도 더했습니다.

이런 장면에서 잘 듣는다 (3가지)

예 1: 첫날은 저장소의 지도를 만들기만 한다 곧장 코드를 고치지 않아도 됩니다. “위험한 디렉터리는 어디인가”, “설정 파일은 어디에 있는가”를 AI에게 요약하게 하고, 그걸 읽기만 해도 첫날은 성공입니다. 다음 날부터의 작업이 훨씬 빨라집니다.

예 2: 둘째 날은 README의 한 단락만 작게 성공 경험을 만듭니다. 도입부를 3줄 다시 쓰고, npm run build로 망가지지 않았는지 확인. 이것만 합니다. 작게 끝내고 확인까지 제대로 통과시키면, “나도 돌릴 수 있다”라는 감각이 손에 들어옵니다.

예 3: 셋째 날은 숫자로 이어지는 작은 개선 하나 글의 제목을 고치거나, 테스트를 1건 더하거나, 깨진 링크를 1개 고칩니다. 성과가 보이는 작은 개선을 고릅니다. 중요한 건 매일 하나씩 “확인까지 통과한 변경”을 쌓는 것입니다.

실패 사례와, 그 고치는 법

솔직히 쓰자면, 저는 이 세 가지로 몇 번이나 넘어졌습니다.

함정 1: 한 번에 전부 하려고 한다. “신경 쓰이는 부분 전부”는 확인할 수 없는 거대한 변경 내역을 낳습니다. 고치는 법은 단순합니다. 오늘의 한 문장을 “하나”로 좁히는 것. 나머지는 내일의 메모로 돌립니다.

함정 2: 로컬 빌드만으로 완료로 친다. npm run build가 통과해도, 공개 URL이 제대로 나오고 있다는 보장은 없습니다. 저는 한 번, 빌드는 초록불인데 공개 페이지가 옛날 그대로여서 알아채지 못한 적이 있습니다. 고치는 법은, 공개 후에 실제 URL을 열어서 제목과 본문 첫머리가 이번 변경 내용으로 되어 있는지 눈으로 보는 것입니다.

함정 3: 위험한 승인을 흐름에 떠밀려 누른다. 확인 대화상자가 떴을 때, 초보자는 “일단 Yes”를 누르기 쉽습니다. 삭제나 운영 반영 확인이 오면, 일단 손을 멈춥니다. 판단이 헷갈리면, 그 조작은 오늘은 하지 않는 게 정답입니다. 권한의 사고방식은 비엔지니어를 위한 해설도 참고가 됩니다.

다음번에 남기는 메모의 형태

마지막에 남기는 메모는 짧아도 됩니다. 다만 다음 날 아침의 내가 같은 판단을 다시 하지 않도록, 형태만 정해 둡니다.

- 오늘 한 것: README 도입부 3줄을 다시 씀
- 확인한 방법: npm run build 성공 / 공개 URL에서 제목 확인
- 남은 위험: 이미지 깨진 링크가 2개 있음
- 내일의 최소 작업: 이미지 링크를 1개만 고침

이 메모가 있으면, 다음 날 아침 “무엇부터 시작할까”로 고민하는 시간이 0이 됩니다. 저는 이걸 시작하고 나서, 아침에 시동 거는 게 체감상 5분은 빨라졌습니다.

자주 묻는 질문

Q. 매일 15분도 못 냅니다. 더 짧게 할 수 있나요. 할 수 있습니다. 처음에는 “오늘의 최소 작업을 한 문장 쓴다”만으로도 OK입니다. 확인 명령어를 정하는 습관만 붙으면, 작업 시간은 자연스럽게 짧아집니다.

Q. 확인 명령어가 뭔지 모르겠습니다. 프로젝트에 npm run build나 npm test가 있으면, 우선 그걸로 충분합니다. 아무것도 없으면 “공개 URL을 열어서 눈으로 본다”가 훌륭한 확인입니다. 처음에는 기계로 알 수 있는 것을 하나 정하면 됩니다.

Q. 전부 AI에게 맡기는 편이 빠르지 않나요. 단기적으로는 그렇게 보입니다. 하지만 “무엇이 고쳐졌는지 설명할 수 없는 변경”은 결국 나중에 전부 다시 읽게 됩니다. 작게 끝내는 편이 전체적으로는 빠르다는 게 제 실감입니다.

Q. 초보자가 가장 먼저 해야 할 일은. 저장소의 지도를 만드는 것입니다. 코드를 고치기 전에, 어디에 무엇이 있는지를 AI에게 요약하게 해서 읽습니다. 이게 안전하게 나아가는 토대가 됩니다.

Q. 이 루틴은 팀 도입에서도 쓸 수 있나요. 쓸 수 있습니다. 다만 팀에서는 “누가 공개를 승인하는가”, “어떤 확인을 목표로 삼는가”를 먼저 문서화해 두면, 개인의 습관이 그대로 팀의 규칙이 됩니다.

실제로 시험해 본 결과

그 금요일 밤 이후, 저는 “AI에게 어디까지 맡길까”로 고민하는 걸 그만뒀습니다. 대신 매일 아침 정하는 건 오늘의 한 문장과, 확인 명령어 두 가지뿐입니다.

morning-check.mjs를 2주 동안 돌려 보고, 가장 달라진 건 확인 누락입니다. 전에는 빌드를 통과시킨 줄 알고 커밋했다가, 나중에 망가져 있던 적이 몇 번 있었습니다. 확인을 같은 순서로 기계에 흘리게 하고부터, 그게 0이 되었습니다.

그리고 매일 밤 남기는 4줄 메모. 이걸 시작하고 나서, 다음 날 아침의 “뭐 하려고 했더라”가 사라졌습니다. 똑똑한 사용법을 찾기보다, 작게 끝내고 확인을 남긴다. 수수하지만 초보자가 앞으로 나아가는 속도는 여기서 정해진다고 생각합니다.

우선 내일 아침, 한 문장만 정하고 확인 명령어를 하나 돌려 보세요. 계속하다 보면 자기만의 틀이 생기는데, 그때 교재 목록에서 의뢰 템플릿을 늘리면 매일의 손품이 더 줄어듭니다.