# PHP 를 그만두면 다음 단계의 준비가 시작되었습니다 ── Claude Code 를 통해 PHP2Shell 로 전환할 때 고려한 점

> https://bookfactory.kr/board/news/23787
> 게시판: 뉴스
> 작성자: admin
> 작성일: 2026-10-25T15:57:55.196Z

---

## 이 글에 대해

대상 독자

- 오래된 서버나 지원이 종료된 시스템으로 운영 중인 사이트를 보유하고 계신 분
- PHP 의 심각한 취약점 관련 뉴스를 접하고 자신의 사이트가 안전한지 걱정하시는 분들을 위해
- AI 에이전트를 통해 시스템을 재설계하거나 유지보수를 맡기 시작하신 분

핵심

기존 시스템을 AI 가 코드를 분석하고 수정하며 테스트로 검증하는 것을 중심으로 전환했습니다. 전환 이후 유지보수 과정에서 중요도가 높아진 '수정이 본업 환경에 도달하기까지'라는 항목을 앞으로 비교의 기준에 추가할 계획입니다.

## 목차

- 이 글에 대해
- 교체 작업은 발표 전까지 완료되어 있었습니다.
- 이동하기로 결정한 순간, 생각했던 일
- 이동한 곳에서도 계속 고쳐나가고 있습니다.
- 다음 지원 종료 시 무엇을 기준으로 결정할지
- 결론

## 교체 작업은 발표 전 이미 완료되었습니다.

PHP 에 외부에서 명령을 실행할 수 있는 심각한 취약점인 PHP2Shell 이 발견되어 수정 버전이 공개되었습니다. 공식 웹사이트는 즉시 업데이트할 것을 요청했습니다.

X 에서 이 사실을 알게 되자, 먼저 떠오른 것은 제가 PHP 에서 이전한 사이트였습니다. 이전 전의 해당 사이트는 공식 지원이 이미 종료된 PHP 위에서 실행되고 있었습니다.

새 사이트로의 전환은 발표 일보다 약 한 달 전에 완료되었습니다. 기존 서버로의 외부 웹 접근도 발표 일보다 약 일주일 전에 차단되었습니다.

그 오래된 서버 역시 공격 흔적이 남기 쉬운 부분을 조사했습니다. 확인한 범위에서는 침입 흔적이 발견되지 않았으나, 그것만으로는 과거 침입을 완전히 부정할 수 없습니다.

다시 되돌아보면 전환을 제안한 시기는 Anthropic 이 새로운 모델을 출시한 시기였습니다. 일반 대중용 Claude Fable 5 와 동일한 모델을 기반으로 한 버전은 사이버 공격의 악용 방지를 위해 제공 대상이 제한되어 있었습니다.

내 머릿속에 떠오른 것은 결국 이러한 AI 가 취약점을 악용하는 공격에도 쉽게 노출될 것이라는 막연한 우려입니다. 그런 일이 발생하면 공식 패치를 받을 수 없는 구형 사이트에서는 취약점이 발견되어도 이를 업데이트하여 고치는 기본 대응을 취할 수 없습니다.

이번 취약점은 연구자들이 AI 의 도움을 받아 발견한 것입니다. PHP 는 서버 측 언어를 사용하는 사이트 중 약 70% 에서 사용되고 있습니다. 또한 수정 버전을 발표하기 전에 정보가 유출되었고, 공격 시도가 이미 발견되었습니다.

AI 를 통해 이렇게 빠르게, 이렇게 광범위한 취약점이 발견되었다는 것은 상상조차 하지 못했습니다.

공표 이전까지 종료된 부분은 운에 크게 의존한 것으로 생각됩니다. 하지만 그로써 문제가 완전히 해결되었다고 할 수는 없습니다. 이번 취약성에 영향을 받았는지는 별개로, 수정을 받지 못한 상태로 오랫동안 외부에 노출되어 있다는 사실 자체가 위험을 내포하고 있었습니다.

공표 전후로 새로운 사이트에도 PHP 취약점을 찾아내는 통신이 여러 건 도착했습니다. 새로운 사이트 서버에 PHP 가 설치되어 있지 않다는 것을 확인했으므로, 이번 수정 버전을 즉시 적용할 필요는 없습니다. 급하지 않았던 것은 PHP 수정 버전 때문이었습니다.

## 이동하기로 결정한 순간, 생각했던 것들

구식 사이트는 지원이 종료된 PHP 와 해당 버전에서만 실행 가능한 구식 프레임워크의 조합으로 동작하고 있었습니다.

PHP 버전만 올리는 방법은 거의 고려하지 않았습니다. 프레임워크가 오래된 PHP 에 묶여 있기 때문에, 버전을 올린다면 결국 큰 재구성이 필요하기 때문입니다.

재가공을 위한 대안으로는 완제품 사용 방안이 두 가지, 자체 제작 방안이 두 가지 있었습니다.

출발 지점의 측면은 서비스 형태로 제공되는 소프트웨어 (SaaS) 와 기존 패키지를 의미합니다. 검토한 SaaS 는 내부 코드를 직접 읽어서 수정하는 방식과 맞지 않았습니다. 기존 패키지는 플러그인이나 관리 화면 설정이 복잡하게 얽혀 있어 이번 용도에는 지나치게 크다고 판단되었습니다.

우리가 직접 구현하는 방안은 인증과 같은 기반까지 자체로 구축하는 경우와 Python 웹 프레임워크인 Django 를 활용해 재구축하는 경우입니다. 기반까지 자체로 구축하면 보호해야 할 범위가 지나치게 넓어집니다.

결정적인 기준은 AI 가 모든 부분을 완벽하게 처리할 수 있는가 여부였습니다.

재작성과 이후의 보수적 수정도 모두 Claude Code 에 맡길 계획이었습니다. Django 의 경우 데이터 모델, 템플릿, 설정이 모두 코드로 읽히며 변경 사항을 테스트로 확인할 수 있기 때문입니다. AI 가 코드를 분석하고 수정하며 검증하도록 하는 이 방식이 적합하다고 판단했습니다.

다만, AI 에 맡기는지 여부를 확인하고 그 변경을 수용할지 여부를 판단하는 것은 별개로 고려하고 있습니다.

또 하나의 약속은 다음 버전으로 지원 종료 부채를 넘기지 않는 것입니다. 이를 위해 Django 는 장기 지원 버전을 선택했습니다. 다만, 수정 버전이 제대로 출시되어 자신의 웹사이트까지 도달한다는 사실을 체감하게 된 것은 이직 이후였습니다.

## 이동한 곳에서도 계속 고쳐나가고 있습니다.

이해관계가 바뀌었다고 해서 끝난 것은 아닙니다. 새로운 구성으로 교체된 지 얼마 되지 않은 짧은 시간 동안, 사용 중인 부품의 심각한 취약성에 대한 뉴스가 여러 차례 보도되었습니다.

일반적인 업데이트는 앱과 OS 를 구분하여 처리하며, 앱 라이브러리는 버전을 고정하고 교체하는 것은 모든 테스트가 통과된 이후입니다.

OS 보안 패치는 자동으로 적용되도록 설정하고, 사이트가 중단되면 즉시 인지할 수 있도록 했습니다. 자동 처리 범위와 사전 검증 범위는 정지 가능 시간, 업데이트의 긴급성, 롤백 방법 등에 따라 달라집니다. 현재 구분은 현재 환경의 조건에 따라 선택된 것입니다.

취약성을 확인하는 방법에도 결정해야 할 사항이 있습니다. 사용하는 소프트웨어의 구성 요소와 버전을 파악하여 취약성 정보와 비교할 수 있도록 준비하는 것입니다.

SBOM(소프트웨어 구성 요소 목록)은 소프트웨어 구성 요소를 기록한 목록으로, 이를 위한 방법 중 하나입니다. 저는 고정된 버전의 의존성 목록과 자동화된 취약점 검사를 통해 이를 파악하고 교차 검증하고 있습니다.

반면, 의존성 목록과 점검만으로는 모든 것을 파악할 수 없습니다. 라이브러리에 다른 부품이 함께 포함되어 있어 의존성 점검에서 누락될 수도 있습니다. 이는 AI 와 함께 실제 프로덕션 환경을 직접 살펴본 뒤 처음 깨달은 사실입니다.

뉴스가 나오면 AI 가 실제 버전을 읽기만 하고 확인하게 합니다. 확인하는 대상은 사용 중인 버전이 영향을 받는지에 대한 것뿐만 아니라, 해당 결함이 우리 설정에서도 공격 조건을 충족하는지까지 포함합니다.

이러한 확인을 거듭하다 보니, 다음 단계로 넘어갈 때 고려해야 할 사항들이 드러나고 있습니다.

## 다음 지원 종료 시 무엇을 기준으로 결정할지

현재 구성도 결국 지원 종료 (EOL) 시기가 오게 됩니다. 그 시점에 무엇을 기준으로 삼을지 미리 정리해 두겠습니다.

첫 번째는 이번과 마찬가지로 AI 가 모든 부분을 다룰 수 있는가입니다. 읽을 수 있고, 수정할 수 있는 것뿐만 아니라, 수정된 결과를 테스트로 검증할 수 있어야 합니다. 이번 재구축 과정에서 축적된 테스트들은 다음 단계로 넘어갈 때 동작을 확인하는 기반이 되도록 하겠습니다.

두 번째는 이동 후 무게가 증가하고 취약점이 발견된 이후의 여정입니다.

상류에서 보고를 받고 수정안을 제출하는 체계가 있는지, 그 수정안이 사용 중인 버전이나 획득 경로까지 도달하는지, 그리고 도달한 수정안을 검증하여 실제 서비스에 반영할 수 있는지.

이 세 단계 중 하나라도 끊기면 수정판이 존재하더라도 본인이 직접 경험할 수 없습니다. 이번에는 수정판이 나올 전부터 공격이 시작되었습니다. 뉴스 보고 나서야 행동할 수 있다는 전제조차 성립하지 않는다는 느낌을 받습니다.

수정이 도착할 때까지 견딜 수 있을지, 접촉 가능한 범위를 좁히는 다른 대비책을 마련해 두는 방안도 함께 검토해 보겠습니다.

경계 수비를 권해도 미루는 장면을, 오랫동안 일해 온 과정에서 여러 번 목격해 왔습니다.

눈에 보이는 성과와 아직 발생하지 않은 피해에 대한 대비를 같은 자리에서 비교하는 것은 어렵습니다. 제를 권유해 주신 분도 판단에 필요한 자료를 충분히 전달해 주셨는지 돌아보아야 할 것 같습니다.

공개 이후 사이트 소유자로부터 "이제야 전환이 가능해져서 정말 좋았어요"라는 말을 들었습니다.

이러한 일들은 우선순위를 재고할 계기가 될 것 같습니다. 저도 논란을 기다리지 않고 제안 단계부터 판단에 필요한 자료를 준비해 나가고자 합니다.

다음은 수정이 적용된 후 실제 서비스 환경에 도달하기까지의 과정을, 처음부터 비교하는 축으로 서술합니다.

## 결론

이전 글에서는 AI 가 생성한 결과물이 AI 의 자체 판단만으로 종료되지 않도록 하는 것에 대해 썼습니다.

이번에 돌아본 것은 재구현 전 이동先の 선택 기준이 무엇이었는지에 관한 것입니다. AI 가 처리 가능한지를 기준으로 선택한 것은 이동 후 유지보수의 용이성에도 기여했습니다.

선택을 한 이후에도 매일 점검과 취약성 공개 시 확인은 계속됩니다. 유지 가능성 확인 역시 완료 판정과 마찬가지로, 생성 시 한 번에 끝나는 것이 아닙니다.

> 
> 
> 본 글은 작성 시점의 정보에 기반합니다. 각社の 데이터 이용 정책은 자주 변경되므로 실제 사용 전 반드시 공식 최신 약관을 확인하시기 바랍니다. 옵트아웃 설정은 '미래 학습에 사용하지 않을 것'이라는 계약적 약속일 뿐, 단기 데이터 보관·안전성 목적의 인간 검토·계정 침해 등으로 인한 데이터 유출 위험을 완전히 제거하는 것은 아닙니다. 업무에서 기밀 정보를 다루는 경우 Consumer 플랜의 옵트아웃에 의존하지 말고, 기업용 계약 하에서의 사용을 권장합니다. 계약뿐만 아니라 기술 통제와 운영 규칙을 결합한 다층적 설계가 실무적입니다. 소속 조직에 AI 이용 정책이 있다면 이를 따르시기 바랍니다. 본 글은 개인 계정에서의 업무 기밀 정보 처리(Shadow AI)를 권장하지 않습니다.
> 

**출처:** [note 원문](https://note.com/glad_viper103/n/nd4c0cf6ea3ce)

*번역: Qwen 3.5(.48) 초벌 + 교정 40청크*

[원문 보기](https://note.com/glad_viper103/n/nd4c0cf6ea3ce) | 출처: note.com