이 책은 나름의 자부심을 가지고 일하던 나의 성장에 대한 이야기다. 우물 안에서 잘난 척하고 살던 내가 우물 밖으로 나가 새로운 삶에 적응하고 나만의 기준을 만들기까지, 하루하루 애쓰고 노력했던 날들의 기록이다. 온라인 서비스 기획자라는 특정 직무에서나 일어난 큰 변화에 대한 글이라고 생각할 수 있겠지만, 사실 이러한 변화와 그로 인한 고민은 누구에게나, 언제든 찾아올 수 있다. 특히 10년쯤 일을 하게 되면 반드시 우물 안을 벗어나야 할 때가 온다. 그게 내 직업처럼 시대적인 변화를 맞이해서든, 아니면 회사나 개인의 발전과 관련해서든, 하던 대로만 해서는 성과가 나지 않는 순간이 반드시 온다.
--- 「프롤로그」 중에서

한번은 기존 기업에서 엄청난 직무 성과를 많이 올려 왔다고 자랑하는 기획자를 만난 적이 있다. 사내의 굵직한 서비스를 모두 본인이 만들었다고 했다. 아무리 생각해 봐도 그 기간 내에 혼자서 다 기획하고 프로젝트 실무까지 진행할 수는 없는 범위였다. 자세히 물어보니 외주에 발주하고 관리하는 역할만 했던 사람이었다. 물론 회사마다 업무의 범주는 다를 수 있다. 그 회사에서 필요한 기획자의 역량은 딱 거기까지였을 것이다. 하지만 그의 경력은 실무로서 직접 프로젝트를 수행할 수 있는 사람이 필요한 곳에서는 의미 없는 경력이 되고 만다. 자신이 일했던 회사의 기준이 아니라, 내가 하고 있는 이 직무의 커리어패스에서 필요한 수준을 올바로 정의하고 있었다면 어땠을까? 관계적 정의가 아닌, 스스로 객관적인 기준을 세워 자신의 현 상태에서 한계와 차이를 아는 것이 중요하다.
--- 「누가 우물 안 일잘러를 만드나」 중에서

내가 목표한 키워드는 단 하나. ‘크로스펑셔널팀’. 기존의 기업들과 다르게 일하는 것으로 가장 유명한 회사 몇 군데를 찾아서 이 질문을 해 보기로 결심했다. 한 회사에서는 사내의 탤런트 애퀴지션(Talent acquisition. 사내 헤드헌트 부서의 일종)의 리크루터를 만났고, 또 다른 회사에서는 나와 같은 직무의 사람을 찾았다. 그리고 그들에게 이직에 대해 묻는 대신, 가벼운 커피챗(coffee chat)을 요청했다.
커피챗이란 IT 업계에서 많이 사용하는 용어로 커피를 마시면서 수다를 떠는 가벼운 만남을 이야기한다. 커피챗이 사전 면접처럼 작용한다고 부담감을 느끼는 사람도 많지만, 사실은 그저 서로 ‘간을 보는 자리’이기 때문에 커피챗 후에 꼭 입사를 지원해야 할 필요는 없다. 내 경우에는 당장 지원해 봤자 떨어질 것이 뻔했기에, 정말 가벼운 마음으로 대화해 보면서 무엇을 준비할지 큰 그림을 그릴 수 있었다. 먼저 유명 이커머스의 리크루터 두 명을 만났는데, 마침 한 블록 옆 건물이었기에 점심시간을 쪼개서 인근 커피숍에서 만남을 가졌다.

“PO(프로덕트 오너)가 크로스펑셔널팀으로 일하나요? 조직 구성은 어떻게 되나요?”
“그 회사에 계신 분이 쓰신 글에서 본 일하는 방식이 사내에서 표준적으로 일하는 방식인가요?”
“PO는 서비스 기획자보다 의사 결정 권한이 많다는데, 의사 결정을 하고 나서 책임을 지는 방식은 어떻게 진행되나요?”
“저처럼 서비스 기획자로 대기업에서 일하다가 넘어온 사람들 중에 적응에 실패한 사람이 있나요? 실패한 사람은 어떤 점을 힘들어했나요?”

짧은 30분 동안의 대화에서 막연하게 품고 있던 질문들을 했다. 크로스펑셔널팀이 가져야 하는 생각이나, 그런 팀에서 일하는 기획자가 갖춰야 할 차별성이 무엇인지 알 수 있을 만한 질문들이었다. 일하는 방식이 달라진다는 것은 사실 프로세스 변경만을 의미하지 않는다. 일하는 방식이 다를 때는 분명 그것을 뒷받침하는 이론이나 배경이 있을 테니 그것을 알고 싶었다.
--- 「헤드헌터보다 유능한 커피 한 잔」 커피챗 중에서

상품 시스템을 새로 만들어야 한다는 미션에서 나는 내 경험을 기반으로 필요한 모든 상품 항목들을 열거했다. 그런데 팀원들과 리뷰하는 과정에서는 ‘비즈니스 임팩트’를 위해 꼭 필요한 항목을 정해서 그것만으로 오픈할 수 있어야 첫 오픈 시점을 맞출 수 있다는 데 이야기가 모아졌다. 나는 여기서 첫 번째 큰 차이를 정의할 수 있었다.

‘기능의 완결성과 기능의 효용성 중 무조건 후자를 택하는 세상에 온 거구나.’

기능의 완결성을 추구한다는 것은, 그 기능을 사용하는 모든 사용자의 이용 케이스와 발생 가능한 데이터적 케이스를 모두 고려하여 그에 맞는 정책을 빠짐없이 기획하는 것을 뜻한다. 그만큼 개발과 디자인해야 할 케이스가 많다. 여기서 한 단계 더 나아가면 내가 처음에 서비스 기획을 시작했을 때 들었던 그 단어, ‘확장 가능성’에 대한 부분까지 나아가게 된다. 기능의 확장 가능성이란 예를 들어 나중에 이 기능에서 지금은 제외되었지만 추가적인 기능을 만들 수도 있으니까 그걸 개발 설계에 녹여 달라고 하는 것에 해당한다. 이렇게 기획을 할 때는 120%를 상상하고 그중 20%는 버려질 수 있다는 것을 감안하고 기획해야 한다. 어차피 과도한 기획이라 다 수용하지 못하는 것이 당연시되는 상황이기에, 가능한 더 많은 양을 내세워서 합의 가능한 수준을 높이려고 한다. 그래야 완결성을 조금이나마 높이게 되니까. (중략)
그렇다면 기능의 효용성을 중요시하며 일하는 세상은 어떤 것일까. 이커머스에서 만들 수 있는 10가지의 상품 종류가 있다면, 당장 오픈 시키려고 하는 단 한 가지의 상품 종류에 최적화해서 확장성을 고려하지 않고 프로덕트를 만들어 내는 것이다. 그리고 그 최적화의 과정에서 ‘확장 가능성’에 대한 부분도 배제한다. 다만 나중에 아홉 가지 종류가 들어올 때를 대비해서, 미리 만들기보다는 한 가지씩 항목이 추가될 때 기존시스템을 다시 부수고 새로 필요한 만큼 확장해서 만들어 낸다는 약속이 존재한다.