[SQLD 7화] CASE WHEN 조건문을 활용한 데이터 세그먼트 분류 및 유연한 조건 분기법 (SQLD, 직장인 SQL)

작성자:

1. 데이터에 가치를 부여하는 변환 도구: CASE WHEN

6화에서 우리는 데이터 집계 과정에서 데이터 증발과 계산 오류를 유발하는 복병인 NULL 개념의 본질을 파악하고, 이를 안전하게 제어하기 위한 COALESCE 함수 활용법을 살펴보았습니다. 이처럼 원천 데이터에 존재하는 결측치를 정돈하고 나면, 분석가는 정제된 숫자와 문자 데이터를 가공하여 단순 조회를 넘어선 ‘비즈니스적 의미를 지닌 인사이트’를 추출하는 단계로 나아가게 됩니다.

현업 실무에서는 데이터베이스에 입력된 원천 값 그대로 보고서에 사용하는 경우보다, 특정 기준에 따라 데이터를 재분류해야 하는 상황이 빈번하게 발생합니다. 예를 들어 “고객들의 누적 구매 금액을 기준으로 VIP, 골드, 일반 등급을 나누어 달라”거나 “결제 수단 코드에 따라 간편결제, 신용카드, 현금성 수단으로 그룹핑해 달라”는 식의 요청이 대표적입니다.

프로그래밍 언어의 If-Else 문처럼, SQL 내에서 데이터의 조건에 따라 흐름을 분기하고 새로운 값을 동적으로 할당해 주는 강력한 도구가 바로 CASE WHEN 구문입니다.

2. CASE WHEN 조건문의 두 가지 표준 문법 구조

CASE WHEN 구문은 작성 방식에 따라 크게 두 가지 형태(단순형과 검색형)로 분류됩니다. 두 방식 모두 최종적으로는 동일한 조건 분기를 수행하지만, 다루고자 하는 조건의 복잡성에 따라 선택하여 사용하는 것이 효율적인 방법으로 평가받고 있습니다.

1) 단순형 CASE 표현식 (Simple CASE)

특정 하나의 칼럼 값이 무엇과 같은지(=) 일대일 맵핑 방식으로 단순 비교할 때 유용하게 쓰이는 문법 구조입니다.

-- 결제 수단 코드를 직관적인 한글 명칭으로 변환하는 단순형 구조 예시
SELECT 
    ORDER_NO
  , PAY_METHOD_CD
  , CASE PAY_METHOD_CD
        WHEN '01' THEN '신용카드'
        WHEN '02' THEN '간편결제'
        WHEN '03' THEN '계좌이체'
        ELSE '기타'
    END AS PAY_METHOD_NM
FROM 
    DW_MART.ORDER_MASTER;

2) 검색형 CASE 표현식 (Searched CASE)

실무에서 분석가들이 가장 압도적으로 많이 사용하는 구조입니다. WHEN 뒤에 대소 비교(>, <), 범위(BETWEEN), 패턴(LIKE) 등 다양한 조건식을 자유롭게 나열할 수 있어 다차원적인 비즈니스 로직을 구현하는 데 적합한 대안으로 꼽힙니다.

-- 조건절 내에 다양한 연산자를 포함할 수 있는 검색형 구조 기본 틀
CASE 
    WHEN 조건식1 THEN 반환값1
    WHEN 조건식2 THEN 반환값2
    ELSE 모든 조건에 맞지 않을 때의 기본 반환값
END

3. 현업 비즈니스 사례로 보는 데이터 세그먼트 분류

CASE WHEN 구문이 실무 마케팅 및 CRM(고객 관계 관리) 분석에서 어떻게 가치를 발휘하는지, 실제 커머스 기업의 우수 고객 타겟팅 전략 수립 부서에서 발생할 수 있는 가상의 비즈니스 시나리오를 통해 짚어보겠습니다.

📊 [실무 사례 예시: CRM 팀 이 과장의 고객 등급 분류 업무]

유통 대기업의 CRM 담당자인 이 과장은 이번 달 프로모션 예산 집행을 앞두고 ‘최근 1분기 고객별 누적 구매 금액 마트 테이블’을 기반으로 고객을 세그먼트화하라는 지시를 받았습니다.

  • 분류 기준: 누적 구매 금액이 100만 원 이상이면 ’01_VIP’, 50만 원 이상 100만 원 미만이면 ’02_GOLD’, 10만 원 이상 50만 원 미만이면 ’03_SILVER’, 그 외 10만 원 미만이거나 구매 이력이 마땅치 않은 고객은 ’04_GENERAL’ 등급으로 분류하여 단 하나의 결과 테이블로 도출해야 합니다.

이 과장은 마케팅 세그먼트를 명확하게 구분하기 위해 다음과 같이 검색형 CASE WHEN 쿼리를 설계하여 실행했습니다.

-- [올바른 예시] CASE WHEN 검색형 문법을 활용한 다단계 고객 세그먼트 분류 쿼리
SELECT 
    CUST_NO
  , TOTAL_PURCHASE_AMT
  , CASE 
        WHEN TOTAL_PURCHASE_AMT >= 1000000 
             THEN '01_VIP'
        WHEN TOTAL_PURCHASE_AMT >= 500000 AND TOTAL_PURCHASE_AMT < 1000000 
             THEN '02_GOLD'
        WHEN TOTAL_PURCHASE_AMT >= 100000 
             THEN '03_SILVER'
        ELSE '04_GENERAL'
    END AS CUST_GRADE_SEG -- 최종 세그먼트 칼럼 생성
FROM 
    DW_MART.CUSTOMER_QUARTERLY_SUMMARY
WHERE 
    BASE_YYMM = '202606';

💡 쿼리 작성 시 기억해야 할 문법적 특성과 효율성 팁

  • 순차적 평가 메커니즘: CASE WHEN 구문은 위에서부터 작성된 순서대로 조건을 평가합니다. 특정 행의 데이터가 첫 번째 WHEN 조건을 만족하여 값을 반환하면, 아래에 남아있는 나머지 WHEN 조건들은 뒤돌아보지 않고 즉시 패스(Skip)합니다.
  • 범위 조건의 스마트한 축소: 위 이 과장의 쿼리 중 세 번째 줄인 WHEN TOTAL_PURCHASE_AMT >= 100000 영역을 살펴보면, 앞선 항목과 달리 50만 원 미만이라는 상한선 조건을 명시적으로 쓰지 않았음을 볼 수 있습니다. 이미 위쪽의 첫 번째와 두 번째 WHEN 절에서 50만 원 이상의 모수들이 필터링되어 먼저 빠져나갔기 때문에, 자연스럽게 세 번째 단계에서는 50만 원 미만인 데이터들만 내려와 평가받게 되므로 코드를 간결하게 유지하는 대안이 됩니다.

4. 팩트 체크 및 데이터 분석가의 관점 점검

기술적 정확성을 확보하기 위해, 실무에서 CASE WHEN 조건문을 다룰 때 초보 직장인들이 가장 많이 범하는 오해와 실수들을 점검해 보겠습니다.

  • THEN이나 ELSE 뒤에 오는 반환값들의 데이터 타입이 달라도 되는가?
    • 팩트 체크: 그렇지 않습니다. 6화에서 배운 COALESCE 함수와 마찬가지로, CASE WHEN 조건문이 최종적으로 생성해내는 새로운 가상 칼럼 역시 단 하나의 명확한 데이터 타입을 가져야 합니다. 예를 들어 THEN 'VIP'(문자형)를 쓰고 아래에 ELSE 0(숫자형)을 나열하면, 데이터베이스에 따라 데이터 타입 변환 오류 또는 데이터 타입 불일치 오류가 발생할 수 있습니다. 숫자를 문자로 일치시키거나(ELSE '0'), 반환값은 가능한 동일한 데이터 타입으로 작성하는 것이 좋습니다.
  • ELSE 절은 생략해도 무방한가?
    • 팩트 체크: 문법적으로 생략 자체는 가능합니다. 하지만 ELSE를 생략하면 조건을 만족하지 않는 행은 NULL이 반환됩니다. 이는 6화에서 지적했듯 데이터 누락이나 연산 왜곡으로 번질 리스크가 있으므로, 예외 처리를 명확히 규정하고 데이터 무결성을 유지하기 위해 가능한 한 ELSE 절을 명시적으로 작성하여 기본값을 채워주는 습관이 실무 안정성 관점에서 유리할 수 있습니다.

5. 7화 요약 및 실무 다중 조건 분기 체크리스트

업무 자동화 스크립트나 대용량 조회를 실행하기 전, 내 조건 분기 로직의 결점을 점검할 수 있는 핵심 가이드 표를 제공합니다.

체크포인트발생 가능한 리스크현직 분석가의 권장 대안 및 대응
조건의 순서 배치 오류범위가 좁은 조건을 아래에 두면 상위 조건에 먹혀 오작동 유발조건의 경계선이 좁고 까다로운 핵심 조건식을 CASE 최상단에 선제 배치
반환값의 데이터 형식 혼용문자 형식과 숫자 형식이 섞여 실행 오류 발생'VIP', 'GOLD' 등 문자열로 일치시키거나 형변환 함수 활용
NULL 조건 판별 시 등호(=) 사용WHEN CAL_VAL = NULL로 작성하면 NULL을 올바르게 판별할 수 없음반드시 WHEN CAL_VAL IS NULL 문법 형태로 전용 연산자 매칭

6. 결론 및 다음 화 예고

이번 7화에서는 원천 데이터에 비즈니스적 가치를 불어넣고 조건에 따라 유연하게 흐름을 제어하는 CASE WHEN 조건문의 문법 구조와 이를 활용한 다차원 데이터 세그먼트 분류 실무 사례를 다각도로 점검해 보았습니다. 쿼리 내부에서 이러한 조건 분기를 능숙하게 다루는 역량은 분석가의 비즈니스 규칙을 SQL로 구현하는 핵심 역량입니다.

지금까지 1화부터 7화에 이르기까지 우리는 단 하나의 테이블 안에서 데이터를 추출, 필터링, 정렬, 변환하는 ‘단일 테이블 제어 기법’을 마스터했습니다.

이어지는 8화부터는 SQL의 진정한 꽃이자 정점이라 불리는 다중 테이블 결합(Join)의 세계로 진입합니다. 그 첫 단추로 두 개 이상의 테이블에서 공통 분모를 지닌 데이터의 교집합만을 정밀하게 추출해 내는 INNER JOIN (내부 조인)의 개념을 분석합니다. 현업에서 서로 분리되어 저장된 고객 마스터 테이블과 매출 내역 테이블을 유기적으로 엮어내고, 조인 과정에서 가장 많이 발생하는 치명적인 대참사인 ‘데이터 뻥튀기(Duplication)’ 현상을 방어하는 현직자들의 핵심 조인 가이드를 비즈니스 예시와 함께 상세히 파악해 보겠습니다.

댓글 남기기