회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
본문은 deepL을 활용해 만든 해외 번역 콘텐츠입니다. 필자인 빅터 세민(Victor Semin)은 UK 핀테크 회사 Revolut의 프로덕트 오너로 일하고 있습니다. 이 글은 데이터 주도적인 프로덕트 개발을 위해 실험 환경을 세팅하는 방법을 이야기합니다.
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
본문은 deepL을 활용해 만든 해외 번역 콘텐츠입니다. 필자인 빅터 세민(Victor Semin)은 UK 핀테크 회사 Revolut의 프로덕트 오너로 일하고 있습니다. 이 글은 데이터 주도적인 프로덕트 개발을 위해 실험 환경을 세팅하는 방법을 이야기합니다.
PO(Product Owner)는 옵션 A를 진행할지, 옵션 B를 진행할지, 또는 더 나은 결과를 얻으려면 어떤 버전의 화면을 구현해야 하는지 고민하는 경우가 많습니다. 특히 제한된 리소스로 촉박한 마감 시한에 쫓기는 경우 이러한 결정을 내리는 것은 어려운 일일 수 있습니다. 게다가 이러한 결정은 개인적인 판단이나 경쟁사의 접근 방식을 모방하여 이루어지기 때문에 최적의 결과를 얻지 못할 수 있습니다.
다행히도 비교적 적은 노력으로 간단한 실험 환경을 세팅하면 이러한 함정을 피할 수 있습니다. 이 글에서는 이를 달성하는 방법을 설명하고자 합니다.
실험 환경 세팅은 두 가지 이유로 중요합니다.
첫째, 새로운 기능을 구현할 때, 데이터 주도적 접근 방식을 기반으로 최적의 옵션을 선택할 수 있습니다.
둘째, '있는 그대로as-is'와 '될to-be' 옵션을 비교하고 '만약에what if' 분석을 수행하여 제품의 기능을 지속적으로 개선할 수 있습니다.
더 설명하기에 앞서, PO를 잘못된 방향으로 이끄는 몇 가지 일반적인 오해를 파헤쳐 보겠습니다.
6.2K
실험과 A/B 테스트를 수행할 수 있는 복잡한 환경을 마련하려면 많은 리소스가 필요하다.
아닙니다. 설명된 접근 방식은 소프트웨어 엔지니어의 리소스 중 1주일도 채 걸리지 않습니다.
잘 정립된 데이터 수집 프로세스와 상세한 이벤트 추적이 필요하다.
아닙니다. 제품의 주요 요소의 수명 주기에 대한 정보를 저장하는 기존 데이터베이스를 활용할 수 있습니다. 예를 들어, 배달 서비스인 경우 주문 상태와 같은 정보를 활용할 수 있습니다.
매일 요청을 처리할 전담 분석팀이 필요하다.
아닙니다. 실험의 접근 방식과 지표를 이해했다면, 간단한 SQL 쿼리를 사용하여 정기적으로 데이터를 직접 가져올 수 있습니다.
실험 환경을 세팅하려면, 다음과 같은 단계를 따르는 것이 좋습니다.
제품 디자이너에게 연락하기 전에 실험을 통해 측정할 목표와 지표를 정의해야 합니다. '옵션 A 아니면 옵션 B'처럼 둘 중 하나를 선택하는 일반적인 문제의 경우, 보통 옵션 변경을 통해 달성하고자 하는 것이 간단합니다. 퍼널의 특정한 한 부분만 다루고 있을 수 있으니까요.
배달 업체에서 일하며 주문 생성폼을 개선하려는 PO가 있다고 가정해보겠습니다. 사용자가 배송지 주소를 입력한 뒤 배송 방법을 선택하는 것으로 넘어가는 비율이 상대적으로 낮은 상황이고요. 이때 주문폼 개선 방식으로 두 가지 버전을 고려하고 있다고 가정해보겠습니다.
둘 중 어떤 옵션이 주소를 입력한 뒤 배송 방법까지 선택하는 사용자의 비율을 높이는지 파악하는 것이 목표입니다. 지표는 매우 간단합니다. 주소를 입력하고 배송 방법을 선택한 사용자의 퍼센티지(%)입니다.
실제로 이러한 데이터를 측정하는 방법에는 두 가지가 있습니다.
1) 백엔드 설계상 이미 사용할 수 있는 데이터를 기반으로 합니다. 예를 들어, 주문의 수명 주기에 대한 정보를 갖고 있는 데이터베이스를 생각해 보겠습니다. 주문에는 다음과 같은 상태(state) 또는 경과(status)가 있을 수 있습니다.
2) 이벤트 추적 : 이는 실행 즉시 작동하는 것이 아니므로 구현하는 데 추가적인 노력이 필요합니다. 하지만 이벤트 추적을 사용하면 디바이스 유형과 브라우저 이름을 이벤트의 매개변수로 전달할 수 있는 등 보다 세분화된 분석이 가능합니다.
이중 첫 번째 접근 방식, 즉 이벤트 추적 없이 기존에 존재하는 데이터 아키텍처를 활용하는 방식을 살펴보도록 하겠습니다.
실험이 진행되는 과정에서, 아래 두 가지 주요 단계가 완료되어야 합니다.
1) 실험 만들기
가능한 간단해야 하고, 아래 네 가지 매개변수를 활용해 실험을 만들 수 있도록 하는 가벼운 A/B테스트 프레임 워크를 생각해봅시다.
이러한 매개변수를 구성할 수 있으면, 원하는 샘플 크기에 도달할 때까지 무작위로 실험 대상을 선택하고 샘플의 한계를 설정할 수 있습니다.
이를 위해서는 클라이언트와 서버 모두 변경이 필요합니다. 서버는 실험당 참가자 수를 추적해야 하며, 백엔드는 현재 사용자가 실험에 참여해야 하는지 여부를 결정합니다. 백엔드는 현재 샘플 크기와 고정된 확률에 따라, 인증된 사용자를 실험에 참여시켜야 하는지 여부를 결정합니다. 또한 백엔드는 특정 실험에 참여하는 사용자군을 유지하고, 일관된 사용자 경험 제공 및 실험 결과의 올바른 계산을 위해 이를 제공해야 합니다.
아래는 실험 구성을 위한 엔드포인트의 예시입니다.
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,}이론적인 데이터 흐름이 어떻게 보이는지 설명하기 위해, 이것 역시 배달 업체의 주문 생성 흐름을 예시로 가정해 살펴보겠습니다. 주문 생성 화면에서 두 가지 옵션 중 하나를 선택합니다.
아래 다이어그램에는 다음과 같은 엔드포인트가 언급되어 있습니다.
위 세 가지는 설명을 위한 예시일 뿐 실험 환경에서 필수적인 부분은 아닙니다.
이 데이터베이스를 잘 보여줄 수 있도록 단순화된 아키텍처를 아래에서 살펴보겠습니다.
이 경우 데이터베이스에는 3개의 주요 테이블이 있습니다(아래 그림 참조).
Experiments set: 이전에 만든 모든 실험이 포함되어 있습니다. 데이터베이스는 /experiment-create 엔드포인트를 호출할 때마다 업데이트됩니다.Experiments database: 특정 사용자의 각 등록과 관련된 모든 기록이 포함되어 있습니다. 데이터베이스는 experiment-enrollments 엔드포인트를 호출할 때마다 업데이트됩니다.Order lifecycle database: 실험 관련 데이터를 저장하는 방법을 예시로 보여주기 위한 것입니다. 요점은 이 테이블(또는 제품의 세부 사항에 해당하는 유사한 테이블)을 통해, 자신이 설정한 실험 그룹 중 하나에 등록된 특정 사용자의 참여(예: 주문 생성)가 성공했는지 여부를 확인할 수 있다는 것입니다.
우리의 예제에서는, ‘배송 방법 선택’ 상태를 확인해볼 수 있습니다. 이는 사용자가 배송 세부 정보를 성공적으로 입력한 다음, 제안된 배송 방법 중 하나를 선택했다는 결론을 내릴 수 있도록 하겠죠.
장점
단점
태스크와 작업 추정치
백엔드를 설계한 후에는 프론트엔드 팀과 함께 정보를 수신하는 가장 좋은 방법과 정보를 수신할 단계에 대해 논의하세요.
주요 의존성을 염두에 두고 조율하세요.
충분한 시간 동안 실험을 실행한 후에는 결과를 분석하고 해석하여 의미 있는 결론을 도출하는 것이 중요합니다. 앞서 집중하기로 결정한 지표에 미치는 영향을 계산하는 데 필요한 필드 목록을 정의합니다.
데이터 원본은 위 데이터테이블 예시 중 두 개입니다.
Experiments database
Order lifecycle database
이 데이터를 기반으로, 각 실험 그룹에 대해 성공적으로 생성된 주문의 비율을 계산할 수 있습니다.
결과를 분석할 때는 수치만 보지 말고 그 이상의 것을 살펴보는 것이 중요합니다. 또한 테스트 그룹 간에 관찰되는 차이가 단순히 우연에 의한 것이 아닌지 확인하기 위해 통계적 유의성을 찾아야 합니다. 이 주제는 이미 이 글과 다른 온라인 리소스에서 많이 볼 수 있으므로 이 부분에 너무 집중하지는 않겠습니다. 어쨌든 여기에는 엄청난 지식이 필요하지 않습니다. 제 생각에는 두 그룹 간의 차이의 유의성을 확인하기 위해 Z-Test 또는 T-Test를 적용 할 수 있으면 충분할 것입니다.
그럼에도 불구하고 결과가 통계적으로 유의미하다고 판단되면, 어떤 옵션이 더 나은 퍼포먼스를 발휘했는지에 대한 결론을 도출할 수 있습니다.
실험을 성공적으로 실행하고 최적의 옵션에 대해 어느 정도 확신을 얻었다면, 다음 단계는 제품 전체에 변경 사항을 확장해 적용하는 것입니다. 여기에는 여러 가지 접근 방식이 있을 수 있습니다.
자체 실험 환경은 모든 제품 관리자에게 매우 유용한 도구입니다. 현재 제품의 성숙도에 관계없이 실험 환경을 만드는 데 너무 많은 시간이 걸리지 않아야 합니다. 상당히 저렴한 일회성 비용을 들여 실험 환경을 구축하면 성과가 금방 나타납니다.
마지막으로, 실험 결과가 의미 있는지 확인하기 위한 몇 가지 팁이 있습니다.
이러한 모범 사례를 따르면, 데이터 기반 의사 결정을 내리고 전환율을 점점 더 높이는 데 도움이 되는 효과적인 실험 환경을 만들 수 있습니다.
<원문>
How to Set Up an Experiment Environment for Data-Driven Product Development
위 번역글의 원 저작권은 Victor Semin에게 있으며, 요즘IT는 해당 글로 수익을 창출하지 않습니다.
좋아요
댓글
공유
공유
