이 글은 샌프란시스코 오피스 투어 #2에서 이어진 글이다.

이제 오피스 투어도 좀 익숙해지고 있었다. 영어로 의사소통도 쉽지 않지만 할 얘기도 있어야 하므로 점점 저녁에 들어오면 다음 날 방문할 회사의 서비스나 기술들을 살펴보고 공개된 기술자료 같은 걸 보면서 질문할 질문 리스트를 작성했다. 아무래도 우리가 부탁해서 찾아간 거다 보니 말할 소재를 잃으면 좀 미안하기도 하고 영어다 보니 현장에서 영어가 팍팍 잘 튀어나오는 것도 아니니 미리 질문을 만들어 놓으니 좀 나았다.

Sourcegraph

Sourcegraph는 Github에서 코드를 분석해서 코드리뷰를 쉽게 해주거나 사용한 프로젝트 등을 알려주는 서비스다. Github 프로젝트의 소스코드를 분석해서 웹상에서 코드의 정의로 바로 이동하는 등 코드 리뷰를 할 때 분석이 쉽도록 해주고 API를 수정할 때 해당 API를 누가 사용하고 있는지 확인해서 알림을 보내거나 예제로 참고하기 위해 특정 라이브러리의 함수를 사용한 곳을 검색할 수 있다. 나도 원래 서비스에 대해서는 잘 몰랐는데 Sourcegraph는 Go 언어를 쓰는데 오픈소스로 공개한 프로젝트도 많고 외부 발표도 많이 해서 Go쪽에서는 많이 알려진 듯 하다.

나는 올 초에 읽었던 5 surprisingly painful things about client-side JS라는 글도 Sourcegraph의 글이라는 걸 이번에 알게 돼서 반갑기도 했다. 원제가 "Why we left AngularJS"라서 글이 당시 많이 퍼졌었다.

사무실은 중심가에서 멀지 않은 곳에 있었는데 입구에서 벨을 누르자. 마케팅 쪽은 담당하고 있는 듯한 Charles Vickery가 내려왔다. 4층에 있었는데 엘리베이터는 공사장 같은 데서나 보던 문이 없이 셔터 같은 걸 내리고 버튼을 누르고 있으면(계속 누르고 있어야 한다는 의미) 올라가는 클래식한 엘리베이터였다. 우리 온다고 미리 티셔츠랑 스티커도 준비해 놨고 전날 점심 메뉴주문을 받아서 시킨 햄버거가 테이블에 놓여 있었다.(친절해!)

Sourcegraph는 이번에 방문한 회사 중 가장 작은 규모의 회사로 직원이 5명인고(4명이 개발자이고 한 명이 사업이나 마케팅을 하는 듯) 길게 생긴 사무실에 가운데는 회의도 하고 밋업도 할 수 있는 공간같이 있고 끝에는 일하는 공간인 방이 있었다. 작은 규모의 스타트업이다 보니 서비스를 어떻게 생각하는지 피드백도 많이 궁금해했고 한국에 돌아가서 얘기도 많이 해 달라고 부탁도 했다.

5 surprisingly painful things about client-side JS에 대해서...

정확히는 SPA(Single Page Application)를 버리고 서버사이드 렌드링 100%로 갈아탄 얘기였는데 초기에 제목을 "Why we left AngularJS"라고 하는 바람에 글의 의도가 다르게 흘러가서 고생을 좀 했다. 현재는 React.js를 만족하며 사용하고 있고 전체적으로 보면 서버 렌더링이 95%정도이고 클라이언트 렌더링이 5%이고 의존성은 webpack을 사용 중이다.

업무에 사용하는 서비스나 도구는?

Github을 헤비하게 써서 대부분의 논의는 Github issue를 사용하고 모든 기록도 이슈에 모으는 편이다. 로깅에 Papertrail을 사용하고 그룹 채팅으로 Flowdock를 사용하고 있다.

작은 규모의 회사인데 외부 발표나 오픈 소스 프로젝트를 많이 진행하는 이유는?

자신들도 다른 사람들에게 많이 배웠기 때문에 자신들이 프로젝트를 하면서 배운 것을 다른 사람들과 다시 공유하고 있는 것뿐이다. 그리고 콘퍼런스 등에서 발표하거나 오픈 소스 프로젝트를 진행하면 서비스나 프로젝트에 대한 피드백을 받을 수 있고 서비스를 홍보하기 위한 전략이기도 하다.

Go 버전 관리는 어떻게 하는가?

Godep을 사용하고 있다.

Sourcegraph 사람들은 셀카봉을 주자 특히 신기해하고 재밌어 했다. 전날 급하게 서비스랑 기술을 공부해서 갔지만 꽤 재밌는 시간이었고 우리한테도 잘 대해줬다. 회사 방문해서 친근하게 얘기 나누고 분위기 파악해 보기에는 작은 회사가 더 좋은 것 같기도.. ㅎ

CoreOS

CoreOS는 Docker와 함께 주목받은 컨테이너를 위한 경량 OS다. 난 써본 적은 없고 같이 갔던 anarcher님이 이쪽을 잘 알아서 대충 개념 정도만 알고 있는 정도이다. CoreOS의 Jonathan Boulle가 올해 Deview에서 발표를 하러 왔었는데 어쩌다 보니 끝나고 자정까지 감자탕을 함께 먹게 돼서 끝나고 11월에 가면 사무실 놀러 가도 되냐고 미리 얘기해놨던지라 메일 보내서 자연스럽게 약속을 잡았다. 이때도 CoreOS를 많이 쓰고 계신 subicura님과 함께 방문했다.

CoreOS는 샌프란시스코 남쪽으로 외진 곳에 있어서 Uber를 타고 이동했다.(돌아올 때는 버스 타고 무서운 동네의 스릴감을 느끼면서 돌아왔다.) 1층에서 벨을 누르자 brian이 내려와서 반갑게 맞아줬다. CoreOS는 2, 3층을 쓰고 있었는데 2층에는 회의실 하나 정도만 있고 사무실은 3층에 있었다.

전체 직원은 잘 모르겠지만, 우리가 방문했을 때는 7~8명 정도가 있었고 뉴욕 쪽에도 4명이 일하고 있다고 했다.

사무실을 구경하고는 Jonathan Boulle와 2층 회의실로 내려가서 brian이 서비스나 기술에 대해서 설명해 주는 시간을 가졌다. 우리가 다 개발자들이다 보니 이렇게 시간을 내서 시연을 해주고 설명해주는 게 무척 고마웠다. TV에는 행아웃이 세팅 되어 있었는데 이걸로 컨퍼런스 콜등을 하는 것 같았고 저런 식으로 안 써봐서 모르겠는데(크롬캐스트인가?) 시연도 그 안에서 다 했다.

quay

가장 먼저 보여준 건 CoreOS가 인수한 quay인데 컨테이너 이미지 저장소이고 Docker의 Docker Hub와 같은 포지션을 가진 서비스다. 미리 알고 있던 서비스가 아니라서 새로운 기능인지 아닌지 모르겠지만 타 서비스와 비교하면 이미지의 크기가 아주 작다고 자랑을 하면서 히스토리를 압축해서 다시 하나로 만들 수 있는 squashed image 기능도 보여주었다. 이미지를 Pull 받은 로그도 웹상에서 다 볼 수 있고 사용자별로 권한을 제어하거나 인증 방식을 토큰이나 비밀번호를 사용하도록 세세하게 제어할 수 있다. 물론 모든 기능은 API로 다 열려있고 이미지를 Dockerfile로 만드는 대신 Github 저장소의 webhook과 연결해서 소스를 커밋할 때마다 quay로 바로 가져올 수도 있다.

Base image는 무엇을 사용하는가?

이건 Jonathan과 brian이 역으로 물어온 것인데 우리가 그냥 Ubuntu를 사용한다고 하자 Buildroot를 보여주었다. Buildroot는 CoreOS의 서비스는 아니고 임베디드 리눅스의 이미지를 만들어 주는 도구인데 이미지를 만들 때 커널은 어떤 커널을 사용하고 glib이나 패키지 매니저 등을 다 세세하게 선택해서 이미지를 만들 수 있다. 정확히는 못 물어봤지만, Ubuntu가 호스트 OS로는 무거우니까 Buildroot도 원하는 이미지를 만들어서 쓰라는 의미로 보이는데 프로덕션에 적용하려면 이런 식으로 커스터마이징이 필요하다는 늬앙스를 풍겼다.

Base image 서비스를 만들 생각은 없는가?

Buildroot로 만들 수는 있지만 모든 개발자가 커널이나 저수준 도구까지 다 아는 것은 아니고 buildroot가 아주 편해 보이지는 않아서 베이스 이미지를 만들어주는 서비스를 따로 만들 생각이 없는지 물었다. 필요한 부분이라고는 생각하지만, 자신이 시스템 엔지니어가 아니기도 하고 CoreOS가 해야 하는 부분인지는 잘 모르겠다고 했다.

Toolbox

얘기하다가 지금 얘기해 줄 수는 없지만 CoreOS에서 다음 달에 큰 발표를 할 거라는 얘기를 했다. 우리가 궁금해하면서 힌트라도 좀 달라고 하자 Infrastructure in CoreOS라고만 대답했는데 지금 와서 보면 이게 Rocket이 아닌가 생각한다.(이후에 다른 발표가 또 있을 수도 있고...) 그러면서 대화는 CoreOS의 Toolbox로 넘어갔다. 당시 다음 달의 발표가 뭔지 몰랐으므로 왜 Toolbox로 대화가 이어졌는지는 우리도 모른다. 아무튼, Toolbox를 써봤느냐면서 시연을 했는데 CoreOS 상에서 Toolbox로 이미지를 띄우고 익스포트 한 다음에 이미지를 제거하고는 Toolbox로 컨테이너 안으로 들어가서 호스트와 컨테이너를 왔다갔다하면서 프로세스 등을 확인하는 걸 보여줬다. 계속 물어보면서 우리끼리도 얘기를 나누었지만, 우리 중 아무도 지금 뭘 보여주고 있는 건지 제대로 이해하지 못했다. 디버깅 목적으로 사용하는 것은 확실한데 구체적인 사용례를 이해하지 못했고 Brian은 호스트 OS와 컨테이너 양쪽에 모두 팔을 넣고 있는 것이라고 설명했지만 역시나 이해는 제대로 못 했다. Toolbox를 오랫동안 설명듣느라고 우리는 모두 멘붕에 빠져서 티셔츠 하나 달라는 얘기도 못 했다. ㅠ

etcd

etcd는 0.5에서 많이 바뀔 것이지만 훨씬 안정화되었고 자동 마이그레이션을 지원할 것이다. 0.5부터는 standby 모드가 없어지고 금요일(11월 21일)부터 beta0을 릴리즈하고 매주 금요일에 릴리즈할 계획이다.

회사에서 사용하는 도구는?

Jenkins CI와 Travis CI를 모두 사용하고 당연히 Github은 쓰고 있다. 팀 커뮤니테이션에는 Slack을 쓰고 고객 지원에는 Zendesk를 쓰고 있다.

돈은 어디서...

주력 제품이 오픈 소스이므로 수익은 주로 컨설팅을 통해서 낼 것이고 현재도 소니 플레이스테이션과 진행 중인 부분이 있다. 그 외에도 quay를 통한 private 계정을 통한 수익을 계획하고 있고 기술지원에 대한 계약도 생각하고 있다. 다른 것보다 오픈 소스가 가지는 강력함을 신뢰하고 있다.

앞에 있는 사람이 Jonathan이고 뒤에 있는 사람이 Brian이다. CoreOS에서만 한 2시간 정도 있었는데 시연해주면서 설명을 해주니까 물어볼 것도 많고 재미난 시간이었다. 내가 CoreOS를 잘 몰라서 오히려 아쉬웠을 뿐... 얘기 중에 Brian이 Docker도 그렇고 CoreOS도 그렇고 새로운 것을 만들어낸 것이 아니라 기존에 존재하던 기술들의 좋은 부분을 모아서 컨테이너를 사용하기 쉽게 만들었을 뿐인데 이것이 정말 가치 있는 일이라고 했는데 동감한다.

Docker Meetup

Docker Meetup은 Yelp 본사에서 열렸는데 샌프란시스코 중심가에 위치하고 있었다.

Meetup이다 보니 사무실 안으로는 못 들어가서 세미나실과 식당이 연결된 곳까지만 들어갔다. 피자가 많이 쌓여있어서 배부르게 저녁을 해결했고 Yelp라 그런지 먹을 것도 잘 준비가 되어 있었다. 그냥 Meetup 참가자들도 맘대로 꺼내먹을 수 있었고 생맥주도 제공돼서 편하게 맥주나 따라먹으면서 Meetup을 기다렸다.

Building System Packages With Jenkins And Docker At Yelp

첫 세션은 시간표에는 없던 세션으로 Docker와 Jenkins로 Yelp에서 시스템을 어떻게 패키징했는지를 공유하는 세션인데 아마 Yelp에서 장소를 제공해주다보니 한 세션을 내어 준 게 아닌가 싶다. 다양한 OS나 환경에 대한 패키징을 해야 할 때 이전 같으면 종류별로 서버를 준비해 놓고 빌드했겠지만 Jenkins와 Docker를 이용해서 빌드를 돌릴 때 파이프라인으로 종류별로 컨테이너를 실행해서 빌드했다는 얘기였다.

"Sneak Preview of Docker Clustering" by Andrea Luzzardi and Victor Vieux

Docker에서 직접 와서 새로 도입될 클러스터링 기능을 시연하고 기술을 미리 소개하는 세션이었다. 아직 이 클러스터링 기능은 공개 안 된 것으로 알고 있다. Docker를 몰라서 자세히 정리하기는 어렵지만, 마스터(grand master)가 존재하고 마스터에 클러스터링할 서버를 등록한다. 마스터 서버에 명령을 내리면 여러 호스트에서 컨테이너를 실행할 수 있는데 cpu 1g를 지정하면 cpu 1G를 가진 서버에 컨테이너가 실행되고 메모리를 지정하면 해당 메모리를 가진 서버에서 실행되고 지정한 스펙의 서버가 없으면 오류가 발생한다. 물론 CoreOS의 fleet처럼 태그 기반으로 컨테이너를 실행하는 것도 가능하다.

이후 CloudHQ에서 Flocker를 소개하는 라이트닝 토크가 있었다.

이번 밋업은 끝나고 걸어오면서 anarcher님이랑 대화하는 시간이 더 즐거웠는데 Docker Clustering 발표에 꽤 흥분해 계셨다. ^^ 이는 꽤 흥미로운 부분인데 Docker를 중심으로 한 컨테이너 시장을 키우기 위해서 여러 회사가 협력해서 생태계를 만드는 구조이면서 자세히 들여다보면 Docker의 Docker Hub를 CoreOS가 quay로 뺏으려고 하고 CoreOS의 fleet 기능을 Docker가 클러스터 기능으로 빼앗아 오려고 싸우고 있는 구조이다. 물론 이 싸움에는 Google의 Kubernates도 있다. 같은 목표의 프로젝트를 진행하면서 치열하게 경쟁하는 구조가 오픈 소스 답다는 생각이 들었다. 물론 지금 시점에서는 플랫폼을 쥐고 있다고 볼 수 있는 Docker가 여러 부분에서 이점이 있다고 본다. 트위터가 사진을 지원하면서 twitpic이 날아가 버리듯이 Docker에 기능이 추가되면서 서드파티는 언제든 날아가 버릴 수 있으니... 그런 면에서 CoreOS가 Docker에 Rocket을 쏴버린 건 당연한 움직일지도..

Twitter

Twitter는 내가 정말 좋아하는 서비스라서 대부분 정보를 Twitter에서 얻고 모든 소셜활동을 Twitter를 거쳐 가게 구성해 놨다. 그래서 난 Facebook보다 Twitter의 가치를 훨씬 높게 치고 있다.(보통 내가 좋아하는 서비스는 잘 안 되긴 하지만... ㅠㅠ)

Twitter는 샌프라시스코의 Market 스트리트에 위치하고 있다. 중심가에서는 약간 벗어난 위치에 있는데 샌프란시스코에서 일종의 빈민가 같은 Tenderloin의 경계에 위치하고 있다. 나중에 듣기로는 이곳도 Tenderloin에 속해 있는데 Twitter가 들어오면서 분위기가 많이 달라졌다고 한다. 이전에는 가구건물인 곳을 사들여서 건물이 엄청나게 크다.

올 초에 실리콘밸리의 한국인 : K-Group과의 만남에 초대합니다!행사를 보다가 Twitter에 근무하시는 유호현님을 트위터상에서 알게 되었고 트위터 사무실 가고 싶다는 얘기를 하다가 담에 오면 연락 달라고 하셔서 이번에 연락을 드렸다.(일단 영어로만 얘기하다가 우리 말로 얘기하니까 편해!) Twitter는 회사가 크다 보니 미리 방문자 등록을 해서 입구에서 방문증을 받았다. 이 건물의 5층부터 11층까지 트위터가 이용하고 있는데 올라가서 기다리고 있으니까 유호현님이 나오셨다.

회사가 크다 보니 사무 공간에는 못 들어가 보고 식당에만 들어갔다가 왔는데 꽤 큰 식당이 여러 층에 걸쳐서 있었다. 다양한 메뉴가 있어서 취향에 맞게 맘껏 담아서 오랜만에 맛있는 걸 많이 먹었다. 밥 푸고 있을 때 식당에 CEO인 Dick Costolo가 있었다는데 나는 보지 못했다. ㅠㅠ 이 건물에는 2,500명 정도가 있고 개발자는 1,800명 정도 있다고 했다. Twitter는 개발자는 주로 본사로 불러서 같이 근무하는 분위기라고 한다.

조직 구조

수평적인 조직으로 구성되어 있고 매니저가 존재하지는 하지만 윗사람이라는 의식은 거의 없다. 프로젝트별로 매니저가 할당되어 있지만, 프로젝트의 업무는 각 팀 내에서 정하고 이를 매니저에게 알려주는 방식으로 진행되는데 2주 단위의 스프린트로 할 일을 정하고 이를 매니저와 공유한 뒤에 업무를 진행한다. 임원이 정기적으로 전체를 모아 놓고 비전을 공유하는 회의를 하고 있으며 이 회의에서 회사의 비전이나 방향을 공유하고 있다. 평가는 관리자가 따로 없으므로 팀원들끼리 피어 리뷰로 진행한다.

Twitter의 오픈소스 프로젝트

프로젝트를 진행하다가 오픈 소스로 하고 싶다고 매니저에게 얘기해서 동의하면 오픈 소스화가 진행된다. 팀에서 이번 한 달은 오픈 소스 작업만 하겠다고 해도 매니저가 크게 이의제기를 하지 않으면 그대로 진행되는 편이다. 상당한 실력을 갖춘 오픈 소스 팀이 별도로 존재해서 오픈 소스를 진행할 때 라이센스 처리도 해주고 프로젝트도 오픈 소스에 맞게 새로 말아주고 코드 리뷰까지 다 해준다. 트위터는 내부에서 Pants 빌드도구(Python + ant)를 사용하는데 최근에 유호현님이 작업하고 있는 트위터 한국어 처리기의 메이븐 빌드도 오픈 소스팀에서 말아 준 것이라고 한다.(개인적으로 Scala인데 SBT를 안 쓴 이유가 궁금하긴 했다.) 거의 모든 오픈 소스는 트위터 내부에서 사용하고 있는 프로젝트다.

트위터 한국어 처리기

한국어 파서의 경우 대부분 회사가 가지고 있지만, 오픈 소스는 없어서 대부분 회사가 각자 만들고 있었으므로 오픈 소스로 존재하면 의미 있을 것 같아서 공개하기로 했다고 한다.(Scala도 좀 만져본 상태라 공헌을 해볼까 하는데 시간이 잘 안 난다 ㅠ)

직급

트위터는 개발자가 D1, D2, Senior 단계로 되어 있고 그 위에는 임원급 개발자이다. 10년이 지나도 D2로 있는 개발자도 있지만 다들 크게 신경을 쓰지 않는 분위기이고 매니저로 이동하더라도 승진이라고 생각하는 사람은 아무도 없다. 샌프란시스코에서(트위터 말고) 연봉은 보통 12~15만 불 사이에 대부분 형성되어 있는 것 같다.(1억 연봉을 부러워하지만 우리가 3천~5천 정도에 보통 구성되어 있는 거 보면 최하 연봉선이 다를 뿐 간격차이는 비슷한 것 같다. 세금이 40%나 되고 집세 같은 거 생각하면 크게 차이가 나진 않는 느낌적 )

개발 문화

Twitter의 코드 베이스는 대부분 Scala로 되어 있다. Scala는 러닝 커브가 좀 있다고 생각하는데 자바를 잘하는 개발자도 트위터에 입사하면 프로젝트를 2~3개는 진행해야 Scala를 제대로 이해하게 되는 것 같다. 1년에 2번 정도 Hack Week이라는 행사가 있어서 한 주 동안은 새로운 아이디어를 개발한다.

사무공간에는 못 들어가 봐서 아쉽지만 나는 트위터 사무실에 와봤다는 것만으로도 감격스러웠다. ㅠ 우리말로 얘기하다 보니 다른 오피스때와는 달리 회사 분위기나 샌프란시스코 분위기에 관해서도 얘기를 편히 나누다가 점심 이후에 유호현님이 회의가 생기셔서 적당한 시간에 마무리하고 나왔다.

GoSF - Optimizing Go

GoSF - Optimizing Go 밋업은 New Relic 사무실에서 열렸다. 난 Go는 한번도 안해봤지만 일행중에 Go에 관심있는 사람이 있어서 갔다왔다.

약간 늦게 가서 저녁도 못 먹고(ㅠㅠ) 바로 세션을 들었는데 세션은 Go에서 성능개선 경험을 공유한 "Optimizing Go : Going from 3K req/sec to 480K req/sec per core"와 ORM 혹은 Model Mapper를 만든 경험을 공유한 "Go and SQL"가 있었는데 솔직히 발표가 엉망이었다. 뒤에 앉기도 했지만 발표자료의 글씨가 너무 작은데 색도 배경색과 비슷해서 앞에서는 보이나 할 정도로 아무것도 안 보였고 영어도 다 못 알아듣는데 발표자료도 안보이니 거의 알아듣기가 힘들었다. 두 번째 발표는 영어 발음이 알아듣기 너무 힘들어서 거의 넋 놓고 있었다.

세미나 공간 옆에 있던 New Relic의 로비와 식당사진만 건졌다.

이 글은 샌프란시스코 오피스 투어 #4로 이어진다.