채용 가능한 실시간 그래픽스 프로그래머가 되기 위해 배워야 할 핵심 기술, 렌더링 지식, 수학, 언어, 그리고 포트폴리오 방향을 정리한 글입니다.
실시간 그래픽스 프로그래머로 채용되려면 무엇을 알아야 하는지 꽤 자주 질문을 받습니다. 매번 다시 타이핑하는 대신 링크로 보낼 수 있는 페이지를 만들 때가 되었다고 생각했습니다.
우리는 LLM과 함께 다소 이상한 시기에 살고 있습니다. 제 생각에는 현재의 ML은 지금의 과장된 기대를 충족시키지 못할 것이고, 앞으로 몇 년 동안 추는 ML에서 약간 멀어지는 쪽으로 흔들릴 것입니다. 사기꾼들은 다음에는 양자 컴퓨팅으로 옮겨 가거나, 아니면 또 다른 무언가를 부풀렸다가 팔아치울 대상을 찾을 것이라고 생각합니다. 그렇지만 ML 자체는 컴퓨터 과학 도구 상자 안에서 분명한 자리가 있으므로, 그것이 제공하는 피팅과 최적화 기법을 배우는 것은 가치가 있다고 생각합니다. 기초적인 저수준 요소들을 배울 수 있도록 영상을 하나 만들었지만, 배울 가치가 있는지는 여러분이 판단하면 됩니다.
게임 개발자를 위한 머신 러닝
https://www.youtube.com/watch?v=sTAqWRsEiy0
그 외에는:
현대 렌더링은 일종의 두 가지 일을 하나로 합쳐 놓은 것과 같습니다.
이 두 가지를 동시에 배우는 것은 매우 어렵습니다. #2에 집중하고 싶다면 #1에는 opengl, webgl, DirectX11, 엔진 또는 비슷한 더 단순한 것을 사용할 수 있습니다. #1에 집중하고 싶다면 먼저 화면에 첫 삼각형을 띄우고, 그다음 메시를 띄우는 식으로 진행하되, 아주 예쁘게 보이는지는 걱정하지 마세요.
#2의 일부는 패스 트레이서를 작성하는 것입니다. 패스 트레이싱은 영화에서 렌더링을 하는 방식이며, 현대의 실시간 렌더링 기법들이 근사하려고 하는 대상이기도 합니다. 패스 트레이서를 시작하기에 아주 좋은 곳은 무료 온라인 책인 “Ray Tracing in One Weekend”입니다. 많은 사람들이 이 책을 사용했습니다. 정말 접근하기 쉽고, 사진처럼 사실적인 렌더링을 만드는 방법을 보여 줍니다.
https://raytracing.github.io/books/RayTracingInOneWeekend.html
#2의 또 다른 부분은 “물리 기반 렌더링” 또는 PBR을 배우는 것입니다. 이것은 조명을 적용하는 한 방식인데, 결국 따지고 보면 주로 정반사와 관련이 있습니다. PBR은 “원칙 기반”입니다. 즉, 규칙을 따르면 좋은 결과를 얻습니다. PBR 이전에는 사람들이 온갖 임의의 수정과 해킹이 들어간 제각각의 조명 방정식을 작성했습니다. 그 때문에 어떤 에셋은 한 상황에서는 보기 좋게 만들 수 있었지만, 조명을 바꾸면 너무 어둡게 보이거나 빛나는 것처럼 보이곤 했습니다. 사람들은 서로 다른 조명 조건에 맞춰 에셋의 다른 버전을 만들어야 했고, 그것은 많은 시간과 노력이 들었습니다.
PBR은 기본적으로 모든 조명 조건에서 에셋이 더 좋아 보이게 해 주고, 여러 버전을 만들 필요가 없도록 시간과 노력을 절약해 줍니다. 이것은 우리 업계에 큰 승리였습니다. 그럼에도 불구하고 에셋 제작 시간, 비용, 노력은 여전히 게임 개발의 큰 병목입니다.
이 페이지의 PBR 섹션(및 하위 섹션들)은 PBR 입문으로 아주 좋습니다.
https://learnopengl.com/PBR/Theory
어느 시점에 이것을 넘어 더 깊이 들어가고 싶다면, Filament 문서를 읽는 것이 좋은 다음 단계입니다. PBR을 더 깊이 파고들수록 미적분과 통계가 많이 나옵니다.
https://google.github.io/filament/Filament.md.html
그보다 더 나아가면 유명한 PBRT 책인 “Physically Based Rendering: From Theory To Implementation”이 있으며, 이것도 온라인에서 무료로 볼 수 있습니다.
이상적으로는 여러분이 이런 것들을 알고 있다는 증거를 보여 주기 위해, 잠재적 고용주와 공유할 수 있는 소스 코드가 있게 될 것입니다. 예를 들어 github에 올리고 이력서에 링크하는 식입니다. 대략 이런 것들입니다.
어떤 수학을 알아야 하는지 궁금할 수도 있습니다. 위의 항목들을 해 보면 알아야 할 수학을 자연스럽게 마주치게 되지만, 기본적으로는 선형대수(행렬 곱셈, 외적, 내적), 기초 삼각법, 그리고 약간의 미적분이 실제로 필요한 전부입니다. 그래픽스(그리고 전반적인 게임 개발)의 재미있는 점은, 필요한 수학의 양은 꽤 적지만 사용할 수 있는 수학의 양은 사실상 무한하다는 것입니다.
알고리즘도 마찬가지입니다. 연결 리스트, 해시 테이블, 정렬, 탐색 같은 기본적인 추상 자료형과 알고리즘을 알아야 합니다. 많은 경우 가장 빠른 알고리즘은 가장 단순합니다. 배열은 연결 리스트보다 훨씬 빠릅니다. 하지만 더 고급의 알고리즘 개념을 알고 있으면, 정말로 새롭고 맞춤형인 무언가가 필요할 때 도움이 될 수 있습니다.
게임 개발에서는 C++가 배워야 할 언어입니다. rust를 사용하는 사람들도 있고, rust 사용이 늘고 있는지는 판단하기 어렵지만, 표준 언어로 기대되는 정도는 아니어도 분명 일정한 지분은 가지고 있습니다. WebGPU는 WebGL에 없던 많은 기능을 갖고 있고 점점 더 진지한 플랫폼이 되고 있어서, CPU 측 작업을 javascript로 할 수 있게 해 줍니다. 다만 게시된 WebGPU 채용 공고는 많이 보지 못했고, 웹에서도 WebGPU 관련 콘텐츠를 많이 보지는 못했습니다. CPU 측 프로그래밍을 위해서는 단연코 C++를 배우는 것이 맞아 보입니다.
셰이더 언어로는 hlsl이 가장 흔해 보이지만, glsl로 작업하는 사람들도 있습니다. 멀티 플랫폼 게임에서는 셰이더를 다른 셰이더 언어로 트랜스파일하는 경우가 많습니다.
그래픽스 프로그래머가 되려면 미술을 잘해야 하는지 궁금할 수도 있습니다. 다행히 그렇지는 않습니다. 여러분은 미술을 잘하는 아티스트들, 그리고 프로그래머와 아티스트 사이에 있으면서 두 분야 사이의 이해 차이를 메워 주는 테크니컬 아티스트들과 협업하게 될 것입니다. 그렇다고 해도 미술이나 사진 같은 것에 대해 어느 정도 알고 있다면 도움이 되기는 합니다. 하지만 필수는 아닙니다.
상황이 바뀌거나 여기서 다루지 않은 질문을 사람들이 하면 이 페이지를 계속 업데이트하겠습니다.
에이전트에 관한 확장 ML 코멘터리:
저는 현재의 ML 기술이 그들이 활용처라고 팔고 있는 대부분의 일에 대해 “과업을 해낼 수준”이라고 믿지 않습니다. 저는 Claude와 수학, 논문, 낯선 알고리즘에 대해 이야기하면서는 실제로 도움을 받습니다. 그런 상황에서는 지어내고 있는지 아닌지 쉽게 알아볼 수 있고, 다른 출처로 상식적인 교차 확인을 하기도 쉽습니다. 하지만 프로그래밍에는 그다지 유용하다고 느끼지 않습니다. 설령 해야 할 일을 제대로 해내더라도, 제가 그 코드를 이해하기 위해 시간을 들여 이해하지 않으면 소용이 없기 때문입니다. 그 시점이면 차라리 제가 직접 썼어야 했을 것입니다. 물론 제가 유용하다고 느끼는 더 작은 일들도 있습니다. 예를 들면 “이 파일에 버그가 보이나요?” 같은 질문인데, 그러면 그렇다고 답이 와서 제가 조사해 볼 수도 있고, 아니라고 답이 와도 물어보는 데 비용이 거의 들지 않습니다. 이런 기술적인 문제들을 제쳐 두더라도, 저는 언젠가 인류가 실제 인간 수준의 인공지능을 만드는 방법을 알아내고, 그 수준을 넘어설 것이라고 믿습니다. 그것이 제 생애 안에 일어날지는 모르겠지만, 언젠가는 일어날 것이라고 믿습니다. 우리가 먼저 스스로를 파괴해 버리지 않는 한 말입니다. 그런 의미에서 지금의 LLM 시대는 나중에 “진짜 물건”이 왔을 때를 위한 일종의 드레스 리허설과 같습니다. 그때가 왔을 때 우리가 올바른 교훈을 배우고 더 잘 준비되어 있기를 바랍니다.
