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:
Antigravity Agent
@@ -0,0 +1,31 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Alignment Knowledge"
|
||||
generated_at: 2026-06-30T18:00:30.881Z
|
||||
sources: ["2026-06-26 핸드폰에 붙이는 필름을 판매하고 있어. 기능은 3d 앱"]
|
||||
---
|
||||
|
||||
# 소화 노트: Alignment Knowledge
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: 이 제품의 가장 큰 기술적 단점은 무엇인가요?** — A: 3D 입체감을 구현하는 필름 특성상, 일반 상태에서 화면을 볼 때 미세한 줄이 보여 예민한 사용자는 픽건(pixel)이 깨져 보인다고 느낄 수 있습니다. [원본 요청]
|
||||
- **Q: 현재 지원 가능한 스마트폰 모델 범위는 어떻게 되나요?** — A: 아이폰 15, 16, 17 모델만 지원하며, 안드로이드 기기는 지원하지 않는다는 약점이 있습니다. [원본 요청]
|
||||
- **Q: 제품을 통해 사용자가 경험할 수 있는 기능은 무엇인가요?** — A: 로컬 모바일 장비에 저장된 영상과 사진을 3D 입체감으로 볼 수 있으며, 회사에서 제공하는 뮤직 비디오 콘텐츠를 시청할 수 있습니다. [원본 요청]
|
||||
- **Q: 현재 제품의 가격과 마케팅 예산 상황은 어떤가요?** — A: 필름 가격은 4만 원이며, 약 2억 원의 마케팅 예산이 있으나 이 비용을 사용하지 않고도 홍보할 수 있는 아이디어가 필요한 상태입니다. [확인된 정보]
|
||||
- **Q: 주요 타겟 고객층은 누구로 파악되나요?** — A: 구매자 기록을 바탕으로 볼 때, 35세 이상의 연령층이 주를 이룹니다. [원본 요청]
|
||||
|
||||
## 핵심 사실
|
||||
- **제품 특징**: 3D 앱 사용 시 화면에 입체감을 부여하는 핸드폰 필름 (가격 4만 원).
|
||||
- **기술적 한계 및 단점**:
|
||||
- 일반 화면 시청 시 미세한 줄(pixel 깨짐 현상 유사)이 보일 수 있음.
|
||||
- 안드로이드 기기 지원 불가 (아이폰 15, 16, 17 전용).
|
||||
- 자사 제공 콘텐츠(뮤직 비디오 등)의 수량이 매우 빈약함.
|
||||
- **비즈니스 상황**: 마케팅 예산 2억 원 보유 중이나, 저비용/무료 배포 방식 등 효율적인 홍보 전략이 필요함.
|
||||
- **고객 데이터**: 주 구매층은 35세 이상임.
|
||||
|
||||
## 문서 간 연결
|
||||
- **제품 기능과 단점의 상관관계**: 제품의 핵심 가치(3D 입체감)가 기술적 한계(화면 줄 생김 현상)와 직접적으로 연결되어 있음.
|
||||
- **서비스 내용과 콘텐츠 부족 문제**: 제공되는 서비스(영상/사진 3D 변환)는 명확하나, 이를 뒷받침할 자사 콘텐츠의 양이 매우 적다는 결론에 도달함.
|
||||
- **마케팅 전략 수립의 필요성**: 확보된 예산(2억)과 제품의 약점(안드로이드 미지원, 콘텐츠 부족) 사이의 간극을 메울 마케팅 아이디어가 요구되는 상황임.
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Projects"
|
||||
generated_at: 2026-06-30T18:00:18.788Z
|
||||
sources: ["AI가상피팅_커머스_상사보고서_v1", "AI가상피팅_커머스_실현가능성검토_v1"]
|
||||
---
|
||||
|
||||
# 소화 노트: Projects
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
|
||||
- **Q: 이 사업의 핵심 기술적 한계와 현실적인 대안은 무엇인가요?** — A: 원래 구상했던 '실시간 영상'이나 '3D 물리 엔진' 기반의 피팅은 2026년 현재 기술로 불가능합니다. 대신 '사진 한 장으로 옷을 입혀 보여주는' 정지 이미지 방식이 이미 검증된 상용 기술(구글, 에이블리 등)이며, 이를 활용하는 것이 가장 현실적입니다. [AI가상피팅_커머스_상사보고서_v1], [AI가상피팅_커머스_실현가능성검토_v1]
|
||||
- **Q: 서비스 출시를 위해 어떤 전략을 취해야 하나요?** — A: 처음부터 자체 기술을 개발하기보다, 검증된 외부 AI API(FASHN, Kling 등)를 빌려 6~8주 내에 빠르게 MVP(최소 기능 제품)를 출시하는 '단계적 전략'을 권고합니다. 이후 데이터와 매출이 증명되면 그때 자체 기술로 전환하여 원가를 절감해야 합니다. [AI가상피팅_커머스_상사보고서_v1], [AI가상피팅_커머스_실현가능성검토_v1]
|
||||
- **Q: 오픈소스 AI 모델을 가져다 써도 법적인 문제가 없나요?** — A: 주의가 필요합니다. IDM-VTON, CatVTON 같은 우수한 오픈소스 모델은 '비상업적 이용(CC BY-NC-SA)'만 허용되는 경우가 많아, 이를 그대로 상용 서비스에 사용하면 라이선스 위반 리스크가 있습니다. [AI가상피팅_커머스_실현가능성검토_v1]
|
||||
- **Q: 사업 추진 시 예상되는 위험 요소와 대비책은 무엇인가요?** — A: 외부 기술 의존도, 개인정보(얼굴 사진) 보호, AI 생성물 표시 의무(AI 기본법) 등이 주요 리스크입니다. 이에 대해 여러 업체를 교체 가능한 구조로 설계하고, 사진은 최소 보관·즉기 삭제하며, 결과물에 "AI 생성" 표시를 탑재하는 등의 대비책이 필요합니다. [AI가상피팅_커머스_상사보고서_v1]
|
||||
|
||||
## 핵심 사실
|
||||
- **기술적 현황**: 정지 이미지 기반 가상 피팅(VTON)은 1장당 5~17초 내외로 상용화 수준임. 반면 동영상이나 3D 물리 시뮬레이션 기술은 현재 비현실적임. [AI가상피팅_커머스_실현가능성검토_v1]
|
||||
- **시장 사례**: 국내 에이블리는 AI 옷입기 기능 출시 후 매출이 55% 증가하고 이용자가 38% 늘어나는 성과를 보임. [AI가상피팅_커머스_상사보고서_v1]
|
||||
- **비용 구조**: 외부 API 사용 시 회당 약 100원 미만(약 $0.07~$0.075)의 비용이 발생함. [AI가상피팅_커머스_상사보고서_v1], [AI가상피팅_커머스_실현가능성검토_v1]
|
||||
- **개발 로드맵**: 6~8주 내 시범 서비스 출시 → 데이터 확보 → 자체 기술 전환(원가 절감) 순의 단계적 추진을 권고함. [AI가상피팅_커머스_상사보고서_v1]
|
||||
|
||||
## 문서 간 연결
|
||||
- **공통 주제**: 두 문서 모두 신규 사업인 'AI 가상 의상 피팅 서비스'에 대해 **"기술적 현실을 반영한 조건부 추진(Go)"**을 공통적으로 제안하고 있습니다.
|
||||
- **보완 관계**: [상사보고서]는 사업의 목적, 결론, 단계적 실행 방안 등 **의사결정권자의 관점**에서 비즈니스 가치를 설명하며, [실현가능성 검토서]는 기술적 상세 스펙(API 단가, 라이선스 리스크, 렌더링 시간 등)을 다루며 **기술적 실현 가능성을 정밀하게 뒷받침**합니다.
|
||||
- **상충 사항**: 두 문서 모두 '실시간 영상/3D' 구현은 불가능하다는 점을 명시하며 기술적 한계에 대해 일치된 견해를 보입니다.
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Agent"
|
||||
generated_at: 2026-06-18T18:01:28.797Z
|
||||
sources: ["self envolving", "self evolving", "Value Proposition Canvas", "Zero-Trust Foundation Models"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Agent
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: Self-Evolving Agent(자가 진화 에이전트)란 무엇이며, 기존 LLM과 무엇이 다른가요?** — A: 정적인 모델의 한계를 넘어, 인간의 개입 없이 스스로 코드, 도구, 아키텍처를 재설계하여 성능을 개선하는 지능형 시스템입니다. 기존 모델이 고정된 파이프라인을 따르는 것과 달리, 실시간 데이터와 경험을 통해 자율적으로 변화합니다. [self envolving / self-evolving]
|
||||
- **Q: Value Proposition Canvas(VPC)를 사용할 때 '검증 공백'이 발생하는 경우는 언제인가요?** — A: 제품의 고통 완화제(Pain Relievers)가 고객의 최상위 3개 과업(Jobs-to-be-Done)과 제대로 연결되지 않을 때 발생합니다. [Value Proposition Canvas]
|
||||
- **Q: Zero-Trust Foundation Models(ZTFM)의 핵심 보안 원칙은 무엇인가요?** — A: '지속적 검증'과 '최소 권한 원칙'입니다. 에이전트의 모든 상호작용을 매번 확인하고, 임무 수행에 필요한 최소한의 권한만 부여하여 피해를 최소화합니다. [Zero-Trust Foundation Models]
|
||||
- **Q: 자가 진화 에이전트에서 '재귀적 자가 설계(Recursive Self-Design)'는 어떤 의미인가요?** — A: 단순히 하이퍼파라미터를 최적화하는 수준을 넘어, 에이전트의 프롬프트 정책, 워크플로우, 실행 메커니즘 등 시스템의 스캐폴드 자체를 수정 대상으로 삼는 것을 의미합니다. [self envolving / self-evolving]
|
||||
- **Q: VPC를 통해 제품 개발 과정에서 수행할 수 있는 검증 단계는 무엇인가요?** — A: 문제 검증(문제가 해결 가치가 있는가), 솔루션 검증(해결책이 근본 원인을 해결하는가), 비즈니스 모델 검증(고객이 실제 비용을 지불하는가)의 3단계 계층 구조를 따릅니다. [Value Proposition Canvas]
|
||||
|
||||
## 핵심 사실
|
||||
- **Self-Evolving Agent의 진화 차원**: 무엇을(모델/정책, 컨텍스트/메모리, 도구/기술), 언제(실행 중 진화 vs 실행 간 진화) 진화시킬 것인지가 핵심입니다. [self envolving / self-evolving]
|
||||
- **VPC의 전략적 가치**: 제품 기능과 고객 요구 사이의 정렬을 시각화하여 '문제-해액 적합성'을 검증하고 자본 효율성을 극대화합니다. [Value Proposition Canvas]
|
||||
- **ZTFM의 적용 분야**: 6G 생태계 및 IoT 환경에서 에이전트 간의 안전한 협업과 적대적 공격으로부터 시스템을 보호하는 데 필수적인 인프라입니다. [Zero-Trust Foundation Models]
|
||||
|
||||
## 문서 간 연결
|
||||
- **기술적 상호보완성**: `self-evolving` 기술은 자율성이 높아지는 만큼 보안 위협이 커지므로, 이를 방어하기 위한 `Zero-Trust Foundation Models`의 도입이 필수적인 관계에 있습니다.
|
||||
- **비즈니스와 기술의 결합**: `Value Proposition Canvas`는 제품의 가치를 정의하는 도구이며, `self-evolving` 에이전트가 생성하는 새로운 기능이나 '도구 제작(Tool Maker)' 패턴은 이러한 가치 제안을 실현하는 기술적 수단이 될 수 있습니다.
|
||||
- **패턴의 공통성**: 여러 문서에서 '자율적 학습', '재귀적 구조', '지속적 검증'과 같은 자동화된 피드백 루프와 자기 개선(Self-improvement) 메커즘을 공통적으로 다루고 있습니다.
|
||||
@@ -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,30 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Programming/Engineering_Intelligence"
|
||||
generated_at: 2026-06-18T18:01:19.599Z
|
||||
sources: ["안티패턴_카탈로그", "엔지니어링_트레이드오프_분석", "아키텍처_휴리스틱", "디버깅_플레이북"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Programming/Engineering_Intelligence
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: 코드를 작성할 때 에러를 `try { ... } catch {}`로 처리하면 왜 위험한가요?** — A: 에러를 이유 없이 삼키면(Silent swallow) 실패가 숨겨져 디버깅이 불가능해지고 시스템이 잘못된 상태로 진행될 수 있기 때문입니다. 단, 부가 작업에 한해 이유를 주석으로 명시하고 처리하는 것은 허용됩니다. [안티패턴 카탈로그]
|
||||
- **Q: 에이전트 설계를 할 때 '에이전트 남발'을 피하기 위한 기본 원칙은 무엇인가요?** — A: 기본값은 "에이전트를 늘리지 않는 것"입니다. 문제마다 새 페르소나를 추가하면 컨텍스트 누적, 자원 폭증, 디버깅 난해 등의 문제가 발생하므로, 단일 작성자가 다중 역할을 수행하거나 정말 필요한 경우에만 순차적으로 협업하도록 설계해야 합니다. [안티패턴 카탈로그, 아키텍처 휴리스틱]
|
||||
- **Q: 5계층 메모리 시스템에서 발생할 수 있는 주요 장애와 진단 방법은 무엇인가요?** — A: 오래된 사실을 현재로 착각하거나 기억이 반영되지 않는 장애가 발생할 수 있습니다. 이는 `expiresAt` 미설정이나 추출 실패 때문일 수 있으며, 진단 시에는 계층별 `buildContext` 출력을 확인해야 합니다. [디버링 플레이북, 5계층 메모리 시스템]
|
||||
- **Q: 하이브리드 검색(RAG)의 성능을 높이기 위한 예방 조치는 무엇인가요?** — A: 정기적인 평가 하니스 실행, 정규화 일관성 유지, 인덱스 무결성 점검 등이 필요합니다. [디버깅 플레이북, RAG 검색 파이프라인]
|
||||
- **Q: 동시성 제어를 위한 락(Lock) 사용 시 반드시 지켜야 할 예방 규칙은 무엇인가요?** — A: 락은 반드시 `try/finally` 구문을 사용하여 release 누락을 방지해야 하며, 토큰 기반으로 정리하고 무거운 작업은 직렬화해야 합니다. [디버깅 플레이북, 동시성 제어 Lock Queue Transaction]
|
||||
|
||||
## 핵심 사실
|
||||
- **안티패턴의 정의:** 안티패턴은 처음에는 그럴듯해 보이지만 시간이 지나면 버그와 복잡도를 유발하는 습관이며, ConnectAI의 실제 사례에서 추출된 피해야 할 목록입니다. [안티패턴 카탈로그]
|
||||
- **설계의 본질:** 모든 설계는 무언가를 최적화하기 위해 다른 무언가를 희생한 결과(Trade-off)입니다. [엔지니어링 트레이드오프 분석]
|
||||
- **아키텍처 결정 규칙(휴리스틱):** 좋은 설계자는 0부터 고민하는 것이 아니라, "언제 X를 만들고 언제 만들지 않을 것인가"에 대한 결정 규칙을 적용합니다. [아키텍처 휴리스틱]
|
||||
- **디버깅의 원칙:** 디버깅은 증상에서 근본 원인으로 좁혀 들어가는 체계적인 절차이며, '증상 $\rightarrow$ 가설 $\rightarrow$ 검증 $\rightarrow$ 최소 변경'의 과정을 거칩니다. [디버깅 플레이북]
|
||||
|
||||
## 문서 간 연결
|
||||
- **공통 주제:** 모든 문서는 소프트웨어 엔지니어링의 **'의사결정 지능(Decision Intelligence)'**을 다루고 있습니다. 안티패턴은 '피해야 할 것', 트레이드오프는 '선택의 근거', 휴리스틱은 '판단 기준', 플레이북은 '사후 대응'이라는 측면에서 상호 보완적입니다.
|
||||
- **상호 참조 관계:**
|
||||
- **[안티패턴] $\leftrightarrow$ [트레이드오프]:** 에이전트 남발(A-04)과 멀티에이전트 설계의 최적화/희생 관계는 서로 연결됩니다.
|
||||
- **[아키텍처 휴리스틱] $\leftrightarrow$ [디버깅 플레이북]:** 특정 기술(예: 락, 메모리 타입)을 언제 사용하는지에 대한 규칙(휴리스틱)은 해당 기술이 실패했을 때의 대응책(플레이북)과 직결됩니다.
|
||||
- **[ConnectAI 사례]:** 모든 문서는 ConnectAI 프로젝트에서 실제로 검증되고 적용된 사례를 바탕으로 구성되어 있어 데이터의 일관성을 가집니다.
|
||||
@@ -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,29 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Programming/Pattern_Catalog"
|
||||
generated_at: 2026-06-18T18:01:08.478Z
|
||||
sources: ["React_State_Pattern", "Repository_Pattern", "Infinite_Scroll_Pattern", "JWT_Authentication_Pattern", "Push_Notification_Pattern"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Programming/Pattern_Catalog
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: React에서 상태를 관리할 때 가장 권장되는 위치와 방법은 무엇인가요?** — A: 상태를 필요한 가장 낮은 곳에 두되, 공유가 필요하면 부모로 끌어올리고(lifting state up), 서버 데이터는 UI 상태와 분리하여 캐시 라이브러리(react-query 등)를 사용하는 것이 핵심입니다. [React State Pattern]
|
||||
- **Q: Repository 패턴을 사용할 때 얻을 수 있는 이점과 주의할 점은 무엇인가요?** — A: 도메인 로직을 저장 기술(DB, API 등)로부터 분리하여 테스트와 구현 교체가 용이하다는 장점이 있지만, ORM이 이미 유사한 추상을 제공하는 경우 중복 설계가 될 수 있으므로 주의해야 합니다. [Repository Pattern]
|
||||
- **Q: 무한 스크롤 구현 시 성능 저하를 막기 위해 반드시 포함해야 할 요소는 무엇인가요?** — A: 커서 기반 페이징, DOM 가상화(virtualization), 그리고 중복/경쟁 요청 방지 로직이 필수적입니다. [Infinite Scroll Pattern]
|
||||
- **Q: JWT 인증 방식의 구조적 약점과 이를 보완할 방법은 무엇인가요?** — A: 토큰을 즉시 무효화하기 어렵다는 것이 약점이며, 이를 위해 Access/Refresh Token의 수명을 분리하거나 블랙리스트/토큰 회전(Rotation) 방식을 사용하여 보완할 수 있습니다. [JWT Authentication Pattern]
|
||||
- **Q: React 상태 관리 시 '파생 상태'를 처리하는 올바른 방법은 무엇인가요?** — A: 파생된 값은 별도로 저장하지 않고 `useMemo`를 통해 계산하여 사용합니다. [React State Pattern]
|
||||
|
||||
## 핵심 사실
|
||||
- **React State Pattern:** 상태는 최소 단위에 두되, 공유 시 끌어올리고 서버 데이터는 분리함. 파생 상태는 저장하지 않고 계산함. [React State Pattern]
|
||||
- **Repository Pattern:** 도메인 코드와 데이터 저장 방식 사이에 인터페이스를 두어 결합도를 낮춤. [Repository Pattern]
|
||||
(참고: ConnectAI의 `eventSourcedStore`는 Repository 패턴을 적용한 사례임)
|
||||
- **Infinite Scroll Pattern:** 커서 기반 페이징과 DOM 가상화가 성능 유지의 핵심임. [Infinite Scroll Pattern]
|
||||
- **JWT Authentication Pattern:** 서버 세션 없이 상태를 유지(stateless)하는 방식이며, 확장성이 좋으나 즉시 무효화가 어렵다는 특징이 있음. [JWT Authentication Pattern]
|
||||
|
||||
## 문서 간 연결
|
||||
- **상태 관리와 데이터 접근의 관계:** `React State Pattern`은 프런트엔드 UI 상태 관리에 집중하며, `Repository Pattern`은 백엔드/데이터 계층의 추상화에 집중합니다. 두 패턴 모두 '관심사의 분리'를 지향합니다.
|
||||
- **공통 주제 (Pattern Catalog):** 모든 문서는 웹 및 소프트웨어 공학의 설계 패턴을 다루고 있으며, 특정 기술(React, SQL, JWT)에 종속되지 않는 추상화된 구조를 제안합니다.
|
||||
- **기술적 상호보완:** `Infinite Scroll Pattern`은 대량의 데이터를 처리할 때 `React State Pattern`에서 관리하는 상태(로컬/서버)와 결합되어 동작하며, `JWT Authentication Pattern`은 API 호출 시 보안을 위한 인증 수단으로 사용됩니다.
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Programming/Platform_Guides"
|
||||
generated_at: 2026-06-18T18:01:47.199Z
|
||||
sources: ["웹_개발_가이드", "백엔드_API_개발_가이드", "AI_에이전트_개발_가이드", "데스크탑_앱_개발_가이드"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Programming/Platform_Guides
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: 웹 개발 시 상태 관리의 핵심 원칙은 무엇인가요?** — A: 서버 데이터와 UI 상태를 분리하고, 단방향 데이터 흐름(SSOT)을 유지하며, 가능한 한 낮은 곳에서 상태를 관리하는 것이 원칙입니다. [웹 개발 가이드]
|
||||
- **Q: 백엔드 API 설계 시 '멱등성'이 왜 중요한가요?** — A: 동일한 요청이 여러 번 전달되어도 결과가 같아야 시스템의 신뢰성을 보장할 수 있기 때문입니다. 이는 복원력 있는 시스템 구축의 핵심입니다. [백엔드 API 개발 가이드]
|
||||
- **Q: AI 에이전트 개발에서 '환각(Hallucination)' 문제를 줄이기 위한 전략은 무엇인가요?** — A: RAG(검색 증강 생성) 활용, 강력한 Grounding, 자기 검증(Critic/Reflection) 레이어 구축, 그리고 프롬프트 엔지니어링을 통한 결정론적 응답 유도가 필요합니다. [AI 에이전트 개발 가이드]
|
||||
- **Q: 데스크탑 앱 개발 시 메모리 누수를 방지하기 위한 가장 좋은 방법은 무엇인가요?** — A: 모든 자원을 사용한 후 `dispose`를 등록하고, 무거운 작업은 UI 스레드가 아닌 워커 큐나 별도 프로세스로 분리하여 관리해야 합니다. [데스크탑 앱 개발 가이드]
|
||||
- **Q: 백엔드 아키텍처에서 마이크로서비스(MSA) 도입 시 고려해야 할 트레이드오프는 무엇인가요?** — A: 독립적인 확장과 배포가 가능하지만, 분산 시스템 특유의 복잡도와 데이터 일관성 문제를 감수해야 합니다. 따라서 초기에는 모놀리스로 시작하는 것을 권장합니다. [백엔드 API 개발 가이드]
|
||||
|
||||
## 핵심 사실
|
||||
- **웹 개발:** 프레임워크보다 상태, 비동기, 데이터 흐름, 에러, 계층 분리라는 본질적 문제를 푸는 것이 중요함. [웹 개발 가이드]
|
||||
- **백엔드 개발:** 계층 분리(라우터→서비스→리포지토리)와 명확한 API 계약이 신뢰성의 핵심임. [백엔드 API 개발 가이드]
|
||||
- **AI 에이전트:** RAG, 메모리, 도구 호출, 검증의 조합이 핵심이며, 특히 작은 모델일수록 자기 검증과 강한 Grounding이 품질을 결정함. [AI 에이전트 개발 가이드]
|
||||
- **데스크탑 앱:** 프로세스 분리(UI↔백그라운드)와 자원 관리(Lifecycle/Dispose)가 안정성의 핵심임. [데스크탑 앱 개발 มี 가이드]
|
||||
|
||||
## 문서 간 연결
|
||||
- **공통 주제 (Software Engineering Principles):** 모든 문서는 공통적으로 **계층 분리(Layered Architecture)**, **에러 핸들링 패턴**, **테스트 전략(단위/통합/E2E)**, 그리고 **확장성(Scaling) 전략**을 핵심 설계 원칙으로 다루고 있습니다.
|
||||
- **상호 보완적 관계:** 웹/백엔드 가이드가 일반적인 시스템의 구조적 안정성을 다룬다면, AI 에이전트 가이드는 그 시스템 내에서 지능형 로직을 구현하기 위한 특화된 아키텍처(RAG, Memory)를 설명합니다.
|
||||
- **실증 사례 연결:** 모든 가이드는 `ConnectAI`라는 프로젝트의 실제 적용 사례나 구조(VS Code 확장, 웹뷰 UI 등)를 통해 이론의 실재성을 뒷받침하고 있습니다.
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: Topic_Programming/Subsystems"
|
||||
generated_at: 2026-06-18T18:01:38.365Z
|
||||
sources: ["TFIDF_이중언어_스코어링", "LLM_프로바이더_추상화", "RAG_검색_파이프라인", "Agent_오케스트레이터_분해"]
|
||||
---
|
||||
|
||||
# 소화 노트: Topic_Programming/Subsystems
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: ConnectAI의 검색 엔진은 어떤 방식으로 작동하나요?** — A: 임베딩 엔진 없이도 가벼운 검색이 가능하도록 '좋은 토크나이저'와 'TF-IDF 가중치'를 사용합니다. 한국어/영어 혼합 토크나이저, 불용어 제거, 동의어 확장, 제목 가중치(3배) 등을 적용하여 단순 매칭 이상의 점수를 산출합니다. [TF-IDF 이중언어 스코어링]
|
||||
- **Q: 다양한 LLM 공급자(Provider)를 하나의 코드로 관리하는 방법은 무엇인가요?** — A: '어댑터 패턴'을 사용합니다. Model ID의 접두사(prefix)로 공급자를 결정하는 라우팅 방식을 사용하며, 각 공급자의 API 차이(인증, 바이트 형식 등)는 어댑터가 흡수하고 출력은 OpenAI 호환 SSE 포맷으로 정규화하여 통일합니다. [LLM 프로바이더 추상화]
|
||||
- **Q: RAG 파이프라인에서 검색된 결과의 우선순위는 어떻게 결정되나요?** — A: 소스별로 점수를 0~1로 정규화한 후 소스 우선순위 가중치를 곱합니다. 이후 Actionability(작업 상태 신호)와 Hierarchical(질의/문서 매칭) 지표로 재가중(Re-rank)하여 최종 선택합니다. [RAG 검색 파이프라인]
|
||||
- **Q: 에이전트 오케스트레이터 설계 시 'God-class' 문제를 어떻게 해결했나요?** — A: 거대한 하나의 클래스가 모든 것을 처리하는 대신, 전체 흐름의 골격만 유지하고 세부 구현은 `handlePrompt`, `llm`, `actions` 등의 모듈로 추출하여 위임하는 구조를 가집로 유지보수성을 높였습니다. [Agent 오케스트레이터 분해]
|
||||
|
||||
## 핵심 사실
|
||||
- **TF-IDF 스코어링:** 한글-영문 경계 분리 정규식을 사용하며, 제목 일치 시 본문보다 3배 높은 가중치를 부여합니다. [TF-IDF 이중언어 스코어링]
|
||||
- **LLM 라우팅:** `anthropic:`, `gemini:` 등 모델 ID의 접두사(prefix)를 통해 공급자를 결정하며, 로컬 엔진 사용 시에는 접두사가 없는 형태를 따릅니다. [LLM 프로바이더 추상화]
|
||||
- **RAG 검색 단계:** 질의 계획 $\rightarrow$ 다중 소스 병렬 검색 $\rightarrow$ 점수 정규화 및 재가중 $\rightarrow$ 토큰 예산 내 선택 순으로 진행됩니다. [RAG 검색 파이프라인]
|
||||
- **멀티에이전트 전략:** 단순한 병렬 실행보다 자원 제약에 맞춘 '순차 실행'과 단일 작성자가 여러 역할을 수행하는 'ChunkedWriter' 방식이 더 견고합니다. [Agent 오케스트레이터 분해]
|
||||
|
||||
## 문서 간 연결
|
||||
- **공통 주제:** 모든 문서는 ConnectAI 시스템의 효율적인 구조 설계(검색, LLM 호출, 에이전트 실행)를 위한 아키텍처 패턴(어댑터, 오케스트레이터 분해, 모듈화)을 다루고 있습니다.
|
||||
- **기술적 연결:**
|
||||
- `TF-IDF 스코어링`의 토크나이저 기술은 `RAG 검색 파이프라인`의 첫 단계인 Query Planning과 직접적으로 연결됩니다.
|
||||
- `LLM 프로바이더 추상화`를 통해 정규화된 출력(SSE)은 `Agent 오케스트레이터`가 사용자에게 진행 상황을 전달하는 메시지 프로토콜(`streamChunk` 등)의 기반이 됩니다.
|
||||
- `RAG 파이프라인`에서 사용하는 섹션 청킹 기술은 `TF-IDF 스코어링`의 정밀도를 높이는 요소로 작용합니다.
|
||||
@@ -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,32 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: (두뇌 루트)"
|
||||
generated_at: 2026-07-02T18:00:44.348Z
|
||||
sources: ["ASTRA 기능 인벤토리"]
|
||||
---
|
||||
|
||||
# 소화 노트: (두뇌 루트)
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
|
||||
- **Q: ASTRA의 '주간 성장 사이클'은 어떤 과정으로 진행되나요?** — A: 매주 지정된 요일/시각에 [평가(검색 평가) $\rightarrow$ 학습 큐 갱신(Need Engine) $\rightarrow$ 지식 노약 점검 $\rightarrow$ 성장 리포트 $\rightarrow$ 승인된 학습 자동 실행(Research Agent)] 순서로 진행됩니다. [ASTRA 기능 인연토리]
|
||||
- **Q: 'Sleep-time Digest' 기능은 무엇을 수행하나요?** — A: 매일 지정된 시각(유휴 시간)에 최근 7일 내 변경된 두뇌 지식을 폴던별 '소화 노트'(`<두뇌>/Digests/`)로 변환하는 기능입니다. [ASTRA 기능 인벤토리]
|
||||
- **Q: 데일리 브리핑은 어떤 정보를 제공하나요?** — A: 평일(월~금) 지정된 시각에 오늘의 캘린더 일정과 Google Tasks(마감/기한 경과/조건부 대기 항목)를 정리하여 텔레그램으로 발송합니다. [ASTRA 기능 인벤토리]
|
||||
- **Q: Astra의 메모리 시스템은 어떻게 구성되어 있나요?** — A: 3단계 계층형 메모리 주입 방식을 사용합니다: 단기(최근 대화 메시지), 중기(최근 저장된 채팅 세션), 장기(관련 Second Brain 마크다운 파일) [ASTRA 기능 인벤토리]
|
||||
- **Q: 텔레그램 봇 설정 시 고려해야 할 사항은 무엇인가요?** — A: `telegram.enabled` 활성화, 허용된 Chat ID(`allowedChatIds`) 설정, 그리고 답변 범위를 제한할 에이전트(`defaultAgent`) 지정이 필요합니다. [ASTRA 기능 인벤토리]
|
||||
|
||||
## 핵심 사실
|
||||
- **문서 성격**: 이 문서는 소스 코드(`package.json`)에서 기계적으로 생성된 것으로, 버전 변경 시 수동 편집 없이 덮어씌워집니다. [ASTRA 기능 인벤토리]
|
||||
- **주요 자동화 프로세스**:
|
||||
- **성장 사이클**: 주간 단위로 평가와 학습을 자동 수행하며, `growthCycle.autoRunApproved` 설정 시 승인된 항목은 Research Agent가 직접 실행합니다. [ASTRA 기능 인연토리]
|
||||
- **지식 관리**: `sleepDigest`를 통해 지식을 정기적으로 소화(Digest)하여 문서화합니다. [ASTRA 기능 인벤토리]
|
||||
- **기술적 특징**:
|
||||
- Multi-Agent Workflow(`multiAgentEnabled`) 지원 (Planner $\rightarrow$ Researcher $\rightarrow$ Writer).
|
||||
- LM Studio 및 Ollama와 연동하여 로컬 모델 사용 가능.
|
||||
- `mapReduce` 기법을 통해 컨텍스트 창을 초과하는 대형 메시지를 처리하는 기능 포함. [ASTRA 기능 인벤토리]
|
||||
|
||||
## 문서 간 연결
|
||||
- **기능적 통합**: 이 문서는 ASTRA의 '사용자 명령(명령어)'과 이를 자동화하기 위한 '설정값(Configuration)' 사이의 관계를 설명합니다.
|
||||
- **상호 의존성**: 사용자의 명령어(`Astra: ...`)는 설정된 자동화 규칙(`growthCycle`, `dailyBriefing` 등)에 따라 실행 결과와 알림 방식이 결정되는 구조입니다.
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
type: digest
|
||||
title: "소화 노트: writing"
|
||||
generated_at: 2026-06-29T18:02:58.938Z
|
||||
sources: ["영상_제작_공정_가이드"]
|
||||
---
|
||||
|
||||
# 소화 노트: writing
|
||||
|
||||
> ⚙️ 자동 생성 (sleep-time 사전 소화) — **원문이 항상 우선**입니다. 소스가 바뀌면 자동 재생성되며, 이 파일은 삭제해도 안전합니다.
|
||||
|
||||
## 예상 질문과 답
|
||||
- **Q: 영상 제작의 표준 공정 단계는 무엇이며, 각 단계별 최소 소요 기간은 어떻게 되나요?** — A: 기획(컨셉 설정 및 스토리보드 작성), 리소스 제작(키이미지/영상 소스 확보, VFX 및 사운드 작업), 편집(최종 합성 및 자막 작업)의 3단계로 구성되며, 각 단계별 최소 1주의 기간을 확보하는 것을 원칙으로 합니다. [영상 제작 공정 및 소요 시간 가이드]
|
||||
- **Q: 영상 길이에 따른 기본 제작 기간 산출 공식은 무엇인가요?** — A: 1분 이내 영상은 기본적으로 3주가 소요되며, 이후 길이를 연장할 경우 1분 증가할 때마다 약 1주가 추가됩니다. [영상 제작 공정 및 소요 시간 가이드]
|
||||
- **Q: 세 가지 영상 유형 중 가장 제작 기간이 길거나 복잡한 것은 무엇인가요?** — A: 브랜드 필름(3:30)은 6주 및 그 이상이 소요되며, CIO 세미나 영상 역시 상급 기술을 요구하며 5주가 소요됩니다. [영상 제작 공정 및 소요 시간 가이드]
|
||||
- **Q: 영상 제작 기간을 증가시키는 요인(변수)에는 어떤 것들이 있나요?** — A: 등장인물/배경 등의 에셋 일관성 유지, 고난도 VFX 또는 복잡한 자막 효과 같은 기술적 난이도 추가, 레퍼런스 확보의 어려움, 그리고 최소 2회 이상의 공식 피드백 루프 반영 등이 있습니다. [영상 제작 공정 및 소요 시간 가이드]
|
||||
- **Q: '미래 전시관' 영상과 'CIO 세미나' 영상의 주요 차이점은 무엇인가요?** — A: 미래 전시관은 3개 옴니버스 구성과 등장인물 일관성 유지가 필수적이며, CIO 세미나는 가상 AI 영상 및 연출 효과 중심의 상급 기술이 필요하다는 차이가 있습니다. [영상 제작 공정 및 소요 시간 가이드]
|
||||
|
||||
## 핵심 사실
|
||||
- **표준 제작 워크플로우:** 기획 $\rightarrow$ 리소스 제작 $\rightarrow$ 편집의 3단계로 구성되며, 각 단계는 최소 1주가 소요됩니다. [영상 제작 공정 및 소요 시간 가이드]
|
||||
- **제작 기간 산출:** 1분 이내 영상은 기본 3주가 소요되며, 이후 길이에 따라 1분당 약 1주씩 추가됩니다. [영상 제작 공정 및 소요 시간 가이드]
|
||||
- **프로젝트별 기간:**
|
||||
* 미래 전시관 (1:30): 3주 소요, 6명 투입. [영상 제작 공정 및 소요 시간 가이드]
|
||||
* CIO 세미나 (1:30): 5주 소요, 3명 투입. [영상 제작 공정 및 소요 시간 가이드]
|
||||
* 브랜드 필름 (3:30): 6주 이상 소요, 3명 투입. [영상 제작 공정 및 소요 시간 가이드]
|
||||
|
||||
## 문서 간 연결
|
||||
Reference in New Issue
Block a user