왜 Elixir로 Rails를 교체했고 후회했는가?

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

웹 개발

대상자

Ruby on Rails 및 Elixir 기술 스택을 고려하는 백엔드 개발자, 기술 리더

핵심 요약

• Elixir의 기대 성능 vs 실제 결과: N+1 쿼리 문제, JSON 파싱 병목 현상으로 인해 CRUD 엔드포인트 속도 저하
• BEAM VM의 한계: 감독 트리가 비정상 코드를 수정하지 못해 결제 서비스 버그로 인한 트랜잭션 중 재시작
• 비용 효율성 저하: Phoenix의 연결 풀링 효율성 부족으로 PostgreSQL 비용 2배 증가
• Rails의 강점: ActiveAdmin, Migrations, Devise Gem 등 생태계 풍부성과 개발자 유치 어려움

섹션별 세부 요약

1. 기대 vs 현실: Elixir의 성능 문제

• N+1 쿼리 문제: Ecto가 ActiveRecord와 달리 자동 포함 기능 없음

```elixir

users = Repo.all(User)

Enum.map(users, fn user -> Repo.all(from p in Post, where: p.user_id == ^user.id) end)

```

• JSON 파싱 병목: Oj 라이브러리와 같은 고성능 파서가 없음
• 예상 10배 성능 향상: 실제 CRUD 엔드포인트 속도 저하

2. BEAM VM의 자동 복구 기능 한계

• 감독 트리가 코드 오류를 수정하지 못해 결제 서비스 버그로 인한 트랜잭션 중 중단
• 자체 복구 기능 부족: 시스템이 자동 복구를 보장하지 않음

3. 비용 증가 및 기술적 부채

• PostgreSQL 비용 2배 증가: Phoenix의 연결 풀링이 Puma보다 비효율적
• CPU 부하 증가: Rails의 JSON 렌더링 속도와 동일한 성능 달성 위해 추가 CPU 필요

4. Rails의 생태계 및 개발자 경험

• ActiveAdmin 대체: 관리자 패널을 수작업 구현 필요
• Ecto Migrations: change 명령어의 역행 가능성 부족
• Elixir 라이브러리: Devise와 같은 Ruby Gem 대비 성숙도 낮음
• 개발자 부족: Elixir 개발자 수가 Ruby 개발자 10분의 1 수준

5. Elixir의 강점

• 실시간 기능: Phoenix Channels가 ActionCable을 초월
• 백그라운드 작업: Oban이 Sidekiq보다 신뢰성 높음
• 고성능 API: JSON 파싱 최적화 후 고처리량 처리 가능

결론

• 하이브리드 접근: CRUD는 Rails, 실시간 기능은 Elixir로 혼합 아키텍처 도입
• 벤치마크 우선: Elixir의 ROI를 전체 마이그레이션 전에 증명
• 팀 교육 투자: 3개월 Elixir 멘토링 프로그램 실행
• 기존 팀 DNA 존중: Ruby 기반 개발 문화를 유지하며 기술 혁신 시도