수요응답형 DRT '타바라' 개발

어떤 서비스인가

수요응답형 교통(DRT)은 정해진 노선을 도는 버스가 아닙니다. 승객이 부르면 그때 차가 정해지고, 태우는 순서와 경로도 그때 만들어집니다. 그래서 화면 몇 개를 만드는 일이 아니라 하나의 운행을 호출부터 하차까지 상태로 추적하는 시스템을 만드는 일이었습니다.

쓰는 사람이 셋이라는 점도 일반적인 앱과 달랐습니다.

누가	무엇이 필요한가	어떤 환경에서 쓰나
승객	부르고, 언제 오는지 보고, 타고, 결제한다	자기 휴대폰에서 가끔
기사	배차를 받고, 길 안내를 받고, 승하차를 처리한다	운행 내내 켜 둔 채, 운전 중에
차량	운행 정보를 차 안에 띄운다	아무도 만지지 않는 고정 단말

기존에 쓰던 대여 플랫폼은 이 구조를 담지 못했습니다. 고쳐 쓰는 대신 신규 구축으로 방향을 잡았습니다.

무엇을 만들었나

• 승객 앱 (Android · iOS) — 호출, 도착 예정 확인, 좌석, 결제, 이용 내역, 공지·문의
• 기사 앱 — 배차 수신, 길 안내, 승하차 처리, 휴식 상태 전환
• 차량 단말 앱 — 차 안에 띄우는 운행 정보 화면
• 서버 — 배차 규칙, 운행 상태 관리, 결제·취소, 푸시, 운행 로그
• 관리자 — 운행 이력, 정기 이용, 결제 관리, 통계

어떻게 개발했나

1. 앱을 하나로 만들지 않았습니다. 승객·기사·차량 단말은 쓰는 사람도 환경도 다릅니다. 승객은 가끔 열고, 기사는 운전 중에 조작하고, 차량 단말은 아무도 만지지 않은 채 하루 종일 떠 있습니다. 하나로 묶었다면 셋 다 불편한 앱이 됐을 겁니다.

2. 지도를 용도에 맞게 나눠 썼습니다. 승객 앱에는 익숙한 지도 화면을, 기사 앱에는 실제 길 안내가 되는 내비게이션을 붙였습니다. 승객이 필요한 건 “어디쯤 왔나”이고 기사가 필요한 건 “어디서 좌회전인가”라서, 같은 지도를 쓸 이유가 없었습니다.

3. 상태 변화는 서버가 밀어 넣습니다. 호출이 들어오고, 배차가 잡히고, 차가 도착하고, 타고 내리는 과정은 몇 초 단위로 바뀝니다. 앱이 서버에 계속 물어보는 방식 대신 바뀐 시점에 해당 기사와 해당 승객에게만 밀어 넣는 구조로 만들었습니다. 배터리와 데이터를 덜 쓰면서 화면은 더 빨리 바뀝니다.

4. 배차는 사람이 아니라 규칙이 잡습니다. 호출이 들어오면 대기 중인 차량 가운데 운행·휴식 상태를 확인해 자동으로 배차하고, 잡히지 않으면 배차 실패로 처리해 승객에게 바로 알립니다. 성공과 실패가 모두 상태로 남아서 나중에 운행 기록을 되짚을 수 있습니다.

5. 승하차를 승객이 신고하지 않아도 되게 했습니다. 차량에 설치한 근거리 신호를 승객 앱이 감지해 탑승을 확인하고, 신호가 끊기면 하차로 처리하는 구조를 넣었습니다. 버튼을 누르지 않아 운행이 끝나지 않는 문제, 좌석이 반납되지 않는 문제를 줄이기 위한 장치입니다.

힘들었던 점

승하차 처리는 사무실이 아니라 현장에서 완성됐습니다. 설계대로 만든 뒤에도 승하차 부분은 가장 여러 번 고친 곳입니다. 처리 방식을 바꾸고, 승하차 팝업에서 뒤로 가기를 막고, 팝업이 자동으로 갱신되게 하고, 중도 하차 화면을 따로 손봤습니다. 실제 차 안에서는 기사가 손님을 응대하면서 화면을 누릅니다. 책상에서 맞는 흐름과 흔들리는 차 안에서 맞는 흐름이 달랐습니다.

실시간은 100%가 아닙니다. 지하차도나 신호가 약한 구간에서는 밀어 넣은 정보가 늦게 도착할 수 있습니다. 실시간 구조를 아무리 잘 짜도 현장에서는 “지금 화면이 안 바뀌는데요”라는 상황이 생깁니다. 그래서 운영 중에 기사가 직접 지금 상태를 다시 받아오는 새로고침을 넣었습니다. 자동화가 실패했을 때 사람이 빠져나갈 길을 만들어 두는 편이 낫다고 판단했습니다.

앱이 셋이면 배포도 셋입니다. 안드로이드 정책이 바뀌거나 외부 지도·내비게이션 SDK가 올라갈 때마다 세 앱을 함께 점검해야 했습니다. 승객 앱만 올리고 기사 앱을 두면 같은 운행을 두 앱이 다르게 보는 상황이 생깁니다. 운행 중인 서비스라 배포 시점도 운행이 없는 시간대에 맞춰야 했습니다.

한 번 멈추면 그날 승객이 못 탑니다. 일반적인 서비스라면 장애가 나도 나중에 다시 들어오면 됩니다. 교통은 그렇지 않습니다. 그래서 운행 상태·결제·푸시를 각각 기록으로 남기고, 잘못된 상태로 멈춘 운행을 정리하는 절차를 따로 뒀습니다.

그 뒤

2023년 11월에 착수해 2024년 7월 정식 운행에 들어갔고, 2026년 6월까지 유지보수를 이어갔습니다. 구축 기간보다 운영 기간이 훨씬 긴 프로젝트였습니다.

출시 이후에 한 일은 새 기능을 얹는 것보다 운행하면서 드러난 것을 고치는 일이 많았습니다. 승하차 흐름, 공지·문의 같은 운영자 도구, 정책 변경 대응, 그리고 현장에서 올라온 요청들입니다.

이런 곳에 맞습니다

• 운행·운영 규칙이 사업 중에 바뀌는 프로젝트
• 이용자·현장 인력·설치 단말처럼 쓰는 사람이 여럿인 서비스
• 출시가 끝이 아니라 몇 년 단위로 이어서 손봐 줄 팀이 필요한 경우