"어제 카드 승인 금액이 100억 원인데, DW 보고서에는 98억 원으로 나옵니다."
"승인 시스템에서는 정상적으로 조회되는데, 분석 화면에는 일부 거래가 보이지 않습니다."
"지난주에 확인한 월별 실적과 오늘 조회한 월별 실적이 서로 다릅니다."
금융회사에서 DW(데이터웨어하우스)를 운영하다 보면 현업 부서로부터 이러한 문의를 받는 경우가 있습니다.
데이터를 조회하는 사용자 입장에서는 두 화면의 금액이 다르면 시스템에 오류가 발생했다고 생각하기 쉽습니다.
하지만 금융 IT 담당자의 관점에서 보면 데이터 불일치는 다양한 원인으로 발생할 수 있습니다.
실제로 데이터가 누락되었을 수도 있지만, 집계 기준일이나 취소 거래 반영 방식이 다르기 때문에 정상적인 차이가 나타나는 경우도 있습니다.
따라서 중요한 것은 두 시스템의 숫자가 다르다는 사실만으로 오류라고 판단하지 않는 것입니다.
먼저 두 시스템이 같은 데이터를 같은 기준으로 계산하고 있는지 확인해야 합니다.
이번 글에서는 카드 승인 금액과 DW 보고서 금액이 달라지는 대표적인 원인 7가지와 금융 IT 담당자가 데이터 정합성을 점검하는 방법을 자세히 알아보겠습니다.
※ 본문의 거래 정보, SQL, 금액, 테이블명은 이해를 돕기 위한 가상 예시입니다. 실제 카드사의 승인·매입·청구 업무 규칙과 DW 구조는 회사마다 다를 수 있습니다.
전체 목차
- DW 데이터 정합성이 중요한 이유
- 카드 승인 시스템과 DW 보고서의 차이
- 승인 금액과 DW 보고서 금액이 다른 7가지 원인
- 실제 사례: 승인 금액 100억 원과 DW 금액 98억 원
- 데이터 불일치 발생 시 실무 점검 순서
- SQL로 데이터 누락과 중복 확인하기
- 데이터 정합성 검증에서 주의할 사항
- 현업 부서에 데이터 차이를 설명하는 방법
- 데이터 불일치를 예방하는 운영 관리 방법
- 생성형 AI를 데이터 정합성 점검에 활용하는 방법
- 자주 묻는 질문
- 마무리
1. DW 데이터 정합성이 중요한 이유
DW는 여러 업무 시스템에서 생성된 데이터를 분석 목적에 맞게 수집하고 관리하는 환경입니다.
카드사에서는 승인, 매입, 청구, 입금, 가맹점, 상품 등 다양한 업무 데이터가 DW에 적재될 수 있습니다.
이러한 데이터는 다음과 같은 업무에 활용됩니다.
- 카드 이용 실적 분석
- 가맹점 업종별 이용 현황
- 상품별 이용 금액 집계
- 월별 경영 실적 보고
- 고객 서비스 개선
- 마케팅 성과 분석
- 업무 운영 현황 점검
문제는 DW에서 제공하는 데이터가 실제 업무 기준과 다르면 분석 결과의 신뢰성이 떨어질 수 있다는 점입니다.
예를 들어 카드 승인 실적을 100억 원으로 알고 있는 부서와 98억 원으로 보고받은 부서가 있다면 어느 수치를 사용해야 할지 혼란이 발생할 수 있습니다.
이러한 문제를 예방하기 위해 필요한 것이 데이터 정합성 관리입니다.
데이터 정합성이란?
데이터 정합성은 관련 데이터가 정해진 업무 규칙에 따라 정확하고 일관되게 관리되는 상태를 의미합니다.
하지만 정합성이란 단순히 모든 시스템의 금액이 동일해야 한다는 뜻은 아닙니다.
서로 다른 업무 기준으로 계산한 금액은 정상적으로 다를 수 있습니다.
예를 들어 다음과 같은 지표를 생각해 보겠습니다.
| 지표 | 의미 |
| 총 승인 금액 | 승인된 거래를 특정 기준으로 집계한 금액 |
| 순승인 금액 | 승인 금액에서 취소 등 조정 요소를 반영한 금액 |
| 매입 금액 | 매입 처리 기준으로 집계한 금액 |
| 청구 금액 | 청구 업무 기준으로 산정한 금액 |
이 네 가지 금액은 모두 카드 거래와 관련이 있지만 동일한 의미를 가지지는 않습니다.
데이터 정합성을 검증하려면 먼저 비교하려는 지표의 정의가 일치하는지 확인해야 합니다.
2. 카드 승인 시스템과 DW 보고서의 차이
카드 승인 시스템과 DW는 데이터를 처리하는 목적이 다릅니다.
카드 승인 시스템
카드 승인 시스템은 고객이 카드를 이용할 때 거래 승인 여부를 판단하는 업무를 담당합니다.
승인 처리 과정에서는 승인번호, 거래 일시, 승인 금액, 승인 결과 등 관련 정보가 생성됩니다.
이러한 시스템은 개별 거래의 정확성과 신속한 처리가 중요합니다.
DW 시스템
DW는 업무 시스템에서 생성된 데이터를 분석 목적에 맞게 수집하고 가공합니다.
예를 들어 승인 데이터를 일별, 월별, 업종별, 상품별로 집계해 현업 부서에 제공할 수 있습니다.
이때 DW에는 데이터 수집, 변환, 적재, 검증 등의 과정이 추가됩니다.
두 시스템의 차이
| 구분 | 승인 시스템 | DW |
| 주요 목적 | 카드 승인 업무 처리 | 데이터 분석 및 통계 |
| 데이터 단위 | 개별 승인 거래 중심 | 개별 거래 및 집계 데이터 |
| 반영 시점 | 승인 처리 시점 중심 | 적재 및 갱신 주기에 따라 다름 |
| 주요 기준일 | 승인일·처리일 등 | 승인일·적재일·집계 기준일 등 |
| 취소 처리 | 승인 취소 업무 반영 | 정의된 집계 규칙에 따라 반영 |
| 주요 사용자 | 승인 업무 시스템 및 담당자 | 현업 분석가·경영관리·DW 담당자 |
따라서 승인 시스템과 DW의 금액이 다를 때는 단순히 데이터 오류 여부만 확인할 것이 아니라 두 시스템의 목적과 처리 구조를 함께 이해해야 합니다.
3. 승인 금액과 DW 보고서 금액이 다른 7가지 원인
원인 ① 집계 기준일이 다른 경우
가장 먼저 확인해야 할 항목은 날짜 기준입니다.
카드 거래에는 여러 날짜가 존재할 수 있습니다.
- 승인일
- 취소일
- 매입 처리일
- DW 적재일
- 보고서 집계 기준일
예를 들어 10월 24일 밤에 승인된 거래가 DW에는 10월 25일 새벽에 적재될 수 있습니다.
이때 승인일 기준 보고서와 적재일 기준 보고서는 서로 다른 금액을 표시할 수 있습니다.
따라서 날짜 조건이 같아 보여도 실제로 어떤 날짜 컬럼을 사용하는지 확인해야 합니다.
원인 ② 승인 취소 반영 기준이 다른 경우
카드 결제 후 취소가 발생하면 원 승인과 취소 거래를 어떻게 집계하는지에 따라 금액이 달라질 수 있습니다.
예를 들어 다음과 같은 거래가 발생했다고 가정하겠습니다.
| 거래 | 금액 |
| 카드 승인 | 100,000원 |
| 승인 취소 | -100,000원 |
| 순승인 금액 | 0원 |
한 보고서는 원 승인 금액을 기준으로 계산하고, 다른 보고서는 취소를 차감한 순승인 금액을 표시한다면 결과가 달라집니다.
특히 취소일이 원 승인일과 다른 경우에는 집계 기간에 따라 차이가 발생할 수 있습니다.
취소 거래를 원 승인일에 소급 반영하는지, 취소 발생일에 반영하는지도 확인해야 합니다.
원인 ③ DW 데이터 적재가 지연된 경우
DW는 원천 시스템의 데이터를 일정한 주기로 수집할 수 있습니다.
따라서 승인 시스템에 존재하는 거래가 DW에 아직 반영되지 않았을 수 있습니다.
예를 들어 DW가 매일 새벽 전일 데이터를 적재하도록 구성되어 있다면 당일 발생한 거래가 즉시 조회되지 않을 수 있습니다.
또한 적재 작업이 지연되거나 실패하면 일부 데이터가 늦게 반영될 수 있습니다.
이 경우 다음 항목을 확인해야 합니다.
- 적재 작업 시작 및 종료 시간
- 정상 완료 여부
- 처리 대상 기간
- 원천 데이터 수집 범위
- 재처리 여부
- 보고서 갱신 시점
원인 ④ 데이터 변환 과정에서 일부 거래가 제외된 경우
DW에서는 원천 데이터를 그대로 사용하는 경우도 있지만 분석 목적에 따라 변환 작업을 수행할 수 있습니다.
이 과정에서 특정 거래가 제외될 수 있습니다.
예를 들어 보고서가 정상 승인 거래만 대상으로 하도록 설계되어 있다면 승인 거절 거래나 특정 거래 유형은 집계에서 제외될 수 있습니다.
또한 업무 규칙에 따라 테스트 거래, 특정 코드, 정정 거래 등을 별도로 처리할 수 있습니다.
이러한 제외가 정상적인 업무 규칙인지, 의도하지 않은 오류인지 구분해야 합니다.
원인 ⑤ 데이터 중복 또는 누락이 발생한 경우
데이터 적재 과정에서 실제 오류가 발생하는 경우도 있습니다.
대표적인 문제는 중복과 누락입니다.
중복 데이터
동일한 거래가 의도하지 않게 여러 번 적재되는 경우입니다.
누락 데이터
원천 시스템에는 존재하지만 DW에 적재되지 않은 거래가 발생한 경우입니다.
다만 동일한 거래번호가 여러 행에 나타난다고 해서 무조건 중복 오류는 아닙니다.
거래 상태 변경 이력이나 정정 내역을 여러 행으로 관리하는 구조도 있기 때문입니다.
따라서 거래 식별키와 데이터 구조를 이해한 상태에서 중복 여부를 판단해야 합니다.
원인 ⑥ 코드값이나 업무 분류 기준이 다른 경우
승인 시스템과 DW에서 사용하는 코드 체계가 다를 수 있습니다.
예를 들어 카드 상품 코드나 가맹점 업종 코드가 변경되었는데 DW 변환 규칙이 이를 적절하게 반영하지 못하면 집계 결과가 달라질 수 있습니다.
특히 코드값이 변경되는 시점에는 과거 데이터와 현재 데이터를 어떤 기준으로 분류할지 결정해야 합니다.
업종별 또는 상품별 금액은 다르지만 전체 금액은 일치하는 경우라면 분류 기준을 점검할 필요가 있습니다.
원인 ⑦ 보고서 SQL이나 집계 로직이 다른 경우
마지막으로 확인해야 할 부분은 보고서의 SQL과 집계 로직입니다.
예를 들어 두 보고서가 같은 거래 테이블을 사용하더라도 다음과 같은 차이가 있을 수 있습니다.
- 조회 조건 차이
- 취소 금액 처리 차이
- 조인 조건 차이
- 거래 유형 필터 차이
- 금액 컬럼 선택 차이
- 중복 제거 방식 차이
- 집계 기준일 차이
특히 조인 조건이 잘못되면 하나의 거래가 여러 행으로 증가하면서 집계 금액이 커질 수 있습니다.
7가지 원인 요약
| 번호 | 주요 원인 | 핵심 점검 사항 |
| 1 | 집계 기준일 차이 | 승인일·처리일·적재일 |
| 2 | 취소 반영 차이 | 총승인·순승인·취소 기준 |
| 3 | 적재 지연 | 배치 완료 및 갱신 시점 |
| 4 | 데이터 변환 차이 | 제외 조건과 업무 규칙 |
| 5 | 중복·누락 | 거래 식별키 기준 검증 |
| 6 | 코드·분류 차이 | 코드 매핑과 변경 이력 |
| 7 | SQL·집계 로직 차이 | 필터·조인·금액 산식 |
4. 실제 사례: 승인 금액 100억 원과 DW 금액 98억 원
이제 가상의 사례를 통해 분석 과정을 살펴보겠습니다.
현업 문의
"10월 24일 승인 시스템에서는 승인 금액이 100억 원인데, DW 보고서에서는 98억 원으로 조회됩니다."
두 시스템의 금액 차이는 2억 원입니다.
이 상황에서 운영담당자가 가장 먼저 해야 할 일은 무엇일까요?
바로 두 금액이 어떤 기준으로 계산되었는지 확인하는 것입니다.
1단계. 지표 정의 확인
승인 시스템은 총 승인 금액을 표시하고, DW는 취소 금액을 반영한 순승인 금액을 표시한다고 가정하겠습니다.
2단계. 취소 금액 확인
해당 집계 기준에 따라 차감되는 취소 금액이 2억 원이라고 가정합니다.
3단계. 금액 비교
| 구분 | 금액 |
| 총승인 금액 | 100억 원 |
| 취소 차감 금액 | 2억 원 |
| 순승인 금액 | 98억 원 |
| DW 보고서 금액 | 98억 원 |
이 경우 두 시스템의 금액은 다르지만 반드시 오류라고 볼 수는 없습니다.
서로 다른 지표를 비교했기 때문입니다.
4단계. 업무 기준 검증
운영담당자는 다음 사항을 확인합니다.
- 승인 시스템의 100억 원이 총 승인 금액인가?
- DW 보고서의 98억 원이 순승인 금액인가?
- 취소 금액 2억 원의 집계 기준은 무엇인가?
- 취소 발생일과 원 승인일 중 어느 날짜를 기준으로 하는가?
- 두 시스템의 데이터 반영 시점은 동일한가?
5단계. 현업 설명
원인이 확인되면 다음과 같이 설명할 수 있습니다.
"승인 시스템은 총승인 금액을 표시하고, DW 보고서는 취소 금액을 차감한 순승인 금액을 표시하고 있습니다. 동일한 기준으로 재집계한 결과 데이터 누락이 아니라 집계 기준 차이로 확인되었습니다."
이 사례에서 중요한 점은 숫자의 차이를 발견하는 것보다 차이가 발생한 이유를 업무 기준에 따라 설명할 수 있어야 한다는 사실입니다.
※ 위 금액과 원인은 설명을 위한 가상 사례입니다.
5. 데이터 불일치 발생 시 실무 점검 순서
DW 운영담당자가 데이터 불일치 문의를 받았다면 다음 순서로 점검할 수 있습니다.
① 비교 대상 확정
먼저 어떤 시스템과 어떤 보고서를 비교하는지 확인합니다.
화면명, 보고서명, 조회 조건, 조회 시점 등을 확보합니다.
② 지표 정의 확인
승인 금액인지, 순승인 금액인지, 매입 금액인지 확인합니다.
서로 다른 지표라면 동일한 기준으로 비교할 수 있도록 정리합니다.
③ 조회 기간과 기준일 확인
승인일, 매입일, 적재일 등 어떤 날짜를 기준으로 조회했는지 확인합니다.
④ 데이터 갱신 시점 확인
원천 시스템과 DW의 데이터 반영 시점을 비교합니다.
DW 적재 작업이 정상적으로 완료되었는지도 확인합니다.
⑤ 원천 데이터와 DW 데이터 비교
동일한 조건으로 거래 건수와 금액을 비교합니다.
필요하다면 일자별, 상품별, 거래 유형별로 범위를 좁혀 차이가 발생하는 구간을 찾습니다.
⑥ 누락·중복 및 변환 규칙 점검
특정 거래가 누락되었거나 중복 적재되었는지 확인합니다.
코드 변환과 집계 규칙도 함께 점검합니다.
⑦ 원인 정리 및 후속 조치
확인 결과를 현업에 설명합니다.
실제 오류라면 영향 범위, 수정 방법, 재처리 여부, 검증 결과 등을 관리해야 합니다.
실무 점검 흐름
현업 문의 접수 → 비교 기준 확인 → 적재 상태 확인 → 건수·금액 비교 → 거래 단위 분석 → 원인 확정 → 조치 및 결과 공유
이러한 순서로 접근하면 불필요한 재작업을 줄이고 원인을 체계적으로 분석하는 데 도움이 됩니다.
6. SQL로 데이터 누락과 중복 확인하기
이번에는 DW 데이터 정합성을 점검할 때 사용할 수 있는 가상의 SQL 예제를 살펴보겠습니다.
다음 두 테이블이 있다고 가정하겠습니다.
- SAMPLE_SOURCE_TXN: 원천 승인 거래 테이블
- SAMPLE_DW_TXN: DW 승인 거래 테이블
두 테이블에는 다음 컬럼이 존재한다고 가정합니다.
| 컬럼 | 의미 |
| TXN_ID | 거래 식별번호 |
| TXN_DATE | 거래일자 |
| TXN_TYPE | 거래 유형 |
| AMOUNT | 거래 금액 |
모든 예제는 TXN_ID가 거래를 유일하게 식별하고, TXN_DATE가 YYYYMMDD 형식의 문자형이라는 가정에 기반합니다.
실제 시스템에서는 거래 이력, 취소 연결키, 복합키 등 별도의 업무 규칙을 확인해야 합니다.
예제 ① 원천과 DW의 건수·금액 비교
SELECT
'SOURCE' AS DATA_TYPE,
COUNT(*) AS TXN_CNT,
SUM(AMOUNT) AS TOTAL_AMOUNT
FROM SAMPLE_SOURCE_TXN
WHERE TXN_DATE = '20261024'
UNION ALL
SELECT
'DW' AS DATA_TYPE,
COUNT(*) AS TXN_CNT,
SUM(AMOUNT) AS TOTAL_AMOUNT
FROM SAMPLE_DW_TXN
WHERE TXN_DATE = '20261024';이 SQL은 동일한 날짜에 대해 원천과 DW의 건수 및 금액을 비교합니다.
다만 두 테이블의 거래 유형, 취소 처리, 반영 시점이 동일하다는 전제가 필요합니다.
예제 ② 원천에는 있지만 DW에는 없는 거래 확인
SELECT
S.TXN_ID,
S.TXN_DATE,
S.AMOUNT
FROM SAMPLE_SOURCE_TXN S
WHERE S.TXN_DATE = '20261024'
AND NOT EXISTS (
SELECT 1
FROM SAMPLE_DW_TXN D
WHERE D.TXN_ID = S.TXN_ID
);이 SQL은 원천 테이블에 존재하지만 DW 테이블에는 동일한 거래 식별번호가 없는 경우를 확인합니다.
다만 실제 DW에 적재 대상이 아닌 거래도 포함될 수 있으므로 적재 대상 기준을 먼저 확인해야 합니다.
또한 실제 운영 환경에서는 조회 대상 기간과 거래 식별키의 구성에 따라 조건을 조정해야 합니다.
예제 ③ DW에 동일한 거래번호가 여러 건 존재하는지 확인
SELECT
TXN_ID,
COUNT(*) AS DUP_CNT
FROM SAMPLE_DW_TXN
WHERE TXN_DATE = '20261024'
GROUP BY TXN_ID
HAVING COUNT(*) > 1;이 SQL은 동일한 거래번호가 여러 번 나타나는 경우를 찾습니다.
하지만 여러 행이 존재한다는 사실만으로 오류라고 판단해서는 안 됩니다.
거래 이력 관리 구조라면 정상적인 결과일 수 있기 때문입니다.
예제 ④ 원천과 DW의 거래 금액 차이 확인
SELECT
S.TXN_ID,
S.AMOUNT AS SOURCE_AMOUNT,
D.AMOUNT AS DW_AMOUNT
FROM SAMPLE_SOURCE_TXN S
JOIN SAMPLE_DW_TXN D
ON S.TXN_ID = D.TXN_ID
WHERE S.TXN_DATE = '20261024'
AND (
S.AMOUNT <> D.AMOUNT
OR (S.AMOUNT IS NULL AND D.AMOUNT IS NOT NULL)
OR (S.AMOUNT IS NOT NULL AND D.AMOUNT IS NULL)
);이 SQL은 동일한 거래번호에 대해 금액이 서로 다른 경우를 확인합니다.
다만 이 예제는 두 테이블에서 TXN_ID가 유일하고 금액의 의미가 동일하다는 가정이 필요합니다.
실제 업무에서는 취소·정정, 통화, 금액 부호, 거래 상태 등도 고려해야 합니다.
SQL 분석 시 주의사항
운영 시스템과 DW의 대용량 테이블을 비교하는 SQL은 상당한 시스템 자원을 사용할 수 있습니다.
따라서 실제 운영 환경에서는 다음 사항을 확인해야 합니다.
- 조회 범위를 적절하게 제한했는가?
- 인덱스 및 파티션을 활용할 수 있는가?
- 실행 계획을 검토했는가?
- 운영 부하가 큰 시간대를 피해야 하는가?
- 개인정보 및 접근 권한 기준을 준수하는가?
특히 원천 시스템에 대한 대량 조회는 운영 서비스에 영향을 줄 수 있으므로 회사의 운영 절차를 따라야 합니다.
7. 데이터 정합성 검증에서 주의할 사항
데이터 정합성을 점검할 때 흔히 발생하는 실수가 있습니다.
실수 ① 건수가 같으면 정합성이 맞는다고 판단
원천과 DW의 거래 건수가 같아도 금액이나 거래 내용이 다를 수 있습니다.
예를 들어 한 건이 누락되고 다른 한 건이 중복되면 전체 건수는 같을 수 있습니다.
따라서 건수뿐 아니라 거래 식별키와 금액 등도 확인해야 합니다.
실수 ② 금액 합계가 같으면 문제가 없다고 판단
금액 합계가 같아도 거래별 금액이 다를 수 있습니다.
예를 들어 한 거래에서 10만 원이 적게 반영되고 다른 거래에서 10만 원이 많게 반영되면 합계는 같아집니다.
따라서 필요한 경우 거래 단위 검증을 수행해야 합니다.
실수 ③ 적재 완료 여부만 확인
배치 작업이 정상 종료되었다고 해서 데이터 품질까지 보장되는 것은 아닙니다.
작업은 정상적으로 완료되었지만 일부 데이터가 업무 규칙에 따라 잘못 처리되었을 가능성도 있습니다.
실수 ④ 취소 거래를 단순 차감
취소 거래는 원 승인과의 연결 관계, 취소 처리 시점, 부분 취소 여부 등을 고려해야 할 수 있습니다.
모든 취소 거래를 동일한 방식으로 처리하면 실제 업무 기준과 다른 결과가 발생할 수 있습니다.
실수 ⑤ 보고서 SQL만 확인
보고서 SQL에 문제가 없어도 원천 수집, 변환, 적재, 코드 매핑 등 이전 단계에서 문제가 발생할 수 있습니다.
따라서 데이터 흐름 전체를 확인해야 합니다.
데이터 정합성은 단순한 숫자 비교가 아니라 데이터가 생성되고 처리되는 전체 과정을 이해하는 작업입니다.
8. 현업 부서에 데이터 차이를 설명하는 방법
DW 운영 업무에서는 기술적인 원인을 찾는 것만큼 현업 부서에 이해하기 쉽게 설명하는 것도 중요합니다.
예를 들어 데이터 불일치가 발생했을 때 다음과 같이 설명하는 것은 충분하지 않을 수 있습니다.
"ETL 배치의 매핑 조건 때문에 차이가 발생했습니다."
IT 담당자에게는 익숙한 표현이지만 현업 부서에서는 의미를 이해하기 어려울 수 있습니다.
따라서 업무 관점으로 설명하는 것이 좋습니다.
설명 예시 ① 집계 기준 차이
"승인 시스템은 취소 전 승인 금액을 표시하고, DW 보고서는 취소 금액을 반영한 금액을 표시하고 있어 차이가 발생했습니다."
설명 예시 ② 데이터 적재 지연
"일부 거래가 DW 적재 완료 시점 이후에 처리되어 현재 보고서에 반영되지 않았습니다. 해당 거래의 반영 예정 시점과 재확인 방법을 안내드리겠습니다."
설명 예시 ③ 실제 데이터 오류
"일부 거래가 DW 적재 과정에서 누락된 것으로 확인되었습니다. 영향 범위를 점검하고, 승인된 절차에 따라 재처리한 뒤 결과를 검증하겠습니다."
현업 대응 시 포함하면 좋은 항목
| 항목 | 설명 내용 |
| 현상 | 어떤 수치가 얼마나 다른가? |
| 원인 | 집계 기준 차이인가, 실제 오류인가? |
| 영향 범위 | 어떤 기간·보고서·거래에 영향이 있는가? |
| 조치 계획 | 어떤 확인 또는 수정 작업이 필요한가? |
| 후속 안내 | 언제, 어떤 방식으로 결과를 공유할 것인가? |
원인이 확정되지 않았다면 추정과 확인된 사실을 구분해서 안내하는 것이 중요합니다.
9. 데이터 불일치를 예방하는 운영 관리 방법
데이터 정합성 문제는 발생한 뒤에 해결하는 것도 중요하지만 사전에 예방하는 것이 더욱 효과적일 수 있습니다.
① 지표 정의 표준화
승인 금액, 순승인 금액, 매입 금액 등 주요 지표의 정의를 문서화합니다.
집계 기준일과 취소 반영 기준도 함께 관리합니다.
② 원천과 DW의 정합성 검증 자동화
적재 완료 후 주요 데이터의 건수와 금액을 자동으로 비교할 수 있습니다.
다만 단순 합계 비교뿐 아니라 업무 규칙에 맞는 검증 항목을 설계해야 합니다.
③ 적재 작업 모니터링
배치 지연이나 실패가 발생했을 때 신속하게 확인할 수 있도록 관리합니다.
④ 코드 변경 이력 관리
상품 코드, 가맹점 업종 코드 등 업무 분류 기준이 변경되면 관련 데이터 변환 규칙도 점검합니다.
⑤ 데이터 변경 및 재처리 이력 관리
데이터를 재적재하거나 수정한 경우 변경 사유와 처리 결과를 관리합니다.
⑥ 주요 보고서 검증
현업에서 중요하게 사용하는 보고서는 집계 로직이 변경될 때 결과를 검증하는 절차가 필요합니다.
⑦ 현업과 업무 기준 공유
동일한 용어를 사용하더라도 부서마다 의미가 다를 수 있습니다.
따라서 지표 정의와 집계 기준을 현업과 함께 확인하는 것이 좋습니다.
10. 생성형 AI를 데이터 정합성 점검에 활용하는 방법
최근 생성형 AI는 SQL 분석과 데이터 품질 점검 항목 작성에도 활용할 수 있습니다.
예를 들어 다음과 같은 질문을 할 수 있습니다.
AI 활용 예시 ① 데이터 불일치 점검 항목 작성
"카드 승인 시스템과 DW 보고서의 금액이 다른 가상 상황입니다. 집계 기준, 적재 시점, 취소 처리, 데이터 누락·중복, 코드 매핑, SQL 로직 관점에서 점검 항목을 정리해 주세요."
AI 활용 예시 ② SQL 검증 로직 작성
"가상의 SOURCE_TXN 테이블과 DW_TXN 테이블이 있습니다. 거래번호를 기준으로 누락, 중복, 금액 불일치를 확인할 수 있는 SQL 예제를 작성해 주세요."
AI 활용 예시 ③ 현업 설명문 작성
"DW 데이터 불일치의 원인이 승인 취소 반영 기준 차이로 확인된 상황입니다. 현업 부서에 설명할 수 있도록 기술 용어를 줄이고 간단한 안내문을 작성해 주세요."
이러한 방식은 업무를 체계적으로 정리하는 데 도움이 될 수 있습니다.
다만 실제 고객 거래 데이터, 내부 테이블 구조, 운영 로그 등은 승인되지 않은 외부 AI 서비스에 입력해서는 안 됩니다.
또한 AI가 작성한 SQL이나 설명은 반드시 검증해야 합니다.
AI는 정합성 점검을 지원할 수 있지만 실제 데이터의 의미와 오류 여부를 판단하는 책임은 담당자에게 있습니다.
11. 자주 묻는 질문
Q1. 승인 시스템과 DW의 금액이 다르면 무조건 오류인가요?
아닙니다.
집계 기준일, 취소 반영 방식, 데이터 갱신 시점 등이 다르면 정상적인 차이가 발생할 수 있습니다.
Q2. DW 데이터는 항상 원천 시스템과 같아야 하나요?
동일한 업무 기준으로 비교한 데이터는 정합성이 유지되어야 합니다.
하지만 DW에서 데이터를 변환하거나 집계한다면 원천 시스템의 데이터와 형태나 금액이 다를 수 있습니다.
Q3. 배치 작업이 정상 종료되면 데이터도 정상인가요?
반드시 그렇지는 않습니다.
배치가 정상적으로 완료되어도 업무 규칙이나 데이터 변환 과정에서 문제가 발생할 수 있으므로 별도의 품질 검증이 필요합니다.
Q4. 승인 취소 거래는 어떻게 집계해야 하나요?
업무 목적에 따라 다릅니다.
원 승인일 기준으로 반영할 수도 있고, 취소 발생일 기준으로 집계할 수도 있습니다.
중요한 것은 지표 정의와 집계 규칙을 명확하게 관리하는 것입니다.
Q5. 데이터 건수와 금액이 모두 같으면 정합성 문제가 없나요?
반드시 그렇지는 않습니다.
전체 건수와 금액이 같아도 개별 거래가 누락되거나 잘못 연결되었을 가능성이 있습니다.
필요한 경우 거래 단위 검증이 필요합니다.
Q6. 데이터 정합성 검증은 자동화할 수 있나요?
네.
건수, 금액, 중복, 누락, 코드값 등의 검증을 자동화할 수 있습니다.
다만 업무 규칙에 따른 정상적인 차이까지 오류로 판단하지 않도록 검증 기준을 설계해야 합니다.
Q7. DW 운영담당자가 가장 먼저 확인해야 할 것은 무엇인가요?
두 시스템의 지표 정의와 집계 기준이 동일한지 확인하는 것이 중요합니다.
그다음 데이터 반영 시점과 적재 상태, 거래 단위 차이를 순서대로 분석하는 것이 좋습니다.
12. 마무리｜데이터 정합성의 핵심은 숫자보다 업무 기준입니다
금융회사에서 DW를 운영하다 보면 승인 시스템과 보고서의 금액이 다르다는 문의를 자주 접할 수 있습니다.
하지만 데이터 차이가 발생했다고 해서 모든 경우에 시스템 오류가 있는 것은 아닙니다.
집계 기준일, 취소 반영 방식, 적재 시점, 코드 분류, SQL 로직 등에 따라 정상적인 차이가 발생할 수 있습니다.
반대로 실제 데이터 누락이나 중복, 변환 오류가 발생했을 가능성도 있습니다.
따라서 DW 운영담당자는 단순히 금액을 맞추는 데 집중하기보다 차이가 발생한 원인을 정확하게 분석해야 합니다.
오늘 내용을 세 가지로 정리하겠습니다.
첫째, 데이터 불일치가 발생하면 두 시스템의 지표 정의와 집계 기준부터 확인해야 합니다.
둘째, 원천과 DW의 데이터는 건수와 금액뿐 아니라 필요한 경우 거래 단위까지 검증해야 합니다.
셋째, 데이터 정합성 문제를 예방하려면 지표 정의 표준화, 적재 모니터링, 검증 자동화, 현업과의 업무 기준 공유가 중요합니다.
DW 운영에서 가장 중요한 것은 데이터를 많이 저장하는 것이 아닙니다.
현업이 신뢰할 수 있는 데이터를 제공하고, 숫자의 차이가 발생했을 때 그 이유를 명확하게 설명할 수 있어야 합니다.
데이터 정합성 관리의 시작은 숫자를 맞추는 것이 아니라, 숫자가 만들어진 업무 과정을 이해하는 것입니다.
함께 읽으면 좋은 글
[생활 속 금융 기술 #13] 카드사 DW에는 어떤 데이터가 쌓일까?｜승인·매입·청구 데이터가 분석 정보가 되는 과정
카드사 DW의 구조와 승인·매입·청구 데이터가 분석 정보로 활용되는 과정을 설명합니다.
[생활 속 금융 기술 #12] SQL 조회가 느려지는 이유 7가지｜금융 IT 담당자가 알려주는 실행 계획과 성능 개선 방법
DW에서 SQL 조회가 느려지는 원인과 실행 계획을 활용한 성능 분석 방법을 알아봅니다.
[생활 속 금융 기술 #11] 챗GPT에 회사 자료를 올려도 될까?｜금융 IT 직장인이 꼭 알아야 할 AI 보안 수칙 7가지
금융회사에서 AI를 사용할 때 지켜야 할 정보보안 원칙을 살펴봅니다.
다음 글 예고
[생활 속 금융 기술 #15] DW 배치 작업이 실패하면 어떻게 될까?｜데이터 적재 장애 원인과 복구 절차
매일 정상적으로 실행되던 DW 배치 작업이 갑자기 실패한다면 어떤 문제가 발생할까요?
다음 글에서는 데이터 적재 장애가 발생했을 때 운영담당자가 확인하는 로그, 작업 의존관계, 재처리 범위, 데이터 중복 방지, 복구 검증 절차 등을 실무 관점에서 설명하겠습니다.
