> 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/networking/third-party-servers.md).

# 서드파티 서버

서드파티 서버를 사용해 멀티플레이어 Decentraland 씬을 구축합니다.

씬에서 멀티플레이어 상호작용을 위한 권장 방식은 [멀티플레이어 서버](/creator/content-creator-ko/sdk7/networking/authoritative-servers.md). 이 문서에서는 지원되는 다른 옵션들도 다룹니다.

* **REST API + DB**: 자주 변경되지 않는 데이터(리더보드, 방명록)에 적합합니다. 플레이어는 업데이트를 위해 API를 폴링하며, 상태는 세션 간에 유지됩니다. 참조하세요 [네트워크 연결](/creator/content-creator-ko/sdk7/networking/network-connections.md) 어떻게 만드는지 `fetch` 씬에서 요청을 보내는 방법.
* **WebSocket 서버**: 실시간 양방향 통신을 가능하게 합니다. WebSocket 사용법은 [네트워크 연결](/creator/content-creator-ko/sdk7/networking/network-connections.md) 여기를 참조하세요. 다음과 같은 라이브러리들은 [Colyseus](https://colyseus.io/) Decentraland SDK와 잘 호환됩니다.

{% hint style="warning" %}
**📔 참고**: 타사 서버는 `syncEntity`, `validateBeforeChange` 또는 `저장소` 와 통합되지 않습니다 — 자체적인 상태 관리 및 동기화 로직을 구현해야 합니다.
{% endhint %}

변경 사항이 플레이어 간에 다음을 통해 알림되는 하이브리드 접근 방식을 선택할 수도 있습니다 [serverless-multiplayer](/creator/content-creator-ko/sdk7/networking/serverless-multiplayer.md), 하지만 최종 상태는 이후 방문자를 위해 REST API를 통해서도 저장됩니다.

타사 서버를 사용하는 씬의 몇 가지 예시는 다음과 같습니다:

* [리더보드](https://github.com/decentraland/sdk7-goerli-plaza/tree/main/leader-board)
* [방명록](https://github.com/decentraland/sdk7-goerli-plaza/tree/main/guest-book-api)
* [진위 확인](https://github.com/decentraland/sdk7-goerli-plaza/tree/main/validate-player-authenticity)

## 로컬에서 테스트하기

타사 서버를 사용하는 씬을 미리 보려면 씬과 그것이 의존하는 서버를 모두 실행해야 합니다. 서버는 더 쉽게 테스트하기 위해 미리보기와 같은 컴퓨터에서 로컬로 실행할 수 있습니다. 로컬에서 실행할 때 서버는 안전하지 않은 `http` 또는 `ws` 연결을 사용할 수 있어 설정이 더 쉽습니다.

서버를 시작하려면 `/server` 폴더로 이동하여 실행하세요 `npm run start`.

미리보기를 두 개의 별도 창에서 열면 각 창은 별도의 플레이어로 취급됩니다. 각 창을 서로 다른 주소로 연결하세요. 두 클라이언트는 동일한 로컬 서버 인스턴스에 연결됩니다.

Creator Hub을 사용하여 다음을 켜세요 **Multi-Instance Preview** 다음의 **Desktop Client** 하위 메뉴에서 **Play Options**, 그런 다음 다음을 클릭하세요 **Play** 버튼을 한 번 더 눌러 두 번째 디센트럴랜드 explorer 창을 엽니다. 두 창 모두 서로 다른 주소로 연결해야 합니다. 장면이 다시 로드되어도 동일한 세션이 유지됩니다.

대안으로, 브라우저 URL에 다음을 입력하여 두 번째 Decentraland 탐색기 창을 열 수 있습니다:

> `decentraland://realm=http://127.0.0.1:8000&local-scene=true&debug=true&multi-instance=true`

## 별도의 영역

Decentraland의 플레이어는 여러 개의 별도 *영역*. 플레이어는 서로 다른 영역에 있으면 같은 파셀에 서 있더라도 서로를 볼 수 없고, 상호작용하거나 채팅할 수도 없습니다. 이처럼 플레이어를 나누면 어떠한 제한에도 걸리지 않고 무제한의 플레이어를 처리할 수 있습니다. 또한 서로 상호작용하는 플레이어 간의 핑 시간이 허용 가능한 수준이 되도록, 가까운 지역의 플레이어들을 매칭합니다.

씬이 플레이어 간 변경 사항을 실시간으로 동기화하기 위해 타사 서버로 데이터를 보낸다면, 변경 사항은 같은 영역에 있는 플레이어들 사이에서만 동기화되는 것이 중요합니다. 하나의 영역에 속한 모든 변경 사항은 다른 영역의 변경 사항과 분리해서 처리해야 합니다. 그렇지 않으면 아무도 변경하지 않았는데도 플레이어는 무언가가 으스스하게 변하는 것을 보게 됩니다.

각 플레이어의 영역을 얻는 방법은 [플레이어 데이터 가져오기](/creator/content-creator-ko/sdk7/interactivity/user-data.md)

## 멀티플레이어 지속성

플레이어가 들어올 때마다 새로 마운트되는 로컬 씬과 달리, 타사 서버를 사용하는 씬은 플레이어가 씬에 들어오고 나간 이후에도 훨씬 더 오래 지속되는 수명을 가집니다.

따라서 플레이어가 항상 같은 초기 상태의 씬을 발견하는 것은 아니라는 점을 고려하여 경험을 설계해야 합니다. 씬에 적용된 모든 변경 사항은 다른 플레이어가 발견할 수 있도록 남아 있으므로, 이러한 변경 사항이 미래의 플레이어 경험을 원치 않는 방식으로 방해하지 않도록 해야 합니다.

### 상태 초기화

씬을 로드할 때 기본 상태가 아니라 서버에 저장된 공유 정보를 바탕으로 구성되도록 하세요.

경우에 따라 씬에 어떤 종류의 초기화 버튼을 포함하는 것이 좋습니다. 초기화 버튼을 누르면 씬이 자연스럽게 초기화됩니다.

때로는 씬 상태의 변수들을 기본값으로 되돌리는 것만을 의미하기도 합니다. 하지만 씬을 초기화하는 과정에는 서버 측에서 리스너를 구독 해제하고 루프를 중지하는 것도 포함될 수 있습니다. 씬을 초기화할 때마다 빈 루프가 남아 있다면, 이것들이 계속 쌓여 씬 성능에 나쁜 영향을 미치게 됩니다.


---

# 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/networking/third-party-servers.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.