이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.
이 문서는 Linux Foundation이 발행한 Open Source Audits in Merger and Acquisition Transactions: The Basics You Must Know (Ibrahim Haddad, Ph.D. 저, 2018)를 번역한 것입니다. 원저자는 이 번역을 검토하지 않았습니다. 원문은 원문 PDF에서 볼 수 있습니다.
소프트웨어가 모든 거래의 중심이 된 시대에, 인수합병(M&A)에서 오픈소스 실사(due diligence)는 표준 절차로 자리 잡았습니다. 이 책은 M&A 거래에서 오픈소스 감사(open source audit)가 어떻게 진행되는지, 인수 기업과 인수 대상 기업이 각각 무엇을 준비해야 하는지를 다룹니다.
이 문서는 Linux Foundation이 발행한 Open Source Audits in Merger and Acquisition Transactions (Ibrahim Haddad 저, 2018)를 번역한 것입니다. 원저자는 이 번역을 검토하지 않았습니다. 원문은 원문 PDF에서 볼 수 있습니다.
우리는 소프트웨어가 정의하는 시대에 살고 있습니다. 우리가 하는 거의 모든 일이 어떤 식으로든 소프트웨어로 계획되고, 형성되고, 분석되고, 관리됩니다. 그 거대한 소프트웨어 우산 아래에서 오픈소스 소프트웨어는 단연 으뜸입니다. 모든 산업의 기업이 오픈소스 프로젝트가 제공하는 다양한 이점을 누리려고 앞다투어 오픈소스를 사용하고, 참여하고, 기여하고 있습니다. 출시 시점을 앞당기는 외부 엔지니어링 자원을 활용하는 일부터 더 빠른 혁신에 이르기까지, 그 이점은 다양합니다.
이러한 흐름은 기업 거래에도 그대로 적용됩니다. 거의 모든 기술 인수가 어떤 형태로든 소프트웨어를 포함하기 때문입니다. 인수 기업이 인수 대상 기업(타깃)의 소프트웨어와 컴플라이언스(compliance) 관행을 종합적으로 검토하는 소프트웨어 실사(software due diligence) 프로세스는 이제 모든 인수합병(M&A)의 표준 절차로 자리 잡고 있습니다. 이 과정에서 오픈소스 소프트웨어를 마주치는 일이 흔한데, 오픈소스는 독점 소프트웨어(proprietary software)와는 다른 검증 과제를 안깁니다.
이 자료에서는 인수합병(M&A) 거래에서 이루어지는 오픈소스 감사(open source audit) 프로세스의 개요를 살펴봅니다.
오픈소스 실사(due diligence) 프로세스를 본격적으로 다루기 전에, 오픈소스 소프트웨어가 인수 대상 기업의 개발 과정에 들어오는 다양한 경로를 이해하는 것이 도움이 됩니다. 이는 기업이 자사 코드베이스에 오픈소스 소프트웨어를 알고서 넣었든 모르고 넣었든 모두 해당됩니다. 교통 위반 딱지와 마찬가지로, 의무사항을 몰랐다는 사실은 변명이 되지 않습니다. 그러므로 여러 출처에서 온 소프트웨어가 사용되는 다양한 방식을 이해해 두는 것이 현명합니다. 오픈소스 소프트웨어의 가장 흔한 사용 시나리오는 결합(incorporation), 링크(linking), 수정(modification)입니다.
오픈소스 컴포넌트를 변경하거나, 독점 컴포넌트 또는 제3자 컴포넌트에 오픈소스 코드를 주입하면, 감사 서비스 제공업체가 그러한 코드를 발견하고 보고하는 방식에 영향을 줄 수 있습니다. 오픈소스 감사(open source audit) 제공업체와 협업할 때는 그들의 탐지 방식이 오픈소스 코드를 어떻게 포착하는지 이해하면 도움이 되는 경우가 많습니다.
개발자는 완전한 오픈소스 컴포넌트를 사용하거나, 컴포넌트의 일부분(스니펫(snippet)이라고 부르기도 합니다)을 복사해 자사 소프트웨어 제품에 넣을 수 있습니다. 이러한 상황은 허용될 수 있으며, 결합된 오픈소스 코드의 라이선스와 그 코드가 복사되어 들어간 소프트웨어 컴포넌트의 라이선스에 따라 라이선스 위험이 없을 수도 있습니다. 그러나 복사한 오픈소스 코드의 라이선스가 독점 코드베이스의 라이선스와 호환되지 않으면, 결합이 문제를 일으키는 경우도 있습니다(그림 1).
오픈소스 라이선스에는 기업의 법적 책임과 자사 코드의 독점적 성격에 영향을 줄 수 있는 다양한 의무사항이 따라옵니다. 따라서 모든 결합은 제3자 라이선스 소프트웨어를 추적하고 승인할 때 사용하는 것과 동일한 프로세스에 따라 사내에서 추적하고, 신고하고, 승인해야 합니다.
그림 1. 결합(incorporation): 오픈소스 코드(초록색)를 다른 코드 본체(파란색) 안에 넣는 방식 (출처: Linux Foundation, 2018)
소스 코드 감사는 오픈소스가 코드베이스에 신고되지 않은 채 결합된 것을 찾아내, 인수 이후 불쾌한 일이 생기는 것을 막기 위해 설계됩니다. 인수 대상 기업이 오픈소스 컴플라이언스 교육을 충분히 받지 못했거나, 장기 기록을 남기지 않는 외주 인력 또는 인턴에게 의존한 경우, 신고되지 않은 결합이 발생할 가능성이 높아집니다.
결합 시나리오는 사람이 직접 소스 코드를 들여다볼 때는 잘 드러나지 않는 경우가 많지만, 스니펫을 발견하고 대조하는 능력을 갖춘 소스 코드 스캐닝 도구를 쓰면 이러한 결합을 쉽게 찾아낼 수 있습니다.
링크는 예를 들어 오픈소스 라이브러리를 사용할 때 흔히 나타나는 시나리오입니다. 이 시나리오에서 개발자는 오픈소스 소프트웨어 컴포넌트를 자사 소프트웨어 컴포넌트와 링크할 수 있습니다(그림 2). 정적/동적 링크, 결합(combining), 패키징, 상호 의존성 생성 등 이러한 시나리오를 가리키는 용어는 여러 가지입니다. 라이브러리는 보통 파일 첫머리에 포함되고 링크된 코드는 별도로 이름 붙은 디렉터리나 파일에 들어가는 경향이 있어, 소스 코드를 눈으로 훑어볼 때 링크를 탐지하기가 비교적 쉬운 편입니다.
그림 2. 링크(linking): 오픈소스 코드(초록색)를 다른 코드 본체(파란색)와 별도로 유지한 채 연결하는 방식 (출처: Linux Foundation, 2018)
링크는 소스 코드를 하나의 결합된 형태로 복사하지 않고 별도로 유지하므로 결합과 다릅니다. 링크 상호작용은 코드가 하나의 실행 가능한 바이너리로 컴파일될 때(정적 링크), 또는 메인 프로그램이 실행되어 링크된 프로그램을 호출할 때(동적 링크) 일어납니다.
수정은 개발자가 오픈소스 소프트웨어 컴포넌트를 변경하는 시나리오입니다(그림 3). 다음과 같은 작업이 여기에 해당합니다.
그림 3. 수정(modification): 개발자가 오픈소스 코드(초록색)에 코드를 추가하거나 변경하거나 삭제하는 방식 (출처: Linux Foundation, 2018)
일부 개발 도구가 이러한 작업 중 일부를 사용자가 눈치채지 못하는 사이에 수행할 수 있다는 점을 알아 두는 것이 중요합니다. 예를 들어 개발자가 개발 과정의 특정 부분을 자동화하는 도구를 사용할 수 있습니다. 사용자 인터페이스 템플릿을 제공하는 그래픽 프레임워크, 물리 엔진을 제공하는 게임 개발 플랫폼, 클라우드 서비스 커넥터를 제공하는 소프트웨어 개발 키트(Software Development Kit, SDK) 등이 그 예입니다. 이러한 서비스를 제공하기 위해 도구는 코드가 빌드될 때 보통 자기 코드의 일부를 개발자의 결과물에 주입합니다. 개발 도구가 이렇게 주입한 코드의 라이선스는 반드시 검증해야 합니다. 그 결과물이 정적으로 링크되는 경우가 많기 때문에 특히 그렇습니다.
인수합병(M&A) 거래는 저마다 다르지만, 오픈소스 의무사항을 인수했을 때의 영향을 검증할 필요는 어느 거래에서나 변하지 않습니다. 오픈소스 감사(open source audit)는 오픈소스 소프트웨어를 얼마나 깊이 사용하고 의존하는지 파악하기 위해 수행합니다. 또한 컴플라이언스(compliance) 문제에 관한 통찰을 제공하며, 나아가 인수 대상 기업(타깃)의 엔지니어링 관행까지 들여다볼 수 있게 해 줍니다.
오픈소스 라이선스는 소프트웨어를 재배포하는 방식에 제약을 부과할 수 있습니다. 이런 제약은 인수 기업의 사업과 양립하지 못할 수 있으므로 일찍 밝혀내야 합니다. 오픈소스 소프트웨어가 인수 자산에 영향을 미치는 사례로는 다음과 같은 것이 있습니다.
오픈소스 라이선스는 대개 코드를 배포할 때 이행해야 하는 의무를 부과합니다. 한 예가 GNU 일반 공중 라이선스(GNU General Public License, GNU GPL)로, 파생물이나 결합물도 동일한 라이선스로 제공할 것을 요구합니다. 다른 라이선스는 문서에 특정 고지를 넣을 것을 요구하거나, 제품 홍보 방식에 제약을 두기도 합니다.
오픈소스 라이선스 의무를 충족하지 못하면 소송, 비용이 많이 드는 재설계, 제품 리콜, 평판 손상으로 이어질 수 있습니다.
흔히 나오는 질문 하나는 오픈소스 감사가 과연 필요한가입니다. 그 답은 기업, 인수 목적, 소스 코드 규모에 따라 다릅니다. 예를 들어 규모가 작은 인수라면 일부 기업은 타깃이 제공한 오픈소스 자재 명세서(bill of materials, BoM)만 검토하고(제공된다는 전제 하에) 그들의 엔지니어링 리더와 오픈소스 관행에 관해 논의하는 편을 택하기도 합니다. 인수 목적이 인재 확보(talent)에 있더라도, 이미 출시된 제품의 과거 라이선스 의무에서 비롯된 미공개 책임이 있는지를 감사로 밝혀낼 수 있습니다.
감사 절차에는 하나의 주된 입력과 하나의 주된 출력이 있습니다(그림 4). 절차의 입력은 진행 중인 인수합병(M&A) 거래의 대상이 되는 전체 소프트웨어 스택입니다. 여기에는 독점 소프트웨어(proprietary software), 오픈소스, 제3자(3rd party) 소프트웨어가 포함됩니다. 절차의 마지막에 나오는 주된 출력은 상세한 오픈소스 소프트웨어 자재 명세서로, 다음을 열거합니다.
그림 4. 실사(due diligence) 절차의 입력과 출력. 독점 소프트웨어, 제3자 소프트웨어, 오픈소스 소프트웨어로 이루어진 전체 소프트웨어 스택을 입력으로 받아, 소스 코드 스캔과 식별을 거쳐 오픈소스 소프트웨어 명세(BoM)를 산출합니다 (출처: Linux Foundation, 2018)
감사의 규모, 범위, 비용은 거래마다 다르며, 일반적으로 소스 코드의 크기와 복잡도가 커질수록 늘어납니다. 오픈소스 감사의 견적(비용과 기간)을 제시하려면, 감사자는 코드베이스의 규모와 특성, 그리고 프로젝트의 긴급도를 어느 정도 파악해야 합니다.
감사자가 처음 던지는 질문은 코드 지표와 관련된 것입니다. 소스 코드베이스의 크기, 소스 코드 줄 수, 감사해야 할 파일 수 같은 것들입니다. 또한 코드베이스가 소스 코드로만 이루어져 있는지, 아니면 바이너리 파일, 설정 파일, 문서, 그 밖의 파일 형식까지 포함하는지를 묻습니다. 감사 대상이 되는 파일 확장자를 아는 것이 감사자에게 도움이 될 때도 있습니다.
성숙한 기업은 일반적으로 자사 제품과 프로젝트에 사용한 오픈소스 구성요소와 버전에 관한 기록을 보관합니다. 이런 정보는 감사자가 예상 작업량을 가늠하는 데 큰 도움이 됩니다.
감사 비용 논의는 규모와 범위를 근거로 절차 초기에 이루어지므로, 인수 기업이 앞서 설명한 모든 정보에 접근하지 못할 수도 있습니다. 최소한 감사자는 진행에 앞서 스캔할 파일 수를 파악해야 하며, 추가 정보가 있으면 추정치를 더 정교하게 다듬는 데 도움이 됩니다. 감사자가 작업 범위를 이해할 만큼 충분한 정보를 확보하면, 긴급도도 파악해야 합니다. 긴급도는 감사 비용에 상당한 영향을 미치기 때문입니다.
오픈소스 감사(open source audit)를 수행할 때, 도구가 갖춘 특정 기능은 인수 기업에 실질적인 가치를 제공합니다. 가장 중요한 기능 하나는 타깃 기업의 독점 코드(proprietary code)에 섞여 들어간 오픈소스 코드 스니펫(snippet)을 찾아내는 능력이며, 그 반대 방향도 마찬가지입니다. 또 다른 기능은 감사 결과에서 오탐(false positive)을 자동으로 걸러내어 수작업으로 처리해야 할 노동량을 최소화하는 능력입니다.
감사 방법(audit methods)에는 세 가지가 있습니다.
이 방법을 전통적이라고 부르는 이유는, 오픈소스 컴플라이언스(compliance)를 위한 소스 코드 스캔의 원조 방식이기 때문입니다. 전통적 감사는 제3자 감사 회사의 컴플라이언스 감사자가 클라우드 시스템을 통해 원격으로, 또는 현장을 직접 방문하여 소스에 접근한 뒤 소스 코드 스캔을 수행하는 방식입니다.
그림 5. 인수합병(M&A) 거래에서의 전통적 감사 절차 (출처: Linux Foundation, 2018)
그림 5는 전통적 감사 방법에 따른 감사 절차를 보여 줍니다. 이 절차는 서비스 제공자마다 조금씩 다를 수 있다는 점에 유의하시기 바랍니다. 일반적인 전통적 감사 절차는 다음 단계를 따릅니다.
이 방법은 대부분의 감사 서비스 제공자가 공통으로 채택합니다. 동일한 감사 작업에 대해 여러 입찰을 받아 자신의 요구사항에 가장 잘 맞는 입찰을 고를 수 있습니다. 이 모델을 따르려면 타깃 기업이 감사자에게 코드를 이전하거나, 감사자가 사무실을 방문해 현장에서 작업을 완료하도록 허용해야 합니다.
블라인드 감사 방법은 스톡홀름에 본사를 둔 FOSSID AB가 인수합병(M&A) 거래의 기밀유지 요구사항을 다루기 위해 개척했습니다. (여기서 FOSSID AB는 회사를, FOSSID는 도구 자체를 가리킵니다.)
이 회사는 자사의 독점 기술을 사용하여 소스 코드를 보지 않고도 감사를 수행하고 보고서를 생성할 수 있습니다. 그림 6은 FOSSID AB가 사용하는 블라인드 감사 절차를 보여 주며, 이 절차는 인수합병(M&A) 거래에서 소스 코드의 기밀을 유지하도록 설계되었습니다. 블라인드 감사의 주요 장점 하나는, 감사자가 소스 코드에 접근하지 않고도 검토를 완료할 수 있다는 점입니다. 또한 인수 기업이 충분히 주의를 기울이면, 감사자가 타깃의 정체를 알지 못하게 하여 높은 수준의 기밀성을 제공할 수도 있습니다. 저자가 아는 한, 이러한 감사 방법은 오픈소스 컴플라이언스 서비스를 제공하는 다른 어떤 회사도 제공하지 않습니다.
그림 6. FOSSID를 사용한 블라인드 감사 절차. 타깃 기업이 핑거프린트 수집 도구로 소프트웨어의 디지털 서명(digital signature)만 수집해 전송하면, FOSSID AB가 소스 코드에 접근하지 않고 그 서명을 오픈소스 데이터베이스와 대조해 감사합니다 (출처: Linux Foundation, 2018)
자체 수행(Do-It-Yourself, DIY) 감사는 인수 기업이나 타깃 기업에 컴플라이언스 클라우드 도구에 대한 기간 한정 접근 권한을 제공하여, 스스로 스캔을 실행할 수 있게 합니다. 그러면 지식 베이스와 모든 보고 기능에 완전히 접근하여 내부에서 감사를 수행할 수 있습니다. 이 방식은 스캔 결과를 해석하고 개선 조치(remediation) 절차를 제안할 만큼 충분한 경험을 갖춘 사내 직원을 보유한 기업에 특히 매력적입니다. 한 해에 여러 차례 인수합병(M&A) 절차를 거치는 기업이라면 금세 더 비용 효율적인 방식이 될 수 있습니다. 감사 도구 서비스 제공자가 독립 인증(independent certification)을 수행하여 결과를 검증함으로써 감사의 무결성을 한층 더 확보할 수 있습니다.
그림 7은 FOSSID AB의 도구를 사용한 이 감사 방법을 보여 줍니다. 이 방식에는 여러 장점이 있습니다. 내부 자원을 사용하고 제3자 감사자의 가용 여부에 의존하지 않으므로 필요할 때 즉시 감사를 시작할 수 있습니다. 이 방식은 일정을 단축하고 외부 비용 요인을 줄일 수 있습니다. 코드에 직접 접근하는 사람이 감사를 수행하므로 모든 컴플라이언스 문제를 즉시 처리하고 수정을 곧바로 적용할 수 있습니다. 끝으로, 감사 도구 제공자가 감사를 검증하여 정확성과 완전성을 보장할 수 있습니다. FOSSID AB는 DIY 서비스의 일부로, 타깃 기업이 감사하기로 정한 파일 중 X 퍼센트(X는 견적 합의의 일부로 정해집니다)를 무작위로 검증해 줍니다.
그림 7. FOSSID를 사용한 자체 수행(DIY) 감사 절차. 타깃 기업이 전용 웹앱의 기간 한정 인스턴스에서 직접 스캔과 감사를 수행하고, FOSSID AB는 감사 대상 파일의 일부를 독립 검증한 뒤 기간이 끝나면 모든 데이터를 삭제합니다 (출처: Linux Foundation, 2018)
많은 감사 도구는 잠재적 문제를 부각하도록 설정을 조정할 수 있습니다. 결과를 주의 깊게 살펴보면 상당수가 실제 문제가 아닌 것으로 드러날 수 있지만, 많은 양의 잡음(noise)이 섞여 있을 것에 대비해야 합니다. 이런 잡음은 코드 트리에는 남아 있지만 실제로는 사용되지 않는 잔여 코드 같은 것에서 비롯됩니다. 따라서 초기 보고서는 분량이 길 수 있으며, 보고서를 걸러내어 진짜 문제를 찾아내는 데 시간을 투자할 준비를 해야 합니다.
소프트웨어 패키지 데이터 교환(Software Package Data Exchange, SPDX) 형식에 부합하는 보고서는 보통 요청이 있을 때 제공된다는 점에 유의해야 합니다. 따라서 감사 서비스 제공자에게 그런 형식의 보고서를 받고 싶다면 별도로 요청해야 합니다.
소프트웨어는 와인이 아니라 우유처럼 나이를 먹는다는 것이 일반적으로 받아들여지는 사실입니다. 그리고 보안 취약점(security vulnerability)은 오픈소스든 아니든 모든 코드에서 우려 대상입니다. 다만 오픈소스 프로젝트에서는 이러한 취약점이 그것을 수정하는 과정과 함께 공개적으로 노출됩니다. 이 노출은 수정이 적용되기 전에 일어날 수도 있고 후에 일어날 수도 있으며, 오래된 오픈소스 코드는 실제 환경에서 활발히 악용되는 취약점을 담고 있을 가능성이 있습니다. 보안과 버전 관리(version control)는 오픈소스 컴플라이언스(compliance) 실사 과정의 일부는 아니지만, 소스 코드 스캔 서비스를 제공하는 기업이 식별된 오픈소스 구성요소를 알려진 오픈소스 보안 취약점과 대조해 매핑하는 서비스를 함께 제공하기도 합니다.
이 시점에 이르면 인수 기업은 인수 대상 기업(타깃)이 오픈소스 소프트웨어를 어떻게 사용하고 관리하는지, 그리고 오픈소스 라이선스 의무사항을 충족하는 데 얼마나 성공적이었는지를 명확히 파악하고 있어야 합니다. 인수 기업과 타깃은 이 정보를 바탕으로 오픈소스 컴플라이언스(compliance) 문제에 대한 개선 조치(remediation)를 협상해야 합니다. 감사에서 문제가 발견되면, 진행 중인 거래의 일부로 이를 해결할 몇 가지 선택지가 있습니다. 첫 번째 선택지는 문제가 되는 코드를 단순히 제거하는 것입니다. 오픈소스 소프트웨어가 독점 코드를 보완하는 역할만 한다면 이를 완전히 제거할 수 있습니다. 또 다른 선택지는 문제가 되는 구성요소를 우회하도록 설계하거나, 클린룸(cleanroom) 기법을 사용해 해당 코드를 다시 작성하는 것입니다.
해당 코드 영역이 꼭 필요하거나 이미 배포된 적이 있다면, 남은 유일한 선택지는 그 코드를 컴플라이언스에 부합하도록 만드는 것입니다. 각 선택지의 비용은 타깃의 가치를 평가할 때 활용할 수 있습니다. 어떤 선택지를 택하든, 오픈소스 코드를 도입하는 데 참여한 개인을 식별해 개선 조치 작업에 참여시키는 것이 중요합니다. 이들에게는 문제 해결에 유용한 추가 문서나 지식이 있을 수 있습니다.
오픈소스 컴플라이언스(compliance) 감사를 통과하는 일은 준비만 되어 있다면 어렵지 않습니다. 그러나 인수 기업이 관심을 보인 다음에야 준비를 시작한다면 통과하기 어렵습니다. 이러한 활동은 일상적인 사업 및 개발 활동과 함께 진행되어야 합니다. 목표는 회사가 사용하는 모든 오픈소스 컴포넌트를 추적하고, 오픈소스 컴포넌트 사용에서 발생하는 오픈소스 라이선스 의무사항을 존중하도록 하는 것입니다. 이와 동일한 조치는 회사가 기업 거래의 대상이 되었을 때도 큰 도움이 됩니다. 예기치 못한 문제의 위험을 줄여 주기 때문입니다.
코드 안에 무엇이 있는지 파악하는 것은 컴플라이언스의 황금률입니다. 출처와 라이선스 정보를 포함해, 모든 소프트웨어 컴포넌트에 대한 완전한 소프트웨어 인벤토리(inventory)를 유지해야 합니다. 여기에는 조직이 자체적으로 만든 소프트웨어 컴포넌트, 오픈소스 컴포넌트, 제3자에서 유래한 컴포넌트가 모두 포함됩니다. 가장 중요한 점은 오픈소스 컴포넌트를 식별하고 추적하는 프로세스를 갖추는 것입니다. 항상 복잡한 컴플라이언스 프로그램이 필요한 것은 아니지만, 정책(policy), 프로세스, 인력, 교육, 도구라는 다섯 가지 기본 요소는 갖추어야 합니다.
오픈소스 컴플라이언스 정책은 오픈소스 소프트웨어의 관리(사용과 기여 모두)를 규율하는 규칙의 집합입니다. 프로세스는 회사가 이러한 규칙을 일상적으로 어떻게 구현할지에 관한 세부 명세입니다. 컴플라이언스 정책과 프로세스는 오픈소스 소프트웨어의 사용, 기여, 감사, 배포 등 다양한 측면을 규율합니다.
그림 8. 종단 간 오픈소스 컴플라이언스 프로세스 예시. 식별, 감사, 해결, 검토, 승인, 등록, 문서화, 검증, 공개의 단계를 거칩니다 (출처: Linux Foundation, 2018)
그림 8은 컴플라이언스 프로세스의 예시를 보여 줍니다. 제품이나 소프트웨어 스택을 구축하는 과정에서 실사(due diligence)의 일부로 각 소프트웨어 컴포넌트가 거치게 되는 여러 단계를 나타냅니다.
이 프로세스의 산출물은 오픈소스 명세(Bill of Materials, BOM)입니다. 명세에 포함된 컴포넌트의 법적 의무사항을 이행하는 서면 제공(written offer)과 각종 저작권, 라이선스, 출처 표시 고지와 함께 이 명세를 공개할 수 있습니다. 오픈소스 컴플라이언스 프로세스에 대한 자세한 논의는 Linux Foundation이 발행한 무료 전자책 Open Source Compliance in the Enterprise를 내려받아 참고하시기 바랍니다.
대기업에서 오픈소스 컴플라이언스 팀은 오픈소스 컴플라이언스 보장을 임무로 하는 여러 구성원으로 이루어진 다학제 그룹입니다. 흔히 오픈소스 검토 위원회(Open Source Review Board, OSRB)라고 불리는 핵심 팀은 엔지니어링 및 제품 팀 대표, 한 명 이상의 법률 자문, 컴플라이언스 책임자로 구성됩니다. 확장 팀은 문서화, 공급망, 기업 개발, IT, 현지화 등 여러 부서에 걸쳐 컴플라이언스 노력에 지속적으로 기여하는 다양한 구성원으로 이루어집니다. 다만 소규모 회사나 스타트업에서는 법률 자문의 지원을 받는 엔지니어링 매니저 한 명 정도로 단순할 수도 있습니다. 모든 회사는 저마다 다릅니다.
교육은 컴플라이언스 프로그램의 필수 구성 요소로서, 직원이 오픈소스 소프트웨어 사용을 규율하는 정책을 잘 이해하도록 돕습니다. 오픈소스 및 컴플라이언스 교육을 제공하는 목표는 오픈소스 정책과 전략에 대한 인식을 높이고, 오픈소스 라이선싱의 쟁점과 사실에 대한 공통된 이해를 구축하는 것입니다. 또한 제품이나 소프트웨어 포트폴리오에 오픈소스 소프트웨어를 포함할 때 발생하는 사업적, 법적 위험도 다루어야 합니다.
공식적인 교육 방법과 비공식적인 교육 방법을 모두 활용할 수 있습니다. 공식적인 방법으로는 직원이 과정을 이수하기 위해 지식 시험을 통과해야 하는 강사 주도 교육 과정이 있습니다. 비공식적인 방법으로는 웨비나, 브라운백 세미나, 신입 사원 오리엔테이션 세션의 일부로 진행하는 발표 등이 있습니다.
오픈소스 컴플라이언스 팀은 소스 코드 감사를 자동화하고, 오픈소스 코드를 발견하며, 그 라이선스를 식별하기 위해 도구를 자주 사용합니다. 이러한 도구로는 컴플라이언스 프로젝트 관리 도구, 소프트웨어 인벤토리 도구, 소스 코드 및 라이선스 식별 도구가 있습니다.
의도했든 아니든 오픈소스 소프트웨어가 포함된 제품을 출하했다면, 그 소프트웨어 컴포넌트를 규율하는 여러 라이선스를 준수해야 합니다. 그래서 코드 안에 무엇이 있는지 파악하는 일이 중요합니다. 완전한 명세가 있으면 컴플라이언스가 훨씬 쉬워지기 때문입니다.
컴플라이언스 준수는 단순한 작업이 아니며, 라이선스와 코드 구조에 따라 제품마다 다릅니다. 큰 틀에서 컴플라이언스를 준수한다는 것은 다음을 의미합니다.
종합적인 컴플라이언스 프로그램의 이점 중 하나는 안전하지 않은 버전의 오픈소스 컴포넌트가 포함된 제품을 더 쉽게 찾아 교체할 수 있다는 점입니다. 대부분의 소스 코드 스캐닝 도구는 이제 오래된 소프트웨어 컴포넌트에서 공개된 보안 취약점을 표시하는 기능을 제공합니다. 오픈소스 컴포넌트를 업그레이드할 때 중요한 고려 사항 하나는, 해당 컴포넌트가 이전 버전과 동일한 라이선스를 유지하는지 항상 확인하는 것입니다. 오픈소스 프로젝트가 메이저 릴리스에서 라이선스를 변경한 사례가 간혹 있기 때문입니다.
기업은 보안 취약점이 있는 버전을 사용하는 상황을 피하기 위해 오픈소스 프로젝트 커뮤니티에 참여하는 것이 좋습니다. 사용하는 모든 오픈소스 프로젝트에 활발히 참여하는 것은 합리적이지도 실현 가능하지도 않으므로, 가장 중요한 컴포넌트를 식별하기 위한 일정 수준의 우선순위 설정이 필요합니다. 참여 수준은 메일링 리스트 가입과 기술 토론 참여부터 버그 수정 및 소규모 기능 기여, 나아가 주요 기여에 이르기까지 다양합니다. 최소한 특정 오픈소스 프로젝트에서 작업하는 기업 개발자는 보안 취약점 및 사용 가능한 수정과 관련된 보고를 받기 위해 해당 메일링 리스트를 구독하고 모니터링하는 것이 유익합니다.
규모를 막론하고 모든 조직이 취할 수 있는 가장 쉽고 효과적인 첫 단계는 오픈체인 프로젝트(OpenChain Project)에 참여하여 “오픈체인 적합(OpenChain Conformant)” 상태를 획득하는 것입니다. 이는 일련의 질문에 온라인으로 또는 수동으로 답변함으로써 이루어집니다. 오픈체인 적합성에 사용되는 질문은 조직이 오픈소스 소프트웨어 컴플라이언스를 위한 프로세스나 정책을 마련했는지 확인하는 데 도움을 줍니다. 오픈체인은 ISO 9001과 유사한 산업 표준입니다. 정밀한 프로세스와 정책 구현은 개별 조직에 맡기고 “큰 그림"에 초점을 맞춥니다. 오픈체인 적합성은 오픈소스 컴플라이언스 프로세스나 정책이 존재하며, 공급업체나 고객이 요청할 때 추가 세부 사항을 공유할 수 있음을 보여 줍니다. 오픈체인은 전 세계 공급망 전반에서 조직 간 신뢰를 구축하도록 설계되었습니다.
Linux Foundation의 자가 평가 체크리스트(Self-Assessment Checklist)는 컴플라이언스 모범 사례에 더해, 컴플라이언스 프로그램이 성공하기 위해 갖추어야 할 요소까지 담은 광범위한 체크리스트입니다. 기업은 이 내부용 자가 점검 체크리스트를 활용하여 자사의 컴플라이언스를 컴플라이언스 모범 사례와 비교 평가할 수 있습니다.
인수 기업으로서 감사를 의뢰하기 전에 조치를 취하고 결정을 내려야 하며, 결과를 받은 뒤에는 추가적인 의무사항이 있습니다.
앞서 논의한 것처럼 세 가지 주요 감사 방법을 사용할 수 있으며, 자신의 구체적인 상황에 가장 적합한 방법이 무엇인지 결정해야 합니다.
소스 코드 감사 보고서는 스캔한 코드의 복잡도에 따라 상당한 양의 정보를 제공할 수 있습니다. 어떤 라이선스와 사용 사례가 중요한 것으로 간주되는지 식별하는 것이 중요합니다.
오픈소스 감사 보고서는 인수 대상 기업(타깃)의 소스 코드와 관련 라이선스에 대한 많은 정보를 제공합니다. 그러나 컴플라이언스(compliance) 관련 우려 사항을 명확히 하거나 확인하려면 그 밖의 여러 데이터 항목에 대한 추가 조사가 필요합니다. 이 절에서는 무엇이 중요한지 정리하고, 인수 대상 기업에 다루어야 할 질문을 구성하기 위한 출발점으로 일련의 질문을 제시합니다.
경우에 따라 오픈소스 감사가 인수 기업에게 용인되지 않는 라이선스나 컴플라이언스 관행의 사례를 드러낼 수 있습니다. 이때 인수 기업은 거래 종결(closing)의 조건으로 해당 사례를 완화하도록 요청할 수 있습니다. 예를 들어 인수 대상 기업이 라이선스 A로 제공되는 코드 컴포넌트를 사용하지만, 인수 기업은 라이선스 A로 라이선스된 어떠한 소스 코드도 사용하지 못하게 하는 엄격한 정책(policy)을 두고 있을 수 있습니다. 이러한 상황에서는 양측이 논의하여 가능한 해결책을 찾아야 합니다.
컴플라이언스 개선 계획 수립은 인수 기업이 자회사로 계속 운영될 소규모 스타트업을 인수하는 대기업인 경우 특히 중요합니다. 이러한 상황에서 인수 기업은 인수 대상 기업이 공식 컴플라이언스 정책과 프로세스를 수립하도록 돕고, 자사의 관행에 대한 교육을 제공하며, 지속적인 안내와 지원을 제공하는 경우가 많습니다.
오픈소스 라이선스 컴플라이언스(compliance) 활동을 뒷받침하는 개발 관행을 어떻게 마련할지에 관해서는 이미 여러 문헌에서 상세한 권고가 나와 있습니다. 이 장에서는 그 가운데 가장 중요한 관행을 간략히 짚습니다. 이를 지키면 흔히 발생하는 컴플라이언스 문제의 상당수를 없앨 수 있습니다.
오픈소스 실사(due diligence)는 일반적으로 인수합병(M&A) 거래에서 성공적으로 완료해야 하는 긴 작업 목록 가운데 하나일 뿐입니다. 그렇더라도 소프트웨어의 핵심적인 역할과 잠재적 지식재산권(IP) 위험을 고려하면, 전반적인 실사 과정에서 여전히 중요한 측면입니다. 오픈소스 실사는 오래 걸리는 과정처럼 보일 수 있지만, 양측이 준비되어 있고 신속한 컴플라이언스(compliance) 서비스 제공업체와 협력한다면 빠르게 마무리되는 경우가 많습니다.
그렇다면 어떻게 준비할 수 있을까요?
대상 기업이라면, 개발 및 사업 프로세스에 다음 항목을 포함시켜 적절한 오픈소스 컴플라이언스 관행을 유지할 수 있습니다.
인수 기업이라면, 무엇을 살펴야 하는지 알고 문제를 신속히 해결할 역량을 갖추고 있어야 합니다.
오픈소스 컴플라이언스는 지속적인 과정입니다. 좋은 오픈소스 컴플라이언스 관행을 유지하면 잠재적 인수, 매각, 제품이나 서비스 출시 등 소프트웨어의 소유나 관리가 바뀌는 어떠한 상황에도 대비할 수 있습니다. 이런 이유로 기업은 오픈소스 컴플라이언스 프로그램을 구축하고 개선하는 데 투자할 것을 강력히 권장합니다.