AI 시대, 이제 CMS의 승부는 보안에서 갈린다
AI가 CMS 개발의 문턱을 낮추고 있다. 그렇다면 앞으로 무엇이 CMS의 경쟁력이 될 것인가
소프트웨어 개발의 환경이 빠르게 변하고 있습니다. 과거에는 하나의 CMS를 개발하기 위해 상당한 시간과 경험이 필요했습니다. 데이터베이스를 설계하고 회원가입과 로그인 기능을 만들고 게시판과 댓글, 파일 업로드, 관리자 페이지, 권한관리, 검색, 통계, API 등을 하나씩 구현해야 했으며, 개발자가 직접 코드를 작성하고 오류를 찾아 수정하면서 오랜 시간 동안 시스템을 다듬어야 했습니다. CMS 하나를 만든다는 것은 단순히 게시판 하나를 만드는 것과는 전혀 다른 문제였고, 특히 실제 서비스에 적용할 수 있는 수준의 안정성과 확장성을 확보하기 위해서는 상당한 개발 경험이 필요했습니다. 그러나 생성형 AI가 등장하면서 소프트웨어 개발의 환경이 빠르게 달라지고 있습니다. AI는 코드를 작성하고 기존 소스의 구조를 분석하며 오류를 찾아내고 테스트 방법을 제안하고 문서까지 작성할 수 있습니다. 물론 AI가 시니어 개발자를 완전히 대신한다는 의미는 아닙니다. 오히려 복잡한 시스템에서는 설계와 판단, 검증과 운영 경험을 가진 개발자의 역할이 더욱 중요할 수 있습니다. 다만 분명한 변화는 있습니다. 과거에 많은 시간과 인력이 필요했던 구현 작업의 상당 부분을 AI가 보조할 수 있게 되었다는 것입니다. 그렇다면 앞으로 CMS 시장의 경쟁력은 어디에서 발생하게 될까요. 저는 이제 그 경쟁의 중심이 단순한 기능 구현에서 점차 보안과 유지보수, 그리고 지속적인 대응 능력으로 이동할 가능성이 높다고 생각합니다. 누가 더 많은 기능을 만들었는가도 중요하지만, 실제 서비스를 운영하는 입장에서 더욱 중요한 질문은 따로 있습니다. 이 CMS를 얼마나 안전하게 운영할 수 있는가, 그리고 새로운 취약점이 발견되었을 때 얼마나 빠르게 대응할 수 있는가라는 질문입니다.
1장. AI는 CMS 개발의 풍경을 바꾸고 있다
코드를 만드는 것보다 무엇을 만들어야 하는지가 중요해지는 시대
AI가 등장했다고 해서 CMS 개발 자체가 쉬운 일이 되었다고 말할 수는 없습니다. CMS는 단순한 게시판 프로그램이 아니며 사용자 인증과 권한관리, 데이터베이스, 파일 업로드, 관리자 기능, 검색, API, 세션, 보안정책, 서버환경 등 수많은 요소가 서로 연결되어 있습니다. 개발환경에서는 정상적으로 작동하던 코드가 실제 운영환경에서는 예상하지 못한 문제를 일으킬 수도 있고, 사용자가 입력하는 데이터 역시 개발자가 예상했던 형태와 다를 수 있습니다. 여기에 외부 라이브러리의 취약점이나 서버환경의 변화, 새로운 공격기법까지 더해지면 CMS는 출시하는 순간부터 새로운 문제에 대응해야 하는 살아 있는 시스템이 됩니다. AI는 이러한 개발과정을 상당 부분 빠르게 만들어 줄 수 있지만, AI가 작성한 코드가 자동으로 안전해지는 것은 아닙니다. 오히려 개발 속도가 빨라질수록 그 결과물을 검증하고 위험을 찾아내는 과정은 더욱 중요해질 수 있습니다. NIST의 Secure Software Development Framework 역시 보안을 개발 마지막 단계에서 추가하는 작업으로 보지 않고 소프트웨어 개발 생명주기 전체에 통합해야 할 영역으로 보고 있으며, 취약점이 발견된 이후 이를 분석하고 대응하는 과정 역시 안전한 소프트웨어 개발의 중요한 부분으로 다루고 있습니다. 결국 AI 시대의 개발자는 단순히 코드를 작성하는 사람에서 한 단계 더 나아가 AI가 만들어낸 결과를 이해하고 구조적으로 검증하며 시스템 전체의 위험을 판단할 수 있는 사람이 되어야 합니다. 그리고 이러한 변화는 CMS 개발에서 더욱 중요합니다. 게시판을 만드는 것은 AI가 도와줄 수 있지만, 그 게시판이 실제 서비스에서 어떤 공격에 노출될 수 있는지를 판단하는 것은 전혀 다른 문제이기 때문입니다.
2장. CMS의 기능은 점점 평준화될 수 있다
게시판을 만드는 능력만으로는 차별화하기 어려운 시대
과거에는 게시판 하나를 만드는 것조차 상당한 개발 작업이었습니다. 회원가입과 로그인을 구현하고 게시물을 저장하며 댓글과 첨부파일을 처리하고 관리자 페이지를 구성하는 데 상당한 시간이 필요했습니다. 그러나 AI를 이용할 수 있는 현재의 개발환경에서는 기본적인 CRUD 기능이나 관리자 화면, API의 기본 구조 등을 이전보다 빠르게 구현할 수 있습니다. 물론 이것이 곧 상용 CMS 수준의 품질을 쉽게 만들 수 있다는 뜻은 아닙니다. 실제 서비스에서는 예외처리와 권한관리, 데이터 무결성, 성능, 보안, 유지보수성 등 훨씬 복잡한 문제가 존재하기 때문입니다. 하지만 분명한 것은 기본적인 기능을 구현하는 데 필요한 진입장벽이 과거보다 낮아지고 있다는 점입니다. 그렇다면 앞으로 CMS의 차별화는 어디에서 발생할까요. 게시판이 있다는 것만으로는 부족하고 회원관리가 된다는 것만으로도 부족하며 플러그인을 사용할 수 있다는 것만으로도 충분하지 않을 수 있습니다. 결국 사용자는 실제 서비스를 운영하면서 더욱 중요한 질문을 하게 됩니다. 기능이 얼마나 많은가보다 안전한가, 문제가 발생했을 때 대응할 수 있는가, 새로운 취약점이 발견되었을 때 신속하게 패치할 수 있는가, 기존 시스템을 무너뜨리지 않고 지속적으로 업데이트할 수 있는가라는 질문입니다. 저는 AI 시대의 CMS 경쟁이 바로 이 지점에서 새로운 국면을 맞이할 가능성이 있다고 생각합니다.
3장. OWASP가 보여주는 웹 보안의 현실
보안은 SQL Injection 하나로 끝나지 않는다
웹 보안을 이야기할 때 많은 사람들이 SQL Injection이나 XSS를 먼저 떠올립니다. 물론 이러한 취약점은 여전히 매우 중요합니다. 그러나 최신 OWASP Top 10:2025를 살펴보면 현대 웹 애플리케이션의 보안 문제는 훨씬 넓은 영역으로 확장되어 있습니다. OWASP Top 10:2025에는 Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging & Alerting Failures, Mishandling of Exceptional Conditions 등이 포함되어 있습니다. 특히 Security Misconfiguration은 2021년 5위에서 2025년 2위로 올라갔으며 OWASP는 테스트된 애플리케이션에서 어떤 형태로든 설정 오류가 발견되었다고 설명하고 있습니다. 이것은 매우 중요한 사실입니다. 보안은 특정 코드 한 줄을 수정하는 것으로 끝나는 문제가 아니기 때문입니다. 서버 설정도 보안이고 권한 설정도 보안이며 인증과 세션도 보안이고 파일 업로드와 API도 보안입니다. 외부 라이브러리와 플러그인도 보안의 영역이며 로그 역시 보안과 연결됩니다. 결국 현대 CMS에서 보안은 하나의 기능이 아니라 시스템 전체를 둘러싸고 있는 하나의 구조가 되어야 합니다.
4장. DXCMS가 보안을 바라보는 방식
보안을 하나의 거대한 기능으로 만들지 않는다
제가 DXCMS를 개발하면서 보안에 대해 고민하게 된 것도 바로 이 부분입니다. 보안을 하나의 거대한 코드에 모두 넣어 놓으면 처음에는 관리하기 편할 수 있지만 시간이 지나 취약점이 발견되었을 때 문제가 달라집니다. 어떤 부분에 문제가 생겼는지 찾아야 하고 그 부분을 수정해야 하며 수정한 코드가 다른 기능에 영향을 주지 않는지도 확인해야 합니다. 그래서 DXCMS에서는 보안 영역을 하나의 거대한 기능으로 묶기보다 각각의 공격 표면을 구분하고 필요한 영역을 독립적으로 관리할 수 있는 방향으로 발전시키고 있습니다. 현재 디자인원엑스에서 공개하고 있는 DXCMS 보안 관련 플러그인을 살펴보면 Log Injection, Extend Abuse, Hook Abuse, Plugin Isolation, Replay Attack, Rate Limit Bypass, IP Spoofing/Proxy Trust, Bot Challenge Automation Bypass, Authorization Bypass, Authentication Bypass, Path Traversal, SSRF, XSS, SQL Injection, Upload Bypass, Cookie Attribute, CSRF, Session Hijacking 등 다양한 영역으로 세분화되어 있습니다. 중요한 것은 단순히 보안 플러그인이 많다는 사실이 아닙니다. 인증과 권한을 구분하고 세션과 쿠키를 구분하며 파일 업로드와 경로 탐색을 구분하고 봇과 Rate Limit을 구분하는 것처럼 각각의 공격 표면을 별도의 문제로 바라보고 대응하려는 구조에 의미가 있습니다.
5장. DXCMS의 강점은 보안 플러그인의 숫자가 아니다
중요한 것은 몇 개를 만들었는가가 아니라 어떻게 연결되는가이다
보안 플러그인이 10개 있다고 해서 자동으로 안전한 CMS가 되는 것은 아닙니다. 20개라고 해서 반드시 더 안전하다고 말할 수도 없습니다. 보안에서 중요한 것은 숫자가 아니라 각각의 보안 계층이 어떤 위험을 담당하고 있으며 기존 시스템과 어떻게 결합되고 문제가 발생했을 때 어떻게 패치할 수 있는가입니다. DXCMS가 추구하는 구조 역시 바로 이 부분을 바라보고 있습니다. DXCMS는 코어를 직접 수정하는 방식에 의존하기보다 Plugin, Hook, Extend 등의 구조를 통해 필요한 기능을 확장할 수 있도록 설계되어 있습니다. 이것은 단순히 개발 편의를 위한 구조만은 아닙니다. 장기간 운영되는 CMS에서는 코어와 확장기능이 지나치게 결합될 경우 하나의 보안 문제를 수정하기 위해 전체 시스템을 다시 검토해야 하는 상황이 발생할 수 있기 때문입니다. 반대로 적절하게 분리된 구조에서는 특정 보안 영역을 독립적으로 개선하고 패치하는 방향을 설계할 수 있습니다. 물론 플러그인으로 분리한다고 해서 보안 문제가 자동으로 해결되는 것은 아닙니다. 플러그인 역시 하나의 소프트웨어이기 때문에 자체적으로 안전하게 설계되고 관리되어야 하며, 플러그인이 많아질수록 공급망과 의존성 관리라는 새로운 문제가 발생할 수도 있습니다. 따라서 중요한 것은 플러그인의 숫자가 아니라 확장할 수 있으면서도 그 확장을 통제하고 관리할 수 있는 구조입니다.
6장. SQL Injection과 XSS에서 끝나지 않는 DXCMS 보안
공격자가 바라보는 지점은 계속 넓어진다
현재 DXCMS에서 별도의 보안 영역으로 다루고 있는 항목들을 보면 현대 CMS의 공격 표면이 얼마나 넓어졌는지 확인할 수 있습니다. SQL Injection은 데이터베이스를 공격하는 대표적인 방법이며 XSS는 사용자의 브라우저에서 악성 스크립트가 실행될 가능성과 관련됩니다. CSRF는 사용자의 인증 상태를 악용하는 공격과 연결되고 Session Hijacking은 인증된 사용자의 세션을 탈취하는 문제를 다룹니다. Upload Bypass는 파일 업로드 기능을 공격 표면으로 이용하는 문제이며 Path Traversal은 서버의 파일 경로를 조작하는 공격과 관련됩니다. SSRF는 서버가 의도하지 않은 내부 또는 외부 자원에 요청하도록 유도하는 문제와 연결되며 Authentication Bypass와 Authorization Bypass는 각각 인증과 권한 경계를 우회하려는 공격을 다룹니다. 여기에 Replay Attack, Rate Limit Bypass, IP Spoofing/Proxy Trust, Bot Challenge Automation Bypass와 같은 운영 단계의 공격과 Plugin Isolation, Hook Abuse, Extend Abuse처럼 CMS 자체의 확장구조를 공격 표면으로 삼을 수 있는 문제까지 존재합니다. 로그 역시 예외가 아닙니다. 공격자는 데이터를 공격할 뿐만 아니라 로그 시스템 자체를 공격하거나 로그를 오염시켜 보안 분석을 어렵게 만들 수도 있습니다. 결국 현대 CMS의 보안은 과거처럼 몇 가지 대표적인 웹 취약점만 방어하는 것으로 끝나지 않습니다. CMS가 제공하는 모든 기능과 확장지점이 공격 표면이 될 수 있다는 전제에서 설계해야 합니다.
7장. DXCMS에서 바라보는 Log Injection
보안은 공격을 막는 것뿐만 아니라 흔적을 안전하게 남기는 것까지 포함한다
개인적으로 DXCMS의 보안 영역을 만들면서 중요하게 생각한 부분 중 하나가 로그입니다. 일반적으로 보안이라고 하면 공격을 차단하는 것부터 생각하지만 실제 사고가 발생했을 때는 로그가 매우 중요합니다. 언제 어떤 요청이 들어왔는지, 어떤 사용자가 어떤 행동을 했는지, 어떤 오류가 발생했는지 확인할 수 있어야 하기 때문입니다. 그런데 여기에서 또 하나의 문제가 발생합니다. 로그 자체가 공격 대상이 될 수 있다는 것입니다. DXCMS의 Log Injection 방어 플러그인은 사용자 입력이 로그에 기록되는 과정에서 발생할 수 있는 CRLF Injection, 로그 분할, ANSI Escape, 민감정보 노출, Log Viewer XSS 등의 문제를 별도로 다루고 있으며 구조화 로그, 로그 Rate Limit, 필드 길이 제한, Request ID, HMAC 기반 로그 무결성 검증 등의 기능을 통해 로그 자체를 하나의 보안 영역으로 바라보고 있습니다. 이것은 CMS 보안의 범위를 한 단계 넓혀주는 접근입니다. 보안은 공격을 막는 것만이 아니라 공격이 발생했을 때 정확하게 흔적을 남기고 그 흔적이 다시 공격에 이용되지 않도록 보호하는 것까지 포함하기 때문입니다. 로그는 단순한 디버깅 파일이 아니라 사고를 추적하고 원인을 분석하며 시스템의 이상 징후를 확인하기 위한 중요한 보안 인프라가 될 수 있습니다.
8장. 플러그인도 공격 표면이 된다
확장성은 강력하지만 확장성에는 책임이 따른다
CMS의 가장 큰 장점 가운데 하나는 플러그인입니다. 필요한 기능만 선택해서 설치할 수 있고 코어를 직접 수정하지 않고 새로운 기능을 추가할 수 있기 때문입니다. 하지만 플러그인이 많아질수록 새로운 보안 문제가 발생할 수 있습니다. 플러그인 하나가 취약하면 CMS 전체에 영향을 줄 가능성이 있기 때문입니다. 이러한 문제는 특정 CMS만의 문제가 아닙니다. OWASP Top 10:2025에서 Software Supply Chain Failures를 별도의 핵심 범주로 다루는 것도 현대 소프트웨어가 하나의 코드베이스만으로 구성되지 않는 현실을 반영합니다. 외부 라이브러리와 의존성, 빌드 시스템, 배포 과정까지 보안의 범위가 확대되고 있는 것입니다. DXCMS에서도 Plugin Isolation이라는 별도의 보안 영역을 두고 있으며 Hook Abuse와 Extend Abuse 역시 독립적인 문제로 바라보고 있습니다. 이것은 DXCMS가 추구하는 확장성과도 연결됩니다. 확장할 수 있어야 하지만 확장되는 부분 역시 통제할 수 있어야 합니다. 플러그인을 많이 만들 수 있는 CMS보다 플러그인이 늘어나더라도 각각의 확장영역을 어떻게 관리하고 검증할 것인지 고민하는 CMS가 장기적으로 더 중요한 구조를 갖게 될 수 있습니다.
9장. 코어를 건드리지 않는 구조가 보안에서도 의미를 갖는 이유
패치를 위해 전체 CMS를 다시 뜯어고치지 않는 구조
CMS를 개발하면서 가장 피하고 싶은 상황 가운데 하나는 기능 하나를 수정하기 위해 코어 전체를 수정해야 하는 것입니다. 코어에 직접 기능을 넣으면 처음에는 편할 수 있지만 시간이 지나면서 여러 기능이 서로 얽히게 되고 하나의 수정사항이 다른 기능에 영향을 줄 가능성도 커집니다. 특히 보안 취약점이 발견되었을 때 이러한 구조는 더욱 부담이 될 수 있습니다. 단순히 취약점이 있는 부분만 수정하는 것이 아니라 수정으로 인해 전체 시스템이 영향을 받지 않는지 다시 검증해야 하기 때문입니다. DXCMS는 Hook, Plugin, Extend 등의 구조를 활용하여 코어를 직접 수정하지 않고 기능을 확장하는 방향을 가지고 있습니다. 이 구조가 모든 보안 문제를 해결해 주는 것은 아니지만 보안 기능을 독립적으로 추가하고 개선하며 필요한 부분을 패치할 수 있는 구조를 만드는 데 중요한 기반이 될 수 있습니다. CMS가 짧게 사용되는 프로그램이라면 이러한 차이가 크게 느껴지지 않을 수도 있습니다. 하지만 수년 동안 운영되는 CMS라면 이야기가 달라집니다. 시간이 지나면서 보안 취약점도 발견될 수 있고 새로운 기능도 추가되며 서버환경도 변화하기 때문입니다. 결국 장기적으로 중요한 것은 처음에 얼마나 완벽하게 만들었느냐뿐만 아니라 변화가 발생했을 때 얼마나 안전하게 수정할 수 있도록 만들어 놓았느냐입니다.
10장. AI가 코드를 만들수록 보안 검증은 더 중요해진다
AI가 개발자를 도와줄수록 사람은 결과를 검증해야 한다
AI가 개발자를 도와준다고 해서 보안 전문가의 역할이 줄어든다고 단정할 수는 없습니다. 오히려 개발 속도가 빨라질수록 검증의 중요성은 더 커질 수 있습니다. AI에게 게시판을 만들어 달라고 요청할 수 있고 로그인 기능이나 API를 만들어 달라고 요청할 수도 있습니다. 그러나 만들어진 기능에 권한 우회가 존재하지 않는지, 인증과 권한이 제대로 분리되어 있는지, 파일 업로드를 우회할 수 없는지, 세션이 탈취될 가능성은 없는지, API 토큰이 잘못 사용될 가능성은 없는지, 로그에 민감한 정보가 기록되지 않는지 등을 판단하는 것은 별개의 문제입니다. AI는 개발자의 생산성을 높여주는 도구가 될 수 있지만 시스템 전체의 위험을 최종적으로 판단하고 책임지는 주체는 여전히 사람입니다. 그래서 AI 시대의 시니어 개발자는 코드를 직접 많이 작성하는 능력만으로 평가되는 것이 아니라 구조를 설계하고 위험을 발견하며 AI가 만들어낸 결과를 검증할 수 있는 능력이 더욱 중요해질 수 있습니다. 저는 오히려 AI 시대가 될수록 개발 경험이 많은 사람과 그렇지 않은 사람의 차이가 코드 작성 속도보다 시스템을 바라보는 시야에서 나타날 가능성이 있다고 생각합니다.
11장. CMS의 진짜 경쟁력은 보안 기능보다 보안 구조다
한 번의 방어보다 계속 방어할 수 있는 시스템
저는 이제 CMS 보안을 조금 다르게 바라보고 있습니다. 과거에는 보안 기능을 하나 추가하면 보안을 강화했다고 생각할 수 있었습니다. 하지만 지금은 그렇게 단순하게 생각하기 어렵습니다. 보안은 계속 변하기 때문입니다. 오늘 발견되지 않은 취약점이 내일 발견될 수 있고, 지금 안전한 외부 라이브러리에서 새로운 취약점이 발견될 수도 있으며, 현재 존재하지 않는 새로운 공격기법이 등장할 수도 있습니다. 따라서 진짜 중요한 것은 특정 보안 기능 하나의 완성도가 아니라 새로운 보안 문제를 계속 받아들이고 대응할 수 있는 구조입니다. DXCMS가 보안 영역을 하나씩 분리하여 개발하고 있는 이유도 여기에 있습니다. 현재 공개된 보안 영역만 보더라도 인증, 권한, 세션, 쿠키, CSRF, 파일 업로드, SQL Injection, XSS, SSRF, Path Traversal, 봇, Rate Limit, IP 신뢰, Replay Attack, Plugin Isolation, Hook, Extend, 로그 등으로 세분화되어 있습니다. 이것은 보안이 하나의 거대한 기능이 아니라 계속해서 새로운 위험을 받아들이는 구조여야 한다는 생각과 연결됩니다. 보안은 완성품이 아니라 변화에 대응하는 시스템입니다.
12장. 앞으로의 CMS는 기능을 더 넣는 것보다 안전하게 확장할 수 있어야 한다
CMS가 다른 시스템과 연결될수록 보안의 범위도 넓어진다
CMS는 이제 단순히 웹사이트의 게시물을 관리하는 프로그램으로만 존재하지 않습니다. 기업의 인트라넷과 ERP, 외부 서비스, 모바일 애플리케이션, API, 다양한 데이터 시스템과 연결될 수 있습니다. DXCMS 역시 REST API와 같은 확장기능을 통해 외부 시스템과 연결할 수 있는 구조를 제공하고 있습니다. 이러한 확장은 CMS의 활용 범위를 크게 넓혀주지만 동시에 보안의 경계도 넓어집니다. 웹사이트 내부에서만 사용되는 시스템이라면 고려하지 않아도 되었던 인증 토큰과 API 권한, 외부 요청, 데이터 무결성 등의 문제가 등장하기 때문입니다. 결국 CMS가 발전할수록 보안 역시 함께 발전해야 합니다. 기능을 추가하면서 보안을 나중에 생각하는 방식으로는 충분하지 않을 수 있습니다. 새로운 기능을 추가하는 순간 그 기능이 어떤 공격 표면을 만드는지 함께 생각해야 합니다. 확장성과 보안은 서로 반대되는 개념이 아니라 확장할수록 더욱 정교하게 함께 설계해야 하는 관계가 됩니다.
13장. 앞으로 CMS를 선택하는 기준도 달라질 수 있다
“무엇을 할 수 있는가”에서 “어떻게 지키는가”로
지금까지 CMS를 선택할 때 우리는 기능표를 많이 확인했습니다. 게시판이 몇 개 있는지, 회원관리가 되는지, 관리자 기능이 편리한지, 플러그인을 얼마나 사용할 수 있는지, 테마를 쉽게 변경할 수 있는지 등을 확인했습니다. 앞으로도 이러한 기능은 중요합니다. 그러나 AI 시대에는 여기에 새로운 질문이 추가될 수 있습니다. 취약점이 발견되었을 때 어떻게 대응하는가, 보안 패치를 얼마나 지속적으로 제공하는가, 플러그인과 테마는 어떻게 관리하는가, 인증과 권한은 어떻게 분리되어 있는가, 세션과 쿠키는 어떻게 보호되는가, 파일 업로드는 어떻게 검증하는가, 로그는 안전하게 관리되는가, 외부 라이브러리의 취약점을 어떻게 확인하는가, 새로운 공격방법이 등장했을 때 얼마나 빠르게 대응할 수 있는가와 같은 질문입니다. 이것은 CMS의 기능이 중요하지 않다는 뜻이 아닙니다. 오히려 실제 서비스를 운영하는 단계에서는 기능을 안전하게 사용할 수 있는 기반이 있어야 하기 때문입니다. 결국 CMS의 진짜 가치는 기능의 숫자만으로 설명하기 어려워질 수 있습니다.
14장. 보안은 CMS의 부가 기능이 아니라 핵심 인프라가 된다
보안 플러그인이 많다는 것보다 보안을 계속 발전시키는 것이 중요하다
DXCMS의 현재 보안 플러그인을 보면 하나의 방향이 나타납니다. 보안을 하나의 부가 기능으로 취급하지 않고 각각의 영역을 지속적으로 찾아보고 있다는 것입니다. 인증 문제가 있다면 인증을 바라보고 권한 문제가 있다면 권한을 바라보며 세션과 쿠키, 파일 업로드, SQL Injection, XSS, SSRF, Path Traversal, 봇, Rate Limit, IP 신뢰, Replay Attack, 플러그인 격리, Hook과 Extend, 로그까지 각각의 공격 표면을 나누어 바라보고 있습니다. 저는 이것이 중요한 이유가 있다고 생각합니다. 보안 문제는 한꺼번에 나타나지 않기 때문입니다. 오늘은 XSS가 중요한 문제가 될 수 있고 내일은 인증 우회가 문제가 될 수 있으며 다음에는 외부 라이브러리 취약점이 문제가 될 수도 있습니다. 또 다른 시점에는 지금까지 존재하지 않았던 새로운 공격방식이 등장할 수도 있습니다. 그렇기 때문에 보안은 한 번 만들어 놓고 끝나는 기능이 아니라 계속해서 변화하는 환경을 받아들이는 구조여야 합니다.
15장. 결국 AI 시대의 CMS는 누가 더 오래 지키느냐의 경쟁이 될 수 있다
만드는 사람보다 지키는 사람이 중요해지는 순간
저는 앞으로 CMS 시장이 상당히 다른 방향으로 움직일 가능성이 있다고 생각합니다. AI가 발전할수록 개발자는 더 빠르게 코드를 만들 수 있고 숙련된 개발자가 AI를 제대로 활용한다면 하나의 시스템을 구축하는 속도 역시 과거보다 훨씬 빨라질 수 있습니다. 그렇다면 CMS를 만드는 기술 자체가 지금보다 널리 퍼질 가능성이 있습니다. 하지만 CMS를 만드는 것과 CMS를 수년 동안 안전하게 운영하는 것은 전혀 다른 문제입니다. CMS는 출시하는 날 끝나는 소프트웨어가 아닙니다. 오히려 출시하는 순간부터 새로운 문제가 시작됩니다. 사용자가 늘어나고 데이터가 늘어나며 플러그인이 추가되고 외부 서비스가 연결되고 서버환경이 바뀌며 PHP와 데이터베이스, 브라우저와 네트워크 환경도 계속 변화합니다. 공격기법 역시 계속 변화합니다. 이러한 변화 속에서도 시스템을 유지해야 합니다. 그래서 앞으로의 CMS 경쟁력은 단순히 얼마나 잘 만들었는가가 아니라 얼마나 오랫동안 안전하게 유지할 수 있는가에 의해 평가될 가능성이 있습니다.
16장. DXCMS가 지금 보안을 이야기하는 이유
기능 개발의 끝이 아니라 보안 개발의 시작
DXCMS는 이미 다양한 기능을 갖추고 있습니다. 그러나 이제는 기능을 계속 추가하는 것만을 목표로 삼아서는 안 된다고 생각합니다. 이미 만들어진 기능을 더욱 안전하게 만들고 새로운 공격 가능성을 찾아내며 취약점을 발견하면 독립적으로 패치하고 필요한 보안 기능을 플러그인으로 확장하며 코어의 안정성을 유지하면서 새로운 방어 계층을 추가하는 것, 이것이 앞으로 DXCMS가 가야 할 중요한 방향 가운데 하나라고 생각합니다. 현재 디자인원엑스에서 공개하고 있는 보안 관련 플러그인들을 보면 이러한 방향을 확인할 수 있습니다. SQL Injection과 XSS 같은 전통적인 웹 취약점에서 시작해 CSRF, Session Hijacking, Authentication Bypass, Authorization Bypass, Upload Bypass, Path Traversal, SSRF, Cookie Attribute, IP Spoofing, Rate Limit Bypass, Replay Attack, Bot Challenge Automation Bypass, Plugin Isolation, Hook Abuse, Extend Abuse, Log Injection까지 보안의 범위를 계속 넓혀가고 있습니다. 이것은 단순히 보안 플러그인이 많다는 이야기가 아닙니다. CMS의 보안을 바라보는 관점 자체가 변화하고 있다는 이야기입니다.
맺음말
AI는 CMS를 더 쉽게 만들 것이다. 그렇다면 CMS를 지키는 일은 더 중요해질 것이다
저는 AI 시대에 CMS의 미래를 생각하면서 한 가지 질문을 계속하게 됩니다. 앞으로 AI가 더욱 발전한다면 CMS를 만드는 일은 얼마나 쉬워질 것인가, 그리고 그때 CMS의 진짜 경쟁력은 무엇으로 남게 될 것인가라는 질문입니다. 저는 기능만으로는 충분하지 않을 것이라고 생각합니다. AI는 계속 발전할 것이고 개발자가 작성해야 하는 코드의 양은 줄어들 수도 있으며 프로토타입을 만드는 시간도 짧아질 수 있습니다. 숙련된 개발자가 AI를 활용한다면 새로운 CMS와 서비스를 이전보다 훨씬 빠르게 만들어낼 수도 있습니다. 그렇다면 결국 경쟁의 중심은 다른 곳으로 이동할 수 있습니다. 저는 그 중심 가운데 하나가 보안이라고 생각합니다. 정확하게 말하면 단순히 보안 기능을 많이 가지고 있는가가 아니라 보안을 지속적으로 유지할 수 있는 능력입니다. 오늘 안전한가, 내일도 안전한가, 취약점이 발견되었을 때 얼마나 빠르게 대응할 수 있는가, 플러그인과 테마는 안전한가, 외부 라이브러리는 안전한가, 관리자 권한은 제대로 통제되는가, 로그는 안전하게 남는가, API는 안전한가, 새로운 공격기법이 등장했을 때 대응할 수 있는 구조인가, 그리고 무엇보다 문제가 발생했을 때 다시 고칠 수 있는 구조인가를 물어야 합니다.
DXCMS 역시 지금 그 길을 가고 있습니다. 처음부터 모든 보안을 완벽하게 만들었다고 말하는 것이 아닙니다. 오히려 새로운 취약점이 발견될 수 있다는 사실을 인정하고 그때마다 필요한 부분을 찾아내고 분리하고 패치할 수 있는 CMS를 만들어가는 것입니다. 이것이 중요한 이유는 보안에는 완성이라는 말이 쉽게 적용될 수 없기 때문입니다. 오늘의 공격방법과 내일의 공격방법이 같다는 보장은 없으며 오늘 안전했던 구성요소가 시간이 지나 새로운 취약점을 가질 수도 있습니다. 따라서 중요한 것은 모든 공격을 영원히 막을 수 있다고 주장하는 것이 아니라 새로운 공격이 등장했을 때 얼마나 빠르게 발견하고 대응할 수 있는 구조를 갖추고 있느냐입니다.
AI가 코드를 만드는 시대라면 사람은 구조를 설계해야 합니다. AI가 기능을 만드는 시대라면 사람은 그 기능을 검증해야 합니다. AI가 CMS를 빠르게 만드는 시대라면 우리는 CMS를 오랫동안 안전하게 운영할 방법을 만들어야 합니다. 결국 앞으로의 CMS 경쟁은 누가 더 많은 기능을 만들었는가에서 누가 더 안전한 구조를 만들었는가로, 그리고 다시 누가 더 오랫동안 그 안전을 유지할 수 있는가로 이동할 가능성이 있습니다.
그래서 저는 앞으로 CMS의 진짜 경쟁력은 단순히 기능의 숫자로 결정되지 않을 것이라고 생각합니다. CMS를 만들 수 있는 기술은 AI와 함께 더욱 보편화될 수 있습니다. 그러나 CMS를 안전하게 운영하고 새로운 취약점에 대응하며 수년 동안 안정적으로 유지하는 능력은 단순한 코드 생성만으로 해결하기 어렵습니다. 결국 필요한 것은 경험과 설계, 검증과 운영, 그리고 무엇보다 지속적인 보안 대응입니다.
AI 시대, 이제 CMS의 승부는 보안에서 갈릴 수 있습니다.
CMS를 만드는 기술은 계속 발전할 것입니다. 새로운 기능도 계속 등장할 것입니다. AI는 개발자를 더욱 빠르게 만들어 줄 것입니다. 하지만 공격 역시 계속 발전할 것입니다. 새로운 취약점이 발견될 것이고 새로운 공격기법이 등장할 것이며 새로운 확장기능이 새로운 공격 표면을 만들어낼 수도 있습니다.
그래서 CMS의 보안에는 마지막이라는 말이 어울리지 않습니다.
보안은 완성하는 것이 아니라 계속 지켜가는 것입니다.
그리고 저는 앞으로 DXCMS가 단순히 기능을 많이 가진 CMS가 아니라 안전하게 확장되고, 지속적으로 패치되며, 새로운 위협에 대응할 수 있고, 오랫동안 운영할 수 있는 CMS로 성장하는 것이 더욱 중요하다고 생각합니다.
AI가 CMS를 만드는 시대.
이제 우리는 한 단계 더 생각해야 합니다.
무엇을 만들 것인가.
그리고 그 다음에는 반드시 이런 질문을 해야 합니다.
그것을 어떻게 지킬 것인가.
그리고 결국 마지막에는 또 하나의 질문이 남습니다.
몇 년이 지나도 안전하게 지킬 수 있는가.
저는 앞으로 CMS의 진짜 경쟁력이 바로 이 질문에서 시작될 것이라고 생각합니다.
AI 시대, 이제 CMS의 승부는 보안에서 갈릴 수 있습니다.
그리고 어쩌면 앞으로의 CMS는 무엇을 만들었는지가 아니라, 그것을 얼마나 오래 안전하게 지켜냈는지로 자신의 실력을 증명하게 될지도 모릅니다.
