dbt 테스트 — Generic·Singular 테스트와 실행 제어
50 dbt Interview Questions for Data Engineers (Real Answers, 2026) — 미상 (데이터 엔지니어링 커리어 블로그, 2026) Section 2: Testing & Documentation, Q11-Q15 (pp.4-5)
이 모듈을 다 읽으면
- generic 테스트와 singular 테스트의 차이와 각각을 언제 쓰는지 구분해 설명할 수 있다
- 커스텀 제네릭 테스트를 {% test %} 블록으로 작성하는 방법을 설명할 수 있다
- severity·error_if/warn_if 설정과 --select를 이용한 타겟 테스트 실행을 판단할 수 있다
dbt의 테스트는 YAML에 선언해 컴파일되는 generic 테스트(과거 명칭 schema test)와, tests/ 디렉터리의 독립 SQL 파일인 singular 테스트(과거 명칭 data test) 두 갈래로 나뉜다. 두 경우 모두 실패 행의 개수를 반환하며 0이면 통과다. severity 설정으로 실패를 파이프라인 중단 없이 경고만 하게 할 수 있고, --select로 특정 모델·태그·테스트 유형만 골라 실행할 수 있어 CI 피드백 속도를 높인다.
Generic 테스트와 Singular 테스트
YAML에 선언해 dbt가 SQL 쿼리로 컴파일하는 테스트가 있다. 내장된 네 가지는 unique, not_null, accepted_values, relationships이며, 각 테스트는 실패한 행의 개수를 반환하고 0이면 통과다. 이 테스트들은 데이터 품질 문제에 대한 첫 번째 방어선이며 추가 비용이 거의 없다. 모든 기본 키에 최소한 unique와 not_null을 걸지 않았다면 인터뷰어가 놓치지 않을 허점이다.
YAML로 설정되며 특정 컬럼·모델에 적용되는 테스트와 달리, tests/ 디렉터리 안의 독립된 SQL 파일로 작성되어 실패 행을 반환하는 테스트도 있다. YAML 포맷에 맞지 않는 비즈니스 로직 검증(예: '매출은 음수가 될 수 없다', 'order_date는 항상 ship_date보다 앞서야 한다')에 이 방식을 쓴다. 쿼리가 0개 행을 반환하면 테스트는 통과한다.
— 정정: 원문은 이 둘을 각각 'schema test'와 'data test'라고 부르지만, 이는 dbt v0.20(2021년경) 이전의 옛 용어다. 현재 dbt 공식 문서는 YAML로 선언해 컬럼/모델에 적용하는 테스트를 'generic test'로, tests/ 안의 독립 SQL 파일 테스트를 'singular test'로 부른다. 동작은 동일하지만 최신 용어를 쓰는 것이 인터뷰에서 더 정확한 인상을 준다.
핵심 포인트
- 내장 generic 테스트 네 가지: unique, not_null, accepted_values, relationships — 실패 행 수가 0이면 통과
- singular 테스트는 tests/ 안의 독립 SQL 파일로, YAML 포맷에 맞지 않는 비즈니스 로직 검증에 쓴다
- 원문의 'schema test'/'data test'는 옛 용어이며, 현재 공식 명칭은 각각 'generic test'/'singular test'다 — 정정
- 모든 기본 키에 최소 unique·not_null 테스트를 걸지 않는 것은 인터뷰에서 지적받는 흔한 허점이다
커스텀 제네릭 테스트, severity, 타겟 테스트 실행
커스텀 제네릭 테스트는 tests/generic/(또는 macros/) 아래에 인자를 받아 실패 행을 반환하는 SQL 파일로 작성한다. 예를 들어 test_is_positive.sql 안에 {% test is_positive(model, column_name) %} SELECT * FROM {{ model }} WHERE {{ column_name }} < 0 {% endtest %} 처럼 정의하고, YAML에서 컬럼의 tests 아래 is_positive를 추가해 호출한다. 이렇게 하면 테이블마다 일회성 singular 테스트를 반복 작성하지 않고도 데이터 품질 검증을 확장할 수 있다.
severity 설정은 실패 처리 방식을 제어한다. 기본값에서는 실패 행이 하나라도 있으면 테스트가 실패하고 dbt build가 다운스트림 처리를 멈춘다. severity: warn으로 설정하면 실패를 보고는 하되 파이프라인을 막지는 않는데, 이는 아직 고치지 못했지만 추적 중인 알려진 데이터 품질 이슈에 유용하다. error_if와 warn_if로 임계값도 설정할 수 있다 — 예를 들어 error_if: ">100"은 100개를 초과하는 행이 위반할 때만 실패로 처리한다.
dbt test --select는 특정 모델(dbt test --select my_model), 태그(dbt test --select tag:finance), 특정 테스트 유형(dbt test --select test_type:singular)에 대해서만 테스트를 실행할 수 있게 해준다. --select는 dbt run과 동일한 그래프 연산자를 쓰므로, dbt test --select my_model+는 my_model과 그 다운스트림 전체를 테스트한다. 이는 PR이 변경한 부분만 테스트하고 프로젝트 전체를 테스트하지 않게 해 빠른 CI 피드백을 가능케 하는 핵심 기법이다.
핵심 포인트
- 커스텀 제네릭 테스트는 tests/generic/ 아래 {% test %}...{% endtest %} 블록으로 작성하고 YAML에서 이름으로 호출한다
- severity: warn은 테스트 실패를 보고만 하고 파이프라인을 막지 않으며, 아직 고치지 못한 알려진 이슈 추적에 쓴다
- error_if/warn_if로 실패 임계값(예: 100행 초과 시에만 실패)을 지정할 수 있다
- dbt test --select는 dbt run과 동일한 그래프 연산자(+ 등)를 지원해 변경된 모델과 그 다운스트림만 빠르게 테스트할 수 있다