brunch

You can make anything
by writing

C.S.Lewis

by 진영화 Jan 11. 2016

UX 방법론이 과연 맞는가

방법론 실패경험담

이 글은 오래 전 스타트업에서 근무 할 때 일어난 일을 기초로 작성하였다. 최고의 개발자들과 함께 이상적인 팀을 구성함에도 불구하고 만족스럽지 못한 결과물을 만들어 낼 수 밖에 없었던 이유와 자신이 유능하다고 믿는 방법론 지상주의 스타트업 경영자들에게 이야기를 전하는 게 이 글의 목적이다.

회사는 인내심이 없다.

평생 이런팀을 만들 수 있을까라는 생각을 했던 꿈에 그리던 팀을 구성하였다. 각각 성향이 다른 사람들이 같은 방향으로 코드를 작성하고 그 의도를 쉽게 파악 할 수 있도록 팀워크를 만들어서 탄탄한 개발을 진행하고자 했었는데.. 쉽지 않았다. 경영자는 외부 인사를 계속 유입시키고 사업 초기에서 팀 빌딩까지 노력했던 사람보다 새로 들어 온 사람을 신뢰하는 상황이 이루어 지기 시작하였다. 소프트웨어에 이해를 가지고 있지 않는 사람이 권력을 휘두르기 시작하였으며, 내부 설계와 무관하게 외형을 갖춰 빠르게 런칭하고자 하는 의도로 개발자들은 힘겨워 했다. 개발팀이 구성되고 그들의 성향을 이해하고 맞춰가기까지 기다리지 못하였으며 보이는 부분을 빨리 만들고 싶어 했다.

보이는 부분이 다가 아니다.

시스템을 구성하고자 하는 부분에 있어서 보이는 부분보다 보이지 않는 부분이 중요할 때가 있다. 실제 서비스를 진행 할 때 화려한 인터렉션보다 프로세스에서 오류가 나지 않는 부분과 늘어날 수 있는 사용자에 대한 대응이 더 중요하다고 생각한다. 스타트업이 망하는 과정에 있을 때 가장 늦게 회사를 나가는 직군이 누구인지 묻는다면 나는 주저 없이 서버 개발자라고 말할것이다. 그러나 경영하는 입장에서는 얼마나 유려한 디자인을 가진 앱이 나오는지가 중요하였으며, (그것이 투자에 직결되기 때문인지는 모르지만) 에러에 대한 이해가 없었다.

개선이 아닌 시작에서의 반복

보이는 부분을 중요하게 생각하기 때문에 계속 디자인을 수정하였다. 디자인에서도 고통스럽겠지만, 애니메이션과 디자인의 변경이 될 수록 해당 부분의 통신도 변경되어야 하는데 이 부분을 이해하지 못했다. 개발자 입장에서는 디자인과 애니메이션도 변경하기 힘든데 통신도 변경해야 하니 더더욱 고통스러울 수밖에 없었다. 그러나 경영진 입장에서는 해당 부분을 이해하지 못하였고, 일정또한 협의없이 마음대로 결정하여 부담이 가중되었다. 무엇보다 더 힘든것은 하나의 프로젝트를 맘에들때까지 완성없이 반복한다는 것이었다. 실무자들에게 가장 힘이 빠지는것이 바로 이 부분이었는데 완성하지 않은 상태에서 반복하여 수정하는것 자체가 일정이 늘어남을 의미하지만, 일정의 변경은 없었다.

이미 우리들은 반복하여 개발하고 있었다.

앞서 말한것과 같이 이미 우리는 개발과 수정을 반복하고 있었다. 맘에 맞을 때 까지 계속 수정을 진행하였기 때문에 만들었던 부분을 계속 뒤엎었으며, 그 부분을 업무로 인정받지 못하였다. 또한 새로운 페이지가 늘어나거나 중간에 끼어드는 부분과 설계를 변경하는 부분이 계속되었다. 초반에는 쉽게 변경 될 수 있었으나, 구조가 완성되어 갈 수록 기존 구조를 변경하고자 하기에는 일부가 아닌 크게 변경되는 부분이 다반사였다. (실수가 있었다면 설계가 계속 변경된다는 것을 알지 못한 채 정해진 구조대로 개발할 것이라는 지킬 수 없는 약속을 믿었던 것일 수도 있다.)

멘토링을 받은 대표가 제안한 방법론

경영자 입장에서는 투자대비 얻어지는게 적게 보일 수 밖에 없다. 무언가 문제가 있음을 느낀 경영자는 멘토링을 받았다. 당연하게도 내부 사정을 모르는 사람들은 많은 인원이 투입된 결과물이 실망스러운 퍼포먼스를 가진 것에 대한 조언을 하였다. 여기에 빨리 만들어서 최소 기능들을 구현한 결과물을 시장에 내놓으라는 조언을 하였다.

MVP의 함정

정말 최소의 결과물일 리가 없지 않는가... 경영자 입장에서 해당 제품으로 투자를 받아야 한다면 거의 완성에 가까운 제품이 나와야 한다. 그러나 그정도 수준의 제품이 나올려면 그만한 투자가 있어야 한다. 방법론 그대로가 실무에 적용되지 않는다는 것을 안 시점에는 이미 서로 감정적으로도 상처를 주고 받게 되는 시기가 왔다. 경영자는 내부의 목소를 듣지 않고 방법론 대로만 진행하여 탁월한 관리를 이루고자 하였으며 그렇게 욕심을 낼 수록 팀원들은 점점 지쳐갔다.

방법론을 적용?

개인적으로 UX방법론에 대한 회의가 왔다. 나름대로 공부한 결과 모두 긍정적인 부분만 강조 할 뿐 그 밑에 깔린 팀원들의 희생은 언급하지 않는다. 방법론에 희생되는것을 당연시 여기는것인지 정말 궁금하였고 팀원들이 동의하지 않는 방법론 적용으로 경영자들은 쉬운 관리를 얻으려 하는것이 아닌지 궁금하였다. 방법론을 적용하기 전에 그것이 맞는것인지 검토하지도 않고 유행이나 외국에서 주장하는 부분만 믿고 적용하려는 부분은 무지의 극치가 아닌가라는 생각이 든다.

방법론 그 자체도 의심하기 시작했다.

Lean UX는 물론 방법론들을 다시 보기 시작했다. 솔직히 방법론이 누구 좋으라고 존재하는지 혼동이 갔다. 사용자인가? 경영자인가? 아니면 UX로 돈을 번다는 사람들인가? 또한 그들이 그렇게나 비난하는 폭포수 방법론이 그렇게 나쁜것인지도 의문이 생겼다. 무엇보다 근본적인 의문은 방법론이 사용자를 향하고 있는가이다.

해답을 찾을 때까지 공부하는 수밖에

UX방법론은 기존 시스템의 개선에서는 의미가 있다고 생각하나, 무에서 유로 만드는데에는 적합하다고 생각하지 않게 되었다. 가설을 검증하려고 방법론을 사용한다면, 가설이 검증되기 전까지 회사를 만들지 말아야 한다. 만드는것이 이미 결정된 사업이라면 완성 후 개선을 목표로 적용해야 한다고 생각한다. 폭포수 방법론을 비웃는 사람중에 실제 제대로 그 방법론을 완전하게 진행해본 사람이 얼마나 있는지 모르겠지만, 그 방법론 자체도 의미가 있고 가치가 있다. 또한 지금 돌고 있는 방법론이 대부분 제조업에서 왔다는 것을 생각하면 그게 소프트웨어에 적합한지 다시한번 생각해봐야 할 것 같다. 완성품이 정해지고 눈에 보이는 결과물을 조합하는 부분과 눈에 보이지 않는 부분이 큰 두가지 산업을 동일한 방법론을 적용하는게 과연 적합한지 한번도 이 부분에 대해 고민하는 사람이 없는것이 개인적으로 매우 안타깝다. 결국 스스로 해답을 찾을 때까지 공부하는 방법밖에 없는것 같다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari