소규모 Rails 애플리케이션 개발 중, 부분적으로 도입된 React가 백엔드 엔지니어들에게 기술 부채로 작용하는 문제에 직면했습니다. 팀 내에서 서비스 규모에 비해 React가 과도한지에 대한 논의가 지속되었고, 대안으로 Hotwire의 가능성이 제기되었습니다. 하지만 React의 풍부한 생태계와 유연성에 대한 익숙함 때문에 Hotwire로의 전면 전환에 대한 막연한 두려움이 존재했습니다. 특히 Turbo는 CRUD에 적합하지만, Stimulus만으로는 React처럼 유연한 UI 구현이 어려울 것이라는 인식이 있었습니다. 이러한 배경 하에, Hotwire의 실질적인 적용 가능성을 검증하고 팀의 기술 선택 기준을 명확히 하기 위해 실제 기능(피드백 영상 녹화)을 React에서 Hotwire로 교체하는 실험을 진행하게 되었습니다. 이 기능은 PC 카메라 및 마이크 접근이 필요하여 Stimulus 활용이 필수적이며, 기능 개선이 빈번하지 않아 실험 대상으로 적합했습니다. 기존 UI/UX를 유지하며 교체를 진행하는 것을 조건으로 삼았습니다.
초기 Hotwire(Stimulus 중심)로 녹화 기능을 구현하면서 예상보다 많은 JavaScript 코드를 작성하게 되는 문제에 직면했습니다. 이는 React의 Hooks 등이 자동으로 처리해주던 상태 관리를 직접 구현해야 했기 때문입니다. 이 시점에서 Hotwire 전환에 대한 회의감이 들었으나, Hotwire의 진정한 강점이 Turbo에 있으며, “종이 연극(紙芝居)” 개념을 활용한 설계 사고방식이 중요하다는 깨달음을 얻었습니다. 즉, UI 상태 변화를 버튼 클릭과 같은 이벤트 중심이 아닌, 데이터베이스의 상태 변화(영상 데이터 존재 유무)를 중심으로 바라보고, 이 상태 변화에 따라 화면 전체가 아닌 일부를 Turbo Streams로 교체하는 방식이 Hotwire의 핵심임을 인지했습니다. 영상 녹화 기능의 경우, 영상 데이터가 없는 상태와 있는 상태의 두 가지 “종이 연극”으로 구분하고, 영상 생성(POST) 및 삭제(DELETE)와 같은 CRUD 작업이 이 “종이 연극” 간의 전환을 담당하게 했습니다. 녹화 시작/종료 버튼 변경이나 시간 표시와 같이 화면 내의 세부적인 UI 조작은 “종이 연극의 장치”로 간주하여 Stimulus로 구현했습니다. 이 과정에서 Stimulus 컨트롤러에 모든 로직을 집중시키는 대신, 재사용 가능한 함수들을 별도 파일로 분리하여 코드 가독성을 높였습니다. 이러한 설계를 통해 Turbo와 Stimulus의 역할을 명확히 분담하여 구현을 완료하였고, 팀 내 논의를 거쳐 성공적으로 코드를 머지할 수 있었습니다.
이번 React에서 Hotwire로의 기능 교체 경험을 통해 팀의 기술 선택 기준을 구체화할 수 있었습니다. 첫째, 이번 실험 대상과 같이 CRUD 작업이 주를 이루고 약간의 JavaScript 조작("종이 연극"에 "장치"를 추가하는 형태)이 필요한 기능에는 Hotwire(Turbo + Stimulus)가 매우 효과적이며 적극적으로 활용하기로 합의했습니다. 둘째, CRUD와 무관하게 매우 풍부하고 복잡한 사용자 인터랙션이 필요한 기능(예: 고도의 WYSIWYG 에디터)은 React의 강점 영역임을 재확인했습니다. 셋째, 사용자 체류 시간이 길고 CRUD 작업 없이 복잡한 UI 조작이 필요한 중간 영역의 기능(예: 텍스트 에디터)에 대해서는 여전히 고민이 필요하다는 결론에 도달했습니다. 이 영역은 React의 상태 관리 이점이 있지만 깊은 이해가 필요하고, Hotwire로 구현하려면 CRUD 중심으로 설계를 비틀어야 하는 어려움이 있습니다. 결과적으로, "Hotwire 방식" 즉, 기능을 "종이 연극"처럼 CRUD 중심으로 설계할 수 있다면 Hotwire의 적용 범위는 예상보다 훨씬 넓다는 것을 실감할 수 있었습니다. 이번 경험이 다른 개발자들에게도 Hotwire를 시도해볼 동기를 부여하기를 바랍니다.