# [[Composables]]

## 📌 Brief Summary
Composables는 Vue 3의 Composition API 환경에서 상태 저장 로직(stateful logic)을 캡슐화하여 재사용할 수 있도록 설계된 함수 패턴입니다. [1, 2] 기존 Vue의 Mixin이 가지던 이름 충돌과 암시적 데이터 흐름의 한계를 해결하며, 애플리케이션의 뷰 레이어와 비즈니스 로직을 분리하는 '기능적 코어(functional core)' 역할을 수행합니다. [3, 4] React의 커스텀 훅(Custom Hooks)과 유사하게 작동하지만, 호출 순서나 조건부 호출에 대한 제약이 적어 더욱 유연하게 활용될 수 있습니다. [5]

## 📖 Core Content
*   **논리의 캡슐화와 단일 책임 원칙**: Composables는 특정 기능이나 단일 책임(single responsibility)에 초점을 맞춰 설계되어야 합니다. 데이터 페칭 로직을 예로 들면, 주요 상태(데이터)와 함께 로딩 상태, 에러 처리 등의 보조 상태, 그리고 이를 제어하는 메서드를 하나의 함수 내에 통합하여 관리합니다. [1, 6]
*   **상속을 넘어선 합성(Composition over Inheritance)**: 과거 객체지향적 접근이나 Mixin을 통한 코드 공유는 속성 충돌과 출처가 불분명한 데이터 문제를 낳았습니다. Composables는 명시적으로 정의된 반응형 참조(refs)와 함수만을 반환하므로, 의존성 관계가 투명하고 안전한 타입스크립트 기반의 논리 공유가 가능합니다. [3, 4]
*   **컴포넌트 설계와 결합**: 더 복잡한 기능을 만들기 위해 작은 Composable 여러 개를 중첩(nesting)하여 사용할 수 있습니다. [7] 이렇게 추출된 Composables를 사용하면, 복잡한 인증 흐름이나 폼 유효성 검사, 드래그 앤 드롭 등의 인터랙션 로직을 컴포넌트 밖으로 빼내어 UI 컴포넌트를 가볍게 유지할 수 있습니다. [4, 8]
*   **팀 협업 및 테스트 용이성 극대화**: 각 Composable은 `useAuth`, `useCounter`와 같이 의도를 명확히 드러내는 명명 규칙을 따르는 것이 권장됩니다. [5, 9] 또한 UI DOM 요소 전체를 마운트할 필요 없이, 반응형 상태와 비즈니스 로직이 담긴 Composable 함수만 개별적으로 유닛 테스트할 수 있어 대규모 프로젝트에서 코드 오염을 방지하고 견고함을 유지할 수 있습니다. [4, 5, 10]

## ⚖️ Trade-offs & Caveats
*   **유연성으로 인한 코드 파편화 위험**: Composition API와 Composables가 제공하는 높은 유연성은 오히려 양날의 검이 될 수 있습니다. 로직을 어떻게 추출하고 명명할지에 대해 팀 내의 명확한 코딩 표준(naming conventions, 파일 구조 등)이 확립되지 않으면, 일관성 없는 코드가 양산되어 장기적인 유지보수가 어려워질 수 있습니다. [5, 9, 11]
*   **가파른 학습 곡선**: 소규모 프로젝트나 Vue에 처음 입문하는 개발자에게는 직관적이고 선언적인 Options API에 비해, 상태와 반응성 객체를 직접 조립해야 하는 Composables 패턴이 상대적으로 가파른 학습 곡선을 요구합니다. [12-14]
*   **반응성(Reactivity) 손실 주의**: 원시 값과 객체의 반응성을 다루는 방식(`ref` vs `reactive`)을 정확히 이해하지 못하고 구조 분해 할당(destructuring)을 오용할 경우, 컴포넌트와의 반응성 연결이 끊어지는 흔한 함정(pitfall)에 빠질 수 있습니다. [15]

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처/기반 기술]
- [[Composition API]]
  - 연결 이유: Composables를 구현하고 실행하기 위한 Vue 3의 핵심 API입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 논리를 컴포넌트 옵션(data, methods 등)이 아닌 기능별로 묶어내는 메커니즘과 반응성 기초를 이해할 수 있습니다. [16, 17]
- [[Custom Hooks]]
  - 연결 이유: React 진영에서 상태 기반 로직을 추출하기 위해 사용하는, Composables와 직접적으로 대응되는 설계 패턴입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 함수 합성을 통한 로직 재사용 패러다임을 이해하고, 두 프레임워크 간의 호출 제약(Hook의 규칙 등) 차이를 심층적으로 비교할 수 있습니다. [5, 18]

#### [구현/활용 도구]
- [[Mixins]]
  - 연결 이유: Vue 2에서 널리 쓰이던 로직 재사용 패턴이자, Composables가 극복하고자 한 핵심 대상입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 이름 충돌(Naming collision)과 암시적 데이터 출처 문제 등 구형 패턴의 한계를 인지함으로써 Composables 도입의 당위성을 체감할 수 있습니다. [3, 4]
- [[Smart vs Dumb Components]]
  - 연결 이유: 프레임워크 전반의 UI 설계 패턴으로, Composables와 시너지를 내는 컴포넌트 구조화 전략입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 데이터 페칭 및 상태 관리(Smart)를 Composables로 분리하여, 오직 렌더링에만 집중하는 재사용 가능한 프리젠테이셔널 컴포넌트(Dumb)를 효과적으로 구성하는 방법을 익힐 수 있습니다. [19]

### Deeper Research Questions
- Vue 3의 Composables는 React의 Custom Hooks와 비교하여, 라이프사이클 처리 및 반응성 추적(Dependency Tracking) 메커니즘에서 어떠한 근본적 차이와 이점을 가지는가?
- 대규모 애플리케이션에서 다수의 Composables와 중앙 집중식 전역 상태 관리 라이브러리(Pinia 등)를 아키텍처 수준에서 어떻게 명확히 구분하고 조화롭게 설계할 수 있는가?
- 서버 사이드 렌더링(SSR) 환경에서 Composables를 설계할 때, 교차 요청 상태 오염(Cross-Request State Pollution) 현상을 방지하기 위한 메모리 및 상태 관리 지침은 무엇인가?
- 여러 개의 Composables를 깊게 중첩(Nesting)하여 사용할 때 발생하는 테스트 복잡성이나 성능 한계를 완화하기 위한 모범 패턴은 무엇인가?
- Composables가 내부적으로 생성하는 부수 효과(Side effects)를 안전하게 해제하기 위해 Vue 3.5에서 도입된 `onWatcherCleanup`과 같은 API를 실무에 어떻게 적용할 것인가? 

### Practical Application Contexts
- **Implementation:** 드래그 앤 드롭 기능, 다단계 워크플로우 진행 상태 추적, API 데이터 페칭(로딩, 에러, 응답 상태 통합)과 같이 복잡한 UI 상호작용 및 상태 변화 로직을 개별 함수로 캡슐화하여 구현할 때 사용합니다. [7, 8]
- **System Design:** 애플리케이션의 로직이 여러 컴포넌트에 분산되는 것을 막고, '기능적 코어' 역할을 하는 독립된 모듈 단위로 시스템을 설계함으로써 마이크로 프론트엔드나 모노레포 아키텍처 확장에 대응합니다. [4, 20]
- **Operation / Maintenance:** 비즈니스 규칙이 변경되거나 버그 패치가 필요할 때, 여러 컴포넌트를 탐색할 필요 없이 해당 로직을 담당하는 단일 Composable만 수정하여 즉각적인 전역 업데이트 효과를 얻습니다. [5, 21]
- **Learning Path:** Vue의 기본 Reactivity(`ref`, `reactive`, `computed` 등)를 이해한 후, 코드의 모듈화를 위해 학습해야 하는 핵심 패턴이며, 이후 대규모 상태 관리(Pinia)로 넘어가기 위한 징검다리 역할을 합니다. [2, 22]
- **My Project Relevance:** 프론트엔드 코드베이스가 커짐에 따라 발생하는 중복 코드를 제거하고, UI 표현 계층과 비즈니스 로직 계층의 결합도를 낮춰 팀 단위 협업 시 충돌 없이 안전하게 개발하기 위해 즉각적으로 도입해야 할 패턴입니다. [23, 24]

### Adjacent Topics
- [[Pinia]]
  - 확장 방향: Composables를 통해 개별 상태 로직을 캡슐화하는 것을 넘어, 애플리케이션 전체에서 공유되어야 하는 글로벌 상태를 타입 안전하고 일관된 방식으로 관리하는 아키텍처로 지식을 확장할 수 있습니다. [25, 26]
- [[TypeScript Generics]]
  - 확장 방향: 재사용성을 더욱 고도화하기 위해, Composables가 다루는 데이터의 타입을 동적으로 추론하고 보호할 수 있도록 제네릭을 접목하는 고급 타입 설계 기법을 연구할 수 있습니다. [27-29]

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