리액트로 글로벌 서비스 리뉴얼한 경험 회고
와그트래블 서비스의 레거시는 php로 만들어진 모놀리식 구조였다. 백엔드와 프론트엔드가 하나의 프로젝트에 있어서 작은 프론트 변경 사항에도 서비스 전체를 배포할 수 밖에 없었다. 피씨웹과 모바일웹 코드가 완전히 분리되어 있었으며, 이렇다할 규약없이 작성된 레거시를 유지보수하는데 상당한 비용이 들어갔다. 이를 해소하기 위해 JAVA API 서버를 요청하고 React(Next.js)로 서비스 전환 작업을 진행했다.
결론만 톺아보면..
- 전체 서비스를 완전히 리액트로 리뉴얼하지는 못했음(내부 사정상 순차적 적용 중..)
- php와 react가 각각의 서비스로 존재하고 있음(AWS ELB 활용)
- 트래픽과 사용자 인터렉션이 집중되는 페이지 순으로 리뉴얼했음(기존 기능들을 유지/업그레이드 시키면서 엉키고 설켜있던 로직들을 정돈함)
- 가장 많은 트래픽이 발생하는 상품페이지 안정적으로 배포, 운영되고 있음
- 리뉴얼 후 배포까지는 혼자했지만, 이제는 동료가 생김(>_<b)
- 코드 리뷰를 통해서 계속 리팩 및 새로운 페이지 작업이 병행되고 있음
신규 서비스를 오픈하는 것 vs 라이브 중인 서비스를 대체하는 것의 차이
하이브리드앱 기반의 신규 서비스를 Vue로 구현했던 경험에 비춰 비교하자면…
신규 서비스는 명확한 기획에 근거해서 출발할 수 있고 상대적으로 긴 호흡을 가지고 서비스를 완성해 갈 수 있다.(물론 애자일하게 MVP를 뽑아내는 과정도 결국엔 긴호흡으로 MVP를 완성해 갈것이기에..)
라이브 중인 서비스를 대체하는 것은 훨씬 고려해야하는 부분이 많다…
서비스의 운영 기간동안 계속 추가되고 수정된 기능들을 유지/업그레이드 해야하기 때문에… 또한 이미 트래픽이 상당히 발생하고 있는 서비스이기에 리뉴얼된 코드가 배포된 이후의 파급력도 어마어마하기에 전사적인 QA과정이 필요했다.
또한, 이미 있는 기능을 리뉴얼하는데 긴 호흡을 가져가긴 쉽지 않는듯(빨리 새로운 코드가 적용되길 기다리는 구성원들의 독촉.. 격려 등..)
라이브 중인 서비스의 모든 기능을 알고 있는 사람이 작업을 한다해도 기능 누락이 발생하기 마련인데… 서비스가 가져가야하는 모든 기능을 정의해둔 문서는 존재하지 않았다. 내게 주어진 것은 php 코드 그리고 2개월이라는 시간…
코드라도 있으니 다행.. 기존 레거시를 풀스캔하면서 가져가야할 기능과 걷어내야할 기능을 정리했고, 이를 가지고 PM(Product Manager), 이사진과 의견을 정리하는 시간을 가졌다. 사실상 프로젝트의 오너가 나였기에… 꽤나 신경이 많이 쓰이는 작업이었다.
기존 서비스의 기능은 유지하면서 단점을 보완하는 방향
레거시의 구조적 한계로 구현되지 못했던 Backlog들과 반응형이라는 지향점을 가지고 출발
- SEO를 위해 SSR 적용(직접 구현보단 어느정도 보증된 Next.js 활용)
- 글로벌 서비스를 위해 php에서 쓰던 번역 시스템을 (po, mo 파일의 관리 지옥에서 도망치기위해) i18n 적용
- 프론트엔드 코드규약을 위해 Typescript와 tslint(airbnb) 적용
- 클라이언트단 버그 트래킹을 위해 Sentry.io 적용
- Hooks 적극 활용
- Redux, saga로 깔끔한 Props, State 관리 및 통신 일원화
- 기타 마케팅팀에서 사용중인 Tracking tool 적용 + criteo 추가
- 웹최적화(무거운 module은 최대한 지양, 외국의 3g이하 환경에서의 사용성 고려)
- 반응형 스타일링을 개발자 friendly하게 구성하기 위해 scss 적용
- 테스트 환경 구성 Componet 단위 테스트에 대한 대답은 아직 못정했지만 Redux 등 로직과 관련된 코드는 jest로 test코드 적용
결론
앞으로 3년은 충분히 경쟁력 있을 코드 작성
프로젝트를 시작할때, 핫한데 안써본 기술들을 적용해보자는 생각으로 기본 골조를 구성하기로 결정하고 끝까지 지켜냈다는 것에서 높은 점수를 주고 싶다.
리뉴얼을 시작할때 즈음 프론트엔드 커뮤니티에서 논의되고 있던 거의 모든 트랜드를 고려하고 적용하려 했다.(GraphQL 녹여내지 못한게 조금 아쉽…)
백엔드 개발자와 좀 더 나은 RESTful한 API에 대한 고민
프론트엔드 뿐 아니라 우리 서비스를 사용하는 third party 회사들에게 제공될 API를 만든다는 생각으로 진행된 작업이라,
사내 API를 가지고 작업을 하는 느낌이 아니라 타사의 API의 베타 테스터로서 작업을 하는 느낌을 받았다. (ex. 연관 상품 조회시, 상품 정보 api와 별개로 연관상품 조회 api를 호출하고, 특정 갯수 미만일 경우, 인기상품 조회 api를 호출하고, 그래도 없으면, 주변상품 조회 api를 호출해야하는 괴상한…)
하지만 보다 직관적이고 범용적으로 사용할 수 있는 API 구성에 대해 고민해볼 수 있었다.
프론트엔드 배포 환경을 위한 인프라 구축 작업
SSR을 위해서는 서버단에서 node를 실행할 수 있는 환경이 필요했고, 이를 위해 기존의 php 프로젝트가 도는 apache 서버용 인스턴스와 별개로 node 인스턴스를 만들고, 이를 타겟 그룹으로 묶어 AWS ELB에 리다이렉션 설정을 해주었다.
CI, CD까지 어느정도 마무리해놓으니 나름 쓸만해보인다. 추후 트래픽에 따른 auto scaling같은 기능을 구현하기 위한 고민들이 더 필요해보인다. Docker swarm만으로 인스턴스 오케스트레이션을 해본 경험밖에 없기에 쿠버네티스를 적용하고 싶었으나, 아직 백엔드도 그렇게 안하고 있는 판국에 더 판을 키우기는 조심스러웠다.
(쿠버네티스는 사이드 프로젝트로는 그 효용을 충분히 느낄 수 없을것 같아.. 회사에서 해보는게좋을텐데..)
사내 배포와 끊임없는 버그리포트
사내 배포후 꽤 다양한 방식으로 빈틈없는 QA를 진행했으나, 역시나 버그는 있었고, 클라이언트 사이드에서 발생하는 버그를 리포트 받기 위해 Sentry.io를 달아둔 것은 아주 좋은 선택이었다.
클라이언트 사이드에서 발생하는 unhandledException이나 기타 error들을 모아 dash board에서 확인할 수 있도록 해주며, 해당 에러가 발생한 기기, 브라우저 등의 환경들에 대한 리포트도 함께 되기때문에 크로스브라우징의 미비한 부분을 잘 보충해준다.
(slack 알람을 비활성화 할 수 있는 수준까지 끌어올리면 편하긴 한데, 배포하고 한동안은 슬랙 알람에 노이로제가 걸릴지경이었…)
개운한데, 무료한?
프로젝트의 시작부터 기획, 개발, 배포, QA 전과정을 거의 혼자 진행했기에 어느정도 안정화가 된 이후에는 보람과 개운한 기분이 들었는데… 큰 프로젝트를 하나 끝내고 나니 무료함이 덥쳐왔다..
(무료함의 정체는 비단 프로젝트의 마무리에서만 오는 건 아니지만.. 쉿)
집중하는 동안은 블로깅을 못했다. 분기 회고를 했어야하는데… 이제사 뭐라도 남길 수 있어서 다행이다.