위키 동기화 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,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
+- 같은 질문 유형에서 [사실오류] 재발 여부 확인 — 주간 회귀 테스트 대상