기획은 '문제' 그리고 '해결'이다

사수 없는 신입 기획자의 기획 본질 찾기

기획은 2형식이다. 출처 :예스 24

내 직무명은 ‘Service Design’으로, 팀에서 서비스 기획과 운영 전반을 담당하고 있다. 아직 입사한 지 만 1년도 되지 않은 신입이다. 그리고 나는 사수가 없다. 첫 회사이기에 실무 경험도 거의 없다. 부족한 점이 많은 내게 이러한 현실은 하루에도 수없이 많은 고민거리를 안겨준다.

불행 중 다행인지, 나는 내가 컨트롤할 수 없는 상황이라고 판단되면 크게 몰입하지 않는 편이다. 즉 상황을 탓하지 않는다. 사수가 있으면 좋았겠지만, 나에게는 그런 희망고문(?)할 시간이 없다. 주어진 상황을 받아들이고, 어떻게 하면 좋은 제품을 만들 수 있을지를 한번 더 고민하는 것이 내 생존에 득이 되는 길이라고 생각한다.

사수가 없이 실무적인 배움을 얻을 수 있는 방법이 무엇이 있을까 다양한 루트를 고민하던 중 “데이먼의 PM 일지”라는 블로그를 구독하기 시작했다. 오늘의 한 문장이라는 컨셉으로 매일 아침 PM 업무에 관한 다양한 소식을 전해준다. 마치 내 온라인 사수와 같은 느낌을 받는다.

‘띵’ 하는 휴대폰 알림 소리와 함께 “기획자를 두 부류로 나눈다면? ”이라는 제목의 메일이 도착했다. 내용을 읽지 않았는데, 자아성찰부터 한다. “보나 마나 뛰어난 기획자 vs 부족한 기획자 특징을 정리했겠지?, 내 이야기가 얼마나 들어 있을까?” 하는 마음으로 클릭했다. 과연 내용은 어땠을까?

만약 세상의 모든 기획자를 두 부류로 나눈다면 어떻게 나눌 수 있을까요?
‘기획 잘하는 사람’과 ‘기획 못하는 사람’으로?
제 생각에는, ‘기획 잘하는 사람’과 ‘보통으로 하는 사람’으로 나뉠 듯합니다.

정답. 역시 내 이야기가 적혀 있었다. 나는 ‘보통’ 수준의 기획을 하는 사람이다. 고만고만한 생각, 엇비슷한 논리, 적당한 결과물로 기본은 하는 기획. 영어로 치면 그야말로 ‘so-so’ 기획. 우리 팀에 내가 아닌 다른 서비스 기획자가 와도 비슷하게 할 수 있는, 즉 대체 가능한 수준인 것이다.

그래도 다행인 건, 이렇게 내 ‘주제’와 ‘분수’를 파악하는 일은 잘한다는 점이다. 고수가 되는 첫걸음이라니, 나는 벌써 시작을 뗀 셈인가? 시작이 반이라면 이미 절반은 간 걸까? 메일에 담긴 요약만 봐도 부족함을 채울 좋은 솔루션이 있을 것 같아, 바로 퇴근길에 알라딘에 들러 책을 구입했다.

책의 내용은 간결했지만, 저자가 전하고자 하는 기획의 본질은 깊었다. 본질은 ‘단순함(simplicity)’이었다. 단순함(simplicity)은 전체에서 본질을 꿰뚫는 지혜로움이며, 복잡함(complexity)은 표면과 현상에서 겉도는 어리석음이라고 했다. 즉, 기획 고수는 단순 명료하면서 완성도 높은 기획안을 낳는 지혜를 발휘하는 사람이라는 것이다.

이를 위해 저자는 ‘2형식(P코드·S코드)’ 개념을 제시했다.

기획에서 사고·문제·해결의 기술을 모두 ‘~은/는 ~다’라는 2형식으로 간결하게 표현할 수 있어야 한다고 말한다. 처음엔 생각의 흐름을 단 두 문장으로 압축하고, 그것을 절대적 정답처럼 보이게 하는 게 옳은 걸까 의구심이 들 수도 있다. 하지만 결국 ‘문제’와 ‘해결’은 기획의 본질이자 원형이므로, 불필요한 요소를 덜어내서라도 명확히 규정해야 한다는 것이다.

고수는 S코드보다는 P코드에 훨씬 더 많은 시간과 노력과 열정을 투입한다고 한다.(P: 75% S: 25%) 모든 해결책의 실마리는 이미 문제 안에 존재하기 때문에 ‘문제 규정’만 제대로 잘되면 ‘해결책’은 ‘상식적’으로 만들어진다는 것이다. 그렇다면, P코드를 잘 찾기 위한 방법은 무엇일까. 바로 왜(why)? 한 글자면 충분하다.

이를 증명하기 위해 몇 가지 예시를 든다. ‘토끼와 거북이’ 우화에서, 토끼가 경주에서 진 진짜 이유는 무엇일까? 토끼가 낮잠을 잤기 때문일까? 아니다. “문제는 토끼의 자만심이다.” 이 정도 질문에는 나도 금세 답할 수 있었다. 이처럼 우리 모두에게는 문제의 본질을 직관적으로 파악할 수 있는 ‘유전자’가 어느 정도 존재한다고 한다. 다만 실무에서는 훨씬 더 입체적이고 복잡한 문제들이 대부분이라, 토끼 이야기처럼 빠르게 정답을 찾아내긴 어렵다. 그래도 문제의 본질로 가는 접근법 자체는 같다. 바로 “왜?”를 계속해서 물어보는 것이다.

이제 “왜?”라는 질문을 던져야 한다는 사실을 배웠다. 두 번째 예시를 보자. 낡고 느린 엘리베이터를 기다리던 주민들의 불평이 끊임없이 터져 나왔다. 그렇다면 진정한 문제는 무엇일까? 단순히 “엘리베이터 속도가 너무 느리다”가 문제인 걸까? 과연 그럴까?

“음 속도가 문제라기보다는 엘리베이터를 지루하게 기다리고 있는 시간이 나를 위해 사용되지 못하고 낭비되고 있다는 생각이 문제 아닐까요?” - 플래닝 코드를 아는 고수

오... 나는 생각지 못했다. 이 예시에서 중요한 점은 주민들의 불평(현상적 문제)을 속도 개선(해결)으로 직접 해결하기보다, 그 불평이 발생하는 근본적 원인(왜 불평할까?)에 초점을 맞춘 것이다. 결국 주민들이 엘리베이터를 기다리는 시간을 ‘자기에게 유용한 시간’으로 바꿔줄 무언가(거울 부착)를 마련하는 방식으로 문제를 해결한 셈이다. 이 예시는 엘리베이터 전문 기업인 OTIS의 실제 사례라고 한다. 이후 주민들은 불편함을 점차 잊고, 엘리베이터를 기다리는 시간마저 자기 자신을 위해 활용할 수 있게 되었다고 한다. 문제는 이렇게 간단히 해결됐다. 그것도 매우 비용 효율적인 방법으로 말이다.

나는 여기서 생각했다. ‘내가 조금만 더 “왜?”라는 질문을 두 번, 세 번 반복했다면 문제 규정을 제대로 할 수 있었을까? 단지 생각이 부족했던 걸까, 아니면 아무리 시간을 들여도 떠오르지 않았을까?’

그런데 답은 뒷장에 바로 나와 있었다. ‘왜’라는 질문을 한두 번 던져서는 쉽게 찾아지지 않을 수도 있다는 것이다. 결국 P코드 찾기는 누가 더 끈질기게 “왜(why)?”를 되풀이하며 깊이 파고드느냐의 게임이라고 한다. 말 그대로 ‘생각의 체력’이 요구되는 고도의 멘탈 게임인 셈이다.

괜찮다. 나는 아직 관점의 전환이 조금 부족할 뿐이다. 이제 평범한 현상도 ‘문제 상황’으로 바라보고, 문제점을 구조화해 궁극적으로 2형식으로 규정해야 한다는 마인드셋을 갖출 수 있게 되었다.

앞서 P코드가 7할 이상이라고 말한 것처럼, S(Solution) 코드에 대한 내용은 훨씬 짧고 간결하다. 그만큼 핵심은 다시 P에 있다. 솔루션은 막연한 ‘새로운 발상’이 아니라, 명확히 규정된 문제를 해결하는 구체적인 방안을 찾는 것이다. 즉, ‘문제 규정’이 제대로 이루어지면 ‘해결책’은 상식적으로, 거의 자연스럽게 도출된다고 한다. 만약 좋은 아이디어가 떠오르지 않는다면, 근본적으로 문제 정의가 적절했는지, 곧 P코드를 다시 점검해봐야 한다고 한다. 책의 마무리 또한 간결했다. 이제 P와 S를 살펴보았으니, 두 개를 이어주면 끝이라고. ‘왜 이것이 진짜 문제지?’를 그려주기 → ‘왜 이것이 최적의 해결책이지?’를 그려주기.

마치며,

기획을 처음 접하고 IA, 유저 스토리, 와이어프레임 등 각종 프로세스에만 치중해 왔던 내게, 이 책은 기획의 본질을 다시금 일깨워주는 좋은 계기가 되었다. 또한 하루하루 쌓여가는 고민, “기획이 과연 나에게 맞을까?” 하는 방향성, 그리고 직무적 성장에 대한 고민 등으로 복잡해진 생각을 조금은 단순화할 수 있었다.

하지만 실제 현업에서는 일정에 쫓기거나 윗선의 요구에 밀려, 문제의 본질보다 단순히 ‘오퍼레이터’에 가까운 기획을 해야 할 때가 적지 않다. 이미 “이것이 문제다, 해결해야 한다”라고 지정해 놓은 상태로 시작할 때도 있다. 그럴 때는 기획자로서 문제의 본질을 직접 정의하기보다는, 마치 ‘오퍼레이터’처럼 지시받은 요구사항을 구현해야 한다. 앞으로는 이런 상황 속에서도 내 나름의 가치와 본질을 살려낼 방법을 고민하고 싶다. 제한된 문제나 기능이라 할지라도 “어떻게 하면 더 많은 사용자에게 더 가치 있게 전달할 수 있을까? 어떻게 하면 특정 사용자가 아니라, 우리 서비스 전체에 이로운 가치를 창출할 수 있을까?”를 스스로에게 질문하며 기획을 해나가야겠다. 비록 문제 규정의 시작점이 내가 아니더라도, 그 과정에서 새로운 가능성을 찾아내고 결국 내가 창출할 수 있는 ‘진짜 가치’를 놓지 않기 위해 부단히 노력해야겠다.