3년치 회고록_1

회사가 가진 프론트엔드 프로덕트의 굵직한 마이그레이션이 끝나고 나서 내가 원하는 건 기존 Spring + JSP 스택의 레거시 프로덕트를 ‘RESTful API + 모던한 프론트엔드 프레임워크로 만드는 웹 클라이언트’ 조합으로 바꾸는 것이었다.

내가 이 조합을 제시했을 때 백엔드 팀에서 돌아온 답변은 ‘안 된다’였다. 왜 안 되느냐 물었을 때 돌아온 대답은 ‘레거시가 IDC에 있어서'였다.

그때는 뭘 모르기도 했고, 웹 서버나 인프라에 관해 지금보다 무지했기 때문에 안 된다고 하니 안 되는 것이라 생각했었다. 그렇게 해서 나온 대안은 뭣 모르는 나에게도 굉장히 기묘했다:

1. Spring 프로젝트 내부에 정적 파일 서빙 경로를 만든다
2. 이 경로가 IDC 서버의 특정 폴더(프론트엔드 빌드 결과물)를 바라보게 한다
3. 특정 URL로 접근하면 Spring이 SPA를 제공한다

나는 이런 방식으로 제공될 아이템 통합 검색 페이지를 Vue3 SPA로 만들었다.

시간이 흐르고 새롭게 입사한 백엔드 개발자 분께 같은 질문을 했다. 답변은 명쾌했다. Nginx 같은 리버스 프록시를 앞단에 두고, URL 패턴에 따라 트래픽을 라우팅하면 된다는 것이었다. 마이그레이션이 완료된 페이지는 새로운 프론트엔드 + API로, 아직 작업 중인 페이지는 기존 JSP로 보내면 된단다.

그도 그럴 것이 내가 그때 제시한 방법은 유튜브 같은 데서 실제 사례로 언급되고 있었다. 그래서 반대하는 개발자에게 영상을 공유하기도 했었는데, 그에겐 그게 '불가능’으로만 보였나보다.

결과적으로 우리가 선택한 방식은 오히려 더 복잡했다. Spring과 프론트엔드의 결합도가 높아졌고, 독립적인 배포가 어려워졌으며, 캐싱 전략도 복잡해졌다.

이 글을 쓰는 지금은, 결과가 이렇게 되버린 이유를 알 것도 같다. 그때 당시 나를 비롯한 이 회사의 개발팀은 프론트엔드 개발에 대한 이해도가 거의 바닥이었던 것이다. 프론트엔드 개발을 UI를 만드는, 단순한 HTML + CSS + Javascript 코드의 조합으로 이해한 조직이었기에 웹 클라이언트 코드가 완전히 분리된 아키텍쳐가 왜 필요한지도 몰랐던 것이다. 그래서 안 되는 이유는 모르기 때문에 그냥 ‘안 되기’ 때문이었고, 모르기 때문에 그냥 하자는 대로 개발을 한 거였다.

이제는 알겠다. 프론트엔드 개발은 더 이상 백엔드의 부속품이 아니다. 사용자가 직접 마주하는 모든 경험이 프론트엔드에서 결정되고, 그 복잡도는 백엔드 못지않게 높아졌다. 빌드 파이프라인, 상태 관리, 번들 최적화, 렌더링 전략—이 모든 것이 독립적인 전문 영역이 되었다. 그래서 프론트엔드는 독립적으로 배포되고, 독립적으로 확장되며, 독립적으로 발전할 수 있어야 한다. 이건 트렌드가 아니라 필연이다. 그리고 이 필연을 이해하지 못했던 그때의 나는 결국 더 어려운 길을 가는 데에 동의했던 것이다.