> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/creator/content-creator-ko/sdk7/designing-the-experience/mvp-guidelines.md).

# MVP 가이드라인

SDK를 사용해 첫 MVP 씬이나 경험을 제작할 때 권장되는 가이드라인

이 문서의 목적은 Decentraland에서 씬의 첫 번째 반복 버전을 구축하는 과정을 안내하는 데 있습니다. 우리는 이를 최소 기능 제품(MVP)이라고 부를 것입니다.

**씬에 대한 최소 기능 제품(MVP)을 만들 때, 다음 두 가지 초점을 고려해야 합니다:**

1. 프로젝트의 기본 사용자 경험과 기능.
2. 경험을 구축하고 이를 반복적으로 개선하기 위한 기본 "파이프라인", 즉 팀 워크플로와 콘텐츠 관리 시스템의 구축.

MVP는 가능한 모든 경험의 가능한 모든 결과를 보여주려 해서는 안 됩니다. 대신, MVP는 Decentraland의 SDK를 사용하여 구현할 수 있는 경험의 가장 좋은 첫인상이 되어야 합니다.

자신의 한계, 사용자에게 콘텐츠를 제공할 계획, 그리고 사용자의 기대를 고려하는 것이 중요합니다. 이런 방식으로 MVP에 접근하려면 세 가지 서로 다른 관점이 필요합니다:

1. 개발자 또는 제작자로서, 사용자/플레이어에게 경험을 어떻게 전달할 것인가?
2. 사용자 또는 플레이어로서, 이 경험에서 무엇을 기대하는가?
3. 기여자 또는 이해관계자로서, 파이프라인 또는 경험에 어떻게 기여할 것인가?

이 접근 방식은 전통적인 애자일 개발과 구별하는 것이 중요합니다. 디자인 목표를 달성하기 위해 최적이 아닌 방법을 사용해야 할 수도 있기 때문입니다.

특정 릴리스가 플레이어, 파이프라인과 콘텐츠 기여자, 또는 이 둘을 조금씩 모두 더 중점적으로 다루는지 결정하려면, 사용자 기대의 맥락에서 자신의 목표를 검토해야 합니다.

각 릴리스를 계획할 때, 이 세 가지 관점 각각에 따라 의식적이고 의도적으로 우선순위를 설정하는 것이 매우 중요합니다.

개발 백로그가 두 가지 흐름을 따를 것이라고 예상할 수 있습니다:

* 생성하고자 하는 사용자 경험의 백로그.
* 배포 파이프라인을 구축하는 데 필요한 도구와 인터페이스의 개발. (또는 기여자와 개발 팀 모두를 위해 기존 파이프라인을 최적화하는 작업.)

이 두 흐름은 또한 두 가지 서로 다른 테스트 접근 방식을 따릅니다:

* 사용자 경험 테스트는 전통적인 사용자 인터페이스 테스트에 더 가깝고, 동일한 스크립팅 리소스를 필요로 하지는 않습니다.
* 도구와 파이프라인 인터페이스 테스트에는 더 많은 기술적 리소스가 필요합니다.

사용자나 플레이어 앞에 가치 제안을 더 빨리 내놓을수록, 그 제안을 확인하거나 거부할 피드백을 더 빨리 얻을 수 있습니다. 가치를 빠르게 확인하는 것은 매우 중요합니다. 많은 숙련된 개발자들은 새로운 메커니즘이 얼마나 놀라울지 의심의 여지 없이 확신했지만, 막상 사용해 보니 어색하고 버그투성이였고, 플레이어는 전혀 반응하지 않았거나, 소비자의 욕구/필요를 해결하지 못했다는 이야기를 들려줄 것입니다. 가능한 한 적은 노력으로 빠르게 실패해야 실패에서 배우고 다음 반복을 계획할 수 있습니다.

어떻게 빨리 실패할 수 있을까요? 플레이어가 제품을 직접 접하게 하는 데 필요한 최소한만 하면 됩니다.

## 최소 기능 제품을 위한 요소

기본 MVP를 위해 고려해야 할 요소 목록은 다음과 같습니다. 더 견고한 대체안을 개발하는 동안 어떤 것을 임시 자리표시자로 사용하겠다고 명시하는 것은 괜찮습니다.

1. 아트 제작
   * 먼저, 기본 정지 이미지로 시작하세요
   * 첫 번째 테스트는 스타일에 관한 것이어야 합니다: 선택한 스타일이 사용자에게 매력적인가요?
   * 이는 외주 아티스트에게 제공할 스타일 가이드의 시작이 될 수 있습니다
2. 씬 제작
   * 공간에 대한 기본적인 감각을 구축하세요
   * 플레이어는 자신이 새롭고 독특한 공간에 있다고 느껴야 합니다
   * 주변 공간과 구분되도록 당신의 공간을 구획하세요
   * 경계가 드러나고 분명해야 합니다. 단지 그려진 선일지라도요
   * 전체 영역을 정적 콘텐츠/아트로 채우세요
3. 씬에 렌더링된 아트
   * 빌보드를 사용해도 괜찮고, 다른 표지판도 좋습니다(실제 빌보드일 수도 있고, 카메라를 향하는 더 정교한 스프라이트일 수도 있습니다)
   * 공간의 분위기와 미학(즉, 스타일, 밝음, 어두움)을 설정하세요
   * 과정을 기록하세요: 아트는 어떻게 만들어져 씬에 배포되었나요?
   * 반복 배포를 위해 아트 파일을 어떻게 정리하고 싶나요?
4. 플레이어 경험
   * 플레이어는 당신의 공간/씬을 방문할 수 있습니다
   * 플레이어는 당신의 공간을 주변 공간과 구별할 수 있습니다
5. 파이프라인 목표
   * 샘플 정적 씬 배포: 플레이어와의 상호작용 없음
   * 애니메이션 씬 배포: 분수나 펄럭이는 깃발 같은 요소가 애니메이션을 반복 재생함
   * 인터랙티브 씬 배포: 플레이어 참여 포함
   * 콘텐츠를 다시 배포하여 배포 파이프라인을 시연: 아트 제작부터 스크립팅 + QA를 포함한 씬 내 배포까지]
   * 파이프라인의 공백을 드러내기: 특정 콘텐츠 배포 영역에서 알려지지 않은 요소를 식별

## 프로토타입 수준

빠르게 실패하면 연속적인 프로토타입을 만들어 경험을 개발할 수 있으며, 각 반복은 이전 버전을 기반으로 합니다.

**단일 플레이어 프로토타입으로 시작하세요. 그런 다음 멀티플레이어 상호작용을 위한 스크립팅을 계획할 수 있습니다. 마지막으로, 트랜잭션 계층을 보여 주는 지속형 핵심 루프에 도전할 수 있습니다.**

**지속형 핵심 루프란 무엇인가요?**

게임 디자인에서 지속형 핵심 루프는 플레이어의 행동과 그 행동에 대한 게임의 반응을 이끄는 근본적인 "게임 루프"입니다. 이러한 지속형 루프는 Districts에서 제공하는 것과 같은 모든 형태의 가상 경험으로 확장됩니다.

**트랜잭션 계층이란 무엇인가요?**

트랜잭션 계층은 블록체인 업데이트나, 플레이어 행동의 지속적인 기록을 유지하기 위해 당신의 경험에 연결된 다른 애플리케이션과 같은 시스템 간의 인터페이스입니다. 이 지속적인 기록을 생성하고 유지하는 것이 더 개인적인 경험을 만드는 요소입니다.

MVP는 단일 플레이어 경험으로 만드는 것을 권장합니다.

예를 들어, 다음과 같은 연속된 경험을 포함하는 씬을 설계할 수 있습니다:

* 단일 플레이어가 세계에 들어올 수 있습니다.
* 플레이어는 씬 안의 하나 또는 두 개의 단순한 엔티티와 상호작용할 수 있습니다.
* 다른 플레이어들이 합류해 세계와 다른 플레이어와 상호작용할 수 있습니다.
* 마지막으로, 각 플레이어가 씬에 들어왔다는 사실을 기억하고 플레이어의 이벤트와 활동을 추적하는 기능을 추가할 수 있습니다.

## MVP를 공유하는 방법

새 버전의 씬을 Decentraland에 업로드하기 전에 테스트 사용자와 변경 사항을 시험해 보는 것을 권장합니다. 씬을 [Decentraland World](/creator/content-creator-ko/sdk7/publishing/publishing-options.md#decentraland-worlds) LAND 없이 링크로 공유할 수 있으며, 운영 중인 콘텐츠에는 영향을 주지 않습니다.

## 추가 고려 사항

기본 사용 사례를 다루고 나면, 메커니즘에 집중함으로써 릴리스 관리 전략을 더 정교하게 발전시킬 수 있습니다. **메커니즘** 은 플레이어가 취할 수 있는 모든 행동과, 시스템이 이러한 플레이어 행동에 따라 제공할 응답을 포괄하는 넓은 용어입니다.

**기기 상호운용성** 은 반드시 인지해야 할 중요한 사항입니다. 당신의 씬 사용자는 데스크톱, 모바일 기기 또는 VR 헤드셋으로 씬에 접근할 수 있습니다. 사용자는 어느 기기에서든 씬과 reasonably 잘 상호작용할 수 있어야 합니다. VR 헤드셋을 사용하는 경우, 멀미를 유발할 수 있는 어지러운 움직임은 피하세요.

**오디오** 는 씬의 분위기를 좌우하는 또 다른 핵심 요소입니다. 바람, 귀뚜라미 소리, 멀리서 들려오는 대화, 심지어 음악 같은 배경음은 몰입감을 높이고 맥락을 제공하는 매우 강력한 방법이 될 수 있습니다. 또한 소리의 위치를 더 강조하거나 덜 강조하기 위해 볼륨 수준이 소스와의 거리에 어떻게 대응할지도 바꿀 수 있습니다.

읽기 [게임을 위한 디자인 제약 사항](/creator/content-creator-ko/sdk7/designing-the-experience/design-games.md) 다른 여러 고려 사항을 자세히 살펴보려면.

파이프라인을 구축한 후에는 릴리스의 주기를 정립하는 데 사용할 수 있는 여러 프로토타입 중 하나로 MVP를 생각하세요. 각 릴리스의 초점은 달라질 수 있으며, 경험의 각 측면을 혼합한 형태일 수도 있습니다. 그러나 각 반복이 이전 버전을 기반으로 점점 더 복잡한 경험을 전달하는 것을 목표로 해야 합니다.

1. **MVP**: 싱글 플레이어
2. **릴리스 2**: 멀티플레이어 및/또는 상호작용 지원 추가
3. **릴리스 3**: 첫 번째 메커니즘 도입
4. **릴리스 4**: 오디오 지원 추가
5. **릴리스 5**: 아트 파이프라인 마무리

예를 들어, 프리스비 골프 게임을 위한 MVP를 만든다고 해봅시다. MVP에는 코스의 정지 이미지 몇 장이 포함될 것입니다. 플레이어는 아주 기초적인 블록 스타일 방식으로 디스크를 던질 수도 있습니다. 이를 통해 기본 던지기 메커니즘을 정립할 수 있습니다. 다음 릴리스에는 멀티플레이어 지원용 프로토타입이 포함되어, 두 사용자가 동시에 로그인하여 우리 LAND에서 플레이하는 것을 시연하고 테스트할 수 있습니다.

기억하세요. 최종 목표는 진정으로 몰입감 있는 3D 월드이지만, MVP는 그곳에서 시작되지 않습니다. 플레이어를 가능한 한 빨리 당신의 세계로 데려오는 것이 첫 번째 목표여야 합니다. 릴리스를 테스트하는 데 몇 달이 아니라 몇 주가 걸리도록 하는 것은, 노력 낭비 없이 배우고 반복하기 위해 매우 중요합니다.

경험이 주는 첫인상을 항상 염두에 둘 것을 강력히 권장합니다. 아무것도 없는 경험은 플레이어를 실망시킬 것입니다. 반면에, 초기 콘텐츠와 기본적인 경험이 있는 씬은 앞으로 올 것들의 가능성을 플레이어에게 보여 주고, 커뮤니티와 상호작용하며 다음 몇 개의 릴리스를 기대하고 다시 방문하도록 유도합니다.

## 고려해야 할 지속성 요소

궁극적으로는 아키텍처의 트랜잭션 계층이 작동 중임을 보여 줄 수 있는 수준의 지속성을 달성하고자 합니다. 트랜잭션은 플레이어의 행동에만 국한되지 않고, 플레이어에 대한 시스템의 반응도 포함합니다.

1. **계정 정보**: 로그인 이름, 시간대, 해당 경험/게임의 위치
2. **리더보드 통계**: 이전 게임 결과, 전역/지역 순위, 대회
3. **신원 검증**: 이더리움 지갑 주소 또는 기타 백엔드 신원 관리
4. **블록체인 업데이트**: 경험/게임에 따라 트랜잭션 투명성을 위해 블록체인 원장을 업데이트하는 데 필요
5. **런타임 지속성**: 잠재적으로 분산된 플랫폼 전반에서 지속성을 유지하기 위한 임시 데이터(즉, 단일 게임 경험에 대한 체력)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decentraland.org/creator/content-creator-ko/sdk7/designing-the-experience/mvp-guidelines.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.