Part 1. 03~04

론 코하비, 다이앤 탕, 야 쉬, 『A/B 테스트 신뢰할 수 있는 온라인 종합 대조 실험』, 이기홍, 김기영, 에이콘출판사-MANNING(2022), p78-129.

 

3. 트위먼의 법칙과 실험의 신뢰도

• 트위먼의 법칙: 흥미롭게 보이거나 다르게 보이는 모든 것들은 대체로 틀렸다.
• 2가지 상이한 반응
  • 긍정적인 결과: 그것을 중심으로 이야기를 만들고 공유하고 축하하는 경향이 있음 (ex. 핵심 지표의 현저한 개선)
  • 부정정인 결과: 연구의 한계나 사소한 결함을 찾아내고 그것을 기각해 버리는 경향
• 실험 결과의 신뢰도를 높이기 위한 방법
  • 결과에 이상이 있을 수 있다는 것을 나타내는 일련의 테스트와 실습 권장
  • Ex. assert문을 활용한 테스트

통계 결과의 잘못된 해석

• 통계적 검정력 부족
  • 일반적인 실수: 지표가 통계적으로 유의적이지 않다고 해서 실험 효과(treatment effect)가 없다고 가정함
    • Ex. GoodUI.org에서 115개의 A/B 테스트를 평가한 결과 대부분 검정력이 부족한 상태였음
  • 해결 방법
    • 실험이 모집단의 작은 부분 집합에만 영향을 미치는 경우 → 영향을 받은 부분 집합만 분석
    • 작은 사용자 집합에만 큰 효과가 있는 경우에는 전체적으로 효과가 희석되고 감지되지 않을 수 있음
• p값의 잘못된 해석
  • 일반적인 실수: p값이 단일 실험 데이터에 기초해 통계 집단의 평균 지표 값이 실험군의 값과 다를 것이라는 믿음
  • p-value 정의: 귀무가설이 참이라고 가정할 때 관측된 것과 같거나, 더 극단적인 결과를 얻을 확률
  • p값의 오해
    • p-value = .05면 귀무가설이 참일 확률이 5%에 불과하다.
      • p값은 귀무가설이 참이라고 가정하고 계산된다.
    • 유의하지 않은 차이는 (p > .05) 그룹 간에 차이가 없음을 의미한다.
      • 대조실험에서 신뢰구간은 0을 포함하는데, 0이 구간의 다른 값보다 가능성이 높다는 것을 의미하지는 않는다. → 실험의 검정력 부족일 수 있음
    • p-value = .05는 귀무가설 하에서 수많은 시행 중 5%만 발생하는 데이터를 관측했음을 의미
      • p값은 관찰된 것과 같거나 더 극단의 값을 얻을 확률이다.
    • p-value = .05는 귀무가설을 기각할 경우, 거짓 양성 확률이 5%에 불과함을 의미
      • FPR을 계산하려면 베이즈 정리나 사전 확률을 필요로 함 → 결합 확률 개념이며 귀무가설이 참이라는 가정 하에 조건부 확률이 아님
• p값 미리보기 (p-value peeking)
  • 미리 보기 문제: 대조군과 실험군 차이에 대한 통계적 유의도(p값) 중간 결과를 미리보고, 이를 기반으로 의사결정할 때 발생하는 문제
  • 해결 방법: 테스트 시작점에서 샘플 크기를 고정하고, 샘플 크기에 도달할 때까지 어떠한 의사결정도 반영되면 안 됨
    • 구글, 링크드인, 마소: 정해진 실험기간을 사용
    • 옵티마이즐리: p값이 항상 유효한지 순차적 테스트 or 베이지안 테스트 프레임워크를 사용

다중 가설 검정

• 다중 테스트에서 가장 낮은 p값을 선택하는 케이스 → p값과 효과 크기에 대한 추정치가 편향되기 쉬움
• 발생하는 상황
  • 여러 지표를 확인
  • p값 미리 보기
  • 모집단 세그먼트 보기
  • 같은 실험의 반복된 결과 보기 → 우연히 p값이 낮아질 수 있음
• 거짓 발견 비율(False Discovery Rate)은 다중테스트를 다루는 핵심 개념

신뢰 구간

• 개념
  • 신뢰구간: 실험 효과의 불확실성 정도를 계량화함
  • 신뢰 수준: 신뢰구간에 실제 실험 효과가 얼마나 자주 포함돼야 하는지 나타냄
• 일반적인 실수:
  • 대조군과 실험군에 대한 신뢰구간을 별도로 살펴본 후, 중복될 경우 실험 효과가 통계적으로 다르지 않다고 가정하는 것 → 신뢰구간이 겹쳐도 실험 효과의 차이는 통계적으로 유의할 수 있음
  • 제시된 95% 신뢰구간에서 실험 효과가 포함될 확률이 95%라는 믿음 → 포함될 확률은 100% or 0%다.

내적 타당성에 대한 위협

• 개념
  • 내적 타당성: 다른 모집단이나 다른 기간에 일반화를 시도하지 않는 실험 결과의 정확성
• SUTVA 위반
  • SUTVA (Stable Unit Treatment Value Assumption): 안정적 단위 실험 가치 가정
  • 실험 단위(ex. user)가 서로 간섭하지 않는다는 가정
  • 가정이 위배되는 상황
    • SNS: 기능이 사용자의 네트워크로 유출될 수 있음
    • 통신 도구(ex. 스카이프): P2P 호출
    • 공동 문서 작성 도구 (ex. MS office, Google docs)
    • 양면 시장 (ex. airbnb, ebay) → 실험군에 가격 인하를 할 경우, 경매를 통해 대조군에 영향을 미침
    • 공유 자원 (ex. CPU, cache) → 실험군의 프로세스가 느려지면 대조군에게도 영향이 미칠 수 있음
• 생존 편향
  • 현실적으로 가지고 있는 데이터만으로 원인을 추론한 case라고 생각됨
  • Ex. 폭격기에 철갑 추가한 사례
    • 비행기가 총알을 많이 맞은 곳에 철갑 추가를 했음
    • 나중에 알고 보니 가장 좋지 않은 부분임을 확인함
    • 총알구멍이 없는 곳에 추가를 해야 했었음 → 그곳에 맞았던 폭격기는 살아 돌아오지 못했음
• 실험 의도 분석
  • 실험 의도 분석 (intention-to-treat): 최초 할당이 실행됐는지 여부가 아닌, 최종 할당을 분석에 사용함
  • 참여한 사용자만 분석하면 선택 편향이 나타나고 일반적으로 실험 효과를 과대 평가함
• 샘플 비율 불일치 (SRM, Sample Ratio Mismatch)
  • 실험 단위 수가 큰 경우, 1.0을 요구하는 실험 설계에서 0.99보다 작거나 1.01보다 큰 비율은 심각한 문제를 초래할 수 있음
  • 발생하는 상황
    • 브라우저 리디렉션
      • A/B 테스트 구현을 위한 매우 보편적이고 실용적인 메커니즘
      • 지속적으로 SRM을 야기하는 것으로 나타남
      • 원인
        • 성능 차이: 실험군의 사용자가 추가적인 리디렉션을 경험하면서 발생하는 시간 차이
        • 봇
        • 비대칭: 사용자가 실험군 페이지로 리디렉션 된 이후, 즐겨찾기 or 추천이나 링크를 공유하는 경우
          • 구현에서 리디렉션이 아닌 서버 측 메커니즘을 활용하는 것이 좋음
    • 손실 계측
      • 실험이 손실률에 영향을 미쳐 활동성이 낮은 사용자가 다른 비율로 나타나 SRM을 유발 가능
    • 잔여 or 이월 효과
      • 새로운 실험은 신규 코드를 포함하기 때문에 버그 발생률은 더 높은 경향이 있음
      • 버그가 발생한 경우, 사용자는 버그에 영향을 받았기 때문에 잔여 효과가 심해질 수 있다.
        • ex. 링크드인에서 “알 수 있는 사람”을 추천했다가 실험 중지 이후 재개한 경우 SRM 발생
      • 실험 전에 A/A 테스트를 실시하고 선제적으로 다시 무작위 추출을 하는 것이 좋다.
    • 무작위 추출에 대한 잘못된 해시 함수
      • MD5와 같은 방법이 좋지만 느린 단점 존재
      • 마이크로소프트: Jenkins SpookyHash 사용
    • 실험의 영향을 받는 트리거링
      • 실험을 트리거하는 속성이 시간에 흐름에 따라 변하는 경우, 속성이 실험 자체에 영향을 받지 않도록 해야 함
    • 시간 효과
      • 동일한 크기의 대조군과 실험군으로 무작위 추출을 해도, 전자 메일 개봉 비율은 SRM이었다.
      • 이메일을 읽은 시간이 변형군 간 서로 다른 시간대에 몰려있었음
      • 구현의 용이성을 위해 이메일 전송 순서가 대조군(업무 시간) → 실험군(퇴근 후)이었음
    • 실험에 영향을 받는 데이터 파이프라인
      • 봇 필터링으로 인해 info pannel 슬라이드 수 실험의 일부 사용자가 분석에서 제외됨
      • 0.008의 비율로 분할이 굉장히 우연히 발생했지만, 실험 효과는 크게 차이를 보임

외적 타당성에 대한 위협

• 개념
  • 외적 타당성: 종합 대조 실험의 결과가 다른 모집단에 일반화될 수 있는 정도를 의미
• 해결 방법: 일반화 대신, 실험을 다시 실행하는 것
• 초두 효과 (primacy effect)
  • 변경사항이 도입됐을 때, 사용자들은 익숙해지기까지 시간이 필요할 수 있음
• 신기 효과 (novelty effect)
  • 지속되지 않는 효과를 의미
  • 새로운 기능, 눈에 띄는 기능 도입 시 처음에는 사용자들이 시도해 보지만 유용하지 않다면 반복 사용량이 작아질 것
  • 카이웨이 니의 나이키 광고 사례
    • 사진에 머리카락을 넣어서 사용자들이 치우려고 화면을 건드리는 경우를 노림 → 삭제됨
• 초두/신기 효과 검증 방법
  • 시간이 지남에 따라 사용량을 표시하고 증감 여부를 확인하는 것

세그먼트 차이

• 세그먼트 종류
  • 시장 or 국가
    • 어떤 기능은 특정 국가에서 더 잘 작동함
    • 때로는 성능이 떨어지는 기능이 현지화가 제대로 되지 못한 경우일 수 있음
  • 기기 or 플랫폼
    • UI가 브라우저, 데스크톱, 휴대전화인지
    • iOS, Android 중 어떤 모바일 플랫폼을 사용하는지
  • 시간과 요일 + 주말
  • 사용자 유형 (New, Old)
  • 사용자 계정 기능 (싱글, 공유 등)
• 사용 방식
  • 지표에 대한 관점
    • iOS와 Android의 CTR 차이
      • iOS, Windows Phone: 클릭을 추적하기 위해 리디렉션 사용 → 높은 정확도를 갖지만 사용자 경험은 느림
      • Android: 웹 비콘을 사용해 추적 클릭이 수행 → 사용자 경험은 좋지만 추적 손실률은 더 높음
  • 실험 맥락에서 지표의 실험 효과에 대한 관점 (heterogeneous treatment effect)
    • 상이한 세그먼트에 대해 실험 효과가 동질적이거나 균등하지 않다고 하는 것
    • 사용자가 세그먼트별 이동이 가능하기 때문에, 세그멘트별 지표 변화를 해석하는 것은 오해의 가능성이 있음
    • 총 실험 효과를 활용해야 함
    • 이상적인 케이스: 세그먼트를 실험 전에 결정된 값으로만 수행

심슨의 역설

• 개별적으로 보면 좋은 결과로 보이지만, 전체적으로 보면 결과가 달라지는 경우
• 비직관적으로 보이는 이유는 가중평균을 다루고 있기 때문이다.
  • 개별적인 실험의 대조군/실험군의 비율을 동일하게 세팅할 뿐만 아니라, 전체 샘플 수도 동일해야 함

 

4. 실험 플랫폼과 문화

실험 성숙도 모델

• 조직에서 실험을 시작할 때, 실험 성숙도 모델을 도입하는 것부터 문제를 겪음
• 성숙의 4단계
  • 기어가기 (crawl):
    • 1달에 1번 실험
    • 실험 설계, 요약 통계량, 실험 실행 및 분석
  • 걷기 (walk):
    • 1주일에 1번 실험
    • 실험 검증, A/A 테스트 실행, SRM 테스트 수행
  • 달리기 (run):
    • 1일에 1번 실험
    • 여러 지표 간의 trade-off를 포착, OEC 성문화
    • 새로운 기능과 변화를 실험을 사용하여 평가
  • 날기 (fly):
    • 연간 수천 번 실험
    • A/B 테스트 표준화, 데이터 과학자/분석가의 도움이 없이 실험

1. 리더십

• Step
  • HiPPO를 신뢰하기 때문에 측정과 실험은 필요하지 않다고 자만하지 말기
    • HiPPO (Highest Paid Person’s Opinion): 최고 보수를 받는 사람의 의견
  • 주요 지표를 측정하고, 원인을 설명할 수 없는 차이를 고려하기 시작
    • 패러다임의 변화는 “통상 연구에서 무엇인가 잘못된 것이 있을 때 일어난다” - 토마스 쿤
• Requirements
  • KPI, 가드레일 지표 합의 + trade-off 지표 & OEC 성문화
  • 지표 개선 관점 목표 설정 (기능 출시 목표의 발전된 버전)
  • 빠르게 실패하는 문화 정착 + 실패로부터 배우기
  • 짧은 출시 주기로 민첩성(agility)을 향상하고, 성과 측정을 위한 민감한 대리지표 확립
    • 민감한 대리지표(sensitive surrogate measure): 장기 지표 변화를 예측할 수 있는 단기적으로 예측 가능한 지표
  • 실험 결과 검토 및 해석 방법 숙지
  • ROI 확립과 같은 장기 목적을 위한 실험 및 학습

2. 프로세스

• 신뢰할 수 있는 결과를 보장하기 위해서는 교육 과정과 문화적 규범 확립이 필요
  • 교육: 모든 사람이 신뢰할 수 있는 실험 설계 및 실행, 올바르게 해석할 수 있는 기본적인 이해
  • 문화적 규범: 실패를 오히려 축하하고 배우려는 자세, 혁신에 대한 기대 설정
• Example
  • 구글: 실험자들이 실험할 때, 전문가들이 검토한 체크리스트를 작성해야 했음
    • 가설, 기대효과와 같은 기본적인 질문 + 검정력 분석을 위한 질문
    • 검정력 분석은 자동화해서 계산되도록 설정
    • 익숙해지면 통계 전문가나 데이터 과학자의 지원 없이 독립적으로 가능하게 됨
  • 링크드인, 마이크로소프트, 구글(비정기적)
    • 직원들이 실험의 개념을 상기하도록 정기적으로 강좌를 개설함
• 실험을 성공시키고 규모를 확대시키기 위해서는 지적 무결성으로 무장된 문화가 반드시 필요
  • 학습 자체가 가장 중요하다고 생각해야 함 → 선행 실험에 대한 메타 분석 및 실험 방법 전달
  • 실험 영향에 대한 완전한 투명성 또한 중요 → 실험 대시보드(다양한 지표, OEC, 가드레일)

3. 실험 플랫폼 구축 vs 구매

• 외부 플랫폼이 필요 기능을 모두 제공하는가?
  • 실행할 실험 유형을 고려 (FE vs BE, Server vs Client, Mobile vs Web 등)
  • 웹 사이트 속도 고려 → 외부 솔루션은 자바스크립트가 추가적으로 필요 ⇒ 지연 시간 증가는 사용자에게 영향
  • 사용하고 싶은 차원과 지표를 고려
  • 어떤 무작위 추출 단위를 사용할지, 어떤 데이터를 공유할 수 있는지 (민감성 정보)
  • 실시간(NRT, Near Real-Time)에 가까운 결과가 필요한지
  • 실험 기록을 공유하고 보존할 수 있는지
• 자체 구축 비용은 어떻게 될까?
  • 어렵고 많은 비용이 든다
• 실험이 증가하면 어떤 것이 필요할까?
  • 실험 모멘텀과 수요가 있고, 실험의 양이 증가할 가능성이 있다면 자체 구축이 좋다.
• 실험이 시스템 사양과 배포 방법에 통합될 필요가 있나?
  • 복잡한 디버깅 상황과 같이 배포와 실험 간의 긴밀한 통합이 필요하다면 자체 구축하자.
  • 자체 구축에 대한 니즈와 의지가 부족할 수 있기 때문에, 외부 솔루션으로 필요성을 강조하는 것도 방법이다.

인프라와 도구

• 실험 플랫폼의 목표:
  • 실험을 셀프서비스화
  • 신뢰할 수 있는 실험 실행을 위한 추가 비용을 최소화
• 실험 플랫폼 구성 요소
  • UI or API를 통한 실험 정의, 설정 및 관리로 실험 시스템 설정에 저장
  • 실험군 할당 및 파라미터화를 커버하는 서버와 클라이언트에 실험 배포
  • 실험 계측
  • 실험 분석 (p값, 통계 테스트, 지표 정의)

실험 정의, 설정과 관리

• 실험 정의와 구체화를 위해 소유자, 이름, 설명, 시작일/종료일이 필요
• 실험이 반복될 수 있도록 세팅해야 함
  • 실험 중에 발견된 버그 수정
  • 실험을 점진적으로 광범위한 실험 대상자에게 시행
• 많은 실험과 반복 시행을 위한 기능적 필요 사항
  • 실험 사양서의 초안 작성, 편집 및 보존
  • 실험 초안과 실행 중인 실험의 반복 시행 비교
  • 과거 실험에 대한 결과 및 히스토리
  • 실험 id, 변형군 자동 할당
  • 설정 불일치 방지 → 설정에 명백한 오류가 없는지 검증
  • 실험 시작은 허가를 받은 사람만, 실험 중단은 누구나 가능하도록 설정
• 실험 안정성을 위한 기능
  • 실험 시작 및 확대 방법의 자동화
  • 실시간 모니터링 및 경보 → 나쁜 실험 조기 포착
  • 불량 실험 자동 탐지 및 종료

실험 배포

• 구성 요소
  • 실험 인프라: 실험의 정의, 변형군 할당 및 기타 정보 제공
  • 실험 할당에 따라 변형군마다 행태를 구현하는 생산 코드 변경
• 실험 인프라 제공 사항
  • 변형군 할당 (variant assignment):
    • 사용자 요청과 속성이 주어질 때, 어떤 실험군과 변형군의 조합에 할당해야 하는지
    • 실험 사양 설정과 ID의 준랜덤 해시에 기반
    • 할당의 일관성을 위해 사용자 ID를 사용
    • 독립적으로 할당이 되어야 함
  • 생산 코드, 시스템 파라미터, 값
• 원자성(atomicity)이 필요한지 고려해야 함
  • 원자성: 모든 서버가 동시에 다음 실험의 반복 시행으로 전환되는지 여부
  • ex. 각 서버의 검색이 여러 대의 서버를 필요로 하는 경우
    • 검색 순위 알고리즘 변경 시, 모든 서버는 동일한 알고리즘을 사용해야 함
• 언제 변형군 할당이 일어나는지 고려해야 함
  • ex. 트래픽 분할, 클라이언트 or 서버
  • 결정을 위해 필요한 질문
    • 워크플로우의 어느 시점에서 변형군 할당에 필요한 모든 정보가 존재하는가?
    • 실험 할당은 워크플로우의 한 시점 or 여러 시점 중 어떻게 수행하도록 허용할 것인가?
      • 실험 초기 단계 → 한 시점만 권장
      • 여러 시점인 경우, 나중에 발생한 실험 항당에 편향을 주지 않도록 직교성(orthogonality)의 보장이 필요
• 실험 실행의 비용과 영향을 측정해서 아키텍처를 선택해야 함
  • 변형군 할당을 조기에 수행하고 파라미터 처리를 최적화하는 아키텍처가 많이 쓰임
    ⇒ 각 시스템 파라미터는 기본 설정을 갖고 있고, 실험군에 대해서는 어떤 시스템 파라미터와 값을 변경하면 되는지 지정하기만 하는 방식
    
    • 트리거링 처리는 어렵지만 성능 측면에서 우수
    • 기술 부채와 미래 변경 사항이 발생 시, 용이함
    • 구글, 빙에서 사용하는 방식

실험 계측

• 실험 조건과 반복 실험에 대한 모든 사용자 요청과 상호작용을 계측해야 한다.
  • 반복 실험의 계측은 실험을 개시하거나 실험 대상을 확대할 때 특히 중요
• 반사실적인 것(counterfactual)에 대한 기록을 원하는 경우
  • ex. 실험군 사용자가 대조군의 사용자였다면, 어떤 결과를 반환했을지
  • 시스템 파라미터화된 아키텍처에서 변형군 할당이 일찍 일어나는 경우, 반사실적인 로깅이 필요함
  • 성능 관점에서 비용이 많이 들 수 있음

실험 스케일링

• 최대 검정력을 원하는 경우 실험은 50:50으로 실행되어야 함
• 실험 횟수를 확대하려면 사용자가 여러 실험에 참여해야 함

a. 단일 계층법

• 총 트래픽의 특정 비율을 실험 변형군을 할당하는 방법
  • ex. 트래픽의 60%가 하나의 대조군과 두 개의 실험군으로 구성된 실험에 할당, 나머지 40%의 트래픽으로 하나의 대조군과 하나의 실험군으로 실험에 할당
• 일반적으로 해시함수를 사용하여 사용자를 버킷에 할당함
  • 버킷에 대한 사용자 할당은 무작위적이면서 결정론적이어야 함
  • 동일한 실험을 시행하는 두 버킷을 비교할 경우, 버킷은 통계적으로 유사한 것으로 가정
  • 각 버킷은 동일한 사용자 수로 구성되어야 함 (세그먼트로 분할해도 마찬가지)
• 핵심 지표 (KPI, 가드레일, 품질)는 거의 동일한 값을 가져야 함
• 이월 효과를 주의해야 한다
  • 이월 효과(carry-over effect): 실험 과정에서 이전 조건 or 처리의 영향이 현재에 영향을 미치는 경우
  • 해결책: 재정규화 or 셔플링으로 모든 실험에서 버킷이 오염되지 않도록 처리하는 것이 일반적임
• 장점: 여러 실험을 동시에 실행할 수 있다.
• 단점: 각 실험이 충분한 검정력을 갖기 위한 충분한 트래픽이 필요 → 실험 수에 제한이 있음
  • 동시성(concurrency)을 관리하기 위해 링크드인, 빙, 구글은 수동 방식으로 시작함

b. 동시 실험

• 각 사용자가 동시에 여러 실험에 참여하는 것
  • 각 실험 계층이 단일 계층 방식처럼 동작하는 여러 실험 계층을 가져야 함
  • 계층 간 실험의 직교성 보장을 위해 사용자를 버킷에 할당할 때, 계층 id를 추가해야 함
• 요청이 들어오면 변형군의 할당이 각 계층에 대해 한 번씩 수행됨
• 문제: 계층을 어떻게 결정하는가?
  • 완전 요인 실험 설계를 완전 요인 플랫폼 설계로 확장
    • 완전 요인 실험 설계(full factorial experiment design): 모든 요인의 가능한 조합이 변형군으로 테스트
    • 완전 요인 플랫폼 설계(full factorial platform design): 사용자는 모든 실험에 동시에 참여
      • 각 실험은 고유한 계층 id와 연관되므로 모든 실험은 서로 직교함
      • 동일한 실험 반복은 사용자에게 일관성 있는 경험을 보장하기 위해 동일한 해시 id를 공유
      • 단점: 잠재적 충돌
        • 두 개의 상이한 실험의 특정 실험조건이 공존할 경우, 사용자에게 안 좋은 경험을 제공할 수 있음 ⇒ 실험 간의 상호작용을 고려해야 함
        • ex. 실험 1(파란색 텍스트 테스트) + 실험 2(파란색 배경 테스트)
  • 통계적 검정력의 감소가 상호작용의 잠재적 우려보다 크다면 플랫폼 설계가 좋다.

실험 분석 도구

• 분석 자동화를 위한 데이터 처리가 필요 (= 데이터 쿠킹)
  • 실험 결과를 계산하고 시각화하는데 사용할 수 있는 상태
  • 상이한 로그를 분류 및 결합, 로그 정제/세션화/증강
    • 세션화: 이벤트를 공통된 키로 구분해서 그룹핑해주는 상태 관리 프로세스
• 주요 지표 요약 및 의사결정자에게 도움을 줄 수 있는 결과 리포팅
  • 세그먼트별 지표 계산
  • 신뢰도 검사 (p-value, 신뢰구간, SRM 점검)
    • 실험 데이터를 보기 전에 모든 데이터의 처리와 계산은 철저히 테스트하고 점검해야 함
• 모든 실험 결과에 대한 지표별 view 시각화
  • 이해관계자가 쉽게 어떤 실험이 효과적인지 모니터링 가능
  • 실험에 대한 전반적인 지식을 증가시킬 수 있음