테스트가 싫은 기획자를 위해

저지르지말고 만드셔야죠

1년 6개월의 달하는 프로젝트 기간의 8부능선에 올라가고 있다. 개발기간은 끝나가고 이제 테스트와 사용자 가이드 교육을 목전에 두고있다.

바쁘다는 말로는 표현이 안되는 지옥같은 시간, 우리 후배는 5년뒤 꼰대를 예약할 것 같단다. 지나고 이 때를 추억할 때쯤에 '라떼는 말이야~'가 안튀어나올 수 없겠다고.

'기획자들은 테스트를 싫어한다.'

난 이 문장이 내 경험에서 생겨난 편견인줄 알았는데 이제보니 이 문장은 진리를 담은 명제였다.  내가 정리해준 어렵고 힘든 정책을 겨우겨우 되새김질해가며 SB를 작성하던 수행사 기획자들이 자꾸 이탈하기 시작했다. 온갖 병들이 도져서 이제 와서 인력이 교체된다.  미래를 찾으시겠다며 나가는 경우도 있다.

 뭐 다들 병이 생기거나 진짜 자신을 위한 일인 것은 사실이다. 근데 그 근저에는 도저히 감당할 자신이 없는 테스트에 대한 부담감이 있다고 생각한다. 그리고 그 테스트라는 건 사실 어떤 면에서 기획과정보다 더 자세하게 더 집요하게 알고 덤벼야하기 때문에 지금 내가 담당하는 주문/클레임 쪽이라면 겁날 수 있다. 시장에 씨가 말랐다고하는 주문 이후 뒷단 기획자들이 이 분야를 가장 힘겨워하는 이유도 바로 이거다.

 감당이 안될만큼 복잡한 케이스와 감당이 안되는 영향도, 그리고 온오프라인을 넘나드는 법과 규제에 대한 지식. 그리고 무엇보다도 서비스의 품질과 직결되는 민감한 부분이니까.

하지만 저지르기만 하는 사람은
기획자가 아니다.
그냥 아이디어꾼일 뿐이다.

 서비스기획자는  저지르는 사람이 아니라 문제를 해결해서 구현해내는 사람이다. 서비스기획자를 준비하면서 인사이트나 퐁퐁 샘솟는 아이디어만 계속 연습한다면 그 사람은 서비스기획자가 될 수 없다. 서비스기획자가 연습해야하는건 도리어 가장 최악의 상황을 떠올리고 막아내는 연습이다.

 아이디어를 떠드는건 누구나 할 수 있다. 날으는 슈트도 눈만 깜빡이면 생겨나는 음식도 있을 수 있다. 하지만 우리가 하는 일은 구현이다. 구현의 과정에서 필요한 것은 '컨셉'이 아니라 어떻게 이걸 진짜로 만들어내느냐에 대한 고민이어야한다. 그리고 항상 말하지만 이건 개발자만 생각해서 해내야하는 몫이 아니다.  물론 말만하는 우리보다 개발자가 엄청나게 멋지게 만들어줄 수 있지만 어떻게 만들어졌냐를 알아야 한다.  왜냐면 지속가능한 서비스를 만들려면 가능한 넥스트 스텝도 알아야 하니까.

테스트는 이해의 차이를 알아내는 과정이다.

 테스트의 중요성은 불신에서 기인하는 것은 아니다.

 이해의 차이에서 기인한다,

 예를 들어 생각해보자.

 기획자가 '콜라맛이 나는 귤'을 만들어달라고 했다고 치자. 기획자의 상상은 그 귤을 먹고 또 재배해서 또 먹고 하는 것이겠지만 이걸 저 말로만 던져놓고 나면 안된다. 개발자는 지속가능한 귤나무를 재배하는지 모르고 귤에다가 콜라를 주입한 단발성 콜라맛 귤을 산출물로 줄 수도 있다.

 이 결과를 제대로 검토하지 않고 그냥 훑어본다면 기획자는 프로젝트를 날렸다고 봐야한다. 개발자에게 처음부터 필요한 것이 무엇인지 제대로 물어보고 불가능했으면 처음부터 왜 불가능한지 알았어야한다. 콜라맛은 안되도 탄산이 들어간 귤은 제배할 수 있었을 지 모른다.

 하지만 콜라맛 귤이든 탄산이 들어간 귤이든 안먹어보면 알 수 없다. 그 먹어보고 다시 재배해보고 다시 또 먹어보는 과정이 '테스트'다.

 그러면 '테스트 케이스'란 뭘해봐야 검증할 수 있는지에 대한 전체 액션이 된다. 써야된다. 요목조목 다양하게  살펴보고 봐야할 수준을 정의해야한다.

QA는 QC나 하면 되지 않나요?
아무도 내 생각과 똑같지 않다

 테스트 기간은 기획자에게 최악이다. Qa도 QC도 개발자도 항상 기획자에게 무언가를 묻는다. 기획자는 시간도 없고 항상 대답을 해줘야하고 답답함을 느낀다.

 하지만 우린 그안에서 빠르게 모순을 찾아야한다. 기획자가 아무리 똑똑해도 내가 정한 수많은 정책에서 모순이 있을 수 있다. 정리되다가 만 것, 조금도 정리가 필요한 것, 그리고

미처 생각하지 못한 것들이 나타난다.

 개발에 넘겼을 때 기획자의 역할이 끝난게 아니다. 이제부터는 진짜 구현을 위한 문제를 빠르게 해결해줘야한다. 테스트하면서 발견되는 이해와 생각의 차이를 이제부터 좁혀 줘야된다.

 최악인 건 알겠는데 지금 오픈전에 바로잡을 수 있는 마지막 기회라고 생각하면 좋겠다. 생각과 다르게 진행된 점을 파악하고 오픈 후에 바꿔야할 점을 찾는 것도 어떤 점이 고객에게 불편한지 찾아내는 것도 지금 다 알아내야한다.

하지만 그 무엇보다도
테스트는 정책을 뼈에 새기는 시간이다

 큰 방향성에 딸린 수백개의 정책을 기획자도 모두 외울 수 있는 것도 아니다. 그런데 이 지독한 테스트 기간이 지나면 완전히 뼈에 새겨진다. 누가 5년뒤에 툭쳐도 이 정책의 이유와 결론을 잘 알게 된다면 그 서비스 하나의 도메인에 대해서 그만큼 전문성이 생기는 거라고 봐야한다.

 모바일에서 이럴 때  오류가 어떤 양상을 보이는지, 사용자가 어떤 방식으로 이용하면 어떤 문제가 생기는지, 서버에 업데이트하다가 무슨 오류가 생기는지 등등.

 한 마디로 하나를 완수하면서 그만큼 경험치가 늘어나는 시간중 하나고 가장 짜증나고 고통스럽지만 제일 필요한 시기다. 오류가 펑펑나는 서비스에서 좋은 경험을 기대하는 것은 어불성설이니까.

 고로 테스트에 대해 고만 불평하자.

 기획자보다 더 테스트 잘 해낼 사람은 없다.

 이제 그만 기획 저지르고. 끝까지 잘 만들어보자.

... 라고 스스로에게 말해봅니다.