우리는 매일 문제와 마주친다. 우리 삶과 일터에는 크고 작은 문제들이 있다. 우리가 소속된 조직에서 수많은 난제들을 마주할 때면 어떻게 풀어야 할지 막막할 때도 있다. 어떤 이는 문제를 발판으로 성장하고, 어떤 이는 문제에 빠져 허우적댄다. 문제를 어떻게 바라 보느냐에 따라 득이 되거나, 독이 되기 때문이다.

회사의 경영활동은 문제해결 활동의 집합체이다. 이는 크게 2가지 유형으로 분류된다. 경영활동의 첫번째 유형은 원하는 일이 일어나도록 하는 것이다. 미국 경영학자 Edward Deming(1900~1993)에 의해 널리 알려진 PDCA(Plan-Do-Check-Action) 사이클을 돌려 지속적인 개선을 이룬다. 즉 매출, 손익 등 경영목표를 세우고 이를 달성하기 위한 계획을 수립, 실행한다. 계획(목표) 대비 결과(실적)을 체크하고 필요한 조치를 취하는 PDCA 실행과정에서 생기는 각종 문제를 해결한다.

두번째 경영활동 유형은 원하지 않는 일이 일어나지 않도록 하는 것이다. 예방적 차원에서 문제가 생기기 않도록 최선을 다한다. 그럼에도 불구하고 안전사고, 제품불량 등 문제들이 생기기 마련이다. 이렇게 예상 문제든, 예상 못한 문제든 해결해야 한다. 회사의 임직원이 존재 이유가 이러한 문제를 모두 해결함에 있을 것이다. 문제 해결에 왕도는 없지만 효과적인 세 가지 열쇠가 있다.

이것이 DDC, 즉 Define(정의하기), Divide(쪼개기), Connect(엮기)이다. 이 세 가지 접근법은 마치 퍼즐 조각을 맞추듯 문제를 풀어나가게 해 준다.

Define_정의하기 : 문제해결의 주춧돌

시작이 반이다. 영어 속담에도 “Well begun is half done.”이라는 표현이 있다. “무엇을, 어떻게 시작하느냐”가 문제 해결의 절반을 결정한다는 의미와 일맥상통한다. 상대성 이론으로 잘 알려진 아인슈타인(1879–1955)은 "만약 나에게 문제를 해결할 한 시간이 주어진다면, 나는 그중 55분은 문제에 대해 생각하고, 나머지 5분은 해결책에 대해 생각할 것이다."라는 명언을 남겼다. 이는 문제 해결에 있어 문제 정의에 압도적인 시간과 노력을 집중해야 한다는 통찰을 담고 있다. 이처럼 명확한 문제 정의(Define)는 해결책을 위한 청사진 역할을 한다. 이것은 단순히 문제를 언급하는 것을 넘어 아래와 같이 문제 배경, 경계, 영향, 그리고 목표를 포괄적으로 담아야 한다.

①맥락(Context): 문제의 배경과 상황에 대한 광범위한 이해를 제공하여 상황의 중요성을 파악할 수 있도록 한다. ②범위(Scope): 문제가 영향을 미치는 영역의 경계를 명확히 설정함으로써, 프로젝트가 다룰 영역을 명확히 구분한다. ③영향(Impact): 문제가 왜 중요한지, 그리고 해결되지 않을 경우 발생 가능한 파급 효과(Business Case)를 설명한다. ④바람직한 결과(Desired Outcome): 문제 해결을 통해 달성하고자 하는 이상적인 결과(목표)를 정의한다.

필자가 일했던 삼성 SDI는 1997년 Six Sigma를 도입하면서 미국 SBTI社 컨설팅을 받았다. 당시 Six Sigma 프로젝트를 수행하면서 컨설턴트로부터 가장 많은 지적 사항이 바로 문제 정의에 있었다(Most Black Belt do not properly state the problem). 당시 컨설턴트는 문제란 “고객이 느끼는 고통”이라 강조하였다. DMAIC 프로젝트 해결 과정에서 정의(Define) 단계는 전체 프로젝트의 성공과 효율성을 결정짓는 중요한 전략적 주춧돌이다. 이 단계를 통해 프로젝트의 방향성, 경계, 그리고 궁극적인 목표가 확립된다. 이 단계의 견고함이 해결책의 지속 가능성을 보장한다.

반면에 명확하지 못한 문제 정의는 이후 온갖 노력을 엉뚱한 곳에 쏟아 재작업, 비효율, 자원 낭비, 제품이나 서비스의 결함으로 나타내며 고객 신뢰 하락으로 이어진다. 문제를 정의할 때 주지할 점은 ‘미리 해결 방안을 고려하면 안 된다’는 것이다. 만약 문제 정의 자체에 이미 특정 해결책을 내포하고 있다면, 이는 분석 단계가 시작되기도 전에 결론을 미리 정해버리는 중대한 오류를 범하게 된다. 정의는 오직 '무엇이 문제인가'에 집중해야 하며, '어떻게 해결할까'는 후속단계에 맡겨야 한다.

Six Sigma 프로젝트 Define 활동은 고객의 니즈를 파악하고, 현재 프로세스에서 개선 기회와 문제점을 파악하는 것이다. 이 단계의 가장 중요한 산출물은 프로젝트의 공식적인 계약서인 헌장(Project Charter)이다. 여기에는 다음의 필수 구성 요소가 상세하게 포함되어야 한다.

Problem Statement: 고객이 무엇을 원하는지, 고객이 느끼는 고통(CTQ: Critical To Quality)을 구체적으로 진술한다. Goal Statement: CTQ로부터 측정 가능한 지표 Y(KPI, Output)를 정의한다. Y의 현수준(baseline)과 목표(goal)를 설정한다. 예를 들어, 막연히 "요즘 고객 불만이 많다"고만 말한다면 문제를 정확히 짚었다고 보기 어렵다. 대신 "지난 3개월간 배송 지연에 관한 고객 불만이 20% 증가했다"처럼 구체적이고 정량화된 표현으로 문제를 정의해야 한다.

Project Scope: 프로젝트의 경계(In/Out of Scope)를 명확히 정의한다. 이를 위한 SIPOC(Supplier, Input, Process, Output, Customer) 다이어그램은 프로세스를 시각화하고 이해하는데 유용하다. 이는 복잡한 프로세스에 대한 팀과 이해관계자들의 공감대 형성에 필수적이다. Business Case: 프로젝트의 가치 및 재정적 타당성을 포함하여, 왜 이 문제를 지금 해결해야 하는지에 대한 정당성을 제공한다. Milestone/Deliverables: 프로젝트의 주요 일정과 최종 결과물을 명시한다.

프로젝트 Define 단계는 문제 해결 프로세스의 성패를 가르는 가장 중요한 초기 투자이다. Define 결과는 이 단계가 단순한 문제 식별을 넘어, 전략적 정렬, 리스크 통제, 그리고 혁신적인 해결책의 기반 마련이라는 다층적인 기능을 수행한다. 문제를 명확하게 규정해야 그에 따른 정확한 진단과 원인 분석이 가능해지고, 결국 실효성 있는 해결책을 도출할 수 있다.

Divide_쪼개기 : 분석의 힘

문제를 해결하는 두번째 열쇠는 바로 “문제를 어떻게 나눌 것인가”이다. 나누기는 말 그대로 문제를 잘게 쪼개는 것이다. 우리는 흔히 문제 해결을 위한 분석활동을 하게 되는데, 이것이 바로 문제를 쪼개 보는 것이다. 복잡해 보이는 문제도 쪼개 놓으면 한 조각, 한 조각이 선명해진다. 이처럼 쪼개는 개념을 “Elephant Technique”이라고 은유적으로 표현할 수 있다. 이는 “아무리 큰 코끼리라 할지라도 잘게 잘라 놓으면 다 먹어 치울 수 있다”는 의미이다. “아무리 큰 문제라도 잘게 잘라 놓으면 다 해결할 수 있다”로 해석된다.

삼성 SDI에는 삼성 고유의 프로젝트 발굴방법론인 CTQ-Y 전개방식을 활용한다. 이는 사업부 CTQ-Y → 팀 CTQ-Y → 그룹 CTQ-Y로 큰 조직의 문제를 작은 조직의 문제로 하부 전개(세분화)하여 프로젝트를 발굴하는 것이다. “Divide and Conquer”는 컴퓨터 과학 알고리즘에서 쓰이는 전략으로써 “분할하여 정복한다”는 의미이다. 문제 해결관점에서는 큰 문제를 해결 가능한 조각(Manageable Piece)으로 나누어 전체 문제를 해결한다. 이를 위해 문제를 두 가지 관점에서 세분화할 수 있다.

첫째, 대상 세분화는 문제가 영향을 미치는 대상(target)이나 범위(scope)를 쪼개 보는 것이다. 분석하려는 Output(Input)를 고객별, 시간별, 지역별로 나누어 봄으로써 개선의 실마리를 찾을 수 있다. 예를 들어 한 제조공정에서 불량률이 갑자기 높아졌다고 하자. 막연히 “공장이 문제다”라고 하기보다는, 어느 라인에서, 어느 시간대에 불량이 집중되는지 나눠서 보는 것이다. 이같이 불량 문제를 층별해 보면 전체 공정의 문제가 아니라 특정 설비와 특정 근무조에서 주로 발생한다는 것을 발견할 수 있다. 이렇듯 대상을 세분화하면 문제의 범위와 우선순위를 명확히 할 수 있다.

둘째, 내용 세분화는 분석하려는 문제의 내용을 구성 요소로 쪼개 보는 것이다. 이는 일의 흐름이나 과정을 분해하는 방식으로 이뤄진다. 복잡한 업무나 절차는 Process Map을 그려보면 큰 도움이 된다. 필자가 삼성 SDI 시절 Six Sigma 프로젝트를 추진하면서 프로세스 맵은 필수적인 도구로 활용되었다. 이는 Y = f ( x ) 즉 Output = f ( input ) 관점에서 프로세스를 세분화하여 그려 봄으로써 세부 프로세스별 output에 영향을 미치는 input을 도출해 내는 것이다.

개선 대상인 프로세스 정보를 시각적으로 드러내서 output(Y) 발생에 영향을 미치는 input(x)을 발굴할 수 있다. 예를 들어 제조공정의 개선 활동을 위하여 Process Map을 효과적으로 활용할 수 있다. 즉 불량이 발생하는 공정 흐름을 여러 서브 공정(sub process)으로 나눈 다음 Input – Process – Output의 공정 흐름도(flow chart)를 그리는 것이다. 이를 통해 자재 투입부터 가공, 검사, 포장에 이르는 세분화된 공정 흐름을 다이어그램으로 시각화 함으로써 어디에서 병목(bottleneck)이 생기고, 어디서 불량이 나오는지가 뚜렷하게 드러난다.

이러한 세분화 과정은 마치 복잡한 기계를 분해해서 부품별로 점검해 보는 것과 같다. 일상 생활에서도 우리가 무언가 잘 안될 때 내용을 쪼개 보면 비로소 원인이 손에 잡힌다. 가령, 아침마다 출근 준비에 늘 늦는다면 그 과정을 쪼개 보는 것이다. 기상 → 세수 → 옷 입기 → 아침식사 → 출발, 이렇게 과정을 나눠 살펴보면, 옷 고르는 데 시간을 너무 쓰고 있다든지, 아침 식사 시간이 비효율적이라든지 특정 단계의 문제를 발견할 수 있다. 이렇게 내용을 하나하나 들여다보면, 막연했던 문제도 구체적인 개선점으로 바뀌게 된다. 분석이 정밀해지고 행동은 더 정확해진다. 결국 쪼개기는 문제를 해결 가능할 정도로 잘게 만들어 주는 마법이다. 이와 같이 문제를 쪼갤 때에 그래프나 차트를 이용하여 눈에 보이도록 하는 것이 중요하다.

물론, 문제를 쪼개다 보면 원인도 여러 갈래로 보이고 여기저기서 단서가 나온다. 이것이 분석의 힘이라면, 이제 다음으로 중요한 것은 그렇게 나온 조각들을 제대로 엮어 보는 것이다. 흩어진 퍼즐 조각을 맞추듯, 원인과 결과의 인과관계를 찾아내야 비로소 큰 그림이 완성된다.

Connect_엮기 – 인과관계의 힘

문제해결을 위한 세번째 열쇠는 “문제를 어떻게 엮을 것인가?”이다. 쪼개기를 통해 문제를 구성하는 요소들을 알아냈다면, 이제는 엮기, 즉 인과관계를 따져볼 차례이다. "구슬이 서말이라도 꿰어야 보배다"는 속담이 있다. 문제 해결 관점에서 파편처럼 흩어진 원인과 현상을 실로 꿰듯 연결해야 진짜 가치가 생긴다. 즉 세분화된 문제 변수들의 인과관계(causal relation)을 밝혀내고, 이를 구조화(structuring)하는 것이 해결의 관건이다. 아무리 많은 단서가 있어도 그것들이 서로 어떻게 이어지는지 알아내지 못하면, 우리는 핵심 원인이 아닌 표면적 증상만 건드릴 위험이 있다. 인과관계를 제대로 파악해야 문제를 뿌리째 해결할 수 있다.

문제 해결책을 관리함에 있어 위 도표에서 어느 쪽이 더 심플하게 보이는가? 왼쪽은 문제 쪼개기를 통해 4개의 관리 포인트를 찾은 그림이다. 오른쪽은 8개 관리 포인트가 있으나 화살표로 다 연결되어 있다. 이 화살표는 문제를 엮기 위한 인과관계의 방향을 제시하고 있다. 화살표의 시작점은 원인이며, 종착점은 결과로써 원인과 결과를 찾아 연결시킨 것이다. 이처럼 쪼개진 문제를 엮는 과정을 통해 오른쪽 도표는 단 1개의 관리 포인트(노란색)만 남게 된다. 복잡한 문제를 원인과 결과로 엮어 냄으로써 왼쪽보다 심플하다. 올바른 인과관계를 찾아 문제를 구조화하여 문제 해결의 실마리를 찾아낸 것이다.

지난 칼럼에서도 언급한 바와 같이, 문제 해결은 상관관계를 너머 인과관계에 있다. 통계분석에 의한 상관계수만으로는 충분하지 않다. 문제의 참원인을 찾는 노력이 필요하다. 이를 위하여 “왜? 왜? 왜?” 하고 연속으로 다섯 번을 물어보는 5 Why 분석기법이 있다. 그 배경에는 첫 번째 원인으로 멈추지 말고 진짜 근본 원인이 드러날 때까지 파고들라는 철학이 담겨 있다. 문제 원인을 Drill down하여 참원인을 밝혀낸 사례를 하나 소개한다.

워싱턴 주에 있는 美 3대 대통령 토머스 제퍼슨 기념관은 관광명소이다. 그런데 대리석 건물 천장에 비둘기가 집단 서식하여 그 배설물이 건물에 떨어져서 돌로 된 기념관의 벽이 심하게 부식되어 유지보수 작업이 불가피했다. 방문객들은 기념관에 대한 관리가 부실하여 그렇게 훼손된 것이라고 불만을 터뜨렸고, 그로 인하여 기념관의 이미지는 훼손되었다. 또한 보수작업 요원들은 청결유지에 너무 많은 시간을 소모하고 있으며 청소 용역비 및 청소용 자재 비용이 증가하고 있었다. 1943년에 설립된 이 기념관의 돌을 교체하는 것은 자명한 것으로 보였다. 이에 따라 고민에 빠진 기념관장은 5 Why를 전개하여 원인과 대책을 논의하였다.

기념관 대리석 부식의 원인을 심층적으로 분석한 결과, 황혼 무렵 전등을 일찍 켜서 주변의 나방이 몰려든 것임을 밝혀냈다. 따라서 대리석 부식의 해결책으로 “기념관 점등을 2시간 늦게 켜기”라는 뜻 밖의 참 원인(Root Cause)을 찾아낸 사례이다.

5 Whys처럼 원인과 결과를 엮는 방법은 여러 가지가 있다. 일본 Ishikawa(1915~1989) 박사가 개발한 원인-결과(물고기뼈) 다이어그램과 같은 특성요인도도 원인들을 체계적으로 분류해 인과관계를 정리하는 데 자주 쓰인다. 또한 C&E 매트릭스(Cause & Effect Matrix)라는 것도 있다. 이는 원인과 결과를 행렬 형태로 배열하여 각각의 관련성을 점수화하는 기법이다. 예를 들어 제품의 고객 불만 원인을 찾는다면, 가로축에는 잠재적 원인들(배송 지연, 제품 불량, 고객응대 문제 등)을 쭉 나열하고 세로축에는 영향받는 결과들(고객 만족도, 재구매율 등)을 놓는다. 그리고 각각의 원인이 각 결과에 얼마나 큰 영향을 주는지 점수를 매겨 가장 영향력이 큰 원인을 찾아낸다. 이는 복잡한 인과관계 속에서 우선순위를 정해주는 나침반 역할을 한다.

인과관계를 명확히 하는 데 있어 FMEA(Failure Mode Effects Analysis, 고장 모드 영향 분석) 기법을 빼놓을 수 없다. FMEA는 제품이나 프로세스에서 발생할 수 있는 모든 실패 시나리오를 분석하고 각각의 위험 수준을 평가한다. 구체적으로는 각 잠재적 문제에 대해 심각도(Severity), 발생 가능도(Occurrence), 발견 가능도(Detection)를 점수로 매긴다. 예를 들어 자동차 브레이크 시스템을 설계한다고 하면, 브레이크 오일 누유라는 문제의 심각도는 얼마나 치명적인 사고로 이어질 수 있는지를 평가하고, 발생 가능도는 그런 누유가 얼마나 자주 일어날 것 같은지를, 발견 가능도는 정비나 검사에서 얼마나 쉽게 발견될 수 있는지를 각각 점수화한다.

이상의 세 가지 점수를 곱하여 RPN(Risk Priority Number) 값을 계산한다. 이 값이 높게 나온 실패 모드부터 개선 대책을 세운다. 결국 FMEA의 핵심은 위험과 발생 확률을 따져가며 가장 우선적으로 다뤄야 할 문제를 선별하는 데 있다. 제한된 시간과 자원 속에서 피해야 할 리스크와 우선 잡아야 할 불씨를 가려내는 것이다. FMEA를 활용하여 수십 개의 잠재 문제들 중 상위 RPN 항목에 집중하여 개선함으로써 향후 발생할 뻔한 큰 결함들을 미리 예방할 수 있다.

이처럼 5 Whys, C&E 매트릭스, FMEA 등의 도구들은 각각 방식은 달라도 공통점이 있다. 바로 문제의 원인과 결과를 체계적으로 연결하고 검증해 준다는 점이다. 근본 원인을 찾고, 그 중에서 가장 중요한 원인을 선별하여 효과적인 처방을 내린다. 사실 이런 접근법은 체계적인 문제해결 방법론에서 널리 권장된다. 삼성 SDI의 Six Sigma 교육 과정을 보면, Measure 단계에서 프로세스 맵, C&E 매트릭스, FMEA와 같은 도구들을 활용하여 Y(output)에 영향을 미치는 x(input)을 발굴하고, 이를 평가한다. Analyze 단계에서는 data를 활용하여 이들 간의 인과관계를 따져보도록 가르친다. 그만큼 “엮기”, 곧 인과관계 분석의 힘은 문제 해결의 성패를 가르는 중요한 열쇠이다.

그런데 원인을 찾아냈다고 해서 문제가 자동으로 해결되는 것은 아니다. 찾아낸 원인을 제거하려고 행동을 취할 때, 우리가 간과하기 쉬운 게 있다. 바로 전체적인 맥락과 시스템의 영향이다. 어떤 원인을 제거하면 다른 곳에 새로운 문제가 생기진 않을까? 혹은 팀 간 충돌이 일어나진 않을까? 부분만 볼 것이 아니라 시스템 전체를 생각해야 지속적인 해결이 가능하다. 그래서 문제 해결의 방점인 통계적 사고, 그리고 그에 수반되는 시스템적 사고의 힘을 이야기하고자 한다.

문제 해결의 방점 – 통계적 사고

앞서 “쪼개기”와 “엮기”를 통해 우리는 문제의 구성 요소와 원인들을 파악하였다. 이제는 한 걸음 물러서서 숲을 보는 일이 남았다. 바로 전체 시스템을 조망하며 통계적 안목으로 바라보는 것이다. 통계적 사고는 문제를 둘러 싼 시스템과 프로세스 그리고 프로세스의 변동성을 이해하고, 줄여 나가는 것이다. 이와 더불어 부분 최적화가 아닌 전체 최적화를 지향하는 사고방식이다.

예를 들면 한 공장의 A공정 팀이 “우리는 생산량을 두 배로 늘렸어!”라고 의기양양해하지만, 정작 다음 B공정 팀의 처리 능력은 그대로라면 어떤 일이 벌어질까? B공정 팀 앞에는 처리가 밀린 반제품들이 산더미처럼 쌓이고, 전체 생산 리드타임은 더 늘어날 것이다. A공정 팀은 자기 할 일은 다 했다고 생각하겠지만, 결과적으로 공장 전체로 보면 더딘 출하로 손해를 볼 수 있다. 이게 바로 부분최적화의 함정이다.

한 부분의 효율만 높이다 보면 다른 부분과 엇박자가 생겨 전체 시스템 성능이 저하될 수 있다. 시스템적 사고는 팀 전체를 보고 팀 전체의 정렬(alignment)을 가져온다. 부분의 문제를 우리 모두의 공동 과제로 인식하게 해준다. 삼성 SDI에서도 Six Sigma를 추진하면서 당면 문제를 다 같이 바라보며 문제해결 활동 과정에서 임직원 전반의 공감대 형성과 팀간 소통 촉진 또한 중요한 성과로 꼽는다.

지금까지 이야기한 세 가지 열쇠 – 정의하기, 쪼개기, 그리고 엮기는 따로 떨어져 있는 기법들이 아니라 사실 하나의 흐름으로 이어지는 문제 해결의 여정이다. 우선 문제를 명확히 정의한 다음 작게 쪼개 분석하고, 다음으로 그 조각들을 인과관계로 엮어 근본 원인을 찾는 것이다. 그리고 그 해법을 전체 시스템 관점에서 추진하는 것이다. 이 세 단계가 유기적으로 맞물릴 때 우리는 비로소 정교하면서도 실행력 있는 해결책에 도달하게 된다.

우리 삶에서도 이 원리는 유효하다. 일터에서 프로젝트가 꼬였을 때든, 일상에서 풀기 힘든 문제에 직면해 있다면 이 세 가지 열쇠를 활용해 보길 권한다. 어떤 문제든 처음에는 복잡해 보여도 ①무엇이 문제인지를 명확하게 문제를 꿰뚫어 정의한다. ②정의된 문제를 잘게 쪼개 보면 문제가 선명해지고 문제가 손에 잡힌다. ③원인과 결과를 엮어 뿌리를 찾으면 해결책이 심플해진다. 다음으로 시스템적 사고로 전체를 바라보며 지속가능한 해법을 모색해보는 것이다.

어려운 문제일수록 기본으로 돌아가 “정의하고, 쪼개고, 엮고, 전체를 보라”는 이 단순한 원칙이 의외로 강력한 해결의 열쇠가 되어줄 것이다. 이러한 접근법을 터득하게 되면 당면한 문제들을 풀어나가는 데 자신감이 생길 것이다. 무엇보다 문제를 바라보는 시야와 사고방식이 바뀌니, 이전에는 보이지 않던 해결의 본질에 접근한다. 진짜 문제는 문제가 없는 것이다. 지금부터는 문제를 피하기 보다는 문제에 맞서 즐기자. 이것이 바로 회사 경영에 기여하고, 개인도 성장하는 좋은 기회이기 때문이다. 그리하여 세상을 바꾸는 진정한 해결사가 되어 보자.

2025. 10. 22 한국표준협회 전문위원 / 건국대학교 김학수