기존 서비스 시스템을 모르겠을 때
기획자는 찾아보고 테스트해보고 물어보고 씹고 뜯어야 한다
신입 기획자들의 질문은 특권이긴 한데 가끔 너무 남용된다. 어떤 친구들은 왜 처음부터 시스템을 제대로 가르쳐 주는 사람이 없냐며 불만을 갖기도 하는데, 아마도 이 불만은 영원히 해소되기 어려울 것이다. 시스템의 파악은 어디까지나 '본인 하기 나름'일 수밖에 없는 뼈아픈 이유가 있다.
사실 어떤 선배도 전체 시스템을 - 토씨 하나 틀리지 않고- 정책을 줄줄 외우는 것은 불가능하다. 하나의 서비스에서 오랜 기간 일을 해왔어도 그 한 명이 계속 프로젝트하고 서비스를 만드는 시간 동안 다른 기획자들도 같은 시스템을 열심히 개선해나가고 있기 때문이다.
서비스는 멈춰있지 않는다. 계속 변한다. 계속 발전하고 서비스는 계속 추가되기 때문에 새로운 서비스를 기획하여 추가하기 앞서서 현행 정책과 서비스 상태를 파악해야만 한다. 그래야 헛발질하는 기획을 최소화시킬 수 있다.
문제가 없는 서비스를 기획하기 위해서는
그 어떤 돌다리라도 두드려 봐야 한다
함께 일하던 토끼 같은 신입 기획자가 한 번도 해 본 적 없던 소위 '뒷단'의 복잡한 업무를 맡게 됐다. 가이드하고 도와주려다 보니 그 업무를 많이 해봤던 나였어도 갑자기 뭔가 확 부족한 기분을 받았다. 평소 기본 정책은 다 안다고 자부했는데 내가 정책을 습득한 시점이 2012년. 그 광활한 5년 사이 일어난 무수한 정책 변화에 대해서 막 또렷이 알려줄 자신이 없다는 기분이 들었다.
지금 토끼 같은 아가 기획자는 스펀지 같은 시절이라 내가 자칫 잘 못 가르쳐주면 잘못된 정책을 빨아들일까 걱정됐다. 책임감을 가지고 제대로 정리해서 가르쳐주고 싶었다. 물론 이런 공부도 자신의 지식이 되려면 선배가 아니라 본인이 직접 하면 훨씬 더 자신의 것이 될 것이지만, 아직 비즈니스에 대한 이해도 부족한 상태에서 기본에서 변경된 상세 정책부터 찾아내서 공부하면 너무 힘들 거 같기도 하고, 신입의 배가 산으로 가도 방향타가 틀렸다고 해도 의논하며 잡아갈 시간도 없었으니까, 나 역시 강제로 초심 장착하고 기존 시스템을 공부할 수밖에 없었다.
운영 중인 서비스에 중간에 투입된 기획자라면 신입이고 경력이고 누구를 막론하고 거쳐야 하는 과정이 바로 이 '현행 분석'이다. 학생 때는 대부분 요점 정리나 핵심 정리해줄 누군가가 존재하지만 회사에 오면 사실 아무도 없다. 선배가 아무리 설명해준다고 해도 본인이 뒤져보면서 뼈에 새기는 만큼 내 지식이 된다. 누가 안 가르쳐줘서 몰랐다고 말해봤자 그건 자기 손해다. 큰 목차는 가르쳐줄 수 있어도 세부사항까지 다 가르칠 천재 같은 선배는 별로 없다.
거창할 것은 없지만 보통의 현행 서비스와 정책을 분석하는 현실적인 방법들에 대해서 이야기해보고자 한다.
개발자 같으면 소스를 까서 보지만
기획자는 역사를 뒤져야 한다
STEP1. 정책서를 읽는다.
서비스가 아주 잘 정돈돼서 운영된다면 모듈을 아우르는 정책문서가 있기 마련이다. 하지만 서비스 운영기간이 길고 서비스의 양이 방대할수록 어휘 정리나 굵직한 서비스 목차 수준이 되기 쉽다. 그래도 머리 속이 백지와도 같은 상태에서 정책서는 적어도 어디에서 뭘 알아야 하는지 경로를 정해주는 역할을 한다.
수십장의 정책서 앞에서 자연히 예의가 바르게 변하는 기획자STEP 2. 스토리보드와 화면을 동시에 본다.
정책서를 보고 난 다음에는 모니터 2개에 한쪽에는 스토리보드와 한쪽에는 실제 구현 화면을 찾아서 띄운다.
한쪽에는 스토리보드 한쪽에는 구현화면을 켜자 출처:구글스토리보드를 읽을 때는 적어도 3가지를 파악해야 하는데 1) 서비스 목적 2) 기능별 프로세스 3) 케이스 다.
전시 스토리보드의 경우 흐름과 동작, 인터렉션 등이 많기 때문에 보면서 화면을 쉽게 파악했다고 생각이 들지만, 정말 중요한 건 한눈에 파악 안 되는 '디스크립션'에 있다. 눈에 보이는 화면의 구분보다 각 버튼이나 숨겨진 기능이 나열되어 있는 백오피스 backoffice의 기획서는 더더욱 모든 핵심이 디스크립션에 있다.
근데 이 디스크립션이 진짜 난제다. 디스크립션이라는 게 규칙이 있다기보다는 작성자마다 개성이 묻어나고 수준 차이도 많이 나기 때문에 디스크립션을 눈으로만 읽고 이해했다고 생각한다면 오산이다.
그래서 한쪽에 실제 구현 화면을 펴놓고 어떻게 구현됐는지 확인해봐야 한다. 적어도 UI노출 정도는 확인해볼 수 있으니까. 그리고 화면 설계서와 실제 구현이 너무 다르다면 원래 기획하거나 개발했던 담당자에게 부분 부분 물어보면서 현행 파악을 해야 한다.
STEP 3. 테스트해본다
사실 여기서 화면을 조금씩 깔짝대며 몇 번 보았다고 테스트해봤다고 하면 안 된다. 진짜 테스트는 앞에서 분석한 케이스대로 프로세스를 따라가면서 이해했던 대로 작동하고 있는지 파악하는 과정을 의미한다.
이 과정에서 이해가 안돼서 계속 ( -"-) 이런 표정이다가 ('0')이런 표정과 함께 '아~ 이거구나' 이 소리를 연발하게 된다. 그제야 정책과 서비스가 체화되기 시작하는 자연스러운 탄성이다.
운영 서비스에서 해볼 수 있는 건 바로바로 하고 만약에 비정상적인 케이스나 돈이 드는 거라면 회사 내부의 테스트용 서버에 접속해서 테스트해보게 해달라고 해볼 수도 있다.
결국은 제대로 한번 해보는 게 제일 중요하다.
STEP 4. 내 손으로 도식도 만들고 질문 찾아내기
수십 가지의 정책과 프로세스가 정리되어 있었어도 내 손으로 한번 정리해보면 그 효과는 배가 된다. 플로우 차트와 마인드맵은 훌륭한 정리 도구가 된다.
개인적으로 자주 사용하는 '무료'서비스 2가지를 소개한다.
Xmind : 마인드맵 도구
draw.io : 웹에서 바로 사용하는 플로우 차트
이 두 가지를 이용해서 모듈 또는 서비스 단위로 정책은 마인드맵으로 도식도는 플로우 차트로 정리한다. 이렇게 내 머릿속에서 정리된 걸 내 손으로 정리하다 보면 드디어 '구멍'이 나타난다. 이해한 줄 알았는데 이해 못했던 것과 2차원적인 SB와 정책서에는 아주 미세하게 적혀있고 시간 때가 제약적이거나 해서 테스트할 때 해볼 수 없는 것들에 대한 질문이 떠오르게 된다. 또는 SB가 너무 오래돼서 미쳐 현행화 되지 않아 현재 시스템과 다른 점도 있을 수 있다. (예를 들어 외환은행이 하나은행이랑 통합돼서 카드가 통합된 것 같은 상식 비슷한 것들도 포함될 수 있다)
여하튼 다양하게 발견하는 것들을 정리해두면 누구보다도 완벽하게 서비스를 분석할 수 있는 기반이 된다.
STEP 5. 선배들에게 물어보자.
이제 질문 사항들이 나왔으면 최종 보스인 선배들에게 물어볼 차례다. 완벽한 질문을 위해 이만큼을 준비하고 돌아온 것이라고 생각하면 된다.
선배에게 질문하는 것은 1에서 10까지 공부하면서 자기가 지금까지 알아낸 것에서 빠진 것이 없는지 왜 빠진 건지 물어보는 것이 되어야 한다. 덮어놓고 서비스를 1부터 가르쳐달라고 하면 웃으면서 다음만 기약하게 된다. 아무리 해주고 싶어도 너무 방대해서 해줄 수가 없는 경우가 더 많으니까.
우리는 2종류의 선배에게 질문할 수 있다. 나보다 잘 아는 기획자 선배와, 소스까지 뒤져서라도 정확히 파악해줄 개발자 선배다. 정책을 그렇게 정한 이유를 알고 싶으면 기획자 선배에게 묻고 정확하게 어떻게 굴러가는지 로직이 파악하고 싶다면 개발자 선배에게 물어보자.
예쁜 병아리 눈망울로 물어보자물론 질문에서 가장 중요한 건 예의 바르게 자신의 추측과 현재의 내용이 맞는지를 묻는 것이다. 보따리 내놓아라 하는 식으로 덮어놓고 묻지 말자.
방법적인 면에서도 메일로 질문 뭉탱이 보내기보다는 처음에는 메신저로 자기소개와 이유, 시간 되는지 묻고 병아리 같은 눈망울로 음료수라도 하나 사다 드리면서 물어보는 게 최고다. 첨에 잘 물어봐놓고 면을 터놓으면 묻는 의도를 알기 때문에 그다음부터는 전화로 메신저로 이메일로 추가 질문도 가능하다. 열심히 배워서 기획해보겠다는 기획자를 싫어할 사람은 별로 없다.
혹시 이런 과정을 기대하는 게 너무 꼰대 같은 요구라고 생각이 든다면?
하지만 난 오늘도 담당 기획자에게 정책을 묻고 개발자에게 질문지를 들고 가서 로직에 대해 물었다. 이건 연차와 관계없는 업무에 대한 열의이고 더 좋은 기획을 위한 노력일 뿐이다.
요즘 IT 서비스는 미래 형태가 불확실하기에 불확실성에 유연해야 한다고 말한다. 하지만 불확실한 상황에 대처하려면 현재를 제대로 알아야 변수에 대한 대처도 된다. 그래서 신입도 시니어도 계속해서 자기 서비스의 현행을 파악해야 하고 가능하면 영향 범위를 많이 생각해봐야 한다.
그런 상황에서 가장 필요한 능력은 자가 습득 능력이다. 신입이라면 하루아침에 전체를 파악하려 하지 말고 천천히 전체를 파악해나가고 선배라도 계속 서비스 현행을 따라잡기 위한 노력을 해야 한다고 생각한다.
너무 정석 같은 방법들이라 다른 사람에게도 딱히 도움이 될지 모르겠지만 환기 차원에서는 나에게 더 도움이 되는 글인 것 같다. 여하튼 이렇게 지식이 쌓이면 서비스에 대한 애정도 더 높아지는 기분이 드는데, 이 감정 꼭 다들 느껴보셨으면 좋겠다.
