Claude Code 1,000시간 사용으로 배운 실전 워크플로

URL: https://www.youtube.com/watch?v=usiK-qjjCKs
날짜: 2026-08-23
채널: Tech Bridge
영상 ID: usiK-qjjCKs
재생 시간: 약 21분 7초
원문 언어: 영어(한국어 자막 제공)
처리 유형: YouTube 심층 다이제스트

메타데이터

• 원문 제목: [한영자막] Claude Code와 1000시간 넘게 함께하며 배운 것들
• 핵심 주제: Claude Code, 코딩 에이전트(Coding Agent), 스킬(Skill), MCP(Model Context Protocol), 컨텍스트 관리(Context Management), 검증(Verification), 자동화(Automation)
• 분류: AI·LLM / 개발·엔지니어링
• 원본 업로드일: 2026-08-23
• 자막 처리: 한국어 자동 자막을 우선 시도했으나 요청 과정에서 HTTP 429가 발생해 영어 자동 자막을 전체 추출한 뒤 한국어로 번역·정리함
• 영상 설명의 관련 링크:
  • https://github.com/DietrichGebert/ponytail
  • https://github.com/rtk-ai/rtk
  • https://caveman.so/
  • https://www.skills.sh/
  • https://slothbytes.beehiiv.com/subscribe
  • https://tally.so/r/mZVvKa
  • https://twitter.com/TheCodingSloth1
  • https://www.tiktok.com/@thecodingsloth
  • https://discord.gg/2ByMHqTNca
  • https://app.codecrafters.io/join?via=TheCodingSloth
  • https://www.beehiiv.com?via=the-coding-sloth

---

📌 핵심 질문 / Claude Code를 오래 쓸수록 무엇을 다르게 해야 하는가

==Claude Code의 성능은 모델 자체보다 프로젝트 맥락을 정리하고, 작업을 계획하고, 결과를 검증하며, 토큰과 컨텍스트를 아끼는 사용 습관에 크게 좌우된다.==

• $20 요금제에서도 프롬프트를 한두 번 보낸 뒤 사용량 제한에 걸려 3시간을 기다리는 일이 생기므로, 토큰을 낭비하지 않는 운영이 필수다.
• CLAUDE.md, 스킬, 계획 모드, MCP, 검증, 새 세션, 작업 트리(worktree)를 조합하면 코드 에이전트가 더 일관되고 안전하게 일한다.
• AI에게 코드를 맡기더라도 코드를 읽고 테스트·타입·린트 결과를 판단할 능력은 남겨야 한다. 코딩 지식이 있어야 정확한 프롬프트와 검증 기준을 만들 수 있고, AI가 만든 결과를 자기 프로젝트에 책임 있게 적용할 수 있다.
• Claude Code의 핵심 개념은 Codex, OpenCode, Cursor, Pi, GitHub Copilot, T3 Code 같은 다른 에이전트에도 대부분 옮겨 갈 수 있다.

Claude Code는 반복 가능한 지식은 스킬로, 외부 시스템과의 접점은 MCP로, 큰 작업의 의사결정은 계획 모드로, 결과의 신뢰성은 검증으로 분리할 때 가장 효율적으로 작동한다. 모델이 모든 것을 알아서 하게 두기보다 필요한 정보만 주고, 별도 세션과 격리된 작업 공간에서 작은 단위로 확인하는 방식이 비용과 품질을 함께 지킨다.

1. 1,000시간 사용에서 얻은 출발점

1.1. 사용량 제한이 만드는 현실적인 제약

1. 짧은 대화만으로도 제한에 걸리는 요금제

   1. $20 플랜의 한계: $20 요금제로 프로그래밍하면서 프롬프트를 한두 번 보냈을 뿐인데 사용량 제한에 걸리는 일이 있었다.
   2. 3시간 대기: 인사 한마디를 건네자마자 제한이 소진되어 3시간을 기다려야 하는 식의 경험이 반복됐다.
   3. 모델 이름을 둘러싼 농담: 당시 새로 나온 모델을 “Claude fable”이라고 부르며 제한 문제를 비꼬았고, 관객의 웃음이 터졌다. 한 달 전에 촬영한 장면이라 모델과 기능이 이미 달라졌을 수 있다는 편집자 코멘트도 붙었다.

2. 비용과 사용량의 균형

   1. 비싼 상위 요금제 거부감: $100을 매달 내고 싶지 않으며, 그 돈이면 차라리 McDonald’s를 사 먹겠다는 농담으로 비용 부담을 표현했다.
   2. 상위 플랜도 무제한이 아님: $20 플랜 사용자뿐 아니라 $100·$200 플랜 사용자도 토큰과 컨텍스트를 관리해야 한다.
   3. 사용법을 배울 시간 자체가 필요함: 결과가 좋은 사람들은 더 똑똑한 모델만 쓰는 것이 아니라 도구를 제대로 사용할 충분한 시간을 확보하고 있을 가능성이 크다. 제한에 너무 빨리 걸리면 좋은 워크플로를 익힐 기회도 사라진다.

1.2. Claude Code의 위치와 학습 가치

1. 터미널에서 작동하는 코딩 특화 Claude

   1. 기본 정의: Claude를 코딩에 특화하고 터미널에서 실행하는 도구다.
   2. IDE 선호: 터미널보다 실제 IDE와 에이전트 인터페이스가 결합된 형태를 선호한다. 버튼을 눌러 조작할 수 있고 결과가 시각적으로 보여야 편하다는 이유다.
   3. 자기 비하 유머: 시각적 요소를 좋아하는 자신을 “나는 유아(toddler) 같다”고 표현하며 터미널보다 IDE를 선호하는 취향을 웃음으로 풀었다.
   4. 접근 경로 확대: Claude Code는 터미널뿐 아니라 IDE와 웹에서도 사용할 수 있다.

2. 기업과 채용 시장이 요구하는 도구

   1. 광범위한 사용: 일반 개발자뿐 아니라 대형 기술 기업과 거의 모든 사람이 사용하고 있다.
   2. Uber 사례 언급: 기업이 코딩 에이전트를 과도하게 사용하는 사례로 Uber를 거론했다.
   3. 빠른 매출 성장: Claude Code가 출시 후 6개월 만에 약 10억 달러 규모를 만들었다는 점을 언급했고, 이 성공이 다른 AI 회사들이 비슷한 도구를 복제하게 만든 배경이 됐다.
   4. 기업의 교육 논리: 회사들은 이런 도구를 배워 차세대 엔지니어가 되라고 권한다. 그만큼 더 많은 업무를 맡기려는 계산도 있지만, 비용이 너무 커서 모든 기업의 도입이 순조롭게만 진행된 것은 아니다.
   5. 작은 보상과 구독 홍보: 무료 스티커를 받았다는 이야기를 곁들이고, 이메일을 남기면 무료 프로그래밍 조언과 뉴스를 보내 주는 뉴스레터를 홍보했다.

3. Claude Code를 배워야 하는 이유와 한계

   1. 추천 여부: 취업 가능성을 높여 준다면 사용법을 배울 가치가 있다고 판단한다.
   2. 한계의 전제: 사용량 제한에 걸리기 전까지는 편리하지만, 제한에 걸리는 순간 작업 흐름이 끊긴다.
   3. 개념의 이식성: 스킬·계획·검증·서브 에이전트 같은 개념은 특정 제품에 종속되지 않아 다른 코딩 에이전트에도 적용된다.
   4. 비후원 비교: 특정 제품의 후원을 받지 않는 입장이므로 Claude Code만 고집할 이유가 없고, 여러 대안을 함께 비교할 수 있다.

2. 프로젝트 맥락을 저장하는 방법

2.1. /init과 CLAUDE.md의 역할과 등급

1. 첫 프로젝트에서 실행하는 초기화 명령

   1. 작동 방식: 프로젝트를 처음 열고 /init을 실행하면 Claude가 코드베이스 전체를 살펴보고 CLAUDE.md 파일에 내용을 정리한다.
   2. 영구 메모리: CLAUDE.md는 프로젝트의 영구적인 기억처럼 작동하며, 이후 대화에서 반복해서 참고할 맥락을 보관한다.
   3. 초기 평가: 경험상 /init 자체는 C 또는 D 등급으로 평가할 만큼 자주 사용하지 않는다. 기능의 존재만으로 결과가 획기적으로 좋아지지는 않는다.

2. 파일 포맷 호환성 문제

   1. AGENTS.md와의 차이: 다른 AI 에이전트는 같은 목적의 파일을 AGENTS.md에 저장하는 경우가 많지만 Claude만 CLAUDE.md를 사용한다.
   2. 불편한 독자 포맷: 여러 도구를 함께 쓰는 사람에게 Claude만 별도 파일을 요구하는 것은 매우 번거롭다.
   3. 파일 가져오기: CLAUDE.md 안에서 다른 파일을 import할 수 있으므로 AGENTS.md를 심볼릭 링크(symlink)로 복제하지 않고도 내용을 불러올 수 있다.

3. 실험적 인터뷰 모드

   1. 환경 변수 활성화: 환경 플래그를 켜면 /init의 실험 버전을 사용할 수 있다.
   2. 코드 분석에서 사용자 인터뷰로 변화: 기존처럼 코드베이스만 분석해 파일을 쓰는 대신 사용자에게 프로젝트에 관해 질문한다.
   3. 스킬과 훅 추천: 인터뷰 결과를 바탕으로 필요한 스킬과 훅(hook)을 추천한다.
   4. 최종 판단: 실험 버전에는 잠재력이 있지만, 한 달 뒤 다시 평가해도 “그저 그렇다(mid)”는 의견은 그대로였다.

2.2. 직접 관리하는 CLAUDE.md의 내용

1. 장기 사용으로 발견한 모델의 습관

   1. 슬롭 코드(sloppy code): 모델이 만든 엉성한 코드를 몇 달 동안 다루면 각 모델의 기이한 습관과 반복되는 실수를 파악하게 된다.
   2. 파일의 성격: CLAUDE.md는 완성된 헌법이 아니라 프로젝트가 변하면서 계속 바뀌는 작업 문서다.
   3. 필수 여부: 파일이 없다고 프로젝트를 운영할 수 없는 것은 아니다. 스킬만으로 같은 목적을 달성하거나 더 나은 결과를 얻을 때도 있다.

2. 실제로 기록하는 프로젝트 맥락

   1. 프로젝트 개요: 프로젝트가 무엇인지 빠르게 이해할 수 있는 설명을 넣는다.
   2. 현재 상태: 구현된 것, 진행 중인 것, 다음에 해야 할 일을 기록한다.
   3. 코딩 스타일: 선호하는 구조·명명·구현 방식 등 개인적인 코딩 스타일을 명시한다.
   4. 작업 철학: 모델이 판단할 때 따를 수 있는 “working philosophy”를 실험적으로 추가하고 있다.

3. 구체적인 규칙의 예시

   1. 사용자에게 보이는 문구의 대소문자: AI 모델은 디자인을 만들 때 대문자만 쓰는 것을 유난히 좋아하는데, 이유를 알 수 없고 보기에도 좋지 않다고 지적한다.
   2. 사용자 지향 대소문자 규칙: 이런 무차별 대문자 사용을 막기 위해 user-facing 텍스트의 capitalization 규칙을 CLAUDE.md에 적는다.
   3. Pull Request 언어: PR을 어떤 언어와 형식으로 작성할지도 규칙으로 설정해 실험하고 있다.
   4. 유연한 유지: 모든 규칙을 영구 고정하기보다 실제 결과를 보며 파일을 계속 조정한다.

3. 반복 가능한 지식을 스킬로 분리하기

3.1. 스킬의 개념과 기본 제공 스킬

1. 스킬은 재사용 가능한 Markdown 가이드

   1. 파일 형태: 스킬은 특별한 바이너리가 아니라 skill.md라는 Markdown 파일이다.
   2. 반복 업무의 절차서: 여러 번 수행하는 작업의 모범 사례(best practices), 워크플로, 조사 방법을 적어 둔다.
   3. 호출 방식: AI가 상황에 맞는 스킬을 자동으로 사용하게 하거나, 사용자가 명시적으로 사용을 지시할 수 있다.
   4. 적용 범위: 반복 가능한 워크플로라면 조사·문서화·코드 품질·요구사항 정리 등 거의 무엇이든 스킬로 만들 수 있다.

2. 기본 제공 스킬의 가치

   1. 예시: Claude Code에는 코드 리뷰(code review), 보안 리뷰(security review) 같은 기본 스킬이 설치돼 있다.
   2. 등급: 기본 스킬은 B에서 A 등급 정도로 평가하며, Claude가 기능을 구현한 뒤 적용하면 좋은 보너스가 된다.
   3. 학습 자료: 커뮤니티가 각자의 지식과 베스트 프랙티스를 한 파일에 모아 두므로, 에이전트뿐 아니라 사람에게도 유용한 학습 자료가 된다.

3.2. 스킬을 찾고 조합하는 방법

1. 검색 출발점

   1. Skills.sh: 스킬을 찾고 설치하는 첫 번째 장소로 skills.sh를 추천한다.
   2. GitHub 저장소: 여러 GitHub 저장소에도 다양한 스킬이 있다.
   3. 커뮤니티의 집단 지식: 회사와 뛰어난 엔지니어가 축적한 지식을 읽으며 다른 사람의 사고방식과 실무 습관을 배울 수 있다.

2. Matt Pocock 계열 스킬

   1. grow with doc: 요구사항을 더 명확하게 다듬도록 돕는다. 작성자의 어휘가 매우 뛰어나다며 “매일 사전을 읽는 것 같다”고 칭찬했다.
   2. 개선된 코드베이스 아키텍처 스킬: 코드베이스의 구조를 개선하는 워크플로를 제공한다.
   3. 시각 자료의 장점: 아키텍처 스킬에 보기 좋은 시각 자료가 포함된 점도 선호 이유다. 시각적인 것을 좋아하는 “유아” 취향이 다시 등장한다.

3. 코드 품질과 계획을 위한 커뮤니티 스킬

   1. Cursor의 ‘Thermonuclear Code Quality Review’: AI가 생성한 코드를 단순화해 슬롭을 줄이는 코드 품질 리뷰 스킬이다.
   2. 조합 효과: Thermonuclear 리뷰 스킬과 개선된 코드베이스 아키텍처 스킬을 동시에 사용하면 구조를 점검하면서 구현 결과도 정리할 수 있다.
   3. 코드베이스 감사·계획 스킬: 자막에서 이름이 정확히 식별되지 않은 커뮤니티 제작 “improved” 스킬도 시험하고 있다. 코드베이스를 감사한 뒤 다른 에이전트가 실행할 계획을 작성한다.
   4. 등급: 계획을 자동으로 분리하는 접근은 쉽게 S 등급이 될 만큼 좋은 아이디어라고 평가한다.

4. 스킬을 많이 설치하지 않는 원칙

   1. 과잉 설치 금지: 스킬을 100개 설치해 두고 모두 호출하는 방식은 피한다.
   2. 주관성 인식: 좋은 코드의 기준은 사람마다 다르므로 서로 충돌하는 스킬이 많으면 에이전트가 혼란스러워진다.
   3. 일관된 묶음 선택: 자신의 코딩 스타일과 맞는 하나의 스킬 그룹을 골라 일관되게 사용한다.
   4. 핵심 패턴: AI 도구 전반에서 “필요한 것만 한다”는 원칙이 반복된다.

4. 계획과 검증을 품질의 중심에 두기

4.1. Shift+Tab 계획 모드

1. 코드를 바꾸기 전에 계획하기

   1. 호출 방법: Claude Code에서 Shift+Tab을 누르면 plan mode로 들어간다.
   2. 탐색 우선: 곧바로 파일을 수정하지 않고 코드베이스를 더 꼼꼼히 읽은 뒤 전체 계획을 작성한다.
   3. 승인 절차: 계획을 먼저 보여 주므로 사용자는 실행 전에 승인하거나 거부할 수 있다.

2. 작업 크기에 따른 사용 기준

   1. 큰 작업: 여러 파일을 바꾸거나 설계 판단이 필요한 작업에 계획 모드를 사용한다.
   2. 오류 발견 비용 절감: 3,000줄의 코드와 12개 파일을 수정한 뒤 실수를 찾는 것보다 계획 단계에서 틀린 방향을 잡아내는 편이 훨씬 쉽다.
   3. 작은 작업에는 불필요: 오타 수정, 변수명 변경, 작은 디자인 변경에 plan mode를 쓰면 시간이 늘고 품질 이득이 거의 없다.
   4. 등급: Claude 계열 모델에서 반드시 써야 할 기능으로 보고 S 등급을 부여한다.

3. 고성능 모델로 계획하고 저렴한 모델로 구현하기

   1. 역할 분리: 똑똑한 모델이 계획을 만들고, 더 빠르고 저렴한 모델이 계획을 구현하는 전략이다.
   2. 저렴함과 지능은 별개: 빠른 모델이 반드시 멍청한 모델인 것은 아니다. 최근의 저비용 모델도 충분히 영리하기 때문에 이런 분업이 가능하다.
   3. Claude 안에서의 예시: 당시에는 Fable 모델을 구현에 쓰려 했지만 촬영 후 상황이 달라졌다. 실질적으로는 Opus로 계획하고 Sonnet으로 구현하는 조합을 제시한다.
   4. 제품을 섞을 수 있는 환경: Claude Code가 아닌 Cursor·OpenCode·Codex를 사용하면 제품과 모델을 더 자유롭게 섞을 수 있다.

4.2. 검증(Verification)은 최고 우선순위다

1. AI가 스스로 정답을 알지는 못한다

   1. 완료 선언의 불신: Claude는 코드가 맞는지 실제로 알지 못하면서도 “완료했다”고 말할 수 있다.
   2. 검증의 정의: 코드를 작성한 뒤 스스로 확인할 수 있는 수단을 제공해 실제로 작동하는지 검사하게 만드는 것이 검증이다.
   3. 소프트웨어 공학의 기본: 검증은 AI 전용 요령이 아니라 원래부터 좋은 소프트웨어 엔지니어링의 기본이며, AI가 코드를 대량 생성할수록 더 중요해진다.
   4. 등급: S를 넘어 더블 S, 트리플 S를 줄 수 있는 최고 등급으로 평가한다.

2. 테스트는 구현보다 먼저 작성한다

   1. 권장 순서: Claude에게 먼저 테스트를 작성하게 한 다음 구현하도록 지시한다.
   2. 뒤늦은 테스트의 함정: 구현을 먼저 시키면 에이전트가 자기 코드에 맞춰 통과하는 테스트를 작성하기 쉽다. 그런 테스트는 검증이 아니라 부정행위에 가깝다.
   3. 중요한 부분 중심: 코드의 모든 줄을 테스트할 필요는 없고, 핵심 동작과 실패 가능성이 큰 부분을 검증한다.
   4. 과잉 테스트의 부작용: 똑똑한 모델일수록 모든 것을 테스트하려 해 코드베이스를 불필요하게 부풀릴 수 있다.

3. 정적 검사와 프런트엔드 검사

   1. 타입 검사기: 언어가 지원한다면 타입 체커(type checker)를 실행해 타입 오류를 찾는다.
   2. 린터: 린터(linter)를 작업 완료 조건에 포함해 스타일과 잠재적 문제를 점검한다.
   3. 스크린샷 테스트: 프런트엔드·디자인 작업에서는 결과 화면을 캡처해 레이아웃과 시각적 문제를 확인한다.
   4. 브라우저 테스트: 에이전트가 앱을 열고 버튼을 클릭하고 화면을 돌아다니며 실제 동작을 확인하게 한다.
   5. 시각 입력의 보완: Claude는 본래 자신이 만든 화면을 볼 수 없지만, 브라우저와 스크린샷 검증을 거치면 무엇이 보이는지 확인할 수 있다. 예전에는 MCP가 필요했으나 최근 모델은 컴퓨터를 직접 사용하는 능력이 내장되기 시작했다.

5. 외부 세계와 연결하는 MCP

5.1. MCP의 역할과 등급

1. 코드베이스 밖의 도구 접근

   1. 정의: MCP(Model Context Protocol)는 Claude가 다른 도구와 서비스에 접근하도록 연결한다.
   2. 연결 대상: GitHub, 데이터베이스, Slack, 분석 도구, 배포 시스템, 브라우저 등을 연결할 수 있다.
   3. 등급 조정: 처음에는 B 등급이라고 말하려다 곧바로 “거짓말이다, A 등급”이라고 정정했다.

2. 실제 활용 예시

   1. 디자인 영감 수집: 외부 사이트에서 디자인 아이디어와 레퍼런스를 가져온다.
   2. 데이터베이스 시딩: 기능을 시험할 가짜 데이터를 데이터베이스에 넣는다.
   3. 조사·문서 확인: 외부 연구 자료와 공식 문서를 찾아 읽는다.
   4. 브라우저 테스트: 실제 배포·실행 환경을 브라우저로 조작하며 프런트엔드를 검증한다.

3. MCP와 스킬의 경계

   1. MCP가 필요한 경우: Claude가 코드베이스 외부의 무언가와 직접 상호작용해야 할 때만 MCP를 설치한다.
   2. MCP가 불필요한 경우: 베스트 프랙티스, 디자인 패턴, 구현 방법처럼 지식과 절차를 전달하는 일에는 MCP가 필요 없다.
   3. 스킬의 담당 영역: 반복 가능한 지식과 워크플로는 스킬 파일에 넣는다.
   4. 재사용 원칙: MCP도 스킬처럼 많이 설치하지 말고, 실제 작업에 필요한 연결만 남긴다.

6. 잘 알려지지 않았지만 유용한 명령

6.1. 대화와 세션을 다루는 명령

1. /voice — B 등급

   1. 사용법: /voice를 입력한 뒤 말하면 음성이 프롬프트로 변환된다.
   2. 생각을 더 자세히 말하기: 타이핑보다 말할 때 요구사항과 배경을 더 구체적으로 설명하기 쉽다.
   3. 기술 지식 유지: 무엇을 원하는지 말로 풀어내는 과정이 자신의 기술적 사고를 유지하고 정리하는 데 도움이 된다.
   4. 속도 이점: 타이핑이 느린 사람에게는 입력 속도도 빨라진다.

2. /btw — C 등급

   1. 중간 질문: 현재 작업을 중단하지 않고 진행 중인 내용에 관해 질문할 수 있다.
   2. 대화 기록 보존: 기존 대화 기록을 건드리지 않으며 현재 작업을 방해하지 않는다.
   3. 참조 범위: Claude가 이미 읽었거나 구현한 내용을 대화 기록에서 설명할 수 있다.
   4. 제한: 이 모드에서는 파일을 읽거나 명령을 실행하지 않고 대화 기록만 이용한다.

3. /teleport와 remote control — 개인 기준 C~D, 외부 활동이 많은 사람은 A

   1. 세션 이동: 휴대전화·웹·터미널 사이에서 Claude 세션을 이동할 수 있다.
   2. 생활 속 아이디어 포착: McDonald’s 드라이브스루 줄에 서 있다가 갑자기 떠오른 천재적인 아이디어를 모바일 앱에 먼저 적고, 집에 돌아와 터미널로 넘길 수 있다.
   3. 사용자별 가치: 밖에 자주 나가는 사람에게는 매우 편리하지만, 외출이 적은 사람에게는 우선순위가 낮다.

4. 셸 모드(!) — C 등급

   1. 사용법: 메시지를 느낌표로 시작하면 일반 터미널 명령을 실행하는 셸 모드로 들어간다.
   2. 차이점: 일반 터미널처럼 명령을 실행하면서도 Claude가 명령의 출력 결과를 함께 볼 수 있다.
   3. 농담: “느낌표를 입력한다”는 설명을 하다가 “exclamation God, that was terrible”이라고 자책하며 썰렁한 말장난을 했다.

5. /radio — 생산성 F, 분위기 triple S

   1. 기능: /radio는 코딩할 때 들을 수 있는 Claude FM의 로파이(lo-fi) 음악을 연다.
   2. 실용 가치: 코딩 생산성을 높이는 기능으로는 F 등급이다.
   3. 분위기 가치: 작업 분위기와 재미만큼은 triple S 등급이다.
   4. 저작권 주의: 실제 음악을 재생해 들려주지는 않았다. 저작권 문제가 생길 수 있기 때문이다.

7. 토큰·컨텍스트를 보존하는 운영법

7.1. 토큰이 사용량과 품질을 동시에 결정한다

1. 프롬프트 개수가 아닌 토큰 개수

   1. 소모 대상: 사용량은 단순히 프롬프트를 몇 번 보냈는지로 계산되지 않는다.
   2. 모든 입출력의 비용: 메시지, Claude가 읽는 파일, Claude가 작성하는 응답이 모두 토큰을 만든다.
   3. 목표: 같은 제한 안에서 토큰을 오래 쓰면서도 모델 성능을 유지해야 한다.

2. 컨텍스트 윈도우와 ‘멍청해지는 구간’

   1. 단기 기억: 컨텍스트 윈도우(context window)는 Claude의 단기 기억처럼 작동한다.
   2. Dumb zone: 컨텍스트를 많이 채울수록 모델이 앞서 읽은 것을 잊고, 서로 모순되는 말을 하며, 단순한 실수를 만들기 시작한다.
   3. 두 가지 한계: 컨텍스트 제한은 약 300,000토큰과 1,000,000토큰 두 종류로 언급됐다. Claude Code는 기본적으로 1,000,000토큰을 사용할 수 있는 것으로 보인다.
   4. 큰 창의 착시: 300,000에서 1,000,000으로 늘어나도 멍청해지는 구간이 사라지지는 않고 더 길어질 뿐이다.
   5. 실전 체감: 약 100,000~200,000토큰을 넘기면 성능이 조금씩 떨어지기 시작하고 사용량 제한도 빠르게 소진된다.

3. /context — B 등급

   1. 확인 기능: /context로 현재 컨텍스트 사용량을 확인할 수 있다.
   2. 사용 시점: 큰 작업을 시작하기 전에 실행하면 남은 여유를 파악할 수 있다.
   3. 한계: 숫자를 보는 것만으로는 컨텍스트를 절약할 수 없으므로, 세션을 나누고 입력을 구체화하는 운영이 함께 필요하다.

7.2. 새 세션과 구체적인 프롬프트

1. 작업마다 새 세션 시작

   1. 첫 작업 이후 품질 저하: Claude Code에서 중간 규모 이상 작업 하나만 해도 최소 50,000토큰 정도를 쓰는 경우가 많다.
   2. 외부 도구의 추가 비용: 조사하거나 스킬·MCP를 사용하면 100,000토큰을 쉽게 넘을 수 있다.
   3. 세션 재사용의 문제: 하나의 대화에서 여러 작업을 이어 가면 다음 작업의 품질이 낮아지고 사용량 제한도 빨리 소진된다.
   4. 실천 규칙: 새 작업을 시작할 때마다 새 세션을 열어 컨텍스트를 깨끗하게 유지한다.

2. 연구의 곁가지 차단

   1. 탐색 감시: Claude가 필요하지 않은 파일을 열거나 관련 없는 주제를 검색하기 시작하면 즉시 멈추게 한다.
   2. 숨은 비용: 읽는 파일과 방문하는 웹사이트 하나하나가 토큰 비용이 된다.
   3. 소스 지정: 참고해야 할 파일과 출처가 정해져 있다면 프롬프트에서 정확히 그 범위를 지정한다.

3. 프롬프트는 지나칠 정도로 구체적으로 작성한다

   1. 모호함의 비용: 모호한 요청을 받으면 Claude가 원하는 바를 추측하려고 프로젝트 전체를 읽게 된다.
   2. 기술적 결정에서의 중요성: 어떤 파일을 기준으로 어떤 제약 아래 어떤 결과를 원하는지 명시해야 기술적 판단을 엉뚱하게 내리지 않는다.
   3. 핵심 원칙: “구체적으로”가 아니라 “바보 같을 정도로 구체적으로(stupidly specific)” 작성하는 편이 낫다.

7.3. /compact를 언제 사용할 것인가

1. 컨텍스트 요약 기능

   1. 역할: /compact는 대화 전체를 더 짧은 요약으로 압축해 컨텍스트 윈도우에 다시 들어가게 한다.
   2. 등급: Claude가 자동으로 실행할 때는 C 등급, 사용자가 무엇을 보존할지 알고 직접 실행할 때는 B 등급이다.

2. 자동 압축 뒤의 품질 저하

   1. 새 세션 신호: Claude가 작업 중 스스로 /compact를 실행했다면 새 세션을 시작하라는 신호로 본다.
   2. 기억 손실 비유: 자동 압축 뒤에는 Claude가 “치매에 걸린 것처럼” 이전 맥락을 잃고 품질이 떨어지는 느낌이 즉시 나타난다.
   3. 수동 압축 예외: 별도 대화를 만들 필요가 없다고 확신하는 작업이라면 직접 /compact를 실행하고 요약에 반드시 남겨야 할 정보를 지시한다.

3. 커뮤니티의 컨텍스트 도구

   1. 추가 도구의 존재: 컨텍스트를 더 효율적으로 관리하기 위해 커뮤니티가 만든 도구들이 있다.
   2. 선별 사용: 모든 도구를 설치하기보다 설명과 저장소를 확인한 뒤 자신의 세션 운영에 실제로 도움이 되는 것만 선택한다.
   3. 관련 자료: 영상 설명에는 ponytail, rtk-ai/rtk, caveman.so가 관련 링크로 제공돼 있다.

8. 코딩 지식을 유지한 채 AI를 사용하기

8.1. “포 루프” 유행이 보여 주는 역설

1. AI와 함께 재발명된 for 루프

   1. 집단적 발견: AI 열성 사용자와 소프트웨어 엔지니어들이 AI를 다루는 혁신적 해법으로 결국 for 루프를 다시 발견했다는 농담을 했다.
   2. 다음 유행 예측: 곧 object-oriented prompting, functional prompting, system prompting이 차례로 유행할 것이라고 비꼬았다.
   3. 웃음의 핵심: 프로그래머가 대체될 것이라는 말을 비판하며, 사람들이 이미 알고 있던 구조를 글꼴만 바꿔 반복해서 발명하고 있다고 지적했다.

2. 프로그래밍 학습의 필요성

   1. 코드를 읽지 못하면 놓치는 것: 코드를 읽을 수 없다면 같은 구조가 반복되는지조차 알아차리지 못한다.
   2. 권고: “제발 코딩을 배워라. 실제 두뇌를 가진 사람이 더 필요하다”고 강조한다.
   3. 팁의 전제: 구체적인 프롬프트, 계획, 검증이 효과를 내는 이유는 사용자가 코드를 이해하고 있기 때문이다.

8.2. AI가 일을 대신하면서 사람을 더 똑똑하게 만드는 방식

1. 사용량 제한 이후에도 일할 수 있어야 한다

   1. 위험한 의존: 사용량 제한에 걸렸을 때 자기 프로젝트에서 무엇을 해야 할지 전혀 모른다면, 도구가 멈추는 순간 개발도 멈춘다.
   2. 강한 표현: 코딩을 전혀 배우지 않은 채 AI에만 의존한 사람에게는 이미 대체됐을 수 있다고 날카롭게 말한다.
   3. 자기 프로젝트의 주도권: AI가 없어도 구조와 원리를 이해할 수 있어야 제한·오류·환각에 대응할 수 있다.

2. 설명을 요구하는 학습 루프

   1. 변경 설명: AI가 바꾼 모든 내용을 설명하게 만든다.
   2. 맹목적 승인 금지: 생성된 변경 사항을 보지도 않고 accept 버튼만 연달아 누르지 않는다.
   3. 상호 강화: 사람이 더 많이 이해할수록 더 좋은 요청과 검증을 만들고, AI도 더 나은 결과를 낸다. 결과적으로 사람의 뇌와 AI 작업 품질이 함께 커지는 승-승 구조가 된다.

9. 자동화와 장시간 실행

9.1. /loop — AI 크론 잡

1. 반복 실행 구조

   1. 사용법: 실행 간격과 수행할 작업을 지정하면 해당 작업을 계속 반복한다.
   2. 비유: /loop는 AI로 만든 크론 잡(cron job)과 같다.
   3. 가치: 개인 프로젝트를 매일 직접 관리하지 않아도 일정한 루틴이 진행된다.
   4. 등급: 실제로 자동화를 즐겨 사용하고 있어 A 등급으로 평가한다.

2. GitHub 이슈 구현 자동화

   1. 작동 방식: 매일 프로젝트의 열린 이슈 중 하나를 골라 구현하게 한다.
   2. 결과: 자리를 비웠다가 돌아오면 작업 결과가 PR로 올라와 있다.
   3. 주의점: PR을 그대로 병합하는 것이 아니라 사람이 변경 내용과 검증 결과를 확인해야 한다.

3. 보안·버그 스윕 자동화

   1. 취약점 탐색: 코드베이스의 알려진 보안 취약점을 검색한다.
   2. 버그 탐색: 발견한 버그나 의심스러운 부분을 표시한다.
   3. 이슈화: 결과를 GitHub 이슈로 기록해 후속 작업으로 남긴다.

4. 기능 브레인스토밍 자동화

   1. 참조 범위: 코드베이스, 기존 PR, 열린 이슈를 함께 읽는다.
   2. 산출물: 프로젝트에 실제로 도움이 될 만한 기능 아이디어를 브레인스토밍한다.
   3. 이벤트 기반 실행: 정해진 시간뿐 아니라 특정 일이 발생했을 때 자동화를 실행할 수도 있다.
   4. 도입 현황: 기업과 오픈소스 프로젝트가 이런 자동화를 시험하고 있으며 꽤 괜찮은 결과를 얻고 있으므로 직접 시도할 만하다.

9.2. 목표 달성까지 계속하는 실행 명령

1. 목표 기반 지속 실행

   1. 기능: Claude에게 목표를 주면 목표를 완수하거나 사용자의 도움이 필요할 때까지 계속 작업한다.
   2. 검증 목표 예시: “모든 테스트가 통과하고 타입 오류가 없도록 하라”를 목표로 지정할 수 있다.
   3. 반복 구조: 목표가 충족될 때까지 Claude가 확인·수정·재실행을 반복한다.
   4. 명령어 표기: 해당 구간의 자동 자막에는 명령어 이름이 직접 나오지 않고 “이 명령”으로만 표현된다.

2. 요금제별 등급

   1. 낮은 요금제: 토큰이 제한된 플랜에서는 반복 실행이 사용량을 빠르게 소모하므로 B 등급이다.
   2. 상위·무제한 플랜: 토큰 여유가 있다면 A 등급에 가까워진다.
   3. 조건부 자동화: 계속 실행하는 기능은 검증 기준이 명확할 때 유용하지만, 모호한 목표를 주면 토큰을 태우며 엉뚱한 반복을 할 수 있다.

10. 에이전트, 서브 에이전트, 작업 트리

10.1. 서브 에이전트의 구조와 비용

1. 메인 에이전트와 서브 에이전트

   1. 메인 에이전트: 평소 대화하는 Claude를 “아빠 에이전트(daddy agent)”, “Chad”, “그룹 리더”에 비유한다.
   2. 서브 에이전트: 메인 에이전트가 특정 작업 하나를 맡기기 위해 시작하는 작은 Claude다.
   3. 역할 예시: 연구자(researcher), 리뷰어(reviewer), 디버거(debugger)로 나눌 수 있다.
   4. 컨텍스트 분리: 각 서브 에이전트는 별도의 컨텍스트 윈도우에서 작업하고, 끝나면 한 일의 요약을 메인 에이전트에 돌려준다.

2. 만드는 방법과 품질 효과

   1. 간단한 생성법: Claude에게 어떤 서브 에이전트를 만들고 무슨 일을 맡길지 설명하면 된다.
   2. 병렬 전문화: 서로 독립된 연구·검토·디버깅을 병렬로 처리해 구현 품질을 높인다.
   3. 등급: 일반 사용자 기준 A 등급이며, 상위 플랜이나 무제한 토큰 환경에서는 구현 품질을 크게 높이는 S 등급이다.

3. $20 플랜의 비용 문제

   1. 독립 대화 비용: 서브 에이전트 하나가 사실상 완전한 대화 하나를 병렬로 실행한다.
   2. 제한 소진 속도: 작은 멀티 에이전트 구성만으로도 작업이 끝나기 전에 $20 플랜의 사용량 전체를 소진할 수 있다.
   3. 운영 기준: 충분한 토큰이 없는 환경에서는 모든 작업에 서브 에이전트를 붙이지 말고, 병렬화로 얻는 품질 이득이 비용보다 클 때만 사용한다.

10.2. 작업 트리(worktree)로 병렬 개발하기

1. 격리된 브랜치 공간

   1. 기능: 하나의 저장소에서 여러 브랜치를 각각 별도 폴더로 체크아웃한다.
   2. 구조: worktree를 만들 때마다 프로젝트가 독립된 폴더로 복사된다.
   3. AI 병렬 개발: 여러 에이전트가 동시에 다른 기능을 구현해도 서로의 파일과 브랜치를 건드리지 않는다.

2. 실제 워크플로

   1. 대화 하나에 worktree 하나: 각 채팅 세션을 하나의 worktree로 배정한다.
   2. 대기 시간 제거: 한 브랜치의 작업이 끝날 때까지 기다리지 않고 여러 브랜치에서 동시에 진행한다.
   3. 간섭 방지: 각 작업이 완전히 격리돼 에이전트끼리 충돌할 위험이 줄어든다.
   4. 지원 여부: Claude Code는 worktree를 네이티브로 지원한다.

11. Claude Code 외의 선택지

11.1. 모델과 인터페이스를 기준으로 도구 고르기

1. Codex

   1. 성격: OpenAI의 코딩 에이전트다.
   2. 개인 선호: 여러 대안 가운데 가장 많이 사용하고 좋아하는 도구로 꼽는다.
   3. 사용량: Claude Code보다 사용량 제한이 넉넉하다고 느낀다.
   4. 유머 섞인 감사: “우리의 주님이자 구원자 Tibo가 제한을 계속 리셋해 준다”고 말하며 덕분에 프로젝트를 많이 진전시켰다고 농담한다.

2. OpenCode

   1. 성격: Claude Code의 오픈소스 버전처럼 사용할 수 있다.
   2. 모델 선택: 특정 회사의 모델에 묶이지 않고 원하는 모델을 사용하고 싶다면 확인할 만하다.

3. Pi

   1. 성격: 최소한의 구성(minimalist setup)을 제공한다.
   2. 대상: 정해진 사용법보다 자신만의 워크플로를 처음부터 만들고 싶은 사람에게 맞는다.

4. Cursor

   1. 성격: IDE와 에이전트가 결합된 형태를 원할 때 선택한다.
   2. 모델 선택: 여러 모델을 고를 수 있다.
   3. 자체 모델: 빠르고 저렴한 Grok와 Composer를 선호한다고 언급한다. 자막에는 Grok가 “Rock”처럼 표기되기도 한다.

5. VS Code와 GitHub Copilot

   1. 성격: 가장 오래되고 널리 알려진 조합(“the OG”)이다.
   2. 접근성: 대부분의 개발자가 VS Code를 이미 알고 있어 진입 장벽이 낮다.

6. T3 Code

   1. 성격: 최근 좋아지고 있는 오픈소스 코딩 에이전트용 컨트롤 플레인(control plane)이다.
   2. 단일 구독 사용: Claude Code 구독 하나만 있다면 T3 Code의 UI가 더 마음에 들 수 있다.
   3. 여러 구독 통합: Claude Code, Codex, OpenCode, Cursor 등을 모두 구독했다면 T3 Code 하나에서 여러 구독을 사용할 수 있어 앱을 오가며 작업할 필요가 줄어든다.

11.2. 선택 기준

1. 단일 정답 없음

   1. Claude Code의 터미널 경험과 사용량 제한이 마음에 들면 계속 사용하면 된다.
   2. IDE가 중요하면 Cursor나 VS Code·Copilot을 선택한다.
   3. 여러 모델·구독을 한곳에 모으고 싶으면 OpenCode나 T3 Code를 검토한다.
   4. 최소 구성과 자유로운 조립을 원하면 Pi를 선택한다.

2. 도구보다 원칙의 재사용성

   1. 계획 모드, 스킬, MCP, 검증, 컨텍스트 관리, 새 세션, 격리된 브랜치는 대부분의 코딩 에이전트에서 그대로 재사용할 수 있다.
   2. 특정 제품의 기능 목록을 외우기보다 “필요한 정보만 주고, 계획하고, 검증하고, 비용을 관찰한다”는 운영 원칙을 익히는 편이 오래 간다.

주요 발언 모음

“Claude Code의 사용량 제한은 끔찍하다. 인사 한마디 했더니 제한이 사라지고 3시간을 기다려야 한다.”

“나는 이 도구에 한 달 $100를 쓰지 않을 것이다. 그 돈이면 차라리 McDonald’s를 사 먹겠다.”

“Claude Code는 Claude인데 코딩용이다. 천만에. 정말로는 코딩에 특화돼 있고 터미널에 산다.”

“스킬을 100개 설치하지 마라. 필요한 것만 해라.”

“3,000줄의 코드와 12개 파일에서 실수를 찾는 것보다 계획에서 실수를 찾는 편이 훨씬 쉽다.”

“구현하기 전에 테스트를 써라. 구현한 뒤에 쓰면 자기 코드가 통과하도록 테스트를 만드는 셈이다.”

“AI에 기대더라도 AI를 이용해 일을 하고 동시에 더 똑똑해져라.”

“변경 내용을 설명하게 하고, 맹목적으로 accept 버튼을 누르지 마라.”

“새 작업마다 새 세션을 시작하라. 이전 작업의 컨텍스트는 다음 작업의 품질을 떨어뜨린다.”

“코드를 배워라. 실제 두뇌를 가진 사람이 더 필요하다.”

“/radio는 생산성에는 F 등급이지만 분위기에는 triple S 등급이다.”

핵심 데이터 & 수치

• 1,000시간 이상: Claude Code를 장기간 사용하며 워크플로와 기능을 비교한 기준이다.
• $20: 실제 사용 중인 기본 요금제이며, 짧은 대화만으로도 제한에 도달하는 사례가 있었다.
• 3시간: 사용량 제한에 걸린 뒤 기다려야 했던 시간의 예시다.
• $100·$200: 상위 요금제 사용자도 토큰과 컨텍스트를 관리해야 한다는 비교 기준이다.
• 6개월·약 10억 달러: Claude Code의 빠른 매출 성장 사례로 언급됐다.
• 80개 이상: 조사 과정에서 발견한 Claude Code의 명령과 기능 수다. 대부분은 설정이거나 거의 쓰지 않는 기능이라 핵심 기능만 추렸다.
• 300,000·1,000,000토큰: 언급된 두 가지 컨텍스트 제한 규모다.
• 100,000~200,000토큰: 실전에서 성능 저하가 느껴지기 시작하는 구간이다.
• 최소 50,000토큰: 중간·대형 작업 하나가 사용하는 컨텍스트의 체감 최소치다.
• 3,000줄·12개 파일: 구현 후 오류를 찾는 것보다 계획에서 방향을 검토하는 편이 낫다는 비유다.

기능 등급 요약

• S~triple S: 계획 모드, 검증, (토큰 여유가 있을 때) 서브 에이전트, /radio의 분위기 가치
• A: 스킬(현명하게 쓰는 경우 S), MCP, /loop, worktree, 상위 플랜의 목표 지속 실행, 기본 스킬
• B: /voice, /context, 낮은 요금제의 목표 지속 실행
• C~D: /init 자체, /btw, /teleport·remote control(개인 사용 기준), 셸 모드 !, /compact 자동 실행
• F: /radio의 생산성 가치

결론 및 시사점

1. 프로젝트 맥락을 짧고 살아 있는 문서로 유지한다: CLAUDE.md에 개요·현재 상태·코딩 스타일·작업 철학을 적되, 결과에 맞춰 계속 수정한다.
2. 반복 절차는 스킬로 만든다: 요구사항 정리, 아키텍처 개선, 코드 품질 리뷰처럼 두 번 이상 반복할 업무는 skill.md로 분리해 재사용한다.
3. 큰 작업은 계획부터 승인한다: 작은 수정에는 바로 실행하고, 여러 파일을 건드리는 일에는 plan mode로 탐색·계획·승인을 거친다.
4. 검증을 완료 조건으로 고정한다: 테스트를 먼저 만들고, 타입 검사·린트·브라우저·스크린샷 검사를 실제 실행한 뒤에만 완료로 간주한다.
5. 외부 연결은 MCP로 최소화한다: 코드베이스 밖의 GitHub·DB·Slack·분석·배포·브라우저에 직접 접근할 때만 MCP를 쓰고, 지식과 절차는 스킬로 처리한다.
6. 작업마다 새 세션을 사용한다: /context로 상태를 확인하고, 불필요한 조사와 파일 읽기를 막으며, 모호한 요청 대신 구체적인 범위·출처·제약을 제시한다.
7. 자동 압축을 경고 신호로 본다: Claude가 작업 중 자동으로 /compact를 실행하면 품질 저하 가능성을 고려해 새 세션으로 옮기고, 꼭 필요할 때만 보존할 정보를 지정해 수동 압축한다.
8. 토큰이 충분할 때만 병렬화를 확장한다: 서브 에이전트와 목표 지속 실행은 품질을 높이지만 $20 플랜에서 제한을 빠르게 소모하므로 작업 가치와 비용을 비교한다.
9. worktree로 에이전트를 격리한다: 대화마다 별도 worktree를 두면 여러 기능을 동시에 진행하면서 브랜치 간 간섭을 줄일 수 있다.
10. 도구보다 코딩 능력을 먼저 지킨다: AI를 이용해 반복 작업을 덜어내되, 코드의 원리와 변경 내용을 이해하고 설명을 요구해 AI가 사람의 학습을 대체하지 않고 증폭하게 만든다.
11. Claude Code에 종속되지 않는다: Codex, OpenCode, Pi, Cursor, VS Code·Copilot, T3 Code 중 요금·모델 선택·IDE 선호·구독 통합 요구에 맞는 도구를 고른다.