4.2 KiB
4.2 KiB
id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, inferred_by
| id | title | category | status | canonical_id | aliases | duplicate_of | source_trust_level | confidence_score | tags | raw_sources | last_reinforced | github_commit | inferred_by | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| wiki-2026-0508-유니버스-ltv-universe-ltv | 유니버스 LTV(Universe LTV) | 10_Wiki/Topics | needs_review | self | none | A | 0.92 |
|
2026-05-08 | pending | Claude Opus 4.7 (auto-normalize 2026-05-08) |
유니버스 LTV(Universe LTV)
📌 한 줄 통찰 (The Karpathy Summary)
'유니버스 LTV(Universe LTV)'는 단일 게임의 수명 주기에 갇혀 있던 기존의 고객 평생 가치(LTV) 제약을 극복하기 위해 등장한 개념입니다 [1, 2]. 이는 플레이어가 한 게임에서 획득한 온체인 자산(예: NFT, 토큰)이 개발사의 다른 게임에서도 가치나 지위를 부여받는 상호 운용적 구조를 의미합니다 [2]. 이를 통해 게임 내에서 창출된 가치와 경제 활동이 단일 타이틀을 넘어 서로 연결된 '유니버스' 수준으로 계속 확장될 수 있습니다 [1].
📖 구조화된 지식 (Synthesized Content)
- 기존 LTV의 제약 극복: 기존 Web2 하이브리드 캐주얼 장르 등에서는 단일 게임의 수명 주기가 LTV의 한계점으로 작용했습니다 [1]. 기존 방식에서는 LTV를 지속적으로 유지하기 위해 끊임없는 콘텐츠 업데이트와 라이브 옵스(live ops)에 의존해야 했으며 이는 개발사에 큰 부담이 되었습니다 [1]. Web3 환경에서는 가치가 단일 타이틀에 종속되지 않고 그 너머로 확장되도록 하여 이러한 구조적 제약을 해결합니다 [1].
- 온체인 자산의 상호 운용성 활용: 유니버스 LTV는 온체인 자산을 통한 게임 간의 이동성을 기반으로 작동합니다 [1]. Base 플랫폼 기반의 'Chef Universe' 사례처럼, 플레이어가 첫 번째 게임('Rolling Burger')에서 획득한 결과물(예: 햄버거를 분해해 얻은 재료 토큰)은 단일 게임에 귀속되지 않고 단일 계정을 통해 시리즈 내 다른 게임으로 온전히 이전될 수 있습니다 [1]. 즉, 첫 번째 게임에서의 진행 상황이 두 번째 게임에서 명시적인 가치나 지위를 해제(unlock)하는 역할을 합니다 [1].
- 유니버스 경제 생태계와 유지율 강화: 거래 가능한 토큰이나 자산이 중심이 되는 유니버스 LTV 모델에서는 게임 경제가 단일 타이틀의 수명 주기에 의해 상한선이 정해지지 않고 계속해서 확장됩니다 [1]. 게임 내부에서 창출된 가치가 게임 외부의 새로운 참여자, 맥락, 시장 수요와 상호작용하게 됩니다 [1]. 자산을 기반으로 진화하는 이러한 경제 메타(meta)는 플레이어에게 장기적인 전략과 기대감을 제공하여 지속적으로 게임으로 돌아오게 만드는 유지율(retention)의 핵심 동력이 됩니다 [1].
🔗 지식 연결 (Graph)
- Related Topics: LTV (고객 평생 가치, Web3 게임(Web3 Gaming), 상호 운용성(Interoperability]]
- Projects/Contexts: Chef Universe, Base 플랫폼, Play-and-Earn
- Contradictions/Notes: 소스에 관련 정보가 부족합니다.
Last updated: 2026-04-29
🤖 LLM 활용 힌트 (How to Use This Knowledge)
언제 이 지식을 쓰는가:
- (TODO)
언제 쓰면 안 되는가:
- (TODO)
🧪 검증 상태 (Validation)
- 정보 상태: needs_review
- 출처 신뢰도: A
- 검토 이유: (P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)
🧬 중복 검사 (Duplicate Check)
- 기존 유사 문서: (TODO: 인덱서 클러스터 리포트 참조)
- 처리 방식: UPDATE (자동 정규화)
- 처리 이유: Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
⚠️ 모순 및 업데이트 (Contradictions & Updates)
- 과거 데이터와의 충돌: 없음
- 정책 변화: 없음
🕓 변경 이력 (Changelog)
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|---|---|---|---|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |