docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
This commit is contained in:
@@ -0,0 +1,27 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Programming/Architecture"
|
||||
generated_at: 2026-06-22T18:00:44.986Z
|
||||
sources: ["의존성_주입과_서비스_인터페이스", "이벤트_소싱_스토어_패턴", "동시성_제어_Lock_Queue_Transaction", "ConnectAI_아키텍처_개요"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Programming/Architecture
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: ConnectAI의 전체적인 아키텍처 구조는 어떻게 구성되어 있나요?** — A: ConnectAI는 기능별 폴더 경계를 가진 **계층형 모듈 아키텍처**를 따릅니다. `core/lib` (인프라) → `memory/intelligence` (역량) → `features` (도메인 기능) 순으로 계층이 구성되며, 하위 계층은 상위 계층을 알지 못하는 구조입니다. [ConnectAI 아키텍처 개요]
|
||||
- **Q: 의존성 주입(DI)을 통해 얻는 이점과 구체적인 방법은 무엇인가요?** — A: 객체가 협력자를 직접 만들지 않고 외부에서 받게 함으로써 모듈의 순수성을 유지하고 테스트 가능성을 높입니다. 생성자 옵션 객체나 함수 타입을 통해 구현을 주방하며, `IAIService`와 같은 인터페이스로 계약을 정의합니다. [의존성 주입과 서비스 인터페이스]
|
||||
- **Q: 이벤트 소싱 스토어 패턴은 어떤 방식으로 데이터를 관리하나요?** — A: 현재 상태를 덮어쓰는 대신, 발생한 이벤트를 **Append-only(추가만 가능)** 방식으로 JSONL 파일에 기록합니다. 현재 상태는 저장된 이벤트들을 재생(`computeStates`)하여 도출합니다. [이벤트 소싱 스토어 패턴]
|
||||
- **Q: 자바스크립트 환경에서 비동기 작업 시 발생할 수 있는 경쟁 상태(Race Condition)를 어떻게 방지하나요?** — A: 세 가지 장치를 사용합니다. 첫째, 자원별 **비동기 락(AsyncLock)**을 통해 작업의 직렬화를 보장하고, 둘째, **동시성 제한 큐**로 I/O 폭주를 막으며, 셋째, 파일 변경 시 **보상 트랜잭션**을 통해 실패 시 원복할 수 있도록 합니다. [동시성 제어 Lock Queue Transaction]
|
||||
|
||||
## 핵심 사실
|
||||
- **ConnectAI 아키텍처:** 308개의 TypeScript 파일로 구성된 VS Code 확장형 지식 OS이며, `extension.ts`는 조립과 등록 역할만 수행하는 얇은 entry point를 가집니다. [ConnectAI 아키텍처 개요]
|
||||
- **이벤트 소싱 구현:** JSONL 형식을 사용하며, 제네릭 팩토리(`createEventStore<E>`)를 통해 중복된 I/O 로직을 통합 관리합니다. [이벤트 소싱 스토어 패턴]
|
||||
- **동시성 제어 전략:** `AsyncLock`은 Promise 체인을 활용하며, `Symbol` 토큰을 사용하여 락 해제 시 발생할 수 있는 race condition을 방지합니다. [동시성 제어 Lock Queue Transaction]
|
||||
|
||||
## 문서 간 연결
|
||||
- **공통 주제 (Architecture):** 모든 문서는 ConnectAI의 확장 가능하고 안정적인 시스템 구축을 위한 소프트웨어 설계 패턴(Dependency Injection, Event Sourcing, Concurrency Control)을 다루고 있습니다.
|
||||
- **상호 작용:**
|
||||
- `의존성 주입` 패턴은 `아키텍처 개요`에서 언급된 계층 간 결합도를 낮추는 핵심 기술로 사용됩니다.
|
||||
- `이벤트 소싱`과 `동시성 제어`는 파일 시스템 기반의 데이터 영속화 및 안정적인 자원 관리를 위한 구체적인 구현 방법론을 제시합니다.
|
||||
Reference in New Issue
Block a user