4. 전문가를 위한 C++ 프로그램 디자인 4.5 코드의 재사용 4.5.5 오픈 소스 라이브러리

4.5.5 오픈 소스 라이브러리

코드 재사용에서 오픈 소스 라이브러리는 단연 인기 메뉴다. 오픈소스의 일반적인 의미는 모든 사람이 소스 코드를 볼 수 있도록 공개한다는 것이다. 모든 배포방식별로 오픈 소스의 법률적인 정의가 따로 있지만. 핵심은 오픈 소스 소프트웨어라면 모든 사람이 소스코드에 접근할 수 있게 해야 한다는 것이다.

 

오픈 소스는 라이브러리에만 국한하지 않는다. 리눅스 운영체제는 사실 가장 유명한 오픈소스 제품이다.

 

구글 크롬과 모질라 파이어폭스 브라우저도 유명한 오픈소스 제품이다.

 

4.5.5.1 오픈소스 운동

오픈소스 커뮤니티 안에서도 용어에 약간의 혼란이 있다.

첫 번째로 오픈 소스 운동에는 두 가지 경쟁 중인 이름이 있다. 리차드 스톨만과 GNU 프로젝트에서는 프리 소프트웨어(free software)라는 용어를 사용한다. 여기서 free는 최종 제품이 공짜(free)라는 뜻이 아니다.

 

개발자는 자기가 원하는 만큼 많든 적든 가격을 받을 수 있다. free는 공짜라는 뜻 대신 소스 코드를 열람하고 수정하고 재배포할 자유(free)를 의미한다.

 

free를 공짜 맥주(free bear)의 free보다는 표현의 자유 (free speech)의 free로 생각하라.

이러한 GNU 프로젝트에 대해서는 https://www.gnu.org/ 에서 더 자세히 살펴볼 수 있다.

 

오픈소스 이니셔티브

오픈소스 이니셔티브(Open source Initiaive[OSI])는 오픈 소스 소프트웨어를 소스를 반드시 사용할 수 있는 소프트웨어로 해석한다.

프리 소프트웨어와 오픈 소스 소프트웨어의 가장 큰 차이는 오픈 소스라고 해서 마음대로 사용, 수정, 배포할 권한이 항상 열려 있는 것은 아니라는 점이다. 오픈 소스 이니셔티브에 대해서는 https://opensource.org/ 에서 자세히 살펴볼 수 있다.

 

오픈 소스 프로젝트가 사용할 수 있는 라이선스에는 몇 가지 종류가 있다. 그중 하나는 GNU 일반 공중 사용 허가서(GNU Public License) 이다. 그런데 GPL을 사용하면 연계되어 새로 개발한 소프트웨어도 오픈소스화 해야 한다. 반면, Boost, OpenBSD, CodeGuru, COdeProject, Creative Commons License 등은 소스를 공개하지 않는 제품에서도 사용 가능한 라이브러리 라이선스다.

 

오픈 소스가 프리 소프트웨어보다 오해가 적기 떄문에 이 책에서는 소스 코드가 공개된 라이브러리나 제품을 칭할 때 오픈소스를 이용할 것이다. 이러한 용어 선택은 특정 오픈 소스 철학을 지지하는 것이 아닌, 편의상 선택일 뿐이다.

 

4.5.5.2 오픈 소스 라이브러리 찾기

용어야 어떻든 간에 오픈 소스 소프트웨어는 엄청난 도움을 준다. 가장 큰 이득은 기능적인 부분이다. 다양한 작업에 사용할 수 있는 방대한 오픈 소스 C++라이브러리가 있다. XML구문 해석에서부터 크로스 플랫폼 에러 로깅까지 정말 다양하다.

 

오픈 소스 소프트웨어는 아무런 대가도 받지 않지만, 그렇다고 무료 배포나 무료 라이선스를 강제하지도 않는다. 오픈 소스 라이브러리를 사용하면 큰 비용을 아낄 수 있다.

 

오픈 소스 라이브러리는 필요에 따라 자유롭게 수정할 수 있는 경우가 많기는 하지만 꼭 그렇지는 않다.

 

대부분의 오픈 소스 라이브러리는 웹에서 내려받을 수 있다. 예를 들어 '오픈 소스 C++라이브러리 XML 파싱'이라고 검색하면 C와 C++로 된 XML 라이브러리들이 검색된다. 

 

4.5.5.3 오픈 소스 코드 이용 가이드

오픈 소스 라이브러리는 몇 가지 도유한 이슈가 있고, 새로운 이용 전략을 요구한다.

 

첫 번째로 오픈 소스 라이브러리는 보통 기여의 여가 시간에 작성된다.

소스 베이스는 일반적으로 기능 추가든 버그 수정이든 기여하고자 하는 모든 프로그래머에게 열려 있다. 프로그래머 사회의 훌륭한 일원이라면 기여할 만한 오픈 소스 프로젝트를 찾고 오픈 소스로부터 혜택을 받은 만큼 되돌려주는 것이 미덕이다.

 

회사에서 근무한다면 매출과 관계없는 오픈 소스 활동을 관리자들이 달가워하지 않을 수 있다. 하지만 회사 이미지 제고나 오픈 소스 프로젝트로부터의 지원 등 여러 가지 간접적 이익을 호소하면 회사의 용인과 지원을 받을 수도 있을 것이다.

 

두 번째로 오픈 소스의 배포 방식과 강력한 오너십의 부재는 종종 기술 지원 문제를 일으킨다.

만약 오픈 소스 라이브러리에서 발견한 버그가 당면 프로젝트에 매우 중대한 영향이 준다면, 오픈 소스 커뮤니티의 다른 누군가가 수정하는 것을 기다리기보다는 직접 수정하는 것이 빠르다. 만약 버그를 수정했다면 소스 베이스에 반영하는 것도 잊지 말길 바란다. 버그를 수정하지 못하더라도 버그 리포트를 제출하는 것이 좋다. 그렇게 하면 다른 프로그래머가 같은 문제로 시간을 허비하는 것을 막을 수 있다.