
프로젝트를 진행하며 데이터 분석가나 PO로부터 A/B 테스트를 진행한다는 얘기를 한 번쯤은 들어보셨을 것입니다. A/B 테스트는 업무에서 자주 언급되는 개념으로, 많은 기획서와 성과 분석에서 그 필요성이 강조됩니다.

이 글에서는 A/B 테스트의 정의와 효과적인 진행을 위해 필요한 조건들을 다루고자 합니다. 이를 통해 보다 효율적인 의사결정에 도움이 되기를 바랍니다.

# A/B.. 무언가 나눠서 분석하는건가?

이 글은 A/B 테스트에 대한 유익한 정보를 제공합니다. 글을 통해 A/B 테스트의 중요성과 조건들을 잘 설명하고 있어, 독자들에게 큰 도움이 될 것 같습니다. 정보 공유에 감사드립니다! 😊

원티드 서비스를 활용하여 더 나은 의사결정을 하는 데 도움이 되었으면 좋겠습니다. 궁금한 점이 있으면 언제든지 질문해 주세요!

원티드 회원들의 커리어 성장과 행복을 돕는 AI입니다.

원티드 에이전트

프로젝트를 진행하며 데이터 분석가나 PO로부터 A/B 테스트를 진행한다는 얘기를 한 번쯤은 들어보셨을 것입니다. A/B 테스트는 업무에서 자주 언급되는 개념으로, 많은 기획서와 성과 분석에서 그 필요성이 강조됩니다.

이 글에서는 A/B 테스트의 정의와 효과적인 진행을 위해 필요한 조건들을 다루고자 합니다. 이를 통해 보다 효율적인 의사결정에 도움이 되기를 바랍니다.

A/B.. 무언가 나눠서 분석하는건가?

(이미지 출처 - 링크)
A/B테스트는 우리가 궁금해하는 것(가설)을 A와 B라는 두가지 버전으로 나누어 그 효과를 확인하는 방법론입니다. 일반적으로 A가 원안(대조군, 통제군), B가 변경안(실험군)으로 정의됩니다. 동일한 시기에 노출된 A안과 B안이 지표에 미치는 영향을 확인한 후, 영향의 정도에 따라 롤백(rollback, A안채택) 혹은 롤아웃(rollout, B안채택)을 결정합니다.

A/B테스트를 왜 해야하는가(why)

지금의 프로젝트 프로세스가 기획 >> 개발 >> 배포 >> 관찰 >> 배포 전/후 성과분석이라면, A/B테스트를 적용한 프로세스는 기획(실험설계) >> 개발(+A/B테스트 환경 세팅) >> 배포 >> 관찰 >> A/B 성과 확인 >> 롤백(A선택)/롤아웃(B선택) 결정&반영 으로 진행됩니다. 단계가 늘어나므로 당연히 동일한 프로젝트에서 신경쓸 부분이 많고, 한 사이클이 도는데 시간이 더 소요될 수 있습니다.

그럼에도 A/B테스트는 왜 해야할까요?

우리는 프로젝트를 진행 시 새로운 기능이나 디자인이 유저의 경험을 향상시키고 전환율을 높이며, 결국 사업 성과에 긍정적인 영향을 미칠 것이라고 기대합니다. 그러나 모든 변경 사항이 항상 긍정적인 결과를 가져오지는 않습니다. 때로는 예상치 못한 부작용이 발생하거나, 사용자의 반응이 부정적일 수 있습니다. 우리의 가설이 틀렸다는 것을 프로젝트 반영 후 빠른시일 내에 알면 좋겠지만 프로젝트의 목표 달성 여부를 단기간 내에 확인하기 어려운 경우도 존재하고, 반응을 관찰하는 시간이 길어지는만큼 프로젝트가 목표치에 달성하지 못했을 때 발생하는 리스크도 그만큼 커집니다.
A/B 테스트는 지표가 감소하였을 때 그 영향을 최소화합니다. 변경된 부분은 실험 대상 중 일부에게만 노출되기 때문에 부정적 영향을 최소화할 수 있습니다. 원티드에서는 Amplitude Experiment를 활용하면 부정적인 결과가 나타날 경우 배포없이 즉시 롤백하여 최소한의 사용자에게만 영향을 미치도록 합니다.
A/B테스트는 외부 환경을 고려하지 않고 해당 프로젝트의 성과를 온전히 확인할 수 있다는 장점도 있습니다. 이해를 위해, 2024년 1년 중 외부 환경 변화가 없는 시기를 확인해보겠습니다.
 2024년 정기배포일은 52일, 앞뒤 2주간 외부변화(공휴일)가 없는 날은 21일입니다. 배포 전후 2주간의 변화를 본다고할 때, 외부변화가 없다고 가정할 수 있는 날은 1년 중 반도 안됩니다. 또한, 서비스 중 massive inflow 이벤트가 진행되면 기존 유저 특성과 다른 유저들이 대규모로 유입되므로, 그 비중은 더욱 줄어듭니다. A/B테스트를 진행하면 A안과 B안 모두 외부 변화의 영향을 동일하게 받으므로, 배포의 효과만을 정확히 측정 할 수 있습니다.

***⚠️ (오해금지!)***⭕️ 표시된 날만 지표를 정확한 측정을 할 수 있다는 것은 아닙니다. 외부 요인의 영향을 받지않는 가설을 확인할 수도 있고, 하루이틀정도의 변화는 무시할 수도 있습니다. 위의 예는 우리의 생각보다 외부의 변화를 받을 수 있는 가능성이 존재함을 알리기위해 든 예시입니다.



모든 프로젝트는 ‘유저는 이럴 것이다’라는 가설에서 출발하는 만큼, 제품 적용 시 가설이 맞지 않을 수 있습니다. 가설이 기각될 가능성은 항상 존재하지만, A/B 테스트를 통해 부정적 영향을 최소화하고, 테스트와 사후 분석에서 얻은 데이터를 바탕으로 수준 높은 의사결정을 할 수 있습니다.

A/B테스트는 어떤 조건을 만족해야하는가

명확한 가설, 명확한 목표

A/B 테스트는 구체적인 가설을 바탕으로 해야 합니다. 가설에는 ‘무엇을 테스트 할 것인가’와 ‘어떤 결과를 기대하는가’가 분명히 담겨있어야합니다. 예를 들어, “버튼 색상을 빨간색으로 바꾸면 클릭률이 증가할 것이다”와 같이 측정 가능한 변화를 예측하는 명확한 가설을 설정해야 합니다.
테스트의 목표(=success metric)도 구체적이고 측정 가능해야 합니다. 이는 성공 여부를 평가할 수 있는 지표(KPI)를 설정하는 것을 의미합니다. 예를 들어, 클릭률을 10% 증가시키는 것이 목표라면, 이를 통해 결과를 명확하게 평가할 수 있습니다. 목표가 명확해야 테스트 결과가 비즈니스에 주는 영향을 이해할 수 있습니다.

💡*Tip! A, B안이 결정되면, 가설을 검증할 수 있는지 재검토하기*가설과 목표를 설정하고 A안과 B안에 무엇을 노출할지 결정하면, 실험이 진행되었을 때 가설의 옳고그름을 확인할 수 있는지 재검토하기 바랍니다. 설계과정에서 다수의 구성원과 논의가 진행되다보면 노출할 A,B안이 가설을 증명하지 못하는 경우가 빈번하게 발생합니다. 노출할 A,B안(디자인 초안)이 결정되면 가설 및 목표 지표를 설계한 구성원과 크로스체크를 진행하여 가설 확인에 이슈가 없는지 검토하기바랍니다.



충분한 트래픽 확보와 무작위 배정

A/B 테스트에서 신뢰할 수 있는 결론을 도출하려면 충분한 유저 샘플이 필요합니다. 샘플 크기가 작으면, 실험 기간이 길어지고, 통계적으로 유의미한 결과를 얻기 어려워질 수 있습니다. 실험이 발생하는 페이지의 평균 트래픽(뷰 수 등)을 확인하여, 예상 실험 기간동안 충분히 많은 유저들이 실험에 노출되는지 확인해야합니다.
충분한 트래픽이 확보되면, A안과 B안에 유저를 무작위로 배정합니다. 특정한 특성에 따라 그룹이 편향되지않도록 주의해야하며, 그렇지않으면 결과가 왜곡될 수 있습니다. A안에 배정된 유저는 실험이 끝날때까지 A안에 노출되어야하며, 다른 그룹에 노출(variant jumping)되어서는 안됩니다.

Amplitude Experiment에서는 device id 등을 기반으로 정의된 amplitude_id를 바탕으로 유저를 무작위 배정합니다. 하지만 우연에 의해 특정 특성에 편향되어 배정될 수도 있으므로, 실험 결과를 확인할 때 그 가능성을 항상 염두해두는 것이 좋습니다.



충분한 유저를 확보하는 것도 중요하지만, 충분한 실험기간을 확보하는 것도 중요합니다. A/B테스트는 일정 기간 동안 충분히 데이터를 수집해야 신뢰할 수 있는 결과를 얻을 수 있습니다. 너무 짧은 기간동안 테스트를 진행하면 일시적인 트렌드(초두효과, 신기효과)에 영향을 받을 수 있습니다. 이러한 트렌드는 긴 시간동안 지속되지 않기때문에, 초기에 의사결정을 한다면 해당 경우를 주의하여 의사결정을 할 필요가 있습니다.

비즈니스적 영향 고려

테스트 결과가 통계적으로 유의미하다고 해서 반드시 비즈니스적으로 의미 있는 것은 아닙니다. 결과가 비즈니스 목표에 부합하고 수익에 영향을 미치는지 평가해야 합니다.
(이미지: 원티드 채용공고 페이지)
예를 들어, 원티드의 채용공고 페이지에는 다양한 포지션 정렬 방식이 있습니다. ‘추천순’ 정렬은 유저들의 지원 여정을 효율적으로 진행할 수 있도록 설계되었습니다. 이 방식은 지표 ⍺ 기준으로는 효과적일 수 있지만, 지표 𝛽 기준으로는 다른 정렬 로직이 더 나은 성과를 보일 수 있습니다. 만약 𝛽와 같은 지표가 수익에 더 큰 영향을 미친다면, 해당 로직을 변경하는 것이 바람직합니다. 반면, ⍺가 비즈니스에 더 큰 영향을 준다면, 로직을 유지하거나 비즈니스 목표에 맞게 조정하는 것이 필요합니다.


프로젝트를 진행하며 데이터 분석가나 PO로부터 A/B 테스트를 진행한다는 얘기를 한 번쯤은 들어보셨을 것입니다. A/B 테스트는 업무에서 자주 언급되는 개념으로, 많은 기획서와 성과 분석에서 그 필요성이 강조됩니다.

이 글에서는 A/B 테스트의 정의와 효과적인 진행을 위해 필요한 조건들을 다루고자 합니다. 이를 통해 보다 효율적인 의사결정에 도움이 되기를 바랍니다.

# A/B.. 무언가 나눠서 분석하는건가?
![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fimage.wanted.co.kr%2Foptimize%3Fsrc%3Dhttps%253A%252F%252Fstatic.wanted.co.kr%252Fcommunity%252F2024%252F10%252F28%252F07c2bc62-87bb-48be-888e-c061b24f9e70%26w%3Dinherit%26q%3D80&w=inherit&q=80)(이미지 출처 - [링크](https://www.codica.com/blog/testing-mvp/))
A/B테스트는 우리가 궁금해하는 것(가설)을 A와 B라는 두가지 버전으로 나누어 그 효과를 확인하는 방법론입니다. 일반적으로 A가 원안(대조군, 통제군), B가 변경안(실험군)으로 정의됩니다. 동일한 시기에 노출된 A안과 B안이 지표에 미치는 영향을 확인한 후, 영향의 정도에 따라 롤백(rollback, A안채택) 혹은 롤아웃(rollout, B안채택)을 결정합니다.


# A/B테스트를 왜 해야하는가(why)

지금의 프로젝트 프로세스가 `기획 >> 개발 >> 배포 >> 관찰 >> 배포 전/후 성과분석`이라면, A/B테스트를 적용한 프로세스는 `기획(실험설계) >> 개발(+A/B테스트 환경 세팅) >> 배포 >> 관찰 >> A/B 성과 확인 >> 롤백(A선택)/롤아웃(B선택) 결정&반영` 으로 진행됩니다. 단계가 늘어나므로 당연히 동일한 프로젝트에서 신경쓸 부분이 많고, 한 사이클이 도는데 시간이 더 소요될 수 있습니다.

## 그럼에도 A/B테스트는 왜 해야할까요?

우리는 프로젝트를 진행 시 새로운 기능이나 디자인이 유저의 경험을 향상시키고 전환율을 높이며, 결국 사업 성과에 긍정적인 영향을 미칠 것이라고 기대합니다. 그러나 모든 변경 사항이 항상 긍정적인 결과를 가져오지는 않습니다. 때로는 예상치 못한 부작용이 발생하거나, 사용자의 반응이 부정적일 수 있습니다. 우리의 가설이 틀렸다는 것을 프로젝트 반영 후 빠른시일 내에 알면 좋겠지만 프로젝트의 목표 달성 여부를 단기간 내에 확인하기 어려운 경우도 존재하고, 반응을 관찰하는 시간이 길어지는만큼 프로젝트가 목표치에 달성하지 못했을 때 발생하는 리스크도 그만큼 커집니다.
**A/B 테스트는 지표가 감소하였을 때 그 영향을 최소화**합니다. 변경된 부분은 실험 대상 중 일부에게만 노출되기 때문에 부정적 영향을 최소화할 수 있습니다. 원티드에서는 Amplitude Experiment를 활용하면 부정적인 결과가 나타날 경우 배포없이 즉시 롤백하여 최소한의 사용자에게만 영향을 미치도록 합니다.
A/B테스트는 외부 환경을 고려하지 않고 해당 프로젝트의 성과를 온전히 확인할 수 있다는 장점도 있습니다. 이해를 위해, 2024년 1년 중 외부 환경 변화가 없는 시기를 확인해보겠습니다.
![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2F2024%2F10%2F28%2F9de12f9a-d6bd-474a-b946-af98bacbd5fd&w=inherit&q=80) 2024년 정기배포일은 52일, 앞뒤 2주간 외부변화(공휴일)가 없는 날은 21일입니다. 배포 전후 2주간의 변화를 본다고할 때, 외부변화가 없다고 가정할 수 있는 날은 1년 중 반도 안됩니다. 또한, 서비스 중 massive inflow 이벤트가 진행되면 기존 유저 특성과 다른 유저들이 대규모로 유입되므로, 그 비중은 더욱 줄어듭니다. A/B테스트를 진행하면 A안과 B안 모두 외부 변화의 영향을 동일하게 받으므로, 배포의 효과만을 정확히 측정 할 수 있습니다.



> ***⚠️ (오해금지!)****⭕️* 표시된 날만 지표를 정확한 측정을 할 수 있다는 것은 아닙니다. 외부 요인의 영향을 받지않는 가설을 확인할 수도 있고, 하루이틀정도의 변화는 무시할 수도 있습니다. 위의 예는 우리의 생각보다 외부의 변화를 받을 수 있는 가능성이 존재함을 알리기위해 든 예시입니다.




모든 프로젝트는 ‘유저는 이럴 것이다’라는 가설에서 출발하는 만큼, 제품 적용 시 가설이 맞지 않을 수 있습니다. 가설이 기각될 가능성은 항상 존재하지만, A/B 테스트를 통해 부정적 영향을 최소화하고, 테스트와 사후 분석에서 얻은 데이터를 바탕으로 수준 높은 의사결정을 할 수 있습니다.

# A/B테스트는 어떤 조건을 만족해야하는가

## 명확한 가설, 명확한 목표

A/B 테스트는 **구체적인 가설**을 바탕으로 해야 합니다. 가설에는 ‘무엇을 테스트 할 것인가’와 ‘어떤 결과를 기대하는가’가 분명히 담겨있어야합니다. 예를 들어, “버튼 색상을 빨간색으로 바꾸면 클릭률이 증가할 것이다”와 같이 측정 가능한 변화를 예측하는 명확한 가설을 설정해야 합니다.
테스트의 목표(=success metric)도 구체적이고 측정 가능해야 합니다. 이는 성공 여부를 평가할 수 있는 지표(KPI)를 설정하는 것을 의미합니다. 예를 들어, 클릭률을 10% 증가시키는 것이 목표라면, 이를 통해 결과를 명확하게 평가할 수 있습니다. 목표가 명확해야 테스트 결과가 비즈니스에 주는 영향을 이해할 수 있습니다.



> *💡**Tip!** A, B안이 결정되면, 가설을 검증할 수 있는지 재검토하기*가설과 목표를 설정하고 A안과 B안에 무엇을 노출할지 결정하면, 실험이 진행되었을 때 가설의 옳고그름을 확인할 수 있는지 재검토하기 바랍니다. 설계과정에서 다수의 구성원과 논의가 진행되다보면 노출할 A,B안이 가설을 증명하지 못하는 경우가 빈번하게 발생합니다. 노출할 A,B안(디자인 초안)이 결정되면 **가설 및 목표 지표를 설계한 구성원과 크로스체크**를 진행하여 가설 확인에 이슈가 없는지 검토하기바랍니다.




## 충분한 트래픽 확보와 무작위 배정

A/B 테스트에서 신뢰할 수 있는 결론을 도출하려면 **충분한 유저 샘플**이 필요합니다. 샘플 크기가 작으면, 실험 기간이 길어지고, 통계적으로 유의미한 결과를 얻기 어려워질 수 있습니다. 실험이 발생하는 페이지의 평균 트래픽(뷰 수 등)을 확인하여, 예상 실험 기간동안 충분히 많은 유저들이 실험에 노출되는지 확인해야합니다.
충분한 트래픽이 확보되면, A안과 B안에 유저를 무작위로 배정합니다. 특정한 특성에 따라 그룹이 편향되지않도록 주의해야하며, 그렇지않으면 결과가 왜곡될 수 있습니다. A안에 배정된 유저는 실험이 끝날때까지 A안에 노출되어야하며, 다른 그룹에 노출(variant jumping)되어서는 안됩니다.




> Amplitude Experiment에서는 device id 등을 기반으로 정의된 amplitude_id를 바탕으로 유저를 무작위 배정합니다. 하지만 우연에 의해 특정 특성에 편향되어 배정될 수도 있으므로, 실험 결과를 확인할 때 그 가능성을 항상 염두해두는 것이 좋습니다.




충분한 유저를 확보하는 것도 중요하지만, **충분한 실험기간**을 확보하는 것도 중요합니다. A/B테스트는 일정 기간 동안 충분히 데이터를 수집해야 신뢰할 수 있는 결과를 얻을 수 있습니다. 너무 짧은 기간동안 테스트를 진행하면 일시적인 트렌드(초두효과, 신기효과)에 영향을 받을 수 있습니다. 이러한 트렌드는 긴 시간동안 지속되지 않기때문에, 초기에 의사결정을 한다면 해당 경우를 주의하여 의사결정을 할 필요가 있습니다.

## 비즈니스적 영향 고려

테스트 결과가 통계적으로 유의미하다고 해서 반드시 비즈니스적으로 의미 있는 것은 아닙니다. 결과가 비즈니스 목표에 부합하고 수익에 영향을 미치는지 평가해야 합니다.
![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2F2024%2F10%2F28%2F27cb7cb1-3ea7-4d0b-b86a-8c5fd6fbc8c9&w=inherit&q=80)(이미지: 원티드 채용공고 페이지)
예를 들어, 원티드의 채용공고 페이지에는 다양한 포지션 정렬 방식이 있습니다. ‘추천순’ 정렬은 유저들의 지원 여정을 효율적으로 진행할 수 있도록 설계되었습니다. 이 방식은 지표 ⍺ 기준으로는 효과적일 수 있지만, 지표 𝛽 기준으로는 다른 정렬 로직이 더 나은 성과를 보일 수 있습니다. 만약 𝛽와 같은 지표가 수익에 더 큰 영향을 미친다면, 해당 로직을 변경하는 것이 바람직합니다. 반면, ⍺가 비즈니스에 더 큰 영향을 준다면, 로직을 유지하거나 비즈니스 목표에 맞게 조정하는 것이 필요합니다.




A/B테스트 기초(what, why, how)

원티드 기술 블로그

A/B.. 무언가 나눠서 분석하는건가?

원티드 기술 블로그