게임 프로그래밍 프로파일링 도구 사용 후기 가이드

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

프레임 드랍을 눈으로만 잡으려 했던 첫 실패

느낌이 아니라 숫자로 보기 시작한 순간

게임 프로그래밍을 하다 보면 가장 답답한 순간은 코드가 분명히 맞는 것 같은데 화면이 끊기는 때입니다. 저도 처음에는 프레임 드랍을 애니메이션, 렌더링 옵션, 물리 업데이트 순서 문제로만 의심했습니다. 그런데 실제로 프로파일링 도구를 켜 보니 병목은 예상과 달리 매 프레임 반복되던 작은 메모리 할당과 로그 출력에 있었습니다.

Will Perone 같은 개발자 포트폴리오나 개인 기술 프로젝트를 운영한다면, 결과물만 보여주는 것보다 어떤 문제를 어떻게 측정하고 개선했는지를 함께 보여주는 편이 훨씬 설득력 있습니다. 특히 game programming 포트폴리오에서는 “최적화했습니다”라는 문장보다 “CPU 12ms 구간을 7ms로 줄였습니다”라는 기록이 더 강합니다.

• 체감 기준: 플레이 중 끊김, 입력 지연, 카메라 흔들림을 먼저 기록합니다.
• 측정 기준: CPU, GPU, 메모리, GC, 드로우콜을 각각 분리해서 봅니다.
• 비교 기준: 수정 전후 프레임 타임을 같은 장면에서 반복 측정합니다.

팁: 처음부터 모든 도구를 켜지 말고, 한 장면과 한 문제만 정해 측정하세요. 프로파일링은 많이 보는 일이 아니라 정확히 비교하는 일에 가깝습니다.

제가 가장 먼저 확인한 지표

처음에는 평균 FPS만 봤지만, 실제 사용 후 가장 유용했던 지표는 프레임 타임이었습니다. 60FPS라면 한 프레임은 약 16.67ms 안에 끝나야 합니다. 평균 FPS가 괜찮아도 특정 순간 35ms, 50ms로 튀면 플레이어는 바로 끊김을 느낍니다.

1. 테스트 장면을 하나 고정합니다. 예를 들어 적 30마리, 투사체 100개, 이펙트 10개처럼 조건을 정합니다.
2. 프로파일러로 CPU와 GPU 중 어느 쪽이 먼저 막히는지 확인합니다.
3. 수정 후 같은 입력, 같은 카메라 위치, 같은 오브젝트 수로 다시 측정합니다.

Unity Profiler를 써보며 얻은 실제 장단점

빠르게 원인을 좁히기 좋은 도구

Unity 기반 프로젝트에서 가장 자주 쓴 도구는 Unity Profiler였습니다. 별도 설치 부담이 적고, CPU Usage, Rendering, Memory, Timeline을 한 번에 볼 수 있어서 게임 프로그래밍 입문자부터 포트폴리오 제작자까지 접근성이 좋습니다. 개인적으로는 Timeline 뷰가 가장 도움이 됐습니다. 어떤 함수가 어느 순서로 실행되는지 보이기 때문에 감으로 추적하던 시간을 줄여 줍니다.

장점은 명확합니다. 에디터 안에서 바로 실행할 수 있고, 특정 함수가 과하게 호출되는지 확인하기 쉽습니다. 단점도 있습니다. 에디터에서 측정한 값은 실제 빌드와 다를 수 있고, Deep Profile을 켜면 측정 자체가 무거워져 결과가 왜곡될 수 있습니다. 그래서 저는 에디터 측정은 원인 탐색용, 개발 빌드 측정은 최종 확인용으로 나눠 사용했습니다.

• 좋았던 점: 스크립트 병목, GC Alloc, 렌더링 비용을 빠르게 찾을 수 있습니다.
• 아쉬운 점: Deep Profile은 느려지기 쉬워 장시간 켜두기 어렵습니다.
• 추천 사용법: 먼저 일반 Profiler로 큰 병목을 찾고, 필요한 함수만 샘플링합니다.

실제로 효과가 컸던 수정 사례

제가 만든 작은 액션 프로토타입에서는 적 AI가 매 프레임 모든 타깃 후보를 탐색하고 있었습니다. 오브젝트 수가 적을 때는 문제가 없었지만, 화면에 적이 40마리 이상 나오자 CPU 시간이 급격히 증가했습니다. Profiler에서 Update 구간을 확인하니 AI 탐색 함수가 반복 호출되고 있었고, 이 부분을 0.2초 간격 갱신으로 바꾸자 체감 끊김이 줄었습니다.

또 하나는 문자열 처리였습니다. 디버그 텍스트를 매 프레임 조합하면서 GC Alloc이 꾸준히 발생했습니다. 화면에는 아무 변화가 없어 보였지만 메모리 그래프가 주기적으로 튀었고, 나중에는 짧은 멈춤으로 이어졌습니다. 텍스트 갱신 주기를 낮추고 StringBuilder를 제한적으로 사용하자 안정성이 좋아졌습니다.

1. 매 프레임 실행되는 코드를 먼저 의심합니다.
2. 리스트 생성, 문자열 합치기, LINQ 사용처럼 할당이 생길 수 있는 코드를 확인합니다.
3. AI, 충돌 검사, UI 갱신은 매 프레임이 꼭 필요한지 다시 묻습니다.

GPU 병목은 RenderDoc과 프레임 디버거가 더 잘 보였다

렌더링 문제는 코드만 봐서는 부족했습니다

게임 수학이나 gameplay 코드를 오래 만지다 보면 병목도 당연히 CPU 쪽일 것이라고 생각하기 쉽습니다. 하지만 실제 프로젝트에서는 GPU가 막히는 경우도 많았습니다. 특히 포스트 프로세싱, 그림자, 투명 오브젝트, 과한 파티클이 겹치면 스크립트 최적화를 아무리 해도 프레임이 좋아지지 않았습니다.

이때 도움이 된 것이 프레임 디버거와 RenderDoc입니다. Unity Frame Debugger는 드로우콜 흐름을 빠르게 확인하기 좋고, RenderDoc은 한 프레임을 깊게 뜯어보기에 좋았습니다. 처음에는 인터페이스가 낯설었지만, 특정 패스에서 비용이 몰리는지 보는 데 익숙해지면 렌더링 최적화의 방향이 훨씬 선명해집니다.

• Frame Debugger: 어떤 순서로 렌더링되는지 확인하기 좋습니다.
• RenderDoc: 텍스처, 셰이더, 렌더 타깃 상태를 깊게 분석하기 좋습니다.
• 실전 기준: 투명 오브젝트, 그림자, 후처리 효과를 켜고 끄며 비교합니다.

렌더링 최적화는 “예쁘게 보이느냐”와 “얼마나 자주 그리느냐”를 함께 봐야 합니다. 같은 비주얼이라도 패스 수와 오버드로우가 다르면 성능 차이는 크게 벌어집니다.

제가 체감한 GPU 최적화 우선순위

가장 먼저 본 것은 그림자였습니다. 캐릭터와 오브젝트가 많아질수록 실시간 그림자 비용이 커졌고, 낮은 사양 노트북에서는 바로 티가 났습니다. 모든 오브젝트에 같은 품질의 그림자를 주는 대신, 플레이어와 가까운 핵심 오브젝트만 선명하게 유지하고 배경 오브젝트는 그림자 품질을 낮췄습니다.

그다음은 파티클과 투명 머티리얼이었습니다. 겉보기에는 작은 이펙트였지만 화면을 넓게 덮는 투명 파티클은 오버드로우를 크게 만들었습니다. 이 부분은 수학적으로도 재미있습니다. 벡터, 카메라 방향, 거리 기반 페이드 같은 math 처리를 활용하면 시각 품질을 유지하면서도 낭비되는 렌더링을 줄일 수 있습니다.

1. 그림자 해상도와 거리 설정을 먼저 낮춰 비교합니다.
2. 투명 이펙트가 화면을 과하게 덮는지 확인합니다.
3. 후처리 효과는 개별로 끄고 켜며 비용을 분리합니다.
4. LOD와 배칭 설정이 실제 장면에서 작동하는지 확인합니다.

프로파일링 결과를 포트폴리오로 보여주는 방법

숫자와 맥락이 함께 있어야 설득력이 생깁니다

개발자 포트폴리오에서 성능 개선 사례를 보여줄 때 가장 흔한 실수는 결과 숫자만 쓰는 것입니다. “FPS 40에서 60으로 개선”이라고만 적으면 좋아 보이지만, 어떤 장면에서, 어떤 기기에서, 어떤 방식으로 측정했는지 빠져 있으면 신뢰도가 낮아집니다. Will Perone 사이트처럼 game programming, math libraries, tech projects를 다루는 개인 사이트라면 기술적 맥락을 짧게 붙이는 것이 좋습니다.

저는 포트폴리오 문서에 문제, 측정, 수정, 결과를 한 묶음으로 적는 방식을 추천합니다. 예를 들어 “적 50마리 전투 장면에서 CPU 프레임 타임이 22ms까지 상승했고, 타깃 탐색 주기 조정과 캐싱으로 13ms 수준까지 낮췄습니다”처럼 쓰면 읽는 사람이 바로 상황을 이해합니다. 이 방식은 채용 담당자뿐 아니라 동료 개발자에게도 훨씬 친절합니다.

• 문제: 어떤 장면에서 성능 저하가 발생했는지 적습니다.
• 측정: 사용한 도구와 기준값을 함께 적습니다.
• 수정: 바꾼 코드 구조나 렌더링 설정을 설명합니다.
• 결과: 프레임 타임, 메모리 사용량, 드로우콜 변화를 수치로 남깁니다.

기술 블로그 글감으로 확장하기

프로파일링 기록은 블로그 콘텐츠로도 좋습니다. 단순한 개발 일지보다 검색 유입에 유리하고, game programming profiling, 게임 최적화, 게임 개발 포트폴리오 같은 키워드를 자연스럽게 포함할 수 있습니다. 국제 게임 개발 흐름을 참고하고 싶다면 GDC 관련 용어 설명처럼 공신력 있는 자료를 함께 인용하는 것도 좋습니다.

제 경험상 가장 반응이 좋았던 글은 “최적화 팁 10가지”보다 실제 문제 하나를 끝까지 추적한 글이었습니다. 독자는 완성된 정답보다 판단 과정을 보고 싶어 합니다. 왜 이 도구를 썼는지, 처음 가설이 왜 틀렸는지, 마지막에 무엇을 포기했는지까지 적으면 글의 밀도가 달라집니다.

1. 스크린샷 대신 측정 표를 넣어도 충분히 설득력 있습니다.
2. 함수 이름과 수치는 공개 가능한 범위에서 구체적으로 씁니다.
3. 실패한 가설도 짧게 남기면 글이 더 현실적으로 보입니다.

제가 쓰는 프로파일링 체크리스트

처음 30분 안에 확인하는 항목

프로파일링을 시작할 때 모든 문제를 한 번에 해결하려고 하면 금방 지칩니다. 그래서 저는 첫 30분 동안 확인할 항목을 정해 둡니다. 이 체크리스트는 개인 프로젝트, 게임잼 결과물, 포트폴리오용 데모 모두에 잘 맞았습니다. 중요한 것은 측정 범위를 작게 유지하는 것입니다.

특히 개발 장비가 좋을수록 문제를 놓치기 쉽습니다. 고성능 데스크톱에서는 멀쩡하던 프로젝트가 노트북이나 내장 그래픽 환경에서 크게 흔들릴 수 있습니다. 실제 유저 환경을 가정해 해상도, 품질 옵션, 빌드 타입을 바꿔 보는 과정이 필요합니다.

• CPU: Update, FixedUpdate, AI, 경로 탐색, 이벤트 호출 비용을 확인합니다.
• GPU: 그림자, 포스트 프로세싱, 투명 오브젝트, 파티클 비용을 봅니다.
• Memory: 반복 할당, 텍스처 크기, 오디오 로딩 방식을 점검합니다.
• Build: 에디터와 실제 빌드 결과를 분리해서 기록합니다.
• Input: 프레임은 괜찮아도 입력 반응이 늦는지 직접 플레이합니다.

상황별 추천 도구 비교

아래 표는 제가 실제로 사용하면서 정리한 기준입니다. 정답이라기보다 시작점을 잡기 위한 비교표에 가깝습니다. 프로젝트가 작을수록 내장 도구만으로 충분하고, 렌더링 문제가 복잡해질수록 전문 도구가 필요해졌습니다.

도구 선택보다 더 중요한 것은 같은 조건에서 반복 측정하는 습관입니다. 오늘은 에디터에서 측정하고 내일은 빌드에서 측정하면 비교가 흐려집니다. 저는 프로젝트 폴더 안에 profiling-notes 같은 문서를 두고, 날짜와 장면, 기기, 수정 내용을 짧게 남겼습니다.

자주 묻는 질문과 현장에서 배운 팁

초보자는 어떤 도구부터 써야 할까요?

처음이라면 엔진에 포함된 기본 프로파일러부터 쓰는 편이 좋습니다. Unity라면 Unity Profiler, Unreal이라면 Insights 계열 도구처럼 프로젝트와 바로 연결되는 도구가 학습 비용이 낮습니다. RenderDoc 같은 도구는 강력하지만, 렌더링 파이프라인에 익숙하지 않다면 처음부터 모든 메뉴를 이해하려고 하기보다 한 프레임 캡처와 텍스처 확인 정도부터 시작하는 것이 현실적입니다.

수학 라이브러리나 자체 엔진을 만드는 경우에는 더 단순한 계측도 충분히 의미가 있습니다. 함수 실행 시간을 로그로 남기고, 프레임별 평균과 최댓값을 기록하는 작은 도구만 있어도 병목을 찾을 수 있습니다. 중요한 것은 측정 가능한 구조를 코드에 남기는 것입니다.

• 처음에는 평균 FPS보다 프레임 타임 그래프를 봅니다.
• 최적화 전에는 반드시 기준 장면을 저장합니다.
• 성능 개선 후에는 코드 가독성이 지나치게 나빠지지 않았는지 확인합니다.

최적화는 언제 시작하는 게 좋을까요?

너무 이른 최적화는 개발 속도를 늦출 수 있지만, 너무 늦은 측정은 구조를 크게 뜯어고치게 만듭니다. 제 기준은 간단합니다. 핵심 시스템이 돌아가기 시작하면 가벼운 측정을 붙이고, 콘텐츠가 늘어나는 시점부터 정기적으로 프로파일링합니다. 예를 들어 전투, 이동, 카메라, UI가 연결된 뒤에는 매주 한 번 정도 같은 장면을 측정해 보는 식입니다.

기획과 개발이 맞물린 팀 프로젝트라면 성능 예산을 미리 정해 두는 것도 도움이 됩니다. 예산이라는 개념이 낯설다면 계획예산 제도의 기본 설명처럼 제한된 자원을 목적에 맞게 배분한다는 관점으로 이해할 수 있습니다. 게임 개발에서는 CPU 시간, GPU 시간, 메모리, 빌드 용량이 모두 예산이 됩니다.

1. 프로토타입 단계에서는 큰 병목만 확인합니다.
2. 알파 단계에서는 반복 측정 기준을 만듭니다.
3. 베타 단계에서는 타깃 기기에서 안정성을 검증합니다.
4. 포트폴리오 공개 전에는 개선 수치를 문서로 정리합니다.

실제로 써보니 프로파일링은 고급 개발자만의 영역이 아니었습니다. 오히려 작은 프로젝트일수록 빨리 익혀 두면 좋습니다. 프레임 타임을 읽고, 병목을 가설로 세우고, 수정 후 다시 비교하는 습관은 game programming 실력을 가장 빠르게 드러내는 방법 중 하나였습니다.