뷰

뷰는 쓰는 자리마다 가리키는 것이 다른 말입니다. 데이터베이스의 뷰와 화면의 뷰는 이름만 같지 서로 다른 것입니다. 그래서 어느 자리의 뷰인지 먼저 맞추지 않으면, 같은 말을 주고받으면서 서로 다른 것을 떠올린 채 이야기가 흘러갑니다.

상세

관계형 데이터베이스에서 뷰는 질의입니다. PostgreSQL 문서는 CREATE VIEW 가 어떤 질의의 뷰를 정의한다고 적습니다. 그 뷰는 물리적으로 구체화되지 않는다고 적습니다. 대신 질의가 다른 질의 안에서 참조될 때마다 다시 실행된다고 적습니다.

화면을 다루는 자리에서 뷰는 객체입니다. Android 문서는 View 클래스가 UI(User Interface, 사용자 인터페이스) 구성 요소의 기본 블록을 나타낸다고 적습니다. 뷰 하나가 화면에서 사각 영역을 차지한다고 적습니다. 그리고 그리기와 이벤트 처리를 책임진다고 적습니다.

배열과 버퍼를 다루는 자리에서 뷰는 참조입니다. NumPy 문서는 데이터를 복사해 옮기지 않고 내부 데이터 버퍼에 바로 접근하는 방법을 뷰라고 적습니다. 데이터 버퍼는 그대로 남는다고 적습니다. 그래서 뷰에 가한 변경이 원본에도 나타난다고 적습니다.

웹 프레임워크에서 뷰는 함수입니다. Django 문서는 뷰 함수를 웹 요청을 받아 웹 응답을 돌려주는 파이썬 함수라고 적습니다. 다만 이 자리는 프레임워크 안에서 또 갈립니다. Ruby on Rails 가이드는 Action View 가 MVC(Model-View-Controller, 모델-뷰-컨트롤러)의 V 라고 적습니다. 그리고 Action View 의 템플릿을 그냥 뷰라고도 부른다고 적습니다.

네 뜻을 한 문장으로 묶고 싶어집니다. "원본을 소유하지 않고 보여 주기만 하는 것" 이라고 적으면 넷이 다 걸리는 것처럼 보입니다. 그런데 Android 의 View 가 이 문장에 안 맞습니다. 문서가 그리기와 이벤트 처리를 이 클래스의 책임이라고 못 박아 두었습니다. 보여 주기만 하는 자리가 아닙니다.

공유하는 뼈대는 이름이 같다는 것까지입니다. 갈리는 것은 무엇을 가리키느냐 수준이 아니라 범주 자체입니다. 데이터베이스 자리는 질의입니다. 화면 자리는 객체입니다. 배열 자리는 메모리 참조입니다. 웹 프레임워크 자리는 그 안에서 함수와 템플릿으로 다시 갈립니다. 어느 쪽이 원래 뜻인지는 이 문서들이 적지 않습니다. 그러니 맥락 이름을 먼저 대야 뜻이 섭니다.

맥락별 뜻

관계형 데이터베이스

PostgreSQL 문서는 CREATE VIEW 가 질의의 뷰를 정의한다고 적습니다. 뷰는 물리적으로 구체화되지 않습니다. 질의가 뷰를 참조할 때마다 저장해 둔 질의가 다시 실행됩니다. CREATE OR REPLACE VIEW 도 이와 비슷합니다. 다만 같은 이름의 뷰가 이미 있으면 그것을 대체한다고 적습니다.

sequenceDiagram
    participant 클라이언트
    participant 뷰
    participant 테이블
    클라이언트->>뷰: 뷰를 참조하는 질의
    뷰->>테이블: 저장해 둔 질의를 다시 실행
    테이블-->>뷰: 질의 결과
    뷰-->>클라이언트: 질의 결과

같은 제품의 튜토리얼은 이것을 쓰는 쪽에서 다시 적습니다. 질의 위에 뷰를 만들면 그 질의에 이름이 붙습니다. 그 이름을 보통 테이블처럼 참조할 수 있습니다. 튜토리얼은 뷰가 테이블 구조의 세부를 일관된 인터페이스 뒤로 감싸게 해 준다고 적습니다. 애플리케이션이 자라면서 그 구조가 바뀔 수 있기 때문이라고 적습니다. 그리고 실제 테이블을 쓸 수 있는 거의 모든 자리에 뷰를 쓸 수 있다고 적습니다.

UI 툴킷

Android 문서는 View 클래스가 사용자 인터페이스 구성 요소의 기본 블록을 나타낸다고 적습니다. 뷰 하나는 화면에서 사각 영역을 차지합니다. 그 영역의 그리기와 이벤트 처리가 이 뷰의 책임입니다.

이 자리의 뷰는 위계의 밑바닥입니다. 문서는 View 가 위젯의 기반 클래스라고 적습니다. 위젯은 버튼이나 텍스트 필드 같은 상호작용하는 구성 요소를 만드는 데 쓰인다고 적습니다. 하위 클래스인 ViewGroup 은 레이아웃의 기반 클래스입니다. 레이아웃은 다른 뷰나 다른 ViewGroup 을 담는 보이지 않는 컨테이너라고 적습니다. 레이아웃이 담은 것들의 배치 속성도 정의한다고 적습니다.

배열과 버퍼

NumPy 문서는 데이터를 복사해 옮기지 않고 내부 데이터 버퍼에 바로 접근하는 방법이 있다고 적습니다. 그것이 뷰입니다. stride 와 dtype 같은 메타데이터만 바꾸면 데이터 버퍼를 건드리지 않고도 배열을 다르게 볼 수 있다고 적습니다. 그렇게 만든 새 배열을 뷰라고 부릅니다. 데이터 버퍼는 그대로이므로 뷰에 가한 변경이 원본에도 나타납니다. ndarray.view 메서드로 뷰를 강제할 수도 있다고 적습니다.

원본 배열에서 오프셋과 stride 로 원소를 가리킬 수 있으면 뷰가 만들어집니다. 그래서 기본 인덱싱은 언제나 뷰를 만든다고 문서는 적습니다. 문서가 든 실물은 이렇습니다.

x = np.arange(10)
y = x[1:3]        # 뷰가 만들어진다
x[1:3] = [10, 11]
y                 # array([10, 11])

x 를 고쳤는데 y 가 따라 바뀝니다. 복사였다면 안 바뀝니다.

웹 프레임워크

Django 문서는 뷰 함수를 웹 요청을 받아 웹 응답을 돌려주는 파이썬 함수라고 적습니다. 짧게 뷰라고 부른다고 적습니다. 그 응답은 웹 페이지의 HTML(HyperText Markup Language) 내용일 수도 있습니다. 리다이렉트나 404 오류일 수도 있습니다. XML(eXtensible Markup Language) 문서나 이미지일 수도 있습니다. 문서는 사실상 무엇이든 될 수 있다고 적습니다. 그 응답을 돌려주는 데 필요한 임의의 로직은 뷰 자신이 담는다고 적습니다.

같은 낱말이 다른 프레임워크에서는 템플릿을 가리킵니다. Ruby on Rails 가이드는 Action View 가 MVC 의 V 라고 적습니다. Action Controller 가 모델 계층과 소통해 데이터를 가져옵니다. 그 데이터로 웹 요청에 대한 응답 본문을 그리는 것이 Action View 입니다. 기본적으로 Action View 템플릿은 ERB(Embedded Ruby, 내장 루비)로 작성된다고 적습니다. 그 템플릿을 그냥 뷰라고 부르기도 한다고 적습니다.

Microsoft 문서도 같은 쪽입니다. MVC 패턴에서 뷰는 앱의 데이터 표현과 사용자 상호작용을 다룬다고 적습니다. 뷰는 Razor 마크업이 박힌 HTML 템플릿이라고 적습니다. ASP.NET Core MVC 에서 뷰는 Razor 마크업 안에서 C# 을 쓰는 .cshtml 파일이라고 적습니다.

그러니 "웹에서 뷰" 라는 말만으로는 요청을 받는 함수인지 응답을 그리는 템플릿인지 정해지지 않습니다. Django 자신이 이 어긋남을 문서에 적어 두었습니다. Django FAQ(Frequently Asked Questions, 자주 묻는 질문)는 자기 해석에서 뷰가 사용자에게 제시되는 데이터를 기술한다고 적습니다. 데이터가 어떻게 보이는지가 아니라 어느 데이터가 제시되는지라고 적습니다. 그래서 특정 URL(Uniform Resource Locator, 웹 주소)에 대한 파이썬 콜백 함수가 뷰라고 적습니다. 뷰는 보통 템플릿에 위임한다고 적습니다. 데이터가 어떻게 제시되는지는 그 템플릿이 기술한다고 적습니다. 컨트롤러 자리는 프레임워크 자신일 것이라고 적습니다. 요청을 URL 설정에 따라 알맞은 뷰로 보내는 기계 장치가 그것입니다. 약어를 원한다면 Django 는 MTV(Model-Template-View, 모델-템플릿-뷰) 프레임워크라고 부를 수 있다고 적습니다.

경계

구체화 뷰

CREATE MATERIALIZED VIEW 로 만든 구체화 뷰도 뷰인가. 이름이 같은 제품 안에서 갈립니다. PostgreSQL 이 정의한 뷰의 성질을 그대로 대면 아닙니다.

가르는 선은 질의가 언제 도느냐입니다. 뷰는 물리적으로 구체화되지 않고 참조될 때마다 질의가 다시 돕니다. 구체화 뷰는 반대입니다. 문서는 명령이 내려지는 시점에 질의가 실행되어 뷰를 채운다고 적습니다. WITH NO DATA 를 쓰면 그렇지 않다고 덧붙입니다. 그리고 나중에 REFRESH MATERIALIZED VIEW 로 갱신될 수 있다고 적습니다. 문서는 구체화 뷰가 CREATE TABLE AS 와 비슷하다고 적습니다. 다만 나중에 요청에 따라 갱신할 수 있도록 뷰를 초기화하는 데 쓴 질의를 기억해 둔다는 점이 다르다고 적습니다.

문서는 한 문장을 더 답니다. 구체화 뷰는 테이블과 같은 성질을 많이 가진다고 적습니다. 다만 임시 구체화 뷰는 지원되지 않는다고 적습니다. 같은 제품이 문법을 따로 두고 저장 방식을 반대로 두었습니다. 그래서 뷰 이야기를 하다 구체화 뷰가 나오면 그것은 같은 것의 한 종류가 아니라 다른 명령입니다.

관련 항목

관계형 데이터베이스에서 이것을 호출·실행하는 명령

CREATE VIEW · CREATE MATERIALIZED VIEW · REFRESH MATERIALIZED VIEW · CREATE TABLE AS

관계형 데이터베이스에서 뷰 자리를 두고 겨루는 저장 방식

테이블 · 임시 테이블 · 구체화 뷰

관계형 데이터베이스에서 뷰를 이루는 구성 요소

질의 · 기반 테이블 · 인터페이스

UI 툴킷에서 View 클래스를 이루는 요소

위젯 · ViewGroup · 레이아웃 · 컨테이너 · 이벤트 처리 · 그리기

배열과 버퍼에서 뷰를 규정하는 개념

ndarray · 데이터 버퍼 · stride · dtype · 메타데이터 · 기본 인덱싱 · 슬라이스 · 참조 · 복사

웹 프레임워크에서 뷰 함수가 다루는 요청과 응답

웹 요청 · 웹 응답 · 리다이렉트 · HTTP 404 · 콜백 함수

웹 프레임워크에서 뷰(템플릿)를 이루는 기술

템플릿 · ERB · Razor · HTML · XML

웹 프레임워크에서 이것에 관여하는 역할·참여자

컨트롤러 · 모델 · URL 설정

뷰의 각 뜻이 속하는 상위 분류

데이터베이스 · 관계형 데이터베이스 · 사용자 인터페이스 · MVC · MTV

각 맥락에서 이 뜻을 실제로 구현·채택한 제품

PostgreSQL · NumPy · Django · Ruby on Rails · ASP.NET Core MVC

뷰의 각 뜻을 문서로 관리·소유하는 주체

Android Developers · Microsoft · Rails