놀라운 Google의 브랜치 전략
20170803 Thu @ Google
2017년 5월 10일부터 8월 4일까지 베이 지역으로 조금 특별한 출장을 다녀왔다.
어쩌다보니 일년이나 지나서 올리게 됐지만, 이 글은 그 곳에서 사는 동안 보고, 듣고, 느낀 것들을 사진과 글로 남긴 기록이다.
이전까지 여러 나라를 다니며 얻은 경험과 그동안 다양한 활동들을 하며 찍었던 방점을 연결할 수 있는 또 하나의 선이 되길 바란다.
8/3 Thu
#Google Sunnyvale Office
2년 만에 만난 재욱님. 2년 전엔 Oracle의 PM으로 만났는데, 작년에 이직하셔서 이번엔 Google의 개발자로 구글의 이모저모에 대해 들을 수 있었다. 특히 브랜치 관리에 대한 이야기는 놀랍기 짝이없었다.
<조명 - 건물 안에 위치에 따라 구글 글씨가 보이는 조명>
#많아진 사람, 부족한 오피스, 높아지는 건물
사람을 많이 뽑아서 마운틴뷰에 자리가 부족하여 클라우드팀 2/3는 Sunnyvale로 왔다. Google Flex 앞에도 공사 중이었는데, 사람이 많아져서 건물을 새로 짓는 중이라고 한다. 재욱님은 현재 Sunnyvale TC 1에서 근무하고 있었다.
써니베일 오피스는 마운틴뷰와 분위기가 사뭇 달랐다. 건물도 높고 좀 더 정형화된 오피스 느낌. 땅값이 비싸니까 위로 올리는 추세로 보여 여쭤보니 그렇다고 했다.
구글 오피스가 너무 퍼져있어서, 자전거 타고 다니는 것도 머니까. Mountain View랑 Sunnyvale 2/3까지 오피스가 퍼져있다. YouTube는 San Bruno에 있고. 구글 처음 와서 보니까 내부에 우버 서비스같은 것이 있더라. 조그만 봉고나 차가 와서 캠퍼스 간에 오간다. 구글이 직접하는건 아니고 외주 주는 것.
엘지도 MC는 셔틀을 운행하는데 그것 때문에 일하기 힘들다는 얘기가 많이 나왔는데, 여기서는 떨어져 있어도 일 잘한다고 하더니 이런 서비스가 있었던건가. 물론 정기적으로 운행하는 셔틀이 있지만 기다려야 하니까..
오라클은 꽤 큰 gym이 건물 가운데 하나 있었는데, 구글은 작게 10개 정도 있음. 수영장이 있는 캠퍼스는 차로 10분 넘게 가야하고. 붐비고. 그런건 아쉬운 점. 한곳에 모여있으면 크게 있을텐데.
여기는 오피스 분위기가 많이 나기 때문에 보통은 손님이 오면 구글 플렉스를 데려간다고 한다.
마운틴뷰 오피스에는 Visitor Center 쪽으로 안드로보를 다 옮겼던데. 사람들이 너무 많이 온다고 외곽으로 빼놨음. 사람들 관광을 너무 많이 와서. 오라클에서는 일년에 한 번 정도 연락왔었는데, 구글 오니까 매달 연락이 오고 있다.
#업무에만 집중할 수 있는 근무 환경
여기는 빨래하는 곳이다. 일명 빨래방.
신기하기는 했는데 좋아보이지는 않았다. 여기서 살라는 이야기지...
층마다 샤워실도 있다. 일하다 씻고 빨래도 하고. 일에만 집중할 수 있는 근무 환경이 조성돼있다.
주말에 집에 세탁기가 고장나서 오피스 온적이 있는데, 주말에 세탁실에 사람들이 줄 서있던 적도 있다고 한다.
건물마다 식당이 있는데, 캐주얼한 곳도 있고 정식을 주는 곳도 있고 전부 다르다. 사무실 자리에서 시끄럽게 일하는 사람들도 많아서 좀 조용한 곳이 필요하거나 혼자 일하고 싶을 때 식당 등을 이용하기도 한다고.
전반적으로 일은 모여서 하자는 분위기이지만 구글 모든 미팅은 행아웃으로 화상 미팅이 활성화돼있다.
화상 미팅은 Hangout enterprise를 활용한다. 회사 차원에서 개인 채팅은 Duo랑 Alo를 밀고, Hangout은 enterprise로 미는 중이다. 그래서 회의를 잡으면 자동으로 행아웃 링크가 생기고, 회의의 기본은 화상으로 셋팅된다. 그럼에도 불구하고 회의는 웬만하면 다 모여서 하는 분위기이다. 팀 분위기마다 다르지만, 재택은 자유롭다.
여긴 매니저도 대부분 테크 사이드인데, 재욱님 매니저는 개발자 출신은 아니라고 했다. 좀 특이한 커리어인데, SAP의 VP까지 했다가 여기로 디렉터 밑으로 왔음. 생각해보니까 compensation이 비슷해서 그런 것 같다. Level 6로 와서 compensation이 비슷한 것 같다.
처음엔 테크 사이드에 대해 디테일한 것은 모르니까 ‘알아서 해라~’ 해서 지난4개월동안은 거의 얼굴을 못봤다. 나가서 일하고. 문제 없으면 알아서 해라 하는 분위기. 그래서 처음 들어왔을 때 힘들었다. 팀이 처음 생기면서 그 사람이 뽑은 첫 번째 사람이 나였는데, 물어볼 사람이 아무도 없어서.
#직원이 함께 만들어 나가는 오피스
회의실 이름에 캡틴아메리카, 헐크 등등이 적혀있었다. TC 1, TC2, .. 동마다 주제를 잡아서 해당 주제에 맞는 회의실 이름을 공모해서 직원들이 낸 이름을 붙여준다고 한다.
또, 팀 공간마다 뭔가가 있었는데, 이사를 자주 다녀서 직원들에게 불편함을 주니까 HR에서 직원 1명 당 $50씩 준다고 한다. 그리고 팀 별로 그 돈을 모아 공간을 꾸민다고 한다. 어떤 팀은 레고같은 것을 갖다놓고 작품을 만들기도 하고, 아이들 와서 갖고 놀면서 뭔가를 만들 수 있는 공간으로 꾸몄다.
탁구대. 동료랑 일하다가 아규가 생기면 화를 누그러뜨리라는 용도로 좋다.
심지어 탁구대는 삼성전자에도 있다. (우리도 놔주면 좋겠다!)
각 건물마다 게임룸이 있다. Meditation room이 있어서 피곤할 때는 가서 쉬기도 한다. 건물에 아직 사람이 많이 안들어와서 비어있는 자리가 많다.
#외국인으로 이 동네에 사는 것은 어떤가?
이 동네에서 사는건 좋은가? 이제는 적응해서 괜찮지만, 아직도 렌트해서 살고 있는 중이었는데 집을 살 시기를 놓쳤다. 집 값이 너무 올랐다. 그런게 고민이지 뭐.
이 동네에 살고 있는 친구들도 같은 얘길 하던데, 이 동네에 있는 사람들이 평생 회사의 노예로 살아야 하는 이유가 그런 건가..
내가 방문했던 날은 Hack day같은 것 하던 날이었다. 퇴근할 시간인데도 사람들이 많이 모여있었다.
오라클은 4시쯤부터 집에 가서 5시면 사람이 없는데, 여기는 저녁 밥 주는 사내 식당에 가면 사람들 바글바글 하다. 직원은 아무나 먹을 수 있음. 야근을 하거나 말거나. 자체적인 룰은 구글러 당 한달에 2번, 2명 까지만 외부인을 데려와서 밥을 같이 먹도록 하자는 것. 이건 알아서 지키라는 것이고, 회사에서 규제를 심하게 하지는 않지만 알아서 다들 지킴.
시키는 분위기는 아니니까 알아서들 한다. 원래 있던 사람들은 너무 바쁘지 않게 하는 편. 퍼포먼스 리뷰 같은 것이 있어서 이정도면 하는거 아니냐~ 젊은 친구들은 패기넘쳐서 일을 많이 하니 나이든 사람은 힘들기도 함. 매릴랜드 출신의 한참 어린 친구(미국인)가 들어왔는데, 말을 안들어서 스트레스를 받기도 했음.
나도 한국사람이라 그런지 동양인이랑 일하는게 편한 것 같다. 미국인들 나이스한 친구들은 괜찮은데 선입견인지 모르지만 가끔 아시안이라 날 무시하나 하는 생각이 들기도 함. 미묘한 것이라 뭐라 말하기는 좀 그런? 구글에 중국 사람들이 많이 있다.
#구글의 형상관리
개발 프로세스는 어떤가?
우리도 개발 프로세스 때문에 챌린지가 있다. 우리가 애자일 한다 스크럼 한다 하지도 않고 팀마다 다른데. 팀이 대부분 거의 DevOps처럼 굴러간다. 우리같은 경우는 크게 프론트 엔드, 백엔드가 있다. 백엔드는 우리가 하는데, 프론트엔드는 서플라이 체인하는 팀에서 운영을 한다. 그 팀은 일주일에 두 번 릴리즈를 한다. 근데 우리가 코드를 서밋하면 자동으로 파이프라인으로 올라가는데 그걸 컨트롤할 수 있는게 별로 없다. 예를 들면 화요일부터 목요일까지 고친게 다음주 화요일에 자동으로 배치되고. 여러가지 챌린지가 있다.
우리가 개발한거 서밋해서 일주일이든 이주일이든 안정화시킨 다음에 프로덕션에 올리고 싶은데, 그런게 잘 안되고 있다. 서밋하면 무조건 프로덕션에 올라가버리니까. 안정화 기간 없이 바로 마스터 브랜치에 들어간다.
테스트 자동화시키고, 커버리지 늘리고 계속 하지만 그게 쉽지도 않고. 툴도 다 있지만, 가끔 리그레션이 발생하면 “아 우리 어떻게 하냐 프로세스 다시 점검해야 한다’ 그런 것이 챌린지다.
근데 구글 내부 많은 팀이 DevOps처럼 되어있다.오라클 때는 소스컨트롤 시스템이 브랜치가 중요하고 관리가 중요했지만, 구글은 기본적으로 브랜치 기능이 없다. 전부 마스터 하나로 관리한다.
마스터 하나로? Git을 여기서 만들었는데 브랜치를 안쓴다니 말이 되나?
메인으로 쓰는 소스코드 리파지토리 파이퍼라고 있는데, 기본적으로 브랜치를 만들 수는 있지만 툴에서 지원하지도 않고 브랜치가 없다. 이게 말이 될까? 싶은데 되더라.
일단 인더스트리가 다르다. Cloud 100%니까 버저닝을 할 필요가 없다. 보통은 문제가 생긴 것을 기준으로 버전을 관리하는데, 버저닝에 들이는 노력보다 모든걸 자동화시키려는데 노력을 한다. 만약 문제가 발생하면 5분 안에 그 문제를 고치던지 아니면 롤백을 시키던지둘 중 하나다. 롤백은 컨트롤 시스템에서 버튼 하나 누르면 롤백 가능하다. 그런 식으로 관리하더라.
사실 나도 이걸 보고 깜짝 놀랐다. ‘어떻게 브랜치 기능이 없을 수 있지?’ 근데 그런식으로 돌아감. 그래서 릴리즈 사이클이 빠를 수밖에 없다. 마스터에 다 넣어버리니까. 일주일 안에 프로덕션에 올라가는 것이다.
예를 들어 지메일이나 이런건 여러개 서버에 로드밸런싱을 하니까 릴리즈할 때 여러개 서버에 부분적으로 패치를 해서 사용자 그룹 별로 다르게 사용하고 있다.
아, 그 형태로 자연스럽게 AB 테스트가 되는군요?
그렇다. 근데 소스코드 관리 측면에서는 버전 관리라는 개념이 없음. (진짜 신기하다)
물론 우리도 컨셉추얼하게는 이해를 하는데 실제로 돌리려면 문제가 많다. 특히 오라클에서는 유닛 테스트가 10-20%도 안됐는데, 구글은 이미 개발해서 들어오는 코드의 유닛테스트 커버리지가 90%가 넘는다. 인티그레에션 테스트는 좀 적은데 90%까지 올려야한다가 기조.
인티그레이션 테스트는 어떻게 하나?
인티그레이션 서비스 콜하고 그런 것들을 그쪽 팀에서 mocking 서비스를 만들어서 실제 콜하고 받고 해서 테스트한다. 디펜던시 있는 것들 작은 것 하나도 mocking 만들어서 IN/OUT 서비스 콜 해서 테스트 한다. 이렇게 자동화하는데 엄청 노력을 기울인다.
그걸 개발자 모두가 하나? 테스트 인원이 있나?
우리 그룹은 그래도 PM이 좀 있고 어날리스트가 꽤 있는데, 다른 팀은 거의 엔지니어라 리그레션 테스트는 거의 없고 개발만 한다. 그런 분위기라 오라클이랑 많이 다른데 구글 전체적인 분위기가 그러하다.
우리팀은 어날리시스트가 있어서 리그레션 테스트, 인티그레이션 테스트 등 수동 테스트도 많이 한다. 근데 이렇게 수동으로 하는게 맞냐 우리 문제다 해서 내년까지 자동화로 많은 부분 바꿀 예정이다.
궁극적으로 DevOps 형태로 운영하려고 자동화를 시키는데 노력을 많이 기울인다는 뜻이네요?
우리가 애자일이라고 하는 것들은 개발 프로세스까지만 자동화시키는 컨셉이잖나. DevOps가 되려면 Continuous Integration까지 되어야 하는거니까 방법론을 뭘 쓴다 하는 말은 안하고, 툴 자체에서 자동화가 되고 라벨도 자동으로 붙여주고 등등 그런 시스템을 많이 만들어서 지원하려고 하는 것 같다.
뭔가 끝단의 모습을 그려놓고 그걸 보고 달려가는 느낌이군요. 애자일은 앞단의 잘못된 부분을 보면서 바로 앞의 것까지를 보면서 하나씩 바꿔나가는데? 그나저나 툴이 너무 많아서 찾는 것도 일이라고 하던데?
새로온 사람들을 누글러라고 하는데, 소스컨트롤 시스템부터 모니터링 툴, 디플로이툴 그래프 그려놓은게 있어서 봤더니 각각 하나에 툴이 40-50개씩 있더라. 각각이 커며셜로 만들 수 있을 퀄리티이고. 아무래도 개발자 중심의 회사니까 그런 것에 노력을 많이 기울인다. 그게 오라클과 다른 대표적인 부분.
어날리시스나 테스트. 여긴 기본적으로 팀에 QA가 없으니까 엔지니어가 다 해야한다. 근데 다 할 수 없으니까 툴이 지원해주지 않으면 안되는 것ㅇ다. 굳이 뭐 애자일 쓰냐 스크럼 쓰냐 그게 중요한게 아니고 CI가 되도록 하는 것이 목적이라 기본적으로 CI 하는 것이 툴과 시스템에 녹아있는 것 같다.
DevOps 이야기가 많이 나오니까. 충분하게 역량이 안되고 ,크로스 펑셔널 팀이 아니고, 툴이 지원이 안되면 DevOps는 사실 되기 어려운 환경이다. 이런걸 모두 제대로 하는데가 아니면 DevOps가 안되는거지.
오라클 때는 툴이나 이런 서포트가 없는 환경이라 2주 스프린트를 돌려도 릴리즈는 6개월 걸리고. 여기는 기본적으로 2주 릴리즈 싸이클로 돌아간다. 그래서 우리는 챌린지가 웹서버쪽 디플로이를 우리가 컨트롤을 못한다. 일주일에 두번씩 자동으로 패칭되니까. 그러니까 코드 넣으면 다음주 화요일에 패칭 자동으로 올라가니까. 물론 그 안에 Nightly test, QA라던가 그런 테스트 환경이 있지만, 우리가 우스게소리로 하는게 야 이거 달리는 기차 아니냐. 그래서 화수목요일에만 코드 서밋하자고 자체 룰 만들었다. 금요일에 리그레션 테스트 하고 토요일에 고쳐서 넣으면 다음주 화요일엔 토요일까지 코드만 올라갈테니까. 근데 시간이 너무 짧아서 힘들다. 그래서 우리 자체 서버 만들어서 거기서 1-2주 안정화 테스트 거치고 올리려고 하는 중이다. 그게 챌린지. 마스터로만 올리고 버저닝이 안되니까.
디펜던시 2-3개 걸려있는 정도면 괜찮은데, 수정한 코드 덩치가 커져버리면 컨플릭 리졸브 해야하고 등등 그게 일이 돼버리니까.
얘기 듣다보니 버전관리는 엘지가 더 잘하는 것 같다. 규모가 크니까.
장단점이 있는데, 오라클은 4년차에 버전 11을 릴리즈 했다. 그 다음해에 버전 12를 만들어서 6개월만에 끝냈다. 근데 그 때 버전 11을 여전히 테스트 중이었고, 버전 13을 개발하던 중인데 QA들이 여전히 버전 11을 테스트하던 중이었다. 디펜던시 여기저기 걸려있고 이슈 나온 것들을 고치고 하는게 일이 많으니까. 개발 인력은 손도 못대로. 버그 리포트 된거 고치면 또 타고타고 내려가서 또 고쳐야하고, 브랜치가 동시에 4-5개가 돌아가고, 하나 고칠 때마다 머리가 아프고.
그런걸 생각하면 구글 시스템이 낫지만, 오라클은 stand alone 시스템이니까 버전 관리가 중요했던 거죠. 사실 LG도 비슷해요. 구글의 현재 프로세스는 산업 특성 상 클라우드 시스템이라 적용이 가능한 것 같아요.
그렇다. 구글 같은 경우는 극단적으로 적용시켜버린 것이다.
전에 MS갔을 때 CD Rom일 때는 테스트에 집중했는데, 클라우드로 가니까 SDET도 없어지고 테스트를 그렇게 오래하지 않는다던데.
여기도 이렇게 돌아가지만 가끔 문제가 크게 터진다.
우리 집에 구글홈이 있는데, 업데이트가 있으면 자동으로 패치가 된다. 지지난주에 자동으로 패치됐나본데 동작을 안하는 이슈가 있었다. 그 때 구글 내부에서 클레임이 대거 들어온적이 있다.
구글 내부적으로 OMG(Oh My God) 사이트가 있는데, 이슈가 나면 거기에 막 올라온다. 보통은 매일매일 자잘하게 조금씩 있고. 지지난주 구글홈 패치는 동작을 안하니까 잔뜩 올라왔던 경우다. OMG에 올라오면 바로 롤백시키고. 100% 자동화시키려고 노력하니까 좋은데, 실제 프로덕션 서비스할 때 개발자들이 정말 힘들겠단 생각이 들었다.
얘길 듣다보니 여기도 비슷한 문제가 있는 것 같은데, 내가 코드를 반영하기 전에 이상동작 하지 않는단걸 확인하고 올려야하는거 아닌가? 근데 어디까지 영향을 미칠지 모르는 것 같다.
여러가지 복합적인 얘긴데, 그렇기 때문에 가능하면 마이크로 서비스로 개발을 하려고 한다. 심플한 구조로. 그렇게 노력을 하는데 말처럼 쉽게 되진 않으니. 내가 개발하는 것도 굉장히 심플한 아키텍쳐로 가져가지만 5-6개 시스템에 디펜던시 걸려있다. 그러니까 100% 테스팅하고 유닛테스트 커버리지 높이고, 시뮬레이션 해볼 수 있고 하지만 예상 못한 이슈가 발생할 수 있으니까 OMG 같은 사이트는 좋은 것 같다. 아무튼 내가 예상 못한 문제는 언제든 발생할 수 있으니 우리팀은 매주 금요일날 리그레션 테스트 수동으로 하고 있다.
여긴 100% 소프트웨어라고 가능한 것 같다. 우린 임베디드라서 이러면 난리난다.
얘기 들어보니까 규모가 큰 것들. 안드로이드는 git으로 개발하면서 관리하는 것으로 알고 있다. 거의 구글 내부적으로 90% 이상은 브랜치 없는 소스코드 리파지토리를 쓰고 있다. 모든 툴이 다. 그런 부분이 개발자 입장에서 많이 다른 것이다.
네 말대로 100% 소프트웨어라서 가능한 것 같다. “금방 고치면 되잖아” 이런 마인드.
어떤게 있냐면, 시스템 다운되지 않아도 프론트엔드에 exception이 발생하면 그거 발생된 코드에 영향을 끼친 코드를 서밋한 모든 사람들에게 그룹 메일이 자동으로 간다. 그런 시스템이 있다. 그 중에 가장 영향을 많이 끼친 코드를 반영한 개발자에게 자동으로 어싸인해서 분석시킴. 우리 경우는 테스팅 유닛 테스트, 인티그레이션 테스트, 리그레션 테스트 중, 스크린 테스트라고 해서 이거 한게 변경이 있을 수 있으니 . 스크린 테스트 했는데 화면이 깨지면 크롬이 업데이트 된것 . 이렇게 테스팅하는데 시간을 엄청 많이 들임. 기본적으로 완전 다른 로케이션 3개 이상에서 서비스하고, 각각 로드밸런싱 해서 마이크로 서비스 형태로 돌고. 죽으면 자동으로 리스타트 시키고 등등. 이게 구글만의 서비스 전략. 덩치 큰 서버를 한번에 돌리는게 아니고.
즉, 구글은 DevOps를 지향한다. 구글의 모든 시스템과 툴은 DevOps 환경을 만드는 것을 목적하고 만들어져 있다.
