오픈소스 '슬기롭게' 사용하는 법

10분

2023.05.23.

11.3K

다음 기업의 공통점은 무엇일까?

구글(Google), 마이크로소프트(Microsoft), 아파치(Apache)

바로 오픈소스 생태계를 리드하는 소프트웨어 기업과 재단이라는 점이다. 디지털 전환이 본격화되면서, 소프트웨어 기술 노하우를 공유하고 인공지능이나 블록체인과 같은 신기술의 시드 기술을 제공하는 오픈소스 사용은 필수가 되었다. 오픈소스는 비즈니스 생태계에 파괴적인 혁신을 초래하며, 다양한 참여자들의 소프트웨어 시장 진입장벽을 완화하고 있다.

오픈소스라고 하면 이름 때문에 아무런 제약 없이 무료로 사용할 수 있다고 생각하기 쉬우나, 실제 실무 환경에서는 생각보다 고려해야 하는 사항이 많다. 이번 글에서는 오픈소스 소프트웨어 사용 시 발생할 수 있는 문제와 이에 대응하기 위한 방안을 살펴보고자 한다.

오픈소스는 어떻게 발전해왔을까?

1) 오픈소스란

오픈소스 소프트웨어(Open Source Software)는 라이선스 방식에 따라서 배포 및 수정, 복제, 사용, 재배포가 가능한 공개된 소프트웨어를 의미한다. 상당수의 오픈소스가 무료로 사용할 수 있기 때문에 프리웨어(Freeware)와 혼동하는 경우가 있지만, 엄연히 다른 개념이다. 프리웨어는 말 그대로 무료로 사용할 수 있는 프로그램이지만, 오픈소스는 소스코드가 공개되어 있을 뿐 라이선스를 기반으로 제약 사항들이 존재하는 프로그램이다.

2) 오픈소스 생태계의 발전 4단계

오픈소스 생태계의 발전은 크게 4단계로 구분된다. 먼저, 1980년대 초반 상용 소프트웨어 시장이 성장하면서, 상용 소프트웨어에 저항하기 위한 자발적인 참여 운동으로 오픈소스가 시작되었다. 개발자 커뮤니티를 중심으로 별도의 수익 모델 없이 오로지 자유로운 소프트웨어 생태계를 만들겠다는 목적에서 출발한 것이다. 이 시기가 오픈소스 1.0 시기이다.

이후 라이선스 개념이 정립되면서 소프트웨어가 양립화되기 시작했다. 상용 소프트웨어와 오픈소스는 각자의 목표와 목적에 따라 라이선스 정책을 유지하며 각각 체계를 강화하였다. 오픈소스는 LAMP(Linux, Apache, MySQL, PHP) 프로젝트를 기반으로 오픈소스 커뮤니티의 결속력을 강화하여 오픈소스 생태계 조성의 초석을 마련하였다. 이때가 오픈소스 2.0이다.

오픈소스 3.0 시기는 기술적 우위를 확보한 일부 오픈소스 프로젝트를 통해 소프트웨어 산업 패러다임의 전환점을 맞이하게 되었다. 디지털 생태계가 확대되며 소프트웨어 개발 수요가 폭발적으로 증가하면서, 빅테크 기업들도 전에 없는 호황을 맞이하게 되었다. 이러한 개발 생태계의 변화로 인해 소프트웨어 시장의 표준도 자연스럽게 오픈소스가 주도하게 되었다.

오픈소스 4.0 시기라 불리는 현재는 오픈소스 생태계의 성장기라고 할 수 있다. 클라우드와 인공지능 등 차세대 기술을 적용한 디지털 전환이 본격화되며 소프트웨어가 비즈니스 혁신의 성공 요소로 자리 잡으면서 오픈소스의 영향력이 증대되었다. 텐서플로우(TensorFlow), 파이토치(PyTorch), 쿠버네티스(Kubernetes), 아폴로(Apollo) 등의 오픈소스 프로젝트는 기술 혁신의 자양분이 되어 오픈소스 보편화를 촉발했다. 나아가 상용 소프트웨어를 역전하는 현상을 일으키며 빅테크 기업의 플랫폼 수익모델을 가속화하였다.

오픈소스 사용 전 알아야 할 양립성, 종속성, 보안 이슈

소프트웨어 개발을 할 때 오픈소스의 제약 사항을 제대로 확인하지 않은 채 무분별하게 사용하다가는 라이선스 양립성 문제나 보안 이슈에 봉착할 수 있다. 장점만 보고 무턱대고 사용하지 말고 꼭 제약 사항을 확인해야 한다.

1) 오픈소스 양립성(Compatibility)문제

오픈소스 라이선스에 대해 이해하기 위해서는 지식재산권과 라이선스를 이해해야 한다. 먼저 지식재산권(Intellectual Property)은 ‘인간의 창조적 활동 또는 경험 등을 통해 창출하거나 발견한 지식·정보·기술이나 표현, 표시 그밖에 무형적인 것으로서 재산적 가치가 실현될 수 있는 지적 창작물에 부여된 재산에 관한 권리’를 의미한다. 다시 말해 인간의 지적 창조물 중에서 법의 보호가 필요한 가치가 있는 권리라고 볼 수 있다.

라이선스(License)는 ‘라이선스 소유자와 제공자인 라이센서로부터 라이선스를 사용하려는 제3자(라이센시)에게 지적재산권을 이전하는 계약’을 의미한다. 따라서 오픈소스의 라이선스라는 것은 인간의 창조 활동으로 생산된 소스코드 및 관련 산출물에 대한 사용 권한과 범위를 명시하는 것이다.

화이트소스(WhiteSource)에서 발표한 보고서에 따르면, 2021년 사용된 오픈소스 라이선스 사용 분포에서 Apache-2.0이 34.1%로 가장 높은 사용률을 보이고 있으며, 뒤를 이어 MIT 29.7%, GPLv3, BSD 3, LGPLv2.1 Microsoft Public, BSD 2순으로 사용된 것으로 나타났다. 이는 오픈소스 라이선스라고 해서 모두 동일한 것이 아니라 적용 범위 및 방법 등이 상이하기 때문에 라이선스 유형별 제약 사항을 제대로 파악해야 한다는 것을 의미한다.

아파치 라이선스(Apache License)는 아파치 소프트웨어 재단(Apache Software Foundation)에서 만든 라이선스로 소스코드 수정 및 배포 시에는 Apache-2.0라고 밝혀야 한다. 아파치 라이선스로 배포 시에는 저작권, 특허, 상표 등에 대한 고지사항을 포함해야 하며 최초 개발자를 위해 보증을 면제하고 책임을 제한한다. 아파치 소프트웨어 재단은 오픈소스 웹 서버 중에서 가장 유명한 아파치 HTTP(Apache HTTP), 서버 하둡(Hadoop), 카프카(Kafka), 로그포제이(Log4j)등 361개 프로젝트가 운영하고 있다.

MIT 라이선스(MIT License)는 미국 매사추세츠 공과대학교인 MIT에서 소프트웨어 공학도를 위해 개발한 라이선스이다. 저작권 관련 명시만 하면 되기에 라이선스 중에서는 가장 제약이 적다.

GPL 라이선스(GPL License)는 GNU General Public License로 GNU GPL 또는 GPL이라고 불리며 자유 소프트웨어 재단에서 만든 라이선스다. 라이선스에 명시된 제약 조건이 까다로운 편으로 소스코드의 수정 및 배포 시에는 모두 GPL로 공개해야 한다. 버전별 주요 특징을 살펴보면 GPL 2.0에서는 원본 저작물과 파생 저작물에 대한 소스코드를 제공하거나 요청 시 제공한다는 내용을 명시해야 하며, GPL 3.0은 사용자 제품(User Product)에는 수정된 버전을 설치하는 데 필요한 모든 방법 및 절차, 인증 키, 기타 정보 등의 설치 정보(Installation Information)를 제공해야 한다.

이처럼 오픈소스 소프트웨어마다 라이선스 정책이 상이하기 때문에 소프트웨어를 개발할 때 라이선스 정책이 상호 양립 불가한 상황이 발생할 수 있다. 이를 오픈소스 양립성 문제라고 한다. 오픈소스 양립성 문제는 계약조건 위배 및 저작권, 특허권, 기타 지적재산권 등으로 법적 분쟁 요소가 발생할 수 있기 때문에 특히 중요한 부분이다.

2) 오픈소스 종속성(Dependency)과 보안 이슈

오픈소스는 프로젝트 설계 상의 문제 및 종속성(Dependency)으로 인해 연쇄적인 보안 문제가 발생될 수 있다. 오픈소스 취약점의 종속성 문제를 보안 패치 수준으로 생각한다면 큰 오산이다. 소프트웨어 생태계를 뒤흔들었던 아파치 로그포쉘(Apache Log4Shell)의 취약점 사례(CVE-2021-44228)는 오픈소스의 종속성이 미치는 영향력을 짐작할 수 있게 한다.

취약점이 공개된 2021년 12월 당시, 메이븐 중앙 저장소(Maven Central)에 저장된 자바(Java) 아티팩트 중 8%가 로그포쉘 취약점이 발생하는 로그4j(Log4j)에 종속적인 것으로 나타났다. 8%라는 수치만 보면 생각보다 낮은 수치라고 중요치 않게 넘기기 쉽다. 하지만 메이븐 중앙 저장소 생태계에 미치는 영향 정도를 권고하는 수치가 2%인 점을 감안한다면, 무려 4배가 넘는 아티팩트가 영향을 받기 때문에 매우 높은 수치라고 볼 수 있다. 결국 아파치 로그포쉘 취약점의 영향도가 높을 수 있었던 것은 취약한 로그4j들이 종속적인 관계를 형성하기 때문이다.

오픈소스 소프트웨어는 단독 프로젝트로 구성될 수 있지만 다중 프로젝트로 구성되는 경우에는 오픈소스 간의 종속성으로 연쇄적인 보안 위험이 발생되게 된다. 종속성은 보안 취약점을 해결하는 과정에도 영향을 미친다. 취약한 오픈소스 패키지를 사용하는 경우에는 보안 패치된 버전으로 즉시 업데이트하면 되지만, 적용된 패키지의 종속적인 패키지가 취약한 경우에는 종속된 패키지 자체가 보안 업데이트를 수행해야 하기 때문에 상대적으로 보안 업데이트 속도가 더딜 수밖에 없다.

오픈소스 사용할 때 고려해야 할 것

오픈소스 소프트웨어 사용이 증가되면서, 금융감독원과 금융보안원에서는 금융 분야 소프트웨어 종사자들이 참고할 수 있는 보안 가이드를 발표하였다. 이 가이드에서는 소프트웨어 생명주기(SDLC)에 따라서 오픈소스 생태계에서 발생할 수 있는 고려 사항을 제시하고 있기 때문에 금융 분야 종사자가 아니더라도 소프트웨어 종사자라면 프로젝트 개발할 때 적용할 수 있다.

가이드에서는 소프트웨어 생명주기에 따라 개발 전, 개발 중, 개발 후의 단계로 분류하였다. 개발 전 단계에서는 ‘사전 기능 및 보안성 테스트’와 ‘라이선스 검토’가 필요하다. ‘사전 기능 및 보안성 테스트’에서는 오픈소스에서 제공하는 기능 이외에 백도어나 권한 상승 등 의도하지 않은 기능이 포함되어 있는지를 확인하거나 공개되어 있는 취약점의 보안패치 여부 등을 점검하게 된다. ‘라이선스 검토’ 단계에서는 다수의 오픈소스 사용으로 인해 라이선스 간 충돌이 발생하지 않았는지를 점검하고 라이선스에 따른 의무 사항을 지키고 있는지를 검토해야 한다.

개발 중인 단계에서는 ‘취약점 최소화’, ‘대체 수단 확보’, ‘자체 대응 및 추가 개발 역량 확보’가 필요하다. 먼저 ‘취약점 최소화’에서는 소프트웨어 개발 단계에서 일반적으로 수행되는 주요 기능의 보안 기능을 점검하게 된다. ‘취약점 최소화’ 단계에서 중요한 기능의 보안적 결함이 발견된 경우에는 ‘대체수단 확보’ 단계에서 법적 또는 기술적 대응 방안을 수립하게 된다. 오픈소스의 보안 업데이트 및 대체 오픈소스 활용 등으로 해결되지 않는 경우에는 ‘자체 대응 및 추가 개발 역량 확보’단계를 통해 내부 개발 인력을 이용하여 오픈소스를 자체적으로 커스터마이징하거나 기타 방식으로 문제를 해결한다.

개발이 완료된 후에는 테스트 부서 및 보안 부서 등을 통해 소프트웨어 기능 및 보안성 테스트를 수행하게 된다. 일반적으로 오픈소스의 기능 및 보안성 테스트가 제외되는 경우가 많기 때문에, 이것이 누락되지 않고 점검될 수 있도록 개발 환경과 프로세스를 구성해야 한다. 기능 및 보안성 테스트가 종료되면 종속성 검사를 수행해야 한다. 소프트웨어 개발 시에 적용한 오픈소스와 종속성 충돌 및 이슈가 발생하는지 검토한 후 운영팀과 보안팀에서 오픈소스 현황 관리 및 취약점 정보 모니터링을 거쳐 발견된 취약점을 보안 패치하는 단계를 수행하게 된다.

안전한 소프트웨어 생태계를 위한 방법

디지털 시대의 소프트웨어 생태계에서 오픈소스는 필수적인 요소다. 오픈소스 사용 시 발생하는 법적 리스크나 보안 이슈에 대응하기 위해서는 소프트웨어 계획 단계부터 주의가 필요하다. 오픈소스 라이선스의 법적 리스크를 최소화하기 위해서는 오픈소스 사용 전에 의무사항을 확인하고 저작권 이슈나 라이선스 충돌로 인한 양립성 여부를 확인해야 한다. 특히 상용 소프트웨어 개발 환경에서는 오픈소스의 소스코드 공개 의무화 여부 및 범위에 대한 내용을 확인해야 한다.

오픈소스의 보안 이슈는 사용 현황을 주기적으로 파악하는 것으로 대응할 수 있다. 취약한 라이브러리 버전이나 패키지 적용 여부를 확인하고, 보안 패치 버전이 적용된 최신 버전으로 유지해야 한다. 법적 리스크나 보안 이슈 문제에 사전에 점검하고 대응한다면, 비용을 절감하고 개발 환경을 유연하게 할 수 있는 오픈소스를 보다 다양한 분야에서 활용할 수 있으리라 기대해 본다.

로그인하고 자유롭게 의견을 남겨주세요.