From f01c9d55ef16c293347831f36822b46361657a36 Mon Sep 17 00:00:00 2001 From: Antigravity Agent Date: Sun, 3 May 2026 21:29:03 +0900 Subject: [PATCH] =?UTF-8?q?[P-Reinforce]=202026-05-03:=20=EC=A7=80?= =?UTF-8?q?=EC=8B=9D=20=EA=B0=95=ED=99=94=20=EC=99=84=EB=A3=8C=20(Datacoll?= =?UTF-8?q?ector=5FMAC=20=EA=B8=B0=EC=88=A0=20=EC=95=84=ED=8B=B0=ED=8C=A9?= =?UTF-8?q?=ED=8A=B8=20=EC=9D=BC=EA=B4=84=20=EC=9C=84=ED=82=A4=ED=99=94)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../Aspect-Oriented Programming (AOP).md | 61 ++++++++++++ 01_Archive/2026-05-03/Clean Architecture.md | 63 ++++++++++++ 01_Archive/2026-05-03/Client Components.md | 59 ++++++++++++ 01_Archive/2026-05-03/Composables.md | 58 +++++++++++ 01_Archive/2026-05-03/Composition API.md | 61 ++++++++++++ .../2026-05-03/Cross-Cutting Concerns.md | 75 +++++++++++++++ .../2026-05-03/DTO (Data Transfer Object).md | 70 ++++++++++++++ .../2026-05-03/Dependency Injection (DI).md | 70 ++++++++++++++ .../Design Patterns (디자인 패턴).md | 82 ++++++++++++++++ .../2026-05-03/Domain-Driven Design (DDD).md | 63 ++++++++++++ .../2026-05-03/Hexagonal Architecture.md | 65 +++++++++++++ .../Hydration & Progressive Rendering.md | 73 ++++++++++++++ .../2026-05-03/JSI (JavaScript Interface).md | 65 +++++++++++++ 01_Archive/2026-05-03/Layered Architecture.md | 67 +++++++++++++ 01_Archive/2026-05-03/Micro-frontends.md | 58 +++++++++++ .../Microservices Architecture (MSA).md | 58 +++++++++++ .../2026-05-03/Microservices Architecture.md | 64 +++++++++++++ .../2026-05-03/Middleware & Interceptors.md | 68 +++++++++++++ 01_Archive/2026-05-03/Next.js App Router.md | 66 +++++++++++++ 01_Archive/2026-05-03/Options API.md | 56 +++++++++++ 01_Archive/2026-05-03/Pinia.md | 58 +++++++++++ 01_Archive/2026-05-03/React Hooks.md | 75 +++++++++++++++ 01_Archive/2026-05-03/React Suspense.md | 63 ++++++++++++ .../Reactivity System (ref, reactive).md | 57 +++++++++++ .../2026-05-03/Server Components (RSC).md | 67 +++++++++++++ .../2026-05-03/Server Side Rendering (SSR).md | 60 ++++++++++++ 01_Archive/2026-05-03/Spring Boot.md | 65 +++++++++++++ .../2026-05-03/State Management Libraries.md | 72 ++++++++++++++ 01_Archive/2026-05-03/TypeScript.md | 66 +++++++++++++ .../2026-05-03/프레임워크별 실전 패턴.md | 75 +++++++++++++++ .../Aspect-Oriented Programming (AOP).md | 74 +++++++++++++++ 10_Wiki/Topics/Clean Architecture.md | 76 +++++++++++++++ 10_Wiki/Topics/Client Components.md | 72 ++++++++++++++ 10_Wiki/Topics/Composables.md | 71 ++++++++++++++ 10_Wiki/Topics/Composition API.md | 74 +++++++++++++++ 10_Wiki/Topics/Cross-Cutting Concerns.md | 88 +++++++++++++++++ 10_Wiki/Topics/DTO (Data Transfer Object).md | 83 ++++++++++++++++ 10_Wiki/Topics/Dependency Injection (DI).md | 83 ++++++++++++++++ .../Topics/Design Patterns (디자인 패턴).md | 95 +++++++++++++++++++ 10_Wiki/Topics/Domain-Driven Design (DDD).md | 76 +++++++++++++++ 10_Wiki/Topics/Hexagonal Architecture.md | 78 +++++++++++++++ .../Hydration & Progressive Rendering.md | 86 +++++++++++++++++ 10_Wiki/Topics/JSI (JavaScript Interface).md | 78 +++++++++++++++ 10_Wiki/Topics/Layered Architecture.md | 80 ++++++++++++++++ 10_Wiki/Topics/Micro-frontends.md | 71 ++++++++++++++ .../Microservices Architecture (MSA).md | 71 ++++++++++++++ 10_Wiki/Topics/Microservices Architecture.md | 77 +++++++++++++++ 10_Wiki/Topics/Middleware & Interceptors.md | 81 ++++++++++++++++ 10_Wiki/Topics/Next.js App Router.md | 79 +++++++++++++++ 10_Wiki/Topics/Options API.md | 69 ++++++++++++++ 10_Wiki/Topics/Pinia.md | 71 ++++++++++++++ 10_Wiki/Topics/React Hooks.md | 88 +++++++++++++++++ 10_Wiki/Topics/React Suspense.md | 76 +++++++++++++++ .../Reactivity System (ref, reactive).md | 70 ++++++++++++++ 10_Wiki/Topics/Server Components (RSC).md | 80 ++++++++++++++++ 10_Wiki/Topics/Server Side Rendering (SSR).md | 73 ++++++++++++++ 10_Wiki/Topics/Spring Boot.md | 78 +++++++++++++++ 10_Wiki/Topics/State Management Libraries.md | 85 +++++++++++++++++ 10_Wiki/Topics/TypeScript.md | 79 +++++++++++++++ 10_Wiki/Topics/docs/records/Topics/README.md | 18 ++++ .../docs/records/Topics/chronicle.config.json | 11 +++ ...ravity-wiki-10-wiki-topics-여기가-네-지.md | 19 ++++ .../docs/records/Topics/project-profile.md | 31 ++++++ .../Topics/docs/records/Topics/timeline.md | 7 ++ 10_Wiki/Topics/프레임워크별 실전 패턴.md | 88 +++++++++++++++++ scratch/p_reinforce_bulk.py | 92 ++++++++++++++++++ 66 files changed, 4488 insertions(+) create mode 100644 01_Archive/2026-05-03/Aspect-Oriented Programming (AOP).md create mode 100644 01_Archive/2026-05-03/Clean Architecture.md create mode 100644 01_Archive/2026-05-03/Client Components.md create mode 100644 01_Archive/2026-05-03/Composables.md create mode 100644 01_Archive/2026-05-03/Composition API.md create mode 100644 01_Archive/2026-05-03/Cross-Cutting Concerns.md create mode 100644 01_Archive/2026-05-03/DTO (Data Transfer Object).md create mode 100644 01_Archive/2026-05-03/Dependency Injection (DI).md create mode 100644 01_Archive/2026-05-03/Design Patterns (디자인 패턴).md create mode 100644 01_Archive/2026-05-03/Domain-Driven Design (DDD).md create mode 100644 01_Archive/2026-05-03/Hexagonal Architecture.md create mode 100644 01_Archive/2026-05-03/Hydration & Progressive Rendering.md create mode 100644 01_Archive/2026-05-03/JSI (JavaScript Interface).md create mode 100644 01_Archive/2026-05-03/Layered Architecture.md create mode 100644 01_Archive/2026-05-03/Micro-frontends.md create mode 100644 01_Archive/2026-05-03/Microservices Architecture (MSA).md create mode 100644 01_Archive/2026-05-03/Microservices Architecture.md create mode 100644 01_Archive/2026-05-03/Middleware & Interceptors.md create mode 100644 01_Archive/2026-05-03/Next.js App Router.md create mode 100644 01_Archive/2026-05-03/Options API.md create mode 100644 01_Archive/2026-05-03/Pinia.md create mode 100644 01_Archive/2026-05-03/React Hooks.md create mode 100644 01_Archive/2026-05-03/React Suspense.md create mode 100644 01_Archive/2026-05-03/Reactivity System (ref, reactive).md create mode 100644 01_Archive/2026-05-03/Server Components (RSC).md create mode 100644 01_Archive/2026-05-03/Server Side Rendering (SSR).md create mode 100644 01_Archive/2026-05-03/Spring Boot.md create mode 100644 01_Archive/2026-05-03/State Management Libraries.md create mode 100644 01_Archive/2026-05-03/TypeScript.md create mode 100644 01_Archive/2026-05-03/프레임워크별 실전 패턴.md create mode 100644 10_Wiki/Topics/Aspect-Oriented Programming (AOP).md create mode 100644 10_Wiki/Topics/Clean Architecture.md create mode 100644 10_Wiki/Topics/Client Components.md create mode 100644 10_Wiki/Topics/Composables.md create mode 100644 10_Wiki/Topics/Composition API.md create mode 100644 10_Wiki/Topics/Cross-Cutting Concerns.md create mode 100644 10_Wiki/Topics/DTO (Data Transfer Object).md create mode 100644 10_Wiki/Topics/Dependency Injection (DI).md create mode 100644 10_Wiki/Topics/Design Patterns (디자인 패턴).md create mode 100644 10_Wiki/Topics/Domain-Driven Design (DDD).md create mode 100644 10_Wiki/Topics/Hexagonal Architecture.md create mode 100644 10_Wiki/Topics/Hydration & Progressive Rendering.md create mode 100644 10_Wiki/Topics/JSI (JavaScript Interface).md create mode 100644 10_Wiki/Topics/Layered Architecture.md create mode 100644 10_Wiki/Topics/Micro-frontends.md create mode 100644 10_Wiki/Topics/Microservices Architecture (MSA).md create mode 100644 10_Wiki/Topics/Microservices Architecture.md create mode 100644 10_Wiki/Topics/Middleware & Interceptors.md create mode 100644 10_Wiki/Topics/Next.js App Router.md create mode 100644 10_Wiki/Topics/Options API.md create mode 100644 10_Wiki/Topics/Pinia.md create mode 100644 10_Wiki/Topics/React Hooks.md create mode 100644 10_Wiki/Topics/React Suspense.md create mode 100644 10_Wiki/Topics/Reactivity System (ref, reactive).md create mode 100644 10_Wiki/Topics/Server Components (RSC).md create mode 100644 10_Wiki/Topics/Server Side Rendering (SSR).md create mode 100644 10_Wiki/Topics/Spring Boot.md create mode 100644 10_Wiki/Topics/State Management Libraries.md create mode 100644 10_Wiki/Topics/TypeScript.md create mode 100644 10_Wiki/Topics/docs/records/Topics/README.md create mode 100644 10_Wiki/Topics/docs/records/Topics/chronicle.config.json create mode 100644 10_Wiki/Topics/docs/records/Topics/decisions/ADR-0001-volumes-data-project-antigravity-wiki-10-wiki-topics-여기가-네-지.md create mode 100644 10_Wiki/Topics/docs/records/Topics/project-profile.md create mode 100644 10_Wiki/Topics/docs/records/Topics/timeline.md create mode 100644 10_Wiki/Topics/프레임워크별 실전 패턴.md create mode 100644 scratch/p_reinforce_bulk.py diff --git a/01_Archive/2026-05-03/Aspect-Oriented Programming (AOP).md b/01_Archive/2026-05-03/Aspect-Oriented Programming (AOP).md new file mode 100644 index 00000000..0e505e11 --- /dev/null +++ b/01_Archive/2026-05-03/Aspect-Oriented Programming (AOP).md @@ -0,0 +1,61 @@ +# [[Aspect-Oriented Programming (AOP)]] + +## 📌 Brief 시 Summary +Aspect-Oriented Programming(AOP)은 소프트웨어 시스템 내 여러 모듈에 걸쳐 공통적으로 나타나는 **횡단 관심사(Cross-Cutting Concerns)를 핵심 비즈니스 로직과 분리하여 모듈화하는 프로그래밍 방법론**이다 [1]. 주로 로깅, 예외 처리, 트랜잭션, 보안 등 애플리케이션 전반에 필수적이지만 도메인 로직 자체는 아닌 기능들을 캡슐화하는 데 사용된다 [2], [3]. 이를 통해 비즈니스 코드를 수정하지 않고도 공통 기능을 적용할 수 있어 코드의 중복(Scattering)을 막고 시스템의 가독성과 유지보수성을 극대화한다 [4], [5]. + +## 📖 Core Content +* **관심사의 분리 (Core vs Cross-Cutting):** + 소프트웨어 시스템은 일차적 요구사항인 핵심 관심사(Core Concerns, 예: 비즈니스 로직)와 이차적 요구사항인 횡단 관심사(Cross-Cutting Concerns)로 나뉜다 [2]. AOP는 이 중 로깅, 보안, 데이터 유효성 검사, 예외 처리처럼 여러 계층(프레젠테이션, 비즈니스, 데이터 등)에 걸쳐 반복적으로 등장하는 로직을 추출해 내는 역할을 한다 [6], [7], [2], [8], [9]. +* **코드 산재(Scattering)와 얽힘(Tangling) 방지:** + AOP를 적용하지 않으면 수백, 수천 개의 클래스에 `try-catch` 블록이나 로깅 코드가 반복적으로 산재하게 된다 [8], [10]. AOP는 이러한 로직을 하나의 '관점(Aspect)'으로 중앙 집중화하여 비즈니스 코드의 오염을 막고 단일 책임 원칙(SRP)과 DRY(Don't Repeat Yourself) 원칙을 준수하도록 돕는다 [4], [11], [12]. +* **프레임워크별 실전 아키텍처 패턴:** + * **Spring Boot (Java):** AOP는 메서드 레벨에서 작동하며, 컨트롤러, 서비스, 리포지토리 등 모든 Spring 빈(Bean) 메서드의 실행을 가로챌 수 있다 [5]. `@Aspect` 어노테이션과 함께 `@Before`, `@After`, `@Around` 등의 Advice를 사용하여 비즈니스 로직을 터치하지 않고 횡단 관심사를 적용하는 것이 가장 강력한 실전 패턴이다 [5], [13], [14]. + * **C# / .NET:** C#은 AOP를 네이티브 수준에서 완전하게 지원하지 않는다 [1]. 따라서 속성(Attributes)을 정의하고 `Castle.DynamicProxy`와 같은 런타임 인터셉터를 사용하여 메서드 호출을 가로채는 방식으로 간접적인 AOP를 구현해야 한다 [1]. + +## ⚖️ Trade-offs & Caveats +* **코드의 마법 같은 동작(Magical Behavior)과 디버깅 난이도:** + AOP의 가장 큰 단점은 코드가 명시적으로 호출되지 않아도 은연중에 실행되기 때문에 로직의 흐름이 너무 "마법처럼" 보일 수 있다는 점이다 [15], [16]. 이로 인해 새로운 개발자가 특정 동작이 어디서 유발되는지 파악하기 어려우며, 의도치 않은 곳에서 로직이 실행되거나 에러가 발생할 경우 디버깅 추적이 매우 까다로워진다 [15], [16]. +* **성능 오버헤드 (Performance Cost):** + C# 등에서 `Castle.DynamicProxy`와 같은 런타임 인터셉터를 사용하는 AOP 접근법은 각 메서드나 클래스에 대해 런타임 프록시 래퍼를 생성해야 하므로 성능 비용(Runtime cost)이 발생한다 [17]. +* **세밀한 컨텍스트 제어의 한계:** + 특정 상황의 세부적인 맥락(예: 함수 내 특정 지역 변수의 상태 포맷팅)이 필요한 로깅의 경우, AOP 외부 래퍼에서 그 데이터에 접근하기 어려워 기존 로깅 라이브러리를 코드 내부에서 직접 호출하는 것보다 유연성이 떨어질 수 있다 [18]. + +## 🔗 Knowledge Connections + +### Related Concepts + +#### [관계 유형 A: 아키텍처/기반 기술] +* **[[Cross-Cutting Concerns]]** (횡단 관심사) + * 연결 이유: AOP가 기술적으로 해결하고자 하는 근본적인 대상이 바로 애플리케이션 전반에 걸쳐 영향을 미치는 횡단 관심사이기 때문이다 [6], [1]. + * 이 개념을 통해 더 깊게 이해할 수 있는 부분: 로깅, 예외 처리, 캐싱, 보안 정책 등이 왜 비즈니스 핵심 로직과 분리되어 관리되어야 하는지 그 아키텍처적 당위성을 이해할 수 있다 [7], [3]. +* **[[Separation of Concerns]]** (관심사 분리) + * 연결 이유: 핵심 도메인 규칙과 시스템 인프라 로직을 물리적/논리적으로 분리하는 소프트웨어 설계의 대원칙으로, AOP 탄생의 철학적 기반이다 [7], [19]. + * 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클린 아키텍처 및 헥사고날 아키텍처에서 비즈니스 로직을 외부 프레임워크나 횡단 관심사로부터 어떻게 고립시키는지 그 메커니즘을 파악할 수 있다 [7], [20]. + +#### [관계 유형 B: 구현/활용 도구] +* **[[Filters]] & [[Interceptors]]** + * 연결 이유: Spring Boot와 같은 프레임워크에서 AOP와 함께 횡단 관심사를 처리하는 대표적인 파이프라인 컴포넌트들이다 [19], [21], [16]. + * 이 개념을 통해 더 깊게 이해할 수 있는 부분: AOP(임의의 빈 메서드 레벨), Filter(서블릿 레벨), Interceptor(웹 컨트롤러 레벨)가 각각 어느 계층에서 어떤 역할(예: CORS, 보안, 세부 로깅 등)에 가장 적합한지 비교 분석할 수 있다 [13], [22]. + +### Deeper Research Questions +* Spring Boot 시스템에서 로깅이나 보안 같은 횡단 관심사를 구현할 때, 서블릿 계층의 Filter, MVC 계층의 Interceptor, 서비스 계층의 AOP 중 어느 것을 선택하는 것이 가장 최적의 성능과 유지보수성을 보장하는가? [13], [22] +* C# 및 .NET 환경에서 런타임 프록시 생성으로 인한 성능 오버헤드를 방지하기 위해, 컴파일 타임(Compile-Time) 위빙을 통한 AOP 구현 방식에는 어떤 것들이 있는가? [17] +* AOP의 '마법 같은(magical)' 비명시적 실행 흐름으로 인한 디버깅 추적의 어려움을 해결하기 위해, 대규모 엔터프라이즈 환경에서는 어떠한 아키텍처적 안전장치나 모니터링 도구를 도입하는가? [15], [16] +* 클린 아키텍처(Clean Architecture)나 헥사고날 아키텍처(Hexagonal Architecture) 패턴 내에서 AOP를 적용할 때, 핵심 도메인 모델을 침범하지 않고 인프라스트럭처 레이어와 자연스럽게 연결하는 방법은 무엇인가? [7], [19] +* 마이크로서비스나 분산 시스템 환경에서 AOP를 사용하여 여러 서비스에 걸친 분산 추적(Distributed Tracing) 및 에러 핸들링의 일관성을 어떻게 유지할 수 있는가? [23], [24], [25] + +### Practical Application Contexts +* **Implementation:** Spring Boot 애플리케이션에서 특정 비즈니스 로직(Service)의 실행 시간을 측정하거나 로깅을 남길 때, 코드 내부에 `System.out.println` 등을 산재시키지 않고 `@Aspect`와 `@Around` 어노테이션을 활용하여 깔끔하게 캡슐화하여 구현한다 [10], [5], [13]. +* **System Design:** 시스템 전반에 걸친 보안 검사, 트랜잭션 롤백, 글로벌 예외 처리 정책을 설계할 때, 핵심 비즈니스 로직에서 해당 책임을 제거하고 AOP 계층이나 중앙 집중화된 파이프라인 행동(Pipeline Behaviors)으로 추상화하여 확장 가능한 시스템을 설계한다 [19], [26], [8], [27]. +* **Operation / Maintenance:** 로깅 프레임워크를 변경하거나 보안 인가(Authorization) 정책을 대대적으로 수정해야 할 때, 수천 개의 파일을 개별적으로 수정하는 대신 단일 Aspect 정의부만 수정하여 유지보수성을 극대화한다 [10], [4]. +* **Learning Path:** 소프트웨어 기능의 분류(Core vs Cross-Cutting) 이해 ➔ 의존성 주입(DI)의 필요성 파악 ➔ Filter/Interceptor 등 기존 계층적 패턴 학습 ➔ 최종적으로 AOP의 핵심 요소(Aspect, Pointcut, Advice)를 적용하는 단계적 학습 모델을 거친다 [2], [13]. +* **My Project Relevance:** 현대 개발 프레임워크 아키텍처에서 비즈니스 로직과 인프라 관심사를 융합 없이 격리하는 필수 전략으로 다뤄지지만, 동시에 '기술 부채(Technical Debt)'를 야기할 수 있는 디버깅 복잡성을 이해하고 방어적으로 적용해야 하는 핵심 패턴이다 [16], [28]. + +### Adjacent Topics +* **[[Dependency Injection (DI)]]** + * 확장 방향: AOP가 인터셉터나 관점(Aspect)을 애플리케이션 곳곳의 객체에 적용하기 위해서는 객체의 생명주기를 관리하는 제어의 역전(IoC) 및 의존성 주입 컨테이너의 지원이 필수적이므로, IoC/DI 컨테이너의 작동 원리로 학습을 확장한다 [29], [30]. +* **[[Hexagonal Architecture]]** + * 확장 방향: 도메인 로직을 외부 데이터베이스나 UI 인프라로부터 철저히 분리하고 보호한다는 철학이 AOP의 관심사 분리와 일맥상통하므로, 포트와 어댑터(Ports and Adapters) 패턴에서 횡단 관심사가 어떻게 매핑되는지로 개념을 확장한다 [20], [31]. + +--- +*Last updated: 2026-05-03* \ No newline at end of file diff --git a/01_Archive/2026-05-03/Clean Architecture.md b/01_Archive/2026-05-03/Clean Architecture.md new file mode 100644 index 00000000..36816406 --- /dev/null +++ b/01_Archive/2026-05-03/Clean Architecture.md @@ -0,0 +1,63 @@ +# [[Clean Architecture]] + +## 📌 Brief Summary +Clean Architecture는 시스템의 핵심 비즈니스 로직과 애플리케이션 전체에 걸쳐 있는 횡단 관심사(Cross-cutting concerns)를 분리하여 시스템의 유지보수성과 확장성을 보장하는 아키텍처 원칙입니다 [1]. 이 아키텍처는 관심사의 분리와 모듈화를 강조하며, 비즈니스 규칙이 다른 요소들로 인해 어지럽혀지지 않고 깔끔하며 적응 가능하도록 유지하는 것을 목표로 합니다 [1, 2]. 핵심 아이디어는 로깅, 캐싱, 유효성 검사 등의 횡단 관심사를 비즈니스 로직과 분리하여 인프라스트럭처(Infrastructure) 계층에 구현하는 것입니다 [3]. + +## 📖 Core Content + +* **관심사 분리와 모듈화의 중심 역할** + Clean Architecture에서 횡단 관심사(로깅, 인증, 유효성 검사, 캐싱 등)는 시스템의 유지보수성과 확장성을 보장하기 위해 핵심 비즈니스 로직과 별개로 처리되어야 합니다 [1, 4]. 이러한 분리는 컴포넌트 간의 강한 결합(tight coupling)을 방지하고 코드의 중복을 막아줍니다 [4]. Clean Architecture의 원칙에 따라 핵심 비즈니스 규칙을 깔끔하게 유지하면, 아키텍처 자체를 변경에 유연하게 만들 수 있습니다 [1]. + +* **인프라스트럭처 계층(Infrastructure Layer)에서의 횡단 관심사 구현** + 이상적으로 횡단 관심사는 인프라스트럭처 계층에 구현되어야 합니다 [3]. 프레임워크에 따라 ASP.NET Core 미들웨어나 데코레이터, MediatR 파이프라인 동작(Pipeline behaviors) 등을 사용하여 비즈니스 로직과 횡단 관심사를 명확히 분리할 수 있습니다 [3, 5]. + +* **주요 횡단 관심사의 실전 분리 전략** + * **로깅(Logging):** 파이프라인 동작 내에 로깅 로직을 캡슐화하여 비즈니스 로직과 분리된 고유한 관심사로 취급해야 합니다 [5]. 구조화된 로깅(Structured logging)을 사용하면 정보를 효과적으로 수집하면서도 핵심 로직을 어지럽히지 않을 수 있습니다 [5, 6]. + * **유효성 검사(Validation):** 유효성 검사는 시스템에 잘못된 데이터가 들어오는 것을 막는 첫 번째 방어선으로, 핵심 처리 로직에 도달하기 전에 파이프라인에서 요청을 검증해야 합니다 [6, 7]. 데이터 형식 등을 확인하는 '입력 유효성 검사'와 도메인 특정 규칙을 준수하는지 확인하는 '비즈니스 규칙 유효성 검사'를 명확하게 구별하여 설계해야 합니다 [7, 8]. + * **캐싱(Caching):** 성능과 확장성 향상을 위해 자주 쓰이며, 파이프라인 내에서 Cache Aside 패턴 등을 구현해 요청 처리 전 캐시를 확인하고 업데이트하는 방식을 사용합니다 [8, 9]. + +## ⚖️ Trade-offs & Caveats +Clean Architecture 설계 자체의 근본적인 단점이나 아키텍처적 반대 급부(Trade-off)에 대해서는 **소스에 관련 정보가 부족합니다.** + +다만, Clean Architecture 원칙에 따라 횡단 관심사를 인프라스트럭처 계층으로 분리하여 최적화할 때 다음과 같은 기술적 제약과 고려 사항이 따릅니다: +* **로깅의 적정성 문제:** 효과적인 로깅을 위해 구조화된 데이터를 캡슐화하더라도, 세분화(granularity)와 명확성 사이의 균형을 맞추지 못하면 로그가 유용한 도구가 아닌 단순한 소음(noise)으로 전락할 수 있습니다 [6]. +* **캐싱 설계의 복잡성 증가:** 캐싱을 구현할 때는 연산 비용이 높으면서도 충분히 안정적인(stable) 데이터만을 신중히 선택해야 합니다 [9]. 또한, 적절한 캐시 무효화(Invalidation) 시점 결정과 만료 시간 및 크기 등의 캐시 설정(Configuration)을 완벽히 통제해야 하는 기술적 부담이 발생합니다 [9]. + +## 🔗 Knowledge Connections + +### Related Concepts + +#### [아키텍처 패턴 / 설계 사상] +- [[Hexagonal Architecture]] + - 연결 이유: Clean Architecture와 마찬가지로 외부 종속성(DB, UI 등)으로부터 애플리케이션 로직을 강하게 결합하지 않고 관심사를 분리 및 모듈화하기 위해 고안된 아키텍처 패턴입니다 [2]. + - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처가 어떻게 핵심 비즈니스 로직을 중심에 두고 외부와의 인터페이스(포트와 어댑터)를 통해 횡단 관심사와 외부 기술을 격리하는지 이해할 수 있습니다 [2, 10]. + +- [[Cross-Cutting Concerns]] + - 연결 이유: 로깅, 유효성 검사, 캐싱, 예외 처리 등 여러 계층에 걸쳐 나타나는 공통 기능들로, Clean Architecture가 비즈니스 로직에서 떼어내어 인프라스트럭처 계층으로 격리하고자 하는 주 대상입니다 [1, 3, 4]. + - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 왜 이 관심사들이 중앙집중화되어야 하며, 이를 방치할 경우 어떻게 코드 중복과 강한 결합이 발생하는지 통찰을 얻을 수 있습니다 [4]. + +#### [구현 및 활용 도구] +- [[Modular Monolith]] + - 연결 이유: Clean Architecture 원칙과 결합하여 대규모 애플리케이션을 구축할 때 자주 언급되는 실전 시스템 구현 구조입니다 [11, 12]. + - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 물리적인 마이크로서비스로 분리하기 전, 단일 코드베이스 내에서 Clean Architecture의 모듈화와 관심사 분리 원칙을 어떻게 실제 프로덕션 수준으로 구현하는지 파악할 수 있습니다 [12]. + +### Deeper Research Questions +- Clean Architecture 내에서 도메인 규칙을 검증하는 '비즈니스 규칙 유효성 검사'와 단순한 '입력 유효성 검사'를 코드 레벨에서 완벽하게 분리하는 가장 이상적인 패턴은 무엇인가? +- 인프라스트럭처 계층의 파이프라인 (예: MediatR 파이프라인)을 통해 캐싱과 로깅을 중앙 집중화할 때 발생하는 런타임 오버헤드는 어떻게 최소화할 수 있는가? +- Clean Architecture, Hexagonal Architecture(Ports and Adapters), Onion Architecture 등 관심사 분리를 강조하는 아키텍처들 간의 미세한 구조적 차이점과 프레임워크(Spring Boot, NestJS 등)별 최적합성은 무엇인가? +- 대규모 애플리케이션에서 비즈니스 로직의 순수성을 지키면서 캐시 무효화(Cache Invalidation)와 같은 인프라적 제어 로직을 도메인과 분리해 설계하는 방법은 무엇인가? +- 클린 아키텍처의 의존성 주입(DI) 원칙이 모놀리식 구조에서 마이크로서비스 아키텍처로 전환할 때 어떤 이점과 한계를 가지는가? + +### Practical Application Contexts +- **Implementation:** .NET 에코시스템의 MediatR `IPipelineBehavior` 나 ASP.NET Core 미들웨어를 사용하여 로깅, 캐시(Cache Aside), 입력 유효성 검사를 구현함으로써 비즈니스 로직과 인프라를 분리할 수 있습니다 [3, 5, 9]. +- **System Design:** 아키텍처 초기 설계 단계부터 횡단 관심사를 한 곳에 집중시키도록 설계함으로써, 각 기능(Feature) 모듈의 핵심 도메인 규칙이 오염되지 않는 확장 가능한 백엔드 시스템을 설계할 수 있습니다 [1, 4]. +- **Operation / Maintenance:** 구조화된 로깅과 체계적인 예외 파이프라인 처리를 통해 시스템 운영 시 발생하는 상태 이상을 빠르게 추적하고, 잘못된 데이터 유입을 비즈니스 로직 진입 전에 차단하여 운영 복원력을 높입니다 [6, 8]. +- **Learning Path:** 횡단 관심사 이해 -> 의존성 주입과 파이프라인 패턴 학습 -> Clean Architecture와 Hexagonal Architecture 철학 이해 -> Modular Monolith 및 Domain-Driven Design 설계 방식 수립 순으로 학습을 진행합니다 [2, 3, 11, 12]. +- **My Project Relevance:** 현재 적용 중인 웹 프레임워크(예: NestJS의 파이프/가드, Spring Boot의 AOP/인터셉터)에서 핵심 로직 외의 기능들이 어떻게 구현되어 있는지 점검하고, 이를 Clean Architecture의 관점에서 인프라스트럭처 계층으로 재배치하는 리팩토링에 활용할 수 있습니다 [3, 13]. + +### Adjacent Topics +- [[Domain-Driven Design]] + - 확장 방향: Clean Architecture가 구조적 분리를 통해 뼈대를 잡는다면, DDD는 그 내부의 '핵심 비즈니스 로직'을 어떻게 모델링하고 구체화할지에 대한 방법론을 제공하므로 이 둘의 결합 시너지를 탐구할 수 있습니다 [8, 11]. + +--- +*Last updated: 2026-05-03* \ No newline at end of file diff --git a/01_Archive/2026-05-03/Client Components.md b/01_Archive/2026-05-03/Client Components.md new file mode 100644 index 00000000..dfd755bb --- /dev/null +++ b/01_Archive/2026-05-03/Client Components.md @@ -0,0 +1,59 @@ +# [[Client Components]] + +## 📌 Brief 신Summary +클라이언트 컴포넌트(Client Components)는 React Server Components (RSC) 패러다임에서 상태(State), 생명주기(Lifecycle), 이벤트 핸들러 및 브라우저 전용 API를 사용할 수 있는 전통적인 React 컴포넌트를 의미합니다 [1-3]. 파일 상단에 `'use client'` 지시어(directive)를 선언하여 명시적으로 정의하며, 서버 컴포넌트와 달리 자바스크립트 번들에 코드가 포함되어 브라우저에서 하이드레이션(Hydration) 과정을 거쳐 상호작용성을 제공합니다 [3-5]. + +## 📖 Core Content +* **정의 및 실행 환경** + 명칭과 달리 클라이언트 컴포넌트는 클라이언트에서만 렌더링되는 것이 아니라, 초기에는 서버에서 렌더링된 후 클라이언트에서 다시 렌더링(하이드레이션)되는 특징을 갖습니다 [2, 6, 7]. 이는 과거 애플리케이션의 '표준(standard)' React 컴포넌트에 대한 새로운 명칭이라 볼 수 있습니다 [2]. + +* **서버-클라이언트 경계 및 직렬화(Serialization)** + 서버 컴포넌트에서 클라이언트 컴포넌트로 전달되는 Prop은 반드시 직렬화 가능한(serializable) 값(예: 문자열, 숫자, 객체, 배열, React 요소 등)이어야 합니다 [8]. 함수는 직렬화할 수 없으므로 서버에서 클라이언트로 프로퍼티 형태의 함수 전달이 불가능합니다 [8]. 클라이언트 컴포넌트의 코드는 번들에 남아 있으며, 렌더링 시 RSC 페이로드(Payload)에는 해당 클라이언트 컴포넌트에 대한 모듈 참조(module ID, `react.client.reference`)와 직렬화된 Prop만이 포함되어 클라이언트로 전송됩니다 [9, 10]. + +* **컴포넌트 중첩 및 구조화 (Interleaving)** + 클라이언트 컴포넌트는 내부에서 서버 컴포넌트를 직접 임포트(Import)하여 렌더링할 수 없습니다. 클라이언트 컴포넌트가 임포트하는 모든 하위 컴포넌트는 암시적으로 클라이언트 컴포넌트로 변환되기 때문입니다 [11, 12]. 서버 컴포넌트를 클라이언트 컴포넌트 내부에서 사용하려면, 서버 컴포넌트를 부모 영역에서 생성한 뒤 클라이언트 컴포넌트의 `children`과 같은 Prop 형태로 전달하는 중첩(Interleaving) 방식을 사용해야 합니다 [13-15]. Prop은 직렬화 가능하므로 번들러가 이 구조를 문제없이 처리할 수 있습니다 [15]. + +## ⚖️ Trade-offs & Caveats +* **자바스크립트 번들 크기 증가:** 서버 컴포넌트는 번들에 포함되지 않아 크기를 줄여주지만, 클라이언트 컴포넌트의 코드는 여전히 사용자 브라우저로 전송되어야 하므로 너무 많은 클라이언트 컴포넌트를 사용하면 애플리케이션의 번들 사이즈가 증가합니다 [3, 16]. +* **하이드레이션 간극(Hydration Gap):** 클라이언트 컴포넌트는 서버에서 HTML 형태로 먼저 사용자에게 보일 수 있으나, 브라우저가 자바스크립트를 다운로드하고 이벤트 리스너를 연결(하이드레이션)하기 전까지는 버튼 등 UI가 사용자의 조작에 반응하지 않는 간극이 존재합니다 [17, 18]. +* **관습적 적용의 함정 (Vibe Coding Trap):** 튜토리얼을 따라 하거나 단순히 에러를 피할 목적으로 불필요한 곳까지 무분별하게 `'use client'`를 선언하는 것은 안티 패턴입니다 [19, 20]. 이는 서버 컴포넌트의 장점(번들 사이즈 감소)을 무효화하고 불필요한 아키텍처적 복잡성만 가중시키므로, 브라우저 환경이나 상태 관리 등 클라이언트 기능이 명확히 필요한 경우에만 클라이언트 컴포넌트로 지정해야 합니다 [20]. + +## 🔗 Knowledge Connections + +### Related Concepts + +#### [관계 유형 A: 아키텍처/기반 기술] +- [[React Server Components]] + - 연결 이유: 클라이언트 컴포넌트는 React Server Components (RSC) 패러다임을 구성하는 반쪽이며, 이 둘은 서로 협력하여 클라이언트-서버 간의 렌더링 경계를 형성합니다 [2, 3, 21]. + - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 번들 사이즈 최적화 원리와 데이터를 서버에서 클라이언트로 직렬화하여 전달하는 전체적인 데이터 흐름 아키텍처. +- [[Hydration]] + - 연결 이유: 클라이언트 컴포넌트가 브라우저에 도달하여 마침내 상호작용성을 획득하는 일련의 과정입니다 [17, 22]. + - 이 개념을 통해 더 깊게 이해할 수 있는 부분: SSR(Server-Side Rendering) 환경에서 클라이언트 컴포넌트가 어떻게 기존 HTML DOM 노드에 이벤트 리스너를 부착하고 상태를 초기화하는지에 대한 내부 매커니즘 [18, 22]. + +#### [관계 유형 B: 구현/활용 도구] +- [[use client]] + - 연결 이유: 해당 파일과 그 파일이 임포트하는 모든 종속성이 클라이언트 컴포넌트 환경에서 실행되어야 함을 React와 번들러에 명시하는 지시어(Directive)입니다 [3-5]. + - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 애플리케이션 내에서 '클라이언트 경계(Client Boundary)'가 어떻게 생성되고 파일 단위로 전파되는지에 대한 구조적 원리 [12, 23]. + +### Deeper Research Questions +- 클라이언트 컴포넌트의 하이드레이션 병목 현상을 해결하기 위한 React 18의 'Selective Hydration'은 내부적으로 어떻게 우선순위를 결정하고 작동하는가? +- 서버 컴포넌트를 클라이언트 컴포넌트의 `children` prop으로 전달할 때, 클라이언트의 상태(State)가 변경되어 리렌더링이 발생하면 내부의 서버 컴포넌트 결과물은 어떻게 유지되는가? +- 대규모 React 애플리케이션에서 클라이언트 컴포넌트가 무분별하게 확장되는 것을 방지하기 위해 파일 트리를 어떻게 구조화하는 것이 가장 효과적인가? +- React-Query나 상태 관리 라이브러리를 클라이언트 컴포넌트 최상단 계층(Providers)에 적용할 때 발생하는 성능 저하와 서버 컴포넌트 활용의 트레이드오프는 무엇인가? +- 클라이언트 컴포넌트에서 실행되는 코드 번들의 크기를 평가하고 모니터링하기 위해 어떤 도구와 지표(Metrics)를 활용해야 하는가? + +### Practical Application Contexts +- **Implementation:** React로 버튼, 폼(Form), 토글(Toggle)과 같이 사용자의 직접적인 상호작용이나 상태(`useState`), 사이드 이펙트(`useEffect`)가 필요한 UI 조각을 구현할 때 상단에 `'use client'`를 선언하여 컴포넌트를 개발합니다 [1, 5]. +- **System Design:** 대규모 시스템 설계 시 전체 레이아웃과 데이터 페칭 계층은 서버 컴포넌트로 구성하고, 상태 관리가 필요한 말단의 리프 노드(Leaf Node)나 특정 상호작용 영역만 클라이언트 컴포넌트로 감싸는(Boundary) 캡슐화 전략을 적용합니다 [13, 24]. +- **Operation / Maintenance:** 코드 리뷰 및 유지보수 과정에서 정적인 텍스트만 보여주는 컴포넌트가 클라이언트 컴포넌트로 지정되지 않았는지 주기적으로 검수하여, 불필요한 자바스크립트 전송과 성능 하락을 방지합니다 [19, 20]. +- **Learning Path:** 전통적인 React의 생명주기와 상태 관리를 먼저 학습한 후, SSR과 Hydration의 한계를 파악하고, React 19 및 Next.js 앱 라우터를 통해 RSC 및 클라이언트 컴포넌트 분리 원리를 익힙니다. +- **My Project Relevance:** 차세대 웹 프로젝트를 구축할 때, 유저 인터랙션이 잦은 장바구니/채팅 기능은 클라이언트 컴포넌트로 만들고, 제품 목록 등은 서버 컴포넌트로 구축하여 초기 렌더링 성능을 극대화하는 데 활용될 수 있습니다. + +### Adjacent Topics +- [[Server Actions]] + - 확장 방향: 클라이언트 컴포넌트 내에서 발생한 이벤트를 처리하기 위해 서버 컴포넌트의 기능(데이터베이스 업데이트 등)을 브라우저에서 안전하게 호출하는 최신 패턴으로 확장하여 학습할 수 있습니다 [25-27]. +- [[Suspense]] + - 확장 방향: 클라이언트 컴포넌트가 아직 로딩 중이거나 서버에서 데이터 스트리밍이 진행 중일 때, 사용자의 대기 시간을 부드럽게 처리하는 로딩 스켈레톤(UI) 구현 메커니즘으로 학습을 확장합니다 [28-30]. + +--- +*Last updated: 2026-05-03* \ No newline at end of file diff --git a/01_Archive/2026-05-03/Composables.md b/01_Archive/2026-05-03/Composables.md new file mode 100644 index 00000000..0d53e40c --- /dev/null +++ b/01_Archive/2026-05-03/Composables.md @@ -0,0 +1,58 @@ +# [[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* \ No newline at end of file diff --git a/01_Archive/2026-05-03/Composition API.md b/01_Archive/2026-05-03/Composition API.md new file mode 100644 index 00000000..04c6db25 --- /dev/null +++ b/01_Archive/2026-05-03/Composition API.md @@ -0,0 +1,61 @@ +# [[Composition API]] + +## 📌 Brief Summary +Vue 3 Composition API는 컴포넌트의 옵션(`data`, `methods`, `computed` 등)이 아닌 '논리적 관심사(Logical concerns)'를 기준으로 코드를 구성하고 조직할 수 있게 해주는 강력한 기능이다 [1]. 반응형 원시 타입(`ref`, `reactive`)과 함수를 활용하여 상태와 로직을 캡슐화하고 재사용 가능한 형태로 만든다 [1]. 기존의 Options API에 비해 대규모 프로젝트에서의 확장성, 코드 재사용성, 그리고 TypeScript와의 뛰어난 호환성을 제공하여 유지보수성을 극대화한다 [2-4]. + +## 📖 Core Content +* **반응형 상태 관리 (Reactive State Management)**: `ref()`와 `reactive()` 함수를 통해 반응형 상태를 선언한다. `ref()`는 원시 값과 객체를 모두 지원하며 `.value` 속성을 통해 접근하고, `reactive()`는 주로 복잡한 객체나 배열을 다루기 위해 설계되었다 [5, 6]. 내재된 한계로 인해 유연성을 갖춘 `ref()`를 반응형 상태 선언의 주요 API로 사용하는 것이 종종 권장된다 [6]. +* **컴포저블 (Composables)**: 재사용 가능한 상태 기반 로직을 캡슐화한 함수로, Composition API 재사용성의 초석이다 [7, 8]. 과거 Vue 2의 Mixins 패턴이 초래하던 네이밍 충돌이나 데이터 출처가 불분명해지는 문제를 '상속 대신 합성(Composition over Inheritance)'이라는 접근법을 통해 투명하고 타입 안전하게 해결한다 [9]. +* **논리적 관심사 그룹화**: 기존 Options API에서는 단일 기능에 대한 로직이 `data`, `methods`, `computed` 곳곳에 흩어져 있었으나, Composition API를 사용하면 관련된 모든 로직을 한 곳에 밀집시킬 수 있어 가독성과 추적성이 향상된다 [10, 11]. +* **`