G7은 5년, 10년 뒤에도 사용되는 CMS가 될 수 있을까?
앞선 글에서 G7을 직접 설치하거나 소스를 살펴본 사람이 얼마나 될까 하는 의문을 던졌다.
여러 글에 달린 의견을 보면서 생각이 조금 더 이어졌다.
G7이 기술적으로 잘 설계된 CMS가 되는 것과 앞으로 5년, 10년 동안 계속 사용되는 CMS가 되는 것은 같은 문제일까?
아마 그렇지는 않을 것 같다.
CMS는 한번 만들어 배포하는 것으로 끝나는 소프트웨어가 아니다.
사이트가 만들어지고,
사용자가 생기고,
모듈과 플러그인이 만들어지고,
새로운 환경에 대응하고,
오래된 기능과의 호환성을 유지하면서 계속 변화해야 한다.
그래서 CMS는 만드는 것보다 유지하는 시간이 훨씬 긴 소프트웨어인지도 모르겠다.
G5가 지금까지 사용되는 이유도 단순히 기술적인 구조 때문만은 아닐 것이다.
오랫동안 사용해 온 사람들이 있고,
수많은 사이트가 운영되고 있고,
테마와 플러그인, 스킨이 쌓여 있고,
그누보드로 홈페이지를 제작해 수익을 얻는 개발자와 제작자도 있다.
문제가 생겼을 때 검색하면 오래전 질문과 답변이라도 찾을 수 있고,
비슷한 문제를 경험한 사람도 찾을 수 있다.
그 시간 동안 쌓인 것 전체가 하나의 생태계가 된 셈이다.
반면 G7은 이제 그 생태계를 만들어 가야 하는 단계에 있는 것 같다.
Laravel 기반의 구조,
modules / plugins / templates를 통한 확장,
API와 UI의 분리 등은 앞으로 확장하기 좋은 기반이 될 수도 있다.
하지만 좋은 구조가 있다고 해서 자연스럽게 사용자가 생기는 것은 아니다.
앞선 글의 댓글에서 한 분이 아주 현실적으로 이야기했다.
“5 개발하면 아직은 먹고살게 해준다.
7 개발하면 먹고 살수가 없다.”
기술적인 평가와는 별개로 현재 G5에는 시장이 있고, G7에는 아직 시장이 충분히 형성되지 않았다는 의미로 들렸다.
이 차이는 생각보다 클 수 있다.
개발자가 G7을 익히고 확장을 만드는 데 시간을 사용하려면 그것을 사용할 사람이 있어야 한다.
확장이 많아지면 사용자가 늘어날 수 있지만, 사용자가 적으면 확장을 만드는 개발자 역시 늘어나기 어렵다.
CMS 생태계가 처음 만들어질 때 생기는 문제일 것이다.
접근성도 중요해 보인다.
앞선 글의 댓글에서 G7 메인테이너분이 일반 호스팅 환경에서 설치하고 운영할 수 있도록 개선하고 있는 상황을 구체적으로 알려주셨다.
Composer를 실행할 수 없는 환경,
PHP CLI,
SSE,
심볼릭 링크,
disabled_functions,
크론탭 같은 문제들이다.
개발자 입장에서는 해결할 수 있는 문제일지 몰라도 일반적인 홈페이지 제작 환경에서는
이런 작은 장벽 하나가 “한번 사용해 볼까?”와 “그냥 G5를 쓰자”를 나누는 경계가 될 수도 있다.
기술적으로 더 좋은 구조를 만드는 것과 쉽게 시작할 수 있게 만드는 것은 서로 다른 문제인 것 같다.
그리고 한번 사용하게 만드는 것과 계속 사용하게 만드는 것도 다르다.
CMS가 오래 살아남으려면 코어를 계속 개발하는 것만으로는 어려울 것이다.
문서가 쌓이고,
사용 사례가 생기고,
모듈과 플러그인이 만들어지고,
질문과 답변이 축적되고,
실제 사이트가 운영되고,
그 안에서 누군가는 수익도 얻을 수 있어야 한다.
그래야 새로운 사용자가 들어올 이유가 생기고,
개발자가 확장을 만들 이유도 생긴다.
생각해 보면 이것은 앞서 적었던 “무엇을 만들지 않을 것인가”라는 문제와도 연결되는 것 같다.
G7에 기능을 계속 추가하는 것만이 발전은 아닐 수 있다.
이미 만들어진 기능을 안정시키는 일,
설치를 쉽게 만드는 일,
문서를 정리하는 일,
확장들이 서로 충돌하지 않게 규칙을 만드는 일,
실제 사용 사례를 만드는 일도 새로운 기능 하나를 추가하는 것만큼 중요할 수 있다.
특히 CMS는 오늘 얼마나 많은 기능을 가지고 있는가보다
몇 년 뒤에도 기존 사이트와 확장이 계속 동작할 수 있는가가 더 중요한 소프트웨어일지도 모르겠다.
G7이 현재 위치까지 온 것만으로도 하나의 성과라고 생각한다.
새로운 구조를 설계하고 실제 동작하는 CMS로 만들고,
그 위에서 모듈과 플러그인을 만들 수 있는 단계까지 오는 것도 쉬운 일은 아닐 것이다.
하지만 CMS는 여기서부터가 더 어려울 수도 있다.
코드를 만드는 것에는 어느 정도 끝이 있을 수 있지만,
생태계를 만드는 것에는 명확한 끝이 없기 때문이다.
5년 뒤에도 새로운 사이트가 G7으로 만들어지고,
10년 뒤에도 지금 만든 사이트를 업데이트할 수 있고,
그때도 누군가 새로운 모듈과 플러그인을 만들고 있다면 그 CMS는 살아 있다고 할 수 있을 것이다.
결국 G7의 성공을 판단하는 기준은 최신 기술을 얼마나 사용했는가도,
기능이 얼마나 많은가도 아닐지 모른다.
사람들이 실제로 사용하고,
그 위에서 무언가를 만들고,
그것을 계속 유지할 이유가 있는가.
그것이 더 중요한 기준일 것 같다.
G7은 5년, 10년 뒤에도 사용되는 CMS가 될 수 있을까?
지금은 그 답을 알 수 없다.
다만 앞으로 G7에서 무엇을 더 만들 것인가만큼,
어떻게 해야 사람들이 들어오고, 만들고, 남아 있게 할 것인가.
이 질문도 함께 고민해야 할 시점이 아닐까 하는 생각에 몇 자 적어 본다.
- 💫Glitter Gim
여러 글에 달린 의견을 보면서 생각이 조금 더 이어졌다.
G7이 기술적으로 잘 설계된 CMS가 되는 것과 앞으로 5년, 10년 동안 계속 사용되는 CMS가 되는 것은 같은 문제일까?
아마 그렇지는 않을 것 같다.
CMS는 한번 만들어 배포하는 것으로 끝나는 소프트웨어가 아니다.
사이트가 만들어지고,
사용자가 생기고,
모듈과 플러그인이 만들어지고,
새로운 환경에 대응하고,
오래된 기능과의 호환성을 유지하면서 계속 변화해야 한다.
그래서 CMS는 만드는 것보다 유지하는 시간이 훨씬 긴 소프트웨어인지도 모르겠다.
G5가 지금까지 사용되는 이유도 단순히 기술적인 구조 때문만은 아닐 것이다.
오랫동안 사용해 온 사람들이 있고,
수많은 사이트가 운영되고 있고,
테마와 플러그인, 스킨이 쌓여 있고,
그누보드로 홈페이지를 제작해 수익을 얻는 개발자와 제작자도 있다.
문제가 생겼을 때 검색하면 오래전 질문과 답변이라도 찾을 수 있고,
비슷한 문제를 경험한 사람도 찾을 수 있다.
그 시간 동안 쌓인 것 전체가 하나의 생태계가 된 셈이다.
반면 G7은 이제 그 생태계를 만들어 가야 하는 단계에 있는 것 같다.
Laravel 기반의 구조,
modules / plugins / templates를 통한 확장,
API와 UI의 분리 등은 앞으로 확장하기 좋은 기반이 될 수도 있다.
하지만 좋은 구조가 있다고 해서 자연스럽게 사용자가 생기는 것은 아니다.
앞선 글의 댓글에서 한 분이 아주 현실적으로 이야기했다.
“5 개발하면 아직은 먹고살게 해준다.
7 개발하면 먹고 살수가 없다.”
기술적인 평가와는 별개로 현재 G5에는 시장이 있고, G7에는 아직 시장이 충분히 형성되지 않았다는 의미로 들렸다.
이 차이는 생각보다 클 수 있다.
개발자가 G7을 익히고 확장을 만드는 데 시간을 사용하려면 그것을 사용할 사람이 있어야 한다.
확장이 많아지면 사용자가 늘어날 수 있지만, 사용자가 적으면 확장을 만드는 개발자 역시 늘어나기 어렵다.
CMS 생태계가 처음 만들어질 때 생기는 문제일 것이다.
접근성도 중요해 보인다.
앞선 글의 댓글에서 G7 메인테이너분이 일반 호스팅 환경에서 설치하고 운영할 수 있도록 개선하고 있는 상황을 구체적으로 알려주셨다.
Composer를 실행할 수 없는 환경,
PHP CLI,
SSE,
심볼릭 링크,
disabled_functions,
크론탭 같은 문제들이다.
개발자 입장에서는 해결할 수 있는 문제일지 몰라도 일반적인 홈페이지 제작 환경에서는
이런 작은 장벽 하나가 “한번 사용해 볼까?”와 “그냥 G5를 쓰자”를 나누는 경계가 될 수도 있다.
기술적으로 더 좋은 구조를 만드는 것과 쉽게 시작할 수 있게 만드는 것은 서로 다른 문제인 것 같다.
그리고 한번 사용하게 만드는 것과 계속 사용하게 만드는 것도 다르다.
CMS가 오래 살아남으려면 코어를 계속 개발하는 것만으로는 어려울 것이다.
문서가 쌓이고,
사용 사례가 생기고,
모듈과 플러그인이 만들어지고,
질문과 답변이 축적되고,
실제 사이트가 운영되고,
그 안에서 누군가는 수익도 얻을 수 있어야 한다.
그래야 새로운 사용자가 들어올 이유가 생기고,
개발자가 확장을 만들 이유도 생긴다.
생각해 보면 이것은 앞서 적었던 “무엇을 만들지 않을 것인가”라는 문제와도 연결되는 것 같다.
G7에 기능을 계속 추가하는 것만이 발전은 아닐 수 있다.
이미 만들어진 기능을 안정시키는 일,
설치를 쉽게 만드는 일,
문서를 정리하는 일,
확장들이 서로 충돌하지 않게 규칙을 만드는 일,
실제 사용 사례를 만드는 일도 새로운 기능 하나를 추가하는 것만큼 중요할 수 있다.
특히 CMS는 오늘 얼마나 많은 기능을 가지고 있는가보다
몇 년 뒤에도 기존 사이트와 확장이 계속 동작할 수 있는가가 더 중요한 소프트웨어일지도 모르겠다.
G7이 현재 위치까지 온 것만으로도 하나의 성과라고 생각한다.
새로운 구조를 설계하고 실제 동작하는 CMS로 만들고,
그 위에서 모듈과 플러그인을 만들 수 있는 단계까지 오는 것도 쉬운 일은 아닐 것이다.
하지만 CMS는 여기서부터가 더 어려울 수도 있다.
코드를 만드는 것에는 어느 정도 끝이 있을 수 있지만,
생태계를 만드는 것에는 명확한 끝이 없기 때문이다.
5년 뒤에도 새로운 사이트가 G7으로 만들어지고,
10년 뒤에도 지금 만든 사이트를 업데이트할 수 있고,
그때도 누군가 새로운 모듈과 플러그인을 만들고 있다면 그 CMS는 살아 있다고 할 수 있을 것이다.
결국 G7의 성공을 판단하는 기준은 최신 기술을 얼마나 사용했는가도,
기능이 얼마나 많은가도 아닐지 모른다.
사람들이 실제로 사용하고,
그 위에서 무언가를 만들고,
그것을 계속 유지할 이유가 있는가.
그것이 더 중요한 기준일 것 같다.
G7은 5년, 10년 뒤에도 사용되는 CMS가 될 수 있을까?
지금은 그 답을 알 수 없다.
다만 앞으로 G7에서 무엇을 더 만들 것인가만큼,
어떻게 해야 사람들이 들어오고, 만들고, 남아 있게 할 것인가.
이 질문도 함께 고민해야 할 시점이 아닐까 하는 생각에 몇 자 적어 본다.
- 💫Glitter Gim
총 9명이 반응했습니다
|
댓글을 작성하시려면 로그인이 필요합니다.
댓글 9개
시대의 흐름이 CMS를 거부한다고 생각합니다.
기존 방식:
- 누군가가 아주 고생해서 1000+가지 기능을 정교하게 만들어서 오픈소스로 배포
- 오픈소스 기반으로 그 위에 덮어서 개발
- 오픈소스라 보안 취약점이 빨리 발견되면서 빠르게 패치되지만 또한 공격 포인트도 해커가 모두 알고 있음
요즘 방식:
- 내가 필요한 10가지 기능만 간단하게 AI로 만들어 적용
- 다만 보안이나 미처 생각지 못한 예외상황들은 본인이 감당
- 오픈소스가 아니다 보니 취약점이 있어도 빨리 발견은 잘 안됨
요즘 개발 방식의 변화로 이제 오픈소스 CMS는 각광받기는 좀 힘들어 질것 같고
오히려 AI 와 cli를 통해 상호작용되면서 개발할수 있는
SaaS 형태의 서비스가 발전을 하지 않을까요?
제 짧은 생각이네요..
무조건적인 비판이라기보다, 조금 다른 시각에서도 바라볼 필요가 있다고 생각합니다.
위에서 언급하신 최신 기술을 사용했느냐, 기능이 많으냐 적으냐가 핵심적인 문제는 아닙니다.
현재 G7의 가장 큰 장벽은 접근하기가 어렵고, 관련 자료가 턱없이 부족하다는 점이라고 생각합니다.
G5가 ‘누구나 쉽게 사용할 수 있는 환경’에 초점을 두고 시작된 것과 달리,
G7은 출발점과 지향점 자체가 다르기 때문에 어느 정도는 자연스러운 현상일 수 있습니다.
전문적인 개발자나 새로운 기술에 익숙한 사용자에게는 G7이 충분히 매력적인 선택지가 될 수 있겠지만,
개발을 잘 모르는 초보 사용자에게 G7은 아직 먼 나라의 이야기처럼 느껴질 가능성이 큽니다.
많은 사용자는 새로운 기술보다 익숙한 방식을 선호합니다.
새로운 것을 접했을 때 호기심보다 부담을 먼저 느끼는 것도 현실입니다.
AI가 좋은 것은 분명합니다.
“G7에 출석부를 만들어줘”라고 요청하면 AI가 상당 부분을 만들어 줄 수도 있겠죠.
하지만 아직 AI가 무엇인지조차 익숙하지 않은 사용자도 많습니다.
이들에게는 AI에게 기능을 설명하고, 생성된 코드를 검토하고, 오류를 수정해 가며 서비스를 완성하는 방식보다 이미 누군가가 만들어 놓은 플러그인이나 스킨을 내려받아 설치하는 방식이 훨씬 익숙합니다.
예전에도 비슷한 취지의 댓글을 작성한 적이 있습니다.
현실적으로 구현이 매우 어렵겠지만, G5의 플러그인이나 스킨을 G7에서 사용할 수 있도록 변환하거나 마이그레이션해 주는 기능이 있다면 G7의 활성화에 도움이 되지 않을까 하는 내용이었습니다.
현재 G7에서 활동하는 창작자와 자료가 충분하지 않은 상황에서 모든 것을 AI에게 맡기라고 하는 것은 초보 사용자에게 또 다른 진입장벽이 될 수 있습니다.
결국 AI가 있느냐 없느냐보다, 사용자가 실제로 얼마나 쉽게 접근하고 결과물을 만들 수 있느냐가 더 중요하다고 생각합니다.
최근 진행한 프로젝트에서도 비슷한 경험이 있었습니다.
회원가입 화면을 단계별 방식으로 구성했는데, 고객사에서는 다음과 같은 피드백을 주었습니다.
“사용자 입장에서 개발했으면 좋겠습니다. 너무 어렵습니다.”
개발한 사람의 입장에서는 “이게 무엇이 어렵지?”라고 생각할 수 있습니다.
하지만 실제 사용자가 느끼는 난이도는 개발자의 판단과 전혀 다를 수 있습니다.
누가 맞고 누가 틀렸다는 이야기가 아닙니다.
개발자가 의도한 편리함과 사용자가 체감하는 편리함은 서로 다를 수 있다는 뜻입니다.
G7이 성공할지 실패할지를 지금 단정할 수는 없습니다. 다만 G7이 넘어야 할 산이 너무나 많다는 점은 분명해 보입니다.
공개된 로드맵을 보면 현재는 기능적인 완성도를 먼저 갖추고, 이후에 편의성과 접근성을 개선하려는 방향으로 보입니다.
그 방향 자체가 잘못됐다는 뜻은 아닙니다. 다만 사용 편의성이 충분히 개선되기까지 얼마나 많은 시간이 필요할지는 알 수 없습니다.
그 기간 동안 일반 사용자와 초보 개발자의 유입이 제한된다면, 단기간에 큰 활성화나 흥행을 기대하기는 어려울 수 있다는 의미입니다.
그누보드 사이트에서 XE를 언급하는 것이 다소 조심스럽기는 하지만, XE1과 XE3의 사례를 떠올려 보면 이해가 쉬울 것 같습니다.
기존 사용자에게 익숙했던 환경과 완전히 다른 시스템으로 전환할 때는 기술적인 우수성만으로 해결되지 않는 문제가 많습니다.
기존 생태계와의 단절, 부족한 자료, 높은 학습 난이도, 사용자의 익숙함을 어떻게 연결할 것인지가 함께 고려되어야 합니다.
결국 G7에 필요한 것은 기능의 개수나 최신 기술만이 아니라, 초보 사용자도 쉽게 시작할 수 있는 자료와 예제, 설치 가능한 결과물, 그리고 기존 G5 사용자들이 자연스럽게 넘어올 수 있는 연결고리가 아닐까 생각합니다.
말씀하신 문제의식에 전체적으로 공감합니다. 기존에도 계속 지적해 주셨던 접근성 문제, 매뉴얼의 부재, 사용자 참여가 부족한 문제 모두 저희가 넘어야 할 과제라고 인식하고 있습니다.
접근성, 매뉴얼, 튜토리얼, 편의성, 마이그레이션까지 모두 함께 잡고 갈 수 있으면 좋겠지만, 현실적으로는 순서를 정해 처리할 수밖에 없는 점 양해 부탁드립니다. 한꺼번에 급하게 하기보다 차근차근 처리해 나가겠습니다. 진행 상황은 종종 게시판을 통해 공유드리겠습니다.
G5의 스킨/플러그인을 G7에서 그대로 쓸 수 있게 변환하는 문제는, 솔직히 말씀드리면 어렵다고 보고 있습니다. G5는 하나의 PHP 파일에 비즈니스 로직과 프론트가 함께 들어가 있고, G7은 백엔드와 프론트가 분리되어 있어 구조적인 차이가 있습니다.
이 문제는 확장을 쉽게 개발할 수 있도록 메뉴얼을 보강하고, 보일러플레이트나 에이전트 스킬을 제공하는 쪽으로 풀어 나가는 것이 합리적이라고 생각합니다.
앞으로도 지금처럼 사용자 입장에서 보이는 부분들을 짚어 주시면 개선에 참고하겠습니다.
좋은 의견 감사합니다.
Node.js 는 컴퓨터에서 자바스크립트 코드를 실행할 수 있게 해주는 런타임 환경입니다. 그 자체로 하나의 거대한 프로그램이며, 내부적으로 여러 개의 '내장 모듈'(예: 파일 읽기, 네트워크 통신 등)을 포함하고 있습니다
Composer는 PHP 언어에서 다른 사람이 만든 외부 라이브러리(패키지)를 다운로드하고 관리해 주는 의존성 관리 도구(패키지 매니저)입니다. 자바스크립트의 npm과 비슷한 역할을 합니다.
하여 학습되지않는 개발자라면 제생각은 새롭게 추가개발해서 쓰는것보다는 개발된 그대로 쓰면 적합할것으로 보입니다.
기본적인 기능은 다 가추고있으닌깐요~
결론은 새로운 빌드라고 생각하시고 쓰시면 될 것 같아보이네요
G5 -> XP
G5 Pro -> Me
G6 -> Vista
G7 -> Unix
저는 이런 느낌이 들어요.
다 훌륭한 CMS인데,
아직 G7를 잘 다룰만큼 실력이 되지 않다보니...
사용하는 장비 수준, 프로젝트 크기에 맞게, 그리고 사용자(개발자)가 잘 활용할 수 있는걸 사용하면 될것 같다는 합리화를 하며
설치는 못하고 살펴만 봤어요 ㅎㅎ
$g5 = new GNU5();
$g5->get_member('');
$g5->get_latest('skin', 'basic');
$g5->get_board('notice', 'basic');
광범위해서 필요할지는 가늠이 안되네요.
5를 설치하지는 않을 것 같네요.
7이 메인이고, 5는 서브의 역활로...