brunch

You can make anything
by writing

C.S.Lewis

by THISDOT Jan 25. 2023

우리는 디자인과 UX에서 ‘문제해결’이라는 늪에 빠졌다

UX에서 문제해결이란

UX를 공부하는 사람이라면, 디자인을 공부하는 사람이라면, 디자인씽킹이란 이론을 들어본 사람이라면 디자인은 ‘문제해결 과정’이라는 말을 너무나도 많이 들어봤을 것이다. 실제로 팀브라운이나 토마스 록우드 같은 디자인씽킹 거장이 그러한 말을 저서에서 직접 언급하였고, 수많은 실리콘밸리 기업 출신의 UX 프로덕트 디자이너가 그렇게 일을 한다 해서 ‘문제정의’→’ 문제해결'을 잘한다는 것은 일잘러의 표본이 되었다.

실제로 그러한 방식이 전 세계적으로 매우 유명세를 탔고 나름 it강국인 우리나라에도 유입되어 입사할 때도 포트폴리오에서 ‘문제해결능력'을 보여주는 것은 매우 중요한 필수 능력이 되었다.

그런데 최근 UX분야에서 특히나 이 ‘문제해결'이라는 부분에 너무 집착한 나머지 무분별하게 남용되는 경우가 간혹 발견되고 있어 관련 내용을 글로 정리해보려고 한다. 사실 실제 케이스들을 알고 있지만 레퍼런스로 넣기에는 너무 직접적으로 말하게 될 수 있어 두리뭉실하게 포괄적으로 그런 흐름에 대한 경각심 정도를 집어가며 이야기를 풀어볼까 한다. 보통 해외 문물이 한국에 들어올 때 긍정적인 면도 물론 많지만 한국 실정을 고려하지 않고 부분별 하게 적용되었을 때 일어나는 부작용이 항상 우려되는 점이다.

애자일 방식에 대한 아쉬움

Agile uses incremental, iterative work sequences called sprints.

애자일은 탑다운 방식의 워터풀 방식과는 달리 스크럼 단위로 계속 반복되는 프로토타입 활동을 통해 완성도를 높여 나가는 방식이다. 하지만 수년간 애자일을 시도해 보고 겪어본 결과 해외와 국내, 그리고 대기업과 스타트업 등 기업 규모에 따라 그 효과가 차이가 있다는 것을 발견할 수 있었다.

특히 나는 애자일이라던가 프로덕트 디자인이라던가 이 말을 처음 들었을 때부터 그렇게 달갑지 않았다. 물론 되게 좋은 말이고 진보된 생각이었지만 과연 한국시장에서 잘 녹아들 수 있을까 하는 생각이 많이 들었다.

개인적으로 어떤 현상을 관찰할 때 bias 즉 편견을 가지고 싶지 않아서 객관적으로 평가할 수 있는 장치를 마련하는데, 그래서 애자일을 진짜 많이 돌려보고 프로덕트 디자인이란 단어에 대해서도 수많은 디자이너와 토론을 해 보았다. 그리고 간접적으로 여럿과 인터뷰도 해보면서 결과적으로 내 우려가 어느 정도는 일리가 있었다는 결론에 도달했다.

애자일은 효과가 좋을 때도 있고 안 좋을 때도 있다.

일단 애자일은 작은 규모의 조직에서는 매우 효율적이고 빠르게 일을 쳐낼 수 있다. 몇 안 되는 디자이너와 개발자가 같은 사무실에서 일하고 수시로 핑퐁이 가능한 상태이며 보고체계도 단순화되고 수평적인 조직이라면 매우 훌륭하게 작동한다.

그러나 조직규모가 좀 많이 커지게 되면 이게 생각보다 운영하기가 힘들다. 수백 수천 명의 임직원이 있는 회사인데 애자일이 운영되려면 프로덕트를 굉장히 많이 스타트업 수준으로 쪼개야 할 수밖에 없다. 그렇지 않다면 애자일 상황에서 문제가 생겼을 때 의사결정이 안 돼서 누군가를 찾게 된다. 그나마 영어가 반말(?!)이고 예전부터 수평적인 문화에 익숙한 해외라면 이런 문제가 닥쳤을 때 pm이 조정을 해줄 수 있지만 국내의 경우는 상황이 조금 다르다. 일단 pm자체가 주니어인 경우 관리가 잘 되지 않으며 po 역할을 하려면 연차가 꽤 있어야 한다. 이 말인즉슨 나이와 연차 차이가 나야 pm의 역할을 제대로 수행할 수 있다는 점이고 이는 수평적인 조직구조라고 보기는 힘든 것이다. 큰 문제에 봉착했을 때 결국 책임자를 찾게 되며 아이러니하게도 이럴 때 탑다운 방식이 효과적이게 된다. pm/po의 역할이 매우 중요한데, 주니어 레벨에서 제대로 된 pm/po 역할을 해낼 수 있는 기업이 얼마나 될지는 잘 모르겠다. (ux 자체가 큰 이슈가 되지 않는 기업이라면 또 이야기가 다르긴 하다. 그런데 그건 그냥 ux팀이 힘이 없는 경우일지도...)

결과적으로 큰 조직에서 애자일이란 탑다운과 애자일의 하이브리드 형태가 가장 이상적이며 애자일만으로는 굴러가기가 힘든 구조이다.

프로덕트 디자인의 맹점

프로덕트 디자인이란 말도 처음에 한국에 붐이 일 초기에, 단어 자체에 대한 definition에 대한 연구와 해외와 국내 사례를 뒤져보고 현장을 경험하면서 아 이 단어도 여러 곳에서 부작용이 있구나 하는 생각이 들었다. 물론 제대로 프로덕트 디자이너를 잘 채용해서 정확한 JD(job description)에 입각한 업무를 시키는 기업도 있겠지만, 커뮤니티 활동을 통해서 수많은 디자이너들을 만나고 검증해 본 결과 제대로 프로덕트 디자이너로서 대우해 주는 회사는 많지 않았다.

프로덕트 디자이너 = 그냥 모든 일을 다하는 사람으로 치부되는 케이스들이 있는 듯하다.

가장 불쌍한 경우는 본인이 프로덕트 디자이너 포지션으로 일한다고 착각(?!)을 하면서 자부심을 가지고 회사를 다니지만 실상은 기획 디자인 마케팅 심지어 퍼블리싱까지 여러 명의 일감을 한 사람에게 몰아주고 가성비 좋은 월급을 받으면서 ‘성장하고’ 있다고 착각을 하는 경우이다. 이미 프로덕트 디자인의 업무 범위를 한참 넘어섰는데도 그 구분점이 모호하다 보니 부당하게 일하고 있는 경우도 많았다. 디스닷 내 주니어 디자이너들 중에 이런 케이스들을 정말 많이 보았고 사실 본인이 그런 케이스인지 인지조차 못하는 경우도 더러 보았다.

그렇다면 그런 디자이너를 채용한 사장님은 얼마나 행복할 것인가! 통탄할 따름이다.

문제해결의 늪

그리고 오늘의 메인 메뉴인 ‘문제 해결'에 대한 부분도 서서히 남용되어 가고 있다는 생각이 든다. 특히나 여러 학원과 매체에서 거의 반 강제 주입식 교육으로 디자인 포트폴리오는 ‘문제 해결’을 보여줘야 한다라고 해서 나온 결과물일 수 있는데, 이 말이 틀린 말은 아니다.

그런데 우리나라의 빨리빨리 문화 덕에 허겁지겁 문제를 찾고 문제를 해결해서 문서를 정리하는 습관이 생기면서 실상 문제 같지도 않은 문제를 문제라고 정의하고, 사실 큰 문제가 아님에도 불구하고 문제라고 지적하면서 고치려고 하는 습성이 생긴 광적인 디자이너들을 보았다. 이해가 아얘 안 되는 건 아닌 게 디자인이란 것이 정량적으로 측정되지 않는 영역이기 때문에 ‘문제해결 횟수'는 꽤나 정량적으로 매력적인 지표이기 때문이다.

그러다 보니 성과를 내기 위해서 문제해결을 하려고 들고 그게 욕심이 과해지면 기본적인 ux를 해치는 지경까지 이르게 된다. 한번 UX를 바꾸면 유저가 적응해야 하는 일정의 시간을 고려해야 하는데 몇 번 프로토를 돌려보거나 a/b테스트란답시고 실험을 주기적으로 반복하여 문제를 찾아내서 해결하는 경우, 그 문제를 해결하기 위해 더 큰 문제를 만들어내는 경우가 생긴다.

이 경우 개인적으로는 성과를 인정받을 수 있을 수 있으나 가면 갈수록 전체 프로덕트의 완성도에 있어서는 삐그덕 하는 여지가 생기는 것이다. 문제는 이렇게 일을 하는 사람이 일을 정말 잘한다고 본인을 평가하고 있는 것이다… 본인은 문제해결 전문가라고 인식하고 있으면서 자존감은 하늘을 찌른다. 그리고 더 큰 문제는 이러한 경험을 좋은 스킬로 포장하여 또 다른 학생들에게 강의나 멘토링을 하고 있다는 점이다…

물론 위 예시는 안 좋은 사례이며 디스닷 커뮤니티에 있는 일원들은 유혹에 빠지지 않을 것이라 믿는다.

문제해결을 위한 문제해결을 위한 문제해결.. 무한반복

자 그럼 어떻게 하면 더 좋은 ‘문제 해결'을 할 수 있을까. 일단 문제에 대한 인식을 조금 더 넓혀 이것이 ux적인 문제점인지 그래픽적인 문제점인지 프로덕트의 운영상 문제점인지 비즈니스 자체가 문제인지 문제의 결을 파악하는 것이 중요하다. 그리고 개인적으로는 본인의 연차와 능력을 객관화하고 회사 입장에서도 해결책을 찾을 수 있을지 전체적인 시각으로 문제의 범위를 설정하는 것이 중요하다. 그다음에 이게 디자인으로 풀 수 있는 건지 ux로 풀 수 있는 건지 파악해야 한다. 디자이너 입장이라면 주 업무가 그거니까 그걸로 해결해야 하는 건 맞는데 막무가내로 해결하는 것이 아니라 이게 디자인으로 혹은 ux로 해결하는 게 맞나…?라는 것을 선 고려해야 한다는 점이다.

그리고 디자인 or ux로 해결했을 때 들어가는 리소스 대비 효과를 고려해서 문제 해결에 착수하고 결과를 내는 것이 필요하다. 사실 이 부분은 경험이 많지 않은 디자이너가 파악하기는 쉽지 않은 부분인데, 옆자리 사수가 잘 알려주는 것이 중요할 것 같다. (사수가 없다면… 음… 스터디...? ㅜㅜ)

이러한 방식으로 일 년간 본인이 했던 문제해결 건수를 강 중 약으로 난이도를 설정하고 해결 시간을 기입하는 것은 그냥 단순히 양을 늘려서 체크하는 것보다 훨씬 질적으로 퀄리티가 좋을 수밖에 없다. 문제가 너무 큰 것이라면 1년 내내 하나도 해결하기 어려울 수도 있는데 그 1건을 해결한다면 본인의 인생 최고 포폴이 될 수도 있다.

문제해결은 강 중 약에 따른 적절한 해결책을 제시해야 한다.

지금까지 디자인, ux 분야에서 ‘문제 해결'의 늪에 빠진 케이스를 알아보고 진짜 ‘문제 해결'을 위해서는 어떻게 해야 하는지 살펴보았다.

사실 기업에서 일하다 보면 문제를 굳이 정의할 필요도 없긴 하다. 어딜 가나 문제 투성이니까. 특히나 작은 스타트업의 경우에는 ux적인 문제부터 회사 운영, 복지, 비즈니스 방향성 등 정말 다양한 측면에서 문제를 직면하게 된다. 그중 하나를 골라서 본인이 가장 자신 있거나 성과를 낼 수 있는 문제를 해결하는 것이 중요하다. 자기 객관화가 안 돼 있다면 본인이 해결하기 버거운 문제를 맡아 정말 고생하는 경우가 생길 수 있다. 물론 어떨 때는 그럼 고생이 도움이 되는 경우도 있지만 추천하고 싶지는 않다 ㅜ

디자인 커뮤니티 디스닷에서는 포폴 스터디를 하면서 포폴뿐만 아니라 자기소개서도 검토하곤 하는데 위와 같은 방식으로 문제를 해결했다면 자소서도 함께 빛이 날 수 있다. 특히 신입 레벨에서 저렇게 문제를 해결했다? 정말 손뼉 쳐주고 싶은 자소서 및 포트폴리오일 것이다. 그러나 감당하기 힘든 문제를 들고 온다면 자승자박의 늪에 빠지게 된다.

주니어 레벨의 문제를 해결할 줄 알게 되었다고 생각했으나 이제는 시니어 레벨의 문제가 눈앞에 있다. 끝없는 레벨업 싸움..

마치 게임처럼 연차가 쌓이면서 신입 때 해결할 수 있는 문제와 시니어가 해결할 수 있는 문제가 난이도가 엄청 달라진다. 레벨업이 되면서 몬스터도 점점 세지는 것과 같은 이치다. 어떤 문제는 대기업 회장님이 오셔도 해결 못한다. (진양철 회장님을 떠올려보자… 순양자동차…) 그리고 아무리 해결하려고 노력해 봐도 세계적인 경제 상황이나 운이 따라주지 않으면 해결이 어려운 경우도 있다.

따라서 문제의 난이도를 파악하고 나와 회사의 상황을 고려하여 해결할 수 있는 좋은 문제를 찾아 해결하려고 해 보자. 문제해결능력이라는 것은 단순히 양만으로 승부해서 키워지는 건 아니므로 최대한 다각도로 분석해서 제대로 된 문제를 찾고 해결하는 습관을 들이면 좋을 것 같다. 문제의식을 항상 가지고 사는 건 매우 좋은 습관인데, 요즘엔 재밌는 문제를 발견하면 마치 제대로 된 먹잇감을 찾은 것처럼 빠져들기도 한다. 그러한 문제를 해결하면 또 매우 기쁘기도 하다. 커뮤니티에서 이런 문제를 공유하고 같이 해결해 나갈 수 있는 사람을 만난다면 더할 나위 없이 행복해진다. 이것이 커뮤니티를 지속 운영하는 원동력인 것 같다.