속도의 선순환 : 빠르게 진행하는것의 중요성에 대하여 by Randy Shoup

4월 30일 일본 동경에서 개최되었던 QCon Tokyo 2014에서 가장 인상깊었던 Randy Shoup씨의 기조연설 "속도의 선순환 : 빠르게 진행하는 것의 중요성에 대해서 구글과 eBay에서 배운것The Virtuous Cycle of Velocity: What I Learned About Going Fast at eBay and Google"의 내용을 요약해 소개해 보고자 한다.

연사인 Randy Shoup씨는 20년 경력의 베테랑 앤지니어로 eBay와 구글의 엔지니어링 디렉터를 거쳐 현재는 War commander로 유명한 게임회사인 KIXEYE의 CTO를 맡고있다. (개인적으로 우연의 일치인지는 모르겠으나 요즘 읽은 책이나 만났던 사람중에 엔지니어의 최종 테크트리로 게임 개발자를 택한 사람들이 많았다.)

맨 왼쪽부터 Randy Shoup(KIXEYE), Marco Cecconi(Stack Overflow), Eugene Ciurana(Yahoo,Summly), 그리고 영국인 앤지니어인 Andrew.

강연내용 요약

QCon의 강연내용을 간단히 요약해 본다.
QCon Tokyo 2014의 비디오는 아직 공개되지 않았기에 Flowcon 2013에서 동일한 타이틀로 진행한 강연영상과 QCon에서 작성한 메모를 이용해 작성하였다.

The Virtuous Cycle of Velocity: What I Learned About Going Fast at eBay and Google by Randy Shoup - Flowcon 2013

기술

A클래스 개발자를 채용하라

• 최상위 개발자와 최하위 개발자의 생산성의 차이는 10배에 달한다.
• 채용의 선순환과 악순환 : A클래스 개발자는  A클래스 개발자를 뽑지만 B클래스 개발자는 C클래스 개발자를 뽑는다. 왜냐하면, A 클래스 개발자는 다른 A클래스 개발자가 자신의 자리를 위협한다고 생각하지 않지만  B클래스 개발자는 다른 B나 A클래스 개발자가 자신의 자리를 빼앗을지도 모른다고 생각하기 때문이다. 그 결과 A클래스를 뽑은 개발자 그룹은 인재의 질이 시간이 지나도 떨어지지 않지만 B클래스 이하를 뽑은 개발자 그룹은 인재의 질이 갈수록 떨어지게 되어 있다. - 구글이 잘 하고 있는것.

이번 QCon내내 지겹게 들었던 말 이다. A클래스 개발자를 채용하라. 유니콘 개발자를 채용하라. 멀티 플레이어를 채용하라.

사람이 우선이다

• 소프트웨어 기업에 있어서 사람은 가장 중요하면서 대체불가능한 자산이다.
• 사람은 부품이 아니며 대체 불가능하다.
• 나쁜 예 : 예전 eBay의 "Train seats" (역자 주: eBay 특유의 공수계산법. 1명의 개발자가 3주동안 진행할 수 있는 일의 양을 말한다. 전통적인 man-month와 동일한 개념으로 2014년인 현 시점에서는 더이상 사용하지 않는듯 하다.(아시는분은 댓글 요망) 자세한것은 The Journey of a Product on eBay – from Idea to Rollout을 참조)
• man-month기반 관리는 개발자의 긍지와 주인의식을 무너트린다.
• 사람은 자산이지 원가 절감의 대상이 아니다.
• 개발자가 회사에게 있어서 소중한 존재라는것을 느낄 수 있도록 하라 - 구글이 잘 하고 있는것. 자신이 소중하게 다루어진다는 것을 느낄수록 더 열심히 일한다.

인재 채용의 선순환 : 인재의 질이 유지됨

인재 채용의 악순환 : 인재의 질이 꾸준히 나빠짐

서비스 개발

• 작은팀 - 아마존의 피자 두판 팀: 팀 인원수는 피자 두판으로 끼니가 해결 될 수 있는 인원 이하로 유지하라.
• 잘 정의된 인터페이스 - 팀은 회사의 나머지 부분들과 효율적으로 의사소통을 할 수 있도록 적절한 의사 소통 통로를 지녀야 한다.
• 완벽하게 독립적으로 운영하라 - 팀에게 최대한의 자치권을 부여하라.
• 자율성과 책임성 - 스스로 결정하고 스스로 책임지도록 하라. 구글은 모든 서비스에 사용할 언어와 미들웨어, 플랫폼을 아무런 제약없이 팀 내부에서 자체적으로 결정할 수 있다.대신, 그에 따른 책임도 스스로 져야만 한다.

팀 운영에 있어서 가장 중요한것은 주인의식이다. 권한과 책임 없이는 주인의식도 생기기 어려울 것이다.

품질 원칙

• 자동화 테스트는 일의 진행을 빠르게 해 준다
• 자동화 테스트는 안심감을 준다
• 자동화 테스트는 과감한 리팩토링과 수정을 가능하게 함
• 버그를 잡기 더 쉬워지고 더 빠르게 발견할 수 있음
• 좋은건 알지요. 하지만 시간이 없다구요!
• 당신이 틀렸다. 똑같은일을 계속해서 반복 하게 될 것을 생각하면 어느쪽이 더 시간 절약이 되는가?

기술적 채무의 악순환과 기술적 자산의 선순환

• 자산을 저축할 것인가 채무를 늘려 나갈 것인가

기술적 자산의 선순환

기술적 채무의 악순환

품질관리의 자동화

• 올바른 형태의 개발이 쉬워짐
• Mocking/테스팅 프레임워크의 사용
• 모니터링
• 위험에 대한 경고(Canarying)

품질은 절대 타협 대상이 아니다

• 품질(신뢰성, 스케일링)은 영순위 사항이다.
• 구글은 잘 했으나 예전 eBay는 잘 못했음.

품질관리의 선순환 : 선순환의 시작점은 테스트이다

Randy씨는 구글에서는 약 1년2개월을, eBay에서는 6년 8개월을 일했었는데 예전 eBay의 개발 방식에 대해서는 많은 후회가 있었던듯 싶다. 반면 구글에서의 경험은 대부분 긍정적으로 평가하고 있다.

문화

책임과 주인의식

• 개인과 팀에게 자율을 보장하라.
• 성공의 열쇠는 책임의식.
• 약속을 지켜라 - 무언가를 하겠다고 말했다면 반드시 실행하라.

 필자 또한 격하게 공감하는 내용이다. 주인의식이 없이는 최선을 다하기가 어렵다. 권한과  책임은 동면의 양면과 같아서 떨어트려 생각할 수 없다. 직원들을 믿는 회사로 사람들이 몰리는 이유이다.

협업

• 엔지니어, 프로듀서, 운영자가 함께하는 하나의 팀
• 함께 문제를 적극적으로 풀어나가는 게임처럼 일을 할 것인가.
• 아니면, 보신주의(CYA:Cover your ass)를 위해 문제를 숨겨놓을 것인가.
• 구글은 다른 지역사람들이 모여 하나의 팀을 이루는 경우도 적지 않지만 협업이 매우 잘 이루어짐.

양보다 질

• 적은것이 더 낫다
• 진정한 사냥꾼에게는 많은 화살이 필요 없다.
• 한가지문제를 100%완벽하게 풀어내는것이 두 문제를 50%만 풀어내는것 보다 낫다.
• 어정쩡한 두개의 기능을 추가하는 것 보다 훌륭한 기능 한개를 만들어내는것이 더 낫다.
• 온전한 UX
• 사용자 경험에 대한 모든면을 처음부터 끝까지 고려 할 수 있어야 함.
• UX, 기능, 성능, 버그, 기타 등등.

실험정신

• 런칭은 단지 첫 걸음에 불과하다.
• KIXEYE의 War commander의 경우 첫달에는 주목받지 못하였다. 하지만 매달 꾸준히 개선을 거듭한 결과 6개월후 동일 카테고리에서 최고의 자리에 오름.
• 작고 많은 실험들이 모여 큰 성공을 이루어 낸다.
• eBay의 machine-learned 랭킹시스템 (역자주:초창기 Hadoop의 대표적인 성공사례로서 기능과 성능이라는 두마리 토끼를 잡아냄. 자세한것은 ebay tech blog를 참고)

배움의 선순환을 만들라

• 회사는 배움의 장이 되어야 한다
• 구글에서는 모든것에 대하여 회고를 진행한다
• 잘 된것, 잘 못한것 모두 대상으로 진행
• 솔직하게 진행하지 않으면 결국 형식뿐인 빈 껍데기가 되어 버린다  
• 배우는것을 좋아하고 즐기는 사람을 채용하라

가장 공감했던 내용.
최소한 IT기업에 있어서 회사는 배움의 장이 되어야 한다.

회사는 학교가 아니다 라는 말을 하는 사람이 아직도 주변에 있는가?

아직 있다면 당당하게 말하라. 

"당신이 틀렸소."
그런데 그 사람이 사장이라면?!
진지하게 이직을 고려해 보라.

실패에 대한 관용

• 실패를 통해 배우고 발전해 나갈 수 있어야 한다.
• 면접때 무엇을 알고 있는가를 물어보기 보다는 무엇을 배웠는가를 물어본다.
• 감정과 개성을 존중
• 구글의 경우 프로젝트 사후 평가에 있어서 비난을 허용하지 않는다.

빠르고 반복적인 개발을 장려

• 실패는 쓰러지는것을 말하는 것이 아니라, 다시 일어나기를 포기하는것이다. - 루즈벨트

Randy Shoup씨의 강연에서 가장 인상깊었던 것은 개발을 둘러싼 모든 문제들을 하나의 순환구조로 파악하고 있다는 점 이다. 시간이 흐름에 따라 좋아지는 것은 더욱더좋아지게 되고 나빠지는 것 또한 그러하다. 이러한 선순환과 악순환은 동일한 출발지점을 지니며 어떠한 선택을 하느냐에 따라 완전히 다른 방향을 향하게 된다. 악순환을 선순환으로 바꾸는 출발점은 이러한 순환구조를 이해하는데에서 출발한다.

현재 KIXEYE의 모든 게임들은 3명이 한팀을 이루어 한달을 주기로 반복형 개발을 수행하고 있으며, 소스코드의 빌드가 끝난 이후 AWS를 이용해 완전 백지상태에서 서비스 런칭까지 15분이 소요된다 한다. 아마도 DevOps를 통해 인프라 셋업의 자동화를 이루어낸 덕분이리라.

관련링크

Randy Shoup씨의 다른 강연

• Everything I Learned About Scaling Online Games I Learned at Google and eBay: Scalability at KIXEYE - QCon New York 2014 : 게임 개발자라면 성능과 인프라에 대한 많은 팁을 얻을 수 있을것이다.