SWAP Admin V1·V2 전환
기존 작업 데이터가 남아 있는 환경에서 V2 화면·API 전환에 참여했어요.
업무 맥락
SWAP 운영 Admin에 V2 화면과 Fleet API를 도입할 때 기존 작업 조회 경로도 남아 있었어요. 데이터와 화면이 한 번에 모두 바뀌지는 않았어요.
SWAP FE Part Lead로 주요 기능 개발과 기술 검토·코드 리뷰를 맡으며 Admin V2 릴리스에 참여했어요. 구독·작업·팩토링 화면, 버전별 이동, 권한과 운영 메뉴가 새 경로와 맞물리도록 작업했어요.
2025년 9월부터 SWAP FE의 기술 의사결정과 개발·리뷰를 맡고 있어요. V2는 팀이 함께 진행한 릴리스였고, 화면·API·운영 경로를 맞추는 작업에 참여했어요.
선택과 구현
- 01
새 화면과 기존 조회 경로의 공존
V2 작업 화면을 도입하는 동안에도 기존 작업 데이터를 조회할 경로가 필요했어요.
Admin V2 전환 범위에서 새 Fleet API·화면과 기존 경로의 공존을 다뤘어요. 릴리스 시점의 작업 상세에는 V2를 먼저 조회하고 요청 실패 시 V1을 조회하는 경로가 있었어요.
- 02
데이터 버전에 따른 화면 이동
작업을 여는 위치와 실제 작업 데이터의 버전이 다를 수 있었어요.
기존 상세 화면에서 버전을 확인해 V2 작업을 해당 상세 화면으로 보내는 흐름을 전환 범위에 포함했어요.
- 03
운영 메뉴·권한의 동반 전환
구독·작업 화면만 바뀌면 직원의 메뉴, 접근 권한과 결제·일괄 작업 흐름이 끊길 수 있었어요.
권한·사이드바, 결제 조회와 일괄 작업을 포함한 운영 기능 전환에 참여했어요.
작업 상세 진입 → V2 우선 조회 → 요청 실패 시 V1 fallback
전환 당시 작업 상세에서 사용한 조회 흐름이에요.기술적 구현
V2 전환에서는 데이터 버전에 맞춰 화면을 이동시키고 새 API 응답을 연결했어요. 상세·계약 업무에 남아 있던 기존 API 경로도 함께 다뤘어요.
- 01상세 진입
기존 주소에서 작업 데이터를 조회해요.
- 02버전 확인
응답의 작업 버전을 확인해요.
- 03V2 상세 이동
replace로 새 상세 경로에 이동해요.
- 04신규·기존 경로 공존
새 API와 기존 API의 업무 경로를 함께 유지해요.
작업 데이터 버전에 따른 이동
기존 작업 상세에서 응답의 버전을 확인하고, V2 데이터이면 새 상세 화면으로 보내도록 연결했어요. 이동에는 replace를 사용해 전환용 진입 주소가 브라우저 이력에 추가로 쌓이지 않게 했어요.
필터·페이지와 목록 응답
팩토링 목록에서는 필터·페이지 상태를 함께 관리하고 빈 필터 값을 제거해 조회했어요. 필터가 바뀌면 첫 페이지로 돌아가고, Fleet API가 돌려준 총 건수와 페이지를 테이블의 페이지네이션에 연결했어요.
화면별 API 전환 범위
신규 목록은 Fleet API의 페이지 응답을 사용했지만, 관련 상세·계약·첨부 업무에는 기존 API 경로도 남아 있었어요. 구독·작업·팩토링의 새 진입 화면을 연결했어요. 팩토링 V2 목록에 Suspense와 ErrorBoundary로 로딩·오류 경계를 구성한 팀 릴리스에도 참여했어요.
검증과 결과
- Admin V2 릴리스
2025년 12월 구독·작업·팩토링 V2 화면과 Fleet API 연동을 포함한 Admin 릴리스가 병합됐어요.
- 공존하는 작업 상세
릴리스 시점의 작업 상세에는 V2 우선 조회와 요청 실패 시 V1 조회 경로가 함께 있었어요. 이 경로의 운영 오류율은 별도로 측정하지 않았어요.
구·신규 작업 데이터가 공존하는 환경에서 Admin V2 화면·API 전환에 참여했어요.
이 사례는 SWAP 운영 Admin의 전환 경험이에요. 당시 조회 경로를 설명하되 운영 오류율이나 전체 서비스의 전환 완료 여부를 정량 결과로 제시하지 않아요.
작업에서 확인한 점
새 API와 화면을 연결할 때 기존 데이터가 남아 있는 동안의 이동·조회 경로도 챙겼어요. 다룬 범위는 SWAP 운영 Admin 전환이에요.
경력 기록과 구현 근거를 바탕으로 정리했어요. 도식은 작업을 설명하려고 재구성한 것으로, 비공개 제품 화면과 데이터는 포함하지 않았어요.