위키 동기화 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
@@ -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