로블록스 Studio 데이터가 저장되지 않을 때: DataStore 권한·Script·키 점검법

작성·편집: Robux.co.kr 운영자 · 출처·실행 범위 안내

테스트 중 숫자가 올랐는데 다시 실행하자 0으로 돌아오면 SetAsync를 여러 번 호출하기 쉽습니다. 공식 Data Store 문서와 오류 코드를 대조해 보니 “저장 코드를 실행함”, “Studio가 백엔드에 접근할 수 있음”, “같은 게임·같은 키를 다시 읽음”은 별도 조건이었습니다. 운영 데이터를 건드리지 않는 테스트본부터 만들고 Output의 첫 오류를 기준으로 권한·실행 위치·키·요청 실패를 한 단계씩 나누는 편이 안전합니다.

1. 먼저 ‘저장이 안 된다’의 성공 조건을 한 줄로 적습니다

한 세션에서 화면 숫자가 바뀐 것과 세션을 나갔다 다시 들어와 값이 복원된 것은 다릅니다. 전자는 메모리의 변수나 리더보드 표시만 바뀌어도 보이고, 후자는 DataStore 쓰기와 다음 세션의 읽기가 모두 성공해야 합니다. 테스트용 복사본에서 다음 네 항목을 기록하세요.

1. 게임과 Place: 테스트하는 게임 이름, 소유자가 개인인지 그룹인지, 현재 Place가 어느 게임에 게시됐는지 적습니다. 로컬 파일만 연 상태와 Roblox에 게시된 게임을 구분합니다.
2. 저장 이름과 키: GetDataStore("PlayerData")의 Store 이름, scope를 따로 썼다면 scope, 실제 키 문자열을 그대로 기록합니다.
3. 실행 위치: 코드를 넣은 객체가 Script, LocalScript, ModuleScript 중 무엇이며 어느 서비스 아래 있는지 적습니다.
4. 재현 순서: 입장 → 값 변경 → 저장 확인 문구 → 테스트 종료 → 다시 입장 → 불러온 값을 같은 순서로 확인합니다.

성공 기준: 첫 세션의 저장 함수가 오류 없이 끝나고, 새 세션에서 같은 Store·scope·키로 읽은 값이 예상값과 일치해야 합니다. UI 숫자만 남아 있거나 Output에 성공 문구만 찍힌 것은 다음 세션 복원까지 증명하지 않습니다.

2. Output의 첫 신호로 원인을 네 갈래로 나눕니다

Roblox 공식 오류 문서는 DataStore 요청이 연결 상태나 서비스 문제로 실패할 수 있으므로 호출을 pcall()로 감싸라고 안내합니다. Output에서 가장 먼저 나온 오류 한 개와 그 직전 키를 기록한 뒤 다음 단계로 이동하세요. 후속 오류는 첫 실패 때문에 연쇄적으로 생겼을 수 있습니다.

3. 게시된 테스트 게임과 Studio API 접근을 분리해서 확인합니다

Data stores 문서에 따르면 Studio에서 테스트하는 게임은 기본적으로 DataStore에 접근할 수 없습니다. 접근을 켜려면 게임이 먼저 게시돼 있어야 하며 Studio에서 File → Experience Settings → Security → Enable Studio Access to API Services를 켜고 저장합니다.

하지만 이 설정은 단순한 편의 스위치가 아닙니다. 공식 문서는 Studio가 실제 클라이언트와 같은 DataStore에 접근하므로 운영 중인 게임에서는 제작 데이터가 덮어써질 위험이 있다고 경고합니다. 그래서 운영 게임에서 바로 켜기보다 별도 테스트 버전의 게임을 게시하고 그곳에서 활성화하라고 안내합니다.

1. Studio의 현재 게임 이름과 소유자를 확인하고, 운영본이 아닌 테스트용 복사본인지 봅니다.
2. 아직 게시하지 않은 로컬 파일이라면 테스트 게임으로 게시합니다. 다른 운영 게임을 대상으로 Publish to Roblox As를 잘못 선택하지 않습니다.
3. Experience Settings의 Security에서 Studio API 접근을 켜고 Save합니다.
4. Play 테스트를 새로 시작하고 Output의 접근 오류가 사라졌는지 확인합니다. 설정을 켠 채 이전 실행 결과만 보고 성공으로 판단하지 않습니다.

4. DataStore 호출은 서버 Script에 두고 결과를 숨기지 않습니다

공식 문서는 DataStore가 게임 서버에서만 접근 가능하므로 Script 또는 서버 Script가 사용하는 ModuleScript에서 호출해야 한다고 설명합니다. 버튼 UI 아래의 LocalScript에서 직접 SetAsync()를 부르는 구조라면 키나 값이 맞아도 서버 저장이 되지 않습니다. 클라이언트 입력이 필요하면 검증된 RemoteEvent로 서버에 요청하고, 실제 저장 판단은 서버에서 해야 합니다.

진단용으로는 저장과 읽기를 각각 pcall()로 감싸고 성공 여부와 오류를 분리합니다. 사용자 ID 같은 개인 식별값이나 전체 저장 테이블을 공개 로그에 그대로 남기지 말고 테스트용 키와 최소 상태만 출력하세요.

local DataStoreService = game:GetService("DataStoreService")
local testStore = DataStoreService:GetDataStore("SaveCheckV1")
local testKey = "diagnostic_001"

local saveOk, saveError = pcall(function()
    testStore:SetAsync(testKey, { coins = 10, schema = 1 })
end)

if not saveOk then
    warn("DataStore save failed:", saveError)
    return
end

local loadOk, loadedValue = pcall(function()
    return testStore:GetAsync(testKey)
end)

if loadOk then
    print("DataStore read completed:", loadedValue ~= nil)
else
    warn("DataStore read failed:", loadedValue)
end

이 코드는 테스트용 최소 진단 예시이지 운영용 플레이어 저장 시스템 전체가 아닙니다. 종료 순간 저장, 자동 저장, 재시도 간격, 스키마 이전, 동시 접속 충돌, 클라이언트 입력 검증을 해결하지 않습니다. 진단 후에는 의미 없는 테스트 키를 계속 늘리지 말고 Data Stores Manager에서 대상과 권한을 확인한 뒤 정리 계획을 세우세요.

5. 같은 게임·Store·scope·키를 다시 읽는지 확인합니다

DataStore는 게임 단위로 일관되며 같은 게임의 여러 Place가 같은 저장소를 사용할 수 있습니다. 반대로 비슷한 이름의 테스트 게임과 운영 게임은 서로 다른 게임이므로 같은 코드와 키를 써도 저장값이 공유된다고 가정하면 안 됩니다. 다음 문자열 하나만 달라도 다른 위치를 읽게 됩니다.

• 게임: 테스트본을 저장한 게임과 다시 입장한 게임이 같은지 확인합니다.
• Store 이름: PlayerData와 PlayerDataV2는 다릅니다. 대소문자와 공백을 포함해 그대로 비교합니다.
• scope: GetDataStore()의 두 번째 인수를 썼다면 저장과 읽기 양쪽의 scope를 맞춥니다.
• 키: User_ 접두사, 숫자를 문자열로 바꾸는 방식, Player.UserId를 조합한 결과를 양쪽에서 같은 함수로 만듭니다.

읽기 성공 결과가 nil이면 네트워크 호출 자체가 성공했지만 그 키에 값이 없을 수 있습니다. 이때 기본값을 바로 저장하기 전에 실제로 어떤 키를 읽었는지 확인하세요. 키 오타 때문에 기존 값이 있는데도 새 사용자처럼 초기화하고 그 값을 덮어쓰는 실수를 막아야 합니다.

Creator Hub의 Creations → 대상 게임 → Configure → Data Stores Manager에서는 소유자 또는 허용된 그룹 권한으로 저장소와 키 항목, 사용량을 확인할 수 있습니다. 조회 권한과 삭제 권한은 다르므로, 원인 확인을 위해 키나 Store를 삭제할 필요는 없습니다.

6. 호출이 너무 잦거나 동시에 쓰는지 봅니다

SetAsync(), GetAsync(), UpdateAsync() 같은 함수는 네트워크 요청이며 항상 성공하는 로컬 변수 대입이 아닙니다. 공식 문서는 요청 한도를 넘으면 쓰로틀링되고 큐가 가득 찬 뒤 요청이 버려질 수 있다고 안내합니다. 값이 바뀔 때마다 또는 RunService 프레임마다 저장하면 테스트 인원이 적어도 호출 구조가 잘못된 것입니다.

1. 저장 함수가 호출되는 이벤트와 횟수를 셉니다. 반복문·Changed 이벤트·RemoteEvent가 중복 연결되지 않았는지 봅니다.
2. 저장 직전의 값 변경과 저장 완료 뒤의 상태를 분리합니다. pcall()이 실패했는데 UI만 성공으로 바꾸지 않습니다.
3. 여러 서버가 같은 키를 바꿀 수 있다면 SetAsync()가 마지막 쓰기로 덮어쓸 수 있음을 고려합니다. 공식 문서는 다중 서버 갱신에는 현재 값을 읽어 콜백으로 바꾸는 UpdateAsync()를 설명합니다.
4. UpdateAsync() 콜백 안에는 task.wait() 같은 양보 함수가 들어갈 수 없습니다. 콜백이 nil을 반환하면 쓰기가 취소되는 점도 확인합니다.

오류가 제한·큐·서비스 상태와 관련돼 보이면 즉시 촘촘하게 재시도하지 않습니다. 저장 중요도, 중복 호출 방지, 제한된 횟수의 지수형 재시도 같은 운영 정책은 게임 설계에 맞게 별도로 정해야 합니다. 이 글은 특정 동시 접속자 수에 맞춘 저장 주기를 제시하지 않습니다.

7. 안전한 테스트본에서 한 조건씩 되돌려 검증합니다

점검은 테스트 키 한 개로 게시 상태 → 접근 권한 → 서버 실행 → 저장 결과 → 같은 키 읽기 순서를 한 바퀴 도는 방식으로 시작합니다. 예상 소요 시간은 15~20분 정도를 확보하자는 편집상 계획이며 실제 장애 해결 시간을 측정한 값은 아닙니다. 성공하면 브라우저를 새로 고친 것이 아니라 Play 세션을 완전히 끝내고 다시 시작해 값이 복원되는지 확인하세요.

그래도 실패하면 게임 식별 정보, Store와 scope 이름, 익명화한 테스트 키, Script 위치, 재현 순서, Output의 첫 오류, 발생 시각을 묶어 공식 개발자 지원 채널에서 확인합니다. API 키, 인증 정보, 실제 플레이어 전체 데이터는 공개 게시글에 올리지 마세요.

공식 출처·갱신일·적용 범위

아래 Roblox Creator Hub 문서를 2026년 9월 14일 공개 페이지와 Markdown 원문으로 확인했습니다. 네 문서의 메타데이터 last_updated는 2026년 9월 11일 22:47 UTC이며, 기능의 최초 발표일이 아니라 문서 최종 갱신 시각입니다. 별도의 최초 게시일은 원문에서 확인하지 못했습니다.

• Data stores — Studio 접근 기본 차단, 게시된 테스트 게임의 Security 경로, 운영 데이터 위험, 서버 Script, Get·Set·Update와 pcall()을 확인했습니다.
• Save player data with standard data stores — 게임 게시 후 Studio API 접근을 켜는 순서와 서버 쪽 저장·불러오기 튜토리얼의 적용 범위를 확인했습니다.
• Data store error codes and limits — Studio 접근 오류, 요청 실패 처리, 쓰로틀링·큐와 요청 한도를 확인했습니다.
• Data Stores Manager — Creator Hub의 저장소·키·사용량 확인 경로와 그룹 권한 범위를 확인했습니다.

적용 범위: 표준 DataStoreService가 Roblox Studio 테스트나 게시 게임에서 값을 쓰고 다시 읽지 못할 때의 첫 진단입니다. OrderedDataStore 순위표 설계, MemoryStore, Open Cloud API 키, 데이터 이전·복원, GDPR 삭제 요청, 실제 운영 게임의 자동 저장·종료 처리·재시도 아키텍처는 다루지 않습니다. 메뉴와 한도가 바뀌면 현재 Studio 화면과 최신 공식 문서를 우선하세요.