2개월의 사각지대

사망신고를 해도 은행이 그 사실을 알기까지 최대 두 달이 걸렸습니다.

제도 문구를 DB 요구사항으로

보도자료의 각 문장이 어떤 테이블과 제약으로 바뀌었는지 대응시켰습니다.

어디까지 구현했는가

차단이라는 하나의 흐름을 끝까지 구현하는 데 집중했습니다.

법령에서 모델을 도출했다

제도 문서만 보고 만든 것이 아니라, 근거 법령의 조문을 확인해 다섯 축으로 정리했습니다. 조문을 클릭하면 요지가 열립니다.

MySQL 서버 1대 · 데이터베이스 5개 · 테이블 30개

실제 은행은 역할에 따라 시스템을 나눕니다. 그 구조를 하나의 MySQL 서버 안에서 데이터베이스(스키마)를 나누는 방식으로 재현했습니다.

데이터가 쌓이는 순서

사망신고부터 집계까지, 각 단계에서 어느 테이블에 행이 생기는지가 곧 그 테이블이 존재하는 이유입니다.

거래 한 건이 처리되는 순서

출금 요청이 들어오면 세 곳을 읽어 판정하고, 네 곳에 기록합니다.

차단 기준일은 사망일이 아니다

사망신고 기한은 1개월입니다. 사망일로 차단하면 아직 신고되지 않은 사망을 은행이 알 수 없어 제도가 성립하지 않습니다.

-- 애플리케이션이 아니라 DB가 강제한다
CONSTRAINT ck_block_start CHECK (
  block_start_dtm =
    TIMESTAMP(DATE_ADD(
      death_report_dt,
      INTERVAL 1 DAY))
)

업무 규칙을 코드가 아닌 데이터로  [ block_rule 테이블 조회 예시 ]

아래 표는 컬럼 목록이 아니라 block_rule 테이블에 실제로 들어 있는 7개 행입니다. 거래유형 코드를 클릭하면 설명이 열립니다.

치료비·장례비는 어떻게 처리하나

상태와 테이블 이름을 클릭하면 각 단계의 의미와 테이블 속성을 볼 수 있습니다.

규칙을 코드가 아니라 DB에 새긴다

지켜야 할 정책은 하나입니다. 예외인출 대금은 등록된 병원·장례식장으로만 나간다. 이걸 어디서 막느냐가 문제입니다.

if (!payeeRepo.exists(payeeId)) {
    throw new Exception("미등록 수취처");
}

payee_id BIGINT NOT NULL,

CONSTRAINT fk_expay_payee
  FOREIGN KEY (payee_id)
  REFERENCES payee_registry (payee_id)

FK를 걸지 않은 것도 설계다

전체 68개 FOREIGN KEY 중, 아래 8개 컬럼만 의도적으로 FK 없이 두었습니다.

이력은 왜 9999-12-31로 닫는가

고객 상태가 바뀔 때마다 기존 행을 남기고 새 행을 추가하는 SCD Type 2 방식을 썼습니다.

valid_to_dtm DATETIME(3) NOT NULL
  DEFAULT '9999-12-31 23:59:59.999',

UNIQUE KEY uk_cust_hist_current
  (cust_no, valid_to_dtm)

우리 모델은 어디까지 정규화됐나

30개 테이블 전부 제3정규형을 만족합니다. 단계별로 무엇을 제거했는지 점검했습니다.

법령이 컬럼과 제약이 되다

규제 요건을 문서로만 정리하지 않고 실제 스키마에 반영했습니다.

의도적 반정규화 3건

이유는 두 가지뿐입니다. 조회 성능과 판정 시점의 값 고정.

경계값 — 같은 계좌, 같은 금액, 1분 차이

차단개시일시를 사이에 두고 동일한 출금 요청이 정반대로 처리됩니다.

제약조건이 실제로 막는다

미등록 수취처, 즉 상속인 개인계좌로 예외인출을 지급하려고 시도했습니다.

INSERT INTO exc_payout (exc_request_id, payee_id, ...) VALUES (1, 9999, ...);

ERROR 1452 (23000): Cannot add or update a child row:
  a foreign key constraint fails (`core_bank`.`exc_payout`,
  CONSTRAINT `fk_expay_payee` FOREIGN KEY (`payee_id`)
  REFERENCES `payee_registry` (`payee_id`))

무결성 검증 — 무엇을 확인했나

설계한 규칙이 데이터에서 실제로 지켜지는지 네 가지를 쿼리로 확인했습니다.

한계와 다음 단계