레거시 천국
입사 후 마주한 프로젝트는 예상보다도 더 거대한 레거시의 집합체였다.
SSR(Server-Side Rendering) 방식인 JSP 기반의 구조는 현대적인 앱 UX를 구현하기에 적합하지 않은 언어였다.
모든 페이지 전환마다 서버로부터 전체 마크업을 다시 받아오는 구조 특성상 불필요한 데이터를 주고 받는 네트워크 오버헤드가 발생하여 앱의 전반적인 응답 속도가 저하되고 있었다.
이로 인해 앱 리뷰는 처참했지만.. 왜 이것이 관리가 되지 않고 있는지.. 의문이었다.
작은 기능 하나를 수정하려 해도 전체 영향도를 파악하기 위해 레거시 분석에만 수 시간을 쏟아야 하는 비효율의 연속이었다.
체계적인 관리없이 쌓여온 코드는 단순한 유지보수조차 힘들만큼 기술 부채가 심각했지만,
신사업에 집중된 회사의 리소스 탓에 기존 기존 서비스의 개선 의지가 없는 듯 보였다.
드디어 찾아온 리뉴얼의 기회
앱 서비스를 전반적으로 리뉴얼 한다는 소식이 들렸다.
개발자로써 매우 기쁜 소식이었으며, 이 기회에 리액트로 마이그레이션할 계획이었다.
이 기회가 아니면 구조 개선을 할 수 없다는 것을 알기에 더 의지가 강했다.
마이그레이션을 한다고 해서 당장 매출이 급격하게 오른다거나,
MAU(Monthly Active Users: 월간 활성 사용자)가 높아진다는 보장도 없었다.
그래서 경영진을 설득하는 것은 쉽지 않았지만,
개선 의지가 확고했던 실무진과 기획팀의 강력한 추진력 덕분에 진행하게 되었다.
특히 개발자로써 마이그레이션은 꼭 해내고 싶었다.
하지만 현실은 냉혹했다..
여러가지 이유로 일정이 지연되면서 리뉴얼 작업에 3개월이라는 기간밖에 얻어내지 못했다.
이번에야 말로 이 지독한 레거시에서 벗어날 수 있을 거란 기대감이 컸는데
너무 아쉬웠고 한편으론 원망스럽기도 했다.
그치만 어쩌겠나.. 주어진 환경에서만이라도 최선의 결과를 낼 수 밖에..
마이그레이션의 위기와 현실적 벽
주어진 시간은 단 3개월 뿐이고 그 기간안에 UI/UX 개선, 전면 회원제, 간편 로그인 등 해야할 것들이 많았다.
리액트로 마이그레이션을 하기 위해서는 서버의 지원이 많이 필요했다.
단순히 프레임워크를 바꾸는 작업이 아니었다.
서버가 화면을 직접 그려주던 방식에서 벗어나, 프론트엔드가 순수하게 데이터(JSON)만 주고받는 구조로 개선해야 했기 때문이다.
이를 위해서는 기존 JSP 내부에 복잡하게 얽혀 있던 비즈니스 로직들을 독립적인 API 형태로 추출하는 백엔드의 전폭적인 지원이 필요했다.
프론트엔드 서버 내 WAS에 정의되어있는 API들을 분리하여 백엔드에서 재정의하는 과정이 필요했고 이것이 수행되어야만 진정한 의미의 클라이언트-서버 분리 마이그레이션이 가능했다.
하지만 백엔드도 만만치 않은 기술 부채가 있었고 주어진 일정 내에 수행하기엔 불가능했다.
아키텍처 구조 개선: 미래를 위한 설계
마이그레이션은 잠시 뒤로 미루고.. 기존에 있던 구조 개선이 필요했다.
먼저 유지보수 효율을 떨어트리던 AOS/iOS 개별 폴더 구조를 통합하는 과정이 필요했고,
앱 개발자에게 AOS/IOS 브릿지명과 인터페이스 함수명을 통일해 달라고 요청했다.
특히 가장 중요하고 공을 들여야 되는 부분은 컴포넌트 중심의 아키텍처 도입이었다.
추후 리액트 마이그레이션 시 코드를 그대로 재사용할 수 있도록 기존의 거대한 CSS 파일을
기능별, 단위별로 쪼개어 독립적인 구조로 재배치가 필요했다.
- Base: reset, 공통 변수, layout
- Components: Button, Input, Checkbox, Modal 등 재사용이 가능한 UI
- Pages: Main, Member, Setting 등 특정 페이지 전용 레이아웃이러한 설계는 향후 리액트 전환 시 발생할 리소스를 획기적으로 줄여줄 핵심 전략이었다.
