카카오 T에서 ‘심야주차권’을 3분 빨리 쓰면 벌어지는 일에 대하여

제품 개발에서 유즈케이스(USECASE)를 설정해야 하는 이유

카카오 T 주차 서비스를 이용하다 만난 제품 이야기를 준비했습니다. 제품 개발 과정에서 유즈케이스(USECASE)를 제대로 설정하지 않으면 무슨 문제가 생기는지, 또 그것이 고객에게 어떤 불편함을 주는지에 대한 이야기입니다.

주차 상품 심야권(17:00~07:00)을 구입했습니다

오랜만에 제가 주로 서식하는 경기 남부와는 정말 먼 지역인 합정역 인근에서 미팅을 잡았습니다. 멀리 나가다 보니 미팅 한 건만 하고 돌아오는 것은 여러 가지로 아까웠기 때문에, 그 김에 미팅도 하고 저녁 약속도 정하고 또 오랜만에 여러 사람을 만날 즐거운 번개 모임도 잡았습니다.

저는 전기차를 타기 때문에 공영 주차장 50% 할인 혜택을 받을 수 있고 이를 정말 잘 이용하고 있습니다. 다만 이번에는 여러 건의 일정을 잡았기 때문에 전체 시간도 길었고, 제가 애용하는 양화진 공영주차장과 미팅 장소가 멀기도 해서 망설여지더군요. 그래서 카카오 T 주차 서비스를 이용하기로 했습니다.

저는 카카오 T 주차 서비스를 참 좋아합니다. 특히 카카오 T가 주차 서비스 파크히어를 인수한 이후 보여준 표준화와 스케일업 전략은 정말 탁월한 선택으로, 교과서적인 성공 사례라고 생각하고 있습니다. 가장 흥미로운 지점은 카카오 T가 기존 파크히어 시절보다 나은 방향성을 수립하고 성공시켰다는 점입니다.

과거에는 최대한 많은 주차 면수를 확보하는 것이 경쟁의 핵심이었습니다. 그 때문에 표준화되지 않은 - 사람 관리인이 처리하거나, 주차면이 비정형인 - 주차장을 포함해 최대 면수를 갖기 위해 무한한 경쟁을 했습니다. 그러나 카카오 T는 파크히어를 인수한 이후 전략을 바꿨습니다. 표준화할 수 있는 우수한 품질의 주차장만을 남기고 나머지는 모두 디마케팅해버린 것입니다. 초기에는 주차할 곳이 없다는 소비자 불만도 많았지만, 결국 표준화를 먼저 이루고 나서 표준과 자동화를 지킨 상품을 기준으로 스케일업을 해내며 지금의 위상을 가지게 되었습니다. 그렇게 지금의 카카오 T 주차는 다른 경쟁자들을 모두 따돌리고 주차 분야에서는 독보적인 선두에 올라섰습니다.

이렇게 대단하고 훌륭한 기업이지만, 이들 역시 제품을 만들고 관리하는 과정에서는 일부 아쉬운 지점들도 당연히 안고 있을 것입니다. 제가 경험한 이 사건 또한 그러한 이유로 발생했을 것이라는 생각이 들었습니다.

전체적으로 글이 진행되는 과정은 제가 과거 세탁 서비스를 사용하면서 느꼈던 지점들과 유사할 것이라 생각합니다. 세탁 서비스에서 유즈케이스가 부재한 케이스가 궁금한 분들은 이 글(CS가 탁월하면 프로덕트가 무능해진다)을 먼저 읽어보기를 권해드립니다.

“9시 1분은 9시가 아닙니다” vs. “4시 57분은 5시입니까?”

아무래도 운전을 하면서 먼 길을 가다 보면, 길이 막힐 것이 우려되기도 하고 여러 변수가 있으니 조금 여유를 두고 움직이는 편입니다. 여유롭게 출발하면 도착해 너무 오래 기다려야 하는 상황을 만나기도 하지만요. 이날도 저는 조금 여유롭게 출발했고, 무척 여유롭게 도착하게 되었습니다.

당시 저렴한 가격으로 예약한 심야권은 17시부터 이용할 수 있는 상품이었고, 40분가량 시간이 남아버린 저는 가까운 교보문고에 주차하고 책을 한 권 구매해 읽으면서 시간이 되기를 기다렸습니다.

참고로 이날 구매한 책은 “실리콘밸리 프로세스의 힘”입니다. 제목은 마치 “실리콘밸리의 팀장들”처럼 뭔가 신뢰가 가지 않는 느낌이지만, 평소 프로세스쟁이를 자처하는 제게는 필독해야 할 책이라는 생각이 들 정도로 좋았습니다. 특히, 문제를 해결하지 않고 없애버리라는 서평은 정말 매력적이었습니다. 참고로 “실리콘밸리의 팀장들(원제/ Radical Candor)”도 제목만 빼고 보면 참 좋은 내용입니다.

그렇게 시간을 보내다 17시가 다 되어가는 것을 확인하고는 차량을 이동해 예약한 주차장으로 향했습니다. 제가 주차권을 예약한 곳은 교보문고 바로 옆에 붙어있는 건물이지만, 그래도 출차하고 이동하고 다시 입차하는 과정이 5분은 넘을 거라고 생각했는데, 너무 효율적으로 이동한 탓에 2~3분 만에 다음 건물에 들어서 버리게 되었습니다. 어쩐지 이날은 엘리베이터도 한번 기다리지 않고 바로 탈 수 있더라고요.

그렇게 문제의 사건이 일어나버렸습니다. 17시부터 이용할 수 있는 심야 주차권으로 16시 57분(16시 47분 30초 정도)에 입차했고, ‘뭐 2~3분 정도야 버퍼로 처리되겠지’ 안일하게 생각했던 저의 예상을 비웃듯 아무런 알림이나 통보 없이 상품이 강제 취소되어 버린 것입니다.

나는 지금 어디에 있는 것일까? 제품의 여정 속에서 길을 잃다

주차를 하는 과정에서 생각보다 빠른 전개 - 5분은 걸려야 하는데 2.5분 만에 이동해 버린 그 전개 - 에 저도 잠시 머뭇거린 순간이 있었음을 고백합니다. ‘들어가지 말고 한 바퀴를 돌아와야 할까’하고요. 하지만 이미 막히기 시작한 도로를, 그리고 다가오는 미팅 시간을 보며 저는 용감하게 주차장으로 진입했습니다.

사실 믿는 구석도 있었거든요. 카카오T 주차를 꽤 자주 이용하다 보니 어느 날은 몇 분 빨리 들어가도 문제가 없었던 경험도 있었고, 심지어 다른 케이스에서 상담원에게 이런 상황을 물어보고 ‘연동 주차장의 경우 5분 정도 여유는 두고 있습니다’는 답을 들은 적도 있었죠.

어떠한 경우든 시간제 제품을 개발하다 보면 약간은 버퍼를 유지하게 됩니다. 물론 절대 시간은 하나이지만, 그 시간을 바라보는 시계는 아주 다양하고, 그 사이에는 약간씩 오차가 있어 작게는 몇 초에서 십여 초, 많게는 일이 분까지도 존재하기 때문이죠.

이를테면 남산터널 혼잡통행료는 정확하게 21시 정각부터 면제하지만, 경부고속도로 버스전용차로의 일반 승용차 이용은 정규 시각인 22시보다 2~3분 정도 빨라도 단속받지 않습니다. 남산터널 혼잡통행료 징수를 위해서는 톨게이트에 커다란 시계를 두고 면제 여부를 정확하게 표시(Indicate)하고 있지만, 버스전용차로는 그렇게 할 수 없어 개인 시계(보통은 차량이나 내비게이션의 시계)에 의존하기 때문이죠.

그렇게 주차하고 미팅을 마치고 다음 장소로 이동하려던 저는 평소와는 무언가 다르다는 것을 인지했습니다. 주차를 이용하고 있다는 표시가 앱에서 보이지 않는 겁니다.

카카오 T 주차는 상품을 예약했을 때는 ‘이용중:주차권 예약’이, 상품을 이용하는 동안에는 ‘이용중:주차중’이라는 상태가 표시됩니다. 물론 이런 정보들은 반드시 실시간으로 표시되기보다는 주차장 시스템과 배치 시스템이 돌아가는 주기에 따라 30분에서 한 시간 정도 늦게 표시되는 일도 자주 있습니다. 그에 ‘주차권 예약’이 ‘주차중’으로 바뀌지 않는 것은 늘상 있는 일이지만, 이렇게 아무것도 뜨지 않는 것은 처음 경험해 보는 일이었거든요. 앞서 찜찜함도 있었던 저는 상담을 시도하기로 합니다.

채팅 상담은 말이 안 통하는 참 어려운 물건입니다. 안내하기에는 아주 편리하지만, 제대로 된 상담은 사실상 불가능한 것이 아닌가 싶기도 합니다. 특히 전문적인 상담이 필요한 저 같은 프로불편러에게는 갑갑하기 짝이 없습니다.

제품쟁이의 직업병: 없는 유즈케이스를 추정해 보기  

*짐작한 것을 기반으로 글을 쓰다 보니, 실제와 다소 다른 부분이 포함되어 있을 수 있습니다. 그러한 부분이 있다면 관계자분들이 불편하게 여길 수 있을 것입니다. 이점 미리 양해를 구하고 사과드립니다. 

서론이 너무 길었습니다. 여러분이라면 이런 상황에서 어떻게 대응하시겠습니까? 사람마다 성향이 다르니 대응도 다 다르겠습니다. 하지만 저를 포함한 프로덕트 매니저(Product Manager), 그러니까 제품쟁이들이라면 왜 이 제품은 이런 상황에서 이렇게 작동하게 되었는가를 생각해 보게 됩니다. 한번 돌이켜 볼까요.

이는 사용자가 진입을 했는데 시간 조건이 ‘Fail’한 상황입니다. 그래서 그 상품을 “이용” 혹은 “결제”할 수 없게 되었습니다. 결제에 필요한 조건 파라미터 중 하나가 실패했기 때문이죠. 그렇게 시스템상 불가피하게 제품 이용이 강제로 취소되어 버린 것입니다.

참고로 카카오 T 주차 상품 중 시간제 이용 상품(3시간권 등)은 초과 이용을 해도 강제로 취소되지 않습니다. 3시간 초과 이용분은 주차장 일반 요금에 맞게 추가 요금을 카카오 T에서 자동으로 청구합니다.*

*물론 이 정책도 올해 2월, 제 차가 출차되지 않은 것으로 처리되어 하루 최대 요금이 부과된 적이 있었습니다. 그때도 CS에서 탁월하게 처리해 주셔서 요금을 강제로 조정한 적이 있습니다. 하지만 그 이후로는 아주 매끄럽게 잘 작동하고 있습니다. 아마도 뭔가 엣지 케이스 오류가 있었고, 이 부분을 잘 패치한 것 같습니다.

물론 “법적으로 사용자 과실이니까 사용자 책임이야”라고 할 수도 있을 것입니다. 단순하게 “규정 시간보다 일찍 입차했기 때문에 앞서 ‘3분’에 대해서는 그 상품을 이용할 수 없다”라고 한다면 이 부분은 저와 같은 프로불편러들도 받아들여야만 하는 상황입니다.

다만, 그로 인해 예약했으나 이용하지 않은 ‘주차 심야권’이 강제로 취소되는 것은 어떻게 받아들여야 할까요? 그리고 만약 취소를 했다면, “예약한 주차권 상품이 취소되었습니다”라는 안내가 도착하지 않은 것은 왜일까요?

(제 생각으로는) 이 상황은 제품 정책에서 예상하고 규정한 “취소”가 아니기 때문입니다. 즉, 사용자가 이용하는 유즈케이스를 설정하고 그 예외를 미리 처리하지 않았기 때문에 설정된 ‘취소 API’를 객체로서 호출하여 처리하지 않은 거죠. 또 그에 따라 ‘취소 API’에 연동되어 있는 자동알림기능이 작동하지 않았습니다.

그저 입차에 따라 차량 번호를 기반으로 배치를 돌렸고, “사용중 처리” 과정에서 파라미터 값 검증이 Fail하며 프로세스가 실패한 것입니다. (시스템에서는 에러코드와 로그가 남았겠지만) 사용자에게는 아무런 정보 제공과 알림 없이 그냥 해당 요청(request)을 “죽여”버렸거나 스스로 “죽어”버린 것이라고 짐작됩니다.

많은 기업에서 제품을 개발하고 기능을 구현하며 해당 기능에 대한 유즈케이스를 수립하지 않고 그냥 개발 요건만 가지고 개발을 진행합니다. 해당 주차장을 운용하는 회사는 “아마노코리아”라는 큰 주차장 운영 기업이고, 그 기업에서는 아마도 SI를 이용해 외부에서 운용할 API와 배치 시스템을 구성했을 것입니다. 그 API를 받아 우리 쪽에서 요건에 맞게 호출하고 처리할 때, 정산 부분을 제외하면 저 개발 요건에 따라 개발하고 구성하는 것은 어려운 일이 아닙니다.

하지만 아마노코리아는 카카오 T 주차의 사용자와 유즈케이스, 예외 케이스를 스스로 고려하고 준비해야 할 기업은 아닙니다. 그래서 카카오 T 주차에서 단순히 API 제공자(provider)의 가이드라인만 보고 요건에 맞춰 개발을 한다면 사용자의 유즈케이스를 모두 충족시켜 나갈 수는 없습니다.

개발 요건 중심

입차 시간 안내 > 입차 시간 확인 > 입차 처리(이때, 입차 시간 파라미터가 Fail) > 주차권 사용 처리 실패

유즈케이스(USECASE) 중심

사용자가 입차할 수 있어야 한다 > 입차하면, 시간 정보를 확인하고 정상 입차 여부를 노출해야 한다 > 비정상 입차가 되었을 경우 » 시간 차이가 n분 이내라면, 사용자의 오사용 가능성을 고려하여 재입차 안내를 실시한다 » 시간 차이가 n분 이상이라면, 사용자의 이용 의사가 없는 것으로 판단하여 주차권을 취소하지 않고 유지하되, 사용자에게 리마인더 알림을 전송한다.

‘고객 중심’이라는 건 CS보다 제품이 하는 것

우리 서비스를 이용하는 우리 고객은 ‘사람’입니다. 사람은 요건대로 움직여주지 않습니다. 그래서 아주 많은 예외를 만들어 내고, 그렇기에 예외를 모두 미리 준비하는 것은 당연히 불가능합니다. 하지만 그 예외를 합리적으로 추정하고 대응하며 보완하는 것은 가능합니다.

사용자를 가정하고(페르소나), 사용자의 행위를 가정하고(메인 시나리오), 그리고 그 가정된 행위에서 세부 시퀀스를 분리해 유즈케이스를 구성하면, 그 유즈케이스에서 발생하는 예외 상황이라거나 오류 상황, 혹은 진입이나 작동을 막아야 하는 지점을 찾아 문제를 예방할 수 있습니다. 또는 아예 사용자의 진입점(Entry Point)을 설계하여 예외가 발생할 수 있는 경로를 차단해버릴 수도 있습니다.

그래서 제가 주장하는 제품 개발 프로세스에서는 “사용자의 형상화”가 아주 큰 부분을 차지합니다. 사용자를 구체적으로 형상화하면 그 사용자가 살아 움직이며 동선과 행위를 상상하고 사용자의 유즈케이스를 설계하는 것이 가능해집니다.

하지만 사용자가 배제된 API 문서(Document)만 가지고 얼기설기 순서를 배치하고, 요구하는 대로 파라미터를 붙여 Json을 발행해 버리면 그곳에는 사용자의 행동이나 동선(흔히들 말하는 유저 저니(User Journey)), 그리고 사용자에게 발생하는 예외가 존재하지 않기 일쑤입니다.

제가 경험한 케이스에서 사용자의 동선과 상황을 약간 틀어, 이렇게 설계해 보면 어떨까요?

사용자 김민석(가명) 씨는 17시부터 사용할 수 있는 심야 주차권을 예약했습니다. 같은 건물에 위치한 교보문고에서 1시간 주차권을 받을 수 있었기 때문에, 김민석 씨는 16시 30분에 주차장에 진입했고, 교보문고에서 주차권을 받아서 17시 20분에 출차한 다음, 미리 예약했던 심야권을 이용하기 위해 17시 22분에 같은 주차장에 다시 입차하였습니다.

김민석 씨는 예약한 주차권을 무사히 잘 이용할 수 있었을까요? 혹시 궁금한 분이 있다면 위와 같은 상황을 한 번 재현해 보는 것도 좋겠습니다. 현실 세계에서의 ‘개밥먹기(Dog Fooding)’ 같은 QA가 될 것 같아 흥미진진하네요.

참고로 소프트웨어의 QA를 수행할 때에도 유즈케이스가 수립되어 있으면 정말 편리합니다. 그 유즈케이스를 그대로 따라해보면서 Pass or Fail을 확인하면 되니까요. API 문서를 들고 API의 배치 순서대로 작동하는지만 QA하는 것은 그다지 서비스의 퀄리티를 보장할 수 있는 방법은 못 됩니다.

또 하나의 ‘운수좋은날’ 같은 하루 

사건이 벌어졌던 당일에는 피곤하고 짜증이 나기도 해 스트레스를 받았습니다. 저는 계획을 많이 세우는 편이 아니지만, 일단 세운 계획은 그대로 이루어지지 않으면 극심하게 스트레스를 받기도 하거든요. 그날은 그렇게 스트레스를 받기도 하고, 채팅 상담 과정에서 아주 피곤하기도 했고, 비싼 주차비를 피하기 위해 차량을 이동하면서 약속 시간에 조금 늦기도 하는 등 아주 재수 없고 거지 같은 날이라고 생각했습니다.

하지만 어쨌든 저는 또 미팅도 잘했고, 저녁 약속도 잘했고, 이후 모임에서도 즐거운 시간을 보낼 수 있었습니다. 게다가 이렇게 글 한 편을 쓸 수 있는 소재를 얻은 날이기도 했죠. 마치 현진건의 소설 ‘운수좋은날’에서의 역설처럼, (소설과는 정반대로) 어떻게 보면 참 재수없는 날이었을 수도 있겠지만, 덕분에 이렇게 또 글 한 편을 내었으니 제게는 고맙고 감사한 날이었다는 생각이 듭니다.

무엇보다 PM으로서 다시 한번 유즈케이스에 대해 돌아볼 수 있는 날이기도 했고요. 그렇게 다른 분들도 이 이야기를 제품을 개발하는 과정에서 유즈케이스를 고려하는 계기로 삼아주면 좋겠습니다. 저 역시 앞으로는 4시 57분에 입차하지 않도록 동선을 잘 설정하겠습니다.

**카카오 T 주차의 CS팀은 정말 탁월한 역량을 보여주었습니다. 채팅 상담은 너무 불편했지만, 다음날 CS팀에서 상황을 리뷰한 이후 전화 상담을 먼저 걸어주셨고, 주차장 공급사마다 버퍼 정책이 상이할 수 밖에 없다는 말도 해주었습니다. 또, 제가 본 금전적 손해에 대한 보상과 제품팀으로 문제를 리포트해 개선하겠다는 다짐도 밝혀주셨죠. 이 자리를 빌어 카카오 T 주차 상담 팀장님께 감사를 전하며, 프로불편러를 상대해야만 했던 상담원분께도 불편을 드려 죄송하다는 말씀을 남깁니다. 그분들이 이 글을 봐주신다면 좋겠네요.

이 글에서 간단하게 예를 든 사건 외에도 수많은 상황을 누군가는 마주하고 또 경험하고 있을 것이고, 이렇게 해주었으면 저렇게 할 수 있다면 하는 많은 방법론들을 생각해 낼 수 있을 것입니다. 이 글을 읽는 독자분들 중에 이런 사항을 경험하고 공감하는 분이 있다면 댓글로 생각을 남겨주세요.

또한, 제품 개발 과정(Agile Product Development Process, APDP)에 대해, 특히 PRD에 대해 궁금한 분들을 위해 커피챗 신청 창구를 만들었습니다. 링크를 참고해 주세요.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.