'인프라'에 해당되는 글 1건

  1. 2011.02.10 구글의 실험 인프라스트럭쳐 - 지속적인 혁신의 비밀 1
예전에 구글의 진짜 경쟁력은 유연성이라는 글을 쓴 적이 있는데, 최근에 데이터에 기반한 지속적인 혁신을 가능하게 하는 구글의 실험 인프라에 대한 논문이 나왔습니다. 예전 글에서 "On most Google queries, you’re actually in multiple control or experimental groups simultaneously"라는 구글 엔지니어의 말을 인용했었는데, 이 논문에서는 구체적으로 어떤 기술이 그런 실험을 가능하게 하는지를 소개하고 있습니다. 

이 논문에서 소개하는 핵심 개념이 Multi-factorial Experimental Design입니다. 한번에 한가지 요인(Factor 혹은 Parameter)을 통제하는 일반적인 실험설계와 달리, Multi-factorial Experimental Design에서는 한번에 여러 요인을 동시에 변화시키며 결과를 관찰합니다. 물론 변화시키는 요인 간에는 서로 간섭이 없는 독립성이 보장된다는 조건이 붙지만, 한 데이터에 대해 N가지의 요인을 동시에 바꿀 수 있기 때문에 실험에 필요한 데이터의 양이 1/N로 줄어든다는 장점이 있습니다. 세계에서 가장 많은 검색 데이터를 가진 구글이 데이터를 아끼기 위해 이런 기법을 도입하고 있다는 점이 놀랍습니다. 저자들의 설명을 들어봅시다.

The solution we propose in this paper is to partition the parameters into subsets, and each subset contains parameters that cannot be varied independently of each other. A subset is associated with a layer that contains experiments, and traffic diversion into experi- ments in different layers is orthogonal. Each query here would be in N experiments, where N equals the number of layers.

이들이 소개하는 구글의 실험 인프라는 단지 N개의 실험을 동시에 진행하는 수준에 그치지 않습니다. 실험을 위해 분리된 트레픽의 일부를 본 논문에서는 도메인(domain)으로, 파라메터의 일부를 레이어(layer)로 정의하는데, 도메인은 레이어를 그리고 레이어는 서브 도메인를 포함할 수 있습니다. 즉, 한 실험 내부에서 좀더 세분화된 실험을 진행할 수 있는 것입니다. 

또한, 성공적인 실험을 거쳐 런칭에 들어가는 기능에 대해서도 같은 인프라를 사용한다는 점도 흥미롭습니다. 즉, 런칭에 사용할 트레픽을 따로 분리하는 대신에, 런칭될 기능을 일종의 기본값으로 정의하고, 실험 설계에 따라 그 값을 덮어쓰도록(override) 하는 것입니다. 이렇게 하면 다양한 실험에 영향을 끼치지 않고 특정 기능을 서서히 런칭할 수 있습니다. 

Defining launch layers in this way allows us to gradually roll out changes to all users without interfering with existing experiments and to keep track of these roll-outs in a standardized way. The general usage of launch layers is to create a new launch layer for each launched fea- ture and to delete that layer when the feature is fully rolled out (and the new parameter values are rolled into the defaults). Finally, because experiments in launch layers are generally larger, they can be used to test for interactions between features.

아래 다이어그램은 위에서 설명한 실험 인프라의 사례를 보여줍니다. 맨 위에 모든 트레픽에 걸쳐 파라메터 일부에 대한 기본값을 제공하는 런치 레이어가 있고, 그 아래 트레픽 일부에 대해 다양한 파라메터 조합을 테스트하는 실험 레이어가 있습니다. 위에서 설명한대로 실험 레이어는 여러 도메인으로 나뉘고, 각 도메인의 레이어는 또다시 도메인과 레이어를 포함할 수 있는 구조로 되어있습니다.

이 논문은 이밖에도 구글의 실험 인프라에 대한 여러 디테일을 포함하고 있습니다. 그중 흥미로웠던 점은 CTR (click-through rate)과 같은 지표가 표준화된 형태로, 그것도 실시간으로 실험자에게 제공된다는 점입니다. 이처럼 어떤 실험을 누가 하더라도 일관성 있는 결과를 빠르게 알 수 있기 때문에, 여러 팀에서 작업한 결과물이 투명하게 평가되고 실 서비스에 즉시 반영될 것입니다. 저자들은 마지막으로 여기에 소개한 인프라가 구글의 혁신을 가속화한다는 수치적 결과를 소개합니다.



작년에 Bing에서 인턴을 하면서도 느꼈지만, 검색이라는 대용량 서비스를 가능하게 하는 것은 실제 서비스에 사용되는 프로덕션 시스템 만큼이나 이를 뒷받침하는 인프라라는 생각을 해 봅니다. 그리고 이 논문은 구글과 같은 큰 조직에서 어떻게 데이터에 근거한 신속한 의사결정을 가능하게 하는지를 실증적으로 보여줍니다.  최근 구글도 관료화되었다는 말이 많이 나오지만, 적어도 이 논문을 읽어보면 윗선에서 떨어지는 명령에 의한 일방적인 의사결정이나, 조직간의 정치적 알력이 기업의 의사결정에 작용할 여지는 별로 없어 보입니다.

맺음말

많은 사람들이 구글의 '현재 모습'을 부러워합니다. 하지만 이 논문에서 알 수 있듯이 구글의 진짜 힘은 혁신의 결과물이 아니라, 혁신을 지속하고 가속화하는 이러한 인프라일 것입니다. 이 논문에 공개된 내용을 따라한다고 해도, 그것이 구글의 최신(bleeding edge) 기술이라고 믿기는 어렵고, 그 사이에 그들은 또 저만치 달아나 있을 것입니다. 마이크로소프트의 실험 인프라도 이에 결코 뒤지지 않습니다. 요즘 많이 들리는 말입니다만, 조직 전체에 혁신을 체질화하는것만이 이런 기업과 경쟁할 수 있는 역량을 갖추는 길이라는 생각이 듭니다. 물론 여기서의 혁신은 일회성의 구호가 아니라, 지속적으로 데이터에 근거한 신속한 의사결정을 내릴 수 있는 문화와 인프라일 것입니다.