1년 전 올린 내 글 이후로도 Vulkan에 대한 내 생각은 크게 바뀌지 않았음
저수준 그래픽스 제어를 원하는 사람에게는 흥미롭겠지만, 나에게는 정말 사용하기 괴로운 API였음
게임 엔진을 직접 만들어보고 싶다는 생각은 여전하지만, Vulkan의 초기 설정조차 여전히 두려움
내가 원하는 건 SDL이 2D 그래픽을 다루는 방식의 3D 버전 같은 것임
SDL에서 3D를 하려면 결국 OpenGL로 내려가야 하는데, 그건 내가 바라는 수준이 아님
어쩌면 WebGPU가 내가 즐겁게 다룰 수 있는 대안일지도 모름
SDL 3.0이 1년쯤 전에 GPU API를 도입했음. Vulkan 등 여러 백엔드를 감싸는 추상화 레이어라서 확인해볼 만함
나도 그걸로 엔진을 하나 만들었지만, 결국 더 많은 제어와 성능을 원해서 Vulkan 기반 엔진으로 돌아갔음
그래도 SDL GPU 코드에서 동기화 패턴을 배워서 Vulkan 엔진에서 큰 도움이 되었음
Rust의 wgpu는 WebGPU 수준의 추상화를 제공하는 중간 지점임
OpenGL보다 강력하지만, 리소스 배리어나 레이아웃 전환 같은 세부 사항을 직접 다룰 필요가 없음
런타임에서 일부 bookkeeping을 대신 해주고, 단일 큐만 지원하는 등의 제약이 있음
Vulkan은 힘들지만, 주요 벤더들이 지원하는 확장 기능을 쓰면 꽤 개선됨
다만 드라이버들이 무시하는 세부 설정을 요구하는 등, 여전히 불필요한 복잡성이 존재함
오래된 OpenGL 프로그래머로서 완전히 공감함
지금은 고수준 게임 엔진과 저수준 Vulkan/Metal 사이의 중간 API가 사라진 상태임
초보자가 3D 그래픽을 배우려면 셰이더나 버퍼 같은 개념을 몰라도 되는, 단순한 “삼각형 그리기” 수준의 API가 필요함
Vulkan의 세세한 제어는 극소수의 엔진 개발자에게만 필요하고, 대부분은 OpenGL 수준이면 충분함
“SDL 같은 3D”를 만들려는 시도는 금세 풀스택 엔진으로 커짐
3D는 2D보다 조합 가능한 요소가 훨씬 많아서, 단순한 그래픽 API로는 감당이 어려움
OpenGL도 원래 그걸 목표로 했지만, 결국 복잡해졌음
‘bike shedding’은 사소한 문제에 집착하면서 중요한 부분을 놓치는 행위를 뜻함
원문에서 묘사한 건 오히려 feature creep이나 over-engineering에 가까움
저자라면 “hobby horsing”이라는 표현도 쓸 수 있었을 것임
프로젝트 진전을 막고 개인적 즐거움에만 집중하는 행위를 뜻함
bike shedding은 흔히 “집 완성 전 자전거 창고 색깔부터 정하는 것”으로 설명됨
“bike shedding”이라는 단어 자체를 두고 bike shedding하고 있는 셈임
“Minecraft 멀티플레이어 클론으로 엔진 개발을 시작하는 건 좋지 않다”는 말이 있었지만,
사실 많은 사람들이 첫 엔진 프로젝트로 Minecraft류 게임을 만듦
복셀 엔진에서는 그게 일종의 “Hello, world”임
Vulkan은 내가 배운 것 중 가장 어려운 기술이었음
너무 비직관적이고 반복 작업이 많아서 프로그래밍의 즐거움을 앗아감
네가 머리가 작은 게 아님. Vulkan은 저수준 칩 추상화 API라서 USB API만큼 재미없음
더 간단하게 시작하려면 OpenGL(특히 셰이더 도입 전 버전)을 추천함
하지만 업계는 OpenGL을 점점 밀어내는 중임
나도 처음 Vulkan을 배울 때 완전히 같은 느낌이었음
튜토리얼을 따라가며 코드를 베끼기만 했지 개념을 이해하지 못했음
그래서 WebGPU(Google Dawn) 로 전환했는데, Vulkan보다 훨씬 단순했음
WebGPU의 제약 덕분에 개념을 익히고 나서 다시 Vulkan을 배우니 훨씬 수월했음
WebGPU는 push constant가 없고 pipeline 폭발 문제가 있지만, Vulkan은 동기화와 메모리 관리가 더 어려움 SDL_GPU도 비슷한 수준의 API라 입문용으로 좋음
내가 아직 OpenGL에서 Vulkan으로 넘어가지 않은 이유도 같음
Vulkan은 과도하게 설계된 API임
CUDA에서는 한 줄로 가능한 GPU 메모리 할당이 Vulkan에서는 수많은 보일러플레이트를 요구함
최신 Vulkan이 많이 개선됐지만 여전히 갈 길이 멂
일반적인 Vulkan 코드 예시를 보면, 이건 게임 개발자용이 아님을 바로 알 수 있음
SDL3나 wgpu가 이 복잡성을 덜어주는 추상화 계층이 되길 바람
Valve가 SDL3를 지원하니 그쪽이 유력하다고 생각함
Vulkan/DX12 프로그래밍은 정말 고통스러움
“그래픽을 멀티스레드로 처리해야 하는가?”라는 질문을 먼저 해야 함
아니라면 Vulkan/DX12를 쓸 이유가 없음
성능 문제가 생기기 전까지는 OpenGL, DX11, 혹은 게임 엔진을 쓰는 게 훨씬 나음
나는 3D/게임 프로그래밍에 매료되어 있고, 몇몇 유튜버들이 게임을 만드는 과정을 자주 봄
하지만 웹앱이나 DevOps에 비해 훨씬 복잡한 세계임
픽셀 셰이더, 계산 셰이더, 기하학, 선형대수, PDE까지 등장함 TokyoSpliff 유튜브 채널
요즘 취미로 게임 엔진을 만드는 게 멋진 일로 여겨지는 게 좋음
나도 10년째 개인 엔진을 개발 중인데, 매우 보람찬 경험이었음
그래픽 프로그래밍을 처음 한다면 OpenGL부터 시작하는 게 좋음
23년 전 NeHe의 OpenGL 튜토리얼을 읽었는데, 지금도 가장 잘 구성된 학습 자료 중 하나라고 생각함
Hacker News 의견
1년 전 올린 내 글 이후로도 Vulkan에 대한 내 생각은 크게 바뀌지 않았음
저수준 그래픽스 제어를 원하는 사람에게는 흥미롭겠지만, 나에게는 정말 사용하기 괴로운 API였음
게임 엔진을 직접 만들어보고 싶다는 생각은 여전하지만, Vulkan의 초기 설정조차 여전히 두려움
내가 원하는 건 SDL이 2D 그래픽을 다루는 방식의 3D 버전 같은 것임
SDL에서 3D를 하려면 결국 OpenGL로 내려가야 하는데, 그건 내가 바라는 수준이 아님
어쩌면 WebGPU가 내가 즐겁게 다룰 수 있는 대안일지도 모름
나도 그걸로 엔진을 하나 만들었지만, 결국 더 많은 제어와 성능을 원해서 Vulkan 기반 엔진으로 돌아갔음
그래도 SDL GPU 코드에서 동기화 패턴을 배워서 Vulkan 엔진에서 큰 도움이 되었음
wgpu는 WebGPU 수준의 추상화를 제공하는 중간 지점임OpenGL보다 강력하지만, 리소스 배리어나 레이아웃 전환 같은 세부 사항을 직접 다룰 필요가 없음
런타임에서 일부 bookkeeping을 대신 해주고, 단일 큐만 지원하는 등의 제약이 있음
Vulkan은 힘들지만, 주요 벤더들이 지원하는 확장 기능을 쓰면 꽤 개선됨
다만 드라이버들이 무시하는 세부 설정을 요구하는 등, 여전히 불필요한 복잡성이 존재함
지금은 고수준 게임 엔진과 저수준 Vulkan/Metal 사이의 중간 API가 사라진 상태임
초보자가 3D 그래픽을 배우려면 셰이더나 버퍼 같은 개념을 몰라도 되는, 단순한 “삼각형 그리기” 수준의 API가 필요함
Vulkan의 세세한 제어는 극소수의 엔진 개발자에게만 필요하고, 대부분은 OpenGL 수준이면 충분함
3D는 2D보다 조합 가능한 요소가 훨씬 많아서, 단순한 그래픽 API로는 감당이 어려움
OpenGL도 원래 그걸 목표로 했지만, 결국 복잡해졌음
‘bike shedding’은 사소한 문제에 집착하면서 중요한 부분을 놓치는 행위를 뜻함
원문에서 묘사한 건 오히려 feature creep이나 over-engineering에 가까움
프로젝트 진전을 막고 개인적 즐거움에만 집중하는 행위를 뜻함
bike shedding은 흔히 “집 완성 전 자전거 창고 색깔부터 정하는 것”으로 설명됨
“Minecraft 멀티플레이어 클론으로 엔진 개발을 시작하는 건 좋지 않다”는 말이 있었지만,
사실 많은 사람들이 첫 엔진 프로젝트로 Minecraft류 게임을 만듦
복셀 엔진에서는 그게 일종의 “Hello, world”임
(2024) 당시 게시물은 625포인트, 260댓글을 기록했음 — 원문 링크
Vulkan은 내가 배운 것 중 가장 어려운 기술이었음
너무 비직관적이고 반복 작업이 많아서 프로그래밍의 즐거움을 앗아감
더 간단하게 시작하려면 OpenGL(특히 셰이더 도입 전 버전)을 추천함
하지만 업계는 OpenGL을 점점 밀어내는 중임
튜토리얼을 따라가며 코드를 베끼기만 했지 개념을 이해하지 못했음
그래서 WebGPU(Google Dawn) 로 전환했는데, Vulkan보다 훨씬 단순했음
WebGPU의 제약 덕분에 개념을 익히고 나서 다시 Vulkan을 배우니 훨씬 수월했음
WebGPU는 push constant가 없고 pipeline 폭발 문제가 있지만, Vulkan은 동기화와 메모리 관리가 더 어려움
SDL_GPU도 비슷한 수준의 API라 입문용으로 좋음
Vulkan은 과도하게 설계된 API임
CUDA에서는 한 줄로 가능한 GPU 메모리 할당이 Vulkan에서는 수많은 보일러플레이트를 요구함
최신 Vulkan이 많이 개선됐지만 여전히 갈 길이 멂
SDL3나 wgpu가 이 복잡성을 덜어주는 추상화 계층이 되길 바람
Valve가 SDL3를 지원하니 그쪽이 유력하다고 생각함
“그래픽을 멀티스레드로 처리해야 하는가?”라는 질문을 먼저 해야 함
아니라면 Vulkan/DX12를 쓸 이유가 없음
성능 문제가 생기기 전까지는 OpenGL, DX11, 혹은 게임 엔진을 쓰는 게 훨씬 나음
나는 3D/게임 프로그래밍에 매료되어 있고, 몇몇 유튜버들이 게임을 만드는 과정을 자주 봄
하지만 웹앱이나 DevOps에 비해 훨씬 복잡한 세계임
픽셀 셰이더, 계산 셰이더, 기하학, 선형대수, PDE까지 등장함
TokyoSpliff 유튜브 채널
요즘 취미로 게임 엔진을 만드는 게 멋진 일로 여겨지는 게 좋음
나도 10년째 개인 엔진을 개발 중인데, 매우 보람찬 경험이었음
그래픽 프로그래밍을 처음 한다면 OpenGL부터 시작하는 게 좋음
23년 전 NeHe의 OpenGL 튜토리얼을 읽었는데, 지금도 가장 잘 구성된 학습 자료 중 하나라고 생각함
참고로, 나는 원글 작성자가 아니며 제목만 유지했음