412. 카티션 프로덕트 (Cartesian Product)

⚠️ 이 문서는 두 개의 테이블을 무작정 조인(JOIN)할 때, **서로 어떻게 묶을 것인지 기준(조인 조건)을 빼먹었을 때 발생하는 무식한 '모든 경우의 수 곱하기' 현상인 카티션 프로덕트(교차 조인)**를 다룹니다.

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

  1. 본질: 관계 대수의 기본 연산자 중 하나로, A 테이블의 모든 행과 B 테이블의 모든 행을 1:1로 전부 다 한 번씩 짝지어보는(곱하는) 무식한 결합 방식이다. 수학에서는 '데카르트 곱'이라고 한다.
  2. 원인: 실무에서는 개발자가 SELECT * FROM A, B 처럼 쿼리를 치면서 WHERE 절에 조인 조건을 깜빡 잊고 안 적었을 때 발생한다.
  3. 결과: A에 1,000줄, B에 1,000줄이 있다면 결과는 1,000 + 1,000 = 2,000줄이 아니라 1,000 $\times$ 1,000 = 100만 줄이 튀어나와 서버가 펑 터지게 된다.

Ⅰ. 개요: 묻지 마 소개팅 (Context & Necessity)

남자 3명과 여자 3명이 미팅에 나왔다. 보통은 서로 성격이 맞는 사람끼리 짝을 지어준다. (이게 일반적인 JOIN이다.)

하지만 주선자가 도망가 버렸다. 그래서 **"일단 모든 남자가 모든 여자랑 한 번씩 다 대화를 나눠봐!"**라고 규칙을 정했다.

  • 남자 1호가 여자 1호, 2호, 3호와 대화한다.
  • 남자 2호가 여자 1호, 2호, 3호와 대화한다.
  • 남자 3호가 여자 1호, 2호, 3호와 대화한다. 총 9번의 만남이 이루어졌다. 이것이 바로 데이터베이스의 **카티션 프로덕트(Cartesian Product)**다.

📢 섹션 요약 비유: 카티션 프로덕트는 **'상의 3벌과 하의 3벌로 코디할 수 있는 모든 경우의 수'**를 나열하는 것과 같습니다. 상의 1개당 하의 3개를 모두 매칭해 봐야 하므로, 3 $\times$ 3 = 9가지의 옷차림 결과가 나옵니다.


Ⅱ. 카티션 프로덕트의 수학적 성질 ★

시험에 단골로 나오는 카디널리티(행)와 차수(열)의 계산 공식이다.

  • 릴레이션 A: 행이 3개, 열이 2개
  • 릴레이션 B: 행이 4개, 열이 3개

이 두 릴레이션을 카티션 프로덕트($A \times B$) 했을 때 나오는 결과물은?

  1. 행의 개수 (카디널리티 / 튜플 수): 두 행의 수를 곱한다 ($\times$)
    • 3 $\times$ 4 = 12개의 튜플이 생성된다.
  2. 열의 개수 (차수 / 속성 수): 두 열의 수를 더한다 ($+$)
    • 2 + 3 = 5개의 컬럼이 생성된다. (양옆으로 그냥 이어 붙였으니까)

Ⅲ. 실무에서의 카티션 프로덕트 (CROSS JOIN)

실무에서 카티션 프로덕트를 의도적으로 쓰는 경우는 극히 드물다 (주로 더미 데이터를 왕창 뻥튀기해서 테스트할 때 쓴다). 대부분은 개발자의 **"조인 조건 누락 실수"**로 인해 장애(장애 원인 1순위)로 나타난다.

1. ANSI 표준 SQL (CROSS JOIN)

-- 의도적인 카티션 프로덕트 (명시적)
SELECT * 
FROM 직원 CROSS JOIN 부서;

2. 예전 방식 SQL (실수 유발)

-- 개발자의 실수 (조인 조건을 까먹음)
SELECT * 
FROM 직원, 부서;  -- WHERE 직원.부서코드 = 부서.부서코드 (이 부분을 빼먹음!)

이 쿼리를 날리면 직원이 1,000명, 부서가 100개일 때 10만 줄의 쓰레기 데이터가 조회되면서 DB 서버의 CPU와 메모리가 터져버린다.

┌──────────────────────────────────────────────────────────────┐
│           카티션 프로덕트 (Cartesian Product) 작동 시각화               │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 👨‍💼 직원 테이블 ]                 [ 🏢 부서 테이블 ]               │
│ 이름(A)                           부서명(B)                     │
│ ──────                            ──────                       │
│ 김철수                            영업팀                        │
│ 이영희                            개발팀                        │
│                                                              │
│                   ▼ (CROSS JOIN 결과)                          │
│                                                              │
│ [ 이름(A) ]        [ 부서명(B) ]                                │
│ ────────        ─────────                                    │
│  김철수            영업팀                                        │
│  김철수            개발팀    ◀── (철수는 사실 영업팀인데, 조건이 없으니 다 붙임) │
│  이영희            영업팀    ◀── (영희는 사실 개발팀인데, 조건이 없으니 다 붙임) │
│  이영희            개발팀                                        │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"가장 멍청한 연산이 가장 강력한 재앙을 부른다." 카티션 프로덕트는 관계 대수에서 두 테이블을 합치는 가장 기초적인 뼈대 연산이다. 우리가 흔히 쓰는 INNER JOIN은 사실 이 무식한 카티션 프로덕트(곱하기)를 먼저 수행한 뒤, 거기서 말이 안 되는 데이터들을 WHERE 조건으로 걸러내는(Select) 과정의 숏컷(Shortcut)일 뿐이다. 실무 개발자는 SELECT 문에서 여러 테이블을 FROM 절에 나열할 때, 반드시 그 테이블들을 엮어줄 연결 고리(JOIN 조건)가 꼼꼼하게 빠짐없이 들어갔는지 확인해야만 DB 서버의 억울한 죽음을 막을 수 있다.


📌 관련 개념 맵

  • 관련 연산자: 관계 대수 ($\times$ 기호 - 409번 문서), JOIN (413번 문서)
  • SQL 키워드: CROSS JOIN
  • 연산 공식: 카디널리티(행)는 곱하고($\times$), 차수(열)는 더한다($+$)
  • 활용처: Dummy Data (가짜 테스트 데이터) 대량 생성 시 의도적으로 사용

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

  1. 옷장에 '빨간색, 파란색' 티셔츠 2벌과 '청바지, 면바지' 바지 2벌이 있어요.
  2. 옷을 입는 '카티션 프로덕트' 방식은, 무조건 상의 1개당 하의를 다 입어보는 거예요! (빨-청, 빨-면, 파-청, 파-면)
  3. 2벌 $\times$ 2벌 = 총 4가지의 패션(결과)이 나오죠? 조건 없이 무조건 모든 경우의 수를 다 짝지어주는 무식한 곱하기 방법이랍니다!