로블록스 Studio에서는 되는데 공개 게임에서 오류가 날 때: F9 콘솔 확인법

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

Studio의 Output이 조용하다는 이유만으로 공개 서버에도 문제가 없다고 단정할 수 없습니다. 로컬 테스트와 실제 게임은 접속자 수, 네트워크, 권한, 데이터 요청 조건이 다르고, 오류가 클라이언트와 서버 중 한쪽에만 기록될 수도 있습니다. 먼저 같은 문제를 한 번 재현한 뒤 F9 Developer Console에서 어느 쪽 신호가 변했는지 좁혀야 불필요한 코드 수정을 줄일 수 있습니다.

1. Studio 정상과 공개 게임 정상을 같은 결과로 보지 않습니다

Roblox는 엔진의 클라이언트·서버 구조 때문에 공개 전 여러 테스트 모드를 사용해야 한다고 설명합니다. Studio의 Test와 Test Here도 클라이언트와 서버를 따로 시뮬레이션하지만, 실제 공개 서버의 접속자 수, 저장 데이터, 네트워크 지연과 권한까지 완전히 같아지는 것은 아닙니다.

오류가 공개 게임에서만 나타난다면 바로 코드를 여러 군데 고치지 않습니다. 먼저 Studio의 Server & Clients 테스트에서 같은 행동을 반복해 클라이언트가 두 개일 때도 생기는지 확인하고, 그래도 재현되지 않으면 공개 서버 한 곳에서 정확한 시각을 기록합니다.

2. 오류를 다시 만들기 전에 조건을 고정합니다

콘솔에는 정상적인 경고와 다른 시스템 메시지도 함께 쌓일 수 있습니다. 문제 행동 전후를 구분할 수 있도록 아래 항목을 먼저 한 줄씩 적습니다.

1. 게임과 Place: 게임 이름, Universe와 Place를 구분하고 공개 게임의 최신 버전이 의도한 게시본인지 확인합니다.
2. 계정 역할: 소유자, 그룹 편집 권한 계정, 일반 플레이어 중 누구로 재현했는지 기록합니다.
3. 환경: Studio 또는 Roblox 앱, 운영체제, 기기, 연결 방식과 대략적인 핑을 적습니다.
4. 한 행동: 입장, 버튼 클릭, 아이템 구매, 저장, 텔레포트처럼 오류 직전에 한 행동 하나만 고릅니다.
5. 시각과 결과: 초 단위까지 가능하면 기록하고 기대한 결과와 실제 결과를 한 문장씩 나눕니다.

3. 문제 행동 직후 F9 Developer Console을 엽니다

Creator Hub 공식 문서는 Studio 테스트와 실행 중인 공개 게임에서 Developer Console을 열 수 있다고 안내합니다. 가장 짧은 방법은 F9이며, 채팅에서 /console을 입력하거나 Roblox 메뉴의 Settings → Developer Console → Open을 사용할 수도 있습니다.

1. 게임 입장 직후에는 콘솔을 열지 말고, 먼저 기준 시각과 정상 상태를 기록합니다.
2. 문제가 나는 행동을 한 번만 수행합니다.
3. 즉시 F9를 열고 상단의 치명적 오류·경고 수, 클라이언트 메모리와 평균 핑을 기록합니다.
4. Log에서 오류 문구와 스크립트 이름·줄 번호가 있다면 전체 문장을 복사합니다.
5. 같은 행동을 연속 클릭하지 말고 콘솔을 닫은 뒤 한 조건만 바꿔 다시 비교합니다.

콘솔이 열리지 않는다고 기능이 없는 것으로 단정하지 마세요. 키보드 기능키 설정에 따라 F9가 다른 동작을 할 수 있으므로 게임 메뉴의 Settings 경로로 다시 확인합니다. /console은 채팅 입력이 허용된 환경에서만 대안으로 사용합니다.

4. Client와 Server 로그를 반드시 분리합니다

Developer Console의 Log에는 Client와 Server 전환이 있습니다. Client 쪽에는 LocalScript와 Client RunContext의 출력이 나타나며, 게임을 실행한 이용자가 자신의 로컬 출력을 볼 수 있습니다. Server 쪽에는 서버 Script의 출력이 나타나지만 게임 소유자 또는 편집 권한이 있는 그룹 구성원만 볼 수 있습니다.

일반 플레이어 계정에서 Server 탭이 비어 있거나 보이지 않는 것은 서버가 정상이라는 증거가 아닙니다. 권한 있는 계정으로 같은 서버에 들어가거나, Studio의 Server & Clients 테스트에서 서버 창의 Output을 확인합니다. 협업자가 서버 로그를 봐야 한다면 먼저 게임별 편집·게시 권한이 실제로 부여됐는지 확인하세요.

5. 빨간 줄보다 ‘첫 오류와 반복 조건’을 찾습니다

Log에는 스크립트의 진단 메시지와 오류가 표시됩니다. 같은 오류가 수십 번 반복되면 마지막 줄부터 고치기보다 첫 발생 시각과 가장 처음 나온 스택·스크립트 위치를 찾습니다.

1. 문제 행동 이전부터 있던 경고와 행동 직후 새로 생긴 오류를 구분합니다.
2. 오류 문구, 스크립트 경로, 줄 번호와 Client·Server 쪽을 함께 기록합니다.
3. 같은 문구가 반복되면 횟수와 반복 간격을 봅니다. 한 번 클릭했는데 계속 증가하면 연결 이벤트나 반복문을 의심할 근거가 됩니다.
4. 오류가 없으면 코드가 실행되지 않았는지, 정상 종료됐지만 결과만 다른지 확인할 수 있도록 단계별 진단 메시지를 최소한으로 추가합니다.
5. 재현이 끝나면 민감한 데이터가 출력되지 않도록 임시 진단 메시지를 제거하거나 제한합니다.

비밀번호, 인증 토큰, DataStore 키와 이용자의 개인정보를 로그에 출력하지 마세요. 지원 커뮤니티에 전체 로그를 올리기 전에도 사용자 이름, 서버 식별 정보와 개인 데이터를 가리고 문제 전후의 필요한 부분만 공유합니다.

6. 오류가 없으면 Network·Memory·Profiler로 범위를 좁힙니다

Network 도구는 게임이 만든 웹 호출과 DataStoreService 같은 Roblox 서비스의 요청을 보여 줍니다. Summary에서는 요청 종류별 전체·실패 횟수와 걸린 시간을 보고, Details에서는 개별 요청의 메서드, 상태 코드, 시간, 요청 종류와 주소를 확인할 수 있습니다.

• 저장 직후 실패 수가 늘면 같은 시각의 Server Log와 함께 확인합니다. Network 실패만으로 스크립트의 잘못인지 일시적인 서비스 문제인지 단정하지 않습니다.
• 외부 HTTP 요청이 느리다면 한 번의 시간뿐 아니라 같은 행동을 여러 서버·시각에서 재현한 기록을 비교합니다.
• DataStore 문제는 API 서비스 접근 설정과 Studio·공개 게임 차이를 함께 봅니다. 자세한 순서는 DataStore 저장 실패 점검법에서 확인할 수 있습니다.

Memory는 엔진 내부와 제작한 구성 요소의 실시간 메모리 사용량을 범주별로 보여 줍니다. Luau heap은 스크립트 메모리 스냅샷을 여러 번 만들어 객체 유형과 엔진 클래스별 차이를 비교할 수 있습니다. 입장 직후, 같은 행동 10회 뒤, 일정 시간 뒤처럼 조건을 고정해 비교해야 증가 추세를 판단할 수 있습니다.

Script Profiler는 실행 중인 스크립트가 소비한 CPU 시간을 기록해 비용이 큰 스크립트를 찾는 도구입니다. 핑이 높다는 이유만으로 CPU 문제라고 결론내리거나, 메모리 수치가 높다는 이유만으로 누수라고 단정하지 않습니다. 렉의 기본 분류는 핑·FPS 렉 진단표와 함께 보되, 제작자는 콘솔의 로그·요청·메모리 변화로 원인을 더 좁혀야 합니다.

7. 콘솔이 닫혔다면 로컬 로그와 재현 자료를 확인합니다

공식 Debugging 문서는 Studio와 Player의 출력이 기기의 로그 파일에도 기록된다고 설명합니다. Windows에서는 파일 탐색기의 %LOCALAPPDATA%\Roblox\logs, macOS에서는 Finder의 Go → Go to Folder에서 ~/Library/Logs/Roblox를 엽니다.

1. 오류를 재현한 정확한 시각을 기준으로 해당 세션의 로그 파일을 찾습니다.
2. Windows에서는 같은 문자열 식별자를 가진 로그가 동일한 Studio 세션에서 나온 것인지 확인합니다.
3. 오류 문구를 검색하고 앞뒤의 필요한 구간만 별도 메모에 복사합니다.
4. 게임 이름·Place, 게시 버전, 계정 역할, 기기, 재현 순서와 함께 보관합니다.
5. Roblox 지원이나 개발자 포럼에 제출할 때 개인정보·토큰·사용자 생성 내용을 가립니다.

로그 폴더 전체를 공개 첨부하지 않습니다. 원인을 모를 때도 ‘안 됩니다’보다 어느 환경에서, 어떤 행동 직후, Client와 Server 중 어디에서, 어떤 첫 오류가 나왔는지를 적으면 다른 사람이 같은 조건을 재현하기 쉽습니다.

8. 수정 뒤에는 같은 순서로 한 번 더 확인합니다

핵심 순서는 재현 조건 고정 → F9 상단 신호 기록 → Client·Server Log 분리 → Network·Memory 보조 확인 → 한 가지 수정 → 같은 조건으로 Studio와 공개 서버 재검증입니다. 콘솔의 숫자 하나가 아니라 문제 행동 전후에 어떤 신호가 함께 바뀌었는지를 기준으로 판단하세요.

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

아래 Roblox Creator Hub 1차 자료를 2026년 9월 28일 확인했습니다. 공개 Markdown 메타데이터에는 Developer Console과 Debugging이 2026년 9월 25일 18:51:41 UTC, Studio testing modes가 2026년 9월 25일 18:51:42 UTC 갱신으로 표시됐습니다.

• Developer Console — F9·/console·메뉴 실행 경로, Client·Server 로그 권한, Memory·Luau heap·Network·Script Profiler의 표시 범위를 확인했습니다.
• Debugging — Breakpoint·Watch·Call Stack의 기본 흐름과 Developer Console, Windows·macOS 로그 파일 위치를 확인했습니다.
• Studio testing modes — Test·Test Here·Run, Client·Server 전환, Server & Clients 다중 테스트와 Output의 클라이언트·서버 표시를 확인했습니다.

적용 범위: Roblox Studio 테스트에서는 정상인데 공개 게임에서만 스크립트 오류, 저장 실패, 네트워크 지연 또는 시간이 지날수록 느려지는 현상이 생길 때 첫 진단 순서를 정리했습니다. 특정 게임의 코드 수정, Roblox 서비스 장애 판정, 메모리의 정상 절대값, 모바일·콘솔의 로그 수집 절차와 MicroProfiler의 세부 프레임 분석은 다루지 않습니다. 실제 콘솔에 표시된 오류·권한·게시 버전과 최신 Creator Hub 문서가 이 글보다 우선합니다.