60조 원 오지급 사건을 보며 – 주니어 백엔드 개발자의 시선
지난 2월 6일, 약 60조 원 규모(비트코인 62만 개 상당)의 오지급 사고가 발생했습니다.
단순 실수가 아닌, 시스템 설계 관점에서 많은 생각을 하게 만든 사건이었습니다.
오지급 사건의 타임라인은 아래와 같습니다.
사건 타임라인
사건의 흐름을 시간 순으로 정리해보면 다음과 같습니다.
2026-02-06 19:00 : 이벤트 리워드 오지급 발생
2026-02-06 19:35 : 오지급 계정 거래 및 출금 차단 시작
2026-02-06 19:40 : 거래 및 출금 차단 완료, 회수 작업 시작
2026-02-07 00:23 : 1차 공지 (사고 발생 사실 및 초기 조치 안내)
2026-02-07 04:30 : 2차 공지 (사고 원인 및 회수 현황 안내)
2026-02-07 13:00 : 금융감독원 현장 점검 개시
2026-02-07 17:33 : 3차 공지 (재발 방지 대책 및 고객 보호 보상안 공개)
2026-02-07 22:42 : 이미 매도된 1,788 BTC에 대해 회사 보유 자산으로 정합성 조치 완료
사건의 직접적인 원인은 이벤트 리워드 지급 과정에서 원화 단위로 지급해야 할 금액을 비트코인 단위로 지급한 오입력이었습니다.
정말 “사람의 실수” 문제일까?
주변 반응을 보면 이렇게 말합니다.
“직원의 실수다.”
“휴먼에러는 어쩔 수 없다.”
맞는 말입니다. 사람은 언제든 실수할 수 있습니다.
그래서 백엔드 개발자의 관점에서 중요한 질문은
“왜 그 실수가 실제 송금으로 이어질 수 있었을까?”
대규모 자산이 오가는 시스템에서는 휴먼에러를 전제로 한 설계가 기본이 되어야 합니다.
특히 60조 원이라는 비정상적으로 큰 금액이 아무런 시스템적 제약 없이 전송 가능했다는 점은 구조적인 문제를 의미한다고 생각합니다.
기업이 몰랐을까 ?
하지만 빗썸이란 큰 기업이 이런 리스크를 전혀 몰랐을 가능성은 낮습니다.
오히려 다음과 같은 트레이드오프를 고려했을 가능성이 큽니다.
- 이벤트 지급 속도
- 운영 편의성
- 승인 절차 단순화
- 개발 비용 절감
즉, 속도와 안정성 사이에서 속도를 선택했을 가능성이 있습니다.
하지만 금융 시스템에서 안정성은 선택이 아니라 전제 조건이어야 한다고 생각합니다.
시스템적으로 막을 수는 없었을까 ?
이 사건을 보며 저는 이런 질문을 스스로 던졌습니다.
어떤 사용자가 한 번에 60조원을 이체하려 할까 ?
정상적인 사용자 행동 패턴을 기준으로 본다면,
이는 이상치입니다. 이를 사전에 방어할 수 있었을 가능성이 있습니다.
만약 내가 설계를 다시 한다면
만약 제가 해당 구조를 재설계한다면 아래와 같은 장치를 두었을 것 같습니다.
- 원화 기준 최대 이체 한도 제한
- 내부적으로 모든 자산을 원화 환산 금액을 계산
- 일정 금액 이상 자동 차단
- 비정상적인 대량 지급은 예외 승인 프로세스 분리
- 다중 승인 구조
- 특정 금액 이상 지급 시 최소 2인 이상 승인
- 단순 UI 분리가 아닌 실제 승인 트랜잭션 분리
- 환산 금액 시각적 강조
- 단위(BTC) 뿐만 아니라 총 지급 금액 : 60,000,000,000,000원 처럼 명확히 표기
사후 대응
사고 이후에는 이러한 유형의 사고 재발 방지를 위해 다른 곳에서도 유사한 유형의 사고가 발생할 가능성은 없지 않은지 점검해봐야 한다고 생각합니다.
그래서 아래와 같이 접근할 것 같습니다.
- 정산/지급/환급 등 프로세스 위험 구간 분석
- 테스트 케이스에 비정상적인 값 등 엣지 케이스 추가
참고
