Claude Code 강의 핵심 정리
1. 워크플로우의 핵심 사이클
기능을 만들 때마다 반복하는 3단계 사이클이 있습니다.
설계 → 만들기 → 확인 을 계속 반복합니다. 코드를 바로 짜게 하지 말고, Plan 모드로 탐색·설계를 먼저 한 뒤 Normal 모드로 구현하는 것이 핵심입니다.
2. Git은 처음부터 쓰는 습관이 중요
기능을 만들면 코드가 바뀌기 때문에, 변경사항 추적과 되돌리기를 위해 Git을 처음부터 사용해야 합니다. 나중에 습관을 들이는 건 어렵기 때문에 처음 시작할 때부터 git init으로 시작하는 것이 중요합니다.
3. 컨텍스트 윈도우 관리
컨텍스트 윈도우는 컴퓨터의 RAM과 같은 유한한 자원입니다. 가득 차면 AI 성능이 저하되고, 초반 지시를 잊어버리거나 실수가 늘어납니다.
잘 관리하는 3가지 방법은 아래와 같습니다.
- 필요한 정보만 넣고 불필요한 정보로 오염시키지 않기
- 대화가 길어지면 /compact 명령어로 압축·요약하기
- claude.md에는 AI가 알아야 할 정보만 넣기
4. Anthropic 공식 3대 원칙
원칙 1: 검증 수단을 줘라 테스트, 스크린샷, 기대 결과물을 함께 주면 AI가 스스로 검증할 수 있어 성능이 극적으로 올라갑니다.
원칙 2: 탐색 → 설계 → 구현 → 커밋 순서로 일해라 바로 코드를 짜게 하지 말고, Plan 모드로 설계 먼저 하고 구현하세요.
원칙 3: 구체적인 컨텍스트를 줘라 목적, 사용자 경험, 제약 조건을 명확하게 제시해야 합니다. 요구사항이 모호할수록 AI가 엉뚱한 방향으로 갑니다.
나쁜 예 좋은 예
| "커뮤니티 사이트 만들어줘" | "레딧 스타일 익명 커뮤니티, 로그인 없이 누구나 글 작성 가능, 카테고리별 분류" |
| "디자인 바꿔줘" | 스크린샷 첨부 후 "이거대로 해줘, 차이점 알아서 수정해" |
| "기능 하나 추가해줘" | "게시글에 좋아요 버튼과 카운트 표시, 중복 클릭 허용" |
5. claude.md 작성법
claude.md는 프로젝트 루트에 두는 파일로, Claude Code가 매 세션 시작 시 자동으로 읽는 파일입니다. 새로 합류한 팀원에게 주는 안내 문서라고 생각하면 됩니다.
넣어야 할 것 ✅
- 프로젝트 목적 (예: "레딧 스타일 익명 커뮤니티")
- 핵심 제약 조건 (예: "DB 없음, 로컬 JSON 파일로 저장, 인증 없음")
- AI가 코드만 봐서는 알 수 없는 고유 맥락
넣으면 안 되는 것 ❌
- AI가 코드를 보면 이미 알 수 있는 정보 (사용 언어, 실행 방법 등)
- 너무 추상적인 목적 ("최고의 UX 만들어줘")
- 자주 바뀌는 정보
- API 문서 전체 복붙 (링크만 주면 충분)
- 모순되는 정보 (성능 저하의 원인)
핵심 기준
"이 줄을 빼면 Claude가 실수를 할 수 있나?" → 그렇다면 남기고, 아니라면 과감하게 삭제
6. claude.md 관리 원칙
- 처음부터 완벽하게 만들려 하지 말 것
- /init 명령어로 자동 생성한 뒤 불필요한 내용 삭제하고 고유 맥락 추가
- 살아있는 문서로 코드처럼 지속적으로 관리·업데이트
- Claude가 자꾸 같은 실수를 하면 그때 항목을 추가
- 정말 중요한 규칙에만 IMPORTANT / You must 같은 강조 표현 사용 (남용 금지)
한 줄 요약: 프롬프트는 AI에게 하는 말이지만, 컨텍스트는 AI가 보는 세계다. 세계를 잘 설계하는 것이 말을 잘하는 것보다 중요하다.
6. 4단계 개발 사이클 (핵심 워크플로우)
실제 기능을 만들 때 반복하는 4단계입니다.
탐색 → 설계 → 구현 → 커밋
단계 모드 하는 일
| 탐색 (Explore) | Plan 모드 | 코드를 읽고 프로젝트 구조 파악 |
| 설계 (Plan) | Plan 모드 | 무엇을 어떻게 만들지 계획 수립 |
| 구현 (Implement) | Normal 모드 | 실제 코드 작성 및 수정 |
| 커밋 (Commit) | - | 변경사항 Git에 저장 |
모드 전환은 Shift + Tab 으로 합니다.
중요: Plan 모드에서는 코드를 단 한 글자도 수정할 수 없습니다. 읽고 분석만 가능합니다. 코드 수정은 반드시 Normal 모드에서만 됩니다.
7. 4단계를 매번 다 거칠 필요는 없다
간단한 수정은 그냥 바로 시키면 됩니다.
- 4단계 필요 없는 경우: "이 텍스트 대문자로 바꿔줘" 같은 단순 수정
- 4단계가 필요한 경우:
- 여러 파일을 건드려야 할 때
- 새로운 기능을 처음 만들 때
- 불확실하거나 미지의 영역을 다룰 때
8. 바로 코드를 짜게 하면 안 되는 이유
많은 사람들이 하는 가장 흔한 실수가 "로그인 기능 만들어줘"처럼 바로 코드를 짜게 시키는 것입니다.
악순환 구조:
- 맥락 없이 코드 생성 요청
- 내가 원하는 방식이 아닌 코드가 나옴
- 계속 수정 요청
- 컨텍스트가 실패한 시도들로 오염
- 성능 저하 → 원하는 결과에서 점점 멀어짐
AI는 확실하지 않아도 일단 빠르게 코드를 짜려는 습성이 있기 때문에, 방향이 잘못된 상태에서 코드를 짜면 오히려 고치는 데 시간이 더 걸립니다.
비유: 설계도 없이 벽돌부터 쌓는 건축은 없습니다. Plan 모드로 설계도를 먼저 그리고, Normal 모드로 벽돌을 쌓으세요.
9. Plan 모드 실전 활용법
Step 1. 프로젝트 예열
Claude Code를 처음 켰을 때 바로 작업을 시키지 말고, 먼저 프로젝트를 파악하게 합니다.
이 SvelteKit 프로젝트 구조 파악 좀!
Step 2. 구체적인 목적 전달
모호하게 말하지 말고 무엇을 왜 만드는지 맥락과 함께 전달합니다.
지금부터 Reddit 스타일 커뮤니티 만들 거야.
첫 번째 기능으로 카테고리 목록 조회와 생성 기능을 만들고 싶어.
Step 3. 작업 계획서 확인 후 승인
Claude가 세세한 작업 계획서를 작성하면, 확인 후 승인합니다. 이때 두 가지 선택지가 있습니다.
- 1번 선택 (권장): 컨텍스트를 비우고 작업 계획서만 가지고 구현 시작
- 2번 선택: 이전 대화 내용을 모두 유지한 채 구현 시작
대화가 길지 않다면 2번도 괜찮지만, 핑퐁이 많이 오갔다면 1번으로 컨텍스트를 정리하고 시작하는 게 유리합니다.
승인하면 Claude가 자동으로 Normal 모드로 전환해서 구현을 시작합니다. 따로 "구현해줘"라고 말할 필요가 없습니다.
10. 컨텍스트 비우기가 중요한 이유
Plan 모드에서 탐색하고 설계하는 과정에서 대화가 길어지면, 그 내용들이 컨텍스트 윈도우를 차지합니다. 하지만 충분한 작업 계획서가 완성된 순간, 그 이전 대화는 사실상 쓸모가 없어집니다.
핵심: 좋은 작업 계획서 하나가 있으면, 그 이전의 긴 대화 내용은 노이즈입니다. 과감하게 비우고 계획서만 가지고 구현을 시작하는 것이 컨텍스트 관리의 핵심입니다.
11. AI 자가 검증 도구 (bun run check)
구현이 끝난 후 Claude Code가 스스로 bun run check 같은 검증 명령어를 실행하는 장면이 나옵니다. 이것이 바로 챕터 2에서 말한 "AI에게 검증 수단을 줘라" 의 실제 적용 사례입니다.
코드를 짠 뒤 Claude가 스스로 오류를 체크하게 만드는 것으로, 사람이 일일이 확인하지 않아도 AI가 결과물을 자체 검증하고 문제가 있으면 스스로 수정할 수 있게 됩니다.
검증 수단이 있으면 → AI가 스스로 틀린 걸 잡아냄 → 품질이 올라감
