서비스 기획자 시각에서 본 서비스 기획 없는 앱, 웹 e커머스 개발 시 발생 문제

대기업 온라인 e커머스 서비스의 앱, 웹 개발을 SI를 통해 들어가서 겪은 일을 바탕으로 서비스 기획이 앱과 웹 온라인 e커머스 서비스 개발에 어떤 영향을 주는지 정리해 보겠습니다. 기획자로 투입되었을 때 상황과 고객사의 TFT 분들과 인터뷰 등을 정리합니다.

 

 

서비스 기획자로 투입되었던 상황 정리

 

고객인 대기업의 이름은 밝히지 않겠습니다. 그러나 국내 10대 재벌 중 하나로 유통 대기업 중 하나로 여러 온라인 쇼핑 서비스를 진행 중입니다. 이런 분산되어 운영 중인 여러 앱과 웹의 e커머스의 통합과 신규 e커머스 서비스 개발, 기존 운영 중인 서비스 개편 등 목적을  가진 프로젝트였습니다.

 

웹에이전시를 통해 기획 분야로 투입이 결정되어 있었는데 예정일보다 투입이 계획 늦춰지고 있었습니다. 메인 개발사로는 고객인 대기업의 SI 자회사가 전체 개발 프로젝트를 담당하였습니다. 미뤄지다 갑자기 인터뷰를 하자는 고객의 SI PM으로부터 연락이 왔습니다. PM은 웹에이전시 회사가 투입하려는 기획자/디자이너를 인터뷰하였습니다. 저는 기획, 디자인 총괄로 투입되는 것이어서 좀 색다르게 인터뷰가 진행되었습니다. SI나 웹에이전시를 통해 기획자로 투입될 때 잘 물어보지 않는 서비스 기획 가능 여부를 면밀히 인터뷰한 것입니다.

 

나중에 투입된 후 알게된 것은 이미 PI 프로젝트가 완료된 후 기획과 개발이 진행되고 있었는데 무슨 문제인지 모르는 상황에서 기획과 개발은 지연되고 있고 고객사의 TFT 분들의 불만은 이미 커져 있었던 상황이었던 것입니다. 기존 기획에 문제가 있어 우리 팀이 다시 투입된 상황이었던 것입니다. 기존 팀이 기획을 하고 있어서 투입이 계속 미루어졌던 것이고 문제가 생겨 우리 기획/디자인 팀이 투입되는데 이 문제가 바로 서비스 기획의 부재라고 고객의 TFT 분들과 SI PM이 결론 내린 것으로 보였습니다. 투입 후 고객 TFT 분들 인터뷰 시 온라인 서비스 기획이 무엇인지에 대해 설명해 달라는 요구도 받았습니다.

 

SI 프로젝트 규모가 큰 만큼 정치적 관계도 복잡했습니다. 고객의 SI 자회사뿐 아니라 국내 3대 SI 기업에서도 지속적으로 영업을 하고 있었습니다. 자회사인 SI가 시작부터 헛발질을 하자 3대 SI 기업 중 하나는 임원에 영업을 하면서 정치를 하는 상황이었습니다. 

 

 

서비스 기획이 없는 웹, 앱 온라인 e커머스 서비스         

 

재밌는 사실은 수억 원의 PI 컨설팅 프로젝트도 진행했고 통합 로그인, 통합 장바구니 기획을 이미 진행하고 있음에도 서비스 기획 문서가 없다는 것입니다. 기획 회의를 브레인스토밍처럼 진행하다 보니 회의 한번 하면 각 팀과 TFT 분들, 기획자들이 모두 모여 한 마디씩만 해도 1시간이 훌쩍 넘어가는 회의가 매일 진행되고 있었습니다. 기획이 되어있지 않다 보니 회의 진행의 방향성도 중구난방 이었고 회의 결과는 당연히 개발에 반영되지 않고 있었습니다.

 

사실 온라인 e커머스 PI 컨설팅 프로젝트가 진행되어 완료되었다면 당연히 서비스 기획과 서비스 프로세스가 나와 있어야 합니다. 그런데 서비스 관련 문서가 없었습니다. 그러니 고객의 핵심 담당자들인 TFT에서는 왜 지금 통합 로그인과 통합 장바구니 관련 회의를 해야 하는지에 대한 불만이 커져 있었습니다. 투입된 기획/디자인 팀 중 총괄인 저만 고객 TFT 사무실에 배치되었습니다. 개발 회의 한번 하면 기본 2시간 이상 진행되었는데 끝나고 나오면 TFT 분들은 불만을 한 가득 쏟아내었습니다. 투입 초기 제가 누군지 몰라서 있는데도 말을 한 것 같습니다. 

 

PI라는 용어가 가진 의미만 보아도 컨설팅을 완료했으면 통합 로그인과 통합 장바구니 프로세스는 나와 있어야 합니다. Process Innovation(PI) 이니까 당연한 결과물이 되어야 합니다. 프로세스 혁신을 위해서는 통합 프로세스에서 발생하는 연동 로직과 데이터 처리도 규정되어 있어야 합니다. 프로세스를 혁신하기 위해 각각 독립된 e커머스 시스템의 보완 개발 방안과 추가 개발 또는 새로 개발해야 할 지도 정의되어 있어야 합니다. 오프라인 마트나 상점에서 사용 중인 결재, 배송, 재고 관리 등 시스템과 통합 e커머스 시스템의 통합 운영 부분이 있다면 이에 대한 프로세스 제시가 있어야 합니다. 그런데 PI 자료에는 이런 내용은 하나도 없었습니다. 그냥 e커머스 시장 동향, 그러니까 다른 온라인 쇼핑앱, 쇼핑 사이트의 상황과 e커머스 분야별 시장 규모나 주요 플레이어에 대한 내용만 있었습니다. 

 

앱과 웹을 통해 서비스 되는 온라인 e커머스의 경우 사용 유저가 디스플레이된 상품을 보고 장바구니에 담거나 바로 구매를 하고, 결재 후 배송 상황을 알아보는 등의 프로세스 단위로 쇼핑 경험이 형성됩니다. 각각의 프로세스는 따로 또는 결합되어 해당 쇼핑 앱/웹에 대한 느낌과 이미지가 형성됩니다. 그러므로 Process Innovation(PI)의 명칭 상 핵심적 서비스 기획이 되어 있어야 하는 것입니다. 온라인 서비스 또한 용어의 의미 상 프로세스 상에서 상품이 생산되고 소비된다는 것이 포함되고 있으므로 당연이 PI 결과물에 포함되어야 합니다. 서비스 기획자 입장에서 대형 e커머스 서비스를 개발하면서 PI까지 완료되어 있는데 서비스 프로세스 관련 문서가 하나도 없다는 것은 이해할 수 없는 상황인 것입니다.

 

 

서비스 기획이 없이는 불가능한 e커머스 개발    

 

보통 SI나 웹이전시를 통해 웹이나 앱의 온라인 개발 프로젝트에 기획자로 투입되면 기획 자료가 없는 경우가 대부분입니다. 그냥 투입된 기획자는 요구사항과 RFP 내용 가지고 스토리보드를 그리는 작업부터 진행합니다. 이 조차 기획 PL이 제대로 하지 못해 초기 버전의 요구사항으로 작업해야 하는 경우도 있습니다.  그래서 금융 프로젝트는 금융 프로젝트 경험 있는, e커머스는 e커머스 경험 등 관련 분야 경험의 기획자를 선호하는 것입니다. 과거 경험을 토대로 그대로 화면을 그리다 고객 미팅을 통해 수정하는 방식으로 진행됩니다. 문제는 이전 프로젝트 경험을 바탕으로 비슷하게 기획 작업을 하다 보면 서로 다른 시스템 방식 때문에 문제가 발생하게 되는데 과거 경험을 바탕으로 기획을 해오던 기획자는 이런 문제에 대응하지 못하는 경우가 많습니다.

 

본래 기획이라는 말은 불확실성에 대응할 수 있도록 계획을 세운다라는 의미가 있습니다. 그런데 기획자가 과거를 바탕으로 작업한다는 것은 확실성에 대해서만 작업한다는 의미이므로 문제에 대응을 못하는 일이 생기게 되는 것입니다. 온라인 서비스를 기획하면서 서비스가 무엇인지는 모르고 과거 경험을 바탕으로 스토리보드 작업을 해왔다는 것은 프로젝트가 커질 수록 진행이 안될 가능성이 따라서 커지게 될 것은 자명합니다.

 

다행히 온라인 서비스 프로젝트 규모가 작고, 심플한 서비스 프로세스를 지니고 있다면 문제는 일어나지 않을 수 있습니다. 솔직히 이런 서비스는 디자이너와 개발자가 기획자 없이 기존 인기 온라인 서비스를 레퍼런스 삼아 개발해도 큰 차이 없는 결과물이 나옵니다. 문제는 제가 투입된 것처럼 복잡하고 다양한 서로 다른 서비스들이 연동되는 경우입니다.

 

온라인 프로젝트에서 서비스 기획자는 SI 프로젝트가  진행되기 전에 온라인 서비스의 프로세스를 정의하고 각 프로세스에서 발생하는 문제와 이루어져야 하는 것들을 정리하고 이때 발생하는 세부 프로세스를 정리해야 합니다. 보통 온라인 서비스 현장에서는 PI나 BPR 컨설턴트가 이 작업을 합니다. 그런데 대부분 컨설턴트는 IT 전략 또는 솔루션 기반이라 서비스 프로세스에 대해서는 잘 모르는 경우가 많습니다. 내부 ERP 등 관리 시스템을 주로 작업하므로 고객 서비스 기반 프로세스에 대한 지식은 부족합니다. 그래서 규모가 있는 e커머스 개발 프로젝트의 PI 내용이 온라인 서비스와 관련이 없는 내용이고 사전 서비스 기획 내용이 없기 때문에 개발의 방향성도 없고 개발이 진행될수록 문제가 생기는 것입니다.

 

서비스 기획자 입장에서 서비스 기획이 무엇인지에 대한 내용은 차치하고 최소한 서비스 프로세스 기획 없이 개발을  한다는 것은 기획 없이 어벤저스 영화를 찍는다는 것이고, 1000페이지 소설을 쓴다는 것이고, 리니즈 게임을 코딩한다는 것을 의미합니다. 기획 없는 코딩의 경우 수백 줄, 수천 줄까지는 문제도 없고 문제가 생겨도 수정하기 쉽습니다. 그러나 수만 줄, 수십만 줄 코딩을 해나갈수록 문제가 생길 가능성도 커지고 문제가 생기면 수정하기 어려워집니다. 함수 간 상호 관계나 변수 참조의 복잡성이 기하급수적으로 증가하기 때문입니다.

 

제가 참여한 대기업  e커머스 프로젝트의 문제도 서비스 기회자 없이 PI 프로젝트가 진행되어 온라인 서비스 개발에 사용할 수 없는 결과물을 산출했고 단순 코팅에만 몰두했기에 문제가 생긴 것입니다. 고객 대기업 자회사를 몰아내고 이 프로젝트를 먹으려던 국내 3대 SI 기업도 똑같은 실수를 반복했습니다. 서비스 프로세스 기획은 관심 없고 영업과 정치에만 집중해 자회사를 몰아낸 것입니다. 결국 이 프로젝트는 대형 SI 기업 간 정치 싸움만 하다 중단되었습니다. 1년 정도 지난 다음 보니 이 대기업은 서비스 기획자를 뽑고 있는 것을 볼 수 있었습니다.