신용카드로 50,000원을 결제했는데 결제 알림이 두 번 도착했다면 어떤 생각이 들까요?
대부분의 사람은 카드 대금이 두 번 청구되는 것은 아닌지 걱정할 것입니다.
하지만 알림이 두 번 도착했다고 해서 실제 결제도 두 번 처리되었다고 단정할 수는 없습니다.
알림 전송 과정에서 동일한 메시지가 반복되었을 수도 있고, 실제로 서로 다른 승인 거래가 발생했을 수도 있습니다.
이 두 상황은 전혀 다른 문제입니다.
금융 IT 시스템에서도 비슷한 일이 발생합니다.
카드 승인 시스템, 데이터 연계 시스템, DW(데이터웨어하우스), 배치 프로그램 등에서는 동일한 거래 정보가 두 번 이상 전달되거나 처리되는 상황이 발생할 수 있습니다.
예를 들어 카드사 DW에 100만 건의 거래 데이터를 적재하던 중 시스템 장애가 발생했다고 가정하겠습니다.
운영담당자가 장애를 복구한 후 배치 작업을 다시 실행했습니다.
그런데 이미 적재되었던 60만 건이 다시 적재된다면 어떻게 될까요?
DW에는 동일한 거래가 중복 저장될 수 있습니다.
이러한 중복 데이터는 카드 이용 실적, 매입 금액, 고객 분석 결과 등에 영향을 줄 수 있습니다.
그렇다면 금융 IT 시스템에서는 왜 같은 데이터가 여러 번 처리되는 것일까요?
그리고 장애가 발생하여 프로그램을 다시 실행하더라도 중복 처리되지 않도록 만들 수는 없을까요?
이 문제를 이해하기 위해 알아야 할 중요한 개념이 있습니다.
바로 **멱등성(Idempotency)**입니다.
이번 글에서는 금융 IT 시스템에서 데이터 중복이 발생하는 원인과 멱등성의 원리를 살펴보고, SQL과 가상의 장애 사례를 통해 안전하게 데이터를 재처리하는 방법을 알아보겠습니다.
※ 본문에 등장하는 거래번호, 금액, 데이터베이스 테이블, SQL, 장애 시나리오는 설명을 위한 가상 사례입니다. 특정 금융회사의 실제 내부 시스템이나 운영 절차를 공개하는 내용은 아닙니다. 실제 처리 방식은 업무 규칙과 시스템 구성에 따라 달라질 수 있습니다.
전체 목차
- 금융 IT 시스템에서 데이터 중복이란 무엇인가?
- 같은 거래가 여러 번 처리되는 대표적인 원인 6가지
- 중복 알림·중복 승인·중복 적재는 어떻게 다를까?
- 장애가 발생하면 왜 재처리가 필요할까?
- 멱등성(Idempotency)이란 무엇인가?
- 멱등성을 적용하지 않은 시스템의 문제점
- 실무 사례: DW 배치 장애 후 60만 건이 중복 적재된 상황
- 중복 데이터는 어떻게 찾아낼까? SQL 실습
- 중복 적재를 방지하는 4가지 설계 방법
- 메시지 재전송과 멱등성 키의 역할
- 중복 데이터를 발견했다면 어떻게 복구해야 할까?
- 멱등성을 적용해도 주의해야 할 문제
- 금융 IT 운영담당자의 중복 데이터 점검 체크리스트
- 자주 묻는 질문
- 마무리: 안전한 재처리가 가능한 시스템이 좋은 시스템이다
1. 금융 IT 시스템에서 데이터 중복이란 무엇인가?
금융 IT 시스템에서는 다양한 데이터가 생성되고 전달됩니다.
카드 승인 거래가 발생하면 승인 관련 데이터가 생성됩니다.
이후 해당 데이터가 다른 업무 시스템으로 전달되거나 DW에 적재될 수 있습니다.
그런데 이 과정에서 동일한 업무 이벤트나 거래 기록이 의도하지 않게 반복 처리되는 상황이 발생할 수 있습니다.
이를 넓은 의미에서 데이터 중복 문제라고 부를 수 있습니다.
데이터 중복의 두 가지 모습
첫 번째는 중복 저장입니다.
동일한 거래가 DW 테이블에 두 번 저장되는 상황입니다.
두 번째는 중복 처리입니다.
동일한 요청이 반복 실행되어 업무 결과가 중복으로 반영되는 상황입니다.
두 문제는 서로 연결되어 있지만 반드시 같은 것은 아닙니다.
예를 들어 같은 거래 메시지가 두 번 전달되더라도 시스템이 이를 식별하여 한 번만 반영한다면 중복 처리 문제는 발생하지 않을 수 있습니다.
반대로 데이터베이스에 중복 행이 존재하지 않더라도 동일한 요청으로 서로 다른 거래가 두 번 생성되었다면 업무상 중복 처리가 발생했을 수 있습니다.
따라서 데이터 중복을 점검할 때는 단순히 행의 개수를 세는 것만으로 충분하지 않습니다.
동일한 업무 거래가 무엇인지 정의하고, 해당 거래가 어떤 결과로 반영되었는지 확인해야 합니다.
2. 같은 거래가 여러 번 처리되는 대표적인 원인 6가지
데이터 중복은 단순한 프로그램 오류 외에도 여러 원인으로 발생할 수 있습니다.
① 네트워크 응답 지연
시스템 A가 시스템 B에 거래 처리 요청을 보냈습니다.
시스템 B는 정상적으로 처리했지만 응답이 늦게 도착했습니다.
시스템 A는 요청이 실패했다고 판단하고 같은 요청을 다시 보낼 수 있습니다.
이때 시스템 B가 두 번째 요청을 새로운 거래로 처리하면 중복 문제가 발생할 수 있습니다.
② 메시지 재전송
메시지 기반 시스템에서는 처리 확인이 되지 않은 메시지를 다시 전달하는 방식이 사용될 수 있습니다.
이는 메시지 유실을 줄이는 데 도움이 되지만, 동일한 메시지가 여러 번 전달될 가능성도 고려해야 합니다.
③ 배치 작업 재실행
DW 적재 작업이 중간에 실패하면 운영담당자는 작업을 재실행할 수 있습니다.
하지만 이미 적재된 데이터의 범위를 확인하지 않고 다시 실행하면 중복 적재가 발생할 수 있습니다.
④ 데이터 연계 구간의 재처리
원천 시스템에서 데이터를 추출한 후 연계 시스템에서 장애가 발생할 수 있습니다.
복구 과정에서 이미 전달된 데이터를 다시 전송하면 중복 데이터가 발생할 수 있습니다.
⑤ 처리 완료 상태 관리 오류
거래 처리 자체는 성공했지만 처리 완료 상태가 정상적으로 기록되지 않을 수 있습니다.
이 경우 시스템은 해당 거래를 미처리 상태로 판단하고 다시 실행할 수 있습니다.
⑥ 업무상 중복 거래
기술적인 재전송 문제가 아니더라도 고객이나 가맹점이 동일한 결제를 반복 요청하는 경우가 있습니다.
이 경우 서로 다른 승인번호가 생성될 수 있으며, 단순히 금액과 시간이 같다는 이유만으로 동일 거래라고 판단해서는 안 됩니다.
3. 중복 알림·중복 승인·중복 적재는 어떻게 다를까?
금융 서비스에서 중복이라는 표현은 여러 상황에 사용됩니다.
하지만 실제 의미는 서로 다릅니다.
| 구분 | 발생 위치 | 주요 문제 |
| 중복 알림 | 문자·푸시 알림 서비스 | 같은 거래 알림이 반복 수신됨 |
| 중복 승인 | 카드 승인 처리 | 별개의 승인 거래가 반복 발생할 수 있음 |
| 중복 적재 | DW·데이터 연계 | 같은 거래 데이터가 여러 번 저장됨 |
| 중복 집계 | 통계·보고서 | 동일 거래가 실적에 반복 반영됨 |
| 중복 업무 처리 | 업무 프로그램 | 같은 요청의 효과가 반복 적용됨 |
예를 들어보겠습니다
고객이 50,000원을 한 번 결제했습니다.
그런데 카드사 앱에서 승인 알림이 두 번 나타났습니다.
이때 실제 승인 거래가 한 건이라면 알림 중복 문제일 수 있습니다.
반면 승인번호가 서로 다른 두 거래가 발생했다면 별도의 승인 거래가 존재하는지 확인해야 합니다.
또 다른 경우도 있습니다.
실제 승인 거래는 한 건인데 DW에 동일한 거래가 두 번 적재되었다면 고객의 실제 결제와 무관하게 내부 분석 데이터가 중복되었을 수 있습니다.
이처럼 중복 문제는 발생 위치에 따라 영향과 해결 방법이 달라집니다.
4. 장애가 발생하면 왜 재처리가 필요할까?
금융 IT 시스템은 장애가 발생하더라도 업무 데이터를 정확하게 복구할 수 있어야 합니다.
특히 데이터 연계와 배치 처리에서는 작업이 중간에 실패할 수 있습니다.
예를 들어 DW 적재 작업이 다음과 같이 진행되었다고 가정하겠습니다.
오전 2시, 총 100만 건의 데이터 적재가 시작됩니다.
오전 2시 10분, 60만 건이 적재됩니다.
오전 2시 15분, 데이터베이스 연결 장애가 발생합니다.
이후 운영담당자가 장애를 복구했습니다.
그렇다면 남은 40만 건만 적재하면 될까요?
반드시 그렇지는 않습니다.
먼저 확인해야 할 사항이 있습니다.
- 실제로 커밋된 데이터는 몇 건인가?
- 실패한 작업의 처리 단위는 무엇인가?
- 적재 완료 상태는 어디에 기록되는가?
- 일부 데이터가 중복 반영되었는가?
- 동일한 작업을 다시 실행해도 안전한가?
여기서 커밋(Commit)이란 데이터베이스에서 수행한 변경 사항을 확정하는 작업을 의미합니다.
데이터가 프로그램상으로 처리된 것처럼 보이더라도 실제로 커밋되었는지는 별도로 확인해야 할 수 있습니다.
따라서 장애 복구에서는 단순히 프로그램을 다시 실행하는 것보다 이미 반영된 데이터와 미처리 데이터를 정확하게 구분하는 과정이 중요합니다.
5. 멱등성(Idempotency)이란 무엇인가?
멱등성은 같은 연산을 여러 번 수행하더라도 최종 결과가 한 번 수행했을 때와 같도록 하는 성질입니다.
수학에서는 어떤 연산을 반복 적용해도 결과가 변하지 않는 성질을 의미합니다.
IT 시스템에서는 동일한 요청이 반복되더라도 의도하지 않은 추가 효과가 발생하지 않도록 설계하는 개념으로 활용됩니다.
쉽게 이해하는 예시
고객의 알림 수신 설정을 '켜짐'으로 변경한다고 가정하겠습니다.
설정을 한 번 켜도 결과는 '켜짐'입니다.
같은 설정 요청을 다시 보내도 결과는 여전히 '켜짐'입니다.
이러한 요청은 멱등적으로 구현하기 비교적 쉽습니다.
반면 고객의 포인트를 1,000점 증가시키는 요청을 생각해 보겠습니다.
한 번 실행하면 1,000점이 증가합니다.
같은 요청을 두 번 실행하면 2,000점이 증가할 수 있습니다.
따라서 이 요청은 별도의 중복 방지 장치 없이 실행하면 멱등적이지 않습니다.
금융 IT에서 중요한 이유
금융 시스템에서는 동일한 업무 요청이 반복 전달될 가능성을 고려해야 합니다.
네트워크 장애나 메시지 재전송이 발생할 수 있기 때문입니다.
따라서 시스템은 다음 질문에 답할 수 있어야 합니다.
"이 요청은 처음 들어온 요청인가, 아니면 이미 처리된 요청인가?"
이 질문에 답할 수 있도록 설계하면 중복 처리를 방지하는 데 도움이 됩니다.
멱등성은 요청이 반복되더라도 업무 결과가 의도치 않게 반복 반영되지 않도록 하는 중요한 설계 원칙입니다.
6. 멱등성을 적용하지 않은 시스템의 문제점
가상의 포인트 적립 시스템을 예로 들어보겠습니다.
고객이 카드 결제로 1,000포인트를 적립받을 예정입니다.
시스템 A가 포인트 시스템 B에 적립 요청을 보냅니다.
멱등성 처리가 없는 경우
- 시스템 A가 1,000포인트 적립을 요청합니다.
- 시스템 B가 포인트를 적립합니다.
- 네트워크 문제로 응답이 유실됩니다.
- 시스템 A가 요청 실패로 판단합니다.
- 시스템 A가 같은 적립 요청을 다시 보냅니다.
- 시스템 B가 다시 1,000포인트를 적립합니다.
결과적으로 고객에게 2,000포인트가 적립될 수 있습니다.
멱등성을 적용한 경우
- 시스템 A가 요청 식별번호 P001과 함께 1,000포인트 적립을 요청합니다.
- 시스템 B가 P001을 처음 처리하는 요청으로 확인합니다.
- 1,000포인트를 적립하고 처리 결과를 저장합니다.
- 응답이 유실됩니다.
- 시스템 A가 동일한 P001 요청을 다시 보냅니다.
- 시스템 B는 P001이 이미 처리된 요청임을 확인합니다.
- 추가 적립 없이 기존 처리 결과를 반환합니다.
최종 적립 포인트는 1,000점입니다.
다만 실제 구현에서는 요청 식별번호의 저장과 포인트 적립이 서로 어긋나지 않도록 트랜잭션 처리 등을 설계해야 합니다.
단순히 요청번호를 조회하는 코드 하나만 추가한다고 모든 중복 문제가 해결되는 것은 아닙니다.
7. 실무 사례: DW 배치 장애 후 60만 건이 중복 적재된 상황
이번에는 DW 운영 상황을 가정해 보겠습니다.
장애 발생 전
어느 카드사에서 매일 승인 거래 데이터를 DW에 적재한다고 가정하겠습니다.
해당 일자의 원천 거래는 총 100만 건입니다.
적재 작업은 10만 건 단위로 처리되도록 구성되어 있습니다.
장애 발생
60만 건의 적재가 완료된 후 데이터베이스 연결 장애가 발생했습니다.
운영담당자는 장애를 복구한 뒤 전체 작업을 다시 실행했습니다.
그런데 적재 프로그램이 기존 데이터를 확인하지 않고 INSERT만 수행하는 구조였다면 어떻게 될까요?
이미 적재된 60만 건이 다시 저장될 수 있습니다.
결과 비교
| 항목 | 정상 기대 결과 | 중복 발생 시 |
| 원천 거래 건수 | 1,000,000건 | 1,000,000건 |
| 최초 적재 완료 | 600,000건 | 600,000건 |
| 재실행 적재 | 미처리 400,000건 | 전체 1,000,000건 |
| DW 최종 건수 | 1,000,000건 | 1,600,000건 |
| 중복 건수 | 0건 | 600,000건 |
위 표는 최초 60만 건이 실제로 커밋되었고, 재실행이 전체 데이터를 추가 INSERT 했으며, 중복을 제한하는 장치가 없다는 가정에 따른 결과입니다.
실제 운영에서 확인해야 할 부분
운영담당자는 단순히 DW 건수가 160만 건이라는 사실만 확인해서는 안 됩니다.
어떤 거래가 중복되었는지 확인해야 합니다.
또한 중복된 거래가 이미 집계 테이블에 반영되었는지, 관련 보고서에 영향을 주었는지도 확인해야 합니다.
원천 데이터와 DW의 거래 건수 및 금액을 비교하는 것은 중요한 출발점입니다.
하지만 거래 식별정보를 기준으로 개별 데이터의 일치 여부까지 확인해야 정확한 영향 범위를 파악할 수 있습니다.
8. 중복 데이터는 어떻게 찾아낼까? SQL 실습
이번에는 SQL을 이용해 중복 데이터를 찾는 방법을 살펴보겠습니다.
가상의 DW 테이블 이름은 DW_APPROVAL이라고 하겠습니다.
주요 컬럼은 다음과 같습니다.
| 컬럼명 | 의미 |
| APPROVAL_NO | 승인번호 |
| APPROVAL_DATE | 승인일시 |
| APPROVAL_AMOUNT | 승인금액 |
| MERCHANT_ID | 가맹점 식별정보 |
| LOAD_TIME | DW 적재일시 |
이 예제에서는 APPROVAL_NO가 원천 시스템에서 유일한 거래 식별자라고 가정합니다.
실제 금융 시스템에서는 승인번호만으로 모든 거래를 유일하게 식별할 수 있다고 단정해서는 안 됩니다. 업무에 따라 거래일자, 기관 식별자, 거래 일련번호 등을 조합한 키가 필요할 수 있습니다.
① 중복된 승인번호 찾기
SELECT
APPROVAL_NO,
COUNT(*) AS DUP_COUNT
FROM DW_APPROVAL
GROUP BY APPROVAL_NO
HAVING COUNT(*) > 1;이 SQL은 승인번호별 건수를 집계한 후 두 건 이상 존재하는 승인번호를 조회합니다.
② 중복 데이터의 상세 내역 확인
SELECT
APPROVAL_NO,
APPROVAL_DATE,
APPROVAL_AMOUNT,
MERCHANT_ID,
LOAD_TIME
FROM DW_APPROVAL
WHERE APPROVAL_NO IN (
SELECT APPROVAL_NO
FROM DW_APPROVAL
GROUP BY APPROVAL_NO
HAVING COUNT(*) > 1
)
ORDER BY APPROVAL_NO, LOAD_TIME;중복된 승인번호의 상세 내역을 확인할 수 있습니다.
③ 중복 건수 계산
SELECT
SUM(DUP_COUNT - 1) AS EXTRA_ROW_COUNT
FROM (
SELECT COUNT(*) AS DUP_COUNT
FROM DW_APPROVAL
GROUP BY APPROVAL_NO
HAVING COUNT(*) > 1
) T;각 승인번호에서 한 건을 제외한 추가 행의 개수를 계산합니다.
단, 이 계산은 승인번호별로 정확히 한 행이 존재해야 한다는 가정이 맞을 때 의미가 있습니다.
SQL 점검 시 주의할 점
중복된 데이터가 발견되었다고 해서 곧바로 DELETE 명령을 실행해서는 안 됩니다.
동일한 승인번호로 여러 종류의 거래 기록이 존재하는 것이 정상적인 데이터 모델일 수도 있기 때문입니다.
따라서 먼저 업무적으로 중복인지 확인해야 합니다.
SQL로 같은 값을 찾는 것과 실제 업무상 중복 거래를 판별하는 것은 서로 다른 과정입니다.
9. 중복 적재를 방지하는 4가지 설계 방법
중복 데이터는 장애가 발생한 후 제거하는 것보다 처음부터 발생하지 않도록 설계하는 것이 중요합니다.
방법 ① 고유 키와 제약조건 활용
업무적으로 유일해야 하는 데이터에 고유 키 또는 UNIQUE 제약조건을 적용할 수 있습니다.
예를 들어 승인번호가 유일한 거래 식별자라면 중복 저장을 제한할 수 있습니다.
다만 실제 데이터 모델에서는 적절한 복합 키를 설계해야 할 수 있습니다.
방법 ② MERGE 또는 UPSERT 활용
MERGE나 UPSERT는 대상 데이터가 이미 존재하는지에 따라 INSERT 또는 UPDATE를 수행하는 방식입니다.
예를 들어 다음과 같은 SQL을 사용할 수 있습니다.
MERGE INTO DW_APPROVAL T
USING STG_APPROVAL S
ON (T.APPROVAL_NO = S.APPROVAL_NO)
WHEN MATCHED THEN
UPDATE SET
T.APPROVAL_AMOUNT = S.APPROVAL_AMOUNT,
T.APPROVAL_DATE = S.APPROVAL_DATE
WHEN NOT MATCHED THEN
INSERT (
APPROVAL_NO,
APPROVAL_DATE,
APPROVAL_AMOUNT
)
VALUES (
S.APPROVAL_NO,
S.APPROVAL_DATE,
S.APPROVAL_AMOUNT
);이 SQL은 개념 설명을 위한 예제입니다.
STG_APPROVAL은 원천에서 수집한 데이터를 임시로 저장하는 스테이징 테이블입니다.
실제 적용 시에는 원천 데이터의 중복 여부, 변경 순서, 트랜잭션 격리 수준, DBMS별 MERGE 동작 등을 검토해야 합니다.
특히 원천 데이터에 동일한 키가 여러 건 존재하면 MERGE 실행 자체가 실패하거나 예상하지 못한 결과가 발생할 수 있습니다.
방법 ③ 처리 완료 상태 관리
배치 작업에서 처리한 데이터의 범위와 완료 상태를 관리하는 방식입니다.
예를 들어 처리 기준일, 배치 실행번호, 완료된 구간 등을 기록할 수 있습니다.
장애 발생 후 재실행할 때는 이 정보를 활용하여 재처리 범위를 판단합니다.
단, 완료 상태와 실제 데이터 커밋 결과가 일치하도록 설계해야 합니다.
방법 ④ 멱등성 키 활용
요청마다 고유한 식별번호를 부여하여 동일한 요청이 반복 처리되는 것을 방지하는 방법입니다.
이미 처리한 요청이라면 추가 처리하지 않고 기존 결과를 반환할 수 있습니다.
이는 API, 메시지 처리, 포인트 적립 등 다양한 업무에 활용될 수 있습니다.
10. 메시지 재전송과 멱등성 키의 역할
금융 IT 시스템에서는 메시지 기반 연계를 활용하는 경우가 있습니다.
이러한 시스템에서는 메시지가 한 번만 전달된다고 가정하면 문제가 발생할 수 있습니다.
At-most-once와 At-least-once
메시지 전달 방식을 설명할 때 다음 개념이 자주 사용됩니다.
At-most-once
메시지를 최대 한 번 전달하는 방식입니다.
중복 전달 가능성은 줄일 수 있지만, 장애 상황에서는 메시지가 유실될 수 있습니다.
At-least-once
메시지가 적어도 한 번 전달되도록 재전송 등을 활용하는 방식입니다.
메시지 유실 가능성을 줄이는 데 도움이 되지만 중복 전달 가능성이 존재합니다.
Exactly-once는 무엇일까?
Exactly-once는 메시지 처리에서 한 번만 효과가 반영되는 성질이나 보장 수준을 설명할 때 사용됩니다.
다만 특정 메시지 플랫폼이 Exactly-once 기능을 제공한다고 해서 외부 데이터베이스나 다른 업무 시스템에 대한 모든 처리가 자동으로 정확히 한 번만 수행되는 것은 아닙니다.
보장 범위와 외부 시스템의 트랜잭션 처리를 함께 고려해야 합니다.
멱등성 키를 활용하는 이유
동일한 요청이 여러 번 전달되더라도 동일한 업무 결과가 반복 반영되지 않도록 하기 위해서입니다.
예를 들어 포인트 적립 요청에 POINT-20261020-0001이라는 식별번호를 부여했다고 가정하겠습니다.
이 요청이 두 번 전달되더라도 수신 시스템은 동일한 요청인지 판단할 수 있습니다.
다만 식별번호를 저장하는 과정과 실제 업무 처리 결과가 원자적으로 관리되도록 설계해야 합니다.
또한 서로 다른 요청에 동일한 키가 사용되지 않도록 키의 생성 범위와 유효기간을 정의해야 합니다.
11. 중복 데이터를 발견했다면 어떻게 복구해야 할까?
실제 운영에서 중복 데이터를 발견했다면 무조건 삭제하는 방식으로 대응해서는 안 됩니다.
먼저 중복이 발생한 원인과 영향 범위를 확인해야 합니다.
1단계. 중복 발생 사실 확인
중복이 의심되는 거래를 식별합니다.
거래 식별정보와 적재 시점 등을 확인합니다.
2단계. 업무상 중복 여부 판단
동일한 거래가 잘못 반복 적재된 것인지 확인합니다.
서로 다른 정상 거래를 중복으로 오인하지 않도록 주의해야 합니다.
3단계. 영향 범위 확인
중복 데이터가 어떤 테이블과 보고서에 영향을 주었는지 확인합니다.
4단계. 원인 분석
배치 재실행, 메시지 재전송, 프로그램 오류 등 원인을 확인합니다.
5단계. 복구 방안 수립
데이터 정정, 재적재, 집계 재생성 등 적절한 복구 방안을 결정합니다.
6단계. 승인된 절차에 따른 복구
운영 환경에서는 변경 통제와 승인 절차에 따라 복구를 수행해야 합니다.
7단계. 복구 후 정합성 검증
원천 데이터와 DW의 건수, 금액, 거래 식별정보 등을 다시 비교합니다.
8단계. 재발 방지
동일한 장애가 반복되지 않도록 적재 로직과 재처리 절차를 개선합니다.
특히 금융 데이터는 고객의 거래 정보나 보고서에 영향을 줄 수 있으므로 데이터 정정 작업의 추적 가능성과 검증 절차가 중요합니다.
12. 멱등성을 적용해도 주의해야 할 문제
멱등성을 적용하면 모든 중복 문제가 사라질까요?
그렇지는 않습니다.
멱등성은 중복 처리를 방지하는 데 중요한 개념이지만 실제 구현에서는 여러 조건을 고려해야 합니다.
① 업무상 동일 거래의 정의
같은 금액과 같은 가맹점에서 발생한 거래라도 서로 다른 정상 거래일 수 있습니다.
따라서 금액이나 시간만으로 중복 여부를 판단하면 안 됩니다.
② 요청 식별번호의 유일성
서로 다른 요청에 같은 식별번호가 부여되면 정상 거래가 차단될 수 있습니다.
③ 동시 요청 처리
동일한 요청이 거의 동시에 들어오면 두 처리 과정이 모두 미처리 상태로 판단할 수 있습니다.
따라서 고유 제약조건, 잠금, 트랜잭션 등 적절한 동시성 제어가 필요합니다.
④ 처리 결과 저장 실패
업무 처리는 완료되었지만 처리 결과 저장에 실패하면 재요청 시 중복 처리가 발생할 수 있습니다.
업무 처리와 중복 방지 기록의 일관성을 유지하는 설계가 중요합니다.
⑤ 요청 내용 변경
같은 멱등성 키를 사용하면서 요청 금액이나 대상이 달라지는 경우도 고려해야 합니다.
이때는 기존 요청과 다른 요청으로 판단하여 오류를 반환하는 등의 정책이 필요할 수 있습니다.
⑥ 데이터 변경 이력
DW에서는 최신 상태만 관리하는 것이 아니라 변경 이력을 보존해야 하는 경우도 있습니다.
이러한 구조에서는 같은 거래 식별번호가 여러 행에 존재하는 것이 정상일 수 있습니다.
따라서 멱등성 설계는 데이터 모델과 업무 목적에 맞게 적용해야 합니다.
13. 금융 IT 운영담당자의 중복 데이터 점검 체크리스트
DW나 데이터 연계 시스템을 운영한다면 다음 항목을 확인하는 것이 좋습니다.
데이터 식별
- 거래를 유일하게 구분하는 업무 키가 정의되어 있는가?
- 중복 데이터와 정상적인 이력 데이터를 구분할 수 있는가?
- 원천과 DW에서 동일한 거래를 추적할 수 있는가?
적재 및 재처리
- 배치 재실행 시 기존 데이터가 중복 적재되지 않는가?
- 재처리 대상 범위를 명확하게 확인할 수 있는가?
- 처리 완료 상태와 실제 커밋 결과가 일치하는가?
- 적재 프로그램이 동일한 입력에 대해 안전하게 재실행되는가?
메시지 연계
- 메시지 재전송 시 중복 처리 방지 기능이 있는가?
- 요청 식별번호가 적절하게 관리되는가?
- 동일한 요청이 동시에 들어오는 상황을 고려했는가?
정합성 검증
- 원천과 DW의 거래 건수를 비교하는가?
- 거래 금액을 동일한 기준으로 비교하는가?
- 개별 거래 식별정보를 기준으로 누락과 중복을 확인하는가?
- 중복 적재가 집계 테이블과 보고서에 미친 영향을 확인할 수 있는가?
장애 복구
- 재처리 전에 데이터 반영 상태를 확인하는가?
- 복구 작업의 승인과 이력이 관리되는가?
- 복구 후 정합성 검증 절차가 존재하는가?
- 장애 원인을 분석하고 재발 방지 조치를 수행하는가?
이러한 항목은 특정 회사의 내부 점검표가 아니라 일반적인 데이터 처리 및 운영 원칙을 바탕으로 구성한 예시입니다.
14. 자주 묻는 질문
Q1. 카드 승인 알림이 두 번 오면 실제 결제도 두 번 된 건가요?
반드시 그렇지는 않습니다.
알림이 중복 전송되었을 수도 있습니다.
카드사 앱에서 실제 승인 내역을 확인하고, 서로 다른 거래가 존재하는지 확인하는 것이 좋습니다.
Q2. DW에서 같은 승인번호가 두 번 조회되면 무조건 중복 오류인가요?
그렇지 않습니다.
테이블의 업무 목적과 데이터 모델에 따라 동일한 승인번호로 여러 이력 데이터가 존재할 수 있습니다.
먼저 해당 테이블의 업무 키와 저장 기준을 확인해야 합니다.
Q3. 배치 프로그램을 다시 실행하면 반드시 중복 데이터가 발생하나요?
아닙니다.
고유 키, MERGE, 처리 완료 상태 관리 등 적절한 중복 방지 구조가 있다면 안전하게 재실행할 수 있습니다.
Q4. 멱등성을 적용하면 메시지가 중복 전달되지 않나요?
멱등성은 메시지 자체의 중복 전달을 반드시 막는 개념은 아닙니다.
동일한 요청이 반복되더라도 업무 결과가 중복 반영되지 않도록 하는 데 초점이 있습니다.
Q5. MERGE를 사용하면 모든 중복 적재 문제가 해결되나요?
그렇지 않습니다.
업무 키 정의, 원천 데이터 중복, 동시성 처리, 변경 순서 등을 함께 고려해야 합니다.
Q6. 중복 데이터를 발견하면 SQL DELETE로 제거해도 되나요?
운영 환경에서는 임의로 삭제해서는 안 됩니다.
업무상 중복 여부와 영향 범위를 확인하고 승인된 절차에 따라 복구해야 합니다.
Q7. 금융 IT에서 멱등성이 특히 중요한 이유는 무엇인가요?
금융거래는 동일한 요청의 반복 처리로 금액이나 거래 상태가 잘못 반영되면 문제가 발생할 수 있기 때문입니다.
따라서 장애 복구와 재전송 상황에서도 업무 결과의 정확성을 유지하는 것이 중요합니다.
15. 마무리｜안전한 재처리가 가능한 시스템이 좋은 시스템이다
금융 IT 시스템에서는 데이터가 여러 시스템을 거쳐 전달됩니다.
이 과정에서 네트워크 장애, 메시지 재전송, 배치 재실행 등 다양한 상황이 발생할 수 있습니다.
따라서 동일한 데이터나 요청이 여러 번 전달될 가능성을 고려해야 합니다.
이번 글의 핵심을 네 가지로 정리하겠습니다.
첫째, 중복 알림, 중복 승인, 중복 적재는 서로 다른 문제이며 발생 위치에 따라 대응 방법이 달라집니다.
둘째, 장애 복구 과정에서는 이미 처리된 데이터와 미처리 데이터를 정확하게 구분해야 합니다.
셋째, 멱등성은 동일한 요청이 반복되더라도 업무 결과가 의도하지 않게 반복 반영되지 않도록 하는 중요한 설계 원칙입니다.
넷째, 고유 키, MERGE, 처리 완료 상태 관리, 멱등성 키 등 여러 방법을 업무 특성에 맞게 조합해야 합니다.
금융 IT 시스템을 운영하다 보면 장애 자체를 완전히 없애는 것은 현실적으로 어렵습니다.
네트워크는 지연될 수 있고, 프로그램은 실패할 수 있으며, 배치 작업은 중간에 중단될 수 있습니다.
따라서 중요한 것은 장애가 절대 발생하지 않는 시스템을 만드는 것만이 아닙니다.
장애가 발생하더라도 데이터를 정확하게 복구하고, 동일한 업무를 안전하게 다시 처리할 수 있도록 설계하는 것입니다.
좋은 금융 IT 시스템은 정상 상황에서만 잘 동작하는 시스템이 아니라, 실패한 작업을 다시 실행해도 데이터의 정확성을 유지할 수 있는 시스템입니다.
함께 읽으면 좋은 글
[생활 속 금융 기술 #22] 카드사 DW 데이터는 어떻게 만들어질까?｜ETL·ELT·CDC의 차이와 데이터 적재 과정
카드사 DW 데이터가 수집·변환·적재되는 과정을 알아봅니다.
[생활 속 금융 기술 #15] DW 배치 작업이 실패하면 어떻게 될까?｜데이터 적재 장애 원인 7가지와 복구 절차
DW 적재 장애와 복구 절차를 살펴봅니다.
[생활 속 금융 기술 #14] 카드 승인 금액과 DW 보고서 금액이 다른 이유 7가지｜금융 IT 담당자의 데이터 정합성 점검 방법
업무 시스템과 DW의 거래 금액 차이를 확인하는 방법을 설명합니다.
[생활 속 금융 기술 #18] 카드 승인 문자가 두 번 왔다면?｜중복 승인과 중복 결제의 차이, 확인 방법 7가지
소비자 관점에서 중복 승인과 중복 알림을 구분하는 방법을 알아봅니다.
[생활 속 금융 기술 #19] 카드 결제는 승인됐는데 가맹점은 실패라고 한다면?｜승인 응답 유실과 거래 상태 확인의 원리
승인 응답이 유실되었을 때 발생하는 문제와 대응 원리를 살펴봅니다.
다음 글 예고
[생활 속 금융 기술 #24] 금융 IT 시스템은 왜 데이터를 즉시 반영하지 못할까?｜실시간 처리·비동기 처리·최종 일관성의 원리
카드 결제는 완료되었는데 앱의 이용 내역에는 아직 표시되지 않는 경우가 있습니다.
또한 업무 시스템의 데이터가 변경되었지만 DW 보고서에는 이전 값이 표시될 수도 있습니다.
이러한 현상은 왜 발생할까요?
다음 글에서는 금융 IT 시스템에서 데이터가 서로 다른 시점에 반영되는 이유와 실시간 처리, 비동기 처리, 최종 일관성(Eventual Consistency)의 개념을 실제적인 사례로 설명하겠습니다.
