435. EXISTS 연산자 (고속 탐색)

⚠️ 이 문서는 "이 학생이 도서관에서 책을 한 번이라도 빌린 적이 있나?"를 찾을 때, 학생이 빌린 100권의 책 목록을 굳이 다 꺼내보지 않고 **"어? 빌린 기록 1개 있네! 오케이 확인 끝!" 하고 즉시 검색을 멈춰버리는 초고속 쿼리 최적화 기법인 'EXISTS'**를 다룹니다.

핵심 인사이트 (3줄 요약)

본질: 서브쿼리(Subquery) 안에서 찾으려는 데이터가 **'단 1건이라도 존재하는지(True/False)'**만 판별하는 논리 연산자다.

가치 (Short-circuit Evaluation): 매칭되는 데이터를 1개라도 찾는 순간, 그 뒤에 100만 건의 데이터가 더 남아있어도 쿨하게 무시하고 검색을 즉시 종료해 버리므로 엄청난 성능 향상을 가져온다.

IN과의 차이점: IN은 서브쿼리의 결과를 끝까지 다 읽어서 리스트를 만든 뒤 비교하지만, EXISTS는 존재 여부만 확인하므로 대용량 데이터 필터링에서 IN보다 압도적으로 유리하다. (단, 최근 옵티마이저는 둘 다 세미 조인으로 비슷하게 최적화해 준다 - 434번 문서 참조)

Ⅰ. 개요: 우물에서 바늘 1개 찾기 (Context & Necessity)

"우리 쇼핑몰에 가입된 10만 명의 VIP 고객 중에서, '결제 취소'를 단 한 번이라도 한 적이 있는 블랙컨슈머를 다 찾아내라!"

초보 개발자의 쿼리 (IN 사용):

SELECT 이름 FROM 고객 
WHERE 고객번호 IN (SELECT 고객번호 FROM 결제_취소_내역);

이 쿼리를 돌리면, DB는 결제_취소_내역 테이블을 처음부터 끝까지 다 뒤져서 취소한 사람들의 거대한 번호표 리스트를 먼저 만든다. (어떤 진상 고객이 취소를 1,000번 했다면, 그 사람 번호도 리스트에 1,000번 들어간다. 낭비다.)

고수 개발자의 쿼리 (EXISTS 사용):

SELECT 이름 FROM 고객 C
WHERE EXISTS (
    SELECT 1 FROM 결제_취소_내역 R 
    WHERE C.고객번호 = R.고객번호
);

DB는 취소 내역 테이블을 뒤지다가 해당 고객의 취소 기록이 딱 1건이라도 발견되는 순간, 그 고객이 뒤에 취소를 999번 더 했든 말든 알 바 없이 "얘 진상 맞음(True)!" 하고 바로 다음 고객 검사로 넘어간다.

📢 섹션 요약 비유: IN 방식은 반 친구 30명의 가방을 전부 쏟아서 지우개가 총 몇 개인지 리스트를 다 적어본 뒤에 "너 지우개 있네?"라고 확인하는 방식입니다. EXISTS 방식은 가방을 열고 뒤지다가 지우개가 딱 1개라도 손에 잡히면 즉시 지퍼를 닫고 "너 지우개 있네!" 하고 다음 친구로 넘어가는 초고속 검사법입니다.

Ⅱ. EXISTS의 작동 원리 (세미 조인) ★

EXISTS는 내부적으로 세미 조인 (Semi Join) 방식으로 작동한다.

1. 서브쿼리에 `SELECT 1`을 쓰는 이유

EXISTS 뒤의 서브쿼리에는 보통 SELECT 1 또는 SELECT *을 쓴다.
어차피 EXISTS는 서브쿼리가 반환하는 '데이터의 내용'에는 1도 관심이 없고, 오직 '데이터가 있는가 없는가(True/False)'만 본다.
그래서 아무 의미 없는 숫자 1을 리턴하게 쿼리를 짜는 것이 관례다. (물론 SELECT *를 써도 똑똑한 옵티마이저가 알아서 무시해 주긴 한다.)

2. 메인 쿼리와의 연결 고리 (Correlated Subquery)

EXISTS가 제대로 동작하려면, 반드시 서브쿼리의 WHERE 절 안에 메인 쿼리의 컬럼(C.고객번호 = R.고객번호)이 연결되어 있어야 한다.
메인 쿼리의 데이터 한 줄을 핀셋으로 집어서 서브쿼리에 던져주고, "얘 있어?" 하고 묻는 방식이기 때문이다.

Ⅲ. NOT EXISTS: 안 한 사람 찾기의 제왕

실무에서는 무언가를 '한 사람'보다 **'안 한 사람(이탈자)'**을 찾을 때 더 많이 쓰인다.

"장바구니에 물건은 담았는데, 결제는 안 한 사람 찾아줘!"

SELECT * FROM 장바구니 C
WHERE NOT EXISTS (
    SELECT 1 FROM 결제내역 R WHERE C.고객번호 = R.고객번호
);

결제 내역 테이블을 뒤지다가 내 번호가 하나라도 보이면 "얘는 결제했네(True)"가 되어 탈락하고, 끝까지 뒤졌는데도 안 나오면 "얘 결제 안 했네(False $\rightarrow$ NOT EXISTS니까 최종 합격!)"가 되어 결과로 튀어나온다. 이를 **안티 조인 (Anti Join)**이라고 부른다.

┌──────────────────────────────────────────────────────────────┐
│           EXISTS 연산자의 Short-circuit(빠른 종료) 작동 시각화          │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 👨‍💼 고객 (메인) ]            [ 💳 결제 취소 내역 (서브쿼리) ]      │
│                                                              │
│ 1번: 김철수 ──(EXISTS 검사)──▶ 1번(취소) ◀── 1개 찾음! 멈춰!! 🛑 │
│                            1번(취소) (안 봐도 됨)             │
│                            1번(취소) (안 봐도 됨)             │
│                                                              │
│ 2번: 이영희 ──(EXISTS 검사)──▶ 끝까지 다 뒤져도 2번은 없음. (False) │
│                                                              │
│ ★ 특징: 1번 철수는 취소를 3번이나 했지만, DB는 맨 위 1개만 보고 검사를 끝냈다.│
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"존재 여부만 묻는 질문에는 리스트(List)로 대답하지 마라." 데이터베이스 성능 튜닝의 기본은 "불필요한 디스크 읽기(I/O)를 어떻게든 줄이는 것"이다. EXISTS는 개발자의 "딱 1개만 찾고 그만 찾아!"라는 강력한 의도를 옵티마이저에게 전달하는 최고의 명세서다. 최신 RDBMS 옵티마이저들이 IN과 EXISTS를 내부적으로 똑같이 최적화해 주긴 하지만, 내가 원하는 비즈니스 로직이 '목록 매칭'인지 '존재 여부 확인'인지를 명확히 구분하여 EXISTS를 적재적소에 사용하는 것은 시니어 개발자의 필수 소양이다.

📌 관련 개념 맵

관련 연산자: IN, ANY, ALL (434번 문서)
내부 실행 계획: Semi Join (세미 조인 - 중복 제거), Anti Join (안티 조인)
서브쿼리 종류: 상관 서브쿼리 (Correlated Subquery - 메인 쿼리와 값이 연결된 서브쿼리)
주의점: NOT EXISTS는 서브쿼리에 Null 값이 있어도 논리적으로 안전하다. (NOT IN은 위험함)

👶 어린이를 위한 3줄 비유 설명

숨바꼭질을 할 때, 옷장 안에 숨은 친구를 찾는다고 해봐요.
IN 방식은 옷장 문을 열고 "철수, 영희, 민수... 총 3명이 있네!" 하고 일일이 다 세어보는 거예요.
EXISTS 방식은 옷장 문을 살짝 열었는데 발가락 딱 하나라도 보이면, 누구 발가락인지 몇 명인지 세어보지도 않고 "찾았다!" 하고 바로 문을 닫는 아주 빠른 게임 방법이랍니다!