그동안 컨설팅 현장 등에서 이런 이야기를 공유드리면서, 포스팅을 했다고 생각했는데 아직 안했더라구요.
부랴부랴 정리해서 올려봅니다.
이 글의 청중은 CEO 나 CTO 입니다.
팀내에 프로세스와 협업문화를 만들어야 하는 팀장급도 해당됩니다.
이 글은 2011년에 쓰여졌습니다.
F8을 발표하고 페이스북이 한창 성장할 때의 이야기며, 직원규모가 2천명 정도 수준일 때의 이야기입니다.
지금도 크게 다르지 않으며, 다른 회사들도 비슷하게 일합니다.
참고로, 우리나라도 비슷하게 일하긴 합니다.
다만 닮은 듯 아닌 듯 그럴 뿐이죠.
- 원문 : 페이스북은 어떻게 코드를 배포하는가? (2011.1.17)
- 글쓴이 : yeeguy
나는 페이스북의 운영 방식에 푹 빠져 버렸다.
매우 독특하면서도 결코 쉽게 복제될 수 없다.
혹시 누가 따라 하더라도 성공할 거라는 보장이 없다.
이 포스팅은 페이스북 친구들의 이야기를 모아 놓은 거다.
그들이 어떻게 소프트웨어를 개발하고 배포하는지 짐작할 수 있다.
많은 사람들이 페이스북에 관심이 많다.
그리고, “개발자 주도의 기업문화”를 도입하려고 노력한다.
하지만, 내부 프로세스에 대한 페이스북의 보안은 높은 편이다.
“엔지니어링팀”이 새로운 기능과 내부 시스템에 대해, “페이스북 노트”를 계속 공개하고 있지만, 이것은 “무엇”에 대한 것이지, “어떻게”에 대한 것은 아니다.
페이스북이 어떻게 다른 회사들보다 효과적으로 자기 서비스를 혁신하고 최적화시키는지 외부인들은 정말 알기 어렵다.
아래 이야기들은 개인적으로 긴 시간 동안 관찰한 걸 모아놓은 것이다.
취재원 보호를 위해 그들을 식별할 수 있는 단어를 모두 지웠다.
이야기도 6개월 이상 지난 후에야 공개했다.
최근 이야기라면 어느 팀에서 흘러 나왔는지 알 수 있기 때문이다.
그래서 아래 내용은 조금 지난 이야기일 수 있다.
그리고, 이 이야기는 페이스북 제품(앱, 서비스)에 대한 이야기는 아니다.
페이스북이 어떻게 조직 혼란 없이 의사결정을 “아래로” 전달하는지 그런 걸 이해하기 위한 이야기다.
궁금해하는 분들에게 도움이 되었으면 한다.
이 자료를 모을 수 있게 도와준 친구들에게 감사를 드린다.
그리고 편집할 때 도와준 epriest 와 fryfog 에게도 감사를 표한다.
인터뷰 내용
01. 조직구조
- 2010.6월 쯤 페이스북의 직원이 거의 2천명에 달했다.
10개월 전에 1,100 명이었으니 1년 동안 거의 2배 늘어난 셈이다. - 회사에서 가장 큰 두 팀은 “Engineering”과 “Ops” 팀이다.
각각 400-500명 정도 된다.
두 팀을 합하면 대략 회사 전체 인원 수의 50% 가 된다. - 1명의 제품관리자에 대략 7-10명 정도의 엔지니어가 매핑되어 있다.
02. 입사
- 입사자들은 4 – 6주 짜리 “부트캠프”를 거친다.
- 거기서 버그를 고치면서 페이스북 시스템을 익힌다.
그리고 시니어들로부터 필요한 강의를 듣는다.
10% 정도는 이 과정을 따라오지 못하고 퇴사면담을 하게 된다. - 부트캠프가 끝나면 모든 엔지니어는 실제 DB 에 접속할 수 있는 권한을 받는다.
(그 전에 “큰 권한 뒤에는 큰 책임이 따른다”라는 강의를 들어야 한다. 해고사유에 대한 교육도 받는다. 예를 들어 고객 데이터를 오픈하면 해고된다. ) - (fryfrog) 우리는 사람들이 실수로 큰 Sort 를 돌렸을 때 작업을 차단할 수 있는 장치를 가지고 있다.
즉, 대부분의 엔지니어는 그 정도 권한을 가지고 있다.
하지만, 그런 작업을 해야 할 땐 사유를 남기고 면밀한 검사를 받아야 한다.
예외 케이스는 없다.
03. 권한과 책임
- 모든 엔지니어들은 페이스북 코드의 모든 부분을 수정할 수 있고, 마음대로 check-in도 할 수 있다.
- “울트라 엔지니어링 중심 문화. “
어떤 엔지니어는 이렇게 말한다.
“기본적으로 제품관리자는 이곳에서 필요없다.”
엔지니어들은 제품관리자 없이 직접 스펙을 변경하거나, 작업의 우선순위를 조정할 수 있다.
그리고 아무때나 새로운 기능을 삽입할 수도 있다. - (편집자) 그런데 이 블로그 저자는 “제품 관리자” Product Manager이다.
그래서 이 글을 적어야 할까 조심스러웠다.
하지만, 아래에서 보듯이 페이스북의 제품관리를 아주 훌륭하다.
제품관리자의 역할은 절대 무시되지 않는다.
오히려, “모두”가 제품에 대한 책임감을 느낄 수 있게 만들어가고 있다.
04. 일하는 방식
- 월별 팀간 회의에서, 진행상황은 엔지니어가 발표한다.
그 회의에는 제품마케터와 제품매니저도 참가한다.
그런데, 마케터나 매니저가 너무 말을 많이 한다면, 리더들에게 제품팀의 말이 너무 많다고 피드백 된다.
페이스북은 엔지니어가 그 제품의 오너쉽을 갖고, 공개적으로 그 제품의 컨택 포인트가 되기를 원한다. - 프로젝트 멤버는 완전히 자발적으로 뽑는다.
엔지니어는 일하고 싶은 프로젝트를 선택한다.
제품 관리자는 엔지니어들이 자기 아이디어에 관심을 가질 수 있게 계속 접촉하고 이야기한다.
엔지니어는 자기 관리자에게 이렇게 말한다.
“이번 주에는 이 다섯 개를 처리하겠습니다.”
관리자는 대부분 그들이 하고 싶은 대로 내버려 둔다.
물론, 종종 먼저 끝낼 일을 주문하기도 한다. - 엔지니어들은 대부분 혼자서 전체 기능들을 개발한다.
프론트엔드 자바스크립트부터, 백엔드 DB코드까지, 그 사이에 있는 모든 것을 만든다.
만일 디자이너의 도움을 필요하다면, 디자이너가 내 프로젝트에 참여할 수 있게 관심을 유도해야 한다.
아키텍쳐도 마찬가지다.
기본적으로는 엔지니어가 모든 걸 알아서 처리하는 방식이다. - “그 기능을 구현할 가치가 있을까?”
그런 논쟁은 대부분 1주일 정도 만들어서 테스트 그룹에 던져 보는 걸로 해결된다.
05.코드리뷰
- 엔지니어들은 일반적으로 인프라, 확장성, 그리고 어려운 문제에 공을 많이 들이고 싶어 한다.
명성이 높아지기 때문이다.
프론트엔드 프로젝트와 유저 인터페이스 쪽은 비교적 엔지니어의 관심을 끌기 어렵다.
이런 현상은 일반적인 B2C 서비스와 정반대다.
B2C 서비스에선 개발자들이 고객과 만나는 지점에서 일하고 싶어한다.
UX 를 가리키며 “저거 내가 만들었어”. 이렇게 자랑하고 싶어한다.
하지만 페이스북에서는 백엔드가 엔지니어들의 로망이다.
(뉴스피드 알고리즘, 타겟광고 알고리즘, memcached 최적화 등) - 핵심 기능에 영향을 주는 commit은 반영 전에 코드 리뷰를 한다.
뉴스 피드는 저커버그가 모든 리뷰에 참여할 정도로 중요한 기능이다.
하지만, 그런 사례가 흔하지는 않다. - (정정) 모든 변경에 대해 코드리뷰는 필수다.
이건 저크버그가 모든 걸 일일히 다 보지 않는다는 뜻이기도 하다. - (fryfrog) 모든 변경은 최소한 한 명에 의해서라도 리뷰된다.
그리고 시스템은 누가 초대하지 않아도 아무나 들여다 볼 수 있게 오픈되어 있다.
누군가 악의적으로 리뷰되지 않은 코드를 심어 놓을 수 있기 때문이다.
06.QA, Unit Test
- QA가 없다.
엔지어가 모두 테스트하고, 버그를 고치고, 배포 후 유지보수를 해야 한다.
물론 유닛 테스트나 프레임웍 통합 테스트가 있기는 하다.
하지만 정말 가끔씩 사용되어진다. - (fryfrog) QA팀은 없지만, QA 업무는 있다.
온오프라인으로 일하는 모든 직원들은 “테스트 앱”을 사용하고 있다.
배포 직전의 모든 변경을 포함한다.
이 앱은 자주 업데이트 되고, 직원들은 정식배포 1시간 ~ 12시간 전에 그 기능을 볼 수 있다.
모든 직원이 버그를 찾아내도록 유도하며, 버그가 발견되면 빠르게 패치된다. - (fryfrog) 자동화된 유닛 테스트나 QA 가 없다는 것에 대해 놀란 분들을 위해.
대부분의 엔지니어들은 버그가 없는 코드를 만들 수 있다.
하지만, 많은 회사들이 그렇게 일할 동기를 없애버린다.
QA 부서를 만들면, 개발자들은 에러 발견작업을 그들에게 던져 버린다.
(편집자주 : 이건 개인의견이다) - (epriest) 물론 배포 전에는 반드시 거쳐야만 하는 자동화된 테스트 과정이 있다.
“대부분의 엔지니어가 버그 없는 코드를 만들 수 있다”
우리도 사실 이 말을 전적으로 믿지는 않는다. 적어도 “진짜 사업”이라면 말이다.
07.제품관리자
- “PM(Product Manager) 의 영향력이 적다는 것에 대해”
제품관리자는 독립적이고 자유롭다.
그들은 영향력을 갖기 위해 기술 관리자들과 매우 친밀한 관계를 쌓는다.
하지만, 엉뚱한 이야기를 하지 않으려고 그 기술을 깊이 알아야 할 필요는 없다. - 별개로, Roadmap이나 Backlog를 만들 때 누군가의 허락이나 리뷰를 받을 필요도 없다.
PM의 수는 비교적 적지만 그들 모두 회사의 중요한 사람이며,
자기 관심분야에 대해서는 책임감을 느끼며 일하고 있다.
08.DevOps, 배포
- 모든 commits은 주 단위로 배포된다.(화요일)
- 특정 사유가 발생되면 당일날 배포될 수도 있다.
- 화요일 배포는 그날 엔지니어가 자리를 지키고 있어야 한다는 뜻이다.
- 엔지니어는 배포 전까지 정해진 채팅 채널로 반드시 대기하고 있어야 한다.
그렇지 않으면 공개적으로 망신을 당한다. - Ops 팀은 코드를 단계적으로 배포하기 위해 “Release process”를 실행한다.
그 프로세스에는 9 단계의 중앙 통제장치가 있다. - 페이스북은 6만개의 서버를 가지고 있다.
- (epriest) 9 단계 모두가 중앙 집중식이 아니다. 3개만 그렇다.
(1단계, 내부 릴리즈, 2단계 작은 외부 릴리즈, 3단계. 외부 릴리즈)
나머지 6 단계는 동영상 업로드 같은 보조 프로세스들이다. - 가장 작은 서버그룹은 6개다.
- 예를 들어 새로운 화요일에 6개의 서버에 배포해야 한다면 (= Level 1),
Ops 팀은 그 6대의 서버를 잘 관찰한다.
그 다음 단계로 진행하기 전에 그 서버들이 원하는 대로 작동하는지 확인한다. - 만일 배포 중에 에러를 만나면, 배포 작업은 중단된다.
그 부분을 개발한 엔지니어는 문제 해결에 착수한다.
그리고, 해결이 되면 다시 Level 1부터 시작된다. - 그래서, 배포는 반복적으로 행해진다.
1-2-3-fix. back to 1.
1-2-3-4-5-fix. back to 1.
1-2-3-4-5-6-7-8-9.
이렇게.
09.Ops 팀
- Ops 팀은 정말 잘 훈련되어 있다.
모두로부터 존경받고 있으며, 비즈니스에 대해 아주 잘 알고 있다.
그들은 일반적인 에러 로그나, 부하분산, 메모리 사용률 이상을 관리한다.
사용자의 행동까지 포함한다. - 예를 들면, 새로운 Release는 그 기능을 사용하는 사용자들의 퍼센트를 바꾼다.
Ops 팀은 그 지표까지 들여다 보고, “Release 중단하기”를 권하기도 한다. - Ops 팀은 배포 중에 IRC 기반의 페이징 시스템을 사용한다.
이 시스템으로 Ops 팀은 엔지니어들에게 다양한 방법으로 체크를 한다.
이 메시지에 응답을 하지 않으면 공개적으로 망신을 당하기도 한다. - Level 9 까지 모두 배포되고, 안정적으로 작동한다면, 그 주의 Push(반영작업)는 종료된다.
10.성과, 평판
- 한 기능이 배포 기간 동안에 종료되지 않더라도, 그다지 큰 문제가 되지 않는다.
(그게 외부 의존도가 그렇게 높지 않다면 말이다.)
기능이 제대로 동작할 때 다시 배포된다. - svn 상에서 비난을 받거나, 공개적으로 망신을 당하거나,
너무 자주 프로젝트에서 제외되면 해고될 수 있다.
“매우 성과 중심적인 문화다.”
생산적이지 않은 사람이나, 천재가 아닌 사람들은 정말로 눈에 잘 띈다. - 신규 입사자가 6개월 이내에도 성과가 저조하다면,
관리자는 말 그대로 조용한 곳으로 그를 데리고 간다.
그리고 “당신은 우리 문화에 잘 맞지 않네요.”라고 이야기한다.
이건 모든 직원에게 해당된다.
임원이나 사장급이라고 하더라도 뚜렷한 성과가 없다면 금방 해고될 수 있다. - (epriest) 버그를 설명해달라고 하는 사람은 없다.
그냥 전화가 와서 이번 Release 에서 빼달라고 요청받는다.
설령 뭔가 잘못되더라도 지원해줄 사람이 주변에 없다.
(아무도 당신을 도와주지 않는다. 다 알아서 해야 한다.) - (epriest) 비난을 받는다고 해서 해고되지는 않는다.
우리는 이점에서 매우 관대하다.
대부분의 시니어 엔지니어들은 최소한 한 개 이상의 어려운 일들을 하고 있다.
내가 아는 한, 실수를 했다고 해서 해고된 사람은 없다. - (fryfrog) 물론 실수에 대해 해고된 사람을 본 적이 없다.
하지만 실수로 사이트를 다운시킨 사람들을 본 적은 있다.
그들은 그 문제를 해결하기 위해 진땀을 뺐고,
많은 사람들은 교훈을 얻었다.
적어도 망신당하는 게(쪽팔리는) 해고되는 것보다 훨씬 더 두렵다.
페이스북의 개발문화가 얼마나 더 진화할지 지켜보는 건 흥미롭다.
그리고, 그 문화가 계속 수천명의 다른 개발자들에게 이어질지도 궁금하다.
어떻게 생각하나?
“개발자 주도 문화”가 당신 회사에서도 잘 동작할 것 같은가?
끝.
IT의 중심에서 
댓글 남기기