---
title: "그래픽스 프로그래머가 되려면 뭘 배워야 할까"
published: 2026-07-01T17:53:44.000Z
canonical: https://jeff.news/article/4501
---
# 그래픽스 프로그래머가 되려면 뭘 배워야 할까

그래픽스 프로그래머로 취업하려면 CPU 쪽 렌더링 API와 GPU 쪽 조명·셰이딩 수학을 둘 다 이해해야 한다는 글이다. 다만 둘을 한 번에 잡기는 어렵기 때문에, 명시적 그래픽스 API와 실시간 렌더링 기법 중 어디에 먼저 집중할지 나눠 접근하라고 조언한다. 포트폴리오로는 C++ 기반 엔진스러운 렌더러와 사진처럼 보이는 이미지를 뽑는 패스 트레이서가 강하게 추천된다.

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

- 글쓴이는 그래픽스 프로그래머로 채용될 만하려면 뭘 알아야 하냐는 질문을 자주 받아서, 아예 링크로 줄 수 있는 가이드를 정리함.
  - 먼저 요즘 분위기답게 대규모 언어 모델(LLM)과 머신러닝(ML) 이야기를 꺼내는데, 현재의 ML 열풍은 과장된 면이 있고 몇 년 안에 열기가 좀 식을 거라고 봄.
  - 그래도 ML 자체가 컴퓨터 과학 도구함에서 사라질 건 아니고, 피팅(fitting)과 최적화(optimization) 기법은 배워둘 가치가 있다고 봄.

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

> [!IMPORTANT]
> 이 글의 핵심은 “둘 다 배워라”가 아니라 “둘을 한 번에 깊게 배우려 하지 말라”에 가까움. CPU API와 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 렌더링이 맞는지 검증할 수 있기 때문임.
  - 더 나아가 두 결과가 어디서 다르게 나오는지 설명하고, 실시간성을 유지하면서 더 비슷하게 만들 방법까지 말할 수 있으면 강력함.

> [!TIP]
> 단순히 “Vulkan 해봤음”보다 “내 실시간 렌더러의 PBR 결과가 패스 트레이서와 어디서 다르고 왜 그런지 설명 가능함”이 훨씬 세게 먹힘. 이건 API 사용법을 넘어 렌더링 원리를 이해했다는 신호라서임.

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

- 필요한 수학은 생각보다 무한정 많지는 않음. 시작에 필요한 건 꽤 명확함.
  - 선형대수는 필수임. 행렬 곱, 외적(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 결과와 비교하면 내가 만든 렌더러가 어디서 타협하고 있는지 설명할 수 있거든요.

## 핵심 포인트

- 현대 렌더링은 CPU 쪽 엔진·API 작업과 GPU 쪽 조명·셰이딩 작업이 거의 별도 직무처럼 나뉜다.
- DirectX 12, Vulkan, Metal 같은 명시적 그래픽스 API를 배우되, GPU 기법을 먼저 익히려면 OpenGL, WebGL, DirectX 11, 엔진 같은 더 단순한 기반을 써도 된다.
- 패스 트레이싱과 물리 기반 렌더링(PBR)은 실시간 렌더링의 기준점을 이해하는 데 핵심이다.
- 취업용 증거로는 모델과 텍스처를 로드하고 조명·효과를 실시간 렌더링하는 C++ 프로젝트, 그리고 사진 같은 이미지를 생성하는 패스 트레이서가 좋다.
- 수학은 선형대수, 기본 삼각함수, 약간의 미적분이면 시작 가능하지만, 그래픽스에서 활용할 수 있는 수학의 깊이는 사실상 끝이 없다.

## 인사이트

그래픽스 쪽은 ‘화려한 화면’을 만드는 분야처럼 보이지만, 실제 취업 관점에서는 코드로 증명 가능한 렌더러와 렌더링 이론의 연결이 중요함. 특히 패스 트레이서 결과와 실시간 PBR 결과를 비교해 설명할 수 있으면 단순 데모보다 훨씬 강한 포트폴리오가 된다.