[칼럼]UX, "도대체 누구냐 넌?"

출처 : http://www.zdnet.co.kr/column/column_view.asp?artice_id=20110812101136

[지디넷코리아]







기업에서 UX(User Experience, 사용자경험) 업무를 하다 보면 종종 ‘도대체 어디서부터 어디까지가 UX 팀에서 해야 하는 일인가?’라는 의문이 들 때가 있다. 눈코 뜰새 없이 바쁘게 돌아가는 와중에 “UX 팀에서 오후까지 결정해 달라”며 날아든 요구 사항이 전혀 UX 팀에서 할 일이 아닌 것으로 보일 때. 이와 반대로 UX 팀에서는 단 한 명도 참석하지 않은 회의에서 결정된 사항이라며 이대로 진행해 달라는 요청을 받아 읽어보니 거의 모두 UX에 직접적인 영향을 미치는 의사 결정일 때.

UX 담당자라면 누구나 이런 업무 충돌을 겪었을 것이다. “UX가 무엇인지 이해 못하는 내부의 적들아!” 라며 UX 담당자는 분노의 한숨을 쏟아 낸다. 그런데 재미있는 것은 유관 부서들만큼이나 UX 팀원들도 자신들의 업무가 어디서부터 어디까지인지를 명확하게 알지 못한다는 점이다. 그러다 보니 유관 부서들도 불만들이 쌓일 수 밖에 없다. “언제는 이것이 자기네 주관이라고 주장하더니 또 언제는 아니라고 떼쓰고 말이야...” 라는 생각, 아마도 UX 팀의 유관 부서 소속들이면 한 번씩 다 해보았을 것이다.

경영 관점에서 UX의 가치, 프로세스, 조직 구조 등에 대해 분석을 할 때 한 번은 건드려야 하는 것이 UX 업무에 대한 범주와 정의이다. 한마디로 UX 팀의 R&R(Roles & Responsibilities, 역할과 책임)이 문제인 것인데, 왜 UX 팀의 R&R은 명확하지가 않은 것일까? 여기에는 여러 가지 복합적인 이유가 있다.





■UX의 'R & R'...역할과 책임

근본적인 배경부터 끄집어 낸다면 UX의 정의 자체가 아직도 불분명 하다는 것이다. 우선 기존의 UI(사용자환경)와 최근 유행어처럼 번진 UX의 차이부터 명확하지 않다. 이를테면 많은 UI 팀들이 이름을 UX로 바꾸었는데, 그것이 단순히 트렌드에 따른 것인지 혹은 맡게 될 업무의 범주, 역할 및 책임까지도 바뀐 것인지는 불분명하다.

또 기업에 따라서 UI, GUI(Graphical User Interface), UX가 각각 별도의 팀으로 존재하기도 하는데, 이런 기업을 벤치마킹하는 다른 기업들은 도대체 이 세 팀간의 차이는 무엇이고 상호 협업이 어떻게 이루어지는지 납득이 가지 않는다(사실 그렇게 별도의 팀들로 두고 있는 기업들 스스로도 잘 모르는 경우가 허다하다).

조직 구조와 사업 분야에 따라 차이는 있겠지만 UI로 불리던 시절에는 지금보다는 업무 범주가 좀더 단순하고 직관적이었다. 인터랙션(Interaction) 설계하고 GUI 만들고. 그러던 것이 ‘경험’으로 개념이 확장되면서 마케팅, 사업 기획, 전략, CRM, 고객경험(CEM, Customer Experience Management), 광고, 홍보, 흔히들 A/S 라고 말하는 고객 서비스까지 전부 경험의 스펙트럼에 들어오게 됐다.

워낙 많은 항목들이 경험이란 단어의 우산 밑에 놓일 수 있게 되면서 “회사에서 커피 타는 일만 빼곤 다 UX 일이다"란 소리가 나올 만도 하게 된 것이다. 물론 UI에 대해 저렇게 단순하게 단정지은 것에 대해 반감과 의문을 가질 UI 담당자들이 많을 것이다. 필자도 깐깐하게 굴자면 같은 의문을 던지는 측에 해당하는데, 어찌했든 확실한 것은 UI 시절보다 UX 시대인 요즘 정체성에 대해서 더욱 머리가 아파졌다는 점이다.





■애매모호한 UX 업무 사례들

아래는 필자가 직간접적으로 겪은 “매우 애매모호한 UX 업무 범주"의 실제 사례들이다. 자신이 UX 담당자이든 유관 부서 소속이든 이 사례들을 보면서 과연 이들이 UX 팀의 일인지 아닌지를 한 번씩 따져보도록 하자.

• 어느 제품에 들어가는 UI를 만들 때였다. UI 개발을 어느 정도 진행한 후 양산에 들어가기 전에 테스트를 했는데 UI 조작 과정에서 제품의 반응 속도가 너무 떨어졌다. 이 문제는 사용자 경험을 떨어뜨리는 주된 요소로 뽑혀 양산 전까지 반드시 개선되어야 할 1순위 항목으로 올라갔다. 문제는 누가 책임의 도마 위에 올라가야 하는가였다. ‘사용자 경험’이 떨어지는 것이니만큼 UX 팀이 책임을 져야 하는가, 아니면 최적화를 담당하는 개발 팀이 나서야 하는가?

• 예전 피처폰 만드는 시절 경험이다. 한숨 돌리고 있던 어느 날 개발팀으로부터 급한 연락을 받았다. 당시의 휴대폰들은 메모리가 많지 않아 수신하는 SMS의 개수에 제한을 두어야 했는데 몇 개까지 받을 수 있는지에 대한 의사 결정이 UI 스펙에서 빠져 있다는 것이었다. “그건 메모리 관리에 따라 달라지는 것 아닌가?”라며 의문을 제기한 것이 결국 별로 크지도 않은 일에 서로 신경전을 벌이며 갑론을박을 하는 시간소모적 갈등으로 커졌었다. UI 팀의 입장은 “수신 SMS의 메모리 초과로 문제가 발생할 때의 에러 표시와 같은 UI 설계는 우리 일이지만 실제 100개든 120개든 수신 가능한 SMS의 숫자는 개발 팀에서 오히려 UX 팀에게 알려줘야 하는 일이 아닌가”였다. 개발 팀은 개발 팀대로 수신 SMS 목록을 열었을 때 “1, 2, 3 ~ 100" 과 같이 번호를 붙이는 UI를 설계해줘야 하고 이 과정에서 당연히 최대 수신 개수를 UX 팀에서 정해서 UX 문서에 명시해야 한다는 것이었다.

• 역시 피처폰 만들던 시절이다. 피처폰의 배경 화면으로 들어갈 그림의 종류와 그림의 내용에 대해서 어느 부서에서 담당해야 하는지를 놓고 영업, 마케팅, UX 부서 간에 신경전이 벌어졌다. 재미있었던 것은 서로 그 일을 맡지 않으려고 하면서도 막상 다른 부서가 내놓는 아이디어에 대해서는 자신들의 업무 관점에서 “아~ 그건 좀 아닌 듯 한데”라며 비판만 내세웠다는 것. 이 일은 과연 누가 맡았어야 하는가? (당시에는 실제 그림을 만들 외주 업체를 관리하는 UX 부서가 결국 맡게 되었다)

• 난데없이 영업 그룹에서 전화가 왔다. 제품 출시일이 코앞인데 왜 1 페이지짜리 팜플렛 형태의 제품 소개서를 빨리 안 만들어 주냐며 대뜸 호통치는 것이었다. “도대체 이걸 왜 UX 팀에서 해야 하는데? 홍보 팀은 뭐하고 있는가? (홍보 팀이 이 일을 하는지조차 확실하지 않지만)”라며 되받아 치자 “제품 소개서의 곳곳에 UI 화면이 들어가고 간단한 사용 소개가 나오는데 이거 UX에서 해줘야 하는 일이 아닌가?"라는 주장이다. 사용(use) 또는 사용경험(use experience)의 내용이 들어가는 소개 팜플렛, 설치 설명서 또는 책/CD 형태로 제공되는 두터운 메뉴얼은 과연 어느 부서에서 담당해야 하는 일인가?

• 정신 없이 UX 설계를 하고 있는데 전화가 울린다. 받아보니 고객 서비스 센터였다. 고객이 서비스의 이런 저런 사용 방식에 불만을 터뜨리며 전화를 했는데 자기네로는 도저히 감당이 안되니 직접 받아보라며 답도 기다리지 않고 분노한 고객을 직접 연결해 준다. 사용자를 위한 마음을 아무리 많이 가지고 있다 하더라도 고객 대응 훈련을 한 번도 받아보지 않은 UX 디자이너가 육두문자부터 내뱉는 고객을 어떻게 잘 대처 할 수 있겠는가? 아무튼 이 일이 마무리 된 후에 고객 센터 담당자에게 “도대체 왜 이것을 UX 팀에 넘기냐?” 며 항의했더니 답변이 아주 걸작, 요즘 말로 하면 대박이다: “고객들의 사용 경험에 전문적으로 대응하는 부서가 아닌가요?”




■참을 수 없는 팀명의 가벼움

R&R 이야기가 나오면 자연스레 부서명을 따져보게 된다. 대체로 부서명은 그 부서의 R&R이 압축되어 있기 때문이다(영업 팀이 영업 하지 개발하는 것 보았는가?).

사용자 경험을 주관하는 부서는 이름도 다양하다. 아래 이름들은 실제로 필자가 국내외에서 일하면서 소속을 두어 봤던 팀들의 명칭이다(뒤에 부서 호칭도 ‘팀’, ‘그룹’ 등 여러 개였지만 이 부분은 크게 중요한 것은 아니기에 혼동을 줄이기 위해 팀으로 통일했다).


• 인터랙션 디자인 팀
• 인터랙션 팀
• UI 디자인 팀
• UI 팀
• UX 팀
• UI/UX 팀
• HCI (Human-computer Interaction) 팀


이 밖에도 여러 이름들을 들어보았는데 예를 들면 HI(Human Interaction)팀이라든가 CXM(Customer eXperience Management)팀 같은 것도 있었다.

비슷비슷하면서도 조금씩 다른 표현을 사용하는 것은 각 기업마다 UX에 대해 조금씩 다른 관점을 가지고 있음을 보여준다. 물론 ‘메뉴 드리븐 팀’과 같이 어처구니 없다고 밖에 할 말이 없는 팀명을 받아 본 적도 있는데 UX에 대한 개념이 전혀 없는 인사 조직에서 나름 오랜 시간 정성 들여 가공한 이름이었다.

위의 이름 중에 재미있는 이름이 하나 있다. ‘UI/UX’란 표현이다. 외부인으로서 UI와 UX의 차이에 대해 고민했던 흔적이 역력한 이름이다. UI와 UX의 동일성/차이성에 대해서는 여전히 많은 논란이 있지만 대체로 ‘UX는 UI를 포함하면서 더 넓은 범주의 것’임에 동의하는 편이다. 그런데도 UI와 UX를 ‘/’로 분리하면서도 결합하여 놓은 것을 보면 “UI=UX는 아니고, 그렇다고 UX에서 UI를 안 한다고 할 수도 없고…”하며 고민했지 않았나 싶다. 한편으로 “기존의 UI 일은 당연히 다 하는 것이고 기타 경험자 들어가는 것도 다 너희들이 책임져라"라는 염원을 은근히 비친 것일 수도 있겠다.

이름만큼이나 다양한 것이 UX 팀의 소속이다. 특히 UX 팀의 보고체계(reporting line)에 대한 것인데, UX 팀의 R&R은 UX 팀이 어디에 속해있고 누구에게 보고하며 평가 조건이 무엇인가에 따라 크게 달라질 수 밖에 없다. 이를테면 위의 팀명에서 ‘디자인’자가 붙고 안 붙고 하는 것은 상위 조직이 디자인 조직인지 아닌지에 따라 달라진다.

소속이 어딘가에 따라 동일한 업무도 그 내용이 확연히 달라진다. 좋은 예로 ‘UX 설계서’ 또는 ‘UX 가이드라인’ 이라고 불리는 UX 문서를 들 수 있다. 이 문서는 제품/서비스에 탑재될 UX에 대한 설명서로 대개 UX 팀에서 작성하고 개발 팀에게 넘기게 되어 있다. 그런데 중앙 디자인 센터 소속의 UX 팀이면 이 문서에 이번에 추진하는 과제에서의 UX 디자인 근간, 철학, 전략, 방향, 개념 등으로 문서를 채울 것이다.

반면 개발 조직 산하의 UX 팀이면 구체적인 인터랙션 논리(logic), 플로우(flow), GUI 요소들이 위치할 (x, y) 좌표와 모션 효과에 대한 상세한 설명 등 UX 실제 개발에 필요한 내용들을 상세하게 기술할 것이다. 동일한 문서도 어느 조직 산하의 어느 이름을 가진 팀이냐에 따라 이렇게 내용이 달라진다.




■유럽 '필립스 디자인'에서 겪은 일

실제 필자가 겪은 사례를 하나 소개한다. 필립스 디자인(유럽의 전자 회사 Philips의 중앙 디자인 센터)의 싱가포르 스튜디오에서 TV UX 표준화 과제를 할 때 겪은 일이다. 유럽의 스튜디오에서 보내는 UX 가이드라인은 그야말로 ‘좋고 아름다운 이야기’들이 들어있는 디자인 컨셉 설명서였다. 당시 필자는 이를 ‘우아한 유럽풍 UX 서사시’라고 불렀다. 문제는 싱가폴에 위치한 TV 개발 그룹에서는 이런 추상적인 내용의 UX 문서로는 도저히 개발을 할 수 없다고 소리 지르는 것이었다.

양측의 입장을 모두 이해하는 필자로서는 이 우아한 유럽풍 UX 서사시를 현실적으로 개발에 직결되는 UX 스펙으로 바꾸는 일이라 생각하고 그 작업에 들어갔다. 그런데 고래 싸움에 새우등 터지는 격으로 중간에 끼어 과제 내내 양 측 모두에게 호된 질타를 받았다.

유럽의 디자인 동료들은 “개발용 스펙 작성은 우리의 일이 아니다. 디자이너로서 우리의 주 업무는 최고의 UX 디자인 작품 - 필자 기억이 맞는다면 ‘artpiece’란 표현을 썼었다 -을 내기 위해 창의적 발상을 하는 것이며 나머지 세세한 것은 개발 조직에서 알아서 채울 일이다” 하며 개발 스펙 작성에 시간을 쏟는 필자를 힐난했다. 반면 싱가포르의 개발조직 수장은 “개발 스펙에 빠진 use case가 많다. 데드라인이 타이트한데 문서가 제때 전달되지도 않고…” 하면 지속적으로 강한 불만을 표출하였다.

비슷한 업무를 해본 UX 담당자라면 잘 알겠지만 ‘디자인 컨셉 묘사문’을 ‘개발용 UX 스펙’으로 바꾸는 것은 포루투칼어로 쓰여진 시를 한국어로 된 소설로 재구성하는 것만큼 어렵다. 이 표현을 다시 읽어보기 바란다. 소설을 소설로 번역하는 것이 아니라 시를 소설로 재구성하는 것이라 하였다. 언어 간 차이를 번역해야 할 뿐만 아니라 시를 소설화 하면서 엄청나게 많은 내용을 추가로 채워 넣어야 한다.

당시 필자는 UX 디자인 그룹 산하 인터랙션 디자인 팀의 소속이면서 동시에 홈엔터테인먼트 부문의 TV 사업 계정을 맡은 UX 매니저였다. 즉, 디자인 연구가 주된 업무인 디자인 센터 소속이지만 한편으로 한 사업부의 상용 UX의 구현을 책임져야 하기도 했다. 그런데 양 조직의 UX 업무 범주 - 그리고 범주에 따른 업무 산출물 - 에 대한 정의가 너무나도 달랐던 것이다. 재미있는 것은 그 누구도 필자의 업무가 어디서부터 어디까지인지 퇴사하는 그날까지도 제대로 정의 내려주지 못했다는 것이다.




■마이크로 혼동, 매크로 혼동

필자의 경험담을 좀 더 파헤쳐 보자. 업무 범주에 대한 여러 충돌 중에서 가장 극심했던 것이 바로 use case를 얼마나 커버할 것인가 이었다. Use case는 이런 저런 상황에서 사용자가 이런 저런 조작을 했을 때 제품/서비스가 어떻게 대응 하는지를 정리한 것으로 UX 분야에서 말하는 사용 시나리오(use scenario)와 유사한 성격을 가지고 있다. 그렇지만 use case는 소프트웨어 엔지니어링 분야에서 버그가 없는 완전한 소프트웨어를 만들어 내기 위해 사용하는 것으로 보다 좋은 사용자 경험을 제공하고자 작성하는 사용 시나리오와는 근본적인 차이가 있다.

비교적 단순한 제품이라도 use case를 뽑으면 생각보다 많이 나오고 휴대폰이나 IPTV와 같이 복잡한 제품/서비스에서는 use case들은 그야말로 한도 끝도 없다. 개발 그룹의 입장은 이 모든 것이 UX 문서에 커버되어 있어야 한다는 것인데 그 근거로 “사용자가 조작하는 것에 따라 시스템이 반응”이라는 기본적인 HCI(Human-Computer Interaction)가 바로 UX 팀에서 전담하는 분야임을 댄다.

개발 조직에서 우려하던 것 중의 하나는 UX 문서에서 미처 커버하지 못한 use case들에 대해서 타이트한 개발 일정 때문에 개발자들이 UX 팀에 일일이 문의하지 못하고 알아서 스스로 디자인을 해버리는 점이었다. 이것은 사실 UX 팀에서도 걱정해야 하는 사안이다. 그렇게 해서 품질이 떨어지는 UX가 실려 나갔을 때 그 책임은 UX 팀이 져야 하기 때문이다. 또한 UX 문서에는 기록되어 있지 않은 내용들이라 제대로 추적하기가 쉽지 않다.

이번에는 UX 디자인 그룹의 생각을 보자. 사용 경험에 큰 영향을 미치는 핵심적인 use case(즉 use scenario)는 당연히 UX 문서에 들어 있어야 하겠지만 소프트웨어의 완전성(integrity)를 목적으로 모든 use case를 커버하는 것은 개발 팀에서 작성할 소프트웨어 개발 설계서가 할 일이지 UX 문서의 역할이 아니라는 것이다.

UX 팀은 훌륭한 UX를 만들기 위해 노력하는 팀이지 개발자들의 MMI (Man-Machine Interface) 설계 문서를 대신 작성해 주는 대행업체가 아니라는 주장. 바꿔 말해 똑같은 시간이 주어졌을 때 “어떻게 하면 보다 사용하기 쉽고 직관적이며 만족도가 높은 인터랙션을 제공할 것인가?”를 고민하고 창의적 발상 등을 통해 해결책을 찾는 것에 집중해야지 1년에 한 번 발생할까 말까 한 use case까지 한 개라도 더 찾아 커버하려는 것에 용쓰는 것은 UX 팀의 R&R이 아니라는 것이다. 자, 과연 어느 쪽의 주장이 옳다고 생각이 드는가? 당신은 누구의 손을 들어주고 싶은가?

Use case는 UX 스펙, 보다 좁혀 표현하자면 UI 스펙의 매우 상세한 부분에서 발생하는 문제이다. 이와 유사하면서도 그 범주가 비할 바 없이 큰 매크로 단위의 것이 있다. 바로 경험이다. 앞서도 언급하였듯 UI에서 UX로 관심사가 옮겨지면서 R&R에 대한 두통이 더욱 커졌는데 그 주범이 바로 경험이 가지는 대규모 범위의 애매모호함 때문이다. 고객의 경험은 어디서부터 어디까지이며 그 중 UX 팀이 커버해야 하는 사용자 경험은 어디서부터 어디까지인가?

사용자 경험을 전담하는 팀으로서 고객의 경험을 모두 커버해야 한다면 사실상 회사 전체가 UX 팀 소속이어야 할 것이다. 실제로 CEM, 경험경제학(Experience Economy), 체험마케팅(Experiential Marketing)과 같은 분야에서는 ‘경영의 핵심은 고객 경험의 설계와 관리’로 규정을 내리기도 한다. 그렇지만 CEO 밑에 UX 조직이 하나 있고 그 산하에 영업부터 고객 서비스 센터까지 다 들어가 있는 조직의 구도는 상상만으로도 좀 엽기(?)적이다. 당연히 이것은 답이 아니다. 답이 아니라는 데에서 ‘경험 자가 붙는 일은 모두 UX 팀 일이다’가 얼마나 잘못된 생각임을 유추하기는 어렵지 않다(만약 그 말을 철석같이 믿는다면 정말 위에 설명한 대로 회사 조직 체계를 바꾸기 바란다).

기존 UI의 일을 계속 UX 팀이 해야 하는 것에 대해서도 한 번쯤 재고해 볼 수 있다. 앞서 언급하였듯 UI와 UX를 별도의 팀으로 둔 기업들도 있다. 특히 해외 선진 기업에서 이런 사례를 종종 찾을 수 있는데, 그들이 보는 UI와 UX의 차이는 무엇이길래 이들을 갈라 두었을까?

만약 UX가 CEM 등에서 주장하는 대로 고객의 총체적인 경험이라면 UI는 그 총체적인 경험 중에 고객과 제품/서비스가 상호작용 하는 과정에서의 경험을 디자인 하는 분야이다. 필자는 이를 상호작용의 경험(interaction experience) 이라고 종종 표현한다. 고객의 경험 중에는 이 상호작용의 경험 이외에도 다른 여러 경험 들이 있다. A/S 받을 때의 느낌이라든가 제품을 사서 처음 포장을 뜯어볼 때의 체험과 같은 것들 말이다.

이런 경험은 UI에서 다룰 내용은 아니지만 UX적으로는 다뤄야 할 사안일 수 있다. UI와 UX를 나눈 기업은 이런 점을 R&R로 명기하기 위해 그러한 것은 아닐까? 이를테면 UX팀은 별도로 존재하는 UI팀 뿐만 아니라 영업, 마케팅, 사업 전략 및 기획, 홍보, QA, 고객 서비스 대응 부서 등에게 총괄적으로 경험 컨설팅을 제공하는 내부 컨설팅 조직일 수도 있다. 이런 R&R은 “경험 자가 붙는 것은 너희들이 다 알아서 해라”와는 확연한 차이가 난다.




■답은 없지만 명확해야 한다

사실 UX의 R&R에 대해서는 지속가능한 또는 궁극적인 답은 없다. 어느 사업 분야에서 어떠한 BM(Business Model)으로 얼마나 많은 인적/물적/금전적 자원을 가지고 어떤 업무 프로세스에 맞춰 일을 하는가에 따라 정의가 천차만별로 다를 수 밖에 없다. 또한 시장 상황, 경영진의 교체, 경쟁업체들의 행보에 따라 한 회사에서의 R&R도 끊임없이 변화할 수 밖에 없다는 것이 굳이 정답이라면 정답이겠다. 비단 UX 팀뿐만 아니라 회사의 모든 팀이 다 이러지 않을까 싶은 것이 필자 개인의 생각이다.

다만 어느 한 시점에서든 R&R이 무엇이냐고 UX 담당자에게 물으면 명확하게 - 그리고 팀원 모두 공통적으로 - "우리의 R&R은 무엇이다" 라고 말할 수 있어야 한다. 그 R&R이 다른 조직/회사의 UX팀들이 가지는 R&R과 확연하게 차이가 나고 내일이 되면 또 달라지는 한이 있더라도 말이다. 다시 말해 R&R의 수명이 과제 기간이든, 회계연도가 되든, 하다못해 팀장 교체 시기마다 바뀌는 한이 있더라도 매번 한 가지 R&R은 뚜렷하게 있어야 한다.

보다 바람직한 모습은 UX 업무에 직접적인 영향을 주는 주요 의사 결정자 – CEO, 임원, 디렉터 등 - 와 회사의 인사 조직에서 UX 팀의 R&R에 대해 UX 팀원들과 동일한 생각을 가지고 있는 것이다. 이쯤 되면 가히 이상적인 UX의 R&R이라고 할 수 있겠다. 필자는 이를 UX 선진 업무 문화의 한 조건으로 넣는다.




당신이 UX 담당자라면, 당신과 당신 팀의 지금 이 순간의 R&R은 무엇이라고 답하겠는가?



당신이 CEO나 인사 담당자라면, 당신이 믿는 UX 팀의 R&R이 그들의 생각과 동일하다고 자신하는가?