Graphics Programming

표준 라이브러리가 능사는 아니다 본문

Season 1/Misc

표준 라이브러리가 능사는 아니다

minseoklee 2017. 8. 13. 01:17

크로스 플랫폼 환경에서 작업하거나 극단적인 리눅스 진영 사람들을 많이 접하면 표준은 무조건 지켜야만 하며, 네이티브 코드가 죄악이라는 세뇌를 점차 당한다. 하지만 목적에 따라 어느 API를 쓸지 신중하게 결정해야 한다.


C++로 작성되었고 윈도우즈에서만 돌아가는 게임을 예로 들어보자. 무언가 새 기능을 구현해야 하는데 파일시스템 API가 필요하다. 선택지가 적어도 4가지가 있다.


1. 게임 엔진의 파일시스템 모듈

게임 엔진에는 대개 파일 I/O를 래핑한 모듈 혹은 서브시스템이 들어있다. 이 경우는 C++로 작성했으니 C 런타임 라이브러리 또는 C++ STL을 래핑했을 것이고, 사용법도 비슷할 것이다.


2. C 런타임 라이브러리 (CRT)

게임 엔진이나 네이티브 API에 대한 사전지식이 필요 없고 STL보다 실행속도가 빠르다. 멀티쓰레드 환경에서는 주의해야 한다. CRT의 일부 함수들은 CRT 버전에 따라 멀티쓰레딩 시 오작동 또는 메모리 릭이 발생할 수 있다.


3. C++ STL

CRT보다 성능이 떨어진다.


4. Win32 API

윈도우즈의 네이티브 API를 사용한다. CRT나 STL보다 기능이 많고 더 정교한 제어가 가능하다.


어떤 API를 쓸 지는 여러 관점에서 고민해야 한다.


호환성

게임이 이미 윈도우즈 전용으로 개발되어 서비스되고 있고, 당신이 나중에 팀에 들어왔다면 이제부터 크로스플랫폼을 고려해봤자 소용이 없다. 그리고 호환성은 저기능을 포장한 용어다. 표준은 여러 네이티브의 교집합이며 기능이 부족할 수 밖에 없다.


성능

엔진의 파일시스템이 성능이 좋지 않거나 STL이 원하는 만큼 성능이 나오지 않을 수 있다. CRT와 STL의 성능 차이가 별로 크지 않을 것 같지만, 대용량 파일을 읽어보면 속도가 몇 배 이상 차이난다. 게임의 로딩 속도는 항상 악평의 근원이다.


멀티쓰레드

게임이 멀티쓰레드를 쓴다면 사용하려는 API가 쓰레드 안전인지 확인해야 한다.


일관성

프로젝트의 다른 코드에서 전부 한 방식을 쓰고 있다면 특수 상황이 아닌 한 같은 방식을 고수하는 게 나을 것이다. 여러 해에 걸쳐 다양한 사람이 작업한다면 히스토리가 제대로 남지 않고 물어볼 사람이 이미 팀을 떠났을 수 있다. 이런 상황에서 API 사용법이 뒤죽박죽인 코드들은 그 의도를 파악하기가 매우 힘들다.


기능성

Win32 API는 C나 C++의 표준 라이브러리보다 강력한 기능을 제공한다. (파일 보안 등) 표준 라이브러리가 지원하지 않는 기능이 필요하다면 윈도우즈 네이티브 API가, 혹은 그것을 래핑한 엔진 파일시스템을 쓸 수 밖에 없다.

Comments