시스매

데이터베이스 뷰 완벽 정복 A to Z 핸드북

19 min read

2025-08-27 23:15

  • 데이터베이스 뷰는 실제 데이터를 저장하지 않고, 하나 이상의 테이블에서 파생된 가상의 테이블입니다.

  • 뷰는 복잡한 쿼리를 단순화하고, 데이터 접근을 제어하여 보안을 강화하며, 논리적 데이터 독립성을 제공하는 목적으로 사용됩니다.

  • 뷰는 단순 뷰와 복합 뷰로 나뉘며, 읽기 전용으로 사용될 때도 있고 특정 조건 하에서는 데이터 수정(INSERT, UPDATE, DELETE)도 가능합니다.

데이터베이스 뷰 완벽 정복 A to Z 핸드북

데이터베이스를 다루다 보면 ‘뷰(View)‘라는 개념을 반드시 마주치게 됩니다. 뷰는 단순히 테이블을 조회하는 또 다른 방법이라고 생각하기 쉽지만, 그 이면에는 데이터베이스를 더욱 효율적이고 안전하게 관리할 수 있는 강력한 기능이 숨어있습니다. 마치 우리가 스마트폰에서 실제 파일이 저장된 복잡한 경로를 몰라도 바탕화면의 바로가기 아이콘을 통해 손쉽게 앱을 실행하는 것처럼, 뷰는 복잡한 데이터의 세계로 통하는 편리한 창구 역할을 합니다.

이 핸드북에서는 뷰가 왜 만들어졌는지, 어떤 구조로 이루어져 있으며 어떻게 사용하는지, 그리고 실무에서 마주칠 수 있는 심화 내용까지 A부터 Z까지 모든 것을 상세하게 다룰 것입니다.

1. 뷰의 탄생 배경 왜 우리는 뷰를 사용해야 할까?

뷰의 필요성을 이해하려면 먼저 뷰가 없는 세상을 상상해보는 것이 좋습니다. 데이터베이스에는 수많은 테이블이 있고, 각 테이블은 복잡한 관계를 맺고 있습니다. 만약 모든 사용자가 이 모든 테이블의 구조를 파악하고, 필요한 데이터를 얻기 위해 매번 긴 SQL 문을 작성해야 한다면 어떨까요?

  • 반복적이고 복잡한 쿼리: 여러 테이블을 조인(JOIN)하고, 특정 조건으로 필터링하며, 데이터를 그룹핑하는 복잡한 쿼리를 매번 작성해야 합니다. 이는 시간 낭비일 뿐만 아니라, 실수할 가능성도 높입니다.

  • 보안의 취약성: 사용자에게 필요 이상의 데이터(예: 개인정보, 급여 정보)가 노출될 수 있습니다. 특정 부서의 직원은 해당 부서의 데이터만 봐야 하지만, 전체 테이블에 접근 권한이 있다면 민감한 정보가 유출될 위험이 있습니다.

  • 논리적 종속성: 데이터베이스의 테이블 구조가 변경되면(예: 컬럼 이름 변경, 테이블 분리), 해당 테이블을 사용하는 모든 애플리케이션의 쿼리문을 일일이 수정해야 하는 대참사가 발생합니다.

이러한 문제들을 해결하기 위해 ‘뷰’라는 개념이 탄생했습니다. 뷰는 데이터베이스 설계자와 사용자 사이의 ‘추상화 계층(Abstraction Layer)’ 역할을 수행하며 다음과 같은 핵심적인 목적을 달성합니다.

  1. 쿼리 단순화 (Simplicity): 복잡한 쿼리 로직을 뷰 내부에 숨기고, 사용자는 마치 하나의 테이블을 조회하듯 간단한 SELECT 문으로 원하는 결과를 얻을 수 있습니다.

  2. 보안 강화 (Security): 사용자에게 테이블의 특정 행이나 열만 선택적으로 보여줄 수 있습니다. 즉, 접근 권한을 세밀하게 제어하여 데이터 보안 수준을 획기적으로 높입니다.

  3. 논리적 데이터 독립성 (Logical Data Independence): 테이블의 구조가 변경되더라도 뷰만 수정하면 되므로, 사용자의 쿼리나 애플리케이션 코드는 영향을 받지 않습니다. 이는 유지보수 비용을 크게 절감시킵니다.

2. 뷰의 구조와 종류 파헤치기

뷰는 종종 ‘가상 테이블(Virtual Table)‘이라고 불립니다. 왜냐하면 뷰는 테이블처럼 보이지만, 실제로 데이터를 저장하고 있지 않기 때문입니다. 뷰는 CREATE VIEW 구문으로 생성되며, 그 본질은 데이터베이스에 저장된 하나의 SELECT 쿼리문입니다. 사용자가 뷰를 조회하면, 데이터베이스 시스템은 해당 뷰에 정의된 SELECT 문을 실행하여 그 결과를 동적으로 생성해서 보여줍니다.

뷰의 작동 원리

  1. 생성 (CREATE): 관리자 또는 개발자가 CREATE VIEW 뷰이름 AS SELECT ... 구문을 사용하여 뷰를 정의합니다. 이 정의(SELECT 문)는 데이터 딕셔너리(Data Dictionary)에 저장됩니다.

  2. 조회 (QUERY): 사용자가 SELECT * FROM 뷰이름 과 같이 뷰를 조회합니다.

  3. 실행 (EXECUTE): 데이터베이스 관리 시스템(DBMS)은 데이터 딕셔너리에서 해당 뷰의 정의를 찾아, 저장된 SELECT 문을 기반 테이블(Base Table)에 실행합니다.

  4. 결과 반환 (RESULT): 실행된 쿼리의 결과 집합(Result Set)이 사용자에게 반환됩니다.

이 과정에서 뷰 자체는 데이터를 가지고 있지 않으며, 항상 최신 데이터를 기반 테이블에서 가져와 보여줍니다. 기반 테이블의 데이터가 변경되면, 뷰를 통해 조회되는 데이터도 실시간으로 변경됩니다.

뷰의 종류

뷰는 그 기반이 되는 SELECT 문의 복잡성에 따라 크게 **단순 뷰(Simple View)**와 **복합 뷰(Complex View)**로 나눌 수 있습니다.

구분단순 뷰 (Simple View)복합 뷰 (Complex View)
기반 테이블하나의 테이블두 개 이상의 테이블
함수 포함 여부집계 함수(SUM, AVG 등)나 분석 함수 미포함집계 함수나 분석 함수 포함 가능
GROUP BY 절미포함포함 가능
DISTINCT 키워드미포함포함 가능
DML 작업가능 (INSERT, UPDATE, DELETE)불가능 (읽기 전용)

단순 뷰는 하나의 테이블에서 파생되며, 주로 특정 컬럼만 선택하거나 특정 조건의 행만 필터링하는 등 보안이나 편의성을 위해 사용됩니다. 단순 뷰는 특정 조건 하에서 데이터를 수정하는 DML(Data Manipulation Language) 작업이 가능합니다.

복합 뷰는 여러 테이블을 조인하거나, 데이터를 그룹핑하고 집계 함수를 사용하는 등 복잡한 로직을 포함합니다. 여러 테이블의 데이터가 얽혀있기 때문에 어떤 데이터를 수정해야 할지 명확하지 않아 대부분 **읽기 전용(Read-Only)**으로 사용됩니다.

3. 뷰 사용법 실전 가이드

이제 실제 SQL을 통해 뷰를 생성하고 활용하는 방법을 알아보겠습니다. Employees (직원) 테이블과 Departments (부서) 테이블이 있다고 가정해 봅시다.

Employees 테이블 | emp_id | emp_name | dept_id | salary | hire_date | | :--- | :--- | :--- | :--- | :--- | | 101 | Alice | 10 | 70000 | 2020-01-15 | | 102 | Bob | 20 | 85000 | 2019-03-10 | | 103 | Charlie | 10 | 65000 | 2021-05-20 | | 104 | David | 30 | 92000 | 2018-11-01 |

Departments 테이블 | dept_id | dept_name | location | | :--- | :--- | :--- | | 10 | 개발팀 | 서울 | | 20 | 기획팀 | 부산 | | 30 | 디자인팀 | 서울 |

뷰 생성 (CREATE VIEW)

예제 1: 단순 뷰 생성 (개발팀 직원 정보) 개발팀(dept_id=10) 소속 직원의 사번, 이름, 입사일 정보만 보여주는 뷰를 만들어 보겠습니다. 급여와 같은 민감 정보는 제외합니다.

CREATE VIEW V_DEV_EMPLOYEES AS
SELECT emp_id, emp_name, hire_date
FROM Employees
WHERE dept_id = 10;

이제 인사팀 담당자는 복잡한 조건 없이 아래와 같이 간단한 쿼리로 개발팀 직원 정보만 조회할 수 있습니다.

SELECT * FROM V_DEV_EMPLOYEES;

예제 2: 복합 뷰 생성 (부서별 평균 급여) 부서 이름과 해당 부서의 평균 급여를 보여주는 통계용 뷰를 생성해 보겠습니다.

CREATE VIEW V_DEPT_AVG_SALARY AS
SELECT
    d.dept_name,
    AVG(e.salary) AS average_salary
FROM
    Employees e
JOIN
    Departments d ON e.dept_id = d.dept_id
GROUP BY
    d.dept_name;

경영진은 이 뷰를 통해 복잡한 조인이나 그룹핑 없이 부서별 평균 급여 현황을 쉽게 파악할 수 있습니다.

SELECT * FROM V_DEPT_AVG_SALARY;

뷰 수정 및 삭제 (ALTER VIEW, DROP VIEW)

  • 뷰 수정: 기존 뷰의 정의를 변경하고 싶을 때는 ALTER VIEW 또는 CREATE OR REPLACE VIEW 구문을 사용합니다.

    ALTER VIEW V_DEV_EMPLOYEES AS
SELECT emp_id, emp_name, hire_date, salary -- 급여 컬럼 추가
FROM Employees
WHERE dept_id = 10;

  • 뷰 삭제: 더 이상 사용하지 않는 뷰는 DROP VIEW로 간단하게 삭제할 수 있습니다. 뷰를 삭제해도 기반 테이블의 데이터는 전혀 영향을 받지 않습니다.

    DROP VIEW V_DEV_EMPLOYEES;

뷰를 통한 데이터 수정 (DML)

앞서 언급했듯이, 특정 조건을 만족하는 단순 뷰는 INSERT, UPDATE, DELETE 작업이 가능합니다. 하지만 몇 가지 제약 조건이 따릅니다.

  • 뷰가 하나의 테이블만을 참조해야 합니다.

  • 뷰 정의에 GROUP BY, DISTINCT, 집계 함수 등이 포함되지 않아야 합니다.

  • 기반 테이블에서 NOT NULL 제약 조건이 있는 컬럼이 뷰에 포함되어 있어야 INSERT가 가능합니다.

예제: 뷰를 통한 UPDATE V_DEV_EMPLOYEES 뷰에 급여 정보가 포함되어 있다고 가정하고, Alice의 급여를 인상해 보겠습니다.

UPDATE V_DEV_EMPLOYEES
SET salary = 75000
WHERE emp_id = 101;

이 쿼리는 성공적으로 실행되며, Employees 원본 테이블의 데이터가 변경됩니다. 하지만 복합 뷰인 V_DEPT_AVG_SALARY의 평균 급여를 직접 수정하려는 시도는 실패합니다. DBMS는 어떤 직원의 급여를 변경해야 평균값이 맞춰지는지 알 수 없기 때문입니다.

4. 심화 내용 더 깊이 알아보기

인덱싱된 뷰 (Indexed View / Materialized View)

일반적인 뷰는 데이터를 저장하지 않고 매번 동적으로 결과를 생성한다고 했습니다. 하지만 매우 복잡하고 조회 비용이 큰 뷰의 경우, 성능 저하의 원인이 될 수 있습니다. 이때 사용하는 것이 인덱싱된 뷰(SQL Server) 또는 **구체화된 뷰(Oracle, PostgreSQL)**입니다.

이 뷰는 일반 뷰와 달리, 쿼리 결과를 물리적인 디스크 공간에 저장합니다. 마치 테이블처럼 실제 데이터와 인덱스를 가지게 됩니다.

  • 장점: 복잡한 조인이나 집계 연산이 포함된 뷰의 조회 성능을 획기적으로 향상시킬 수 있습니다. 데이터 웨어하우스(DW)나 OLAP 환경에서 자주 사용됩니다.

  • 단점:

    • 물리적인 저장 공간을 차지합니다.

    • 기반 테이블의 데이터가 변경될 때마다 뷰의 데이터도 함께 갱신되어야 하므로 DML(INSERT, UPDATE, DELETE) 작업에 오버헤드가 발생합니다.

    • 생성 및 유지보수에 제약 조건이 많아 관리가 까다롭습니다.

WITH CHECK OPTION

뷰를 통해 데이터를 수정할 때, 뷰의 WHERE 조건절에 위배되는 변경을 막고 싶을 때 사용하는 옵션입니다. 데이터의 일관성을 유지하는 데 중요한 역할을 합니다.

예를 들어, V_DEV_EMPLOYEES 뷰는 dept_id = 10인 직원만 보여줍니다. WITH CHECK OPTION 없이 뷰를 생성했다면, 아래와 같은 쿼리가 가능합니다.

UPDATE V_DEV_EMPLOYEES
SET dept_id = 20 -- 개발팀 직원을 기획팀으로 변경
WHERE emp_id = 101;

이 쿼리가 실행되면 Alice는 더 이상 개발팀 소속이 아니므로, V_DEV_EMPLOYEES 뷰를 다시 조회했을 때 Alice는 보이지 않게 됩니다. (사라지는 현상 발생)

이러한 논리적 모순을 방지하기 위해 뷰를 생성할 때 WITH CHECK OPTION을 추가합니다.

CREATE OR REPLACE VIEW V_DEV_EMPLOYEES AS
SELECT emp_id, emp_name, dept_id, salary
FROM Employees
WHERE dept_id = 10
WITH CHECK OPTION;

이제 이 뷰를 통해 dept_id를 10이 아닌 다른 값으로 변경하려는 시도는 오류를 발생시키며 실패합니다.

5. 결론 뷰, 현명하게 사용하는 지혜

지금까지 데이터베이스 뷰의 모든 것을 살펴보았습니다. 뷰는 단순히 쿼리를 줄여주는 편의 기능이 아니라, 데이터를 논리적으로 추상화하여 보안, 편의성, 유지보수성을 모두 잡는 강력한 도구입니다.

  • 사용자에게는 복잡한 내부 구조를 감추고 필요한 데이터만 명확하게 제공하는 ‘맞춤형 창’을 제공합니다.

  • 개발자에게는 테이블 구조 변경에 유연하게 대처할 수 있는 ‘방어막’을 제공하여 유지보수 효율을 높여줍니다.

  • 데이터베이스 관리자에게는 사용자별 접근 권한을 세밀하게 제어할 수 있는 ‘보안 게이트’ 역할을 합니다.

물론 뷰를 남용하면 오히려 성능 저하를 유발하거나 관리 포인트를 늘리는 부작용을 낳을 수도 있습니다. 특히 중첩된 뷰(뷰 위에 또 다른 뷰를 만드는 구조)는 쿼리의 복잡도를 기하급수적으로 높일 수 있으므로 신중하게 사용해야 합니다.

결론적으로, 뷰의 작동 원리와 장단점을 명확히 이해하고, 각 상황에 맞는 최적의 뷰를 설계하여 사용하는 것이 데이터베이스를 더욱 견고하고 효율적으로 운영하는 핵심 비결이라 할 수 있습니다. 이 핸드북이 여러분의 데이터베이스 여정에 든든한 나침반이 되기를 바랍니다.

레퍼런스(References)

뷰

그래프 뷰

백링크