알스솔루션
팜브릿지 서비스 재구축
약국 대상 약품 입고 관리 프로그램의 백엔드 JSP→Spring 전환에 맞춘 프론트엔드 전면 재구성. 전환 일정 내 안정화 제약을 최우선으로, SSR 제약·운영 인력 기술 폭을 함께 고려해 Vanilla JS 채택
주요 성과
- 약국 대상 약품 입고 관리 프로그램 ‘팜브릿지’의 백엔드 JSP→Spring 전환에 맞춰 프론트엔드 전면 재구성
- 의사결정: 백엔드 Spring 전환과 동기화된 일정 안에 안정화해야 하는 제약이 가장 컸고, 여기에 SSR 라우팅 제약·운영 인력의 장기 유지보수 가능 기술 폭을 함께 고려하여 Vanilla JS 선택 (React 도입 시 구조 설계·학습 비용으로 전환 일정 내 안정화가 어렵다고 판단)
- HTML/CSS/JavaScript만으로 라우팅 진입점, 상태 컨테이너, 이벤트 위임 처리 모듈을 자체 구현하여 프레임워크 의존도 없이 유지보수 가능한 구조 설계
- SSR 환경에 최적화된 자체 디자인 시스템을 별도 설계 — 사내 Monorepo·Antd 라인과 토큰·컴포넌트 모두 분리 운영
- 이후 2026.02-03에 React Island 패턴으로 부분 전환 (팜브릿지 서비스 리팩토링 참조)
기술 선택 자세히 보기
2025년에 Vanilla JS를 고른 이유 — 무엇을 1순위 제약으로 뒀고, 프레임워크 없이 유지보수 가능한 구조를 어떻게 세웠는지. 그리고 그 선택의 유효기간을 어떻게 봤는지.
1. 제약에 순위를 매긴다
제약이 여럿일 때는 전부 만족시키려 하기보다 무엇이 1순위인지 정하는 게 결정을 만든다. 여기서는 일정이 1순위였다.
전환 일정
백엔드 JSP→Spring 전환과 같은 일정 안에서 안정화해야 했다. 프론트가 늦으면 백엔드 전환 전체가 묶인다.
SSR 라우팅 제약
라우팅을 서버가 소유하는 구조라 클라이언트 라우터를 얹을 수 없었다. 이 구조 자체는 변경 대상이 아니었다.
운영 인력의 기술 폭
인수인계 후 장기 유지보수를 맡을 인력이 다룰 수 있는 범위여야 했다. 내가 떠난 뒤에도 고쳐져야 한다.
→ React를 얹으면 구조 설계와 팀 학습 비용이 전환 일정 안에 들어오지 않는다고 봤다. 기술의 우열이 아니라 이 일정 안에서의 선택이었다.
2. 프레임워크 없이도 구조는 있어야 한다
Vanilla JS를 고른다는 건 “구조 없이 쓴다”가 아니다. 프레임워크가 대신 해주던 일 중 이 서비스에 반드시 필요한 세 가지만 골라 직접 만들었다. 라이브러리를 만든 게 아니라 따라야 할 규칙을 만든 것에 가깝다 — 인수인계받을 사람이 읽어야 할 코드가 늘어나면 3순위 제약을 어기는 셈이라서다.
3. 이벤트를 어디서 받을 것인가
SSR 구조에서는 서버가 화면을 다시 그린다. 요소마다 리스너를 붙여두는 방식은 새로 그려진 DOM에서 조용히 죽는다 — 에러도 안 나고 그냥 클릭이 먹지 않는다. 그래서 이벤트를 컨테이너 한 곳에서 받도록 위임 구조를 기본으로 삼았다.
4. 이 선택의 유효기간
일정 제약이 사라지면 근거도 사라진다. 실제로 운영이 이어지면서 상태와 이벤트 결합으로 유지보수 비용이 쌓였고, 약 두 달 뒤 React Island 패턴으로 부분 전환했다. SSR 라우팅 제약(2순위)은 그대로 둔 채 동적 영역만 React가 맡는 구조다.
→ 되돌아보면 1순위 제약을 지킨 선택이었고, 동시에 오래 갈 선택은 아니었다. 두 판단이 모순은 아니라고 본다 — 다만 “언제 다시 볼지”를 처음부터 적어두는 편이 나았다.
5. 디자인 시스템을 따로 판 이유
사내에는 이미 범용 Monorepo 디자인 시스템이 있었지만 이 프로젝트에는 쓰지 않았다. 그쪽은 번들러와 컴포넌트 모델을 전제로 만들어졌고, 여기는 서버가 HTML을 그리는 환경이다. 억지로 맞추면 양쪽 다 제약을 지게 된다고 판단해 토큰·컴포넌트를 모두 분리해 운영했다.