트리즈 문제 분석

뿌리를 찾아서

아이디어를 내기 위해 제일 먼저 해야 하는 것은 문제를 제대로 알아야 한다.

그렇다면 문제는 무엇인가?

문제에 대한 뜻은 여러 사전을 참고해 보면 알 수 있다.

그중 공통적으로 첫 번째 뜻은 "해결을 요구하는 것"이라 정의된다.

또한 원하는 이상적 목표와 현실 사이의 차이를 문제라고 정의할 수 있다.

문제를 해결할 때 우리는 직관적으로 당장 눈앞에 있는 문제를 해결하려고 한다.

하지만 그 문제를 해결해도 또 다른 문제가 계속 발생하는 경험을 해 봤을 것이다.

처음부터 근본적인 문제를 찾아서 근본 원인을 제거하는 것이 효과적인 해결안을 제시할 수 있는 방법이라 생각한다.

문제 해결은 근본 원인에서 파생되는 문제를 해결하는 것이 아니라 근본 원인을 찾아서 해결해야 한다.

문제를 풀어보자.

다음 그림에서 사각형은 모두 몇 개인가?

답은 각자 알아서 생각해보자

바로 해결하려고 하면 사각형은 몇 개 되지 않는다.

하지만 집중해서 보면 상당히 많은 사각형이 보일 것이다.

이 정도 문제는 굳이 근본적인 문제까지 찾지 않아도 된다.

문제를 보는 관점을 바꾸면 해결할 수 있다.

문제 해결을 위해서는 문제 원인을 순서대로 찾아낸 다음에 근본 원인을 제거해야 한다.

나비효과를 들어본 경험이 있을 것이다.

우리가 흔히 알고 있는 것은 중국의 나비가 날갯짓을 하면 미국에 토네이도가 생긴다고 알고 있다.

실제 나비효과는 기상학에서 발표된 것인데 초기 민감한 조건의 변화로 인하여 이후를 예측할 수 없다는 것이다.

나비효과를 거꾸로 생각해보면 초기 변화를 알아내는 것이 중요하다.

중국에 있는 모든 나비를 없애면 미국에 토네이도는 안 생기는 것일까?

근본 원인 분석 (Root Cause Analysis) 또는 원인- 결과 분석 모델 (Cause-Effct Chain)이라는 트리즈의 방법이 있다.

이 방법은 고전 트리즈 (Classic TRIZ) 이후 트리즈 방법론에 추가된 것이다.

식스시그마에서 배운 5 why method와도 유사하다.

이 방법의 목적은 근본 원인을 정확하게 밝혀내서 문제를 해결하는 것이다.

문제를 구조화하고 Sub-problem과의 관계를 도식화하여 문제를 노출시킬 수 있고,

예측적 모순이 아닌 분석적 모순 문제 분석을 통하여 트리즈 문제 모델로 만드는 목적이다.

액자는 왜 떨어졌을까?

어제 액자를 벽에 걸었다.

다음 날 보니깐 액자가 떨어져 있었다.

액자는 왜 떨어졌을까?

각자 원인을 생각해보자. 이 질문을 했을 때 사람들은 다음과 같이 답을 한다.

액자가 무거워서 떨어졌다.

못이 약하게 박혀서 떨어졌다.

액자 부품이 부실해서 떨어졌다.

벽이 약해서 못이 빠져서 떨어졌다.

바람이 불어 떨어졌다.

지진이 일어나서 떨어졌다.

이와 같이 액자가 떨어진 원인들을 대답한다.

여러분도 이와 같은 원인을 생각했을 것이다.

하지만 중요한 것을 우리는 모르고 있지만 예측에 의하여 액자가 떨어진 원인을 대답하고 있는 것이다.

도대체 어떤 액자를 걸었는가? 크고 무거운 액자도 액자라고 하지만 작고 가벼운 액자도 역시 액자이다.

액자가 떨어졌다고 하니 아마도 무겁고 큰 액자일 것이라 생각한다.

못이 빠져서 액자가 떨어졌다고 하는 대답도 역시 나무용 못인지 콘크리트용 못인지 모르는 상태에서, 못 길이가 몇 cm 인지 그중 반이 박힌 건지 반도 안 박힌 건지 모르는 상태에서 대답할 수밖에 없다.

여러분이 생각하는 벽은 어떤 벽인가? 나무벽? 시멘트 벽? 콘크리트 벽?

그 벽은 건물 내부에 있는 내벽인지 아니면 건물 외부에 있는 외벽 인지도 우리는 모르고 있다.

액자를 건 벽이 있는 위치는 어디일까? 지구일까 달일까? 또는 한국일까 일본일까?

문제를 해결하기 위해서는 이렇게 많은 정보가 필요하다.

하지만 여러분들은 단지 액자가 떨어졌다는 문제를 듣고 바로 원인을 대답하고 있는 것이다.

이런 것들이 문제에 대한 고정관념이다.

문제에 대한 고정관념은 크게 2가지 때문에 생긴다.

1. 정보 부족

2. 유사 경험

살아오면서 떨어진 액자를 한 번 이상 봤을 것이다.

직접 본 사람도 있고 뉴스 또는 영화에서 본 사람도 있을 것이다.

떨어진 액자가 크고 무거운 액자가 많으므로 우리도 모르는 사이에 결과를 가지고 액자를 유추해낸다.

예전에 본 떨어진 액자가 크고 무거웠으니깐 액자가 떨어졌다고 하니 그 액자는 크고 무거울 것이라는 고정관념이 생기게 된다.

이런 고정관념에서 벗어날 수 있는 논리적이고 분석적인 원인 도출 방법이 근본 원인 분석이라고 할 수 있다.

이제 근본 원인 분석에 대하여 알아보자.

근본 원인 분석 (Root Cause Analysis)

근본 원인 분석을 하기 전에 먼저 해야 할 일은 목표를 제대로 정하고 시작해야 한다.

해결해야 하는 목표가 정의되어 있지 않으면 문제는 계속 바뀌게 된다.

근본 원인 분석을 하기에 적당한 인원은 최소 3명에서 최대 7명 정도이다. 사람이 적으면 충분한 토의가 일어나지 않고 사람이 너무 많으면 조용한 사람이 많아져서 실제 참여하는 인원은 7명을 넘지 못한다.

개인적으로는 5명이 가장 활발한 분석이 진행되고 좋은 결과를 얻을 수 있었다.

이때 참여할 사람은 문제에 대한 이해를 할 수 있는 사람이면 좋다.

기술 문제를 해결하는데 인사, 마케팅 부서에서 참여하는 것보다 연구원과 엔지니어가 참여하는 것이 효과적이다.

진행하기 전에 문제에 대한 설명을 할 수 있는 전문가가 참석해야 한다.

단지 말로만 설명하는 것이 아니라 설계도 또는 실물을 가지고 설명해야 공통적인 생각을 할 수 있다.

예전 글에서 언급한 착시 효과를 생각해 보자.

말로 설명하면 문제에 대한 충분한 이해가 없이 분석을 시작할 수 있다.

이 문제는 토끼에 대한 문제이다. 다음 그림을 보자.

그림에 독일어로 "어떤 동물이 보이는가?"라고 질문하고 아래 대답은 "토끼와 오리"라고 적혀있다.

이 그림을 보기 전까지 사람들은 토끼에 대한 문제라고 인식할 수밖에 없다.

하지만 그림을 본 이후에는 이 문제는 토끼와 오리의 복합적인 문제로 인식하게 될 것이다.

문제를 인지하고 설명하는 사람은 모든 사람들이 문제를 이해할 수 있도록 유도해야 하고 문제에 대하여는 모든 사람들의 동의를 받아야 한다.

이때 문제는 한 문장으로 정리하는 것이 좋다.

이 문제를 시작으로 계속 질문을 하고 대답을 하면서 Cause-Effect Chain을 만들어가는 것이다.

5 Why 방법에서는 "왜 그런 일이 일어났을까?"라고 질문을 한다.

하지만 RCA는 "어떤 현상이 그 결과를 만드는가?"라고 질문한다.

왜 (Why)?라고 질문하는 것이 아닌 어떤 원인(What cause)이라고 질문해야 한다.

질문에 대한 대답은 명확해야 한다.

예를 들어 기분이 나빠서, 마음에 안 들어서, 신뢰성이 낮아서, 품질이 안 좋아서 등과 같이 명확하지 않게 대답하면 안 된다.

이런 질문들을 반복하면서 아래와 같이 RCA를 완성시켜 나가는 것이다.

RCA 예시

그림에서 보면 Event #1이 표면적으로 드러난 문제이다.

Event #1에 대하여 "어떤 원인이 Event #1을 일으켰는가?"를 질문하면 그림에서는 2가지, 즉 Event#2와 Event#3이 원인으로 도출된다.

이때 화살표는 항상 결과로 향해진다.

이후 Event#2에 대하여 "어떤 원인이 Event#2를 일으켰는가?"라고 질문한다.

이 질문에 대하여는 Event#4와 Event#5의 원인을 도출하였다.

그림은 잘 보면 Event#4와 Event#5 사이에 And라고 적혀있다.

And가 적혀있지 않은 것은 Or 조건이다.

Or 조건은 각각의 원인들이 결과를 만들어내는 것이다.

하지만 And 조건은 두 개 이상의 원인이 동시에 생겨야지만 결과가 일어나는 조건이다.

요즘 걱정이 많은 미세먼지를 예를 들어 보자.

미세먼지가 나쁨을 나타낼 때는 단지 미세먼지가 많은 것뿐 아니라 바람의 방향이 중요하다고 한다.

미세먼지가 많다는 원인에 "중국에 미세먼지 발생이 많다."와 "동풍이 분다."라는 두 가지 원인이 동시에 발생해야 한국에 미세머지 수준이 나쁨으로 되는 것과 같다.

(미세먼지는 실제로 여러 원인이 복합적으로 작용된다.)

이런 식으로 계속해서 원인을 찾다 보면 오른쪽 그림과 같이 모순이 도출된다.

여기서 말하는 모순은 기술적 모순이다.

기술적 모순은 한쪽을 좋게 하니깐 다른 쪽이 나빠지고, 그 다른 쪽을 좋게 하려고 하니깐 한쪽이 나빠지는 것을 말한다. (모순 편에서 자세히 설명하겠다.)

Event#3에 원인으로 Event#6이 도출되었다.

하지만 Event#6은 Event#7을 위해서는 필요한 것이다.

RCA를 하기 전에는 서로 연관이 되어 있는지 명확하지 않았지만 RCA를 통하여 명확하게 정의되는 것이다.

그림에서 빨간색으로 표시한 것은 유해한 원인이고 파란색으로 표시한 것은 유익한 원인이다.

노란색으로 표시한 것은 유익하고 동시에 유해한 기술적 모순이다.

RCA를 진행할 때는 다양한 관점에서 문제를 도출해야 된다.

기술 및 공정 문제는 4M1E (Method, Man, Machine, Material, Environment)로 볼 수 있고,

다른 분야에서는 4P (Product, Price, Place, Promotion) 등과 같이 검토할 수 있다.

RCA는 계속 진행하다가 고객 문제 또는 어떡해도 결과를 낼 수 없는 문제에 다다르면 멈출 수 있다.

RCA가 종료되면 핵심 문제를 찾아야 한다.

보통 Tree 하단에 있는 모든 것들을 핵심 문제로 지정될 수 있다.

결과에 영향을 주는 모든 원인을 제거해야 문제는 해결되는 것이다. 가장 큰 원인을 해결한다고 해도 남아있는 원인들로 인하여 문제는 재발할 수 있다.

핵심 문제를 지정하고 난 후에 해결하는 순서는 해결하기 쉬운 것부터 해결하자.

바로 적용할 수 있는 것과 적은 변형으로 결과에 영향을 미치는 것도 우선적으로 해결해야 한다.

아래 그림에서 빨간 표시를 한 것이 핵심 문제이다.

일반적으로는 Event#4, Event#5, Event#6을 선택해야 한다. 하지만 Event#4와 Event#5는 And 조건이므로 하나만 제거돼도 Event#2는 제거될 수 있다.

다양한 아이디어를 내기 위해서는 Event#4와 Event#5를 핵심 문제로 선정해도 된다.

핵심 문제는 보통 최하단에 위치한 원인을 선택하는 데 중간 단계인 Event#2를 동시에 선택하여도 된다.

각각 원인에서 아이디어를 도출할 수 있다.

핵심 문제

실제 사례를 살펴보자.

아래 그림은 Valeri Souchkov가 2005년 학회에서 발표하고 2010년 개정한 내용이다.

(출처: http://www.xtriz.com/RootConflictAnalysisIntroduction.pdf)

Original paper was presented at the ETRIA Conference TRIZ FUTURE 2005, Graz, Austria

그림에서 설명하는 것은 컴퓨터가 고장 난 원인을 찾는 것이고 And 조건을 "&"라는 기호로 나타내고 있다.

우측 하단에 보면 냉각 팬의 속도가 낮은 원인이 있고 유해한 결과는 냉각팬이 효율적이지 않다는 것과 유익한 결과로는 소음이 작다라는 모순을 가지고 있다.

RCA를 진행하면서 모든 핵심 문제를 모순으로 만들어 보다.

예전에 삼성코닝정밀소재에서 컨설팅한 TRIZ 과제에서 RCA를 진행하였다.

당시 Flexible Dispaly 용 신소재 개발을 할 때, 제조 장비 문제에 대한 근본 원인 분석을 하였는데 분석 기간이 2주가 넘게 걸렸다.

위 논문에 나온 그림도 마찬가지지만 교육용으로 만들어졌기 때문에 실제 원인과는 다른 예측적 원인이 나오게 된다.

하지만 실제 문제에 적용할 때는 원인 하나하나를 다 검증하면서 그려 나가야 한다.

5명이 매일 8시간씩 회의실에 모여서 하나씩 검증해 나갔고, 검증은 논문, 특허, 실험 결과 등을 확인하면서 원인을 찾아갔다.

시작하는 문제를 상당히 크게 정의하고 아래쪽으로 전개한 결과 회의실 한쪽 벽이 모두 RCA Tree로 변했다.

핵심 문제의 수준이 분자 단위까지 내려갔다.

RCA 결과로 우리는 확보해야 할 기술이 무엇인지, 중장기 계획을 세울 수 있고, 해결해야 하는 핵심 문제를 도출하였다. 또한 RCA 결과로 특허도 출원할 수 있었다.

트리즈를 하는 많은 사람들이 RCA를 진행하기가 어렵다고 한다.

제대로 진행하려면 관련 지식도 있어야 하지만 중요한 것은 충분한 시간이 있어야 하는 것인데 트리즈를 하면 바로 아이디어가 나온다고 생각하여 아무도 기다려주지 않는다는 것이 가장 큰 문제이다.

문제를 해결 기간이 100이면 그중 10은 목표 설정에 사용하고 50은 문제 분석에 사용하고 20은 아이디어 도출하고 나머지 20은 아이디어 분석 및 적용하는 것으로 시간 분배를 해야 한다.

아이디어는 빨리, 많이 내는 것이 중요한 게 아니라 문제를 해결하는 것이 중요하다.