[특집] 고칠 사람이 없었다 — PHP2Shell로 본 오픈소스 보안 인력의 구조: 감사, 대기열, 합의제, 그리고 돈

이 글이 다루는 것

PHP2Shell의 사흘을 정리하면서 가장 마음에 남은 문장은 기술 설명이 아니었습니다. PHP 재단이 공개 당일 쓴 이 문장이었습니다.

우리는 달리 말하지 않겠습니다. 지연은 보안팀의 결정 방식과 자원 부족이 함께 만든 구조적 실패였습니다.

PHP는 웹사이트의 상당수가 쓰는 언어인데, 그 엔진의 보안은 누가 어떤 구조로 맡고 있었을까요? 이 글은 결함이 어떻게 작동하는지는 다루지 않습니다(이전 글들과 마찬가지입니다). 대신 보고서가 어디로 들어와 누구의 책상에 놓이고, 수정이 왜 멈추며, 그 자리에 돈과 사람이 어떻게 들어오는가를 봅니다.

크게 보기

1부 · 2024년의 감사: 어디까지 비춰 볼 수 있었나

PHP는 2024년에 첫 외부 보안 감사를 받았습니다. 독일 소버린 테크 에이전시(Sovereign Tech Agency)가 돈을 대고, 오픈소스 기술 개선 기금 OSTIF가 조직하고, 프랑스 보안 업체 Quarkslab이 두 달간 수행했습니다. 결과는 2025년 4월에 발표됐습니다.

그런데 발표문에는 눈에 띄는 경고 상자가 하나 있습니다. 예산 제약 때문에 감사는 코드 전체가 아니라 가장 중요한 구성 요소에 집중했다는 내용입니다. 감사 범위 문서에도 우선순위 목록(PHP-FPM, MySQL 네이티브 드라이버, 멀티파트 폼 파서, JSON 파싱, OpenSSL 확장, 비밀번호·해시 기능 등)이 적혀 있습니다.

크게 보기

감사는 시간과 돈이 정한 범위 안에서만 봅니다. 그래서 감사가 있었다는 사실과 감사가 모든 곳을 봤다는 사실은 다릅니다. 이번 사건과 관련해 재단은 이렇게 적었습니다.

• 감사에서 보고된 문제 하나를 고치던 재단 소속 핵심 개발자가 훗날 CVE-2026-109618이 되는 문제의 첫 징후를 발견했다.
• 2024년에 이미 가능한 공격이 이론적으로 거론됐지만, 구체적 경로가 확인되지 않았고 영향이 분명한 다른 문제들이 더 급해 보여 가려졌다.

두 문장이 보여 주는 건 누군가의 태만이 아니라 한정된 시간에서의 우선순위 계산입니다. 이 지점의 더 자세한 연대기는 첫 글의 1부에 있습니다.

2부 · 수정안이 세 개일 때: 합의제가 멈춘다

더 흥미로운 대목은 그다음입니다. 재단은 문제를 고치기 위해 보안팀이 서로 경쟁하는 여러 접근을 개발했다고 밝혔습니다. 모두 대가가 따랐습니다.

• 기존 코드와의 하위 호환이 깨질 수 있었다.
• 새로운 서비스 거부 가능성이 생길 수 있었다.
• 수많은 서드파티 확장을 함께 고쳐야 했는데, 조율이 사실상 불가능해 보였다.

여기에 합의로 움직이는 보안팀, 잘못된 선택의 결과를 두려워하는 분위기, 엔진을 깊이 아는 핵심 개발자가 적고 이미 다른 일로 바쁘다는 사정, 그리고 실제 원격 실행 경로가 알려져 있지 않다는 사실이 겹쳤습니다. 결과는 수정 작업이 몇 달 동안 멈췄다가 다시 시작하기를 반복한 것입니다.

크게 보기

합의제는 나쁜 제도가 아닙니다. 오픈소스 거버넌스에서 합의는 소수 의견을 보호하고 큰 실수를 막아 왔습니다. 문제는 모든 선택지가 불완전한데 시간은 흐르는 상황에서 합의가 사실상 거부권의 합이 된다는 점입니다. 재단은 이번 일 이후 이렇게 바꾸고 있다고 적었습니다.

• 결정을 다수결로 내릴 수 있게 하고 타협을 장려한다.
• 복잡한 수정에서 막힌 취약점이 재단 지도부에 더 일찍 올라가 방향을 잡도록 한다.
• 같은 종류의 문제가 다음에 와도 더 빨리 풀리도록 반복 가능한 절차로 만든다.

3부 · 하트블리드의 연봉 2만 달러: 12년 전에도 같은 장면이었다

이 이야기가 낯설지 않은 건 2014년 하트블리드 때 똑같은 장면이 있었기 때문입니다.

위키백과가 당시 보도를 인용해 정리한 바로는, 하트블리드가 공개될 때 OpenSSL 프로젝트의 연 기부금은 약 2,000달러, 즉 전기요금 수준이었고 전업으로 일하는 개발자는 한 명(스티븐 헨슨, 연 2만 달러 안팎)이었습니다. 이 소프트웨어는 당시 인터넷 보안 웹 서버의 약 17%(50만 대 안팎)에 쓰이고 있었습니다. 사고가 터진 뒤 리눅스 재단이 며칠 만에 13개 기업을 모아 핵심 인프라 이니셔티브(CII)를 만들었고, OpenSSL의 전업 개발자 두 명을 후원하기로 했습니다.

크게 보기

연표를 위에서 아래로 읽으면 순서가 보입니다. 사고 → 돈 → 사람 → 감사 → 다음 사고입니다. PHP도 2024년 감사가 있었고, 2026년 5월에야 생태계 보안팀이 생겼으며, 그 직후에 이번 사건이 터졌습니다. 순서를 바꾸는 일, 즉 사고 전에 돈이 움직이게 하는 일은 12년이 지나도 쉽지 않다는 이야기입니다.

4부 · 2026년의 변화: 보안팀이 '직업'이 되는 중

PHP 재단의 2026년 움직임을 순서대로 보면 이렇습니다.

1. 3월: 리눅스 재단이 보안 지원금(1,250만 달러 규모)을 발표. Alpha-Omega와 OpenSSF가 운영한다.
2. 5월 18일: PHP 재단이 Alpha-Omega 지원금으로 생태계 보안팀(Ecosystem Security Team) 을 신설. 6개월 전업 "AI 보안 엔지니어 레지던트"로 볼커 두슈를 채용.
3. 7월: 알렉상드르 도부아가 합류해 PHP 보안팀의 접수·분류·수정을 돕는다.
4. 9월: 다니엘 셰르저가 합류해 하드닝(방어 강화)을 맡는다.
5. 8월 11일 이후: Calif·OpenAI·Wiz의 보고로 영향이 분명해지자 수정이 재단 보안 작업 전체의 최우선 과제가 되었고, 재단은 후원금이 없었다면 여러 사람이 전업으로, 주말과 밤샘까지 매달리는 일은 불가능했다고 적었습니다.

눈여겨볼 점이 둘 있습니다. 하나는 이 인력이 6개월 계약으로 시작했다는 것, 재단 글도 "초기 단계가 끝난 뒤의 지속 가능성 계획"을 따로 준비한다고 적었습니다. 다른 하나는 보안팀이 재단과 별개로 운영되는 조직이라는 점입니다. PHP 보안팀은 자원봉사 커뮤니티 구성원과 재단 후원 개발자가 섞여 있고, 재단이 일부를 뒷받침하지만 의사결정은 팀이 합니다.

크게 보기

재단이 후원을 요청하는 대상도 구체적입니다. PHP에 의존하는 기업, 공공 서비스가 PHP 위에서 도는 정부와 공공기관(2024년 감사를 소버린 테크 에이전시가 댄 사례를 들며), 그리고 개인 개발자입니다. 한 번의 특별 기부보다 지속적이고 예측 가능한 후원이 필요하다고 되풀이합니다.

5부 · 보고서의 홍수: AI가 대기열을 바꾼 방식

지금 보안 담당자의 가장 큰 변화는 들어오는 보고서의 양과 질입니다. 재단은 10월 14일 글에서 "AI 도구가 지난 1년 사이 보안 보고서를 훨씬 싸게 쓰게 만들었다"고 적었습니다. 수치도 있습니다.

• 7월 1일 이후 PHP 보안팀이 공개한 CVE는 15건.
• 같은 기간 106건의 보고를 종결했다. 취약점이 아니거나, 이미 접수된 것과 중복이거나, 재현되지 않는 보고였다. 일부는 실제 환경에서는 쓰지 않는 방식으로 PHP를 돌리는 퍼저(fuzzer)가 만든 것이다.
• 여전히 밀린 보고서가 있고, 조용한 권고는 잊힌 권고가 아니라고 재단이 적었다.

가장 선명한 사례는 curl입니다. 메인테이너 다니엘 스텐베리는 2025년 7월 글에서 AI가 만든 엉터리 보고서가 제출의 약 20%까지 늘었고 진짜 취약점은 약 5%였다고 적었습니다. 그리고 2026년 1월에는 이렇게 결정했습니다.

• 2026년 1월 31일부로 버그 바운티 종료. 2019년 이후 취약점 87건, 보상 10만 달러 이상을 남겼다.
• 금전 보상 중단. 지어낸 보고를 쓸 동기를 없애려는 시도다.
• 보고 창구를 HackerOne에서 GitHub 비공개 취약점 신고로 이동.
• 예전에는 15% 넘던 유효 보고 비율이 2025년 들어 5% 아래로 떨어졌다.

크게 보기

수치를 곱해 보면 이 문제가 왜 심각한지 직관이 생깁니다. curl 팀은 7명이고, 보고서 한 건에 3~4명이 30분에서 서너 시간씩 붙습니다. 그중 상당수는 전업이 아니라 주당 몇 시간만 낼 수 있는 사람들입니다. 위 계산기에서 보고서가 주당 몇 건일 때 팀이 빠듯해지는지 확인해 보세요. 가짜 보고서가 주는 부담은 진짜 보고서를 읽을 시간을 빼앗는 것입니다.

이 문제에 대한 PHP의 답은 "AI를 막는다"가 아니었습니다. 반대로 재단은 AI로 쓴 보고서도 환영한다고 하되, 조건을 걸었습니다. PHP 빌드에서 재현하고, 분류 정책과 대조하고, 내용을 이해한 채로 보내라는 것입니다. 보안팀 쪽도 OpenAI의 Daybreak 최상위 등급을 받아 보고서 검증과 중복 묶기에 쓰고, 올해 초에는 Anthropic의 Claude Mythos에도 접근했다고 밝혔습니다. 다만 모든 판정은 사람이 내리고 모든 패치는 사람이 쓰거나 검토한다고 못 박았습니다.

6부 · 죽은 척하는 패키지들: 문을 두드리면 누가 대답하나

PHP 엔진 바깥, 의존성의 세계는 어떨까요? Alpha-Omega의 한 분석 글은 이렇게 물었습니다. "마지막 커밋이 오래됐다"가 아니라 "문을 두드리면 누가 대답하는가" 를 보자는 것입니다.

글쓴이는 ecosyste.ms의 핵심 패키지 집합에서 16개 패키지 관리자에 걸친 5,874개 저장소를 골라 1년 치 활동을 분류했습니다. 결과는 이렇습니다.

• 활동 48.8%, 휴면 20.2%, 무응답 12.1%, 미상 18.9%.
• 무응답 713개 저장소 가운데 공식 보관(archived) 처리된 곳은 322개이고, 391개는 보관 표시 없이 이슈 창만 열려 있다. 글쓴이는 이를 영화 「위켄드 앳 버니스」에 빗댔다. 죽은 사람에게 선글라스를 씌워 놓고 아무도 모른 척하는 상황이다.
• 그 저장소들에 사람이 올린 이슈가 321곳, 한 번도 병합되지 않은 PR이 243곳에 있다. 그중에는 수정안이 붙은 PR도 있다. 버튼을 누를 사람이 없는 것이다.
• 사망·휴면 패키지 1,414개는 레지스트리 배포 권한을 가진 계정이 하나뿐이다.

크게 보기

PHP 패키지 저장소 Packagist는 547개 저장소 중 66개(12.1%)가 무응답이었습니다. 다만 이 분석은 활동과 응답 여부를 본 것이지 취약점을 센 것이 아닙니다. 글쓴이도 "코드가 40줄이고 끝난 패키지는 커밋이 없어도 건강할 수 있다"고 적었습니다. 그리고 하나 더 덧붙였습니다. 아무도 들여다보지 않은 것은 안전한 것이 아니라 검사되지 않은 것이고, 예전에는 "아무도 안 본다"가 방어였지만 AI 도구가 코드를 훑는 비용을 거의 0으로 만들면서 그 방어가 무너지고 있다는 것입니다.

7부 · 그래서 의존하는 쪽은 무엇을 하나

이 구조에서 나올 수 있는 결론은 "유지보수자를 탓하자"가 아닙니다. 재단은 자신들의 지연을 공개적으로 인정했고, 그 자체가 드문 일입니다. 질문은 의존하는 쪽의 몫이 무엇인가입니다.

회사라면 의존하는 상류 프로젝트의 보안 예산을 내부 예산에 넣는지 물어볼 만합니다. 개발자라면 의존성 목록에서 응답하는 사람이 있는지를 한 번 확인해 볼 만합니다. 운영자라면 버전 번호의 함정을 보고 업그레이드 경로를 확보해 두는 것이 가장 현실적인 첫걸음입니다.

8부 · 맺으며: 안전은 코드가 아니라 사람의 시간

PHP2Shell은 기술적 사건이면서 동시에 시간표의 사건이었습니다. 2024년에 단서가 있었고, 2026년 8월에 영향이 분명해졌고, 10월에 공개됐습니다. 그 사이의 간격을 채운 것은 코드가 아니라 누가 얼마나 시간을 쓸 수 있었는가였습니다.

세 가지만 기억하면 좋겠습니다.

1. 감사는 범위가 정해진 렌즈입니다. 감사가 있었다는 말은 모든 것이 비춰졌다는 말이 아닙니다.
2. 합의제는 기본값이 아니라 선택입니다. 대가가 다른 수정안이 경쟁할 때 결정 방식이 일정을 정합니다.
3. 돈은 사고 뒤에 모입니다. 하트블리드(2014)에서도, PHP2Shell(2026)에서도 그랬습니다. 이 순서를 바꾸려면 의존하는 쪽의 예측 가능한 후원이 필요합니다.

이 글은 의도적으로 결함의 내부를 다루지 않았습니다. 공개 직후의 해설은 방어자 쪽 속도를 앞서는 것이 맞는지 판단하기 어렵기 때문입니다. 패치가 충분히 퍼지고 나면 갱신편(패치 2주 뒤의 현황)에서 확인된 사실을 다시 정리하겠습니다.

이전 글: PHP2Shell 사흘의 기록 · 버전 번호는 거짓말을 한다 · 엠바고는 누구의 것인가

참고 자료

• The PHP Foundation, "Today's PHP Security Release, and How We're Strengthening PHP Security" (2026-10-21) — "A first external audit…", "structural failure", 후원 요청 절
• The PHP Foundation, "How the PHP Security Team Handles Your Reports" (2026-10-14)
• The PHP Foundation, "Announcing the Ecosystem Security Team at The PHP Foundation" (2026-05-18)
• The PHP Foundation, "PHP Core Security Audit Results" (2025-04-10); Quarkslab, "Security audit of PHP-SRC"(범위·작업 목록)
• Daniel Stenberg, "Death by a thousand slops" (2025-07-14); "The end of the curl bug-bounty" (2026-01-26)
• Alpha-Omega, "Weekend at Bernie's: which of your dependencies are wearing sunglasses?" (2026)
• Wikipedia, "Core Infrastructure Initiative", "Heartbleed"
• 이 시리즈의 이전 글: PHP2Shell 사흘의 기록, 엠바고는 누구의 것인가