그래픽스 프로그래머가 되려면 무엇을 배워야 하는가

• 실시간 그래픽스 채용 역량은 CPU 측 명시적 그래픽스 API와 GPU 측 조명·셰이딩을 함께 요구하며, 두 영역을 동시에 깊게 익히기는 어려움
• CPU 측은 DirectX12, Vulkan, Metal 같은 현대적 API와 애셋 로딩·엔진 지원 작업을 다루고, GPU 측은 그림자, 앰비언트 오클루전, 후처리, GPU 성능 특성을 다룸
• GPU 학습의 중심은 path tracer 작성과 PBR 이해이며, Ray Tracing in One Weekend, LearnOpenGL PBR, Filament 문서, PBRT가 출발점이 될 수 있음
• 포트폴리오는 C++ 기반 실시간 렌더러, 사진 같은 이미지를 만드는 path tracer, 두 렌더링 결과를 비교·검증하는 코드로 지식을 보여주는 방식이 이상적임
• 필요한 수학은 선형대수, 기본 삼각법, 약간의 미적분이 중심이고, 게임 개발의 CPU 측 언어는 C++, 셰이더 언어는 HLSL이 가장 흔함

실시간 그래픽스는 CPU와 GPU 두 영역을 함께 다룸

• 현대 렌더링은 사실상 두 가지 일을 합친 형태에 가까움
  • CPU 측 학습: DirectX12, Vulkan, Metal 같은 현대적 명시적 API와 애셋 로딩, 기타 지원 작업을 위한 엔진 프로그래밍
  • GPU 측 학습: 현대적 조명·셰이딩 수학, 그림자, 앰비언트 오클루전, 후처리 효과, GPU에서 빠른 작업과 느린 작업의 차이
• 두 영역을 동시에 배우기는 매우 어려움
  • GPU 측에 집중하려면 OpenGL, WebGL, DirectX11, 기존 엔진처럼 CPU 측 부담이 낮은 도구를 사용할 수 있음
  • CPU 측에 집중하려면 먼저 화면에 삼각형을 띄우고, 다음에는 메시를 띄우는 식으로 진행하되 결과물이 예쁜지에는 크게 신경 쓰지 않아도 됨

path tracing과 PBR

• GPU 측 학습에는 path tracer 작성이 포함됨
  • Path tracing은 영화 렌더링에 쓰이는 방식이며, 현대 실시간 렌더링 기법이 근사하려는 대상임
  • 시작 자료로 무료 온라인 책 Ray Tracing in One Weekend가 적합하며, 접근하기 쉽고 사진 같은 렌더링을 만드는 과정을 보여줌
• Physically Based Rendering(PBR) 은 조명, 특히 specular 적용 방식에 해당함
  • PBR은 규칙을 지키면 좋은 결과를 얻는 원칙 기반 방식임
  • PBR 이전에는 조명을 위해 임의의 수식, 조정, 해킹을 많이 사용했기 때문에 한 조명 환경에서 좋아 보이던 애셋이 다른 환경에서는 너무 어둡거나 빛나는 것처럼 보일 수 있었음
  • 그 결과 조명 조건별로 다른 애셋 버전을 만들어야 했고, 시간과 노력이 많이 들었음
• PBR은 여러 조명 조건에서 애셋이 더 일관되게 보이도록 만들고, 버전별 애셋 제작에 드는 시간과 노력을 줄임
  • 그래도 애셋 제작 시간, 비용, 노력은 여전히 게임 개발의 큰 병목임

추천 학습 자료

• PBR 입문에는 LearnOpenGL의 PBR Theory 섹션과 하위 섹션이 적합함
• 더 깊게 들어가려면 Filament documentation이 다음 단계가 될 수 있음
  • PBR을 깊이 배울수록 미적분과 통계가 많이 등장함
• 더 나아가면 무료 온라인 책 Physically Based Rendering: From Theory To Implementation이 있음
• 머신러닝은 현재 과대광고만큼의 성과를 내지는 못할 것으로 보지만, 컴퓨터 과학 도구상자 안에서 피팅과 최적화 기법을 배울 가치는 있음
  • 관련 자료로 Machine Learning For Game Developers 영상을 참고할 수 있음

포트폴리오로 보여줄 만한 코드

• 채용 담당자에게 지식을 증명하려면 GitHub 같은 곳에 공유 가능한 소스 코드를 두고 이력서에서 연결하는 것이 이상적임
• 예시 포트폴리오:
  • 모델과 텍스처 같은 애셋을 로드하고 화면에 실시간으로 렌더링하는 엔진형 렌더러
    • 조명과 그림자, depth of field, area lights, tone mapping, ray traced shadows 같은 몇 가지 효과 포함
    • 가능하면 PBR 기반 조명, 사용자가 제어할 수 있는 카메라, DX12·Vulkan 같은 API, C++ 사용
  • 사진 같은 이미지를 생성하는 path tracer
    • 가능하면 C++가 좋지만, 창 없이 PNG만 출력하는 프로그램이어도 됨
    • 실시간일 필요는 없음
  • path tracer가 엔진형 렌더러의 별도 모드라면 더 좋음
    • path traced 결과와 실시간 PBR 렌더링을 비교해 정확성을 검증할 수 있음
    • 두 렌더링이 일치하지 않는 지점을 짚고, 왜 다른지 설명하며, 실시간성을 유지하면서 더 가깝게 만들 방법을 생각할 수 있으면 더 높은 평가를 받을 수 있음

수학, 알고리듬, 언어 선택

• 위 항목들을 직접 해보면 필요한 수학을 자연스럽게 만나게 됨
  • 기본적으로 필요한 것은 선형대수의 행렬 곱셈, cross product, dot product, 기본 삼각법, 약간의 미적분임
  • 그래픽스와 게임 개발은 필요한 수학의 최소치는 비교적 작지만, 활용 가능한 수학의 범위는 사실상 제한이 없음
• 알고리듬도 비슷함
  • linked list, hash table, 정렬, 검색 같은 기본 추상 자료형과 알고리듬은 알아야 함
  • 가장 빠른 알고리듬은 단순한 경우가 많고, 배열은 linked list보다 훨씬 빠름
  • 더 고급 알고리듬 개념은 새롭고 맞춤형인 무언가가 정말 필요할 때 도움이 됨
• 게임 개발에서 배워야 할 언어는 C++ 임
  • Rust를 쓰는 사람도 있고 일부 지분은 있지만, 사람들이 기대하는 표준 언어는 아님
  • WebGPU는 WebGL에 없던 많은 기능을 갖추고 더 진지한 플랫폼이 되고 있으며, CPU 측 작업을 JavaScript로 할 수 있게 함
  • 다만 WebGPU 일자리와 웹상의 WebGPU 콘텐츠는 많이 보지 못했음
• 셰이더 언어는 HLSL이 가장 흔함
  • 일부는 GLSL을 사용함
  • 멀티플랫폼 게임에서는 셰이더가 다른 셰이더 언어로 변환되는 경우가 많음

LLM과 ML에 대한 활용 범위

• 현재 ML 기술은 판매되는 사용처 대부분에 충분하지 않은 수준으로 봄
• Claude와 수학, 논문, 익숙하지 않은 알고리듬을 이야기하는 데는 도움이 됨
  • 이런 상황에서는 지어낸 내용을 말하는지 확인하기 쉽고, 다른 출처로 타당성을 점검하기도 쉬움
• 프로그래밍에는 그다지 유용하지 않음
  • 원하는 대로 동작하는 코드를 내놓더라도 그 코드를 이해하려면 시간을 들여야 함
  • 그럴 바에는 직접 작성하는 편이 낫다고 봄
• 작은 용도는 유용할 수 있음
  • 예를 들어 “이 파일에서 버그가 보이는가?”라고 물으면, 답이 yes일 때 조사할 수 있고 no여도 물어보는 비용이 거의 없음
• 언젠가는 인류가 인간 수준의 인공지능을 만들고 그 이상으로 나아갈 것이라고 믿지만, 그 시점이 자신의 생애 안일지는 알 수 없다고 봄
  • 현재 LLM 시대는 나중에 “진짜”가 왔을 때를 위한 예행연습에 가까움