docs(10_Wiki): W3Schools 위키화 — HTML/CSS/JavaScript(core)
W3Schools 튜토리얼을 P-Reinforce v3.1 포맷으로 위키화(영어 본문, 한/영 섹션 헤더). - Topic_HTML: 59문서 (튜토리얼+예제, 레퍼런스/메타 제외) - Topic_CSS: 190문서 (메인 + Advanced/Flexbox/Grid/RWD 전체) - Topic_JavaScript: 120문서 (코어 언어; Temporal/DOM상세/BOM/WebAPI/AJAX/jQuery/Graphics 등은 후속) 각 폴더 00_INDEX.md(MOC) 포함. 코드 verbatim, 미확인분은 "Not found in source" 표기. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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)을 다루고 있습니다.
|
||||
- **상호 작용:**
|
||||
- `의존성 주입` 패턴은 `아키텍처 개요`에서 언급된 계층 간 결합도를 낮추는 핵심 기술로 사용됩니다.
|
||||
- `이벤트 소싱`과 `동시성 제어`는 파일 시스템 기반의 데이터 영속화 및 안정적인 자원 관리를 위한 구체적인 구현 방법론을 제시합니다.
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Programming/Conventions"
|
||||
generated_at: 2026-06-22T18:01:03.587Z
|
||||
sources: ["코딩_컨벤션과_주석_철학", "프롬프트_엔지니어링_패턴"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Programming/Conventions
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: 코딩 컨벤션에서 주석을 작성할 때 가장 중요하게 고려해야 할 원칙은 무엇인가요?** — A: '무엇'을 하는지가 아니라, 왜 그렇게 했는지(**Why**)와 왜 다른 방법이 아니었는지(대안 기각 이유), 그리고 과거의 버그 사례를 남기는 **Post-mortem 주석**을 작성하는 것이 핵심입니다. [코딩 컨벤션과 주석 철학]
|
||||
- **Q: 프롬프트 엔지니어링에서 '블록 조립' 방식이란 무엇인가요?** — A: 시스템 프롬프트를 역할, 규칙, 컨텍스트, 출력 형식 등 독립적인 요소로 나누어 `[EPISTEMIC GUARD]`와 같이 명명된 블록 형태로 만들고, 필요에 따라 이를 조합하여 사용하는 방식입니다. [프롬프트 엔지니어링 패턴]
|
||||
- **Q: 작은 규모의 LLM(예: Gemma)을 사용할 때 발생할 수 있는 문제와 대응 방안은?** — A: System 프롬프트가 없으면 환각(Hallucination) 현상을 일으키며 답변을 거절할 수 있으므로, 반드시 **System 메시지를 통해 강하게 Grounding**해야 합니다. 또한 규칙을 번호로 매겨 명시하고 부정적 제약(Negative Constraint)을 활용해야 합니다 *합니다*. [프롬프트 엔지니어링 패턴]
|
||||
- **Q: 코드에서 `??` (Nullish coalescing operator)를 사용하는 권장 패턴이 있나요?** — A: `0`이나 `''`(빈 문자열)처럼 유효한 값이 의미가 있는 경우, `||` 대신 `??`를 사용하여 의미 있는 기본값을 보존해야 합니다. [코딩 컨벤션과 주석 철학]
|
||||
- **Q: 프롬프트에서 JSON 출력을 강제할 때 발생할 수 있는 위험과 해결책은?** — A: 모델이 JSON 외의 잡설(예: `## 마커`)을 섞어 출력할 수 있으므로, 균형 괄호 `{}`를 스캔하여 추출하는 **강건한 파서(Robust Parser)**와 사후 정제 로직을 함께 설계해야 합니다. [프롬프트 엔지니어링 패턴]
|
||||
|
||||
## 핵심 사실
|
||||
- **코딩 컨벤션의 핵심 가치:** 주석은 코드의 의도(Why)와 과거의 실수(Post-mortem)를 학습시켜, LLM이 코드의 논리적 함정까지 이해하도록 돕는 최고의 학습 신호입니다. [코딩 컨벤션과 주석 철학]
|
||||
- **프롬프트 설계 전략:** 프롬프트는 조립 가능한 블록 형태여야 하며, 출력 형식은 파싱 가능한 JSON/템플릿으로 강제하고, 검색 근거가 없을 때는 가드 지시를 강화하는 동적 조절이 필요합니다. [프롬프트 엔지니어링 패턴]
|
||||
- **코드 작성 패턴:** 함수명은 동사구로, Boolean은 `is*`/`should*` 접두사를 사용하며, 내부 전용 메서드는 `_` 접두사를 사용하는 것이 권장됩니다. [코딩 컨벤션과 주석 철학]
|
||||
|
||||
## 문서 간 연결
|
||||
- **공통 주제:** 두 문서 모두 **"예측 가능성과 신뢰성 확보"**를 공통 주제로 합니다. 코딩 컨벤션은 개발자와 LLM이 실수하지 않도록 '의도'와 '근거'를 남기는 것을 강조하며, 프롬프트 패턴은 모델이 정해진 규칙을 벗어나지 않도록 '구조화된 블록'과 '강한 제약'을 설계하는 것을 다룹니다.
|
||||
- **상호 보완성:** 코딩 컨벤션에서 언급된 "LLM이 의도까지 학습하게 하는 주석"은 프롬프트 엔지니어링 패턴에서 말하는 "작은 모델의 Grounding 및 규칙 준수"를 구현하기 위한 기초 데이터(학습 신호) 역할을 합니다.
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Programming/Language"
|
||||
generated_at: 2026-06-22T18:00:36.586Z
|
||||
sources: ["에러_처리와_커스텀_에러", "모듈_시스템과_프로젝트_구성", "비동기_프로그래밍_Promise_async_await", "TypeScript_고급_타입"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Programming/Language
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: 에러 발생 시 시스템의 본 흐름을 유지하기 위해 어떤 전략을 사용하나요?** — A: 부가 기능(메모리 추출, 텔레메이트리 등)의 실패는 `catch {}`를 통해 의도적으로 삼키고, 이를 통해 "Graceful degradation"을 구현하여 본 흐름이 깨지지 않도록 합니다. [에러 처리와 커스텀 에러]
|
||||
- **Q: 비동기 작업 중 사용자가 'Stop'을 눌렀을 때 어떻게 중단시키나요?** — A: `AbortSignal`과 `AbortController`를 사용하여 외부에서 비동기 작업을 취소할 수 있는 표준 메커니즘을 활용합니다. 특히 타임아웃과 사용자 취소를 결합하여 즉각적인 중단을 구현합니다. [비동기 프로그래밍 Promise async await]
|
||||
- **Q: 모듈 시스템에서 `named export`를 주로 사용하는 이유는 무엇인가요?** — A: 자동완성, 일관된 이름 유지, 리팩터링의 안전성을 확보하기 위해서입니다. ConnectAI는 `default export`를 사실상 배제하고 이 방식을 채택합니다. [모듈 시스템과 프로젝트 구성]
|
||||
- **Q: TypeScript에서 런타임 검증을 컴파일 타입 좁히기로 연결하는 방법은?** — A: `x is T` 형태의 '타입 가드'를 사용하여, 함수 내에서 런타임 검증이 성공하면 컴파일러가 해당 타입을 특정 타입으로 인식하도록(Type Narrowing) 만듭니다. [TypeScript 고급 타입]
|
||||
- **Q: 에러 클래스를 설계할 때 어떤 정보를 포함해야 하나요?** — A: `Error`를 상속받아 도메인별로 분기하며, 경로, 엔진, 상태 코드와 같은 추가적인 컨텍스트(Context)를 담아 잡는 쪽에서 실패 원인을 명확히 알 수 있게 합니다. [에러 처리와 커스텀 에러]
|
||||
|
||||
## 핵심 사실
|
||||
- **에러 처리:** `Error` 상속 계층을 통해 `instanceof`로 분기하며, 기술적 에러를 사용자 행동 지침(title/message/action)으로 번역하는 프로세스를 갖춤. [에름 처리와 커스텀 에러]
|
||||
- **모듈 구조:** 308개의 파일을 `esbuild` 단일 번들로 통합하며, `barrel(index.ts)`을 통해 외부 진입점을 단일화함. [모듈 시스템과 프로젝트 구성]
|
||||
- **비동기 제어:** `Promise.race`를 이용해 '작업 vs 타임아웃' 경쟁 구조를 만들고, 큐(Queue)를 통해 동시 실행 수를 CPU 코어 수에 맞춰 제한함. [비异步 프로그래밍 Promise async await]
|
||||
- **타입 안전성:** 판별 유니온(Discriminated union)을 사용하여 결과값의 성공/실패(`{ ok: true } | { ok: false }`)를 명확히 분기 처리함. [TypeScript 고급 타입]
|
||||
|
||||
## 문서 간 연결
|
||||
- **공통 주제 (Robustness & Reliability):** 모든 문서는 단순히 기능을 구현하는 것을 넘어, 에러를 예측하고(에러 처리), 취소 가능한 비동기를 만들며(비동기), 타입을 통해 런타임 오류를 방지하는(TypeScript 고급 타입) 등 **'견고한 소프트웨어 설계'**라는 공통된 지향점을 공유합니다.
|
||||
- **상호 작용:**
|
||||
- **에러 처리 + TypeScript:** 에러 클래스의 구조와 판별 유니온을 이용한 결과값 분기 처리는 서로 연결되어 안정적인 예외 처리를 완성합니다.
|
||||
- **모듈 시스템 + 비동기:** 모듈의 `dynamic import`는 비동기 프로그래밍의 `await` 패턴과 결합하여 초기 로딩 속도를 최적화하는 데 사용됩니다.
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: lessons"
|
||||
generated_at: 2026-06-22T18:00:54.121Z
|
||||
sources: ["2026-06-16-correction-ccoc가-아니라-sisihosi야", "2026-06-15-correction-대화의-주제-기간-오차범위-와-다른-내용-영상-길이-을-놓침", "2026-06-15-correction-수치-오류를-바로잡기-위한-논리적-근거-재검토-필요", "2026-06-12-correction-요구한-구성-요소-기대-효과-를-누락하고-다른-포맷으로-작성함"]
|
||||
---
|
||||
|
||||
# 소화 노트: lessons
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: 회의록 내용 중 'CCCOC'가 아닌 올바른 프로젝트 명칭은 무엇인가요?** — A: SISIHOSI입니다. [2026-06-16-correction-ccoc가-아니라-sisihosi야]
|
||||
|
||||
|
||||
- **Q: 영상 제작 공정에서 3주~5주라는 오차 범위가 발생한 이유는 무엇인가요?** — A: 기획은 완료되었으나 소스(VFX, 사운드 등) 제작 여부에 따라 작업 기간이 달라지기 때문입니다. [2026-06-15-correction-대화의-주제-기간-오차범위-와-다른-내용-영상-길이-을-놓침]
|
||||
|
||||
|
||||
- **Q: 영상 길이가 1분 30초로 고정될 경우, 제작 기간은 어떻게 변동되나요?** — A: 리소스가 준비된 상태(편집/합성만 남은 경우)라면 약 3주, 리소스 제작이 추가로 필요한 경우에는 약 5주가 소요됩니다. [2026-06-15-correction-수치-오류를-바로잡기-위한-논리적-근거-재검토-필요]
|
||||
|
||||
|
||||
- **Q: 계열사가 프로젝트 참여를 꺼리는 상황에서 취해야 할 전략적 방향은 무엇인가요?** — A: 프로젝트의 정체성을 '업무 전달'이 아닌, 비용 절감, 수익 창출, 리소스 최적화와 같은 '가치 증폭기(Value Multiplier)'로 전환하여 계열사의 이득을 강조해야 합니다. [2026-06-12-correction-요구한-구성-요소-기대-효과-를-누락하고-다른-포맷으로-작성함]
|
||||
|
||||
## 핵심 사실
|
||||
- **프로젝트 현황**: iOS 기기의 메모리 부족 문제 해결을 위해 PlayCanvas, Babylon.js 등 웹GL 플랫폼 조사가 필요하며, 가우시안 스플래팅 R&D가 진행 중입니다. [2026-06-16-correction-ccoc가-아니라-sisihosiya]
|
||||
- **제작 공정 기준**: 영상 제작 기간은 '리소스 준비 여부'에 따라 3주(준비 완료) 또는 5주(제작 필요)로 구분하여 관리하는 것이 효율적입니다. [2나 2026-06-15-correction-대화의-주제-기간-오차범위-와-다른-내용-영상-길이-을-놓침]
|
||||
- **전략적 포지셔닝**: 계열사의 추가 업무 부담을 줄이기 위해 '비용 절감형', '수익 창출형', '리소스 최적화형' 모델을 제안해야 합니다. [2026-06-12-correction-요구한-구성-요소-기대-효과-를-누락하고-다른-포맷으로-작성함]
|
||||
|
||||
## 문서 간 연결
|
||||
- **기술적 이슈와 프로젝트 관리**: iOS 메모리 문제(기술적 이슈)와 영상 제작 기간 관리(프로젝트 스케줄링)는 모두 '예측 불가능한 리스크'를 줄이기 위한 검증과 기준 확립을 공통적으로 다루고 있습니다.
|
||||
- **논리적 정정의 흐름**: 모든 문서는 사용자의 정정 사항(Ground Truth)을 바탕으로, 기존 AI 답변의 오류(수치 오류, 맥락 누락, 지시 불이행)를 바로잡고 새로운 논리적 근거를 재구축하는 과정을 보여줍니다.
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: (두뇌 루트)"
|
||||
generated_at: 2026-06-22T18:01:11.571Z
|
||||
sources: ["ASTRA 기능 인벤토리"]
|
||||
---
|
||||
|
||||
# 소화 노트: (두뇌 루트)
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: ASTRA의 '주간 성장 사이클'은 어떤 과정으로 진행되나요?** — A: 검색 평가(골든셋) $\rightarrow$ 학습 큐 갱신(Need Engine) $\rightarrow$ 지식 노후 점검 $\rightarrow$ 성장 리포트 $\rightarrow$ 승인된 학습 자동 실행(Research Agent, 사이당 최대 3건) 순으로 진행됩니다. [ASTRA 기능 인벤토리]
|
||||
- **Q: '지식 사전 소화(Sleep-time Digest)' 기능의 역할은 무엇인가요?** — A: 매일 지정된 시각(유휴 시간)에 최근 7일 내에 변경된 두뇌 지식을 찾아 폴더별 '소화 노트'(`<두뇌>/Digests/`)로 변환하는 자동화 기능입니다. [ASTRA 기능 인벤토리]
|
||||
- **Q: ASTRA의 데일리 브리핑은 어떤 정보를 제공하나요?** — A: 평일(월~금) 지정된 시각에 오늘의 캘린더 일정과 Google Tasks(오늘 마감, 기한 경과, 조건부 대기 항목 포함)를 정리하여 텔레그램으로 발송합니다. [ASTRA 기능 인벤토리]
|
||||
- **Q: ASTRA의 메모리 시스템은 어떻게 구성되어 있나요?** — A: 최근 대화 메시지를 사용하는 단기 메모리(`memoryShortTermMessages`), 최근 저장된 채팅 세션을 활용하는 중기 메모리(`memoryMediumTermSessions`), 그리고 관련 Markdown 파일을 활용하는 장기 메모리(`memoryLongترFiles`)로 계층화되어 있습니다. [ASTRA 기능 인벤토리]
|
||||
- **Q: 텔레그램 봇 설정 시 필요한 요소는 무엇인가요?** — A: `telegram.enabled` 활성화, `telegram.allowedChatIds`(허용할 ID 목록), 그리고 특정 에이전트 범위를 지정하기 위한 `telegram.defaultAgent` 설정 등이 필요합니다. [ASTRA 기능 인벤토리]
|
||||
|
||||
## 핵심 사실
|
||||
- **문서의 성격**: 이 문서는 ASTRA의 기능 목록을 담은 '기능 인벤토리'이며, 소스 코드(`package.json`)에서 자동 생성되는 참조용 문서입니다. [ASTRA 기능 인벤토리]
|
||||
- **주요 자동화 프로세스**:
|
||||
- **성장 사이클**: 주간 단위로 평가와 학습을 자동 수행합니다.
|
||||
- **지식 관리**: 지식 노후 점검, 충돌 스캔, 사전 소화(Digest) 기능을 통해 지식의 최신성을 유지합니다.
|
||||
- **알림 서비스**: 데일리 브리핑 및 텔레그램 연동을 통한 일정/업무 관리를 지원합니다. [ASTRA 기능 인벤토리]
|
||||
- **기술적 특징**: LLM 활용을 위한 다양한 파라미터(Temperature, Context Window, Map-Reduce 전략 등)와 멀티 에이전트 워크플로우(`multiAgentEnabled`) 제어 옵션을 포함하고 있습니다. [ASTRA 기능 인벤토리]
|
||||
|
||||
## 문서 간 연결
|
||||
- **자동 생성 및 현행화**: 이 문서는 `package.json`을 통해 기계적으로 생성되므로, ASTRA의 실제 기능과 일치하는 '항상 현행' 상태를 유지해야 하는 근거 문서입니다. [ASTRA 기능 인벤토리]
|
||||
- **기능적 연관성**: '사용자 명령(명령어)' 섹션은 사용자가 직접 실행할 수 있는 액션을 나타내며, '설정으로 제어되는 동작' 섹션은 그 명령어들이 작동하는 환경과 자동화 로직을 정의합니다. [ASTRA 기능 인벤토리]
|
||||
Reference in New Issue
Block a user