Claude Code 사용법 - 6개월 실전 적용 후 알게 된 17가지 (2026 최신)

TL;DR
- 지난 6개월 동안 매일 Claude Code로 일했습니다. 한 달 평균 PR 187개를 머지했고, 그중 130개에 Claude Code가 깊이 관여했습니다.
- 결론부터 말하면 “코드를 대신 짜주는 도구”가 아니라 “맥락(Context)을 정교하게 관리하는 시스템을 짜는 도구” 입니다. 이 차이를 이해하는 사람과 그렇지 않은 사람의 결과물은 완전히 다릅니다.
- 이 글은 매뉴얼이 아니라 운영 일지에 가깝습니다. 좋은 점만큼 함정과 한계도 솔직하게 적었습니다.

저는 7년차 백엔드 개발자입니다. 스타트업에서 Kotlin/Spring 모놀리스와 Python 마이크로서비스를 함께 다루고 있고, 2025년 5월 Claude Code 출시 직후부터 매일 써왔습니다. 그동안 레거시 모놀리스 리팩토링, 신규 서비스 0→1 구축, 인프라 자동화 스크립트까지 다양한 영역에 적용해봤습니다.

처음 3개월은 신기해서 모든 걸 맡겼다가 망친 PR도 꽤 많았습니다. 4개월차쯤 되니 어떤 패턴이 잘 통하고 어떤 게 시간 낭비인지 감이 잡혔습니다. 이 글은 그 6개월의 시행착오를 정리한 결과입니다. 같은 함정을 다시 밟을 필요가 없도록요.


1. Claude Code, 왜 다른 AI 코딩 도구와 다른가

“터미널 네이티브 에이전트”라는 패러다임

Cursor를 써본 분들은 처음 Claude Code를 만나면 어색합니다. UI가 거의 없거든요. claude 한 줄 치고 들어가면 끝입니다. 처음엔 “이게 왜 더 좋다는 거지?”라고 생각했는데, SSH로 원격 서버에 들어가서 디버깅할 때 처음 그 차이를 체감했습니다.

Claude Code는 IDE 안에 사는 도구가 아니라 터미널 그 자체에서 동작하는 에이전트입니다. 그래서 SSH, tmux, Docker 컨테이너 안에서도 그대로 작동합니다. 새벽 3시 프로덕션 서버에서 로그 파헤치다가 그 자리에서 claude 한 번이면 코드베이스 분석에 들어갈 수 있다는 건, IDE 기반 도구로는 흉내 낼 수 없는 자유도입니다.

Cursor / Copilot과의 결정적 차이

자주 받는 질문이 “Cursor랑 뭐가 달라요?” 입니다. 표로 정리하면 이렇습니다.

항목 Claude Code Cursor GitHub Copilot
형태 터미널 네이티브 에이전트 AI 네이티브 IDE (VS Code fork) 멀티 IDE 익스텐션
시작가 $20/월 $20/월 $10/월
컨텍스트 윈도우 1M 토큰 128K~200K 모델별 상이
SWE-bench Verified 87.6% (Opus 4.7) 미공개 미공개
강점 복잡한 다중 파일, 대규모 코드베이스 Supermaven 자동완성, Composer 시각 편집 모든 IDE에서 가벼운 보조
적합한 워크플로 자율 백그라운드, SSH/원격, 모노레포 일상 편집 + 휴먼-인-더-루프 어디서나 가벼운 보조

수치도 차이가 큽니다. Opus 4.7의 SWE-bench Verified는 87.6%로, 한때 1위였던 Opus 4.6의 80.8%를 이미 추월했고 GPT-5.5(82.0%)보다도 높습니다. 컨텍스트 윈도우 1M은 Cursor 대비 5~7배입니다. 블라인드 코드 품질 테스트에서 67% 승률을 가지면서도 동일 작업에 토큰을 5.5배 적게 쓴다는 게 가장 인상적인 부분입니다.

그래서 “하나만 골라야 한다”는 프레임은 틀렸다

여기서 한 가지 흥미로운 통계가 있습니다. 직장 내 사용률은 Copilot 29% > Cursor 18% = Claude Code 18% 순인데, 개발자 “Most Loved” 지표는 Claude Code 46% > Cursor 19% > Copilot 9%입니다. 좋아하지만 회사에서 못 쓰는 사람이 많다는 뜻이죠.

제가 6개월 굴려보고 내린 결론은 “하나만 고르지 말고 조합하라” 입니다. 저는 일상적인 자동완성과 시각적 편집은 Cursor를 쓰고, 다중 파일 리팩토링이나 백그라운드 자율 작업은 Claude Code를 씁니다. 가장 생산성 높은 2026년 개발자들의 공통 패턴이 정확히 이겁니다.


2. 5분 만에 시작하기 - 설치부터 첫 실행까지

사전 요구사항

  • Node.js 18 이상
  • Claude Pro, Max, Team, Enterprise 중 하나의 계정 (Free 플랜은 Claude Code 미포함 - 최소 Pro 필요)

설치

# 권장: npm 글로벌 설치
npm install -g @anthropic-ai/claude-code

# 또는 의존성 없는 네이티브 설치
curl -fsSL https://claude.ai/install.sh | bash

여기서 잘 빠지는 함정 두 개:

  1. sudo로 설치하지 마세요. 리눅스에서 권한 에러가 나면 ~/.npm-global을 PATH에 추가하는 식으로 해결하세요. sudo로 설치하면 나중에 권한 꼬여서 더 골치 아픕니다.
  2. 업그레이드는 npm install -g @anthropic-ai/claude-code@latest로 하세요. npm update -g는 semver 범위에 묶여서 진짜 최신 버전으로 못 갈 수 있습니다.

첫 실행

cd ~/your-project
claude

최초 실행 시 OAuth 플로우가 뜨고 Anthropic 계정과 연결됩니다. 이게 끝입니다.

플랜 선택은 이렇게

가격은 2026년 5월 기준 이렇습니다.

플랜 가격 누구에게
Pro $20/월 처음 써보는 개인, 사이드 프로젝트
Max ($100) $100/월 매일 풀타임으로 쓰는 개인 (Pro 대비 5배 사용량)
Max ($200) $200/월 헤비 유저, 1M 컨텍스트 Opus 자동 적용 (Pro 대비 20배 사용량)
Team Premium $100/시트/월 팀 도입 (최소 5시트, Cowork 포함)
Enterprise 영업 협의 보안 요건 (HIPAA, SCIM, SSO 등)

저는 처음 한 달은 Pro($20)로 시작했다가 한도 자주 터져서 Max($100)로 옮겼습니다. 하루에 두세 번 한도 친다면 Max로 올리는 게 시간 가치로 봤을 때 무조건 이득입니다. 시간당 인건비랑 비교하면 답이 빨리 나옵니다.

/init으로 첫 CLAUDE.md 만들기

설치하고 가장 먼저 할 일은 프로젝트 안에서 /init을 치는 겁니다.

/init

Claude Code가 코드베이스를 훑어보고 자동으로 CLAUDE.md 초안을 만들어줍니다. 이게 모든 것의 시작점입니다.


3. CLAUDE.md - 모든 것의 시작점

이 섹션이 사실 이 글에서 가장 중요합니다. 6개월 써본 결론은 단순합니다. CLAUDE.md의 품질이 Claude Code의 품질을 결정합니다.

CLAUDE.md가 왜 결과를 결정하는가

Claude Code는 매 세션 시작 시 CLAUDE.md를 자동으로 컨텍스트에 로드합니다. 즉, 이 파일은 모든 대화의 “헌법” 역할을 합니다. 헌법이 부실하면 매번 같은 실수를 반복하고, 매번 같은 컨벤션을 다시 설명해야 합니다.

실전 CLAUDE.md 템플릿 (그대로 복붙하세요)

제가 실제로 쓰는 템플릿입니다. 한국어 백엔드 프로젝트 기준입니다.

# 프로젝트: payments-api

## 응답 언어
- 기본 응답은 한국어로
- 코드 주석은 영어로 (팀 컨벤션)

## 기술 스택
- Kotlin 1.9 / Spring Boot 3.2
- PostgreSQL 15 / Redis 7
- Gradle (KTS), JDK 21
- 테스트: JUnit 5 + Kotest

## 프로젝트 구조
- `domain/` - 도메인 모델, 비즈니스 로직 (외부 의존성 금지)
- `application/` - 유스케이스, 트랜잭션 경계
- `adapter/in` - REST 컨트롤러, 메시지 리스너
- `adapter/out` - DB 리포지토리, 외부 API 클라이언트
- 헥사고날 아키텍처 - domain은 adapter를 모릅니다

## 자주 쓰는 명령어
- 테스트: `./gradlew test` (cd 하지 말 것 - 루트에서 실행)
- 빌드: `./gradlew bootJar`
- 로컬 DB 띄우기: `docker compose up -d postgres redis`
- 마이그레이션: `./gradlew flywayMigrate`

## 코딩 컨벤션
- DTO는 `data class`, 도메인은 일반 `class` + 생성자에서 검증
- 예외는 `domain/error/`에 정의된 sealed class만 사용
- Optional 대신 nullable 사용
- Public 함수는 KDoc 필수, 내부 함수는 자명하면 생략

## 절대 하지 말 것
- `@Autowired` 필드 주입 금지 (생성자 주입만)
- `domain/` 안에서 Spring 어노테이션 사용 금지
- 신규 라이브러리 추가는 반드시 사전 논의

## 작업 흐름
- 변경 전 항상 plan mode로 계획부터
- 테스트가 없는 코드는 절대 머지 안 함
- 변경 단위마다 `git commit` (체크포인트)

자주 빠지는 함정 - “너무 많이 적지 마라”

처음에 의욕에 차서 CLAUDE.md를 800줄짜리 위키처럼 만든 적이 있습니다. 결과는 재앙이었습니다. 매 세션마다 토큰을 잡아먹고, Claude가 진짜 중요한 부분을 놓쳤습니다.

HumanLayer의 베스트 프랙티스와 제 경험을 종합하면 300줄 미만이 sweet spot입니다. 그 이상으로 길어지면 의심하세요. 정말 필요한 정보인지, 아니면 “있으면 좋겠다” 수준인지.

3계층 구조를 활용하세요

CLAUDE.md는 3계층으로 동작합니다. 잘 모르고 한 곳에 다 적는 분들이 많은데, 분리하는 게 훨씬 깔끔합니다.

  • ~/.claude/CLAUDE.md (글로벌) → 나의 코딩 스타일, 한국어 응답 같은 개인 선호
  • 프로젝트/CLAUDE.md (프로젝트) → 위 템플릿처럼 프로젝트별 컨벤션
  • 프로젝트/하위디렉토리/CLAUDE.md (디렉토리별) → 특정 모듈만의 규칙 (예: frontend/에만 적용되는 React 컨벤션)

설정도 똑같이 ~/.claude/settings.json프로젝트/.claude/settings.json 3계층으로 머지됩니다.


4. 매일 쓰는 슬래시 명령어 8가지

설치 직후 /만 쳐도 명령어가 쭉 뜹니다. 다 외울 필요 없고, 매일 쓰는 건 사실 8개 정도입니다.

컨텍스트 관리의 핵심: /clear, /compact

이 두 개를 모르면 토큰을 흥청망청 쓰게 됩니다.

  • /clear - 컨텍스트를 완전히 초기화. 작업 단위가 바뀔 때 무조건 치세요. (예: API 작업 끝내고 인프라 작업 들어갈 때)
  • /compact - 현재 컨텍스트를 요약본으로 압축. 긴 디버깅 세션 후반에 유용합니다.

저는 하나의 PR 작업이 끝나면 무조건 /clear 합니다. 이걸 안 하고 그냥 다음 작업 시작하면, 이전 작업의 잡소리가 새 작업에 섞여서 결과 품질이 떨어집니다.

그 외 자주 쓰는 것

  • /init - CLAUDE.md 초안 자동 생성
  • /review - 변경사항 PR 단위 자동 리뷰
  • /resume - 이전 세션 이어서 진행
  • /model - Sonnet/Opus 전환 (Sonnet은 빠르고 싸게, Opus는 어려운 일에)
  • /cost - 현재 세션 토큰 사용량 확인 (이거 자주 보세요)
  • /schedule - Routines 예약 (2026년 신기능, 뒤에서 자세히)

커스텀 슬래시 커맨드 만들기

진짜 강력한 건 직접 만드는 명령어입니다. .claude/commands/ 폴더에 마크다운 파일 하나만 두면 됩니다.

예시: .claude/commands/commit-msg.md

스테이지된 변경사항을 분석해서 Conventional Commits 형식의 커밋 메시지를 작성해주세요.

규칙:
- feat / fix / refactor / docs / chore / test 중 선택
- 한 줄 요약은 50자 이내
- body는 무엇이 아니라 "왜"를 설명
- 한국어로 작성
- Breaking change가 있으면 BREAKING CHANGE: footer 추가

이제 /commit-msg만 치면 끝입니다. 매번 “커밋 메시지 좀 써줘”라고 길게 설명할 필요가 없습니다. 저희 팀은 /pr-description, /release-notes, /postmortem 같은 커스텀 명령어를 공유하고 있고, 이게 팀 생산성의 가장 큰 변곡점이었습니다.


5. 실전 워크플로우 - “Plan First, Code Second”

가장 비싼 실수: 계획 없이 코딩 시작

6개월간 가장 많이 망친 패턴이 이겁니다. “이 API에 필드 하나 추가하면 돼”라고 가볍게 시킨 작업이 30분 뒤에 보면 6개 파일이 엉망진창으로 수정되어 있는 거죠. 롤백하는 게 새로 짜는 것보다 빠를 정도였습니다.

해결책은 plan mode를 강제하는 겁니다. 작업 시작할 때 이렇게 시킵니다.

이 작업의 계획을 먼저 세워줘. 
- 어떤 파일을 어떻게 바꿀지
- 어떤 테스트가 필요한지
- 잠재적 부작용은 무엇인지
실제 코드 변경은 내가 OK 하기 전까지 절대 하지 마.

계획을 받아보면 “아 이 부분은 내가 잘못 설명했네”, “이거까지 건드릴 필요는 없는데” 같은 게 보입니다. 5분 더 쓰고 30분 아끼는 패턴입니다.

Extended Thinking을 언제 켜는가

think, think hard, think harder, ultrathink 같은 키워드로 thinking 시간을 늘릴 수 있습니다. 저는 이렇게 씁니다.

  • 그냥 쓰기: 단순 CRUD, 컴포넌트 만들기, 보일러플레이트
  • think: 다중 파일 리팩토링, API 설계
  • think hard: 동시성 버그, race condition 추적
  • ultrathink: 아키텍처 결정, 마이그레이션 전략

남용하면 토큰만 까먹습니다. 정말 어려운 문제일 때만 쓰세요.

TDD 패턴 - 테스트 먼저, 그 다음 구현

가장 잘 통한 패턴입니다.

1. "이런 동작이 필요해. 우선 테스트만 작성해줘. 구현은 비워두고."
2. (테스트 검토 후) "이 테스트들이 다 통과하도록 구현해줘. 테스트는 수정하지 마."
3. "테스트 다시 돌려서 다 통과하는지 확인해줘."

테스트를 먼저 받아두면 Claude가 “이게 됐다고 우기는” 상황을 막을 수 있습니다. 테스트가 실패하면 거짓말을 못 합니다.

Before / After 비교 - 800줄 레거시 파일 리팩토링

데이터 한 줄로 와닿는 효과:

Before (수동 리팩토링)
- 800줄 단일 파일 → 테스트 가능한 모듈로 분할
- 평균 4~8시간 소요
- 중간에 컨텍스트 잃고 다시 읽음

After (Claude Code + plan mode)
- 같은 작업 15분 이내 완료
- plan을 먼저 받아서 모듈 경계만 사람이 결정
- 실제 코드 이동은 Claude가 처리

비슷한 사례로 cyclomatic complexity 16짜리 210줄 Python 함수를 30줄 미만(complexity 3~6) 함수들로 쪼개는 작업도 한 세션 안에서 끝납니다. 수동으로 하면 반나절짜리입니다.

Git 통합 - 자연어로 커밋/리베이스

이게 한 번 익숙해지면 못 돌아갑니다.

스테이지된 변경사항을 의미 단위로 3개 커밋으로 쪼개줘. 
각 커밋 메시지는 한국어로.
main 기준으로 리베이스해서 커밋 메시지 정리하고, 
fixup 커밋들 squash 해줘.

저는 --no-verify--force-push 같은 위험한 옵션은 절대 못 쓰게 CLAUDE.md에 명시해뒀습니다. 안전장치는 필수입니다.


6. 고급 기능 - Subagents, Hooks, MCP, Plugins (2026 NEW)

여기서부터가 다른 글들이 잘 안 다루는 영역입니다. 2026년에 새로 추가된 게 많아서 정보가 흩어져 있습니다.

Subagents - 역할별 전문가 팀 구성

Subagent는 자신만의 시스템 프롬프트와 도구 권한을 가진 별도의 Claude 인스턴스입니다. 메인 Claude가 작업을 위임할 수 있어요.

저희 팀이 정의한 subagent들:

  • researcher - 코드베이스 분석만 함, 쓰기 권한 없음. 큰 영향 평가 시 유용.
  • test-writer - 테스트만 작성. 구현 코드는 못 건드림.
  • security-reviewer - 보안 관점 코드 리뷰만.
  • doc-writer - README, 주석, API 문서만.

리드 Claude가 “이 변경의 보안 영향을 security-reviewer에게 물어봐줘”라고 시키면 격리된 컨텍스트에서 병렬로 작업합니다. 메인 컨텍스트가 무거운 분석으로 오염되지 않는 게 핵심입니다.

.claude/agents/ 폴더에 마크다운으로 정의하면 됩니다. 풀스택 시나리오에서는 리드 에이전트가 인터페이스 계약을 정의하고, DB 스키마/API/UI를 담당하는 서브 에이전트 3개가 병렬로 작업하는 패턴이 가장 잘 통합니다. 1M 컨텍스트 덕분에 모노레포 전체와 문서를 한 세션에 적재할 수 있어서 가능한 패턴입니다.

Hooks - 결정론적 안전장치

Hooks는 “이벤트가 발생하면 무조건 X를 실행”하는 결정론적 장치입니다. AI에게 맡기지 않고 코드로 강제하는 부분입니다.

대표적 활용:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "block-dangerous-commands.sh" }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "./gradlew ktlintFormat" }
        ]
      }
    ]
  }
}

위 예시는 매 파일 편집 후 자동으로 ktlintFormat을 돌립니다. “포맷 까먹는 일”이 구조적으로 불가능해집니다. AI가 가끔 빼먹는 일도, 사람이 자주 빼먹는 일도 코드가 강제하면 사라집니다.

MCP 서버 - 외부 시스템 연결

MCP(Model Context Protocol)는 Claude Code가 외부 도구를 쓸 수 있게 해주는 표준입니다. 설정은 claude mcp add <server>로 끝입니다.

저희 팀이 실제로 쓰는 조합:

서비스 사용 사례
GitHub “결제 플로우 관련 PR 보여줘” → 자동으로 관련 파일 가져옴
Linear “지난 30일 체크아웃 관련 티켓 전부” → 워크스페이스 쿼리
Slack 채널/DM 요약, 누가 왜 그 결정 했는지 컨텍스트
PostgreSQL 스키마 검토, 직접 쿼리

특히 Slack → Linear → 코드까지 한 흐름으로 이어지면 “고객 컴플레인 → 티켓 → PR”이 한 세션 안에서 가능해집니다. 처음 해보면 충격적입니다.

설정 파일은 .claude/settings.json(팀 공유, git 커밋)과 ~/.claude/settings.json(개인 토큰) 두 군데에 나눠 두는 게 안전합니다. 토큰 같은 비밀은 개인 설정에만.

Plugins (2026 NEW) - 팀 자산 배포 단위

2026년 들어서 가장 큰 변화입니다. Plugins는 슬래시 커맨드, subagents, hooks, MCP 설정을 하나의 패키지로 묶어 배포하는 메커니즘입니다.

지금 마켓플레이스에 425개 플러그인, 2,810개 스킬, 200개 에이전트가 올라와 있고, awesome-claude-code 리포는 36K stars를 찍었습니다. 회사 내부에서도 “결제팀 표준 플러그인”, “인프라팀 표준 플러그인” 같은 식으로 묶어 배포할 수 있어서 온보딩이 비교할 수 없이 빨라졌습니다. 신규 입사자가 첫날 플러그인 하나 설치하면 팀의 모든 컨벤션, 명령어, 안전장치가 동시에 깔립니다.

Routines (2026.04 출시) - 클라우드 자동화

2026년 4월 14일에 출시된 따끈따끈한 기능입니다. Anthropic의 관리형 인프라에서 백그라운드로 실행되어서, 내 노트북이 꺼져 있어도 돌아갑니다.

3가지 트리거가 있습니다:
- Scheduled - cron 같은 시간 기반
- API - HTTP POST로 호출
- GitHub - PR 이벤트, 릴리스 이벤트 등

실제 활용 예: 매일 오전 7시에 어제 머지된 PR들을 분석해서 릴리스 노트 초안을 Slack에 올리도록 예약. 또는 새 PR 열리면 자동으로 보안 리뷰 subagent가 돌아서 코멘트 다는 식.

한도는 Pro 5회/일, Max 15회/일, Team/Enterprise 25회/일입니다. 아직 research preview라 한도가 빡빡합니다.

Routines × MCP × Subagents 3종 콤보

이 세 가지를 합치면 진짜 게임이 바뀝니다. 저희 팀 워크플로 하나 예시:

  1. Routine 예약: GitHub에 새 PR이 열림
  2. Subagent 자동 호출: security-reviewer가 변경 분석
  3. MCP로 컨텍스트 확장: 관련 Linear 티켓, 과거 Slack 결정 내용 가져옴
  4. 결과: PR에 자동 코멘트, 위험 요소가 발견되면 Slack에 멘션

내가 출근하기 전에 이미 1차 리뷰가 끝나 있습니다. 이게 다른 글에선 분리해서 설명되어 있는데 합쳐서 보면 흐름이 훨씬 자연스럽습니다.


7. 비용과 함정 - 솔직한 운영 후기

월 토큰 사용량 공개

저는 Max ($100) 플랜을 쓰고 있고, 한 달 평균 토큰 사용량은 약 870만 토큰입니다. PR 130개를 처리한 결과니까 PR당 평균 6.7만 토큰 정도네요.

여기서 흥미로운 데이터 하나. Cursor 대비 동일 작업에 토큰을 5.5배 적게 쓴다는 벤치마크가 있는데, 6개월 굴려본 체감으로도 비슷합니다. Claude Code의 컨텍스트 관리 로직이 그만큼 똑똑하다는 뜻입니다. 한 번에 다 읽어들이는 게 아니라 필요한 부분만 발췌해서 보거든요.

손익분기점 - 어느 플랜이 맞는가

대략적인 가이드라인:

  • 월 PR 30개 이하: Pro($20) 충분
  • 월 PR 30~100개: Max($100) 권장 (한도 안 터지는 안정감)
  • 월 PR 100개 이상 + 1M 컨텍스트 자주: Max($200) 또는 API
  • 팀 5명 이상: Team Premium ($100/시트) - mix & match 가능

시간당 인건비 $50 기준으로 보면 Max($100)는 하루 2시간만 절약해도 본전입니다.

컨텍스트 폭주를 막는 5가지 습관

가장 자주 망치는 게 컨텍스트 관리입니다. 제가 정착시킨 습관들:

  1. 작업 단위마다 /clear - PR 하나 끝나면 무조건
  2. CLAUDE.md는 300줄 이내 - 헌법은 짧을수록 좋다
  3. 큰 분석은 subagent에 위임 - 메인 컨텍스트 오염 방지
  4. /cost로 주기적 체크 - 5만 토큰 넘어가면 의심
  5. plan mode 강제 - 무계획 실행이 토큰 가장 많이 먹는다

Claude Code가 못 하는 일 / 하면 안 되는 일

솔직히 적습니다. 6개월 써본 한계점들:

  • 시각적 검증이 필요한 UI 작업: 화면 보면서 “여기 좀 더 왼쪽으로”가 안 됩니다. Cursor의 Composer가 이쪽은 더 낫습니다.
  • 외부 통합 디버깅: 실제 외부 서비스 응답 보면서 디버깅하는 건 여전히 사람 일입니다. 로그 분석은 잘하는데 라이브 디버깅은 아닙니다.
  • “감”이 필요한 아키텍처 결정: 비즈니스 맥락이 결정의 절반인 경우가 많은데, 그건 사람만 압니다. 옵션을 펼쳐주는 건 잘하지만 결정은 사람이 해야 합니다.
  • 갓 나온 신생 라이브러리: 학습 데이터 cutoff 이후 나온 라이브러리는 환각이 심합니다. 문서를 직접 MCP로 연결하거나 컨텍스트에 넣어줘야 합니다.

그리고 “코드 한 줄도 안 보고 머지” 하는 패턴은 절대 하지 마세요. 6개월간 가장 크게 데인 게 이거였습니다. Claude Code는 시니어의 손발이 빨라지게 도와주는 도구지, 주니어의 부족한 판단력을 메워주는 도구가 아닙니다.

팀 도입 시 반드시 정해야 할 규칙

저희 팀이 시행착오 끝에 정착시킨 룰입니다.

  1. 공유 CLAUDE.md를 git으로 관리 - 컨벤션 변경은 PR로
  2. .claude/commands/도 공유 자산 - 팀 표준 명령어 모음
  3. --no-verify, --force-push 금지 - hooks로 강제
  4. AI가 생성한 코드도 PR 리뷰 동일하게 - “AI가 짰으니까 패스”는 없음
  5. prod 서버에서는 plan mode만 허용 - 실제 변경 권한 없음

결론: 우리는 코딩이 아니라 시스템을 짜고 있다

6개월 써본 결론을 다시 한 번 정리하면 이렇습니다.

Claude Code의 진짜 가치는 “코드를 대신 짜준다”가 아닙니다. “맥락을 정교하게 관리하는 시스템을 우리 손으로 짤 수 있다” 는 것입니다. CLAUDE.md를 헌법처럼 다듬고, 슬래시 명령어로 팀 표준을 박제하고, subagent로 역할을 분리하고, hooks로 안전장치를 깔고, MCP로 외부 시스템을 연결하고, plugins로 팀 자산을 배포하는 것. 이 전체가 하나의 시스템이고, 그 시스템의 품질이 결과의 품질을 결정합니다.

도구가 똑똑할수록 우리는 더 적게 일하는 게 아니라 더 위 레벨에서 일하게 됩니다. 어떤 컨벤션을 강제할지, 어떤 작업을 자동화할지, 어떤 경계를 둘지를 설계하는 게 새로운 우리 일입니다. 코드를 짜는 일은 점점 더 그 시스템이 잘하게 됩니다.

저는 이게 두렵기보다 신납니다. 이 글이 여러분의 시행착오 시간을 조금이라도 줄일 수 있다면 좋겠습니다.


FAQ

Q. Claude Code는 무료로 쓸 수 있나요?
A. 아니요. Anthropic 무료 플랜에서는 Claude Code를 사용할 수 없고, 최소 Claude Pro($20/월) 이상이 필요합니다. 다만 API 키 방식(Pay-as-you-go)으로 토큰 단위 결제도 가능합니다. Sonnet 4.6 기준 입력 $3/MTok, 출력 $15/MTok이고, 2026년 3월부터는 200K~1M 토큰 구간 프리미엄도 없어졌습니다.

Q. 한국어 응답을 받으려면 어떻게 하나요?
A. CLAUDE.md에 기본 응답 언어: 한국어 한 줄을 추가하면 됩니다. Claude는 한국어를 매우 자연스럽게 구사하니 코드 주석만 영어로 두고 대화는 한국어로 하는 조합이 가장 편합니다.

Q. 팀 단위 도입 시 가장 큰 고민은 보안인데요.
A. Team Premium ($100/시트) 이상부터 audit logs, SCIM 같은 보안 기능이 붙고, Enterprise는 HIPAA, SSO, IP 제한까지 지원합니다. 코드가 학습에 쓰이는지 걱정이라면 Enterprise 계약 시 명시적으로 제외할 수 있습니다.

Q. Cursor를 이미 쓰고 있는데 Claude Code도 같이 써야 하나요?
A. 한 도구만 고르는 프레임은 시장 데이터와 맞지 않습니다. 일상 편집과 시각 작업은 Cursor, 다중 파일 리팩토링과 원격 자율 작업은 Claude Code 식으로 조합하는 것이 가장 생산성 높은 패턴입니다.

Q. Claude Code가 코드를 망쳤을 때 어떻게 복구하나요?
A. 평소 변경 단위마다 git commit (체크포인트 워크플로우)을 들이는 습관이 답입니다. 망친 시점으로 git reset --hard 하거나, plan mode를 강제해서 애초에 망치지 않게 하는 게 더 중요합니다.

Q. JetBrains IDE에서도 쓸 수 있나요?
A. 네. JetBrains Plugin이 베타로 나와 있고, Cmd+Esc(맥)/Ctrl+Esc(윈)로 빠르게 호출됩니다. VS Code Extension이 더 완성도가 높지만, JetBrains 사용자라면 베타라도 충분히 쓸 만합니다.


다음 글 예고

이 글에서 다 다루지 못한 부분이 많아서 시리즈로 이어집니다.

  • 다음 글: Subagents 심화 - 역할별 전문가 팀 구성 패턴 7가지
  • 그 다음 글: CLAUDE.md 패턴 백과사전 - 30개 실전 템플릿
  • 그 다음 글: MCP 통합 워크플로우 - Slack → Linear → 코드까지 한 흐름으로

여러분의 운영 노하우도 댓글로 공유해주시면 다음 글에 반영하겠습니다. 잘 풀린 패턴이든, 망친 케이스든 모두 환영입니다.