데이터·AI 프로젝트를 들여다보면 자주 나오는 질문이 있습니다.
“기술과 도구도 갖췄고 사람도 뽑았는데, 왜 결과가 의도와 다르게 흘러가는 걸까요?”
이 질문이 시리즈를 시작하는 출발점입니다. 데이터 통합 전략(Unifying Data Strategy) 시리즈의 첫 편이며, ‘진단’ 단계를 다룹니다.
시리즈는 다음 흐름으로 풀립니다.
- 진단을 통해 정렬되지 않은 곳을 식별하고,
- 정렬에 기초해 합의를 만드는 도구를 만들어 내고,
- 설계에서 데이터를 자기 완결성을 갖춘 객체로 다듬고,
- 조직의 합의를 시스템화 합니다.
1편은 그 가운데 진단 단계를 다룹니다.
1. IT 프로젝트의 80%가 제대로 굴러가지 않는 이유
RAND가 2024년에 발표한 연구에 따르면 기업 AI 프로젝트의 80%가 비즈니스 가치를 만들지 못한 채 끝납니다. 이는 전통적인 IT 프로젝트 실패율의 두 배에 해당하는 숫자입니다.
같은 흐름을 다른 자료에서도 확인할 수 있습니다. 가트너는 2024년 발표에서 생성형 AI(GenAI) 프로젝트의 30%가 PoC 단계 이후 폐기될 것이라 예측했고, 폐기 사유 1위로 데이터 품질·리스크 통제 부재를 짚었습니다. 가트너의 2026년 4월 I&O 조사에서는 AI 프로젝트 가운데 28%만 ROI를 충족했고, 20%는 완전히 실패한 것으로 집계됐습니다. Quest가 2025년에 정리한 분석에서도 조사 대상의 37%가 데이터 품질을 전략적 데이터 활용의 가장 큰 장애로 꼽았습니다.
이 숫자들의 원인을 데이터 부족이나 모델 성능에서 찾기 쉽습니다. 그러나 위 보고서들은 다른 결론으로 모입니다. 비즈니스 팀과 데이터 팀이 같은 단어로 서로 다른 얘기를 하고 있고, 그 사실을 인식하지 못한다는 점입니다. 데이터 통합 전략은 그 인식부터 시작합니다.
30년이 지나도 변하지 않는 통계
IT 프로젝트 전체가 30년간 비슷한 패턴을 반복해 왔습니다. 스탠디시 그룹의 카오스 리포트(Standish CHAOS Report)는 1994년 이후 IT 프로젝트의 성공·지연·실패 비율을 추적해 왔습니다. 30년동안 추적한 프로젝트 성공 여부에 의하면, 성공률은 16%(1994년)에서 31%(2020년) 사이를 오갑니다. 대형 프로젝트의 성공률은 9% 미만으로 떨어진 시기도 있습니다.
| 시기 | 데이터 출처 | 성공 | 지연·예산 초과(Challenged) | 실패 |
|---|---|---|---|---|
| 1994년 | Standish CHAOS | 16% | 53% | 31% |
| 2012년 | Standish CHAOS | 37% | 42% | 21% |
| 2020년 | Standish CHAOS | 31% | 50% | 19% |
| 2024년 (AI) | RAND, Gartner | 약 20% | 약 50% | 약 30% |
표의 “지연·예산 초과(Challenged)”는 카오스 리포트가 쓰는 분류로, 결과는 나왔지만 일정·예산·범위가 의도와 다르게 흐른 프로젝트를 가리킵니다. 본문에서 “프로젝트가 잘 안 풀린다”는 표현이 가리키는 경우도 비슷합니다. 완전히 죽은 것은 아니지만, 처음 그렸던 결과와 다르게 흘러간 프로젝트입니다.
30년이 지났는데도 본질이 바뀌지 않은 이유는 한 가지로 모입니다. 기술이 부족해서가 아닙니다. 사람과 소통의 문제이기 때문입니다.
클라우드로 옮겨도, 워터폴을 애자일로 바꿔도, 데이터 웨어하우스를 데이터 레이크하우스로 갈아치워도, 같은 단어를 서로 다르게 쓰는 두 팀이 만나면 결과는 비슷하게 흐릅니다. AI 시대에는 이 패턴이 더 진하게 나옵니다. 모델이 학습 데이터에 의존하는 정도가 커질수록, 정렬되지 않은 정의 하나가 모델 출력 전체를 흔듭니다.
2. 손 위생이 의학의 토대가 되기까지
이그나츠 제멜바이스(Ignaz Semmelweis)는 ‘손씻기’ 하나로 산모 사망률을 극적으로 낮춘 19세기 의사입니다. 당시 의학계는 의사들의 손이 더럽다는 주장은 의사라는 직업에 대한 모욕으로 받아들여, 그의 주장에 대해 격렬하게 반대했었습니다. 이로 인해 손씻기가 의학의 토대로 자리잡기까지 그 후로도 오랜 시간이 더 걸렸습니다.
데이터 위생(Data Hygiene)도 같은 흐름을 따릅니다.
- 핵심 어휘의 정의를 맞추고,
- 도메인 지식을 문서화하고,
- 자기 평가에 다른 시각을 더하는 일입니다.
그러나 단순하기 때문에 무시되기 쉽습니다. 모델 아키텍처를 새로 짜거나 벡터 데이터베이스를 도입하는 등의 일들이 단순히 ‘더 멋있어 보이기’ 때문입니다. AI 시대에는 이 토대의 부재가 더 큰 비용으로 돌아옵니다. 모델 복잡도가 올라갈수록, 정렬되지 않은 정의 하나가 만들어내는 분산된 결과물의 영향이 무지막지하게 커지기 때문입니다.
3. 데이터 위생을 무너뜨리는 세 가지 위협
진단의 첫 단계는 정렬되지 않은 곳을 가려낼 ‘어휘’를 잡아 데이터 위생은 높이는 것입니다. 데이터 위생에 위협을 가하는 것은 대표적으로 세 가지, 모호성·지식 격차·맹점입니다. 셋은 서로 겹치기도 하지만, 진단 단계에서는 분리해서 보는 게 효과적입니다.
| 위협 | 정의 | 증상 | 사례 | 해소 방향 |
|---|---|---|---|---|
| 모호성 | 같은 단어, 다른 의미 | “우리는 합의했어요”라고 말하지만 결과물이 매번 다름 | “고객” 정의가 부서마다 다름 | 핵심 어휘의 공통 정의를 명시 |
| 지식 격차 | 필요한 정보가 누락 | 외부 데이터 컬럼명을 해석 못 함 | cust_segment_v3이 무엇인지 모름 | 도메인 지식의 문서화·접근 보장 |
| 맹점 | 위 둘이 있다는 인식 자체가 없음 | “우리 데이터 품질 좋아요” 같은 자신감 | 자기 평가가 진단을 막음 | 외부 시각·구조화된 진단 절차 |
1) 모호성: 같은 단어, 다른 의미
모호성(Ambiguity)은 같은 단어가 사람마다 다른 의미로 해석되는 상태를 가리킵니다. 가장 자주 등장하는 사례는 “고객(customer)”이라는 단어입니다.
┌─────────────────────────────────────────┐
│ "아, 고객에 대한 것들이 필요하군!" │
└─────────────────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
[영업팀] [마케팅팀] [CS팀]
┌─────┐ ┌─────┐ ┌─────┐
│ ■ │ │ ● │ │ ▲ │
│계약자 │ │잠재고객│ │사용자│
└─────┘ └─────┘ └─────┘
같은 합의 아래에서 세 사람이 서로 다른 정의를 머리에 그리고 있음같은 “고객”이라는 단어를 부서마다 다르게 씁니다.
- 영업팀: 계약서에 사인한 사람
- 마케팅팀: 캠페인 내 잠재 고객
- CS팀: 지금 이 순간 제품을 쓰고 있는 사람
세 정의 모두 틀리지 않습니다. 문제는 회의실에서 “고객 데이터를 정비합시다”라고 말할 때 일어납니다. 세 사람은 같은 합의를 한 줄 알고 회의를 마치지만, 실제로는 서로 다른 데이터셋을 머릿속에 그리고 있습니다. 데이터 파이프라인을 만들고 모델을 학습시키는 단계에 가서야 그 차이가 드러납니다.
모호성이 생기는 메커니즘은 암묵지(tribal knowledge, 내부 지식)입니다. 공식 문서에 정의가 빠진 빈칸을 각 팀 내부에서 통하는 암묵적 합의가 메웁니다. TDAN이 정리한 자료에 따르면 코로나 이후 96%의 회사가 암묵지에 의한 손실을 경험했습니다. Cohevo가 2026년에 짚은 분석은 도구 분산이 암묵지를 파편화하여 키운다는 점을 짚습니다. 슬랙·노션·지라·컨플루언스·구글 드라이브로 정보가 흩어질수록, 한 사람의 머릿속에만 살아 있는 정의가 늘어납니다.
세 모양 사이의 차이를 보지 못하는 상태가 맹점입니다. 그 차이를 보았지만 왜 모양이 다른지 설명할 자료가 없는 상태가 지식 격차입니다. 차이를 보고 설명할 수 있지만 합의가 없는 상태가 모호성입니다. 진단의 첫 작업은 이 셋 가운데 우리 조직이 어디에 머물러 있는지를 가려내는 일입니다.
2) 지식 격차: 알아야 할 정보가 누락된 상태
지식 격차(Knowledge gaps)는 의사결정에 필요한 정보가 누락되어 문제 해결을 가로막는 상태입니다. 모호성이 “정의가 여러 개”인 문제라면, 지식 격차는 “정의가 없는” 문제입니다.
분석가가 외부 파트너에게서 받은 데이터의 컬럼명을 해석할 수 없는 상황과도 같습니다. cust_segment_v3이라는 컬럼이 무엇을 뜻하는지, 1·2·3이라는 값이 어떻게 매겨지는지, 누가 언제 그 정의를 정했는지를 알아낼 자료가 없습니다. 분석가는 메일로 묻고, 답이 늦으면 짐작으로 채웁니다. 이 짐작이 누적되면 분석 결과는 더 이상 데이터를 반영하지 않습니다.
지식 격차가 가장 잘 누적되는 영역은 “당연히 알 것”이라고 가정되는 영역입니다. 마이크로소프트에 의하면, 전문 역량(advanced skills) 투자에 의해 IT 사일로가 오히려 강화되는 메커니즘을 짚습니다. 한쪽 팀의 전문성이 깊어질수록, 그 팀이 쓰는 약어와 가정이 다른 팀에는 점점 더 닫힌 영역이 됩니다.
3) 맹점: 정렬되지 않았다는 사실 자체를 모름
맹점(Blind spots)은 모호성·지식 격차가 있다는 인식 자체가 없는 상태입니다. 진단 단계에서 가장 위험한 상태입니다.
“우리 데이터 품질 좋은데?”라고 자신 있게 답하는 리더를 떠올려 보세요. 회의실에서 “우리 팀은 정렬되어 있어요”라는 자기 평가가 나오는 경우도 비슷합니다. 두 답에 공통된 점은 한 가지입니다. 답하는 사람은 정렬되지 않은 곳이 어디인지 보지 못한다는 것입니다. 모호성과 지식 격차는 발견되는 순간 풀 수 있지만, 맹점은 발견 자체를 가로막습니다.
다음 다이어그램은 세 위협이 한 회의실 안에서 어떻게 작동하는지를 보여줍니다. 합의 위에 한 단어가 적혀 있지만, 그 아래에 사람마다 서로 다른 모양의 정의가 들어 있는 그림입니다.
4. 데이터 통합 전략은 어디에서 시작되는가
데이터 통합 전략은 다음 질문에서 출발합니다.
최대의 비즈니스 가치를 창출하는, 데이터를 둘러싼 최소한의 공동의 노력은 무엇인가?
이 질문은 일반적인 데이터 전략과는 출발점부터 다릅니다.
많은 데이터 전략은 특정 기술과 아키텍처를 중심으로 시작합니다. 어떤 데이터 플랫폼을 도입할지, 어떤 AI 모델을 붙일지, 어떤 데이터베이스를 선택할지를 먼저 논의합니다. 그러나 데이터 통합 전략은 기술보다 먼저 조직의 정렬 상태를 봅니다. 대부분의 실패는 기술 부족보다 방향의 불일치에서 시작되기 때문입니다.
기술은 속도를 높여주지만, 방향 자체를 맞춰주지는 못합니다. 정렬되지 않은 상태에서의 가속은 진전이 아니라 혼란의 확대에 가깝습니다. 잘못된 방향으로 더 빨리 움직이는 조직은 더 빠르게 피로해지고, 더 많은 데이터를 쌓고도 더 적은 신뢰를 얻게 됩니다.
데이터 통합 전략이 말하는 “최소한의 공동의 노력”은 거대한 전사 혁신을 뜻하지 않습니다.
모든 시스템을 하나로 통합하거나, 완벽한 데이터 거버넌스를 먼저 구축하는 일이 아닙니다. 오히려 그 이전 단계에 가깝습니다. 조직이 최소한 같은 목표와 같은 해석 기준 위에서 움직일 수 있는 상태를 만드는 일입니다.
데이터 통합 전략이 일반적인 데이터 전략과 구분되는 지점은 세 가지입니다.
첫째, 특정 기술이나 도구를 먼저 처방하지 않습니다.
기술은 방향이 정해진 뒤에 선택되는 수단입니다. 방향이 불분명한 상태에서의 기술 도입은 문제 해결보다 혼란의 확산으로 이어지는 경우가 많습니다.
둘째, 총체적 관점(holistic perspective)을 요구합니다.
데이터 문제를 기술 문제만으로 분리해서 보지 않습니다. 사람·프로세스·기술이 서로 어떤 방식으로 연결되어 있는지를 함께 봅니다. 조직의 데이터 문제는 대부분 하나의 계층에서만 발생하지 않기 때문입니다.
셋째, 공통 언어와 일하는 방식의 정렬을 도구의 도입보다 우선합니다.
데이터 통합 전략은 “무엇을 도입할 것인가”보다 먼저 “우리는 같은 방향을 보고 있는가”를 묻습니다. 같은 방향 없이 도입된 기술은 조직 전체를 연결하기보다, 기존의 혼란을 더 빠르게 증폭시키기 쉽습니다.
가속 페달을 밟기 전에 사람을 정렬시키는 일, 그것이 데이터 통합 전략의 출발점입니다.
5. 정렬과 통합의 차이
진단 단계에서 가장 자주 헷갈리는 두 어휘가 정렬(Aligning)과 통합(Unifying)입니다. 시리즈 전체에서 두 단어는 자주 등장하므로, 여기서 한 번 구분하는 것이 좋습니다.
| 축 | 정렬(Aligning) | 통합(Unifying) |
|---|---|---|
| 정의 | 공통 목표를 향해 움직임을 맞춤 | 사람·프로세스·기술까지 미세 조정 |
| 범위 | 사람·합의 | 사람·합의·시스템·문화 |
| 만들어지는 도구 | 회의·OKR·KPI | 거버넌스·프로세스·도구 |
| 요구하는 태도 | 협력 | 자기 비판·편향 인정·겸손함 |
| 실무에서의 신호 | “우리는 같은 목표를 본다” | “우리가 무엇을 모르는지 안다” |
| 결과 | 일회성 합의 | 반복 가능한 합의 |
정렬은 공통 목표를 향해 일관된 전략으로 움직이도록 보장하는 일입니다. 각자 다른 영역에서 다른 일을 하지만 같은 방향을 보고 있는 상태입니다. 회의·OKR·KPI 합의·정기 동기화 같은 도구로 만들어집니다. 정렬은 정적인 상태가 아니라 지속적인 재평가와 조정이 들어가는 동적인 과정입니다.
통합은 정렬보다 한 단계 더 깊은 차원입니다. 사람뿐 아니라 프로세스와 기술까지 함께 미세 조정하여 일관성있는 과정을 마련한 것입니다. 그렇기 때문에 단순히 회의로만 만들어질 수 없습니다. 시스템·프로세스·문화로 만들어집니다. 통합은 정렬과 달리 자기 비판·편향 인정·겸손함을 요구합니다.
6. 문제가 가진 문제: 솔루션부터 파고드는 함정
진단 단계에서 자주 마주치는 또 한 가지 함정이 있습니다. 리더가 “우리는 무슨 문제를 풀고 있는가”보다 “어떤 도구를 도입할 것인가”부터 정해놓는 모습입니다. 이 함정을 데이터 통합 전략에서는 ‘탑다운 사고의 함정’이라 부릅니다.
탑다운식 접근은 ‘풀어야 할 문제가 분명할 때’ 효과적입니다. “우리는 분기 매출 예측의 정확도를 90%까지 끌어올린다”처럼 목표가 잡혀 있을 때 탑다운으로 자원을 집중하면 결과가 나옵니다.
그러나 문제 자체가 불분명할 때 탑다운으로 해결하기 시작하면 잘못된 방향으로 더 빨리 갈 뿐입니다. “Y라는 문제를 해결하려면 기술 X가 필요하다”는 발상이 들어가면, 실제 문제가 X로 풀리지 않는 종류였다는 사실은 한참 뒤에 드러납니다.
바텀업 접근은 정반대 방향에서 시작합니다. 데이터·운영·개념을 함께 살피며 진짜 문제가 어디에 있는지를 찾아냅니다. 비즈니스 프로세스 모델링·인터뷰·관찰·프로토타이핑 같은 도구가 바텀업식 접근에 속합니다. 바텀업은 시간이 더 걸리지만, 문제 자체가 흐린 상황에서 탑다운식 접근보다 유용합니다.
다음 다이어그램은 두 흐름이 개념·데이터·운영 세 계층을 어떻게 오가는지를 보여줍니다.
┌─────────────────┐
탑다운(활용) ▼ │ 개념(Concept) │
├─────────────────┤
│ 데이터(Data) │
├─────────────────┤
│ 운영(Operation) │ ▲ 바텀업(탐색)
└─────────────────┘
탑다운: 개념(목표·전략) → 데이터 → 운영으로 내려옴 (활용)
바텀업: 운영(현장·증상) → 데이터 → 개념으로 올라감 (탐색)탑다운과 바텀업은 어느 한쪽이 옳은 게 아니라, 문제의 단계에 따라 달라집니다.
| 상황 | 어느 쪽이 맞는가 | 이유 |
|---|---|---|
| 풀어야 할 문제가 분명함 | 탑다운(활용) | 자원 집중으로 빠르게 결과를 만들 수 있음 |
| 문제 자체가 흐림 | 바텀업(탐색) | 진짜 문제를 찾는 단계가 먼저 필요 |
| 도구·기술이 잡혀 있음 | 탑다운 | 정해진 도구를 적용하는 단계 |
| 도구·기술도 미정 | 바텀업 | 도구 선정에 정보가 더 필요 |
| 단기 KPI 압박 | 탑다운으로 보이지만, 보텀업이 필요한 영역이 자주 섞임 | 압박이 진단을 건너뛰게 만듦 |
데이터에 대한 정렬와 통합이 제대로 되어있지 않은 조직의 경우, 문제 자체가 정의되지 않은 경우일 확률이 큽니다. 그렇기 때문에, 면밀하고 문제가 무엇인지를 파악하고 이 모호함을 구조화할 사람이 필요합니다.
7. 데이터 챔피언, 진단을 적극적으로 수행하는 사람
데이터 통합 전략은 진단을 책임지고 실행할 역할에 데이터 챔피언(Data Champion)을 둡니다. 직책이라기보다 행동 패턴에 가까운 정의입니다.
데이터 챔피언은 데이터가 사일로를 가로질러 어떻게 흐르는지를 볼 수 있는 사람입니다. 한 부서의 정의가 다른 부서로 옮겨갈 때 무엇이 변하는지를 추적하고, 모호성·지식 격차·맹점이 생기는 곳을 짚어냅니다.
줌인은 비즈니스 프로세스 모델링·데이터 모델링·SQL 쿼리 검토 같은 기술적 대화입니다. 줌아웃은 재무 KPI 설정·팀 협업 설계·로드맵 우선순위 같은 전략적 대화입니다. 두 대화를 오가야 정렬되지 않은 곳이 보입니다. 한쪽에만 머물면 다른 쪽이 보이지 않습니다.
데이터 챔피언이 직책이 아니라 행동 패턴이라는 점이 중요합니다. 회사가 새 직책을 만들기를 기다릴 필요가 없습니다. 사일로를 가로질러 데이터 흐름을 보고, 정렬되지 않은 어휘를 짚어내고, 줌인과 줌아웃을 오가며 대화를 이끌어가는 행동이 곧 데이터 챔피언의 시작입니다.
8. 데이터 챔피언, 진단을 적극적으로 수행하는 사람
데이터 통합 전략은 진단을 책임지고 실행할 역할에 데이터 챔피언(Data Champion)을 둡니다. 그러나 이는 특정 직책이라기보다 조직 안에서 반복적으로 나타나는 행동 패턴에 가깝습니다.
1) ‘지정’한다고 해서 되는 것이 아닌 데이터 챔피언
중요한 점은, 데이터 챔피언을 “새로운 조직”으로 이해하면 안 된다는 것입니다. 많은 회사가 데이터 문제를 해결하려 할 때 가장 먼저 전담 조직부터 만듭니다. 데이터 혁신 TF를 만들고, 거버넌스 조직을 신설하고, CDO 조직을 확대합니다. 물론 일정 규모 이상에서는 이런 구조가 필요합니다. 그러나 대부분의 조직은 구조보다 먼저 “누가 연결 역할을 하는가”가 비어 있습니다.
실제 데이터 거버넌스 사례들을 보면 성공적인 조직은 처음부터 거대한 중앙 조직으로 시작하지 않습니다. 기존 조직 안에서 현업과 기술을 연결할 수 있는 사람들을 먼저 식별하고, 이들을 중심으로 점진적으로 네트워크를 형성합니다. 최근 데이터 거버넌스가 중앙집중형보다 연합형 거버넌스(federated governance) 구조를 강조하는 이유도 여기에 있습니다. 데이터 문제는 중앙 조직 하나만으로 해결되지 않기 때문입니다.
2) 데이터 챔피언의 특징
데이터 챔피언은 보통 다음 특징을 가진 사람들 가운데 등장합니다.
- 특정 부서의 데이터 흐름을 실제로 이해하고 있는 사람
- 기술 조직과 현업 조직 모두와 대화가 가능한 사람
- 회의에서 정의 충돌을 그냥 넘기지 않는 사람
- “왜 숫자가 다르지?”를 집요하게 추적하는 사람
- 공식 문서보다 실제 업무 흐름의 차이를 더 잘 아는 사람
- 여러 조직 사이에서 반복적으로 질문을 받는 사람
흥미로운 점은, 이런 사람들은 직급과 무관하게 나타난다는 것입니다.
시니어 데이터 엔지니어일 수도 있고, 운영 PM일 수도 있으며, 재무 분석가일 수도 있습니다. 중요한 것은 전문 분야보다 “조직 간 번역 능력”입니다. 실제 데이터 거버넌스 프레임워크에서도 데이터 스튜어드(Data Steward)나 데이터 오너(Data Owner)를 새로 채용하기보다 기존 역할에 책임(accountability)을 부여하는 방식이 반복적으로 등장합니다.
그래서 데이터 챔피언은 임명보다 발견에 가깝습니다. 조직 안에는 이미 데이터 챔피언 역할을 수행하고 있는 사람들이 있습니다. 다만 대부분 공식적으로 인정되지 않았을 뿐입니다. 데이터 통합 전략에서 중요한 것은 그 사람들을 식별하고 연결하는 일입니다.
3) 데이터 챔피언의 주요 역할
실무에서는 보통 다음 방식으로 시작됩니다.
첫 번째는 “정의 충돌이 반복적으로 발생하는 영역”을 찾는 것입니다.
예를 들어 고객·매출·활성 사용자처럼 부서마다 해석이 자주 갈리는 개념들이 있습니다. 이 영역에서는 이미 누군가가 비공식적으로 정의를 조율하고 있을 가능성이 높습니다. 데이터 챔피언은 대개 이런 영역에서 먼저 발견됩니다.
두 번째는 “반복적으로 병목이 되는 회의”를 보는 것입니다.
특정 회의에서 항상 같은 사람이 “이 KPI 정의가 팀마다 다른데요” 혹은 “이 숫자는 어느 기준인가요?” 같은 질문을 던진다면, 그 사람은 이미 데이터 챔피언 역할을 수행하고 있는 경우가 많습니다.
세 번째는 “조직 간 이동 경험”입니다.
현업과 데이터 조직을 모두 경험한 사람들은 의미 체계의 차이를 더 쉽게 발견합니다. 최근 분석 엔지니어(Analytics Engineer) 역할이 중요해진 이유도 비슷합니다. SQL만 잘 쓰는 사람이 아니라, 비즈니스 의미와 데이터 구조를 함께 연결할 수 있는 역할이 필요해졌기 때문입니다.
그래서 데이터 챔피언은 “데이터를 관리하는 사람”이라기보다 조직 안의 의미 충돌을 가장 먼저 발견하는 사람에 가깝습니다. 데이터 통합 전략에서 진단은 데이터를 점검하는 일이 아닙니다. 조직 안에서 서로 다른 의미 체계가 어디에서 충돌하고 있는지를 발견하는 과정입니다.
데이터 챔피언은 그 충돌을 조직이 볼 수 있도록 드러내는 사람입니다.
이 과정에서 필요한 것이 줌인(zoom-in)과 줌아웃(zoom-out)을 오가는 시야입니다.
- 줌인은 데이터 모델링·SQL 검토·데이터 계보(lineage)·파이프라인 구조처럼 실제 데이터 흐름을 깊게 들여다보는 능력입니다.
- 줌아웃은 KPI·조직 구조·로드맵 우선순위·성과 체계 같은 비즈니스 맥락을 함께 보는 능력입니다.
현실의 데이터 문제는 대부분 이 둘 사이에서 발생합니다.
대시보드 숫자가 맞지 않는 이유가 SQL 오류 때문이 아니라 서로 다른 KPI 정의 때문인 경우가 있습니다. 데이터 품질 문제가 실제로는 조직 간 책임 회피 문제인 경우도 있습니다. 기술만 봐서는 원인이 보이지 않고, 조직만 봐서도 구조가 보이지 않습니다.
그래서 데이터 챔피언은 단순 기술 전문가와도 다르고, 단순 PM과도 다릅니다. 이들은 조직 안의 의미 체계가 어떻게 충돌하는지를 추적합니다. 서로 다른 팀이 어디에서 같은 단어를 다르게 쓰는지, 어떤 정의가 암묵지로만 남아 있는지, 어떤 지표가 실제로는 서로 다른 의사결정을 동시에 만족시키려 하고 있는지를 발견합니다.
회의 중 “우리가 같은 의미로 말하고 있는가?”를 확인하는 사람, 지표 정의를 문서화하기 시작하는 사람, 조직 간 KPI 차이를 그냥 넘기지 않는 사람이 데이터 챔피언의 시작입니다. 최근 데이터 거버넌스가 중앙 통제보다 크로스펑셔널(cross-functional) 협업 구조를 강조하는 이유도 같은 맥락입니다. 데이터 문제는 단일 조직만으로 해결되지 않기 때문입니다.
데이터 통합 전략에서 진단은 데이터를 점검하는 일이 아닙니다. 조직 안에서 의미가 충돌하는 지점을 발견하는 일입니다. 데이터 챔피언은 그 충돌을 가장 먼저 보고, 조직이 그것을 보도록 만드는 사람입니다.
마무리
데이터·AI 프로젝트가 반복적으로 같은 문제를 겪는 이유는 생각보다 단순할 수 있습니다. 조직이 같은 데이터를 보고 있으면서도, 서로 다른 의미 체계 위에서 움직이고 있기 때문입니다.
기술은 계속 발전했습니다. 클라우드가 등장했고, 생성형 AI가 조직 안으로 들어왔습니다. 그러나 프로젝트 실패의 패턴은 크게 달라지지 않았습니다. 이는 문제의 중심이 기술 부족이 아니라 정렬 부족에 있다는 점을 보여줍니다.
데이터 통합 전략은 바로 그 지점에서 출발합니다. 새로운 플랫폼을 도입하기 전에, 조직이 같은 방향을 보고 있는가를 먼저 묻습니다. 더 많은 데이터를 연결하기 전에, 무엇을 같은 의미로 이해하고 있는가를 확인합니다. 진단 단계의 목적은 완벽한 답을 만드는 데 있지 않습니다. 조직 안에서 정렬되지 않은 지점을 발견하고, 그것을 드러낼 공통의 어휘를 확보하는 데 있습니다.
이 단계는 느리고 비효율적으로 보일 수 있습니다. 정의 충돌을 하나씩 드러내고, 암묵지를 문서화하며, 서로 다른 팀의 관점을 조율하는 일은 새로운 AI 모델을 붙이는 일보다 덜 화려해 보입니다. 그러나 실제로는 이 과정이 이후 모든 데이터·AI 전략의 방향을 결정합니다.
정렬되지 않은 조직에서의 기술 가속은 진전이 아니라 혼란의 확대에 가까워집니다. 그래서 데이터 통합 전략은 기술보다 먼저 사람과 의미 체계를 바라봅니다. 같은 목표를 향해 움직이고 있는지, 같은 단어를 같은 의미로 쓰고 있는지, 서로 다른 조직 사이에 어떤 해석 충돌이 숨어 있는지를 먼저 진단합니다.
다음 단계는 이 진단 결과를 실제 합의 구조로 바꾸는 일입니다. 합의는 선언만으로 유지되지 않습니다. 반복 가능한 도구와 구조가 필요합니다. 2편에서는 정렬되지 않은 조직이 어떻게 공통 언어를 만들고, 서로 다른 관점을 하나의 의사결정 체계 안으로 연결할 수 있는지를 다룹니다.
통합 데이터 전략 시리즈
(1) ‘진단’: 우리 조직은 어디가 정렬되지 않았는가