최적화보다 계측, 게임 프로그래밍 병목을 먼저 본다

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

Q. 프레임이 흔들릴 때 왜 ‘느낌’부터 버려야 하나요?

A. 게임 프로그래밍에서 성능 문제는 대개 체감과 실제 원인이 다릅니다

프레임 드랍이 보이면 많은 개발자가 먼저 렌더링, 물리, AI 중 익숙한 영역을 의심합니다. 하지만 실제 병목은 게임 프로파일링 없이 맞히기 어렵습니다. 화면에 보이는 현상은 결과이고, CPU 스레드 대기, GPU 오버드로, 메모리 할당, 캐시 미스 같은 원인은 더 깊은 곳에 숨어 있기 때문입니다.

Will Perone 같은 developer 포트폴리오에서 배울 수 있는 태도도 여기에 가깝습니다. 게임 프로그래밍은 멋진 알고리즘을 쓰는 일만이 아니라, 수치로 시스템을 설명하는 일입니다. 특히 개인 프로젝트나 인디 게임에서는 팀원이 적어 추측이 곧 일정 손실로 이어집니다.

• 평균 FPS만 보면 순간적인 끊김을 놓치기 쉽습니다.
• 프레임 타임을 보면 어느 프레임이 왜 길어졌는지 추적할 수 있습니다.
• 호출 횟수를 보면 한 번의 무거운 함수보다 수천 번 반복되는 작은 비용을 발견할 수 있습니다.

전문가 조언: “최적화는 코드를 빠르게 만드는 작업이 아니라, 먼저 느린 곳을 틀리지 않게 찾는 작업입니다.”

인터뷰이인 성능 엔지니어는 “감으로 고친 최적화는 재현이 어렵고, 재현이 어려운 개선은 팀 자산이 되기 어렵다”고 말합니다. 독자가 지금 게임 루프 어딘가를 의심하고 있다면, 첫 질문은 ‘무엇을 고칠까’가 아니라 어디에서 시간이 사라지고 있는가여야 합니다.

Q. CPU 프로파일링과 GPU 프로파일링은 어떻게 다르게 봐야 하나요?

A. 같은 프레임 드랍이라도 책임지는 파이프라인이 다릅니다

CPU 프로파일링은 게임 로직, 스크립트, AI, 물리 업데이트, 리소스 로딩처럼 명령을 준비하는 쪽을 봅니다. 반면 GPU 프로파일링은 드로우콜, 셰이더, 텍스처 샘플링, 그림자, 후처리처럼 화면을 그리는 쪽을 봅니다. 둘을 섞어 보면 “렌더링이 느리다”는 말만 남고, 실제 행동으로 이어지지 않습니다.

예를 들어 카메라를 돌릴 때만 느려진다면 컬링, 오브젝트 정렬, 머티리얼 변경, 그림자 캐스팅이 후보가 됩니다. 적이 많이 등장할 때 느려진다면 AI 업데이트, 애니메이션 평가, 충돌 후보군 계산이 더 유력합니다. 이 구분이 있어야 game programming 문제를 엔진 탓으로 넘기지 않고 좁힐 수 있습니다.

• CPU 병목: 메인 스레드 점유율, 잡 시스템 대기, 동적 할당, 스크립트 호출 비용을 확인합니다.
• GPU 병목: 픽셀 비용, 버텍스 수, 오버드로, 렌더 패스 수, 셰이더 복잡도를 확인합니다.
• 동기화 병목: CPU가 GPU를 기다리거나 GPU가 CPU 제출을 기다리는 구간을 따로 봅니다.

관련 산업 행사에서 성능 사례가 공유되는 맥락을 알고 싶다면 GDC의 의미를 지식백과에서 확인해도 좋습니다. 이런 컨퍼런스 발표의 핵심은 화려한 기법보다 측정 가능한 문제 정의에 있는 경우가 많습니다.

Q. 수학 라이브러리도 프로파일링 대상인가요?

A. 벡터와 행렬 연산은 작아 보여도 프레임 전체를 움직입니다

게임 수학 라이브러리는 보통 “정확해야 하는 코드”로만 취급됩니다. 그러나 캐릭터 수, 투사체 수, 파티클 수, 충돌 후보가 늘어나면 math library의 작은 선택이 전체 프레임 타임에 영향을 줍니다. 정규화, 내적, 외적, 행렬 곱셈, 쿼터니언 변환이 매 프레임 수만 번 호출된다면 이야기가 달라집니다.

인터뷰이는 “수학 함수는 짧기 때문에 안전하다고 생각하기 쉽지만, 짧은 함수가 가장 자주 불릴 때도 많다”고 설명합니다. 예를 들어 길이 계산에서 매번 제곱근을 호출하는지, 단순 비교에는 제곱 길이를 쓰는지, 임시 객체가 과도하게 생기지는 않는지 살펴봐야 합니다. Will Perone의 사이트 키워드인 math와 game programming이 만나는 지점이 바로 여기입니다.

• 정확도: 좌표 변환이나 회전 누적에서 오차가 눈에 띄는지 확인합니다.
• 호출 비용: 자주 호출되는 함수가 불필요한 분기나 할당을 만드는지 봅니다.
• 데이터 배치: 벡터 배열이 캐시 친화적으로 순회되는지 측정합니다.
• 플랫폼 차이: PC에서 빠른 코드가 모바일이나 콘솔에서도 같은 성격인지 검증합니다.

전문가 조언: “수학 코드는 예쁘게 보이는 것보다 반복 호출에서 안정적으로 예측 가능한 것이 더 중요할 때가 많습니다.”

다만 모든 수학 함수를 손으로 최적화하라는 뜻은 아닙니다. 핵심은 프로파일러에서 상위에 뜨는 함수부터 확인하는 것입니다. 프로젝트 초반에는 가독성 좋은 구현을 유지하고, 실제 장면에서 병목으로 확인된 부분만 SIMD, 배치 처리, 근사 함수 같은 선택지를 검토하는 편이 현실적입니다.

Q. 기획 변경이 성능 예산을 무너뜨릴 때는 어떻게 대화하나요?

A. 개발자는 수치를 번역해 팀의 의사결정 언어로 바꿔야 합니다

게임 성능 문제는 코드만의 문제가 아닙니다. “한 화면에 적을 100마리 더 보여주자”, “스킬 이펙트를 더 화려하게 만들자”, “맵을 끊김 없이 열어두자” 같은 결정은 기획, 아트, 엔진 코드가 함께 만드는 결과입니다. 그래서 개발자는 단순히 안 된다고 말하기보다 프레임 예산이라는 언어로 대화해야 합니다.

예를 들어 60FPS 목표라면 한 프레임에 약 16.67ms를 쓸 수 있습니다. 여기서 게임 로직 4ms, 렌더 준비 3ms, GPU 7ms, 여유 2ms처럼 나누면 논의가 구체화됩니다. 새로운 기능이 3ms를 추가로 요구한다면, 무엇을 줄이거나 어느 플랫폼에서 품질 단계를 나눌지 함께 정할 수 있습니다.

• 기획 요청을 “가능/불가능”으로 답하지 말고 “예산 안에서 어떤 버전이 가능한가”로 바꿉니다.
• 프로파일링 캡처 화면과 숫자를 공유해 논의가 개인 취향으로 흐르지 않게 합니다.
• 플랫폼별 목표 FPS와 해상도를 먼저 합의해 성능 기준을 흔들리지 않게 만듭니다.

게임 제작에서 기획자의 역할을 더 넓게 이해하고 싶다면 기획자 직무 설명을 참고할 수 있습니다. 성능 대화는 개발자가 기획을 막는 과정이 아니라, 의도를 실제 플레이 경험으로 번역하는 과정에 가깝습니다.

인터뷰이는 특히 작은 팀일수록 “성능 예산표를 문서 한 장으로라도 남기라”고 권합니다. 문서가 있으면 나중에 기능이 늘어났을 때 왜 느려졌는지, 어느 지점에서 합의를 다시 해야 하는지 추적하기 쉬워집니다.

Q. 프로파일링 도구는 비싼 상용 툴부터 써야 하나요?

A. 프로젝트 규모보다 질문의 정밀도가 먼저입니다

상용 엔진을 쓴다면 Unity Profiler, Unreal Insights처럼 내장 도구부터 충분히 활용할 수 있습니다. 자체 엔진이나 C++ 중심 프로젝트라면 Tracy, RenderDoc, PIX, Xcode Instruments, Visual Studio Profiler 등 목적별 도구를 조합할 수 있습니다. 중요한 것은 도구의 가격이 아니라 “지금 알고 싶은 것이 CPU 시간인지, GPU 패스인지, 메모리인지”를 분명히 하는 일입니다.

비용 관점도 현실적으로 봐야 합니다. 무료 도구만으로도 병목의 70% 이상은 찾을 수 있는 경우가 많습니다. 다만 콘솔 플랫폼, 대규모 팀, 장기 라이브 서비스라면 자동 캡처, 회귀 추적, 빌드별 성능 리포트가 필요해지고 유료 솔루션이나 사내 대시보드의 가치가 커집니다.

1. 먼저 엔진 내장 프로파일러로 프레임 타임을 구간별로 나눕니다.
2. CPU와 GPU 중 어느 쪽이 더 긴지 확인합니다.
3. 가장 긴 구간의 호출 스택이나 렌더 패스를 캡처합니다.
4. 수정 후 같은 장면, 같은 카메라, 같은 입력 조건에서 다시 측정합니다.

예산을 배분하는 사고방식은 개발 도구 선택에도 그대로 적용됩니다. 공공 영역의 용어이긴 하지만, 계획예산 제도처럼 목표와 자원 배분을 연결해 생각하면 팀의 장비 투자도 더 설득력 있게 설명할 수 있습니다.

인터뷰이는 “좋은 툴을 사면 빨라지는 것이 아니라, 같은 질문을 반복해서 빠르게 확인할 수 있을 때 툴값이 회수된다”고 말합니다. 개인 개발자라면 무료 툴을 깊게 익히는 쪽이 먼저이고, 팀 프로젝트라면 캡처 공유와 리그레션 감시가 가능한 체계를 조금씩 붙이는 편이 좋습니다.

오늘 빌드에서 30분짜리 성능 캡처를 남기는 법

Q. 당장 무엇부터 하면 실력이 쌓이나요?

가장 좋은 시작은 거창한 최적화 계획이 아니라 오늘 빌드 하나를 기준점으로 남기는 것입니다. 플레이어가 실제로 오래 머무는 장면을 고르고, 30초에서 2분 정도 동일한 동선을 반복해 캡처하세요. 적이 많이 나오는 구간, UI가 많이 뜨는 구간, 카메라가 넓은 맵을 보는 구간처럼 부담이 큰 장면이면 더 좋습니다.

그다음 숫자를 짧게 기록합니다. 평균 FPS, 1% low FPS, 가장 긴 프레임, CPU 최상위 함수 3개, GPU에서 가장 긴 패스 3개만 적어도 충분합니다. 이 기록은 완벽한 문서가 아니라 다음 측정을 가능하게 하는 기준점입니다. 다음 빌드에서 같은 장면을 다시 찍으면 개선인지 착시인지 바로 구분할 수 있습니다.

• 장면 이름: 예를 들어 “숲 전투 3웨이브”처럼 재현 가능한 이름을 붙입니다.
• 측정 조건: 해상도, 품질 옵션, 빌드 타입, 플랫폼을 함께 적습니다.
• 상위 병목: 함수명이나 렌더 패스명을 그대로 남겨 검색 가능하게 합니다.
• 다음 행동: 가장 큰 항목 하나만 골라 원인 가설을 씁니다.

오늘 해볼 행동은 단순합니다. 지금 작업 중인 게임을 실행하고, 가장 느리다고 느낀 장면을 하나 고른 뒤 프로파일러 캡처 파일과 5줄 메모를 같은 폴더에 저장하세요. 파일명은 scene-build-platform-date처럼 정하면 충분합니다. 내일 코드를 고치기 전에 그 캡처를 다시 열어 “정말 가장 큰 비용이 무엇이었나”를 먼저 확인하면, 게임 프로그래밍 실력은 추측이 아니라 기록 위에서 자라기 시작합니다.