Elixir/Phoenix 학습 및 개발 과정저자는 Elixir/Phoenix 학습 초기 보일러플레이트를 사용했으나, 요구사항에 맞지 않아 코드의 70%를 재작성해야 했습니다. 이는 확장성과 재사용성이 부족했기 때문이며, 다음 프로젝트에서는 빈 Phoenix 앱으로 시작할 계획입니다. Elixir의 함수형 접근 방식에 익숙해지는 데 시간이 걸렸고, 특히 Quote/Unquote 개념은 최근에야 이해했지만, 대부분의 앱 구현에는 큰 지장이 없었습니다. Ecto는 함수명과 인수를 암기하기 어려워 항상 치트시트를 사용해야 할 만큼 복잡하게 느껴졌습니다.
Elixir/Phoenix의 주요 장점
- LiveView: Rails의 Turbo보다 훨씬 뛰어나다고 평가하며, 초기에는 UI 상호작용에 과도하게 사용했으나, 이후 Alpine.js와 조합하여 효율성을 높였습니다. 유럽에서 뉴욕 서버를 사용함에도 지연 시간 문제가 없었고, 대부분의 React 기반 앱보다 성능이 좋았습니다.
- ObanJob: Sidekiq와 달리 백그라운드 작업을 위해 별도의 앱 인스턴스나 추가 인프라, 유지보수가 필요 없어 매우 긍정적인 경험을 제공했습니다.
- 패턴 매칭: Elixir의
case문과 패턴 매칭 기능은{:ok, result}또는{:error, message}와 같은 결과 처리를 매우 용이하게 하여 Ruby보다 훨씬 깔끔하고 좋은 코드를 작성하는 데 기여했습니다. - 인증: Phoenix가 제공하는 인증 코드는 Devise보다 최소한의 구현으로 시작하지만, Google/GitHub 인증과 같은 기능을 몇 시간 만에 추가할 수 있을 정도로 확장성이 뛰어났습니다.
직면했던 도전 과제
- 배포: Docker를 사용한 멀티스테이지 빌드 배포 중 4GB 인스턴스에서 OOM(Out Of Memory) 오류가 발생했습니다. 수많은 디버깅 끝에 Elixir 포럼의 짧은 메시지에서 찾은
ERL_MAX_PORTS=1024환경 변수 설정을 통해 메모리 문제를 해결했습니다. - 테스트 도구: Rails의 Factory Bot과 같은 유용한 Gem에 비해 Elixir/Phoenix의 테스트 도구 생태계는 아직 부족하다고 느꼈습니다.
- 레이아웃 및 프로젝트 구조:
root,live,app레이아웃의 복잡성과 최근 업데이트로 템플릿, 뷰, 컨트롤러가 동일한 컨트롤러 폴더 아래에 통합되어 관리하기 어렵다고 지적했습니다. - 서드파티 통합: 일부 서드파티 서비스에 대한 패키지가 없어 직접 구현해야 했지만, 대부분 한 시간 내에 처리할 수 있을 만큼 어렵지 않았습니다.
- 이미지 업로드: 초기에는 앱 내부에 저장했으나, 비용 절감을 위해 DO Spaces CDN으로 전환했습니다.
presign_함수의 작동 방식과 훅 사용에 대한 이해가 필요했으며, 구현 방식에 대한 아쉬움을 표했습니다.