Claude Code의 Skills를 사용하여 테스트 자동 생성을 효율화하는 5가지 테크닉

「테스트 코드를 작성하는 것이 귀찮다」, 「AI에게 맡겨봤지만 엉뚱한 테스트가 생성된다」라고 느낀 적이 없으신가요?

Claude Code의 Skills 기능을 능숙하게 사용하면, 테스트 자동 생성의 정밀도와 속도가 극적으로 변합니다. 이 기사에서는 제가 실제로 시행착오를 거치며 찾아낸 테스트 자동 생성을 효율화하는 5가지 테크닉을 소개합니다. 다 읽을 때쯤에는 「Skills는 이렇게 사용하면 됐던 거구나」라며 납득하게 될 것입니다.

테스트 자동 생성에서 잘 풀리지 않아 고민하고 계시지는 않나요?

결론부터 말씀드리면, 생성되는 테스트의 품질은 「Claude에게 프로젝트의 컨텍스트 (Context)를 얼마나 Skills를 통해 전달할 수 있는가」에 의해 거의 결정됩니다.

관점	내용
Point (결론)	테스트 품질은 Skills의 문맥 설계로 결정된다
Reason (이유)	Claude는 매번 코드를 읽는 것이 아니라 Skills의 정보를 우선적으로 참조하기 때문
Example (예)	테스트 프레임워크나 명명 규칙을 명시하면 생성물이 단번에 통일된다
Point (재결론)	Skills에 「프로젝트 고유의 전제 조건」을 쓰는 것만으로 정밀도가 급상승한다

Claude는 우수하지만, 「이 프로젝트가 어떤 테스트 전략을 채택하고 있는지」, 「어떤 프레임워크를 사용하고 있는지」, 「어떤 명명 규칙이 있는지」는 지정하지 않으면 추측할 수밖에 없습니다.

추측으로 생성된 테스트는 동작할 때도 있지만, 완전히 엉뚱할 때도 있습니다. 저는 이것을 몇 번이나 경험했습니다. 매번 「이 프로젝트에서는 〇〇를 사용하고 있습니다」라고 전달하는 것은 비효율적이며, 잊어버리면 즉시 문제가 됩니다.

Skills에 한 번 프로젝트의 전제를 써두면, 그 후에는 Claude가 매번 「이 프로젝트의 규칙」을 참조하면서 테스트를 생성해 줍니다. 즉, Skills는 팀의 암묵지 (Implicit Knowledge)를 명문화하는 장소이기도 한 셈입니다.

가장 먼저 해야 할 일은 이것입니다. Claude가 테스트를 생성할 때, 프레임워크 지정이 없으면 Jest로 쓰거나 Vitest로 쓰는 등 매번 제각각이 됩니다.

## 사용 테스트 프레임워크
- Unit Test: Vitest
- E2E Test: Playwright
...

◎ 이것만으로 생성되는 테스트의 「외관」이 단번에 통일됩니다. 코드 리뷰의 부하도 줄어들기 때문에 팀에서 사용할 경우 특히 효과적입니다.

설정 전	설정 후
❌ 프레임워크가 매번 제각각	✅ 항상 Vitest로 통일됨
...

「어디까지 테스트를 작성할 것인가」에 대한 방침이 없으면, Claude는 과도하게 테스트를 생성하거나, 반대로 중요한 케이스를 놓치기도 합니다.

## 커버리지 (Coverage) 방침
- 정상계 · 이상계 · 경계값의 3가지 패턴을 반드시 커버할 것
- private 메서드는 직접 테스트하지 않고, public 메서드를 경유하여 검증할 것
...

저는 이것을 쓰기 전, 「왠지 테스트가 부실하다」고 느끼면서 매번 수동으로 이상계를 추가하곤 했습니다. 방침을 명시한 후에는 처음부터 3가지 패턴이 갖춰진 상태로 생성되게 되었습니다.

「모킹 (Mocking) 해주세요」라고 전달해도, 프로젝트에서 사용 중인 모킹 방식과 다른 코드가 생성될 때가 있습니다. 이는 Claude가 프로젝트 고유의 모킹 패턴을 모르기 때문입니다.

## 모킹 작성법 (샘플)
### 외부 API 모킹 예시
typescript
...

◎ 샘플 코드를 SKILL.md에 넣어두면, Claude가 「이 프로젝트의 모킹은 이렇게 작성한다」라고 학습한 상태에서 테스트를 생성해 줍니다. 몇 줄의 샘플이 생성 품질을 크게 끌어올립니다.

Skills의 description (설명)이 모호하면, 테스트 생성 Skill이 의도하지 않은 상황에서 발화하거나, 반대로 사용되지 않을 수 있습니다.

# ✅ description 작성 예시
description: |
TypeScript · React 프로젝트의 유닛 테스트를 자동 생성하는 Skill.
...

조건의 종류	작성해야 할 내용
✅ 발화시키고 싶은 상황	「테스트를 작성해줘」, 「~의 테스트를 생성해줘」
...

생성된 테스트를 그대로 사용하면, assertion (단언)이 느슨하거나 에러 메시지가 성의 없을 수 있습니다. Claude에게 「생성 후에 스스로 체크할 항목」을 정의해 두면 품질이 더욱 올라갑니다.

테스트 생성 후 셀프 체크리스트

Claude는 반드시 다음 사항을 확인한 후 테스트 코드 (test code)를 출력할 것.

• 정상계(Normal case), 이상계(Abnormal case), 경계값(Boundary value)이 모두 포함되어 있는가
  ...

◎ 이 체크리스트를 넣은 이후로, "생성된 테스트가 통과하지 않는다", "assertion이 toBeTruthy()로만 되어 있다"와 같은 문제가 거의 사라졌습니다.

테크닉	효과
✅ 프레임워크 및 명명 규칙 (Naming convention) 명시	생성물의 형식이 통일됨
...

Skills에 프로젝트의 전제 조건을 명확히 작성해 두는 것만으로도 테스트 자동 생성의 경험은 크게 달라집니다. 초기 설정에 30분을 투자하면, 이후의 시간을 몇 배나 절약할 수 있습니다. 꼭 시도해 보세요.