Google Play 스토어는 10여 년 전인 2012년에 출시된 이래, 끊임없이 발전하는 전 세계의 수많은 앱과 게임을 수십억 명의 사용자와 연결하며 Android의 중심 역할을 해 왔습니다.
세계 최대 Android 마켓플레이스의 서비스 인프라는 어떻게 설계해야 할까요? 소비자를 대상으로 하는 소프트웨어의 경우, 창의적인 엔지니어링 솔루션을 마련하더라도 Google 규모의 서비스에 필요한 까다로운 조건을 충족하지 못하는 일이 많습니다. 따라서 Google의 모든 시스템은 Google Play 스토어의 기준에 맞는 특유의 가용성, 품질, 지연 시간 조건을 지킬 수 있도록 세심한 개선을 반복적으로 거칩니다.
기능 엔지니어링이란?
기능이란 사용자와 직접 상호 작용하는 형식, 콘텐츠, 콘텐츠의 배열, 페이지 레이아웃, 정보 아키텍처 등을 말합니다. 형식은 추천 시스템, 광고주, 머천다이저 등의 다양한 소스가 제공하는 앱 콘텐츠가 UI에 표시되는 방식을 결정합니다. 적절한 콘텐츠와 UI로 맞춤형 환경을 형성하여 Play 스토어를 이용하는 사용자에게 가장 관련성 높은 앱과 게임을 제안하는 것이 그 목표입니다.
소비자를 대상으로 하는 기능의 영역에서는 사용자의 의견과 선택, 개발자 생태계, 수요가 너무 빠르게 바뀌는 바람에 인프라가 따라잡지 못하기도 합니다. 그런 환경에서 엔지니어가 직면하는 가장 큰 어려움은 확장성과 성능의 제약 안에서 변화에 발맞추는 한편 소비자 공간의 요구사항을 충족하는 인프라를 설계하는 것입니다. 이처럼 역동적인 공간에서 발생하는 엔지니어링의 어려움을 몇 가지 자세히 살펴보겠습니다.
성공의 요소
Play 스토어처럼 데이터를 기반으로 하는 구조에서는 모든 중요 요소를 평가할 수 있는 측정항목이 마련되어 있습니다. 성공의 정도를 측정하고 추적할 때 유용한 몇 가지 기준을 아래에 소개합니다.
제품/비즈니스 측정항목 - 검토 대상인 제품이나 서비스에 해당하는 측정항목입니다. 새로운 관리가 필요할 때 A/B 테스트로 이 측정항목의 변화를 측정하면 신뢰도를 확보할 수 있으며, 득실을 따지는 의사 결정을 할 때 특히유용합니다.
성능 - 지연 시간, 오류율, 가용성 측정은 당연하게도 거의 모든 서비스의 근간을 이룹니다. 이들은 제품에 대한 사용자의 경험과 인식을 면밀히 추적하는 기본 측정항목이므로 반드시 알아 두어야 합니다.
시스템 상태 - 리소스 사용률과 연결 안정성을 추적하는 내부 시스템 측정항목입니다.
기능 엔지니어링 인프라의 어려움
Play 스토어의 요구사항에 맞게 확장하는 한편 사용자 상호 작용의 유동성과 반응성을 성능 기준 이상으로 확보할 수 있는 백엔드 시스템을 설계하는 것이 무엇보다도 중요합니다. 엔지니어링의 관점에서 보자면 인프라는 비즈니스의 요구를 충족할 수 있도록 지속적으로 발전해야 합니다. Play 스토어의 인프라도 예외가 아니기에, 오늘날 사용자들이 이용하는 신규 기능의 발판을 마련하고 현대화, 기술 부채 탕감, 특히 지연 시간 단축을 이루기 위하여 지난 10년간 여러 단계의 발전을 거쳤습니다.
잦은 반복
어려움: 기능은 오랫동안 반복적으로 시험해야 하지만, 앞으로 발생할 모든 요구사항을 미리 충족하는 엔지니어링 인프라를 계획하기는 쉽지 않습니다.
실험이 일상인 환경에서는 기능을 적정 규모로 신속히 구축하고자 최적의 접근 방식을 취해도 기술 부채가 발생하는 일이 비일비재합니다. 기술 부채는 종류가 다양하므로, 실패로 끝난 기능이 쌓이다 보면 정리가 어려워지고, 성능이 하락하며, 까다로운 테스트를 피할 길이 없는 코드 오류가 발생하기도 합니다.
협력하기 어려운 개발 환경
어려움: 수백 명의 엔지니어가 활동하는 대규모 조직에서는 여러 기능을 동시에 제각각 개발하곤 합니다.
인프라를 재사용하고 함께 혁신을 이루려 하면 속도가 심각하게 떨어지는 일이 많습니다. 제품이 빠르게 발전하는 부문에서는 시스템의 유연성을 위해 각종 수단을 투입하는 데 상당한 불확실성이 따릅니다. 투입 수단이 너무 많으면 시스템이 지나치게 복잡해지고, 너무 적으면 반복으로 인한 비용이 치솟습니다. 양쪽 사이에서 균형을 찾는 것은 이 부문에서 활동하는 기능 엔지니어가 갖추어야 할 핵심 역량입니다.
실험 시간
어려움: 근사한 엔지니어링 솔루션을 개발하는 데 시간이 소요되어 기회 비용이 발생합니다.
실험 시간은 사용자를 대상으로 하는 기능을 위한 솔루션을 설계할 때 염두에 두어야 할 매우 중요한 측정항목입니다. 반복 속도를 향상하고 지연 시간을 비롯한 성능 관련 SLO를 충족하는 유연한 설계가 이상적입니다.
하지만 실제로는 변경 사항으로 인해 특정 사용자가 받을 영향을 추정할 때 어림짐작에 기대야 할 부분이 많습니다. 과거의 데이터와 경험을 거리낌 없이 활용할 만한 상황도 있겠지만, 전에 없던 완전히 새로운 아이디어에 적용하기에는 무리가 있습니다.
기능 엔지니어링의 원칙
Play 스토어가 최첨단 혁신을 꾀하고자 위의 어려움을 해결하는 방법은 다음과 같습니다.
성공에 직결되는 데이터 측정항목을 참고해 실험을 수행하고 출시를 결정합니다
최적의 출시 시점을 찾으려면 사용자에게 기능을 제공하고 앱 설치와 같은 스토어 비즈니스 측정항목에 어떤 영향이 있는지 A/B 테스트를 통해 알아내야 합니다. 데이터를 기반으로 하는 빠른 반복을 수행하면 최종 기능을 목표에 맞게 조정할 수 있습니다. Google은 세계적인 규모로 A/B 테스트를 실행하기 위한 여러 자체 개발 기술을 보유하고 있으며, 이 기술들은 실험의 원활한 진행에 도움을 주는 측정항목 표시 도구와 전혀 어긋나지 않게 잘 작동합니다. 따라서 개발자 여러분은 분석 대신 코딩에 더 많은 시간을 할애할 수 있습니다.
품질에 집중할 수 있도록 양질의 MVP 위주로 설계와 실험을 수행합니다
설계를 시작하기 전에는 몇 가지 중요한 질문에 대한 답이 필요합니다. 무엇을 개발할지 결정하고, 개발 결과물이 Google의 품질 기준을 충족하는지 판단하고, 엔지니어링 비용을 파악하고, 해결하고자 하는 사용자의 요구사항이 무엇인지 이해해야 합니다. 따라서 기능 엔지니어링에는 제품 관리자와의 긴밀한 협업이 필요할 때가 많습니다. 사용자 여정에 맞는 합리적인 엔지니어링 시간 내에 구축할 수 있는 MVP를 위주로 삼는 것이 성공의 핵심입니다.
인프라를 자주 쇄신하여 기술 부채를 정리합니다
반복을 자주 수행하고 MVP를 빨리 개발하다 보면 각종 부작용이 따르는데, 그중 심각한 것이 기술 부채입니다. 속도 향상을 위한 최적화 과정에서 중요 단계를 건너뛰면 측정항목 실행이 불가능해져 코드를 쓰지 못하게 되거나 실험 플래그가 삭제될 수 있고, 이런 문제를 방치하면 테스트와 유지 관리가 어려워지는 데다 향후 개발 속도에도 차질이 생깁니다. 반면 최근에 나온 훌륭한 프레임워크를 이용해 지연 시간을 최대한 줄이거나 개발 과정을 단순화하면 장기적으로 큰 이득이 됩니다. 리팩터링 혹은 완전 재작성을 통해 인프라를 자주 쇄신하는 것은 코드가 잘못 설계되었음을 인정하는 일일 수도 있지만, 기능 엔지니어라면 감수해야 할 일입니다. 사용자와 기능 사이의 상호 작용이 이루어지지 않으면 아무리 멋진 인프라라도 의미가 없을 겁니다.
