by
Dec 26. 2022
비전공자가 IT에서 '일' 찾기 2
어디서부터 어디까지가 서비스 기획일까?
최근 채용 면접에 참석할 일이 있어 비전공자이면서 예비 서비스 기획자를 꿈꾸는 분들과 만나서 얘기를 나눌 기회가 많았다. 다들 '서비스 기획'이라는 직무에 대해 나름의 생각을 가지고 준비도 열심히 하신 분들도 계셨지만, 아쉽게도 '서비스 기획'이라는 직무를 조금 오해하고 계신 분들도 있는 것 같아 이번 글을 적기까지 많은 고민을 했다.
보통 면접에 들어가면 나는 중반부쯤에서 항상 이런 질문을 한다.
"본인이 생각하는 '서비스 기획' 직무란 어떤 것일까요?"
굉장히 추상적인 질문이지만 이것만큼 해당 지원자와 우리 회사가 얼마나 잘 맞는지, 그리고 해당 지원자는 우리 회사에게 어떤 업무내용을 기대하고 있는지 파악할 수 있는 질문은 존재하지 않는다고 생각한다. 그래서 이 질문에 어떻게 대답하느냐에 따라 합격 여부가 달라질 정도다.
그럼 이 '서비스 기획'이라는 직무가 무엇인지 자신의 생각을 표현하려면 '서비스 기획자'는 무슨 일을 하는지 흐름 정도는 알아야 하지 않을까?
그래서 이번에는 '스타트업 ■■'의 '서비스 기획자 최사원'의 업무를 통해 간략한 흐름과 주의점을 소개하도록 하겠다.
(현직에 있는 여러 기획자의 경험을 기반으로 한 내용이다 보니 일부 내용은 실제 직무 또는 커리큘럼에서 체감하는 것과는 차이가 있을 수 있는 점은 먼저 양해를 구한다.)
사용자 조사? UX 리서치? 괜찮겠어?
강남구 삼성동의 한 공유 오피스에서 커머스 스타트업 '■■기업'의 서비스 기획자 '최사원'은 오늘도 지옥철을 뚫고 무사히 사무실에 출근했다. 라운지에서 진하게 내린 아아를 한 모금 마시며 노트북을 켜던 최사원에게 옆자리의 신과장이 말을 걸었다.
"최사원 님, 제가 휴가 간 사이에 대표님께서 마이페이지 리뉴얼을 담당해달라고 하셨다던데 괜찮겠어요?"
수습기간을 막 끝낸 최사원이었지만, 나름 여러 가지 강좌와 여러 부트캠프의 기획자 과정을 통해 많은 경험을 해왔다는 자신감이 있었기 때문에 당당한 목소리로 신과장에게 이렇게 답했다.
"네, 이번주에 GA에서 추출해낸 데이터를 바탕으로 사용자 행동 분석을 진행하려고요. 그리고 마이페이지에서 일어난 이탈률을 조사하면 저희가 리뉴얼을 해야 하는 부분에 대해서도 파악할 수 있고..."
앞으로의 업무 계획을 신나게 얘기하던 최사원의 말을 듣던 신과장은 조금 걱정된다는 얼굴로 최사원에게 물었다.
"근데 대표님께서 기한을 얼마 주지 않으셨던 것 같은데... 사용자 분석이랑 UX 리서치에 너무 시간을 쏟지 않는 게 좋을 것 같아요. 차라리 해당 부분에 대해서는 운영팀에서 VOC 분석을 해둔 게 있던데, 그걸 참조해서 빠르게 기획을 하는 게 좋지 않을까요?"
그 말을 들은 최사원은 조금 당황한 기색으로 신과장에게 물었다.
"예? 그럼 저희 회사에서는 기획자가 사용자 데이터를 기반으로 기획을 하지 않나요...?"
그러자 신과장이 작게 웃으며 답했다.
"하하... 그렇지는 않아요. 하지만 기한이 얼마 없는 상황이고, 저희는 운영팀에서 단순 CS 뿐만 아니라 다양한 사용자 분석을 함께 진행해주고 있으니 직접 하는 것보다 훨씬 생산성이 높을 거예요."
최사원은 이어진 신과장의 설명을 듣고 일단 운영팀을 통해 자료를 받아보기로 했지만, 마음 한구석에서는 기획을 담당한 내가 직접 조사한 것이 아닌데 이 데이터를 믿어도 되는 것인가 라는 의문점이 남았다.
서비스 기획 관련 공부를 시작하면 일단 '사용자 조사'라던가 'UX 리서치 기법' 같은 내용을 가장 먼저 접하게 될 것이다. 모바일 환경이 대두되면서 사용자가 서비스를 구축하고 운영하는 데 있어서 무시할 수 없는 큰 요소가 되었기 때문이다. 그래서 서비스 기획을 시작할 때는 반드시 이 '사용자 조사' 또는 '사용자 행동 분석'을 가장 먼저 해야 한다고 많은 이론서 및 커리큘럼에서 소개하고 있다.
물론 이것은 정답이다. 정확히 말하면 '정론'이라고 표현하는 것이 좋을 것 같지만.
최사원의 얘기로 돌아가보자. 최사원의 이야기에서 요약할 수 있는 것은 다음 두 가지이다.
1. 얼마 주어지지 않은 기한 내에 리뉴얼을 완료해야 함
2. 운영팀에서 CS 과정에서 축적된 데이터를 바탕으로 분석해둔 자료가 존재함
처음 기획 업무를 하면 나의 첫 프로젝트라는 기쁨(??)에 배운 것을 실행에 옮기기 위해 사용자 조사와 분석을 시작하게 될 것이다. 하지만 실무를 하다 보면 조사와 분석에 프로젝트의 일정 중 귀중한 1주가량이 순식간에(!) 날아가는 것을 경험하게 될 가능성이 90% 이상이다.
물론 우리가 소위 말하는 IT 대기업의 경우 기획팀 내에 CX(Customer Experience)라는 전담 부서가 있어 이런 사용자 조사와 분석만 밤낮으로 하는 곳도 있다. 하지만 그분들과 최사원의 차이라면 그분들은 그 일만 하셔도 되고, 우리 최사원은 이 이후에 무궁무진한(...) 일들이 기다리고 있다는 점이랄까.
만약 최사원처럼 운영팀에서 이미 축적해 두었고, 분석해둔 자료가 있다면 그것을 적극적으로 활용하는 것도 '사용자 조사'가 되고 'UX 리서치'가 된다는 점을 반드시 알아두었으면 한다. 오히려 기획단계에서 모르는 운영과정에서의 다양한 사용자 UX를 내 힘 안 들이고(?) 얻을 수 있는 기회가 무궁무진하다. 능력 좋은 동료와 팀이 있다면 사용자 조사 과정에서 적극적으로 활용하자. 적어도 3일 이상의 시간을 벌 수 있을 것이다.
그럼 이 기능의 정책은요? IA는 없나요?
최사원은 운영팀의 박주임에게 전달받은 VOC 분석 자료를 통해 계정 정보를 수정하는 기능을 좀 더 눈에 잘 띄도록 리뉴얼하기로 결정하고 관련 페이지의 와이어프레임을 Figma로 열심히 설계했다. 기획자 스쿨에서 Figma를 배워두길 잘했지, 빠르게 원하는 형태의 페이지를 그리고 멋지게 인터렉션까지 넣었다. 다 그리고 나니 좀 뿌듯한 기분이 들어 만족스럽게 화면을 바라보고 있던 중, 신과장이 최사원에게 말을 걸었다.
"최사원 님, 잘 되고 있어요?"
"아, 과장님! 아주 잘 되고 있습니다. 저번에 알려주신 대로 운영팀에서 받은 자료 덕택에 생각보다 빠르게 중간 리뷰를 할 수 있을 것 같아요."
최사원은 조금 들뜬 목소리로 신과장에게 자신이 그린 화면을 보여주며 열심히 설명하기 시작했다. 하지만 너무 들떴던 것일까? 화면을 바라보던 신과장의 눈에 걱정스러움이 묻어나는 것을 최사원은 알지 못했다.
다음날, 최사원은 개발팀의 한차장과 김과장과 함께 예약해둔 회의실에서 중간리뷰를 진행했다.
"... 그래서 이 페이지에서 이렇게 전환이 됩니다. 이번 리뉴얼에 대한 기획은 이 정도인데 혹시 의견 있으실까요?"
내가 생각해도 좀 잘했어!라는 듯이 최사원은 눈을 반짝거리며 개발팀의 두 사람을 바라보았다.
하지만 왠지 두 개발자의 시선이 그다지 긍정적이지 않다. 마른침을 꿀꺽 삼키던 최사원에게 한차장과 김과장이 연거푸 질문을 하기 시작했다.
"혹시 이 기능의 정책은 이런 건가요?"
"IA는 없나요? 이대로라면 새로운 플래그를 추가하게 되는 건데, 지금 화면에서는 해당 플래그와 관련된 내용을 찾아볼 수 없고..."
"사용자 Flow를 기반으로 한다면 저건 저기에서...."
엄청난 질문 공세에 최사원은 머릿속으로 이런 생각을 했다.
'내 기획, 뭔가 잘못된 것 같아...!!!!!'
요새 기획자들에게 핫한(?) 것이 있다. 바로 프로토타이핑 툴(Prototyping Tool)이다.
실제와 최대한 가까운 환경으로 시안을 만들어 직접 시연 및 사용을 해봄으로써 초기단계부터 기획 및 디자인의 결함을 발견하고 빠르게 수정하고 적용하며 개발 생산성을 높이는데 많이 사용되므로, 요새는 이 프로토타이핑 툴을 기획단계에서 와이어프레임(Wireframe)을 만드는 데에 많이 사용하기도 한다.
하지만 이제 막 서비스 기획을 시작한 사람이라면 이 프로토타이핑 툴을 아무리 잘 쓴다고 하더라도 잠시 접어두길 권장한다. 최사원처럼 되고 싶지 않다면(?)
화면을 설계전 기획자는 정보구조 (IA : Information Architecture)를 반드시 먼저 만들어봐야 한다.
생각하고 있는 완성형이 구체적이라고 하더라도 현행 데이터베이스 내역과의 충돌은 없는지, 다른 기능들과의 중복되는 내용은 없는지, 미처 빠뜨린 요소가 없는지 반드시 사전에 검증을 하고 화면을 설계해야 기껏 만들어놓은 화면을 다 뒤집어엎는 일이 발생하지 않기 때문이다.
IA 작성 예시, 기능을 단계(Depth)별로 세분화하여 구조와 작동방식을 파악할 수 있도록 작성한다또한 화면의 각 요소가 어떻게 작동할지에 대한 정책도 반드시 사전에 준비되어야 한다.
만약 이런 정책이 기획서에 없거나 별도의 정책서로 작성되어 있지 않다면, 한차장이나 김대리처럼 기획자가 만든 프로토타이핑을 보고도 기획자에게 무한 질문을 하거나 심할 경우에는 그냥 본인 맘대로 만들어버리는 경우도 생긴다.
정책서 작성 예시, 각 기능이 어떻게 노출 될 것인지와 입력 및 처리 방식에 대한 기준을 명확하게 지정한다
기능 사용에 대한 Flow Chart 예시, 각 기능이 작동되는 순서나 구조를 확인할 수 있도록 작성한다각 팀과의 소통에서 가장 정확한 것은 명확하게 정의된 문서이다.
만들고 싶은 기능이나 내용이 확실하게 있다면 초기 단계부터 정책을 설계하고 그 뒤에 화면을 그리는 것이 소통의 오류를 줄이고 초기에 문제의 소지를 없앨 수 있다.
즉, 프로토타이핑 툴은 기획자에게 있어서 생각을 효과적으로 보여주는 보조도구일 뿐이지, 절대로 이것을 메인도구로 사용해서는 안된다.
그래서 1줄이 나와야 되나요 아니면 2줄이 나와야 되나요?
우여곡절 끝에 최사원은 IA와 정책서, 그리고 Flow Chart까지 준비하여 개발팀과의 리뷰를 무사히 마쳤다. 이제는 별일 없겠지 생각한 최사원은 Figma로 만들어둔 와이어프레임을 바탕으로 구성한 화면설계서를 외주 디자이너에게 메신저로 전달했다. 메신저에 읽음 표시와 함께 확인했다는 답장이 올라왔다.
그리고 잠시 뒤 최사원의 휴대폰이 울렸다. 외주 디자이너였다.
"네 디자이너님. 무슨 일이실까요?"
그러자 전화기 너머에서 외주 디자이너의 조금 당황스러운 목소리가 들려왔다.
"최사원 님... 정말 죄송한데, 12페이지 말인데요... 저장 버튼을 눌렀을 때 어디로 가는지는 알겠는데 입력한 내용이 길어질 경우 말줄임표를 써서 한 줄로 노출이 되어야 하는 건지, 아니면 줄 바꿈을 해서 두줄로 나와야 하는 건지 알 수가 없어서요. 이런 부분이 한두 군데가 아니라서 혹시 정확하게 화면설계서에 적어주실 수 있으실까요?"
그 말을 듣자마자 화면설계서를 열어본 최사원의 머릿속은 백지가 되어버렸다. 정말도 한두 곳이 아니었기 때문이었다.
이쯤 되니 이 프로젝트에서 최사원의 멘탈이 괜찮을지 걱정되기 시작하지만, 덕분에 우리는 시행착오를 겪어도 되지 않으니 이 점은 다행으로 생각하자(?)
정책서도 잘 됐고, 와이어프레임도 잘 만들어서 줬는데 무엇이 문제였을까? 외주 디자이너의 말을 다시 살펴보자.
1. 버튼을 눌렀을 때 어떤 페이지로 이동하는지는 파악했음
2. 단, 입력한 내용이 길어졌을 때의 노출은 어떤 식으로 될지 파악할 수 없었다
즉, 최사원의 화면 설계서에는 화면 간의 이동은 표시되어 있었으나 사용자의 입력에 대한 다양한 케이스에 대한 대응이 전혀 작성되어 있지 않았던 것이다.
화면 설계서는 가장 보기 좋은 이상적인 배치만을 보여주는 것으로 끝나서는 안된다. 사용자에 따라서는 입력 내용을 길게 쓸 수도 있고, 어떤 사용자는 좁은 스마트폰이 아닌 더 넓은 태블릿으로 서비스에 접근할 수도 있고, 또 어떤 사용자는 A버튼이 아닌 B버튼을 먼저 누를 수도 있다.
다양한 상황과 시나리오에 대해 고려하고 이에 대한 노출 방식, 대응 방식을 화면 설계서에 작성해주어야 프로젝트를 진행하는 구성원들과 당황하지 않고 무사히 프로젝트를 진행할 수 있을 것이다.
리스트의 정렬 순서를 조정한 뒤 리스트의 내역을 선택하는 시나리오를 표현한 화면 설계서잘 되는지 확인해 봤나요?
부랴부랴 생각지도 않았던 부분에 대한 시나리오를 화면 설계서에 추가해서 겨우 늦지 않게 디자인과 개발의뢰를 진행한 최사원은 일주일 뒤 개발팀의 한차장으로부터 개발이 완료되었다는 얘기를 메신저로 전달받았다. 아 정말 이제 끝났다 싶어 최사원은 마지막 단계인 QA팀의 정주임에게 메신저를 보냈다.
"이번에 기획한 내용 개발 끝났대서 QA 의뢰를 하려고요."
정주임은 귀여운 이모티콘과 함께 답장을 보냈다.
"(엄지 척) 이야~ 진짜 고생 많았다. 끙끙 앓더니 해냈네요 ㅋㅋㅋ"
하지만 정주임의 다음 말에 최사원의 등줄기에 식은땀이 흘렀다.
"근데 잘 되는지 먼저 확인은 해봤어요? 우리 팀에서 QA 들어가기 전에 기획서대로 작동하는지 먼저 확인하는 게 좋지 않겠어요?"
그러고 보니 개발이 완료되었다는 얘기를 들었지 이게 기획서대로 움직이는지는 안 봤다 싶어 재빠르게 개발팀으로부터 전달받은 개발서버 URL로 접속해 보았다. 화면설계서에 작성한 시나리오대로 버튼을 하나하나 눌러보는데...
젠장. 망했다. 에러메시지가 나온다.
최사원은 달력을 바라보며 얼마 남지 않은 마감일을 걱정하기 시작했다.
기획의 마지막 단계를 화면설계서 작성으로 알고 있는 예비 기획자 및 현직 기획자가 꽤 있을 것으로 생각된다. 하지만 이렇게 생각하는 사람일수록 기획에 큰 구멍이 있어도 눈치채지 못하고 배포 직전인 QA 단계에서 그 구멍을 발견하고 부랴부랴 수정하는 일이 자주 발생한다.
기획의 마지막 단계이자 꽃은 확인 테스트 및 검증이다. 내가 기획한 내역이 이 정도는 문제없이 작동되어야 한다는 범위를 지정함과 동시에 QA 단계로 내가 기획한 내역이 넘어가도 되는 것인지에 대한 최소한의 검증을 통해 생산성 있는 프로젝트 진행이 가능하기 때문이다. 물론 테스트는 QA의 영역 아니냐라고 말하는 사람도 있지만, 작은 규모의 스타트업이나 회사라면 QA팀이 따로 없을 가능성도 있고 QA팀이 있다면 더더욱 고차원적인 테스트를 위해서라도 확인테스트 과정을 기획자가 반드시 진행해야 한다.
한번 상상해 보자.
새로 나온 화장품 테스트를 하라고 시제품을 줬는데 뚜껑이 열리지 않는다. 이대로 과연 테스트를 진행할 수 있을까? 기획자가 확인테스트를 하지 않는다는 것은 뚜껑이 안 열리는 화장품 시제품 테스트와 같다.
기획자가 할 수 있는 테스트의 영역이라면 세너티 테스트(Sanity Test)가 되겠다.
개발이 완료되었다고 전달받은 내역이 테스트를 하기에 적합한 상태인지를 확인하는 것으로 기획 문서 및 화면설계서 등에 명시된 사용자 시나리오를 3~4단계 정도로 작성하고 기대되는 결과를 바탕으로 테스트를 진행한다.
세너티 테스트 케이스의 예시, 기획 내용 상의 시나리오를 바탕으로 기대되는 결과를 단계별로 작성해서 확인했다