게임 프로파일러는 하나면 충분하다? 무료 도구 조합이 더 정확하다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

프레임이 끊기는 순간 개발자는 흔히 가장 익숙한 게임 프로파일러 하나부터 실행합니다. 그런데 CPU 사용률이 높다는 결과만 보고 코드를 고쳤다가, 실제 원인이 GPU 동기화나 메모리 할당이었다는 사실을 뒤늦게 발견하는 경우가 적지 않습니다.

게임 성능 분석은 도구의 가격이나 기능 수보다 관측 범위를 어떻게 조합하느냐가 중요합니다. 엔진 내장 프로파일러, Tracy, RenderDoc, NVIDIA Nsight Graphics는 서로 경쟁하는 제품처럼 보이지만 실제로는 각기 다른 질문에 답합니다. 한 도구에 모든 판단을 맡기기보다 프로젝트 단계와 병목의 위치에 따라 선택해야 분석 시간이 줄어듭니다.

프로파일러 네 가지가 보여주는 병목은 서로 다릅니다

CPU부터 GPU 프레임까지 비교하면 선택 기준이 보입니다

게임 프로그래밍에서 ‘느리다’는 말은 원인을 설명하지 못합니다. 메인 스레드가 물리 연산에 묶였을 수도 있고, 렌더 스레드가 드로 콜 제출에 시간을 쓰고 있을 수도 있습니다. GPU가 복잡한 셰이더를 처리하느라 늦어졌거나 매 프레임 발생하는 작은 할당이 가비지 컬렉션을 유발했을 가능성도 있습니다.

아래 표는 Unity Profiler와 Unreal Insights처럼 대표적인 엔진 내장 도구, 범용 실시간 CPU 프로파일러인 Tracy, 프레임 디버거 RenderDoc, 하드웨어 중심 분석 도구 NVIDIA Nsight Graphics를 비교한 것입니다. 가격은 라이선스 정책이 바뀔 수 있으므로 고정 금액보다 도입 비용과 운영 부담을 중심으로 보는 편이 안전합니다.

초기 프로토타입이라면 엔진 내장 프로파일러가 가장 빠릅니다. 어떤 오브젝트의 업데이트가 비싼지, 물리와 애니메이션 중 어느 쪽이 프레임을 소비하는지 코드 문맥을 유지한 채 확인할 수 있기 때문입니다. 반면 자체 엔진이나 C++ 비중이 높은 프로젝트에서는 Tracy의 사용자 정의 영역과 스레드 타임라인이 훨씬 선명한 답을 줍니다.

• 엔진 로직이 의심될 때: 내장 프로파일러로 시스템별 CPU 시간과 할당량을 먼저 봅니다.
• 간헐적인 멈춤이 있을 때: Tracy로 여러 초 동안 캡처하여 락 경합과 작업 대기를 추적합니다.
• 화면이 틀리거나 드로 콜이 많을 때: RenderDoc으로 문제 프레임의 패스와 리소스를 엽니다.
• GPU 시간이 예산을 넘을 때: Nsight Graphics로 셰이더와 파이프라인 병목을 좁힙니다.

팁: 프로파일러를 고르기 전에 “CPU가 느린가?”라고 묻지 말고 “어느 스레드가 누구를 기다리는가?”처럼 관측 가능한 질문을 적어보세요. 질문이 구체적이면 무료 도구도 값비싼 솔루션보다 빠르게 답합니다.

게임 기술이 발표되고 공유되는 대표적인 장으로 GDC의 배경과 의미를 살펴보면, 성능 최적화 역시 단일 비법보다 제작 현장에서 축적된 측정 방법과 사례가 중요하다는 점을 이해하기 쉽습니다. 발표 슬라이드의 최종 수치만 따라 하기보다 자신의 프레임 캡처로 같은 가설을 검증해야 합니다.

상황별 추천은 엔진보다 질문과 개발 단계가 결정합니다

프로토타입과 출시 직전에는 필요한 데이터가 달라집니다

기능이 계속 바뀌는 프로토타입 단계에서 정교한 계측 시스템부터 구축하면 유지 비용이 커집니다. 이때는 엔진 내장 프로파일러로 큰 비중을 차지하는 시스템을 찾고, 프레임 시간의 중앙값과 상위 구간을 기록하는 정도가 효율적입니다. 아직 삭제될 가능성이 높은 기능에 수십 개의 사용자 정의 마커를 심는 것은 투자 대비 효과가 낮습니다.

알파 단계에 들어가 콘텐츠와 플레이 흐름이 안정되면 Tracy를 함께 사용하는 편이 좋습니다. 로딩, 월드 스트리밍, AI 업데이트, 작업 시스템처럼 여러 스레드가 얽힌 구간에 의미 있는 존을 넣으면 평균 프레임만으로는 보이지 않던 대기 관계를 찾을 수 있습니다. 마커 이름은 함수명이 아니라 게임 시스템의 역할을 드러내도록 작성하는 것이 핵심입니다.

1. 프로토타입: 내장 프로파일러로 가장 큰 CPU·메모리 비용을 찾아 설계 수준의 낭비부터 제거합니다.
2. 알파 빌드: Tracy를 연결해 실제 플레이 세션의 스파이크와 스레드 간 대기를 수집합니다.
3. 그래픽 기능 확정 시점: RenderDoc으로 대표 장면을 캡처하고 불필요한 렌더 패스, 상태 변경, 중복 리소스를 확인합니다.
4. 최적화 집중 기간: Nsight Graphics를 사용해 GPU 이벤트별 시간과 셰이더 비용을 조사합니다.
5. 출시 후보 빌드: 최소 사양, 권장 사양, 고주사율 환경에서 같은 테스트 경로를 반복해 회귀 여부를 비교합니다.

증상에 따라 첫 번째 도구를 바꾸면 조사 시간이 짧아집니다

예를 들어 전투 중 0.2초씩 화면이 멈춘다면 RenderDoc을 먼저 실행할 이유가 크지 않습니다. 수십 초짜리 플레이 구간을 Tracy나 엔진 프로파일러로 기록해 메인 스레드 중단, 파일 입출력, 동적 할당, 락 대기를 찾는 것이 우선입니다. 반대로 프레임 시간은 안정적이지만 특정 이펙트에서 GPU 시간이 두 배가 된다면 CPU 타임라인을 오래 들여다볼수록 해결이 늦어집니다.

화면에 검은 재질이 나타나거나 후처리 결과가 플랫폼마다 달라지는 문제는 성능 수치보다 렌더링 상태를 재현하는 일이 먼저입니다. RenderDoc은 어떤 텍스처와 셰이더가 실제 드로 콜에 연결됐는지 확인하는 데 유리합니다. 그 뒤 GPU 시간이 기준을 넘는다고 확인되면 Nsight Graphics로 넘어가 웨이브 실행, 대역폭, 오버드로와 같은 하드웨어 관점의 원인을 좁힐 수 있습니다.

• CPU 평균 시간이 높다: 엔진 내장 도구로 시스템 비중을 확인한 뒤 Tracy로 세부 구간을 계측합니다.
• 드물게 큰 스파이크가 발생한다: 긴 캡처가 가능한 Tracy를 우선 사용하고 로딩과 락 이벤트를 함께 기록합니다.
• 드로 콜 결과가 예상과 다르다: RenderDoc에서 이벤트 목록, 입력 리소스, 렌더 타깃 순서로 추적합니다.
• GPU 사용률은 높은데 프레임이 늘지 않는다: CPU와 GPU 동기화 지점을 먼저 보고, Nsight에서 실제 유휴 구간을 확인합니다.
• 저사양 장치에서만 느리다: 개발 PC 캡처를 재사용하지 말고 문제가 발생한 등급의 하드웨어에서 다시 측정합니다.

도구 선택에도 일정과 인력이 필요합니다. 계측 코드를 넣고 캡처 파일을 보관하며 회귀 테스트를 운영하는 시간까지 비용으로 봐야 합니다. 기능별 목표와 예산을 연결하는 사고방식은 계획예산 제도의 개념처럼 목표와 투입 자원을 함께 판단하는 방식과 닮았습니다. 무료 소프트웨어라고 해서 도입 비용이 0원인 것은 아닙니다.

현장 조언: 팀에 그래픽스 전담 개발자가 없다면 네 도구를 동시에 정착시키려 하지 마세요. 내장 프로파일러와 RenderDoc부터 공통 절차를 만들고, 반복해서 해결하지 못하는 CPU 또는 GPU 문제가 생길 때 전문 도구를 추가하는 편이 안정적입니다.

캡처를 많이 모으고도 병목을 놓치는 세 가지 습관

평균값, 개발 PC, 계측 비용이 판단을 왜곡합니다

첫 번째 실수는 평균 FPS만 비교하는 것입니다. 60 FPS가 유지된다고 표시돼도 일정 간격으로 프레임 시간이 30ms를 넘으면 플레이어는 끊김을 느낍니다. 평균값과 함께 프레임 시간 분포, 상위 1% 지연 구간, 최악 프레임이 발생한 이벤트를 살펴야 합니다. 성능 목표도 ‘평균 60 FPS’보다 ‘대표 플레이 구간에서 대부분의 프레임이 정해진 예산 안에 들어온다’처럼 작성하는 편이 유용합니다.

두 번째 실수는 고성능 개발 PC에서 얻은 결과를 최소 사양의 결과로 간주하는 것입니다. CPU 코어 수, GPU 아키텍처, 메모리 대역폭과 드라이버가 달라지면 병목의 순서도 바뀝니다. 개발 PC에서는 CPU가 먼저 프레임을 제출하지만 저사양 장치에서는 GPU가 이전 프레임을 끝내지 못해 대기가 생길 수 있습니다. 따라서 같은 저장 데이터와 카메라 경로를 준비해 장치 등급별로 캡처해야 비교가 가능합니다.

세 번째 실수는 프로파일러 자체의 비용을 무시하는 것입니다. 지나치게 촘촘한 Tracy 존, 매 프레임 생성하는 문자열, 모든 리소스의 상세 추적은 실행 흐름을 바꿀 수 있습니다. 디버그 빌드에서만 나타나는 병목을 최종 제품의 성능 문제라고 오해하지 않도록 계측이 적은 기준 빌드와 상세 캡처 빌드를 분리하고, 두 빌드의 프레임 시간을 먼저 대조해야 합니다.

• 평균 FPS만 기록하지 말고 프레임 시간 그래프와 느린 프레임의 호출 구간을 함께 저장합니다.
• 에디터 실행 결과와 패키징된 게임 빌드의 결과를 섞지 않습니다.
• 수직 동기화나 프레임 제한이 켜진 상태에서 CPU·GPU 여유 시간을 성능 한계로 오판하지 않습니다.
• 빈 장면의 수치보다 실제 전투, 이동, 메뉴 전환, 저장과 로딩이 포함된 경로를 측정합니다.
• 최적화 전후에는 카메라, 캐릭터 수, 해상도, 그래픽 옵션을 동일하게 유지합니다.

한 번의 캡처보다 재현 가능한 측정 절차가 오래 남습니다

팀에서 바로 적용하려면 대표 장면 세 개를 정하는 것이 좋습니다. 예를 들어 탐색 장면, 적이 밀집한 전투 장면, 대량의 리소스를 불러오는 이동 장면을 마련하고 각 장면에서 30초 이상 동일한 입력을 재생합니다. 내장 프로파일러로 전체 시스템의 비중을 보고, 의심 구간은 Tracy로 확대하며, 렌더링 프레임은 RenderDoc과 Nsight Graphics로 나눠 조사하면 도구 사이의 결과를 연결할 수 있습니다.

캡처 파일 이름에도 빌드 번호, 장치, 해상도, 장면, 그래픽 옵션을 넣어야 합니다. ‘final_capture’처럼 맥락이 없는 이름은 며칠만 지나도 비교 자료로서 가치가 사라집니다. 수정한 코드와 예상 효과까지 짧게 기록하면 성능 회귀가 생겼을 때 어떤 선택이 비용을 되돌렸는지 추적하기 쉬워집니다.

1. 재현 가능한 저장 파일이나 입력 리플레이를 준비합니다.
2. 목표 장치에서 계측이 적은 기준 실행을 세 차례 기록합니다.
3. 가장 느린 구간에만 상세 마커나 GPU 캡처를 추가합니다.
4. 수정 전후의 중앙 프레임 시간과 느린 프레임 분포를 비교합니다.
5. 시각 품질이나 게임플레이 동작이 달라지지 않았는지 별도로 확인합니다.

가장 흔한 실패는 도구를 먼저 정하고 모든 문제를 그 도구의 화면에 맞춰 해석하는 것입니다. CPU 스파이크에 RenderDoc 캡처만 쌓거나, 잘못 연결된 텍스처를 CPU 함수 최적화로 해결하려 하면 수치는 많아져도 답은 멀어집니다. 또 한 번 빨라진 장면만 확인하고 다른 플랫폼과 플레이 구간을 재측정하지 않는 실수도 피해야 합니다.

도구 네 개를 모두 능숙하게 다루는 것보다 각 도구가 답하지 못하는 질문을 아는 개발자가 더 빠르게 병목을 찾습니다. 다음 캡처를 시작하기 전에는 먼저 ‘어느 장치의 어떤 장면에서, 어떤 프레임 예산이 초과됐는가’를 한 문장으로 적어보세요. 그 문장에 CPU, GPU, 리소스 상태 중 무엇이 필요한지 드러나면 첫 번째로 실행할 게임 프로파일러도 자연스럽게 결정됩니다.