419. 뷰 (VIEW) - 가상 테이블

⚠️ 이 문서는 복잡하게 얽혀있는 여러 개의 진짜 테이블들을 하나로 합쳐서 보여주거나, **진짜 테이블에 들어있는 민감한 개인정보를 숨긴 채로 사용자에게 필요한 정보만 딱 잘라서 보여주기 위해 창문에 덧대는 '가상 테이블'인 뷰(VIEW)**를 다룹니다.

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

  1. 본질: 뷰(View)는 하드디스크에 실제 데이터를 저장하지 않는다. 단지 "어떻게 데이터를 모아서 보여줄지"에 대한 **SQL 쿼리문(로직)만 저장해 둔 '가짜(가상) 테이블'**이다.
  2. 가치: JOIN이 5번이나 걸린 끔찍한 쿼리를 뷰로 만들어두면, 다음부턴 그냥 SELECT * FROM 뷰이름 한 줄로 끝난다. 또한 민감한 컬럼(주민번호)을 뺀 뷰를 만들면 완벽한 보안 통제가 가능하다.
  3. 한계: 뷰는 뼈대 없는 가짜 테이블이므로 인덱스(Index)를 직접 걸 수 없고, 뷰를 통해서 원본 데이터를 수정(UPDATE, INSERT)하는 데에는 매우 까다로운 제약이 따른다.

Ⅰ. 개요: 선글라스를 끼고 세상을 보라 (Context & Necessity)

회사의 직원 테이블에는 직원의 이름, 부서, 연봉, 주민번호가 들어있다.

  • 기획팀 막내에게 직원 명단을 뽑아오라고 지시했다.
  • 하지만 막내가 쿼리를 날려서 직원들의 연봉과 주민번호까지 다 봐버리면 큰일이다.

이때 DBA는 기획팀 막내를 위한 **'뷰(View)'**를 하나 만들어준다.

CREATE VIEW 기획팀용_직원명단 AS
SELECT 이름, 부서 FROM 직원;  -- (연봉, 주민번호는 뺌!)

이제 막내는 기획팀용_직원명단이라는 가짜 테이블만 볼 수 있다. DB 안에 진짜로 저런 테이블이 새로 생긴 건 아니다. 막내가 저 뷰를 조회할 때마다, DB가 뒤에서 몰래 진짜 직원 테이블에 가서 '이름과 부서'만 쓱 뽑아서 화면에 보여주는 것이다.

📢 섹션 요약 비유: 뷰(View)는 **'셀로판지 선글라스'**와 같습니다. 세상(진짜 테이블)은 하나지만, 어떤 선글라스(뷰)를 끼느냐에 따라 빨간색만 보일 수도 있고, 모자이크 처리되어 보일 수도 있죠. 선글라스 자체는 아무 실체가 없는 투명한 유리알일 뿐입니다.

Ⅱ. 뷰(View)의 3대 장점 ★

시험과 실무에서 뷰를 쓰는 명확한 이유들이다.

1. 보안성 (Security)

  • 사용자별로 테이블의 특정 컬럼이나 특정 행(Row)만 보여주도록 접근을 통제(Access Control)할 수 있다.
  • 데이터 독립성 1단계인 '논리적 데이터 독립성(395번 문서)'을 구현하는 핵심 기술이다.

2. 편의성 (Simplicity)

  • 조인(JOIN)과 서브쿼리(Subquery)가 떡칠 된 100줄짜리 쿼리를 Daily_Sales_View라는 이름으로 저장해 두면, 누구나 SELECT * FROM Daily_Sales_View 한 줄로 복잡한 데이터를 쉽게 뽑아볼 수 있다.

3. 데이터 독립성 제공

  • 진짜 테이블 구조가 바뀌어도(예: 컬럼 이름 변경), 뷰의 정의(SQL)만 슬쩍 고쳐주면 기존 응용 프로그램의 소스코드는 한 줄도 안 고쳐도 된다.

Ⅲ. 뷰의 치명적인 단점과 제약

가짜 테이블이라서 생기는 어쩔 수 없는 한계들이다.

  1. 독자적인 인덱스(Index) 생성 불가
    • 뷰는 실체가 없으므로 검색 속도를 높이는 인덱스를 달 수 없다. (단, Oracle의 Materialized View 같은 특수 뷰는 실제 데이터를 디스크에 저장하므로 예외적으로 인덱스 생성이 가능하다.)
  2. ALTER VIEW (변경 불가)
    • 한 번 만들어진 뷰의 뼈대(쿼리)는 수정할 수 없다. 고치고 싶으면 무조건 지우고(DROP) 새로 만들어야(CREATE) 한다. (또는 CREATE OR REPLACE VIEW 사용)
  3. 삽입/수정/삭제(DML)의 극심한 제약
    • 뷰를 통해서 원본 데이터를 고칠 수는 있다. 하지만 뷰에 그룹 함수(SUM, GROUP BY)나 조인(JOIN)이 들어간 경우에는 "도대체 원본의 어느 줄을 고치라는 거야?"라고 DB가 헷갈리므로 UPDATE나 INSERT가 절대 불가능하다.
┌──────────────────────────────────────────────────────────────┐
│           진짜 테이블 (Base Table)과 뷰 (View)의 관계 시각화             │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 📦 원본 테이블 (Users) - 하드디스크에 진짜 있음 ]                 │
│  ID │ 이름 │ 나이 │ 비밀번호(🔒)                                │
│ ────┼────┼────┼──────                                        │
│  1  │ 철수 │ 20 │ 1234                                        │
│                                                              │
│       ▲ (DB 엔진이 실시간으로 렌더링)                             │
│       │                                                      │
│ [ 👓 뷰 (Public_Users_View) - 디스크에 없음, 쿼리만 저장됨 ]        │
│  ID │ 이름 │ 나이                                             │
│ ────┼────┼────                                              │
│  1  │ 철수 │ 20        ◀── (비밀번호 컬럼은 아예 안 보임!)             │
│                                                              │
│ ★ 특징: 사용자는 이 뷰가 진짜 테이블인 줄 알고 SELECT 쿼리를 날린다.       │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"복잡함을 덮는 가장 우아한 장막." 뷰(View)는 데이터베이스 설계에서 없어서는 안 될 논리적 완충재다. 프론트엔드 개발자가 API 응답 포맷을 요구할 때, 백엔드 개발자가 일일이 자바 코드로 DTO를 매핑해 주는 대신, DB 단에서 아예 화면에 맞춘 뷰를 하나 짜주면 개발 생산성이 미친 듯이 올라간다. 다만 뷰 안에서 뷰를 부르고 그 뷰가 또 뷰를 부르는 '뷰 체인(View Chain)' 현상이 발생하면, 성능이 바닥으로 꽂혀도 범인을 찾을 수 없는 지옥도가 펼쳐지므로 오남용은 절대 금물이다.

📌 관련 개념 맵

  • 관련 명령어: DDL (CREATE VIEW), DCL (GRANT - 권한 통제 시너지)
  • 목적: 논리적 데이터 독립성 (395번 문서)
  • 특수 뷰: Materialized View (구체화된 뷰 - 속도를 위해 진짜 데이터를 디스크에 저장해 두는 뷰)
  • 보안 패턴: Row-Level Security (RLS)

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

  1. 뷰(View)는 투명한 '셀로판지'와 같아요.
  2. 진짜 그림(테이블) 위에 빨간색 셀로판지(뷰)를 대고 보면 빨간색만 보이고, 파란색 셀로판지를 대면 파란색만 보이죠!
  3. 내가 셀로판지를 통해 본다고 해서 진짜 그림이 망가지거나 변하는 건 아니랍니다. 그저 내가 원하는 모양으로 가려서 보는 마법이죠!