API 기반 운영 데이터 전환

운영 과정에서 새로운 센터와 클라이언트를 백엔드에 추가해도 프론트엔드 운영 화면에는 자동으로 반영되지 않았습니다.

프론트엔드에서 센터 목록을 하드코딩된 enum으로 관리하고 있어 백엔드 데이터를 추가한 뒤 프론트엔드의 enum도 별도로 수정하고 다시 배포해야 했습니다. 한쪽의 수정이 누락되면 백엔드에는 존재하지만 운영 화면에서는 선택할 수 없는 센터가 생겼습니다.

센터 데이터의 관리 기준이 프론트엔드와 백엔드에 각각 존재하는 것이 원인이었습니다. 두 데이터는 같은 센터를 표현하지만 서로 동기화되는 구조가 아니었습니다.

센터를 추가할 때마다 담당자가 두 위치를 직접 수정해야 했고 프론트엔드의 변경과 배포 여부에 따라 화면에 표시되는 데이터가 달라졌습니다. 개별적인 수정 누락이 아니라 동일한 데이터를 두 곳에서 관리하도록 설계된 구조의 문제라고 판단했습니다.

프론트엔드에 하드코딩되어 있던 센터 enum을 제거하고 백엔드 API 응답을 센터 데이터의 단일 기준으로 사용하도록 변경했습니다.

운영 화면은 내부 상수 대신 로그인 이후 전달받은 API 데이터를 기준으로 선택지와 화면 데이터를 구성했습니다. 센터의 이름과 식별자처럼 화면에 필요한 정보도 API 응답에서 가져와 프론트엔드가 백엔드 데이터의 복사본을 별도로 유지하지 않도록 했습니다.

하드코딩된 센터 데이터를 API 응답으로 바꾸려면 센터 목록을 사용하는 여러 운영 화면을 함께 수정해야 했습니다.

기존 화면은 Recoil selector를 통해 센터별 데이터를 가공하고 있었습니다. API 전환과 동시에 상태 관리 구조까지 새로 설계하면 데이터 조회, 필터링, 선택 상태를 사용하는 화면 전반으로 변경 범위가 확산되고 회귀 여부를 확인할 범위도 함께 커질 수 있었습니다.

화면 컴포넌트가 하드코딩된 enum을 직접 사용하는 부분과 Recoil에서 파생 데이터를 사용하는 부분이 함께 존재했습니다. 데이터 원천과 화면 상태 관리의 책임을 구분하지 않고 전체 구조를 한 번에 변경하면 로그인 이후 데이터 유지, 센터 선택 상태, 화면별 데이터 가공과 기존 selector를 사용하는 화면이 모두 영향을 받을 수 있었습니다.

이번 작업의 목적은 상태 관리 기술을 교체하는 것이 아니라 센터 데이터의 원천을 백엔드 API로 통합하는 것이었습니다. 따라서 데이터 원천 변경과 화면 상태 구조 변경을 분리할 필요가 있다고 판단했습니다.

API에서 받아온 센터 목록을 로그인 시점에 LocalStorage에 저장하고 기존 화면은 저장된 데이터를 바탕으로 동작하도록 구성했습니다.

각 화면에서 API 응답을 직접 가공하지 않고 기존 Recoil selector가 LocalStorage의 센터 데이터로부터 필요한 형태를 파생하도록 변경했습니다. 데이터 원천은 API 응답으로 전환하면서도 화면 컴포넌트와 Recoil 기반 데이터 사용 방식은 최대한 유지해 변경 책임을 수집과 가공 계층으로 제한했습니다.