웹/앱 서비스 기획자가 하는 일
서비스 출시를 기념하며
저번주 내가 기획한 서비스가 출시가 되었다. 내가 작성한 기획서를 기반으로 서비스가 만들어졌다는 것이 마치 내가 하지 않은 것처럼 느껴졌다. 참 기분이 묘했는데 기쁨도 성취도 아니었다. 이 경험을 바탕으로 이 글에서 내가 생각하는 서비스를 기획하기 위한 서비스 기획자의 일을 써보고자 한다. 물론, 서비스 기획 중에서 내가 몸담고 있는 웹/앱 서비스 기획이다.
(1) 타겟층에 대한 이해
내가 만드는 서비스를 누가 쓰는지 명확하지 않다면 먼 산으로 갈 가능성이 높다. 이 서비스가 왜 필요하고 왜 사용하는지 끊임없이 질문을 던져야 한다. 이 번 서비스를 기획하면서 나는 문득 클라이언트가 회사의 이익만을 대변하는 것은 아닐까 생각이 들었다. 자세하게 내용을 밝힐 수는 없지만 이에 대한 고민이 깊지 않았기 때문에 정책이 흔들리거나 자주 변경되었다. 그렇다 보니 서비스를 기획하는데 애를 먹었고 당연히 기획에서 흔들리니 프로젝트 전체가 흔들리게 되었다.
(2) 정책 작성
내가 처음 서비스 기획을 할 때 정책이라는 말을 처음 들었는데 꽤나 어색하게 들렸다. 쉽게 말하자면 서비스의 기준이다. 유튜브를 예로 들자면, 유튜브 프리미엄 가격, 유저에게 어떤 알림을 줄 것인지, 스크롤하다가 몇 개의 콘텐츠를 로드해 줄 것인지 등 서비스 내용에 대한 설명이다. 다만, 정말 핵심적인 유튜브 프리미엄 가격, 동영상 업로드 용량 크기 제한 기준, 인기 급상승 동영상에 대한 기준 등 서비스 방향성에 대한 내용은 한 데모아 명확하고 충분한 근거아래 정해져야 서비스 개발이 원활하게 이루어질 수 있다.
(3) 법령 조사
서비스 기획자는 눈을 크게 떠야 한다. 단지 소비자와 앱 사이의 관계를 볼 것이 아니라 이 서비스를 둘러싼 이해관계자들을 한눈에 조망해야 한다. 그중 하나는 국가(공공기관)이다. 서비스가 아무리 편해도 그것이 유저의 권익을 해친다면 법적 제재로 서비스 운영이 불가할 것이다. 전자상거래가 오간다면 이에 대한 법령 조사가 필요할 것이고 유저의 생체 정보가 오간다면 적절하게 유저에게 허락을 구해야 한다. 또한, 다른 서비스에서 벤치마킹한 것이 있다면 다른 서비스의 권익을 해치는 것은 없는지 확인해야 할 것이다.
(4) 기획서 작성
많은 조사를 기반으로 서비스에 대한 정책이 작성되었다면 실제 산출물을 만들기 위한 기획서가 필요하다. 여기서 작성에 대한 포션은 회사마다 다를 것이다. UX 디자이너/PO/PM/서비스 기획자 등 다양한 이름으로
불리고 있는데 나에게는 솔직히 말장난처럼 느껴진다. 회사에서 필요한 업무가 어느 부분에 치중하느냐에 따라서 이름을 붙이고 있는데 아쉬운 것은 회사를 운영하다가 조금씩 아쉬운 부분을 기획자라는 이름을 가진 인원에서 덕지덕지 붙이다 보니 혼종이 되어가는 것 같다.
UX 디자이너는 서비스 내용에 맞게 화면 설계를 구체적으로 하는 사람을 일컫는 것처럼 느껴지고 PO/프로덕트 매니저(PM)는 서비스 정책이나 방향성에 힘을 주고 프로젝트 매너지(PM)은 서비스 개발 공정 관리에 힘을 쓰는 것 같다. 그러나, 하는 일들은 비슷하고 웬만큼 IT에 관심 있는 회사가 아니라면 이름과 무관하게 그냥 모든 일을 얹어주고 있는 것이 현실이다.
내가 느끼기에는 서비스 기획자는 프로젝트 진행과 관련 논의에 대해 모두 알아야 한다고 생각하고 그 아래 문서 산출물은 여러 기획자가 나누어 맡아 진행되야 한다. 앞서 말한 서비스 자체에 대한 큰 조망 없이 분업만 나뉜다며 필시적으로 그 작업에 대해 매몰되어 방향성과 동떨어진 산출물이 나올 것이다.
여기서 또 하나 말하고 싶은 것은 절대 기획서는 혼자 작성하는 것이 아니다. 문서를 쓰는 사람이 한 사람일지는 모르나 이에 참여하는 사람은 다른 기획자, 개발자, 디자이너, QA 등 다양한 직군의 사람이 되어야 할 것이다. 우리는 무한한 시간과 자원을 가지고 일하는 것이 아니며 한정된 시간과 자원 안에서 최고의 산출물을 만들어내기 위해 일하는 것이다. 이런 공감대 없이 기획자가 독단적으로 서비스 방향성과 개발 기준을 설정해 버린다면 그 기획은 현실화되지 않을 가능이 높다. 또한, 기획자뿐만 아니라 다른 직군에서도 서비스에 대한 방향성 이해는 필요하다. 이런 이해도 기반한 작업 진행 중 더 나은 산출물을 만들기 위한 아이디어가 그들에서 나오는 것이 흔한 일이다. 기획자는 신이 아니기 때문이다.
(5) 커뮤니케이션
또 하나 유념할 것은 커뮤니케이션 시간을 고려한 프로젝트 기간이 산정되야 한다. 혹자는 현실과 동떨어진 소리라고 할지 모르나 오히려 이 것이 현실이다. 이미 운영되는 서비스 개선 프로젝트를 가정해서 이미 이해와 서비스 공감대가 형성되었다 할지라도 논의는 필요하며 새로운 프로젝트에서는 처음 시작하는 일이기에 커뮤니케이션 비용은 기하급수적으로 늘어난다.
논의 > 결정 > 정리 > 공유의 프로세스는 프로젝트 진행 내내 반복되기에 이를 줄이기 위해 협업툴에 대한 관심이 증대되었던 것이며 손쉬운 의사결정을 위해 데이터 기반 의사결정이 계속 고민되었던 것이다. 단순 기획 > 개발 > 디자인 > QA로 진행 혹은 형식적인 스프린트 프로세스 논리로 프로젝트 기간을 산정하고 진행한다면 프로젝트 완성도는 뒷전이기 될 것이다. 이 보다 큰 문제는 내부적으로 불화와 일 떠넘기는 문화가 정착해 있을 것이다. 원활한 커뮤니케이션과 협의가 이루어지지 않은 일이 정리되지 않은 채 진행된다면 각자의 이해관계에 따라서 진행되고 각자의 기록과 기억에 진행된 결과물은 책임전가 문제로 반기게 된다. 이 문화가 자리 잡는 순간 그 프로젝트는 그냥 넘어갈지 모르나 이후 프로젝트에서 삐걱거리는 일이 예삿일처럼 될 것이다. 그 이후는 프로젝트 멤버 퇴사/신규 멤버 충원/실무는 잊은 정치질 무한궤도에 빠지게 된다.
