프레임 드롭을 잡아야 하는 게임 개발자라면 성능 예산부터

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

플레이 테스트에서는 부드럽던 게임이 전투만 시작하면 끊기고, 개발용 PC에서는 보이지 않던 문제가 저사양 기기에서 한꺼번에 드러납니다. 이런 상황이라면 무작정 코드를 최적화하기 전에 프레임 시간과 메모리 사용량에 한도를 배정하는 성능 예산부터 세워야 합니다.

성능 예산은 그래픽, 물리, 애니메이션, 인공지능, 오디오처럼 서로 다른 시스템이 제한된 자원을 나누어 쓰게 만드는 기준입니다. 다음 단계별 점검표를 따라가면 프로파일러의 수많은 숫자 중 무엇을 먼저 봐야 하는지, 최적화 작업을 어디에서 멈춰야 하는지 판단하기 쉬워집니다.

목표 프레임을 밀리초 예산으로 바꾼다

FPS보다 프레임 시간을 먼저 적기

60FPS를 목표로 한다는 문장만 적어 두면 구체적인 작업 기준이 되지 못합니다. 60FPS의 한 프레임은 약 16.67ms이며, 30FPS는 약 33.33ms, 120FPS는 약 8.33ms입니다. 렌더링과 게임 로직이 이 시간 안에 끝나야 하므로 평균 FPS가 아니라 한 프레임에 허용되는 시간을 출발점으로 삼아야 합니다.

여기서 주의할 점은 16.67ms 전체를 게임 코드에 배정할 수 없다는 사실입니다. 운영체제 스케줄링, 드라이버, 프레임 동기화, 예측하지 못한 부하를 위한 여유가 필요합니다. 예를 들어 60FPS 게임이라면 내부 작업 예산을 14~15ms 수준으로 잡고 나머지를 안전 구간으로 남기는 방식이 현실적입니다.

• 목표 플랫폼: PC, 콘솔, 모바일 중 실제 최저 사양을 명시합니다.
• 목표 프레임: 30·60·120FPS 중 플레이 경험에 필요한 값을 정합니다.
• 프레임 한도: 1000을 목표 FPS로 나누어 밀리초로 기록합니다.
• 여유 시간: 전체 프레임 시간의 약 10~15%를 돌발 부하용으로 남깁니다.
• 측정 구간: 메뉴가 아니라 전투, 이동, 이펙트가 겹치는 장면을 고릅니다.

실무 팁: 평균 60FPS보다 1% 최저 프레임과 프레임 시간 그래프가 안정적인지를 먼저 확인합니다. 평균값은 짧고 강한 끊김을 쉽게 숨깁니다.

CPU와 GPU 중 기다리는 쪽을 먼저 찾는다

병목을 추측하지 않는 첫 진단

화면이 복잡하다고 해서 항상 GPU가 원인은 아닙니다. 드로 콜 준비, 물리 충돌, 애니메이션 갱신, 경로 탐색이 메인 스레드를 오래 점유하면 GPU는 명령을 받지 못한 채 기다릴 수 있습니다. 반대로 CPU 시간이 충분해도 고해상도 후처리와 투명 오브젝트가 많다면 GPU 프레임 시간이 한도를 넘습니다.

간단한 분리 실험이 유용합니다. 렌더 해상도를 절반으로 낮췄을 때 프레임 시간이 크게 줄면 GPU 병목일 가능성이 높습니다. 변화가 거의 없다면 CPU 작업이나 프레임 제한, 동기화 대기를 살펴봐야 합니다. 단, 동적 해상도와 업스케일러가 자동으로 개입하지 않도록 동일한 옵션에서 비교해야 합니다.

1. CPU와 GPU의 프레임 시간을 같은 캡처에서 확인합니다.
2. 해상도만 낮추고 동일한 플레이 구간을 다시 측정합니다.
3. CPU라면 메인 스레드, 렌더 스레드, 작업 스레드의 대기 시간을 나눠 봅니다.
4. GPU라면 패스별 비용과 오버드로, 셰이더 복잡도, 메모리 대역폭을 확인합니다.
5. 가장 긴 단일 작업뿐 아니라 여러 번 반복되어 누적되는 작은 작업도 표시합니다.

개발 과정에서 성능 문제를 공유하고 다양한 구현 사례를 접하려면 GDC의 성격과 역할을 함께 살펴볼 만합니다. 다만 발표에서 소개된 수치를 그대로 목표로 삼기보다 자신의 장르, 카메라, 하드웨어 조건으로 재측정해야 합니다.

시스템별 성능 예산표를 플레이 장면에 연결한다

기능 목록이 아닌 비용 목록 만들기

병목을 찾았다면 프레임 예산을 시스템별로 나눕니다. 60FPS 액션 게임의 CPU 예산을 예로 들면 게임 로직 3ms, 물리 2ms, 애니메이션 2ms, 렌더 준비 3ms처럼 시작할 수 있습니다. 이 숫자는 정답이 아니라 팀이 기능의 대가를 협의하기 위한 기준선입니다.

특히 최악의 장면을 기준으로 작성해야 합니다. 평상시 적이 5명인데 보스전에서 졸개 40명이 등장한다면 AI와 애니메이션 예산은 보스전을 견뎌야 합니다. 모든 캐릭터를 매 프레임 같은 빈도로 갱신할 필요가 있는지, 화면 밖 객체의 업데이트를 줄일 수 있는지도 이 단계에서 결정합니다.

• 각 예산에는 담당 시스템과 측정 도구를 지정합니다.
• 평균값과 함께 95·99백분위 프레임 시간을 보관합니다.
• 적 수, 파티클 수, 가시 거리처럼 장면 조건을 숫자로 기록합니다.
• 초과를 허용할 수 있는 시간과 반드시 수정할 기준을 구분합니다.

기획 단계에서 기능의 우선순위를 비용과 함께 관리하는 관점은 계획과 예산을 연결하는 개념과도 닮아 있습니다. 화려한 기능을 먼저 넣고 마지막에 줄이는 것보다, 필요한 플레이 가치에 자원을 배정하는 편이 수정 비용을 낮춥니다.

프로파일링 캡처의 조건을 고정해 숫자를 믿을 수 있게 한다

재현 가능한 테스트 장면 준비

프로파일러를 한 번 실행해 가장 큰 막대를 고르는 방식은 위험합니다. 에디터 자체의 오버헤드, 디버그 빌드, 백그라운드 프로그램, 셰이더 컴파일이 결과를 왜곡할 수 있기 때문입니다. 실제 배포 설정에 가까운 빌드와 목표 하드웨어에서 같은 입력을 반복해야 전후 비교가 가능합니다.

수동 플레이는 매번 카메라와 전투 진행이 달라집니다. 가능하다면 리플레이 입력, 고정된 카메라 경로, 자동 전투 시나리오를 만들어 측정 구간을 재생하세요. 워밍업 구간을 먼저 실행해 셰이더와 리소스 로딩을 끝낸 뒤 안정 구간과 최초 실행 구간을 별도로 캡처하면 원인을 훨씬 정확하게 구분할 수 있습니다.

1. 목표 기기의 전원 모드와 발열 상태를 기록합니다.
2. 릴리스 또는 프로파일링 전용 빌드를 사용합니다.
3. 동일한 세이브 데이터와 난수 시드, 그래픽 옵션을 적용합니다.
4. 30초 이상 같은 장면을 반복하고 중앙값과 긴 프레임을 함께 수집합니다.
5. 캡처 파일 이름에 빌드 번호, 기기, 장면, 옵션을 남깁니다.
6. 수정 전후 캡처를 같은 화면 축척으로 나란히 비교합니다.

한 번의 빠른 결과보다 다른 개발자가 같은 조건에서 재현할 수 있는 결과가 가치 있습니다. 캡처 조건을 문서화하지 않으면 개선 수치도 쉽게 논쟁거리가 됩니다.

또한 프로파일러 자체가 만드는 부하를 확인해야 합니다. 모든 이벤트와 메모리 할당 스택을 동시에 기록하면 원래 없던 병목이 생길 수 있으므로, 첫 캡처에서는 넓게 보고 두 번째 캡처에서 의심 구간만 상세 추적하는 방식이 효율적입니다.

메모리와 로딩 피크를 프레임 성능과 함께 점검한다

평균 사용량보다 순간 최고치를 보기

메모리는 애플리케이션이 종료되지 않으면 괜찮다고 생각하기 쉽지만, 부족한 메모리는 프레임 드롭으로 먼저 나타나기도 합니다. 반복적인 동적 할당과 가비지 컬렉션, 텍스처 스트리밍 실패, 압축 리소스 해제 지연은 CPU와 저장장치 대기를 동시에 만들 수 있습니다. 따라서 프레임 시간과 메모리 그래프의 상승 시점을 같은 타임라인에서 비교해야 합니다.

가격이 높은 프로파일링 솔루션을 도입하기 전에 엔진 내장 도구와 플랫폼 제조사의 무료 도구로 필요한 항목을 확인할 수 있는지 점검하세요. 유료 도구는 팀 단위 캡처 공유, 장시간 추적, 자동 회귀 탐지에 강점이 있지만, 측정 절차가 정해지지 않은 팀에서는 기능을 충분히 활용하기 어렵습니다.

• 상주 메모리: 로비, 일반 전투, 보스전에서 각각 기준선을 측정합니다.
• 로딩 피크: 새 에셋을 읽는 동안 기존 에셋과 중복 상주하는지 확인합니다.
• 할당 빈도: 매 프레임 생성되는 임시 배열, 문자열, 이벤트 객체를 찾습니다.
• 스트리밍: 이동 속도보다 에셋 공급이 느려지는 구간을 재현합니다.
• 누수 검사: 장면을 여러 차례 왕복한 뒤 기준 메모리로 돌아오는지 봅니다.

예를 들어 캐릭터 선택 화면을 열고 닫을 때마다 메모리가 20MB씩 증가한다면 한 번의 캡처로는 알아채기 어렵습니다. 같은 행동을 10회 반복한 뒤 스냅샷을 비교하고, 객체 수와 실제 바이트 증가를 함께 보세요. 객체가 해제됐어도 메모리 풀이 유지되는 정상 상황이 있으므로 증가했다는 사실만으로 누수라고 단정하지 않는 것도 중요합니다.

출시 후보 빌드에서는 플레이 가치 순으로 예산을 지킨다

수정 우선순위를 다시 세우는 기준

출시가 가까워질수록 모든 초과 항목을 완벽하게 고칠 수는 없습니다. 이때는 가장 느린 함수가 아니라 사용자에게 자주 노출되고 플레이를 방해하는 문제부터 선택해야 합니다. 튜토리얼에서 반복되는 80ms 끊김은 숨겨진 장소의 20ms 초과보다 우선순위가 높습니다.

기능을 삭제하기 전에 품질 단계와 갱신 빈도를 조절할 수 있는지 확인하세요. 먼 거리 애니메이션을 절반 빈도로 평가하고, 중요하지 않은 AI의 사고 주기를 늘리며, 그림자 캐스팅 조명을 줄이는 방식은 핵심 플레이를 보존하면서 비용을 낮춥니다. 게임 기획자의 역할과 협업 범위를 이해하려면 게임 기획자 관련 설명도 참고할 수 있습니다. 성능 예산은 개발자 혼자 지키는 숫자가 아니라 기획 의도와 기술 비용을 조정하는 공용 언어이기 때문입니다.

1. 첫째, 크래시와 메모리 한도 초과: 진행 불가 가능성이 있으므로 가장 먼저 처리합니다.
2. 둘째, 입력과 전투를 깨뜨리는 긴 프레임: 평균값보다 체감 피해가 큰 스파이크를 줄입니다.
3. 셋째, 자주 방문하는 장면의 지속 병목: 해상도와 객체 수를 바꿔 CPU·GPU 원인을 분리합니다.
4. 넷째, 특정 옵션과 기기에서만 발생하는 초과: 품질 단계나 기능 대체 경로를 제공합니다.
5. 다섯째, 수치에는 잡히지만 체감하기 어려운 미세 개선: 회귀 테스트를 남기고 이후 작업으로 배치합니다.

마지막 승인 전에는 최저 사양 기기, 대표 장면, 목표 프레임 시간, 메모리 최고치, 허용 가능한 긴 프레임 횟수를 한 장의 기준표에 적으세요. 그다음 안정성, 입력 반응, 반복 노출 빈도, 시각 품질, 개발 비용 순서로 판단하면 무엇을 유지하고 무엇을 낮출지 흔들리지 않습니다.