하이브리드씽킹의 3단계 문제해결공식

모든 문제해결은 3단계다: Discover–Develop–Deliver

Feb 17. 2026

문제를 해결한다는 말은 흔하지만, 사실 문제는 그렇게 쉽게 “해결”되지 않습니다.

새로운 제품을 만들고, 조직을 바꾸고, 정책을 설계하고, 고객을 설득하는 일은 늘 예외와 변수가 따라옵니다. 분야가 다르다고 해서 구조가 달라지는 것도 아닙니다. 오히려 저는 일을 오래 해볼수록 반대로 느낍니다. 겉으로는 서로 다른 언어를 쓰는 것처럼 보여도, 문제 해결의 골격은 놀라울 정도로 비슷하다는 사실을요.

컨설팅 업계에서는 논리 기반의 단계적 프로세스를 중요하게 여깁니다. 반면 혁신과 창업, 디자인과 UX 분야에서는 사람의 경험을 관찰하고 실험하는 접근을 강조합니다. 출발점은 분명 다릅니다. 하나는 분석을, 다른 하나는 공감을 말합니다. 그런데 조금만 깊이 들여다보면 두 방식 모두 결국 같은 흐름을 반복합니다.

문제를 발견하고(Discover), 해법을 만들고(Develop), 실행해 현실에 심는(Deliver).

이 세 단계는 유행하는 프레임이 아니라, 인간이 문제를 다루는 가장 자연스러운 순서에 가깝습니다.

Discover: “정확히 무엇이 문제인가?”

문제 해결은 대부분 여기서 이미 승패가 갈립니다.
우리는 종종 문제를 너무 빨리 “해결”하려고 합니다. 하지만 많은 경우 해결해야 할 것은 문제 자체가 아니라, 문제를 바라보는 방식입니다.

예를 들어 이런 장면은 익숙합니다.
한 조직이 “매출이 줄었다”고 말합니다. 그러면 사람들은 곧바로 가격 정책을 손보고, 광고를 늘리고, 영업 인력을 투입합니다. 그런데 시간이 지나도 매출은 돌아오지 않습니다. 이유는 단순합니다. 매출 감소는 문제의 이름이지, 문제의 정체가 아니기 때문입니다.

진짜 문제는 다른 곳에 있을 수 있습니다. 고객이 떠난 이유가 가격이 아니라 신뢰일 수도 있고, 경쟁사의 등장보다 내부 서비스 품질 붕괴가 원인일 수도 있습니다. 또는 제품이 아니라 채널이 문제일 수도 있고, 브랜드가 아니라 경험이 문제일 수도 있습니다.

Discover는 바로 그 정체를 찾아내는 단계입니다.
이 단계에서 중요한 건 “많이 아는 것”이 아니라, “잘 묻는 것”입니다.

저는 Discover를 설명할 때 종종 의학의 진단 과정을 떠올립니다.
같은 두통이라도 원인이 스트레스인지, 수면 부족인지, 혈압인지, 뇌혈관인지에 따라 치료가 완전히 달라집니다. 환자가 “머리가 아파요”라고 말하는 순간, 의사는 곧바로 처방전을 쓰지 않습니다. 질문을 하고, 관찰을 하고, 필요한 검사를 통해 문제를 재정의합니다.

문제 해결도 같습니다.
Discover는 ‘정답’을 찾는 단계가 아니라, 올바른 질문을 만드는 단계입니다.

Develop: “그렇다면 어떻게 해결할 것인가?”

문제가 제대로 정의되면, 이제는 해법을 만드는 시간입니다.
Develop는 많은 사람들이 문제 해결이라고 부르는 영역이기도 합니다.

하지만 이 단계에서도 중요한 오해가 하나 있습니다.
해법은 언제나 논리적으로 “계산”되는 것이 아니라는 점입니다.

물론 어떤 문제는 분석으로 풀립니다. 예를 들어 기업이 새로운 사업을 검토할 때, 시장 규모와 성장률, 경쟁 구도, 수익성, 투자 회수 기간 등을 모델링해야 합니다. 이런 영역에서는 가설을 세우고 데이터를 검증하며 최적안을 도출하는 방식이 효과적입니다.

그런데 또 다른 종류의 문제는 분석만으로는 나오지 않습니다.
사람이 움직이는 문제, 경험이 바뀌어야 하는 문제, 의미가 설계되어야 하는 문제는 대개 실험을 필요로 합니다.

저는 Develop의 본질을 보여주는 사례로 “라이트 형제”를 자주 떠올립니다.
비행기의 원리는 이미 많은 과학자들이 연구하고 있었습니다. 하지만 하늘을 나는 기계는 여전히 불가능에 가까웠습니다. 라이트 형제가 특별했던 것은 더 똑똑한 수식을 가지고 있어서가 아니라, 실패를 반복할 수 있는 실험 구조를 스스로 만들었다는 점입니다. 그들은 작은 글라이더를 만들고, 풍동 실험을 하고, 날개 형상을 바꾸며 수없이 반복했습니다.

Develop는 결국 이런 단계입니다.
한 번의 아이디어로 끝나는 것이 아니라, 해법이 만들어질 때까지 계속 다듬는 과정입니다. 그래서 이 단계는 언제나 조금 지저분합니다. 그리고 그 지저분함을 견디는 것이 혁신의 본질입니다.

Deliver: “현실에서 작동하게 하려면 무엇이 필요한가?”

좋은 아이디어는 생각보다 흔합니다.
문제는 그것이 현실에서 작동하지 않는다는 데 있습니다.

Deliver는 바로 그 지점에서 시작됩니다.
이 단계의 질문은 단순합니다. “이게 실제로 돌아가게 하려면 무엇이 필요한가?”

여기에는 실행의 모든 요소가 들어옵니다. 사람, 예산, 제도, 시스템, KPI, 인센티브, 커뮤니케이션, 그리고 조직 내부의 저항까지.

Deliver의 중요성을 보여주는 대표적인 사례로 저는 넷플릭스보다 “코닥”을 떠올립니다.
코닥은 디지털 카메라 기술을 일찍부터 알고 있었습니다. 심지어 내부에서 관련 기술을 개발하기도 했습니다. 그런데도 디지털 전환에 실패했습니다. 기술이 없어서가 아니라, Deliver가 불가능했기 때문입니다. 기존 필름 사업의 수익 구조, 유통망, 조직 문화, 성과 평가 방식이 디지털로의 이동을 가로막았습니다.

즉, Deliver는 단순히 배포하는 단계가 아닙니다.
현실의 힘과 조직의 관성을 상대하는 단계입니다.

많은 프로젝트가 여기서 무너집니다.
Discover와 Develop는 멋지게 했는데, Deliver에서 “현장 적용”이 안 되는 순간, 그 모든 노력은 보고서 한 권으로 남습니다.

방법론은 달라도, 결국 구조는 같다

사람들은 종종 “논리적 사고”와 “디자인 사고”를 대립시키곤 합니다. 하나는 숫자와 분석, 다른 하나는 공감과 창의. 마치 서로 다른 세계처럼 보입니다.

하지만 저는 이 둘이 싸우는 것이 아니라, 같은 구조를 다른 언어로 말한다고 생각합니다. 논리적 사고는 Discover에서 구조를 잡고, Develop에서 가설을 검증하며, Deliver에서 실행 계획을 심습니다. 디자인 사고는 Discover에서 사람을 관찰하고, Develop에서 아이디어를 실험하며, Deliver에서 테스트와 개선을 반복합니다.