구조적 사고: 컨설턴트의 진짜 강점

구조적 사고는 컨설턴트가 모호하고 어지러운 고객의 문제에서 회의실의 사람들이 따라가고 반박할 수 있는 권고안에 이르는 방법입니다. 의사결정을 프레임으로 세우고, 서로 겹치지 않는 부분으로 문제를 나누고, 가장 가능성이 높은 답부터 검증한 다음, 결과를 하나의 명확한 권고안으로 모읍니다.

이 글은 압박 속에서도 이 일을 반복해서 해낼 방법을 원하는 컨설턴트와 애널리스트를 위한 것입니다. 제가 가장 많이 쓰는 네 가지 도구, 다음 프로젝트에서 바로 쓸 수 있는 한 쪽짜리 워크시트, 그리고 AI가 이 역량에 가져온 변화를 다룹니다.

고객 회의에서 얼어붙는 사람들을 본 적이 있습니다. 아이디어가 없어서가 아닙니다. 어디서 시작해야 할지 몰랐기 때문입니다.

상황은 낯익습니다. 복잡한 문제, 고위 임원들로 가득한 회의실, 모호한 범위, 그리고 명쾌한 답에 대한 기대. 구조 없는 대응은 일단 말을 꺼내 놓고 답이 저절로 나오기를 바라는 것입니다. 가끔은 나옵니다. 더 자주는 20분 동안 빙빙 돌다가 아무도 만족하지 못한 채 회의실을 나옵니다.

모호한 문제를 구성 요소로 나누고, 각 요소를 순서대로 풀어 가고, 결과를 다시 모아 권고안으로 만드는 일입니다.

템플릿을 채우고 그것을 분석이라 부르는 것이 아닙니다. 맞지 않는 문제에 프레임워크를 억지로 끼우는 것도 아닙니다. 모든 상황에 2x2 매트릭스를 들이대는 컨설턴트는 생각하는 것이 아니라 패턴을 맞추고 있는 것입니다.

여러분이 기르는 것은 몇 가지 역량입니다.

1. 제시된 문제와 다른 경우가 많은 진짜 문제를 알아보기
2. 문제를 따로 분석할 수 있는 부분으로 나누기
3. 어떤 정보가 중요하고 어떤 정보가 중요하지 않은지 알기
4. 찾아낸 내용으로 일관된 논거 세우기
5. 회의실 분위기가 팽팽할 때 명확하게 말하기

이 역량이 자라는 동안 프레임워크는 비계 역할을 합니다. 더 폭넓은 도구 세트가 궁금하다면 간단한 컨설팅 프레임워크 해설에서 흔히 쓰는 것들을 다룹니다.

프레이밍 질문

어떤 프레임워크를 쓰기 전에 질문 하나를 하십시오. 어떤 의사결정을 내려야 하고, 어떤 정보가 그 결정을 바꿀 것입니까?

이 질문은 어떤 구조적 도구보다 분석의 질을 높입니다. 산출물이 무엇인지 분명히 하게 하고, 아무도 답을 필요로 하지 않은 질문에 철저하게 매달리는 일을 막아 줍니다. HBR도 오래전 Are You Solving the Right Problem?에서 같은 주장을 했습니다. 낭비되는 노력의 대부분은 문제를 부실하게 정의한 데서 시작합니다.

SAP 맥락에서 "이 조직에 맞는 도입 모델은 무엇인가"는 의사결정입니다. "S/4HANA란 무엇인가"는 설명입니다. 앞의 것에는 분석이 필요하고 뒤의 것에는 문서화가 필요합니다. 지금 어느 쪽을 하고 있는지 아는 것이 한 주를 어떻게 쓸지를 정합니다.

MECE

MECE는 Mutually Exclusive, Collectively Exhaustive의 약자입니다. 문제를 부분으로 나눌 때 각 부분은 서로 구별되어야 하고(겹치지 않음), 합치면 문제 전체를 덮어야 합니다(빠진 것이 없음).

범주가 겹치면 이중으로 셉니다. 빈틈이 있으면 놓칩니다. 약어는 대부분의 컨설턴트가 알지만 엄격하게 적용하는 사람은 드뭅니다.

두 가지 테스트로 점검합니다. 첫째, 하나의 항목이 두 가지에 동시에 들어갈 수 있는가? 그렇다면 가지가 겹칩니다. 둘째, 모든 가지에 답했을 때 핵심 질문에도 답이 되는가? 그렇지 않다면 빈틈이 있습니다. 완벽한 MECE는 드뭅니다. 중요한 것은 매번 이 두 질문을 던지는 것입니다.

이슈 트리

이슈 트리는 핵심 질문을 뿌리에 두고 하위 질문을 가지에 배치합니다. 각 가지는 따로 분석할 수 있습니다.

"이 SAP Go-Live는 왜 계획 예산을 40% 초과했는가?"를 예로 들겠습니다. 첫 번째 분기는 범위 변경, 인력 비용, 일정 연장, 계획에 없던 보완 작업일 수 있습니다. 범위 변경은 다시 공식 변경 요청, 비공식 추가, 뒤늦게 발견된 갭으로 나뉩니다. 각 말단은 측정할 수 있습니다.

이슈 트리는 프로젝트 초반, 아직 분석을 하나도 하지 않았을 때 진가를 발휘합니다. 한 가지를 3주 동안 파고드는 사이 다른 가지가 손도 못 대는 상황을 막아 줍니다.

가설 중심 분석

모든 데이터를 모은 다음 결론을 내리는 대신, 가장 가능성이 높은 답에서 출발해 검증합니다. 전략 컨설팅 회사들은 이 접근법으로 명성을 쌓았습니다.

시간이 한정되어 있고 문제가 복잡하면 전수 분석은 불가능합니다. 좋은 가설은 무엇을 먼저 봐야 하는지 알려 줍니다. 가설이 맞으면 답을 얻은 것입니다. 틀리면 그것을 깨뜨린 증거가 대개 쓸모 있는 곳을 가리킵니다.

가장 자주 잘못 쓰이는 접근법이기도 합니다. 컨설턴트가 가설을 세운 다음 그것을 뒷받침하는 증거만 찾습니다. 무엇이 내가 틀렸음을 증명할지 묻고, 그것부터 찾으러 가십시오.

첫 진단에 나서는 신입 컨설턴트에게 제가 건네줄 순서입니다. 스프레드시트를 하나라도 열기 전에 채우십시오.

1. 01프레이밍의사결정을 한 문장으로
2. 02분해MECE한 질문 세 개에서 다섯 개
3. 03가설 수립가지마다 한 줄
4. 04반증가설이 틀렸음을 보여 줄 증거
5. 05검증출처를 단 가지별 발견 사항
6. 06종합권고안 먼저, 그다음 근거
7. 07압박 테스트회의실이 제기하기 전에 답해 둔 반론

운영위원회를 통과하는 권고안

단계	답해야 할 질문	산출물	승인자
1. 프레이밍	고객은 어떤 의사결정을 언제까지 내려야 하는가?	한 문장	고객 스폰서
2. 분해	함께 답하면 그 의사결정이 정해지는 질문은 세 개에서 다섯 개 중 무엇인가?	1단계 이슈 트리, MECE 검증 완료	프로젝트 리드
3. 가설 수립	현재 내가 생각하는 답은 무엇이고, 그 이유는 무엇인가?	가지마다 한 줄짜리 가설	프로젝트 리드
4. 반증	각 가설이 틀렸음을 보여 줄 증거는 무엇인가?	순위를 매긴 데이터 요청 목록	자료 제공에 동의한 고객 데이터 책임자
5. 검증	증거는 무엇을 말하는가?	출처를 단 가지별 발견 사항	팀의 가지별 담당자
6. 종합	그래서 고객은 무엇을 해야 하는가?	권고안 먼저, 그다음 뒷받침하는 논점	프로젝트 리드
7. 압박 테스트	회의실에서 누가 어떤 점에 반대할 것인가?	준비된 반론과 답변	해당 작업에 참여하지 않은 동료

7단계는 사람들이 건너뛰는 단계입니다. 권고안이 운영위원회를 통과할지를 가르는 단계이기도 합니다.

한 SAP 고객, 대형 제조 그룹은 커스터마이징이 많은 ECC 환경을 운영하고 있었습니다. IT 책임자는 분명하게 말했습니다. "운영 비용을 줄여야 하지만, 아무것도 망가뜨릴 수는 없습니다."

본능적으로는 절감 아이디어를 나열하기 시작합니다. 그러면 긴 목록, 불안해하는 사람들, 우선순위 없음이 남습니다.

저희는 비용 분석을 세 가지로 나눴습니다. 애플리케이션 유지보수, 인프라, 라이선스입니다. 그런 다음 커스텀 코드 분석을 얹었습니다. 수정 사항 중 실제로 쓰이는 것은 몇 개인가? 절반이 넘게 쓰이지 않았습니다. 불필요한 인터페이스, 쓰지 않는 커스텀 리포트, 겹치는 워크플로였습니다.

그렇게 구조화한 덕분에 사용하지 않는 커스텀 오브젝트를 아카이빙하고 개발 환경을 통합하는 것처럼 안전하다고 느껴지는 절감 항목을 짚을 수 있었습니다. 명확해지니 정치적 마찰이 줄었고 신뢰도 쌓였습니다. 트리가 없었다면 아무도 서명하고 싶어 하지 않는 삭감 목록이 되었을 것입니다.

같은 방법은 더 모호한 요청에도 통합니다. 한 엔터프라이즈 소프트웨어 벤더가 저희에게 사우디 중견 시장을 위한 "지역 출시 전략"을 요청한 적이 있습니다. 저희는 일을 시장 수요, 경쟁 구도, 파트너 준비도로 나눴습니다. 파트너 준비도 아래에서 이 벤더의 리셀러 네트워크가 SAP S/4HANA Cloud 경험이 거의 없다는 사실을 발견했습니다. 시장이 아무리 매력적으로 보여도 이 걸림돌 때문에 실행이 멈췄을 것입니다. 구조 덕분에 캠페인 예산을 쓰기 전에 그것이 드러났습니다.

프레임워크는 바뀌지 않았습니다. 다른 두 가지가 바뀌었습니다.

초안이 싸졌습니다. Joule, ChatGPT, Claude는 이슈 트리나 가설 트리를 몇 초 만에 만들어 냅니다. 예전에는 첫 초안에 저녁 시간을 통째로 쓰던 주니어 컨설턴트가 이제는 30초 만에 초안을 만들고, 그 저녁을 모델이 못 하는 일에 씁니다. 구조가 문제에 맞는지 검증하고, 모델이 놓친 것을 찾고, 프롬프트에 깔린 가정에 도전하는 일입니다.

판단의 프리미엄은 커졌습니다. 누구나 MECE 분해를 만들어 낼 수 있게 되자, 질문은 "문제를 분해했는가"가 아니게 됩니다. "고객이 말한 문제가 사실은 다른 문제라는 것을 알아챘는가, 모델이 기본값으로 받아들인 가정을 잡아냈는가"가 됩니다. 실제 프로젝트에서 판단력을 쌓은 컨설턴트는 2024년보다 더 큰 격차로 앞서 있습니다.

그래서 역량이 이동했습니다. 더 이상 "이슈 트리를 만들 수 있는가"가 아닙니다. "AI가 초안을 잡은 트리가 틀렸을 때 그것을 알아보고 고객 회의실에서 바로잡을 수 있는가"입니다.

커리어에서 자신의 위치를 가늠하고 있다면, SAPopedia의 커리어 경로가 컨설팅 트랙을 정리해 두었고, ERPCV 커리어 팩은 프레임워크를 나열하는 데 그치지 않고 이런 종류의 판단력을 이력서에 드러내도록 돕습니다.

해결책에서 시작하기. 문제를 프레이밍하기 전에 고객이나 컨설턴트가 이미 답을 정해 두고 있습니다. 분석이 확인 작업으로 바뀝니다.

구조가 지나침. 단순한 문제 중에는 MECE 분해가 아니라 직접적인 답이 어울리는 것이 있습니다. 구조를 쓰지 말아야 할 때를 아는 것도 쓰는 법을 아는 것만큼 중요합니다.

잘못된 깊이로 분해하기. 너무 일찍 너무 깊이 내려가는 트리는 마비를 낳습니다. 얕게 머무는 트리는 아무도 실행할 수 없는 권고안을 낳습니다. 깊이는 의사결정과 주어진 시간에 맞추십시오.

종합 없는 분석. 엄밀한 트리가 데이터 덤프로 끝납니다. 구조는 생각을 돕습니다. 권고안을 만드는 것은 판단입니다.

소통의 구조와 사고의 구조를 혼동하기. Barbara Minto의 피라미드 원칙처럼 결론부터 제시하는 것은 소통 기법입니다. 그 밑의 사고가 건전했는지는 말해 주지 않습니다. 나쁜 분석을 잘 전달해도 나쁜 분석입니다.

이것은 타고난 기질이 아니라 기술입니다. 연습으로 늘어납니다.

중요한 고객 대화가 끝날 때마다 다음을 적어 두십시오. 제가 이해한 문제, 분해한 구조, 가설, 그리고 그것을 검증할 증거입니다. 데이터를 보기 전에 하십시오. 글로 쓰면 머릿속으로만 생각할 때는 얻지 못하는 명료함이 생깁니다.

분석만이 아니라 종합도 연습하십시오. 쌓인 증거에서 방어할 수 있는 권고안 하나를 만드는 것이 더 어려운 절반입니다. 대부분의 주니어 컨설턴트는 분석은 무난하게 하지만 종합은 덜 발달해 있습니다. 그 격차가 다음 승진이 놓인 자리이고, 유행어를 걷어 내고 나면 컨설턴트가 실제로 하는 일의 큰 부분이기도 합니다.

컨설팅에서 구조적 사고란 무엇입니까?

복잡하고 모호한 문제를 부분으로 나누고, 각 부분을 순서대로 풀어 가고, 결과를 합쳐 명확한 권고안으로 만드는 일입니다. 어려운 문제를 다룰 수 있게 하고 추론 과정을 눈에 보이게 하므로, 고객이 결론을 믿고 받아들이는 대신 따라가고 반박할 수 있습니다.

주요 도구는 프레이밍 질문, 이슈 트리, MECE, 가설 중심 분석입니다. 어느 것도 판단을 대체하지 못합니다.

MECE는 무슨 뜻이고 어떻게 쓰입니까?

Mutually Exclusive, Collectively Exhaustive. 분해한 부분들은 서로 겹치지 않아야 하고, 합치면 문제 전체를 덮어야 합니다.

겹침 테스트: 하나의 항목이 두 가지에 들어갈 수 있는가? 빈틈 테스트: 모든 가지에 답했을 때 핵심 질문에도 답이 되는가? 이슈 트리를 만들 때 적용하십시오. 끝난 분석에 적용하면 대개 너무 늦습니다.

가설 중심 분석은 어떻게 작동합니까?

가장 가능성이 높은 답을 일찍 정하고, 그것을 확인하거나 반증할 증거를 나열한 다음, 검증하러 갑니다. 어디를 봐야 하는지 알려 주기 때문에 모든 것을 먼저 모으는 것보다 빠릅니다.

위험은 확증 편향입니다. 먼저 내가 틀렸음을 증명할 수 있는 증거를 찾으십시오.

컨설팅 문제를 올바르게 프레이밍하려면 어떻게 합니까?

어떤 의사결정을 내려야 하고 어떤 정보가 그것을 바꿀지 물으십시오. 그런 다음 고객의 문제 진술을 받아들이기 전에 검증하십시오.

고객이 "어떤 SAP 모듈을 먼저 구축해야 합니까?"라고 묻지만 실제로는 "지금이 SAP 프로그램을 시작할 적기인가?"를 결정하는 중일 수 있습니다. 프레이밍을 검증하지 않고 말로 던진 질문에만 답하면, 기술적으로는 맞지만 사업적으로는 틀린 분석이 나옵니다.

컨설팅에서 분석과 종합의 차이는 무엇입니까?

분석은 문제나 데이터 세트를 부분으로 나누어 이해하는 것입니다. 종합은 발견한 내용을 합쳐 권고안으로 만드는 것입니다.

가장 흔한 산출물의 실패는 분석은 많은데 종합이 없는 것입니다. 고객은 발견 사항 더미를 받지만, 컨설턴트를 고용한 이유인 질문에 대한 답은 받지 못합니다. 결론을 먼저 쓰면 종합이 일어나게 됩니다.

구조적 사고는 ERP 구축에 어떻게 적용됩니까?

프로그램 초반에는 실제 문제를 이해하기 전에 팀이 설정부터 시작하는 일을 막아 줍니다. "SAP가 필요합니다"라고 말하는 조직은 SAP가 더 선명하게 드러내기만 할 프로세스나 데이터 문제를 먼저 풀어야 할 수 있습니다.

Fit-Gap 작업에서는 업무 프로세스를 MECE로 분해하면 워크숍에서 거론된 프로세스만이 아니라 모든 프로세스가 검토됩니다. 어려움을 겪은 Go-Live 이후에는 의사결정(안정화, 복구, 교체)을 프레이밍하고 주된 원인에 대한 가설을 검증하면, 증상을 나열하는 것보다 방어 가능한 권고안에 더 빨리 이를 수 있습니다.