앱, 웹 서비스 기획에 있어 프로세스와 플로우의 중요성과 작성 난이도

여러 앱과 웹 관련 프로젝트를 진행하면서 느끼는 것은 복잡하고 어려울수록 프로세스 설계가 중요하다는 점입니다. 이 유형 설계에는 프로세스와 플로우로 구분할 수 있습니다. 이 구분은 제가 경험하면서 정리한 것이지 학술적으로나 실무 규범적으로 정해진 것은 아닙니다.

 

 

 

앱과 웹 서비스 프로세스와 플로우 

 

제 기준으로 정리한 것에 따르면 프로세스는 앱과 웹의 기능이 작동하는 데 있어 필요한 과정과 연동, 데이터 흐름을 정리한 것입니다. 플로우의 경우 화면 단에서 사용자가 메뉴나 기능을 이용하는 화면의 흐름을 말합니다.

 

이는 제가 프로젝트를 하면서 설계 공정을 정리하면서 구분한 것이지 IT 기획 관련 분야에서 정해져서 통용되는 개념은 아닙니다.

 

단지 기획자들도 서로 상이한 기획 역량을 가지고 있어서, 앱/웹 서비스 개발 및 운영 시 기획자 R&R을 정하고 배분하기 위한 필요로 제가 정리한 것입니다.

 

이 기준에 따르면 프로세스는 서버 및 데이터 연동과 흐름을 포함합니다. 플로우는 사용자가 개발 후 앱과 웹을 이용할 때 진행 단계별로 보게 되는 화면 내용과 입력 사항 등에 대한 흐름입니다.

 

그러므로 프로세스는 BA(앱과 웹 사업적 구조) 측면의 기획, 플로우는 화면 설계 측면의 기획이라 할 수 있습니다.

 

굳이 프로세스와 플로우라 구분하는 것은 실제 앱/웹 개발과 운영 실무에서 프로세스와 플로우는 서로 다른 역할과 기여를 하기 때문입니다. 

 

물론 앱과 웹 관련 프로젝트를 하다 보면 기획자가 프로세스는 물론 플로우 작업을 하지 않는 경우도 있습니다. 때때로 프로젝트 관리자의 요구로 기획자가 작업을 하기는 개발자가 설계하는 프로세스, 로직과 기획자가 작성하는 프로세스, 플로우를 구분하지 못해 오히려 개발에 방해되는 형식적인 문서만 양산하기도 합니다.

 

기획자 입장에서 보면 만약 앱/웹 개발 관련 기획을 한다고 할 때 중요한 것은 개발 완료가 되어야 합니다. 문서와 같은 형식은 개발 완료라는 목표를 달성하기 위한 수단일 뿐입니다. 

 

즉, 이런 형식은 개발 완료라는 목표를 달성하는 과정에 따라 필요에 따라 적절하게 추가, 변형되어야 합니다. 이는 기획적으로 당연한 것입니다.

 

그러나 경험한 많은 프로젝트는 서로 기술적 단위 펑션(Function)으로 구분되어 서로 상이한 기업에 책임을 맡기는 경우가 많다 보니, 형식을 바탕으로 책임 회피적 태도를 보이게 됩니다. 이로 인해 개발 완료라는 목표는 문서라는 형식에 잡아먹히게 됩니다.

 

이 또한 프로젝트 구조 관리, 프로세스 관리의 한 영역이므로 말씀드린 것입니다.

 

프로젝트 팀이 목표를 달성하기 위해 기술적 단위 펑션(Function)을 구분하고 각 단위 펑션(Function)의 역할과 책임을 규정한 후 업무 과정을 정하여 관리하는 것은 앱과 웹 개발에서 BA, 프로세스, 플로우에 대응되는 것입니다.

 

기획적으로 보았을 때 마케팅, 재무, 광고, 투자, 개발, 운영, 행사 등 서로 다른 유형의 작업이지만 기획 이론적 측면의 구조는 비슷하다는 것입니다.

 

여기서 우리가 지금 다루는 프로세스와 플로우가 부실하거나 없는 경우 기획적 완성도는 낮아지게 됩니다. 특히 프로젝트 규모가 커서 기억에 의존하여 작업할 수 없는 경우 특히 이러한 부실화는 크게 나타납니다.

 

저 또한 블로그 글을 짧게 쓰는 이유 중 하나가 바로 여기에 있습니다.

 

글을 길게 쓸 경우 사전에 주제, 구조(BA), 흐름(프로세스, 플로우) 등을 기획한 후 작업해야 합니다. 그렇지 않으면 글을 쓰는 도중 연결되지 않는 내용을 쓰게 됩니다. 

 

 

 

프로세스와 플로우  중요성 경험

 

 

케이스 1

 

과거 한 기업의 기획자로 들어간 적이 있습니다. 중소기업이었으므로 제가 해야 하는 기획의 범위는 마케팅, 광고, 제휴, 운영 또는 연동 시스템 설계, 웹 사이트 기획 등 다양한 분야에 걸쳐 있었습니다.

 

이 중 장기간 진행이 되지 않고 있던 시스템 연동 부분이 있었습니다. 편의점 ATM 기기에서 충전을 하는 시스템을 개발하는 것이었습니다. 실질적인 개발은 편의점 ATM 기기 회사에서 다 하기로 되어 있다고 했는데 일이 진행되지 않고 몇 달째 중단되어 있다는 내부 보고를 받았습니다.

 

며칠이 지난 후 편의점 ATM 기기 회사에서 미팅 제안이 왔다는 보고를 받았습니다. 그래서 그동안 일을 담당했던 팀장님(저는 그 팀 차장이었습니다)과 함께 미팅을 했습니다.

 

미팅 때 파악된 것은 그동안 개발이 안되고 있었던 이유는 우리 회사에서 충전 프로세스를 편의점 ATM 기기 회사에 전달해 주지 않았기 때문이었습니다.  

 

편의점 ATM 기기 회사에서는 프로세스만 정리해 주면 바로 개발해 편의점 ATM 기기에 반영하겠다고 말했습니다. 바로 이 프로세스 작업을 제가 해 주기로 했습니다.

 

미팅이 끝난 후 바로 편의점 ATM 기기 충전 프로세스를 정리하며 전달했습니다. 전달 후 얼마 안 되어 편의점 ATM 기기 회사로부터 충전 적용을 완료했다고 연락이 왔습니다.

 

저는 팀원들과 회사 근처 편의점으로 가서 충전을 테스트했습니다. 편의점 ATM 기기에서 충전은 문제없이 잘 되었습니다.

 

이렇게 보면 굉장히 간단해 보이지만, 프로세스를 못해서 1 주일이면 끝나는 일을 몇 달째 못하고 있었던 것입니다. 심지어 제가 회사에 들어오기까지 편의점 ATM 기기 회사와 미팅을 미루고 있기 조차 했습니다.

 

이 프로젝트에서 제가 한 것은 제 구분 기준으로 플로우입니다. 서버와 데이터의 작동 흐름은 고려하지 않고 사용자의 이용 흐름에 따라 설계했기 때문입니다.

 

 

 

케이스 2

  

과거 한 유니콘 풀필먼트 기업의 밀크런 개발 프로젝트에 기획자로 참여한 적이 있습니다. 일단 첫 미팅을 한 후 아직 전체 정리된 것은 아니지만 미팅 시까지 정리된 밀크런 시스템 관련 기능 정리 문서를 전달받았습니다.

 

초기 설계는 PM과 개발 PL, 그리고 기획자인 저 3명이 투입되었습니다.

 

일단 미팅 후 바로 유니콘 풀필먼트 기업 내 프로젝트 룸을 만들어 투입될 계획이었습니다. 이때까지는 SI 회사에서 작업을 하였습니다.

 

1차 미팅 후 투입 일이 계속 미루어지고 있었습니다. 1달, 2달 미루어지다 갑자기 유니콘 풀필먼트 기업에서 밀크런 시스템은 직접 개발하겠다는 연락이 왔습니다. 1차 미팅을 했던 유니콘 풀필먼트 기업의 담당 PO도 퇴사했다고 전해 들었습니다.

 

그러나 우리에게 비용을 지불해야 했던 SI 기업에서 비용을 받기 위해 우리가 그동안 작업했던 자료를 달라고 했습니다. 이 내용으로 비용을 청구하겠다는 것입니다.

 

저는 1차 미팅 내용과 이후 전달받은 기능 정리 문서를 바탕으로 설계한 밀크런 시스템 프로세스와 기타 작업 문서를 전달했습니다.

 

이후 SI 회사로부터 유니콘 풀필먼트 기업에서 이번 밀크런은 자신들이 직접 개발하고, 다음 진행할 프로젝트에 기획자만 투입해 달라는 회신이 왔다고 전달받았습니다.

 

그런데 1달 후라고 해서 저는 바로 할 수 있는 프로젝트를 하기로 했습니다. 이후 전해 들은 이야기로는 이 SI회사의 에이스 프리랜서 기획자가 투입되었다고 합니다. 이 기획자는 정규직 제안을 했으나 단가 문제로 장기 계약으로 묶어 두고 있는 핵심 기획자라고 했습니다.

 

그런데 이후 제가 프로젝트를 끝내고 다음 프로젝트를 위해 해당 SI 회사 사무실에서 작업을 하고 있을 때 전해 들은 이야기는 사뭇 이상했습니다.

 

SI 회사 담당 임원에게 유니콘 풀필먼트 기업에서 전화를 했습니다. 저는 근처에 있어 내용을 듣게 되었습니다.

 

내용을 요약하면 이러했습니다. 이 SI 회사의 핵심 기획자가 말 귀를 너무 못 알아먹는다는 것입니다. 그래서 고급이 아니라 중급으로 낮추자는 것이었습니다.

 

유니콘 풀필먼트 기업은 제가 작업한 프로세스 설계서를 보고 기획자를 요청한 것이었습니다. 프로세스를 설계하기 위해서는 전반적인 시스템의 비즈니스 구조(BA)와 개발을 위한 기능 정의와 기능이 작동하기 위한 조건 등에 대한 기술적 이해가 있어야 합니다.

 

이러한 기획적 부분은 화면 설계와 다릅니다. 화면은 누구나 볼 수 있기에, 누구나 비슷하게 따라 할 수 있습니다.

 

하지만 시스템 설계, 즉 BA 측면이 프로세스 설계는 비즈니스 로직과 구성, 시스템이 어떻게 작동되어야 하는지 기본적인 이해가 바탕이 되어야 합니다.

 

이 전화를 듣고 나서 이 SI 회사 핵심 기획자가 진행한 바로 이전 기획서를 전달받아 분석했습니다. 제 다음 프로젝트가 이 기획자가 한 내용을 바탕으로 진행하는 것이었기 때문입니다. 그리고 저는 PM으로 투입되어 확인을 해야 했습니다.

 

그런데 기획서는 화면 중심이었으며, 플로우조차 제대로 반영되지 않은 문서였습니다.

 

화면 플로우도 설계 못하는 기획자가 유티콘 스타트업의 시스템을 설계하러 간 것이기에 이런 전화를 받은 것입니다.

 

 

 

 

프로세스와 플로우 난이도

   

앱과 웹 시스템의 프로세스를 기획하기 위해서는 해당 시스템의 BA(사업 구조/구성)와 전반적인 개발 진행에 대한 이해가 있어야 합니다.

 

위의 케이스 2에서 다수 프로젝트 경험을 한 SI 핵심 기획자가 유니콘 풀필먼트 기업으로부터 중급 수준이라 평가를 받은 이유는 여기에 있습니다.

 

보통 SI에서는 경험이나 경력으로 초중고급 평가를 받습니다. 그러나 유티콘 스타트업 정도에서는 경험이나 경력이 아니라 실력으로 평가를 받습니다.

 

그러므로 BA와 시스템이 어떻게 개발되는지 파악하지 못하는 기획자가 유니콘급 스타트업에서 고급 대우를 받기는 어렵습니다. 

 

플로우는 조금 다릅니다.

 

사용자가 이용하는 화면의 흐름을 정리한 문서이므로 시스템이 어떻게 개발되는 전체적으로 알지 못해도 기획이 가능합니다. BA를 설계할 수 있으면 좋겠지만, 기획 못하더라도 파악만 할 수 있어도 플로우는 기획 가능합니다.

 

하지만 앱과 웹 시스템 전체 화면 구조 상에서 이용의 흐름을 이해하지 못한다면 플로우 또한 작업하기 어렵게 됩니다. 그래서 BA를 파악은 할 수 있어야 한다고 하는 것입니다.

 

이 지점에서 각 화면 하나하나를 설계하는 것과 플로우를 기획하는 것은 다르다고 하는 것입니다.

 

제 개인적으로 화면 기획자도 고급이 되려면 최소 플로우 기획은 할 수 있어야 한다고 생각합니다. 그러나 제가 본 현실은 그렇지 않습니다. 바로 이 지점이 요즘 외주 개발 프로젝트가 어려운 이유라 생각합니다.

 

플로우가 제대로 반영되어 있는지 파악하는 것은 단순합니다. 화면의 흐름과 그 속에 담겨 있는 사용자 이용의 흐름이 끊이지 않고 제대로 되어 있는지 보면 됩니다.

 

최근 고급으로 등장하는 기획자 중 많은 비율이 바로 참고(레퍼런스) 중심 기획자라는 점입니다. 그래서 프로세스는 물론 플로우조차 작업할 줄 모릅니다.

 

참고(레퍼런스) 중심 기획자란 다른 앱과 웹을 참고로 기획하는 기획자를 말합니다. 그러다 보니 각 화면 중심으로만 참고(레퍼런스) 앱/웹을 보고 따라 기획하는 경향을 보입니다. 기획의 대부분이 무언가를 참고한 것입니다.

 

참고(레퍼런스) 중심 기획자는 플로우를 신경 쓰지 않습니다. 그러다 보니 기획서는 수 백페이지지만 내용 파악이 어렵습니다. 화면과 화면이 연결되지 않고, 화면 UI의 근거가 희박합니다.

 

다른 앱/웹을 참고(레퍼런스)해서 작업한 것이기에 근거는 다른 앱과 웹이 됩니다. 여러 앱과 웹을 참고(레퍼런스)하다 보니 각 화면을 참고(레퍼런스) 한 앱/웹 다를 수도 있습니다. 그러므로 당연히 연결되지 않습니다.

 

개발자는 작업할 화면을 찾기도 어렵고, 화면과 화면 간의 관계를 파악하기도 어렵습니다, UI가 어떻게 작동되는지 일기도 어렵습니다. 이런 화면 설계서를 가지고 개발할 수 있는 개발자는 존재하지 않습니다.

 

하지만 기획서는 다른 유명 앱과 웹을 참고(레퍼런스) 한 것이기에 한 장 한 장만 보면 좋아 보입니다. 이러한 문서는 엄밀히 개발을 위한 기획서가 아니고 검수 문서로 구분할 수 있습니다. 

 

플로우를 설계하지 못한다면 IA 작업도 부실해집니다. 이에 따라 앱/웹 시스템 화면 구조 또한 부실해집니다.

 

이런 부실은 화면 경로와 화면 ID 체계 역시 엉망으로 만들게 됩니다. 결국 프로젝트가 진행될수록 화면 설계 관리가 되지 않게 되는 것입니다.

 

지금까지 이야기는 프로세스와 플로우 기획을 못해서도 나타나지만, 기획은 했지만 잘못해서도 나타납니다.

 

잘 못하면 차라리 안 하는 게 더 낫습니다. 잘못된 프로세스, 플로우는 일단 있으니까 분석해야 하고, 문제점을 파악해 수정하거나 다시 해야 합니다. 차라리 잘하는 기획자를 새로 뽑아 처음부터 하는 게 더 시간이 절약됩니다.

 

못하는 기획자는 아무리 해도 단기간 프로세스, 플로우 기획을 할 수 없습니다. 자꾸 인터넷에서 찾아서 작업하는 기획자도 있습니다. 그 정도 난이도라면 하지 말라는 말도 안 할 것입니다.