테스트 코드를 정성 들여 짜본 적이 없습니다. 부끄럽지만 사실이에요. 맨날 구현에만 집중하다 보니 테스트는 늘 뒷전이었는데, 어디선가 "테스트를 먼저 짜라"는 말을 듣고 한번 해볼까 싶었습니다. 마침 Claude Code에 Skill이라는 기능이 있길래, TDD Skill을 골라서 써봤어요.
결론부터 말하면, Skill 파일을 열어보고 핵심만 추리다가 중간에 멈췄습니다. 왜냐면 원문이 너무 잘 쓰여져 있어서 제가 요약하는 게 오히려 손해더라고요. 그래서 이 글은 "뜯다 말기"입니다.
Skill이 뭔데?
Claude Code를 쓰다 보면 매번 같은 지침을 프롬프트에 넣을 때가 있잖아요. "테스트 먼저 짜", "커밋 메시지 이렇게 써", "리팩토링할 때 이 순서로 해" 같은 것들. Skill은 그걸 미리 마크다운 파일로 등록해두는 기능이에요. 불러오면 Claude가 그 지침대로 움직입니다.
매번 입력할 필요 없이 한 번만 정리해두면 끝. 꽤 편합니다.
뭘 골랐냐면
GitHub 스타 112k짜리 obra/superpowers 레포. 여기에 있는 스킬 중에서 test-driven-development를 골랐습니다. 이유요? 스타가 많으니까요.
🔗 obra/superpowers - test-driven-development
TDD 30초 요약
TDD 모르시는 분들을 위해 간단히. 코드보다 테스트를 먼저 짜는 방식입니다.
기존: 코드 짜기 → 에러 → 수정 → 또 에러 → 무한 반복
TDD: 합격 기준부터 정하기 → 당연히 실패 → 통과할 만큼만 코드 짜기 → 정리
"아이디 admin, 비밀번호 1234로 로그인하면 성공해야 함"
이 테스트를 먼저 써두고, 당연히 실패하고(🔴 Red), 딱 통과할 정도로만 코드를 짜고(🟢 Green), 그다음 정리하는(🔵 Refactor) 순서예요. 방향을 먼저 세워두니까 코드가 산으로 안 갑니다.
Skill 파일 열어봤더니
MD 파일 열었는데 목차가 이렇습니다:
- Overview
- When to Use
- The Iron Law
- Red-Green-Refactor
- Good Tests
- Why Order Matters
- Common Rationalizations
- Red Flags - Stop and Start Over
- Example: Bug Fix
- Verification Checklist
- When Stuck
- Debugging Integration
- Testing Anti-Patterns
- Final Rule
14개 섹션. 이걸 매번 프롬프트에 직접 치고 있었다고 생각하면 아찔하죠. Skill 기능이 왜 필요한지 바로 체감됩니다.
구조를 뜯어보면
처음부터 간단하게 봐보면 크게 세 덩어리로 나뉩니다.
첫 번째 — 기본 원칙 세우기. 언제 쓸지(When to Use), 어떻게 할지(The Iron Law), 무엇을 할지(Red-Green-Refactor), 왜 이 순서인지(Why Order Matters)를 먼저 짚어줍니다. TDD의 뼈대를 세우는 부분이에요.
두 번째 — Claude가 빠지기 쉬운 함정 차단. Good Tests, Common Rationalizations, When Stuck 같은 섹션들이 여기에 해당합니다. 이게 왜 필요하냐면, Claude는 TDD를 하다가 "이건 너무 단순해서 테스트 안 짜도 될 것 같은데..."라고 스스로 합리화하거나, 순서를 건너뛰려는 경향이 있거든요. 그걸 미리 차단하는 장치입니다.
세 번째 — 예시와 지침으로 다시 한번 강조. Example: Bug Fix, Verification Checklist, Testing Anti-Patterns 등으로 앞에서 설명한 원칙들을 구체적인 사례와 체크리스트로 못 박아둡니다.
원칙 → 함정 차단 → 예시로 못 박기. 이 흐름이 인상적이었어요.
사실 제가 느끼기에 Claude는 빅테크 언어모델 중에서 꽤 고집이 센 편입니다. 비생산적이라고 판단하면 아무리 강하게 말해도 잘 안 들어요. 반대로 말하면 "왜 이게 논리적인지"를 납득시켜야 따라온다는 뜻이기도 합니다. Skill 작성자도 그걸 아는 것 같아요. 사람이 읽어도 자연스럽게 설득되는 논리 구조로 짜여져 있어서, 나중에 나만의 Skill을 만들 때 레퍼런스로 삼기 딱 좋겠다 싶었습니다.
핵심만 추리면 이 정도
- 새 기능, 버그 수정, 리팩토링 — 항상 TDD
- 사람이 "이번만 스킵" 하면 스킵 (말은 잘 들음)
- Iron Law: 테스트 실패 먼저 → 그다음 코드. "다 통과했으니 괜찮겠지"를 방지하는 순서 규칙
- Red-Green-Refactor 엄수
- 🔴 Red: 실패하는 테스트 먼저
- 🟢 Green: 겨우 통과하는 미니멀 코드
- 🔵 Refactor: 정리 (중복 제거, 이름 정리)
여기서 뜯기를 멈춘 이유
솔직히 더 요약하려다가 그만뒀습니다. 원문 자체가 너무 잘 써져 있어요. 제가 풀어 쓰면 오히려 질이 떨어질 것 같았거든요.
실제로 써보니 "테스트부터"라는 규칙 하나만으로도 개발 흐름이 확 달라지더라고요. 뭘 만들어야 하는지 먼저 정의하고 시작하니까요. 그리고 Claude가 이 Skill을 따를 때 정말 착실하게 Red → Green → Refactor를 지키는 게 꽤 인상적이었습니다.
나머지는 직접 읽어보세요. 제가 뜯다 만 데서부터가 진짜 알맹이입니다.
🔗 원문 보러가기