성능 문제 식별

*이 콘텐츠는 AI(베타)를 사용해 번역되었으며, 오류가 있을 수 있습니다. 이 페이지를 영어로 보려면 여기를 클릭하세요.

성능 문제를 식별하는 것은 일반적으로 세 가지 범주 중 하나인 프레임 속도(계산), 메모리 또는 로드 시간에 대해 깊이 파고드는 것을 의미합니다.

Roblox에는 성능 문제를 식별하기 위한 여러 도구가 있으며, 그 중 일부는 Roblox 클라이언트(따라서 Studio에서도 사용 가능)에서 사용할 수 있고, 일부는 Studio에서만 사용할 수 있습니다. 클라이언트 동작을 직접 관찰할 수 있는 반면, 서버 문제를 진단하려면 도구를 사용해야 합니다.

진단 도구

도구설명위치키보드 단축키환경
개발자 콘솔실시간 로그 메시지, 오류 및 메모리, 네트워킹, 스크립트 성능에 대한 자세한 정보를 제공하는 콘솔입니다. 메모리 소비, 주요 서버 건강 통계, 스크립트 성능 통계를 보기 위해 유용하며, 클라이언트 또는 서버 MicroProfiler를 시작할 수 있습니다.
Studio

게임 내
F9
Studio 테스트

라이브 세션
MicroProfiler각 프레임에서 작업에 소요되는 계산 시간을 분해하는 디버깅 도구입니다. 개별 프레임의 정확한 분해를 보여주는 덤프를 생성할 수 있어 성능 문제를 일으키는 특정 작업을 식별하는 데 유용합니다. 클라이언트 또는 서버에서 프로파일러를 실행할 수 있으며, 문제가 있는 쪽에서 실행할 수 있습니다.
Studio

게임 내
CtrlAltF6 (⌘⌥F6)
Studio 테스트

라이브 세션
장면 분석클라이언트와 서버 장면이 사용하는 리소스 및 해당 리소스 사용에 책임이 있는 인스턴스에 대한 비교 정보를 제공합니다.StudioN/A
Studio 테스트
성능 통계메모리 소비, CPU, GPU, 전송 및 수신된 네트워크 데이터, 핑 시간 등을 포함한 기본 성능 통계가 있는 툴바입니다.
게임 내
CtrlAltF7 (⌘⌥F7)
Studio 테스트

라이브 세션
디버그 통계그래픽, 물리, 네트워크 트래픽 및 FPS에 대한 자세한 정보를 오버레이합니다.
Studio

게임 내
ShiftCtrlF1 (Shift⌘F1), ShiftCtrlF2 (Shift⌘F2), ShiftCtrlF3 (Shift⌘F3), ShiftCtrlF4 (Shift⌘F4), ShiftCtrlF5 (Shift⌘F5)
Studio 테스트

라이브 세션
네트워크 시뮬레이션지연, 지터 및 패킷 손실과 같은 실제 네트워크 조건을 시뮬레이션하여 연결을 플레이 테스트합니다.
Studio
AltS(⌥S)
Studio 테스트
성능 대시보드클라이언트 및 서버 메모리 사용량, 클라이언트 프레임 속도, 서버 하트비트 및 충돌 비율에 대한 집계 차트가 있는 대시보드입니다. 시간에 따른 성능 패턴 분석에 유용합니다. 성능 모니터링을 참조하세요.
크리에이터 대시보드
N/A
라이브 세션

서버 계산

서버 하트비트는 모든 게임에서 60 FPS로 제한되므로 낮은 값은 성능 문제를 나타낼 수 있습니다. 서버 하트비트를 확인하려면:

  • 개발자 콘솔에서 - 서버 작업 탭에서 하트비트 행을 확장하고 게임의 하트비트를 나타내는 초당 단계 값을 확인합니다.

  • MicroProfiler에서 그래프를 확인하여 프레임이 16.67ms 이상 걸리는지 확인할 수 있습니다.

서버 하트비트가 저하된 또 다른 증상은 증가된 지연(일반적으로 핑으로 알려짐)입니다. 서버가 각 프레임에서 작업을 완료하는 데 걸리는 시간이 길어질수록 클라이언트에서 전송 및 수신된 네트워크 데이터를 처리하는 데 걸리는 시간도 길어집니다. 서버에 연결된 모든 플레이어의 평균 핑을 확인하려면 개발자 콘솔의 서버 통계 탭으로 이동하세요.

성능을 개선한 후에도 서버 하트비트가 낮게 유지된다면, 게임이 기본적으로 서버에서 제공하는 CPU보다 더 많은 CPU를 필요로 할 수 있습니다. 계산을 위한 확장 서비스를 통해 더 많은 CPU를 예약할 수 있습니다.

클라이언트 계산

기본 클라이언트 프레임 속도 제한은 60 FPS입니다. 그러나 사용자는 Windows에서 프레임 속도 제한을 최대 240 FPS까지 높일 수 있습니다.

프레임 속도는 장치 간에 크게 다릅니다. 예를 들어, 고급 PC는 계산 문제를 "무식하게" 처리할 수 있어 프레임 속도가 거의 눈에 띄지 않게 떨어질 수 있습니다. 저사양 장치에서 테스트하면 문제를 더 심각하게 인식할 수 있습니다.

게임의 프레임 속도를 확인하려면:

  • 클라이언트에서 ShiftF5를 눌러 디버그 통계 요약을 표시합니다.

  • Studio의 창 ⟩ 성능 메뉴에서 통계를 켜서 디버그 통계를 활성화합니다.

  • MicroProfiler에서 그래프를 확인하여 프레임이 16.67ms 이상 걸리는지 확인할 수 있습니다.

서버 메모리

서버 메모리 사용량을 50% 이하로 유지하는 것이 좋습니다. 총 서버 메모리는 다음 공식을 사용합니다:

6.25 GiB + (100 MiB * 최대 연결 플레이어 수)

예를 들어, 30명의 플레이어가 연결된 서버는 총 약 9.18 GiB의 메모리를 가집니다. 서버는 플레이어가 연결될 때 메모리를 얻지만, 플레이어가 연결 해제될 때는 잃지 않습니다. 10명의 플레이어가 나가더라도 서버는 8.2 GiB로 줄어드는 대신 여전히 9.18 GiB의 메모리를 유지합니다.

서버가 종료될 때(예: 비어 있거나 업데이트 프로세스의 일환으로), 그 대체 서버는 기본 메모리 양으로 시작하고 플레이어가 연결됨에 따라 메모리를 확장하기 시작합니다.

클라이언트 메모리

게임의 메모리 사용량을 확인하는 방법은 여러 가지가 있습니다:

  1. 개발자 콘솔을 열고 메모리 탭으로 전환합니다. 이 탭은 메모리가 어떻게 할당되고 있는지에 대한 분해를 제공합니다. 가장 정확한 수치를 얻으려면 Studio보다 클라이언트를 사용하세요.
  2. 클라이언트의 설정 메뉴에서 성능 통계 보기를 활성화하여 총 클라이언트 메모리 사용량이 표시된 오버레이를 확인합니다.

높은 메모리 사용량이 반드시 문제를 나타내는 것은 아니지만, 추가 조사가 필요할 수 있는 몇 가지 징후는 다음과 같습니다:

  • 성능 대시보드에 표시되는 클라이언트 충돌의 상당한 비율, 특히 업데이트와 일치하는 갑작스러운 증가. 일정 수의 충돌은 예상되지만, 충돌 비율이 2-3%를 초과하면 조사해야 합니다.
  • 게임이 지원하기를 원하는 장치에서 테스트 중 충돌이 발생합니다.

클라이언트에서 게임의 메모리 소비의 상당 부분은 메모리에 로드된 자산(예: 이미지, 메시, 오디오 파일)에서 발생합니다. 개발자 콘솔에서 PlaceMemory 아래의 다음 레이블을 확인하세요:

  • GraphicsMeshParts - 메시로 소비되는 그래픽 메모리.
  • GraphicsTexture - 텍스처로 소비되는 그래픽 메모리.
  • Sounds - 오디오 파일로 소비되는 메모리.

로드 시간

로드 시간, 즉 조인 시간은 플레이어가 재생을 클릭한 시점부터 세계가 렌더링되고 플레이를 시작할 수 있는 시점까지의 총 시간입니다. 클라이언트가 서버에 연결된 후 조인은 다음 순서로 진행됩니다:

  1. ReplicatedFirst가 클라이언트에 복제되고, 그 안에 있는 모든 사용자 정의 로딩 화면이 나타납니다.
  2. 나머지 데이터 모델이 복제되며, ReplicatedStorage와 Workspace의 모든 것이 포함됩니다. 인스턴스 스트리밍을 활성화하면 이 단계에서 플레이어의 스폰 지점 근처의 Workspace 영역만 복제됩니다.
  3. 플레이어의 아바타가 로드됩니다. 로드 시간은 로딩 화면이 사라지고 세계가 렌더링되기 시작할 때 종료됩니다.

어떤 단계가 느린지 아는 것은 가장 큰 영향을 미치는 최적화를 선택하는 데 도움이 됩니다. 일반적인 원인과 수정 사항은 성능 개선을 참조하세요.

로드 시간을 확인하기 위한 내장 도구는 없지만, 밀리초 수준의 정밀도가 필요하지 않기 때문에 스톱워치만 있으면 현재 기준을 이해하고 실질적인 개선이 있었는지 확인할 수 있습니다. ReplicatedFirst에서 클라이언트 스크립트를 사용하여 변경 사항이 로드 시간에 미치는 영향을 어느 정도 파악할 수 있지만, 이 스크립트는 완전한 종단 간 측정을 제공하지 않습니다. ReplicatedFirst가 복제된 후 타이밍을 시작하고 초기 복제가 완료되고 DataModel.Loaded가 발생할 때 중지되므로 서버에 연결하는 데 걸리는 시간이나 아바타 로드 시간은 포함되지 않습니다:

local startTime = os.clock()
game.Loaded:Connect(function()
local loadTime = os.clock() - startTime
local roundedLoadTime = math.round(loadTime * 10000) / 10000 -- 소수점 4자리
print("게임이 " .. roundedLoadTime .. " 초에 로드되었습니다.")
print("로드된 인스턴스 수: " .. #workspace:GetDescendants())
end)

추가 통찰력을 위해, Studio 설정의 네트워크 탭에서 조인 크기 분해 인쇄를 활성화하여 게임을 Studio에서 시작할 때 크기별로 상위 20개 인스턴스와 인스턴스 유형별 비율 분해를 인쇄합니다.

로드 시간이 게임의 명백한 크기에 비해 예상보다 높다면, 인식되지 않거나 난독화된 스크립트가 있는지 장소를 검사하세요. 크리에이터 스토어의 일부 무료 모델에는 플레이어가 조인할 때 복제해야 하는 데이터 양을 극적으로 증가시키는 수천 개의 추가 인스턴스를 생성하는 스크립트가 포함되어 있습니다.

각 최적화 또는 업데이트 전후에 로드 시간을 측정하여 그 영향을 확인하고 회귀를 잡아내세요. 갑작스러운 증가는 종종 ReplicatedStorage에 최근에 콘텐츠가 추가되었거나 자산 변경으로 다운로드 크기가 증가했음을 의미합니다.

핑

핑(지연)의 두 가지 주요 측정값은 네트워크 핑과 데이터 핑입니다.

네트워크 핑은 클라이언트가 네트워크 데이터 패킷을 전송한 시점부터 서버의 에코 응답을 받을 때까지의 왕복 시간을 측정한 것입니다. 일반적인 핑 네트워크 유틸리티에서 보고되는 time과 유사합니다.

네트워크 핑은 성능 통계 바에서 확인할 수 있습니다. 이는 주로 클라이언트와 서버 간의 네트워크 경로 길이에 의해 영향을 받으며, 사용자의 제어를 벗어납니다. 그러나 Studio에서 플레이 테스트할 때 네트워크 시뮬레이션을 사용하여 핑 및 기타 네트워크 조건을 시뮬레이션할 수 있습니다.

데이터 핑은 클라이언트가 복제 시스템을 통해 데이터를 신뢰성 있게 전송한 시점부터 서버의 복제 시스템에서 에코 응답을 받을 때까지의 왕복 시간을 측정한 것입니다. 여기에는 클라이언트와 서버의 복제 대기열에서 소요된 시간과 손실되거나 손상된 패킷의 TCP와 유사한 재전송이 포함됩니다.

데이터 핑은 클라이언트에서 신뢰할 수 있는 원격 이벤트를 전송하고, 서버에서 이를 수신한 후 서버에서 클라이언트로 신뢰할 수 있는 원격 이벤트를 응답으로 전송하는 것과 유사합니다. 데이터 핑은 클라이언트와 서버 간의 네트워크에서 소요된 시간도 포함되므로 네트워크 핑보다 크거나 같습니다.

서버에 연결된 모든 플레이어의 평균 데이터 핑은 개발자 콘솔의 서버 통계 탭에서 확인할 수 있습니다. 개별 클라이언트의 데이터 핑은 ShiftF3를 사용하여 네트워크 디버그 통계를 표시하여 확인할 수 있습니다.

데이터 핑은 네트워크 경로와 복제 대기열 지연 모두에 의해 영향을 받습니다. 서버가 네트워크가 전송할 수 있는 것보다 더 빠르게 복제 데이터를 생성할 때(또는 클라이언트가 처리할 수 있는 것보다 더 빠르게 생성할 때), 데이터는 복제 대기열에서 대기해야 합니다. 데이터 핑과 네트워크 핑 간의 차이는 네트워크 재전송과 Roblox 앱에서 네트워크 데이터를 처리하는 방식으로 인해 정상입니다. 그러나 데이터 핑이 네트워크 핑보다 상당히 높으면 MicroProfiler를 사용하여 네트워크 트래픽을 확인하세요. 최적화 제안은 네트워킹 및 복제를 참조하세요.

©2026 Roblox Corporation. Roblox 및 Roblox 로고, 'Powering Imagination'은 미국 및 기타 국가 내 당사의 등록 및 미등록 상표입니다.