# 2026년 Vue 3 성능의 모든 것: Vapor Mode, Alien Signals 그리고 면접 질문

> Vue 3.6 Vapor Mode는 가상 DOM을 제거하고 직접 DOM 조작을 구현합니다. 벤치마크 결과, Alien Signals 반응성 시스템, 마이그레이션 가이드, 면접 대비 질문까지 상세 분석합니다.

- Published: 2026-06-02
- Updated: 2026-06-02
- Author: SharpSkill
- Tags: vue, vue-3, vapor-mode, performance, virtual-dom, alien-signals
- Reading time: 12 min

---

Vue 3.6의 Vapor Mode는 Vue 2에서 가상 DOM을 도입한 이후 가장 중요한 렌더링 아키텍처 변화입니다. Single File Components를 명령형 DOM 조작으로 직접 컴파일함으로써, Vapor Mode는 수년간 Vue의 렌더링 파이프라인을 정의해 온 비교(diffing) 오버헤드를 완전히 제거합니다. 여기에 Alien Signals 기반의 반응성 시스템 전면 재작성이 결합되어, Vue 3.6은 Solid.js 및 Svelte 5와 벤치마크에서 동등한 성능에 도달했습니다. 개발자가 새로운 API를 학습할 필요는 없습니다.

> **Vapor Mode 핵심 요약**
>
> Vapor Mode는 Vue 3.6의 옵트인 방식 컴파일 전략으로, 가상 DOM을 완전히 우회합니다. Vapor Mode로 컴파일된 컴포넌트는 각 반응형 의존성을 영향을 미치는 DOM 노드에 직접 연결하여, 트리 순회 없이 정밀한 업데이트를 수행합니다. 활성화는 단일 속성으로 완료됩니다: `<script setup vapor>`.

## Vue의 가상 DOM 작동 원리 — 왜 병목이 되었는가

가상 DOM(VDOM) 패턴은 React에 의해 대중화되었고 Vue 2에서 채택되었습니다. 실제 DOM 트리의 경량 JavaScript 표현을 생성하는 방식입니다. 상태가 변경될 때마다 Vue는 새로운 VDOM 트리를 생성하고, 이전 트리와 비교(diff)한 후, 변경된 노드만 실제 DOM에 패치합니다.

이 접근 방식은 대부분의 애플리케이션에서 충분히 잘 작동합니다. 비교 알고리즘은 O(n) 시간에 실행되며, Vue의 컴파일러는 정적 서브트리를 비교 경로에서 제외하는 최적화를 수행합니다. 그러나 특정 시나리오에서는 오버헤드가 누적됩니다.

- **대규모 리스트**: 수백 개의 행이 있는 리스트는 업데이트마다 전체 서브트리 비교가 실행됩니다
- **빈번한 상태 변경**: 애니메이션이나 실시간 데이터에서 VDOM 생성과 폐기가 가비지 컬렉터 부하를 증가시킵니다
- **깊은 컴포넌트 트리**: 트리 순회와 패치 생성 비용이 증가합니다

Vue 3의 템플릿 컴파일러는 정적 호이스팅, 패치 플래그, 블록 트리 등 여러 VDOM 최적화를 도입하여 불필요한 작업을 줄였습니다. 하지만 근본적인 아키텍처는 여전히 렌더링 사이클마다 JavaScript 객체의 생성, 비교, 폐기를 필요로 했습니다.

## Vue 3.6 Vapor Mode: 가상 DOM의 컴파일 제거

Vapor Mode는 근본적으로 다른 접근 방식을 취합니다. 템플릿을 VDOM 노드를 반환하는 렌더 함수로 컴파일하는 대신, Vapor 컴파일러는 DOM 요소를 직접 생성하고 업데이트하는 코드를 출력합니다. 각 반응형 바인딩은 특정 DOM 조작에 매핑되며, 중간 표현이 필요하지 않습니다.

표준 Vue 컴포넌트가 각 모드에서 어떻게 컴파일되는지 살펴보겠습니다.

```vue
<!-- Counter.vue -->
<script setup vapor>
import { ref } from 'vue'

const count = ref(0)
const increment = () => count.value++
</script>

<template>
  <button @click="increment">
    Count: {{ count }}
  </button>
</template>
```

기존 VDOM 모드에서 이 템플릿은 가상 노드 트리를 반환하는 렌더 함수로 컴파일됩니다. 클릭할 때마다 Vue는 새로운 VDOM 트리를 생성하고, 이전 트리와 비교하여 텍스트 내용 변경을 감지한 후 실제 DOM에 패치합니다.

Vapor Mode에서는 컴파일러가 다음과 유사한 코드를 생성합니다.

```javascript
// Vapor 컴파일 출력 (간략화)
const button = document.createElement('button')
const text = document.createTextNode('Count: 0')
button.appendChild(text)

// 직접 바인딩: 반응형 소스 -> DOM 조작
effect(() => {
  text.nodeValue = `Count: ${count.value}`
})

button.addEventListener('click', increment)
```

반응형 이펙트가 `count`를 `text.nodeValue`에 직접 연결합니다. VDOM 생성도, 비교 처리도, 패치 적용도 발생하지 않습니다. 상태 변경은 정확히 하나의 DOM 조작만 트리거합니다.

### 프로젝트에서 Vapor Mode 활성화

Vapor Mode는 컴포넌트 단위로 작동합니다. 두 가지 통합 전략이 존재합니다.

```javascript
// vaporApp.js — 완전한 Vapor 애플리케이션 (VDOM 런타임 없음)
import { createVaporApp } from 'vue'
import App from './App.vue'

createVaporApp(App).mount('#app')
```

```javascript
// hybridApp.js — VDOM + Vapor 하이브리드 구성
import { createApp, vaporInteropPlugin } from 'vue'
import App from './App.vue'

createApp(App)
  .use(vaporInteropPlugin)
  .mount('#app')
```

하이브리드 접근 방식으로 점진적인 마이그레이션이 가능합니다. 데이터 테이블, 실시간 대시보드, 애니메이션이 많은 뷰 등 성능이 중요한 컴포넌트를 Vapor로 전환하면서, 나머지 애플리케이션은 표준 VDOM 런타임을 계속 사용할 수 있습니다. 두 가지 컴포넌트 타입은 동일한 컴포넌트 트리 내에서 공존합니다.

> **Vue 3.6에서 Vapor Mode의 제한 사항**
>
> Vapor Mode는 `<script setup>`을 사용한 Composition API가 필수입니다. Options API, `app.config.globalProperties`, `getCurrentInstance()`, 요소별 라이프사이클 이벤트(`@vue:mounted` 등)는 지원되지 않습니다. 커스텀 디렉티브는 바인딩 객체 대신 반응형 getter를 받는 다른 인터페이스를 사용합니다. Suspense는 VDOM 부모 컴포넌트 안에서 Vapor 컴포넌트를 감쌀 때는 작동하지만, 순수 Vapor 애플리케이션에서는 작동하지 않습니다.

## Alien Signals: Vue의 새로운 반응성 엔진

Vue 3.6은 Vapor Mode와 함께 또 하나의 중대한 변경 사항을 포함합니다. [Alien Signals](https://github.com/stackblitz/alien-signals) 라이브러리 기반의 `@vue/reactivity` 전면 재작성입니다. Johnson Chu가 개발한 Alien Signals는 메모리 할당과 계산 오버헤드를 동시에 줄이는 푸시-풀(push-pull) 반응성 알고리즘을 구현합니다.

푸시-풀 모델은 두 단계로 작동합니다.

1. **푸시 단계** — 시그널(반응형 소스)의 값이 변경되면, 모든 의존하는 computed 속성에 "dirty" 플래그를 전파합니다. 이 순회는 불리언 플래그를 뒤집는 것뿐이므로 비용이 낮습니다.
2. **풀 단계** — computed 속성이 읽힐 때 dirty 플래그를 확인합니다. dirty이면 재계산하고, 클린이면 캐시된 값을 즉시 반환합니다.

이 설계로 불필요한 재계산이 제거됩니다. Vue 3.5의 반응성 시스템에서는 3개의 시그널에 의존하는 computed 속성이 어떤 시그널이 변경되든 매번 재계산되었습니다(computed 결과가 동일하더라도). Alien Signals는 값이 실제로 읽히고, 최소 하나의 의존성이 변경된 경우에만 재계산을 수행합니다.

```typescript
// reactivityComparison.ts
import { ref, computed, watch } from 'vue'

const firstName = ref('Jane')
const lastName = ref('Doe')
const isActive = ref(true)

// 이 computed는 dirty이고 읽힐 때만 재계산됨
const displayName = computed(() => {
  return isActive.value
    ? `${firstName.value} ${lastName.value}`
    : 'Inactive User'
})

// isActive 변경으로 displayName이 dirty로 표시됨
// 하지만 무언가가 displayName.value를 읽을 때까지 계산은 실행되지 않음
isActive.value = false

// 이 시점에서 재계산이 발생함
console.log(displayName.value) // 'Inactive User'
```

내부 데이터 구조도 변경되었습니다. Alien Signals는 `Set` 기반 의존성 추적을 이중 연결 리스트로 교체하여, 반응형 의존성당 메모리를 줄이고 정리(cleanup) 시 순회 속도를 향상시켰습니다.

### 벤치마크 결과: Alien Signals 실측 성능

Vue 3.6 베타 벤치마크 수치는 Vue 3.5 대비 일관된 개선을 보여줍니다.

| 지표 | Vue 3.5 | Vue 3.6 (Alien Signals) | 개선율 |
|---|---|---|---|
| 반응형 ref당 메모리 | 기준값 | -14% | 메모리 할당 감소 |
| computed 재계산 | 기준값 | 평균 -20% | 불필요한 실행 감소 |
| 컴포넌트 마운트 (10만 개) | 약 300ms | 약 100ms | 3배 빠름 |
| First Contentful Paint | 기준값 | 일반적으로 0.7s | 프레임워크 오버헤드 감소 |
| 기본 번들 크기 | 약 16KB | 10KB 미만 | -37% |

이러한 개선 사항은 모든 Vue 3.6 애플리케이션에 자동으로 적용됩니다. 컴포넌트별 옵트인이 필요한 Vapor Mode와 달리, Alien Signals 반응성 시스템은 Vue 3.6의 기본값입니다.

## 실전 Vue 3 성능 최적화 기법

Vapor Mode와 Alien Signals는 프레임워크 수준의 오버헤드를 해결하지만, 애플리케이션 수준의 성능은 컴포넌트 구조에 달려 있습니다. 다음 기법들은 VDOM과 Vapor 컴포넌트 모두에 적용됩니다.

### 대규모 데이터 구조를 위한 Shallow Reactivity

깊은 반응성(deep reactivity)은 모든 중첩 속성을 Proxy로 래핑합니다. 대규모 데이터셋(API 응답, 설정 객체, 캐시된 상태)에서는 수천 개의 불필요한 Proxy 래퍼가 생성됩니다. `shallowRef`와 `shallowReactive`는 반응성을 최상위 참조로 제한합니다.

```typescript
// shallowReactivity.ts
import { shallowRef, triggerRef } from 'vue'

interface Product {
  id: number
  name: string
  variants: { sku: string; price: number }[]
}

// ref 자체만 반응형이며, 중첩 속성은 대상이 아님
const products = shallowRef<Product[]>([])

// 데이터 가져오기 — 새 배열을 할당하여 반응성 트리거
async function fetchProducts() {
  const response = await fetch('/api/products')
  products.value = await response.json() // 업데이트 트리거
}

// 중첩 데이터 변경 — 수동 트리거 필요
function updatePrice(productId: number, sku: string, newPrice: number) {
  const product = products.value.find(p => p.id === productId)
  const variant = product?.variants.find(v => v.sku === sku)
  if (variant) {
    variant.price = newPrice
    triggerRef(products) // 명시적 트리거 필요
  }
}
```

### v-memo 디렉티브를 활용한 고비용 리스트 렌더링 최적화

VDOM 컴포넌트에서 긴 리스트를 렌더링할 때, `v-memo`는 의존 값에 따라 서브트리 렌더링 결과를 캐시합니다. 의존성이 변경되지 않은 메모이제이션된 서브트리에 대해 VDOM은 비교 처리를 완전히 건너뜁니다.

```vue
<!-- ProductGrid.vue -->
<script setup>
import { ref } from 'vue'

const products = ref([])
const selectedId = ref(null)
</script>

<template>
  <div class="grid">
    <div
      v-for="product in products"
      :key="product.id"
      v-memo="[product.id === selectedId, product.price]"
      :class="{ selected: product.id === selectedId }"
    >
      <h3>{{ product.name }}</h3>
      <span>{{ product.price }}</span>
    </div>
  </div>
</template>
```

`v-memo` 배열 `[product.id === selectedId, product.price]`는 Vue에게 "선택 상태나 가격이 변경되지 않는 한 이 항목의 재렌더링을 건너뛰라"고 지시합니다. 500개 상품 리스트에서 하나만 선택되는 경우, VDOM 작업이 500개의 서브트리 비교에서 2개(이전 선택 항목과 새로 선택된 항목)로 줄어듭니다.

### Suspense를 활용한 비동기 컴포넌트와 코드 분할

무거운 컴포넌트의 지연 로딩으로 초기 번들을 가볍게 유지할 수 있습니다. Vue의 `defineAsyncComponent`와 `Suspense`를 조합하면 로딩 상태를 선언적으로 처리할 수 있습니다.

```vue
<!-- Dashboard.vue -->
<script setup>
import { defineAsyncComponent } from 'vue'

// 무거운 차트 라이브러리는 필요할 때만 로드
const AnalyticsChart = defineAsyncComponent(() =>
  import('./components/AnalyticsChart.vue')
)

const DataExport = defineAsyncComponent({
  loader: () => import('./components/DataExport.vue'),
  delay: 200,       // 200ms 후 로딩 표시
  timeout: 10000,   // 10초 후 타임아웃
})
</script>

<template>
  <Suspense>
    <template #default>
      <AnalyticsChart />
      <DataExport />
    </template>
    <template #fallback>
      <div class="skeleton-loader" />
    </template>
  </Suspense>
</template>
```

## Vapor Mode vs VDOM: 상황별 선택 가이드

Vapor Mode는 가상 DOM의 보편적인 대체제가 아닙니다. 각 컴파일 모드는 서로 다른 컴포넌트 프로파일에 적합한 강점을 가지고 있습니다.

| 시나리오 | 권장 모드 | 이유 |
|---|---|---|
| 데이터 테이블 (1000행 이상) | Vapor | 행별 VDOM 오버헤드 제거 |
| 실시간 대시보드 | Vapor | 빈번한 업데이트가 직접 DOM 바인딩의 이점을 받음 |
| 애니메이션 다수 컴포넌트 | Vapor | VDOM 생성/폐기로 인한 GC 압력 없음 |
| 서드파티 VDOM 컴포넌트 라이브러리 | VDOM | 상호 운용 레이어가 복잡성을 증가시킴 |
| Options API를 사용하는 컴포넌트 | VDOM | Vapor는 Composition API 필수 |
| 복잡한 유효성 검사가 있는 폼 | 둘 다 가능 | 양 모드에서 렌더링 오버헤드 최소 |
| 정적 콘텐츠 페이지 | 둘 다 가능 | SSG/SSR이 주요 처리를 담당 |

권장 마이그레이션 경로는 먼저 Vue DevTools의 Performance 탭으로 애플리케이션을 프로파일링하는 것입니다. 렌더링 시간과 재렌더링 빈도가 가장 높은 컴포넌트를 식별하고, Vapor Mode로 변환한 후 영향을 측정하고, 거기서부터 확장해 나가는 방식입니다.

## 면접 질문: Vue 3 성능과 Vapor Mode

다음 질문들은 2026년에 Vue 전문성을 평가할 때 엔지니어링 팀이 실제로 묻는 내용을 반영합니다. 각 답변은 면접관이 기대하는 기술적 근거를 요약합니다.

**Q: Vapor Mode는 어떤 문제를 해결하며, Vue가 이미 보유하고 있던 VDOM 최적화와 어떻게 다른가?**

Vue 3의 VDOM 컴파일러는 이미 정적 서브트리 최적화, 패치 플래그 추가, 불필요한 비교를 건너뛰기 위한 블록 트리를 구현하고 있었습니다. 이를 통해 VDOM 오버헤드가 줄었지만 제거되지는 않았습니다. 모든 상태 변경 시 여전히 VDOM 노드 생성, 트리 순회, 패치 생성이 필요했습니다. Vapor Mode는 이 전체 파이프라인을 제거합니다. 컴파일러가 반응형 상태를 직접 DOM 조작에 매핑하므로, 상태 변경은 필요한 DOM 작업만 트리거합니다. 중간 데이터 구조도, 비교 알고리즘도, 폐기되는 VDOM 노드의 가비지 컬렉션도 발생하지 않습니다.

**Q: Vapor 컴포넌트와 VDOM 컴포넌트는 같은 애플리케이션에서 공존할 수 있는가?**

가능합니다. `vaporInteropPlugin`을 사용하면 동일한 컴포넌트 트리 내에서 두 가지 컴포넌트 타입을 모두 사용할 수 있습니다. VDOM 부모가 Vapor 자식을 렌더링할 수 있고, 그 반대도 가능합니다. 다만 주의할 점이 있습니다. Vapor 슬롯은 VDOM 컴포넌트 내에서 `slots.default()`를 사용할 수 없으며(대신 `renderSlot` 사용), VDOM 기반 컴포넌트 라이브러리(Vuetify, PrimeVue)와의 상호 운용은 실험 단계에서 문제가 발생할 수 있습니다.

**Q: Vue 3.6 Alien Signals의 푸시-풀 반응성 모델을 설명하시오.**

푸시-풀 모델은 반응형 업데이트를 두 단계로 분할합니다. 푸시 단계에서 시그널 값이 변경되면, 모든 의존하는 computed 속성에 dirty 플래그를 하류로 전파합니다. 이는 불리언 플래그를 뒤집는 것뿐이므로 비용이 낮습니다. 풀 단계에서 computed 값이 실제로 읽힐 때 dirty 여부를 확인합니다. dirty이면 의존성에서 재계산하고, 클린이면 캐시된 값을 반환합니다. 이를 통해 특정 업데이트 사이클에서 읽히지 않을 수 있는 computed 속성을 선행 계산하는 문제를 방지합니다.

**Q: Vue 3 애플리케이션에서 `ref` 대신 `shallowRef`를 사용해야 하는 경우는?**

`shallowRef`는 데이터 구조가 크고 최상위 재할당만으로 반응성을 트리거해야 하는 경우에 적합합니다. API 응답 캐시, 설정 객체, `triggerRef()`로 개별 항목 변경을 수동 제어하는 대규모 배열 등이 해당됩니다. 깊은 반응성은 모든 중첩 속성을 Proxy로 래핑하는데, 데이터를 개별적으로 수정하지 않고 일괄 교체하는 경우에는 불필요한 오버헤드입니다.

Vue.js의 composables와 반응성 패턴에 관한 [면접 대비 문제](/technologies/vue-nuxt/interview-questions/vue-composables)는 SharpSkill에서 추가로 연습할 수 있습니다.

> **참고 자료**
>
> 공식 [Vue.js 성능 가이드](https://vuejs.org/guide/best-practices/performance)에서는 props 안정성, 가상 스크롤링, SSR 스트리밍 등 추가 최적화 기법을 다루고 있습니다. [Vue 3.6 베타 릴리스 노트](https://github.com/vuejs/core/releases/tag/v3.6.0-beta.1)에는 Vapor Mode의 모든 API와 알려진 제한 사항이 기록되어 있습니다.

## 결론

- Vapor Mode는 Vue SFC를 직접 DOM 조작으로 컴파일하여, 가상 DOM 생성, 비교, 패치 적용의 오버헤드를 완전히 제거합니다
- `<script setup vapor>`로 컴포넌트 단위 활성화가 가능하며, 애플리케이션 전체 마이그레이션은 필요하지 않습니다
- Alien Signals는 새로운 기본 반응성 엔진으로, 메모리 사용량을 14% 줄이고 푸시-풀 지연 평가를 통해 computed 속성 성능을 향상시킵니다
- 대규모 데이터 구조에는 `shallowRef`, 고비용 리스트 렌더링에는 `v-memo`, 코드 분할에는 `defineAsyncComponent`를 사용합니다. 이 패턴들은 VDOM과 Vapor 두 모드 모두에서 적용 가능합니다
- Vapor Mode는 `<script setup>`을 사용한 Composition API가 필수입니다. Options API, `getCurrentInstance()`, `globalProperties`는 지원되지 않습니다
- 먼저 Vue DevTools로 프로파일링하고, 영향이 큰 컴포넌트를 Vapor로 변환한 후, 효과를 측정하고 점진적으로 확대합니다
- Vue 3.6은 2026년 초 기준으로 베타 단계입니다. 프로덕션 애플리케이션에서는 Vapor Mode를 실험적으로 취급하되, 팀의 숙련도를 지금부터 높여 나가는 것을 권장합니다

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/ko/blog/vue-nuxt/vue-3-performance-vapor-mode-virtual-dom