POOOLING FOREST
백엔드 개발자가 굳이 컴퓨터 그래픽스 기초를 다시 파는 이유 - 백엔드 개발자가 그래픽스 기초를 공부하며 얻은 통찰과 Scratchapixel 사이트를 통한 엔지니어링 원리
Engineering & Tech

백엔드 개발자가 굳이 컴퓨터 그래픽스 기초를 다시 파는 이유

백엔드 개발자가 그래픽스 기초를 공부하며 얻은 통찰과 Scratchapixel 사이트를 통한 엔지니어링 원리 이해의 중요성을 다룹니다.

김영태

테크리드

안녕하세요. 풀링포레스트 테크리드 김영태입니다.

솔직히 고백하자면, 저는 한동안 '화면에 점 하나 찍는 일'을 무서워했습니다. 인프라를 구축하고 대용량 트래픽을 처리하는 백엔드 로직은 자신 있었지만, 클라이언트 쪽에서 3D 모델이 깨지거나 렌더링 성능이 떨어진다는 이슈가 리포트되면 일단 등 뒤로 식은땀부터 흘렀으니까요. "그건 프론트엔드나 그래픽스 엔진 이슈 아닌가요?"라며 방어하기 급급했죠. 하지만 데이터 시각화 프로젝트를 리딩하면서 벽에 부딪혔습니다. 라이브러리가 해주는 '마법' 뒤에 숨어만 있으니, 정작 성능 최적화가 필요한 순간에 아무것도 건드릴 수 없더군요. 그때 만난 보석 같은 사이트가 바로 'Scratchapixel'입니다. 오늘은 이 사이트를 통해 제가 왜 그래픽스 기초를 다시 공부하게 되었는지, 그리고 이것이 우리 같은 백엔드 개발자에게 어떤 통찰을 주는지 이야기해 보려 합니다.

우리는 흔히 3D 그래픽스라고 하면 화려한 게임 엔진이나 복잡한 모델링 툴 사용법을 먼저 떠올립니다. 하지만 Scratchapixel은 접근 방식이 완전히 다릅니다. 이 사이트의 모토는 "처음부터(from scratch)"입니다. 이미 만들어진 API를 호출하는 게 아니라, 픽셀 하나가 어떻게 계산되어 모니터에 찍히는지 그 원리를 바닥부터 긁어줍니다.

가장 인상 깊었던 건 '3D 렌더링의 기초(The Foundations of 3D Rendering)' 섹션이었습니다. 보통 그래픽스 책을 펴면 첫 장부터 선형대수학 공식이 쏟아져 나와 책을 덮게 만드는데, 이곳은 접근이 실용적입니다. 이론을 먼저 장황하게 설명하기보다, 일단 코드를 보여주고 "자, 이렇게 하면 이미지가 나옵니다"라고 결과물을 먼저 제시합니다. 그 뒤에 왜 핀홀 카메라 모델이 필요한지, 좌표계 변환이 왜 일어나는지 역추적하며 설명하죠.

특히 레이트레이싱(Ray-Tracing) 파트를 보면서 무릎을 쳤습니다. 카메라에서 광선을 쏘아 픽셀 값을 계산하는 과정을 코드로 직접 구현해 보면, 이게 단순히 그림을 그리는 기술이 아니라는 걸 알게 됩니다. 결국은 엄청난 양의 연산 최적화 싸움이고, 메모리 관리 싸움이더군요. 우리가 백엔드에서 트래픽을 처리할 때 리소스를 어떻게 분배할지 고민하는 것과 본질적으로 다르지 않습니다.

'수학(Mathematics for Computer Graphics)' 섹션도 빼놓을 수 없습니다. 요즘 AI다 뭐다 해서 벡터 데이터베이스나 임베딩을 다룰 일이 많아졌습니다. 그런데 막상 벡터 내적이나 행렬 연산이 나올 때마다 개념이 흐릿해 당황했던 적 없으신가요? 이 사이트는 기하학, 행렬의 역행렬(가우스-조르단 소거법), 몬테카를로 방법 등을 그래픽스라는 구체적인 응용 사례와 함께 설명해 줍니다. 추상적인 수학 공식이 아니라, "이 수식이 있어야 조명을 이렇게 표현할 수 있다"는 식이라 훨씬 직관적으로 와닿습니다.

최근에는 'Vulkan 배우기(Learn Vulkan)' 코스도 새로 열렸더군요. Vulkan 같은 저수준 API는 진입 장벽이 높기로 유명하지만, 하드웨어를 극한까지 제어해 보고 싶은 개발자에게는 필독서와 같습니다. 또한, '무인도에 가져갈 책'이라는 컨셉으로 오프라인 서적 프로젝트도 준비 중이라니 기대가 됩니다.

물론 현업에서 우리가 직접 렌더러를 짤 일은 거의 없습니다. 하지만 원리를 아는 것과 모르는 것의 차이는 결정적인 순간에 드러납니다. 라이브러리가 뱉어내는 에러 로그가 외계어가 아니라 힌트로 보이기 시작하고, "이건 안 됩니다"라고 말하기 전에 "이 부분 연산 비용이 높으니 셰이딩 모델을 단순화합시다"라고 제안할 수 있게 됩니다.

개발자로서 성장 정체기를 겪고 있거나, 매일 쓰는 도구의 내부가 궁금해 잠 못 이루는 분들이라면 Scratchapixel을 일독해 보시길 권합니다. 단순히 그래픽스를 배우는 것을 넘어, 문제를 바닥부터 정의하고 해결해 나가는 엔지니어링의 정수를 맛보실 수 있을 겁니다. 저도 이번 주말에는 절차적 생성(Procedural Generation) 파트의 펄린 노이즈(Perlin Noise)를 보면서, 테스트 데이터를 좀 더 그럴듯하게 만드는 스크립트를 짜볼 생각입니다. 기술의 뿌리를 이해하는 즐거움, 여러분도 꼭 느껴보셨으면 좋겠습니다.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.