현대적 테스트 전략: Pyramid, Contract, E2E의 균형
실무에서 문제는 테스트가 적어서가 아니라, 느린 스위트와 흐릿한 소유권, flaky한 게이트, 비싼 계층으로 밀려 올라간 결함 때문에 생기는 경우가 더 많습니다.
신뢰도는 개수보다 배치에서 나옵니다
좋은 테스트 전략은 먼저 한 가지 질문에 답합니다. 이 종류의 버그는 어디에서 처음 실패해야 하는가?
보통은 다음처럼 나뉩니다.
- unit test: 순수 로직, 계산, 비즈니스 규칙
- integration test: 프레임워크, DB, 인프라 경계
- contract test: 서비스 간 계약과 스키마 호환성
- E2E test: 정말 중요한 사용자 여정
모든 검증이 E2E로 올라가면 스위트는 비싸고 느려집니다. 반대로 모든 것을 unit만으로 해결하려 하면 통합과 계약 리스크가 증명되지 않습니다.
Pyramid는 여전히 유효하지만 중간 계층이 더 중요해졌습니다
현대적인 테스트 피라미드는 여전히 값싼 테스트를 많이, 비싼 테스트를 적게 두는 방향이 맞습니다. 다만 분산 시스템과 API 중심 구조에서는 중간 계층의 중요성이 훨씬 커졌습니다.
실무적으로는 보통 다음이 필요합니다.
- unit test는 가장 빠른 피드백 루프를 담당
- integration test는 프레임워크와 영속성 동작을 검증
- contract test는 시스템 간 드리프트를 줄임
- E2E test는 브라우저와 사용자 흐름의 최종 증명을 담당
한 계층을 만능 해법처럼 쓰는 순간 전략은 약해집니다.
Contract test는 실제 운영 공백을 메웁니다
API, 이벤트, 마이크로서비스가 있는 구조에서는 unit과 integration만으로는 한 시스템의 변경이 다른 시스템 기대와 여전히 맞는지 증명하기 어렵습니다.
Contract test는 특히 다음을 검증하는 데 유용합니다.
- 요청/응답 스키마 호환성
- 소비자 기대치와 제공자 변경의 일치
- 이벤트 payload 필드 보장
- 점진적 롤아웃 중 backward compatibility
이 계층이 약하면 결함은 대개 스테이징이나 늦은 통합 환경에서야 드러납니다.
E2E는 비즈니스 핵심 여정만 맡겨야 합니다
E2E는 실제 UI와 서비스 스택을 통과하는 사용자 흐름을 증명해준다는 점에서 강합니다. 대신 환경 구성, 테스트 데이터, 브라우저 타이밍, 다계층 의존성 때문에 가장 비싼 계층이기도 합니다.
강한 E2E는 보통 다음에 집중합니다.
- 로그인과 접근 제어 핵심 흐름
- 결제와 체크아웃
- 권한 민감 워크플로
- 비즈니스가 깨진 채로 배포할 수 없는 최상위 여정
브라우저 수준에서 모든 것을 검증하려 들면 E2E는 금방 느리고 brittle해집니다.
CI 게이트는 속도와 목적에 따라 분리해야 합니다
건강한 배포 시스템은 모든 테스트를 하나의 동일한 게이트로 다루지 않습니다.
실무적으로는 자주 다음처럼 나눕니다.
- PR 피드백: 빠른 unit + 일부 integration
- merge/branch gate: 더 넓은 integration + contract
- release gate: 선택된 E2E + 고신뢰 환경 검증
이렇게 해야 개발자 피드백은 빠르고, 릴리스 검증은 엄격하게 유지됩니다.
Flaky test는 운영 문제입니다
Flaky test는 사소한 귀찮음이 아니라 CI 신뢰를 무너뜨리는 운영 문제입니다.
성숙한 전략은 최소한 다음을 정의합니다.
- 누가 flaky test를 소유하는가
- 언제 quarantine 하는가
- 실패를 어떻게 triage 하는가
- quarantine 상태를 얼마나 오래 허용하는가
재실행해서 초록불만 확인하는 문화가 생기면 스위트는 이미 신뢰를 잃은 상태입니다.
실패 진단 시간은 짧아야 합니다
좋은 테스트 스위트는 실패했을 때 원인을 빠르게 좁혀줍니다.
이를 위해 보통 다음이 필요합니다.
- 행동 기준의 명확한 테스트 이름
- 읽기 쉬운 assertion
- 작고 집중된 시나리오
- 계층 간 과도한 중복 제거
테스트가 많아도 실패 설명에 오래 걸리면 가치가 크게 떨어집니다.
흔한 안티패턴
실무에서는 다음 패턴이 자주 전략을 약하게 만듭니다.
- coverage 수치를 주된 성공 지표로 삼음
- 약한 unit/contract를 E2E로 메우려 함
- 모든 테스트를 모든 커밋에서 같은 규칙으로 돌림
- flaky 실패를 rerun 문화로 정상화
- 깨진 테스트의 소유권이 없음
이런 구조는 비용만 늘리고 신뢰도는 충분히 만들지 못합니다.
리뷰 체크리스트
전략이 건강한지 보려면 최소한 다음을 물어야 합니다.
- 각 계층이 잡아야 할 결함 종류가 명확한가
- 싼 계층이 실제로 잡을 수 있는 문제를 먼저 잡고 있는가
- 시스템 간 의존이 있는 곳에 contract coverage가 있는가
- E2E가 정말 브라우저 증명이 필요한 여정만 맡고 있는가
- flaky test에 대한 소유권과 quarantine 정책이 있는가
마무리
테스트 전략의 본질은 수량이 아니라 배치입니다. 어떤 결함이 어디에서 먼저 실패해야 하는지 더 의식적으로 설계할수록, 전체 전달 시스템은 더 저렴하고 더 신뢰 가능해집니다.
Continue Reading
다음으로 읽기 좋은 글
플레이키 테스트 신호 예산 관리
불안정한 테스트를 단순 재시도로 덮지 않고 신뢰도, 소유권, 격리 기준으로 관리하는 방법을 정리합니다.
🧪 Test릴리스 후보 테스트 컷라인 설계
모든 테스트를 다 돌리는 것과 안전하게 배포하는 것은 다릅니다. 릴리스 후보에서 어떤 테스트를 통과 기준으로 삼아야 할지 정리합니다.
🔧 Tools팀 개발 워크플로 자동화 플레이북
로컬 검사, PR CI, 스캐폴딩, 릴리스 단계, 문서화 자동화를 어떻게 나눠 설계해야 팀의 인지 부하를 줄이면서도 우회가 적은 자동화 체계를 만들 수 있는지 정리합니다.
🚀 DevOpsKubernetes 심화 — HPA, Resource 관리, Pod Scheduling
Kubernetes 운영을 설정 모음이 아니라 자원 배치와 장애 복원력의 관점에서 정리합니다. requests/limits, HPA, affinity, taint, PDB, probe를 언제 어떻게 써야 하는지 실무적으로 설명합니다.
다음 탐색