도메인 지식도 없던 신입 기획자, 첫 프로젝트에서 VOC 0건을 달성하다
방치되어 있던 택시 배차 문제를 완전히 해결해 지금까지 단 한 건의 컴플레인도 발생하지 않은 프로젝트. 놀랍게도 이 성과는 도메인 지식이 전무했던 내가 입사 3일 차에 발견해 낸 문제에서 시작되었다.
IT 서비스기획 직무로 전환하고 처음 회사에 입사했을 때였다. 2명의 사내 기획자 중 1명이 퇴사해 내가 공석을 채우게 되었다는 소식을 들었다. 당연히 남은 한 분이 나의 사수인 줄 알았으나, 우리는 아예 다른 서비스를 맡는 구조였다. 설상가상으로 퇴사하게 된 나의 전임자는 퇴사 기한을 불과 일주일 남겨두고 있었다.
모든 것이 처음 하는 일 투성이였던 나는 쏟아지는 인수인계 속에서도 ‘공동사업구역’이라는 시스템의 치명적인 구멍을 발견했고, 이에 대한 해결을 기점으로 본격적인 기획자로서의 커리어를 시작하게 되었다. 사수 없는 뉴비가 어떻게 한계를 뚫고 성공적인 MVP를 만들어 냈는지, 그 과정을 이야기해 보려 한다.
당시 나는 총 세 개의 서비스를 담당했고, 그중 하나가 회사의 주요 캐시카우 중 하나인 택시/콜밴 호출 플랫폼이었다.
도화선이 된 것은 공동사업구역에 입찰이 불가하다는 택시 기사의 VOC였다. ‘공동사업구역’이란 공항 이용객을 위해 여러 지자체의 택시가 공동으로 영업할 수 있도록 특별히 지정된 구역을 의미한다. 원래 경기도 부천시 택시는 부천에서만, 서울시 택시는 서울에서만 운행이 가능하지만, 인천공항 공동사업구역의 경우 부천과 서울을 포함해 총 6개 지자체의 택시가 모두 영업할 수 있다.
문제는 이 공동사업구역이 공항 터미널 외에도 인스파이어 리조트, 물류단지 등 인근 부대 시설까지 포함한다는 점이었다. 우리 서비스는 택시의 영업구역을 어드민에서 시·군·구 행정구역 단위의 텍스트로만 관리하고 있었다. 공동사업구역은 행정구역에 맞춰 딱 떨어지지 않는 불규칙한 형태였기에 시스템상에서 영업 처리가 되지 않았다. 기사는 뻔히 영업이 가능한 지역임에도 앱 내에서 입찰을 하지 못했다.
해당 VOC는 문의량이 많지 않다는 이유로 우선순위에서 밀려 있었다. 하지만 택시 호출 플랫폼은 기사 풀이 서비스 경쟁력과 직결된다. 기사 입장에서는 하루 수입에 영향을 주는 문제였고, 업계 특성상 불편한 경험은 기사들 사이에서 빠르게 입소문으로 확산될 수 있다. 공급자 차원에서 신뢰가 흔들리면 장기적으로는 기사 확보와 입찰 품질에도 영향을 줄 수 있다고 판단했다. 이전에 CS 업무를 주로 하며 이런 문제를 가까이서 봐 왔기에, 중요성과 시급성을 단박에 눈치챘고 이는 내가 맡은 첫 번째 과제가 되었다.
공동사업구역 지도를 뚫어져라 쳐다보던 중, 문득 한 아이디어가 떠올랐다.
‘그냥 이 모양대로 지도에 영역을 그려서 설정하면 안 되나?’
아무런 리서치 없이 떠오른 초심자의 촉이었지만, 방향성은 명확했다. 운영자가 지도 위에 구역을 그리고, 지역별 택시들이 그 구역에서 운행할 수 있도록 옵션을 주는 방식이었다.
내부에서 긍정적인 피드백을 얻은 후, 기술적으로 구현 가능한 건지 검토에 들어갔다. 이 아이디어는 특정 영역에 가상의 울타리를 치는 지오펜싱(Geofencing) 기술과 매우 흡사했다. 개발 코드는 몰랐지만, 카카오맵과 네이버 지도 등의 폴리곤(Polygon) API를 활용하면 마커를 통해 다각형을 그릴 수 있다는 사실을 찾아냈다.
나는 이 내용을 정리해 개발팀에 현재의 상황과 구체적인 해결 방안을 담아 Jira 티켓을 올렸다.
다행히도 개발팀에서 충분히 구현 가능하다는 답변이 돌아왔다. 그렇게 운영자가 직접 마커를 찍어 영역을 설정하는 지도 영업구역 관리라는 새 어드민 메뉴가 탄생하게 되었다.
이 기능의 핵심은 운영자가 지도에 마커를 최소 3개 이상 찍어 다각형 영역을 만들면, 특정 장소가 그 영역 안에 포함되는지 검증하는 것이었다. 그런 의미에서 초기 프로토타입도 훌륭히 작동했지만, 운영팀이 실무에서 사용하기에는 사용성이 다소 부족했다. 네 차례의 QA와 추가 기획을 거쳐 이를 정교하게 발전시켰다.
초기 QA에서는 주로 사용성과 정확도를 보완하는 데 집중했다. 지도를 클릭하는 것 외에도 좌표값을 텍스트로 직접 입력할 수 있도록 해 정밀도를 높였다. 또한 마커를 잘못된 순서로 찍으면 도형이 꼬이는 자가 교차 버그를 방지하기 위해 마커를 시계방향으로 추가하라는 안내 메시지를 넣었다.
이어진 두 차례의 QA에서 대대적인 수정이 있었다. 가장 큰 문제는 특정 구역을 수정할 때 기존 마커 전체를 삭제해야 하는 불편함이었다. 이를 해결하기 위해 기존 마커를 드래그 앤 드롭으로 이동할 수 있게 수정하고, 넘버링을 추가했다. 마커 이동 시 폴리곤 갱신과 기존 순서가 꼬이지 않고 정상적으로 동기화되도록 로직을 다듬었다. UI 가독성을 위해 버튼 위치를 최하단에서 영역 좌표 아래로 조정하고, 주소 입력 시 중복 좌표가 생성되는 버그를 잡는 등 디테일도 챙겼다.
이 모든 절차를 끝낸 후, 인천공항 공동사업구역 지도를 참고해 직접 영역을 그리고 지역별 택시들을 배당했다. QA 서버와 실서버 크로스 체크까지 마친 결과, 입찰의 사각지대는 말끔하게 해소되었다. 커리어 전환 후 처음으로 짜릿한 성과를 낸 순간이었다. 나아가 김포공항에도 유사한 영역이 있음을 선제적으로 파악해 추가 적용함으로써, 발생 가능한 리스크를 사전에 방지할 수 있었다.
사실 워낙 초기에 기획했던 기능이라, 한동안은 이 프로젝트가 특별히 대단한 성과라고 생각하지 못했다. 하지만 이직을 위해 포트폴리오를 리빌딩하며 업무 일지를 뜯어 보니, 도메인 지식이 전무한 상태에서 문제를 정의하고 API까지 찾아내 구현해 낸 이 프로젝트야 말로 나의 적응력과 실행력, 그리고 문제 해결 능력을 가장 잘 보여주는 사례였다. 지금은 면접에서도 가장 많은 질문과 관심을 받는 메인 프로젝트 중 하나가 되었다.
물론 아쉬운 점도 있다. 공동사업구역은 기존 행정구역 기반 시스템으로는 커버할 수 없던 예외 구역이다. 내가 만든 기능 덕분에 공동사업구역이 추가되더라도 개발팀 리소스 없이 운영단에서 즉각 대응할 수 있는 환경이 되긴 했지만, 경력이 조금 더 쌓인 지금 돌이켜보면 이 방법이 100% 옳다고 생각하진 않는다. 추가적인 대안을 충분히 검토하지 못했고, 시스템이 예외 상황을 자동 탐지하는 대신 운영팀의 수동 입력에 일임하는 방식이기 때문이다. 자주 발생하는 케이스가 아니라 이 정도 선에서 넘어갈 수 있었던 것 같기도 하다.
다만 이 과정을 통해 모빌리티 도메인의 특수한 상황을 이해하고 선제적으로 대응하는 시야를 기를 수 있었다. 또한, 어드민 기능을 기획할 때는 사전 지식이 없는 운영자도 쉽게 쓸 수 있도록 직관적이고 친절한 UX가 필수적이라는 사실도 깨달았다.
처음에는 단순한 예외 케이스처럼 보였다. 하지만 양면 고객이 존재하는 플랫폼 비즈니스에서는 공급자 경험 역시 서비스 품질의 일부가 된다. 특히 모빌리티 업계는 기사 풀이 한정되어 있고 현장의 평판이 빠르게 공유되는 특성이 있어, 기사의 신뢰를 잃는 문제는 VOC 몇 건만으로 끝나지 않을 수 있다. 작은 불편이라도 반복되면 기사 확보와 운영 안정성, 나아가 서비스 경쟁력에도 영향을 준다.
따라서, 기획자는 문의 건수만 보는 것이 아니라 문제가 서비스에 미치는 영향까지 함께 판단해야 한다. 사용자의 목소리 너머에 있는 비즈니스 리스크와 구조적인 원인까지 이해해야 문제의 본질에 도달할 수 있다. 그 과정에서 해결 방향과 필요한 기술은 자연스럽게 따라온다. 이 프로젝트는 이를 체감할 수 있었던 소중한 첫 프로젝트였다.