속도의 선순환 : 빠르게 진행하는것의 중요성에 대하여 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 : 게임 개발자라면 성능과 인프라에 대한 많은 팁을 얻을 수 있을것이다.

책 이야기 - 실천 반복형 소프트웨어 개발

왜 반복형 개발인가?

 Disciplined Agile Delivery (DAD)를 비롯해 애자일 개발에 가장 큰 영향을 끼치고 있는 인물인 Scot Ambler는 2007년부터 자신의 웹 사이트에서 비 정기적으로(거의 1-2년에 한차례)프로젝트 성공에 대한 설문을 진행해 오고 있다. (2013년 투표는 2013년 12월1일 현재 진행중이며 결과가 나오면 살펴볼 기회를 가져보려 한다.)

아래 표는 가장 최근 이뤄진 2011년의 조사 결과이다.

 여기서 눈여겨 보아야 할 것은 성공률 1위가 애자일 개발이 아닌 반복형 개발이라는 점이다.
 반복형 개발은 순차 점증적 개발(Iterative and incremental development)과 동일한 의미 이며 폭포수 개발 방식과 마찬가지로 여러가지 수정모델이 존재하는데, Rational Unified Process로 흔히 불리우는 Unified Process가 대표적이며,  2위와 3위에 오른 애자일 소프트웨어 개발 프로세스들 또한 반복형 개발에 근간을 두고 있다.

반복형 개발 VS 애자일 개발 VS 폭포수 모델

 애자일 개발과 반복형 개발은 실상 프로젝트 내부에서 이뤄지는 작업의 내용면에서는 사실상 큰 차이가 없다고 보는데, 두가지 개발 방식에 대한 차이는 무엇을 하는가 보다는 무었을 지향하는가에 있기 때문이다.

 애자일 개발은 가치 지향적이다. 애자일 개발은 프로세스나 계약, 절차보다 완성된 소프트웨어가 지니는 가치를 가장 중심에 놓고 프로세스를 바라보는 관점을 지닌다. 
반복형 개발은 폭포수 개발과 마찬가지로 기본적으로는 절차 지향적이다. 인적 자원에 크게 의존 할 수 밖에 없는 소프트웨어 개발 프로젝트가 필연적으로 지니게 되는 불가시성을 최대한 배제하기 위해 반복적이며 점진적으로 계획하고 실행하는 방법을 택하고 있다. 
XP나 스크럼과 같은 애자일 개발 프로세스들은 기본적으로 반복형 개발을 기초로 하여 개발 프로세스들을 확립하였다. 짧은 개발주기, 지속적인 통합/배포, 그리고 회고를 통한 피드백이 그것이다. 

 엔터프라이즈 어플리케이션 개발에 있어서 애자일 개발이 지니는 최대의 약점은 고객으로 부터 듣는 질문중 가장 단순하면서도 가장 흔히 듣는 질문인 "그래서 얼마면 되는거요?"라는 질문에 답변하기가 까다롭다는 점이다. 특히나 대규모의 프로젝트에서 "일단 한번 해 보시면 얼마나 좋은지 아실껍니다." 라는 답변으로 고객을 안심시키기는 쉽지가 않다는 이야기 이다.

 그렇다고 견적내기 편하다는 이유로 폭포수 모델을 택하기엔 너무나도 많은 대가를 감수해야만 한다. 폭포수 모델이 오늘날 천덕꾸러기 신세를 면치 못하는 이유는 만들어 내야 하는 소프트웨어에 대한 복잡성이 검토를 통해 예측 가능한 법위를 넘어섰기 때문이다. 

 현대의 사회 시스템은 끊임없이 복잡한 방향으로 변화하고 있으며 이를 추상화 하여 다루는 소프트웨어도 함께 복잡성을 더해가고 있다.  이에 대해 반복형 개발은 끊임없이 완성된 소프트웨어를 만들어 내고 그에 대한 피드백을 통해 프로젝트를 통제해 나가는 방식을 취함으로서 이러한 복잡성에 대응해 나가고 있다.

 즉, 고객이 진정 원하는 소프트웨어의 사양은 완성된 소프트웨어를 직접 만져보기 전에는 확정하기 어렵다. 따라서 검토만으로 해결 할 수있다고 주장하는것은 너무나 천진 난만한 생각이며, 이에 대한 대가로 지불되는 것은 대부분의 개발 현장에서 개발자들의 땀과 눈물이 될 것이다.  

실천 반복형 소프트웨어 개발에서 다루는 내용

이제 본론인 책 이야기를 할 시간이다.

 저자인 쓰다씨는 현재 일본 마이크로소프트에서 테스트 전문가로 활동하고 있으며 필자가 소속된 豆蔵Mamezou의 OB이기도 하다.

저자는 이 책의 대상 독자에 대해 책 머리에 다음과 같이 밝히고 있다.

• 3~5년정도의 소프트웨어 개발 경험이 있는 분
• 프로젝트 팀을 리드하는 위치이며, 팀운영방침을 정해야 하는 분
• 지금부터 프로젝트팀을 리드하는 위치에 서게되는 분
• 프로젝트팀의 운영에 대해서 문제의식을 가지고 있는 분
• 개발중인 소프트웨어의 품질을 제어할 수 없어서 곤란을 겪고 있는 분
• 개발을 지원하는 툴을 도입하고 싶지만, 조직의 문화적 저항에 부딧혀 뜻을 이루지 못하는 분
• 툴을 도입하기는 하였으나 제대로 활용하는 방법을 알지 못하는 분
• 폭포수개발 프로세스에서 벗어나고 싶은 분
• 반복형 개발을 시험해 보고 싶지만, 몇번을 반복해도 끝이 나질 않아 실패한적이 있는 분

 이 책에서는 언어나 생산되는 소프트웨어에 관계없이 다양한 소프트웨어 개발 프로젝트에서 사용 가능한 범용적인 반복헝 개발의 원칙과 규율을 제시하고 있다.

 책에서 소개하는 원칙과 규울은 단순히 이론에 그치는것이 아니라 현재 나와있는 최적의 개발지원 환경들(빌드, 형상관리, 이슈트래킹, CI)이 개발 규모와 진행상황에 따라 어떻게 연동되어 운용 되어야 하는지를 구체적인 예제와 함께 설명하고 있다.

 개인적으로 이 책의 가장 맘에 드는 부분은 일방적으로 이러한 방식이 가장 좋습니다 라고 강요하는 식이 아니라 스스로 각자의 개발 현실에 맞는 프로세스를 찾아 나갈 수 있도록 다양한 힌트를 제시하고 있다는 점이다.

품질과 납기를 동시에 잡는 비장의 무기 - 타임박싱 관리 기법

 저자인 쓰다씨가 반복형 개발에서 특히 중요하게 생각하는 개념은 타임박싱기법 이다.
타임박싱이란 기간 안에 끝낼 수 있는 작업과 그렇지 못한 작업을 선별하여 다음 반복에 넘기는 프로젝트 관리 기법을 지칭하는 것으로 정해진 시간 속에서 개발 사이클을 반복해야 하는 반복형 개발에서 품질과 납기를 지켜내기 위해 매우 유용한 개념이라 할 수 있다.

타임박싱 기법에 대해서는 아래 포스팅에서 자세히 다루고 있다.

프로젝트 관리 기법 - 타임박싱(Timeboxing) 관리 기법

그래서 얼마면 되는거요?

 마지막으로 아까전에 했던 "그래서 얼마면 되는거요?"라는 고객의 질문에 대해서 필자는 다음과 같이 답변을 하고자 한다.

"반복형 개발이 더 싸지지는 않을지 모릅니다. 하지만 같은 비용의 폭포수 개발과 비교하자면 위험 요소들의 제어가 훨씬 쉬워지며, 무엇보다 좋은 품질의 소프트웨어를 생산하는것이 가능해 집니다."

 반복형 개발(또는 애자일 개발)은 개발자가 편해지자고 하는것이 아니다. 오히려 개발자는 폭포수형 개발에 비해 훨씬 많은 작업들을 수행 해야만 한다. 그렇기 때문에 빌드하고 에러를 체크하고 코드 품질을 유지하는 등의 작업들을 철저하게 자동화 해 나감으로서 사람만이 할 수 있는 창조적인 작업에 보다 많은 시간을 투자 하는것이 가능해지는 것이다.

 개발 현장에서 애자일 프로세스의 도입을 검토하고 있거나 이미 도입하였더라도 프로세스의 개선에 목말라 하는 모든 이들에게 이 책을 꼭 추천한다.