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