Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

[아티클][UX Summit 2020 요약] 감지와 응답: 우리의 방식을 지속적으로 파악하여 더 좋은 성과에 도달하기


Recommended Posts

<< UX Summit 으로 이동
 

UX Summit 의 2020 시리즈 중, Sense & Respond: Continuously Learning Our Way to Better Outcomes - Jeff Gothelf 의 한글 번역본입니다.

  • 발표자 (Jeff Gothelf)는 애자일 UX와 린 UX 분야에서 매우 인기가 높은 전문가로서 “Forever Employable”, “Lean UX”, “Lean, Agile & Design Thinking”등을 저술한 Gothelf.co의 대표입니다.
  • 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요YouTube 비디오 (총 20분) 보기

이 세션을 통해서 우리는, 

  • 오늘날 우리가 만드는 소프트웨어가 세상을 어떻게 바꾸고 있고 얼마나 영향력이 큰지를 알 수 있습니다.
  • 이에 맞게 소프트웨어 개발자는 어떤 자세를 가져야 하는지를 생각할 수 있습니다.
  • (사람들은 소프트웨어를 의도된 대로 사용하지 않는다는 사실을 인정하고) 더 좋은 소프트웨어 UX를 제공하기 위한 근본적인 접근 방식을 배울 수 있습니다.
     

20-30년 전의 소프트웨어 세상은,

  • 학습이 오래 걸렸다: 만들 수 있는 소프트웨어가 무엇인지조차 알기 어려웠다.
  • 소프트웨어 도입이 느렸다: 설치 미디어를 한 박스 사서 설치해야 했다.
  • 영향(Impact)은 기술 전문가들에게만 끼쳤다: 소프트웨어를 사서 쓸 수 있는 사람이 제한적이었다.
  • 설계한 대로 작동하는 것이 목표였다: 약속한 기능이 작동하는 가가 중요했다.
  • 소프트웨어 출시는 성공을 의미했다: 정해진 시간과 예산 안에 출시가 곧 성공이었다.
     

지금 소프트웨어는 이미 세상을 삼켰다.

  • 2011년, 마크 앤드리슨은 “소프트웨어가 세상을 삼키고 있다”는 유명한 말을 남겼다.
  • 지금은 소프트웨어가 핸드폰 뿐만 아니라 커피머신, 소금통 등 수많은 것을 인터넷에 연결하고 있다.
     

소프트웨어의 근본적인 속성은 20~30년 전에 비해 완전히 달라졌다.

  • 예전에는
    • 하드웨어에 들어있는 정적인 것이었다.
       
  • 이제는
    • 계속해서 학습하면서 진화하는 일종의 지속적인 시스템이다.
    • 예전과 같은 정해진 계획에 따라 소프트웨어를 제작 배포하는 예전 방식이 아니라, 이제는 지속적인 시스템을 만들어 간다.
      결승점이 따로 없고 우리는 이 시스템이 어떻게 사용되는 지를 살피고 지속적으로 새로운 길을 모색한다.
    • "우리는 지금 빅데이터 기술이 부상하는 것을 목격하고 있다. 사물인터넷이 뜨고 있고, 인공지능이 여전히 초기 단계이다.
      따라서 우리는 결승선이 없고 전례도 없는 경주에서 경쟁하고 있다. 규칙 역시 전혀 없다.” - 프란치스코 곤잘레스

       

지금의 자동차 산업을 보면 예전의 소프트웨어 산업을 보는 것 같다.

  • 지금 가진 차보다 더 빠르고, 더 연비가 좋고, 더 음향이 좋은 자동차를 가지려면 새 모델을 사는 것이 당연하다는 믿음이 100년째 이어지고 있다.
    • 사실 이것은 100년전 GM에서 만든 마케팅을 우리가 받아들인 결과일 뿐, 당연해야 할 이유는 없다.
       
  • 소프트웨어도 예전에는 마찬가지였다. 심지어 윈도우 95, 98, 2000처럼 제품에 연도를 붙이기도 했다.
     

소프트웨어 업계의 사람들이 자동차를 만들기 시작하자, 자동차 산업에서 사용자 경험과 가치를 만들고 제공하는 방식이 근본적으로 변했다.

  • 테슬라 차는 자고나면 향상된다.
    • 자고나면 자동차가 향상되어 스스로 운행할 수 있고, 또 자고 나면 자동차가 내가 있는 곳을 찾아오는 기능이 추가된다.
       
  • 사실 향상되는 것은 자동차 자체라기 보다는, 지속적으로 그 차를 지원하는 시스템이 향상되는 것이다.
     

테슬라의 업데이트 사례

일론 머스크는 고객 의견을 트위터에서 인식하고, 응답했다. 그리고 6일 만에 해결책이 반영되었다. 테슬라가 기존 자동차 회사처럼 일하는 조직이었으면 시도조차 하지 않았을 것이다.
소프트웨어 방식으로 일하기 때문에 가능했다. (기사 보기, Opinion: One day, All Companies might be in the Software Business, 2017년 2월)

  • (고객의) 의견: 충전이 완료되어도 충전소에 계속 머무는 운전자 때문에 충전기를 사용하지 못한다.
  • (일론 머스크의) 응답: 맞다. 충전소는 충전하는 곳이지 주차하는 곳이 아니다.
  • (6일 후 반영된) 조치: "충전이 완료된 시점 이후 분당 사용료가 추가되도록" 테슬라 앱이 업데이트 되었다.

(기사 보기, 2014년 2월: 테슬라의 무선 정비: 현존하는 최고의 사물인터넷 사례인가?

  • 테슬라는 판매한 자동차에 대한 지속적인 향상을 무상으로 제공하는 세계에서 유일한 자동차 회사이다. 살짝 바뀐 새 모델을 출시하고 가격을 올리는 다른 자동차 회사들과 비교된다.
  • 테슬라 자동차의 하드웨어는 소프트웨어 무선 업데이트를 통해 거의 끊임없이 개선될 수 있도록 세심하게 설계되어 있다. 간단한 하드웨어 보정도 포함된다.
    이로 인해 테슬라 중고차의 가격이 경쟁사의 새 차 가격과 차이가 없다면 테슬라에게 유리하다.
  • 요컨데, 하드웨어 개선과 소프트웨어가 개선, 이 모두가 무료로 제공된다.

지속적인 피드백 루프 - 고객과 대화하면서 향상시키는 능력을 갖추자. 엄청한 기회가 온다.

Sense1-Continuous Conversation.png
그림1. 지속적 피드백 루프: 감지-응답-배포
 

  • Ship(배포, 사용자에게 배포) - Sense(감지, 사용자의 변화된 행위 파악) - “Respond(응답, 파악된 것에 대응) - Ship(배포) - ...
    • Ship(배포): 작고 빠르게 배포함으로써 투자를 최소화 하자. 그러려면, 이것을 가능하도록 만드는 체계에 투자하자.
    • Sense(감지)새 배포에 대해 고객이 어떻게 행동하는 지를 파악하자. 그러려면, 연구 분석에 투자하자. 
    • Respond(응답😞 고객으로부터 알게 된 것을 바탕으로 우리가 해야할 것을 하자. 그러려면, 조직 문화가 변해야 한다.
       
  • 이 주기를 매우 빠르고 빈번하게 하자.
    • 한 바퀴 돌 때마다 뭔가를 배우게 된다. 빨리 배울 수록 빨리 조치할 수 있고, 투자는 더 작아진다. 그러면 실패하더라도 손실 역시 더 적다.
       
  • 잘못된 것을 알게 되기까지 6일 걸리는 체계와 6달 걸리는 체계는 그 차이가 크다.
    • 피드백 루프를 빠르게 돌려서 가능한 빠르게 학습 하고 반복하는 문화를 구축해야 소프트웨어가 가진 지금의 속성을 십분 활용할 수 있다.
       

조직 문화가 “근본적으로” 변해야 한다.

  • 고객 피드백에 대해 걱정없이 내부 논의를 할 수 있는 문화가 중요하다.
    • 예: “이번에 배포한 기능이 효과가 매우 클 것으로 예상했는데 실제로는 효과가 없네요. 뭔가 다른 시도를 해야겠어요”라는 말을 걱정없이 할 수 있어야 한다.
       
  • 그리고 매우 빠르게 대응하고, 마음 편히 반복할 수 있는 문화가 중요하다.
    • 그래야 잘못된 아이디어도 쉽게 파악된다. 새로운 아이디어로 인해 피해가 생기는 경우에도 피해 규모가 작아진다.
       

소프트웨어 회사라면 사고 방식을 바꾸자.

  • 소프트웨어 공장처럼 일하지 말자: 소프트웨어를 더 많이 만든다고 더 좋은 회사가 된다는 생각을 버리자.
  • 코드가 더 많아진다고, 고객이나 사업의 가치가 더 높아지지 않는다:
    코드가 많아지는 경우, 늘어났다고 확신할 수 있는 것은 코드 자체 뿐이다. 코드가 늘어나면 잠재적인 기술적 부채는 더 커진다.
  • 회사의 성공을 측정하는 방법을 바꾸자: 오로지 고객에게만 집중하는 업무 방식과 감각이 필요하다.
     

우리가 만들 수 있는 기능이라는 이유로 그저 만들기만 한다면,

  • 우리 능력으로 만들 수 있는 기능들을 빠르게 배포할 수 있다.
  • 하지만, 기능이 많다고 해서 위대한 소프트웨어가 되는 것이 아니다.
  • 오히려 아무도 바라지 않고, 아무도 사용하지 못하는 기능들로 가득차게 될 수 있다.
     

회사의 성공 척도는 실제 결과(Outcome)여야 한다.

  • 코드, 기능, 생산 자체를 가지고 성공을 측정하면 안된다.
  • 실제 변화된 사용자 행위가 곧 결과(Outcome)이다. 우리가 사용자에게 실제로 가치를 제공했는지는 그 결과를 통해 알 수 있다.
  • 실제 결과를 보면, 우리가 언제 고객에게 가치를 제공했는지를 알 수 있다.
  • 제품을 제공하는 체계가 구축되면, 초기 버전부터 고객과의 대화가 시작되고 실제 결과를 볼 수 있다.
    피드백 반복을 지속하면서 고객의 행위가 향상되도록 지속적으로 소프트웨어를 개선할 수 있다.
     

문제(Problem): 우리는 사용자의 행위를 예상할 수 없다.

  • 기능을 생각하는 것은 쉽다.
  • 고객이 어떻게 사용할 지를 알고 있다고 믿는 것도 쉽다.
  • 하지만, “우리가 사용자의 행위를 예상할 수 없다”는 것이 사실이고 현실이다. 
     

삼거리에서 불법 좌회전을 방지하기

도로 바닥에 “우회전만 됨” 표시가 있지만, 실제로는 좌회전하는 차량이 많았다. 이 도로의 안전을 향상시키려면? 

Sense2-Output vs Outcome.png
그림2. 생산(Output) 대 결과(Outcome)

  • 조치(우리가 생산한 것, 즉 Output): 좌회전 금지 교통 표지판을 붙인다.
  • 의도한 결과: 운전자들이 이 표지판을 보고 좌회전을 하지 않을 것이라고 생각했다.
  • 실제 결과(Outcome): 이후에도 주민들은 계속 좌회전을 하기를 원했고, 실제로 계속 좌회전했다.
     

생산(Output) vs 결과(Outcome)를 구분하자.

  • Output (부착한 교통표지판) 자체가 문제였을까?
    • 표지판은 아무 문제없다. (소프트웨어라면 약속된 스펙에 맞게 기능이 제공된다.)
       
  • Outcome (운전자 행위 변화) 결과는 생겼는가?
    • 아니다. (소프트웨어로 치자면 Outcome이 없는 Output이다. 아무리 멋져보여도 쓸모가 없다.)
       
  • 우리의 목표는 사용자 행위를 변화시키는 Outcome을 만드는 것이다.
     

소프트웨어는 이 삼거리보다 훨씬 더 복잡하고 예측하기 힘들다.

  • 사람들은 본질적으로 다양하고 예측불가하고 고집스럽기도 하다.
    • 사람들은 과거의 경험, 문화적 기준 등 수많은 요인에 다양하게 행동한다. 우리가 제공한 기능을 그저 장애물로 여길 수도 있다.
       
  • 우리가 사용자의 행위를 파악했다고 하더라고, 변하기 마련이다. 변하는 속도는 점점 빨라진다.
    • 사용자는 우리가 만든 시스템을 사용하는 동안 새로운 행위를 하기 시작하기도 한다.
       
  • (사례) 인스타그램
    고객은 인스타그램에 올릴 완벽한 사진을 위해 찍고 편집 하는 과정 때문에 스트레스를 받았다. 특히 10대 소녀들에게 이 스트레스가 더 심했다.
    10대 소녀들은 이 스트레스에서 벗어나기 위해, 인스타그램에서 예상하지 못했던 다른 행동을 하기 시작했다.
    • 핀스타(Finsta) 현상:
      인스타그램에서 10대 소녀들이 친한 친구들끼리만 소통하는 용도로 가짜 계정을 만들고 솔직하고 사실적인 사진을 공유하는 현상.
      핀스타를 통해 10대 소녀들은 완벽한 사진에 대한 집착과 스트레스에서 벗어날 수 있었다.
    • 인스타그램은 인스타그램 사용자들의 이런 사용을 주의깊게 보기 시작했다:
      인스타그램 밖에서도 이런 현상이 있다는 것을 파악했다. 예를 들면 스냅챗에서는 24시간이 지나면 포스팅이 없어지는 기능이 많이 사용되고 있었다.
    • 인스타그램은 스토리 서비스를 만들었다:
      이것은 현재 가장 성공적인 인스타그램 기능이다. 인스타그램 스토리는 앞에서 파악된 사용자의 니즈를 충족했다.
    • 이처럼 인스타그램은 지속적으로 관찰하고 반영하여 진화하는 시스템이다.
       

또 다른 문제(Problem): 우리는 미래를 예측하지 못한다.

  • 그렇기 때문에 우리는 지속적이고 작은 피드백 루프를 통해 사용자가 더 성공할 수 있도록 돕는 능력을 강화해야 한다.

피드백 루프 (배포-감지-응답)를 통해 사업을 기민(Agile)하게 운영하는 것이 중요한 이유는,

  • 애자일(Agile, 기민한) 사업은 방향 전환을 신속하게 할 수 있다. 그 결과, 어떤 상황에서도 생존할 수 있다.
    • 사례: 미국의 모 증류주 회사에서는 이미 보유한 알콜을 사용하여 소독제를 만들어서 무상 배포하고 있다. (기사 보기)
  • 예전에 성공한 방식이나 기존의 유명 브랜드가 계속 성공할 것이라는 보장을 할 수 없는 세상이 되었다.
  • 새 기능을 잔뜩 만들고 마케팅 예산을 많이 투입해도 성공한다는 확신이 없는 세상이 되었다.
    • 사례: 퀴비(Quibi)의 화려한 출발과 6개월만의 몰락
      이 모바일 전용 온라인 동영상 서비스는 영화사와 유명 테크 기업의 유능한 임원들이 모여 막대한 자금을 투자하고도 6개월만에 문을 닫았다. (기사 보기)
       

사소한 기능이 (긍정적이든 부정적이든) 예상치 못한 엄청난 결과를 초래할 수도 한다.

  • 따라서, 우리는 우리가 실제로 세상에 끼치는 결과(Outcome)를 측정하는 것에 집중해야 한다.
  • (세상에 끼치는 결과에 대한 고려가 없이) 무작정 개선하면 위험을 자초한다. 최악의 경우 범죄가 되기도 한다.
     

사례1: 참여(Engagement)라는 이름 하에 반인륜적 범죄에 도움이 되기도 한다.

페이스북은 월 활성 사용자수(MAU)와 일 활성 사용자수(DAU) 라는 개념을 전세계에 확산했다. 이 두가지 지표에만 집중한다.
이 지표만 높일 수 있으면, 사용자들이 실제로 무슨 일을 하건 (학살을 장려하건, 정치 선동을 하건) 신경쓰지 않는다.

  • 페이스북은 미얀마에서 로힝야족의 위치를 찾고 학살하는데 활용되었다. (기사 보기)
  • 페이스북은 정치인들이 사회적 기준을 위반하는 발언을 페이스북에 올리는 것을 금지하지 않기로 했다. (트위터 보기)

유튜브는 사용자가 동영상을 보면 같은 내용을 담은 동영상 50개를 목록에 보여준다.
유튜브는 사용자가 무엇을 보는 지에는 관심이 없고, 얼마나 많이 보는가에만 집중하고 더 많이 보도록 노력한다.

사례2: “판매”라는 이름 하에 인간 관계 문제를 만들기도 한다.

소매점은 데이터 마이닝(Data Mining)을 통해 판매 흐름을 최적화하고 고객의 니즈를 예측하는 능력을 강화하기를 원한다.

타겟(미국의 소매점)은 여기에 매우 능하다. 고객이 어디에서 무엇을 샀는지, 매장을 방문하는지 온라인 쇼핑을 하는지 등을 파악하고 그 정보를 활용한다.
심지어 고객의 임신유무도 알고 임신/출산용품 관련 할인 쿠폰을 보내기도 한다.

사례3: “효율성”이라는 이름 하에 성차별이 발생할 수 있다.

아마존은 지원자의 이력서를 효율적으로 처리하기 위해 AI를 적용했다. 이 AI에는 편향된 알고리즘이 들어 있었다.
Women's라는 단어가 들어 있으면 감점을 했는데 그 결과 여대를 졸업한 지원자 모두에게 감점이 반영되었다. 아마존은 곧 이 문제를 수정했다.

  • 아마존은 AI를 통해 효율성을 높였지만, 실제 결과는 차별이 발생했다. (기사 보기)
  • 우리는 이 사례를 통해 Outcome에 집중해야 한다는 점을 배울 수 있다.
     

사례4: “편리함”이라는 이름 하에 - 사람을 위협할 수도 있다.

(온도 조절기, 잠금 장치, 조명 등) 스마트홈 기술은 정말 편리하다.

  • 스마트홈 기술을 이용하여 헤어진 배우자를 위협하는 사람들도 있다. (기사 보기)
  • 우리의 사업 성공의 척도에는 사람들이 어떻게 사용하는 가? 나쁜 용도로 사용되지는 않는가? 등의 Outcome이 들어가야 한다.
     

사례5: “뉴스”라는 이름 하에 - 우리에게 가장 나쁜 것들을 전한다.

뉴스를 예로 들면, 일상적이지 않은 가장 나쁜 사건을 널리 전한다.

  • 우리가 고객의 니즈를 해소해주던지, 오히려 망치던지, 두 경우 모두 매출이 발생한다.
  • 우리는 피드백 루프를 반복하면서, 매출 뿐만 아니라 우리가 실제로 제공하는 가치에 대해 끊임없이 살펴야 한다.
     

이것은 최고경영진 이슈다. (Alan Pao, Wired 기고 보기)

SNS 회사와 임원들은 사용자들이 얼마나 많고 얼마나 참여하는 지에 따라 보상을 받는다. 이들은 긍정적인 영향을 미치는지, 위험 요소로부터 보호하는지 등에는 신경쓰지 않게 된다.
 

소프트웨어 사업자/설계자/개발자는 Outcome을 잘 살펴야 한다.

하지만, 개발자들 대부분의 대답은

  • "난 제품 책임자를 믿어요”: 제품 책임자를 믿는 것은 좋지만, 검증하라! 지금 만들고 있는 것이 전략에 맞는지, 왜 만드는지, 어떻게 돈을 벌 것인지를 질문하자.
    만약 책임자도 잘 모른다면 함께 대답을 찾자.
  • 난 그저 코드를 작성하고 싶어요. 고객이나, Outcome 같은 것은 신경쓰기 싫어요”: 20-30년 전만해도 작성된 코드는 전문 기술자들에게만 영향을 끼쳤다.
    하지만, 이제는 너무나 많은 사람들에게 영향을 끼친다. 이제는 더이상 그냥 코드만 작성하는 것만 즐기는 시대가 아니다.
    사람을 존중하는 결과를 가져오는지도 고려해야 한다.

     

당신의 코드가 무엇을 하는 데 사용되는 지에 대해 책임을 져야 한다.

"새로운 기술은 기본적으로, (더 넓은 사회의 윤리적 흔적이 아니라) 그 기술을 만든 사람의 윤리적 흔적을 담고 있다."  - Cennydd, ‘Future Ethics’

고객 중심적인 피드백 루프 (배포-감지-응답)을 바탕으로 훌륭한 UX를 만드는 방법

"목표를 향하고, 가치를 통해 길을 잡고, 두가지 모두 측정하라" - Kim Goodwin

  • 목표(Goal): 실제 결과(Outcome)와 그 측정 지표
  • 가치(Value): 목표 때문에 희생하고 싶지는 않은 것들
  • 측정: 목표와 가치를 각각 명확히 하고, 이 둘 간의 경계도 명확히 하자. 경계가 침범되면 의견을 제시하자.
     

우리가 무엇을 할 수 있을까?

  1. (당신의 사업 모델 즉 회사가 어떻게 돈을 버는 지를) 이해하라.
    • 예) 수집된 데이터는 어떻게 수익에 기여하는가?
  2. (고객 안에 들어 있는) 관심을 파악하라.
    • 예) 고객은 무엇을 하려고 하는가? 고객이 그 목적을 이루고 있는가? 새로운 행동을 하고 있는가?
  3. (고객의 행동을 인지하기 위해) 당신이 만들고 있는 소프트웨어를 직접 사용하라.
  4. (당신의 일이 끼치는 영향을) 측정하라.
  5. (어쩌다 발생할 수 있는 위험에 대해) 논의하라.
  6. (사람에게 위해한 일은) 거부하라.

“너희 과학자들은 자신들이 할 수 있는가 아닌가에만 빠져서 멈춰서서 하는 것이 옳은가 아닌가를 생각하지 않았어.” - 영화 쥬라기공원 중에서

 

<< UX Summit 으로 이동


View full 아티클

이 댓글 링크
다른 사이트에 공유하기

이 토의에 참여하세요

지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.

Guest
이 토픽(기고/질문)에 답하기

×   서식있는 텍스트로 붙여넣기.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   이전에 작성한 콘텐츠가 복원되었습니다..   편집창 비우기

×   You cannot paste images directly. Upload or insert images from URL.

 공유하기

×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.