# zod.kr 개발 7개월, 오픈 5개월 후기 - CMS 선택 및 개발편

> Clean Markdown view of GeekNews topic #20222. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=20222](https://news.hada.io/topic?id=20222)
- GeekNews Markdown: [https://news.hada.io/topic/20222.md](https://news.hada.io/topic/20222.md)
- Type: news
- Author: [dofuuz](https://news.hada.io/@dofuuz)
- Published: 2025-04-09T09:32:22+09:00
- Updated: 2025-04-09T09:32:22+09:00
- Original source: [ake.kr](https://ake.kr/2025/04/02/zod-kr-publish-after-5-month-cms-review)
- Points: 13
- Comments: 2

## Summary

국내 커뮤니티인 Zod 사이트 구축을 위해 **Rhymix**를 선택했으며, 이는 **XE 기반**으로 친숙하고 구조 개선 및 확장성이 뛰어나다는 이유 때문입니다. Rhymix는 **Composer**, **모듈화 구조**, **캐시 지원** 등 현대적 기능을 제공하지만, 구식 관리자 UI와 문서 부족 등의 단점도 있습니다. 사이트 구축 과정에서 **웹 푸시**, **이벤트 관리** 등 다양한 기능을 자체 구현하며 안정적으로 운영 중이며, 많은 시행착오 끝에 Rhymix를 통해 안정적인 사이트를 성공적으로 구축했습니다.

## Topic Body

https://news.hada.io/topic?id=19746 의 후속 글입니다.  
  
국내 커뮤니티 사이트를 구축하기 위해 Rhymix를 선택한 이유와 Rhymix를 통한 사이트 개발 과정을 다룹니다.  
  
이하 ChatGPT 요약입니다.  
  
----  
  
**zod.kr CMS 선택 및 개발 후기 요약 (간단 요약)**  
  
- **배경:** 한국 CMS 환경이 너무 낡았다고 판단, 하지만 현실적 이유로 새로 만들지 않고 기존 CMS 사용을 결정.  
- **CMS 비교:**  
  - **그누보드5:** 코드 품질, 보안, 구조 문제로 제외.  
  - **Rhymix:** XE 기반으로 친숙하고, 구조 개선·모던 문법 지원·확장성 좋음 → 최종 선택.  
- **Rhymix 장점:**  
  - Composer, 모듈화 구조, 캐시 지원, 비동기 큐 등 현대적 기능 다수.  
- **단점:**  
  - 구식 관리자 UI, 불완전한 서드파티, 문서 부족 등.  
- **디자인:** 반응형 테마 활용 + 수많은 버그 수정 및 CSS/JS 개선.  
- **기능 추가:**  
  - 웹 푸시, 이벤트 관리, R2 연동 업로드, 사용자 기능 등 다수 자체 구현.  
- **모듈 개발:** 매뉴얼 부족 → 코드 분석 + 직접 구조 파악하며 구현.  
  
👉 요약: 낡은 CMS 환경 속에서 현실적인 선택으로 Rhymix를 택했고, 많은 시행착오와 커스터마이징을 통해 zod.kr을 안정적으로 구축함.

## Comments



### Comment 36996

- Author: jujumilk3
- Created: 2025-04-10T12:47:05+09:00
- Points: 1

실제 사이트 개발과 운영까지 너무 귀중한 자료 감사합니다 잘 보고 있습니다

### Comment 36960

- Author: nemorize
- Created: 2025-04-09T17:16:35+09:00
- Points: 2

XE1 초창기때부터 Rhymix까지 십수년간 써오고 있는 유저 입장에서 공감이 많이 가는 내용이네요.  
  
라이믹스가 타게팅하는 시장의 다수가 직접 개발할 능력이 충분하지 못하다는 점이 제일 큰 문제라고 봅니다.  
  
직접 개발할 능력이 되는 사람들은 XE나 라이믹스의 부족한 문서, 애매한 구조와 레거시들을 감수하기보단, 라라벨 등을 채택하는 경우가 많을거구요.  
  
원글 저자분과 마찬가지로, 저 또한  
1. 많은 사람들이 익숙하게 느낄만한 관리자 페이지  
2. 아쉬움은 있어도 부족함은 없는 CMS로서의 기능들  
3. 새로운 제안들을 적극적으로 반영하는 코어 개발팀  
4. 오랫동안 써온 정  
등등 때문에라도 몇몇 새 프로젝트에서 라이믹스를 채택하고 있습니다만, 매번 이 선택이 올바른 선택일지 고민을 많이 하게 되네요.  
  
라이믹스를 프레임워크 대용으로 사용하며 아쉬웠던 부분들을 보완하고자 개인적으로 여러 시도를 해 보고 있는데요.  
https://github.com/nemorize/rx-make (develop 브랜치 / PoC 프로젝트로 프로덕션 예정 없음)  
  
라이믹스를 통째로 프레임워크/라이브러리화 해버린다던가, 레거시 API의 접근을 최소화하고, 좀 더 모던한 API를 (레거시와 얼추 호환되게) 재구축하는 등의 여러가시 시도를 해 보고 있지만... 진짜 정말 많이 고민이 됩니다ㅎㅎ..  
  
이 고민을 명확하게 정리해 본 적이 없었는데, 이 기회에 한번 명료하게 정리해 봐야겠어요.