# [[Reactivity System (ref, reactive)]]

## 📌 Brief Summary
Vue 3의 Composition API에서 제공하는 **`ref`와 `reactive`는 애플리케이션의 반응형 상태(Reactive State)를 관리하기 위한 핵심 도구**이다 [1]. `ref`는 문자열, 숫자와 같은 원시 값부터 객체까지 다양한 데이터 타입을 지원하며, `.value` 속성을 통해 데이터에 접근하거나 업데이트한다 [1]. `reactive`는 주로 객체, 배열, 컬렉션 구조를 처리하는 데 특화되어 있으며, `.value` 프로퍼티 없이 속성에 직접 접근할 수 있다 [2]. 이 반응성 시스템은 데이터 변경 시 UI를 자동으로 업데이트하여 빠르고 부드러운 사용자 인터랙션을 가능하게 한다 [1].

## 📖 Core Content
* **반응성(Reactivity) 기초:** Vue 3는 `ref()`와 `reactive()` 함수를 통해 반응형 상태를 직관적이고 효율적으로 관리할 수 있도록 지원한다 [1]. 과거 Options API의 `data()` 옵션이 반환하는 객체 역시 내부적으로는 `reactive()` 함수를 통해 반응성이 부여되었다 [3].
* **`ref()`의 유연성:** `ref()`는 문자열, 숫자, 불리언과 같은 원시값(Primitive values)뿐만 아니라 객체 등 거의 모든 데이터 타입에 사용할 수 있는 매우 다목적인 상태 관리 방법이다 [1, 4]. 이 함수는 `.value` 속성을 가진 래퍼 객체를 생성하여 데이터에 접근하게 하지만, 템플릿(Template) 내에서는 `.value`를 명시할 필요 없이 자동으로 언래핑(Unwrapping)된다(단, 중첩된 ref는 예외) [1, 4]. 
* **`reactive()`의 구조화:** `reactive()`는 주로 객체, 배열, Map, Set과 같은 컬렉션을 처리하기 위해 설계되었다 [2, 4]. `.value`를 사용할 필요 없이 내부 프로퍼티에 직접 접근할 수 있어, 복잡한 데이터 구조를 다룰 때 구조적으로 더 직관적인 관리가 가능하다 [2].
* **글로벌 상태 관리로의 확장:** 여러 컴포넌트 인스턴스에서 공유해야 하는 상태가 있다면, `reactive()`나 `ref()`로 생성한 반응형 상태를 외부 파일로 추출하여 필요한 곳에서 임포트해 단일 진실 공급원(Single source of truth)으로 활용할 수도 있다 [3, 5].
* **Vue 3.5의 반응성 시스템 최적화:** 최신 Vue 3.5 버전에서는 반응성 시스템 엔진이 대대적으로 리팩토링되었다 [6-8]. 그 결과, **메모리 사용량이 약 56% 감소**하였으며, 크고 깊은 반응형 배열에 대한 작업 속도가 **최대 10배까지 향상**되어 대규모 애플리케이션에서의 데이터 처리 효율이 극대화되었다 [7, 8].

## ⚖️ Trade-offs & Caveats
* **`ref`와 `reactive`의 선택 제약:** `reactive`의 고유한 한계들로 인해, 공식적으로는 상태를 선언할 때 **`ref()`를 주요 API로 사용하는 것이 권장**된다 [2].
* **원시값에 `reactive` 사용 금지:** `reactive`를 문자열, 숫자, 불리언 같은 원시값에 사용할 경우 프레임워크의 반응성 연결이 파괴되는 문제가 발생한다 [4].
* **구조 분해 할당(Destructuring) 시의 반응성 상실:** `reactive`로 생성된 객체의 속성을 직접 구조 분해 할당할 경우 해당 속성과 원본 반응형 객체 간의 반응성 연결이 끊어진다 [4]. 이를 방지하려면 프로퍼티에 직접 접근하여 사용하거나, `toRefs()` 유틸리티 함수를 사용하여 반응성을 유지한 채 구조 분해 할당을 수행해야 한다 [4].
* **SSR(서버 사이드 렌더링) 환경에서의 상태 누수 위험:** 반응성 API로 만든 상태를 외부 파일에서 글로벌 싱글톤(Global singleton) 방식으로 단순 공유할 경우, SSR 환경에서는 여러 클라이언트의 요청 간에 상태가 공유되어 데이터 누수나 교차 오염 문제가 발생할 수 있다 [5, 9]. 이를 방지하려면 요청마다 독립적인 스토어 인스턴스를 보장하는 **Pinia**와 같은 상태 관리 라이브러리의 도입이 필요하다 [9, 10].

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처/기반 기술]
- [[Composition API]]
  - 연결 이유: `ref`와 `reactive`를 기반으로 로직을 기능 단위로 그룹화하고 코드의 확장성을 보장하는 Vue 3의 핵심 아키텍처 철학이기 때문이다 [11, 12].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 애플리케이션에서 기존 Options API의 한계를 극복하고 논리적 관심사(Logical concerns)를 분리하는 전략적인 설계 방식을 이해할 수 있다 [11, 12].

#### [구현/활용 도구]
- [[Composables]]
  - 연결 이유: `ref` 및 `reactive`를 활용한 상태 기반 로직을 컴포넌트에서 독립된 재사용 가능한 함수로 캡슐화하는 핵심 패턴이기 때문이다 [13, 14].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포넌트 간 복잡한 비즈니스 로직(예: 데이터 페칭, 폼 유효성 검사)을 추출하고 타입 안전성을 유지하며 공유하는 실전 방법론을 파악할 수 있다 [13, 15].
- [[Pinia]]
  - 연결 이유: 기본 `ref`와 `reactive`만으로는 처리하기 어려운 팀 협업의 복잡성, SSR 지원, DevTools 통합 등을 해결해 주는 Vue의 공식 차세대 상태 관리 라이브러리이기 때문이다 [9, 10, 16].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 시스템에서 글로벌 상태를 안전하게 중앙 집중화하고 SSR 환경에서의 상태 오염(State leakage) 문제를 해결하는 엔터프라이즈급 패턴을 배울 수 있다 [9, 10].

### Deeper Research Questions
- Vue 3.5에서 리팩토링된 반응성 시스템은 내부적으로 어떠한 데이터 구조와 메커니즘을 변경하여 메모리 사용량을 56% 줄이고 배열 연산 속도를 10배 향상시켰는가? [7, 8]
- `reactive` 객체를 구조 분해 할당할 때 반응성이 끊어지는 자바스크립트 레벨의 기술적 원인은 무엇이며, `toRefs()`는 내부적으로 이를 어떻게 프록시(Proxy) 처리하여 반응성을 복원하는가? [4]
- 대규모 엔터프라이즈 환경에서 단일 진실 공급원(Single source of truth)을 구축할 때 `ref`/`reactive`로 만든 외부 스토어를 직접 사용하는 것과 Pinia를 도입하는 것의 아키텍처적 트레이드오프는 무엇인가? [5, 9, 10, 16]
- SSR(서버 사이드 렌더링) 환경에서 `reactive()` 기반의 글로벌 싱글톤 객체를 사용할 때 발생할 수 있는 데이터 격리 실패(Data Bleeding) 시나리오는 구체적으로 어떠한 형태를 띠는가? [5, 9]
- 원시값에는 무조건 `ref`를, 복잡한 객체에는 `reactive`를 사용하는 기존의 관행을 넘어서, 개발팀의 컨벤션으로 오직 `ref()`만을 사용하기로 결정했을 때 얻을 수 있는 장점과 손실되는 편의성은 무엇인가? [2, 4]

### Practical Application Contexts
- **Implementation:** 폼 입력의 단순 텍스트 상태, UI 토글 버튼의 불리언 상태 등 컴포넌트의 단순 지역 상태는 `ref`로 선언하고, 서버에서 받아오는 복잡한 객체 폼 모델은 `reactive`를 사용하여 구현한다. 템플릿에서는 두 경우 모두 직관적으로 바인딩하고 스크립트 내부에서만 `.value`의 명시 여부를 구분하여 코딩한다.
- **System Design:** Composition API를 적용하여 비즈니스 로직을 Composable 함수 단위로 분리할 때, 함수 내부에서 생성한 `ref`와 `reactive` 변수들을 반환함으로써 다양한 컴포넌트 뷰에서 해당 상태와 로직을 자유롭게 레고 블록처럼 조합하여 재사용하게 설계한다.
- **Operation / Maintenance:** 레거시 Options API 코드 베이스를 Vue 3의 Composition API로 전환하거나 Vue 3.5로 프레임워크 버전을 올릴 경우, 크기가 방대한 배열 연산이나 복잡한 상태 객체를 다루는 관리자 대시보드 등의 메모리 부하와 렌더링 성능 지연을 별도의 코드 수정 없이 즉각적으로 개선할 수 있다.
- **Learning Path:** Options API의 `data()` 옵션이 내부적으로 어떻게 `reactive`와 매핑되는지 이해한 후, `ref` 및 `reactive`를 시작으로 `computed`와 `watch`로 이어지는 반응성 기초를 습득한다. 그 후, 이를 Composable 패턴으로 확장하고 최종적으로 Pinia를 통한 전역 상태 관리로 발전해나간다.
- **My Project Relevance:** 프론트엔드 프로젝트 아키텍처 수립 시, 상태 관리의 기본 단위인 `ref`와 `reactive`의 혼용을 막고, 구조 분해 할당 등에서 발생할 수 있는 안티 패턴을 사전에 차단하기 위한 팀 코딩 컨벤션 및 린트(Lint) 규칙을 설정하는 지침으로 활용할 수 있다.

### Adjacent Topics
- [[Computed Properties & Watchers]]
  - 확장 방향: 반응형 상태(`ref`, `reactive`)의 변화를 감지하여 파생된 상태를 자동으로 계산하거나, 외부 데이터 페칭 등 사이드 이펙트(Side Effects)를 실행하는 파생형 반응성 관리 패턴으로 학습을 확장한다.
- [[React Hooks (useState, useEffect)]]
  - 확장 방향: 타 프레임워크인 React의 핵심 훅과 Vue의 반응성 시스템을 아키텍처 관점에서 대조 분석하여, 불변성(Immutability) 기반의 React 상태 관리와 프록시(Proxy) 기반의 Vue 반응성 철학이 프레임워크 패턴에 미치는 영향을 비교 연구한다.

---
*Last updated: 2026-05-03*