자사 CMS로 전환하는 에이전시들

CMS 개발의 시대에서 CMS를 보유하고 운영하는 시대로

과거 웹 에이전시의 웹사이트 개발 방식은 비교적 단순했습니다. 고객의 요구사항을 분석하고 이미 널리 사용되고 있는 CMS나 프레임워크를 선택한 뒤 디자인과 필요한 기능을 추가하는 방식이 일반적이었습니다. 특히 오픈소스 CMS가 빠르게 성장하면서 에이전시가 직접 CMS의 핵심 구조를 개발해야 할 필요성은 상대적으로 줄어들었습니다. 그러나 웹 서비스의 규모가 커지고 기업의 요구사항이 복잡해지면서 이러한 개발 환경도 조금씩 달라지고 있습니다. 단순한 기업 홈페이지를 넘어 ERP, 인트라넷, 회원관리, 대규모 커뮤니티, 쇼핑몰, 업무 시스템, API 연동, 외부 서비스 통합 등 다양한 요구사항이 하나의 플랫폼 안에서 처리되기 시작하면서 기존 CMS를 그대로 사용하는 것만으로는 프로젝트의 모든 요구를 충족하기 어려운 경우가 발생하고 있습니다. 이러한 변화 속에서 일부 웹 에이전시와 소프트웨어 개발 기업들은 자신들이 반복적으로 사용하는 기능과 구조를 하나의 자체 플랫폼으로 만들기 시작했습니다. 프로젝트마다 처음부터 모든 것을 개발하는 대신 자체 CMS 또는 자체 웹 플랫폼을 구축하고 이후 진행되는 프로젝트에서 이를 기반으로 개발하는 방식입니다. 자체 CMS를 하나의 내부 개발 도구가 아니라 반복적인 프로젝트를 위한 기술 플랫폼으로 활용하는 흐름은 이미 여러 개발 기업에서 나타나고 있습니다.
 

그러나 여기에서 매우 중요한 문제가 발생합니다. CMS를 만들 수 있다는 것과 안정적인 CMS를 운영할 수 있다는 것은 전혀 다른 문제입니다. CMS는 단순히 관리자 화면을 만들고 게시물을 저장하는 프로그램이 아닙니다. 사용자의 인증과 권한, 데이터베이스 구조, 파일 업로드, 세션과 쿠키, API, 검색, 캐시, 로그, 관리자 기능, 데이터 무결성, 외부 서비스 연동, 서버 환경과의 호환성 등 수많은 요소가 서로 연결되어 있는 하나의 소프트웨어 시스템입니다. 특히 CMS는 일반적인 웹페이지보다 많은 사용자가 데이터를 입력하고 수정하며 관리자 권한을 가진 사용자가 중요한 데이터를 조작하기 때문에 보안 구조가 매우 중요합니다. OWASP의 웹 애플리케이션 보안 위험에서도 접근제어 문제는 핵심적인 위험으로 다뤄지고 있으며, 권한이 없는 사용자가 다른 사용자의 데이터에 접근하거나 API를 통해 허용되지 않은 기능을 실행하는 문제 등은 CMS를 직접 개발하는 조직이 반드시 고려해야 할 영역입니다.
 

자체 CMS의 장점은 동시에 책임이 된다

자체 CMS의 가장 큰 장점은 자유도입니다. 불필요한 기능을 제거하고 기업의 업무에 필요한 기능만 설계할 수 있으며 데이터베이스 구조 역시 프로젝트의 목적에 맞게 구성할 수 있습니다. 외부 CMS의 구조에 맞추어 개발하는 것이 아니라 기업의 업무 프로세스 자체를 CMS에 반영할 수 있다는 것도 장점입니다. 또한 특정 플러그인이나 테마에 지나치게 의존하지 않고 시스템의 핵심 구조를 직접 통제할 수 있다는 점 역시 자체 CMS가 가지는 중요한 가치입니다. 그러나 바로 그 자유도가 위험으로 바뀔 수도 있습니다. 외부 CMS를 사용하는 경우에는 해당 제품을 개발하고 유지보수하는 조직이 존재하며, 많은 사용자와 개발자가 사용하는 과정에서 문제가 발견되고 취약점이 공개되며 패치가 제공되는 생태계가 형성될 수 있습니다. 반면 자체 CMS는 개발팀이 설계한 구조 자체가 하나의 생태계가 됩니다. 개발팀이 놓친 취약점은 외부에서 발견되지 않은 채 장기간 남아 있을 수도 있고, 초기에는 문제가 없어 보였던 구조가 서비스 규모가 커지면서 성능이나 보안 문제로 이어질 수도 있습니다. 따라서 자체 CMS를 구축했다는 사실 자체가 보안을 보장하는 것은 아닙니다. 오히려 자체 CMS를 보유하는 순간부터 개발사는 CMS의 보안과 유지보수에 대한 책임을 직접 부담하게 됩니다.
 

CISA 역시 소프트웨어 제조사가 제품이 배포된 이후에도 고객의 보안 결과에 책임을 가지고 취약점을 발견하고 패치를 제공하며 보안 업데이트를 쉽게 적용할 수 있도록 해야 한다는 Secure by Design 원칙을 제시하고 있습니다. 이는 CMS에도 그대로 적용할 수 있는 개념입니다. CMS는 개발이 끝나는 순간 관리가 끝나는 제품이 아니라 실제 서비스가 운영되는 동안 지속적으로 변화하고 관리되어야 하는 소프트웨어이기 때문입니다. 새로운 보안 취약점이 발견될 수 있고 PHP, 데이터베이스, 웹서버와 같은 실행환경이 변경될 수도 있으며 브라우저와 모바일 환경이 변화할 수도 있습니다. 새로운 API가 필요할 수도 있고 기존 기능에서 예상하지 못했던 버그가 발견될 수도 있습니다. 결국 CMS의 개발 완료는 CMS의 생명주기가 끝났다는 의미가 아니라 오히려 CMS의 실제 생명주기가 시작되는 시점에 가깝습니다.
 

CMS의 성능은 기능 목록만으로 판단할 수 없다

자체 CMS를 개발할 때 또 하나의 어려운 문제가 성능입니다. 처음에는 대부분의 CMS가 빠릅니다. 회원이 수십 명이고 게시물이 수백 개이며 동시접속자가 많지 않은 환경에서는 데이터베이스 구조나 캐시 구조에 문제가 있더라도 쉽게 드러나지 않습니다. 그러나 서비스 규모가 커지고 회원 수가 증가하며 게시물이 수십만 건, 수백만 건으로 증가하기 시작하면 이야기가 달라집니다. 처음에는 빠르게 처리되던 데이터베이스 쿼리가 데이터 증가에 따라 느려질 수 있고 잘못 설계된 인덱스 하나가 전체 시스템의 성능에 영향을 줄 수도 있습니다. 반복적인 데이터 조회나 불필요한 JOIN, 세션 처리, 파일 처리, 캐시 정책 하나가 서버의 부하를 증가시킬 수도 있습니다. 더 어려운 것은 이러한 문제가 개발 초기에는 잘 보이지 않는다는 것입니다. 따라서 CMS의 성능은 단순히 현재 페이지가 빨리 열린다는 사실만으로 판단할 수 없습니다. 데이터가 증가했을 때 어떻게 동작하는지, 동시접속자가 증가했을 때 어떤 병목이 발생하는지, 캐시가 어떤 방식으로 동작하는지, 데이터베이스가 어떤 방식으로 확장되는지, API 요청이 증가했을 때 서버가 어떻게 대응하는지를 함께 살펴봐야 합니다. 이러한 문제는 단순히 코드를 작성할 수 있는 능력만으로 해결하기 어렵습니다. 시스템 전체를 바라보고 장기적인 결과까지 판단할 수 있는 개발자의 경험이 필요한 영역입니다.
 

그래서 시니어 개발자의 존재가 중요하다

여기서 말하는 시니어 개발자는 단순히 프로그래밍 경력이 오래된 사람을 의미하지 않습니다. 중요한 것은 시스템의 구조를 이해하고 개발 당시의 선택이 향후 어떤 문제를 만들 수 있는지 예측하며 문제가 발생했을 때 원인을 추적하고 해결할 수 있는 능력입니다. CMS를 개발할 때 이러한 능력은 특히 중요합니다. 회원 권한을 어떻게 설계할 것인지, 관리자와 일반 사용자의 접근 영역을 어떻게 분리할 것인지, API의 인증과 권한을 어디에서 검증할 것인지, 파일 업로드를 어떻게 제한할 것인지, 데이터베이스의 핵심 테이블을 어떻게 구성할 것인지, 캐시를 어느 계층에서 적용할 것인지, 오류가 발생했을 때 어떻게 추적할 것인지와 같은 문제는 각각 독립적인 문제가 아닙니다. 하나의 설계가 다른 영역에 영향을 줍니다. 잘못된 권한 설계는 보안 문제가 될 수 있고 잘못된 데이터베이스 설계는 성능 문제가 될 수 있으며 지나치게 복잡한 구조는 향후 유지보수 비용을 증가시킬 수 있습니다. 따라서 자체 CMS를 개발하는 조직에서는 단순히 “개발자가 있는가?”를 확인하는 것보다 “시스템의 구조를 책임지고 판단할 수 있는 사람이 있는가?”를 확인하는 것이 훨씬 중요합니다.
 

AI 시대에는 오히려 이 문제가 더욱 중요해졌다

최근에는 AI를 이용해 웹 애플리케이션과 CMS의 기본적인 기능을 빠르게 만들어낼 수 있습니다. 회원가입, 로그인, 게시판, 관리자 페이지, CRUD, API 등 과거에는 상당한 시간이 필요했던 기능도 AI의 도움을 받으면 짧은 시간 안에 구현할 수 있습니다. 이것은 분명한 기술적 발전입니다. 그러나 여기에서 한 가지 착각해서는 안 됩니다. 코드를 빠르게 생성할 수 있다는 것과 그 코드가 장기간 안전하게 운영될 수 있다는 것은 다른 문제입니다. AI가 생성한 코드가 정상적으로 동작한다고 해서 그것이 반드시 안전한 구조라는 의미는 아닙니다. 권한 검증이 특정 경로에서 빠져 있거나 예외 상황을 제대로 처리하지 못하거나 API의 입력값을 충분히 검증하지 않거나 데이터베이스 쿼리 구조가 특정 상황에서 병목을 일으킬 가능성도 존재합니다. 따라서 AI는 개발 속도를 높이는 강력한 도구가 될 수 있지만 최종적인 구조적 판단과 검증의 책임까지 대신해 주는 것은 아닙니다. 오히려 AI로 개발 속도가 빨라질수록 사람의 역할은 코드를 직접 작성하는 것에서 시스템을 검증하고 판단하는 방향으로 이동할 가능성이 큽니다.
 

CMS의 진짜 가치는 배포 이후에 드러난다

CMS는 개발이 끝나는 순간 완성되는 제품이 아닙니다. 배포 이후 새로운 보안 취약점이 발견될 수 있고 PHP나 데이터베이스, 웹서버와 같은 실행환경이 변경될 수 있으며 브라우저와 모바일 환경이 변화할 수도 있습니다. 새로운 API가 필요할 수도 있고 기존 기능에서 예상하지 못했던 버그가 발견될 수도 있습니다. 따라서 CMS의 품질을 평가할 때는 현재 가지고 있는 기능만 보는 것이 아니라 얼마나 오랫동안 안정적으로 변화에 대응할 수 있는 구조인가를 함께 봐야 합니다. 정기적인 취약점 점검과 코드 분석, 구성요소 분석, 패치 관리가 필요한 이유도 여기에 있습니다. CMS가 수많은 사이트에서 사용되는 순간 하나의 패치가 여러 서비스의 안정성에 영향을 줄 수 있기 때문에 개발자는 새로운 기능을 추가하는 것만큼 기존 구조를 안전하게 유지하는 일에도 책임을 가져야 합니다.
 

결국 좋은 CMS란 기능이 많은 CMS가 아닙니다. 변화할 수 있는 CMS, 문제가 발생했을 때 수정할 수 있는 CMS, 수정한 내용이 기존 시스템을 무너뜨리지 않는 CMS, 그리고 새로운 보안 위협에 지속적으로 대응할 수 있는 CMS가 좋은 CMS입니다. 이것은 화려한 관리자 화면이나 많은 기능 목록만으로는 확인할 수 없는 부분입니다. 실제로 CMS를 장기간 운영해본 경험과 장애와 보안 문제를 직접 해결해본 경험이 중요한 이유도 바로 여기에 있습니다.
 

자사 CMS 시대에 필요한 것은 개발 능력 이상의 것이다

앞으로 더 많은 개발 기업과 에이전시가 자신들만의 CMS나 개발 플랫폼을 보유하려는 움직임을 보일 가능성이 있습니다. 프로젝트마다 반복되는 개발을 줄이고 자신들의 개발 경험을 기술자산으로 축적하며 고객에게 보다 유연한 시스템을 제공하기 위해서는 충분히 합리적인 선택입니다. 하지만 자체 CMS를 개발하는 것은 단순히 새로운 제품 하나를 만드는 일이 아닙니다. 하나의 소프트웨어 생태계를 만드는 일입니다. 그리고 생태계를 만든다는 것은 그 안에서 발생하는 문제에 지속적으로 책임을 져야 한다는 뜻입니다. 특히 중견 규모의 에이전시가 자체 CMS를 기반으로 여러 고객의 서비스를 개발하기 시작한다면 CMS 자체가 회사의 핵심 기술자산이 됩니다. 이때 CMS의 작은 결함 하나가 단일 프로젝트의 문제가 아니라 해당 CMS를 사용하는 여러 프로젝트에 동시에 영향을 미칠 수 있습니다. 따라서 자체 CMS를 개발하는 조직에서는 초기 개발팀뿐만 아니라 장기적인 유지보수 체계, 코드 리뷰, 보안 점검, 취약점 대응, 성능 모니터링, 장애 대응, 버전 관리와 같은 운영 체계까지 함께 설계해야 합니다.
 

그리고 그 중심에는 결국 사람이 있습니다. CMS의 성능과 보안을 결정하는 것은 CMS라는 이름이나 개발 언어가 아닙니다. 그 시스템을 어떻게 설계했는지, 어떤 원칙으로 개발했는지, 문제가 발생했을 때 얼마나 정확하게 원인을 분석할 수 있는지, 그리고 1년 후, 3년 후에도 그 구조를 이해하고 수정할 수 있는지가 중요합니다. 특히 CMS와 같은 핵심 플랫폼은 개발자가 떠났을 때 아무도 구조를 이해하지 못하는 순간부터 기술부채가 급격하게 증가할 수 있습니다. 따라서 시니어 개발자의 역할은 단순히 어려운 코드를 작성하는 데 있지 않습니다. 시스템의 방향을 결정하고 개발팀이 선택한 기술적 판단을 검증하며 문제가 발생했을 때 전체 구조에서 원인을 찾아내고 미래의 위험까지 고려하는 것이 진정한 역할입니다.
 

결론

과거에는 CMS를 선택하는 시대였다면 이제는 CMS를 직접 보유하려는 시대가 열리고 있습니다. 에이전시가 자체 CMS를 갖는 것은 단순히 다른 회사의 솔루션을 사용하지 않겠다는 의미가 아닙니다. 그것은 자신들의 개발 경험과 기술을 하나의 플랫폼으로 축적하겠다는 의미가 될 수 있습니다. 그러나 자체 CMS의 진정한 가치는 “우리도 CMS를 만들었다”는 사실에서 발생하지 않습니다. 오히려 그 이후부터 시작됩니다. 얼마나 안정적인가, 얼마나 빠른가, 얼마나 안전한가, 문제가 발생했을 때 얼마나 빠르게 원인을 찾고 수정할 수 있는가, 그리고 그 CMS를 만든 개발자가 떠난 이후에도 다른 개발자가 그 구조를 이해하고 유지할 수 있는가를 확인해야 합니다. 이러한 질문에 답할 수 있어야 비로소 하나의 CMS를 만들었다고 말할 수 있습니다.
 

AI가 코드를 만들어주는 시대가 되면서 CMS를 만드는 진입장벽은 분명 낮아지고 있습니다. 그러나 역설적으로 검증하고 책임지는 기술의 가치는 더욱 높아지고 있습니다. 과거에는 CMS를 처음부터 개발하는 데 많은 시간과 인력이 필요했다면 이제는 AI를 활용해 상당히 짧은 시간 안에 기본적인 CMS를 만들어낼 수도 있습니다. 그러나 CMS를 실제 서비스에 배포하고 여러 고객에게 공급하는 순간부터 이야기는 달라집니다. 그때부터는 코드를 생성하는 능력보다 코드의 구조를 이해하고 취약점을 찾아내며 성능을 분석하고 문제가 발생했을 때 책임지고 패치할 수 있는 능력이 중요해집니다.
 

따라서 자체 CMS의 경쟁력은 얼마나 많은 기능을 가지고 있는지가 아니라 얼마나 오랫동안 안전하고 안정적으로 운영될 수 있는가에 의해 결정됩니다. 그리고 그 기반에는 아키텍처를 이해하고 보안을 설계하며 성능을 분석하고 지속적으로 패치할 수 있는 개발 역량이 필요합니다. 결국 자체 CMS 시대가 본격화될수록 CMS를 만드는 사람의 역할보다 CMS를 끝까지 책임질 수 있는 사람의 가치가 더욱 중요해질 것입니다.
 

참고자료

[1] OWASP Foundation, OWASP Top 10:2025 — A01 Broken Access Control. 웹 애플리케이션의 접근제어와 권한 검증 문제를 주요 보안 위험으로 다루고 있습니다.
 

[2] CISA, Secure by Design Pledge. 소프트웨어 개발사가 제품 생명주기 전반에서 보안을 고려하고 취약점에 지속적으로 대응해야 한다는 원칙을 제시하고 있습니다.
 

[3] CISA & FBI, Product Security Bad Practices. 소프트웨어 구성요소의 취약점 관리, 보안 패치, 오픈소스 의존성 관리 등의 중요성을 다루고 있습니다.
 

[4] OWASP Foundation, Authorization Cheat Sheet. 애플리케이션의 권한 로직을 업무 맥락에 맞게 설계하고 유지보수 및 확장이 가능한 구조로 관리해야 한다는 내용을 설명하고 있습니다.
 

[5] OWASP Foundation, Legacy Application Management Cheat Sheet. 오래된 애플리케이션의 취약점 점검, 코드 분석, 구성요소 분석, 패치 관리 및 지속적인 보안 관리의 중요성을 설명하고 있습니다.