계정계 정보계 채널계 구조

금융 시스템의 핵심 아키텍처를 이루는 기본 구조인 “계정계·정보계·채널계”를 이해하자!

📍 계정계 / 정보계 / 채널계 구조 요약

계정계 (Account System, OLTP)

• 핵심 거래가 이뤄지는 시스템
• 사용자의 잔액, 계좌, 이자, 대출 등 실시간 트랜잭션을 처리
• 시스템 장애 시 금융 서비스 중단으로 이어짐 → 가용성･정합성이 매우 중요
• 고성능 RDBMS + 메인프레임 or 고신뢰성 서버 기반이 일반적
• 예: A가 B에게 송금할 때 잔액 감소 → 수신자 계좌 증가까지가 한 트랜잭션

정보계 (Analysis System, OLAP)

• 계정계에서 수집된 거래 데이터를 가공･분석해서 경영･마케팅에 활용
• 고객 행동 분석, 리스크 분석, 이자율 예측, KPI 추적 등에 사용
• 실시간성이 필요없고, 대용량 데이터를 다룸
• 데이터 웨어하우스(DW) + BI 도구 기반
• 예: ‘30대 남성의 평균 카드 사용액’, ‘지난달 1억 이상 입금 고객 리스트’ 등

채널계 (Interface System)

• 사용자가 실질적으로 접속하는 시스템
• 예: 모바일 앱, 인터넷뱅킹, 콜센터, 창구, ATM
• 계정계와 직접 연결되며, 인증, 보안, UX 처리를 담당
• 최근에는 API Gateway 및 클라우드/쿠버네티스 위에 올라가는 구조로 많이 바뀜
• 예: 앱에서 로그인 → 잔액조회 → 거래 내역 확인까지 전부 채널계를 통해 이루어짐

왜 이 구조를 알아야할까?

그 외 계층

실제 구조도 예시

[ 사용자  →  채널계  →  중계계  →  계정계  ↔  정보계 ]
                           ↘ 보안계/공통계 ↙

• 중계계는 채널계와 계정계/정보계를 연결하는 ‘버스’
• 공통계는 시스템 운영에 필요한 부가 시스템
• 보안계는 인증/인가 및 접근제어 시스템을 통제
• FDS는 금융 범죄 방지 시스템 (독립적으로 존재)

MSA 설계 시 어떤 계층부터 분리하는게 좋을까?

일반적으로 채널계/공통계부터 분리하는게 안전하고 효과적이다.

채널계는 서비스별로 독립 UI/UX 흐름이 존재하고, 인증/로그인 등 자연스러운 MSA 분리가 가능하기 때문에 MSA 전환이 적합하다.
공통계는 인증, 권한, 알림, 로그 등은 MSA로 분리하면 재사용성이 높기 때문에 적합하다.
정보계는 대용량 처리 및 일괄 작업이 많아 통합 처리가 유리한 경우도 있기 때문에, 제한적으로 분리가 가능하다.
계정계는 트랜잭션 정합성 보장이 중요하고, 서비스 간 데이터 정합성 이슈 위험이 높기 때문에 MSA 전환을 매우 신중하게 접근해야 한다. FDS는 실시간 처리가 요구되므로 고성능 환경이 필요하고, 전환 시 고려 요소가 많아 주의해야한다.

점진적 전환 전략

• 채널계 → 공통계 → 정보계 → 계정계 순으로 점진적 마이그레이션
• 특히 계정계는 **도메인별(Micro-domain)**로 쪼갤 수 있는 기반이 있어야 분리가 가능함

📍 계층별 테스트 전략 - 구조별로 달라지는 품질 관리 방식

금융 시스템은 계정계·정보계·채널계에 더해, 중계계·공통계·보안계·FDS로 세분화된다.
MSA 전환은 채널계/공통계부터 점진적으로 시작하는 것이 바람직하며, 계층마다 테스트 전략이 다르므로 계층 구조에 맞춘 품질관리 계획이 필요하다.

보너스: 금융권에서 MSA 도입 시 자주 나오는 설계 키워드

• API Gateway, Domain Driven Design (DDD)
• Saga 패턴: 분산 트랜잭션 처리
• Circuit Breaker, Service Mesh (Istio)

📍 금융 시스템 도메인 설계 및 MSA 전환 실무 관점

🏦 도메인: 계정계 – 송금 서비스

핵심 도메인 구조 (도메인 모델링 관점 DDD 기반)

[UserAccount] ← 송금 요청 → [TransferService] → [Ledger] ←→ [Notification]

고려사항

• 트랜잭션 일관성: 출금→입금까지 원자성 보장 필요
• 이중 송금 방지: 송금 중복 요청 식별 필요 (idempotency)
• 비동기 처리: 알림은 MQ/이벤트로 비동기 처리

📊 도메인: 정보계 – 소비 분석 서비스

핵심 흐름

[AccountTransaction] → [Batch ETL] → [SpendingAnalyzer] → [UserDashboard]

💡 고려사항

• 실시간 아님: 최소 1일 지연 발생
• 정확도 우선: 실시간보다 분석 정확성 우선
• OLAP 처리: Snowflake, BigQuery, Hive 등 사용 가능

📍 MSA 아키텍처 설계도 예시

디지털뱅크 서비스의 마이크로서비스 설계 예시

                  [ API Gateway ]
                         ↓
     ┌────────────┬─────────────┬────────────┐
     │   AuthSvc  │ TransferSvc │ AccountSvc │ ← 채널계/계정계 주요 서비스
     └────────────┴─────────────┴────────────┘
           ↓             ↓              ↓
[ NotificationSvc ] [ LedgerSvc ] [ FeeCalcSvc ] ← 공통계 / 보조 도메인
           ↓
Kafka Topic or RabbitMQ
           ↓
[ LoggingSvc ] [ FraudDetectionSvc ] [ AuditSvc ] ← 공통계/보안계

설계 포인트

• 도메인 기반 마이크로서비스 분리 (계좌, 송금, 인증, 수수료 등)
• Kafka 등 비동기 메시징 활용
• 서비스 간 느슨한 결합 유도
• Spring Boot + Docker/K8s + Redis + JPA 조합 권장

📍 면접 질문 답변 구성

질문: “계정계를 왜 쉽게 MSA로 분리하지 못할까요?”

계정계는 실시간 거래 처리와 높은 정합성을 요구하는 핵심 시스템이기 때문에,
단순히 서비스 단위로 분리하기보다 트랜잭션 관리, 데이터 일관성, 장애 대응 등 다양한 고려가 필요합니다.

특히 MSA에서는 서비스 간 트랜잭션이 분산되어 관리되기 때문에,
ACID 보장이 어려워지고, 이를 보완하려면 Saga 패턴이나 이벤트 기반 보상 트랜잭션 설계가 필요합니다.

또한 계정계는 기존에 단일 DB와 모놀리식 구조로 설계되어 있는 경우가 많아서,
MSA로 전환 시 기존 시스템의 안정성 유지와 데이터 마이그레이션까지 동시에 고려해야 합니다.

그래서 일반적으로는 채널계, 공통계부터 점진적으로 MSA를 적용하고,
계정계는 충분한 설계와 테스트를 거쳐 점진적 도메인 단위로 분리하는 것이 현명하다고 생각합니다.

📍 요약

• 금융 도메인은 단순 CRUD가 아닌 계층적 구조와 데이터 정합성 중심의 도메인 모델 설계가 필수
• MSA는 비즈니스 도메인 기반 분리가 효과적이며, 계정계는 가장 마지막 단계로 전환하는 것이 일반적
• 실제 면접이나 프로젝트 기획 단계에서 위 개념과 설계를 제시하면 높은 평가를 받을 수 있음

📍 금융 시스템의 장애 대응 시나리오

은행은 고객 자산을 실시간으로 다루는 고신뢰 시스템이기 때문에, 장애 발생 시에도 거래 정합성과 신뢰를 유지해야한다.

• 무중단 운영 (Always On)
• 장애 복구 시 정합성 유지 (Zero Data Loss or 최소화)
• 신속한 복구 (RTO/RPO 최소화)
• 이중화, 이관, 수동 전환 체계 내재화

장애 유형별 시나리오

💥 시나리오 1: 계정계 DB 장애 발생

상황: 출금 요청 중 DB 트랜잭션 실패 → 이체 완료 여부 불명확

대응 흐름

1. 장애 발생 감지 (DB 응답 지연, 에러 로그, 모니터링)
2. 자동 Failover → 복제 DB로 전환 (Active-Standby)
3. 복구 이후 트랜잭션 로그 기반 정합성 점검
4. 필요 시 사용자에 “일시적 오류 → 복구 안내”

예방 설계 포인트

• WAL 기반 트랜잭션 로그 저장
• DB Replication 상태 지속 감시 (Heartbeat)
• 거래 로그의 transaction_id 기준 중복 처리 방지

💥 시나리오 2: 인터넷뱅킹 접속 불가

상황: 특정 시간대 트래픽 폭증 → 채널계 WAS 과부하

대응 흐름

1. WAS Pool 초과 감지 → Auto-scaling 요청 (클라우드 기반)
2. 일부 사용자를 모바일뱅킹으로 유도
3. 알림센터를 통해 공지 및 사과 메시지 발송

예방 설계 포인트

• API Gateway + Circuit Breaker 설정
• 사용자 세션 분산 (Redis 기반)
• 일시적 오류 시 재시도 정책 (Exponential Backoff)

💥 시나리오 3: 외부 기관 연동 장애 (예: 카드사 API 다운)

상황: 마이데이터에서 카드사 API 연동 실패 → 사용자 리포트 누락

대응 흐름

1. 오류 시 failover cache 사용 → 과거 데이터 기반 뷰 제공
2. 장애 사유 저장 → 장애 해소 후 자동 재조회 배치

3.사용자에게 “일부 데이터는 수집 대기 중” 안내

예방 설계 포인트

• 연동 실패 시 재시도 큐에 적재 (Kafka, RabbitMQ)
• 외부 API Health Check 주기적 수행

장애 복구 체계 핵심 전략

금융 시스템에서의 장애 대응은 단순한 복구가 아니라 정합성, 신뢰성, 연속성이 최우선이다.
계정계 장애 → 데이터 정합성 유지가 핵심
채널계 장애 → 사용자 대응 및 대체 채널 안내
외부 연동 장애 → 재처리 설계, 사용자 신뢰 회복 방안 필요
이를 위한 DR 체계, RTO/RPO 관리, 자동 Failover 설계가 필수다.

필요하다면,
장애 유형별 시스템 설계 전략
RTO/RPO 설계 예시
MSA 전환 시 장애 격리 전략
이런 것도 더 자세히 도와줄 수 있어.

📍 금융 IT 시스템에서의 보안 인증 방식 (OTP, FIDO, 2FA 등)

1️⃣ 보안 인증 방식 개요 (OTP, FIDO, 2FA 등)

• OTP (일회용 비밀번호): 모바일 앱/토큰기반
• FIDO (생체인증): 지문/홍채 기반, 서버 저장 없음
• 2FA (Two-Factor Auth): 비밀번호 + 추가 인증요소

인증 흐름 예시

ID 입력 → 비밀번호 확인 → OTP 입력 → FIDO 지문 스캔 → 인증 완료

2️⃣ 장애 유형별 보안 인증 시스템 설계 전략

3️⃣ 인증 시스템의 RTO/RPO 설계 기준

인증 시스템 RTO/RPO 설계 팁

• Session 서버와 OTP 서버는 분리 설계
• 핵심 구성은 Active-Active 이중화
• 토큰 발급 시점, 유효시간 고려한 보상 처리 로직 내재화

4️⃣ 클라우드 환경에서의 인증 시스템 고가용성 설계

• OAuth2 서버 + Redis 세션 클러스터링
• FIDO 서버 다중 리전 배포
• OTP 인증은 Stateful → 가능하면 Stateless 토큰화
• 장애 발생 시 자동 Failover + 서비스 Degradation 대응

금융 시스템의 보안 인증은 단순히 강력한 수단을 쓰는 걸 넘어서, 인증이 실패하거나 중단됐을 때도 서비스를 신뢰성 있게 이어갈 수 있는 복구 설계가 핵심이다. OTP, FIDO, 2FA 등 다양한 인증 방식은 각기 다른 장애 대응 전략을 가져야 하며, 이를 위해 RTO/RPO 기반의 인증 인프라 이중화 설계, 장애 발생 시 fallback 인증 체계, 고가용성 클라우드 인증 구조를 함께 고려해야 한다.

이 주제는 보안 + 인프라 + 사용자 경험까지 통합적으로 고려해야 하는 주제이기 때문에, → 금융 IT 직무, SI 엔지니어, 클라우드 아키텍트 등 모두에게 어필 가능해

원한다면:

• OAuth2 인증 서버 MSA 설계 예시
• FIDO 인증 흐름도
• OTP 장애 복구 절차 문서 예시도 만들어줄게