Emdash
https://blog.cloudflare.com/emdash-wordpress/
워드프레스를 타겟으로 해서 나왔습니다.
Typescript + Astro 기반인데, 아마 이러다가 슬금슬금 클플에서 만든 OpenNext 기반으로 바꾸지 않을까 싶네요.
현재 사용자데모도 가능하지만, 0.1.0버전과 같이 엄청나게 불안한 상황인 만큼 아직 지켜봐야 할것같습니다.
그누보드7
https://sir.kr/g7
데모만 봐서는 솔직히 뭘 원하는지 잘 모르겠습니다..
디자인들도 AI디자인이고, 메뉴 구성도 AI가 해준 느낌이고, 결국에 AI가 잘하는 스택을 기반으로 그누보드라는 이름만 가져온 새로운 CMS를 만들었다는 느낌이 큽니다.
사용자 매뉴얼도 AGENTS.md를 제공해주는걸 보고 깜짝 놀랐네요.
XE3과 비슷한 전철을 밟는 기술 스택도 그렇고, 그누보드6에서 엎어진적이 있었던걸로 기억해서 어느 모습으로 변할지도 굉장히 궁금합니다.
에카
Lv. 3
댓글 12
그누보드는 써본적이 없는데 어떤가요
저는 예전 제로보드 때 부터 쭉 써왔고
라이믹스는 최근에 다시 뚜드려보고 있는 단계고
XE3(엑스이허브)의 경우에는
제가 한때 회사다닐 때 소속회사에서 XE3로 엑스이허브랑 같이 프로젝트 한적은 있었죠...
플랫폼을 2개정도 만들었던 기억이 있습니다.
그래도 여전히 라이믹스가 편하긴 하더라구요.
솔직히 말씀드려서 5 출시때까지만 해도 괜찮았던걸로 기억합니다. 나름 변화를 하려고 한것도 있었구요.
근데 뭐 스파게티 코드 범벅이다보니 뭣만하면 코어 수정해야되고, 그러다보니 빌더 업데이트가 안되면 코어 업데이트 못하고 여러모로 총체적 난국이였습니다.
뜬금없이 뱀탕을 한 사발 드셨던 그누보드 6보다는 그나마 낫네요.^^ 그런데 설치 가이드가 웹호스팅과는 전혀 무관해 보인다는 점에서 여전히 글쎄올시다. 라라벨을 쓴다고 해서 꼭 자체서버나 클라우드를 써야 한다는 법은 없거든요. 홈페이지 제작해서 납품하고 손 떼는 일이 다반사인 이쪽 업계에서는 더더욱 그렇고요.
기술적인 우수성(?)에 꽂혀서 이용자 커뮤니티와 서드파티 생태계의 니즈를 고려하지 않는 것은 어느 동네 개발자들이나 마찬가지인 것 같습니다. 플러그인 없는 워드프레스, 빌더 없는 그누보드는 대체할 가치조차 없을지도 모르는데 말이죠. 클플의 막강한 자금력으로 플러그인 생태계까지 테라포밍할 수 있을 거라고 생각하는 걸까요?
AI 개발툴과 얼마나 쉽게 연동할 수 있는지가 앞으로 매우 중요해질 것 같은데, 그런 면에서는 전세계적으로 많이 쓰는 프레임워크를 활용하는 이점이 있습니다.
그누보드에 관해서는 말씀하셨던 '기술적 우수성'에 걸맞는 사례가 하나있었죠.
XE3이라는 너무 가까운곳의 너무 큰 실패사례가 있었는데 똑같은 전철을 밟는거 아닌지 걱정됩니다.
이미 베타 첫 빌드부터 웹호스팅을 생각안하고 올린것 자체부터가 영화 인터스텔라의 유명한 장면인 Stay 가 생각나지만요 ㅋㅋ
XE3과 다른점은 AI의 유무인것같아요. 그래서 좀더 흥미롭게 지켜보려고 하네요.
Emdash의 경우 클플의 오픈소스 수행능력이 어디까지인지 볼 수 있을 좋을 사례라고 생각합니다.
기술적인 측면을 강조하는 클플이기에 마케팅 비용을 써서 유저들을 옮기게끔 하진 않을것같고,
클플 대시보드에서 워드프레스 특화기능 아래에 짤막하게 "보안과 성능이 확보된 Emdash로 지금 바로 마이그레이션 할 수 있습니다" 이런식의 마케팅을 진행하지 않을까 하구요.
관리자 페이지를 들어가봤는데 워드프레스를 기능으로 이겨버리겠다! 할만한 임팩트는 전혀 없어보이네요..
네, 시대가 달라져서 AI를 활용할 수 있게 되었고, 무엇보다 SIR 운영진도 XE3과는 다르죠. ㅎㅎ 그나마 이쪽은 사용자들과 좀더 적극적으로 소통하면서 보완해 갈 여지가 있습니다. 특히 초기에는 그게 굉장히 중요하거든요.
에.. 요즘 누가 호스팅쓰나요 클라우드보다 같은사양비하면 더 비싼데요.
일본이나 다른나라 cms 보면 php 긴한데 도커환경으로 쉽게 쓸수있게 환경파일 같이 배포하더군요.
일본의 EC-CUBE
https://github.com/EC-CUBE/ec-cube
요즘 누가 호스팅을 씁니다. 가상서버 비용이 저렴한건 고객이 서버 유지보수 및 튜닝 책임을 지기 때문이지요.
재료를 사서 직접 요리해먹는게 대부분 압도적으로 저렴함에도 외식을 하는 이유를 생각해보시면 될것 같네요.
astro도 클라우드플레어에서 인수했으니 굳이 opennext로 바꾸지는 않을거 같아요.
거기다 기진곰님 말씀대로 플러그인 생태계가 중요한데, 그런 생태계 확장의 관점에서 봤을 때 react에 종속된 opennext보단, 그래도 원하는 프레임워크를 섞어 쓸 수 있는 astro가 조금 더 유리할테구요.
엇 Astro를 클플에서 인수했나요? 그건 또 처음알았네요 ㅡㅡ;
Astro를 프로덕션에서 그렇게 많은곳들이 쓴단 느낌은 없어서, 저는 기왕이면 React, 그리고 Next를 대체하려는 opennext이지 않을까 싶었거든요.
opennext가 react, next.js를 대체 하려는 시도인가요? 그냥 Vercel 이외에 플랫폼에 맞게 적용하려는 프로젝트 수준이 아니었나요?
저는
"(리액트 그리고 넥스트)를 대체하려는 오픈넥스트"
가 아니라
"리액트 그리고 (넥스트를 대체하려는 오픈넥스트)"
로 이해했어요.
React를 대체하려는이 아니라 Next를 대체하려는이 맞습니다.
제가 알기론 Turbopack같은 의존성을 버리고 Vite기반으로 아예 새로 작성하는걸로 알고있어서요.
요즘 정신이 없어서 표현도 잘 정제되지 않네요.