chore: Clean up 00_Raw directory by moving processed files to 00_Processed

00_Raw/00_Processed/Continuous Integration-Continuous Deployment (CI-CD).md

@@ -0,0 +1,20 @@
+# [[Continuous Integration/Continuous Deployment (CI/CD)]]
+
+## 📌 Brief Summary
+CI/CD(지속적 통합/지속적 배포)는 소프트웨어 개발에서 코드의 병합, 테스트 및 배포 과정을 자동화하는 파이프라인입니다 [1]. 프론트엔드 시스템에서 CI/CD는 코드가 메인 브랜치에 병합되기 전에 린팅, 포맷팅, 타입 검사 및 테스트를 자동으로 실행하여 코드 품질과 안정성을 보장합니다 [2, 3]. 또한 시각적 회귀 테스트 도구를 CI 파이프라인에 통합하여 의도치 않은 UI 버그가 프로덕션에 도달하는 것을 사전에 방지할 수 있습니다 [4, 5].
+
+## 📖 Core Content
+*   **자동화된 거버넌스 및 빌드 오류 방지**
+    현대적인 대규모 프론트엔드 시스템에서 CI/CD 파이프라인은 자동화된 거버넌스를 실행하는 핵심적인 역할을 합니다 [1]. 개발자가 코드를 커밋하기 전에 린팅, 포맷팅 및 타입 검사를 수행하여 고품질의 코드만 저장소에 들어가도록 보장합니다 [2]. 또한 로컬 환경(예: Windows, macOS)에서는 대소문자를 구분하지 않아 정상 동작하더라도, Linux 기반의 CI/CD 파이프라인에서는 파일 이름(PascalCase)과 임포트 구문(camelCase)의 대소문자 불일치로 인해 빌드 실패가 발생할 수 있으므로 이를 사전에 엄격히 검사합니다 [6].
+*   **Git 워크플로우와의 통합**
+    안정적인 협업을 위해 모든 기능 브랜치(Feature branch)의 코드는 동료의 리뷰와 CI/CD 검사를 모두 통과한 후에만 메인 브랜치로 병합되어야 합니다 [3, 7]. 소규모 팀이 성장함에 따라 기존 워크플로우에 CI 검사를 추가하여 안정성을 높일 수 있으며 [8], 트렁크 기반 개발(Trunk-based development) 워크플로우를 채택하려면 강력한 CI 환경이 필수적으로 뒷받침되어야 합니다 [9]. 작업 방식을 GitHub Flow로 마이그레이션할 때는 CI/CD 설정을 업데이트하여 메인 브랜치에서 직접 배포(Deploy)가 이루어지도록 구성해야 합니다 [10].
+*   **시각적 UI 테스트(Visual Testing) 파이프라인 연동**
+    Storybook과 같은 환경에서 개발된 UI 컴포넌트는 Happo나 Chromatic과 같은 시각적 회귀 테스트 도구를 통해 CI에 통합될 수 있습니다 [4, 5, 11]. CI 파이프라인에 해당 도구들을 추가하면, 풀 리퀘스트(Pull Request)가 생성될 때마다 자동으로 스크린샷을 캡처하고 시각적 변경 사항을 비교하는 리뷰 링크를 제공합니다 [5, 12]. 이를 통해 코드 변경으로 인한 UI 깨짐이나 접근성 위반(Accessibility violations) 문제를 병합 전에 차단할 수 있습니다 [5, 13, 14].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Git Workflow]], [[Trunk-Based Development]], [[Automated Governance]], [[Visual Regression Testing]]
+- **Projects/Contexts:** [[Scalable Frontend Systems]], [[Storybook Component Testing]]
+- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (소스 내에서 CI/CD의 역할이나 접근 방식에 대한 상충되는 주장은 발견되지 않았습니다.)
+
+---
+*Last updated: 2026-04-26*

00_Raw/00_Processed/Feature-Sliced Design (FSD).md

@@ -0,0 +1,19 @@
+# [[Feature-Sliced Design (FSD)]]
+
+## 📌 Brief Summary
+Feature-Sliced Design (FSD)은 프론트엔드 애플리케이션, 특히 대규모 React 프로젝트를 구축하기 위해 고안된 현대적인 아키텍처 방법론으로, 코드를 기술적인 역할이 아닌 범위(scope)와 비즈니스 책임(responsibility)에 따라 구성합니다 [1-3]. 이 방법론은 컴포넌트 기반 개발과 도메인 주도 설계(DDD)의 원칙을 결합하여 명확한 경계를 설정합니다 [1]. 또한 애플리케이션을 여러 계층(Layer)과 슬라이스(Slice)로 나누고 단방향 의존성 규칙과 공개 API(Public API) 규칙을 강제함으로써 결합도를 낮추고 유지보수성과 확장성을 크게 높이는 것을 목표로 합니다 [2, 4-6].
+
+## 📖 Core Content
+* **구조적 모델 (Layers, Slices, Segments):** FSD는 애플리케이션을 `app`(전역 설정 및 초기화), `pages`(라우팅 수준 컴포넌트), `widgets`(기능과 엔티티로 구성된 재사용 가능한 UI 블록), `features`(사용자 상호작용 및 비즈니스 워크플로우), `entities`(핵심 비즈니스 모델), `shared`(도메인에 구애받지 않는 재사용 가능한 유틸리티)와 같은 구체적 계층(Layers)으로 분류합니다 [2, 7, 8]. 각 계층 내에서는 특정 기능을 위한 개념적 경계인 '슬라이스(Slice)'와 논리, 컴포넌트 등을 더 세분화하는 '세그먼트(Segment)'로 나뉘어 구성됩니다 [6, 8].
+* **단방향 의존성 규칙 (Unidirectional Dependencies):** 상위 계층의 코드는 하위 계층에 의존하고 가져올 수 있지만, 하위 계층은 상위 계층에 의존할 수 없습니다 [2, 4]. 이 단일 제약 조건은 모듈 간의 순환 참조를 방지하고 아키텍처 내 규율을 강제하여 시스템 변경 시 파급 효과를 차단합니다 [4, 9]. ESLint와 같은 린팅(Linting) 도구를 통해 한 기능(Feature)이 다른 기능을 참조하는 것을 제한하는 방식으로 자동화할 수 있습니다 [10, 11].
+* **공개 API 및 캡슐화 (Public APIs and Encapsulation):** 각 슬라이스는 단일 진입점(주로 `index.ts`)을 노출하여 외부와 통신해야 합니다 [5, 12, 13]. 외부의 다른 모듈은 이 진입점을 통해서만 해당 코드를 가져올 수 있습니다. 이로 인해 내부 파일(특정 UI 요소 등)이 철저하게 캡슐화되며, 외부 의존성을 깨뜨리지 않고 모듈 내부를 안전하게 리팩토링할 수 있습니다 [12, 13].
+* **상태 관리의 위치 지정:** FSD는 특정 상태 관리 라이브러리(Context, Redux, Zustand 등)에 의존하지 않습니다 [14]. 대신 상태가 아키텍처적으로 어디에 위치해야 하는지만 정의합니다. 예를 들어 엔티티의 상태는 엔티티(entities) 계층에, 기능별 상호작용 상태는 기능(features) 계층에, 인프라의 전역 상태는 앱(app) 계층에 배치하여 상태 소유권을 명확히 합니다 [14].
+* **도입 시 학습 곡선과 고려사항:** 파일이나 컴포넌트 유형 위주로 개발하던 개발자가 '비즈니스 기능' 위주의 FSD 패러다임으로 전환할 때는 학습 곡선이 존재합니다 [15]. 특히 특정 컴포넌트가 '기능(Feature)'인지 '위젯(Widget)'인지 결정하는 등 경계를 찾는 의미론적 논의에서 오버헤드가 발생할 수 있습니다 [11]. 
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Frontend Folder Structure]], [[Clean Code Principles]], [[Domain-Driven Design (DDD)]], [[Component-Based Architecture]], [[State Management in React]], [[React Refactoring]]
+- **Projects/Contexts:** [[Scalable React Apps]], [[Enterprise-level Frontend Systems]], [[Monorepo Environments]]
+- **Contradictions/Notes:** FSD는 명확한 기능 분리를 강조하지만, 실제 개발자들은 '인증(Auth)'과 같은 교차 관심사(Cross-cutting concerns)가 발생할 때 경계를 찾는 것이 가장 어렵다고 지적합니다. 인증을 단일 기능으로 볼 것인지, 아니면 로그인, 회원가입, 비밀번호 찾기 등 여러 기능의 집합으로 쪼개야 하는지에 대한 설계상 딜레마가 생길 수 있습니다 [16-18]. 더불어 팀원들이 이 아키텍처를 완벽히 숙지하지 않으면, 오히려 모호한 모든 코드를 `/shared` 폴더에 몰아넣어 거대한 의존성 문제를 일으킬 위험이 있다는 실무자들의 경고도 있습니다 [11, 18].
+
+---
+*Last updated: 2026-04-26*