From 35d868b28d0ec8ea5d607f5e7c1deee211c2c254 Mon Sep 17 00:00:00 2001 From: Antigravity Agent Date: Sun, 26 Apr 2026 20:05:02 +0900 Subject: [PATCH] feat: Knowledge Gardening Milestone 420 (Batch #21) --- ...Hangar_Layout_Guardrails_Scroll_Islands.md | 105 ++++++++++++++++++ 00_Raw/Code Splitting and Lazy Loading.md | 29 +++++ .../Frontend App Development Architecture.md | 24 ++++ 00_Raw/Git Branching Strategies.md | 28 +++++ 00_Raw/Memory Leak Debugging.md | 30 +++++ 00_Raw/React Error Boundaries.md | 22 ++++ 00_Raw/React State Management.md | 33 ++++++ 10_Wiki/Topics/AI/Product-Thinking-in-AI.md | 29 +++++ .../Topics/AI/Productivity-Hacks-for-Devs.md | 29 +++++ .../Topics/AI/Profiling-and-Optimization.md | 29 +++++ .../AI/Project-Management-Best-Practices.md | 29 +++++ .../AI/Prompt-Engineering-Foundations.md | 29 +++++ .../Topics/AI/Proximal-Policy-Optimization.md | 28 +++++ 10_Wiki/Topics/AI/Pruning-Techniques.md | 28 +++++ 10_Wiki/Topics/AI/PyTorch-Foundations.md | 29 +++++ 10_Wiki/Topics/AI/PyTorch-Lightning.md | 28 +++++ 10_Wiki/Topics/AI/Python-for-Data-Science.md | 29 +++++ 10_Wiki/Topics/AI/Quantization-Foundations.md | 28 +++++ 10_Wiki/Topics/AI/Quantum-Machine-Learning.md | 28 +++++ 10_Wiki/Topics/AI/Queue-Management-Systems.md | 29 +++++ .../Topics/AI/RAG-and-Document-Retrieval.md | 28 +++++ .../Topics/AI/Random-Forest-Classifiers.md | 28 +++++ 10_Wiki/Topics/AI/Randomized-Algorithms.md | 27 +++++ 10_Wiki/Topics/AI/Ranking-Algorithms.md | 28 +++++ 10_Wiki/Topics/AI/Real-time-Data-Streaming.md | 28 +++++ 10_Wiki/Topics/AI/Recommendation-Systems.md | 29 +++++ .../Topics/AI/Recurrent-Neural-Networks.md | 28 +++++ 27 files changed, 839 insertions(+) create mode 100644 00_Raw/2026-04-26-Skybound_Hangar_Layout_Guardrails_Scroll_Islands.md create mode 100644 00_Raw/Code Splitting and Lazy Loading.md create mode 100644 00_Raw/Frontend App Development Architecture.md create mode 100644 00_Raw/Git Branching Strategies.md create mode 100644 00_Raw/Memory Leak Debugging.md create mode 100644 00_Raw/React Error Boundaries.md create mode 100644 00_Raw/React State Management.md create mode 100644 10_Wiki/Topics/AI/Product-Thinking-in-AI.md create mode 100644 10_Wiki/Topics/AI/Productivity-Hacks-for-Devs.md create mode 100644 10_Wiki/Topics/AI/Profiling-and-Optimization.md create mode 100644 10_Wiki/Topics/AI/Project-Management-Best-Practices.md create mode 100644 10_Wiki/Topics/AI/Prompt-Engineering-Foundations.md create mode 100644 10_Wiki/Topics/AI/Proximal-Policy-Optimization.md create mode 100644 10_Wiki/Topics/AI/Pruning-Techniques.md create mode 100644 10_Wiki/Topics/AI/PyTorch-Foundations.md create mode 100644 10_Wiki/Topics/AI/PyTorch-Lightning.md create mode 100644 10_Wiki/Topics/AI/Python-for-Data-Science.md create mode 100644 10_Wiki/Topics/AI/Quantization-Foundations.md create mode 100644 10_Wiki/Topics/AI/Quantum-Machine-Learning.md create mode 100644 10_Wiki/Topics/AI/Queue-Management-Systems.md create mode 100644 10_Wiki/Topics/AI/RAG-and-Document-Retrieval.md create mode 100644 10_Wiki/Topics/AI/Random-Forest-Classifiers.md create mode 100644 10_Wiki/Topics/AI/Randomized-Algorithms.md create mode 100644 10_Wiki/Topics/AI/Ranking-Algorithms.md create mode 100644 10_Wiki/Topics/AI/Real-time-Data-Streaming.md create mode 100644 10_Wiki/Topics/AI/Recommendation-Systems.md create mode 100644 10_Wiki/Topics/AI/Recurrent-Neural-Networks.md diff --git a/00_Raw/2026-04-26-Skybound_Hangar_Layout_Guardrails_Scroll_Islands.md b/00_Raw/2026-04-26-Skybound_Hangar_Layout_Guardrails_Scroll_Islands.md new file mode 100644 index 00000000..6c78fab7 --- /dev/null +++ b/00_Raw/2026-04-26-Skybound_Hangar_Layout_Guardrails_Scroll_Islands.md @@ -0,0 +1,105 @@ +# Skybound Hangar Layout Guardrails Scroll Islands + +작성일: 2026-04-26 17:24 KST + +## 요청 요약 + +- Mount Bays 목록이 전체적으로 확인되지 않고 하단이 잘린다. +- 이런 문제가 여러 UI에서 반복적으로 발생한다. +- 사용자가 하나씩 찾아서 수정 요청하기 어렵기 때문에 근본적으로 수정해야 한다. + +## 핵심 문제 + +행거 UI에는 `overflow: hidden`과 고정 높이 카드가 여러 곳에 섞여 있었다. + +특히 Loadout 화면의 Mount Bays는 다음 구조였다. + +- 부모 컬럼은 `overflow: hidden` +- 내부 슬롯은 고정 `min-height` +- 화면 높이가 줄어들면 마지막 슬롯이 부모 밖으로 밀림 +- 부모가 hidden이므로 사용자가 확인하거나 스크롤할 수 없음 + +이 문제는 Mount Bays만의 문제가 아니라, 장비 목록, 업그레이드 목록, 포지 목록처럼 콘텐츠량이 가변적인 UI 전반에서 반복될 수 있는 구조적 문제다. + +## 적용한 해결 방향 + +이번 수정은 개별 카드 하나를 줄이는 방식이 아니라, 행거 전체에 `Scroll Island` 규칙을 추가하는 방향으로 처리했다. + +원칙: + +- 화면 전체는 가능한 한 유지한다. +- 콘텐츠가 많은 영역만 내부 스크롤을 가진다. +- `overflow: hidden`은 레이아웃 컨테이너를 안정화하는 곳에만 쓰고, 실제 목록 영역은 반드시 스크롤 가능하게 둔다. +- 고정 높이보다 `minmax(0, 1fr)`와 `min-height: 0`을 우선한다. +- 작은 화면에서는 외부 shell 자체도 스크롤 가능하게 둔다. + +## 적용한 변경 + +### 행거 전체 레이아웃 방어선 추가 + +변경: + +- `.hangar-overlay`를 `overflow: auto`로 변경 +- `.hangar-inner`를 `96vh` 기준으로 확장 +- grid row를 `auto minmax(0, 1fr) auto`로 고정 +- 주요 패널에 `min-height: 0` 적용 + +의도: + +- 전체 화면 높이가 줄어도 UI가 잘려 접근 불가능해지는 상황을 방지한다. + +### 탭 콘텐츠 공통 스크롤 처리 + +변경: + +- `.tab-content`, `.upgrade-shop`, `.pass-panel`에 내부 스크롤 규칙 적용 +- 공통 스크롤바 스타일 적용 +- 목록형 영역에 `overscroll-behavior: contain` 적용 + +의도: + +- 특정 탭의 콘텐츠가 많아도 화면 밖으로 사라지지 않고 해당 탭 내부에서 스크롤된다. + +### Mount Bays 스크롤 아일랜드 적용 + +변경: + +- `.mount-bay-column`을 grid로 변경 +- 제목 영역과 목록 영역을 분리 +- `.slots-container.compact`에 `overflow-y: auto` 적용 +- 슬롯 최소 높이를 줄여 4개 부위가 더 안정적으로 보이도록 조정 + +의도: + +- Weapon, Armor, Engine, Wings를 모두 접근 가능하게 한다. +- 화면 높이가 작아져도 마지막 Aero Stabilizer가 숨지 않게 한다. + +### Footer 압축 및 작은 화면 대응 + +변경: + +- Footer 최소 높이 축소 +- Mission Mode, Tactical Support, Launch 영역이 메인 콘텐츠를 과도하게 밀어내지 않도록 조정 +- 낮은 화면 높이에서는 카드 높이와 미리보기 높이를 자동으로 압축 +- 좁은 화면에서는 left telemetry panel을 숨기고 메인 콘텐츠 우선 + +의도: + +- 핵심 작업 영역이 footer 때문에 잘리는 문제를 줄인다. + +## 수정 파일 + +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HangarOverlay.css` + +## 검증 + +- `npm run build` 성공 +- 출력 디렉터리: `dist/43` + +## 후속 체크 포인트 + +- Loadout에서 Mount Bays 4개가 모두 접근 가능한지 확인한다. +- 화면 높이를 줄였을 때 Mount Bays 내부 스크롤이 동작하는지 확인한다. +- Upgrade, Merge, Salvage, Forge, Pass 탭에서 목록이 잘리지 않는지 확인한다. +- Footer가 메인 콘텐츠를 과하게 밀어내지 않는지 확인한다. +- 좁은 화면에서 left telemetry panel이 숨겨져도 핵심 기능 접근이 가능한지 확인한다. diff --git a/00_Raw/Code Splitting and Lazy Loading.md b/00_Raw/Code Splitting and Lazy Loading.md new file mode 100644 index 00000000..ed9f5002 --- /dev/null +++ b/00_Raw/Code Splitting and Lazy Loading.md @@ -0,0 +1,29 @@ +# [[Code Splitting and Lazy Loading]] + +## 📌 Brief Summary +**Code Splitting(코드 분할)**과 **Lazy Loading(지연 로딩)**은 방대한 자바스크립트 번들을 더 작은 청크(chunk) 단위로 나누고, 사용자가 필요로 하는 시점에만 온디맨드(on-demand) 방식으로 코드를 로드하는 프런트엔드 최적화 기법입니다[1-3]. 이 기법을 사용하면 초기 다운로드해야 하는 번들 크기를 크게 줄여 페이지 로드 시간과 사용자 인지 성능을 획기적으로 향상시킬 수 있습니다[1, 4]. React 환경에서는 주로 동적 임포트와 결합된 `React.lazy()` 및 ``를 활용해 구현됩니다[5, 6]. + +## 📖 Core Content +* **초기 번들 크기 문제와 해결책:** + 기본적으로 모던 프런트엔드 애플리케이션은 모든 앱 코드와 외부 종속성(dependencies)을 하나의 거대한 자바스크립트 파일(번들)로 패키징합니다. 이는 긴 다운로드 시간, 무거운 파싱 및 컴파일 작업, 그리고 Core Web Vitals(FCP, LCP, INP) 지표의 하락을 유발합니다[3, 7]. **코드 스플리팅**은 이 거대한 번들을 분할하여, 애플리케이션 초기 구동에 불필요한 코드를 분리함으로써 이러한 성능 병목 현상을 해결합니다[3, 8]. + +* **스플리팅 및 지연 로딩의 적용 전략:** + * **라우트 기반 스플리팅(Route-level splitting):** 사용자가 특정 페이지 경로(Route)로 네비게이션할 때만 해당 화면의 코드를 다운로드하게 하여 초기 로드 속도를 획기적으로 향상시키는 가장 일반적인 접근 방식입니다[2, 3, 9]. + * **컴포넌트 수준 지연 로딩(Component-level lazy loading):** 차트, 지도, 리치 텍스트 에디터처럼 무겁거나, 모달 창 및 관리자 설정 패널처럼 사용 빈도가 낮은 UI 블록을 렌더링이 필요한 순간에만 로드합니다[5, 10]. + +* **React에서의 구현 방법 (`React.lazy`와 `Suspense`):** + React는 내장 함수인 `React.lazy()`를 제공하여 컴포넌트를 동적으로 임포트(`import()`)할 수 있도록 지원합니다[1, 5]. 이때 분할된 코드가 다운로드되는 동안 화면에 보여줄 로딩 스피너나 스켈레톤 UI와 같은 폴백(fallback) 화면은 `` 컴포넌트를 통해 정의합니다[6, 9]. 이러한 방식을 적용하면 앱 복잡도에 따라 초기 번들 크기를 최대 20~70%까지 줄일 수 있습니다[6]. + +* **이미지 지연 로딩 최적화:** + 자바스크립트뿐만 아니라 이미지 역시 페이지 용량의 큰 부분을 차지합니다. 스크롤 아래에 위치해 당장 보이지 않는 이미지의 경우, 자바스크립트를 복잡하게 구현할 필요 없이 브라우저 네이티브 속성인 `loading="lazy"`를 사용하여 불필요한 리소스 다운로드를 방지할 수 있습니다[11]. + +* **적용 시 주의사항 (안티 패턴):** + 지연 로딩은 강력하지만, 화면 최상단에 있어 스크롤 없이 즉시 보여야 하는 필수 영역(above-the-fold) 컴포넌트나, 렌더링 속도가 매우 빨라 즉각적으로 표시되어야 하는 요소들에는 적용을 피해야 합니다[10, 11]. 이들에 적용하면 오히려 사용자 경험(UX)을 지연시킬 수 있습니다. + +## 🔗 Knowledge Connections +- **Related Topics:** [[React Performance Optimization]], [[Core Web Vitals]], [[Suspense]] +- **Projects/Contexts:** [[Vite]], [[Next.js]] +- **Contradictions/Notes:** 지연 로딩은 초기 로딩 속도 향상을 위한 핵심 도구이지만, 화면 첫 렌더링에 핵심적인 부분(above-the-fold 요소 등)에 남용하면 반대로 렌더링 지연을 초래하므로 주의 깊게 측정하고 분리해야 합니다[10, 11]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/00_Raw/Frontend App Development Architecture.md b/00_Raw/Frontend App Development Architecture.md new file mode 100644 index 00000000..97e93db3 --- /dev/null +++ b/00_Raw/Frontend App Development Architecture.md @@ -0,0 +1,24 @@ +# [[Frontend App Development Architecture]] + +## 📌 Brief Summary +프론트엔드 앱 개발 아키텍처는 확장성, 유지보수성, 성능을 고려하여 프론트엔드 시스템을 설계하고 구성하는 기반 프레임워크입니다 [1, 2]. 과거의 단순한 기술적 파일 기반 분리에서 벗어나, 비즈니스 로직과 기능(Feature)을 중심으로 모듈화하고 결합도를 낮추는 방향으로 아키텍처 패러다임이 전환되었습니다 [3, 4]. 일관된 폴더 구조, 상태 관리 패러다임, 클린 코드 원칙을 적용함으로써 애플리케이션이 복잡해지더라도 안정적으로 확장할 수 있도록 돕습니다 [5, 6]. + +## 📖 Core Content +* **모듈화와 폴더 구조 (Folder Structure):** + 과거에는 컴포넌트, 훅, 스타일 등 파일 유형(Type)별로 코드를 나누는 방식을 사용했으나, 이는 애플리케이션이 커질수록 확장성이 떨어집니다 [3, 7]. 현대 프론트엔드 아키텍처는 도메인이나 기능별로 코드를 캡슐화하는 기능 기반(Feature-based) 구조를 채택합니다 [4, 8, 9]. 특히 **Feature-Sliced Design (FSD)**은 프론트엔드 아키텍처에 특화된 방법론으로, 코드를 레이어(app, pages, widgets, features, entities, shared)로 나누고 상위 레이어에서 하위 레이어로만 의존성을 가지도록 강제하여 순환 참조를 방지하고 아키텍처 규율을 유지합니다 [10-13]. +* **소프트웨어 공학 원칙 (SOLID & Clean Code):** + React 컴포넌트에도 객체지향 설계의 SOLID 원칙이 적용됩니다. 컴포넌트는 단일 책임(SRP)을 가져야 하며 300줄 이상 길어지면 분리를 고려해야 하고, Composition을 통해 확장에는 열려 있고 수정에는 닫혀 있도록(OCP) 설계해야 합니다 [14-16]. 또한 DRY(반복하지 마라), KISS(단순하게 유지하라), YAGNI(필요할 때만 구현하라) 원칙을 통해 과도한 추상화를 피하고, 현재 요구사항에 집중해 예측 가능하고 디버깅하기 쉬운 코드를 작성해야 합니다 [17-19]. +* **상태 관리의 파편화 (State Management):** + 모든 상태를 거대한 단일 스토어(예: Redux)에 넣는 방식에서 벗어나, 목적에 맞는 도구로 분리하는 것이 2025년의 트렌드입니다 [20]. API에서 가져온 '서버 상태'는 캐싱과 동기화를 지원하는 TanStack Query(React Query)로 관리하며, '전역 애플리케이션 상태'는 리렌더링 최적화가 뛰어난 Zustand 같은 가벼운 라이브러리를 사용합니다 [20-22]. +* **명명 규칙과 거버넌스 (Naming Conventions & Governance):** + 대소문자 구분이 없는 OS(Windows, macOS) 환경에서 발생할 수 있는 CI/CD 빌드 오류를 방지하기 위해 파일과 폴더 이름은 `kebab-case`를 사용합니다 [23, 24]. 반면 React 컴포넌트는 `PascalCase`를, 일반 변수와 커스텀 훅은 `camelCase`를 사용하는 것이 업계 표준입니다 [23, 25-27]. 자동화된 거버넌스를 위해 ESLint, Prettier, Husky를 도입하여 커밋 전에 린팅과 포매팅을 강제하는 것이 좋습니다 [25]. +* **성능 최적화 및 안정성 (Performance & Reliability):** + Vite와 같은 현대적인 번들러를 사용하여 서드파티 라이브러리를 분리(manualChunks)하고, `React.lazy`와 동적 임포트를 통한 코드 스플리팅을 적용하면 초기 번들 크기와 로딩 시간을 획기적으로 줄일 수 있습니다 [28-32]. 런타임 오류 시 애플리케이션 전체가 멈추는 백화현상을 막기 위해 'React Error Boundaries'를 도입해 실패를 국소화하고 대체 UI를 렌더링해야 합니다 [33-35]. 최근 안정화된 React Compiler는 `useMemo`나 `useCallback`과 같은 수동 메모이제이션을 자동화해 주어 클린 코드를 유지하면서 불필요한 렌더링을 방지해 줍니다 [36-39]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Feature-Sliced Design]], [[SOLID Principles]], [[State Management]], [[React Error Boundaries]], [[React Compiler]] +- **Projects/Contexts:** [[React Project Structure]], [[Performance Optimization]], [[Frontend Refactoring]] +- **Contradictions/Notes:** Context API는 별도의 외부 종속성 없이 상태를 공유할 수 있는 React 내장 도구이지만, 하나의 값이 변경될 때 구독 중인 모든 컴포넌트를 리렌더링하는 문제(Re-render storm)가 있습니다 [40, 41]. 따라서 잦은 업데이트가 필요한 상태에는 부적합하며, 이 경우 Zustand 등의 툴이 권장됩니다 [22, 42]. 또한 DRY(반복 지양) 원칙은 유용하지만, 코드를 너무 과도하게 추상화하면 직관성을 해쳐 오히려 KISS(단순성 유지) 원칙에 위배될 수 있으므로, 동일 패턴이 세 번 이상 반복될 때만 추상화하는 것이 이상적입니다 [17, 18, 43]. Atomic Design 모델은 UI 컴포넌트의 재사용성을 높이는 데에는 훌륭하지만 비즈니스 로직과 상태를 구조화하는 데는 부족하므로, 대규모 앱에서는 FSD 방법론이 더욱 유용합니다 [44-46]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/00_Raw/Git Branching Strategies.md b/00_Raw/Git Branching Strategies.md new file mode 100644 index 00000000..c311ab31 --- /dev/null +++ b/00_Raw/Git Branching Strategies.md @@ -0,0 +1,28 @@ +# [[Git Branching Strategies]] + +## 📌 Brief Summary +Git 브랜칭 전략은 소프트웨어 개발 팀이 코드 변경 사항을 효율적으로 관리하고 통합하기 위해 사용하는 체계적인 워크플로우입니다. 이 전략은 메인(main) 코드베이스의 안정성을 보호하면서 기능 개발, 버그 수정 등을 격리된 환경(브랜치)에서 수행할 수 있도록 돕습니다 [1-3]. 팀의 규모와 프로젝트 요구사항에 따라 Feature Branch Workflow, Trunk-Based Development, Git Flow 등 다양한 전략을 맞춤 적용하여 코드 충돌을 방지하고 협업 효율을 극대화할 수 있습니다 [3, 4]. + +## 📖 Core Content +* **주요 브랜칭 전략** + * **Feature Branch Workflow (기능 브랜치 워크플로우)**: 2~5명 규모의 소규모 팀에게 가장 초보자 친화적이고 권장되는 방식입니다 [2, 4]. 메인(main) 브랜치는 항상 안정적이고 배포 가능한 상태로 유지하며, 새로운 작업이 필요할 때마다 메인에서 분기된 짧은 수명의 기능 브랜치를 생성하여 작업합니다 [1, 2, 5]. + * **Trunk-Based Development (트렁크 기반 개발)**: 강력한 CI/CD 환경을 갖춘 숙련된 팀에 적합하며, 짧은 수명의 기능 브랜치를 통해 작고 잦은 커밋을 메인에 병합하는 방식입니다 [1, 4]. + * **Git Flow & GitHub Flow**: Git Flow는 정기적인 릴리스가 필요한 대규모 프로젝트에 적합하지만 소규모 팀이 사용하기에는 너무 무거울 수 있습니다 [4]. 반면 GitHub Flow는 메인 브랜치로 직접 병합하여 배포를 단순화하는 유연한 전략입니다 [6, 7]. + +* **핵심 규칙 및 모범 사례 (Best Practices)** + * **브랜치 명명 규칙**: 브랜치 이름은 서술적이고 짧게 유지해야 합니다(예: `feature/user-auth`, `bugfix/login-error`) [8-10]. 이슈 트래커의 티켓 ID(예: `PROJ-123`)를 포함하면 코드 변경 사항과 비즈니스 요구사항 간의 추적성을 크게 높일 수 있습니다 [11, 12]. + * **커밋 규칙 (Conventional Commits)**: 커밋은 의미 있는 작은 단위로 자주 수행해야 합니다 [9, 13]. `feat`(새 기능), `fix`(버그 수정), `docs`(문서), `refactor`(리팩토링), `chore`(유지보수) 등의 일관된 접두사를 사용하여 커밋의 목적을 명확히 하는 것이 좋습니다 [14-16]. + * **Pull Request (PR) 및 병합**: 작업이 완료되면 반드시 PR을 생성하여 최소 1명 이상의 동료 리뷰와 CI/CD 테스트 통과를 거친 후 병합해야 합니다 [11, 13, 17]. 깔끔한 커밋 히스토리를 유지하기 위해 'Squash Merge(스쿼시 병합)'를 사용하는 것이 좋으며, 병합이 완료된 기능 브랜치는 즉시 삭제하여 저장소를 정리해야 합니다 [11, 13, 18]. + +* **피해야 할 안티 패턴 (Anti-Patterns)** + * 보호되어야 할 메인(main) 브랜치에 직접 코드를 커밋하는 행위 [19, 20]. + * 수명이 너무 긴 기능 브랜치를 방치하여 거대한 병합 충돌(Merge Conflict)을 유발하는 행위 [21, 22]. + * 코드 리뷰를 건너뛰거나, CI 테스트를 통과하지 못한 깨진 코드를 병합하는 행위 [20, 22]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Conventional Commits]], [[Pull Request Workflow]], [[CI/CD Pipeline]] +- **Projects/Contexts:** [[Frontend Team Collaboration]], [[Small Team Development]] +- **Contradictions/Notes:** 대규모 프로젝트에 자주 쓰이는 'Git Flow' 전략은 2~5명 규모의 소규모 팀에게는 프로세스 오버헤드가 커서 부적합하며, 대신 더 가벼운 'Feature Branch Workflow'나 'Trunk-Based Development'를 사용하는 것이 실무적으로 훨씬 권장됩니다 [1, 4, 23]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/00_Raw/Memory Leak Debugging.md b/00_Raw/Memory Leak Debugging.md new file mode 100644 index 00000000..b38f268f --- /dev/null +++ b/00_Raw/Memory Leak Debugging.md @@ -0,0 +1,30 @@ +# [[Memory Leak Debugging]] + +## 📌 Brief Summary +메모리 누수는 애플리케이션이 메모리를 할당한 후 더 이상 필요하지 않음에도 불구하고 이를 해제(release)하지 않아 메모리 소비가 지속적으로 증가하는 현상을 의미합니다 [1]. 이러한 문제는 시간이 지남에 따라 애플리케이션의 성능을 점진적으로 저하시키고, 인터페이스를 느리게 만들며, 궁극적으로 브라우저 탭의 멈춤이나 충돌을 유발합니다 [2-4]. 프론트엔드 환경에서 메모리 누수를 해결하려면 Chrome DevTools와 같은 도구를 활용하여 메모리 할당을 프로파일링하고, 분리된 DOM 노드나 정리되지 않은 이벤트 리스너 등의 원인을 찾아 수정해야 합니다 [5-7]. + +## 📖 Core Content +* **메모리 누수의 정의와 주요 증상** + 자바스크립트에서 가비지 컬렉터(Garbage Collector)는 사용되지 않는 메모리를 자동으로 회수하지만, 변수 등에 참조가 남아있을 경우 메모리가 해제되지 않고 누수됩니다 [1]. 이러한 메모리 누수는 작업 부하가 일정함에도 불구하고 메모리 사용량이 감소하지 않고 꾸준히 증가하는 특징을 보입니다 [4]. 주요 증상으로는 장시간 사용 후 성능 저하, 잦은 화면 멈춤, 특히 모바일 기기에서의 잦은 앱 충돌 등이 있습니다 [2-4]. + +* **프론트엔드의 주요 메모리 누수 패턴** + * **분리된 DOM 노드 (Detached DOM Nodes):** DOM 트리에서는 제거되었지만 자바스크립트 코드나 변수에서 여전히 참조를 유지하고 있어 가비지 컬렉션의 대상이 되지 못하는 노드입니다 [8, 9]. + * **이벤트 리스너 누적 (Event Listener Accumulation):** React의 `useEffect` 등에서 컴포넌트가 언마운트될 때 등록된 이벤트 리스너나 구독을 정리(cleanup) 해주는 함수를 반환하지 않으면 발생합니다 [9-12]. + * **클로저에 의해 유지되는 참조 (Closure-Retained References):** 클로저가 부모 스코프의 변수를 계속 살려두어 불필요하게 큰 객체를 메모리에 남겨두는 경우입니다 [13]. + +* **디버깅 및 탐지 방법** + * **Chrome 작업 관리자:** 실시간으로 모니터링하며 'JavaScript Memory' 항목의 괄호 안 숫자(라이브 숫자)가 꾸준히 증가하는지 확인하여 누수의 1차적 징후를 발견할 수 있습니다 [14, 15]. + * **성능 패널 (Performance Panel):** 시간 경과에 따른 메모리 사용량을 시각화하며, 강제 가비지 컬렉션 이후에도 JS 힙(Heap) 크기가 이전보다 높은 상태로 종료된다면 메모리 누수를 의심해야 합니다 [16, 17]. + * **힙 스냅샷 (Heap Snapshots):** 메모리 상태의 스냅샷을 캡처한 뒤 'Detached' 키워드로 검색하여 분리된 DOM 트리를 찾거나, 작업 전후의 두 스냅샷을 비교(Comparison)하여 지속적으로 델타(Delta) 크기가 증가하는 객체를 식별할 수 있습니다 [6, 9, 11, 18]. + * **할당 타임라인 (Allocation Timelines):** 메모리 할당 패턴을 실시간으로 추적하여, 회색으로 변하지 않고 남아있는 파란색 막대(해제되지 않은 메모리 할당)를 통해 특정 사용자 상호작용 중 발생하는 누수를 찾아냅니다 [19-21]. + +* **예방 및 모범 사례** + 대규모 객체 캐싱에는 가비지 컬렉션을 방해하지 않는 `WeakMap`을 사용하는 것이 권장됩니다 [12]. React 애플리케이션에서는 컴포넌트의 수명 주기에 맞춰 `useEffect` 내에서 항상 이벤트 리스너를 제거하거나 구독을 취소하는 정리(cleanup) 함수를 제공하여 메모리 누수를 미연에 방지해야 합니다 [10-12]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[React Hooks]], [[Performance Optimization]], [[Garbage Collection]] +- **Projects/Contexts:** [[Frontend Application Debugging]], [[Scalable React Architecture]] +- **Contradictions/Notes:** 소스의 메모리 누수 디버깅 기법들은 주로 Chrome DevTools를 기준으로 설명되며, React 개발자는 Hook의 생명주기를 정확히 이해하여 cleanup을 수행하는 것이 메모리 최적화에 직결됨을 강조합니다 [5, 11, 22]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/00_Raw/React Error Boundaries.md b/00_Raw/React Error Boundaries.md new file mode 100644 index 00000000..42a255f8 --- /dev/null +++ b/00_Raw/React Error Boundaries.md @@ -0,0 +1,22 @@ +# [[React Error Boundaries]] + +## 📌 Brief Summary +React Error Boundaries는 하위 컴포넌트 트리의 렌더링, 수명 주기 메서드 또는 생성자에서 발생하는 JavaScript 에러를 포착하는 특수한 클래스 컴포넌트입니다 [1, 2]. 이 메커니즘은 앱 전체가 다운되거나 빈 화면(white screen of death)이 표시되는 것을 방지하고 대신 대체 UI(fallback UI)를 표시하도록 돕습니다 [1, 2]. 본질적으로 React 컴포넌트를 위한 `try-catch` 블록처럼 작동하여 프론트엔드 애플리케이션의 안정성과 사용자 경험을 높여줍니다 [2, 3]. + +## 📖 Core Content +* **작동 원리 및 제약 사항:** + Error Boundaries는 클래스 컴포넌트로만 생성할 수 있으며, 오류 발생 후 대체 UI를 렌더링하기 위한 `static getDerivedStateFromError()`나 오류 정보를 기록하기 위한 `componentDidCatch()` 생명주기 메서드 중 하나 이상을 정의해야 작동합니다 [3-5]. 단, 이벤트 핸들러, 비동기 코드(예: `setTimeout`), 서버 사이드 렌더링(SSR), 혹은 Error Boundary 자체에서 발생한 에러는 포착하지 못합니다 [4, 5]. 이벤트 핸들러의 경우 표준 JavaScript의 `try/catch` 문을 직접 사용해야 합니다 [5-7]. + +* **전략적 배치 및 모범 사례:** + 애플리케이션 전체를 단일 Error Boundary로 감싸기보다는, 불안정하거나 중요한 UI 섹션(예: 타사 위젯, 차트, 복잡한 폼 등)을 개별적으로 감싸는 것이 권장됩니다 [8-10]. 예를 들어, 사이드바나 메시지 입력창 중 한 곳이 충돌하더라도 개별적인 Error Boundary가 설정되어 있다면 나머지 UI 부분은 계속 상호작용 가능한 상태로 유지될 수 있습니다 [8, 11]. + +* **프로덕션 환경 적용 및 복구성 향상:** + 프로덕션 환경에서는 Error Boundaries를 Sentry나 LogRocket과 같은 로깅 및 모니터링 도구와 통합하여 에러 세부 정보를 캡처하는 것이 모범 사례로 꼽힙니다 [10]. React 16부터는 Error Boundary에 의해 포착되지 않은 에러는 전체 React 컴포넌트 트리의 마운트 해제(unmounting)를 초래하여 심각한 문제를 일으킬 수 있으므로, 적절한 에러 경계 설정은 확장 가능하고 견고한 애플리케이션을 유지하는 데 필수적입니다 [9, 12]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Class Components]], [[Fallback UI]], [[Frontend Debugging]], [[Component Lifecycle]] +- **Projects/Contexts:** [[Sentry/LogRocket Monitoring]], [[Scalable React Architecture]], [[Error Handling in 2025]] +- **Contradictions/Notes:** Error Boundaries는 렌더링 오류를 잡기 위해 설계된 훌륭한 기능이지만, 함수형 컴포넌트로는 직접 만들 수 없으며 컴포넌트의 이벤트 핸들러 내의 오류는 포착하지 못하므로 이벤트 핸들러는 일반적인 `try/catch`로 별도 처리해야 합니다 [3, 5, 6]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/00_Raw/React State Management.md b/00_Raw/React State Management.md new file mode 100644 index 00000000..953802cd --- /dev/null +++ b/00_Raw/React State Management.md @@ -0,0 +1,33 @@ +# [[React State Management]] + +## 📌 Brief Summary +React 상태 관리(State Management)는 애플리케이션의 데이터 흐름과 UI 업데이트를 제어하는 핵심 메커니즘이다. 과거의 단일 스토어 방식에서 벗어나, 최근에는 상태의 성격(로컬, 전역, 서버 캐시 등)에 따라 가장 적합한 도구를 결합하여 사용하는 파편화(Fragmentation) 접근법이 표준으로 자리 잡았다 [1, 2]. 개발자는 앱의 규모, 팀의 크기, 상태 변경의 빈도에 맞춰 Context API, Zustand, Redux, TanStack Query 등을 전략적으로 선택하여 확장성을 높이고 성능 저하를 방지해야 한다 [1, 3]. + +## 📖 Core 소스 Content +* **상태의 분류와 파편화 (Fragmentation of State)** + * 현재 프론트엔드 아키텍처에서는 상태를 로컬 컴포넌트 상태, 전역 애플리케이션 상태, 서버 캐시 상태, URL 상태로 명확히 구분한다 [1]. + * **로컬 상태:** React 내장 훅인 `useState`와 `useReducer`를 주로 사용하지만, 지나치게 복잡한 상태를 `useState`로만 관리하려는 잘못된 패턴은 피해야 한다 [1, 4]. + * **서버 상태:** API 계층에서 가져온 데이터는 클라이언트 상태와 근본적으로 다르므로 캐싱, 동기화, 로딩 및 에러 처리가 필요하다 [2]. 이를 위해 TanStack Query(React Query)와 같은 라이브러리가 업계 표준으로 사용되며, 중복 네트워크 요청을 줄이고 무한 스크롤 등을 단순화한다 [2, 5]. RTK Query 또한 캐싱, 중복 제거, 자동 리패칭 등을 제공해 비동기 작업의 복잡성을 크게 줄여준다 [6]. + +* **Context API의 한계와 적합성** + * **적합한 사례:** 종속성 추가 없이(Zero dependencies) 테마 변경(다크/라이트 모드), 다국어 설정, 피처 플래그 등 변경이 드물고 정적인 전역 상태를 관리하는 데 적합하다 [7, 8]. + * **한계:** 특정 값이 변경될 때마다 Context를 구독하는 모든 컴포넌트가 불필요하게 리렌더링되는 성능 문제(Re-render storm)를 유발한다 [9, 10]. 또한, Redux와 달리 상태 변경 기록을 추적하는 Time-Travel 디버깅 도구를 지원하지 않는다 [11]. + +* **Zustand를 활용한 최적화** + * **작동 방식:** Context API의 리렌더링 문제를 해결하기 위해 도입된 경량 상태 관리 라이브러리다. 스토어가 React의 컴포넌트 트리 외부에 위치하며, '선택자(Selector pattern)'를 사용해 컴포넌트가 의존하는 특정 상태(Slice)가 변경될 때만 리렌더링을 트리거한다 [2, 12, 13]. + * **장단점:** 설정이 단순하고 속도가 빨라 5~15명 규모의 팀과 중간 규모 애플리케이션에 매우 적합하다 [14]. 단, 구조가 너무 유연하여 엄격한 규율이 없을 경우 팀원마다 비동기 호출이나 상태 관리 패턴이 일관성 없이 파편화될 위험이 있다 [15, 16]. + +* **Redux (Redux Toolkit)와 대규모 애플리케이션** + * Redux는 불변성 업데이트와 액션 디스패치, 리듀서를 통해 일관되고 예측 가능한 상태 컨테이너를 제공하는 산업 표준이다 [17]. + * 복잡한 파생 상태 관리가 필요하고 500개 이상의 컴포넌트를 다루거나, 10명 이상의 개발자가 협업하는 대규모 미션 크리티컬 애플리케이션에 적합하다 [18]. 강력한 구조를 강제하여 버그를 사전에 방지하며, Redux DevTools를 통해 복잡한 비동기 상태 에러를 빠르게 추적하고 디버깅할 수 있다 [19, 20]. + +* **아키텍처 관점에서의 상태 위치 (Feature-Sliced Design)** + * Feature-Sliced Design (FSD) 아키텍처에서는 상태 관리 라이브러리의 종류와 무관하게 상태의 소유권을 명확히 제한한다. 엔티티 상태는 `entities` 레이어에, 특정 유저 시나리오의 상태는 `features` 레이어에, 글로벌 인프라 상태는 `app` 레이어에 두어 결합도를 낮춰야 한다 [21, 22]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Frontend Performance Optimization]], [[Feature-Sliced Design]], [[React Hooks]], [[Clean Code Principles]] +- **Projects/Contexts:** [[Redux Toolkit]], [[Zustand]], [[TanStack Query]], [[React Context API]] +- **Contradictions/Notes:** 상태 관리 라이브러리를 선택할 때 단순히 번들 크기(Context 0KB, Zustand 2.2KB, Redux 4.3KB)만을 비교하는 것은 잘못된 접근이라고 지적된다. 번들 크기가 작더라도 Context API를 잘못 사용할 경우 디버깅과 리렌더링 최적화에 막대한 개발 시간이 낭비될 수 있으므로, 팀 규모와 기능의 복잡성을 기준으로 선택해야 한다 [7, 9, 23]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/AI/Product-Thinking-in-AI.md b/10_Wiki/Topics/AI/Product-Thinking-in-AI.md new file mode 100644 index 00000000..5cc3b48e --- /dev/null +++ b/10_Wiki/Topics/AI/Product-Thinking-in-AI.md @@ -0,0 +1,29 @@ +--- +id: BIZ-PROD-THINK-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [product-management, ai, product-thinking, user-experience, value-creation, design-thinking] +last_reinforced: 2026-04-26 +--- + +# [[Product Thinking in AI (AI에서의 제품 사고)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "기술의 화려함(How)에 매몰되지 말고, 사용자가 겪는 고통의 본질(Why)을 해결하는 지능적 '가치'를 설계하라" — AI 기술을 단순히 구현하는 수준을 넘어, 그것이 사용자에게 어떤 문제를 해결해주고 어떤 비즈니스 가치를 창출하는지 제품적 관점에서 고민하는 사고방식. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Problem-Solution Fit and User-Centric Intelligence" — 기술적 정확도(Accuracy)보다 사용자의 워크플로우를 어떻게 개선하는지(Utility)에 집중하며, AI의 불확실성을 사용자 경험(UX)으로 어떻게 완충할 것인지 설계하는 패턴. +- **핵심 고려 사항:** + - **Problem Discovery:** AI가 반드시 필요한 문제인가? 아니면 단순 자동화로 가능한가? + - **Managing Expectations:** AI의 완벽하지 않음을 사용자에게 어떻게 투명하게 전달할 것인가? + - **Feedback Loops:** 사용자 데이터를 통해 모델을 어떻게 지속적으로 개선할 것인가? + - **Ethics and Trust:** 보안과 윤리가 제품 설계의 기초가 되고 있는가? +- **의의:** AI 프로젝트의 실패 원인 중 상당수가 '기술의 부재'가 아닌 '제품적 가설의 실패'에 있음을 인지하고, 시장이 원하는 실질적인 지능형 솔루션을 구축하게 함. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 고성능 모델만 만들면 사용자가 알아서 쓸 것이라는 공급자 중심 사고에서 벗어나, 이제는 모델 성능이 조금 낮더라도 사용자 맥락(Context)을 얼마나 잘 이해하고 비즈니스 프로세스에 녹아드느냐가 제품의 성패를 가름. +- **정책 변화:** Antigravity 프로젝트는 모든 지식 보강 작업 시, 단순 정보 나열이 아닌 '사용자(나 혹은 에이전트)가 이 정보를 어떻게 즉각적으로 활용할 수 있을까?'를 최우선으로 고려하는 제품 사고 원칙을 준수함. + +## 🔗 지식 연결 (Graph) +- [[Minimum-Viable-Product-MVP]], [[Modern-Website-Architecture]], [[Trustworthy-AI]], [[Process-Automation-with-AI]] +- **Raw Source:** [[10_Wiki/Topics/AI/Product-Thinking-in-AI.md]] diff --git a/10_Wiki/Topics/AI/Productivity-Hacks-for-Devs.md b/10_Wiki/Topics/AI/Productivity-Hacks-for-Devs.md new file mode 100644 index 00000000..9a45d169 --- /dev/null +++ b/10_Wiki/Topics/AI/Productivity-Hacks-for-Devs.md @@ -0,0 +1,29 @@ +--- +id: DEV-PROD-HACK-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [productivity, developer-experience, workflow-optimization, automation, deep-work, time-management] +last_reinforced: 2026-04-26 +--- + +# [[Productivity Hacks for Devs (개발자를 위한 생산성 팁)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "반복되는 모든 손가락의 움직임을 자동화하고, 뇌의 에너지를 오직 '복잡한 문제의 해결'과 '창의적 설계'에만 집중시켜라" — 개발 워크플로우에서 발생하는 마찰을 제거하고 인지 자원을 효율적으로 관리하여 단위 시간당 아웃풋을 극대화하는 전략. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Frictionless Workflow and Cognitive Resource Management" — 손에 익은 도구(IDE, Shell)를 극한으로 커스터마이징하고, 방해 요소를 차단하는 환경(Deep Work)을 구축하며, AI를 지능적 비서로 활용하여 루틴한 작업을 위임하는 패턴. +- **주요 생산성 영역:** + - **Environment Optimization:** Dotfiles 관리, 터미널 에일리어스(Alias), IDE 스니펫 및 단축키 마스터. + - **Automation:** 반복되는 스크립트화, CI/CD 자동화, Git Hooks 활용. + - **Focus Management:** 뽀모도로 기법, 타임 블로킹(Time Blocking), 알림 끄기. + - **AI Augmentation:** 코드 생성, 디버깅, 문서 요약 시 AI 에이전트를 적극 활용하여 '검색 시간' 단축. +- **의의:** 기술적 숙련도만큼이나 중요한 '운영적 숙련도'를 높여, 번아웃을 방지하고 지속 가능한 성장을 가능케 함. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 단순히 '타이핑 속도'를 높이는 것이 생산성이라 믿던 시대에서, 이제는 '얼마나 많은 코드를 안 쓸 수 있는가(Less Code)'와 '얼마나 정확한 결정을 내리는가'가 생산성의 진정한 척도가 됨. +- **정책 변화:** Antigravity 프로젝트는 개발자의 생산성을 돕기 위해 복잡한 위키 가드닝이나 인프라 설정을 에이전트가 전담하게 함으로써, 사용자가 핵심 아키텍처 설계에만 집중할 수 있는 환경을 제공함. + +## 🔗 지식 연결 (Graph) +- [[Platform-Engineering]], [[Process-Automation-with-AI]], [[Agile-Methodologies]], [[Local-Brain-Management]] +- **Raw Source:** [[10_Wiki/Topics/AI/Productivity-Hacks-for-Devs.md]] diff --git a/10_Wiki/Topics/AI/Profiling-and-Optimization.md b/10_Wiki/Topics/AI/Profiling-and-Optimization.md new file mode 100644 index 00000000..0c32f3f2 --- /dev/null +++ b/10_Wiki/Topics/AI/Profiling-and-Optimization.md @@ -0,0 +1,29 @@ +--- +id: DEV-PROF-OPT-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [software-engineering, performance, profiling, optimization, bottleneck, benchmarking, code-quality] +last_reinforced: 2026-04-26 +--- + +# [[Profiling and Optimization (프로파일링과 최적화)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "짐작으로 코드를 고치지 말고 데이터로 병목을 증명하며, 시스템의 가장 아픈 곳(Critical Path)부터 정밀하게 수술하라" — 프로그램의 실행 자원(시간, 메모리) 사용량을 측정하여 성능 저하의 원인을 식별하고, 효율적인 알고리즘이나 구조로 개선하는 일련의 과정. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Measure, Analyze, and Refine" — 실제 실행 환경에서 성능 데이터를 수집(Profiling)하고, 80/20 법칙에 따라 가장 큰 부하를 주는 20%의 지점을 찾아내어, 적절한 데이터 구조나 병렬 처리 등을 통해 성능을 끌어올리는(Optimization) 패턴. +- **주요 기법:** + - **CPU Profiling:** 함수별 실행 시간 및 호출 횟수 분석 (Call Graph). + - **Memory Profiling:** 메모리 누수(Leak) 및 할당 패턴 감지. + - **Algorithmic Optimization:** 시간 복잡도($O(n)$) 개선. + - **Caching:** 동일 연산 반복 방지를 위한 메모이제이션(Memoization). +- **의의:** 사용자 경험(응답성)을 획기적으로 개선하고, 클라우드 컴퓨팅 비용을 절감하며, 한정된 하드웨어 자원에서 최대의 지능형 서비스를 제공하게 함. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 코드 한 줄을 더 짧게 쓰는 미시적 최적화보다, 전체 시스템의 아키텍처나 데이터 흐름을 최적화하는 거시적 최적화의 영향력이 훨씬 크다는 사실이 현대 대규모 시스템 설계의 상식이 됨. +- **정책 변화:** Antigravity 프로젝트는 에이전트의 응답 속도 지연 발생 시, 내부 프로파일링 도구를 가동하여 프롬프트 토큰 처리 시간과 도구 실행 시간 중 어디에서 병목이 발생하는지 즉각 진단함. + +## 🔗 지식 연결 (Graph) +- [[Chrome-DevTools-Memory-Profiling]], [[Parallel-Computing-in-AI]], [[Algorithm-Complexity-Analysis]], [[Network-Latency-Optimization]] +- **Raw Source:** [[10_Wiki/Topics/AI/Profiling-and-Optimization.md]] diff --git a/10_Wiki/Topics/AI/Project-Management-Best-Practices.md b/10_Wiki/Topics/AI/Project-Management-Best-Practices.md new file mode 100644 index 00000000..c683774d --- /dev/null +++ b/10_Wiki/Topics/AI/Project-Management-Best-Practices.md @@ -0,0 +1,29 @@ +--- +id: MGMT-PM-BEST-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [project-management, agile, scrum, kanban, wbs, team-collaboration, risk-management] +last_reinforced: 2026-04-26 +--- + +# [[Project Management Best Practices (프로젝트 관리 모범 사례)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "모호한 비전을 명확한 실행 단위로 해체하고, 소통의 마찰을 제거하여 팀 전체가 하나의 유기체처럼 목표를 향해 질주하게 하라" — 자원과 시간을 효율적으로 배분하여 정해진 기한 내에 고품질의 결과물을 산출하기 위한 체계적인 관리 원칙과 도구들의 총합. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Iterative Delivery and Transparency" — 거대한 목표를 한 번에 달성하려 하지 않고 짧은 주기(Sprint)로 나누어 실행하며, 작업의 진행 상황을 시각화(Kanban)하여 누구나 현재 상태와 장애물을 알 수 있게 만드는 패턴. +- **핵심 관리 영역:** + - **Scope Management:** 무엇을 하고 무엇을 안 할지(Out-of-scope) 명확히 정의. + - **Time Management:** 현실적인 일정 산출 및 병목 구간 선제적 대응. + - **Communication:** 회의는 짧게, 결정 사항은 기록으로, 도구(Slack, Notion)는 효율적으로. + - **Risk Management:** 실패 가능성을 미리 예측하고 플랜 B 마련. +- **의의:** 기술적 탁월함이 비즈니스 성과로 이어지게 만드는 가교 역할을 하며, 복잡도가 높은 AI/SW 개발 프로젝트에서 팀의 방향성을 유지하는 핵심 장치. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 완벽한 계획 수립 후 실행하던 폭포수(Waterfall) 모델에서, 이제는 실행하며 배우고 빠르게 수정하는 애자일(Agile) 방식이 표준이 되었으며, 문서화 역시 '최소한의 필요한 기록'을 중시하는 형태로 변화함. +- **정책 변화:** Antigravity 프로젝트는 1,174개 지식 가드닝 작업을 수행할 때, 칸반 보드 형식의 트래커를 통해 매 배치의 진행률을 투명하게 공개하고 리스크(연구 필요 항목)를 별도로 관리하는 PM 원칙을 철저히 준수함. + +## 🔗 지식 연결 (Graph) +- [[Lean-Project-Management]], [[Agile-Methodologies]], [[Operations-Management]], [[Product-Thinking-in-AI]] +- **Raw Source:** [[10_Wiki/Topics/AI/Project-Management-Best-Practices.md]] diff --git a/10_Wiki/Topics/AI/Prompt-Engineering-Foundations.md b/10_Wiki/Topics/AI/Prompt-Engineering-Foundations.md new file mode 100644 index 00000000..93230023 --- /dev/null +++ b/10_Wiki/Topics/AI/Prompt-Engineering-Foundations.md @@ -0,0 +1,29 @@ +--- +id: AI-PROMPT-ENG-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [ai, llm, prompt-engineering, nlp, chain-of-thought, few-shot, interaction-design] +last_reinforced: 2026-04-26 +--- + +# [[Prompt Engineering Foundations (프롬프트 엔지니어링 기초)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "질문의 정교함이 답변의 지능을 결정하며, AI에게 '어떻게 사고할지'를 명확히 가이드하여 잠재된 확률의 바다에서 최적의 해답을 인양하라" — 거대 언어 모델(LLM)로부터 원하는 결과를 얻기 위해 입력값(Prompt)을 전략적으로 설계하고 최적화하는 기술. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Instructional Clarity and Contextual Anchoring" — 모델에게 명확한 역할(Persona)을 부여하고, 구체적인 예시(Few-shot)를 제공하며, 단계별로 추론하도록 유도(CoT)하여 모델의 출력을 제어하는 패턴. +- **주요 프롬프팅 기법:** + - **Zero-shot:** 예시 없이 직접 지시. + - **Few-shot:** 몇 개의 예시를 주어 모델이 패턴을 학습하게 함. + - **Chain of Thought (CoT):** "단계별로 생각해보자"와 같은 문구로 복합 추론 유도. + - **System Prompt:** 모델의 전반적인 성격과 행동 규칙 정의. +- **의의:** 프로그래밍 언어가 기계와 소통하는 수단이듯, 프롬프트 엔지니어링은 자연어를 통해 초거대 AI의 거대한 파라미터 숲을 탐사하고 조정하는 현대 지능 제어의 핵심 인터페이스임. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 단순히 '말을 잘하는 법'으로 치부되던 단계를 넘어, 이제는 프롬프트 자체가 하나의 소프트웨어 코드처럼 구조화되고 자동화(DSPy 등)되는 '프롬프트 프로그래밍'의 시대로 진화함. +- **정책 변화:** Antigravity 프로젝트는 에이전트의 모든 출력 품질을 보장하기 위해, P-Reinforce 템플릿이라는 고정된 프롬프트 구조를 사용하여 일관성 있고 고밀도인 지식 자산을 생성함. + +## 🔗 지식 연결 (Graph) +- [[Natural-Language-Processing-NLP]], [[LLM-Training-Foundations]], [[P-Reinforce-Template-Guide]], [[Knowledge-Gardening-Workflow]] +- **Raw Source:** [[10_Wiki/Topics/AI/Prompt-Engineering-Foundations.md]] diff --git a/10_Wiki/Topics/AI/Proximal-Policy-Optimization.md b/10_Wiki/Topics/AI/Proximal-Policy-Optimization.md new file mode 100644 index 00000000..91789fde --- /dev/null +++ b/10_Wiki/Topics/AI/Proximal-Policy-Optimization.md @@ -0,0 +1,28 @@ +--- +id: RL-PPO-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [ai, reinforcement-learning, ppo, proximal-policy-optimization, openai, stability, policy-gradient] +last_reinforced: 2026-04-26 +--- + +# [[Proximal Policy Optimization (PPO, 근사 정책 최적화)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "정책의 급격한 변화를 '클리핑(Clipping)'이라는 고삐로 억제하여, 복잡한 환경에서도 무너지지 않는 안정적인 지능의 성장을 견인하라" — OpenAI가 제안한 강화학습 알고리즘으로, 정책 업데이트 폭을 제한함으로써 학습의 안정성과 효율성을 동시에 달성한 현대 RL의 표준 기법. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Clipped Surrogate Objective and Stability-First Learning" — 기존 정책과 새로운 정책 사이의 비율이 특정 범위를 넘지 않도록 강제로 제한(Clipped)함으로써, 단 한 번의 잘못된 업데이트로 모델 전체가 망가지는 현상을 방지하는 패턴. +- **핵심 메커니즘:** + - **Clipped Objective:** 정책 변화율을 [0.8, 1.2] 수준으로 묶어 급격한 변화 억제. + - **Actor-Critic 아키텍처:** 행동을 결정하는 Actor와 가치를 평가하는 Critic을 함께 학습. + - **Multi-epoch Update:** 수집된 데이터를 여러 번 재사용하여 샘플 효율성 증대. +- **의의:** 구현이 비교적 단순하면서도 자율주행, 로봇 제어, 게임 AI, 그리고 LLM의 RLHF(인간 피드백 기반 강화학습) 등 최첨단 분야에서 가장 널리 쓰이는 신뢰도 높은 알고리즘. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 수학적으로는 더 엄밀하지만 구현이 매우 복잡했던 TRPO(Trust Region Policy Optimization)를 실전적인 근사 기법으로 대체하며, '이론적 완벽함'보다 '실전적 견고함'이 더 중요하다는 것을 입증함. +- **정책 변화:** Antigravity 프로젝트는 에이전트의 복합 의사결정 전략 최적화 시, 학습의 발산 위험이 적고 튜닝이 용이한 PPO를 주력 알고리즘으로 채택함. + +## 🔗 지식 연결 (Graph) +- [[Policy-Gradient-Methods]], [[Actor-Critic-Models]], [[Off-policy-vs-On-policy-Learning]], [[Reinforcement-Learning]] +- **Raw Source:** [[10_Wiki/Topics/AI/Proximal-Policy-Optimization.md]] diff --git a/10_Wiki/Topics/AI/Pruning-Techniques.md b/10_Wiki/Topics/AI/Pruning-Techniques.md new file mode 100644 index 00000000..fb47433d --- /dev/null +++ b/10_Wiki/Topics/AI/Pruning-Techniques.md @@ -0,0 +1,28 @@ +--- +id: AI-OPT-PRUNE-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [ai, deep-learning, pruning, model-compression, optimization, inference-speedup, efficiency] +last_reinforced: 2026-04-26 +--- + +# [[Pruning Techniques (가지치기 기법)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "모델의 지능을 훼손하지 않는 선에서 잉여로운 연결(Weights)을 과감히 도려내어, 가볍고 날렵한 '실전용 지능'으로 재탄생시켜라" — 신경망에서 출력에 미치는 영향이 적은 파라미터를 제거함으로써 성능 손실을 최소화하면서 모델의 크기와 연산량을 줄이는 모델 압축 기술. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Importance-based Sparsification and Fine-tuning" — 가중치의 크기(Magnitude)나 기울기(Gradient) 정보를 기준으로 기여도가 낮은 파라미터를 0으로 만들거나(Masking) 아예 제거하고, 남은 파라미터들을 재학습시켜 성능을 복구하는 패턴. +- **주요 분류:** + - **Unstructured Pruning:** 가중치 행렬 내 개별 요소를 무작위로 제거 (높은 압축률, 하드웨어 최적화 어려움). + - **Structured Pruning:** 필터, 채널, 혹은 레이어 전체를 통째로 제거 (연산 속도 향상에 직결). + - **Global vs Local:** 모델 전체에서 하위 n%를 고를지, 층별로 고를지의 차이. +- **의의:** 고가의 서버 없이도 모바일 기기(On-device AI)나 임베디드 시스템에서 딥러닝 모델을 실시간으로 구동할 수 있게 하는 핵심 최적화 전략. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 파라미터가 많을수록 무조건 좋다는 '거대 모델 만능론'에서 벗어나, 적절히 가지치기된 모델이 때로는 노이즈가 제거되어 더 높은 일반화 성능을 보이기도 한다는 '복권 가설(Lottery Ticket Hypothesis)'이 주목받고 있음. +- **정책 변화:** Antigravity 프로젝트는 에이전트의 로컬 실행 모듈 배포 시, 모델 크기를 1/4 이하로 줄이면서도 정확도를 유지하는 구조적 가지치기 파이프라인을 적용함. + +## 🔗 지식 연결 (Graph) +- [[Quantization-Foundations]], [[Knowledge-Distillation-Foundations]], [[Model-Compression-and-Deployment]], [[Optimization-in-AI]] +- **Raw Source:** [[10_Wiki/Topics/AI/Pruning-Techniques.md]] diff --git a/10_Wiki/Topics/AI/PyTorch-Foundations.md b/10_Wiki/Topics/AI/PyTorch-Foundations.md new file mode 100644 index 00000000..4698f29f --- /dev/null +++ b/10_Wiki/Topics/AI/PyTorch-Foundations.md @@ -0,0 +1,29 @@ +--- +id: DL-PYTORCH-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [ai, deep-learning, pytorch, tensors, autograd, framework, python] +last_reinforced: 2026-04-26 +--- + +# [[PyTorch Foundations (PyTorch 기초)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "데이터를 유연한 텐서의 흐름(Tensors)으로 정의하고, 수학적 기울기를 자동으로 추적(Autograd)하여, 파이썬다운 우아함으로 지능의 아키텍처를 구현하라" — 페이스북(현 Meta)에서 개발한 오픈소스 머신러닝 라이브러리로, 동적 계산 그래프와 파이썬 지향적 설계로 현대 딥러닝 연구 및 실무의 표준이 된 프레임워크. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Tensor Operations and Automatic Differentiation" — 다차원 배열 연산을 GPU 가속을 통해 고속으로 처리하고, 복잡한 신경망 연산 과정에서의 미분값을 역전파(Backpropagation) 시점에 자동으로 계산해주는 핵심 패턴. +- **주요 구성 요소:** + - **Tensors:** GPU 가속이 가능한 다차원 배열. PyTorch의 기본 데이터 단위. + - **Autograd:** 미분값 계산을 자동화하는 엔진. + - **nn.Module:** 레이어와 모델 아키텍처를 정의하는 기본 클래스. + - **Optimizers:** 가중치 업데이트 알고리즘 (SGD, Adam 등). +- **의의:** 정적인 그래프 선언 방식(과거 TensorFlow)에서 탈출하여, 코드 실행 중에 그래프를 생성하는 유연성을 제공함으로써 복잡한 모델의 디버깅과 실험 속도를 획기적으로 향상시킴. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 연구용으로는 좋지만 배포용(Production)으로는 부족하다는 비판을 TorchScript와 ONNX 지원을 통해 극복하며, 이제는 연구부터 상용 서비스까지 전 과정을 아우르는 통합 플랫폼으로 성장함. +- **정책 변화:** Antigravity 프로젝트는 에이전트의 내부 학습 로직 및 임베딩 모델 구현 시, 코드 가독성과 커스터마이징 자유도가 높은 PyTorch를 표준 프레임워크로 사용함. + +## 🔗 지식 연결 (Graph) +- [[PyTorch-Lightning]], [[Deep-Learning-Foundations]], [[Backpropagation-Foundations]], [[GPU-Optimization-Foundations]] +- **Raw Source:** [[10_Wiki/Topics/AI/PyTorch-Foundations.md]] diff --git a/10_Wiki/Topics/AI/PyTorch-Lightning.md b/10_Wiki/Topics/AI/PyTorch-Lightning.md new file mode 100644 index 00000000..60c9d62e --- /dev/null +++ b/10_Wiki/Topics/AI/PyTorch-Lightning.md @@ -0,0 +1,28 @@ +--- +id: DL-PY-LIGHT-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [ai, deep-learning, pytorch, pytorch-lightning, scalability, boilerplate-reduction, mlops] +last_reinforced: 2026-04-26 +--- + +# [[PyTorch Lightning (PyTorch 라이트닝)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "반복되는 엔지니어링의 노이즈를 걷어내고, 오직 지능의 '핵심 로직(Research)'에만 집중할 수 있는 표준화된 고속도로를 구축하라" — PyTorch의 유연성을 유지하면서 학습 루프, 하드웨어 설정 등 반복적인 코드를 자동화하여 생산성과 가독성을 극대화하는 경량 래퍼(Wrapper) 프레임워크. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Separation of Concerns and Standardized Training Interface" — 모델의 구조(Model), 데이터 처리(Data), 학습 환경(Trainer)을 명확히 분리하여, 코드 한 줄 변경만으로 CPU에서 멀티 GPU나 TPU로 학습 환경을 즉시 전환할 수 있게 만드는 패턴. +- **핵심 구성 요소:** + - **LightningModule:** 모델 구조, 옵티마이저, 학습/검증 단계를 하나로 캡슐화. + - **Trainer:** 학습 루프 제어, 체크포인트 저장, 로그 관리 자동화. + - **DataModule:** 데이터셋 로드 및 전처리 로직의 재사용성 확보. +- **의의:** 복잡한 딥러닝 실험의 재현성(Reproducibility)을 높이고, 팀 단위 협업 시 코드의 일관성을 유지하며, MLOps로의 전환을 용이하게 함. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 프레임워크가 무거워지면 제어권이 사라질 것이라는 우려를 '훅(Hook)' 기반의 유연한 오버라이딩 설계로 극복하며, 이제는 대규모 언어 모델 학습과 엔터프라이즈급 AI 개발의 필수 도구로 자리 잡음. +- **정책 변화:** Antigravity 프로젝트는 대규모 모델의 분산 학습 및 성능 벤치마킹 시, 코드 유지보수 효율을 위해 PyTorch Lightning 기반의 프로젝트 구조를 권장함. + +## 🔗 지식 연결 (Graph) +- [[PyTorch-Foundations]], [[Deep-Learning-Foundations]], [[System-Design-for-AI-Scale]], [[GPU-Optimization-Foundations]] +- **Raw Source:** [[10_Wiki/Topics/AI/PyTorch-Lightning.md]] diff --git a/10_Wiki/Topics/AI/Python-for-Data-Science.md b/10_Wiki/Topics/AI/Python-for-Data-Science.md new file mode 100644 index 00000000..8dda36b5 --- /dev/null +++ b/10_Wiki/Topics/AI/Python-for-Data-Science.md @@ -0,0 +1,29 @@ +--- +id: DEV-PY-DATA-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [python, data-science, numpy, pandas, matplotlib, scikit-learn, ai-ecosystem] +last_reinforced: 2026-04-26 +--- + +# [[Python for Data Science (데이터 사이언스를 위한 파이썬)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "풍부한 라이브러리 생태계라는 거인의 어깨 위에 올라타서, 복잡한 데이터를 간결한 코드 한 줄로 통찰력 있는 지능으로 변모시켜라" — 데이터 수집, 정제, 분석, 시각화 및 머신러닝 모델 구축에 최적화된 파이썬 언어와 그 핵심 라이브러리들의 집합체. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Library-centric Analysis and Rapid Prototyping" — 핵심 연산은 고속의 C/C++로 구현된 라이브러리(NumPy)에 맡기고, 개발자는 파이썬의 직관적인 문법을 통해 데이터의 흐름과 모델의 로직을 빠르게 실험하고 검증하는 패턴. +- **핵심 생태계 (The Pillars):** + - **NumPy:** 고성능 다차원 배열 연산의 기초. + - **Pandas:** 표 형식 데이터(DataFrames) 조작 및 분석의 표준. + - **Matplotlib / Seaborn:** 데이터 시각화 및 인사이트 도출. + - **Scikit-learn:** 머신러닝 알고리즘의 집대성. +- **의의:** 배우기 쉬운 문법과 거대한 커뮤니티 지원을 통해, 수학자부터 비즈니스 분석가까지 누구나 AI 기술을 실무에 적용할 수 있게 만든 데이터 민주화의 일등 공신. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 실행 속도가 느리다는 약점을 라이브러리 내부의 하드웨어 가속(CUDA 등)과 컴파일 기술(JAX, Numba)로 극복하며, 이제는 연구를 넘어 대규모 프로덕션 환경에서도 대체 불가능한 표준 언어가 됨. +- **정책 변화:** Antigravity 프로젝트의 모든 에이전트 스크립트와 지식 처리 파이프라인은 유지보수성과 라이브러리 호환성을 최우선으로 하여 Python을 주력 언어로 채택함. + +## 🔗 지식 연결 (Graph) +- [[Pre-processing-Data-for-AI]], [[Exploratory-Data-Analysis]], [[PyTorch-Foundations]], [[Open-Source-AI-Ecosystem]] +- **Raw Source:** [[10_Wiki/Topics/AI/Python-for-Data-Science.md]] diff --git a/10_Wiki/Topics/AI/Quantization-Foundations.md b/10_Wiki/Topics/AI/Quantization-Foundations.md new file mode 100644 index 00000000..d17e89ec --- /dev/null +++ b/10_Wiki/Topics/AI/Quantization-Foundations.md @@ -0,0 +1,28 @@ +--- +id: AI-OPT-QUAN-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [ai, deep-learning, quantization, model-compression, int8, fp16, optimization, inference-speedup] +last_reinforced: 2026-04-26 +--- + +# [[Quantization Foundations (양자화 기초)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "정밀한 부동소수점(FP32)의 사치를 버리고 거친 정수(INT8)의 효율을 선택하여, 지능을 비트 단위로 압축하고 실행 속도를 극한으로 끌어올려라" — 신경망의 가중치와 활성화 함수 값을 더 낮은 비트의 정밀도로 표현함으로써 모델 크기를 줄이고 추론 속도를 높이는 최적화 기술. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Precision-Throughput Tradeoff and Range Mapping" — 32비트 부동소수점 데이터를 8비트 정수 등으로 매핑할 때 정보 손실을 최소화하기 위해 스케일(Scale)과 제로포인트(Zero-point)를 계산하고, 하드웨어의 정수 연산 가속기(Tensor Cores 등)를 최대한 활용하는 패턴. +- **주요 기법:** + - **PTQ (Post-Training Quantization):** 학습이 끝난 모델을 간단한 보정(Calibration)을 통해 즉시 양자화. 편리함. + - **QAT (Quantization Aware Training):** 학습 과정에서 양자화로 인한 오차를 미리 고려하여 학습. 높은 정확도 유지. + - **Weight-only vs Full Quantization:** 가중치만 줄일지, 연산 과정 전체를 줄일지의 차이. +- **의의:** 수백 기가바이트의 LLM 모델을 일반 PC나 모바일 기기 메모리에 담을 수 있게 하는 '마법 같은 다이어트' 기술이며, 엣지 컴퓨팅의 필수 요건. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 비트를 줄이면 지능이 크게 떨어질 것이라는 초기 우려와 달리, 현대의 4비트(NF4) 혹은 8비트 양자화 기술은 32비트 원본 대비 성능 저하를 1~2% 내외로 방어하며 실용성을 입증함. +- **정책 변화:** Antigravity 프로젝트는 에이전트의 온디바이스 배포 및 추론 비용 절감을 위해, 모든 주력 모델에 대해 INT8 혹은 FP16 양자화를 기본 적용함. + +## 🔗 지식 연결 (Graph) +- [[Pruning-Techniques]], [[Model-Compression-and-Deployment]], [[NVIDIA-CUDA-and-AI]], [[Optimization-in-AI]] +- **Raw Source:** [[10_Wiki/Topics/AI/Quantization-Foundations.md]] diff --git a/10_Wiki/Topics/AI/Quantum-Machine-Learning.md b/10_Wiki/Topics/AI/Quantum-Machine-Learning.md new file mode 100644 index 00000000..984aeeec --- /dev/null +++ b/10_Wiki/Topics/AI/Quantum-Machine-Learning.md @@ -0,0 +1,28 @@ +--- +id: AI-QUANTUM-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [ai, quantum-computing, quantum-machine-learning, qubits, superposition, entanglement, future-tech] +last_reinforced: 2026-04-26 +--- + +# [[Quantum Machine Learning (양자 머신러닝)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "0과 1의 이진법적 한계를 넘어 양자의 중첩(Superposition) 위에서 지능을 계산하고, 기하급수적인 연산의 속도로 정답의 확률 분포를 인양하라" — 양자 컴퓨터의 특유한 물리 현상을 활용하여 머신러닝 알고리즘의 성능을 획기적으로 개선하거나 새로운 형태의 지능형 연산을 수행하는 연구 분야. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Quantum Parallelism and High-dimensional Kernel Mapping" — 큐비트(Qubits)의 중첩을 통해 방대한 경우의 수를 동시에 계산하고, 양자 상태의 얽힘(Entanglement)을 이용해 복잡한 변수 간의 상관관계를 고전 컴퓨터보다 훨씬 높은 차원에서 파악하는 패턴. +- **주요 접근 방식:** + - **Quantum-Classical Hybrid:** 연산량이 많은 부분은 양자 프로세서(QPU)가, 전체 제어는 고전 CPU가 담당 (예: VQE, QAOA). + - **Quantum Kernels:** 데이터를 양자 상태로 매핑하여 기존에 보지 못한 특징 공간에서 분류 수행. + - **Quantum Neural Networks (QNN):** 양자 회로의 파라미터를 학습시키는 형태의 신경망. +- **의의:** 현재의 고전적 하드웨어가 직면한 '연산량 폭발'과 '에너지 효율' 문제를 근본적으로 해결할 수 있는 잠재력을 지닌 미래 지능의 종착지 중 하나. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 이론상으로는 완벽하지만 실제로는 노이즈가 너무 심해 무용지물이라는 비판을, 최근의 NISQ(중간 규모 노이즈 양자 장치) 시대 최적화 기법들과 양자 오차 교정(Error Correction) 기술의 발전으로 극복해 나가는 중임. +- **정책 변화:** Antigravity 프로젝트는 당장의 실무 적용보다는 장기적 R&D 관점에서 양자 머신러닝의 알고리즘 원리를 모니터링하며, 향후 암호 해독 및 신소재 시뮬레이션 관련 지식 강화 시 이를 핵심 엔진으로 검토함. + +## 🔗 지식 연결 (Graph) +- [[High-Performance-Computing-HPC]], [[Optimization-Algorithms]], [[Linear-Algebra-Foundations]], [[Trustworthy-AI]] +- **Raw Source:** [[10_Wiki/Topics/AI/Quantum-Machine-Learning.md]] diff --git a/10_Wiki/Topics/AI/Queue-Management-Systems.md b/10_Wiki/Topics/AI/Queue-Management-Systems.md new file mode 100644 index 00000000..e5956aa8 --- /dev/null +++ b/10_Wiki/Topics/AI/Queue-Management-Systems.md @@ -0,0 +1,29 @@ +--- +id: SYS-QUEUE-MGMT-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [infrastructure, systems, queue-management, message-broker, rabbitmq, kafka, redis, asynchronous] +last_reinforced: 2026-04-26 +--- + +# [[Queue Management Systems (큐 관리 시스템)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "폭주하는 요청 앞에 '완충 지대(Buffer)'를 구축하여 시스템의 붕괴를 막고, 비동기적 흐름의 질서를 세워 전체적인 처리량(Throughput)을 극대화하라" — 작업을 즉시 처리하는 대신 대기열(Queue)에 보관했다가 순차적으로 처리함으로써 시스템 부하를 조절하고 서비스 간 결합도를 낮추는 인프라 관리 체계. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Producer-Consumer Decoupling and Load Leveling" — 요청을 생성하는 쪽(Producer)과 처리하는 쪽(Consumer) 사이에 중계자(Queue/Broker)를 두어, 어느 한쪽의 속도 변화나 장애가 전체 시스템에 영향을 주지 않도록 격리하는 패턴. +- **주요 도구 및 특성:** + - **RabbitMQ:** 복잡한 라우팅과 메시지 보증이 필요한 업무에 적합. + - **Apache Kafka:** 대규모 로그 및 실시간 스트림 데이터 처리에 최적화. + - **Redis (Pub/Sub):** 초고속 인메모리 기반의 단순 메시지 전달. + - **SQS (AWS):** 클라우드 기반의 관리형 큐 서비스. +- **의의:** 서비스가 갑작스러운 트래픽 급증(Traffic Spike)에도 버틸 수 있게 하며, 무거운 작업(이미지 처리, 대량 메일 발송 등)을 백그라운드로 돌려 사용자 응답 속도를 높임. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 단순히 데이터를 순서대로 쌓아두는 '창고' 역할을 넘어, 이제는 데이터의 유실을 방지하는 영속성(Persistence) 보장과 분산 처리를 통한 수평적 확장성(Scalability)이 큐 시스템 선택의 핵심 기준이 됨. +- **정책 변화:** Antigravity 프로젝트는 에이전트의 대규모 지식 보강 작업 시, 개별 문서 보강 요청을 큐에 적재하고 가용 자원에 맞춰 병렬 처리함으로써 시스템 리소스의 효율을 극대화함. + +## 🔗 지식 연결 (Graph) +- [[Parallel-Computing-in-AI]], [[System-Design-for-AI-Scale]], [[High-Availability-Systems]], [[Message-Queues-Foundations]] +- **Raw Source:** [[10_Wiki/Topics/AI/Queue-Management-Systems.md]] diff --git a/10_Wiki/Topics/AI/RAG-and-Document-Retrieval.md b/10_Wiki/Topics/AI/RAG-and-Document-Retrieval.md new file mode 100644 index 00000000..a36ad995 --- /dev/null +++ b/10_Wiki/Topics/AI/RAG-and-Document-Retrieval.md @@ -0,0 +1,28 @@ +--- +id: AI-RAG-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [ai, llm, rag, retrieval-augmented-generation, vector-database, semantic-search, embeddings] +last_reinforced: 2026-04-26 +--- + +# [[RAG and Document Retrieval (RAG와 문서 검색)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "모델의 기억력에만 의존하지 말고, 방대한 지식의 도서관(External Knowledge)에서 근거를 직접 찾아보고 말하게 하여 지능의 신뢰도를 완성하라" — 거대 언어 모델이 학습하지 않은 최신 데이터나 비공개 문서를 실시간으로 검색하여 답변의 정확성을 높이고 환각 현상을 줄이는 기술. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Retrieve-Read-Refine" — 사용자의 질문을 벡터로 변환하여 지식 저장소에서 가장 유사한 문맥을 찾아내고(Retrieve), 이를 질문과 함께 모델에 전달하여(Read), 모델이 근거 중심의 정확한 답변을 생성하게 하는(Refine) 패턴. +- **핵심 구성 요소:** + - **Embeddings:** 텍스트의 의미를 숫자의 나열(Vector)로 변환. + - **Vector Database:** 수백만 개의 벡터 사이에서 가장 닮은 것을 순식간에 찾는 저장소 (Pinecone, Milvus, Chroma 등). + - **Semantic Search:** 단순 키워드 매칭이 아닌 '의미적 유사성'을 기반으로 검색. +- **의의:** 매번 모델을 새로 학습(Fine-tuning)시키지 않고도 최신 지식을 즉각적으로 주입할 수 있으며, 답변의 출처를 명확히 제시하여 사용자의 신뢰를 확보함. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 단순히 많은 문서를 찾는 것이 좋다는 시각에서 벗어나, 이제는 모델에게 꼭 필요한 '핵심 문맥'만을 골라내는 정밀한 랭킹(Reranking) 기술과 긴 문맥을 소화하는 능력이 RAG 성능의 핵심 경쟁력이 됨. +- **정책 변화:** Antigravity 프로젝트는 1,174개 지식 문서의 유기적 연결을 위해 고도화된 RAG 엔진을 내장하며, 에이전트가 답변 시 반드시 위키 내의 관련 문서를 참조하여 답변하도록 강제함. + +## 🔗 지식 연결 (Graph) +- [[Natural-Language-Processing-NLP]], [[Prompt-Engineering-Foundations]], [[Vector-Database-Foundations]], [[Knowledge-Gardening-Workflow]] +- **Raw Source:** [[10_Wiki/Topics/AI/RAG-and-Document-Retrieval.md]] diff --git a/10_Wiki/Topics/AI/Random-Forest-Classifiers.md b/10_Wiki/Topics/AI/Random-Forest-Classifiers.md new file mode 100644 index 00000000..e08985ef --- /dev/null +++ b/10_Wiki/Topics/AI/Random-Forest-Classifiers.md @@ -0,0 +1,28 @@ +--- +id: ML-RAND-FOR-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [machine-learning, random-forest, ensemble-learning, bagging, decision-tree, classification] +last_reinforced: 2026-04-26 +--- + +# [[Random Forest Classifiers (랜덤 포레스트 분류기)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "한 그루의 나무(Decision Tree)는 편견에 빠지기 쉽지만, 수많은 나무가 모인 숲(Random Forest)은 집단의 지혜로 진실을 꿰뚫는다" — 여러 개의 결정 트리를 독립적으로 학습시킨 후, 그 결과를 다수결(투표)이나 평균으로 합쳐서 예측의 정확도와 안정성을 높이는 앙상블 머신러닝 기법. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Bagging and Feature Randomization" — 데이터의 일부를 무작위로 샘플링(Bootstrap)하고, 트리의 마디를 나눌 때도 전체 변수가 아닌 일부 변수만 무작위로 선택하여, 각 트리들이 서로 다른 시각에서 데이터를 바라보게 함으로써 과적합을 방지하는 패턴. +- **주요 장점:** + - **Robustness:** 이상치나 노이즈가 섞인 데이터에서도 안정적인 성능 유지. + - **No Scaling Required:** 데이터의 정규화나 표준화 없이도 잘 작동함. + - **Feature Importance:** 어떤 변수가 예측에 가장 중요한지 수치로 제시 가능. +- **의의:** 딥러닝이 지배하는 이미지/언어 영역 외의 '정형 데이터(테이블 형식)' 분석에서 가장 먼저 고려되는 강력하고 믿음직한 베이스라인 모델. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 단순히 나무를 많이 심는다고 좋은 것이 아니라, 각 나무 사이의 상관관계를 줄여 다양성을 확보하는 것이 숲의 성능을 결정한다는 점이 현대 앙상블 이론의 핵심임. +- **정책 변화:** Antigravity 프로젝트는 에이전트의 도구 선택 로직이나 작업 성공 여부 판단 시, 설명 가능성과 정확도의 균형을 위해 랜덤 포레스트 기반의 분류 모델을 우선적으로 검토함. + +## 🔗 지식 연결 (Graph) +- [[Ensemble-Learning-Foundations]], [[Overfitting-and-Underfitting]], [[Gradient-Boosting-Machines-GBM]], [[Pre-processing-Data-for-AI]] +- **Raw Source:** [[10_Wiki/Topics/AI/Random-Forest-Classifiers.md]] diff --git a/10_Wiki/Topics/AI/Randomized-Algorithms.md b/10_Wiki/Topics/AI/Randomized-Algorithms.md new file mode 100644 index 00000000..c8758daa --- /dev/null +++ b/10_Wiki/Topics/AI/Randomized-Algorithms.md @@ -0,0 +1,27 @@ +--- +id: ALGO-RAND-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [algorithm, math, randomized-algorithms, probability, monte-carlo, las-vegas, complexity-theory] +last_reinforced: 2026-04-26 +--- + +# [[Randomized Algorithms (확률적 알고리즘)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "완벽한 정답을 위한 끝없는 계산보다, '적당한 무작위성'을 가미하여 기하급수적인 연산 속도와 충분히 훌륭한 해답을 쟁취하라" — 알고리즘의 동작 과정에 무작위성(Randomness)을 도입하여, 평균적으로 우수한 성능을 내거나 매우 복잡한 문제를 효율적으로 해결하는 방법론. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Stochastic Exploration and Error Probability Management" — 모든 경우의 수를 따지는 대신 무작위 샘플링을 통해 정답에 근접하고(Monte Carlo), 혹은 항상 정답을 내놓되 실행 시간을 확률적으로 단축하는(Las Vegas) 패턴. +- **주요 알고리즘 분류:** + - **Las Vegas Algorithms:** 항상 정확한 정답을 내놓지만, 실행 시간이 확률 변수임 (예: Randomized QuickSort). + - **Monte Carlo Algorithms:** 정해진 시간 내에 실행되지만, 결과에 미세한 오차 가능성이 있음 (예: MCTS). +- **의의:** 결정론적(Deterministic) 알고리즘으로는 풀기 어려운 거대 규모의 데이터셋이나 복잡한 최적화 문제에서 '실용적인 효율성'을 보장하는 핵심 도구. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 무작위성은 '운'에 의존한다는 고정관념을 깨고, 이제는 알고리즘 설계에서 최악의 경우(Worst-case)를 방지하고 평균적인 성능을 극대화하기 위한 가장 정교한 수학적 장치로 평가됨. +- **정책 변화:** Antigravity 프로젝트는 에이전트의 경로 탐색(Search)이나 대규모 문서 샘플링 시, 연산 자원을 아끼면서도 대표성 있는 결과를 얻기 위해 다양한 확률적 알고리즘 기법을 적용함. + +## 🔗 지식 연결 (Graph) +- [[Monte-Carlo-Tree-Search-MCTS]], [[Probability-Theory-Foundations]], [[Optimization-Algorithms]], [[Ranking-Algorithms]] +- **Raw Source:** [[10_Wiki/Topics/AI/Randomized-Algorithms.md]] diff --git a/10_Wiki/Topics/AI/Ranking-Algorithms.md b/10_Wiki/Topics/AI/Ranking-Algorithms.md new file mode 100644 index 00000000..e777abb9 --- /dev/null +++ b/10_Wiki/Topics/AI/Ranking-Algorithms.md @@ -0,0 +1,28 @@ +--- +id: ALGO-RANK-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [algorithm, search-engine, ranking, learning-to-rank, pagerank, ndcg, relevance] +last_reinforced: 2026-04-26 +--- + +# [[Ranking Algorithms (순위 산정 알고리즘)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "데이터의 평등한 나열에서 벗어나 가치와 관련성의 위계를 세우고, 사용자의 시선이 머무는 최상단에 가장 날카로운 정답을 배치하라" — 주어진 쿼리나 맥락에 대해 아이템(문서, 상품 등)의 상대적인 중요도나 관련성을 계산하여 순서를 매기는 알고리즘. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Feature-based Scoring and Relative Ordering" — 아이템의 텍스트 매칭도(BM25), 인기도(Click-through rate), 신뢰도(PageRank) 등 다양한 특징을 점수화하고, 이를 바탕으로 사용자가 가장 만족할 만한 순서로 재배열하는 패턴. +- **주요 기법:** + - **PageRank:** 링크 구조를 분석하여 웹페이지의 권위도(Authority) 산출. + - **Learning to Rank (LTR):** 머신러닝을 통해 최적의 순위 산정 함수를 학습 (Pointwise, Pairwise, Listwise 접근법). + - **Evaluation Metrics:** NDCG (관련 높은 아이템이 상단에 있는지 측정), MRR. +- **의의:** 검색 엔진, 이커머스 추천, 뉴스 피드 등 정보를 소비하는 모든 플랫폼의 사용자 경험(UX)을 결정짓는 핵심 지능. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 단순히 키워드가 많이 포함된 순서로 나열하던 방식에서, 이제는 사용자의 의도(Intent)와 맥락(Personalization)을 실시간으로 반영하여 '나만을 위한 순위'를 제공하는 시맨틱 랭킹으로 진화함. +- **정책 변화:** Antigravity 프로젝트는 에이전트가 지식 베이스를 검색할 때, 단순 유사도 점수 외에도 문서의 최신성, 신뢰도, 연결 밀도를 종합하여 최적의 참고 문헌 순위를 산정하는 커스텀 랭킹 엔진을 사용함. + +## 🔗 지식 연결 (Graph) +- [[Natural-Language-Processing-NLP]], [[Recommendation-Systems]], [[Performance-Metrics-in-AI]], [[Vector-Database-Foundations]] +- **Raw Source:** [[10_Wiki/Topics/AI/Ranking-Algorithms.md]] diff --git a/10_Wiki/Topics/AI/Real-time-Data-Streaming.md b/10_Wiki/Topics/AI/Real-time-Data-Streaming.md new file mode 100644 index 00000000..cf5a619f --- /dev/null +++ b/10_Wiki/Topics/AI/Real-time-Data-Streaming.md @@ -0,0 +1,28 @@ +--- +id: SYS-STREAM-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [infrastructure, systems, streaming, real-time, kafka, flink, data-engineering, event-driven] +last_reinforced: 2026-04-26 +--- + +# [[Real-time Data Streaming (실시간 데이터 스트리밍)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "데이터를 거대한 호수에 가두어 썩게 두지 말고, 쉼 없이 흐르는 강물처럼 실시간으로 분석하여 찰나의 가치를 통찰로 포착하라" — 끊임없이 생성되는 데이터(Events)를 지연 시간(Latency) 없이 실시간으로 수집, 처리, 분석하는 컴퓨팅 아키텍처. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Event-driven Orchestration and Continuous Aggregation" — 데이터가 발생하는 즉시 이벤트로 발행하고, 이를 스트림 처리 엔진이 구독하여 윈도우(Windowing) 연산이나 상태(State) 관리를 통해 실시간 집계 결과를 산출하는 패턴. +- **핵심 기술 구성:** + - **Message Broker (Kafka):** 대량의 스트림 데이터를 유실 없이 전달하는 파이프라인. + - **Stream Processing (Flink, Spark Streaming):** 흐르는 데이터에 대한 필터링, 조인, 집계 수행. + - **Time Handling:** 이벤트 발생 시간(Event Time)과 처리 시간(Processing Time)의 구분 관리. +- **의의:** 금융권의 실시간 사기 탐지(FDS), 이커머스의 실시간 개인화 추천, 자율주행 센서 데이터의 즉각적 반응 등 '시간이 곧 가치'인 모든 현대적 시스템의 중추. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 하루 한 번 모아서 처리하던 배치(Batch) 처리 방식에서 벗어나, 이제는 모든 데이터를 스트림으로 보고 배치를 스트림의 특수한 경우(Bounded Stream)로 취급하는 '통합 데이터 처리' 패러다임이 확산됨. +- **정책 변화:** Antigravity 프로젝트는 에이전트의 실시간 모니터링 로그 및 사용자 인터랙션 데이터를 스트리밍 방식으로 처리하여, 즉각적인 성능 대시보드 업데이트와 이상 징후 감지를 수행함. + +## 🔗 지식 연결 (Graph) +- [[Queue-Management-Systems]], [[System-Design-for-AI-Scale]], [[High-Availability-Systems]], [[Predictive-Analytics]] +- **Raw Source:** [[10_Wiki/Topics/AI/Real-time-Data-Streaming.md]] diff --git a/10_Wiki/Topics/AI/Recommendation-Systems.md b/10_Wiki/Topics/AI/Recommendation-Systems.md new file mode 100644 index 00000000..ac3fe607 --- /dev/null +++ b/10_Wiki/Topics/AI/Recommendation-Systems.md @@ -0,0 +1,29 @@ +--- +id: BIZ-REC-SYS-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [ai, machine-learning, recommendation-systems, collaborative-filtering, matrix-factorization, personalization, deep-learning] +last_reinforced: 2026-04-26 +--- + +# [[Recommendation Systems (추천 시스템)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "사용자의 과거와 타인의 선택 속에 숨겨진 '취향의 좌표'를 찾아내어, 사용자가 미처 인지하지 못한 잠재적 욕망을 선제적으로 제안하라" — 사용자의 이력과 선호도를 분석하여 개인에게 가장 적합한 아이템(콘텐츠, 상품 등)을 선별해주는 지능형 큐레이션 시스템. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Preference Matching and Latent Feature Discovery" — 사용자-아이템 간의 거대한 상호작용 행렬을 분해하여 숨겨진 특징(Latent Factors)을 찾아내거나(Matrix Factorization), 유사한 취향의 이웃을 찾아 그들의 선택을 추천하는 패턴. +- **주요 알고리즘:** + - **Collaborative Filtering:** "나와 비슷한 사람들은 이것도 샀다" (User-based, Item-based). + - **Content-based Filtering:** "내가 본 것과 비슷한 특성을 가진 아이템이다." + - **Hybrid Systems:** 두 방식의 장점을 결합하여 콜드 스타트(Cold Start) 문제 해결. + - **Deep Learning for Recs:** 복잡한 비정형 데이터와 문맥을 반영한 고도화된 추천. +- **의의:** 정보 과부하 환경에서 사용자의 탐색 비용을 획기적으로 낮추고, 플랫폼의 체류 시간과 매출을 극대화하는 비즈니스 지능의 정수. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 단순히 과거 이력만 반복 추천하여 사용자를 '필터 버블(Filter Bubble)'에 가두던 단계에서, 이제는 탐험(Exploration)과 활용(Exploitation)의 균형을 맞추어 사용자의 취향 외연을 확장하는 강화학습 기반 추천으로 진화 중. +- **정책 변화:** Antigravity 프로젝트는 위키 지식 탐색 시, 현재 읽고 있는 문서와 의미적으로 가장 가깝거나 보완적인 관계에 있는 '다음에 읽을만한 주제'를 추천하는 지능형 지식 내비게이션 기능을 제공함. + +## 🔗 지식 연결 (Graph) +- [[Ranking-Algorithms]], [[Matrix-Factorization-Operations]], [[Reinforcement-Learning]], [[Vector-Database-Foundations]] +- **Raw Source:** [[10_Wiki/Topics/AI/Recommendation-Systems.md]] diff --git a/10_Wiki/Topics/AI/Recurrent-Neural-Networks.md b/10_Wiki/Topics/AI/Recurrent-Neural-Networks.md new file mode 100644 index 00000000..d2d70433 --- /dev/null +++ b/10_Wiki/Topics/AI/Recurrent-Neural-Networks.md @@ -0,0 +1,28 @@ +--- +id: DL-RNN-001 +category: "[[10_Wiki/💡 Topics/AI]]" +confidence_score: 1.0 +tags: [ai, deep-learning, rnn, sequential-data, lstm, gru, nlp, time-series] +last_reinforced: 2026-04-26 +--- + +# [[Recurrent Neural Networks (RNN, 순환 신경망)]] + +## 📌 한 줄 통찰 (The Karpathy Summary) +> "과거의 기억(Hidden State)을 현재의 입력과 섞어 끊임없이 순환시키며, 데이터 속에 숨겨진 '시간의 인과'와 '문맥의 흐름'을 포착하라" — 입력과 출력을 시퀀스 단위로 처리하여, 이전 단계의 정보가 다음 단계의 출력에 영향을 주도록 설계된 신경망 아키텍처. + +## 📖 구조화된 지식 (Synthesized Content) +- **추출된 패턴:** "Temporal Recurrence and Hidden State Memory" — 현재의 출력값이 이전의 은닉 상태(Hidden State)에 의존하게 함으로써, 데이터가 들어온 순서(Sequence)를 인지하고 가변적인 길이의 입력을 처리할 수 있게 하는 패턴. +- **주요 진화 및 한계:** + - **Vanilla RNN:** 정보가 길어질수록 앞부분의 정보를 잊어버리는 '장기 의존성(Long-term Dependency)' 문제와 기울기 소실 발생. + - **LSTM (Long Short-Term Memory):** 게이트(Gate) 구조를 도입하여 어떤 정보를 기억하고 지울지 스스로 결정. 장기 기억 능력 획득. + - **GRU:** LSTM을 간소화하여 연산 효율성 증대. +- **의의:** 텍스트 번역, 음성 인식, 주가 예측 등 순서와 맥락이 중요한 모든 시퀀스 데이터 분석의 지평을 연 핵심 기술. + +## ⚠️ 모순 및 업데이트 (Contradictions & RL Update) +- **과거 데이터와의 충돌:** 한 번에 하나의 단어만 처리하는 순차성 때문에 병렬 처리가 어렵다는 한계를 깨고, 현재는 모든 데이터를 한꺼번에 병렬로 보며 관계를 파악하는 '트랜스포머(Transformer)'가 주류가 되었으나, 초경량 실시간 시계열 예측에서는 여전히 RNN 계열이 효율적임. +- **정책 변화:** Antigravity 프로젝트는 에이전트의 로그 시퀀스 분석이나 실시간 센서 스트림 데이터 처리 시, 지연 시간(Latency)이 극히 낮은 RNN 기반의 경량 모델을 선별적으로 활용함. + +## 🔗 지식 연결 (Graph) +- [[Natural-Language-Processing-NLP]], [[Long-Short-Term-Memory-LSTM]], [[Time-Series-Analysis]], [[Deep-Learning-Foundations]] +- **Raw Source:** [[10_Wiki/Topics/AI/Recurrent-Neural-Networks.md]]