[A/B 테스트] 05. 속도의 중요성: 엔드-투-엔드 사례 연구

책 <A/B 테스트(론 코하비.다이앤 탕.야 쉬 지음)>의 05장을 요약정리한 내용입니다. 

---

 

속도의 중요성

속도의 중요성을 평가하기 위해 실험의 설계, 실행, 해석까지의 엔드-투-엔드 예시를 우선 살펴보겠습니다.

예시로 들기에 간단하기 때문에 실험의 많은 예시로, 사용자 인터페이스(UI)에 초점을 맞추지만,

많은 기업에서 발견한 것처럼 백엔드 측면에서도 많은 혁신이 일어나며, 속도가 매우 중요하다는 것이 밝혀졌습니다.

물론 속도가 더 빠를수록 좋지만, 노력의 투자수익률(ROI)을 단순한 속도 저하 실험 실행을 통해 계량화할 수 있어야 합니다.

 

종합 대조 실험의 단순하지만 강력한 기법인 속도 저하 실험 (sorcom erparmen)을 통해 아래와 같은 질문에 대한 명확한 답을 얻을 수 있습니다. 

• 제품 성능이 얼마나 중요한가?
• 제품의 어느 곳에서 지연 시간을 줄이는 것 이 중요한가?

제품 속도를 늦추면 매출 및 사용자 만족도 지표의 하락을 포함한 주요 지표에 대한 지연 시간 증가의 영향을 평가할 수 있습니다. 검증할 수 있는 가벼운 가정 하에서, 성능의 개선 -> 즉 지연 시간의 감소가 이러한 지표(매출과 만족도)를 높일 수 있다는 것을 보여줄 수 있다.

 

아마존에서 실행한 100밀리 초 속도 저하 실험은 매출을 1% 감소시켰으며,

빙과 구글의 공동 강연(Schurman, Brutlag 2009)에서 성능이 검색어 수, 수익, 클릭, 만족도, 클릭 시간 등

주요 지표에 큰 영향을 미친다는 것을 보여줬습니다.

빙에서의 2012년 상세한 연구(Kohavi et al. 2013)는 100 msec 가속마다 매출이 0.6% 향상되는 것으로 나타났습니다.

 

비록 많은 결과가 중합 대조 실험에서 나온 것은 아니어서, 결과가 성능 이외의 변화와 혼동되기는 하지만,

성능 항상이 컨버전과 사용자 참여를 증가시킨다는 많은 결과를 "왜 성능이 중요한가"에서 공유하고 있습니다.

 

---

 

개인화 또는 최적화를 위해 제 3자의 제품을 사용할 것인가

최적화를 위해 제 3자의 제품을 사용하는 경우 중  일부는 HTML페이지 상단에 자바스크립트 코드를 삽입해야 합니다.

이들은 코드 제공자와 상호작용해야 하고, 일반적으로 수십 킬로바이트인 자바스크립트를 전송하기 위해 다른 코드를 차단해야 하므로, 페이지 속도가 매우 느려집니다. 코드를 페이지 아래쪽에 놓으면 페이지가 점멸(easthing)하게 됩니다. 

 

지연 시간 실험 결과를 바탕으로 유추했을 때 목표 지표의 증가는 지연 시간 증가 비용으로 상쇄될 수 있다.

따라서 가능하면 서버 측 개인화 및 최적화를 사용할 것을 권장합니다.

즉, 서버 측에서 변형군 할당을 구현하고 이 변형군용 HTML 코드를 생성하도록 합니다.

 

이러한 유형의 실험을 실행함으로써 얻을 수 있는 또 다른 이점은 성능의 차이로부터

주요 지표의 차이의 영향을 함수화 해서 추정함으로써 "성능 개선이 당장 매출에 미치는 영향은? 성능 개선으로 인한 장기적 영향(해지 고객이 줄어드는 것과 같은 것)이 있는가?"같은 질문에 답할 수 있게 된다는 것이다.

---

종합 대조 실험을 수행하기 위해 지연 시간을 변화된 유일한 요인으로 하고, 지연 시간의 영향을 다른 요인들의 영향과 분리하고 싶을 것입니다.

성능을 향상시키는 것은 매우 어려운 일이기에 우리는 웹사이트나 제품의 속도를 저하시키는 간단한 기법에 의존해 실험을 진행하도록 하겠습니다. 실험군을 대조군에 비해 느리게 함으로써 간단하게 임의의 지표에 대한 영향을 측정할 수 있다. 하지만 이 경우 몇 가지 가정을 수립할 필요가 있다.

 

중요 가정: 국지적 선형 근사

속도 저하 실험의 주요 가정은 (매출과 같은) 지표 대 성능의 그래프가 

현시점의 성능값을 중심으로 하는 직선으로 잘 근사된다는 것이다. 이것은 1차 테일러 시리즈 근사 (= 즉 선형 근사)이다.

 

그림은 시간(성능)과 관심 지표(ex. 클릭률(CTR) 또는 사용자당 매출) 간의 관계를 나타낸 그래프이다.

일반적으로 사이트 속도가 빠를수록 지표값(이 예시에서는 더 높음)이 좋다.

실험 조건의 속도를 늦추면 수직선이 그래프와 교차하는 지점에서 오른쪽으로 이동하며, 측정지표의 변화를 측정할 수 있다.

 

우리의 가정) 직선의 왼쪽으로 움직인다면(성능이 향상되는 경우), 이때의 지표의 변화량은 우리가 오른쪽으로 움직였을 때 측정하는 변화량과 거의 같을 것이다

 

1. 사용자로서의 경험으로 볼 때 검색 시 빠른 속도가 더 좋다. 특히 현시점의 성능 포인트 주변에서 그래프의 불연속성이나 극적인 변화가 있기는 힘들다. 만약 우리가 3초 늦춘 다면, 사람들은 눈에 띄는 절벽이 있다고 상상할 수 있지만, 10분의 1초를 더하거나 빼면, 이것이 일어날 가능성이 적다.
2. 그래프를 두 점에서 샘플링해 선형 근사치가 타당한지 확인할 수 있다. 특히 빙은 100밀리 초와 250밀리 초의 속도로 속도 저하 실험을 진행했다. 몇 개의 주요 지표에서 250밀리 초 실험의 변화량은 100밀리 초 실험의 약 2.5배이므로 이는 선형성의 가정을 지지한다.

 

---

 

웹사이트 성능을 측정하는 법

웹사이트 성능을 측정하는 것은 자명하지 않습니다.

리퀘스트가 상이한 서버들에 의해 처리되기 때문에, 지연 시간을 신뢰성 있게 측정하기 위해 서버는 동기화돼야 합니다.

서버 간에 시계가 동기화되지 않는다면 데이터 품질에 문제를 일으키게 됩니다. (ex. 음의 기간 같은 불가능한 데이터)

그렇기에 서버의 시계를 자주 동기화하는 것은 매우 중요합니다.

 

우리의 예제에서는 클라이언트와 서버의 시간이 분리됩니다. 왜냐하면 이들은 다른 시간대에 있을 가능성이 크기 때문입니다. 또한 클라이언트 시계는 대체로 신뢰성이 떨어져 때로는 몇 년 동안 작동하지 않은 경우(ex. 배터리가 방전된 경우)도 있기 때문입니다.

 

아래 그림은 검색 엔진과 같은 고도로 최적화된 웹사이트에 대한 리퀘스트를 나타낸다. 단계는 다음과 같다.

 

사용자가 경험하는 페이지 로드 시간 P은 T6-T0이지만, T7-T1을 측정해 근사한다. 

서버에 도달하는 데 초기 리퀘스트가 걸리는 시간은 온로드 이벤트 비콘이 서버에 도달하는 데 걸리는 시간과

매우 유사할 가능성이 높기 때문에 (둘 다 작은 요청인 경우)

이 두 델타들은 아마도 매우 유사할 것이며 사용자 경험 시간을 대략적으로 알 수 있게 해 준다.

 

---

속도 저하 실험 설계

속도 저하 실험은 간단한 실험으로 보일 수도 있지만, 매우 복잡하다. 

속도 저하(slowdown)를 어디에 삽입하느냐를 고민해야 한다.

빙은 처음에는 청크 1의 전송을 늦췄지만(그림 5.2 참조) 영향이 너무 컸고, 다음과 같은 이유로 불합리하다고 판단됐다.

 

1. 청크 1은 계산할 것이 없기 때문에 서버에서 빠르게 전송된다. 그러므로 청크 1의 지연 시간을 개선할 수 있다고 말하는 것은 비합리적이다.
2. 청크 1은 사용자에게 페이지 크롬이나 프레임을 색칠을 해 리퀘스트가 제대로 수신됐다는 피드백을 제공한다. 이것의 지연은 전체 사이트 성능과 이것의 지연은 여러 가지 부 정적인 영향을 미친다.

지연에 적합한 장소는 서버가 URL-의존적 HITML인 청크 2의 계산을 끝낼 때이다. 서버가 HTML을 보내는 대신 HTML의 쿼리 의존적인 부분을 생성하는 데 시간이 더 걸린 것처럼 서버로부터의 응답을 지연시킨다.

실험을 설계할 때 아래와 같은 세 가지 질문이 존재하였다.

 

지연 시간은 얼마나 돼야 하는가

우리가 계산하는 모든 지표에는 신뢰구간이 있습니다. 신뢰구간인 "기울기"를 더 정확하게 추정할 수 있게 하기 위해서는 실험 효과가 클 필요가 있습니다. 만약 둘 다 유사한 신뢰구간 크기를 갖고 있다면, 250밀리 초로 측정하는 것이 훨씬 더 좁은 범위의 기울기를 제공합니다. 이는 지연 시간을 더 크게 할 것을 요구합니다. 

지연 시간이 길다는 것은 1차, 테일러급수 근사치가 덜 정확할 수 있다는 것을 의미합니다. 이는 더 짧은 지연을 요구합니다. 

 

 지리적 네트워크의 차이를 감안하기 위해 지연을 일정하게 할지, 또는 일정 비율로 할 것인가

(ex. 남아프리카의 빙 사용자들은 페이지로드 시간이 매우 느려서 250밀리 초 지연이 별로 느껴지지 않을 수도 있다.)

백엔드 서버 측 지연을 모델링하는 실험에서는, 일정한 지연이 좋은 선택일 것이다.

네트워크 차이에 관련해 어떤 일이 일어나는가를 모델링하려면, 예를 들어 실험은 지연 시간 대신 페이로드의 크기를 기반으로 할 수 있다.

 

 세션의 처음 페이지 또는 세션 후반부의 페이지 어느 쪽에서의 속도 향상이 더 중요한가

일부 속도 향상 기법(ex. 자바스크립트의 캐싱)은 세션 후반부 페이지의 성능을 향상시킬 수 있다.
위의 요인을 감안할 때 빙에서의 100밀리 초와 250밀리 초의 속도 저하는 합리적인 선택이라고 결정됐다.

 

---

상이한 페이지 구성 요소의 영향이 다르다

페이지 영역마다 성능이 다르다. 

빙의 알고리즘 검색 결과를 보여주는 속도는 매우 중요했고, 속도 저하는 매출과 사용자 지표와 같은 주요 지표에 중 요한 영향을 미쳤다.
페이지의 다른 영역은 어떠했을까? 그들이 훨씬 덜 중요하다는 것이 밝혀졌다. 빙에서는 오른쪽 화면의 일부 요소가 늦게 로딩되고 있었다. (기술적으로 말하자면 window.onload 함수 이벤트 후를 뜻함. 여기서 window.onload 함수란 웹 페이지의 로드가 끝나는 시점에 실행되는 함수다.)

 

위에서 설명한 것과 같이 오른쪽 화면의 요소가 표시되는 시간을 250밀리초 지연시키는 속도 저하 실험을 실행했다.
실험에 거의 2천만 명의 사용자가 있었음에도 불구하고 주요 지표에 대해 통계적으로 유의한 영향은 감지되지 않았다.

 

감지되지 않은 이유는 PLT(페이지 로드 시간)를 측정하기 위해 앞에서 설명한 시퀀스 대신 유용한 브라우저 활동의 종료를 표시하는 window.onload를 사용하는 경우가 많은데, 그러나 이 척도는 현대의 웹 페이지에 대해 심각한 결함을 갖고 있다.

 

이 결함의 원인은 인지된 성능의 개념의 추상적이고 모호하기 때문이라 판단된다. "인지된 성능"이라는 용어는 사용자가 페이지를 충분히 볼 수 있을 때 이를 해석하기 시작한다는 직관적인 아이디어를 나타내는 경우가 많다. 인지된 성능의 개념은 추상적으로 말하기는 쉽지만 실제로 측정하지는 어려우며 perception.ready()는 어떤 브라우저의 로드맵에도 존재하지 않는다. 인지된 성능을 추정하기 위해 다음과 같은 여러 제안이 개발됐다.

• 첫 번째 결과까지의 시간. 트위터와 같이 리스트가 표시되면 첫 번째 트윗이 보일 때가 지의 시간이 지표가 될 수 있다.
• 기본 화면 표시 시간(AFT, Albove the Fold Tirme). 브라우저의 초기영역(기본 화면)의 픽셀이 모두 칠해질 때까지의 시간으로 측정할 수 있다. 기타 동적 컨텐츠를 처리하기 위해 휴리스틱한 구현을 사용한다. 페인트 된 픽셀의 비율에 대한 임계값을 설정해 그다지 중요하지 않은 작은 픽셀들 때문에 시간이 필요 이상으로 길게 측정되지 않도록 한다.
• 속도지수(Speed Index). 이것은 AFT(Meenan 2012)의 일반화한 것으로서. 페이지상에 보이는 요소가 표시되는 시간을 평균 낸 것이다. 이는 덜 중요한 요소가 늦게 보이는 경우의 문제를 피할 수 있지만, 여전히 초기 기본 화면을 변경하는 동적인 콘텐츠에 시달린다.
• 페이지 단계 시간(Page Phase Time) 및 사용자 준비 시간. 페이지 단계 시간은 인지된 성능을 만족하는 렌더링 단계를 식별할 필요가 있으며, 단계는 픽셀 변화 속도에 의해 결정된다.

인지된 성능의 복잡한 정의에 대한 설명을 피하는 한 가지 방법은 클릭과 같은 사용자 행까지의 시간을 측정하는 것이다. 이 기법은 사용자가 예상하는 행동이 있을 때 잘 작동한다는 특징이 있다.

클릭까지의 시간보다 더 정교한 변형은 성공한 클릭까지의 시간이다. 

여기서 성공은 사용자가 30초 동안 다시 돌아오지 않는 클릭으로 정의될 수 있다. 따라서 "미끼" 클릭을 피할 수 있다. 

이러한 지표는 많은 성능 지표에 필요하다고 하는 휴리스틱의 영향을 받지 않고, 많은 변경에 민감하지 않다.

이러한 지표의 주요 문제는 동작이 예상될 때만 작동한다는 것이다. 

 

---

극단적 결과

속도가 매우 중요한 반면, 또한 우리가 속도의 영향력을 과대평가하고 있다고 믿는 몇몇 결과들을 보았다.

 

그 당시 구글에 있었던 마리사 메이어는 웹 2.0 강연에서, SERP의 검색 결과 수를 10개에 서 30개로 늘리는 실험을 기술했다(uinden 2006). 그는 실험 그룹의 구글 검색자로부터의 트레픽과 매출이 20% 감소했다고 주장했다. 이 원인을  0.5초 더 경기 때문이라고 본 것이다. 성능은 주요한 요인이긴 하지만 여러 요인이 바뀌었고, 성능은 손실의 적은 비율만을 차지하는 것으로 의심된다.

 

반대로 당시 Etsy에서 Dan Mckintoy(2013)는 200밀리 초의 지연은 전혀 문제가 되지 않는다고 주장했다. Etsy사용자의 경우 성능이 중요하지 않을 수 있지만, 우리는 보다 가능성이 높은 가설은 실험이 차이를 탐지하기에 충분한 통계적 검정력을 갖고 있지 않았다는 것이라 믿는다.

 

마지막으로, 매우 드문 시나리오이지만 속도가 너무 빠르면 어떤 활동이 실제로 수행됐는지 사용자가 의심할 수 있어서 일부 제품에는 가짜 진행 막대 progress bar가 추가되기도 한다.

 

실험 결과를 검토할 때 어떤 신뢰 수준을 적용해야 하는지 데이터 분석을 하는 스스로에게 물어보고,

특정 사이트에 대해 아이디어가 작용했더라도 다른 사이트에서는 잘 작동하지 않을 수 있다는 점을 데이터 분석가는 기억해야 한다. 한 가지 할 수 있는 일은 과거 실험의 재현(성장 여부)을 보고하는 것이다.

 

 

---

 

 

 

 

 

퀴즈 1. 계산할 것이 있는 청크 1과 계산할 것이 없는 청크 2  이 두가지 중 지연에 적합한 장소는 청크 2이다. (Y / N)

 

퀴즈 2. 특정 사이트에 대해 아이디어가 작용했더라도 다른 사이트에서는 잘 작동할 것이다.

(Y / N)