Claude Code 45 tips 2026 ykdojo repo 적용 순서와 안전 체크리스트

Claude Code 팁 글은 많다.

하지만 진짜 문제는 팁의 개수가 아니다.

어떤 팁을 먼저 적용하고, 어떤 팁은 실험실에만 두고, 어떤 팁은 팀 repo에 넣으면 안 되는지 가르는 일이다.

ykdojo의 claude-code-tips repo는 그래서 흥미롭다.

제목 그대로 Claude Code를 더 잘 쓰기 위한 45개 팁을 모은 저장소다.

status line, voice input, context compaction, Git worktree, container, CLAUDE.md와 skills와 slash commands와 plugins의 차이, approved commands audit, background subagents, dx plugin, setup script까지 넓게 다룬다.

원 Threads 요약에는 74일 연속 사용, 4,100회 대화, 1,760만 token 같은 수치가 보인다.

실제 GitHub README의 /stats 예시에도 17.6m tokens, 4.1k sessions, current streak 74 days 같은 사용량이 나온다.

그러니 이 repo는 가벼운 팁 모음이라기보다 heavy user의 작업 루틴 노트에 가깝다.

그런데 바로 여기서 조심해야 한다.

heavy user의 팁은 초보자에게는 약이 되기도 하고, 팀 운영자에게는 과한 권한 설정이 되기도 한다.

재미있다고 전부 켜면 Claude Code가 빨라지는 게 아니라 내 작업환경이 무슨 자동화 박람회처럼 변한다.

구경은 즐거운데 나중에 어디서 소리가 나는지 모르는 상태가 된다.

이 글은 45개 팁을 하나씩 번역하는 글이 아니다.

TECHTAEK식으로 “어떤 팁부터 적용할까”, “어떤 팁은 개인 실험에만 둘까”, “어떤 팁은 팀 repo에 넣기 전에 검토가 필요할까” 를 나누는 운영 체크리스트다.

결론 먼저

Claude Code 45 tips를 적용할 때 내 기준 순서는 이렇다.

순서	먼저 볼 것	이유
1	status line과 `/usage`	내 context와 사용량을 봐야 다음 판단이 가능하다
2	task 쪼개기와 test cycle	자동화보다 실패 단위를 줄이는 게 먼저다
3	context compaction과 CLAUDE.md 정리	token 낭비와 지시 오염을 줄인다
4	Git worktree와 draft PR	병렬 작업을 하되 git 경계를 만든다
5	verification 루틴	AI output을 믿는 대신 증거를 본다
6	approved commands audit	위험 command 자동 승인을 줄인다
7	container 실험	장기 위험 작업은 격리한다
8	dx plugin과 setup script	마지막에만, 읽고 나서 설치한다

요약하면 이렇다.

Claude Code를 잘 쓰는 첫 단계는 더 많은 자동화가 아니다.

내가 지금 얼마나 많은 context와 권한을 열어뒀는지 보는 것이다.

그 다음에 worktree, container, subagent, MCP, plugin을 붙여야 한다.

순서를 바꾸면 손은 빨라지는데 운영은 느려진다.

이건 묘하게 억울하다.

하지만 자동화 세계에서는 자주 있는 일이다.

빠른 길이 가끔 가장 긴 길이다.

이 repo가 유용한 이유

ykdojo repo가 좋은 이유는 팁이 실제 사용자의 루틴에서 나왔다는 점이다.

README는 Claude Code를 단순한 코드 생성기가 아니라 긴 작업을 함께 하는 terminal coworker처럼 다룬다.

예를 들어 Tip 0은 status line이다.

model, current directory, git branch, uncommitted files, origin sync 상태, context usage를 아래 줄에 보여준다.

이건 사소해 보이지만 Claude Code를 오래 쓰면 꽤 중요하다.

AI coding agent에서 가장 흔한 실패는 “모델이 멍청해졌다”가 아니다.

사실은 context가 너무 낡았거나, branch가 꼬였거나, 작업 단위가 너무 커졌거나, 사용량을 못 보고 밀어붙인 경우가 많다.

status line은 이런 문제를 눈에 보이게 만든다.

Tip 5와 Tip 8은 context를 신선하게 유지하라는 쪽이다.

Tip 16은 Git worktree로 병렬 branch 작업을 하라는 쪽이다.

Tip 21은 long-running risky task를 container에서 돌리는 쪽이다.

Tip 33은 approved commands를 감사하라는 쪽이다.

이 조합을 보면 저장소의 핵심 메시지는 생각보다 건전하다.

Claude Code를 무작정 믿어라가 아니다.

오히려 작업 단위를 나누고, context를 관리하고, git 경계를 만들고, 권한을 감사하라는 말에 가깝다.

그래서 TECHTAEK 독자에게도 쓸 만하다.

다만 그대로 다 따라 하면 안 된다.

각 팁의 위험도가 다르다.

45개 팁을 5개 그룹으로 나누기

45개를 하나씩 보면 많다.

운영 관점에서는 다섯 그룹으로 나누면 된다.

그룹	대표 팁	먼저 적용해도 되나
관찰	status line, `/usage`, `/stats`	좋다
작업 단위	작은 문제로 쪼개기, write-test cycle, draft PR	좋다
context 관리	compact, CLAUDE.md 단순화, half-clone	조심해서 좋다
격리와 권한	worktree, container, approved commands audit	필요할수록 좋다
확장	plugins, setup script, MCP companion	마지막에 검토

이렇게 나누면 바로 실행할 것과 잠깐 보류할 것이 보인다.

status line은 대부분 안전하다.

사용량을 보는 명령도 안전하다.

작업을 작게 쪼개는 것도 안전하다.

테스트를 먼저 만들게 하는 것도 안전하다.

반대로 container 안에서 --dangerously-skip-permissions를 쓰는 흐름, setup script를 curl | bash 형태로 실행하는 흐름, plugin을 설치해 slash command와 skills를 추가하는 흐름은 좋은 도구일 수 있지만 바로 팀 표준으로 삼으면 안 된다.

먼저 읽어야 한다.

어떤 파일을 바꾸는지 봐야 한다.

어떤 permission을 여는지 봐야 한다.

업데이트와 rollback 방법을 봐야 한다.

이 한 박자가 중요하다.

AI 도구는 설치보다 제거가 어려울 때가 많다.

공식 Claude Code 확장 구조로 다시 보기

Claude Code 공식 문서는 확장 기능을 역할별로 나눈다.

CLAUDE.md는 항상 들어가는 project context.

Skills는 필요할 때 쓰는 지식과 workflow.

MCP는 외부 service와 tool 연결.

Subagents는 별도 context에서 도는 작업자.

Hooks는 agent loop 밖에서 도는 결정적 자동화.

Plugins는 이런 요소들을 패키징하는 방식이다.

ykdojo repo의 Tip 25도 CLAUDE.md, Skills, Slash Commands, Plugins 차이를 이해하라고 한다.

이 둘을 합치면 기준이 깔끔하다.

내가 하려는 일	먼저 볼 Claude Code 구조	ykdojo 팁에서 연결되는 부분
매번 봐야 하는 팀 규칙	CLAUDE.md	Tip 30
반복 가능한 절차	Skills	Tip 25, dx plugin
자주 쓰는 명령	Slash Commands	Tip 1, Tip 44
외부 도구 연결	MCP	Tip 1, Tip 27
병렬 조사나 검증	Subagents	Tip 36
실행 전후 자동 검사	Hooks	approved command audit와 함께 봐야 함
여러 요소 묶음 배포	Plugin	Tip 44, Tip 45

중요한 건 하나의 문제를 모든 확장 기능으로 풀지 않는 것이다.

프로젝트 규칙이면 CLAUDE.md.

반복 절차면 skill.

외부 도구면 MCP.

분리된 작업자면 subagent.

실행 게이트면 hook.

이렇게 나눠야 context가 덜 망가진다.

다 섞으면 처음엔 편하다.

나중엔 디버깅이 집안 대청소가 된다.

마음은 알아.

근데 대청소는 주말에만 해도 충분히 피곤하다.

먼저 적용할 7개

45개 중 내가 먼저 권하는 건 7개다.

1. Status line

context usage, branch, uncommitted files, sync 상태를 보이게 만드는 것부터 시작한다.

이건 거의 모든 사용자에게 이득이다.

Claude Code를 오래 쓰면 내가 어느 branch에 있는지, 얼마나 context를 썼는지, 작업 파일이 남아 있는지 모르는 순간이 온다.

status line은 그 순간을 줄인다.

AI 작업의 첫 번째 안전장치는 멋진 prompt가 아니라 현재 상태를 보는 화면이다.

2. 작은 작업으로 쪼개기

Tip 3의 핵심은 전통적인 software engineering과 같다.

큰 문제를 작은 문제로 나눈다.

Claude Code가 큰 문제를 한 번에 못 풀면 모델을 탓하기 전에 task size를 줄인다.

이건 정말 기본인데 가장 자주 까먹는다.

“이거 다 해줘”는 편하다.

하지만 좋은 agent workflow는 “1단계만 고치고 테스트해줘”에서 시작하는 경우가 많다.

3. Write-test cycle

Tip 9의 방향도 좋다.

Claude Code에게 코드를 쓰게 할 거라면 검증 루프도 같이 줘야 한다.

write, test, fix, explain.

이 네 박자가 없으면 AI 코딩은 빨라 보이다가 마지막에 수동 디버깅 청구서가 날아온다.

4. Context compaction

Tip 8과 Tip 5는 context가 낡기 전에 정리하라는 이야기다.

긴 대화가 항상 좋은 것은 아니다.

오래된 대화에는 틀린 가정, 끝난 작업, 바뀐 요구사항, 필요 없는 로그가 섞인다.

중간중간 compact하거나 handoff 문서를 만들고 새 session으로 넘어가는 습관이 낫다.

여기서 중요한 건 대화를 줄이는 게 아니라 현재 작업에 필요한 근거만 남기는 것이다.

5. Git worktree

Tip 16은 팀 작업에 특히 유용하다.

동시에 여러 branch를 만질 때 한 working tree에서 싸우지 말고 worktree로 분리한다.

Claude Code에게도 이 구조는 좋다.

한 session은 bugfix.

다른 session은 docs.

또 다른 session은 experiment.

이렇게 분리하면 agent가 파일을 섞어 만지는 위험이 줄어든다.

단, worktree가 많아질수록 정리 규칙도 필요하다.

끝난 worktree는 지우고, branch 이름은 규칙 있게 만들고, PR 단위로 닫아야 한다.

6. Verification 방법 여러 개

Tip 28은 아주 중요하다.

Claude Code output을 검증하는 방법은 하나가 아니다.

test, diff review, draft PR, GitHub Desktop 같은 visual diff, manual spot check, preflight script를 섞어야 한다.

내 기준으로는 Claude Code가 코드를 바꾸는 순간 반드시 둘 이상 검증 루트가 있어야 한다.

test만 믿지 않는다.

눈검토만 믿지도 않는다.

둘을 섞는다.

사람도 실수하고 test도 비는 곳이 있으니 서로 감시하게 만든다.

7. Approved commands audit

Tip 33은 꼭 봐야 한다.

Claude Code를 오래 쓰면 편해서 승인한 command가 쌓인다.

처음에는 git status였다.

다음에는 npm test.

그 다음에는 조금 더 넓은 bash pattern.

그리고 어느 날 무서운 command가 조용히 지나갈 수 있다.

approved commands는 주기적으로 봐야 한다.

특히 rm, sudo, chmod, curl | bash, deploy, push, kubectl, terraform apply 같은 계열은 자동 승인을 피하는 편이 좋다.

이건 겁먹자는 얘기가 아니다.

승인 피로를 줄이되 사고 비용이 큰 command만 남겨두자는 얘기다.

보류하고 읽어야 할 4개

좋지만 바로 적용하면 위험한 팁도 있다.

1. System prompt 줄이기

Tip 15는 흥미롭다.

README는 Claude Code의 system prompt와 tool definitions가 큰 context overhead를 만들고, patch로 줄일 수 있다고 설명한다.

하지만 이건 개인 실험과 팀 표준을 나눠야 한다.

개인 machine에서 원리를 배우는 건 좋다.

그러나 팀 운영 환경에서 Claude Code 내부 prompt나 tool definitions를 무리하게 patch하는 것은 업데이트 충돌, 지원 범위 이탈, 예상치 못한 tool behavior를 만들 수 있다.

따라서 이 팁은 “공식 설정과 context discipline으로 overhead를 줄이자”는 방향으로 읽는 게 더 안전하다.

CLAUDE.md를 줄이고, 불필요한 MCP server를 빼고, skills를 필요한 순간에만 쓰고, subagent output을 짧게 받는 쪽이 먼저다.

2. Container에서 위험 작업 돌리기

Tip 21은 long-running risky task를 container에서 돌리는 쪽이다.

방향은 맞다.

격리 환경은 필요하다.

하지만 container가 안전을 자동 보장하지는 않는다.

mount를 넓게 열면 host data가 노출된다.

secret을 넘기면 container 안에서도 secret이다.

network를 열면 외부 호출도 가능하다.

따라서 container는 “권한을 생략해도 되는 공간”이 아니라 “권한을 좁게 다시 설계한 공간”으로 봐야 한다.

3. Background commands와 subagents

Tip 36은 long-running bash command와 subagents를 background로 돌리는 흐름이다.

작업량이 많으면 아주 유용하다.

하지만 background 작업은 끝났는지, 실패했는지, 어떤 로그를 남겼는지 놓치기 쉽다.

Claude Code 공식 docs도 subagent와 hooks, tools, MCP를 꽤 세밀하게 나눈다.

background subagent를 쓸 때는 max turns, allowed tools, output summary, log path, stop condition을 같이 정해야 한다.

그냥 “뒤에서 해줘”라고 맡기면 뒤에서 정말 여러 가지를 한다.

여러 가지가 늘 좋은 건 아니다.

4. dx plugin과 setup script

Tip 44와 Tip 45는 dx plugin과 quick setup script다.

이런 bundle은 편하다.

slash commands와 skills를 한 번에 받을 수 있다.

하지만 plugin과 setup script는 내 Claude Code 환경을 바꾼다.

따라서 설치 전에 최소한 이 세 가지를 봐야 한다.

어떤 파일을 쓰는가.

어떤 settings를 바꾸는가.

어떤 commands와 permissions를 추가하는가.

특히 curl로 script를 바로 실행하는 방식은 읽고 나서 실행하는 습관을 들이는 게 좋다.

귀찮지만 내 개발 환경은 남의 빠른 설치 한 줄보다 비싸다.

개인용과 팀용을 나누는 표

같은 팁도 개인용이면 괜찮고 팀용이면 위험할 수 있다.

팁	개인용	팀 repo 공통
status line	바로 가능	각자 선택
slash command 학습	바로 가능	문서화만
worktree 사용	추천	branch/worktree naming 필요
compact 습관	추천	handoff template 필요
CLAUDE.md 단순화	추천	review 필수
skills 추가	실험 가능	skill 구조와 검증 필요
MCP 추가	조심	owner, scope, credential 정책 필요
hooks 추가	조심	실패 모드와 disable 방법 필요
subagents 추가	조심	tools, model, max turns, memory 범위 필요
plugin 설치	실험 가능	lock/version/review 필요
setup script	읽고 실행	기본 금지, 필요 시 내부 fork

팀에서 제일 위험한 것은 “내가 써보니 좋더라”가 곧장 공통 설정이 되는 것이다.

좋은 팁도 팀 전체에 적용되면 운영 계약이 된다.

운영 계약은 누가 유지하고, 누가 되돌리고, 누가 사고를 설명할지까지 정해야 한다.

그게 귀찮다면 아직 개인 설정으로 두는 게 맞다.

내 작업흐름에 붙이는 최소 버전

내가 오늘 ykdojo repo에서 바로 가져온다면 최소 버전은 이렇다.

/usage와 status line으로 사용량을 보이게 한다.
CLAUDE.md를 줄이고, 오래된 지시를 지운다.
큰 작업은 1시간 이하 단위로 쪼갠다.
코드 변경 작업에는 test command를 반드시 붙인다.
동시에 두 작업 이상이면 Git worktree를 쓴다.
draft PR이나 diff review를 검증 루트로 둔다.
approved commands를 감사한다.
MCP server는 필요한 것만 켠다.
container는 risky task에만 쓰고 mount를 좁힌다.
plugin과 setup script는 읽고 나서 별도 branch에서 실험한다.

이 정도면 팁의 좋은 부분은 가져오고 위험한 부분은 뒤로 미룰 수 있다.

너무 얌전해 보일 수 있다.

하지만 Claude Code 운영에서는 얌전한 시작이 오래 간다.

처음부터 다 켜는 건 냉장고 정리하다가 갑자기 주방 리모델링 들어가는 느낌이다.

정신 차리면 바닥 타일을 고르고 있다.

FAQ

ykdojo의 45 tips를 그대로 따라 해도 되나?

개인 실험이라면 일부는 바로 따라 해도 된다.

하지만 팀 설정, MCP, hooks, plugins, setup script, 권한 자동승인은 바로 공통화하지 않는 편이 좋다.

먼저 어떤 파일과 권한이 바뀌는지 봐야 한다.

가장 먼저 적용할 팁 하나만 고르면?

status line과 /usage다.

현재 model, branch, uncommitted files, context usage를 보는 습관이 생기면 나머지 최적화 판단이 쉬워진다.

Claude Code context를 줄이려면 system prompt patch부터 해야 하나?

아니다.

대부분은 CLAUDE.md 정리, 불필요한 MCP server 제거, 작업 단위 축소, compact와 handoff만으로도 먼저 좋아진다.

내부 prompt patch는 개인 실험으로 보고 팀 표준에서는 조심해야 한다.

Container를 쓰면 위험 command를 자동 승인해도 되나?

항상 그렇지는 않다.

container는 격리 계층이지 만능 방탄복이 아니다.

mount, network, secret, output path를 좁힌 뒤에야 위험 command 자동화를 검토할 수 있다.

dx plugin은 설치해도 되나?

관심 있으면 별도 실험 환경에서 먼저 보는 게 좋다.

어떤 slash commands, skills, settings를 추가하는지 확인하고, 팀에서는 version 고정과 rollback 방법을 정한 뒤 적용하는 편이 안전하다.

이 글은 기존 Claude Code 운영 허브와 뭐가 다른가?

기존 허브는 TECHTAEK에 이미 발행된 Claude Code 글을 읽는 순서다.

이 글은 ykdojo의 45개 팁을 내 환경에 적용할 때 무엇부터 켜고 무엇을 보류할지 가르는 적용 순서표다.

참고 자료

마무리

Claude Code 45 tips는 좋은 도구 상자다.

하지만 좋은 도구 상자도 한 번에 다 꺼내면 책상이 난리가 난다.

먼저 봐야 할 것은 내 작업 상태다.

context가 얼마나 찼는가.

어느 branch에 있는가.

검증 루프가 있는가.

위험 command가 자동 승인되어 있지 않은가.

그 다음에 worktree, container, subagent, MCP, plugin을 붙이면 된다.

Claude Code를 잘 쓰는 사람의 공통점은 팁을 많이 아는 것이 아니다.

작업 단위를 줄이고, 권한을 좁히고, 검증을 남기고, 필요한 순간에만 확장하는 것이다.

ykdojo repo의 진짜 가치는 45개 팁 자체보다 그 팁들을 통해 드러나는 운영 감각에 있다.

따라서 내 결론은 이렇다.

먼저 관찰하라.

그 다음 작게 나눠라.

그 다음 검증하라.

마지막에 자동화하라.

이 순서만 지켜도 Claude Code는 훨씬 덜 위험하고 훨씬 더 오래 쓸 수 있는 도구가 된다.

Claude Code 45 tips는 어디부터 적용해야 하나 2026 – ykdojo repo로 보는 context·worktree·container·dx 안전 체크리스트