> 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 헤드셋으로 씬에 접속할 수 있습니다. 사용자는 어느 기기를 사용하든 씬과 비교적 잘 상호작용할 수 있어야 합니다. 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. **신원 검증**: Ethereum 지갑 주소 또는 기타 백엔드 신원 관리
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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.