feat: Knowledge Gardening Milestone 470 (Batch #24 - 40% Achieved)
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,27 @@
|
||||
# [[Clean Code]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
클린 코드(Clean Code)는 소프트웨어를 작성할 때 누구나 읽기 쉽고 유지보수하기 편하도록 코드를 명확하고 단순하게 작성하는 방법론입니다 [1]. 프론트엔드 및 리액트(React) 생태계에서 애플리케이션의 규모가 커질 때 코드의 복잡성을 관리하고 예측 가능성을 높이기 위한 필수적인 기반 역할을 합니다 [2]. 이를 위해 개발자들은 간결하고 의미 있는 이름을 사용하며 깊게 중첩된 구조를 피해야 하고, 단일 프로젝트에 국한되지 않고 가독성을 보장하기 위해 모든 프로젝트에 적용해야 합니다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **클린 코드의 기본 적용 방식:**
|
||||
* 클린 코드는 명확성과 단순성을 최우선으로 합니다 [1]. React 컴포넌트를 작성할 때는 코드를 간결하게 유지하고, 목적이 명확히 드러나는 이름을 사용하며, 로직이 과도하게 깊게 중첩되는 구조를 피하는 것이 핵심입니다 [3].
|
||||
|
||||
* **SOLID 원칙을 통한 React 코드의 구조화:**
|
||||
* **SRP (단일 책임 원칙):** 컴포넌트나 훅은 오직 하나의 명확한 목적만 가져야 합니다 [4]. 만약 컴포넌트가 300줄을 넘어선다면, 이는 상태 관리, 데이터 페칭, 렌더링 등 너무 많은 역할을 짊어지고 있다는 신호이므로 더 작고 집중된 컴포넌트로 분리해야 합니다 [5].
|
||||
* **OCP (개방/폐쇄 원칙):** 기존 컴포넌트의 소스 코드를 직접 수정하는 대신, 컴포넌트 합성(composition)이나 `children`, `render props` 패턴을 사용하여 새로운 기능을 확장할 수 있어야 합니다 [4, 6].
|
||||
* **ISP (인터페이스 분리 원칙):** 컴포넌트는 자신이 사용하지 않는 props에 의존해서는 안 됩니다 [6, 7]. 큰 객체를 통째로 전달하기보다는 컴포넌트가 필요로 하는 명확하게 분리된 특정 데이터만 전달해야 결합도를 낮출 수 있습니다 [4, 6].
|
||||
* **DIP (의존성 역전 원칙):** 하나의 컴포넌트가 다른 컴포넌트에 직접적으로 의존하는 것을 피하고, props나 context를 통해 의존성을 주입받도록 설계해야 합니다 [4, 7].
|
||||
|
||||
* **DRY, KISS, YAGNI 원칙과 균형:**
|
||||
* **DRY (Don't Repeat Yourself):** 반복되는 코드를 피하고 재사용성을 높이기 위해, 공통 로직을 커스텀 훅이나 고차 컴포넌트(HOC)로 추출해야 합니다 [1, 3, 8, 9].
|
||||
* **KISS (Keep It Simple, Stupid):** 복잡성보다 단순함을 선택해야 합니다 [1]. 디버깅과 이해가 쉽도록 코드를 단순하게 유지해야 하며, 너무 이른 최적화를 피해야 합니다 [3, 9].
|
||||
* **YAGNI (You Aren't Gonna Need It):** 미래에 발생할지도 모르는 요구사항을 위해 복잡한 기능을 미리 구축해서는 안 됩니다 [10, 11]. 현재의 요구사항과 오늘 필요한 것들만 구현하여 추후의 데드 코드 발생을 최소화해야 합니다 [1, 3, 10].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[SOLID Principles]], [[React Architecture]], [[Refactoring]]
|
||||
- **Projects/Contexts:** [[Frontend Scalability]], [[Large-scale React Systems]]
|
||||
- **Contradictions/Notes:** 너무 철저하게 DRY 원칙을 지키려다 보면 불필요하고 복잡한 추상화를 낳게 되어, 오히려 코드를 단순하게 유지하라는 KISS 원칙을 위반할 위험이 있습니다. 소스는 이러한 문제를 방지하기 위해 특정 패턴이 최소 3번 반복될 때까지 기다렸다가 추상화하는 방식을 권장합니다 [8, 12].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[Component Composition]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
컴포넌트 합성(Component Composition)은 작은 선언적 컴포넌트들을 조립하여 더 크고 복잡한 컴포넌트 트리를 구성하는 React의 핵심 패턴입니다 [1]. 이는 `children` prop이나 렌더 프롭(render props)을 활용하여 내부 소스 코드 수정 없이 컴포넌트에 새로운 기능을 확장할 수 있게 함으로써 개방-폐쇄 원칙(OCP)을 충족시킵니다 [2, 3]. 확장 가능한 프론트엔드 아키텍처(예: Feature-Sliced Design)에서는 비즈니스 로직을 포함하지 않고 하위 모듈들을 오케스트레이션하여 UI를 조립하는 방식으로 널리 활용됩니다 [4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **선언적 UI 조립:** React의 JSX는 컴포넌트 트리 관점에서 생각하도록 장려하며, 상태(state)와 프롭스(props)의 순수 함수로서 UI를 표현합니다. 이러한 합성을 통한 선언적 접근은 예측 가능성과 테스트 용이성을 높여줍니다 [1].
|
||||
* **개방-폐쇄 원칙(OCP)의 구현:** SOLID 원칙 중 개방-폐쇄 원칙은 React에서 컴포넌트 합성을 통해 구현됩니다. 기존 컴포넌트를 직접 수정하는 대신 `children` prop이나 렌더 프롭(render props)을 통해 컴포넌트를 구성하면, 기존 코드를 손상시키지 않고도 새로운 기능을 쉽게 확장할 수 있습니다 [2, 3].
|
||||
* **기능 분할 설계(Feature-Sliced Design)에서의 역할:** 확장성을 위한 FSD 아키텍처에서 합성은 명확한 책임을 가집니다. '위젯(Widgets)' 레이어는 비즈니스 규칙을 직접 구현하지 않고, 하위의 '기능(Features)'과 '엔티티(Entities)'를 재사용 가능한 UI 블록으로 합성(compose)하여 오케스트레이션하는 역할을 수행합니다 [4]. 그 위 레이어인 '페이지(Pages)'와 '앱(App)' 역시 위젯들을 모아 전체 화면과 글로벌 설정을 합성하는 역할을 맡습니다 [4, 5].
|
||||
* **서버 및 클라이언트 컴포넌트의 합성:** Next.js의 App Router와 같은 최신 아키텍처에서는 React 서버 컴포넌트(RSC)가 일반 클라이언트 컴포넌트와 원활하게 합성될 수 있습니다 [6]. 이를 통해 정적인 UI는 서버에서 렌더링하고, 상호작용이 필요한 부분만 클라이언트 컴포넌트로 분리하여 결합할 수 있습니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Open/Closed Principle (OCP)]], [[Feature-Sliced Design (FSD)]], [[JSX]], [[React Server Components]]
|
||||
- **Projects/Contexts:** [[Scalable React Architecture]], [[Frontend System Design]]
|
||||
- **Contradictions/Notes:** 컴포넌트 합성에 대해 소스 간의 모순점은 발견되지 않았으며, 제공된 자료들은 모두 합성이 코드의 재사용성을 높이고 아키텍처의 결합도를 낮추는 핵심 원칙이라는 점에 동의하고 있습니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,25 @@
|
||||
# [[Custom Hooks]]
|
||||
|
||||
## 📌 Brief 시
|
||||
Custom Hooks는 React 애플리케이션에서 반복되는 로직을 추출하여 재사용성과 모듈성을 높이는 핵심적인 리팩토링 단위입니다 [1]. 주로 데이터 패칭, 폼 처리, 전역 상태 구독과 같은 공통 로직을 캡슐화하는 데 사용되며, 비즈니스 로직을 UI와 격리시켜 독립적이고 빠른 단위 테스트를 가능하게 합니다 [1]. 스케일러블한 프로젝트 구조에서는 별도의 디렉토리에 관리되며, 일관된 명명 규칙을 통해 코드베이스의 가독성과 유지보수성을 크게 향상시킵니다 [2-4].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **리팩토링 및 모듈성 향상:**
|
||||
최신 React 개발에서 Custom Hook은 리팩토링의 주요 단위로 작용합니다 [1]. 거대한 컴포넌트 내부에 있는 복잡한 데이터 패칭이나 폼 처리 로직을 `useFetch`, `useForm`과 같은 Custom Hook으로 추출하면, 비즈니스 로직이 UI 컴포넌트로부터 완전히 분리됩니다 [1]. 이러한 격리는 느린 통합 테스트에 의존하는 대신 빠르고 고립된 단위 테스트를 가능하게 하여 코드의 모듈성과 테스트 용이성을 극대화합니다 [1].
|
||||
* **DRY(Don't Repeat Yourself) 원칙의 실천:**
|
||||
동일한 코드를 반복하지 말라는 DRY 원칙을 React 컴포넌트에 적용하는 가장 대표적인 방법이 바로 재사용 가능한 로직을 Custom Hook이나 고차 컴포넌트(HOC)로 추출하는 것입니다 [5, 6]. 또한, 복잡한 상태 관리를 위해 단순히 `useState`를 남용하기보다는 `useReducer`나 Custom Hook을 활용하여 상태 관리 로직을 깔끔하게 유지하는 것이 권장됩니다 [7].
|
||||
* **폴더 구조 (Folder Structure) 모범 사례:**
|
||||
확장 가능한 애플리케이션 아키텍처에서 Custom Hook은 주로 `src/hooks/` 폴더 내에 중앙 집중화되어 배치됩니다 [2, 4]. 이 폴더에는 `useAuth`, `useLocalStorage`, `useWindowSize`와 같이 여러 컴포넌트와 도메인에 걸쳐 재사용되는 횡단 관심사(Cross-cutting logic)들이 위치하게 되며, 이를 통해 코드 재사용이 촉진되고 애플리케이션 로직 관리가 쉬워집니다 [2, 4].
|
||||
* **명명 규칙 (Naming Conventions):**
|
||||
클린 코드와 일관성을 위해 Custom Hook의 이름은 반드시 `camelCase`로 작성해야 하며, `use` 접두사로 시작하여 훅이라는 목적과 정체를 명확히 나타내야 합니다 (예: `useAuthState`) [3, 8-10].
|
||||
* **성능 최적화 고려사항:**
|
||||
의존성(dependencies)이 변하지 않는 상황에서 성능을 최적화하기 위해, Context Provider나 Custom Hook 자체를 메모이제이션(memoizing)하는 전략이 활용되기도 합니다 [11].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[DRY Principle]], [[React Folder Structure]], [[Clean Code]], [[Naming Conventions]]
|
||||
- **Projects/Contexts:** [[React Refactoring]], [[Scalable Frontend Architecture]]
|
||||
- **Contradictions/Notes:** 소스 내에 Custom Hook과 관련한 특별한 모순점은 발견되지 않았으며, 여러 출처에서 공통적으로 관심사 분리, 코드 재사용 및 리팩토링을 위해 Custom Hook의 적극적인 활용을 권장합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,21 @@
|
||||
# [[DRY Principle]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
DRY는 "Don't Repeat Yourself"의 약자로, 동일한 코드를 두 번 이상 작성하지 않고 기존 코드를 재사용하여 코드 중복을 피하는 소프트웨어 엔지니어링 원칙입니다 [1, 2]. 이를 통해 코드의 가독성을 높이고, 향후 변경 사항이 발생했을 때 여러 곳을 수정할 필요 없이 단일 지점에서만 변경할 수 있도록 하여 유지보수성을 극대화합니다 [2]. React 애플리케이션에서는 주로 공통 로직을 커스텀 훅(Custom Hooks)이나 고차 컴포넌트(Higher-Order Components)로 추출하는 방식으로 적용됩니다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
- **개념과 장점**: DRY 원칙을 따르지 않아 중복된 코드가 많아지면, 향후 코드 변경 시 여러 부분을 동시에 수정해야 하는 어려움이 따릅니다 [2]. 이 원칙을 적용하여 코드를 별도의 컴포넌트나 함수로 분리하면, 단 한 곳에서만 변경을 수행하면 되므로 코드의 반복을 줄이고 관리가 용이해집니다 [2, 5]. 특히 반복적인 로직이 많은 애플리케이션에서 매우 유용하게 쓰입니다 [4].
|
||||
- **React에서의 적용 방법**: React 개발에서 DRY 원칙은 로직을 재사용 가능한 형태로 추출하는 것을 장려합니다. 구체적으로는 반복되는 코드를 커스텀 훅이나 고차 컴포넌트(HOC)로 분리하여 컴포넌트 간의 결합도를 낮추고 로직의 예측 가능성을 높입니다 [3, 4, 6].
|
||||
- **적용 시 주의점 및 타 원칙과의 조화**:
|
||||
- DRY 원칙을 지나치게 맹신하면 지나치게 복잡한 추상화(overly complex abstractions)를 초래할 수 있습니다 [5].
|
||||
- 재사용 가능한 추상화가 본래의 반복된 코드보다 이해하기 어려워진다면, 이는 코드를 단순하게 유지하라는 **KISS (Keep It Simple, Stupid)** 원칙을 위배한 것입니다 [3].
|
||||
- 성급한 최적화를 피하기 위해, 코드 패턴이 세 번 이상 반복될 때까지 추상화를 보류하는 것이 일반적인 권장 지침입니다. 이렇게 함으로써 코드를 단순하고 디버깅하기 쉽게 유지할 수 있습니다 [3].
|
||||
- 모듈형 아키텍처인 **Feature-Sliced Design (FSD)** 같은 방법론에서도 DRY 원칙과 지역적인 커스터마이징(local customization) 사이에서 적절한 균형을 유지하는 것을 핵심으로 삼고 있습니다 [7].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[KISS Principle]], [[YAGNI Principle]], [[Clean Code]], [[Custom Hooks]]
|
||||
- **Projects/Contexts:** [[React Architecture]], [[Feature-Sliced Design]], [[Frontend Refactoring]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 DRY 원칙을 통해 반복을 줄일 수 있지만, 무리하게 적용할 경우 지나치게 복잡한 추상화로 이어질 수 있습니다 [5]. 이는 코드를 단순하게 유지하려는 KISS 원칙과 상충될 수 있으므로, 패턴이 세 번 이상 반복될 때 추상화를 적용하는 등 두 원칙 사이의 균형이 필요합니다 [3].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[KISS Principle]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
KISS(Keep It Simple, Stupid) 원칙은 복잡성보다는 단순성을 항상 선택하여 코드를 이해하고 유지보수하기 쉽게 만드는 소프트웨어 엔지니어링 원칙입니다 [1, 2]. React 개발 환경에서는 컴포넌트 로직을 단순화하고 조기 최적화(premature optimization)를 피하는 방향으로 적용됩니다 [3]. 함수나 컴포넌트가 비대해질 경우, 코드를 '단순하고 멍청하게(simple and dumb)' 남겨두기 위해 더 작고 직관적인 논리적 부분으로 분할할 것을 권장합니다 [2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **단순성 우선:** KISS 원칙은 코드를 명확하고 단순하게 작성하는 것을 핵심으로 합니다 [1]. 코드가 단순할수록 직관적으로 이해하기 쉽고 디버깅이 수월해집니다 [4]. 이 원칙은 빠른 프로토타이핑을 진행하거나 단순한 애플리케이션을 개발할 때 특히 유용하게 사용됩니다 [3].
|
||||
* **React 환경에서의 적용:** React에서 KISS 원칙을 준수하려면 컴포넌트의 로직을 복잡하게 만들지 않고 조기 최적화를 피해야 합니다 [3]. 컴포넌트와 함수가 성장함에 따라 논리를 분리하여 작고 이해 가능한 단위로 유지하는 것이 중요합니다 [2].
|
||||
* **DRY 원칙과의 균형 및 한계:** "Don't Repeat Yourself"를 뜻하는 DRY 원칙을 무리하게 적용하다 보면 KISS 원칙을 위반하기 쉽습니다 [5]. 코드의 중복을 피하려고 재사용 가능한 추상화(예: 커스텀 훅)를 만들었을 때, 그 추상화된 코드가 원본 코드보다 이해하기 어렵다면 추상화의 목적을 상실한 것입니다 [5]. 따라서 패턴이 최소 3번 반복될 때까지 추상화를 미루는 전략이 권장되며, 이를 통해 너무 이른 최적화를 방지하고 코드를 쉽게 디버깅할 수 있는 상태로 유지할 수 있습니다 [5].
|
||||
* **트레이드오프:** 단순하고 직관적인 구조 덕분에 디버깅이 용이해진다는 큰 장점이 있지만, 복잡한 문제에 대해 해결책을 지나치게 단순화(oversimplify)해버릴 위험이 있다는 단점도 존재합니다 [4].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[DRY Principle]], [[Clean Code]], [[Refactoring Techniques]]
|
||||
- **Projects/Contexts:** [[React Component Optimization]], [[Frontend Architecture]]
|
||||
- **Contradictions/Notes:** 코드 중복을 제거하기 위한 [[DRY Principle]]과 충돌할 여지가 있습니다. 과도한 추상화가 코드의 가독성을 해친다면, 무리한 중복 제거보다는 [[KISS Principle]]을 따라 직관성을 유지하는 것이 더 권장됩니다 [5].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,22 @@
|
||||
# [[Large-scale Application Architecture]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
대규모 애플리케이션 아키텍처(Large-scale Application Architecture)는 단순한 스크립트를 넘어 복잡한 분산 소프트웨어 시스템으로 진화한 현대 프론트엔드를 지탱하기 위한 엄격한 구조적 기반입니다 [1]. 이는 유지보수성, 확장성, 성능을 극대화하기 위해 코드를 기술적 역할이 아닌 비즈니스 기능(Feature)과 도메인 중심으로 구성하는 것을 핵심으로 합니다 [1-3]. 대표적으로 Feature-Sliced Design(FSD)과 같은 방법론을 통해 명확한 경계와 캡슐화, 단방향 의존성을 강제하여 시스템의 예측 가능한 성장을 가능하게 합니다 [4-7].
|
||||
|
||||
## 📖 Core Content
|
||||
* **아키텍처의 필요성과 실패 요인**: 리액트 시스템이 대규모로 성장할 때 마주하는 가장 흔한 실패 원인은 렌더링 속도 등의 기술적 요인이 아닌 '아키텍처의 붕괴'입니다 [8, 9]. 비즈니스 로직이 UI 컴포넌트로 새어나가거나, 상태 소유권이 중복되고 불분명해지면, 하나의 변경 사항이 시스템 전체에 영향을 미치는 숨겨진 결합(Hidden coupling)을 생성하여 개발 속도를 급격히 저하시킵니다 [8-10].
|
||||
* **기능 기반 구조와 Feature-Sliced Design (FSD)**: 폴더를 컴포넌트, 훅 등 기술적 파일 유형별로 분리하는 방식은 소규모 앱에서는 직관적이나 대규모 환경에서는 확장성이 매우 떨어집니다 [2, 11-13]. 이에 대한 해결책으로 비즈니스 기능과 사용자 흐름을 중심으로 코드를 구성하는 FSD가 도입되었습니다 [3, 4, 14]. FSD는 프로젝트를 `app`, `pages`, `widgets`, `features`, `entities`, `shared`의 6가지 계층(Layer)으로 엄격히 나눕니다 [5, 7]. 특히 상위 계층은 하위 계층에 의존할 수 있지만 하위는 상위에 의존할 수 없는 '단방향 의존성'과 명시적인 Public API(`index.ts`)를 강제하여 모듈 간의 안정적인 격리를 보장합니다 [5, 6, 15, 16].
|
||||
* **상태 관리(State Management)의 파편화 및 전문화**: 대규모 환경에서는 상태를 단일 스토어에 넣기보다 용도에 맞게 분리하여 관리합니다 [17]. 서버 API로부터 가져오는 데이터(서버 상태)는 TanStack Query를 통해 캐싱과 동기화를 처리하고, 테마와 같은 정적이고 전역적인 상태는 Context API를, 알림이나 장바구니처럼 빈번하게 변하는 동적 애플리케이션 상태는 Zustand를 사용하는 것이 권장됩니다 [18-22]. 단, 개발자가 10명 이상인 대규모 팀에서 얽혀있는 복잡한 상태를 다루고 일관된 패턴을 강제해야 할 때는 Redux가 산업 표준으로서 효과적입니다 [23-25].
|
||||
* **클린 코드와 설계 원칙 (SOLID & DRY)**: 기능형 리액트 컴포넌트에서도 소프트웨어 공학 원칙은 필수적입니다 [16, 26]. 단일 책임 원칙(SRP)에 따라 컴포넌트는 한 가지의 역할만 해야 하며, 300줄이 넘어간다면 여러 개의 작은 컴포넌트로 분리해야 합니다 [27]. 중복 로직은 커스텀 훅으로 추출하여 DRY 원칙을 지키되, 과도한 추상화보다는 직관적이고 단순하게 유지하는 KISS, YAGNI 원칙의 균형이 필요합니다 [28-30].
|
||||
* **성능 최적화 및 빌드 엔지니어링 (Performance & Build)**: 거대한 자바스크립트 번들은 초기 로드를 지연시킵니다 [31-33]. Vite 등의 번들러를 이용해 `manualChunks`로 무거운 벤더 라이브러리(React core 등)를 분리하고, `React.lazy`와 `Suspense`를 결합해 라우트나 기능 수준의 코드 스플리팅을 적용하여 성능을 높여야 합니다 [34-38]. 또한 2025년의 React Compiler는 빌드 타임에 자동으로 메모이제이션을 적용하여 수동 성능 최적화의 번거로움을 줄여줍니다 [34, 39-41].
|
||||
* **복원력 (Resilience) 및 모니터링**: 대규모 앱은 단일 컴포넌트의 런타임 오류가 전체 화면을 백지화하는 것을 막기 위해 Error Boundaries를 주요 위젯이나 불안정한 섹션마다 전략적으로 배치해야 합니다 [42-45]. 또한 프로덕션 레벨에서는 Sentry, LogRocket, Datadog과 같은 도구를 통해 사용자의 에러 발생 맥락(Session Replay)과 메모리 누수 등을 추적하여 디버깅을 고도화합니다 [45-48].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Feature-Sliced Design]], [[State Management]], [[SOLID Principles]], [[Performance Optimization]], [[Clean Code]], [[Error Boundaries]]
|
||||
- **Projects/Contexts:** [[React]], [[Next.js]], [[Vite]], [[Bulletproof React]]
|
||||
- **Contradictions/Notes:**
|
||||
- FSD 아키텍처의 적용에 대해 "모든 코드를 처음부터 세밀하게 슬라이싱하는 것보다 모놀리식으로 시작한 뒤 기능의 경계가 명확해졌을 때 분리하는 것이 낫다"는 상반된 의견이 존재합니다. 처음부터 무리하게 분할하면 3개면 충분할 조각이 수백 개로 나뉘는 부작용이 발생할 수 있습니다 [49].
|
||||
- FSD의 `shared` 계층에 대해서도, 조직이 커짐에 따라 관리가 통제 불능이 되고 버그의 온상이 되어 시스템 변경을 오히려 어렵게 만들 수 있다는 실무적 비판이 있습니다 [50].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,26 @@
|
||||
# [[YAGNI Principle]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
YAGNI는 "You Aren't Gonna Need It"의 약자로, 개발자가 미래에 필요할지도 모른다고 추측하여 복잡한 기능을 미리 구축하는 것을 피하라는 소프트웨어 설계 원칙입니다[1, 2]. 이 원칙은 오직 현재의 요구사항에만 집중함으로써 유지보수해야 할 데드 코드(dead code)와 복잡성을 최소화하는 데 목적이 있습니다[1]. 특히 요구사항이 자주 변경되는 애자일(Agile) 환경이나 스타트업 프로젝트에서 매우 중요하게 다뤄집니다[1, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **핵심 개념 및 도입 이유**:
|
||||
YAGNI의 핵심은 "정말로 필요해지기 전까지는 기능을 추가하지 말라"는 것입니다[2]. 언젠가 쓰일지도 모른다는 이유로 추가 기능을 작성하게 되면 코드를 작성하는 시간만 낭비될 뿐만 아니라, 결국 해당 기능이 필요 없어지거나 요구사항이 변경될 가능성이 큽니다[4]. 따라서 개발자는 현재 당장 필요한 기능만 구현하여 불필요한 기술 부채(tech debt)와 잉여 코드를 줄여야 합니다[5].
|
||||
|
||||
* **React 환경에서의 적용 (YAGNI in React)**:
|
||||
React 컴포넌트를 설계할 때도 YAGNI 원칙을 통해 코드를 간결하게 유지할 수 있습니다. 컴포넌트는 오늘 당장 필요한 것만 구현하고 확장은 나중으로 미뤄야 합니다[3].
|
||||
* 예를 들어 현재 날짜의 원시 데이터(raw date)만 필요한 상황이라면, 나중에 쓰일 것 같다는 이유로 날짜 포맷팅 함수를 미리 추가하지 말아야 합니다[2].
|
||||
* 마찬가지로 `<UserProfile />` 컴포넌트가 현재 사용자 정보(`user`)만 필요로 한다면, 아직 화면에 쓰이지 않는 `userSettings`나 `userPosts` 같은 여분의 props를 선제적으로 넘겨주거나 구현하지 않는 것이 좋은 사례입니다[3].
|
||||
|
||||
* **장단점(Trade-offs) 및 최적의 사용 환경**:
|
||||
* **장점**: 낭비되는 개발 노력을 줄여주고 코드베이스를 가볍게 유지할 수 있습니다[6]. 코드 자체가 부채가 되는 상황을 방지하고 불필요한 부분을 제거하는 리팩토링의 훌륭한 기준이 됩니다[5].
|
||||
* **단점**: 미래의 확장성(future scalability)을 간과하게 될 위험성도 내포하고 있습니다[6].
|
||||
* **사용 환경**: 요구사항이 계속해서 변화하는 스타트업 프로젝트나 빠른 릴리스가 중요한 애자일 개발 환경에서 사용하는 것이 가장 적합합니다[3].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[KISS Principle]], [[DRY Principle]], [[Clean Code]], [[Refactoring]]
|
||||
- **Projects/Contexts:** [[React Component Design]], [[Agile Development]], [[Startup Projects]]
|
||||
- **Contradictions/Notes:** YAGNI 원칙은 불필요한 노력의 낭비를 막아주지만, 미래의 확장성을 고려하지 못하게 만들 수 있다는 점이 단점으로 지적되므로 설계 시 균형을 잡는 것이 필요합니다[6].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -1,31 +1,28 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-SSLE-001
|
||||
id: AI-SELF-SUP-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 0.97
|
||||
tags: [auto-reinforced, self-supervised-learning, labels, pre-training, deep-learning, representation-learning]
|
||||
last_reinforced: 2026-04-20
|
||||
confidence_score: 1.0
|
||||
tags: [ai, deep-learning, self-supervised-learning, contrastive-learning, pretext-task, foundations]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Self-Supervised-Learning]]
|
||||
# [[Self-Supervised Learning (자기지도 학습)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "스승 없는 학습의 기적: 사람이 일일이 정답(Label)을 달아주지 않아도, 데이터 스스로의 일부를 가리고(Masking) 나머지로 맞추는 과정을 통해 세상의 패턴을 통달해 내는 데이터 효율성의 극치이자 현대 거대 모델(LLM)의 심장."
|
||||
> "데이터의 바다에서 정답지(Label)를 기다리지 말고, 데이터 스스로가 가진 내부 구조를 파고들어 지능의 본질을 깨워라" — 레이블이 없는 방대한 데이터로부터 스스로 정답(Pseudo-label)을 만들어 학습함으로써, 인간 수준의 상식과 일반화 능력을 획득하는 인공지능 학습 방법론.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
자기 지도 학습(Self-Supervised-Learning)은 레이블이 없는 데이터에서 자체적으로 레이블을 생성하여 학습하는 머신러닝 기법입니다.
|
||||
|
||||
1. **핵심 메커니즘 (Pretext Tasks)**:
|
||||
* **Masking**: 문장의 중간 단어를 가리고 문맥으로 맞추기 (BERT 스타일).
|
||||
* **Prediction**: 다음 단어나 프레임을 예측하기 (GPT 스타일).
|
||||
* **Contrastive Learning**: 같은 이미지 변형본끼리는 가깝게, 다른 이미지와는 멀게 배치하기. (Representation-Learning와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 인터넷의 방대한 날것의 데이터(Text, Image)를 정답지 작업 없이 통째로 먹일 수 있어, 지능의 규모를 인간의 한계를 넘어 무한히 키울 수 있기 때문임.
|
||||
- **추출된 패턴:** "Pretext Task and Representation Distillation" — 문장의 다음 단어를 맞추거나(BERT/GPT), 이미지의 일부를 가리고 복원하거나, 혹은 같은 이미지의 다른 변형을 가깝게 배치하는(Contrastive Learning) 등의 '가짜 문제'를 통해 데이터의 핵심 특징(Representation)을 추출하는 패턴.
|
||||
- **주요 기법:**
|
||||
- **Generative:** 데이터의 누락된 부분을 생성하며 학습 (예: GPT).
|
||||
- **Contrastive:** 서로 다른 샘플 간의 유사성과 차이점을 비교하며 학습 (예: SimCLR, CLIP).
|
||||
- **Predictive:** 데이터의 순서나 회전 상태 등을 예측하며 학습.
|
||||
- **의의:** 값비싼 인간의 레이블링 작업 없이도 무한한 인터넷 데이터를 지능의 땔감으로 사용할 수 있게 하여, 초거대 AI 모델 탄생의 결정적인 기폭제가 됨.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 사람이 정답을 준 것만 배우는 지도 학습(Supervised)이 최고였으나, 현대 정책은 지도 학습을 '미세 조정'용 보조 정책으로 밀어내고 자기 지도 학습 정책이 '기초 체력(Foundation)'을 만드는 주류 정책이 됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 단순히 텍스트 예측 정책을 넘어, 세상을 물리학적으로 이해하는 '비디오 생성 모델'에서의 자기 지도 학습 정책이 차세대 AI의 핵심 전장 정책임.
|
||||
- **과거 데이터와의 충돌:** 비지도 학습(Unsupervised)의 하위 범주로 여겨졌으나, 이제는 데이터가 '스스로 지도한다'는 능동적 의미를 담아 독립적인 패러다임으로 정착되었으며, 지도 학습보다 더 강력한 범용 표현을 형성할 수 있음이 입증됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 기본 언어 모델 및 임베딩 모델 구축 시, 대규모 비정형 지식 데이터를 가장 효과적으로 자산화할 수 있는 자기지도 학습 기반의 파이프라인을 최우선으로 고려함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Representation-Learning]], [[Deep Learning (DL)]], [[Machine Learning (ML)]], [[Optimization]], [[Efficiency]]
|
||||
- **Modern Tech/Tools**: BERT, GPT, DINO, SimCLR, MAE (Masked Autoencoders).
|
||||
---
|
||||
- [[Representation-Learning]], [[Deep-Learning-Foundations]], [[Natural-Language-Processing-NLP]], [[LLM-Training-Foundations]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Self-Supervised-Learning.md]]
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: IR-SEM-SEARCH-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, information-retrieval, semantic-search, embeddings, vector-database, nlp, search-engine]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Semantic Search with AI (AI를 활용한 시맨틱 검색)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "단순한 글자 맞추기(Keyword Matching)를 넘어 단어 이면에 숨겨진 '의미의 좌표'를 탐색하고, 사용자의 의도와 지식의 맥락을 연결하라" — 딥러닝 기반의 임베딩 기술을 활용하여 질문과 문서 사이의 의미적 유사성을 계산하고 가장 관련성 높은 정보를 추출하는 차세대 검색 기법.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Dense Vector Retrieval and Latent Semantic Alignment" — 텍스트를 고차원 수치 벡터로 변환하고, 벡터 공간에서의 거리(코사인 유사도 등)를 측정하여 언어의 모호함(동의어, 문맥 등)을 해결하며 정답에 접근하는 패턴.
|
||||
- **핵심 구성 요소:**
|
||||
- **Embeddings:** 단어/문장의 의미를 숫자의 나열로 변환.
|
||||
- **Vector Database:** 수백만 개의 벡터 중 유사한 것을 초고속으로 탐색.
|
||||
- **Re-ranking:** 초기 검색 결과를 정교한 모델로 다시 순위 매기기.
|
||||
- **의의:** "아이폰 충전기"를 검색했을 때 "라이트닝 케이블"을 보여줄 수 있는 유연함을 제공하며, 정보 검색의 패러다임을 '단어' 중심에서 '개념' 중심으로 전환함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 시맨틱 검색이 키워드 검색(BM25 등)을 완전히 대체할 것이라는 예상과 달리, 최근에는 고유 명사나 정확한 수치 검색에 강한 키워드 방식과 맥락에 강한 시맨틱 방식을 결합한 '하이브리드 검색(Hybrid Search)'이 표준으로 자리 잡음.
|
||||
- **정책 변화:** Antigravity 프로젝트는 1,174개 지식 문서 간의 연관 관계 분석 및 사용자 질의 응답 시, 최신 리랭킹 알고리즘이 적용된 시맨틱 검색 엔진을 주력으로 활용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Natural-Language-Processing-NLP]], [[Vector-Database-Foundations]], [[RAG-and-Document-Retrieval]], [[Relevance-Feedback]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Semantic-Search-with-AI.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: NLP-SENT-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, nlp, sentiment-analysis, text-mining, opinion-mining, emotion-detection, customer-insights]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Sentiment Analysis Models (감성 분석 모델)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "언어의 행간에 숨겨진 감정의 파동을 읽어내고, 텍스트 뒤에 숨은 화자의 '진심'과 '태도'를 정량적인 수치로 번역하라" — 자연어 처리 기술을 활용하여 텍스트에 포함된 주관적인 의견, 감정, 태도를 자동으로 추출하고 분류하는 기술.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Subjective Polarity Scoring and Aspect-based Evaluation" — 긍정/부정의 이진 분류를 넘어 특정 대상(Aspect)에 대한 세부 감정을 분석하고, 비유나 반어법 같은 복잡한 언어 장치를 문맥 임베딩을 통해 파악하는 패턴.
|
||||
- **주요 분석 기법:**
|
||||
- **Rule-based (VADER 등):** 감정 단어 사전(Lexicon)을 기반으로 점수 합산.
|
||||
- **Machine Learning:** SVM, Naive Bayes 등을 이용한 통계적 분류.
|
||||
- **Deep Learning (BERT/GPT):** 문장 전체의 맥락을 파악하여 미묘한 감정선 변화 감지.
|
||||
- **Aspect-based (ABSA):** "성능은 좋은데 가격이 비싸다"처럼 대상별로 감정 분리 분석.
|
||||
- **의의:** 브랜드 평판 관리, 시장 트렌드 파악, 고객 불만 실시간 대응 등 기업이 소비자의 '목소리'를 데이터로 이해하게 만드는 핵심 도구.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단순히 단어의 긍/부정만 따지던 방식에서 벗어나, 이제는 화자의 사회적 배경, 유머, 냉소적 표현까지 파악하는 '멀티모달(텍스트+음성+표정)' 감성 분석으로 확장되고 있음.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트와 사용자 간의 대화 흐름에서 사용자의 피드백 톤을 실시간 분석하여, 답변의 공감 수준이나 지원 강도를 동적으로 조절하는 감성 인지 로직을 가동함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Natural-Language-Processing-NLP]], [[Representation-Learning]], [[Semantic-Search-with-AI]], [[Prompt-Engineering-Foundations]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Sentiment-Analysis-Models.md]]
|
||||
@@ -1,28 +1,28 @@
|
||||
---
|
||||
id: SEQ2SEQ-001
|
||||
id: DL-SEQ2SEQ-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, nlp, seq2seq, encoder-decoder, deep-learning]
|
||||
tags: [ai, deep-learning, nlp, seq2seq, encoder-decoder, machine-translation, neural-networks]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Sequence-to-Sequence Models (Seq2Seq)]]
|
||||
# [[Sequence-to-Sequence Models (Seq2Seq 모델)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "시퀀스를 이해하고, 또 다른 시퀀스로 재구성하라" — 입력된 가변 길이의 시퀀스를 고정된 벡터로 압축(Encoder)한 뒤, 이를 바탕으로 다시 가변 길이의 결과 시퀀스를 생성(Decoder)해내는 아키텍처.
|
||||
> "입력 시퀀스의 모든 정보를 하나의 고정된 '생각의 압축(Context Vector)'에 담고, 이를 해체하여 전혀 다른 새로운 시퀀스로 재구성하라" — 입력과 출력의 길이가 다른 시퀀스 변환 문제를 해결하기 위해 고안된 인코더-디코더 구조의 신경망 모델.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 입-출력의 길이가 달라도 문맥을 보존하며 데이터를 변환할 수 있게 하는 인코더-디코더 매핑 패턴.
|
||||
- **세부 내용:**
|
||||
- **Encoder:** 입력 시퀀스의 정보를 요약하여 문맥 벡터(Context Vector) 생성.
|
||||
- **Decoder:** 문맥 벡터를 초기값으로 받아 한 토큰씩 결과 생성.
|
||||
- **RNN-based Origins:** 초기에는 LSTM이나 GRU를 기반으로 설계되었으나, 현재는 트랜스포머가 주류.
|
||||
- **Applications:** 기계 번역, 요약, 챗봇, 음성 인식 등 대다수의 생성형 태스크.
|
||||
- **추출된 패턴:** "Information Compression and Generative Decoding" — 입력 데이터를 순차적으로 읽어 전체 문맥을 고정된 크기의 벡터로 요약하고, 이를 시작점으로 하여 정답 시퀀스를 한 단어씩 생성해 나가는 패턴.
|
||||
- **핵심 구성:**
|
||||
- **Encoder:** 입력 시퀀스(예: 한국어)를 처리하여 은닉 상태(Hidden State)로 정보를 응축.
|
||||
- **Decoder:** 응축된 정보로부터 대상 시퀀스(예: 영어)를 차례대로 생성.
|
||||
- **Context Vector:** 인코더와 디코더를 잇는 지식의 병목이자 연결고리.
|
||||
- **의의:** 구글 번역기 등에 도입되며 기계 번역의 정확도를 비약적으로 향상시켰으며, 요약, 챗봇, 음성 인식 등 다양한 시퀀스 변환 작업의 표준 아키텍처로 자리 잡음.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 고정된 크기의 '문맥 벡터' 하나에 모든 정보를 담으려다 정보가 소실되는 병목 현상이 발생. 이를 해결하기 위해 '어텐션(Attention)' 기법이 도입되며 현대 AI의 폭발적 성장을 견인함.
|
||||
- **정책 변화:** Antigravity 프로젝트의 '코드 요약 에이전트'는 Seq2Seq 원리를 활용하여 복잡한 소스 코드를 간결한 자연어 위키 문서로 변환함.
|
||||
- **과거 데이터와의 충돌:** 긴 문장일수록 정보를 하나의 벡터에 다 담지 못해 성능이 급격히 떨어지는 '정보 손실' 문제에 직면했으나, 이를 해결하기 위해 필요한 부분만 골라 보는 '어텐션(Attention)' 기법이 추가되면서 현대 트랜스포머 모델의 시조가 됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 서로 다른 데이터 형식 간의 자동 변환이나 프로토콜 번역 작업 시, 구조적 안정성이 검증된 인코더-디코더 기반의 Seq2Seq 아키텍처를 활용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Encoder-Decoder-Architecture]], [[Transformer-Architecture]], [[NLP]], [[Attention-Mechanisms]]
|
||||
- [[Natural-Language-Processing-NLP]], [[Recurrent-Neural-Networks-RNN]], [[Self-Attention-Mechanisms]], [[LLM-Training-Foundations]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Sequence-to-Sequence-Models.md]]
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
id: SYS-SERVERLESS-AI-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, infrastructure, serverless, cloud-computing, faas, aws-lambda, scalability, mlops]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Serverless Computing for AI (AI를 위한 서버리스 컴퓨팅)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "서버 관리의 짐을 클라우드에 넘기고 오직 '모델의 추론'에만 집중하며, 호출된 만큼만 비용을 지불하는 가장 경제적이고 유연한 지능형 인프라를 구축하라" — 인프라 구성이나 관리 없이 코드(함수) 단위로 AI 모델을 실행하고, 요청량에 따라 자원이 자동으로 할당되는 클라우드 컴퓨팅 모델.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Event-driven Inference and Pay-per-invocation" — 서버를 상시 가동하는 대신 특정 이벤트(API 호출, 데이터 업로드 등)가 발생할 때만 컨테이너를 띄워 AI 연산을 수행하고 즉시 자원을 반납하는 효율성 중심의 운영 패턴.
|
||||
- **주요 특징 및 장점:**
|
||||
- **No Server Management:** 패치, 업데이트, 용량 계획 등 운영 부담 전무.
|
||||
- **Elastic Scalability:** 수천 개의 동시 요청에도 자동 확장(Auto-scaling) 대응.
|
||||
- **Cost Efficiency:** 실행 시간과 메모리 사용량에 대해서만 비용 청구.
|
||||
- **한계점:**
|
||||
- **Cold Start:** 오랜만에 실행할 때 발생하는 초기 지연 시간.
|
||||
- **Execution Limits:** 실행 시간 및 메모리 용량의 제한.
|
||||
- **의의:** 스타트업이나 개인 개발자가 대규모 인프라 투자 없이도 전 세계 사용자에게 AI 서비스를 안정적으로 제공할 수 있는 진입 장벽의 혁신.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 초기에는 가벼운 웹 요청 처리용으로만 여겨졌으나, 최근에는 GPU 지원 서버리스 서비스와 컨테이너 기반 서버리스(Knative 등)의 등장으로 무거운 딥러닝 모델 추론도 서버리스 환경에서 활발히 이루어지고 있음.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 간헐적인 데이터 전처리 및 배치 분석 작업 시, 비용 최적화를 위해 서버리스 아키텍처를 우선적으로 활용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Scalability-in-AI-Systems]], [[Cloud-Computing-Foundations]], [[Service-oriented-Architecture]], [[Optimization-in-AI]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Serverless-Computing-for-AI.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: SYS-SOA-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [systems, architecture, soa, service-oriented, microservices, decoupling, interoperability]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Service-oriented Architecture (SOA, 서비스 지향 아키텍처)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "거대한 시스템을 독립적인 기능을 가진 '서비스'들의 집합으로 해체하고, 표준화된 통신(Interface)을 통해 이들이 유연하게 협력하게 하라" — 비즈니스 기능을 독립적인 서비스 단위로 쪼개어 네트워크상에서 서로 연동 가능하게 설계하는 소프트웨어 아키텍처 스타일.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Service Decoupling and Standardized Interoperability" — 각 서비스가 특정 기술에 종속되지 않고 공용 프로토콜(주로 SOAP나 REST)을 통해 대화하게 함으로써, 전체 시스템의 유연성과 재사용성을 극대화하는 패턴.
|
||||
- **핵심 원칙:**
|
||||
- **Loose Coupling:** 서비스 간의 의존성을 최소화하여 개별 업데이트 용이.
|
||||
- **Service Contract:** 서비스가 제공하는 기능과 입출력 형식을 명확히 정의.
|
||||
- **Reusability:** 하나가 만든 기능을 다른 여러 서비스에서 호출하여 중복 제거.
|
||||
- **Composability:** 작은 서비스들을 조합하여 더 큰 비즈니스 로직 완성.
|
||||
- **의의:** 90년대 중반부터 현대 마이크로서비스 아키텍처(MSA)의 철학적 모태가 되었으며, 복잡한 엔터프라이즈 시스템을 관리 가능한 수준으로 유지하는 데 결정적인 역할을 함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 중앙 집중형 서비스 버스(ESB)를 사용하는 무거운 SOA 방식에서, 이제는 가벼운 API 게이트웨이와 메시지 브로커 중심의 민첩한 마이크로서비스 방식으로 진화하며 '서비스 지향'의 본질은 계승하고 구현의 복잡도는 낮추는 방향으로 발전함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 각 기능(검색, 생성, 검증 등)을 독립적인 서비스 모듈로 설계하여, 필요에 따라 개별적으로 확장하거나 교체할 수 있는 SOA의 유연성 원칙을 고수함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Microservices-Foundations]], [[Scalability-in-AI-Systems]], [[Software-Architecture-Patterns]], [[API-Design-Principles]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Service-oriented-Architecture.md]]
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: SYS-OBS-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [systems, observability, shadowing, monitoring, mlops, distributed-tracing, reliability]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Shadowing and Observability (섀도잉 및 관측성)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "사용자 모르게 실제 트래픽의 복사본으로 모델의 담력을 시험(Shadowing)하고, 시스템 내부의 모든 신호를 투명하게 기록하여 장애의 징후를 선제적으로 포착하라" — 운영 환경에 영향을 주지 않는 안전한 테스트 기법과 시스템의 동작 상태를 정밀하게 파악하기 위한 관측 체계.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Risk-free Validation and Transparent Monitoring" — 새로운 모델이나 코드를 배포할 때 실제 트래픽을 병렬로 흘려보내 결과를 비교 검증하고, 메트릭/로그/트레이싱의 3대 요소를 결합해 장애의 원인을 즉각 규명하는 패턴.
|
||||
- **핵심 요소:**
|
||||
- **Shadow Deployment:** 운영 서비스 결과는 무시하고 새 모델의 예측값만 기록하여 성능 비교. 리스크 없는 실전 테스트 가능.
|
||||
- **Observability (Three Pillars):**
|
||||
- **Metrics:** 수치화된 지표 (CPU 사용량, Latency 등).
|
||||
- **Logs:** 발생한 사건의 상세 기록.
|
||||
- **Tracing:** 서비스 간의 호출 경로 추적 (Distributed Tracing).
|
||||
- **의의:** 복잡해진 마이크로서비스 환경에서 "무슨 일이 일어났는가"를 넘어 "왜 일어났는가"에 대한 답을 제공하며, 배포의 두려움을 데이터 기반의 확신으로 바꿈.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단순히 서버가 죽었는지만 체크하던 '모니터링'의 시대를 지나, 이제는 분산 시스템 전체의 맥락을 이해하고 예상치 못한 문제(Unknown-Unknowns)를 탐사하는 '관측성' 중심의 엔지니어링으로 패러다임이 이동함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 답변 생성 모델 업데이트 시, 최소 24시간의 섀도잉 기간을 거쳐 기존 모델과의 응답 품질 차이를 정밀 분석한 후 최종 배포를 결정함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Scalability-in-AI-Systems]], [[Service-oriented-Architecture]], [[Reliability-Engineering]], [[MLOps-Best-Practices]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Shadowing-and-Observability.md]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: CV-SHAPE-FEAT-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, computer-vision, feature-extraction, image-processing, shape-analysis, pattern-recognition]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Shape Feature Extraction (형상 특징 추출)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "색상과 픽셀의 소음에서 벗어나 사물의 본질적인 '실루엣'과 '기하학적 질서'를 추출하여, 어떤 환경에서도 변하지 않는 형상의 정체성을 정의하라" — 이미지 내 객체의 형태적 특성을 수치화하여 분류, 인식, 매칭 등에 활용하는 컴퓨터 비전의 핵심 공정.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Geometric Invariance and Contour Description" — 물체의 크기가 변하거나 회전해도 일정하게 유지되는 불변 특징(Invariant Features)을 찾기 위해, 윤곽선(Contour)의 좌표 변화나 내부 픽셀의 모멘트(Moment) 분포를 분석하는 패턴.
|
||||
- **주요 기법:**
|
||||
- **Boundary-based:** 윤곽선의 길이, 곡률, 푸리에 기술자(Fourier Descriptors) 등을 통한 경계선 분석.
|
||||
- **Region-based:** 객체 내부 면적, 중심점, Hu-Moments 등을 통한 영역 특성 분석.
|
||||
- **HOG (Histogram of Oriented Gradients):** 픽셀 기울기의 방향을 밀집된 벡터로 표현 (사람 인식 등에 탁월).
|
||||
- **의의:** 문자 인식(OCR), 부품 결함 검사, 동작 인식 등 사물의 정확한 형태적 구분이 필요한 분야에서 딥러닝 모델의 성능을 보완하거나 강력한 베이스라인을 제공함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 사람이 직접 수학적 수식을 설계하던 방식에서, 이제는 컨볼루션 신경망(CNN)이 층을 거듭하며 복잡한 형상 특징을 스스로 학습하는 방식으로 발전했으나, 기하학적 엄밀함이 필요한 정밀 계측 분야에서는 여전히 고전적인 형상 추출 기법이 병행됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 비전 에이전트의 물체 인식 로직 설계 시, 연산 자원이 제한된 환경에서도 안정적인 형태 파악을 위해 경량화된 형상 특징 추출 알고리즘을 우선 적용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Computer-Vision-Fundamentals]], [[Representation-Learning]], [[Optical-Character-Recognition-OCR]], [[Deep-Learning-Foundations]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Shape-Feature-Extraction.md]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: SYS-SHARD-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [database, systems, scalability, sharding, partitioning, distributed-systems, big-data]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Sharding and Partitioning (샤딩 및 파티셔닝)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "거대한 지식의 덩어리를 전략적인 기준(Key)에 따라 조각내어 분산하고, 병렬 처리를 통해 단일 서버의 한계를 넘어 무한한 확장의 길을 열어라" — 대규모 데이터를 효율적으로 관리하기 위해 데이터베이스를 수평적 혹은 수직적으로 분할하여 저장하고 처리하는 최적화 기법.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Data Fragmentation and Distributed Load Balancing" — 하나의 거대한 테이블을 여러 서버(Sharding)나 동일 서버 내 여러 논리적 단위(Partitioning)로 쪼개어, 전체 데이터를 조회하지 않고 필요한 조각에만 접근하여 응답 속도를 비약적으로 높이는 패턴.
|
||||
- **핵심 구분:**
|
||||
- **Vertical Partitioning:** 테이블의 컬럼을 기준으로 쪼개기. 자주 쓰이는 데이터와 아닌 데이터를 분리.
|
||||
- **Horizontal Partitioning (Sharding):** 행(Row)을 기준으로 쪼개어 서로 다른 서버에 분산 저장.
|
||||
- **Sharding Key:** 데이터를 나누는 기준값. 데이터가 특정 서버에 쏠리지 않도록 고르게 분산시키는 것이 핵심.
|
||||
- **의의:** 서비스가 폭발적으로 성장해도 인프라를 증설하여 대응할 수 있는 '수평적 확장성(Horizontal Scalability)'의 기술적 근간.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 샤딩은 데이터 정합성 유지와 조인(Join) 연산이 극도로 어렵다는 단점이 있었으나, 최근에는 '분산 SQL DB(CockroachDB, Spanner 등)'의 등장으로 애플리케이션 수준의 복잡도 없이 자동화된 샤딩과 정합성을 동시에 보장하는 방향으로 발전함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 대규모 지식 노드와 벡터 임베딩 데이터를 저장할 때, 검색 빈도와 문서 카테고리를 고려한 동적 샤딩 전략을 통해 글로벌 검색 지연 시간을 최소화함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Scalability-in-AI-Systems]], [[Schema-Design-for-NoSQL]], [[Relational-Databases]], [[High-Availability-Systems]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Sharding-and-Partitioning.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: MATH-SIG-PROC-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [math, engineering, signal-processing, fourier-transform, sampling-theorem, filtering, digital-signal]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Signal Processing Foundations (신호 처리 기초)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "현실의 혼란스러운 아날로그 파동에서 불필요한 노이즈를 걷어내고, 지능이 이해할 수 있는 순수한 '정보의 정수'를 디지털 숫자로 추출하라" — 물리적 세계의 신호를 수학적으로 조작하여 정보의 품질을 높이거나 핵심 특징을 분석하는 공학적 토대.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Analog-to-Digital Conversion and Frequency Domain Transformation" — 연속적인 신호를 일정한 간격으로 샘플링(Sampling)하여 디지털화하고, 시간축의 데이터를 주파수축으로 변환하여 눈에 보이지 않던 숨겨진 패턴과 주기성을 찾아내는 패턴.
|
||||
- **핵심 이론:**
|
||||
- **Sampling Theorem (Nyquist):** 원신호를 완벽히 복원하기 위해 원래 최고 주파수의 2배 이상으로 샘플링해야 한다는 원칙.
|
||||
- **Fourier Transform:** 복잡한 신호를 단순한 정현파들의 합으로 분해하여 주파수 성분을 분석.
|
||||
- **Filtering:** 고주파(Low-pass)나 저주파(High-pass) 등 특정 대역의 신호만을 통과시켜 노이즈 제거.
|
||||
- **Convolution:** 두 신호를 결합하여 특징을 강조하거나 시스템의 응답 확인 (CNN의 수학적 근간).
|
||||
- **의의:** 음성 인식, 이미지 처리, 통신, 센서 데이터 분석 등 현대의 모든 디지털 문명과 AI가 '세상을 감각하는 법'에 대한 절대적 기초 지식.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 사람이 수동으로 필터 계수를 설계하던 방식에서, 이제는 신경망이 학습 데이터로부터 최적의 신호 처리 방식(예: CNN의 필터 커널)을 직접 찾아내는 '데이터 기반 신호 처리'로 지평이 넓어짐.
|
||||
- **정책 변화:** Antigravity 프로젝트는 오디오 에이전트의 입력 신호 처리 시, 배경 소음을 효과적으로 억제하고 화자의 음성 특징만을 극대화하기 위해 표준 디지털 신호 처리(DSP) 라이브러리와 딥러닝 전처리를 병행함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Natural-Language-Processing-NLP]], [[Computer-Vision-Fundamentals]], [[Scientific-Computing-with-Python]], [[Convolutional-Neural-Networks-CNN]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Signal-Processing-Foundations.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: AI-MET-SIM-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, machine-learning, similarity-metrics, cosine-similarity, euclidean-distance, jaccard-similarity, vector-space]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Similarity Metrics in AI (AI에서의 유사도 메트릭)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터를 고차원 벡터의 좌표로 변환하고, 그들 사이의 '거리'와 '각도'를 측정하여 보이지 않는 의미적 유사성을 수치화하라" — 두 데이터 객체가 서로 얼마나 닮았는지 정량적으로 측정하기 위한 수학적 척도들의 총합.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Vector Distance and Semantic Proximity" — 텍스트, 이미지, 사용자 행동 등을 수치 벡터로 투영하고, 선택한 메트릭에 따라 기하학적 거리를 계산하여 분류, 클러스터링, 추천 등에 활용하는 패턴.
|
||||
- **주요 유사도 메트릭:**
|
||||
- **Cosine Similarity:** 두 벡터 사이의 각도 측정. 벡터의 크기보다 '방향(의미)'이 중요할 때(예: 텍스트 분석) 최적.
|
||||
- **Euclidean Distance:** 두 점 사이의 직선 거리. 데이터의 물리적 수치 차이가 중요할 때 사용.
|
||||
- **Jaccard Similarity:** 두 집합 사이의 겹침 정도 측정. 키워드 공유 여부 분석에 용이.
|
||||
- **Manhattan Distance:** 격자 구조에서의 거리. 고차원 데이터에서 유클리드 거리의 한계를 보완할 때 사용.
|
||||
- **의의:** 시맨틱 검색, 추천 시스템, 중복 데이터 제거 등 현대 AI 서비스의 거의 모든 '비교' 로직의 핵심 수학적 근간.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단순히 거리가 가까우면 비슷하다는 가정을 넘어, 이제는 데이터의 분포와 밀도를 고려한 마할라노비스 거리(Mahalanobis Distance)나 학습된 신경망 기반의 유사도 측정(Deep Metric Learning)이 복잡한 데이터 분석의 표준이 됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 지식 문서 간의 연관 관계 산출 시, 문맥적 의미 보존율이 높은 코사인 유사도를 기본 메트릭으로 채택하며 필요에 따라 리랭킹 모델을 병행함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Semantic-Search-with-AI]], [[Vector-Database-Foundations]], [[Recommendation-Systems]], [[Cluster-Analysis-Techniques]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Similarity-Metrics-in-AI.md]]
|
||||
@@ -1,27 +1,28 @@
|
||||
---
|
||||
id: ANNEAL-001
|
||||
id: MATH-OPT-SA-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [optimization, algorithm, heuristics, statistical-mechanics]
|
||||
tags: [math, optimization, simulated-annealing, heuristics, global-optimum, algorithm, stochastic-process]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Simulated Annealing (시뮬레이션 어닐링)]]
|
||||
# [[Simulated Annealing (시뮬레이티드 어닐링)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "지역 최적해에서 벗어나기 위해 때로는 '모험'을 허용하라" — 금속을 뜨겁게 달구었다가 천천히 식히며 결정 구조를 안정화시키는 담금질(Annealing) 과정을 모방하여, 확률적으로 더 나쁜 해를 수용함으로써 전역 최적해를 찾아가는 확률적 탐색 알고리즘.
|
||||
> "초기에는 뜨거운 열기(Randomness)로 지역적 최적해의 함정을 뛰어넘고, 서서히 식어가는 지혜(Cooling Schedule)를 통해 전역 최적해라는 완벽한 결정체를 형성하라" — 금속 공학의 담금질 원리를 모방하여, 복잡한 탐색 공간에서 지역 최적해(Local Optima)를 탈출하고 전역 최적해(Global Optimum)를 찾기 위한 확률적 최적화 기법.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 초기에는 높은 '온도(Probability)'를 유지하여 탐색 공간을 넓게 훑고, 시간이 지남에 따라 온도를 낮추며 현재 위치 근처에서 정교하게 수렴하는 전역 최적화 패턴.
|
||||
- **세부 내용:**
|
||||
- **Metropolis Criterion:** 현재보다 좋지 않은 해라도 특정 확률($e^{-\Delta E / T}$)로 수용하여 지역 최적해(Local Optima) 탈출 유도.
|
||||
- **Cooling Schedule:** 온도를 낮추는 속도와 방식 정의. 너무 빠르면 지역 최적해에 갇히고, 너무 느리면 연산 비용 과다 발생.
|
||||
- **Combinatorial Optimization:** 외판원 문제(TSP)나 회로 설계 등 탐색 공간이 방대하고 불연속적인 문제에서 강력한 성능 발휘.
|
||||
- **추출된 패턴:** "Stochastic Exploration and Gradual Convergence" — 현재보다 좋지 않은 해(Solution)라도 온도($T$)에 따른 특정 확률로 수용함으로써 탐색의 범위를 넓히고, 시간이 흐름에 따라 온도를 낮춰 점점 정교하게 정답에 안착하는 패턴.
|
||||
- **핵심 메커니즘:**
|
||||
- **Temperature ($T$):** 탐색의 무작위성을 결정하는 변수. 초기에 높고 서서히 낮아짐.
|
||||
- **Metropolis Criterion:** 나쁜 해를 수용할 확률 $P = \exp(-\Delta E / T)$. 온도가 높을수록, 오차가 작을수록 나쁜 해를 더 잘 받아들임.
|
||||
- **Cooling Schedule:** 온도를 얼마나 빨리 식힐지 결정하는 함수. 학습의 성패를 좌우함.
|
||||
- **의의:** 수학적으로 해를 구하기 어려운 조합 최적화 문제(예: TSP)나 매우 복잡한 손실 함수를 가진 모델 학습에서 전역적인 시야를 유지하게 해주는 강력한 메타휴리스틱 도구.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 미분이 가능한 공간에서의 경사 하강법에 비해 속도는 느리지만, 미분이 불가능하거나 매우 불규칙한 에너지 지형을 가진 문제에서 여전히 독보적인 유연성을 가짐.
|
||||
- **정책 변화:** Antigravity 프로젝트의 자원 할당 최적화 및 복잡한 워크플로우 스케줄링 시, 시뮬레이션 어닐링 알고리즘을 사용하여 최적의 배치 조합을 산출함.
|
||||
- **과거 데이터와의 충돌:** 연산 속도가 느리다는 단점 때문에 경사 하강법(Gradient Descent)에 밀리는 듯했으나, 경사 정보를 알 수 없는 비연속적 공간이나 강화학습의 하이퍼파라미터 최적화 등에서 여전히 대체 불가능한 가치를 발휘함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 작업 스케줄링 최적화나 복잡한 지식 그래프의 클러스터링 초기값 설정 시, 지역 최적해 함정을 피하기 위해 시뮬레이티드 어닐링의 확률적 탐색 로직을 적용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Optimization]], [[Genetic-Algorithms]], [[Stochastic-Gradient-Descent]], [[Statistical-Mechanics]]
|
||||
- [[Optimization-Algorithms]], [[Randomized-Algorithms]], [[Reinforcement-Learning]], [[Algorithm-Complexity-Analysis]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Simulated-Annealing.md]]
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: AI-SIM-ENV-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, reinforcement-learning, simulation, digital-twin, physics-engine, unity, mujoco, sim-to-real]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Simulation Environments (시뮬레이션 환경)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "현실의 물리 법칙을 디지털 코드로 재구성한 '안전한 우주'를 창조하고, 수백만 번의 시행착오를 빛의 속도로 반복시켜 지능의 진화를 가속하라" — 인공지능 에이전트가 학습하고 평가받을 수 있도록 설계된 가상의 물리적 혹은 논리적 상호작용 공간.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Risk-free Iteration and Parallel Experience Collection" — 실제 하드웨어나 환경의 파손 없이 극단적인 상황까지 테스트하고, 여러 시뮬레이션을 동시에 돌려 방대한 학습 데이터를 단시간에 수집하는 패턴.
|
||||
- **핵심 구성 및 도구:**
|
||||
- **Physics Engines:** MuJoCo, PyBullet, PhysX 등 중력, 마찰력 등 물리 현상 계산.
|
||||
- **RL Frameworks:** OpenAI Gym(Gymnasium), Unity ML-Agents 등 표준화된 인터페이스 제공.
|
||||
- **Digital Twins:** 실제 공장이나 도시를 그대로 가상화하여 정밀한 예측 수행.
|
||||
- **의의:** 자율주행, 로보틱스, 드론 제어 등 현실 세계의 위험이 큰 분야에서 AI가 상용화되기 전 반드시 거쳐야 하는 '지능의 검증 센터' 역할.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 가상은 가상일 뿐이라는 'Sim-to-Real Gap' 문제로 비판받았으나, 최근에는 가상 환경에 의도적인 노이즈를 섞는 'Domain Randomization'과 정교한 시스템 식별 기술을 통해 시뮬레이션에서 배운 지식을 현실에 즉각 적용하는 수준까지 발전함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 새로운 에이전트 알고리즘 배포 전, 다양한 시나리오가 설정된 시뮬레이션 환경에서의 벤치마크 테스트 통과를 필수 품질 게이트로 설정함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Reinforcement-Learning]], [[Robotics-Foundations]], [[Self-Driving-Car-Foundations]], [[Reward-Shaping-in-RL]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Simulation-Environments.md]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: MATH-LA-SVD-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [math, linear-algebra, svd, dimensionality-reduction, pca, recommendation-systems, matrix-factorization]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Singular Value Decomposition (SVD, 특이값 분해)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "복잡한 데이터 행렬을 본질적인 에너지(특이값)의 순서대로 해체하고, 사소한 노이즈를 걷어내어 데이터가 숨기고 있던 '핵심 구조'만을 선명하게 드러내라" — 임의의 행렬을 세 개의 특수한 행렬($U, \Sigma, V^T$)의 곱으로 분해하여 데이터의 특징 추출 및 차원 축소에 활용하는 강력한 선형대수학 기법.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Energy-based Rank Reduction and Latent Structure Discovery" — 행렬의 정보를 가장 잘 설명하는 방향(특이 벡터)과 그 중요도(특이값)를 산출하고, 작은 특이값들을 0으로 처리함으로써 데이터의 용량은 획기적으로 줄이면서 본질적인 정보는 보존하는 패턴.
|
||||
- **수학적 구성:** $A = U\Sigma V^T$
|
||||
- **$U$:** 왼쪽 특이 벡터 (행 사이의 관계/공간).
|
||||
- **$\Sigma$:** 특이값 (각 성분의 중요도/에너지 크기). 내림차순 정렬됨.
|
||||
- **$V^T$:** 오른쪽 특이 벡터 (열 사이의 관계/특징).
|
||||
- **의의:** 추천 시스템(사용자-아이템 취향 분석), 이미지 압축, 자연어 처리의 잠재 의미 분석(LSA) 등 데이터의 '숨은 의미'를 찾아야 하는 모든 곳의 수학적 표준.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 연산 복잡도가 높다는 단점으로 대규모 데이터셋 적용에 한계가 있었으나, 최근에는 Truncated SVD나 Randomized SVD 등 필요한 성분만 빠르게 뽑아내는 근사 기법들이 발전하여 빅데이터 환경에서도 핵심 도구로 쓰임.
|
||||
- **정책 변화:** Antigravity 프로젝트는 대규모 지식 관계망의 차원 축소 및 문서 간의 잠재적 유사성 탐색 시, 정보 손실을 최소화하면서 연산 효율을 높이는 SVD 기반의 알고리즘을 내부 라이브러리로 운용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Principal-Component-Analysis-PCA]], [[Dimensionality-Reduction-Strategies]], [[Recommendation-Systems]], [[Scientific-Computing-with-Python]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Singular-Value-Decomposition.md]]
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: BIZ-SIX-SIGMA-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [business, quality-management, six-sigma, dmaic, process-improvement, statistics, efficiency]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Six Sigma Methodologies (식스 시그마 방법론)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터라는 잣대로 프로세스의 변동성을 집요하게 추적하고, 백만 분의 3.4라는 극한의 정밀도(Zero Defect)를 향해 모든 낭비와 오류를 제거하라" — 통계적 기법을 활용하여 비즈니스 프로세스의 결함을 찾아내고 원인을 제거하여 품질을 획기적으로 개선하는 경영 전략.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Standardized Quality Control and Variance Minimization" — 주관적 판단이 아닌 객관적 데이터에 근거하여 문제의 근본 원인을 파악하고, 표준화된 5단계 절차(DMAIC)를 반복하여 프로세스의 안정성을 확보하는 패턴.
|
||||
- **핵심 프로세스 (DMAIC):**
|
||||
- **Define:** 고객의 요구사항을 바탕으로 문제와 프로젝트 목표 정의.
|
||||
- **Measure:** 현재 프로세스의 성능을 측정하고 신뢰할 수 있는 데이터 수집.
|
||||
- **Analyze:** 결함의 근본 원인을 통계적으로 분석.
|
||||
- **Improve:** 원인을 제거하고 최적의 개선안 실행.
|
||||
- **Control:** 개선된 성과가 유지되도록 모니터링 및 표준화.
|
||||
- **의의:** 기업 운영의 모든 과정을 '수치'로 관리하게 함으로써 효율성을 극대화하고, 불필요한 비용(Cost of Poor Quality)을 줄여 비즈니스의 경쟁력을 강화함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 제조 현장의 전유물로 여겨졌으나, 이제는 소프트웨어 개발(Agile Six Sigma)이나 AI 모델의 추론 정확도 관리 등 높은 신뢰성이 요구되는 지식 서비스 분야에서도 프로세스 혁신의 도구로 널리 활용됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 지식 자산의 보강 및 검수 프로세스에 식스 시그마의 DMAIC 철학을 투영하여, 작업의 변동성을 줄이고 일관된 Karpathy Summary 품질을 유지하는 품질 관리 체계를 운용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Operations-Management-Foundations]], [[Process-Automation-with-AI]], [[Performance-Metrics-in-AI]], [[Risk-Assessment-with-AI]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Six-Sigma-Methodologies.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: DEV-SLACK-BOT-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [development, automation, slack, chatbot, slack-api, webhook, bot-development, collaboration]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Slack Bot Development (슬랙 봇 개발)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "협업의 중심지인 슬랙에 '지능형 에이전트'를 상주시켜, 번거로운 반복 작업을 자동화하고 팀의 생산성을 실시간으로 가속하라" — 슬랙 API를 활용하여 사용자의 메시지에 응답하거나 이벤트를 감지하여 특정 작업을 수행하는 자동화 프로그램 개발 기법.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Event-driven Interaction and Workflow Integration" — 슬랙의 이벤트 API(가입, 메시지 등)를 수신하고, 봇 토큰(Bot Token)을 사용해 채널에 응답하거나 인터랙티브 버튼/모달을 통해 사용자 입력을 받아 업무 워크플로우를 자동화하는 패턴.
|
||||
- **주요 구성 요소:**
|
||||
- **Slack API:** Web API (봇이 메시지 전송), Events API (슬랙 내 사건 감지).
|
||||
- **Socket Mode:** 복잡한 방화벽 설정 없이 로컬에서도 봇을 테스트할 수 있는 통신 방식.
|
||||
- **App Home:** 사용자별 맞춤 정보를 보여주는 봇 전용 공간.
|
||||
- **Slash Commands:** `/`로 시작하는 명령어를 통한 서비스 호출.
|
||||
- **의의:** 알림 모니터링, 승인 프로세스 자동화, 사내 데이터 조회 등 파편화된 업무 툴들을 채팅창 안으로 통합하여 소통 비용을 획기적으로 절감함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단순히 메시지만 주고받던 초기 형태에서 벗어나, 이제는 거대 언어 모델(LLM)과 결합하여 복잡한 질문에 답하고 코드를 작성하거나 회의록을 요약해주는 'AI 비서' 수준의 지능형 봇으로 진화함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 가드닝 진행 상황 및 장애 알림을 실시간으로 팀에 공유하기 위해, 프로젝트 전용 슬랙 봇을 구축하여 운영 효율을 극대화함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Process-Automation-with-AI]], [[Natural-Language-Processing-NLP]], [[API-Design-Principles]], [[Shadowing-and-Observability]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Slack-Bot-Development.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: SEC-BC-AUDIT-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [blockchain, security, smart-contract, auditing, ethereum, solidity, cybersecurity, web3]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Smart Contract Auditing (스마트 컨트랙트 감사)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "수정 불가능한 코드(Immutability)의 무게를 견디기 위해, 배포 전 단 한 점의 논리적 틈새도 허용하지 않는 철저한 검증으로 디지털 자산의 안전을 담보하라" — 블록체인상에 구현된 스마트 컨트랙트의 취약점, 버그, 논리적 결함을 분석하여 해킹 사고를 예방하는 보안 검증 공정.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Multi-layered Vulnerability Scanning and Logical Verification" — 자동화된 정적 분석 도구로 알려진 보안 패턴(재진입 공격, 가스 리미트 등)을 검출하고, 전문가의 수동 리뷰를 통해 비즈니스 로직의 모순을 찾아내며, 수학적 형식 검증으로 모든 경우의 수에 대한 안전성을 입증하는 패턴.
|
||||
- **주요 감사 단계:**
|
||||
- **Automated Scanning:** Slither, Mythril 등을 활용한 빠른 취약점 탐지.
|
||||
- **Manual Code Review:** 코드의 의도와 실제 구현 사이의 괴리 분석.
|
||||
- **Economic Analysis:** 토큰 이코노미나 거버넌스 공격 가능성 검토.
|
||||
- **Formal Verification:** 수학적 모델링을 통해 계약 조건의 완벽성 증명.
|
||||
- **의의:** DeFi, NFT 등 거대한 자본이 흐르는 Web3 생태계에서 사용자 신뢰를 얻기 위한 필수 관문이며, 코드의 실수가 돌이킬 수 없는 자산 손실로 이어지는 것을 막는 최후의 방어선.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 사람이 일일이 코드를 보던 방식에서, 이제는 AI 기반의 스마트 컨트랙트 분석기가 실시간으로 새로운 공격 패턴을 학습하고 감지하며 인간 감사자의 직관과 도구의 정밀함이 결합된 하이브리드 감사 방식으로 진화함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 향후 지식 자산의 소유권이나 에이전트 간 보상 체계를 블록체인화할 경우, 배포 전 반드시 공인된 외부 감사를 거치는 'Security-First' 배포 프로토콜을 준수함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Security-Best-Practices]], [[Trustworthy-AI]], [[Risk-Assessment-with-AI]], [[Software-Architecture-Patterns]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Smart-Contract-Auditing.md]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: SYS-DATA-WARE-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [database, data-warehouse, snowflake, cloud-computing, big-data, data-analytics, saas]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Snowflake Data Warehousing (스노우플레이크 데이터 웨어하우징)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "저장과 연산을 분리하여 무한한 확장성을 확보하고, 복잡한 인프라 관리 없이 오직 '데이터의 가치'를 캐내는 분석에만 전념하라" — 클라우드 네이티브 아키텍처를 기반으로 설계된 완전 관리형(SaaS) 데이터 웨어하우징 서비스.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Separation of Storage and Compute with Multi-cluster Shared Data" — 데이터를 중앙 집중식 스토리지에 저장하되, 여러 개의 가상 웨어하우스(연산 엔진)가 이를 동시에 참조하며 독립적으로 자원을 사용하고 자동 확장(Auto-scaling)하는 패턴.
|
||||
- **핵심 아키텍처 3계층:**
|
||||
- **Database Storage:** 열 지향(Columnar) 방식으로 압축 저장되어 성능 최적화.
|
||||
- **Query Processing:** 독립적인 가상 웨어하우스들이 연산 수행. 서로 간섭 없음.
|
||||
- **Cloud Services:** 인증, 메타데이터 관리, 쿼리 최적화 등을 담당하는 뇌의 역할.
|
||||
- **의의:** 정형/반정형 데이터를 통합 관리하고 전 세계 어디서나 실시간으로 데이터를 공유(Data Sharing)할 수 있게 함으로써, 현대 기업의 데이터 민주화와 분석 속도를 획기적으로 향상시킴.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 초기에는 단순히 데이터 저장소로 여겨졌으나, 최근에는 'Snowpark'를 통해 파이썬, 자바 등 개발 언어로 데이터 파이프라인을 구축하고 ML 모델을 직접 실행하는 '데이터 클라우드' 플랫폼으로 진화함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 대규모 지식 활용 로그 및 사용자 행동 패턴을 장기간 보관하고 대규모 배치 분석을 수행할 때, 연산 자원 관리가 용이한 스노우플레이크의 아키텍처 철학을 참고하여 분석 파이프라인을 설계함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Relational-Databases]], [[NoSQL-Databases]], [[Scalability-in-AI-Systems]], [[Process-Automation-with-AI]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Snowflake-Data-Warehousing.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: DATA-SNA-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [data-science, social-network-analysis, graph-theory, centrality, community-detection, network-science, relationship-mapping]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Social Network Analysis (사회망 분석)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "개별 주체의 특성보다 그들 사이의 '연결 구조'에 주목하고, 네트워크 속에서 정보와 권력이 흐르는 지도(Map)를 파악하라" — 사회적 관계를 그래프 이론을 활용하여 구조적으로 분석하고, 노드 간의 상호작용 패턴을 밝혀내는 방법론.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Graph-based Structural Property and Influence Mapping" — 점(Node)과 선(Edge)으로 이루어진 복잡한 네트워크에서 특정 노드의 중심성(Centrality)을 계산하고, 밀집된 하위 집단을 찾아내어(Community Detection) 전체 시스템의 역학을 파악하는 패턴.
|
||||
- **핵심 분석 지표:**
|
||||
- **Degree Centrality:** 연결된 친구가 얼마나 많은가? (지역적 영향력)
|
||||
- **Betweenness Centrality:** 정보가 흐르는 길목을 얼마나 장악했는가? (중개자 역할)
|
||||
- **Closeness Centrality:** 다른 모든 노드에 얼마나 빨리 도달할 수 있는가? (접근성)
|
||||
- **PageRank:** 얼마나 영향력 있는 사람들로부터 연결되었는가? (권위도)
|
||||
- **의의:** 마케팅에서의 인플루언서 발굴, 조직 내 의사소통 병목 지점 파악, 범죄 네트워크 추적 등 '관계의 맥락'이 성과를 결정짓는 모든 분야의 핵심 도구.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 정적인 관계도 분석에서 벗어나, 이제는 시간에 따라 관계가 변하는 '동적 네트워크 분석'과 그래프 신경망(GNN)을 이용해 보이지 않는 관계를 예측하는(Link Prediction) AI 기반 분석으로 고도화됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 1,174개 지식 문서 간의 상호 참조 관계를 사회망 분석 기법으로 시각화하여, 어떤 지식이 프로젝트의 핵심 교차로(Core Knowledge)인지 식별하고 관리 우선순위를 정함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Ranking-Algorithms]], [[Graph-Theory-Foundations]], [[Cluster-Analysis-Techniques]], [[Recommendation-Systems]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Social-Network-Analysis.md]]
|
||||
@@ -1,29 +1,30 @@
|
||||
---
|
||||
id: ARCH-PAT-001
|
||||
id: SYS-ARCH-PAT-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [software-engineering, architecture, design-patterns, system-design]
|
||||
tags: [systems, architecture, software-engineering, design-patterns, microservices, layered-architecture, event-driven, scalability]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Software Architecture Patterns (소프트웨어 아키텍처 패턴)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "복잡한 시스템의 구조를 정형화된 틀로 관리하여 변경에 강한 지도를 그려라" — 소프트웨어 시스템의 기본 구조와 구성 요소 간의 상호작용 방식을 정의한 검증된 설계 청사진.
|
||||
> "코드를 작성하기 전에 지식과 기능의 '지도(Map)'를 먼저 그려라. 올바른 패턴 선택은 복잡성이라는 파도 앞에서 시스템을 지탱하는 가장 견고한 닻이 된다" — 소프트웨어 시스템의 구조적 문제를 해결하기 위해 반복적으로 사용되는 검증된 설계 원칙과 골격.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 시스템의 요구사항과 제약 조건에 따라 구성 요소들을 배치하고 통신 방식을 결정하여, 유지보수성, 확장성, 성능을 최적화하는 구조 설계 패턴.
|
||||
- **주요 패턴:**
|
||||
- **Layered (N-tier) Architecture:** 기능을 관심사에 따라 계층별로 분리 (예: Presentation, Business, Data layers). 가장 보편적임.
|
||||
- **Microservices Architecture (MSA):** 시스템을 독립적으로 배포 가능한 작은 서비스 단위로 분해하여 유연성 극대화.
|
||||
- **Event-Driven Architecture:** 상태 변화(Event)를 발행/구독(Pub/Sub) 모델로 처리하여 시스템 간 결합도를 낮춤.
|
||||
- **Hexagonal (Ports & Adapters):** 핵심 비즈니스 로직을 외부 기술(DB, UI)로부터 독립시켜 테스트와 교체가 용이하게 설계.
|
||||
- **Microkernel (Plug-in):** 핵심 코어와 확장 기능을 분리하여 동적인 기능 확장이 가능하게 함.
|
||||
- **추출된 패턴:** "Separation of Concerns and Structural Modularity" — 시스템의 책임을 명확히 분리하여 변경의 파급 효과를 최소화하고, 특정 요구사항(확장성, 성능, 배포 속도 등)에 최적화된 컴포넌트 간 배치 방식을 결정하는 패턴.
|
||||
- **주요 아키텍처 패턴:**
|
||||
- **Layered (N-tier):** 역할을 수평으로 분리 (UI-Business-Data). 가장 범용적이고 단순함.
|
||||
- **Event-driven:** 비동기 이벤트를 통해 통신. 높은 확장성과 유연성 제공.
|
||||
- **Microservices:** 비즈니스 단위로 서비스를 완전히 쪼개어 독립적 배포와 확장이 가능하게 함.
|
||||
- **Microkernel (Plugin):** 핵심 코어에 기능을 추가/제거할 수 있는 플러그인 구조. 확장성 우수.
|
||||
- **Hexagonal (Ports & Adapters):** 핵심 로직을 외부 환경(DB, UI 등)으로부터 고립시켜 테스트 용이성 극대화.
|
||||
- **의의:** 개발팀이 동일한 설계 언어를 공유하게 하며, 초기 결정이 향후 시스템의 생존 여부와 비용에 결정적인 영향을 미치는 '소프트웨어의 뼈대' 구축 과정.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 모든 기능을 하나에 담던 모놀리식(Monolithic) 아키텍처에서, 분산 처리와 유연성을 중시하는 MSA 및 서버리스 환경으로 패러다임이 이동.
|
||||
- **정책 변화:** Antigravity 프로젝트는 핵심 엔진과 개별 에이전트 스킬을 분리하는 '마이크로커널' 및 '이벤트 기반' 아키텍처를 하이브리드로 채택하여 높은 확장성을 확보함.
|
||||
- **과거 데이터와의 충돌:** "무조건 마이크로서비스가 최고다"라는 유행에서 벗어나, 시스템의 규모와 팀의 역량에 맞춰 단순한 모놀리식(Monolithic)이나 모듈형 모놀리식(Modular Monolith)이 더 효율적일 수 있다는 실용주의적 접근이 다시 강조되고 있음.
|
||||
- **정책 변화:** Antigravity 프로젝트는 핵심 에이전트 엔진은 마이크로커널 패턴으로 설계하여 기능을 유연하게 확장하고, 전체 서비스 배포는 독립성을 위해 마이크로서비스 지향적 패턴을 준수함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Domain-Driven-Design]], [[Separation-of-Concerns]], [[Microservices]], [[Design-Patterns]]
|
||||
- [[Service-oriented-Architecture]], [[Microservices-Foundations]], [[Scalability-in-AI-Systems]], [[API-Design-Principles]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Software-Architecture-Patterns.md]]
|
||||
|
||||
Reference in New Issue
Block a user