20년 5월에 작업했던 게시판 글쓰기 UI

요즘은 어떤게 트렌드인가요?

나름 커뮤니티(게시판)스러운 이용 패턴을 유지하면서도 요즘 잘나가는 서비스라면 오늘의집, 블라인드, 아하 같은 곳을 생각해 볼 수 있겠지요. 기본적으로 PC가 아닌 모바일 퍼스트이고, 모바일에서도 홈페이지를 먼저 만들어 놓고 웹뷰앱으로 랩핑했다기보다는, 웹뷰앱으로 램핑하기 위해 홈페이지를 만들었다는 느낌입니다.

즉, 앞으로 CMS의 가장 큰 역할은 아마 "앱을 운영하기 위한 백엔드"일 겁니다.

아하, 요 글의 포인트는 저 2000년대 레이아웃이 아니라 글쓰기 에디터 였습니다 ㅎ

저도 요즘 라이믹스 기반의 앱 쪽에 관심이 있고 예전부터 글을 썼는데

라이믹스 api 모듈을 만들고 RN, 플러터로 웹앱 만드는걸 해보려고 하고 있습니다.

혹시 코어 차원에서의 그런 지원은 기대할 수 없겠지요?

아, 제목 입력란까지 에디터 안에 들어가 있는 형태요?

요즘 앱이나 sns에서 에디터를 찾아 보세요. 아예 없는 경우가 대부분이고,

있는 경우에는 본문 중간에 이미지나 동영상을 삽입하는 용도에 최적화되어 있습니다.

폰트 바꾸고 색깔 바꾸고 이런 건 모바일이 대세가 되면서 인기가 팍 식었지요.

코어에서 무엇을 지원해 드려야 하죠?

모듈을 개발하는데 어떤 부분이 안 되더라, RN이랑 연동하는데 어디서 오류나더라 등등

구체적으로 아쉬운 부분이 있다면 말씀하시면 됩니다.

에디터 UI를 말씀드린 건데 설명드려야 좀 서로 소통이 될거 같군요

https://eond.com/threads/write

말씀주신 부분은 이런 식으로 구현해서 사용 중입니다.

유튜브 링크를 넣거나 하면 자동 변환됩니다.

요즘엔 말씀처럼 인라인 형태로 바뀌었죠. 저건 그래도 6년전에 작업한 버전이고,

나중에 에디터의 변천사도 살펴보면 재밌겠군요.

위 스샷에서 키 포인트를 집어드리자면

1. 뒤로가기, 저장하기의 UI 변경

보통은 푸터 쪽에 위치하지만 이 영역은 홈페이지로 말하자면 메뉴와 같습니다.

메뉴가 글쓰기 본문 크기에 가려져 너무 아래로 가거나 하면 이동을 하기 위해서 스크롤을 내려야 한다거나 하는 부분이 있겠죠. 그래서 항상 네비게이션처럼 보이게끔 위로 이동했습니다.

2. 에디터툴 위치의 변화

1과 마찬가지로 글쓰기에서 에디터가 크게 필요하지 않습니다. 그래서 에디터 기능은 있되, 진짜 중요한 제목과 본문을 더 강조한 UI입니다.

3. 제목과 본문의 위치

제목과 본문이 기본이 되게끔 배치했습니다. 중간에 에디터를 뺌으로써 가능하죠.

4. 확장필드의 인터페이스 변경

기존에는 아시다시 제목 아래 보통 테이블 형태로 존재하죠. 이걸 아래로 변경한 UI입니다.

코어 쪽에서 지원되는걸 어떤게 필요할까라고 묻는걸 보면

아마 코어를 담당하시다보니 굉장히 의미가 축소된거 같긴 한데요.

제 생각에는 그 방향성을 제시하는게 중요한거 같습니다.

그냥 돌아가는 선을 너머서 이것을 발전시켜야하는게 아닐까 하는게 제 생각입니다.

발전 방향에 대해서 논의하는 것이라면 꾸준히 말씀은 드렸지만 

모듈 개발의 어려움, 연동의 어려움은 지금쯤 되면 사실 개개인 개발자의 어려움일 듯 합니다.

이걸 여러명을 대상으로 교육을 한다던가 매뉴얼을 작성하는 영역은 아무리 회사의 형태지만 1인이 하기엔 어려운 요소라고 봅니다.

요즘 개발의 형태도 아시다시피 굳이 기존 사용자가 아니라면 라이믹스를 이용해 뭔가 만들려고 하는 사람들이 없습니다.

굳이 배포하지 않더라도 혼자 쓰기 간편한 형태의 툴이라면 next.js, nuxt.js + supabase, firebase 등으로 개발하는 추세기도 하고요. 그러면 이 역할, 이 시장을 라이믹스에서 가져올 수 있는건 안될까라고 고민해봤습니다.

전통적인 php+Database가 굳이 현재도 나쁜건 없다고 봅니다.

그렇다면 laravel + MySQL 조합보다 라이믹스 조합이 그보다 나쁜게 뭘까라고 생각해보면요.

1. 러닝커브와 문서화
   • Laravel은 체계적인 공식 문서, Laracasts 같은 교육 플랫폼, 방대한 커뮤니티 자료가 있습니다.
   • 라이믹스는 상대적으로 학습 자료가 부족하고, 모듈 개발 진입장벽이 높습니다.
   • 이건 AI를 활용한 기본 레이아웃 제작툴, 기본 모듈 제작툴(용도별) 등을 프롬프트 제공 가능하다고 봅니다.
2. 개발 생태계
   • Laravel은 Composer 생태계를 그대로 활용할 수 있고, 수많은 패키지를 쉽게 통합할 수 있습니다.
   • 라이믹스는 독자적인 구조로 인해 외부 라이브러리 통합이 상대적으로 번거롭습니다.
   • 유료든 무료든 신청하면 바로 내 웹에 바로 설치 가능한 코드를 제공한다던가 할 수 있겠죠
3. 현대적 개발 경험
   • Laravel은 Artisan CLI, 마이그레이션, Eloquent ORM, Queue, Event 등 현대적인 개발 도구를 제공합니다.
   • 라이믹스는 이런 부분이 부족하거나 직관적이지 않습니다.
   • 하지만 아직도 개별적으로 XE 개발을 하는 분들은 심심찮게 보이는 거 같습니다. 그 분들의 도움을 받아서 서로 으샤으샤하면 좀 더 쉬운 개발 방법이 나오지 않을까요.
4. API 우선 설계
   • 요즘은 프론트엔드 분리가 일반적인데, Laravel은 API 개발에 최적화되어 있습니다.
   • 라이믹스는 전통적인 서버 렌더링 방식에 더 최적화되어 있습니다.

그렇다면 라이믹스가 가져갈 수 있는 방향은

저는 라이믹스의 강점을 이렇게 봅니다:

• 즉시 사용 가능한 CMS: 설치 후 바로 글쓰기, 회원관리, 권한관리가 가능
• 한국 환경에 최적화: 본인인증, 결제 등 한국 서비스에 필요한 기능(일부 유료)
• 레거시 안정성: 오랜 기간 검증된 코드베이스

하지만 이것만으로는 새로운 개발자를 유입시키기 어렵습니다.

1. Headless CMS 모드 지원
   • 라이믹스를 백엔드 API 서버로만 사용
   • Next.js, Nuxt.js와 쉽게 연동할 수 있는 REST/GraphQL API 제공
   • 프론트엔드는 자유롭게, 백엔드는 라이믹스의 안정성 활용
2. CLI 도구 개선
   • rhymix make:module, rhymix make:widget 같은 명령어로 스캐폴딩
   • 개발 서버, 테스트 환경 쉽게 구축
3. 컴포넌트 기반 개발
   • 모듈보다 작은 단위의 재사용 가능한 컴포넌트
   • npm처럼 쉽게 설치하고 사용할 수 있는 패키지 매니저
4. 개발자 경험(DX) 개선
   • 타입힌트, IDE 자동완성 지원 강화
   • 명확한 에러 메시지와 디버깅 도구
   • 단계별 튜토리얼과 예제 프로젝트

결국 핵심은 "라이믹스로 뭔가를 만드는 게 더 쉽고 빠르다"는 경험을 제공하는 것입니다.

지금은 "라이믹스를 배우는 것"이 장벽이 되고 있는데, 이걸 "라이믹스 위에서 바로 만들 수 있다"로 바꿔야 한다고 봅니다.

1인 코어 개발자 입장에서 보면 허황된 이야기일 수도 있지만, 요즘의 환경에서 라이믹스로 개발이 명함도 못 내미는 거 같아서 -_-; 이걸 요즘 MZ들에게 어떻게 어필할까 막 써봤습니다;

라이믹스도 커뮤니티 제작 CMS를 넘어 개발툴로써의 역할을 기대할 수 있을거 같아서 주저리 써봤습니다. 

요즘 개발하시는 분들보면 진짜 혼자서도 뚝딱이거나 뭔가 형태만 갖춰지면 요즘 해외 오픈소스툴처럼 공식홈에서 그런 컴포넌트 개발 방법을 매뉴얼화해서 배포하던가 그런 사이트들이 종종 보이더라구요.

https://devup-ui.com/components/overview

이건 단순 ui 이긴 하지만 이런 형태로 라이믹스 모듈 등도 이런 UI로 아이디어를 내볼 수 있지 않을까 하는 생각을 해봤습니다.

일련의 구체적인 개선 요청으로 정리되지 않는 의견은 한 귀로 듣고 한 귀로 흘려버리는 것은 어떤 오픈소스 프로젝트라도 똑같습니다. 모든 개발자가 모든 분야에 관심을 가지고 전문가가 될 수는 없으니, 각자 관심있는 분야에 대해서 구체적인 방향성을 제시해 주어야 합니다. 큰 변화도 작은 패치가 모여서 이루어져야지, 누가 갑자기 확 고쳐버리면 다른 사람들이 못 따라오죠.

예) 타입힌트, IDE 자동완성 지원 강화

라이믹스 프레임워크를 구성하는 대부분의 클래스와 함수들은 타입 선언이 되어 있고, VSCode + PHP Intelephense와 같은 오픈소스 IDE 환경에서 자동완성이 지원됩니다. 그러나 document 모듈, member 모듈 같은 부분은 타입 선언이 빠진 곳이 많죠. 그렇다면 이런 부분의 타입 선언도 제대로 하자고 제안할 수 있습니다. 특정 IDE와의 호환성을 개선해 볼 수도 있겠고요. 아무튼 목표가 분명해야 어떤 결과라도 나옵니다.

예) 모듈보다 작은 단위의 재사용 가능한 컴포넌트

UI 구성을 위한 컴포넌트인가요? 아니면 API나 그 밖의 백엔드 기능에 사용할 컴포넌트인가요? 무엇이 아쉬운지 구체적으로 제시하지 않으면 플러그인을 만들자는 건지 위젯을 만들자는 건지 알 수가 없습니다.

예) 명확한 에러 메시지와 디버깅 도구

기존 라이믹스의 디버그 기능을 타 프레임워크의 디버깅 도구와 비교했을 때 어떤 부분이 아쉬운지, 무엇을 도입했으면 좋겠는지, 어떤 오류를 잡기가 가장 어려운지 등등

이온디님은 경험도 풍부하시고 아이디어도 많이 갖고 계신데, 그 아이디어를 이렇게 차근차근 풀어서 제시하는 데 서투르셔서 흐지부지되거나 묻혀버리는 경우가 많은 것이 아쉽습니다.

코어 차원에서 지원이 필요하다면 어떤 게 가능할까 해서 예를 들어 이런걸 생각해볼 수 있지 않을까 해서 말씀드린 부분이고, 저도 구체적으로 방향을 제시하거나 디벨롭할 수 있는 수준은 못 됩니다. ^^;

저도 다방면 잡부라서 이것저것 경험이 많을 뿐, 아이디어 제시 정도 밖엔 할 줄 아는게 없습니다. ㅠㅠ

하나씩 하자면 한 개마다 엄청난 공수가 투입이 되다보니 현실적으로 참 많이 어려운 줄은 압니다.

그 중에서도 차근차근 하나씩 풀어가야한다면 최우선 과제가 기진님께서도 언급하신 바와 같이 헤드리스CMS로써 API 모듈을 개발해서 앱을 운영하기 위한 백 시스템일 거 같습니다.

물론 이전에도 이건 코어 차원이 아니라 각 개발 써드파티마다 개발을 해야한다고 하셔서 이 부분부터 좀 파보는 중입니다.

개인적인 생각으로는 코어에서 지원해주었으면 하는 바람이긴 하지만요.

잘만든다고 되는게 아니라 잘 만들어져있게끔 포장하는게 굉장히 중요하다는 걸 느낍니다.

아이돌들이 대형기획사 하는 이유처럼-_-;; 홍보 마케팅이 엄청난 영역이라는걸 네이버를 떠난 뒤에야 알게 됐습니다. ㅠ