# PHP 의 치명적인 취약점 'PHP2Shell'에 대해 생각한 바. Java 와 Python 은 안전한가? SI 기업의 개발은 앞으로 어떻게 변할 것인가

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

---

안녕하세요, 요헤이입니다.

다시 한번 업무 관련 글을 써볼까 생각해보고 있습니다.

2026 년 10 월 이후 프로그래밍 언어인 PHP 에 심각한 취약점이 발견되어 큰 화제가 되고 있습니다.

이번에 발견된 것은 'PHP2Shell'이라는 취약점입니다.

이러한 악용 시 외부에서 불법 프로그램을 실행당하거나 서버를 탈취당할 수 있어 매우 심각한 문제입니다.

이 문제에 대해 일부 웹 서비스는 예방적으로 서비스를 중단하는 조치를 취했습니다. 평소 사용하는 서비스가 중단되면 생활에 영향을 미치기도 하죠.

그런데 이 뉴스를 본 순간, 먼저 떠오른 생각은 있었습니다.

"뭐야? PHP 는 20 년 전부터 취약점이 문제가 아니었지?"

IT 업계에서 약 20 년간 근무해 왔습니다.

프로그래머, 시스템 엔지니어, 인프라 엔지니어 등 다양한 직군에서 시스템 개발에 참여해 왔습니다.

그런 저에게 PHP 의 보안 문제는 결코 새로운 주제가 아닙니다. 초기부터 PHP 라는 개발 언어는 취약점이 많았으며, 이후 보안 대응에 시달릴 것이라고 예상했기 때문에 개발 현장에서 사용을 피했습니다. 따라서 현재 저의 업무에서는 특별히 보안 리스크 대응에 시달리고 있지 않습니다.

하지만 이번 문제를 자세히 조사해 보니 단순히'PHP 가 과거부터 위험했다'고 치부할 수 없는 것이 밝혀졌습니다.

그리고 또 다른 궁금한 점이 있습니다.

이건 향후 시스템 개발 방식을 바꿀지도 모른다.

그렇습니다.

SI 업체로서 업무를 수행하고 있어 이번 문제를 보니 다소 긴장스럽습니다...

어떤 개발 언어를 선택해야 할지.

고객에게 보안의 안전성을 어떻게 설명할 것인가.

개발 중 중대한 취약점이 발견되었을 때 어떻게 대응할 것인가.

그런데 앞으로 Java 나 Python 에도 같은 문제가 발생할지도 모른다는 점이다.

오늘은 PHP 취약점을 정리한 후, 향후 시스템 개발의 방향을 IT SIer 의 관점에서 살펴보고자 합니다.

또한, 이번 기사는 2026 년 10 월 25 일 현재 공개된 정보를 바탕으로 작성되었습니다.

前半は実際に確認されている事実、後半は自分自身の考察や予測です。

## 목차

- PHP 에서 발견된 중대한 취약점 'PHP2Shell'이란
- PHPの脆弱性は20年以上前から問題になっていた
- 왜 이번 PHP 문제가 사회적 파장을 불러일으켰는지에 대한 이유
- 이제 본론입니다. SIer(시스템 통합 기업)으로서 느낀 공포
- 개발 언어의 취약점이 존재하지 않는다는 것을 증명할 수 있는가
- 가장 적합한 언어를 선택하더라도 사용할 수 없는 가능성이 있습니다.
- 다음으로 표적이 될 언어가 Java 나 Python 이 아닐까
- Java 는 어떨까
- 파이썬은 어떨까
- 자바스크립트와 노드.js도 무시할 수 없습니다.

## PHP 에서 발견된 중대한 취약점 'PHP2Shell'이란

먼저 이번에는 어떤 일이 일어났는지 간단히 정리해 보겠습니다.

2026 년 10 월 21 일, PHP 의 개발자가 중대한 취약점을 수정한 새로운 버전을 공개했습니다.

대상된 취약점은 다음 두 가지입니다.

취약점과 그 내용

- 메모리 부족 발생 시 오류 처리에 기인한 문제
- CVE-2026-109619: 요청 처리 시 해제된 메모리를 참조하는 취약점

두 가지 모두 심도 (Severity) 를 나타내는 CVSS v4.0 점수가 9.2 입니다.

최대값이 10 이므로 매우 위험한 상황임을 알 수 있습니다.

이러한 취약점이 악용되면 공격자가 인증 없이 서버 외부에서 임의의 코드를 실행할 수 있습니다.

이를 원격 코드 실행 (RCE: Remote Code Execution) 이라 합니다.

RCEP이 성립되면 무엇이 두려운가?

예를 들어, 웹 서버에서 악성 프로그램이 실행되거나 서버 내부 정보가 유출되거나, 다른 시스템에 대한 공격에 악용될 수 있습니다.

즉, 웹사이트를 표시하는 메커니즘이 서버의 침입 경로가 되는 것입니다.

이번 취약점 중 특히 우려되는 점은 PHP 내부 처리에 문제가 존재했다는 사실입니다.

일반적인 웹 애플리케이션의 취약점으로는 SQL 인젝션이나 크로스사이트 스크립팅 (XSS) 등이 알려져 있습니다.

이러한 문제는 애플리케이션 구현 방식에 따라 자주 발생합니다.

그런데 이번 PHP2Shell 은 PHP 실행 환경 자체에 존재하던 문제였습니다.

특히 Apache 의 mod_php 를 사용하는 구성에서는 애플리케이션의 PHP 코드가 실행되기 전에 공격이 성공한다는 것이 입증되었습니다.

이건 정말로 매우 곤란한 일입니다.

코딩을 얼마나 세심하게 하든 애플리케이션 외부에서 문제가 발생할 수 있습니다.

물론, 모든 PHP 환경에서 공격이 동일하게 성립하는 것은 아닙니다.

웹 서버와의 연동 방식, 설정, 공격 조건 등에 따라 위험도는 달라집니다.

하지만 PHP-FPM 등 구성 요소도 영향 대상이 되어 광범위한 대응이 필요해졌습니다.

개발자는 PHP 8.2, 8.3, 8.4, 8.5 각 버전 시리즈에 대한 수정 버전을 제공합니다.

그런데 PHP 8.1 이전에는 PHP 프로젝트로서의 지원이 종료되었습니다.

이러한 오래된 버전을 사용하는 시스템에서는 단순한 업데이트로 해결되지 않으며, '업데이트가 어렵다'는 문제가 이번 논의의 핵심이라고 생각합니다.

귀에 들어오는 친밀한 사례로는, '업데이트가 불가능하면 대응도 불가능하다'는 원칙 때문에 재작성을 하거나 서비스 종료에 시달린 사례도 있었다는 말입니다.

## PHPの脆弱性は20年以上前から問題になっていた

그런데 이제 조금 전의 이야기를 해보겠습니다.

앞서 언급했듯이 PHP 의 보안 문제는 과거부터 지적되어 왔다는 기억이 있습니다.

궁금한 점이 생겨 조사해 보았습니다.

그 후 2002 년 7 월 22 일, PHP 의 개발자가 심각한 취약점에 대해 공식적으로 발표했습니다.

대상은 PHP 4.2.0 과 4.2.1 입니다. (nostalgic 버전입니다.)

HTTP POST 요청을 분석하는 처리에 문제가 있어 외부에서 악성 코드가 실행될 수 있다는 것입니다.

당시에도 서버가 탈취될 위험성이 지적되었습니다.

그건 24 년 전의 이야기입니다.

이번 회와 완전히 다른 취약점이지만, 외부 요청 처리를 계기로 서버가 공격받는다는 점에서는 공통점이 있습니다.

또한 초기 PHP 에는 '레지스터 글로벌스(register_globals)'라는 기능이 있었습니다.

이 기능은 외부에서 전송된 값 등을 자동으로 변수로 처리합니다.

편리한 반면으로, 프로그램 작성 방식에 따라 외부에서 의도하지 않은 변수 조작이 발생할 위험이 있었습니다.

이 기능은 2002 년 기본 설정으로 비활성화된 후 폐지되었습니다.

즉, PHP 는 20 년 이상 보안 취약점을 해결해 왔으며, 이를 지속적으로 개선해 온 언어입니다.

여기에서 오해하고 싶지 않은 것은 과거의 취약점이 그대로 24 년간 방치되었던 것이 아니라는 점입니다. (일단, 확인을 위해 덧붙입니다.)

당시 발견된 문제들은 수정되었고, PHP 자체도 진화해 왔습니다.

이번에 발견된 취약점은 그들과 별개의 문제입니다.

그러나 장기간에 걸쳐 개선이 지속되어 온 소프트웨어라도 여전히 심각한 취약점이 남아 있을 수 있습니다.

이것이 다시 한번 부각되었을 것 같습니다.

그리고 이는 PHP 에만 국한된 이야기일 것 같지는 않습니다.

## 왜 이번 PHP 문제가 사회적 파장을 불러일으켰는지에 대한 이유

이번 취약성은 단순한 IT 뉴스에 그치지 않았습니다.

2026 년 10 월 21 일, 재무성은 PHP 취약점 대응 조치로 일부 웹 콘텐츠와 서비스를 중단한다고 발표했습니다.

22 일에 안전 대책이 마련된 콘텐츠를 순차적으로 공개를 재개한다고 발표했습니다.

도쿄도 또한 10 월 22 일 일부 서비스를 예방적으로 중단한다고 발표했습니다. 또한同日, 국내의 다양한 서비스가 긴급 중단되었습니다. 자주 이용하는 버스 위치 정보 시스템인 '바스키타'도 중단되어 상당한 불편을 겪게 되었습니다...

여기서 중요한 점은 '서비스 정지'와 '공격 피해'를 구분해야 한다는 것입니다.

실제로 공격을 받아 멈춘 사례는 있을 수 있지만, 모두 그런 것은 아닙니다.

이번에는 심각한 취약점이 존재할 가능성을 고려하여 피해 예방을 위한 중단 조치도 취하고 있습니다.

저는 이 판단 자체를 이해합니다.

행정 서비스나 기업의 웹 시스템이 해킹당해 정보 유출 등의 피해가 발생한다면, 이는 곧 큰 문제가 됩니다.

안전성이 확인될 때까지 일시적으로 정지합니다.

리스크 관리는 합리적이고 올바른 판단이라고 생각합니다.

하지만 이용자의 입장에서는 갑자기 서비스를 이용할 수 없게 되는 것입니다.

기업의 시스템이라면 매출 손실이나 업무 정지를 초래할 수 있습니다.

그렇다면 현대 사회가 IT 시스템에 대한 의존도가 높다는 말씀이시군요.

아사히 그룹에 대한 사이버 공격에 대해 기고했습니다.

그때부터 생각했지만, 시스템이 정지한다는 것은 곧 기업의 활동 자체가 마비될 수 있다는 뜻입니다.

이번에는 사이버 공격으로 인한 피해뿐만 아니라, 취약점에 대한 예방적 조치도 사회 활동에 영향을 미쳤다는 것이 확인되었습니다.

보안 확보를 위한 시스템 정지도 사업 연속성 측면에서 리스크가 될 수 있습니다.

시스템 개발 및 운영을 업무로 삼는 입장에서 매우 중요한 문제라고 생각합니다.

## 이제 본론입니다. SIer로서 느낀 공포

이번 뉴스에서 가장 우려되는 점은 PHP 자체의 보안이 아니라는 것입니다.

앞으로 시스템 개발에서의 기술 선정 책임이 과거보다 더 무거워질 것이 아닐까?

그렇습니다.

IT 업계에서 약 20 년간 근무해 왔습니다.

다양한 시스템 개발을 수행해 왔지만, 업무 요구사항과 비기능 요구사항을 정리한 후 개발 언어와 프레임워크를 선택하는 것은 매우 중요한 작업입니다.

예를 들어, 새로운 업무 시스템을 개발할 때.

원하는 업무 요구사항을 정리하고, 시스템의 구성과 기능을 설계한 뒤, 구현에 적합한 기술을 선정합니다.

물론이지만, 개발 언어를 임의로 선택한 것은 아닙니다.

요건과의 적합성, 실행 성능, 개발 효율, 라이브러리 생태계의 풍성함, 인력 확보, 유지보수성 등 다양한 관점에서 선정합니다.

대규모 데이터 처리를 수행하는 시스템의 경우 파이썬이 후보가 될 수 있습니다.

복잡한 비즈니스 프로세스를 처리하는 대규모 시스템이라면 Java 가 적합할 수 있습니다.

물론, 둘 다 다른 용도로 활용될 수 있으며, 이것만으로는 언어를 결정할 수 없습니다.

가장 중요한 것은 요구되는 기능과 품질을 구현하기 위해 기술 선택에 합리적인 근거를 두고 있다는 점입니다.

그런데 앞으로 어떻게 될까요?

이번 PHP 관련 문제의 여파로 고객 측의 보안 요구가 더욱 강화될 것으로 예상됩니다.

예를 들어, 이런 질문을 받을 수도 있습니다.

왜 그 개발 언어를 선정했는지요?

이것은 지금까지도 흔한 질문입니다.

하지만 앞으로는 그 이후에,

그 언어의 안전성을 증명해 달라

이러한 요구사항이 추가되지 않을까요.

이건 상당히 심각한 이야기라고 생각해요.

어쩌면 악마의 증명 수준에 도달할 가능성도 있는지도 모르겠습니다. 개발 언어의 벤더가 보안 수준 인증을 공개해 주셨으면 좋겠습니다.

## 개발 언어의 취약점이 존재하지 않는다는 것을 증명할 수 있는가

먼저 고려해야 할 것은 개발 언어의 안전성을 증명하는 것입니다.

결론부터 말씀드리면, 알려지지 않은 취약점까지 포함하여 취약점이 존재하지 않음을 증명하는 것은 현실적으로 불가능하다고 생각합니다.

예를 들어, 어느 시점에서 Java 에 중요한 취약점이 공개되지 않았다고 가정해 보겠습니다.

그렇다고 Java 에 취약점이 존재하지 않는다는 뜻은 아닙니다.

그 시점에는 아직 발견되지 않았을 뿐입니다. 이는 미래에 취약점이 발견되지 않음을 증명하는 것이 아니며, 우리와 같은 벤더가 그 사실을 알 수 있는 근거도 없습니다.

이번 PHP2Shell 은 그 명확한 예시라고 생각합니다.

PHP 재단의 발표에 따르면, 이번 문제와 연결된 징후는 2024 년에 실시된 보안 감사 과정에서 파악되었습니다.

그러나 초기에는 구체적인 공격 경로가 명확히 드러나지 않았고, 수정 방법도 쉽게 결정되지 않았습니다.

기존 확장 기능에 미치는 영향, 호환성 문제, 성능 저하 등 여러 문제가 있어 수정 작업이 난항하고 있었습니다.

그 후 2026 년에 여러 보안 전문가들이 보고를 내놓아 심각한 영향이 드러났습니다.

즉, 오랫동안 사용되어 온 PHP 에도 아직 발견되지 않은 심각한 문제가 존재하고 있었습니다.

Java 가든 Python 이든 마찬가지라고 생각합니다.

따라서 향후 기술 선정 시에는 '절대적으로 안전하다'는 설명이 아닌 '알려진 위험을 어떻게 평가하고 관리할 것인가'에 대한 설명이 필요할 것이라고 생각합니다.

예를 들어, 지원이 지속되고 있는지, 수정 프로그램이 제공되는지, 신속한 업데이트가 가능한지, 의존 라이브러리를 파악할 수 있는지.

이러한 관점에서입니다.

그렇지만 고객이 그것을 이해할 수 있을지는 또 다른 문제입니다.

그게 SI 업체로서는 불안한 점입니다.

## 가장 적합한 언어를 선택하더라도 사용할 수 없는 가능성이 있습니다.

구체적인 사례를 몇 가지 살펴봅시다.

어떤 SI 회사가 업무 시스템 개발을 수주했다고 가정해 봅시다.

요건 정의가 완료되고 기본 설계가 진행됨에 따라, 개발을 Python 을 중심으로 진행하기로 결정했습니다.

Python 을 선택한 이유도 명확합니다.

필요한 데이터 처리 라이브러리가 풍부하며, 개발 팀에도 충분한 전문 지식이 있습니다.

성능과 비용 측면에서도 문제가 없습니다.

누군가 봐도 합리적인 기술 선정이었다고 가정해 보겠습니다.

그러나 개발 과정에서 Python 실행 환경에 중대한 취약점이 발견되었습니다.

물론, 기본적으로 수정 버전에 업데이트하는 등의 대책을 검토할 것입니다.

그런데 고객사의 보안부서로부터

중대한 취약점이 발견된 Python 은 이번 시스템에서 사용하지 마십시오.

그렇게 말한다면 어떨까요?

아니, 아니, 잠깐만 기다려달라고 말하고 싶을 텐데요...

그런 취약성이 수정될 수도 있습니다.

애플리케이션 구성상 공격이 성립하지 않을 수 있습니다.

다른 언어로 변경하더라도 다른 보안 리스크가 발생할 수 있습니다.

그런데 언어 그 자체의 사용이 금지되어버렸다면 어떨까.

먼저, 기술 선정 작업을 다시 검토해야 합니다.

다음으로 설계 변경이 필요합니다.

기존 라이브러리가 사용되지 않을 가능성도 있습니다.

또한 새로 도입할 언어에 능통한 인력을 확보해야 합니다.

개발 중인 프로그램이 있다면 재작성될 가능성이 있습니다.

물론, 작업 수량과 납기에도 큰 영향을 미칩니다.

또한, 개발자가 익숙하지 않은 언어를 사용함으로써 개발 품질이 저하될 가능성도 있습니다.

보안 리스크를 회피함으로써 오히려 다른 개발 리스크가 증가할 수 있습니다.

이것이 이번 PHP 문제에서 제가 가장 우려하는 점입니다.

기술 선정은 시스템 품질을 확보하기 위한 것이어야 했는데, 보안을 최우선으로 삼았기 때문에 전체 개발이 더 어려워지는 결과를 초래했습니다.

물론, 실제로 언어 전체를 변경해야 하는 경우는 제한적이라고 생각합니다.

그러나 고객의 보안 정책이 강화되면 이러한 문제가 발생할 가능성은 부정할 수 없습니다.

## 다음으로 표적이 될 언어가 Java 나 Python 이 아닐까

그런데 여기에서도 또 한 가지 궁금한 점이 있습니다.

이번과 같은 심각한 취약점이 PHP 를 제외한 다른 언어에서도 발견될 수 있다는 것입니다.

개인적으로는 주요 개발 언어인 Java, Python, JavaScript에 특히 관심이 많습니다.

물론, 다음에 어떤 언어가 공격받을지 정확하게 예측할 수는 없습니다.

이후부터는 제만의 견해입니다.

### Java 는 어떨까

Java 는 기업의 비즈니스 시스템에서 널리 사용되는 개발 언어입니다.

금융, 제조, 유통 등 다양한 분야에서 활용되고 있습니다.

그리고 Java 세계에서는 과거에도 대규모 보안 문제가 발생했습니다.

대표적인 사례는 2021 년에 발견된 'Log4Shell'입니다.

이 취약점은 조건이 충족되면 외부에서 임의의 코드를 실행할 수 있는 Java 로그 출력 라이브러리인 Log4j 에서 발견된 문제입니다.

Java 언어 자체의 취약점은 아니지만, 매우 광범위한 시스템에 영향을 미쳤습니다.

여기서 중요한 점은 Java 를 채택한 시스템이 Java 로만 동작하지 않는다는 것입니다.

Java 실행 환경인 JVM, 비즈니스 처리를 담당하는 프레임워크, 로그 출력 및 통신 등을 구현하는 라이브러리.

다양한 소프트웨어가 결합되어 하나의 시스템을 구성합니다.

즉, Java 본체 자체에 문제가 없더라도 주변 소프트웨어에 취약점이 존재하면 시스템 전체가 위험에 노출될 수 있습니다.

또한 JVM 자체에도 네이티브 코드가 사용되고 있습니다.

Java 는 메모리 관리 등 보안에配慮를 둔 언어이지만, 실행 환경 내부에서도 취약점이 발생할 수 있다는 점은 변함없습니다.

그리고 매우 궁금한 정보가 있습니다.

오라클은 2026 년 9 월, Java 의 보안 업데이트 주기를 단축하는 방안을 발표했습니다.

기존 분기별 업데이트 방식에 더해 2027 년에는 월별 보안 업데이트를 추가할 계획이라고 합니다.

이 배경에서 설명되는 것은 AI 를 통한 취약점 발견의 가속화입니다.

즉, Java 의 개발자 본인이 향후 취약점 발견 및 수정 속도가 달라질 것으로 예상하고 있다는 것입니다.

SI 업체로서 놓쳐서는 안 될 이야기라고 생각합니다.

### 파이썬은 어떨까

다음은 파이썬입니다.

파이썬은 데이터 분석, 인공지능, 기계 학습, 웹 애플리케이션, 업무 자동화 등 다양한 분야에서 널리 활용되고 있습니다.

AWS 를 다루는 엔지니어들에게도 익숙한 언어일 것입니다.

저 역시 Python 을 자주 활용합니다.

파이썬의 경우 특히 주의해야 할 점은 방대한 외부 라이브러리 의존도입니다.

파이썬에서는 PyPI라는 패키지 배포 플랫폼을 통해 다양한 라이브러리를 활용할 수 있습니다.

예를 들어 API 를 호출하거나 데이터베이스에 연결하거나 데이터를 분석하는 경우입니다.

라이브러리가 풍부해야 적은 코드로 다양한 처리를 구현할 수 있습니다.

이것이 파이썬의 큰 장점입니다.

그러나 보안 관점에서는 주의해야 할 부분이기도 합니다.

라이브러리에 취약점이 존재할 경우 해당 라이브러리를 사용하는 시스템에도 영향을 미칠 수 있기 때문입니다.

또한, 정상적인 패키지가 변조되거나 악의적인 패키지가 배포되는 문제도 있습니다.

이러한 공격은 공급망 공격이라고 불립니다.

또한 일반적으로 사용되는 Python 실행 환경인 CPython 은 주로 C 언어로 구현되어 있습니다.

따라서 Python 이라는 언어의 문법이 안전하다고 하더라도, 실행 환경의 내부 처리에 문제가 발생할 수 있습니다.

PHP2Shell과 같은 문제는 원리적으로 향후 Python 실행 환경에서도 발견될 가능성이 부정할 수 없습니다.

하지만 이는 Python 이 특별히 위험하다는 뜻은 아닙니다.

Java, PHP, 그리고 기타 언어 모두 고유한 위험 요소를 가지고 있습니다.

중요한 것은 어떤 언어든 리스크가 존재한다는 점을 전제로 삼는다는 것입니다.

### 자바스크립트와 Node.js도 무시할 수 없습니다.

Java 와 Python 에 대해 언급했지만, JavaScript 도 관심 있는 존재입니다.

특히 Node.js 를 활용한 서버 사이드 개발입니다.

JavaScript 세계에도 npm이라는 거대한 패키지 관리 시스템이 있습니다.

편의로운 라이브러리가 대량으로 존재하는 반면, 의존 관계가 매우 복잡해질 수 있습니다.

직접 사용하는 라이브러리가 10 개여도, 해당 라이브러리가 다른 라이브러리를 의존하거나 그 이후에도 의존 관계가 존재할 수 있습니다.

결과적으로 개발자가 관리할 수 없는 수준의 소프트웨어를 사용하고 있을 수 있습니다.

그 중 하나에 심각한 취약점이 존재한다면 어떻게 될까요?

사용하지 않는 라이브러리가 시스템에 영향을 줄 수 있습니다.

따라서 향후 보안 문제는 개발 언어 자체를 고려하는 것이 아니라, 해당 언어를 중심으로 구축된 소프트웨어 전체를 고려해야 한다고 생각합니다.

## AI 가 취약점 발견을 가속화하는 시대

이번 PHP 문제에서 또 다른 관심사는 AI 의 존재입니다.

실제로 PHP 재단의 발표에 따르면, 이번 취약성 조사에는 여러 보안 연구자들과 AI 를 활용한 분석이 참여했습니다.

2024 년에 문제의 징후가 감지되었고, 2026 년에는 외부 연구자 및 기업으로부터 추가 보고가 접수되었습니다.

PHP 재단 또한 AI 를 활용한 보안 조사 및 검증 환경 강화에 대해 설명하고 있습니다.

고려해 볼 점들이 있습니다.

과거에는 복잡한 소프트웨어의 취약점을 발견하기 위해 전문 기술과 방대한 시간이 필요했습니다.

소스 코드를 분석하여 의심스러운 처리를 찾아내고, 실제 공격이 성공할지 여부를 확인합니다.

매우 고도의 작업입니다.

그러나 AI 의 분석 능력이 향상되면, 지금까지 발견되지 않았던 문제를 찾아낼 가능성이 높아집니다.

물론, AI 가 지적한 모든 것이 실제로 공격 가능한 취약점이라는 것은 아닙니다.

오류 감지 또한 존재하며, 인간에 의한 검증도 필요합니다.

그러나 기존에 비해 더 넓은 범위의 코드를 조사할 수 있게 될 가능성이 있습니다.

이것은 방어 측에게 큰 이점이 됩니다.

공격되기 전에 취약점을 발견하고 수정할 수 있기 때문입니다.

반면, 공격자도 유사한 기술을 활용할 가능성이 있습니다.

그렇다면 지금까지 10 년, 20 년 동안 간과되어 온 취약점이 차례로 드러나는 시대가 될지도 모릅니다.

저는 이 부분이 향후 시스템 개발에 있어 중요한 전환점이 될 것 같습니다.

과거에는 안정적으로 운영 중인 시스템에 대해 '큰 문제가 없다면 큰 변화를 원하지 않는다'는 생각도 있었습니다.

그러나 앞으로는 변경하지 않는 것 자체가 리스크로 변할 수 있습니다.

보안 대책을 위해 시스템을 지속적으로 업데이트해야 합니다.

그런 시대가 되지 않았을까요.

## 보안을 중시하면 개발 품질이 저하될까?

여기서 우리는 모순처럼 들릴 수 있는 이야기를 하나 이야기해 보겠습니다.

보통 보안 대책을 강화하는 것은 좋은 일입니다.

그것은 당연하다고 생각합니다.

다만, 보안 대책을 강화하는 것과 시스템 전체의 품질 향상이 반드시 동일하지는 않습니다.

예를 들어, 어떤 시스템에서 자바를 도입할 계획이라고 가정해 보겠습니다.

Java 를 선택한 이유는 개발 팀에 풍부한 경험이 있으며, 기존 라이브러리 및 개발 자산도 활용 가능하기 때문입니다.

그러나 보안 부서에서 자바 사용이 금지되어 다른 언어로 개발하기로 결정되었습니다.

새로 도입된 언어는 보안 측면에서 확실한 장점을 가지고 있을 수 있습니다.

하지만 개발 팀에 경험이 없다면 어떻게 될까요?

개발 효율이 떨어집니다.

설계상의 문제를 놓칠 수도 있습니다.

부적절한 코딩으로 인해 다른 취약점이 발생할 수 있습니다.

테스트 작업량이 늘어나 납기가 지연될 수 있습니다.

즉, 하나의 리스크를 낮추는 결과로 다른 리스크가 증가할 수 있다는 것입니다.

저는 기술 선정이 가장 어려운 부분이 바로 여기라고 생각합니다.

시스템 개발에서는 보안뿐만 아니라 성능, 가용성, 유지보수성, 개발 효율성 및 비용 등 다양한 품질 특성을 고려해야 합니다.

보안성이 중요하다고 해서 다른 요구사항을 간과해서는 안 됩니다.

개인적으로는 앞으로의 기술 선정은 과거보다 더 종합적인 판단이 필요할 것으로 생각합니다.

중요한 것은 '취약성이 적은 언어를 선택하는 것'이 아니라 '그 기술을 안전하게 계속 사용할 수 있는가'에 있다고 생각합니다.

## 향후 시스템 개발은 어떻게 변화해 나갈 것인가

그럼 이제부터 향후 개발 방향에 대해 논의해 보겠습니다.

아쿠아 M 에서는 예상하지만, 앞으로의 시스템 개발은 '완성'을 중심으로 한 개발에서 '안전한 상태를 유지하는 것'까지 포함하는 개발로 더욱 변화할 것이라고 생각합니다.

사실, 이 관념 자체는 새로운 것이 아닙니다.

보안 개발이나 DevSecOps 같은 개념은 이미 오래전부터 존재해 왔습니다.

다만, 이번 PHP 문제를 계기로 앞으로 현장에서의 실제 적용이 더욱 요구될 수 있다고 생각합니다.

### 보안 요구사항을 명확히 정의하기

먼저 요구사항 정의입니다.

과거에도 보안 요구사항은 정의되어 왔습니다.

예를 들어 인증 방식, 접근 제어, 통신 암호화, 로그 보관, 불법 접근 방지 대책 등이 있습니다.

앞으로는 이들에 더해 소프트웨어의 지속적인 업데이트 요구사항도 명확히 해야 한다고 생각합니다.

예를 들어, 중대한 취약점이 발견될 경우 영향 조사를 어느 기간 동안 수행할지.

수정 프로그램이 제공될 경우, 누가 적용 여부를 결정할 것인가.

시스템 정지를 수반하는 업데이트 작업을 허용하는 조건은 무엇인가.

그리고 보안 리스크를 완전히 제거할 수 없는 경우, 잔존 리스크를 누가 수용해야 하는가.

이 정도까지 처음부터 정리해 두는 것이 아닌지 고려해 보지 않겠습니까.

전통적인 개발 방식에서는 운영 시작 후의 취약점 대응을 유지보수 계약 범위 내로 고려하기도 합니다.

그러나 시스템 사용 기간이 길어질수록 보안 대응에 필요한 작업량도 달라집니다.

따라서 개발 단계부터 운영 시작 후의 보안 대책을 고려하여 대비해야 한다고 생각합니다.

### 기본 설계에서는 기술 선정의 근거를 명확히 합니다.

다음은 기본 설계입니다.

이 부분은 이번 글에서 저에게 특히 중요한 내용입니다.

개발 언어 및 프레임워크 선정에 있어서는 과거보다 더 명확한 근거가 요구될 것으로 보입니다.

물론, 사용할 기술은 기본 설계가 완료된 후에 검토하는 것이 아니라, 요구사항 정의부터 기본 설계 초기 단계에서 방향성을 미리 정해 두어야 합니다.

기술에 따라 시스템 구성과 설계 방식이 달라지기 때문입니다.

또한 선정 시에는 보안 리스크 평가도 실시합니다.

예를 들어, 선정된 언어의 지원 기간, 사용 중인 프레임워크의 업데이트 현황, 라이브러리의 유지보수 체계, 중대한 취약점이 발생했을 때의 대안 등.

이를 기술 선정의 판단 기준으로 포함합니다.

저는 기술 선정 결과뿐만 아니라 선정 근거를 기록하는 것이 중요하다고 생각합니다.

왜 그 언어를 선택했는지.

그밖에 어떤 후보들이 있었는지.

각각의 장단점은 무엇인가.

어떤 리스크가 존재하며 이를 어떻게 관리할 것인가.

이러한 정보가 남아있다면, 향후 문제가 발생했을 때 당시의 판단 근거를 설명할 수 있습니다.

그리고 향후 기술 변경이 필요해진 경우에도 재선정된 소재로 활용 가능합니다.

### 개발 프로세스에서는 취약점을 지속적으로 탐지합니다.

다음은 개발 단계입니다.

이곳에서는 보안 대책을 최종 테스트 단계에만 맡기지 않는 것이 중요합니다.

예를 들어, 소스 코드를 실행하지 않고도 문제를 감지하는 정적 분석인 SAST 를 사용하면 됩니다.

또한, 소프트웨어 구성 분석 (SCA) 이라는 기법은 사용 중인 외부 라이브러리 등의 구성과 알려진 취약점을 조사합니다.

CI/CD 프로세스에 통합하면 프로그램 변경이나 라이브러리 업데이트에 맞춰 자동으로 검증할 수도 있습니다.

그러나 이러한 시스템을 도입한다고 해서 모든 취약점을 감지할 수 있는 것은 아닙니다.

PHP2Shell 와 같이 실행 환경 자체에 알려지지 않은 문제가 존재할 수도 있습니다.

또한, 도구에서 대량의 경고가 발생하더라도 이를 분석하고 적절히 대응하지 않으면 의미가 없습니다.

즉, 도구의 도입뿐만 아니라 그 결과를 평가하고 대응할 수 있는 기술자와 프로세스도 필요합니다.

보안 점검 자체가 목적이 되지 않도록 주의해야 합니다.

### 릴리스 이후에도 지속적인 업데이트가 필요합니다.

그리고, 운용 및 유지보수입니다.

개인적으로는 앞으로 가장 변해야 할 부분이 이 부분이라고 생각합니다.

전통적인 비즈니스 시스템에서는 프로덕션 릴리스 이후 큰 기능 변경이 없다면 가능한 한 시스템에 개입하지 않는 운영 방식도 흔합니다.

안정 가동을 최우선으로 한다는 관점이라면 이해할 수 있습니다.

그러나 보안 관점에서는 그것이 리스크가 될 수 있습니다.

OS, 미들웨어, 실행 환경, 라이브러리 등은 지속적으로 업데이트됩니다.

또한, 오래된 버전의 경우 보안 지원이 종료될 수 있습니다.

이번 PHP 문제에서도 지원이 종료된 버전을 계속 사용하는 시스템에 대한 대응이 주요 과제로 대두되고 있습니다.

따라서 향후에는 개발 완료 후에도 정기적으로 소프트웨어 구성을 점검하고 필요한 업데이트를 적용하는 운영 관리가 중요해질 것입니다.

물론, 업데이트에는 위험 요소가 있습니다.

상호 호환성 문제로 인해 애플리케이션이 작동하지 않을 수 있습니다.

그렇기에 평소부터 자동 테스트나 검증 환경을 미리 구축해 두어야 합니다.

업데이트하고 싶어도 업데이트가 안 되는 상태를 만들지 않는 것이 중요하다고 생각합니다.

## 워터폴 개발 방식과의 호환성에 대한 우려가 있습니다.

지금까지 쓴 내용 중 SIer(시스템 통합 엔지니어)에게는 특히 어려울 것 같은 부분이 있습니다.

그것이 워터폴 개발 방식과 맞지 않는 점입니다.

워터폴 개발 방식은 일반적으로 요구사항 정의, 기본 설계, 상세 설계, 제조, 테스트 등의 단계를 순차적으로 진행합니다.

각 공정별 산출물을 승인하여 다음 공정으로 진행하는 방식입니다.

물론 실제 프로젝트에서는 공정 간 재작업과 병행 작업이 발생할 수 있습니다.

다만, 기본적으로는 이전 단계에서 결정된 내용을 바탕으로 다음 단계를 진행하게 됩니다.

여기에 문제가 있습니다.

기본 설계를 완료하고 개발 언어도 확정되었습니다.

개발 인력과 일정도 확정되었습니다.

개발 팀원도 할당되었습니다.

그러나 제조 공정 중 사용 중인 언어에 심각한 취약점이 발견되었습니다.

또한, 고객이 기술 변경을 요구했다고 가정해 봅시다.

어떤 결과가 나올까요?

기본 설계부터 다시 시작해야 할 수도 있습니다.

물론, 상세 설계에도 영향을 미칩니다.

이미 개발된 프로그램에도 영향을 미칩니다.

테스트 계획도 재검토가 필요합니다.

생각만 해도 끔찍한군요...

하나의 변경 사항만으로도 후속 공정에서 큰 영향을 받을 수 있습니다.

과거에도 요구사항 변경으로 인한 작업 재시작이 있었습니다. 개발 중 설계 변경으로 인한 작업 재시작도 있었습니다.

그러나 앞으로 외부에서 발견된 취약점이 프로젝트의 전제 조건을 갑자기 변경할 수 있습니다.

그리고 그 문제는 SI 가 만든 버그에 국한되지 않을 수도 있습니다.

개발 언어나 외부 라이브러리에 내장되어 있던 알려지지 않은 취약점일 수도 있습니다.

그렇다면 워터폴 개발 방식은 더 이상 사용할 수 없게 될까요?

저는 그렇게 생각하지 않습니다.

대규모 업무 시스템에서는 요구사항과 설계를 단계적으로 확정하는 데 이점이 있습니다.

그러나 기존 프로젝트 관리 체계에 더해, 기술 리스크를 지속적으로 재평가하는 메커니즘이 필요하다고 생각합니다.

예를 들어, 기본 설계 단계부터 기술 선정 평가를 실시하고, 이후에도 중대한 취약점이 공개될 때마다 재평가합니다.

필요한 경우 변경 관리 프로세스를 통해 영향을 분석합니다.

이러한 구조가 표준적으로 도입되지 않을까요.

설계를 확정하는 것과 기술 리스크 평가를 종료하는 것은 별개의 문제입니다.

이 부분이 향후 중요한 포인트가 될 것 같습니다.

## 보안 대응 비용의 부담 주체는 누구인가

또 하나, SI 업체로서 궁금한 점이 있습니다.

그건 돈 문제입니다.

시스템 개발에서는 계약 단계에서 작업 범위, 비용, 납기 등을 명확히 정합니다.

그러나 계약 후 개발 언어나 프레임워크의 중대한 취약점이 발견될 경우, 대응 비용은 누가 부담해야 할까요?

예를 들어, 수정 프로그램 적용만으로 해결되는 경우입니다.

이는 기존 작업 범위나 유지보수 계약 내에서 해결 가능한 사항일 수 있습니다.

그렇다면 라이브러리의 대규모 업데이트가 필요한 경우 어떻게 해야 할까요?

프로그램 수정이 필요한 경우?

또한, 고객 보안 정책으로 개발 언어 변경을 요구받는 경우?

이 정도까지 오면 이야기가 간단하지 않습니다.

초기 계약에는 포함되지 않았던 작업들이 대량으로 발생할 수 있기 때문입니다.

물론, SI 측의 설계 판단이나 주의 의무에 문제가 있는 경우 상당한 책임을 질 수도 있습니다.

그런데 계약 당시에는 알려지지 않았던 취약점이 나중에 발견되는 경우까지 모두 SIer 의 책임으로 간주된다면 어떨까요?

아마도 상당히 무거운 말씀이실 것 같습니다.

경제산업부는 2024 년 SBOM 도입 관련 가이드라인 개정판을 공개했습니다.

SBOM 은 소프트웨어 구성 요소 목록을 의미하는 소프트웨어 빌 오브 재료의 약어로, 간단히 말해 소프트웨어를 이루는 부품들의 목록을 뜻합니다.

예를 들어, 어떤 라이브러리를 어떤 버전으로 사용하고 있는지와 같은 정보를 관리합니다.

이 가이드는 취약점 관리뿐만 아니라 거래처와의 계약에서 요구사항, 책임, 비용 부담 등도 정리하고 있습니다.

즉, 기술적 대응뿐만 아니라 계약상의 정리도 중요하다는 것입니다.

개인적으로는 향후 시스템 개발에서 계약 단계 이전에 알려지지 않은 취약점이 발견될 경우의 대응 원칙을 명확히 규정해 두어야 한다고 생각합니다.

그렇지 않으면 SI 업체와 고객 모두 예상치 못한 문제에 휘말리게 될 것입니다.

## 그렇다면 언어를 바꾸는 것이 옳은 일인가

지금까지 이렇게 써왔지만, 한 가지 강조하고 싶은 점이 있습니다.

그 개발 언어를 사용해야 할 이유가 발견된 심각한 취약성이라는 사실만으로 결정되는 것은 아닙니다.

예를 들어, 이번과 같은 취약점이 PHP 에서 발견되어도 패치 버전에 업데이트함으로써 해결될 수 있는 경우가 있습니다.

JAVA 와 Python 도 마찬가지입니다.

약점이 발견되면 먼저 영향 범위를 조사합니다.

수정판의 유무를 확인합니다.

그리고 수정판 적용과 필요한 완화 방안을 검토한다.

이것이 기본적인 사고방식이라고 생각합니다.

물론, 수정할 수 없는 취약점이 남아 있거나 지원이 종료된 경우 등에는 기술 변경이 필요할 수 있습니다.

그러나 처음부터 언어 변경을 전제로 해야 할 필요는 없었을 것입니다.

오히려 지나치게 쉽게 변경함으로써 새로운 문제를 야기하는 것이 더 위험하다고 생각합니다.

예를 들어, 오랫동안 Java 로 운영해 온 시스템을 보안상의 이유로 다른 언어로 전면 전환했다고 가정해 보겠습니다.

새로운 언어가 더 안전하다고 생각했는데도, 마이그레이션 후 구현한 애플리케이션에서 부적절한 인증 처리가 이루어진다면 어떻게 될까요?

결국, 다른 취약점을 만들어버릴 수 있습니다.

또한 개발 언어를 변경하더라도 운영체제나 미들웨어, 통신 라이브러리 등의 취약점이 사라지는 것은 아닙니다.

즉, 언어만 변경한다고 보안 문제가 해결되는 것은 아닙니다.

따라서 기술 선정 시 알려진 취약점의 수만으로优劣를 판단하는 것이 아니라, 지속적으로 안전성을 확보할 수 있는지를 중점적으로 고려하고 싶습니다.

## 앞으로 SI 업체에서 요구되는 역량은 달라질 것으로 생각합니다.

이번 PHP 문제를 통해 향후 시스템 통합 업체가 요구하는 역량이 어떻게 변해갈지 느끼게 되었습니다.

과거에는 고객의 요구사항을 정리하고 적합한 시스템을 설계하며 품질을 확보하여 납품하는 것이 중요했습니다.

물론, 앞으로도 변함없습니다.

하지만 그것만으로는 부족할 수 있습니다.

이후에는 기술 선택뿐만 아니라, 선택한 기술을 어떻게 유지해 나갈지도 고려해야 합니다.

저는 다음과 같은 능력이 점점 더 중요해질 것이라고 생각합니다.

- 기술 리스크 평가에 필요한 역량 언어와 라이브러리의 특징, 취약점, 지원 상태를 이해하고, 이를 바탕으로 채택 여부를 합리적으로 판단할 수 있어야 한다.
- 기술 변경의 영향 분석 능력을 가진 취약점이 발견될 경우, 해당 시스템 및 기능이 어떤 영향을 받을지 파악할 수 있습니다.
- 연속적으로 업데이트할 수 있는 시스템을 설계할 수 있는 실행 환경과 라이브러리를 업데이트하더라도, 품질을 검증하며 안전하게 릴리스할 수 있습니다.
- 고객에게 리스크를 설명할 수 있는 역량을 갖추어야 하며, 기술적 문제는 비용, 납기, 업무 영향 등의 관점에서 설명할 수 있어야 합니다.
- 보안과 개발 품질을 동시에 확보할 수 있는 역량. 보안뿐만 아니라 성능, 유지보수성, 개발 효율성 등을 종합적으로 고려하여 최적의 구성을 판단할 수 있어야 함.

과거에도 중요했던 능력이지만, 앞으로는 그 필요성이 더욱 높아질 것이 아닐까요.

특히 네 번째 항목입니다.

기술적으로 올바른 판단을 할 뿐만 아니라, 그 판단이 왜 합리적인지 고객에게 설명할 수 있는 능력입니다.

이곳은 SI 업체에게 매우 중요해질 것으로 보입니다.

보안을 강화하기 위해 개발 기간이나 비용이 증가할 수 있습니다.

반대로 과도한 보안 요구는 시스템 전체의 리스크를 키울 수도 있습니다.

이러한 균형을 설명할 수 있는 전문가들은 앞으로 더욱 필요하지 않을까요.

## 개발에 대한 생각은 이미 변하기 시작하는 것 같습니다.

사실, 이러한 생각은 저의 오직 자신의 추측에 불과하지 않습니다.

미국 NIST 는 안전한 소프트웨어 개발을 위한 프레임워크인 SSDF(보안 소프트웨어 개발 프레임워크) 을 공개했습니다.

SSDF 은 개발 단계의 보안 조치뿐만 아니라, 출시 후 발견된 취약점에 대한 대응도 중요한 활동으로 정의하고 있습니다.

또한 일본에서도 2026 년 3 월 31 일, 경제산업성과와 내각관방 국가사이버통괄실이「사이버인프라사업자에게 요구되는 역할 등에 관한 가이드라인」을 발표했습니다.

소프트웨어 개발, 공급 및 운영을 담당하는 사업자와 그 고객들이 각각 수행해야 할 역할을 정리한 것입니다.

이것들은 모든 SI 업체에 동일한 개발 방식을 의무화하는 것이 아닙니다.

그러나 보안 문제는 시스템 개발사만의 책임도, 고객만의 책임도 아니라는 점을 강조하고 있습니다.

개인적으로는 이 부분이 가장 중요하다고 생각합니다.

시스템 개발 과정에서의 보안 리스크는 개발자 혼자서는 완전히 제거할 수 없습니다.

그렇기에 SI 업체와 고객은 위험을 공유하고, 어떤 수준의 대응을 취할 것이며 무엇을 허용할지에 대해 합의해야 합니다.

향후 시스템 개발에서는 이러한 사고방식이 더욱 중요해질 것으로 생각합니다.

다른 관점에서 보아도 보안 대책은 개발 벤더가 전담해야 한다고 생각할 수 있지만, 비용과 보안은 일반적으로 트레이드오프 관계에 있습니다.

보안 대응 비용에 자금을 투입할수록 보안 대책을 충분히 구현할 수 있으나, 그만큼 고객이 부담해야 할 개발 비용이 급증합니다. 따라서 어떤 리스크를 회피하고 어떤 리스크를 수용할지 결정하는 것은 고객과 조율해야 합니다.

## 나 스스로 생각하는, 앞으로의 시스템 개발의 모습

지금까지 다양한 내용을 살펴보았으니, 이제 구체적으로 어떤 개발 방식으로 변화할 것인지 살펴봅시다.

제대로 예상해 본다면 워터폴 개발 방식이 사라지는 것도 아니며, 모든 프로젝트가 애지럴 개발로 전환되는 것도 아니라고 생각합니다.

오히려 기존 개발 프로세스에 지속적인 보안 평가와 기술 변화 대응을 통합하는 방향으로 나아가는 것이 아닐까 생각합니다.

요구사항 정의 및 기본 설계 단계에서 보안 요구사항과 기술 선정 근거를 명확히 해야 합니다.

개발 프로세스에서는 소스 코드와 의존 라이브러리의 취약점을 지속적으로 점검합니다.

배포 시에는 알려진 취약점과 잔존 리스크를 평가합니다.

또한 운영 시작 후에도 기술 리스크를 지속적으로 모니터링하고 필요한 업데이트를 수행합니다.

이러한 흐름입니다.

물론, 이러한 사례는 이미 현장에서 적용된 사례도 있습니다.

특히 클라우드 기반 시스템이나 CI/CD 가 구축된 개발 환경에서는 비교적 도입하기 쉬운 접근 방식이라고 생각합니다.

반면, 오랫동안 사용되어 온 업무 시스템에서는 해결이 어려운 부분도 있습니다.

예를 들어, 동작 확인을 자동화할 수 없는 시스템.

개발 당시 담당자가 없던 시스템.

사용 중인 라이브러리를 파악할 수 없는 시스템.

이러한 시스템에서는 수정 프로그램을 적용하는 것만으로도 상당한 작업량이 소요될 수 있습니다.

따라서 앞으로 새로 개발되는 시스템에서는 향후 업데이트를 고려한 설계가 중요해질 것입니다.

앞으로 저는 안전 시스템을 구축하는 기술과 안전 상태를 유지하는 시스템을 구축하는 기술이 동등하게 중요해질 것이라고 생각합니다.

한 번 개발하여 끝내는 것이 아니라, 지속적으로 개선해 나가는 것입니다.

그것이 앞으로의 시스템 품질의 하나가 되지 않겠습니까.

## SIer 의 업무는 앞으로 점점 더 어려워질 수도 있습니다.

이러한 점을 종합해 보면 솔직히 말하자면 SI 업계의 업무는 앞으로 더욱 어려워질 것 같습니다.

개발 언어 선정만 해도 고려해야 할 사항이 늘어납니다.

보안성 평가도 필요합니다.

사용 중인 라이브러리 관리도 필요합니다.

개발 후에도 업데이트 계획이 필요합니다.

알려지지 않은 취약점이 발견될 경우의 대응 방안도 마련해야 합니다.

그리고 이를 고객에게 설명해야 합니다. 설명만으로는 부족하며, 고객이 실제로 이해해야 합니다. IT 에 능통한 사람은 좋지만, 그렇지 않은 사람들도 많습니다. 그런 분들에게도 이해를 시켜야 합니다.

그 어느 때보다 어려운 시대가 찾아오고 있군요...

하지만 비관적인 내용만 있는 것은 아닙니다.

관점을 바꾸면, 그동안 충분히 중요시되지 않았던 기술 선정이나 운영 설계의 가치가 재평가받을 수 있는 가능성도 있습니다.

예를 들어, 업데이트가 용이한 시스템을 설계할 수 있는 기술자.

취약성의 영향 범위를 신속하게 파악할 수 있는 전문가.

보안과 비용을 균형 있게 고려할 수 있는 기술자.

또한, 기술적 리스크를 고객에게 명확하게 설명할 수 있는 기술자.

이러한 전문가의 가치는 앞으로 더욱 높아지지 않겠습니까.

저는 클라우드 중심의 인프라 설계 및 구축에 참여하고 있습니다.

AWS 와 같은 클라우드 서비스에서는 인프라인 코드로 관리하거나 환경을 자동으로 구축할 수 있습니다.

이러한 구조는 시스템 업데이트를 용이하게 한다는 관점에서도 유용할 것 같습니다.

물론 클라우드를 활용한다고 해서 모든 취약점이 해결되는 것은 아닙니다.

클라우드 서비스 제공자가 관리하는 부분과 사용자가 관리하는 부분을 명확히 이해해야 합니다.

다만, 향후 보안 대책을 수립할 때 자동화 및 구성 관리의 중요성은 더욱 높아질 것으로 생각합니다.

## 결론

이번에는 PHP 의 중대한 취약점인 'PHP2Shell' 을 계기로 향후 시스템 개발 방향을 고려했습니다.

PHP 는 20 년 이상前から 보안상의 문제가 지적되어 왔으며, 이에 따라 지속적으로 개선되어 온 언어입니다.

그럼에도 불구하고 2026 년에 중대한 취약점이 발견되었습니다.

그 영향으로 인해 행정 기관 등이 일부 웹 서비스를 정지하는 사태까지 발생했습니다.

저는 이 문제가 PHP 로만 해결될 것이라고 생각하지 않습니다.

Java, Python, JavaScript 등 다양한 언어와 실행 환경에도 아직 발견되지 않은 문제가 존재할 수 있습니다.

AI 를 활용한 보안 분석이 발전하면, 이러한 문제가 과거보다 더 빠르게 발견될 수 있습니다.

그런 상황이 발생했을 때, 시스템 개발 현장에는 어떤 일이 일어날까요?

기술 선정의 근거에 대한 요구가 과거보다 더욱 엄격해질 수 있습니다.

개발 과정에서 기술 변경이 필요할 수 있습니다.

보안 대응을 위해 인력 투입이나 비용이 증가할 수 있습니다.

그리고 출시 후에도 시스템을 지속적으로 업데이트하는 것이 당연한 일이 되어갈 것이 아닐까요.

하지만 잊지 말아야 할 일, 단 하나뿐이라고 생각합니다.

보안 확보는 시스템을 안전하게 활용하기 위한 수단일 뿐, 그 자체가 최종 목표는 아닙니다.

보안성이 아무리 강화되어도 필요한 업무를 실현할 수 없다면 그 의미는 없습니다.

반대로, 업무 요구사항을 완벽하게 충족하더라도 심각한 취약점이 남아있다면 안심하고 사용할 수 없습니다.

따라서 보안, 기능, 성능, 개발 효율성, 유지보수성, 비용 등을 종합적으로 고려해야 한다고 생각합니다.

이번 PHP 문제를 접하자마자, 앞으로의 SI 업계가 큰 어려움을 겪을 것 같아 생각했습니다.

지금까지도 그 생각은 변함이 없습니다.

다만, 향후 변화에 대응하기 위해 무엇이 필요한지 조금은 눈앞에 보였다는 느낌도 드네요.

개발 언어의 안전성을 증명하는 것보다, 위험을 이해하고 적절히 관리하는 것이 더 중요합니다.

발견되지 않는 것을 기대하는 것보다, 발견되었을 때 신속하게 대응할 수 있는 것.

그리고 기술적 판단을 SI 업체가 단독으로 부담하지 않고, 고객과 함께 고민해 나가는 것.

이러한 관점은 향후 시스템 개발에서 중요해질 것으로 생각합니다.

IT 업계에서 약 20 년간 활동해 왔지만, 기술의 발전에 따라 요구되는 역량은 크게 변해 왔습니다.

앞으로도 변화는 계속될 것입니다.

그런 변화에 대한 불안감을 느끼면서도, 기술자로서 이를 제대로 대응할 수 있도록 노력하겠습니다.

이번 PHP 문제는 저에게 그런 생각을 하게 된 계기가 되었습니다.

끝까지 읽어주셔서 감사합니다!

## 참고 자료

본 기사는 다음 공식 정보 등을 참고하여 작성되었습니다.

- PHP 공식: 2026 년 10 월 보안 릴리스
- PHP 취약점 대응 방안 (PHP2Shell)
- PHP Foundation: 이번 취약점과 보안 체계 개선
- PHP 공식: 2002 년 PHP 4.2.2 보안 권장 사항
- 오라클: Java 보안 업데이트 주기의 변경에 대해
- NIST: 안전한 소프트웨어 개발 프레임워크 (SSDF)
- 경제산업부: SBOM 도입에 관한 가이드라인 Ver.2.0
- 경제산업부: 사이버 인프라 사업자용 가이드라인

#PHP #PHP2Shel #취약점 #사이버보안 #Java #Python #시스템개발 #SIer #시스템엔지니어 #DevSecOps

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

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

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