Ch06. 뷰 - 뷰의 장점과 단점

뷰의 장점

편리성과 재사용성

가장 큰 장점이다. 복잡한 "SELECT" 쿼리(수십 줄에 달하는 "JOIN", 서브쿼리, "CASE" 문의 조합)를 뷰 뒤에 숨겨둘 수 있다.

• 사용자 입장: 쿼리의 내부 로직을 전혀 몰라도, "SELECT * FROM v_my_report;" 한 줄만으로 원하는 결과를 얻을 수 있다.
• 개발자 입장: 동일한 로직이 여러 곳에서 필요할 때, 뷰 하나만 만들어두면 모두가 재사용할 수 있다. 만약 로직을 수정해야 할 경우, 뷰의 정의(ALTER VIEW)만 한 번 수정하면 이 뷰를 사용하는 모든 곳에 즉시 반영되므로 유지보수성이 극적으로 향상된다.

 

보안성

실무에서 뷰를 사용하는 가장 중요한 이유 중 하나다. 뷰는 데이터베이스에 대한 섬세한 "권한 제어"를 가능하게 한다.

• 특정 컬럼 숨기기: "employees" 테이블에서 "salary"(연봉)나 "private_info"(개인정보) 컬럼을 제외한 뷰를 만들어, 일반 직원들에게는 해당 뷰만 조회할 수 있는 권한을 줄 수 있다.
• 특정 행만 노출하기: 마케팅팀 직원에게는 "orders" 테이블에서 "마케팅" 캠페인을 통해 들어온 주문 데이터만 보여주는 뷰를 만들어 제공할 수 있다.

이렇게 하면, 사용자에게 원본 테이블에 대한 직접적인 접근 권한을 주지 않고도, 그들이 꼭 봐야 할 데이터만 안전하게 노출하는 것이 가능해진다.

 

논리적 데이터 독립성

뷰는 일종의 "추상화 계층" 역할을 한다.

• 만약 데이터베이스 구조를 변경해야 하는 상황(테이블 분리, 컬럼명 변경 등)이 발생했다고 하자. 이때, 변경 이전과 동일한 구조의 뷰를 새로 만들어 준다면, 이 뷰를 사용하던 응용 프로그램들은 원본 테이블이 변경되었다는 사실조차 모른 채 기존 코드를 그대로 사용할 수 있다.
• 뷰가 중간에서 물리적인 테이블의 변화를 숨겨주는 방패 역할을 하는 셈이다.

 

뷰의 단점

성능 문제

"SELECT * FROM my_view;"라는 간단한 쿼리 뒤에는 어마어마하게 무거운 실제 쿼리가 숨어있을 수 있다.

• 착각: 사용자는 자신이 매우 가벼운 쿼리를 실행한다고 착각하지만, 실제로는 시스템에 큰 부하를 주는 쿼리를 날리고 있을 수 있다.
• 최적화의 한계: 데이터베이스의 쿼리 옵티마이저는 매우 똑똑하지만, 뷰의 구조가 너무 복잡해지면 최적의 실행 계획을 찾아내는 데 어려움을 겪을 수 있다. 특히 뷰 위에 또 다른 뷰를 쌓는 방식(Nested Views)은 성능 저하의 주된 원인이 되므로 가급적 피해야 한다.

업데이트 제약

뷰를 테이블처럼 다룰 수 있다고 했지만, 그것은 주로 조회(읽기)에 국한된 이야기다.

• 수정 불가(대부분의 경우): "JOIN", 집계 함수(SUM, COUNT 등), "GROUP BY", "DISTINCT" 등을 사용한 복잡한 뷰는 일반적으로 "INSERT", "UPDATE", "DELETE"가 불가능하다.
  • 왜냐하면 데이터베이스 입장에서, 뷰의 한 행을 수정하는 것이 원본 테이블들의 데이터를 어떻게 바꿔야 하는지에 대한 명확한 규칙을 특정할 수 없기 때문이다.
• 수정 가능: 뷰가 오직 하나의 기본 테이블만을 참조하고, 뷰의 모든 컬럼이 기본 테이블의 실제 컬럼을 직접 참조하는 경우에는 뷰에 데이터를 추가/수정할 수 있다. 이 경우 원본 테이블의 값이 변경된다.

실무 규칙: "뷰는 기본적으로 조회용이다" 라고 생각하는 것이 가장 안전하고 일반적인 원칙이다. 데이터를 수정해야 한다면, 뷰가 아닌 원본 테이블에 직접 수행해야 한다.

 

 

 

복잡한 로직을 편리하게 재사용하고 보안을 강화하는 데는 좋은 도구지만, 성능 저하의 가능성을 내포하고 있으며 데이터 수정에는 제약이 따른다는 한계를 가지고 있다.