로블록스 Studio 패키지가 업데이트되지 않을 때: 수정본·AutoUpdate 점검법

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

패키지에 새 버전을 게시했는데 다른 Place의 복사본이 그대로라면 “동기화가 고장 났다”고 보기 전에 그 복사본이 여전히 패키지인지, 로컬 수정본인지, 새 버전만 기다리는지부터 나눠야 합니다. 특히 수정된 복사본에서는 AutoUpdate가 꺼지고 무시되며, Update All도 수정본을 의도적으로 건너뜁니다. 덮어쓰기 전에 보존할 변경과 버릴 변경을 결정하는 진단 순서를 정리했습니다.

1. “업데이트 안 됨”은 네 가지 상태로 나누면 빨라집니다

PackageLink API의 Status 설명에는 Up To Date, Changed, New Version Available, Changed + New Version Available 네 상태가 있습니다. 게임 실행 스크립트에서 이 값을 읽어 진단하는 용도가 아니라 Studio가 패키지 복사본의 로컬 변경과 원격 버전 차이를 관리하기 위한 상태입니다. Explorer 아이콘과 우클릭 메뉴, PackageLink 속성을 함께 보면서 아래처럼 해석하면 됩니다.

가장 헷갈리는 것은 마지막 상태입니다. 내 수정도 살리고 다른 사람이 게시한 최신 변경도 받아야 하므로 단순한 “새 버전 받기” 문제가 아닙니다. 어떤 복사본을 기준으로 합칠지 팀에서 정하고, 현재 변경을 별도 모델이나 Place 버전에 보존한 뒤 처리해야 합니다.

2. Explorer에서 PackageLink가 사라졌다면 이미 일반 객체입니다

공식 문서는 패키지로 변환된 객체의 루트 아래에 PackageLink가 생긴다고 설명합니다. 이 객체를 삭제하거나 패키지 루트 밖으로 옮기면 복사본이 일반 객체로 바뀌며 업데이트 같은 패키지 기능을 잃습니다. 비슷한 이름과 모양을 유지하더라도 연결 정보는 되살아나지 않습니다.

1. Explorer에서 문제가 있는 모델의 루트를 펼칩니다.
2. 직계 자식에 PackageLink가 있는지 확인합니다.
3. 없다면 우클릭 메뉴에 Get Latest Package가 나타나는지만 반복 확인하지 말고 일반 객체로 전환된 것으로 판단합니다.
4. 현재 객체의 고유 변경을 별도 모델로 보존합니다.
5. Toolbox의 Inventory → My Packages 등 공식 경로에서 패키지를 새로 삽입하고 필요한 변경만 수동으로 옮깁니다.

PackageLink는 Script로 새로 만드는 객체가 아닙니다. API 문서도 Studio 상호작용으로만 추가된다고 밝힙니다. 빈 PackageLink를 코드로 붙여 복구하려는 방법이나 다른 패키지의 PackageLink만 복사하는 방법은 사용하지 마세요. 다른 자산 ID와 버전 연결을 임의로 섞으면 상태 판단이 더 어려워집니다.

패키지를 새로 삽입하기 전에 낯선 자산 내부 Script도 확인합니다. Creator Hub는 자신이 만들지 않은 자산에 악성 Script가 포함될 수 있으므로 먼저 Place를 저장하고 Script를 조사하라고 경고합니다. 패키지라는 형식 자체가 코드의 안전성을 보증하지 않습니다.

3. Publish·Undo·Get Latest는 서로 다른 문제를 해결합니다

메뉴 이름이 비슷해 보여도 세 명령의 방향이 다릅니다. 작업 전에 “이 복사본의 변경을 원본에 올릴 것인가, 버릴 것인가, 원본의 최신 버전을 받을 것인가”를 한 문장으로 답해야 합니다.

원본 모델을 수정하고 Place만 게시했다고 다른 Place의 패키지 버전이 올라가는 것은 아닙니다. Creator Hub는 수정된 패키지를 먼저 게시하지 않아도 Place 자체는 게시할 수 있다고 설명합니다. 즉, Place 게시 성공과 패키지 새 버전 생성은 별개입니다. 다른 Place에서 새 버전을 찾지 못하면 원본 쪽에서 Publish to Package를 실제로 완료했는지 먼저 확인하세요.

반대로 보존할 필요가 없는 실험 변경이라면 복사본을 삭제하고 재삽입하기보다 Undo Changes to Package가 상태를 더 명확하게 되돌립니다. 다만 구성용 Attribute는 일반 변경 되돌리기와 기본값 초기화가 같지 않으므로 7절을 함께 확인해야 합니다.

4. AutoUpdate가 켜져 있어도 수정본에서는 작동하지 않습니다

PackageLink.AutoUpdate의 기본값은 패키지 생성 시 false입니다. true로 설정하면 Place가 열려 있는 동안 Studio가 새 버전을 주기적으로 확인해 최신 버전으로 갱신합니다. “켜자마자 즉시 모든 Place와 공개 서버가 바뀐다”는 기능은 아닙니다.

• 새 패키지의 기본값: false이므로 복사본마다 의도적으로 켰는지 확인합니다.
• 확인 시점: Place가 Studio에서 열려 있는 동안 새 버전을 주기적으로 확인합니다.
• 로컬 수정: 복사본을 수정하면 AutoUpdate가 비활성화되고 무시됩니다.
• 중첩 패키지: 중첩 구조에서는 가장 바깥쪽 부모 패키지에만 AutoUpdate가 적용됩니다. 부모가 업데이트될 때 내부도 함께 처리됩니다.
• 공개 상태: 업데이트된 Place는 저장과 게시를 구분해야 합니다. Studio 파일이 바뀌었다고 실행 중 공개 서버가 즉시 같은 버전이 되는 것은 아닙니다.

수정본에서 AutoUpdate를 다시 기대하려면 먼저 변경을 Publish to Package로 정식 버전으로 만들거나, Undo Changes to Package로 버려 깨끗한 상태로 되돌립니다. “AutoUpdate 체크를 껐다 켜기”만 반복해도 로컬 수정 상태는 해제되지 않습니다.

자동 업데이트는 편하지만 예상하지 못한 Script 변경까지 받을 수 있습니다. 공용 시스템 패키지는 새 버전을 테스트 Place에서 확인한 뒤 운영 Place에 반영하는 수동 흐름이 더 적합할 수 있습니다. 자동화를 선택할 때는 편의보다 변경 검토와 되돌리기 책임을 먼저 정하세요.

5. Use와 Edit 권한은 ‘받기’와 ‘게시하기’를 가릅니다

PackageLink.PermissionLevel은 현재 Studio 이용자의 패키지 권한을 나타냅니다. PackagePermission에는 None, NoAccess, Revoked, UseView, Edit, Own이 있습니다. 권한 데이터가 보이지 않는 None과 실제 접근 불가인 NoAccess를 같은 의미로 단정하지 말고 로그인 계정·그룹 역할·자산 소유자를 함께 확인합니다.

친구·게임·그룹·그룹 역할에 패키지 권한을 줄 수 있지만, Place 편집 권한과 패키지 Edit 권한은 같은 것이 아닙니다. 협업자가 Experience를 열어 수정할 수 있어도 다른 사람이 소유한 패키지의 새 버전을 게시할 수 없을 수 있습니다. Place 자체의 협업 권한 문제는 Studio 협업자 편집·게시 권한 확인법과 분리해서 점검하세요.

그룹에서 쓸 패키지는 처음 만들 때 Ownership을 올바른 그룹으로 선택해야 합니다. 공식 문서는 자산 시스템이 소유권 이전을 지원하지 않는다고 경고합니다. 개인 소유로 만든 뒤 나중에 그룹 패키지로 “옮기면 된다”고 가정하지 말고, 장기 유지 주체를 정한 뒤 생성하세요.

패키지 안에 비공개 이미지·오디오처럼 제한 자산이 있으면 패키지 사용 권한만으로 런타임 표시 권한까지 자동 해결되지 않습니다. 해당 게임·친구·그룹이 그 제한 자산을 사용할 명시적 권한도 가져야 합니다. Studio에서는 모델이 보이지만 공개 게임에서 일부 이미지나 소리가 빠진다면 패키지 동기화보다 자산 권한을 따로 확인합니다.

6. 중첩 패키지는 안쪽부터 게시해야 합니다

차량 패키지 안에 엔진 패키지가 있는 식으로 패키지를 중첩할 수 있습니다. 안쪽 패키지를 수정하면 안쪽과 바깥쪽 부모 패키지가 모두 수정 상태가 됩니다. 이때 부모부터 Publish to Package 하려고 하면 내부 변경과 상태가 충돌하므로 허용되지 않습니다.

1. Explorer에서 가장 깊은 중첩 패키지부터 찾습니다.
2. 그 패키지의 변경이 의도한 것인지 View Script Changes나 버전 비교 자료로 확인합니다.
3. 가장 안쪽 패키지를 Publish to Package 합니다.
4. 한 단계 위 부모의 수정 상태와 포함된 버전을 다시 확인합니다.
5. 부모 패키지를 게시하고 최상위까지 같은 순서로 올라갑니다.

안쪽 수정이 실수였다면 게시하지 말고 안쪽 패키지에서 먼저 되돌립니다. 부모만 깨끗하게 만들려고 삭제·재삽입하면 어느 버전의 중첩 패키지가 포함됐는지 추적하기 더 어려워집니다. 팀 작업에서는 패키지별 변경 설명에 “엔진 v12 반영”처럼 중첩 의존 버전을 함께 남기는 편이 좋습니다.

7. 루트 Attribute 구성값은 업데이트 뒤에도 남을 수 있습니다

패키지 루트의 Attribute는 복사본별 구성값으로 쓸 수 있습니다. 패키지를 게시할 때 현재 Attribute 집합과 값이 기본 구성으로 기록되고, 각 복사본에서 바꾼 값은 Properties에서 굵은 기울임꼴로 표시됩니다. 최신 패키지를 받아도 복사본에서 변경한 구성값은 보존되고, 변경하지 않은 Attribute는 최신 기본값을 받습니다.

이 동작 때문에 “업데이트했는데 값 하나만 예전 그대로다”라는 증상이 생길 수 있습니다. 구조·Script는 최신인데 속도, 색상, 모드 같은 루트 Attribute만 다른 경우 동기화 실패로 단정하지 말고 그 값이 복사본별 구성으로 변경돼 있는지 확인합니다.

• 복사본마다 달라야 하는 값이면 현재 로컬 구성값을 유지합니다.
• 새 기본값을 받아야 한다면 Attributes 영역의 해당 값 옵션에서 Reset을 사용합니다.
• Undo Changes to Package가 구성값을 기본값으로 초기화하는 명령이라고 가정하지 않습니다.
• 기본 구성값만 바꾸려면 의도한 기본값을 가진 패키지에서 다시 게시하고, 다른 변경과 섞이지 않게 확인합니다.

PackageLink API의 SerializedDefaultAttributes 설명도 마지막 게시 또는 동기화 시점의 루트 Attribute 스냅샷을 기준으로 현재 값을 비교해 로컬 맞춤값을 보존한다고 밝힙니다. 따라서 Attribute 보존은 우연한 잔여값이 아니라 패키지 업데이트의 병합 규칙입니다.

8. Update All은 수정된 복사본을 의도적으로 건너뜁니다

한 게임의 여러 Place에 같은 패키지가 많으면 Update All을 쓸 수 있습니다. 하지만 대량 업데이트는 의도하지 않은 덮어쓰기를 막기 위해 수정된 복사본을 갱신하지 않습니다. 작업이 끝난 뒤 Studio가 업데이트하지 못한 패키지 수를 경고하므로, 완료 메시지만 보고 전부 최신이라고 판단하면 안 됩니다.

1. 대상 패키지의 깨끗한 복사본 하나에서 Update All을 시작합니다.
2. 대상 Place 목록을 확인하고 운영·테스트 Place를 구분합니다.
3. 완료 뒤 업데이트된 수와 건너뛴 수를 기록합니다.
4. 건너뛴 각 복사본을 열어 Changed 상태의 원인을 확인합니다.
5. 로컬 변경을 게시·보존·되돌릴지 개별 결정한 뒤 최신 버전을 적용합니다.
6. 각 Place를 테스트하고 필요한 Place를 명시적으로 게시합니다.

공식 문서에서 Update All은 선택한 Place를 자동으로 저장하지만 게시하지 않는다고 구분합니다. 팀원이 웹에서 보는 공개 게임 버전까지 바뀌었다고 생각하지 않도록 저장 완료, 테스트 완료, 게시 완료를 별도 체크 항목으로 관리하세요.

9. 덮어쓰기 전에 버전 비교, 문제 뒤에는 복원입니다

패키지의 Asset Configuration → Versions에서는 게시 시각과 변경 설명을 확인하고 이전 게시 버전을 복원할 수 있습니다. 버전 비교 도구는 계층에서 추가·삭제·수정된 Instance를 표시하고, Properties 탭에서 속성과 Attribute 차이, Script 탭에서 줄 단위 코드 차이를 보여 줍니다.

다만 Script 비교가 “누가” 변경했는지 알려 주는 감사 로그는 아닙니다. 공식 문서도 현재 버전과 최신 게시 또는 로컬 버전의 차이를 보여 줄 뿐 변경한 협업자를 표시하지 않는다고 설명합니다. 책임자를 추측하기보다 Place 버전 기록, 팀 변경 설명과 별도 작업 기록을 함께 봅니다.

복원은 패키지 버전의 기준을 되돌리는 작업입니다. 복원 뒤 각 Place의 복사본이 저절로 공개 서버까지 동일해지는 것은 아니므로 다시 최신 패키지를 받고, 테스트하고, Place를 게시하는 단계가 필요합니다.

10. 운영 Place를 건드리기 전에 작은 복사본으로 재현합니다

패키지 동기화 문제는 자동 갱신과 여러 Place가 얽혀 있어 한 번에 고치면 원인을 놓치기 쉽습니다. 소유한 테스트 Experience 또는 운영 Place의 별도 저장본에서 아래 순서로 재현하세요.

1. 기준 기록: PackageId, VersionNumber, 소유자, 현재 권한, AutoUpdate와 로컬 수정 표시를 적습니다.
2. 깨끗한 복사본: 같은 패키지의 새 복사본을 넣고 현재 버전을 비교합니다.
3. 원본 게시 확인: 눈에 띄는 비파괴 변경 하나를 원본 테스트 복사본에서 만들고 Publish to Package 합니다.
4. 수동 갱신: AutoUpdate가 꺼진 깨끗한 복사본에서 Get Latest Package가 새 버전을 받는지 확인합니다.
5. 자동 갱신: 다른 깨끗한 복사본에서 AutoUpdate를 켜고 Place가 열린 동안 새 버전 반영을 확인합니다.
6. 수정본 제외: 세 번째 복사본을 로컬 수정한 뒤 AutoUpdate와 Update All이 이를 덮어쓰지 않는지 확인합니다.
7. 구성 보존: 루트 Attribute 하나를 복사본별로 바꾸고 최신 버전 뒤 값이 보존되는지 확인합니다.
8. 게시 분리: 저장 뒤 실제 게임 게시 전 Server & Clients 등 필요한 테스트를 하고, 게시 대상을 명시적으로 선택합니다.

통과 기준은 “모든 복사본이 무조건 같은 값”이 아닙니다. 깨끗한 복사본은 최신 구조를 받고, 수정본은 경고와 함께 보존되며, 복사본별 구성값은 의도대로 유지되고, 권한 없는 계정에서는 게시가 차단되는 것이 정상일 수 있습니다.

11. 증상별로 첫 확인 지점을 정합니다

한 번에 여러 원인을 고치려 하지 마세요. PackageLink → Changed 여부 → 최신 버전 존재 → 권한 → 중첩 → 구성값 → Place 게시 순서로 한 항목씩 확인하면 어떤 조치가 상태를 바꿨는지 남길 수 있습니다.

12. 팀이 함께 쓰는 패키지의 공개 전 점검표

• 패키지를 처음 만들 때 개인과 그룹 중 장기 소유자를 올바르게 선택했습니다.
• PackageLink를 삭제·이동하거나 다른 패키지에서 복사하지 않았습니다.
• 변경을 Place에만 저장한 것과 Publish to Package한 것을 구분했습니다.
• Changed 복사본에서 AutoUpdate가 무시된다는 점을 알고 있습니다.
• UseView와 Edit 권한을 협업자의 역할에 맞게 나눴습니다.
• 중첩 패키지는 가장 안쪽부터 게시했습니다.
• 복사본별 루트 Attribute 중 유지할 구성과 기본값으로 돌릴 구성을 구분했습니다.
• Update All의 미업데이트 경고 수를 확인하고 수정본을 개별 처리했습니다.
• Update All이 Place를 저장할 뿐 게시하지 않는다는 점을 확인했습니다.
• 낯선 패키지의 Script와 제한 자산 권한을 공개 전에 검토했습니다.
• 버전 설명을 남기고 문제가 생기면 비교·복원할 정상 버전을 알고 있습니다.
• 운영 Place 게시 전 테스트 복사본에서 수동·자동·수정본·구성값 경로를 각각 확인했습니다.

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

아래 Roblox Creator Hub 1차 자료를 2026년 10월 8일 공개 HTML과 Markdown 원문으로 확인했습니다. Markdown 메타데이터의 last_updated는 Packages 문서가 2026년 10월 7일 17:02:20 UTC, PackageLink API가 17:02:21 UTC, PackagePermission 열거형이 17:02:22 UTC로 표시됐습니다. 이 시각은 문서 최종 갱신 시각이며 기능의 최초 출시일을 뜻하지 않습니다.

• Roblox Creator Hub: Packages — 생성·수정·게시·최신 버전 받기, AutoUpdate, Update All, 중첩 패키지, 구성 Attribute, 권한, 버전 복원과 비교 절차를 확인했습니다.
• PackageLink API — AutoUpdate 기본값과 확인 시점, PermissionLevel, Status 네 종류, VersionNumber와 기본 Attribute 스냅샷의 의미를 확인했습니다.
• PackagePermission — None, NoAccess, Revoked, UseView, Edit, Own의 현재 권한 범위를 확인했습니다.
• Asset privacy — 패키지 권한과 별도로 제한 자산의 Experience 사용 권한을 확인할 때 참고하는 공식 문서입니다.

적용 범위: Roblox Studio에서 패키지 복사본이 최신 게시 버전을 받지 못하거나 게시·자동 업데이트·대량 업데이트에서 제외될 때의 일반 진단 절차입니다. 실제 팀 프로젝트의 그룹 역할, 비공개 자산, 운영 Place, 대량 업데이트와 공개 서버를 실행해 측정한 결과가 아니며, Studio UI와 권한 체계는 바뀔 수 있습니다. 운영 자산을 덮어쓰기 전에 별도 저장본에서 최신 Creator Hub 문서와 자신의 PackageId·버전·권한을 기준으로 검증하세요.