편의점에서 카드로 결제했는데 단말기에는 '승인 실패'라고 표시됩니다. 그런데 카드사 앱에는 승인 알림이 도착했습니다.
고객은 결제가 되었는지 궁금하고, 가맹점은 다시 결제해야 하는지 판단하기 어렵습니다.
이런 상황에서 금융 IT 운영자는 어디서부터 문제를 확인해야 할까요?
카드 승인 시스템은 여러 서버와 네트워크를 거쳐 거래를 처리합니다. 따라서 한 시스템의 로그만 확인해서는 장애 원인을 정확하게 파악하기 어려울 수 있습니다.
이번 글에서는 카드 승인 요청이 여러 시스템을 통과하는 과정에서 로그가 어떻게 남는지 살펴보고, 거래번호와 Trace ID를 활용해 하나의 거래를 추적하는 방법을 SQL 실습과 함께 알아보겠습니다.
※ 이 글의 시스템 구성과 데이터는 금융 IT 운영 원리를 설명하기 위한 가상 사례입니다. 실제 카드사 내부 시스템의 로그나 고객 정보를 사용하지 않았습니다.
1. 카드 승인은 성공했는데 단말기에는 왜 실패라고 표시될까?
카드 승인 과정은 일반적으로 다음과 같은 흐름을 거칩니다.
가맹점 단말기 → VAN사 → 카드사 승인 시스템 → VAN사 → 가맹점 단말기
카드사는 거래의 승인 여부를 판단한 뒤 결과를 응답합니다.
하지만 승인 판단이 정상적으로 끝났다고 해서 그 결과가 반드시 가맹점 단말기까지 전달되는 것은 아닙니다.
예를 들어 다음과 같은 상황이 발생할 수 있습니다.
- 카드사 승인 시스템에서 거래를 정상 승인했습니다.
- 카드사가 VAN사로 승인 응답을 전송했습니다.
- VAN사 또는 통신 구간에서 지연이 발생했습니다.
- 가맹점 단말기는 정해진 시간 안에 응답을 받지 못했습니다.
- 단말기에는 통신 오류 또는 타임아웃이 표시되었습니다.
이 경우 중요한 것은 거래 승인 결과와 단말기의 응답 수신 결과가 서로 다른 정보라는 점입니다.
운영자는 카드사 승인 여부뿐 아니라 응답이 어느 구간까지 전달되었는지도 확인해야 합니다.
2. 장애 분석의 핵심은 거래를 식별하는 세 가지 ID
금융 IT 시스템에서는 하나의 거래를 식별하기 위해 여러 종류의 식별자를 사용합니다.
대표적으로 거래번호, Request ID, Trace ID가 있습니다.
① 거래번호(Transaction ID)
거래번호는 업무적으로 거래를 구분하기 위한 식별자입니다.
승인 거래, 취소 거래, 정산 데이터 등을 연결하는 데 활용할 수 있습니다.
다만 거래번호의 생성 주체와 유일성 범위는 시스템마다 다릅니다. 하나의 승인 거래에 여러 내부 식별자가 연결될 수도 있습니다.
② Request ID
Request ID는 개별 요청을 구분하는 식별자입니다.
동일한 거래를 재시도하면 요청마다 서로 다른 Request ID를 발급하도록 설계할 수 있습니다.
예를 들어 다음과 같습니다.
| 거래번호 | Request ID | 요청 결과 |
| TX1001 | REQ001 | 응답 타임아웃 |
| TX1001 | REQ002 | 상태 확인 요청 |
업무적으로는 같은 거래를 다루지만 기술적으로는 서로 다른 요청입니다.
이 구분이 없으면 재시도 과정에서 발생한 여러 요청을 하나의 요청으로 오인할 수 있습니다.
③ Trace ID
Trace ID는 여러 서비스에 걸친 하나의 처리 흐름을 연결하는 식별자입니다.
예를 들어 API Gateway, 승인 서비스, 응답 처리 서비스가 동일한 Trace ID를 로그에 기록하면 운영자는 서비스별 로그를 하나의 흐름으로 묶어 확인할 수 있습니다.
분산 추적 시스템에서는 일반적으로 Trace ID와 함께 각 작업 구간을 나타내는 Span ID도 사용합니다.
다만 모든 금융 시스템이 Trace ID를 사용하는 것은 아닙니다. 기존 시스템에서는 거래번호와 전문 추적번호, 별도의 로그 상관관계 ID를 이용하기도 합니다.
핵심은 이름 자체보다 여러 시스템에서 동일한 거래 흐름을 연결할 수 있는 식별 체계를 갖추는 것입니다.
3. 가상 장애 사례: 카드사는 승인했는데 가맹점은 타임아웃
다음과 같은 장애 상황을 가정하겠습니다.
2026년 11월 3일 오전 10시 15분, 고객이 45,000원을 카드로 결제했습니다.
카드사 승인 시스템은 정상 승인했지만 가맹점 단말기에는 타임아웃이 발생했습니다.
운영자가 확인한 가상 로그는 다음과 같습니다.
| 시각 | 시스템 | 처리 내용 |
| 10:15:01.100 | API Gateway | 승인 요청 수신 |
| 10:15:01.180 | 승인 서비스 | 승인 처리 시작 |
| 10:15:01.320 | 승인 서비스 | 승인 완료 |
| 10:15:01.350 | 응답 서비스 | 승인 응답 생성 |
| 10:15:04.500 | VAN 연계 서비스 | 응답 전송 타임아웃 |
각 로그가 서로 다른 시스템에 저장되어 있더라도 동일한 Trace ID를 기록한다면 하나의 거래 흐름으로 연결할 수 있습니다.
이 사례에서 확인되는 사실은 다음과 같습니다.
카드사 내부 승인 처리에는 성공했지만, VAN 연계 서비스의 응답 전송 과정에서 타임아웃이 기록되었습니다.
다만 이 로그만으로 실제 가맹점 단말기가 응답을 받았는지, VAN사가 어떤 상태로 처리했는지까지 확정할 수는 없습니다.
정확한 판단을 위해서는 VAN 측 거래 상태, 응답 수신 확인 정보, 승인 원장 등을 추가로 대사해야 합니다.
4. SQL 실습: 여러 시스템의 로그를 하나의 거래로 연결하기
이번에는 PostgreSQL을 이용해 가상 카드 승인 로그를 조회하겠습니다.
실습 목표는 다음과 같습니다.
하나의 Trace ID로 여러 서비스의 로그를 조회하고, 승인 완료 이후 어느 단계에서 오류가 발생했는지 확인하는 것입니다.
아래 코드는 교육용 독립 실습 환경에서 실행하는 것을 전제로 합니다. 운영 데이터베이스에서 그대로 실행하지 마세요.
① 로그 테이블 생성
CREATE TABLE IF NOT EXISTS demo_card_auth_logs (
log_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
transaction_id VARCHAR(30) NOT NULL,
request_id VARCHAR(30) NOT NULL,
trace_id VARCHAR(50) NOT NULL,
service_name VARCHAR(50) NOT NULL,
event_type VARCHAR(50) NOT NULL,
event_status VARCHAR(20) NOT NULL,
event_time TIMESTAMP(3) NOT NULL
);이 테이블에는 다음 정보를 저장합니다.
- transaction_id: 업무 거래번호
- request_id: 개별 요청 식별자
- trace_id: 서비스 간 처리 흐름 식별자
- service_name: 로그를 기록한 시스템
- event_type: 처리 단계
- event_status: 처리 결과
- event_time: 이벤트 발생 시각
② 가상 승인 로그 입력
INSERT INTO demo_card_auth_logs
(transaction_id, request_id, trace_id,
service_name, event_type, event_status, event_time)
VALUES
('TX1001', 'REQ001', 'TRACE-A001',
'API_GATEWAY', 'REQUEST_RECEIVED', 'SUCCESS',
'2026-11-03 10:15:01.100'),
('TX1001', 'REQ001', 'TRACE-A001',
'AUTH_SERVICE', 'AUTH_STARTED', 'SUCCESS',
'2026-11-03 10:15:01.180'),
('TX1001', 'REQ001', 'TRACE-A001',
'AUTH_SERVICE', 'AUTH_APPROVED', 'SUCCESS',
'2026-11-03 10:15:01.320'),
('TX1001', 'REQ001', 'TRACE-A001',
'RESPONSE_SERVICE', 'RESPONSE_CREATED', 'SUCCESS',
'2026-11-03 10:15:01.350'),
('TX1001', 'REQ001', 'TRACE-A001',
'VAN_INTERFACE', 'RESPONSE_TIMEOUT', 'ERROR',
'2026-11-03 10:15:04.500'),
('TX1002', 'REQ003', 'TRACE-B002',
'API_GATEWAY', 'REQUEST_RECEIVED', 'SUCCESS',
'2026-11-03 10:16:02.100'),
('TX1002', 'REQ003', 'TRACE-B002',
'AUTH_SERVICE', 'AUTH_DECLINED', 'DECLINED',
'2026-11-03 10:16:02.280');TX1001은 승인 완료 이후 응답 전송 타임아웃이 발생한 거래이고, TX1002는 정상적으로 거절 판단이 내려진 별도 거래입니다.
③ Trace ID로 전체 로그 조회
SELECT
event_time,
service_name,
event_type,
event_status
FROM demo_card_auth_logs
WHERE trace_id = 'TRACE-A001'
ORDER BY event_time, log_id;예상 결과
| 시각 | 서비스 | 이벤트 | 상태 |
| 10:15:01.100 | API_GATEWAY | REQUEST_RECEIVED | SUCCESS |
| 10:15:01.180 | AUTH_SERVICE | AUTH_STARTED | SUCCESS |
| 10:15:01.320 | AUTH_SERVICE | AUTH_APPROVED | SUCCESS |
| 10:15:01.350 | RESPONSE_SERVICE | RESPONSE_CREATED | SUCCESS |
| 10:15:04.500 | VAN_INTERFACE | RESPONSE_TIMEOUT | ERROR |
이 결과에서 중요한 부분은 AUTH_APPROVED와 RESPONSE_TIMEOUT이 같은 Trace ID에 존재한다는 사실입니다.
즉, 승인 판단의 성공과 응답 전송의 실패가 하나의 처리 흐름에서 발생했다는 것을 확인할 수 있습니다.
단, RESPONSE_TIMEOUT은 해당 연계 서비스가 타임아웃을 기록했다는 뜻이지, 외부 시스템이 응답을 전혀 받지 못했다는 사실을 단독으로 증명하지는 않습니다.
5. SQL로 승인 이후 응답 오류가 발생한 거래 찾기
실제 운영에서는 하나의 Trace ID를 직접 조회하는 것뿐 아니라, 특정 시간대에 같은 유형의 장애가 얼마나 발생했는지 확인하는 작업도 중요합니다.
다음 SQL은 승인 완료 로그와 응답 타임아웃 로그가 모두 존재하는 처리 흐름을 찾습니다.
SELECT
transaction_id,
trace_id,
MIN(event_time) AS first_event_time,
MAX(event_time) AS last_event_time
FROM demo_card_auth_logs
GROUP BY transaction_id, trace_id
HAVING
COUNT(*) FILTER (
WHERE event_type = 'AUTH_APPROVED'
) > 0
AND
COUNT(*) FILTER (
WHERE event_type = 'RESPONSE_TIMEOUT'
) > 0;예상 결과
| 거래번호 | Trace ID | 최초 이벤트 | 최종 이벤트 |
| TX1001 | TRACE-A001 | 10:15:01.100 | 10:15:04.500 |
TX1002는 승인 거절 거래이므로 조회 결과에 포함되지 않습니다.
이러한 SQL은 승인 성공 후 응답 단계에서 문제가 발생한 거래를 선별하는 데 유용합니다.
다만 실제 운영 환경에서는 로그 유실, 비동기 기록 지연, 재시도에 따른 복수 Trace ID, 서로 다른 서버의 시계 오차 등을 고려해야 합니다.
따라서 조회 결과는 장애 분석 후보 거래 목록으로 활용하고, 최종 거래 상태는 승인 원장 및 외부 연계 기록과 대사해야 합니다.
6. Request ID와 Trace ID를 함께 관리해야 하는 이유
이번 실습에서는 하나의 승인 요청에 하나의 Trace ID를 부여했습니다.
하지만 실제 시스템에서는 재시도 방식에 따라 여러 Request ID가 동일한 Trace ID를 공유하거나, 새로운 Trace ID를 발급받을 수 있습니다.
예를 들어 최초 요청이 타임아웃된 뒤 상태 확인 API를 호출한다면 다음과 같이 관리할 수 있습니다.
| 구분 | 거래번호 | Request ID | Trace ID |
| 최초 승인 요청 | TX1001 | REQ001 | TRACE-A001 |
| 거래 상태 확인 | TX1001 | REQ002 | TRACE-C003 |
이 경우 Trace ID만으로는 두 요청이 같은 업무 거래에 속한다는 사실을 알기 어렵습니다.
반면 거래번호를 함께 관리하면 두 요청을 업무적으로 연결할 수 있습니다.
따라서 로그 설계에서는 다음 세 가지 관계를 고려하는 것이 좋습니다.
- 거래번호로 같은 업무 거래를 찾을 수 있어야 합니다.
- Request ID로 개별 요청과 재시도를 구분할 수 있어야 합니다.
- Trace ID로 하나의 요청이 여러 서비스에서 처리된 과정을 추적할 수 있어야 합니다.
이 세 가지를 적절히 조합하면 장애 분석의 정확도와 효율을 높일 수 있습니다.
7. 실제 금융 IT 운영에서는 어떤 순서로 확인할까?
카드 승인 관련 장애가 접수되었다면 다음과 같은 순서로 분석할 수 있습니다.
1단계. 거래 식별
고객이 제공한 거래 시각, 금액, 가맹점 정보 등을 이용해 해당 거래를 찾습니다.
개인정보와 카드번호는 승인된 업무 절차에 따라 최소한으로 조회해야 합니다.
2단계. 승인 원장 확인
거래가 실제 승인되었는지, 거절되었는지, 취소되었는지 확인합니다.
3단계. 요청 로그 확인
승인 요청이 어느 시스템까지 전달되었는지 확인합니다.
4단계. 응답 로그 확인
승인 응답 생성, 전송, 수신 확인 과정에서 타임아웃이나 오류가 발생했는지 살펴봅니다.
5단계. 외부 연계 상태 확인
필요한 경우 VAN사 등 연계 기관의 거래 상태와 대사합니다.
6단계. 후속 조치
확인된 거래 상태와 업무 절차에 따라 재조회, 정정, 취소 여부 등을 판단합니다.
여기서 주의할 점은 타임아웃이 발생했다는 이유만으로 승인 요청을 무조건 다시 전송해서는 안 된다는 것입니다.
이미 승인된 거래를 중복 요청하면 시스템 설계와 중복 방지 장치에 따라 예상하지 못한 결과가 발생할 수 있습니다.
재시도 전에 원거래 상태를 확인하고, 시스템에서 제공하는 중복 방지 키와 업무 절차를 따라야 합니다.
8. 로그를 많이 남기는 것보다 중요한 것
로그가 많다고 반드시 장애 분석이 쉬워지는 것은 아닙니다.
정작 필요한 거래번호나 처리 단계가 기록되지 않았다면 수많은 로그를 확인하더라도 원인을 찾기 어렵습니다.
반대로 로그에 카드번호, 인증정보, 개인정보를 과도하게 기록하면 보안 위험이 커집니다.
따라서 금융 IT 로그 설계에서는 다음과 같은 원칙이 중요합니다.
- 업무 거래와 기술 요청을 연결할 수 있는 식별자를 기록합니다.
- 승인·거절·응답·타임아웃 등 주요 처리 단계를 구분합니다.
- 서비스 간 시각을 비교할 수 있도록 시계 동기화와 시간대 표기를 관리합니다.
- 카드번호, 인증정보, 민감정보는 로그에 불필요하게 남기지 않습니다.
- 로그 접근 권한과 보존 기간을 관련 규정 및 내부 정책에 맞게 관리합니다.
- 로그가 없거나 일부 유실된 상황도 고려해 거래 원장과 대사할 수 있도록 설계합니다.
특히 카드 결제 환경에서는 적용되는 PCI DSS 요구사항과 국내 관련 법령, 회사의 보안 정책을 함께 확인해야 합니다.
9. 마무리: 카드 승인 장애는 하나의 로그만으로 판단하기 어렵다
이번 글에서는 카드 승인 장애를 추적할 때 필요한 거래번호, Request ID, Trace ID의 역할을 살펴봤습니다.
또한 SQL을 이용해 여러 시스템의 로그를 연결하고, 승인 완료 이후 응답 타임아웃이 발생한 거래를 찾는 방법을 실습했습니다.
핵심은 다음과 같습니다.
승인 여부는 업무 거래 상태로 확인하고, 장애 발생 구간은 시스템 로그를 연결해 분석해야 합니다.
로그는 장애 원인을 찾는 중요한 단서이지만, 모든 거래 상태를 확정하는 유일한 근거는 아닙니다.
금융 IT 운영에서는 로그, 승인 원장, 외부 연계 기록을 함께 확인하는 과정이 중요합니다.
이러한 원리를 이해하면 카드 결제뿐 아니라 계좌 이체, 간편결제, API 연계, 데이터 처리 시스템의 장애 분석에도 응용할 수 있습니다.
