이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 프로젝트로 모바일 게임 UI 렌더링 코드를 분석하고 최적화하는 작업을 맡았습니다. 우선 RenderDoc으로 드로우콜 캡처해 불필요한 상태 전환과 오버드로 구간을 파악했습니다. 분석 결과 동일 텍스처를 매 프레임 새로 바인딩하는 부분이 CPU 병목의 40% 이상을 차지하고 있었습니다.
텍스처 아틀라스로 통합하고 스테이트 변경 횟수를 줄이자 GPU 프레임 타임이 8ms에서 5ms로 줄었습니다. 코드 변경 전후 비교는 profiling 로그를 CSV로 저장해 팀 리뷰에서 수치로 공유했고, 리뷰어가 '왜 이 순서로 변경했는지' 이해할 수 있도록 커밋 메시지에 이유를 남겼습니다. 작업하며 프로파일링 없이 감으로 최적화하면 방향이 틀릴 수 있다는 걸 실감했습니다.
그래픽 코드 최적화 초반에는 GPU 병목만 집중해서 봤는데, 프레임 타임이 개선되지 않는 구간에서 CPU 타임라인을 열어보니 다른 원인이 있었습니다. 렌더링 커맨드를 생성하는 CPU 측 로직에서 매 프레임 오브젝트 리스트를 순회하며 불필요한 가시성 판정을 반복하는 부분이 CPU 스레드를 묶고 있었습니다. GPU가 기다리는 원인이 GPU 자체가 아니라 CPU에서 커맨드를 늦게 제출하는 것이었습니다.
렌더링 병목은 GPU에 있다고 가정하고 시작하면 원인을 놓칩니다. CPU·GPU 타임라인을 동시에 열고 어느 쪽이 기다리는지를 먼저 파악하는 것이 분석의 시작점이어야 합니다. 가시성 판정 캐싱으로 CPU 부담을 줄이자 GPU 커맨드 제출이 빨라졌고, 프레임 타임이 추가로 개선됐습니다.
가정 없이 데이터를 먼저 보는 것이 최적화에서 가장 중요한 습관입니다.
그래픽 최적화에서 가장 까다로웠던 점은 로컬 개발 환경에서 측정한 개선 수치가 다른 기기에서 동일하게 재현되지 않는 경우였습니다. GPU 아키텍처가 기기마다 달라서 텍스처 아틀라스 통합이 한 기기에서는 효과적이었는데, 타일 기반 렌더러를 쓰는 기기에서는 오히려 드로우콜 배치보다 메모리 대역폭이 병목이 되는 경우가 있었습니다.
최적화는 특정 타겟 기기를 기준으로 측정하고 판단해야 일반화 오류를 줄일 수 있습니다. 이후에는 기기 스펙을 먼저 분류하고, 프로파일링 대상 기기 범위를 팀과 합의한 뒤 작업을 시작했습니다. 결과가 환경에 따라 다른 것을 예상하고 기기 다양성을 전제로 접근하는 것이 그래픽 최적화의 어려움이자 핵심입니다. 그 경험이 성능 측정 기준을 처음부터 명확하게 정하는 습관을 만들어줬습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 네이버 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.