서비스 기획의 모든 것

'이걸 벌써 다 정리하셨어요?'

 기능명세서 초안을 처음 공유한 날, 고객사 PM님이 화면을 넘기다 말고 그렇게 말씀하셨다. 칭찬처럼 들리지만 표정은 그렇지 않다. 반가움보다는 의심에 가까운 얼굴이다. '우리 일을 2주 만에 다 파악했다고?' 하는 눈빛이랄까? 이런 사건들이 있을 때마다, 나는 '빠르다'는 표현을 조금 다르게 생각하게 되는 것 같다.

기획이 빠르게 움직여야 하는 이유

 SI 프로젝트에서 가장 중요한 건 일정이다. 약속한 날에 약속한 산출물을 내야 한다. 그리고 기획자는 일의 순서상 맨 앞에 서 있다. 기획자의 뒤에는 디자이너가 있고, 그 뒤에는 개발자가 있다. 릴레이 경주로 치면 첫 번째 주자인 셈이다. 내가 바통을 늦게 넘기면 뒤 주자들은 남은 거리를 더 빨리 뛰어야 하고, 그만큼 부담이다.

 나는 프로젝트를 시작하기 전에, 최종 단계에서 나와야 하는 산출물부터 정리하는 편이다. 어떤 산출물이 언제 나와야 하는지 윤곽을 잡고, 각 산출물이 서로 어떻게 물려 있는지를 알고 정리해야 한다. 예를 들자면 정보구조도(IA)가 나와야 와이어프레임이 나오고, 와이어프레임이 나와야 화면설계서가 나오고, 화면설계서가 어느 정도 잡혀야 디자인이나 개발이 시작될 수 있다. 이 연결고리를 거꾸로 따라가다 보면 지금 당장 해야 할 일이 보인다. 그래서 나는 이 테일러링을 시작하는 동시에 머릿속으로는 기획서를 구상하기 시작한다.

 이때 이해관계자들에게 양해를 구하는 부분이 하나 있다. 기획은 나중에 고칠 수 있는 여지를 열어두고 쓴다는 것이다. 처음부터 완벽한 기획서를 쓰려고 하면 첫 바통부터 늦어진다. 대신 확정된 부분과 아직 열려 있는 부분을 구분해서, 디자이너와 개발자가 확정된 부분부터 먼저 출발할 수 있게 하는 편이다. 내 판단이 아닌 고객의 요청으로 기획이 변경되는 경우에도 함께 일하는 사람들에게 양해를 구하기 좋은 방법이다.

 여기까지만 보면 기획자는 빠를수록 좋은 사람인 것 같이 보인다. 

있는 그대로를 보기

 문제는 기획서를 쓰려면 고객의 요구사항이 분명해야 한다는 점이다. 하지만 처음부터 요구사항이 분명했던 경우는 거의 없다. 적어도 내 경험에서는 그랬다. RFP(제안요청서)가 있어도 마찬가지다. 업무 효율화, 통합 대시보드 같은 화려한 말들이 적혀 있지만, 무엇을 얼마나 효율화하고 무엇과 무엇을 통합한다는 건지는 비어 있는 경우가 많다.

 그래서 나는 고객이 자신의 요구사항을 스스로 정의할 수 있도록 돕는 것까지가 기획이라고 생각한다. 이 일은 깔끔한 산출물로 떨어지지 않는다. 계약서의 업무 범위에 한 줄로 적히지도 않는다. 하지만 이걸 건너뛰면 그 뒤의 모든 산출물이 모래 위에 지어져서 와르르 무너지기 십상이다.

 요구사항 정의서나 SOW(과업명세서), RFP(제안요청서) 같은 문서가 나오기 전이라도 나는 무조건 고객과 미팅부터 잡는다. 현재 업무가 어떻게 돌아가는지, 지금 일하면서 비효율적이거나 불편하다고 느끼는 게 무엇인지 여쭤본다. 이 질문에 바로 답이 나오는 경우는 드물다. 고객은 지금의 업무 방식에 너무 익숙하기 때문이다. 오래 살아온 집의 낡고 삐걱거리는 계단 같은 것이다. 처음 온 손님은 바로 알아차리지만, 매일 오르내리는 사람은 그 소리를 더 이상 듣지 못하는 것과 비슷하달까?

 어떤 중공업 프로젝트에서 영업 담당자분이 업무를 설명해주시던 장면이 기억난다. 매일 아침 ERP에서 내려받은 파일과 협력사가 메일로 보낸 파일, 팀 공유 엑셀을 동시에 열어서 품번을 하나하나 맞춰 붙이고 계셨다. 한 시간 가까이 걸리는 일이었다. 불편하신 점이 있는지 여쭸더니 '딱히 없어요. 원래 이렇게 하는 거라서요' 같은 뉘앙스로 답하셨다. 이 단계에서 나는 의견보다는 사실을 설명해 달라고 요청하는 편이다. 불편한 점을 말씀해달라고 하기보다, 지금 하시는 일을 있는 그대로, 가감 없이 보여달라고 부탁드린다. 이렇게 고객이 보여준 재료를 보고, 속으로 판단을 해보는 것이다.

 이 과정은 프로젝트 초반 내내 반복된다. 처음엔 실무 담당자 한두 분과 가볍게 시작했다가 점점 만나는 사람이 늘어난다. 팀장님, 옆 부서 담당자, 실제로 데이터를 입력하는 직원까지. 만날 때마다 조금 더 상세하게 설명해달라고 부탁드린다. 같은 업무도 누가 설명하느냐에 따라 전혀 다른 이야기가 나오기 때문이다. 

빠를수록 의심받을 때도 있다

 현행 업무와 개선하고 싶은 점의 윤곽이 잡히면 사전 인터뷰를 하고, 그걸 바탕으로 기획서 초안이나 기능명세서를 만든다.

 이 단계의 나는 아직 도메인을 배우는 중이다. 고객의 업무를 고객만큼 알 수는 없다. 그래서 내용보다는 기능 정의에 집중한다. 어떤 시스템이 필요한지, 그 시스템에 어떤 기능이 있어야 하는지를 설계한다. 업무의 디테일은 비워두고 뼈대를 세우는 일이다. 요즘은 이 뼈대가 정말 빨리 나온다. 인터뷰 녹취를 정리하고, 기능 목록을 뽑고, 표로 만드는 일까지 AI와 함께 하루 반나절 정도면 그럴듯한 초안이 된다. 예전 같으면 며칠, 몇주씩 걸렸을 일이다.

 그런데 문서가 빨리 나올수록 첫 반응이 탐탁치 않은 고객도 있다. 네가 뭔데 벌써 우리 일을 다 파악했다는 거지, 하는 식이다. 처음엔 조금 서운하기도 했다, 빨리 정리해드린 건데. 그런데 몇 번을 겪고 나서야 알 것 같았다. 고객이 의심한 건 내 실력이 아니라, 그 문서 안에 자기 이야기가 얼마나 들어가 있느냐인 것 같다. 겉보기에 완성된 문서일수록 '우리 얘기는 언제 들었지?' 하는 의문이 생기는 듯하다. 고급 오마카세인데 손님의 입맛은 하나도 고려되지 않은 것과 비교할 수 있을까?

돌아가는 길처럼 보이는 시간

 기능명세서 다음에 이어질 기획 산출물은 꽤 명확한 편이다. 주로 정보구조도(IA), 화면설계서 같은 것들이다. 전체 WBS(일정표)만 보면 바로 그쪽으로 넘어가는 게 맞다. 하지만 이 시점에 내가 가장 중요하다고 생각하는 건 산출물이 아니라 고객과 함께 보내는 시간이다. 당신의 이야기를 잘 듣고 있고, 제대로 이해하고 있다는 걸 보여주는 시간.

 앞서 언급한 중공업 프로젝트의 전체 프로젝트 기간은 18개월이고, 나는 고객에게 화면설계서를 전달하기까지 3개월 동안 일주일에 두세 번씩 왕복 7시간 거리의 고객사에 갔다. 특별한 회의를 한 건 아니다. 담당자분 옆에 앉아 아침 업무를 지켜보고, 모르는 용어가 나오면 그 자리에서 여쭤봤다. 용어 사전집을 요청하는 것도 방법이지만 대개는 그런 것이 존재하지 않는 경우가 많다. 기존 시스템을 운영하고 있는 담당자에게 현재 업무나 시스템을 소개해 달라고도 요청했다. 기능명세서에 적어둔 항목이 실제 업무에서 어떻게 쓰이는지 하나씩 맞춰봤다.

 어떤 담당자분께는 현행 업무를 마치 신입사원에게 인수인계하듯 설명해 달라고 요청드렸다. 그 담당자를 세 번째 뵙는 자리였다. 그 날은 담당자분이 파일을 열다 말고 먼저 말씀하셨다. '사실 이게 제일 귀찮긴 해요. 품번 하나 틀리면 오후 내내 그거 찾아야 하거든요.' 이 때 느낌이 왔다. 첫 미팅에서는 불편한 것이 딱히 없다고 하셨던 바로 그 일이었다. 이 날을 계기로 기능명세서의 우선순위를 일부 조정했다.

 이렇게 고객과 신뢰를 쌓고, 기능명세서와 정보구조도, 와이어프레임이 담긴 화면설계서까지 초안을 전달하는 데에 3개월의 시간이 걸렸다. 사실 초안은 4주만에 작성했지만, 기획서를 묵히면서 고객의 말과 행동을 이해하며 문서를 수정하는 데에 배의 시간이 걸린 것이다. 그리고 첫 리뷰 회의에서 고객의 표정도 달라져 있었다. 자기 팀의 이야기가 들어가 있었으니까. 

천천히 가는 구간

솔직히 이 시간은 전체 일정을 생각하면 손해처럼 보인다. 눈에 보이는 산출물이 나오지 않는 기간이고, 뒤에서 기다리는 디자이너와 개발자를 생각하면 마음이 급해진다. 때로는 재촉을 받기도 한다.

그래도 이 시간을 지키게 된 것은 반대의 경험이 있어서이다. 기획자로 일한 지 얼마 안 됐을 무렵, 일정을 맞추겠다는 생각 하나로 쉬지 않고 밀어붙인 적이 있다. 고객이나 사업부 리뷰는 매번 순조로웠다. 별다른 의견이 없으셨다. 나는 그게 잘되고 있다는 신호라고 생각했다.

그리고 오픈이 얼마 남지 않은 시점에 현업 부서장님이 처음으로 시스템을 보셨다. 그리고는 '이건 저희가 말한 방식이 아닌데요'라고 하셨다. 결국 핵심 화면 상당수를 다시 설계했고, 디자인부터 RDB 테이블을 포함한 여러 구조를 통째로 갈아엎어야 했다. 지금 생각해보면 그때 리뷰에 의견이 없었던 건 동의해서가 아니라, 자기 이야기라고 느끼지 못해서였던 것 같다.

규모가 큰 프로젝트일수록 이 차이는 커진다. 고객이 기획 과정에 자신의 의견이 들어갔다고 느낄 때, 나중에 큰 규모의 수정이 생길 확률이 확실히 줄어드는 듯하다. 같은 문서라도 받은 문서와 같이 만든 문서를 대하는 태도는 다르다. 대부분의 사람은 자기가 만든 것에 애정을 가져서, 쉽게 뒤엎지 않는다. (기획자라면 자기가 쓴 기획서를 잘 포기할 줄도 알아야 한다는 이야기도 하고 싶은데, 너무 길어질 것 같아서 다른 글로 다루겠다)

그래서 돌아가는 것처럼 보이지만 전체 일정으로 보면 이런 방법이 가장 빠른 길이라고 아직까지는 생각한다.

무엇을 빠르게 하고, 무엇을 천천히 할 것인지

나는 여전히 빠른 기획자가 되려고 애쓰는 것 같다. 그게 정답이 아니라는 것을 알면서도.. 여전히 일정을 지키는 것이 가장 중요하고, 뒤에 있는 사람들의 시간을 벌어주는 것도 기획자의 몫이라고 생각하기에.

다만 요즘은 빠르게 할 일과 천천히 할 일을 나눠서 생각하게 된 것 같다. 산출물의 전체 여정을 그리는 일, 기능 목록을 정리하는 일, 문서의 형식을 갖추는 일은 빠를수록 좋다. AI가 이 부분을 정말 많이 당겨줬다.

반면 고객이 자신의 요구를 알아차리는 데 걸리는 시간, 스스로의 생각을 정리하고 속마음을 꺼내기까지의 시간은 도구가 아무리 좋아져도 줄어들지 않는 듯하다. 그건 문서의 속도가 아니라 사람의 속도이기 때문이다.

AI 덕분에 문서를 만드는 시간이 줄었다면, 그렇게 남은 시간을 어디에 쓰고 있는지 가끔 스스로에게 묻는 것이 필요하다고 느낀다. 다음 문서를 더 빨리 만드는 데 쓰고 있는지? 고객의 옆자리에 한 번 더 앉는 데 쓰고 있는지? 어느 쪽이 맞는지는 프로젝트마다 다를 것이다. 나는 빨라진 만큼 생긴 여유를, 빨라질 수 없는 일에 쓰고 싶다.