Claude Code를 ‘덜 쓰고 더 많이’ 쓰는 법: 창시자가 알려주는 사용 방법

1. Boris Cherny: “만든 사람이 말하는” Claude Code 운영법

Boris Cherny는 Claude Code를 만든 인물로, 많은 사람들이 “어떻게 쓰냐”는 질문을 하자 자신의 셋업과 습관을 공개했습니다. 흥미로운 건 그의 답이 화려한 커스터마이즈가 아니라는 점입니다. 기본 설정 그대로도(out of the box) 잘 동작하고, 팀 내에서도 사람마다 다르게 쓴다고 말합니다.

그럼에도 공통점이 있습니다. 그는 Claude Code를 “프롬프트 기술”이 아니라 “운영”의 문제로 보고, 병렬 작업, 표준화, 검증 루프 같은 습관으로 체감을 끌어올립니다. 이 글은 그가 직접 공개한 사용법을, 초보도 따라할 수 있는 운영 원칙으로 정리한 글입니다.

이 글은 Claude Code를 만든(혹은 팀에서 핵심 역할을 하는) Boris Cherny(@bcherny)와 주변 공개 발언에서 보이는 방향성을 바탕으로 구성했습니다. 각 원칙은 “한 줄 인용 → 짧은 해설 → 실전 팁” 형식으로 정리합니다. 인용은 최소한으로 두고, 핵심은 적용 가능한 루틴으로 바꿔 전달하겠습니다.

Boris Cherny X 바로가기

2. 훅 (Hook): 토큰을 아끼는 사람이 더 오래 이긴다

문서 페이지를 HTML로 긁어오느라 토큰을 불태우는 순간, 에이전트는 똑똑해도 예산과 컨텍스트가 먼저 죽습니다. 그래서 Claude Code(클로드 코드)를 “잘 쓰는 법”은 멋있는 프롬프트를 외우는 게임이 아니라, 입력과 컨텍스트, 반복 루프를 운영하는 방식에서 시작됩니다. Claude Code를 많이 쓴다는 건 대화를 길게 하는 게 아니라, 검증된 작업 단위를 더 많이 쌓는다는 뜻입니다.

Claude Code는 결국 “대화형 자동화”입니다. 자동화가 똑똑해질수록 역설적으로 당신이 신경 써야 하는 건 모델의 지능이 아니라 입력의 품질과 비용입니다. 특히 문서(Docs) 리서치에서 토큰은 가장 빨리 새는 구멍입니다. 같은 내용을 HTML로 가져오면 네비게이션, 사이드바, 푸터, 스크립트 텍스트까지 붙어서 토큰이 폭발하기 쉽습니다.

한 번만 “마크다운으로 가져오는 습관”을 만들면, 이후의 모든 작업이 가벼워집니다. 그게 오늘 글의 출발점입니다.

“Bun’s docs now send markdown instead of HTML by default… token usage… about 10x”

— Bun(@bunjavascript), 2025-09-27

3. 컨텍스트 (Context): Claude Code를 “덜 쓰고 더 많이” 쓴다는 뜻

“덜 쓰고 더 많이”는 말장난처럼 들릴 수 있지만, 실제로는 매우 현실적인 목표입니다. 덜 쓴다는 건 토큰, 컨텍스트, 대기시간, 불필요한 왕복을 줄인다는 뜻이고, 더 많이 쓴다는 건 검증 가능한 변경과 실행 가능한 결론, 닫힌 루프(Plan→Do→Check)를 늘린다는 뜻입니다. 즉 Claude Code는 ‘말을 잘시키는 도구’가 아니라 ‘검증 루프를 빨리 돌리는 도구’로 보는 쪽이 오래 갑니다.

이 글은 다음 5가지를 다룹니다.

• 문서/리서치 입력을 마크다운으로 만들기(토큰 효율)
• 컨텍스트를 오래 쓰기(오토-컴팩트, 요약, 참조)
• 반복 업무를 표준화하기(Plugins)
• 워크플로우에 붙이기(SDK)
• 작게-자주-검증 루프를 시스템으로 만들기

4. 공식/근거 기반 핵심 원칙 (운영 원칙 5개)

원칙 1) 문서는 “HTML”이 아니라 “마크다운”으로 받는다 (토큰 효율)

“In the next version of Claude Code, Claude’s WebFetch tool automatically adds Accept: ‘text/markdown, *’… token-efficient docs”
— Boris Cherny(@bcherny), 2025-11-13

마크다운은 콘텐츠의 본문만 남기기 쉬운 형식입니다. Claude Code가 문서를 읽고 이해해야 하는 상황이라면, “읽을 만한 입력”을 만드는 일이 먼저입니다. 토큰을 덜 쓰면 그만큼 더 많은 반복(실험/검증)을 할 수 있고, 그 반복이 결국 품질로 연결됩니다.

• 실전 팁 5개

1. 문서 사이트에 ‘마크다운 모드’가 있는지 먼저 찾습니다. “raw”, “markdown”, “print”, “?plain=1” 같은 옵션이 있는지 확인해 보세요. 목표는 “잘 가져오기”가 아니라 “가볍게 가져오기”입니다.
2. 통째로 가져오지 말고 필요한 섹션만 가져옵니다. “설치 섹션만”, “에러 코드 목록만”, “API 레퍼런스 중 foo()만”처럼 범위를 좁히면 비용과 잡음이 함께 줄어듭니다.
3. 붙여넣기 대신 “목차 + 링크 + 질문”으로 주입합니다. 문서 전체를 먹이고 요약시키는 패턴보다, 질문을 던지고 관련 단락만 가져오는 질의형 루프가 실전에선 더 강합니다.
4. 팀/개인 레포에 자주 쓰는 docs는 ‘마크다운 스냅샷’으로 캐시합니다. 매번 같은 문서를 fetch하는 건 비용 낭비이고, 필요할 때만 갱신해도 충분한 경우가 많습니다.
5. “문서 입력 최소화”를 리뷰 체크리스트로 만듭니다. 긴 문서/로그를 통째로 붙여넣는 습관만 줄여도, 체감은 빠르게 좋아집니다.

원칙 2) 반복 작업은 “Plugins”로 표준화한다 (개인 요령 → 팀 운영체계)

“Plugins are the easiest way to share and install bundles of agents, slash commands, MCP servers, and hooks.”
— Boris Cherny(@bcherny), 2025-10-10

생산성은 어떤 날의 영감이 아니라 반복 가능한 루틴에서 나옵니다. 플러그인은 개인의 요령을 “설치 가능한 묶음”으로 만드는 장치입니다. Claude Code 잘 쓰는 법은 프롬프트를 다듬는 것보다, 반복되는 동작을 패키징하는 쪽에 더 가깝습니다.

• 실전 팁 5개

1. 가장 먼저 플러그인화할 것은 ‘코딩’이 아니라 ‘운영’입니다. PR 요약, 변경 위험 분석, 릴리즈 노트 초안, 테스트 실행 가이드 같은 것들이 자동화되면 실제 코딩은 더 안전해집니다.
2. 슬래시 커맨드는 짧고 단일 목적(예: /summarize-diff, /suggest-tests)으로 쪼갭니다. 한 번에 많은 걸 시키는 커맨드는 실패했을 때 되돌리기도 어렵습니다.
3. 훅(hooks)은 ‘사고 방지’에만 붙입니다. 포맷/린트/테스트 같은 가드레일을 실행 전후에 붙여두면, 속도를 올릴수록 늘어나는 실수를 줄일 수 있습니다.
4. MCP 서버는 사내 데이터/문서 연결부터 시작합니다. 외부 도구 통합이 멋있어 보이더라도, 팀 생산성은 결국 “우리 조직의 정보”를 얼마나 잘 끌어오느냐에 달려 있는 경우가 많습니다.
5. 플러그인은 버전/변경 로그를 남깁니다. 사람이 불안해하는 지점은 기능이 아니라 “이게 지금 어떤 상태인지”라서, 버전과 변경 내역이 신뢰를 만듭니다.

원칙 3) 컨텍스트는 자동으로 줄어든다—그래서 “요약 가능한 구조”로 일한다 (오토-컴팩트 이해)

“Compact behavior is the same as before… We always auto-compacted near 155k tokens…”
— Boris Cherny(@bcherny), 2025-10-12

긴 작업은 언젠가 컨텍스트가 압축(컴팩트)됩니다. 이건 버그가 아니라 지속 가능성 기능에 가깝습니다. 그래서 “대화가 길었으니 다 기억하겠지”라는 기대는 깨지는 편이 낫습니다. 오토-컴팩트가 있는 세계에서는 대화 로그보다 ‘작업 메모’가 더 중요한 컨텍스트가 됩니다.

• 실전 팁 5개

1. 세션 시작에 ‘작업 메모’를 만들고 계속 갱신합니다. Goal/Constraints/Done/Next 네 줄만 유지해도 작업이 길어질 때 흔들림이 줄어듭니다.
2. 코드/로그는 전문 붙여넣기 대신 ‘경로 + 핵심’만 남깁니다. “src/foo.ts에서 bar() 호출 시 NPE, 스택트레이스 첫 5줄” 정도면 대개 충분합니다.
3. 대화가 길어지면 해결을 요구하기 전에 ‘5줄 요약’을 먼저 시킵니다. 확정된 사실 5줄, 가능한 원인 3개, 다음 액션 3개로 정리시키면 다음 단계 품질이 올라갑니다.
4. 이슈가 바뀌면 세션을 새로 파고, 이전 세션은 한 문단 요약으로 연결합니다. 컨텍스트 오염을 막는 가장 단순한 방법입니다.
5. /context는 상태 확인 도구로만 씁니다. 불필요한 배경 설명은 과감히 줄이고, 목표/제약/재현 방법만 남기는 편이 장기적으로 더 잘됩니다.

원칙 4) Claude Code는 터미널에서 끝나지 않는다—SDK로 워크플로우에 붙인다

“Claude Code SDK is now natively supported for Python and TypeScript”
— Boris Cherny(@bcherny), 2025-06-13

Claude Code를 잘 쓰는 팀은 “툴을 열어야 일이 시작되는 구조”를 싫어합니다. 대신 워크플로우가 흐르는 지점(CI, PR, 이슈 트래킹, 온콜)에 자동화를 붙입니다. SDK는 Claude Code를 ‘대화형 사용’에서 ‘시스템화’로 넘어가게 해주는 연결부입니다.

• 실전 팁 5개

1. CI에 PR 요약/위험 분석/테스트 추천 코멘트를 붙입니다. 코드 생성보다 리뷰 보조가 도입 장벽이 낮습니다.
2. 이슈 트리아지(분류/재현/우선순위 힌트)를 자동화합니다. 문제를 정리하는 단계가 빨라지면 해결 속도도 같이 올라갑니다.
3. 런북(runbook) 자동 생성을 붙입니다. 장애 로그 → 가능한 원인 → 검증 커맨드 → 롤백 순서가 자동으로 나오면 온콜의 피로도가 줄어듭니다.
4. 처음부터 자동 코드 생성에 올인하기보다 검증/리뷰 보조부터 붙입니다. 팀의 신뢰를 쌓는 순서로 가는 편이 안전합니다.
5. 권한/비밀키/로그 보존 원칙을 먼저 정합니다. 자동화가 워크플로우에 들어가는 순간부터는 보안과 컴플라이언스가 현실 문제가 됩니다.

원칙 5) “대부분의 새 코드가 에이전트로 만들어진다”의 진짜 의미: 작은 루프를 시스템으로 만든다

“Claude Code is… an Agentic AI coding product… Most of the new code at Anthropic is created through it today.”
— Matt Turck(@mattturck) 인용, 2025-08-08

이 문장을 “AI가 다 해준다”로 읽으면 실망하기 쉽습니다. 현실적인 해석은 반복 루프의 기본값이 에이전트가 됐다는 쪽에 가깝습니다. 즉 작게 쪼개고, 자주 검증하고, 막히면 다음 액션을 제시하는 시스템이 만들어졌다는 뜻입니다.

• 실전 팁 5개

1. 큰 기능은 1~2시간짜리 변경으로 쪼갭니다. 하루짜리 PR은 사람에게도 위험하고, 에이전트에게는 더 위험합니다.
2. 먼저 실패 재현부터 만들고, 그 다음에 패치합니다. 재현 없는 수정은 운이고, 운은 재현되지 않습니다.
3. 한 번에 하나의 축만 바꿉니다. 로직/리팩터/포맷이 섞이면 실패했을 때 원인 추적이 어려워집니다.
4. 정답 프롬프트보다 Done 정의가 중요합니다. “테스트 A/B 통과”, “이 커맨드에서 에러 사라짐”, “이 입력에서 기대 출력”처럼 성공 기준을 적어두면 왕복이 줄어듭니다.
5. 막히면 다음 액션 3개를 뽑고, 그중 가장 리스크 낮은 1개만 실행합니다. 대화를 늘리는 대신 실행 가능한 선택지를 줄이는 게 오래 갑니다.

5. 실제 사용자 반응 및 커뮤니티 리액션

이번 글은 Reddit/HN 댓글 인용 대신, 공개적으로 확인되는 “사용자 반응성 사례”를 가볍게 묶어봅니다. 커뮤니티 인용은 최종 편집에서 추가해도 좋고, 지금은 메시지가 전달되도록 구성만 잡겠습니다.

긍정적 반응

문서가 HTML이 아니라 마크다운을 주면 토큰 사용량이 10배 줄었다
—Bun(@bunjavascript), 2025-09-27

이 사례가 재미있는 이유는 “모델이 더 똑똑해져서”가 아니라 “입력이 바뀌어서” 비용과 품질이 개선됐다는 점입니다. 즉 실전 체감은 모델 비교보다 입력을 어떻게 만들고 검증 루프를 어떻게 돌리느냐에서 갈릴 때가 많습니다.

우려할 점

많이 나오는 질문은 두 가지입니다. 컨텍스트가 길어지면 어디까지 기억하느냐, 그리고 설정이 복잡해 보여서 손이 안 간다는 이야기죠. 전자는 오토-컴팩트를 전제로 작업 메모/요약 루틴을 만들면 해결되고, 후자는 플러그인/SDK를 나중으로 미루고 15분 루틴부터 시작하는 편이 현실적입니다.

실제 사용 시나리오 3개

1. 문서 기반 버그 수정: 문서를 마크다운으로 가져오고 → 관련 섹션만 확인하고 → 원인 후보를 좁히고 → 재현 테스트를 만든 뒤 → 패치하고 → 테스트로 닫습니다.
2. 팀 표준 PR 루틴: 플러그인으로 PR 요약/체크리스트/리뷰 코멘트 초안을 자동화해 리뷰 속도와 품질을 동시에 올립니다.
3. 릴리즈/장애 대응: SDK로 로그 요약과 검증 커맨드, 롤백 단계가 포함된 런북을 자동 생성해 온콜의 피로도를 낮춥니다.

6. 심층 분석 (Deep Dive): “덜 쓰고 더 많이”의 메커니즘

토큰을 아끼면 비용만 줄어드는 게 아닙니다. 입력이 가벼우면 모델이 잡음을 덜 먹고, 더 많은 반복을 할 수 있고, 그 반복이 검증으로 이어집니다. 그래서 “마크다운을 받는다”는 최적화 팁이 아니라 품질 전략에 가깝습니다.

컨텍스트 운영도 같은 이야기입니다. 오토-컴팩트가 있다는 전제에서 정보를 대화 로그에 두면 언젠가 사라지지만, 정보를 요약 가능한 구조(작업 메모, 파일 경로 참조, 결정 사항 리스트)에 두면 살아남습니다. 긴 작업을 하는 사람일수록 프롬프트보다 메모 구조가 더 중요해집니다.

마지막으로 표준화는 개인 생산성에서 팀 생산성으로 넘어가는 장치입니다. 혼자 잘하는 요령은 오래가기 어렵고, 플러그인/SDK는 그 요령을 팀의 기본값으로 만듭니다. “나는 잘 쓰는데 팀은 못 따라온다”는 문제는 의외로 표준화의 부재에서 시작하는 경우가 많습니다.

7. 실용 가이드 (How to Use)

시작하기: 15분 루틴(초보용)

지금 당장 할 수 있는 가장 짧은 루틴을 제안합니다. 스코프를 정하고, 목표를 1문장으로 쓰고, Done을 2~3개(테스트/커맨드/출력 기준)로 만들어 두는 것부터 시작합니다. 그 다음에는 “코드 수정하지 말고 관련 파일/흐름부터 찾아줘”라고 요청해 탐색을 먼저 하고, 가장 안전한 1개 변경만 골라 패치한 뒤 실행/테스트로 닫습니다. 이 루틴은 화려하지 않지만, 가장 실패가 적고 꾸준히 쌓이는 방식입니다.

바로 복사해서 쓰는 프롬프트 4개(복붙용)

아래 프롬프트는 정답 문장이라기보다, 입력 최소화와 탐색 우선, 닫힌 루프를 습관으로 만들기 위한 형식입니다. 상황에 맞게 {}만 바꿔 쓰셔도 충분합니다.

템플릿 A — 수정 금지, 먼저 탐색

“이 레포에서 {문제/키워드}와 관련된 코드를 찾아서 (1) 핵심 파일 3~5개 (2) 데이터/호출 흐름 (3) 변경 위험 포인트를 요약해줘. 코드는 아직 수정하지 말고, 다음 액션 플랜을 먼저 제안해.”

템플릿 B — 가장 안전한 1개 변경만 PR 단위로

“방금 플랜 중에서 가장 리스크 낮은 1개 변경만 골라서 구현해줘. 범위는 {파일/모듈}로 제한하고, 필요한 테스트도 같이 추가해.”

템플릿 C — 재현/테스트로 닫힌 루프 만들기

“이 문제가 재현되는 최소 테스트(또는 스크립트)를 먼저 추가해줘. 지금은 실패(red)해야 하고, 패치 후에는 통과(green)해야 해. 실행 커맨드도 적어줘.”

템플릿 D — 커맨드 실행까지 포함(실수 방지)

“다음 작업은 로컬에서 커맨드 실행이 필요해. 내가 실행할 커맨드를 단계별로 제시하고, 각 단계에서 예상 출력/실패 케이스/되돌리는 방법을 함께 적어줘.”

Best Practices: 한 장 체크리스트

• 입력(토큰): 마크다운 우선, 범위 지정, 목차+링크+질문 패턴
• 컨텍스트: 작업 메모 유지, 파일 경로 참조, 5줄 요약 루틴
• 루프: 작게-자주-검증(재현→패치→테스트)
• 표준화: 반복은 플러그인/SDK로 묶어서 “설치 가능한 기본값”으로

주의사항: 초보가 많이 망하는 지점

긴 문서/로그를 통째로 붙여넣거나, Done 정의 없이 “일단 만들어줘”로 시작하면 왕복이 늘어납니다. 한 번에 목표를 여러 개 섞는 것도 흔한 실패 패턴이고, 검증 없이 “된 것 같음”으로 끝내면 재현 불가와 회귀로 돌아옵니다. Claude Code는 속도를 올려주는 도구이지만, 검증을 생략하는 도구는 아닙니다.

미니 FAQ(초보가 자주 묻는 3가지)

Q1. 프롬프트를 길게 써야 더 잘하나요?

대체로 반대입니다. 길게 쓰는 건 정보를 많이 준다기보다 잡음을 같이 주는 경우가 많습니다. 목표/제약/재현/Done만 짧게 주고 나머지는 파일 경로로 참조시키는 편이 더 잘 됩니다.

Q2. Claude Code가 자꾸 엉뚱한 데를 고치려 해요.

대부분 스코프가 넓거나 Done이 모호해서 그렇습니다. “수정 금지, 먼저 탐색” 템플릿으로 시작하고 “가장 안전한 1개 변경만”으로 좁히면 성공률이 올라갑니다.

Q3. 플러그인/SDK는 언제부터 하면 좋아요?

처음부터 할 필요 없습니다. 15분 루틴이 3~5번 반복돼서 내가 매번 하는 행동이 보이면 그때가 플러그인/SDK 타이밍입니다. 반복이 보일 때 표준화하는 게 가장 효율적입니다.

8. 결론 (Conclusion): Claude Code는 ‘프롬프트’보다 ‘운영’에서 체감이 갈립니다

Claude Code를 잘 쓰는 핵심은 프롬프트가 아니라 운영입니다. 문서는 마크다운으로 받아 토큰을 줄이고 반복을 늘리고, 컨텍스트는 요약 가능한 구조로 유지해 장기 작업을 버티며, 반복은 플러그인/SDK로 표준화해 개인의 요령을 팀의 기본값으로 만들어야 합니다. 결국 “덜(낭비) 쓰고 더(검증/반복) 많이” 쓰는 쪽이, 장기적으로 더 빠르게 끝냅니다.

오늘부터 하나만 해본다면, “검증 가능한 Done(테스트/커맨드)”을 먼저 적고 시작해 보세요. 그 다음 단계는, 일주일에 두 번 이상 반복하는 루틴 1개를 골라 슬래시 커맨드나 플러그인으로 묶는 것입니다. 그렇게 하면 ‘잘 쓰는 사람의 요령’이 아니라 ‘내가 매일 쓰는 시스템’이 됩니다.

마지막으로, 리트머스는 AI·바이브코딩 기반 실전 외주개발에 강점을 가진 팀으로, 기획 단계에서 요구사항을 빠르게 구조화하고 개발 과정에서는 검증 가능한 산출물과 자동화된 품질 프로세스로 속도와 정확도를 함께 끌어올립니다. Claude Code 같은 최신 워크플로우를 실제 프로젝트에 맞게 적용해 “끝까지 완주”하는 개발 프로세스를 만들고 싶다면, 아래 문장부터 시작하셔도 좋습니다. 지금 바로 리트머스에 문의해 보세요! 무료 견적 상담을 요청하시면 바로 안내드리겠습니다.

그런데 여기서 한 가지가 더 남습니다. “좋은 도구를 찾았다”와 “좋은 결과가 나온다” 사이에는 생각보다 큰 간극이 있습니다. Claude Code든 어떤 AI 코딩 도구든, 결국 성과를 가르는 건 도구 자체가 아니라 ‘습관’이거든요. 오늘 글이 ‘운영 원칙’의 큰 그림이었다면, 아래 글은 그 원칙을 내 업무에 붙이는 방법을 더 구체적으로 정리해둔 글입니다.

AI 코딩 잘하는 법: 지금부터 익혀야 할 개발자의 7가지 습관
↘︎https://litmers.com/blog/ai-코딩-잘하는-법-지금부터-익혀야-할-개발자의-7가지-습관