Rails, Livewire, Phoenix, React용으로 CKEditor 연동을 직접 해본 경험이 있음. 그 중에서 개발자 경험으로는 Phoenix가 가장 인상적이었음. 프레임워크가 매우 잘 설계되어 있어서 통합 작업이 정말 단순했음. Rails와 React, 특히 Next.js에서는 이런 만족감을 전혀 느끼지 못했음. Next.js는 라우터 변경도 너무 자주 일어나고, 매번 바뀌어서 신뢰할 수가 없음. Livewire는 Phoenix랑 비슷한 느낌이지만, 상대적으로 덜 직관적이고 기능이 부족함. 예를 들어 Livewire는 컴포넌트 슬롯을 지원하지 않는데, Phoenix는 문제없이 처리함. 슬롯이 없으면 템플릿 구조가 엉망이 되고, 코드도 불필요하게 복잡해짐. 누구든 궁금하면 ckeditor5-phoenix 깃허브 참고 바람
PHP(Laravel)와 JQuery조합도 2025년까지는 여전히 쓸만함. 그러나 Livewire는 개인적으로 쓰고 싶지 않음. Node.js는 생산성이 떨어질 수 있지만, 더 강력한 기능이 필요할 때 쓸만함. 비동기/await, socket.io, 타입스크립트 모두 지원함. Next.js는 SEO와 대화형 UI 모두 필요한 경우에 유용하긴 하지만, 실제로 이 모든 게 동시에 필요한 웹사이트가 몇이나 있겠음? LinkedIn 같은 서비스 정도만 해당될 듯함
Livewire가 Phoenix의 카피라고는 생각하지 않음. 이름만 봐선 그럴 듯하지만, 두 프로젝트 모두 거의 동시에 시작된 걸로 알고 Livewire가 오히려 더 오래된 프로젝트임. Hotwire가 그 중 가장 늦게 나옴. 두 프로젝트가 서로 다른 접근 방법을 취하는데, PHP와 Elixir는 특성이 너무 다름. Livewire도 꽤 유용하다고 생각함. PHP에서 웹소켓을 쉽게 쓸 수 없어서 http 위주로 동작하는데, 대부분 상황에선 그걸로도 충분함. 오히려 Liveview의 웹소켓은 과할 수 있음
Rails에서의 문제 경험에 대해 구체적으로 궁금함. 어떤 부분이 힘들었는지 듣고 싶음
Rails 사용 시 어떤 점이 어려웠는지 궁금함
Livewire 4에서는 컴포넌트 슬롯 지원 예정임. 하지만 아직 몇 주 남았음. 새로운 버전에서는 성능 및 개발 편의성 향상도 있다고 함
이 글은 작성자가 본인이 선택한 프레임워크를 옹호하고, 타 프레임워크의 기능은 일부러 무시하는 듯한 글임. Phoenix의 장점으로 언급한 부분은 Rails에도 다 있음. 또한, Rails가 프론트엔드와 웹소켓 소통을 지원하지 않는다는 뉘앙스를 풍기는데, Rails로 최근 3년간 앱을 만들어본 사람이라면 완전히 틀린 얘기임. 물론 Phoenix, LiveView도 좋은 도구임엔 틀림없지만, 내가 Rails를 계속 쓰는 이유는 Hotwire Native 덕분임. 모바일과 웹 앱 모두 빠른 시간 안에 혼자서 만들 수 있어서 생산성 측면에서 엄청 큰 이점임
Ruby는 별로 써본 적 없지만, 커뮤니티 말고 Ruby on Rails가 Elixir & Phoenix보다 뛰어난 점이 궁금함. BEAM 플랫폼 덕분에 소프트 실시간 시스템, 장애 허용, NIFs, actor model, 수많은 경량 프로세스, 생각하기 쉬운 동시성, 함수형 프로그래밍, OTP, 끊기지 않는 GC 등 Phoenix가 이론상 월등히 좋다고 생각함. 물론 본인이 좋아하는 걸 쓰면 되고 Hotwire Native도 한번 써볼 예정임
Rails도 웹소켓으로 프론트와 통신할 수 있다는 건 명확함. 실제로 나는 Rails 개발자이지만, 대량의 지속적인 소켓 연결이 필요하다면 Phoenix를 선택하겠음. Phoenix는 Gigalixir 같은 서비스에서 훨씬 값싸고 쉽게 10만개 소켓 연결을 커버할 수 있음. 만약 직접 인프라 관리한다면 얘기는 달라짐. 하지만 Heroku로는 수천 개의 연결조차 어렵고, 가격도 부담됨
글에서 Rails가 프론트와 웹소켓 통신을 지원하지 않는다고 했던 부분이 어디인지 궁금함. 원문에서는 "Rails와 Laravel에서 다 가능한 일이지만 세팅에 시간이 조금 더 든다"고만 함. 이건 완전히 다른 뉘앙스임
Rails + Hotwire 조합도 정말 강력함, Hotwire Native까지 더해지면 더 좋음. 이 글의 요점은 Phoenix와 LiveView가 더 낫다는 게 아니라, LiveView의 구조(서버 주도 상태, 프로세스 분리, 경량 채널 등)이 특정 상황에서 적합하다는 것임. 두 생태계 모두 비슷한 문제를 서로 다르게 풀어나가고 있음. Rails는 컨벤션과 점진적 강화, Phoenix는 BEAM의 동시성과 장애 허용으로 접근함. 결국 중요한 건 어떤 구조가 자신이 만드는 제품에 더 잘 맞는가임
Hotwire Native는 예전에 들어봤는데 그 뒤로 소식이 잠잠했던 것 같음. 실제 모바일 앱에 써본 경험, 지원이나 문서, 구현 완성도가 궁금함
나 역시 Elixir에 대해 글쓴이 못지않게 긍정적인 감정을 갖고 있지만, CTO로서 3년간 운영 환경에서 쓴 결과는 규모가 커질수록 아쉬움도 컸음. BEAM(동시성, 장애허용력)은 약속을 잘 지켰고 Ecto, Oban, 원격 iex, 인재 풀까지 모두 훌륭했음. 하지만 개발자 경험(DX)은 점점 병목이 됐음. 30만 줄짜리 대형 프로젝트에서 다음과 같은 문제가 있었음:
컴파일 시간: 코드 한 줄 바꿔도 개발 환경에서 10초 이상 컴파일이 걸리면서 몰입이 자꾸 깨짐
툴링: ElixirLS 자동완성이 신뢰할 수 없어서, 함수명이나 스키마 필드를 검색하느라 시간 소모
LiveView: 복잡한 UI엔 적합하지 않아 어쩔 수 없이 리액트 프론트엔드를 도입했고, 결국 GraphQL과 스택 분할이라는 복잡성이 그대로 돌아옴
장기적으로 쓸 스택 고민 중이라면 3년 Retrospective 읽어보면 도움될 것임
Elixir에서 개발환경 컴파일 한 번에 10초 넘게 걸린다는 점이 매우 놀라움. Elixir는 Rails보다 이득이 더 많다고만 들어왔었기에 실제 현업에서 이런 사례가 흔한지 궁금함
나도 Elixir를 배우며 비슷한 경험했음. 언어는 마음에 들었지만 윈도에서 WSL로 작업하니 LSP가 자주 깨져서 불편했음. 공식 LSP가 곧 출시될 예정이라 이 부분이 확 좋아지길 기대함
LiveView나 React처럼 프론트엔드가 잘 관리되지 않으면 대규모 앱에서 금방 코드가 난잡해짐. 인원이 늘수록 코드 리뷰와 불필요한 로직 정리가 반드시 필요함. 이 부분은 모든 프레임워크가 마찬가지인 듯함. 앞으로도 개선 여지가 정말 많음
"백그라운드 잡, 실시간 업데이트, 양방향 통신을 가볍게 지원하는 것은 Rails와 Laravel에서도 약간의 설정만 추가하면 다 할 수 있다"고 주장하는데, Rails는 기본으로 Solid Queue(잡), Solid Cable(실시간 메시징) 지원함
최근 Rails로 넘어간 입장에서 SolidQueue는 정말 간단하게 기본세팅만으로 바로 쓸 수 있음. Solid Queue Dashboard까지 붙이면 전체 상황을 한눈에 볼 수도 있음
실시간 메시징만 따지면 Solid Cable 설정이 LiveView보다는 번거롭다고 느낌. LiveView는 렌더링까지 알아서 해주기 때문에 Rails의 SolidCable 개발보다 훨씬 앞서 있다고 생각함
모든 기능은 Rails로도 가능함. 참 아름다운 프레임웍이고, Phoenix로 하면 더 쉽고 쾌적함. 꼭 한번 써보길 추천함
Rails와 Elixir 모두 현업에서 써본 입장에서 전달하자면, 두 시스템은 절대 동등하지 않음. Oban은 사용법이 명확하고 재작업도 단순히 DB 컬럼만 업뎃하면 Oban supervisor가 알아서 잘 처리해줌. Solid Queue는 성공한 잡을 다시 돌릴 쉬운 방법이 없음. 테이블 수도 너무 많아 관리가 힘듦. Oban은 그냥 단순하게 두 테이블만 관리하고 같은 앱에서 자연스럽게 작동하고, Solid Queue는 여러 블로그 참고해서 세팅값 바꿔야 정상 동작함. 기본 설정이 부족함. Erlang/Elixir의 특성 덕분에 Oban은 아주 단순하게 만들고도 뛰어나게 동작해서 개발자로서 기쁨. Solid Queue는 어쩔 수 없이 쓰고 있음
오랫동안 Rails 개발을 해오다가, 요즘은 Phoenix/Elixir가 기본 스택이 됨. Rails가 아직 CRUD 앱을 빠르게 만드는 데는 정말 최고이고, 그 부분에서는 단연 우수함. 하지만 복잡도가 커지고 시간이 지날수록 Phoenix/Elixir가 종합적으로 더 나은 도구임
LLM 등장 이후 이런 간단한 앱은 몇 분 만에 생성 가능해짐. 다만, 신경 써야 하는 주요 부분에 대해선 Phoenix가 더 많은 제어권을 주는 느낌임
어떤 점이 더 잘 맞는지, 무엇이 더 뛰어나다고 느끼는지 좀 더 구체적으로 듣고 싶음
"우리는 문제를 최적의 방식으로 해결하기 위해 코드를 짠다"는 글귀에는 본인의 열정을 느낄 수 있음. 나는 해결만 되면 적당히 만족하는 편이기 때문에 Rails에 머무르는 게 더 맞는 것 같음
그 문장을 보고 웃음이 터졌음. 현실적으로 코드를 최적화만 생각하며 짜면 결국 일이 더디게 진행됨. 나에게는 코딩이 생계 수단이기도 하고, 때로는 재미삼아 하는 것이기도 함
Elixir는 커뮤니티 규모가 작다고들 하지만, 최첨단 라이브러리로 꽤 높은 수준에 도전하고 있음. 예전 개발자 한 명이 "적을수록 더 낫다"는 말을 했던 게 떠오름. elixir-dbvisor/sql 같이 좋은 오픈소스도 많음
반대로 JS 생태계는 크기가 너무 커서 힘들게 느껴짐. 10가지 라이브러리가 각자 독립적으로 존재하고, 아무도 표준을 따르지 않음. 미국 대형 마트에서 메뉴 고르거나, Vercel 체인 레스토랑에서 강제 선택하는 것과 비슷함
Elixir의 진면목을 느끼고 싶다면 Saša Jurić의 강연 영상을 전부 보길 추천함
Saša Jurić는 'Elixir in Action' 책을 쓴 저자로, 책도 정말 훌륭함
이 글은 프레임워크 전체보다 Phoenix LiveView에 초점을 맞춘 내용임. 실제로 Phoenix에서 LiveView를 생성 옵션에서 빼더라도 기본 LV 코드가 여기저기 남아있는 점이 싫음
나도 LiveView가 매우 의견이 확고하고 보일러플레이트가 많다는 점에 공감함. 엘릭서의 간결성, 표현력을 좋아하는데 LiveView는 그 반대라 느껴짐
Elixir를 선택하지 않은 유일한 이유가 타입체커 부재였음. 혹시 변화가 생겼는지 궁금함
Hacker News 의견
Rails, Livewire, Phoenix, React용으로 CKEditor 연동을 직접 해본 경험이 있음. 그 중에서 개발자 경험으로는 Phoenix가 가장 인상적이었음. 프레임워크가 매우 잘 설계되어 있어서 통합 작업이 정말 단순했음. Rails와 React, 특히 Next.js에서는 이런 만족감을 전혀 느끼지 못했음. Next.js는 라우터 변경도 너무 자주 일어나고, 매번 바뀌어서 신뢰할 수가 없음. Livewire는 Phoenix랑 비슷한 느낌이지만, 상대적으로 덜 직관적이고 기능이 부족함. 예를 들어 Livewire는 컴포넌트 슬롯을 지원하지 않는데, Phoenix는 문제없이 처리함. 슬롯이 없으면 템플릿 구조가 엉망이 되고, 코드도 불필요하게 복잡해짐. 누구든 궁금하면 ckeditor5-phoenix 깃허브 참고 바람
PHP(Laravel)와 JQuery조합도 2025년까지는 여전히 쓸만함. 그러나 Livewire는 개인적으로 쓰고 싶지 않음. Node.js는 생산성이 떨어질 수 있지만, 더 강력한 기능이 필요할 때 쓸만함. 비동기/await, socket.io, 타입스크립트 모두 지원함. Next.js는 SEO와 대화형 UI 모두 필요한 경우에 유용하긴 하지만, 실제로 이 모든 게 동시에 필요한 웹사이트가 몇이나 있겠음? LinkedIn 같은 서비스 정도만 해당될 듯함
Livewire가 Phoenix의 카피라고는 생각하지 않음. 이름만 봐선 그럴 듯하지만, 두 프로젝트 모두 거의 동시에 시작된 걸로 알고 Livewire가 오히려 더 오래된 프로젝트임. Hotwire가 그 중 가장 늦게 나옴. 두 프로젝트가 서로 다른 접근 방법을 취하는데, PHP와 Elixir는 특성이 너무 다름. Livewire도 꽤 유용하다고 생각함. PHP에서 웹소켓을 쉽게 쓸 수 없어서 http 위주로 동작하는데, 대부분 상황에선 그걸로도 충분함. 오히려 Liveview의 웹소켓은 과할 수 있음
Rails에서의 문제 경험에 대해 구체적으로 궁금함. 어떤 부분이 힘들었는지 듣고 싶음
Rails 사용 시 어떤 점이 어려웠는지 궁금함
Livewire 4에서는 컴포넌트 슬롯 지원 예정임. 하지만 아직 몇 주 남았음. 새로운 버전에서는 성능 및 개발 편의성 향상도 있다고 함
이 글은 작성자가 본인이 선택한 프레임워크를 옹호하고, 타 프레임워크의 기능은 일부러 무시하는 듯한 글임. Phoenix의 장점으로 언급한 부분은 Rails에도 다 있음. 또한, Rails가 프론트엔드와 웹소켓 소통을 지원하지 않는다는 뉘앙스를 풍기는데, Rails로 최근 3년간 앱을 만들어본 사람이라면 완전히 틀린 얘기임. 물론 Phoenix, LiveView도 좋은 도구임엔 틀림없지만, 내가 Rails를 계속 쓰는 이유는 Hotwire Native 덕분임. 모바일과 웹 앱 모두 빠른 시간 안에 혼자서 만들 수 있어서 생산성 측면에서 엄청 큰 이점임
Ruby는 별로 써본 적 없지만, 커뮤니티 말고 Ruby on Rails가 Elixir & Phoenix보다 뛰어난 점이 궁금함. BEAM 플랫폼 덕분에 소프트 실시간 시스템, 장애 허용, NIFs, actor model, 수많은 경량 프로세스, 생각하기 쉬운 동시성, 함수형 프로그래밍, OTP, 끊기지 않는 GC 등 Phoenix가 이론상 월등히 좋다고 생각함. 물론 본인이 좋아하는 걸 쓰면 되고 Hotwire Native도 한번 써볼 예정임
Rails도 웹소켓으로 프론트와 통신할 수 있다는 건 명확함. 실제로 나는 Rails 개발자이지만, 대량의 지속적인 소켓 연결이 필요하다면 Phoenix를 선택하겠음. Phoenix는 Gigalixir 같은 서비스에서 훨씬 값싸고 쉽게 10만개 소켓 연결을 커버할 수 있음. 만약 직접 인프라 관리한다면 얘기는 달라짐. 하지만 Heroku로는 수천 개의 연결조차 어렵고, 가격도 부담됨
글에서 Rails가 프론트와 웹소켓 통신을 지원하지 않는다고 했던 부분이 어디인지 궁금함. 원문에서는 "Rails와 Laravel에서 다 가능한 일이지만 세팅에 시간이 조금 더 든다"고만 함. 이건 완전히 다른 뉘앙스임
Rails + Hotwire 조합도 정말 강력함, Hotwire Native까지 더해지면 더 좋음. 이 글의 요점은 Phoenix와 LiveView가 더 낫다는 게 아니라, LiveView의 구조(서버 주도 상태, 프로세스 분리, 경량 채널 등)이 특정 상황에서 적합하다는 것임. 두 생태계 모두 비슷한 문제를 서로 다르게 풀어나가고 있음. Rails는 컨벤션과 점진적 강화, Phoenix는 BEAM의 동시성과 장애 허용으로 접근함. 결국 중요한 건 어떤 구조가 자신이 만드는 제품에 더 잘 맞는가임
Hotwire Native는 예전에 들어봤는데 그 뒤로 소식이 잠잠했던 것 같음. 실제 모바일 앱에 써본 경험, 지원이나 문서, 구현 완성도가 궁금함
나 역시 Elixir에 대해 글쓴이 못지않게 긍정적인 감정을 갖고 있지만, CTO로서 3년간 운영 환경에서 쓴 결과는 규모가 커질수록 아쉬움도 컸음. BEAM(동시성, 장애허용력)은 약속을 잘 지켰고 Ecto, Oban, 원격 iex, 인재 풀까지 모두 훌륭했음. 하지만 개발자 경험(DX)은 점점 병목이 됐음. 30만 줄짜리 대형 프로젝트에서 다음과 같은 문제가 있었음:
장기적으로 쓸 스택 고민 중이라면 3년 Retrospective 읽어보면 도움될 것임
Elixir에서 개발환경 컴파일 한 번에 10초 넘게 걸린다는 점이 매우 놀라움. Elixir는 Rails보다 이득이 더 많다고만 들어왔었기에 실제 현업에서 이런 사례가 흔한지 궁금함
나도 Elixir를 배우며 비슷한 경험했음. 언어는 마음에 들었지만 윈도에서 WSL로 작업하니 LSP가 자주 깨져서 불편했음. 공식 LSP가 곧 출시될 예정이라 이 부분이 확 좋아지길 기대함
LiveView나 React처럼 프론트엔드가 잘 관리되지 않으면 대규모 앱에서 금방 코드가 난잡해짐. 인원이 늘수록 코드 리뷰와 불필요한 로직 정리가 반드시 필요함. 이 부분은 모든 프레임워크가 마찬가지인 듯함. 앞으로도 개선 여지가 정말 많음
"백그라운드 잡, 실시간 업데이트, 양방향 통신을 가볍게 지원하는 것은 Rails와 Laravel에서도 약간의 설정만 추가하면 다 할 수 있다"고 주장하는데, Rails는 기본으로 Solid Queue(잡), Solid Cable(실시간 메시징) 지원함
최근 Rails로 넘어간 입장에서 SolidQueue는 정말 간단하게 기본세팅만으로 바로 쓸 수 있음. Solid Queue Dashboard까지 붙이면 전체 상황을 한눈에 볼 수도 있음
실시간 메시징만 따지면 Solid Cable 설정이 LiveView보다는 번거롭다고 느낌. LiveView는 렌더링까지 알아서 해주기 때문에 Rails의 SolidCable 개발보다 훨씬 앞서 있다고 생각함
모든 기능은 Rails로도 가능함. 참 아름다운 프레임웍이고, Phoenix로 하면 더 쉽고 쾌적함. 꼭 한번 써보길 추천함
Rails와 Elixir 모두 현업에서 써본 입장에서 전달하자면, 두 시스템은 절대 동등하지 않음. Oban은 사용법이 명확하고 재작업도 단순히 DB 컬럼만 업뎃하면 Oban supervisor가 알아서 잘 처리해줌. Solid Queue는 성공한 잡을 다시 돌릴 쉬운 방법이 없음. 테이블 수도 너무 많아 관리가 힘듦. Oban은 그냥 단순하게 두 테이블만 관리하고 같은 앱에서 자연스럽게 작동하고, Solid Queue는 여러 블로그 참고해서 세팅값 바꿔야 정상 동작함. 기본 설정이 부족함. Erlang/Elixir의 특성 덕분에 Oban은 아주 단순하게 만들고도 뛰어나게 동작해서 개발자로서 기쁨. Solid Queue는 어쩔 수 없이 쓰고 있음
오랫동안 Rails 개발을 해오다가, 요즘은 Phoenix/Elixir가 기본 스택이 됨. Rails가 아직 CRUD 앱을 빠르게 만드는 데는 정말 최고이고, 그 부분에서는 단연 우수함. 하지만 복잡도가 커지고 시간이 지날수록 Phoenix/Elixir가 종합적으로 더 나은 도구임
LLM 등장 이후 이런 간단한 앱은 몇 분 만에 생성 가능해짐. 다만, 신경 써야 하는 주요 부분에 대해선 Phoenix가 더 많은 제어권을 주는 느낌임
어떤 점이 더 잘 맞는지, 무엇이 더 뛰어나다고 느끼는지 좀 더 구체적으로 듣고 싶음
"우리는 문제를 최적의 방식으로 해결하기 위해 코드를 짠다"는 글귀에는 본인의 열정을 느낄 수 있음. 나는 해결만 되면 적당히 만족하는 편이기 때문에 Rails에 머무르는 게 더 맞는 것 같음
Elixir는 커뮤니티 규모가 작다고들 하지만, 최첨단 라이브러리로 꽤 높은 수준에 도전하고 있음. 예전 개발자 한 명이 "적을수록 더 낫다"는 말을 했던 게 떠오름. elixir-dbvisor/sql 같이 좋은 오픈소스도 많음
Elixir의 진면목을 느끼고 싶다면 Saša Jurić의 강연 영상을 전부 보길 추천함
이 글은 프레임워크 전체보다 Phoenix LiveView에 초점을 맞춘 내용임. 실제로 Phoenix에서 LiveView를 생성 옵션에서 빼더라도 기본 LV 코드가 여기저기 남아있는 점이 싫음
Elixir를 선택하지 않은 유일한 이유가 타입체커 부재였음. 혹시 변화가 생겼는지 궁금함