12. 클라이언트 측 실험

 

용어

• Thin Client : 웹 브라우져와 같은 클라이언트
• Thick Client : 모바일 앱이나 데스크탑 앱과 같은 클라이언트

이 챕터에서는 Thick 클라이언트에서 실행하는 실험에 대해서 Thin 클라이언트에서의 실험과의 차이점과 시사점에 대해서 설명한다.
아래에서 설명하는 많은 차이들이 불분명하면서도 중요하기때문에, 주의를 기울여야 한다.

 

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

차이 #1 : 출시 프로세스

• 웹사이트와 같은 Thin 클라이언트에서는 지속적인 통합 및 배포와 같은 서버 측 코드 업데이트가 비교적 쉽다.
• 클라이언트 앱의 경우는 많은 기능이 서버측 코드의 영향을 받는다. 그리고 상당히 많은 양의 코드가 클라이언트에 있으며 변경사항은 다르게 배포되야 한다. (모바일 앱에서는 배포와 출시 주기를 완전히 제어할 수 없다)
  • 코드가 완료되면, 앱 소유자는 검토를 위해서 빌드파일을 앱 스토어에 제출
  • 출시로 인해 모든 앱 방문자가 새 버젼을 사용하게 되는 것은 아니다.
  • 이는 특정 시점에 앱 소유자가 지원해야하는 여러 버젼의 앱이 있음을 의미한다.
  • 구글 플레이와 앱스토어 모두 단계적 출시를 지원, 문제 시에 일시 중지할 수 있음

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

• 클라이언트는 서버와 통신을 통해서 상태를 가져오거나, 상태를 서버에 업데이트해야한다.
• 통신과 관련된 주요 요인
  • 인터넷 연결 : 인터넷 연결이 신뢰할 수 없거나, 상황에 따라 오랜 기간 off-line 상태일 수 있음.
  • 휴대전화 데이터 대역폭 : 국가에 따라 인프라 비용등의 측면에서 대역폭이 다를 수 있으며, wifi 에서만 데이터 전송이 설정되었을 수 도 있음.
  • 배터리 : 통신이 많을 수록 데이터 소모가 증가하며, 이로 이한 배터리 절약모드가 앱에 제한을 줄 수 있다.
  • CPU, 메모리 및 스토레이지 : 많은 저가형 모바일 장치가 아직 많이 있으며, 앱의 사이즈 증가는 삭제를 유발할 수도 있다.

 

실험에 대한 시사점

차이 #1 : 변경사항을 빠른 시일 내에 예측하고 파라메터화 하라

• 최종 사용자에게 배포가 쉬운 부분은 아니기 때문에, 클라이언트측 변경은 신중히 계획되어야 한다.
  • 특정기능이 완성되기 전에 새로운 앱이 출시될 수 있음.
    • feature flag를 통해서 제어할 수 있고, 기능이 꺼진 기능을 dark features 라고 함
  • 더 많은 기능 구축을 서버측에서 조작할 수 있다.
  • 세분화된 파라메터화를 통해서 클라이언트 배포 없이도 새로운 변수로의 확장이 용이하다.
    • 최근 soomgo의 카테고리 변경 실험도 backend에서 멀티 구조를 가져갈 수 있는 구조였다면, 많은 시행착오를 줄일 수 있지 않을까 생각.

차이 #2 : 지연된 로깅 및 유효 시작 시을 예상하라

• 오프라인 상태이거나 제한된 대역폭 상태로 인해 기기가 새로운 실험 구성을 받지 못할 수 있다.
• 사용자가 앱을 열때만 새 실험 구성을 가져오는 경우, 새로운 세션까지 시간이 오래 걸릴 수 있다.
• 새로운 출시 앱이 특정한 기준에 점유되는 데에 시간이 걸릴 수 있다.
• 이런 요소들은 시간에 민감한 실험에 영향을 충분히 줄 수 있다.

차이 #3 : 오프라인 또는 앱 시작을 다룰 수 있는 안전장치를 생성하라

• 일관성을 유지하기 위해서 실험의 할당 값을 캐시로 남겨두어 오프라인에서 앱을 여는 경우를 대비할 필요가 있다.

차이 #4 : 트리거 분석에 클라이언트 측 실험 할당 추척이 필요할 수 있음

• 클라이언트에서 서버로의 통신을 줄이기 위해 실험할당 정보는 실험의 트리거 여부와 관계없이 일반적으로 모든 활성실험에 대해서 한번에 가져온다.
• 위의 시점에 추적 데이터를 바탕으로 트리거분석을 실시하면 과도한 부하가 발생할 수 있으며, 이를 해결하려면, 기능이 실제로 사용될 때 계측정보를 서버로 전동하는 것이다.

차이 #5 : 기기 및 앱에 관한 중요한 가드레일 추적

• 어떤 실험은 더 많은 CPU를 소비하고 많은 배터리를 소모할 수 있다. 사용자 참여 데이터만 추적하면 베터리 소모 문제를 발견하지 못할 수도 있다.
• 많은 push는 알림 비활성화를 높일 수 있다.
• 앱의 사이즈도 앱의 제거에 영향을 줄 수 있다.

차이 #6 : 준실험 방법을 통해 전체 앱 출시 모니터링

• 전체적으로 새로운 앱에서 무작위로 종합대조실험을 하려면, 두 버젼을 동일한 앱에 묶어서 배포해야한다.
• 이는 앱 크기를 두배로 늘릴 수 있으므로 실용적이거나 이상적이지는 않지만, 효과적으로 A/B 비교를 제공한다.

차이 #7 : 여러 기기/플랫폼 및 이들 간의 상호작용에 주의하라

• 같은 사용자가 다른 기기에서 다른 ID로 인한 다른 경험을 할 수 있다. (숨고도 마찬가지)
• 서로 다른 기기간에 상호작용이 있을 수 있다.
  • 웹에서 앱으로의 사용성 연결이나 그 반대의 경우.
  • 주의해야할 사항은 한 플랫폼에서의 경험이 다른 플랫폼에서보다 나을 수 있다. 즉 효과 교란을 가져올 수 있다.