2010년, 나는 첫 번째 공개 프레젠테이션에서 넷플릭스(Netflix)의 동향, 오픈소스를 사용해서 클라우드로 전환하는 방법, 나중에 마이크로서비스로 알려진 분산 아키텍처, 카오스 테스팅, 개발자들이 어떻게 서비스를 운영하는지를 설명하면서 데브옵스의 특징 중 하나인 상시 운영 방식에 대해 설명했다. 혼란스럽다는 반응과 아무도 모방할 수 없는 이상한 '유니콘' 같다는 일반적인 의견, 그리고 곧 엔터프라이즈 라이선스 제품을 실행하는 데이터센터로 다시 돌아가게 될 것이라는 의견이 뒤섞여 있었다.
하지만 호기심과 흥분을 감추지 못한 몇몇 사람들이 트위터에서 #clouderati라는 그룹과 많은 토론을 벌였다. 그 그룹에서 나는 사이먼 와들리(Simon Wardley)를 만나 우리가 하고 있는 연구에 대해 자세히 설명했다. 그 대가로 그는 나에게 매핑 기술을 설명해줬다. 맵을 통해 넷플릭스가 맵을 사용하지 않더라도 상황 인식이 뛰어나고, 정책을 적절히 사용하며, 시스템적 사고로 접근하고, 사이먼이 설명한 여러 모범 프랙티스와 잘 부합한다는 것을 이해할 수 있었다.
지난 12년 동안 이 아이디어가 비주류에서 주류로 이동하면서 내 업무의 큰 부분은 넷플릭스와 아마존(Amazon)에서 개발한 아이디어를 크고 작은 다른 조직과 애플리케이션에 설명하고 적용하는 일이 됐다. 내가 경험한 것 중 가장 잘 정리된 방법론이 이 책이다. 이 책은 와들리 매핑을 사용해 오늘날 최고의 아이디어를 어떻게 취하고, 어떤 상황에서 어떤 정책이나 기법을 사용해야 하는지를 알려준다.
넷플릭스에서 개발한 아이디어는 이전에 나온 아이디어를 종합한 것이다. 우리 중 다수는 수십 년의 경험을 바탕으로 프레드릭 브룩스(Frederick Brooks)의 『맨먼스 미신』(인사이트, 2015)과 콘웨이의 법칙을 잘 알고 있다. 또한 2006년에 나온 버너 보겔스(Werner Vogels)의 '실행한 대로 실행하라'라는 「ACM 큐」 매거진 기사도 접했고, 오픈소스 개발 프랙티스에서 영감을 얻었다. 넷플릭스 팀은 썬 마이크로시스템즈(Sun Microsystems), 제록스 파크(Xerox PARC) 및 이베이(eBay), 구글(Google), 야후(Yahoo)의 초창기 시절에 개발했던 아이디어를 가져왔다. 넷플릭스의 최고경영자인 리드 헤이스팅스(Reed Hastings)는 소프트웨어를 깊이 이해하고 있었으며, 우리가 새롭게 시작해 혁신을 확장하고 지원할 수 있는 아키텍처를 구축하도록 독려했다.
넷플릭스에서 개발한 아이디어를 모방하려는 일부 시도는 이러한 아이디어가 더 엄격하고 느리게 진화하는 규칙과 모범 프랙티스 패턴이 아니라 원칙과 정책을 사용해 서로를 강하화는 유동적인 방식으로 구성하는 역동적인 기본 시스템의 산물이라는 점을 놓쳤다. 이로 인해 넷플릭스의 성공을 모방하려는 조직은 종종 '아키텍처 극장'을 만들었고, 실패했다.
이러한 조직 중 상당수는 기술조직이 넷플릭스나 아마존처럼 작동하도록 '비즈니스'를 어떻게 이끌어낼지에 대한 고민을 하고 있었다. 한 최고정보책임자는 자신들은 우리처럼 뛰어난 엔지니어가 없어서 넷플릭스를 따라갈 수 없다고 말했다. 나는 우리가 방금 당신의 조직에서 누군가를 고용했다고 대답했다.
인재가 문제가 아니다. 문제는 별도의 비즈니스 조직을 두는 것 자체다. 넷플릭스나 아마존의 어느 누구도 '비즈니스'에 대해 이야기하지 않는다. 내가 근무할 당시 넷플릭스는 단일 제품 조직으로 구성돼 있었다. 제품관리와 개발에 종사하는 모든 사람이 최고제품책임자에게 보고했다. 최고정보책임자나 최고기술책임자는 따로 없었다. 아마존은 수많은 독립적인 서비스 팀으로 구성돼 있으며, 이들 중 누구도 최고정보책임자나 최고기술책임자에게 보고하지 않는다.
2014년 말 AWS 람다(Lambda)가 출시됐다. 당시 흥미롭다고 생각했고, 2016년 말에 AWS에 입사해서 하루 동안 진행된 AWS re:Invent 해커톤의 심사위원을 맡게 됐다. 모든 팀이 람다를 사용해 서버리스 아키텍처를 구축하는 것을 보고 놀랐고, 하루 만에 제로에서 시작해서 결과물을 만들어낼 수 있다는 것을 보고 또 놀랐다. 나는 마이크로서비스 워크숍에서 이 이야기를 들려주기 시작했고, 일부 청중은 아주 짧은 시간에 저렴한 운영 비용으로 소규모 팀에서 엄청난 양의 기능을 개발해냈다는 유사한 이야기를 들려줬다.
매우 흥미로운 이야기지만, 문제는 서버리스가 마치 거짓말 같은 동화처럼 느껴졌다는 것이다. 실제로 적용했을 때 결과는 몇 배 이상 개선됐지만, 대부분의 사람은 이것을 환상이나 '유니콘' 기업만이 사용할 수 있는 것으로 치부했다.
2010년에 내가 처음 넷플릭스 강연에서 설명했을 때와 마찬가지로, 대부분의 사람들은 당황하거나 무시했지만, 몇몇은 서버리스에 대한 아이디어를 받아들였다. 사이먼 와들리도 이에 주목해서 클라우드의 진화를 예측하고 서버리스가 미래라고 선언했다. 그 사이 AWS는 서버리스를 할 수 없는 이유에 대해 고객이 제기하는 모든 반대를 체계적으로 불식해 나가고 있었고, 나는 '서버리스 우선'이라는 제목의 강연을 통해 조직이 첫 번째 시도로서 서버리스로 모든 것을 구축한 다음 꼭 필요한 경우에만 콘테이너와 특별한 인스턴스 타입을 사용해야 한다는 주장을 하기 시작했다.
당시 수많은 AWS 고객들과 이야기를 나눴는데, 리버티 뮤추얼(Liberty Mutual)과 연결됐고 데이비드 앤더슨(David Anderson)과 그의 팀을 알게 됐다. 우리는 즉시 연락을 취했고, 몇 년에 걸쳐 정기적인 미팅을 시작했다. 데이비드와 그의 팀은 서버리스를 비롯한 리버티 뮤추얼로부터 얻은 최신 모범 프랙티스를 정리하고 이런 프랙티스를 적용하는 방법을 파악하기 위해 와들리 맵을 사용하는 체계적인 접근 방식을 취했다.
놀라운 점은 이 오래된 보험 회사가 내가 아는 한 가장 혁신적이고 빠르게 움직이는 개발 조직 중 하나를 구축했다는 점이다. 워낙 빠르고 저렴한 비용으로 개발이 진행되다 보니 제품 팀은 서버리스를 시도하기 전까지 다른 기술 플랫폼을 고려하지 않았다. 일부 사람들이 락인(lock-in)을 피하기 위해 기본적으로 쿠버네티스를 사용하자고 얘기했을 때, '왜 10배나 더 많은 시간과 비용을 들여야 하는가? 나중에 어떠한 이유로 이식성을 필요로 하면 그때 시간과 비용을 투자하면 되지.'라는 반응이었다. 또한 새로운 아이디어를 생각해내는 속도보다 구축되는 속도가 더 빠르기 때문에 제품 딜리버리의 병목현상이 제품 관리자에게로 옮겨졌다고 말했다. 이들은 서버리스 우선의 이점을 경영 모든 단계에 걸친 회사의 핵심 이점으로 설명했다.
나는 최근에 은퇴하고 아마존을 떠났기 때문에 넷플릭스나 아마존이 어떤 일을 했는지 더 이상 설명할 수 없다. 그러나, 이 훌륭한 책을 통해 앞으로 몇 년 동안 혼란스럽고, 호기심 많은 차세대 독자에게 리버티 뮤추얼에서 어떤 일을 했는지 설명할 데이비드, 마크, 마이클에게 그 바통을 넘겨주게 돼 기쁘다.
게임의 본질은 오락으로서의 재미다. 그러므로 게임을 개발한다는 것은 게임적 재미를 찾아가는 것을 의미한다. 이러한 게임의 본질은 일반적인 소프트웨어를 개발하는 것과 크게 다른 근본적인 차이를 야기한다.
일반적인 소프트웨어는 사용자가 원하는 기능이 올바로 구현되면 성공적으로 개발되었다고 할 수 있다. 그러나 게임 소프트웨어는 '구현된 기능이 재미있는가?'라는 추가적인 요구사항이 따른다. 만약 재미가 없다면 그 기능이 완벽하게 개발되었더라도 수정되거나 삭제될 수밖에 없다.
문제는 이 게임의 재미라는 것이 상당히 주관적이며 예측하기 어렵다는 점이다. 몇 가지 기능이 재미있다 하더라도 전체 게임 시스템이 완성되었을 때의 재미 문제는 전혀 다를 수 있기 때문이다. 상당히 단순한 메커니즘을 가지고 있는 게임일지라도 그 메커니즘에서 재미를 극대화시킨다는 것은 대단히 어렵다는 점에 모든 게임 개발자들이 동의할 것이다.
이러한 게임의 불확실성과 복잡성 같은 속성들로 인해 게임 개발 프로젝트를 관리하는 것은 매우 어렵다. 이 책의 저자는 이러한 문제에 대해 게임 개발자들이 전통적인 계획 작성 도구와 규범화된 방법으로 접근을 시도했다고 봤다.
한국의 상황도 크게 다르지 않았다. 허들시스템 등의 프로젝트 관리 방법론은 전통적으로 규범화된 제품 개발 방법론이었고, 많은 개발 스튜디오들이 비슷한 폭포수 방식의 개발 방법론을 사용해왔다.
폭포수 방식의 개발 방법론이 지닌 문제는 명확하다. 기획 단계에서 구현되지 않은 게임의 재미를 예측해 설계하는 것은 대단히 어렵다. 더구나 기획 단계 시점과 게임 오픈 시점 간의 시차는 게임 업계의 시간 개념으로는 매우 긴 시간이기에, 그동안 시장과 게이머가 어떻게 바뀔지도 알 수 없다. 그런데 게임 시스템이 완성되어 테스트에 들어가는 시점이 되었을 때에야 비로소 게임의 실체를 테스트해볼 수 있게 되니 테스트 결과가 좋지 않더라도 이미 어쩔 수 없는 일이 되어 큰 폭의 수정 없이 그대로 오픈하게 된다. 다행히 재미있는 게임이었다면 성공하겠지만, 불행히도 한국의 게임 역사에서는 큰 실패를 안겨준 대작 게임들이 더 많았다.
클린턴 키스는 이러한 문제에 대해 애자일 스크럼이라고 하는 일 잘할 수 있는 방안에 대해 실증적이면서 구체적으로 설명한다.
이 책에서도 중요하게 인용되는 켄 슈와버와 제프 서더랜드는 그들의 문서 '스크럼 가이드(The Scrum Guide)'를 통해 다음과 같이 스크럼을 평가한다.
■ 간단하고
■ 이해하기 쉽지만
■ 마스터하기는 어려운 프레임워크
스크럼은 대단히 쉽게 배울 수 있는 방법론이다. 하지만 '어떻게 적용할 것인가?'에 대해서는 많은 고민과 성숙된 경험이 필요하다. 물론 스크럼을 잘 수행할 수 있는 팀을 갖추는 것은 더 어렵다. 하지만 이 책을 통해 독자들은 애자일 스크럼의 철학부터 게임 개발이라는 특수성에 맞는 구체적인 적용 방안에 대한 지식까지 얻을 수 있다. 최고 수준의 해외 게임 개발 스튜디오가 일하는 방법을 접해보는 것도 흥미로울 것이다. 참고로 이 책에서 다루는, CCP 게임즈(CCP Games)가 어떻게 <이브 온라인(EVE Online)> 개발 프로젝트에 애자일 스크럼 방법론을 적용 했는지에 대한 소개 영상도 유튜브에서 볼 수 있으니 반드시 시청하기 바란다(https://www.youtube.com/watch?v=GqsReCZD4hc).
게임 프로듀서로서 애자일 스크럼 게임 개발 프로젝트 관리의 바이블인 이 책이 마침내 한국에 소개되는 것이 매우 반갑다. 더군다나 이 책을 번역한 박현철 님, 전장호 님은 애자일 스크럼에 대한 풍부한 현장 경험과 지식을 갖춘 분들로, 이 책의 번역 작업을 맡아주셔서 업계의 한 사람으로서 깊이 감사한다. 일반적인 기술 서적과는 다른 특수성을 지닌 전문적인 내용을 번역하느라 많은 어려움이 따랐으리라 생각한다. 훌륭한 결과물과 그간의 노고에 박수를 보낸다.
