10.12 오픈 소스 대 클로즈드 소스

개요와 동기

거의 모든 현대 시스템은 직접 쓴 소프트웨어, 산 소프트웨어, 공짜로 가져온 소프트웨어의 혼합입니다. 그중 둘에는 근본적인 선택이 따릅니다. 그 소프트웨어는 오픈 소스입니까 클로즈드 소스입니까? 오픈 소스 소프트웨어(OSS)는 프로그램을 정의하는 사람이 읽을 수 있는 지시문인 소스 코드를 누구나 사용하고, 연구하고, 수정하고, 재배포할 권리를 주는 라이선스로 배포됩니다. 클로즈드 소스 소프트웨어, 곧 독점 소프트웨어는 벤더가 소스 코드를 비공개로 유지하는 완성된 제품으로 배포됩니다. 라이선스에 따라 실행할 권리는 얻지만 작동 방식을 검사하거나 바꿀 권리는 얻지 못합니다. 중간 범주인 소스 공개 소프트웨어는 읽을 수 있도록 소스를 게시하되 사용, 수정, 재배포를 제한합니다. 표준 정의에 따르면 보이지만 개방적이지 않습니다.

비교하기 전에 두 가지를 분명히 해야 합니다. 첫째, “무료”는 모호합니다. 커뮤니티는 자유로서의 무료(수정하고 공유할 자유, 때로 “libre”라고 씀)와 가격으로서의 무료(비용 영, “gratis”)를 구별합니다. 오픈 소스는 가격이 아니라 자유에 관한 것입니다. 둘째, 오픈 소스 라이선스는 두 계열로 나뉩니다. 허용형 라이선스(MIT, BSD, Apache 2.0 등)는 코드를 닫힌 제품에 내장하는 것을 포함해 거의 무엇이든 하게 해 줍니다. 카피레프트 라이선스(GNU 일반 공중 사용 허가서, GPL 등)는 배포하는 파생물도 같은 개방 조건으로 공개하라고 요구하며, 이 상호성 규칙을 비판자는 “바이러스적”이라 부르고 지지자는 “동일 조건 공유”라 부릅니다.

이 장은 선택을 두 측면에서 봅니다. 소비자로서 오픈 소스 구성 요소를 채택할지 독점 구성 요소를 채택할지 결정합니다. 생산자로서 직접 만든 소프트웨어를 오픈 소스로 할지 결정합니다. 큰 기업, 특히 정부에게 두 결정 모두 라이선스 파일을 훨씬 넘어서는 무게를 지닙니다. 조달(10.3장), 디지털 주권(10.11장), 공급망 보안(4.2장), 상호 운용성(3.8장), 구축 또는 구매 계산(6.1장)에 닿습니다.

핵심 원칙

“개방”을 정의하는 것은 가격이 아니라 라이선스입니다. 라이선스를 읽으십시오. 무료와 오픈 소스는 서로 다른 주장입니다.
어느 모델도 본질적으로 더 안전하지 않습니다. 둘 다 훌륭할 수도 태만할 수도 있습니다. 코드의 개방성보다 코드를 둘러싼 실천이 더 중요합니다.
개방성은 의존을 줄이는 지렛대입니다. 소스에 대한 접근은 벤더 종속에 대한 궁극의 보호입니다.
운영 부담은 항상 여러분이 집니다. 얻는 것이 공짜라고 운영하는 것이 공짜는 아닙니다. 총소유비용이 진짜 이야기를 해 줍니다.
차별화 요소는 닫아 두고 범용품은 열 수 있습니다. 여러분을 구별하지 않는 것은 오픈 소스로 하고, 구별하는 것은 지키십시오.
카피레프트에는 결과가 있습니다. 배포하는 제품에 카피레프트 코드를 내장하기 전에 상호성 의무를 이해하십시오.
살아 있는 커뮤니티는 자산이고, 버려진 저장소는 부채입니다. 라이선스만이 아니라 프로젝트를 판단하십시오.

권장 사항

라이선스만이 아니라 프로젝트로 구성 요소를 평가한다

오픈 소스든 독점이든 의존성을 채택하기 전에 그 건강을 평가하십시오. 릴리스 주기, 메인테이너의 수와 다양성, 보안 보고에 대한 반응성, 채택의 폭입니다. 단일 메인테이너의 오픈 소스 라이브러리와 작은 독점 벤더는 같은 버스 팩터 위험(핵심 인물 한두 명이 떠나면 프로젝트가 무너질 위험)을 집니다. 기여자 기반이 넓거나 재무적으로 건전한 벤더의 구성 요소를 선호하고, 평가를 실사의 일부로 기록하십시오(10.2장, 4.2장).

라이선스를 일급 의무로 읽고 추적한다

모든 구성 요소와 그 라이선스의 목록을 유지하고, 어떤 라이선스 계열이 어떤 용도에 수용되는지에 대한 정책을 시행하십시오. 중요한 구별은 카피레프트입니다. 허용형 코드(MIT, Apache 2.0)는 일반적으로 닫힌 제품에 자유롭게 내장할 수 있습니다. 강한 카피레프트(GPL)는 배포하는 자체 파생물을 같은 조건으로 공개하도록 의무화할 수 있습니다. 의존성을 스캔해 구성 요소, 라이선스, 알려진 취약점을 식별하는 도구인 자동 소프트웨어 구성 분석(SCA)을 쓰고, 제품의 모든 구성 요소의 공식 목록인 소프트웨어 자재 명세서(SBOM)를 생성하십시오(10.3장, 4.2장).

개방성이 아니라 실천으로 보안을 판단한다

“많은 눈” 논증(리누스의 법칙: “충분히 많은 눈이 있으면 모든 버그는 얕다”)을 이유로 오픈 소스가 안전하다고 가정하지 마십시오. 그리고 모호성에 의한 보안(소스를 숨기면 결함도 숨겨진다는 잘못된 믿음)으로 독점 코드가 안전하다고 가정하지도 마십시오. 많은 눈은 자격 있는 사람들이 실제로 볼 때만 도움이 되며, 널리 쓰이는 많은 프로젝트가 얇게 유지됩니다. 두 모델 모두 공급망 위험을 집니다. 오픈 소스는 침해되거나 버려진 의존성으로, 독점은 검사할 수 없는 불투명한 코드와 업데이트 채널로 그렇습니다. 모델과 무관하게 버전을 고정하고, 출처를 검증하고, 지속적으로 스캔하고, 권고를 모니터링하십시오(4.2장).

퇴출과 상호 운용성을 위해 설계한다

나중에 교체할 수 있도록 개방형 표준과 이식 가능한 데이터 형식을 쓰는 구성 요소를 선호하십시오(3.8장, 10.11장). 오픈 소스에서는 궁극의 퇴출을 얻습니다. 프로젝트가 멈추면 포크(자체 사본을 만들어 유지)할 수 있습니다. 독점 소프트웨어에서는 앞서 보호 장치를 협상하십시오. 개방형 형식의 데이터 내보내기, 문서화된 API, 벤더가 소스를 제3자에게 맡겨 두었다가 벤더가 실패하면 여러분에게 공개하는 법적 약정인 소스 코드 에스크로입니다. 어느 종류든 단일 구성 요소가 시스템을 인질로 잡지 못하도록 설계하십시오.

정가가 아니라 총소유비용을 저울질한다

선택지를 라이선스 비용만이 아니라 취득, 통합, 운영, 지원, 교육, 업그레이드, 결국의 교체를 포함한 전 생애 비용인 총소유비용(TCO)으로 비교하십시오. 오픈 소스는 라이선스 비용을 더 높은 운영 및 인력 비용과 맞바꾸는 경우가 많습니다. 독점 소프트웨어는 예측 가능한 구독료를 종속과 더 적은 통제와 맞바꾸는 경우가 많습니다. 모델 자체의 비용도 포함하십시오. 스스로 지원하는 오픈 소스에는 사내 기술이, 독점 소프트웨어에는 벤더 관리 역량이 필요합니다.

생산자로서 여러분을 차별화하지 않는 것을 오픈 소스로 한다

자체 소프트웨어를 경쟁 우위나 임무 우위를 주는 것과 차별화되지 않는 배관으로 분류하십시오. 차별화 요소는 독점으로 유지하십시오. 커뮤니티가 유지와 개선을 나눌 수 있는 범용 인프라를 오픈 소스로 하는 것을 고려하십시오. 정부는 투명성, 재사용, 주권의 동인으로서 “공적 자금, 공적 코드”(납세자가 자금을 댄 소프트웨어는 기본적으로 공개되어야 한다는 원칙)를 저울질하십시오(10.5장, 10.11장). 라이선스를 의도적으로 고르십시오. 채택을 극대화하려면 허용형, 생태계를 열어 두려면 카피레프트입니다.

장단점

차원	오픈 소스	클로즈드 / 독점
취득 비용	보통 취득은 영	라이선스 또는 구독료
총소유비용	비용이 운영과 인력으로 이동	더 예측 가능하지만 종속 프리미엄
통제와 맞춤화	완전함. 소스를 읽고 바꿀 수 있음	벤더가 노출하는 것으로 제한
지원과 책임	커뮤니티 또는 유료 제3자. 책임을 물을 단일 상대 없음	계약상 지원과 분명한 책임 당사자
보안 태세	감사 가능. 정말 유지된다면 “많은 눈”	벤더 관리. 불투명. 모호성은 보호가 아님
수명 / 방치	유지되면 포크할 수 있음. 그래도 시들 수 있음	벤더의 생존 가능성과 로드맵에 달림
벤더 종속	낮음. 소스와 개방형 형식이 퇴출을 가능하게 함	표준과 에스크로로 완화하지 않으면 높음
생태계	개방형 커뮤니티와 상호 운용성	큐레이션되고 통합되며 때로 벽으로 둘러싸임

반복되는 긴장은 통제 대 편의와 책임입니다. 오픈 소스는 통제, 감사 가능성, 종속으로부터의 자유를 극대화하지만 역량, 통합, 지원을 스스로 공급하라고 요구합니다. 독점 소프트웨어는 지원되고, 통합되고, 책임지는 제품과 시행할 계약을 제공하지만 통제를 양보하고 종속을 부릅니다. 해법은 거의 전부 아니면 전무가 아닙니다. 대부분의 성숙한 자산은 오픈 소스 기반과, 지원, 책임, 전문 역량이 상충을 정당화하는 곳의 독점 시스템을 섞습니다.

팀과 논의할 질문

파이프라인에서 자동 SCA와 SBOM으로 라이선스 정책을 시행하고 있으며, 특히 출하 전에 강한 카피레프트를 잡습니까? 배포되는 독점 제품에 GPL 라이브러리를 내장하면 자체 소스를 공개해야 할 수 있고, 그 놀람은 보통 되돌리는 데 비쌀 때인 늦게 드러납니다. 모든 구성 요소와 그 라이선스의 목록을 유지하고, 어떤 라이선스 계열이 어떤 용도에 수용되는지 시행하고, 변호사가 출하 때 잡는 대신 파이프라인이 위반을 막도록 소프트웨어 구성 분석을 자동으로 돌리십시오. SBOM을 당연한 일로 생성하십시오. 크거나 정부 자산에서 이는 공급망 위생이기도 하고 조달 요구 사항인 경우가 많습니다. 현재 라이선스 목록, 혹은 없다는 사실을 가져오고 정책을 누가 소유할지 결정하십시오.
의존성을 채택할 때 실사로서 프로젝트 건강과 버스 팩터를 평가합니까? 단일 메인테이너의 오픈 소스 라이브러리와 작은 독점 벤더는 같은 위험을 집니다. 핵심 인물 한두 명이 떠나면 프로젝트가 무너집니다. 무엇이든 채택하기 전에 릴리스 주기, 메인테이너의 수와 다양성, 보안 보고에 대한 반응성, 채택의 폭을 평가하고 평가를 기록하십시오. 어느 모델도 기본적으로 더 안전하지 않습니다. “많은 눈”은 자격 있는 사람들이 실제로 볼 때만 도움이 되고, 널리 쓰이는 많은 프로젝트가 얇게 유지됩니다. 제품이 가장 의존하는 서너 개의 의존성을 가져와 각각에 대해 몇 사람이 떠나야 그것이 여러분의 문제가 되는지 물으십시오. 답할 수 없다면 그것이 스스로에게 빚진 평가입니다.
독점을 살 때 퇴출 보호 장치를 앞서 확보합니까? 독점 소프트웨어는 통제를 대가로 책임과 편의를 제공하며, 숨은 비용은 종속입니다. 벤더가 거의 구제 수단 없이 가격을 올리거나 서비스를 저하시킬 수 있게 하는 전환 비용입니다. 아직 레버리지가 있는 서명 전에 보호 장치를 협상하십시오. 개방형 형식의 데이터 내보내기, 문서화된 API, 벤더가 실패하면 소스를 공개하는 소스 코드 에스크로입니다. 오픈 소스에서 퇴출은 포크할 수 있는 능력이고, 독점에서는 퇴출을 계약에 써야 합니다. 가장 핵심적인 독점 시스템을 가져와 벤더가 가격을 두 배로 올리거나 망하면 실제로 어떻게 되는지 물으십시오. “발이 묶입니다”라는 답이라면 갱신 때 계약을 고치십시오.
직접 만드는 소프트웨어에서 무엇을 오픈 소스로 하고 무엇을 닫아 둘지 어떻게 결정하며, 그 판단을 내릴 권한은 누구에게 있습니까? 한 방향으로 틀리면 여러분을 차별화하는 바로 그 코드를 내주고, 다른 방향으로 틀리면 커뮤니티가 기꺼이 유지를 나눌 범용 배관을 쌓아 둡니다. 경쟁하는 압력은 실제입니다. 엔지니어는 공개 저장소의 채용과 평판 이점을 원하고, 제품과 법무는 경쟁자에게 우위를 넘기거나 보안에 민감한 휴리스틱을 노출할까 걱정합니다. 시스템을 임무를 차별화하는 것과 차별화되지 않는 인프라로 나눈 정직한 분류를 가져오고, 릴리스를 승인하는 사람이나 위원회의 이름을 정하십시오. 저장소를 푸시한 사람이 임시로 내린 결정이 핵심 자산이 새는 방식이기 때문입니다. 큰 기업에서 이 질문은 포트폴리오 전략이고, 정부에서는 납세자가 자금을 댄 소프트웨어는 기본적으로 공개되어야 한다는 “공적 자금, 공적 코드” 원칙과 부딪히므로, 어떤 예외(국가 안보, 사기 탐지, 개인 데이터)가 코드를 닫아 둘 근거가 되는지 미리 정하십시오.
구축 또는 구매 비교가 총소유비용 전체를 포착합니까, 아니면 여전히 라이선스 비용 영을 비용 영으로 다룹니까? 오픈 소스에서 가장 흔한 재무 실수는 “취득이 공짜”를 “운영이 공짜”로 읽고, 통합, 운영, 보안 대응, 유료 지원이 피한 어떤 라이선스든 왜소하게 한다는 것을 발견하는 것입니다. 긴장은 독점 구독이 청구서에서는 비싸 보이면서 종속 프리미엄을 숨기고, 오픈 구성 요소는 청구서에서는 공짜로 보이면서 비용을 자체 직원에게 옮긴다는 것입니다. 실제 결정 두세 개에 대해 같은 조건의 TCO 모델을 가져오십시오. 취득, 통합, 운영, 지원, 교육, 업그레이드, 보안 대응, 결국의 교체를 첫해가 아니라 전 생애로 가격을 매긴 것입니다. 기업이나 정부 자산에서는 운영 모델 자체의 비용을 더하십시오. 스스로 지원하는 오픈 소스는 채용하고 유지해야 하는 사내 기술을 요구하며, 그 항목을 빼 놓은 비교는 분석이 아니라 증거로 다루십시오.
구성 요소의 보안을 실천으로 판단합니까, 아니면 “많은 눈”이든 닫힌 코드의 비밀이든 개방성 라벨에 기댑니까? 두 기본값 모두 덫입니다. “많은 눈”은 자격 있는 사람들이 실제로 코드를 리뷰할 때만 보호하고 널리 쓰이는 많은 오픈 프로젝트가 지친 메인테이너 한 명으로 돌아가며, 공격자가 보지 못하는 것에 기대는 닫힌 소스는 통제가 아니라 모호성에 의한 보안입니다. 이 논쟁은 희소한 보안 노력을 어디에 쓸지를 바꾸기 때문에 중요하며, 정직한 답은 두 모델 모두 공급망 위험을 진다는 것입니다. 오픈 소스는 침해되거나 버려진 의존성으로, 독점은 검사할 수 없는 불투명한 업데이트 채널로 그렇습니다. 가장 핵심적인 구성 요소의 증거를 가져오십시오. 실제로 누가 리뷰하는지, 권고가 얼마나 빨리 패치되는지, 버전이 고정되고 출처가 검증되는지, SBOM을 생성하는지입니다. 크거나 정부 자산에서는 이를 조달과 지속적 스캔 의무에 묶으십시오. 규제 기관은 소스가 공개되었는지가 아니라 무엇을 검사했는지 물을 것이기 때문입니다.

분야별 관점

스타트업. 런웨이가 짧으니 라이선스 비용을 감당할 수 없고 프로젝트가 멈추면 포크할 자유를 원하므로 오픈 소스 기반 위에 만드십시오. 강한 카피레프트 라이브러리가 조용히 자체 소스를 공개하도록 의무화하지 않도록 출하하기 전에 구성 분석 스캔을 돌리고, 하나의 진짜 차별화 요소는 엄격히 닫아 두십시오. 채용에 도움이 된다면 작고 핵심이 아닌 도구를 오픈 소스로 하되, 짊어질 수 없는 유지 보수 부담에 인력을 두지 마십시오.

소기업. 사내 법무나 플랫폼 전문가가 없으니 라이선스를 통달할 주제가 아니라 잘못 읽어서는 안 되는 위험으로 다루십시오. 벤더가 패치와 책임을 소유하는 지원되는 독점 도구나 상용 오픈 소스 배포판을 선호하십시오. 운영할 수 없는 스택을 스스로 지원하는 것은 잘못된 절약이기 때문입니다. 무료 구성 요소를 채택할 때는 그 라이선스가 사용을 허락하는지, 프로젝트가 버려지지 않고 실제로 유지되는지 확인하십시오.

대기업. 규모에서 문제는 많은 팀에 걸친 일관성입니다. 서면 라이선스 정책, 모든 파이프라인의 자동 소프트웨어 구성 분석과 SBOM 생성, 팀별 습관이 아니라 TCO 기반의 구축 또는 구매 결정입니다. 오픈 소스와 독점 소프트웨어를 하나의 포트폴리오로 관리하고, 조달에서 개방형 형식과 소스 코드 에스크로 같은 퇴출 보호 장치를 표준화하고, 버려진 프로젝트 하나가 인시던트가 되지 않도록 핵심 의존성의 건강을 추적하십시오. 조직이 무엇을 오픈 소스로 하고 무엇을 닫아 둘지에 대한 분명한 규칙으로 생산자 측도 다스리십시오.

정부. 조달 규칙, 투명성 의무, 공적 책무가 모든 선택을 형성합니다. 기관 간 재사용과 디지털 주권을 진전시키도록 납세자가 자금을 댄 소프트웨어는 기본적으로 공개되어야 한다는 “공적 자금, 공적 코드”를 저울질하되, 보안에 민감하거나 개인 데이터를 다루는 코드에는 좁은 예외를 두십시오. 모든 독점 공급자에게 개방형 형식의 데이터 내보내기와 소스 코드 에스크로를 제공하도록 요구해 벤더의 실패가 공공 서비스를 발이 묶이게 하지 못하게 하고, 시민이 자신을 다스리는 규칙을 감사할 수 있도록 민감하지 않은 소스를 공개하십시오.

사례

스타트업. 세 명의 창업자 스타트업이 라이선스 비용을 감당할 수 없고 프로젝트가 멈추면 포크할 자유를 원해 제품 전체를 오픈 소스 기반(리눅스, 오픈 소스 데이터베이스, 웹 프레임워크) 위에 만듭니다. 출하 전 한 창업자가 구성 분석 스캔을 돌려 독점 매칭 알고리즘을 공개하도록 강제했을 강한 카피레프트 라이브러리를 잡아내고, 허용형 라이선스의 대체물로 바꿉니다. 유일한 차별화 요소인 그 알고리즘은 엄격히 닫아 두고, 호의를 쌓고 엔지니어를 끌어들이려 작은 내부 로깅 도구만 오픈 소스로 합니다.

기업. 한 대형 보험사가 핵심 플랫폼을 오픈 소스 기반 위에서 운영합니다. 리눅스, 널리 쓰이는 오픈 소스 데이터베이스, 컨테이너 오케스트레이터입니다. 그러나 독점 보험계리 모델링 제품군은 삽니다. 벤더의 도메인 전문성, 규제 인증, 지원 계약이 비용값을 하고 비교할 만한 오픈 대안이 없기 때문입니다. 배관에 대한 책임과 패치를 얻으려고 상용 오픈 소스(오픈 구성 요소의 벤더 지원 배포판) 구독료를 내면서, 차별화하는 가격 알고리즘은 엄격히 독점으로 사내에 둡니다. 이념이 아니라 TCO 분석(10.10장)이 각 선택을 이끕니다.

정부. 한 국세청이 “공적 자금, 공적 코드” 정책에 따라 다른 기관이 재사용하고 시민이 규칙을 감사할 수 있도록 오픈 소스 구성 요소와 개방형 표준(3.8장) 위에 새 급여 자격 서비스를 만듭니다. 민감하지 않은 코드를 공개 저장소에 게시하고, 보안상의 이유로 사기 탐지 휴리스틱만 닫아 둡니다. 이는 벤더 종속을 줄이고 디지털 주권(10.11장)을 진전시킵니다. 조달 규칙(10.3장)은 공급자가 실패할 때의 연속성을 보장하도록 모든 독점 구성 요소가 개방형 형식의 데이터 내보내기와 소스 코드 에스크로를 제공하도록 요구합니다.

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

오픈 소스의 재무적 매력인 라이선스 비용 없음은 사례에서 가장 믿을 수 없는 부분입니다. 취득은 TCO의 작은 부분이기 때문입니다. 지속되는 수익은 전략적입니다. 종속으로부터의 자유(재설계 없이 공급자를 바꾸거나 버릴 수 있는 능력), 보안과 컴플라이언스를 위한 감사 가능성, 엔지니어가 약정 전에 시험해 볼 수 있어 더 빠른 채택, 산업 전체에 걸친 범용 코드의 공유된 유지입니다. 상쇄하는 비용도 실제입니다. 통합, 운영, 보안 대응, 흔히 유료 지원을 직접 공급해야 하고, 잘못 고른 유지되지 않는 프로젝트는 어떤 라이선스보다 인시던트로 더 큰 비용이 들 수 있습니다.

독점 소프트웨어의 비즈니스 사례는 책임과 편의입니다. 제품에 책임지는 단일 벤더, 시행할 수 있는 지원 계약, 통합된 기능, 예측 가능한 예산입니다. 숨은 비용은 종속입니다. 벤더가 구제 수단 거의 없이 가격을 올리거나 서비스를 저하시킬 수 있게 하는 전환 비용에, 벤더의 지급 능력과 로드맵에 대한 의존이 더해집니다. 흔한 비즈니스 모델은 경계를 흐립니다. 오픈 코어(개방된 기반에 독점 유료 부가 기능), 이중 라이선스(같은 코드를 카피레프트와 유료 상용 라이선스로 모두 제공), 서비스형 소프트웨어(SaaS)(소프트웨어가 빌려 쓰는 호스팅 서비스로 돌아, 바이너리를 소유하지 않으므로 소스가 무관할 수 있음), 그리고 그 외에 무료인 코드 둘레의 서비스를 파는 지원/구독 모델입니다.

생산자에게 차별화되지 않는 자체 소프트웨어를 오픈 소스로 하는 ROI는 상당할 수 있습니다. 외부 기여자가 유지 부담을 줄입니다. 프로젝트가 채용과 평판의 자산이 됩니다. 외부 채택은 여러분의 표준을 사실상 표준으로 만듭니다. 정부에는 공공 부문 전반에 걸친 투명성과 재사용을 제공합니다. 전략적 규칙은 단순합니다. 비용을 나누고 생태계를 키우려면 범용품을 오픈 소스로 하고, 다른 모든 것에 자금을 대는 우위를 보호하려면 차별화 요소를 닫아 두십시오.

안티패턴과 함정

“무료는 무료다”: 취득 비용 영을 TCO 영으로 다루다가 운영과 지원에 자금을 적게 대는 것.
라이선스 맹목: 배포되는 독점 제품에 강한 카피레프트 코드를 내장해 계획하지 않은 의무를 촉발하는 것.
“많은 눈”에 대한 믿음: 지친 메인테이너 한 명과 보안 리뷰 없이 열린 프로젝트가 감사받는다고 가정하는 것.
모호성에 의한 보안: 공격자가 읽을 수 없다는 이유만으로 닫힌 소스가 안전하다고 믿는 것.
이념적 절대주의: 구성 요소마다 장점과 TCO로 고르는 대신 “전부 오픈”이나 “전부 독점”을 강제하는 것.
출처 무시: SBOM, 버전 고정, 공급망 검증 없이 의존성을 끌어오는 것(4.2장).
핵심 자산의 오픈 소스화: 여러분을 차별화하는 바로 그 코드를 공개해 우위를 내주는 것.
포크하고 잊기: 포크를 실제로 유지할 역량 없이 버려진 프로젝트를 포크하는 것.

성숙도 모델

1단계(시작). 오픈 소스와 독점 구성 요소가 임시로 자산에 들어옵니다. 라이선스는 읽히지 않고, 목록이나 SBOM이 없으며, 모델 사이의 선택은 습관이나 가격만으로 이루어집니다. 방치와 라이선스 위험은 무언가 깨질 때만 드러나고, 각 팀이 혼자 대응합니다.

2단계(발전). 일부 팀이 기본 실천을 시작합니다. 구성 요소와 라이선스 목록, 수용 가능한 라이선스에 대한 대략적인 관점, 가끔의 소프트웨어 구성 분석입니다. 구축 또는 구매와 오픈 또는 클로즈드 결정이 기록되지만 규율은 팀마다 조각조각이고 일관되지 않아, 습관이 자리 잡지 않은 곳에서는 카피레프트나 버스 팩터의 놀람이 여전히 빠져나갈 수 있습니다.

3단계(표준화). 문서화된 프레임워크가 조직 전체의 소비와 생산을 모두 다스립니다. 구성 요소는 TCO와 프로젝트 건강으로 선택되고, 라이선스는 파이프라인에서 자동으로 시행되어 위반이 빌드를 막으며, SBOM은 당연히 생성되고, 조직이 무엇을 오픈 소스로 하고 무엇을 닫아 둘지 명시적 정책이 정합니다. 개방형 형식과 소스 코드 에스크로 같은 퇴출 보호 장치가 조달의 표준이며, 모든 팀이 자기 규칙이 아니라 같은 규칙을 따릅니다.

4단계(관리). 프로그램이 기준선에 대해 측정되고 통제됩니다. 조직은 제품 전반의 SBOM 커버리지, 정책을 위반하는 의존성의 비중, 공개된 의존성 취약점 패치까지의 평균 시간, 핵심 프로젝트의 버스 팩터와 건강 점수, 각 선택을 정당화한 추정 대비 실현된 TCO 같은 지표를 추적합니다. 임계값이 행동을 촉발합니다. 유지가 멈추거나 패치 지연이 목표를 넘어 표류하는 구성 요소는 증거로 교체 대상으로 표시되고, 오픈 또는 클로즈드와 구축 또는 구매 결정은 습관으로 방어되는 대신 숫자에 대해 리뷰됩니다.

5단계(오케스트레이션). 오픈 소스 전략이 조직 전체에 통합되어 지속적으로 개선되는 의도적인 비즈니스 역량입니다. 조직은 의존하는 프로젝트에 기여하고 때로 스튜어드십을 지며, 차별화되지 않는 소프트웨어를 당연하게 오픈 소스로 하고, 의존성 건강과 TCO 데이터를 조달, 보안, 제품 계획에 되먹입니다. 비용, 위험, 주권, 전략적 우위의 변화가 위기를 강요하기 전에 적응하며 오픈 소스와 독점 소프트웨어의 포트폴리오를 일상적으로 재균형합니다.

논의를 위한 아이디어

자산에서 단일 벤더나 메인테이너를 잃으면 존재론적일 곳은 어디이며, 퇴출 계획은 무엇입니까?
자체 시스템 중 오픈 소스로 할 수 있는 범용품은 무엇이고, 보호해야 할 진짜 차별화 요소는 무엇입니까?
조직은 “많은 눈”을 진짜 보안 통제로 다룹니까, 검토되지 않은 가정으로 다룹니까?
공공 부문 독자에게: “공적 자금, 공적 코드”가 기본이 되면 다음 조달에서 무엇이 바뀌겠습니까?
TCO 비교는 오픈 소스가 여러분에게 옮기는 운영과 지원 비용을 얼마나 잘 포착합니까?

핵심 요점

오픈 대 클로즈드는 가격이 아니라 라이선스가 정의합니다. 자유로서의 무료와 가격으로서의 무료, 허용형과 카피레프트의 차이를 아십시오.
어느 모델도 본질적으로 더 안전하거나 더 싸지 않습니다. 개방성 라벨이 아니라 프로젝트의 실천과 전체 TCO를 판단하십시오.
개방성은 종속에 대한 가장 강력한 해독제로, 감사 가능성, 이식성, 포크할 능력을 줍니다. 독점 소프트웨어는 통제를 대가로 책임과 편의를 제공합니다.
구성 요소마다 장점으로 결정하고, 이념이 아니라 의도적으로 모델을 섞으십시오.
생산자로서는 범용품을 오픈 소스로 하고 차별화 요소는 닫아 두십시오. 정부에서는 투명성, 재사용, 주권을 위해 “공적 자금, 공적 코드”를 저울질하십시오.

참고 문헌과 더 읽을거리

Eric S. Raymond, The Cathedral and the Bazaar
Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Adrian Cockcroft and others, various O’Reilly titles on open-source strategy and operations
Free Software Foundation, The Free Software Definition (and the GNU General Public Licence texts)
Open Source Initiative, The Open Source Definition and approved-licence list
Free Software Foundation Europe, Public Money, Public Code campaign materials
Yochai Benkler, The Wealth of Networks