← 블로그 목록

DirectX 9는 왜 당시 윈도우 게임 개발자들에게 큰 사건이었나

Microsoft가 DirectX 9.0에서 고급 셰이더 언어와 더 강한 그래픽 프로그래밍 기능을 밀어붙이면서, 윈도우 게임 개발의 기준이 한 단계 올라갔다.

DirectX 9는 왜 당시 윈도우 게임 개발자들에게 큰 사건이었나

DirectX 9는 왜 당시 윈도우 게임 개발자들에게 큰 사건이었나

지금 기준으로 보면 DirectX 9는 오래된 기술처럼 보인다. 하지만 2000년대 초 윈도우 게임 개발자들에게 DirectX 9.0은 꽤 큰 전환점이었다. Microsoft는 2003년 1월 DirectX 9.0을 소개하면서, 고급 셰이더 언어와 더 확장된 프로그래머블 그래픽스 기능을 전면에 내세웠다.

핵심은 단순한 버전 업이 아니었다. 개발자가 그래픽 하드웨어를 더 직접적으로, 그리고 더 높은 수준의 언어로 다룰 수 있게 됐다는 점이 중요했다.


가장 큰 변화는 HLSL이었다

Microsoft는 DirectX 9.0의 핵심으로 고급 셰이더 언어(High-Level Shader Language, HLSL)를 강조했다. 이전에도 버텍스 셰이더와 픽셀 셰이더는 있었지만, HLSL은 이를 더 사람이 읽기 쉬운 형태로 작성하고 툴체인과 연결할 수 있게 해 주었다.

당시 공식 소개문에서도 HLSL은 C 언어 계열 문법을 바탕으로, 다양한 그래픽 하드웨어에서 비슷한 시각 효과를 더 쉽게 만들 수 있게 해 주는 환경으로 설명된다. 이건 현업 개발자 입장에서는 꽤 컸다. 셰이더를 더 적극적으로 쓰는 게임이 늘어나기 시작했고, 렌더링 파이프라인을 만지는 방식도 바뀌었다.


DirectX 9는 “더 멋진 화면”만 뜻하지 않았다

DirectX 9.0을 이야기할 때 흔히 그래픽 품질만 떠올리지만, 실제 의미는 조금 더 넓다.

즉 DirectX 9는 “눈에 띄는 그래픽 효과가 많아졌다”는 결과만이 아니라, 윈도우 게임 그래픽 프로그래밍의 작업 방식이 더 본격적인 셰이더 중심으로 이동했다는 의미를 가진다.


그래서 당시 개발자들이 다시 공부해야 했던 것이다

DirectX 9 시대의 개발자는 단순히 API 함수 호출만 아는 수준으로는 부족해졌다. 셰이더를 이해해야 했고, GPU가 어떤 계산을 맡는지 알아야 했으며, 고정 기능 파이프라인 중심 사고에서 조금씩 벗어나야 했다.

물론 그 변화가 하루아침에 모든 스튜디오를 바꾼 것은 아니었다. 하지만 이후의 DirectX 10, 11, 12로 이어지는 흐름을 보면, DirectX 9는 확실히 그 방향을 굳힌 버전이었다. 오늘의 실시간 렌더링 파이프라인을 당연하게 여긴다면, 그 출발선 가운데 하나가 이 시기라고 봐도 무리가 없다.


핵심 정리

DirectX 9.0이 중요했던 이유는 단순히 새 SDK가 나왔기 때문이 아니다. HLSL과 프로그래머블 셰이더 모델이 전면에 등장하면서, 윈도우 게임 개발이 더 본격적인 GPU 프로그래밍 시대로 넘어가는 계기가 되었기 때문이다.

당시 개발자들이 “다시 공부해야 한다”고 느꼈던 것도 당연했다. API 하나를 더 배우는 수준이 아니라, 그래픽을 만드는 사고방식 자체가 바뀌는 시기였기 때문이다.

참고 자료

← 목록으로
Related

함께 읽으면 좋은 글

Unreal EngineDirectX렌더링
언리얼 엔진을 쓴다면 DirectX를 꼭 배워야 할까

언리얼 엔진만으로도 게임을 만들 수 있는데 굳이 DirectX를 공부해야 할까? 두 기술의 관계를 정확히 이해하고, 언제 DirectX 지식이 필요한지, 어떤 순서로 학습하는 것이 현실적인지 정리한다.

게임 개발그래픽스컬링
컬링은 안 보이는 것을 덜 그려서 3D 장면을 버티게 만드는 기본 최적화다

3D 장면이 무거울 때는 폴리곤 수를 줄이는 것 못지않게 보이지 않는 것을 일찍 걸러내는 일이 중요하다. 백페이스, 프러스텀, 오클루전 컬링은 비슷해 보여도 해결하는 문제가 서로 다르고 비용 구조도 다르다. 안 보이는 이유가 방향 때문인지, 시야 밖이기 때문인지, 가려졌기 때문인지 구분해서 적용해야 한다는 점을 OpenGL과 Unity 문서를 함께 정리한다.

게임 개발반복 개발플레이테스트
게임 개발의 품질은 한 번의 완성보다 테스트와 수정이 반복되는 루프에서 나온다

게임의 품질은 처음부터 잘 짠 설계가 아니라 빨리 만들고 시험하고 고치는 루프의 건강함에서 나온다. 테스트는 버그 잡기보다 이 선택이 맞는가를 확인하는 질문 검증에 가깝고, 좋은 팀은 가설과 빌드, 플레이테스트, 수정, 재검증을 짧게 반복한다. 결국 좋은 게임은 정답을 처음부터 아는 팀이 아니라 더 빨리 배우는 팀이 만든다.