feat: complete wikification of War Commander batch 1&2 and final grey dot cleanup

This commit is contained in:
2026-04-27 18:58:22 +09:00
parent 3424166ea2
commit 6b86b0da4c
2706 changed files with 9074 additions and 7273 deletions
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-03FE7E
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.95
tags: []
last_reinforced: 2026-04-20
@@ -21,5 +21,5 @@ github_commit: "[P-Reinforce] Mega Batch - Wikified AODA-Accessibility-for-Ontar
## 🔗 지식 연결 (Graph)
- Raw Source: [[00_Raw/2026-04-20/AODA-Accessibility-for-Ontarians-with-Disabilities-Act.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-09EEF3
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -30,11 +30,11 @@ github_commit: "[P-Reinforce] Continuous Worker - API 응답 및 상태 모델
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[완전성 검사 (Exhaustiveness checking)]], [[Result 타입 (Result Type)]]
- **Projects/Contexts:** [[상태 머신 (State Machine)]], [[오류 처리 아키텍처 (Error Handling Architecture)]]
- **Related Topics:** 식별 가능한 유니온 (Discriminated Unions), 완전성 검사 (Exhaustiveness checking), Result 타입 (Result Type)
- **Projects/Contexts:** 상태 머신 (State Machine), 오류 처리 아키텍처 (Error Handling Architecture)
- **Contradictions/Notes:** API나 시스템의 에러 응답을 모델링할 때 'Result 타입'을 사용하는 방식에 대해 개발자 간의 이견이 존재한다. 예상된 실패를 Result로 강제 반환하면 실행 흐름이 예측 가능해진다는 찬성 측 주장이 있는 반면, 전역 예외 처리기(Global Exception Handler)를 사용하는 쪽이 예외를 단순히 위로 올려보낼 수 있어 불필요한 보일러플레이트 코드 및 과도한 제어 흐름 분기(`switch`문 등)를 줄이고 컨트롤러를 더 깔끔하게 유지할 수 있다는 반대 주장도 팽팽하게 맞선다 [7, 20, 26-31].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/API 응답 및 상태 모델링 (State Modeling and API Responses).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AST-TRANS
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.99
tags: [AST, Abstract Syntax Tree, Transformation, Compiler, Babel]
last_reinforced: 2026-04-20
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AST-TRAVERSAL
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.99
tags: [AST, Abstract Syntax Tree, Traversal, Visitor Pattern, Static Analysis]
last_reinforced: 2026-04-20
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-2801A2
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.95
tags: []
last_reinforced: 2026-04-20
@@ -21,5 +21,5 @@ github_commit: "[P-Reinforce] Batch 10 - Wikified Accessibility-Compliance-WCAG"
## 🔗 지식 연결 (Graph)
- Raw Source: [[00_Raw/2026-04-20/Accessibility-Compliance-WCAG.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AI-ADDITIVE-TYPE
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.97
tags: [Type Theory, Additive Type Logic, TypeScript, Category Theory]
last_reinforced: 2026-04-20
@@ -23,5 +23,5 @@ last_reinforced: 2026-04-20
- 과도한 타입 덧셈(Intersection)은 타입 추론 속도를 늦추고 에러 메시지를 난해하게 만든다. 특히 무한 재귀적인 타입 결합은 컴파일러가 포기하게 만들 수 있으므로, `Interface Extension`을 통해 적절히 계층화하는 설계가 권장된다.
## 🔗 지식 연결 (Graph)
- Related: [[TypeScript-Advanced-Type-System-Design]] , [[Category_Theory]]
- Related: TypeScript-Advanced-Type-System-Design , Category_Theory
- Foundation: [[Computational Theory & Math/Information Theory]]
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-30D321
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.95
tags: []
last_reinforced: 2026-04-20
@@ -21,5 +21,5 @@ github_commit: "[P-Reinforce] Batch 10 - Wikified Affective User Interfaces (AUI
## 🔗 지식 연결 (Graph)
- Raw Source: [[00_Raw/2026-04-20/Affective User Interfaces (AUI).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AI-AGENCY
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.98
tags: [Agency, Game Design, Player Choice, Narrative, Ludology]
last_reinforced: 2026-04-20
@@ -23,5 +23,5 @@ last_reinforced: 2026-04-20
- '에이전시의 환상'도 기술이다. 사실은 정해진 길을 가고 있어도, 마치 자신이 선택한 것처럼 느끼게 만드는 레벨 디자인의 기교(Invisible hand)가 플레이어의 스트레스를 줄이면서 만족감을 극대화한다.
## 🔗 지식 연결 (Graph)
- Related: [[BioShock (2007)]] , [[Ludo-Narrative-Dissonance]]
- Related: [[BioShock (2007)]] , Ludo-Narrative-Dissonance
- Context: [[Immersive-Sim-Genre]]
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AI-AGENT-COMMUNICATION
category: "[[10_Wiki/💡 Topics/AI]]"
category: "10_Wiki/💡 Topics/AI"
confidence_score: 0.97
tags: [AI, MultiAgent, Communication, Protocols]
last_reinforced: 2026-04-20
@@ -24,5 +24,5 @@ last_reinforced: 2026-04-20
- 과거의 규약은 엄격한 기호 논리 기반이었으나, 현대 LLM 기반 에이전트들은 자연어(Natural Language)를 통신 수단으로 주로 사용한다. 이는 유연하지만 '모호함'의 문제를 야기하므로, 최근에는 JSON Schema 기반의 정형화된 통신 포맷을 강제하여 신뢰성을 확보하는 추세다.
## 🔗 지식 연결 (Graph)
- Related: [[AI 에이전트 (AI Agent)]] , [[Multi-Agent System (다중 에이전트 시스템)]]
- Related: [[AI 에이전트 (AI Agent)]] , Multi-Agent System (다중 에이전트 시스템)
- Standard: [[Model Context Protocol (MCP)]]
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-1363FF
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.95
tags: []
last_reinforced: 2026-04-20
@@ -21,5 +21,5 @@ github_commit: "[P-Reinforce] Batch 10 - Wikified Agile-UX-Integration"
## 🔗 지식 연결 (Graph)
- Raw Source: [[00_Raw/2026-04-20/Agile-UX-Integration.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-4B67E4
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.95
tags: []
last_reinforced: 2026-04-20
@@ -21,5 +21,5 @@ github_commit: "[P-Reinforce] Mega Batch - Wikified Americans-with-Disabilities-
## 🔗 지식 연결 (Graph)
- Raw Source: [[00_Raw/2026-04-20/Americans-with-Disabilities-Act-ADA.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-35F340
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.95
tags: []
last_reinforced: 2026-04-20
@@ -21,5 +21,5 @@ github_commit: "[P-Reinforce] Mega Batch - Wikified Apple Human Interface Guidel
## 🔗 지식 연결 (Graph)
- Raw Source: [[00_Raw/2026-04-20/Apple Human Interface Guidelines.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-E24948
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.95
tags: []
last_reinforced: 2026-04-20
@@ -23,11 +23,11 @@ github_commit: "[P-Reinforce] Mega Batch 2 - Wikified Atomic Design Pattern"
- **정책 변화:** Design & Experience 카테고리의 전문성 확보 및 링크 밀도 최적화.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[UI 컴포넌트]], [[관심사의 분리]]
- **Projects/Contexts:** [[프론트엔드 개발]]
- **Related Topics:** UI 컴포넌트, 관심사의 분리
- **Projects/Contexts:** 프론트엔드 개발
- **Contradictions/Notes:** 소스에서는 Atomic Design Pattern을 도입할 때 atoms, molecules, organisms 같은 이름과 단순한 구조적 분리에 집착하기보다는, 컴포넌트를 세밀하게 나눌 수 있는 '기준'을 마련하여 복잡성을 정돈하는 것이 이 패턴의 주요한 역할이라고 강조합니다 [1].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/Atomic Design Pattern.md]]
---
@@ -1,12 +1,12 @@
---
id: P-REINFORCE-AI-BDD
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.98
tags: [BDD, Behavior Driven Development, TDD, Agile, Gherkin]
last_reinforced: 2026-04-20
---
# [[Behavior-Driven-Development-(BDD)]] (행동 중심 개발)
# Behavior-Driven-Development-(BDD) (행동 중심 개발)
## 📌 한 줄 통찰 (The Karpathy Summary)
> "코딩하기 전에 대화부터 하라." 기획자, 디자이너, 개발자가 모여 사용자의 행동 시나리오(Given/When/Then)를 명확히 정의하고, 이를 검증하는 테스트 코드를 먼저 작성하며 개발하는 협업 중심 방법론이다.
@@ -23,5 +23,5 @@ last_reinforced: 2026-04-20
- BDD는 초기 시나리오 작성에 시간이 많이 든다. 하지만 개발 중반 이후 발생하는 '기획 번복'과 '커뮤니케이션 미스'로 인한 손실을 생각하면, 장기적으로는 반드시 이득이 남는 고수익 투자다.
## 🔗 지식 연결 (Graph)
- Related: [[Test-Driven-Development-(TDD)]] , [[Agile-Software-Development]]
- Strategy: [[User-Experience-Design]]
- Related: Test-Driven-Development-(TDD) , Agile-Software-Development
- Strategy: User-Experience-Design
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-BIZ-STRATEGY
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.98
tags: [Business Strategy, Market Analysis, Competitive Advantage, Innovation]
last_reinforced: 2026-04-20
@@ -23,5 +23,5 @@ last_reinforced: 2026-04-20
- 현대의 전략은 '고정된 계획'이 아니라 '유연한 적응'이다. AI 시대에는 데이터 피드백 루프를 통해 전략을 실시간으로 수정하는 'Agile Strategy'가 전통적인 5개년 계획을 대체하고 있다.
## 🔗 지식 연결 (Graph)
- Related: [[Business-Driven-Security]] , [[Innovation-Management]]
- Strategy: [[User-Experience-Design]]
- Related: Business-Driven-Security , Innovation-Management
- Strategy: User-Experience-Design
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-E4F919
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -30,11 +30,11 @@ github_commit: "[P-Reinforce] Continuous Worker - Code Formatting"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Linter]], [[Prettier]], [[Code Stylometry]], [[Code Readability]]
- **Projects/Contexts:** [[Automated Code Governance]], [[CI/CD Pipeline]]
- **Related Topics:** Linter, [[Prettier]], Code Stylometry, Code Readability
- **Projects/Contexts:** Automated Code Governance, CI/CD Pipeline
- **Contradictions/Notes:** ESLint와 같은 Linter 도구 내에도 자체적인 포맷팅 규칙이 존재하여 Prettier와 동시 사용 시 규칙 충돌(Infinite feedback loop)이 일어날 수 있습니다. 따라서 Linter의 포맷팅 기능을 끄고 이를 Prettier에 전담시키는 구성 최적화가 필수적입니다 [12, 18].
---
*Last updated: 2026-04-19*
- Raw Source: [[00_Raw/2026-04-20/Code Formatting.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-912710
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -28,10 +28,10 @@ github_commit: "[P-Reinforce] Continuous Worker - FSD (Feature-Sliced Design)"
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[단일 책임 원칙 (SRP)]], [[컴포넌트 기반 아키텍처]]
- **Projects/Contexts:** [[대규모 프론트엔드 프로젝트 아키텍처 및 폴더 구조 설계]]
- **Projects/Contexts:** 대규모 프론트엔드 프로젝트 아키텍처 및 폴더 구조 설계
- **Contradictions/Notes:** 소스에서는 FSD가 기능 간 결합도를 줄이고 유지보수를 돕는 훌륭한 표준이지만, 모든 상황에서 완벽한 정답은 아니라고 주장합니다. 프로젝트의 크기나 특성에 따라 오히려 기존의 단순한 폴더 구조가 더 적합할 수도 있으므로 프로젝트 상황에 맞는 유연한 폴더 구조 적용을 권장합니다.
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/FSD (Feature-Sliced Design).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-925C5C
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -26,11 +26,11 @@ github_commit: "[P-Reinforce] Continuous Worker - Feature-Sliced Design"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리(Separation of Concerns)]], [[멘탈 모델]]
- **Related Topics:** [[관심사의 분리(Separation of Concerns)]], 멘탈 모델
- **Projects/Contexts:** [[대규모 프론트엔드 프로젝트]]
- **Contradictions/Notes:** FSD 아키텍처는 대규모 프로젝트의 복잡성 관리에 유용하지만, 모든 프로젝트에서 완벽한 해결책은 아니며 상황과 규모에 따라 오히려 기존의 폴더 구조가 더 효율적일 수도 있습니다.
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/Feature-Sliced Design.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-4CFD51
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -24,11 +24,11 @@ github_commit: "[P-Reinforce] Continuous Worker - GitHub Actions"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[CI/CD]], [[Static Application Security Testing (SAST)]], [[Supply Chain Attack]]
- **Projects/Contexts:** [[Snyk]], [[Endor Labs]]
- **Related Topics:** CI/CD, [[Static Application Security Testing (SAST)]], Supply Chain Attack
- **Projects/Contexts:** Snyk, Endor Labs
- **Contradictions/Notes:** 소스에 GitHub Actions 자체의 동작 원리, 문법, 고유 기능 등에 대한 세부 정보는 전무하며, 단순히 외부 보안 솔루션 연동을 위한 파이프라인 환경 및 공급망 공격 사례의 일부로만 등장합니다.
---
*Last updated: 2026-04-19*
- Raw Source: [[00_Raw/2026-04-20/GitHub Actions.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-317AB6
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -23,11 +23,11 @@ github_commit: "[P-Reinforce] Continuous Worker - Interface Segregation Principl
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[SOLID Design Principles]], [[Single Responsibility Principle (SRP)]], [[Facade Pattern]]
- **Projects/Contexts:** [[TypeScript/JavaScript Architecture]], [[Toss Front SDK]]
- **Related Topics:** SOLID Design Principles, Single Responsibility Principle (SRP), Facade Pattern
- **Projects/Contexts:** TypeScript/JavaScript Architecture, Toss Front SDK
- **Contradictions/Notes:** 소스 내에 ISP에 반대되는 주장은 없습니다. 추가적인 참고 사항으로, 소스는 인터페이스에 여러 도메인 동사가 존재할 경우 이를 분리하는 기준으로 삼으라고 조언합니다 [3].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/Interface Segregation Principle (ISP).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-B068E2
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -30,12 +30,12 @@ github_commit: "[P-Reinforce] Continuous Worker - React Performance Optimization
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[React 19 Compiler]], [[재조정 (Reconciliation)]], [[상태 관리 최적화 (Zustand, Jotai, Valtio)]], [[Code Splitting & Lazy Loading]], [[React Server Components (RSC)]]
- **Projects/Contexts:** [[대규모 E-commerce 및 대시보드 애플리케이션 구축]], [[고성능 멀티스레드 React 앱 아키텍처]], [[Next.js 기반 App Router 마이그레이션]]
- **Related Topics:** [[React 19 Compiler]], [[재조정 (Reconciliation)]], 상태 관리 최적화 (Zustand, Jotai, Valtio), Code Splitting & Lazy Loading, [[React Server Components (RSC)]]
- **Projects/Contexts:** 대규모 E-commerce 및 대시보드 애플리케이션 구축, [[고성능 멀티스레드 React 앱 아키텍처]], Next.js 기반 App Router 마이그레이션
- **Contradictions/Notes:** 많은 개발자들이 컴포넌트가 느려지면 습관적으로 `useMemo``React.memo`를 추가(Premature Memoization)하지만, 메모이제이션 자체에도 얕은 비교(Shallow Compare)라는 오버헤드가 발생합니다. 렌더링 자체가 빠르고 프롭스 변경이 빈번한 단순 컴포넌트에 이를 남용하면 오히려 메모리와 연산 자원만 낭비하므로 반드시 React DevTools Profiler로 측정한 후 적용해야 합니다. 또한 React 19 컴파일러가 아무리 자동화를 해주어도, 무분별한 상태 구조 등 근본적인 아키텍처 설계 결함을 고쳐주지는 않습니다.
---
_Last updated: 2026-04-14_
- Raw Source: [[00_Raw/2026-04-20/React Performance Optimization.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-3FAE48
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -29,11 +29,11 @@ github_commit: "[P-Reinforce] Continuous Worker - React 상태 관리 (React Sta
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Discriminated Unions]], [[Immutability]], [[State Machine Pattern]]
- **Projects/Contexts:** [[Redux-style Reducers]], [[Context API]]
- **Related Topics:** [[Discriminated Unions]], Immutability, State Machine Pattern
- **Projects/Contexts:** Redux-style Reducers, [[Context API]]
- **Contradictions/Notes:** 소스 문서는 React 프레임워크 자체의 상태 관리 동작 원리(예: Virtual DOM과의 관계, 훅의 내부 원리 등)를 깊이 있게 다루기보다는, TypeScript의 타입 시스템(구분된 유니언, 불변성 등)을 React 상태 관리에 어떻게 접목하여 안정성을 높이는지에 초점이 맞추어져 있습니다.
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/React 상태 관리 (React State Management).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-3E04B1
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -24,11 +24,11 @@ github_commit: "[P-Reinforce] Continuous Worker - React 상태 관리 및 API
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Discriminated Unions]], [[State Machine Pattern]], [[TypeScript]]
- **Projects/Contexts:** [[비동기 작업 패턴(Async Operations Pattern)]], [[Redux 스타일 리듀서(Redux-style reducers)]]
- **Related Topics:** [[Discriminated Unions]], State Machine Pattern, TypeScript
- **Projects/Contexts:** 비동기 작업 패턴(Async Operations Pattern), Redux 스타일 리듀서(Redux-style reducers)
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (React 상태 관리 및 API 응답 처리와 관련하여 소스 간의 상충되는 주장이 포함되어 있지 않습니다.)
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/React 상태 관리 및 API 응답 처리.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-F45907
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -25,11 +25,11 @@ github_commit: "[P-Reinforce] Continuous Worker - React 컴포넌트 Props 검
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Discriminated Unions]], [[Exclusive Props]], [[Excess Property Checking]], [[Zod 런타임 검증]], [[satisfies 연산자]]
- **Projects/Contexts:** [[React 상태 및 Props 관리]], [[외부 API 데이터 연동 컴포넌트]]
- **Related Topics:** [[Discriminated Unions]], Exclusive Props, [[Excess Property Checking]], Zod 런타임 검증, [[satisfies 연산자]]
- **Projects/Contexts:** React 상태 및 Props 관리, 외부 API 데이터 연동 컴포넌트
- **Contradictions/Notes:** TypeScript의 컴파일 타임 검사는 무결성을 보장하지만, 런타임에 외부(API, 설정 파일 등)에서 주입되는 잘못된 Props 데이터까지는 막아주지 못하므로 외부 데이터 연동 컴포넌트에서는 런타임 검증이 동반되어야 합니다 [4].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/React 컴포넌트 Props 검증.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-8514DD
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -22,11 +22,11 @@ github_commit: "[P-Reinforce] Continuous Worker - Redux 등 상태 관리 (State
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[불변성 (Immutability)]], [[Readonly 타입]]
- **Projects/Contexts:** [[TypeScript 기반 React 애플리케이션의 Redux 스타일 리듀서 구현]]
- **Related Topics:** 식별 가능한 유니온 (Discriminated Unions), [[불변성 (Immutability)]], Readonly 타입
- **Projects/Contexts:** TypeScript 기반 React 애플리케이션의 Redux 스타일 리듀서 구현
- **Contradictions/Notes:** 소스에서는 Redux 라이브러리 자체의 세부적인 API나 동작 원리보다는, TypeScript의 강력한 타입 시스템(식별 가능한 유니온, Readonly)을 결합하여 상태 관리의 복잡성과 부작용을 통제하는 아키텍처적 관점이 주로 강조되어 있습니다 [1, 3, 4, 7].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/Redux 등 상태 관리 (State Management).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-EFAFFE
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -22,11 +22,11 @@ github_commit: "[P-Reinforce] Continuous Worker - Redux 스타일 리듀서 및
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Discriminated Unions]], [[Type Narrowing]]
- **Projects/Contexts:** [[상태 관리 및 프레임워크의 액션 처리]]
- **Related Topics:** [[Discriminated Unions]], Type Narrowing
- **Projects/Contexts:** 상태 관리 및 프레임워크의 액션 처리
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. 소스는 Redux 자체에 대한 깊은 설명보다는 TypeScript의 타입 시스템을 설명하면서 그 예시로만 Redux를 간략하게 다루고 있습니다.
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/Redux 스타일 리듀서 및 액션 관리.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-F26CB3
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -22,11 +22,11 @@ github_commit: "[P-Reinforce] Continuous Worker - Snyk Open Source"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[SCA (Software Composition Analysis)]], [[Snyk Code]], [[서드파티 종속성 (Third-party dependencies)]], [[CVE (Common Vulnerabilities and Exposures)]]
- **Projects/Contexts:** [[Snyk Security Platform]]
- **Related Topics:** SCA (Software Composition Analysis), Snyk Code, 서드파티 종속성 (Third-party dependencies), CVE (Common Vulnerabilities and Exposures)
- **Projects/Contexts:** Snyk Security Platform
- **Contradictions/Notes:** 소스의 내용 간에 특별한 모순은 발견되지 않았습니다. 소스는 Snyk Open Source(SCA)와 Snyk Code(SAST)가 경쟁 관계가 아니라 완전히 다른 영역을 검사하며, 강력한 보안 태세를 위해 상호 보완적으로 사용되어야 한다는 점을 거듭 강조합니다 [2, 3, 5].
---
*Last updated: 2026-04-19*
- Raw Source: [[00_Raw/2026-04-20/Snyk Open Source.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-5A7457
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -31,12 +31,12 @@ github_commit: "[P-Reinforce] Continuous Worker - Tree Shaking (번들 크기
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Code Splitting & Lazy Loading]], [[React Performance Optimization]], [[Webpack 번들 분석기 (webpack-bundle-analyzer)]], [[First Contentful Paint (FCP) 개선]]
- **Projects/Contexts:** [[대규모 React 프론트엔드 최적화]], [[모바일 웹 성능 향상 프로젝트]]
- **Related Topics:** Code Splitting & Lazy Loading, [[React Performance Optimization]], Webpack 번들 분석기 (webpack-bundle-analyzer), First Contentful Paint (FCP) 개선
- **Projects/Contexts:** 대규모 React 프론트엔드 최적화, 모바일 웹 성능 향상 프로젝트
- **Contradictions/Notes:** 모듈을 가져올 때 구조 분해 할당(예: `import { debounce } from 'lodash'`)을 하더라도 해당 라이브러리가 본래 ES6 모듈 기반으로 작성되지 않았다면 전체 코드가 번들에 포함될 수 있습니다. 따라서 `lodash` 대신 Tree Shaking이 지원되는 `lodash-es`를 사용하는 등, 종속성을 추가할 때 라이브러리 자체의 지원 여부를 확인하는 것이 매우 중요합니다.
---
_Last updated: 2026-04-14_
- Raw Source: [[00_Raw/2026-04-20/Tree Shaking (번들 크기 최적화).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-D2A4B8
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -22,11 +22,11 @@ github_commit: "[P-Reinforce] Continuous Worker - Type Alias"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Interface]], [[Union Types]], [[Intersection Types]]
- **Projects/Contexts:** [[TypeScript Type System 설계]], [[대규모 애플리케이션의 도메인 모델링]]
- **Related Topics:** Interface, [[Union Types]], Intersection Types
- **Projects/Contexts:** TypeScript Type System 설계, 대규모 애플리케이션의 도메인 모델링
- **Contradictions/Notes:** 소스 내 개발자 커뮤니티에서는 Type Alias와 Interface의 사용을 두고 뚜렷한 논쟁이 존재한다. 일부 개발자들은 선언 병합으로 인한 잠재적 오류를 피하고 일관성을 유지하기 위해 전적으로 Type Alias만 사용할 것을 주장한다 [2, 4, 11]. 반면, TypeScript 공식 가이드 및 다른 개발자들은 컴파일러 캐싱에 따른 성능 최적화와 에러 메시지의 직관성(불투명한 이름 표시)을 이유로 Interface를 기본으로 사용해야 한다고 반론한다 [7, 12-15].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/Type Alias.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-D3F069
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -23,11 +23,11 @@ github_commit: "[P-Reinforce] Continuous Worker - Type Declaration"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Type Alias]], [[Interface]], [[Type Assertion]], [[Declaration Merging]], [[Type Inference]]
- **Projects/Contexts:** [[TypeScript Type System]], [[TypeScript Best Practices]]
- **Related Topics:** [[Type Alias]], Interface, Type Assertion, Declaration Merging, Type Inference
- **Projects/Contexts:** TypeScript Type System, TypeScript Best Practices
- **Contradictions/Notes:** 객체 타입을 선언할 때 `interface``type` 중 어느 것을 사용할지에 대한 개발자 간의 선호도 논쟁이 존재한다. 일부는 선언 병합의 이점과 성능 최적화를 위해 `interface`를 선호하지만[8-10], 다른 진영에서는 의도치 않은 선언 병합에 의한 오작동을 막고 오류를 명확히 잡기 위해 `type` 선언을 엄격히 사용하는 것을 지향한다[6, 11].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/Type Declaration.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-6ECC4D
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -30,11 +30,11 @@ github_commit: "[P-Reinforce] Continuous Worker - TypeScript 인터페이스 및
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[과잉 속성 체크 (Excess Property Checking)]], [[재귀적 불변성 (DeepReadonly)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[브랜디드 타입 (Branded Types)]], [[SOLID 원칙]]
- **Related Topics:** 구조적 타이핑 (Structural Typing), [[과잉 속성 체크 (Excess Property Checking)]], [[재귀적 불변성 (DeepReadonly)]], 식별 가능한 유니온 (Discriminated Unions), [[브랜디드 타입 (Branded Types)]], [[SOLID 원칙]]
- **Projects/Contexts:** [[Toss Front SDK의 Facade 패턴 적용 사례]]
- **Contradictions/Notes:** TypeScript의 구조적 타이핑은 최소 요건만 충족하면 호환성을 허용하므로 매우 유연하지만, 이메일 주소와 이름이 같은 `string`으로 취급되는 등 "기본 타입에의 집착(Primitive Obsession)" 문제를 야기한다 [11]. 이를 방어하기 위해 컴파일 시점에만 존재하는 고유 속성을 부여하는 브랜디드 타입(Branded Types)을 사용하여 데이터의 무분별한 혼용을 차단해야 한다 [10, 11].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/TypeScript 인터페이스 및 시스템 보호 아키텍처 설계.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-3D0990
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -22,11 +22,11 @@ github_commit: "[P-Reinforce] Continuous Worker - TypeScript 컴파일러 캐싱
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[인터페이스 확장(Interface Extends)]], [[교집합 타입(Intersection Types)]]
- **Projects/Contexts:** [[TypeScript Performance Guide]]
- **Related Topics:** 인터페이스 확장(Interface Extends), 교집합 타입(Intersection Types)
- **Projects/Contexts:** TypeScript Performance Guide
- **Contradictions/Notes:** 인터페이스 간의 타입 관계는 이름 기반으로 캐싱되어 성능상 이점을 제공하지만, 교집합 타입은 전체가 캐싱되지 않고 사용할 때마다 평탄화 및 재계산을 거쳐야 한다는 구조적 차이가 존재합니다 [3].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/TypeScript 컴파일러 캐싱 최적화.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-08AE3A
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -36,11 +36,11 @@ github_commit: "[P-Reinforce] Continuous Worker - TypeScript의 안전한 인터
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[구조적 타이핑]], [[과잉 속성 체크(EPC)]], [[식별 가능한 유니온]], [[브랜디드 타입]], [[불변성(Immutability)]]
- **Projects/Contexts:** [[대규모 애플리케이션 개발]], [[프론트엔드 아키텍처 및 SDK 설계]]
- **Related Topics:** [[구조적 타이핑]], [[과잉 속성 체크(EPC)]], [[식별 가능한 유니온]], 브랜디드 타입, [[불변성(Immutability)]]
- **Projects/Contexts:** 대규모 애플리케이션 개발, 프론트엔드 아키텍처 및 SDK 설계
- **Contradictions/Notes:** `type``interface`의 사용 지침과 관련하여, TypeScript 성능과 캐싱을 고려해 객체 확장에 `interface extends`를 권장하는 측면과 [4, 14], 선언 병합(Declaration Merging)으로 인한 의도치 않은 타입 변경을 방지하기 위해 보다 엄격한 `type`의 사용을 선호하는 개발자들의 의견이 대립하는 사례가 존재합니다 [15, 17, 34, 35].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/TypeScript의 안전한 인터페이스 설계.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-844A65
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -37,11 +37,11 @@ TypeScript의 객체 타입은 명목적 타이핑(Nominal Typing)과 달리 명
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[초과 속성 검사 (Excess Property Checking)]], [[선언 병합 (Declaration Merging)]], [[satisfies 연산자]]
- **Projects/Contexts:** [[대규모 TypeScript 애플리케이션 아키텍처 구축]], [[SOLID 원칙 기반의 타입 시스템 설계]]
- **Related Topics:** 구조적 타이핑 (Structural Typing), [[초과 속성 검사 (Excess Property Checking)]], 선언 병합 (Declaration Merging), [[satisfies 연산자]]
- **Projects/Contexts:** 대규모 TypeScript 애플리케이션 아키텍처 구축, SOLID 원칙 기반의 타입 시스템 설계
- **Contradictions/Notes:** 소스 간 의견 대립이 존재합니다. 일부 개발자(소스 52, 138, 141)는 캐싱 성능 최적화와 외부 확장을 위한 선언 병합 기능 때문에 '인터페이스(Interface) 우선 사용'을 강력히 주장하지만, 또 다른 현업 개발자(소스 138, 140, 147)는 의도치 않은 선언 병합으로 인해 런타임 로직이 오염될 위험과 일관된 문법을 이유로 '모든 상황에서 타입 별칭(Type)만을 사용하는 규칙'을 조직 내에 강제하는 것이 장기 유지보수에 유리하다고 반박합니다.
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/TypeScript의 인터페이스 및 객체 타입 설계.md]]
---
@@ -1,13 +1,13 @@
---
id: P-REINFORCE-AI-042
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.95
tags: [ux, gamification, design, psychology]
last_reinforced: 2026-06-XX
github_commit: "[P-Reinforce] Processed UX_Gamification.md"
---
# [[UX - Gamification]] (사용자 경험 및 게이미피케이션)
# UX - Gamification (사용자 경험 및 게이미피케이션)
## 📌 한 줄 통찰 (The Karpathy Summary)
> 게임 메커니즘을 활용해 사용자의 동기를 유발하고 지속적인 참여를 설계하는 것은, 사용자 경험(UX)의 목표와 행동 심리학적 원리를 결합한 필수 전략이다.
@@ -28,7 +28,7 @@ github_commit: "[P-Reinforce] Processed UX_Gamification.md"
- **정책 변화:** 게이미피케이션의 남용은 '보상의 역효과 (Overjustification Effect)'를 초래할 수 있으므로, 보상이 학습 자체를 방해하지 않도록 신중하게 설계해야 한다.
## 🔗 지식 연결 (Graph)
- Parent: [[User Experience (UX) Design]]
- Related: [[Self-Determination Theory]] , [[Behavioral Economics]] , [[Gamification-Design]]
- Raw Source: [[00_Raw/UX_Gamification.md]]
- Parent: User Experience (UX) Design
- Related: Self-Determination Theory , Behavioral Economics , Gamification-Design
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-181AC7
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -30,11 +30,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 가상 DOM (Virtual DOM)"
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[재조정 (Reconciliation)]], [[React Performance Optimization]], [[불필요한 리렌더링 방지]]
- **Projects/Contexts:** [[대규모 데이터 렌더링 및 가상화 최적화]], [[고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처]]
- **Projects/Contexts:** [[대규모 데이터 렌더링 및 가상화 최적화]], 고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처
- **Contradictions/Notes:** 가상 DOM과 재조정 알고리즘은 일반적인 웹 애플리케이션의 선언적 UI 관리에는 압도적으로 훌륭하지만, 매 프레임 수만 개의 속성이 변해야 하는 3D 게임이나 무거운 애니메이션 환경에서는 오히려 가상 DOM을 비교하는 $O(n)$ 연산 자체가 프레임 저하(Lag)를 유발하는 치명적인 원인이 됩니다. 이러한 특수 환경에서는 가상 DOM을 우회하여 참조(`ref`)를 통한 **명령형 직접 조작(Imperative Manipulation)**을 사용해야만 60FPS를 달성할 수 있습니다.
---
_Last updated: 2026-04-15_
- Raw Source: [[00_Raw/2026-04-20/가상 DOM (Virtual DOM).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-28439B
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -31,11 +31,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 계층형 아키텍처 (Layere
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[N-Tier 아키텍처 (N-Tier Architecture)]], [[의존성 주입 (Dependency Injection)]], [[단일 책임 원칙 (SRP)]]
- **Projects/Contexts:** [[엔터프라이즈 애플리케이션]], [[웹 애플리케이션 3계층 시스템 (3-Tier Systems)]]
- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], N-Tier 아키텍처 (N-Tier Architecture), [[의존성 주입 (Dependency Injection)]], [[단일 책임 원칙 (SRP)]]
- **Projects/Contexts:** 엔터프라이즈 애플리케이션, 웹 애플리케이션 3계층 시스템 (3-Tier Systems)
- **Contradictions/Notes:** 소스에 따르면, 계층형 아키텍처는 명확한 분리를 제공해 주지만 레이어를 무겁게 만들면 오히려 시스템 관리가 비효율적일 수 있으므로, 계층을 얇게 유지(Keep layers thin)하고 인터페이스와 의존성 주입을 적극 활용하여 경계를 명확히 보호할 것을 권장하고 있습니다 [8, 9].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/계층형 아키텍처 (Layered Architecture).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-71F406
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -33,11 +33,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 대규모 프론트엔드 웹
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[Feature-Sliced Design (FSD)]], [[마이크로 프론트엔드 (Micro Frontends)]]
- **Projects/Contexts:** [[항해 DEV LAB 미니 학술회]] (FSD와 프론트엔드 관심사 분리에 관한 시각과 발표 내용이 논의된 맥락 [16]), [[스포티파이 (Spotify)]] (자율적인 기능 단위 '스쿼드' 모델과 프론트엔드를 분리하는 마이크로 프론트엔드를 결합하여 대규모 웹 앱 개발의 확장성을 획기적으로 개선한 실제 기업 사례 [17, 18])
- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[Feature-Sliced Design (FSD)]], 마이크로 프론트엔드 (Micro Frontends)
- **Projects/Contexts:** 항해 DEV LAB 미니 학술회 (FSD와 프론트엔드 관심사 분리에 관한 시각과 발표 내용이 논의된 맥락 [16]), 스포티파이 (Spotify) (자율적인 기능 단위 '스쿼드' 모델과 프론트엔드를 분리하는 마이크로 프론트엔드를 결합하여 대규모 웹 앱 개발의 확장성을 획기적으로 개선한 실제 기업 사례 [17, 18])
- **Contradictions/Notes:** 소스에 따르면 폴더 구조 설계에 있어서 절대적으로 "이것이 정답"이라고 할 수 있는 완벽한 구조는 존재하지 않는다. 프로젝트의 특성과 규모, 팀의 요구사항, 그리고 시기에 따라 기능 중심, 역할 중심, 혹은 도메인 중심 등으로 유연하게 폴더 구조를 진화시키고 균형을 맞추는 것이 핵심이라고 조언한다 [11, 19].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/대규모 프론트엔드 웹 프로젝트 폴더 구조화.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-ADBB0E
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -25,10 +25,10 @@ github_commit: "[P-Reinforce] Continuous Worker - 도메인 주도 설계 (DDD)"
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[바운디드 컨텍스트 (Bounded Context)]], [[유비쿼터스 언어 (Ubiquitous Language)]], [[관심사의 분리 (Separation of Concerns)]], [[애그리거트 (Aggregates)]]
- **Projects/Contexts:** [[마이크로서비스 아키텍처 (MSA)]], [[복잡한 비즈니스 도메인 (금융, 헬스케어, 이커머스 등)]]
- **Projects/Contexts:** [[마이크로서비스 아키텍처 (MSA)]], 복잡한 비즈니스 도메인 (금융, 헬스케어, 이커머스 등)
- **Contradictions/Notes:** 소스 내용 간의 모순점은 발견되지 않았습니다. 다만, 도메인 주도 설계(DDD)는 비즈니스와 강하게 결합된 명확한 모델을 도출하는 데 큰 장점이 있지만, 도메인 전문가와의 긴밀한 협업과 깊은 모델링 분석 시간이 필요하여 구현 복잡도와 리소스 요구량이 높다는 특징이 있습니다 [5].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/도메인 주도 설계 (DDD).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-4DC206
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -26,11 +26,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 도메인 주도 설계(DDD)"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[보편적 언어(Ubiquitous Language)]], [[제한된 문맥(Bounded Contexts)]], [[마이크로서비스 아키텍처(MSA)]], [[관심사의 분리(SoC)]]
- **Projects/Contexts:** [[이벤트 스토밍(Event Storming)]], [[복잡한 비즈니스 도메인(금융, 의료, 이커머스 등)]]
- **Related Topics:** 보편적 언어(Ubiquitous Language), 제한된 문맥(Bounded Contexts), 마이크로서비스 아키텍처(MSA), [[관심사의 분리(SoC)]]
- **Projects/Contexts:** 이벤트 스토밍(Event Storming), 복잡한 비즈니스 도메인(금융, 의료, 이커머스 등)
- **Contradictions/Notes:** 도메인 주도 설계는 비즈니스 도메인을 명확하게 반영하고 강력한 기반을 제공하지만, 깊은 수준의 모델링과 조직적 협력이 필요하므로 구현 복잡성이 높고 상당한 리소스(도메인 전문가, 분석 시간 등)가 요구된다는 제약이 있습니다 [6].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/도메인 주도 설계(DDD).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-73EE30
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -27,11 +27,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 라이브러리 타입 선언
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[인터페이스(Interface)]], [[선언 병합(Declaration Merging)]], [[타입 별칭(Type Alias)]]
- **Projects/Contexts:** [[TypeScript 라이브러리 생태계 및 DefinitelyTyped]]
- **Related Topics:** 인터페이스(Interface), [[선언 병합(Declaration Merging)]], 타입 별칭(Type Alias)
- **Projects/Contexts:** TypeScript 라이브러리 생태계 및 DefinitelyTyped
- **Contradictions/Notes:** 소스에 따르면, 일반적인 애플리케이션 코드 작성 시에는 엄격한 관리가 가능한 타입 별칭(Type)을 선호하는 실무 의견이 많지만, 외부 라이브러리 사용자가 타입을 확장해야 하는 특수한 상황에서는 선언 병합이 가능한 인터페이스(Interface)가 절대적으로 더 적합하다는 뚜렷한 용도 차이를 보입니다 [1, 2, 5, 7].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/라이브러리 타입 선언 (d.ts) 확장.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-589F08
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -30,11 +30,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 몰입감 (Presence)"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Flow State]], [[Cognitive Load]], [[Immersion]], [[Virtual Reality (VR)]]
- **Projects/Contexts:** [[Mixed Reality (MR) Tasks]], [[VR Exergaming]]
- **Related Topics:** [[Flow State]], Cognitive Load, Immersion, Virtual Reality (VR)
- **Projects/Contexts:** Mixed Reality (MR) Tasks, VR Exergaming
- **Contradictions/Notes:** 소스에 따르면 높은 수준의 가상 몰입감(Virtual Presence)은 학습 성과와 참여도를 긍정적으로 향상시키지만, 가상 콘텐츠를 처리하기 위한 정신적 노력이 요구되어 필연적으로 인지 부하(Cognitive Load)를 증가시킨다는 이중적 특성을 지닙니다 [3, 10].
---
*Last updated: 2026-04-19*
- Raw Source: [[00_Raw/2026-04-20/몰입감 (Presence).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-7B2713
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -23,11 +23,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 바운디드 컨텍스트 (Bou
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[도메인 주도 설계 (Domain-Driven Design, DDD)]], [[보편적 언어 (Ubiquitous Language)]], [[마이크로서비스 아키텍처 (Microservices Architecture)]], [[관심사의 분리 (Separation of Concerns, SoC)]]
- **Related Topics:** 도메인 주도 설계 (Domain-Driven Design, DDD), [[보편적 언어 (Ubiquitous Language)]], [[마이크로서비스 아키텍처 (Microservices Architecture)]], 관심사의 분리 (Separation of Concerns, SoC)
- **Projects/Contexts:** 복잡한 비즈니스 도메인 모델링 [1], 객체 지향 및 모듈러 소프트웨어 시스템 설계 [3, 5], 마이크로서비스로의 서비스 분리 및 마이그레이션 [2]
- **Contradictions/Notes:** 소스 내에 바운디드 컨텍스트의 효용이나 개념에 대한 상반된 주장은 존재하지 않으며, 일관되게 시스템 복잡성 완화와 마이크로서비스 확장을 위한 핵심 기반으로 설명되고 있습니다.
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/바운디드 컨텍스트 (Bounded Context).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-DC2EFA
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -29,12 +29,12 @@ github_commit: "[P-Reinforce] Continuous Worker - 반응형 윈도우 리사이
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Throttling & Debouncing]], [[React Performance Optimization]], [[Memory Leak Prevention (메모리 누수 방지)]], [[useEffect 클린업(Cleanup)]]
- **Projects/Contexts:** [[반응형 3D 캔버스(Three.js/R3F) 크기 최적화]], [[실시간 데이터 대시보드 레이아웃 조절 시스템]]
- **Related Topics:** Throttling & Debouncing, [[React Performance Optimization]], Memory Leak Prevention (메모리 누수 방지), [[useEffect 클린업(Cleanup)]]
- **Projects/Contexts:** 반응형 3D 캔버스(Three.js/R3F) 크기 최적화, [[실시간 데이터 대시보드 레이아웃 조절 시스템]]
- **Contradictions/Notes:** 단순히 윈도우 크기에 맞춰 CSS 요소의 크기나 배치를 조정하는 것이 목적이라면, 자바스크립트의 `resize` 이벤트를 아예 사용하지 않고 CSS의 미디어 쿼리(Media Queries)나 상대 단위(`vw`, `vh`, `100%`)를 사용하는 것이 렌더링 파이프라인 성능 측면에서 가장 비용이 낮고 완벽한 방법입니다. 자바스크립트 이벤트는 캔버스 렌더러 리사이즈나 복잡한 가상화 리스트(Virtualization) 재계산 등 CSS만으로 해결할 수 없는 경우에만 제한적으로 사용해야 합니다.
---
_Last updated: 2026-04-14_
- Raw Source: [[00_Raw/2026-04-20/반응형 윈도우 리사이즈(Resize) 이벤트 처리.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-C7F096
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -22,11 +22,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 비동기 데이터 패칭 (As
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[상태 머신 (State Machine Pattern)]], [[런타임 유효성 검사 (Runtime Validation)]]
- **Projects/Contexts:** [[API 응답 처리 (API Response Handling)]], [[비동기 UI 상태 관리 (Async UI State)]]
- **Related Topics:** 식별 가능한 유니온 (Discriminated Unions), 상태 머신 (State Machine Pattern), 런타임 유효성 검사 (Runtime Validation)
- **Projects/Contexts:** API 응답 처리 (API Response Handling), 비동기 UI 상태 관리 (Async UI State)
- **Contradictions/Notes:** 소스 내에서 비동기 데이터 패칭 패턴 자체에 대한 상충되는 의견은 없으나, 타입스크립트의 구조적 타이핑 특성상 컴파일 타임의 에러 방지만으로는 외부 비동기 데이터의 무결성을 완벽히 보장할 수 없다는 한계가 존재합니다. 따라서 외부 API나 설정 파일에서 전달받는 비동기 상태 데이터는 반드시 런타임 유효성 검사를 병행해야 한다고 강조하고 있습니다 [6, 7]. (소스에 비동기 데이터 패칭의 구체적인 코드 구현 예시 정보는 일부 누락되어 있어 관련 정보가 부족합니다.)
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/비동기 데이터 패칭 (Async Operations Pattern).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-58EC09
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -22,11 +22,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 상태 관리(State Management
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[식별 가능한 유니온(Discriminated Unions)]], [[불변성(Immutability)]], [[상태 기계(State Machine)]], [[리듀서(Reducer)]]
- **Projects/Contexts:** [[React 프론트엔드 개발]], [[Redux 아키텍처]]
- **Related Topics:** 식별 가능한 유니온(Discriminated Unions), [[불변성(Immutability)]], 상태 기계(State Machine), 리듀서(Reducer)
- **Projects/Contexts:** React 프론트엔드 개발, Redux 아키텍처
- **Contradictions/Notes:** 소스 전반에 걸쳐 상태 관리에 있어 불변성 유지(`readonly` 활용)와 타입 시스템(Discriminated Unions)을 통한 엄격한 상태 제어의 중요성에 동의하고 있으며, 상태 관리에 대한 상반된 주장이나 모순점은 발견되지 않았습니다.
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/상태 관리(State Management).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-D423C6
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -24,11 +24,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 상태 머신 (State Machine)
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[타입 안전성 (Type Safety)]]
- **Related Topics:** 식별 가능한 유니온 (Discriminated Unions), [[타입 안전성 (Type Safety)]]
- **Projects/Contexts:** [[React 상태 관리 (React State Management)]], [[비동기 데이터 패칭 (Async Operations Pattern)]]
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. 상태 머신 및 Redux 패턴 설계 지침을 다루기보다는, 타입스크립트의 '식별 가능한 유니온'이 활용되기 좋은 대표적인 사례(Use Case) 중 하나로서만 간략히 소개되어 있습니다.
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/상태 머신 (State Machine) 모델링 및 Redux 액션_리듀서 설계.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-BC8C33
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -24,11 +24,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 상태 모델링 (State Modeli
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[완전성 검사 (Exhaustiveness Checking)]], [[상태 머신 (State Machine)]]
- **Projects/Contexts:** [[API 응답 처리 (API Response Handling)]], [[폼 제출 워크플로우 (Form Submission Workflow)]]
- **Related Topics:** 식별 가능한 유니온 (Discriminated Unions), 완전성 검사 (Exhaustiveness Checking), 상태 머신 (State Machine)
- **Projects/Contexts:** API 응답 처리 (API Response Handling), 폼 제출 워크플로우 (Form Submission Workflow)
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/상태 모델링 (State Modeling).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-18CC73
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -23,11 +23,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 선언 병합(Declaration Merg
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[인터페이스(Interface)]], [[타입 별칭(Type Alias)]]
- **Projects/Contexts:** [[라이브러리 코드 작성]], [[TypeScript 타입 시스템]]
- **Related Topics:** 인터페이스(Interface), 타입 별칭(Type Alias)
- **Projects/Contexts:** 라이브러리 코드 작성, TypeScript 타입 시스템
- **Contradictions/Notes:** 소스에 따르면 라이브러리 제작 관점에서는 소비자에게 확장을 허용하는 매우 유용한 기능으로 평가받지만 [1, 4], 애플리케이션 개발 팀 관점에서는 의도치 않은 병합 버그를 유발할 수 있어 피해야 할 기능으로 강하게 반대되기도 합니다 [2, 8].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/선언 병합(Declaration Merging).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-6B386C
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -32,11 +32,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 소프트웨어 시스템 설
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Separation of Concerns (SoC)]], [[Clean Architecture]], [[Microservices Architecture]], [[SOLID Principles]]
- **Projects/Contexts:** [[Netflix Microservices & Cosmos Platform]], [[Feature-Sliced Design (FSD)]]
- **Related Topics:** Separation of Concerns (SoC), Clean Architecture, Microservices Architecture, SOLID Principles
- **Projects/Contexts:** Netflix Microservices & Cosmos Platform, [[Feature-Sliced Design (FSD)]]
- **Contradictions/Notes:** 마이크로서비스 아키텍처는 유연성과 독립적 배포를 제공하지만 분산 시스템 간의 통신, 배포의 복잡성, 메모리 오버헤드를 유발하므로 무조건적인 도입은 지양해야 합니다 [38, 39]. 또한 완벽한 관심사 분리를 위한 과도한 추상화(Over-engineering)나 너무 이른 계층 분리는 오히려 시스템을 복잡하게 만들어 가독성을 해치고 인지적 부하를 유발할 수 있으므로, 응집도와 결합도를 실무적 상황에 맞게 조율해야 합니다 [40-42].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/소프트웨어 시스템 설계 및 아키텍처 구축.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-BAC69B
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -31,12 +31,12 @@ github_commit: "[P-Reinforce] Continuous Worker - 실시간 데이터 대시보
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Throttling & Debouncing]], [[React 동시성 훅 (useTransition, useDeferredValue)]], [[상태 관리 최적화 (Zustand, Jotai, Valtio)]], [[Virtualization (리스트 가상화)]], [[Web Worker (웹 워커)]]
- **Projects/Contexts:** [[대용량 데이터 분석 플랫폼 및 모니터링 시스템]], [[고성능 금융/주식 실시간 거래 대시보드]]
- **Related Topics:** Throttling & Debouncing, [[React 동시성 훅 (useTransition, useDeferredValue)]], 상태 관리 최적화 (Zustand, Jotai, Valtio), Virtualization (리스트 가상화), [[Web Worker (웹 워커)]]
- **Projects/Contexts:** 대용량 데이터 분석 플랫폼 및 모니터링 시스템, 고성능 금융/주식 실시간 거래 대시보드
- **Contradictions/Notes:** React에 내장된 Context API는 테마나 로그인 정보처럼 가끔 변하는 데이터에는 훌륭하지만, 고빈도로 상태가 업데이트되는 실시간 대시보드에서는 성능을 조용히 갉아먹는 주범이 되므로 대안 상태 관리 도구가 필수적입니다.
---
_Last updated: 2026-04-15_
- Raw Source: [[00_Raw/2026-04-20/실시간 데이터 대시보드 레이아웃 조절 시스템.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-8E681E
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -30,11 +30,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 엔티티 (Entities)"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[도메인 주도 설계 (Domain-Driven Design)]], [[클린 아키텍처 (Clean Architecture)]], [[유스케이스 (Use Cases)]], [[값 객체 (Value Objects)]]
- **Projects/Contexts:** [[엔터프라이즈급 소프트웨어 아키텍처 설계]], [[VIPER 아키텍처 기반 iOS 애플리케이션 개발]]
- **Related Topics:** 도메인 주도 설계 (Domain-Driven Design), [[클린 아키텍처 (Clean Architecture)]], [[유스케이스 (Use Cases)]], 값 객체 (Value Objects)
- **Projects/Contexts:** 엔터프라이즈급 소프트웨어 아키텍처 설계, VIPER 아키텍처 기반 iOS 애플리케이션 개발
- **Contradictions/Notes:** 엔티티와 시스템의 요청 및 응답 모델은 많은 데이터를 공유하기 때문에 서로 참조하거나 결합하려는 유혹에 빠지기 쉽지만, 이는 장기적으로 공통 폐쇄 원칙을 위반하고 코드베이스에 혼란을 초래하므로 엄격히 분리해야 한다고 경고합니다 [14].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/엔티티 (Entities).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-57A5BA
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -30,11 +30,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 의존성 규칙 (Dependency R
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[클린 아키텍처 (Clean Architecture)]], [[의존성 역전 원칙 (Dependency Inversion Principle, DIP)]], [[엔티티 (Entities)]], [[유스케이스 (Use Cases)]]
- **Related Topics:** [[클린 아키텍처 (Clean Architecture)]], 의존성 역전 원칙 (Dependency Inversion Principle, DIP), [[엔티티 (Entities)]], [[유스케이스 (Use Cases)]]
- **Projects/Contexts:** [[엔터프라이즈 소프트웨어 시스템 설계]], [[모듈화 및 아키텍처 경계 설정]]
- **Contradictions/Notes:** 의존성 규칙을 엄격하게 준수하기 위해 완벽한 아키텍처 경계(쌍방향 다형적 인터페이스, 분리된 입/출력 데이터 구조 등)를 만드는 것은 초기 설정 및 유지보수 비용이 상당히 큽니다 [11]. 따라서 모든 상황에 이 규칙을 엄격히 적용하기보다는, 프로젝트의 규모에 따라 전략 패턴이나 퍼사드(Facade) 패턴을 활용한 부분적 경계(Partial Boundary)를 두거나 실무적 타협을 하는 경우도 존재합니다 [11-13].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/의존성 규칙 (Dependency Rule).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-FD8793
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -25,11 +25,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 인터페이스 분리 원칙
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[SOLID Principles]], [[Separation of Concerns (SoC)]], [[Object-Oriented Programming (OOP)]]
- **Projects/Contexts:** [[Clean Architecture]], [[Software System Design]]
- **Related Topics:** SOLID Principles, Separation of Concerns (SoC), Object-Oriented Programming (OOP)
- **Projects/Contexts:** Clean Architecture, Software System Design
- **Contradictions/Notes:** 주어진 소스 내에서 인터페이스 분리 원칙에 대한 모순된 주장은 발견되지 않으며, 모든 소스가 이 원칙이 관심사의 분리(SoC) 개념에 뿌리를 두고 있으며 모듈성과 시스템 유연성을 향상시킨다는 점에 동의하고 있습니다.
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/인터페이스 분리 원칙 (Interface Segregation Principle).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-EDDCE3
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -33,9 +33,9 @@ github_commit: "[P-Reinforce] Continuous Worker - 재조정 (Reconciliation)"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[가상 DOM (Virtual DOM)]], [[React 동시성 기능 (Concurrent Features)]], [[불필요한 리렌더링 방지]], [[명령형 조작 (Imperative Manipulation)]]
- **Related Topics:** [[가상 DOM (Virtual DOM)]], React 동시성 기능 (Concurrent Features), [[불필요한 리렌더링 방지]], 명령형 조작 (Imperative Manipulation)
- **Projects/Contexts:** [[고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처]], [[대규모 데이터 렌더링 및 가상화 최적화]]
- **Projects/Contexts:** 고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처, [[대규모 데이터 렌더링 및 가상화 최적화]]
- **Contradictions/Notes:** 재조정 알고리즘은 선언적 UI 관리를 가능하게 하는 훌륭한 기능이지만 만능은 아닙니다. Three.js(R3F) 기반의 게임이나 대규모 애니메이션 환경처럼 매 프레임 수만 개의 좌표나 속성이 변하는 경우, React의 재조정 과정을 거치면 성능이 붕괴되므로 `useFrame` 등을 활용해 참조(Ref)의 속성을 직접 조작(Direct/Imperative Mutation)하여 재조정을 우회하는 기법이 반드시 필요합니다.
@@ -43,5 +43,5 @@ github_commit: "[P-Reinforce] Continuous Worker - 재조정 (Reconciliation)"
---
_Last updated: 2026-04-15_
- Raw Source: [[00_Raw/2026-04-20/재조정 (Reconciliation).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-A8177A
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -33,11 +33,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 철벽 수비대_ - TypeScript
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[선언 병합 (Declaration Merging)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[브랜디드 타입 (Branded Types)]], [[satisfies 연산자]]
- **Projects/Contexts:** [[대규모 애플리케이션 개발]], [[도메인 기반 설계 (DDD)]]
- **Related Topics:** 구조적 타이핑 (Structural Typing), 선언 병합 (Declaration Merging), 식별 가능한 유니온 (Discriminated Unions), [[브랜디드 타입 (Branded Types)]], [[satisfies 연산자]]
- **Projects/Contexts:** 대규모 애플리케이션 개발, [[도메인 기반 설계 (DDD)]]
- **Contradictions/Notes:** 과잉 속성 체크(EPC)는 객체 리터럴을 직접 다룰 때만 활성화되어 간접 할당 시 우회될 수 있다는 취약점이 있으나, TypeScript 4.9부터 도입된 satisfies 연산자를 통해 이 문제를 해결하고 엄격한 속성 검사를 수행할 수 있습니다 [9, 10].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/철벽 수비대_ - TypeScript 타입 시스템 (인터페이스 설계).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-8EC391
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -20,9 +20,9 @@ github_commit: "[P-Reinforce] Continuous Worker - 치타 사람 이미지 프롬
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[VFX Particle Simulation]], [[Cinematic Sports Advertising]], [[Surrealism Concept Art]]
- **Related Topics:** VFX Particle Simulation, Cinematic Sports Advertising, Surrealism Concept Art
- **Projects/Contexts:** [[Sportswear Brand Campaign Visuals]]
- **Projects/Contexts:** Sportswear Brand Campaign Visuals
- **Contradictions/Notes:** 치타는 고체 형태의 동물이 아니라 수백만 개의 모래와 먼지로 이루어진 볼륨 시뮬레이션(Volumetric Simulation)이므로 경계면이 모래폭풍 속으로 자연스럽게 흩어지도록 연출 요망
@@ -30,5 +30,5 @@ github_commit: "[P-Reinforce] Continuous Worker - 치타 사람 이미지 프롬
---
_Last updated: 2026년 4월 14일_
- Raw Source: [[00_Raw/2026-04-20/치타 사람 이미지 프롬프트.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-F36267
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -28,11 +28,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 컴포넌트 기반 웹 프레
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리(Separation of Concerns)]], [[마이크로 프론트엔드(Micro Frontends)]], [[Feature-Sliced Design(FSD)]], [[단일 책임 원칙(SRP)]]
- **Projects/Contexts:** [[Spotify, Netflix, Amazon의 마이크로 프론트엔드 도입]], [[대규모 웹 애플리케이션의 폴더 구조 진화]]
- **Related Topics:** [[관심사의 분리(Separation of Concerns)]], 마이크로 프론트엔드(Micro Frontends), Feature-Sliced Design(FSD), [[단일 책임 원칙(SRP)]]
- **Projects/Contexts:** Spotify, Netflix, Amazon의 마이크로 프론트엔드 도입, 대규모 웹 애플리케이션의 폴더 구조 진화
- **Contradictions/Notes:** 컴포넌트 기반 아키텍처는 초기에 관심사 분리의 혁신으로 여겨졌으나, 점차 하나의 컴포넌트에 너무 많은 로직이 집중되며 독립성이 훼손되는 모순이 발생했습니다. 이를 해결하기 위해 기능 단위로 묶인 컴포넌트 내부에서 다시 데이터 로직과 뷰 로직의 역할을 나누는 계층적(Layer) 분리 방식이 재도입되었습니다 [4, 9, 12].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/컴포넌트 기반 웹 프레임워크 아키텍처 설계.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-0A3765
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -43,5 +43,5 @@ github_commit: "[P-Reinforce] Continuous Worker - 클린 아키텍처 (Clean Arc
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/클린 아키텍처 (Clean Architecture).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-2298F3
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -38,11 +38,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 클린 아키텍처(Clean Arch
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리(Separation of Concerns)]], [[의존성 역전 원칙(Dependency Inversion Principle)]], [[SOLID 원칙(SOLID Principles)]]
- **Projects/Contexts:** [[안드로이드 애플리케이션(Android Applications)]], [[iOS 애플리케이션의 VIPER 패턴(VIPER Architecture)]], [[ASP.NET Core 애플리케이션]], [[넷플릭스 마이크로서비스(Netflix Microservices)]]
- **Related Topics:** [[관심사의 분리(Separation of Concerns)]], 의존성 역전 원칙(Dependency Inversion Principle), SOLID 원칙(SOLID Principles)
- **Projects/Contexts:** 안드로이드 애플리케이션(Android Applications), iOS 애플리케이션의 VIPER 패턴(VIPER Architecture), ASP.NET Core 애플리케이션, 넷플릭스 마이크로서비스(Netflix Microservices)
- **Contradictions/Notes:** 소스 출처 "Complete Guide to Clean Architecture - GeeksforGeeks"는 클린 아키텍처가 시스템의 장기적인 유지보수성, 테스트 가능성, 유연성을 제공한다고 강조하지만, 동시에 도입 초기에는 여러 추상화 계층을 구축해야 하므로 초기 개발 시간이 증가하고 오버엔지니어링(Over-Engineering)에 빠질 위험이 있다고 지적합니다. 따라서 실용적인 관점과의 균형 유지가 필수적입니다 [21], [19].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/클린 아키텍처(Clean Architecture).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-417677
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -37,11 +37,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 클린 아키텍처"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리]], [[의존성 규칙]], [[의존성 역전 원칙]], [[SOLID 원칙]]
- **Projects/Contexts:** [[Netflix 마이크로서비스]], [[Android 애플리케이션 아키텍처]], [[VIPER 아키텍처]]
- **Related Topics:** 관심사의 분리, 의존성 규칙, 의존성 역전 원칙, [[SOLID 원칙]]
- **Projects/Contexts:** Netflix 마이크로서비스, Android 애플리케이션 아키텍처, VIPER 아키텍처
- **Contradictions/Notes:** 클린 아키텍처는 시스템의 유지보수성과 유연성을 극대화하지만, 동시에 여러 계층과 추상화의 추가로 인해 초기 개발 시간이 늘어나고 구조가 복잡해지는 '오버 엔지니어링'의 위험을 동반하므로 실용성과의 적절한 균형이 필요하다는 점을 주의해야 합니다 [18].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/클린 아키텍처.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-5D0418
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -31,11 +31,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 타입 가드 (Type Guards)"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Type Narrowing]], [[Union Types]], [[Type Predicates]], [[unknown type]]
- **Projects/Contexts:** [[외부 API의 불확실한(unknown) 데이터 검증 로직]], [[복잡한 유니온 타입 분기 처리]]
- **Related Topics:** Type Narrowing, [[Union Types]], Type Predicates, unknown type
- **Projects/Contexts:** 외부 API의 불확실한(unknown) 데이터 검증 로직, 복잡한 유니온 타입 분기 처리
- **Contradictions/Notes:** 사용자 정의 타입 가드는 타입 좁히기에 매우 유용하지만, TypeScript가 내부 판별 로직의 논리적 오류를 잡아주지 못하기 때문에 개발자의 부주의로 인해 타입 안정성이 훼손될 위험이 존재합니다 [5].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/타입 가드 (Type Guards).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-37A8A8
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -32,11 +32,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 타입 별칭 (Type Alias)"
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[인터페이스 (Interface)]], [[유니온 타입 (Union Types)]], [[구조적 타이핑 (Structural Typing)]], [[선언 병합 (Declaration Merging)]]
- **Related Topics:** 인터페이스 (Interface), 유니온 타입 (Union Types), 구조적 타이핑 (Structural Typing), 선언 병합 (Declaration Merging)
- **Projects/Contexts:** [[대규모 TypeScript 프로젝트의 컴파일 성능 최적화]], [[견고한 도메인 모델 및 API 계약 설계]]
- **Contradictions/Notes:** TypeScript 핸드북 및 성능 가이드라인은 컴파일러의 캐싱 이점과 성능 최적화를 이유로 객체 확장 시 교집합을 사용하는 타입 별칭보다 인터페이스 상속(extends)을 사용할 것을 권장합니다 [8-10]. 하지만 실무 현장에서는 의도치 않은 선언 병합을 방지하고 유연성을 얻고자 린팅(Linting) 규칙을 통해 인터페이스 사용을 아예 금지하고 타입 별칭(Type Alias)만을 전면적으로 사용하는 개발 팀들도 많아 명확한 대립이 존재합니다 [4, 6, 15].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/타입 별칭 (Type Alias).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-BF1A40
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -24,11 +24,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 테스트 용이성 (Testabili
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[의존성 주입 (Dependency Injection)]], [[클린 아키텍처 (Clean Architecture)]], [[테스트 더블 (Test Double)]]
- **Projects/Contexts:** [[소프트웨어 아키텍처 설계]], [[AI 시스템 아키텍처 개발]], [[마이크로서비스 아키텍처 구축]]
- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[의존성 주입 (Dependency Injection)]], [[클린 아키텍처 (Clean Architecture)]], 테스트 더블 (Test Double)
- **Projects/Contexts:** [[소프트웨어 아키텍처 설계]], AI 시스템 아키텍처 개발, 마이크로서비스 아키텍처 구축
- **Contradictions/Notes:** 모의 객체(Mock)와 스텁(Stub) 사용에 있어, 테스트를 단순하게 하고 외부 시스템으로부터 코드를 보호해 준다는 강력한 장점이 있지만, 너무 남용할 경우 코드가 실제와 다르게 동작할 수 있고 구현 세부 사항과 강하게 결합되어 테스트의 신뢰성을 떨어뜨릴 수 있다는 classicist 관점의 경고가 존재합니다 [19, 20].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/테스트 용이성 (Testability).md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-353103
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -23,11 +23,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 프론트엔드 컴포넌트
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리]], [[Feature-Sliced Design]], [[단일 책임 원칙 (SRP)]], [[Atomic Design Pattern]]
- **Related Topics:** 관심사의 분리, [[Feature-Sliced Design]], [[단일 책임 원칙 (SRP)]], [[Atomic Design Pattern]]
- **Projects/Contexts:** [[대규모 프론트엔드 웹 프로젝트 폴더 구조화]], [[컴포넌트 기반 웹 프레임워크 아키텍처 설계]]
- **Contradictions/Notes:** 초기 웹 개발은 HTML, CSS, JS라는 역할 중심의 계층 구조로 이루어졌으나, 컴포넌트 패러다임의 등장으로 기능 중심의 융합 구조로 변하였습니다 [1, 3]. 하지만 컴포넌트 비대화와 결합도 증가라는 복잡성 문제가 다시 발생함에 따라, 현대에는 컴포넌트 내외부를 다시 세분화된 역할과 기능(Feature) 단위로 분리하는 FSD 아키텍처 구조로 나아가는 진화 흐름을 보입니다 [2, 4, 7].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/프론트엔드 컴포넌트 구조화.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-F2362F
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -34,11 +34,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 프론트엔드 컴포넌트
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리 (SoC)]], [[단일 책임 원칙 (SRP)]], [[아토믹 디자인 패턴 (Atomic Design Pattern)]], [[단방향 데이터 흐름]], [[FSD (Feature-Sliced Design)]]
- **Projects/Contexts:** [[대규모 프론트엔드 애플리케이션 아키텍처 구축 및 리팩토링]]
- **Related Topics:** [[관심사의 분리 (SoC)]], [[단일 책임 원칙 (SRP)]], 아토믹 디자인 패턴 (Atomic Design Pattern), 단방향 데이터 흐름, [[FSD (Feature-Sliced Design)]]
- **Projects/Contexts:** 대규모 프론트엔드 애플리케이션 아키텍처 구축 및 리팩토링
- **Contradictions/Notes:** 소스에서는 시각적 형태가 비슷하다고 무작정 동일한 컴포넌트로 묶는 것을 프론트엔드 개발자들이 흔히 하는 실수로 지적합니다. 데이터(도메인)가 다를 경우 결합도가 급증하여 오히려 유지보수성이 저해되므로, UI 컴포넌트와 도메인 컴포넌트를 명확히 분리해야 한다고 강조합니다.
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/프론트엔드 컴포넌트 설계.md]]
---
@@ -1,6 +1,6 @@
---
id: P-REINFORCE-AUTO-21E1FE
category: "[[10_Wiki/💡 Topics/Design & Experience]]"
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
@@ -24,11 +24,11 @@ github_commit: "[P-Reinforce] Continuous Worker - 현대 웹 애플리케이션
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리(SoC)]], [[마이크로서비스 아키텍처]], [[마이크로 프론트엔드]], [[클린 아키텍처]], [[Feature-Sliced Design (FSD)]], [[API 우선 아키텍처]]
- **Projects/Contexts:** [[넷플릭스(Netflix) 마이크로서비스 도입]], [[스포티파이(Spotify) 스쿼드 모델 및 마이크로 프론트엔드]]
- **Related Topics:** [[관심사의 분리(SoC)]], 마이크로서비스 아키텍처, [[마이크로 프론트엔드]], [[클린 아키텍처]], [[Feature-Sliced Design (FSD)]], API 우선 아키텍처
- **Projects/Contexts:** 넷플릭스(Netflix) 마이크로서비스 도입, 스포티파이(Spotify) 스쿼드 모델 및 마이크로 프론트엔드
- **Contradictions/Notes:** 마이크로서비스나 모듈화를 통한 관심사의 분리는 개발 및 배포의 완벽한 독립성을 제공하는 것처럼 보이지만, 횡단 관심사(Cross-cutting concerns)나 공유 데이터 구조 변경 시에는 여러 서비스가 간접적으로 결합되어 파급 효과가 발생할 수 있다는 맹점이 존재한다 [34-36]. 또한, 과도한 계층 분리와 추상화는 네트워크 지연 시간 증가, 데이터 변환 오버헤드, 가독성 저하 등의 '오버엔지니어링'을 초래할 수 있으므로 프로젝트의 규모와 실용성에 맞춘 적절한 트레이드오프와 조율이 필요하다 [37-39].
---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/현대 웹 애플리케이션 설계.md]]
---