C++ 을 빛내는 boost 라이브러리, 약간의 아쉬움.

MSX 와 Apple 의 BASIC 으로 프로그래밍을 시작했지만, 별표(*) 삼각형으로 찍는 수준으로 프로그래밍을 했다고 보기는 좀 어렵겠고, 그런 점에서 16비트 시절 GW-BASIC 도 마찬가지. 아마도 제대로 프로그래밍에 맛을 들인 것은 Turbo Pascal 5.5 시절부터인 듯 하다. 그래서 아직까지도 파스칼의 아버지 앤더스 헤즐버그를 가장 존경 & 좋아하며, 그가 만든 C# 을 최고의 언어로 칭송하고 있다.

그렇지만 어쩌다보니 주력 언어는 C++ 이 되었고, 그 결정을 하루에 한번씩 후회하고 있다 -_-;

난, C++ 개발자가 더 똘똘하거나 더 훌륭하거나 더 좋은 프로그램을 만든다거나 그런 멍청하고 망상적인 생각을 하고 있지는 않지만, 이것 하나는 확실하다.

공부하기는 가장 빡세고 드럽게 어렵다는 것!!

C# 이 처음 나왔을 때, 소개해주는 강사(MS 전도사)가 그랬다.

"C++ 을 공부하고 사용하기에 인생이 너무 짧다고..."

그런것 같다. 특히 자바나 C# 을 사용하면서 더욱 그런 생각이 든다.
문제는 공부 엄청나게 해봤자 결국 엄청난 개발자로 성장하는가 하면 또 그것도 아니고...
그렇다고 연봉이라도 몇 배씩 더 받는가 하면 그것도 아니고...
게다가 요즘은 웹과 모바일의 시대... 

그러나~!!!
그런 나의 고통을 덜어주고, C++ 개발자에게 희망이 되어준 라이브러리가 있으니...
제목에 언급했다가 15라인 이상 얘기도 꺼내지 않고 있는 바로 boost 라이브러리이다.

물론, C++ 개발자에겐 STL (Standard Template Library) 이 있다.
사실 자바고 C# 이고 어떤 언어고 컨테이너는 다 STL 빼끼거나 참고해서 만들었겠지.
그만큼 좋긴 좋은데... 컨테이너일 뿐. 그것 말고 별게 없다.

그리고, 이상할 정도로 C++ 개발자는 단체로 다 돌아버렸는지, 라이브러리를 대부분 다 직접 만들어서 쓴다.  아니 그 어려운 C++ 로 매번 라이브러리를 "개인적"으로 만들어 쓰냐고~ 앙???

아마, 우리 회사에도 C++ 개발자라면, 각 팀마다 팀원마다(...) 자기 라이브러리가 있을껄?
솔직히 고백하자면, 나도 하나 만들어놨다. -_-;

비야네 스트라우 스트롭이 1983년에 발표한 C++ 이, 20년이 넘도록 적절한 통합 라이브러리가 없다니 대체 C++ 은 왜 이렇게 우울한 언어인거냐고~ C++ 의 아빠인 비야네 아저씨가 너무 손 놓고 있었나?

아, 또 얘기가 boost 에서 벗어났는데, 하여튼 그런 상황에 부스트가 탄생했다. (사실, 좀 됐다)

boost 는 좋다. 정말 좋다. 아~ 부스트가 개발자에게 참 좋은데 뭐라 표현할 (...)

boost 는 C++ 세상에서 가장 짱 먹는 애들이 천재적인 두뇌를 이용해서 만든 각종 라이브러리 모음집이다. 루비 언어보면 '뭔가 이 기능도 있을까?' 싶은게 전부 다 있어서 놀라곤 하는데, 부스트는 그것보다도 더 많다. 정말 라이브러리의 제왕이다.

boost 는 진짜 다양하고, 진짜 잘 만들었고, 진짜 빠르다.
그리고, 역시나 어렵다.

C++ 개발자가 '자기 라이브러리'를 만들어 쓰는 이유는 아마도, 남이 만든 라이브러리를 쓰는게 만드는 것 보다 더 어렵기 때문이 아닐까 싶다. 펄도 아니고 객체지향 언어가 대체 왜 그렇게 남의 코드 보는게 어려운건지... 똘똘한 놈이 짠 코드일 수록 더 보기 어렵다는 최근 프로그래밍 경향에 어긋나는 현상도 C++  난이도를 높이는데 한 몫 하고 있다. 보통 좋은 개발자일수록 보기 쉽고 이해하기 쉬운 코드를 짜는데, C++ 은 언어 자체가 점점 더 어렵게 짜는 것을 유도하는 것 같다.-_-;

boost 는 "그나마" 쉬운 편이다!
하지만, boost 도 막혔을 때는 해답이 없다.
나온지 그래도 꽤 됐는데, 기본 문서 외에 참고 자료가 굉장히 부족하다.
당연히 한글 번역된 문서도 거의 없고, 그러다보니 좋긴 좋으나 학습 곡선이 또 높아진다.

최근 프로젝트를 부스트 기반으로 만들고 있다.
회사에서 만들어 놓은 서버용 라이브러리가 굉장히 완성도도 높고 잘 만들어지긴 했는데, 의존성이 걸리면서 너무 많은 제약이 생기는 상황이 발생해서 그것을 제외하고, 또 개인적으로 만든 라이브러리도 신뢰성이나 성능이나 추후 업그레이드 문제로 제외를 시켰더니, 가장 좋은 선택은 이제 C++ 0x  로 공식 인정 받았고, Visual Studio 에도 포함되는 boost 를 사용하는 것이었다.

쉽게 해결되는 부분은 정말 쉽게 해결되기도 하지만, 발목 잡히면 프로젝트 일정에 영향을 줄 정도로 막히기도 하고 있다. 그리고, 만능 라이브러리이기는 하지만, 또 완전한 것은 없다보니 약간의 아쉬움이 남는 부분도 있고.

오늘 같은 경우에는 boost::property_tree 라는 7서클 마법 같은 라이브러리를 사용하고 있는데, 플렛폼에 상관없이 ini, Json, XML 을 다룰 수 있게 해주는 짱 유능한 라이브러리이다. 좋기는 완전 좋은데~ 조금씩 아쉽다. ini 는 주석을 지원하지 않고, Json 은 부분 저장이 안되고, Xml 은 어트리뷰트 속성 값으로 검색하는 방법이 없다. 이것들을 해결하려고 래퍼 클래스 만들 때 꽤나 노력을 기울였으나 찾아내지 못했다. 그렇다고 그 부분만 다른 라이브러리를 쓰기도 그렇고, 자체적으로 만들자니 피로도가 상승하고... 고민이다.

아마도, 이 고민은 프로젝트가 끝날 때까지 계속될 것 같다.
어쩌면 끝난 후에도 계속될지도...