---
id: re-poc-request
title: "RE: POC Request"
category: "Topic"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["AES-1rass Clear Key", "EZDRM POC", "CALIVERSE DRM Strategy", "Bento4 Encryption"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.85
created_at: 2026-07-03
updated_at: 2026-07-03
review_reason: ""
merge_history: []
tags: ["email", "wikify"]
raw_sources: ["email:RE: POC Request"]
applied_in: []
github_commit: ""
---

# [[RE: POC Request]]

## 🎯 한 줄 통찰 (One-line insight)
[[iOS]] 환경의 고성능 3D 렌더링 파이프라인 유지를 위해 하드웨어 DRM 대신 소프트웨어 기반의 [[AES-128 Clear Key]] 방식을 채택하여 기술적 제약을 극복하고자 함.

## 🧠 핵심 개념 (Core concepts)
- **[[AES-128 Clear Key]]**: 하드웨어 수준의 보안(FairPlay 등)이 불가능한 환경에서 텍스처 접근 권한을 확보하기 위한 소프트웨어 기반 암호화 방식.
- **[[CVPixelBuffer]] & [[Metal API]]**: iOS 내에서 비디오 프레임을 커스텀 셰이더로 처리하여 3D 스테레오스코픽 환경을 구축하기 위한 핵심 기술 요소.
- **[[Bento4]] / [[Shaka Packager]]**: 암호화 키를 획득하고 콘텐츠를 패키징하기 위해 사용될 오프라인/온프레미스 패키저 전략.
- **[[Naver Cloud Platform (NCP)]]**: 자산 저장(Object Storage) 및 배포(CDN)를 위한 인프라 기반 기술.

## 🧩 추출된 패턴 (Extracted patterns)
- **기술적 제약에 따른 대안 선택 패턴**: 하드웨어 DRM이 특정 API(Apple Metal)의 텍스처 접근을 차단할 경우, 보안 수준을 낮추더라도 기능 구현이 가능한 소프트웨어 방식(Clear Key)을 선택함.
- **인프라 통합 설계**: 클라우드 서비스(NCP)와 스트리밍 표준(HLS)을 결합하여 확장 가능한 미디어 배포 구조를 설계함.

## ⚖️ 비교 및 선택 기준 (Comparison & decision criteria)

| 항목 (Option) | 장점 | 단점 | 언제 선택 |
|---|---|---|---|
| [[AES-128 Clear Key]] | 하드웨어 DRM과 달리 텍스처(CVPixelBuffer) 접근 및 커스텀 렌더링 가능 | 보안 수준이 하드웨어 DRM에 비해 낮음 | iOS에서 Metal API를 통한 고성능 3D 렌더링이 필수적인 경우 |
| [[FairPlay]] (Hardware-level DRM) | 강력한 보안 및 콘텐츠 보호 제공 | Apple의 Secure Path로 인해 텍스처 접근이 차단되어 커스텀 렌더링 불가 | 표준적인 비디오 재생 환경이며 높은 보안 수준이 요구될 때 |

## 📖 세부 내용 (Details)
### 1. 기술적 배경 및 결정 근계 [S1]
[[CALIVERSE]] 프로젝트는 iOS 네이티브 앱을 대상으로 하며, [[AVPlayer]]와 [[CoreVideo]] 프레임워크를 사용합니다. 특히 [[Apple Metal API]]를 통한 3D 스테레오스코픽 환경 구현을 위해 [[CVPixelBuffer]]의 원시 픽셀 버퍼에 접근해야 합니다. 하드웨어 수준의 DRM은 이러한 텍스처 접근을 완전히 차단하므로, 기술적 타당성을 위해 [[AES-128 Clear Key]]와 토큰 기반 인증 방식을 채택하였습니다.

### 2. 인프라 및 스트리밍 구조 [S1]
- **CDN/Storage**: [[Naver Cloud Platform (NCP)]]의 Object Storage 및 CDN을 활용합니다.
- **Streaming Protocol**: [[HLS]]를 사용하며, [[Bento4]] 또는 [[Shaka Packager]]를 통해 패키징을 수행합니다.
- **Key Management**: [[CPIX API]]를 통해 [[EZDRM]] 서버로부터 암호화 키를 획득하는 구조입니다.

### 3. 프로젝트 로드맵 [S1]
- **대상 플랫폼**: iOS 네이티브 앱 (Android 및 Web은 현재 범위 제외)
- **출시 목표**: 2026년 10월 말 예정
- **비즈니스 현황**: 글로벌 대형 플랫폼과 협력 중이며, K-pop 팬을 위한 몰입형 3D 비디오 서비스 개발 중

### 📖 세부 내용 흐름 (Timeline)
- **2026-06-11 17:23**: [[김도건]]이 [[EZDRM]] 측의 회신 내용을 전달함. [S1]
- **2026-06-11 18:55**: [[Wonil Kim]]이 [[EZDRM]]에 기술적 요구사항(AES-128 선택 이유 등)을 포함한 답변을 보냄. [S1]
- **2026-06-19 16:30**: [[EZDRRM]] 측에서 [[Clear key]] 계정 생성을 완료하고 접속 정보(ID/PW)를 제공함. [S1]

| 누가 | 무엇을 | 기한 | 근거(메시지 번호) |
|---|---|---|---|
| [[Wonil Kim]] | [[AES-12int Clear Key]] 채택 이유 및 기술 사양 전달 | 완료 | 메시지 1 |
| [[EZDRM]] (Pierre Hunter) | [[Clear key]] 계정 생성 및 접속 정보(ID/PW) 제공 | 완료 | 메시지 1 |

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **업데이트**: 기존의 하드웨어 DRM 중심 보안 전략에서, 기술적 구현 가능성(텍스처 접근)을 우선시하는 소프트웨어 암호화 전략으로 전환됨.

## 🛠️ 적용 사례 (Applied in summary)
현재 [[CALIVERSE]] 프로젝트의 iOS 네이티브 앱 개발 및 [[EZDRM]] POC 계정 설정을 위한 인프라 구축에 해당 기술 결정 사항이 적용되었습니다.

## 💻 코드 패턴 (Code patterns)
소스에 코드 예시 없음

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual
- **출처 신뢰도:** B
- **신점 점수:** 0.85
- **중복 검사 결과:** 신규 생성 (New discovery)

## 🔗 지식 그래프 (Knowledge Graph)
- **상위/루트:** [[RE: POC Request]]
- **관련 개념:** [[AES-128 Clear Key]], [[Apple Metal API]], [[Naver Cloud Platform]]
- **참조 맥락:** iOS 기반 고성능 3D 비디오 스트리밍 서비스의 보안 및 인프라 설계 결정 시 참조.

## 📚 출처 (Sources)
- [S1] email:RE: POC Request (2026-06-19)

## 📝 변경 이력 (Change history)
- 2026-07-03: Astra /email wikify 로 이메일 스레드에서 초안 생성.