구글애널리틱스 IQ 시험 후기

스타트업에 있다보니 지표 측정이 중요하다. 아무래도 경력이 있다보니 어깨너머로 들은 지식들은 있지만 지표측정에 대해 정확히 안다고 이야기할 수는 없었다. 그렇다고 요즘 유행하는 강의를 듣기에는 비용부담이 만만하지 않았다.

GA 강사들의 프로필을 보다보니 Google 애널리틱스 공인 전문가 자격증(GAIQ)이 빠지지 않는다는 것을 알게 되었다. 아직은 회사규모가 지표만 분석하는 사람을 뽑기에는 어려움이 있어서 내가 공부하고 적용해보기로 마음먹었다.

그렇지 않아도 GA 와는 인연이 있다. 예전 KTH 에 입사해 처음 작업한 일이 바로 이벤트 측정 코드를 곳곳에 심는 일이었다. 그렇게 대략 200개 정도의 이벤트 코드를 꽂았다. 그런 이유로 GA SDK 레퍼런스도 꽤 여러번 봤었다.

시험 준비는 구글의 가이드 대로 Google Analytics Academy 의 Digital Analytics Fundamentals 강의를 보았다. (개편 후에 Google Analytics Platform Principles 까지 포함되었다고 알고 있다. )그리고 “구글 애널리틱스” 책을 한 번 다 읽었다. 강의는 영어로 되어 있지만 PDF 파일이 지원되고, 자막을 켜고 보아서 많은 도움이 되었다.

처음부터 끝까지 3번 정도 영상을 봤는데 주로 웹분석의 프로세스와 구글 애널리틱스의 기초적인 사용법에 대해 강의한다. 더 자세한 특색에 대해서는 구글 애널리틱스 도움말을 한 번 살펴본 것이 더 좋았다.

마침 사이트 런칭 직전이라 야근이 꽤 많았기 때문에 주말에만 시간이 조금 나서 대략 2개월정도 소요되었다. 동영상을 두번 보고 나서 구글의 테스트 센터에 가서 50달러를 결제하고 영어로 시험을 쳤다.

첫 시험은 사실 간만 본다는 마음으로 쳤다. 오픈북이 가능하지만 시험범위 등을 알아보는게 목적이어서 열어보지 않고 테스트를 봤고 예상대로 떨어졌다. 구글 애널리틱스의 도움말을 자세히 살펴봐야 한다는 것을 알게 됐다.

점수는 예상보다는 나쁘지 않았다. 70문제 80% 통과인데 74%로 아쉽게 탈락했다. 재시험은 2주 후에 가능했기 때문에 그 때까지 공부를 더 해야겠다고 생각했다. GAIQ첫시험 결과 74%로 불합격

어찌어찌 시간이 지나고 2주가 지났는데 짬이 안돼 1달만에 시험을 봤다.

그런데 구글 애널리틱스 시험이 기존 테스트센터에서 사라져서 당황했다. 아직 재시험을 볼 수 없게 된 것인지 싶었다. 그래서 다른 개인 계정으로 시험센터에 재접속해보니 그냥 시험이 테스트 센터에서 사라진 것이었다.

이제 GAIQ 시험 방식이 변경되어서 이제 시험을 무료로 볼 수 있다. 시험은 http://partners.google.com 에서 볼 수 있으며 이제는 한글 시험도 제공된다.

재시험을 준비하면서 이전에 공부했던 내용에 비해 조금씩 추가된 내용이 있는 것 같다는 느낌을 받았는데 아마도 이번 개편과 관련된 것으로 보인다. 물론 문제도 처음 시험볼 때 봤던 문제들이 많이 출제되었지만 못 풀어서 기억에 남았던 문제중 하나는 사라졌고, 처음보는 문제들도 추가되는 등 조금 달라졌다. 무엇보다 무료로 풀린게 속이 쓰렸다.

그리고 결과는 92% 합격이었다. GAIQ 인증서 시험을 보다보니 영어로 공부한 내용을 한글로 시험을 보려니 용어 등에서 어려움이 있었다. 강의자료들이 영어로 되어 있으니 되도록 그냥 영어로 시험을 보는 것을 추천한다.

이제 기본준비는 다 되었다. 하지만 이제야 대략 틀을 잡은 것 뿐이고 공부할 것이 무척 많다는 것도 알게 되었다. 웹분석은 전문분야는 아니어서 한계는 있겠지만 조금 더 관심을 가지고 알아보려고 한다.

Dockerfile – ADD 를 통해 build 캐시막기

Dockerfile 을 수정하고 다시 빌드할 때 cache 덕분에 빠르게 재실행이 가능하다.

Dockerfile 의 명령라인이 변경되지 않으면 자동으로 캐시가 작동하게 되는데 가끔 이 기능이 불편할 때가 있다.

Node 개발용 서버를 구축하는 중에 이런 경우를 만났다.

git pull 을 하고, 의존성 해결을 위해 npm install 을 하는 플로우인데, RUN git pull 행이 변경되지 않으니 계속 캐시가 작동했다.

캐시를 작동하지 않게 하는 명령을 추가하는 것에 대해 이 곳에서 계속 논의가 진행중인데, 이 이슈를 살펴보다 랜덤스트링을 추가하는 괜찮은 방법을 알게되었다.

ADD http://www.random.org/strings/?num=10&len=8&digits=on&upperalpha=on&loweralpha=on&unique=on&format=plain&rnd=new /var/tmp/uuid

이 명령을 더이상 캐시가 필요하지 않는 곳에 추가해주면 된다. 이렇게 추가해주면 build 할 때마다 랜덤스트링을 다운받고 컨테이너의 파일이 변경되기 때문에 이후의 명령들은 캐시가 동작하지 않게된다.

어느 스타트업의 백오피스 인증 구현기

스타트업에는 놓치지 않아야 할 여러 가지가 있다. 난 그 중 백오피스를 꽤 높은 순위에 둔다.

백오피스를 가졌을 때의 장점은

  1. 서비스를 만들고 지표의 변화를 감지해 서비스를 개선하는 데 큰 도움이 된다.
  2. 개발자전용 인터페이스(REST API 도구라든지 <form> 만 있는 HTML 페이지 등)를 사용하는 것보다 모두의 도구를 만드는 것이 가장 시간이 부족할 때 큰 도움이 된다.

지표에 대해 조금 더 이야기하면 IT 기업에서 지표를 측정하려면 개발자의 도움이 꼭 필요하다. Google Analytics와 같은 도구의 코드를 삽입하거나 데이터베이스 내의 수치 등의 많은 지표가 개발자의 손을 통해 측정되고 알 수 있게 되기 때문이다. 백오피스가 없는 경우 데이터에 접근성이 떨어지고 알고 싶은 리포트를 수동으로 작성할 수밖에 없다. 가뜩이나 인원도 시간도 모자란 스타트업에게 보고서 작성하는 시간을 할애하는 것과 같다고 생각한다.

현재 근무하고 있는 회사는 KStyleTrip.com이고 첫 서비스로 Luck2share 를 만들었다. 새로 입주한 사무실을 꾸미면서 위시리스트를 작성하려고 했는데 공수도 많이 들지 않을 테니 서비스로 만들어보자. 그리고 dogfooding 해보자는 개념으로 시작한 서비스다. KStyleTrip 의 위시리스트 바로 가기

아직 kstyletrip.com 은 제작 중이기 때문에 백오피스의 플랫폼을 만드는 작업은 주로 이 Luck2share 를 대상으로 했다. 그리고 회사의 서비스와 관리자에게 필요한 기능은 앞으로 계속 늘어날 것이기 때문에 서비스마다 각기 다른 백오피스를 갖는 것이 아니라 모든 서비스가 통합된 백오피스를 제작하는 것으로 방향을 잡았다. 이 방법이 각 서비스가 방치되지 않고 잘 관리되는 방법이라는 것에는 이견의 여지가 없으리라고 생각한다.

DB 쿼리 vs. REST API

여기까지 생각이 미치고 구현에 앞서 고민했던 점은 Luck2share 의 데이터를 가져오는 방법이었다. 검토했던 방법은 DB 포트를 열고 백오피스 서버에서 접근해 관리자 전용 API를 구현하는 것과 Luck2share 서버에 관리자용 API를 만들어 사용하는 것이었다.

Luck2share 의 DB 포트는 외부에 공개되지 않고 서버 안쪽에서만 사용하고 있다. 따라서 상대적으로 안전하게 보관되고 있는데 이 포트를 열어 보안이슈를 만들고 싶지 않았다. 그리고 이미 Luck2share 내에 DB쿼리하는 코드베이스가 충분한데 비슷한 코드를 다시 만들어야 하는 것에도 거부감이 있었다.

따라서 API는 Luck2share 서버에 두고 데이터를 가져오는 것으로 방향을 잡았다.

Private API 구축 – 비밀번호 공유 vs. 비대칭 키암호화

두 번째 고민은 Private API를 구축하는 부분이었다. 관리자를 위한 API라면 서버 간, 또는 서버와 클라이언트 간 HTTP 통신을 구축하는데 인증수단이 반드시 있어야 한다. 따라서 HTTP의 Authorization헤더를 통해 인증하는 방법을 사용했다.

우리는 구글 앱스를 사용하고 있기 때문에 회원을 관리할 필요는 없다. OAuth 로그인을 정상적으로 마친 후 OAuth 로부터 얻어온 회원정보에서 몇 가지를 추려 다시 토큰을 만들었다.

이 토큰을 Luck2share 서버에서 검사하도록 해야 했는데 secret을 공유해 암호화/복호화하는 방식은 깔끔하지 않을 뿐 아니라 유출되었을 때 다른 서비스도 동시에 유출되기 때문에 안전하지 않다. 따라서 비밀 키/공개 키를 통한 암호화 방식을 선택했다.

아래와 같은 절차로 Private API에 접근할 수 있다.

  1. 우선 비밀 키와 공개 키를 생성한다. 이 키 쌍의 비밀 키는 백오피스 서버에, 공개 키는 Luck2share(다른 서비스들의 서버)에 둔다
  2. 사용자가 로그인할 때 사용자의 필수정보와 토큰 생성시간과 관련한 데이터를 묶는다. 시간을 묶으면 생성할 때마다 토큰이 확연히 달라지기 때문에 유출의 위험이 적다.
  3. 2에서 만들어진 데이터를 백오피스 서버의 비밀 키로 암호화해 토큰으로 만든다.
  4. 통신이 필요할 때 토큰을 Luck2share 에 전달한다.
  5. Luck2share 에서는 미리 받아놓은 공개 키로 토큰을 복호화한다.
  6. 복호화가 정상적으로 이루어지고 조건에 맞으면 API 호출결과를 돌려주고 그렇지 않으면 401 Unauthorized를 내보낸다.

백오피스 API 서버에서 사용한 프레임워크는 Restify 로, Node 의 jwt 모듈과 express-jwt 미들웨어를 사용해 큰 어려움 없이 Private API를 구축할 수 있었다.

(사실 키 암호화에 대해 깊은 조예가 있어서 떠올린 것이 아니라, jwt 모듈의 기능을 살펴보다 알게 되었다. :-P)

OAuth Login 과 만료시간

앞서 밝혔듯 KStyletrip.com은 Google Apps for Business를 사용하고 있다. 따라서 구글에서 제공하는 OAuth 인증을 사용하면 되므로 회원가입, 회원정보 수정과 같은 것을 구현할 필요가 없었다. 단지 OAuth Consumer로서 회원정보를 활용하는 방법을 구현하면 되었다. 다만 Google에 로그인할 때 제공하는 Access Token의 만료시간은 1시간으로 굉장히 짧아서 API 호출 때마다 이 정보에 의존할 수는 없었다.

따라서 별도의 토큰을 만들어 유지하기로 했다. 이 토큰은 위에 설명한 Private API에 접근하는 토큰과 같은 것이다. 이 토큰을 만들고 사용하는데 만료기간이 너무 짧으면 불편할 것이고 너무 길면 퇴사하거나 변동이 생긴 직원에 대해 대처하기 어려워질 것으로 판단했다.

그래서 아래와 같은 방법으로 구현했다.

OAuth 인증 시에 오프라인 접근권한을 받을 수 있도록 했다. 오프라인 접근권한을 받으면 Refresh Token을 얻어올 수 있다. 이렇게 받아온 Refresh Token으로 백오피스 API 서버가 주기적으로 Google의 OAuth 서버에서 Access Token을 받아오도록 했다. 이렇게 하면 자동으로 사용자의 유효성을 측정할 수 있게 되어 퇴사한 직원에 대해 걱정하지 않아도 된다.

그리고 유효성이 확인된 토큰들을 메모리에 (사실은 API 서버의 변수에) 넣어두고 최초 로그인시 발급된 토큰을 갱신할 수 있는 API 를 만들었다. 변수에 저장된 토큰들은 서버를 새로 시작하면 날아가 버리기 때문에 다른 방법으로 보완할 예정이다. 2014. 8. 3 추가: nedb (Node Embeded DataBase) 를 사용했다.

프론트엔드에서는 주기적으로 갱신 API를 호출해 토큰을 갱신하는 동시에 자체토큰을 가진 사람이 Google에서도 유효하게 판단하는지를 확인했다.

후기

일주일 남짓한 시간에 우리는 꽤 안정적인 백오피스 플랫폼을 갖게 되었다. 그리고 이제 실제로 비즈니스에 필요한 API를 필요할 때마다 개발하기만 하면 된다.

참고

VirtualBox – Vagrant Disk IO 성능개선 방법

  • VirtualBox 에서 제공하는 공유폴더 기능은 심각한 퍼포먼스 저하가 있다. 따라서 다른 방법으로 파일을 공유하는 것이 성능에 훨씬 유리하다.

    • 참고: Vagrant 개발자인 Mitchell Hashimoto 의 VM 내 파일시스템 성능비교 https://mitchellh.com/comparing-filesystem-performance-in-virtual-machines

    • 해결법 – shared folder 를 NFS 로 공유하기 또는 Rsync 로 공유하기 (Rsync는 Vagrant 1.5 이상에서 동작)

      • NFS 로 만드는 방법 간단요약 – 참고: https://coderwall.com/p/uaohzg https://docs.vagrantup.com/v2/synced-folders/nfs.html

        • Host only Adapter 추가 – Virtualbox > VM

        • private_network 행 추가 – Vagrantfile

        • shared_folder 에 type: nfs 추가 – Vagrantfile

      • Host OS 의 /etc/exports (NFS 설정 파일) 에 Vagrant 가 자동으로 행을 추가하기 때문에 vagrant up 도중 sudoer 패스워드 물어봄

    • Rsync 는 일반적인 Rsync 와 동일하게 동작한다. Guest 와 Host 양쪽에 rsync 명령어가 있으면 활용이 가능하다. 윈도우에서도 msysgit, MinGw, Cygwin 에서 Rsync 기능 제공 중

      • 다른 shared folder 타입들과 달리 rsync 명령어를 활용하기 때문에 Rsync 는 vagrant up 때 한번 싱크. 따라서 자동으로 파일 변화를 감지해 싱크를 맞춰주는 vagrant rsync-auto 를 사용해야 함.

하이브리드 프론트엔드 개발 5원칙

3년 정도 하이브리드 플랫폼들을 경험했다. 하이브리드 플랫폼은 정말 여러 곳에서 쓰이고 있다. 하지만 그 모든 플랫폼이 크롬, 파이어폭스만큼 우수한 디버깅 환경을 제공하지는 않는다. 에뮬레이터를 지원하지 않는 경우는 부지기수이고 한 줄이라도 수정하면 앱을 종료했다 다시 켜야 변경사항이 반영되는 때도 있다.

오늘도 하이브리드 개발 중에 API 서버가 죽었다. 일정도 꼬인 김에 하이브리드 개발 때 도움이 될만한 팁을 공유해본다.

독립된 API 서버를 갖춰라

가능하다면 독립된 API를 갖는 게 좋다. 하이브리드 앱은 API와 통신이 많은 부분을 차지한다. 끊임없이 개발되고 있는 와중에 개발 중인 API가 안정적이기를 바라는 것은 무리다. 하지만 최소한 지금 프론트엔드 개발 중인 API는 안정적이어야 한다. 따라서 독립된 API 서버를 확보해서 현재 개발 중인 부분의 API 는 안정적으로 동작하도록 버전 관리 시스템의 리비전을 변경하면서 개발하자. “가능하다면” 이란 단서를 달았다. 만약 독립된 API 서버가 없다면 원활한 개발을 포기하면 된다.

ps. 단순한 프로젝트라면 API 서버를 대체할만한 목업 서버라도 만들어서 쓰기를 강력히 추천한다.

ps2. Vagrant나 Docker 사용도 추천할만 하다.

프락시를 활용하라

하이브리드 플랫폼에서는 hosts 파일을 변경하기 어렵다. 따라서 다른 방법으로 우회해야 하는데 그것이 바로 프락시다. 단말기의 네트워크 설정에서 프락시 서버를 사용하도록 하고 프락시 서버설정을 변경해 hosts 와 같은 효과를 낼 수 있다. 리버스 프락시와 PAC(Proxy Auto Config) 를 사용한다면 더 편리한 개발이 가능하다. 단말에 탑재된 소스 중 일부만 로컬서버에서 동작하게 할 수도 있고 문제가 있는 API 만 다른 API 서버로 우회하도록 동작시킬 수도 있다. 특히 소스를 곧바로 고칠 수 없는 환경에서 프락시는 활용도가 무척 높다. 가끔 프락시 조차 지원하지 않는 단말기가 있다. 이럴 때는 Wireless AP 를 만들어 해결하는 방법도 있다.

최대한 웹 브라우저에서 확인할 수 있도록 개발하라

하이브리드 애플리케이션은 단말 전용 API를 이용해 브라우저보다 더 많은 기능을 사용할 수 있다. 하지만 전용 API 를 사용한 특별한 부분을 제외하면 거의 모든 기능은 브라우저로도 동작할 수 있다. 어떤 하이브리드 플랫폼도 브라우저만큼 개발환경을 지원해주지 못한다. 따라서 기능 대부분을 브라우저에서 확인할 수 있도록 개발하는 것이 좋다.

가끔은 브라우저용 폴백을 직접 만들어야 할 때도 있다. 예를 들어 화면간에 파라미터를 전달하는 기능은 URL hash에 JSON 을 담아 전송하면 쉽게 파라미터를 전달할 수 있다. 하이브리드 플랫폼에서 데이터베이스를 사용할 수 있다면, Ajax로 데이터베이스에 접근하는 간단한 서버프로그램을 작성해 활용하면 브라우저에서도 쉽게 확인할 수 있다.

플랫폼에서 제공하는 디버깅 도구에 대해 공부하라

브라우저에서 디버깅하는 방법에 대해 잘 알고 있는 만큼 개발중인 디바이스 플랫폼에 대해서도 공부가 필요하다. 예를들어 안드로이드 플랫폼에서는 adb 를 사용할 수 있다. adb 를 통해 개발중인 소스를 기기로 복사할 수 있고 로그도 곧바로 볼 수 있다.

리모트 디버깅 도구를 활용하라

iOS6 와 OSX Lion 이상의 환경에서는 사용한다면 Safari 브라우저를 통해 웹뷰의 디버깅이 가능하고, 최근의 안드로이드 브라우저도 크롬을 통해 디버그할 수 있다. 위 플랫폼에서 벗어난 경우엔 Weinre 를 사용해보는 것을 추천한다.

한마디로 정리하면 – 가능한 모든 것을 추상화하라.