테스트 분류로 설계하는 위험 기반 품질 전략

테스트 설계의 핵심 축

테스트 분류는 테스트 활동을 목적과 기법의 관점, 실행 메커니즘인 수행 방식, 적용 범위인 대상으로 나누어 계획·설계·운영을 모듈화하는 방법이다. 제품의 특성과 릴리스 목표가 바뀌어도 필요한 검증 조합을 빠르게 구성하는 데 쓴다.

관점은 어떤 시각과 기법으로 확인할지를, 수행 방식은 테스트를 어떻게 실행·자동화·검토할지를, 대상은 무엇을 어느 수준까지 검증할지를 결정한다.

관점에 따라 달라지는 검증 방식

기법 기준으로는 블랙박스, 화이트박스, 그레이박스를 구분한다. 블랙박스는 명세를 기반으로 하고, 화이트박스는 구조를 기반으로 하며, 그레이박스는 부분적인 내부 지식을 활용한다. 이 선택에 따라 결함을 발견하는 위치와 근본 원인을 추적하는 방식이 달라진다.

품질 속성 기준에서는 기능 테스트와 비기능 테스트를 분리한다. 비기능 영역에는 성능·보안·신뢰성·사용성 등이 포함되며, NFR 명세 및 SLO/SLA와의 연결이 핵심이다.

목적 기준에서는 Verification과 Validation을 나눈다. Verification은 요구사항과 설계에 대한 정확성을, Validation은 비즈니스 가치 충족을 다룬다. 규제 준수와 사용자 가치의 관점을 분리해 운영할 수 있다.

실행 방식은 발견 능력과 재현성의 균형이다

정적 테스트는 리뷰와 정적 분석으로 결함 유입을 막고, 동적 테스트는 실행을 통해 런타임 결함을 찾는다. 둘은 대체 관계가 아니라 보완 관계다.

수동 테스트는 탐색과 맥락 판단에 강점이 있고, 자동화는 반복·회귀·규모 확장에 적합하다. 자동화 대상은 ROI 기준으로 우선순위를 정할 필요가 있다. 탐색적 테스트는 히ュー리스틱을 바탕으로 빠르게 학습하고 발견하며, 스크립트 기반 테스트는 재현성과 감사 추적성을 확보한다.

검증 대상을 레벨과 계층으로 나눈다

테스트 레벨은 단위(Unit), 통합(Integration), 시스템(System), 인수(Acceptance)로 상향 구성할 수 있으며, V-Model 및 CI 파이프라인과 정렬할 수 있다.

검증 계층은 UI, API, 서비스/도메인, 데이터/DB, 인프라/네트워크로 나뉜다. 변경 영향 범위에 따라 얕은 스모크 테스트와 깊은 회귀 테스트를 섞어 적용한다. 신규 기능, 리팩터링, 구성·인프라 변경처럼 변경 유형이 달라질 때도 범위와 깊이를 달리한다.

커버리지 공백을 줄이는 분류 체계

관점·수행·대상은 서로 독립적인 축이다. 세 축을 조합하면 상황에 맞는 테스트를 설계하면서 중복과 공백을 줄일 수 있다.

요구사항, 아키텍처, 위험 항목을 각 축에 연결하면 커버리지 매트릭스를 만들 수 있다. 결함 유출이 발생했을 때 누락된 검증 지점을 확인하고 대응 루프를 빠르게 닫는 데도 도움이 된다.

레벨과 계층은 빌드·배포 단계에 맞춰 정렬한다. 프리커밋에서는 정적 테스트와 단위 테스트를, PR에서는 통합 테스트를, 릴리스 전에는 시스템 테스트와 비기능 테스트를 배치한다. 프로덕션에서는 카나리아와 헬스체크를 가드로 활용한다.

변경 성격에 따른 조합

커머스 결제 기능을 새로 도입할 때는 기능 정합성, 성능·보안 같은 비기능 요소, 핵심 정산 모듈의 화이트박스 관점을 함께 둔다. 시퀀스와 정산 로직은 정적으로 검토하고, 결제 플로우는 동적 E2E로 확인한다. 회귀와 가맹사별 파라메트릭 검증은 자동화하며, API·서비스 중심의 통합 테스트에서 시스템 테스트와 외부 PG 연동 인수 시나리오로 이어간다. 스모크 세트는 배포 안정성을 확인하는 역할을 맡는다.

모바일 앱 성능을 최적화할 때는 응답·전력·메모리 같은 비기능 관점과 블랙박스 UI 체감 지표가 중심이 된다. 프로파일링과 벤치마크는 동적 자동화로 수행하고, UX 지연 구간은 수동 탐색으로 찾는다. 대상은 UI의 스크롤·전환, API 백엔드 병목, 이미지·CDN 경로까지 걸친다.

모놀리스에서 마이크로서비스로 전환하는 상황에서는 회귀 위험과 계약 기반(Consumer-Driven Contract) 검증이 중요하다. 설계 리뷰와 스키마 차이 분석을 정적으로 수행하고, CDC 및 API 계약 테스트를 동적 자동화에 포함한다. 서비스 경계 통합, 데이터 마이그레이션 검증, 카나리아 릴리스 가드를 함께 다룬다.

금융·메드테크처럼 규제와 안전이 중요한 도메인에서는 Verification을 표준과 감사 관점에서, Validation을 사용자 가치 관점에서 운영한다. 트레이서빌리티와 문서 리뷰는 정적으로, 형식적 시나리오와 증적 캡처는 동적으로 수행한다. 요구사항과 테스트를 일대일로 매핑하고 변경 영향에 맞춰 증적을 보강한다.

위험 우선순위가 만드는 효과

위험 기반 조합은 변경 규모, 비즈니스 임팩트, 가시성을 기준으로 관점·수행·대상의 가중치를 조정하는 방식이다. 이 접근에서는 결함 유출률이 30~60% 감소하고, 상위 20% 케이스가 80% 결함을 포착한다.

자동화된 회귀와 스모크 테스트는 리드타임을 20~40% 단축하며, 배포 빈도와 안정성을 함께 개선한다. 커버리지 매트릭스를 결함 밀도, MTTR, 안정성 SLO와 정렬하면 품질 상태도 더 명확하게 볼 수 있다.

분류부터 계획까지의 흐름

⤢✕

수행 방식별 운영 적합도

수행 방식	성능(실행 속도)	확장성(대상/데이터)	일관성(재현성)	안정성(변경 내성)	운영 편의(유지비)
수동	낮음	낮음	중간	중간	중간
자동화	높음	높음	높음	높음	초기 높음/장기 낮음
탐색적	중간	중간	낮음	중간	높음

탐색적 테스트는 고위험 영역을 일찍 찾는 데 강점이 있다. 자동화는 회귀와 스모크 테스트에 적합하며, 수동 테스트는 새로운 UX와 맥락 판단이 필요한 경우에 유효하다.

운영에서 조정할 지점

위험 기반으로 조합을 설계할 때는 과도한 자동화 투자에 대한 회수 기간을 산정해야 한다. 테스트 피라미드는 단위 테스트를 다수로 두고 통합 테스트와 소수의 E2E 테스트로 이어지는 비율을 유지한다. UI E2E를 과도하게 사용하면 불안정성과 운영비가 급증할 수 있다.

시드 데이터와 계약 테스트는 CI에 통합하고, 외부 연동은 모킹과 실제 연동 검증의 비율을 균형 있게 유지한다. 이 기준을 바탕으로 테스트 분류를 운영하면 신규 기능, 대규모 변경, 규제 대응에서 필요한 검증 범위를 일관되게 조정할 수 있다.