OpenGL

1992년 초에 컴퓨터 그래픽을 하드웨어 가속으로 처리(렌더링)함과 동시에 여러 분야에서 사용될 수 있도록 하는 범용성을 보장하기 위해 발표된 2D, 3D 그래픽 라이브러리이자 산업용 API로, 범용성이 있는 만큼 가장 광범위하게 사용되고 있다.

OpenGL 이전에는 1980년대 실리콘 그래픽스(SGI) 사에서 개발한 솔루션인 IRIS GL이 있었는데 여러 OS에서 사용할 수 있기 위해 필요한 범용성과 독립성을 고려하지 않고 만들었기 때문에 당시엔 하드웨어 뿐만 아니라 소프트웨어까지 제약이 심했던 솔루션이었다. 그래서 하드웨어와 운영체제에 제약을 받지 않는 범용적인 API 프로그래밍을 위한 OpenGL이 탄생하게 되었던 것.

2000년에 비영리 기술 컨소시엄인 크로노스 그룹이 설립되면서 GPGPU 병렬연산용 라이브러리인 OpenCL을 비롯한 다양한 용도의 라이브러리 및 API꾸러미로 확장 및 관리하기 시작했는데, 2006년 7월에 OpenGL도 크로노스 그룹에 의해 관리받는 것으로 전환되었다.

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

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

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

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

어지간한 그래픽 카드라면 둘 다 지원하는 경우가 많다. DirectX는 사실상 윈도우 전용이므로 타 운영체제(OS X, 리눅스 등)를 쓴다면 유일한 그래픽 라이브러리이기도 하다. 2010년대 시점에서는 일반인 시각으로 그놈이 그놈이다. 특히 안드로이드에서는 OpenGL이 메이저다.

OpenGL은 크게 GL, GLU(Utility)로 나눠져 있다. GL은 기본적인 함수들로 구성되어 있고, GLU는 GL을 좀 더 편히 사용할 수 있도록 도와주는 래핑 함수로 구성되어 있다. 참고로 GL과 GLU 둘 다 업데이트가 끊긴 지 오래되었기 때문에, 실질적으로 OpenGL을 사용하려면 GLEW 같은 외부 확장 라이브러리를 활용해야 한다.

사실 OpenGL은 API는 인터페이스와 기능의 명세일 뿐이라, 실제 그 구현체인 라이브러리는 하나의 플랫폼에도 여럿 존재할 수 있고, 플랫폼 마다도 구현이 달라서 디바이스 컨텍스트 생성 따위의 부분이 플랫폼마다 모두 달라 완전한 크로스플랫폼은 아니다. 이 때문에 실제로 화면에 뭔가를 나타내려면 대체로 추가 라이브러리를 사용해야 한다. 이 때 사용하는 것이 GLUT이다.[4][5][6] 이 외에도 SDL 등과 연동해서 사용하기도 하는데 이는 대부분 크로스플랫폼을 지원한다.

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

관련 교재와 서적으로는 Red Book과 Blue Book(레퍼런스 매뉴얼), Orange Book, Superbible이 대표적이다.

애플이 매우 사랑하여[7] OS X[8]의 모든 시스템 그래픽은 OpenGL로 가속되어 표시된다.[9] 그러나 OpenGL 4.1 버전 이후 드라이버 업데이트를 전혀 하지 않아 애플 환경에서 OpenGL을 이용하는 개발자들에게 원성을 사고 있다가, WWDC 2014에서 자체 개발한 그래픽 라이브러리인 Metal 라이브러리를 새로 공개하였고, WWDC 2015에는 macOS용 Metal 라이브러리를 추가 공개하면서 앞으로의 macOS, iOS, tvOS용 앱들이 Metal 라이브러리로 개발될 것이라 발표하였다. 안드로이드, 리눅스 등의 타 플랫폼에서는 여전히 OpenGL을 사용하고 있지만, 모바일 시장의 한 축이었던 iOS에서의 점유율은 확실히 잃어버리게 되었다. 언리얼 엔진, 유니티 엔진 등의 주요 게임 엔진들은 Metal을 정식 지원하고 있다.

2015년 3월, 차세대 OpenGL인 Vulkan이 최초 공개되었다.

최신 버전은 2017년 7월 31일 발표된 4.6 버전이다. #

2.0 버전부터 GLSL을 이용한 셰이더 프로그래밍 언어를 정식으로 지원하기 시작했으나 사실, 셰이더 프로그래밍 언어 자체는 OpenGL의 탄생과 함께 시작되었다. 초기에는 ARB AL라고도 부르는 Architecture Review Board 어셈블리 언어가 그것으로 벤더 입장인 하드웨어 제조사들을 주도로 추가된 확장 기능 컨셉[14]이다보니 OpenGL이 그렇게 중요시 하던 범용성이 무시되었기 때문에 어떤 그래픽카드에서는 잘 돌아가고 다른 어떤 그래픽카드에서는 돌아가지 않는 등 전체적으로 중구난방일 수밖에 없었으며, 1998년 1.2.1 버전에 들어서야 범용성이 있는 ARB_multitexture 명령어를 시작으로 2001년 1.3 버전부터 ARB가 붙여진 공식 확장 기능들이 대거 추가되었지만[15] 결정적으로 어셈블리어로 다뤄야 하다보니 진입장벽이 엄청 높았다.

개념 자체는 2000년 11월에 발표된 MS의 DirectX 8.0의 셰이더 어셈블리 언어보다 8년 이상 먼저 내세운 것에 의의 있는 셰이더 프로그래밍 언어라고 볼 수 있지만 2002년에 MS가 진입장벽을 대폭 낮춘 고수준 셰이더 프로그래밍 언어인 HLSL을 재빠르게 발표함으로써 OpenGL 측에서도 2004년에 이와 비슷한 개념을 지닌 GLSL이 발표되었다. 2.0 버전까진 셰이더 프로그래밍 언어를 이용하지 않는 이전의 방식으로도 화면에 폴리곤을 출력할 수 있었지만, 3.0 버전부터는 GLSL을 사용하지 않으면 화면에 폴리곤을 출력할 수 없게끔 필수가 되었다.

교육기관 등에서는 최신버전을 숙지하기 위해서는 구버전부터 개념을 익히는게 중요하다는 명목으로 아직도 1.0 버전을 가지고 수업을 하고 있는 경우가 많다.[16] OpenGL 1.0은 폴리곤 연산 등 개념만 익히는 것을 추천하고 실무 개발시에는 OpenGL 1.x 대나 2.x 대를 사용한 개발은 추천하지 않는다.

OpenGL 3.x 부터 많은 개선이 있었으며, 테셀레이션 기능이 제외된 3.3 버전을 쓸 수 없는 정 여의치 않는 상황이라면 최소한 고수준 셰이더 프로그래밍 언어를 사용할 수 있는 2.0 버전 이상을 사용하여 개발하는 것이 추천된다. 대표적인 차이로 2.0까지는 primitives를 그릴 때 glBegin()과 glEnd()를 사용하는 것에 비해, 3.0 이후부터 이 기능은 Deprecated 되었다. glBegin()의 대표적인 문제점으로는 멀티코어 프로세서가 대중화된 현대 컴퓨팅 환경에서 병렬 처리가 거의 불가능하다는 점을 꼽을 수 있으며 각 오브젝트를 그려 낼 때 glBegin()을 호출해야 하므로 오버헤드 문제가 일어났기 때문이다.

이 때문에 OpenGL 2.0 이전과 3.0 이후는 OpenGL의 큰 틀을 공유하긴 하지만, DirectX 9 이전과 10 이후의 차이처럼 렌더 파이프라인 구조의 차이가 있는 개선된 API라고 보는 편이 좋다. 다른 비유로 C++98과 C++11의 관계라고 볼 수 있다.

특히 이런 레거시 OpenGL의 가장 큰 문제는 고정 파이프라인을 사용하는데다 일반 소비자용 그래픽카드 들의 드라이버에 해당 성능을 제한을 걸어 둔 관계로 쿼드로나 라데온 프로와 같은 워크스테이션용 드라이버에서 내는 성능에 비해 아주 처참한 성능이 나오게 된다.
그에 비해 셰이더 기반을 사용하는 모던 OpenGL 3.0 이후의 경우 소비자용 그래픽카드 에서도 성능차이가 없거나 오히려 더 높다. Viewport 2.0 가 포함된 Autodesk Maya(3.2)나 Cinema 4D(4.1), Blender(3.3), 또는 둠(2016)(4.6)이 그 예.

그리고 Vulkan이 상대적으로 개발하기 어렵고 하위 호환도 지원하지 않는 상황이라, OpenGL을 활용한 프로젝트가 아직 더 많이 개발되고 있다. 이는 DirectX 12도 마찬가지로, DirectX 11과 12가 투 트랙으로 개발되고 있으며 현재까지는 DirectX 11의 사용 빈도가 더 높은 상황이다.

그렇지만, OpenGL이 지속적으로 업데이트 되면서 최신 하드웨어의 기능을 지원해 나갈 것인가에 대해서는 회의적이다. 예를 들어 NVIDIA의 RTX 그래픽카드가 지원하는 레이트레이싱 가속 기능의 경우, Vulkan과 DirectX12 버젼의 API는 만들었지만, OpenGL의 경우 지원하지 않는다. OpenGL의 경우 이를 활용하려면 Cuda 기반의 Optix(Nvidia 자체 API)를 사용해 레이트레이싱 가속 기능을 사용한 뒤, OpenGL에서 결과물 이미지만 받아온 후 그려야 한다. 파이프라인을 재구성하기 어려운 OpenGL의 특성 때문인듯 하다. 물론, 또 다른 RTX 그래픽카드의 특징인 Mesh Shader의 경우 파이프라인을 재구성해야 했음에도 불구하고 OpenGL도 지원을 해주었지만, 레이트레이싱 가속 기능은 그렇지 않다.

최신 버전은 2015년 8월에 발표한 3.2 버전이다. 임베디드 시스템 등에서 사용할 수 있게 몇 가지 잘 사용되지 않는 함수를 제거한 API. 안드로이드 시스템과 iOS에서 그래픽 가속을 위해 사용된다.

OpenGL ES 1.0은 OpenGL 1.3을, OpenGL ES 1.1은 OpenGL 1.5를, OpenGL ES 2.0은 OpenGL 2.0을 베이스로 만들어졌다. 다만, OpenGL ES 2.0은 OpenGL 2.1 버전까지 사용 가능했던 고정 파이프라인이 제거[17]되었기 때문에 사실상 GLSL이 필수가 된 OpenGL 3.0과 비슷하게 사용된다. OpenGL ES 3.0은 OpenGL 4.3을 베이스로 만들어졌다.

이 문서를 참고.