[A/B 테스트] 12장. 클라이언트 측 실험

본 내용은 [A/B테스트, 론 코하비 저] 교재를 활용하여 작성되었습니다.

https://product.kyobobook.co.kr/detail/S000060625360

A/B 테스트 | 론 코하비 - 교보문고

---

본문

12장. 클라이언트 측 실험 (P. 221 ~ 230)

 

 

1. 개요

 현재는 모바일 사용량이 폭발적으로 증가함에 따라, 모바일 앱에서 실행되는 실험의 개수도 증가 중인 상황이다. 이에, 출시절차 및 인프라, 사용자 동작으로 인한 신 클라이언트와 식 클라이언트의 차이를 이해하는 것은 실험의 신뢰성을 보장하는데 매우 유용할 수 있다.

---

2. 서버 측과 클라이언트 측의 차이점

-  온라인 실험에 영향을 주는 서버와 클라이언트 측의 주요한 두 가지 차이점은 출시 프로세스와 데이터 통신이다.

 

차이1. 출시 프로세스

 온라인 웹사이트에서는 새로운 기능 출시가 지속적으로 발생하는 것이 일반적이다. 조직에서 이러한 변경사항을 관리하기 때문에 지속적 통합, 배포와 같은 서버 측 업데이트는 비교적 쉬운 편이다. 그리고, 종합 대조 실험에서는 사용자가 보는 변수는 서버에서 완전히 관리되며, 사용자의 행동이 요구되지 않는다.

 

 클라이언트 앱의 경우 많은 기능이 서비스,  즉 페이스북 앱에 표시된 피드 컨텐츠와 같은 서버 측 코드의 영향을 계속 받을 수 있다. 이러한 영향을 주는 변경 사항은 웹 페이지와 유사한 출시 절차를 따를 수 있는데, 실제로 서비스 의존성이 강할수록 신속히 실험을 구현할 수 있고 다양한 클라이언트에 대해 일관성 있는 실험이 가능하다. 구글과 같은 기업의 많은 변경 사항은 서버 측에서 이루어지며 웹, 모바일과 같은 식 클라이언트를 포함한 모든 클라이언트에 영향을 미친다.

 

 클라이언트 자체에는 많은 양의 코드가 들어있다. 이 코드의 변경 사항은 다르게 배포되어야 한다. 모바일 앱의 개발자는 배포와 출시 시기를 제어할 수 없으며, 출시 프로세스에는 앱 소유자, 앱 스토어, 최종 사용자라는 당사자가 있기 때문이다.

 

 코드가 준비되면 스토어에 해당 빌드 파일을 제출하여 검토를 맡긴다. 이 과정에서 사용자는 새로운 버전에 대한 소프트웨어 업데이트 여부를  선택할 수 있게 되는데, 업데이트를 지연시키거나 무시할 수 있다.

 

구글 플레이와 앱스토어 모두 단계적 출시를 지원한다는 점에 주목한다. 이는 앱 소유자가 일정 비율의 사용자만 사용할 수 있도록 하고, 문제가 발생할 경우 일시 중지할 수 있다. 랜덤화 실험이라고 볼 수도 있겠지만 이는 앱 소유자는 적격의 사용자를 알 수 없으므로 랜덤화 실험이라고 보기는 힘들다. 앱 소유자는 누가 새 앱을 채택했는지만 알 수 있다.

 

 앱 소유자는 새 버전을 자주 배포하는 것을 원치 않을 수 있다. 네트워크 비용, 사용자 불편성 등을 야기할 수 있기 때문이다. 특히 재부팅이 필요한 업데이트라면 빈번한 업데이트를 할 수 없을지도 모른다.

 

 

차이2. 클라이언트와 서버 간의 데이터 통신

 앱이 사용자에게 제공되었다면 앱은 서버와 통신해야 할 것이다.  클라이언트는 서버에서 필요한 데이터를 가져와야 하고 클라이언트에서 발생한 상황에 대해 서버로 데이터를 다시 전달해야 한다. 클라이언트와 서버 간 데이터 통신 중 일어날 수 있는 문제점으로는 대표적으로  클라이언트와 서버 간의 데이터 연결이 제한되거나 지연될 수 있다는 점이 있는데, 세부 사항은 다음과 같다.

 

1) 인터넷 연결

- 인터넷 연결이 신뢰할 수 없거나, 안정적이지 않을 수 있다. WIFI가 없는 지역에서는 인터넷에 엑세스할 수 없게 된다. 이 경우, 클라이언트로 서버 측에서 발생하는 데이터 변경 사항이 푸시되지 않는 경우가 발생한다. 이로써 클라이언트에서 서버로의 데이터 수집 지연을 야기할 수 있다.

 

2) 휴대전화 데이터 대역폭

- WIFI를 사용할 경우 서버 측에서 해당 데이터를 수신하기까지 지연이 걸릴 수 있다. 또한 일부 국가의 경우에는 네트워크 인프라가 취약한 점과 같은 문제가 있을 수 있다. 만일 연결 상태가 양호하더라도 기기 성능에 따라 차이가 있을 수 있으며, 이는 앱에 대한 사용자 참여에 영향을 줄 수 있다.

 

3) 배터리

- 데이터 통신이 많을수록 배터리 소모가 증가한다. 또한 배터리 절약 모드가 작동되면 허용되는 앱에 제한이 있을 수 있다.

 

4) CPU, 대기 시간 및 성능

- 저가형 모바일 기기는 CPU성능에 의한 제약을 받게 되므로 앱의 응답성 및 전체적인 성능이 저하될 수 있다.

 

5) 메모리 및 스토리지

- 캐시는 데이터 통신을 줄이는 방법 중 하나이지만, 앱 크기에 영향을 미치므로 앱 삭제에 영향을 줄 수 있다.

 

 통신 대역폭과 기기 성능은 서로 트레이드오프관계에 있다. 더 많은 휴대전화 데이터를 사용하면 안정적인 인터넷이 가능하지만, 더 많은 CPU를 사용할 수 있다. 또한, 기기의 저장 용량을 사용해 WIFI가 추적 데이터를 보낼 때 까지 기다릴 수 있다.

---

3. 실험에 대한 시사점

 

시사점 1. 변경사항을 빠른 시일 내에 예측하고 파라미터화 하라.

 최종 사용자에게 클라이언트 코드를 쉽게 전달할 수 없으므로 모든 클라이언트 측 변경에 대한 종합 대조 실험은 신중히 계획될 필요가 있다. 즉, 모든 실험의 모든 실험군을 사전에 코드화하고 출시할 필요가 있다. 마이크로소프트 오피스는 안전한 배포를 위해 다양한 기능을 월 단위로 출시하는데, 여기에는 다음과 같은 의미가 있다.

 

1) 특정 기능이 완성되기 전에 새로운 앱이 출시될 수 있다.

2) 더 많은 기능이 구축됨에 따라 서버 측에서 더 많은 조작이 가능하다.

3) 세분화된 파라미터화를 통해 클라이언트 배포 없이도 새로운 변수로의 확장이 용이하다.

 

 사용자 경험을 위해서는 모든 앱 사용자들에게 출시 전 새 기능을 테스트하는 것이 좋을 지도 모른다. 하지만 이를 제한하는 앱 스토어도 있으므로, 앱 스토어 정책을 주의 깊게 읽어보는 것이 필요하다.

 

 

시사점 2. 지연된 로깅 및 유효 시작 시간을 예상하라.

 클라이언트와 서버 간의 데이터 통신 제한 또는 지연은 데이터 도착을 지연시킬 뿐만 아니라 실험 자체의 시작 시간도 지연시킨다. 먼저 클라이언트 측의 실험은 새로운 버전의 앱을 제공하면서 시작되고 그 다음에 소수에 대한 실험을 활성화할 수 있는데, 그럼에도 불구하고 다음과 같은 이유로 실험이 완전히 활성화되지 않을 수 있다.

 

1) 기기가 오프라인 상태이거나 제한된 대역폭으로 인한 새로운 실험 구성을 받을 수 없는 경우

2) 사용자가 앱을 열 때만 새 실험 구성을 가져오는 경우

3) 새로운 앱 출시 직후 과거 버전이 설치된 기기가 많은 경우

 

 실험 시작 시간과 데이터가 서버에 도착하는 시간의 지연은 분석이 시간에 민감한 실험 분석에 영향을 줄 수 있다. 따라서, 기간을 연장하는 등 방안이 필요할 수도 있다.

 

 또 다른 시사점은 실험군과 대조군에서 유효 시작 시간이 다를 수 있다는 점이다. 이 경우 선택 편향으로 인한 사용자 집단이 달라질 수 있으며 미리 준비된 집단에 대한 서비스 요청이 후행집단 대비 선행되므로 추가 편향이 발생할 수 있다. 이러한 점을 최소화하기 위하여 실험군과 대조군을 비교할 기간을 신중하게 선택할 필요가 있다.

 

 

시사점 3. 오프라인 또는 앱 시작을 다룰 수 있는 안전장치를 생성하라.

 사용자가 앱을 열 때 기기가 오프라인상태일 수도 있다. 이 경우 일관성을 유지하기 위해서는 실험의 할당 값을 캐시로 남겨 두어 사용자가 오프라인에서 앱을 여는 경우를 대비할 필요가 있다. 또한, 서버가 실험을 할당하는데 필요한 환경구성에 응답하지 않는 경우를 대비하여 실험용 기본 실험군을 준비해야 한다.

 

 

시사점 4. 트리거 분석에 클라이언트 측 실험 할당 추적이 필요할 수 있음에 유의하라.

 클라이언트 측 실험에서 트리거 분석을 유효하게 만드려면 실험이 수행될 때 추적 데이터를 서버에 보내는 것과 같은 추가적인 고려사항이 있을 수 있다. 이 때 실험 할당 정보를 가져온 시점의 추적 데이터를 바탕으로 트리거 분석을 실시하면 과도한 트리거를 유발할 수 있다. 이 문제를 해결하기 위해서는 기능이 실제로 사용될 때 할당 정보를 전송하여, 실험 성능 계측정보가 클라이언트로부터 전송되도록 하는 방법을 사용할 수 있다. 

 

 

시사점 5. 기기 및 앱에 관한 중요한 가드레일 추적

 기기 성능은 앱의 성능에 영향을 줄 수 있다. 그 중 가장 두드러지는 것이 CPU와 배터리이다. 실험군의 사용자에게 더 많은 푸시 알림을 전송한다면  사용자는 배터리 절약을 위해 알림을 비활성화할 수 있다. 이 경우 실험 중에는 참여율 감소 폭이 작으나, 장기적으로는 많은 영향을 미칠 수 있다.

 앱의 전반적인 상태를 추적하는 것도 중요하다. 앱 크기가 크다면 기기 스토리지 가용공간을 확보하기 위해 앱을 제거할 가능성이 높아지므로 앱 크기 역시 추적할 필요가 있다. 앱 내부적으로도 앱 충돌이 발생한다면 정상종료 로그 등을 기록함으로써 다음 앱 시작 시 충돌에 관한 정보를 보낼 수 있다. 

 

 

시사점 6. 준실험 방법을 통해 전체 앱 출시 모니터링

 새로운 앱의 모든 변경 사항이 A/B파라미터로서 고려되는 것은 아니다. 두 가지 버전을 묶고 일부 사용자는 새 버전, 일부 사용자는 이전 버전으로 유지하는 방법은 앱 크기를 두 배로 늘릴 수도 있으므로 이상적인 방법이 아닐 수 있다. 반면 모든 사용자가 동시에 새로운 앱 버전을 채택하는 것은 아니기 때문에 실제 사용자에게 두 버전의 앱 서비스를 제공하는 기간이 있다. 이 경우에는 효과적인 A/B비교를 제공할 수 있다.

 

 

시사점 7. 여러 기기 및 플랫폼, 그리고 이들 간의 상호작용에 주의하라.

 사용자는 데스크탑, 모바일 앱 및 모바일 웹과 같은 여러 기기 및 플랫폼을 통해 동일한 사이트에 액세스 한다. 이것은 다음과 같은 의미를 가질 수 있다.

 

1) 다른 기기에서 다른 ID를 사용할 수 있다. 결과적으로 동일한 사용자가 다른 기기에서 다른 변수로 랜덤화될 수 있다.

2) 서로 다른 기기간 상호작용이 있을 수 있다.

---

4. 결론

-  신 클라이언트와 구 클라이언트를 실험할 때에는 분명한 차이도 있지만 많은 차이들이 불분명하며 중요하다. 따라서 실험을 적절하게 설계하고 분석하려면 각별한 주의를 기울여야 한다. 

 

 

끝.

---

퀴즈

1.  다음 설명 중 옳지 않은 것을 모두 고르시오.

 

1) 변경에 대한 종합 대조 실험은 신중히 계획될 필요가 있기 때문에 모든 실험의 모든 실험군을 사전에 코드화하고 출시할 필요가 있다.

2) 두 가지 버전을 묶고 일부 사용자는 새 버전, 일부 사용자는 이전 버전으로 유지하는 방법은 준실험설계상 이상적인 방법이라고 볼 수 있다.

3) 랜덤화 실험의 예로, 앱 소유자가 일정 비율의 사용자만 사용할 수 있도록 하고 문제가 발생할 경우 일시 중지하는 방법이 있다.

4) 일반적으로 앱 소유자는 가끔씩 업데이트를 하는 방법보다는, 업데이트를 자주 하여 앱 사용성을 향상시키는 편을 선호한다.

5) 클라이언트 측의 실험은 새로운 버전의 앱을 제공하면서 시작되고 그 다음에 소수에 대한 실험을 활성화할 수 있다.

 

 

 

 

 

정답: 드래그하면 보입니다.

2, 3, 4