약 1년 전 Smol Talk 웹앱에 Phoenix LiveView를 도입하기로 한 비용 큰 기술적 결정을 내렸는데, 지금은 후회하고 있다. 왜 그런지 스스로에게 남기는 메모를 적어본다.

분명히 말하지만 이건 확실히 내 실력 문제이기도 하다. 하지만 (이미 JS/Python에 능숙한 사람에게는) 학습 곡선이 들인 노력에 전혀 값하지 않았다.

내가 한 일

우리는 커스터마이징 가능한 요약 파이프라인 플랫폼이 필요했다. 나는 예전부터 Elixir와 LiveView를 멀리서 동경해 왔고, 마침 만들어 줄 친구도 있었다. 그래서 하자고 했다.

Elixir/LiveView가 마음에 들었던 이유

• 단순한 모놀리식 서버 사이드 렌더링이라는 아이디어가 늘 마음에 들었다
• HTML diff 렌더링이 빠르고 쉬울 것 같았다 (마치 React Server Components처럼)
• 특히 ORM과의 매끄러운 연동 덕분에 필드의 CRUD 뷰를 자동으로 만들 수 있다는 점
• Elixir는 내결함성이 높고 빠르다고 들었다
• Oban은 잡 러너로서 평판이 좋았다

현실

불안정성/느린 속도

페이지 로딩이 끔찍하게 느렸다.

그리고 페이지 로드 중 약 20%? 30%?는 실패했다. DB 문제는 아닌 것 같다. 그냥 UI를 많이 렌더링하는 게 존나 느릴 뿐이다.

마치 전화 접속 인터넷을 쓰는 기분이었다.

생태계의 미성숙

우리 앱에는 나름 최신 기술들을 골라 썼다. 세어 보니 36개 의존성 중 20개(55%)가 0.x 버전이었다.

조건부 폼을 만들 수 없었다

이건 분명 우리가 고른 의존성 때문이기도 하겠지만, 다른 요소에 따라 특정 UI 요소가 나타나거나 추가될 수 있게 하고 싶었다. 코드 붙잡고 존나 삽질하며 일주일을 날린 끝에, ... 없이는 불가능하다는 결론을 내리고 포기했다.

JS 추가하기

클라이언트 측 인터랙션을 조금이라도 넣으려면 결국 JS가 필요하다. LiveView도 JS 컴포넌트에 데이터를 넘기는 괜찮은 방법을 제공하지만, 컴포넌트를 하나 쓰기 시작하면 점점 더 많이 쓰게 되고 결국 Phoenix를 API 백엔드로만 쓰게 된다. 그러느니 차라리 SPA로 만드는 게 낫다.

끔찍한 에러

에러를 보여주고 싶지만 지금 앱이 로드되지 않아서 보여줄 수가 없다

(추신: 이제 로딩되네... 그래, 이런 완전 쓰레기 같은 게 일상이다. 제정신인 시스템이라면 기대할 만한 타입 안전한 에러 핸들링 따위는 전혀 없다.)