JSP 기반 업무를 React 화면으로 바꾸는 프로젝트를 준비하면서 처음에는 화면 전환이 가장 큰 일이라고 생각했습니다.

기존 JSP에서 HTML과 스크립트를 분리하고, React로 화면을 다시 만들고, Spring Boot API를 연결하면 새로운 구조로 옮길 수 있을 것처럼 보였습니다.

하지만 기존 업무를 하나씩 살펴보니 화면 뒤에 더 많은 것이 묶여 있었습니다.

JSP 안에는 화면보다 많은 역할이 있었습니다

기존 JSP는 화면만 렌더링하는 파일이 아니었습니다.

세션에서 사용자와 계좌 정보를 읽고, 공통 모듈을 호출하고, 원장 응답을 화면 형식으로 바꾸고, 조건에 따라 다음 화면으로 이동시키는 역할이 함께 들어 있었습니다.

화면을 React로 바꾸더라도 이 책임들이 사라지는 것은 아니었습니다. 오히려 기존에는 한곳에 숨어 있던 책임을 어디로 옮길지 명확하게 정해야 했습니다.

어떤 판단은 프론트엔드가 담당하고, 어떤 검증은 API가 책임질지 살펴봤습니다. 앱의 로그인 상태와 WebView 진입 흐름도 함께 봐야 했습니다.

화면이 아니라 업무 흐름을 기준으로 봤습니다

전환 대상을 화면 목록으로만 정리하면 비슷해 보이는 화면을 같은 방식으로 옮기기 쉽습니다.

하지만 조회 업무와 신청·처리 업무는 필요한 기준이 달랐습니다. 조회 화면은 데이터를 안정적으로 제공하고 상태를 표현하는 일이 중심이지만, 처리 업무에는 계좌 상태와 거래 가능 여부, 인증과 전자서명, 중복 요청 방지 같은 검증이 추가됩니다.

그래서 이번 프로젝트에서는 화면 수보다 업무 흐름을 먼저 정리했습니다.

  • 진입 전에 필요한 인증 정보는 무엇인지
  • 화면에서 조회하는 데이터와 처리에 사용하는 데이터가 같은지
  • 서버가 다시 검증해야 하는 조건은 무엇인지
  • 처리 후 앱과 웹이 어디로 이동해야 하는지
  • 기존 공통 모듈 중 유지하거나 새로 분리할 것은 무엇인지

이 기준을 확인한 뒤에야 화면과 API의 경계를 나눌 수 있었습니다.

모든 것을 한 번에 바꾸지 않기로 했습니다

기존 구조를 분석하다 보면 공통 기능을 모두 새로 만들고 싶어집니다. 인증, 응답, 예외, 메시지, 원장 연동을 이상적인 모습으로 한 번에 정리하고 싶은 마음도 생깁니다.

하지만 실제 프로젝트에서는 기존 서비스가 계속 운영되고 있고 일정도 정해져 있습니다. 한 번에 너무 많은 책임을 바꾸면 전환 범위뿐 아니라 검증해야 할 범위도 함께 커집니다.

이번에는 업무 단위로 전환하되 공통 응답, 인증 컨텍스트, 예외 처리처럼 앞으로 반복해서 사용할 기준부터 만들기로 했습니다. 도메인별 기능은 분리하되 초기 배포 구조는 지나치게 복잡하게 만들지 않는 방향을 선택했습니다.

전환의 기준이 달라졌습니다

JSP 레거시 전환은 오래된 화면을 새로운 프레임워크로 다시 만드는 일이 아니었습니다.

기존 화면 안에 섞여 있던 책임을 드러내고, 앱과 웹과 서버가 각자 무엇을 맡을지 다시 정하는 일이었습니다. 기술을 바꾸는 것보다 업무 흐름을 잃지 않으면서 다음 업무도 같은 기준으로 만들 수 있게 하는 것이 더 중요했습니다.

화면은 전환의 결과로 바뀝니다. 하지만 전환을 가능하게 만드는 것은 화면 뒤의 책임을 다시 바라보는 일이라고 생각합니다.