요약
Drupal 창시자는 Drupal이 평판보다 훨씬 나아졌다며 그 인식 차이를 좁히는 것이 최우선 과제라고 했습니다.
Drupal을 만든 드리스 바위타르트가 9월 DrupalCon 로테르담 2026 기조연설 내용을 블로그에 정리했습니다. 2년여 전 시작한 Starshot 프로젝트가 Drupal CMS로 결실을 맺은 만큼, 이제는 새 기능보다 알리는 일에 힘을 쏟겠다고 밝혔습니다.
왜 중요한가
- Drupal을 AI가 일을 처리하는 동안 권한과 규칙을 지키게 하는 통제 계층으로 자리매김하려는 전략입니다.
- 창시자가 직접 혁신보다 홍보가 급하다고 인정해, 프로젝트의 우선순위가 바뀌었음을 보여 줍니다.
- React 코드 컴포넌트와 헤드리스(콘텐츠 관리와 화면 구현을 분리하는 방식) 지원으로 Drupal 관례를 몰라도 쓰기 쉬워졌습니다.
핵심 내용
- AI 비서에게 페이지 게시 중단을 시키면 Drupal은 사람이 할 때처럼 편집자 권한과 게시 규칙을 확인합니다.
- Tool 모듈은 게시·사용자·미디어·설정 같은 기존 기능을 AI 비서나 다른 소프트웨어가 MCP(AI가 외부 도구를 쓰는 연결 규약)로 찾아 쓰게 합니다.
- 맷 글레이먼이 만드는 실험 기능으로 사진 앨범 모듈에 필요하던 코드 약 1,000줄이 PHP 속성 20개 남짓으로 줄었습니다.
- Drupal Canvas 페이지 빌더가 다국어를 지원하고, Canvas Headless로 Next.js나 Astro 같은 프레임워크와 함께 쓸 수 있습니다.
- 6월에 시험한 AI 코딩 에이전트조차 Drupal CMS를 몰라서, 외부 강연·기고·사례 소개도 기여 크레딧으로 인정하는 홍보 프로그램을 시작합니다.
HN 반응
- 2010년대 잦은 대규모 재작성에 데어 떠난 개발자가 많아 나쁜 평판은 자초한 것이라는 지적이 많았고, 지금은 LLM과 쓰기 좋을 만큼 나아졌다는 반론도 나왔습니다.
- 에이전트로 직접 만들면 CMS가 필요 없다는 주장에는, 대규모 조직의 관리 체계와 검증된 내부 API가 여전히 쓸모 있다는 반박이 이어졌습니다.
Opus 5.5가 끔찍한 레거시 Drupal 앱을 제가 선호하는 스택으로 네 시간 만에 처음부터 다시 짰습니다. 방치된 플러그인 처리, 말이 되는 데이터베이스 스키마로의 이전, 그리고 제가 참여하지 않았던 Drupal 6-7-8 업그레이드 중 어딘가에서 망가져 잘려 나간 셀들을 Drupal 4 백업에서 복구하는 콘텐츠 보정까지 모두 포함해서요.
Drupal에 대해 알아야 할 모든 것을 알고 싶다면 사이트맵을 둘러싼 커뮤니티 논의를 한번 보세요. 복잡해진 데는 진짜 이유들이 있긴 하지만, 자기 URL 목록 하나 만들어 내지 못해서 수천 명을 어리둥절하게 만드는 CMS라니, 대단한 업적입니다.
선호하는 스택이 뭐였나요?
2010년대에 Drupal 때문에 데인 개발자가 많습니다. "The drop is always moving"(드롭은 늘 움직인다)라는 말은 이제 사라졌을지 몰라도, 안전한 사이트만 원했을 뿐인데도 몇 년마다 사이트 템플릿을 대대적으로 다시 짜고 플러그인 생태계를 다시 구축해야 하는 건 감당하기 벅찼습니다. 게다가 프로젝트에 기여했거나 플러그인을 만든 사람의 말만 들으려는 커뮤니티까지 더해져, 나쁜 평판은 자초한 것이었습니다. 저는 전문 웹 개발자는 아니지만, 그 시기에 저처럼 Drupal을 포기한 전문가를 몇 명 압니다. 제 비영리단체는 지금 Wordpress로 돌아가는데, 완벽하진 않아도 (유료 플러그인으로) 유료 회원 1,600명을 감당하고 하루하루 그냥 잘 돌아갑니다. 유지보수 부담이 훨씬 적다 보니 제 개인 사이트도 Drupal 시절보다 훨씬 정교해졌습니다. 이 평판을 되살리려면 엄청난 노력이 필요할 겁니다. 많은 애정이 사라졌으니까요.
저는 2010년대에 중견 기업들을 위해 Drupal, WordPress 등으로 만든 웹사이트를 유지보수했습니다.
Drupal은 유지보수, 하위 호환성, 반응형 대응(코드와 개발 측면에서)이 정말 엉망이었어요.
사람들이 WP로 더 많이 몰리기 시작했고, 사람들이 떠나가면서 Drupal 문서는 최신 상태가 아니게 됐습니다.
지금 시점에서도 Drupal에 대한 제 생각을 바꿀 건 아무것도 없습니다. 특히 요즘 같은 시대에는요. 차라리 직접 만들거나 WP를 고쳐 쓰는 게 낫습니다.
글에서 "light-years ahead"라고 하는 건 틱톡 인플루언서가 하는 말처럼 들립니다.
지금은 정말 그 어느 때보다 훨씬 좋아졌습니다.
사람들이 왜 데였는지는 충분히 이해합니다. 앞으로 나아가는 방향이 사용자, 사이트 빌더, 개발자를 여정에 함께 데려가는 쪽이기보다는 엔터프라이즈가 필요로 하는 것을 제공하는 쪽이었으니까요.
그리고 그 중심에 있던 엔터프라이즈 중 하나가 Acquia였죠. Dries가 Drupal 기반 컨설팅 서비스를 제공하려고 세운 조직입니다.
그렇긴 해도, 지금은 정말 아주 좋은 제품이고 LLM이 놀랄 만큼 잘 다루는 제품이기도 합니다.
풍부한 문서, 설정보다 관례, 그리고 API 중심이라는 Drupal의 성격은 LLM의 도움을 받기에 아주 잘 맞습니다.
WordPress가 보안, 커뮤니티, 일관성, 코드 품질, 유지보수성 면에서 얼마나 끔찍한지 생각하면, Drupal이 그렇게 많은 호감을 잃은 건 정말 안타까운 일이라고 생각합니다.
해결책이 뭔지는 잘 모르겠지만, 이 글을 읽는 분은 누구든 Codex나 Claude Code로 한번 써 보시길 권합니다. 제 말이 무슨 뜻인지 아시게 될 겁니다.
지금 시점에서 중요한 건 사용성이나 다른 제품보다 얼마나 좋으냐, AI로 얼마나 더 많은 걸 할 수 있느냐가 아닙니다.
Drupal은 사람들이 그걸로 얼마나 돈을 벌 수 있는지, 하다못해 얼마나 아낄 수 있는지를 마케팅해야 합니다. 팀에 뒷받침할 데이터가 있다면 ROI가 내세우기 좋은 KPI입니다.
Rural은 호감을 거의 다 잃었고, 그럴 만한 이유가 있었어요. 확장 기능 생태계도 어설프기 짝이 없는 쓰레기장이었죠. 그동안 WordPress는 사용자 의견을 듣고 관리를 훨씬 쉽게 만들면서 번창하고 있었고요.
Drupal이 지금이 역대 최고라고 해 봐야 별 의미 없는 말입니다. 운영을 잘못한 여파로 기여자 커뮤니티가 작아서 여전히 확장하기가 쉽지 않거든요.
나아졌기를 바라지만, 평판은 몇 번이고 자초한 겁니다.
안타깝지만 WordPress는 블로깅 엔진 이상이었던 적이 거의 없습니다.
확장성이 아주 좋습니다. WooCommerce는 말할 것도 없고, CiviCRM, Give 등 정교한 확장 기능을 많이 한번 보세요. 복잡한 업그레이드를 앞둔 Drupal 기반 업체들이 WordPress로도 필요한 걸 다 할 수 있다는 걸 알게 되는 경우가 많았습니다.
WooCommerce 사용자들은 전부 동의하지 않을걸요.
뭐, dri.es가 Drupal 창시자니까요 :D
네, 그게 양날의 검이죠. Drupal이 오늘날 할 수 있는 일을 하게 된 건 기반을 계속 새로 다졌기 때문이지만, 동시에 그런 움직임이 그 과정에서 많은 고통을 준 것도 사실입니다. 한편 "에이전트한테 다시 만들라고 하면 되지"라는 세상에서는 그런 변화를 감당하기가 훨씬 쉬워집니다. 모두가 그렇게 받아들여야 하는 표준까지는 아니더라도요.
저는 "설정은 가장 중요한 것이 아니라 유일한 것이다"라고 생각하는 편인데, 올해 초에 우리 쪽 Drupal 작업을 하면서 최신 Drupal의 설정 방식에 큰 존경심이 생겼습니다.
노력과 시간 면에서는 더 쉬워지겠지만, 그래도 비용이 들고 여전히 발목을 잡습니다.
에이전트로 잡다한 정리 작업을 훨씬 쉽게 할 수 있다고 해서 그런 일을 더 하고 싶어지는 건 아닙니다. 애초에 핵심은 제 시간과 에너지와 생각을 더 가치 있고 흥미롭고 부가가치를 만드는 일에 쓸 수 있게 풀어 주는 거니까요. 집에서나 회사에서나 제 마음가짐은 그렇습니다.
오픈 소스든 상용이든 프레임워크나 라이브러리를 만들면서, 에이전트 기반·AI 네이티브 개발 덕에 사용자가 에이전트로 알아서 고치면 되니 호환성을 깨는 변경과 잦은 변동을 더 마음대로 해도 된다고 생각한다면, 안타깝지만 나쁜 소식이 있습니다. 그 칼날은 양쪽 모두를 벱니다.
계속 바꾸고 망가뜨릴 수 있다면, 저도 질려서 뜨거운 돌덩이처럼 당신네 쓰레기를 내던지고 직접 만들 수 있습니다. 그리고 실제로 그럴 겁니다.
저는 쓰던 프레임워크에 질려서 개인 사이트를 처음부터 다시 만들었는데, 시간이 별로 걸리지 않았습니다. 오히려 예전에는 너무 귀찮아서 못 했던 개선 작업을 전부 하느라 더 오래 걸렸죠. 그래서 배포 규율을 다시 익혀야 하긴 하지만, 괜찮습니다.
회사에서도 마찬가지입니다. 데이터베이스 엔진 이전 같은 큰 스택 변경도 훨씬 쉬워졌어요. 물론 여전히 체계적이고 규율 있게 해야 하고, 오히려 에이전트 때문에 많은 엔터프라이즈 환경에서는 그게 그 어느 때보다 중요해졌다고 생각합니다. 그래도 훨씬 쉬운 건 사실입니다. 예전 같으면 몇 주, 몇 달 걸렸을 프로젝트가 여기저기서 며칠, 몇 주 만에 끝나는 걸 보고 있어요. 정신없는 시대입니다.
에이전트가 알아서 만들 수 있는데 Drupal을 왜 쓰나요?
에이전트가 무언가를 만들 수는 있지만, 우리 인간에게 다행히도 "올바른" 것이 만들어지도록 챙기는 일의 여지는 여전히 있으니까요.
예컨대 에이전트가 책을 쓸 수 있는데 왜 사람이 쓴 책을 읽을까요? 인쇄할 수 있는 그림을 왜 돈 주고 살까요?
오픈 소스와 프레임워크의 장점 하나는, 오랜 시간 실제로 이해관계를 걸고 임한 많은 사람의 검증된 결정들로 이루어져 있다는 것입니다. 에이전트가 문제를 해결해 주는 경우가 많고, 요청받은 대로라면 올바르게 해결하겠지만, 더 나은 답은 대개 한 걸음 물러서서 근본을 따져 보고, 다른 관점을 확인하고, 가정에 의문을 던지고, 의견을 가질 때 나옵니다.
에이전트에게 가드레일(하!) 역할을 하는 프레임워크가 있는 건 여전히 아주 강력합니다. 제 경험상 Rails + Claude는 서로 아주 잘 맞물려 돌아가고, 완전히 처음부터 만드는 것에 비해 단점이 사실상 없습니다.
저라면 "인증 기능 만들어, 실수하지 말고"라고 시키기보다는 에이전트에게 인증 gem을 가리키며 그걸 쓰라고 하겠습니다.
그건 에이전트를 drupal이 아니라 symfony나 laravel 쪽으로 향하게 하자는 논거 아닌가요?
저는 부모 댓글이 프레임워크를 쓰느냐, 전부 처음부터 쓰느냐를 말한 거라고 이해했습니다. 꼭 Drupal, Laravel, Symfony 얘기는 아니고요. Drupal은 스레드 제목이라 나왔을 뿐입니다. 저라면 그 말을 어떤 프레임워크에든 적용하겠습니다.
회사에서 PHP는 보안 악몽이라는 얘기를 제가 딱 한 번 입 밖에 내도록 스스로 허락한 적이 있는데, 바로 다음 날 아침에 출근해 보니 유일한 PHP 지지자가 자기가 맡은 drupal 인스턴스가 해킹당해 변조되는 바람에 패치를 하고 있더군요. 타이밍 때문에 제가 범인처럼 보일 수도 있었고 저는 아직 신입이었기에, 우쭐해하지 않으려고 애썼습니다.
하지만 그 사람은 그 뒤로 PHP 얘기를 다시는 꺼내지 않았고, 저는 그게 아주 좋았습니다.
신뢰가 걸린 상황에서는 일종의 불문율 같은 원죄 개념이 있습니다. 누군가 엄청난 보안 실수를 한 번 저지르면, 그것이 우발적 사고가 아니라 만연한 문제가 아니라고 믿을 수 없다는 것이죠. "썩음은 머리에서 시작된다"가 사실이라면, 아무리 손을 봐도 어떻게 그걸 다시 믿을 수 있겠습니까?
저는 Drupal이 적용한 보안 패치를 살펴봤는데, PHP를 읽을 줄 아는 건 아니지만 패치되지 않은 코드의 다른 두 곳에서 똑같은 안티패턴을 찾았다고 확신했습니다. 한 시간만 봤는데도요. 그 뒤로 수년간 성의 없는 CERT 권고문이 계속 나왔습니다. 사용자 입장에서 매몰 비용에 깊이 빠져 있지 않다면, 이건 밑 빠진 독에 물 붓기로 보입니다. 합리화를 해야만 좋은 거래처럼 보일 뿐입니다.
코드베이스를 Symfony로 바꿨을 때만큼 나쁘진 않지만, Drupal 프로젝트는 핵심 프레젠테이션 시스템을 새 Canvas 도구에 밀려 사실상 버렸고, 나머지 코어와의 호환성은 뒷전인 듯합니다. 그래서 이제 서로 경쟁하는 표시 설정 방식이 최소 세 가지인데, 함께 잘 동작하지도, 단독으로 온전히 동작하지도 않습니다.
전적으로 Drupal의 평판에 걸맞은 상황입니다. 제대로 한 번에 하질 못했고, 이제 진지한 Drupal 팀들은 생태계에서 어느 쪽으로 가야 할지 모릅니다.
핵심 프레젠테이션 시스템을 완전히 버린 건 아닙니다. Dries는 그랬을지도 모르지만, 그 사람이 Matt만큼(이었던가요?) 독재자는 아니니까요. 혼란스럽다는 데는 동의하고 저도 Canvas가 마음에 들지 않지만, 어차피 저는 쓰지 않습니다.
지금도 symfony인데요…
아직도 Drupal이 필요한 사람이 있나요? Claude Code로 온갖 종류의 소프트웨어를 그냥 만들 수 있잖아요.
저는 Drupal이든 그 비슷한 것이든 어떻게 살아남을지 모르겠어요. 이런 종류의 소프트웨어는 2026년이 아니라 2006년에 맞는 물건 같아요.
Claude로 빠르게 만드는 건 훌륭하지만, 규모가 일정 수준을 넘거나 통제된 워크플로와 감독이 필요해지면 어떤 형태로든 CMS를 원하게 될 겁니다. 그때가 되면 혼자 알아서 해결하거나, Drupal 커뮤니티가 수십 년간 이런 문제들을 다뤄 오며 충분히 논의하고 깊이 고민해 쌓은 해법들 위에 만들거나 둘 중 하나입니다.
그건 이제 필요 없습니다. 한 사람이 완전한 자체 솔루션을 유지보수할 수 있고, 변경과 조정도 쉽게 할 수 있어요.
LLM이 짠 코드의 장기적인 유지보수성에 대해 결론을 내릴 만큼 시간이 충분히 지나지 않았습니다.
AI 에이전트가 설계 결정(기술적이든 아니든)을 스스로 내리게 해 보신 적 있나요? 제 경험상 좋은 결과를 얻으려면 여전히 원하는 게 뭔지 제대로 이해하고 있어야 해요. 잠재적인 문제점, 보안 구멍, 사용성 문제 등을 전부 깊이 이해하고 있어야 하죠. AI로 CMS를 개발하는 건 여전히 상당한 규모의 프로젝트입니다.
그래서 바이브 코딩이 등장했죠.
Drupal은 사이트가 수백 개, 사용자가 수천 명이고 어느 정도 조율된 여러 개발 팀이 있는 대규모 조직에서 씁니다. 내부 API가 아주 탄탄하게 자리 잡혀 있어서 사실 에이전트 코딩에 아주 좋은 대상이기도 하고요. 시대착오처럼 느껴질 수 있는 건 맞지만, 그 용도 중 일부라도 대체할 수 있는 프로젝트는 거의 없다고 생각합니다. CMS계의 B-52죠.