1. 30년 가까이 된 설계로 C++ 마냥 덕지덕지의 끝장판을 달림. 기존 고정 파이프라인 API 도 있고, 3 이후 버전부터 나온 프로그래머블 파이프라인도 다 제공하고 있어서 C++ 랑 C랑 스까하듯이 섞어서 써버릴 수도 있음. 이게 아이러니컬하게 입문 장벽을 올려버림.


2. GL 컨텍스트를 만들어야 GL 을 쓸 수 있는데, 이 컨텍스트를 만들어서 바인딩하는데 플랫폼마다 다 다르니 너무 빡셈. 물론 Vulkan 도 이것의 운명에서는 벗어날 수...는 없지만 그나마 약간 낫다.


3. OpenGL 은 D3D12 나 D3D11, D3D10, Vulkan 과는 다르게 컨텍스트마다 내부의 상태머신이라는 것이 있어서, 이 상태머신을 잘못 짚고 하다가는 에러를 뿜어냄. 그렇다고 상태머신의 상태를 쿼리하는 API 의 설계가 좋냐? 하면 그것도 아닌게 glGet... 시리즈로 대표되는 API 들과 거기에 맞춰서 쓰는 GLenum 타입들이 알아보기 쉽게 설계된 것도 아니라서 눈물짜게 함


4. OpenGL 설계 자체가 OOP 적인 것과는 상당히 거리가 멈. OOP 스럽게 쓰겠다? 하면 코어단에서 알아서 랩핑해서 쓸 수 있도록 해줘야함. Vulkan 은 내부 상태머신 없고, 알아서 다 해주세요 지향이라서 OOP 적으로 짠다고 하면 GL 보다는 조금 나을지도...


5. glGetError() 라고 GL 쪽에서도 에러 코드 enum 을 반환하는 API 가 있는데, 어떻게 쓰라는지 명확히 안되있어서 GL을 사용한 앱들이 다 지맘대로 쓰고 있음. 글타고 Vulkan 의 Validation Layer 같은 디버그 계층같이 잘못 인자를 넣었을 때 에러로그가 자동으로 튀어나오냐하는것도 아님. + GL 에서 발생한 에러들은 이 역시 내부 컨텍스트의 에러 큐에 차곡차곡 저장이 되는데, 저장만 될 뿐 이걸 꺼내쓰던가 말던가 하는 것 역시 프로그래머 마음이라서 혼파망되기 쉬움.


6. OpenGL 에 각종 익스텐션 (ARB, AMD, NV) 이 있는데, 드라이버마다 지원하는게 다 달라서 뭘 적절히 써야할 지 힘듦. 그냥 일반 펑션써도 되긴 하는데 이러면 성능이 안나온다고들. 같은 얘기긴 한데 OpenGL 에 너무 많은 입김들이 달라붙어서 문어발이 된 것 같다.


7. OpenGL 자체가 멀티스레드를 지원할려는 의지가 없어보임. 최근 들어서는 어토믹 변수, 배리어 같은 것들이 들어와 있긴 한데, 설계 한계상 이거 써서 돌리는 것보다 그냥 싱글로 돌리는게 낫다고들. 설계 한계때문에 천장이 명확한 것 같음. D3D11 이나 D3D12 나 아님 Vulkan 쓰는게 나을 지경이라 함.


8. 위의 컨텍스트의 암묵적인 상태머신 스위칭 때문에, gl 함수를 잘못 썼다가는 에러가 일어나고, 이 에러를 찾느라 몇시간 써야할 수도 있음. 에러 로깅하면 되지 않느냐 아니면 glGetError() 써서 에러코드 받아오면 되지 않겠느냐 할 수도 있는데, 에러 로깅 => 드라이버마다 안될 수 있음. glGetError() => 전역 에러 관리 상태머신에서 뽑아오는 거이고 어디서부터 잘못되었는지 말해주지 않음. 조트망


9. OpenGL 3 의 API 들은 그나마 문서화나 예제들이 잘 되어있는데, 4 이상의 API 들은 급격하게 줄어들음. 문제는 4 나오고 4.3 나온지가 2012년 해서 이제 7년 째인데 미비하다는거. 찾아서 볼 때가 공식 문서 사이트밖에 없고, 자세하게 설명하지도 않음.


플젝 마무리 작업하다가 열뻗혀서 싸질렀는데... 진짜 OpenGL ES는 몰라도 OpenGL 이 자체는 그냥 쓰기에는 너무 암걸린다... 깊게 파고드니까 Vulkan 이나 D3D12 가 선녀같이 보일 지경임.


덤으로 2001년부터 게임 개발해온 프로그래머 분의 OpenGL 이 왜 X같은가에 대한 글 링크도 올릴게요

http://richg42.blogspot.com/2014/05/things-that-drive-me-nuts-about-opengl.html