45가지 Claude Code 팁: 기초부터 고급까지

이 문서는 [> 이 문서는 moonkey48/claude-code-tips의 한글 번역본입니다. 훌륭한 팁들을 공유해주신 원작자님께 감사드립니다.

Claude Code를 최대한 활용하기 위한 팁 모음입니다. 커스텀 상태 표시줄 스크립트, 시스템 프롬프트 절반으로 줄이기, Gemini CLI를 Claude Code의 보조 도구로 사용하기, 컨테이너에서 Claude Code 실행하기 등을 다룹니다. dx 플러그인도 포함되어 있습니다.

📺 빠른 데모 - 멀티 Claude 워크플로우와 음성 입력을 활용한 팁 시연 영상:

목차

• Tip 0: 상태 표시줄 커스터마이징
• Tip 1: 필수 슬래시 명령어 익히기
• Tip 2: 음성으로 Claude Code와 대화하기
• Tip 3: 큰 문제를 작은 문제로 나누기
• Tip 4: Git과 GitHub CLI 프로처럼 사용하기
• Tip 5: AI 컨텍스트는 우유와 같다 - 신선하고 농축된 것이 최고!
• Tip 6: 터미널에서 출력 내용 가져오기
• Tip 7: 빠른 접근을 위한 터미널 별칭 설정
• Tip 8: 사전에 컨텍스트 압축하기
• Tip 9: 자율 작업을 위한 쓰기-테스트 주기 완성
• Tip 10: Cmd+A와 Ctrl+A는 당신의 친구
• Tip 11: 차단된 사이트의 대안으로 Gemini CLI 사용하기
• Tip 12: 자신만의 워크플로우에 투자하기
• Tip 13: 대화 기록 검색하기
• Tip 14: 터미널 탭으로 멀티태스킹
• Tip 15: 시스템 프롬프트 슬림화
• Tip 16: 병렬 브랜치 작업을 위한 Git worktree
• Tip 17: 장시간 작업을 위한 수동 지수 백오프
• Tip 18: Claude Code를 글쓰기 보조 도구로 활용
• Tip 19: 마크다운이 최고다
• Tip 20: Notion으로 링크 보존하며 붙여넣기
• Tip 21: 장시간 위험 작업을 위한 컨테이너
• Tip 22: Claude Code를 잘 쓰려면 많이 쓰는 것이 최고
• Tip 23: 대화 복제/포크와 반절 복제
• Tip 24: realpath로 절대 경로 얻기
• Tip 25: CLAUDE.md vs Skills vs 슬래시 명령어 vs 플러그인 이해하기
• Tip 26: 인터랙티브 PR 리뷰
• Tip 27: Claude Code를 리서치 도구로 활용
• Tip 28: 출력 검증 방법 마스터하기
• Tip 29: Claude Code를 DevOps 엔지니어로 활용
• Tip 30: CLAUDE.md를 간결하게 유지하고 주기적으로 검토하기
• Tip 31: 범용 인터페이스로서의 Claude Code
• Tip 32: 적절한 추상화 수준 선택이 핵심
• Tip 33: 승인된 명령어 감사하기
• Tip 34: 테스트를 많이 작성하기 (그리고 TDD 활용)
• Tip 35: 미지의 영역에서 더 대담해지기 - 반복적 문제 해결
• Tip 36: 백그라운드에서 bash 명령어와 서브에이전트 실행
• Tip 37: 개인화된 소프트웨어의 시대가 왔다
• Tip 38: 입력 상자 탐색 및 편집
• Tip 39: 계획에 시간을 투자하되, 프로토타입도 빠르게
• Tip 40: 과도하게 복잡한 코드 단순화하기
• Tip 41: 자동화의 자동화
• Tip 42: 지식을 공유하고 기여하기
• Tip 43: 계속 배우기!
• Tip 44: dx 플러그인 설치하기
• Tip 45: 빠른 설정 스크립트

Tip 0: 상태 표시줄 커스터마이징

Claude Code 하단의 상태 표시줄을 유용한 정보를 보여주도록 커스터마이징할 수 있습니다. 저는 모델명, 현재 디렉토리, git 브랜치(있는 경우), 커밋되지 않은 파일 수, origin과의 동기화 상태, 토큰 사용량 시각적 진행 바를 표시하도록 설정했습니다. 또한 마지막 메시지를 보여주는 두 번째 줄이 있어 대화 주제를 확인할 수 있습니다:

Opus 4.5 | 📁claude-code-tips | 🔀main (scripts/context-bar.sh uncommitted, synced 12m ago) | ██░░░░░░░░ 18% of 200k tokens
💬 This is good. I don't think we need to change the documentation as long as we don't say that the default color is orange el...

컨텍스트 사용량을 주시하고 작업 중인 내용을 기억하는 데 특히 유용합니다. 이 스크립트는 10가지 색상 테마(orange, blue, teal, green, lavender, rose, gold, slate, cyan, gray)를 지원합니다.

설정하려면 이 샘플 스크립트를 사용하고 설정 안내를 확인하세요.

Tip 1: 필수 슬래시 명령어 익히기

다양한 내장 슬래시 명령어가 있습니다 (/를 입력하면 전체 목록을 볼 수 있습니다). 알아두면 유용한 몇 가지를 소개합니다:

/usage

사용량 한도 확인:

 Current session
 █████████▌                                         19% used
 Resets 12:59am (America/Vancouver)

 Current week (all models)
 █████████████████████▌                             43% used
 Resets Feb 3 at 1:59pm (America/Vancouver)

 Current week (Sonnet only)
 ███████████████████▌                               39% used
 Resets 8:59am (America/Vancouver)

사용량을 면밀히 모니터링하려면 탭에 열어두고 Tab 후 Shift+Tab 또는 ← → 키로 새로고침하세요.

/chrome

Claude의 네이티브 브라우저 통합 토글:

> /chrome
Chrome integration enabled

/mcp

MCP (Model Context Protocol) 서버 관리:

 Manage MCP servers
 1 server

 ❯ 1. playwright  ✔ connected · Enter to view details

 MCP Config locations (by scope):
  • User config (available in all your projects):
    • /Users/yk/.claude.json

/stats

GitHub 스타일 활동 그래프로 사용 통계 확인:

      Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan
      ··········································▒█░▓░█░▓▒▒
  Mon ·········································▒▒██▓░█▓█░█
      ·········································░▒█▒▓░█▒█▒█
  Wed ········································░▓▒█▓▓░▒▓▒██
      ········································░▓░█▓▓▓▓█░▒█
  Fri ········································▒░░▓▒▒█▓▓▓█
      ········································▒▒░▓░░▓▒▒░░

      Less ░ ▒ ▓ █ More

  Favorite model: Opus 4.5        Total tokens: 17.6m

  Sessions: 4.1k                  Longest session: 20h 40m 45s
  Active days: 79/80              Longest streak: 75 days
  Most active day: Jan 26         Current streak: 74 days

  You've used ~24x more tokens than War and Peace

/clear

대화를 지우고 새로 시작합니다.

Tip 2: 음성으로 Claude Code와 대화하기

타이핑보다 음성으로 훨씬 빠르게 소통할 수 있다는 것을 발견했습니다. 로컬 머신에서 음성 전사 시스템을 사용하면 매우 유용합니다.

Mac에서 몇 가지 옵션을 사용해봤습니다:

• superwhisper
• MacWhisper
• Super Voice Assistant (오픈소스, Parakeet v2/v3 지원)

호스팅 서비스를 사용하면 더 높은 정확도를 얻을 수 있지만, 로컬 모델도 이 용도에는 충분히 강력합니다. 전사에 실수나 오타가 있어도 Claude는 의도를 이해할 만큼 똑똑합니다. 가끔 특정 단어를 더 명확히 말해야 할 때가 있지만, 전반적으로 로컬 모델도 충분히 잘 작동합니다.

예를 들어, 이 스크린샷에서 Claude가 "ExcelElanishMark"와 "advast"라는 잘못 전사된 단어를 "exclamation mark"와 "Advanced"로 올바르게 해석한 것을 볼 수 있습니다:

이것을 친구와 소통하는 것처럼 생각하면 좋습니다. 물론 문자로 소통할 수 있습니다. 어떤 사람들에게는 그게 더 편하거나, 이메일로 하는 것도 괜찮습니다. 대부분의 사람들이 Claude Code와 그렇게 소통합니다. 하지만 더 빠르게 소통하고 싶다면, 간단한 전화 통화를 하지 않을 이유가 있을까요? 음성 메시지를 보내면 됩니다. Claude Code와 실제로 전화할 필요는 없습니다. 음성 메시지를 보내기만 하면 됩니다. 적어도 지난 몇 년간 말하기를 많이 연습한 저에게는 더 빠릅니다. 하지만 대부분의 사람들에게도 더 빠를 거라고 생각합니다.

흔한 반론은 "다른 사람들이 있는 방에서는 어떻게 하나요?"입니다. 저는 이어폰을 사용해서 속삭입니다 - 개인적으로 Apple EarPods(AirPods 아님)를 좋아합니다. 합리적인 가격에 품질도 충분하고, 조용히 속삭이면 됩니다. 다른 사람들 앞에서 해봤는데 잘 작동합니다. 사무실에서는 어차피 사람들이 대화합니다 - 동료와 대화하는 대신 음성 전사 시스템에 조용히 말하는 것뿐입니다. 전혀 문제될 것이 없다고 생각합니다. 이 방법은 비행기에서도 작동할 정도로 효과적입니다. 다른 사람들이 들을 수 없을 만큼 조용하지만, 마이크에 충분히 가까이 말하면 로컬 모델이 여전히 이해할 수 있습니다. (사실 이 문단 자체를 비행 중에 그 방법으로 작성하고 있습니다.)

Tip 3: 큰 문제를 작은 문제로 나누기

이것은 마스터해야 할 가장 중요한 개념 중 하나입니다. 전통적인 소프트웨어 엔지니어링과 완전히 동일합니다 - 최고의 소프트웨어 엔지니어들은 이미 이 방법을 알고 있으며, Claude Code에도 적용됩니다.

Claude Code가 어려운 문제나 코딩 작업을 한 번에 해결하지 못한다면, 여러 개의 작은 이슈로 나눠달라고 요청하세요. 그 문제의 개별 부분을 해결할 수 있는지 확인하세요. 여전히 너무 어려우면 더 작은 하위 문제를 해결할 수 있는지 확인하세요. 모든 것이 해결 가능할 때까지 계속하세요.

본질적으로, A에서 B로 직접 가는 대신:

A에서 A1, A2, A3을 거쳐 B로 갈 수 있습니다:

좋은 예시로, 저만의 음성 전사 시스템을 만들 때의 경험이 있습니다. 사용자가 모델을 선택하고 다운로드할 수 있게 하고, 키보드 단축키를 받고, 전사를 시작하고, 전사된 텍스트를 사용자의 커서 위치에 넣고, 이 모든 것을 멋진 UI로 감싸는 시스템이 필요했습니다. 할 일이 많았죠. 그래서 작은 작업으로 나눴습니다. 먼저 모델만 다운로드하는 실행 파일을 만들었습니다. 그 다음 음성만 녹음하는 것을 만들었습니다. 그 다음 사전 녹음된 오디오만 전사하는 것을 만들었습니다. 하나씩 완성한 후 마지막에 결합했습니다.

이것과 밀접하게 관련된 것: 여러분의 문제 해결 능력과 소프트웨어 엔지니어링 기술은 에이전트 코딩과 Claude Code의 세계에서도 여전히 매우 중요합니다. Claude Code가 많은 문제를 스스로 해결할 수 있지만, 여러분의 일반적인 문제 해결 및 소프트웨어 엔지니어링 기술을 적용하면 훨씬 더 강력해집니다.

Tip 4: Git과 GitHub CLI 프로처럼 사용하기

Claude에게 Git과 GitHub CLI 작업을 맡기면 됩니다. 커밋(커밋 메시지를 수동으로 쓸 필요 없음), 브랜치, 풀, 푸시 등이 포함됩니다.

개인적으로 pull은 자동으로 허용하지만 push는 허용하지 않습니다. push가 더 위험하기 때문입니다 - pull에서 문제가 생겨도 origin을 오염시키지 않습니다.

GitHub CLI (gh)로 할 수 있는 것이 많습니다. Claude Code를 사용한 후 더 자주 하게 된 것 중 하나가 draft PR 만들기입니다. 이렇게 하면 Claude Code가 낮은 리스크로 PR 생성 과정을 처리할 수 있습니다 - 리뷰 준비 완료로 표시하기 전에 모든 것을 검토할 수 있습니다.

그리고 gh는 꽤 강력합니다. 임의의 GraphQL 쿼리도 보낼 수 있습니다. 예를 들어, GitHub PR 설명이 편집된 정확한 시간까지 찾을 수 있습니다:

⏺ Bash(gh api graphql -f query='
      query {
        repository(owner: "...", name: "...") {
          pullRequest(number: ...) {
            userContentEdits(first: 100) {
              nodes { editedAt editor { login } }
            }
          }
        }
      }')

⏺ PR 설명의 전체 편집 이력입니다:

  | #  | Edited At (UTC)     | Editor |
  |----|---------------------|--------|
  | 1  | 2025-12-01 00:08:34 | ykdojo |
  | 2  | 2025-12-01 15:57:21 | ykdojo |
  | 3  | 2025-12-01 16:24:33 | ykdojo |
  | 4  | 2025-12-01 16:27:00 | ykdojo |
  | 5  | 2025-12-04 00:40:02 | ykdojo |
  ...

커밋/PR 기여자 표시 비활성화

기본적으로 Claude Code는 커밋에 Co-Authored-By 트레일러를, PR에 기여자 표시 푸터를 추가합니다. ~/.claude/settings.json에 다음을 추가하면 둘 다 비활성화할 수 있습니다:

{
  "attribution": {
    "commit": "",
    "pr": ""
  }
}

둘 다 빈 문자열로 설정하면 기여자 표시가 완전히 제거됩니다. 이것은 현재 더 이상 사용되지 않는 이전의 includeCoAuthoredBy 설정을 대체합니다.

Tip 5: AI 컨텍스트는 우유와 같다 - 신선하고 농축된 것이 최고!

Claude Code와 새로운 대화를 시작하면, 이전 대화의 컨텍스트를 처리해야 하는 추가 복잡성이 없기 때문에 최고의 성능을 발휘합니다. 하지만 대화가 길어질수록 컨텍스트도 길어지고 성능이 떨어지는 경향이 있습니다.

따라서 새로운 주제마다 새 대화를 시작하거나, 성능이 떨어지기 시작하면 새로 시작하는 것이 가장 좋습니다.

Tip 6: 터미널에서 출력 내용 가져오기

가끔 Claude Code의 출력을 복사 붙여넣기하고 싶지만, 터미널에서 직접 복사하면 깔끔하지 않을 때가 있습니다. 콘텐츠를 더 쉽게 가져오는 몇 가지 방법이 있습니다:

• /copy 명령어: 가장 간단한 옵션 - /copy를 입력하면 Claude의 마지막 응답이 마크다운으로 클립보드에 복사됩니다
• 클립보드 직접 사용: Mac이나 Linux에서 Claude에게 pbcopy를 사용해 출력을 클립보드로 직접 보내달라고 요청하세요
• 파일로 작성: Claude가 콘텐츠를 파일에 넣은 다음 VS Code(또는 선호하는 편집기)에서 열어달라고 요청하면 거기서 복사할 수 있습니다. 줄 번호도 지정할 수 있어서, 방금 편집한 특정 줄을 열어달라고 요청할 수 있습니다. 마크다운 파일의 경우 VS Code에서 열린 후 Cmd+Shift+P (Linux/Windows에서는 Ctrl+Shift+P)를 누르고 "Markdown: Open Preview"를 선택하면 렌더링된 버전을 볼 수 있습니다
• URL 열기: 직접 확인하고 싶은 URL이 있으면 Claude에게 브라우저에서 열어달라고 요청하세요. Mac에서는 open 명령을 사용하도록 요청할 수 있지만, 일반적으로 선호하는 브라우저에서 열어달라고 요청하면 어떤 플랫폼에서든 작동합니다
• GitHub Desktop: Claude에게 현재 저장소를 GitHub Desktop에서 열어달라고 요청할 수 있습니다. 루트가 아닌 디렉토리에서 작업할 때 특히 유용합니다 - 예를 들어, 다른 디렉토리에 git worktree를 만들었는데 아직 거기서 Claude Code를 열지 않은 경우

이 방법들을 조합할 수도 있습니다. 예를 들어, GitHub PR 설명을 편집하고 싶을 때, Claude가 직접 편집하게 하면 (잘못할 수 있으므로) 대신 먼저 로컬 파일에 내용을 복사하게 할 수 있습니다. 그것을 편집하게 하고, 직접 결과를 확인한 후, 괜찮으면 GitHub PR에 다시 복사 붙여넣기하게 하면 됩니다. 이 방법이 매우 잘 작동합니다. 또는 직접 하고 싶다면 VS Code에서 열거나 pbcopy로 제공받아 수동으로 복사 붙여넣기할 수 있습니다.

물론 이 명령들을 직접 실행할 수도 있지만, 반복적으로 하게 된다면 Claude에게 맡기는 것이 유용합니다.

Tip 7: 빠른 접근을 위한 터미널 별칭 설정

Claude Code 덕분에 터미널을 더 많이 사용하게 되면서, 짧은 별칭을 설정해 빠르게 실행하는 것이 유용하다는 것을 알게 되었습니다. 제가 사용하는 별칭들입니다:

• c - Claude Code (가장 많이 사용)
• ch - Chrome 통합이 포함된 Claude Code
• gb - GitHub Desktop
• co - VS Code
• q - 대부분의 프로젝트가 있는 프로젝트 디렉토리로 이동. 거기서 개별 폴더로 cd하여 해당 프로젝트를 작업하거나, c로 Claude Code를 실행해 필요한 모든 프로젝트에 접근할 수 있습니다.

설정하려면 쉘 설정 파일(~/.zshrc 또는 ~/.bashrc)에 다음과 같은 줄을 추가하세요:

alias c='claude'
alias ch='claude --chrome'
alias gb='github'
alias co='code'
alias q='cd ~/Desktop/projects'

이 별칭들을 설정한 후 플래그와 조합할 수 있습니다: c -c는 마지막 대화를 이어가고, c -r은 이어갈 최근 대화 목록을 보여줍니다. ch에도 동일하게 작동합니다 (ch -c, ch -r).

Tip 8: 사전에 컨텍스트 압축하기

Claude Code에는 대화를 요약하여 컨텍스트 공간을 확보하는 /compact 명령어가 있습니다. 사용 가능한 전체 컨텍스트가 가득 차면 자동 압축도 발생합니다. Opus 4.5의 총 사용 가능한 컨텍스트 윈도우는 현재 200k이고, 그 중 45k가 자동 압축을 위해 예약되어 있습니다. 총 200k의 약 10%는 시스템 프롬프트, 도구, 메모리, 동적 컨텍스트로 자동 채워집니다. 하지만 사전에 수동으로 하는 것이 더 좋다는 것을 발견했습니다. /config로 auto-compact를 끄고 메인 대화에 더 많은 컨텍스트를 사용할 수 있게 하며, 압축 시점과 방법을 더 잘 제어합니다.

제가 하는 방법은 새로 시작하기 전에 Claude에게 인수인계 문서를 작성하도록 요청하는 것입니다. 예를 들면:

나머지 계획을 system-prompt-extraction 폴더에 HANDOFF.md로 넣어줘. 시도한 것, 작동한 것, 작동하지 않은 것을 설명해서 신선한 컨텍스트를 가진 다음 에이전트가 그 파일만 로드해도 이 작업을 시작하고 마무리할 수 있게 해줘.

Claude가 현재 작업 상태를 요약하는 파일을 생성합니다:

⏺ Write(experiments/system-prompt-extraction/HANDOFF.md)
  ⎿  Wrote 129 lines to experiments/system-prompt-extraction/HANDOFF.md
     # System Prompt Slimming - Handoff Document
     ## Goal
     Reduce Claude Code's system prompt by ~45% (currently at 11%, need ~34% more).
     ## Current Progress
     ### What's Been Done
     - **Backup/restore system**: `backup-cli.sh` and `restore-cli.sh` with SHA256 verification
     - **Patch system**: `patch-cli.js` that restores from backup then applies patches
     ...

Claude가 작성한 후 빠르게 검토하세요. 빠진 것이 있으면 수정을 요청하세요:

모든 것을 한꺼번에 하려고 하지 말고 반복적으로 테스트하는 것에 대한 메모를 추가했어?

그런 다음 새 대화를 시작하세요. 새 에이전트에게는 파일 경로만 주면 잘 작동합니다:

> experiments/system-prompt-extraction/HANDOFF.md

이후 대화에서는 에이전트에게 다음 에이전트를 위해 문서를 업데이트하도록 요청할 수 있습니다.

이 과정을 자동화하는 /handoff 슬래시 명령어도 만들었습니다 - 기존 HANDOFF.md가 있는지 확인하고, 있으면 읽은 다음, 목표, 진행 상황, 작동한 것, 작동하지 않은 것, 다음 단계를 포함하여 생성하거나 업데이트합니다. skills 폴더에서 찾을 수 있고, dx 플러그인을 통해 설치할 수도 있습니다.

대안: plan 모드 사용

또 다른 옵션은 plan 모드를 사용하는 것입니다. /plan 또는 Shift+Tab으로 진입합니다. Claude에게 관련 컨텍스트를 모두 수집하고 다음 에이전트를 위한 포괄적인 계획을 세우도록 요청하세요:

방금 plan 모드를 활성화했어. 다음 에이전트를 위해 필요한 모든 컨텍스트를 가져와. 다음 에이전트는 다른 컨텍스트가 없을 거라서 꽤 포괄적이어야 해.

Claude가 코드베이스를 탐색하고 컨텍스트를 수집하여 상세한 계획을 작성합니다. 완료되면 다음과 같은 옵션이 표시됩니다:

Would you like to proceed?

❯ 1. Yes, clear context and auto-accept edits (shift+tab)
  2. Yes, auto-accept edits
  3. Yes, manually approve edits
  4. Type here to tell Claude what to change

옵션 1은 이전 컨텍스트를 지우고 계획으로 새로 시작합니다. 새 Claude 인스턴스는 계획만 보게 되어 이전 대화의 부담 없이 집중할 수 있습니다. 특정 세부 사항을 찾아볼 필요가 있는 경우를 대비해 이전 대화 파일에 대한 링크도 제공됩니다.

Tip 9: 자율 작업을 위한 쓰기-테스트 주기 완성

Claude Code가 git bisect 같은 작업을 자율적으로 실행하려면 결과를 검증할 방법을 제공해야 합니다. 핵심은 쓰기-테스트 주기를 완성하는 것입니다: 코드를 작성하고, 실행하고, 출력을 확인하고, 반복합니다.

예를 들어, Claude Code 자체를 작업하는 중에 /compact가 작동을 멈추고 400 에러를 발생시키는 것을 발견했다고 합시다. 이 문제를 일으킨 정확한 커밋을 찾는 고전적인 도구가 git bisect입니다. Claude Code가 자신에 대해 bisect를 실행할 수 있다는 점이 좋지만, 각 커밋을 테스트할 방법이 필요합니다.

대화형 터미널을 포함하는 작업의 경우 tmux를 사용할 수 있습니다. 패턴은 다음과 같습니다:

1. tmux 세션 시작
2. 명령 전송
3. 출력 캡처
4. 예상과 일치하는지 확인

/context가 작동하는지 테스트하는 간단한 예시입니다:

tmux kill-session -t test-session 2>/dev/null
tmux new-session -d -s test-session
tmux send-keys -t test-session 'claude' Enter
sleep 2
tmux send-keys -t test-session '/context' Enter
sleep 1
tmux capture-pane -t test-session -p

이런 테스트가 있으면 Claude Code가 git bisect를 실행하고 문제를 일으킨 커밋을 찾을 때까지 각 커밋을 자동으로 테스트할 수 있습니다.

이것은 또한 소프트웨어 엔지니어링 기술이 왜 여전히 중요한지의 예시이기도 합니다. 소프트웨어 엔지니어라면 git bisect 같은 도구를 알고 있을 것입니다. 그 지식은 AI와 작업할 때도 여전히 매우 가치 있습니다 - 단지 새로운 방식으로 적용할 뿐입니다.

또 다른 예시는 단순히 테스트를 작성하는 것입니다. Claude Code가 코드를 작성한 후 테스트하고 싶다면, 테스트도 직접 작성하게 할 수 있습니다. 스스로 실행하고 문제를 수정하도록 놔두세요. 물론 항상 올바른 방향으로 가는 것은 아니고 가끔 감독이 필요하지만, 놀라울 정도로 많은 코딩 작업을 스스로 해낼 수 있습니다.

창의적 테스트 전략

때로는 쓰기-테스트 주기를 완성하는 방법에 창의적이어야 합니다. 예를 들어, 웹 앱을 만드는 경우 Playwright MCP, Chrome DevTools MCP, 또는 Claude의 네이티브 브라우저 통합(/chrome 사용)을 활용할 수 있습니다. Chrome DevTools는 아직 시도하지 않았지만 Playwright와 Claude의 네이티브 통합은 사용해봤습니다. 전반적으로 Playwright가 일반적으로 더 잘 작동합니다. 컨텍스트를 많이 사용하지만, 200k 컨텍스트 윈도우는 보통 하나의 작업이나 몇 개의 작은 작업에 충분합니다.

두 가지의 주요 차이점은 Playwright가 스크린샷을 찍는 것보다 접근성 트리(페이지 요소에 대한 구조화된 데이터)에 초점을 맞춘다는 것입니다. 스크린샷을 찍는 기능이 있지만 행동을 취하는 데 주로 사용하지 않습니다. 반면 Claude의 네이티브 브라우저 통합은 스크린샷을 찍고 특정 좌표로 요소를 클릭하는 데 더 초점을 맞춥니다. 랜덤한 것을 클릭할 수 있고, 전체 과정이 느릴 수 있습니다.

이것은 시간이 지남에 따라 개선될 수 있지만, 기본적으로 시각적으로 집약적이지 않은 대부분의 작업에는 Playwright를 사용하겠습니다. 로그인된 상태를 자격 증명을 제공하지 않고 사용해야 하는 경우(자신의 브라우저 프로필에서 실행되므로), 또는 좌표를 사용해 시각적으로 클릭해야 하는 경우에만 Claude의 네이티브 브라우저 통합을 사용합니다.

그래서 Claude의 네이티브 브라우저 통합을 기본적으로 비활성화하고 이전에 정의한 ch 단축키를 통해 사용합니다. 이렇게 하면 Playwright가 대부분의 브라우저 작업을 처리하고, 특별히 필요할 때만 Claude의 네이티브 통합을 활성화합니다.

추가로, 좌표 대신 접근성 트리 참조를 사용하도록 요청할 수 있습니다. CLAUDE.md에 다음과 같이 넣었습니다:

# Claude for Chrome

- Use `read_page` to get element refs from the accessibility tree
- Use `find` to locate elements by description
- Click/interact using `ref`, not coordinates
- NEVER take screenshots unless explicitly requested by the user

개인적인 경험으로, Python 라이브러리(Daft)를 작업하면서 로컬에서 빌드한 버전을 Google Colab에서 테스트해야 하는 상황이 있었습니다. 문제는 Rust 백엔드가 있는 Python 라이브러리를 Google Colab에서 빌드하기가 어렵다는 것입니다 - 잘 작동하지 않는 것 같았습니다. 그래서 실제로 로컬에서 wheel을 빌드한 다음 수동으로 업로드해야 Google Colab에서 실행할 수 있었습니다. 전체 wheel이 로컬에서 빌드되기를 기다리기 전에 단기적으로 잘 작동하는 monkey patching도 시도했습니다. Claude Code와 왔다 갔다 하면서 이러한 테스트 전략을 생각해내고 실행했습니다.

또 다른 상황은 Windows에서 테스트해야 했지만 Windows 머신을 사용하지 않는 경우였습니다. 같은 저장소의 CI 테스트가 Windows에서 Rust 관련 문제로 실패하고 있었고, 로컬에서 테스트할 방법이 없었습니다. 그래서 모든 변경사항이 포함된 draft PR을 만들고, 동일한 변경사항에 non-main 브랜치에서의 Windows CI 실행을 활성화한 또 다른 draft PR을 만들어야 했습니다. Claude Code에게 이 모든 것을 하도록 지시했고, 그 새 브랜치에서 CI를 직접 테스트했습니다.

Tip 10: Cmd+A와 Ctrl+A는 당신의 친구

몇 년 전부터 말해왔습니다: AI 시대에 Cmd+A와 Ctrl+A는 좋은 친구입니다. Claude Code에도 마찬가지입니다.

가끔 Claude Code에 URL을 주고 싶지만 직접 접근할 수 없을 때가 있습니다. 비공개 페이지(민감한 데이터가 아닌, 공개적으로 접근할 수 없는 것)일 수도 있고, Reddit 게시물처럼 Claude Code가 가져오기 어려운 것일 수도 있습니다. 이런 경우 보이는 모든 콘텐츠를 선택해서 (Mac에서는 Cmd+A, 다른 플랫폼에서는 Ctrl+A), 복사해서 Claude Code에 직접 붙여넣으면 됩니다. 꽤 강력한 방법입니다.

터미널 출력에도 잘 작동합니다. Claude Code 자체나 다른 CLI 애플리케이션의 출력이 있을 때 같은 방법을 사용할 수 있습니다: 전체 선택, 복사, CC에 붙여넣기. 꽤 유용합니다.

일부 페이지는 기본적으로 전체 선택이 잘 되지 않지만 - 먼저 더 나은 상태로 만드는 방법이 있습니다. 예를 들어, Gmail 스레드의 경우 Print All을 클릭해 인쇄 미리보기를 표시합니다 (실제 인쇄는 취소). 해당 페이지에서는 스레드의 모든 이메일이 확장되어 있어 전체 대화를 깔끔하게 Cmd+A로 선택할 수 있습니다.

이것은 Claude Code뿐만 아니라 모든 AI에 적용됩니다.

Tip 11: 차단된 사이트의 대안으로 Gemini CLI 사용하기

Claude Code의 WebFetch 도구는 Reddit 같은 특정 사이트에 접근할 수 없습니다. 하지만 Claude에게 Gemini CLI를 대안으로 사용하도록 하는 skill을 만들어 이를 우회할 수 있습니다. Gemini는 웹 접근이 가능하여 Claude가 직접 접근할 수 없는 사이트의 콘텐츠를 가져올 수 있습니다.

이것은 Tip 9의 동일한 tmux 패턴을 사용합니다 - 세션을 시작하고, 명령을 보내고, 출력을 캡처합니다. skill 파일은 ~/.claude/skills/reddit-fetch/SKILL.md에 위치합니다. 전체 내용은 skills/reddit-fetch/SKILL.md를 참조하세요.

Skills은 Claude Code가 필요할 때만 로드하기 때문에 더 토큰 효율적입니다. 더 간단한 것을 원한다면 ~/.claude/CLAUDE.md에 축약된 버전을 넣을 수도 있지만, 그것은 필요 여부에 상관없이 모든 대화에 로드됩니다.

Reddit에서 Claude Code skills이 어떻게 평가되는지 Claude Code에게 확인하도록 요청해서 테스트했습니다 - 좀 메타적이죠. Gemini와 한동안 왔다 갔다 하므로 빠르지는 않지만, 보고서 품질은 놀라울 정도로 좋았습니다. 당연히 이것이 작동하려면 Gemini CLI가 설치되어 있어야 합니다. 이 skill은 dx 플러그인을 통해서도 설치할 수 있습니다.

Tip 12: 자신만의 워크플로우에 투자하기

개인적으로, Swift로 처음부터 음성 전사 앱을 만들었습니다. Claude Code를 사용해 bash로 처음부터 커스텀 상태 표시줄을 만들었습니다. 그리고 Claude Code의 최소화된 JavaScript 파일에서 시스템 프롬프트를 단순화하는 시스템도 만들었습니다.

하지만 그렇게까지 할 필요는 없습니다. 자신의 CLAUDE.md를 관리하고 목표 달성에 도움이 되도록 최대한 간결하게 유지하는 것 - 그런 것이 유용합니다. 그리고 물론, 이런 팁들을 배우고, 도구를 배우고, 가장 중요한 기능들을 배우는 것도요.

이 모든 것은 원하는 것을 만들기 위해 사용하는 도구에 대한 투자입니다. 적어도 약간의 시간을 그것에 투자하는 것이 중요하다고 생각합니다.

Tip 13: 대화 기록 검색하기

Claude Code에게 과거 대화에 대해 물어볼 수 있고, 검색을 도와줄 것입니다. 대화 기록은 ~/.claude/projects/에 로컬로 저장되며, 폴더 이름은 프로젝트 경로를 기반으로 합니다 (슬래시가 대시로 변환).

예를 들어, /Users/yk/Desktop/projects/claude-code-tips 프로젝트의 대화는 다음 위치에 저장됩니다:

~/.claude/projects/-Users-yk-Desktop-projects-claude-code-tips/

각 대화는 .jsonl 파일입니다. 기본 bash 명령으로 검색할 수 있습니다:

# "Reddit"이 언급된 모든 대화 찾기
grep -l -i "reddit" ~/.claude/projects/-Users-yk-Desktop-projects-*/*.jsonl

# 특정 주제에 대한 오늘의 대화 찾기
find ~/.claude/projects/-Users-yk-Desktop-projects-*/*.jsonl -mtime 0 -exec grep -l -i "keyword" {} \;

# 대화에서 사용자 메시지만 추출 (jq 필요)
cat ~/.claude/projects/.../conversation-id.jsonl | jq -r 'select(.type=="user") | .message.content'

또는 Claude Code에 직접 물어보면 됩니다: "오늘 X에 대해 뭐 이야기했어?" 하면 기록을 검색해줍니다.

Tip 14: 터미널 탭으로 멀티태스킹

여러 Claude Code 인스턴스를 실행할 때, Git worktree 같은 특정 기술 설정보다 정리 정돈이 더 중요합니다. 한 번에 최대 3~4개의 작업에 집중하는 것을 권장합니다.

제 개인적인 방법은 "캐스케이드"라고 부르는 것입니다 - 새 작업을 시작할 때마다 오른쪽에 새 탭을 엽니다. 그런 다음 왼쪽에서 오른쪽으로, 왼쪽에서 오른쪽으로 훑어보며 오래된 작업에서 새로운 작업으로 이동합니다. 특정 작업을 확인하거나 알림을 받을 때를 제외하면 일반적인 방향은 일관됩니다.

제 설정은 보통 이렇게 생겼습니다:

이 예시에서:

1. 맨 왼쪽 탭 - 음성 전사 시스템을 실행하는 영구 탭 (항상 여기에 있음)
2. 두 번째 탭 - Docker 컨테이너 설정
3. 세 번째 탭 - 로컬 머신의 디스크 사용량 확인
4. 네 번째 탭 - 엔지니어링 프로젝트 작업
5. 다섯 번째 탭 (현재) - 바로 이 팁을 작성 중

Tip 15: 시스템 프롬프트 슬림화

Claude Code의 시스템 프롬프트와 도구 정의는 작업을 시작하기도 전에 약 19k 토큰(200k 컨텍스트의 ~10%)을 차지합니다. 이를 약 9k 토큰으로 줄이는 패치 시스템을 만들었습니다 - 약 10,000 토큰(오버헤드의 ~50%) 절약입니다.

구성 요소	패치 전	패치 후	절약량
시스템 프롬프트	3.0k	1.8k	1,200 토큰
시스템 도구	15.6k	7.4k	8,200 토큰
합계	~19k	~9k	~10k 토큰 (~50%)

패치 전후의 /context 모습입니다:

패치 전 (~20k, 10%)

패치 후 (~10k, 5%)

패치는 핵심 지침을 유지하면서 최소화된 CLI 번들에서 장황한 예시와 중복 텍스트를 제거하는 방식으로 작동합니다.

이것을 광범위하게 테스트했고 잘 작동합니다. 더 날것 같은 느낌입니다 - 더 강력하지만 약간 덜 규제된 느낌인데, 시스템 지침이 더 짧으니 당연합니다. 이 방식으로 사용하면 더 프로 도구 같은 느낌이 듭니다. 낮은 컨텍스트로 시작하면 가득 차기 전에 더 많은 여유가 있어서 대화를 좀 더 길게 이어갈 수 있다는 것이 정말 좋습니다. 이것이 이 전략의 가장 좋은 부분입니다.

패치 스크립트와 제거되는 내용의 전체 세부 사항은 system-prompt 폴더를 확인하세요.

왜 패치인가? Claude Code에는 파일에서 간소화된 시스템 프롬프트를 제공할 수 있는 플래그(--system-prompt 또는 --system-prompt-file)가 있어서, 그것도 대안입니다. 하지만 도구 설명에 대해서는 커스터마이징할 공식 옵션이 없습니다. CLI 번들을 패치하는 것이 유일한 방법입니다. 제 패치 시스템이 하나의 통합된 접근 방식으로 모든 것을 처리하므로, 지금은 이 방식을 유지하고 있습니다. 향후 플래그를 사용해 시스템 프롬프트 부분을 다시 구현할 수도 있습니다.

지원되는 설치 방식: npm 및 네이티브 바이너리 (macOS, Linux).

중요: 패치된 시스템 프롬프트를 유지하려면 ~/.claude/settings.json에 다음을 추가하여 자동 업데이트를 비활성화하세요:

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

이것은 쉘 유형(대화형, 비대화형, tmux)에 관계없이 모든 Claude Code 세션에 적용됩니다. 새 버전에 패치를 다시 적용할 준비가 되면 수동으로 업데이트할 수 있습니다.

MCP 도구 지연 로딩

MCP 서버를 사용하는 경우, 도구 정의가 기본적으로 모든 대화에 로드됩니다 - 사용하지 않더라도요. 이는 특히 여러 서버가 구성된 경우 상당한 오버헤드를 추가할 수 있습니다.

지연 로딩을 활성화하면 MCP 도구가 필요할 때만 로드됩니다:

{
  "env": {
    "ENABLE_TOOL_SEARCH": "true"
  }
}

이것을 ~/.claude/settings.json에 추가하세요. Claude가 처음부터 모든 MCP 도구를 로드하는 대신 필요에 따라 검색하고 로드합니다. 버전 2.1.7부터는 MCP 도구 설명이 컨텍스트 윈도우의 10%를 초과하면 자동으로 이루어집니다.

Tip 16: 병렬 브랜치 작업을 위한 Git worktree

같은 프로젝트에서 여러 작업을 동시에 하면서 충돌을 피하고 싶다면, Git worktree가 좋은 방법입니다. Claude Code에게 git worktree를 만들고 거기서 작업을 시작하라고 요청하면 됩니다 - 구체적인 구문을 걱정할 필요가 없습니다.

기본 개념은 다른 디렉토리에서 다른 브랜치로 작업할 수 있다는 것입니다. 본질적으로 브랜치 + 디렉토리입니다.

멀티태스킹 팁에서 논의한 캐스케이드 방법 위에 Git worktree 레이어를 추가할 수 있습니다.

Git worktree란?

Git worktree는 일반 git 브랜치와 같지만, 새로운 디렉토리가 특별히 할당됩니다.

예를 들어, main 브랜치와 feature-branch-1에서 작업하고 있다면, git worktree 없이는 프로젝트 폴더가 한 번에 하나의 브랜치에만 설정될 수 있으므로 하나씩만 작업할 수 있습니다.

하지만 git worktree가 있으면 원래 프로젝트 폴더에서 main 브랜치(또는 다른 브랜치)로 작업을 계속하면서, 동시에 새 폴더에서 feature-branch-1으로 작업할 수 있습니다.

Tip 17: 장시간 작업을 위한 수동 지수 백오프

Docker 빌드나 GitHub CI 같은 장시간 작업을 기다릴 때, Claude Code에게 수동 지수 백오프를 요청할 수 있습니다. 지수 백오프는 소프트웨어 엔지니어링에서 흔한 기법인데, 여기서도 적용할 수 있습니다. Claude Code에게 증가하는 대기 간격으로 상태를 확인하도록 요청하세요 - 1분, 2분, 4분, 이런 식으로요. 전통적인 의미에서 프로그래밍적으로 하는 것은 아니지만 - AI가 수동으로 하는 것이지만 꽤 잘 작동합니다.

이렇게 하면 에이전트가 지속적으로 상태를 확인하고 완료되면 알려줄 수 있습니다.

(GitHub CI의 경우 gh run watch가 있지만 많은 줄을 지속적으로 출력하여 토큰을 낭비합니다. gh run view <run-id> | grep <job-name>을 사용한 수동 지수 백오프가 실제로 더 토큰 효율적입니다. 이것은 전용 대기 명령이 없을 때도 잘 작동하는 일반적인 기법이기도 합니다.)

예를 들어, 백그라운드에서 Docker 빌드가 실행 중인 경우:

작업이 완료될 때까지 계속됩니다.

Tip 18: Claude Code를 글쓰기 보조 도구로 활용

Claude Code는 훌륭한 글쓰기 보조 도구이자 파트너입니다. 글쓰기에 사용하는 방법은 먼저 쓰려는 내용에 대한 모든 컨텍스트를 제공하고, 그 다음 음성으로 상세한 지시를 하는 것입니다. 그러면 첫 번째 초안이 나옵니다. 충분하지 않으면 몇 번 더 시도합니다.

그런 다음 거의 줄 단위로 검토합니다. "좋아, 같이 살펴보자. 이 줄은 이런 이유로 좋아. 이 줄은 저쪽으로 옮겨야 할 것 같아. 이 줄은 이런 방식으로 변경해야 해." 참고 자료에 대해서도 물어볼 수 있습니다.

이런 식의 왔다 갔다 하는 과정, 왼쪽에 터미널이 오른쪽에 코드 편집기가 있는 식으로:

이것이 매우 잘 작동하는 경향이 있습니다.

Tip 19: 마크다운이 최고다

보통 사람들이 새 문서를 작성할 때 Google Docs나 Notion 같은 것을 사용할 수 있습니다. 하지만 이제 솔직히 가장 효율적인 방법은 마크다운이라고 생각합니다.

마크다운은 AI 이전에도 꽤 좋았지만, 특히 Claude Code와 함께 사용하면, 앞서 글쓰기에 대해 언급한 것처럼 매우 효율적이기 때문에, 마크다운의 가치가 더 높아진다고 생각합니다. 블로그 게시물이나 LinkedIn 게시물을 쓸 때마다 Claude Code와 대화하고, 마크다운으로 저장하고, 거기서 시작하면 됩니다.

이것에 대한 빠른 팁: 마크다운 콘텐츠를 쉽게 받지 않는 플랫폼에 복사 붙여넣기하려면, 먼저 새 Notion 파일에 붙여넣은 다음 Notion에서 다른 플랫폼으로 복사할 수 있습니다. Notion이 다른 플랫폼이 받아들일 수 있는 형식으로 변환합니다. 일반 붙여넣기가 안 되면 Command + Shift + V로 서식 없이 붙여넣기를 시도해보세요.

Tip 20: Notion으로 링크 보존하며 붙여넣기

반대 방향도 작동합니다. 다른 곳에서, 예를 들어 Slack에서 링크가 있는 텍스트를 복사해서 Claude Code에 직접 붙여넣으면 링크가 표시되지 않습니다. 하지만 먼저 Notion 문서에 넣은 다음 거기서 복사하면 마크다운으로 얻을 수 있고, 당연히 Claude Code가 읽을 수 있습니다.

Tip 21: 장시간 위험 작업을 위한 컨테이너

일반 세션은 권한을 제어하고 출력을 더 신중하게 검토하는 체계적인 작업에 적합합니다. 컨테이너 환경은 일일이 권한을 부여할 필요 없는 --dangerously-skip-permissions 세션에 적합합니다. 한동안 자체적으로 실행하도록 둘 수 있습니다.

이것은 시간이 오래 걸리고 위험할 수 있는 리서치나 실험에 유용합니다. Tip 11의 Reddit 리서치 워크플로우가 좋은 예시인데, reddit-fetch skill이 tmux를 통해 Gemini CLI와 왔다 갔다 합니다. 이것을 메인 시스템에서 감독 없이 실행하는 것은 위험하지만, 컨테이너에서는 문제가 생겨도 격리됩니다.

또 다른 예시는 이 저장소의 시스템 프롬프트 패치 스크립트를 만든 방법입니다. Claude Code의 새 버전이 나올 때 최소화된 CLI 번들의 패치를 업데이트해야 합니다. 호스트 머신에서 (모든 것에 접근할 수 있는) --dangerously-skip-permissions로 Claude Code를 실행하는 대신 컨테이너에서 실행합니다. Claude Code가 최소화된 JavaScript를 탐색하고 변수 매핑을 찾아 새 패치 파일을 만들 수 있으며, 일일이 모든 것을 승인할 필요가 없습니다.

사실, 마이그레이션을 거의 혼자서 완료할 수 있었습니다. 패치를 적용하고, 새 버전에서 작동하지 않는 것을 발견하고, 반복적으로 수정했고, 심지어 학습한 것을 기반으로 미래 인스턴스를 위한 안내 문서를 개선하기도 했습니다.

컨테이너화된 Claude Code 세션을 쉽게 실행할 수 있도록 SafeClaw를 만들기도 했습니다. 웹 터미널이 있는 여러 격리된 세션을 띄우고 대시보드에서 모두 관리할 수 있습니다. 최적화된 시스템 프롬프트, DX 플러그인, 상태 표시줄 등 이 저장소의 여러 커스터마이징을 사용합니다.

고급: 컨테이너에서 워커 Claude Code 오케스트레이션

로컬 Claude Code가 컨테이너 내부에서 실행되는 다른 Claude Code 인스턴스를 제어하도록 더 발전시킬 수 있습니다. 핵심은 tmux를 제어 레이어로 사용하는 것입니다:

1. 로컬 Claude Code가 tmux 세션을 시작
2. 해당 tmux 세션에서 컨테이너에 연결하거나 실행
3. 컨테이너 내부에서 Claude Code가 --dangerously-skip-permissions로 실행
4. 외부 Claude Code가 tmux send-keys로 프롬프트를 보내고 capture-pane으로 출력을 읽음

이렇게 하면 모든 작업을 승인하지 않고도 실험적이거나 장시간 작업을 실행할 수 있는 완전 자율 "워커" Claude Code를 갖게 됩니다. 완료되면 로컬 Claude Code가 결과를 가져올 수 있습니다. 문제가 발생하면 모두 컨테이너 안에 격리되어 있습니다.

고급: 멀티 모델 오케스트레이션

Claude Code 외에도 Codex, Gemini CLI 등 다양한 AI CLI를 컨테이너에서 실행할 수 있습니다. 코드 리뷰용으로 OpenAI Codex를 시도해봤는데 잘 작동합니다. 요점은 이런 CLI를 호스트 머신에서 직접 실행할 수 없다는 것이 아닙니다 - 당연히 가능합니다. 가치는 Claude Code의 UI/UX가 충분히 매끄러워서 그냥 대화하면 오케스트레이션을 처리한다는 것입니다: 다른 모델을 띄우고, 컨테이너와 호스트 사이에 데이터를 보내는 것을요. 터미널 간에 수동으로 전환하고 복사 붙여넣기하는 대신, Claude Code가 모든 것을 조율하는 중앙 인터페이스가 됩니다.

Tip 22: Claude Code를 잘 쓰려면 많이 쓰는 것이 최고

최근에 세계적인 암벽 등반가가 다른 등반가에게 인터뷰하는 것을 봤습니다. "암벽 등반을 더 잘하려면 어떻게 해야 하나요?"라는 질문에 그녀는 간단히 "암벽 등반을 하면 됩니다"라고 답했습니다.

저도 같은 느낌입니다. 물론 영상 보기, 책 읽기, 팁 배우기 같은 보충적인 것들을 할 수 있습니다. 하지만 Claude Code를 사용하는 것이 사용법을 배우는 가장 좋은 방법입니다. AI를 사용하는 것이 AI 사용법을 배우는 가장 좋은 방법입니다.

10,000시간 법칙 대신 10억 토큰 법칙이라고 생각하면 좋겠습니다. AI를 더 잘 활용하고 작동 방식에 대한 직관을 제대로 얻으려면, 가장 좋은 방법은 많은 토큰을 소비하는 것입니다. 요즘은 가능합니다. 특히 Opus 4.5의 경우, 충분히 강력하면서도 합리적인 가격이어서 여러 세션을 동시에 실행할 수 있습니다. 토큰 사용량에 대해 너무 걱정하지 않아도 되어 훨씬 자유롭습니다.

Tip 23: 대화 복제/포크와 반절 복제

가끔 원래 스레드를 잃지 않으면서 대화의 특정 지점에서 다른 접근 방식을 시도하고 싶을 때가 있습니다. clone-conversation 스크립트는 새 UUID로 대화를 복제하여 분기할 수 있게 합니다.

내장 대안 (최신 버전): Claude Code에는 이제 네이티브 포킹이 있습니다:

• /fork - 대화 내에서 현재 세션을 포크
• --fork-session - --resume 또는 --continue와 함께 사용 (예: claude -c --fork-session)

--fork-session에는 축약형이 없으므로, ~/.zshrc 또는 ~/.bashrc에 이 함수를 추가하면 --fs를 단축키로 사용할 수 있습니다:

claude() {
  local args=()
  for arg in "$@"; do
    if [[ "$arg" == "--fs" ]]; then
      args+=("--fork-session")
    else
      args+=("$arg")
    fi
  done
  command claude "${args[@]}"
}

이것은 모든 claude 명령을 가로채서 --fs를 --fork-session으로 확장하고 나머지는 그대로 전달합니다. 별칭과도 함께 작동합니다 (Tip 7 참조): c -c --fs, ch -c --fs 등.

아래의 clone 스크립트는 이러한 내장 옵션보다 먼저 만들어졌지만, 그 아래의 half-clone 스크립트는 컨텍스트를 줄이는 고유한 기능으로 남아 있습니다.

첫 번째 메시지에는 [CLONED <timestamp>] (예: [CLONED Jan 7 14:30])가 태그되어 claude -r 목록과 대화 내부에 모두 표시됩니다.

수동으로 설정하려면 두 파일을 심볼릭 링크하세요:

ln -s /path/to/this/repo/scripts/clone-conversation.sh ~/.claude/scripts/clone-conversation.sh
ln -s /path/to/this/repo/skills/clone ~/.claude/skills/clone

또는 dx 플러그인을 통해 설치하면 심볼릭 링크가 필요 없습니다.

아무 대화에서 /clone (플러그인 사용 시 /dx:clone)을 입력하면 Claude가 세션 ID를 찾아 스크립트를 실행합니다.

이것을 광범위하게 테스트했고 복제가 매우 잘 작동합니다.

컨텍스트 줄이기를 위한 반절 복제

대화가 너무 길어지면 half-clone-conversation 스크립트가 후반부만 유지합니다. 이렇게 하면 최근 작업을 보존하면서 토큰 사용량을 줄입니다. 첫 번째 메시지에는 [HALF-CLONE <timestamp>] (예: [HALF-CLONE Jan 7 14:30])가 태그됩니다.

수동으로 설정하려면 두 파일을 심볼릭 링크하세요:

ln -s /path/to/this/repo/scripts/half-clone-conversation.sh ~/.claude/scripts/half-clone-conversation.sh
ln -s /path/to/this/repo/skills/half-clone ~/.claude/skills/half-clone

또는 dx 플러그인을 통해 설치하면 심볼릭 링크가 필요 없습니다.

hook으로 반절 복제 자동 제안

선택적으로, 컨텍스트가 너무 길어지면 자동으로 /half-clone을 트리거하는 hook을 사용할 수 있습니다. check-context 스크립트는 Claude의 모든 응답 후에 실행되어 컨텍스트 사용량을 확인합니다. 85%를 초과하면 Claude에게 /half-clone을 실행하라고 알려주고, 새 에이전트가 거기서 이어갈 수 있도록 후반부만 있는 새 대화를 만듭니다.

설정하려면 먼저 스크립트를 복사하세요:

cp /path/to/this/repo/scripts/check-context.sh ~/.claude/scripts/check-context.sh
chmod +x ~/.claude/scripts/check-context.sh

그런 다음 ~/.claude/settings.json에 hook을 추가하세요:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/scripts/check-context.sh"
          }
        ]
      }
    ]
  }
}

이것은 auto-compact가 비활성화되어야 합니다 (/config > Auto-compact > false), 그렇지 않으면 Claude Code가 hook이 발동하기 전에 컨텍스트를 압축할 수 있습니다. 트리거되면 hook이 Claude의 중지를 차단하고 /half-clone을 실행하라고 합니다. auto-compact 대비 장점은 half-clone이 결정적이고 빠르다는 것입니다 - 요약하는 대신 실제 메시지를 그대로 유지합니다.

clone 스크립트에 대한 권장 권한

두 clone 스크립트 모두 ~/.claude(대화 파일 및 기록용)를 읽어야 합니다. 어떤 프로젝트에서든 권한 프롬프트를 피하려면 전역 설정(~/.claude/settings.json)에 다음을 추가하세요:

{
  "permissions": {
    "allow": ["Read(~/.claude)"]
  }
}

Tip 24: realpath로 절대 경로 얻기

다른 폴더의 파일에 대해 Claude Code에게 알려줘야 할 때, realpath를 사용해 전체 절대 경로를 얻으세요:

realpath some/relative/path

Tip 25: CLAUDE.md vs Skills vs 슬래시 명령어 vs 플러그인 이해하기

이것들은 다소 비슷한 기능이고 처음에는 꽤 혼란스러웠습니다. 이해하려고 노력하면서 배운 것을 공유하고 싶었습니다.

CLAUDE.md는 가장 간단합니다. 기본 프롬프트로 취급되어 모든 대화의 시작 부분에 무조건 로드되는 파일들입니다. 장점은 단순함입니다. 특정 프로젝트(./CLAUDE.md)나 전역적으로(~/.claude/CLAUDE.md) 프로젝트가 무엇에 관한 것인지 설명할 수 있습니다.

Skills는 더 잘 구조화된 CLAUDE.md 파일과 같습니다. 관련될 때 Claude가 자동으로 호출하거나, 사용자가 슬래시(예: /my-skill)로 수동 호출할 수 있습니다. 예를 들어, 특정 언어의 단어 발음을 물어볼 때 적절한 형식의 Google Translate 링크를 여는 skill이 있을 수 있습니다. 해당 지침이 skill에 있으면 필요할 때만 로드됩니다. CLAUDE.md에 있으면 이미 거기서 공간을 차지하고 있을 것입니다. 그래서 skills이 이론적으로 더 토큰 효율적입니다.

슬래시 명령어는 지침을 별도로 패키징하는 방식이라는 점에서 skills과 유사합니다. 사용자가 수동으로 호출하거나 Claude가 직접 호출할 수 있습니다. 더 정확한 것이 필요하고 자신만의 속도로 적절한 시점에 호출하려면 슬래시 명령어가 적합한 도구입니다.

Skills과 슬래시 명령어는 기능 방식이 꽤 비슷합니다. 차이점은 설계 의도입니다 - skills는 주로 Claude가 사용하도록 설계되었고, 슬래시 명령어는 주로 사용자가 사용하도록 설계되었습니다. 하지만 결국 통합하게 되었는데, 제가 이 변경을 제안했었습니다.

플러그인은 skills, 슬래시 명령어, 에이전트, hooks, MCP 서버를 함께 패키징하는 방법입니다. 하지만 플러그인이 이 모든 것을 사용할 필요는 없습니다. Anthropic의 공식 frontend-design 플러그인은 본질적으로 skill 하나일 뿐입니다. 독립적인 skill로 배포할 수 있지만, 플러그인 형식이 설치를 더 쉽게 만듭니다.

예를 들어, 이 저장소의 슬래시 명령어와 skill을 함께 묶은 dx라는 플러그인을 만들었습니다. 작동 방식은 dx 플러그인 설치 섹션에서 볼 수 있습니다.

Tip 26: 인터랙티브 PR 리뷰

Claude Code는 PR 리뷰에 훌륭합니다. 절차는 꽤 간단합니다: gh 명령을 사용해 PR 정보를 가져오도록 요청하고, 원하는 방식으로 리뷰를 진행합니다.

전체적인 리뷰를 하거나, 파일별로, 단계별로 할 수 있습니다. 속도를 제어합니다. 얼마나 자세히 살펴보고 싶은지, 어느 수준의 복잡성에서 작업하고 싶은지를 제어합니다. 전체적인 구조만 이해하고 싶을 수도 있고, 테스트도 실행하고 싶을 수도 있습니다.

핵심 차이점은 Claude Code가 단발성 기계가 아닌 인터랙티브 PR 리뷰어로 작동한다는 것입니다. 일부 AI 도구는 단발성 리뷰에 뛰어나지만 (최신 GPT 모델 포함), Claude Code에서는 대화를 할 수 있습니다.

Tip 27: Claude Code를 리서치 도구로 활용

Claude Code는 모든 종류의 리서치에 놀라울 정도로 뛰어납니다. 본질적으로 Google 대체제 또는 딥 리서치 대체제이지만, 여러 면에서 더 발전된 것입니다. 특정 GitHub Actions가 왜 실패하는지 조사하거나 (최근에 많이 하고 있습니다), Reddit에서 감성 분석이나 시장 분석을 하거나, 코드베이스를 탐색하거나, 공개 정보를 탐색해 무언가를 찾는 것 - 이 모든 것을 할 수 있습니다.

핵심은 올바른 정보 조각과 해당 정보에 접근하는 방법에 대한 지침을 제공하는 것입니다. gh 터미널 명령 접근, 컨테이너 접근 방식 (Tip 21), Gemini CLI를 통한 Reddit (Tip 11), Slack MCP 같은 MCP를 통한 비공개 정보, Cmd+A / Ctrl+A 방법 (Tip 10) - 무엇이든 될 수 있습니다. 추가로, Claude Code가 특정 URL을 로딩하는 데 문제가 있으면 Playwright MCP나 Claude의 네이티브 브라우저 통합 (Tip 9 참조)을 사용해볼 수 있습니다.

사실, Claude Code를 리서치에 활용해 $10,000을 절약할 수도 있었습니다.

Tip 28: 출력 검증 방법 마스터하기

출력이 코드인 경우 검증하는 한 가지 방법은 테스트를 작성하게 하고 테스트가 전반적으로 괜찮은지 확인하는 것입니다. 그것도 한 방법이지만, 물론 Claude Code UI에서 생성하는 코드를 진행하면서 확인할 수도 있습니다. 또한 GitHub Desktop 같은 시각적 Git 클라이언트를 사용할 수 있습니다. 개인적으로 사용합니다. 완벽한 제품은 아니지만 변경사항을 빠르게 확인하기에 충분합니다. 그리고 앞서 언급한 것처럼 PR을 생성하게 하는 것도 좋은 방법입니다. draft PR을 만들게 하고, 실제 PR로 전환하기 전에 내용을 확인하세요.

또 다른 방법은 자체 점검, 즉 자기 작업을 확인하게 하는 것입니다. 리서치에서 어떤 출력을 제공하면 "이거 확실해? 다시 확인해볼 수 있어?"라고 말할 수 있습니다. 제가 즐겨 쓰는 프롬프트 중 하나는 "모든 것을 다시 확인해, 생산한 내용의 모든 주장을 하나하나 확인하고 마지막에 검증할 수 있었던 것의 표를 만들어줘"라고 하는 것인데, 이것이 정말 잘 작동합니다.

Tip 29: Claude Code를 DevOps 엔지니어로 활용

이것에 대해 별도의 팁을 만들고 싶었는데, 정말 놀라울 정도로 유용했기 때문입니다. GitHub Actions CI 실패가 있을 때마다 Claude Code에게 주고 "이 이슈를 파고들어서 근본 원인을 찾아봐"라고 합니다. 가끔 표면적인 답변을 주기도 하지만, 계속 물어보면 - 특정 커밋 때문인지, 특정 PR 때문인지, 아니면 불안정한 문제인지? - 수동으로 파고들기 힘든 복잡한 이슈를 파헤치는 데 정말 도움이 됩니다. 많은 로그를 살펴봐야 하고 수동으로 하면 극도로 고통스럽겠지만, Claude Code가 많은 부분을 처리할 수 있습니다.

이 워크플로우를 /gha 슬래시 명령어로 패키징했습니다 - GitHub Actions URL과 함께 /gha <url>을 실행하면 자동으로 실패를 조사하고, 불안정성을 확인하고, 원인이 되는 커밋을 식별하고, 수정 사항을 제안합니다. skills 폴더에서 찾을 수 있고, dx 플러그인을 통해 설치할 수도 있습니다.

특정 문제가 무엇인지 파악한 후, draft PR을 만들고 앞서 언급한 팁들을 활용하면 됩니다 - 출력을 확인하고, 괜찮은지 확인하고, 자체 검증을 하게 한 다음, 실제 PR로 전환하여 이슈를 수정합니다. 개인적으로 정말 잘 작동하고 있습니다.

Tip 30: CLAUDE.md를 간결하게 유지하고 주기적으로 검토하기

CLAUDE.md를 간단하고 최대한 간결하게 유지하는 것이 중요합니다. CLAUDE.md 없이 시작해도 됩니다. 그리고 Claude Code에게 같은 말을 반복적으로 하게 된다면, CLAUDE.md에 추가하면 됩니다. # 기호를 통해 추가하는 옵션이 있는 것은 알지만, 저는 Claude Code에게 프로젝트 수준의 CLAUDE.md나 전역 CLAUDE.md에 추가해달라고 요청하는 것을 선호하며, 정확히 무엇을 편집해야 하는지 알아냅니다.

CLAUDE.md 파일은 시간이 지남에 따라 오래될 수 있으므로 주기적으로 검토하는 것도 중요합니다. 얼마 전에 의미 있었던 지침이 더 이상 관련 없을 수 있고, 문서화해야 할 새로운 패턴이 있을 수 있습니다. 이를 위해 review-claudemd라는 skill을 만들었는데, 최근 대화를 분석하여 CLAUDE.md 파일의 개선 사항을 제안합니다.

Tip 31: 범용 인터페이스로서의 Claude Code

예전에는 Claude Code 덕분에 CLI가 새로운 IDE라고 생각했고, 어떤 면에서는 여전히 맞습니다. 빠른 편집을 하고 싶을 때 프로젝트를 여는 첫 번째 장소로 훌륭합니다. 하지만 프로젝트의 심각도에 따라 바이브 코딩 수준에 머무르는 것보다 출력에 더 주의를 기울여야 합니다.

하지만 더 일반적인 경우도 사실입니다. Claude Code는 정말로 컴퓨터, 디지털 세계, 모든 종류의 디지털 문제에 대한 범용 인터페이스입니다. 많은 경우 해결하도록 맡길 수 있습니다. 예를 들어, 영상을 빠르게 편집해야 한다면 그냥 요청하면 됩니다 - ffmpeg이나 비슷한 것을 통해 해결 방법을 찾을 것입니다. 로컬에 있는 오디오나 비디오 파일을 전사하고 싶다면 그냥 요청하면 됩니다 - Python을 통한 Whisper를 제안할 수 있습니다. CSV 파일에 있는 데이터를 분석하고 싶다면 Python이나 JavaScript로 시각화를 제안할 수 있습니다. 그리고 물론 인터넷 접근 - Reddit, GitHub, MCP - 가능성은 무한합니다.

로컬 컴퓨터에서 수행하려는 모든 작업에도 훌륭합니다. 예를 들어, 저장 공간이 부족하면 정리 방법에 대한 조언을 요청하면 됩니다. 로컬 폴더와 파일을 살펴보고 많은 공간을 차지하는 것을 찾은 다음 정리 방법을 조언해줍니다 - 특히 큰 파일을 삭제하라고 할 수 있습니다. 제 경우 정리했어야 할 정말 큰 Final Cut Pro 파일이 있었습니다. Claude Code가 알려줬습니다. docker system prune을 사용해 미사용 Docker 이미지와 컨테이너를 정리하라고 할 수도 있습니다. 또는 존재하는 줄도 몰랐던 캐시를 정리하라고 할 수도 있습니다. 컴퓨터에서 무엇을 하든, Claude Code가 제가 먼저 가는 곳입니다.

흥미로운 점은 컴퓨터가 텍스트 인터페이스로 시작했다는 것입니다. 그리고 어떤 면에서는, 앞서 언급한 것처럼 세 개, 네 개의 탭을 동시에 띄울 수 있는 이 텍스트 인터페이스로 돌아오고 있습니다. 저에게는 정말 흥미진진합니다. 두 번째 뇌를 가진 것 같은 느낌입니다. 하지만 터미널 탭이라는 구조 때문에 세 번째 뇌, 네 번째 뇌, 다섯 번째 뇌, 여섯 번째 뇌를 열 수 있습니다. 그리고 모델이 더 강력해짐에 따라, 이런 것들에 위임할 수 있는 사고의 비율이 - 중요한 것이 아닌, 하고 싶지 않거나 지루하거나 너무 지겨운 것들 - 그냥 처리하게 하면 됩니다. 앞서 언급한 것처럼 GitHub Actions를 살펴보는 것이 좋은 예입니다. 누가 하고 싶겠습니까? 하지만 이 에이전트들은 그런 지루한 작업을 정말 잘합니다.

Tip 32: 적절한 추상화 수준 선택이 핵심

앞서 언급한 것처럼, 때로는 바이브 코딩 수준에 머물러도 괜찮습니다. 일회성 프로젝트나 코드베이스의 중요하지 않은 부분에서 작업할 때는 모든 코드 줄을 걱정할 필요가 없습니다. 하지만 다른 때에는 좀 더 깊이 파고들어야 합니다 - 파일 구조와 함수, 개별 코드 줄, 심지어 종속성까지 확인해야 합니다.

핵심은 이분법적이지 않다는 것입니다. 어떤 사람들은 바이브 코딩이 무엇을 하는지 모르기 때문에 나쁘다고 말하지만, 때로는 전혀 문제가 없습니다. 하지만 다른 때에는 더 깊이 파고들어 소프트웨어 엔지니어링 기술을 활용하고, 세부 수준에서 코드를 이해하거나, 코드베이스의 일부나 특정 오류 로그를 복사 붙여넣기해서 Claude Code에 구체적인 질문을 하는 것이 도움이 됩니다.

거대한 빙산을 탐험하는 것과 비슷합니다. 바이브 코딩 수준에 머물고 싶다면 위를 날면서 멀리서 확인할 수 있습니다. 그런 다음 좀 더 가까이 갈 수 있습니다. 다이빙 모드로 들어갈 수 있습니다. Claude Code를 가이드로 삼아 더 깊이, 더 깊이 들어갈 수 있습니다.

Tip 33: 승인된 명령어 감사하기

최근에 이 게시물을 봤는데, 누군가의 Claude Code가 rm -rf tests/ patches/ plan/ ~/를 실행해서 홈 디렉토리를 모두 지웠습니다. 바이브 코더의 실수로 치부하기 쉽지만, 이런 실수는 누구에게나 일어날 수 있습니다. 그래서 승인된 명령어를 때때로 감사하는 것이 중요합니다. 이를 더 쉽게 하기 위해 cc-safe를 만들었습니다 - .claude/settings.json 파일에서 위험한 승인된 명령어를 스캔하는 CLI입니다.

다음과 같은 패턴을 감지합니다:

• sudo, rm -rf, Bash, chmod 777, curl | sh
• git reset --hard, npm publish, docker run --privileged
• 그 외 더 많은 것들 - 컨테이너를 인식하므로 docker exec 명령은 건너뜁니다

모든 하위 디렉토리를 재귀적으로 스캔하므로, 프로젝트 폴더를 지정해 한 번에 모든 것을 확인할 수 있습니다. 수동으로 실행하거나 Claude Code에게 실행하도록 요청할 수 있습니다:

npm install -g cc-safe
cc-safe ~/projects

또는 npx로 바로 실행할 수 있습니다:

npx cc-safe .

GitHub: cc-safe

Tip 34: 테스트를 많이 작성하기 (그리고 TDD 활용)

Claude Code로 코드를 더 많이 작성할수록 실수하기가 더 쉬워집니다. PR 리뷰와 시각적 Git 클라이언트가 이슈를 잡는 데 도움이 되지만 (앞서 언급한 것처럼), 코드베이스가 커질수록 테스트 작성이 중요해집니다.

Claude Code가 자기 코드의 테스트를 작성하게 할 수 있습니다. 어떤 사람들은 AI가 자기 작업을 테스트할 수 없다고 하지만, 사실 가능합니다 - 인간의 뇌가 작동하는 방식과 비슷합니다. 테스트를 작성할 때 같은 문제를 다른 방식으로 생각하게 됩니다. AI에도 마찬가지가 적용됩니다.

Claude Code와 TDD (테스트 주도 개발)가 정말 잘 작동한다는 것을 발견했습니다:

1. 먼저 테스트를 작성
2. 실패하는지 확인
3. 테스트를 커밋
4. 테스트를 통과하는 코드를 작성

이것이 실제로 cc-safe를 만든 방법입니다. 구현 전에 실패하는 테스트를 먼저 작성하고 커밋하면 코드가 무엇을 해야 하는지에 대한 명확한 계약을 만들게 됩니다. 그러면 Claude Code에 달성해야 할 구체적인 목표가 생기고, 테스트를 실행해 구현이 맞는지 검증할 수 있습니다.

추가로 확실히 하고 싶다면, 테스트를 직접 검토해서 단순히 true만 반환하는 것 같은 어리석은 짓을 하지 않는지 확인하세요.

Tip 35: 미지의 영역에서 더 대담해지기 - 반복적 문제 해결

Claude Code를 더 집중적으로 사용하기 시작한 이후, 미지의 영역에서 점점 더 대담해지는 것을 느꼈습니다.

예를 들어, Daft에서 일하기 시작했을 때, 프론트엔드 코드에 문제가 있는 것을 발견했습니다. React 전문가가 아니지만, 어쨌든 파고들기로 했습니다. 코드베이스와 문제에 대해 질문하기 시작했습니다. 결국 Claude Code로 문제를 반복적으로 해결하는 방법을 알고 있었기 때문에 해결할 수 있었습니다.

최근에 비슷한 일이 있었습니다. Daft 사용자를 위한 가이드를 만들면서 매우 구체적인 문제에 부딪혔습니다: cloudpickle이 Pydantic과 함께 Google Colab에서 작동하지 않는 문제, 그리고 Python과 약간의 Rust에서 터미널에서는 잘 되는데 JupyterLab에서는 제대로 출력되지 않는 별개의 문제. Rust로 작업해본 적이 없었습니다.

이슈를 만들어 다른 엔지니어에게 맡길 수도 있었습니다. 하지만 코드베이스를 파고들어보자고 생각했습니다. Claude Code가 초기 솔루션을 제안했지만 그다지 좋지 않았습니다. 그래서 속도를 늦췄습니다. 동료가 그 부분을 비활성화하자고 제안했지만, 어떤 회귀도 원하지 않았습니다. 더 나은 솔루션을 찾을 수 있을까?

이어진 것은 협력적이고 반복적인 과정이었습니다. Claude Code가 잠재적 근본 원인과 솔루션을 제안했습니다. 실험했습니다. 일부는 막다른 길로 판명되어 다른 방향으로 갔습니다. 이 과정에서 속도를 조절했습니다. 때로는 다른 솔루션 공간이나 코드베이스 부분을 탐색하게 할 때처럼 빠르게 갔습니다. 때로는 "이 줄이 정확히 무엇을 의미하지?"라고 물으며 느리게 갔습니다. 추상화 수준을 제어하고, 속도를 제어하면서요.

결국 꽤 우아한 솔루션을 찾았습니다. 교훈: 미지의 세계에서도 Claude Code와 함께라면 생각보다 훨씬 많은 것을 할 수 있습니다.

Tip 36: 백그라운드에서 bash 명령어와 서브에이전트 실행

Claude Code에서 오래 걸리는 bash 명령이 있을 때, Ctrl+B를 눌러 백그라운드에서 실행하도록 이동할 수 있습니다. Claude Code는 백그라운드 프로세스를 관리하는 방법을 알고 있어 나중에 BashOutput 도구를 사용해 확인할 수 있습니다.

이것은 명령이 예상보다 오래 걸리는 것을 깨달았을 때 Claude가 그 사이에 다른 작업을 하도록 하고 싶을 때 유용합니다. 그런 다음 Tip 17에서 언급한 지수 백오프 방법을 사용해 진행 상황을 확인하게 하거나, 프로세스가 실행되는 동안 완전히 다른 작업을 하게 할 수 있습니다.

Claude Code에는 서브에이전트를 백그라운드에서 실행하는 기능도 있습니다. 장시간 리서치가 필요하거나 주기적으로 무언가를 확인하는 에이전트가 필요한 경우, 포그라운드에서 계속 실행할 필요가 없습니다. Claude Code에게 에이전트나 작업을 백그라운드에서 실행하도록 요청하면 다른 작업을 계속하면서 처리됩니다.

서브에이전트 전략적 활용

백그라운드 실행 외에도, 큰 작업을 분할해야 할 때 서브에이전트가 유용합니다. 예를 들어, 분석해야 할 큰 코드베이스가 있다면 서브에이전트들이 다른 방식으로 분석하거나 코드베이스의 다른 부분을 병렬로 살펴보게 할 수 있습니다. Claude에게 다른 부분을 처리할 여러 서브에이전트를 생성하도록 요청하면 됩니다.

서브에이전트를 요청하여 커스터마이징할 수 있습니다:

• 몇 개 - 원하는 수만큼 생성 요청
• 백그라운드 vs 포그라운드 - 백그라운드에서 실행하도록 요청하거나 Ctrl+B 사용
• 어떤 모델 - 각 작업의 복잡성에 따라 Opus, Sonnet, Haiku를 요청 (서브에이전트는 기본적으로 Sonnet)

Tip 37: 개인화된 소프트웨어의 시대가 왔다

개인화된 맞춤형 소프트웨어의 시대에 접어들고 있습니다. AI가 나온 이후 - 일반적인 ChatGPT, 특히 Claude Code - 훨씬 더 많은 소프트웨어를 만들 수 있게 되었습니다. 때로는 저만을 위해, 때로는 작은 프로젝트를 위해서요.

이 문서에서 앞서 언급한 것처럼, 매일 Claude Code와 대화하기 위해 사용하는 커스텀 전사 도구를 만들었습니다. Claude Code 자체를 커스터마이징하는 방법을 만들었습니다. Python을 사용한 데이터 시각화와 데이터 분석 작업도 그렇지 않았으면 할 수 있었을 것보다 훨씬 빠르게 많이 했습니다.

또 다른 예시입니다: korotovsky/slack-mcp-server, 거의 1,000개의 스타를 가진 인기 있는 Slack MCP는 Docker 컨테이너로 실행되도록 설계되어 있습니다. 제 Docker 컨테이너 내부에서 원활하게 사용하는 데 문제가 있었습니다 (Docker-in-Docker 복잡성). 그 설정과 씨름하는 대신, Claude Code에게 Slack의 Node SDK를 사용해 직접 CLI를 작성하도록 요청했습니다. 정말 잘 작동했습니다.

흥미진진한 시기입니다. 무엇이든 하고 싶으면 Claude Code에게 요청할 수 있습니다. 충분히 작다면 한두 시간 안에 만들 수 있습니다. 내부에 인터랙티브하고 영구적인 터미널 프로세스를 삽입할 수 있는 슬라이드 데크 템플릿 - CSS와 JavaScript가 포함된 단일 HTML 파일 - 도 만들었습니다.

Tip 38: 입력 상자 탐색 및 편집

Claude Code의 입력 상자는 일반적인 터미널/readline 단축키를 에뮬레이트하도록 설계되어, 터미널에서 작업하는 데 익숙하다면 자연스럽게 느껴집니다. 유용한 것들을 소개합니다:

탐색:

• Ctrl+A - 줄의 시작으로 이동
• Ctrl+E - 줄의 끝으로 이동
• Option+Left/Right (Mac) 또는 Alt+Left/Right - 단어 단위로 앞뒤 이동

편집:

• Ctrl+W - 이전 단어 삭제
• Ctrl+U - 커서에서 줄 시작까지 삭제
• Ctrl+K - 커서에서 줄 끝까지 삭제
• Ctrl+C / Ctrl+L - 현재 입력 지우기
• Ctrl+G - 외부 편집기에서 프롬프트 열기 (긴 텍스트를 붙여넣을 때 유용, 터미널에 직접 붙여넣으면 느릴 수 있으므로)

bash, zsh 또는 다른 쉘에 익숙하다면 바로 적응할 수 있습니다.

Ctrl+G의 경우, 편집기는 EDITOR 환경 변수에 의해 결정됩니다. 쉘 설정(~/.zshrc 또는 ~/.bashrc)에서 설정할 수 있습니다:

export EDITOR=vim      # 또는 nano, code, nvim 등

또는 ~/.claude/settings.json에서 설정합니다 (재시작 필요):

{
  "env": {
    "EDITOR": "vim"
  }
}

줄바꿈 입력 (멀티라인 입력):

가장 빠른 방법은 설정 없이 어디서나 작동합니다: \를 입력한 후 Enter를 누르면 줄바꿈이 됩니다. 키보드 단축키의 경우 Claude Code에서 /terminal-setup을 실행하세요. Mac Terminal.app에서는 Option+Enter를 사용합니다.

이미지 붙여넣기:

• Ctrl+V (Mac/Linux) 또는 Alt+V (Windows) - 클립보드에서 이미지 붙여넣기

참고: Mac에서는 Cmd+V가 아닌 Ctrl+V입니다.

Tip 39: 계획에 시간을 투자하되, 프로토타입도 빠르게

Claude Code가 무엇을 어떻게 만들어야 하는지 알 수 있도록 충분한 시간을 계획에 투자해야 합니다. 이것은 높은 수준의 결정을 일찍 내리는 것을 의미합니다: 어떤 기술을 사용할지, 프로젝트를 어떻게 구조화할지, 각 기능이 어디에 위치할지, 어떤 파일에 들어갈지. 가능한 한 일찍 좋은 결정을 내리는 것이 중요합니다.

때로는 프로토타이핑이 그것에 도움이 됩니다. 간단한 프로토타입을 빠르게 만드는 것만으로 "좋아, 이 기술이 이 특정 목적에 적합하구나" 또는 "다른 기술이 더 잘 작동하네"라고 말할 수 있을 겁니다.

예를 들어, 최근에 diff 뷰어를 만드는 실험을 했습니다. 먼저 tmux와 lazygit을 사용한 간단한 bash 프로토타입을 시도한 다음, Ink과 Node로 자체 git 뷰어를 만들어봤습니다. 여러 가지에서 많은 어려움을 겪었고 결국 이 결과물들을 게시하지 않았습니다. 하지만 이 프로젝트를 통해 계획과 프로토타이핑의 중요성을 다시 상기했습니다. 코드를 작성하게 하기 전에 처음에 조금 더 잘 계획하는 것만으로도 더 잘 안내할 수 있다는 것을 발견했습니다. 코딩 과정 전반에 걸쳐 여전히 안내해야 하지만, 먼저 약간의 계획을 세우게 하는 것이 정말 도움이 됩니다.

이를 위해 Shift+Tab을 눌러 plan 모드를 사용할 수 있습니다. 또는 Claude Code에게 코드를 작성하기 전에 계획을 세우도록 요청할 수 있습니다.

Tip 40: 과도하게 복잡한 코드 단순화하기

Claude Code가 때때로 과도하게 복잡하게 만들고 너무 많은 코드를 작성한다는 것을 발견했습니다. 요청하지 않은 변경을 합니다. 더 많은 코드를 작성하려는 편향이 있는 것 같습니다. 이 가이드의 다른 팁을 따랐다면 코드가 올바르게 작동할 수 있지만, 유지 관리하기 어렵고 확인하기 어려울 것입니다. 충분히 검토하지 않으면 악몽이 될 수 있습니다.

그래서 때때로 코드를 확인하고 단순화를 요청해야 합니다. 직접 수정할 수도 있지만, 단순화를 요청할 수도 있습니다. "왜 이 특정 변경을 했어?" 또는 "왜 이 줄을 추가했어?"라고 질문할 수 있습니다.

어떤 사람들은 AI로만 코드를 작성하면 결코 이해하지 못할 거라고 합니다. 하지만 그것은 충분한 질문을 하지 않을 때만 맞습니다. 모든 것을 이해하도록 확인한다면, 실제로 AI에게 물어볼 수 있기 때문에 그렇지 않았을 때보다 더 빨리 코드를 이해할 수 있습니다. 특히 큰 프로젝트에서 작업할 때요.

이것은 산문에도 적용됩니다. Claude Code는 종종 마지막 문단에서 이전 문단을 요약하거나, 마지막 문장에서 이전 문장을 요약하려 합니다. 꽤 반복적이 될 수 있습니다. 때로는 도움이 되지만, 대부분의 경우 제거하거나 단순화하도록 요청해야 할 것입니다.

Tip 41: 자동화의 자동화

결국에는 자동화의 자동화에 관한 것입니다. 이것이 의미하는 바는 더 생산적이 될 뿐만 아니라 과정을 더 재미있게 만드는 가장 좋은 방법이라는 것입니다. 적어도 저에게는 자동화의 자동화라는 이 전체 과정이 정말 재미있습니다.

개인적으로 ChatGPT에서 시작해 ChatGPT가 제공하는 명령어를 터미널에 복사 붙여넣기하고 실행하는 과정을 자동화하고 싶었습니다. Kaguya라는 ChatGPT 플러그인을 만들어 그 전체 과정을 자동화했습니다. 그 이후로 계속 더 많은 자동화를 향해 일해왔습니다.

요즘에는 다행히 그런 도구를 만들 필요가 없습니다. Claude Code 같은 도구가 존재하고 정말 잘 작동하기 때문입니다. 그리고 더 많이 사용하면서, 타이핑 과정을 자동화할 수 있다면 어떨까 하고 생각했습니다. 그래서 앞서 언급한 것처럼 Claude Code 자체를 사용해 음성 전사 앱을 만들었습니다.

그런 다음 가끔 같은 말을 반복하는 것을 느꼈습니다. 그래서 CLAUDE.md에 넣었습니다. 그러다 같은 명령을 반복적으로 실행한다고 생각했습니다. 어떻게 자동화할 수 있을까? Claude Code에게 요청할 수 있을까. 아니면 skills에 넣을 수 있을까. 아니면 같은 과정을 반복하지 않도록 스크립트를 만들게 할 수 있을까.

궁극적으로 그것이 우리가 향하는 방향이라고 생각합니다. 같은 작업이나 명령을 반복적으로 실행하는 것을 발견할 때마다, 몇 번은 괜찮지만 계속 반복한다면, 그 전체 과정을 자동화할 방법을 생각해보세요.

Tip 42: 지식을 공유하고 기여하기

이 팁은 다른 것들과 좀 다릅니다. 가능한 한 많이 배우면 주변 사람들과 지식을 공유할 수 있다는 것을 발견했습니다. 이런 게시물을 통해, 심지어 책, 강좌, 영상을 통해서요. 최근에는 Daft 동료들을 위한 내부 세션도 했습니다. 매우 보람 있었습니다.

그리고 팁을 공유할 때마다 종종 정보를 되돌려 받습니다. 예를 들어, 시스템 프롬프트와 도구 설명을 줄이는 트릭 (Tip 15)을 공유했을 때, 일부 사람들이 대안으로 사용할 수 있는 --system-prompt 플래그에 대해 알려줬습니다. 또 다른 때는 슬래시 명령어와 skills의 차이 (Tip 25)에 대해 공유했더니 그 Reddit 게시물의 댓글에서 새로운 것을 배웠습니다.

그러므로 지식 공유는 브랜드를 구축하거나 학습을 견고히 하는 것만이 아닙니다. 그 과정을 통해 새로운 것을 배우는 것이기도 합니다. 항상 일방통행이 아닙니다.

기여에 관해서는, Claude Code 저장소에 이슈를 보내왔습니다. 들어주면 좋고, 안 들어줘도 괜찮다고 생각했습니다. 기대는 없었습니다. 하지만 버전 2.0.67에서 제가 보고한 여러 제안이 채택된 것을 발견했습니다:

• /permissions에서 권한 규칙을 삭제한 후 스크롤 위치가 리셋되는 문제 수정
• /permissions 명령에 검색 기능 추가

팀이 기능 요청과 버그 리포트에 얼마나 빨리 반응하는지 놀랍습니다. 하지만 그들이 Claude Code로 Claude Code를 만들고 있기 때문에 말이 됩니다.

Tip 43: 계속 배우기!

Claude Code에 대해 계속 배울 수 있는 효과적인 방법이 여러 가지 있습니다:

Claude Code에게 직접 물어보기 - Claude Code에 대한 질문이 있으면 그냥 물어보세요. Claude Code에는 자체 기능, 슬래시 명령어, 설정, hooks, MCP 서버 등에 대한 질문에 답하는 전문 서브에이전트가 있습니다.

릴리스 노트 확인 - /release-notes를 입력하면 현재 버전의 새로운 기능을 볼 수 있습니다. 최신 기능을 배우는 가장 좋은 방법입니다.

커뮤니티에서 배우기 - r/ClaudeAI 서브레딧은 다른 사용자들로부터 배우고 사람들이 사용하는 워크플로우를 볼 수 있는 훌륭한 곳입니다.

Ado의 팁 팔로우하기 - Ado (@adocomplete)는 Anthropic의 DevRel로, 2025년 12월 내내 "Advent of Claude" 시리즈에서 매일 Claude Code 팁을 게시했습니다. 이 특정 시리즈는 이미 끝났지만, X에서 계속 유용한 팁을 공유합니다.

• Twitter/X: Advent of Claude 게시물
• LinkedIn: Advent of Claude 게시물

Tip 44: dx 플러그인 설치하기

이 저장소는 dx (개발자 경험)라는 Claude Code 플러그인이기도 합니다. 위의 팁들에서 여러 도구를 하나의 설치로 묶습니다:

Skill	설명
/dx:gha <url>	GitHub Actions 실패 분석 (Tip 29)
/dx:handoff	컨텍스트 연속성을 위한 인수인계 문서 생성 (Tip 8)
/dx:clone	대화를 복제하여 분기 (Tip 23)
/dx:half-clone	컨텍스트 줄이기를 위한 반절 복제 (Tip 23)
/dx:reddit-fetch	Gemini CLI를 통한 Reddit 콘텐츠 가져오기 (Tip 11)
/dx:review-claudemd	대화를 검토하여 CLAUDE.md 파일 개선 (Tip 30)

두 명령으로 설치:

claude plugin marketplace add ykdojo/claude-code-tips
claude plugin install dx@ykdojo

설치 후 명령어는 /dx:clone, /dx:half-clone, /dx:handoff, /dx:gha로 사용할 수 있습니다. reddit-fetch skill은 Reddit URL에 대해 질문하면 자동으로 호출됩니다. review-claudemd skill은 최근 대화를 분석하고 CLAUDE.md 파일의 개선 사항을 제안합니다. clone 명령어의 경우 권장 권한을 참조하세요.

권장 동반 도구: 브라우저 자동화를 위한 Playwright MCP - claude mcp add -s user playwright npx @playwright/mcp@latest로 추가

Tip 45: 빠른 설정 스크립트

이 저장소의 여러 권장 사항을 한 번에 설정하고 싶다면, 많은 것들을 처리하는 설정 스크립트가 있습니다:

bash <(curl -s https://raw.githubusercontent.com/ykdojo/claude-code-tips/main/scripts/setup.sh)

스크립트가 구성할 모든 항목을 보여주고 항목을 건너뛸 수 있습니다:

설치 항목:
  1. DX 플러그인 - 슬래시 명령어 (/dx:gha, /dx:clone, /dx:handoff) 및 skills (reddit-fetch)
  2. cc-safe - 'rm -rf'나 'sudo' 같은 위험한 승인된 명령어 스캔

설정 (~/.claude/settings.json):
  3. 상태 표시줄 - 화면 하단에 모델, git 브랜치, 커밋되지 않은 파일, 토큰 사용량 표시
  4. 자동 업데이트 비활성화 - Claude Code 자동 업데이트 방지 (시스템 프롬프트 패치에 유용)
  5. MCP 도구 지연 로딩 - 필요할 때만 MCP 도구 정의 로드, 컨텍스트 절약
  6. Read(~/.claude) 권한 - clone/half-clone 명령어가 대화 기록을 읽을 수 있도록 허용
  7. Read(//tmp/**) 권한 - 프롬프트 없이 임시 파일 읽기 허용
  8. 어트리뷰션 비활성화 - 커밋에서 Co-Authored-By 제거 및 PR에서 어트리뷰션 제거

셸 설정 (~/.zshrc 또는 ~/.bashrc):
  9. 별칭: c=claude, ch=claude --chrome, cs=claude --dangerously-skip-permissions
 10. 포크 단축키: --fs가 --fork-session으로 확장 (예: claude -c --fs)

건너뛸 항목? [예: 1 4 7 또는 Enter로 전체 설치]:

---

📺 관련 강연: Claude Code 마스터클래스 - 31개월간의 에이전트 코딩에서 얻은 교훈과 프로젝트 예시

📝 이야기: Claude Code로 정규직을 얻은 방법

📰 뉴스레터: 규율과 기술로 하는 에이전트 코딩 - 에이전트 코딩 실천을 다음 단계로