<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://noote-taking.github.io/feed.xml" rel="self" type="application/atom+xml" /><link href="https://noote-taking.github.io/" rel="alternate" type="text/html" /><updated>2025-11-23T23:02:38+09:00</updated><id>https://noote-taking.github.io/feed.xml</id><title type="html">Noote’s Journey</title><subtitle>데이터 분석가의 여정과 회고</subtitle><author><name>Noote</name></author><entry><title type="html">정들었던 회사를 떠나며</title><link href="https://noote-taking.github.io/%ED%9A%8C%EA%B3%A0/leaving-the-company-I-have-grown-found-of/" rel="alternate" type="text/html" title="정들었던 회사를 떠나며" /><published>2025-11-20T00:00:00+09:00</published><updated>2025-11-20T00:00:00+09:00</updated><id>https://noote-taking.github.io/%ED%9A%8C%EA%B3%A0/leaving-the-company-I-have-grown-found-of</id><content type="html" xml:base="https://noote-taking.github.io/%ED%9A%8C%EA%B3%A0/leaving-the-company-I-have-grown-found-of/"><![CDATA[<p>언젠가 나도 지금 있는 회사를 떠나게 된다면, 한때 유행했던 ‘퇴사 부검’을 작성하며 담담히 이별을 준비할 거라 생각했다. <br />하지만 막상 이별을 준비하는 요즘의 나는 새로운 도전에 대한 두근거림 만큼 진한 아쉬움과 알 수 없는 두려움을 마주하고 있다. <br />그건 아마도 이곳에서 보낸 지난 날들의 무게가 결코 가볍지 않았기 때문일 것이다.</p>

<p>처음 하는 이직이 아님에도, 유독 내 안에서 희비가 공존하는 이번 여정을 좀 더 잘 기억하고자 <br />내가 기억하는 지난 날들에 대한 기록을 남겨본다.</p>

<h2 id="지난-날들의-기억-23012511">지난 날들의 기억 (23.01~25.11)</h2>

<h3 id="1-첫-만남">1. 첫 만남</h3>

<p>23년 1월 24일 판교의 카페에서 처음 만난 젊은 대표님. 처음 만난 성인 남성 둘이 두 시간이 넘도록 이야기를 나눴다. <br />담담하게 풀어내는 학생창업 이야기 부터, 시리즈B 투자를 받기까지의 여정이 참 인상적이었다. <br />이런 게 바로 스타트업 이구나 라는 생각이 들었다.</p>

<h3 id="2-두-번째-만남">2. 두 번째 만남</h3>

<p>23년 1월 31일, 퇴근 후 카페에서 COO님 포함 성인 남성 셋이 다시 만났다. <br />그리고 이번에는 카페 문이 닫을 때까지 이야기를 나눴다. <br />집에 가는 길에 ‘합류 하고싶다’ 라는 생각이 들었다.</p>

<h3 id="3-합류">3. 합류</h3>

<p>얼마 뒤 나는 이곳에 합류했다. <br />이곳은 내가 예상했던 것보다 훨씬 단단하고 기민했으며, 사람들이 참 따뜻했다. <br />나만 잘하면 되겠구나 싶었다.</p>

<h3 id="4-레거시의-늪">4. 레거시의 늪</h3>

<p>경력직이 많지 않은 조직 구조에서, 이정도로 데이터를 로깅하고 의사결정에 사용하는 조직이 있다니 감탄스러웠다. <br />하지만 문제는 과거에 잘못 쌓여진 로깅 시스템. <br />어떻게 해야 할지, 해결할 수는 있는 건지 조차 막막하게 느껴졌다.</p>

<h3 id="5-로깅-시스템-개편">5. 로깅 시스템 개편</h3>

<p>백엔드팀과 협력하여 재화의 획득 소진 파악에 필요한 테이블을 4개에서 1개로 줄였다. <br />게임사에서 경험한 로깅 구조를 많이 차용했지만, 기존 시스템과 전혀 다른 방식으로의 0 to 1은 정말 쉽지 않았다. <br />포기하지 않고 끝까지 설계 및 구현에 참여해준 개발자 분에게 참 감사하다는 생각이 들었다.</p>

<h3 id="6-실험-시스템-구축">6. 실험 시스템 구축</h3>

<p>데이터 기반의 의사결정 문화는 잘 정착되었지만, 실험을 의사결정에 얼마나 잘 활용하는가는 또 다른 이야기였다. <br />기존의 실험 설계, 평가 방식의 문제점을 정의하고 하나씩 수정하기 시작했다. <br />지난하고 쉽지 않은 길이었지만, 그렇게 실험 시스템을 구축해 나갔다.</p>

<h3 id="7-실험-결과-조회-웹-페이지-구축">7. 실험 결과 조회 웹 페이지 구축</h3>

<p>실험 진행 회차가 늘어날수록 해결해야 할 문제도 늘어났지만 실험 평가 방식에 대한 기준은 선명해져 가고 있었다. <br />이참에 더 나은 의사결정과 효율적인 리소스 사용을 위해, 자동화할 부분은 자동화해야겠다는 생각이 들었다. <br />그래서 실험 결과를 모두가 같은 기준으로 확인할 수 있는 웹 페이지를 만들었다.</p>

<h3 id="8-정식으로-팀장이-되었다">8. 정식으로 팀장이 되었다</h3>

<p>입사 했을 때 부터 겸직을 하고 있었지만, 정식으로 리드 역할을 맡게 되니 솔직히.. 기분이 좋았다. <br />가족보다 더 오랜 시간을 함께하는 조직에서 신뢰받는 다는 기분이 제법 괜찮았다. <br /></p>

<h3 id="9-리더의-성장에는-시간이-필요하다">9. 리더의 성장에는 시간이 필요하다</h3>

<p>회사의 인정에 기분 좋음도 잠시, 팀원을 구하고 리딩하는 게 생각보다 쉽지 않았다. <br />혼자 일할 때 보다 더 멀리 보고 움직여야 했다. 답답한 마음에 강의도 보고 책도 보았지만, <br />시간이 지나서 보니 결국 성장에 필요한건 시간이었다.</p>

<h3 id="10-새로운-구성원들과-함께하다">10. 새로운 구성원들과 함께하다</h3>

<p>내가 조직에 스며드는 동안 새로운 동료 분들을 맞이하고 그들과 함께 일하는 경우가 늘어났다. <br />모두가 내 마음 같지는 않았다. 때로는 내 자신조차 무엇이 맞는 것인지 헷갈릴 때도 있었다. <br />하지만 그들 덕에 ‘함께 일하는 방법’에 대해 배울 수 있었다.</p>

<h3 id="11-새로운-시작을-앞두다">11. 새로운 시작을 앞두다</h3>

<p>새로운 동료들을 만난 만큼 제법 많은 동료들도 내 곁을 떠나갔다. <br />그리고 이제는 내가 새로운 출발을 앞두고 있다. <br /></p>

<h2 id="응원의-말들">응원의 말들</h2>

<p>회사를 떠날 준비를 하며 한 분 한 분 이야기를 나누는 시간을 가졌다. <br />아쉬운 게 많아 떠나는 게 아니기에, 지난 날 나의 모습에 대한 피드백을 구하고, <br />새로운 도전을 준비하며 내가 느끼는 감정에 대해서도 솔직하게 이야기를 나눴다. <br />그런데 이 시간들이 생각보다 많은 위로가 되어, 이 감정과 감사함을 기억하고자 그들의 응원을 기록으로 남겨둔다.</p>

<blockquote>
  <p>대표님의 응원</p>
</blockquote>

<p><img src="/images/2025-11-20-leaving-the-company-I-have-grown-found-of/ceo-cheerup.png" alt="ceo-cheerup" /></p>

<ul>
  <li>젊고 유능했던 대표님, 많은 신뢰와 기회를 주신 덕분에 내가 조금 더 나은 사람이 될 수 있었다.</li>
</ul>

<blockquote>
  <p>팀원 분들의 응원</p>
</blockquote>

<p><img src="/images/2025-11-20-leaving-the-company-I-have-grown-found-of/team-cheerup.png" alt="team-cheerup" /></p>

<ul>
  <li>내가 처음으로 뽑은 팀원부터, 산학 협력 프로젝트에서 이어온 인연으로 입사를 하게 된 팀원까지</li>
  <li>잘 따라와 주시고 지지해 주셔서 감사했어요.</li>
</ul>

<blockquote>
  <p>동료분들의 응원</p>
</blockquote>

<p><img src="/images/2025-11-20-leaving-the-company-I-have-grown-found-of/colleague-cheerup.jpeg" alt="colleague-cheerup" /></p>

<ul>
  <li>내 관심사와 특징을 살려 직접 그린 그림으로 만들어 주신 이별 카드. 이런 동료, 이런 회사는 또 없지 않을까..?</li>
</ul>

<blockquote>
  <p>이별 선물</p>
</blockquote>

<p><img src="/images/2025-11-20-leaving-the-company-I-have-grown-found-of/gift_from_colleague.jpeg" alt="gift_from_colleague" /></p>

<ul>
  <li>추위를 많이 타서 겨울에 사무실에서도 목도리를 하고 다니던 나를 기억해준 팀원들</li>
  <li>휴식과 체력 회복이 필요한 나에게 딱 맞는 비타민을 선물해 준 동료분</li>
  <li>누군가가 나를 기억해 주고, 마음을 표현해 준다는 것은 정말 감사한 일인 것 같다.</li>
</ul>

<h2 id="감사의-말">감사의 말</h2>

<p>내일이면 두 번째 스타트업에서의 여정이 마무리된다. <br />내 인생에서 가장 따뜻하고 찬란한 페이지들 중 하나를 만들어 준 와이피랩스 <br />회사도, 구성원들도 모두가 행복하기를 진심으로 바란다. :)</p>]]></content><author><name>Noote</name></author><category term="회고" /><category term="이직" /><summary type="html"><![CDATA[언젠가 나도 지금 있는 회사를 떠나게 된다면, 한때 유행했던 ‘퇴사 부검’을 작성하며 담담히 이별을 준비할 거라 생각했다. 하지만 막상 이별을 준비하는 요즘의 나는 새로운 도전에 대한 두근거림 만큼 진한 아쉬움과 알 수 없는 두려움을 마주하고 있다. 그건 아마도 이곳에서 보낸 지난 날들의 무게가 결코 가볍지 않았기 때문일 것이다.]]></summary></entry><entry><title type="html">시니어가 이직을 준비할 때 주의할 점</title><link href="https://noote-taking.github.io/%ED%9A%8C%EA%B3%A0/things-to-consider-when-seniors-change-jobs/" rel="alternate" type="text/html" title="시니어가 이직을 준비할 때 주의할 점" /><published>2025-11-10T00:00:00+09:00</published><updated>2025-11-10T00:00:00+09:00</updated><id>https://noote-taking.github.io/%ED%9A%8C%EA%B3%A0/things-to-consider-when-seniors-change-jobs</id><content type="html" xml:base="https://noote-taking.github.io/%ED%9A%8C%EA%B3%A0/things-to-consider-when-seniors-change-jobs/"><![CDATA[<blockquote>
  <p>제목이 거창하지만, 이번 글은 최근 면접을 보며 느낀 감정과 반성에 대한 기록이다. <br />
더 겸손해지자, 그리고 더 나은 사람이 되자</p>
</blockquote>

<h2 id="당신은-여전히-최선을-다해야-한다">당신은 여전히 최선을 다해야 한다</h2>

<p>커리어가 쌓이기 전인 주니어 시절에 나는 참으로 애를 많이 썼다. <br />잘 알려진 회사에 들어가고 싶었고, 거기서만 경험할 수 있는 무언가가 너무나도 궁금했다. <br />그래서 내가 부족한 점은 어떻게든 메우고 강점은 살리는 방식으로 면접을 준비했고, <br />회사의 서비스와 사업 전략에 대한 질문들도 오랜 시간을 들여 준비했었다. <br />그렇다. 그때의 나는 누가 봐도 간절했다.</p>

<p>시니어가 된 이후로는 면접을 보는 횟수가 급속도로 줄어들었다. <br />뒤로 갈수록 회사의 만족도가 올라가고, 해야할 일도 많았기 때문에 이직을 생각할 겨를이 없었다. <br />하지만 시간이 흘러 내가 시니어 또는 리드로 면접을 보게 되었을때 나에게는 간절함이 부족할때가 있었다. <br />좀 더 정확히는 ‘열심히 준비했다고 생각했지만, 돌이켜보니 최선을 다하지 않았던 나를 보게 되었다.’</p>

<p>그리고 내가 최선을 다했다고 생각한 면접에서는, 대부분 좋은 결과가 돌아왔다. <br />그렇다, 당신이 평소 얼마나 열심히 사는지 그들은 알수 없다. <br /><strong>당신이 최선을 다하지 않는다면 상대는 어떻게든 알게 된다.</strong></p>

<h2 id="나에-대해서-잘-알아야-한다">나에 대해서 잘 알아야 한다</h2>

<p>과거에 좋은 커리어를 쌓아왔다 할지라도 한동안 이직 시장에 뛰어들지 않다 보면 내가 어떤 사람인지 잊어버리게 된다. <br />갑자기 이직을 준비하게 되었다면 다음 질문들에 대해 시간을 갖고 고민해보자</p>

<ul>
  <li><strong>Q1.</strong> 지금까지 나는 어떤 이유로 이직을 결심하게 되었나?</li>
  <li><strong>Q2.</strong> 이직을 했을때 채워지는 점과 채워지지 않는 점에는 어떤게 있었나?</li>
  <li><strong>Q3.</strong> 당신이 가고 싶은 회사와, 당신을 필요로 하는 회사 중에 어떤 회사에서 당신의 만족도가 더 높았나?</li>
  <li><strong>Q4.</strong> 당신이 가지고 있는 경쟁력은 무엇인가?</li>
</ul>

<p>미들급 이하의 이직은 더 높은 네임벨류와 연봉수준이 이직의 실질적 사유가 되더라도 경험상 큰 문제가 되지 않는다. <br />회사의 즉시 전력이 될수 있으면서도, 규모가 큰 회사일수록 개개인의 영향력이 크지 않기 때문이다.</p>

<p>하지만 시니어부터는 이야기가 달라진다. <br />상대적으로 급여가 높을 뿐만 아니라 조직에 미치는 개인의 영향력이 커지기 때문에, <br />나와 회사의 핏이 정말 잘 맞아야 한다.</p>

<p>내 경우에는 1~2번 질문에 대한 답은 금방 얻을 수 있었던 반면, 3~4번 질문에 대한 답은 시간이 더 필요했다. <br />그리고 그 답을 통해 다음 회사에 합류 할 기회를 얻을 수 있었다.</p>

<h2 id="좋아-보이는-회사에-지원하면-안된다">좋아 보이는 회사에 지원하면 안된다</h2>

<p>직장인으로 사는 동안에는 여전히 머릿속 한 편에서는 파라다이스를 꿈꾼다 <br />특히 IT 쪽에 있다 보면 새로운 산업 군이나 신기술에 기반한 회사들, 복지와 처우로 유명한 회사들 <br />아직 내가 가보지 못한 회사들이 즐비한다.</p>

<p>하지만, 정신차려야 한다. <br />좋은 회사라는 기준은 타인이 아닌 나에게 있다. 그리고 대부분의 회사는 크게 다르지 않다. <br />당신이 만약 최선을 다할 준비가 되지 않았다면, 나의 기준과 나의 무기가 마련되지 않았다면 <br /><strong>남들이 보기에 괜찮아 보이는 회사에 지원하지 말아라.</strong></p>

<h2 id="추천을-받은-경우에는-더-신중하게-생각해라">추천을 받은 경우에는 더 신중하게 생각해라</h2>

<p>내가 추천 지원을 부탁한 경우가 아니라, 추천 지원을 제안받은 경우라면 훨씬 더 신중해져야 한다. <br />우선 다음의 두 가지를 점검해 봐야한다.</p>

<ul>
  <li>나를 추천해 준 사람이 나에 대해 얼마나 알고 있는가?</li>
  <li>당신은 최선을 다할 준비가 되어있는가?</li>
</ul>

<p>나를 알긴 알지만 직접적으로 협업해 본 경험이 없거나, 오래전 인연으로 연결된 사람이 추천을 해주는 경우라면 <br />그 회사와 나의 핏이 맞지 않을 확률이 높다. 이 상태로 면접에 들어가게되면 서로의 기대치가 다르게 되어 <br />시간 낭비만 하게 되거나 인연을 하나 잃게 될지도 모른다.</p>

<p>약한 연결 고리의 힘을 무시하라는 말이 아니다. <br /><strong>추천을 받지 않았더라도 내가 가고 싶었거나, 가기 위해 최선을 다 할 준비가 된게 아니라면 지원하지 않는게 맞다.</strong></p>

<h2 id="준비-되지-않은-회사에-상처받을-필요는-없다">준비 되지 않은 회사에 상처받을 필요는 없다</h2>

<p>규모가 큰 회사임에도, 어떤 사람을 구해야 하는지 구체화가 되지 않은 경우들이 종종 있다. <br />심지어는 해야 할 일과 소속이 구체화되지 않은 상태에서 공고만 적당히 올려둔 회사들도 있다. <br />이런 경우에는, 직접 면접을 보거나 합류하기 전에는 무엇이 잘못되었는지 알기 어렵다.</p>

<p>이는 정보 불균형에 의해 발생하는 ‘교통 사고’로 볼수 있는데 <br />회사 안에 지인이 없는 경우라면 피하기 쉽지 않은 사고로 볼 수 있다. <br /></p>

<p>구인구직 시장에서 지원자는 상대적 약자의 위치에 있지만, 이럴 때일수록 사고의 전환이 필요하다. <br />준비되지 않은 회사에 들어가 봤자 당신만 고통스러웠을 것이다. <br /><strong>유감이지만 당신의 잘못이 아니다. 잊어버리고 내일을 준비하자.</strong></p>

<h2 id="아쉬워-하되-너무-낙담할-필요는-없다">아쉬워 하되 너무 낙담할 필요는 없다</h2>

<p>최선을 다했음에도 결과가 좋지 않다면 어찌 아쉽지 않을 수 있을까? <br /><strong>하지만 너무 크게 낙담하지 말아라. 이번의 실패는 반드시 다음 기회를 얻는 열쇠가 된다.</strong> <br />시니어에게도 실패에 기반한 성장은 꼭 필요하다.</p>]]></content><author><name>Noote</name></author><category term="회고" /><category term="이직" /><summary type="html"><![CDATA[제목이 거창하지만, 이번 글은 최근 면접을 보며 느낀 감정과 반성에 대한 기록이다. 더 겸손해지자, 그리고 더 나은 사람이 되자]]></summary></entry><entry><title type="html">MDE는 어떻게 설계해야 되는가? (Ver.1)</title><link href="https://noote-taking.github.io/%ED%86%B5%EA%B3%84%ED%95%99/how-to-design-mde/" rel="alternate" type="text/html" title="MDE는 어떻게 설계해야 되는가? (Ver.1)" /><published>2025-09-21T00:00:00+09:00</published><updated>2025-09-21T00:00:00+09:00</updated><id>https://noote-taking.github.io/%ED%86%B5%EA%B3%84%ED%95%99/how-to-design-mde</id><content type="html" xml:base="https://noote-taking.github.io/%ED%86%B5%EA%B3%84%ED%95%99/how-to-design-mde/"><![CDATA[<blockquote>
  <p><strong>요약</strong> <br /></p>

  <ul>
    <li>1안: 업계 표준 기준을 사용한다. (상한선 5%)</li>
    <li>2안: 과거의 실험 데이터를 기반으로, 비즈니스 적으로 유의미한 개선 수준을 설정한다.</li>
    <li>3안: 검정력 공식을 역으로 사용해서 검정 가능한 MDE를 확인한다.</li>
  </ul>
</blockquote>

<p>실험 설계 전에 최소 샘플 사이즈를 계산하기 위해서는 MDE를 설계해야한다. 그런데 어떻게 설계를 하면 될까? 이 부분이 실무자 입장에서는 상당히 어려운 부분인데, 가장 큰 이유는 대개의 경우가 베이스라인을 설정할 수 있을 만큼 회사 내에 실험 데이터가 없다는 점이다.</p>

<p>비즈니스적으로 유의미한 수준의 기준을 잡아야 한다는 말도 다소 추상적인데, 그 이이유는 간단하다. 회사에서는 20%, 50% 이상의 높은 개선일수록 좋겠지만 이는 현실적이지 않으며, 적당히 10% 정도가 좋을까? 라고 생각해도 통계적으로 유의하게 10% 정도가 올랐던 실험 사례가 많지 않다면 그걸 베이스라인으로 정하기에는 확신이 없을 수 있다.</p>

<p>나 또한 그 기준을 어떻게 잡아야 하는가? 에 대해서는 여전히 정답을 찾지는 못했지만, 지난 2년여간 약 100개의 실험을 진행하면서 조금은 구체화 된 내용이 있어서 그 기록을 남겨본다. (언젠가는 더 명확한 기준을 설계할 수 있기를 기원하며 포스팅 제목을 Ver.1으로 작성..)</p>

<h2 id="1안-업계-표준-기준을-사용한다">1안. 업계 표준 기준을 사용한다</h2>

<p>가장 심플하지만 가장 어려운 방법이다. 왜냐하면 업계 표준에 대해서는 알려진 자료가 별로 없기 때문이다. 특히 본인이 담당하는 서비스가 틈새 시장에 속하는 경우라면 더욱더 참고할 만한 기준을 찾기 어렵다.</p>

<p>내 경우에는 Ron 박사님의 <a href="https://www.linkedin.com/pulse/why-5-should-upper-bound-your-mde-ab-tests-ron-kohavi-rvu2c/">Why 5% should be the upper bound of your MDE in A/B tests</a> 게시물을 참고했는데, 여기에는 왜 MDE의 상한을 5%로 잡아야 하는지에 대한 내용들이 작성되어 있다.</p>

<p>우선 박사님이 게시물을 통해 직접 공유한 사례 두 가지는 아래와 같다.</p>

<ol>
  <li>Airbnb allowed me to state that in 1.5 years of leading search relevance, we improved booking conversion by 6% by running 250 experiments, of which 20 were successful. The average successful experiment improved conversion by 0.3%. <br />➤ <strong>1.5년동안 250개의 실험을 진행하며 예약 전환율 6%를 개선했지만, 성공한 실험 하나당 평균 개선율은 0.3% 수준</strong></li>
  <li>At Bing, hundreds of people worked to improve the cumulative OEC of Bing’s relevance by 2% every year. In https://eduardomazevedo.github.io/papers/azevedo-et-al-ab.pdf, the success-rate metric (a component of the OEC) varied from -0.22% to 0.28% (Table 1). <br />➤ <strong>1,450개의 실험중 가장 낮은 실험의 효과는 -0.22%, 가장 높은 실험의 효과는 0.28%, 평균 효과는 -0.001%</strong></li>
</ol>

<p><br />즉, Airbnb에서 성공한 실험의 평균 개선율은 0.3% 수준이고, Bing과 같이 성숙한 서비스에서는 관찰되는 실험의 효과가 매우 적다는 것이다. 물론 최적화가 덜 된 제품으로 작업한다면 이보다 더 큰 효과를 목표로 해야겠지만, 그걸 고려하더라도 제품 개선 실험의 경우 5%의 MDE가 합리적인 상한선으로 보인다는 의견이다.</p>

<p>물론 이 내용은 서비스 도메인의 특성 외에도, 앱이 아닌 인터넷이 서비스의 주력 무대였던 시절의 데이터임을 고려할 필요는 있어보인다.</p>

<h2 id="2안-과거의-실험-데이터를-기반으로-비즈니스-적으로-유의미한-개선-수준을-설정한다">2안. 과거의 실험 데이터를 기반으로, 비즈니스 적으로 유의미한 개선 수준을 설정한다</h2>

<p>개인적으로는 2안이 가장 좋은 방법이라고 생각한다. 회사마다 서비스의 형태와 실험의 종류가 한정될 수 있으므로 각 도메인별, 기능별, 가설별로 실험 데이터가 많이 있다면, 이번에 진행하는 실험에서는 목표치를 어느정도로 잡아야할지 감을 잡기 수월하기 때문이다.</p>

<p>하지만 대부분의 초기 스타트업은 1년에 잘 설계된 실험을 20번 하기도 힘든게 현실이라 생각한다. 결국 지금 회사 내부에 데이터가 없다면 실험 환경을 구축하고, 더 많은 가설을 실험을 통해 검증하길 권장한다.</p>

<p>개인적으로는 지금까지 진행한 약 100여 개의 실험들 중에서 최근 3분기에 진행한 실험들에서 유의미한 결과들이 제법 나왔는데, 그중에서도 최소 샘플사이즈를 만족하면서 p-value &lt; 0.05인 실험은 하나가 있었고, 약 7.x% 수준의 지표 개선이 있었다.</p>

<p>승률 1%.. 실험 노하우 내재화를 위해서는 더 부지런히 움직여야 한다.</p>

<h2 id="3안-검정력-공식을-역으로-사용해서-검정-가능한-mde를-확인한다">3안. 검정력 공식을 역으로 사용해서 검정 가능한 MDE를 확인한다.</h2>

<p>이 방법은 기존의 검정력 공식인 $n=16\sigma^2/\delta^2$ 을 $\delta = 4\sigma/\sqrt{n}$ 로 바꿔서, 우리 서비스에서 일정 기간내에 검증 가능한 효과의 크기를 역산하는 방법이다.</p>

<p>간단한 방법이지만 우리 서비스의 한계치를 직관적으로 살펴볼수 있는 쉬운 방법이라고 생각한다. 특히 실험에 대한 투자가 미흡한 조직의 경우, 2주 안에 실험이 종료되기를 바라는 경우가 있는데, 이럴 경우에 왜 좀 더 기다려야 하는지에 대한 설명을 하기에도 용이하다.</p>

<p>생각해 보면 실험을 하기 위해서는 내부적으로 생각보다 많은 준비가 필요하다. 랜덤할당 로직부터 평가 기준 수립, 데이터 정합성 고도화, 가설 검증을 위한 적절한 방식의 실험 설계까지. 만약여기 까지 왔다면, 1~2주 더 실험을 진행하는게 그렇게 큰 비용일까? 오히려 실험을 조기 종료하고 검정력이 낮은 상태에서 잘못된 의사 결정을 하는 것보다는 훨씬 얻는 게 많은 기다림 일 거라 생각한다.</p>

<h2 id="references">References</h2>

<p>[1] Kohavi, R. (2023). Why 5% should be the upper bound of your MDE in A/B tests. LinkedIn. https://www.linkedin.com/pulse/why-5-should-upper-bound-your-mde-ab-tests-ron-kohavi-rvu2c/</p>

<p>[2] Azevedo, E. M., Deng, A., Montiel Olea, J. L., Rao, J., &amp; Weyl, E. G. (2019). A/B testing with fat tails. arXiv preprint arXiv:1505.03940v4.</p>

<p>[3] Kohavi, R. (2023). Using the statistical power formula in reverse. LinkedIn. https://www.linkedin.com/posts/ronnyk_using-the-statistical-power-formula-in-reverse-activity-7027144092459438080-2FTy/</p>]]></content><author><name>Noote</name></author><category term="통계학" /><category term="ab-test" /><summary type="html"><![CDATA[요약 1안: 업계 표준 기준을 사용한다. (상한선 5%) 2안: 과거의 실험 데이터를 기반으로, 비즈니스 적으로 유의미한 개선 수준을 설정한다. 3안: 검정력 공식을 역으로 사용해서 검정 가능한 MDE를 확인한다.]]></summary></entry><entry><title type="html">최소 샘플 사이즈는 언제 어떻게 계산하는가?</title><link href="https://noote-taking.github.io/%ED%86%B5%EA%B3%84%ED%95%99/when-and-how-to-calculate-minimum-sample-size/" rel="alternate" type="text/html" title="최소 샘플 사이즈는 언제 어떻게 계산하는가?" /><published>2024-11-03T00:00:00+09:00</published><updated>2024-11-03T00:00:00+09:00</updated><id>https://noote-taking.github.io/%ED%86%B5%EA%B3%84%ED%95%99/when-and-how-to-calculate-minimum-sample-size</id><content type="html" xml:base="https://noote-taking.github.io/%ED%86%B5%EA%B3%84%ED%95%99/when-and-how-to-calculate-minimum-sample-size/"><![CDATA[<blockquote>
  <p><strong>요약</strong> <br />최소 샘플 사이즈는 실험 결과의 오류율(1종 오류 α, 2종 오류 β)과 실험 목표 수준을 통제하기 위해 실험 시작 전에 설계되어야 한다. <br />하지만 실험 진행 중 지표의 분산이 초기 추정값과 크게 다를 경우, 이를 기반으로 샘플 크기를 재추정할 수 있다.</p>

  <p>물론, 이 경우에도 통계적 검정은 반드시 재추정된 최소 샘플 사이즈가 충족된 시점에 단 1회만 수행되어야 하며 <br />반복적 판단으로 인한 1종 오류 증가(p-hacking)를 방지해야 한다. <br />또한 실험 초반에는 신기 효과, 샘플 부족, 이상값 영향으로 인해 결과가 불안정할 수 있으므로 <br />검정을 허용하기 위한 최소 실험 기간(보류 기간) 등의 가드레일도 사전에 정의해둘 필요가 있다. <br />
이는 최소 샘플 사이즈 충족 여부와 함께 “평가 가능한 시점”에 대한 추가적인 신뢰성 기준이 될 수 있다.</p>
</blockquote>

<h2 id="1-두-그룹의-분산이-같은-경우---최소-샘플-사이즈-계산-공식">1. 두 그룹의 분산이 같은 경우 - 최소 샘플 사이즈 계산 공식</h2>

<p>최소 샘플 사이즈 계산 공식을 살펴보면, 왜 사전에 설계되어야 하는지를 이해할 수 있으므로 계산 공식부터 살펴보도록 하자.</p>

<p>참고로, A/B 테스트에서 효과 유무를 검정할 때 사용되는 통계적 검정은 지표 유형(평균, 비율)에 관계없이 표본 평균의 분포가 중심극한정리에 따라 정규분포로 근사된다는 가정 하에 수행된다. 따라서 최소 샘플 사이즈 계산 시에도 정규분포 기반의 Z값을 사용할 수 있어, 지표 유형에 상관없이 거의 동일한 구조로 계산이 가능하다. 단, 분산 추정 방식은 지표 유형에 따라 달라진다.</p>

<h3 id="11-평균-지표-최소-샘플-사이즈-계산-공식">1.1. 평균 지표 최소 샘플 사이즈 계산 공식</h3>

<p>대조군과 실험군의 샘플 사이즈가 동일하다는 전제로 최소 샘플 사이즈는 다음과 같이 계산된다:</p>

\[n_1 = \frac{(Z_{1 - \alpha/2} + Z_{1 - \beta})^2 \cdot 2\sigma_{pooled}^2}{\delta^2} \tag{1}\]

<ul>
  <li>$\alpha$: 1종 오류 확률 (유의 수준)</li>
  <li>$\beta$: 2종 오류 확률</li>
  <li>$Z_{1 - \alpha/2}$: 양측 검정 기준, 유의 수준 에 해당하는 Z값
    <ul>
      <li>이는 귀무가설 하에서 1종 오류를 통제하기 위한 임계 값</li>
      <li>(e.g. $\alpha = 0.05, Z_{1 - 0.025} ≈ 1.96$)</li>
    </ul>
  </li>
  <li>$Z_{1 - \beta}$: 검정력 $(1 - \beta)$에 해당하는 Z 값
    <ul>
      <li>이는 대립가설 하에서 검정력을 확보하기 위한 기준 값</li>
      <li>(e.g. $\beta = 0.2, Z_{1 - 0.2} = Z_{0.8} ≈ 0.84$)</li>
    </ul>
  </li>
  <li>$\sigma_{pooled}^2$: 두 그룹이 동일한 분산을 가진다고 가정할 때의 합동 분산 (pooled variance)
    <ul>
      <li>합동 분산 추정량을 통해 다음과 같이 계산됨: $s_{pooled}^2 = \frac{(n_1 - 1)s_1^2 \;+\; (n_2 - 1)s_2^2}{n_1 + n_2 - 2}$</li>
      <li>$2\sigma_{pooled}^2$ 에서 2는 두 그룹의 분산이 동일하고, 표본 수도 동일한경우 표본 평균 차이의 분산이 $\frac{2\sigma^2}{n}$가 되기 때문에 등장한다.</li>
      <li>즉, 2는 이러한  대칭 구조(등분산, 동일 샘플)에서 유도된 자연스러운 결과이며, 불필요한 조정 없이 공식에 포함된다.</li>
    </ul>
  </li>
  <li>$\delta$: 효과 크기, 즉 대조군과 실험군 간의 지표 값 차이
    <ul>
      <li>실험 설계 시에는 보통 우리가 사전에 의미 있다고 판단하는 최소 수준의 효과를 기준으로 설정함.</li>
      <li>이 값은 Minimum Detectable Effect (MDE) 라고 불리며, 샘플 수를 결정하는 핵심 입력값.</li>
    </ul>
  </li>
</ul>

<h3 id="12-비율-지표-최소-샘플-사이즈-계산-공식">1.2. 비율 지표 최소 샘플 사이즈 계산 공식</h3>

<p>비율 지표에 또한 대조군과 실험군의 샘플 사이즈가 동일하다는 전제로 최소 샘플 사이즈는 다음과 같이 계산된다:</p>

\[n_1 = \frac{(Z_{1 - \alpha/2} + Z_{1 - \beta})^2 \cdot 2p_{pooled}(1-p_{pooled})}{\delta^2} \tag{2}\]

<ul>
  <li>
    <p>$p_{pooled}$: 합동 비율 추정량으로 다음과 같이 계산됨: $\hat{p}_{pooled} = \frac{x_1+x_2}{n_1+n_2}$</p>
  </li>
  <li>
    <p>동일 샘플 사이즈($n_1=n_2$) 일때의 간소화 버전: $\bar{p}_{pooled} = \frac{p_1+p_2}{2}$ ($x_1=n_1p_1, x_2=n_2p_2$)</p>
  </li>
  <li>
    <p>나머지 구성 요소는 (1)번 식에서 정의된 내용과 동일</p>
  </li>
</ul>

<h3 id="13-간소화-버전의-샘플-사이즈-계산-공식-">1.3. 간소화 버전의 샘플 사이즈 계산 공식 <br /></h3>

<p>(3)번 식은 앞서 정의된 (1)번 식의 간소화 버전으로 실무에서는 다음과 같이 근사하여 자주 사용된다: <br /></p>

\[n_1 = \frac{16 \cdot \sigma^2}{\delta^2} \tag{3}\]

<ul>
  <li>여기서 16은 $(1.96 + 0.84)^2 \cdot 2 ≈ 15.68 $을 반올림한 값이다.</li>
  <li>나머지 $\sigma^2$와 $\delta$는 (1)번 식의 정의와 동일</li>
</ul>

<p><br />참고로 위 식의 상수 16은 $\alpha=0.05, \beta=0.2$ 기준 하에서 유도된 값이며, 다른 오류 기준을 설정하면 해당 상수도 달라질 수 있다.</p>

<h3 id="14-사전에-최소-샘플-사이즈를-계산해야-되는-이유-">1.4. 사전에 최소 샘플 사이즈를 계산해야 되는 이유 <br /></h3>

<p>자, 그럼 이제 앞서 확인한 식을 통해 생각해 보자 $\sigma^2$을 제외한 $\alpha, \beta, \delta$를 관측된 데이터를 바탕으로 임의로 조정하게 되면 어떤 문제가 생길 수 있을까? 정리해 보면 아래와 같이 두 가지 관점에서 문제를 정의해 볼 수 있다.</p>

<blockquote>
  <p><strong>문제1.</strong> 실험 결과를 보고 기준($\alpha, \beta, \delta$)을 변경하면 통계적 타당성이 훼손될 수 있음</p>
</blockquote>

<ul>
  <li>예를 들어 실험 중에 $\delta$를 키워서 필요한 최소 샘플 사이즈를 줄이면, 샘플 수가 부족한 상태에서도 조기 종료가 가능해지고, 이로 인해 검정력이 낮아져 실제로 존재하는 효과를 놓칠 수 있다. (2종 오류 증가 가능성)</li>
  <li>반대로, $\delta$를 줄이면 필요한 샘플 수는 증가하겠지만, 이는 실험 결과를 본 뒤, 원하는 결론을 얻기 위해 기준을 조정하는 것으로 간주되어 p-hacking으로 해석될 수 있다.</li>
  <li>$\alpha$와 $\beta$는 실험 결과를 어떤 확률 수준에서 신뢰할지 정하는 기준으로, 실험 전에 설계되어야 한다. 이를 실험 중 임의로 조정하면 해석의 일관성이 무너지고 p-hacking으로 이어질 수 있어 바람직하지 않다.</li>
</ul>

<blockquote>
  <p><strong>문제.2</strong> 실험 결과를 보고 MDE를 변경하는 것은 실험의 해석 기준 자체를 바꾸는 행위</p>
</blockquote>

<ul>
  <li>MDE는 ‘이 정도의 차이는 있어야 비즈니스 적으로 실질적인 의미가 있다’는 의사결정 기준이다.</li>
  <li>실험 결과를 본 뒤, 효과가 작아 보이니까 기준도 낮추자는 것은 실험 설계의 목적과 기준을 사후에 바꾸는 것과 같다.</li>
</ul>

<p>따라서 최소 샘플 사이즈는 사전에 정의된 $\alpha, \beta, \Delta$ 값을 기반으로 계산되어야 하며, 그래야만 실험 결과에 대한 유의성 판단이 통계적으로 정당성을 가질 수 있다.</p>

<h2 id="2-두-그룹의-분산이-다를-경우---최소-샘플-사이즈-계산-공식">2. 두 그룹의 분산이 다를 경우 - 최소 샘플 사이즈 계산 공식</h2>

<p>앞서는 ‘대조군과 실험군의 분산이 동일하다’는 등분산 가정 하에 최소 샘플 사이즈를 계산했다. 그러나 실무에서는 두 그룹의 분산이 다른 경우가 존재한다. 이 경우 최소 샘플 사이즈 계산 시 분산을 어떻게 다루는지 살펴보자.</p>

<p>또한 A/B 테스트에서는 일반적으로 균등 배분(1:1)을 하지만, 상황에 따라 의도적으로 비균등 배분(예: 2:1)을 하는 경우도 있다. 이러한 경우의 계산 로직도 반영해 두었으니 참고하도록 하자.</p>

<h3 id="21-평균-지표-최소-샘플-사이즈-계산-공식">2.1. 평균 지표 최소 샘플 사이즈 계산 공식</h3>

<p>평균 지표에서의 최소 샘플 사이즈 계산 공식은 (1)번 식에서 분산에 대한 정의만 차이가 있다.</p>

\[n_2 = \frac{(Z_{1 - \frac{\alpha}{2}} + Z_{1 - \beta})^2 \cdot (\frac{\sigma_1^2}{k} + \sigma_2^2)}{(\mu_1 - \mu_2)^2}, n_1=k \cdot n_2 \tag{4}\]

<ul>
  <li>$\sigma_1^2$: 대조군의 분산</li>
  <li>$\sigma_2^2$: 실험군의 분산</li>
  <li>$\mu_1 - \mu_2$: 효과 크기, 즉 기대하는 평균 차이($\delta$)</li>
  <li>$k$: 샘플 사이즈 비율 ($n_1/n_2$)</li>
</ul>

<h3 id="22-비율-지표-최소-샘플-사이즈-계산-공식">2.2. 비율 지표 최소 샘플 사이즈 계산 공식</h3>

<p>비율 지표에서의 최소 샘플 사이즈 계산 공식 또한 (2)번 식 대비 분산에 대한 정의만 차이가 있다.</p>

\[n_2 = \frac{(Z_{1 - \frac{\alpha}{2}} + Z_{1 - \beta})^2 \cdot \left[\frac{p_1(1 - p_1)}{k} + p_2(1 - p_2) \right]}{(p_1 - p_2)^2}, n_1=k \cdot n_2  \tag{5}\]

<ul>
  <li>$p_1$: 대조군의 전환율 또는 성공 확률</li>
  <li>$p_2$: 실험군의 전환율 또는 성공 확률</li>
  <li>$p_1 - p_2$: 효과 크기, 즉 기대하는 전환율 차이($\delta$)</li>
  <li>$k$: 샘플 사이즈 비율 ($n_1/n_2$)</li>
</ul>

<p><br /></p>

<h2 id="appendix-a-peeking-vs-p-hacking">Appendix A: Peeking vs. p-hacking</h2>

<table>
  <thead>
    <tr>
      <th>항목</th>
      <th><strong>Peeking</strong></th>
      <th><strong>p-hacking</strong></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><strong>정의</strong></td>
      <td>실험 도중 중간 결과(p-value 등)를 미리 들여다보는 행위</td>
      <td>실험 결과가 유의하게 보이도록 분석 기준이나 조건을 조작하는 행위</td>
    </tr>
    <tr>
      <td><strong>목적</strong></td>
      <td>조기 종료 또는 실험 연장의 판단</td>
      <td>원하는 결론을 얻기 위해 유의미해 보이도록 결과를 왜곡</td>
    </tr>
    <tr>
      <td><strong>의도성</strong></td>
      <td>없을 수도 있음 (무지에 의한 실수 가능)</td>
      <td>있음. 유의미한 결과를 얻기 위한 의도적 조작</td>
    </tr>
    <tr>
      <td><strong>대표 사례</strong></td>
      <td>p-value가 작아졌을 때 실험을 조기 종료</td>
      <td>변수 추가/삭제, 여러 지표 중 유의한 것만 보고, MDE/α 조정 등</td>
    </tr>
    <tr>
      <td><strong>문제점</strong></td>
      <td>1종 오류(α) 증가</td>
      <td>1종 오류(α) 증가 및 재현성 저하, 전반적인 통계적 신뢰도 훼손</td>
    </tr>
  </tbody>
</table>

<h2 id="references">References</h2>

<p>[1] Zhou, J., Lu, J., &amp; Shallah, A. (2023). All about sample-size calculations for A/B testing: Novel extensions &amp; practical guide. Proceedings of the 32nd ACM International Conference on Information and Knowledge Management (CIKM ‘23), 1-30.</p>

<p>[2] Chow, S. C., Shao, J., Wang, H., &amp; Lokhnygina, Y. (2017). Sample Size Calculations in Clinical Research (3rd ed.). Chapman &amp; Hall/CRC Biostatistics Series.</p>

<p>[3] Frost, J. (n.d.). What is P hacking: Methods &amp; best practices. Statistics By Jim. https://statisticsbyjim.com/hypothesis-testing/p-hacking/</p>]]></content><author><name>Noote</name></author><category term="통계학" /><category term="ab-test" /><summary type="html"><![CDATA[요약 최소 샘플 사이즈는 실험 결과의 오류율(1종 오류 α, 2종 오류 β)과 실험 목표 수준을 통제하기 위해 실험 시작 전에 설계되어야 한다. 하지만 실험 진행 중 지표의 분산이 초기 추정값과 크게 다를 경우, 이를 기반으로 샘플 크기를 재추정할 수 있다. 물론, 이 경우에도 통계적 검정은 반드시 재추정된 최소 샘플 사이즈가 충족된 시점에 단 1회만 수행되어야 하며 반복적 판단으로 인한 1종 오류 증가(p-hacking)를 방지해야 한다. 또한 실험 초반에는 신기 효과, 샘플 부족, 이상값 영향으로 인해 결과가 불안정할 수 있으므로 검정을 허용하기 위한 최소 실험 기간(보류 기간) 등의 가드레일도 사전에 정의해둘 필요가 있다. 이는 최소 샘플 사이즈 충족 여부와 함께 “평가 가능한 시점”에 대한 추가적인 신뢰성 기준이 될 수 있다.]]></summary></entry><entry><title type="html">검정력을 확보해야 하는 이유</title><link href="https://noote-taking.github.io/%ED%86%B5%EA%B3%84%ED%95%99/why-statistical-power-matters/" rel="alternate" type="text/html" title="검정력을 확보해야 하는 이유" /><published>2024-06-08T00:00:00+09:00</published><updated>2024-06-08T00:00:00+09:00</updated><id>https://noote-taking.github.io/%ED%86%B5%EA%B3%84%ED%95%99/why-statistical-power-matters</id><content type="html" xml:base="https://noote-taking.github.io/%ED%86%B5%EA%B3%84%ED%95%99/why-statistical-power-matters/"><![CDATA[<blockquote>
  <p><strong>요약</strong> <br />관찰된 효과의 크기가 통계적으로 유의하더라도 (p-value &lt; 0.05) <br />실제 효과보다 과장 되었을 가능성이 있으며 검정력이 낮을수록 과장의 정도가 심해진다.</p>
</blockquote>

<p>A/B 테스트는 사전에 정의된 평가지표(primary metirc)에 대해 최소 샘플 사이즈가 확보된 이후, <br />단 한번의 통계적 검정으로 실험의 효과 유무를 판단하는 것이 이상적이다.</p>

<p>하지만, 왜 충분한 수준의 검정력(Power)을 확보해야 하는 것일까? <br />일차적인 이유는 검정력의 정의에서 알수 있다. 검정력은 ‘각 변형 간에 의미 있는 차이가 있을때 이를 감지할 확률로’ 정의되는데 <br />이는 검정력이 낮은 상태에서 통계적으로 유의미한 결과를 얻을 경우, 우연에 의한 결과일 확률이 높아지기 때문이다. <br />(또는 Power = $1 - \beta$ 라는 관점에서, ‘2종 오류’를 줄이기 위해서라는 이해도 가능하다)</p>

<p>그렇다면 또 다른 이유는 무엇일까? 그건 바로 효과의 과대 추정을 방지하기 위함이다. <br />아래의 그래프는 검정력의 크기에 따른 과장 비율을 도식한 그래프로 (Gelman &amp; Carlin, 2014) <br />업계 표준인 검정력 80%에서도 약 13%의 과장이 발생하고, 50%에서는 40%의 과장, 10% 이하에서는 약 400% 이상의 과장이 발생하는 것을 알 수 있다.</p>

<p><img src="/images/2024-06-08-why-statistical-power-matters/Exaggeration ratio.png" alt="Exaggeration ratio" /></p>

<ul>
  <li>Exaggeration ratio(과장 비율): 효과가 통계적으로 유의미하게 0이 아님으로 나타났을 경우, <br />추정된 효과 크기의 절댓값을 실제 효과 크기로 나눈 값의 기댓값</li>
</ul>

<p>이와 관련해서는 Ron 박사님 역시 다음과 같이 <a href="https://www.linkedin.com/posts/ronnyk_abtesting-experimentguide-pvalue-activity-7137182337276014592-Pw3K/">언급</a>한 바 있다.</p>

<blockquote>
  <p>At 80% power, which is the industry standard power for a well-run experiment, the exaggeration factor is 13%. This may not seem like much, but when you add up successful experiments from the last year and tell finance that they added up to 15% improvement to conversion or revenue, make sure to apply at least this haircut and report 13%.  I wrote “at least” because due to multiple-hypothesis testing (we often run A/B/C/D tests) and other human degrees of freedom, <u>I would haircut at least 20%, the number we used at Bing.</u></p>
</blockquote>

<p>따라서 우리는 실험 설계 및 평가시, 최소 샘플 사이즈확보가 평가 결과의 신뢰성 확보에 훨씬 더 많은 영향을 준다는 것을 인지할 필요가 있다.</p>

<h2 id="references">References</h2>

<p>[1] Gelman, A., &amp; Carlin, J. (2014). <em>Beyond power calculations: Assessing Type S (sign) and Type M (magnitude) errors</em>. <em>Perspectives on Psychological Science, 9</em>(6), 641–651.</p>]]></content><author><name>Noote</name></author><category term="통계학" /><category term="ab-test" /><summary type="html"><![CDATA[요약 관찰된 효과의 크기가 통계적으로 유의하더라도 (p-value &lt; 0.05) 실제 효과보다 과장 되었을 가능성이 있으며 검정력이 낮을수록 과장의 정도가 심해진다.]]></summary></entry></feed>