C++ 이야기 열번째: TR1(1st Library Extension) History
[이글의 최신 Update 문서는 항상 여기에서 확인할 수 있습니다]
(다음 글은 다음 원문의 전반부를 의미를 해치지 않는 선에서 약간 편집하면서 번역한 것입니다. 후반부를 번역한 글은 여기를 클릭하세요)원문 보기: Dr. Dobb's | The Technical Report on C++ Library Extensions | 5/9/2005
C++ 표준 라이브러리는 방대하지만 성공적인 프로젝트였습니다. 라이브러리 규격문서가 거의 370페이지나 될 정도였으니까요-C++ 언어 코어를 기술하는 문서보다 양이 많았죠(ISO, International Standard: Programming languages—C++. ISO/IEC 14882:2003(E), 2003). C++ 표준화가 이미 6년전에 완료되어 지금은 표준 라이브러리 사용법을 설명해 주는 책도 제법 있고(그 중 몇 개는 다음글의 참고문헌에 나열하겠습니다), 웬만한 주류 컴파일러는 표준 라이브러리를 제공하고 있으며, 이미 수백만명의 프로그래머들이 표준 라이브러리를 사용하고 있는 상황입니다. 게다가 C++ 프로그램이 지난 5년 전 안에 작성된 거라면 std::string, STL 컨테이너, 알고리즘, IOStream 을 사용하는 건 아주 일반적일 것입니다. 이 정도면 성공이라고 할 수 있겠지요 ?
그러나 상황을 약간 다른 시각으로 본다면, 표준 라이브러리는 그렇게 방대하다고 할 수는 없습니다. 물론, 1990 C 라이브러리를 모두 포함하고 있는데다 다양한 컨테이너와 알고리즘을 포함하고 있으니 어떤 측면에서는 크다고 할 순 있겠죠. 그렇지만, C++ 표준 라이브러리가 해결하고 있는 문제 영역-I/O, 지역화, 문자열 조작, 메모리 할당, 수학 함수-은 C 라이브러리에도 있는 것입니다. 그리고, 다른 언어의 표준 라이브러리에서 제공하는 것과 비교해 보면 어떤 수준일까요 ? Perl, Python, Java 표준 라이브러리는 XML 파싱, 정규식 검색, 이미지 파일 조작, 네트워크를 통한 데이터 전송 등을 포함하고 있습니다. 그런 측면에서 본다면 C++ 표준 라이브러리는 그저 시작에 지나지 않을 것입니다.
표준화 위원회 위원들도 이 사실을 물론 다 알고 있었습니다. 표준안을 1998년에 마무리할 때, 좋은 아이디어들을 모두 수용하지는 못했습니다-그 때 위원회는 포함할 수 있는 것만 포함했죠. 상당히 좋은 아이디어였음에도 시간이 없거나, 합의를 도출하지 못하거나, 구현 경험 사례가 없다거나, 아니면 단지 상상력이 부족하다거나 해서 제외된 것들이 많았습니다. 그래서 Bjarne Stroustrup이 "The Design of C++0x" (C/C++ Users Journal, 2005년 5월)에서 다음 C++ 표준안은 핵심 언어 자체보다는 라이브러리를 개선하는 데 초점을 맞추게 될 것이라고 밝힌 것이겠지요. 표준화 위원회 내에서 더 풍부한 표준 라이브러리에 대한 요구는 세계 평화에 대한 요구만큼이나 명백했으니까요.
좀 더 풍부한 라이브러리가 필요하냐 아니냐는 건 중요하지 않았고, 어떻게하면 풍부한 라이브러리를 정의할 수 있느냐가 중요한 문제였습니다. 표준화 위원회는 아이디어를 평가하고, corner case 들을 다루는데 익숙하긴 하지만, 표준화 진행이 원래 상당히 느린데다 표준화 위원회가 직접 처음으로 새로운 아이디어를 제안하는 건 잘 못하기 마련입니다. 그래서 "위원회에 의한 설계"가 그렇게 성공한 적이 드문 것이겠지요.
역사적으로 따지면, 이 문제에 대해 표준화 위원회는 두 가지 방안을 가지고 있었습니다. 1998년 Santa Cruz 위원회 회의에서 라이브러리 Working Group 장이었던 Beman Dawes이 C++ 커뮤니티 회원들이 함께 좀 더 확장성 있는 표준 라이브러리를 구축하고자 하는 목표를 갖고 비공식적으로 새로운 라이브러리 컴포넌트를 설계하고 구현해보자고 제안했습니다. 당시 그 제안은 상당히 잘 받아들여졌고, 그 결과로 나온 것이 Boost 입니다.
그러나 그 제안이 완벽한 답은 아니었습니다. 어떻게 Boost 나 다른 곳에서 개발된 비공식적인 라이브러리를 어떤 형태로든 공식적인 ISO 표준안에 반영할 수 있을 것이냐가 또 문제였습니다. 2001년 Copenhagen 미팅에서 Nico Josuttis 외 몇 몇 회원이 그 빈 공간-비공식적인 라이브러리 개발과 공식적인 ISO 표준안 사이에 필요한 그 무엇-을 채워주었습니다. 2001년 당시 차기 버전의 C++ 표준을 만드는 건 무척 요원해 보였지만, 다행히 상당수 위원회 회원들이 새로운 표준안의 일부가 되리라고 생각하는 비공식적인 라이브러리를 개발하고 있었습니다.
그래서 표준화 위원회는 라이브러리 개발이 언어 자체 개발보다는 훨씬 빨리 진행될 수 있다는 것을 인식하고 새로운 표준을 시작하기 전에라도 라이브러리 확장 작업을 시작하기로 결정했습니다. 새로운 라이브러리 컴포넌트에 대한 공식 표준안을 출판할 수는 없을지라도 기술 보고서 형식으로 새로운 라이브러리를 출판하기로 결정했습니다. 왜냐면, 이 보고서가 표준화 관점에서 본다면 "normative"-표준에 Compliant하기 위해서는 컴파일러 벤더가 꼭 포함할 필요가 있는-하지 않습니다만, 그 내용을 제공하고 싶어하는 벤더에게 일종의 가이드 역할을 하게 되고, 다양한 사람들이 새로운 라이브러리 컴포넌트를 일단 기술하기 시작할 수 있게 되고, 구현하거나 사용할 수 있게 되어, 결국 다음 공식 표준안에 보고서 내용을 반영시키기가 쉬워질 것이라고 생각했기 때문입니다.
라이브러리 확장을 기술 보고서로 작성하는 아이디어가 2001년 Copenhagen 미팅에서 제안된 후, 다음 미팅에서부터 라이브러리 Working Group 은 새로운 라이브러리 확장에 대한 아이디어를 토론하기 시작했고, 제안서 제출을 요청하기 시작했습니다. 첫번째 제안서가 2002년 Santa Cruz 미팅에서 접수되었고, 2003년 미팅에서 접수 마감이 됐습니다. 그 이후로 라이브러리 정의를 시작해서 2005년 5월경에 C++ 라이브러리 확장에 대한 Technical Report Draft인 ISO/IEC PDTR 19768 를 완성했습니다. 당시 절차적인 단계만 남은 상태라 공식적으로 완성되기까지는 소소한 변경만 일어날 것으로 예상됐습니다. 현재 상황에 대해서는 http://www.open-std.org/jtc1/sc22/wg21/ 를 보세요.
TR1를 다운로드해서 읽어보면 C++ 표준안의 라이브러리 부분처럼 작성된 걸 알 수 있을 겁니다. 나중에 TR1에 있는 내용이 그대로 표준안에 반영될 것이기 때문에 일부러 이렇게 표준안의 형식에 맞게 작성한 것이랍니다.
진짜 표준안과 차이가 있다면 표준 라이브러리는 std 라는 네임스페이스에 정의되어 있는데 반해 TR1에 있는 것들은 std::tr1 이라는 네임스페이스에 정의되어 있다는 점입니다. 왜 std::tr1 에 정의했을까요 ? 그건 언젠가 std::tr2, std::tr3 이런 것들이 필요할 것으로 예상됐기 때문입니다. 비슷한 이유로 보통 "Technical Report on C++ Library Extensions" 이라는 정식 이름을 쓰는 대신 "TR1" 이라고들 많이 얘기합니다. 현재 새 표준 라이브러리 정의 작업이 진행중인 상태입니다.
TR1의 컴포넌트들이 std 네임스페이스에 있지 않다는 건 단순한 차이 이상을 뜻합니다. std 네임스페이스에 있는 것은 표준이지만 std::tr1에 있는 것은 표준이 아닙니다. 그 안에 있는 것은 모두 실험적인 것이고, 사용 경험 또는 구현 경험을 얻어내기 위해 임시로 있는 것입니다. 따라서 비록 TR1에 있는 대부분이 다음 C++ 표준인 "C++0x"에 반영되겠지만, 경우에 따라서는 실제 경험한 결과, 바뀔 여지도 충분히 있습니다. TR1이 C++ 프로그래머에게 유용하고 재밌는 기능을 많이 제공하고, 다음 표준이 어떨지를 미리 보여줄 수 있지만, 여전히 TR1을 사용하는 건 최첨단의 라이브러리는 사용한다는 것을 의미하게 됩니다.
이걸 염두에 두고, TR1의 독특한 기능들을 살펴 보겠습니다.
(이후는 다음글에서...)
블로그를 구독하는 방법을 잘 모르시는 분은 2. RSS 활용을 클릭하세요.
RSS에 대해 잘 모르시는 분은 1. RSS란 무엇인가를 클릭하세요.