그래픽스 프로그래머가 되려면 뭘 배워야 할까

그래픽스 프로그래밍은 사실상 두 직무가 섞여 있음

• 글쓴이는 그래픽스 프로그래머로 채용될 만하려면 뭘 알아야 하냐는 질문을 자주 받아서, 아예 링크로 줄 수 있는 가이드를 정리함.

  • 먼저 요즘 분위기답게 대규모 언어 모델(LLM)과 머신러닝(ML) 이야기를 꺼내는데, 현재의 ML 열풍은 과장된 면이 있고 몇 년 안에 열기가 좀 식을 거라고 봄.
  • 그래도 ML 자체가 컴퓨터 과학 도구함에서 사라질 건 아니고, 피팅(fitting)과 최적화(optimization) 기법은 배워둘 가치가 있다고 봄.

• 현대 렌더링은 크게 CPU 쪽과 GPU 쪽으로 갈라짐. 이게 은근 핵심임.

  • CPU 쪽은 DirectX 12, Vulkan, Metal 같은 현대적 명시적 그래픽스 API(explicit API)를 배우고, 에셋 로딩이나 엔진 지원 코드를 만드는 영역임.
  • GPU 쪽은 현대 조명과 셰이딩 수학, 그림자, 앰비언트 오클루전(ambient occlusion), 후처리 효과 같은 렌더링 기법을 다루는 영역임.
  • 여기에 GPU에서 뭐가 빠르고 뭐가 느린지 알아야 실시간으로 돌아가는 결과물을 만들 수 있음.

• 둘을 동시에 배우는 건 꽤 빡셈. 그래서 우선순위를 나눠야 함.
  • GPU 쪽 조명·셰이딩·렌더링 기법에 집중하고 싶으면, CPU 쪽은 OpenGL, WebGL, DirectX 11, 기존 엔진처럼 더 단순한 기반을 써도 됨.
  • 반대로 DirectX 12나 Vulkan 같은 API 쪽에 집중한다면, 일단 삼각형 하나 띄우고, 그다음 메시(mesh)를 띄우는 식으로 가면 됨.
  • 이 단계에서는 화면이 예쁘지 않아도 됨. 목표는 렌더링 파이프라인과 리소스 관리 감각을 잡는 쪽임.

패스 트레이싱과 PBR은 꼭 건드려야 함

• GPU 쪽 공부의 큰 축 하나는 패스 트레이서(path tracer)를 직접 만들어보는 것임.

  • 패스 트레이싱은 영화 렌더링에서 쓰이는 방식이고, 현대 실시간 렌더링은 이걸 빠르게 근사하려는 시도에 가까움.
  • 그래서 패스 트레이서를 만들면 “정답에 가까운 렌더링”이 뭔지 감이 생김.
  • 입문 자료로는 무료 온라인 책인 “Ray Tracing in One Weekend”가 추천됨. 많은 사람이 이걸로 시작했고, 접근성이 좋다고 평가함.

• 또 하나는 물리 기반 렌더링(PBR)임. 특히 스페큘러(specular), 그러니까 빛 반사 쪽을 원칙적으로 다루는 방식임.

  • PBR 이전에는 조명 계산에 온갖 임의 방정식과 트릭을 넣는 일이 흔했음.
  • 문제는 어떤 조명에서는 좋아 보이던 에셋이 조명을 바꾸면 너무 어둡거나, 반대로 이상하게 빛나는 식으로 깨졌다는 점임.
  • 그래서 조명 조건마다 에셋 버전을 따로 만드는 식의 낭비가 생겼고, 시간·돈·노력이 많이 들었음.

• PBR은 그 문제를 줄여준 큰 전환점이었음.

  • 규칙을 지키면 에셋이 여러 조명 조건에서 기본적으로 더 자연스럽게 보임.
  • 덕분에 조명마다 에셋을 따로 손보는 부담이 줄었고, 게임 업계 입장에서는 꽤 큰 승리였음.
  • 다만 에셋 제작 시간과 비용은 여전히 게임 개발의 큰 병목이라고 글쓴이는 봄. PBR이 마법은 아니라는 얘기임.

• PBR을 깊게 파고들수록 수학 난이도도 올라감.

  • 입문으로는 LearnOpenGL의 PBR 섹션이 좋고, 더 깊게 가면 Google Filament 문서가 추천됨.
  • Filament 문서부터는 미적분과 통계가 꽤 나온다고 함.
  • 최종 보스급으로는 무료 온라인 책인 “Physically Based Rendering: From Theory To Implementation”, 흔히 PBRT 책이 있음.

포트폴리오는 말보다 코드가 세다

• 채용 관점에서는 “안다”보다 “보여줄 수 있다”가 훨씬 중요함.

  • GitHub 같은 곳에 소스 코드를 올리고, 이력서에 링크할 수 있으면 좋음.
  • 특히 그래픽스는 결과물이 눈에 보이기 때문에, 데모와 코드가 같이 있으면 설득력이 커짐.

• 추천되는 첫 번째 포트폴리오는 엔진처럼 보이는 실시간 렌더러임.

  • 모델과 텍스처 같은 에셋을 로드할 수 있어야 함.
  • 실시간으로 화면에 렌더링하고, 조명과 몇 가지 효과를 보여주는 게 좋음.
  • 예시로는 그림자, 피사계 심도(depth of field), 면광원(area lights), 톤 매핑(tone mapping), 레이 트레이싱 그림자 등이 있음.
  • 가능하면 PBR로 조명 처리하고, 사용자가 조작 가능한 카메라를 넣고, DirectX 12나 Vulkan 같은 API와 C++로 작성하는 쪽이 좋다고 봄.

• 추천되는 두 번째 포트폴리오는 사진 같은 이미지를 만드는 패스 트레이서임.

  • C++이면 가장 좋지만, 꼭 실시간 창을 띄울 필요는 없음.
  • 그냥 실행하면 PNG 파일을 뽑는 프로그램이어도 충분함.
  • 중요한 건 광선 추적, 재질, 조명, 샘플링 같은 렌더링 원리를 코드로 구현했다는 증거임.

• 보너스 점수는 실시간 렌더러와 패스 트레이서를 연결할 때 나옴.

  • 패스 트레이서를 엔진형 렌더러의 별도 모드로 만들면 더 좋음.
  • 패스 트레이싱 결과를 기준으로 실시간 PBR 렌더링이 맞는지 검증할 수 있기 때문임.
  • 더 나아가 두 결과가 어디서 다르게 나오는지 설명하고, 실시간성을 유지하면서 더 비슷하게 만들 방법까지 말할 수 있으면 강력함.

수학·알고리즘·언어 선택은 현실적으로 접근하면 됨

• 필요한 수학은 생각보다 무한정 많지는 않음. 시작에 필요한 건 꽤 명확함.

  • 선형대수는 필수임. 행렬 곱, 외적(cross product), 내적(dot product)은 계속 나옴.
  • 기본 삼각함수도 필요함.
  • 미적분은 약간 필요하지만, 처음부터 고급 수학을 다 알아야 하는 건 아님.
  • 다만 그래픽스의 재밌는 점은 “필요한 수학은 제한적이지만, 활용 가능한 수학은 사실상 무한”이라는 데 있음.

• 알고리즘도 비슷함. 기본기가 먼저임.

  • 연결 리스트, 해시 테이블, 정렬, 검색 같은 기본 자료구조와 알고리즘은 알아야 함.
  • 하지만 실무에서는 가장 빠른 알고리즘이 가장 단순한 경우도 많음.
  • 예를 들어 배열은 연결 리스트보다 훨씬 빠른 경우가 많음.
  • 그래도 정말 새로운 커스텀 해결책이 필요할 때는 더 고급 알고리즘 지식이 도움이 됨.

• 게임 개발에서 배울 언어를 하나 고르라면 C++임.

  • Rust를 쓰는 사람도 있고 점유율이 있는 건 맞지만, 표준처럼 기대되는 언어는 아직 C++ 쪽임.
  • WebGPU는 WebGL보다 훨씬 많은 기능을 제공하고, JavaScript로 CPU 쪽 작업을 할 수 있게 해줌.
  • 다만 글쓴이는 WebGPU 일자리나 웹상의 WebGPU 콘텐츠를 많이 보지 못했다고 함.
  • 그래서 CPU 쪽 그래픽스 프로그래밍을 위해서는 C++이 압도적으로 우선순위가 높다고 봄.

• 셰이더 언어는 HLSL이 가장 흔해 보인다고 함.

  • GLSL을 쓰는 사람들도 있음.
  • 멀티플랫폼 게임에서는 셰이더를 다른 셰이더 언어로 변환(transpile)하는 경우가 많음.

---

기술 맥락

• 이 글에서 가장 중요한 선택은 “명시적 그래픽스 API를 먼저 팔지, 렌더링 이론을 먼저 팔지”예요. DirectX 12나 Vulkan은 리소스 관리와 동기화 부담이 커서, 여기에 조명·셰이딩 수학까지 같이 얹으면 초반 학습량이 확 늘어나거든요.

• 그래서 GPU 쪽을 배우려는 사람에게 OpenGL, WebGL, DirectX 11, 기존 엔진을 허용하는 게 꽤 실용적인 조언이에요. API 복잡도를 낮춰야 그림자, PBR, 후처리처럼 실제 화면 품질을 결정하는 개념에 집중할 수 있기 때문이에요.

• 반대로 CPU 쪽 엔진 프로그래밍을 노린다면 화면이 예쁘지 않아도 삼각형, 메시, 에셋 로딩 순서로 가는 게 맞아요. 이 단계의 목표는 미술적 결과물이 아니라 GPU에 데이터를 넘기고 렌더링 파이프라인을 제어하는 감각을 얻는 거예요.

• 패스 트레이서를 포트폴리오로 추천하는 이유도 단순히 멋있어서가 아니에요. 패스 트레이싱은 실시간 렌더링이 근사하려는 기준점에 가깝기 때문에, PBR 결과와 비교하면 내가 만든 렌더러가 어디서 타협하고 있는지 설명할 수 있거든요.