PHP2Shell: AI가 소프트웨어로 하여금 40년의 기술 부채를 갚게 만드는 방법

PHP2Shell 취약점은 2년 된 PHP 크래시 버그를 원격 코드 실행 결함으로 바꾸어 WordPress, Drupal, NASA, Wikipedia 및 백악관 웹사이트를 위험에 빠뜨렸습니다. AI 도구가 코드를 분석하기 시작한 지 약 2주 만에 발견되었습니다. 2026년 11월 IEEE Spectrum이 보도한 이 사건은 더 큰 논쟁의 기준 사례가 되었습니다. AI는 수십 년 된 레거시 소프트웨어에서 악용 가능한 버그를 찾는 비용을 붕괴시켜, 업계가 40년 동안 미뤄온 기술 부채를 직면하도록 강요하고 있습니다.

PHP2Shell이 실제로 무엇이었나

PHP2Shell은 1994년에 만들어진 서버 측 언어인 PHP의 심각한 취약점이었습니다. PHP는 여전히 웹의 상당 부분을 뒷받침합니다. 이 결함으로 공격자는 호스트 서버에서 민감한 데이터를 읽고 악성 코드를 실행할 수 있었으며, 이를 통해 악성 소프트웨어를 설치하거나 중요한 데이터를 유출할 수 있었습니다.

그 밑에 있는 버그는 새로운 것이 아니었습니다. 2024년에 이미 PHP 재단에 보고되었으며 메모리 부족 오류로 나타났습니다. 이는 일반적으로 프로그램을 충돌시키는 버그 종류입니다. 충돌은 흔하고 대개 위험하지 않기 때문에 보고서는 처리되지 않은 채 남아 있었습니다.

"어느 시점을 보더라도 수정을 기다리는 버그 보고서가 많이 있을 것입니다. 그냥 충돌일 뿐인 것들 말이죠. 대부분의 사람들은 그것들을 심각하게 여기지 않습니다." — Suman Jana, Columbia University 컴퓨터 과학 부교수

전환점은 사이버 보안 회사인 Calif가 OpenAI의 후원으로 PHP를 독립적으로 감사하겠다고 제안하면서 찾아왔습니다. 2주 안에 AI 도구의 도움을 받은 Calif 연구원은 메모리 부족 버그를 임의 코드 실행으로 변환하는 방법을 찾았습니다. Wiz는 이 발견을 확인하고 확장했습니다. 그 후 PHP 재단의 엔지니어 4명이 패치를 개발하는 데 두 달을 보냈습니다.

공개적으로 알려진 바에 따르면, 이 취약점은 악의적인 행위자가 입수하기 전에 연구자들에 의해 보고되었고 패치가 먼저 배포되었습니다. 같은 시기에 공개된 다른 주요 보안 문제로는 Node.js에 영향을 미치는 Brotli 원격 코드 실행 결함, Ruby의 정규 표현식 엔진의 세 가지 버그, 그리고 키가 밀리초 만에 해독된 인증 기관이 있었습니다.

AI가 악용 경제학을 바꾸는 이유

AI가 보안 균형을 바꾸기 위해 자율 해커가 될 필요는 없습니다. 고통스럽고 매우 구체적인 추론을 충분히 저렴하게 만들어 더 많은 사람들이 할 수 있게 하면 됩니다.

메모리 버그를 악용하려면 특정 프로그램의 메모리에서 특정 지점으로 점프하는 방법을 알아내고 어떤 비트를 어떤 순서로 덮어써야 하는지 정확히 결정해야 합니다. Suman Jana는 이것을 훌륭한 작업이라기보다 지루한 작업이라고 설명합니다.

"그것은 정말 로켓 과학이 아닙니다. 단지 하기 힘든 매우 구체적인 추론이 많을 뿐입니다. 그리고 AI가 그 일을 아주 잘 해냈다고 생각합니다." — Suman Jana, Columbia University

Jana는 인간이 여전히 필수적이라고 분명히 말합니다. Calif, OpenAI, Wiz 연구자들은 사이버 보안과 PHP 모두에 깊은 전문 지식을 가지고 있었습니다. 그의 주장은 더 좁고 더 결과적으로 중요합니다. AI가 최상위 0.1% 전문가의 산출량을 높이고 그 바로 아래 계층의 사람들이 모든 세부 사항을 숙달하지 않고도 작업할 수 있게 한다는 것입니다.

Hacker News 댓글 작성자들은 이 점을 공격 경제학으로 확장했습니다. 한 사람은 정교한 공격에 값비싼 전문가가 필요했던 세상에서 비용이 수 센트에서 수 달러에 불과한 세상으로의 변화를 설명했습니다.

"대부분의 회사에서 모호성에 의한 보안은 항상 중요했습니다. 정교한 공격을 수행하는 데 비용이 많이 드는 IT 전문가를 고용해야 했기 때문에 상대적으로 안심할 수 있었습니다... 이제 그러한 공격을 수행하는 데는 기껏해야 몇 센트에서 몇 달러가 들 뿐입니다. 이것은 게임을 완전히 바꾸며 모든 사람이 표적이 됩니다." — @ThePhysicist

또 다른 사람은 같은 변화를 일반적인 암묵적 전략의 죽음으로 설명했습니다.

"'공격하기 너무 고통스럽다'는 보안 전략으로서의 사고방식은 AI 시대에 더 이상 통하지 않습니다." — @ctrlaltdileep

버그 찾기와 수정 사이의 비대칭성

PHP2Shell이 승리가 아니라 경고인 핵심 이유는 버그를 찾는 것과 수정하는 것이 대칭적인 작업이 아니기 때문입니다. 발견은 병렬화가 가능하고 저렴합니다. 반면 수정은 공격의 모든 경로가 차단되었고 기존 기능을 깨뜨리지 않는다는 것을 증명해야 합니다.

"버그를 찾는 것과 수정하는 것 사이에는 근본적인 비대칭성이 있습니다. 버그를 수정할 때는 공격의 모든 부분이 차단되었는지 확인해야 하고 기존 기능을 깨뜨리지 않아야 하기 때문입니다." — Suman Jana

이 비대칭성은 명확한 수익원 없이 널리 의존되는 PHP와 같은 오픈 소스 프로젝트에 가장 큰 타격을 줍니다. AI 지원 발견은 유지 보수 부담을 더욱 시급하게 만들지만 자동으로 자금을 지원하지는 않습니다.

Jana가 제안한 완화책은 최첨단 AI 연구소가 중요한 오픈 소스 코드의 보안 감사에 토큰 예산을 기부하는 것입니다. 그는 이것이 조정된 노력이나 기부를 통해 더 자주 일어나야 한다고 주장합니다. 그는 또한 패치 측을 자동화하는 방법으로 형식 검증을 지적합니다. 10월 22일의 새로운 Anthropic 릴리스는 LLM이 패치를 생성하고 다른 LLM이 패치가 올바르다는 증명을 생성하는 파이프라인을 시연했습니다.

"LLM이 하지 않는 유일한 일은 증명 검사기입니다. 누군가 증명을 확인해야 하기 때문입니다. LLM은 환각을 일으키니까요. 그래서 형식적인 것이 필요합니다." — Suman Jana

반론: AI도 기술 부채를 만들고 있다

Hacker News에서 가장 강력한 반박은 헤드라인이 이야기의 절반에 불과하다는 것이었습니다. AI는 오래된 결함의 발견을 가속화하는 동시에 이해하는 사람이 거의 없는 새로운 코드를 생성하고 있습니다.

"아이러니하게도 AI는 우리가 완전히 새로운 수준의 기술 부채를 만들게 하고 있습니다. 아무도 작성된 코드를 실제로 이해하지 못하고 기계를 신뢰할 뿐입니다." — @herval

"사람들이 기술 부채와 보안 허점을 만들지 않는다고 생각하며 대규모 AI 앱을 '바이브 코딩'하는 것이 웃깁니다. 오히려 AI는 기존 허점을 발견하고 있으며 역사상 그 어느 때보다 빠르게 새로운 허점을 만들고 있습니다." — @program_whiz

여러 댓글 작성자는 버그와 부채를 구분했습니다. 버그는 결함입니다. 부채는 아무도 이해하지 못하는 코드의 누적 비용입니다. 그 정의에 따르면 테스트를 통과하지만 이해되지 않는 AI 생성 코드는 부채 상환이 아니라 부채 생성입니다.

"기술 부채는 버그가 아닙니다. 기술 부채는 AI가 애플리케이션을 생성하도록 하고 그것이 어떻게 작동하는지 거의 이해하지 못하는 경우입니다. 이해 없는 AI는 무한한 기술 부채를 만듭니다." — @nwmcsween

관련 우려는 AI 수정이 좁은 경향이 있다는 것입니다. 댓글 작성자들은 AI 생성 패치가 특정 테스트를 통과할 수 있지만 여전히 취약하거나 명확하지 않은 실패 모드를 도입할 수 있다고 보고했습니다. 이는 보안에 중요한 수리에서 가장 중요합니다.

프레임 논쟁: 강제 지불인가, 상환 가능하게 하는 것인가?

Hacker News의 많은 파벌은 기사의 비관적 프레임을 완전히 거부했습니다. AI가 버그를 찾았고 AI가 패치 작성에 도움을 주었다면 헤드라인은 강제로 갚는 것이 아니라 부채를 제거하는 것에 관한 것이어야 한다고 주장했습니다.

"그러므로 헤드라인은 'AI가 40년의 기술 부채를 제거하도록 돕고 있다'로 읽혀야 합니다. AI가 버그를 찾았고 아마도 이 시점에서 패치도 생성했을 것이기 때문입니다." — @Kevin_Flynn

"이것을 'AI가 아무도 시간, 기술 또는 욕구가 없어 찾지 못했던 오랜 소프트웨어 보안 문제를 수정할 수 있게 해주고 있다'고 헤드라인을 쓸 수도 있습니다. 관점의 문제일 뿐입니다." — @cushychicken

다른 사람들은 AI가 지연을 유지했던 변명을 제거한다고 주장했습니다. 이전에 너무 비싸서 정당화할 수 없었던 작업이 저렴해지면서 허용 가능한 방치의 기준이 바뀌었습니다.

"AI는 기술 부채를 제거하지 않을 변명을 모두 없앴습니다." — @Lucasoato

더 회의적인 댓글 작성자는 두 프레임 모두 옳지 않을 수 있으며 결과는 일회성 상환이 아니라 영구적인 러닝머신일 수 있다고 제기했습니다. 모든 사소하지 않은 수정이 새로운 문제의 위험을 수반한다면 업계는 단지 움직이는 표적이 되기 위해 지속적으로 코드를 소각하고 회전시킬 수 있습니다.

"그것이 사실이고 AI가 유한한 시간 안에 완벽한 소프트웨어를 마법처럼 만들 수 없다면, 실제로 일어난 일은 적대적 AI가 우리의 기술 부채를 악용할 위협이 우리가 항상 움직이는 표적이 되기 위해 코드를 태우고 회전시키도록 강요할 것이라는 점입니다." — @swatcoder

병목은 발견이 아니라 배포입니다

실용적인 반론이 논쟁의 많은 부분을 차단했습니다. 버그를 찾는 것은 저렴해지고 있지만 대규모 조직 내에서 수정 사항을 배포하는 것은 그렇지 않습니다.

"많은 대규모 조직에서 가장 오래된 시스템에는 명확한 소유자가 없고 충분한 자동화 테스트도 부족하며 릴리스 프로세스를 이해하는 사람은 소수에 불과합니다. 중요한 패치가 도착해도 팀은 여전히 기본적인 질문에 답할 수 없습니다. 이 구성 요소가 실제로 어디에서 실행되고 있는지, 변경을 승인할 수 있는 사람은 누구인지, 다른 것을 깨뜨리지 않았다는 것을 어떻게 알 수 있는지 말입니다." — @rahulsawhneyonl

이것이 '재앙이 피해졌다'는 주장이 즉각적인 회의론을 불러일으킨 이유입니다. 패치가 존재하는 것은 패치가 배포되는 것과 같지 않습니다. 댓글 작성자들은 많은 운영자가 PHP를 자동으로 업데이트하지 않으므로 취약한 표면이 공개 후에도 오랫동안 야생에 남아 있다고 지적했습니다.

"지금도 취약한 서비스가 해킹당하고 있지 않나요?" — @tlhunter

"많은 사람들이 실제로 PHP를 자동 업데이트하지 않으므로 취약점이 야생에서 사라진 것은 아닙니다." — @hoppp

타임라인 반론

한 댓글 작성자는 AI가 결정적인 새로운 요소라는 기사의 전제에 도전하며 Brotli/HTTP2Shell 타임라인이 인간 프로세스가 여전히 지연을 지배한다는 증거라고 지적했습니다. 인용된 타임라인에 따르면 결함이 코드에 8년 동안 존재했고 수정 사항이 Git에 8개월 동안 미출시 상태로 있었으며 최소 4명의 독립적인 연구자가 문제를 발견하고 보고했습니다.

"기사는 PHP2Shell을 현재 취약점 물결의 최악의 사례로 꼽지만 HTTP2Shell/Brotli2Shell은 아마도 더 나빴습니다... 현실의 적어도 일부는 여전히 '인간이 취약점을 몇 달 또는 몇 년 동안 방치하는 것'입니다." — @vanschelven

반론은 AI 주장을 반박하기보다는 복잡하게 만듭니다. 공개 및 수정 파이프라인은 AI가 등장하기 전에 이미 실패하고 있었습니다.

보안 실무자가 실제로 해야 할 일

존스 홉킨스 대학교 정보 보안 연구소의 Matthew Green은 제도적 대응에 대해 비관적입니다. 그의 예측은 일반인이 알아차릴 심각한 사건이 발생한 후에야 의미 있는 자금이 도착할 것이라는 것이며, 그는 이를 아마도 2027년 초로 봅니다.

"정말 나쁜 일이 일어나기 전에는 아무도 이 문제를 해결하지 않을 것입니다. 그리고 PHP2Shell은 정말 나쁠 만큼 나쁘지 않았습니다." — Matthew Green, 존스 홉킨스 대학교

그의 즉각적인 조언은 화려하지 않고 구체적입니다. 기다리지 말고 보안 업데이트가 제공되는 즉시 설치하라는 것입니다.

"휴대전화가 '보안 업데이트가 있습니다. 설치하시겠습니까?'라고 말하면 다음 주까지 기다리지 마세요. 그냥 하세요." — Matthew Green

Jana의 결론은 PHP2Shell이 이상이 아니라 예고편이라는 것입니다.

"이것이 마지막이 아닐 것은 확실합니다. 누가 찾느냐의 문제일 뿐입니다. 바라건대 이번처럼 화이트햇 해커가 먼저 찾기를 바랍니다." — Suman Jana

댓글 작성자들은 실용적인 결과를 추가했습니다. 다른 사람이 하기 전에 자신의 코드에 대해 공격적으로 AI를 사용하고, 버그 바운티 프로그램을 용량 제약이 있는 것으로 취급하고, 빠르게 움직이는 애플리케이션 코드보다 기반 소프트웨어에 형식 검증이 먼저 도래할 것으로 기대하라는 것입니다.

"앞으로 몇 년 안에 기본 소프트웨어의 대규모 트렁크에 대한 검증과 그 위에 있는 소프트웨어에 대한 하위 검증 신뢰 체계를 보게 될 것이라고 쉽게 예측할 수 있습니다." — @samuelknight

완벽하게 안전한 소프트웨어가 가능한가?

스레드의 가장 깊은 의견 차이는 철학적이었습니다. 여러 댓글 작성자는 괴델의 불완전성 정리를 괴델, 에셔, 바흐를 통해 인용하며 어떤 시스템도 원칙적으로 무적이 될 수 없고 단지 깨는 데 더 많은 비용이 들 뿐이라고 주장했습니다. 다른 사람들은 실용적인 목표는 결코 완벽함이 아니라 공격 비용을 표적의 가치 이상으로 높이는 것이라고 반박했습니다.

"사소하지 않은 소프트웨어가 완전히 안전할 수 있는지 우리는 알고 있나요? 아니면 우리가 아무리 고쳐도 그것을 깨는 방법이 항상 존재할까요?" — @carra

"일반적인 복잡성의 소프트웨어는 '증명 가능'할 수 없습니다." — @pyrphoros

그 긴장은 해결되지 않았으며, 그것이 PHP2Shell 이야기의 진짜 주제입니다. AI는 결함 검색을 거의 무료로 만들었습니다. 업계가 동일한 능력을 사용하여 기반을 강화할지, 아니면 단지 더 빨리 패치하는 데 그칠지에 따라 다음 10년의 소프트웨어가 더 안전할지 아니면 단지 더 혼란스러울지가 결정됩니다.

"네, AI가 버그를 드러내는 것을 보게 될 것이고 몇 달 동안 조금 힘들 것입니다. 그러나 이 모든 것이 끝나면 소프트웨어는 그 어느 때보다 안전해질 것입니다." — @glennfiedler