← 모든 작업
03 / YELLOW BUSMigration · Operations

Yellow Bus 운행 도구 재구성

분산된 운영 기능을 새 Admin의 운행 흐름으로 옮겼어요.

PERIOD

2024.11–2025.08

MY ROLE

옐로우버스 스쿼드 프론트엔드 엔지니어

TOOLS & CONTEXT

React · TypeScript · TanStack Router · Kakao Map · 운영 플랫폼

01 / CONTEXT

업무 맥락

Yellow Bus를 인수했을 때 학생·배차·노선 업무는 여러 세대의 운영 도구에 나뉘어 있었어요. 내부 운영팀과 학원이 쓰는 기능과 권한도 달랐어요.

인수 초기의 기술부채와 이전 방안을 함께 검토했어요. 로그인·기본 UI에서 시작해 기존 기능을 React·TypeScript 기반 Admin의 운행 흐름으로 옮기고, 데이터 계약과 접근 범위도 새 서비스에 맞춰 정리했어요.

  • 레거시 운영 기능 이관
  • 직원·학원 권한
  • 배차·탑승·관제
  • 지도·일정 출력
맡은 역할과 협업

로그인과 기본 UI를 먼저 준비한 뒤 필요한 API를 기능별로 나눠 백엔드에 요청했어요. 기존 운영 데이터 형태와 새 응답을 맞추며 내부 직원과 학원이 쓰는 기능도 정리했어요.

02 / DECISIONS

선택과 구현

  1. 01

    준비된 API부터 순차 연동

    새 Admin의 인증과 기본 UI를 만들었을 때 운영 API가 모두 준비된 상태는 아니었어요.

    필요한 엔드포인트와 데이터 형태를 기능별로 정리해 요청하고, 준비된 API부터 순서대로 화면에 연결하는 방식을 제안했어요.

  2. 02

    보호자 정보가 없거나 여러 명인 경우

    학생 목록을 옮길 때 보호자 정보가 없거나 여러 명인 실제 데이터 형태를 함께 다뤄야 했어요.

    기존 운영 화면을 기준으로 응답 형태를 백엔드와 조율하고, 보호자 정보의 누락·복수 상황을 UI 예외 조건으로 정리했어요.

    백엔드가 변경된 응답안을 공유했고, 그 계약에 맞춰 목록 화면을 이어갔어요.

  3. 03

    운행 정보 통합 화면

    학원 담당자는 날짜별 배차와 노선, 학생 탑승 상태와 승하차 위치를 한곳에서 확인하고 변경해야 했어요.

    배차 조회와 복수 노선 지도, 탑승 상태·정류장 변경, 접근 제한을 새 운행 화면에 연결했어요. 관제에는 데이터 폴링을, 노선·정류장 관리에는 Kakao Map을 사용했어요.

  4. 04

    정류장 이름을 모를 때의 검색

    운영자가 정류장 명칭을 정확히 모르면 이름 검색만으로 원하는 정류장을 찾기 어려워요.

    주소로 찾거나 학원에 연결된 정류장 후보에서 고르는 방안을 제안했어요.

03 / ENGINEERING

기술적 구현

운행 화면에서는 학원·날짜·시간·배차 선택이 목록과 지도에 일관되게 반영돼야 했어요. 조회 데이터와 선택 상태를 나누고, 수정 후에는 해당 운행 데이터를 다시 가져오게 했어요.

  • React
  • TypeScript
  • React Context
  • TanStack Query
  • Kakao Map
  • Drag & Drop
  1. 01조건 선택

    학원·날짜·시간에 맞는 배차를 조회해요.

  2. 02지도 확인

    선택한 배차의 여러 노선을 지도에 표시해요.

  3. 03운행 수정

    탑승 상태와 승하차 정류장을 변경해요.

  4. 04데이터 갱신

    관련 조회 캐시를 무효화해요.

운행 정보 탭에서 조회하고 선택한 뒤 수정하는 흐름이에요.
STATE MODEL

상위 조건 변경 시 하위 선택 초기화

React Context에서 선택 학원·날짜·시간·배차와 지도 초점을 관리했어요. 학원을 바꾸면 기존 선택을 초기화하고, 날짜를 바꾸면 시간과 경로 선택을 비웠어요. 이전 조건의 배차가 새 조건 아래 남지 않도록 상태 간 관계를 맞췄어요.

QUERY & MAP

자동 조회와 명시적 조회

시간 목록은 useQuery로 가져오고, 배차와 경로는 useMutation으로 명시적으로 요청했어요. 선택한 배차가 없거나 조회 중일 때는 경로 요청을 막았어요. 경로가 하나면 해당 배차에 초점을 맞추고, 여러 개면 학원 위치를 중심으로 보여줬어요. 선택한 노선은 Polyline으로 강조했어요.

INVALIDATION

변경 후 관련 데이터 재조회

탑승 상태와 정류장 변경이 성공하면 해당 배차의 상세·학생 일정·정류장 목록 query key를 무효화했어요. 화면의 값만 바꾸지 않고 관련 조회가 서버 결과로 갱신되게 했어요.

INTERACTION RULES

승하차 정류장 이동 제약

학생의 승하차 정류장을 드래그할 때 같은 정류장인지, 노선 방향과 출발·도착 제약을 만족하는지, 승차와 하차 순서가 뒤집히지 않는지 검사했어요. 조건을 통과한 이동만 변경 확인 대화상자로 보냈어요.

04 / VERIFICATION

검증과 결과

API 협업

로그인·기본 UI 이후 API를 기능별로 요청했고, 학생 목록의 예외 데이터에 맞춘 응답안도 백엔드와 조율했어요.

운행 정보 화면

학원별 배차 조회, 복수 노선 표시, 탑승 상태와 승하차 정류장 변경, 접근 제한을 포함한 운행 화면을 구현했고 관련 변경이 병합됐어요.

후속 운영 기능

학생 탑승 일정과 위치를 일괄 등록하는 기능도 이어졌어요. 새 Admin의 운행 업무에 필요한 기능을 순차적으로 연결했어요.

OUTCOME

여러 도구에 나뉘어 있던 운영 기능을 새 Admin의 운행 흐름으로 재구성하고 초기 안정화에 참여했어요.

운영 흐름과 기능을 재구성한 과정을 다뤘어요. 전체 이관 완료 시점과 안정화 효과의 정량 수치는 포함하지 않았어요.

05 / REFLECTION

작업에서 확인한 점

운영 주체와 운행 순서를 먼저 정리한 뒤 기존 화면을 옮겼어요. 데이터 예외와 직원·학원의 권한 차이도 새 흐름에 반영했어요.

경력 기록과 구현 근거를 바탕으로 정리했어요. 도식은 작업을 설명하려고 재구성한 것으로, 비공개 제품 화면과 데이터는 포함하지 않았어요.

NEXT / SWAP ADMIN

SWAP Admin V1·V2 전환