코드를 작성하고 나면 항상 따라오는 질문이 있다. “테스트는 충분한가?” 대부분의 개발자는 유닛 테스트 몇 개를 작성하고 넘어가거나, 시간에 쫓겨 테스트를 아예 건너뛰기도 한다. 하지만 실제 프로덕션에서 문제를 일으키는 것은 단위 테스트로는 잡을 수 없는 영역에서 발생한다.
이 글에서는 왜 종합적인 테스트가 필요한지, 그리고 이를 자동화하기 위해 만든 Claude Code 스킬 Full Test Orchestrator를 소개한다.
TL;DR
- 코드 구현 후 테스트는 10개 도메인(Unit, API, Integration, E2E, Security, Accessibility, Performance, Load/Stress, Smoke, Chaos)을 모두 커버해야 한다.
- 수동으로 하면 누락과 편향이 불가피하다. 자동화가 답이다.
- Full Test Orchestrator는 3-Agent 병렬 실행으로 10개 도메인의 시나리오, 케이스, 코드를 자동 생성한다.
- 커버리지 98% 이상, 9가지 품질 기준을 목표로 한다.
- GitHub: greeun/full-test-orchestrator
왜 종합적인 테스트가 필요한가
유닛 테스트만으로는 부족하다
많은 프로젝트에서 “테스트 작성”이라 하면 유닛 테스트를 떠올린다. 함수 하나가 올바른 값을 반환하는지 확인하는 것이다. 물론 중요하다. 하지만 실제 장애의 대부분은 유닛 테스트가 커버하지 못하는 곳에서 발생한다.
| 장애 유형 | 유닛 테스트로 발견 가능? | 필요한 테스트 도메인 |
|---|---|---|
| SQL Injection 취약점 | ❌ 불가능 | Security |
| 동시접속 1000명 시 서버 다운 | ❌ 불가능 | Load/Stress |
| 스크린리더가 폼을 읽지 못함 | ❌ 불가능 | Accessibility |
| 배포 후 로그인 불가 | ❌ 불가능 | Smoke |
| DB 연결 끊김 시 앱 크래시 | ❌ 불가능 | Chaos |
| 페이지 로드 8초 소요 | ❌ 불가능 | Performance |
| 모듈 A-B 연동 시 데이터 손실 | ❌ 불가능 | Integration |
유닛 테스트의 모든 항목이 통과해도 프로덕션에서 장애가 발생할 수 있다. 이것이 종합적인 테스트가 필요한 근본적인 이유다.
10개 테스트 도메인이라는 답
소프트웨어 품질을 제대로 검증하려면 기능적 테스트, 비기능적 테스트, 복원력 테스트를 모두 수행해야 한다. 이를 10개 도메인으로 체계화했다.
| # | 도메인 | 검증 대상 | 핵심 질문 |
|---|---|---|---|
| 1 | Unit | 함수/모듈 격리 검증 | 이 함수가 올바른 값을 반환하는가? |
| 2 | API | 엔드포인트 요청/응답 | API 계약이 지켜지는가? |
| 3 | Integration | 모듈 간 연동 | 모듈 A와 B가 함께 작동하는가? |
| 4 | E2E | 전체 사용자 흐름 | 사용자가 로그인에서 결제까지 완료할 수 있는가? |
| 5 | Security | OWASP Top 10 | 공격자가 시스템을 뚫을 수 있는가? |
| 6 | Accessibility | WCAG 2.1 AA | 장애를 가진 사용자도 이용할 수 있는가? |
| 7 | Performance | LCP, FID, TTFB | 사용자가 느리다고 느끼지 않는가? |
| 8 | Load/Stress | 동시접속, TPS | 1000명이 동시에 써도 버티는가? |
| 9 | Smoke | 배포 후 핵심 경로 | 배포 직후 핵심 기능이 작동하는가? |
| 10 | Chaos | 장애 주입 복원력 | DB가 죽어도 앱이 살아남는가? |
수동 테스트의 한계
10개 도메인을 모두 수동으로 테스트하면 어떻게 될까? 현실적으로 불가능에 가깝다.
수동 테스트가 실패하는 3가지 이유
| 문제 | 원인 | 결과 |
|---|---|---|
| 누락 | 10개 도메인을 매번 기억하고 수행하기 어려움 | Security, Accessibility, Chaos 등이 빠짐 |
| 편향 | 개발자는 자신이 작성한 코드의 happy path만 테스트하는 경향 | 경계값, 에러 케이스 미검증 |
| 시간 | 10개 도메인 순차 수행 시 수 시간 소요 | 결국 “나중에 하자”가 되어 영영 안 함 |
특히 세 번째 문제인 시간이 가장 치명적이다. 구현에 3시간이 걸렸는데 테스트에 5시간을 쓸 수 있는 개발자는 많지 않다. 결국 테스트는 후순위로 밀리고, 프로덕션에서 문제가 터진 후에야 급하게 작성하게 된다.
Full Test Orchestrator: 자동화된 해결책
이 문제를 해결하기 위해 Full Test Orchestrator라는 Claude Code 스킬을 만들었다. 핵심 아이디어는 간단하다.
핵심 아이디어
- 코드를 분석하여 테스트 대상을 자동으로 파악한다.
- 10개 도메인의 테스트 시나리오, 케이스, 코드를 한 번에 생성한다.
- 3개 Agent 병렬 실행으로 시간을 단축한다.
- 문서와 코드를 분리하여 시나리오/케이스는 tests/doc/에, 코드는 tests/에 배치한다.
5-Phase 워크플로우
| Phase | 작업 | 실행 방식 | 산출물 |
|---|---|---|---|
| A | 코드 분석 | 순차 | 분석 컨텍스트 (모든 Agent에 공유) |
| B | 테스트 문서 생성 | 3-Agent 병렬 | tests/doc/scenarios/*.md, tests/doc/testcases/*.md |
| C | 테스트 코드 생성 | 3-Agent 병렬 | tests/**/*.test.*, Test Preparation Report |
| D | 테스트 실행 검증 | 3-Agent 병렬 | Test Execution Report |
| E | 리포트 표시 | 순차 | 준비 리포트 + 실행 리포트 |
병렬 Agent 그룹
10개 도메인을 3개 Agent에 분배하여 병렬로 실행한다. 그룹핑 기준은 도메인 간의 관련성이다.
| Agent | 담당 도메인 | 그룹핑 이유 |
|---|---|---|
| Agent 1 | Unit + API + Smoke | 빠르고 격리된 테스트 – 빠른 피드백 |
| Agent 2 | Integration + E2E | 흐름 기반 테스트 – 통합 컨텍스트 공유 |
| Agent 3 | Security + Accessibility + Performance + Load/Stress + Chaos | 비기능/복원력 테스트 – 품질/보안 컨텍스트 공유 |
9가지 품질 기준
생성된 모든 테스트는 9가지 품질 기준으로 측정된다. “테스트를 작성했다”는 것만으로는 부족하다. 그 테스트가 좋은 테스트인지까지 검증해야 한다.
| 기준 | 목표 | 의미 |
|---|---|---|
| 커버리지 | line 98%+, branch 90%+ | 코드의 거의 모든 경로를 테스트 |
| 독립성 | 테스트 간 의존 0 | 어떤 순서로 실행해도 동일 결과 |
| 결정성 | flaky 0건 | 같은 코드에 항상 같은 결과 |
| 경계값 | null, empty, max 포함 | edge case까지 빈틈없이 검증 |
| 실패 명확성 | 기대값/실제값 포함 | 실패 시 원인을 즉시 파악 가능 |
| 실행 속도 | unit < 1s, e2e < 30s | CI에서 빠르게 피드백 |
| 보안 | OWASP Top 10 커버 | 주요 공격 벡터 차단 확인 |
| 접근성 | WCAG 2.1 AA 통과 | 모든 사용자가 이용 가능 |
| 성능 | LCP < 2.5s, FID < 100ms | 사용자 체감 속도 보장 |
2개의 분리된 리포트
테스트 준비(코드 생성)와 테스트 실행 결과를 분리하여 리포트한다. 준비 리포트에서 생성된 테스트의 양과 구조를 확인하고, 실행 리포트에서 실제 pass/fail 결과와 품질 기준 달성 여부를 확인한다.
| 구분 | Test Preparation Report | Test Execution Report |
|---|---|---|
| 시점 | Phase C 완료 후 | Phase D 완료 후 |
| 내용 | 시나리오/케이스/파일 수, 라인 수 | pass/fail 수, 커버리지, 소요 시간 |
| 목적 | “무엇이 만들어졌는가” | “결과가 어떤가” |
| 품질 기준 | 포함하지 않음 | 9가지 기준 달성 여부 표시 |
사용법
어떤 프로젝트에서든 Claude Code 세션에서 다음 키워드로 트리거할 수 있다.
| 언어 | 트리거 키워드 예시 |
|---|---|
| 한국어 | 테스트 작성, 테스트 생성, 모든 테스트, 커버리지, 검증, QA 검증 |
| English | write tests, generate tests, create test suite, coverage, QA |
특정 도메인만 선택적으로 실행할 수도 있다.
# 전체 10개 도메인
"테스트 작성해줘"
# 특정 도메인만
"unit이랑 security 테스트만 만들어줘"프로젝트 구조
full-test-orchestrator/
├── SKILL.md # 메인 워크플로우 지침
├── README.md # 영문 문서
├── README.ko.md # 한국어 문서
├── references/
│ ├── test-domains.md # 10개 도메인 상세 가이드
│ ├── quality-criteria.md # 9가지 품질 기준
│ ├── doc-templates.md # 문서 구조 규칙
│ ├── parallel-strategy.md # 병렬 실행 전략
│ └── report-format.md # 리포트 템플릿
└── assets/templates/
├── scenario-template.md # 시나리오 문서 템플릿
└── testcase-template.md # 테스트 케이스 문서 템플릿결론
테스트는 “시간이 남으면 하는 것”이 아니라 “코드 작성의 일부”다. 하지만 10개 도메인을 매번 수동으로 커버하는 것은 현실적으로 불가능하다. Full Test Orchestrator는 이 간극을 메운다.
- 매 세션마다 자동으로 종합 테스트를 생성하여 누락을 방지한다.
- 3-Agent 병렬 실행으로 시간 부담을 최소화한다.
- 9가지 품질 기준으로 테스트의 품질 자체를 보장한다.
- 프로젝트의 기존 프레임워크를 자동 감지하여 추가 설정 없이 바로 사용할 수 있다.
“테스트 작성해줘” 한 마디면 된다.