위키 동기화 2026-06-19: 보안 트러블슈팅 노트·회의록·lessons·Digests + ASTRA 성장 산출물

- 00_Raw: ASTRA 보안 가이드 3종(SSRF/셸 명령/파일 경로 경계), 회의록 p/q/r 추가 - Topics: Digests 5종, lessons 4종, 메모리 에피소드/장기기억 갱신 - .astra: growth(decay/regression/weakness)·eval(corrections/report) 학습 산출물 갱신 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-19 18:29:23 +09:00
parent e2c5471046
commit 8957890d13
46 changed files with 1494 additions and 102 deletions
@@ -11,7 +11,7 @@
 - **Stats**: 6 source files, ~110 lines across 1 top-level modules.

 ## Last Refresh
- **Time**: 2026-05-27T10:07:53.609Z
+- **Time**: 2026-06-15T06:09:49.560Z
 - **Files newly analysed**: 0
 - **Files reused from cache**: 6

@@ -38,7 +38,7 @@ mindmap
 - `docs/records/00_Raw/README.md` (18 lines) — 00Raw Chronicle Records
 - `docs/records/00_Raw/timeline.md` (10 lines) — Project Timeline

-_Last auto-scan: 2026-05-27T10:07:53.609Z · signature `1c09705`_
+_Last auto-scan: 2026-06-15T06:09:49.560Z · signature `1c09705`_
 <!-- ASTRA:AUTO-END -->

 ## Purpose
@@ -1,6 +1,6 @@
 {
  "version": 1,
-  "generatedAt": "2026-05-27T10:07:53.617Z",
+  "generatedAt": "2026-06-15T06:09:49.588Z",
  "files": {
    "docs/records/00_Raw/chronicle.config.json": {
      "mtimeMs": 1779876330777.5742,
@@ -7,5 +7,5 @@
  "corePurpose": "",
  "detailLevel": "standard",
  "createdAt": "2026-05-27T10:00:54.426Z",
-  "updatedAt": "2026-05-27T10:05:30.777Z"
+  "updatedAt": "2026-06-15T06:10:04.618Z"
 }
@@ -0,0 +1,22 @@
+# Development Log: 파일 생성해. E:\Wiki\2nd\00_Raw 여기에 우서 저장해두면 될 것 같아.
+
+## Purpose
+Record the implementation or verification outcome from the current conversation.
+
+## Implementation Summary
+<create_file path="E:\Wiki\2nd\00_Raw\영상_제작_공정_가이드.md"> # 영상 제작 공정 및 소요 시간 가이드 영상 콘텐츠의 종류와 난이도에 따른 표준 제작 공정, 투입 인력, 소요 기간을 정의합니다. ## 1. 영상 유형별 제작 사양 각 영상은 기획, 리소스 제작(키이미지/영상, VFX, 사운드), 편집 단계로 구성되며, 유형에 따라 난이도가 상이합니다. | 영상 종류 | 영상 길이 | 주요 특징 및 요구 사항 | 투입 인력 (맨먼스) | 제작 기간 | 필요 인원 | | :--- | :---: | :--- | :---: | :---: | :---: | | **미래 전시관** | 1:30 | - 3개 옴니버스 구성 (등장인물 일관성 유지 필수)<br>- VFX, 자막 효과 및 영상 합성 포함<br>- 단기 집중 투입형 모델 | 기획(10) / 리소스(26) / 편집(3) | **3주** | 6명 | | **CIO 세미나** | 1:30 | - 가상 AI...
+
+## Architecture
+Captured automatically from the assistant response and active project context.
+
+## Changed Files
+- E:\Wiki\2nd\00_Raw\영상_제작_공정_가이드.md
+
+## Dependency Notes
+No new dependency note was captured automatically.
+
+## Bugs
+No bugs recorded.
+
+## Lessons
+- Automatic project records should be generated in the background when the turn contains durable project knowledge.
@@ -8,3 +8,6 @@

 ## 2026-05-27
 - Auto development record created: development\2026-05-27_e-wiki-2nd-00-raw-폴더에-있는-회의록-a-b-e를-wiki화-해주고-저장은-e-wiki-2nd_implementation.md
+
+## 2026-06-15
+- Auto development record created: development\2026-06-15_파일-생성해-e-wiki-2nd-00-raw-여기에-우서-저장해두면-될-것-같아_implementation.md
@@ -0,0 +1,4 @@
+{"ts":"2026-06-12T07:39:07.470Z","errorTag":"지시불이행","question":"일단 조건을 하나 더 추가할께.  계열사는 하고 싶어 하지 않아. 우리한테 업무를 주는게 추가 업무로 이어진다고 생각해. 해서 이걸 뒤집을 정도로 매력적이어야해.","wrongAnswer":"그렇다면 전략의 패러다임을 완전히 바꿔야 합니다. 계열사가 \"우리는 안 해, 귀찮아\"라고 말하는 이유는 '이 일이 우리에게 득이 되는 게 아니라, 단순히 처리해야 할 숙제(Task)로 느껴지기 때문'입니다.\n\n새로운 정보가 직전 결론의 '계열사 대상 가치' 부분을 정면으로 반박하며, 교육의 목적을 '업무 전달'에서 '자원 및 수익 창출 모델'로 재정의해야 합니다. 결론 수정: 계열사의 거부감을 없애기 위해, 이 프로젝트를 \"우리가 일을 해주는 것\"이 아니라 \"계열사가 돈을 벌거나 비용을 아낄 수 있는 솔루션을 우리가 제공하는 것\"으로 포지셔닝해야 합니다.\n\n---\n\n🚀 [RE-STRATEGY] 계열사의 '귀찮음'을 '기회'로 뒤집는 3가지 매력 포인트\n\n계열사가 이 프로젝트를 받아들였을 때, \"추가 업무\"가 아니라 \"우리 팀의 리소스를 아껴줄 치트키\"라고 느끼게 만들어야 합니다.\n\n1. [비용 절감형] The Cost-Killer: Automated Compliance (자동화된 비용 방어)\n\n\"업무를 주는 게 아니라, 계열사의 '인건비'와 '리스크 비용'을 삭제해 드립니다.\"\n\n- 핵러(Strategy): 계열사가 직접 교육하고 검증해야 하는 번거로운 프","correction":"지금까지 너는 나에게 아이디어, 핵심 내용, 기대 효과 내용으로 써줬는데. 법정 의무 교육은 다른 포멧으로 줬어 기대 효과를 써줘. \n법정 의무 교육\t단순히 영상을 보는 것이 아니라, 퀴즈를 틀리면 정답 근거가 있는 영상 구간으로 '자동 리다이로(Seek)' 되는 기술적 메커니즘을 핵심 가치로 내세웁니다.","title":"요구한 구성 요소(기대 효과)를 누락하고 다른 포맷으로 작성함"}
+{"ts":"2026-06-15T06:32:12.103Z","errorTag":"맥락누락","question":"3주에서 5주면, 2배인거자나? +/- 오차 범위가 너무 넓어","wrongAnswer":"그렇습니다. 3주와 5주는 작업량 차이가 거의 67%에 달하기 때문에, 이 정도의 편차는 프로젝트 스케줄링 관점에서는 **'예측 불가능한 리스크'**로 작용합니다.\n\n오차 범위를 줄이기 위해 우리가 결정해야 할 것은 **\"기획(스토리보드)이 준비되었을 때, 제작 공정 중 어디까지가 확정된 상태인가?\"**입니다.\n\n범위를 좁히기 위한 두 가지 선택지를 제안합니다.\n\n### 옵션 1: '리소스 확보' 여부에 따라 범위 고정 (현실적 접근)\n단순히 \"기획이 있다\"가 아니라, **\"기획에 필요한 소스(키이미지, 영상, 사운드)가 준비되었는가?\"**를 기준으로 삼는 것입니다.\n\n*   **Case A (리소스 완료):** 기획 + 리소스 확보 완료 $\\rightarrow$ **3주 고정** (편집/합성만 남음)\n*   **Case B (기획만 완료):** 기획은 있으나 소스 제작 필요 $\\rightarrow$ **5주 유지** (리소스 제작 기간 포함)\n\n이렇게 하면 오차 범위를 3주~5주가 아닌, **'3주(소스 준비 시)' vs '5주(소스 미준비 시)'**로 명확히 구분할 수 있습니다.\n\n### 옵션 2: '기술적 난이도'를 기준으로 범위 고정 (구조적 접근)\n","correction":"1분 30초 말하는거야 3분 30초가 아니라","title":"대화의 주제(기간/오차범위)와 다른 내용(영상 길이)을 놓침"}
+{"ts":"2026-06-15T06:32:55.330Z","errorTag":"기타","question":"1분 30초 말하는거야 3분 30초가 아니라","wrongAnswer":"그렇다면 오차 범위의 핵심은 **'영상 길이(분량)'**가 아니라, **'기술적 난이도와 리소스 작업량'**에 집중되어야 합니다.\n\n사용자께서 말씀하신 대로 1분 30초를 기준으로 잡는다면, 3분 30초(브랜드 필름)처럼 긴 영상으로 인한 변수는 제거됩니다. 이제 우리가 줄여야 할 오차 범위의 핵심은 **\"기획만 있고 소스는 없는 상태인가, 아니면 소스까지 준비된 상태인가\"**로 압축됩니다.\n\n결론을 수정하여 범위를 다음과 같이 재정의할 수 있습니다.\n\n### 결론 수정: 1분 30초 영상 기준 예측 범위\n\n직전의 '3주~5주'라는 넓은 범위는 영상 길이에 따른 변수(3분 30초)를 포함하고 있었으나, **1분 30초로 고정할 경우** 오차 범위는 다음과 같이 좁혀집니다.\n\n1.  **[Case 1] 리소스 준비 완료 (기획 + 소스 확보): 약 3주**\n    *   이미 키이미지, VFX, 사운드 등 편집에 쓸 재료가 모두 있는 상태입니다. 오직 '편집'과 '합성'만 남았으므로 3주 내에 확정적 종료가 가능합니다.\n2.  **[Case 2] 리소스 제작 필요 (기획만 완료): 약 5주**\n    *   기획은 있지만, 가이드에 명시된 '리소스 제작(VFX","correction":"리소스가 있고 편집이라면 3주가 아니라 1.5주여야 하는거 아니야?","title":"수치 오류를 바로잡기 위한 논리적 근거 재검토 필요"}
+{"ts":"2026-06-16T09:44:43.435Z","errorTag":"사실오류","question":"/meet D:\\Meet\\p.txt","wrongAnswer":"**Datacollect Radio** · `/meet` · bridge=`http://127.0.0.1:3002`\n\n📝 **회의록 작성**: D:\\Meet\\p.txt\n\n⏳ 녹취 파일 읽는 중…📚 자동 용어집 3개 용어 주입\n\n✅ 파일 읽기 완료 (8,631자)\n\n🧪 **회의록 합성** (모델 `gemma-4-26b-a4b-it`)\n모델·하드웨어에 따라 수 분 걸릴 수 있습니다… ✓ (16s)\n\n# [회의 제목] 플랫폼 최적화 및 CCOC 프로젝트 진행 현황 논의\n\n- **날짜**: 2026년 06월 16일\n- **참석자**: 김원일 PD, 송병준, 김상엽, 오경득, 전효주, 한예성 (메타데이터 기준)\n- **주제 요약**: iOS 메모리 이슈 해결을 위한 플랫폼(PlayCanvas, Babylon.js 등) 조사 및 CCOC 프로젝트의 목업 기반 개발 방향 논의\n\n## 🔹 요약 보고\n*   **iOS 메모리 문제 및 최적화**: iOS 기기에서 파일 압축 해제 시 발생하는 메모리 부족 문제와 이를 극복하기 위한 플레이캔버스(PlayCanvas) 활용 방점 논의.\n*   **플랫폼 기술 조사**: 웹GL 기반 환경에서 성능이 검증된 샘플 사이트(3개 ","correction":"ccoc가 아니라 SISIHOSI야","title":"ccoc가 아니라 SISIHOSI야"}
@@ -1 +1,2 @@
 {"ts":"2026-06-14T11:00:23.846Z","recall1":0.20833333333333334,"recall3":0.2916666666666667,"mrr":0.2534722222222222,"queries":24}
+{"ts":"2026-06-17T10:10:22.905Z","recall1":0.6666666666666666,"recall3":0.8333333333333334,"mrr":0.7604166666666666,"queries":24}
@@ -0,0 +1,59 @@
+# Astra 검색 평가 리포트
+
+- 두뇌: **Local Brain**
+- 일시: 2026. 6. 17. 오후 7:10:22
+- 임베딩: (없음 — TF-IDF only)
+- 질의 수: 24
+- 메모: 주간 자동 사이클 (TF-IDF 경로)
+
+## 종합 지표
+
+| 지표 | 값 |
+|---|---|
+| recall@1 | 66.7% |
+| recall@3 | 83.3% |
+| recall@5 | 87.5% |
+| MRR | 0.760 |
+
+> recall@k = 기대 문서가 상위 k개 안에 든 질의 비율. MRR = 첫 정답의 1/순위 평균 (1에 가까울수록 좋음).
+
+## 질의별 상세
+
+| # | 질의 | 첫 정답 순위 | top-k hit | 기대 문서 |
+|---|---|---|---|---|
+| 1 | 긴 문서를 검색용으로 어떻게 잘게 나눠 인덱싱하지? | **miss** | @1✗ @3✗ @5✗ | 문서 청킹 전략.md, 청킹 전략.md |
+| 2 | RecursiveCharacterTextSplitter 같은 재귀적 문자 분할은 어떻게 동작해? | #1 | @1✓ @3✓ @5✓ | 재귀적 문자 분할.md |
+| 3 | 키워드 검색과 벡터 검색을 함께 쓰는 하이브리드 방식 | #2 | @1✗ @3✓ @5✓ | 하이브리드 검색.md |
+| 4 | 벡터 데이터베이스는 어떤 기준으로 비교해서 골라야 하나 | #1 | @1✓ @3✓ @5✓ | 벡터 데이터베이스.md |
+| 5 | 텍스트 임베딩 모델 선택 기준과 종류 | #1 | @1✓ @3✓ @5✓ | 임베딩 모델.md, 텍스트 임베딩 모델.md |
+| 6 | 검색 결과를 다시 정렬하는 reranker 재랭킹 기법 | #1 | @1✓ @3✓ @5✓ | Re-ranking.md, Reranker.md |
+| 7 | RAG 성능을 RAGAS로 정량 평가하는 지표들 | #1 | @1✓ @3✓ @5✓ | RAGAS 평가 지표.md, RAGAS.md |
+| 8 | LLM을 심판으로 써서 답변 품질을 평가하는 방법 | **miss** | @1✗ @3✗ @5✗ | LLM-as-a-Judge.md |
+| 9 | 검색된 컨텍스트의 정밀도 precision은 어떻게 측정하나 | #2 | @1✗ @3✓ @5✓ | Context Precision.md |
+| 10 | context recall 지표가 의미하는 것 | #1 | @1✓ @3✓ @5✓ | Context Recall.md |
+| 11 | 에이전트가 스스로 검색을 도구로 호출하는 Agentic RAG | #1 | @1✓ @3✓ @5✓ | Agentic RAG.md |
+| 12 | 지식 그래프 기반 GraphRAG 동작 원리 | #2 | @1✗ @3✓ @5✓ | GraphRAG.md |
+| 13 | 검색이 부실할 때 교정하는 Corrective RAG | **miss** | @1✗ @3✗ @5✗ | CRAG.md |
+| 14 | 지식 그래프와 그래프 데이터베이스 개념 | #1 | @1✓ @3✓ @5✓ | 지식 그래프.md, 그래프 데이터베이스.md |
+| 15 | 문서에서 개체(엔티티)와 관계를 추출하는 방법 | #1 | @1✓ @3✓ @5✓ | 개체 및 관계 추출.md |
+| 16 | 전처리 단계에서 텍스트 정규화를 어떻게 하나 | #1 | @1✓ @3✓ @5✓ | 텍스트 정규화.md |
+| 17 | 토크나이저는 어떻게 텍스트를 토큰으로 쪼개나 | #1 | @1✓ @3✓ @5✓ | 텍스트 토크나이저.md |
+| 18 | RAG 전체 파이프라인 아키텍처와 구성 요소 | #1 | @1✓ @3✓ @5✓ | RAG 아키텍처 및 파이프라인 기초.md, RAG 아키텍처.md, RAG 파이프라인.md |
+| 19 | 고급 RAG 기법 정리 | #1 | @1✓ @3✓ @5✓ | Advanced RAG 기법.md |
+| 20 | 데이터 인덱싱과 오케스트레이션 파이프라인 | #1 | @1✓ @3✓ @5✓ | 데이터 인덱싱 및 오케스트레이션.md |
+| 21 | LangChain으로 RAG 구현하기 | #4 | @1✗ @3✗ @5✓ | LangChain.md |
+| 22 | LlamaIndex 프레임워크로 문서 검색 | #2 | @1✗ @3✓ @5✓ | LlamaIndex.md |
+| 23 | 데이터셋 버전 관리 DVC | #1 | @1✓ @3✓ @5✓ | 데이터 버전 관리.md |
+| 24 | LLM 운영 LLMOps 베스트프랙티스 | #1 | @1✓ @3✓ @5✓ | LLMOps.md, MLOps.md |
+
+## Miss 진단 (top 결과가 기대와 어긋난 질의)
+
+- **긴 문서를 검색용으로 어떻게 잘게 나눠 인덱싱하지?**
+  - 기대: 문서 청킹 전략.md, 청킹 전략.md
+  - 실제 상위: Poetic_Blog_Writing\062_긴_문장의_물결감.md · Poetic_Blog_Writing\222_긴_글에서_집중_유지하기.md · AI_and_ML\P-Reinforce 위키 포맷 정본.md · Topics_Rag\벡터 데이터베이스.md · Coding\Python\_MOC.md
+- **LLM을 심판으로 써서 답변 품질을 평가하는 방법**
+  - 기대: LLM-as-a-Judge.md
+  - 실제 상위: Coding\AI_LLM_Cost_Optimization.md · DevOps_and_Security\코드 서식 지정과 축소가 코드 스타일로메트리(작성자 인식)에 미치는 영향을 평가하는 기계 학습 모델 분류 연구.md · AI_and_ML\AI Connect LLM Tool.md · Comfyui\Comfyui workflow json 생성 방법.md · Comfyui\Large Language Models (LLM).md
+- **검색이 부실할 때 교정하는 Corrective RAG**
+  - 기대: CRAG.md
+  - 실제 상위: Topics_Rag\Agentic RAG.md · Topics_Rag\RAG 아키텍처 및 파이프라인 기초.md · Topics_Rag\Advanced RAG 기법.md · Coding\AI_RAG_Advanced.md · Comfyui\Retrieval-Augmented Generation (RAG) for Nodes.md
@@ -1 +1 @@
-{"lastScanMs":1781546454140}
+{"lastScanMs":1781805707217}
@@ -1,8 +1,8 @@
 # 지식 노후 점검 (Knowledge Decay)

- 두뇌: Topics · 일시: 2026. 6. 14. 오후 8:00:23
+- 두뇌: Local Brain · 일시: 2026. 6. 17. 오후 7:10:22
 - 분야별 반감기: AI/기술 30일 · SEO 90일 · 시장/트렌드·회의 180일 · 일반 365일

-## 요약 — 신선 5465 · 노화 중 572 · **노후 0**
+## 요약 — 신선 5454 · 노화 중 589 · **노후 0**

 노후(stale) 지식 없음.
@@ -1,10 +1,11 @@
 # ASTRA 성장 리포트 (Reflection 기반)

-총 업무 turn: 5
+총 업무 turn: 12

 | 주 (시작일) | 업무 수 | 평균 확신도 | 요소 누락률 | 에스컬레이션 |
 |---|---|---|---|---|
 | 2026-06-07 | 5 | 62 | 80% | 3 |
+| 2026-06-14 | 7 | 79 | 0% | 0 |

 ## 반복 실수 Top (Failure Patterns)
 - 회의록 · **참석자** 누락 3회
@@ -19,6 +20,9 @@

 | 업무 | Score | 추세 | 전반기→후반기 | 표본 |
 |---|---|---|---|---|
+| 코딩 | **90** | → 유지 | 90→90 | 3 |
+| 리서치·분석 | **90** | → 유지 | 90→90 | 2 |
+| 일반 업무 | **88** | → 유지 | 90→85 | 2 |
 | 업무조사 | **53** | → 유지 | 0→53 | 1 |
 | 일정 관리 | **52** | → 유지 | 0→52 | 1 |
 | 회의록 | **40** | → 유지 | 33→44 | 3 |
@@ -4,9 +4,12 @@

 | 우선순위 | 업무 | Need Score | 표본 | 근거 |
 |---|---|---|---|---|
-| 1 | 회의록 | **42** | 3 | 요소 누락률 100% · 평균 확신도 67 · 자주 누락: 참석자, 기한 |
-| 2 | 업무조사 | **34** | 1 | 요소 누락률 100% · 평균 확신도 66 · 자주 누락: 조사 목적, 세부 내용 |
-| 3 | 일정 관리 | **12** | 1 | 평균 확신도 44 |
+| 1 | 회의록 | **35** | 3 | 요소 누락률 100% · 평균 확신도 67 · 자주 누락: 참석자, 기한 |
+| 2 | 업무조사 | **32** | 1 | 요소 누락률 100% · 평균 확신도 66 · 자주 누락: 조사 목적, 세부 내용 |
+| 3 | 일정 관리 | **10** | 1 | 평균 확신도 44 |
+| 4 | 코딩 | **8** | 3 | 특이 신호 없음 (빈도 기반) |
+| 5 | 일반 업무 | **7** | 2 | 특이 신호 없음 (빈도 기반) |
+| 6 | 리서치·분석 | **6** | 2 | 특이 신호 없음 (빈도 기반) |

 ## Knowledge Inventory (지식 보유 상태)

@@ -15,6 +18,9 @@
 | 업무조사 | 보유 | 12.0 | 0.90 |
 | 일정 관리 | 부족 | 2.0 | 0.93 |
 | 회의록 | 보유 | 6.7 | 0.94 |
+| 코딩 | 보유 | 11.7 | 0.99 |
+| 일반 업무 | 보유 | 12.0 | 1.03 |
+| 리서치·분석 | 보유 | 8.0 | 1.03 |

 ## Knowledge Debt (지식 부채)

@@ -29,6 +35,9 @@ approved 항목은 Research Agent(후속 증분)가 처리합니다. 시스템

 | 우선순위 | 주제 | 상태 | 근거 |
 |---|---|---|---|
-| 42 | 회의록 역량 보강 (자주 누락: 참석자, 기한) | proposed | 요소 누락률 100% · 평균 확신도 67 · 자주 누락: 참석자, 기한 |
-| 34 | 업무조사 역량 보강 (자주 누락: 조사 목적, 세부 내용) | proposed | 요소 누락률 100% · 평균 확신도 66 · 자주 누락: 조사 목적, 세부 내용 |
-| 12 | 일정 관리 역량 보강 | proposed | 평균 확신도 44 |
+| 35 | 회의록 역량 보강 (자주 누락: 참석자, 기한) | proposed | 요소 누락률 100% · 평균 확신도 67 · 자주 누락: 참석자, 기한 |
+| 32 | 업무조사 역량 보강 (자주 누락: 조사 목적, 세부 내용) | proposed | 요소 누락률 100% · 평균 확신도 66 · 자주 누락: 조사 목적, 세부 내용 |
+| 10 | 일정 관리 역량 보강 | proposed | 평균 확신도 44 |
+| 8 | 코딩 역량 보강 | proposed | 특이 신호 없음 (빈도 기반) |
+| 7 | 일반 업무 역량 보강 | proposed | 특이 신호 없음 (빈도 기반) |
+| 6 | 리서치·분석 역량 보강 | proposed | 특이 신호 없음 (빈도 기반) |
@@ -2,28 +2,55 @@
  {
    "id": "need-meeting-minutes",
    "topic": "회의록 역량 보강 (자주 누락: 참석자, 기한)",
-    "priority": 42,
+    "priority": 35,
    "reason": "요소 누락률 100% · 평균 확신도 67 · 자주 누락: 참석자, 기한",
    "status": "proposed",
    "createdAt": "2026-06-14T11:00:23.846Z",
-    "updatedAt": "2026-06-14T11:00:23.846Z"
+    "updatedAt": "2026-06-17T10:10:22.905Z"
  },
  {
    "id": "need-work-research",
    "topic": "업무조사 역량 보강 (자주 누락: 조사 목적, 세부 내용)",
-    "priority": 34,
+    "priority": 32,
    "reason": "요소 누락률 100% · 평균 확신도 66 · 자주 누락: 조사 목적, 세부 내용",
    "status": "proposed",
    "createdAt": "2026-06-14T11:00:23.846Z",
-    "updatedAt": "2026-06-14T11:00:23.846Z"
+    "updatedAt": "2026-06-17T10:10:22.905Z"
  },
  {
    "id": "need-schedule",
    "topic": "일정 관리 역량 보강",
-    "priority": 12,
+    "priority": 10,
    "reason": "평균 확신도 44",
    "status": "proposed",
    "createdAt": "2026-06-14T11:00:23.846Z",
-    "updatedAt": "2026-06-14T11:00:23.846Z"
+    "updatedAt": "2026-06-17T10:10:22.905Z"
+  },
+  {
+    "id": "need-coding",
+    "topic": "코딩 역량 보강",
+    "priority": 8,
+    "reason": "특이 신호 없음 (빈도 기반)",
+    "status": "proposed",
+    "createdAt": "2026-06-17T10:10:22.905Z",
+    "updatedAt": "2026-06-17T10:10:22.905Z"
+  },
+  {
+    "id": "need-general",
+    "topic": "일반 업무 역량 보강",
+    "priority": 7,
+    "reason": "특이 신호 없음 (빈도 기반)",
+    "status": "proposed",
+    "createdAt": "2026-06-17T10:10:22.905Z",
+    "updatedAt": "2026-06-17T10:10:22.905Z"
+  },
+  {
+    "id": "need-research",
+    "topic": "리서치·분석 역량 보강",
+    "priority": 6,
+    "reason": "특이 신호 없음 (빈도 기반)",
+    "status": "proposed",
+    "createdAt": "2026-06-17T10:10:22.905Z",
+    "updatedAt": "2026-06-17T10:10:22.905Z"
  }
 ]
@@ -0,0 +1,10 @@
+# 정정 회귀 리포트 — 2026. 6. 17. 오후 7:10:22
+
+과거 사용자 정정(Ground Truth)을 같은 질문으로 재검사한 결과.
+
+| 결과 | 유형 | 질문 | 비고 |
+|---|---|---|---|
+| ✅ 통과 | 지시불이행 | 일단 조건을 하나 더 추가할께.  계열사는 하고 싶어 하지 않아. 우리한테 업무를 주는게 추가 업무로 이어진 | 새 답변에 오류 반복 여부를 판단할 근거가 없음 |
+| ❌ 재발 | 맥락누락 | 3주에서 5주면, 2배인거자나? +/- 오차 범위가 너무 넓어 | 영상 길이에 대한 맥락을 무시하고 기존 오류 반복 |
+| ❌ 재발 | 기타 | 1분 30초 말하는거야 3분 30초가 아니라 | 영상 길이를 1분 30초로 인지했으나 기간 오류 반복 |
+| ❌ 재발 | 사실오류 | /meet D:\Meet\p.txt | 사용자가 CCOC가 아닌 SISIHOSI로 정정했으나 오류 반복함 |
@@ -0,0 +1,26 @@
+{
+  "updatedAt": "2026-06-17T10:10:22.905Z",
+  "totalCases": 4,
+  "tagCounts": [
+    {
+      "tag": "지시불이행",
+      "count": 1,
+      "example": "요구한 구성 요소(기대 효과)를 누락하고 다른 포맷으로 작성함"
+    },
+    {
+      "tag": "맥락누락",
+      "count": 1,
+      "example": "대화의 주제(기간/오차범위)와 다른 내용(영상 길이)을 놓침"
+    },
+    {
+      "tag": "기타",
+      "count": 1,
+      "example": "수치 오류를 바로잡기 위한 논리적 근거 재검토 필요"
+    },
+    {
+      "tag": "사실오류",
+      "count": 1,
+      "example": "ccoc가 아니라 SISIHOSI야"
+    }
+  ]
+}
@@ -11,9 +11,15 @@
 - **Stats**: 9 source files, ~159 lines across 1 top-level modules.

 ## Last Refresh
- **Time**: 2026-06-12T14:37:36.125Z
- **Files newly analysed**: 1
- **Files reused from cache**: 8
+- **Time**: 2026-06-15T06:09:01.070Z
+- **Files newly analysed**: 9
+- **Files reused from cache**: 0
+- **Files deleted since last refresh** (5):
+  - `docs/records/Topics/bugs/BUG-0001-이-내용-검토해줘-위험-요소는-없는지-우리-의도대로-위키화-작업이-되는지-import-os-topics-di.md`
+  - `docs/records/Topics/bugs/BUG-0002-아래-내용-확인해줘-아래와-같은-답변을-받는데-내용이-다-좋아-근대-어느-내용에-내가-집중해야하는것인지-내가.md`
+  - `docs/records/Topics/decisions/ADR-0001-volumes-data-project-antigravity-wiki-10-wiki-topics-제2뇌의-지식.md`
+  - `docs/records/Topics/decisions/ADR-0002-volumes-data-project-antigravity-wiki-10-wiki-topics-여기에-내가-.md`
+  - `docs/records/Topics/decisions/ADR-0003-volumes-data-project-antigravity-wiki-10-wiki-topics-여기-하위에-.md`

 ## Directory Map
 ```mermaid
@@ -28,20 +34,20 @@ mindmap
 ### `docs/` — 9 files, ~159 lines

 **Sub-directories**
- `docs/records/` (9) — Topics Chronicle Records
+- `docs/records/` (9) — Bug: 이 내용 검토해줘. 위험 요소는 없는지. 우리 의도대로 위키화 작업이 되는지. import os topicsdir = "/Volumes/Dat...

 **Key files**
- `docs/records/Topics/README.md` (18 lines) — Topics Chronicle Records
- `docs/records/Topics/bugs/BUG-0001-이-내용-검토해줘-위험-요소는-없는지-우리-의도대로-위키화-작업이-되는지-import-os-topics-di.md` (16 lines) — Bug: 이 내용 검토해줘. 위험 요소는 없는지. 우리 의도대로 위키화 작업이 되는지. import os topicsdir = "/Volumes/Dat...
- `docs/records/Topics/bugs/BUG-0002-아래-내용-확인해줘-아래와-같은-답변을-받는데-내용이-다-좋아-근대-어느-내용에-내가-집중해야하는것인지-내가.md` (16 lines) — Bug: 아래 내용 확인해줘. 아래와 같은 답변을 받는데. 내용이 다 좋아. 근대 어느 내용에 내가 집중해야하는것인지 내가 잘 모르겠어. 조금만 더 깔끔...
+- `docs/records/Topics/bugs/BUG-0001-이-내용-검토해줘-위험-요소는-없는지-우리-의도대로-위키화-작업이-되는지-import-os-topics-di.md` (16 lines) — Bug: 이 내용 검토해줘. 위험 요소는 없는지. 우리 의도대로 위키화 작업이 되는지. import os topicsdir = "/Volumes/Dat...
+- `docs/records/Topics/bugs/BUG-0002-아래-내용-확인해줘-아래와-같은-답변을-받는데-내용이-다-좋아-근대-어느-내용에-내가-집중해야하는것인지-내가.md` (16 lines) — Bug: 아래 내용 확인해줘. 아래와 같은 답변을 받는데. 내용이 다 좋아. 근대 어느 내용에 내가 집중해야하는것인지 내가 잘 모르겠어. 조금만 더 깔끔...
 - `docs/records/Topics/chronicle.config.json` (11 lines) — JSON configuration
- `docs/records/Topics/decisions/ADR-0001-volumes-data-project-antigravity-wiki-10-wiki-topics-제2뇌의-지식.md` (19 lines) — ADR: /Volumes/Data/project/Antigravity/Wiki/10Wiki/Topics 제2뇌의 지식이 정보 간의 연결성(Interco...
- `docs/records/Topics/decisions/ADR-0002-volumes-data-project-antigravity-wiki-10-wiki-topics-여기에-내가-.md` (19 lines) — ADR: /Volumes/Data/project/Antigravity/Wiki/10Wiki/Topics 여기에 내가 계속 새로운 지식 즉, 예로 능동적...
- `docs/records/Topics/decisions/ADR-0003-volumes-data-project-antigravity-wiki-10-wiki-topics-여기-하위에-.md` (19 lines) — ADR: /Volumes/Data/project/Antigravity/Wiki/10Wiki/Topics 여기 하위에 지식 연결이 없는 문서들이 있어. ...
+- `docs/records/Topics/decisions/ADR-0001-volumes-data-project-antigravity-wiki-10-wiki-topics-제2뇌의-지식.md` (19 lines) — ADR: /Volumes/Data/project/Antigravity/Wiki/10Wiki/Topics 제2뇌의 지식이 정보 간의 연결성(Interco...
+- `docs/records/Topics/decisions/ADR-0002-volumes-data-project-antigravity-wiki-10-wiki-topics-여기에-내가-.md` (19 lines) — ADR: /Volumes/Data/project/Antigravity/Wiki/10Wiki/Topics 여기에 내가 계속 새로운 지식 즉, 예로 능동적...
+- `docs/records/Topics/decisions/ADR-0003-volumes-data-project-antigravity-wiki-10-wiki-topics-여기-하위에-.md` (19 lines) — ADR: /Volumes/Data/project/Antigravity/Wiki/10Wiki/Topics 여기 하위에 지식 연결이 없는 문서들이 있어. ...
 - `docs/records/Topics/project-profile.md` (31 lines) — Project Profile
+- `docs/records/Topics/README.md` (18 lines) — Topics Chronicle Records
 - `docs/records/Topics/timeline.md` (10 lines) — Project Timeline

-_Last auto-scan: 2026-06-12T14:37:36.125Z · signature `467d2bf1`_
+_Last auto-scan: 2026-06-15T06:09:01.070Z · signature `467d2bf1`_
 <!-- ASTRA:AUTO-END -->

 ## Purpose
@@ -1,66 +1,66 @@
 {
  "version": 1,
-  "generatedAt": "2026-06-12T14:37:36.125Z",
+  "generatedAt": "2026-06-15T06:09:01.200Z",
  "files": {
-    "docs/records/Topics/README.md": {
-      "mtimeMs": 1777961554000,
-      "size": 443,
-      "lines": 18,
-      "role": "Topics Chronicle Records",
-      "imports": []
-    },
-    "docs/records/Topics/bugs/BUG-0001-이-내용-검토해줘-위험-요소는-없는지-우리-의도대로-위키화-작업이-되는지-import-os-topics-di.md": {
-      "mtimeMs": 1777961554000,
-      "size": 2153,
+    "docs/records/Topics/bugs/BUG-0001-이-내용-검토해줘-위험-요소는-없는지-우리-의도대로-위키화-작업이-되는지-import-os-topics-di.md": {
+      "mtimeMs": 1778029080050.159,
+      "size": 2169,
      "lines": 16,
      "role": "Bug: 이 내용 검토해줘. 위험 요소는 없는지. 우리 의도대로 위키화 작업이 되는지. import os topicsdir = \"/Volumes/Dat...",
      "imports": []
    },
-    "docs/records/Topics/bugs/BUG-0002-아래-내용-확인해줘-아래와-같은-답변을-받는데-내용이-다-좋아-근대-어느-내용에-내가-집중해야하는것인지-내가.md": {
-      "mtimeMs": 1777963191000,
-      "size": 2883,
+    "docs/records/Topics/bugs/BUG-0002-아래-내용-확인해줘-아래와-같은-답변을-받는데-내용이-다-좋아-근대-어느-내용에-내가-집중해야하는것인지-내가.md": {
+      "mtimeMs": 1778029080050.159,
+      "size": 2899,
      "lines": 16,
      "role": "Bug: 아래 내용 확인해줘. 아래와 같은 답변을 받는데. 내용이 다 좋아. 근대 어느 내용에 내가 집중해야하는것인지 내가 잘 모르겠어. 조금만 더 깔끔...",
      "imports": []
    },
    "docs/records/Topics/chronicle.config.json": {
-      "mtimeMs": 1781275049000,
-      "size": 427,
+      "mtimeMs": 1781492239792.1636,
+      "size": 438,
      "lines": 11,
      "role": "JSON configuration",
      "imports": []
    },
-    "docs/records/Topics/decisions/ADR-0001-volumes-data-project-antigravity-wiki-10-wiki-topics-제2뇌의-지식.md": {
-      "mtimeMs": 1777877200000,
-      "size": 1541,
+    "docs/records/Topics/decisions/ADR-0001-volumes-data-project-antigravity-wiki-10-wiki-topics-제2뇌의-지식.md": {
+      "mtimeMs": 1778029080051.6616,
+      "size": 1560,
      "lines": 19,
      "role": "ADR: /Volumes/Data/project/Antigravity/Wiki/10Wiki/Topics 제2뇌의 지식이 정보 간의 연결성(Interco...",
      "imports": []
    },
-    "docs/records/Topics/decisions/ADR-0002-volumes-data-project-antigravity-wiki-10-wiki-topics-여기에-내가-.md": {
-      "mtimeMs": 1777891599000,
-      "size": 1787,
+    "docs/records/Topics/decisions/ADR-0002-volumes-data-project-antigravity-wiki-10-wiki-topics-여기에-내가-.md": {
+      "mtimeMs": 1778029080052.181,
+      "size": 1806,
      "lines": 19,
      "role": "ADR: /Volumes/Data/project/Antigravity/Wiki/10Wiki/Topics 여기에 내가 계속 새로운 지식 즉, 예로 능동적...",
      "imports": []
    },
-    "docs/records/Topics/decisions/ADR-0003-volumes-data-project-antigravity-wiki-10-wiki-topics-여기-하위에-.md": {
-      "mtimeMs": 1777951122000,
-      "size": 1690,
+    "docs/records/Topics/decisions/ADR-0003-volumes-data-project-antigravity-wiki-10-wiki-topics-여기-하위에-.md": {
+      "mtimeMs": 1778029080052.6975,
+      "size": 1709,
      "lines": 19,
      "role": "ADR: /Volumes/Data/project/Antigravity/Wiki/10Wiki/Topics 여기 하위에 지식 연결이 없는 문서들이 있어. ...",
      "imports": []
    },
    "docs/records/Topics/project-profile.md": {
-      "mtimeMs": 1777961554000,
-      "size": 600,
+      "mtimeMs": 1778029080053.7246,
+      "size": 631,
      "lines": 31,
      "role": "Project Profile",
      "imports": []
    },
+    "docs/records/Topics/README.md": {
+      "mtimeMs": 1778029080048.9976,
+      "size": 461,
+      "lines": 18,
+      "role": "Topics Chronicle Records",
+      "imports": []
+    },
    "docs/records/Topics/timeline.md": {
-      "mtimeMs": 1777963191000,
-      "size": 482,
+      "mtimeMs": 1778029080054.2383,
+      "size": 492,
      "lines": 10,
      "role": "Project Timeline",
      "imports": []
@@ -1,12 +1,12 @@
 ---
 type: reference
 title: "ASTRA 기능 인벤토리 (자동 생성)"
-version: "0.0.72"
-generated_at: 2026-06-16T00:54:06.133Z
+version: "0.0.78"
+generated_at: 2026-06-17T09:58:45.959Z
 aliases: ["ASTRA 기능 목록", "ASTRA 명령어", "내 기능", "ASTRA가 할 수 있는 것", "기능 인벤토리", "ASTRA capabilities"]
 ---

-# ASTRA 기능 인벤토리 — v0.0.72 (자동 생성)
+# ASTRA 기능 인벤토리 — v0.0.78 (자동 생성)

 > ⚙️ 이 문서는 Astra 활성화 시 **소스 코드(package.json)에서 기계 생성**됩니다 — 수동 편집 금지 (버전 변경 시 덮어씀).
 > 자기 기능에 대한 질문·자기 개선 제안은 이 문서가 **항상 현행** 근거입니다. 서사적 설명은 [[ASTRA 자기 아키텍처]] 참고.
@@ -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,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/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,74 @@
+---
+type: lesson
+title: 요구한 구성 요소(기대 효과)를 누락하고 다른 포맷으로 작성함
+error-tag: 지시불이행
+applies-to: []
+severity: medium
+source: user-correction
+occurrences: 1
+last-seen: 2026-06-12
+---
+
+# Lesson: 요구한 구성 요소(기대 효과)를 누락하고 다른 포맷으로 작성함
+
+## Situation
+사용자 질문: 일단 조건을 하나 더 추가할께.  계열사는 하고 싶어 하지 않아. 우리한테 업무를 주는게 추가 업무로 이어진다고 생각해. 해서 이걸 뒤집을 정도로 매력적이어야해.
+
+## Mistake / Risk
+[지시불이행] AI 답변: 그렇다면 전략의 패러다임을 완전히 바꿔야 합니다. 계열사가 "우리는 안 해, 귀찮아"라고 말하는 이유는 '이 일이 우리에게 득이 되는 게 아니라, 단순히 처리해야 할 숙제(Task)로 느껴지기 때문'입니다.
+
+새로운 정보가 직전 결론의 '계열사 대상 가치' 부분을 정면으로 반박하며, 교육의 목적을 '업무 전달'에서 '자원 및 수익 창출 모델'로 재정의해야 합니다. 결론 수정: 계열사의 거부감을 없애기 위해, 이 프로젝트를 "우리가 일을 해주는 것"이 아니라 "계열사가 돈을 벌거나 비용을 아낄 수 있는 솔루션을 우리가 제공하는 것"으로 포지셔닝해야 합니다.
+
+---
+
+🚀 [RE-STRATEGY] 계열사의 '귀찮음'을 '기회'로 뒤집는 3가지 매력 포인트
+
+계열사가 이 프로젝트를 받아들였을 때, "추가 업무"가 아니라 "우리 팀의 리소스를 아껴줄 치트키"라고 느끼게 만들어야 합니다.
+
+1. [비용 절감형] The Cost-Killer: Automated Compliance (자동화된 비용 방어)
+
+"업무를 주는 게 아니라, 계열사의 '인건비'와 '리스크 비용'을 삭제해 드립니다."
+
+- 핵러(Strategy): 계열사가 직접 교육하고 검증해야 하는 번거로운 프로세스를 우리 플랫폼이 자동으로 처리(Auto-pilot)하게 합니다.
+- 매력 포인트: "계열사 담당자님, 따로 교육 자료 만드실 필요 없습니다. 우리 시스템에 프로젝트 등록만 하시면, 보안/준법 테스트와 결과 리포트가 자동으로 생성되어 감사팀에 전송됩니다."
+- 결과: 계열사 입장에서는 '추가 업무'가 아니라, '기존 업무의 자동화(Automation)'가 됩니다.
+
+2. [수익 창출형] The Revenue Generator: New Market Access (신규 시장 진입 도구)
+
+"우리가 만든 기술을 쓰면, 계열사의 서비스가 '글로벌 표준'이 됩니다."
+
+- 핵러(Strategy): 계열사가 보유한 서비스에 우리 플랫폼의 '인터랙티브 교육 모듈'을 입혀서, 외부 고객(B2B/B2무)에게 판매할 수 있는 '부가 가치 상품(Add-on)'으로 변모시킵니다.
+- 매력 포인트: "이 기술을 도입하면 계열사 서비스의 퀄리티가 '게임급'으로 올라갑니다. 이를 통해 해외 고객이나 대형 계약처에 '검증된 보안/품질'을 마케팅 포인트로 내세울 수 있습니다."
+- 결과: 계열사 입장에서는 '새로운 매출원(New Revenue Stream)'이 생기는 것입니다.
+
+3. [리소스 최적화형] The Resource Saver: Plug & Play Module (즉시 투입 가능한 모듈)
+
+"개발은 우리가 할 테니, 계열사는 '콘텐츠'만 결정하세요."
+
+- 핵러(Strategy): 계열사가 새로운 프로젝트를 시작할 때 겪는 기술적 난관(Unity 구현, 서버 구축 등)을 우리 플랫폼의 '표준 모듈'로 즉시 해결해 줍니다.
+- 매력 포인트: "새로운 서비스 출시할 때 개발팀 인력 많이 쓰지 마세요. 우리가 만든 인터랙티브 엔진에 콘텐츠만 태우면, 개발 기간을 1/3로 단축할 수 있습니다."
+- 결과: 계열사 입장에서는 '개발 기간 단축 및 리소스 최적화'를 달 수 있습니다.
+
+---
+
+💡 전략적 제언 (Strategic Roadmap)
+
+결론 수정: 계열사의 거부감을 없애기 위해, 이 프로젝트의 정체성을 '서비스 제공자(Provider)'에서 '가치 증폭기(Value Multiplier)'로 전환해야 합니다.
+
+- 핵심 가치: "업무를 준다" $\rightarrow$ "효율을 준다"
+- 검증할 것: 계열사 담당자들이 현재 가장 '귀찮아하는' 지점(예: 보안 감사, 교육 이수 관리, 개발 인력 부족)이 무엇인지 먼저 파악하여, 위 3가지 모델 중 하나를 타겟팅해야 합니다.
+- 다음 단계: 계열사가 "오, 이건 우리한테 진짜 이득인데?"라고 느낄 수 있도록, 실제 '비용 절감 시뮬레이션(ROI)' 데이터를 준비하는 것이 필요합니다.
+
+출처: `모델 지식 (검색 출처 미사용)`
+
+이 답변은 사용자의 요청에 따라 완성되었습니다.
+
+## Fix
+사용자 정정 (Ground Truth): 지금까지 너는 나에게 아이디어, 핵심 내용, 기대 효과 내용으로 써줬는데. 법정 의무 교육은 다른 포멧으로 줬어 기대 효과를 써줘. 
+법정 의무 교육	단순히 영상을 보는 것이 아니라, 퀴즈를 틀리면 정답 근거가 있는 영상 구간으로 '자동 리다이로(Seek)' 되는 기술적 메커니즘을 핵심 가치로 내세웁니다.
+
+## Prevention Checklist
+- 같은 질문 유형에서 [지시불이행] 재발 여부 확인 — 주간 회귀 테스트 대상
+
+## 관련 레슨
+- [[2026-06-15-correction-대화의-주제-기간-오차범위-와-다른-내용-영상-길이-을-놓침]]
@@ -0,0 +1,57 @@
+---
+type: lesson
+title: 대화의 주제(기간/오차범위)와 다른 내용(영상 길이)을 놓침
+error-tag: 맥락누락
+applies-to: []
+severity: medium
+source: user-correction
+occurrences: 1
+last-seen: 2026-06-15
+---
+
+# Lesson: 대화의 주제(기간/오차범위)와 다른 내용(영상 길이)을 놓침
+
+## Situation
+사용자 질문: 3주에서 5주면, 2배인거자나? +/- 오차 범위가 너무 넓어
+
+## Mistake / Risk
+[맥락누락] AI 답변: 그렇습니다. 3주와 5주는 작업량 차이가 거의 67%에 달하기 때문에, 이 정도의 편차는 프로젝트 스케줄링 관점에서는 **'예측 불가능한 리스크'**로 작용합니다.
+
+오차 범위를 줄이기 위해 우리가 결정해야 할 것은 **"기획(스토리보드)이 준비되었을 때, 제작 공정 중 어디까지가 확정된 상태인가?"**입니다.
+
+범위를 좁히기 위한 두 가지 선택지를 제안합니다.
+
+### 옵션 1: '리소스 확보' 여부에 따라 범위 고정 (현실적 접근)
+단순히 "기획이 있다"가 아니라, **"기획에 필요한 소스(키이미지, 영상, 사운드)가 준비되었는가?"**를 기준으로 삼는 것입니다.
+
+*   **Case A (리소스 완료):** 기획 + 리소스 확보 완료 $\rightarrow$ **3주 고정** (편집/합성만 남음)
+*   **Case B (기획만 완료):** 기획은 있으나 소스 제작 필요 $\rightarrow$ **5주 유지** (리소스 제작 기간 포함)
+
+이렇게 하면 오차 범위를 3주~5주가 아닌, **'3주(소스 준비 시)' vs '5주(소스 미준비 시)'**로 명확히 구분할 수 있습니다.
+
+### 옵션 2: '기술적 난이도'를 기준으로 범위 고정 (구조적 접근)
+영상 유형을 '난이도 상/하'로 나누어, 기술적 요구사항이 확정된 상태라면 기간을 고정하는 방식입니다.
+
+*   **Low-End (단순 자막/편집):** 3주
+*   **High-End (VFX/합성 필수):** 5주
+
+---
+
+**결론적으로 제가 제안하는 방향은 이렇습니다:**
+
+만약 사용자가 **"기획이 준비되었다"**고 말할 때, 그 기획에 **'리소스 제작(VFX, 사운드 등) 계획'까지 포함되어 있는지**를 확인해야 합니다.
+
+*   만약 리소스 제작까지 완료된 상태라면 $\rightarrow$ **3주**
+*   기획은 있지만 소스 작업이 남아있다면 $\rightarrow$ **5주**
+
+이렇게 기준을 세우면 오차 범위를 훨씬 좁게 관리할 수 있습니다. 지금 이 가이드의 기준을 **'리소스 준비 여부'**에 따라 재정의할까요?
+
+## Fix
+사용자 정정 (Ground Truth): 1분 30초 말하는거야 3분 30초가 아니라
+
+## Prevention Checklist
+- 같은 질문 유형에서 [맥락누락] 재발 여부 확인 — 주간 회귀 테스트 대상
+
+## 관련 레슨
+- [[2026-06-12-correction-요구한-구성-요소-기대-효과-를-누락하고-다른-포맷으로-작성함]]
+- [[2026-06-15-correction-수치-오류를-바로잡기-위한-논리적-근거-재검토-필요]]
@@ -0,0 +1,46 @@
+---
+type: lesson
+title: 수치 오류를 바로잡기 위한 논리적 근거 재검토 필요
+error-tag: 기타
+applies-to: []
+severity: medium
+source: user-correction
+occurrences: 1
+last-seen: 2026-06-15
+---
+
+# Lesson: 수치 오류를 바로잡기 위한 논리적 근거 재검토 필요
+
+## Situation
+사용자 질문: 1분 30초 말하는거야 3분 30초가 아니라
+
+## Mistake / Risk
+[기타] AI 답변: 그렇다면 오차 범위의 핵심은 **'영상 길이(분량)'**가 아니라, **'기술적 난이도와 리소스 작업량'**에 집중되어야 합니다.
+
+사용자께서 말씀하신 대로 1분 30초를 기준으로 잡는다면, 3분 30초(브랜드 필름)처럼 긴 영상으로 인한 변수는 제거됩니다. 이제 우리가 줄여야 할 오차 범위의 핵심은 **"기획만 있고 소스는 없는 상태인가, 아니면 소스까지 준비된 상태인가"**로 압축됩니다.
+
+결론을 수정하여 범위를 다음과 같이 재정의할 수 있습니다.
+
+### 결론 수정: 1분 30초 영상 기준 예측 범위
+
+직전의 '3주~5주'라는 넓은 범위는 영상 길이에 따른 변수(3분 30초)를 포함하고 있었으나, **1분 30초로 고정할 경우** 오차 범위는 다음과 같이 좁혀집니다.
+
+1.  **[Case 1] 리소스 준비 완료 (기획 + 소스 확보): 약 3주**
+    *   이미 키이미지, VFX, 사운드 등 편집에 쓸 재료가 모두 있는 상태입니다. 오직 '편집'과 '합성'만 남았으므로 3주 내에 확정적 종료가 가능합니다.
+2.  **[Case 2] 리소스 제작 필요 (기획만 완료): 약 5주**
+    *   기획은 있지만, 가이드에 명시된 '리소스 제작(VFX, 사운드 등)' 단계를 새로 거쳐야 합니다. 이 단계에서 발생하는 물리적 시간이 추가되어 5주가 소요됩니다.
+
+**결론 유지 — 이유는 다음과 같습니다:**
+1분 30초라는 길이는 고정되었으므로, 이제 프로젝트의 리스크는 **'추가적인 제작 공정(리소스 제작)이 포함되느냐 아니냐'**에 달려 있습니다. 따라서 우리는 **"기획 완료 시점의 리소스 준비 상태"**를 기준으로 스케줄을 3주 또는 5주로 명확히 분리하여 관리해야 합니다.
+
+---
+*이 정보는 사용자가 제공한 `영상_제작_공정_가이드.md`의 수치와 1분 30초라는 새로운 전제를 바탕으로 도출된 논리적 추론입니다.*
+
+## Fix
+사용자 정정 (Ground Truth): 리소스가 있고 편집이라면 3주가 아니라 1.5주여야 하는거 아니야?
+
+## Prevention Checklist
+- 같은 질문 유형에서 [기타] 재발 여부 확인 — 주간 회귀 테스트 대상
+
+## 관련 레슨
+- [[2026-06-15-correction-대화의-주제-기간-오차범위-와-다른-내용-영상-길이-을-놓침]]
@@ -0,0 +1,91 @@
+---
+type: lesson
+title: ccoc가 아니라 SISIHOSI야
+error-tag: 사실오류
+applies-to: []
+severity: medium
+source: user-correction
+occurrences: 1
+last-seen: 2026-06-16
+---
+
+# Lesson: ccoc가 아니라 SISIHOSI야
+
+## Situation
+사용자 질문: /meet D:\Meet\p.txt
+
+## Mistake / Risk
+[사실오류] AI 답변: **Datacollect Radio** · `/meet` · bridge=`http://127.0.0.1:3002`
+
+📝 **회의록 작성**: D:\Meet\p.txt
+
+⏳ 녹취 파일 읽는 중…📚 자동 용어집 3개 용어 주입
+
+✅ 파일 읽기 완료 (8,631자)
+
+🧪 **회의록 합성** (모델 `gemma-4-26b-a4b-it`)
+모델·하드웨어에 따라 수 분 걸릴 수 있습니다… ✓ (16s)
+
+# [회의 제목] 플랫폼 최적화 및 CCOC 프로젝트 진행 현황 논의
+
+- **날짜**: 2026년 06월 16일
+- **참석자**: 김원일 PD, 송병준, 김상엽, 오경득, 전효주, 한예성 (메타데이터 기준)
+- **주제 요약**: iOS 메모리 이슈 해결을 위한 플랫폼(PlayCanvas, Babylon.js 등) 조사 및 CCOC 프로젝트의 목업 기반 개발 방향 논의
+
+## 🔹 요약 보고
+*   **iOS 메모리 문제 및 최적화**: iOS 기기에서 파일 압축 해제 시 발생하는 메모리 부족 문제와 이를 극복하기 위한 플레이캔버스(PlayCanvas) 활용 방점 논의.
+*   **플랫폼 기술 조사**: 웹GL 기반 환경에서 성능이 검증된 샘플 사이트(3개 내외)를 선정하여 QA 팀에 테스트 요청 계획 수립.
+*   **CCCOC 프로젝트 진행**: 현옥 팀장의 목업을 바탕으로 한 개발 방식 및 데이터 업데이트 방식(바이브 코딩 활용 등) 논의.
+*   **가우시안 스플래팅 R&D**: 파노라마 방식을 대체하거나 보완할 수 있는 기술적 가능성 및 퀄리티 검증 필요성 제기.
+
+## 1. 주요 논의 사항
+### [iOS 메모리 이슈 및 웹GL 플랫폼 조사]
+- **현황**: iOS 환경에서 압축 파일 해제 시 발생하는 메모리 문제로 인해 특정 기기에서 실행이 불안정함.
+- **핵심 논의**: 
+    - 참석자 1: iOS 10/17 등 특정 기기에서의 메모리 터짐 현상과 이를 극복하기 위한 플레이캔버스 지원 포맷(sgl/sog 등) 활용 가능성 언급.
+    - 참석자 2: 이미 서비스 중인 사례나 샘플 데모를 찾아보고, QA 팀에 URL을 전달하여 성능(초 단위 등) 및 작동 여부를 체크리스트로 확인 요청할 것을 제안.
+    - 참석자 3: 가우시안 스플래팅 기반의 최적화된 프로젝트 샘플 3개를 찾아 전달하겠다고 답변.
+- **결론**: 논의 중 (플레이캔버스 및 베이비론 JS 등 기술 검토 필요)
+
+### [CCCOC 프로젝트 개발 방향]
+- **현황**: CCOC 프로젝트의 1차 작업 기한은 19일까지이며, 현재 목업 단계임.
+- **핵급 논의**:
+    - 참석자 4: 현옥 팀장이 만든 웹 기반 목업 형태를 공유할 예정이며, 상품 리스트가 나열된 단순한 구조임을 설명.
+    - 참석자 2: 바이브 코딩을 활용하여 초기 구현을 진행하되, 데이터 업데이트(DB/로컬)를 위한 개별 코딩 및 구조 고민이 필요함을 강조.
+- **결론**: 논의 중 (목업 전달 후 구체적 개발 방식 결정)
+
+### [가우시안 스플래팅 R&D 방향]
+- **현황**: 가우시안 스플래팅 기술을 기존 파노라마 방식에 적용하거나 새로운 무기로 사용할지 검토 중.
+- **핵심 논의**: 
+    - 참석자 3: 기존 파노라마 기술을 유지하면서 새로운 포맷으로 가져가는 방향 제안.
+    - 참석자 2: 결과물의 퀄리티와 호환성에 따라 결정될 문제이며, 최종적인 평가가 필요함.
+- **결론**: 논의 중
+
+## 2. 리스크 및 이슈
+*   **iOS 메모리 부족**: 파일 압축 해제 시 메모리 점유로 인해 특정 기기에서 크래시 발생 가능성 있음.
+*   **기술적 불확실성**: 베이비론 JS나 트리JS 등 선택한 플랫폼의 비주얼 툴 지원 여부 및 개발 편의성에 대한 검증이 필요함.
+
+## 3. 결정 사항
+- **QA 테스트 요청**: 선정된 샘플 사이트(약 3개)를 QA 팀에 전달하여 기종별 성능 및 작동 여부를 체크할 것 — 근거: "QA 통해서 거기 돌아가는지를 체크해서 이 체크리스트 표를 만들어서... 확인해 달라고"
+- **CCCOC 목업 공유**: 개발 방향 설정을 위해 현옥 팀장의 목업 링크를 전달할 것 — 근거: "현옥 팀장이 목업 만든 거을 한번 전달드릴게요."
+
+## 4. 오픈 이슈
+*   베이비론 JS(Babylon.js)의 비주얼 툴 지원 범위 및 활용 가능성 확인 필요.
+*   CCCOC 프로젝트의 데이터 업데이트 방식(DB 연동 또는 로컬 입력)에 대한 구체적인 설계.
+
+## 5. 액션 아이템
+| 담당 | 작업 내용 | 작업 상세 | 기한 | 상태 |
+| --- | --- | --- | --- | --- |
+| 참석자 3 | 웹GL 샘플 프로젝트 전달 | 플레이캔버스 기반의 가우시안 스플래팅 프로젝트를 포함하여, 검증 가능한 샘플 3개를 찾아 전달함. 근거: "가오샤스 플래트 프로젝트 2개하고 일반 프로젝트 하나 해서 3개 정도 전달드리고" | 기한미정 | 진행미정 |
+| 참석자 4 | CCOC 목업 링크 전달 | 현재 개발 중인 CCOC 프로젝트의 느낌을 파악할 수 있도록 현옥 팀장의 목업 링크를 공유함. 근거: "현옥 팀장이 목업 만든 거을 한번 전달드릴게요." | 기한미정 | 기한미정 |
+| 참석자 1/2 | 플랫폼 성능 테스트 및 조사 | 플레이캔버스 등 선정된 사이트의 작동 여부와 성능(초 단위)을 QA 팀을 통해 확인하도록 요청함. 근거: "QA 통해서 거기 돌아가는지를 체크해서... 초 같은 걸을 재는" | 기한미정 | 진행미정 |
+
+💾 **회의록 저장 완료**: `E:\Wiki\2nd\00_Raw\회의록 p 2026-06-16.md`
+
+ℹ️ 캘린더 자동 등록을 건너뜁니다 — Google Calendar OAuth(쓰기)가 연결되지 않았습니다. (Astra Settings → Google 섹션에서 연결)
+
+## Fix
+사용자 정정 (Ground Truth): ccoc가 아니라 SISIHOSI야
+
+## Prevention Checklist
+- 같은 질문 유형에서 [사실오류] 재발 여부 확인 — 주간 회귀 테스트 대상
@@ -1,9 +1,9 @@
 {
-  "timestamp": 1780969449862,
+  "timestamp": 1781597869139,
  "report": {
    "candidateCount": 2,
    "promotedCount": 2,
    "archivedCount": 0,
-    "durationMs": 18
+    "durationMs": 20
  }
 }
@@ -23,5 +23,7 @@
  "projectContext": "e:\\Wiki",
  "timestamp": 1778655982091,
  "duration": 0,
-  "messageCount": 101
+  "messageCount": 101,
+  "promoted": true,
+  "promotedToLongTermId": "586811fb-6966-4034-b37f-32c254ba139d"
 }
@@ -23,5 +23,7 @@
  "projectContext": "e:\\Wiki",
  "timestamp": 1778840072869,
  "duration": 0,
-  "messageCount": 77
+  "messageCount": 77,
+  "promoted": true,
+  "promotedToLongTermId": "45e01fe1-f9dd-4704-a6ab-42747f4f9be3"
 }
@@ -0,0 +1,21 @@
+{
+  "id": "7cb97355-59f9-4363-b99f-805f4c5939f4",
+  "sessionId": "task_1781492801815",
+  "title": "/stocks discover sector 전기 3000 5000",
+  "summary": "/stocks discover sector 전기 3000 5000 /stocks discover sector 2차전지 3000 5000 /stocks discover sector 2차전지 /stocks discover sector 2차전지 /stocks analysis 119850 /stocks analysis 119850",
+  "keyDecisions": [],
+  "topics": [
+    "stocks",
+    "discover",
+    "sector",
+    "2차전지",
+    "3000",
+    "5000",
+    "analysis",
+    "119850"
+  ],
+  "projectContext": "e:\\Wiki",
+  "timestamp": 1781500071619,
+  "duration": 0,
+  "messageCount": 12
+}
@@ -0,0 +1,27 @@
+{
+  "id": "efef2d61-4f98-49ff-b829-100035958163",
+  "sessionId": "task_1781492801815",
+  "title": "우리 회사에서 할 수 있는 기술력을 설명할께.  우리만 작업해서 할 수 있는 작업 위주로 주면 더 좋지...",
+  "summary": "시작: 우리 회사에서 할 수 있는 기술력을 설명할께. \n우리만 작업해서 할 수 있는 작업 위주로 주면 더 좋지만 안되면 우리를 중심으로 외주를 고용하는 방법도 괜찮아. \n\n우리가 할 수  → 최종: /stock discover 3000 5000",
+  "keyDecisions": [
+    "수정: 만약 회사의 리소스를 가장 빠르게 현금화(Cash-out)하고 싶다면 [2번: 에이전시]로 시작하여 캐시카우를 확보한 뒤, 그 결과물을 기반으로 [1번: 플랫폼]을 구축하는 것이 가장 리스크가 적은 로드맵입니",
+    "수정: 이 프로젝트의 성공은 \"모회사가 얼마나 강력한 표준(Standard)을 제시하느냐\"에 달려 있습니다.",
+    "수정: 이 모든 아이디어의 핵심은 \"지식의 휘발성 방지\"입니다.",
+    "수정: 교육의 목적은 '지식 전달'에서 '행동 변화'로 옮겨가야 합니다.",
+    "수정: 계열사의 거부감을 없애기 위해, 이 프로젝트를 \"우리가 일을 해주는 것\"이 아니라 \"계열사가 돈을 벌거나 비용을 아낄 수 있는 솔루션을 우리가 제공하는 것\"으로 포지셔닝해야 합니다."
+  ],
+  "topics": [
+    "영상을",
+    "아이디어",
+    "아이디어로",
+    "회사에서",
+    "우리가",
+    "사용하여",
+    "유사한",
+    "좋겠어"
+  ],
+  "projectContext": "e:\\Wiki",
+  "timestamp": 1781497356360,
+  "duration": 0,
+  "messageCount": 26
+}
@@ -0,0 +1,25 @@
+{
+  "id": "198df3ba-28a7-4af4-b5a6-4b4fa7a16db2",
+  "sessionId": "task_1781594574017",
+  "title": "아래 내용을 위키화 해줘. 영상 만들때 걸리는 시간이야.  \t\t\t\t\t\t\t\t\t\t\t\t \t영상 종류\t영상 길...",
+  "summary": "시작: 아래 내용을 위키화 해줘. 영상 만들때 걸리는 시간이야. \n\n\t\t\t\t\t\t\t\t\t\t\t\t\n\t영상 종류\t영상 길이\t영상 특징\t기획\t\t리소스 제작\t\t편집\t\t1인 기준 맨먼스\t제작 기간\t인원 → 최종: 회의록 합성 실패: Datacollect Bridge(http://127.0.0.1:3002)에 연결할 수 없습니다. Wiki/Datacollect 프로젝트에서 npm run br",
+  "keyDecisions": [
+    "지연'이나 '스토리보드 수정' 시간은 단축됩니다. 하지만 가이드상 **'리소스 제작(키이미지/영상 확보)'과 '편집'에 각각 최소 1주씩**이 기본으로 필요하므로, 물리적인 작업 시간 자체는 줄어들기 어렵습니다.",
+    "수정: 1분 30초 영상 기준 예측 범위",
+    "유지 — 이유는 다음과 같습니다:**"
+  ],
+  "topics": [
+    "vfx",
+    "키이미지",
+    "사운드",
+    "meet",
+    "리소스",
+    "가상의",
+    "위키화",
+    "만들때"
+  ],
+  "projectContext": "e:\\Wiki",
+  "timestamp": 1781597869078,
+  "duration": 0,
+  "messageCount": 25
+}
@@ -0,0 +1,18 @@
+{
+  "id": "c7b3bcf1-3c83-4621-8448-3a9dc14557de",
+  "sessionId": "task_1781678118976",
+  "title": "/meet D:\\Meet\\p.txt",
+  "summary": "/meet D:\\Meet\\p.txt /meet D:\\Meet\\p.txt /meet D:\\Meet\\p.txt ccoc가 아니라 SISIHOSI야 너는 self envolving이 있자나. 앞으로 시시오시, ccoc라고 쓰지말고 SISIHOSI라고 써",
+  "keyDecisions": [
+    "수정: **CCCOC** 프로젝트에 대한 논의를 **SISIHOSI** 프로젝트로 바로잡습니다.",
+    "유지 — 기존에 'CCCOC' 또는 'CCOC'로 잘못 표기되었던 프로젝트 명칭을 이제부터는 반드시 **SISIHOSI**로 통일하여 호출하고 기록하겠습니다."
+  ],
+  "topics": [
+    "meet",
+    "txt"
+  ],
+  "projectContext": "e:\\Wiki",
+  "timestamp": 1781683011263,
+  "duration": 0,
+  "messageCount": 10
+}
@@ -0,0 +1,15 @@
+{
+  "id": "bb982c18-6a60-4ef6-9554-80943db3f23b",
+  "sessionId": "task_1781678118976",
+  "title": "/meet D:\\Meet\\q.txt",
+  "summary": "/meet D:\\Meet\\q.txt /meet D:\\Meet\\q.txt",
+  "keyDecisions": [],
+  "topics": [
+    "meet",
+    "txt"
+  ],
+  "projectContext": "e:\\Wiki",
+  "timestamp": 1781683477361,
+  "duration": 0,
+  "messageCount": 4
+}
@@ -0,0 +1,26 @@
+{
+  "id": "9d52b81c-2923-49ea-98f6-2002e34c0194",
+  "sessionId": "task_1781775264357",
+  "title": "/meet D:\\Meet\\q.txt",
+  "summary": "시작: /meet D:\\Meet\\q.txt → 최종: E:\\Wiki\\astraai 코드 리뷰를 하고 개선할 부분이 있는지 확인해줘.",
+  "keyDecisions": [
+    "- 장바구니 연동 시 회원 인증 문제로 인한 높은 개발 작업 부담 확인",
+    "| 송 팀장과 협의하여 상단/하단(푸터) 유지 여부 등 테스트 버전을 제작함 근거: \"내일 탑이랑 쿠터 저쪽만 송 팀장이랑 얘기하면 될 것 같긴 해요.\" | 테스트 버전 | 내일 | 확정 |",
+    "(API 연동 vs 수동 운영 툴 제공)",
+    "(담당: 참석자 8)"
+  ],
+  "topics": [
+    "meet",
+    "wiki",
+    "astraai",
+    "리뷰를",
+    "개선할",
+    "부분이",
+    "있는지",
+    "확인해줘"
+  ],
+  "projectContext": "e:\\Wiki",
+  "timestamp": 1781775358476,
+  "duration": 0,
+  "messageCount": 35
+}
@@ -0,0 +1,24 @@
+{
+  "id": "a80e59ac-5b23-4270-bf86-81929f8f911b",
+  "sessionId": "task_1781834834717",
+  "title": "E:\\Wiki\\astraai 설계를 분석하고 개선이 필요한 부분 의견줘.",
+  "summary": "시작: E:\\Wiki\\astraai 설계를 분석하고 개선이 필요한 부분 의견줘. → 최종: 아래 내용은 채팅 내용인데 요약해주고, 해결된 것과 해결되지 않은것. 결정이 필요한 것들이 무엇이 있는지. 그러고 Target 날짜까지 산출할 수 있으면 정리해주면 좋겠어. \n\n여",
+  "keyDecisions": [
+    "지을 핵심 과제입니다.",
+    "사항 및 향후 리팩토링 계획 문서로 기록될 가치가 있습니다."
+  ],
+  "topics": [
+    "2026",
+    "칼리버스",
+    "롯데백화점",
+    "디지털영업전략팀",
+    "정현욱",
+    "감사합니다",
+    "안녕하세요",
+    "롯데이노베이트"
+  ],
+  "projectContext": "e:\\Wiki",
+  "timestamp": 1781857568154,
+  "duration": 0,
+  "messageCount": 4
+}
@@ -8,8 +8,8 @@
      "source": "session:task_1778642741077",
      "confidence": 0.7,
      "createdAt": 1778655981978,
-      "lastReferencedAt": 1781533561927,
-      "referenceCount": 35
+      "lastReferencedAt": 1781775495175,
+      "referenceCount": 36
    },
    {
      "id": "5d44cb85-e018-468c-a7be-dbfa44546fce",
@@ -18,8 +18,8 @@
      "source": "session:task_1778642741077",
      "confidence": 0.7,
      "createdAt": 1778655981979,
-      "lastReferencedAt": 1781533561927,
-      "referenceCount": 37
+      "lastReferencedAt": 1781775495175,
+      "referenceCount": 38
    },
    {
      "id": "4cb93674-fd06-4cf4-96f9-9ac2008a6b49",
@@ -28,8 +28,8 @@
      "source": "session:task_1778642741077",
      "confidence": 0.7,
      "createdAt": 1778655981979,
-      "lastReferencedAt": 1781533561927,
-      "referenceCount": 32
+      "lastReferencedAt": 1781775495175,
+      "referenceCount": 33
    },
    {
      "id": "acb8373d-3a17-4266-9f7e-608349add88c",
@@ -38,8 +38,8 @@
      "source": "session:task_1778642741077",
      "confidence": 0.7,
      "createdAt": 1778655981986,
-      "lastReferencedAt": 1781533561927,
-      "referenceCount": 32
+      "lastReferencedAt": 1781775495175,
+      "referenceCount": 33
    },
    {
      "id": "64b1c34d-64a0-493a-82ee-298c0fd1900f",
@@ -48,8 +48,8 @@
      "source": "session:task_1778642741077",
      "confidence": 0.7,
      "createdAt": 1778655981992,
-      "lastReferencedAt": 1781533561927,
-      "referenceCount": 33
+      "lastReferencedAt": 1781775495175,
+      "referenceCount": 34
    },
    {
      "id": "2e323e3f-bd37-4b25-8cd7-d21ddee58728",
@@ -58,8 +58,8 @@
      "source": "session:task_1778642741077",
      "confidence": 0.7,
      "createdAt": 1778655981997,
-      "lastReferencedAt": 1781533561927,
-      "referenceCount": 27
+      "lastReferencedAt": 1781775495175,
+      "referenceCount": 28
    },
    {
      "id": "e54c9135-67ac-4a46-b337-95af5bce61bb",
@@ -88,8 +88,8 @@
      "source": "session:task_1778642741077",
      "confidence": 0.7,
      "createdAt": 1778655982004,
-      "lastReferencedAt": 1781161507133,
-      "referenceCount": 3
+      "lastReferencedAt": 1781834888277,
+      "referenceCount": 4
    },
    {
      "id": "8f248ce7-e9f8-42a9-bc4a-eadfd3534419",
@@ -118,7 +118,7 @@
      "source": "session:task_1778642741077",
      "confidence": 0.7,
      "createdAt": 1778655982022,
-      "lastReferencedAt": 1781533546507,
+      "lastReferencedAt": 1781594584305,
      "referenceCount": 15
    },
    {
@@ -168,7 +168,7 @@
      "source": "session:task_1778642741077",
      "confidence": 0.7,
      "createdAt": 1778655982028,
-      "lastReferencedAt": 1781533546507,
+      "lastReferencedAt": 1781593976846,
      "referenceCount": 10
    },
    {
@@ -188,8 +188,8 @@
      "source": "session:task_1778642741077",
      "confidence": 0.7,
      "createdAt": 1778655982039,
-      "lastReferencedAt": 1778655982039,
-      "referenceCount": 0
+      "lastReferencedAt": 1781834888277,
+      "referenceCount": 1
    },
    {
      "id": "342d5547-0c51-4a0f-88df-3bc9873d481f",
@@ -288,8 +288,8 @@
      "source": "session:task_1778819919539",
      "confidence": 0.7,
      "createdAt": 1778840072798,
-      "lastReferencedAt": 1778840072798,
-      "referenceCount": 0
+      "lastReferencedAt": 1781834888277,
+      "referenceCount": 1
    },
    {
      "id": "81e1c769-3dd0-4708-ba62-434d01541a3e",
@@ -378,8 +378,8 @@
      "source": "session:task_1778819919539",
      "confidence": 0.7,
      "createdAt": 1778840072838,
-      "lastReferencedAt": 1781233879537,
-      "referenceCount": 5
+      "lastReferencedAt": 1781834888277,
+      "referenceCount": 7
    },
    {
      "id": "947dd1e0-a369-4023-8829-381d72a6fefd",
@@ -388,7 +388,7 @@
      "source": "session:task_1778819919539",
      "confidence": 0.7,
      "createdAt": 1778840072839,
-      "lastReferencedAt": 1781533546507,
+      "lastReferencedAt": 1781593976846,
      "referenceCount": 23
    },
    {
@@ -398,8 +398,8 @@
      "source": "session:task_1778819919539",
      "confidence": 0.7,
      "createdAt": 1778840072845,
-      "lastReferencedAt": 1781533546507,
-      "referenceCount": 18
+      "lastReferencedAt": 1781775495175,
+      "referenceCount": 19
    },
    {
      "id": "d4804a31-585e-49bc-b6a3-4c1751dcf312",
@@ -438,8 +438,8 @@
      "source": "session:task_1779619484222",
      "confidence": 0.7,
      "createdAt": 1779619946611,
-      "lastReferencedAt": 1781354532601,
-      "referenceCount": 16
+      "lastReferencedAt": 1781834888277,
+      "referenceCount": 18
    },
    {
      "id": "9b7b2ff2-a9b0-4fce-b26e-f2dba942a29a",
@@ -448,8 +448,8 @@
      "source": "episodic:585dd6d9-1308-44a3-b4ca-2a7c803687b1",
      "confidence": 0.7,
      "createdAt": 1780969449853,
-      "lastReferencedAt": 1781354532601,
-      "referenceCount": 18
+      "lastReferencedAt": 1781834888277,
+      "referenceCount": 20
    },
    {
      "id": "25530cbf-6913-4784-8d7d-c189be33ec51",
@@ -458,8 +458,8 @@
      "source": "episodic:a4e4d26e-4fe6-4882-bf78-90a8f1c5a618",
      "confidence": 0.7,
      "createdAt": 1780969449854,
-      "lastReferencedAt": 1781533561927,
-      "referenceCount": 24
+      "lastReferencedAt": 1781834888277,
+      "referenceCount": 26
    },
    {
      "id": "6f215df5-9cc4-4bc2-be65-9f417f98dfb4",
@@ -512,9 +512,9 @@
      "source": "session:task_1781165391416",
      "confidence": 0.7,
      "createdAt": 1781167677722,
-      "lastReferencedAt": 1781167677722,
-      "referenceCount": 0,
-      "expiresAt": 1782377277720
+      "lastReferencedAt": 1781834888277,
+      "referenceCount": 1,
+      "expiresAt": 1783044488277
    },
    {
      "id": "97c10831-403a-4e37-ac22-97939aa16ae8",
@@ -581,7 +581,49 @@
      "lastReferencedAt": 1781358728400,
      "referenceCount": 0,
      "expiresAt": 1782568328400
+    },
+    {
+      "id": "45e01fe1-f9dd-4704-a6ab-42747f4f9be3",
+      "category": "episode-digest",
+      "content": "[2026-05-15] tetris라는 폴더를 만들고 거기에 react 기반으로 테트리스 게임 하나 만들어. 우선 만들기 전에...\n요약: 시작: tetris라는 폴더를 만들고 거기에 react 기반으로 테트리스 게임 하나 만들어. 우선 만들기 전에 기획하고 설계하고 그 다음에 고딩으로 들어가면 좋겠어 → 최종: 지금까지 우리가 작업하면서 self reflector 기능이 있는데. 잘 반영되고 있는건지 확인해주면 좋겠어.\n결정: 텍서트(Conclusion Text): Final Result]** · 현재의 `connectai`는 **'개인용 지능형 에이전트'**로서는 매우 수준 높은 설계를 가지고 있습니다. 하지만 프로젝트의 규모가 '개인의 메모'를 넘어 '방대한 데이터셋'을 다루게 될 경우, 지금의 **Ful · 받으신다고 하셔서 일단은 홀드를 한 이틀 정도 해놨었잖아요. · 참석자 7 46:53 · *   5월 19일까지 최종 수정 빌드 완료 및 외부 시연용 영상 제작 계획 수동\n토픽: 참석자, 그러니까, 이렇게, 모바일, 그래서, 같아요, 그러면, 거예요",
+      "source": "episodic:262cd2f1-d533-4f6c-91c2-de044b44570a",
+      "confidence": 0.7,
+      "createdAt": 1781597869128,
+      "lastReferencedAt": 1781834888277,
+      "referenceCount": 1
+    },
+    {
+      "id": "586811fb-6966-4034-b37f-32c254ba139d",
+      "category": "episode-digest",
+      "content": "[2026-05-13] 회의록 작성해줘.  참석자 : 김원일, 오경득, 김상엽, 강성규, 김성회, 홍지훈, 정현욱, 오은지, ...\n요약: 시작: 회의록 작성해줘. \n참석자 : 김원일, 오경득, 김상엽, 강성규, 김성회, 홍지훈, 정현욱, 오은지, 한예성. \n\n[내용]\n새로운 노트\n2026.05.07 목 오후 5:17 ・ 2 → 최종: 너가 방금 작성한 20260512_롯데월드_이머시브_및 _ai스타일링샵_기술 검토도 동일하게 wiki화 작업해줘.\n결정: 참석자 2 16:52 · **계정과 캐릭터 간의 연결고리만 끊어** 해당 계정으로 재접속 시 신규 캐릭터를 생성하도록 하는 방식이 가장 적절하다는 의견으로 수렴됨. · 과정을 명확하게 기록하고 싶어 하십니다. 특히, 복잡한 기술적/정책적 딜레마(계정 정지 vs. 캐릭터 삭제) 속에서 어떤 해결책이 가장 실용적인지 정리하는 것이 주요 목적입니다. · **계정과 캐릭터 간의 연결고리만 끊는 방식**이 가장 적절하다는 의견으로 수렴됨. · ** **'미니 게임' 요소를 최소화하거나 아예 제외하는 조건**으로, 360도 탐험과 영상 연출만을 포함한 가장 단순하고 핵심적인 플로우를 먼저 구체화하여 개발 난이도를 측정해야 합니다.\n토픽: 참석자, 그러니까, 이렇게, 그래서, 모바일, 그러면, 우리가, 같아요",
+      "source": "episodic:9ec317f3-ef96-4b09-a299-d47a647fe5cd",
+      "confidence": 0.7,
+      "createdAt": 1781597869129,
+      "lastReferencedAt": 1781834888277,
+      "referenceCount": 1
+    },
+    {
+      "id": "3af8dbcc-b679-45c8-b327-10904a72d13b",
+      "category": "rule",
+      "content": "앞으로 시시오시, ccoc라고 쓰지말고 SISIHOSI라고 써",
+      "source": "session:task_1781678118976",
+      "confidence": 0.7,
+      "createdAt": 1781680740263,
+      "lastReferencedAt": 1781680740263,
+      "referenceCount": 0,
+      "expiresAt": 1782890340263
+    },
+    {
+      "id": "a5a4012e-18c9-4ca0-9ee9-a1de41d5b08c",
+      "category": "rule",
+      "content": "앞으로 시시오시, ccoc라고 쓰지말고 SISIHOSI라고 써",
+      "source": "session:task_1781678118976",
+      "confidence": 0.7,
+      "createdAt": 1781683011262,
+      "lastReferencedAt": 1781683011262,
+      "referenceCount": 0,
+      "expiresAt": 1782892611262
    }
  ],
-  "lastUpdated": 1781533615418
+  "lastUpdated": 1781857568169
 }
@@ -0,0 +1,37 @@
+# 영상 제작 공정 및 소요 시간 가이드
+
+영상 콘텐츠의 종류와 난이도에 따른 표준 제작 공정, 투입 인력, 소요 기간을 정의합니다.
+
+## 1. 영상 유형별 제작 사양
+각 영상은 기획, 리소스 제작(키이미지/영상, VFX, 사운드), 편집 단계로 구성되며, 유형에 따라 난이도가 상이합니다.
+
+| 영상 종류 | 영상 길이 | 주요 특징 및 요구 사항 | 투입 인력 (맨먼스) | 제작 기간 | 필요 인원 |
+| :--- | :---: | :--- | :---: | :---: | :---: |
+| **미래 전시관** | 1:30 | - 3개 옴니버스 구성 (등장인물 일관성 유지 필수)<br>- VFX, 자막 효과 및 영상 합성 포함<br>- 단기 집중 투입형 모델 | 기획(10) / 리소스(26) / 편집(3) | **3주** | 6명 |
+| **CIO 세미나** | 1:30 | - 가상 AI 영상 및 연출 효과 중심<br>- VFX/자막/합성 상급 기술 필요<br>- 피드백이 많은 세미나용 영상 | 기획(15) / 리소스(35) / 편집(5) | **5주** | 3명 |
+| **브랜드 필름** | 3:30 | - 가상 AI 영상 및 연출 효과 중심<br>- 단순 자막 위주의 구성 | 기획(10) / 리소스(45) / 편집(5) | **6주** 및 그 이상 | 3명 |
+
+---
+
+## 2. 표준 제작 공정 (Standard Workflow)
+영상 제작의 기본 단위는 각 단계별 최소 1주의 기간을 확보하는 것을 원칙으로 합니다.
+
+* **기획 (Planning):** 컨셉 설정 및 스토리보드 작성 (최소 1주)
+* **리소스 제작 (Asset Creation):**
+    * 키이미지 및 영상 소스 확보 (최소 1주)
+    * VFX(시각효과) 및 사운드 작업 (최소 1주)
+* **편집 (Post-Production):** 최종 합성 및 자막 작업 (최소 1주)
+
+> **[기본 제작 시간 산출 공식]**
+> - **1분 이내 영상:** 기본 **3주** 소요 (기획 $\rightarrow$ 리소스 $\rightarrow$ 편집 각 1주씩)
+> - **길이 연장 시:** 기본 제작 기간 이후, **1분 증가할 때마다 약 1주 추가**
+
+---
+
+## 3. 작업 난이도 및 변수 (Complexity Factors)
+다음 요소가 포함될 경우 제작 기간 및 인력 투입량이 증가합니다.
+
+* **일관성 유지:** 등장인물, 배경, 로고 등의 에셋 일관성 유지가 필요한 경우
+* **기술적 난이도:** 고난도 VFX 연출 및 복잡한 자막 효과 작업이 추가되는 경우
+* **레퍼런스 확보:** 가상의 연출 효과를 위해 참조할 레퍼런스 확보가 어려운 경우 (기획 단계의 리스크)
+* **피드백 루프:** 최소 2회 이상의 공식 피드백 과정(프로토타입 $\rightarrow$ 중간 수정 $\rightarrow$ 최종 완성)을 공정 계획에 반영해야 함