
DX의 70%는 첫 질문에서 결정된다 — 문제 정의와 비즈니스 이해의 기술
DX 프로젝트의 70%가 실패한다. GE의 68억 달러 Predix 참사부터 영국 NHS의 100억 파운드 IT 프로젝트 붕괴까지 — 원인은 기술이 아니라 '잘못된 질문'이었다. 아인슈타인에서 디자인 씽킹까지, 문제 정의 200년 계보와 2026년 AI 시대의 새로운 패러다임을 총정리한다.

DX 프로젝트의 70%가 실패한다. GE의 68억 달러 Predix 참사부터 영국 NHS의 100억 파운드 IT 프로젝트 붕괴까지 — 원인은 기술이 아니라 '잘못된 질문'이었다. 아인슈타인에서 디자인 씽킹까지, 문제 정의 200년 계보와 2026년 AI 시대의 새로운 패러다임을 총정리한다.
2015년, GE의 CEO 제프 이멜트(Jeff Immelt)는 자신만만하게 선언했다.
"GE는 세계 최고의 산업 인터넷 기업이 될 것이다."
GE 디지털은 산업 IoT 플랫폼 Predix에 70억 달러 이상을 쏟아부었다. CDO(최고디지털책임자) 빌 루(Bill Ruh)는 2020년까지 소프트웨어 사업에서 150억 달러 매출을 예측했다. 실리콘밸리에 대규모 개발 센터를 세우고, 수천 명의 소프트웨어 엔지니어를 채용하고, 자체 클라우드 데이터센터까지 구축했다.
결과는? 2020년 실제 소프트웨어 매출 — 약 12억 달러. 목표의 8%에 불과했다. GE 주가는 70% 넘게 폭락했고, 이멜트는 사임했으며, 2021년 GE는 결국 항공·전력·헬스케어 3개 회사로 해체되었다.
무엇이 잘못되었는가?
기술이 아니었다. 질문이 잘못되었다.
GE는 "최첨단 IoT 플랫폼을 어떻게 만들까?"를 물었다. 하지만 진짜 물었어야 할 질문은 이것이었다 — "고객이 지금 가장 돈이 새는 곳은 어디이며, 디지털로 그 출혈을 어떻게 막을 수 있는가?" GE는 고객의 구체적인 비즈니스 문제를 정의하기도 전에, "범용 산업 인터넷 플랫폼"이라는 거대한 답을 먼저 만들어버렸다.
이것이 디지털 전환(DX)의 70%가 실패하는 이유다. 기술이 부족해서가 아니라, 문제를 정의하지 않았기 때문이다. 피터 드러커(Peter Drucker)가 반세기 전에 경고한 것과 정확히 같다:
"가장 심각한 실수는 잘못된 답에서 나오지 않는다. 진정으로 위험한 것은 잘못된 질문을 던지는 것이다."
이 글은 DX 전문가 로드맵 10편 시리즈의 첫 번째 편이다. 왜 "문제 정의"가 DX의 70%를 결정하는지, 그 지적 계보를 1940년대부터 2026년까지 추적하고, 국내외 성공·실패 사례를 통해 실전 인사이트를 뽑아낸다.
문제 정의가 왜 이토록 중요한가를 가장 날카롭게 표현한 인용은 아인슈타인의 것이다:
"나에게 지구를 구할 1시간이 주어진다면, 55분은 문제를 정의하는 데 쓰고 5분은 답을 찾는 데 쓰겠다."
이 말이 실제로 아인슈타인이 한 것인지는 논쟁이 있지만, 핵심은 변하지 않는다. 문제를 제대로 정의하면, 답은 그 안에서 자연스럽게 드러난다. 반대로 문제를 잘못 정의하면, 아무리 정교한 답을 내놓아도 엉뚱한 방향으로 달려가게 된다.
이 직관은 학술적으로 어떻게 발전해 왔을까?
현대적 문제 정의의 기원은 독일 출신 사회심리학자 쿠르트 레빈(Kurt Lewin)으로 거슬러 올라간다. 레빈은 1943년 "Defining the 'Field at a given time'"이라는 논문에서 물리학의 장(場) 이론을 인간 행동에 적용했다.
그의 핵심 아이디어는 놀랍도록 단순했다:
모든 조직은 변화를 밀어붙이는 힘(기술 발전, 시장 변화, 경쟁 압박)과 변화를 막는 힘(관성, 비용, 두려움) 사이에서 균형을 이루고 있다. 변화를 일으키려면 추진력을 키우거나, 저항력을 줄이거나, 둘 다 해야 한다. 여기서 핵심은 — 지금의 균형 상태(As-Is)와 원하는 미래 상태(To-Be) 사이의 간극(gap)을 정확히 측정하는 것이다.
이 "간극 분석(Gap Analysis)"이라는 프레임은 이후 80년간 경영학의 기본 도구가 된다. DX에서 반복적으로 등장하는 As-Is / To-Be 분석의 지적 뿌리가 바로 여기에 있다.
1969년, 카네기멜론 대학교의 허버트 사이먼(Herbert A. Simon)은 MIT 출판사에서 『인공의 과학(The Sciences of the Artificial)』을 출간했다. 이 책은 인공지능, 인지과학, 경영학에 두루 영향을 미친 고전이 되었고, 사이먼은 이 연구 흐름으로 1978년 노벨 경제학상을 수상했다.
사이먼의 핵심 통찰은 "제한된 합리성(bounded rationality)"이다. 인간은 모든 정보를 처리하고 최적의 답을 찾는 초합리적 존재가 아니다. 인지적 한계와 환경의 구조라는 두 날의 가위에 끼어, 항상 "충분히 좋은(satisficing)" 답을 찾는다.
그렇다면 문제 해결의 본질은 무엇인가? 사이먼은 이렇게 정의했다:
"현재 상태를 바람직한 상태로 바꾸기 위한 행동의 경로를 고안하는 모든 사람은 설계를 하는 것이다."
이 정의가 DX에 갖는 함의는 심대하다. DX는 소프트웨어를 도입하는 것이 아니라, 현재 상태를 바람직한 상태로 바꾸는 행동 경로를 설계하는 것이다. 그리고 그 설계의 첫 단계는 "현재 상태"와 "바람직한 상태"를 정확하게 정의하는 것이다 — 즉 문제 정의다.
1973년, 버클리 대학교의 호르스트 리텔(Horst Rittel)과 멜빈 웨버(Melvin Webber)는 "일반 계획 이론의 딜레마(Dilemmas in a General Theory of Planning)"라는 논문을 발표했다. 이 논문이 정의한 "사악한 문제(wicked problem)" 개념은 오늘날 DX를 이해하는 데 결정적이다.
| 구분 | 순한 문제 (Tame Problem) | 사악한 문제 (Wicked Problem) |
|---|---|---|
| 문제 정의 | 명확하게 정의 가능 | 정의 자체가 문제의 일부 |
| 종료 조건 | "풀었다"를 알 수 있음 | 멈출 시점이 없음 |
| 정답 여부 | 맞다/틀리다로 판정 | 좋다/나쁘다의 스펙트럼 |
| 시행착오 | 실험 가능, 되돌리기 쉬움 | 모든 시도가 비가역적 |
| DX 예시 | 서버 마이그레이션 | 비즈니스 모델 전환 |
DX의 진짜 어려움은 대부분의 DX 과제가 사악한 문제라는 데 있다. "ERP를 도입하라"는 순한 문제처럼 보이지만, 실제로는 "수십 년간 쌓인 업무 관행을 어떻게 재설계할 것인가"라는 사악한 문제를 품고 있다. 문제의 정의 자체가 문제 해결의 가장 어려운 부분인 것이다.
1985년, 하버드 경영대학원의 마이클 포터(Michael Porter)는 『경쟁 우위(Competitive Advantage)』에서 가치사슬(Value Chain) 모델을 발표했다. 같은 해 HBR 논문 "정보가 경쟁 우위를 주는 방법(How Information Gives You Competitive Advantage)"에서는 이미 IT와 가치사슬의 관계를 분석했다(이 논문은 5,200회 이상 인용되었다).
가치사슬이 DX 문제 정의에 중요한 이유는 명확하다. 비즈니스를 활동 단위로 분해해야, "어디에 디지털 기술을 적용할 것인가"를 구체적으로 물을 수 있기 때문이다. "DX를 하겠다"는 답이 없는 추상적 선언이다. "출하 물류 단계에서 평균 3일 걸리는 배송 리드타임을 디지털로 1일로 줄이겠다"는 실행 가능한 문제 정의다.
1992년, 하버드 경영대학원의 로버트 캐플란(Robert Kaplan)과 컨설턴트 데이비드 노턴(David Norton)은 HBR에 "성과를 이끄는 측정(The Balanced Scorecard: Measures That Drive Performance)"을 발표했다.
핵심 문제의식: 재무 지표만으로는 비즈니스의 건강 상태를 알 수 없다. 매출과 이익이 좋아도, 고객이 이탈하고 있거나, 내부 프로세스가 비효율적이거나, 학습·혁신이 정체되어 있다면 미래는 어둡다.
BSC는 DX의 KPI 설계에 직접적으로 적용된다. "AI를 도입해서 매출을 올리겠다"는 재무 관점만 보는 편향된 목표다. BSC는 묻는다 — 고객 관점에서 어떤 가치가 개선되는가? 내부 프로세스의 어떤 병목이 해소되는가? 조직의 어떤 역량이 성장하는가? 이 4가지 관점이 정렬되지 않은 DX는 재무 성과도 만들어내지 못한다.
1996년 시작되어 2000년 완성된 CRISP-DM(Cross-Industry Standard Process for Data Mining)은 데이터 프로젝트의 표준 방법론이다. EU ESPRIT 프로젝트로 Teradata, Daimler AG, NCR 등이 컨소시엄을 이루어 만들었다.
주목할 점은 1단계가 "비즈니스 이해"라는 것이다. 데이터를 모으기 전에, 모델을 설계하기 전에, 비즈니스가 무엇을 필요로 하는지를 이해하라. 이것은 1996년에 이미 데이터 분석 실무자들이 현장에서 깨달은 교훈이었다 — 프로젝트가 실패하는 이유는 알고리즘이 아니라, 비즈니스 문제를 잘못 정의했기 때문이다.
2003년, IDEO의 CEO 팀 브라운(Tim Brown)이 IDEO의 방법론을 "디자인 씽킹(Design Thinking)"이라고 명명했다. 2004년, 스탠포드 대학교의 데이비드 켈리(David Kelley)가 하소 플래트너 디자인 연구소(d.school)를 설립했다. 2008년, 팀 브라운의 HBR 논문 "Design Thinking"이 발표되면서 이 개념은 글로벌 비즈니스 세계로 폭발적으로 확산되었다.
d.school이 정립한 5단계 프로세스는 이렇다:
여기서 핵심은 첫 두 단계다. "공감"은 사무실에서 상상하는 것이 아니라 현장에 나가 사용자의 경험 속으로 들어가는 것이고, "정의"는 그 관찰에서 진짜 풀어야 할 문제를 추출하는 것이다. 디자인 씽킹이 DX에 가져온 결정적 전환은 이것이다 — 문제 정의의 출발점을 "기술"에서 "사람"으로 옮겨놓았다.
문제 정의의 가장 기초적인 도구는 As-Is / To-Be 분석이다. "지금 어디에 있고(As-Is), 어디로 가고 싶은가(To-Be), 그 사이의 간극(Gap)은 무엇인가"를 측정하는 것이다.
단순해 보이지만, 현장에서는 As-Is조차 정확히 파악하지 못하는 경우가 대부분이다.
2025년 글로벌 컨설팅 기업 Accenture가 한 다국적 기업의 구매 프로세스를 프로세스 마이닝으로 분석한 결과는 충격적이었다. 50개국에 걸쳐 운영되는 이 기업에서, 하나의 구매 요청이 처리되는 경로가 무려 14,000가지나 되었다. 경영진은 표준 프로세스가 있다고 믿었지만, 현실은 14,000개의 변종이 뒤엉킨 카오스였다.
프로세스 마이닝으로 이 현실을 "발굴(discover)"한 뒤, 프로세스를 표준화하자 사이클 타임이 75% 단축되어 평균 15시간으로 줄었다.
이 사례가 말해주는 것: "우리는 우리의 프로세스를 안다"는 가정 자체가 위험하다. As-Is 분석은 "이미 아는 것을 적는 것"이 아니라, "몰랐던 현실을 발굴하는 것"이어야 한다.
현대자동차는 울산 공장의 DX를 추진하면서, "스마트 팩토리를 만들겠다"는 추상적 목표 대신 구체적인 생산 문제를 정의하는 데서 출발했다. 차종 변경 시 생산라인 전환에 소요되는 시간, 용접 품질 편차, 부품 재고 과잉 — 각각의 As-Is를 데이터로 측정하고, 구체적인 To-Be 목표를 수치로 설정했다.
현대자동차 싱가포르 혁신센터(HMGICS)는 이 접근의 집약체다. 로봇과 AI 비전 시스템으로 차체 조립 공정을 자동화하되, 그 출발점은 "어떤 공정에서 얼마만큼의 비효율이 발생하는가"라는 구체적 문제 측정이었다.
독일 Siemens의 암베르크(Amberg) 공장은 "디지털 팩토리"의 교과서적 사례로 꼽힌다. 이 공장의 DX 출발점은 기술이 아니라, "제품 불량률을 어디까지 줄일 수 있는가"라는 단 하나의 질문이었다. As-Is 분석으로 공정별 불량 발생 지점을 데이터로 매핑하고, 각 지점에 IoT 센서와 AI 품질 검사를 투입했다. 결과적으로 불량률은 0.001% 이하 — 100만 개 중 11.5개 — 에 도달했다. 제품 당 생산량은 20년 전과 같은 인원으로 14배 증가했다.
마이클 포터가 1985년 제시한 가치사슬은 40년이 지난 2026년에도 DX의 기본 분석 도구다. 하지만 적용 방식은 근본적으로 달라졌다.
1985년의 가치사슬에서 "기술개발"은 지원 활동이었다. 2026년의 가치사슬에서 디지털 기술은 모든 본원 활동과 지원 활동을 관통한다. 구매 물류에 AI 수요예측이, 운영에 디지털 트윈이, 마케팅에 개인화 엔진이, 서비스에 챗봇이 들어간다.
DX 문제 정의에서 가치사슬의 역할은 이것이다 — "우리 비즈니스의 어느 활동에서 가장 큰 가치가 새고 있는가?"를 구조적으로 분석하는 지도.
쿠팡은 2010년 소셜커머스(공동구매) 사이트로 시작했다. 하버드를 중퇴한 김범석 대표가 고객 불만 데이터를 분석했을 때, 전체 불만의 50%가 배송에 관한 것이었다. 이 데이터가 문제를 재정의했다:
"더 좋은 딜을 어떻게 만들까?" ❌ → "한국 이커머스 물류를 어떻게 100배 더 좋게 만들 수 있는가?" ✅
이 질문이 모든 것을 결정했다. 쿠팡은 가치사슬의 출하 물류 단계에 집중했다. 전국에 자체 물류센터 네트워크를 구축하고, AI 기반 수요예측으로 고객이 주문하기 전에 미리 가까운 물류센터에 상품을 배치하는 "로켓배송" 시스템을 만들었다. 배송 직원도 외주가 아닌 직접 고용("쿠팡친구")으로 라스트마일을 통제했다.
결과:
핵심은 쿠팡이 "기술 회사"가 아니라 "물류 문제를 디지털로 재정의한 회사"라는 점이다. "배송 불만이 50%"라는 데이터에서 출발한 문제 정의가 78조 원의 가치를 만들어낸 것이다.
스페인 인디텍스(Inditex)의 Zara는 패션 산업의 가치사슬을 근본적으로 재설계한 사례다.
전통 패션 브랜드의 문제 정의: "어떻게 좋은 디자인을 만들까?" Zara 창업자 아만시오 오르테가의 문제 정의: "패션은 부패하는 정보 문제다 — 실제 소비자 수요에 가까울수록 낭비가 줄어든다."
이 질문의 차이가 산업을 바꿨다:
| 지표 | Zara | 업계 평균 |
|---|---|---|
| 디자인→매장 사이클 | 2~3주 | 3~6개월 |
| 시즌 전 사전 생산 비율 | 15~39% | 80~90% |
| 연간 컬렉션 수 | ~20 마이크로 컬렉션 | 2 시즌 |
| 미판매 재고율 | ~10% | 17~20% |
| 유럽 내 생산 비율 | 50% 이상 | 대부분 아시아 저비용 국가 |
매장 매니저가 매일 판매량, 고객 요청, 트렌드를 본사 디자이너에게 직접 보고한다. RFID를 업계 최초로 도입하여 공장부터 매장 피팅룸까지 모든 의류를 실시간 추적한다. 2020년 글로벌 공급망 혼란 때, 경쟁사들이 허둥대는 동안 Zara의 재고는 9%만 감소했다.
Zara의 가치사슬 DX는 가장 근본적인 질문에서 출발한다 — "이 산업에서 시간이 가치인가, 디자인이 가치인가?" Zara는 "시간"이라고 답했고, 그 답에 맞춰 전체 가치사슬을 재설계했다.
피터 드러커의 또 다른 격언, "측정할 수 없으면 관리할 수 없다(If you can't measure it, you can't manage it)."
DX에서 KPI(핵심 성과 지표)가 중요한 이유는 분명하다. DX의 성공/실패를 판단할 기준이 없으면, 아무도 DX가 성공했는지 알 수 없다. 그런데 여기에 함정이 있다. 잘못된 KPI는 잘못된 행동을 유도한다.
| 구분 | 선행 지표 (Leading) | 후행 지표 (Lagging) |
|---|---|---|
| 정의 | 미래 성과를 예측 | 이미 발생한 결과를 측정 |
| 시점 | 현재 행동 → 미래 결과 | 과거 결과 → 현재 보고 |
| DX 예시 | 직원 시스템 채택률, 데이터 품질 점수 | 매출 증가율, ROI |
| 활용 | 방향 수정 가능 (조종대) | 결과 확인만 가능 (백미러) |
많은 DX 프로젝트가 후행 지표(ROI, 매출)만 설정하고 선행 지표를 무시한다. "DX로 매출 20% 증가"라는 KPI를 세우고 1년 뒤에 확인해보면 이미 늦다. 매출은 수십 가지 변수의 결과지, 조종할 수 있는 입력이 아니기 때문이다.
올바른 DX KPI 설계는 선행 지표와 후행 지표를 함께 설정한다:
도미노 피자의 디지털 전환은 KPI 재정의의 교과서적 사례다.
2008년, 도미노의 주가는 약 3달러. 포커스 그룹에서 "피자가 골판지 맛이 난다"는 조롱이 나올 정도였다. 2010년 취임한 CEO 패트릭 도일(Patrick Doyle)은 피자 레시피를 전면 교체하는 동시에, 놀라운 문제 재정의를 했다:
"도미노는 피자를 배달하는 기술 회사다."
2011년, 도일은 IT팀에 이런 과제를 던졌다: "신호가 바뀌는 17초 안에 스마트폰으로 피자를 주문할 수 있게 만들어라." 이 문제 정의가 DX의 방향을 완전히 바꿨다. 도미노는 피자 레시피가 아니라 주문 경험 전체를 디지털화했다. Domino's Tracker(주문 추적), AnyWare 플랫폼(Amazon Echo, Apple Watch, Google Home, Twitter 이모지, Facebook Messenger, 삼성 스마트TV에서 주문), Zero Click(앱 열면 자동 주문) — 모든 혁신은 "주문 경험의 마찰을 줄인다"는 단일 문제에서 파생되었다.
KPI도 달라졌다. "피자 판매량"(후행 지표) 대신, "디지털 채널 주문 비율"(선행 지표)을 핵심으로 설정했다. 이 비율이 올라갈수록 주문 효율이 높아지고, 고객 데이터가 쌓이고, 개인화가 가능해진다는 인과관계를 설계한 것이다.
결과:
이 통계는 2018년 맥킨지(McKinsey)에서 나왔다. 맥킨지는 1,793명의 경영진을 대상으로 설문 조사를 실시했고, "대규모 변혁을 추진할 때, 약 70%의 확률로 실패한다"는 결론을 도출했다. 같은 해 BCG도 825명의 임원을 대상으로 한 연구에서 "DX 이니셔티브의 30%만이 목표 달성과 지속 가능한 변화를 동시에 이뤄냈다"고 보고했다.
더 충격적인 숫자가 있다. 글로벌 기업들이 DX에 투자한 1.3조 달러 중 약 9,000억 달러가 낭비되었다는 추산이다.
그렇다면 실패한 70%의 공통점은 무엇인가?
영국 국민보건서비스(NHS)의 국가 IT 프로그램(NPfIT)은 역사상 가장 값비싼 IT 실패 중 하나다.
NHS NPfIT의 교훈은 잔인할 정도로 명확하다:
"아키텍처가 설계되고 구축된 이후에야, 이것을 어떻게 사용할 것인지에 대한 명확성이 필요하다는 사실이 인식되었다."
이것은 문제 정의의 가장 치명적인 반전이다 — 답을 먼저 만들고 나서 질문을 찾는 것. 62억 파운드짜리 "답"을 먼저 만들었지만, 의료진이 실제로 필요로 하는 것이 무엇인지는 한 번도 제대로 물어본 적이 없었다.
들어가며에서 언급한 GE Predix의 실패를 구조적으로 분석해 보자.
| 실패 요인 | GE가 한 것 | 해야 했던 것 |
|---|---|---|
| 문제 정의 | "범용 산업 IoT 플랫폼 구축" | "고객 산업별 구체적 비용 절감 문제 정의" |
| 고객 정의 | 내부(GE 사업부) + 외부 동시 타겟 | 핵심 고객 세그먼트 집중 |
| 경쟁 전략 | 자체 클라우드로 AWS/Azure와 경쟁 | 기존 클라우드 위에서 산업 특화 가치 제공 |
| KPI | 분기별 소프트웨어 매출 | 고객 문제 해결율, 채택률 |
| 조직 문화 | 제조업 문화로 소프트웨어 개발 | 별도 조직으로 독립적 실험 |
GE의 근본적 문제는 "우리가 만들 수 있는 것"에서 출발했지, "고객이 해결해야 할 문제"에서 출발하지 않은 것이다. 이것은 기술 중심 DX의 전형적 패턴이다.
2016년, 포드(Ford)는 Ford Smart Mobility LLC라는 별도 자회사를 디트로이트가 아닌 실리콘밸리에 설립하고, 차량 공유 스타트업 Chariot를 6,500만 달러에 인수했다. "모빌리티 서비스" 기업으로의 전환을 선언한 것이다.
결과: 2017년 Ford Smart Mobility 부문 손실 3억 달러. 2018년 Chariot의 뉴욕 셔틀 서비스에서 밴 25대가 하루에 운송한 총 승객은 약 1,000명 — 밴 1대당 하루 9명. 2019년 1월 Chariot 완전 폐업, 6,500만 달러 전액 손실. 같은 해 Pivotal Software 투자에서도 1.81억 달러 손실.
포드의 실패 원인: "자동차 회사 옆에 기술 스타트업을 어떻게 세울까?"라고 물었지, "핵심 자동차 비즈니스를 어떻게 디지털로 진화시킬까?"라고 묻지 않았다. DX를 핵심 사업과 분리된 별도 프로젝트로 정의한 것 자체가 실패의 시작이었다.
한국 기업의 DX 실패도 같은 패턴을 보인다.
AI를 도입한 기업에서도 "변화 없음"이 우세한 응답이라는 2025년 조사 결과는 시사하는 바가 크다. 글로벌 통계도 암울하다 — Bain & Company 2024년 보고서에 따르면, 88%의 비즈니스 변혁이 원래 목표 달성에 실패한다. ERP 구현의 경우 Gartner 기준 75% 이상이 목표를 달성하지 못하며, 평균 비용 초과율은 215%에 달한다.
가장 흔한 실패 패턴:
싱가포르의 DBS 은행은 세계에서 가장 성공적인 DX 사례 중 하나로 꼽힌다. 2014년, CEO 피유시 굽타(Piyush Gupta)는 잭 마(Jack Ma)와의 만남에서 핀테크 파괴의 위기를 직감했다. 그가 정의한 문제는 기존 은행의 DX 접근법과 완전히 달랐다:
"DBS를 GANDALF(Google, Amazon, Netflix, DBS, Apple, LinkedIn, Facebook) 속의 D로 만들려면 무엇이 달라져야 하는가?"
내부 슬로건은 "26,000명으로 구성된 스타트업이 되자"였다. 이 문제 정의가 이끌어낸 전략:
결과는 압도적이었다:
| 지표 | 디지털 고객 | 전통 고객 |
|---|---|---|
| ROE (자기자본이익률) | 27% | 18% |
| 수익 | 2배 | 기준 |
| 획득 비용 | 57% 낮음 | 기준 |
| 셀프서비스 거래 | 16배 | 기준 |
DBS의 교훈: 문제를 "어떤 기술을 도입할까"가 아닌 "어떤 조직이 되어야 하는가"로 정의했을 때, DX는 기술 프로젝트가 아닌 비즈니스 변혁이 된다.
포스코는 한국 제조업 DX의 대표 성공 사례다. 2019년 7월, 한국 기업 최초로 세계경제포럼(WEF) "글로벌 등대 공장(Lighthouse Factory)"에 선정되었다. 4차 산업혁명 기술 리더십을 인정받은 것이다.
포스코의 문제 정의는 기술이 아닌 제철 프로세스의 구체적 병목에서 시작했다.
핵심 문제 정의: "고로(용광로)의 온도 변동을 줄여 용선 품질을 안정화하고, 원료 투입 최적화로 비용을 절감할 수 있는가?"
이 문제는 수치로 정의할 수 있었기에, 수치로 측정할 수 있었다:
AI가 카메라, 온도, 장입 성분을 실시간 분석하여 송풍량과 연료 공급을 자동 조절한다. 도금 공정은 이제 완전 AI 제어로 운영된다.
포스코의 교훈: "AI를 도입하겠다"가 아니라 "고로 온도 편차를 줄이고 일일 용선을 240톤 더 뽑겠다"는 구체적 문제 정의가 2,500억 원의 성과를 만들었다.
스타벅스의 문제 재정의: "스타벅스는 커피를 파는 데이터 회사다."
2017년 "Digital Flywheel" 전략은 리워드, 개인화, 모바일 주문, 결제를 하나의 연속적 피드백 루프로 통합했다. 2019년 출시된 AI 플랫폼 Deep Brew는 이를 노동 스케줄링과 설비 유지보수까지 확장했다.
스타벅스가 정의한 문제: "매장별로 다른 고객 패턴에 맞춰, 각 고객에게 가장 적합한 음료를 추천하고, 각 매장의 재고를 최적화할 수 있는가?"
이 문제는 두 가지 하위 문제로 분해된다:
결과:
2026년 현재, 전 세계 기업들이 AI에 쏟아붓는 투자는 천문학적이다. IDC는 2026년 글로벌 DX 투자를 3.4조 달러로 전망하고, Gartner는 전 세계 IT 지출이 사상 처음 6.15조 달러를 돌파할 것으로 예측했다.
한국도 예외가 아니다:
그런데 맥킨지 2025년 AI 보고서가 전하는 현실은 냉혹하다:
"대부분의 기업은 AI에서 실패하는 것이 아니라, AI가 어떤 문제를 풀어야 하는지를 이해하지 못한 채 실패한다."
88%의 기업이 AI를 활용하지만, 실제로 EBIT(세전 영업이익)의 5% 이상을 AI에서 창출하는 "AI 고성과 기업"은 전체의 6%에 불과하다. 기업의 21%만이 GenAI 도입 시 실질적인 워크플로 재설계를 수행하고, 나머지 79%는 기존 프로세스 위에 AI를 덧씌우는 데 그친다.
결국 2026년에도 핵심은 같다. "AI로 뭘 할까?"가 아니라 "이 비용/시간을 어떻게 줄일까?"
2025년 6월, 전 Tesla AI 디렉터이자 OpenAI 공동창업자인 안드레이 카르파시(Andrej Karpathy)가 흥미로운 개념을 제시했다:
"Context engineering은 다음 단계에 딱 맞는 정보로 컨텍스트 윈도우를 채우는 섬세한 기술이자 과학이다."
카르파시는 "프롬프트 엔지니어링(prompt engineering)"이라는 용어가 너무 좁다고 지적했다. 산업 수준의 LLM 애플리케이션에서 진짜 중요한 것은 짧은 지시문을 잘 쓰는 것이 아니라, AI가 올바른 판단을 내릴 수 있도록 적절한 맥락을 구성하는 것이다.
이것은 DX 문제 정의와 본질적으로 같은 구조다:
| 구분 | Context Engineering | DX 문제 정의 |
|---|---|---|
| 핵심 질문 | "AI에게 어떤 맥락을 줘야 하는가?" | "어떤 비즈니스 문제를 풀어야 하는가?" |
| 실패 원인 | 잘못된 맥락 → 잘못된 AI 출력 | 잘못된 문제 정의 → 잘못된 DX 방향 |
| 핵심 역량 | 도메인 지식 + 기술 이해 | 비즈니스 이해 + 기술 이해 |
| 공통 본질 | 올바른 질문을 구성하는 능력 |
Cognizant는 향후 1년간 1,000명의 Context Engineer를 배치하겠다고 발표했다. Fortune 500 기업들이 이 역할을 "도메인 지식 + 기능 이해 + 기술 구현을 결합하는 전문 역량"으로 인식하기 시작한 것이다.
2026년의 DX 전문가는 곧 Context Engineer다. 비즈니스 문제를 정확히 이해하고, 그 문제를 AI가 풀 수 있는 형태로 구조화하는 사람.
전통적으로 문제 정의는 인터뷰, 워크숍, 현장 관찰로 이루어졌다. 2026년에는 여기에 강력한 도구가 추가되었다 — 프로세스 마이닝(Process Mining).
프로세스 마이닝은 ERP, CRM 등 시스템의 이벤트 로그를 분석하여, 실제 업무가 어떻게 흘러가는지를 데이터로 시각화하는 기술이다. "사람들이 이렇게 일한다고 생각하는 것"과 "실제로 이렇게 일하고 있는 것" 사이의 간극을 드러낸다.
대표적 성과 사례:
프로세스 마이닝의 혁명적인 점: 문제를 "추측"하는 것에서 "발굴"하는 것으로 전환된다. 경영진의 직관이나 현장 인터뷰에 의존하지 않고, 데이터가 스스로 병목과 비효율을 드러낸다.
2026년의 DX 전문가가 활용할 수 있는 현대적 문제 정의 프레임워크를 정리한다.
① Jobs-to-be-Done (JTBD) — 클레이튼 크리스텐슨
하버드 경영대학원의 클레이튼 크리스텐슨(Clayton Christensen)이 정립한 JTBD 이론의 핵심: 고객은 제품을 "구매"하는 것이 아니라 "고용(hire)"한다. 고객의 인구통계학적 속성이 아니라, "고객이 달성하려는 진전(progress)이 무엇인가?"에 집중한다.
DX 적용: "ERP를 도입하자"가 아니라, "우리 구매팀이 달성하려는 진전은 무엇이며, 현재 그것을 가로막는 것은 무엇인가?"
② Double Diamond — 영국 디자인 카운슬
4단계 프로세스: 발견(Discover) → 정의(Define) → 개발(Develop) → 전달(Deliver). 첫 번째 다이아몬드(발견+정의)에서 넓게 탐색한 뒤 진짜 문제를 좁히고, 두 번째 다이아몬드(개발+전달)에서 해결책을 넓게 탐색한 뒤 최적의 답을 좁힌다.
DX 적용: DX 기획 단계에서 성급하게 솔루션에 뛰어들지 말고, 첫 번째 다이아몬드에 충분한 시간을 투자하라.
③ Working Backwards — 아마존
아마존의 방법론: 제품을 만들기 전에 보도자료(PR)와 FAQ를 먼저 작성한다. "이 제품이 출시되었을 때 고객에게 어떤 가치를 주는가?"를 강제로 먼저 정의한다.
DX 적용: DX 프로젝트 킥오프 전에, "이 프로젝트가 성공했을 때 내부 보도자료는 어떻게 작성될 것인가?"를 먼저 쓴다. 그 보도자료를 쓸 수 없다면, 문제 정의가 아직 안 된 것이다.
이 글에서 추적한 200년의 계보를 한 장으로 정리한다.
200년간 학자, 경영자, 엔지니어들이 반복적으로 도달한 같은 결론:
문제를 정의하는 능력이 문제를 해결하는 능력보다 중요하다.
그리고 DX에서 이 원칙은 더욱 극단적으로 작용한다. GE는 70억 달러를, NHS는 100억 파운드를, 전 세계 기업들은 매년 9,000억 달러를 "잘못된 질문에 대한 정교한 답"을 만드는 데 쏟아붓고 있다.
2026년의 DX 전문가에게 필요한 첫 번째 근육은 코딩이 아니고, AI 모델 튜닝이 아니고, 클라우드 아키텍처가 아니다. 올바른 질문을 던지는 힘이다.
"AI로 뭘 할까?" ❌
"이 비용/시간을 어떻게 줄일 수 있을까?" ✅
"DX를 추진하겠다" ❌
"배송 리드타임 3일을 1일로 줄이겠다" ✅
"ERP를 도입하겠다" ❌
"구매 요청에서 결제까지 14,000개 경로를 3개로 표준화하겠다" ✅
다음 편에서는 이렇게 정의된 문제를 프로세스와 시스템으로 설계하는 방법 — DX의 두 번째 축, "프로세스 & 시스템 설계"를 다룬다.
① 문제 정의 & 비즈니스 이해 ← 현재 글 ② 프로세스 & 시스템 설계 ③ 데이터 구조 이해 ④ AI/ML 이해 (예정) ⑤ 시스템 아키텍처 (예정) ⑥ 클라우드 & 인프라 (예정) ⑦ 자동화 & 운영 (예정) ⑧ UX / 사용자 경험 설계 (예정) ⑨ 산업 도메인 이해 (예정) ⑩ 실행 전략 (예정)