refactor(topics): 멀티 에이전트용 지식 재편 — _Common(공통 기본기) + Domain_* 구조
에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게 [공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류. 문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인). - Topic_Programming → Domain_Programming (내부 구조 보존) - Topic_Graphic → Domain_Design - Topic_Business → Domain_Product - Topic_General → Domain_General - _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning), Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing) - 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서) - 빈 폴더 정리 (memory/procedures) - 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,170 @@
|
||||
---
|
||||
id: wiki-2026-0508-ai-sampling-strategies
|
||||
title: AI Sampling Strategies
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [LLM Sampling, Decoding Strategies]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [llm, sampling, decoding, inference]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: vllm/transformers
|
||||
---
|
||||
|
||||
# AI Sampling Strategies
|
||||
|
||||
## 매 한 줄
|
||||
> **"매 logits → token 의 conversion 의 art — 매 quality vs diversity trade-off."** 매 greedy 의 deterministic — 매 temperature/top-k/top-p 의 stochastic — 매 2026 에 min-p, mirostat, speculative decoding 의 mainstream.
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 deterministic
|
||||
- **Greedy**: argmax token. 매 repetitive 의 risk.
|
||||
- **Beam search**: 매 top-B sequences 의 maintain. 매 translation 의 useful, 매 open-ended 의 bland.
|
||||
|
||||
### 매 stochastic
|
||||
- **Temperature**: logits / T. T<1 sharpen, T>1 flatten.
|
||||
- **Top-k**: 매 top-k tokens 의 sample.
|
||||
- **Top-p (nucleus)**: 매 cumulative prob ≥ p 의 smallest set.
|
||||
- **Min-p**: 매 P(top) * min_p 의 threshold — 매 top-p 의 better.
|
||||
- **Typical-p**: 매 entropy-based — 매 typical tokens.
|
||||
- **Mirostat**: 매 perplexity targeting feedback control.
|
||||
|
||||
### 매 응용
|
||||
1. Creative writing — 매 high temp + top-p.
|
||||
2. Code generation — 매 low temp + greedy fallback.
|
||||
3. Reasoning — 매 self-consistency (sample N, majority vote).
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### Temperature + top-p
|
||||
```python
|
||||
import torch
|
||||
import torch.nn.functional as F
|
||||
|
||||
def sample(logits, temperature=0.7, top_p=0.9):
|
||||
logits = logits / temperature
|
||||
probs = F.softmax(logits, dim=-1)
|
||||
sorted_probs, sorted_idx = probs.sort(descending=True)
|
||||
cumsum = sorted_probs.cumsum(-1)
|
||||
mask = cumsum - sorted_probs > top_p
|
||||
sorted_probs[mask] = 0
|
||||
sorted_probs /= sorted_probs.sum()
|
||||
pick = torch.multinomial(sorted_probs, 1)
|
||||
return sorted_idx.gather(-1, pick)
|
||||
```
|
||||
|
||||
### Min-p
|
||||
```python
|
||||
def min_p_sample(logits, min_p=0.05, temperature=1.0):
|
||||
logits = logits / temperature
|
||||
probs = F.softmax(logits, dim=-1)
|
||||
threshold = probs.max(-1, keepdim=True).values * min_p
|
||||
probs = torch.where(probs >= threshold, probs, torch.zeros_like(probs))
|
||||
probs /= probs.sum(-1, keepdim=True)
|
||||
return torch.multinomial(probs, 1)
|
||||
```
|
||||
|
||||
### Self-consistency (CoT majority vote)
|
||||
```python
|
||||
def self_consistency(prompt, llm, n=20):
|
||||
answers = []
|
||||
for _ in range(n):
|
||||
cot = llm.generate(prompt, temperature=0.7)
|
||||
answers.append(extract_final_answer(cot))
|
||||
from collections import Counter
|
||||
return Counter(answers).most_common(1)[0][0]
|
||||
```
|
||||
|
||||
### Speculative decoding
|
||||
```python
|
||||
def speculative(target, draft, prompt, k=4):
|
||||
# Draft k tokens cheaply, target verifies in parallel
|
||||
ctx = prompt
|
||||
while not done(ctx):
|
||||
draft_tokens, draft_probs = draft.generate(ctx, k)
|
||||
target_probs = target.score(ctx, draft_tokens)
|
||||
accepted = []
|
||||
for i, (dp, tp) in enumerate(zip(draft_probs, target_probs)):
|
||||
r = torch.rand(1)
|
||||
if r < min(1, tp / dp):
|
||||
accepted.append(draft_tokens[i])
|
||||
else:
|
||||
# Reject, sample from (target - draft)+ then break
|
||||
resample = sample_diff(target_probs[i], draft_probs[i])
|
||||
accepted.append(resample)
|
||||
break
|
||||
else:
|
||||
accepted.append(target.sample(ctx + accepted))
|
||||
ctx += accepted
|
||||
return ctx
|
||||
```
|
||||
|
||||
### Mirostat (perplexity control)
|
||||
```python
|
||||
def mirostat(logits, mu, tau=5.0, eta=0.1):
|
||||
# Adaptively adjusts top-k to target surprise tau
|
||||
sorted_probs, idx = F.softmax(logits, -1).sort(descending=True)
|
||||
s = -torch.log(sorted_probs)
|
||||
k = (s < mu).sum().item()
|
||||
k = max(k, 1)
|
||||
pick = torch.multinomial(sorted_probs[:k] / sorted_probs[:k].sum(), 1)
|
||||
surprise = -torch.log(sorted_probs[pick])
|
||||
mu = mu - eta * (surprise - tau)
|
||||
return idx[pick], mu
|
||||
```
|
||||
|
||||
### Repetition penalty
|
||||
```python
|
||||
def apply_repetition_penalty(logits, generated_ids, penalty=1.1):
|
||||
for tok in set(generated_ids):
|
||||
if logits[tok] < 0:
|
||||
logits[tok] *= penalty
|
||||
else:
|
||||
logits[tok] /= penalty
|
||||
return logits
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Sampler |
|
||||
|---|---|
|
||||
| Code, math, structured | T=0 greedy or T=0.2 |
|
||||
| Chat / general | T=0.7, top-p=0.9 or min-p=0.05 |
|
||||
| Creative / fiction | T=1.0+, min-p=0.02 |
|
||||
| Reasoning ensemble | T=0.7, n=20, majority vote |
|
||||
| Translation | Beam search (B=4-8) |
|
||||
| Latency-critical | Speculative decoding (target + small draft) |
|
||||
|
||||
**기본값**: 매 T=0.7 + min-p=0.05.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Decoding]]
|
||||
- 응용: [[Self-Consistency]]
|
||||
- Adjacent: [[LLM_Optimization_and_Deployment_Strategies|vLLM]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 inference pipeline 의 every call — 매 task 의 sampler 의 match.
|
||||
**언제 X**: 매 logprob analysis (no sampling needed).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **High temp + greedy fallback**: 매 inconsistent — 매 single sampler.
|
||||
- **Top-k=1 with high temp**: 매 contradictory.
|
||||
- **No repetition penalty on long outputs**: 매 loops.
|
||||
- **Speculative without acceptance check**: 매 distribution shift.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Holtzman et al. nucleus sampling 2020, Leviathan et al. speculative 2023, min-p paper 2024).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — sampler taxonomy + working code |
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: wiki-2026-0508-ai-추론-및-맥락-인식-아키텍처
|
||||
title: AI 추론 및 맥락 인식 아키텍처
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: wiki-2026-0508-ai-reasoning-context-aware-architecture
|
||||
duplicate_of: "[[AI Reasoning and Context-Aware Architecture]]"
|
||||
aliases: []
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, ai, reasoning, context]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# AI 추론 및 맥락 인식 아키텍처
|
||||
|
||||
> **이 문서는 [[AI Reasoning and Context-Aware Architecture]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 핵심 요약
|
||||
- 매 chain-of-thought, ReAct, scratchpad — reasoning trace 의 explicit emission.
|
||||
- 매 long-context (1M+ tokens) + RAG — context-aware grounding.
|
||||
- 매 2026 에 Claude 4.7, GPT-5 의 deliberative reasoning + tool use 의 unified architecture.
|
||||
|
||||
## 🔗 Graph
|
||||
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
@@ -0,0 +1,338 @@
|
||||
---
|
||||
id: wiki-moc-architecture
|
||||
title: Architecture
|
||||
category: 10_Wiki/Topics
|
||||
status: moc
|
||||
aliases: [architecture]
|
||||
tags: [moc, index]
|
||||
last_reinforced: 2026-05-20
|
||||
---
|
||||
|
||||
# Architecture
|
||||
|
||||
> **Architecture** 카테고리 목차(MOC). `Architecture/` 의 토픽 문서 316개. 자동 생성 인덱스 — redirect/중복 문서는 제외.
|
||||
|
||||
## 📚 토픽 (316)
|
||||
|
||||
- [[2026년_3월_연구_드롭(March_2026_Research_Drop)]]
|
||||
- [[3의 법칙 (Rule of Three)]]
|
||||
- [[A2A]]
|
||||
- [[ACID Transactions]]
|
||||
- [[Active_Record_Pattern_vs_Repository_Pattern]]
|
||||
- [[ADR_(Architecture_Decision_Records)]]
|
||||
- [[AI-Assisted Refactoring (AI 기반 리팩토링)]]
|
||||
- [[Alliance_(동맹)]]
|
||||
- [[Ambient_Declarations]]
|
||||
- [[AOP_Aspect-Oriented_Programming]]
|
||||
- [[AOT_Compilation_Ahead-of-Time]]
|
||||
- [[Apache Ignite]]
|
||||
- [[API Gateway]]
|
||||
- [[API-Contract-Definition]]
|
||||
- [[API-First_Architecture]]
|
||||
- [[API_Fundamentals]]
|
||||
- [[Append-only log]]
|
||||
- [[Architectural Violations]]
|
||||
- [[Architectural-Constraint-Enforcement]]
|
||||
- [[Architecture Description (아키텍처 명세)]]
|
||||
- [[Architecture_Diagramming_Standards]]
|
||||
- [[Architecture_Refactor]]
|
||||
- [[Arrangement-and-Composition]]
|
||||
- [[Aspect-Oriented Programming (AOP)]]
|
||||
- [[AST_Traversal]]
|
||||
- [[ATAM (Architecture Trade-offs Analysis Method)]]
|
||||
- [[Automated Refactoring Tools]]
|
||||
- [[Base_Layouts]]
|
||||
- [[Bayesian_Inference]]
|
||||
- [[Beat_Saber]]
|
||||
- [[Belief-System]]
|
||||
- [[Big-Data]]
|
||||
- [[BLoC]]
|
||||
- [[Boilerplate]]
|
||||
- [[Bottom-Up-Approach]]
|
||||
- [[Bounded_Context]]
|
||||
- [[BPM]]
|
||||
- [[Branded-Types]]
|
||||
- [[Breaking Dependencies]]
|
||||
- [[Broker Topology]]
|
||||
- [[Browser]]
|
||||
- [[C4_Modeling_Framework]]
|
||||
- [[CAD 렌더링 최적화]]
|
||||
- [[Call_Stack_Analysis]]
|
||||
- [[Characterization Tests (특성화 테스트)]]
|
||||
- [[Choreography]]
|
||||
- [[Code Refactoring]]
|
||||
- [[Combat_Timeline_Difficulty_Scaling]]
|
||||
- [[Complex Event Processing (CEP)]]
|
||||
- [[Complexity_Theory]]
|
||||
- [[Component Library Architecture]]
|
||||
- [[Component-Based Architecture (CBA)]]
|
||||
- [[Compound_Components]]
|
||||
- [[Compute_Shaders]]
|
||||
- [[Conceptual Integrity]]
|
||||
- [[Concurrent_Rendering]]
|
||||
- [[Constructor_Injection]]
|
||||
- [[Continuous_Integration_CI]]
|
||||
- [[Control-Points]]
|
||||
- [[Control_Systems_Engineering]]
|
||||
- [[Cosmos_플랫폼_(Netflix)]]
|
||||
- [[Cross-Cutting Concerns]]
|
||||
- [[Cross-Cutting_Concerns_AOP]]
|
||||
- [[CST]]
|
||||
- [[Cyclomatic Complexity]]
|
||||
- [[DeepReadonly]]
|
||||
- [[Dependencies (의존성)]]
|
||||
- [[Dependency_Analysis]]
|
||||
- [[Dependency_Inversion_Principle]]
|
||||
- [[Digital_Twin]]
|
||||
- [[Discriminated_Unions]]
|
||||
- [[Distributed Systems Fallacies]]
|
||||
- [[Distributed Tracing]]
|
||||
- [[Distributed-System-Type-Safety]]
|
||||
- [[DOM]]
|
||||
- [[DORA-Metrics]]
|
||||
- [[Downshift]]
|
||||
- [[Dynamic Systems Development Method (DSDM)]]
|
||||
- [[E-commerce_Platforms]]
|
||||
- [[Enabling Point (활성화 지점)]]
|
||||
- [[Entity_엔티티]]
|
||||
- [[EVE_온라인(EVE_Online)]]
|
||||
- [[Event Mediator]]
|
||||
- [[Event stream processing]]
|
||||
- [[Event_Storming]]
|
||||
- [[Eventual Consistency]]
|
||||
- [[Excess_Property_Checking]]
|
||||
- [[Executable_Documentation]]
|
||||
- [[Exergaming]]
|
||||
- [[Experience-Sampling-Method]]
|
||||
- [[Exploration_vs_Exploitation]]
|
||||
- [[Extract Class (클래스 추출하기)]]
|
||||
- [[Extract Method (함수 추출하기)]]
|
||||
- [[Fault-Tolerance]]
|
||||
- [[Feature-Driven_Architecture]]
|
||||
- [[Fiber_Architecture]]
|
||||
- [[Flow_State]]
|
||||
- [[Fluid_Typography]]
|
||||
- [[FOMO (Fear of Missing Out)]]
|
||||
- [[Fragment-bound]]
|
||||
- [[Fragment_Shading]]
|
||||
- [[Functional_Programming]]
|
||||
- [[G-Stack-Integration-Guide]]
|
||||
- [[Garbage_Collection]]
|
||||
- [[Gates]]
|
||||
- [[Generational_Hypothesis]]
|
||||
- [[Generics-and-Polymorphism]]
|
||||
- [[Global_Singleton]]
|
||||
- [[God-Object-Antipattern]]
|
||||
- [[Graph_Theory]]
|
||||
- [[gRPC_and_Protocol_Buffers]]
|
||||
- [[Hardware]]
|
||||
- [[Hexagonal_Architecture_Ports_and_Adapters]]
|
||||
- [[High-Cohesion-Low-Coupling]]
|
||||
- [[Hydration]]
|
||||
- [[Impedance-Matching]]
|
||||
- [[Implementation Separation]]
|
||||
- [[In-Memory Data Grid]]
|
||||
- [[Incremental-Static-Regeneration-ISR]]
|
||||
- [[Incremental_Marking]]
|
||||
- [[Indian-Innovation-Models]]
|
||||
- [[Infraspace]]
|
||||
- [[InstancedMesh]]
|
||||
- [[Integration_Architecture_Diagrams]]
|
||||
- [[Introduce Null Object (널 객체 도입하기)]]
|
||||
- [[Inversion_of_Control_IoC]]
|
||||
- [[Island Architecture]]
|
||||
- [[ISO 25010]]
|
||||
- [[Istio]]
|
||||
- [[Keeper of the Vision]]
|
||||
- [[Link Seam (링크 접점)]]
|
||||
- [[LiveOps]]
|
||||
- [[Logging_Diagnostics]]
|
||||
- [[LSTM_(Long_Short-Term_Memory)]]
|
||||
- [[Machinations]]
|
||||
- [[Macro-architecture]]
|
||||
- [[Mapper_-_ModelMapper]]
|
||||
- [[March_2026_Research_Drop]]
|
||||
- [[Mark-Sweep]]
|
||||
- [[Mediator Topology]]
|
||||
- [[Memory_Leaks]]
|
||||
- [[Mental_Models]]
|
||||
- [[Message Broker]]
|
||||
- [[Message-Queues-and-Event-Streams]]
|
||||
- [[Micro-interactions]]
|
||||
- [[Mock Objects (가짜 객체)]]
|
||||
- [[Mocking_Framework]]
|
||||
- [[Mockito]]
|
||||
- [[Modern Review Workflow]]
|
||||
- [[Modern-Website-Architecture]]
|
||||
- [[Modular-Programming]]
|
||||
- [[Modular-Weapon-Evolution-and-Skill-Trees]]
|
||||
- [[Modular_Architecture]]
|
||||
- [[Monorepo]]
|
||||
- [[Monorepo_architectures]]
|
||||
- [[Monorepo_Turborepo-Nx]]
|
||||
- [[Multi-threaded Architecture]]
|
||||
- [[MVC (Model-View-Controller)]]
|
||||
- [[ndf-parse]]
|
||||
- [[Netflix_마이크로서비스_전환]]
|
||||
- [[Network-Latency-Optimization]]
|
||||
- [[New_Architecture]]
|
||||
- [[Next-js-and-Modern-Web]]
|
||||
- [[NoSQL-Databases-in-AI]]
|
||||
- [[Nudge_Theory]]
|
||||
- [[Object Seam (객체 접점)]]
|
||||
- [[Object-Oriented-Programming]]
|
||||
- [[Old_Space]]
|
||||
- [[Orinoco]]
|
||||
- [[Over-engineering (오버엔지니어링)]]
|
||||
- [[Overdraw]]
|
||||
- [[Parallel-Computing-in-AI]]
|
||||
- [[PBR]]
|
||||
- [[Permanent_Loss]]
|
||||
- [[Pipeline-Parallelism]]
|
||||
- [[Platform-Engineering]]
|
||||
- [[Platform-Resistance]]
|
||||
- [[Pocket_Land]]
|
||||
- [[Pointer_Compression]]
|
||||
- [[Polymorphism (다형성)]]
|
||||
- [[Predictive_Refactoring]]
|
||||
- [[Preprocessing Seam (전처리 접점)]]
|
||||
- [[Preserve Whole Object (객체 통째로 넘기기)]]
|
||||
- [[Primitive Obsession (기본 타입 집착)]]
|
||||
- [[Problem Solving Skills]]
|
||||
- [[Problem_Solving]]
|
||||
- [[Procedural-Architecture-Systems]]
|
||||
- [[Program Dependence Graph]]
|
||||
- [[Progressive-Disclosure]]
|
||||
- [[Prototyping]]
|
||||
- [[Publish-Subscribe Model]]
|
||||
- [[Pull Up Method]]
|
||||
- [[Queue-Management-Systems]]
|
||||
- [[Reachability_Analysis]]
|
||||
- [[readonly]]
|
||||
- [[Real-Time Engine (RTE)]]
|
||||
- [[Real-time-Data-Streaming]]
|
||||
- [[Red-Green Refactoring]]
|
||||
- [[Render_Props]]
|
||||
- [[Replace Conditional with Polymorphism (조건식을 다형성으로 바꾸기)]]
|
||||
- [[Resource-Management]]
|
||||
- [[Risk_Management]]
|
||||
- [[Router_Implementation]]
|
||||
- [[SARA (Software Architecture Review and Assessment)]]
|
||||
- [[Scalability]]
|
||||
- [[Scratch Refactoring (스크래치 리팩토링)]]
|
||||
- [[Seam (접점)]]
|
||||
- [[Separation_of_Concerns]]
|
||||
- [[Serverless_Architecture]]
|
||||
- [[Service Mesh]]
|
||||
- [[Service-oriented-Architecture]]
|
||||
- [[Service_Layer_Pattern]]
|
||||
- [[SharedArrayBuffer_보안_이슈와_Cross-Origin_Isolation]]
|
||||
- [[Simple event processing]]
|
||||
- [[Single Responsibility Principle (SRP)]]
|
||||
- [[Single_Source_of_Truth]]
|
||||
- [[Skybound_Implementation_Report_V10_5]]
|
||||
- [[Snapshots]]
|
||||
- [[Social_Engineering]]
|
||||
- [[Software Architecture Documentation]]
|
||||
- [[Software Architecture Knowledge Management (소프트웨어 아키텍처 지식 관리)]]
|
||||
- [[Software_Architecture_Recovery]]
|
||||
- [[SOLID Principles]]
|
||||
- [[SPA_라우트_전환_성능_최적화]]
|
||||
- [[Space-Based_Architecture]]
|
||||
- [[Spring Framework]]
|
||||
- [[Sprout & Wrap Techniques (스프라우트 & 랩 기법)]]
|
||||
- [[Sprout Method (스프라우트 메서드)]]
|
||||
- [[Stat-Injection-and-Visual-Renderer-Pipeline]]
|
||||
- [[Static_and_Dynamic_Analysis]]
|
||||
- [[Stochastic-Gradient-Descent]]
|
||||
- [[Storage-Area-Networks]]
|
||||
- [[Strategic_Thinking]]
|
||||
- [[Stream-Processing-Architectures]]
|
||||
- [[Styled_Components]]
|
||||
- [[Swarm_Intelligence]]
|
||||
- [[Switch Statements (Switch 문)]]
|
||||
- [[System_Protocol_Standard]]
|
||||
- [[Systems_Thinking]]
|
||||
- [[TARA]]
|
||||
- [[Technical-Architecture]]
|
||||
- [[Technical_Debt]]
|
||||
- [[Test Automation Pyramid]]
|
||||
- [[Testability_Architecture]]
|
||||
- [[Tetris_Project_Retrospective]]
|
||||
- [[The Two Hats]]
|
||||
- [[Thought-Architecture]]
|
||||
- [[Threejs]]
|
||||
- [[Time_Slicing]]
|
||||
- [[TSL_(Three_Shader_Language)]]
|
||||
- [[Turborepo]]
|
||||
- [[Type_Alias]]
|
||||
- [[Type_Casting]]
|
||||
- [[Uber Base Web]]
|
||||
- [[Unit Tests (단위 테스트)]]
|
||||
- [[Utility Tree (유틸리티 트리)]]
|
||||
- [[V8_엔진_힙_아키텍처]]
|
||||
- [[Variational-Autoencoders-VAE]]
|
||||
- [[Vergence-Accommodation_Conflicts]]
|
||||
- [[vFunction]]
|
||||
- [[VIP]]
|
||||
- [[Vite Build Tool]]
|
||||
- [[VR_Sickness]]
|
||||
- [[Vue_Architecture]]
|
||||
- [[Web-Rendering-Strategies-CSR-vs-SSR]]
|
||||
- [[WebGL]]
|
||||
- [[WebGPU]]
|
||||
- [[Whale Hunting]]
|
||||
- [[Wrap Method (랩 메서드)]]
|
||||
- [[YAGNI (You Aren't Gonna Need It)]]
|
||||
- [[Zod]]
|
||||
- [[가상현실(VR)]]
|
||||
- [[가차(Gacha)]]
|
||||
- [[객체 지향 소프트웨어 아키텍처 설계]]
|
||||
- [[깊이_지각(Depth_perception)]]
|
||||
- [[데이터_파싱(Data_Parsing)]]
|
||||
- [[디아블로_2(Diablo_II)]]
|
||||
- [[로그_Logs]]
|
||||
- [[리텐션(Retention)]]
|
||||
- [[리팩토링 원칙]]
|
||||
- [[마이크로서비스 아키텍처의 의존성 관리]]
|
||||
- [[매몰_비용_오류_(Sunk_Cost_Fallacy)]]
|
||||
- [[배수구(Sinks)]]
|
||||
- [[버전_관리_이력_Version_Control_History]]
|
||||
- [[보이스카우트 규칙 (Boy Scout Rule)]]
|
||||
- [[복잡한 비즈니스 도메인 (금융 헬스케어 이커머스 등)]]
|
||||
- [[부분_유료화(Free-to-Play)]]
|
||||
- [[불변성(Immutability)]]
|
||||
- [[비기능 요구사항 (Non-functional Requirements)]]
|
||||
- [[사용자_제작_콘텐츠(UGC)]]
|
||||
- [[상태 머신 (State Machine) 모델링 및 Redux 액션_리듀서 설계]]
|
||||
- [[소프트웨어 아키텍처 베스트 프랙티스]]
|
||||
- [[소프트웨어 아키텍처 설계]]
|
||||
- [[스택_트레이스(Stack_trace)]]
|
||||
- [[시스템 아키텍처 시각화 (System Architecture Visualization)]]
|
||||
- [[시프트_레프트(Shift-Left)]]
|
||||
- [[실시간_엔진_(Real-Time_Engine)]]
|
||||
- [[아키텍처 패턴 지식]]
|
||||
- [[안구_운동_기능(Oculomotor_functions)]]
|
||||
- [[약한_타입_검사(Weak_Type_Detection)]]
|
||||
- [[어포던스(Affordances)]]
|
||||
- [[엔터프라이즈 애플리케이션 및 점진적 리팩토링]]
|
||||
- [[외부_라이브러리_API_설계]]
|
||||
- [[웹 애플리케이션의 3계층 구조]]
|
||||
- [[의사결정_매트릭스(Decision_Matrix)]]
|
||||
- [[의존성 규칙 (Dependency Rule)]]
|
||||
- [[이동_속도(Movement_Speed)]]
|
||||
- [[이커머스의 실시간 재고 관리]]
|
||||
- [[타입_가드_(Type_Predicates)]]
|
||||
- [[타입_단언(Type_Assertions)]]
|
||||
- [[탭과_싱크(Taps_and_Sinks)]]
|
||||
- [[텔레메트리_(Telemetry)]]
|
||||
- [[폭주-조절_갈등_(Vergence-Accommodation_Conflict)]]
|
||||
- [[프로토타이핑 및 개념 증명(PoC)]]
|
||||
- [[플랫폼_컨버전스(Platform_Convergence)]]
|
||||
- [[하향식_탐색_Top-Down_Approach]]
|
||||
|
||||
## 🕓 변경 이력
|
||||
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-20 | MOC 페이지 신규 생성 (링크명 정규화) |
|
||||
+107
@@ -0,0 +1,107 @@
|
||||
---
|
||||
id: autonomous-queue-processing-engine
|
||||
title: Autonomous Queue Processing Engine
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [자율 큐 처리 엔진, 지식 수집 엔진, Knowledge Expansion Engine]
|
||||
source_trust_level: A
|
||||
confidence_score: 0.98
|
||||
created_at: 2026-05-11
|
||||
updated_at: 2026-05-11
|
||||
last_reinforced: 2026-05-11
|
||||
verification_status: applied
|
||||
applied_in:
|
||||
- path: /Volumes/Data/project/Antigravity/Datacollector_MAC/src/lib/engine.ts
|
||||
note: Producer-Consumer 기반 지식 수집 파이프라인 구현
|
||||
- path: /Volumes/Data/project/Antigravity/Datacollector_MAC/src/store/agentStore.ts
|
||||
note: Zustand Persist를 이용한 큐 및 상태 영속화
|
||||
tags: [engine, queue, automation, architecture]
|
||||
---
|
||||
|
||||
# [[Autonomous_Queue_Processing_Engine]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> 자율 엔진의 생명력은 단순히 코드가 실행되는 것이 아니라, **상태의 영속성(Persistence)**과 **비동기 파이프라인의 격리**를 통해 프로세스가 중단되어도 마지막 지점에서 즉시 재개할 수 있는 능력에서 나온다.
|
||||
|
||||
## 📖 핵심 개념 (Synthesized Content)
|
||||
|
||||
### 1. Producer-Consumer 모델
|
||||
지식 수집(Research)과 지식 확장(Ontology Expansion)을 분리합니다. 수집된 지식에서 새로운 주제(Links)를 발견하면 큐에 추가(Produce)하고, 엔진은 큐를 순차적으로 소비(Consume)합니다.
|
||||
|
||||
### 2. 상태 영속화 (State Persistence)
|
||||
메모리상의 큐는 휘발성입니다. 엔진의 상태(`queue`, `completed`, `processedCount`)는 반드시 파일 시스템이나 LocalStorage 등에 영속화되어야 하며, `running` 상태에서 비정상 종료 시 재시작할 때 `paused`로 안전하게 복구되어야 합니다.
|
||||
|
||||
### 3. 지능적 틱 조절 (Intelligent Tick Scheduling)
|
||||
하드웨어(예: M4 아키텍처)의 부하를 고려하여 작업 간 간격(Tick)을 동적으로 조절하고, 정체 감지 시 Watchdog 로직이 엔진을 다시 깨울 수 있어야 합니다.
|
||||
|
||||
## 💻 코드 패턴 (Implementation Patterns)
|
||||
|
||||
### 상태 영속화 (Zustand 예시)
|
||||
```typescript
|
||||
persist(
|
||||
(set, get) => ({
|
||||
queue: [],
|
||||
completed: [],
|
||||
// ... actions
|
||||
}),
|
||||
{
|
||||
name: 'engine-storage',
|
||||
partialize: (state) => ({
|
||||
queue: state.queue,
|
||||
completed: state.completed,
|
||||
status: state.status === 'running' ? 'paused' : state.status
|
||||
}),
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
### Dequeue 및 실행 락
|
||||
```typescript
|
||||
async function processQueue() {
|
||||
if (!isRunning || isConsumerActive || executionLock) return;
|
||||
|
||||
executionLock = true;
|
||||
isConsumerActive = true;
|
||||
|
||||
try {
|
||||
const task = queue[0];
|
||||
await executeTask(task);
|
||||
dequeue();
|
||||
} finally {
|
||||
isConsumerActive = false;
|
||||
executionLock = false;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준
|
||||
|
||||
| 항목 | 기준 |
|
||||
|---|---|
|
||||
| 작업 우선순위 | 일반적으로 Depth-First(깊이 우선)를 선호하되, 큐 삽입 시 정렬 필수 |
|
||||
| 중복 처리 | 큐 삽입 전 `completed` 리스트와 현재 `queue` 내 중복을 반드시 체크 |
|
||||
| 종료 조건 | 목표 처리량(Max Count) 또는 모든 작업 완료 시 엔진 정지 |
|
||||
|
||||
## ❌ 안티패턴
|
||||
|
||||
- **In-Memory Only Queue**: 브라우저 리프레시나 프로세스 재시작 시 모든 작업 내역을 잃게 됩니다.
|
||||
- **Concurrent Execution without Lock**: 동일한 큐 아이템에 대해 여러 Consumer가 동시에 달려들어 중복 작업을 수행하거나 상태가 꼬일 수 있습니다.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **상태:** verified
|
||||
- **출처 신뢰도:** A
|
||||
- **적용 사례:** `Datacollector_MAC`의 `KnowledgeEngine` 클래스에서 검증됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[Software_Architecture_Patterns]]
|
||||
- **Related:** [[System_Resilience_and_Fault_Tolerance]], [[Data Schema]]
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-11 | Datacollector_MAC 엔진 설계를 바탕으로 최초 생성 | CREATE | A |
|
||||
@@ -0,0 +1,147 @@
|
||||
---
|
||||
id: wiki-2026-0508-cipomdps
|
||||
title: CIPOMDPs
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [CI-POMDP, Communicative Interactive POMDP, Cooperative Inverse POMDP]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [rl, pomdp, multi-agent, alignment]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: pomdp-py/pettingzoo
|
||||
---
|
||||
|
||||
# CIPOMDPs
|
||||
|
||||
## 매 한 줄
|
||||
> **"매 Cooperative Inverse Partially Observable MDP — 매 human + agent 의 shared reward, 매 reward function 의 hidden parameter."** 매 Hadfield-Menell et al. (CIRL 2016) 의 POMDP extension — 매 assistance games, alignment formalization 의 backbone — 매 2026 에 LLM agent assistance 의 theoretical frame.
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 정의
|
||||
- **State** s ∈ S, **Actions** (a^H, a^R) for human + robot.
|
||||
- **Reward parameter** θ ∈ Θ — 매 human 의 known, robot 의 unknown.
|
||||
- **Reward** r(s, a^H, a^R; θ) — 매 shared.
|
||||
- **Observations** o^H, o^R — 매 partial.
|
||||
- **Goal**: maximize E[Σ r(s, a^H, a^R; θ)] — 매 robot 의 θ 의 inference + acting.
|
||||
|
||||
### 매 properties
|
||||
- **Active learning**: 매 robot 의 information-gathering actions.
|
||||
- **Off-switch problem**: 매 robot 의 uncertainty 의 corrigibility 의 induce.
|
||||
- **Reward hacking immunity** (in theory): 매 θ unknown → 매 proxy 의 over-optimize 의 X.
|
||||
|
||||
### 매 응용
|
||||
1. Assistance games (cleaning, cooking robot).
|
||||
2. RLHF formalization — 매 preference 의 reward 의 evidence.
|
||||
3. Multi-agent communication (CIPOMDPs with messages).
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### CIPOMDP belief update
|
||||
```python
|
||||
import numpy as np
|
||||
|
||||
def update_theta_belief(b_theta, s, a_H, theta_grid, beta=1.0):
|
||||
# Boltzmann human: P(a_H | s, theta) ∝ exp(beta * Q*(s, a_H; theta))
|
||||
likelihoods = np.array([
|
||||
np.exp(beta * Q_star(s, a_H, theta)) /
|
||||
sum(np.exp(beta * Q_star(s, a, theta)) for a in actions_H)
|
||||
for theta in theta_grid
|
||||
])
|
||||
posterior = b_theta * likelihoods
|
||||
return posterior / posterior.sum()
|
||||
```
|
||||
|
||||
### Robot policy (expected utility over θ)
|
||||
```python
|
||||
def robot_action(s, b_theta, theta_grid, gamma=0.95):
|
||||
# Pick a^R maximizing expected return under belief
|
||||
best_a, best_eu = None, -np.inf
|
||||
for a_R in actions_R:
|
||||
eu = sum(
|
||||
b * V_pi(s, a_R, theta, gamma)
|
||||
for b, theta in zip(b_theta, theta_grid)
|
||||
)
|
||||
if eu > best_eu:
|
||||
best_a, best_eu = a_R, eu
|
||||
return best_a
|
||||
```
|
||||
|
||||
### Off-switch game
|
||||
```python
|
||||
def off_switch_decision(b_theta, theta_grid, action_value, switch_off_value=0):
|
||||
# Robot defers to human if uncertain about reward
|
||||
expected_action_value = sum(
|
||||
b * action_value(theta) for b, theta in zip(b_theta, theta_grid)
|
||||
)
|
||||
# If human can correct, deferring dominates when uncertain
|
||||
if expected_action_value < switch_off_value + uncertainty_bonus(b_theta):
|
||||
return "wait_for_human"
|
||||
return "act"
|
||||
```
|
||||
|
||||
### Active query (info gain)
|
||||
```python
|
||||
def best_query(b_theta, theta_grid, candidate_queries):
|
||||
def expected_info_gain(q):
|
||||
H_prior = entropy(b_theta)
|
||||
H_post = sum(
|
||||
P_response(r, q, theta) * b *
|
||||
entropy(update_theta_belief_query(b_theta, q, r, theta_grid))
|
||||
for theta, b in zip(theta_grid, b_theta)
|
||||
for r in possible_responses
|
||||
)
|
||||
return H_prior - H_post
|
||||
return max(candidate_queries, key=expected_info_gain)
|
||||
```
|
||||
|
||||
### Boltzmann human model
|
||||
```python
|
||||
def boltzmann_human(s, theta, beta=1.0):
|
||||
qs = np.array([Q_star(s, a, theta) for a in actions_H])
|
||||
probs = np.exp(beta * qs - np.max(beta * qs))
|
||||
return probs / probs.sum()
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Small θ space | Exact belief update + value iteration |
|
||||
| Large θ | Particle filter + POMCP/POMCPOW |
|
||||
| Continuous θ | Variational + amortized inference |
|
||||
| Real human | Boltzmann + irrationality terms (myopia, bias) |
|
||||
| Communication | CIPOMDPs with message channel |
|
||||
|
||||
**기본값**: 매 particle filter belief + MCTS robot policy.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[POMDP]]
|
||||
- 응용: [[RLHF]]
|
||||
- Adjacent: [[AI Safety and Alignment]] · [[Theory of Mind]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 assistant agent design 의 theoretical justification, 매 ambiguity-handling spec.
|
||||
**언제 X**: 매 small tactical decision 의 deployment-ready code.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Maximize-best-guess θ**: 매 expected utility 의 over Θ — not max-likelihood θ.
|
||||
- **Rational human assumption**: 매 noisy/biased — 매 Boltzmann + bias models.
|
||||
- **Static θ**: 매 preferences drift — 매 non-stationary θ 의 model.
|
||||
- **Ignoring corrigibility**: 매 θ certainty 의 prematurity 의 dangerous.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Hadfield-Menell et al. NeurIPS 2016, Russell *Human Compatible* 2019).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — formal CIRL/CIPOMDP with code |
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: wiki-2026-0507-034
|
||||
title: CI CD 파이프라인 및 배포 자동화
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: wiki-2026-0508-ci-cd-pipeline-deployment-automation
|
||||
duplicate_of: "[[CI/CD Pipeline and Deployment Automation]]"
|
||||
aliases: []
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, devops, cicd, deployment]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# CI CD 파이프라인 및 배포 자동화
|
||||
|
||||
> **이 문서는 [[CI/CD Pipeline and Deployment Automation]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 핵심 요약
|
||||
- 매 CI = build + test on every commit; CD = automated deploy to staging/prod.
|
||||
- 매 GitHub Actions, GitLab CI, CircleCI, Jenkins, ArgoCD (GitOps).
|
||||
- 매 blue-green, canary, rolling, feature flags 의 deployment patterns.
|
||||
|
||||
## 🔗 Graph
|
||||
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
@@ -0,0 +1,163 @@
|
||||
---
|
||||
id: wiki-2026-0508-cnn
|
||||
title: CNN (Convolutional Neural Network)
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [ConvNet, Convolutional Network]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
verification_status: applied
|
||||
tags: [deep-learning, computer-vision, cnn, neural-network]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: Python
|
||||
framework: PyTorch 2.5 / JAX
|
||||
---
|
||||
|
||||
# CNN (Convolutional Neural Network)
|
||||
|
||||
## 매 한 줄
|
||||
> **"매 CNN 의 핵심: spatial locality + parameter sharing + translation equivariance"**. 매 1989 LeCun LeNet 으로 시작, 매 2012 AlexNet 의 ImageNet breakthrough 가 deep-learning era 의 trigger. 매 2026 현재 ViT 의 주류 진입 unauthenticated, ConvNeXt-V2 / EfficientNet-V2 / RegNet 같은 modern CNN 의 efficiency 의 강점, 매 mobile / edge 의 dominant.
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 architectural primitive
|
||||
- **Conv2d**: 매 sliding kernel — 매 (in_ch, out_ch, kH, kW) parameters.
|
||||
- **Pooling**: max/avg — 매 spatial downsampling.
|
||||
- **BatchNorm / GroupNorm**: 매 internal covariate shift mitigation.
|
||||
- **Residual connection (ResNet)**: 매 identity skip — 매 vanishing gradient solved.
|
||||
- **Depthwise-separable conv (MobileNet)**: 매 efficient — 매 9× FLOPs 감소.
|
||||
|
||||
### 매 inductive biases
|
||||
- **Locality**: 매 nearby pixels correlated.
|
||||
- **Translation equivariance**: 매 object 의 위치 shift 도 같은 feature.
|
||||
- **Hierarchy**: 매 edge → texture → part → object.
|
||||
|
||||
### 매 응용
|
||||
1. Image classification (ResNet, ConvNeXt, EfficientNet).
|
||||
2. Object detection (YOLO v11, RT-DETR backbone).
|
||||
3. Segmentation (U-Net, DeepLab v3+).
|
||||
4. Audio spectrograms, time-series, medical imaging.
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### Basic CNN block (PyTorch)
|
||||
```python
|
||||
import torch.nn as nn
|
||||
|
||||
class ConvBlock(nn.Module):
|
||||
def __init__(self, in_c, out_c, k=3, s=1):
|
||||
super().__init__()
|
||||
self.conv = nn.Conv2d(in_c, out_c, k, s, padding=k//2, bias=False)
|
||||
self.bn = nn.BatchNorm2d(out_c)
|
||||
self.act = nn.GELU()
|
||||
def forward(self, x):
|
||||
return self.act(self.bn(self.conv(x)))
|
||||
```
|
||||
|
||||
### Residual block (ResNet-style)
|
||||
```python
|
||||
class ResBlock(nn.Module):
|
||||
def __init__(self, c):
|
||||
super().__init__()
|
||||
self.b1 = ConvBlock(c, c)
|
||||
self.b2 = ConvBlock(c, c)
|
||||
def forward(self, x):
|
||||
return x + self.b2(self.b1(x))
|
||||
```
|
||||
|
||||
### Depthwise-separable (MobileNet)
|
||||
```python
|
||||
class DWSep(nn.Module):
|
||||
def __init__(self, in_c, out_c, s=1):
|
||||
super().__init__()
|
||||
self.dw = nn.Conv2d(in_c, in_c, 3, s, 1, groups=in_c, bias=False)
|
||||
self.pw = nn.Conv2d(in_c, out_c, 1, 1, 0, bias=False)
|
||||
self.bn = nn.BatchNorm2d(out_c)
|
||||
self.act = nn.GELU()
|
||||
def forward(self, x):
|
||||
return self.act(self.bn(self.pw(self.dw(x))))
|
||||
```
|
||||
|
||||
### ConvNeXt block (2026 modern CNN)
|
||||
```python
|
||||
class ConvNeXtBlock(nn.Module):
|
||||
def __init__(self, dim):
|
||||
super().__init__()
|
||||
self.dwconv = nn.Conv2d(dim, dim, 7, padding=3, groups=dim)
|
||||
self.norm = nn.LayerNorm(dim)
|
||||
self.pw1 = nn.Linear(dim, 4 * dim)
|
||||
self.act = nn.GELU()
|
||||
self.pw2 = nn.Linear(4 * dim, dim)
|
||||
def forward(self, x):
|
||||
i = x
|
||||
x = self.dwconv(x).permute(0, 2, 3, 1) # NCHW -> NHWC
|
||||
x = self.pw2(self.act(self.pw1(self.norm(x))))
|
||||
return i + x.permute(0, 3, 1, 2)
|
||||
```
|
||||
|
||||
### Training loop with mixed precision
|
||||
```python
|
||||
import torch
|
||||
from torch.cuda.amp import autocast, GradScaler
|
||||
|
||||
scaler = GradScaler()
|
||||
opt = torch.optim.AdamW(model.parameters(), lr=3e-4, weight_decay=0.05)
|
||||
for x, y in loader:
|
||||
opt.zero_grad()
|
||||
with autocast():
|
||||
loss = nn.functional.cross_entropy(model(x.cuda()), y.cuda())
|
||||
scaler.scale(loss).backward()
|
||||
scaler.step(opt)
|
||||
scaler.update()
|
||||
```
|
||||
|
||||
### Inference with TorchScript / compile
|
||||
```python
|
||||
model.eval()
|
||||
model = torch.compile(model, mode="reduce-overhead") # PyTorch 2.5+
|
||||
with torch.no_grad():
|
||||
out = model(x)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Small data (<10k images) | Pretrained ResNet-50 + finetune |
|
||||
| Mobile / edge | MobileNetV4 / EfficientNet-Lite |
|
||||
| SOTA on ImageNet | ConvNeXt-V2 or hybrid (CNN+ViT) |
|
||||
| Real-time detection | YOLOv11 (CSPDarknet backbone) |
|
||||
| Medical seg | U-Net++ or nnU-Net |
|
||||
|
||||
**기본값**: 매 timm 의 pretrained ConvNeXt-Tiny — 매 81%+ ImageNet, 매 28M params.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Deep Learning]] · [[Neural Networks]]
|
||||
- 변형: [[ResNet]] · [[EfficientNet]]
|
||||
- 응용: [[Computer Vision]] · [[Object Detection]] · [[Image Segmentation]]
|
||||
- Adjacent: [[Transformer_Architecture_and_LLM_Foundations|Attention Mechanisms]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 architecture sketch 의 generation, 매 training-loop boilerplate, 매 hyperparameter starting points, 매 debugging shape mismatches.
|
||||
**언제 X**: 매 SOTA tuning / benchmark 의 LLM 의존 X — 매 paper + timm 의 reference.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Vanilla VGG-style 의 2026 사용**: 매 outdated — 매 ResNet/ConvNeXt 의 사용.
|
||||
- **No data augmentation**: 매 immediate overfit on small data.
|
||||
- **BatchNorm with batch size 1**: 매 statistic 무의미 — 매 GroupNorm 사용.
|
||||
- **Conv 후 immediate ReLU + BN order 의 inconsistent**: 매 BN→Act 의 standard.
|
||||
- **No mixed precision on modern GPU**: 매 free 2× speedup 의 손실.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (LeCun 1989, He et al. 2015 ResNet, Liu et al. 2022 ConvNeXt, 2024 ConvNeXt-V2).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — CNN fundamentals + ConvNeXt modern patterns |
|
||||
@@ -0,0 +1,193 @@
|
||||
---
|
||||
id: wiki-2026-0508-css-architecture-and-styling
|
||||
title: CSS Architecture and Styling
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [CSS Patterns, Styling Architecture, CSS Methodologies]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
verification_status: applied
|
||||
tags: [css, frontend, design-system, web]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: CSS/TS
|
||||
framework: Tailwind v4 / CSS-in-JS / vanilla CSS
|
||||
---
|
||||
|
||||
# CSS Architecture and Styling
|
||||
|
||||
## 매 한 줄
|
||||
> **"매 CSS architecture 의 핵심: scope + composition + design tokens + 매 minimize specificity wars"**. 매 2010s OOCSS / BEM / SMACSS, 매 2017 CSS-in-JS, 매 2020 utility-first (Tailwind), 매 2024 native CSS (cascade layers, container queries, `:has()`, nesting, view transitions). 매 2026 현재 Tailwind v4 + CSS Modules + design-token system 의 dominant.
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 architecture pillars
|
||||
- **Scoping**: 매 CSS Modules / Shadow DOM / Tailwind atomic / Vue scoped.
|
||||
- **Tokens**: 매 design tokens (`--color-primary`) — 매 single source of truth.
|
||||
- **Cascade layers**: 매 `@layer` — 매 explicit specificity ordering.
|
||||
- **Container queries**: 매 component-level responsive (not viewport).
|
||||
- **Logical properties**: 매 `margin-inline` — 매 i18n RTL/LTR free.
|
||||
|
||||
### 매 modern CSS features (2026 baseline)
|
||||
- `@layer reset, base, components, utilities;`
|
||||
- `@container (min-width: 30rem) { ... }`
|
||||
- `:has(> img)` parent selector.
|
||||
- Native nesting `&` (no preprocessor needed).
|
||||
- `view-transition-name: card-hero;` for smooth navigation.
|
||||
- `color-mix(in oklch, var(--brand) 80%, white)`.
|
||||
|
||||
### 매 응용
|
||||
1. Design systems (Radix, shadcn/ui, Material 3).
|
||||
2. Multi-brand white-label apps (token theming).
|
||||
3. Email templates (limited subset).
|
||||
4. Cross-platform (web + React Native via NativeWind).
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### Design tokens with CSS custom properties
|
||||
```css
|
||||
:root {
|
||||
--color-bg: oklch(98% 0.01 250);
|
||||
--color-fg: oklch(20% 0.03 250);
|
||||
--color-brand: oklch(60% 0.18 260);
|
||||
--space-1: 0.25rem;
|
||||
--space-2: 0.5rem;
|
||||
--radius: 0.5rem;
|
||||
}
|
||||
[data-theme="dark"] {
|
||||
--color-bg: oklch(15% 0.02 250);
|
||||
--color-fg: oklch(95% 0.01 250);
|
||||
}
|
||||
```
|
||||
|
||||
### Cascade layers (specificity sanity)
|
||||
```css
|
||||
@layer reset, base, components, utilities;
|
||||
|
||||
@layer reset {
|
||||
*, *::before, *::after { box-sizing: border-box; margin: 0; }
|
||||
}
|
||||
@layer components {
|
||||
.btn {
|
||||
background: var(--color-brand);
|
||||
color: white;
|
||||
padding: var(--space-2) var(--space-4);
|
||||
border-radius: var(--radius);
|
||||
}
|
||||
}
|
||||
@layer utilities {
|
||||
.mt-4 { margin-top: 1rem; }
|
||||
}
|
||||
```
|
||||
|
||||
### Container queries
|
||||
```css
|
||||
.card-grid { container-type: inline-size; }
|
||||
|
||||
@container (min-width: 30rem) {
|
||||
.card { display: grid; grid-template-columns: 1fr 2fr; }
|
||||
}
|
||||
```
|
||||
|
||||
### Tailwind v4 (CSS-first config)
|
||||
```css
|
||||
@import "tailwindcss";
|
||||
|
||||
@theme {
|
||||
--color-brand: oklch(60% 0.18 260);
|
||||
--font-display: "Inter Display", sans-serif;
|
||||
--breakpoint-3xl: 120rem;
|
||||
}
|
||||
|
||||
@utility scrollbar-hidden {
|
||||
scrollbar-width: none;
|
||||
&::-webkit-scrollbar { display: none; }
|
||||
}
|
||||
```
|
||||
|
||||
### CSS Modules (Vite/Next)
|
||||
```tsx
|
||||
// Button.module.css
|
||||
.btn { background: var(--color-brand); }
|
||||
.btn:hover { filter: brightness(1.1); }
|
||||
|
||||
// Button.tsx
|
||||
import s from "./Button.module.css";
|
||||
export const Button = (p) => <button className={s.btn} {...p} />;
|
||||
```
|
||||
|
||||
### CSS-in-JS (vanilla-extract, zero-runtime)
|
||||
```ts
|
||||
import { style, createTheme } from "@vanilla-extract/css";
|
||||
|
||||
export const [themeClass, vars] = createTheme({
|
||||
color: { brand: "oklch(60% 0.18 260)" },
|
||||
});
|
||||
|
||||
export const button = style({
|
||||
background: vars.color.brand,
|
||||
padding: "0.5rem 1rem",
|
||||
});
|
||||
```
|
||||
|
||||
### View transitions API
|
||||
```css
|
||||
::view-transition-old(card),
|
||||
::view-transition-new(card) {
|
||||
animation-duration: 0.3s;
|
||||
}
|
||||
```
|
||||
|
||||
```js
|
||||
document.startViewTransition(() => updateDOM());
|
||||
```
|
||||
|
||||
### `:has()` for parent-state styling
|
||||
```css
|
||||
.card:has(> img) { padding: 0; }
|
||||
form:has(input:invalid) .submit { opacity: 0.5; }
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Solo / small app | Tailwind v4 |
|
||||
| Design system / library | CSS Modules + tokens, or vanilla-extract |
|
||||
| Mature React app | shadcn/ui (Tailwind + Radix) |
|
||||
| Web Components | Shadow DOM + adopted stylesheets |
|
||||
| Static site / MPA | Native CSS + cascade layers |
|
||||
| Email | Inline styles + table layout |
|
||||
|
||||
**기본값**: 매 web app 의 Tailwind v4 + design tokens + cascade layers.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Web Standards]]
|
||||
- 변형: [[CSS_Architecture_and_Styling|Tailwind CSS]] · [[CSS Modules]] · [[CSS_Architecture_and_Styling|CSS-in-JS]]
|
||||
- 응용: [[Design Systems]]
|
||||
- Adjacent: [[Accessibility (A11y)|Accessibility]] · [[Web Performance]] · [[Responsive Design]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 component CSS scaffolding, 매 token system design, 매 Tailwind class consolidation, 매 legacy CSS refactor (BEM → cascade layers).
|
||||
**언제 X**: 매 pixel-perfect designer review — 매 visual diff tooling 사용.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **`!important` 의 남용**: 매 specificity war — 매 cascade layers 로 해결.
|
||||
- **Magic numbers (`top: 17px`)**: 매 token / spacing scale 의 사용.
|
||||
- **Global selectors (`div { ... }`)**: 매 leakage — 매 scoped 사용.
|
||||
- **Inline styles for everything (CSS-in-JS overuse)**: 매 runtime cost.
|
||||
- **Ignoring `prefers-reduced-motion`**: 매 a11y violation.
|
||||
- **Pixel-only sizing**: 매 `rem` / `em` / `clamp()` 의 사용.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (MDN cascade layers, web.dev container queries, Tailwind v4 docs 2025, CSS Working Group specs).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — modern CSS 2026 (cascade layers, :has, Tailwind v4) |
|
||||
@@ -0,0 +1,203 @@
|
||||
---
|
||||
id: wiki-2026-0508-cloud-native
|
||||
title: Cloud Native
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [CNCF, Cloud-Native Computing, K8s-native]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
verification_status: applied
|
||||
tags: [cloud, kubernetes, devops, microservices, containers]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: Go/YAML
|
||||
framework: Kubernetes/CNCF stack
|
||||
---
|
||||
|
||||
# Cloud Native
|
||||
|
||||
## 매 한 줄
|
||||
> **"매 cloud-native 의 핵심: containers + orchestration + declarative API + 매 immutable infra"**. 매 2014 Google Borg → K8s open-source 으로 시작, 매 2026 현재 CNCF 의 200+ projects (K8s, Istio, Prometheus, Argo, Cilium) 가 매 production-grade platform 의 표준. 매 enterprise 의 90%+ 가 K8s 의 채용 (CNCF 2025 survey).
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 5 pillars (CNCF 정의)
|
||||
- **Containerization**: 매 OCI image (Docker/Podman) — 매 immutable, portable.
|
||||
- **Microservices**: 매 small, single-purpose services.
|
||||
- **DevOps**: 매 CI/CD + culture of automation.
|
||||
- **Continuous Delivery**: 매 GitOps (Argo CD, Flux).
|
||||
- **Orchestration**: 매 K8s — 매 declarative scheduler.
|
||||
|
||||
### 매 K8s 의 핵심 abstractions
|
||||
- **Pod**: 매 minimum deployable unit (1+ containers, shared net/storage).
|
||||
- **Deployment**: 매 ReplicaSet manager — 매 rolling update.
|
||||
- **Service**: 매 stable virtual IP / DNS for pods.
|
||||
- **Ingress / Gateway API**: 매 L7 routing — 매 2026 Gateway API 가 stable.
|
||||
- **ConfigMap / Secret**: 매 config injection.
|
||||
|
||||
### 매 응용
|
||||
1. SaaS multi-tenant platforms (e.g., Slack, Snowflake).
|
||||
2. ML model serving (KServe, Seldon Core).
|
||||
3. Event-driven backends (Knative Eventing, KEDA).
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### Deployment + Service (basic)
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: api
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels: { app: api }
|
||||
template:
|
||||
metadata:
|
||||
labels: { app: api }
|
||||
spec:
|
||||
containers:
|
||||
- name: api
|
||||
image: ghcr.io/me/api:1.4.0
|
||||
ports: [{ containerPort: 8080 }]
|
||||
resources:
|
||||
requests: { cpu: 100m, memory: 128Mi }
|
||||
limits: { cpu: 500m, memory: 512Mi }
|
||||
readinessProbe:
|
||||
httpGet: { path: /health, port: 8080 }
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata: { name: api }
|
||||
spec:
|
||||
selector: { app: api }
|
||||
ports: [{ port: 80, targetPort: 8080 }]
|
||||
```
|
||||
|
||||
### HPA (Horizontal Pod Autoscaler)
|
||||
```yaml
|
||||
apiVersion: autoscaling/v2
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata: { name: api-hpa }
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: api
|
||||
minReplicas: 3
|
||||
maxReplicas: 30
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
target: { type: Utilization, averageUtilization: 70 }
|
||||
```
|
||||
|
||||
### Gateway API (modern Ingress)
|
||||
```yaml
|
||||
apiVersion: gateway.networking.k8s.io/v1
|
||||
kind: HTTPRoute
|
||||
metadata: { name: api-route }
|
||||
spec:
|
||||
parentRefs: [{ name: prod-gateway }]
|
||||
hostnames: ["api.example.com"]
|
||||
rules:
|
||||
- matches: [{ path: { type: PathPrefix, value: /v1 } }]
|
||||
backendRefs: [{ name: api, port: 80 }]
|
||||
```
|
||||
|
||||
### Helm chart values pattern
|
||||
```yaml
|
||||
# values.yaml
|
||||
image:
|
||||
repo: ghcr.io/me/api
|
||||
tag: "1.4.0"
|
||||
replicas: 3
|
||||
resources:
|
||||
cpu: 500m
|
||||
memory: 512Mi
|
||||
```
|
||||
|
||||
### GitOps (Argo CD Application)
|
||||
```yaml
|
||||
apiVersion: argoproj.io/v1alpha1
|
||||
kind: Application
|
||||
metadata: { name: api }
|
||||
spec:
|
||||
project: default
|
||||
source:
|
||||
repoURL: https://github.com/me/infra
|
||||
path: apps/api
|
||||
targetRevision: main
|
||||
destination:
|
||||
server: https://kubernetes.default.svc
|
||||
namespace: prod
|
||||
syncPolicy:
|
||||
automated: { prune: true, selfHeal: true }
|
||||
```
|
||||
|
||||
### NetworkPolicy (zero-trust default)
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata: { name: deny-all }
|
||||
spec:
|
||||
podSelector: {}
|
||||
policyTypes: [Ingress, Egress]
|
||||
```
|
||||
|
||||
### Operator pattern (CRD)
|
||||
```go
|
||||
// controller-runtime Reconciler
|
||||
func (r *MyReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
|
||||
var obj v1.MyResource
|
||||
if err := r.Get(ctx, req.NamespacedName, &obj); err != nil {
|
||||
return ctrl.Result{}, client.IgnoreNotFound(err)
|
||||
}
|
||||
// ensure desired state...
|
||||
return ctrl.Result{RequeueAfter: 30 * time.Second}, nil
|
||||
}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Small team, 1-2 services | 매 managed PaaS (Fly, Render) — K8s overkill |
|
||||
| 10+ services, multi-team | K8s + GitOps (Argo) |
|
||||
| Edge / IoT | K3s, KubeEdge |
|
||||
| Serverless workloads | Knative or cloud Functions |
|
||||
| Strict compliance | OpenShift / GKE Autopilot |
|
||||
|
||||
**기본값**: 매 managed K8s (EKS/GKE/AKS) + Argo CD + Helm.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Distributed Systems]] · [[DevOps]]
|
||||
- 변형: [[Kubernetes]] · [[Service Mesh]] · [[Serverless]]
|
||||
- 응용: [[Microservices]] · [[Platform Engineering]]
|
||||
- Adjacent: [[Edge Computing]] · [[Observability]] · [[GitOps]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 K8s YAML 생성, Helm chart drafting, 매 troubleshooting (kubectl describe → root cause), 매 manifest review.
|
||||
**언제 X**: 매 cluster credentials / secrets 의 prompt 에 포함 X. 매 production drift detection 은 GitOps tooling 사용.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Lift-and-shift VM mindset**: 매 stateful pet servers 의 K8s 에 그대로 — 매 cattle 화 X.
|
||||
- **No resource limits**: 매 noisy-neighbor / OOM cascade.
|
||||
- **Cluster-admin everywhere**: 매 RBAC bypass — 매 zero-trust violation.
|
||||
- **Ignoring node autoscaling**: 매 capacity ceiling — 매 outage during spike.
|
||||
- **Custom CRDs for everything**: 매 ecosystem fragmentation — 매 CNCF projects 의 reuse.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (CNCF official definition, K8s docs v1.31+, 2025 CNCF survey).
|
||||
- 신뢰도 A.
|
||||
- 관련: [[Cloud Native and Microservices]] (duplicate, redirected).
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Cloud Native canonical 정립, K8s patterns + GitOps |
|
||||
@@ -0,0 +1,189 @@
|
||||
---
|
||||
id: wiki-2026-0508-data-schema
|
||||
title: Data Schema
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [Schema Design, Data Modeling, Schema Definition]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.93
|
||||
verification_status: applied
|
||||
tags: [data, schema, database, modeling, validation]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: SQL/JSON/TS
|
||||
framework: Postgres / Avro / Zod / JSON Schema
|
||||
---
|
||||
|
||||
# Data Schema
|
||||
|
||||
## 매 한 줄
|
||||
> **"매 schema 의 핵심: structure + constraints + evolution + 매 contract between producers/consumers"**. 매 1970 Codd relational model 으로 시작, 매 2000s schemaless / NoSQL backlash, 매 2020s schema-on-read 의 한계 인식 후 매 type-safe 회귀 (Zod, TypeScript-first ORMs, dbt contracts). 매 2026 현재 schema-as-code + version-aware evolution 의 standard.
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 schema layers
|
||||
- **Conceptual**: 매 ERD — 매 business entities.
|
||||
- **Logical**: 매 normalized tables — 매 BCNF/3NF.
|
||||
- **Physical**: 매 indexes, partitions, storage.
|
||||
- **API/Wire**: 매 JSON Schema, Avro, Protobuf, GraphQL.
|
||||
- **Validation**: 매 Zod, Pydantic, Joi (runtime).
|
||||
|
||||
### 매 evolution principles
|
||||
- **Backward compatible**: 매 add nullable / default 만 — 매 reader of old schema 의 새 data read 가능.
|
||||
- **Forward compatible**: 매 unknown field 의 ignore.
|
||||
- **Full compatible**: 매 둘 다.
|
||||
- **SemVer for schemas**: 매 breaking = major bump.
|
||||
|
||||
### 매 응용
|
||||
1. Database schema (Postgres, MySQL, BigQuery).
|
||||
2. Event streaming (Kafka + Schema Registry).
|
||||
3. API contracts (OpenAPI, GraphQL, tRPC).
|
||||
4. Data lake / lakehouse (Iceberg, Delta Lake schema).
|
||||
5. Form validation (frontend + backend shared via Zod).
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### Postgres schema with constraints
|
||||
```sql
|
||||
CREATE TABLE users (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
email TEXT NOT NULL UNIQUE CHECK (email ~* '^.+@.+\..+$'),
|
||||
name TEXT NOT NULL,
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
||||
status TEXT NOT NULL CHECK (status IN ('active','suspended','deleted'))
|
||||
);
|
||||
|
||||
CREATE INDEX users_status_idx ON users(status) WHERE status = 'active';
|
||||
```
|
||||
|
||||
### Zod (TypeScript) — runtime + static type
|
||||
```ts
|
||||
import { z } from "zod";
|
||||
|
||||
export const User = z.object({
|
||||
id: z.string().uuid(),
|
||||
email: z.string().email(),
|
||||
name: z.string().min(1).max(100),
|
||||
age: z.number().int().min(0).max(150).optional(),
|
||||
status: z.enum(["active", "suspended", "deleted"]),
|
||||
});
|
||||
export type User = z.infer<typeof User>;
|
||||
|
||||
const parsed = User.parse(jsonInput); // throws on invalid
|
||||
```
|
||||
|
||||
### JSON Schema (language-agnostic)
|
||||
```json
|
||||
{
|
||||
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
||||
"type": "object",
|
||||
"required": ["id", "email"],
|
||||
"properties": {
|
||||
"id": { "type": "string", "format": "uuid" },
|
||||
"email": { "type": "string", "format": "email" },
|
||||
"age": { "type": "integer", "minimum": 0 }
|
||||
},
|
||||
"additionalProperties": false
|
||||
}
|
||||
```
|
||||
|
||||
### Avro schema (Kafka)
|
||||
```json
|
||||
{
|
||||
"type": "record",
|
||||
"name": "UserCreated",
|
||||
"namespace": "com.example.events",
|
||||
"fields": [
|
||||
{ "name": "id", "type": "string" },
|
||||
{ "name": "email", "type": "string" },
|
||||
{ "name": "age", "type": ["null", "int"], "default": null }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Protobuf (gRPC)
|
||||
```proto
|
||||
syntax = "proto3";
|
||||
package user.v1;
|
||||
|
||||
message User {
|
||||
string id = 1;
|
||||
string email = 2;
|
||||
string name = 3;
|
||||
optional int32 age = 4;
|
||||
enum Status { ACTIVE = 0; SUSPENDED = 1; DELETED = 2; }
|
||||
Status status = 5;
|
||||
}
|
||||
```
|
||||
|
||||
### Pydantic v2 (Python)
|
||||
```python
|
||||
from pydantic import BaseModel, EmailStr, Field
|
||||
from typing import Literal
|
||||
from uuid import UUID
|
||||
|
||||
class User(BaseModel):
|
||||
id: UUID
|
||||
email: EmailStr
|
||||
name: str = Field(min_length=1, max_length=100)
|
||||
age: int | None = Field(default=None, ge=0, le=150)
|
||||
status: Literal["active", "suspended", "deleted"]
|
||||
```
|
||||
|
||||
### Migration (Alembic / Drizzle)
|
||||
```python
|
||||
# alembic upgrade — backward compatible
|
||||
def upgrade():
|
||||
op.add_column("users",
|
||||
sa.Column("phone", sa.String(20), nullable=True)) # nullable = safe
|
||||
```
|
||||
|
||||
### Iceberg schema evolution (lakehouse)
|
||||
```sql
|
||||
ALTER TABLE catalog.db.users ADD COLUMN phone STRING;
|
||||
ALTER TABLE catalog.db.users RENAME COLUMN nm TO name; -- safe in Iceberg
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| OLTP RDBMS | Strict SQL DDL + migrations |
|
||||
| Event streaming | Avro + Schema Registry |
|
||||
| Microservice gRPC | Protobuf |
|
||||
| Frontend form + backend | Zod (shared) |
|
||||
| Data lake | Iceberg / Delta with schema evolution |
|
||||
| Document store | JSON Schema validation in app |
|
||||
|
||||
**기본값**: 매 strict schema-first — 매 schemaless 의 default 의 X (debt 누적).
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Database Design]] · [[Data Modeling]]
|
||||
- 변형: [[JSON Schema]] · [[Avro]] · [[Protobuf]]
|
||||
- 응용: [[API Design]] · [[Event-Driven Architecture]]
|
||||
- Adjacent: [[Schema Migration]] · [[TypeScript 타입 시스템 (TypeScript Type System)|Type Systems]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 schema drafting from natural-language requirements, 매 migration generation, 매 schema diff explanation, 매 cross-format conversion (Postgres ↔ Avro ↔ Protobuf).
|
||||
**언제 X**: 매 production migrations 의 LLM 의 단독 실행 X — 매 review + dry-run 필수.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Schema-on-read everything**: 매 cost 는 consumer 가 부담 — 매 chaos.
|
||||
- **Breaking changes without versioning**: 매 consumer outage.
|
||||
- **Storing JSON blobs in JSON column without structure**: 매 query nightmare.
|
||||
- **No NOT NULL / no FK / no CHECK**: 매 DB 의 dumb storage 화.
|
||||
- **Reusing field IDs in protobuf**: 매 wire incompatibility.
|
||||
- **Adding required field 의 backward compatibility 위반**.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Codd 1970, Kleppmann "Designing Data-Intensive Applications", Confluent Schema Registry docs, JSON Schema 2020-12, Iceberg spec).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — schema layers + evolution + 2026 tooling |
|
||||
@@ -0,0 +1,192 @@
|
||||
---
|
||||
id: wiki-2026-0508-edge-computing
|
||||
title: Edge Computing
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [Edge AI, Fog Computing, Edge Inference, MEC]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
verification_status: applied
|
||||
tags: [edge, iot, distributed-systems, latency, on-device]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: Rust/C++/Python
|
||||
framework: K3s / Cloudflare Workers / ONNX Runtime / WasmEdge
|
||||
---
|
||||
|
||||
# Edge Computing
|
||||
|
||||
## 매 한 줄
|
||||
> **"매 edge computing 의 핵심: compute moves to data — latency + bandwidth + privacy"**. 매 2010s CDN edge → 매 2020s function-edge (Cloudflare Workers, Deno Deploy, AWS Lambda@Edge), 매 2022 edge AI inference, 매 2024 5G MEC. 매 2026 현재 phone (Apple Intelligence, Pixel Gemini Nano) → CDN edge (Workers AI) → micro-DC 의 3-tier edge stack 의 일반화.
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 edge spectrum
|
||||
- **Device edge**: 매 phone, sensor, MCU, robot.
|
||||
- **Near edge / On-prem**: 매 factory floor, retail store K8s.
|
||||
- **Far edge / CDN**: 매 Cloudflare, Fastly, Akamai PoPs.
|
||||
- **MEC (Mobile Edge Computing)**: 매 5G base station co-located.
|
||||
|
||||
### 매 drivers
|
||||
- **Latency**: 매 <10ms — 매 cloud round-trip 의 불가능.
|
||||
- **Bandwidth**: 매 video / sensor stream의 cloud 전송 cost.
|
||||
- **Privacy / sovereignty**: 매 data 의 region / device 외 미반출.
|
||||
- **Resilience**: 매 offline operation.
|
||||
- **Cost**: 매 egress fee 회피.
|
||||
|
||||
### 매 응용
|
||||
1. Real-time vision (autonomous driving, AR).
|
||||
2. Voice assistants (Siri on-device wake-word).
|
||||
3. Industrial control (PLC + edge AI).
|
||||
4. Game streaming, low-latency RTC.
|
||||
5. Edge AI inference (Llama 3.2 on phone, Whisper on Pi).
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### Cloudflare Workers (function edge)
|
||||
```ts
|
||||
export default {
|
||||
async fetch(req: Request, env: Env): Promise<Response> {
|
||||
const cache = caches.default;
|
||||
const cached = await cache.match(req);
|
||||
if (cached) return cached;
|
||||
const data = await env.DB.prepare("SELECT * FROM posts LIMIT 10").all();
|
||||
const res = new Response(JSON.stringify(data),
|
||||
{ headers: { "cache-control": "max-age=60" } });
|
||||
await cache.put(req, res.clone());
|
||||
return res;
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
### Workers AI (edge LLM inference)
|
||||
```ts
|
||||
export default {
|
||||
async fetch(req, env) {
|
||||
const { prompt } = await req.json();
|
||||
const out = await env.AI.run("@cf/meta/llama-3.2-3b-instruct",
|
||||
{ prompt, max_tokens: 200 });
|
||||
return Response.json(out);
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
### K3s (lightweight K8s for edge)
|
||||
```bash
|
||||
# Install on edge node
|
||||
curl -sfL https://get.k3s.io | sh -s - --disable traefik --node-name edge-01
|
||||
# Deploy edge inference service
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata: { name: edge-yolo }
|
||||
spec:
|
||||
replicas: 1
|
||||
template:
|
||||
spec:
|
||||
nodeSelector: { tier: edge }
|
||||
containers:
|
||||
- name: yolo
|
||||
image: ghcr.io/me/yolo11n:latest
|
||||
resources: { limits: { cpu: "2", memory: 2Gi } }
|
||||
EOF
|
||||
```
|
||||
|
||||
### ONNX Runtime on edge (Raspberry Pi 5)
|
||||
```python
|
||||
import onnxruntime as ort
|
||||
import numpy as np
|
||||
sess = ort.InferenceSession("yolov11n.onnx",
|
||||
providers=["CPUExecutionProvider"])
|
||||
out = sess.run(None, {"images": img.astype(np.float32)})
|
||||
```
|
||||
|
||||
### WasmEdge (portable edge runtime)
|
||||
```rust
|
||||
// Compile Rust → wasm32-wasi
|
||||
fn main() {
|
||||
let img = std::fs::read("input.jpg").unwrap();
|
||||
let result = run_inference(&img);
|
||||
println!("{:?}", result);
|
||||
}
|
||||
// Run: wasmedge app.wasm
|
||||
```
|
||||
|
||||
### MQTT-bridged hierarchical edge
|
||||
```python
|
||||
# Edge gateway aggregates sensors, forwards summaries to cloud
|
||||
import paho.mqtt.client as mqtt
|
||||
|
||||
def on_local(client, _, msg):
|
||||
summary = aggregate(msg.payload)
|
||||
cloud.publish("plant/summary", summary)
|
||||
|
||||
local = mqtt.Client(); local.connect("localhost"); local.on_message = on_local
|
||||
local.subscribe("sensors/#"); local.loop_start()
|
||||
|
||||
cloud = mqtt.Client(); cloud.connect("cloud.broker.com")
|
||||
```
|
||||
|
||||
### CRDT-based offline-first sync
|
||||
```ts
|
||||
import * as Y from "yjs";
|
||||
import { WebsocketProvider } from "y-websocket";
|
||||
const doc = new Y.Doc();
|
||||
// Works offline, merges automatically when reconnected
|
||||
new WebsocketProvider("wss://sync.edge.local", "doc1", doc);
|
||||
```
|
||||
|
||||
### Edge LLM with quantization (mobile)
|
||||
```python
|
||||
# Convert Llama 3.2 3B to 4-bit GGUF for mobile
|
||||
# llama.cpp or MLX
|
||||
from mlx_lm import convert
|
||||
convert("meta-llama/Llama-3.2-3B-Instruct",
|
||||
mlx_path="llama-3b-q4", quantize=True, q_bits=4)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Static asset / API cache | CDN (Cloudflare, Fastly) |
|
||||
| Low-latency API | Workers / Deno Deploy |
|
||||
| Stateful edge service | K3s on near-edge |
|
||||
| Sensor / IoT | MQTT + edge gateway |
|
||||
| Edge AI inference | ONNX Runtime / TFLite / Core ML |
|
||||
| Cross-platform portable | Wasm (WasmEdge, Spin) |
|
||||
| Personal AI | On-device LLM (MLX, llama.cpp) |
|
||||
|
||||
**기본값**: 매 latency-sensitive read 은 CDN edge, 매 sensor data 의 edge gateway 에서 aggregate.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Distributed Systems]]
|
||||
- 변형: [[CDN]] · [[Serverless]] · [[MEC]]
|
||||
- 응용: [[클라우드 인프라 및 IaC 운영 표준|IoT]] · [[Edge AI]] · [[On-device AI]]
|
||||
- Adjacent: [[Cloud Native]] · [[Data Privacy & Local Processing]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 edge deployment scaffolding (K3s manifests, Workers code), 매 quantization workflow, 매 latency-budget reasoning.
|
||||
**언제 X**: 매 hard-real-time (<1ms) — 매 LLM 의지 X. 매 deterministic timing 의 RTOS 사용.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Edge as cloud-with-extra-steps**: 매 unnecessary 사용 — 매 latency / privacy 명확한 driver 없으면 cloud.
|
||||
- **No degradation strategy**: 매 edge offline → 전체 fail.
|
||||
- **State at every edge**: 매 consistency nightmare — 매 CRDT / eventual 의 사용.
|
||||
- **Same model size as cloud**: 매 device OOM — 매 quantize + distill.
|
||||
- **Ignoring network partitions**: 매 split-brain → corrupted state.
|
||||
- **Pushing all logic to client**: 매 trust boundary violation.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Cloudflare Workers docs 2025, K3s docs, ETSI MEC spec, ONNX Runtime mobile docs, Llama 3.2 release notes 2024).
|
||||
- 신뢰도 A.
|
||||
- 관련: [[Cloud Native]], [[Data Privacy & Local Processing]].
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — edge spectrum + 2026 tooling (Workers AI, MLX, K3s) |
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
id: wiki-2026-0508-encoder-decoder-inconsistency
|
||||
title: Encoder Decoder Inconsistency
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [encoder-decoder-mismatch, seq2seq-inconsistency]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [nlp, transformer, training, decoding]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: pytorch
|
||||
---
|
||||
|
||||
# Encoder Decoder Inconsistency
|
||||
|
||||
## 매 한 줄
|
||||
> **"매 encoder가 본 분포 ≠ decoder가 생성하는 분포"**. Seq2seq training 시 encoder는 ground-truth context를 보지만 decoder는 inference에서 자기 prediction을 다시 입력으로 받기 때문에 train/inference 간 distribution shift가 발생한다. 매 exposure bias 의 근본 원인.
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 정의
|
||||
- **Train**: decoder input = teacher-forced ground truth.
|
||||
- **Inference**: decoder input = previously generated token.
|
||||
- **Gap**: 매 error compounds along sequence — early mistake → later tokens conditioned on out-of-distribution prefix.
|
||||
|
||||
### 매 표현
|
||||
- Exposure bias (Ranzato 2016).
|
||||
- Schedule sampling 의 motivation.
|
||||
- Hallucination 의 한 원인 (특히 long-form generation).
|
||||
|
||||
### 매 응용
|
||||
1. NMT (Neural Machine Translation) — 매 long sentence translation degradation.
|
||||
2. Summarization — repetition / drift.
|
||||
3. Speech recognition — RNN-T vs CTC trade-off.
|
||||
4. Code generation — 매 long completion 의 syntax break.
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### Scheduled Sampling
|
||||
```python
|
||||
import torch
|
||||
import torch.nn.functional as F
|
||||
|
||||
def scheduled_sampling_step(decoder, prev_token, hidden, gt_token, p_use_gt: float):
|
||||
"""p_use_gt 의 확률로 ground-truth, 아니면 model prediction 의 사용."""
|
||||
if torch.rand(1).item() < p_use_gt:
|
||||
input_tok = gt_token
|
||||
else:
|
||||
with torch.no_grad():
|
||||
logits, _ = decoder(prev_token, hidden)
|
||||
input_tok = logits.argmax(dim=-1)
|
||||
out_logits, hidden = decoder(input_tok, hidden)
|
||||
return out_logits, hidden
|
||||
```
|
||||
|
||||
### Minimum Risk Training
|
||||
```python
|
||||
def mrt_loss(model, src, refs, n_samples=8):
|
||||
"""매 sequence-level loss 의 — 매 sampled hypotheses 에 대해 risk minimize."""
|
||||
hyps = [model.sample(src) for _ in range(n_samples)]
|
||||
risks = torch.tensor([1 - bleu(h, refs) for h in hyps])
|
||||
log_probs = torch.stack([model.log_prob(h, src) for h in hyps])
|
||||
weights = F.softmax(log_probs, dim=0)
|
||||
return (weights * risks).sum()
|
||||
```
|
||||
|
||||
### Self-distillation Fix
|
||||
```python
|
||||
def self_distill(student, teacher, src, T=2.0):
|
||||
"""매 teacher 가 자기 생성한 sequence 의 사용 — 매 train/inference gap 축소."""
|
||||
with torch.no_grad():
|
||||
gen = teacher.generate(src, do_sample=True, top_p=0.9)
|
||||
teacher_logits = teacher(src, gen).logits
|
||||
student_logits = student(src, gen).logits
|
||||
return F.kl_div(
|
||||
F.log_softmax(student_logits / T, dim=-1),
|
||||
F.softmax(teacher_logits / T, dim=-1),
|
||||
reduction="batchmean",
|
||||
) * T * T
|
||||
```
|
||||
|
||||
### Beam Search with Length Penalty
|
||||
```python
|
||||
def length_penalty(score, length, alpha=0.7):
|
||||
"""GNMT length penalty — 매 short hypothesis 의 bias 보정."""
|
||||
return score / ((5 + length) ** alpha / (5 + 1) ** alpha)
|
||||
```
|
||||
|
||||
### Contrastive Decoding
|
||||
```python
|
||||
def contrastive_decode(big, small, prompt, alpha=0.5):
|
||||
"""매 large model logit − small model logit — 매 expert/amateur gap 의 강조."""
|
||||
big_logits = big(prompt).logits[:, -1]
|
||||
small_logits = small(prompt).logits[:, -1]
|
||||
return big_logits - alpha * small_logits
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Short sequence (<32) | Teacher forcing 충분 |
|
||||
| Long sequence | Scheduled sampling / MRT |
|
||||
| Production NMT | Beam + length penalty + coverage |
|
||||
| LLM long-form | Contrastive decoding / self-distillation |
|
||||
|
||||
**기본값**: teacher forcing + 1k step warmup 이후 scheduled sampling.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Sequence-to-Sequence]] · [[Transformer]]
|
||||
- Adjacent: [[Hallucination]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: long-form generation 의 quality issue 분석 시. Train/eval BLEU gap 의 진단.
|
||||
**언제 X**: 매 short classification — 매 inconsistency 의 무관.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Pure teacher forcing forever**: 매 inference distribution 의 미본 채 deploy.
|
||||
- **Greedy decoding only**: 매 early mistake 의 lock-in.
|
||||
- **No length normalization**: beam 의 short hypothesis bias.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Ranzato et al. 2016, Bengio et al. 2015 scheduled sampling).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — encoder/decoder distribution shift + scheduled sampling/MRT/contrastive decoding |
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: wiki-2026-0508-g1nation-build-fix-report
|
||||
title: G1nation Build Fix Report
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: build-failure-postmortem
|
||||
duplicate_of: "[[Build-Failure-Postmortem]]"
|
||||
aliases: []
|
||||
source_trust_level: B
|
||||
confidence_score: 0.7
|
||||
verification_status: redirected
|
||||
tags: [duplicate, ci-cd, postmortem, internal]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# G1nation Build Fix Report
|
||||
|
||||
> **이 문서는 [[Build-Failure-Postmortem]] 의 중복본입니다.** Canonical 문서로 redirect. (개인 project report — generic build failure pattern 의 specialization.)
|
||||
|
||||
## 핵심 요약
|
||||
- Internal build fix log — generic CI 디버깅 흐름 의 instance.
|
||||
|
||||
## 🔗 Graph
|
||||
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
@@ -0,0 +1,178 @@
|
||||
---
|
||||
id: wiki-2026-0508-green-check-mark-syndrome
|
||||
title: Green Check Mark Syndrome
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [Green Check Syndrome, CI Theater, Test Theater]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [anti-pattern, ci-cd, testing, observability]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: TypeScript/Python
|
||||
framework: GitHub-Actions/pytest
|
||||
---
|
||||
|
||||
# Green Check Mark Syndrome
|
||||
|
||||
## 매 한 줄
|
||||
> **"매 green CI ≠ correct system."** 매 anti-pattern: 매 passing tests 의 confidence inflation, 매 actual coverage / assertion strength / production behavior 의 disconnect. 매 2026 prevalent — 매 LLM-generated tests, 매 mock-heavy suites, 매 flaky-retry hides 매 real bugs.
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 Symptoms
|
||||
- 매 100% green builds, 매 still production incidents 의 frequent.
|
||||
- 매 tests assert truisms (`expect(1).toBe(1)`).
|
||||
- 매 mocks return canned data — 매 integration paths 의 untested.
|
||||
- 매 retries hide flakiness — 매 race conditions 의 ignored.
|
||||
- 매 coverage % high, 매 mutation score low.
|
||||
|
||||
### 매 Root causes
|
||||
- **Goodhart's law**: 매 green check 의 metric → metric 의 target → 매 gamed.
|
||||
- **Mock theater**: 매 unit isolation 의 over-mocked, 매 real failure modes 의 missed.
|
||||
- **AI-generated tests**: 매 LLM이 매 implementation을 매 mirror — 매 same bug 의 test에도 present.
|
||||
- **Flaky-retry culture**: 매 "retry until green" 의 normalized.
|
||||
|
||||
### 매 Detection
|
||||
- Mutation testing — 매 assertion strength measurement.
|
||||
- Property-based testing — 매 input space coverage.
|
||||
- Production observability — 매 errors in prod that tests 의 missed.
|
||||
- Test-impact analysis — 매 untouched code paths surface.
|
||||
|
||||
### 매 응용
|
||||
1. CI quality dashboard — 매 mutation score + flake rate.
|
||||
2. Test review checklist — 매 each test 의 specific failure mode가 매 catch?
|
||||
3. Chaos engineering — 매 production-like failures inject.
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### Mutation testing (Stryker)
|
||||
```javascript
|
||||
// stryker.conf.json
|
||||
{
|
||||
"mutate": ["src/**/*.ts"],
|
||||
"testRunner": "vitest",
|
||||
"thresholds": { "high": 80, "low": 60, "break": 50 }
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
npx stryker run
|
||||
# 매 surviving mutants 의 매 weak tests indicate
|
||||
```
|
||||
|
||||
### Property-based test
|
||||
```typescript
|
||||
import { fc } from 'fast-check';
|
||||
|
||||
test('reverse twice = identity', () => {
|
||||
fc.assert(
|
||||
fc.property(fc.array(fc.integer()), (arr) => {
|
||||
expect(reverse(reverse(arr))).toEqual(arr);
|
||||
})
|
||||
);
|
||||
});
|
||||
```
|
||||
|
||||
### Flake-detector (no silent retry)
|
||||
```yaml
|
||||
# .github/workflows/test.yml
|
||||
- name: Test
|
||||
run: npm test
|
||||
# NO retry — 매 flake 의 immediately surface
|
||||
- name: Flake report
|
||||
if: failure()
|
||||
run: |
|
||||
echo "::warning::Test failed — investigate, do not retry blindly"
|
||||
```
|
||||
|
||||
### Assertion-strength linter
|
||||
```python
|
||||
# detect weak assertions
|
||||
import ast
|
||||
from pathlib import Path
|
||||
|
||||
WEAK_PATTERNS = {'assertTrue(True)', 'assertEqual(1, 1)', 'assert True'}
|
||||
|
||||
for file in Path('tests').rglob('*.py'):
|
||||
tree = ast.parse(file.read_text())
|
||||
for node in ast.walk(tree):
|
||||
if isinstance(node, ast.Call) and ast.unparse(node) in WEAK_PATTERNS:
|
||||
print(f"WEAK: {file}:{node.lineno}")
|
||||
```
|
||||
|
||||
### Production-trace replay
|
||||
```python
|
||||
# 매 prod traces → test fixtures
|
||||
import json
|
||||
from opentelemetry.trace import get_tracer
|
||||
|
||||
def replay_prod_trace(trace_id: str):
|
||||
trace = fetch_trace(trace_id) # from observability backend
|
||||
inputs = extract_inputs(trace)
|
||||
result = run_system(inputs)
|
||||
expected = trace.outputs
|
||||
assert result == expected, f"Drift from prod: {trace_id}"
|
||||
```
|
||||
|
||||
### Real integration (no mocks)
|
||||
```typescript
|
||||
// testcontainers — 매 real DB
|
||||
import { GenericContainer } from 'testcontainers';
|
||||
|
||||
let pg: StartedTestContainer;
|
||||
beforeAll(async () => {
|
||||
pg = await new GenericContainer('postgres:17')
|
||||
.withExposedPorts(5432)
|
||||
.withEnvironment({ POSTGRES_PASSWORD: 'test' })
|
||||
.start();
|
||||
});
|
||||
|
||||
test('real query', async () => {
|
||||
const client = connect(pg.getMappedPort(5432));
|
||||
await client.query('CREATE TABLE u (id int)');
|
||||
// 매 real SQL behavior tested
|
||||
});
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| New test suite | Property-based + integration |
|
||||
| Existing green-but-fragile suite | Mutation testing audit |
|
||||
| Flaky test | Investigate root cause, never blind-retry |
|
||||
| Mock-heavy suite | Add testcontainers for real I/O |
|
||||
| Coverage-driven culture | Switch metric to mutation score |
|
||||
|
||||
**기본값**: 매 green CI 의 trust 의 X — 매 mutation score + 매 prod observability + 매 chaos drills 의 combined signal.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[CI CD]]
|
||||
- 변형: [[Test-Theater]]
|
||||
- 응용: [[Mutation-Testing]] · [[Property-Based-Testing]] · [[Chaos-Engineering]]
|
||||
- Adjacent: [[Goodharts-Law]] · [[Observability]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: test review (assertion strength critique), mutation report triage, prod-trace replay generation.
|
||||
**언제 X**: 매 LLM이 매 test generation 단독 — 매 same blind spots reproduce.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Coverage as quality**: 매 100% line coverage, 매 0% mutation kill rate.
|
||||
- **Auto-retry on fail**: 매 race condition 의 hide → prod incident.
|
||||
- **Mock everything**: 매 unit "passes", 매 integration broken.
|
||||
- **LLM-only test suite**: 매 implementation mirror — 매 bug parity.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Hillel Wayne "Test theater", Google Testing Blog "Just Say No to More End-to-End Tests").
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — CI theater anti-pattern, mutation testing, real integration |
|
||||
+114
@@ -0,0 +1,114 @@
|
||||
---
|
||||
id: wiki-2026-0508-llm-optimization-and-deployment-
|
||||
title: LLM Optimization and Deployment Strategies
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-CANONICAL-LLM-OPTIMIZATION]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [canonical, llm-ops, quantization, distillation, peft, vllm, inference]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[LLM_Optimization_and_Deployment_Strategies|LLM Optimization & Deployment Strategies]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "지능의 밀도는 높이고, 실행의 비용은 낮추라." LLM 최적화는 거대한 모델의 파라미터를 압축(양자화, 증류)하고, 학습 효율을 극대화(PEFT)하며, 추론 엔진(vLLM, PagedAttention)을 통해 처리량을 최대로 끌어올려 실전 서비스가 가능한 수준으로 지능을 정제하는 프로세스입니다.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
### 1. 모델 압축 기술 (Model Compression)
|
||||
* **Quantization (양자화):** 32비트 부동소수점(FP32) 가중치를 8비트(INT8) 또는 4비트(INT4/NF4)로 변환하여 메모리 사용량을 70% 이상 절감하면서도 성능 저하를 최소화합니다. (GGUF, EXL2, AWQ 등)
|
||||
* **Knowledge Distillation (지식 증류):** 거대한 교사(Teacher) 모델의 지식을 작고 빠른 학생(Student) 모델에게 전이시켜, 작은 모델로도 높은 성능을 내게 합니다.
|
||||
* **Pruning (가지치기):** 모델에서 중요도가 낮은 뉴런이나 연결을 제거하여 연산량을 줄입니다.
|
||||
|
||||
### 2. 효율적 미세 조정 (PEFT)
|
||||
* **LoRA (Low-Rank Adaptation):** 전체 가중치를 고정하고 매우 작은 크기의 행렬만을 학습시켜, 적은 리소스로도 특정 도메인에 특화된 모델을 생성합니다.
|
||||
* **QLoRA:** 양자화된 모델 위에 LoRA를 적용하여 단일 소비자용 GPU에서도 수십억 파라미터 모델의 미세 조정이 가능하게 합니다.
|
||||
|
||||
### 3. LLM Ops 및 실전 배포 (LLM Ops & Deployment)
|
||||
* **vLLM & PagedAttention:** OS의 가상 메모리 관리 방식에서 영감을 얻어 KV 캐시 메모리를 효율적으로 관리, 추론 처리량(Throughput)을 수 배 이상 향상시킵니다.
|
||||
* **Speculative Decoding:** 작은 보조 모델이 먼저 토큰을 생성하고 큰 모델이 이를 검증하는 방식으로 추론 속도를 가속화합니다.
|
||||
* **Continuous Monitoring & Evaluation:** 모델의 응답 속도, 토큰 사용량, 그리고 환각(Hallucination) 지표를 실시간 모니터링하고, Ragas나 G-Eval과 같은 프레임워크로 정기적으로 성능을 평가합니다.
|
||||
* **Data Drift 감지:** 사용자 입력 데이터의 분포 변화를 감지하여 모델 재학습이나 프롬프트 조정 시점을 결정합니다.
|
||||
* **Local Deployment:** Ollama, LM Studio 등을 활용하여 로컬 환경(Mac M 시리즈, Mini PC 등)에서 프라이버시를 보호하며 LLM을 구동합니다.
|
||||
|
||||
---
|
||||
|
||||
## ⚖️ 트레이드오프 및 주의사항 (Trade-offs)
|
||||
* **정밀도 vs 속도:** 양자화 비트 수가 낮아질수록 속도는 빨라지지만, 복잡한 추론이나 수학적 문제에서 성능 저하(Perplexity 증가)가 발생할 수 있습니다.
|
||||
* **지연 시간(Latency) vs 처리량(Throughput):** 단일 사용자의 빠른 응답을 위한 최적화와 동시에 수많은 사용자를 처리하기 위한 최적화 전략은 다를 수 있습니다.
|
||||
* **비용 vs 성능:** 고성능 GPU 클러스터 배포와 로컬/엣지 배포 간의 비용 대비 지능 수준을 프로젝트 목적에 맞게 선택해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[Transformer_Architecture_and_LLM_Foundations]], [[데이터 사이언스 및 ML 엔지니어링|Neural_Networks_and_Deep_Learning_Foundations]], [[LLM_Ops_and_Tuning]]
|
||||
- **Redirects:** [[LLM_Optimization_and_Deployment_Strategies|Quantization]], [[PEFT]], [[LLM_Optimization_and_Deployment_Strategies|vLLM]], [[Model Compression]], [[Ollama]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
id: wiki-2026-0508-microservices-architecture
|
||||
title: Microservices Architecture
|
||||
category: Architecture
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [microservices_architecture]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [- msa - microservices - software-architecture - ddd - distributed-systems - fault-isolation]
|
||||
raw_sources: [- AI_and_ML/Microservices Architecture (MSA).md - AI_and_ML/Microservices Architecture Pattern.md - AI/Microservices-Architecture.md - AI/마이크로서비스 아키텍처 (Microservices Architecture).md - Architecture/Monolithic-vs-Microservices.md]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 마이크로서비스 아키텍처 (Microservices Architecture)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
마이크로서비스 아키텍처(MSA)는 대규모 애플리케이션을 비즈니스 도메인(Domain)을 중심으로 독립적으로 배포 및 실행 가능한 작은 서비스들의 집합으로 설계하는 소프트웨어 개발 접근 방식입니다 [1]. 각 서비스는 고유의 프로세스를 실행하며 API와 같은 경량화된 통신 메커니즘을 통해 상호작용합니다 [3]. 이를 통해 조직은 시스템의 유연성, 확장성, 복원력을 확보하고 개발 및 배포 속도를 극대화할 수 있습니다 [4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
### 1. 핵심 특징 (Core Characteristics)
|
||||
* **자율성 및 독립성 (Autonomy & Isolation)**: 각 서비스는 독립적인 코드베이스, CI/CD 파이프라인, 그리고 개별 데이터베이스를 보유하는 'Database per Service' 패턴을 따릅니다 [6, 10].
|
||||
* **단일 책임 원칙 (Single Responsibility)**: 각 서비스는 오직 하나의 비즈니스 기능에만 집중하며, 도메인 주도 설계(DDD) 원칙에 따라 경계가 정의됩니다 [12].
|
||||
* **기술적 이질성 (Technology Heterogeneity)**: 서비스별 특성에 맞춰 최적의 언어, 프레임워크, 데이터베이스(폴리글랏 프로그래밍)를 자율적으로 선택할 수 있습니다 [4, 9].
|
||||
* **장애 격리 (Fault Isolation)**: 한 서비스의 장애가 전체 시스템으로 전파되는 'Blast Radius'를 최소화하여 시스템 복원력을 높입니다 [9, 12].
|
||||
|
||||
### 2. 주요 아키텍처 패턴 (Key Patterns)
|
||||
* **통신 메커니즘**: 주로 HTTP/REST API나 메시지 큐(Kafka, RabbitMQ)를 통한 비동기 이벤트 전달 방식을 사용합니다 [13, 14].
|
||||
* **데이터 일관성 관리**: 분산 환경에서의 ACID 트랜잭션 한계를 극복하기 위해 **Saga 패턴**, **API 컴포지션(API Composition)**, **CQRS 패턴**을 활용하여 최종 일관성(Eventual Consistency)을 구현합니다 [24, 25].
|
||||
* **복원력 설계**: 서비스 간 연쇄 장애를 방지하기 위해 **서킷 브레이커(Circuit Breaker)**, 재시도(Retry), 타임아웃(Timeout) 패턴을 적용합니다 [18].
|
||||
* **인프라 추상화**: 수많은 서비스의 위치 투명성을 위해 **서비스 메시(Service Mesh)**나 **API Gateway**를 도입하여 인증, 라우팅, 로드 밸런싱을 중앙 제어합니다 [15, 26].
|
||||
|
||||
### 3. 도입 시 고려 사항 (Pros & Cons)
|
||||
* **장점**: 개발 주력 단축, 독립적 확장 가능, 기술 부채 관리 용이 [11, 16].
|
||||
* **단점**: 분산 시스템의 본질적 복잡성, 데이터 무결성 보장의 어려움, 인프라 및 운영 비용 증가 [18, 21].
|
||||
* **필수 요건**: 고도로 자동화된 CI/CD, 분산 로그 수집 체계, 상관관계 ID(Correlation ID) 기반의 **분산 트레이싱** 모니터링 환경이 뒷받침되어야 합니다 [36, 38].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **결합 분리의 오류**: 물리적으로 서비스를 나누더라도 공유 데이터 모델이나 횡단 관심사에 얽혀 있으면 진정한 독립성을 확보할 수 없습니다. 서비스 내부의 아키텍처 경계와 의존성 규칙 설계가 선행되어야 합니다 [21-24].
|
||||
* **운영 오버헤드**: 서비스 수가 늘어날수록 관리 지점이 기하급수적으로 증가하므로, 조직의 성숙도와 시스템 복잡성을 고려한 'Sweet Spot'을 찾아야 합니다 [52].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics**: [[Cloud_Native]], [[Service Mesh]]
|
||||
- **Projects/Contexts**: 넷플릭스 코스모스 플랫폼, 스포티파이 스쿼드 모델
|
||||
- **Next Steps**: 모듈형 모놀리스(Modular Monolith)와의 비용 편익 분석, Saga 패턴의 구체적 구현 사례 연구.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+126
@@ -0,0 +1,126 @@
|
||||
---
|
||||
id: wiki-2026-0508-nodejs-and-backend-optimization
|
||||
title: Nodejs and Backend Optimization
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-CANONICAL-NODEJS-BACKEND]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [canonical, nodejs, backend, performance, v8, memory-leak]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Nodejs_and_Backend_Optimization|Node.js & Backend Optimization]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "메모리는 유실되는 것이 아니라 붙잡혀 있는 것이다." Node.js의 고성능 백엔드 구축은 V8 엔진의 세대별 가비지 컬렉션(GC) 메커니즘을 이해하고, 클로저·이벤트 리스너·캐시 등에서 발생하는 '래칫(Ratchet)' 패턴의 메모리 누수를 힙 스냅샷과 할당 타임라인으로 정밀 타격하여 제거하는 과정입니다.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
### 1. V8 메모리 구조 및 가비지 컬렉션 (GC)
|
||||
* **세대별 가설 (Generational Hypothesis):** "대부분의 객체는 일찍 죽는다." V8은 이를 기반으로 힙(Heap)을 **New Space(Young Generation)**와 **Old Space(Old Generation)**로 분리 관리합니다.
|
||||
* **Minor GC (Scavenger):** New Space에서 짧은 수명의 객체를 매우 빠르게 정리합니다. 여러 번 살아남은 객체는 Old Space로 **승격(Promotion)**됩니다.
|
||||
* **Major GC (Mark-Sweep-Compact):** Old Space의 장기 객체를 정리합니다. 실행 비용이 크며, 메모리 파편화를 줄이기 위해 압축(Compaction)을 수행합니다.
|
||||
* **Orinoco GC:** 메인 스레드 중단(Stop-the-world)을 최소화하기 위해 병렬(Parallel), 점진적(Incremental), 동시(Concurrent) 기법을 결합하여 백그라운드에서 메모리를 회수합니다.
|
||||
|
||||
### 2. 메모리 누수 패턴 (The "Ratchet" Effect)
|
||||
정상적인 시스템은 트래픽에 따라 힙이 증가했다가 GC 후 복구되는 '톱니바퀴(Sawtooth)' 패턴을 보이지만, 누수가 있으면 하한선이 계속 상승하는 '계단식(Ratchet)' 패턴이 나타납니다.
|
||||
* **이벤트 리스너 누적:** `on()` 호출 후 `removeListener()`를 누락하여 `MaxListenersExceededWarning`이 발생하는 경우 (가장 흔한 패턴).
|
||||
* **클로저 변수 유지:** 비동기 콜백이나 타이머가 대규모 데이터(요청/응답 객체 등)를 캡처한 채 종료되지 않는 경우.
|
||||
* **무제한 캐시 증식:** LRU 등 크기 제한이 없는 인메모리 캐시 변수에 데이터가 무한정 쌓이는 경우.
|
||||
* **정리되지 않은 타이머/소켓:** `clearInterval`되지 않은 타이머나 `.destroy()`되지 않은 스트림/소켓이 버퍼를 점유하는 경우.
|
||||
|
||||
### 3. 진단 도구 및 워크플로우
|
||||
* **Chrome DevTools & `--inspect`:** 실시간 메모리 프로파일링 및 힙 스냅샷 분석의 표준.
|
||||
* **힙 스냅샷 (Heap Snapshot):** 특정 시점의 메모리 상태를 캡처. **3-스냅샷 기법(Three-snapshot technique)**을 통해 일회성 할당을 걸러내고 지속적인 누수 후보를 특정합니다.
|
||||
* **할당 타임라인 (Allocation Timeline):** 시간에 따른 할당을 시각화. GC 후에도 파란색 막대로 남은 객체가 누수 지점입니다.
|
||||
* **유지 경로 (Retaining Path):** 특정 객체가 왜 해제되지 않는지 GC 루트까지의 참조 체인을 추적합니다.
|
||||
* **명령줄 플래그:**
|
||||
* `--max-old-space-size`: OOM 방지를 위한 힙 크기 확장.
|
||||
* `--trace-gc`: GC 발생 빈도 및 소요 시간 로그 확인.
|
||||
* `--heap-prof`: 외부 패키지 없이 V8 네이티브 프로파일링 수행.
|
||||
|
||||
### 4. 백엔드 최적화 전략
|
||||
* **싱글 스레드 보호:** CPU 집약적 작업은 Worker Threads로 분리하여 이벤트 루프 블로킹 방지.
|
||||
* **스트림 활용:** 대용량 파일/데이터 처리 시 전체를 메모리에 올리지 않고 Buffer 단위로 처리.
|
||||
* **가시성 (Observability):** `prom-client` 등을 활용해 RSS, heapUsed 메트릭을 Prometheus/Grafana로 모니터링하고 임계치 알람 설정.
|
||||
|
||||
---
|
||||
|
||||
## ⚖️ 트레이드오프 및 주의사항 (Trade-offs)
|
||||
* **수동 GC의 위험성:** `--expose-gc`를 통한 `global.gc()` 호출은 특수한 배치 작업 외에는 권장되지 않으며, V8의 최적화된 자동 GC 메커니즘을 방해할 수 있습니다.
|
||||
* **포인터 압축 (Pointer Compression):** 64비트 시스템에서도 V8 힙을 4GB로 제한하는 구조적 한계가 있어, 대규모 데이터를 다룰 때 주의가 필요합니다.
|
||||
* **조급한 최적화 금지:** 초기 단계에서의 과도한 메모리 튜닝보다는 정확한 누수 지점 파악이 선행되어야 합니다.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[Cloud_Native|Cloud_Native_and_Microservices]], [[Modern_Web_Rendering_and_Optimization]], [[Performance_Profiling_and_Memory]]
|
||||
- **Redirects:** [[Nodejs_and_Backend_Optimization|Nodejs]], [[Allocation Timeline|Allocation_Timeline]], [[Heap Snapshot]], [[Nodejs_and_Backend_Optimization|Retaining_Path]], [[Nodejs_and_Backend_Optimization|clinicjs]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
id: wiki-2026-0508-pev-loop
|
||||
title: PEV Loop
|
||||
category: 10_Wiki/Topics/AI
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [e6f7a8b9-c0d1-4e2f-3a4b-5c6d7e8f9a0b]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.99
|
||||
tags: [pev-loop, execution, verification, agent, harness, reliability]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: wikification-pev-loop
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Plan-Execute-Verify (PEV) Loop]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> PEV 루프는 에이전트가 즉흥적으로 행동하는 것을 방지하기 위해 계획, 제한된 실행, 엄격한 검증의 3단계를 강제하여 자율 시스템의 신뢰성과 아키텍처 일관성을 보장하는 핵심 실행 패턴이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
### 1. 3단계 실행 파이프라인
|
||||
- **Plan (계획)**: 문제를 명시적으로 분해하고 수용 기준(Acceptance Criteria)을 포함한 상세 계획을 수립한다. 이는 추론의 비결정성 문제를 줄이는 역할을 한다.
|
||||
- **Execute (실행)**: 수립된 계획의 범위 내에서만 도구를 호출한다. 실행 전 게이트(Pre-execution gates)가 개입하여 인자 유효성 및 권한을 실시간으로 통제한다.
|
||||
- **Verify (검증)**: 단순 성공 여부를 넘어 계획과의 일치성(Plan Alignment)을 평가한다. 실패 시 구체적인 에러 피드백을 추론 루프로 돌려보내 자가 수정을 유도한다.
|
||||
|
||||
### 2. 하네스 게이트 (Harness Gates)
|
||||
- **Pre-execution gates**: 도구 호출 전 작업 공간 및 권한을 확인하여 범위를 벗어난 행동을 원천 차단한다.
|
||||
- **Post-execution verification**: 린터, 테스트 러너, 아키텍처 규칙 검사 등을 통해 결과물의 품질을 보증한다.
|
||||
|
||||
### 3. 신뢰성 중심 설계
|
||||
- '일단 해보고 확인하기(Generate-and-Check)' 방식의 한계를 극복하고, 하네스 계층에서 결정론적 규칙을 강제함으로써 엔터프라이즈 급의 안정성을 확보한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **지연 시간 오버헤드**: 단계를 강제함에 따라 간단한 작업에서도 처리 시간이 증가하며 토큰 소모량이 늘어난다.
|
||||
- **검증 로직의 복잡성**: 단순히 코드가 실행되는지를 넘어 아키텍처 규칙 준수 여부를 판단하는 '계획 일치성' 검증 로직 구현에 높은 기술적 난이도가 따른다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/AI]]
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Plan-Execute-Verify (PEV) Loop Architecture"`
|
||||
3. Push: `git push origin main`
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+114
@@ -0,0 +1,114 @@
|
||||
---
|
||||
id: wiki-2026-0508-040
|
||||
title: Performance Profiling and Memory
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0508-040, Performance, Profiling, Memory Management, V8 Engine, Garbage Collection, GC, Memory Leak, Node.js Performance, 성능 최적화, 메모리 관리, 가비지 컬렉션]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [Performance, Memory, V8, Profiling, Node.js, Diagnostics]
|
||||
raw_sources: [직접 입력, DevOps_and_Security/V8 관련 문서군, AI/Memory 관련 문서군]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 성능_프로파일링_및_메모리_관리_표준
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "보이지 않는 메모리의 실체를 추적하라." 가비지 컬렉션(GC)의 메커니즘을 이해하고, 크롬 개발자 도구와 힙 스냅샷을 통해 누수 지점(Retaining Path)을 정확히 짚어내는 것이 고성능 애플리케이션의 핵심이다.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> V8 엔진의 세대별 가비지 컬렉션(Generational GC) 전략을 활용하여 객체 생명주기를 관리하고, 런타임 프로파일링을 통해 병목 지점을 데이터 기반으로 식별하여 시스템 처리량을 극대화한다.
|
||||
|
||||
**세부 내용:**
|
||||
- **V8 메모리 아키텍처:**
|
||||
- **New Space (Young Gen):** Scavenge 알고리즘 기반. 생존율이 낮은 짧은 수명 객체 처리.
|
||||
- **Old Space (Old Gen):** Mark-Sweep-Compact 알고리즘 기반. 수명이 긴 객체 및 대형 객체 관리.
|
||||
- **V8 Memory Cage:** 포인터 압축 기술을 통해 64비트 환경에서도 메모리 효율성 증대.
|
||||
- **가비지 컬렉션 (GC) 최적화:**
|
||||
- **Orinoco 프로젝트:** 병렬(Parallel), 점진적(Incremental), 동시성(Concurrent) 마킹을 통해 Stop-the-world 지연 최소화.
|
||||
- **Oilpan:** C++ 객체 관리용 GC 엔진과 V8의 협력적 메모리 관리.
|
||||
- **성능 병목 및 누수 패턴:**
|
||||
- **CPU Bottleneck:** 과도한 루프, 동기식 I/O, 복잡한 정규 표현식.
|
||||
- **Memory Leak:** 해제되지 않은 이벤트 리스너, 클로저에 의한 의도치 않은 참조 유지, 무제한 캐시 증식.
|
||||
- **Sawtooth vs Ratchet:** 건강한 시스템은 톱니형 패턴을 보이나, 누수 시에는 할당량이 우상향하는 라쳇 패턴 관찰.
|
||||
- **진단 및 프로파일링 기법:**
|
||||
- **Chrome DevTools:** Allocation Timeline(누수 지점), Heap Snapshot(객체 분포), Flame Graphs(함수 실행 시간).
|
||||
- **Retaining Path 분석:** GC Root로부터 객체까지의 참조 사슬을 추적하여 객체가 메모리에 남은 근본 원인 식별.
|
||||
- **Runtime Metrics:** Node.js의 `--trace-gc`, `--inspect`, `clinic.js` 등을 활용한 지표 수집.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 원인 불명의 프로세스 Crash(OOM: Out of Memory)가 발생하거나 응답 지연이 심화될 때.
|
||||
- 렌더링 성능이 저하되어 사용자가 '끊김'을 느낄 때 (Blink, Render-tree 분석).
|
||||
- 대규모 트래픽 처리를 위한 인프라 사이징(Heap Size 설정 등)이 필요할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 성능 최적화가 비즈니스 가치보다 비용이 큰 극초기 프로토타입 단계 (조기 최적화 주의).
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **Heisenbug:** 프로파일링 도구 자체가 시스템 부하를 일으켜(Stop-the-world) 현상을 왜곡할 수 있음.
|
||||
- **수동 GC:** `global.gc()` 호출은 V8의 정교한 스케줄링을 방해하므로 특수한 테스트 환경 외에는 금지.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics**: [[Web_Performance_Optimization]], [[CI_CD_Pipeline|CI_CD Pipeline]]
|
||||
- **Next Step**: 대규모 트래픽 환경에서의 메모리 덤프 자동화 및 임계치 기반 알람 시스템 구축.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
id: wiki-2026-0508-runtime-validation
|
||||
title: Runtime Validation
|
||||
category: Programming
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [runtime_validation]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [- typescript - validation - zod - type_safety - parsing]
|
||||
raw_sources: ["- E:/Wiki/2nd/10_Wiki/Topics/Frontend/런타임 상태 검증(Runtime Validation).md - E:/Wiki/2nd/10_Wiki/Topics/런타임 유효성 검사 (Runtime Validation).md - E:/Wiki/2nd/10_Wiki/Topics/Programming & Language/Zod 런타임 유효성 검사 통합.md"]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 런타임 유효성 검사 (Runtime Validation)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "컴파일 타임의 타입 안전성과 런타임의 데이터 무결성 사이의 간극을 메우기 위해, 시스템 경계(Boundary)에서 데이터를 검증하는 대신 신뢰할 수 있는 타입으로 파싱하는 설계 기법."
|
||||
|
||||
## 📖 핵심 개념 (Core Concept)
|
||||
|
||||
### 1. 런타임 검증의 필요성
|
||||
TypeScript의 정적 타입 시스템은 컴파일 시점에만 존재하며, 런타임에는 소거(Erasure)됩니다. 따라서 API 응답, 설정 파일, 사용자 입력 등 외부에서 유입되는 데이터는 TypeScript가 그 구조를 보장할 수 없습니다. 런타임 유효성 검사는 이러한 **타입 불일치로 인한 런타임 에러를 방지**하기 위해 필수적입니다 [1, 2, 5].
|
||||
|
||||
### 2. "검증하지 말고 파싱하라 (Parse, Don't Validate)"
|
||||
단순히 데이터가 유효한지 체크(Boolean 반환)하는 것에 그치지 않고, 시스템의 진입점에서 데이터를 검증한 후 **완벽하게 타이핑된 결과물로 변환**하는 철학입니다 [3, 6].
|
||||
* **시스템 경계(Boundary) 보호**: 외부 데이터가 내부 로직으로 침투하기 전에 단 한 번의 파싱을 거쳐 안전성을 확보합니다 [3, 7].
|
||||
* **유효하지 않은 상태의 표현 불가**: 파싱을 통과했다는 것은 해당 데이터가 비즈니스 규칙을 충족함을 의미하며, 이후 로직에서는 추가적인 체크가 불필요해집니다 [3].
|
||||
|
||||
### 3. Zod 라이브러리와의 통합
|
||||
Zod는 TypeScript 우선(TypeScript-first) 스키마 선언 및 검증 라이브러리로, 런타임 유효성 검사의 사실상 표준(de facto standard)입니다 [1, 8].
|
||||
* **Safe Parsing**: `.safeParse()` 메서드를 통해 예외(Exception)를 던지는 대신 성공/실패 여부가 담긴 결과 객체를 반환하여 흐름 제어를 예측 가능하게 합니다 [4, 6, 9].
|
||||
* **Branded Types 연동**: `.brand()` 메서드를 사용하여 검증을 통과한 데이터에 고유한 표식(Brand)을 부여함으로써 컴파일러 수준에서도 의미적으로 다른 데이터를 구분할 수 있게 합니다 [4, 6].
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항 (Trade-offs)
|
||||
* **성능 비용 (Runtime Cost)**: 정적 타입 검사와 달리 실제 실행 시 코드가 동작하므로 오버헤드가 발생합니다. 성능이 매우 중요한 루프 내부 등에서는 신중한 사용이 필요합니다 [2].
|
||||
* **유연성 vs 엄격함**: 너무 엄격한 스키마 정의는 외부 API의 미세한 변경에도 시스템을 중단시킬 수 있으므로, 하위 호환성을 고려한 유연한 설계가 병행되어야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Concepts**: [[Parse, don't validate]], [[Branded Types]], [[Discriminated_Unions|Discriminated Unions]]
|
||||
- **Tools**: [[Zod]], Joi, Yup, Valibot
|
||||
- **Contexts**: API 응답 파싱, 설정 파일(Config) 검증, Form 데이터 유효성 체크
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+100
@@ -0,0 +1,100 @@
|
||||
---
|
||||
id: system-resilience-and-fault-tolerance
|
||||
title: System Resilience and Fault Tolerance
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [결함 허용 시스템, 회복 탄력성 아키텍처, Resilience Patterns]
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
created_at: 2026-05-11
|
||||
updated_at: 2026-05-11
|
||||
last_reinforced: 2026-05-11
|
||||
verification_status: applied
|
||||
applied_in:
|
||||
- path: /Volumes/Data/project/Antigravity/Datacollector_MAC/src/lib/engine.ts
|
||||
note: Exponential Backoff 및 Backend Restart 로직 적용
|
||||
- path: /Volumes/Data/project/Antigravity/Datacollector_MAC/src/lib/diagnostics.ts
|
||||
note: Circuit Breaker 패턴 적용
|
||||
tags: [architecture, reliability, engineering]
|
||||
---
|
||||
|
||||
# [[System Resilience and Fault Tolerance]]
|
||||
|
||||
> [!TIP]
|
||||
> 시스템 회복 탄력성은 단순히 에러가 나지 않는 것이 아니라, **에러가 발생했을 때 어떻게 우아하게 복구(Graceful Recovery)하느냐**의 문제입니다.
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> 분산 시스템과 외부 API 의존도가 높은 현대 소프트웨어에서 안정성은 '완벽한 차단'이 아닌, 지수 백오프(Backoff)와 서킷 브레이커(Circuit Breaker)를 통한 **격리된 실패 제어**와 **자동화된 자가 치유(Self-healing)** 능력에 의해 결정된다.
|
||||
|
||||
## 📖 핵심 개념 (Synthesized Content)
|
||||
|
||||
### 1. 지수 백오프 (Exponential Backoff)
|
||||
실패한 요청을 즉시 재시도하는 대신, 재시도 간격을 지수적으로 늘려나가는 전략입니다. 이는 네트워크 부하를 방지하고 일시적인 장애(Transient Failure)가 해소될 시간을 벌어줍니다.
|
||||
|
||||
### 2. 서킷 브레이커 (Circuit Breaker)
|
||||
외부 서비스 장애가 시스템 전체로 전파되는 것을 막기 위해, 특정 임계값 이상의 실패가 발생하면 요청을 즉시 차단(OPEN)하는 패턴입니다. 일정 시간 후 시범 요청(HALF_OPEN)을 통해 복구 여부를 확인합니다.
|
||||
|
||||
### 3. 격리된 자동 재시작 (Orchestrated Restart)
|
||||
애플리케이션 계층에서 해결되지 않는 하부 서비스(백엔드 브릿지 등)의 장애를 감지했을 때, 격리된 방식으로 해당 서비스를 리셋하고 세션을 복구하는 최후의 복구 수단입니다.
|
||||
|
||||
## 💻 코드 패턴 (Implementation Patterns)
|
||||
|
||||
### Circuit Breaker 상태 관리
|
||||
```typescript
|
||||
let circuit = {
|
||||
status: 'CLOSED', // CLOSED, OPEN, HALF_OPEN
|
||||
failureCount: 0,
|
||||
lastFailureTime: Date.now()
|
||||
};
|
||||
|
||||
function updateCircuit(isSuccess: boolean) {
|
||||
if (isSuccess) {
|
||||
circuit.status = 'CLOSED';
|
||||
circuit.failureCount = 0;
|
||||
} else {
|
||||
circuit.failureCount++;
|
||||
if (circuit.failureCount >= 3) circuit.status = 'OPEN';
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 지수 백오프 기반 재시도
|
||||
```typescript
|
||||
const delays = [5000, 15000, 45000]; // 5초, 15초, 45초
|
||||
const retryDelay = delays[consecutiveErrors - 1];
|
||||
setTimeout(() => processNext(), retryDelay);
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준
|
||||
|
||||
| 상황 | 권장 접근법 |
|
||||
|---|---|
|
||||
| 일시적 네트워크 타임아웃 | 3단계 내외의 지수 백오프 재시도 |
|
||||
| 인증 만료 및 세션 오류 | 즉시 자동 복구(Re-auth) 시도 후 실패 시 일시정지 |
|
||||
| 외부 서비스 연속 실패 | 서킷 브레이커 OPEN 하여 리소스 소모 차단 |
|
||||
| 백엔드 프로세스 응답 없음 | 프로세스 격리 재시작(Bridge Restart) 오케스트레이션 |
|
||||
|
||||
## ❌ 안티패턴
|
||||
|
||||
- **무한 재시도 (Infinite Retry Loop)**: 종료 조건 없는 재시도는 서버 리소스를 고갈시키고 로그 폭증을 유발합니다.
|
||||
- **Immediate Retry**: 실패 즉시 재시도하는 것은 'Self-DDOS' 행위이며, 장애 상황을 악화시킵니다.
|
||||
- **이중 카운팅 (Double Counting Errors)**: 서킷 브레이커와 엔진의 백오프 카운터가 독립적으로 소진되어, 실제 재시도 기회를 낭비하는 것을 경계해야 합니다.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **상태:** verified
|
||||
- **출처 신뢰도:** A (Datacollector_MAC 실구현체 기반)
|
||||
- **적용 사례:** `Datacollector_MAC` 프로젝트의 `engine.ts`와 `diagnostics.ts`에서 검증됨.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[Software_Architecture_Patterns]]
|
||||
- **Related:** [[Runtime_Validation]], [[Autonomous_Queue_Processing_Engine]]
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-11 | Datacollector_MAC 엔진 리뷰를 기반으로 최초 생성 | CREATE | A |
|
||||
+117
@@ -0,0 +1,117 @@
|
||||
---
|
||||
id: wiki-2026-0508-transformer-architecture-and-llm
|
||||
title: Transformer Architecture and LLM Foundations
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-CANONICAL-TRANSFORMER-LLM]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [canonical, transformer, llm, attention, bert, gpt]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Transformer_Architecture_and_LLM_Foundations|Transformer Architecture & LLM Foundations]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터 간의 모든 관계를 병렬로 파악하여 시퀀스의 한계를 돌파하라." 트랜스포머는 순차적 처리를 버리고 셀프 어텐션(Self-Attention) 메커니즘을 통해 데이터의 맥락을 전역적으로 파악하며, 현대 대규모 언어 모델(LLM)의 폭발적인 성능 향상을 이끈 표준 아키텍처입니다.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
### 1. 트랜스포머의 핵심: 어텐션 메커니즘 (Attention Mechanism)
|
||||
* **Self-Attention:** 입력 문장의 각 단어가 문맥 내 다른 모든 단어들과 어떤 관계를 맺고 있는지 점수를 매깁니다. 특정 단어를 이해하기 위해 어떤 단어에 '주의(Attention)'를 기울여야 하는지 계산합니다.
|
||||
* **Multi-Head Attention:** 여러 개의 어텐션 루프를 병렬로 실행하여, 단어 간의 다양한 의미적(문법, 의미, 대용어 등) 관계를 동시에 포착합니다.
|
||||
* **Query, Key, Value (Q, K, V):** 정보를 찾으려는 주체(Q), 정보의 인덱스(K), 실제 정보 값(V)으로 데이터를 벡터화하여 관계를 연산합니다.
|
||||
|
||||
### 2. 아키텍처 구성 요소
|
||||
* **Positional Encoding:** 트랜스포머는 데이터를 한꺼번에 입력받으므로 순서 정보가 없습니다. 이를 해결하기 위해 단어 벡터에 위치 정보(Sine/Cosine 함수 등)를 더해 순서 감각을 부여합니다.
|
||||
* **Feed-Forward Network (FFN):** 어텐션 층 이후에 각 위치에서 독립적으로 적용되는 신경망으로, 비선형성을 추가하고 정보를 정제합니다.
|
||||
* **Layer Normalization & Residual Connections:** 학습을 안정화하고 깊은 층에서도 기울기 소실 문제 없이 정보가 잘 전달되도록 돕습니다.
|
||||
|
||||
### 3. LLM의 발전과 파이프라인
|
||||
* **Encoder-Only (BERT):** 문장의 양방향 맥락을 이해하는 데 특화. 분류, 개체명 인식 등에 사용됩니다.
|
||||
* **Decoder-Only (GPT):** 이전 단어들을 바탕으로 다음 단어를 예측하는 데 특화. 텍스트 생성의 표준입니다.
|
||||
* **Encoder-Decoder (T5, BART):** 번역이나 요약처럼 입력을 받아 다른 형태의 출력을 만드는 작업에 사용됩니다.
|
||||
|
||||
### 4. 최신 최적화 기법
|
||||
* **Flash Attention:** 메모리 접근 패턴을 최적화하여 어텐션 연산 속도를 비약적으로 높이고 메모리 사용량을 줄입니다.
|
||||
* **KV Cache:** 생성 작업 시 이전 단계의 Key/Value 벡터를 재사용하여 추론 속도를 가속화합니다.
|
||||
* **MoE (Mixture of Experts):** 모델 전체를 활성화하는 대신 데이터에 맞는 일부 전문가 네트워크만 활성화하여 효율성을 극대화합니다.
|
||||
|
||||
---
|
||||
|
||||
## ⚖️ 트레이드오프 및 주의사항 (Trade-offs)
|
||||
* **연산 복잡도:** 어텐션은 문장 길이의 제곱($N^2$)에 비례하는 연산량을 가집니다. 이를 해결하기 위해 Sparse Attention이나 Ring Attention 등의 기법이 연구되고 있습니다.
|
||||
* **데이터 의존성:** 트랜스포머는 언어의 규칙을 스스로 학습해야 하므로, 충분한 성능을 내기 위해 방대한 양의 학습 데이터가 필요합니다.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[데이터 사이언스 및 ML 엔지니어링|Neural_Networks_and_Deep_Learning_Foundations]], [[데이터 사이언스 및 ML 엔지니어링|Reinforcement_Learning_and_Decision_Making]]
|
||||
- **Redirects:** [[Transformer]], [[Attention Mechanism]], [[Transformer_Architecture_and_LLM_Foundations|BERT]], [[GPT]], [[Transformer_Architecture_and_LLM_Foundations|LLM_Fundamentals]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,131 @@
|
||||
---
|
||||
id: wiki-2026-0508-wearables-api-iot-devices
|
||||
title: Wearables API IoT Devices
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [mission_14d797993957]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [automated, datacollector, brain_sync]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Wearables API IoT Devices]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Wearables API 및 IoT 기기는 스마트 링, 연속 혈당 측정기(CGM), 무선 이어버드 등 다양한 건강 및 피트니스 트래커에서 발생하는 생체 데이터를 단일 플랫폼으로 통합하는 기술입니다 [1, 2]. 최근 이 기술은 기기 내장형 AI(온디바이스 AI) 및 대형 언어 모델과 결합하여, 단순한 수동적 데이터 기록을 넘어 증상이 나타나기 전에 질병을 예측하고 실시간으로 행동 지침을 제공하는 '선제적 제안(Proactive Suggestion)' 기능으로 진화하고 있습니다 [3-8].
|
||||
|
||||
## 📖 Core 사Content
|
||||
- **수동적 추적에서 선제적 건강 인텔리전스로의 전환**: 웨어러블 기기의 역할은 단순히 수면 부족이나 심박수 변이를 알려주는 것에서, 데이터를 기반으로 "오늘 강도 높은 운동을 건너뛰고 회복에 집중하라"고 지시하거나 증상을 느끼기 전에 질병 발생을 예측하는 능동적인 코치 역할로 변화하고 있습니다 [9-12]. AI 모델은 패턴을 분석해 저혈당 쇼크, 임신 합병증, 스트레스 수준 등을 선제적으로 경고합니다 [5, 6, 13].
|
||||
- **엣지 컴퓨팅(Edge Computing)과 온디바이스 AI**: 데이터를 클라우드로 보내는 대신 기기 자체에서 실시간으로 분석하는 온디바이스 AI가 웨어러블에 도입되고 있습니다 [4, 5]. 이는 지연 시간을 줄이고 에너지 소비를 최소화하며, 비정상적인 심장 리듬이나 스트레스 징후를 감지하여 즉각적인 개입(Intervention)을 제안할 수 있게 합니다 [5].
|
||||
- **통합 건강 데이터 API (Unified Health Data APIs)**: 수백 개의 각기 다른 웨어러블 및 IoT 기기를 통합하는 API(예: Spike Wearables API)는 개발자가 개별 기기마다 별도의 연결을 구축할 필요 없이 단일 파이프라인을 통해 데이터를 수집하게 해줍니다 [1, 2]. 이를 통해 앱은 수면, 영양, 생리 주기 등 다각적인 데이터를 종합할 수 있습니다 [2, 8].
|
||||
- **LLM과 MCP(Model Context Protocol)를 통한 맞춤형 코칭**: 수집된 원시 생체 데이터는 MCP를 통해 대형 언어 모델과 안전하게 연결될 수 있습니다 [8]. 이를 통해 앱은 단순한 알림을 넘어, 사용자의 고유한 생리적 특성, 식단, 수면 패턴을 맥락화하여 스트레스 관리나 식단 조절 같은 고도로 개인화된 건강 제안을 선제적으로 제공합니다 [8].
|
||||
- **임상 등급(Clinical-Grade) 센서의 도입**: 스마트 링과 연속 혈당 측정기(CGM) 등의 기기들이 연구실 수준에 가까운 정확도(예: 99% 정확도의 온도 센서)를 확보하면서, 웰니스 기기와 의료 진단 기기 사이의 경계가 허물어지고 있으며, 이는 선제적 제안의 임상적 신뢰도를 높이고 있습니다 [14-16].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **개인정보 보호와 클라우드 처리 간의 딜레마**: 온디바이스 AI는 데이터를 로컬에 유지하여 프라이버시를 보호하지만, 가장 강력하고 복잡한 예측 모델을 실행하기 위해서는 여전히 클라우드 서버의 처리 능력이 필요합니다 [17]. 특히 여성 건강(FemTech)과 같이 극도로 민감한 생체 데이터를 다룰 때는 클라우드 전송에 대한 사용자의 우려가 크며, HIPAA 및 GDPR과 같은 엄격한 보안 규정 준수와 엔드투엔드 암호화가 필수적으로 요구됩니다 [1, 11, 18].
|
||||
- **의학적 오남용 및 규제 위험**: 웨어러블 기기가 임상 등급에 가까워지고 있으나, 여전히 대다수는 의료 기기가 아닙니다. 예를 들어, FDA는 스마트워치나 스마트 링을 이용해 비침습적으로 혈당을 측정하여 의학적 결정을 내리는 것은 승인되지 않았으며, 심각한 부상이나 사망을 초래할 수 있다고 명시적으로 경고합니다 [19]. 선제적 제안이 자칫 검증되지 않은 의료 진단으로 오인될 위험이 존재합니다 [19, 20].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [데이터 수집 및 통합 인프라]
|
||||
- [[Wearables API]]
|
||||
- 연결 이유: 수십, 수백 종의 IoT 기기 및 피트니스 트래커에서 수집되는 원시 데이터를 단일 파이프라인으로 표준화하여 제공함으로써, 선제적 제안을 생성하는 AI의 필수적인 데이터 기반을 형성합니다 [1, 2].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 파편화된 생체 데이터를 연결하여 사용자의 전체적인 건강 타임라인을 구성하는 통합 아키텍처 방법론 [2, 8, 21].
|
||||
|
||||
#### [분석 및 지능형 코칭 기술]
|
||||
- [[Edge Computing (온디바이스 AI)]]
|
||||
- 연결 이유: 데이터를 클라우드로 전송하지 않고 기기 내부에서 실시간으로 머신러닝 모델을 구동하여, 지연 없이 즉각적인 위험 경고나 선제적 조치를 제안합니다 [5].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 실시간 데이터 분석 아키텍처가 어떻게 프라이버시 침해 우려를 줄이면서도 신속한 사용자 개입을 가능하게 하는지 [5, 17].
|
||||
- [[Model Context Protocol (MCP)]]
|
||||
- 연결 이유: API로 수집된 사용자의 방대한 생체 및 활동 데이터를 대형 언어 모델(LLM)에 맥락적(Contextual)으로 연결하여, 단순 통계가 아닌 종합적이고 개인화된 AI 챗봇의 건강 코칭을 가능하게 합니다 [1, 8].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 웨어러블의 정량적 데이터가 어떻게 실질적이고 선제적인 언어 기반 건강 제안으로 변환되는지에 대한 시스템적 연결 고리 [8].
|
||||
|
||||
### Deeper Research Questions
|
||||
- 단일 Wearables API를 통해 이기종 IoT 기기들의 데이터를 통합할 때 발생하는 데이터 표준화 및 포맷 불일치 문제를 어떻게 기술적으로 해결하는가?
|
||||
- 온디바이스 AI(Edge Computing)와 클라우드 기반 거대 예측 모델 간의 데이터 처리 분담은 어떻게 설계되어야 프라이버시 보호와 '선제적 제안'의 정확도를 동시에 극대화할 수 있는가?
|
||||
- 생리 주기, 심박수, 영양 등 다양한 컨텍스트 데이터를 MCP(Model Context Protocol)를 통해 LLM에 전달할 때, AI의 환각(Hallucination)으로 인한 잘못된 의학적 제안을 방지할 시스템적 안전장치는 무엇인가?
|
||||
- 웨어러블 기기 기반의 '선제적 질병 예측(Proactive Illness Prediction)' 기능이 실제 의료 현장 및 보험 적용을 받기 위해 거쳐야 하는 FDA 등 규제 기관의 승인(Clearance) 요건은 무엇인가?
|
||||
- FemTech 애플리케이션에서 HIPAA 및 GDPR 표준을 준수하면서 웨어러블 데이터를 능동적 헬스 코칭에 활용하기 위한 데이터 익명화 및 사용자 동의 메커니즘은 어떻게 구성되는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **Implementation:** 단일 Wearables API(예: Spike API)를 애플리케이션에 연동하여 개별 기기(스마트워치, 링 등)별로 통합 모듈을 개발하는 데 드는 수개월의 엔지니어링 시간과 유지보수 리소스를 획기적으로 감축합니다 [1, 2].
|
||||
- **System Design:** 사용자의 심박수 변이, 체온, 수면 데이터를 수집하는 IoT 센서 단과, 이를 실시간 분석하는 온디바이스 AI, 그리고 맥락을 부여해 능동적 제안을 텍스트로 생성하는 MCP 기반 LLM 계층으로 시스템 아키텍처를 설계합니다 [4, 5, 8].
|
||||
- **Operation / Maintenance:** 사용자 데이터 보안을 위해 종단 간(End-to-End) 암호화를 유지하며, 수집된 민감한 생체 정보를 HIPAA 및 GDPR 기준에 부합하는 인프라에 저장하고 정기적인 보안 감사를 수행합니다 [1, 18].
|
||||
- **Learning Path:** IoT 디바이스 프로토콜, 모바일 환경의 경량 머신러닝(Edge AI) 모델 최적화 기술, 그리고 헬스케어 데이터 규정(HIPAA 등)과 보안 아키텍처에 대한 학습이 필수적입니다 [1, 5, 18].
|
||||
- **My Project Relevance:** 웨어러블 및 스마트 기기 사용자들에게 수동적인 통계 대시보드를 제공하는 것을 넘어, 다중 데이터를 분석하여 위험 징후를 사전에 경고하고 개선 방안을 제시하는 선제적 건강 코칭(Proactive Health Coaching) 앱/서비스를 기획하는 데 직접적으로 적용됩니다 [7, 8].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[FemTech (여성 건강 기술)]]
|
||||
- 확장 방향: 생리 주기 추적을 넘어 체온, 심박수 변이 데이터를 결합하여 임신 합병증 감지, 가임기 예측 등 여성의 생리적 주기에 맞춘 선제적이고 임상적인 예측 진단 시장으로의 확장 [6, 7, 13, 16].
|
||||
- [[Clinical-Grade Biosensors (임상 등급 바이오센서)]]
|
||||
- 확장 방향: 스마트 링, 무채혈 연속 혈당 측정기(CGM) 등 일반 웰니스 트래커에서 의료 기기 수준으로 진화하는 하드웨어 센서 기술 동향과 예방 의학적 활용 가치 탐구 [14-16, 19].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
id: wiki-2026-0508-wearables-api
|
||||
title: Wearables API
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [mission_f66b7b222a6c]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [automated, datacollector, brain_sync]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Wearables API]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Wearables API(웨어러블 API)는 스마트워치, 피트니스 트래커, 스마트 링 등 수많은 웨어러블 및 IoT 기기의 데이터를 단일 연결을 통해 애플리케이션에 연동해 주는 인터페이스입니다 [1-3]. 개발자는 이를 통해 각 기기별로 시스템을 별도로 구축할 필요 없이 일관된 형식의 건강 데이터를 수집하고 개발 및 유지보수 시간을 크게 단축할 수 있습니다 [2]. 특히 펨테크(FemTech) 및 헬스케어 앱이 AI를 활용하여 개인화되고 선제적인 건강 관리(Proactive health coaching)를 제공할 수 있도록 돕는 핵심 인프라 역할을 수행합니다 [1, 2, 4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **포괄적인 기기 통합 및 엔지니어링 효율성**: Wearables API(예: Spike Wearables API)는 단 한 번의 연동 작업만으로 500개 이상의 웨어러블 및 IoT 기기에 대한 데이터 접근을 제공합니다 [1, 2]. 이는 수백 개의 기기를 일일이 연동하고 지속적으로 유지보수하는 데 드는 수개월의 엔지니어링 리소스를 절감해주며, 서로 다른 기기 유형 간에도 일관된 데이터 형식을 보장합니다 [2].
|
||||
* **폭넓은 데이터 범용성 및 확장성**: 오직 피트니스 목적의 기기에 한정되는 피트니스 API와 달리, Wearables API는 피트니스 트래커뿐만 아니라 스마트 링 및 다양한 IoT 기기 등을 광범위하게 포함합니다 [3]. 웰니스 트래커와 피트니스 트래커 간의 기능적 경계가 모호해지는 오늘날의 시장 환경에서, 다양한 기기를 지원함으로써 사용자 기반을 효과적으로 확장할 수 있습니다 [3].
|
||||
* **선제적 코칭(Proactive Suggestion) 환경 구축**: 웨어러블 API는 웨어러블 기기의 생체 데이터(심박수, 수면 패턴, 체온 등)는 물론 영양 AI 정보, 실험실 검사 결과 등 광범위한 데이터를 파이프라인으로 연결합니다 [1, 4]. 이를 MCP(Model Context Protocol)를 통해 대규모 언어 모델(LLM)과 통합하면, 건강 관리 앱은 단순한 데이터 추적기를 넘어 스트레스나 수면 부족 등 상황에 맞춰 구체적이고 선제적인 맞춤형 조언을 제공하는 지능형 건강 코치로 기능할 수 있습니다 [1, 4].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **엄격한 데이터 규제 및 보안 의무**: 웨어러블 API를 통해 처리되는 정보는 개인의 민감한 건강 데이터이므로, 미국의 HIPAA 및 유럽의 GDPR과 같은 엄격한 규제를 반드시 충족해야 합니다 [1, 5]. 데이터를 안전하게 관리하기 위해서는 데이터 전송 시 종단 간 암호화(end-to-end encryption) 적용, HIPAA를 준수하는 인프라 구축, 정기적인 보안 감사 등 높은 수준의 보안 표준이 강제됩니다 [2].
|
||||
* **사용자 권한 동의 및 데이터 단절 가능성**: 앱이 API를 통해 데이터를 수집하려면 기기 제조사의 API를 통한 사용자의 명시적인 권한 승인이 필수적입니다 [5]. 사용자는 언제든지 기기 설정을 통해 데이터 공유 권한을 철회할 수 있으므로, 지속적인 데이터 접근성을 100% 보장받을 수 없다는 제약이 따릅니다 [5].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-05*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
id: wiki-2026-0507-029
|
||||
title: 데이터 사이언스 및 ML 엔지니어링
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-029, Machine Learning, Deep Learning, ML, Python, Data Science, Generative AI, Neural Networks, VAE, LSTM, DQN, Bayesian Inference, MDP, Swarm Intelligence, NLP, Computer Vision, CNN, Reinforcement Learning, 기계 학습, 데이터 사이언스, 강화 학습]
|
||||
duplicate_of: none
|
||||
source_trust_level: B
|
||||
confidence_score: 1.0
|
||||
tags: [AI, Machine Learning, Deep Learning, Data Science, Generative AI, MLOps, NeuralNetworks, ProbabilisticModels, ComputerVision, RL]
|
||||
raw_sources: [직접 입력, AI/VAE.md, AI/LSTM.md, AI/DQN.md, AI/Bayesian.md, AI/MDP.md, CNN.md, Neural_Networks_and_Deep_Learning_Foundations.md, Reinforcement_Learning_Fundamentals.md, Reinforcement_Learning_and_Decision_Making.md, Theoretical_Foundations.md, Computer_Vision.md]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 데이터_사이언스_및_ML_엔지니어링
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터로부터 가치를 추출하고 지능을 모델링하는 공학." 단순한 예측을 넘어, 대규모 데이터를 학습하여 새로운 콘텐츠를 생성하고(Generative AI), 복잡한 문제를 인공신경망으로 해결하는 현대 AI 기술의 근간.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 데이터 전처리(Cleaning)에서 시작하여 모델 학습(Training)과 최적화(Optimization)를 거쳐, 실제 서비스에 배포하고 모니터링하는 전 과정(MLOps)을 하나의 유기적인 파이프라인으로 구축하는 것이 핵심이다.
|
||||
|
||||
**세부 내용:**
|
||||
- **머신러닝 및 딥러닝 기초:**
|
||||
- **3대 학습 패러다임:** 지도 학습, 비지도 학습, 강화 학습.
|
||||
- **인공신경망 아키텍처 (Neural Architectures):**
|
||||
- **CNN (Convolutional Neural Networks):** 이미지 데이터의 공간적 구조를 보존하며 특징을 추출하는 표준 아키텍처. 풀링(Pooling), 필터(Filter), 스트라이드(Stride) 등을 통해 고수준 시각적 패턴 학습.
|
||||
- **LSTM (Long Short-Term Memory):** 시계열 데이터의 장기 의존성 문제를 해결하는 순환 신경망(RNN) 변형. 게이트 메커니즘(Forget, Input, Output)으로 정보의 흐름 제어.
|
||||
- **VAE (Variational Autoencoder):** 데이터의 잠재 공간(Latent Space)을 학습하여 새로운 데이터를 생성하는 확률론적 생성 모델.
|
||||
- **Transformer:** 셀프 어텐션(Self-Attention) 메커니즘을 통해 병렬 연산과 전역 문맥 파악이 가능한 현대 NLP의 표준.
|
||||
- **강화 학습 및 의사 결정 (RL & Decision Making):**
|
||||
- **보상 기반 학습:** 환경과의 상호작용을 통해 누적 보상을 최대화하는 정책(Policy) 학습.
|
||||
- **DQN (Deep Q-Network):** Q-Learning에 딥러닝을 결합하여 고차원 상태 공간에서 최적 정책 학습. 경험 재생(Experience Replay)과 타겟 네트워크 사용.
|
||||
- **MDP (Markov Decision Process):** 불확실성 하에서의 순차적 의사 결정을 정형화한 수학적 프레임워크.
|
||||
- **Swarm Intelligence:** 개별 개체들의 단순한 규칙 상호작용을 통해 복잡한 문제를 해결하는 집단 지성 알고리즘.
|
||||
- **확률 및 정보 이론:**
|
||||
- **Bayesian Inference:** 새로운 증거가 나타날 때마다 가설의 확률을 갱신하는 통계적 추론 방식.
|
||||
- **Information Theory:** 데이터의 압축, 전송 및 엔트로피(Entropy)를 다루는 통신과 학습의 기초 이론.
|
||||
- **도메인별 AI 응용:**
|
||||
- **Computer Vision:** 이미지 및 비디오 데이터의 특징 추출(CNN), 객체 탐지(YOLO, Faster R-CNN), 분할 및 생성.
|
||||
- **NLP (Natural Language Processing):** 언어의 구문 분석, 감성 분석, 기계 번역 및 텍스트 생성.
|
||||
- **데이터 엔지니어링 및 사이언스:**
|
||||
- **EDA (Exploratory Data Analysis):** 데이터의 특성과 패턴을 시각화 및 통계적으로 파악.
|
||||
- **데이터 정제:** 결측치, 이상치 처리 및 피처 엔지니어링을 통한 모델 성능 극대화.
|
||||
- **MLOps 및 실전 배포:**
|
||||
- **실험 관리:** MLflow 등을 활용한 하이퍼파라미터 및 모델 버전 관리.
|
||||
- **서빙 아키텍처:** 모델을 API 형태로 배포하고 데이터 드리프트를 실시간 모니터링.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 데이터 기반의 예측 모델이나 추천 시스템을 기획하고 개발할 때.
|
||||
- Stable Diffusion, DALL-E 등 생성형 AI 모델의 작동 원리를 이해하고 커스텀 학습(LoRA 등)을 수행할 때.
|
||||
- 파이썬 기반의 데이터 분석 파이프라인을 구축하거나 성능 튜닝이 필요할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 단순한 규칙 기반 알고리즘으로 충분히 해결 가능한 문제.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **문제 정의:** 비즈니스 목표를 데이터 사이언스 문제(분류, 회귀 등)로 치환.
|
||||
2. **데이터 확보 및 분석:** 원천 데이터를 수집하고 EDA를 통해 데이터의 질 파악.
|
||||
3. **모델링:** 데이터 크기와 복잡도에 따라 적절한 알고리즘(트리 기반 vs 신경망) 선택.
|
||||
4. **평가 및 최적화:** 정밀도(Precision), 재현율(Recall) 등 지표를 기반으로 모델 튜닝.
|
||||
5. **배포 및 관리:** MLOps 프로세스에 따라 모델을 배포하고 지속적으로 성능 관리.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **데이터 의존성:** 모델의 성능은 학습 데이터의 양과 질에 절대적으로 의존함 (GIGO).
|
||||
- **모델 붕괴 (Model Collapse):** AI가 생성한 합성 데이터를 다시 학습에 활용할 경우, 시간이 지남에 따라 모델의 정확성과 신뢰성이 저하되는 현상 주의.
|
||||
- **해석 가능성:** 복잡한 딥러닝 모델은 결과 도출 근거를 설명하기 어려울 수 있으므로 XAI 기법 병행 권장.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** B
|
||||
- **검토 이유:** 해당 없음
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Machine Learning (ML)]], [[Deep Learning]], [[Neural Networks]], [[Generative AI]], [[Diffusion 모델 작동 원리]] 등 150여 개
|
||||
- **처리 방식:** MERGE
|
||||
- **처리 이유:** 기초 통계부터 딥러닝, 생성형 AI, 그리고 MLOps까지 AI 엔지니어링 전반을 다룬 수많은 중복 문서를 통합하여 전사적 AI 지능 아키텍처 표준으로 구축함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 단순한 분석 도구 활용에서 '데이터 중심(Data-centric)의 파이프라인 자동화' 및 '생성형 AI의 실전적 응용'으로 초점 이동.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** , [[AI_이미지_생성_워크플로우]]
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 150개 이상의 AI/ML/데이터 사이언스 관련 중복 문서를 통합 및 v3.0 규격 적용 | MERGE | B |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
id: wiki-2026-0508-001
|
||||
title: 데이터 엔지니어링 표준
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0508-001, Data Engineering, Data Warehouse, Data Quality, Governance, Snowflake, Firebase Data Connect, ETL, Data Pipeline, 데이터 엔지니어링]
|
||||
duplicate_of: none
|
||||
source_trust_level: B
|
||||
confidence_score: 1.0
|
||||
tags: [Data Engineering, Infrastructure, Cloud, Data Governance, Database, SaaS]
|
||||
raw_sources: [Principles-of-Data-Connect.md, Snowflake-Data-Warehousing.md, 데이터 품질 계층 (Data Quality Layer).md, Active Metadata.md, Schema Drift.md]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 데이터_엔지니어링_표준
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터의 흐름은 공학이고, 파이프라인은 생명선이다." 원천 데이터의 수집부터 정제, 저장, 그리고 분석에 이르기까지 전 과정의 신뢰성을 확보하고, 데이터 품질 계층(Data Quality Layer)을 통해 AI 에이전트의 판단 근거를 견고히 하는 현대적 데이터 아키텍처 구축 표준.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> '저장과 연산의 분리(Separation of Storage and Compute)' 및 '스키마 우선 설계(Schema-First Design)'를 통해 확장성과 무결성을 동시에 확보한다. 특히 AI 에이전트 환경에서는 데이터의 최신성과 인증 상태를 실시간으로 검증하는 '데이터 품질 계층'이 필수적이다.
|
||||
|
||||
**세부 내용:**
|
||||
- **데이터 엔지니어링 아키텍처:**
|
||||
- **Cloud Native Data Warehouse (Snowflake):** 다중 클러스터 공유 데이터 아키텍처를 통해 무한한 확장성을 확보. 데이터 공유(Data Sharing) 기능을 활용하여 복제 없이 실시간 협업 수행.
|
||||
- **Hybrid Data Access (Firebase Data Connect):** NoSQL의 민첩성과 SQL(PostgreSQL)의 엄격함을 결합. GraphQL 인터페이스를 통해 복잡한 관계형 데이터를 타입 안전하게 처리.
|
||||
- **데이터 품질 및 거버넌스 (Data Quality Layer):**
|
||||
- **액티브 메타데이터 (Active Metadata):** 데이터 시스템을 지속적으로 모니터링하여 최신성 및 인증 상태를 에이전트에게 컨텍스트로 제공.
|
||||
- **데이터 계약 (Data Contracts):** 스키마 변경(Schema Drift)을 선제적으로 감지하고 차단하여 AI 에이전트의 환각 현상 방지.
|
||||
- **데이터 리니지 (Data Lineage):** 컬럼 단위의 계보 추적을 통해 오류 발생 시 원천 소스 식별.
|
||||
- **가상 인프라 운영:**
|
||||
- **SaaS 중심 운영:** 복잡한 서버 관리 대신 완전 관리형 서비스를 활용하여 '데이터의 가치' 창출에 집중.
|
||||
- **MCP 기반 연동:** 활성 메타데이터와 리니지 정보를 모델 컨텍스트 프로토콜(MCP)을 통해 에이전트와 동기화.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 대규모 데이터 파이프라인이나 분석 플랫폼(Snowflake 등)을 설계할 때.
|
||||
- AI 에이전트가 참조할 데이터의 신뢰성을 보장하기 위한 거버넌스 체계를 구축할 때.
|
||||
- 관계형 데이터베이스를 현대적인 GraphQL 환경에서 통합 관리해야 할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 데이터 관계가 매우 단순하고 무결성이 중요하지 않은 소규모 토이 프로젝트.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **스키마 정의:** 모든 데이터 모델링의 시작은 명확한 스키마 정의(GraphQL/SQL)에서 출발.
|
||||
2. **저장/연산 분리:** 비용 효율성과 확장성을 고려하여 스토리지와 컴퓨팅 자원을 분리 운영.
|
||||
3. **거버넌스 통합:** 데이터 파이프라인 초기 단계에 품질 검증 및 리니지 추적 메커니즘 삽입.
|
||||
4. **인증 자동화:** 에이전트가 사용할 데이터 소스에 대한 '인증 상태'를 자동 업데이트.
|
||||
|
||||
---
|
||||
|
||||
## ⚖️ 트레이드오프 및 고려사항
|
||||
|
||||
- **복잡성 vs 제어력:** 완전 관리형 SaaS(Snowflake, Firebase)는 운영 편의성을 제공하지만, 세부적인 성능 튜닝이나 인프라 비용 제어 측면에서 제약이 있을 수 있음.
|
||||
- **보안 vs 접근성:** 데이터 거버넌스가 강화될수록 데이터 접근 속도와 사용자 편의성이 저하될 수 있으므로, 'Zero Trust' 기반의 정교한 접근 제어 정책 병행 필요.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** B
|
||||
- **검토 이유:** 해당 없음
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Snowflake-Data-Warehousing]], [[Principles-of-Data-Connect]], [[데이터 품질 계층 (Data Quality Layer)]], [[데이터 엔지니어링 표준|Active Metadata]], [[Schema Drift]] 등
|
||||
- **처리 방식:** MERGE
|
||||
- **처리 이유:** 파편화되어 있던 데이터 창고 아키텍처, 실시간 데이터 연동 기술, 데이터 거버넌스 및 품질 관리 표준을 하나로 통합하여 '데이터 엔지니어링' 도메인의 단일 진실 공급원(Single Source of Truth)으로 구축함.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[백엔드_엔지니어링_및_데이터베이스_설계]], [[보안_및_시스템_신뢰성_표준]], [[데이터_사이언스_및_ML_엔지니어링]]
|
||||
- **Redirects:** [[Data-Engineering]], [[Snowflake]]
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | 데이터 엔지니어링 및 가상 인프라 관련 파편화된 자산 통합 및 v3.0 규격 적용 | CREATE | B |
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,141 @@
|
||||
---
|
||||
id: wiki-2026-0507-101
|
||||
title: 도메인 주도 설계(DDD) 및 소프트웨어 아키텍처
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-101, DDD, Domain-Driven Design, Clean Architecture, Hexagonal Architecture, Onion Architecture, Software Architecture, Microservices, CQRS, Layered Architecture, Microkernel, Space-based Architecture, 도메인 주도 설계, 클린 아키텍처, 아키텍처 패턴]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [Architecture, DDD, Clean Architecture, Backend, System Design, Software Engineering, DistributedSystems]
|
||||
raw_sources: [Software_Architecture_Patterns.md, Clean Architecture.md, Hexagonal Architecture.md, Microservices_Architecture.md, DDD_Aggregates.md, Space-based-Architecture.md]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 도메인_주도_설계(DDD)_및_소프트웨어_아키텍처
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "기술은 변하지만 도메인은 변하지 않는다." 소프트웨어의 핵심 가치인 비즈니스 로직(Domain)을 외부 프레임워크나 데이터베이스(Infrastructure)로부터 철저히 격리하여, 변화에 유연하고 테스트 가능한 고밀도 지능 시스템을 구축하는 현대 아키텍처의 정점.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 현대 소프트웨어 아키텍처는 **'관심사의 분리(SoC)'**와 **'의존성 역전(DIP)'**을 통해 비즈니스 핵심(Brain)과 기술적 세부사항(Limbs)을 분리한다. 클린/육각형/양파 아키텍처는 모두 도메인을 최중심에 두고 의존성이 안쪽으로만 향하게 함으로써 기술 스택의 교체가 비즈니스 로직에 영향을 주지 않도록 설계된다.
|
||||
|
||||
**세부 내용:**
|
||||
|
||||
### 1. 도메인 주도 설계 (DDD) 핵심 전략
|
||||
- **전략적 설계 (Strategic Design):**
|
||||
- **바운디드 컨텍스트 (Bounded Context):** 모델이 적용되는 명확한 경계를 설정하여 용어의 혼선을 방지 (예: '상품'이 주문 컨텍스트와 재고 컨텍스트에서 가지는 의미의 차이).
|
||||
- **보편적 언어 (Ubiquitous Language):** 개발자와 비즈니스 전문가가 동일한 용어를 사용하여 소통 비용과 오해를 최소화.
|
||||
- **전술적 설계 (Tactical Design):**
|
||||
- **엔티티 (Entities) vs 값 객체 (Value Objects):** 식별자(ID) 기반의 연속성을 가진 객체와 속성값 자체로 정의되는 불변 객체의 분리.
|
||||
- **애그리거트 (Aggregates):** 데이터 변경의 단위이자 일관성 유지의 경계. 외부에서는 애그리거트 루트(Root)를 통해서만 내부 객체에 접근.
|
||||
- **리포지토리 (Repository):** 도메인 객체의 영속성을 추상화하여 컬렉션처럼 다룸.
|
||||
|
||||
### 2. 현대적 아키텍처 스타일
|
||||
- **클린 아키텍처 (Clean Architecture):**
|
||||
- **4계층 구조:** Entities → Use Cases → Interface Adapters → Frameworks & Drivers.
|
||||
- **의존성 규칙:** 모든 의존성은 반드시 저수준(외부)에서 고수준(내부) 정책 방향으로만 향해야 함.
|
||||
- **육각형 아키텍처 (Hexagonal / Ports & Adapters):**
|
||||
- **포트 (Ports):** 내부 도메인이 정의한 인터페이스 (Input/Output).
|
||||
- **어댑터 (Adapters):** 외부 기술(DB, REST API, GUI)이 포트를 구현하거나 호출하는 구체적인 모듈.
|
||||
- **CQRS (Command Query Responsibility Segregation):**
|
||||
- 시스템의 상태를 변경하는 '명령(Command)'과 정보를 조회하는 '조회(Query)'의 모델을 분리하여 각각의 성능과 확장성을 최적화.
|
||||
|
||||
### 3. 주요 아키텍처 패턴 유형
|
||||
- **고전적 패턴 (Classic Patterns):**
|
||||
- **계층형 (Layered/N-tier):** 역할을 수평으로 분리(UI-Business-Data)하여 구조가 단순하고 이해하기 쉬움.
|
||||
- **마이크로커널 (Microkernel/Plugin):** 핵심 코어에 기능을 추가/제거할 수 있는 플러그인 구조. 시스템의 확장성과 유연성 극대화.
|
||||
- **분산 및 고성능 패턴:**
|
||||
- **이벤트 기반 (Event-driven):** 비동기 이벤트를 통해 컴포넌트 간 느슨한 결합과 높은 확장성 제공.
|
||||
- **스페이스 기반 (Space-based):** 중앙 DB의 병목을 해결하기 위해 공유 메모리(Tuple Space)를 활용한 분산 처리 아키텍처.
|
||||
- **마이크로서비스 (MSA)와 거시적 설계:**
|
||||
- **거시 아키텍처 (Macro):** 서비스 간 통신(API Gateway), 장애 전파 방지(Circuit Breaker), 분산 트랜잭션(Saga).
|
||||
- **미시 아키텍처 (Micro):** 각 서비스 내부를 클린/육각형 아키텍처로 구성하여 독립성 확보.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 대규모 엔터프라이즈 시스템의 초기 뼈대를 설계하거나 복잡한 레거시 시스템을 리팩토링할 때.
|
||||
- 비즈니스 로직이 매우 복잡하여(예: 뱅킹, 물류, 헬스케어) 기술적 노이즈를 제거하고 순수 도메인 로직만 테스트하고 싶을 때.
|
||||
- DB나 프레임워크(예: TypeORM -> Prisma, Express -> NestJS)를 교체할 가능성이 있는 장기 프로젝트.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 단순 CRUD 위주의 소규모 프로토타입이나 MVP. (오버엔지니어링으로 인한 속도 저하 위험)
|
||||
- 비즈니스 로직이 거의 없고 단순한 데이터 파이프라인만 수행하는 시스템.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **도메인 분석:** 전문가와 대화하며 바운디드 컨텍스트와 보편적 언어를 정의.
|
||||
2. **포트 정의:** 외부 기술(DB, API)에 의존하지 않고 비즈니스에 필요한 인터페이스(Repository, Service)를 먼저 설계.
|
||||
3. **유스케이스 구현:** 엔티티와 포트를 조합하여 비즈니스 시나리오를 코드로 작성.
|
||||
4. **어댑터 구현:** 실제 기술(SQL, 외부 API 호출)을 사용하여 포트를 구체화.
|
||||
5. **의존성 주입:** 최외곽 계층에서 모든 조각을 결합.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **보일러플레이트:** 계층 간 데이터 변환(DTO <-> Entity)을 위한 매퍼 코드가 늘어나며 초기 개발 속도가 느릴 수 있음.
|
||||
- **학습 곡선:** 팀 전원이 아키텍처 철학을 이해하지 못하면 경계가 무너지고 다시 스파게티 코드가 될 위험이 큼.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** A (로버트 마틴, 에릭 에반스 등 권위 있는 소스 기반)
|
||||
- **검토 이유:** 120개 이상의 파편화된 아키텍처 문서를 통합하여 전사적 표준으로 수립함.
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Architecture]], [[Clean Architecture]], [[Hexagonal Architecture]], [[DDD]], [[CQRS_Pattern]], [[Layered Architecture]] 등 120여 개
|
||||
- **처리 방식:** MERGE & ARCHIVE
|
||||
- **처리 이유:** 개별 아키텍처 패턴들이 서로 다른 이름으로 산재해 있으나, 핵심 철학(도메인 중심, 의존성 제어)이 일치하므로 이를 하나의 고밀도 지식 체계로 통합함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 전통적인 하향식 계층형 아키텍처(Presentation->Business->DB)는 더 이상 권장되지 않으며, 의존성 역전을 통한 도메인 중심 설계가 표준임.
|
||||
- **정책 변화:** 모든 기술적 결정(DB 선택 등)은 최대한 늦추고, 도메인 로직을 먼저 완성하는 '지연된 결정(Deferred Decision)' 원칙 장려.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[소프트웨어 설계 원칙 및 디자인 패턴]], [[현대적 프론트엔드 아키텍처 및 상태 관리]], [[클라우드 인프라 및 IaC 운영 표준]]
|
||||
- **Raw Source:** Architecture 폴더 내 500여 개 파일
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 120개 이상의 아키텍처/DDD 관련 문서 통합 및 v3.0 규격 적용 | MERGE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,137 @@
|
||||
---
|
||||
id: wiki-2026-0507-104
|
||||
title: 백엔드 엔지니어링 및 데이터베이스 설계
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-104, Backend Engineering, Database Design, API Design, Node.js, SQL, NoSQL, System Design, 백엔드, 데이터베이스]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [Backend, Database, Node.js, API, System Design]
|
||||
raw_sources: [Backend.md, API_Communication_Patterns.md, Relational-Database.md, Query-Optimization.md, NestJS_Microservices.md]
|
||||
last_reinforced: 2026-05-07
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 백엔드_엔지니어링_및_데이터베이스_설계
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터는 흐르고 시스템은 응답한다." 비즈니스 로직의 안정적인 실행 환경을 구축하고, 대규모 데이터의 영속성과 정합성을 보장하며, 고성능 통신 프로토콜을 통해 클라이언트와 에이전트의 요청을 처리하는 시스템의 심장부.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 현대적 백엔드는 **'계층화된 아키텍처'**와 **'다중 저장소 전략(Polyglot Persistence)'**을 통해 확장성을 확보한다. API 설계는 단순한 데이터 전달을 넘어 보안, 속도 제한(Rate Limiting), 그리고 관측 가능성(Observability)을 포함하는 종합적인 관문으로 진화했다.
|
||||
|
||||
**세부 내용:**
|
||||
|
||||
### 1. API 아키텍처 및 통신 패턴
|
||||
- **REST (Representational State Transfer):** 자원 중심의 표준 인터페이스. 무상태성(Stateless)을 통한 확장성 확보.
|
||||
- **GraphQL:** 클라이언트가 필요한 데이터만 요청할 수 있는 유연한 쿼리 언어. Over-fetching 방지.
|
||||
- **gRPC:** HTTP/2 기반의 고성능 바이너리 통신. 서비스 간 통신(Internal)에 최적.
|
||||
- **비동기 통신:** Message Broker (Kafka, RabbitMQ)를 활용한 이벤트 기반 아키텍처로 서비스 간 결합도 완화.
|
||||
|
||||
### 2. 데이터베이스 설계 및 최적화
|
||||
- **관계형 DB (RDBMS):** 엄격한 스키마와 ACID 트랜잭션 보장. 복잡한 조인과 정합성이 중요한 데이터에 적합.
|
||||
- **NoSQL:**
|
||||
- **Document (MongoDB):** 유연한 데이터 구조, 빠른 개발 속도.
|
||||
- **Key-Value (Redis):** 인메모리 처리로 초저지연 캐싱 및 상태 저장.
|
||||
- **Graph (Neo4j):** 복잡한 관계 중심 데이터 탐색에 특화.
|
||||
- **성능 최적화 기술:**
|
||||
- **인덱싱 전략:** B-Tree, Hash, GIN 등 접근 패턴에 맞는 인덱스 설계.
|
||||
- **샤딩 및 파티셔닝:** 데이터를 물리적으로 분산하여 부하 분산 및 쿼리 성능 향상.
|
||||
|
||||
### 3. Node.js 기반 백엔드 마스터리
|
||||
- **이벤트 루프 (Event Loop):** 싱글 스레드 논블로킹 I/O 모델의 핵심. CPU 집약적인 작업은 Worker Threads로 분리.
|
||||
- **메모리 관리:** V8 엔진의 힙(Heap) 구조와 가비지 컬렉션(GC) 메커니즘을 이해하여 메모리 누수 방지.
|
||||
- **미들웨어 및 인터셉터:** 요청/응답 파이프라인에서 공통 관심사(로깅, 보안, 변환)를 캡슐화.
|
||||
|
||||
### 4. 엔터프라이즈 데이터 패턴
|
||||
- **DTO (Data Transfer Object):** 계층 간 데이터 전송을 위한 객체. 도메인 엔티티를 외부 노출로부터 보호.
|
||||
- **Repository Pattern:** 데이터 접근 로직을 캡슐화하여 비즈니스 로직과 영속성 계층을 분리.
|
||||
- **의존성 주입 (DI):** 객체 생성을 외부에서 관리하여 테스트 용이성 및 결합도 완화.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 데이터 정합성과 성능 사이의 트레이드오프를 결정해야 하는 데이터베이스 스키마 설계 시.
|
||||
- 서비스 간의 통신 방식(HTTP vs gRPC vs Kafka)을 선택해야 할 때.
|
||||
- 대규모 트래픽 처리를 위한 서버 최적화 및 캐싱 전략 수립 시.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 복잡한 서버 로직이 필요 없는 정적 사이트 호스팅.
|
||||
- 프론트엔드 단독으로 처리 가능한 로컬 애플리케이션.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **요구사항 분석:** 읽기/쓰기 비율, 데이터의 관계 복잡도, 트랜잭션 필요 여부 파악.
|
||||
2. **저장소 선택:** RDBMS, NoSQL, Cache 중 목적에 맞는 저장소 매핑.
|
||||
3. **스키마 설계:** 정규화 또는 역정규화를 결정하고 인덱스 설계.
|
||||
4. **API 정의:** 인터페이스(REST/GraphQL)와 데이터 형식(JSON/Protobuf) 정의.
|
||||
5. **성능 테스트:** 부하 테스트를 통해 병목 지점을 찾고 최적화(Connection Pool, Query Tuning).
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **조급한 최적화 (Premature Optimization):** 초기 단계에서 과도한 샤딩이나 마이크로서비스 분리는 운영 복잡도만 높임.
|
||||
- **분산 트랜잭션의 한계:** CAP 정리(Consistency, Availability, Partition Tolerance)를 이해하고 보상 트랜잭션(Saga) 등의 대안 고려 필요.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** NestJS, Spring, PostgreSQL, MongoDB 등 주요 기술 스택의 공식 문서 및 실전 아키텍처 사례를 기반으로 함.
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Backend]], [[API_Communication_Patterns]], [[Relational-Database]], [[Query-Optimization]], [[Nodejs-Backend-Architecture]] 등 80여 개
|
||||
- **처리 방식:** MERGE & ARCHIVE
|
||||
- **처리 이유:** 백엔드와 데이터베이스는 실과 바늘 같은 관계이나 문서가 파편화되어 있음. 이를 시스템적 관점에서 하나의 통합 지침으로 묶어 설계의 일관성을 확보함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **ORM vs SQL:** 과도한 ORM 의존보다는 복잡한 쿼리에서 Raw SQL의 성능 이점을 고려해야 함.
|
||||
- **서버리스의 부상:** 전통적인 상주형 서버에서 이벤트 기반의 서버리스(Lambda, Cloud Functions)로 인프라 비용 최적화 트렌드 반영.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[도메인 주도 설계(DDD) 및 소프트웨어 아키텍처]], [[클라우드 인프라 및 IaC 운영 표준]], [[보안 및 시스템 신뢰성 표준]]
|
||||
- **Raw Source:** Backend 폴더 내 다수 파일
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 80개 이상의 백엔드/DB 관련 문서 통합 및 v3.0 규격 적용 | MERGE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,143 @@
|
||||
---
|
||||
id: wiki-2026-0507-039
|
||||
title: 보안 및 시스템 신뢰성 표준
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-039, Security, Reliability, Governance, Supply Chain Security, SAST, DAST, Secret Management, Encryption, SSDLC, SDLC, Data Privacy, 보안 표준, 시스템 신뢰성, 거버넌스, 비밀 키 관리, 암호화, 소프트웨어 개발 수명 주기]
|
||||
duplicate_of: none
|
||||
source_trust_level: B
|
||||
confidence_score: 1.0
|
||||
tags: [Security, Reliability, Governance, DevSecOps, Infrastructure, Safety, Encryption, Secrets_Management]
|
||||
raw_sources: [직접 입력]
|
||||
last_reinforced: 2026-05-07
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 보안_및_시스템_신뢰성_표준
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "보안은 사후 처리가 아닌 설계의 일부다." 외부 위협으로부터 시스템을 보호하고, 예기치 않은 오류 상황에서도 핵심 기능을 유지하며, 조직의 정책을 기술적으로 강제하는 신뢰 기반 인프라.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 심층 방어(Defense-in-depth) 전략을 통해 인프라, 애플리케이션, 데이터 전 계층에 걸쳐 보안 관문을 구축하고, 자동화된 테스트와 거버넌스 프레임워크를 통해 시스템의 예측 가능성과 신뢰성을 확보한다.
|
||||
|
||||
**세부 내용:**
|
||||
- **애플리케이션 보안 (App Security):**
|
||||
- **SAST/DAST/IAST:** 정적, 동적, 대화형 분석을 통해 코드 및 런타임 취약점을 조기에 식별.
|
||||
- **Shift-Left Security:** 보안 점검을 개발 초기 단계와 CI/CD 파이프라인에 내장하여 수정 비용 절감.
|
||||
- **SCA (Software Composition Analysis):** 오픈소스 및 서드파티 라이브러리의 취약점(CVE)과 라이선스를 실시간 모니터링.
|
||||
- **제로 트러스트 아키텍처 (Zero Trust):**
|
||||
- **명시적 검증 (Verify Explicitly):** 사용자 위치나 기기 상태와 상관없이 모든 접근 요청을 개별적으로 인증 및 인가.
|
||||
- **최소 권한 부여 (Least Privilege):** 작업 수행에 필요한 최소한의 권한만을 Just-in-Time 방식으로 부여.
|
||||
- **침해 가정 (Assume Breach):** 내부 침입자가 있다고 가정하고 마이크로 세그먼테이션(Micro-segmentation)을 통해 피해 범위 최소화.
|
||||
- **공급망 보안 (Supply Chain Security):**
|
||||
- **SBOM (Software Bill of Materials):** 모든 외부 의존성 목록을 관리하고 체크섬 검증을 통해 무결성 보장.
|
||||
- **시스템 신뢰성 엔지니어링 (SRE):**
|
||||
- **SLI/SLO/Error Budget:** 성공률 및 지연 시간 지표를 설정하고, 허용 가능한 실패 예산(Error Budget) 내에서 혁신 시도.
|
||||
- **Toil Automation:** 단순 반복적인 운영 작업을 코드로 자동화하여 소프트웨어 엔지니어링 문제로 해결.
|
||||
- **AIOps:** AI가 로그를 분석하여 장애 징후를 사전에 감지하고 방어.
|
||||
- **비밀 정보 관리 (Secret Management):**
|
||||
- **Credential Separation:** API 키, DB 자격 증명 등을 코드와 분리하여 환경 변수나 Vault(AWS Secrets Manager, HashiCorp Vault)에서 관리.
|
||||
- **Secrets Detection:** Git 커밋 전 하드코딩된 비밀 정보 탐지(Gitleaks, Semgrep) 및 유출 시 즉각적인 키 무효화(Revocation).
|
||||
- **Rotation & Auditing:** 정기적인 비밀 키 순환과 접근 이력 감사를 통해 유출 피해 범위 최소화.
|
||||
- **암호화 표준 (Encryption Standards):**
|
||||
- **대칭 키 암호화 (AES-256):** 대용량 데이터의 고속 암호화/복호화에 활용. '하이브리드 방식'을 통해 키 전달 문제를 해결.
|
||||
- **비대칭 키 암호화 (RSA/ECC):** 키 교환 및 디지털 서명에 활용하여 신뢰 관계 형성.
|
||||
- **Data-at-Rest & In-Transit:** 저장된 데이터와 전송 중인 데이터 모두에 대해 표준화된 암호 프로토콜(TLS 1.3 등) 적용.
|
||||
- **안전한 개발 수명주기 (SDLC & SSDLC):**
|
||||
- **SDLC Phases:** 계획(Planning) → 분석(Analysis) → 설계(Design) → 구현(Implementation) → 테스트(Testing) → 유지보수(Maintenance) 전 과정의 체계화.
|
||||
- **Shift-Left Integration:** 계획 단계부터 위협 모델링을 수행하고, 설계-구현-테스트 전 과정에 보안 관문을 배치하여 수정 비용 최소화.
|
||||
- **SSDF 준수:** NIST의 안전한 소프트웨어 개발 프레임워크를 기반으로 아키텍처적 거버넌스 확립.
|
||||
- **데이터 프라이버시 및 개인정보 보호 (Data Privacy):**
|
||||
- **Privacy by Design:** 시스템 설계 시점부터 개인정보 최소 수집 및 익명화/가명화 기술(Differential Privacy 등) 적용.
|
||||
- **Compliance Management:** GDPR, CCPA, ISMS 등 국내외 보안 규제 대응 로드맵 구축.
|
||||
- **거버넌스 및 규제 준수 (Governance & Safety):**
|
||||
- **Data Governance:** 데이터 무결성 및 기밀성을 유지하기 위한 정책 집행.
|
||||
- **AI Guardrails:** 에이전트의 출력이 안전 범위 내에 있도록 실시간 제어 및 필터링.
|
||||
- **Audit Trail:** 모든 중요한 조작 이력을 불변의 로그로 기록하여 사후 추적 보장.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 신규 시스템의 보안 아키텍처를 설계하거나 기존 인프라의 취약점을 점검할 때.
|
||||
- 규제 준수(ISO 27001, HIPAA, GDPR 등)가 필요한 엔터프라이즈 환경에 배포할 때.
|
||||
- 오픈소스 라이브러리를 대량으로 사용하거나 외부 API와 연동하는 공급망 관리가 필요할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 보안이 전혀 고려되지 않아도 되는 내부용 일회성 테스트 스크립트.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **위협 모델링:** 공격 가능한 지점(Attack Surface)을 식별하고 우선순위 설정.
|
||||
2. **자동화 검사 도입:** CI/CD 파이프라인에 SAST 도구와 종속성 스캔 단계 추가.
|
||||
3. **격리 정책 수립:** 최소 권한 원칙(Principle of Least Privilege)에 따라 권한 분리 및 네트워크 격리.
|
||||
4. **모니터링 구축:** 장애나 보안 위협을 실시간으로 감지할 수 있는 경보(Alerting) 시스템 설정.
|
||||
5. **사고 대응 수립:** 문제 발생 시 즉각적으로 대응하고 복구할 수 있는 절차(Playbook) 마련.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **편의성과의 충돌:** 보안이 너무 엄격하면 개발 속도와 사용자 편의성이 저하될 수 있으므로 적정 수준의 균형 필요.
|
||||
- **완벽한 보안은 없음:** 보안은 고정된 상태가 아니라 지속적으로 진화하는 과정임을 인식해야 함.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** B
|
||||
- **검토 이유:** 해당 없음
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Governance, Safety & Reliability]], [[Supply Chain Security]], [[SAST]], [[Reliability]], [[Security-Best-Practices]] 등 90여 개
|
||||
- **처리 방식:** MERGE
|
||||
- **처리 이유:** 보안 진단 기술, 공급망 관리, 시스템 신뢰성 아키텍처, 거버넌스 정책 등 시스템의 안전성과 신뢰성 전반을 다룬 90개 이상의 문서를 통합하여 전사적 보안 표준으로 확립함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 개별 도구 중심의 보안에서 '데이터 거버넌스와 시스템 신뢰성이 결합된 통합 신뢰 아키텍처'로 확장 정의함.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[클라우드_인프라_및_IaC_운영_표준]], [[CI_CD_파이프라인_및_배포_자동화]], [[데이터_사이언스_및_ML_엔지니어링]]
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 90개 이상의 보안 및 신뢰성 관련 중복 문서를 통합 및 v3.0 규격 적용 | MERGE | B |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
id: wiki-2026-0507-106
|
||||
title: 생성형 AI 및 LLM 엔지니어링 표준
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-106, Generative AI, LLM Engineering, Large Language Models, Transformer, Mamba, LoRA, RAG, Prompt Engineering, Sampling Strategies, CFG, Test-time Computing, 생성형 AI, LLM 엔지니어링, 샘플링 전략]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [AI, GenerativeAI, LLM, MachineLearning, NLP, MLOps, Inference]
|
||||
raw_sources: [AI_Sampling_Strategies.md, CFG_스케일_제어.md, Soft-Prompt-Compression.md, Test-time computing.md, Mamba.md]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
---
|
||||
|
||||
# 생성형_AI_및_LLM_엔지니어링_표준
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "언어는 지능의 운영체제다." 방대한 데이터를 통해 학습된 언어 모델(LLM)을 최적화하고, 외부 지식(RAG)과 결합하며, 추론 성능을 극대화(Test-time computing)하여 자율적으로 사고하고 행동하는 인공지능 시스템의 코어 엔진.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 생성형 AI 엔지니어링은 **'모델의 효율적 학습(LoRA/PEFT)'**과 **'고성능 추론(FlashAttention/Quantization)'**, 그리고 **'신뢰성 있는 응답(RAG/Self-correction)'**이라는 세 축을 중심으로 발전하고 있다. 최근에는 Transformer의 한계를 넘는 SSM(Mamba) 아키텍처와 추론 시 연산량을 늘려 지능을 높이는 기법이 주목받고 있다.
|
||||
|
||||
**세부 내용:**
|
||||
|
||||
### 1. LLM 아키텍처 및 혁신
|
||||
- **Attention 메커니즘 최적화:**
|
||||
- **FlashAttention:** 메모리 대역폭 병목을 해결하여 긴 문맥(Long Context) 처리 속도를 획기적으로 개선.
|
||||
- **S2-Attn:** 다중 해상도 및 긴 문맥 처리를 위한 효율적인 어텐션 구조.
|
||||
- **차세대 아키텍처 (SSM):**
|
||||
- **Mamba (Selective SSM):** 데이터에 따라 상태를 선택적으로 압축하여 RNN의 효율성과 Transformer의 성능을 동시에 확보. 선형 시간 복잡도로 긴 시퀀스 처리 가능.
|
||||
- **Jamba/Bamba:** Transformer와 Mamba를 결합하여 두 아키텍처의 장점을 극대화한 하이브리드 모델.
|
||||
|
||||
### 2. 학습 및 미세조정 (Fine-tuning)
|
||||
- **LoRA (Low-Rank Adaptation):** 모델의 전체 가중치 대신 일부 가중치 행렬만 학습하여 자원 소모를 최소화하면서 특정 태스크에 최적화.
|
||||
- **SFT (Supervised Fine-tuning):** 지시 이행 능력을 높이기 위해 선별된 데이터셋으로 모델을 직접 학습.
|
||||
- **Self-Correction (자기 수정):** 모델이 자신의 응답을 스스로 검토하고 오류를 수정하는 메커니즘을 학습에 포함하여 신뢰성 향상.
|
||||
|
||||
### 3. 신뢰성 및 성능 고도화 (Reliability & Inference)
|
||||
- **환각(Hallucination) 제어:** RAG(Retrieval-Augmented Generation)를 통해 외부의 검증된 지식을 참조하게 함으로써 사실 관계 오류 최소화.
|
||||
- **Test-time Computing:** 추론 시점에 더 많은 연산(Chain of Thought 등)을 할당하여 복잡한 논리 문제 해결 능력을 비약적으로 향상.
|
||||
- **GPU 메모리 최적화:** Triton, CuTe 등을 활용한 커스텀 커널 작성으로 하드웨어 가속 성능 극대화.
|
||||
|
||||
### 4. 샘플링 및 생성 제어 (Generation Control)
|
||||
- **샘플링 전략 (Sampling):**
|
||||
- **Temperature:** 확률 분포의 평탄도를 조절하여 응답의 창의성과 결정론적 성향 사이의 균형 제어.
|
||||
- **Top-p (Nucleus Sampling):** 누적 확률이 임계값 p에 도달할 때까지 상위 토큰들을 선택하여 품질 유지.
|
||||
- **CFG (Classifier-Free Guidance):** 프롬프트에 대한 조건부 생성과 무조건부 생성 사이의 차이를 증폭시켜, 모델이 프롬프트의 지시 사항을 더 엄격하게 따르도록 강제하는 기법.
|
||||
- **Soft Prompt Compression:** 긴 프롬프트의 핵심 정보를 압축하여 컨텍스트 창을 효율적으로 사용하고 추론 속도를 높이는 최적화 기술.
|
||||
|
||||
### 5. 온디바이스(On-Device) 및 엣지 AI
|
||||
- **경량화 기술:** 양자화(Quantization), 가지치기(Pruning)를 통해 모바일 및 웨어러블 기기에서 실시간 추론 가능하도록 최적화.
|
||||
- **엣지 컴퓨팅:** 개인정보 보호와 저지연성을 위해 데이터를 기기 내에서 직접 처리하는 아키텍처.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 특정 도메인(법률, 의료, 코딩)에 특화된 커스텀 LLM을 구축하거나 LoRA 학습을 설계할 때.
|
||||
- RAG 시스템을 구축하며 벡터 DB와 검색 알고리즘의 최적화가 필요할 때.
|
||||
- 긴 문서를 요약하거나 복잡한 추론이 필요한 AI 에이전트의 워크플로우를 설계할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 단순한 텍스트 분류나 키워드 추출 등 가벼운 NLP 작업 (Small 모델로 충분함).
|
||||
- 지연 시간이 극도로 짧아야 하는 단순 응답 시스템 (LLM의 추론 시간 고려 필요).
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **베이스 모델 선정:** 태스크의 복잡도와 가용 자원에 따라 Llama, Mistral, Mamba 등 선정.
|
||||
2. **데이터 파이프라인:** 고품질의 학습 데이터 또는 참조 문서(RAG용) 수집 및 정제.
|
||||
3. **최적화 기법 적용:** FlashAttention 적용 및 적절한 양자화(4-bit, 8-bit) 선택.
|
||||
4. **신뢰성 검증:** 환각 여부 및 일관성 테스트를 위한 벤치마크 수행.
|
||||
5. **배포 및 모니터링:** MLOps를 통해 서빙 성능을 모니터링하고 피드백 루프 구축.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **자원 소모:** LLM은 고성능 GPU 자원을 많이 소모하므로 비용 대비 효용성 분석 필수.
|
||||
- **데이터 오염:** 합성 데이터가 학습에 과도하게 포함될 경우 발생하는 '모델 붕괴' 현상 주의.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** 최신 AI 논문(FlashAttention, Mamba, LoRA 등)과 대형 언어 모델 배포 사례를 기반으로 함.
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Large Language Models (LLMs)]], [[Hallucination-in-LLMs|LLM Hallucinations]], [[Mamba]], [[Flash Attention]], [[LoRA_모델_커스텀_기법]], [[Supervised Fine-Tuning (SFT)]] 등 100여 개
|
||||
- **처리 방식:** MERGE & ARCHIVE
|
||||
- **처리 이유:** 생성형 AI 분야의 기술 속도가 매우 빨라 관련 문서가 산발적으로 생성됨. 이를 '엔지니어링 표준'이라는 하나의 체계로 묶어 최신 기술 트렌드를 일목요연하게 파악할 수 있도록 함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **Transformer의 독주:** 오랜 시간 Transformer가 주도해왔으나, 최근 SSM 계열 모델이 긴 문맥 처리에서 강력한 대안으로 부상 중.
|
||||
- **RAG vs Long Context:** 모델의 문맥 창이 넓어지더라도 비용과 정밀도 측면에서 RAG의 중요성은 여전히 유효함.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[데이터 사이언스 및 ML 엔지니어링]]
|
||||
- **Raw Source:** AI 및 LLM 폴더 내 다수 파일
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 100개 이상의 생성형 AI/LLM 엔지니어링 관련 문서 통합 및 v3.0 규격 적용 | MERGE | A |
|
||||
@@ -0,0 +1,137 @@
|
||||
---
|
||||
id: wiki-2026-0507-102
|
||||
title: 소프트웨어 설계 원칙 및 디자인 패턴
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-102, Software Design Principles, Design Patterns, SOLID, DRY, KISS, YAGNI, GoF Patterns, 디자인 패턴, 설계 원칙, 클린 코드]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [Programming, Software Engineering, Design Patterns, SOLID, Clean Code]
|
||||
raw_sources: [SOLID_Principles.md, Design_Patterns.md, DRY_Principle.md, Clean Code.md]
|
||||
last_reinforced: 2026-05-07
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 소프트웨어_설계_원칙_및_디자인_패턴
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드는 한 번 작성되지만 수만 번 읽힌다." 인간의 인지 한계를 극복하고 변화의 파동을 국소화하기 위해, 검증된 구조(Design Patterns)와 엄격한 규율(SOLID/Clean Code)을 적용하여 '읽기 쉽고 고치기 쉬운' 생태계를 구축하는 지침서.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 설계의 본질은 **'추상화'**와 **'결합도 관리'**에 있다. SOLID 원칙이 클래스 레벨의 올바른 의존성 방향을 제시한다면, 디자인 패턴은 반복되는 문제 상황에 대한 검증된 구조적 해답을 제공한다. 이 둘의 조화는 시스템의 부패를 막는 가장 강력한 방어선이다.
|
||||
|
||||
**세부 내용:**
|
||||
|
||||
### 1. 5대 핵심 설계 원칙: SOLID
|
||||
- **SRP (단일 책임 원칙):** 클래스는 단 하나의 변경 이유만 가져야 함. 책임이 명확하면 테스트와 재사용이 용이함.
|
||||
- **OCP (개방-폐쇄 원칙):** 확장에는 열려 있고 수정에는 닫혀 있어야 함. 인터페이스와 다형성을 활용하여 기존 코드를 건드리지 않고 기능을 추가.
|
||||
- **LSP (리스코프 치환 원칙):** 서브타입은 언제나 기반 타입으로 교체 가능해야 함. 상속 관계에서 부모의 계약을 어기지 않는 일관성 보장.
|
||||
- **ISP (인터페이스 분리 원칙):** 클라이언트가 사용하지 않는 메서드에 의존하지 않도록 거대 인터페이스를 구체적인 여러 개로 분리.
|
||||
- **DIP (의존성 역전 원칙):** 고수준 모듈은 저수준 모듈의 구현이 아닌 추상화(Interface)에 의존해야 함.
|
||||
|
||||
### 2. 주요 디자인 패턴 (GoF 기반)
|
||||
- **생성 패턴 (Creational):** 객체 생성 과정을 추상화.
|
||||
- **Singleton:** 인스턴스를 하나만 생성하고 전역 접근 제공.
|
||||
- **Factory Method:** 객체 생성을 서브클래스에 위임.
|
||||
- **Builder:** 복잡한 객체 생성을 단계별로 분리.
|
||||
- **구조 패턴 (Structural):** 클래스/객체 조합을 통한 더 큰 구조 형성.
|
||||
- **Adapter:** 서로 다른 인터페이스를 연결하는 중개자.
|
||||
- **Decorator:** 객체에 동적으로 새로운 책임을 추가.
|
||||
- **Facade:** 복잡한 서브시스템에 대한 단순화된 인터페이스 제공.
|
||||
- **행위 패턴 (Behavioral):** 객체 간의 책임 할당과 알고리즘 교류.
|
||||
- **Observer:** 상태 변화를 관찰자들에게 통지.
|
||||
- **Strategy:** 런타임에 알고리즘을 교체 가능하게 함.
|
||||
- **Command:** 요청을 객체로 캡슐화하여 매개변수화 및 취소 지원.
|
||||
|
||||
### 3. 실용적 설계 원칙 (KISS, DRY, YAGNI)
|
||||
- **DRY (Don't Repeat Yourself):** 지식의 중복을 배제. 모든 정보는 시스템 내에서 단일하고 권위 있는 표현을 가져야 함.
|
||||
- **KISS (Keep It Simple, Stupid):** 항상 단순함을 지향. 오버엔지니어링은 유지보수의 적임.
|
||||
- **YAGNI (You Aren't Gonna Need It):** 실제로 필요하기 전까지는 미래를 대비한 기능을 미리 구현하지 않음.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 신규 모듈을 설계하거나 기존 스파게티 코드를 리팩토링할 포인트가 필요할 때.
|
||||
- 코드 리뷰 시 "왜 이 코드가 나쁜지"에 대한 논리적 근거를 제시해야 할 때.
|
||||
- 인터페이스 기반의 확장성 있는 라이브러리나 SDK를 개발할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 극도의 성능 최적화가 필요한 하위 레벨 시스템 (추상화 오버헤드가 문제가 될 수 있음).
|
||||
- 수명이 매우 짧은 일회성 스크립트나 실험적 코드.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **문제 식별:** 중복 코드(DRY 위반)나 거대 클래스(SRP 위반) 등 악취(Code Smell) 탐지.
|
||||
2. **패턴 매칭:** 현재 상황에 적합한 디자인 패턴(예: 조건문이 너무 많으면 Strategy 패턴) 선정.
|
||||
3. **추상화:** 인터페이스를 먼저 정의하고 클라이언트 코드를 작성.
|
||||
4. **구현:** SOLID 원칙을 준수하며 구체 클래스 구현.
|
||||
5. **검증:** 단위 테스트를 통해 각 컴포넌트가 독립적으로 작동하는지 확인.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **디자인 패턴 남용:** 모든 문제에 패턴을 적용하려다 오히려 구조가 더 복잡해지는 '패턴 중독' 주의. 단순함(KISS)이 최우선임.
|
||||
- **추상화 비용:** 인터페이스 증가로 인해 코드 탐색이 어려워질 수 있으므로 적절한 수준에서 타협 필요.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** GoF, SOLID 등 검증된 소프트웨어 공학 표준을 기반으로 통합됨.
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[SOLID Principles]], [[Design_Patterns]], [[DRY Principle (Don't Repeat Yourself)]], [[Clean Code]], [[Singleton Pattern]], [[Observer Pattern]] 등 150여 개
|
||||
- **처리 방식:** MERGE & ARCHIVE
|
||||
- **처리 이유:** 개별 원칙과 패턴들이 낱개 문서로 흩어져 있어 전체적인 맥락 파악이 어려움. 이를 '설계 체계'라는 하나의 마스터 문서로 통합하여 활용성을 극대화함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **상속보다는 합성 (Composition over Inheritance):** 과거에는 상속(LSP)을 강조했으나, 현대 설계는 유연성을 위해 합성을 우선시함.
|
||||
- **함수형 프로그래밍의 영향:** 상태를 가진 객체 패턴보다 순수 함수와 불변성을 활용한 패턴 비중 확대 중.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[도메인 주도 설계(DDD) 및 소프트웨어 아키텍처]], [[테스트 전략 및 방법론]], [[프론트엔드 및 Nodejs 개발 워크플로우]]
|
||||
- **Raw Source:** Architecture 및 Programming 폴더 내 다수 파일
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 150개 이상의 설계 원칙/디자인 패턴 관련 문서 통합 및 v3.0 규격 적용 | MERGE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,123 @@
|
||||
---
|
||||
id: wiki-2026-0507-028
|
||||
title: 클라우드 인프라 및 IaC 운영 표준
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-028, Cloud Infrastructure, Kubernetes, Docker, Terraform, IaC, AWS, Backups, SaaS, IoT, Virtualization, 클라우드, 오케스트레이션, 백업, 가상화]
|
||||
duplicate_of: none
|
||||
source_trust_level: B
|
||||
confidence_score: 1.0
|
||||
tags: [Cloud, DevOps, Infrastructure, Kubernetes, Docker, IaC, Backup, SaaS, IoT, Virtualization]
|
||||
raw_sources: [직접 입력, DevOps_and_Security/Backups.md, DevOps_and_Security/SaaS.md, DevOps_and_Security/IoT.md]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 클라우드_인프라_및_IaC_운영_표준
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "서버를 직접 조립하지 말고 코드로 정의하라." 클라우드 네이티브 환경에서 인프라는 더 이상 물리적 자산이 아닌, 소프트웨어처럼 버전 관리되고 자동 배포되는 가변적 자원(Cattle, not Pets)이다.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 애플리케이션을 컨테이너(Docker)로 격리하고, 이를 수천 개의 인스턴스로 확장·관리(Kubernetes)하며, 이 모든 인프라 구성을 코드(IaC / Terraform)로 명시하는 것이 현대적 인프라 운영의 핵심 패턴이다.
|
||||
|
||||
- **클라우드 서비스 모델 (Service Models):**
|
||||
- **IaaS (Infra as a Service):** 가상 서버, 스토리지 등 기초 인프라 제공.
|
||||
- **PaaS (Platform as a Service):** 개발·배포 환경(런타임, 미들웨어) 제공.
|
||||
- **SaaS (Software as a Service):** 설치 없이 인터넷을 통해 애플리케이션을 구독하여 사용(수도·전력과 같은 '경험의 구독').
|
||||
- **백업 및 재해 복구 (Backup & Disaster Recovery):**
|
||||
- **3-2-1 법칙:** 데이터 복사본 3개 보유, 2개 이상의 매체 저장, 1개는 원격지 보관.
|
||||
- **Snapshot:** 특정 시점의 데이터 상태를 기록하여 롤백에 용이.
|
||||
- **WORM (Write Once Read Many):** 랜섬웨어 대응을 위해 수정/삭제 불가능한 격리 백업 정책 시행.
|
||||
- **가상화 (Virtualization):**
|
||||
- 하드웨어 자원을 가상 계층(Hypervisor)을 통해 논리적으로 분할하여 효율성 극대화.
|
||||
- 컨테이너 가상화(Docker)는 OS 커널을 공유하여 VM보다 가볍고 빠른 기동성을 제공함.
|
||||
- **IoT 및 엣지 인프라:**
|
||||
- **Telemetry:** 센서 데이터를 MQTT/HTTP 프로토콜을 통해 실시간 수집.
|
||||
- **Edge Computing:** 클라우드 전송 전 현장에서 데이터를 필터링하여 실시간성 강화 및 네트워크 부하 감소.
|
||||
- 서버리스(Lambda), 관리형 DB(RDS), 컴퓨팅(EC2) 등 다양한 추상화 계층을 제공하여 비즈니스 로직에만 집중할 수 있는 환경 제공.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 대규모 트래픽 대응을 위한 시스템 확장성(Scalability) 설계가 필요할 때.
|
||||
- 인프라 설정을 수동 작업이 아닌 자동화된 파이프라인(GitOps)으로 구축하고 싶을 때.
|
||||
- 마이크로서비스 아키텍처(MSA)를 실제 클라우드 환경에 구현하고자 할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 트래픽이 극히 적은 초기 MVP나 단일 서버로 충분한 소규모 프로젝트(오버엔지니어링 주의).
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **컨테이너화:** 앱을 Dockerfile로 작성하여 이미지를 빌드하고 레지스트리에 푸시.
|
||||
2. **IaC 정의:** VPC, 서브넷, 클러스터 등 기초 인프라를 Terraform 코드로 작성.
|
||||
3. **오케스트레이션 설정:** Kubernetes 매니페스트(YAML)를 통해 앱의 복제본 수(Replica), 로드밸런서 등을 정의.
|
||||
4. **모니터링 연동:** 사이드카 패턴 등을 활용해 로깅 및 보안 기능을 메인 로직과 분리하여 구축.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **YAML 지옥:** 설정 파일의 복잡성이 증가할 수 있으므로 Helm 차트나 Kustomize 같은 관리 도구 활용 권장.
|
||||
- **비용 관리:** 클라우드 자원은 사용량만큼 과금되므로 자동 확장(Autoscaling) 임계값 설정에 유의.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** B
|
||||
- **검토 이유:** 해당 없음
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Kubernetes]], [[Terraform-Infrastructure-as-Code]], [[Containerization_and_Docker]], [[Amazon-AWS-Formal-Verification]] 등 10여 개
|
||||
- **처리 방식:** MERGE
|
||||
- **처리 이유:** 클라우드 인프라의 핵심 3요소(컨테이너, 오케스트레이션, IaC)를 다룬 파편화된 문서들을 하나의 운영 표준 지침서로 통합함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 단순 '서버 관리' 개념에서 '코드 기반의 동적 오케스트레이션'으로 인프라 패러다임을 공식 정의함.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[CI/CD 파이프라인 자동화]]
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 10여 개의 클라우드/인프라 관련 중복 문서를 통합 및 v3.0 규격 적용 | MERGE | B |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,122 @@
|
||||
---
|
||||
id: wiki-2026-0507-023
|
||||
title: 테스트 전략 및 방법론
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-023, Testing Methodologies, 테스트 방법론, TDD, BDD, Unit Testing, Test Strategy]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [Testing, Software Engineering, Quality Assurance, TDD, Automation, CI/CD]
|
||||
raw_sources: [직접 입력]
|
||||
last_reinforced: 2026-05-07
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 테스트_전략_및_방법론
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "테스트는 단순히 버그를 찾는 행위가 아니라, 코드의 변경에 대한 용기(Confidence)를 부여하고 설계의 품질을 강제하는 엔지니어링 규율이다."
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 자동화된 테스트를 통해 사소한 로직 결함을 기계가 선별하게 함으로써, 인간 리뷰어가 아키텍처와 비즈니스 맥락 등 고차원적 가치에 집중할 수 있는 '품질 게이트(Quality Gate)'를 구축하는 것이 핵심이다.
|
||||
|
||||
**세부 내용:**
|
||||
- **테스트 계층 구조 (Testing Pyramid):**
|
||||
- **단위 테스트 (Unit Test):** 개별 함수/클래스 독립 검증. 가장 빠르고 많아야 함.
|
||||
- **통합 테스트 (Integration Test):** 모듈 간 상호작용 및 데이터 흐름 검증.
|
||||
- **E2E 테스트 (End-to-End):** 사용자 시나리오 기반 전체 시스템 흐름 검증.
|
||||
- **주요 방법론:**
|
||||
- **TDD (Test-Driven Development):** [실패 테스트 작성 -> 구현 -> 리팩토링] 순환을 통해 테스트 용이성이 높은 설계 유도.
|
||||
- **BDD (Behaviour-Driven Development):** 사용자 행위(Scenario) 중심 서술로 요구사항과 구현의 간극 해소.
|
||||
- **자동화 및 CI/CD 통합:**
|
||||
- **Pre-commit Hooks:** 코드 제출 전 기초 테스트 및 린팅 강제.
|
||||
- **Branch Protection:** 모든 테스트와 품질 검사를 통과해야만 병합 가능한 규칙 적용.
|
||||
- **품질 지표와 한계:**
|
||||
- **커버리지 (Coverage):** 80% 내외의 합리적 목표 설정 권장. 100% 강제는 무의미한 테스트 양산을 초래할 수 있음.
|
||||
- **결정론적 테스트 (Deterministic):** 무작위로 실패하는 'Flaky Test'를 제거하여 파이프라인 신뢰도 확보.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 프로젝트 초기 단계에서 품질 관리 및 배포 자동화 파이프라인을 설계해야 할 때.
|
||||
- 코드의 유지보수성이 떨어지고 변경 시마다 버그가 자주 발생하여 시스템적인 보완이 필요할 때.
|
||||
- 신입 개발자나 협업 팀에게 우리 팀의 테스트 표준을 안내해야 할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 일회성 스크립트나 실험적 프로토타이핑과 같이 코드 수명이 극히 짧은 경우.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **단위 테스트 구축:** 핵심 비즈니스 로직에 대해 작은 단위의 테스트부터 작성.
|
||||
2. **Mocking 활용:** 데이터베이스나 외부 API 등 의존성을 격리하여 테스트 속도와 독립성 확보.
|
||||
3. **CI 연동:** GitHub Actions 등을 통해 모든 PR에 대해 자동으로 테스트가 실행되도록 설정.
|
||||
4. **리뷰 문화:** 테스트 코드 자체도 리뷰 대상에 포함하여 테스트의 적절성과 엣지 케이스 검증 여부 확인.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- 자동화 테스트는 패턴 기반 오류는 잘 찾지만, 비즈니스 맥락의 논리적 모순은 인간의 검토가 여전히 필요함.
|
||||
- 테스트 코드가 프로덕션 코드보다 비대해지면 오히려 유지보수의 짐이 될 수 있으므로, '가치 있는 테스트'에 집중해야 함.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** 해당 없음
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Testing Methodologies (테스트 방법론)]], [[Testing Strategy]], [[Testing]], [[Unit Testing]], [[Integration-Testing-for-AI]] 등 다수
|
||||
- **처리 방식:** MERGE
|
||||
- **처리 이유:** 테스트의 이론, 계층, 자동화 전략을 담은 20여 개의 중복 문서를 통합하여 전사적 테스트 표준 가이드로 정립함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 단순 '버그 탐지'를 넘어 '리뷰어 에너지 보존'과 '설계 품질 강제'를 테스트의 핵심 가치로 격상함.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** , [[CI/CD 파이프라인 자동화]]
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 20개 이상의 테스트 관련 중복 문서를 통합 및 v3.0 규격 적용 | MERGE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
id: wiki-2026-0508-프론트엔드-및-nodejs-개발-워크플로우
|
||||
title: 프론트엔드 및 Nodejs 개발 워크플로우
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-D024EA]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 프론트엔드 및 [[Nodejs_and_Backend_Optimization|Nodejs]] 개발 워크플로우"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[프론트엔드 및 Nodejs 개발 워크플로우]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 프론트엔드 및 Node.js 개발 워크플로우는 소스 코드의 품질, 일관성, 그리고 보안을 자동화된 방식으로 유지하기 위해 일련의 도구들을 파이프라인에 결합하는 과정입니다. 주축이 되는 도구로는 코드 에러를 정적으로 분석하는 [[ESLint]]와 코드 스타일을 자동으로 정렬해주는 [[Prettier]]가 있으며, 이를 Git 훅([[Git Hooks]]) 관리 도구인 [[Husky]]와 변경된 파일만 검사하는 [[lint-staged]]를 통해 커밋 전에 강제합니다. 최근에는 이러한 파이프라인과 IDE에 AI 기반의 정적 애플리케이션 보안 테스트([[SAST]])를 결합하여 취약점을 조기에 탐지하고 자동 수정하는 체계가 필수적으로 자리 잡고 있습니다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **코드 품질 및 스타일 자동화 도구 (ESLint & Prettier)**
|
||||
자바스크립트 및 타입스크립트 기반의 프론트엔드와 Node.js 환경에서는 코드 품질과 스타일을 일관되게 유지하기 위해 ESLint와 Prettier를 핵심 도구로 사용합니다 [1, 2]. ESLint는 문법적 오류와 잠재적 버그, 안티 패턴을 찾아내고 규칙을 강제하는 린터(Linter)이며, Prettier는 줄 바꿈, 공백, 들여쓰기 등의 코드 스타일을 일관되게 변환해주는 포매터(Formatter)입니다 [1, 3, 4]. 이 두 도구를 함께 사용할 때 포맷팅 역할이 겹쳐 충돌이 발생할 수 있는데, 이를 방지하기 위해 `[[eslint-config-prettier]]` 패키지를 사용하여 Prettier와 충돌하는 ESLint 규칙을 비활성화하는 방식이 표준으로 권장됩니다 [5-7].
|
||||
|
||||
* **Git 훅을 통한 검증 자동화 (Husky & lint-staged)**
|
||||
개발자가 컨벤션에 맞지 않는 코드를 저장소에 커밋하는 것을 방지하기 위해 Git 훅(Git Hooks)을 자동화하는 Husky와 lint-staged가 폭넓게 사용됩니다 [8, 9]. Husky는 `pre-commit`이나 `pre-push` 등의 훅을 쉽게 공유하고 설정하게 해주며, lint-staged는 전체 코드베이스가 아닌 커밋 대기 중인 '스테이징된(staged) 파일'에 대해서만 검사와 포맷팅을 실행하도록 오케스트레이션하여 실행 속도를 획기적으로 높입니다 [9-11]. 이 설정은 `package.json`의 `prepare` 스크립트와 연동되어 팀원 누구나 의존성을 설치할 때 동일한 검증 파이프라인을 구축하게 해줍니다 [12, 13].
|
||||
|
||||
* **모노레포 환경에서의 워크플로우 구성**
|
||||
React, [[Next.js]] 등 다양한 애플리케이션과 공유 라이브러리를 단일 저장소에서 관리하는 [[Turborepo]] 같은 모노레포([[Monorepo]]) 환경에서는 린팅 설정의 파편화와 중복을 막기 위해 중앙집중식 관리를 수행합니다 [14, 15]. 중앙 패키지(예: `@repo/eslint-config`)에 Base, Next.js, 라이브러리 용의 사전 설정(preset)을 정의해두고, 각 개별 패키지에서는 이를 상속하여 사용합니다 [16-18]. 이후 프로젝트 루트 디렉토리에서 lint-staged를 실행할 때, 오케스트레이션 설정을 통해 변경된 파일이 어느 패키지에 속하는지 파악하고 각 패키지의 린팅 규칙을 독립적으로 적용함으로써 유지보수성을 극대화합니다 [18-20].
|
||||
|
||||
* **정적 애플리케이션 보안 테스트(SAST) 및 AI의 결합**
|
||||
코드 품질 검증과 함께 Snyk Code, [[SonarQube]], Checkmarx와 같은 SAST 도구들이 IDE 및 CI/CD 파이프라인에 통합되어 실시간으로 보안 취약점을 점검합니다 [21-23]. 기존의 단순 패턴 매칭을 넘어, 최근 워크플로우에는 LLM과 기계학습(ML)을 기반으로 한 AI 에이전트가 도입되어 파일 간의 데이터 흐름(Interfile [[Analysis]])이나 XSS, SQL 인젝션, 하드코딩된 비밀번호 등 복잡한 문맥의 취약점을 탐지합니다 [24-26]. 나아가 발견된 오류에 대해 단순 경고를 넘어 AI 기반의 자동 수정(Auto-fix) 코드를 제안하여 개발자가 즉각적으로 코드를 리팩토링하고 병합할 수 있도록 돕습니다 [27-29].
|
||||
|
||||
* **개발 워크플로우 내 공급망 보안 위협**
|
||||
개발 워크플로우를 구성하는 도구 자체의 보안 검증 또한 중요합니다. 실제로 워크플로우 구축 시 가장 흔하게 사용되는 `eslint-config-prettier` 패키지가 2025년에 공급망 공격(CVE-2025-54313)의 타겟이 된 사례가 있습니다 [30-32]. 관리자의 토큰 탈취를 통해 배포된 악성 버전은 `npm install` 실행 시 윈도우(Windows) 개발자 머신에 원격 코드 실행(RCE)을 가능하게 하는 악성 DLL을 드롭하도록 조작되어 있어, 코드 검증 도구와 서드파티 패키지 사용에 대한 지속적인 보안 및 의존성 관리가 필수적임을 시사합니다 [31-33].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[ESLint]], [[Prettier]], [[Husky]], [[lint-staged]], [[공급망 공격 (Supply Chain Attack)]]
|
||||
- **Projects/Contexts:** React 및 Next.js 개발 환경, [[Turborepo 기반 모노레포 워크플로우]]
|
||||
- **Contradictions/Notes:** ESLint와 Prettier를 결합할 때, `[[eslint-plugin-prettier]]`를 사용하여 Prettier를 ESLint 규칙의 일부로 실행하는 방식이 존재하지만, Prettier 공식 문서 및 실무 환경에서는 성능 저하 문제와 에디터 내 과도한 경고(빨간 밑줄) 발생 등의 피로도 문제로 인해 `eslint-config-prettier`를 활용해 역할(규칙 검사는 ESLint, 포맷팅은 Prettier)을 명확히 분리하는 것을 가장 권장합니다 [5, 34, 35].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,116 @@
|
||||
---
|
||||
id: wiki-2026-0508-041
|
||||
title: 프론트엔드 및 UIUX 표준
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0508-041, Frontend Architecture, UI/UX Design, Design Systems, HCI, Human-Computer Interaction, Accessibility, Web Performance, User Experience, Interaction Design, UCD, 프론트엔드, 디자인 시스템, 사용자 경험, 인간-컴퓨터 상호작용]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [Frontend, UX, UI, DesignSystem, HCI, Architecture, WebDev]
|
||||
raw_sources: [AI/Frontend-Architecture.md, AI/Design Systems.md, Frontend/Design Systems.md, Biz/UIUX Design Strategy.md]
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 프론트엔드_및_UIUX_표준
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "복잡한 UI 상태를 예측 가능한 흐름으로 관리하고, 사용자 경험(UX)을 기술적 구조로 구현하라." 단순히 화면을 그리는 것을 넘어, 컴포넌트 기반 설계(CDD)와 디자인 시스템을 통해 일관성을 유지하고 렌더링 최적화로 초저지연 인터랙션을 보장하는 것이 현대 프론트엔드의 핵심이다.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> UI를 독립적인 컴포넌트로 분리(Atomic Design)하고, 단방향 데이터 흐름을 통해 상태를 제어하며, 디자인 시스템(Design Tokens)을 통해 시각적 일관성과 개발 생산성을 동시에 확보하는 아키텍처 패턴.
|
||||
|
||||
**세부 내용:**
|
||||
- **프론트엔드 아키텍처:**
|
||||
- **Component-Driven Development (CDD):** Atomic Design(Atom -> Molecule -> Organism) 기반의 재사용 가능한 UI 설계.
|
||||
- **State Management:** 전역 상태(Zustand, Redux)와 서버 상태(TanStack Query), 로컬 상태의 역할 분리.
|
||||
- **Rendering Strategies:** Next.js App Router 기반의 서버 컴포넌트(RSC)와 클라이언트 컴포넌트의 조화로운 배치.
|
||||
- **디자인 시스템 (Design Systems):**
|
||||
- **Design Tokens:** 색상, 타이포그래피, 간격 등을 변수화하여 플랫폼 간 일관성 유지.
|
||||
- **Pattern Library:** 재사용 가능한 컴포넌트 집합과 사용 가이드라인 제공.
|
||||
- **Governance:** 시스템 업데이트 및 확산 프로세스 정의.
|
||||
- **UI/UX 디자인 및 전략:**
|
||||
- **HCI (Human-Computer Interaction):** 피츠의 법칙(Fitts's Law), 힉의 법칙(Hick's Law) 등 인지 심리학 기반 인터랙션 설계.
|
||||
- **Accessibility (WCAG):** 스크린 리더 지원, 고대비 모드 등 보편적 디자인(Universal Design) 원칙 준수.
|
||||
- **UX Research:** 사용성 테스트(UT), 데이터 기반 A/B 테스트를 통한 사용자 여정(User Journey) 최적화.
|
||||
- **인간-컴퓨터 상호작용 (HCI):**
|
||||
- **UCD (User-Centered Design):** 사용자의 인지 모델(Mental Model)과 어포던스(Affordance)를 최우선으로 고려하는 설계 철학.
|
||||
- **Interface Evolution:** GUI(그래픽) -> VUI(음성) -> NUI(자연스러운 행동) -> BCI(뇌파)로 확장되는 인터랙션 기술.
|
||||
- **Adaptive UI:** 사용자의 숙련도, 선호도, 현재 맥락에 맞춰 인터페이스 구성을 실시간으로 변경하는 지능형 UI.
|
||||
- **Human-in-the-Loop:** AI의 의사 결정 과정에 인간이 적절히 개입하여 신뢰성을 확보하는 설계 패턴.
|
||||
- **성능 최적화:**
|
||||
- **Web Vitals:** LCP, FID, CLS 등 핵심 지표 관리.
|
||||
- **Optimization:** Code Splitting, Lazy Loading, 이미지 최적화, 대규모 데이터 렌더링(Virtualization).
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 신규 프로젝트의 프론트엔드 기술 스택(React/Next.js 등) 및 폴더 구조를 설계할 때.
|
||||
- 브랜드 아이덴티티를 반영한 확장 가능한 디자인 시스템을 구축할 때.
|
||||
- 웹 페이지의 로딩 속도나 인터랙션 반응성이 낮아 성능 개선이 필요할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 백엔드 로직 중심의 API 서버 개발이나 데이터 엔지니어링 작업 시.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **조기 최적화:** 복잡한 상태 관리 라이브러리 도입은 초기 개발 속도를 늦출 수 있으므로 프로젝트 규모에 맞춰 선택할 것.
|
||||
- **디자인 부채:** 디자인 시스템의 엄격한 준수는 창의적 UI 시도를 제한할 수 있으므로 유연한 확장성을 고려해야 함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** , [[보안_및_시스템_신뢰성_표준]], [[Cloud_Native|Cloud_Native_and_Microservices]]
|
||||
- **Next Step:** AI 에이전트와 연동되는 동적 생성 UI(Generative UI) 패턴 연구 및 표준화.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,124 @@
|
||||
---
|
||||
id: wiki-2026-0507-038
|
||||
title: 현대적 웹 성능 및 사용자 경험 최적화
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-038, Web Performance, Core Web Vitals, RUM, Chrome DevTools, Rendering Optimization, 웹 성능 최적화, 사용자 경험 최적화, 코어 웹 바이탈]
|
||||
duplicate_of: none
|
||||
source_trust_level: B
|
||||
confidence_score: 1.0
|
||||
tags: [Frontend, Performance, UX, Web Vitals, Optimization, RUM, Profiling]
|
||||
raw_sources: [직접 입력]
|
||||
last_reinforced: 2026-05-07
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 현대적_웹_성능_및_사용자_경험_최적화
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "속도가 곧 경험이다." 데이터 기반의 지표(Core Web Vitals)를 바탕으로 로딩, 상호작용, 시각적 안정성을 최적화하여 사용자의 이탈을 막고 비즈니스 가치를 극대화하는 프론트엔드 공학의 핵심.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 실험실 데이터(Lighthouse)로 병목을 디버깅하고, 실사용자 모니터링(RUM)으로 실제 경험을 추적하며, 중요 렌더링 경로(CRP) 최적화와 현대적 렌더링 전략(SSR, RSC)을 통해 인지된 성능을 극대화한다.
|
||||
|
||||
**세부 내용:**
|
||||
- **핵심 성능 지표 (Core Web Vitals):**
|
||||
- **LCP (Largest Contentful Paint):** 최대 콘텐츠 렌더링 시간. 로딩 성능의 척도.
|
||||
- **INP (Interaction to Next Paint):** 다음 페인트까지의 상호작용 지연. 응답성 측정.
|
||||
- **CLS (Cumulative Layout Shift):** 시각적 안정성. 레이아웃 흔들림 측정.
|
||||
- **분석 및 진단 도구:**
|
||||
- **Chrome DevTools:** 메인 스레드 점유율, 메모리 누수, 네트워크 병목 실시간 프로파일링.
|
||||
- **Real User Monitoring (RUM):** 실제 사용자의 환경(네트워크, 기기 성능)에서 발생하는 지표를 수집하여 CrUX 데이터와 비교 분석.
|
||||
- **렌더링 및 자원 최적화:**
|
||||
- **Critical Rendering Path (CRP):** 렌더링 차단 리소스(JS/CSS) 최소화 및 폰트/이미지 우선순위 제어.
|
||||
- **이미지 최적화:** 차세대 포맷(WebP, AVIF) 사용 및 반응형 이미지(`srcset`) 적용.
|
||||
- **자바스크립트 실행 최적화:** 코드 분할(Code Splitting), 긴 작업(Long Tasks) 분산 실행, 웹 워커 활용.
|
||||
- **현대적 아키텍처:**
|
||||
- **React Server Components (RSC):** 클라이언트 전송 번들 크기를 줄이고 서버 리소스를 직접 활용.
|
||||
- **Streaming SSR:** 페이지 전체 로드 전 콘텐츠의 일부를 먼저 스트리밍하여 TTFB 개선.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 웹 애플리케이션의 로딩 속도가 느려 사용자 이탈률이 증가하거나 SEO 점수가 낮을 때.
|
||||
- 애니메이션이 끊기거나 클릭 반응이 느린 등 상호작용 품질을 개선해야 할 때.
|
||||
- 대규모 트래픽이 발생하는 서비스에서 실사용자의 성능 데이터를 기반으로 의사결정을 내려야 할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 성능보다 기능 구현의 속도가 압도적으로 중요한 프로토타입 단계(단, 기본 수칙은 준수 권장).
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **지표 설정:** 목표로 하는 Core Web Vitals 임계치 설정 (예: LCP < 2.5s).
|
||||
2. **현황 파악:** Lighthouse 실험실 데이터와 CrUX/RUM 필드 데이터 비교 분석.
|
||||
3. **병목 식별:** Chrome DevTools Performance 패널을 통해 메인 스레드를 차단하는 Long Task 식별.
|
||||
4. **최적화 수행:** 이미지 압축, 리소스 우선순위 조정, 미사용 코드 제거 등 실행.
|
||||
5. **검증 및 모니터링:** 변경 사항 배포 후 RUM 데이터를 통해 실제 사용자 경험 개선 여부 확인.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **트레이드오프:** SSR은 SEO와 FCP에 유리하지만 서버 비용과 TTI 지연(하이드레이션 병목)을 유발할 수 있음.
|
||||
- **네트워크 의존성:** 최적화된 코드라도 사용자의 네트워크 환경(3G 등)에 따라 성능이 좌우되므로 가혹한 환경에서의 테스트 필수.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** B
|
||||
- **검토 이유:** 해당 없음
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Web Performance Optimization]], [[Nodejs_and_Backend_Optimization|Chrome DevTools 및 메모리 프로파일링]], [[Real User Monitoring (RUM)]], [[React Performance Optimization]] 등 70여 개
|
||||
- **처리 방식:** MERGE
|
||||
- **처리 이유:** 웹 성능 측정 지표, 진단 도구 활용법, 렌더링 최적화 전략 등 웹 성능 전반을 다룬 70개 이상의 중복 문서를 통합하여 고성능 사용자 경험 구축을 위한 권위 문서로 수립함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** FID(First Input Delay)가 상호작용 전체를 측정하는 INP로 대체됨을 반영.
|
||||
- **정책 변화:** 단순한 '속도' 측정에서 '사용자가 인지하는 부드러움과 안정성' 중심으로 최적화 패러다임 이동.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** , [[디자인_시스템_및_사용자_경험_표준]], [[CI_CD_파이프라인_및_배포_자동화]]
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 70개 이상의 웹 성능 관련 중복 문서를 통합 및 v3.0 규격 적용 | MERGE | B |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,138 @@
|
||||
---
|
||||
id: wiki-2026-0507-103
|
||||
title: 현대적 프론트엔드 아키텍처 및 상태 관리
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [wiki-2026-0507-103, Frontend Architecture, Modern Frontend, State Management, FSD, Feature-Sliced Design, React Patterns, Next.js Architecture, 상태 관리, 프론트엔드 아키텍처]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [Frontend, React, Next.js, Architecture, State Management, FSD]
|
||||
raw_sources: [Frontend_Architecture.md, FSD (Feature-Sliced Design).md, React Component Patterns.md, Modern React Architecture.md]
|
||||
last_reinforced: 2026-05-07
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# 현대적_프론트엔드_아키텍처_및_상태_관리
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "UI는 상태의 함수다 ($UI = f(State)$)." 단순한 화면 구성을 넘어, 복잡한 상태의 흐름을 예측 가능하게 통제하고(State Management), 비즈니스 로직과 UI를 물리적으로 격리하여(FSD), 사용자에게 초저지연의 지능형 경험을 제공하는 설계의 정점.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**추출된 패턴:**
|
||||
> 현대 프론트엔드는 **'컴포넌트 기반 설계(CDD)'**와 **'기능 중심 아키텍처(FSD)'**를 결합하여 거대해진 코드베이스의 복잡성을 관리한다. 특히 서버 사이드와 클라이언트 사이드의 경계가 모호해지는 React Server Components(RSC) 환경에서, 상태의 위치와 렌더링 전략을 최적화하는 것이 핵심이다.
|
||||
|
||||
**세부 내용:**
|
||||
|
||||
### 1. 기능 중심 아키텍처: FSD (Feature-Sliced Design)
|
||||
- **계층 구조 (Layers):** 하위 계층은 상위 계층을 참조할 수 없는 엄격한 단방향 의존성 유지.
|
||||
- **App:** 전역 설정 (Providers, Styles).
|
||||
- **Processes:** 다단계 워크플로우 (Legacy 지향).
|
||||
- **Pages:** 애플리케이션의 화면 단위.
|
||||
- **Widgets:** 여러 기능을 조합한 독립적 UI 블록.
|
||||
- **Features:** 사용자 가치를 제공하는 비즈니스 기능 (예: '장바구니 담기').
|
||||
- **Entities:** 비즈니스 엔티티 (예: '상품', '사용자').
|
||||
- **Shared:** 재사용 가능한 범용 컴포넌트 및 유틸리티.
|
||||
|
||||
### 2. 컴포넌트 설계 패턴
|
||||
- **컴포넌트 합성 (Composition):** 작은 컴포넌트를 조합하여 복잡한 UI 구축 (Ant-Design, Headless UI의 핵심).
|
||||
- **Compound Components:** 상태를 공유하는 부모-자식 관계 (예: `Select`, `Option`).
|
||||
- **Hooks Pattern:** 로직을 재사용 가능한 단위로 캡슐화하여 UI와 완전히 분리.
|
||||
- **Headless UI:** UI 로직(상태, 접근성)만 제공하고 스타일은 사용자에게 위임.
|
||||
|
||||
### 3. 상태 관리 전략 (Layered State)
|
||||
- **Local State:** `useState`, `useReducer`. 컴포넌트 내부의 국소적 상태.
|
||||
- **Server State:** TanStack Query, SWR. 비동기 데이터 패칭, 캐싱, 동기화 전용.
|
||||
- **Global State:** Zustand, Redux Toolkit, Jotai. 애플리케이션 전반에서 공유되는 UI 상태.
|
||||
- **URL State:** `react-router`, `next/navigation`. 필터, 검색어 등 공유 가능한 상태.
|
||||
|
||||
### 4. 현대적 렌더링 전략
|
||||
- **RSC (React Server Components):** 서버에서 데이터를 직접 조회하고 렌더링하여 클라이언트 번들 크기 최소화.
|
||||
- **Hydration 최적화:** 필요한 부분만 자바스크립트를 로드하는 Islands Architecture.
|
||||
- **점진적 정적 재생성 (ISR):** 정적 페이지의 장점과 실시간 데이터 업데이트의 결합.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 대규모 React/Next.js 프로젝트의 폴더 구조와 의존성 규칙을 수립할 때.
|
||||
- 성능 최적화(리렌더링 방지, 번들 사이즈 최적화)가 필요한 시점.
|
||||
- 다수의 개발자가 협업하며 코드의 위치와 책임을 명확히 정의해야 할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 매우 단순한 랜딩 페이지나 정적 문서 사이트. (FSD 도입 시 폴더 깊이만 깊어짐)
|
||||
- Vanilla JS 기반의 가벼운 인터랙션 위주 시스템.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **아키텍처 선정:** 프로젝트 규모에 따라 FSD 또는 도메인 기반 폴더 구조 채택.
|
||||
2. **상태 계층 정의:** 서버 데이터와 클라이언트 UI 상태를 엄격히 분리 (TanStack Query vs Zustand).
|
||||
3. **공통 컴포넌트 구축:** Shared 계층에 원자적 컴포넌트(Atomic Design) 구축.
|
||||
4. **기능 구현:** Features 계층에서 비즈니스 로직을 구현하고 Widgets로 조립.
|
||||
5. **의존성 검사:** ESLint 등을 활용하여 하위 계층이 상위 계층을 참조하는지 상시 감시.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **과도한 계층화:** 소규모 프로젝트에서 FSD를 적용하면 파일 하나를 수정하기 위해 여러 계층을 이동해야 하는 불편함 발생.
|
||||
- **서버/클라이언트 경계 혼선:** RSC 도입 시 'use client'와 'use server'의 경계에서 발생하는 데이터 전달 제약 이해 필수.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** FSD 공식 가이드, React 최신 문서, 그리고 대규모 프론트엔드 프로젝트의 베스트 프랙티스를 기반으로 함.
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
- **기존 유사 문서:** [[Frontend Architecture]], [[FSD (Feature-Sliced Design)]], [[React Component Patterns]], [[State Management]], [[Nextjs-App-Router-Architecture]] 등 100여 개
|
||||
- **처리 방식:** MERGE & ARCHIVE
|
||||
- **처리 이유:** 프론트엔드 기술은 파편화되기 쉬우나, '컴포넌트'와 '상태'라는 두 축으로 모든 지식을 통합할 수 있음. 이를 통해 파편화된 기술 스택 가이드를 하나의 현대적 표준으로 융합함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **Flux vs Hooks:** Redux와 같은 대형 프레임워크 위주에서, Hooks와 원자적 상태(Atomic state) 위주로 트렌드 변화.
|
||||
- **CSR의 몰락:** SEO와 초기 로딩 성능을 위해 서버 사이드 렌더링(SSR/RSC)이 다시 주류가 됨.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[도메인 주도 설계(DDD) 및 소프트웨어 아키텍처]]
|
||||
- **Raw Source:** Frontend 폴더 내 다수 파일
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 100개 이상의 프론트엔드 아키텍처/패턴 관련 문서 통합 및 v3.0 규격 적용 | MERGE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
Reference in New Issue
Block a user