This commit is contained in:
Antigravity Agent
@@ -0,0 +1,22 @@
|
||||
# [[Class Components]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
클래스 컴포넌트(Class Components)는 JavaScript 클래스 문법을 사용하여 작성된 과거 React의 주요 컴포넌트 형태입니다. 오늘날의 React 개발 생태계는 대부분 함수형 컴포넌트로 전환되었으나, 특정 기능을 구현하기 위해 여전히 일부 사용됩니다. 가장 대표적으로 자식 컴포넌트 트리의 렌더링 에러를 포착하고 처리하는 '에러 바운더리(Error Boundaries)'는 오직 클래스 컴포넌트로만 구현할 수 있습니다 [1-4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **함수형 컴포넌트로의 전환 및 리팩토링:**
|
||||
현대의 프론트엔드 업계 표준은 클래스 기반 React에서 함수형 React로 전환되었습니다 [1]. 최신 React에서는 클래스 상속과 같은 객체 지향 프로그래밍(OOP) 방식이 거의 사용되지 않으며, 함수형 접근법이 선호됩니다 [5]. 이에 따라 레거시 React 코드베이스를 리팩토링할 때 가장 우선적으로 고려되는 작업 중 하나가 기존의 클래스 기반 컴포넌트를 함수형 컴포넌트 및 훅(Hooks)으로 마이그레이션하는 것입니다 [4].
|
||||
|
||||
* **에러 바운더리(Error Boundaries)로서의 필수적 역할:**
|
||||
대부분의 기능이 함수형 컴포넌트로 대체되었음에도 불구하고, 클래스 컴포넌트가 반드시 필요한 고유 영역이 존재합니다. 컴포넌트 트리 하위에서 발생하는 JavaScript 에러를 포착하여 애플리케이션 전체가 중단되는 것을 막아주는 '에러 바운더리'는 오직 클래스 컴포넌트로만 생성할 수 있습니다 [3, 6].
|
||||
|
||||
* **라이프사이클 메서드를 통한 에러 처리:**
|
||||
클래스 컴포넌트가 에러 바운더리로 동작하기 위해서는 특정 라이프사이클 메서드 중 하나 이상을 정의해야 합니다. 에러가 발생했을 때 깨진 컴포넌트 트리 대신 폴백(fallback) UI를 렌더링하려면 `static getDerivedStateFromError()` 메서드를 사용하며, 에러에 대한 상세 정보를 기록(log)하려면 `componentDidCatch()` 메서드를 사용합니다 [2, 6].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Functional Components]], [[Error Boundaries]], [[React Hooks]], [[Refactoring]]
|
||||
- **Projects/Contexts:** [[레거시 React 코드베이스 마이그레이션]], [[React 애플리케이션 예외 및 에러 처리]]
|
||||
- **Contradictions/Notes:** 전반적인 코드베이스 리팩토링 시에는 클래스 컴포넌트를 함수형 컴포넌트로 변경할 것을 강력히 권장하지만 [4], 에러 바운더리를 구현할 때만큼은 기술적 한계로 인해 오직 클래스 컴포넌트만 사용해야 한다는 예외가 존재합니다 [3].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[Fallback UI]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Fallback UI는 React 애플리케이션의 특정 부분에서 에러가 발생하거나 데이터를 로딩 중일 때 표시되는 대체 사용자 인터페이스입니다 [1-3]. 이는 결함이 있는 단일 컴포넌트 때문에 전체 애플리케이션이 중단되거나 빈 화면(하얀 화면)이 나타나는 것을 방지합니다 [1, 4]. 사용자에게 친숙한 에러 메시지나 로딩 상태를 제공하여 애플리케이션의 안정성과 전반적인 사용자 경험을 크게 향상시킵니다 [5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
* **에러 경계(Error Boundaries)와의 통합:** Fallback UI는 UI를 위한 'try-catch' 블록 역할을 하는 React 에러 경계와 함께 가장 중요하게 사용됩니다 [1]. 하위 컴포넌트 트리의 렌더링, 수명 주기 메서드 또는 생성자에서 JavaScript 에러가 발생할 경우, 에러 경계 컴포넌트는 에러를 포착하고 `static getDerivedStateFromError()`와 같은 메서드를 호출해 상태를 업데이트한 뒤, 깨진 컴포넌트 트리 대신 Fallback UI를 렌더링합니다 [2, 5, 7].
|
||||
* **전략적 배치 및 애플리케이션 안정성:** 애플리케이션 전체를 하나의 에러 경계로 감싸기보다는 타사 위젯, 차트, 복잡한 폼 등 독립적이거나 불안정한 섹션을 개별적으로 감싸는 것이 모범 사례입니다 [1, 8]. 이렇게 구성하면 특정 위젯이 실패하여 Fallback UI를 표시하더라도 애플리케이션의 나머지 부분은 계속 안정적으로 작동하고 상호 작용할 수 있습니다 [1, 9].
|
||||
* **사용자 중심 디자인:** Fallback UI는 단순하고 명확하며 유익하게 디자인해야 합니다. 기술적인 세부 사항으로 사용자를 압도하지 않으면서도, 무언가 잘못되었음을 이해할 수 있도록 친절한 오류 메시지를 제공하는 것이 권장됩니다 [5, 8].
|
||||
* **지연 로딩(Lazy Loading) 및 Suspense에서의 활용:** 에러 처리뿐만 아니라 성능 최적화를 위한 코드 분할 및 지연 로딩에도 Fallback UI가 핵심적인 역할을 합니다 [3]. `React.lazy()`를 사용하여 컴포넌트를 온디맨드 방식으로 로드할 때, `Suspense`를 결합하여 모듈이나 데이터가 로드되는 동안 보여줄 Fallback UI(예: 로딩 스피너, 스켈레톤 상태 등)를 정의할 수 있습니다 [3, 10].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Error Boundaries]], [[React Suspense]], [[Lazy Loading]]
|
||||
- **Projects/Contexts:** [[Frontend Application Stability]], [[Performance Optimization]]
|
||||
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,33 @@
|
||||
# [[Frontend Debugging]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
프론트엔드 디버깅은 프로덕션 환경이나 개발 과정에서 발생하는 자바스크립트 오류, 메모리 누수, 그리고 불필요한 리렌더링 같은 성능 저하의 근본 원인을 식별하고 해결하는 과정입니다 [1-4]. 현대의 복잡한 프론트엔드 시스템에서는 단순한 콘솔 로그를 넘어 브라우저 개발자 도구, React 전용 프로파일러, 그리고 Sentry나 LogRocket과 같은 클라우드 기반 로깅 및 세션 리플레이 도구를 적극적으로 활용합니다 [2, 5-7]. 또한, React 환경에서는 Error Boundary를 통해 런타임 에러를 격리하여 앱 전체가 멈추는 것을 방지하는 방어적 프로그래밍 전략이 필수적으로 동반됩니다 [8, 9].
|
||||
|
||||
## 📖 Core Content
|
||||
- **메모리 누수(Memory Leaks) 및 힙 메모리 디버깅**
|
||||
- 자바스크립트에서 할당된 메모리가 제대로 해제되지 않고 계속 축적될 때 메모리 누수가 발생하며, 이는 앱의 성능 저하 및 크래시로 이어집니다 [10, 11].
|
||||
- **Chrome DevTools의 Heap Snapshots:** 이를 통해 메모리 덤프를 비교하고 "Detached DOM nodes(분리된 DOM 노드)"나 클로저로 인해 불필요하게 유지되고 있는 객체 참조를 식별할 수 있습니다 [12-15].
|
||||
- **Allocation Timeline:** 애플리케이션과 상호작용하는 동안 실시간으로 메모리가 할당되는 패턴을 추적하여 누수가 발생하는 정확한 시점을 시각적으로 파악할 수 있습니다 [16-18].
|
||||
- 객체 캐싱으로 인한 메모리 누수를 방지하기 위해 일반 객체 대신 가비지 컬렉션이 가능한 `WeakMap`을 활용하는 것이 권장됩니다 [19].
|
||||
|
||||
- **React 렌더링 성능 및 상태 관리 디버깅**
|
||||
- **React DevTools Profiler:** 렌더링이 발생한 컴포넌트, 렌더링 소요 시간, 그리고 렌더링을 유발한 원인(props 또는 state의 변경)을 정확히 분석하여 병목 지점을 찾습니다 [7, 20].
|
||||
- **why-did-you-render:** 개발 환경에서 props나 state의 변경 없이 발생하는 불필요한 리렌더링을 콘솔 경고로 표시해주어, 낭비되는 렌더링을 방지하는 데 유용합니다 [21, 22].
|
||||
- 복잡한 비동기 작업 및 상태를 관리할 때, Context API는 상태 추적이 어렵지만 Redux는 Redux DevTools를 통해 상태 변경 내역을 확인하고 액션을 재현할 수 있는 '시간 여행(Time-travel) 디버깅' 기능을 제공하여 디버깅 속도를 크게 높여줍니다 [23-25].
|
||||
|
||||
- **프로덕션 클라우드 로깅 및 모니터링 도구**
|
||||
- **Sentry:** 오류를 지능적으로 그룹화하고, 콘솔 로그와 네트워크 요청, 사용자 액션을 포함한 Breadcrumb 트레일을 제공하여 오류 발생 전후의 컨텍스트를 파악합니다 [5, 26].
|
||||
- **LogRocket:** 사용자의 화면과 함께 DOM 변경, Redux/Vuex 상태 변화, 네트워크 응답을 비디오처럼 기록하는 세션 리플레이(Session replay)를 제공하여 디버깅 맥락을 완벽히 제공합니다 [6, 26, 27].
|
||||
- **Datadog RUM 및 SigNoz:** 프론트엔드 에러 클릭 시 분산 시스템의 백엔드 트레이스(Traces)와 인프라 메트릭까지 연결하는 End-to-end 추적 기능을 제공합니다 [28-30].
|
||||
|
||||
- **에러 바운더리(Error Boundaries)를 통한 UI 에러 격리**
|
||||
- React 클래스 컴포넌트로 구현되는 Error Boundary는 자식 컴포넌트 트리의 렌더링, 수명 주기 메서드 등에서 발생하는 JavaScript 오류를 잡아냅니다 [9, 31].
|
||||
- 서드파티 위젯이나 복잡한 폼 같은 불안정한 UI 섹션을 Error Boundary로 개별 래핑하면, 오류 발생 시 전체 앱이 충돌하여 "백지 화면"이 표시되는 것을 막고, 친숙한 Fallback UI(대체 화면)를 대신 보여줄 수 있습니다 [8, 32, 33].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[React Error Boundaries]], [[Performance Optimization]], [[State Management]]
|
||||
- **Projects/Contexts:** [[확장 가능한 React 아키텍처 및 폴더 구조 설계]], [[프론트엔드 클라우드 로깅 도구 도입 및 프로덕션 모니터링]]
|
||||
- **Contradictions/Notes:** Error Boundaries는 선언형 컴포넌트 트리 내의 렌더링 에러는 훌륭하게 잡아내지만, 이벤트 핸들러(Event handlers)나 `setTimeout` 등의 비동기 코드에서 발생하는 에러는 감지하지 못하므로, 해당 영역에서는 일반적인 `try/catch` 블록을 별도로 사용해야 합니다 [34, 35]. 또한 Datadog과 같은 통합 가시성 도구는 매우 강력하지만, 인제스트(수집)와 인덱싱(검색 활성화)을 각각 과금하는 이중 가격 모델 때문에 대규모 트래픽에서 비용이 기하급수적으로 증가할 수 있다는 한계가 있습니다 [36, 37].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,25 @@
|
||||
# [[Frontend Team Collaboration]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
프론트엔드 팀 협업은 일관된 폴더 구조, 명확한 네이밍 규칙, 그리고 체계적인 Git 워크플로우를 통해 다수의 개발자가 충돌 없이 코드를 작성하고 확장 가능한 애플리케이션을 유지보수할 수 있게 하는 프로세스입니다 [1-3]. 소규모부터 엔터프라이즈 규모의 팀까지 효율적으로 협업하기 위해서는 코드 컨벤션의 자동화(거버넌스)와 티켓 기반의 이슈 추적이 필수적입니다 [4, 5]. 기능 중심(Feature-based)의 아키텍처와 시각적 회귀 테스트(Visual Regression Testing)를 도입하면, 코드 충돌을 방지하고 온보딩 시간을 단축하며 프로덕션 환경의 안정성을 높일 수 있습니다 [6-8].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **협업을 위한 Git 워크플로우 및 PR 리뷰:**
|
||||
프론트엔드 팀은 메인 브랜치를 항상 안정적이고 배포 가능한 상태로 유지해야 하며(메인 브랜치 직접 푸시 금지), 각 작업마다 짧은 주기의 기능 브랜치(Feature Branch)를 생성하여 작업해야 합니다 [9-12]. PR(Pull Request)은 리뷰어가 쉽게 이해할 수 있도록 작게 유지해야 하며, 최소 1명 이상의 동료 리뷰를 거친 후 병합(Squash merge 등)해야 합니다 [13, 14]. Storybook이나 Chromatic과 같은 도구를 통한 시각적 리뷰(Visual review)를 추가하면, 레이아웃이나 색상 등의 UI 회귀(Regression)가 프로덕션에 도달하는 것을 방지할 수 있습니다 [6, 15].
|
||||
* **커밋 메시지와 티켓 추적성 (Traceability):**
|
||||
커밋 메시지는 코드의 변경 내용(what)과 변경 이유(why)를 명확히 설명해야 하며, `feat`, `fix`, `chore` 등을 사용하는 'Conventional Commits' 형식을 따라야 릴리스 노트를 자동화하고 히스토리를 쉽게 파악할 수 있습니다 [14, 16, 17]. 브랜치 이름과 커밋 메시지에 티켓 ID(예: `PROJ-123`)를 포함하면 요구사항과 코드 변경 사항 간의 추적성을 높이고, 코드 리뷰어에게 비즈니스 컨텍스트를 효과적으로 제공할 수 있습니다 [5, 18, 19].
|
||||
* **폴더 구조와 아키텍처를 통한 병렬 작업:**
|
||||
표준화된 폴더 구조는 개발자 간의 불필요한 의사소통 비용을 줄이고, 새 팀원의 온보딩을 가속화합니다 [8]. Feature-Sliced Design(FSD)과 같이 기능(Feature)을 중심으로 폴더를 구성하면, 개발자들이 서로의 코드를 건드리지 않고도 각자의 슬라이스(기능 도메인)에서 병렬로 작업할 수 있어 애자일(Agile) 개발 방식의 확장에 유리합니다 [7, 20-22].
|
||||
* **코드 컨벤션과 자동화된 거버넌스 (Automated Governance):**
|
||||
파일 명명 규칙(예: 파일 이름은 호환성을 위해 `kebab-case`, React 컴포넌트는 `PascalCase`, 변수나 훅은 `camelCase` 사용)을 팀 전체가 일관되게 유지하면 코드를 한눈에 파악하고 충돌을 방지하기 쉽습니다 [23-26]. ESLint, Prettier, Husky 등의 도구를 활용하여 Git 훅 단계에서 린팅과 포맷팅, 타입 검사를 강제하면, 규칙 위반을 자동으로 방지하고 고품질의 코드만 저장소에 병합되도록 만들 수 있습니다 [4].
|
||||
* **팀 규모에 따른 상태 관리 도구 선택:**
|
||||
팀의 규모는 협업 도구 선택에 큰 영향을 미칩니다. 규모가 큰 팀(10명 이상)에서는 Zustand처럼 유연하고 자유도가 높은 도구보다, Redux처럼 엄격한 패턴과 구조(Boilerplate)를 강제하는 도구가 팀원 간의 코드 일관성(예: 일관된 비동기 코드 작성 방식)을 유지하고 디버깅을 쉽게 하는 데 더 적합합니다 [27-30].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Git Branching Strategies]], [[Conventional Commits]], [[Feature-Sliced Design]], [[Automated Governance]], [[Visual Regression Testing]]
|
||||
- **Projects/Contexts:** [[Small vs Large Frontend Teams]], [[Scalable React Apps]]
|
||||
- **Contradictions/Notes:** 소규모 팀이나 스타트업에서는 자유도가 높은 상태 관리 도구(예: Zustand)가 빠른 개발 속도를 이끌어내지만, 팀이 커짐에 따라 구조적인 강제가 없다면 서로 다른 비동기 처리 패턴이 생겨나 통합의 혼란(Integration chaos)을 초래할 수 있으므로 팀 성장에 맞춰 Redux와 같은 더 견고한 구조로 마이그레이션하거나 엄격한 패턴을 적용해야 합니다 [30-32].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,25 @@
|
||||
# [[Small Team Development]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
소규모 팀(보통 2~5명) 환경에서 복잡한 프로세스 오버헤드를 최소화하고 빠른 피드백과 안정적인 코드 기반을 유지하기 위한 소프트웨어 개발 및 협업 방식을 의미합니다 [1]. 프론트엔드 및 React 개발 환경에서는 주로 가벼운 기능 분기(Feature-branch) 워크플로우나 단기 트렁크 기반(Trunk-based) 개발을 채택하며, 불필요한 보일러플레이트를 줄일 수 있는 상태 관리 도구를 선호합니다 [2-4]. 이를 통해 코드 충돌을 예방하고 팀원 간의 동기화 및 코드 리뷰를 원활하게 진행할 수 있습니다 [5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
* **소규모 팀을 위한 Git 브랜칭 전략:**
|
||||
* 복잡한 Git-Flow 방식은 소규모 팀에게 너무 무거울 수 있으므로, **단순한 기능 분기(Feature-Branch) 워크플로우**나 **수명이 짧은 기능 브랜치를 활용하는 트렁크 기반(Trunk-based) 워크플로우**가 가장 적합합니다 [1-3, 7, 8].
|
||||
* `main` 브랜치는 항상 배포 가능하고 안정적인 상태로 보호되어야 하며(직접 푸시 금지), 새로운 기능 추가나 버그 수정 등 모든 작업은 `main`에서 분기한 단독 브랜치(`feature/*`, `fix/*` 등)에서 수행해야 합니다 [1-3, 9, 10].
|
||||
* **커밋 및 PR(Pull Request) 규칙:**
|
||||
* 변경 사항은 커밋당 하나의 논리적 변경만 포함하는 원자적 커밋(Atomic Commits) 형태로 작게 유지해야 코드 리뷰와 문제 추적이 쉽습니다 [9, 11-13].
|
||||
* 모든 변경 사항은 병합 전 PR을 열어 적어도 **1명 이상의 팀원에게 코드 리뷰 및 승인**을 받아야 하며, CI/CD 테스트를 통과해야 합니다 [9-13].
|
||||
* 깔끔한 커밋 히스토리를 유지하기 위해 **스쿼시 병합(Squash & Merge)**을 주로 사용하고, 병합이 완료된 기능 브랜치는 즉시 자동 삭제하도록 설정하는 것이 좋습니다 [9-11, 13].
|
||||
* **소규모 팀의 React 상태 관리 도구 선택:**
|
||||
* 스타트업이나 5명 내외의 소규모 팀이 React 프로젝트를 진행할 때, Redux는 초기 보일러플레이트가 과도하게 느껴질 수 있습니다 [14-16].
|
||||
* 빠른 MVP 개발 및 기능 구현을 위해 가벼우면서도 Redux와 유사한 강력함을 제공하는 **Zustand**가 소규모 팀에게 가장 이상적인 "골디락스(Goldilocks) 솔루션"으로 권장됩니다 [4, 16, 17].
|
||||
* 반면 3~4명 이상의 팀에서 Context API를 전역 상태 관리로 남용하면 리렌더링 폭풍(re-render storm) 등 심각한 성능 문제가 발생하기 쉬우므로 주의해야 합니다 [14, 17, 18].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Git Branching Strategies]], [[Feature-Branch Workflow]], [[Trunk-Based Development]], [[React State Management]], [[Zustand]]
|
||||
- **Projects/Contexts:** [[GitHub Flow in Small Teams]], [[React App Prototypes and Startups]]
|
||||
- **Contradictions/Notes:** 단순한 기능 브랜치 구조와 Zustand 같은 유연한 도구는 소규모 팀이 빠르게 움직이기에 최적이지만, 팀 규모가 10명 이상으로 커지고 애플리케이션의 복잡도가 증가하면 구조적 규율이 부족해질 수 있습니다. 이 경우, 대규모 릴리스 관리를 위해 Git-Flow로 마이그레이션하거나, 더 엄격한 상태 관리 패턴을 강제하는 Redux로의 전환을 고려해야 합니다 [8, 15, 16, 19, 20].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: UX-DATA-TEST-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ux, ab-testing, data-driven-design, cro, micro-conversions, product-growth]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[A/B Testing and Data-Driven UX (A/B 테스트 및 데이터 기반 UX)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "디자인의 주관적 미학을 통계적 객관성으로 치환하고, 사용자의 실제 행동 데이터를 나침반 삼아 비즈니스 전환율의 임계점을 돌파하라" — 가설을 검증하고 사용자 경험의 마찰을 수치로 정밀 타격하는 현대 프로덕트 성장의 핵심 엔진.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Empirical Validation and Iterative Optimization" — 직관이나 가정에 의존하는 대신, 트래픽을 대조군(Control)과 실험군(Test)으로 분리하여 특정 UI 변경이 미치는 인과관계를 데이터로 증명하는 패턴.
|
||||
- **핵심 방법론 및 도구:**
|
||||
- **A/B & Multivariate Testing:** 단일 또는 다중 변수의 변경이 최종 전환율에 미치는 영향을 분리 및 검증.
|
||||
- **Micro-conversions:** 최종 목표(구매 등) 이전의 행동(스크롤, 클릭, 시청)을 추적하여 사용자 의도 파악.
|
||||
- **Behavioral Analysis:** 히트맵(Heatmaps)과 세션 녹화(Session Recording)를 통해 정량적 지표 뒤에 숨겨진 정성적 마찰 지점 식별.
|
||||
- **Progressive Rollouts:** 리스크 최소화를 위해 신규 디자인을 특정 세그먼트에게만 점진적으로 노출.
|
||||
- **의의:** 디자인 결정의 불확실성을 제거하고, 지속적인 실험 루프를 통해 제품의 비즈니스 가치를 과학적으로 극대화함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거에는 디자인을 '완성된 작품'으로 보았으나, 현재 정책은 제품을 '지속적 실험의 대상'으로 간주함. 특히 상관관계(Correlation)와 인과관계(Causation)를 혼동하지 않기 위한 엄격한 통계적 유의성 검증 정책이 강화됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 주요 UI 변경 시 최소 10%의 트래픽에 대해 A/B 테스트를 선행하며, 데이터 기반의 근거 없이는 레이아웃 변경을 승인하지 않는 'Evidence-based Design' 정책을 고수함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[User-Centered-Design]], [[Conversion-Rate-Optimization-CRO]], [[Hypothesis-Testing]], [[Product-Management-Best-Practices]]
|
||||
- **Raw Source:** [[00_Raw/A-B 테스트 및 데이터 기반 UX 검증 환경.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: SYS-COMP-ADA-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [accessibility, compliance, ada, wcag, pour-principles, inclusive-design, digital-governance]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[ADA Website Compliance (ADA 웹사이트 규정 준수)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "장애 유무와 관계없이 모든 인간이 디지털 공간의 정보를 공평하게 소유하게 하고, 기술적 표준(WCAG)을 통해 법적 리스크를 비즈니스 신뢰도로 전환하라" — 미국 장애인법(ADA)을 기반으로 한 디지털 콘텐츠의 보편적 접근성 보장 체계.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Universal Access and Regulatory Alignment" — 민권법인 ADA와 기술 표준인 WCAG(최소 Level AA)를 결합하여, 모든 사용자의 '인식, 운용, 이해, 견고성'을 보장하는 인클루시브 디자인 패턴.
|
||||
- **핵심 원칙 (POUR Principles):**
|
||||
- **Perceivable (인식의 용이성):** 이미지 대체 텍스트(Alt Text) 제공, 영상 자막 탑재 등 정보의 감각적 인식 보장.
|
||||
- **Operable (운용의 용이성):** 키보드 전용 탐색 보장, 충분한 조작 시간 제공, 발작 유발 콘텐츠 배제.
|
||||
- **Understandable (이해의 용이성):** 텍스트 가독성 확보, 예측 가능한 UI 동작, 입력 오류 수정 지원.
|
||||
- **Robust (견고성):** 보조 기술(화면 판독기 등) 및 최신 브라우저와의 높은 호환성 유지.
|
||||
- **의의:** 차별 없는 정보 접근권이라는 사회적 가치 실현과 동시에, 접근성 소송(Lawsuits)으로부터 비즈니스를 보호하고 검색 엔진 최적화(SEO) 효과를 덤으로 얻는 전략적 필수 요건.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거에는 '접근성 위젯(Overlay)'이 법적 방패가 될 것으로 오해했으나, 실제 정책상 이러한 위젯은 근본적 해결책이 아니며 소송의 타겟이 되고 있음. 코드를 근본적으로 수정하는 '네이티브 접근성' 정책이 유일한 정답임.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 UI 컴포넌트 개발 시 WCAG 2.1 AA 표준 감사를 빌드 파이프라인에 포함하며, 시각 장애인 에이전트의 접근성 시뮬레이션을 필수로 거치는 정책을 시행함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Web-Accessibility]], [[POUR-Principles]], [[Inclusive-Design]], [[SEO-Foundations]]
|
||||
- **Raw Source:** [[00_Raw/ADA Website Compliance.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: MKT-AEO-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [aeo, geo, seo, generative-ai, chatgpt, search-generative-experience, structured-data, ssr]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[AI Answer Engine Optimization (AEO, AI 답변 엔진 최적화)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "전통적인 검색창의 '목록'에 머물지 말고, 생성형 AI의 '입(답변)'이 되어 브랜드의 가시성을 인용구(Citation)라는 새로운 권력으로 재편하라" — AI 답변 엔진과 챗봇이 웹 콘텐츠를 신뢰할 수 있는 출처로 채택하도록 최적화하는 차세대 검색 전략.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Crawlable Authority and Direct Answer Mapping" — 대규모 AI 크롤러가 JavaScript 실행 비용 없이도 콘텐츠를 즉시 합성할 수 있도록 '사전 렌더링된 HTML'과 '구조화된 데이터'를 제공하는 패턴.
|
||||
- **AEO 달성 핵심 전략:**
|
||||
- **JS Execution Wall 제거:** AI 봇(GPTBot 등)은 비용 문제로 JS를 실행하지 않는 경우가 많으므로, SSR/SSG를 통해 원본 HTML에 핵심 콘텐츠를 노출.
|
||||
- **Semantic Clarity:** `<main>`, `<article>` 태그를 활용해 AI가 핵심 내용과 주변 요소를 즉시 구분하도록 설계.
|
||||
- **JSON-LD Schema Markup:** 페이지의 실체(Entity)와 답변의 맥락을 머신러닝 모델이 오해 없이 이해하도록 명시적 신호 제공.
|
||||
- **Q&A Formatting:** 질문(H2)과 간결한 답변 구조를 통해 AI 오버뷰(SGE)에 직접 인용될 확률 극대화.
|
||||
- **의의:** '검색 결과 클릭' 중심의 시대에서 '답변 내 인용 및 신뢰도 확보' 중심으로 이동하는 AI 시대의 디지털 마케팅 생존법.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거 SEO는 사용자 클릭 유도를 위한 자극적 제목이 중요했으나, AEO 정책은 AI가 답변을 요약하기 좋게 만드는 '정보의 정합성'과 '구조적 명확성' 정책을 최우선으로 함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 지식 문서를 AEO 친화적인 Karpathy Summary 포맷으로 유지하며, 에이전트의 지식 추출 효율을 위해 JSON-LD 스키마를 자동 생성하여 메타데이터에 포함하는 정책을 시행함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SEO-Foundations]], [[Generative-Engine-Optimization]], [[Server-Side-Rendering-SSR]], [[Structured-Data-Markup]], [[Semantic-HTML]]
|
||||
- **Raw Source:** [[00_Raw/AI Answer Engine Optimization.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: MKT-SGE-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [sge, ai-overviews, google-search, aeo, citation, search-generative-experience, seo]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[AI Overviews and SGE (AI 오버뷰 및 생성형 검색 경험)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "검색 결과의 '목록'에 나열되는 것을 넘어, 구글이 직접 생성하는 답변 박스(AI Overview)의 '원천 데이터'로 선택받아 정보의 최상위 권위를 획득하라" — 구글의 Search Generative Experience(SGE) 환경에서 콘텐츠 가시성을 확보하기 위한 노출 최적화 전략.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Structural Authority and Direct Citation Yield" — 복잡한 레이아웃 뒤에 숨겨진 정보가 아닌, 시각적 계층 구조가 명확하고 질문-답변 형식이 뚜렷한 콘텐츠를 AI가 즉시 합성(Synthesize)할 수 있도록 설계하는 패턴.
|
||||
- **노출 극대화 핵심 요소:**
|
||||
- **Visual Hierarchy:** 깔끔한 디자인과 명확한 제목 계층(H1-H3)을 통해 AI가 핵심 답변 구간을 오차 없이 식별하게 함.
|
||||
- **Direct Answer Formatting:** 명확한 질문 뒤에 즉각적이고 간결한 답변을 배치하는 구조를 선호함.
|
||||
- **Schema.org Utilization:** JSON-LD를 통해 해당 섹션이 FAQ나 주요 설명임을 검색 엔진에 명시적으로 통지.
|
||||
- **Performance Prerequisite:** Core Web Vitals(LCP, INP, CLS)를 통과하는 페이지가 AI 오버뷰에 채택될 확률이 유의미하게 높음.
|
||||
- **의의:** 제로 클릭 검색(Zero-click Search) 시대에 사용자의 질문에 대한 '정답'으로 인용됨으로써 브랜드 신뢰도를 구축하고 고품질 트래픽을 유도함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거에는 사용자를 사이트로 유입시키기 위해 정보를 의도적으로 감추는 '낚시성 제목'이 통했으나, SGE 정책하에서는 AI가 즉시 요약할 수 있도록 정보를 투명하고 구조적으로 제공하는 '투명성 정책'이 노출의 핵심이 됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 공용 지식 데이터 배포 시 SGE 크롤러가 자바스크립트 실행 없이 읽을 수 있도록 사전 렌더링(Pre-rendering)을 강제하며, AI가 선호하는 Q&A 블록을 본문에 반드시 포함하는 정책을 시행함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[AI-Answer-Engine-Optimization]], [[Generative-Engine-Optimization]], [[Core-Web-Vitals]], [[Semantic-HTML]], [[Structured-Data-Markup]]
|
||||
- **Raw Source:** [[00_Raw/AI Overviews (SGE).md]], [[00_Raw/AI Overviews Visibility.md]], [[00_Raw/AI Overviews.md]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: MKT-AI-SEARCH-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai-search, geo, aeo, semantic-entity-mapping, seo, future-of-search, knowledge-graph]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[AI Search Optimization (AI 검색 최적화)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "단순한 키워드 매칭의 시대에서 '의미론적 엔티티 매핑(Semantic Entity Mapping)'의 시대로 전환하고, AI 에이전트가 내 지식의 구조를 단번에 파악할 수 있도록 지식의 해상도를 높여라" — 챗봇, 답변 엔진 및 AI 에이전트를 타겟으로 하는 최신 검색 엔진 최적화 전략.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "From Keyword Density to Entity Authority" — 파편화된 단어의 빈도보다는 지식 간의 관계와 전문성(E-E-A-T)을 중심으로 AI 모델의 지식 그래프(Knowledge Graph)에 편입되는 패턴.
|
||||
- **AI 검색 최적화의 핵심 진화:**
|
||||
- **GEO (Generative Engine Optimization):** 생성형 모델이 문맥을 이해하고 자연스럽게 인용할 수 있도록 풍부한 시맨틱 메타데이터 제공.
|
||||
- **AEO (Answer Engine Optimization):** 특정 질문에 대한 '직접적인 해답'으로서의 권위 확보.
|
||||
- **Semantic Entity Mapping:** 콘텐츠 내의 고유 명사와 개념들이 어떻게 연결되는지 명시하여 AI의 추론 효율 극대화.
|
||||
- **의의:** 인간 사용자를 위한 가독성과 AI 에이전트를 위한 기계 가독성(Machine Readability)을 동시에 만족시켜, 지식의 유통 수명을 연장함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 전통적 SEO는 키워드 밀도(Keyword Density)를 중시했으나, AI 검색 최적화 정책은 '의미론적 엔티티 매핑'과 '맥락적 정합성' 정책을 최우선으로 함. 또한 JS 실행에만 의존하는 SPA의 구조적 모순을 지적하며 SSR/SSG로의 근본적 회귀 정책을 강조함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 지식 자산에 대해 'Agent-First Access' 정책을 적용하며, AI 크롤러가 정보를 수집할 때 연산 자원을 최소화할 수 있도록 경량화된 시맨틱 마크업을 제공함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[AI-Answer-Engine-Optimization]], [[Generative-Engine-Optimization]], [[Knowledge-Graph-Foundations]], [[Semantic-Search-with-AI]], [[Ontology-Engineering]]
|
||||
- **Raw Source:** [[00_Raw/AI Search Optimization.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: CS-CLEAN-CODE-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [software-engineering, clean-code, srp, dry, kiss, refactoring, maintainability]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Clean Code Principles (클린 코드 원칙)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드는 컴퓨터가 읽기 위함이 아니라, 미래의 나를 포함한 '다른 인간'이 단번에 의도를 파악할 수 있도록 설계된 고도의 의사소통 수단이다" — 유지보수 효율을 극대화하고 소프트웨어의 부패를 막기 위한 코드 작성의 도덕적/기술적 기준.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Human-Centric Engineering and Responsibility Separation" — 기계적인 동작 완성을 넘어, 이름 짓기(Naming), 함수 설계, 클래스 구조에서 의미적 명확성과 단일 책임(Single Responsibility)을 관철시키는 패턴.
|
||||
- **핵심 원칙:**
|
||||
- **Meaningful Names:** 변수와 함수명은 존재 이유와 기능을 스스로 설명해야 함.
|
||||
- **Single Responsibility (SRP):** 하나의 함수/클래스는 오직 하나의 일만 수행하고 하나의 변경 이유만 가져야 함.
|
||||
- **DRY (Don't Repeat Yourself):** 중복은 시스템의 복잡도를 높이고 버그의 온상이 됨. 추상화를 통해 제거.
|
||||
- **KISS (Keep It Simple, Stupid):** 가장 단순한 해결책이 가장 좋은 해결책임.
|
||||
- **의의:** 기술 부채(Technical Debt)의 누적을 방지하고, 대규모 협업 환경에서 코드 리뷰 비용을 획기적으로 낮추며 시스템의 수명을 연장함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거에는 메모리와 성능 최적화를 위해 짧고 암호 같은 코드를 선호했으나, 현대 정책은 하드웨어 자원보다 '개발자의 인지적 자원(Cognitive Resource)'을 훨씬 비싼 자산으로 간주하여 가독성을 최우선 정책으로 삼음.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트가 생성하는 모든 코드에 대해 SOLID 원칙과 클린 코드 가이드라인을 강제 적용하며, 복잡도가 일정 수준 이상인 코드는 자동 리팩토링 루프에 진입시킴.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Software-Architecture-Patterns]], [[Refactoring-Techniques]], [[SOLID-Principles-in-React]], [[Technical-Debt-Management]]
|
||||
- **Raw Source:** [[00_Raw/Clean Code Principles.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: FE-REACT-HOOKS-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [react, frontend, hooks, functional-programming, state-management, useEffect, useState]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[React Hooks (리액트 훅)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "클래스의 복잡한 생명주기(Lifecycle)를 직관적인 함수의 흐름으로 평탄화하고, 컴포넌트 간 상태 로직을 마법처럼 공유하라" — React 16.8부터 도입된, 함수형 컴포넌트에서도 상태와 생명주기 기능을 사용할 수 있게 해주는 혁신적인 API.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Logic Decoupling and Composition Over Inheritance" — UI 렌더링과 비즈니스 로직을 분리하고, 커스텀 훅(Custom Hooks)을 통해 반복되는 로직을 독립적인 단위로 재사용하는 패턴.
|
||||
- **주요 훅과 역할:**
|
||||
- **useState:** 컴포넌트 내의 로컬 상태 관리.
|
||||
- **useEffect:** API 호출, 이벤트 리스너 등 사이드 이펙트(Side Effects) 처리 및 클린업.
|
||||
- **useMemo / useCallback:** 불필요한 연산과 리렌더링을 방지하는 메모이제이션(Memoization).
|
||||
- **useContext:** 전역 상태 공유를 위한 Context API 접근.
|
||||
- **의의:** 기존 HOC(High-Order Components)나 Render Props 방식의 'Wrapper Hell' 문제를 해결하고, 코드의 가독성과 테스트 가능성을 비약적으로 향상시킴.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 초기에는 모든 최적화에 `useMemo` 등을 남발했으나, 최근 React Compiler(React Forget)의 등장으로 수동 최적화의 필요성이 줄어들고 있으며, 훅은 오직 최상위 레벨에서만 호출되어야 한다는 'Rules of Hooks' 정책이 더욱 엄격해짐.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 신규 프런트엔드 모듈에 함수형 컴포넌트와 훅 아키텍처를 강제하며, 복잡한 데이터 페칭 로직은 반드시 커스텀 훅으로 추상화하여 관리함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[React-Architecture]], [[Functional-Programming]], [[State-Management-Patterns]], [[SOLID-Principles-in-React]]
|
||||
- **Raw Source:** [[00_Raw/React Hooks.md]]
|
||||
+16
-19
@@ -1,31 +1,28 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-SEOO-001
|
||||
id: MKT-SEO-CORE-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, seo, search-engine-optimization, traffic, visibility, ranking, digital-marketing]
|
||||
last_reinforced: 2026-04-20
|
||||
confidence_score: 1.0
|
||||
tags: [seo, marketing, search-engine, technical-seo, core-web-vitals, ssr, aeo, geo]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[SEO]]
|
||||
# [[SEO (Search Engine Optimization)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "정보의 발견 확률 조절술: 내 지식이 거대한 구글 검색창의 심연 속에 묻히지 않고, 정작 그것이 필요한 사람의 화면 가장 위에 뜨도록 기술-콘텐츠-신뢰도를 최적화하는 디지털 세계의 '입지 선정 전략'."
|
||||
> "정보의 바다에서 단순한 '존재'를 넘어, 검색 엔진과 AI 크롤러가 가장 신뢰할 수 있는 '해답'으로 선택하도록 기술적 구조와 콘텐츠의 맥락을 완벽히 정렬하라" — 웹사이트의 가시성을 높여 유기적 트래픽을 극대화하는 전략적 프로세스.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
검색 엔진 최적화(SEO)는 웹사이트가 검색 결과 상단에 노출되도록 개선하는 활동입니다.
|
||||
|
||||
1. **3대 최적화 기둥**:
|
||||
* **On-Page SEO**: 제목, 태그, 키워드 배치 등 페이지 내부 최적화. (Documentation-Strategy와 연결)
|
||||
* **Technical SEO**: 사이트 속도, 모바일 친화성, 스키마 마크업 등 인프라 최적화. (Scalability와 연결)
|
||||
* **Off-Page SEO**: 타 사이트로부터의 인용(Backlinks)을 통한 신뢰도 확보. (Reference와 맥락 공유)
|
||||
2. **왜 중요한가?**:
|
||||
* 아무리 SOTA급 지식이라도 발견되지 않으면 가치가 0이기 때문이며, SEO는 정보의 '전달력'을 극대화하는 핵심 비즈니스 기술임.
|
||||
- **추출된 패턴:** "Technical Robustness and Contextual Authority Alignment" — 사이트 속도(Technical)와 모바일 친화성, 그리고 정보의 전문성(E-E-A-T)을 결합하여 검색 결과 상단의 지배력을 확보하는 패턴.
|
||||
- **현대 SEO의 핵심 축:**
|
||||
- **Technical SEO:** Core Web Vitals(LCP, INP, CLS) 최적화, SSR/SSG를 통한 JS 장벽 제거, 시맨틱 HTML5 구조화.
|
||||
- **Content Strategy:** 사용자 의도(Search Intent) 분석 및 키워드 최적화를 넘어선 엔티티(Entity) 기반 정보 제공.
|
||||
- **AEO & GEO:** AI 답변 엔진 및 생성형 검색(Search Generative Experience)에서 인용(Citation)을 얻기 위한 구조화된 데이터(JSON-LD) 배치.
|
||||
- **의의:** 비즈니스 자산의 발견 가능성을 높이고 광고비 지출 없이 지속 가능한 성장을 가능케 하는 디지털 마케팅의 정수.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌**: 과거에는 키워드를 억지로 쑤셔 넣는 '어뷰징 정책'이 통했으나, 현대 정책은 사용자 경험(UX) 정책과 정보의 전문성(E-E-A-T) 정책을 최우선으로 하는 '사람 중심 최적화 정책'으로 정화됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 이제는 구글 검색창을 넘어 챗봇(Perplexity, ChatGPT 등)이 정보를 요약해 주는 'AI 검색 결과 최적화(GEO/AEO) 정책'이 새로운 생존 과제 정책이 됨.
|
||||
- **과거 데이터와의 충돌:** 과거에는 키워드 반복(Keyword Stuffing)이 통했으나, 현재 구글 알고리즘은 실제 사용자 인터랙션과 상호작용 속도(INP)를 핵심 지표로 반영함. 또한 SPA의 CSR 방식은 크롤링 예산을 낭비시키므로 SSR로의 전환이 필수가 됨.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 웹 자산 배포 시 'SEO-First' 아키텍처를 적용하며, AI 크롤러의 접근성을 위해 자바스크립트 실행 없이도 핵심 콘텐츠가 HTML에 포함되도록 강제함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Documentation-Strategy]], [[Scalability]], [[UX]], [[Reference]], [[Information-Society]], [[Product-Marketing]]
|
||||
- **Modern Tech/Tools**: Google Search Console, Ahrefs, SEMrush, Schema.org.
|
||||
---
|
||||
- [[Core-Web-Vitals]], [[Server-Side-Rendering-SSR]], [[Modern-Website-Architecture]], [[AI-Answer-Engine-Optimization]]
|
||||
- **Raw Source:** [[00_Raw/SEO.md]]
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: NLP-TF-IDF-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, nlp, tf-idf, information-retrieval, text-mining, keyword-extraction, search-engine]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Term Frequency-Inverse Document Frequency (TF-IDF)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "문서 내 빈도는 높되 전체 문서군에서는 희귀한 단어에 가중치를 부여하여, 흔한 소음(Stopwords)을 걷어내고 문서의 고유한 '정체성'을 결정짓는 핵심 키워드를 추출하라" — 텍스트 데이터에서 특정 단어가 문서 내에서 가지는 통계적 중요도를 계산하는 수치적 지표.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Local Relevance and Global Rarity Balance" — 특정 문서에 자주 등장하는 단어($TF$)의 점수는 높이고, 모든 문서에 흔하게 등장하는 단어($IDF$)의 점수는 깎아서, 해당 문서를 가장 잘 대표하는 특징을 추출하는 패턴.
|
||||
- **핵심 수식:** $TF-IDF(t, d, D) = TF(t, d) \times IDF(t, D)$
|
||||
- **TF (Term Frequency):** 문서 $d$에 단어 $t$가 나타나는 빈도.
|
||||
- **IDF (Inverse Document Frequency):** 단어 $t$가 포함된 문서의 비율의 역수에 로그를 취한 값.
|
||||
- **의의:** 검색 엔진의 문서 랭킹, 텍스트 요약, 유사도 측정 등 초기 자연어 처리 및 정보 검색 기술의 가장 강력하고 직관적인 기초 도구.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 단어의 순서나 맥락을 무시하는 'Bag-of-Words' 방식의 한계 때문에 딥러닝 임베딩(BERT 등)에 자리를 내주었으나, 여전히 키워드 기반 검색이나 데이터 전처리의 기준점(Baseline)으로서 압도적인 연산 효율성과 해석력을 제공함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 1,174개 지식 문서의 초기 자동 분류 및 핵심 태그 추출 시, 연산 자원을 최소화하면서도 정확도가 높은 TF-IDF 알고리즘을 1차 필터링 엔진으로 활용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Natural-Language-Processing-NLP]], [[Semantic-Search-with-AI]], [[Sparse-Data-Handling]], [[Similarity-Metrics-in-AI]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Term-Frequency-Inverse-Document-Frequency.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: SYS-IAC-TERRA-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [systems, infrastructure, terraform, iac, cloud-computing, devops, automation, hashicorp]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Terraform Infrastructure as Code (테라폼 코드형 인프라)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "인프라를 수동 조작의 대상이 아닌 '버전 관리되는 코드'로 승격시키고, 선언적인 명세(HCL)를 통해 원하는 최종 상태(Desired State)를 단번에 실현하라" — 클라우드 자원을 안전하고 효율적으로 구축, 변경, 관리하기 위한 오픈소스 코드형 인프라(IaC) 도구.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Declarative Specification and State-based Reconciliation" — 어떻게(How)가 아닌 무엇(What)을 만들지 정의하고, 현재 상태(State)와 정의된 코드 사이의 간극을 테라폼 엔진이 자동으로 계산하여 실행 계획(Plan)을 도출하는 패턴.
|
||||
- **핵심 구성 요소:**
|
||||
- **HCL (HashiCorp Configuration Language):** 인프라를 정의하기 위한 인간 가독성 높은 언어.
|
||||
- **Providers:** AWS, Azure, GCP 등 외부 서비스와 연결하는 플러그인.
|
||||
- **State File:** 실제 배포된 자원의 정보를 담고 있는 지도. 정합성 유지의 핵심.
|
||||
- **Modules:** 자주 쓰이는 인프라 패턴을 묶어 재사용 가능하게 만든 컴포넌트.
|
||||
- **의의:** 복잡한 멀티 클라우드 환경에서 인프라 구축의 일관성을 보장하고, 인적 오류를 방지하며, 인프라 자체를 소프트웨어처럼 테스트하고 협업할 수 있게 함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 초기에는 단순히 설치 스크립트의 발전형으로 여겨졌으나, 이제는 '불변 인프라(Immutable Infrastructure)' 철학의 핵심 도구로서 기존 자원을 수정하는 대신 새롭게 배포하고 교체하는 방식의 안정성을 극대화하는 방향으로 발전함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트 구동을 위한 클라우드 클러스터 확장 및 벡터 DB 인프라 구축 시, 모든 변경 사항을 추적 가능하게 관리하기 위해 테라폼을 표준 IaC 도구로 채택함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Cloud-Computing-Foundations]], [[Scalability-in-AI-Systems]], [[System-Architecture-Design]], [[Software-Architecture-Patterns]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Terraform-Infrastructure-as-Code.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: AI-SPEECH-TTS-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [ai, nlp, tts, speech-synthesis, generative-ai, audio-engineering, deep-learning]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Text-to-Speech Synthesis (TTS, 음성 합성)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "텍스트에 담긴 언어적 기호(Grapheme)를 소리의 최소 단위(Phoneme)로 해체하고, 딥러닝의 표현력을 빌려 인간 특유의 운율(Prosody)과 감정이 실린 파형(Waveform)으로 재탄생시켜라" — 문자를 자연스러운 인간의 목소리로 변환하는 기술.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Text Analysis and Neural Waveform Generation" — 입력된 텍스트의 문맥을 파악해 음소와 운율 정보를 생성하는 '프런트엔드'와, 이 정보를 바탕으로 실제 고품질 오디오 신호를 만들어내는 '보코더(Vocoder)'가 결합된 생성 패턴.
|
||||
- **기술적 진화:**
|
||||
- **Concatenative:** 녹음된 음성 조각들을 이어 붙이는 방식. 부자연스러운 연결이 한계.
|
||||
- **Parametric:** 통계 모델로 소리의 특징을 생성. 기계적인 음색이 단점.
|
||||
- **End-to-End Neural TTS:** Tacotron, FastSpeech 등 신경망이 텍스트에서 멜-스펙트로그램을 직접 생성.
|
||||
- **Neural Vocoder:** WaveNet, HiFi-GAN 등이 스펙트로그램을 인간 수준의 선명한 음성으로 복원.
|
||||
- **의의:** 오디오북, 가상 비서, 게임 캐릭터, 시각 장애인을 위한 정보 접근성 도구 등 인간과 기계 사이의 가장 인간적인 소통 접점을 형성함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 대량의 고품질 녹음 데이터가 필수였으나, 최근에는 단 몇 초의 목소리 샘플만으로도 대상의 음색을 완벽히 모사하는 '제로샷 보이스 클로닝(Zero-shot Voice Cloning)'과 다국어 통합 모델로 패러다임이 이동함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 멀티모달 보고서 브리핑 시, 정보의 전달력과 친근감을 극대화하기 위해 최신 확산 모델(Diffusion) 기반의 고품질 TTS 엔진을 기본 인터페이스로 활용함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Speech-Recognition-Foundations]], [[Signal-Processing-Foundations]], [[Natural-Language-Processing-NLP]], [[Generative-Adversarial-Networks-GAN]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Text-to-Speech-Synthesis.md]]
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: CS-THEORY-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [cs, theoretical-computer-science, algorithms, complexity-theory, p-vs-np, automata, computability]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Theoretical Computer Science (이론 컴퓨터 과학)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드를 한 줄 적기 전에 '이 문제는 해결 가능한가(Computability)'와 '얼마나 많은 자원이 필요한가(Complexity)'를 수학적으로 증명하여, 지능의 논리적 한계를 정의하라" — 컴퓨터 연산과 정보 처리의 수학적 기초를 탐구하는 학문.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Formal Logic and Resource-bounded Computation" — 추상적인 계산 모델(Turing Machine, Automata)을 통해 연산의 본질을 정의하고, 시간과 공간이라는 자원의 제약 하에서 문제의 난이도를 체계적으로 분류하는 패턴.
|
||||
- **핵심 분야:**
|
||||
- **Algorithms:** 문제 해결을 위한 절차 설계 및 효율성 분석 ($O$-notation).
|
||||
- **Complexity Theory:** P, NP, NP-complete 등 문제의 난이도 계층 연구.
|
||||
- **Computability Theory:** 정지 문제(Halting Problem)처럼 물리적으로 해결 불가능한 영역 식별.
|
||||
- **Automata & Formal Languages:** 기계가 언어를 인식하는 문법적 구조 연구.
|
||||
- **의의:** 현대의 모든 암호 기술(RSA 등), 컴파일러 설계, 데이터베이스 최적화, 그리고 인공지능의 학습 한계 정리 등 실제 기술 구현이 가능하게 만드는 '논리적 설계도' 역할.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 고전적 연산(Classical Computing)의 한계에 갇혀있던 시대에서 벗어나, 이제는 양자 컴퓨팅(Quantum Computing)과 확률적 알고리즘, 근사 알고리즘을 통해 기존에는 불가능해 보였던 영역에 도전하는 방식으로 지평이 넓어짐.
|
||||
- **정책 변화:** Antigravity 프로젝트는 에이전트의 복잡한 추론 로직 설계 시, 무의미한 연산 루프를 방지하고 최적의 시간 복잡도를 달성하기 위해 이론 컴퓨터 과학의 '결정 가능성(Decidability)' 원칙을 엄격히 준수함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Algorithm-Complexity-Analysis]], [[Optimization-Algorithms]], [[Machine-Learning-Foundations]], [[Cryptography-Basics]]
|
||||
- **Raw Source:** [[10_Wiki/Topics/AI/Theoretical-Computer-Science.md]]
|
||||
Reference in New Issue
Block a user