Sanity 테스트로 빌드 적합성을 판정하는 품질 게이트

전체 테스트에 앞서 빌드를 걸러내는 검토

Sanity 테스트는 새로운 소프트웨어 빌드가 Regression, System, UAT 같은 본격적인 테스트를 받을 만큼 적합한지 빠르게 가르는 사전 검토다. 변경 범위와 필수 경로를 제한적으로 깊게 확인하며, Regression 테스트의 하위 집합으로서 파이프라인의 품질 게이트 역할을 맡는다.

목표는 빌드 안정성과 기능 적합성을 확인하고, 전체 테스트에 투입할 시간 대비 가치가 있는지 Go/No-Go로 판정하는 데 있다. 대상은 변경 영향도가 큰 소수의 기능과 시나리오다.

변경 지점과 핵심 경로를 따라가는 실행 흐름

입력으로는 신규 빌드, 변경 로그(Release Notes), 영향도 분석 결과, 최소 테스트 환경 구성이 필요하다. 이 정보를 바탕으로 변경 영향도에 따라 후보 기능을 추리고 우선순위를 정한다.

점검 항목은 로그인, 결제, 저장·조회 같은 핵심 경로와 변경 지점의 인터랙션 포인트에 맞춘다. 실행은 Exploratory·Charter 기반의 비스크립트 방식을 우선하며, 필요하면 초경량 체크리스트를 사용한다. 이후 심각도 기준의 결함 존재 여부와 테스트 가치 대비 비용을 평가해 Go/No-Go를 결정한다.

결과물은 Go/No-Go 결정, 결함 리포트, Regression/System 착수 여부, 롤백 여부다. 차단 결함이 발견되면 No-Go로 판정하고 핫픽스 또는 롤백을 거쳐 빌드를 폐기하거나 재배포한다. 경미한 결함만 있으면 Go with Risk로 진행하되 결함을 등록해 Regression에서 추적한다. 결과가 불명확하면 샘플링을 넓히거나 간이 자동화 스모크를 보강한 뒤 다시 판정한다.

⤢✕

Sanity 범위는 좁게 잡되 얕게 보지 않는다

Sanity 테스트는 소수 기능을 깊이 검증한다. 특히 변경 영향도가 높은 인터페이스, 데이터 경계, 오케스트레이션 경로가 우선 대상이다.

사전 스크립트는 최소화하고 탐색적 테스트와 테스트 차터를 사용한다. 시간 박스(Time-box)를 두면 판정 속도를 높일 수 있다. Regression보다 적은 케이스와 짧은 시간으로 진행하지만, 변경 지점과 핵심 경로의 대표성은 확보해야 한다. Sanity를 통과한 빌드는 Regression으로 자연스럽게 넘어간다.

게이트로 운영하려면 Go/No-Go 기준과 차단 결함의 정의를 명확히 둔다. 예를 들어 Sev-1/Sev-2를 차단 기준으로 지정할 수 있다. 자동화 스모크와 함께 운용하면 빌드 안정성에 대한 신뢰도를 높일 수 있다.

릴리스와 변경 배포에서 확인할 대상

모바일 앱 릴리스에서는 스토어 제출 전에 로그인·온보딩, 결제, 푸시 토큰 갱신 같은 핵심 경로를 깊게 확인한다. 타겟 OS·디바이스 매트릭스 전체가 아니라 대표 샘플을 신속히 점검하는 방식이다.

백엔드 마이크로서비스에서 신규 엔드포인트나 스키마가 바뀌면 상·하위 스트림의 계약과 데이터 일관성을 검증한다. 서킷 브레이커와 리트라이 정책이 실제로 동작하는지도 확인 대상이 된다.

데이터 파이프라인 배포에서는 스키마 진화(DDL) 뒤에 핵심 파티션 로딩, 증분 잡, 품질 규칙의 최소 세트를 점검한다. 지연·누락으로 SLO 위반이 예상되는 구간도 샘플링으로 검증한다.

기대할 수 있는 변화

High-sev 결함 유출률은 3060% 감소를 가정할 수 있다. Regression 착수 지연을 막아 전체 테스트 리드타임은 1025% 단축되고, 결함을 조기에 찾음으로써 수정·재검증 비용은 20~40% 절감될 수 있다.

테스트 팀의 가용성을 더 효율적으로 배분할 수 있고 일정 예측도 수월해진다. 품질 게이트가 분명해지면 조직 전체의 품질 책임성도 강화된다.

범위 선정과 판정 기준을 운영에 맞추기

범위는 코드 변경 파일, 의존 모듈, 계약(API/스키마), 런타임 설정처럼 변경 영향도가 큰 지점에서 시작한다. 인증, 결제, 저장·조회, 에러 리커버리 같은 제품 생존 경로는 고정 세트로 둔다. 데이터 경계값, 실패 복구 플로우, 동시성·시간 의존 로직은 리스크 기반 샘플링 대상으로 삼는다.

비스크립트 실행을 기본으로 하되 초경량 체크리스트를 병행한다. 30~90분 타임박스 안에서 진행하며, Go/No-Go 판단은 실시간으로 공유한다. 차단 결함은 즉시 보고하고 단건 재현 영상·로그와 간결한 근거를 붙인다.

핵심 경로가 동작하지 않거나 데이터 손상 위험, 크래시·메모리 릭, 보안 취약점 고위험이 있으면 No-Go다. 사용자 영향이 경미하고 기능을 우회할 방법이 있으면 Go with Risk로 분류한다. 차단 결함 0건이고 경미한 결함만 존재하면 Go로 판정한다.

Smoke·Sanity·Regression의 게이트 역할

테스트 유형	속도(성능)	확장성(케이스 확장)	일관성(절차 표준화)	안정성(게이트 효율)	운영 편의
Smoke	매우 빠름, 수분 단위	낮음, 고정 스크립트 중심	높음, 자동화 용이	중간, 넓은 얕은 커버리지	매우 높음, CI 파이프라인 상시
Sanity	빠름, 30~90분 타임박스	중간, 변경 중심 동적 선정	중간, 비스크립트 가미	높음, 결함 차단 효과 큼	높음, 체크리스트+기본 자동화 병행
Regression	느림, 수시간~수일	높음, 테스트 수 대규모	높음, 표준화·자동화 집중	매우 높음, 출시 품질 담보	중간, 리소스 집약적

Sanity 테스트는 제한된 범위를 깊게 검증해 빌드의 적합성을 빠르게 판단하는 장치다. 영향도 기반의 범위 선정과 비스크립트 접근을 결합하면 Regression 이전에 결함을 차단하고 리드타임을 줄일 수 있다. CI 파이프라인에서는 스모크 자동화와 Sanity 게이트를 함께 운영할 수 있다.