[SQLD 4화] LIKE와 와일드카드(%, _), 그리고 대량의 다중 택일 조건을 깔끔하게 정리해 주는 IN 구문 및 BETWEEN 범위 연산자 (SQLD, 직장인 SQL)

작성자:

1. 정밀한 조건 검색의 확장: 패턴, 택일, 그리고 범위

3화에서 우리는 AND와 OR 논리 연산자를 결합할 때 발생하는 우선순위 함정과 이를 방지하기 위한 명시적 괄호(()) 활용법을 살펴보았습니다. 현업의 데이터 분석 요청은 “A이거나 B인 경우”처럼 명확히 떨어지는 값만을 요구하지 않는 경우가 많습니다. “특정 단어가 포함된 상품명”, “수십 개의 특정 카테고리 코드 중 하나에 해당하는 매출”, “특정 기간이나 가격대 사이의 거래 이력” 등 모호한 패턴이나 연속된 범위, 대량의 선택지를 다루어야 할 때가 필수적으로 찾아옵니다.

이러한 다차원적이고 정밀한 필터링 요구사항을 직관적이고 효율적으로 해결하기 위해 우리는 LIKE, IN, BETWEEN 연산자를 사용하게 됩니다.

많은 초보 분석가가 이 연산자들을 단순히 ‘코드를 조금 더 짧게 만들어 주는 문법적 편의 기능’으로만 오해하곤 합니다. 그러나 대규모 분산 데이터웨어하우스(DW) 환경에서 이 연산자들은 쿼리의 가독성을 획기적으로 개선할 뿐만 아니라, 옵티마이저가 보다 효율적인 실행 계획을 수립하는 데 도움이 될 수 있습니다.

2. 문자열 패턴 매칭의 핵심: LIKE와 와일드카드(%, _)

LIKE 연산자는 정확히 일치하는 값이 아닌, 특정 문자열의 패턴을 검색할 때 활용됩니다. 이때 문자열의 유연한 매칭을 돕는 두 가지 와일드카드 기호인 퍼센트(%)와 언더바(_)의 메커니즘 차이를 명확히 인지해야 합니다.

  • 퍼센트 와일드카드(%): 0개 이상의 모든 문자 집합을 의미합니다. 위치에 따라 전방 일치, 후방 일치, 부분 일치 등을 구현할 수 있습니다.
  • 언더바 와일드카드(_): 반드시 ‘정확히 1개’의 문자 자리를 의미합니다. 글자 수 제한이 필요한 특수한 패턴 검색에 유용하게 쓰입니다.

테라데이터 실무 문법 예시 (LIKE)

-- 상품명에 '유기농'이 포함되고, 사은품 코드가 'G'로 시작하며 뒤에 정확히 3글자가 붙는 패턴 조회
SELECT 
    PROD_CD
  , PROD_NM
  , GIFT_CD
FROM 
    DW_MART.PRODUCT_MASTER
WHERE 
    PROD_NM LIKE '%유기농%'    -- '유기농'이라는 단어가 앞, 뒤, 중간 어디든 포함된 경우
    AND GIFT_CD LIKE 'G___';   -- 'G'로 시작하며 뒤에 정확히 3개의 문자(총 4글자)가 오는 경우

테라데이터 환경에서 LIKE 연산자를 사용할 때 유의할 점은 ‘와일드카드가 배치되는 위치’입니다. LIKE ‘유기농%’처럼 문자열의 앞부분이 고정된 패턴은 데이터베이스가 보다 효율적인 실행 계획을 선택할 가능성이 있습니다. 다만 실제 실행 계획은 인덱스 구성, 통계 정보, 데이터 분포 등에 따라 달라질 수 있습니다.

반면 LIKE ‘%유기농%’처럼 문자열 앞부분에 와일드카드가 위치하면, 데이터베이스는 검색 시작 지점을 특정하기 어려워집니다. 이 경우 실행 계획에 따라 전체 테이블을 읽는(Table Scan) 방식이 선택될 가능성이 커질 수 있으므로, 대용량 테이블에서는 사용에 주의하는 것이 좋습니다.

3. 대량의 다중 OR 조건을 구원하는 IN 구문

이커머스나 금융권 실무에서는 마케팅 대상 카테고리나 점포 코드가 수십 개에 달하는 경우가 다반사입니다. 3화에서 배운 OR 연산자만을 활용해 이를 구현하려고 하면 쿼리가 기하급수적으로 길어지고 가독성이 무너지는 현상이 발생합니다.

[비즈니스 리팩토링 사례: 지저분한 OR 코드의 습격]

의류 커머스 기업의 마케팅 부서에서 “여성 의류 중 셔츠(011), 블라우스(012), 원피스(015), 스커트(022), 슬랙스(031) 카테고리의 매출 데이터를 뽑아달라”고 요청했다고 가정해 보겠습니다. 이를 초보자가 쿼리로 구현하면 다음과 같이 작성되기 쉽습니다.

-- [비효율적 예시] 가독성이 떨어지고 실수의 여지가 많은 OR 연발 쿼리
SELECT 
    ORDER_NO
  , ITEM_CD
  , SALE_AMT
FROM 
    DW_MART.ORDER_DETAIL
WHERE 
    CATEGORY_CD = '011'
    OR CATEGORY_CD = '012'
    OR CATEGORY_CD = '015'
    OR CATEGORY_CD = '022'
    OR CATEGORY_CD = '031';

위 쿼리는 가독성이 낮을 뿐만 아니라, 만약 다른 필터 조건(AND)이 결합될 때 3화에서 다룬 괄호 처리를 깜빡한다면 심각한 데이터 추출 오류를 야기할 리스크가 존재합니다.

이때 다중 택일 조건을 리스트 형태로 묶어 깔끔하게 정리해 주는 솔루션이 바로 IN 구문입니다. 위 코드를 IN 구문으로 리팩토링하면 다음과 같이 세련되게 변모합니다.

-- [올바른 예시] IN 구문을 활용한 가독성 및 가시성 최적화 쿼리
SELECT 
    ORDER_NO
  , ITEM_CD
  , SALE_AMT
FROM 
    DW_MART.ORDER_DETAIL
WHERE 
    CATEGORY_CD IN ('011', '012', '015', '022', '031');

IN 구문을 사용하면 코드가 획기적으로 단축될 뿐만 아니라 논리적 결합 구조가 하나로 묶이기 때문에 다중 조건 환경에서 괄호 누락으로 인한 사고를 원천 차단해 주는 장점이 있습니다.

IN 구문은 다수의 동일 칼럼 조건을 간결하게 표현할 수 있으며, 옵티마이저가 내부적으로 OR 조건과 유사한 형태로 변환하여 처리하는 경우도 있습니다. 따라서 IN 구문은 성능 향상을 보장하는 기능이라기보다, 동일한 조건을 간결하게 표현하여 가독성과 유지보수성을 높이는 데 더 큰 의미가 있습니다. 만약 리스트에서 제외하고 싶은 값들이라면 NOT IN (...) 구조를 적용할 수도 있습니다.

4. 연속된 데이터 구간을 정의하는 BETWEEN 범위 연산자

특정 날짜 구간이나 금액 구간 등 상한선과 하한선이 명확한 연속형 데이터를 필터링할 때 입문자들은 흔히 WHERE PURCHASE_DT >= '2026-01-01' AND PURCHASE_DT <= '2026-01-31'과 같이 비교 연산자의 조합을 사용합니다. 이 역시 훌륭한 문법이지만, 이를 한 단어로 깔끔하게 대체해 주는 것이 BETWEEN 연산자입니다.

-- BETWEEN을 활용한 특정 기간 및 금액 구간 데이터 추출
SELECT 
    CUST_NO
  , PURCHASE_DT
  , PURCHASE_AMT
FROM 
    DW_MART.CUSTOMER_PURCHASE_LOG
WHERE 
    PURCHASE_DT BETWEEN '2026-01-01' AND '2026-01-31'   -- 1월 한 달간의 거래
    AND PURCHASE_AMT BETWEEN 50000 AND 200000;          -- 구매금액 5만 원 이상 20만 원 이하

BETWEEN 사용 시 반드시 기억해야 할 팩트 체크

  • 이상·이하(Inclusive) 메커니즘: BETWEEN A AND B는 항상 A 이상이자 B 이하인 폐구간 영역을 지정합니다. 즉, 하한선 값인 A와 상한선 값인 B가 결과 집합에 조건 없이 포함됩니다. 미만이나 초과 조건을 다루어야 할 때는 BETWEEN이 아닌 대소 비교 연산자(>, <)를 사용해야 합니다.
  • 날짜와 시간 데이터 유형의 주의점: 현업에서 가장 많은 실수가 발생하는 지점입니다. 만약 PURCHASE_DT 칼럼의 데이터 타입이 단순 날짜(DATE)가 아니라 시·분·초까지 포함하는 타임스탬프(TIMESTAMP) 유형인 경우, BETWEEN '2026-01-01' AND '2026-01-31'로 조회하면 ‘2026-01-31 00:00:00’인 데이터까지만 인식될 수 있습니다. 즉, 1월 31일 오후에 발생한 거래 데이터(2026-01-31 15:30:22 등)는 상한선을 벗어나 누락되는 현상이 발생하곤 합니다. 따라서 타임스탬프 칼럼을 다룰 때는 CAST 함수를 통해 날짜형으로 변환하거나 비교 연산자를 통해 마감 시점을 명확히 펜싱하는 접근이 안전할 수 있습니다.

5. 테라데이터 20부작 중간 요약 및 체크리스트

지금까지 1화부터 4화에 이르기까지 우리는 데이터 조회의 기초 뼈대와 다차원 필터링에 필요한 핵심 조건 연산자들을 섭렵했습니다. 쿼리를 실행하기 전 내 코드가 대용량 DW 시스템에 무리를 주지 않는지 점검할 수 있는 핵심 체크리스트 표를 제공합니다.

연산자 유형실무 체크포인트시스템 부하 요인 및 대안
LIKE (패턴)와일드카드 기호(%)가 맨 앞에 위치하는가?전방에 % 배치 시 효율적인 접근 경로를 선택하기 어려울 수 있음. 전방 일치 유도 권장.
IN (택일)다중 OR 구문을 하나의 리스트로 압축했는가?가독성을 높이고 조건식을 간결하게 표현하는데 도움.
BETWEEN (범위)데이터 타입이 타임스탬프(시분초) 형태인가?상한선 날짜의 당일 오후 데이터 누락 위험. 데이터 타입 변환 매칭 필요.

6. 결론 및 다음 화 예고

이번 4화에서는 복잡한 문자열 패턴을 유연하게 제어하는 LIKE, 대량의 이산적 선택지를 가독성 있게 묶어주는 IN, 연속적인 수치 및 날짜 구간을 안전하게 정의하는 BETWEEN 연산자의 내부 메커니즘과 비즈니스 활용 사례를 다각도로 점검해 보았습니다. 이러한 조건절의 고도화는 쿼리 가독성을 극대화하여 협업 효율을 높일 뿐 아니라, 불필요한 연산을 줄이고 가독성 높은 SQL을 작성하는 데 도움이 됩니다.

이어지는 5화에서는 추출된 데이터 결과 집합을 비즈니스 요구사항에 맞춰 일정한 순서로 정렬하는 ORDER BY 구문을 집중 분석해보겠습니다.

댓글 남기기