우리는 신용카드를 사용할 때 카드사 전산 시스템이 어떻게 구성되어 있는지 거의 생각하지 않습니다.
카드를 단말기에 접촉하면 결제가 이루어지고, 카드사 앱을 실행하면 이용 내역이 표시됩니다.
매월 결제일이 되면 카드 대금이 청구되고, 카드사는 고객의 이용 실적을 분석하여 다양한 혜택과 서비스를 제공합니다.
소비자 입장에서는 이 모든 일이 하나의 카드사에서 이루어집니다.
그런데 실제 금융 IT 시스템은 하나의 거대한 프로그램으로 모든 업무를 처리하는 구조가 아닙니다.
카드사에는 승인, 회원, 한도, 매입, 청구, 입금, 채권, 고객 서비스, 데이터 분석 등 다양한 업무를 담당하는 시스템이 존재합니다.
그리고 이러한 시스템을 설명할 때 자주 등장하는 용어가 있습니다.
바로 계정계, 정보계, 채널계입니다.
처음 듣는 사람에게는 다소 어렵게 느껴질 수 있지만, 각 시스템의 역할을 이해하면 카드사가 어떻게 운영되는지 훨씬 쉽게 알 수 있습니다.
예를 들어 고객이 편의점에서 30,000원을 결제했다고 가정해 보겠습니다.
카드사는 결제 가능 여부를 판단해야 합니다.
고객은 앱에서 승인 내역을 확인하고 싶어 합니다.
며칠 후 카드사는 해당 거래의 매입 정보를 처리하고, 청구 대상 금액을 계산해야 합니다.
또한 분석 담당자는 고객의 월별 카드 이용 실적을 분석할 수도 있습니다.
이 모든 업무를 하나의 시스템에서 처리하면 편리할 것 같지만, 실제로는 업무 특성에 따라 시스템을 구분하는 편이 안정성과 운영 효율 측면에서 유리할 수 있습니다.
이번 글에서는 카드사 전산 시스템의 기본 구조와 계정계·정보계·채널계의 역할을 알아보고, 실제 카드 결제 데이터가 각 시스템을 거쳐 어떻게 활용되는지 살펴보겠습니다.
※ 본문은 금융 IT 시스템의 일반적인 구조를 이해하기 위한 설명입니다. 계정계·정보계·채널계의 구분과 업무 배치는 금융회사마다 다르며, 특히 승인계·대외계 등은 별도 영역으로 운영될 수 있습니다. 실제 특정 카드사의 내부 아키텍처를 설명하는 글은 아닙니다.
전체 목차
- 카드사 전산 시스템을 하나로 운영하지 않는 이유
- 계정계·정보계·채널계란 무엇인가?
- 계정계: 카드사의 핵심 거래를 처리하는 시스템
- 정보계: 거래 데이터를 분석 정보로 만드는 시스템
- 채널계: 고객과 카드사를 연결하는 시스템
- 승인계와 대외계는 어디에 속할까?
- 실제 사례: 30,000원 카드 결제가 처리되는 과정
- 시스템별 데이터 처리 방식의 차이
- 계정계와 정보계의 금액이 다를 수 있는 이유
- 카드사 DW는 왜 별도로 운영할까?
- 시스템 간 데이터는 어떻게 전달될까?
- 시스템을 분리하면 장애 대응에 어떤 장점이 있을까?
- 금융 IT 운영담당자가 확인하는 핵심 점검 항목
- 카드사 시스템 구조에 대한 자주 묻는 질문
- 마무리
1. 카드사 전산 시스템을 하나로 운영하지 않는 이유
카드사의 IT 시스템을 이해하려면 먼저 금융회사가 처리하는 업무의 특성을 살펴봐야 합니다.
카드사는 단순히 카드 결제 승인만 처리하는 회사가 아닙니다.
카드 발급부터 회원 관리, 승인, 매입, 청구, 입금, 채권 관리, 고객 상담, 마케팅, 통계 분석 등 다양한 업무를 수행합니다.
이러한 업무는 처리 방식이 서로 다릅니다.
예를 들어보겠습니다
카드 승인 업무에서는 고객이 결제를 시도할 때 빠르게 결과를 반환하는 것이 중요합니다.
반면 고객의 1년간 카드 이용 패턴을 분석하는 업무는 상대적으로 많은 데이터를 조회하고 집계하는 것이 중요합니다.
두 업무를 같은 데이터베이스에서 무분별하게 처리하면 어떤 문제가 발생할까요?
대량의 분석 작업이 시스템 자원을 사용하면서 실시간 거래 처리 성능에 영향을 줄 수 있습니다.
물론 현대적인 시스템은 자원 격리와 분산 처리를 통해 이런 영향을 줄일 수 있습니다.
하지만 업무별로 요구되는 성능, 가용성, 데이터 처리 방식이 다르다는 점은 변하지 않습니다.
따라서 금융회사는 업무의 성격에 따라 시스템을 구분하여 운영할 수 있습니다.
핵심은 업무별 처리 목적이 다르기 때문에 시스템의 역할도 달라진다는 것입니다.
2. 계정계·정보계·채널계란 무엇인가?
금융 IT에서는 업무 시스템을 설명할 때 계정계, 정보계, 채널계라는 용어를 자주 사용합니다.
간단히 설명하면 다음과 같습니다.
- 계정계: 금융거래와 관련된 핵심 업무 데이터를 처리하고 관리하는 영역
- 정보계: 업무 데이터를 수집·가공하여 분석과 의사결정을 지원하는 영역
- 채널계: 고객이나 외부 이용자가 금융 서비스를 이용할 수 있도록 연결하는 영역
이 세 가지는 시스템의 목적에 따른 개념적인 구분입니다.
모든 카드사가 동일한 이름이나 경계로 시스템을 운영하는 것은 아닙니다.
시스템별 역할 비교
| 구분 | 계정계 | 정보계 | 채널계 |
| 주요 목적 | 핵심 금융업무 처리 | 데이터 분석 및 활용 | 고객 서비스 제공 |
| 주요 업무 | 회원·한도·청구·입금 등 | DW·통계·분석·보고 | 앱·웹·고객 접점 |
| 데이터 특성 | 거래 중심 | 집계·이력·분석 중심 | 조회·요청·응답 중심 |
| 중요 요소 | 정확성·일관성·가용성 | 데이터 품질·분석 성능 | 사용성·응답속도·보안 |
| 대표 사용자 | 업무 담당자 및 연계 시스템 | 분석·기획·현업 담당자 | 고객 및 상담 직원 |
여기서 중요한 점이 있습니다.
계정계가 모든 실시간 업무를 담당하고, 정보계가 모든 데이터를 저장하며, 채널계가 화면만 보여준다고 단순하게 이해하면 실제 구조와 차이가 생길 수 있습니다.
현대 금융 IT 시스템에서는 업무별로 별도의 서비스와 데이터베이스를 운영하기도 하고, 일부 기능이 여러 영역에 걸쳐 있을 수도 있습니다.
따라서 계정계·정보계·채널계는 금융 IT의 역할을 이해하기 위한 출발점으로 보는 것이 적절합니다.
3. 계정계: 카드사의 핵심 거래를 처리하는 시스템
계정계는 금융회사의 핵심 업무를 처리하는 시스템 영역을 의미합니다.
은행에서는 예금, 대출, 계좌, 이자 등과 관련된 거래 처리가 대표적입니다.
카드사에서는 회원, 카드, 이용 한도, 매입, 청구, 입금, 채권 등 여러 핵심 업무가 관련될 수 있습니다.
카드사 계정계의 주요 업무 예시
| 업무 | 처리 내용 |
| 회원 관리 | 회원 및 고객 관련 업무정보 관리 |
| 카드 관리 | 카드 발급·상태 등 관련 업무 |
| 한도 관리 | 이용 가능 한도 및 관련 정보 관리 |
| 매입 관리 | 매입 거래 및 관련 업무 처리 |
| 청구 관리 | 카드 대금 청구 대상 및 금액 산정 |
| 입금 관리 | 카드 대금 납부 및 입금 처리 |
| 채권 관리 | 미납 및 채권 관련 업무 |
실제 시스템 분류는 카드사별로 다를 수 있습니다.
계정계에서 중요한 것은 무엇일까요?
첫 번째는 거래 데이터의 정확성입니다.
예를 들어 고객이 카드 대금 500,000원을 납부했다면 해당 입금이 정확하게 반영되어야 합니다.
두 번째는 거래 처리의 일관성입니다.
관련된 업무 데이터가 서로 모순되지 않도록 관리해야 합니다.
세 번째는 안정적인 서비스 운영입니다.
계정계 장애는 고객의 금융거래와 직접 연결될 수 있기 때문에 장애 예방과 복구 체계가 중요합니다.
금융 IT 관점에서 생각해 볼 점
계정계는 단순히 데이터를 저장하는 곳이 아닙니다.
업무 규칙에 따라 거래를 검증하고 처리하며 그 결과를 관리하는 핵심 시스템입니다.
따라서 계정계 데이터의 변경은 관련 업무 규칙과 통제 절차를 고려하여 이루어져야 합니다.
4. 정보계: 거래 데이터를 분석 정보로 만드는 시스템
정보계는 여러 업무 시스템에서 발생한 데이터를 수집하고 가공하여 분석에 활용할 수 있도록 지원하는 영역입니다.
대표적인 시스템으로 데이터웨어하우스(Data Warehouse, DW)를 들 수 있습니다.
카드사의 정보계에서는 어떤 일을 할까요?
예를 들어 카드사가 다음과 같은 질문에 답해야 한다고 가정해 보겠습니다.
"지난달 전체 카드 이용 금액은 얼마일까?"
"연령대별 카드 이용 업종은 어떻게 다를까?"
"신규 회원의 카드 이용 실적은 어떻게 변화하고 있을까?"
"특정 상품의 월별 이용 실적은 얼마나 증가했을까?"
이러한 질문에 답하려면 여러 업무 시스템의 데이터를 수집하고 분석해야 합니다.
정보계는 이러한 분석 업무를 지원합니다.
정보계의 주요 업무
- 거래 데이터 수집 및 적재
- 데이터 정제와 표준화
- 통계 및 집계 데이터 생성
- DW 및 데이터마트 운영
- 분석 보고서 제공
- 데이터 품질 및 정합성 점검
계정계와 정보계의 중요한 차이
계정계는 개별 거래를 정확하게 처리하는 것이 중요합니다.
정보계는 많은 거래 데이터를 모아 의미 있는 정보를 도출하는 것이 중요합니다.
예를 들어 계정계에서는 특정 고객의 카드 대금 청구 금액을 정확하게 계산해야 합니다.
반면 정보계에서는 전체 고객의 월별 청구 금액을 분석하거나 상품별 실적을 비교할 수 있습니다.
계정계가 거래를 처리하는 영역이라면 정보계는 거래 데이터를 분석 가능한 정보로 만드는 영역이라고 이해할 수 있습니다.
5. 채널계: 고객과 카드사를 연결하는 시스템
채널계는 고객이 카드사의 서비스를 이용할 수 있도록 연결하는 시스템 영역입니다.
대표적으로 카드사 모바일 앱과 홈페이지 등이 있습니다.
채널계의 주요 역할
고객은 카드사 앱에서 다양한 서비스를 이용합니다.
- 카드 이용 내역 조회
- 이용 가능 한도 조회
- 카드 대금 확인
- 결제 예정 금액 조회
- 카드 신청
- 분실 신고
- 각종 서비스 신청
이러한 기능은 고객이 직접 이용하는 서비스입니다.
그러나 채널계가 모든 금융거래 데이터를 독립적으로 처리하는 것은 아닙니다.
많은 경우 채널계는 관련 업무 시스템과 연계하여 필요한 정보를 조회하거나 업무 처리를 요청합니다.
예를 들어보겠습니다
고객이 카드사 앱에서 이용 가능 한도를 조회합니다.
이때 앱은 고객에게 화면을 제공하지만 실제 한도 정보는 관련 업무 시스템에서 관리될 수 있습니다.
따라서 채널계는 해당 정보를 조회하여 고객에게 표시합니다.
단순화하면 다음과 같습니다.
고객 → 카드사 앱 → 관련 업무 서비스 → 한도 정보 조회 → 앱 화면 표시
채널계에서 중요한 요소
첫 번째는 사용 편의성입니다.
고객이 필요한 기능을 쉽게 찾고 이용할 수 있어야 합니다.
두 번째는 응답속도입니다.
조회나 신청 과정에서 지나치게 오래 기다리지 않도록 해야 합니다.
세 번째는 보안입니다.
고객 인증과 접근통제, 개인정보 보호가 중요합니다.
네 번째는 안정성입니다.
관련 업무 시스템에 문제가 발생하더라도 고객에게 적절한 오류 안내와 후속 처리 방법을 제공해야 합니다.
6. 승인계와 대외계는 어디에 속할까?
카드사 전산 시스템을 설명할 때 계정계·정보계·채널계만으로 모든 구조를 설명하기는 어렵습니다.
특히 카드사에서는 승인계와 대외계라는 용어도 중요합니다.
승인계
승인계는 카드 결제 승인 요청을 처리하는 업무 영역입니다.
가맹점에서 승인 요청이 들어오면 관련 정보를 확인하고 승인 또는 거절 등의 결과를 생성합니다.
승인 처리에는 거래의 신속성과 안정성이 중요합니다.
대외계
대외계는 외부기관과의 데이터 송수신 및 연계 업무를 담당하는 시스템 영역을 의미합니다.
카드사에서는 VAN사, 결제망, 외부기관 등과의 연계가 관련될 수 있습니다.
그렇다면 승인계는 계정계일까요?
이 질문에는 모든 카드사에 공통으로 적용되는 단일한 답이 없습니다.
어떤 회사에서는 승인 관련 업무를 핵심 거래 시스템의 일부로 분류할 수 있습니다.
다른 회사에서는 승인계를 별도의 시스템 영역으로 구분할 수도 있습니다.
대외계 역시 독립적인 연계 시스템으로 운영될 수 있습니다.
따라서 카드사 시스템을 이해할 때는 다음과 같이 생각하면 좋습니다.
계정계·정보계·채널계는 주요 역할을 설명하는 구분이고, 승인계·대외계 등은 실제 업무와 기술 구조에 따라 별도로 운영될 수 있는 영역입니다.
7. 실제 사례: 30,000원 카드 결제가 처리되는 과정
이번에는 가상의 카드 결제 사례를 통해 각 시스템의 역할을 살펴보겠습니다.
직장인 김 과장이 편의점에서 30,000원을 신용카드로 결제했다고 가정하겠습니다.
이 거래는 카드사에서 어떤 과정을 거칠까요?
단계 ① 가맹점에서 승인 요청
김 과장이 카드로 결제하면 가맹점 단말기에서 승인 요청이 생성됩니다.
승인 요청은 관련 결제망을 거쳐 카드사로 전달됩니다.
단계 ② 카드사 승인 처리
카드사의 승인 관련 시스템에서 거래 승인 여부를 판단합니다.
승인 결과가 생성되면 결제망을 통해 가맹점으로 전달됩니다.
단계 ③ 고객에게 승인 알림 제공
카드사는 승인 거래와 관련된 알림 서비스를 제공할 수 있습니다.
다만 승인 처리와 알림 전송은 서로 다른 처리 과정일 수 있습니다.
따라서 승인 성공과 알림 수신 시점은 반드시 일치하지 않습니다.
단계 ④ 고객이 카드사 앱에서 승인 내역 확인
김 과장이 카드사 앱을 실행하면 해당 승인 내역을 확인할 수 있습니다.
앱에 표시되는 데이터는 관련 조회 시스템의 구성과 데이터 반영 방식에 따라 제공됩니다.
단계 ⑤ 매입 관련 업무 처리
이후 가맹점의 거래 매입 관련 절차가 진행될 수 있습니다.
승인 거래와 매입 거래는 구분되는 처리 단계입니다.
단계 ⑥ 청구 업무 처리
매입 등 필요한 업무 처리를 거친 거래는 관련 조건에 따라 카드 대금 청구에 반영됩니다.
단계 ⑦ 정보계 데이터 적재 및 분석
관련 거래 데이터는 정해진 연계 절차에 따라 DW 등 분석 시스템으로 전달될 수 있습니다.
이후 업종별 이용 금액이나 월별 이용 실적 등 분석에 활용될 수 있습니다.
전체 흐름 정리
| 단계 | 주요 처리 | 관련 시스템 영역 |
| 1 | 승인 요청 전달 | 가맹점·결제망·대외 연계 |
| 2 | 승인 여부 판단 | 승인계 및 관련 업무 시스템 |
| 3 | 승인 알림 제공 | 알림 서비스 |
| 4 | 앱 이용 내역 조회 | 채널계 및 조회 서비스 |
| 5 | 매입 거래 처리 | 핵심 업무 시스템 |
| 6 | 청구 금액 산정 | 핵심 업무 시스템 |
| 7 | 거래 데이터 분석 | 정보계·DW |
이 표에서 중요한 것은 한 건의 카드 결제가 여러 시스템의 업무로 이어진다는 사실입니다.
8. 시스템별 데이터 처리 방식의 차이
계정계와 정보계는 데이터 처리 목적이 다릅니다.
이 차이를 이해하면 금융 IT 시스템을 분리하는 이유가 더욱 명확해집니다.
거래 처리 중심 시스템
개별 거래를 정확하고 일관되게 처리해야 합니다.
예를 들어 고객의 카드 대금 입금이나 청구 정보 변경과 같은 업무가 해당합니다.
분석 처리 중심 시스템
대량의 데이터를 조회하고 집계하는 것이 중요합니다.
예를 들어 수백만 건의 거래를 분석하여 월별 이용 실적을 계산하는 업무입니다.
비교
구분거래 처리 중심분석 처리 중심
| 구분 | 거래 처리 중심 | 분석 처리 중심 |
| 주요 목적 | 개별 업무 처리 | 대량 데이터 분석 |
| 처리 단위 | 개별 거래 중심 | 다수 거래 집계 |
| 중요 요소 | 정확성·일관성·응답속도 | 조회 성능·데이터 품질 |
| 대표 작업 | 거래 등록·변경·확정 | 통계·집계·추세 분석 |
| 대표 기술 개념 | OLTP | OLAP |
여기서 OLTP는 Online Transaction Processing의 약자입니다.
OLAP는 Online Analytical Processing의 약자입니다.
다만 실제 시스템에서는 두 방식이 완전히 분리되지 않을 수도 있습니다.
현대적인 데이터 플랫폼은 실시간 분석이나 혼합형 처리를 지원하기도 합니다.
중요한 것은 기술 명칭보다 업무 특성에 맞는 처리 구조를 선택하는 것입니다.
9. 계정계와 정보계의 금액이 다를 수 있는 이유
금융 IT 업무에서 자주 등장하는 질문이 있습니다.
"업무 시스템에서 조회한 금액과 DW 보고서의 금액이 왜 다를까요?"
이 문제는 단순히 데이터가 잘못되었다는 의미가 아닐 수 있습니다.
먼저 두 시스템이 같은 기준으로 데이터를 조회하고 있는지 확인해야 합니다.
가상의 사례
어느 카드사의 업무 시스템에서는 특정 날짜의 승인 금액이 10억 원으로 조회됩니다.
그런데 DW 보고서에서는 9억 8천만 원으로 표시됩니다.
두 금액의 차이는 2천만 원입니다.
왜 이런 차이가 발생할까요?
가능한 원인은 다양합니다.
① 데이터 반영 시점 차이
업무 시스템에는 최신 거래가 반영되었지만 DW에는 아직 적재되지 않았을 수 있습니다.
② 승인과 매입 기준 차이
한쪽은 승인 금액을 집계하고 다른 쪽은 매입 금액을 집계했을 수 있습니다.
③ 취소 거래 처리 기준 차이
취소 거래를 어떤 기준으로 차감했는지에 따라 금액이 달라질 수 있습니다.
④ 거래 일자 기준 차이
승인일, 매입일, 영업일 등 집계 기준이 다를 수 있습니다.
⑤ 데이터 적재 오류
일부 데이터가 누락되거나 중복 적재되었을 가능성도 있습니다.
금액 차이 점검 순서
- 두 시스템의 조회 조건을 비교합니다.
- 집계 대상 거래의 범위를 확인합니다.
- 승인일·매입일·영업일 기준을 확인합니다.
- 취소 거래 반영 기준을 확인합니다.
- 데이터 적재 완료 시점을 확인합니다.
- 거래별 식별정보를 기준으로 차이를 분석합니다.
- 누락·중복·집계 오류 여부를 확인합니다.
금융 데이터의 정합성을 확인할 때는 숫자만 비교하는 것이 아니라 숫자가 만들어진 업무 기준을 먼저 비교해야 합니다.
10. 카드사 DW는 왜 별도로 운영할까?
카드사에서는 많은 거래 데이터가 발생합니다.
이러한 데이터를 분석하기 위해서는 업무 시스템에 직접 대량 조회를 수행하는 방식보다 별도의 분석 환경을 활용하는 것이 유리할 수 있습니다.
대표적인 것이 DW입니다.
DW의 주요 역할
DW는 여러 업무 시스템에서 발생한 데이터를 수집하고 통합하여 분석에 활용할 수 있도록 지원합니다.
예를 들어 다음과 같은 데이터를 수집할 수 있습니다.
- 카드 승인 관련 데이터
- 매입 관련 데이터
- 청구 관련 데이터
- 회원 관련 데이터
- 상품 관련 데이터
- 가맹점 관련 데이터
이 데이터는 업무 목적에 따라 정제·가공·집계되어 분석에 활용됩니다.
DW가 필요한 이유
첫 번째는 대량 데이터 분석 성능입니다.
두 번째는 업무 시스템의 부하 분산입니다.
세 번째는 여러 업무 데이터를 통합하여 분석할 수 있다는 점입니다.
네 번째는 일정한 기준의 보고서와 분석 지표를 제공할 수 있다는 점입니다.
다섯 번째는 데이터 품질과 정합성을 체계적으로 관리할 수 있다는 점입니다.
실무 관점에서 중요한 점
DW를 운영할 때는 데이터를 얼마나 많이 적재하는가 보다어떤 업무 기준으로 데이터를 정의하고 관리하는가가 중요합니다.
예를 들어 '월별 카드 이용 금액'이라는 지표도 승인 기준인지 매입 기준인지에 따라 결과가 달라질 수 있습니다.
따라서 분석 지표의 정의를 명확하게 관리해야 합니다.
11. 시스템 간 데이터는 어떻게 전달될까?
계정계, 정보계, 채널계는 서로 완전히 독립적으로 동작하는 시스템이 아닙니다.
업무를 처리하기 위해 데이터를 주고받아야 합니다.
이때 사용되는 대표적인 연계 방식에는 여러 가지가 있습니다.
① API 방식
한 시스템이 다른 시스템에 필요한 정보를 요청하고 결과를 받는 방식입니다.
예를 들어 카드사 앱에서 이용 가능 한도를 조회하는 기능에 활용될 수 있습니다.
② 메시지 기반 연계
업무 이벤트나 처리 요청을 메시지로 전달하는 방식입니다.
시스템 간 결합도를 줄이거나 비동기 처리를 구현하는 데 활용할 수 있습니다.
③ 배치 방식
정해진 시간이나 조건에 따라 데이터를 모아서 처리하는 방식입니다.
예를 들어 업무 시스템의 거래 데이터를 DW에 적재하는 작업에 활용될 수 있습니다.
④ 변경 데이터 캡처(CDC)
데이터베이스의 변경 사항을 식별하여 다른 시스템에 전달하는 기술입니다.
실시간 또는 준실시간 데이터 연계에 활용할 수 있습니다.
연계 방식 비교
| 방식 | 특징 | 활용 예시 |
| API | 요청과 응답 중심 | 고객 정보 조회 |
| 메시지 | 이벤트·비동기 처리 | 거래 이벤트 전달 |
| 배치 | 일정 단위의 데이터 처리 | DW 데이터 적재 |
| CDC | 데이터 변경 사항 전달 | 변경 데이터 동기화 |
실제 금융회사에서는 업무 중요도와 데이터 특성에 따라 여러 방식을 조합하여 사용합니다.
12. 시스템을 분리하면 장애 대응에 어떤 장점이 있을까?
시스템을 업무별로 구분하는 이유는 성능뿐 아니라 장애 영향 관리와도 관련이 있습니다.
예를 들어 정보계에서 대량 분석 작업이 실행되었다고 가정하겠습니다.
분석 업무와 핵심 거래 업무가 적절하게 분리되어 있다면 분석 시스템의 부하가 승인 처리 서비스에 직접적인 영향을 주는 위험을 줄일 수 있습니다.
또한 채널계에 문제가 발생했을 때 핵심 거래 시스템의 운영 상태를 별도로 확인할 수 있습니다.
시스템 분리의 장점
- 업무별 성능 관리
- 장애 영향 범위 제한
- 독립적인 유지보수
- 업무별 보안 및 접근통제
- 시스템별 확장성 확보
- 운영 책임과 점검 범위 명확화
하지만 시스템을 분리한다고 해서 장애가 자동으로 격리되는 것은 아닙니다.
여러 시스템이 동일한 데이터베이스나 네트워크, 인증 시스템에 의존한다면 공통 장애가 발생할 수 있습니다.
따라서 시스템 분리와 함께 연계 구조, 공통 자원, 장애 전파 방지 설계도 중요합니다.
13. 금융 IT 운영담당자가 확인하는 핵심 점검 항목
이번에는 실제 운영담당자의 관점에서 살펴보겠습니다.
계정계·정보계·채널계가 정상적으로 운영되는지 확인하려면 어떤 항목을 점검해야 할까요?
계정계 관련 점검
- 주요 업무 거래 처리 상태
- 거래 오류 발생 여부
- 데이터베이스 상태
- 핵심 업무 프로그램 상태
- 거래 정합성 관련 이상 여부
정보계 관련 점검
- 데이터 적재 작업 성공 여부
- 배치 처리 시간
- 데이터 적재 건수
- 누락·중복 데이터 발생 여부
- 주요 보고서 데이터 정합성
- 데이터베이스 및 분석 작업 성능
채널계 관련 점검
- 모바일 앱 및 웹 서비스 상태
- 주요 API 응답시간
- 고객 인증 및 조회 기능
- 서비스 오류율
- 관련 업무 시스템 연계 상태
통합 점검 시 중요한 항목
| 점검 영역 | 주요 확인 사항 |
| 거래 처리 | 정상 처리율과 오류율 |
| 데이터 연계 | 송수신 지연 및 실패 |
| 데이터 정합성 | 거래 건수·금액·상태 비교 |
| 시스템 성능 | 응답시간 및 자원 사용률 |
| 장애 대응 | 장애 감지 및 복구 체계 |
| 보안 | 접근통제 및 주요 보안 상태 |
금융 IT 운영에서는 개별 시스템이 정상인지 확인하는 것도 중요하지만, 시스템 간 업무 흐름이 끝까지 정상적으로 연결되는지 확인하는 것이 더욱 중요합니다.
예를 들어 카드사 앱이 정상적으로 실행되더라도 한도 조회 API가 실패하면 고객은 필요한 서비스를 이용할 수 없습니다.
또한 DW 적재 작업이 성공으로 표시되더라도 실제 데이터에 누락이 있다면 분석 결과의 신뢰성이 떨어질 수 있습니다.
따라서 시스템 상태와 업무 결과를 함께 점검해야 합니다.
14. 카드사 시스템 구조에 대한 자주 묻는 질문
Q1. 카드사 계정계는 카드 승인 시스템과 같은 의미인가요?
반드시 그렇지는 않습니다.
계정계는 핵심 금융업무를 처리하는 영역이고, 승인계는 카드 승인 업무를 처리하는 영역입니다.
실제 시스템 구분은 회사별로 다를 수 있습니다.
Q2. 카드사 앱은 채널계에 속하나요?
일반적으로 모바일 앱과 웹 서비스는 채널계의 대표적인 예로 설명할 수 있습니다.
다만 실제 서비스는 여러 업무 시스템과 연계하여 동작합니다.
Q3. 정보계와 DW는 같은 의미인가요?
완전히 같은 의미는 아닙니다.
정보계는 분석과 정보 활용을 위한 시스템 영역을 의미하고, DW는 그 안에서 활용될 수 있는 대표적인 데이터 플랫폼입니다.
Q4. 계정계 데이터가 변경되면 DW에도 바로 반영되나요?
반드시 그렇지는 않습니다.
배치, CDC, 메시지 연계 등 데이터 전달 방식에 따라 반영 시점이 달라질 수 있습니다.
Q5. 계정계와 DW의 거래 금액이 다르면 오류인가요?
반드시 그렇지는 않습니다.
승인·매입 기준, 조회 기간, 취소 처리, 데이터 반영 시점 등이 다른지 먼저 확인해야 합니다.
Q6. 시스템을 여러 개로 나누면 관리가 더 어려워지지 않나요?
시스템이 늘어나면 연계와 운영 관리가 복잡해질 수 있습니다.
하지만 업무별 성능 관리, 장애 영향 제한, 독립적인 변경 관리 등의 장점도 있습니다.
Q7. 카드사와 은행의 시스템 구조는 같은가요?
계정계·정보계·채널계라는 개념은 공통으로 활용될 수 있지만, 핵심 업무와 데이터 구조는 다릅니다.
은행은 예금·대출·계좌 업무가 중요하고, 카드사는 회원·카드·승인·매입·청구 등 카드 업무가 중요합니다.
15. 마무리｜카드사 전산 시스템은 각자의 역할을 수행하며 연결됩니다
우리는 신용카드를 사용할 때 카드사 내부에서 어떤 시스템이 동작하는지 알 필요는 없습니다.
하지만 금융 IT 관점에서 보면 카드 한 건의 결제 뒤에는 여러 업무 시스템이 연결되어 있습니다.
승인 관련 시스템은 카드 거래의 승인 여부를 판단합니다.
핵심 업무 시스템은 회원, 한도, 매입, 청구 등 관련 업무를 처리합니다.
채널계는 고객이 필요한 정보를 조회하고 서비스를 이용할 수 있도록 지원합니다.
정보계는 여러 업무 시스템에서 발생한 데이터를 분석 가능한 정보로 만들어 줍니다.
이처럼 각 시스템은 서로 다른 목적을 가지고 운영되지만 하나의 금융 서비스를 완성하기 위해 연결됩니다.
오늘 내용을 네 가지로 정리하겠습니다.
첫째, 카드사 전산 시스템은 업무별 성능과 안정성을 확보하기 위해 여러 영역으로 구분하여 운영할 수 있습니다.
둘째, 계정계는 핵심 금융업무 처리, 정보계는 데이터 분석, 채널계는 고객 서비스 제공을 중심으로 이해할 수 있습니다.
셋째, 카드사에서는 승인계와 대외계 등 별도의 업무 시스템이 운영될 수 있으며 실제 구성은 회사마다 다릅니다.
넷째, 금융 IT 운영에서는 개별 시스템의 정상 상태뿐 아니라 시스템 간 데이터 연계와 업무 결과의 정합성을 확인하는 것이 중요합니다.
금융 IT 담당자의 관점에서 좋은 시스템 구조란 단순히 서버를 여러 대 설치하거나 프로그램을 여러 개로 나누는 것을 의미하지 않습니다.
각 시스템의 역할과 책임을 명확하게 정의하고, 서로 연결되는 업무 흐름을 안정적으로 운영할 수 있도록 설계하는 것이 중요합니다.
카드사 전산 시스템의 핵심은 각각의 시스템이 독립적인 역할을 수행하면서도 하나의 금융 서비스처럼 정확하고 안정적으로 연결되는 데 있습니다.
함께 읽으면 좋은 글
[생활 속 금융 기술 #20] 카드 결제 시스템은 어떻게 장애를 복구할까?｜금융 IT 담당자가 알려주는 이중화·자동 전환·재해복구의 원리
금융 IT 시스템의 장애 대응과 복구 원리를 설명합니다.
[생활 속 금융 기술 #13] 카드사 DW에는 어떤 데이터가 쌓일까?｜승인·매입·청구 데이터가 분석 정보가 되는 과정
카드 거래 데이터가 분석 정보로 활용되는 과정을 알아봅니다.
[생활 속 금융 기술 #14] 카드 승인 금액과 DW 보고서 금액이 다른 이유 7가지｜금융 IT 담당자의 데이터 정합성 점검 방법
업무 시스템과 DW 데이터의 차이를 분석하는 방법을 설명합니다.
[생활 속 금융 기술 #15] DW 배치 작업이 실패하면 어떻게 될까?｜데이터 적재 장애 원인 7가지와 복구 절차
정보계 데이터 적재 장애와 복구 과정을 살펴봅니다.
다음 글 예고
[생활 속 금융 기술 #22] 카드사 DW 데이터는 어떻게 만들어질까?｜ETL·ELT·CDC의 차이와 데이터 적재 과정
카드사의 승인·매입·청구 데이터는 어떻게 DW에 전달될까요?
데이터를 추출하고 변환하여 적재하는 ETL과 ELT, 변경된 데이터를 전달하는 CDC는 어떤 차이가 있을까요?
다음 글에서는 가상의 카드 거래 데이터를 활용하여 DW 데이터가 만들어지는 과정을 단계별로 살펴보겠습니다.
