10.3 조달, 오픈 소스, 라이선스

개요와 동기

거의 모든 현대 소프트웨어 시스템은 대부분 다른 누군가가 쓴 구성 요소로 조립됩니다. 오픈 소스 소프트웨어는 운영체제, 언어, 프레임워크, 데이터베이스, 클라우드 인프라의 기반을 이룹니다. 그것은 두 경로로 기업에 들어옵니다. 의도적인 조달과, 개별 개발자의 무심한 import 문입니다. 이 장은 그 소비(그리고 알맞은 곳에서는 기여)를 의도적으로 하는 것에 관한 것입니다. 곧 전략, 라이선스 컴플라이언스, 의무와 카피레프트 위험에 대한 이해, 의존하는 구성 요소의 피할 수 없는 수명 종료에 대한 계획입니다.

큰 팀에게 판돈은 법적이고, 운영적이고, 전략적인 것이 한꺼번에입니다. 법적으로 오픈 소스 라이선스는 실제 의무를 지닌 집행 가능한 계약입니다. 카피레프트(파생물을 같은 조건으로 공유하도록 요구할 수 있는 라이선스 방식)를 잘못 다루면 최악의 경우 독점 소스의 공개를 강제하거나 소송을 촉발할 수 있습니다. 라이선스 위반은 실사 중에 인수나 공개 상장을 막을 수도 있습니다. 운영적으로 관리되지 않는 의존성은 썩습니다. 구성 요소가 유지되지 않고, 취약점이 쌓이고, 여전히 프로덕션 깊숙이 묻힌 채 수명이 종료됩니다. 전략적으로 오픈 소스는 비용 절감 투입물 이상입니다. 종속을 피하고, 인재를 끌어들이고, 의존하는 생태계를 형성하는 방법이며, 의도를 갖고 참여할 때만 얻는 이점입니다.

정부에는 추가 차원이 있습니다. 많은 관할권이 이제 오픈 소스, 개방형 표준, 기관 간 코드 공유를 선호하는 명시적 정책을 갖고 있습니다. 흔히 “공적 자금, 공적 코드”로 표현되는데, 납세자가 자금을 댄 소프트웨어는 기본적으로 대중에게 제공되어야 한다는 원칙입니다. 그래서 공공 부문 엔지니어는 라이선스 컴플라이언스와, 오픈 소스를 선호하고, 공개하고, 재사용하라는 적극적 의무를 모두 헤쳐 나가야 합니다. 이 장은 그 모두를 규모에서 관리할 수 있게 하는 것을 목표로 합니다.

핵심 원칙

오픈 소스는 공짜 물건이 아니라 공급망입니다. 소비하는 구성 요소를 어떤 핵심 공급자와도 같은 엄밀함으로 다루십시오.
라이선스는 무시해도 되는 허락이 아니라 의무입니다. 모든 의존성에는 조건이 있습니다. 출하하기 전에 알아 두십시오.
카피레프트는 금기가 아니라 설계 제약입니다. 카피레프트 라이선스는 쓸 만하고 가치가 있습니다. 소프트웨어를 어떻게 결합하고 배포하는지 이해하기만 하면 됩니다.
의도적으로 소비하고 전략적으로 기여하십시오. 무엇을 들여올지 결정하고, 도움이 되는 곳에서는 포크하는 대신 업스트림에 투자하십시오.
모든 것의 목록을 만드십시오. 보이지 않는 것은 준수하고, 보호하고, 갱신할 수 없습니다. SBOM(소프트웨어 자재 명세서, 소프트웨어에 든 구성 요소의 완전한 목록)은 기본 요건입니다.
처음부터 수명 종료를 계획하십시오. 모든 의존성은 언젠가 유지되지 않게 됩니다. 떠밀리기 전에 출구를 아십시오.
정부에서는 기본을 개방으로. 개방형 표준과 오픈 소스를 선호하고, 특별한 이유가 없는 한 공적 자금 코드를 공개하십시오.

권장 사항

오픈 소스 전략과 소비 정책을 정한다

개발자가 조직에 오픈 소스를 들여오는 방식에 대한 분명한 정책을 공표하십시오. 어떤 라이선스가 사전 승인되고, 어떤 것이 리뷰를 요하고, 어떤 것이 여러분의 사용 사례에서 금지되는지입니다. 빠르고 마찰이 낮은 승인 경로를 제공하십시오. 코드를 복사하는 것보다 느린 정책은 그냥 무시됩니다. 맥락을 구별하십시오. 같은 라이선스도 구성 요소가 서비스로 내부에서 쓰일 때, 배포되는 제품에 내장될 때, 독점 애플리케이션에 링크될 때 다르게 동작하기 때문입니다. 쉬운 길이 준수하는 길이 되게 하십시오. 검증된 구성 요소의 큐레이션된 내부 저장소, 파이프라인의 자동 스캔, 일상적인 경우에 변호사를 부르지 않고도 개발자가 따를 수 있는 분명한 안내입니다.

라이선스 컴플라이언스, 의무, 카피레프트 위험을 관리한다

라이선스 계열과 그 의무를 알아 두십시오. 허용형 라이선스(MIT, BSD, Apache 2.0 등)는 주로 귀속 표시와 고지 보존을 요구하며, Apache 2.0은 명시적 특허 허여를 더합니다. 약한 카피레프트(예: LGPL과 MPL)는 해당 파일의 수정을 공유하라고 요구하되 대개 독점 코드와의 결합은 허용합니다. 강한 카피레프트(예: GPL)는 배포되는 저작물 전체를 같은 조건으로 제공하라고 요구할 수 있습니다. 네트워크 카피레프트(AGPL)는 그 의무를 바이너리로 배포되는 소프트웨어만이 아니라 네트워크로 제공되는 소프트웨어까지 확장합니다. 가장 중요한 의무는 두 가지에 달려 있습니다. 소프트웨어를 배포하는지, 구성 요소를 얼마나 긴밀하게 결합하는지입니다. 컴플라이언스를 자동화하십시오. 의존성의 라이선스를 스캔하고, 필요한 귀속 및 고지 파일을 생성해 출하하고, 금지된 라이선스가 조용히 프로덕션에 들어갈 수 없도록 정책으로 빌드를 관문 통제하십시오.

오픈 소스 프로그램 오피스(OSPO)를 세운다

오픈 소스를 규모에서 소비한다면 오픈 소스 전략, 정책, 컴플라이언스 도구, 기여 거버넌스, 커뮤니티 관계를 소유하는 구심점인 OSPO를 만드십시오. OSPO는 모든 팀이 각자 결정하는 혼돈을 억제합니다. 개별 팀이 유지할 수 없는 전문성을 제공합니다. 그리고 전략적 가치를 포착합니다. 어떤 프로젝트에 투자할지, 언제 업스트림에 기여할지, 자체 오픈 소스 프로젝트를 어떻게 잘 공개할지 결정하는 것입니다. 작은 OSPO(때로 한 사람과 부서 간 실무 그룹)도 난장판에 비해 일관성을 극적으로 높이고 법적 위험을 줄입니다.

기여와, 알맞은 곳에서는 공개를 다스린다

언제 되돌려 기여할지 의도적으로 결정하십시오. 의존하는 프로젝트에 수정과 기능을 업스트림하면 비공개 패치를 짊어지지 않게 되어 유지 보수 부담이 줄어듭니다. 또한 호의와 영향력을 쌓고, 여러분에게 중요한 구성 요소를 강화합니다. 지적 재산권과 기여자 계약을 어떻게 다루는지를 포함해, 승인된 기여를 위한 분명하고 빠른 프로세스를 개발자에게 주십시오. 자체 오픈 소스 프로젝트를 공개할 때는 제대로 하십시오. 적절한 라이선스를 고르고, 거버넌스를 문서화하고, 스튜어드십을 약속하십시오. 버려진 프로젝트는 프로젝트가 없는 것보다 평판을 더 해칩니다.

정부의 오픈 소스 및 “공적 자금, 공적 코드” 의무를 충족한다

공공 부문 팀은 개방성을 기본으로 다루어야 합니다. 종속을 피하고 기관과 벤더 사이에서 일하도록 개방형 표준을 선호하십시오. 보안에 민감한 구성 요소, 제3자 권리, 프라이버시 우려 같은 특정하고 문서화된 예외가 적용되지 않는 한 공적 자금으로 개발한 소스 코드를 공개적으로 게시하십시오. 만들기 전에 재사용하십시오. 다른 기관이 이미 알맞은 코드를 공개했는지 확인하십시오. 이런 기대를 조달에 녹여, 기관이 유지하거나 공유할 수 없는 독점 블랙박스가 아니라, 정부가 적절한 권리를 유지한 채 벤더가 개방적이고 재사용 가능하며 잘 문서화된 코드를 전달하게 하십시오.

의존성과 수명이 종료된 소프트웨어를 관리한다

모든 구성 요소와 그 버전, 라이선스, 유지 상태의 라이브 목록(SBOM)을 유지하십시오. 의존성을 합리적으로 최신으로 유지하십시오. 작고 잦은 갱신이 드문 거대한 도약보다 훨씬 싸고 안전합니다. 업스트림 프로젝트의 수명 종료 공지와 보안 지원 기간을 지켜보고, 취약점이 허둥지둥을 강요한 뒤가 아니라 지원이 끝나기 전에 이전을 계획하십시오. 버려질 위험이 있는 핵심 구성 요소는 메인테이너에게 자금을 댈지, 직접 유지 보수에 기여할지, 포크할지, 교체할지 미리 결정하십시오. 상용과 오픈 소스 소프트웨어 모두 수명 종료를 추적하고, 지원이 끝나는 것을 다른 운영 위험과 같은 기준으로 다루십시오.

장단점

선택	장점	단점
오픈 소스를 자유롭게 소비	빠른 전달. 엄청난 레버리지. 라이선스 비용 없음	이제 떠안는 라이선스, 보안, 유지 보수 의무
엄격한 라이선스 허용 목록	낮은 법적 위험. 예측 가능	팀을 늦춤. 정말 쓸모 있는 구성 요소를 배제할 수 있음
허용형 라이선스만	최소한의 의무. 결합이 쉬움	가치 있는 카피레프트 프로젝트를 포기. 상호성 감소
알맞은 곳에서 카피레프트 수용	강한 생태계에 접근. 상호성의 이점	결합과 배포에 주의가 필요
업스트림에 기여	비공개 패치 부담 감소. 영향력. 호의	지속적인 노력. 지적 재산권과 프로세스 오버헤드
대신 독점으로 구축	완전한 통제. 외부 의무 없음	높은 비용. 범용품을 재발명. 영원히 직접 유지
정부의 기본 공개	투명성. 재사용. 종속 회피	공개 노력. 보안 리뷰. 지속적 스튜어드십

중심 긴장은 개발자 속도 대 통제입니다. 모든 것을 무거운 리뷰 뒤에 잠그면 개발자는 정책을 우회합니다. 그것은 관리되지 않는 그림자 의존성을 낳으며, 허용적이지만 보이는 접근보다 나쁩니다. 전혀 통제하지 않고 두면 법적, 보안적 부채가 보이지 않게 쌓입니다. 해법은 자동화와 큐레이션입니다. 사전 검증된 구성 요소, 파이프라인 스캔, 분명한 기본값으로 준수하는 길을 가장 빠른 길로 만들어 마찰 없이 통제를 얻으십시오. 카피레프트에서 상충은 “위험 대 안전”이 아니라 “이해함 대 이해하지 못함”입니다. 어떻게 결합하고 배포하는지 알고 나면 카피레프트는 완전히 쓸 수 있습니다.

팀과 논의할 질문

내부, 배포, 네트워크 제공 맥락에 걸친 강한 카피레프트와 네트워크 카피레프트에 대한 명시적 규칙은 무엇입니까? 카피레프트는 금기가 아니라 설계 제약이며, 의무는 두 가지에 달려 있습니다. 소프트웨어를 배포하는지, 구성 요소를 얼마나 긴밀하게 결합하는지입니다. 내부 도구의 GPL은 출하하는 제품에 링크된 GPL과 매우 다르게 동작하고, AGPL은 공개 의무를 단지 네트워크로 제공하는 소프트웨어까지 확장하므로 서비스로 운영하는 것에 대한 구축 대 채택 계산이 바뀝니다. 개발자가 변호사를 부르지 않고도 알 수 있도록 맥락별로 규칙을 적으십시오. 예를 들어 허용형은 어디서나 사전 승인되고, 강한 카피레프트는 내부에서는 괜찮지만 출하하는 제품에서는 차단되고, AGPL은 네트워크 서비스에 닿기 전에 리뷰가 필요합니다. 증거를 가져오십시오. 현재 의존성 트리를 스캔해 카피레프트 구성 요소가 이미 배포 경계에 대해 어디에 있는지 찾아보십시오. 그다음 그 정책으로 빌드를 관문 통제하십시오. 어떤 스캐너도 시행하지 않는 규칙은 개발자가 실수로 깨뜨릴 규칙이기 때문입니다.
오픈 소스 프로그램 오피스가 필요하며, 오늘 라이선스 정책, 스캔, 기여 결정은 누가 소유합니까? 정직한 답이 “아무도”나 “각 팀이 결정합니다”라면 법적, 보안적 부채를 보이지 않게 쌓는 난장판을 운영하는 것입니다. OSPO는 한 사람과 부서 간 실무 그룹이어도 그 혼돈을 억제하고 전략적 가치를 포착합니다. 어떤 업스트림 프로젝트에 투자할지, 언제 기여할지, 자체 프로젝트를 어떻게 잘 공개할지입니다. 회의에 증거를 가져오십시오. 누구든 현재의 승인된 라이선스 목록, SBOM, 인수 실사 중 카피레프트 질문을 받을 사람의 이름을 내놓을 수 있습니까? 답은 분명한 소유권을 배정하고, 사전 검증된 구성 요소와 파이프라인 스캔으로 준수하는 길을 가장 빠른 길로 만들어, 개발자가 마찰 없이 통제를 얻게 해야 합니다. 코드를 복사하는 것보다 느린 정책은 그냥 무시됩니다.
내일 버려지면 가장 아플 의존성은 무엇이며, 각각에 대해 미리 정한 대응은 무엇입니까? 모든 의존성은 결국 수명이 종료되며, 그 사건의 비싼 버전은 핵심 구성 요소가 몇 달 전에 지원을 잃었음을 취약점이 주의를 강제할 때에야 발견하는 것입니다. 버려질 위험이 있는 핵심 구성 요소는 메인테이너에게 자금을 댈지, 직접 유지 보수에 기여할지, 포크할지, 교체할지 미리 결정하십시오. 증거를 가져오십시오. SBOM에서 실패하면 매출이나 임무에 핵심인 서비스가 멈출 구성 요소를 나열하고 각각의 유지 상태와 보안 지원 기간을 적어 두십시오. 답은 수명 종료를 놀람에서, 계획된 이전이 있는 추적되는 운영 위험으로 바꿔야 하며, 다른 위험과 같은 기준으로 다뤄져야 합니다. 의존성을 작고 잦은 단계로 최신으로 유지하는 것이 드물고 거대하고 강제된 도약보다 훨씬 쌉니다.
전이적 의존성 트리 끝까지 닿는 완전하고 최신인 SBOM을 만들 수 있으며, 얼마나 빨리 가능합니까? 널리 쓰이는 라이브러리에 화제의 취약점이 닿으면 리더십이 가장 먼저 묻는 질문은 “우리가 노출되어 있고, 어디입니까?”입니다. 몇 시간 안에 답하지 못하는 팀은 이미 뒤처진 것입니다. 진짜 위험은 보통 아무도 의도적으로 고르지 않은 의존성 여러 층 아래에 숨어 있기 때문입니다. 경쟁하는 고려는 비용과 잡음입니다. 많은 서비스에 걸친 완전한 전이적 목록은 크고 끊임없이 변하는 목록을 만들고, 과도한 알림은 사람들이 그것을 무시하도록 가르치므로, 어떤 깊이와 어떤 심각도가 실제로 행동을 촉발하는지 정해야 합니다. 논의에 증거를 가져오십시오. 지금 프로덕션 서비스 하나의 새 SBOM을 생성해 보고, 직접 대 전이적 구성 요소가 몇 개인지 세고, 얼마나 걸렸는지 재 보십시오. 기업이나 정부 기관에서는 이를 구체적인 인시던트 대응 목표와, 영향받는 구성 요소를 공개해야 하는 규제 의무에 묶으십시오. 열거할 수 없는 노출을 보고하라는 의무는 어기게 될 의무이기 때문입니다.
핵심 의존성은 언제 공짜로 다루는 대신 자금을 대고, 기여하고, 스튜어드십을 질 가치가 있습니까? 대부분의 조직은 오픈 소스를 공공요금처럼 소비하다가, 매출 서비스를 받치는 구성 요소가 무급 자원봉사자 한 명임을 알고 충격을 받습니다. 메인테이너에게 자금을 대거나, 수정을 업스트림하거나, 자체 프로젝트를 공개하고 스튜어드십을 지기로 의도적으로 결정하면 취약한 공짜 투입물이 지속되고 영향력 있는 것으로 바뀌며, 엔지니어가 모든 업그레이드를 거쳐 비공개 패치를 짊어지는 것도 막습니다. 긴장은 기여와 스튜어드십이 실제로 지속적인 엔지니어링 시간을 들이고 지적 재산권과 프로세스 오버헤드를 지니므로 모든 것에 할 수는 없다는 것입니다. 증거를 가져오십시오. SBOM에서 실패하면 임무에 핵심인 서비스가 멈출 소수의 구성 요소를 표시하고, 각각의 메인테이너 수, 자금, 이미 그것에 대해 짊어진 비공개 패치가 몇 개인지 적어 두십시오. 크거나 공공 조직에서는 요란하게 공개한 오픈 소스 릴리스가 버려졌을 때의 평판 비용을 저울질하고, 정부에서는 공개된 공적 자금 코드의 지속적 스튜어드십을 선택적 부가물이 아니라 전달의 일부로 다루십시오.
조달이 실제로 필요한 권리를 갖춘 개방적이고 재사용 가능하며 잘 문서화된 코드를 전달합니까, 아니면 유지하거나 벗어날 수 없는 독점 블랙박스입니까? 오픈 소스 전문성 없이 쓴 계약은 후회할 통제를 벤더에게 상습적으로 넘깁니다. 닫힌 형식, 공개하거나 수정할 권리 없음, 벤더가 떠난 뒤 기관이 패치할 수 없는 의존성입니다. 이를 일찍 제대로 하는 것이 갱신 때 떠날 수 없음을 발견하는 것보다 훨씬 쌉니다. 경쟁하는 고려는 속도와 벤더 선택입니다. 개방적 산출물과 이식성을 요구하면 후보가 좁아지고 낙찰이 늦어질 수 있으며, 정말 쓸모 있는 일부 공급자는 이에 저항합니다. 증거를 가져오십시오. 최근 계약 두 개를 뽑아 라이선스 조건, 소스 코드 전달, 문서화 표준, SBOM 제공, 조직이 유지하는 권리를 명시하는지 확인하십시오. 기업 조달에서는 이를 종속과 총비용 분석에 연결하고, 정부에서는 기본 개방과 “공적 자금, 공적 코드” 의무, 그리고 시스템 전체가 아니라 보안에 민감한 부분만 닫게 하는 문서화된 예외 프로세스에 연결하십시오.

분야별 관점

스타트업. 거의 모든 것을 오픈 소스로 조립하고 변호사가 없으니 규칙을 한 페이지로 유지하십시오. MIT와 Apache 2.0 같은 허용형 라이선스는 사전 승인, 강한 카피레프트는 내부 도구에는 괜찮지만 출하하는 제품에서는 차단, 이상한 것은 창업자가 빠르게 리뷰합니다. 파이프라인에 라이선스와 취약점 스캔을 더하고 첫날부터 SBOM을 유지하십시오. 이를 제대로 하는 가장 싼 순간은 인수자의 실사가 의존성 트리를 빗질하기 전이기 때문입니다. 두려움 때문에 카피레프트를 금지하지 마십시오. 이해하고 넘어가십시오.

소기업. 오픈 소스 전문가도 없고 예산도 빠듯하니 인력보다 도구에 기대십시오. 빌드의 스캐너와 짧은 승인 라이선스 목록이 사람이 할 일의 대부분을 합니다. 소비를 구매 대 구축으로 정직하게 구성하십시오. 잘 유지되는 개방 구성 요소를 재발명하는 것은 보통 비싼 선택이지만, 목록을 만든 적 없는 것에 의존하는 것도 그렇습니다. 무엇을 어떤 라이선스로 쓰는지 단순한 기록을 유지해, 고객의 보안 설문지나 취약점 알림이 허둥지둥이 되지 않게 하십시오.

대기업. 규모에서 문제는 많은 팀에 걸친 일관성이므로, 정책, 자동 스캔, 귀속 표시 생성, 기여 거버넌스를 소유하는 OSPO를 세우고, 큐레이션된 사전 검증 구성 요소로 준수하는 길을 가장 빠른 길로 만드십시오. 맥락별 카피레프트 규칙을 파이프라인에서 시행하고, 서비스 전반의 SBOM을 유지하고, 의존성 최신성과 수명 종료를 추적되는 운영 위험으로 관리하십시오. 오픈 소스를 코드베이스 대부분에 대한 공급망 관리로 다루되, 인수 실사에 쓸 감사 준비 증거를 갖추십시오.

정부. 개방성은 선택이 아니라 의무인 경우가 많으니, 보안, 제3자 권리, 프라이버시에 대해 문서화된 예외가 적용되지 않는 한 기본을 개방형 표준으로 하고 공적 자금 코드를 공개하십시오. 정부 전반의 카탈로그를 확인해 만들기 전에 재사용하고, 개방적이고 재사용 가능하며 잘 문서화된 산출물과 유지되는 권리를 조달에 녹여 독점 블랙박스가 아니라 유지 가능한 코드를 받으십시오. 공개된 코드를 진짜 스튜어드십으로 유지하고, 예외 프로세스는 꼭 필요한 것만 닫도록 좁고 투명하게 유지하십시오.

사례

스타트업. 모바일 앱을 만드는 네 명의 스타트업이 거의 모든 것을 오픈 소스로 조립하고 상근 변호사가 없습니다. 창업자들은 두려움에 카피레프트를 금지하는 대신 한 페이지짜리 정책을 씁니다. MIT와 Apache 2.0 같은 허용형 라이선스는 사전 승인, GPL 같은 강한 카피레프트는 내부 도구에는 괜찮지만 공개 의무를 피하려고 출하하는 앱에서는 차단, 특이한 것은 창업자가 빠르게 리뷰합니다. 파이프라인에 라이선스와 취약점 스캔을 더해 금지된 라이선스가 릴리스에 슬며시 들어가지 못하게 하고, 첫날부터 SBOM을 유지하고, 핵심 라이브러리에 작은 수정을 업스트림해 모든 업그레이드를 거쳐 비공개 패치를 짊어지는 일을 멈춥니다. 이를 일찍 제대로 한 덕에 인수자의 실사가 결국 의존성 트리를 빗질할 때의 고통스러운 놀람도 면합니다.

기업. 배포되는 제품을 출하하는 한 소프트웨어 벤더가 OSPO를 운영합니다. OSPO는 승인된 라이선스 목록, 큐레이션된 내부 구성 요소 저장소, 모든 파이프라인의 자동 라이선스 및 취약점 스캔을 유지합니다. 개발자가 새 의존성을 끌어오면 파이프라인이 그 라이선스를 정책과 대조하고, 제품과 함께 출하되는 귀속 고지를 생성하고, 리뷰가 필요한 것을 표시합니다. 강한 카피레프트 구성 요소는 공개 의무를 피하려고 내부 도구에는 허용되지만 배포되는 제품에서는 차단됩니다. 회사는 몇 개의 핵심 의존성에 수정을 업스트림합니다. 그 덕에 엔지니어가 모든 업그레이드를 거쳐 짊어지던 비공개 패치의 적체가 사라졌습니다.

정부. 한 국가 디지털 서비스가 “공적 자금, 공적 코드” 정책 아래 운영됩니다. 새 서비스는 개방형 표준 위에 만들어지고, 기본적으로 공개 코드 저장소에서 공개적으로 개발되며, 기관 사이에서 재사용됩니다. 조달 템플릿은 정부가 공개하고 수정할 권리를 유지한 채 벤더가 개방적이고, 잘 문서화되고, 재사용 가능한 코드를 전달하도록 요구합니다. 새 구성 요소를 시작하기 전에 팀은 정부 전반의 카탈로그에서 기존 재사용 가능한 코드를 검색합니다. 보안에 민감한 모듈은 시스템 전체를 닫는 대신 문서화된 프로세스를 통해 공개에서 면제됩니다.

비즈니스 사례: 동기, ROI, TCO

오픈 소스를 잘 관리하는 것은 그 엄청난 레버리지를 포착하는 것과 숨은 비용을 치르는 것의 차이입니다. 오픈 소스는 큰 조직이 스스로는 결코 지을 여력이 없는 기반 위에 서게 해 줍니다. 그러나 총소유비용에는 컴플라이언스, 보안 패치, 결국의 이전이 포함되며, 이 비용은 계획하든 안 하든 도착합니다. 의도적 관리는 예측할 수 없고 비싼 위기를 작고 꾸준하고 계획된 비용으로 바꿉니다. 그 위기에는 인수 실사 중 발견된 카피레프트 위반, 버려진 구성 요소에서의 긴급 이전, 아무도 거기 있는 줄 몰랐던 의존성의 취약점이 포함됩니다.

도입 비용은 노출에 비해 소박합니다. OSPO나 실무 그룹, 스캔 도구, 목록을 유지하는 규율입니다. 도입하지 않는 비용은 법적 책임, 실패한 실사, 패치되지 않은 의존성으로 추적되는 보안 인시던트, 결국 고통스러운 일괄 이전을 강요하는 미뤄진 업그레이드의 복리 비용으로 나타납니다. 리더십을 설득할 때 오픈 소스 관리를 코드베이스 대부분에 대한 공급망 관리로 구성하십시오. 전략적 이점도 적으십시오. 피한 종속, 더 빠른 전달, 인재 유치, 의존하는 생태계에 대한 영향력입니다. 정부에서는 의무 차원을 더하십시오. 개방성은 선택이 아니라 요구되는 경우가 많고, 잘하면 미준수와 중복된 공공 지출을 모두 피합니다.

안티패턴과 함정

복사해 붙이는 라이선싱. 라이선스 점검 없이 구성 요소를 끌어오고 감사나 인수 때에야 의무를 발견하는 개발자.
목록 없음. 취약점이나 라이선스 질문이 터질 때 “무엇을 어떤 라이선스로 쓰고 있는가?”에 답할 수 없는 것.
카피레프트 공황. 이해 대신 두려움으로 모든 카피레프트를 금지해 가치 있는 생태계를 포기하는 것.
버려진 오픈 소스 릴리스. 요란하게 프로젝트를 공개한 뒤 결코 유지하지 않아 평판을 해치는 것.
전이적 의존성 무시. 직접 의존성은 검증하면서 진짜 위험은 여러 층 아래에 숨는 것.
수명 종료의 놀람. 핵심 구성 요소가 몇 달 전에 지원을 잃었음을 취약점이 주의를 강제할 때에야 발견하는 것.
복사보다 느린 정책. 개발자가 우회할 만큼 무거운 컴플라이언스 프로세스가 보이지 않는 그림자 의존성을 만드는 것.
정부의 블랙박스. 기본 개방 원칙을 어기고 기관이 유지하거나, 공유하거나, 벗어날 수 없는 독점 시스템을 조달하는 것.

성숙도 모델

1단계, 시작. 개발자가 정책이나 목록 없이 오픈 소스를 자유롭게 추가합니다. 라이선스는 점검되지 않고 카피레프트 의무는 알려져 있지 않습니다. 수명 종료는 우연히, 보통 취약점이 주의를 강제할 때 발견됩니다. 아무도 오픈 소스 전략을 소유하지 않습니다.

2단계, 발전. 기본 정책과 승인된 라이선스 목록이 있고 일부 팀이 따릅니다. 스캔이 이루어지지만 흔히 수동이거나, 늦거나, 소수 프로젝트에만 적용됩니다. 주요 시스템에 목록이 유지되는 반면 전이적 의존성은 지도화되지 않습니다. 기여와 수명 종료 처리는 임시적이고 팀마다 일관되지 않습니다.

3단계, 표준화. OSPO나 그에 상응하는 것이 조직 전체의 전략, 정책, 도구를 소유합니다. 라이선스와 취약점 스캔이 모든 파이프라인에서 자동화되고, 귀속 및 고지 파일이 자동으로 생성되며, 금지된 라이선스가 들어올 수 없도록 빌드가 관문 통제됩니다. SBOM이 전이적 트리 끝까지 유지되고, 기여는 문서화된 프로세스를 따르고, 수명 종료는 계획된 이전과 함께 추적되며, 정부 팀은 기본으로 공개합니다.

4단계, 관리. 프로그램이 기준선에 대해 측정되고 통제됩니다. 서비스 전반의 정책 스캔 커버리지, 공개된 의존성 취약점 패치까지의 평균 시간, 보안 지원 기간 안에 있는 구성 요소의 비중, 라이선스 위반 누출률, 의존성 최신성 지연, 업스트림에 올린 비공개 패치 수를 추적합니다. 배포 경계에 대한 카피레프트 배치를 모니터링하고, 의견이 아니라 목표에 대한 지표가 각 진행 또는 중단 결정을 이끕니다.

5단계, 오케스트레이션. 오픈 소스가 조직 전체에 통합된 지속적으로 개선되는 전략적 자산입니다. 컴플라이언스는 완전히 자동화되어 비준수 구성 요소가 프로덕션에 닿을 수 없습니다. 핵심 업스트림 프로젝트에 의도적으로 투자하고, 일상적으로 기여하고, 잘 운영되는 자체 프로젝트의 스튜어드십을 집니다. 의존성 최신성과 수명 종료는 위험과 지표가 이동함에 따라 적응적으로 관리되며, 개방성은 진정한 경쟁적, 시민적 이점이 됩니다.

논의를 위한 아이디어

빠른 허용형 기본값과 법적, 보안적 부채를 피하는 데 필요한 통제 사이의 올바른 선은 어디입니까?
조직은 언제 핵심 업스트림 의존성을 공짜로 다루지 않고 자금을 대거나 유지해야 합니까?
자체 구성 요소 중 오픈 소스로 공개하고 스튜어드십을 질 가치가 있는 것을 어떻게 결정합니까?
정부에서 원칙을 침식하지 않으면서 기본 공개에서 구성 요소를 면제하는 방어 가능한 프로세스는 무엇입니까?
라이선스와 보안 리뷰는 현실적으로 전이적 의존성 얼마나 깊이 들어가야 합니까?
네트워크 카피레프트(AGPL)는 서비스로 제공하는 소프트웨어에 대한 구축 대 채택 계산을 바꿉니까?

핵심 요점

오픈 소스는 대부분의 코드베이스의 다수이며, 공짜이고 결과가 없는 것으로 다루지 말고 공급망으로 관리해야 합니다.
라이선스에는 실제 의무가 있습니다. 허용형, 약한 카피레프트, 강한 카피레프트, 네트워크 카피레프트 계열과, 배포와 결합이 의무를 어떻게 촉발하는지 이해하십시오.
큐레이션, 자동 스캔, 분명한 기본값으로 준수하는 길을 가장 빠른 길로 만드십시오. 아니면 개발자가 정책을 우회합니다.
규모에서 전략, 컴플라이언스, 기여, 스튜어드십을 소유할 OSPO를 세우십시오.
SBOM을 유지하고, 의존성을 작은 단계로 최신으로 유지하고, 위기를 강요하기 전에 수명 종료를 계획하십시오.
정부에서는 기본을 개방형 표준으로 하고 공적 자금 코드를 공개하되, 만들기 전에 재사용하십시오.

참고 문헌과 더 읽을거리

Heather Meeker, Open (Source) for Business and Open Source for Business
Van Lindberg, Intellectual Property and Open Source
The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
OpenChain (ISO/IEC 5230), Open Source Licence Compliance
Software Package Data Exchange (SPDX, ISO/IEC 5962) specification
CycloneDX SBOM specification
Free Software Foundation, GNU General Public Licence and GPL FAQ
Open Source Initiative, The Open Source Definition and approved licence list
Free Software Foundation Europe, Public Money, Public Code
U.S. Federal Source Code Policy and Code.gov guidance
UK Government, Technology Code of Practice and open-standards principles