Photo by Chris Ried on Unsplash

기술 전문가가 아닌 창업자들에게 Claude Code에서 가장 활용도가 낮은 기능은 플랜 모드 (plan mode), CLAUDE.md 메모리 시스템, /rewind를 이용한 체크포인트 (checkpoints), 훅 (hooks), 커스텀 슬래시 명령어 (custom slash commands), 서브에이전트 (subagents), 자동 메모리 (auto memory), 그리고 /context 및 /compact를 이용한 컨텍스트 관리 (context management)입니다. 우리 대부분은 프롬프트 (prompt)를 입력하고, 엔터를 누른 뒤, 결과가 좋기를 바라며 학습합니다. 그것도 작동은 하지만, 도구의 대부분을 제대로 활용하지 못하게 만듭니다. 저는 이 기능들의 절반을 발견하기 전까지 몇 달 동안 Claude Code를 사용해 왔으며, 각 기능은 제가 AI 코딩의 대가라고 생각했던 특정한 답답함들을 해결해 주었습니다. 이 포스트에서는 이 8가지 기능 모두를 살펴봅니다 — 각 기능이 무엇을 하는지, 언제 사용해야 하는지, 그리고 제가 이 기능들의 존재를 알기 전에 저질렀던 실수들에 대해 다룹니다.

요약 (TL;DR)

• 플랜 모드 (plan mode)는 Claude가 파일에 손을 대기 전에 코드를 읽고 제안하도록 만듭니다 — 비개발자들에게 있어 신뢰성을 높여주는 가장 큰 업그레이드입니다.
• 200줄 미만의 CLAUDE.md는 매 세션마다 프로젝트를 다시 설명해야 하는 번거로움을 멈춰줍니다.
• 체크포인트 (Checkpoints) (/rewind 또는 Esc 두 번 누르기)는 사용자가 git을 이해할 필요 없이 Claude의 편집을 되돌려줍니다.
• 훅 (Hooks)은 코드로 규칙을 강제합니다; CLAUDE.md는 규칙을 제안할 뿐입니다.
• 이번 주에는 플랜 모드와 CLAUDE.md부터 시작하세요. 나머지는 구체적인 고충이 생길 때 추가하세요.

왜 플랜 모드 (plan mode)가 비개발자에게 그토록 중요한가요?

플랜 모드는 Claude가 코드를 읽고, 검색하고, 추론할 수는 있지만, 디스크에 쓰거나 무언가를 변경하는 명령어를 실행할 수는 없는 세션 상태입니다. Shift+Tab으로 전환할 수 있습니다. Claude는 탐색한 후 계획을 제시합니다. 어떤 일이 일어나기 전에 사용자가 이를 승인합니다.

만약 이 글에서 단 한 가지만 채택해야 한다면, 바로 이것입니다. 이것이 엔지니어보다 비기술직 창업자(non-tech founders)에게 더 중요한 이유는 다음과 같습니다. 엔지니어는 diff(차이점)를 읽고 사후에 잘못된 변경 사항을 잡아낼 수 있습니다. 우리 대부분은 그렇게 할 수 없거나, 적어도 확실하게 해내지는 못합니다. Plan mode(계획 모드)는 체크포인트를 변경이 일어나기 '전'으로 옮겨주며, 그 시점의 대화는 평이한 영어(plain English)로 이루어집니다. "처리를 하기 전에 서명을 확인하도록 webhook handler를 수정하고, 그 다음 테스트를 추가하겠습니다"라는 문장은 제가 평가할 수 있는 내용입니다. 하지만 400줄에 달하는 변경된 TypeScript 코드는 그렇지 못합니다.

저의 예전 워크플로우는 이랬습니다. 요청을 입력하고, 파일이 변하는 것을 지켜보다가, 불길한 예감이 들면, "잠깐, 왜 그걸 바꿨어?"라고 묻는 식이었습니다. 이미 디스크에 손상이 발생한 사후에 말이죠. Plan mode에서는 "잠깐, 왜?"라는 대화가 먼저 일어납니다. 저는 계획에 반대하고, Claude는 이를 수정하며, 그 후에야 우리는 실행에 옮깁니다.

제가 제안하는 습관은 다음과 같습니다. 결제(payments), 인증(auth), 또는 데이터베이스(database)를 건드리는 모든 작업에는 기본적으로 Plan mode를 사용하세요. 이 영역들은 확신 없는 잘못된 변경이 실제 돈이나 사용자의 신뢰를 잃게 만드는 곳입니다. 카피 편집이나 스타일링 같은 외관상의 변경(cosmetic changes)에는 일반 모드(normal mode)도 괜찮습니다. 저는 언제 AI 어시스턴트를 믿어야 하는가에서 이러한 판단 기준에 대해 더 자세히 썼지만, 요약하자면 Plan mode는 diff를 읽어서 얻을 수 없는 검증 시간을 벌어다 주는 방법입니다.

Plan mode는 작업의 품질 자체도 변화시킵니다. Claude가 행동하기 전에 코드베이스를 조사하도록 강제되면, 중복된 코드를 작성하는 대신 기존의 헬퍼 함수(helper function)를 찾아냅니다. 여러분의 코드베이스가 이미 사용하고 있는 패턴을 인지합니다. 먼저 행동하고 나중에 문맥(context)을 발견하는 방식은 AI가 구축한 코드베이스를 지저분하게 만드는 원인이 됩니다.

CLAUDE.md란 무엇이며 왜 가장 먼저 설정해야 할까요?

CLAUDE.md 파일은 Claude Code가 매 세션 시작 시 자동으로 읽는 지속적인 지침(persistent instructions)이 담긴 마크다운 (Markdown) 파일입니다. 이는 개발자가 아닌 사람들에게 AI 코딩의 가장 짜증 나는 점, 즉 매 세션이 0에서 시작되어 프로젝트의 구조(파일 위치, 실행해야 할 명령어, 건드리지 말아야 할 부분 등)를 계속해서 반복해서 설명해야 하는 문제를 해결해 줍니다.

공식 메모리 문서에 따르면, 파일이 길어지면 컨텍스트 (Context)를 소모하고 Claude의 준수 능력이 저하되기 때문에 200행 이내로 유지할 것을 권장합니다. 또한 문서에서는 어떤 내용을 포함해야 하는지에 대한 규칙을 제시하는데, 저는 실무에서 이 규칙이 매우 정확하다는 것을 발견했습니다. 즉, Claude가 같은 실수를 두 번째 저지르거나, 지난 세션에 입력했던 수정 사항을 이번 세션에서도 똑같이 입력하고 있는 자신을 발견했을 때 지침을 추가하십시오.

제 파일에는 다음과 같은 내용들이 포함되어 있습니다: 접근 금지 폴더(보일러플레이트의 /platform/ 영역), 새로운 라우트 (Route)를 생성하는 명령어, 그리고 모든 이메일은 하나의 중앙 헬퍼 (Helper)를 거쳐야 한다는 규칙 등입니다. 이 모든 줄은 Claude가 한 번 틀렸고, 저는 그것을 다시는 설명하고 싶지 않았기 때문에 존재합니다.

대부분의 사람들이 놓치는 세 가지 관련 기능:

/init은 첫 번째 초안을 작성합니다. 프로젝트에서 이 명령어를 실행하면 Claude가 코드베이스를 분석하여 발견된 빌드 명령어와 컨벤션 (Conventions)이 포함된 초기 CLAUDE.md를 생성합니다. 빈 파일을 멍하니 바라보는 대신, 여기서부터 내용을 다듬어 나가면 됩니다.

/memory는 실제로 무엇이 로드되었는지 보여줍니다. 현재 세션에서 로드된 모든 지침 파일을 나열합니다. Claude가 규칙을 무시할 때, 이것이 첫 번째 디버깅 (Debugging) 단계입니다. 절반 정도의 경우에는 파일이 생각한 위치에 있지 않아서 Claude가 파일을 아예 읽지 못한 것이 원인입니다.

.claude/rules/는 지침의 범위를 파일 경로로 제한합니다. paths 프론트매터 (Frontmatter) 필드가 있는 규칙 파일은 Claude가 일치하는 파일을 작업할 때만 로드됩니다. 예를 들어, 데이터베이스 컨벤션은 스키마 (Schema) 파일을 건드릴 때만 로드되고 그 외의 경우에는 방해되지 않습니다. 프로젝트가 커짐에 따라 메인 파일을 200행 이내로 유지할 수 있는 방법이 바로 이것입니다.

이 도구가 처음이라면, 저의 비개발자를 위한 Claude Code 가이드에서 설정 기초를 다루고 있습니다. 설치 후 제가 가장 먼저 추가하는 것은 CLAUDE.md입니다.

Auto memory (자동 메모리): Claude가 스스로 작성하는 노트

CLAUDE.md가 사용자가 작성하는 메모리라면, Auto memory (자동 메모리)는 Claude가 작성하는 메모리입니다. 그리고 대부분의 사용자는 이 과정이 일어나고 있다는 사실조차 모릅니다. Claude는 작업하면서 프로젝트에 관한 노트들을 사용자의 로컬 머신에 있는 메모리 디렉토리(memory directory)에 저장합니다. 스스로 알아낸 빌드 명령(build commands), 디버깅 통찰(debugging insights), 세션 도중 표현한 선호도 등이 여기에 해당합니다. 이 노트들은 향후 세션이 시작될 때 로드됩니다.

최근 버전(문서에 따르면 v2.1.59 이상)에서는 기본적으로 활성화되어 있습니다. 메모리 인덱스의 처음 200행이 모든 세션에 로드되며, Claude는 필요에 따라 상세한 주제 파일(topic files)을 가져옵니다.

알아두면 유용한 두 가지 실용적인 사항이 있습니다. 첫째, Claude에게 무언가를 기억하라고 말하기만 하면 됩니다. 예를 들어 "API 테스트에는 로컬 Redis 인스턴스가 필요하다는 것을 기억해 줘"라고 말하면, 파일을 직접 수정하지 않아도 자동 메모리에 저장됩니다. 비개발자에게 이것은 지속적인 컨텍스트(persistent context)를 구축하는 가장 마찰이 적은 방법입니다. Claude의 오류를 말로 한 번 바로잡아주면, 그것이 그대로 유지됩니다.

둘째, 모든 내용은 읽을 수 있는 일반 마크다운(markdown) 형식입니다. /memory 명령어를 실행하고 자동 메모리 폴더를 열어 Claude가 프로젝트에 대해 작성한 내용을 검토해 보세요. 저는 몇 주마다 제 메모리를 확인합니다. 대부분 정확하지만, 가끔 리팩터링(refactor) 과정에서 남은 오래된 노트가 있을 때가 있는데, 이를 삭제하는 데는 10초도 걸리지 않습니다. 메모리 폴더를 보이지 않는 블랙박스(black box)로 취급하기보다, 읽고 다듬을 수 있는 대상으로 다루는 것이 메모리가 도움을 주는 것과 메모리가 조용히 당신을 잘못된 방향으로 인도하는 것 사이의 차이를 만듭니다.

저에게 나타난 역할 분담은 다음과 같습니다. CLAUDE.md에는 팀 핸드북에 넣을 법한 규칙들을 담고, Auto memory에는 코드베이스에서 직접 작업해 본 사람만이 알 수 있는 축적된 현장 지식(street knowledge)을 담습니다.

Checkpoints (체크포인트)와 /rewind: 아무도 찾지 못하는 실행 취소 버튼

Claude Code는 각 편집을 수행하기 전에 자동으로 파일을 스냅샷(snapshot)으로 저장합니다. /rewind를 실행하거나 — 빈 프롬프트 상태에서 Esc 키를 두 번 누르면 — 세션 내의 모든 프롬프트 메뉴가 나타납니다. 하나를 선택하면 코드, 대화, 또는 둘 다를 해당 시점으로 복구할 수 있습니다.

저는 이것이 존재하는지 모른 채 몇 달을 보냈고, 그 기간 동안 "Claude가 상황을 더 악화시켰다"라는 상황에 대한 저의 복구 전략은 Claude에게 상황을 다시 되돌려달라고 요청하는 것이었습니다. 때로는 그것이 작동하기도 했습니다. 하지만 때로는 문제가 더 심각해지기도 했습니다. 잘못된 변경 사항을 수정하려는 시도가 또 다른 잘못된 변경을 불러왔고, 저는 지도도 없이 세 단계나 깊은 구덩이에 빠지게 되었습니다. 만약 여러분도 이런 악순환을 겪어보았다면, /rewind는 여러분이 놓치고 있었던 바로 그 기능입니다. 명령어 하나로 마지막의 정상적인 지점을 선택하여 안전하게 되돌아갈 수 있습니다.

체크포인트 문서에 따르면 제한 사항도 중요합니다. 체크포인트는 현재 세션에서 Claude가 자체 도구를 통해 편집한 파일만 추적합니다. 다른 에디터에서 직접 수정한 변경 사항은 포함되지 않으며, 이는 git을 대체하는 것이 아닙니다. 영구적인 히스토리를 위해서는 여전히 실제 커밋(commit)이 필요합니다. 저는 체크포인트를 세션 수준의 실행 취소(undo)로, git을 저장 파일(save file)로 생각합니다. 저의 실제 워크플로우는 이렇습니다: 작업 단위를 시작하기 전에 커밋을 하고(저는 실제로 Claude에게 커밋을 해달라고 요청합니다), 그 후 커밋이 단단한 바닥 역할을 한다는 것을 인지한 상태에서 세션 내에서 자유롭게 /rewind를 사용합니다.

또한 더 미묘한 용도도 있습니다. 되감기(rewind) 메뉴는 파일을 건드리지 않고 대화(conversation)만 이전 시점으로 복구하거나, 대화의 특정 구간을 요약할 수 있습니다. 세션이 길어져서 — 세 가지 접근 방식을 탐색한 후 코드는 그대로 유지한 채 결정 지점으로 돌아가고 싶을 때 — 바로 이 기능이 유용합니다. 이는 vibe coding 워크플로우와 잘 어울립니다. 탈출구가 존재하기 때문에 빠르게 움직일 수 있는 것입니다.

Hooks, 커스텀 명령(custom commands), 그리고 서브에이전트(subagents)

이 세 가지는 더 고급 기능이며, 저는 다음과 같은 순서로 사용하곤 합니다.

**커스텀 슬래시 명령어 (Custom slash commands)**는 .claude/commands/ 디렉토리에 마크다운 (markdown) 파일로 저장하여 사용하는 프롬프트 템플릿입니다. 예를 들어 .claude/commands/ship-check.md 파일이 있으면 세션에서 /ship-check로 사용할 수 있습니다. "보안 이슈를 검토하고, 입력 유효성 검사를 확인하며, 비밀 정보가 커밋되지 않았는지 확인해줘"와 같이 반복해서 입력하게 되는 모든 내용은 커스텀 명령어로 만들기에 적합합니다. 저는 반복되는 작업들을 위해 몇 가지 명령어를 유지하고 있으며, 이는 이전에 복사해서 붙여넣던 프롬프트 텍스트 파일을 대체했습니다. 만약 제가 작성한 비개발자를 위한 프롬프트 엔지니어링 (prompt engineering for non-developers) 포스트를 읽어보셨다면, 명령어란 여러분의 좋은 프롬프트들이 재사용 가능한 형태로 변모하는 곳이라는 점을 알 수 있을 것입니다.

**훅 (Hooks)**은 Claude의 라이프사이클(lifecycle) 중 특정 시점 — 도구가 실행되기 전, 파일 편집 후 등 — 에 자동으로 실행되는 쉘 스크립트 (shell scripts)입니다 (훅 레퍼런스 (hooks reference)). 문서에 명시된 핵심적인 차이점은 다음과 같습니다: CLAUDE.md 지침은 Claude가 따르려고 노력하는 컨텍스트 (context)인 반면, 훅은 Claude의 결정과 상관없이 실행됩니다. PreToolUse 훅은 보호된 폴더를 건드리는 모든 명령을 차단할 수 있습니다. 정중하게 요청하는 것이 아니라, 차단하는 것입니다. 만약 프로젝트 내에 "Claude가 보통은 잘 따르긴 하지만"으로는 충분하지 않은 규칙 — 예를 들어, 프로덕션 환경 설정 파일(production env file)은 절대 건드리지 말 것, 편집 후에는 항상 린터(linter)를 실행할 것 — 이 있다면, 그 규칙은 훅으로 만들어야 합니다. 훅을 작성하려면 작은 쉘 스크립트가 필요하며 이는 다소 위협적으로 들릴 수 있지만, 규칙을 설명하기만 하면 Claude가 직접 훅을 작성해 줄 것입니다. 이 점은 여전히 저를 미소 짓게 만듭니다.

**Subagents (하위 에이전트)**는 자신만의 컨텍스트 윈도우 (context window)를 가지고 작업을 처리한 뒤 결론만 보고하도록 생성된 별도의 Claude 세션입니다. 창업자에게 주는 실질적인 이점은 다음과 같습니다: 장황한 작업 내용이 메인 대화에 남지 않는다는 것입니다. Claude가 질문에 답하기 위해 40개의 파일을 검색할 때, 그 모든 파일 읽기 노이즈는 실제 작업에 쓰고 싶은 컨텍스트를 채워버립니다. 조사를 하위 에이전트에게 위임하면 메인 스레드를 깨끗하게 유지할 수 있으며, 이는 세션 성능이 저하되는 시점을 유의미하게 늦춰줍니다. 이 혜택을 누리기 위해 별도로 설정할 것은 없습니다. 그저 Claude에게 "X를 조사하기 위해 하위 에이전트를 사용해줘"라고 요청하기만 하면 됩니다.

어떤 기능이 어떤 문제를 해결하는가?

누군가 저에게 미리 건네주었으면 좋았을 지도입니다:

도구를 심화 학습하기보다 비교하고 있다면, 저의 Cursor vs Claude Code vs Cowork 비교 글에서 각 도구가 어디에 적합한지 다루고 있습니다. 하지만 이 글을 쓰며 얻은 솔직한 결론은 다음과 같습니다: 대부분의 사람들에게는 다른 도구가 필요한 것이 아닙니다. 그들이 가진 도구의 '뒷부분(second half)'이 필요할 뿐입니다.

자주 묻는 질문 (FAQ)

CLAUDE.md와 auto memory (자동 메모리)의 차이점은 무엇인가요?

CLAUDE.md는 사용자가 직접 작성하며 지침과 규칙을 담고 있습니다. 반면 auto memory는 Claude가 작성하며 사용자와 작업하며 습득한 학습 내용을 담습니다. 둘 다 매 세션 시작 시 로드됩니다. 지침(Instructions)은 기준을 설정하고, 메모리(Memory)는 컨텍스트를 축적합니다.

체크포인트(checkpoints)가 git을 대체하나요?