입사 후 마주한 프로젝트는 예상보다도 더 거대한 레거시의 집합체였다. 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 등 특정 페이지 전용 레이아웃

이러한 설계는 향후 리액트 전환 시 발생할 리소스를 획기적으로 줄여줄 핵심 전략이었다.

원래 있어야 할 위치에서 벗어나 요소를 자유롭게 배치할때 쓰는 속성이다. position에 따라서 위치를 정하는 기준이 달라진다. position의 속성 종류에는 static, relative, absolute, fixed, sticky 가 있다.

position의 속성 특징

1. static

position 속성의 기본값으로 원래 있어야 할 위치에 그대로 있다.

2. relative

원래 있어야할 위치를 기준으로 배치하는 것이고 이때 요소의 자리는 그대로 차지한다.

3. absolute

가장 가까운 포지셔닝이 된 조상 요소를 기준으로 배치하는 것이고 이때 요소의 자리는 차지하지 않는다.

4. fixed

브라우저 화면을 기준으로 고정된 배치이다. 요소의 원래 자리는 차지하지 않으며 스크롤 시에도 고정되어 배치된 상태 그대로를 유지한다.

5.sticky

static처럼 원래 위치에 배치되어 있다가 정해진 위치에 스크롤되면 그때부터 fixed처럼 고정되어 배치된다. 기본적으로는 static 처럼 배치되어 있기 때문에 요소의 원래 자리는 유지한다.

시맨틱 태그란 의미를 가진 태그이며 의미를 나누고 싶을때 사용하는 태그이다. 태그의 이름과 의미만 다를 뿐 div 태그랑 기능은 같다.

시맨틱 태그의 장점

1. 검색 엔진 최적화(SEO)

SEO는 Search Engine Optimization의 약자로 인터넷에서 검색했을 때 원하는 사람들에게 알맞게 보여줄 수 있도록 사이트를 최적화하는 것이다. 시맨틱 태그를 잘 사용하면 검색 엔진이 사이트를 더 정확하게 파악하여 상단에 노출될 확율이 높아진다.

2. 웹 접근성(Web Accessibility)

시각장애가 있는 사용자가 스크린 리더라는 프로그램을 사용했을 경우 메뉴, 본문 등을 정확하게 구분할 수 있다. 시맨틱 태그는 이러한 장벽없는 인터넷을 만드는데 중요한 역할을 한다.

3. 개발자 관점

시맨틱 태그를 사용하면 개발자가 코드를 읽고 이해하기 쉬워지며 개발자의 생산성을 높이는 데도 많은 도움이 된다.

시맨틱 태그의 종류

주로 사용하는 시맨틱 태그는 아래와 같다.