"오픈소스 프로젝트의 운영이나 주도적 참여 경험이 없는 것는 것 같다"라는 상상을 해보았습니다.

이 상상의 바탕은 몇 가지가 있습니다.

첫째로, 커밋 로그가 없는 것은 베타 버전이라서, 정식버전 개발에 바빠서 지저분한 커밋로그를 정리하며 푸시할 수 없어서라고 이해할 수도 있습니다만, 수 많은 변경사항을 담은 단일 커밋보다는 지저분한게 차라리 낫죠.
정식 버전에서는 변경사항의 추적이 가능한 상태가 되면 좋을 것 같네요. 버전관리 시스템에 잘 적응한 팀이라면 이렇게 코드의 변경이력을 감추는 개발자가 팀에 있으면 싫어하겠죠.




둘째로, 빌드 과정이 필요없는 JSON 레이아웃 엔진을 내세웠지만, 결코 쉽지는 않습니다.
React 기반 개발자들도 직접 쓸일이 없는 CreateElement를 이해해야하고, 기존처럼 HTML 코드를 만드는 것처럼 생산성을 높이려면 AI를 필수로 사용하여 의존해야합니다.

메인 컨셉의 하나로 SPA를 두고 React를 채택했으나 빌드 과정이 없어야한다는 조건하에 JSON 레이아웃 엔진이 만들어진 것으로 보입니다. 물론 React 컴포넌트를 만들어 활용할 수 있다지만, 배포나 판매형 제품들도 이 빌드 과정을 거치지 않으려면 JSON 엔진의 스펙을 따르는게 거의 강제되겠죠.

이런 문제를 만드는 것은 React 사용이 강제되어 발생하는 문제인데, G7에 구현된 방식은 상당히 폭력적이고 Blade 템플릿이나 다른 프론트엔드 프레임워크나 라이브러리를 사용하기 어렵게 되어있죠. 라라벨의 개방성을 G7이 방해하고 있는 셈이죠. 배포형 솔루션에서 이러한 강제성이나 기술 선택이 적절했는지 의문이 듭니다. 



셋째로, 컴포저, NPM, vite 등을 사용하려는 사용자에 대한 고심이 부족해 보입니다.
G7에 포함된 composer.json 등의 파일들은 이를 활용하려는 사용자에게는 코어 업데이트 시 충돌이 발생할 소지가 크죠. 하지만 이에 대한 고민이 전혀 없었던 것으로 보입니다.



넷째로, 보안취약점을 공개적으로 게시하라고 합니다.


몇가지 더 있는데, 당장 떠오르지 않아서 상상했던 내용이 떠오르면 더 적어보겠습니다.