AI가 취약점을 발견하는 시대, 보안 대응이 가능한 조직을 어떻게 육성할 것인가 — php2shell 사례로 본 인재 양성 및 기술 투자

2026년 10월 21일, PHP에서 두 건의 중대한 취약점에 대한 긴급 보안 릴리스가 공개되었습니다.

'php2shell'이라고 불리는 이번 문제에서는 특정 조건이 성립할 경우, 인증되지 않은 공격자에 의한 원격 코드 실행(RCE)이 가능해집니다.

PHP 공식 권고문은 모든 PHP 사용자에게 신속한 업데이트를 요구하고 있습니다.

이 뉴스에 대해 'PHP를 사용하지 않으면 된다', 'AI가 수정하게 하면 된다'라는 의견도 나올 수 있습니다. 하지만 그것만으로는 보안 대응의 본질을 파악할 수 없습니다.

AI가 취약점을 발견했다고 할 때, 누가 영향을 조사하고, 누가 수정 방침을 결정하는 것일까요? 누가 사용자에게 패치를 전달하고, 누가 사업 지속 가능성을 판단하는 것일까요?

제가 이번에 주목한 것은 취약점 자체뿐만 아니라, 문제의 발견부터 수정, 배포, 운영까지를 뒷받침하는 인재와 조직의 역량입니다.

본 기사에서는 php2shell을 소재로 AI 시대의 보안 인재 양성 및 기술 투자에 대해 고찰합니다.

취약점을 발견할 수 있는 것과 안전한 수정을 완성할 수 있는 것은 별개의 능력입니다.

이번에 수정된 내용은 다음 두 건입니다.

특히 Apache의 mod_php에서는 애플리케이션 코드가 실행되기 전에 미인증 요청으로부터 공격이 성립되는 경로가 실증되었습니다. PHP-FPM에서도 애플리케이션 처리 경로를 통한 RCE가 확인되었습니다.

수정 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35입니다. 배포판이 제공하는 백포트(backport)에 대해서는 각 벤더의 안내를 확인할 필요가 있습니다.

PHP Foundation의 보고에 따르면, OOM 문제의 조짐은 2024년에 인지되었습니다.

하지만 수정안에는 하위 호환성 파괴, 새로운 서비스 거부 가능성, 다수의 확장 모듈에 대한 영향 등 어려운 트레이드오프(trade-off)가 있었습니다.

깊은 내부 지식을 가진 개발자가 적고, 합의 형성을 통한 의사 결정도 어려워진 결과, 수정 작업은 정체와 재개를 반복했습니다. PHP Foundation 스스로 이것을 의사결정과 인적 자원의 부족으로 인한 구조적인 실패로 인정하고 있습니다.

2026년 8월에는 AI를 이용한 보안 연구 등으로부터 문제의 중대성이 더욱 명확해지면서, 수정이 최우선 과제가 되었습니다.

여기에 AI 시대의 특징이 있습니다.

AI는 잠재적인 문제를 발견하고 재현 및 조사를 지원할 수 있습니다. 하지만 광대한 에코시스템에 영향을 미치는 수정 방침을 선택하고, 호환성을 검증하며, 릴리스를 성립시키는 작업에는 여전히 숙련된 엔지니어와 조직적인 판단이 필요합니다.

보안 대응은 개인의 개발 작업이 아니라, 발견부터 본 운영까지를 연결하는 업무 프로세스입니다.

취약점 대응을 공정으로 분해하면 필요한 전문성이 다르다는 것을 알 수 있습니다.

취약점의 세부 사항을 즉시 공표하는 것이 아니라, 수정을 담당하는 조직이나 배포 사업자와 정보를 공유하고, 사용자가 업데이트할 수 있는 상태를 갖춘 후에 공개하는 것을 목표로 합니다.

이번에 그 조율의 어려움도 명확해졌습니다.

PHP Foundation의 경위 설명에 따르면, 10월 20일에 CVE 번호 등이 유출되었기 때문에, 당초 10월 22일로 예정했던 릴리스가 21일로 앞당겨졌습니다.

게다가 보안 기업 Calif가 PoC 실연 영상을 실수로 공개했습니다. 이는 공격 코드 자체를 공개했다는 의미는 아니지만, 공격이 성립하는 모습과 일부 기술 정보가 알려지게 되었습니다.

또한, Chainguard는 조정된 공개 시점보다 6시간 이상 빨리 수정된 컨테이너 이미지를 배포했습니다. 이로 인해 공식 공개 전에 수정 내용을 분석할 수 있는 상황이 발생했습니다.

이것들은 개별 개발자의 기술력만으로는 해결할 수 없는 문제입니다.

OpenAI의 협조 공개에 관한 제안에서도, 유지보수자, 연구자, 배포 사업자, 인프라 사업자가 연계해야 할 필요성이 설명되고 있습니다.

우수한 개발자가 존재하는 것과 보안 대응 프로세스가 조직으로서 기능하는 것은 별개입니다.

발견 능력을 높이는 것뿐만 아니라, 수정 사항을 확실하게 사용자에게 전달하는 시스템을 육성할 필요가 있습니다.

시스템의 책무를 이해하고 있다면, 전면 중단과 정상 운영 사이에서 기능을 제한하여 운영하는 선택지를 설계할 수 있습니다.

예를 들어, WordPress로 운영되는 웹사이트를 생각해 보겠습니다.

긴급 패치를 즉시 적용할 수 없는 경우, 사이트를 전면 중단하거나 평소처럼 운영하는 이분법적 선택에 빠지기 쉽습니다.

하지만 기능을 분해하면 다른 선택지가 보입니다.

CQRS (Command Query Responsibility Segregation)는 상태를 변경하는 작업과 정보를 조회하는 작업의 책무를 나누는 설계상의 개념입니다.

WordPress라면, 글을 열람하는 것과 로그인/게시물 작성/편집/파일 업로드를 구분할 수 있습니다.

HTTP 사양에도 이 개념과 관련된 구분이 있습니다.

RFC 9110의 Safe Methods에서는 GET이나 HEAD를 클라이언트가 대상 리소스의 상태 변경을 요구하지 않는 메서드로 정의하고 있습니다.

또한, 2026년에 표준화된 HTTP QUERY 메서드(RFC 10008)는 요청 본문(request body)을 가지면서도 안전하고 Idempotent한 검색 처리를 표현할 수 있습니다.

여기서 중요한 것은, HTTP 메서드의 Safe성이 PHP 런타임의 메모리 안전성을 보장하지 않는다는 점입니다.

GET으로도 서버 내부에서 로그 기록이나 동적 처리가 발생합니다. 사양에 어긋나게 GET으로 업데이트 처리를 실행하는 애플리케이션도 존재합니다.

더 나아가, 이번 취약점에는 애플리케이션 코드 실행 이전에 성립하는 공격 경로가 있습니다. GET/HEAD로 제한하는 것만으로는 안전해지지 않습니다.

이 전제하에, 기능을 축소시키는 방안을 비교해 보겠습니다.

Cookie 역시 정리가 필요합니다. Cookie는 HTTP 자체의 필수 기능이 아니라, 추가적인 상태 관리 메커니즘입니다. 공개 페이지를 Cookie나 로그인 세션에 의존하지 않는 설계로 한다면, 중단시킬 수 있는 기능을 늘릴 수 있습니다.

하지만, Cookie를 사용하지 않으면 이번 취약점이 막힌다는 의미는 아닙니다.

또한, HTTP는 Stateless한 프로토콜이지만, PHP-FPM의 워커 프로세스는 여러 요청을 순차적으로 처리합니다. 요청 간에 상태를 적절하게 초기화할 책무는 런타임 측에 있습니다.

공격면을 줄이는 완화책은 취약한 PHP 런타임을 수정하는 보안 패치의 대체재가 될 수 없습니다.

이번 PHP 공식 권고 사항도, 업데이트만이 완전한 대처라고 설명하고 있습니다.

기능 축소는 업데이트까지의 리스크 저감이나, 업데이트 작업 중 서비스 지속을 지원하는 설계입니다.

구체적인 대책은 공식 권장 사항을 우선하고, 환경별로 유효성을 확인해야 합니다. 예를 들어, OOM 문제에 대한 임시 대책으로 안내된 memory_limit=-1도 OS 레벨의 메모리 고갈까지 막아주지는 못합니다.

언어의 문법을 아는 것뿐만 아니라, HTTP, 런타임, 메모리 관리의 전제를 이해하는 것이 미지의 장애에 대한 응용력으로 이어집니다.

이전 장의 완화책은 PHP의 문법만을 학습해서는 도출할 수 없습니다.

HTTP의 메서드와 부작용(side effect), 웹 서버와 PHP-FPM의 책무 분담, 프로세스의 생명 주기, 메모리 해제, 접근 제어 등 여러 지식을 조합해야 합니다.

저는 이번 문제를 기본 사양을 다시 학습하는 교재로도 중요하다고 생각합니다.

예를 들어, HTTP의 Stateless성을 '서버가 상태를 가지지 않음'으로 이해하고 있다면, 워커 내부의 상태가 후속 요청에 영향을 미치는 문제점을 간과할 가능성이 있습니다.

그렇다면 PHP에서 Node.js나 Rust로 마이그레이션하면 될까요?

Rust의 Ownership이나 Borrowing 체크는 메모리 안전성에 관한 많은 결함을 컴파일 시점에 방지한다는 기술적 우위가 있습니다.

이는 정당하게 평가되어야 합니다.

반면, Node.js에도 런타임이나 네이티브 의존성(native dependency)의 취약점이 있으며, Rust 역시 unsafe 코드, FFI (Foreign Function Interface), 의존 라이브러리, 논리적 취약점 등의 과제가 있습니다.

언어 선택과 보안 운영 능력의 정비는 별개의 판단입니다.

移行에는 기존 시스템의 개수, 전문 인력 확보, 의존 라이브러리 업데이트, 운영 체제 재구축이 수반됩니다.

기술을 피하는 것보다, 그 기술의 전제와 한계를 이해하는 것이 현실적인 문제에 대처하는 능력으로 이어집니다.

모두를 보안 연구자로 키울 필요는 없습니다. 하지만 서로 다른 전문성을 가진 인재들이 연계되지 않으면 대응은 완성될 수 없습니다.

보안 대응에 필요한 역량을 저는 세 가지 단계로 나누어 생각합니다.

실무 단계에서는 패치 적용 절차뿐만 아니라, 변경으로 인한 장애나 사업에 미치는 영향을 평가하는 능력이 필요합니다.

전문 단계에서는 PHP Internals와 같은 런타임 내부 개발에 참여할 수 있는 고도의 지식이 요구됩니다.

이번 OOM 문제처럼, 하위 호환성과 안전성이 충돌하는 수정은 단순한 코드 생성만으로는 완성되지 않습니다.

하지만 모든 기업이 이러한 전문가를 사내에 보유할 필요는 없습니다.

중요한 것은, 사내에서 보유해야 할 역량과 외부의 전문가나 OSS 커뮤니티에 의존하는 역량을 구분하고, 그 연결 방법을 정비하는 것입니다.

전문가가 수정한 패치를 자사 환경에 적용할 수 없다면 이용자는 지킬 수 없습니다. 반대로, 운영 담당자만으로는 런타임 내부의 중대한 문제를 수정할 수 없는 경우도 있습니다.

인재 육성은 각 단계를 고립시키지 않고, 문제가 인계되고 협업할 수 있도록 설계되어야 합니다.

AI를 활용한 훈련에서는 정답을 찾는 능력뿐만 아니라, 불확실한 상황에서 판단하고 그 근거를 설명하는 능력을 키웁니다.

저는 php2shell을 소재로 한 책상 시뮬레이션을 엔지니어뿐만 아니라 CTO나 경영자도 경험하도록 제안합니다.

책상 시뮬레이션이란, 실제 시스템을 공격하는 것이 아니라, 예상되는 사고나 장애에 대해 역할을 분담하여 대응을 검토하는 훈련입니다.

예를 들어, 다음과 같은 시나리오가 있습니다.

가정 상황:

자사는 WordPress로 기업 사이트와 회원 대상 서비스를 운영하고 있습니다. 중대한 PHP 취약점이 공개되었으나, 사용 중인 확장 기능과의 호환성 검증이 끝나지 않았습니다.

연습은 다음 순서로 진행됩니다.

• 조사: AI를 사용하여 공식 어드바이저리를 조사하고, 영향을 받는 PHP 버전과 구성을 확인합니다. -
  영향 분석: 자사의 서버 구성도와 대조하여 어떤 서비스에 영향이 있는지 정리합니다. -
  완화책 비교: 패치를 즉시 적용할 수 없는 조건에서, 업데이트 작업과 병행하여 실시하는 기능 축소, WAF, 정적 배포 등을 검토합니다. -
  경영 판단: CTO 역할을 맡은 사람이 경영자 역할에게 중단되는 기능, 지속 가능한 사업, 잔존 리스크, 복구 조건을 설명합니다. -
  추가 정보: 도중에 PoC의 조기 공개나 수정 패키지 배포 지연 등을 전달하며 판단을 재검토합니다.

AI는 조사 지원, 추가 시나리오 생성, 판단 누락 지적, 연습 후 회고를 담당하게 합니다.

다만, AI의 답변은 공식 정보나 실제 검증 환경과 대조해야 합니다. 미공개 취약점 정보, 기밀 시스템 구성, 인증 정보 등을 허가 없이 외부 AI 서비스로 전송해서는 안 됩니다.

또한, 실제 긴급 패치 적용을 훈련을 위해 지연시켜서는 안 됩니다. 연습은 본 대응과는 독립된 환경이나 시간에서 실시합니다.

이 훈련으로 측정하고 싶은 것은 정답의 정확성만이 아닙니다.

정보가 부족한 상황에서 누가 무엇을 판단하는지. 어떤 조건에서 판단을 변경하는지. 기술적인 리스크를 사업상의 영향으로 설명할 수 있는지.

그러한 실무 능력을 키우는 것이 목적입니다.

개인의 기술력을 조직의 대응 능력으로 바꾸기 위해서는 책임 분담, 의사 결정, 검증, 교육을 지속적인 시스템으로 만들어야 합니다.

보안 대응에서는 누가 기술적 조사를 담당하고, 누가 본 환경에 변경을 승인할지 명확히 할 필요가 있습니다.

예를 들어, SRE가 업데이트를 실행할 수 있어도, 사업 중단 권한이 없다면 긴급 시 판단이 지연될 가능성이 있습니다.

CTO가 중단을 판단하는 경우에도, 사업에 미치는 영향이나 잔존 리스크를 설명할 정보가 필요합니다.

이처럼 기술적인 책무와 의사 결정 권한을 연결하는 것이 조직 설계의 과제가 됩니다.

저는 다음과 같은 개선을 우선해야 한다고 생각합니다.

• 보안 대응 책임자, 대행자, 승인 권한을 정의한다.
• 기밀 정보의 공유 범위와 공개 규칙을 정립한다.
• 검증 환경, 업데이트 절차, 백업 및 롤백 절차를 마련한다.
• 사양 조사나 OSS(Open Source Software)에 대한 기여를 교육 과정에 포함시킨다.
• 특정 엔지니어에게 의존하지 않고, 여러 사람이 대응할 수 있도록 한다.

여기서 중요해지는 것이 AI로 인한 효율화로 확보된 시간의 활용입니다.

AI 덕분에 코드 조사나 테스트 작성이 효율화되더라도, 그 성과를 단순히 인력 감축으로 연결하면 리뷰나 교육에 필요한 능력을 잃을 수 있습니다.

오히려 AI로 절약한 공수를 품질 보증(QA), 보안 검토, 인재 육성 등에 재투자하는 방침이 고려될 수 있습니다.

PHP Foundation이 보고한 수정 지연은 기술적인 난제인 동시에, 전문 인력 부족과 의사 결정의 문제이기도 했습니다.

전문가가 제한적일 경우에는 회사 내부에서 모든 것을 해결하려 하기보다, 외부 연구자, 벤더, OSS 커뮤니티와의 협력 체계를 갖출 필요가 있습니다.

그때도 외부 위탁할 수 있는 작업과 자사에서 반드시 보유해야 할 판단 책임은 분리해서 생각합니다.

AI로 인해 취약점 발견 속도만 향상된다고 해도, 수정, 검증, 배포, 적용 능력이 부족하면 조직 전체의 대응은 빨라지지 않습니다.

조직의 대응 능력은 가장 유능한 한 명에게 있는 것이 아니라, 일련의 대응 공정들이 얼마나 막힘없이 연계될 수 있는지에 의해 평가되어야 합니다.

보안 대응에 대한 투자는 이번 취약점을 해결하는 것뿐만 아니라, 다음 미지의 문제에 대응할 수 있는 조직을 키우기 위한 투자입니다.

경영자의 입장에서 보면, 긴급 패치 대응은 예정에 없던 비용입니다.

하지만 그 지출을 일회성으로 끝내버리면, 다음 취약점에서도 같은 조사와 판단을 반복하게 됩니다.

이번 대응을 통해 시스템 구성도, 영향 조사 절차, 업데이트/복구 절차, 의사 결정 기록, 교육 자료를 갖춘다면, 그것들은 미래에도 활용할 수 있는 조직의 자산이 됩니다.

이러한 투자 성과는 구체적인 지표로 평가할 수 있습니다.

안전성, 속도, 사업 지속성을 동시에 평가할 것이 필요합니다.

PHP에 대한 지속적인 투자와 Rust 등으로의 전환을 비교하는 경우에도 마찬가지입니다.

프로그래밍 언어가 제공하는 안전성은 중요하지만, 여기에 더해 전문 인력 확보, 전환 및 운영 비용, OSS 유지보수 체제, 장기적인 업데이트 능력을 평가해야 합니다.

이번 php2shell은 AI가 중대한 취약점 발견에 기여할 수 있음을 보여주는 한편, 그 수정과 공개에는 많은 전문가와 조직의 협력이 필요하다는 점도 명확히 했습니다.

엔지니어에게는 HTTP나 런타임의 기본 사양을 다시 배우고, 미지의 문제에 대응하는 판단력을 기를 기회입니다.

CTO에게는 취약점을 발견하는 사람, 수정하는 사람, 적용하는 사람, 경영자에게 설명하는 사람을 연계시키는 조직 설계 과제입니다.

경영자에게는 보안 대응을 일시적인 손실이 아니라, 미래의 사업 지속성을 지탱하는 기술 투자로 생각할 기회입니다.

저는 AI 시대의 기술 투자를 고려할 때, 코드를 작성하는 능력뿐만 아니라 문제점을 발견한 시점부터 해결에 이르기까지 조직 전체의 능력을 중시해야 한다고 생각합니다.

AI가 문제 발견 속도를 높인다면, 기업 역시 문제를 해결할 수 있는 조직을 그에 맞는 속도로 키워야 합니다.