로블록스 플레이 노트

Roblox Studio streaming tool

ModelStreamingMode 선택 도우미

모델의 초기 자손이 한꺼번에 필요한지, 모든 이용자 또는 특정 이용자에게 항상 필요한지 입력하면 Nonatomic·Atomic·Persistent·PersistentPerPlayer 중 우선 검토할 모드와 테스트 계획을 만듭니다. 입력은 브라우저 안에서만 처리하며 Roblox 계정이나 Place에 연결하지 않습니다.

모델 요구 조건 입력

Luau 문자열에 넣을 이름입니다. 빈 값, 제어 문자, 앞뒤 공백은 오류로 처리합니다.

공식 안전 기준을 계산하는 값이 아닙니다. 선택한 모드가 모델 전체를 함께 보내는지 검토 메모에 남깁니다.

구조·수명 점검

Persistent 모델을 Atomic 모델 안에 중첩하면 바깥 모델도 사실상 계속 남을 수 있습니다.

모델 요구 조건을 입력한 뒤 스트리밍 모드 비교하기를 누르세요.

이 도구가 결정하는 범위

이 페이지는 모델의 사용 조건을 공식 스트리밍 규칙과 비교해 우선 검토할 ModelStreamingMode 한 가지, 함께 확인할 경고, 서버 코드 뼈대와 재현 테스트표를 만듭니다. 모델 크기, Mesh·Texture·Sound 용량, 동시 접속자, 기기 메모리와 네트워크를 실제로 측정하지 않으므로 성능을 인증하거나 특정 모드가 항상 빠르다고 보장하지 않습니다.

관련 글인 StreamingEnabled에서 모델이 사라질 때 점검법은 이미 발생한 nil·stream out·상태 초기화 증상을 따라가는 진단 글입니다. 이 도구는 새 모델을 만들거나 기존 구조를 바꿀 때 요구 조건을 입력해 모드와 테스트 범위를 정하는 용도로 분리했습니다.

수동 선택표: 거리 기준이면 Nonatomic 또는 Atomic

요구 조건우선 후보핵심 확인
일부 BasePart만 먼저 보여도 안전Nonatomic클라이언트가 누락 자손과 stream out을 견디는지
모델이 보일 때 초기 자손 전체가 함께 필요Atomic모델 자체는 WaitForChild로 기다리고, 실행 중 추가 자손은 별도 처리
작은 모델이 모든 이용자에게 항상 필요Persistent서버 처리로 바꿀 수 없는지, 저사양 메모리 비용을 측정했는지
작은 모델이 서버가 고른 이용자에게만 항상 필요PersistentPerPlayerAddPersistentPlayer·RemovePersistentPlayer 수명 관리

Roblox 공식 문서에서 Model의 기본 동작은 Nonatomic입니다. Workspace.ModelStreamingBehavior가 Improved일 때 BasePart가 있는 Nonatomic 모델은 해당 Part가 들어올 때 모델과 비-BasePart 자손이 함께 들어오지만, 모든 BasePart가 한 번에 존재한다고 보장하지는 않습니다. 부분 복제가 기능을 깨뜨리지 않는 구조라면 기본 모드를 유지하는 쪽이 스트리밍의 메모리 이점을 보존하기 쉽습니다.

Atomic은 초기 자손의 동시 도착을 다룹니다

Atomic 모델은 한 BasePart가 스트리밍 대상이 되면 처음부터 있던 자손 전체가 함께 들어옵니다. 클라이언트는 모델 자체를 기다려야 하지만 모델이 존재한 뒤 초기 Part마다 WaitForChild를 반복할 필요는 줄어듭니다. 문, 작은 퍼즐 장치, 서로 떨어지면 기능이 깨지는 차량 하위 시스템처럼 논리 단위가 분명할 때 적합합니다.

Atomic 보장은 모델이 최초 복제된 뒤 서버가 새로 추가한 자손까지 소급하지 않습니다. 실행 중 Part나 Attachment를 붙이는 시스템이라면 ChildAdded·WaitForChild·nil 분기를 유지해야 합니다. 거대한 맵 전체를 Atomic 하나로 묶으면 한 부분만 필요해도 큰 단위를 함께 보내야 하므로, 물리적으로 가깝고 논리적으로 관련된 작은 모델로 나눕니다.

Persistent는 호환성 스위치가 아닙니다

Persistent 모델은 일반적인 stream out 대상이 아니며 모든 이용자에게 완전한 단위로 전송된 뒤 계속 남습니다. 공식 Techniques 문서는 드문 상황에서 작은 수의 Part가 클라이언트 Script에 항상 필요할 때만 사용하고, 가능하면 서버 Script 또는 stream in/out을 견디는 클라이언트 코드를 사용하라고 권합니다. DataModel.Loaded가 아니라 Workspace.PersistentLoaded 뒤에 준비됐다고 판단해야 합니다.

입력한 BasePart 수는 자동 합격선이 아닙니다. Roblox는 “몇 개 이하면 Persistent가 안전하다”는 보편 숫자를 제시하지 않습니다. 이 도구는 수를 검토 메모에 남길 뿐이며, 실제 Mesh·Texture·Sound와 저사양 기기 메모리를 MicroProfiler·Developer Console 등으로 측정해야 합니다.

Persistent 모델을 Atomic 조상 안에 중첩하면 조상 전체가 사실상 Persistent처럼 남을 수 있습니다. 반대로 큰 Persistent 모델 안에 여러 독립 시스템을 넣으면 한 기능 때문에 모두 상주합니다. 깊은 계층을 평평하게 만들고 상시 필요 단위를 작게 분리한 뒤 다시 측정하세요.

PersistentPerPlayer는 서버가 대상을 관리합니다

ModelStreamingMode가 PersistentPerPlayer인 모델은 Model:AddPersistentPlayer()로 추가한 이용자에게 Persistent처럼 동작하고, 나머지 이용자에게는 Atomic처럼 동작합니다. 개인 플롯이나 특정 임무 지역처럼 일부 이용자에게만 계속 필요한 작은 모델을 구분할 때 검토할 수 있습니다.

대상에서 제외할 때 RemovePersistentPlayer()를 호출해도 모델이 즉시 사라진다고 보장되지는 않습니다. 그 이용자에게 Atomic 취급으로 돌아가고, 대상 반경 안이라면 계속 남을 수 있습니다. PlayerRemoving, 임무 종료, 플롯 변경 같은 수명 종료 지점을 코드와 테스트표에 명시하세요. 모델 속성은 PersistentPerPlayer로 설정돼 있어야 Add·Remove 호출이 동작을 바꿉니다.

순간 선로딩과 지속 유지에는 다른 API를 씁니다

먼 위치로 순간이동하기 직전이라면 서버에서 Player:RequestStreamAroundAsync(position, timeout)를 호출해 주변 전송을 요청합니다. 이 호출은 yield하고 효과가 일시적이며, 반환됐다고 모든 대상이 도착했다고 보장하지 않습니다. 유한한 timeout, 이동 취소·재시도 UI와 중요 모델의 존재 확인을 함께 둡니다.

원격 카메라나 먼 물리 영역을 일정 시간 유지해야 한다면 서버의 Player:AddReplicationFocus()와 RemoveReplicationFocus()를 제한적으로 비교합니다. Persistent 모델만으로는 먼 영역의 클라이언트 물리 시뮬레이션이 보장되지 않습니다. 추가 focus는 서버 처리량과 클라이언트 메모리 적응 폭을 사용하므로 기능 종료와 이용자 퇴장 때 반드시 제거합니다.

클라이언트 전체 세계 판정은 모드로 고치지 않습니다

클라이언트의 GetChildren, GetDescendants, Raycast, GetPartBoundsInBox와 Model:GetBoundingBox 결과는 현재 stream in된 콘텐츠만 반영합니다. 보상, 피격, 원거리 시야, 전체 NPC 수처럼 세계 전체가 필요한 판정은 모델을 Persistent로 바꾸는 대신 서버에서 계산하고 필요한 결과만 전달하세요. LocalScript는 화면 효과와 현재 주변 상호작용처럼 부분 세계로 충분한 작업을 맡깁니다.

RemoteEvent로 Workspace instance를 보내도 해당 클라이언트에 아직 복제되지 않았다면 안전하게 쓸 수 없습니다. 식별자·좌표·상태 데이터를 보내고 대상 도착을 기다리거나, 서버 판정 결과만 보여 주는 경계를 설계합니다.

도구 결과를 검증하는 순서

  1. Studio Properties 저장: 대상 Model의 ModelStreamingMode와 Workspace의 StreamingEnabled·ModelStreamingBehavior 값을 기록합니다.
  2. 서버와 클라이언트 분리: Test 또는 Server & Clients를 실행하고 Server Explorer와 각 Client Explorer의 모델·자손 차이를 비교합니다.
  3. 세 거리 확인: 입장 직후, 모델 가까이, 모델에서 멀어진 뒤를 관찰하고 다시 돌아왔을 때 LocalScript 상태가 복구되는지 봅니다.
  4. 모드별 예외 확인: Atomic은 실행 중 추가 자손, Persistent는 PersistentLoaded, PersistentPerPlayer는 선택·비선택 이용자와 Remove 뒤 동작을 따로 시험합니다.
  5. 원격 이동 확인: 순간이동은 유한 timeout과 실패 경로, 지속 원격 영역은 focus 제거와 저사양 메모리를 확인합니다.
  6. 한 번에 하나만 변경: 모델 모드, 반경, Script를 동시에 바꾸지 말고 Output·Network Stats·메모리 변화와 함께 기록합니다.

직접 확인한 범위와 공식 근거

2026년 10월 10일 Windows 데스크톱 브라우저에서 Roblox Creator Hub의 Instance streaming, Techniques and conversion, Model API와 ModelStreamingMode enum 공개 HTML·Markdown 원문을 비교했습니다. Markdown의 last_updated는 스트리밍 두 문서가 2026-10-08 21:44:08 UTC, Model API가 2026-10-08 21:43:58 UTC로 표시됐으며 기능 최초 출시일이 아니라 문서 갱신 시각입니다.

  • Nonatomic·Atomic·Persistent·PersistentPerPlayer의 복제 단위, PersistentLoaded, AddPersistentPlayer·RemovePersistentPlayer와 중첩 계층 주의를 공식 문서에서 확인했습니다.
  • Model.ModelStreamingMode가 ReadWrite이며 저장 가능한 속성이라는 API 메타데이터를 확인했습니다.
  • RequestStreamAroundAsync와 replication focus의 목적 차이, 먼 영역 물리와 클라이언트 공간 질의의 제한을 공식 스트리밍 문서에서 확인했습니다.
  • 실제 Roblox Studio Place에서 네 모드, 저메모리 기기, 다중 클라이언트, 순간이동과 추가 focus를 실행하지 않았습니다. 생성 결과는 소유한 테스트 Place에서 검증해야 합니다.
  • 초기화하면 빈 모델 이름·BasePart 수, Nonatomic 후보, 거리 기준, 정적 자손, 원격 유지 없음, 서버 최종 판정 상태로 돌아갑니다.