오픈소스 vs 독점, 누가 고치는가

소프트웨어를 고르는 자리에서 오픈소스와 독점은 늘 양자택일로 놓입니다. 한쪽은 코드가 공개되어 있으니 숨길 것이 없다고 하고, 다른 한쪽은 돈을 받는 회사가 있어야 문제가 생겼을 때 책임을 묻는다고 합니다. 두 문장 모두 그럴듯하고, 그래서 논쟁은 좀처럼 끝나지 않습니다.

그런데 실제로 팔리는 상용 소프트웨어를 뜯어 보면 이 구도가 성립하지 않습니다. 양자택일이 아니라 이미 섞여 있기 때문입니다. 독점 제품의 내부는 대부분 오픈소스 부품으로 채워져 있고, 문제는 어느 진영을 고르느냐가 아니라 그 부품을 지금 누가 손보고 있느냐입니다.

진영 논쟁은 상대가 나와 반대되는 것을 쓰고 있다고 가정하는 데서 시작됩니다. 두 렌즈의 정의는 핵심이론 페이지에 정리해 두었습니다.

독점 소프트웨어의 98퍼센트가 오픈소스로 만들어져 있습니다

보안 기업 블랙덕은 2024년 11월부터 2025년 10월까지 제출된 상용 코드베이스 947개를 감사했습니다. 17개 산업에 걸쳐 있고, 그 안에서 분석된 개별 프로젝트는 3,000개에 가깝습니다. 보고서가 내놓은 첫 숫자는 98퍼센트입니다. 감사 대상 코드베이스의 98퍼센트가 오픈소스 구성요소를 품고 있었습니다.

이 숫자 하나로 논쟁의 전제가 무너집니다. 오픈소스를 쓸 것인가 말 것인가는 이미 선택지가 아닙니다. 어떤 회사의 독점 제품을 구매하더라도 그 안에는 남이 만들어 공개해 둔 부품이 들어 있습니다. 회사가 파는 것은 부품이 아니라 조립과 보증이며, 부품 자체는 대개 공개된 저장소에서 내려받은 것입니다.

나머지 숫자들은 그 부품의 상태를 보여 줍니다. 코드베이스 하나에 들어 있는 취약점은 평균 581개였고, 이는 직전 보고서보다 107퍼센트 늘어난 값입니다. 감사 대상의 87퍼센트가 취약점을 하나 이상 갖고 있었고, 78퍼센트는 고위험 취약점을, 44퍼센트는 심각 위험 취약점을 포함하고 있었습니다. 라이선스 충돌이 발견된 코드베이스는 68퍼센트로, 한 해 전 56퍼센트에서 올라갔습니다.

서로를 보는 편견은 자기 약점의 투사입니다

오픈소스 쪽은 독점 소프트웨어를 안에서 무슨 일이 벌어지는지 알 수 없는 검은 상자로 봅니다. 독점 쪽은 오픈소스를 문제가 터져도 책임질 사람이 없는 무주공산으로 봅니다. 두 평가는 각자가 자기 모델에서 가장 두려워하는 실패 양식을 상대에게 그대로 비춘 것입니다.

이것이 미러 이미징입니다. 상대 진영의 위험이 내 진영의 위험과 같은 종류일 것이라는 가정은, 상대가 전혀 다른 방식으로 무너질 수 있다는 가능성을 지웁니다. 검은 상자를 두려워하는 사람은 공개된 코드를 아무도 읽지 않을 수 있다는 쪽을 잘 보지 못합니다. 책임 소재를 중시하는 사람은 계약서에 적힌 보증이 실제 수리로 이어지지 않는 경우를 잘 보지 못합니다.

위의 숫자들은 두 걱정이 모두 맞으면서 동시에 빗나갔다고 말합니다. 공개되어 있어도 취약점은 쌓였고, 돈을 주고 산 제품 안에도 같은 부품이 들어 있었습니다. 인증 방식이 바뀌는 과정에서 나타난 비슷한 구도를 패스워드와 패스키를 다룬 글에서도 정리해 두었습니다.

진짜 축은 공개냐 비공개냐가 아니라 유지되느냐입니다

같은 보고서에서 가장 무거운 숫자는 취약점 개수가 아닙니다. 감사 대상 코드베이스의 93퍼센트가 최근 2년 동안 개발 활동이 전혀 없는 구성요소를 품고 있었습니다. 92퍼센트는 4년 이상 낡은 구성요소를 갖고 있었습니다. 그리고 실제로 쓰이고 있는 구성요소 가운데 최신 버전인 것은 7퍼센트에 불과했습니다.

코드가 공개되어 있다는 사실은 누군가 그 코드를 고치고 있다는 뜻이 아닙니다. 읽을 수 있다는 것과 읽고 있다는 것은 다른 말이며, 고칠 수 있다는 것과 고칠 사람이 있다는 것도 다른 말입니다. 공개는 가능성을 열어 둘 뿐이고, 그 가능성을 실행으로 바꾸는 것은 사람과 시간입니다. 독점 제품에서도 사정은 같습니다. 회사가 부품 목록을 관리하지 않으면 4년 묵은 부품이 그대로 출하됩니다.

XZ 사태가 보여 준 것

2024년 3월, 리눅스 배포판 대부분에 들어가는 압축 라이브러리 XZ Utils에서 백도어가 발견되었습니다. 미국 사이버보안·인프라보안국은 XZ Utils 5.6.0과 5.6.1 버전이 오염되었다고 경고하고 5.4.6 안정 버전으로 되돌릴 것을 권고했습니다. 이 사건에 매겨진 CVE-2024-3094의 CVSS 3.1 기본 점수는 10.0으로 최고 등급인 심각이었습니다.

주목할 것은 침입 방식입니다. 같은 기관은 이 사건을 두고 악의적 행위자가 패키지 유지보수자의 신뢰를 얻어 백도어를 심기까지 여러 해에 걸친 작업을 벌였다고 설명했습니다. 코드를 몰래 깨뜨린 것이 아니라 코드를 관리할 권한을 정당하게 넘겨받은 것입니다. 같은 기관이 이 사건의 교훈을 정리하면서 유지보수자 소진이 만들어 내는 현실적이고 지속적인 위험을 지목한 이유가 여기에 있습니다.

많은 눈이 지켜보므로 안전하다는 명제는 눈이 실제로 있을 때만 참입니다. 전 세계가 의존하는 부품을 소수가 여가 시간에 돌보고 있다면, 공개라는 조건은 감시가 아니라 접근 경로가 됩니다. 독점 진영이 이 사건을 근거로 삼기 어려운 이유도 같습니다. 문제의 부품은 무료 배포판에만 들어 있던 것이 아니라, 그 위에 세워진 상용 제품에도 그대로 들어가 있었습니다.

결론

오픈소스와 독점은 맞서는 두 진영이 아닙니다. 하나는 부품을 만들어 공개하고, 다른 하나는 그 부품을 조립해 보증을 붙여 팝니다. 이 관계에서 어느 쪽을 고를 것인지 묻는 질문은 답을 내놓지 못합니다. 어느 쪽을 골라도 같은 부품 위에 서게 되기 때문입니다.

바꿔야 할 질문은 이것입니다. 내가 지금 쓰는 제품의 부품 목록을 받아 볼 수 있습니까. 그 목록에서 최근 2년간 손이 닿지 않은 부품이 몇 개입니까. 그리고 그중 하나가 내일 오염되었다는 발표가 나오면 누가 몇 시간 안에 고쳐 줍니까. 세 번째 질문에 답할 수 있는 공급자가 좋은 공급자이며, 그 답은 진영이 아니라 계약과 운영에서 나옵니다.