brunch

You can make anything
by writing

C.S.Lewis

by Sebs Aug 16. 2019

Back to the 'Start Line'

우연치 않게 찾아온 기회를 통해 2015년 부터 갖게 된 서비스 기획 직무는 어느덧 4 년 차를 내달리고 있습니다. 결코 짧지 않은 4 년 이라는 시간 동안 기획자로서 부족한 조각조각을 채우며 일 해왔습니다. 하지만 여전히 기획자로서의 능력과 사고 방식은 부족한 것이 많다고 느끼고 있고 그만큼 고민도 깊습니다. 어떤 방향으로 나아가야 할지, 어떻게 나아가야 할지 등등.. 이런 고민을 하던 와중에 지금까지 기획자로서 지내온 시간들을 돌이켜 보고 그 시간 속에서 어떤 경험을 했고 무슨 생각을 했으며 배움으로 이어졌는지 정리해보고 싶어 졌습니다. 그래서 기획자로서의 인생을 살게 된 그 시작점으로 돌아가는 것 부터 시작했습니다.

0. 우리는 모두 기획을 하고 있다.

IT 쪽 서비스와 제품 기획을 하는 일은 2015년 부터 시작했지만, 실제 사회 생활의 첫 발걸음은 2012년 11월 부터 시작되었습니다. 대학교 4학년 마지막 학기 중에 취업을 하게 된 것이었습니다. 한창 진로 고민이 많은 시기였는데, 주변 친한 선배들이 어린 아이들을 위한 두뇌 운동 지도사 로서 그 업에 대한 자부심과 책임감을 갖고 일하는 모습을 보고 저 또한 그 길을 따르기로 결정했습니다.

그렇게 결정한 순간 부터 이미 머릿속에는 하고 싶은 일이 정해져 있었습니다. 기존 정해진 기본 프로그램 이외에 아이들에게 도움이 될 만한 추가적인 운동 프로그램을 개발하는 것이었습니다. 운동 프로그램을 개발하기 위해서는 실제 현장에서 목적에 맞는 의도와 방법을 직접 적용해 보고 실제 결과가 어떤지 바로바로 피드백을 받는 것이 매우 중요했습니다. 탁상공론이 아닌 직접 내 앞에 펼쳐진 그대로를 경험하고 결과를 토대로 다시 수정된 프로그램에 적용하는 것. 사회생활을 처음 시작했을 때부터 이미 문제를 인식하고 문제 해결의 목표를 달성하기 위해 가설을 세우고 검증하며 검증 결과를 통해 프로그램을 개선해 나아가는 기획이라는 것을 하고 있었던 것 같습니다.

물론 사회생활 뿐 아니라 학교에서 과제를 할 때, 일상에서 여행 계획을 짜려 할 때에도 우리는 목적을 가지고 그 목적을 달성하기 위해 기획을 하고 있다고 생각합니다. 우리들은 모두 각자의 위치에서 기획을 하고 있으며, 모두 기획자인 셈 입니다.

이렇게 정리하는 법을 몰랐던 그 때에는 그냥 머릿 속으로만 생각을 해서 노트에 내용을 적고 '기획' 이라는 것을 했던 것 같다.

1. 불현듯 다가온 서비스 기획자

현장에서 기획한 여러 운동 프로그램들로 아이들을 케어 한지 2년여 정도 되었을까요? 운이 좋게도 본사로 발령이 났습니다. 이제는 현장이 아닌 오피스에서 더욱 큰 그림을 보며 일을 하게 된 것이었습니다. 처음에는 자리를 잘 잡지 못하고 이것 저것 잡다한 업무들을 수행하던 중 불현듯 저에게 운동 센터 관리 시스템 개발 PO (Product Owner) 라는 역할이 주어졌습니다.

PM? Agile? UXUI? Database? Table? Column? Query? Java 랑 Java script 는 달라? 내 인생과는 전혀 연결고리가 없을 것 같던 처음 들어보는 용어들이 저와 가까워지기 시작했습니다. 프로젝트의 시작부터 개발이 완료된 시스템이 배포된 후 운영까지. 흔히 말하는 A to Z 를 모두 경험할 수 있었던 소중한 시간들 이었습니다. 특히나 이제 막 서비스 기획을 시작한 주니어 기획자에게 프로젝트를 리드하며 모든 단계들을 경험할 수 있다는 점은 정말 내가 행운아라고 할 수 밖에 없는 기회였다고 생각합니다.

2. 서비스 경험의 중요성

아직도 IT 개발에 대해서는 배경지식도 없는 저에게 왜 그렇게 막중한 임무가 맡겨 졌는지 정확히 알 수 없지만, 저의 2년 간 현장 경험이 프로젝트를 진행할 수 있는 여러가지 장점들을 가지고 있었을 것이라고 판단했던 것 같습니다. 실제로 프로젝트를 진행하고 제품을 운영 하면서 현장 경험은 여러모로 내게는 이로운 무기 였습니다.

기존 현장의 ①운영관리 문제점과 예외 케이스 파악이 용이하다 보니, 자연스럽게 ②서비스를 플로우화하여 작성하고 그 안에서 개선해야 할 다양한 요구기능과 해결책 들을 백로그(backlogs)로 쉽게 정리할 수 있었습니다. 또한 ③관리해야 할 데이터를 단시간 내에 결정할 수 있었고 무엇보다 현장과 본사 안에서 이루어지는 내용과 입장들을 잘 알고 있다보니 중간에서 ④커뮤니케이션 할 때에 일방적으로 치우치지 않고 진행할 수 있었습니다. 물론 완벽했던 것은 아니었습니다. 제일 힘든 부분이 커뮤니케이션이 었습니다.

현장에 대한 배경 지식과 정보를 모두 이해한 상태에서 프로젝트를 시작하고 운영할 수 있다는 것은 처음 서비스를 기획함에 있어 대단히 유리한 점 이라고 생각합니다. 그래서 꼭 내가 기획해야 할 서비스의 문제점을 파악하고 해결책을 고민 할 때에는 꼭 기존 서비스를 직접 사용 해보고 경험 해본 뒤 기존의 서비스를 플로우 차트로 도식화 하여 점검해 보는 것은 기획 업무에 있어 큰 도움이 됩니다.

3. 악몽 같았던 데일리 미팅

프로젝트는 Agile Scrum 방식으로 구성되어 진행 되었습니다. 당시 재직하던 회사의 개발 팀장님께서 사내 프로젝트에 Agile 정신을 심기 위해 부던히 노력하셨던 것이 생각이 납니다.

개발 팀장님을 스크럼 마스터로 하여, 1주 단위로 Sprint 를 나누어 프로젝트를 진행하기 시작했습니다. 매일 마다 스크럼 마스터, 개발자, 디자이너가 모여 어제 한 일, 오늘 할 일, 이슈들을 공유하는 데일리 미팅이 있었습니다. 아침에 약 15분 정도 되는 짧은 시간이었는데 개발 프로젝트 초심자인 저에게는 악몽과도 같은 시간이었습니다.

프로젝트를 리드하며 점검해야 할 PO 가 경험 1도 없는 초짜에 아는 것이 많지 않다보니 팀원들이 나에게 질문을 하거나 방식에 대해서 문의를 할 때면 식은 땀을 줄줄 흘리기 일수 였습니다. 모르는 걸 자신있게 모른다고 말할 수가 없었습니다. 개발자들이나 디자이너들이 조금 더 쉽게 내게 이야기해 주었으면 좋겠다는 생각도 많았고, 나를 조금 배려 해주었으면 하는 생각도 했었습니다. 하지만 그것을 표현할 수가 없었습니다. 왜냐하면 그것들을 드러내는 순간 내가 PO 로서의 자격이 사라지는 것이라고 생각했었습니다.

결국 당시에는 모르는 걸 모른다고 이야기 하지 못하고 억지로 이해한 척 하고, 식은 땀을 흘린채 데일리 미팅이 어수선하게 끝나기를 몇 차례 반복했습니다. 그렇게 프로젝트 사이클이 몇 주간 반복되고 이어가면서 자연스럽게 기반 지식이 쌓이고 그들과 소통할 수 있는 용어나 원리 등을 공부하며 조금 씩 안정감을 찾았지만 지금 생각해보면 조금 더 용기를 갖고 심적으로 여유를 갖은 상태에서 모르는 것을 적극적으로 물으며 데일리 미팅을 명확하게 마무리 했다면 더욱 서로간의 신뢰가 쌓인 상태에서 프로젝트가 탄력을 받지 않았을까 하는 아쉬움이 남는 기억입니다.

데일리 미팅은 숨김이 없어야 합니다. 여러 사람이 함께 이야기하고 프로젝트에 대한 내용을 공유하는 자리이기 때문에 무엇이든 진실과 사실을 이야기하면 함께 해답을 찾을 수 있는 소중한 15분 입니다. 일대일로 이야기 했을 때 풀리지 않던 이슈가 다수와 함께 이야기 했을 때 의외로 손쉽게 풀어지는 순간입니다. 프로젝트를 할 때 업무시간에는 각 팀원들은 각자에게 할당된 일에 몰두해야 하기 때문에 함께 모였을 때 그 사실을 공유할 수 있는 시간은 굉장히 소중합니다.

사람은 누구나 창피함을 느끼기 싫어합니다. 모르는 것, 업무가 지연되는 것, 할 수 없다고 생각되는 것 등을 타인에게 밝히는 순간 치부를 드러낸 것과 같은 감정을 느끼게 됩니다. 하지만 공동의 목표를 함께하는 프로젝트에서는 서로를 신뢰하는 것이 가장 중요하다고 생각합니다.

4. 모든 것이 내 의도대로 될 줄 알았던 착각

관리 시스템 개발이 마무리되고 제품이 배포될 즈음에서 부터 무언가 잘못되었다는 것을 조금씩 알게 되었습니다. 관리 시스템을 직접적으로 사용하게 될 2~30 여개의 센터에서 개발된 시스템의 UI 와 기능들에 대해 반발이 심했습니다. 현장을 경험했다고 해서 현장을 다 알고 있다고 생각을 했지만 현실은 그렇지 않았습니다. 나는 그저 현장을 경험했던 사람 중 하나 일 뿐이었습니다. 각각의 센터마다 운영하는 스타일이 달랐고, 내가 겪어보았기에 문제라고 생각했던 운영상 이슈가 다른 센터에서는 이슈는 커녕 오히려 장점이 되는 부분도 있었습니다.

"아! 그들의 문제를 근본적으로 파악하지 못했구나!"
"그들의 문제를 개선 해주지 못했구나!"

서비스를 기획 할 당시 나는 내가(나만) 고객이었다 라는 사실에 몰두해 있었습니다. 사실 고객은 다양했고 각기 받아들이는 것이 달랐는데, 나는 내가 정답이라고 생각했습니다. 내가 기획한 기능을 내 의도대로 움직여주지 않을 때 굉장한 괴리감이 몰려왔습니다. 심지어 기능, UIUX 적으로 현장에서 회의적인 피드백이 들어올 때면 더욱 더 나를 자책하기 시작했습니다. 그때부터 내 탓, 남 탓 가리지 않고 하게 됩니다.

하지만 결국 나를 인정해야 합니다. 서비스든, 내부 시스템이든, B2C든, B2B든. 어쨌든 고객이라는 목표가 있습니다. 고객이 외면하는 서비스는 아무리 내가 옳았다고 외쳐대도 소용이 없는 것이라고 생각합니다. 나를 인정하고 정말로 부분적인 기능이 문제인 것인지, 전반적으로 서비스와 제품의 근본적인 설득력이 없는 것인지 다시 돌아가 생각해보는 것이 대단히 중요하다는 것을 느끼는 순간이었습니다. 가끔 기획을 하다보면 자신만의 생각에 매몰될 때가 있는데, 이 순간이 가장 위험하다고 생각합니다. 이럴 때 일수록 더욱 침착하게 주변을 둘러볼 줄 아는 여유를 갖고 눈과 귀, 마음을 열고 다시 생각해볼 줄 아는 통제력 있는 기획자가 되어야 한다고 생각합니다.

2016년. 그때는 Product Manager 라는 타이틀이 멋있어서, 그렇게 되고 싶었다.

처음 기획자가 되었을 때에는 무언가 다 갖춘 상태에서 시작하고 싶었습니다. 탄탄하고 예외 케이스가 1도 없는 완벽한 기획과 걸작을 상상했습니다. 처음에는 전문 지식도 없고 나를 이끌어줄 경험 있는 사수도 없었기 때문에 수학의 정석처럼 정해진 이론과 방법을 알아내고 배우고 싶었고 그런 것이 존재하는 줄 알았습니다. 함께하는 개발자나 디자이너 분들께 기획한 산출물을 전달해줄 때 정해진 문서 형식과 구성이 있어야 한다고 생각했습니다. 하지만 기획이라는 것은 정말로 정답이 없다는 것을 알았습니다. 결국 내가 겪었던 경험이 더 나은 나로 만들 수 있는 지름길이라고 생각합니다. 내가 직접 부딪히는 경험은 앞으로 하게 될 수많은 프로젝트의 밑거름이 될거라 믿어 의심치 않습니다. 경험이 재산입니다. 경험은 누구도 가르쳐주지 않는 온전히 자신의 것이라고 생각합니다.

글 요약 정리,

적절한 가설 제시과 효율적인 검증을 반복하고 정리하여 문제를 개선하는 기획자가 되어야 한다.

기존의 서비스를 직접 경험하고 서비스 플로우를 도식화하여 점검하는 기획자가 되어야 한다.

모르는 것, 할 수 없다고 생각되는 것들을 팀원들과 사실대로 공유하고 함께하는 기획자가 되어야 한다.

자신만의 생각에 매몰되지 않고 여러 고객들의 생각을 둘러볼 줄 아는 여유로운 기획자가 되어야 한다.

경험으로부터 얻는 배움은 누구도 가르쳐주지 않는 최고의 자산이다.

keyword