OpenGL(Open Graphics Library)

open gl

OpenGL을 최초 개발한 개발사는 실리콘 그래픽스이고 개발사는 크로노스 그룹이다. 크로노스 그룹은 2000년에 설립된 비영리 산업체로, 로열티 제한이 없는 오픈 소스이면서 표준 API의 제작을 통해 다양한 플랫폼과 장치에서 동적인 미디어의 가속화된 재생 및 저작이 가능하여지도록 만드는 것이 주목적이다. 크로노스 그룹에 가입된 모든 업체는 크로노스 그룹에서 제시한 API 규격의 개발에 기여할 수 있고, 공개적인 이용 이전에 다양한 단계에서 투표할 권한이 있으며, 규격 초안과 순응 테스트로 쉽게 접근할 수 있기에 최첨단 3차원 플랫폼 및 응용 프로그램을 빠르게 전달할 수 있는 걸로 알려졌다. 다양한 플랫폼에서의 구현을 위한 엄격한 기준을 통과해야 발표할 수 있고, 사용자들이 이용하는 특정 소프트웨어 환경을 개발한 업체들이 이를 지원해줘야 비로소 사용자가 사용할 수 있다. 일반 영리 업체에서 제공하는 API만큼 빠른 개선이 어렵고, 범용성을 지향하기 때문에 특정 용도에는 상대적으로 불친절한 가이드가 태생적인 단점으로 지목되고 있다. 1992년 6월 30일에 출시되었으며 C언어를 사용한다.

1992년 초에 컴퓨터 그래픽을 하드웨어 가속으로 처리(렌더링)함과 동시에, 여러 분야에서 사용될 수 있도록 하는 범용성을 보장하기 위해 발표된 2D, 3D 그래픽 API의 규격서. 범용성이 있는 만큼 가장 광범위하게 사용되고 있다. 이름과는 달리 구현물은 없고 따라서 작동하는 라이브러리는 아니다. API 규격에 대해 정의만 할 뿐이다.

그래픽 쪽을 배울 때는 꼭 접하게 된다. DirectX의 라이벌 격이라고 할 수 있다. 다만 DirectX는 그래픽뿐만 아니라 사용자 입력과 포스 피드백 같은 컨트롤러 제어, 음향 쪽도 아우르고 있어 OpenGL과 1:1로 대응되지 않는다. OpenGL은 순수하게 그래픽 출력만을 담당하니까. 순수하게 OpenGL과 대응되는 부분은 DirectX 컴포넌트의 일부인 Direct3D다.

초창기에는 Microsoft에서도 OpenGL을 지원했다. 현재까지도 그래픽카드 도움 없이 소프트웨어 렌더링인 CPU 가속으로는 OpenGL 1.1까지 지원한다. 그러다가, 독자 솔루션인 DirectX를 내놓으면서 Microsoft는 OpenGL은 전문가 산업용, DirectX는 가정용 컴퓨터 게임 그래픽용이라는 기믹을 만들어 퍼뜨렸는데 존 나맥이 OpenGL이 DirectX보다 훨씬 편리하게 게임에 사용이 가능하다고 직접 코드를 보이면서 글을 올렸고, MS는 존 카맥이 사용하기 힘들다면 다른 누구에게도 힘든 게 바르다면서 꼬리를 내렸다. 그러나, 1998년 초 1.2 버전 이후 OpenGL은 3년 가까이 개선 과정 없이 거듭된 문제를 터뜨렸고 DirectX는 1999년 하반기에 발표한 7.0 버전에서 크게 발전하여 결국 역전되고 말았다. 존 카맥도 이제는 DirectX가 더 낫다고 발언한 상황. 저 원인으로 Microsoft의 음모론을 이야기하는 사람도 있는데, OpenGL 위원회에 Microsoft 측 사람이 껴있긴 했지만 딱 한 명밖에 없어서 가능성은 희박하다. 그리고, 만약 저 한 명으로 인해 그런 짓을 터뜨린 거라면 그건 그냥 OpenGL 쪽이 무능하다는 얘기밖에 안 된다.

어쨌건 지금은 OpenGL도 절치부심해서 빠르게 발전하고 있으며, 특히나 모바일 게임시장이 뜨고 Microsoft가 거기서 지지부진한 상황에서 상당한 우세를 보여주고 있다. 과거 하드웨어 T&L 시절에 비하면 트렌드에 뒤처지지 않을 정도로 잘 개선되고는 있지만, OpenGL 자체가 게임을 비롯한 멀티미디어만을 위한 존재가 아닌 만큼 고려해야 할 영역이 많은 API이다 보니 특정 업체인 Microsoft가 본래 Windows 게임을 위해 개발했던 DirectX보다 앞선 기술을 채택하기 어려울 수밖에 없다는 점을 어느 정도 이해해야 할 필요가 있다. 90년대 중반까지 DirectX보다 OpenGL이 더 우위였던 건 그래픽 API에 있어서 DirectX가 OpenGL보다 3년 늦게 발표된 후발 주자였기 때문에 가능했을 뿐이다.

현시점에서 OpenGL의 가장 큰 문제는 드라이버이다. 25년이 넘는 동안 OpenGL 스펙에 추가된 기능들이 엄청나게 많고 과거 1. x 시절의 API부터 4. x에 추가된 최신 API까지 드라이버에서 전부 지원하는 동시에 300여 개에 달하는 확장기능까지 제공해줘야 하는데, 이에 따라 드라이버의 복잡도는 상상을 초월하는 수준이다. 당연히 드라이버의 품질도 심각하게 뒤떨어질 수밖에 없다. Direct3D처럼 관리주체의 드라이버 통제를 기대할 수 없기 때문에 드라이버의 퀄리티는 순전히 GPU 제조사에 달려 있다. 이러한 이유로 OpenGL 프로그래밍은 각종 GPU 드라이버 버그의 지뢰밭을 살금살금 피하면서 개발하는 과정의 연속이다. 사실상 무늬만 크로스플랫폼인 셈. Chrome은 Windows 버전의 경우 OpenGL을 직접 사용하는 것을 포기하고 OpenGL 명령을 Direct3D로 변환해서 돌리는 ANGLE이라고 불리는 중간 레이어를 개발해서 사용하고 있으며 그 외 플랫폼의 경우 수백개에 달하는 드라이버 버그들을 하나하나씩 우회하는 엄청나게 복잡한 렌더링 패스가 구현되어 있다. 크로노스 그룹이 OpenGL을 놔두고 Vulkan을 만든 가장 큰 이유도 사실 이것이다. 도저히 드라이버가 관리가 안 되는 수준까지 왔기 때문. 그래서 Vulkan은 스펙을 최소화해서 드라이버의 역할을 최대한 줄이고 프로그래머들에게 많은 것을 위임하도록 설계되어 있다. 다만, 이에 따라 Vulkan의 개발 난도는 엄청나게 올라가 버렸다. OpenGL의 그 외의 문제로는 전역 상태 머신 기반이라 멀티스레딩을 온전하게 사용할 수 없으며 상태 기계의 내용을 추적하기 힘들기 때문에 버그를 만들기 쉽다는 점이 있다. 아무래도 API의 기본 틀은 1990년대 초반에 만들어진 것이니만큼 아무래도 요즘 프로그래밍 트렌드와 동떨어진 부분이 있다.

대부분의 3D 그래픽이 그렇지만, 특히 OpenGL은 저급 수준 API이기 때문인 거의 모든 걸 수동으로 해줘야 해서 깊이 있게 사용하려면 어느 정도 수학과 친해져야 한다. 최소한 공대 수준의 선형대수학과 미분기하학은 이해하고 있어야 하는데, 컴퓨터공학과 특성상 이산수학을 제외하면 대학 레벨의 수학을 거의 배우지 않는 경우가 많기도 하고, 신기술이 추가되면서 요구하는 수학 수준이 점점 올라가는 추세라는 점이 문제다. 단순히 API를 가져다 쓰는 정도라면 기초 미적분과 벡터 수준의 지식만 가지고도 되기는 하겠으나, 피상적인 접근에만 머무르게 될 것이다. 물론 그래픽스 자체를 연구하는 게 아니라면 그 정도로도 별문제 없기는 하다.