좋은 건 알겠는데 현실적으로 기존 사이트를 버리고 새로 구축할 사용자는 많지 않다는 생각입니다.
오히려 방향은 "새 CMS"보다는,
기존 G5/XE 같은 레거시 CMS를 Next.js 기반 현대 스택으로 최대한 손실 없이 이전할 수 있는 플랫폼에 가까워야 하지 않을까 싶네요.
디비/첨부파일/URL/권한/SEO 등의 마이그레이션 레이어가 갖춰진다면,
"레거시 CMS 현대화 플랫폼"이라는 포지션으로 자리할 수 있을 것 같습니다.
여기는 완성보다는 다양한 실험에 촛점을 맞춘 곳이라 보시면 될것 같습니다
사용자 층 분리 관련해서.. 제 생각은 다른게 기존 납품자산 유지는 고객이 비용을 추가부담 안하면 어차피 고칠이유가 없고요 새 프로젝트가 돈이 더되고 새프로젝트를 할때는 새로운 솔루션을 사용할 수도 있다는거죠 새 솔루션이 노리는게 이쪽이라 생각되고 한 5~6년을 봤는데요 기존의 사이트가 옮긴다거나 그런건 에이전시에 의뢰한 회사 A 가 있다고 하면 에이전시에 유지보수맡기다가 이제 A 사에서 내부개발팀을 꾸린다거나 하지않으면 잘 일어나지 않더라구요
그누보드가 라이믹스랑 다른점은 그누보드는 일반 사용자용도 있지만 에이전시에서 개발하는사람들이 쓴다는거예요 거기서는 새롭게 갈필요성이 있는게 기존 솔루션 납품받아서 사용하면서 php 이미지가 완전 나빠졌거든요. 이건 가져다 쓰면서 별도의 기술개발안하고 그냥 머무른 탓도있지만 아무튼 그렇습니다. 그누보드는 사용자층이 두 부류인데 두 사용자층이 너무 달라서 어느 한쪽을 만족시키면 한쪽은 불만이 생겨요. PHP 쪽은 현대화라고 하면 라라벨이 일단 생각나는거고 그거 안쓰고 한다면 mvc 로 전환하면서 라우팅 넣고 해야되는데 어떻게 되려는지 모르겠습니다. 아무튼 하고싶은말을 정리하자면 그누7 이 가고싶은 방향은 이 사이트 밖에 있다는 생각이 듭니다... 사람들이 php 를 다시 쓰고싶게 만들고 인식개선이라고 한다면 그렇게 가는게 맞는거 같긴한데 다른분들 의견은 어떻나요
말씀하신 사용자층 분리가 꽤 큰 문제 같네요. 특히 에이전시 쪽은 신규 구축보다 기존 납품 자산 유지 이슈가 커서, 완전 신규 CMS 경쟁보다 '기존 레거시를 현대 스택으로 연결하는 플랫폼' 쪽이 실제 수요가 더 크지 않을까 싶습니다.
"기존 레거시를 현대 스택으로 연결"이 왜 필요한가요? 모던 스택을 가져가는거 개발자 입장에서야 당연히 찬성이지만, 기존 그누보드를 사용하던 에이전시의 비즈니스 관점에서는 전혀 의미가 없어보입니다. 이전에도 설사덩어리같던 구조의 그누보드를 잘만 써온 사람들 입장에선 기술의 현대화만으론 매력 포인트가 될 수 없지 않나 싶습니다.
제 취지는 "개발자 취향 현대화" 보다는, 기존 레거시 자산을 버리지 않고 어떻게 현대화할 수 있느냐를 논한 것입니다. 기존 사용자와 자산을 최대한 이어받으면서도, 현대적인 구조로 이행할 수 있어야 한다는 쪽을 이야기한 것이었습니다.
"기존사용자가 현대화 한다"에서 이 "기존사용자"가 누구냐에 따라 주제가 완전히 달라지고요 개인이 직접 운영하는곳이라고하면 기존 자산을 이어가려고 할것이고 기업도 두 부류인데 외주로 맡겨둔곳이면 (에이전시죠) 해당 외주업가 할일이고 거기서 현대화고하면 재구축에 가깝죠. 내부에서 고치겠다고하면 기존 것을 최대한 유지하려고 할것이겠죠 근데 기업내부에서 전담직원이 현대화 한다고하면 엎는김에 보통다른언어로 가는 경우가 있죠
"기존 사용자와 자산을 최대한 이어받으면서도, 현대적인 구조로 이행할 수 있어야 한다"는 이유가 뭐냐는거죠. 결국 "현대적인 구조"를 도입하는걸 전제로 하는 이야기인데, 그 전제부터가 잘못된거 아니냐는 이야기였습니다. 그게 CMS 수준의 솔루션 위에 얹을 수 있는 프로젝트에서 왜 필요한거죠? AI가 없던 시절에도 그누보드나 XE 기반 외주 업무는 억단위를 넘지 않는 비교적 작은 크기의 프로젝트가 99.9%였는데, 이런 프로젝트를 위해 추가적인 공수를 투자해야 할 이유가 있나 싶습니다. 설령 그럴 가치가 있다고 해도, 그 경우 코ppp님 말씀대로 아예 완전히 현대화된 스택으로 넘어가지, 레거시 스택을 유지하지 않을겁니다. 새로운 스택이 또 다시 다른 CMS가 되지도 않을거구요.
말씀하신 사용자층 분리가 꽤 큰 문제 같네요. 특히 에이전시 쪽은 신규 구축보다 기존 납품 자산 유지 이슈가 커서, 완전 신규 CMS 경쟁보다 '기존 레거시를 현대 스택으로 연결하는 플랫폼' 쪽이 실제 수요가 더 크지 않을까 싶습니다.
"기존 레거시를 현대 스택으로 연결"이 왜 필요한가요? 모던 스택을 가져가는거 개발자 입장에서야 당연히 찬성이지만, 기존 그누보드를 사용하던 에이전시의 비즈니스 관점에서는 전혀 의미가 없어보입니다. 이전에도 설사덩어리같던 구조의 그누보드를 잘만 써온 사람들 입장에선 기술의 현대화만으론 매력 포인트가 될 수 없지 않나 싶습니다.
제 취지는 "개발자 취향 현대화" 보다는, 기존 레거시 자산을 버리지 않고 어떻게 현대화할 수 있느냐를 논한 것입니다. 기존 사용자와 자산을 최대한 이어받으면서도, 현대적인 구조로 이행할 수 있어야 한다는 쪽을 이야기한 것이었습니다.
"기존사용자가 현대화 한다"에서 이 "기존사용자"가 누구냐에 따라 주제가 완전히 달라지고요 개인이 직접 운영하는곳이라고하면 기존 자산을 이어가려고 할것이고 기업도 두 부류인데 외주로 맡겨둔곳이면 (에이전시죠) 해당 외주업가 할일이고 거기서 현대화고하면 재구축에 가깝죠. 내부에서 고치겠다고하면 기존 것을 최대한 유지하려고 할것이겠죠 근데 기업내부에서 전담직원이 현대화 한다고하면 엎는김에 보통다른언어로 가는 경우가 있죠
"기존 사용자와 자산을 최대한 이어받으면서도, 현대적인 구조로 이행할 수 있어야 한다"는 이유가 뭐냐는거죠. 결국 "현대적인 구조"를 도입하는걸 전제로 하는 이야기인데, 그 전제부터가 잘못된거 아니냐는 이야기였습니다. 그게 CMS 수준의 솔루션 위에 얹을 수 있는 프로젝트에서 왜 필요한거죠? AI가 없던 시절에도 그누보드나 XE 기반 외주 업무는 억단위를 넘지 않는 비교적 작은 크기의 프로젝트가 99.9%였는데, 이런 프로젝트를 위해 추가적인 공수를 투자해야 할 이유가 있나 싶습니다. 설령 그럴 가치가 있다고 해도, 그 경우 코ppp님 말씀대로 아예 완전히 현대화된 스택으로 넘어가지, 레거시 스택을 유지하지 않을겁니다. 새로운 스택이 또 다시 다른 CMS가 되지도 않을거구요.
