# 그래픽스 프로그래머가 되려면 무엇을 배워야 하는가 > Clean Markdown view of GeekNews topic #31053. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31053](https://news.hada.io/topic?id=31053) - GeekNews Markdown: [https://news.hada.io/topic/31053.md](https://news.hada.io/topic/31053.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-03T02:46:46+09:00 - Updated: 2026-07-03T02:46:46+09:00 - Original source: [blog.demofox.org](https://blog.demofox.org/2026/07/01/what-to-learn-to-be-a-graphics-programmer/) - Points: 1 - Comments: 1 ## Topic Body - 실시간 그래픽스 채용 역량은 **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](https://raytracing.github.io/books/RayTracingInOneWeekend.html)가 적합하며, 접근하기 쉽고 사진 같은 렌더링을 만드는 과정을 보여줌 - **Physically Based Rendering(PBR)** 은 조명, 특히 specular 적용 방식에 해당함 - PBR은 규칙을 지키면 좋은 결과를 얻는 원칙 기반 방식임 - PBR 이전에는 조명을 위해 임의의 수식, 조정, 해킹을 많이 사용했기 때문에 한 조명 환경에서 좋아 보이던 애셋이 다른 환경에서는 너무 어둡거나 빛나는 것처럼 보일 수 있었음 - 그 결과 조명 조건별로 다른 애셋 버전을 만들어야 했고, 시간과 노력이 많이 들었음 - PBR은 여러 조명 조건에서 애셋이 더 일관되게 보이도록 만들고, 버전별 애셋 제작에 드는 시간과 노력을 줄임 - 그래도 애셋 제작 시간, 비용, 노력은 여전히 게임 개발의 큰 병목임 ### 추천 학습 자료 - PBR 입문에는 [LearnOpenGL의 PBR Theory](https://learnopengl.com/PBR/Theory) 섹션과 하위 섹션이 적합함 - 더 깊게 들어가려면 [Filament documentation](https://google.github.io/filament/Filament.md.html)이 다음 단계가 될 수 있음 - PBR을 깊이 배울수록 미적분과 통계가 많이 등장함 - 더 나아가면 무료 온라인 책 [Physically Based Rendering: From Theory To Implementation](https://pbrt.org/)이 있음 - 머신러닝은 현재 과대광고만큼의 성과를 내지는 못할 것으로 보지만, 컴퓨터 과학 도구상자 안에서 **피팅과 최적화 기법**을 배울 가치는 있음 - 관련 자료로 [Machine Learning For Game Developers](https://www.youtube.com/watch?v=sTAqWRsEiy0) 영상을 참고할 수 있음 ### 포트폴리오로 보여줄 만한 코드 - 채용 담당자에게 지식을 증명하려면 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 시대는 나중에 “진짜”가 왔을 때를 위한 예행연습에 가까움 ## Comments ### Comment 61119 - Author: neo - Created: 2026-07-03T02:46:47+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48750710) - 게임을 만들고 싶은 건지, **3D 엔진 프로그래밍**을 하고 싶은 건지 먼저 구분해야 함 게임을 만들고 싶다면 Unreal Engine, Unity, Godot, Bevy 같은 기존 엔진을 쓰는 편이 좋고, 픽셀을 직접 밀어 넣는 법보다 그래픽의 상위 수준 문제를 배우게 됨. 진짜 어려운 건 재미있게 만드는 것임 3D 엔진을 만들고 싶다면 형편없는 게임 엔진이 이미 너무 많다는 점을 알아야 함. Rust 쪽만 봐도 실패한 렌더러 3개, 미완성 렌더러 1개, Bevy 안의 렌더러가 주요 프로젝트이고, “게임 엔진 만들겠다”는 프로젝트는 훨씬 많음. “첫 렌더러” 수준까지 가는 데도 2년쯤 걸리고, 크고 세밀하며 동적인 장면까지 가는 건 훨씬 큰 일임 취업이 목적이면 게임 업계는 급여도 근무시간도 좋지 않고, 프로젝트가 끝나면 일자리도 끝나며, Hollywood처럼 들어오려는 지망생이 넘쳐남. 게다가 Metaverse 붕괴 때문에 지금은 경험자도 과잉임 모바일은 화면, 연산 성능, GPU, 배터리 모두 부족한 압축 작업이고, 그래서 요즘 인디 게임 대부분은 **2D**임. 그나마 가능하고, HTML/JavaScript로도 자주 만듦 - 대부분이 Unreal과 **비주얼 경쟁**을 하려 한다고 가정한 것 같은데, 그건 당연히 거의 불가능함 하지만 기본 렌더러와 게임 루프를 만드는 건 그렇게 어렵지 않고, 게임 코드의 대부분이 되지도 않을 가능성이 큼. 단순한 게임이면 `for` 루프에서 `drawObject()`만 해도 충분하고, 자원 스트리밍, 바인딩 최적화, 병렬성 같은 걱정은 나중에 필요할 때 해도 됨 “첫 렌더러까지 2년”이라는 기준이 어떤 출발점과 성공 조건을 상정한 건지 궁금함. 1년 전쯤 자유시간 한 달, 전업 기준 1주일도 안 되는 시간에 동적 조명, 그림자 매핑, 몇 가지 후처리가 있는 지연 렌더러를 만들었음 2D라고 낮게 볼 이유도 없음. 진지한 작업 상당수는 2D 인터페이스에서 이뤄지고, WebGL과 오래된 2D canvas도 요즘은 꽤 강력함. 히트한 인디 게임 중에도 2D가 많음 게임 업계가 별로라는 건 맞지만, 요즘은 거의 모든 것이 GPU를 씀. 기계학습 작업 작성·디버깅, 데이터 시각화, HUD, 일반 사용자 인터페이스도 그래픽 이해가 필요한 경우가 많음 - 게임 업계 평균은 별로일 수 있지만, **그래픽스 프로그래밍**이라는 틈새는 그렇지 않다고 봄 게임 말고도 시각화, 시뮬레이션 등 그래픽을 쓰는 분야가 훨씬 많고, 좋은 그래픽스 프로그래머는 극히 드물어서 의외로 괜찮은 커리어임. 게임 개발자나 아티스트가 좋은 일자리를 얻기 더 어려워 보이는 것과는 꽤 대조적임. 다만 수요와 공급 모두 작아서 이직이 쉽지는 않을 수 있음 직업 안정성만 보면 게임 개발을 커리어로 삼는 건 말리고 싶지만, 그래픽스 프로그래밍은 다름 - Unity나 Unreal Engine 때문에 원래 괜찮은 게임들이 **성능 문제**를 겪는 경우가 너무 많아 아쉬움. 이런 걸 추천하지 않았으면 좋겠고, Godot과 Bevy가 더 나은지는 아직 모르겠음 최근 몇 년간 해본 게임 중 Core Keeper(Unity), WORMHOLE(Unity, 특히 무한 모드의 지연), Crab Champions(UE4, 1920x1200에서 60fps 유지하려고 화면을 못생기게 만드는 업스케일링을 써야 함)가 성능 문제가 심했음 반면 Terraria, Necesse, Barony는 자체 엔진을 쓰고 훌륭하게 돌아가며, 오래될수록 더 좋아 보임 공정하게 말하면 Tiny Rogues(Unity)는 기억상 대체로 잘 돌아갔지만, 개발자가 앞으로 Unity를 벗어나려 작업 중이니 스스로도 문제를 찾은 것으로 보임 게임 만들기와 엔진 만들기의 차이, 실제 완성과 출시의 중요성은 알지만, 쓰레기를 내놓으면 좋은 유산을 남기기 어렵다. 멀리 돌아가더라도 일정 수준의 품질을 보장하는 편이 낫다고 봄. 게임은 출시 후 수십 년 동안 플레이되기도 하고, 버그나 지연이 있으면 사람들은 계속 그걸 겪게 됨 - 엔진을 만들기 시작하면 특히 배우면서 하는 경우 게임은 못 만들 가능성이 큼. 둘 다 성공하는 게 기술적으로 가능하긴 하지만, 예전에 직접 겪고 폴란드 취미 게임 개발 커뮤니티에서 수십 명을 봤을 때 성공 확률은 **5% 미만**에 가까웠음 “다음 게임을 쉽게 만들려고 먼저 내 게임용 엔진을 만들겠다”는 놀라울 정도로 강한 함정임. 실제로 중요한 것을 배우고 매일 작은 승리를 얻기 때문임. 장면이 부드럽게 보이도록 언롤을 하나 더 하고, 장면을 만들기 쉽게 설정 형식에 논리 계층을 하나 더 넣고, SIGGRAPH 논문을 하나 더 읽게 됨 개선할 중요한 것은 늘 있지만, 그것들이 완성된 게임으로 합쳐지지는 않음. 돌아보면 직접 엔진을 쓰는 건 기술자가 꿈꾸던 게임의 어렵지만 필요한 부분, 즉 “재미있게 만들기”를 미루는 완벽한 방법임. 인상적인 비디오 게임을 코딩하는 기술은 익히지만, 게임을 만드는 법은 배우지 못함 하위 함정도 있음. 실시간으로 부드럽게 돌아가는 아름다운 시각 효과를 만드는 방법은 백 가지 배우지만, 그걸 예술로 쓰는 법은 배우지 못함 이것은 “Enterprise Java”의 함정과도 매우 비슷함. 다만 구체적인 용어를 다루기 때문에 더 교묘함. Scene Graph에 Factory Factory Interface가 없으니 그 총알은 피했다고 생각하지만, 사실 화면에 비트맵을 띄우고 키에 반응하게 만드는 작업에는 그 자체가 불필요하다는 점을 놓치게 됨 - 게임을 만들고 싶으면 항상 기존 엔진을 쓰라는 데는 꼭 동의하지 않음. 대부분의 경우에는 좋은 조언이지만, 기존 엔진은 너무 **범용적**이고 게임에 대한 가정이 많음. 게임에 다른 제약이 필요할 수도 있음 특히 2D에서는 그렇다. 예를 들어 직접 만든 게임 엔진으로 게임을 만들고 있는데, 성능과 압축, 서버나 데이터베이스가 없는 구조에 초점을 맞추고 있음 이 엔진은 내가 정한 제약 안에서 극단적인 성능과 압축을 달성하기 위해 게임 구조에 대한 매우 구체적인 구조와 가정을 가짐. 관련 Hacker News 글을 곧, 가능하면 다음 주에 올릴 예정임 예전에도 브라우저 게임을 Unity, Godot, React로 여러 번 만들려 했지만 API를 배우는 게 고역이었고, 엔진들이 내 극단적 제약을 만족하지 못했음. 물론 내가 그 엔진들을 잘 못 다룬 탓도 있겠지만, 돌아봐도 내부적으로 달성한 것은 처음부터 만든 **커스텀 엔진** 없이는 불가능했을 거라고 봄 직접 엔진과 게임을 만들며 정말 많이 배웠고, 특히 요즘은 LLM 덕분에 경험 있는 개발자가 직접 맞춤형 게임 엔진을 만들어보는 일이 대부분의 개발자에게 갑자기 현실적인 범위에 들어왔다고 생각함 - 지금이라면 누구에게도 그래픽스 프로그래밍에 들어오라고 추천하지 않겠음 2001년 Nvidia의 첫 GeForce 1, 이른바 “Gigatexel shader card”가 발표되던 때 시작했는데, 그 이후 이 분야의 발전 속도와 혁신은 정신이 아찔할 정도였음. 25년 전과 비교하면 지금 기술은 정말 엄청남 하지만 이 놀라움에는 큰 “하지만”이 있음. 이 분야는 무서울 정도로 빠르게 발전하고 있음. Nvidia는 장면과 자산에 영향을 주는 AI 기반 효과까지 내놓았고, 당시에는 이런 것이 실시간으로 가능하리라고 상상도 못 했음 이제 이 분야에서 “괜찮은 전문가”가 되는 게 가능한지도 모르겠음. 다른 말로 하면 “오늘날의 **John Carmack**은 어디 있는가?”라는 질문임. 그는 하드웨어를 끝까지 쥐어짜고 커뮤니티에 숨어 있던 아이디어를 써서 유명해졌지만, 오늘날 그런 사람에게 경쟁 해자는 없어 보임. 분야가 너무 넓고 빠르게 변해서 다음 Carmack이 될 기회가 없기 때문임 - 어떤 분야에 들어온 뒤 다른 사람을 말리는 태도는 정말 싫음. “나처럼 되지 마, 인생을 낭비했어”라는 건 열정을 잃고 지친 사람의 헛소리에 가깝고, 그래픽스 프로그래밍을 피하라고 하는 건 내일의 John Carmack을 끌어들이는 방식이 아님 다른 관점도 있음. 지금까지 웹 앱과 Kubernetes만 해봤다면 오히려 그래픽스 프로그래밍을 해보는 게 좋음. 피드백 루프가 짜릿하고, 평범한 컴퓨터가 얼마나 말도 안 되게 빠른지 체감하게 됨. 결국 중요하지 않은 최적화를 하게 되더라도, 저수준에서 사물이 얼마나 빠른지 배운 적이 없기 때문에 가치가 있음 자료도 많고 수학도 지나치게 어렵지는 않음. 3D 모델링이 몰랐던 창작 출구가 될 수도 있음. 본업에 전혀 적용되지 않더라도 컴퓨터 프로그래밍이라는 예술을 새롭게 감상하게 되고, Kubernetes를 다시는 건드리지 않고 여가 시간 5년을 들여 자기 게임 엔진을 쓰기로 할지도 모름 그런 미친 사람들은 많고, 직업 게임 개발에 닳아 없어지지 않은 취미 개발자 커뮤니티는 생각보다 큼. Graphics Programming Discord도 확인해볼 만한 환영받는 공간임. 해보면 됨 - 컴퓨터 그래픽스는 본질적으로 흥미롭고 보람 있음. 컴퓨터 과학, 수학, 이론물리, 저수준 프로그래밍 같은 여러 중요한 분야의 교차점에 있음 실제로 뭘 하는지는 상관없고 커리어 전환만 원하는 사람에게는 피하라는 조언이 맞을 수도 있음. 하지만 그런 식으로 사는 건 좋은 방법이 아님. 흥미롭고 가치 있다고 느끼는 것을 따르고, 끊임없이 새로운 것을 배우며 스스로에게 도전하는 편이 낫다. 그러면 컴퓨터 그래픽스를 배울지 말지는 비교적 분명해지고, 맞는 사람에게는 순이익이 됨. 직업이 되지 않더라도 기술은 다른 많은 영역으로 잘 이전됨 - 그래픽스 프로그래밍에는 오늘날 기하급수적으로 더 가치 있는 유용한 면이 하나 있음. **행렬 대수 파이프라인**과 “행렬 변환으로 생각하기”는 기계학습 수학의 토대를 잡기에 훌륭하고 시각적으로도 몰입감 있는 방법임 - Inigo Quilez 같은 사람은 어떨까? 오늘날에도 충분히 주목받는 인물이라고 봄. 그리고 지금은 분야 전체에 사람이 훨씬 많아져서 모두가 유명해질 수는 없음 한 분야에서 가장 잘 알려진 사람 중 하나만큼 유명하지 않아도 괜찮고, 그냥 즐거워서 해도 됨. 그래픽스와 게임 프로그래밍의 수학과 예술은 그 자체로 아름다움 - 맞음. Carmack이 유명해진 영리한 기법 대부분은 소프트웨어에서 **하드웨어**로 옮겨갔음 그래픽스 프로그래밍에 들어오지 말자는 내 이유는 다름. 정점과 텍스처를 가진 3D 엔진이 몇 년 뒤에도 존재할까? 아니면 모든 것이 AI 세계 모델이 직접 렌더링하게 될까? 게임에는 얼마나 많은 코드가 들어갈까, 아니면 영리하게 작성한 프롬프트들의 연속으로 존재하게 될까? - 선형대수 빠른 튜토리얼이 필요하다면 내가 쓴 인쇄 가능한 4쪽짜리를 볼 수 있음: [https://minireference.com/static/tutorials/linear_algebra_in...]() SymPy 코드 예제가 들어 있는 노트북도 여기에 있음: [https://github.com/minireference/noBSLAnotebooks]() - 더 긴 튜토리얼이 필요하다면 3b1b의 시리즈를 강력 추천함: [https://youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2xVFit...]() 시각화 덕분에 Linear 101 수업에서는 이해되지 않던 것들이 확 와닿았음 - 미적으로도 정말 아름다움. 아름다운 수학이 나쁜 **타이포그래피**와 못생긴 간격으로 제시될 때마다 늘 아쉬움 - 기본 디자인 원칙이나 인간 지각의 특성을 이해하는 이야기가 없다는 점이 조금 놀라움 내 형은 90~00년대 유명 컴퓨터 게임들의 프로덕션 아티스트였는데, 시각 감각도 없고 아티스트 쪽을 이해하려는 호기심도 없는 프로그래머와 관리자들에 대해 계속 불평했음 그래픽은 내 전문은 아니지만, 음악가·사운드 디자이너·프로듀서로서 내가 아는 가장 효과적이고 영향력 있는 오디오 DSP 코더들은 음악의 기본, 소리의 물리와 음향, 이산 디지털 처리와 우리가 자극을 지각하고 해석하는 방식 사이의 함정을 이해함 - 말한 내용에 더 가까운 별도 역할이 있는데, **테크니컬 아티스트**라고 부름. 내가 하는 일이기도 함 그래픽스 프로그래머가 예술적 사고방식을 가지면 도움이 되지만, 보통은 꽤 저수준에서 일하기 때문에 성공에 필수는 아님 - 창작 산업 밖에서도 똑같이 적용됨. B2B/기업용 소프트웨어에서도 판매 대상 산업이 어떻게 돌아가는지, 사용자가 어떻게 생각하는지 전혀 모르는 공급업체를 꽤 많이 봤음 AI가 계산을 조금 바꿨거나 최소한 바꿀 잠재력은 있지만, 2000년대 중반의 “코딩을 배우자” 흐름도 상당 부분 이런 이유였다고 봄. 소프트웨어 개발을 기존 분야 전문가의 “제품이 아니라 기능”처럼 다뤄서, 도메인을 가장 잘 아는 사람들이 요구사항을 개발팀에 번역해 전달하는 대신 직접 소프트웨어를 만들게 하려는 움직임이었음 - 100% 동의함. 좋은 그래픽스 프로그래머는 테크 아티스트와 아티스트와 함께 일함 솔직히 그래픽스 프로그래밍은 대체로 그 사람들이 하고 싶은 일을 가능하게 하거나, 상상한 것을 만들도록 돕는 **서비스 역할**에 가까움 Inigo Quilez는 그래픽스 프로그래머이면서 아티스트인 예로 거론되는데, 정말 강력하고 유니콘 같은 사람임 개인적으로는 음악 연주와 오디오 프로그래밍을 더 좋아하고, DSP를 배우기에 좋은 기반이 됨. 예를 들어 렌더링 노이즈를 고주파 쪽으로 밀어 넣으면 저역 통과 필터가 노이즈 제거에 더 효과적일 때가 있음 - 내가 만들고 유지하는 목록은 여기 있음: [https://legends2k.github.io/note/cg_resources/]() 호기심이 생기고 시간이 있다면 배우면 좋음. 정말 재미있고 많이 배우게 되며, 컴퓨터 과학의 다른 여러 분야에서도 더 나은 엔지니어가 되게 해줌. 하드웨어, 시스템 프로그래밍, 프로그래머의 기계 모델 등을 이해하게 됨 하지만 돈을 최종 목표로 삼는다면 배우지 않는 편이 낫다. 요즘 시대에는 그 보상이 덧없고 일시적이며 보장되지 않음 - 나도 이 자료를 쓰고 있는데, 다른 사람들에게도 유용할 수 있음: [https://owlcat.games/learning]() - “25세 미만이고 여기에 쏟을 시간이 많을 것”도 포함해야 할 듯함 예전부터 그래픽스 프로그래밍에 관심이 있었고 몇 년 전 Vulkan을 독학하기 시작했음. 총 얼마나 썼는지는 모르겠지만, 6개월 정도 저녁 자유시간, 어쩌면 그보다 조금 덜 쓴 것 같음. 렌더링 프레임워크에 가까운 것은 만들었음 그런데 더 나아갈수록 얼마나 모르는 게 많은지 깨닫는 종류의 일임. 이제 구조가 괜찮다고 느끼는 순간, 그게 올바른 아키텍처가 아니라는 걸 발견함 결국 하는 일은 기본적으로 **응용 조명 수학**이고, 나머지는 배관 작업임. “왜 스포트라이트가 큐브를 그대로 통과하지?” 하고 보면 그림자를 계산해야 하고, 그걸 렌더 파이프라인에 넣는 방법을 몇 주 동안 파고들게 됨. 그래도 이런 걸 좋아한다면 꽤 “재미” 있음 - 안타깝게도 Vulkan은 그래픽스 프로그래밍을 배우기에는 정말 고통스러운 방법임. 거의 모든 일을 하려면 엄청난 **상용구 코드**가 필요함 예를 들어 그림자를 만들 때도 기술 자체가 본질적으로 요구하는 것보다 10배는 많은 코드를 써야 함 그래픽스 프로그래밍을 배우려면 소프트웨어 렌더러를 작성하는 쪽이 훨씬 즐겁다고 봄. 코드가 적고, 작성하는 코드가 상용구가 아니라 핵심에 닿음. 단점은 하드웨어 가속을 잃어서 느려진다는 것임 - 무엇을 하고 싶은지에 달렸음 그냥 게임을 만들고 싶다면 Unity, Godot, Unreal 같은 **게임 엔진**을 쓰면 됨 엔진, 시뮬레이션, 렌더러 같은 그래픽스를 하고 싶다면 저수준 언어와 그래픽스 API를 배워야 함. 언어로는 C++를 추천하고, C나 Rust도 쓸 수 있지만 C는 조금 어렵고 그래픽스 API 자체가 이미 어려우니 언어와도 싸우고 싶지는 않을 것임. Rust도 좋은 선택일 수 있지만 개인적으로는 컴파일 시간이 매우 느리고 문법이 못생겼다고 느낌 API는 OpenGL을 추천함. 크로스 플랫폼이고 오래됐으며, 그 점이 장점이자 단점이고, 그중 가장 쉬움 learnopengl.com은 OpenGL 튜토리얼 중 단연 최고라서 따라 해보길 권함 OpenGL을 한동안 쓴 뒤에는 Vulkan이나 여러 API를 구현한 그래픽스 라이브러리로 넓혀가도 되고, 괜찮다면 계속 OpenGL을 써도 됨 분명 쉽지는 않지만 컴퓨터 과학에서 가장 매혹적인 분야 중 하나라고 봄 - A-Frame(aframe.io)을 만들었고 지금도 유지하고 있음. 지난 10년간 **3D 그래픽스**를 배우는 부드러운 입문로 역할을 해왔음 직접 말하긴 그렇지만 커뮤니티도 멋짐. 웹은 배우면서 만든 것을 공유하고, 피드백을 모으고, 가시성을 얻기에 좋은 방법임. 커뮤니티 안에서도 3D 그래픽스를 전문적으로 하게 된 사례가 많음 - A-Frame으로 석사 논문을 썼음. 당시에는 프로그래머가 아니었고 경험도 거의 없었지만, A-Frame 덕분에 내 아이디어를 정말 직관적으로 구현할 수 있었음 가끔 저장소를 돌아보면 당시 코드가 너무 엉망이라 민망하지만, 그 프로젝트가 없었다면 지금 위치에 있지 못했을 것 같음 - 확실히 추천할 수 있음 간단한 태그로 시작해서 애니메이션을 더하고, 부족하면 커뮤니티 컴포넌트를 추가하면 됨. 그래도 부족하면 ThreeJS로 수정하고, 셰이더까지 갈 수 있음. A-Frame은 훌륭함 게다가 AR과 VR도 할 수 있음 - 특히 이상한 기계학습 관점까지 붙이면서, 우리가 하는 모든 일을 커리어나 직업으로 바꾸려는 것처럼 느껴짐 “그래픽스 프로그래머가 되기”보다 그냥 **그래픽스 프로그래밍을 하기**는 어떨까? 간단한 것부터 해보다가 감이 오고, 결국 GPU에 물류를 보내는 일이라는 게 보이면 그 위에 온갖 복잡한 개념을 쌓을 수 있음 작은 산을 오르다가 갑자기 모든 게 딱 맞아떨어지고 “와…” 하게 되는 느낌임. 가능성과 실험할 것들이 보이기 시작함 - 그 표현이 꼭 커리어나 직업을 뜻한다고 보지는 않음. 오히려 정체성을 뜻하는 쪽에 가까움 “나는 암벽등반가다”, “게이머다”, “아티스트다”, “어머니다”, “아버지다”, “헬스장 죽돌이다”, “그래픽스 프로그래머다” 같은 말은 꼭 직업을 뜻하지는 않지만, 잠깐 스쳐가는 가벼운 관여보다는 더 깊은 무언가를 암시함 - 그 **레이 트레이싱 튜토리얼**을 열어 천천히 따라가는 중임. 예전부터 관심은 있었지만 해보지 못했음 오늘 PPM 이미지 형식을 배웠는데, 이런 용도에는 접근성이 아주 좋음. 비트맵 쓰기가 대단한 로켓 과학은 아니지만 PPM은 그보다도 더 쉬움