재직중에 했던 프로젝트는 여러가지 있지만 가장 기억에 남는 것을 꼽으면
22년도 하반기에 진행했던 프론트엔드 개편 작업입니다.
당시에 회고 했어야 했는데 지금이라도 문서와 기억에 의존해 적어봅니다.
당시 상황
프로덕트 전면 리뉴얼에 따라 모던 JS 라이브러리를 사용해서 프론트엔드 영역을 개발해야 했습니다. 성능적인 부분에서도 필요했지만, 앞으로의 채용을 위해서도 당시 가장 점유율이 높았던 ReactJS 라이브러리를 사용하기로 했습니다.
Ruby on Rails 버전 5(이하 RoR) 프레임워크를 사용하고 있는 상황이었고, 프론트엔드 어플리케이션 분리 없이 진행해야 했습니다.
RoR은 MVC 패턴을 사용하는 프레임워크입니다.
[참고] https://guides.rubyonrails.org/getting_started.html#model-view-controller-basics
프론트엔드만 분리해낼 수 있으면 정말 좋았겠지만, 메인 계열과 2depth, 검색페이지 한정으로 주어진 시간 내에 반영해야했고,
유저 관련 영역을 rails devise에 의존하고 있는 부분도 있었기 때문에 현실적으로 어려웠습니다.
모던 JavaScipt 환경 세팅
Webpacker는 JS, CSS 및 Rails 애플리케이션의 Asset 을 패키징하는 webpack 기반 Rails wrapper 입니다.
RoR는 기본적으로 node를 필요로하지 않기 때문에, Webpacker를 설치해야 node 모듈을 사용할 수 있습니다.
# Gemfile 추가
gem 'webpacker', '~> 5.4'
# bundle 설치
bundle install
# webpacker 초기화
rails webpacker:install
├── app/
│ └── javascript/
│ └── packs/
│ └── application.js
├── babel.config.js
├── config/
│ ├── webpack/
│ │ ├── development.js
│ │ ├── environment.js
│ │ ├── production.js
│ │ └── test.js
│ └── webpacker.yml
├── package.json
├── yarn.lock
└── bin/
├── webpack
└── webpack-dev-serverWebpacker을 설치하니 JS 패키지 관리자인 yarn을 사용할 수 있게 됐습니다.
기존에 있던 RoR Asset pipeline 인 Sprocket 과 별개로 새로 구성하는 페이지의 JS 파일들, 특히 React 컴포넌트 등을 넣어 webpack 으로 번들링할 수 있게 됐습니다. 설치 이전에는 모듈 번들링을 하지 않아 JS 파일이 페이지 단위로 분산되고, 공통으로 사용되는 함수들은 전역에 배치되어 있었습니다.
React 라이브러리를 설치하고 webpack 설정 후 빌드 해보는 것도 처음이라 검색에 의존하며 많이 시도해봤던 것 같습니다. 꽤 길었지만 실서버에서 돌아갈 컴포넌트를 만들 준비를 마쳤습니다.
성과
이전 코드와 비교해서 사용하던 컨텐츠의 총량이 늘어났기 때문에, React 를 넣음으로서 각 페이지의 Load 시간이 개선되었는지는 측정할 수 없었습니다만,
비즈니스의 목표치였던 사용자의 절대적인 상품컨텐츠 View 가 증가했다는 사실만 알 수 있었습니다. 라이브러리를 도입해서 개선되었다는 수치를 확인할 수는 없었기 때문에 이 부분은 아쉽게 느껴집니다.
React 러닝커브가 없는 상태에서 런칭까지 해낸 것도 의미 있었지만, 당시 2년차 경력으로 5인 규모의 스케쥴 관리도 해볼 수 있어서 상당히 배운 점이 많은 시간이었습니다.
남은 문제들
배포는 마쳤으나 이후에 해야하는 숙제가 생겼습니다.
빌드 시간 증가
기존에 있는 Asset Pipeline 을 제거하지 못하고 Webpacker 를 설치했더니 빌드 시간이 2배이상 늘어나 버렸습니다.
그리고 webpack entry point에 파일을 여러 개 배치해서 컴파일 오버헤드가 증가했습니다.
application.erb 에 단일 entry point 파일인 packs/application.js 만 헬퍼를 사용해 포함 시켜야합니다.
<%= javascript_pack_tag "application" %>그러나 여전히 Rails 프로젝트인 환경에서 legacy view 영역에서는 webpacker 경로의 js 를 불러야하는 경우가 있어 문제가 되었습니다.
이 문제는 veiw 에 해당하는 컨트롤러와 메서드 값을 전역 상태로 받아 필요한 스크립트를 불러내는 형태로 변경해서 개선했습니다.
entry point 문제는 금방 해결할 수 있는 부분이었습니다.
그러나 Sprocket 에 남아있는 레거시를 정리하고, Webpacker로 옮기는 작업의 경우는 워낙 방대해서 부채로 남았습니다.
끝나지 않는 리팩터링
당시 팀 내 React에 대한 이해도가 저를 포함해서 전부 높은 수준이 아니었기 때문에, React에 익숙하지 않은 개발자들이 하는 실수, 대표적으로 hook 과 라이프사이클에 대한 이해 부족의 문제도 있었고, Context API만으로는 부족한 상태관리 라이브러리의 필요성으로 인한 추가 등 계속해서 유지보수 작업이 필요하게 되었습니다.
최근에도 기존에 사용하던 Context Provider를 들어내고 상태관리 라이브러리인 jotai를 새로 적용시키는 작업을 했습니다.
돌아보며
이 작업을 하고나서 동기부여가 많이 된 한 편, 계속되는 코드개선과 레거시의 컴포넌트 작업으로 인해 많이 지쳤던 것 같습니다.
React 같은 라이브러리를 새로 배우고 제품에 적용하는 과정이 소위 도파민 터지는 작업이었다면, 이후에 해결해야하는 과제들은 회사 입장에서 중요하지 않은 작업으로 여겨질까봐 회피하고 싶은 마음이 있었습니다.
그런데 서비스라는게 계속해서 제공되는 것이고 혼자만의 제품이 아니기 때문에 지속가능한 서비스를 위해서는 지속적인 개선이 무엇보다 중요한 일임을 잊지 말고 좋은 코드를 깎아 나가야 겠습니다.
개선 과정에서 했던 고민들도 조금씩 적어 보겠습니다.
