구글의 클라우드 컴퓨팅 아키텍처와 오픈소스 컨테이너 프로젝트 Docker

구글의 클라우드 플랫폼 담당 시니어 소프트웨어 앤지니어인 Joe Beda씨는 Containers At Scale이라는 타이틀로 구글의 스케일링 아키텍처에 대해서 설명하는 슬라이드 자료를 발표했다.

오늘은 이 자료를 통해 세계최고의 IT서비스 기업중 하나인 구글이 채택하고 있는 클라우드 아키텍처를 살펴보고자 한다.

구글의 모든 서비스들은 컨테이서안에서 실행된다. 

(Everything이 굵은 글자로 강조되고 있음을 놓치지 말자!)

• 구글 사내의 어플리케이션을 포함한 구글의 모든 서비스들은 모두 이 컨테이너 안에서 실행되고 있다. (역자주: 현재 구글이 퍼블릭 크라우드 서비스로 제공하고 있는 App Engine또한 이 컨테이서 상에서 동작되고 있다. 자세한것은 App Engine Architecutre 문서를 살펴보자.)
• 구글은 매주 20억개 이상의 컨테이너를 기동하고 있다. (역자주 : 세계 인구는 2013년 1월 기준으로 71억명 이다!) 

컨테이너란?

컨테이너는 프로그램이 작동하기 위한 최소한의 요소들을 묶어 패키징한 것으로 OS보다 작으면서 독립적인 배포와 실행을 가능하게 하는 일종의 가상 머신이다. 대표적인 오픈소스 컨테이너 기술인 docker가 최근 급속도로 인기를 끌고 있다. 대부분의 컨테이너 스텍은 LXC(Linux Containers)를 기초로 만들어졌으며 docker또한 LXC와 호환이 된다.

컨테이너가 동작하는 아키텍쳐 레이어

파란색 부분은 시스템 전체에서 공유되는 부분이며 노랑색 부분이 개별 컨테이너에 해당되는 부분이다.

여기서 컨테이너 아키텍처를 잘 모르시는 분들을 위해 이 추가로 설명을 해 보도록 하겠다.

가상환경에 어플리케이션을 배포하고자 할때 흔히 겪는 문제들은 다음과 같다.

• 가상환경 서버라고는 해도 환경변수나 언어버전, 라이브러리 버전이 달라 어플리케이션이 동장을 하지 않는다
• 개발환경에서는 잘 움직이다가도 프로덕션 환경에서 제대로 움직이지 않는다
• 기존환경의 가동을 중단시키지 않으면서도 새로운 어플리케이션이나 기능을 추가하고자 한다

이를 해결하기 위해 등장한 것이 지금부터 소개할 차세대 가상화 오픈소스 프로젝트인  docker이다.

차세대 오픈소스 가상화 프로젝트 docker

docker는 Go언어로 작성되어 있으며 오직 리눅스 커널에만 의존 한다. 다시 말해 자바의 바이트 코드가 자바VM이 작동되는 곳 이라면 어디든지 작동 가능했던 것 처럼 docker는 리눅스 커널만 작동 가능한 환경이라면 어느곳 이든 동일한 동작을 보장한다.

이러한 컨테이너 방식의 가상화는 개발자와 운영자에게 어떠한 장점이 있을까?

개발자 입장에서 컨테이너 방식의 가상화 개발은 컨테이너 내부의 관리에만 신경을 써 주면 되고, 한번의 컴파일 만으로도 모든 환경에서동일한 동작을 보장 받게 된다. 패키지의 의존관계나 네이티브 라이브러리, 심지어 DB에 이르기 까지 말이다!
반면 DevOps엔지니어의 입장에서는 한번 설정 만으로 모든 어플리케이션의 배포를 보장 받게 되며, 여기에 운영자에게 여러모로 편리한 로그감시나 리모트억세스, 네트워크설정, 리소스 모니터링 기능이 충실히 따라온다.

docker는 가상 os환경과도 다른데, docker만의 특징을 잘 설명해주는 그림이 여기 있다.

효율성과 편의성. 두마리 토끼를 잡아라!

일반적인 가상OS환경(IaaS)에서는 호스트OS위에 게스트OS가 어플리케이션 수 만큼 올라가야 하므로 게스트OS에 소모되는 리소스 낭비가 많다는 단점을 지닌다. 이에비해 docker engine은 OS자체를 가상화 하는것이 아닌 어플리케이션 작동에 필요한 최소한의 바이너리와 라이브러리만을 가상화 함으로서 이러한 오버헤드를 줄일 수 있게된다. 간단히 말해 docker는 PaaS 클라우드를 구현하기 위한 아키텍처라고 할 수 있으며, 플렛폼 자체의 확장이나 변경이 보다 수월하다는 점에서 기존의 PaaS에서 좀 더 발전된 형태라고 할 수 있다.

docker는 장해 발생시에 그 진가를 발휘하는데, 모든 컨테이너는 고유의 ID를 지니는 동시에 업데이트시에 변경 차분을 보관하기 때문에 장해가 발생되었을 경우 롤 백이 손쉽게 가능하며, 이는 어플리케이션 뿐만이 아니라 DB에도 적용이 된다.

이번에  Joe Beda가 발표한 자료를 통해 구글은 Container Manifest라고 하는 yaml로 작성된 일종의 배포 디스크립터를 독자적으로 개발하여 이용하고 있음을 알 수 있는데, 이를 통해 컨테이너 동작에 필요한 자원 할당과 데이터 소스에 대한 공유를 수행한다. 참고로, 오리지널 사양의 docker는 리눅스의 리소스 제어툴인 cgroups를 이용하여 리소스를 제어한다.
Container Manifest의 상세에 대해서는 구글에서 제공하는 문서를 참고하길 바란다.

아마존의 EC2를 사용해 본 사람이라면 어느정도 수긍하겠지만, OS의 가상화는 관리라는 측면에서 보면 물리서버를 운영하는것과 비교해 더 낫다고 말하기 힘들다. 고작해야 하드웨어 관리에 대한 수고를 덜 수 있을 뿐이고, OS를 비롯해 환경변수나 라이브러리를 구축해야 하는 과정은 사실상 동일하다고 볼 수 있다.

또한 오버헤드의 측면에서도 512MB의 메모리를 지닌 가상머신 인스턴스가 어플리케이션에서 사용 가능한 메모리가 절반에도 미치지 못한다는 점을 감안해 본다면 docker 아키텍처의 유용함을 잘 알 수 있을것이다.

  docker아키텍처를 이용한 가상화는 어플리케이션 배포에 소요되는 노력과 오버헤드를 줄여주며, 프로덕션 환경과 개발환경의 차이를 없애주어 요휼적인 리소스 사용과 다양한 장해에 대한 대응을 가능케 해 준다.

구글이 현재 IT계에서 차지하고 있는 위치와 영향력을 감안해 볼 때에, 구글이 채택하고 있는 컨테이너 아키텍쳐는 어떠한 형태로든지 아마존이나 마이크로소프트와 같은 업체들에 영향을 끼칠것이며(이미 아마존은 대응을 시작했다. AWS Adopts Docker Containers For Elastic Beanstalk ) 조만간 클라우드 컴퓨팅의 중요한 흐름으로 우리 앞에 나타나게 될 것으로 예측해 본다.

관련링크

스케일링과 관련하여 프로덕션 환경에서의 Docker적용에 대해서 좀 더 알아보고 싶다면 다음의 링크들이 도움이 될 것이다.

• About Docker
• How to scale Docker containers in production - SteakOverflow
• AUTO-LOADBALANCING DOCKER WITH FIG, HAPROXY AND SERF
• AppScale on Docker

최종 수정일 : 2014년 12월18일

TDD는 벌거벗은 임금님의 투명옷인가? (1) - TDD는 죽었다. 테스트여 영원하라!

TDD는 벌거벗은 임금님의 투명옷인가?

• 1. TDD는 죽었다. 테스트여 영원하라!
• 2. TDD의 사망에 대한 검증
• 3. TDD는 UT가 아니다

지난주 금요일(2014년 5월 9일) 밤 10시.
스텍오버플로StackOverflow를 비롯해 많은 IT커뮤니티를 술렁거리게한 IT업계의 드림매치가 30분간 차분히 이루어졌다.

발단은 Ruby on Rails의 개발자로 유명한 David Heinemeier Hansson(이하 DHH)가 자신의 블로그에 'TDD는 죽었다. 테스트여 영원하라!TDD is dead. Long live testing.'라는 다소 자극적인 제목으로 블로그 포스트를 올린데서 시작되었다.

David Heinemeier Hansson. 덴마크 출신 프로그래머로 Ruby on Rails의 제작자로 알려져 있지만 르망 24에 출전하는등 프로 레이서 로서의 일면도 가지고 있다.(엄친아?) 사진의 포즈는 보통 중딩들이 새로 산 시계를 자랑하고 싶을때 하는 포즈이지만 신경쓰지 말도록 하자.

여기에 XP와 TDD의 창시자인 Kent Beck선생은 RIP TDD 라는 페이스북 포스팅을 통해 DHH의 의견에한 자신의 생각을 밝힌다.

여기에 쌈구경에 재미가 들린 Martin Fowker선생이 멍석을 깔아준다.
바로 구글 플러스를 통해 두사람의 토론을 온라인 생방송 이벤트로 만들어 버린 것이다.
Is TDD dead?

일단 내용이 만만치 않으므로 이번 포스팅은 세 단원으로 나눠서 작성할 예정이다.

1. TDD는 죽었다. 테스트여 영원하라! - David Heinemeier Hansson의 블로그 번역
2. TDD여 편히 잠들라 - Kent Beck의 페이스북 번역
3. TDD는 죽었는가? - DHH, Kent Beck, Martin Fowler의 온라인 토론 이벤트 정리

아직 국내에는 이름이 생소한 DHH이지만 비교적 젊은 나이에도 불구하고 (79년생) 프레임워크에 있어서 Ruby on Rails가 지닌 지위와 영향력을 생각해 본다면 소프트웨어 업계에 있어서 결코 무시할 수 있는 인물이 아니다.

오늘은 첫번째로 DHH의 주장을 담은 블로그의 글을 번역하는것으로 TDD에 대한 논쟁을 시작해 보고자 한다.

TDD는 죽었다. 테스트여 영원하라!

원문: TDD is dead. Long live testing.

테스트 주도Test-first개발 근본주의는 금욕만을 강조한 성교육과 같이 자기혐오를 불러오는 비현실적이자 비효율적인 도덕 캠페인과 같다.

처음시작은 달랐다. 내가 처음 TDD를 접했을때, 그것은 마치 프로그래밍의 신세계가 내 눈앞에서 열리는것 같았다. 그것은 테스트가 없는 세계로부터 테스트를 당연히 여기는 세계로의 의식개혁과도 같은 것 이었다. TDD는 제대로 테스트된 코드가 주는 평온함에 눈을 뜨게 해 주었고, 코드 변경시에 안정감을 가져다 주었다.

테스트 우선 개발은 자전거의 보조바퀴와도 같은것으로, 테스트는 프로그램을 보다 싶도있게 통찰할 수 있게 해 주었으나 나는 곧 그만두었다.

시간이 흐르면서 테스트 우선이란 슬로건은 점점 더 큰고 격렬한 목소리를 내기 시작했다. 테스트우선 개발을 실행하지 않는것은 죄악시 되었고 나 자신도 그러한 근본주의 소용돌이에 휘말려 들었는데, 그것은 마치 종교적인 금욕주의 가르침을 따라가지 못하는 자신이 부끄러워지는 느낌이었다. 그리하여 나도 테스트 우선 개발을 시험해 보기로 했지만 몇주만에 결국 그만 두었다. 테스트 우선 개발이 내 설계를 망쳐놓기 시작했기 때문이다.

테스트 우선 개발은 마치 광신도의 신앙심에 대한 자부심과도 같이, 오직 교리에 적힌 한구절 한마디를 충실히 지키는 것 만이 천국에 이르는 유일한 길이고, 그대로 하지 않으면 지옥에 떨어진다고 하는 희열과 절망의 요요였다. 그리고 그것을 그만둔 나는 모두 함께 가는 버스에서 혼자만 내린 기분이었다.

아마도 처음에는 자동화된 회귀 테스트 따위는 없어도 된다라고 하는 업계의 관행을 부수기 위한 충격요법으로서 테스트 우선 개발이 필요 했을지도 모른다. 아마도 처음에는 글자 곧이곳대로 일상적으로 수행하는 프로그램 개발에 적용하는것을 의도하지는 않았을지도 모른다. 하지만 어찌되었든 시작을 한다고는 해도 금방 중단되기 일쑤였지만, 불경한자를 단죄하는 헤머와도 같이 TDD를 성실히 행하지 않는것은 프로 소프트웨어 개발자로서의 자격이 없다고 낙인 찍혀 버린다. 이것은 리트머스 테스트이다. (단순한 기준으로 흑백이 구분되어버린다는 뜻:역자주)

이제 충분하다. 그만 두겠다. 나 데이빗은 더이상 테스트 우선 개발을 하지 않는다. 나는 더이상 그것에 대해서 사과하지도 숨기지도 않겠다. 나는 TDD가 회귀 테스트에 눈 뜨게 해 준것에 감사한다. 하지만 더이상 TDD에 끼워 맞춰 프로그램을 설계하지는 않는다.

나는 여러분께 TDD적인 접근이 정말로 당신의 시스템의 완전성과 일관성에 어떠한 영향을 주고 있는가를 진지하게 다시 검토해 보기를 권한다. 만약 이것이 정말 좋은것은 아닐지도 모른다는 가능성을 심각하게 받아들이게 된다면, 당신은 메트릭스에 등장하는 붉은 알약을 먹는것이 될 수도 있다. 그리하여 직면하게된 현실 세계는 당신이 원하던 것이 아닐 수도 있다.

그럼 이제 어디를 향해야 하는 것 인가?

최초의 한걸음은 문제의 존재를 인정하는 것 이다. 여러분도 여기까지는 동의할 것으로 생각한다.  그 다음은 메소드에서 시작해 시스템 전체에 이르는 다양한 범위의 테스트에 대해 균형을 잡는것이다. 지금의 열광적인 TDD열풍은 유닛(메소드) 단위의 테스트에 초점이 맟춰져 있다. 왜냐하면 이름 그대로 유닛테스트의 범위는 유닛에 한정되어 버리기 때문이다. (원래부터 테스트 우선 개발의 근거가 이것이다.)
하지만 나는 이것이 올바르지 않다고 생각한다. 테스트 우선개발의 유닛테스트는 중간적인 오브젝트나 간접적이고 지나치게 복잡한 구조를 낳기 십상이다. 게다가 느려지는것을 피하려고 하다보니 데이터베이스나 I/O관련 테스트도 기피하게 된다. 브라우저를 이용한 시스템 전체의 테스트도 지양하게 되어 버린다. 그 결과, 진정 무서운 괴물과도 같은 프로그램 구조가 탄생하게 된다. 서비스오브젝트라던지 커맨드패턴이 형편없이 얽히고 설킨 정글과도 같은 아키텍쳐 말이다.

나는 전통적인 의미의 유닛테스트는 거의 하지 않는다. 모든 의존관계를 목(Mock)으로 하면, 수천건의 테스트가 수초만에 끝나는 유닛테스트 이지만, 레일즈Rails 어플리케이션의 테스트에 있어서 좋은 방법은 아니라는, 단지 그 이유 한가지이다. 나는 실제레코드를 직접 데이터베이스에 억세스하여 동작시키는 방식으로 테스트를 진행한다. 상위레이어에는 컨트롤러 테스트가 있지만, 나는 어느쪽인가 하면 상위레이어에 대한 시스템 테스트는 Capybara나 이와 비슷한 것을 사용하여 테스트하는 편이다.

나는 이것이 우리가 가야 할 방향이라 생각한다. 유닛테스트의 중요도를 내리고, 설계의 일부로서 테스트 우선 개발을 사용하지 않는것이다. 그리고, 보다 시간이 오래 걸리긴 하지만 시스템 테스트의 중요성을 부각시켜야 한다.(게다가, 클라우드의 등장으로 테스트조차도 클러스터링이 가능해 짐에 따라 더이상 시스템 테스트도 느리지만은 않다.)

Rails는 이러한 전환에 도움이 된다. 오늘, 우리는 풀 시스템 테스트 자동화를 장려하기 위해 아무것도 하지 않는다. 정답은 미리 준비되어있지 않다. 단지 실수를 고쳐나갈 뿐이다. 하지만, 여러분은 굳이 실수를 할 때까지 기다릴 필요가 없다. 오늘 당장 Capybara를 돌려보라. 그리고 내일이면 좋은 아이디어가 우리들 머리속에 가득할 것이다.

자, 우선은 심호흡을 하자. 우리가 지금 하려는 것은 신성한 암소를 도살하는 것 이다. 고통스럽고 피를 보는 과정이 수반될 것이다. TDD는 이미 성공적으로 많은 프로그래머들의 머리속에 자리잡고 있다. TDD는 그들이 하는 행위가 아닌 그들 자신이 되어버린 것 이다. 그러한 사람들을 원래대로 돌리기 위해서는 커뮤니티를 만들어 진지하게 임하지 않으면 안되고, 시간또한 오래 걸릴 것 이다.

여기서 우리가 저지를 수 있는 최악의 선택은 또다른 테스트 종교를 만드는 것이다. 이를테면 "시스템 테스트야 말로 진리이다!"와 같은 또다른 황금소의 우상을 만드는 모습이 눈앞에 선하다. 제발 그러지는 말았으면 한다.

그렇다. 나에게 있어서 테스트 주도 개발은 죽었다. 하지만 그 죽음을 축하하며 무덤앞에서 춤을 춘다던지 단점을 조롱하기 보다는, TDD가 소프트웨어 개발에 가져온 기여에 존경을 표하고자 한다. TDD는 우리들의 역사에 중요한 족적을 남겼다. 그리고 지금은 그 다음을 향해 가야할 시간이다.

테스트여 영원하라!

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