어째서 그 CMS 프로젝트는 몇 년째 끝나지를 못하는 걸까?

Mar 21, 2026

대형 프로젝트가 엎어졌다는 이야기는 여러 회사에서 늘 나오는 이야기이긴 하다. 코볼(COBOL) 코드와 IBM 메인프레임을 교체하려다 멈춰선 대기업, 차세대 시스템을 도입하려다 실패한 은행, 파편화된 여러 메뉴를 하나로 합치는 것도 못하고서 팀이 해체된 커머스 업체 등등… 그중 요새 내 귀에 자주 들려오는 이야기는 ‘우리 신문사 CMS(Content Management System) 교체에 실패했다’는 기자들의 푸념이다. 어디는 모바일로 기사를 송고한다는데 우리는 아직도 노트북에서 뭘 켜서 DOS 시절 비슷한 UI로 글을 써야 한다는 이야기가 2026년에도 종종 들려온다. 어떤 신문사는 정부 지원을 받아 새 CMS 개발 업체의 제품을 받아 매년 몇억씩 내놓는다고도 하고, 어떤 회사는 사장이 직접 나서 CMS를 개편한다고 나서고는 개발자를 계속 뽑는데도 끝을 보지 못했다는 이야기가 나돈다. 심지어 어떤 곳은 PM이나 개발자가 도망갔다는 이야기도 들려온다. 계절마다 들려오는 “우리 회사 CMS 좀 어떻게 안 될까요?”라는 물음에 이제 글을 하나 써야겠다는 생각이 들었다.

기싸움이 불러오는 기술부채

CMS는 단순히 글을 쓰는 도구가 아니다. 신문사에서는 기사 작성과 편집, 온라인 송고와 온라인 발행, 포털 연동, 그리고 오프라인 조판으로 이어지는 전 과정에 쓰이는 시스템이고, 방송의 경우 뉴스 관리부터 영상 리소스 관리, 방송 송출 전단계의 소스까지 고려해야하는 거대한 인프라이다.

‘제품을 만드는 일’을 전문 업체가 아니라 언론사가 직접 하게 된다면 무슨 일이 벌어질까? 작은 언론사라면 WordPress를 개조해서 CMS를 뚝딱 만드는 게 어려운 일은 아니다. 하지만 사람이 많아지고 사용자가 많아지면서부터 기술부채가 기하급수적으로 늘어난다. CMS에서 협업 시스템을 분리해내지 못했다가는 사고가 빈번해지고 업무의 긴장감이 높아진다. 기술적 관점에서는 인프라 설계에서부터 실은 전문가의 손길이 필요한 부분이 한두 가지가 아니다. 문제는 기술 외적 부분에서 터진다.

개발자를 영입하든지 해서 CMS를 직접 만들기로 한 언론사 A를 살펴보자. CMS에서 특히나 까다로운 부분은 콘텐츠가 발행되고 배치되는 사이트 빌더이다. 요구사항이 워낙 천차만별이기 때문에 ‘매우 유연한’ 사이트 빌더를 만들어야 한다. 사용 시나리오부터 유즈케이스까지 설계할 때부터 신경써야 할 것이 많다. 템플릿 시스템부터 기술 난이도도 높다. 그런데, 언론사A 종사자들은 ‘기가 꺾이지 않으려고’ 주니어 개발자를 채용했다. 놀랍게도 조직 내 주도권을 빼앗기지 않아야 한다고, ‘기가 꺾이지 않으려고’ 개발자는 주니어로 뽑아야 한다는 원칙을 내건 것이다. 경험이 없는 주니어 개발자들은 허둥지둥 시키는 대로 만들기는 했지만 기술적 난이도를 해결하지 못하고 노하우를 얻지도 못한 채 CMS는 결국 출시되지 못했다.

기자 직군이 아닌 사람이 업무 프로세스를 설계하거나, UX를 설계하려 하면 ‘가르치려 드는’ 것으로 치부하며 못마땅해하는 문화가 언론계에는 여전히 존재한다. 때문에 개발업계에서 언론사 프로젝트는 업무 강도가 ‘높은’ 것으로 소문나 있다. 커뮤니케이션 비용의 규모부터 IT제품을 만드는 업체의 개발환경과는 사뭇 다른 것이다. 사주가 CTO를 데려왔는데 아무도 그의 지시를 따르지 않았다는 K사, 주니어끼리 어떻게 해보려다 CMS 출시는 하지 못하고 결국 광고 퍼블리셔로 직군을 전환시켰다는 A사, 개발자와 협업하기를 거부하고 기자가 개발을 배워서 조금씩 뭐라도 개선했다고 자랑하는 B사 등이 업계에 널리 회자되곤 한다. 그 결과, 포털을 위시한 IT 직군의 많은 노하우와 기술이 언론사로 내재화되지 못하고, 기술 격차는 나날이 벌어졌다.

외주의 안락함

외주 CMS란 누군가 만들어둔 기성 제품(SaaS)을 사와서 라이선스 비용을 내는 것을 의미한다. 이미 만들어져 있는 시스템에 맞춰 업무 프로세스를 짜게 하지만, 다른 업체에 모든 관리 책임을 넘길 수 있기 때문에 많은 언론사들이 이 방법을 택하고 있다. 특히 온라인 매체일 경우 해킹 공격부터 트래픽 비용 절감이나 사이트 렌더링 속도 개선에 광고 배치까지, 기자의 ‘전화 한 통’이면 모든 것이 해결된다.

하지만 외주 업체 솔루션을 고쳐다가 편집 규칙을 만드는 일부터, 광고를 더 붙이거나, 다른 기사를 메인 특정 영역에 배치하는 일까지, 소소한 수정사항을 덧붙이고자 한다면 병목이 생겨난다. 국내외를 둘러보았을 때 현존하는 언론사 외주 업체는 대부분 ‘솔루션 납품업체’, 즉 SaaS 업체이지 ‘언론사를 위한 아웃소싱 개발 업체’, 즉 파트너사가 아니다. 그러니, 언론사의 업무 프로세스와 사고 방식, 영향력은 어디까지나 솔루션 안에 갇혀버리고 만다. 붕어빵처럼 똑같은 언론사 사이트가 마구 생겨난 것도 이 덕분이다. 그 사이 광고수익이 나날이 줄어들고, 클릭바이트의 유혹이 거세지고, AI가 트래픽을 꿀꺽하고, 포털로부터의 트래픽은 점차 줄어든다. 책임이 외주 업체에게 있으니 서버에 전기만 꽂혀 있으면 별 일이 생기지 않겠지만, 별 일을 만들지 않아야 하는 것도 외주 업체로의 위탁이라는 선택지이다.

해외 어느 매체가 기가 막힌 무언가를 만들었다는데 그럼 우리도 해볼 수 없을까? 외주 솔루션을 쓰고 있을 땐 ‘우린 안돼’ 라며 포기하기 십상이다. 그런 경험들이 반복되다 보면 조직 내 ‘패배주의’와 ‘보신주의’가 점차 곰팡이처럼 증식할 것이다.

수많은 페르소나

CMS는 소위 ‘사용자 페르소나’를 규정지음에 있어 단순히 ‘기자’나 ‘에디터’만 고려할 수 없다. 종이신문을 발행하는 언론의 경우, 대략 다음과 같은 페르소나가 동시에 존재한다.

기사를 쓰는 기자.
기사를 송고한 뒤 온라인 편집을 손보는 에디터/편집기자.
오프라인 조판을 손보는 조판기사/편집기자.
그리고, 기사를 검토하는 데스크.

기자도 다 같은 기자가 아니다.

출입처를 오가는 기자.
통신사 기사를 소싱해오는 기자.
외신을 살펴보는 국제부 기자.
클릭바이트 기사를 써야하는 기자 등등.

CMS 구축에는 이 모든 구성원들의 제각각의 업무 프로세스를 결정짓는 이가 반드시 필요하다. 하지만 언론사 데스크가 업무 프로세스, 즉 일하는 방식까지 설계하는 경우는 그리 많지 않다. 일하는 방식은 대개 구성원 전체의 동의를 품고 수십년간 바뀌지 않은 관성으로 존재할 때가 많다. 팀이 협의제 거버넌스일수록 업무 프로세스를 고치고자 하는 도전은 꽤나 많은 반발을 불러온다. 언론사 경영진이 기자의 취재 프로세스를 정하는 것도 미묘한 지점에 있다. 취재 조직의 독립성을 해치는 것이기 때문이다. 그러니 많이들 해온 것처럼 모두가 비슷한 발언권과 비슷한 결정권을 쥔 채로 업무 프로세스를 설계하려 들고, 어느 누구도 결정을 하지 못하는 상황이 벌어진다. 회의실에 개발자, 기획자, 기자 대표, 책임자 정도로 4명이 들어와야 할 회의에 매번 10여명이 들어와 시간만 허비하더라는 언론사 K의 이야기는 개발 업계에도 널리 알려진 일화이다.

조직의 운영은 민주적 의사 결정이 중요하겠으나, 프로젝트 진행에 있어서는 민주적 의사결정이 적합하지 않을 때가 많다. 개발 커뮤니티에서는 종종 ‘자비로운 독재자’ 라거나 ‘리더십’ 같은 표현을 쓴다. 때로는 페르소나에 해당되는 저마다 누군가 결정을 내리고 일을 진행시킬 수 있도록 권한을 위임해줄 필요도 있다. IT직종에서 흔히 하는 말이 있다. ‘논의는 민주적으로, 결정은 권위있게’.

그 프로젝트는 왜 산으로 갔을까

업무 프로세스를 재구성하는 일은 타성에 젖어있는 조직일수록 벽에 부딪히기 쉽다. 저마다 자기가 편해지는 프로세스로의 변화를 희망하기 때문이다. 그러면서도 ‘반복 업무는 기계에게 맡기자’는 명제조차 합의되지 못한 곳들이 많다. CMS 개발에 몇 년째 연거푸 실패했다는 언론사 N의 사례를 보자.

[AS-IS]

언론사 N에는 로이터, AP 등의 해외 통신사의 스톡 사진을 A 웹하드로 관리하는 사진 담당 직원이 있다.
사진 담당 직원은 편집기자의 요청을 받으면 기사에 적합한 이미지를 찾아다가 기자들이 쓰는 B 웹하드에 옮겨다 주기로 정해져 있다.
편집기자는 B 웹하드에 올라온 이미지를 다운받아 CMS에서 기사에 첨부한다.
편집기자는 사진 담당 직원에게 매번 사진을 부탁하는 것이 번거롭고 불편했다. 사진 담당 직원이 고압적이었기 때문이다.
하지만 A 웹하드의 권한은 사진 담당 직원에게만 있다.

[TO-BE]

그래서 편집기자가 새 CMS에서는 편집기자가 직접 사진 담당 직원을 거치지 않고 로이터, AP의 스톡 사진을 쓰고 싶다고 건의한다.
그랬더니 사진 담당 직원이 나의 일자리를 빼앗느냐며 버럭 화를 낸다.
이 사진 담당 직원만 화를 낸다면 상관이 없었을 것이다. A B 웹하드를 관리해오던 기술직 직원까지 덩달아 나타나 나의 일자리를 빼앗느냐며 같이 화를 내기 시작한다.

[RESULT]

편집 기자는 결국 이전 프로세스를 그대로 유지하겠다며 포기한다.

이 논의에서 만약 “많은 업무를 자동화하여 반복 업무를 줄이고, 더 유익한 일에 사람을 쓰자”는 공동 목표가 있었다면 편집 기자가 제안을 포기하지 않아도 되었을 것이다. 세 명의 인력을 좀 더 유익한 일에 배치하고, 편집기자의 일도 더 수월해질 수 있었을 것이다. CMS 설계란 조직이 일하는 방식을 설계하는 일이기 때문에, 조직 구성원 모두가 행복해지고 회사도 행복해지며 제호의 권위가 더 세워지는 것을 목표로 해야한다. 공유 목표가 없을 땐 늘 저마다의 방어적 논리가 논의를 잠식해버린다.

언론사의 CMS는 기자들이 매일 기사를 쓰고 송고할 때마다 끊임없이 마주해야하는 도구이다. 조직에 따라선, 기사에 대한 피드백을 주고받는 커뮤니케이션 도구이기도 하다. 그러니, 구성원의 업무 그 자체를 정의해주고, 교통정리해주며, 필요하다면 재배치를 해줄 수 있는 사람이 CMS 설계에 있어 책임을 지고 함께해야만 한다. 혹은 프로젝트 리드가 책임과 권한을 위임받을 수 있어야 한다.

프로젝트 규모로 치면 은행이 차세대 시스템을 교체하는 것 만큼이나 CMS도 복잡한 프로젝트라 할 수 있다. 그런데 이를 IT 제품을 수시로 만들어온 조직이 아닌 곳에서 직접 만들어보려고 한다면 어려움을 겪는 건 당연한 일이다. 제품 개발 프로젝트는 회식을 열 음식점을 물색해서 예약하는 정도의 간단한 일이 아니다. 이해관계로 얽혀있는 많은 사람들의 의견을 모으고, 정리하여, 합의를 도출하고, 이후 Action Item까지 만들어다가 점진적으로 추진하는 것이 ‘제품 개발’ 프로젝트이다. 이 프로젝트를 이끌어 마무리짓는 것은 기자만큼이나 독특한 전문 영역에 해당한다. 그러나 상당수 언론사들은 이 중요한 업무를 기자의 부업 정도로 ‘겸직’하게 한다. 일단 여기서부터 문제가 생겨난다.

개발자를 영입하는게 아니라 ‘기자가 개발자가 되어야 하고 PM이 되어야 한다’고 믿는 언론사들도 꽤나 많이 있다. 그러나 사람은 쉽게 고쳐지지 않기 마련이고, 저마다 능수능란한 고양이 손을 대신 흉내내어봤자 아귀가 맞지 않게 된다. 일이 왜 진전이 되지 않는 걸까? 원인이 우리에게 있는건 아닐까? 라고 생각해보아야 한다. 취재하고 마감하듯 프로젝트를 이끌다간 프로젝트가 쉽게 산으로 간다. 프로젝트 진행은 다양한 방법론이 존재하고, 축적된 경험이 있어도 잘 될까 말까 하는 분야이다. 그러니 프로젝트 진행은 프로젝트 전문가에게 맡겨야 한다. IT 업종에는 프로젝트를 산으로 가지 않게 하는 프로젝트 매니저, 프로덕트 매니저 라는 직종이 존재한다. 왜 그런 직업이 있는지 생각해보자.

그랜드 오픈은 왜 항상 망하는가?

“그랜드 오픈은 언제나 망한다”. 기획자들과 내가 늘 주고받는 이야기이다. 그랜드 오픈은 철두철미하고 일사분란하게 움직이는 공공SI업체에서나 가능한 일이다. 실패에 대한 인사상의 책임과 감사에 대한 공포가 명확히 작동하는 곳이라면 납품일을 정하고서 프로젝트를 진행시켜도 좋다. 하지만 좋은 게 좋은 거라며 굴러가는 회사라면? 이전에도 프로젝트가 실패한 적이 있었지만 별 일 없이 넘어갔었던 회사라면? ‘그랜드 오픈’을 택해서는 절대 안된다. 특히나 이 프로젝트가 누군가 높으신 분의 성과로 귀결되어야 한다면 ‘그랜드 오픈’을 시도하려는 힘이 매우 강력하게 작용할 것이다. 제품 개발은 그 유혹에서 벗어나야 한다.

일이 되게 하는 개발업계의 노하우가 있다. 하고자 하는 일을 잘게 나누고, 현실적인 일정 산출로 예측 가능한 개발을 하는 것이다. 언론사가 만들고자 하는 CMS는 본질적으로 내부 구성원과 외부 독자를 모두 고려해야하는 제품이다. 취재-발행 프로세스와는 다른 방법으로 제품을 만들어야 한다. 마감만 지킨다고 일이 돌아가지 않는다. 디지털 제품은 디지털 제품이 만들어지는 방식을 따르는 것이 좋다.

그게 가능하겠는가? 라고 물어보면 기자들 열이면 열 손사래를 친다. 새 CMS가 오픈이 안되는 이유를 사실 구성원들은 이미 알고 있을지도 모른다. 부디 ‘이 분과 일을 하니 일이 수월하게 되고 있어요’ 라는 경험을 한번쯤은 해보기를 권해본다. 방송사는 한국의 경우 복잡한 역사가 있다보니 그런 경험을 지닌 이들이 많긴 하나, 신문사의 경우에는 과연 그런 경험이 있는 이가 있을지부터 의문이다.

일이 되게 하려면

제품 개발 프로젝트의 실패는 ‘일이 되게 하는 이’의 책임이 방기되거나 권한이 모호해진 결과일 때가 많다. 날뛰는 스펙, 정리되지 않는 정책, 비용을 고려하지 않고 보여주기식 최신 유행의 선택이 프로젝트를 실패하게 하는 주범이다. 특히나 책임자의 우유부단은 프로젝트를 실패하게 하는 주된 원인이다. 사주가 지배하는 언론사라 일을 실패로 만들어도 어느 누구도 책임지지 않는 지배구조, 개발자는 쓰고 버리면 된다며 기술적 최적화 기회를 놓쳤다가 비용 폭탄을 맞는 조직문화도 한 몫 한다. 무엇보다도 기자가 개발도 알고 PM도 해야 한다’는 식의 겸직 구조는 전문성을 무시한 처사이다. IT 업계에 PM/PO라는 직군이 왜 별도로 존재하는지 고민해 봐야 한다.

CMS 프로젝트가 또 엎어졌는가? 그렇다면 기술력 이전에 우리 조직을 ‘다음 단계로 나아가게 하겠다는 의지’가 있었는지, 독자의 신뢰를 얻기 위해 업무 도구에 그만큼의 절실함을 담았는지 스스로 자문해 보아야 한다. 어떻게 하면 구성원=저널리스트를 빛나게 할지, 어떻게 제호의 가치를 돋보이게 할지에 대한 고민이 없는 프로젝트는 결국 무기력한 결과만 남길 뿐이다. 그만한 절실함을 가진 곳이 있을까? 나는 잘 모르겠다.