기업 AI는 왜 데이터 때문에 멈출까? 세 가지 문제와 확인 기준

안녕하세요. 기업 데이터가 AI 업무에 실제로 활용될 수 있도록 돕는 큐빅(CUBIG)입니다.

모델과 인프라는 준비됐는데 AI 프로젝트가 데이터 단계에서 멈추는 경우가 있습니다.

공공기관의 민원 데이터는 외부 AI 환경으로 가져갈 수 없습니다. 기업의 고객 데이터는 접근 권한을 확보했지만 코드와 결측값의 의미가 빠져 모델이 업무 상태를 구분하지 못합니다. 금융 모델은 PoC에서 정상적으로 작동했지만 데이터 범위와 전처리 기준이 바뀐 뒤 결과가 달라졌습니다.

세 상황은 모두 ‘데이터 문제’처럼 보입니다. 그러나 원인은 서로 다릅니다.

• Restricted: 데이터는 있지만 현재 조건에서 그대로 사용할 수 없음
• Unusable: 데이터에 접근할 수 있지만 모델이 필요한 신호와 맥락을 읽을 수 없음
• Unstable: 지금은 작동하지만 데이터 상태가 바뀌면 결과를 유지하거나 다시 확인하기 어려움

원인을 구분하지 않으면 해결책도 빗나갑니다. 제한된 데이터에 정제 작업을 추가해도 사용 조건은 바뀌지 않습니다. 의미가 빠진 데이터에 접근 권한만 넓혀도 모델의 판단은 좋아지지 않습니다. 실행 상태가 불안정한데 재학습만 반복하면 같은 문제가 다시 나타날 수 있습니다.

세 가지 데이터 장벽은 막히는 지점이 다릅니다

하나의 데이터셋이 두 개 이상의 장벽에 동시에 걸릴 수도 있습니다. 예를 들어 원본 고객 데이터는 사용 조건 때문에 제한돼 있고, 허용된 방식으로 변환한 뒤에는 관계가 사라져 활용 불가 상태가 될 수 있습니다. 운영 중 변환 규칙이 계속 바뀐다면 불안정 문제까지 생깁니다.

따라서 장벽을 한 번에 해결하려 하기보다, 데이터가 도달하기 전, 모델이 읽을 때, 운영 결과를 다시 확인할 때 각각 어디에서 멈추는지 봐야 합니다.

1. Restricted: 데이터는 있지만 그대로 사용할 수 없습니다

Restricted 데이터는 품질이 나쁜 데이터가 아닙니다. 데이터의 내용과 구조가 충분하더라도 규정, 계약, 내부 정책과 시스템 환경 때문에 현재 방식으로는 AI에 사용할 수 없는 상태입니다.

공공기관의 민원·행정 데이터

기관이 민원 분류나 규정 검색에 외부 LLM을 검토한다고 가정해 보겠습니다. 실제 민원 기록에는 이름과 연락처뿐 아니라 담당 부서, 처리 이력, 첨부 문서와 내부 메모가 연결돼 있습니다.

데이터의 업무 가치는 높지만 원본을 외부 환경으로 보낼 수 없다면 모델 연결 단계에서 프로젝트가 멈춥니다. 이때 결측값을 더 채우거나 컬럼명을 정리해도 사용 조건은 달라지지 않습니다.

필요한 것은 현재의 제약을 정확히 확인하고, 허용된 환경과 목적 안에서 AI가 사용할 수 있는 데이터 형태와 실행 경로를 설계하는 일입니다. 원본 값을 직접 사용하지 않는 방식이 필요하다면 업무 관계와 분포가 유지되는지도 함께 검증해야 합니다.

엔터프라이즈의 고객·계약 데이터

고객지원 에이전트가 계약과 상담 이력을 읽어야 하지만, 원본 데이터의 외부 전송이 제한될 수 있습니다. 모든 식별값을 같은 기호로 바꾸면 노출되는 값은 줄어들지만 동일 고객의 여러 계약과 문의를 연결하는 관계도 함께 사라질 수 있습니다.

Restricted 문제의 핵심은 값을 감추는 데 있지 않습니다. 사용 조건을 지키면서 목표 AI 업무에 필요한 구조와 유용성을 어떻게 유지할 것인가에 있습니다.

금융기관의 거래 데이터

이상거래 탐지나 상담 지원에 필요한 거래 데이터는 접근 권한, 처리 환경과 목적이 엄격하게 정해져 있을 수 있습니다. 분석 조직이 데이터의 존재를 알고 있어도 목표 모델이 실행되는 환경으로 옮길 수 없다면 AI 활용이 시작되지 않습니다.

Restricted(제한) 장벽은 다음 네 가지 질문으로 점검할 수 있습니다.

• 원본 데이터를 목표 AI 환경에서 사용할 수 있나요?
• 허용된 사용자와 사용 목적, 데이터 위치, 처리 시점이 명확한가요?
• 원본을 직접 사용할 수 없다면 업무 구조를 유지할 대체 경로가 있나요?
• 변환한 데이터가 실제 모델에서도 충분히 작동하는지 검증했나요?

2. Unusable: 접근할 수 있지만 모델이 읽을 수 없습니다

Unusable 데이터는 저장과 조회가 가능하고 사용 권한도 확보된 상태입니다. 그러나 모델이 업무에 필요한 신호와 맥락을 학습하거나 참조하기 어렵습니다.

표는 정리돼 있고 파이프라인도 정상일 수 있습니다. 문제는 데이터가 모델에게 의미 있는 구분을 전달하지 못한다는 점입니다.

업무 코드의 의미가 분리된 경우

공공 업무 테이블에 status = 3, route = B7이 기록돼 있지만 코드표와 시행 시점이 함께 전달되지 않는다면 모델은 값을 읽어도 다음 조치를 판단할 수 없습니다.

사람은 조직 경험으로 ‘보완 요청’과 ‘처리 완료’를 구분하지만, 모델은 제공된 데이터 밖의 내부 의미를 알 수 없습니다. 접근 가능한 데이터라고 해서 바로 사용할 수 있는 데이터는 아닙니다.

결측값의 이유가 사라진 경우

금융 심사 데이터에서 비어 있는 값은 ‘확인 전’, ‘해당 없음’, ‘수집 실패’를 각각 뜻할 수 있습니다. 이를 모두 0이나 평균값으로 채우면 표는 완성돼 보이지만 모델은 서로 다른 업무 상태를 같은 값으로 인식합니다.

희귀하지만 중요한 패턴이 약해진 경우

이상거래, 설비 고장, 계약 위반과 같은 사건은 자주 발생하지 않습니다. 데이터 정제 과정에서 드문 값을 모두 오류로 제거하거나 상한값으로 조정하면 모델이 찾아야 할 패턴까지 약해질 수 있습니다.

반대로 희귀 사례의 수가 너무 적으면 모델이 안정적으로 학습하기 어렵습니다. 이때는 단순히 데이터 양을 늘리는 것이 아니라, 업무상 중요한 패턴을 왜곡하지 않는 방식으로 보강하고 결과를 검증해야 합니다.

문서에서 사용 조건과 최신성이 빠진 경우

RAG가 규정 문장을 정확히 찾았더라도 시행일, 폐지 여부, 적용 대상과 사용 권한이 문서에서 분리돼 있으면 에이전트는 현재 업무에 적용해도 되는지 판단하기 어렵습니다.

행정안전부의 「공공부문 AI 도입·활용 가이드」가 기관 내부의 최신 문서를 우선 참조하는 RAG 전략을 제시하는 이유도 검색 대상의 신뢰성과 최신성이 중요하기 때문입니다. 검색 가능성에 더해 각 정보의 업무 의미와 적용 조건을 데이터와 함께 전달해야 합니다.

Unusable 장벽을 확인할 때는 다음을 물어야 합니다.

• 코드·단위·결측값·예외값이 업무에서 무엇을 뜻하는지 설명할 수 있나요?
• 데이터를 변환한 뒤에도 필드와 문서 사이의 관계가 유지되나요?
• 드물지만 중요한 패턴을 단순 오류와 구분할 수 있나요?
• 목표 모델과 업무 지표를 기준으로 데이터의 실제 유용성을 검증했나요?

3. Unstable: 지금 작동해도 같은 결과를 다시 확인할 수 없습니다

Unstable 데이터는 PoC에서 가장 놓치기 쉬운 장벽입니다. 접근할 수 있고 모델도 결과를 내기 때문에 준비가 끝난 것처럼 보입니다. 문제는 데이터가 계속 바뀌는 운영 환경에서 나타납니다.

데이터 범위가 달라지는 경우

지난달 학습에는 최근 24개월의 거래가 포함됐지만 이번 달 파이프라인은 최근 12개월만 불러올 수 있습니다. 모델 버전이 같아도 계절성과 희귀 사례의 분포가 달라져 결과가 바뀔 수 있습니다.

스키마와 전처리 규칙이 바뀌는 경우

한 부서가 고객 상태 코드를 통합하고, 다른 부서가 결측값 처리 규칙을 수정했다고 가정해 보겠습니다. 현재 테이블만 보면 정상적으로 정리돼 있습니다. 그러나 과거 실행과 어떤 값이 달라졌는지 알 수 없다면 성능 변화의 원인을 찾기 어렵습니다.

참조 문서와 권한 조건이 바뀌는 경우

공공기관의 RAG가 참조하는 지침이 개정되고, 금융 상담 에이전트의 기준정보가 갱신되며, 특정 데이터에 대한 접근 권한이 변경될 수 있습니다. 모델과 프롬프트가 같더라도 실행 시점의 문서와 권한이 다르면 결과가 달라집니다.

운영 장애를 모델 문제로만 보는 경우

결과가 달라지면 모델을 다시 학습하거나 프롬프트를 수정하기 쉽습니다. 그러나 원인이 데이터 범위나 전처리 변화라면 모델 변경은 문제를 가릴 수 있습니다.

먼저 정상 실행과 문제 실행에 사용된 데이터 상태를 비교해야 합니다. 행과 스키마, 전처리, 참조정보와 권한 조건 가운데 무엇이 바뀌었는지 확인한 뒤 모델 변경 여부를 판단해야 합니다.

Unstable(불안정) 장벽은 다음 네 가지 질문으로 점검할 수 있습니다.

• 각 AI 실행에 사용된 데이터 범위와 상태를 식별할 수 있나요?
• 실행 사이의 스키마·전처리 조건·참조정보 변경점을 비교할 수 있나요?
• 현재 데이터가 바뀐 뒤에도 과거 실행의 입력 상태를 다시 구성할 수 있나요?
• 누가 데이터 상태를 확정했고 어느 실행에 사용했는지 추적할 수 있나요?

장벽마다 다른 처방이 필요합니다

여섯 축은 점수를 만들기 위한 목록이 아닙니다. 낮은 준비도가 실제로 어떤 장벽을 만들고, 무엇을 먼저 개선해야 하는지 결정하기 위한 진단 기준입니다.

우리 프로젝트가 막힌 지점 찾기

다음 순서로 점검하면 첫 번째 장벽을 빠르게 찾을 수 있습니다.

질문 1. 원본 데이터를 목표 AI 환경과 업무에 사용할 수 있나요?

아니라면 Restricted 문제부터 해결해야 합니다. 모델 성능을 논의하기 전에 허용된 데이터 형태와 실행 환경을 정해야 합니다.

질문 2. 모델이 데이터의 업무상 의미를 구분할 수 있나요?

코드, 결측값, 단위, 관계, 희귀 패턴과 최신성이 빠져 있다면 Unusable 문제입니다. 파이프라인이 성공했다는 로그보다 실제 모델과 업무 지표에서 유용성을 검증해야 합니다.

질문 3. 결과에 사용된 데이터 상태를 다시 확인할 수 있나요?

실행별 입력 상태를 식별할 수 없거나 과거 상태를 구성하지 못한다면 Unstable 문제입니다. 모델을 다시 학습하기 전에 정상 실행과 문제 실행의 데이터 차이를 확인해야 합니다.

세 질문에 모두 답할 수 있어야 데이터가 운영 가능한 AI-Ready 상태에 가까워집니다.

프로젝트 단계별로 확인할 아홉 가지 항목

접근 전

모델 연결 전

운영 전

Syntitan은 장벽을 진단하고 실행 가능한 데이터 상태로 연결합니다

Syntitan은 기업 데이터가 Restricted, Unusable, Unstable 가운데 어디에서 막히는지 활용성, 무결성, 맥락, 일관성, 재현성, 추적성의 여섯 축으로 진단하는 AI-Ready Data Platform입니다.

Restricted 데이터에는 사용 조건 안에서 AI 업무에 필요한 구조와 관계를 유지하는 활용 경로가 필요합니다. Unusable 데이터에는 결측과 희귀 패턴, 업무 맥락을 확인하고 목표 모델에서 유용성을 검증하는 과정이 필요합니다.

Unstable 데이터에는 검증을 통과한 데이터 상태를 릴리스 단위로 고정하고 각 AI 또는 에이전트 실행과 연결하는 관리가 필요합니다. 문제가 생기면 정상 실행과 문제 실행의 상태를 비교하고, 필요한 경우 과거 결과를 만든 상태로 돌아가 원인을 확인할 수 있어야 합니다.

AI 프로젝트가 데이터에서 멈췄다면 ‘데이터 품질이 낮다’고 한꺼번에 진단하지 마세요.

데이터가 도달하지 못하는지, 도달해도 읽히지 않는지, 읽힌 뒤 상태가 유지되지 않는지부터 구분해야 합니다.