▲

Rails, Laravel, Next.js 대신 Elixir Phoenix 를 선택한 이유

 (akarshc.com)
6P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • Phoenix LiveView는 애플리케이션 속도와 개발 속도 모두에서 높은 효율성을 제공함
  • Frontend와 backend를 각각 유지관리할 필요 없이, 하나의 언어로 모놀리식하게 처리할 수 있는 점이 장점
  • Rails Hotwire와 Laravel Livewire도 고려했지만, 실시간성 및 백그라운드 작업 구현에서 더 많은 설정이 필요함
  • Elixir의 Phoenix 프레임워크는 Ruby on Rails의 우아함을 유지하면서도 훨씬 뛰어난 성능을 제공하며, Oban을 통한 백그라운드 작업이 기본 내장되어 있고, 익숙하고 깔끔한 문법을 지원
  • LiveView는 WebSocket 기반으로 실시간 양방향 업데이트를 제공하며, 전통적인 서버 렌더링과 프론트엔드 중심 프레임워크의 균형을 이루고, 필요시 Alpine.js나 JavaScript 라이브러리를 훅을 통해 사용 가능
  • Elixir/Erlang 기반의 빠른 개발 속도, 높은 동시성 처리, 단일 언어로 대부분 작성 가능, 컴파일러를 통한 버그 사전 차단, 장애 허용 구조등이 최종 선택의 결정적 요인

왜 Phoenix LiveView를 선택했는가

  • 코딩의 목적은 문제를 가장 최적의 방식으로 해결하기 위함이며, 본인에게 가장 중요한 요소는 애플리케이션 속도와 개발 효율성임
  • React나 Next.js를 Laravel과 함께 사용하거나, Inertia.js를 Laravel과 함께 사용할 경우 프론트엔드와 백엔드 양쪽 스택을 모두 유지 관리해야 함
  • 솔로 개발자로서 두 개의 다른 위치에서 상태를 관리할 시간이 없었고, 모든 것을 함께 처리할 수 있는 견고한 모놀리식 솔루션이 필요했음

  • 대안 비교: Laravel Livewire, Rails Hotwire, Next.js

    • Laravel Livewire와 Rails Hotwire는 JavaScript에 크게 의존하지 않고 프론트엔드 작업을 단순화하는 훌륭한 도구
    • Next.js로 풀 JavaScript 스택을 고려했으나, 백엔드에서 JavaScript를 사용하는 것을 선호하지 않음
    • Rails Hotwire는 Rails로 MVP를 빠르게 구축할 수 있는 능력 때문에 특히 주목받았음
    • 그러나 백그라운드 작업, 실시간 업데이트, 양방향 통신이 필요했고, 이는 Rails와 Laravel에서도 가능하지만 설정에 더 많은 노력이 필요

  • Elixir, Phoenix, LiveView의 결정적 장점

    • Elixir와 Phoenix는 Ruby on Rails의 우아함을 유지하면서 훨씬 높은 성능을 제공함
    • Oban을 통한 내장 백그라운드 잡, 친숙하고 가독성 좋은 문법, 그리고 LiveView의 실시간 양방향 통신이 강점임
    • LiveView는 서버 렌더링 방식과 프론트엔드 무거운 프레임워크 사이에서 이상적 균형을 잡음
    • WebSocket을 통한 실시간 업데이트와 JavaScript 라이브러리(예: Alpine.js) 연동이 가능함
    • Phoenix는 Oban 내장으로 백그라운드 잡 선언과 자동 복구가 쉬움

  • Elixir/Erlang의 이점

    • Elixir는 Erlang 위에 구축된 컴파일 언어로, WhatsApp, Discord와 같은 대규모 동시성 시스템의 기반임
    • 고동시성, 결함 허용성, 장애에 대한 자동 복구를 제공함

최종 선택의 이유

  • 빠른 개발과 높은 동시성 지원
  • 단일 언어로 거의 모든 구현 가능
  • 가독성 좋은 코드 작성
  • 컴파일러가 프로덕션에 도달하기 전에 대부분의 버그를 포착해서 차
  • 장애 허용 구조로 앱이 거의 다운되지 않아 앱의 안정성 보장

결론 및 조언

  • Phoenix가 무조건 Rails, Laravel, Next.js보다 우월하지 않음
  • 모든 프레임워크는 훌륭하며, 각자 다양한 프로젝트에 사용 경험이 있음
  • 본인의 특정 상황과 프로젝트 (Hyperzoned.com)에 Phoenix가 가장 적합했음
  • 이미 알고 있는 것을 넘어 탐색을 시도하면 다음 문제를 해결하는 더 나은 효율적인 방법을 찾을 수 있음
  • 학습을 멈추지 말 것
▲
colus001 2일전  [-]

Livewire 가 재밌는 건 사실이지만 조금만 UI 가 복잡해지면 헬이 됩니다. 그 순간부터 Phoenix 는 장점을 확 잃어버리죠. 사이클이 길어질수록 힘들어지기 때문에 저는 별로 추천을 못하겠네요.

답변달기
▲
GN⁺ 2일전  [-]
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만 줄짜리 대형 프로젝트에서 다음과 같은 문제가 있었음:

    • 컴파일 시간: 코드 한 줄 바꿔도 개발 환경에서 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를 선택하지 않은 유일한 이유가 타입체커 부재였음. 혹시 변화가 생겼는지 궁금함

답변달기