AI 도구 이야기는 넘치는데, 우리는 그누보드7을 얼마나 알고 있을까요?
최근 자유게시판을 보면 AI 도구(이하 도구) 관련 글이 많다.
Claude Code, Gemini, AI Agent 같은 개발 도구부터 개발 기간 단축, 개발 단가, 개발자의 미래까지 다양한 이야기가 있다.
나 또한 도구를 사용하면서 개발 방식이 빠르게 바뀌고 있다는 것을 느끼고 있다.
이제는
"AI가 개발할 수 있는가?"
보다
"도구를 이용해 어떻게 개발할 것인가?"
가 더 현실적인 질문이 된 것 같다.
그런데 한 가지는 궁금하다.
AI 시대의 개발을 이야기하는 우리는,
정작 지금 활동하는 SIR이 미래를 위해 준비하는 CMS에 대해서는 얼마나 알고 있나?
우리는 그누보드7을 얼마나 알고 있을까?
SIR에서 활동하는 개발자라면 그누보드5는 대부분 익숙할 것이다.
그런데 G7은 어떨까?
G5와 무엇이 다른지,
왜 Laravel을 기반으로 하는지,
modules / plugins / templates는 어떻게 구성되는지,
API와 UI는 어떻게 연결되는지,
직접 설치하거나 모듈과 플러그인을 만들어 본 개발자는 얼마나 될까?
G7이 개발되고 있다는 것을 아는 것과 실제 구조를 이해하는 것은 다른 문제다.
도구 이야기에 비해 G7 이야기는 많지 않다.
어떤 도구가 코딩을 더 잘하는지,
개발 기간이 얼마나 줄어드는지,
개발자의 역할과 단가는 어떻게 바뀔지,
도구가 어디까지 개발을 대신할 수 있을지는 계속 논의된다.
반면 SIR이 다음 세대 CMS로 개발하고 있는 G7의 구조와 개발 방식에 대한 이야기는 상대적으로 많지 않다.
현재 대부분의 프로젝트가 G5 기반이고, G7을 당장 사용할 필요가 없는 개발자도 많을 거다.
새로운 구조를 익혀야 한다는 부담도 있을 거다.
하지만 그 부담 역시 도구 때문에 줄어들고 있다.
도구는 개발 시간뿐 아니라 학습 시간도 줄인다.
예전에는 새로운 프레임워크나 CMS를 배우려면 문서와 예제를 보고 직접 소스를 분석해야 했다.
지금은 도구를 이용해 프로젝트 구조를 분석하고, 코드를 설명받고, 필요한 기능을 작성할 수 있다.
도구 때문에 기존 개발자의 기술 가치가 떨어질까 걱정하는 시점에,
새로운 기술을 익히는 비용 역시 도구 때문에 낮아지고 있다.
G7을 직접 설치하고 도구로 소스를 분석하면서 작은 모듈이나 플러그인부터 만들어 볼 수 있다.
G7이 AI 시대의 정답이라는 뜻은 아니다.
modules / plugins / templates 구조가 장점이 될 수도 있고 복잡성으로 작용할 수도 있다.
Laravel 기반 역시 장점일 수도,
진입장벽일 수도 있다.
결국 직접 사용하고 판단할 문제다.
다만 G7은
기능을 분리하고,
모듈과 플러그인으로 확장하며,
API와 UI를 나누고,
기능을 조합하고 재사용하는 구조를 지향하고 있다.
도구로 코드를 빠르게 뽑는 시대에는 이런 구조와 규칙이 중요해질 수 있다.
코드를 만드는 것과 유지 가능한 서비스를 만드는 것은 다른 문제이기 때문이다.
무엇을 만들지,
어떤 구조를 따르게 할지,
기능들을 어떻게 연결할지,
결과를 어떻게 검증할지는 여전히 개발자가 판단해야 한다.
그래서 궁금하다.
그누보드7을 직접 설치하거나 소스를 살펴본 적이 있을까?
아직 사용하지 않았다면 왜 그런지,
사용해 봤다면 G5와 비교해 무엇이 가장 달랐는지 궁금하다.
도구와 개발자의 미래에 대한 이야기가 많은 요즘,
정작 우리가 활동하는 SIR이 미래를 위해 준비하는 G7에 대해 나는 얼마나 알고 있는가?
이 질문도 한번 던져볼 만하다는 생각에 몇 자 적어 본다.
- 💫Glitter Gim
Claude Code, Gemini, AI Agent 같은 개발 도구부터 개발 기간 단축, 개발 단가, 개발자의 미래까지 다양한 이야기가 있다.
나 또한 도구를 사용하면서 개발 방식이 빠르게 바뀌고 있다는 것을 느끼고 있다.
이제는
"AI가 개발할 수 있는가?"
보다
"도구를 이용해 어떻게 개발할 것인가?"
가 더 현실적인 질문이 된 것 같다.
그런데 한 가지는 궁금하다.
AI 시대의 개발을 이야기하는 우리는,
정작 지금 활동하는 SIR이 미래를 위해 준비하는 CMS에 대해서는 얼마나 알고 있나?
우리는 그누보드7을 얼마나 알고 있을까?
SIR에서 활동하는 개발자라면 그누보드5는 대부분 익숙할 것이다.
그런데 G7은 어떨까?
G5와 무엇이 다른지,
왜 Laravel을 기반으로 하는지,
modules / plugins / templates는 어떻게 구성되는지,
API와 UI는 어떻게 연결되는지,
직접 설치하거나 모듈과 플러그인을 만들어 본 개발자는 얼마나 될까?
G7이 개발되고 있다는 것을 아는 것과 실제 구조를 이해하는 것은 다른 문제다.
도구 이야기에 비해 G7 이야기는 많지 않다.
어떤 도구가 코딩을 더 잘하는지,
개발 기간이 얼마나 줄어드는지,
개발자의 역할과 단가는 어떻게 바뀔지,
도구가 어디까지 개발을 대신할 수 있을지는 계속 논의된다.
반면 SIR이 다음 세대 CMS로 개발하고 있는 G7의 구조와 개발 방식에 대한 이야기는 상대적으로 많지 않다.
현재 대부분의 프로젝트가 G5 기반이고, G7을 당장 사용할 필요가 없는 개발자도 많을 거다.
새로운 구조를 익혀야 한다는 부담도 있을 거다.
하지만 그 부담 역시 도구 때문에 줄어들고 있다.
도구는 개발 시간뿐 아니라 학습 시간도 줄인다.
예전에는 새로운 프레임워크나 CMS를 배우려면 문서와 예제를 보고 직접 소스를 분석해야 했다.
지금은 도구를 이용해 프로젝트 구조를 분석하고, 코드를 설명받고, 필요한 기능을 작성할 수 있다.
도구 때문에 기존 개발자의 기술 가치가 떨어질까 걱정하는 시점에,
새로운 기술을 익히는 비용 역시 도구 때문에 낮아지고 있다.
G7을 직접 설치하고 도구로 소스를 분석하면서 작은 모듈이나 플러그인부터 만들어 볼 수 있다.
G7이 AI 시대의 정답이라는 뜻은 아니다.
modules / plugins / templates 구조가 장점이 될 수도 있고 복잡성으로 작용할 수도 있다.
Laravel 기반 역시 장점일 수도,
진입장벽일 수도 있다.
결국 직접 사용하고 판단할 문제다.
다만 G7은
기능을 분리하고,
모듈과 플러그인으로 확장하며,
API와 UI를 나누고,
기능을 조합하고 재사용하는 구조를 지향하고 있다.
도구로 코드를 빠르게 뽑는 시대에는 이런 구조와 규칙이 중요해질 수 있다.
코드를 만드는 것과 유지 가능한 서비스를 만드는 것은 다른 문제이기 때문이다.
무엇을 만들지,
어떤 구조를 따르게 할지,
기능들을 어떻게 연결할지,
결과를 어떻게 검증할지는 여전히 개발자가 판단해야 한다.
그래서 궁금하다.
그누보드7을 직접 설치하거나 소스를 살펴본 적이 있을까?
아직 사용하지 않았다면 왜 그런지,
사용해 봤다면 G5와 비교해 무엇이 가장 달랐는지 궁금하다.
도구와 개발자의 미래에 대한 이야기가 많은 요즘,
정작 우리가 활동하는 SIR이 미래를 위해 준비하는 G7에 대해 나는 얼마나 알고 있는가?
이 질문도 한번 던져볼 만하다는 생각에 몇 자 적어 본다.
- 💫Glitter Gim
총 11명이 반응했습니다
|
댓글을 작성하시려면 로그인이 필요합니다.
댓글 6개
4를 조금 알만하니 5가 튀어나고 맛좀 보려니 6튀어나오고
그러다 흔적없이 사라져버리고,,,그리고 7튀어나오고,,,
위기감에 또 8이 튀어나오겠지만
게다가 나보다 AI가 100배 1000배 더 잘아는데,,,내가 왜 알아야 하는지
시원한 답좀 주세요 ㅜㅜ
이제 아는건 글마들한테 맡겨야 한다는게 확신입니다,,
전분야에 걸쳐 엄청난 정보를 가지고
덤벼드는데 무슨수로 비빈다는 말인지,
게다가 학습능력이 나보다 엄청나게 우수한 놈들입니다,
이제 나는 인간의 감각, 판단, 경험, 그놈들이 못하는거에 집중합니다,
그것도 언젠가는 따라잡히겟지만,
나는 이제 만드는거에 집중하는게
전에도 만드는거에 집중한 적도 없지만서도 ㅋㅋ
아니고 무얼 만들어야 하는지,,
어떤 구성이어야 하는지,,
이게 정말 필요한건지,,
그리고 가장 중요한거는 이게 먹힐지,,,,
AI 시대가 되면서
다들 AI가 다 한다고... 이제 다들 AI 때문에 직업도 없어지고... 개발자는 설자리가 없어진다고 하면서...
정작 AI를 배워야 한다고 하는 아이러니...
AI 시대에 공부할 것을 만들다니, 정작 AI의 목표는 공부하지 않고 아가리 파이트 하나만으로 다 해결하는 게 목표 아니었나?
AI 시대에 AI에 역행하는 거, AI에 투항하지 않는 거 이게 문제 아닌가?
개발자의 시대는 끝났어요.
이제 인문학적 교양과 감각적인 디자인의 시대입니다.
코딩은 종말을 맞았어요.
살아남으려면,
유연해지고 더 쉬워지고 더 많이 시도하고 더 많이 생산하고 더 많이 시간을 아껴줄 수 있는 방법을 찾아야 할 것 같습니다.
그냥 개발자 여러분들 말고 아무나 쉽게 접근할 수 있는 그런 거 만들어서 아저씨 아주머니들 모두 쉽게 홈페이지 만드세요...
이런게 필요하다고요...
나이 좀 있는 분들은 나모웹에디터 시대를 생각해봅시다. 너무 멀리 갔나?
제가 생각하기에...
플론트 (리액트 등등), 백(ALL) 다 끝났습니다.
이제 사실 그냥 찍어내는 디자인의 시대도 끝나 갑니다.
AI가 내가 하는 것보다 디자인 시스템에 대해서 휠씬 잘 알고, 디자인 잘합니다.
(디자인 강사였고 잘 나갔고 나름 디자인 잘 뽑는)다고 생각하는 데 말입니다.
자 자 이제 개발자들에게 세기말의 상황입니다.
뭘 해야 하나요?
간단하잖아요.
돈 벌어야잖아요?
유입이 많아야줘?
윅스, 아이엠웹, 카페24워드프레스 이러 거 보면 느끼는 거 없나요?
멀 하고 있나요?
쉽게 설치하고 세팅이 쉬은 버전 만들고 (저는 그누5SE 에 상당히 기대를 하고 았었습니다만 ... 다크 모드는 이해가 안 갔습니다. 다크모드 있는 홈페이지가 몇개나 있는 지 알아보고 다크 모드를 만든거지...)
호스팅 업체 도메인 업체와 조인해서 설치하게 해주고 입력 몇 개 만으로 홈페이지 만들게 해주고
그기다 테마 얹어주면 (꼭 제가 테마 판매자라서 그런 거 아닙니다.)
윅스, 아이엠웹, 카페24워드프레스 이런 거 생길 틈도 없었습니다.
일개 테마 판매 하는 사람도 피티기게 연구하고 인터페이스 하며 썸네일 이미지 하나하나 신경 써서 구성하는데
이건 머 어려워서 그렇다... 더 편리하게 만들려니 그렇다... 더 멋지고 AI 친화적이다... 하면서
정작 대중과 멀어지네요... 그누 자체의 수익 모델이 그기 있고 어쩔 수 없었다면 머 어쩔 수 없는 일이지만
그누5를 오래 써온 사람으로서 가장 염려되는것은 지속적이지 않거나 혹은 안일한 그누5 의 미래입니다.
이게 그누7에 대한 반감으로 돌아왔을 지도 모르겠네여.
그누7에 대해서 저는 잘 모릅니다.
근데 사용자가 꼭 알아야하나요? 어렵게 또 배우고, 장점에 대해서 인정하고, 깊이 감복하면서 사용해줘야 하나요?
홈페이지 하나 만들려면 너무 많은 것을 배워야 합니다. 아직 GIT이 먼지 모르는 홈페이지 제작하는 프리랜스가 얼마일지...
호스팅은 또 어떻게 하고... 아 모르겠어요... 왜 이런 어려운 걸 만드셨는지... 걍 일반 호스팅이로 할 수 있게 해주지... 걍 멋진 개발자 좀 포기하고 돈 독에 오른 장사치 좀 되주지...
머 걱정은 그누5를 잃어버리는 겁니다만.
저는 요즘 주식으로 돈을 많이 잃었습니다.
손절할 타이밍을 놓쳐서리...
되돌아가서 생각하는 거 많이 해보고 많이 되돌아가서도 실패하지만 결국엔 되돌아 가지 않은 주식 쟁이는 손실만 떠 안죠...
제 말이 옳다는 것도 아니고 그렇다고 나쁜 마음의 해꼬지도 아닙니다.
그냥 그누 때문에 좀 벌어먹었고 지금도 좀 벌어먹고 있는 거의 원년 회원으로서 과거의 그누 영광의 시기(?) 를 생각하며
글 씁니다.
원글 쓴 분에게는 죄송합니다.
따로 써야하는데 어쩌다 보니 ... 제목을 어떻게 해야할 지도 모르겠고 ... 쫄보 이기도 해서
긴 글 읽으셨다면 감사합니다.
7 개발하면 => 먹고 살수가 없다.
좋은 글과 정성스러운 답변들 잘 읽었습니다. 감사합니다.
다만 메인테이너 입장에서는 긍정적인 피드백 보다는 접근성에 대해 우려를 전달해주신 여러 댓글들이 크게 와닿았습니다.
개인 시간을 활용해서 그누보드7을 일반 호스팅에서 설치/운영 가능한 수준으로 개선을 시도해보고 있습니다.
현재 7.0.8 기준 호스팅 환경 대응 수준은 아래와 같습니다.
<대응 완료>
- composer 실행 불가 환경 : vendor 번들 포함으로 처리 완료
- PHP CLI 경로 지정 : 설치 단계에서 지정 가능
- SSE 미지원: 폴링 모드 추가
<미대응>
- PHP CLI 미지원 환경
- wwwroot, public_html 등 web root 에 대한 심볼릭 링크 생성 불가 환경 (SSH 접속 불가 환경)
- exec / proc_open / shell_exe 등이 disabled_functions 등으로 차단된 환경
- 스케쥴용 전용 트리거 URL 제공 (크론탭 구동 불가한 환경에서 외부 서비스의 도움으로 스케쥴을 구동하는 방법)
호스팅에서 설치가 불가한 문제는 <미대응>에 기재된 제약 조건으로 인한 것으로 인식하고 있습니다.
한편으로는 로드맵에 예정되어 있지 않은 기능에 대해 개발 예정이라는 댓글을 남기기가 조심스럽기도 합니다.
로드맵과는 별개로, 순수하게 오픈소스 메인테이너 입장에서 문제점을 무겁게 인식하고 있으며, 개선 노력을 기울이고 있다는 점 정도로 이해 부탁드립니다.
감사합니다.