Guide 2.3 How To use opensource For Developer

오픈소스 사용 가이드 - 개발자편

• 오픈소스 사용 가이드 - 개발자편
  • 오픈소스 생태계의 이해
  • 오픈소스 커뮤니티
  • 오픈소스 생태계의 이해 - 오픈 소스 재단
  • 오픈소스 라이선스
  • 오픈소스 선택 가이드
  • 오픈소스 선택 체크리스트

오픈소스는 생태계는 매년 그 규모가 매우 빠르게 발전하고 있다. 오픈소스 거버넌스 플랫폼을 운영하고 있는 Sonatype 에서 최근 발표한 2020년 소프트웨어 공급망 현황 보고서에 따르면 2020년도에 Java 패키지의 경우 2020년도 다운로드 수가 3700억건을 상회하며 이는 작년 대비 무려 55%나 증가한 것으로 나타난다. Javascript 패키지의 경우에는 주로 NPM을 통해 유통이 되는데 이 역시 패키지 다운로드가 1조에 이르러 매년 100% 성장세로 발전하고 있다. 2019년에는 50만개 이상의 새로운 오픈소스가 릴리즈 되었는데 2020년에는 130만개로 지난해보다도 63%가 증가했다.

이처럼 수 많은 오픈소스가 생겨나면서 오픈소스를 선택하는 폭도 그 만큼 넓어졌다. 이번 장에서는 오픈소스를 올바르게 선택하는 방법에 대한 내용들을 알아보고자 한다.

오픈소스 생태계의 이해

오픈소스 선택에 대한 내용에 앞서 오픈소스 생태계를 이해할 필요가 있다. 오픈소스 생태계는 크게 생산자와 공급자 소비자 계층으로 나뉘는데 생산자는 오픈소스 커뮤니티 및 재단, 그리고 오픈소스 기여자 등으로 구성이 된다. 공급자로는 소프트웨어 인프라 공급자, 교육 및 컨설팅 기업, 기술지원 기업등이 있다. 소비자로는 일반 사용자와 오픈소스를 활용하는 조직이 해당한다.

생산자

• 오픈소스 커뮤니티 : 오픈소스 생태계에서 허브 역할
• 오픈소스 재단 : 오픈소스 커뮤니티와 상용 오픈소스 밴더 사이에서 공동 작업을 지원
• 오픈소스 기여자 : 오픈소스를 개발하고 다양한 오픈소스 이슈를 처리하는 개발자

공급자

• 소프트웨어 인프라 공급자 : 오픈소스 공급망 제공
• 교육 및 컨설팅 기업 : 오픈소스 프로젝트를 중심으로 비즈니스 생태계 조성
• 기술 지원 기업 : 오픈소스 커뮤니티와 협력 관계를 유지하며 오픈소스를 지원하기 위한 기술 인력을 운영

소비자

• 일반 사용자 : 오픈 소스 사용하고, 커뮤니티를 통해 오픈소스의 개선에 참여
• 오픈소스 유료 사용자 : 유료 서비스를 통해 차별화 된 지원을 받는 사용자 또는 조직

오픈소스 커뮤니티

오픈소스 커뮤니티의 구성은 양파 구조에 비유를 많이 하게 되는데, 프로젝트 리더(또는 창시자)와 핵심 기여자, 기여자, 신입 기여자, 사용자로 구성이 된다. 이 중 프로젝트 리더는 오픈소스 프로젝트 전반적인 사항에 대해 최종 의사 결정을 내린다. 핵심 기여자는 프로젝트에서 경험이 제일 많은 실력자이며, 커뮤니티 멤버들을 지도하거나 멘토링을 하게 된다. 그 외 자세한 내용은 오픈소스 기여하기 편에서 다루기로 한다.

오픈소스 생태계의 이해 - 오픈 소스 재단

오픈소스 생태계에는 다양한 오픈소스 재단이 존재한다. 오픈소스 이니셔티브(OSI, Open Source Initiative)의 앨리슨 랜달 회장은 "기업들이 신뢰할 수 있는 비영리 독립 단체를 통해 오픈소스 프로젝트를 공동 추진할 수 있다고 생각함에 따라 재단 설립이 증가하고 있다. 이는 아주 중요한 의미를 지닌다. 경쟁 관계에 있는 기업들이 협력을 할 경우 통상 많은 장애물은 만나게 된다. 중립적이면서도 경쟁적이지 않은 재단을 매개체로 삼는 방법이 아주 유용할 수 있다"라고 설명했다.

몇 가지 주요 오픈소스 재단은 아래와 같다.

OSI (Open Source Initiative)

이 조직은 1998년 Netscape에서 영감을 받아 시작되었으며, 오픈소스 소프트웨어 사용을 장려하기 위해 만들어진 단체이다. 현재는 OSI 라이선스 검토와 승인 등 OSD(Open Source Definition)을 관리하고 있다.

Free Software Foundation

오픈소스 분야에서 유명한 리차드 스톨만이 1985년에 설립한 재단으로 자유(Free) 소프트웨어의 생산과 보급을 장려하고 있다. 주로 컴퓨터 소프트웨어를 만들어 배포하고 수정하는 보편적인 자유를 제고한다.

Linux Foundation

리눅스의 성장을 지원하고 상업적 지원을 진행하고 있는 기술 컨소시엄이다. 최근에는 오픈소스 이벤트, 교육 및 인증, 오픈소스 프로젝트 지원 프로그램등으로 영역을 확장하고 있다.

Apache Software Foundation

1993년 Apache HTTP 개발자들에서 시작한 이 그룹은 전세계 분산 개발자 커뮤니티로 발전하여, 다양한 오픈소스 프로젝트를 진행하고 있다. 그들이 개발하고 있는 소프트웨어는 아파치 라이선스 조항 아래 배포된다. 재단의 목적 중 하나는 아파치 프로젝트에서 일하는 지원자들에 대한 법적 보호와, 허가 없이 다른 조직에서 아파치 브랜드의 사용을 막는 데에 있다. 또한 아파치 프로젝트와 관련된 기술과 아파치 개발자들이 함께 모이는 데에 초점을 맞춘 ApacheCon 콘퍼런스를 해마다 열고 있다.

Cloud Foundry Foundation

클라우드 파운드리 재단은 클라우드 파운드리 오픈 소스 프로젝트의 전 세계적인 인식 및 채택을 이끌고 기여자 공동체를 성장시키고, 프로젝트 성공을 위해 모든 멤버 기업들을 통해 전략 및 조치의 일관성을 구축하기 위해 존재한다. EMC, HP, IBM, 인텔, SAP가 공동 참여하고 있다.

오픈소스 라이선스

오픈소스는 저작권법에 의한 보호를 받는다. 오픈소스는 일반적으로 소스가 공개되어서 접근할 수 있게 설계되었고 누구나 자유롭게 사용, 수정, 배포할 수 있다. 오픈소스는 라이선스를 가지며 해당 오픈소스를 사용하기 위해 사용자가 지켜야 할 의무 사항을 명시하고 있다. 이러한 의무 사항을 제대로 준수하지 않고 사용하면 저작권법 위반이 된다.

오픈소스 라이선스 중 GPL 라이선스의 경우에는 오픈소스를 사용하는 조건으로 사용된 애플리케이션의 모든 코드를 공개해야 하는 의무 사항을 가지고 있다. 만약 상용 소프트웨어나 코드 공개를 원치 않는 애플리케이션에서 GPL 라이선스의 오픈소스를 사용하면 소스 코드 전체 공개는 물론 저작권법 위반으로 형사 처벌을 받을 수도 있다.

오픈소스 라이선스는 크게 copyleft 진영과 permissive 진영으로 나뉜다. 두 가지 라이선스의 특징은 아래와 같이 나눌 수 있습니다.

copyleft 라이선스

• 사용한 경우 코드 공개 의무 (오픈소스를 통해 이익을 얻는 경우, 이를 다시 오픈소스 생태계에 환원하게 하기 위한 목적)
• 사용한 오픈소스의 라이선스와 동일한 조건으로 배포 의무
• 대표적인 라이선스: GPL, LGPL, AGPL, MPL 등

permissive 라이선스

• 일반적으로 고지 의무를 지키면 자유롭게 사용 가능
• 대표적인 라이선스: Apache, MIT, BSD 등
• 오픈소스 라이선스의 의무 사항은 배포가 이루어질 때 적용됨.

배포의 조건

오픈소스 배포란 소스 코드 또는 바이너리의 복사본을 다른 사람에게 제공하는 행위를 의미한다. 앱스토어 배포, 판매, 3rd party 제공, 공개된 코드 등이 배포에 해당한다. 개인적으로 사용하거나 외부에 공개하지 않고 사내툴로만 사용하는 경우는 배포에 해당하지 않는다.

오픈소스 라이선스 공통 의무사항

오픈소스 라이선스는 공통적으로 4가지 의무 사항을 기반으로 한다. 오픈 소스 사용자는 저작권을 고지해야 하고, 라이선스 사본을 포함해야 한다.다만 오픈 소스 사용시 보증은 되지 않으며, 책임에도 제한이 있다.

• 저작권 고지
• 라이선스 사본 포함
• 보증의 부인
• 책임의 제한

오픈소스 선택 가이드

수 많은 오픈소스로 인해 요구 사항에 가장 적합한 오픈소스를 선택하기가 어려울 수 있다. 여기서 오픈소스 선택을 위한 기준을 몇가지 제시해보고자 한다.

1. 기능성
   자신의 프로젝트에서 필요한 기능을 충분히 충족할 수 있고 사용하기에 적합한지 따져봐야 한다. 예를 들어 메세지 큐 기능을 위한 오픈소스를 선택하는데 있어서 기본 메세징 기능 적합한지 확인하고, 업계에서 널리 사용되는 프로토콜과 일치하는지 확인을 해야 한다. 필요한 기능 이상으로 지나치게 과도한 기능을 제공하진 않는지도 중요하다. 예를 들어 단순히 문서 파일 포멧 변환이 필요한데 이미지, 영상 포멧까지 다양하게 제공하는 오픈소스라면 현재 필요하지 않은 기능 때문에 더 많은 용량이나 리소스를 차지할 수도 있다. 오픈소스가 프로젝트에서 요구하는 기능에 완벽하게 충족시키지 못한다면 필요한 추가 기능을 직접 수정하여 사용하는 것도 고려될 수 있다. 그러나 이 수정하게 되는 경우 오픈소스 기여와 변경에 따른 라이선스와 같은 다양한 내용들을 살펴보고 진행해야 한다.

2. 오픈소스 사용 조건 및 성능
   오픈소스 사용 조건과 같은 비기능적인 부분도 반드시 살펴봐야 한다. 프로젝트에서 사용하는 아키텍처나 운영체제와 호환이 되어야 하고, 프로젝트가 현재 Linux 에서 작동하지만 Windows도 추후에 확장될 계획이라면 두 시스템 모두 지원하는 오픈소스여야 한다. 그리고 오픈소스의 성능이 조건에 충족하는지 살펴보고, 성능이 중요하다면 벤치마킹을 수행하여 성능을 반드시 측정해보아야 한다.

3. 라이선스
   오픈소스에 명시된 라이선스를 반드시 확인해야 한다. 상업용 프로젝트에 비 상업용 라이선스를 가진 오픈소스를 사용하거나, GPL 라이선스를 가진 오픈소스를 사용하게 되어 의도하지 않게 자신의 코드를 전부 공개해야 하는 상황은 피해야 한다. 이 경우 Apache나 MIT와 같은 상대적으로 관대한 허용적 라이선스를 사용하는 오픈소스를 선택하는 것이 바람직하다.

4. 보안
   오픈소스의 11%가 알려진 취약점을 가지고 있다는 통계가 있다. 따라서 오픈소스 검토 보안과 관련된 부분을 반드시 확인하고 사용해야 하며, 취약점이 발견 되었을 때 빠르게 조치가 이뤄지고 있는지 등도 검토 대상이 될 수 있다.

5. 인기도
   오픈소스가 GitHub 에서 관리 중이라면, Star 개수나 Watch, Fork 횟수 등으로 얼마나 많은 사용자가 오픈소스를 활용할 수 있는지 가늠해볼 수 있다. 뿐만 아니라 오픈된 이슈 개수나 PR 수, 마지막 커밋 일시 등을 통해 얼마나 활발하게 오픈소스 개발이 이뤄지고 있고 계속 발전할 가능성이 얼마나 되는지 파악이 가능하다. 그 밖에도 해당 오픈소스와 관련된 StackOverflow 질문 수, 오픈소스 다운로드 수, Google 쿼리 결과 수 등과 같은 간단한 측정을 통해서 인기도를 확인해 볼 수 있다. 이러한 여러 지표들을 측정하여 오픈소스 커뮤니티의 건강성을 측정하는 *CHAOSS 와 같은 도구도 있다.

   • Star 수
   • 참조 횟수
   • 오픈된 이슈 수
   • 오픈된 PR 수
   • 마지막 커밋일시
   • 릴리즈 주기

6. 소스 코드
   오픈소스의 소스 코드와 코드의 품질도 중요하다. 프로젝트에서 사용 중이거나 익숙한 프로그래밍 언어로 작성된 오픈소스를 사용하는 것이 유리하다. 이는 오픈소스를 직접 수정하지 않더라도 이슈가 발생했을 때 디버깅을 하거나 원인을 파악하는데 도움이 된다. 낮은 코드 품질의 오픈소스는 잠재적으로 버그, 보안 취약성, 성능 저하 및 유지 관리 이슈를 갖고 있습니다. 코드 품질을 파악하는 방법으로는 세부적인 로직을 모르더라도 단위 테스트 코드가 포함되어 있는지, 메서드 또는 함수가 읽기 쉽게 명명되어 사용 중인지, 코딩 컨벤션은 올바르게 지켜지고 있는지 등을 참고하여 판단할 수 있다.

7. 문서화
   오픈소스 코드 품질과 더불어 문서화가 잘 되어 있는지 살펴보는 것도 중요하다. 설치 방법, 튜토리얼, 참조 설명서 등 문서화가 잘되어 있는 오픈소스는 그만큼 성숙한 오픈소스라고 볼 수 있다. 문서화가 잘되어 있으면 직접 오픈소스 코드를 보지 않더라도 세부적인 사용 방법도 손쉽게 파악이 가능하고 빠르고 다양하게 적용이 가능해져서 오픈소스 활용도도 그만큼 올라가게 된다.

오픈소스 선택 체크리스트

• 많이 쓰이고 있는 오픈소스인가?
• 팀에서 오픈소스를 배우는데 어렵진 않은가? (레퍼런스가 충분한가?)
• 유지보수가 잘 되고 있는가?
• 유사 오픈소스와의 차이점은 무엇인가? (얼마나 효율적인가?)
• 쓰지 않는다면 어떤 문제가 생기는가?
• 라이선스에는 문제가 없는가?
• 커뮤니티는 활성화되어 있는가?