Antigravity Agent
4.5 KiB
4.5 KiB
category, tags, title, description, last_updated
| category | tags | title | description | last_updated | |||
|---|---|---|---|---|---|---|---|
| Other |
|
Reactivity API | Reactivity API(반응성 API)는 Vue. | 2026-05-04 |
Reactivity API
📌 Brief Summary
Reactivity API(반응성 API)는 Vue.js 애플리케이션에서 상태(State)와 로직을 캡슐화하고 관리하기 위해 제공되는 핵심 함수들이다 [1, 2]. ref(), reactive(), computed(), watch 등의 도구를 활용하여 반응형 데이터를 선언하며, 단일 소스(Single source of truth)를 여러 컴포넌트 간에 손쉽게 공유할 수 있게 한다 [2-4]. 이를 통해 개발자는 단방향 데이터 흐름의 한계를 극복하고 컴포넌트 외부에서 전역 상태를 단순하게 관리하거나 유연한 로직 모듈(Composables)을 구성할 수 있다 [2, 5, 6].
📖 Core Content
ref()와reactive()를 통한 로컬 상태 관리ref()함수는 문자열, 숫자, 불리언, 객체 등 다양한 데이터 타입을 지원하는 다목적 상태 관리 도구로,.value속성을 통해 데이터에 접근하거나 업데이트하는 명확한 구문을 제공한다 [1, 4]. 반면reactive()함수는 객체, 배열 및 컬렉션 처리에 특화되어 있으며,.value를 사용하지 않고 속성에 직접 접근할 수 있어 복잡한 데이터 구조를 직관적으로 다룰 수 있게 돕는다 [7].- 파생 상태 생성 및 사이드 이펙트 처리
computed()API는 다른 반응형 데이터를 기반으로 파생된 상태를 생성하며, 결과값을 캐싱하고 의존성이 변경될 때만 재계산된다 [4, 8].watchAPI는 반응형 값의 변경을 관찰하고 API 호출과 같은 사이드 이펙트(비동기 작업 등)를 트리거하는 데 사용된다 [4, 9]. - Reactivity API를 활용한 단순한 전역 상태 관리
Reactivity API는 Vue의 컴포넌트 모델과 분리되어 있어 매우 유연하다 [3]. 옵션 API(Options API)의
data()가 내부적으로reactive()를 사용하듯, 개발자는reactive()나ref()를 사용해 반응형 객체를 생성한 후 여러 컴포넌트에서 이를 임포트하여 전역 상태(Global State)처럼 공유할 수 있다 [2]. - Composition API와의 통합 및 Vue 3.5 성능 최적화 Reactivity API는 재사용 가능한 상태 저장 로직을 함수형태로 캡슐화하는 Composable을 구축하는 근간이 된다 [6, 9]. 또한 Vue 3.5 릴리스에서는 반응성 시스템이 크게 리팩토링되어 메모리 사용량이 56% 감소하였으며, 크고 깊은 반응형 배열(Deeply reactive arrays)에 대한 작업 속도가 최대 10배까지 빨라지는 등 대규모 애플리케이션을 위한 성능 향상이 이루어졌다 [10].
⚖️ Trade-offs & Caveats
- 타입 적용의 한계와 반응성 연결 단절 문제
reactive()를 원시 값(Primitive values: 문자열, 숫자 등)에 잘못 사용하면 반응성이 깨질 수 있으므로, 원시 값에는 반드시ref()를 사용해야 한다 [11]. 또한reactive()로 생성된 반응형 객체를 직접 구조 분해 할당(Destructuring)할 경우 반응형 연결이 끊어지는 부작용이 발생한다 [11]. 이를 방지하려면 속성에 직접 접근하거나toRefs()함수를 활용하여 반응성을 유지해야 한다 [11]. - 무분별한 상태 변이로 인한 유지보수성 저하 Reactivity API로 생성한 객체를 직접 공유할 경우, 임포트한 어떤 컴포넌트에서든 상태를 임의로 변이(Mutate)시킬 수 있다 [12]. 이러한 방식은 단기적으로는 편리하지만 장기적으로는 추적이 어려워 유지보수성을 해친다 [12]. 따라서 상태를 직접 수정하기보다는 명확한 의도를 표현하는 메서드(Action)를 상태 객체와 함께 정의하여 중앙 집중식으로 상태를 변경하도록 강제하는 것이 권장된다 [12].
- 서버 사이드 렌더링(SSR) 환경에서의 싱글톤 상태 유출 서버 사이드 렌더링(SSR)을 사용하는 애플리케이션에서 단순한 Reactivity API로 전역 상태를 구현하면, 해당 스토어가 싱글톤으로 작동하여 여러 요청(Request) 간에 상태가 공유되거나 데이터가 유출되는 심각한 문제가 발생할 수 있다 [3]. 따라서 대규모 프로덕션 수준의 앱이나 SSR 환경에서는 Pinia와 같은 공식 상태 관리 라이브러리의 도입이 필수적으로 요구된다 [13].
Last updated: 2026-05-03