Browse Month

8월 2016

[hotjar] Questions-love-to-ask-users 일부번역

https://www.hotjar.com/blog/2016/03/05/questions-love-to-ask-users/#E-commerce

  • 리딩 포인트 : 드라이버, 배리어, 훅 중 무엇을 얻고자 하는 질문인지 생각해보자.

E-commerce
구매전
– 어떤 정보가 누락되었는가? 혹은 어떤 정보가 구입 결심을 쉽게 만드는가?
– 이 아이템을 구입할 때 무엇이 가장 큰 불안(fear)과 우려(concern)인가?
– 오늘의 방문 목적을 달성(complete)할 수 있었는가?
– 만약 오늘 구입을 하지 않았다면, 무엇이 당신을 포기(stop)하게 만들었는가?

구매후
– 결제(checkout) 프로세스에서 개선해야 할 곳은 어디인가?
– 우리 사이트에서 상품을 구입하는데 가장 큰 불안과 우려는 무엇인가?
– 아이템을 구입하도록 유혹한(persuade) 요소는 무엇인것 같은가?
– 만약 더 이상 서비스를 사용할 수 없게 된다면, 가장 아쉬울 것 같은 기능 하나는 무엇인가?

그 외 좋은(great) 질문들
– 가자고를 지인들에게 추천할 확률은 얼마나 되는가? (NPS 질문, 상세내용 => http://book.naver.com/bookdb/book_detail.nhn?bid=7851521)
– 가자고는 몇점(1 – 10)?

개인취향 JPA 사용기 1편 – SpringBoot + JPA + Gradle

안녕하세요? 가자고 개발팀 막내를 맡고 있는 gemini 입니다.

저희 가자고 서비스는 Spring Boot + JPA/Hibernate 기반으로 개발이 되어있습니다.
그리고 개인적으로는 JPA를 쓴지는 약 2년 되어갑니다만, 아직 많이 부족합니다.

팀 내부에서는 JPA에 관하여 여러 얘기가 오고 갑니다만, 저는 ORM 옹호파를 맡고 있습니다.
내부적으로 문제 발생 시 자주 JPA를 의심합니다. 그러나 이것은 JPA를 아직 성숙하게 다루지 못하기 때문이라 생각합니다.

물론 러닝커브가 존재하는 것은 맞기에 팀원들이 JPA 스터디에 힘을 쏟을지, 빠르게 걷어낼지는 팀의 선택입니다.
개인적으로 ORM에 관심이 있어서 가자고를 JPA로 개발해가며 느낀 점 + 제 개인의 취향대로 JPA를 지금 보다 더 올바르게 사용해보려 합니다.

먼저 오늘은 Spring Boot + JPA + Gradle 프로젝트 설정을 해볼 것입니다.

프로젝트 생성

Spring Boot 프로젝트 생성을 진행합니다.
Screen Shot 2016-08-24 at 1.01.50 AM

프로젝트 설정

프로젝트 설명은 편하게 작성합니다. 저는 개인적으로 Maven 보다는 Gradle 을 선호합니다.
각각 장단점이 존재합니다만, 해당 내용은 추후 다른 포스팅으로 정리해보겠습니다.
Screen Shot 2016-08-24 at 1.40.55 AM

초기 의존성 설정

프로젝트 생성 후 필요에 따라 추가하면 되기 때문에 무시하셔도 됩니다만, 전 그냥 눈에 들어오는 것만 체크하였습니다.
Screen Shot 2016-08-24 at 1.04.25 AM

자 이제 프로젝트가 생성되었습니다. 시작이 반인데 벌써 끝나갑니다.

프로젝트 생성 후 build.gradle 을 확인해봅니다. 조금 길고 뭐가 필요한지도 모르겠습니다.
그래서 저는 아래와 같이 수정하였습니다. 모르는 건 일단 지우고 필요할 때 추가하면 될 것 같습니다.

필요에 따라 부가적인 의존성을 추가합니다, Boot 1.4가 릴리즈 되고 Hibernate 버전이 5.0.9.Final 으로 올라왔습니다.
Boot 1.3.x로 설정할 때에는 Hibernate 버전을 강제로 올려줬습니다만, 버전 명시를 생각 없이 늘리다 보면 Boot를 사용한 의미가 퇴색되는 것 같기에 가능한 지양합니다.

application.properties 을 설정합니다, 일단 저는 최소한의 설정을 넣어봤습니다.

Spring Context가 잘 load 되는지 contextLoads 테스트를 돌려봅시다.

Screen Shot 2016-08-24 at 1.53.44 AM

별문제 없이 테스트가 통과하였네요. JPA를 올바르게 쓰는 과정에서 테스트가 중요하다 생각합니다.

앞으로 어떤 것을 만들지 잘 모르겠으나, 장바구니고객 객체가 존재한다고 생각해보겠습니다.
대략 이런 형태로 존재하겠지요.

id 필드는 getter 만 만들었는지, lombok은 몰라서 안 쓰는 건지 궁금하실 수도 있으실 겁니다만
해당 내용은 다음 편에 적도록 하겠습니다.

그럼 이제 Boot를 Run 시켜봅니다.
Screen Shot 2016-08-24 at 11.15.26 AM

정상적으로 동작한 것처럼 보이네요, 다행입니다.

충분히 예상 가능하지만 무슨 일이 벌어졌나 DB Tool을 실행시켜 테이블 목록을 한번 확인해봅니다.

객체만 만들었을 뿐인데 상응하는 테이블이 잘 만들어졌습니다.

몇몇 설정들도 제가 원하는 대로 적용된 것 같네요, 다음 편에서는 이러한 JPA 설정과 객체 설계에 대한 생각을 공유해보겠습니다.

피드백은 언제나 환영합니다. geminikims@gmail.com

두서없는 글 읽어주셔서 감사합니다.

레저큐 인턴기 5편 – 백엔드 개발 도전기 (1)

신이라면 믿겠지만 아니라면 데이터를 가져와야 합니다.

인터넷에서는 사용자의 결정과 행동을 추적하여 누적해두고 의미 있는 정보로 ‘데이터화’하는 것이 가능하다. 그리고 이런 데이터는 웹 쇼핑몰이라는 가상의 매장을 만들어놓고 상품을 판매하는 이커머스 서비스에게는 매우 강력한 무기가 된다. 웹사이트에서 어떤 사용자 경험성(UX, User Experience)을 제공할지, 어떤 상품을 노출할지, 어떤 가격으로 판매할지 등을 결정할 때 사용자의 구매 패턴과 행동 데이터들을 이용할 수 있고, 이를 통해 서비스의 매출을 극대화 시킬 수 있기 때문이다.

데이터를 기반으로 이커머스 서비스는 어떤 유저에게, 어떤 상품을, 어떤 가격으로(논쟁거리가 되기도 한다!) 노출할지 개인화할 수 있어서, 경제학에서 말하는 이상적인 판매 전략을 실현하여 큰 이익을 낼 수 있다. 따라서 데이터화와 분석은 이커머스가 기존의 상거래 시스템과 차별화되는 가장 주목할만한 요소 중 하나이며 기업의 성장과 직결되는 문제이다.

bigdata
빅데이터! 빅데이터! 빅데이터! 인터넷 세계에서 유저들이 만들어 내는 수많은 데이터들을 수집하고 잘 분석하는 것은 이제 이커머스 서비스에 필수적인 역량이 되었다. (이미지 출처 : LinkedIn post by Amarnath K Mattad)

이커머스 서비스는 사용자의 구매 패턴과 행동을 통계내고 분석하는 툴 혹은 시스템을 잘 구축해야 한다. 물론 사용자와의 인터랙션을 추적하는데 이용하는 Google Analytics과 같은 툴들도 훌륭하긴 하지만 아무래도 DB에서 가져오는 통계보다는 훨씬 부정확하고, 이커머스 운영의 의사결정에 활용하기 위한 정보들을 얻기에는 기능이 부족하다.

가자고 개발팀은 얼마 전부터 엘라스틱서치라는 검색엔진/데이터 저장소를 이용해서 매출과 실시간 판매 데이터등을 통계내고 비주얼라이제이션 하는 시스템을 구축하고 있다. 하지만 서비스 초창기에는 실시간으로 서비스 데이터를 수집하고 분석하는 시스템을 구축할 시간이 없었다. 대신 필요한 데이터가 있을 때 마다 SQL(Structured Query Language)코드로 직접 데이터베이스(DB)에서 판매 데이터나 매출 정보들을 긁어오는 ‘노동집약적인 방식'(^^;)으로 데이터를 수집하고 분석했다.

SQL
SQL은 관계형 데이터베이스 시스템을 관리하고, 조건에 맞는 데이터를 질의(Query) 하는데 이용되는 표준 언어이다.

나의 첫 백엔드 개발

나같은 새내기 개발자에게는 이런 작업이 좋은 기회가 될 수도 있다. DB에서 원하는 데이터를 가져오는 작업을 통해 시스템과 DB의 구조에 대해서 파악할 수 있었기 때문이다. 이커머스 서비스는 DB의 구조와 관계가 매우 복잡한데, 원하는 데이터를 얻기 위해서 어떻게 SQL 쿼리를 짤지 고민하는 것이 이 구조를 이해하는데 좋은 연습이 된다.

하지만 며칠이 지나자 통계를 얻기 위해서 SQL을 짜고, DB에 쿼리를 날리고, 얻어낸 데이터를 다시 스프레드시트에 정리하는 반복적인 작업들이 귀찮아지기 시작했다. 조금씩 조건이 바뀔 뿐, 매일 같이 반복적인 작업을 하는 것일 뿐인데, 수작업으로 SQL을 작성하고, 쿼리를 날리고, 데이터를 스프레드시트 포맷에 정리하는 일련의 일들이 생각보다 훨씬 번거롭고 지루했던 것이다.

이걸 자동화 할 수 있는 방법은 없을까? 당연히 있다. 가자고 백엔드 어플리케이션에 아예 이 통계를 내주는 기능을 추가하고 API를 만들어서 관리자 사이트에서 필요한 데이터의 종류와 검색 조건을 입력하면 해당하는 데이터를 엑셀로 정리해서 다운받을 수 있게 하면 된다.

자, 그렇다면 이제 드디어 첫 백엔드 개발을 시작할 때가 되었다. 일찍이 난무하는 자바 어노테이션(Java Annotation)들과 복잡한 구조에 기죽어서 포기했었던 백엔드 개발에 다시 도전하게 된 것이다.

그 첫번째 미션은 바로 입력한 조건에 따라 DB에서 서비스 운영에 필요한 통계자료를 추출하는 웹 API를 새로 만들기!

백엔드와 프론트엔드

여기서 잠깐 백엔드(Back-end)나 프론트엔드(Front-end)라는 용어를 정리하고 넘어가자. 위키피디아에 따르면 백엔드와 프론트엔드는 이렇게 정의되어 있다.

In software engineering, front end and back end distinguish between the separation of concerns between the presentation layer (the front end) – which is the interface between the user – and the data access layer (the back end). The front and back ends may be distributed among one or more systems.

갓 위키피디아 님에 따르면, 어플리케이션에서 엔드 유저의 눈에 보이지 않는 쪽을 백엔드(back end), 반대로 웹 브라우저 등을 통해서 유저에게 보여지는 쪽을 프론트엔드(front end)라고 한단다. 즉, 브라우저에서 유저와 인터랙션 하는 웹사이트의 UI를 구현하는 것은 프론트엔드 개발이고, 그 UI에 데이터를 뿌려주고, 사용자의 요청을 받아 비지니스 로직대로 처리할 수 있도록 구현하는 것은 백엔드 개발이라고 할 수 있다.

프론트엔드 개발자는 JavaScript, HTML, CSS 등을 이용해서 사용자 친화적인 UI(User Interface)를 구성하는데 주안점을 둔다. 반면에 백엔드 개발자는 사용하는 웹 프레임워크에 따라 Java(Spring, Spark…) 혹은 Python(Django, Flask …) 혹은 JavaScript(NodeJS) 혹은 Ruby(Ruby on Rails)를 이용해서 개발한다. 백엔드 개발자들이 가장 중요하게 생각하는 것은 웹 어플리케이션의 성능과 안정성, 그리고 아키텍쳐이다.

최근엔 백엔드, 프론트엔드, DB 관리, 서버 관리 등 웹 개발에 필요한 기술 전반을 모두 다룰 수 있는 풀스택 개발자(Full-stack developer)들도 시장에서 각광을 받고 있지만, 스타트업의 개발자들은 보통 백엔드 개발 전문 혹은 프론트엔드 개발 전문으로 역할을 나눈다. 백엔드 개발과 프론트엔드 개발은 요구하는 기술이 다르고 초점을 맞추는 것도 다르기 때문에 철저히 전문화된 개발자를 필요로 하기 때문이다.

web dev
웹 개발자들에게 요구되는 기술들. 보통은 한 명의 개발자가 이 모든 것을 다 하기 쉽지 않기 때문에 프론트엔드 개발, 백엔드 개발로 역할을 나누고는 한다. 좀 더 자세히 알고 싶다면 Michael Wales가 Udacity 블로그에 쓴 3 Web Dev Careers Decoded: Front-End vs Back-End vs Full Stack을 참조하자.

가자고는 8명의 개발자가 함께 개발하고 있는데 프론트엔드에 치중하는 개발자가 2명, 백엔드에 치중하는 개발자가 4명, 그리고 그 모두를 개발하고 있는 풀스택 개발자가 1명 있다.

나머지 1명인 나의 역할? 어디에도 속하지 않지만 어디에도 속할 수 있으니 풀스택 개발자라고 치자. ^^

백엔드 개발하기

백엔드 어플리케이션은 서버에서 데이터를 비지니스 로직대로 처리하고 처리한 데이터를 웹 API(Application Program Interface)를 통해 제공하는 역할을 한다. 프론트엔드 개발자들이 우리 눈에 보이는 UI 껍데기를 만들어 놓으면 백엔드 개발자가 개발한 API로 데이터와 리소스들을 불러와서 뿌려주는 것이다.

가자고는 백엔드 프레임워크로 스프링 프레임워크 (Spring Framework)를 쓴다. 스프링은 Java 진영에서 가장 널리 쓰이는 오픈소스 웹 어플리케이션 프레임워크이다. 엔터프라이즈 용으로 개발된 웹 프레임워크이기 때문에 방대하고 기능이 매우 다양하며 유지보수가 쉬운 (쉽나…?) 프레임워크이다. 다만 방대하고 기능이 많은 만큼 진입장벽이 높고, 배우기 어려운 프레임워크이기도 하다.

spring_framework
스프링 프레임워크는 이제는 사실상 Java진영의 엔터프라이즈급 표준 웹 어플리케이션 프레임워크가 되었다. 무엇이든지 할 수 있는 스위스칼 같은 존재랄까…

가자고는 일반적으로 웹 어플리케이션에 적용되는 MVC 디자인 패턴에 따라서 어플리케이션을 뷰(View), 컨트롤러(Controller), 모델(Model)로 나눠서 개발을 하고 있다. 각 컴포넌트들의 역할을 정리해보면…

  • 모델: 관계형 DB에서의 테이블에 대응되는 개념이다. 즉 데이터 스키마라고 볼 수 있다.
  • 뷰: 브라우저를 통해서 유저의 눈에 보이는 UI를 구현한 소스코드와 그 컨테이너에 해당한다.
  • 컨트롤러: 유저의 요청사항(request)를 받아 데이터를 의뢰하고, 가공 후 웹 API의 형태로 돌려준다(response).

뷰가 프론트엔드(JSP, JS, HTML, CSS 등에 해당)에 해당한다고 하면 컨트롤러와 모델이 백엔드에 해당하는 컴포넌트이다. 따라서 웹 API를 만들기 위해서는 처리하고자 하는 데이터들의 스키마(설계도 혹은 틀 쯤으로 생각할 수 있다)를 모델로 정의 및 구현하고, 컨트롤러에서 요청을 받아 비지니스 로직대로 처리하여 돌려 줄 수 있어야 한다.

다만 가자고에서는 (일반적인 웹 어플리케이션들이 그렇듯이) 컨트롤러의 역할을 서비스(Service: 비지니스 로직을 구현한 부분. 추상화된 ‘모델’을 이용하여 이를 가공하고 컨트롤러에 돌려준다.), 리포지토리(Repository: DB와의 인터페이스를 담당한다. ‘모델’의 추상화를 담당하는 부분이다.) 등의 여러개의 레이어로 나누어 개발하고 있다. 이런 구조를 레이어드 아키텍쳐(Layered architecture) 라고 부른다….

mvc_pattern
MVC 패턴의 개념도. (이미지 출처: 구루비 위키)

spring_layered_archtecture
스프링 프레임워크의 레이어드 아키텍쳐. (이미지 출처: petrikainulainen.net)

아, 새로운 용어들이 나오니까 벌써 머리가 아파온다. 자세한 내용은 생략하자… 다음에 좀 더 자세히 얘기할 기회가 있을 것 같다. 여튼 백엔드 개발은 이렇게 복잡한 디자인과 구조, 그리고 웹을 이루는 기반 기술들에 대한 이해를 요구하는 작업이다. 하지만 (이 무렵의) 나에게 이러한 지식과 이해 따위가 있었을리 없다. 그래서…

일단 만들고 보자

그 많은 지식들과 기반 기술들에 대해서 습득할 시간도 없고, 방대한 개발 문서들을 읽을 수도 없다. 숙련된 개발자는 새로운 프레임워크나 라이브러리들을 익히기 위해서 개발문서를 차분히 읽어보면서 기능과 개념을 공부하겠지만 나와 같은 새내기 개발자에겐 아무리 잘 쓰여진 개발문서도 “흰것은 종이요 검은 것은 글자” 일 뿐이다. ‘내가 무엇을 아는지, 무엇을 모르는지’ 전혀 모르는 상태이기 때문이다.

그래서 일단 만들고 싶은 것을 땅바닥에 헤딩해가며 만들어보기로 했다. 그러다 보면 내가 무엇을 공부해야 하는지, 개발 문서에 잔뜩 써져 있는 외계어들이 무엇을 의미하는 것인지도 점점 알게 될 것이다. 다행히 이미 가자고 팀 개발자들이 짜놓은 API 코드가 아주 많으니 참고할 코드도 충분하다.

시작부터 험난하지만 이렇게 나의 첫 백엔드 개발이 시작되었다. 구체적으로 어떻게 했는지 계속 이어서 쓰고 싶지만 이미 충분히 길어졌으니 아 힘들다… 좋은 글귀를 남겨놓고 이번 편을 마무리하자. 다음편에서 계속…

정신적인 존재로서 드넓은 물을 향해 가자.
너는 거기에서 종횡무진으로 살아가며,
마음대로 움직이리라.

요한 볼프강 폰 괴테, “파우스트” 중

By EastskyKang

AOP와 프록시 그리고 스프링 컨테이너

안녕하세요. 가자고 시니어 개발자 HJ.Park 입니다.
이번 포스트에서는 Java 진영에서 가장 많이 사용하고 있는 Spring 프레임워크에서 우리가 자연스럽게 사용하고 있지만 범하기 쉬운 실수에 대해서 공유합니다.
경험에 대해 자연스럽게 공유하기 위해서 편하게(라고 쓰고 반말이라고 읽습니다.) 쓰도록 하겠습니다.

사건의 발단은 이랬다.

가자고의 상품 유형은 매우 다양했고 그 다양성 때문에 결제로직은 매우 복잡한 비지니스 로직을 가지고 있었다.
결제 모듈을 담당한 개발자(이하 A 개발자)가 복잡한 비지니스 로직을 풀기 위해서 팩토리 패턴과 필터 패턴을 사용했는데 A 개발자는 팩토리에서 새 필터 인스턴스(new로 생성한)를 반환하도록 설계했다.
아마 그 개발자는 일부러 그렇게 설계했었던 것 같다. 처음에 해당 로직은 이상없이 잘 돌아갔다. 하지만 문제는 유지보수 및 기능을 계속 추가하면서 발생했다.
해당 모듈을 다른(이하 B 개발자) 개발자가 인수인계를 받았으나 해당 부분에 대한 유의사항(팩토리에서 반환하는 인스턴스가 스프링의 인스턴스가 아니라는 사실을…)을 전달받지 못했다.

그리고 약 6개월 후 우리는 팩토리에서 반환되는 인스턴스 필터의 메서드에 @Transactional을 걸었다…
처음에는 @Transactional이 복잡한 비지니스 로직과 구조속에 깊이 감추어져 있었기 때문에 우리의 잘못을 바로 알아채지 못했다.

시간이 지나면서 우리의 예상과 다르게 롤백된 데이터들이 발견되기 시작했다.
처음엔 그냥 하이버네이트의 트랜젝션 매니저(우리는 하이버네이트를 사용중이다.)가 이상하게 동작한다고 생각하고 하이버네이트를 욕하고 넘어갔다. 🙁

그리고 약 일주일 후 필터 인스턴스에 AOP를 걸려고 했지만 AOP가 제대로 동작하지 않았다.(@Transactional도 AOP로 동작한다.)
그래서 디버깅한 결과 필터 인스턴스가 new로 반환된 인스턴스이기 때문에 AOP가 전혀 동작하고 있지 않았던 것이다.
(스프링 프레임워크에서 AOP를 사용하기 위해서는 인스턴스에 프록시가 걸려있어야 하고 스프링 컨테이너에 등록되어 있는 인스턴스는 프록시가 걸려있다.
반면 동일한 클래스라고 해도 new로 생성한 인스턴스는 프록시가 걸려있지 않다.)

스프링의 빈을 사용하는 규칙은 간단하지만 이러한 실수는 복잡한 비지니스로직과 구조… 그리고 여러 개발자를 거치다 보면 이러한 문제는 어느 프로젝트나 발생할 수 있는 문제다.
그렇기 때문에 우리는 스프링 컨테이너와 AOP 그리고 프록시에 대한 아래 기본적인 사항을 꼭 숙지해야한다.

스프링 컨테이너

스프링을 사용한다면 스프링 컨테이너에 대한 기본적인 이해가 필요하다.
우리는 스프링의 인젝션(@Inject, @Autowire, @Resource…)을 사용하면서도 이 인스턴스들이 어디에서 오는지 별로 신경을 쓰지 않는 사람들도 많다.
그래서 스프링의 인스턴스들이 싱글턴으로 관리되고 있음을 망각하고 new를 사용하는 경우도 가끔 있다.
물론 단순한 로직이나 구조에서는 잘 일어나지는 않지만 복잡한 비지니스로직과 구조가 만나면 누구라도 충분히 할 수 있는 실수다.
스프링의 org.springframework.stereotype 패키지에는 @Component, @Controller, @Repository, @Service등의 annotation(이하 애노테이션)이 있다. 이 애노테이션을 클래스에 걸고 스프링에 해당 패키지를 스캔하도록 설정하면 해당 클래스들은 스프링이 초기화될 때 스프링 컨테이너에 하나의 인스턴스가 들어가게 된다.
물론 @Bean으로 직접 인스턴스를 생성, 설정하고 return하는 방법이나 XML로 선언하는 방법 등이 있다.

AOP와 프록시

스프링의 AOP는 대상 인스턴스에 반드시 프록시가 걸려있어야 작동을 할 수 있다.
인스턴스에 프록시가 걸리기 위해서는 스프링 컨테이너에 빈을 등록해야하며 반드시 스프링 컨테이너에 등록된 빈을 사용해야만 한다.

예제 – 스프링 컨테이너에 등록된 빈과 새로 생성한 인스턴스 비교

소스코드: https://github.com/hyunjun19/spring-boot-sample-aop

스크린샷 2016-08-23 오전 12.52.34
위 이미지를 보면 springInstanceService와 newInstanceService는 동일한 HelloWorldService 클래스의 인스턴스이지만 hashcode가 2872, 2876으로 각기 다른 인스턴스임을 알수 있다.
또한 springInstanceService를 보면 CglibAopProxy가 여러개 걸려있는 모습을 볼수있는 반면에 newInstanceService는 아무런 프록시도 걸려있지 않은 모습을 볼수 있다.

‘핫자르’로 웹사이트 최적화하기 – 액션 플랜 가이드

Translated by Dongho Kang@LeisureQ

이 문서는 (주)레저큐의 웹서비스 가자고핫자르를 도입하고자, 영문으로 되어있는 hotjar action-plan 문서를 한국어로 번역한 것입니다. 번역은 2016년 8월 22일자 문서를 기준으로 하며 의역, 오역이 있을 수 있습니다. 어색한 부분이나 변경된 부분을 발견하시면 피드백 부탁드립니다.


‘핫자르’로 웹사이트 최적화하기

웹사이트 방문자들이 실제로는 어떻게 웹사이트를 이용하고 있는지 확인해보세요 – 당신의 비지니스가 성장할 수 있는 가장 ‘핫한 기회’ 하태핫태!를 발견할 수 있을 것입니다.

이 문서에서는 다음의 내용을 다룹니다.

A: 어떻게 드라이버(Driver – 몰이꾼)와 배리어(Barrier – 장벽)와 훅(Hook – 갈고리)을 이용해서 웹사이트의 ‘큰 그림(Big Picutre)’을 볼 수 있는지
B: 오늘 당장! 당신의 웹사이트를 개선할 수 있는 아홉 단계의 쉽고 간단한 핫자르(Hotjar) 액션 플랜.

시중에는 많은 데이터 분석 툴들이 있지만 대부분의 툴들이 쓸데없이 데이터들을 무수히 늘어놓기만 할 뿐 효과적인 의사결정을 오히려 방해하고는 합니다. 오로지 핫자르 만이 당신에게 ‘핫한 기회’를 선사합니다. 저희가 주의깊게 골라 만든 핫자르 도구세트는 웹사이트 방문자들이 무얼 하고 있는지 (관련도구: 힛맵 (Heatmaps), 방문자 인터랙션 다시보기 (Visitor Playback), 퍼넬 (Funnel)) 그리고 왜 그 일을 하고 있는지 (관련도구: 피드백 투표(Feedback Polls), 서베이 (Surveys), 사용자 테스터 채용하기 (Recruit User Testers))보여줄 것입니다.

핫자르 액션플랜은 단기간에 큰 임팩트를 줄 수 있는 테스트나 변화를 만들 수 있도록 도와줌으로써 당신에게 멋진 기회들을 가져다 줄 것입니다. 하지만 액션플랜을 살펴보기 이전에 당신은 먼저 웹사이트의 진정한 ‘큰 그림’을 볼 수 있어야 합니다.

A. ‘큰 그림’ 보기

체스를 두고 있는 상황을 상상해봅시다. 말을 이동시키기 전에 당신은 우선 전체 판의 흐름을 볼 수 있어야 합니다. 웹사이트를 운영하는 것도 크게 다르지 않습니다. 당신이 진정으로 웹사이트의 ‘큰 그림’을 보지 못한다면 페이지를 바꾸거나 새로운 테스트를 만드는 것은 아무런 의미가 없습니다.

당신이 이 ‘큰 그림’을 보기 위해선 세가지를 알고 있어야 합니다.

a_1_hotjar_way.png
드라이버, 배리어, 훅은 ‘큰 그림’을 볼 수 있게 해줍니다.

1. 드라이버 – 방문자들의 의도를 알아내기

드라이버: 몰이꾼 정도로 번역 가능합니다. 방문자들을 움직이게 하는 동인, 그들의 의도에 대한 비유적 표현이라고 생각할 수 있습니다. 역주.

당신의 방문자들에게 그들이 무엇을 찾고 있는지, 그들이 왜 그것을 원하는지를 ‘그들만의 언어’로 표현하도록 부탁해보세요. 그들의 대답은 강력한 인사이트를 가져다 줄 것입니다. 그리고 그들이 이용하고 있는 언어와 정확하게 같은 언어를 이용하도록 노력하세요. (사용자들이 웹사이트에 대해 사용하는 용어, 단어와 웹사이트를 운영하는 이들이 사용하는 용어, 단어가 완전히 같아야 한다는 것을 의미합니다. 역주) 그렇게 되면 방문자들은 웹사이트의 컨텐츠와 인터페이스, 그리고 웹사이트가 제공하는 사용자 경험(UX: User Experience)에 친근함을 느끼게 될 것입니다. 뿐만 아니라 사용자들의 의도를 이해하게 되면 중요한 셀링 포인트에 더 높은 우선순위를 둘 수 있게 됩니다.

이상의 과정을 다 끝냈다면, 마지막으로 방문자들에게 어디에서 당신의 웹사이트에 대해서 알게 되었는지 물어보세요. 이 것은 당신이 새로운, 혹은 생각치도 못했던 채널을 발견하고 이를 통해 성장할 수 있도록 해줄 것입니다.

드라이버 사용의 예:

  • 어느 한 소프트웨어 리뷰 사이트에서는 대다수 방문자들이 자신이 스타트업에 속해있고, 그 이전까지 자신들이 찾고 있던 소프트웨어를 한번도 사용해보지 못했다는 것을 고백했습니다. 이런 정보를 토대로 웹 사이트의 주인은 소프트웨어의 인트로 가이드를 서비스하고 스타트업을 타게팅하는 새로운 전략으로 잠재 고객들을 발굴해낼 수 있었습니다. (원문에서는 리드(Lead) 제너레이션을 증가시킨다는 표현을 썼습니다. 리드 제너레이션이란 지금 구매하지 않더라도 이후에 상품을 구매할 가능성이 높은 잠재 고객들을 발굴해내는 마케팅 기법을 의미합니다. 역주.)

  • 헤드폰은 판매하던 한 이커머스(e-commerce) 사이트는 한 음악 포럼(게시판)에 그들의 제품에 대한 내용이 올라와 있는 것을 발견했습니다. 이들은 이 포럼이 매우 효과적인 광고 채널이 될 수 있다는 것을 깨닫게 되었습니다.

드라이버를 보여주는 핫자르 도구들:
투표하기(Polls), 서베이(Surveys), 사용자 테스터 채용하기(Recruit User Testers)

2. 배리어(장벽) – 장벽이 높은 단계를 찾아내세요.

방문자들이 자꾸 웹사이트를 떠나는데 어디서 방문자들이 떠나는지, 그리고 왜 그들이 떠나는지 이해하지 못 한다면 웹사이트의 경험성과 핵심 요소들을 절대 개선할 수 없습니다. 이젠 더 이상 생각나는대로 버튼을 바꾸거나 페이지 레이아웃을 바꾸지 마세요. 그 대신, 웹사이트의 경험성을 가로막고 있는 장벽이 어디에 있는지 먼저 주의깊게 살펴보세요.

항상 가장 큰 장벽에 제일 먼저 초점을 맞추세요. 당신의 가장 ‘핫한 기회’는 언제나 가장 트래픽이 많이 발생하는, 그리고, 가장 이탈이 많이 발생하는 페이지(혹은 단계)에서 생겨납니다. 바로 그 지점에서부터 시작해보세요 🙂

배리어 이용의 예:

  • 클라우드 호스팅 서비스는 떠나는 고객들이 대부분 월 이용요금이 너무 비싸다고 느낀다는 것을 알게되었습니다. 이런 깨달음을 엊고 나서 그들은 왜 이용 요금이 경쟁 서비스보다 높은지 합리적으로 설명하는데 많은 리소스를 투자했고, 경쟁서비스들이 사실은 ‘눈에 보이지 않는 숨겨진 비용’을 추가로 만들어 낸다는 사실을 알렸습니다. 이를 통해 이들은 더 많은 사용자들을 모을 수 있었습니다.

  • 꽃을 파는 한 이커머스 사이트는 고객들이 체크아웃 페이지에서 브랜드에 대해 신뢰하지 못해 계속 이탈한다는 것을 발견했습니다. 그들은 고객의 신뢰를 얻기 위해서 사용자 리뷰의 중요성을 높이고 자신들의 웹 서비스가 신뢰할 만한 사이트로 선정되었다는 것을 알리는 로고(‘featured in’ logos)를 페이지 상단에 높이 배치했습니다.

  • 어떤 SaaS 툴 (Software as a Service: 고객들이 인터넷을 통해서 접근할 수 있는 소프트웨어 어플리케이션을 의미. 클라우드 서비스 종류의 하나. 역주)을 이용하는 고객들은 오랫동안 회원가입과 로그인 화면을 자주 혼동해왔습니다. 이 사실을 안 운영자들은 제목과 레이블을 바꾸었고, 사용자들의 이탈률을 현격하게 줄일 수 있었습니다.

배리어를 보여주는 핫자르 도구들:
힛맵(Heatmaps), 사용자 인터랙션 다시보기(Visitor Playback), 전환 퍼넬(Conversion Funnels), 피드백 투표(Feedback Polls), 서베이(Surveys), 사용자 테스터 채용하기(Recruit User Testers).

3. 훅 – 설득력있는 요소들을 찾아내기

훅: 갈고리를 의미합니다. 여기선 사용자들을 갈고리에 걸어서 끌어당길 수 있는 요소들을 비유적으로 표현했습니다. 역주.

당신의 웹사이트를 방문하는 고객들이 진정으로 구매하는 것은 무엇입니까? 그들이 정말 제품이나 서비스를 구매하고 있습니까? 그들이 당신이 제공하는 새로운 라이프 스타일에 돈을 내고 있습니까?

당신의 고객들, 그리고 잠재적인 고객들을 진정으로 설득하고 있는 것이 무엇인지 이해하는 것이 바로 더 많은 고객들을 끌어들일 수 있는 가장 빠른 방법입니다. 이런 이해가 그들을 어떻게 지속적으로 방문하게 할 수 있을지, 어떻게 더 많이 방문하게 할 수 있을지 깨닫게 해줄 것입니다.

훅을 보여주는 핫자르 도구들:
투표하기(Polls), 서베이(Surveys), 사용자 테스터 채용하기(Recruit User Testers).

B. 핫자르 액션 플랜의 9가지 스텝

  1. 트래픽이 높거나, 반송률 (웹사이트에 접속한 뒤 첫 페이지에서 다른 페이지로 이동하지 않고 바로 나가는 비율. 역주.)이 높은 페이지에 힛맵(Heatmap)을 세팅하세요.
  2. 트래픽이 높은 랜딩 페이지에 피드백 투표하기(Feedback Polls) 기능을 이용해서 ‘드라이버(Driver)’들을 발견하세요.
  3. 이메일을 통해서 고객 서베이(Survey)를 하세요.
  4. 퍼넬(Funnel)로 웹사이트의 가장 큰 배리어가(Barrier) 뭔지 확인하기.
  5. 배리어 페이지들에 피드백 투표(Feedback Polls) 세팅하기.
  6. 힛맵을 베리어 페이지에 세팅하기.
  7. 방문자 인터랙션 다시보기(Visitor Playback)로 배리어 페이지의 어느 지점에서 방문자가 떠나는지 확인하기.
  8. 사용자 테스터 채용하기(Recruit User Testers)로 드라이버와 배리어 발견하기.

1. 트래픽이 높거나, 반송률이 높은 페이지에 힛맵(Heatmap)을 세팅하세요.

  • 왜 하나요?: 트래픽이 높거나 반송률(bounce rate)이 높은 페이지들은 더 많은 사용자들을 끌어들일 수 있는 가장 큰 기회들을 가지고 있습니다. 이런 페이지들에 힛맵을 세팅하면, 방문자들이 웹페이지에 어떻게 묶이게 되는지, 어떻게 하면 계속 더 많은 방문자들을 끌여들여야 할지 깨달을 수 있습니다.
  • 어떻게 하나요?: 트래픽이 높은 페이지에 힛맵을 설정하고 ‘quick 8 Hotjar Heatmap tests’ 를 실행하세요. 당신의 웹페이지에서 가장 흔하게 발생하는 문제가 무엇인지, 해결책은 무엇인지 알려줄 것입니다.

b_1_hotjar_move_heatmap.png
핫자르의 힛맵은 방문자들의 행동을 보여주고, 반송률을 낮출 수 있는 힌트를 줄 것입니다.

2. 트래픽이 높은 랜딩 페이지에 피드백 투표하기(Feedback Polls) 기능을 이용해서 ‘드라이버(Driver)’들을 발견하세요.

  • 왜 하나요?: 당신의 가장 큰 방문자 풀을 인터뷰함으로써, 방문자들이 당신의 웹사이트를 방문하는 이유가 뭔지 알 수 있게 될 것입니다. 방문자들이 당신의 사이트를 방문하는 이유를 점점 더 깊이 파보세요. 만약 당신이 게임 사이트를 운영한다면, 게이머들이 게임을 하는 동기가 무엇인지 물어보는 것이 여기에 해당할 것입니다. (돈을 위해서? 재미를 위해서? 아니면 친목도모를 위해서?) 이런 과정은 당신의 사이트 디자인과 텍스트를 좀 더 연관성있게, 또한 좀 더 설득력 있게 만들 수 있도록 도와줄 것입니다.
  • 어떻게 하나요?:
    1. “[서비스 혹은 상품]을 찾는 이유가 무엇인가요?”
    2. “이 페이지에서 빠져있는게 있을까요?”
    3. “처음에 우리에 대해서 알게 되었을때 어떤 얘기들을 들으셨나요?”
  • 방문자들이 정해져있는 답들을 고르도록 강제하지 마세요. 그 대신에 자유롭게 답을 서술 할 수 있도록 해주세요. 그리고 답변들을 이용해서 ‘드라이버’ 워드 맵을 만들어보세요. 아래에는 핫자르 팀이 Hotjar.com 을 방문하는 방문자들을 대상으로 “간단한 질문 – 핫자르가 어떻게 당신의 삶을 더 쉽고, 더 낫게 만들어주고 있나요?” 라는 질문을 던지고 그 응답으로 만든 워드 맵입니다. This should not replace reading carefully through all responses you receive.

b_2_hotjar_feedback_cloud.png
‘드라이버’ 워드 맵은 방문자들이 당신의 웹사이트를 방문하도록 만드는 것이 무엇인지 보여주는 가장 좋은 방법입니다.

3. 이메일을 통해서 고객 서베이(Survey)를 하세요.

  • 왜 하나요?: 어쩌면 드라이버, 배리어, 훅을 한번에 찾는 가장 좋은 방법은 당신의 고객들에게 직접 답을 얻는 것일지도 모릅니다.
  • 어떻게 하나요?: 다음 4개의 open ended 질문을 포함한 서베이를 만드세요.
    1. “당신이 [서비스 혹은 상품]을 찾게 된 동기는 무엇입니까? 이 것이 당신의 삶을 어떻게 개선할 수 있을지 가능한 자세히 설명해주세요.”
    2. “당신이 [액션 e.g. 구매 / 가입]을 하게 만든 것은 무엇이었습니까? 생각나는대로 적어주세요.”
    3. “당신의 결정을 돕기 위해 저희가 할 수 있는 일이 무엇이 있을까요?”
  • 가치있다고 생각되는 질문들을 좀 더 추가하세요. 하지만 7, 8개를 넘지는 마세요. 아래가 좋은 예가 될 수 있습니다.
    1. “당신이 어떤 사람인지 알려주실 수 있으신가요? e.g. 저는 30살의 차와 포커 도박? 를 사랑하는 남성 디자이너입니다”
    2. “친구분들에게 저희 서비스를 소개해주신다면 어떻게 소개할 수 있을까요?” (이런 질문은 당신의 웹사이트를 위한 훌륭한 추천사가 될 수 있습니다!)
  • 답변을 해주시는 사용자들에게 추첨을 해서 선물을 주는 것이 많은 답변을 이끌어내는 인센티브가 될수 있습니다. (짧은 데드라인을 만들면 빠른 답변을 얻는데 도움이 됩니다.)

b_3_hotjar_survey.png
고객 서베이는 드라이버와 배리어와 훅을 한번에 알려주는 좋은 수단입니다. 이것은 핫자르에서 사용할 수 있는 가장 가치있는 툴중 하나입니다.

4. 퍼넬(Funnel)로 웹사이트의 가장 큰 배리어가(Barrier) 뭔지 확인하기.

퍼넬: 직역하면 깔때기라는 뜻입니다. 왜 깔때기라고 하는걸까요? 여기에서는 가장 트래픽이 높은 페이지에서부터 방문자들이 어떤 페이지로 흘러가는지 추적하는 통로의 역할을 하기 때문에 깔때기라는 단어를 사용하는 것 같습니다. 역주.

  • 왜 쓰나요?: 우리는 한번에 바꾸기엔 지나치게 많은 부분을, 과도하게 많이 바꾸려고 하곤 합니다. 이런 실수를 막기 위해서 핫자르에서는 퍼넬(Funnel)이라는 툴을 이용합니다. 퍼넬을 만들면 가장 방문자들을 많이 잃어버리게 되는 곳이 어디인지, 그리고 어떻 작업을 가장 먼저 해야하는지 쉽게 인지할 수 있게 됩니다.
  • 어떻게 쓰나요?: 퍼넬 사용에서 가장 중요한 것 중 하나는 퍼넬을 ‘뒷쪽으로 쭉 이어서’ (원문엔 ‘backward’라고 써놨습니다. 역주) 만들어 놓는 것입니다. 먼저 당신에게 가장 중요한 목표가 무엇인지 스스로에게 한번 물어보세요. 회원가입입니까, 아니면 주문입니까? 이 질문에 대한 나름의 답을 얻었다면 가장 트래픽이 많이 몰리는 페이지에서부터 뒷쪽으로 쭉 퍼넬을 심어두세요. 일반적인 규칙은 당신이 웹사이트에 세운 각각의 목표 지점마다 퍼넬을 세팅해놓는 것입니다.
  • 각 퍼넬은 당신이 만들어놓은 퍼넬에 ‘첫 발자국’을 남긴 방문자들의 데이터만 보여주게 될 것입니다. 따라서, 만약 당신의 웹사이트에서 주로 트래픽을 발생시키는 소스가 2개라면 (이를테면 홈페이지와 랜딩 페이지) 각 소스를 분리하여 퍼넬을 만들어 놓는 것이 좋을 것입니다.
  • 아래가 퍼넬의 용례입니다.
    • 이커머스: 홈페이지 > 상품 페이지 > 카트 > 결제 > 결제완료 페이지
    • 뉴스나 블로그: 홈페이지 > 기사 페이지 > 구독 페이지 > 구독완료 페이지
    • 웹앱: 홈페이지 > 체험판 등록하기 페이지 > 인터페이스(웹앱) > 업그레이드 페이지 > 업그레이드 완료 페이지
    • 리드 제네레이션: 카테고리 페이지 > 양식을 포함한 랜딩 페이지 > 완료 페이지 (리드 제너레이션이란 지금 구매하지 않더라도 이후에 상품을 구매할 가능성이 높은 잠재 고객들을 발굴해내는 마케팅 기법을 의미합니다. 역주.)

b_4_hotjar_funnel.png
가장 배리어가 높은 지점에서 부터 조사해보세요. 위의 이미지에서는 ‘랜딩 페이지’ 단계가 이에 해당합니다.

5. 배리어 페이지들에 피드백 투표(Feedback Polls) 세팅하기.

  • 왜 하나요?: 이쯤이면, 지금 당신의 웹사이트에서 가장 많은 방문자들을 잃고 있는 곳이 어딘지 알게 되셨을 겁니다. 이젠 그들이 떠난 이유에 대해서 들어볼 시간입니다.
  • 어떻게 하나요?: 방문자들을 잃고 있는 페이지들을 타겟으로 피드백 투표를 만드세요. 이 투표는 방문자가 페이지를 나가려고 할때, 혹은 방문자가 페이지의 절반 정도를 스크롤해서 내려봤을 때 뜨도록 설정됩니다. 만약 응답률이 충분하지 않다면 웹 페이지를 들어오고 10초 후에 투표가 뜨도록 설정을 변경하세요.
  • 질문 템플릿은 3가지입니다.
    1. “간단한 질문 – 만약 당신이 [액션 e.g. 가입 / 구매]을 하지 않기로 결정했다면, 무엇이 당신을 멈추게 한 요소였나요?”
    2. “간단한 질문 – 우리 웹사이트에 대해서 걱정하고 있거나 신뢰하지 못하고 계신 부분이 있나요?”
    3. “간단한 질문 – 우리 페이지에 어떤 것이 빠져있다고 느끼시나요?”
  • 효과적인 결과를 얻기 위해서 위의 질문 타입들을 번갈아 가면서 내보내도록 설정하는 것을 고려해보세요.

b_5_hotjar_feedback_poll.png
가장 배리어가 높은 페이지에 피드백 투표를 만들어 놓으면 해당 페이지에 있어서 당신이 그동안 간과했었던 이슈가 무엇인지, 고객들이 가장 우려하고 있는 것이 무엇인지 알 수 있게 됩니다.

6. 힛맵을 베리어 페이지에 세팅하기.

  • 왜 하나요?: 이탈율이 높은 페이지에 힛맵을 생성하면 굉장한 인사이트를 얻을 수 있습니다. 힛맵은 방문자들이 어떻게 페이지와 인터렉션(상호작용: 클릭, 탭, 마우스 움직임, 스크롤…)하고 있는지 빠르게 가시화해줍니다. 이는 곧 방문자들이 진정 보고 있는 것이 무엇인지, 그들이 무시하고 있는 것은 무엇인지 알 수 있게 해줄 것입니다. 이런 정보들은 테스트를 만들거나, 페이지를 개편하는데 큰 도움이 됩니다.
  • 어떻게 하나요?: 힛맵이 세팅되고 나면, ‘quick 8 Hotjar Heatmap tests’를 사용해 가장 흔하게 발생하는 문제는 무엇인지, 해결책은 무엇인지 찾아보세요.

b_6_hotjar_scroll_heatmap.png
당신의 방문자들이 무엇을 보고 있는지, 핫자르 힛맵을 이용해 확인하세요.

7. 방문자 인터랙션 다시보기(Visitor Playback)로 배리어 페이지의 어느 지점에서 방문자가 떠나는지 확인하기.

  • 왜 하나요?: 방문자 인터랙션 다시보기는(Visitor Playback) 방문자의 신발에 작은 카메라를 달아 놓는 것이라고 이해하면 됩니다. 웹사이트를 떠난 고객의 녹화된 화면을 되돌려보면 당신의 페이지에 방문자가 어떻게 반응했는지 확인할 수 있게 됩니다. 혹시 방문자들이 어떤 단계에 정체되어 있지는 않은가요? 혹시 그들이 페이지를 너무 빨리 떠나고 있지는 않은가요?
  • 액션플랜 5와 액션플랜 6을 통해서 우리는 투표하기와 힛맵을 사용한 결과를 얻게 되었습니다. 이제는 ‘방문자의 관점에서 보기’에 대해서 잘 이해하게 되셨을 겁니다. 방문자의 관점에서 그들에게 ‘공감(empathizing)’함으로써 더 나은 의사결정을 내리고, 배리어가 높은 페이지를 어떻게 바꾸어야 할지, 어떤 테스트를 만들어야할지 깨닫게 될 것입니다.
  • 어떻게 하나요?: 올바른 녹화 비디오를 찾기 위해선 검색 필터의 ‘EXIT PAGE’ 항목에 배리어가 높은 웹페이지의 URL을 입력하면 됩니다. 그리고 나서는 준비해놨던 팝콘을 뜯으시면 됩니다 🙂

b_7_hotjar_visitor_playback.png
방문자 인터랙션 다시보기는 방문자의 신발에 카메라를 달아놓고 웹사이트에서 그들의 관점으로 경험성을 파악할 수 있게 해줍니다.

8. 사용자 테스터 채용하기(Recruit User Testers)로 드라이버와 배리어 발견하기.

  • 왜 하나요?: 사용자 테스팅은 사용자들이 당신의 웹사이트를 이용하는 동안 그들을 관찰하고 그들의 행동을 코멘트하는 과정입니다. 이 단계에서 당신은 이미 대강의 ‘큰 그림’을 그리게 되었을 것입니다. 하지만 사실, 그 어떤 작업도 사용자 한명, 한명을 인터뷰하고 상대하는 것만 못할 것입니다. 이런 작업은 꽤나 공수가 많이 들고 지루할 것 처럼 보이지만 생각보다 꽤나 즐겁고 또 굉장한 인사이트를 줄 수 있는 작업입니다.
  • 어떻게 하나요?: 가장 트래픽이 많이 발생하는 랜딩 페이지에 리크루팅 양식(recruit form)을 세팅하세요. 이 프로그램에 참여하는 방문자들에게는 약간의 인센티브를 제공할 수 있어야 합니다. (e.g. 무료 컨텐츠, 현금 혹은 아직 출시하지 않은 특정 기능에 대한 우선권 등)
  • 채용할 사용자를 선택하세요 – 5명 정도의 사용자 테스터를 채용하는 것으로도 충분합니다. 그들에게 이메일을 통해서 연락하고 ‘화면 공유’를 할 날짜와 시간 약속을 잡으세요. 화면 공유를 하기 위해서 스카이프(Skype)나 고투미팅(GoToMeeting), 구글 행아웃(Google Hangout) 같은 미팅 툴을 이용할 수도 있을 것입니다.
  • 목표를 준비하고, 완료하고자 하는 단계들을 나열해보세요. 숨겨진 장벽들을 확인하기 위한 몇개 질문들을 준비하는 것도 좋을 것입니다.

b_8_hotjar_recruit_user_testers.png
화면 공유를 통한 사용성 테스트를 위해 방문자와 사용자들을 채용하세요.

b_8_usability_graph.png
5명의 유저 테스트 만으로도 80%의 문제들을 잡아낼 수 있을 것입니다. (출처: Jakob Nielsen)

9. 가장 성공적인 페이지에서 피드백 투표로 ‘훅(Hook)’을 발견하기

  • 왜 하나요?: 좀 더 방문자들을 많이 끌어들이고 싶다면, 사용자들에게 그들을 설득했던, 그들에게 모티베이션이 된 요소들이 무엇이었는지 물어볼 필요가 있습니다. 이런 과정은 당신의 웹사이트에서 방문자들을 잡아당길 ‘훅’이 무엇인지 이해할 수 있게 해줄 것입니다. 뿐만 아니라, 이런 요소들을 강조하고 더 자세히 설명할 수 있도록 사이트를 개선할 수 있게 해줄 것입니다.
  • 어떻게 하나요?: 아래의 워드 클라우드는 핫자르의 ‘훅’에 대한 피드백 투표 결과를 보여주는 것입니다. 이 결과로부터 친구들의 추천과, 통합된 툴 세트, 그리고 핫자르의 가격 정책이 굉장히 설득력 있는 요소였음을 한눈에 알 수 있습니다. 저희는 이 요소들을 앞으로 핫자르가 만들 캠페인들에 포함시킬 뿐만 아니라, 이를 이용할 수 있는 제품들을 개발시킬 것입니다. (e.g. 대시보드(dashboard)에 추천인 정리해서 보여주기)

b_9_hotjar_feedback_cloud.png
핫자르의 ‘훅’을 보여주는 워드 클라우드(Word Cloud).


9 단계를 모두 마쳤습니다. 이제 뭘 해야하나요?

이제 당신의 사이트를 개편할 시간입니다. 참고로, 가능하다면 개편한 웹사이트와 이전 웹사이트의 트래픽을 나누어 변화의 영향에 대해서 테스트해보고 분석하는 것이 좋습니다.

개편된 웹사이트에서 방문자들의 드라이버, 배리어, 훅에 대해서 알고 싶다면, 다시 액션플랜 1으로 돌아가 아직 숨어있는 새로운 기회들을 찾아보세요!

제가 9 단계를 잘 마쳤는지 어떻게 알 수 있을까요?

  • 당신의 웹사이트가 방문자들의 드라이버와 잘 맞는지 확인해보세요. 방문자들이 이용하는 언어, 용어와 당신이 이용하는 언어나 용어가 일치해야 합니다. 또 사용자가 사이트에 도달하고나서 그들이 찾고 있는 것이 어디있는지 바로 발견할 수 있어야 합니다.
  • 방문자들을 우려하게 하고, 주저하게 하고, 그들의 사용성에 문제를 만드는 배리어들을 최소화했는지 살펴보세요. 웹사이트의 컨텐츠를 좀 더 명확하고 분명하게 만들었다면, 그리고 당신이 웹사이트를 어떻게 더 쉽게 이용하도록 할지 고민하고 있다면, 퍼넬을 통과하는 방문자들의 수가 늘어났다는 것을 확인할 수 있을 것입니다.
  • 방문자들을 끌어당기고, 그들을 효과적으로 설득할 수 있는 요소들을 지속적으로 사용함으로써, 훅의 효과를 극대화시키고 있는지 살펴보세요. 다시 한번 강조하지만, 당신은 고객들이 서베이에서 이용하는 언어나 단어들을 그대로 웹사이트에서 사용하고 있어야 합니다.
  • 위의 세 항목을 모두 달성했다면, 당신은 성공적으로 사용자 경험을 개선한 것입니다. 곧 사용자들이 예전보다 당신의 사이트에서 더 많은 시간을 보내고, 더 자주 방문하고 있다는 것을 확인할 수 있게 될 것입니다. 운이 좋다면 방문자들이 자신의 친구들에게 웹사이트를 추천할 수도 있겠죠 🙂

레저큐 인턴기 4편 – 님과 함께

레저큐에는 직급과 나이에 상관 없이 직원들 간에 ‘님’ 호칭을 쓰고 항상 높임말을 사용한다. 자유롭게 소통할 수 있는 수평적인 조직 문화를 만들기 위해서이다.

나이와 직급이 천차만별인 50명 규모의 조직에서 상하에 상관 없이 서로 ‘님’이라고 부르는 것은 생각만큼 그렇게 쉬운 일만은 아니다. 하지만 ‘님’ 호칭을 쓰는 것은 아주 중요한 규칙이다. 직원들간의 원활한 소통과 창의적인 아이디어가 그 무엇보다도 중요한 스타트업에서 호칭은 조직 문화와 직결되는 문제이자, 조직의 근간이 되는 철학과도 밀접하게 엮여져 있는 문제이기 때문이다.

잡음은 두배로, 메시지는 반으로

우리는 관계의 상하를 따지는 문화에 익숙하다. 자신을 소개할 때 나이를 먼저 이야기 하는 것이 당연하고, 조직이나 단체에서 누군가를 부를 때 직급이나 호칭을 붙여 부르는 것이 더 자연스럽다. 윗 사람은 존경을 받고 아랫 사람은 존중을 받는 이런 문화는 유서 깊고 아름다운 것으로 인식되어 왔다.

그러나 때로 이런 문화가 조직원들간의 소통을 방해하기도 한다. 중요한 정보가 확산되지 않고, 창의적인 의견들이 빠르게 제시되지 않으며 때로는 위화감이 조성되기도 한다. 결국 이러한 문제점들이 조직에 아주 큰 비용으로 돌아오는 경우가 많다. (우리는 이런 사례들을 많이 보아 왔다.)

meeting-image
회의 때의 모습을 생각해보자. 어떤 회의 모습이 떠오르는가? 상석에 앉은 사람이 일장연설을 펼치는 동안 직위에 따라 도열한 아랫 사람들이 열심히 고개만 끄덕이는 회의? 아니면 활발하게 서로 토론하고 직급, 나이의 고하에 상관없이 누구나 자유롭게 발언하는 회의?

현대 경영학의 아버지, 피터 드러커는 “명령 계층 수를 최소화해서 조직을 가능하면 ‘수평적’으로 만드는 것이 조직구조의 원칙”이라고 말했다. 모든 명령의 전달 단계마다 잡음은 두 배로 늘어나고, 메시지는 반으로 줄어들기 때문이다. 즉, 조직의 계층을 최소화해야 합리적인 의사결정이 이루어지고, 효과적인 소통이 이루어 질 수 있다는 것이다.1)

peter-drucker
현대 경영학의 아버지, 피터 드러커. 그는 노동자들이 지식으로 생산활동을 하는 지식 사회에서는 수평적 조직 문화가 중요하다고 주장했다.

이런 철학은 기업들로 전파되었고, 특히 IT 스타트업들을 중심으로 수평적 조직문화를 극단적인 형태로 운영하는 사례들이 나타나기 시작했다. 가장 잘 알려진 사례 중 하나는 Half-Life, Counter-Strike, Portal 의 제작사이자 Steam이라는 게임 배급플랫폼으로 유명한 Valve라는 회사이다. 이 회사는 최소한의 경영진만 남겨두고 조직의 구조와 관리자 직위, 직급 자체를 완전히 없애버렸다. 심지어 팀의 조직도, 직원들이 스스로 하고 싶은 프로젝트에 합류해서 팀을 정할 수 있도록 했다.2)

valve-corporation
밸브 사의 오피스 모습. 이 회사에는 직급도 없고 심지어 정해진 팀도 없다. (이미지 출처: The Wall Street Journal, Who’s the Boss? There Isn’t One.)

이런 문화가 Valve 사에 가져온 효과는 명확하다. 직원들 개개인이 가지고 있는 권한, 특히 결정과 판단의 자유가 대폭 확장되고, 직원들이 얼마든지 창의성을 발휘해서 제품을 개발 할 수 있게 되었다. 실수가 있더라도 빠르게 개선되고, 서로의 실수나 실패가 감추어지는 일이 적어졌다. 직원 개개인의 의견과 동기를 존중하는 수평적인 구조의 회사 문화가 탁월한 성과로 이어졌다.

IT 스타트업의 ‘기업문화’에 대해

물 건너 우리나라에서도 IT 기업들을 중심으로 나이와 직급에 상관 없이 호칭을 통일하고, 나아가서 수평적인 조직 문화를 추구하려는 시도들이 일어나고 있다. 네이버에서는 직급 대신에 ‘님’ 호칭을 쓰고 카카오에서는 서로를 영어 이름으로 부른다. 물론 직원들끼리는 직위와 나이에 관계 없이 항상 높임말을 사용한다.

레저큐와 같은 IT 스타트업에서는 수평적 조직 문화가 더욱 더 중요하다. 스타트업에서는 조직원 개개인의 전문성과 생산성이 굉장히 중요한 문제기 때문이다. 팀의 규모가 작을수록 개개인이 가지고 있는 전문성과 능력을 극대화 시키는 것이 중요한데 그러기 위해서는 모든 조직원들이 동등한 위치에서 의사를 피력하고, 자신의 가지고 있는 전문화된 지식을 최대한으로 활용 할 수 있어야 한다.

물론 수평적 조직 문화가 회사의 성과를 보장하는 ‘만능 해결책’은 아니다. 단점 역시 명확하다. 2013년 미디어를 떠들석하게 했던 valve 사의 집단 해고 사건이 이를 보여준다. (이 때 퇴사했던 이들은 valve 사는 아무도 ‘인기 없는 일’을 맡아 하지 않으려고 하고, 오히려 은밀한 내부정치가 횡횡하는, ‘고등학교’와 같은 조직이었다고 주장했다. 3)) 게다가 수평적 조직문화는 형성하기도 유지하기도 어렵다. 누가봐도 수직적인 의사결정이 이루어지고, 소통이 종적으로 일어나는 조직에서 직원들이 서로를 ‘님’이라고 부른다거나 높임말을 사용하는 것이, 진정으로 소통의 장벽을 제거하는 수평적 조직을 만들 수 있는 것이 아닌 것이다.

lol-asking-parent-anbu
모두가 ‘님’이라는 존칭을 쓰는 완전한 수평 조직, 게임 세계. 그러나 ‘님’이라는 호칭이나 수평적 문화를 만들겠다는 것이 중요한게 아닌 것 같기도…

하지만 수평적이고 합리적인 조직은 젊은 구직자들에게 매력적이다. 많은 청년들이 자신의 의사가 존중받고, 자신의 능력을 자유롭게 발휘할 수 있는 조직에서 일하고 싶어한다. 그 동안 연봉과 복지가 회사를 결정하는데 가장 중요한 요소였다면 이제는, 젊은 인재들에게 조직이 얼마나 수평적이고 민주적인지도, 취업 하고 싶은 기업을 정하는 중요한 지표 중 하나가 된 것이다.

내가 인턴을 하면서 경험한 레저큐는 수평적이고 자유로우며 합리적인 기업문화를 만들기 위해서 노력하고 있는 회사였다. 생각보다, 이렇게 즐겁게 일할 수 있고, 직원 개개인이 존중받는 다는 느낌을 받게 해주는 조직은 흔치 않다. 물론 이런 기업문화를 계속 유지하고 가꾸어나가기는 쉽지 않을 것이고, 회사의 규모가 점점 커질 수록 중대한 도전들에 직면하게 될 것이다. 조직원들이 함께 그 도전들을 잘 극복해나가고 좋은 문화들을 계속 가꾸어나면서 성장하는 기업이 될 수 있으면 좋겠다. 🙂

References

  1. 조영탁, “수평조직을 구축하라!”
  2. 밸브 신입사원 안내서
  3. 노트A – “밸브 수평 관리 구조의 함정”

by EastskyKang