개발자의 초기 스타트업 현장 운영 회고

1년간 셔틀버스 40대부터 밴 100대 규모의 현장을 나가며 얻은 경험과 제품 개선 사례를 기록합니다.

· 약 4분 읽기 ·
목차 · 2

저는 STAVE에 초기 창업 멤버로 참여하여 핸디버스라는 공연장 - 집 모빌리티 서비스를 운영했습니다. 주로 맡은 업무는 제품 개발이었지만 인원이 부족한 스타트업 특성상 현장에도 운영 지원 또는 총괄 역할로 나갔습니다.

1년간 셔틀버스 40대 규모의 현장부터 밴 100대 규모의 현장까지 총 10번을 나가면서 얻은 경험들과 이를 바탕으로 제품을 개선할 수 있게 된 과정을 일부 적어보고자 합니다.


셔틀 운영 현장 경험

현장에서 주로 맡는 업무는 현장 인력 총괄, 버스 기사님과의 커뮤니케이션, 출차 관리 및 현장 변수 대응입니다. 핸디버스는 크게 셔틀버스 서비스와 타다(VCNC)와 협력하여 운영하는 5인승 밴 서비스로 나뉘어져 있습니다. 두 가지 서비스를 동시에 운영하고 공연장에 따라 주차장 여부, 교통 상황, 경찰 협조 여부 등이 달라지다 보니 매번 운영 전략을 조금씩 바꿔가며 최적화된 방식을 찾아나갔습니다. 이를 위해 팀원들끼리 사무실에서 몇 시간씩 회의를 하며 유저 분들이 공연에만 집중할 수 있도록 다양한 의견을 주고받곤 했습니다. 그러나 사무실에서 말로 할 때는 잘 굴러갈 것처럼 보였으나 실제 당일에는 다양한 변수로 인해 이론과 다르게 흐른 적이 대부분이었습니다.

셔틀버스 운영 현장
타다 서비스 운영 현장
뉴스 보도
공연장 인파

핸디버스 셔틀 및 타다 밴 운영 현장, 뉴스 보도

서비스 초기에 인스파이어 아레나에서 열리는 콘서트에 셔틀버스 운영 총괄로 나간 적이 있습니다. 당시 저희는 승객 분들을 사전에 모두 오픈채팅방에 초대드린 뒤 공연이 끝난 이후 셔틀버스 대기 장소를 카톡방에 공지드리는 방식을 사용하고 있었습니다. 현장 교통 상황에 따라 대기 장소가 변경될 가능성이 있었고 노션과 카카오 지도 위치 공유 등으로 여러 번 공지할 수 있는 오픈채팅이 적합하다고 생각했습니다.

그러나 실제 현장에서는 공연장의 인파로 인해 데이터 신호가 약해 채팅을 즉각적으로 확인하지 못하는 분들이 계셨습니다. 오는 길 사진을 첨부해둔 노션 링크는 아예 열리지 않았고 대비책으로 준비했던 카카오 지도 위치 공유는 카카오 지도를 사용하지 않는 유저 분이 주소를 네이버 지도에 검색하여 전혀 다른 장소로 이동하는 상황도 발생했습니다.

저는 이를 대응하기 위해 즉석에서 당시 운용하던 스태프들을 전부 길 안내 역할로 전환하고 탑승 명단 확인은 기사님들께 부탁드렸습니다. 다른 장소로 이동하신 분의 경우 탑승지까지 다시 오시면 도보 시간이 너무 길어지고 이미 탑승한 승객 분들의 대기 시간도 길어지는 상황이었기에 버스 출발을 지연시키는 것보다 개별 택시비를 부담하는 쪽이 전체 승객 경험 측면에서 낫다고 판단하여 택시비를 전액 지원해드렸습니다.


현장 경험을 바탕으로 제품 개선까지

이 경험을 통해 저는 유저들이 공연 당일 인터넷이 되지 않는다는 가정 하에 탑승지 안내를 설계해야 한다는 것을 깨달았습니다. 저희가 택한 해결책은 당일 문자 발송과 사전 안내였습니다.

주차장을 사전 확보하지 않는 한 당일 탑승지 변경은 불가피하고 공연 앵콜 여부에 따라 종료 시각도 달라지기에 변경된 출발 시간을 당일 유저 분들에게 안내하는 것은 필수였습니다. 저희는 이를 문자로 안내드리고자 했습니다. 그런데 당시 내부 어드민에서 노선 단위로 유저 정보를 확인할 수는 있었지만 문자를 발송하려면 외부 SMS 발송 시스템에 연락처를 일일이 기입해야 하는 구조였습니다. 이를 개선하고자 어드민에 행사 단위로 연락처를 엑셀 파일로 다운받을 수 있는 기능을 추가하였고 현장 담당자가 당일에 빠르게 명단을 확보하여 문자를 발송할 수 있게 되었습니다.

사전 안내 측면에서는 서비스 내에서 로드뷰를 통해 탑승지를 더 상세하게 확인할 수 있도록 개선했습니다. 당일 변경사항이 존재하더라도 변동 가능성이 비교적 적은 행사장 행에서는 사전 안내가 특히 효과적이라고 판단했습니다. 당시 서비스에서도 탑승지를 확인할 수 있었으나 주소와 지도만으로 보여주고 있었습니다. 장소 테이블에 로드뷰 관련 정보를 추가하여 예약 내역 내에서 상세한 로드뷰를 돌려보며 탑승 장소를 확인하실 수 있도록 했습니다.

이는 모두 제가 실제로 현장에 나가지 않았다면 몰랐을 부분들이었습니다. 다른 운영 담당자에게 전달받을 수도 있었겠지만 직접 겪지 않았다면 문제에 충분히 공감하지 못하여 효율적인 개선책으로 이어지지 못했을 것이라 생각합니다. 또한 여러 현장 운영 경험을 통해 도메인을 몸으로 익히게 되었고 이는 이후 포토티켓 같은 유저 관점의 신기능 도입에도 자연스럽게 이어질 수 있었습니다.

이전 글
토스페이먼츠 상점 이전 대응과 환불 도메인 재설계
다음 글
상위 도메인이 하위를 제어하던 cascading 뒤집기