Open Source Software Reliability and Community-Driven Development
2026-07-12 2026-07-12 2026-07-12
목차 (0개 섹션)목차 (0개 섹션)목차 (0개 섹션)
2021년 10월, log4j라는 이름도 낯선 자바 로깅 라이브러리 하나가 전 세계 서버를 마비 직전까지 몰아넣었다. 원격 코드 실행이 가능한 이 취약점(CVE-2021-44228, 일명 Log4Shell)을 손보고 있던 사람은 회사에 소속된 전담 보안팀이 아니라, 본업이 따로 있으면서 밤에 짬을 내 이 프로젝트를 관리하던 자원봉사자 몇 명이었다. 아파치 소프트웨어 재단 산하 프로젝트였음에도 실질 유지보수 인력은 손에 꼽을 정도였고, 이 사실이 알려지자 "전 세계 인프라가 무급 개인 몇 명의 선의에 의존하고 있다"는 논쟁이 다시 불붙었다. 이른바 '엑스카드' 문제, 즉 필수 인프라를 지탱하는 프로젝트가 정작 지속 가능한 재정·인력 기반을 갖추지 못한 구조적 취약성이 표면화된 사건이었다.
오픈소스의 신뢰성 문제는 단순히 "버그가 있냐 없냐"의 차원이 아니다. 2024년 3월 발견된 XZ Utils 백도어 사건이 이를 더 극적으로 보여준다. 리눅스 배포판 대부분에 포함되는 압축 라이브러리 XZ Utils에, 'Jia Tan'이라는 이름으로 2년 넘게 신뢰를 쌓아온 기여자가 SSH 인증을 우회하는 백도어 코드를 은밀히 심었다. 이 인물은 실제 유지보수자였던 라세 콜린이 번아웃과 정신건강 문제로 프로젝트 관리에서 손을 뗀 틈을 파고들어 공동 관리자 권한을 획득했다. 발견된 계기도 극적이었다 — 마이크로소프트의 한 엔지니어가 ssh 로그인이 0.5초가량 느려진 것을 우연히 눈치채고 프로파일링을 하다가 찾아낸 것이다. 만약 그가 그 미세한 지연을 무시했다면, 전 세계 서버 인프라에 국가 배후로 추정되는 공급망 공격이 그대로 관철될 뻔했다.
이런 사건들이 반복되면서 커뮤니티 거버넌스 모델 자체에 대한 재평가가 이루어지고 있다. 대표적으로 두 갈래로 나뉜다. 리누스 토르발스가 이끄는 리눅스 커널처럼 '자애로운 종신 독재자(BDFL, Benevolent Dictator For Life)' 모델은 의사결정이 빠르고 방향성이 일관되지만, 특정 개인에게 권한과 신뢰가 집중되는 만큼 그 개인의 판단·건강·동기가 곧 프로젝트의 위험 요인이 된다. 반대로 아파치 재단이나 파이썬 소프트웨어 재단처럼 위원회·투표 기반의 재단형 거버넌스는 의사결정 과정이 투명하고 특정인 리스크는 줄지만, 절차가 느리고 때로는 정치적 다툼으로 프로젝트 동력을 잃기도 한다. 파이썬의 경우 2018년 귀도 반 로섬이 BDFL 자리에서 스스로 물러나면서 '스티어링 카운슬' 5인 합의체 방식으로 전환한 사례가 있는데, 이는 창시자 한 사람에게 쏠린 권한을 제도적으로 분산시킨 상징적 사건으로 꼽힌다.
신뢰성을 담보하기 위한 실무적 장치들도 점차 표준화되고 있다. 깃허브의 'CODEOWNERS' 파일로 코드 영역별 승인권자를 명시하거나, 커밋에 서명키를 요구하는 방식, 그리고 2023년 이후 확산된 SLSA(Supply-chain Levels for Software Artifacts) 프레임워크처럼 빌드 과정 자체를 검증 가능하게 만드는 시도들이 대표적이다. 미국 정부도 2021년 행정명령 14028호를 통해 연방기관에 납품되는 소프트웨어에 SBOM(소프트웨어 구성요소 명세서) 제출을 의무화하며 오픈소스 공급망 문제에 개입하기 시작했다.
다만 이런 제도적 보완이 근본 문제, 즉 '무급 유지보수자의 번아웃'을 해결하지는 못한다는 지적도 많다. Tidelift가 2021년 실시한 설문에서 오픈소스 유지보수자의 약 60%가 최소 한 번은 프로젝트를 그만두고 싶다고 답했고, 그 이유의 대부분은 금전적 보상 부재와 커뮤니티 요구에 대한 소진이었다. 결국 오픈소스의 신뢰성은 코드 품질의 문제라기보다, 그 코드를 계속 돌봐줄 사람을 어떻게 지속 가능하게 지원하느냐는 사회적·경제적 구조의 문제에 가깝다는 시각이 최근 논의의 중심에 있다.
혹시 컴퓨터 프로그램이 "공짜로 아무나 만든 것"이라고 생각한 적 있어? 사실 우리가 매일 쓰는 인터넷 서비스, 스마트폰 앱, 심지어 은행 시스템까지도 그 속을 들여다보면 자원봉사자가 취미 삼아 만들고 관리하는 코드 조각(오픈소스)이 여기저기 들어가 있다. 그런데 2021년 말, 이 사실이 얼마나 위험할 수 있는지 보여준 사건이 터졌다. 'log4j'라는 이름의 자바 프로그램용 부품 하나에서 심각한 보안 구멍이 발견됐는데, 이걸 전 세계 수많은 기업이 가져다 쓰고 있었다. 문제는 이걸 고쳐야 할 사람이 대기업 보안팀이 아니라, 본업 끝나고 밤에 시간 내서 관리하던 개인 몇 명뿐이었다는 점이다.
더 놀라운 사건은 2024년에 있었다. 리눅스라는 운영체제에서 널리 쓰이는 압축 프로그램 'XZ Utils'에, 무려 2년 동안 착실하게 신뢰를 쌓아온 개발자 한 명이 몰래 '뒷문(백도어)'을 심어놓은 게 발견됐다. 이 사람은 진짜 관리자가 지쳐서 손을 놓은 틈을 타 권한을 얻어낸 것이었다. 다행히 마이크로소프트 직원 한 명이 컴퓨터 로그인이 "평소보다 0.5초 느려졌다"는 아주 작은 이상함을 알아채고 파헤친 덕분에 큰 사고로 번지기 전에 막을 수 있었다. 이 이야기가 무서운 이유는, 만약 그 사람이 그 미세한 차이를 그냥 넘겼다면 전 세계 컴퓨터가 위험해질 뻔했기 때문이다.
이런 일들 때문에 요즘 오픈소스 세계에서는 "누가 어떻게 관리할 것인가"라는 질문, 즉 거버넌스(운영 방식)가 중요한 화두가 됐다. 어떤 프로젝트는 한 명의 리더가 모든 결정을 내리는 방식을 쓰고(대표적으로 리눅스 운영체제를 만든 리누스 토르발스), 어떤 프로젝트는 여러 사람이 위원회를 만들어 투표로 결정한다. 파이썬이라는 유명한 프로그래밍 언어는 2018년에 창시자였던 귀도 반 로섬이 스스로 "이제 나 혼자 결정하지 않겠다"며 물러나고, 5명이 함께 결정하는 방식으로 바꾸기도 했다.
또 하나 알아둘 사실은, 이런 프로젝트를 관리하는 사람들 대부분이 돈을 받지 않는다는 점이다. 한 설문조사에서는 오픈소스 관리자 10명 중 6명이 "그만두고 싶었던 적이 있다"고 답했는데, 이유는 대부분 지쳐서였다. 결국 우리가 안전하게 인터넷을 쓸 수 있는 배경에는, 누구인지도 잘 모르는 사람들이 밤을 새워가며 코드를 돌보고 있다는 사실이 숨어 있는 셈이다.
너희 집 냉장고 안에 있는 반찬 중에, 동네 아주머니가 그냥 나눠준 김치가 있다고 생각해보자. 맛있고 공짜라서 다들 좋아하는데, 만약 그 아주머니가 갑자기 아파서 더 이상 김치를 담글 수 없게 되면 어떻게 될까? 그런데 알고 보니 동네 사람 절반이 그 김치만 먹고 있었다면?
컴퓨터 세상에도 이런 '공짜 김치' 같은 게 있다. 바로 '오픈소스'라는 건데, 누군가 열심히 만들어서 "누구나 써도 돼요!"라고 공짜로 나눠주는 컴퓨터 프로그램 부품이다. 그런데 신기하게도 우리가 쓰는 스마트폰, 인터넷, 심지어 은행 컴퓨터 안에도 이런 공짜 부품이 아주 많이 들어가 있다.
2021년에 이런 일이 있었다. '로그포제이'라는 이름의 작은 프로그램 부품에 구멍이 났는데, 전 세계 수많은 회사가 이 부품을 쓰고 있었다. 그런데 이걸 고칠 수 있는 사람은 회사 직원이 아니라, 밤에 취미로 그 프로그램을 돌봐주던 몇 명뿐이었다. 마치 학교 급식 전체를 만드는 주방장이 딱 두 명뿐인데 갑자기 한 명이 아팠던 것과 비슷하다.
2024년에는 더 신기한 일도 있었다. 어떤 사람이 2년 동안이나 착하게 도와주는 척하면서 몰래 프로그램에 '나쁜 뒷문'을 숨겨놓았다. 다행히 다른 회사 직원 한 명이 "어? 컴퓨터가 평소보다 아주 조금, 눈 깜짝할 시간의 반만큼 느려졌네?"라고 눈치채고 확인한 덕분에 큰일을 막을 수 있었다. 아주 작은 이상함도 그냥 넘기지 않은 게 세상을 구한 셈이다.
그래서 요즘 이런 공짜 프로그램을 만드는 사람들은 "우리 이제 한 사람한테만 맡기지 말고, 여러 명이 같이 잘 살펴보자"고 규칙을 새로 만들고 있다. 마치 급식실 주방장을 한 명이 아니라 여러 명이 함께 맡아서, 한 명이 쉬어도 다른 사람이 대신 봐줄 수 있게 하는 것과 같다. 우리가 매일 편하게 쓰는 컴퓨터 뒤에는, 이렇게 아무 대가 없이 밤새 프로그램을 돌봐주는 고마운 사람들이 숨어 있다는 걸 기억해두면 좋겠다.
문서 정보
최초 작성
최종 갱신
분류
기술
HANGUL.WIKI가 정리·작성한 문서입니다. 정확성을 위해 노력하나 오류가 있을 수 있으므로, 중요한 내용은 공식 출처를 통해 확인하시기 바랍니다.
내용의 오류나 정정 요청은 오류·정정 신고로 알려주시면 검토 후 반영합니다.