비바 리퍼블리카로 이직한 이야기

2016년 11월 20일, 나는 8년 10개월간 근무한 네이버를 퇴사하고, 그 바로 다음날인
21일 스마트폰 송금 서비스 토스를 만드는 비바 리퍼블리카에 입사했다.

입사를 결정하게 된 계기

작년 즈음부터 스타트업에서 일해보는 것도 괜찮을 것 같다는 생각을 하게 되었는데,
그 와중에 비바 리퍼블리카에서 보낸 구인 메일을 받고서 이직을 생각하게 되었다.

2주일 정도 생각을 해보다가 한번 면접을 보기로 결정하고 회신 메일을 보냈다. 나는
내가 좋아하는 서비스를 만들기를 원했고, 비바 리퍼블리카에서 만드는 토스는 UX가
굉장히 훌륭해서 매우 만족스럽게 쓰고 있다. 그것이 입사를 결정한 가장 결정적인
이유이다.

채용 과정

이후 진행은 일사천리였다.

10월 2일(일), 입사 제의를 받아들이기로 결정하고 회신
10월 4일(화), 오프라인에서 비바 리퍼블리카가 어떤 회사인지 이야기를 들음
10월 5일(수), 메일로 이력서 전달
10월 7일(금), 기술 면접
10월 10일(월), 최종 면접
10월 11일(화), 최종 합격 및 오퍼 받음
10월 12일(수), 오퍼 수락

면접을 보기로 결정하고 최종적으로 오퍼를 받아들이기까지 고작 10일밖에 걸리지
않았다. 정말 놀라운 속도였다.

퇴사 및 입사

10월 17일(월), 네이버 퇴직 신청
11월 5일(금), 네이버 마지막 출근
11월 20일(일), 네이버 퇴사
11월 21일(월), 비바 리퍼블리카 입사

2주간 휴가를 갖고 비바 리퍼블리카에 입사하였다.

여담

비바 리퍼블리카에 이력서를 보낸 날, 적립 서비스 도도포인트를 만드는 스타트업인
스포카에도 이력서를 보냈다. 스포카는 오픈소스 활동을 적극적으로 하는 점이
매력적이어서 관심을 갖고 있던 회사였다.

하지만 아쉽게도 스포카에서 서류 전형 합격 메일을 받았을 때는 이미 내가 비바
리퍼블리카의 오퍼를 받은 뒤였기 때문에 스포카의 면접을 보는 일은 없었다.
스포카의 채용 프로세스가 느리지는 않았지만 비바 리퍼블리카가 너무나도 빨랐다.

Advertisements

wordpress.com로 이사

원래 cafe24 가상 호스팅에 설치형 워드프레스를 쓰고 있었는데, 때때로 서버가 죽어서 좋지 않았다. 죽어도 알려주지도 않는다는 점은 더욱 나빴다.

그래서 서비스형 워드프레스로 이사왔다. 도메인 연결비용 연 13달러만 내면 되고 서버가 잘 죽지도 않을 것 같고 죽더라도 알아서 살려낼테니.

disqus로 댓글 단 건 옮겨오지 못하고 백업만 했다. xml로 export를 하기는 했는데, 여기로 import 하는 방법은 모르겠다.

구글 크롬으로 구글에 접속하면 HTTP/2가 아닌 SPDY/3.1을 사용하는 이유

구글 크롬을 이용해서 구글 사이트에 접속하면 HTTP/2가 아닌 QUIC+SPDY/3.1로
동작하게 된다. 왜 HTTP/2가 아닌 SPDY/3.1을 사용하는 것일까?

내 생각엔 명세상 QUIC과 HTTP/2를 동시에 사용할 수 없어서가 아닐까 싶다.

HTTP 명세를 살펴보자. 우선 HTTP/1.1은 TCP를 강제하지 않는다. 신뢰할 수 있는
transport layer 위에서 구현되어 있기만 하면 된다.

HTTP is a stateless request/response protocol that operates by
exchanging messages (Section 3) across a reliable transport- or
session-layer “connection” (Section 6).

https://tools.ietf.org/rfc/rfc7230.txt

다음 문장에서도 그 사실을 확인할 수 있다.

Although HTTP is independent of the transport protocol, the “http”
scheme is specific to TCP-based services because the name delegation
process depends on TCP for establishing authority.

https://tools.ietf.org/rfc/rfc7230.txt

TCP를 강제하지 않는 것은 SPDY/3.1 역시 마찬가지다.

SPDY adds a framing layer for multiplexing multiple, concurrent streams
across a single TCP connection (or any reliable transport stream).

https://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1

반면에 HTTP/2는 명시적으로 TCP를 요구한다.

An HTTP/2 connection is an application-layer protocol running on top
of a TCP connection ([TCP]).

https://tools.ietf.org/rfc/rfc7540.txt

구글에서 구현한 QUIC 프로토콜은 TCP의 영역인 transport layer를 포함한다.
따라서 QUIC을 사용한다는 것은 TCP를 사용하지 않는다는 것이므로 QUIC 위에서
HTTP/2를 동작시키는 것은 HTTP/2 명세의 정의상 불가능하다.

변정훈님의 트윗을 보고 생각나서 적어보았다.

ps. Brian Hong님의 트윗에 따르면 QUIC은 TCP만을 대체하는 것이 아니라 SPDY도 대체하는 것이라고 한다. 확인해보니 QUIC은 TCP+TLS+SPDY 혹은 TCP+TLS+HTTP/2와 동등하다고 한다.

gnome에서 hidpi 1.5배 스케일

요새 hidpi 지원하는 모니터/노트북들이 많은데, 이런 디스플레이의 경우 gnome은 자동으로 2배로 스케일을 해 준다. 하지만 솔직히 2배는 너무 크다. 1.5배 정도가 적당할 것 같은데, 스케일은 오직 정수 단위로만 지원된다.

하지만 다음과 같이 스케일은 1배로 하고, 텍스트만 1.5배로 하는 걸로 어느정도 흉내는 낼 수 있다.

gsettings set org.gnome.desktop.interface scaling-factor 1
gsettings set org.gnome.desktop.interface text-scaling-factor 1.5

그럭저럭 만족하면서 쓸 수 있는 수준은 될 것이다.

우분투에서 와이파이가 안될때

나는 맥북에어에 우분투를 사용한다. MacOSX를 쓰다가 수 개월 전에 넘어왔다.

우분투가 MacOSX보다 못한 점 중 하나가 와이파이가 잘 안된다는 점이다. 단순히 늦게 연결되는 정도가 아니라 아예 불통인 경우가 수두룩하다.

우분투에서 인터넷이 안될 때 시도해 볼 수 있는 몇가지 팁을 적어본다.

애플릿 재시작

무선 인터넷이 안되서 와이파이 애플릿에서 AP를 바꿔보려고 하는데 전혀 먹통인 경우가 있다. 아무리 클릭해도 아무런 반응을 하지 않는다.

이럴 땐 그냥 애플릿을 재시작하면 된다. 우분투에서 사용하는 와이파이 애플릿 이름은 nm-applet이다. killall로 죽이고 다시 띄우자.

드라이버 바꿔보기

애플릿에는 아무 문제가 없는데 아무리해도 AP에 연결이 안되는 경우가 있다. 이럴 땐 드라이버를 바꿔보자.

맥북에어 + 우분투에서 쓸 수 있는 드라이버는 wl(broadcom closed driver)과 brcmsmac(opensource driver)의 두 가지가 있는데 wl로는 잘되고 brcmsmac으로는 안 될 때가 있는가 하면 그 반대의 경우도 있다.

wl을 쓰려면 Applications > Additional Drivers에서 Broadcom STA wireless driver를 켜면 된다. 혹시 wl 드라이버를 블랙리스트에 추가한 상태라면 지운다.

$ sudo rm /etc/modprobe.d/blacklist-wl.conf

brcmsmac을 쓰려면 wl을 블랙리스트에 넣고, /etc/modules 파일에 brcmsmac을 추가한다.

$ echo 'blacklist wl' |sudo tee -a /etc/modprobe.d/blacklist-wl.conf
$ echo 'brcmsmac' |sudo tee -a /etc/modules

둘 다 안된다면 업데이트된 버전의 wl을 사용해보자. 여기에 업데이트하는 방법이 나와있다.

그래도 안되면

주위에 쓰는 사람이 많아서 안되는 경우도 있다. 똑같이 쓰는 사람이 많아도 MacOSX에선 잘되고 우분투에서는 안될 수 있다. 사람이 줄어들기를 기다리자.

한달간 매일 블로깅을 해보고

9월 한달동안 하루도 빠지지 않고 이 블로그에 포스팅을 했다. (이 포스팅을 포함해서)

어디선가 좋은 프로그래머가 되기 위해서는 블로그를 성실하게 운영해보는 것이 좋다는 이야기를 들은 것이 계기이다. 성실하게 운영하려면 포스팅하는 습관을 들여야 할 것이고, 습관을 들이기 위해서는 하루도 빼놓지 않고 매일 하는 것이 가장 좋은 방법이라고 생각했다. 이 과정에서 문제점을 발견하기도 했지만, 목표로 한 기간 동안에는 무시하고 계속 진행했다.

한달간의 매일 블로깅에 대해 스스로 분석한 결과를 적어본다.

포스팅 시간 분석

기록된 로그를 통해 나의 포스팅 시간을 분석했다. 여기서 포스팅 시간이란, vim을 열어 포스트를 작성하기 시작해서 vim을 종료하기까지의 시간이다. 따라서 이 작성 시간에는 워드프레스를 통해 웹으로 편집한 시간은 제외되므로 5분 정도 더하는 것이 정확할 것이다. 포스트 작성 도중에 인터넷을 뒤적거리거나 한 시간은 포함되지만, 작성 전에 인터넷으로 자료를 수집한 시간은 포함되지 않는다.

지난 30개의 포스트 중 로그가 잘 남아있는 24개를 대상으로 분석해 본 결과,

  • 평균 포스트 작성 시간은 61분이다.
  • 가장 빨리 작성한 포스트는 “iOS6 사파리의 POST 캐싱 버그에 대해“로 12분이 걸렸다. 사실 이 포스트의 경우 인터넷으로 먼저 자료를 수집한 뒤 작성을 시작한 것도 적게 걸린 이유 중 하나이다.
  • 가장 오래 작성한 포스트는 “개인위키를 10년간 쓰며 배운것“으로 2시간 48분이 걸렸다. 데이터 수집을 위해 내 개인위키의 히스토리를 탐색하거나 하는 데 많은 시간을 썼기 때문이다. 순수하게 포스트를 작성한 시간만 계산하면 68분이다.
  • 도저히 쓸 것이 없으면 내 개인위키를 뒤져서 옛날에 조사했던 것을 토대로 올렸다. (예:
    ECMAScript의 Object와 Property, 3-way merge 알고리즘에 대해)

얻은 것

  • 글을 빨리 쓸 수 있게 되었다. 원래 나는 글을 빨리 쓰지 못해서, 과거(2004-2005년)에 블로그를 운영할 때는 1시간 내로 쓴 포스트는 거의 없었다. 하지만 이번 매일 블로깅 중에는 1/3에 달하는 포스트를 30분 내로 작성했다.

발견된 문제점

  • 다른 사람에게 보여주기 위한 글로서는 부족하다는 생각이 드는 경우도 꽤 많았다. 예를 들어 “3-way merge 알고리즘에 대해“는 지나치게 많은 부분을 생략했기 때문에 그냥 읽고서는 이해하기가 매우 어렵다. 오로지 하루에 한번이라는 꾸준함에 집중했기 때문에 이러한 사실을 알고서도 그냥 포스팅했다.
  • 쓰다가 귀찮아져서 인터넷질을 하느라 많은 시간을 낭비하는 경우도 종종 있었다.
    vim에 능숙해지는 법“가 그런 포스트 대표적인 예이다. 별 내용도 없는 포스트임에도 불구하고 포스트를 쓰기 시작해서 끝내는 데 까지 2시간 36분이 걸렸다. 인터넷 뉴스에서 아무 상관없는 기사를 읽거나 vimgolf에 가서 노느라 많은 시간을 썼다. vimgolf 하는데만 1시간 15분을 썼다. 대개 딱히 쓰고 싶지 않은 주제에 대해 포스팅을 하려고 할 때 이런 현상이 일어난다.
  • 포스팅하는데 1시간 정도 걸린다고 해도, 그 전에 뭘 쓸지 고민하며 빈둥대는 시간도 상당하기 때문에 실제로는 총 1시간 30분 정도는 소모하는 것으로 보는 것이 맞을 것이다. 블로그의 포스팅에 매일 1.5시간씩 쓰는 것은 다소 과한 감이 있다.

개선방향

매일 포스팅하는 것은 과연 쉽지 않은 일이다. 쓸거리는 갈수록 줄어들 것이고 그렇게 되면 포스트를 쓰는 시간보다 뭘 쓸지 고민하느라 낭비하는 시간이 점점 늘어날 것이다. 따라서 둘 중의 하나를 택해야 한다. 별로 영양가 없는 글이라도 꾸준히 포스팅하거나, 아니면 포스팅 횟수를 줄여야 한다.

우선 후자를 시도해보고자 한다. 10월에는 1주일에 두번씩만 포스팅을 할 것이다. 1주일에 두번이라는 횟수는 습관으로 만들기에는 애매하지 않은가 하는 생각이 들긴 한다. 일주일동안 계속 안 쓰다가 토, 일에 한개씩 쓸 가능성이 농후하다. 그러나 9월에서의 실험에서도 그랬듯이, 어떻게 포스팅을 할 것인가에 대해 결정하기 위한 데이터를 얻기 위해 부작용은 감수하고 진행한다.

ps. 내가 로그를 남긴 방법에 대해서는 “내가 맥으로 뭘 하고 있는지 로그 남기기 (애플스크립트)“나, “내가 리눅스로 뭘 하고 있는지 로그 남기기 (파이썬)“를 보라.

3-way merge 알고리즘에 대해

Git에서 두 브랜치를 머지할 때, 기본적으로 3-way merge 알고리즘을 사용하게 된다.

어떤 sequence A, B와 그 둘의 base인 sequence O가 있다고 하자. Git으로 치면 A, B는 머지할 브랜치, O는 base commit이 된다. sequence의 각 item은 소스코드의 한 줄이라고 생각하면 된다.

이렇게 A, O, B가 있을 때,

  1. A, O, B에 대해 [Longest common subsequence](이하 LCS) (( 이름 그대로 가장 긴 공통 sequence이다. 알고리즘은 http://rosettacode.org/wiki/Longest_common_subsequence 의 예제코드들을 보면 쉽게 이해할 수 있을 것이다. )) 를 찾는다. A, O에 대해 LCS를 먼저 찾고, O, B에 대해서도 찾은 다음 이 LCS들을 통해 얻는다.
  2. 위의 LCS를 이용해 모든 chunk에 대해 stable, unstable 여부를 검사한다. A, O, B가 모두 같다면 stable이고 아니면 unstable이다.
  3. unstable chunk에서 A와 O가 같지만 B가 다르다면 B를 택하고, B와 O가 같지만 A가 다르다면 A를 택한다. 셋이 모두 다르다면 충돌로 처리한다.

A Formal Investigation of Diff3에 소개된 예를 통해 위의 알고리즘을 설명하겠다.

다음과 같은 세 sequence가 있다면,

A = [1, 4, 5, 2, 3, 6]
O = [1, 2, 3, 4, 5, 6]
B = [1, 2, 4, 5, 3, 6]

A, O의 LCS는 다음과 같고

A = [[1], [4, 5], [2, 3], [],     [6]]
O = [[1], []      [2, 3], [4, 5], [6]]

O, b의 LCS는 다음과 같다.

O = [[1, 2], [3], [4, 5], [],  [6]]
B = [[1, 2], [],  [4, 5], [3], [6]]

셋의 LCS를 찾으면 다음과 같다.

A = [[1], [4, 5], [2], [3],       [6]]
O = [[1], [],     [2], [3, 4, 5], [6]]
B = [[1], [],     [2], [4, 5, 3], [6]]

위에서 [1], [2], [6]은 셋이 모두 같으므로, stable chunk라고 하며 그 외에는 unstable chunk라고 한다. unstable chunk에 대해서 conflict가 발생헀는지 찾는다. A, O, B가 모두 다른 chunk가 있다면 conflict다.

A' = [[1], [4, 5], [2], [3],       [6]]
O' = [[1], [4, 5], [2], [3, 4, 5], [6]]
B' = [[1], [4, 5], [2], [4, 5, 3], [6]]

2번째 chunk는 A만 [4, 5]이고 O와 B는 같으므로([]) A에서만 변경이 있었음을 의미한다. merge하면 따라서 [4, 5]가 선택된다. 4번째 chunk인 [3], [3, 4, 5], [4, 5, 3]은 A’, O’, B’가 모두 다르므로 conflict다.

위 결과를 출력하면 다음과 같다.

1
4
5
2
<<<<<<< A
3
||||||| O
3
4
5
=======
4
5
3
>>>>>>> B
6

그러나 실제 patch, diff3, Git등으로 merge를 해 보면 이보다 더 쉽게 충돌한다. 주위 문맥을 고려하기 때문이다. 대개 전후 3줄 이내에 변경이 있으면 충돌로 간주한다.

3-way merge에 대해 더 자세히 알고 싶다면 A Formal Investigation of Diff3을 보라. Longest common subsequence를 포함해 3-way merge의 전 과정에 대해 자세히 설명하고 있다.