[생활 속 금융 기술 #22] 카드사 DW 데이터는 어떻게 만들어질까?

우리가 신용카드를 사용하면 카드사에는 다양한 거래 데이터가 발생합니다.

편의점에서 15,000원을 결제하거나 온라인 쇼핑몰에서 80,000원을 결제하면 관련 승인 정보가 생성됩니다. 이후 거래의 매입, 취소, 청구 등 업무가 진행되면서 새로운 정보가 만들어지거나 기존 정보의 상태가 변경됩니다.

그렇다면 카드사는 이러한 데이터를 어떻게 활용할까요?

예를 들어 카드사 마케팅 담당자가 다음과 같은 자료를 요청했다고 가정해 보겠습니다.

"지난달 고객들이 가장 많이 이용한 업종은 무엇인가요?"

"이번 달 승인 금액은 지난달보다 얼마나 증가했나요?"

"카드 상품별 매입 실적은 어떻게 달라졌나요?"

이러한 질문에 답하려면 여러 업무 시스템에 흩어져 있는 데이터를 모으고, 기준을 통일하고, 분석할 수 있는 형태로 가공해야 합니다.

이 역할을 담당하는 대표적인 시스템이 바로 **데이터웨어하우스(Data Warehouse, DW)**입니다.

그런데 DW의 데이터는 저절로 만들어지지 않습니다.

업무 시스템에서 필요한 데이터를 추출하고, 분석 목적에 맞게 변환하고, DW에 적재하는 과정이 필요합니다.

이때 금융 IT 담당자가 자주 접하는 용어가 있습니다.

바로 ETL, ELT, CDC입니다.

세 가지는 비슷해 보이지만 역할과 처리 방식이 서로 다릅니다.

이번 글에서는 가상의 카드 거래 5건을 활용하여 DW 데이터가 만들어지는 과정을 살펴보고, ETL·ELT·CDC의 차이와 실제 운영 시 주의해야 할 사항까지 알아보겠습니다.

※ 이 글의 거래 데이터, SQL, 시스템 구성은 이해를 돕기 위해 작성한 교육용 예시입니다. 특정 카드사의 실제 데이터베이스 구조나 내부 운영 절차를 설명하는 것은 아닙니다. 실제 업무 기준과 처리 방식은 금융회사마다 다를 수 있습니다.

전체 목차

카드사에는 어떤 거래 데이터가 발생할까?
카드사는 왜 DW를 별도로 운영할까?
DW 데이터가 만들어지는 전체 과정
ETL이란? 추출·변환·적재의 원리
ELT란? 데이터를 먼저 적재하고 변환하는 방식
CDC란? 변경된 데이터만 찾아 전달하는 기술
ETL·ELT·CDC의 차이 한눈에 비교하기
실무 사례: 카드 승인 데이터 5건으로 DW 만들기
SQL 예제로 알아보는 데이터 정제와 집계
승인·매입·취소 데이터는 어떻게 연결될까?
DW 적재 작업이 실패하면 어떤 문제가 생길까?
금융 IT 운영담당자의 데이터 정합성 점검 방법
실시간 DW와 배치 DW, 어떤 방식이 좋을까?
DW 운영에서 꼭 알아야 할 실무 체크리스트와 FAQ
마무리: DW의 가치는 데이터의 양보다 신뢰성에 있다

1. 카드사에는 어떤 거래 데이터가 발생할까?

카드사에서 발생하는 데이터는 생각보다 다양합니다.

소비자가 카드를 사용하면 승인 관련 데이터가 발생하고, 이후 업무 처리에 따라 매입과 청구 관련 데이터가 만들어질 수 있습니다.

카드사는 이러한 거래 데이터 외에도 회원, 상품, 가맹점 등 다양한 정보를 관리합니다.

대표적인 데이터 유형을 살펴보겠습니다.

데이터 종류	주요 내용	활용 예시
승인 데이터	승인 일시, 금액, 거래 상태	실시간 이용 현황
매입 데이터	매입 일자, 매입 금액	매입 실적 분석
청구 데이터	청구 대상 금액, 청구 주기	청구 실적 분석
회원 데이터	회원 관련 속성	고객군별 분석
상품 데이터	카드 상품 및 서비스 정보	상품별 실적 분석
가맹점 데이터	가맹점 및 업종 정보	업종별 이용 분석
취소 데이터	취소 대상 거래와 금액	취소율 및 순이용액 분석

여기서 중요한 사실이 있습니다.

하나의 카드 결제가 하나의 데이터만 만들어내는 것은 아닙니다.

카드 승인과 매입, 청구는 서로 다른 업무 단계이며, 각 단계에서 관리하는 데이터도 다를 수 있습니다.

따라서 카드 이용 실적을 분석할 때는 어떤 데이터를 기준으로 삼을지 먼저 결정해야 합니다.

예를 들어 승인 금액을 기준으로 한 이용 실적과 매입 금액을 기준으로 한 이용 실적은 다를 수 있습니다.

이러한 업무 기준을 정확하게 정의하는 것이 DW 구축과 운영의 출발점입니다.

2. 카드사는 왜 DW를 별도로 운영할까?

카드사의 업무 시스템은 금융거래를 안정적으로 처리하는 것이 중요합니다.

반면 DW는 많은 데이터를 조회하고 집계하는 분석 업무를 지원합니다.

두 시스템은 요구되는 처리 방식이 다릅니다.

업무 시스템에서 직접 분석하면 안 될까?

기술적으로 불가능한 것은 아닙니다.

하지만 수많은 거래를 집계하는 대량 조회 작업이 핵심 업무 시스템의 자원을 사용하면 업무 처리 성능에 영향을 줄 수 있습니다.

또한 여러 업무 시스템의 데이터를 통합해서 분석하려면 데이터 형식과 업무 기준을 맞추는 과정이 필요합니다.

DW는 이러한 문제를 해결하기 위한 대표적인 방법입니다.

DW의 주요 역할

첫째, 여러 업무 시스템의 데이터를 수집합니다.

둘째, 서로 다른 데이터 형식을 표준화합니다.

셋째, 분석에 필요한 항목을 추가하거나 가공합니다.

넷째, 과거 데이터를 일정한 기준으로 관리합니다.

다섯째, 현업 담당자가 사용할 수 있는 분석 데이터와 보고서를 제공합니다.

예를 들어 승인 시스템에는 개별 거래 정보가 존재하지만, DW에서는 해당 거래에 가맹점 업종 정보와 카드 상품 정보를 연결하여 분석할 수 있습니다.

이처럼 DW는 단순한 데이터 저장소가 아니라 업무 데이터를 분석 가능한 정보로 만드는 기반입니다.

3. DW 데이터가 만들어지는 전체 과정

DW 데이터가 만들어지는 과정을 간단하게 표현하면 다음과 같습니다.

업무 시스템 → 데이터 추출·전달 → 정제·변환 → DW 적재 → 집계·분석 → 보고서

조금 더 구체적으로 살펴보겠습니다.

1단계. 원천 데이터 확인

먼저 어떤 업무 시스템에서 필요한 데이터가 발생하는지 확인합니다.

예를 들어 카드 승인 실적 분석을 위해 승인 관련 데이터를 수집한다고 가정하겠습니다.

2단계. 데이터 추출 또는 변경 정보 수집

원천 시스템에서 필요한 데이터를 가져옵니다.

이때 전체 데이터를 조회할 수도 있고, 일정 기간의 데이터만 가져올 수도 있습니다.

변경된 데이터만 식별하여 전달하는 방법도 있습니다.

3단계. 데이터 정제

분석에 사용하기 어려운 데이터가 있는지 확인합니다.

예를 들어 필수 항목이 누락되었거나 날짜 형식이 잘못된 데이터 등을 점검합니다.

4단계. 데이터 변환

원천 데이터에 업무 규칙을 적용합니다.

가맹점 업종 코드를 업종명으로 변환하거나, 거래 일시에서 분석 기준 날짜를 생성하는 작업 등이 해당합니다.

5단계. DW 적재

정제·변환한 데이터를 DW의 대상 테이블에 저장합니다.

6단계. 집계 데이터 생성

일별, 월별, 상품별, 업종별 실적 등 분석 목적에 맞는 집계 데이터를 생성합니다.

7단계. 데이터 검증

적재 건수와 금액이 예상한 기준에 부합하는지 확인합니다.

8단계. 보고서 제공

검증된 데이터를 이용하여 분석 보고서나 대시보드를 제공합니다.

이 과정은 한 번만 수행되는 것이 아닙니다.

데이터의 중요도와 업무 요구에 따라 일정한 주기로 반복되거나 실시간에 가깝게 수행될 수 있습니다.

4. ETL이란? 추출·변환·적재의 원리

ETL은 다음 세 단어의 약자입니다.

Extract: 추출
Transform: 변환
Load: 적재

즉, 원천 시스템에서 데이터를 추출하고, 필요한 형태로 변환한 다음, 대상 시스템에 적재하는 방식입니다.

카드사 ETL 처리 예시

가상의 승인 데이터가 다음과 같이 존재한다고 가정하겠습니다.

승인번호	승인일시	승인금액	업종코드
A001	2026-10-20 09:10	15,000원	1001
A002	2026-10-20 12:30	32,000원	2001
A003	2026-10-20 18:45	80,000원	3001

ETL 과정에서는 다음과 같은 처리를 수행할 수 있습니다.

Extract — 추출

승인 관련 테이블에서 필요한 거래를 가져옵니다.

Transform — 변환

승인일시에서 날짜를 추출하고, 업종코드를 업종명으로 변환합니다.

예를 들어 교육용 코드 기준으로 1001은 편의점, 2001은 음식점, 3001은 온라인 쇼핑으로 정의했다고 가정하겠습니다.

Load — 적재

변환한 결과를 DW의 분석용 테이블에 저장합니다.

ETL의 장점

DW에 적재하기 전에 데이터를 정제할 수 있습니다.
변환 과정에서 업무 규칙을 적용할 수 있습니다.
적재 대상의 데이터 구조를 일정하게 유지하기 좋습니다.

ETL의 고려사항

변환 작업이 별도 처리 환경에서 수행되므로 데이터 규모와 처리 시간에 따라 충분한 자원이 필요합니다.

또한 변환 로직이 복잡해지면 유지보수 부담이 커질 수 있습니다.

5. ELT란? 데이터를 먼저 적재하고 변환하는 방식

ELT는 다음 세 단어의 약자입니다.

Extract: 추출
Load: 적재
Transform: 변환

ETL과 사용하는 단어는 같지만 처리 순서가 다릅니다.

ETL은 변환한 후 적재합니다.

반면 ELT는 원천 데이터를 먼저 대상 데이터 플랫폼에 적재하고, 그 안에서 변환 작업을 수행하는 방식입니다.

ELT 처리 과정

원천 시스템에서 데이터를 추출합니다.
데이터 플랫폼의 원천 또는 준비 영역에 적재합니다.
플랫폼 내부에서 필요한 변환 작업을 수행합니다.
분석용 테이블을 생성합니다.
결과 데이터를 검증합니다.

ELT가 유리할 수 있는 상황

대규모 데이터 플랫폼이 충분한 처리 능력을 제공하고, 원천 데이터를 여러 분석 목적에 활용해야 할 때 ELT가 유용할 수 있습니다.

예를 들어 같은 거래 데이터를 마케팅 분석과 리스크 분석에서 서로 다른 기준으로 가공해야 한다면 원천 데이터를 보존한 상태에서 여러 변환 작업을 수행하는 방식이 적합할 수 있습니다.

ELT에서 주의할 점

원천 데이터를 먼저 적재한다고 해서 아무 데이터나 무제한 저장해도 된다는 뜻은 아닙니다.

특히 금융회사는 개인정보와 금융거래정보에 대한 접근통제, 보존 기준, 암호화, 데이터 최소화 등 관련 법령과 내부 정책을 고려해야 합니다.

또한 원천 데이터와 분석용 데이터의 구분이 명확해야 합니다.

6. CDC란? 변경된 데이터만 찾아 전달하는 기술

CDC는 Change Data Capture의 약자입니다.

우리말로는 변경 데이터 캡처라고 합니다.

CDC는 데이터베이스 등 원천 시스템에서 발생한 데이터 변경 사항을 식별하여 다른 시스템에 전달하는 기술 또는 처리 방식입니다.

예를 들어보겠습니다

어느 거래 테이블에 100만 건의 데이터가 있다고 가정하겠습니다.

그런데 하루 동안 새로 등록되거나 수정된 거래는 5,000건입니다.

매번 100만 건 전체를 다시 읽어 전달하는 방식은 비효율적일 수 있습니다.

CDC를 활용하면 변경된 데이터를 중심으로 전달할 수 있습니다.

CDC의 주요 처리 대상

INSERT: 새로운 데이터 등록
UPDATE: 기존 데이터 변경
DELETE: 기존 데이터 삭제

다만 CDC는 구현 방식에 따라 변경 이벤트의 표현, 삭제 처리, 순서 보장, 재전송 방식이 달라집니다.

카드사 업무 예시

가상의 승인 거래가 처음에는 다음과 같은 상태였다고 가정하겠습니다.

승인번호 A001 / 승인금액 15,000원 / 상태 정상

이후 해당 거래에 대한 취소 관련 업무가 발생하여 원천 데이터의 상태가 변경될 수 있습니다.

CDC는 이러한 변경을 식별하여 연계 시스템에 전달하는 데 활용될 수 있습니다.

단, 실제 카드 거래에서는 승인과 취소를 별도의 거래 기록으로 관리할 수도 있습니다.

따라서 CDC로 전달된 데이터가 무엇을 의미하는지는 반드시 원천 시스템의 데이터 모델과 업무 규칙을 기준으로 판단해야 합니다.

CDC의 장점

변경된 데이터를 효율적으로 전달할 수 있습니다.
데이터 반영 지연을 줄이는 데 도움이 될 수 있습니다.
반복적인 전체 데이터 추출 부담을 줄일 수 있습니다.

CDC의 한계

CDC는 데이터를 분석에 적합한 형태로 자동 변환하는 기술이 아닙니다.

변경 정보를 전달한 후에도 정제, 업무 규칙 적용, 데이터 품질 검증 등이 필요합니다.

CDC는 ETL이나 ELT를 무조건 대체하는 기술이 아니라 함께 사용할 수 있는 데이터 수집·연계 기술입니다.

7. ETL·ELT·CDC의 차이 한눈에 비교하기

세 가지를 비교하면 다음과 같습니다.

구분	ETL	ELT	CDC
의미	추출·변환·적재	추출·적재·변환	변경 데이터 캡처
핵심 목적	변환 후 대상에 적재	적재 후 대상에서 변환	변경 사항 식별·전달
주요 특징	적재 전 변환	대상 플랫폼에서 변환	변경 이벤트 중심
데이터 처리	전체·증분 모두 가능	전체·증분 모두 가능	변경 데이터 중심
활용 예시	정기 DW 적재	대규모 분석 플랫폼	준실시간 데이터 연계
주의사항	변환 처리 비용	적재 후 데이터 관리	중복·순서·누락 관리

여기서 기억해야 할 점은 ETL과 ELT가 데이터 처리 파이프라인의 구성 방식을 설명한다는 것입니다.

반면 CDC는 원천 데이터의 변경을 수집하는 방법을 설명합니다.

따라서 다음과 같은 구조도 가능합니다.

원천 DB → CDC → 데이터 수집 영역 → ELT 변환 → DW 분석 테이블

또는 다음과 같은 구조도 가능합니다.

원천 DB → 증분 데이터 추출 → ETL 변환 → DW 분석 테이블

어떤 방식이 더 좋은지는 데이터 규모, 업무 요구, 시스템 환경, 보안 기준, 운영 비용 등을 고려하여 판단해야 합니다.

8. 실무 사례: 카드 승인 데이터 5건으로 DW 만들기

이번에는 가상의 카드 승인 데이터 5건을 활용하여 DW 적재 과정을 살펴보겠습니다.

① 원천 승인 데이터

승인번호	승인일시	금액	업종코드	상태
A001	10/20 09:10	15,000원	1001	정상
A002	10/20 12:30	32,000원	2001	정상
A003	10/20 18:45	80,000원	3001	정상
A004	10/20 19:20	25,000원	1001	정상
A005	10/20 20:15	48,000원	2001	정상

모든 거래는 2026년 10월 20일 발생했다고 가정하겠습니다.

또한 업종코드는 다음과 같이 정의합니다.

1001: 편의점
2001: 음식점
3001: 온라인 쇼핑

이 코드는 설명을 위해 임의로 만든 값이며 실제 카드 업종 분류 코드를 의미하지 않습니다.

② 데이터 추출

먼저 원천 시스템에서 분석에 필요한 승인번호, 승인일시, 승인금액, 업종코드, 거래 상태를 추출합니다.

③ 데이터 변환

승인일시에서 승인일자를 생성합니다.

업종코드를 업종명으로 변환합니다.

거래 상태를 확인하여 분석 대상 거래를 선정합니다.

④ DW 적재 결과

승인일자	승인번호	업종명	승인금액
2026-10-20	A001	편의점	15,000원
2026-10-20	A002	음식점	32,000원
2026-10-20	A003	온라인 쇼핑	80,000원
2026-10-20	A004	편의점	25,000원
2026-10-20	A005	음식점	48,000원

⑤ 업종별 승인 실적 집계

업종	승인 건수	승인 금액
편의점	2건	40,000원
음식점	2건	80,000원
온라인 쇼핑	1건	80,000원
합계	5건	200,000원

이제 현업 담당자는 개별 거래를 하나씩 확인하지 않고도 업종별 승인 실적을 분석할 수 있습니다.

여기서 중요한 질문

만약 원천 데이터에는 5건이 존재하는데 DW에는 4건만 적재되었다면 어떻게 해야 할까요?

단순히 적재 작업이 정상 종료되었다는 사실만으로 데이터가 정확하다고 판단할 수 없습니다.

원천과 DW의 거래 건수 및 금액을 비교해야 합니다.

이것이 DW 운영에서 데이터 정합성 검증이 중요한 이유입니다.

9. SQL 예제로 알아보는 데이터 정제와 집계

이번에는 위의 거래 데이터를 SQL로 분석하는 방법을 살펴보겠습니다.

SQL은 데이터베이스에서 데이터를 조회하고 처리할 때 사용하는 언어입니다.

다음 예시는 교육용으로 단순화한 SQL이며, 실제 실행 시에는 DBMS별 문법과 테이블 구조에 맞게 수정해야 합니다.

① 원천 승인 데이터 조회

SELECT
    approval_no,
    approval_date,
    approval_amount,
    industry_code,
    approval_status
FROM approval_transaction
WHERE approval_date >= DATE '2026-10-20'
  AND approval_date < DATE '2026-10-21';

이 SQL은 지정한 날짜 범위의 승인 데이터를 조회하는 예시입니다.

approval_date가 날짜·시각을 포함하는 컬럼이라는 가정하에 범위 조건을 사용했습니다.

② 정상 승인 거래의 업종별 집계

SELECT
    industry_code,
    COUNT(*) AS approval_count,
    SUM(approval_amount) AS approval_amount
FROM approval_transaction
WHERE approval_date >= DATE '2026-10-20'
  AND approval_date < DATE '2026-10-21'
  AND approval_status = 'NORMAL'
GROUP BY industry_code
ORDER BY industry_code;

이 SQL은 정상 승인 거래를 업종별로 집계합니다.

다만 여기서 NORMAL은 예시 데이터에서 정의한 상태 값입니다.

실제 카드사의 승인 상태 코드와는 다를 수 있습니다.

③ DW 적재 결과와 원천 데이터 비교

데이터 적재가 완료되었다면 원천 데이터와 DW 데이터의 건수 및 금액을 비교할 수 있습니다.

SELECT
    COUNT(*) AS transaction_count,
    SUM(approval_amount) AS total_amount
FROM dw_approval
WHERE approval_date >= DATE '2026-10-20'
  AND approval_date < DATE '2026-10-21';

원천 데이터와 DW에서 동일한 조건으로 조회한 결과를 비교합니다.

예를 들어 원천과 DW가 모두 5건, 200,000원이라면 1차 집계 결과는 일치합니다.

하지만 여기서 점검이 끝나는 것은 아닙니다.

집계 금액이 같아도 데이터가 잘못될 수 있습니다

가령 원천에는 15,000원과 25,000원 거래가 있는데 DW에는 20,000원 거래가 두 건 들어갔다고 가정해 보겠습니다.

두 데이터의 합계는 모두 40,000원입니다.

하지만 개별 거래는 일치하지 않습니다.

따라서 중요한 데이터는 승인번호 등 적절한 거래 식별정보를 기준으로 개별 데이터까지 비교해야 합니다.

또한 거래 식별정보가 실제로 유일한지, 여러 시스템에서 동일한 의미로 사용되는지도 확인해야 합니다.

데이터 정합성 검증에서는 전체 건수와 금액의 일치뿐 아니라 개별 거래의 정확성까지 확인하는 것이 중요합니다.

10. 승인·매입·취소 데이터는 어떻게 연결될까?

카드사 DW를 이해할 때 가장 주의해야 할 부분 중 하나가 승인, 매입, 취소 데이터의 관계입니다.

카드 결제는 승인만으로 모든 업무가 완료되는 구조가 아닙니다.

승인 이후 매입 관련 절차가 진행될 수 있고, 거래가 취소되면 별도의 취소 관련 정보가 발생할 수 있습니다.

가상의 거래 사례

고객이 온라인 쇼핑몰에서 80,000원을 결제했습니다.

10월 20일에 승인이 발생했습니다.

10월 21일에는 매입 관련 처리가 이루어졌다고 가정하겠습니다.

그런데 고객이 10월 22일에 주문을 취소했습니다.

이 경우 DW에서는 어떤 금액을 보여줘야 할까요?

정답은 보고서의 업무 기준에 따라 달라진다는 것입니다.

승인일 기준 실적을 보는지, 매입일 기준 실적을 보는지, 취소 반영 후 순이용액을 보는지에 따라 결과가 달라질 수 있습니다.

분석 기준 예시

분석 지표	주요 기준
승인 실적	승인 거래 및 승인일 기준
매입 실적	매입 거래 및 매입일 기준
취소 실적	취소 거래와 반영 기준
순이용액	정의된 원거래·취소 반영 규칙
청구 실적	청구 대상과 청구 기준

이 때문에 DW에서는 데이터 적재 기술뿐 아니라 업무 데이터의 정의가 매우 중요합니다.

기술적으로 데이터가 정상 적재되었더라도 지표의 업무 기준이 잘못되면 분석 결과가 잘못 해석될 수 있습니다.

11. DW 적재 작업이 실패하면 어떤 문제가 생길까?

DW 적재 작업은 여러 단계로 구성될 수 있습니다.

원천 데이터 추출부터 변환, 적재, 집계, 검증까지 다양한 처리가 연결됩니다.

이 가운데 어느 한 단계에서 문제가 발생하면 최종 보고서에 영향을 줄 수 있습니다.

주요 장애 유형

① 원천 데이터 추출 실패

원천 시스템 연결 오류나 조회 실패 등으로 데이터를 가져오지 못하는 경우입니다.

② 데이터 형식 오류

날짜나 숫자 형식이 예상과 달라 변환 작업이 실패할 수 있습니다.

③ 적재 중복

재처리 과정에서 이미 적재된 데이터가 다시 들어갈 수 있습니다.

④ 데이터 누락

일부 거래가 전달되지 않거나 처리 대상에서 빠질 수 있습니다.

⑤ 처리 시간 지연

대량 데이터 처리로 인해 정해진 시간 안에 작업이 완료되지 않을 수 있습니다.

⑥ 집계 작업 실패

원천 데이터는 적재되었지만 최종 집계 테이블 생성에 실패할 수 있습니다.

⑦ 데이터 정합성 오류

적재 작업은 성공했지만 원천과 DW의 건수나 금액이 일치하지 않을 수 있습니다.

운영담당자가 주의할 점

적재 작업이 실패했을 때 무조건 처음부터 다시 실행하는 것은 위험할 수 있습니다.

이미 일부 데이터가 적재된 상태라면 재실행으로 중복 데이터가 발생할 수 있기 때문입니다.

따라서 재처리 전에 작업의 완료 범위, 데이터 반영 상태, 중복 방지 구조 등을 확인해야 합니다.

12. 금융 IT 운영담당자의 데이터 정합성 점검 방법

이번에는 실제 운영 업무에서 활용할 수 있는 점검 절차를 가상의 사례로 살펴보겠습니다.

상황

매일 새벽 승인 데이터를 DW에 적재하는 작업이 있다고 가정하겠습니다.

작업은 정상 종료되었지만 원천 시스템과 DW의 승인 금액이 다르게 나타났습니다.

항목	원천 시스템	DW
승인 건수	100,000건	99,950건
승인 금액	50억 원	49억 9천만 원

이 경우 단순히 50건이 누락되었다고 바로 단정하면 안 됩니다.

건수 차이와 금액 차이가 발생한 원인을 구분해서 확인해야 합니다.

1단계. 조회 조건 확인

원천과 DW가 같은 거래 범위를 조회했는지 확인합니다.

승인일, 영업일, 거래 상태 등 기준을 비교합니다.

2단계. 적재 기준 시점 확인

원천 데이터 추출 시점과 DW 적재 완료 시점을 확인합니다.

서로 다른 시점의 데이터를 비교하면 정상적인 지연도 차이로 나타날 수 있습니다.

3단계. 적재 로그 확인

데이터 추출 건수, 변환 건수, 적재 건수, 오류 건수 등을 확인합니다.

4단계. 거래 식별정보 비교

원천에는 존재하지만 DW에는 없는 거래를 확인합니다.

반대로 DW에만 존재하는 거래가 있는지도 점검합니다.

5단계. 금액 차이 분석

누락 또는 불일치 거래의 금액을 집계하여 전체 차이와 비교합니다.

6단계. 재처리 범위 결정

원인과 영향 범위를 확인한 뒤 재처리 대상을 결정합니다.

7단계. 재처리 후 검증

재처리 이후 동일한 기준으로 데이터 정합성을 다시 확인합니다.

실무에서 중요한 원칙

배치 작업의 성공 여부와 데이터의 정확성은 서로 다른 점검 항목입니다.

작업이 정상 종료되었더라도 결과 데이터가 정확한지 확인해야 합니다.

또한 정합성 오류를 발견했다면 단순히 숫자를 맞추는 것보다 차이가 발생한 원인을 파악하는 것이 중요합니다.

13. 실시간 DW와 배치 DW, 어떤 방식이 좋을까?

DW 데이터는 반드시 하루에 한 번만 적재되는 것은 아닙니다.

업무 목적에 따라 다양한 주기로 데이터를 반영할 수 있습니다.

배치 기반 데이터 처리

정해진 시간이나 주기에 따라 데이터를 처리하는 방식입니다.

예를 들어 하루 동안 발생한 거래를 모아 새벽에 적재할 수 있습니다.

장점은 처리 일정을 관리하기 쉽고 일정한 기준으로 데이터를 검증하기 좋다는 점입니다.

다만 최신 거래가 반영되기까지 시간이 걸릴 수 있습니다.

실시간 또는 준실시간 처리

변경된 데이터를 빠르게 전달하여 분석 시스템에 반영하는 방식입니다.

예를 들어 CDC나 메시지 기반 연계를 활용할 수 있습니다.

장점은 최신 데이터에 가까운 정보를 활용할 수 있다는 점입니다.

하지만 데이터 중복, 순서, 지연, 장애 복구 등 추가로 고려해야 할 사항이 있습니다.

비교

구분	배치 기반	실시간 / 준실시간 기반
데이터 반영	정해진 주기	지속적 또는 짧은 주기
주요 장점	일정 관리·일괄 검증	데이터 최신성
고려사항	반영 지연	운영 복잡성·변경 이벤트 관리
활용 예시	정기 실적 보고	최신 거래 현황 분석

어떤 방식이 더 좋은지는 업무 요구에 따라 달라집니다.

예를 들어 매월 확정된 청구 실적을 분석하는 업무와 최근 몇 분간의 거래 추세를 파악하는 업무는 필요한 데이터 최신성이 다릅니다.

따라서 모든 데이터를 무조건 실시간으로 처리할 필요는 없습니다.

필요한 시점에 신뢰할 수 있는 데이터를 제공하는 것이 더 중요합니다.

14. DW 운영에서 꼭 알아야 할 실무 체크리스트와 FAQ

DW 적재 운영 체크리스트

DW 운영담당자라면 다음 항목을 확인하는 것이 좋습니다.

원천 데이터의 기준과 추출 범위가 명확한가?
데이터 적재 주기와 기준 시점이 정의되어 있는가?
적재 전후 건수와 금액을 비교하는가?
오류 데이터가 발생했을 때 별도로 식별할 수 있는가?
재처리 시 중복 적재를 방지할 수 있는가?
데이터 변경이나 삭제가 분석 시스템에 적절하게 반영되는가?
집계 지표의 업무 정의가 문서화되어 있는가?
개인정보와 금융거래정보의 접근권한이 적절하게 관리되는가?
장애 발생 시 영향 범위와 복구 절차가 준비되어 있는가?
최종 보고서의 데이터 품질을 확인하는 절차가 있는가?

Q1. ETL과 ELT 중 어느 방식이 더 좋은가요?

일률적으로 정할 수 없습니다.

데이터 규모, 변환 작업의 복잡성, 대상 플랫폼의 성능, 운영 비용 등을 고려해야 합니다.

Q2. CDC를 사용하면 ETL이 필요 없나요?

그렇지 않습니다.

CDC는 변경 데이터를 식별하고 전달하는 역할을 합니다.

분석용 데이터를 만들기 위한 변환과 검증은 여전히 필요할 수 있습니다.

Q3. DW에 데이터를 적재하면 원천 시스템과 항상 일치하나요?

반드시 그렇지는 않습니다.

적재 시점, 데이터 변환 기준, 취소 반영 방식 등에 따라 차이가 발생할 수 있습니다.

Q4. 배치 작업이 성공했는데 보고서 금액이 다를 수 있나요?

가능합니다.

작업 성공은 기술적 처리 결과를 의미하고, 보고서 금액의 정확성은 별도의 업무 기준과 정합성 검증이 필요합니다.

Q5. DW에 원천 데이터를 그대로 저장하면 안 되나요?

원천 데이터를 보존하는 구조도 활용할 수 있습니다.

다만 분석 목적에 맞는 정제와 변환, 데이터 관리 체계가 필요합니다.

Q6. 실시간 DW가 항상 더 좋은가요?

그렇지는 않습니다.

업무에 필요한 데이터 최신성과 운영 비용, 복잡성 등을 함께 고려해야 합니다.

15. 마무리｜DW의 가치는 데이터의 양보다 신뢰성에 있다

카드사에서는 매일 다양한 거래 데이터가 발생합니다.

이러한 데이터는 승인, 매입, 청구 등 여러 업무 시스템에서 만들어지고, 분석 목적에 따라 DW로 전달됩니다.

이 과정에서 ETL, ELT, CDC와 같은 기술이 활용될 수 있습니다.

ETL은 데이터를 추출하고 변환한 뒤 적재하는 방식입니다.

ELT는 데이터를 먼저 적재한 후 대상 플랫폼에서 변환하는 방식입니다.

CDC는 원천 데이터의 변경 사항을 식별하여 전달하는 기술입니다.

세 가지는 서로 경쟁하는 개념이라기보다 업무 요구에 따라 조합하여 활용할 수 있는 데이터 처리 방법입니다.

이번 글의 핵심을 네 가지로 정리하겠습니다.

첫째, DW는 여러 업무 시스템의 데이터를 수집하고 가공하여 분석에 활용할 수 있도록 지원합니다.

둘째, ETL과 ELT는 변환과 적재의 순서가 다르며, CDC는 변경 데이터를 전달하는 기술입니다.

셋째, 카드사의 승인·매입·취소 데이터는 업무 기준이 다르므로 분석 지표를 명확하게 정의해야 합니다.

넷째, DW 운영에서는 적재 작업의 성공뿐 아니라 데이터 건수, 금액, 개별 거래의 정합성까지 확인해야 합니다.

금융 IT 업무에서 데이터가 많다는 사실만으로 좋은 분석 환경이 만들어지는 것은 아닙니다.

아무리 많은 데이터를 수집해도 그 데이터가 정확하지 않다면 분석 결과를 신뢰하기 어렵습니다.

반대로 데이터의 출처와 처리 기준이 명확하고, 적재 결과를 검증할 수 있다면 분석 결과의 신뢰성을 높일 수 있습니다.

DW 운영의 핵심은 데이터를 많이 쌓는 것이 아니라, 업무에 필요한 데이터를 정확하게 만들고 신뢰할 수 있도록 관리하는 것입니다.

함께 읽으면 좋은 글

[생활 속 금융 기술 #21] 카드사 전산 시스템은 왜 여러 개로 나뉘어 있을까?｜계정계·정보계·채널계의 차이와 역할

카드사의 주요 전산 시스템과 데이터 흐름을 설명합니다.

[생활 속 금융 기술 #13] 카드사 DW에는 어떤 데이터가 쌓일까?｜승인·매입·청구 데이터가 분석 정보가 되는 과정

카드사 DW에서 활용하는 주요 데이터를 알아봅니다.

[생활 속 금융 기술 #14] 카드 승인 금액과 DW 보고서 금액이 다른 이유 7가지｜금융 IT 담당자의 데이터 정합성 점검 방법

업무 시스템과 DW의 데이터 차이를 확인하는 방법을 설명합니다.

[생활 속 금융 기술 #15] DW 배치 작업이 실패하면 어떻게 될까?｜데이터 적재 장애 원인 7가지와 복구 절차

DW 적재 장애와 복구 과정을 살펴봅니다.

[생활 속 금융 기술 #12] SQL 조회가 느려지는 이유 7가지｜금융 IT 담당자가 알려주는 실행 계획과 성능 개선 방법

대량 데이터를 조회할 때 발생하는 성능 문제를 알아봅니다.

다음 글 예고

[생활 속 금융 기술 #23] 금융 IT 시스템에서 데이터가 중복되는 이유｜재처리·중복 적재·멱등성의 원리

DW 배치 작업을 다시 실행했더니 거래 데이터가 두 번 적재되었다면 어떻게 해야 할까요?

시스템 간 메시지가 중복 전달되거나 장애 복구 과정에서 동일한 거래가 반복 처리되는 문제는 왜 발생할까요?

다음 글에서는 금융 IT 시스템에서 데이터 중복이 발생하는 원인과 이를 방지하는 멱등성(Idempotency)의 원리를 가상의 거래 사례와 SQL 예제를 통해 알아보겠습니다.

저작자표시 비영리 변경금지 (새창열림)

'금융IT > 생활 속 금융 기술' 카테고리의 다른 글

[생활 속 금융 기술 #24] 카드 결제는 끝났는데 앱에는 왜 안 보일까?｜실시간 처리·비동기 처리·최종 일관성의 원리 (0)	2026.10.30
[생활 속 금융 기술 #23] 금융 IT 시스템에서 데이터가 중복되는 이유｜재처리·중복 적재·멱등성의 원리 (0)	2026.10.29
[생활 속 금융 기술 #21] 카드사 전산 시스템은 왜 여러 개로 나뉘어 있을까?｜계정계·정보계·채널계의 차이와 역할 (0)	2026.10.26
[생활 속 금융 기술 #20] 카드 결제 시스템은 어떻게 장애를 복구할까?｜금융 IT 담당자가 알려주는 이중화·자동 전환·재해복구의 원리 (0)	2026.10.25
[생활 속 금융 기술 #19] 카드 결제는 승인됐는데 가맹점은 실패라고 한다면?｜승인 응답 유실과 거래 상태 확인의 원리 (0)	2026.10.25

[생활 속 금융 기술 #22] 카드사 DW 데이터는 어떻게 만들어질까?｜ETL·ELT·CDC의 차이와 데이터 적재 과정