바이크 주문·계약 운영 화면
직원용 어드민과 사업자 조회 화면을 함께 만들었어요.
업무 맥락
바이크 사업의 주문과 계약, 차량 인계는 직원의 운영 업무와 사업자의 확인 과정을 모두 거쳤어요. 새 시스템을 만드는 동안에도 기존 시스템과 수기 업무는 계속 사용됐어요.
프로젝트의 프론트엔드 전반을 맡아 직원용 어드민을 개발했어요. 이후 사업자가 구독·납부 정보를 직접 확인하는 포털을 만들고, 신규 데이터에 맞춰 화면을 준비하며 백엔드와 API 계약을 맞췄어요.
백엔드 약 5명과 협업하며 프론트엔드 전반을 담당했어요. 기획자의 와이어프레임을 기존 어드민 패턴에 맞는 화면으로 구체화하고, 백엔드와 사용자 구분값·응답 필드를 조율했어요. 기존 데이터 이관과 정합성 보정은 백엔드가 담당했어요.
선택과 구현
- 01
직원 주문과 사업자 조회의 분리
영업 이후 첫 주문과 계약 발송은 직원의 업무였고, 사업자는 계약과 납부 현황을 확인해야 했어요.
직원은 어드민에서 주문을 만들고 계약서를 발송하도록 했어요. 사업자는 로그인 후 마이페이지에서 계약과 미납·납부 내역, 현재 계획을 확인하도록 화면을 나눴어요.
- 02
API 확정 전 업무 흐름 검증
반납·인수·보험 변경 화면을 진행해야 했지만 관련 API는 아직 확정되지 않았어요.
비운영 환경용 fixture로 화면과 업무 순서를 먼저 검증하고, 필요한 API·필드와 실제 연동 때 교체할 부분을 문서화했어요.
실제 요청·응답 계약이 나오자 차량·스토어·보험 화면을 그 구조에 맞춰 연결하고, 기존 필드 표현도 화면에서 호환되도록 보완했어요.
- 03
공통 사용자 모델의 사업자 업무 분리
사업자를 별도 사용자 모델로 예상했지만 실제로는 일반 사용자와 공통 모델을 쓰고 구분값으로 나뉘었어요. 사업자도 일반 SWAP 서비스를 이용할 수 있었어요.
백엔드와 구분값을 맞추고 일반 서비스 이용 흐름은 유지했어요. 사업자 전용 메뉴·페이지·API는 분리하고, 권한 거절 이후의 안내와 이동은 프론트엔드에서 처리했어요.
- 04
화면에서 발견한 B2C 응답 누락
B2B 응답을 전제로 한 자동화는 통과했지만, B2C에서는 사업자 정보 객체 자체가 없어 필요한 정보가 화면에 보이지 않았어요.
백엔드에 응답 보완을 요청하고 사용자 유형별 화면 조건을 수정했어요. 해당 케이스를 다시 정의해 자동화와 직접 화면 확인을 반복했어요.
기술적 구현
어드민에서는 API가 확정되기 전에 화면 개발을 먼저 진행했어요. 이후 사업자 포털에서는 인증·접근 확인·스토어 선택 순서로 조회를 열고, 사용자 유형에 따라 달라지는 응답도 따로 처리했어요.
- 01인증 준비
저장된 인증 상태를 복원하고 초기 처리가 끝나기를 기다려요.
- 02접근 확인
접근 요약을 확인한 뒤 스토어 목록을 조회해요.
- 03스토어 선택
목록에 있는 ID로 상세·구독 정보를 조회해요.
- 04변경 후 갱신
결제 결과를 반영하고 청구 내역을 다시 조회해요.
fixture와 실제 응답의 차이
API가 정해지기 전에는 비운영 fixture로 반납·인수·보험 변경 화면을 확인했어요. 실제 연동에서는 공통 사용자 모델의 구분값을 반영했어요. B2C 응답에 사업자 정보 객체 자체가 없는 경우를 발견한 뒤에는 응답 계약과 화면 조건, 테스트 케이스를 함께 고쳤어요.
접근 확인 뒤 순차 조회
Zustand에 저장된 인증 상태의 복원과 초기 처리가 끝나면 접근 요약을 확인했어요. 그 결과에 따라 스토어 목록과 선택 스토어의 상세를 차례로 조회하고, 조건이 맞지 않으면 SWR 키를 null로 두어 요청을 보류했어요. 로그인 필요·접근 불가·조회 오류는 각각 다른 진입 상태로 표시했어요.
스토어 선택과 결제 후 갱신
스토어는 URL, 저장된 선택, 단일 스토어 기본값 순으로 결정했어요. 상세 조회에는 목록에 있는 ID만 사용하고, 결제 후에는 성공한 항목만 SWR 캐시에 반영한 뒤 청구 목록을 다시 확인했어요. 일부 항목 실패와 전체 실패, 요청 예외도 각각 안내했어요.
외부 인증 복귀 위치의 일회성 사용
결제수단 등록을 시작할 때 복귀 위치를 sessionStorage에 저장하고 앱 브릿지로 인증 화면을 열었어요. 결과 화면에서는 저장값을 꺼내 지운 뒤 같은 출처의 포털 경로인지 확인해 이동해요. 유효한 복귀 위치가 없으면 기존 결제수단 화면으로 이어지게 했어요.
검증과 결과
- 업무 흐름
반납·인수·보험 변경을 비운영 fixture로 먼저 확인한 뒤 실제 API 계약에 맞춰 연동했어요.
- 사용자 유형
B2B·B2C 엣지 케이스를 Playwright E2E와 직접 화면 확인으로 검증했어요. 수정 뒤에도 두 방법으로 다시 확인했어요.
- 사용 범위
직원의 첫 주문·계약 발송 흐름을 개발했어요. 2026년 7월에는 사업자가 구독·미납·납부 상태를 조회하고 결제수단 처리 뒤 복귀하는 포털 흐름까지 연결했어요. 실제 이용률과 수기 업무 감소량은 별도로 측정하지 않았어요.
직원용 주문·계약 업무와 사업자가 직접 조회하는 화면을 구현했어요. API 확정 전후의 업무 흐름도 검증했어요.
기존 데이터 이관은 백엔드가 담당했어요. 수기 작업 감소량이나 비용 효과는 측정값으로 제시하지 않아요.
작업에서 확인한 점
API가 미정인 부분은 따로 두고 업무 흐름을 먼저 확인했어요. 실제 데이터가 예상과 달랐을 때는 화면의 가정을 고쳐 API 계약과 사용자 경험을 다시 맞췄어요.
경력 기록과 구현 근거를 바탕으로 정리했어요. 도식은 작업을 설명하려고 재구성한 것으로, 비공개 제품 화면과 데이터는 포함하지 않았어요.