[Oracle/PostgreSQL] 뷰(View)가 너무 느리다면? 일반 뷰와 구체화 뷰(Materialized View) 완벽 비교

복잡한 조인과 서브쿼리가 얽힌 SQL을 매번 작성하는 것은 고역입니다. 이를 해결하기 위해 우리는 보통 뷰(View)를 사용하죠. 하지만 데이터가 수천만 건을 넘어가면 뷰를 조회하는 것조차 고통스러운 속도로 변하곤 합니다.

이때 구원투수로 등장하는 것이 바로 구체화 뷰(Materialized View, MView)입니다. 오늘은 두 기술의 결정적인 차이점과 실무 적용 사례를 깊이 있게 알아보겠습니다.

---

1. 일반 뷰(View): "가상 테이블이자 쿼리의 별명"

일반적인 뷰는 데이터를 실제로 가지고 있지 않습니다. 그저 복잡한 SELECT 문을 저장해 둔 '창문'이나 '별명'에 불과합니다.

• 작동 원리: 사용자가 뷰를 조회하면, 데이터베이스는 내부적으로 저장된 쿼리를 다시 실행하여 결과를 실시간으로 생성합니다.
• 장점:
  • 논리적 독립성: 복잡한 쿼리를 단순화하여 사용자에게 보여줍니다.
  • 보안성: 원본 테이블의 특정 컬럼만 노출하고 싶은 경우 유용합니다.
  • 저장 공간: 쿼리 텍스트만 저장하므로 저장 공간을 거의 차지하지 않습니다.
• 단점:
  • 성능 한계: 기반 테이블의 데이터가 많거나 조인이 복잡하면, 뷰를 조회할 때마다 무거운 연산을 매번 수행해야 합니다.

---

2. 구체화 뷰(Materialized View): "결과를 물리적으로 저장한 스냅샷"

구체화 뷰(이하 MView)는 쿼리 결과 데이터를 실제 디스크 공간을 할당해 물리적으로 저장합니다. 즉, 쿼리 결과를 테이블처럼 미리 만들어두는 것입니다.

• 작동 원리: 복잡한 집계나 조인이 완료된 최종 결과물을 미리 물리적으로 저장해두고, 사용자가 조회할 때 미리 계산된 결과만 즉시 내줍니다.
• 장점:
  • 폭발적인 조회 성능: 이미 계산된 값을 읽기만 하므로 연산 시간이 거의 '0'에 수렴합니다.
  • 인덱스 생성 가능: 물리적 데이터이므로 MView 위에 별도의 인덱스를 걸어 더 빠르게 만들 수 있습니다.
• 단점:
  • 저장 공간 소모: 테이블과 동일하게 데이터를 저장하므로 디스크 공간을 차지합니다.
  • 데이터 동기화 부하: 원본 데이터가 변하면 MView의 데이터도 갱신(Refresh)해야 하는 추가 비용이 발생합니다.

---

3. 실무 시나리오: 일별 매출 보고서

🛒 상황

하루에 100만 건씩 발생하는 주문 테이블과 상품 테이블을 조인하여 '카테고리별 일간 총 매출'을 집계해야 합니다. 한 달치 통계를 뽑으려면 3,000만 건의 데이터를 매번 조인하고 SUM 해야 합니다.

❌ 일반 뷰를 쓴다면?

SQL

CREATE VIEW daily_sales_view AS
SELECT p.category, o.order_date, SUM(o.amount) as total_amount
FROM orders o, products p
WHERE o.product_id = p.id
GROUP BY p.category, o.order_date;

• 결과: 사용자가 이 뷰를 조회할 때마다 DB는 3,000만 건을 다시 조인하고 집계합니다. 결과가 나올 때까지 커피 한 잔을 마시고 와야 할지도 모릅니다.

✅ 구체화 뷰(MView)를 쓴다면?

SQL

CREATE MATERIALIZED VIEW daily_sales_mview
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
AS
SELECT p.category, o.order_date, SUM(o.amount) as total_amount
FROM orders o, products p
WHERE o.product_id = p.id
GROUP BY p.category, o.order_date;

• 결과: 새벽에 한 번만 실행해서 결과를 저장해두면, 낮 동안 수만 명의 직원이 이 MView를 조회해도 단 0.1초 만에 결과가 출력됩니다. 이미 계산된 합계 값만 읽기 때문입니다.

---

4. 핵심 비교: 언제 무엇을 써야 할까?

비교 항목	일반 뷰 (View)	구체화 뷰 (MView)
데이터 저장	없음 (실시간 쿼리 실행)	있음 (물리적 테이블 형태 저장)
조회 속도	기반 데이터 양에 따라 느려짐	압도적으로 빠름
데이터 정합성	항상 최신 데이터 (실시간)	갱신 주기에 따라 과거 데이터일 수 있음
인덱스	생성 불가	생성 가능
적합한 상황	데이터가 적거나, 최신성이 중요할 때	대량 데이터 통계, 배치 작업용

---

5. MView의 생명줄: 갱신(Refresh) 전략

MView는 원본과 데이터가 달라질 수 있습니다. 오라클 기준 대표적인 갱신 전략은 다음과 같습니다.

1. ON COMMIT: 원본 테이블이 커밋될 때마다 MView를 갱신합니다. (정합성은 높지만 원본 성능에 부하를 줌)
2. ON DEMAND: 사용자가 원할 때나 정해진 주기(스케줄러)에 따라 갱신합니다. (실무에서 가장 선호)
3. FAST Refresh: 바뀐 부분만 찾아서 업데이트합니다. (로그 테이블 필요)
4. COMPLETE Refresh: 데이터를 싹 지우고 다시 전체를 생성합니다.

---

🏁 마무리하며: "전략적 선택이 성능을 결정합니다"

• View는 복잡한 SQL을 깔끔하게 관리하고 보안을 강화하기 위한 '편의 도구'입니다.
• MView는 실시간성이 조금 떨어지더라도 조인과 집계 비용을 미리 지불하여 사용자 경험을 극대화하는 '성능 치트키'입니다.

대용량 데이터를 다루는 백엔드 개발자나 DBA라면, 단순히 뷰를 만드는 것에 그치지 말고 데이터의 성격에 따라 구체화 뷰 도입을 적극적으로 검토해 보시기 바랍니다!