177. 뷰 머징 (View Merging) - 옵티마이저의 쿼리 변환 (인라인 뷰를 메인 쿼리에 병합)

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

1. 본질: 뷰 머징 (View Merging)은 인라인 뷰나 단순 뷰의 경계를 없애고 하나의 질의 블록으로 다시 써서, 옵티마이저가 전체 조인 그래프를 한 번에 최적화하게 만드는 쿼리 변환 (Query Transformation)이다.
2. 가치: 뷰가 고립된 채 남아 있으면 조인 순서, 조건 이동, 인덱스 선택의 폭이 좁아지지만, 머징이 되면 중간 결과와 임시 저장 비용을 줄이고 더 공격적인 최적화가 가능해진다.
3. 판단 포인트: 단순 투영·선택·조인 뷰는 머징에 유리하지만, 집계, DISTINCT, 분석 함수, Top-N, 보안 경계처럼 "결과 의미를 바꾸는 경계"는 유지해야 할 때가 많다.

Ⅰ. 개요 및 필요성

뷰 머징은 SQL (Structured Query Language) 가독성을 위해 나눈 질의 블록을, 실행 전에 다시 합쳐 의미는 그대로 두고 비용은 낮추려는 최적화 기술이다. 개발자는 복잡한 로직을 인라인 뷰, 파생 테이블, 재사용 뷰로 정리하지만, 비용 기반 옵티마이저 (CBO, Cost-Based Optimizer) 입장에서는 이 경계가 남아 있으면 전체 조인 그래프를 자유롭게 탐색하기 어렵다. 특히 선택도가 높은 조건이 바깥 블록에 있고 큰 테이블이 뷰 안에 숨어 있으면, 뷰를 먼저 계산하는 순간 불필요하게 큰 중간 결과를 만든 뒤에야 행 수를 줄이게 된다.

핵심은 "뷰를 썼다"가 문제가 아니라, 뷰 경계가 최적화 벽이 되는가다. 단순한 뷰는 결국 FROM 절 안에 있는 또 하나의 질의 블록일 뿐이므로, 의미를 훼손하지 않는다면 메인 블록과 합쳐 최적화하는 편이 유리하다. 뷰 머징은 바로 이 벽을 제거해 조인 순서 재배치, 선택 조건 이동, 불필요 조인 제거 같은 후속 최적화의 문을 열어 준다.

아래 그림은 뷰 경계가 남아 있을 때와 사라질 때의 차이를 보여 준다. 중요한 점은 최종 결과 건수보다, 중간 결과가 언제 줄어드느냐가 비용을 바꾼다는 사실이다.

┌────────────────────────────────────────────────────────────────────┐
│ View boundary as optimization wall                                 │
├────────────────────────────────────────────────────────────────────┤
│ Before merge                                                       │
│   Main block : CUSTOMERS join [V]                                  │
│   View V    : ORDERS join ORDER_ITEMS                              │
│                 ▲                                                  │
│                 └─ region='SEOUL' predicate stays outside          │
│                                                                    │
│ After merge                                                        │
│   Single block : CUSTOMERS join ORDERS join ORDER_ITEMS            │
│                  + region predicate can influence join order        │
│                                                                    │
│ Same answer / different search space / different temp result size  │
└────────────────────────────────────────────────────────────────────┘

즉 뷰 머징의 필요성은 "뷰를 없애자"가 아니다. 논리적 분리는 유지하되, 물리 실행에서는 불필요한 경계를 걷어 내자는 데 있다.

• 📢 섹션 요약 비유: 서류철을 보기 좋게 분류해 두는 것은 좋지만, 실제 심사할 때는 관련 종이를 한 책상 위에 펼쳐 놓아야 빠르게 판단할 수 있다. 뷰 머징은 정리용 파일철을 잠시 벗겨 실무 처리 속도를 높이는 일과 같다.

Ⅱ. 아키텍처 및 핵심 원리

뷰 머징은 보통 네 단계로 이해하면 된다. 첫째, 옵티마이저가 SQL을 여러 질의 블록으로 나누고 어떤 뷰가 머징 후보인지 식별한다. 둘째, 그 뷰가 의미 보존 측면에서 안전한지 검사한다. 셋째, 안전하다면 뷰의 SELECT, FROM, WHERE 절을 바깥 블록에 흡수해 하나의 조인 그래프로 재구성한다. 넷째, 다시 기수성 (Cardinality)과 비용을 계산해 조인 순서, 액세스 경로, 조인 방식을 새로 결정한다.

예를 들어 다음 SQL은 사람이 보기에는 "주문 뷰와 고객을 조인"하는 형태지만, 옵티마이저는 이를 하나의 조인 문제로 다시 볼 수 있다.

SELECT c.customer_name, v.order_id
  FROM customers c
  JOIN (
        SELECT o.customer_id, o.order_id
          FROM orders o
         WHERE o.order_date >= DATE '2026-01-01'
       ) v
    ON c.customer_id = v.customer_id
 WHERE c.region = 'SEOUL';

뷰 머징이 일어나면 내부적으로는 아래와 비슷한 형태로 재구성된다.

SELECT c.customer_name, o.order_id
  FROM customers c
  JOIN orders o
    ON c.customer_id = o.customer_id
 WHERE c.region = 'SEOUL'
   AND o.order_date >= DATE '2026-01-01';

이 변환의 진짜 가치는 단순히 SQL 줄 수가 줄어드는 데 있지 않다. c.region = 'SEOUL'처럼 선택도가 큰 조건이 고객 테이블을 먼저 줄일 수 있으면, 이후 orders 접근 방식도 달라질 수 있다. 다시 말해 뷰 머징은 조건 푸시다운 (Predicate Pushdown) 과 조인 순서 최적화를 함께 더 잘 작동하게 만드는 전처리다.

물론 모든 머징이 단순하지는 않다. 일반적으로 투영·선택·조인만 있는 단순 뷰는 머징이 쉽다. 반면 집계가 들어간 뷰는 일부 DBMS (Database Management System)에서 더 엄격한 "복합 뷰 머징"이나 조인 백 (Join Back) 형태로 다뤄질 수 있으며, 아무 조건 없이 합칠 수 있는 것은 아니다. 따라서 기술사 답안에서는 "집계 뷰는 무조건 불가"처럼 단정하기보다, 기본적으로 제약이 크고 의미 보존 검사가 더 엄격하다고 설명하는 편이 정확하다.

┌────────────────────────────────────────────────────────────────────┐
│ Optimizer rewrite path                                             │
├────────────────────────────────────────────────────────────────────┤
│ SQL parse                                                          │
│   ▼                                                                │
│ Query block graph                                                  │
│   ▼                                                                │
│ Merge safety check                                                 │
│   ├─ safe   -> remove view boundary -> global cost optimization    │
│   └─ unsafe -> keep block / materialize / separate optimization    │
│   ▼                                                                │
│ Final physical plan                                                │
└────────────────────────────────────────────────────────────────────┘

• 📢 섹션 요약 비유: 뷰 머징은 부서별 회의 자료를 본부 회의 전에 통합 브리핑본으로 다시 묶는 일과 같다. 자료를 합칠 수 있으면 전체 일정 조정이 쉬워지고, 합치면 안 되는 민감 자료는 별도 봉투로 남겨 둬야 한다.

Ⅲ. 비교 및 연결

뷰 머징을 이해할 때 가장 흔한 혼동은 뷰 머징, 조건 푸시다운, 머티리얼라이제이션 (Materialization) 을 같은 것으로 보는 것이다. 셋은 모두 뷰와 관련된 실행 전략이지만, 질의 블록 경계를 어떻게 다루는지가 다르다.

예를 들어 집계 뷰를 여러 번 참조하는 보고서 SQL이라면, 뷰 머징보다 머티리얼라이제이션이 더 이득일 수 있다. 반대로 한 번만 쓰는 단순 인라인 뷰라면 굳이 경계를 유지할 이유가 없으므로 뷰 머징이 유리하다. 즉 "뷰를 합칠 수 있느냐"보다 중요한 질문은 경계를 없애는 편이 전체 비용을 더 낮추느냐다.

또한 뷰 머징은 서브쿼리 언네스팅 (Subquery Unnesting), CTE (Common Table Expression) 인라이닝, 조인 제거와도 연결된다. 모두 쿼리를 사람이 쓴 형태에서 기계가 잘 최적화할 수 있는 형태로 바꾸는 재작성 계열 기술이다. 다만 뷰 머징은 특히 FROM 절에 있는 뷰/인라인 뷰의 경계를 다룬다는 점에서 초점이 분명하다.

실무적으로는 보안 배리어 뷰, 행 수준 보안, Top-N 페이지네이션처럼 경계를 일부러 유지해야 하는 경우도 중요하다. 이런 경우에는 단순 성능보다 결과 의미와 보안 정책이 우선한다. 따라서 뷰 머징은 "무조건 좋은 최적화"가 아니라, 의미 보존이 허용하는 범위에서만 성립하는 최적화 자유도로 이해해야 한다.

• 📢 섹션 요약 비유: 뷰 머징은 벽을 허무는 리모델링이고, 조건 푸시다운은 문만 하나 더 내는 공사이며, 머티리얼라이제이션은 창고를 따로 두는 선택이다. 집 구조와 생활 패턴에 따라 정답이 달라진다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 뷰 머징 이슈는 보통 "인라인 뷰를 썼더니 왜 갑자기 느려졌는가" 혹은 "뷰 기반 SQL인데 왜 어떤 날은 빨라지고 어떤 날은 느려지는가"로 나타난다. 문제의 핵심은 뷰 자체보다, 통계 정보와 데이터 분포를 기준으로 옵티마이저가 경계를 제거할지 유지할지를 어떻게 판단하느냐다.

단순 조회형 SQL이라면 가독성을 위해 인라인 뷰를 쓰되, 옵티마이저가 머징할 수 있게 과도한 DISTINCT, 불필요한 ORDER BY, 의미 없는 중첩 블록을 남발하지 않는 편이 낫다. 반대로 사전 집계 결과를 여러 번 재사용하거나, 페이지네이션용 ROW_NUMBER() 결과를 먼저 확정해야 하거나, 테넌트 보안 경계를 뷰로 강제하는 구조라면 경계를 유지하는 편이 안전하다.

기술사 판단 체크리스트

1. 이 뷰는 단순 투영·선택·조인 중심인가, 아니면 집계·윈도 함수·Top-N처럼 의미를 바꾸는 연산을 포함하는가?
2. 바깥 블록의 선택 조건이 뷰 안쪽 테이블 행 수를 크게 줄일 수 있는가?
3. 이 뷰 결과를 한 번만 쓰는가, 아니면 여러 번 재사용하는가?
4. 실행 계획에서 VIEW, MATERIALIZE, 임시 스풀 같은 구조가 실제 병목으로 나타나는가?
5. 통계 갱신과 SQL 단순화 없이 힌트만으로 MERGE/NO_MERGE를 강제하고 있지는 않은가?
6. 성능보다 보안, 정렬 의미, 순위 확정이 더 중요한 질의는 아닌가?

자주 나오는 안티패턴

• 인라인 뷰를 썼다는 이유만으로 "반드시 임시 테이블이 생긴다"고 단정하는 경우
• 집계나 순위가 있는 뷰에 무리하게 머징을 유도해 결과 의미를 흐리는 경우
• 같은 비싼 뷰를 여러 번 쓰면서도 재사용 전략 없이 계속 인라인으로 복붙하는 경우
• 힌트로 잠깐 빨라진 계획을 영구 해법처럼 받아들이는 경우

DBMS마다 MERGE, NO_MERGE, MATERIALIZED, NOT MATERIALIZED처럼 힌트나 옵션의 이름은 다르지만, 판단 원리는 같다. 경계를 없애야 전체 탐색 공간이 넓어지는가, 아니면 경계를 남겨야 의미와 재사용성이 살아나는가를 먼저 따져야 한다.

• 📢 섹션 요약 비유: 회의실 벽을 허물면 협업은 빨라질 수 있지만, 결재 문서 보관실까지 허물면 오히려 사고가 난다. 뷰 머징도 어디는 터야 하고 어디는 남겨야 한다.

Ⅴ. 기대효과 및 결론

뷰 머징이 잘 작동하면 옵티마이저는 더 넓은 탐색 공간에서 조인 순서와 액세스 경로를 고를 수 있고, 그 결과 중간 결과 크기, 임시 공간 사용량, 디스크 I/O (Input/Output), 응답시간이 함께 줄어드는 경우가 많다. 특히 선택도가 높은 조건이 바깥 블록에 있을 때, 머징은 "늦게 줄일 데이터를 일찍 줄이게" 만드는 강력한 계기가 된다.

하지만 한계도 분명하다. 잘못된 기수성 추정 위에서는 머징 이후에도 엉뚱한 조인 순서가 선택될 수 있고, 일부 질의는 경계를 유지해야 오히려 더 안정적이거나 의미상 안전하다. 따라서 뷰 머징은 만능 버튼이 아니라, 통계 품질·질의 의미·재사용 패턴이 함께 맞아야 효과를 내는 최적화다.

결론적으로 뷰 머징은 "뷰를 없애는 기술"이 아니라, 논리적 설계와 물리적 실행을 분리하는 옵티마이저의 대표적 재작성 전략으로 기억하는 것이 맞다. 읽기 쉬운 SQL을 쓰되, 실행 시에는 불필요한 최적화 벽을 걷어 낼 수 있어야 진짜 좋은 질의가 된다.

• 📢 섹션 요약 비유: 정리정돈은 일을 시작하기 쉽게 만들어 주지만, 실제 작업 때는 필요한 도구를 한 작업대에 모아 두는 편이 더 빠르다. 뷰 머징은 정리와 실행을 구분하는 숙련자의 손놀림이다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

Readable SQL with inline view
        │
        ▼
Query block analysis
        │
        ▼
Merge safety check
        │
        ├──────────────► keep boundary / materialize
        ▼
View merging
        │
        ▼
Predicate movement + join reorder
        │
        ▼
Lower intermediate result cost

이 흐름도는 "가독성을 위한 분리 → 안전성 검사 → 경계 제거 여부 결정 → 전역 최적화 → 중간 결과 축소"라는 뷰 머징의 사고 흐름을 보여 준다.

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

1. 큰 숙제를 여러 종이로 나눠 적어 두면 보기에는 편하지만, 풀 때는 관련 종이를 한곳에 모아야 빨라요.
2. 데이터베이스도 표를 나눠 적은 뷰를 다시 합쳐 보면 더 쉬운 길을 찾을 수 있어요.
3. 하지만 점수표처럼 순서를 꼭 지켜야 하는 종이는 함부로 섞으면 안 돼요.