Rails 7은 프론트엔드 개발 경험 향상을 위해 새로운 자산 파이프라인을 도입했습니다. 이는 기존 Sprockets의 복잡성을 해소하고 Node.js 생태계와의 통합을 강화하기 위한 변화입니다. 본 발표는 개발자들이 올바른 자산 관리 도구를 선택할 수 있도록, 과거 자산 파이프라인이 해결하고자 했던 문제점과 현대 웹 기술의 발전이 가져온 변화, 그리고 새로운 핵심 도구인 Propshaft의 작동 원리를 심층적으로 다룹니다. 궁극적으로 자산 파이프라인의 목표는 페이지 로드 속도 향상과 코드의 유지보수성 증대입니다.
과거 Rails의 자산 파이프라인인 Sprockets는 웹 페이지 로딩 속도와 코드 유지보수성을 위해 트랜스파일링, 번들링, 지문 인식, 압축 기능을 제공했습니다. 이는 당시 CSS 2.1, ES5, HTTP/1과 같은 구형 웹 기술의 한계를 보완하기 위함이었습니다.
그러나 지난 10년간 웹 기술은 크게 발전했습니다. ES6의 광범위한 지원과 CSS의 중첩 기능 도입으로 트랜스파일링의 필요성이 줄었고, HTTP/2의 등장으로 번들링은 더 이상 성능상 이점이 없으며 오히려 안티패턴이 될 수 있습니다. CDN의 자동 압축 기능 또한 서버 측 압축의 필요성을 없앝습니다. 반면, SPA의 확산으로 JavaScript 내 자산 참조 방식이 복잡해지면서 지문 인식은 여전히 중요하지만, 그 구현 방식은 변화가 필요했습니다.
이러한 변화에 발맞춰 Rails는 Sprockets의 복잡성을 단순화하고 핵심 기능만을 남겨 Propshaft를 개발했습니다. Propshaft는 트랜스파일링과 번들링을 제거하고, 향상된 지문 인식 기능만을 유지하며, Node.js 기반 번들러(ESBuild, Rollup 등)와의 통합을 강화합니다. Propshaft의 핵심은 Assembly 클래스로, 애플리케이션 부팅 시 모든 자산 경로를 자동으로 탐색하여 관리합니다. 개발 환경에서는 동적 리졸버와 파일 변경 감지를 통해 실시간 반영을 지원하고, 프로덕션에서는 정적 리졸버와 매니페스트 파일을 사용합니다. 또한, Propshaft는 CSS 파일 내 자산 참조를 자동으로 처리하여 asset_helper를 없앝고, bin/dev 명령을 통해 번들러가 빌드한 결과물을 자동으로 통합합니다. JavaScript 지문 인식은 Import Maps 또는 번들러 자체 기능으로 처리됩니다.
궁극적으로 Rails 7의 자산 파이프라인 전략은 개발자에게 'Node.js를 사용할 것인가?'라는 명확한 질문을 던집니다. 만약 Node.js를 사용하지 않는다면, Import Maps와 함께 Sprockets(향후 Propshaft)를 활용하여 순수 Ruby 기반의 프론트엔드 개발을 지향할 수 있습니다. 반대로 Node.js를 사용하고자 한다면, `jsbundling-rails` 및 `cssbundling-rails` 젬을 통해 ESBuild, Rollup 등 다양한 Node.js 번들러와 Rails를 긴밀하게 통합하여 강력한 프론트엔드 워크플로우를 구축할 수 있습니다. 이러한 유연성은 Rails가 현대 웹 개발의 다양한 요구사항을 충족시키면서도, '노 빌드 프론트엔드'라는 본연의 철학을 유지하려는 노력을 잘 보여줍니다. Propshaft는 Rails 개발자들이 더 효율적이고 간결한 방식으로 프론트엔드 자산을 관리할 수 있도록 지원하는 핵심적인 발전입니다.