<div id="readability-page-1" class="page"><article id="mainContent">
                <div>
                  <p><a href="/m/category/%F0%9F%93%99%20article/biz"><span>📙 article/biz</span></a></p><h3>[가안] MECE한 사고 방식의 통계, 알고리즘, 기획 분야에서의 적용</h3>
                </div>
                <p><cite>DarrenKwonDev</cite>
                  <span> 2022. 11. 26. 16:24</span>
                </p>
                                <div>
                                <p data-ke-size="size16">MECE하다는 것은 Mutually Exclusive (상호 배제) 적이고 Collectively Exhaustive(전체 포괄) 의 앞 문자를 딴 것이다.</p>
<p data-ke-size="size16">이 사고 방식은 생각보다 많은 분야에 적용될 수 있다.</p>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="810" data-origin-height="1200">
    <a href="http://www.yes24.com/Product/Goods/76899643" target="_blank">
        <img src="https://blog.kakaocdn.net/dn/bfD30h/btrR9kTTt28/7HJBEDbQjTuIRM43926S3K/img.jpg" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" width="255" height="378" data-origin-width="810" data-origin-height="1200">
    </a>
    <figcaption>http://www.yes24.com/Product/Goods/76899643</figcaption>
</figure>

<h4 data-ke-size="size20"><b>기획</b></h4>
<p data-ke-size="size16">보통 it 프로덕트를 처음 기획할 때는 아이디어가 아닌 해결하고자 하는 문제에 집중하는 것이 기본이다.&nbsp; (start up = problem solving)</p>

<p data-ke-size="size16">조금 더 파고 들자면 해당 문제가 지닌 전체 공간을 문제 공간(problem space)으로 바라보고 MECE하게 나눠야 한다.</p>

<p data-ke-size="size16">왜?</p>

<p data-ke-size="size16">그것은 사업에 있어 로직 트리를 구성하여 so what/why so로 검증하는 추상적인 기획 방법론으로 시작하여&nbsp;<a href="https://twitter.com/shreyas/status/1376037565057261571?lang=en" target="_blank" rel="noopener">CPSR (Customer Problems Stack Rank)</a>이나 가설 검증을 베이즈 통계적으로 검증하는 토대이기 때문이다.</p>

<p data-ke-size="size16">몇 만원 태워서 광고 돌려보고 반응이 몇 건 나왔는지로 진행하는 검증 방식은 주관적으로 적고 많은 느낌밖에 주지 못한다. 물론 데이터를 보더라도 주관이 개입될 수 밖에 없지만 최소한의 논리를 갖추기 위한 방법이다.</p>


<h4 data-ke-size="size20"><b>통계</b></h4>
<p data-ke-size="size16">전체를 MECE하게 나누는 것을 사건 S에 대한 분할(partition)이라 한다. 베이즈 정리의 토대가 된다.</p>


<h4 data-ke-size="size20"><b>알고리즘</b></h4>
<p data-ke-size="size16">문제 상황의 모든 것을 MECE하게 나누는 것은 모든 경우의 수를 나열 하여 edge case까지 대처했다는 것을 의미한다.</p>
<p data-ke-size="size16">보통 코딩 테스트 문제를 읽고 닥치는 대로 구현하다 보면 엣지 케이스를 코드 상 어디에 끼워 넣어야 할 지 참으로 난감해지는데, 이는 문제를 보자마자 달려들면 생기는 일이다. 나도 이 버릇을 고치기 위해 꽤 많은 시간을 할애했다.</p>

<p data-ke-size="size16">결론적으론 문제를 읽기 전에 먼저 해당 문제를 MECE하게 분리하는 것이 중요하다.</p>



            
            
                </div>
                

              </article></div>

HotHandCoding

DarrenKwon

MECE하다는 것은 Mutually Exclusive (상호 배제) 적이고 Collectively Exhaustive(전체 포괄) 의 앞 문자를 딴 것이다.
이 사고 방식은 생각보다 많은 분야에 적용될 수 있다.
 
기획
보통 it 프로덕트를 처음 기획할 때는 아이디어가 아닌 해결하고자 하는 문제에 집중하는 것이 기본이다.  (start up = problem solving)
 
조금 더 파고 들자면 해당 문제가 지닌 전체 공간을 문제 공간(problem space)으로 바라보고 MECE하게 나눠야 한다.
 
왜?
 
그것은 사업에 있어 로직 트리를 구성하여 so what/why so로 검증하는 추상적인 기획 방법론으로 시작하여 CPSR (Customer Problems Stack Rank)이나 가설 검증을 베이즈 통계적으로 검증하는 토대이기 때문이다.
 
몇 만원 태워서 광고 돌려보고 반응이 몇 건 나왔는지로 진행하는 검증 방식은 주관적으로 적고 많은 느낌밖에 주지 못한다. 물론 데이터를 보더라도 주관이 개입될 수 밖에 없지만 최소한의 논리를 갖추기 위한 방법이다.
 
 
통계
전체를 MECE하게 나누는 것을 사건 S에 대한 분할(partition)이라 한다. 베이즈 정리의 토대가 된다.
 
 
알고리즘
문제 상황의 모든 것을 MECE하게 나누는 것은 모든 경우의 수를 나열 하여 edge case까지 대처했다는 것을 의미한다.
보통 코딩 테스트 문제를 읽고 닥치는 대로 구현하다 보면 엣지 케이스를 코드 상 어디에 끼워 넣어야 할 지 참으로 난감해지는데, 이는 문제를 보자마자 달려들면 생기는 일이다. 나도 이 버릇을 고치기 위해 꽤 많은 시간을 할애했다.
 
결론적으론 문제를 읽기 전에 먼저 해당 문제를 MECE하게 분리하는 것이 중요하다.

[가안] MECE한 사고 방식의 통계, 알고리즘, 기획 분야에서의 적용

댓글