본 발표는 Ruby on Rails 환경에서 Hotwire와 Stimulus를 활용하여 효율적이고 유지보수 가능한 웹 애플리케이션을 개발하기 위한 설계 철학, 즉 'Hotwire 광명의 길'에 대해 논합니다. 개발 과정에서 자연스럽게 복잡한 JavaScript 코드가 증가하는 경향을 경계하며, 서버 사이드 제어의 중요성을 강조합니다. Stimulus의 올바른 활용 방안과 전체 아키텍처 설계가 코드의 복잡성을 줄이는 데 핵심적인 역할을 함을 역설합니다.
Hotwire 개발의 핵심 원칙은 제어를 서버에 집중시키는 것입니다. SPA(Single Page Application)와 달리, Hotwire는 Rails와 함께 화면 변경을 주로 서버에서 처리합니다. Stimulus는 이 과정에서 보조적인 역할만을 수행해야 합니다. Stimulus가 담당해야 할 영역은 HTML 및 브라우저 기능의 확장, 서버 처리 대기를 위한 임시 UI 변경, 서버 상태와 무관한 경미한 화면 요소의 표시/숨김 전환 (단, 신중해야 함), 그리고 서버로부터 받은 화면을 최종적으로 가공하는 렌더링 확장 등입니다. 반면, 주요 화면 변경이나 서버 상태에 의존하는 복잡한 로직은 Rails와 Turbo에게 맡겨야 합니다. 많은 개발자가 화면 단위로 Stimulus 컨트롤러를 작성하는 경향이 있으나, 이는 코드 중복과 유지보수성 저하를 야기합니다. 대신, 체크박스 클릭 시 폼 자동 제출(direct_submit), 셀렉트 박스 선택 시 특정 URL로 이동(selectable_link), 페이지 로드 시 특정 요소에 포커스 설정(initial_focus)과 같이 특정 ‘목적’이나 ‘기능’ 단위로 범용적인 Stimulus 컨트롤러를 설계해야 합니다. 이를 통해 다양한 화면에서 재사용성을 높이고, 개별 화면 요소의 ID나 특정 URL과 같은 정보를 JavaScript 코드 내부에 하드코딩하는 것을 방지할 수 있습니다. targets, events, data attributes와 같은 Stimulus의 기능을 활용하여 요소 간의 결합도를 낮추는 것이 중요합니다. 더 나아가, Stimulus 코드의 복잡성은 전체 아키텍처 설계에 크게 좌우됩니다. ‘웹 종이 연극(Web Kamishibai)’과 같이, 화면 전환을 서버 사이드 라우팅과 렌더링을 통해 단순하게 처리하는 구조를 지향해야 합니다. 예를 들어, 탭 전환 기능을 구현할 때 클라이언트 사이드 JavaScript로 두 개의 탭 내용을 모두 출력하고 숨김/표시를 전환하는 방식(이는 불필요한 DOM 생성 및 복잡성 증가 야기)보다는, 각 탭을 별도의 화면으로 간주하고 탭 클릭 시 해당 화면으로 서버 라우팅을 통해 이동하는 방식이 ‘광명의 길’에 해당합니다. 이러한 설계는 Stimulus 코드의 필요성을 최소화하고, 로직 대부분을 강력한 Ruby 언어로 처리할 수 있게 하여 개발 및 유지보수 효율성을 극대화합니다.
결론적으로, Hotwire 환경에서 Stimulus를 효과적으로 사용하고 '광명의 길'을 걷기 위해서는 서버에 제어를 집중하고 화면 변경의 주체를 Rails와 Turbo로 명확히 해야 합니다. Stimulus는 제한된 목적 하에 범용적으로 재사용 가능한 형태로 작성되어야 하며, 특정 화면에 종속적인 코드를 지양해야 합니다. 또한, '웹 종이 연극'과 같은 단순하고 명확한 전체 아키텍처 설계가 불필요한 JavaScript 코드를 줄이고 Rails의 강점을 최대한 활용하는 기반이 됩니다. 이러한 원칙을 준수함으로써 보다 간결하고 유지보수하기 쉬운 애플리케이션을 구축할 수 있습니다.