뭉게기의 미학 - 완벽한 계획은 존재하지 않는다

뭉게기?

완벽주의자 성향이 강한 극 J인 내가 처음 기획을 할 때 가장 혼란스러웠던 부분이었다.
어떤 아이템을 만들 때 1부터 100까지, 모든 변인들을 고려해서 완벽한 기획을 제안할 수 있다면 과연 그 프로젝트는 무조건 성공할까? 아니라면, 프로젝트의 빠른 진행을 위해 어디까지는 '뭉게'야 하는데, 과연 그 지점이 어디인가?
이러한 고민들이 항상 있었는데, 모든 스타트업 빌더들이 하지 말라는 짓을 알고도 하게 되는 시점이 있었다.

완벽한 계획은 사실 완벽하지 않다.

물리 공부를 할 때 얕게나마 주워들었던 원리 중 '불확정성의 원리' 라는 것이 있다. 어떤 입자에 대해 그 입자의 운동량과 위치 두 가지를 일정 정확도 이상으로 동시에 측정할 수 없다는 원리인데, 기획 또한 이 원리를 비슷하게 따른다고 느꼈다. 운동량을 기획의 속도 (얼마나 빨리 아이템을 던지는가?), 위치를 기획의 완성도 (얼마나 성숙한, 잘 만들어진 아이템인가?) 라고 보았을 때, 양쪽을 동시에 챙기기는 불가능하다는 말이다. 완벽한 기획을 위해 시간을 더더더 할애할수록, 시장은 변화하고, 경쟁자는 늘어나며, 아이템의 신선도는 떨어진다.

그러면 어디까지 계획하고 팀에게 던져야 하는데?

모르겠다. 정말로.

어떤 기획들은 정말 짧게 고민하고 아무런 디테일 없이 던져도 되는 반면, 어떠한 기획들은 개발 이전에 법률 검토, 재정 검토 등까지 필요한, 프로덕트 내부에서 해결되지 않는 영역까지 검토해야 되는 경우도 있었다.

오히려 이 두 케이스면 고민이 덜한데, 공수는 크지 않은 반면 중요한 수익 구조 혹은 제품의 핵심 가치와 엮여 있는 경우 검토에 더 많은 스트레스를 받았다.

선긋기 - 최소치, baseline이 어디인가?

그렇다고 에라 모르겠다 식으로 감에만 의존할 것인가? 물론 감정이나 직감에 호소하는것도 때로는 기획자로서 괜찮은 방법이지만, 이게 먹히려면 기존에 쌓아둔 신뢰도가 충분해야 한다. 새로운 환경에서 일하는 상황에서는 팀원들을 설득할 최소한의 논리 구조가 필요하다.

해당 영상의 핵심 키워드를 나만의 단어로 정리해 보았다. 영상의 주제는 어떻게 스타트업 아이디어를 가져올 것인지였지만, 내가 못했던 것들을 쏙쏙 집어서 찌르는 느낌이라 보면서 마음 한 구석이 매우 아팠다.

1. 넌 전혀 똑똑하지 않아

   인간은 상상의 동물이다. MBTI가 S이건 N이건 새로운 것을 상상하고, 어딘가에 불편함과 욕구를 느끼면 이에 대한 해결책을 떠올려 볼 수 있다. 그렇기에 '기획자' 라는 포지션이 누구에게나 열려 있는 포지션이라고 생각한다. 내가 아무리 좋은 아이디어를 가지고 와도, 이는 이미 나온적 있는 (tarpit) 아이디어이거나, 그냥 남들도 다 생각해볼만한 그저 그런 아이템일 확률이 높다.
   

2. 그래서 남들은 뭐하는데? 사람들은 뭐래?

   그럼 나는 똑똑하지도, 창의적이지도 않은데 어떡하지? 대체 뭘로 팀을 설득하고, 내 아이템이 돋보이게 만들 수 있을까? 아이템이 외부에 공개되기 전과 후로 나누어서 생각해보면, 방법은 다르더라고 결국 '다수의 공감' 이 핵심이라고 생각한다.

   빌딩 단계에서는 철저한 시장 / 유저풀 / 기존 유사 산업 조사, 그리고 우리 팀에 대한 상태 파악.
   출시 이후에는 유저 데이터 분석이나 실제 유저들을 대상으로 한 FGI등을 통해 결국 내가 아닌 많은 수의 유저들, 혹은 많은 수의 매출이 대신 말해주어야 팀을 설득할 수 있다.

데이터 분석가로 커리어를 시작해서인지 모르겠지만, 결국 개개인의 경험, 감정, 취향이 아닌 다수의 공감을 얻을 수 있는 가장 좋은 방법은 '숫자' 라고 생각한다. 이 숫자와 데이터를 baseline으로 논리 구조를 만들고 의사소통을 했을 때, 가장 적은 노력 (및 감정소모...) 으로 프로젝트를 진행할 수 있었던 것 같다.

opinion

SISP - Solution In Search of a Problem

가장 좋아하는 말이고, 이전에 팀원들과 프로젝트를 시작할 때 자주 의견충돌이 있었던 부분이다.
대부분의 공모전들이 'AI 기술을 활용한' or 'AWS 서비스를 기반으로 한' 이러한 특정 기술을 기반으로 한 프로젝트를 요구하는데, 그러다 보니 일단 문제에 대한 시각이 좁아진 상태로 프로젝트가 시작될 수 밖에 없었다. 내가 실생활에서 겪었던 문제는 이렇고, 지금 현재 시장은 이러한 변화를 겪고 있는데, 공모전이 요구하는 기술 스택이 정해져 있으니 문제 -> 기술 검토 가 아닌 기술 검토 -> 그 기술로 뭐하지? 라는 대참사가 자주 일어났었다. '어떠한 기술로 구현할지보다, 어떤 아이템과 가치를 전달할지가 최우선시 되어야 한다' 라는 명제는 앞으로도 굽힐 일이 없을 것 같다. (다만 이는 현재 우리 팀의 기술수준을 무시하자는 이야기는 또 아니다.)

counteropinion

현재 팀에 맞는 의견을 내라 / 우리 팀이 잘하는 걸 해라

순서 및 환경의 문제라고 생각한다. 최적해는 당연히 아이디어에 공감하고, 이를 만들어갈 능력도 되는 팀원을 구하는 것이겠지만, 대부분 환경이 이미 있는 구성원들로 뭔가를 만들어내야 하니... 이러한 이상적인 팀 빌딩 과정은 논외로 치고도 위 영상에서의 해당 내용을 counteropinion에 적은 이유는 다음과 같다.
팀 구성원들의 기술 수준을 파악하고, 의견을 듣고, 자주 대화하는 것이 동기부여 측면이나 길게 봤을 때 '평화롭게' 일이 진행되는데에는 도움이 될 수는 있지만, 결국 그 방향이 맞는지랑은 별개라고 생각한다. 또한 이는 아이디어를 내고, 이에 대한 플래닝을 수행해야 할 기획자가 존재하는 이유와도 엮여 있다.

개발자와 디자이너는 바쁘다. 무한한 수와 능력을 가진 개발자 풀이 있다면야 지구도 정복할 수 있겠지만, 실상은 한정된 리소스로 최소한 그에 준하는, 혹은 크런치를 해서라도 그 이상의 프로덕트를 만들어야 한다. 이러한 상황에서 '혹시 이 디테일은 어떻게 생각하세요?', '이런 아이템은 어떨까요?' 와 같은 질문을 쏟아내는 것은 일이 진행되는 데 도움이 되지 않는다. 적당한 방향성은 팀과 조율하더라도, 팀이 원하는, 혹은 팀이 이미 잘해왔던 convention에 맞추기 위해 기획을 맞추는 것은 좋은 기획에서 멀어지는 방향이라고 생각한다. 현재 기술 수준에 부적합하거나 팀원들의 큰 반대가 있다면 차라리 기획을 폐기하지, 이도저도 아닌 중립을 찾는 것은 모두의 시간을 낭비하는 결과로 이어질 가능성이 높다고 본다.
다시 말하자면 개발자와 디자이너는 바쁘고, 이들과 공유할 기획안을 '최소 수준까지' '뭉게서' 가져오는 것이 기획자의 최소한의 존재 의의라고 생각한다.

그래서 '뭉게기' 가 뭔데?

이거 하나 말하고 싶어서 멀리 멀리 돌아왔는데, 한 문장으로 정의하자면 '최소한의 최대치' 라고 생각한다.

팀을 설득할 수 있을 수준의, 진부하지 않고 현재 시장의 트렌드에 맞는, 충분한 수준의 리서치와 검토를 거친, 남들보다 빠르게 제시할 수 있는. 각각의 영역의 최소치를 잘 설정하고, 이 최소치와 관련 없는 사항들을 과감히 '뭉게서' 없애버리고, 계획의 디테일에 대한 수정가능성은 열어둔 채 최대한의 고민을 통해 제시해야 하는게 스타트업에서의 아이디어라고 생각한다. 아이디어를 한없이 여는것은 누구나 할 수 있지만, 핵심 가치가 아닌 부분들을 뭉게서 속도를 올리고, 피로도를 낮추는 (혹은 실제로 낮아지지 않더라도 할 일들이 가볍게 보일 수 있도록 하는) 과정이 계획에 있어서의 묘수라고 생각한다.