Browse Tag

가자고

레저큐 인턴기 7편 – 여자 개발자, 남자 디자이너를 위하여

Culture does not make people. People make culture. If it is true that the full humanity of women is not our culture, then we can and must make it our culture.
문화가 사람을 만드는 것이 아닙니다. 사람이 문화를 만듭니다.

Chimamanda Ngozi Adichie, We Should All Be Feminists

내가 다닌 학부는 남학생 140명, 여학생이 10명의 무려 14:1라는 경이로운 성비를 자랑한다. 머릿 속에 작은 방을 그려놓고 거기에 사람 15명을 들여 보낸다면 그 중 단 한명이 여자라는 것이다.

설상가상으로 우리 학부가 위치했던 신공학관은 학교 전체에서 제일 남녀 성비가 낮다는 기계공학과, 전기공학과, 컴퓨터공학과가 모여있는 건물이었다. 산 꼭대기에 위치하고 있어서 다른과 학생들이 드나들 일도 없을 뿐더러 모든 학과 수업이 이 건물에서만 열리니, 수업이 끝나고 사방에서 체크무늬 셔츠에 두꺼운 안경을 낀 공돌이들이 쏟아져 나오는 광경은 가히 진풍경이라고 할만하다.

japan_eng_student_are_on_check_shirts
단정하게 교복을 입은 공대생들. 체크무늬 셔츠와 두꺼운 안경은 공대생들의 교복이다.

누군가 그랬다. 세상의 절반은 남자고 다른 절반은 여자라고. 그런데 도대체 무엇이 잘못된걸까? 고등학교-대학교-병역특례에 이르는 지난 10년 기간 동안 단 한번도 여자가 많은 조직을 경험해 본 적이 없다. 혹시 내가 뭔가를 잘못하고 있는 것은 아닐까? 세상에 남자와 여자의 수가 같은 집단이라는 게 존재하기는 하는걸까?

성비 균형의 꿈

it_did_happpen

놀랍게도 레저큐에 입사 하면서 나는 그런 조직을 실제로 볼 수 있게 되었다. 여성 직원과 남성 직원의 수가 거의 1대 1인 조직이 실존하고 있었던 것이다.

사실 이런 성비가 가능한 것은 레저큐의 직원들이 맡고 있는 역할과 업무가 정말 폭넓기 때문이다. 개발에서부터 디자인, 상품 운영, CS, 마케팅.. 업무의 폭이 넓으니 직원들의 연령, 성별도 다양할 수 밖에 없다. 그런데 이렇게 1대 1로 균형 잡힌 구성원들의 성비는 남성, 여성 모두에게 어필 할 수 있는 상품들을 판매하는 이커머스 서비스에는 매우 중요한 요소이기도 하다.

남성과 여성은 세상을 인지하고 바라보는 관점, 관심사, 구매 성향이 다르다. 남성 소비자가 서비스에 요구하는 것과 여성 소비자가 서비스에 요구하는 것은 크게 다를 수 있다. 서비스를 운영하는 사람들은 남성 소비자와 여성 소비자 모두를 잡기 위해서 두 관점, 모두에서 서비스를 바라볼 수 있어야 한다. 이를 달성하기 위한 가장 좋은 방법은 당연 구성원에 비슷한 수의 남성과 여성을 두는 것이다.

여성과 남성의 관점 차이에서 생기는 토론과 합의는 더 훌륭한 아이디어를 만들어 낼 수 있는 힘의 원천이 되기도 한다. 서로 다른 관점에서 나온 의견이 때로는 충돌하기도 하고, 때로는 보완되기도 하면서 더욱더 멋진 아이디어가 탄생한다.

실리콘 밸리의 기업들이 성별, 인종, 문화, 전문분야 등에서 다양성을 지향하는 이유도 여기에 있다. 국제적인 서비스, 전 세계 사람들이 이용하는 제품을 만들고 운영하기 위해서는 먼저 서비스를 이용하는 사람들에 대해서 잘 이해하고 있어야 한다. 더불어, 빠르게 변하는 시장에서 끊임 없이 새롭고 멋진 아이디어를 내며 진화할 수 있어야한다. 이를 달성할 수 있는 가장 효과적인 방법은? 바로 기업을 구성하는 구성원의 다양성을 추구하는 것이다.

apple_diversity
애플은 다양성을 모토로 내걸고 있는 회사 중 하나이다. 다양한 인종, 성별, 전공, 문화를 가진 사람들이 애플에서 일하고 있다.

다양성이 비효율을 수반하는가?

어떤 사람들은 이렇게 주장한다. “다양성은 응당 비용을 수반한다. 남성 사원들로 조직된 조직을 상상해보자 이들이 여성을 채용하기 위해서는 기업의 환경, 인프라, 문화를 바꿔야 한다. 이런 비용을 지불하느니 기존에 해왔듯이 남성들로만 기업을 운영하는 것이 더 나을 수도 있다. 그 반대의 경우도 마찬가지이다.”

이들의 말이 맞을 수도 있다. 하지만 레저큐에서 인턴을 하면서 배우게 된 중요한 사실 중 하나는 기업이 성적, 문화적 다양성을 추구하는데 드는 비용보다 그 것을 달성 했을 때 얻을 수 있는 이득이 훨씬 크다는 것이었다.

뿐만 아니다. 다양성의 추구는 기업의 사회적 역할과도 무관하지 않다. 다양한 인종, 그리고 성별, 특히 소수거나 사회적 약자의 위치에 있는 이들에게 기업이 일자리를 제공하고 소득을 분배할 수 있다면 그 어떤 국가적 차원의 지원과 캠페인들이 만들어 내는 것보다 더 큰 효과를 낼 수 있다.

the_more_women_work_the_more_babied_are_born
다양성과 양성평등은 한 커뮤니티, 나아가서 한 사회가 안고있는 골치아픈 문제들을 해결하는 열쇠가 될 수도 있다. (이미지 출처: TechInsider – Norway solved the gender problem that’s creating a crisis in Japan and Korea)

스웨덴의 저명한 통계학자인 한스 로슬링 카롤린스카는 한국을 괴롭히고 있는 저출산과 고령화의 해결책이 페미니즘이 될 수 있다고 주장한다. 실제로 스웨덴은 저출산 문제를 양성평등 확대를 통해서 해결하려는 노력을 펼쳐왔고 이런 문화를 안정적으로 정착시켜 저출산이라는 난제를 멋지게 해결하고 있다.

우리 사회 구성원들의 머리를 아프게 하는 심각한 사회적 문제들을 극적으로 해결할 수 있는 방법이 있다면, 그리고 그 것을 해결하는 것이 아주 사소한 변화에서부터 출발하는 것이라면 이런 문화를 만드는데 투자해야하는 비용은 기꺼이 지불할 만한 것일테다.

옥의 티 찾아내기

우울했던 14대 1 성비의 내 학부시절과 비교했을 때, 레저큐에서의 생활은 분명 훨씬 더 ‘다양’하고 ‘생동감’ 있었다. 이런 점에서 분명 레저큐는 꽤나 모범적인 조직이라고 할 수 있을 것이다. 하지만 여전히 아쉬운 점이 있다. 팀이나 부서별로 떼어놓고 보면 팀을 구성하는 여성, 혹은 남성의 비율이 다소 편중되어 있다는 것이다. 이를테면 레저큐의 개발팀의 개발자 전원은 남성이며, 레저큐의 디자이너들은 한명을 제외하고는 모두 여성이다.

사실 이런 모습은 우리가 소속되어 있는 한국 사회와 정서의 문제와 무관하지 않다. 왜 이공계에는 남성이 압도적으로 많은 것일까. 왜 디자인 학부에는 여학생이 남학생보다 훨씬 더 많은것일까? 정말 남성이 이성적이고 논리적인 사고에 강하고 여성이 섬세하고 감성적인 사고에 강하기 때문일까?

marie_curie
남성은 여성보다 이성적인 사고에 강하며 여성은 남성보다 감성적인 사고에 강하다?

남성과 여성의 능력의 차이에 대해서 생각해보기 이전에 우리 사회가 성역할의 관념에 매몰되어 그런 차이를 만들어내고 있지는 않은지, 혹시 그러한 문제로 인해서 우수한 인재들을 놓치고 더 멋진 기회들을 놓치고 있지는 않은지 되돌아 볼 필요가 있다. 결국 관념과 편견, 문화 그리고 사회적 시스템은 전부 ‘사람’들이 만들기 나름인 것이니까.

여자 개발자, 남자 디자이너를 위하여

레저큐에서 인턴을 하는 동안, 서로 다른 업무를 맡고 있는, 다양한 배경과 성별을 가진 직원들과 소통하며 이 것이 소비자 시장을 대상으로 하는 기업에 강력한 무기가 될 수 있다는 것을 실감했다. 특히 스타트업은 개개인의 개성, 성별, 배경, 그리고 나아가서 문화와 인종의 다양성을 추구할 수 있어야한다.

아쉽게도 다양성의 측면에 있어서 우리는 아직 갈 길이 멀다. 하지만 긍정적인 변화들이 곳곳에서 일어나고 있다. 때로는 이를 추구하고 수많은 담론들을 테이블에 올려놓는 과정에서 수많은 파열음들이 들리기도 한다. 그럼에도 불구하고, 건설적인 담론들이 테이블 위로 올라오고 있다는 것, 사회 구성원들의 생각도 점점 변화하고 있다는 것은 분명 긍정적인 신호일 것이다.

가까운 미래에 여성개발자들과 남성개발자들의 수가 비슷한 개발팀, 그리고 남성디자이너들과 여성디자이너의 수가 비슷한 디자인 팀을 레저큐에서 볼 수 있기를 희망해본다. 어쩌면 기대보다 좀 더 많은 시간이 걸릴 수도 있겠지만 좀 더 다양한 사람들이 일하는 회사, 레저큐는 분명 더 멋지고 생동감 있는 기업이 되어 있을 것이다. 🙂

By EastskyKang

개인취향 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

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

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

레저큐 인턴기 3편 – EastskyKang 님이 leisureq/gajago에 push했습니다.

가자고는 매우 복잡하고 방대한 소프트웨어 시스템이다. 전체 소스코드가 500만 줄에 달하고 서브시스템(sub-system)이 5개가 넘는다. 아무리 뛰어나고 생산성이 높은 개발자라고 하더라도 이렇게 크고 복잡도가 높은 소프트웨어를 혼자서 개발할 수 없을 것이다.

가자고 팀에는 6명의 개발자가 있고, 이들이 협업하며 동시에 가자고 프로젝트를 개발한다. 그런데 여기서 잠깐 생각해보자. 도대체 어떻게 협업해서 소스코드를 작성하는걸까? 개발해야 하는 프로젝트는 하나인데 작업을 하고 있는 개발자는 여러명이다. 제일 먼저 상상할 수 있는 방법은 아마, 아래와 같은 모습일 것이다.

개발자 A와 B가 동시에 어떤 시스템을 개발하고 있는데 이들이 각자 다른 부분을 수정하고 있다. 이 프로젝트는 굉장히 잘 모듈화되어있고, 개발자들은 굉장히 전문화되어서 분업이 잘 이뤄지고 있다. 이들은 업무 시간 동안 열심히 코딩을 하고, 각자 수정한 부분을 퇴근하기 전에 합치는 작업을 수행한다. 야근이 잦지만 뭐, 아직까지는 양호하다.

쉽게 상상할 수 있는 그림이다. 그런데 문제가 생겼다.

어느날 개발자 A와 B가 실수로 동시에 같은 부분을 수정했다. 이때부터 문제가 생긴다. 아무리 비슷한 실력의 개발자더라도 생각하는 방식과 코딩 스타일이 크게 다르다. 이 둘은 서로 ‘충돌’이 난 부분을 모여서 같이 고치기 시작했고, 각자가 ‘같은 일’을 하도록 짠 코드가 완전히 다르게 작성되었다는 것을 깨달았다. 기억을 더듬어 일일히 수정한 코드를 한줄한줄 비교해봐도 어떻게 코드를 합치는 작업을 해야할지 결정하기가 쉽지 않다.

불쌍한 개발자 A와 B가 밤샘 작업을 통해서 수정하고 합치는 작업에 성공했다고 해보자. 그러나, 만약 개발자가 2명이 아니라 5명으로 늘어난다면 어떨까? 전체 시스템의 코드가 100만, 1000만 줄에 육박한다면 어떨까?

panic
다 망해버려라! (이미지 출처: http://www.itworld.com)

개발자의 영원한 친구 Git과 GitHub

다행히도 세상에는 버전 컨트롤 시스템(Version Control System)이라는 훌륭한 것이 존재한다. 이름에서 유추할 수 있듯이, 개발자가 작성한 소스코드의 버전을 관리하고 협업을 가능하게 해주는 시스템이다. Git이나 Subversion, Mercurial 등이 여기에 속한다.

가자고는 근래의 많은 개발 프로젝트들이 그렇듯이, Git이라고 불리는 VCS를 사용하고 있다. 참고로 Git은 Linux의 아버지, Linus Torvalds가 발명한 것이다. 리눅스 커널(리눅스 OS의 핵심부)을 개발할 때 전 세계 수많은 개발자들의 협업과 배포 버전 관리를 할 수 있는 방법이 필요했는데 적당한 방법을 찾지 못해 짜증이 난 Torvalds가 무려 2주만에 Git을 개발했다고 한다.

linus_torvalds_nvidia_fxxk_you
현존하는 가장 위대한 프로그래머, 오픈소스계의 영원한 아이돌, Linus Torvalds. (Linus Torvalds를 구글에 검색하면 제일 위에 이런 사진이 뜨는데 어떤 상황이었는지는 이 글을 참조…)

마이크로소프트 (악의 제국…) 페이스북, 트위터, 모질라 등 굵직굵직한 기업과 단체에서 Git을 사용하고 있다. 뿐만 아니라 전 세계의 수많은 개발자들, 학생들도 Git을 이용해서 소스코드를 관리한다.

Git의 방식은 프로그래머가 소스코드를 수정하고나서 ‘커밋'(commit)을 하면, 그 때까지의 수정 기록들을 커밋 단위로 모두 저장하는 것이다. 따라서 열심히 수정한 소스코드가 날아가버릴까봐 걱정할 필요도 없고, 지금 작업한 것을 버리고 예전 버전의 소스코드로 되돌리는 것도 자유롭게 할 수 있다. 뿐만 아니라, 버전을 분기시켜서 별도로 관리할 수도 있다. 커밋을 줄줄이 이어놓은 것을 하나의 ‘브랜치'(branch)라고 하는데 이 branch를 새로 분기시켜서 새로운 버전의 소스코드를 작성하는 것이다.

git_branch
Git branch. Git에 대해서 더 자세히 알고싶다면 여기 혹은 여기을 참조하시길… (이미지 출처: git-간편안내서)

여전히 풀리지 않는 의문이 하나 있다. Git을 써서 소스코드의 버전을 관리하기 좋다는 것은 알겠는데 어떻게 여러명의 개발자들이 Git으로 협업을 할 수 있는 걸까? 이런 의문에 대한 답이 Git 원격저장소(Git remote)라고 불리는 기능이다. 쉽게 말하면 서버나 클라우드 어딘가에 Git 저장소를 만들어놓고 여러명의 개발자들이 접근 할 수 있도록 하겠다는 것이다. 이런 Git 원격저장소를 호스팅하는 서비스가 여러군데 있는데 이 중에서 제일 유명한 것은 당연 자유소프트웨어의 성지(?)라고 불리는 GitHub이다.

github_logo
깃허브의 로고. (문어고양이…?) 깃허브는 social coding을 표방한다. 개발자들이 사진이나 글 대신에 소스코드를 공유하고 같이 협업하는, 즉 개발자들의 SNS이다.

GitHub는 개발자들이 무료로 git 저장소를 만들고 접근할 수 있도록 해준다. 다만 전제조건이 있는데, 무료 저장소는 모든 유저들이 볼 수 있도록 공개로 해놓아야한다. 이런 특성 때문에 많은 오픈소스 프로젝트들이 GitHub를 이용해서 git 저장소를 호스팅한다. 참고로 2016년 기준으로 가장 인기 있는 github 오픈소스 저장소는 트위터에서 만든 웹 UI 프레임워크 bootstrap, 구글의 angular.js, 페이스북의 react 등이다.

가자고도 GitHub를 이용하는데 우리의 소중한 소스코드를 누구에게나 공개할 수는 없기 때문에 GitHub의 기업용 유료계정을 통해 Git 저장소를 비공개로 관리하고 있다. 각 개발자들은 GitHub에 올라가 있는 Git 저장소를 자신의 개발머신에 ‘복제'(clone) 하고 자신의 커밋을 GitHub 저장소로 ‘푸쉬'(push) 하는 식으로 공동작업 한다. 이 과정에서 ‘풀 리퀘스트'(pull request)라는 기능을 사용하기도 하는데, 간단히 말하면 개발자가 자신이 개발하려는 기능을 아예 새로운 브랜치 에 만들어놓고 코드 리뷰를 요청하는 것이다. 이 브랜치는 프로젝트의 ‘마스터 브랜치'(master branch: 프로젝트의 기본 브랜치. 보통 실 서버에서 운영하고 있는 어플리케이션의 코드에 해당)와는 별도로 운영되기 때문에 코드 리뷰를 한 사람이 머지하기 전까지는 서비스에 아무런 영향을 끼치지 않는다.

github_gajago_repository
GitHub에 올라가 있는 가자고 저장소. 얼마전에 1주년을 맞이했다.

EastskyKang pushed to master at leisureq/gajago

나도 Git와 GitHub를 꽤 오래 전부터 써오고 있었다. 다만 지금까지 협업을 할 만큼 복잡한 시스템을 개발해 본 적이 없었기 때문에 늘 Git 저장소를 혼자서 썼을 뿐이다. 앞에서 얘기했듯이 혼자서 쓰더라도 Git과 GitHub는 굉장히 훌륭하다. 적어도 아래 그림과 같은 상황은 생기지 않는 것이다.

version_management_failured
최종…최종…최종… 버전관리 실패의 예 (이미지출처 : http://slowalk.tistory.com/)

하지만 역시 Git과 Github의 진가는 여럿이서 동시에 개발을 할 때 발휘된다. 특히 Git을 효과적으로 쓸 수 있게 해주는 몇가지 툴을 함께 사용한다면 여러명이서 동시에 개발하면서 발생할 수 있는 비효율(위에서 우리의 개발자 A와 개발자 B가 겪었던…)을 거의 느끼지 않고 협업을 할 수 있다. 심지어 각자가 고친 소스코드를 리뷰하고 함께 고민하는 과정에서 자연스러운 성장을 경험하기도 하고, 이전에는 찾을 수 없었던 문제들을 발견해내어 고치기도 한다. 1+1 = 1.5 였던 것이 1+1 = 3 정도가 되었다고나 할까…

나의 첫 커밋은 회사에 입사한지 정확하게 4일 뒤에 이루어졌다. 수정한 코드 라인은 정확하게 1줄… 고작 이 한줄을 고쳤을 뿐인데도 혹시나 내가 수정한 코드 때문에 서비스에 장애가 날지도 모른다는 걱정에 덜덜 떨면서 커밋을 했던 기억이 난다. (물론 모바일 앱의 개발에 필요한 플러그인을 추가해준게 다라서 뭔가 문제가 있었더라도 아무일도 일어나지 않았을 것이다 ^^;)

first_commit
가자고 저장소에 등록된 나의 첫 커밋. 수정한 줄수는 정확히 한줄.

6개월이 지난 지금, GitHub에 기록된 EastskyKang의 커밋은 총 197번. 대략 20000 줄의 코드를 추가하거나 수정했고, 수정의 범위도 예전에 비해서 훨씬 넓어졌다. 참으로 장족의 발전이 아닐 수 없다 🙂

이제는 매일같이 브랜치를 새로 만들고, 코드를 수정해서 풀 리퀘스트를 만들고 이슈와 코멘트를 남기고 브랜치들을 머지하고 있다. 때로는 고급 Git 기능들을 이용하기도 한다. 하지만 이 기간동안 내가 배운 것은 단순히 프로젝트를 이해하고 Git을 쓰는 법을 배운 것 뿐이 아니었다. 이 과정에서 자연스럽게 여러명의 개발자들과 협업하고 같이 프로젝트를 발전시켜가는 방법을 배울 수 있었다.

협업은 혼자서는 절대 할 수 없었던 일들을 가능하게 해준다. 특히 개발 프로젝트에서의 협업은 때로 1+1 > 3 의 기적을 만들어내기도 한다. 개발자들은 항상 어떻게 해서 협업의 효율성을 높이고 협업의 생산성을 높일지 늘 고민한다. Git과 GitHub도 그런 개발자들의 문화와 오랜 고민에서 탄생한 결과물이라고 할 수 있을 것이다.

협업의 중요성과 더 나은 협업에 대한 고민, 내가 가자고 팀에서 인턴을 하면서 얻을 수 있었던 가장 소중한 배움이다.

by EastskyKang

레저큐 인턴기 2편 – 첫 출근

첫 출근

1월 18일, 첫 출근날 아침. 꿈의 랩탑인 맥북프로 레티나가 주어졌다. 15인치 화면에 RAM이 16 GB나 달려있는 ‘크고 아름다운’ 녀석이다.
설레는 마음으로 전원 버튼을 누르자 ‘쫘안’하는 따스한 부팅음과 함께 검은 화면에서 흰색 사과가 떠오르고, 곧! 널찍하고 시원한 화면이 나타난다.

maxresdefault.jpg
~~내 몸 값보다 비싼~~ 맥북 프로 15인치. (이미지 출처: DetroidBORG)

신나는 마음을 진정시키고 개발 환경을 세팅할 차례다. IDE(Integrated Development Environment: 통합 개발환경)와 플러그인, 개발툴들을 설치하고 테스트 환경을 세팅한다. 가자고 팀에서는 Jet Brains 사의 Java용 IDE IntelliJ를 사용하는데 학교에서 vim만 사용하던 내게, IntelliJ 이거, 정말 신세계다.

마지막으로 GitHub에서 가자고 프로젝트를 클론해서 내려받는다. 자, 이제 개발을 시작할 모든 준비를 마쳤다. 마침내 가자고 프로젝트의 소스코드를 열어볼 시간이다. 아무래도 Java가 익숙하니 백엔드 코드를 먼저 살펴보자…

어라 근데 뭔가 이상하다… 분명 Java로 작성된 코드인데 세상에, 이게 무엇인가. 내 눈앞에 펼쳐진 소스코드는 왜 이렇게 생소한걸까? 웬 듣도 보도 못한 Annotation 들이 덕지덕지 달려있는 건가. 클래스는 왜 이렇게 많으며 무슨 처음 듣는 용어들은 왜 이렇게 많은가.

아아, 뭔가가 잘못되어가고 있다. 하지만 진정하고 프론트엔드 코드를 살펴보자… 여기는 그래도 뭔가 좀 이해할 만한 것이 있을 수도 있다. 그러나 나의 희망은 곧 눈앞에 모습을 드러낸 암호문과 같은 프론트엔드 소스코드와 함께 산산조각이 나버리고 만다. 그제서야 비로소 깨달았다. 그동안 내가 해온 프로그래밍이 장난에 불과한 것이었다는 걸…

school vs world.jpg
젠장, 학교를 5년이나 다녔는데! (이미지출처: http://preemploymentassessments.com/)

컴퓨터공학을 공부한다는 것, 프로 개발자가 된다는 것.

학부 컴퓨터공학(혹은 컴퓨터과학) 수업에서도 프로그래밍을 한다. 단순한 알고리즘을 구현하는 간단한 코딩을 할 때도 있지만 때로는 꽤나 복잡한 시스템을 구현하기도 한다. 이를테면 DB 시스템을 구현하거나 linux 커널을 해킹한다거나하는 것들 말이다. (사실 linux 커널 해킹 수준이 되면, 그 누구도 절대 단순한 프로그래밍을 한다고 할 수는 없을 것이다.)

그럼에도 불구하고 현업에서 프로그래밍을 한다는 것과 학교에서 프로그래밍을 한다는 것은 완전히 다른 일이나 마찬가지다. 사실 어느 것이 ‘우위에 있다’고 얘기하기 보다는 ‘다른 영역의 일이다’라고 얘기하는 편이 나을 것 같다. 구체적으로는 이런 것들이 다르다.

  1. 학교에서의 프로그래밍과 현업에서의 프로그래밍은 초점과 지향점이 다르다. 컴퓨터공학 수업은 우리가 사용하는 컴퓨터 기술들의 토대에 대해서 가르친다. 따라서 프로그래밍도 원리와 이론의 학습이나 검증을 목표로 한다. 반면에 현업 프로그래밍에서는 이론보다는 구현 그 자체가 더 중요하다. 사실 너무나 당연하다. 그 구현이 곧 회사의 비지니스이기 때문이다.
  2. 문제의 핵심이 다르다. 학교에서의 프로그래밍에서 핵심은 아이디어이다. 협업에 대한 고려와 코드의 질에 대한 고려는 상대적으로 중요도가 덜하다. 그러나 현업에서의 프로그래밍은 코드의 질과 협업에 대한 고려가 가장 중요한 요소 중 하나이다.
  3. 접근 방법이 다르다. 학교에서의 프로그래밍은 현실적인 문제들에서 자유로울 수 있다. 문제들을 추상화시키고 단순하게 생각해도 괜찮다. 현업에서는 그렇지 않다. 항상 현실적인 문제들과 맞닥뜨리고 계속해서 새로운 균형을 찾아나가야 한다. 반면에 현실적으로 큰 문제가 되지 않는 것들은 과감히 무시할 수도 있다.
  4. 기술의 범위가 다르다. 학교에서의 프로그래밍은 가장 로우레벨의 기술들에서부터 차근차근 구현해나간다. 현업 프로그래밍에서는 이미 개발되어 있는 기술들을 얼마나 빠르게 잘 활용하느냐가 중요하다.

컴퓨터공학을 전공한 학생들 중에는 뛰어난 프로그래밍 실력을 가진 학생들이 많다. 그러나 모두가 그런 것은 아니고, 사실 그럴 필요도 없다. 컴퓨터공학에서 뛰어난 프로그래밍 실력을 요구하는 분야는 일부에 불과하기 때문이다. 이를테면, 알고리즘이나 전산학 이론에 대해 공부하고 연구하는 학생들은 프로그래밍 언어보다 수학에 더 익숙하다.

마찬가지로, 좋은 프로그래머가 되기 위해서 반드시 컴퓨터공학을 전공할 필요는 없다. 프로그래밍에서 컴퓨터공학적 지식을 요구로 하는 경우 역시 일부에 불과하기 때문이다. 그보다 자신의 코드의 품질에 집착하고, 얼마나 프로그래밍 생산성을 높일 수 있는지에 대해서 고민하는 사람이 더 좋은 프로그래머의 자질을 가진 사람이라고 할 수 있을 것이다.

difference_between_a_programmer_a_developer_a_computer_scientist.png
프로그래머와 개발자 그리고 컴퓨터 과학자. 학교는 컴퓨터과학자를 길러내는 곳이지 프로그래머나 개발자를 길러내는 곳이 아니다. (이미지 출처: http://www.improgrammer.net/)

다시 처음부터 다시 처음! 처음!

나의 인턴 생활의 첫 날은 ‘현업과 학업의 차이’라는 아주 근본적이면서 또한 아주 거대한 간극에 대한 깨달음으로 귀결되었다. 그러나 이대로 포기할 수 없다. 나의 뇌가 백지 상태임을 깨달았으니 첫 획부터 다시 차근 차근 그려나가야 한다.

그 첫 획을 긋기 위해서, 부랴부랴 데이터베이스의 구조부터 공부하기 시작했다. 가자고는 관계형 데이터베이스 (key와 value들의 간단한 관계를 여러개의 테이블로 정리한 형태의 데이터베이스) 시스템 MySQL을 이용하고 있고, 복잡한 구매와 상품 정보를 저장하기 위한 수십개의 테이블들이 서로 얽혀 있기 때문에 이 관계들과 구조에 대해서 제대로 이해하는 것이 개발을 위한 첫걸음이라고 할 수 있다.

처음엔 몇개의 테이블을 JOIN 해서 데이터를 가져오는 간단한 SQL(Structured Query Language: 관계형 데이터베이스 시스템에서 데이터를 관리하기 위해 이용하는 프로그래밍 언어)스크립트부터 시작했다. 이를테면 특정 상품을 2016년 1월 한달 동안 구매한 고객들의 리스트라던가 1월 한달 동안 어떤 상품 옵션을 통해 발생한 매출을 구해본다던가, 하는 것들이다.

그리고 나서는 점점 복잡한 데이터들을 추출할 수 있는 쿼리 명령어들을 짜봤다. 특히 마케팅이나 매출 집계에 활용할 수 있는 각종 통계 데이터들을 추출하기 위한 쿼리를 작성했다. 활발하게 구매활동을 지속하고 있는 고객들, 다소 장기간 동안 구매활동이나 접속 기록이 없었던 고객들의 리스트 등…

그렇게 레저큐에서의 첫 일주일 동안은 가자고 프로젝트 소스코드는 단 한줄도 손대지 않은채, SQL 문법과 DB 구조에 충분히 익숙해지기 위한 훈련을 했다. 조금 감을 잡고 나서는 쿼리 성능에 중요한 요소들이 어떤 것들이 있는지, 어떤 식으로 쿼리 최적화를 할 수 있는지 고민도 해보면서.

사실 SQL 스크립트를 작성하고 최적화하는 작업은 굉장히 지루한 작업이다. 그러나, 나의 오랜 학부 생활은(햇수로는 7년에 달한다…) 적어도 매우 중요한 한가지 가르침을 내게 남겨주었다. 항상 새로운 지식을 터득할때는 최초의 문턱을 넘기 위해 지난한 시간들을 견뎌내야 한다는 것. 그래서 조금은 우습지만, 나의 첫 커밋(commit)을 잠시 연기해두고 가장 기초가 되는 것들부터 차근차근 공부해나가기 시작했다. 마치 운동 선수들이 본격적인 시합에 앞서서 곳곳의 세밀한 근육들을 단련시키는 것처럼 🙂

By Eastsky Kang

레저큐 인턴기 1편 – 시작하며

시작은 거창하게

This is just the beginning, the beginning of understanding that cyberspace has no limits, no boundaries.
이것은 시작일 뿐입니다. 사이버 세상은 한계도, 경계도 없다는 것을 이해하게 되는 시작 말입니다.

Nicholas Negroponte, co-founder of MIT Media Lab.

할일이 없으면 생각이 많아진다. 오늘이 그랬다. 무던히도 더웠고 마침 아무런 계획 없는 일요일이라 빈둥거리다 문득 이런 생각이 들었다. ‘우와! 우리는 정말 신기한 시대에 살고 있구나!’ 이게 갑자기 무슨 소리인가 싶지만 오늘 하루 있었던 일을 떠올려보면 이런 생각이 드는 것도 무리가 아니다.

  1. 아침. 지구 반대편, 스위스에 있는 선배와 마치 옆에 있는 것처럼 실시간으로 카카오톡 메시지를 주고 받는다.
  2. 점심 무렵. 넷플릭스로 영화 한편을 본다. 미국 대통령 암살 사건에 대한 영화인데 이거 완전 내 스타일이다. 어떻게 골랐을까? 그냥 넷플릭스가 이걸 보라고 추천해주고 아이패드에 끊김 없이 영화를 전송(스트리밍)해주기까지 했다.
  3. 무더운 오후. 날씨가 너무 덥다고 생각하며 온라인 쇼핑몰에서 흰색 반팔 티셔츠를 하나 구입한다. 클릭 몇번으로 마음에 드는 티셔츠를 선택하고 결제까지 완료했다. 아마 내일이나 늦어도 모레 쯤 우리 집 앞에 택배로 도착할 것이다.
  4. 저녁 즈음. 음악을 듣다가 곡에 대해서 궁금해져서 구글에 검색을 한다. “구프타프 말러, 교향곡 6번”. 고급 정보가 주르륵 쏟아진다. “말러 교향곡 중에서 고전적 형식미와 혁신적인 요소들을… 불라불라” 수 분 내에 나는 말러의 인생과 그의 교향곡들에 대해 전문가가 된다.
  5. 하루 종일. 언제나 그렇듯, 페이스북을 공연히 들락날락 거리며 친구들의 여름 휴가 사진을 흘깃흘깃 훔쳐본다. 아 부럽구나 나도 어디론가 떠나고 싶다 생각하며.

20~30년 전만 해도 누가 알았겠는가, 이런 세상이 오게 될지. 남녀노소 가릴 것 없이 전세계 모든 사람이 현실 세계와 인터넷 세계, 두개의 평행 세계에서 살아가고 있다. 하나의 세계에서 살아가는 것만 해도 충분히 터프한 일인데 사람들은 두개의 세상에서 동시에 살아가는 고달픔을 마다하지 않는다. 왜 그런가? ‘인터넷 세계의 나’가 전지전능하기 때문이다. 수만 km 를 날아 지구 반대편 사람과 대화를 할 수 있고 쇼핑몰에 갈 필요 없이 마음에 드는 물건들을 살 수 있다. 심지어 가만히 앉아만 있어도 내 어리석은 친구들은 스스로 자기가 뭘하고 있는지, 어떤 생각을 하고 있는지 주기적으로 보고를 해준다. 오늘은 어느 카페에 가서 어느 원산지의 커피를 마셨다느니, EU를 탈퇴한 영국 때문에 주식이 망했다느니, 유로 2016 결승컵은 누구에게 돌아갈지 궁금하다느니…

facebook-graph-network
초연결사회이다. 지구 상의 모든 인류가 인터넷을 통해 서로 연결되어 있다.

인터넷 그리고 웹 프로그래머

이게 전부 다 인터넷이란 것 덕분이다. 그런데 놀랍게도 인터넷은 만들어진게 채 30년이 되지 않는다. 우리가 인터넷이라고 부르는 WWW(World Wide Web – 월드와이드웹)은 유럽 입자 물리 연구소의 컴퓨터 과학자인 팀 버너스 리(Tim Berners-Lee)에 의해 1989년에 개발되었다. 처음에는 학자들이 서로 빠르게 학술 정보를 교환할 수 있도록 하기 위해서 이런 세계를 고안했다고 한다. 어째 이런 고상한 기술을 친구들이 어떤 디저트를 먹었나 훔쳐보는 용도로 사용하고 있는 내 자신이 비참하게 느껴지긴 하지만 우리는 닐 암스트롱을 달에 보낼 때 사용했던 컴퓨터보다 몇 배 더 좋은 컴퓨터를 쓰고 있고 그 컴퓨터로 앵그리버드를 쏘아 보내며 살고 있는 세대가 아닌가. 원래 세상은 그런것이라고 위안을 해본다.

angry-bird
우리는 NASA의 과학자들이 닐 암스트롱을 달에 보낼 때 썼던 컴퓨터보다 몇 배는 더 좋은 컴퓨터로 앵그리버드를 날려 보내고 있다.

여하튼 WWW이 탄생하고 나서 얼마후 세상에 웹 프로그래머 라고 불리는 사람들이 나타났다. 이들은 스스로를 해커(Hacker)라고 부르며 인터넷 세상에 무엇인가를 뚝딱뚝딱 만들어내는 신기한 사람들이다. 채 30년이 지나지 않아서 이들은 WWW 세계에 검색엔진, 온라인 쇼핑몰, 소셜 네트워크라는 어마어마한 것들을 만들어 낸다.

웹 프로그래머들의 능력은 대단하다. 요새는 한명의 웹 프로그래머가 하루 밤 사이에 웹 사이트 하나 만들어 내는 것은 일도 아니다. 더 신기한 것은 이들은 심지어 자기가 만든 것을 인터넷 세상에 공짜로 공개하기까지 한다는 것이다. “누구나 가져다 쓰시오. 발전 시킬 수 있다면 더 좋음.” 자본주의 논리로는 쉽게 이해할 수 없는 행동이다. 왜 이런 짓을 할까? 요약하자면 내가 만든 것을 다른 사람들과 같이 쓰면 더 나은 것으로 발전시킬 수 있기 때문이다. ~~사실 어차피 돈은 다른 방법으로 벌 수 있다~~

이젠 이들의 엄청난 능력과 특별한 문화가 ‘일반인’들에게도 별로 낯설지 않다. 요새는 일반인들도 전공과 무관하게 금방 해커가 된다. 오픈소스와 클라우드, 그리고 인터넷 세상에 널려있는 수많은 정보들을 이용하면 생각보다 그리 어렵지 않다. 해커가 해커를 만들어내고 또 다시 그 해커들이 새로운 해커들을 만들어낸다. 언제까지? 세상 사람들 모두가 해커가 될 때까지.

새옹지마

사실 10년 전만 해도 이 정도는 아니었다. 대학 입시를 앞두고 있었던 2008년 쯤, 어느 과에 지원해야 하나 하는 깊은 고민에 빠져 있는 내게 컴퓨터 과목 선생님이 하신 말씀이 아직도 기억에 생생하다. “어디를 가도 다 괜찮아. 그런데 컴퓨터과는 가지마. 여긴 3D야.” 그 때만 해도 컴퓨터 공학의 위상은 이랬다. 이 분야는 소수의 재능있는 친구들의 영역이었고 나와 같은 범인들에게는 위험하고, 지저분하며, 고통스러운 분야였다. 2009년에 나의 모교를 졸업한 150명 정도 되는 학생들이 이공계열 대학으로 진학 했는데 그 중에 컴퓨터 공학과로 진학했던 사람은 손에 꼽힐 정도로 적다.

지금은 어떨까? 서울대학교 컴퓨터공학부의 정원이 50명 남짓인데 모든 전공 과목마다 150명이 들어갈 수 있는 대형 강의실들이 꽉꽉 들어찬다. 컴퓨터공학 학생들 50명에 복수전공, 부전공 학생 50명, 그리고 타과생 50명이 같이 수업을 듣기 때문이다. 강의실이 좁아서 수업을 하기가 쉽지 않다는 교수님들의 투정이 그냥 투정으로만 들리지는 않는다. 심지어 갑자기 개설해야하는 전공과목 숫자가 늘어나서 강의할 교수님이 부족하다는 얘기까지 들린다. 미국, 유럽, 중국… 어딜가나 컴퓨터공학(혹은 컴퓨터과학)과가 가장 인기가 많다. 참으로 글로벌하게, 인생사 새옹지마가 아닐 수 없다.

컴퓨터 공학의 위상이 이렇게 변한것은 지난 10년 동안 컴퓨터 기술과 IT 산업이 엄청난 속도로 발전했기 때문이다. 컴퓨터 과학의 발전과 함께 프로그래머란 사람들이 어마어마한 일들을 저질렀고 그들이 세운 구글, 페이스북, 마이크로소프트, 애플 같은 회사는 전세계에서 가장 덩치가 큰 회사들이 됐다. 전 세계에 스타트업 열풍이 불고, 프로그래머들의 몸값이 높아지고 있다. 새벽녘 드럼통에 개발자들이 불 피워놓고 기다리고 있으면 봉고차에서 “여기 자바 2명!” 라고 외치는 시대는 확실히 지나갔다.

yogi-java-du-myung!
IT 산업의 흑역사: 여기 자바 2명 타요!

멀리 돌아서

나는 2013년에 컴퓨터공학 복수전공을 시작했다. 여러가지 이유가 있었지만 사실 컴퓨터 공학을 공부하게 된 동기 중에 하나는 인터넷 세상에 대한 호기심이었다. 웹 기술과 소프트웨어 공학이 만들어낸 이 엄청난 변화, 도대체 어떻게 이런 일이 가능한 것인지에 대한 궁금증, 그리고 나도 해커들 같이 강력한 ‘힘’을 가진 사람이 되면 좋겠다는 생각. 그 때는 그 시작이 컴퓨터 공학을 공부하는 것이라고 생각했다.

그러나 꿈과 현실은 늘 다르다. 학교에서 열심히 공부를 한다고 해서 그런 능력을 얻을 수 있는 것은 아니라는 것을 깨닫는데 그리 오랜 시간이 걸리지 않았다. (그렇다고 후회를 한다는 것은 아니다! 나중에 여기에 대해서 좀 더 자세히 얘기해볼까 한다.) 열심히 공부했지만 마지막 학기가 되기까지 그 동기를 충족시킬 만한 변화를 찾기는 힘들었다.

그래서, 졸업하기전 마지막으로 새로운 도전을 한 번 더 시작하기로 했다. 스타트업에서 웹 프로그래머의 삶을 경험해보자! 웹 프로그래밍에 대해서 배우는데 웹 프로그래머로 일하는 것 보다 더 좋은 방법이 어디있겠는가? 갑자기 새로운 흥분이 느껴졌다. 오 이제야 말로 나도 이제 해커들의 세계로 들어간다! 근데 한가지 문제가 있었다. 나는 코딩 실력도 형편 없고 웹 프로그래밍의 웹자도 모른다는 것이었다. 아니 세상에 컴퓨터공학을 전공한다면서 코딩도 능숙하지 않다니 도대체 학교에서는 무엇을 가르친단 말인가? 라고 생각할 수도 있다. 근데 원래 그렇다. 컴퓨터 공학을 공부한다는 것이 프로그래밍을 잘하게 된다는 것을 의미하지는 않는다.

여하튼, 방황하고 있던 그 때에 이 미천한 공학도에게 한 회사가 기회의 손을 내밀었다.

다시 본론으로

레저큐는 여행 레저 전문 이커머스(e-commerce) 서비스 가자고를 운영하고 있고 빠르게 성장하고 있는 IT 스타트업이다. 복잡한 웹 시스템을 어떻게 구축하고 운영하는지 경험할 수 있고, 무엇보다도 복잡한 오프라인 비지니스 로직을 어떻게 인터넷 세계의 소프트웨어로 구현해낼 수 있을지 고민할 수 있는 기회를 가질 수 있다는 점에서 새내기 프로그래머에게 최고의 직장이다.

사실 무엇인가를 처음부터 시작해야한 다는 것은 꽤나 고통스러운 일이다. 2016년 1월에 레저큐 가자고 팀에 합류하고 나서, 밑바닥부터 공부를 해야했다. 지루하고 힘들었지만 비로소! 이 과정에서 내가 기대했던 것들을 배울 수 있었다. 웹이란 것이 대체 무엇인지, 웹 프로그래밍은 어떻게 하는 것인지, 프로그래머의 삶이란 것이 어떤 것인지, 성장하는 스타트업은 어떤 문화를 가지고 있는지.

어느새 6개월이 지났다. 기술적으로 성숙하기엔 충분하지 않은 시간이다. 하지만 그 동안 겪었던 일들, 가졌던 생각들을 간단하게 정리해보려고 한다. 새내기일 때의 시각과 감상은 ‘헌내기’의 그것보다는 미숙하고 무딜테지만 나름의 풋풋함과 신선한 시각들을 담고 있을 것이므로.

독자가 아무도 없다고 해도 사실 별 상관 없다. 이 글을 쓰면서 내가 얼마나 성장했는지 확인하고, 또 앞으로 나는 엔지니어로서 어떻게 살아가야 할 것인가를 차분히 고민해보게 될 것이다. 여느 때와 조금 다르게 글을 쓴다는 것이 가슴 설렌다.

By Eastsky Kang