feat: Knowledge Gardening Milestone 450 (Batch #23)
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,22 @@
|
||||
# [[Component-Based Architecture]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Component-Based Architecture(컴포넌트 기반 아키텍처)는 사용자 인터페이스(UI)를 재사용 가능한 독립적인 컴포넌트 단위로 분해하여 구성하는 아키텍처 패턴입니다 [1, 2]. 이 설계 방식은 일관성 있는 디자인 시스템을 구축하고, 코드 재사용을 장려하며, 개발자와 디자이너 간의 공통 어휘를 확립하는 데 탁월한 효과를 발휘합니다 [1]. 그러나 비즈니스 로직이나 상태(State)의 구성 방법에 대해서는 명확한 기준을 제시하지 않으므로, 대규모 애플리케이션에서는 구조화된 아키텍처를 추가로 도입하지 않으면 로직 계층이 무질서해질 수 있는 한계를 지닙니다 [1].
|
||||
|
||||
## 📖 Core Content
|
||||
* **UI 분해(UI Decomposition)와 디자인 시스템 지향:**
|
||||
리액트(React)는 본질적으로 컴포넌트 기반으로 작동하며, 컴포넌트 기반 아키텍처의 핵심 원칙은 UI를 세분화하여 구성하는 것입니다 [1, 2]. 이 구조는 최신 사용자 인터페이스와 디자인 시스템을 설계할 때 가장 적합한 모델로 평가받으며, 아토믹 디자인(Atomic Design)과 같은 방법론을 통해 시각적 일관성과 컴포넌트의 강력한 재사용성을 제공합니다 [1, 2].
|
||||
|
||||
* **대규모 확장성의 한계 (구조적 부족함):**
|
||||
컴포넌트 기반 아키텍처는 UI 요소를 깔끔하게 추상화하는 데 성공적이지만, 비즈니스 로직이나 상태 관리(State Management)를 어디에 어떻게 배치해야 하는지는 의도적으로 규정하지 않습니다 [1]. 이로 인해 적절한 제약 없이 개발을 진행하면 잘 정돈된 UI 컴포넌트 아래에 비즈니스 로직이 혼란스럽게 뒤섞이는 현상이 발생합니다 [1]. 따라서 애플리케이션의 규모가 커질 경우, 컴포넌트 기반 방식 단독으로는 불충분하며 기능 분할 설계(Feature-Sliced Design)나 도메인 주도 설계(DDD)와 같은 추가적인 아키텍처의 도입이 필요합니다 [1, 3, 4].
|
||||
|
||||
* **클린 코드와 설계 원칙의 적용:**
|
||||
유지보수 가능성을 높이기 위해 컴포넌트 설계 시 객체 지향 및 소프트웨어 엔지니어링 원칙을 적용할 수 있습니다. 예를 들어, 개방-폐쇄 원칙(OCP)을 리액트의 `children` prop이나 렌더 프롭(render props)을 통한 합성(Composition) 기능으로 구현하면, 기존 컴포넌트의 소스 코드를 수정하지 않고도 새로운 기능을 유연하게 확장할 수 있습니다 [5]. 또한, 컴포넌트가 너무 커지고 여러 책임(데이터 페칭, 상태 관리, 렌더링 등)을 지게 되면 단일 책임 원칙(SRP)에 따라 더 작고 집중된 컴포넌트로 분리하여 관리해야 합니다 [6].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Atomic Design]], [[Feature-Sliced Design]], [[SOLID Principles]]
|
||||
- **Projects/Contexts:** [[React Application Architecture]], [[Design Systems]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 컴포넌트 기반 아키텍처(또는 아토믹 디자인)는 훌륭한 UI 시스템 구축을 가능하게 하지만, 상태 소유권과 비즈니스 로직 구성에 대한 규칙이 없기 때문에 규모가 큰 리액트 애플리케이션의 아키텍처로는 불충분하다고 주장합니다 [1].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[Domain-Driven Design]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
도메인 주도 설계(Domain-Driven Design, DDD)는 기술적인 파일 유형이나 계층이 아닌 비즈니스 개념(예: 사용자, 주문, 결제 등)을 중심으로 프론트엔드 코드를 구성하는 아키텍처 접근법이다 [1]. 이 방식은 코드의 응집력을 높이고 비즈니스 이해관계자와의 원활한 소통을 돕지만, 프론트엔드 환경을 위한 구체적이고 표준화된 폴더 구조를 제공하지는 않는다는 한계가 있다 [1]. 이러한 개념은 최근 프론트엔드 생태계에서 기능 단위로 코드를 그룹화하는 기능 기반(Feature-based) 또는 도메인 기반(Domain-based) 디렉토리 구조 및 기능 분할 설계(Feature-Sliced Design)로 진화하여 확장성을 높이는 모범 사례로 활용되고 있다 [2-5].
|
||||
|
||||
## 📖 Core Content
|
||||
* **비즈니스 개념 중심의 아키텍처 구성:** 프론트엔드에서의 DDD는 단순한 사용자 인터페이스(UI) 개발을 넘어 비즈니스 도메인을 중심으로 코드를 그룹화한다 [1]. 이는 데이터를 다루거나 기술적 역할(컴포넌트, 훅, 서비스 등)별로 파일을 나누던 기존의 계층형 아키텍처(Layered Architecture)의 한계를 극복하며, 복잡한 비즈니스 로직을 처리하는 데 최적화되어 있다 [1, 6].
|
||||
* **프론트엔드 구현의 한계:** 순수한 도메인 주도 설계는 프론트엔드에 필요한 구체적이고 표준화된 폴더 구조를 제공하지 않는다 [1]. 이로 인해 개발 팀은 여러 도메인에서 공유하는 UI, 교차 도메인 기능 및 인프라 코드를 어디에 배치해야 할지 결정하는 데 종종 어려움을 겪는다 [1].
|
||||
* **기능 분할 설계(Feature-Sliced Design, FSD)로의 진화:** DDD의 한계를 극복하기 위해 프론트엔드 생태계에서는 기능 분할 설계(FSD)라는 구체적인 방법론이 등장했다 [2, 4]. FSD는 DDD와 개념적 유사성을 공유하면서도 React의 컴포넌트 기반 특성에 맞게 조정되었으며, 도메인 중심 원칙, 컴포넌트 기반 개발, 모듈형 시스템 아키텍처를 결합하여 명확한 경계와 계층 구조를 제공한다 [2, 4].
|
||||
* **모던 프론트엔드의 디렉토리 구조 모범 사례:** 2025년 기준, 프론트엔드 개발 산업 표준은 기능 기반 구조(Feature-based structure) 또는 도메인 기반 구조(Domain-based structure)로 이동했다 [3]. 컴포넌트 종류가 아닌 기능 및 도메인을 기준으로 컴포넌트, 훅, 로직을 분리하면 기능 간의 숨겨진 결합을 방지하고 코드베이스의 확장성과 유지보수성을 극대화할 수 있다 [3, 5].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Feature-Sliced Design]], [[Component-Based Architecture]], [[Layered Architecture]]
|
||||
- **Projects/Contexts:** [[Scalable React Architecture]], [[Frontend Folder Structure]]
|
||||
- **Contradictions/Notes:** 소스 [1]는 DDD가 공유 UI나 공통 인프라 코드를 배치할 구체적이고 표준화된 프론트엔드 폴더 구조를 제공하지 못하는 한계가 있다고 지적합니다. 그러나 소스 [2, 4]에 따르면, 기능 분할 설계(FSD)가 DDD의 비즈니스 중심 원칙을 차용하면서도 프론트엔드에 특화된 구체적인 계층(Layers)과 슬라이스(Slices) 구조를 제공함으로써 이러한 단점을 보완하고 있음을 알 수 있습니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,36 @@
|
||||
# [[대규모 React 애플리케이션 및 엔터프라이즈 시스템 확장성 관리]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
대규모 React 애플리케이션 및 엔터프라이즈 시스템 확장성 관리는 코드가 비대해짐에 따라 발생하는 유지보수성 및 성능 저하 문제를 방지하기 위해 엄격한 아키텍처와 엔지니어링 원칙을 적용하는 과정입니다. 기능 분할 설계(Feature-Sliced Design), 명확한 명명 규칙, 효율적인 상태 관리 전략, 그리고 최신 성능 최적화 기법을 도입하여 코드베이스를 모듈화합니다. 이를 통해 다수의 개발자가 협업하는 환경에서도 높은 응집도와 낮은 결합도를 유지하며 시스템을 안정적으로 성장시킬 수 있습니다.
|
||||
|
||||
## 📖 Core Content
|
||||
**1. 아키텍처 및 폴더 구조 (Architecture & Folder Structure)**
|
||||
* **기능 기반 구조(Feature-based Structure)로의 전환:** 단순한 기술적 역할(components, hooks 등) 기반의 폴더 구조는 애플리케이션이 커질수록 관련 파일들이 흩어져 확장에 불리합니다 [1, 2]. 2025년의 엔터프라이즈 권장 표준은 비즈니스 로직과 도메인을 중심으로 코드를 구성하는 기능 기반 구조입니다 [3-6].
|
||||
* **기능 분할 설계(Feature-Sliced Design, FSD):** FSD는 의존성 제어를 위해 구조를 `app`, `pages`, `widgets`, `features`, `entities`, `shared`의 엄격한 계층(Layer)으로 나눕니다 [7, 8]. 상위 계층은 하위 계층에만 의존해야 하는 단방향 의존성 규칙을 강제하여 순환 참조를 방지합니다 [7, 9]. 또한, 각 슬라이스(Slice)는 `index.ts`를 단일 진입점(Public API)으로 노출해 내부 구현을 캡슐화해야 합니다 [10-12].
|
||||
|
||||
**2. 대규모 상태 관리 전략 (State Management Strategy)**
|
||||
* **상태의 파편화 및 전문화:** 단일 저장소 대신 데이터 특성에 따라 도구를 분리합니다 [13]. API에서 가져오는 '서버 상태'는 TanStack Query를 사용해 캐싱과 동기화를 처리하고, '클라이언트 애플리케이션 상태'는 Zustand나 Jotai 등을 사용하여 관리합니다 [14, 15].
|
||||
* **Context API vs Zustand vs Redux:** Context API는 테마나 다국어처럼 드물게 변경되는 정적 상태에 적합하지만, 상태가 자주 변경되면 이를 구독하는 모든 컴포넌트의 불필요한 리렌더링을 유발합니다 [16-18]. 잦은 상태 변경에는 상태 슬라이스 단위로 구독할 수 있는 Zustand가 적합하며 [18], 복잡한 파생 상태를 관리해야 하거나 규모가 매우 큰 팀(10명 이상)의 경우 구조적 일관성을 강제하는 Redux(RTK) 도입이 필수적입니다 [19-21].
|
||||
|
||||
**3. 성능 및 빌드 최적화 (Performance & Build Optimization)**
|
||||
* **번들 크기 축소 및 지연 로딩:** 초기 로딩 성능 최적화를 위해 Vite의 `manualChunks`를 활용하여 React 코어 로직과 서드파티 벤더 라이브러리를 별도의 파일로 분리해 브라우저 캐싱 효율을 높입니다 [22-24]. 또한 `React.lazy()`와 `<Suspense>`를 활용해 라우트나 무거운 UI 위젯 수준에서 코드 스플리팅(Code Splitting)을 적용합니다 [24-26].
|
||||
* **렌더링 성능 및 React Compiler:** 불필요한 렌더링을 막기 위해 `React.memo`, `useMemo`, `useCallback`을 활용하되 프로파일링(측정)을 동반하여 남용을 피해야 합니다 [27-29]. React Compiler를 도입하면 빌드 타임에 코드 최적화 및 렌더링 결과의 메모이제이션이 자동으로 적용되어 개발자가 수동 최적화 코드에 쏟는 수고를 덜고 깔끔한 코드를 유지할 수 있습니다 [22, 30-33].
|
||||
|
||||
**4. 클린 코드 원칙 및 명명 규칙 (Clean Code & Naming Conventions)**
|
||||
* **소프트웨어 공학 원칙 적용:** React 개발에 SOLID 원칙을 적용하여 응집도를 높여야 합니다. 특히 단일 책임 원칙(SRP)을 통해 너무 많은 역할을 하는 거대한 컴포넌트를 분리해야 합니다 [34, 35]. 더불어 코드 중복을 피하는 DRY, 과도한 추상화를 경계하는 KISS, 불필요한 기능을 미리 구현하지 않는 YAGNI 원칙을 통해 유지보수성을 극대화합니다 [36-40].
|
||||
* **일관된 명명 규칙:** 운영체제 간(Windows, macOS, Linux) 대소문자 구분 방식 차이로 인한 빌드 충돌을 막기 위해 파일명과 폴더명은 `kebab-case`를 사용합니다 [41-43]. 반면 React 컴포넌트 이름은 `PascalCase`를 적용하고, 변수, 함수, Custom Hook에는 `camelCase`를 적용합니다 [43-46].
|
||||
|
||||
**5. 안정성 보장 및 로깅 디버깅 체계 (Resilience & Debugging)**
|
||||
* **오류 격리:** React Error Boundary 컴포넌트를 전략적으로 배치하여 서드파티 위젯이나 불안정한 UI 섹션에서 발생하는 런타임 에러가 전체 앱을 중단(백화현상)시키는 것을 차단합니다 [47-51].
|
||||
* **메모리 누수(Memory Leaks) 해결:** 애플리케이션의 성능 저하를 방지하기 위해 Chrome DevTools의 Memory 패널(Heap Snapshots, Allocation Timelines)을 사용하여 DOM 트리에서 분리된(detached) 노드나 클로저로 인해 비정상적으로 유지되는 JavaScript 참조를 식별하고 정리해야 합니다 [52-58].
|
||||
* **클라우드 로깅:** 프로덕션 환경에서는 Sentry, LogRocket, Datadog 같은 관측성 도구를 활용하여, 에러의 그룹화 식별과 세션 리플레이(Session Replay) 기능을 통해 문제의 맥락을 추적합니다 [59, 60].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** `[[Feature-Sliced Design]]`, `[[상태 관리 아키텍처(State Management Architecture)]]`, `[[코드 스플리팅 및 성능 최적화(Code Splitting & Performance Optimization)]]`, `[[클린 코드 및 SOLID 원칙(Clean Code & SOLID Principles)]]`, `[[React Error Boundaries]]`
|
||||
- **Projects/Contexts:** `[[프론트엔드 관측성(Frontend Observability) 및 로깅 시스템]]`, `[[Vite 빌드 번들 최적화]]`, `[[Git Branching Strategy 및 협업 워크플로우]]`
|
||||
- **Contradictions/Notes:**
|
||||
- 기능 분할 설계(Feature-Sliced Design)는 장기적인 구조 확장성에는 뛰어나지만, 프로젝트의 규모가 작거나 단순할 때는 오버헤드가 크고 러닝 커브가 가파르다는 한계가 존재합니다 [5, 61, 62].
|
||||
- React Compiler는 개발자에게 렌더링 최적화를 자동화하여 편리함을 제공하지만, 일부 타사 라이브러리가 렌더링마다 불안정한 참조를 반환하는 경우 최적화 사슬이 끊어질 수 있으며 내부 메커니즘을 파악하기 힘든 '블랙박스' 역할을 해 성능 디버깅을 어렵게 만들 수 있습니다 [63-65].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: SYS-SCALE-AI-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, infrastructure, scalability, distributed-systems, load-balancing, microservices, mlops]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Scalability in AI Systems (AI 시스템의 확장성)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "폭증하는 트래픽과 데이터 앞에 시스템이 무너지지 않도록, 선형적 확장(Scaling)이 가능한 모듈형 아키텍처를 구축하고 병목을 선제적으로 해체하라" — 사용자 수나 데이터 규모가 커져도 성능 저하 없이 자원을 추가하여 대응할 수 있는 AI 인프라의 능력.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Horizontal Elasticity and Resource Decoupling" — 서버 한 대의 성능을 높이는 대신(Vertical), 여러 대의 저렴한 서버를 병렬로 연결하고(Horizontal), 연산(GPU)과 저장(DB)을 분리하여 부하에 따라 유연하게 늘리고 줄이는 패턴.
|
||||
- **핵심 확장 전략:**
|
||||
- **Load Balancing:** 트래픽을 여러 추론 서버로 균등하게 분산.
|
||||
- **Model Parallelism:** 거대 모델을 여러 GPU에 나누어 적재.
|
||||
- **Asynchronous Processing:** 무거운 작업은 큐(Queue)를 통해 비동기로 처리.
|
||||
- **Microservices:** 기능을 쪼개어 독립적으로 확장 가능하게 설계.
|
||||
- **의의:** 실험실 수준의 AI 모델이 수억 명이 사용하는 대규모 상용 서비스(예: ChatGPT)로 거듭나기 위한 필수적인 공학적 토대.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 무조건 자원을 많이 투입하는 것이 답이라던 시대를 지나, 이제는 서버리스(Serverless) 추론이나 지능형 자동 확장(Auto-scaling)을 통해 비용 효율과 확장성을 동시에 잡는 '그린 AI' 인프라가 주목받고 있음.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 동시 접속자 수 증가에 대비하여, 도커(Docker)와 쿠버네티스(Kubernetes) 기반의 컨테이너 환경에서 유연하게 확장 가능한 마이크로서비스 구조를 기본 채택함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[System-Design-for-AI-Scale]], [[High-Availability-Systems]], [[Parallel-Computing-in-AI]], [[Cloud-Computing-Foundations]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Scalability-in-AI-Systems.md]]
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: AI-LLM-SCALE-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, llm, scaling-laws, chinchilla, compute-optimal, deep-learning, efficiency]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Scaling Laws for LLMs (LLM을 위한 스케일링 법칙)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "지능의 성장은 무작위가 아니라 파라미터, 데이터, 연산량이라는 세 축의 '멱법칙(Power Law)'을 따르며, 최적의 배합을 찾는 자가 최소한의 비용으로 최강의 지능을 얻는다" — 거대 언어 모델의 성능이 자원 투입량에 따라 예측 가능한 방식으로 향상된다는 통계적 법칙.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Power-law Performance Scaling and Resource Balancing" — 모델 크기($N$), 데이터 크기($D$), 연산량($C$) 중 어느 하나만 극단적으로 키우는 것보다, 세 요소를 조화롭게 확장할 때 손실(Loss)이 가장 효율적으로 감소한다는 패턴.
|
||||
- **주요 법칙 및 연구:**
|
||||
- **OpenAI Scaling Law (2020):** 모델 크기를 키우는 것이 데이터 양을 늘리는 것보다 성능 향상에 더 유리하다고 주장.
|
||||
- **Chinchilla Scaling Law (DeepMind, 2022):** 기존 모델들이 파라미터 수에 비해 데이터가 부족했음을 지적. 모델 크기와 데이터 양을 1:1 비율로 늘려야 '연산 최적(Compute Optimal)'임을 입증.
|
||||
- **의의:** 수천억 원이 드는 거대 모델 학습 전에, 작은 실험만으로 최종 모델의 성능을 정밀하게 예측하여 막대한 자원 낭비를 방지하게 함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** "모델이 클수록 무조건 좋다"는 초기 믿음을 깨고, 이제는 작은 모델에 엄청난 양의 양질 데이터를 학습시켜 큰 모델을 압도하는 '작고 강한 지능' 전략(예: Llama 시리즈)이 주류가 됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 자체 에이전트 모델 미세 조정 시, 최신 스케일링 법칙을 적용하여 보유한 연산 자원 대비 가장 효율적인 모델 크기와 데이터셋 규모를 산정함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[LLM-Training-Foundations]], [[High-Performance-Computing-HPC]], [[Data-Centric-AI]], [[Optimization-in-AI]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Scaling-Laws-for-LLMs.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: DL-SCHED-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, deep-learning, optimization, scheduler, learning-rate, hyperparameter-tuning, training-efficiency]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Scheduler Design in ML (ML에서의 스케줄러 설계)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "학습 초기에는 대담한 탐색(High LR)을 장려하고, 종단에는 정밀한 수렴(Low LR)을 유도하여 모델의 잠재력을 마지막 한 방울까지 쥐어짜라" — 학습 과정 중에 학습률(Learning Rate)이나 자원 배분을 동적으로 변경하여 학습의 안정성과 최종 성능을 최적화하는 전략적 설계.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Decaying Learning Rate and Convergence Optimization" — 학습이 진행됨에 따라 오차가 줄어드는 속도를 감시하고, 사전에 정의된 정책(Schedule)에 따라 학습률을 점진적으로 낮춤으로써 지역 최적해(Local Minima)를 탈출하거나 전역 최적해에 부드럽게 안착시키는 패턴.
|
||||
- **주요 스케줄러 기법:**
|
||||
- **Step Decay:** 정해진 에포크(Epoch)마다 학습률을 일정 비율로 축소.
|
||||
- **Cosine Annealing:** 코사인 함수 곡선을 따라 학습률을 부드럽게 낮춤. 최근 가장 널리 쓰임.
|
||||
- **ReduceLROnPlateau:** 성능 향상이 멈췄을 때만 지능적으로 학습률 인하.
|
||||
- **Warm-up:** 초기 불안정성을 막기 위해 아주 작은 학습률에서 시작해 점차 높이는 과정.
|
||||
- **의의:** 고정된 학습률(Fixed LR)을 쓸 때보다 훨씬 빠르게 수렴하며, 모델이 가질 수 있는 최상의 정확도에 도달하게 하는 결정적 '디테일'의 영역.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단순히 학습률을 낮추기만 하는 것이 정답이라던 과거와 달리, 이제는 학습률을 다시 높였다가 낮추는 'Cyclical Learning Rates' 방식이 안장점(Saddle Point) 탈출에 더 효과적임이 밝혀져 적극 도입되고 있음.
|
||||
- **정책 변화:** Antigravity 프로젝트는 대규모 모델 미세 조정 시, 학습 초기 발산을 방지하기 위한 Linear Warm-up과 최종 수렴 극대화를 위한 Cosine Decay 스케줄러를 표준 조합으로 사용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Optimization-Algorithms]], [[Adam-Optimizer-Foundations]], [[Hyperparameter-Tuning-Best-Practices]], [[Deep-Learning-Foundations]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Scheduler-Design-in-ML.md]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: SYS-NOSQL-SCHEMA-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [database, nosql, schema-design, mongodb, cassandra, dynamodb, denormalization, scalability]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Schema Design for NoSQL (NoSQL 스키마 설계)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터의 관계(Relationship)를 위해 속도를 희생하지 말고, 사용자의 읽기 패턴(Access Pattern)에 맞춰 데이터를 미리 조립하고 중복시켜 검색 성능을 극대화하라" — 유연한 데이터 구조를 가진 NoSQL 데이터베이스에서 높은 확장성과 빠른 응답 속도를 달성하기 위한 쿼리 중심적 설계 전략.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Denormalization and Query-first Modeling" — 여러 테이블을 조인(Join)하는 비용을 피하기 위해 연관된 데이터를 하나의 문서(Document)에 담거나 의도적으로 데이터를 중복 저장하며, 데이터 저장 방식이 아닌 '어떻게 조회할 것인가'를 기준으로 스키마를 짜는 패턴.
|
||||
- **핵심 설계 원칙:**
|
||||
- **Denormalization:** 조인 대신 데이터를 포함(Embedding)시켜 단일 읽기로 해결.
|
||||
- **Partition Key Design:** 데이터를 여러 서버에 균등하게 분산시키기 위한 키 선정.
|
||||
- **CAP Theorem 이해:** 일관성(Consistency)과 가용성(Availability) 중 서비스 성격에 맞는 트레이드오프 선택.
|
||||
- **의의:** 고정된 스키마의 제약에서 벗어나 초당 수만 건의 요청을 처리해야 하는 대규모 웹 서비스와 비정형 데이터 처리에 최적화된 유연성을 제공함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** NoSQL은 "스키마가 없다(Schema-less)"는 말에 현혹되어 설계를 무시하던 초기 단계를 지나, 이제는 정교한 '애플리케이션 수준의 스키마 관리'가 데이터 일관성 유지의 핵심임을 인지하고 설계의 중요성이 재조명됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 대규모 비정형 로그 및 지식 그래프 메타데이터 저장 시, 읽기 성능 최적화를 위해 문서 지향(Document-oriented) NoSQL 설계 원칙을 적용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Relational-Databases]], [[System-Design-for-AI-Scale]], [[Sharding-and-Partitioning]], [[High-Availability-Systems]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Schema-Design-for-NoSQL.md]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: DEV-SCI-COMP-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [python, scientific-computing, numpy, scipy, matplotlib, vectorization, mathematics]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Scientific Computing with Python (파이썬을 활용한 과학 연산)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "수학의 추상적인 언어를 고성능 벡터 연산(Vectorization)으로 치환하고, 거대한 라이브러리 생태계를 활용해 데이터 속의 물리적 법칙과 통계적 진실을 탐사하라" — 고성능 수치 연산과 데이터 분석, 시각화를 위해 파이썬 생태계가 제공하는 과학적 도구들과 방법론의 총합.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Vectorized Computing and High-level Abstraction" — 반복문(Loop)을 사용하는 대신 행렬 단위의 일괄 연산을 수행하여 하드웨어 가속을 극대화하고, 복잡한 선형 대수나 미적분 문제를 표준화된 함수 호출로 해결하는 패턴.
|
||||
- **핵심 라이브러리 트리오:**
|
||||
- **NumPy:** 다차원 배열 연산의 근간. 모든 AI 데이터 처리의 시작점.
|
||||
- **SciPy:** 최적화, 통계, 신호 처리 등 고급 수학 연산 기능 제공.
|
||||
- **Matplotlib:** 연산 결과를 시각화하여 데이터의 패턴을 직관적으로 해석.
|
||||
- **의의:** 전문 수학자나 물리학자의 도구였던 과학 연산을 일반 개발자도 손쉽게 다룰 수 있게 함으로써, AI 연구의 장벽을 낮추고 실무 적용 속도를 비약적으로 높임.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 파이썬은 연산 속도가 느리다는 편견을 넘파이 내부의 C/C++ 최적화와 JAX/Numba 같은 실시간 컴파일 기술을 통해 정면으로 돌파하며, 이제는 슈퍼컴퓨팅 분야에서도 파이썬 기반 과학 연산이 주류가 됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 지식 그래프 밀도 분석 및 시뮬레이션 연산 시, 유지보수성과 라이브러리 지원이 풍부한 파이썬 과학 연산 스택을 표준으로 사용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Python-for-Data-Science]], [[Algorithm-Complexity-Analysis]], [[Deep-Learning-Foundations]], [[Signal-Processing-Foundations]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Scientific-Computing-with-Python.md]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: MKT-SEO-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [marketing, seo, search-engine, search-engine-optimization, content-strategy, website-ranking]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Search Engine Optimization (SEO, 검색 엔진 최적화)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "검색 엔진의 알고리즘을 지식의 지도로 삼아, 사용자가 원하는 가치를 가장 선명하고 신뢰성 있는 구조로 설계하여 '발견될 기회'를 극대화하라" — 웹사이트가 검색 결과 상단에 노출되도록 콘텐츠와 기술적 구조를 최적화하는 전략적 방법론.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Intent Alignment and Structural Trust" — 사용자의 검색 의도에 부합하는 키워드를 발굴하고, 검색 엔진 로봇이 이해하기 쉬운 시맨틱 마크업(Semantic HTML)과 빠른 로딩 속도, 신뢰할 수 있는 백링크를 구축하여 권위도(Authority)를 높이는 패턴.
|
||||
- **핵심 3대 기조:**
|
||||
- **On-Page SEO:** 제목 태그, 메타 설명, 콘텐츠 품질, 내부 링크 최적화.
|
||||
- **Technical SEO:** 사이트 속도, 모바일 친화성, XML 사이트맵, 스키마 마크업.
|
||||
- **Off-Page SEO:** 외부 사이트로부터의 양질의 백링크 확보 및 브랜드 언급.
|
||||
- **의의:** 광고비 지출 없이도 지속적인 트래픽을 유입시키는 가장 강력한 마케팅 자산이며, 정보가 넘쳐나는 시대에 '선택받는 정보'가 되기 위한 필수 요건.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 키워드를 무작위로 반복 삽입하던 '키워드 스터핑' 방식에서 벗어나, 이제는 구글의 E-E-A-T(경험, 전문성, 권위성, 신뢰성) 원칙에 따른 '진짜 가치 있는 콘텐츠'와 '사용자 경험(UX)'이 SEO의 절대적 기준이 됨.
|
||||
- **정책 변화:** Antigravity 프로젝트의 모든 공개 지식 문서는 검색 엔진이 그 가치를 즉각 파악할 수 있도록 표준화된 메타데이터 구조와 시맨틱 HTML 가이드라인을 준수하여 작성됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Ranking-Algorithms]], [[Modern-Website-Architecture]], [[Content-Strategy-Foundations]], [[Search-Engine-Fundamentals]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Search-Engine-Optimization.md]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: SEC-SMPC-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, security, privacy, smpc, secure-multi-party-computation, cryptography, data-privacy]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Secure Multi-party Computation (SMPC, 안전 다자간 연산)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "개별 데이터를 비공개로 유지하면서도 결합된 결과의 진실만을 추출하여, 신뢰 없는 참여자들 사이에서 '완벽하게 안전한 협력'을 구현하라" — 데이터를 암호학적 파편(Shares)으로 쪼개어 여러 참여자에게 분산시키고, 누구도 원본을 복원할 수 없는 상태에서 공동 연산을 수행하는 기술.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Secret Sharing and Distributed Logic" — 원본 데이터를 무작위 값들의 합으로 나누어 분산 저장하고, 각 참여자가 자신의 파편만으로 연산을 수행한 뒤 결과값의 파편만을 합쳐서 최종 정답을 도출하는 패턴.
|
||||
- **핵심 메커니즘:**
|
||||
- **Secret Sharing:** 데이터를 여러 개로 쪼개어 일부만으로는 정보를 알 수 없게 함.
|
||||
- **Garbled Circuits:** 연산 논리 자체를 암호화하여 처리.
|
||||
- **Oblivious Transfer:** 수신자가 무엇을 받았는지 송신자가 알 수 없게 데이터를 전송.
|
||||
- **의의:** 기업 간의 민감 데이터 공유 없이도 공동 시장 분석이나 의료 연구를 수행할 수 있게 하며, 데이터의 가치만 흐르고 정보는 가두는 '신뢰의 프로토콜'을 형성함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 연산 및 통신 비용이 너무 커서 이론적 유희에 불과하다는 비판을 받아왔으나, 최근에는 암호학적 최적화와 하드웨어 가속을 통해 수천만 건의 데이터를 실시간으로 처리할 수 있는 상용 수준의 프레임워크들이 등장함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트 네트워크 간의 지식 전이 학습 시, 개별 사용자의 로컬 데이터를 절대 노출하지 않기 위해 SMPC 기반의 안전한 가중치 취합 방식을 기술적 로드맵에 포함함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Privacy-Preserving-AI]], [[Federated-Learning-Foundations]], [[Personal-Information-Security]], [[Trustworthy-AI]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Secure-Multi-party-Computation.md]]
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: SEC-BEST-PRAC-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [security, infrastructure, best-practices, encryption, authentication, authorization, cyber-security]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Security Best Practices (보안 모범 사례)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "보안은 단일 장벽이 아니라 겹겹이 쌓인 '방어의 층(Layers)'이며, 가장 약한 고리가 전체의 안전을 결정함을 잊지 마라" — 정보 자산의 기밀성, 무결성, 가용성을 유지하기 위해 업계에서 검증된 기술적, 관리적 보안 지침들의 집합.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Defense in Depth and Least Privilege" — 외부의 침입 시도를 다중의 인증/인가 장치로 막고, 내부 사용자에게는 업무에 필요한 최소한의 권한만 부여하며, 모든 활동을 기록(Logging)하여 사후 추적이 가능하게 만드는 패턴.
|
||||
- **5대 실전 수칙:**
|
||||
- **Encryption:** 저장된 데이터(At-rest)와 전송 중인 데이터(In-transit)의 상시 암호화.
|
||||
- **Authentication & MFA:** 강력한 비밀번호 정책과 다요소 인증 필수화.
|
||||
- **Dependency Management:** 사용하는 오픈소스 라이브러리의 보안 취약점 상시 모니터링 및 업데이트.
|
||||
- **Network Security:** 불필요한 포트 폐쇄, 방화벽 및 VPN 활용.
|
||||
- **Security by Design:** 기획 단계부터 보안 요소를 고려하여 아키텍처 설계.
|
||||
- **의의:** 서비스의 신뢰성을 담보하고 법적 규제(GDPR, ISMS 등)를 준수하며, 예상치 못한 해킹이나 데이터 유출 사고로부터 비즈니스의 영속성을 보호함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 한 번의 인증으로 모든 곳을 통과하는 방식에서, 이제는 아무도 믿지 않고 매 단계마다 검증하는 '제로 트러스트(Zero Trust)' 모델이 현대 기업 보안의 글로벌 표준으로 자리 잡음.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 내부 API 통신에 상호 TLS(mTLS)를 적용하고, 에이전트의 작업 권한을 세분화하여 관리하는 보안 최우선 거버넌스를 실행함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Personal-Information-Security]], [[Privacy-Preserving-AI]], [[Trustworthy-AI]], [[Cloud-Computing-Foundations]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Security-Best-Practices.md]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: DL-SELF-ATT-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, deep-learning, transformer, self-attention, attention-mechanism, nlp, neural-networks]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Self-Attention Mechanisms (셀프 어텐션 메커니즘)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터 내의 모든 요소가 서로의 맥락을 병렬로 탐색하게 하고, 현재의 의미를 완성하는 데 가장 기여도가 높은 '상대'에게 지능의 초점을 집중시켜라" — 입력 시퀀스의 각 요소가 전체 시퀀스의 다른 모든 요소와 상호작용하며 자신의 의미를 업데이트하는 트랜스포머 아키텍처의 핵심 메커니즘.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Dynamic Contextual Weighing and Parallel Interaction" — 각 단어를 질문(Query), 대상(Key), 정보(Value) 벡터로 투영하고, 질문과 대상 사이의 유사도(Dot-product)를 점수화하여 필요한 정보를 가중 평균하여 가져오는 패턴.
|
||||
- **핵심 수식 개념:**
|
||||
- **Attention(Q, K, V) = softmax(QK^T / sqrt(d_k))V**
|
||||
- **Scaled Dot-product:** 기울기 폭주를 막기 위해 차원 수의 제곱근으로 나누어줌.
|
||||
- **Multi-head Attention:** 여러 개의 어텐션을 병렬로 돌려 다양한 시각(문법적, 의미적 등)에서 맥락 파악.
|
||||
- **의의:** RNN과 달리 시퀀스를 순차적으로 처리할 필요가 없어 병렬 연산이 가능하며, 거리가 먼 단어들 사이의 관계(Long-range dependency)도 한 번에 파악할 수 있는 지능의 혁신을 이룸.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 데이터가 길어질수록 연산량이 제곱($O(n^2)$)으로 늘어난다는 치명적 한계를 극복하기 위해, 최근에는 Flash Attention이나 Sparse Attention 등 연산 효율을 극대화한 다양한 변형 기술들이 도입되고 있음.
|
||||
- **정책 변화:** Antigravity 프로젝트는 대규모 지식 관계망 구축 시, 문서 간의 의미적 거리를 산출하기 위해 내부적으로 멀티 헤드 셀프 어텐션 기반의 임베딩 분석 엔진을 활용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Natural-Language-Processing-NLP]], [[Deep-Learning-Foundations]], [[Scalability-in-AI-Systems]], [[Modern-Website-Architecture]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Self-Attention-Mechanisms.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: ROBOT-AUTO-DRIVE-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, autonomous-driving, robotics, computer-vision, sensor-fusion, slam, path-planning]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Self-Driving Car Foundations (자율주행 자동차 기초)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "감각의 통합(Sensor Fusion)을 통해 세계를 재구성하고, 예측과 계획의 루프를 초단위로 회전시켜 물리적 공간에서의 '안전한 자율성'을 성취하라" — 인공지능, 센서 기술, 제어 공학을 결합하여 인간의 개입 없이 스스로 목적지까지 주행하는 차량 시스템의 핵심 원리.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Perceive-Predict-Plan-Act and Safety-critical Redundancy" — 주변 환경을 3D로 인지하고, 보행자와 차량의 의도를 예측하며, 충돌 없는 최적 경로를 실시간으로 생성하여 물리적 구동계로 전달하는 계층적 제어 패턴.
|
||||
- **핵심 기술 스택:**
|
||||
- **Perception:** 객체 탐지(Object Detection), 차선 인식, 신호등 감지.
|
||||
- **Sensor Fusion:** 카메라(시각), 라이다(정밀 거리), 레이더(속도) 데이터의 결합.
|
||||
- **Localization:** HD 지도를 기반으로 센서 데이터를 매칭하여 수 cm 단위의 위치 파악.
|
||||
- **Planning & Control:** 동적 장애물을 회피하는 경로 생성 및 가속/제동/조향 제어.
|
||||
- **의의:** 사고 감소, 교통 효율 증대, 이동의 자유 확대 등 사회적 가치를 창출하는 AI 기술의 정점이자 종합 전시장.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 모든 상황을 규칙으로 코딩하던 '모듈형 방식'에서 벗어나, 이제는 인지부터 제어까지 신경망 하나로 처리하는 '엔드 투 엔드(End-to-End) 학습'과 대규모 가상 시뮬레이션 환경에서의 강화학습이 주류 기술로 부상함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 자율주행의 핵심인 '예측과 계획' 알고리즘 지식을 바탕으로, 에이전트의 작업 스케줄링 및 리소스 배분 전략을 고도화함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Robotics-Foundations]], [[Computer-Vision-Fundamentals]], [[Point-Cloud-Processing]], [[Reinforcement-Learning]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Self-Driving-Car-Foundations.md]]
|
||||
Reference in New Issue
Block a user