리버스 플래닝; 역기획

Posted in Planning // Posted at 2018.12.09 21:00

리버스 엔지니어링(Reverse Engineering)이란 장치 또는 시스템의 기술적인 원리를 그 구조 분석을 통해 발견하는 과정으로 기계장치나 전자부품, 소프트웨어 프로그램 등을 조각내서 분석하는 것을 말한다. 
리버스 엔지니어링은 상업적 또는 군사적으로 하드웨어를 분석한 것에서 시작되었으며 원본 생산의 절차에 관한 지식이 거의 없는 상태에서 최종 제품을 가지고 디자인 결정 과정을 추론하는 것에 그 목적이 있다.


기획자로서 처음으로 (이 회사에서 처음 한 것들이 참 많다. SI도 처음 해봤는데 하고 싶지 않았던 일들을 다 해보고 있는 것 같다.) 타인이 기획해 상용 중인 모바일 서비스를 웹서비스로 포팅(Porting, 한 환경에서 작동하는 프로그램을 원래 설계된 바와 다른 환경에서 작동할 수 있도록 프로그램을 변경하는 행위)한다며 리버스 플래닝(Reverse Planning, 역기획)(이라고 쓰고 분석하며 기획 중이라고 읽자.)을 하고 있는데 하루 종일 한숨(이라고 쓰고 쌍욕이라고 읽으면 된다.)이 몇 번이나 나왔는지 모르겠다.

어떻게 기획을 하고 개발을 해야 이런 서비스가 나올 수 있는 것인지 내 머리로는 도저히 이해할 수가 없었기 때문이다.

그 여파로 이 글을 쓰는 새벽까지도 머리가 지끈거릴 정도로 두통이 심했다. :(

핀테크나 거래소, 전자지갑과 같은 금융결제 서비스의 로그인과 회원가입 등의 프로세스가 복잡한 것을 모르는 바는 아니지만 적어도 이런 서비스를 기획하는 서비스 기획자라면 이 프로세스를 정확하게 이해하고 설계를 하거나, 그도 자신이 없다면 기존의 정형화된 프로세스를 따라야 하는데 기존의 정형화된 프로세스를 따르지도, 정확하게 이해하고 설계하지도 않아 비밀번호를 찾거나 비밀번호나 핀번호 등의 불일치로 인한 잠금을 해제하는 과정에서 무한 로딩이 돌고 플로우가 중간에 끊겨 사용자가 고객센터의 도움 없이는 해결할 방법이 없는 등 도저히 한 서비스 기획자로서 납득하거나 이해할 수 없는 지경이다.

그런데 모바일 서비스와 관리자는 타 회사에서 개발 및 관리를 하고 있는지라 백오피스를 크게 바꿀 수도 없는 상황에서 API 통신을 통해 웹서비스를 개발하고 구동해야 하는 상황이다 보니 좋고 나쁨을 떠나 기본적인 설계의 오류로 인해 모바일 서비스조차 정상적인 작동을 하지 못하는 상태에서 웹서비스를 기획해야 하니 하루 종일 한숨이 나올 수밖에.

더욱 열 받는 것은 '리버스 플래닝(Reverse Planning, 역기획)'이라고 이야기한 것처럼 해당 서비스를 기획한 기획자는 퇴사를 하였고, 그 기획서는 버전 관리가 제대로 되어 있지 않아 풀 사이즈의 기획서가 없다 보니 결국 상용 중인 모바일 서비스를 직접 이용해가며 기획을 하는데 이 모바일 서비스를 사용하면 사용할수록 고객들에게 미안함과 부끄러움이 들면서 동시에 한 사용자로서 분노를 감출 수 없기 때문이다.


한 예를 들자면, 

1. 로그인 10회 이상 오류를 냈는데 관련 알림도 없어 정확한 계정으로 로그인을 해보니 그제서야 로그인 10회 불일치로 인해 핀코드로 로그인을 하라고 한다.


2. 그래서 핀코드마저 잊었다 가정하고 핀코드 재설정 버튼을 클릭했더니 무한 로딩... @.,@;;
2_1. 위 상태를 재현한 다음 핀코드마저 5회 오류를 냈다. 그러니 고객센터로 문의하라는 알림이 뜬다.

3. 로그인 페이지로 이동해서 비밀번호 찾기(이메일 인증)를 통해 로그인을 했다.
3_1. 계정이 잠겼다며 계정 활성화 메일이 발송되었다고 한다.
3_2. 메일을 통해 계정 활성화 링크를 클릭하고 ID를 입력하니 '인증 레벨이 낮아 계정 활성화를 할 수 없습니다. 고객센터에 문의해주세요.'라는 알림 메시지가 뜬다.
3_3. 그리곤 로그인을 할 수가 없어 결국 고객센터로 연락을 해서 해결을 해야 한다. 

이쯤 되면 정상적인 사용자였다면 분명 저주를 퍼부으며 앱을 바로 삭제했을 것이다.


비밀번호 찾기 프로세스를 그린 플로우 차트. 좌) 기존 프로세스 우) 신규 프로세스

그런데 인증 레벨이 낮다고?

갑자기 인증 레벨이 비밀번호 찾기 프로세스에서 왜 등장하는지 이해를 할 수가 없다.

이 뿐만이 아니다.
정상적인 경로에서의 로그인과 회원가입에는 문제가 없지만 비밀번호 찾기부터 멀티 로그인 제한 및 기기 변경 시 처리 등 예외적인 케이스에서 사용하는 기능들은 대다수 잘못된 프로세스로 설계되어 짜증과 분노를 느끼게 한다.
게다가 맞춤법에 무척 민감해서 서비스에 표시되는 모든 문장은 습관적으로 맞춤법검사기를 필수로 돌리는 기획자인데 눈 뜨고 보기 힘들 정도로 맞춤법이 틀린 곳이 너무 많다.

기능이 부족하거나 없을 수는 있다. 이는 지속적으로 고도화하거나 사용자의 요구에 따라 추가하면 된다. 하지만 상용 서비스에서 제공하는 기능과 프로세스는 매끄럽게 흘러가야 한다. 

그래서 내가 항상 후배 기획자들에게 하는 이야기가 자신이 기획한 서비스가 회원가입에서 탈퇴까지, 각 곁가지로 뻗어나가는 플로우들이 막힘없이 머릿속에서 굴러가야 하고 이 흐름이 아주 매끄럽게 그려져야지 조금이라도 의심이 들거나 제대로 그려지지 않으면 그 기능과 프로세스를 살펴보고 또 살펴보고 또 살펴봐서 머릿속에서 완벽하게 굴러갈 수 있게 해야 한다고 강조하는 것이다. 
그리고 연차가 늘어갈수록 머릿속에서 돌아가는 기획서의 장수가 늘어날 뿐이다.


O2O 커머스의 상품 구매에서 배송까지의 프로세스를 그린 플로우 차트

O2O 커머스에서 해외직구 상품의 등록 및 통관, 배송 프로세스를 그린 플로우 차트. 한 서비스를 기획하다 보면 여러 프로세스를 그린 수장의 플로우 차트를 그리게 된다. 이 프로세스들이 머릿속에서 매끄럽게 흘러가야 한다.


유지보수보단 항상 처음 서비스를 기획하고 상용화하는 구축형 기획자의 역할 위주로 하다 보니 벤치마킹이나 분석만 해봤지 이렇게 포팅을 하기 위해 기획서를 그려가며 리버스 플래닝을 해 본 적이 없었는데 다시는 이런 방식의 기획을 경험하고 싶지 않다. 
물론 신입 및 초급 기획자들에겐 기획을 배울 수 있는 좋은 학습 방법론임에는 틀림없다고 생각한다.

서비스 기획자에게 기능과 UI/UX도 중요하지만 가장 기본적인 프로세스나 플로우는 제대로 설계를 해야 하는 것 아닌가! 설계에 자신이 없다면 서비스 기획자라고 하지 않았으면 좋겠다. 그냥 UI 기획자라고 이야기하자.

폰에 깔려있는 그 앱을 볼 때마다 내면 깊은 곳에서 뜨거운 빡침이 올라온다. 

author image
'세균무기, 지구별에 흔적을 남기다!' 블로그를 운영하는 세균무기입니다.
법학과 행정학을 전공한 IT서비스 기획자이자 프로덕트 매니저이며, 변방의 한 블로거입니다. IT와 스타트업에 관심이 많으며 여행과 애플 제품, 블랙아이드피스의 음악, 커피를 격하게 애정합니다.


submit