# [[Options API]]

## 📌 Brief Summary
Options API는 Vue.js에서 컴포넌트의 상태와 로직을 `data()`, `methods`, `computed`와 같은 정해진 옵션(options) 블록 기반으로 선언하고 조직화하는 전통적인 컴포넌트 작성 방식이다 [1-3]. 이 방식은 얕은 학습 곡선과 명확하고 선언적인 구조를 제공하여 개발자가 직관적으로 코드를 이해하기 쉽도록 돕는다 [1, 4]. 대규모 애플리케이션보다는 빠른 프로토타입 제작이나 작고 단순한 단일 기능 컴포넌트를 개발하는 데 가장 이상적이고 접근하기 쉬운 패턴으로 평가받는다 [1, 4].

## 📖 Core Content
* **옵션 기반의 코드 조직화**: Options API는 애플리케이션의 특정 기능(feature) 단위가 아닌 역할과 옵션(`data`, `methods` 등)을 기준으로 코드를 그룹화한다 [1, 3]. 컴포넌트 내의 반응형 데이터는 `data()` 옵션을 통해 선언되며, Vue 내부적으로는 `reactive()` 함수를 사용하여 이 객체를 반응형으로 처리한다 [2].
* **소규모 프로젝트 및 초기 학습에 최적화**: 얕은 학습 곡선(Shallow learning curve)을 가지고 있어 Vue.js 입문자에게 훌륭한 진입점(entry point) 역할을 한다 [1, 4]. 또한, 구조가 선언적이고 명확하여 소규모 프로젝트나 신속한 프로토타이핑을 진행할 때 직관적인 개발 경험을 제공한다 [4].
* **로직 재사용 방식**: Options API 환경에서는 컴포넌트 간에 상태 기반 로직을 재사용하기 위한 접근 방식으로 주로 믹스인(Mixins)을 활용한다 [1]. 이는 Composition API가 컴포저블(Composables)을 사용하는 것과 대조된다 [1]. 
* **단일 기능 컴포넌트에 적합**: 재사용성이 낮고 작고 단순하며 단일 기능(single-feature)에 집중하는 컴포넌트를 설계할 때 최적의 선택이 된다 [1].

## ⚖️ Trade-offs & Caveats
* **복잡성 증가 시 유지보수 한계**: 애플리케이션이나 컴포넌트의 규모가 커지고 복잡해지면, 하나의 기능과 관련된 논리가 `data`, `methods`, `computed` 등 여러 옵션에 산발적으로 흩어지게 되어 코드를 추적하고 유지보수하기가 매우 어려워진다 [1, 3, 5].
* **믹스인(Mixins) 사용에 따른 부작용**: 재사용성을 확보하기 위해 믹스인을 적용할 경우, 서로 다른 믹스인 간의 네임스페이스 충돌(naming collision)이 발생하거나, 컴포넌트 내부에서 데이터의 출처가 불분명해지는 숨겨진 데이터(hidden data) 문제가 발생할 수 있다 [1, 6].
* **번들 크기 및 유연성 제약**: Composition API와 비교했을 때 상대적으로 무거운 번들 크기(Bigger bundle size)를 생성하며, 아키텍처 구성에 있어서 유연성이 떨어지는(Less flexible) 단점이 있다 [1].
* **TypeScript 지원의 아쉬움**: Options API 환경에서도 TypeScript를 사용할 수는 있지만, Composition API가 제공하는 뛰어난 타입 추론(Type inference)과 완벽한 호환성에 비하면 타입스크립트 지원이 상대적으로 부족하다 [1, 4].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A: 아키텍처 및 대안 기술]
- [[Composition API]]
  - 연결 이유: Options API의 한계(코드 분절, 믹스인 문제 등)를 극복하기 위해 도입된 Vue 3의 핵심 API로, 기능(Feature) 중심으로 코드를 그룹화하는 대조적인 패턴이다 [1, 3].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Options API가 왜 소규모에 적합하고, 대규모 프로젝트에서는 어떤 이유로 패러다임 전환이 필요했는지에 대한 아키텍처적 진화 과정을 이해할 수 있다 [1, 3].
- [[Reactivity API]]
  - 연결 이유: Options API의 `data()`가 내부적으로 어떻게 반응형 객체를 생성하는지에 대한 기반 메커니즘(`reactive()`, `ref()`)이다 [2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Vue의 반응성 시스템이 컴포넌트 모델과 어떻게 분리되어 동작하는지에 대한 근본적인 원리를 파악할 수 있다 [2].

#### [관계 유형 B: 구현 요소 및 패턴]
- [[Mixins]]
  - 연결 이유: Options API에서 컴포넌트 간에 코드를 재사용하기 위해 전통적으로 사용되어 온 핵심 구현 방식이다 [1].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 객체 병합을 통한 코드 재사용의 한계와 이로 인해 발생하는 네임스페이스 충돌 문제의 원인을 이해할 수 있다 [1, 6].

### Deeper Research Questions
- Options API와 Composition API로 동일한 컴포넌트를 구현했을 때, 내부적인 메모리 처리 및 번들 크기에서 구체적으로 어떤 차이가 발생하는가?
- 대규모 Vue 프로젝트에서 기존 Options API 기반 코드를 Composition API로 점진적으로 마이그레이션할 때 발생할 수 있는 호환성 이슈는 무엇인가?
- Options API에서 Mixins를 사용할 때 발생하는 '이름 충돌(naming collision)'과 '숨겨진 데이터(hidden data)' 문제를 최소화할 수 있는 아키텍처적 우회 방법은 있는가?
- Options API가 제공하는 선언적 구조(Declarative structure)가 초보자의 학습 곡선을 낮추는 인지적, 심리적 이유는 무엇인가?
- TypeScript를 도입한 환경에서 Options API가 가지는 타입 추론의 한계점은 내부 구조적으로 어떻게 기인하는가?

### Practical Application Contexts
- **Implementation:** 작고 재사용성이 낮으며 UI 표현에만 집중하는 단일 기능 컴포넌트(Single-feature component)를 신속하게 구현할 때 직관적인 템플릿으로 사용된다.
- **System Design:** 프로젝트 규모가 작고, 참여하는 팀원들이 Vue 생태계에 처음 입문하여 학습 곡선을 최소화해야 하는 경우 아키텍처 설계의 초기 기준으로 채택될 수 있다.
- **Operation / Maintenance:** 기존 Vue 2 또는 초창기 Vue 3로 작성된 레거시 시스템을 유지보수할 때 가장 빈번하게 마주하는 핵심 패턴이다.
- **Learning Path:** Vue.js의 라이프사이클 훅, 템플릿 문법, `computed`, `watch` 등 프레임워크의 기본적인 동작 방식을 처음 학습하고 이해하는 가장 훌륭한 입문 경로가 된다.
- **My Project Relevance:** 복잡한 상태 관리가 필요 없는 정적 페이지 위주의 웹이나, 빠르게 검증해야 하는 스타트업의 MVP(최소 기능 제품) 프로토타입 제작 시 유용한 선택지가 된다.

### Adjacent Topics
- [[State Management (Pinia/Vuex)]]
  - 확장 방향: Options API 기반의 컴포넌트 트리 내에서 전역 상태(Global State)를 어떻게 효율적으로 주입하고 변이(Mutate)시킬 것인지에 대한 상태 관리 전략으로 확장할 수 있다.
- [[Vue Single-File Components (SFC)]]
  - 확장 방향: 하나의 파일(.vue) 안에 HTML, CSS, JavaScript(Options API)가 응집되어 관리되는 뷰만의 고유한 렌더링 및 파일 구조 원리로 확장된다.

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