무거운 UI 프레임워크를 걷어내다 — 자체 경량 컴포넌트로 갈아탄 이유

지난 글에서 대규모 레거시 PMS를 한 번에 갈아엎지 않고 점진적으로 현대화한 전략을 소개했습니다. 이번에는 그 과정에서 가장 큰 부담이었던 상용 UI 프레임워크 의존성을 어떻게 걷어냈는지 이야기합니다.

오래된 UI 프레임워크가 남긴 부담

이 PMS는 수년 전 도입한 상용 UI 프레임워크 위에 만들어져 있었습니다. 툴바, 트리, 다이얼로그, 폼, 탭 같은 화면 요소를 이 프레임워크 하나가 모두 담당했죠. 처음에는 빠른 개발에 도움이 됐지만, 시간이 지나며 비용이 드러났습니다.

• 무거운 번들 — 실제로 쓰는 기능은 일부인데, 통째로 로드해야 했습니다.
• 버전 잠김 — 오래된 버전에 묶여 최신 브라우저·도구와 어울리지 않았습니다.
• 제어권 부족 — 동작을 조금 바꾸려 해도 프레임워크의 방식에 끼워 맞춰야 했습니다.

"전부 대체"가 아니라 "필요한 것만 다시"

해법은 프레임워크가 제공하던 기능을 똑같이 복제하는 것이 아니라, 우리 화면이 실제로 쓰는 기능만 가볍게 다시 구현하는 것이었습니다. 툴바·트리·다이얼로그·폼·탭을 각각 작은 자체 컴포넌트로 만들고, 표(그리드)는 검증된 오픈소스 그리드로, 레이아웃은 CSS Flexbox로 옮겼습니다.

핵심 원칙은 하나였습니다.

기존 호출 방식은 그대로 두고, 속만 바꾼다.

예를 들어 탭 컴포넌트는 기존 코드가 부르던 함수 이름과 사용법을 그대로 유지했습니다. 화면 수십 곳에서 부르고 있었기 때문에, 내부 구현만 가벼운 자체 코드로 교체하면 호출하는 쪽은 거의 손댈 필요가 없었습니다. 덕분에 한 화면씩 안전하게 옮길 수 있었습니다.

결과: 가벼워지고, 통제 가능해졌습니다

이 작업으로 통합 프레임워크 라이브러리를 완전히 제거했습니다. 수십 개의 화면이 무거운 의존성 없이 CSS Flexbox와 작은 자체 스크립트만으로 동작하게 됐고, 더 이상 쓰지 않는 라이브러리 디렉토리도 함께 정리됐습니다.

눈에 보이는 효과는 분명했습니다.

1. 로딩이 가벼워졌습니다. 쓰지 않는 기능을 더 이상 내려받지 않습니다.
2. 버전에서 자유로워졌습니다. 외부 프레임워크의 릴리스 주기에 끌려다니지 않습니다.
3. 고치기 쉬워졌습니다. 작고 명확한 코드는 동작을 바꾸기도, 디버깅하기도 쉽습니다.

자체 구현이 항상 정답은 아닙니다

물론 모든 것을 직접 만드는 것이 정답은 아닙니다. 표 컴포넌트처럼 복잡하고 검증이 중요한 부분은 성숙한 오픈소스를 그대로 활용했습니다. 직접 만들수록 좋은 것과, 잘 만들어진 것을 쓰는 게 나은 것을 구분하는 판단이 핵심입니다.

이번 사례의 교훈은 분명합니다. '전부 직접'도 '전부 의존'도 아닌, 우리 시스템에 꼭 맞는 만큼만 가볍게 갖추는 것 — 오래된 시스템에 다시 활력을 주는 가장 현실적인 길입니다.