라라벨 참 좋은데 ... 어떻게 표현할 방법이 없네요
그렇다고 라라벨만을 사용하겠다고 말하고 싶은 건 아닙니다.
다만 직접 운영해 보니, 다른 것들에 비해 상대적으로 괜찮게 느껴졌을 뿐입니다.
그누보드5를 출시한 지도 꽤 오랜 시간이 흘렀습니다.
이후 그누보드6 파이썬 버전을 시도했지만, 결과적으로는 잘 되지 않았습니다.
계속 밀고 갔으면 어땠을지는 알 수 없지만,
회사를 운영하는 입장에서는 제 생각만으로 결정을 미룰 수는 없었고
어느 시점에서는 빠른 판단이 필요했습니다.
그 이후로는 여러 언어와 환경을 접해보려 했습니다.
마침 AI 열풍이 시작되면서 다른 언어를 배우는 데 큰 도움을 받기도 했고요.
그렇다고 AI에게 전부 맡겨 놓은 건 아니고,
결과물을 이해하기 위해 기본적인 공부는 나름대로 병행했습니다.
솔직히 말하면, 머리가 잘 돌아가는 편도 아니라 쉽지 않았습니다.
Node, React, Next.js도 해보고,
Python Django도 써보고,
PHP 쪽에서도 여러 프레임워크를 만져봤습니다.
그러면서 점점 이런 생각이 들었습니다.
요즘 기술들은 개발보다 운영이 더 어렵다는 느낌이 강했습니다.
예전 Native PHP 위주로 개발하던 입장에서는
“이걸 만들어서 배포해도, 실제로 쓰는 게 더 문제겠구나”라는 생각이 들더군요.
돌아가게 만드는 것보다, 계속 돌아가게 유지하는 게 훨씬 까다로웠습니다.
그 과정에서 라라벨도 자연스럽게 다시 보게 됐습니다.
그렇지만, 웹호스팅 환경에서 완벽하게 지원하는게 아니어서,
CLI나 Composer, 권한, 큐 같은 부분은 여전히 고민거리입니다.
그래서 한때는 다시 완전히 Native PHP로 갈까 싶기도 했습니다.
그런데 또 한편으로는 이런 생각이 들었습니다.
그 수많은 플러그인과 공통 기능을
과연 Native로 전부 감당할 수 있을까.
결국 플러그인을 쉽게 쓰라고 만든 게 프레임워크고,
라라벨 같은 도구들이 그 역할을 해주고 있는 건 아닐까 하는 생각이요.
그래서 라라벨이 "최고"라서 좋다는 말은 잘 못 하겠습니다.
다만 운영해 보니, 적어도 제가 겪어온 범위 안에서는 상대적으로 덜 힘들었다는 정도입니다.
이게 라라벨이 정말 잘 만들어져서일 수도 있고,
어쩌면 제가 다른 언어나 프레임워크를 충분히 알지 못해서
선택지가 좁아진 결과일 수도 있겠죠.
그래서 요즘은 확신보다는 고민에 가깝습니다.
“이게 최선일까?”보다는
“혹시 더 나은 선택이 있는데, 내가 모르고 있는 건 아닐까?”
아마 이 질문에 대한 답은
조금 더 겪어보고, 조금 더 실패해봐야 보일 것 같습니다.
지금은 다만, 운영해 본 사람으로서의 체감과
그 체감을 의심해 보는 단계쯤에 와 있는 것 같습니다.
댓글 12개
베스트 댓글
운영자가 어디까지 관여하고, 어디를 도구 사용으로 갈지가 중요한 것 같습니다.
어떤 프레임워크가 편하다고 느껴지는 지점도 결국 문법이나 유행의 문제가 아니라,
반복되는 공통 문제를 내가 다시 정의하지 않아도 되는 범위가
얼마나 넓은가에 가깝다고 느끼고요.
다만 그 편의는 운영 환경, 배포 방식에 따라
언제든 부담으로 바뀔 수 있다는 점도 동시에 체감합니다.
“더 나은 선택”을 찾기보다는
“지금 내가 감당 가능한 경계가 어디까지인가?”를 기준으로 가야 하지 않나 싶네요.
그누보드 스타일이라면 slim에 Plate 템플릿 엔진 조합이면 많은걸 참조하지 않는 자체 설계를 구현 해나갈 괜찮은 기반이 될 것 같습니다. Plate는 스코프를 분리해주고 템플릿에 제공할 헬퍼를 추가하는데 유용하더군요. ORM이 아닌 PDO 지원하는 wrapper 도 심플한 게 좀 있고요. slim 외에도 라우터 프레임워크는 더 있고, 잘 활성화되거나 유지보수 되는 것으로 잘 골라야겠죠.
자체 설계를 구현하기 어렵거나 더 나은 방법이 마땅치 않다면 라라벨을 선택하는게 현재로썬 가장 나은 방법 같습니다. 물론 라라벨을 쓴다고 전부 해결이 아니라 앱 구현 또한 잘 만들어야겠죠.
라라벨이나 심포니나 정말 잘 만들어지긴 했지만, 학습비용이 크고 일반 웹호스팅 환경에 어려움이 조금 있을 수 있습니다. 무엇보다 파일 수가 굉장히 많은 것부터 우리가 일반적으로 FTP 클라이언트로 업로드하는 것을 떠올리면 파일업로드부터 큰 작업이죠 ㅎㅎ
카페24 같은 호스팅에서도 composer나 라라벨의 artisan 명령어도 크게 문제 없이 사용할 수 있어서 큰 걸림돌은 없었습니다. git 도 사용 가능했고요.
만약 라라벨 버전의 그누보드를 생각하신다면 주 사용자층을 나눠서 생각하시면 좋을 것 같습니다.
기존 그누보드5 사용자 층과 모던 개발자 층을 나누어야하고 모두를 데려갈 수 없는 한계를 인정해야 합니다. 그누보드5가 극소수의 PHP 5.2 버전 환경 유지를 위해 많은 것을 포기해야 했고, 그로 인해 발전이 멈추고 과거에 머물 수 밖에 없던 문제를 인식해야 합니다.
그누보드의 PHP 5 지원은 이미 최소 5 년 전에 끊어냈어야 했다고 생각합니다. 적어도 5.4로만 올렸어도 많은 선택지가 생겼습니다. 그게 그누보드가 현대의 개발환경과 격차를 좁히지 못하게하는 가장 잘못된 판단이었습니다. 이제와서 그 격차를 좁히려면 아주 많은 것들을 한꺼번에 배워야만 하겠죠.
라라벨을 쓴다고 모두가 라라벨의 모든 것을 학습해야하는 건 아닙니다.
테마류는 블레이드 문법 정도만 익히고, 헬퍼 함수나 필요한 인터페이스를 적극적으로 제공하면 블레이드 문법에 헬퍼함수 정도만 학습하는 정도로 가능하겠죠. 플러그인도 이벤트를 잘 활용하고 플러그인 제작자에 헬퍼, 인터페이스를 제공하면 되겠죠. 라라벨을 쓴다고 써드파티 제작자 모두가 라라벨의 모든 부분을 익혀야 하지 않도록 앱을 잘 설계하여 제공하시면 됩니다. 어떤 것을 기반으로 하든 서드파티의 학습 비용은 프레임워크 레벨이 아닌 앱의 설계가 크게 좌우하게 되겠죠.
아무튼. slim 같은 라우터 같은 심플한 패키지들을 조합하는 방법은 설계 능력이 매우 크게 요구되고, 매뉴얼도 자체적으로 생산해야합니다.
라라벨을 이용한다면 학습 비용이 크지만 프레임워크 레벨의 매뉴얼은 영문이지만 매우 잘 되어있고 기계 번역으로 제공할 수 있고 사용할 수 있는 리소스도 매우 많죠. 앱에 대한 매뉴얼은 작성해야겠지만요.
그누보드5 이상의 무언가를 생각하신다면 심플한 패키지 조합 VS 라라벨 정도의 선택이 되지 않을까 생각합니다.
무엇으로 하시든 매뉴얼은 잘 갖춰지길 바랍니다. 매뉴얼은 제품과 함께 나와야 합니다. "조립 설명서는 한 달 뒤에 우편으로 별도 발송됩니다" 이상하잖아요. 사람도 보지만 AI에게도 더 잘 분석하는데 도움이 될겁니다.
저는 라라벨 별로 입니다. 내부 요소중에서 제가 모르는 부분이 많고, 깊게 이해할려면 라라벨 철학을 이해해야 하는 상황이 옵니다.
다른 사람의 개발 철학을 수긍하는게 좀 어렵다고 느낍니다. 코드를 만들때, 이 사람의 철학을 가급적 존중할려고 하거든요.
그래서 철학적인 접근이 많은 프레임웍을 안 좋아 합니다.(spring boot 도 그래서 안 좋아함)
철학적 이해없이 동작하는 프렘임웍은 그냥 동작만 하는 코드랑 크게 차이 없다는게 제 생각이고,
동작만 하는 코드 만들거면 굳이 라는 생각이 듭니다.
ai 가 만든 코드를 가장 빠르게 리뷰 가능한 프레임웍이 최고인것 같고, 그래서 가급적 간단한 구조, MVC 기본 구조, 중복없는 코드, 커버리지 높은 테스트 코드, 공통 라이브러리 최대 사용.
대략 이정도 claude.md 내용만 추가하고 알아서 만들라고 합니다.
제입장에서 최고는 멀티테넌트(분양형으로) ...
람다(노드,파이썬,go...등등)(걍함수 한부분인데 요청할때마다 컨테이너 하나뛰우는 개념) , s3(걍. html,css,next.js,플러터,뷰,리액터) + rds(오라라 db(걍 mysql인데 사용량에 따라 자동늘어났다,줄어들었다) + 클라우드프런트(캐쉬) 하는게 ...거의 정답입니다..... 한 구조안에 어떤건 html,css(그누보드식...걍 ajax로 람다함수에서 게시판,글쓰기,상세보기 한다고 생각하면됨 ) ,어떤건 nextjs, vue, 어떤건 앱 ....이런식으로 한 RDS안에서 다 가능 .... 람다 + s3 + RDS(오로라 ) + 클라우드프런트.... 거의 정답
라온보드와 호스팅 연결해서 작업도 했었고 이전에 공부하던 것도 있고 하니....^^
말만들었지 코드를 보지는 못했습니다.
그런데 막상 라라벨을 해보면 "진작에 할걸"하는 생각이 들지도 모르겠습니다
제가 아는 Php, Vanilla Js, Mysql로만 작업합니다.
비전공에 할줄 아는것이 이것뿐이라서요 ^^
이번에 sir개편하시느라 리자님이 마음고생, 몸고생 많이하셨을 듯 합니다.
고생 많이 하셨습니다. ^^
그누보드 스타일이라면 slim에 Plate 템플릿 엔진 조합이면 많은걸 참조하지 않는 자체 설계를 구현 해나갈 괜찮은 기반이 될 것 같습니다. Plate는 스코프를 분리해주고 템플릿에 제공할 헬퍼를 추가하는데 유용하더군요. ORM이 아닌 PDO 지원하는 wrapper 도 심플한 게 좀 있고요. slim 외에도 라우터 프레임워크는 더 있고, 잘 활성화되거나 유지보수 되는 것으로 잘 골라야겠죠.
자체 설계를 구현하기 어렵거나 더 나은 방법이 마땅치 않다면 라라벨을 선택하는게 현재로썬 가장 나은 방법 같습니다. 물론 라라벨을 쓴다고 전부 해결이 아니라 앱 구현 또한 잘 만들어야겠죠.
라라벨이나 심포니나 정말 잘 만들어지긴 했지만, 학습비용이 크고 일반 웹호스팅 환경에 어려움이 조금 있을 수 있습니다. 무엇보다 파일 수가 굉장히 많은 것부터 우리가 일반적으로 FTP 클라이언트로 업로드하는 것을 떠올리면 파일업로드부터 큰 작업이죠 ㅎㅎ
카페24 같은 호스팅에서도 composer나 라라벨의 artisan 명령어도 크게 문제 없이 사용할 수 있어서 큰 걸림돌은 없었습니다. git 도 사용 가능했고요.
만약 라라벨 버전의 그누보드를 생각하신다면 주 사용자층을 나눠서 생각하시면 좋을 것 같습니다.
기존 그누보드5 사용자 층과 모던 개발자 층을 나누어야하고 모두를 데려갈 수 없는 한계를 인정해야 합니다. 그누보드5가 극소수의 PHP 5.2 버전 환경 유지를 위해 많은 것을 포기해야 했고, 그로 인해 발전이 멈추고 과거에 머물 수 밖에 없던 문제를 인식해야 합니다.
그누보드의 PHP 5 지원은 이미 최소 5 년 전에 끊어냈어야 했다고 생각합니다. 적어도 5.4로만 올렸어도 많은 선택지가 생겼습니다. 그게 그누보드가 현대의 개발환경과 격차를 좁히지 못하게하는 가장 잘못된 판단이었습니다. 이제와서 그 격차를 좁히려면 아주 많은 것들을 한꺼번에 배워야만 하겠죠.
라라벨을 쓴다고 모두가 라라벨의 모든 것을 학습해야하는 건 아닙니다.
테마류는 블레이드 문법 정도만 익히고, 헬퍼 함수나 필요한 인터페이스를 적극적으로 제공하면 블레이드 문법에 헬퍼함수 정도만 학습하는 정도로 가능하겠죠. 플러그인도 이벤트를 잘 활용하고 플러그인 제작자에 헬퍼, 인터페이스를 제공하면 되겠죠. 라라벨을 쓴다고 써드파티 제작자 모두가 라라벨의 모든 부분을 익혀야 하지 않도록 앱을 잘 설계하여 제공하시면 됩니다. 어떤 것을 기반으로 하든 서드파티의 학습 비용은 프레임워크 레벨이 아닌 앱의 설계가 크게 좌우하게 되겠죠.
아무튼. slim 같은 라우터 같은 심플한 패키지들을 조합하는 방법은 설계 능력이 매우 크게 요구되고, 매뉴얼도 자체적으로 생산해야합니다.
라라벨을 이용한다면 학습 비용이 크지만 프레임워크 레벨의 매뉴얼은 영문이지만 매우 잘 되어있고 기계 번역으로 제공할 수 있고 사용할 수 있는 리소스도 매우 많죠. 앱에 대한 매뉴얼은 작성해야겠지만요.
그누보드5 이상의 무언가를 생각하신다면 심플한 패키지 조합 VS 라라벨 정도의 선택이 되지 않을까 생각합니다.
무엇으로 하시든 매뉴얼은 잘 갖춰지길 바랍니다. 매뉴얼은 제품과 함께 나와야 합니다. "조립 설명서는 한 달 뒤에 우편으로 별도 발송됩니다" 이상하잖아요. 사람도 보지만 AI에게도 더 잘 분석하는데 도움이 될겁니다.
사실 많은 개발자들이 처음에는 무엇을 만들 수 있느냐에 집중하다가, 시간이 지나면 만든 걸 어떻게 안정적으로 굴릴 수 있느냐로 고민이 옮겨가거든요
즉 요즘 기술은 돌아가게 만드는 것보다“계속 돌아가게 유지하는 것이 더 어렵습니다.
한마디로 배포, 보안 업데이트, 의존성 관리, 서버 환경 차이…등 이런 것들이 실제 운영에서 발목을 잡죠.
결국 운영자의 경험과 환경에 따라 최적의 선택은 달라질 수밖에 없다라는 점이지요.
젊어지신듯 .... ~_~
운영자가 어디까지 관여하고, 어디를 도구 사용으로 갈지가 중요한 것 같습니다.
어떤 프레임워크가 편하다고 느껴지는 지점도 결국 문법이나 유행의 문제가 아니라,
반복되는 공통 문제를 내가 다시 정의하지 않아도 되는 범위가
얼마나 넓은가에 가깝다고 느끼고요.
다만 그 편의는 운영 환경, 배포 방식에 따라
언제든 부담으로 바뀔 수 있다는 점도 동시에 체감합니다.
“더 나은 선택”을 찾기보다는
“지금 내가 감당 가능한 경계가 어디까지인가?”를 기준으로 가야 하지 않나 싶네요.
요즘은 그냥 지침만 만들어두고 만들게 시키고 검수만 하면 되는데 굳이 이제 프레임 워크를 써야 되나 싶습니다.