핀테크의 생명선

M사 배경

**업종:** 간편 송금 서비스
**규모:** 회원 500만, 일 거래 100억
**핵심:** 금융 데이터 무결성

경쟁사의 사고

N사 (경쟁사) 데이터 손실 사고

**2024년 3월:**
- 시스템 오류로 거래 데이터 손실
- 5만 건, 총 50억 원
- 누구에게 얼마를 보냈는지 불명확

**결과:**
- 금감원 조사
- 손해배상 100억
- 영업 정지 3개월
- 고객 이탈 70%

**원인:**
- 트랜잭션 미적용
- 제약 조건 없음
- 데이터 무결성 보장 안 됨

M사의 위기감

**CEO 긴급 회의:**
"우리도 이런 사고가 날 수 있다"

**CTO:**
"현재 시스템을 점검하겠습니다"

보안 점검

발견된 문제

**1. 트랜잭션 미흡**
``sql
-- 위험한 코드
UPDATE accounts SET balance = balance - 10000 WHERE user_id = 1;
-- 여기서 오류 발생하면?
UPDATE accounts SET balance = balance + 10000 WHERE user_id = 2;
`

**위험:**
돈이 사라지거나 복제될 수 있음

**2. 제약 조건 없음**
- 잔액 음수 가능
- 중복 거래 가능
- 삭제된 계좌로 송금 가능

**3. 데이터 정규화 미흡**
- 거래 정보 중복
- 일관성 보장 안 됨

긴급 개선 프로젝트

전문가 초빙

**컨설턴트:**
"금융 시스템은 데이터 무결성이 생명입니다"

**팀 교육:**
김영한의 실전 데이터베이스 긴급 수강

**집중 학습:**
- 트랜잭션 (ACID)
- 제약 조건 (FK, CHECK)
- 정규화

개선 작업 (2개월)

#### 1. 트랜잭션 적용

**개선 후:**
`sql
START TRANSACTION;

UPDATE accounts SET balance = balance - 10000 WHERE user_id = 1;
UPDATE accounts SET balance = balance + 10000 WHERE user_id = 2;
INSERT INTO transactions (from_user, to_user, amount) VALUES (1, 2, 10000);

COMMIT; -- 모두 성공하거나 모두 실패
`

**보장:**
원자성 (Atomicity) 확보

#### 2. 제약 조건 추가

**잔액 체크:**
`sql
ALTER TABLE accounts
ADD CONSTRAINT check_balance CHECK (balance >= 0);
`

**외래 키:**
`sql
ALTER TABLE transactions
ADD FOREIGN KEY (from_user) REFERENCES users(id),
ADD FOREIGN KEY (to_user) REFERENCES users(id);
`

**중복 방지:**
`sql
ADD UNIQUE INDEX idx_transaction_unique
(from_user, to_user, amount, created_at);
`

#### 3. 정규화 강화

**Before:**
거래 정보가 여러 테이블에 중복

**After:**
- transactions 테이블: 핵심 거래 정보
- transaction_details: 추가 정보
- 정규화 3NF 적용

**효과:**
- 데이터 일관성 보장
- 중복 제거

#### 4. 감사 테이블

**추가:**
`sql
CREATE TABLE audit_log (
id BIGINT,
table_name VARCHAR(50),
action VARCHAR(10),
old_value JSON,
new_value JSON,
user_id BIGINT,
timestamp DATETIME
);
``

**목적:**
모든 변경 기록 추적

시뮬레이션 테스트

오류 주입 테스트

**시나리오 1: 서버 다운**
- 송금 중 서버 다운
- 재시작 후 확인 → 거래 롤백됨
- 데이터 일관성 유지 ✓

**시나리오 2: 네트워크 오류**
- 송금 중 네트워크 끊김
- 트랜잭션 자동 롤백
- 돈 손실 없음 ✓

**시나리오 3: 잘못된 요청**
- 잔액 부족한데 송금 시도
- CHECK 제약 조건이 막음
- 음수 잔액 방지 ✓

**결과:**
모든 시나리오 통과

실제 사고 방지 사례

사례 1: 서버 장애 (2024년 8월)

**상황:**
AWS 리전 장애로 서버 10분 다운

**Before 시스템이었다면:**
진행 중이던 거래 5,000건 데이터 손실 가능

**현재 시스템:**
- 트랜잭션 모두 롤백
- 재시작 후 자동 복구
- 데이터 손실 0건

**손실 방지:**
약 50억 원

사례 2: 코드 버그 (2024년 10월)

**상황:**
개발자 실수로 잘못된 UPDATE 쿼리 배포

**Before 시스템이었다면:**
잔액 데이터 오염

**현재 시스템:**
- CHECK 제약 조건이 차단
- 즉시 에러 발견
- audit_log로 추적

**손실 방지:**
데이터 무결성 유지

사례 3: 동시 거래 (2024년 12월)

**상황:**
동일한 거래 동시에 2번 실행 시도

**Before 시스템이었다면:**
중복 송금 (돈 2배로)

**현재 시스템:**
- UNIQUE INDEX가 차단
- 한 번만 실행
- 중복 방지

**손실 방지:**
고객 불만 및 환불 비용

금감원 감사

**2024년 11월:**
금감원 정기 감사

**평가 항목:**
- 데이터 무결성
- 트랜잭션 처리
- 감사 추적

**결과:**
"모범 사례로 인정"

**평가:**
"트랜잭션과 제약 조건이 체계적으로 설계되어 있습니다"

경쟁사와 비교

**N사 (사고 발생):**
- 손해배상: 100억
- 고객 이탈: 70%
- 영업 정지: 3개월
- 기업 가치: -80%

**M사 (사고 방지):**
- 손해배상: 0원
- 고객 이탈: 0%
- 영업 정지: 0일
- 기업 가치: +50% (신뢰도 상승)

비즈니스 효과

고객 신뢰

**Before:**
"핀테크는 위험해"

**After (N사 사고 + M사 무사고):**
"M사는 안전하다"

**고객 유입:**
월 10만 → 월 **30만** (3배)

투자 유치

**시리즈 C:**
- 투자: 300억
- VC: "데이터 무결성 시스템이 인상적"
- 밸류: 3,000억

보험료

**금융 배상 보험:**
- Before: 연 5억
- After: 연 2억 (60% 할인)
- 이유: "리스크가 낮음"

CTO 인터뷰

**Q: N사 사고를 보고 어떤 생각이 들었나요?**

"내일은 우리 차례"라고 생각했어요. 즉시 시스템 점검에 들어갔죠.

**Q: 김영한 강의가 도움이 됐나요?**

트랜잭션과 제약 조건의 중요성을 팀 전체가 이해하게 됐어요. 특히 ACID 속성 부분이 핵심이었습니다.

**Q: 다른 핀테크에 조언한다면?**

금융 데이터는 무결성이 생명입니다. 빨리 만드느라 이걸 희생하면 결국 회사를 잃어요.

ROI

**투자:**
- 컨설팅: 5,000만원
- 강의: 200만원
- 개발: 2개월 (약 1억)

**총 투자:**
1.5억원

**방지한 손실:**
- 데이터 손실 사고: 100억 (예상)
- 고객 이탈: 측정 불가
- 회사 생존: 무한대

**ROI:**
무한대 (회사 생존)

결론

**핀테크:**
데이터 무결성 = 회사 생존

**해결책:**
- 트랜잭션 (ACID)
- 제약 조건 (FK, CHECK)
- 정규화 (3NF)
- 감사 추적

**학습:**
김영한의 실전 데이터베이스

**결과:**
100억 손해배상 위기 모면

---

**태그**: #데이터무결성 #핀테크 #리스크방지 #트랜잭션 #DB설계