이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
저는 광선 추적(Ray Tracing) 이론을 가장 중요하게 생각합니다. 학부 그래픽스 수업에서 소프트웨어 렌더러를 직접 만들었는데, 처음에는 래스터라이제이션 방식으로 구현했습니다. 결과물이 나오긴 했지만 그림자와 반사 처리에서 한계가 명확했고, 광선 추적으로 전환하면서 빛의 물리적 동작을 코드로 표현하는 방식을 익혔습니다.
반사(reflection)와 굴절(refraction)을 재귀적으로 처리하는 로직에서 스택 오버플로가 나서 깊이 제한을 걸었고, 그 과정에서 이론과 구현 사이의 간격을 처음 체감했습니다. 실시간 렌더링이 중요한 게임 엔진에서는 PBR(물리 기반 렌더링)이 더 실용적이라는 것도 비교하며 배웠습니다. 지금도 새로운 렌더링 기법을 볼 때는 빛의 어떤 특성을 어떤 방식으로 근사하는지 먼저 확인하는 편입니다.
3D 렌더링 개발에서 광선 추적 구현 시 오브젝트 수가 늘어날수록 교차 테스트 비용이 급증하는 문제를 경험했습니다. 씬에 오브젝트가 100개를 넘어가면서 렌더링 시간이 선형으로 늘어났는데, 모든 오브젝트에 대해 광선 교차를 테스트하는 방식이 원인이었습니다.
`BVH(Bounding Volume Hierarchy)` — 오브젝트를 공간적으로 계층화해 교차 가능성이 없는 오브젝트를 조기에 걸러내는 구조 — 를 구현해서 테스트 수를 줄였습니다. BVH 트리를 씬 로드 시점에 한 번 빌드하고 광선마다 루트부터 탐색하는 방식으로 바꾸니 같은 씬에서 렌더링 시간이 크게 단축됐습니다.
LOD(레벨 오브 디테일) — 원거리 오브젝트에 더 단순한 메시를 쓰는 방식 — 도 함께 적용하면 드로우 비용도 줄일 수 있다는 것을 이후 학습했습니다. 그래픽 이론은 성능 문제 앞에서 왜 중요한지가 보입니다.
3D 렌더링에서 PBR이 왜 업계 표준이 됐는지를 직접 구현하면서 이해했습니다. 금속성(metallic)과 거칠기(roughness) 두 파라미터만으로 금속과 비금속, 매끄러운 면과 거친 면의 빛 반응을 다르게 표현할 수 있는 것이 이론의 핵심이었습니다.
알베도·metallic·roughness 파라미터를 텍스처 맵으로 받아 BRDF 함수로 빛 상호작용을 계산하는 셰이더를 직접 작성해봤는데, 이론의 물리적 근거가 코드에서 어떻게 표현되는지를 이해하는 시간이었습니다. 래스터화 파이프라인 — 정점 처리→래스터화→픽셀 셰이딩 — 의 각 단계에서 무엇이 일어나는지를 이해하지 못하면 PBR 셰이더를 올바르게 작성하기 어렵다는 것을 배웠습니다.
draw call 수가 많아지면 CPU-GPU 통신 비용이 증가한다는 것도 실시간 렌더링에서 셰이더 최적화만큼 중요하다는 것을 이후 알게 됐습니다. 그래픽 이론은 코드로 구현할 때 진짜로 배웁니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 네이버랩스 게임 개발 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.