AI Sparkup

복잡한 AI 세상을 읽는 힘

AI 프로젝트 실패의 진짜 원인: 데이터 품질이 아닌 데이터 신뢰성

2025년까지 생성형 AI 프로젝트의 30%가 개념증명(PoC) 단계를 넘지 못할 것이라는 가트너(Gartner)의 예측이 현실이 되고 있습니다. 더 놀라운 사실은 일반적인 IT 프로젝트 실패율이 40% 정도인 반면, AI 프로젝트는 80%라는 두 배 높은 실패율을 보인다는 점입니다.

많은 조직이 이런 실패의 원인을 데이터 품질 문제로 진단하지만, 실제로는 더 근본적인 문제가 숨어있다는 주장이 제기되고 있습니다. 바로 데이터 신뢰성(Data Reliability)의 부재입니다.

20년간 데이터 품질을 관리했는데도 왜 실패할까?

데이터 품질 관리는 이미 20년 넘게 많은 기업의 핵심 과제였습니다. 그런데도 왜 AI 프로젝트는 계속 실패하고 있을까요?

iceDQ의 CEO인 산데시 가완데(Sandesh Gawande)는 2025년 데이터 엔지니어링 서밋에서 흥미로운 관점을 제시했습니다. 그는 “문제는 데이터 품질을 측정하지 않는 것이 아니라, 너무 늦게 측정한다는 것“이라고 지적했습니다.

대부분의 조직은 데이터 파이프라인이 이미 운영된 후, 대시보드를 통해 정확도 부족이나 누락된 값, 일관성 문제를 발견합니다. 하지만 그때는 이미 손상이 발생한 상태입니다. 마치 자동차가 공장에서 완전히 조립된 후에야 공장 장비가 제대로 보정되었는지 확인하는 것과 같습니다.

사후 대응의 위험성: 실제 사례로 보는 교훈

TSB 은행 IT 장애 사례

이런 사후 대응 방식의 위험성은 실제 사례를 통해 극명하게 드러납니다.

TSB Bank의 IT 대참사(2018년)는 대표적인 예입니다. 데이터 테스트를 충분히 하지 않은 상태로 새로운 IT 플랫폼으로 마이그레이션을 진행했다가, 연쇄적인 품질 문제가 발생했습니다. 결과적으로 £48.65백만(약 700억원)의 벌금과 £330백만(약 4,700억원)의 직접적 손실을 입었습니다. 더욱 충격적인 것은 프로젝트를 담당한 CIO가 개인적으로도 벌금을 받았다는 점입니다.

항공업계도 마찬가지입니다. 타이탄 잠수함은 운항 깊이에 대한 인증을 받지 않은 채 운항하다가 폭발했고, 보잉 항공기는 비행 중 기내 문이 떨어져 나가는 사고가 발생했습니다. 두 사례 모두 시스템이 이미 가동된 후에야 모니터링을 시작했다는 공통점이 있습니다.

데이터 팩토리 모델: 3단계 접근법

가완데는 데이터 파이프라인을 “데이터 팩토리”에 비유하며, 다음 3단계로 구분했습니다:

  1. 시스템 구축 단계: 파이프라인 설계 및 개발
  2. 프로세스 실행 단계: 다양한 소스에서 데이터 유입 및 처리
  3. 결과물 검사 단계: 최종 데이터 품질 확인

현재 대부분의 조직은 3번째 단계에만 집중하고 있습니다. 하지만 이는 배가 이미 침몰하기 시작한 후에 경고음을 울리는 것과 같습니다. 그때는 위기 관리만이 유일한 선택지가 됩니다.

품질 vs 신뢰성: 시간 축의 차이

데이터 품질과 신뢰성의 차이

그렇다면 데이터 품질과 데이터 신뢰성은 어떻게 다를까요?

데이터 품질은 특정 시점에서의 상태를 의미합니다. 현재 데이터가 정확하고 완전하며 일관성이 있는지를 판단하는 것입니다.

반면 데이터 신뢰성은 시간의 연속성 관점에서 접근합니다. 품질 좋은 데이터를 일관되게, 지속적으로 제공할 수 있는 능력을 의미합니다.

가완데는 이를 전장에서의 검 비유로 설명했습니다. “두 번만 휘두르면 부러지는 고품질 검과 절대 부러지지 않는 신뢰할 수 있는 검 중 어느 것을 선택하겠습니까?” 검이 테스트에서는 훌륭해 보였지만 실전에서 부러진다면 사용자를 배신하는 것입니다. 취약한 데이터 파이프라인도 마찬가지입니다.

데이터 신뢰성 엔지니어링(DRE): 사전 예방의 핵심

데이터 신뢰성을 확보하기 위해서는 데이터 신뢰성 엔지니어링(Data Reliability Engineering, DRE) 접근법이 필요합니다.

개발 단계부터의 예방적 접근

놀랍게도 연구 결과에 따르면:

  • 80%의 데이터 결함은 개발 단계에서 예방 가능
  • 15%는 운영 단계에서 예방 가능
  • 단 5%만이 기존의 사후 품질 검사로 발견

이는 개발 단계에서 다음과 같은 질문들을 던져야 함을 의미합니다:

  • 파이프라인이 실행되기 전에 테스트되었는가?
  • 개발자들이 단위 테스트, 통합 테스트, 적절한 버전 관리를 수행하고 있는가?
  • 데이터 문제로 나타나기 전에 프로세스 실패를 감지할 수 있는 도구가 시스템에 내장되어 있는가?

운영 단계의 실시간 모니터링

두 번째 단계는 운영 중 실시간 모니터링입니다. 여기서는 다음과 같은 일반적인 운영 함정들을 방지해야 합니다:

  • 파이프라인이 두 번 실행되거나 아예 실행되지 않는 경우
  • 빈 파일이 경고 없이 로드되는 경우
  • 스키마 변경이나 잘못된 형식의 파일이 감지되지 않는 경우

조직 문화의 변화가 필요한 이유

DRE 구현은 단순히 기술적 문제가 아닙니다. 조직 문화의 근본적 변화가 필요합니다.

품질 보증팀의 역할 확장

기존에 UI 테스트에만 집중했던 품질 보증팀은 파이프라인 로직 검증, 입력 데이터 무결성 확인, 초기 구축 단계에서의 모니터링을 학습해야 합니다.

비즈니스 사용자의 참여

비즈니스 사용자들도 “주문 없이는 제품을 출하할 수 없다”와 같은 비즈니스 룰을 정의하고, 이런 룰이 워크플로우에 직접 내장되도록 해야 합니다. 시스템은 이런 비즈니스 룰이 위반될 때 자동으로 중단되도록 설계되어야 합니다.

관리층의 지원

무엇보다 관리층이 건전한 엔지니어링 관행을 장려하고, 비즈니스 사용자, 개발자, 테스터, 데이터 파이프라인 엔지니어들을 교육하는 문화적 변화를 이끌어야 합니다.

실천을 위한 구체적 방법

가완데는 바가바드 기타의 교훈을 인용하며 “프로세스에 집중하면 결과는 따라온다”고 강조했습니다. 신뢰할 수 있는 데이터를 위해서는 사람, 프로세스, 도구가 처음부터 정렬되어야 합니다.

“나쁜 품질은 우연이지만, 신뢰할 수 있는 품질은 설계에 의한 것입니다.”

이를 위해 조직은 다음과 같은 실천 방안을 고려해야 합니다:

개발 단계에서의 실천 방안:

  • 데이터 파이프라인에 대한 단위 테스트 및 통합 테스트 의무화
  • 코드 리뷰 시 데이터 품질 검증 로직 포함 여부 확인
  • 파이프라인 배포 전 데이터 품질 게이트 설정

운영 단계에서의 실천 방안:

  • 실시간 데이터 흐름 모니터링 시스템 구축
  • 스키마 변경 감지 및 알림 시스템 구현
  • 데이터 이상 감지 시 자동 롤백 메커니즘 구축

마무리: AI 성공을 위한 새로운 패러다임

AI 프로젝트의 성공은 단순히 좋은 알고리즘이나 많은 데이터만으로는 보장되지 않습니다. 시간이 지나도 일관되게 신뢰할 수 있는 데이터를 제공할 수 있는 시스템과 문화가 필요합니다.

앞으로 AI 프로젝트를 계획하고 있다면, 사후 대응 중심의 데이터 품질 관리에서 벗어나 사전 예방 중심의 데이터 신뢰성 엔지니어링으로 패러다임을 전환해야 합니다. 이것이 AI 프로젝트 실패의 30% 통계에서 벗어나는 유일한 길입니다.


참고자료:

Comments