chore(brain): ASTRA 성장 자산 동기화 — 기능 인벤토리·growth(약점프로필/학습큐)·일화기억·장기기억·회의록 원문
This commit is contained in:
@@ -0,0 +1,45 @@
|
||||
# [회의 제목] 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월 중 |
|
||||
@@ -0,0 +1,55 @@
|
||||
# [신규 어트랙션 홍보 및 미니 게임 구현 방안 논의]
|
||||
|
||||
- **날짜**: 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 | 상세 논의 미팅 진행 | 신규 콘텐츠 구현 방식 및 구체적인 기획안 도출을 위해 상세 미팅을 요청함. 근거: "그럼 한번 상세 이거 관련해서 좀 논의가 필요하니 한번 미팅을 한번 하자." | 미정 |
|
||||
@@ -0,0 +1,53 @@
|
||||
# [회의 제목] 롯데온 피드백 반영 및 서비스 기능 구현 관련 논의
|
||||
|
||||
- **날짜**: 확인 불가
|
||||
- **참석자**: 오상무, 김준호(발표자), 김태현팀장, 김원일 이호, 송병준팀장, 안현제팀장, 오경득팀장, 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의 수정 작업을 수행함. 근거: "다음 주 월요일이나 화요일 정도" | 차주 월/화 |
|
||||
@@ -0,0 +1,58 @@
|
||||
# [가우시안 스플래팅(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 진행 및 일정 수립 | 가우시안 스플래팅 기술의 웹 구현 가능성을 연구하고, 프로토타입이 나올 수 있는 구체적인 개발 기간을 산출함. | 미정 |
|
||||
@@ -0,0 +1,48 @@
|
||||
# [회의 제목] 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)을 정리하여 다음 주 중 위버스 담당자와의 미팅을 잡음. 근거: "질문들을 적어줘요. 그러면 저기랑 위버스랑 미팅하..." | 차주 중 | 기한미정 |
|
||||
Reference in New Issue
Block a user