Rails는 Turbo 프레임워크의 성능 개선을 위한 광범위한 탐색 작업의 일환으로, 클라이언트 측 대신 서버 측에서 DOM 변경사항을 Diffing하는 아이디어를 실험했습니다. 이러한 아이디어는 Phoenix Live View의 렌더링 파이프라인에서 영감을 받았으나, Live View의 상태 저장(stateful) WebSocket 연결 방식은 Turbo의 핵심 철학인 점진적 개선(progressive enhancement)과는 부합하지 않았습니다. 클라이언트 측 모핑(morphing)의 성공적인 적용 가능성을 확인한 후, 본 프로젝트는 서버 측 Diffing의 실용성과 잠재적 문제점을 탐색하는 데 중점을 두었습니다.
이러한 배경에서, 서버 측 Diffing의 실현 가능성을 확인하기 위한 프로토타입이 개발되었습니다. 프로토타입은 text/vnd.turbo-diff.json이라는 특별한 MIME 타입을 수락하는 Rails 미들웨어로 구성되었습니다. 이 미들웨어는 요청을 가로채어, 주어진 세션에 대해 캐시된 페이지 내용과 현재 응답을 비교하여 Diff를 계산하고 이를 클라이언트에 전송하는 역할을 수행했습니다. 클라이언트 측에서는 Turbo의 표준 이벤트를 확장하여 새로운 MIME 타입을 인식하고 수신된 Diff 페이로드를 적용하도록 구현되었습니다. Diff 페이로드는 JSON 구조로, 루트로부터의 위치 목록(0/1과 같은 형식)을 사용하여 노드를 식별했습니다. 이 Diffing 알고리즘은 morphdom보다 유연하여 ID가 없는 노드도 조정할 수 있었고, nokolexbor와 같은 라이브러리도 성능 개선을 위해 실험되었습니다.
프로토타입 개발 전, 개발팀은 몇 가지 핵심적인 질문을 가졌습니다. 즉, 전송 페이로드의 크기 감소가 실제 사용 사례에서 충분한 가치가 있는지, solid_cache를 사용하여 세션별로 제공된 화면을 추적하여 Diff를 계산하고 제공하는 것이 실현 가능한지, 그리고 morphdom처럼 DOM ID에 과도하게 의존하지 않는 Diffing 접근 방식을 사용할 수 있는지에 대한 의문이 제기되었습니다.
광범위한 논의와 프로파일링 결과, 서버 측 Diffing은 최종적으로 채택되지 않고 클라이언트 측 모핑이 선택되었습니다. 이는 다음과 같은 중대한 우려 사항들 때문이었습니다:
- 성능상의 미미한 이점: 페이로드 크기 감소로 인한 성능 이득이 미미하여, 테스트된 시나리오에서 사용자에게 체감될 만한 차이를 제공하지 못했습니다.
- HTTP의 무상태성 원칙 위배: 서버에서 마지막으로 렌더링된 페이지 상태를 추적하는 것은 복잡하고 비용이 많이 들며, HTTP의 핵심 특성인 무상태성 원칙에 반합니다. 클라이언트는 이미 현재 페이지의 상태를 가지고 있으므로, 서버로부터의 변경사항을 조정하기에 가장 적합한 위치에 있습니다.
- Turbo의 백엔드 독립성 훼손: 서버에서 DOM 조정을 수행하려면 Ruby 기반의 HTML Diffing 구현이 필요하며, 이는 Turbo의 핵심 설계 강점인 백엔드 독립성을 제한합니다. Turbo는 어떠한 특정 서버 구현에도 묶이지 않아야 합니다.
- 점진적 개선 철학과의 불일치: Turbo는 서버가 HTTP 문서를 제공하고 클라이언트가 자체 능력에 따라 경험을 향상시키는 방식으로 작동합니다. 고충실도 페이지 업데이트를 위해 서버 측 협력과 분산 문서 저장소를 요구하는 것은 Turbo의 단순성과 점진적 개선 철학에 어긋납니다.
- HTML 문서의 본질 유지: HTML은 문서 형식이며, 클라이언트는 HTML을 기본적으로 렌더링할 수 있어 플랫폼에 관계없이 우아한 성능 저하를 제공합니다. 서버가 특정 클라이언트에 맞춰 응답을 조정할 필요가 없어야 시스템 전체가 더 단순해집니다.
비록 서버 측 Diffing 실험은 최종적으로 Turbo 8의 주요 기능으로 채택되지 않았지만, 이 탐색 과정은 프레임워크의 방향성을 설정하는 데 결정적인 역할을 했습니다. 본 문서는 'Turbo 8의 모핑'이라는 헤드라인보다는 '사랑하는 `redirect_to`가 이제 더 부드러워졌다'는 표현이 Turbo의 본질적인 개선을 더 잘 나타낸다고 강조합니다. 이 프로젝트는 코드를 작성하고 결국 폐기하는 과정이 아이디어를 테스트하고, 결함을 논의하며, 핵심 피드백을 얻고, 궁극적으로 무엇을 구축해야 할지 명확히 하는 데 얼마나 가치 있는지를 보여주었습니다. 저자는 결과물이 없더라도 이러한 탐색적 작업을 장려하는 조직 문화에 깊은 감사를 표하며, 이는 솔루션을 실제 요구사항에 자연스럽게 연결하는 데 기여한다고 언급하며 글을 마무리합니다.