2주 전에 최근에 런칭한 서비스에 대한 향후 방향성 및 기능보강을 위한 워크샵이 열렸습니다. 제가 직접적으로 참여해서 만든 서비스는 아니지만, 사내에서 이래저래 쑤시고 다녔더니 '그러면 니가 직접 해봐'라는 식의 오더가 내려온 듯합니다. 그래서 20명정도의 서비스 담당자와 마케팅, 개발, UX 담당자들이 모여서 1박2일 동안 열띤 토론을 버렸습니다. 먼저 참가자 별로 해당 서비스에 대한 3분 스피치를 하고, 비슷한 내용의 사람들끼리 3개조로 나눠서 더 구체적인 안을 내도록 했습니다. 그런 후에 취합된 내용을 모두에게 발표를 하고, 또 각 서비스 개념/방향에 대해서 칭찬/비판의 시간을 가졌습니다. UX팀에서 워크샵을 주관을 했습니다.
개별 조모임을 시작할 때, 사내외에서 IT기술트렌드에 말빨이 있으신 유명 블로거님이 'UX팀은 프로세스를 너무 좋아해'라고 말씀하셨습니다. 저도 이 말이 바로 납득이 되었습니다. 이번 워크샵 이전에도 다른 서비스를 기획, 개발할 때 언제부턴가 UX팀에서 처음부터 합류를 했습니다. 그들은 프로젝트가 시작하면서부터 사용자 설문 및 FGI 등을 진행하고, 담당자들이 모인 자리에서 그런 조사결과를 미리 발표를 해주는 경우가 많았고, 또 컨셉을 잡아가면서 어느 정도 체계화된 프로세스/단계를 강조하는 모습을 자주 목격했습니다. 어떤 분야가 오랜 시간의 경험을 축적하다보면 특정 방법론은 효과가 있고 또 다른 방법론은 효과가 미약하다는 등의 지식이 누적되고, 그렇게 누적된 지식은 프로세스 또는 프레임워크라는 정형화된 틀로 만들어집니다. 그렇게 한번 만들어지면, 이후에는 문제/상화과 무관하게 그 틀에 맞춰서 일을 진행하는 것이 일반화되어있습니다. 어쩌면 오늘날 UX 전문가라는 분들은 그런 틀을 얼마나 많이/다양하게 가지고 있고, 적용할 수 있는가에 의해서 결정되나 봅니다.
아무런 프로세스도 없이 주먹구구식으로 프로젝트를 진행하면 많은 문제들이 발생합니다. 계획도 없이 인력부터 충원해놓고는 결국 할 일이 없어서 그런 비싼 인력을 놀게 만드는 경우도 종종 보게 되고, 비슷한 종류의 일을 여러 그룹에 동시에 분배해서 같은 일을 중복으로 처리하는 경우도 발생합니다. 간혹 중요한 체크사항을 빠트리는 경우도 발생하고, 또 충분한 인력 등의 지원을 못해주는 경우도 발생합니다. 그렇기 때문에 이런 저런 상황에 맞는 다양한 툴킷을 마련해두고, 적제적소에 투입하면 일의 효율이 높아지는 것은 당연합니다. 그런데 정형화된 프로세스의 문제는 프로세스가 견고해지면 질수록 그것에 변형을 가하기가 어려워집니다. 감히 대가가 만들어놓은 프로세스가 잘못되었다고 반박하기가 어려울 때도 많고, 때로는 특정 프로세스에 너무 익숙해져서 더 큰 그림을 못보고 지나치는 경우도 발생합니다. 좋은 것이 항상 좋은 것은 아닌데, 우리의 생각이 그렇게 유연해지기가 어렵습니다.
기획이 너무 체계화되면서부터 오히려 재미있는 기획이 사라지는 것같습니다. 아무런 프로세스나 지식이 없는 경우에는 다양한 생각을 막 쏟아내고 그 중에서 재미있어 보이는 것이나 아니면 빨리 구현해볼 수 있는 것을 찾아서 주먹구구식으로 막 개발하던 때가 있었습니다. 대부분의 스타트업들이 이런 식으로 처음에는 일을 진행할 것입니다. 그렇게 자유롭게 생각하고 막 만들어볼 때는 재미있는 것들이 많이 나오는데, 막상 그것을 제품/서비스화를 하기 위해서 깊이 고민하면서부터 서비스가 재미가 없어집니다. ROI를 따지기 시작하고, 사용성을 따지기 시작하면서부터 깊은 늪에 빠지는 것같습니다. 진짜 재미있고 필요한 기능을 추가하기 보다는, 그저 사용자들을 예측해서 필요할 것같은 기능들을 마구집어넣기 시작하면서부터 서비스는 초기 기획의도에서 벗어나기 시작합니다. 그렇게 서비스는 복잡해지고 사용하기 어려워지고 그래서 또 사용자들로부터 외면을 받고, 결국 서비스는 쥐도 새도 모르게 사라집니다.
워크샵이 있고 며칠이 지난 후에 잠자리에 들면서 '기획은 공학이 아니다'라는 생각이 떠올랐습니다. 공학이나 과학에서는 일관된 프로세스가 중요합니다. 화학실험에서 시약을 넣는 양과 순서와 시간은 매우 중요합니다. 수많은 요소 중에서 하나만 다르게 투입되어도 실험의 결과가 완전히 바뀌어버립니다. 그렇듯이/역으로 정해진 순서와 양을 잘 맞춰서 투입하면 결과물을 또 99%이상 정확히 예측도 할 수가 있습니다. 그리고 과학에서 가설검증은 일종의 (귀납적 경험을 거친 후의) 연역적 사고과정입니다. 어떤 현상을 목격하고 그것을 잘 설명해주는 가설을 세웁니다. 그리고 그 가설을 검증하기 위해서 다양한 실험을 계획하고 수행을 합니다. 그래서 예상했던 결과가 맞으면 가설이 맞는 것이고, 그렇지 않으면 가설을 기각하고 새로운 가설을 세우거나 새로운 실험계획을 수립하고, 또 실험을 통해서 가설을 검증하는 과정을 반복합니다.
그런데 (제품/서비스) 기획도 이런 과학/공학의 과정을 거치는 게 맞는 걸까요? 앞서 말했듯이 어느 정도 정형화된 프로세스는 유효합니다. 그렇지만 하나의 프로세스가 모든 서비스의 기획에 적합한 것이 아닙니다. 그런 프로세스가 특정 서비스의 기획에서 효과가 있다하더라도 프로세스를 진행하면서 유연하게 순서를 바꾼다거나 새로운 단계를 추가/제거하는 일을 끊임없이 벌어져야 합니다. 그런데 고착화딘 프로세스 신봉자들은 사람들의 자유로운 사고의 과정을 장려하기 보다는 그저 틀에 맞춘 질문지에 답변을 할 것을 요구하고, 틀에 맞춘 결과물을 요구하는 경우를 자주 봅니다. 공학은 선형이고 연속적이고 매끄러운 프로세스가 특징이지만, 기획 (또는 사람의 행동 및 사고 과정)은 대부분의 경우 비선형이고 불연속적이고 요철이 많은 그런 미분불가능한 프로세스입니다. 웹2.0시대에 등장한 '영원한 베타'라는 개념이 그런 귀납적인 과정을 잘 설명해줍니다.
창의적이고 재미있는 제품/서비스를 만들기 위해서는 먼저 딱딱하고 재미없는 프로세스부터 파괴하는 것이 우선이지 않을까요? 물론 프로세스 무용론을 펼치는 것은 아닙니다. 주니어들을 교육/훈련시키기 위해서는 프로세스 따라하기가 효과적입니다. 그럼에도 불구하고 더 다양하고 유연한 사고를 거쳐서 더 재미있고 창의적인 결과를 얻기 위해서는 그런 정형화된 프로세스를 파괴하는 과정을 거쳐보는 것도 좋지않을까 생각합니다.
이제껏 많은 제품/서비스에서 실패를 했기 때문에 어쩌면 더 정형화된 프로세스를 고집하는 시도를 해보는 것인지도 모릅니다. 이런 과정을 통해서 또 좋은 결과를 얻게 되면 앞으로는 더 고착화된 툴킷이 될테고, 이렇게 해봐도 별 소용이 없다는 것이 검증되면 새로운 프로세스를 도입하거나 아니면 또 과거처럼 주먹구구로 돌아갈지도 모릅니다. 좋은 결과를 얻기 위해서 이런 저런 다양한 시도를 해보는 것은 참으로 좋습니다. 그게 정형화된 과정을 거치든 그렇지 않든... 그러나 '오직 하나'만을 고집하지는 않았으면 합니다.
