분할정복 알고리즘
한번에 정복하기 힘든 문제가 있을때, 이를 세부적인 부분까지 나누어서 분할한뒤 각 문제를 해결후, 분할된 요소를 합병하는 것
인수분해
의미있는 축을 기준으로 대상을 나누어 각 부분에서 해결 방법을 찾는것.
예] 맥도날드의 매출 증가를 찾기 위해, 연령대/시간대로 나누어 특정 시간대의 연령 대릉 공략하는 전략을 세운다
분할 정복 알고리즘 == 인수분해
파이를 한입에 먹을 수 없다면, 먹을만한 크기로 나누어 먹어라!
각개격파!
분할 정복 알고리즘은 컴퓨터 공학과 수학에서 주로 쓰이는 개념이고, 인수분해는 비즈니스에서 주로 쓰이는 개념이다. 하지만 본질은 결국 같다.
분할 정복 알고리즘,인수분해와 What 트리의 관계
What 트리는 하나의 대상을 분해해 나가는 과정을 트리로써 나타낸 것이다. 분해해 나가는 과정자체는 위에서 언급하는 분할정복 알고리즘, 인수분해와 동일하다. 즉, What 트리에서 대상을 분해하기 위해서 사용하는 방법이 분할정복 알고리즘, 인수분해이다.
분할정복 알고리즘과 인수분해의 공통점과 차이점
공통점 : 양쪽 모두 덩어리째 생각하기 어려운 과제에 대해, 그것을 구성하는 구성요소로 잘게 나누어 생각하는 것이다. 이때 구성요소를 나누는 기준으로는 축이 사용될 수 있는데, 의미 있는 축으로 분할하여 그 분할된 부분에서 해결책을 마련한 후 합병하는 것이다.
차이점 : 프로그래밍 경우 시스템을 구성하는 구성요소를 물리적/논리적 기준으로 명확하게 구분할 수 있지만, 비즈니스의 경우 축의 기준에 따라 인수분해의 결과가 달라지기 때문에, 의미 있는 축(기준)을 잘 선정하여 그 기준에 맞는 구성요소를 분해해야 한다는 차이점이 있다.
\*프로그래밍의 예: 네트워크의 구성-> ec2, elb, subnet, vpc...
\*비즈니스의 예: 회사의 구성-> (부서를 기준으로) 인사부, 법무부, 개발부, 영업부.. (자본을 기준으로) 부채, 누적 자본...인수분해는 문제해결프로세스에서 어떻게 활용될 수 있는가?
탐색형 문제/발생형 문제의 정의를 명확히 한다.(구글 도큐먼트에선 paraphrasing이라고 표현함.. 정말 적절한 표현 같음)
- 정의의 구체적인 방법
- 문제란
목표와 현상의 GAP이므로, 목표와 현상을 명확히 할 것 - 문제를 명확히 하기 위해 주어진 과제를 목적형으로 바꾸어 목적을 명확히 할것
- 특히 실전에서는 다듬어지지 않은 워딩이 등장하여 문제를 해결하는데에 혼란을 주므로 목적을 명확히 한 후 목적을 띈 워딩으로 수정한다.
- why 트리를 통해 상위의 배경을 고려
- 구체화(5 W1 H)
- 명확하게 정의되지 않아 이후 혼선이 발생할 수 있는 키워드들을 명확하게 정의한다. 예를 들어, 「볼빅의 매출을 높이기 위해서는」이라는 문제가 주어진다면, 볼빅들 중에서 몇 ml의 볼빅을 의미하는지 명확히 할 수 있겠다.
- (optional)탐색형 문제를 발생형 문제로 바꾸어 생각해 볼 것
- 가령, 「영어를 말할 수 있기 위해서는」이라는 문제는 「영어를 말할 수 없는 이유는」이라고 생각해서 그 원인을 해결하는 해결책을 입안하는 것이 어프로치하기 쉽다.
- 문제란
탐색형 문제/발생형 문제의 정의를 근거로, 과제형 문제/발생형 문제에서 주어진 키워드가 어떠한 구성요소로 이루어져 있는지 파악한다.
과제형 문제
위에서 언급한대로 비즈니스 사이드는 인수분해가 축의 설정에 따라 달라지므로, 축설정이 중요하다. 그런데 문제를 접하고 어떤 축으로 나누면 의미있을지 곧바로 생각해내는 것은 그 문제에 대한 배경지식의 풀이 있지 않는한 쉽지 않다. 이를 돕기 위한 것이 축설정의 프레임워크이다.
프레임워크는 MESE의 논리를 이미 가지고 있는 검증된 축이므로 문제의 인수분해에 있어 큰 도움이 된다. ppt자료를 만들때 레퍼런스가 있고 없고의 차이를 크게 경험해봤을 것이다. 레퍼런스는 요건에 따라 완벽하지는 않지만 사고에 큰 도움이 된다. 축의 프레임워크는 이러한 레퍼런스와 같다. 예를 들어, 긍정적/부정적, 내부/외부, 온/오프, 개인/환경, 물리적/정신적, 의식적/무의식적, 공급/수요/, 사람/물건/돈/정보, 연령/성별, 사회인/학생, 시각/청각/미각/촉각/후각, 개인/법인, 신규/기존, 프로덕트/서비스, 가상/실제, 사적/공적, 질/양, 4p(product, price,place,promotion).
발생형 문제
발생형 문제 해결의 핵심은 원인 분석이다. 피상적인 원인 분석부터 시작하여 근본적인 원인 분석으로 이어나간다. 근본적인 원인의 분석은 원인에 대한 원인의 규명을 반복하여 접근한다. 이렇게 나뉘어진 원인의 계층에서 각 층의 원인은 피상적이든 근본적이든 해결책 마련의 근거가 된다. 이때 원인 분석은 MESE의 의해서 종류가 나뉘어지면 좋지만(생각이 누출을 막기위해), 이러한 구분보다 중요한 것은 근본적 원인을 밝혀내는 것이라는 방향성을 유지하는 것이다.
발생형 문제의 원인을 파악해 나갈 때, 인과관계의 粒度가 충분히 구체적인지 고려해야한다. 예를 들어, 「꽃가루 알레르기 환자를 줄이기 위해서는」이라는 문제에서,
「꽃가루 -> 알레르기 발생」이라는 인과관계는 중간의 세부적 인과관계가 생략되어 수많은 정보를 놓치고 있다. 이를 더욱 구체적인 인과관계로 분석하면 다음과같다.「꽃가루 -> 꽃가루가 공기로 전달 -> 공기를 흡입 -> 기관지에 쌓임 -> 기관지에서의 방위작용 -> 기침,눈물 등의 알레르기 발생」어떠한가? 이처럼 인과관계를 세부적으로 나타내면 그만큼 더욱 세부적인 원인을 분석할 수 있고, 세부적으로 발전한 원인에 대해 더 많은 해결책을 마련할 수 도 있다.공통
- 축의 설정에 어려움을 겪는 문제라면, 귀납적 인수분해를 사용한다. 귀납적 인수분해란, 개별적 해결책을 생각하기는 비교적 쉬우므로 개별적 해결책을 우선적으로 생각한 후 각 해결책에 맞추어 역으로 축을 재구성해 나가는 것이다. -> 개별적
- 인수분해를 시행할 시 그 구성요소는 stock혹은 flow(시간적 flow, ... )로 나뉘게 된다.
stock적 구성요소 : 어플리케이션(DB- 클라우드 -어플 - 인터페이스), 신체(머리-팔-다리-몸통)
flow적 구성요소 : 승진(퍼포먼스 - 평가 - 승진결정)
생각하기 좋게 나뉜 각 구성요소에서 해결책을 마련한다.
우선순위에 따라 해결책의 순서를 구체적으로 정한다.
- 우선순위를 메기는 기준은 다음과 같다 : 1. 해당 작업은 다른 작업에 영향을 미치는가? 2. 데드라인이 존재하는가?bottom up/top down의 방법으로 검증한다.
예
- 과제 : 면접을 잘 보기 위해서는 어떻게 해야 할까?
과제/문제과제형 문제/발생형 문제의 정의를 명확히 한다.
- 면접이란 무엇일까? 면접은 무엇을 위한 것일까?(why so/so how로 상위의 배경을 고려)
- 면접이란 「회사, 회사 사람들, 직무와 어울리는 지원자를 판단하는 것」이라고 정의(구체화)
- 판단이란 객관적 기준과 주관적 기준에 의해 나뉜다.
- 객관적 기준 :「명시된 기준을 통해서 in/out을 결정하는 것」
- 주관적 기준 :「함께 일하고 싶은 사람인가?같이 맥주한잔 마시면 재밌을까?」*여기에선 객관적 기준만 생각하도록 한다.
과제/문제과제형 문제/발생형 문제의 정의를 근거로,
대상의 정의가과제/문제~
과제형 문제/발생형 문제에서 주어진 키워드가 어떠한 구성요소로 이루어져 있는지 파악한다.
- 면접의 정의 : 회사,회사 사람들,직무와 어울리는 지원자를 명시된 기준을 통해서 in/out을 결정하는 것
- 키워드 : 회사, 회사사람들, 직무, 지원자, 기준
- 회사가 요구하는 기준, 직무가 요구하는 기준
- 지원자의 구성요소 : 경력, 성품
- 지원자의 경력,성품이 회사가 요구하는 기준, 직무가 요구하는 기준과 맞는지?
생각하기 좋게 나뉘어진 각 구성요소에서 해결책을 마련한다.
- 회사가 요구하는 기준 조사
- 직무가 요구하는 기준 조사 : 무엇을 하는지를 통해
- 지원자의 경력 중 회사가 요구하는 기준과 직무가 요구하는 기준을 매칭시키면서 준비하기
해결책의 순서를 구체적으로 정한다.
input조사
- 이메일, 면담할때 이야기해준 정보들,공유석
- 회사가 요구하는 것, 직무가 요구하는 것을 나누어서
input에서 기준을 추출
나의 경력사항 중 기준에 맞는 것들을 찾아서 스토리 만들기
- 스토리를 만들때의 주의사항도 input에 나와있음
- 예를 들어, try fail finally의 구조로 말하기
bottom up/top down의 방법으로 검증한다.