데이터 주도 프로덕트 개발을 위한 실험 환경 세팅하기

본문은 deepL을 활용해 만든 해외 번역 콘텐츠입니다. 필자인 빅터 세민(Victor Semin)은 UK 핀테크 회사 Revolut의 프로덕트 오너로 일하고 있습니다. 이 글은 데이터 주도적인 프로덕트 개발을 위해 실험 환경을 세팅하는 방법을 이야기합니다.

PO(Product Owner)는 옵션 A를 진행할지, 옵션 B를 진행할지, 또는 더 나은 결과를 얻으려면 어떤 버전의 화면을 구현해야 하는지 고민하는 경우가 많습니다. 특히 제한된 리소스로 촉박한 마감 시한에 쫓기는 경우 이러한 결정을 내리는 것은 어려운 일일 수 있습니다. 게다가 이러한 결정은 개인적인 판단이나 경쟁사의 접근 방식을 모방하여 이루어지기 때문에 최적의 결과를 얻지 못할 수 있습니다.

다행히도 비교적 적은 노력으로 간단한 실험 환경을 세팅하면 이러한 함정을 피할 수 있습니다. 이 글에서는 이를 달성하는 방법을 설명하고자 합니다.

실험 환경 세팅이 중요한 이유

실험 환경 세팅은 두 가지 이유로 중요합니다.

첫째, 새로운 기능을 구현할 때, 데이터 주도적 접근 방식을 기반으로 최적의 옵션을 선택할 수 있습니다.

둘째, '있는 그대로as-is'와 '될to-be' 옵션을 비교하고 '만약에what if' 분석을 수행하여 제품의 기능을 지속적으로 개선할 수 있습니다.

실험 환경 세팅에 대한 흔한 오해

더 설명하기에 앞서, PO를 잘못된 방향으로 이끄는 몇 가지 일반적인 오해를 파헤쳐 보겠습니다.

실험과 A/B 테스트를 수행할 수 있는 복잡한 환경을 마련하려면 많은 리소스가 필요하다.

아닙니다. 설명된 접근 방식은 소프트웨어 엔지니어의 리소스 중 1주일도 채 걸리지 않습니다.

잘 정립된 데이터 수집 프로세스와 상세한 이벤트 추적이 필요하다.

아닙니다. 제품의 주요 요소의 수명 주기에 대한 정보를 저장하는 기존 데이터베이스를 활용할 수 있습니다. 예를 들어, 배달 서비스인 경우 주문 상태와 같은 정보를 활용할 수 있습니다.

매일 요청을 처리할 전담 분석팀이 필요하다.

아닙니다. 실험의 접근 방식과 지표를 이해했다면, 간단한 SQL 쿼리를 사용하여 정기적으로 데이터를 직접 가져올 수 있습니다.

실험 환경 세팅하기 

실험 환경을 세팅하려면, 다음과 같은 단계를 따르는 것이 좋습니다.

1. 향후 실험의 목표를 정의하고, 옵션을 이해하고, 지표를 선택합니다.

제품 디자이너에게 연락하기 전에 실험을 통해 측정할 목표와 지표를 정의해야 합니다. '옵션 A 아니면 옵션 B'처럼 둘 중 하나를 선택하는 일반적인 문제의 경우, 보통 옵션 변경을 통해 달성하고자 하는 것이 간단합니다. 퍼널의 특정한 한 부분만 다루고 있을 수 있으니까요. 

배달 업체에서 일하며 주문 생성폼을 개선하려는 PO가 있다고 가정해보겠습니다. 사용자가 배송지 주소를 입력한 뒤 배송 방법을 선택하는 것으로 넘어가는 비율이 상대적으로 낮은 상황이고요. 이때 주문폼 개선 방식으로 두 가지 버전을 고려하고 있다고 가정해보겠습니다.

• 현재 버전: 주소를 입력하면 주소에 핀으로 표시한 지도가 보이는 화면이 먼저 나오고, 그다음 화면에서 주소를 기반으로 배송 방법을 선택하게 하는 버전.
• 새 버전: 한 화면에서 주소 입력과 배송 방법 선택이 모두 이뤄지는 버전.

둘 중 어떤 옵션이 주소를 입력한 뒤 배송 방법까지 선택하는 사용자의 비율을 높이는지 파악하는 것이 목표입니다. 지표는 매우 간단합니다. 주소를 입력하고 배송 방법을 선택한 사용자의 퍼센티지(%)입니다.

실제로 이러한 데이터를 측정하는 방법에는 두 가지가 있습니다.

1) 백엔드 설계상 이미 사용할 수 있는 데이터를 기반으로 합니다. 예를 들어, 주문의 수명 주기에 대한 정보를 갖고 있는 데이터베이스를 생각해 보겠습니다. 주문에는 다음과 같은 상태(state) 또는 경과(status)가 있을 수 있습니다.

• 주문서 초안 생성됨
• 배송 방법 찾기 시도
• 배송 옵션 발견됨/배송 옵션을 찾을 수 없음

2) 이벤트 추적 : 이는 실행 즉시 작동하는 것이 아니므로 구현하는 데 추가적인 노력이 필요합니다. 하지만 이벤트 추적을 사용하면 디바이스 유형과 브라우저 이름을 이벤트의 매개변수로 전달할 수 있는 등 보다 세분화된 분석이 가능합니다.

이중 첫 번째 접근 방식, 즉 이벤트 추적 없이 기존에 존재하는 데이터 아키텍처를 활용하는 방식을 살펴보도록 하겠습니다.

2. 실험 환경의 아키텍처 설계

실험이 진행되는 과정에서, 아래 두 가지 주요 단계가 완료되어야 합니다.

• 선택한 파라미터로 실험을 생성합니다.
• 사용자가 알맞은 그룹에 할당되고 관련 UI가 표시되도록 하는, 사용자 여정의 단계를 정의합니다.

1) 실험 만들기

가능한 간단해야 하고, 아래 네 가지 매개변수를 활용해 실험을 만들 수 있도록 하는 가벼운 A/B테스트 프레임 워크를 생각해봅시다. 

• 실험 ID
• 최대 샘플
• 각 그룹의 수와 이름
• 각 그룹에 속할 확률

이러한 매개변수를 구성할 수 있으면, 원하는 샘플 크기에 도달할 때까지 무작위로 실험 대상을 선택하고 샘플의 한계를 설정할 수 있습니다.

이를 위해서는 클라이언트와 서버 모두 변경이 필요합니다. 서버는 실험당 참가자 수를 추적해야 하며, 백엔드는 현재 사용자가 실험에 참여해야 하는지 여부를 결정합니다. 백엔드는 현재 샘플 크기와 고정된 확률에 따라, 인증된 사용자를 실험에 참여시켜야 하는지 여부를 결정합니다. 또한 백엔드는 특정 실험에 참여하는 사용자군을 유지하고, 일관된 사용자 경험 제공 및 실험 결과의 올바른 계산을 위해 이를 제공해야 합니다.

아래는 실험 구성을 위한 엔드포인트의 예시입니다.

POST /api/your-service/experiment-create

Request:

{
experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e",
maximum_sample_size: 250, 
groups:
{ 
{ group_name: "old_journey", probability_of_falling_in: 0.5 }, { group_name: "new_journey",
probability_of_falling_in: 0.5 },}

Response:
{
200,
experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"
}
 

2) 사용자를 실험 그룹에 할당할 시기와 방법을 결정합니다

특정 사용자를 실험 및 해당 그룹에 할당하는 일을 담당할 별도의 엔드포인트가 필요합니다. 이를 experiment-enrollments이라고 부르겠습니다.

전체 환경을 설계할 때 사용자 여정의 어느 단계에서 experiment-enrollments 엔드포인트를 호출해야 하는지 명확하게 이해해야 합니다. 또한 모든 사용자가 실험에 참여해야 하는 것은 아닐 수도 있습니다. 그렇기 때문에 엔드포인트에 사용자 인증 토큰을 함께 제공하는 것이 유용할 수 있습니다.

우리가 예시로 든 배달 업체의 주문생성 사례로 살펴보겠습니다. 이때 처음 주문을 하는 신규 사용자에게만 집중하려는 경우, 사용자 인증을 통해 어떤 유형의 사용자인지, 실험에 등록해야 하는지 여부를 확인할 수 있습니다. 또한 엔드포인트가 호출되면, 모든 필수 정보를 사용할 수 있고, 이 정보는 사용자 여정과 라이프사이클의 세부 사항을 고려합니다.

experiment-enrollments 엔드포인트는 아래에 설명되어 있습니다. 특정 유형의 사용자(ex. 아직 주소를 제공하지 않은 신규 사용자만)에 대해 여정의 특정 단계(ex. 배송 주소를 요구하는 화면으로 이동하기 전)에서 호출할 수 있으며, 현재 사용자가 특정 실험에 참여해야 하는지 여부를 계산합니다.

POST /api/your-service/experiment-enrollments, user-auth token is required

Request:

\ {

  experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

Response:

{200,
enrolled: true/false,
group_name: group_1,}

이론적인 데이터 흐름이 어떻게 보이는지 설명하기 위해, 이것 역시 배달 업체의 주문 생성 흐름을 예시로 가정해 살펴보겠습니다. 주문 생성 화면에서 두 가지 옵션 중 하나를 선택합니다.

아래 다이어그램에는 다음과 같은 엔드포인트가 언급되어 있습니다.

• /주문서 초안 생성(step.3)
• /배송 방법 찾기(step.16)
• /주문서 제출(step.20)

위 세 가지는 설명을 위한 예시일 뿐 실험 환경에서 필수적인 부분은 아닙니다.

이 데이터베이스를 잘 보여줄 수 있도록 단순화된 아키텍처를 아래에서 살펴보겠습니다.

이 경우 데이터베이스에는 3개의 주요 테이블이 있습니다(아래 그림 참조).

1. Experiments set: 이전에 만든 모든 실험이 포함되어 있습니다. 데이터베이스는 /experiment-create 엔드포인트를 호출할 때마다 업데이트됩니다.
2. Experiments database: 특정 사용자의 각 등록과 관련된 모든 기록이 포함되어 있습니다. 데이터베이스는 experiment-enrollments 엔드포인트를 호출할 때마다 업데이트됩니다.
3. Order lifecycle database: 실험 관련 데이터를 저장하는 방법을 예시로 보여주기 위한 것입니다. 요점은 이 테이블(또는 제품의 세부 사항에 해당하는 유사한 테이블)을 통해, 자신이 설정한 실험 그룹 중 하나에 등록된 특정 사용자의 참여(예: 주문 생성)가 성공했는지 여부를 확인할 수 있다는 것입니다.

우리의 예제에서는, ‘배송 방법 선택’ 상태를 확인해볼 수 있습니다. 이는 사용자가 배송 세부 정보를 성공적으로 입력한 다음, 제안된 배송 방법 중 하나를 선택했다는 결론을 내릴 수 있도록 하겠죠.

전반적인 접근 방식 개요

장점

• 결과 샘플이 다양합니다.
• 샘플 크기를 미리 알 수 있습니다.
• 고정된 샘플링 확률에 따라 결과를 빠르게 계산할 수 있습니다.

단점

• 프론트엔드와 백엔드를 모두 변경해야 합니다.
• 결과 계산은 여러 데이터베이스에 의존하며, 그 중 일부는 처음에 분석 목적으로 설계되지 않았을 수 있습니다.

태스크와 작업 추정치

• [ ]undefined[Backend] 모델 생성 및 가져오기 카운터 엔드포인트 노출: ~2 스토리포인트
• [ ]undefined[Backend] 증가 카운터 엔드포인트 노출: ~2 스토리포인트
• [ ]undefined[Backend] 가져오기 및 증가 카운터 엔드포인트를 노출합니다: ~1 스토리 포인트
• [ ]undefined[Frontend] 카운터 엔드포인트를 호출하여 가입 흐름 간 전환: ~3 스토리 포인트

백엔드를 설계한 후에는 프론트엔드 팀과 함께 정보를 수신하는 가장 좋은 방법과 정보를 수신할 단계에 대해 논의하세요.

주요 의존성을 염두에 두고 조율하세요.

• 프론트엔드 부분이 백엔드와 병행하여 구현될 수 있도록 사전에 계약서에 따라 팀이 조율되었는지 확인하세요.
• 전체 백엔드가 완료될 때까지 프론트엔드가 차단되지 않도록 하세요.
• 실험 환경과 관계없이 모든 UI 옵션은 어쨌든 구현되어야 합니다.

3. 결과 분석 및 해석

충분한 시간 동안 실험을 실행한 후에는 결과를 분석하고 해석하여 의미 있는 결론을 도출하는 것이 중요합니다. 앞서 집중하기로 결정한 지표에 미치는 영향을 계산하는 데 필요한 필드 목록을 정의합니다.

데이터 원본은 위 데이터테이블 예시 중 두 개입니다.

• Experiments database
  • 입력: 결과를 찾고자 하는 실험 ID
  • 출력: 특정 실험의 참가자인 모든 사용자 ID 목록, 각 사용자가 할당된 그룹 및 사용자가 할당된 타임스탬프

• Order lifecycle database
  • 입력: 실험 범위 내에 있는 사용자 목록 및 사용자가 실험에 등록한 타임스탬프
  • 출력: 해당 사용자와 연관되어 있고 사용자가 실험에 등록한 후 처리된 모든 주문의 최종 상태

이 데이터를 기반으로, 각 실험 그룹에 대해 성공적으로 생성된 주문의 비율을 계산할 수 있습니다.

결과를 분석할 때는 수치만 보지 말고 그 이상의 것을 살펴보는 것이 중요합니다. 또한 테스트 그룹 간에 관찰되는 차이가 단순히 우연에 의한 것이 아닌지 확인하기 위해 통계적 유의성을 찾아야 합니다. 이 주제는 이미 이 글과 다른 온라인 리소스에서 많이 볼 수 있으므로 이 부분에 너무 집중하지는 않겠습니다. 어쨌든 여기에는 엄청난 지식이 필요하지 않습니다. 제 생각에는 두 그룹 간의 차이의 유의성을 확인하기 위해 Z-Test 또는 T-Test를 적용 할 수 있으면 충분할 것입니다.

그럼에도 불구하고 결과가 통계적으로 유의미하다고 판단되면, 어떤 옵션이 더 나은 퍼포먼스를 발휘했는지에 대한 결론을 도출할 수 있습니다.

4. 선호하는 옵션 확장하기

실험을 성공적으로 실행하고 최적의 옵션에 대해 어느 정도 확신을 얻었다면, 다음 단계는 제품 전체에 변경 사항을 확장해 적용하는 것입니다. 여기에는 여러 가지 접근 방식이 있을 수 있습니다.

• 가장 쉬운 방법은 실험의 구성을 조정해 100%의 사용자가 더 나은 결과를 보이는 그룹에 속하도록 하는 것입니다. 이 때는 특정 UI를 표시하는 것이 실험 환경과 무관하도록 향후 코드를 정리할 시간을 확보해야 합니다.
• 제품을 여러 플랫폼에서 사용할 수 있는 경우라면 조금 덜 간단합니다. 웹 플로우에서 실험한 결과가 모바일 앱 플로우에 적용된다고 가정할 때(또는 그 반대의 경우도 마찬가지) 각별히 주의해야 합니다. 때로는 다른 플랫폼에서 비슷한 방식으로 별도의 실험을 하는 것이 안전할 수 있습니다.

결론

자체 실험 환경은 모든 제품 관리자에게 매우 유용한 도구입니다. 현재 제품의 성숙도에 관계없이 실험 환경을 만드는 데 너무 많은 시간이 걸리지 않아야 합니다. 상당히 저렴한 일회성 비용을 들여 실험 환경을 구축하면 성과가 금방 나타납니다.

 마지막으로, 실험 결과가 의미 있는지 확인하기 위한 몇 가지 팁이 있습니다.

• 우선 변경을 고려 중인 사항을 실제로 구현하면 어떤 지표에 영향을 미칠지 파악하세요.
• 실험을 시작하기 전에 목표와 지표를 명확하게 정의하세요.
• 한 번에 한 가지 주요 변경 사항에 집중하여 실험을 최대한 단순하게 유지하세요.
• 다른 플랫폼이나 기타 유사한 서비스에서 실험 결과를 추정할 때는 신중하게 고려하세요.

이러한 모범 사례를 따르면, 데이터 기반 의사 결정을 내리고 전환율을 점점 더 높이는 데 도움이 되는 효과적인 실험 환경을 만들 수 있습니다.

<원문>

How to Set Up an Experiment Environment for Data-Driven Product Development

©️위 번역글의 원 저작권은 Victor Semin에게 있으며, 요즘IT는 해당 글로 수익을 창출하지 않습니다.