141. 인라인 뷰 (Inline View) - FROM 절에 사용된 서브쿼리, 동적으로 생성되는 뷰

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

본질: 인라인 뷰(Inline View)는 SELECT 쿼리문의 FROM 절 내부에 괄호 ( )를 씌워 작성한 서브쿼리로, 데이터베이스 디스크에 저장되지 않고 쿼리가 실행되는 그 찰나의 순간에만 메모리 상에 존재하는 1회용 가상 테이블이다.

가치: 복잡한 대용량 테이블을 미리 GROUP BY나 WHERE로 작게 압축(데이터량 축소)한 뒤에 다른 테이블과 조인(Join)하게 만듦으로써, 무식한 카테시안 곱(Cartesian Product) 폭발을 막고 쿼리 성능을 비약적으로 끌어올리는 튜닝의 핵심 도구다.

융합: 작성의 편의성 때문에 중첩(인라인 뷰 안의 인라인 뷰)을 남발하면 옵티마이저가 뷰 병합(View Merging)에 실패하여 디스크 임시 파일(Temp) 부하를 일으키므로, 최신 SQL 스펙인 WITH 절(CTE)로 치환하여 모듈화하는 아키텍처 설계가 대세가 되었다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 데이터베이스 쿼리에서 데이터를 꺼내올 원천(Source)을 명시하는 곳이 FROM 절이다. 일반적으로 이 자리에는 사원, 부서 같은 튼튼한 물리적 테이블이 온다. 하지만 이 자리에 (SELECT * FROM 사원 WHERE 급여 > 5000) 처럼 또 다른 쿼리(서브쿼리)를 통째로 쑤셔 넣고 마치 하나의 테이블인 척 껍데기(AS 가칭)를 씌우는 기법이 인라인 뷰(Inline View)다.
필요성: 수천만 건이 쌓여있는 '주문' 테이블과 10만 건의 '고객' 테이블을 무턱대고 조인(Join)하면 데이터베이스 엔진은 피를 토한다. 만약 '어제 주문한 건'만 필요하다면, 전체 테이블을 조인하기 전에 '주문' 테이블에서 어제 데이터만 살짝 퍼내어 작은 그릇(가짜 테이블)에 담아둔 뒤, 그 작은 그릇과 '고객' 테이블을 조인하는 것이 압도적으로 빠르다. 이처럼 **"본격적인 연산을 시작하기 전에 데이터를 내 입맛대로 가공해 둔 일회용 맞춤형 도마"**가 절실하게 필요했다.
💡 비유: 일반 FROM 물리테이블이 마트에서 사 온 커다란 수박(통데이터)을 냉장고에서 꺼내 통째로 식탁(조인)에 올리는 것이라면, FROM (인라인 뷰)는 수박을 냉장고 안에서 미리 깍둑썰기하고 씨까지 싹 발라낸 뒤, 먹기 좋은 락앤락 통(임시 메모리)에 담아서 식탁에 올리는 것과 같습니다. 요리(메인 쿼리)하기가 훨씬 편하고 빨라집니다.
등장 배경:
1. 물리적 View의 관리 한계: 특정 목적의 쿼리를 재사용하기 위해 DB에 실제 CREATE VIEW로 영구적인 뷰를 만들 수 있으나, 일회성 쿼리를 위해 매번 DB 객체를 생성하고 지우는 것은 스키마 오염과 관리 비용 낭비를 초래했다.
2. 조인 최적화의 한계: RDBMS 초창기, 조인을 걸면 일단 테이블 전체를 다 스캔하려는 무식한 옵티마이저의 한계를 사람이 직접 통제하여 스캔 범위를 줄여주기 위한 수동 튜닝 기법으로 각광받았다.
3. SQL 표준화 지원: 데이터베이스 엔진 메모리(RAM) 용량이 커지면서, 쿼리 파싱 도중 메모리에 임시 집합을 자유자재로 올릴 수 있는 인프라가 갖춰지며 ANSI SQL 표준 핵심 문법으로 자리 잡았다.

┌─────────────────────────────────────────────────────────────┐
│          물리적 테이블 Join vs 인라인 뷰(Inline View) 활용 구조        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [ ❌ 비효율적인 일반 Join 아키텍처 ]                             │
│ SELECT 고객.이름, 주문.금액                                    │
│ FROM 고객 (10만건)                                            │
│ INNER JOIN 주문 (1000만건 전체가 조인 연산에 끌려들어감 💥)           │
│   ON 고객.고객ID = 주문.고객ID                                  │
│ WHERE 주문.일자 = '오늘' (조인이 끝난 거대한 덩어리에서 필터링)         │
│                                                             │
│ [ ✅ 인라인 뷰를 활용한 최적화 아키텍처 (Data Reduction) ]           │
│ SELECT 고객.이름, 오늘주문.금액                                 │
│ FROM 고객 (10만건)                                            │
│ INNER JOIN                                                  │
│   ( 🌟 인라인 뷰: 1000만건 중 오늘 데이터 5천건만 쏙 빼서 메모리 생성! ) │
│   ( SELECT 고객ID, 금액 FROM 주문 WHERE 일자 = '오늘' ) AS 오늘주문│
│   ON 고객.고객ID = 오늘주문.고객ID                              │
│                                                             │
│ 🌟 결과: 1000만 건과 10만 건을 억지로 부딪치게 하는 무식한 연산을 피하고,   │
│    미리 잘라낸 5천 건짜리 깃털 같은 임시 테이블을 조인시켜 DB CPU를 구원한다!│
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 인라인 뷰가 실무 튜닝에서 어떻게 마법을 부리는지 보여주는 핵심 원리다. DB 연산 비용 중 가장 무거운 것이 조인(Join)이다. 상단의 무식한 쿼리는 두 개의 거대한 산을 일단 합치고 나서 쓸모없는 돌을 부수는 방식이다. 하단의 인라인 뷰 쿼리는 거대한 주문 산에서 오늘 치 조약돌 5천 개만 주워 담은 작은 바구니(오늘주문)를 허공(메모리)에 뚝딱 만든 뒤, 그 가벼운 바구니를 고객 테이블과 조인시킨다. 조인에 들어가는 데이터의 모수(집합의 크기)를 사전에 극단적으로 줄여버리는(Data Reduction) 가장 우아한 아키텍처다.

📢 섹션 요약 비유: 수만 명의 학생이 모여있는 대운동장(물리 테이블)에서 1학년을 찾는 게 아닙니다. 인라인 뷰라는 마법의 메가폰으로 "1학년만 모인 임시 텐트(가상 테이블)로 집합!" 시켜놓고, 그 텐트 안에서만 출석 체크(조인)를 하는 아주 똑똑하고 빠른 선생님의 통제 방식입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

인라인 뷰의 문법적 철칙 (Alias 강제)

인라인 뷰는 허공에 뜨는 유령 데이터이기 때문에, 쿼리 엔진이 이를 다른 테이블과 섞어 쓰려면 반드시 **임시 이름표(Alias)**를 달아주어야 한다. (일부 DB는 강제, 오라클 등은 선택이지만 쓰는 것이 표준이다).

SELECT A.부서명, B.최고급여
FROM 부서 AS A
INNER JOIN (
    SELECT 부서ID, MAX(급여) AS 최고급여 
    FROM 사원 
    GROUP BY 부서ID
) AS B  ◀── (필수!) 이 괄호 덩어리를 'B'라는 가짜 테이블로 부르겠다 명시!
ON A.부서ID = B.부서ID;

내부 메모리 동작 원리 (Derived Table): 이 괄호 안의 쿼리가 파싱 되면, DB 엔진은 메모리(RAM)의 Temp 영역에 부서ID, 최고급여 컬럼 딱 2개만 가진 가상의 테이블(Derived Table, 파생 테이블)을 실제로 하나 그린다. 메인 쿼리는 하드디스크를 보지 않고, RAM에 떠 있는 이 'B'라는 임시 테이블을 쳐다보며 고속으로 조인을 수행한다. 메인 쿼리 실행이 끝나는 즉시 메모리 속 'B' 테이블은 가비지 컬렉터에 의해 흔적도 없이 삭제된다.

옵티마이저의 신비: 뷰 병합 (View Merging)

개발자가 데이터를 줄이기 위해 아무리 인라인 뷰를 정성스럽게 짜놔도, CBO(비용 기반 옵티마이저)라는 DB의 천재 뇌세포는 가끔 이걸 무시하고 멋대로 쿼리를 뜯어고친다.

뷰 병합 (View Merging):
- 개발자가 짠 인라인 뷰가 굳이 메모리에 가짜 테이블을 띄울 만큼 효율적이지 않고, 그냥 본 쿼리랑 싹 다 합쳐서 한 방에 조인으로 풀어버리는 게 더 빠르다고 판단되면, 옵티마이저는 괄호를 찢어발겨 인라인 뷰를 메인 쿼리와 한 덩어리로 통째로 병합해 버린다.
뷰 비병합 (View No Merging):
- 반대로, 인라인 뷰 안쪽에 GROUP BY, DISTINCT, LIMIT/ROWNUM 같이 집합을 완전히 새롭게 뭉쳐버리는 무거운 연산이 들어있으면, 옵티마이저는 괄호를 찢지 못하고(불가 조건) 얌전히 메모리에 임시 테이블을 구체화(Materialization)하여 띄운다.

📢 섹션 요약 비유: 내가 요리 재료를 락앤락 통(인라인 뷰)에 예쁘게 소분해 놨는데, 수석 셰프(옵티마이저)가 쓱 보더니 "통에 담을 시간에 그냥 다 같이 큰 솥에 볶아버리는 게 더 빠르다!"며 통을 부어버리는 현상이 뷰 병합(Merging)입니다. 하지만 내가 재료를 믹서기로 갈아버렸다면(GROUP BY) 셰프도 어쩔 수 없이 그 믹서기 통 결과를 그대로 써야 합니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: 스칼라 서브쿼리(SELECT 절) vs 인라인 뷰(FROM 절)

같은 괄호지만 어디에 배치되느냐에 따라 DB 시스템의 목줄을 쥐고 흔드는 파급력이 완전히 다르다.

항목	스칼라 서브쿼리 (SELECT 절)	인라인 뷰 (FROM 절)
리턴 형태	딱 1개의 행(Row), 1개의 열(Column) 값	다수의 행(Row), 다수의 열(Column) 테이블 형태
작동 원리	메인 쿼리 결과가 10만 줄이면 괄호가 10만 번 반복해서 함수처럼 실행됨 (스칼라 캐싱이 안 먹히면 지옥)	메인 쿼리 돌기 전에 딱 1번만 실행되어 메모리에 큰 집합(테이블) 하나를 올려두고 대기함
퍼포먼스 병목	반복 연산으로 인한 CPU 사용률 폭발 (Context Switch)	과도하게 큰 데이터 조회 시 RAM 부족으로 하드디스크 디스크 I/O (Temp Tablespace) 폭발
최적화 튜닝	가능하면 인라인 뷰 조인으로 뜯어고치는 것이 정석	서브쿼리 내 필터 조건을 빡세게 주어 메모리 팽창 방지

성능 튜닝의 대원칙은 "반복적으로 디비를 찌르는 행위(스칼라 서브쿼리의 N번 반복)를 없애고, 큰 덩어리를 한 번에 묶어서 처리(인라인 뷰 해시 조인)하는 집합적 사고"로 전환하는 것이다.

과목 융합 관점

운영체제 (OS) 및 인프라: 인라인 뷰가 뱉어내는 데이터 집합이 수십만 건을 넘어가서 MySQL의 tmp_table_size나 max_heap_table_size 메모리 변수값을 초과하면, OS는 이를 RAM에 두지 못하고 하드디스크의 임시 폴더(Disk Temp)에 물리적으로 파일을 써버린다. RAM 속도의 수백 배 느린 디스크 I/O 병목이 발생하며 디스크 100% 장애가 발생한다. 인라인 뷰 안에서는 반드시 인덱스를 타는 철저한 WHERE 문으로 데이터를 극단적으로 잘라내야 한다.
아키텍처 및 페이징(Pagination): 웹 게시판에서 페이지 번호를 넘길 때 쓰는 LIMIT 쿼리는 인라인 뷰 아키텍처의 꽃이다. 오라클의 경우 SELECT * FROM (SELECT ROWNUM rnum, A.* FROM (SELECT * FROM 게시판 ORDER BY 날짜 DESC) A WHERE ROWNUM <= 20) WHERE rnum >= 11; 처럼 인라인 뷰를 3중 껍질로 싸서 정렬과 컷팅을 분리하는 교과서적인 페이징 쿼리 구조를 강제한다.
📢 섹션 요약 비유: 스칼라 쿼리가 도장 장인이 10만 개의 서류에 도장을 일일이 하나씩 쾅쾅 찍느라 팔(CPU)이 빠지는 작업이라면, 인라인 뷰 쿼리는 큰 롤러 스탬프를 하나 판 다음에 10만 장을 한 번에 싹 밀어버려 종이 더미(메모리)만 잘 관리하면 되는 대량 인쇄 작업입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — TOP-N 쿼리 추출 시 인라인 뷰의 파괴력: 쇼핑몰 메인 화면에 "각 카테고리(가전, 의류, 식품)별로 가장 비싼 상품 딱 3개씩만 뽑아와라"라는 복잡한 요건이 떨어졌다. 초보 개발자가 Java 서버로 카테고리 10개의 전체 리스트 수십만 건을 전부 긁어와서 서버 램에 띄우고 List 소팅을 하다 OutOfMemory(OOM)로 서버를 죽였다.
- 판단: 이런 행(Row) 간의 순위를 매겨 자르는 연산은 DB 엔진이 세상에서 제일 잘하는 일이다. 아키텍트는 쿼리의 FROM 절에 인라인 뷰를 열고, 윈도우 함수인 ROW_NUMBER() OVER (PARTITION BY 카테고리 ORDER BY 가격 DESC)를 사용하여 임시 가상 테이블에 1, 2, 3등 순위 뱃지를 쫙 붙여버린다. 그리고 바깥 메인 쿼리에서 WHERE 순위 <= 3으로 무 썰듯 깔끔하게 썰어버리면, DB에서 군더더기 없는 완벽한 30건의 데이터만 Java 서버로 전송되어 네트워크 대역폭과 서버 램을 완벽히 방어한다.
시나리오 — 뷰(View) 안의 뷰 (중첩 인라인 뷰) 지옥으로 인한 디스크 마비: 분석가가 쿼리를 짤 때 귀찮다는 이유로 FROM (SELECT ... FROM (SELECT ... FROM (SELECT...))) 형태로 인라인 뷰를 10단계나 양파 껍질처럼 감싸서 작성했다. 이 거대한 괴물 쿼리를 실행하자 DB 엔진의 옵티마이저가 뷰 병합(Merging) 해석을 포기해 버렸다. 결과적으로 매 껍질을 깔 때마다 10GB짜리 임시 데이터가 하드디스크에 써졌다가 다음 껍질로 넘어가는 미친 디스크 스와핑(Swapping)이 일어나며 전체 사내 DB 응답이 멈췄다.
- 판단: 인라인 뷰는 가상의 메모리 테이블을 만든다는 달콤한 마약이다. 뎁스(Depth)가 2~3단계를 넘어가면 옵티마이저가 쿼리 실행 계획을 최적화할 길을 잃고 풀스캔(Full Scan)의 나락으로 빠진다. 실무에서는 이럴 때 쿼리를 억지로 1개로 합치지 말고, 아예 임시 물리 테이블(Global Temporary Table)에 중간 결과를 한 번 박아놓고 인덱스를 태워 조인하거나, 가독성을 위해 최신 문법인 WITH 절(CTE)로 뜯어고쳐 블록화시켜야 시스템 붕괴를 막을 수 있다.

  ┌─────────────────────────────────────────────────────────────┐
  │        실무 아키텍처: 인라인 뷰 지옥을 탈출하는 모던 SQL (CTE, WITH 절)│
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [❌ 구시대의 악몽: 양파 껍질 인라인 뷰 (가독성 및 튜닝 최악)]         │
  │ SELECT 최종.*                                                │
  │ FROM (                                                      │
  │    SELECT 중간.*, 부서.이름                                   │
  │    FROM (                                                   │
  │        SELECT 사원ID, SUM(급여) AS 총급여                     │
  │        FROM 사원 GROUP BY 사원ID                              │
  │    ) AS 중간                                                 │
  │    INNER JOIN 부서 ON 중간.부서ID = 부서.부서ID                 │
  │ ) AS 최종                                                    │
  │ WHERE 최종.총급여 > 5000;                                     │
  │                                                             │
  │ [✅ 모던 아키텍처의 정답: WITH 절 (Common Table Expression)]       │
  │                                                             │
  │ -- 1. 첫 번째 임시 블록을 맨 위에 깔끔하게 선언!                  │
  │ WITH 사원급여_블록 AS (                                        │
  │    SELECT 사원ID, 부서ID, SUM(급여) AS 총급여                 │
  │    FROM 사원 GROUP BY 사원ID                                  │
  │ ),                                                          │
  │ -- 2. 두 번째 블록에서 첫 번째 블록을 조립!                      │
  │ 부서조인_블록 AS (                                            │
  │    SELECT S.*, D.이름 AS 부서이름                             │
  │    FROM 사원급여_블록 S INNER JOIN 부서 D ON S.부서ID = D.부서ID │
  │ )                                                           │
  │ -- 3. 최종 메인 쿼리는 위에서 만든 블록을 테이블처럼 우아하게 호출!  │
  │ SELECT * FROM 부서조인_블록                                   │
  │ WHERE 총급여 > 5000;                                          │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 인라인 뷰는 "바깥쪽에서부터 껍질을 까며 안쪽으로 읽어야 하는" 인간의 사고 흐름(Top-down)에 극도로 역행하는 구조다. 안쪽에서부터 무슨 짓을 했는지 추적하며 위로 올라와야 코드가 읽힌다. 최근 10년간 SQL 패러다임을 바꾼 위대한 발명이 상단에 미리 블록을 선언해 두는 **WITH 절 (CTE)**이다. 이는 프로그래밍에서 복잡한 로직을 변수 1, 변수 2로 할당해 두고 메인 함수에서 깔끔하게 변수끼리 더하는(위에서 아래로 읽히는) 객체지향적 코드 캡슐화의 미학을 데이터베이스 쿼리 언어에 이식해 준 완벽한 진화다.

도입 체크리스트

기술적: 인라인 뷰 안에서 SELECT * 를 쳐서 테이블의 모든 50개 컬럼을 죄다 가상 테이블 메모리로 멱살 잡고 끌고 올라오지 않았는가? 뷰가 쪼그라들지 못하고 뚱뚱해져서 조인 시 메모리 한계를 박살 내는 주범이므로, 뷰 안에서는 반드시 밖에서 쓸 2~3개 컬럼 이름만 명확히 박아야 한다.
운영·보안적: 뷰 병합(View Merging)을 옵티마이저가 실패하여 심각한 지연이 생길 때, 강제성 힌트(Oracle의 /*+ MERGE(v) */ 또는 MySQL 최적화 변수)를 주입하여 쿼리 플랜을 강제로 펴버리는 DBA 레벨의 통제 수단이 준비되어 있는가?

안티패턴

필터링 조건의 인라인 뷰 바깥 배치 (Late Filtering): 인라인 뷰 안쪽에서는 SELECT * FROM 로그테이블 로 10억 건을 죄다 메모리에 올려서 거대한 뷰를 뻥 튀겨놓고, 정작 바깥 메인 쿼리의 WHERE 절에 와서야 날짜 = '오늘' 로 뒤늦게 깎아내는 무식한 행위. (물론 똑똑한 옵티마이저가 조건 절 밀어넣기(Predicate Pushing) 기술로 알아서 안으로 조건을 밀어 넣어 살려주기도 하지만), 옵티마이저가 이 마법을 실패하는 순간 서버는 디스크를 토해내며 즉사한다. 조건 필터링은 인라인 뷰 안쪽 깊숙한 곳에서 최대한 빨리 베어내서 모수(Data Set)를 깃털처럼 가볍게 만드는 것이 생존 철칙이다.
📢 섹션 요약 비유: 뷰 바깥에서 필터링을 하는 건 귤 1만 개를 힘들게 지게에 지고 산 정상(메인 쿼리)까지 다 올라가서 썩은 귤 9,900개를 갖다 버리는 미련한 짓입니다. 산 밑바닥(인라인 뷰 안쪽)에서 미리 썩은 걸 다 버리고 싱싱한 100개만 배낭에 가볍게 넣고 올라가는 것이 똑똑한 필터링 푸시다운(Push-down) 전략입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	통 테이블 무지성 조인 (Legacy)	정밀한 인라인 뷰 + CTE 최적화	개선 효과
정량	수천만 건 x 수천만 건 카테시안 조인	1천 건 압축 뷰 x 테이블 고속 조인	대용량 OLAP 통계 쿼리 실행 시간 10배~100배 단축
정량	무거운 뷰 생성으로 임시 디스크 쓰기	필요한 컬럼 2개만 선별한 초경량 뷰	데이터베이스 Temp 스페이스 I/O 스와핑 95% 억제
정성	양파 껍질 구조로 인수인계 및 디버깅 불능	WITH 절을 통한 블록 모듈화 달성	수천 줄짜리 SQL 코드의 가독성 혁신 및 협업 생산성 폭발

미래 전망

스트리밍 데이터와 실시간 뷰의 융합: 과거의 뷰가 정적인 RDBMS에 묶여있었다면, 이제는 Apache Flink나 KSQL 같은 이벤트 스트리밍 플랫폼 상에서 끊임없이 흘러들어오는 무한한 카프카(Kafka) 로그 데이터 위로 '실시간 윈도우 인라인 뷰'를 띄워, 10초 단위로 쪼개진 집계 결과를 메모리에서 1밀리초 만에 쳐내는 스트리밍 SQL의 형태로 진화하고 있다.
물리적 한계를 부수는 데이터 웨어하우스: Snowflake, BigQuery 등 현대의 MPP(대규모 병렬 처리) 클라우드 DB들은 수십 겹의 인라인 뷰를 쳐도 무한에 가까운 클라우드 클러스터 RAM에 집합을 분산시켜 올려버리기 때문에, 과거 온프레미스 DB 시절처럼 메모리 뷰 생성에 벌벌 떨지 않고 분석가들이 데이터 프레임(DataFrame) 주무르듯 미친 듯이 뷰를 겹쳐 짜는 패러다임이 보편화되었다.

참고 표준

ANSI SQL:1999 (SQL3): FROM 절 내의 파생 테이블(Derived Table / Inline View) 명세 및 AS 키워드 강제 표준 확립
ANSI SQL:2003: 인라인 뷰의 가독성 한계를 혁명적으로 돌파한 모던 SQL의 상징 WITH 절(Common Table Expression) 최초 도입

"데이터를 제어하려면 집합(Set)을 지배하라." 인라인 뷰는 디스크라는 딱딱하고 무거운 영구 저장소의 굴레에서 벗어나, 개발자가 상상하는 어떤 형태의 데이터 덩어리(집합)라도 메모리 허공에 찰나의 순간에 빚어내어 휘두를 수 있게 해주는 관계 대수의 궁극기다. 비록 그 괄호의 껍질이 너무 두꺼워져 후배 개발자들의 원성을 사기도 했으나, 이 '조인하기 전에 모수를 깎아낸다(Data Reduction)'는 튜닝의 영원한 대원칙을 하드코딩으로 강제할 수 있는 권한을 주었다는 점에서 인라인 뷰는 DB 튜닝 역사상 가장 위대한 검(劍)으로 평가받아 마땅하다.

📢 섹션 요약 비유: 인라인 뷰는 마술사가 허공에서 1초 만에 만들어냈다가 박수를 치면 펑 하고 연기처럼 사라지는 마법의 빈 상자입니다. 이 상자 덕분에 무거운 쇠구슬 1만 개(디스크 원본)를 직접 들고 낑낑댈 필요 없이, 마법 상자(메모리 뷰) 안에서 깃털 10개로 바꾼 뒤에 사뿐하게 저글링(조인)을 할 수 있게 되었습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
Subquery (서브쿼리)	인라인 뷰의 큰 줄기가 되는 상위 개념. 괄호를 열어 쿼리 안에 쿼리를 심는 모든 기법을 통칭하는 어머니다.
CTE (Common Table Expression, WITH 절)	양파 껍질처럼 파고드는 인라인 뷰의 가독성 지옥을 타파하기 위해, 코드 최상단에 임시 뷰를 깔끔한 블록 변수로 선언해 두는 최신 SQL 문법의 구원자다.
View Merging (뷰 병합)	개발자가 인라인 뷰 괄호를 쳐서 벽을 세워놔도, 똑똑한 옵티마이저가 "이거 그냥 벽 허물고 싹 다 한 번에 조인 쳐버리는 게 더 빠름"이라며 괄호를 찢어발기는 DB 내부 최적화 마법이다.
Predicate Pushing (조건 밀어넣기)	바깥쪽 메인 쿼리에 달린 `WHERE` 필터 조건을, DB 엔진이 알아서 인라인 뷰 안쪽 깊숙이 밀어 넣어 데이터 스캔 모수를 최초부터 싹둑 잘라주는 극한의 성능 최적화 기술이다.
Derived Table (파생 테이블)	인라인 뷰가 실행되는 찰나의 순간, DB 서버의 메모리(또는 디스크 Temp 공간)에 실제로 만들어졌다 사라지는 가상의 테이블을 부르는 엔진 아키텍처 용어다.

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

마트에서 과일 샐러드를 만들려고 커다란 통수박을 샀어요. 수박 전체를 요리상 위(조인)에 올리면 자리가 좁아서 요리할 수가 없겠죠?
인라인 뷰는 냉장고 속에서 수박을 깍둑썰기하고 씨를 다 빼서 딱 먹을 만큼만 **작은 플라스틱 통(가짜 테이블)**에 담아내는 마법의 레시피예요.
이 작고 가벼운 플라스틱 통만 식탁에 올리면, 사과나 바나나(다른 테이블)랑 섞어서 요리하기가 엄~청나게 빠르고 쉬워지고 요리가 끝나면 통은 뿅 하고 사라진답니다!