손끝에서 일어나는 사고는 삼성투자증권에서 1000원을 1000주로 잘못 넣거나, 2000원을 2000BTC(코인)로 입력하는 순간처럼 아주 사소한 입력에서 시작된다. 얼마 전 빗썸 대규모 비트코인 오지급 사고를 바라보며 나 역시 잠시 엉뚱한 상상을 했다. 누군가 실수로 내 계정에 비트코인을 넣어주고 아무도 모른 채 지나가면 좋겠다고. 물론 그런 일은 쉽게 일어나지 않는다. 그리고 바로 그 지점에서 질문이 시작된다.
우리는 숫자가 곧 가치가 되는 디지털 금융의 시대에 살고 있다. 그러나 그 거대한 가치를 이동시키는 최종 트리거는 여전히 인간의 입력과 시스템 설계에 의존한다. 2026년 2월 발생한 60조 원 규모의 비트코인 오지급 사고는, 디지털 시스템이 얼마나 빠르게 신뢰를 잃을 수 있는지를 보여준 사건이었다.
사고가 발생하면 조직은 대개 두 가지 중 하나를 말한다.
“예상하기 어려웠다.”
“합리적으로 가능한 조치는 다 했다.”
이 둘은 비슷해 보이지만 본질적으로 다르다. 전자는 설명이고, 후자는 입증의 문제다.
SFARP(So Far As Reasonably Practicable)는 바로 그 입증을 요구하는 원칙이다. 위험을 완전히 제거하는 것이 아니라, 현실적으로 가능한 수준까지 충분히 줄였는지를 논리적으로 설명하는 기준이다. 이 글에서는 빗썸 사고를 통해 그 기준이 어디에서 멈추었는지 살펴보고자 한다. 우리는 무엇을 통제라고 믿었는지, 그리고 무엇을 설계 단계에서 질문하지 않았는지. 안전은 결과가 아니라 선택의 축적이다. 그리고 SFARP는 그 선택이 과연 충분했는지를 묻는 기준이다.
SFARP(So Far As is Reasonably Practicable)는 위험을 “합리적으로 실행 가능한 범위 내에서” 충분히 낮추었는지를 묻는 안전 원칙이다. 이것은 단순한 예방 구호가 아니라, 조직에게 설명 책임을 요구하는 기준이다. 핵심은 균형이다. 그렇기에 다음 세 가지를 함께 고려해야 한다.
위험의 크기
위험을 줄이는 조치의 실질적 효과
그 조치를 구현하는 데 필요한 비용·시간·기술적 부담
여기서 말하는 비용은 금전만을 의미하지 않는다. 기술적 난이도, 시스템 복잡도 증가, 운영 영향, 일정 지연, 성능 저하까지 모두 포함된다. 그러나 중요한 전제가 있다.
위험이 충분히 크다면, 비용이 크다는 이유만으로 조치를 미룰 수는 없다. 조치를 하지 않으려면, 그 부담이 위험 감소 효과에 비해 명백히 불균형하다는 강한 근거가 필요하다.
이 원칙은 영국 안전법의 ALARP 철학과 맥을 같이한다. 위험이 중대할수록, 아무것도 하지 않는 선택은 점점 더 정당화되기 어려워진다. 따라서 SFARP는 “우리는 최선을 다했다”는 선언이 아니다.
오히려 우리에게 질문은 던진다.
우리는 사고를 막기 위해 실제로 가능한 선택들을 검토했고, 그중 합리적으로 요구되는 수준까지 실행했는가?
만약 멈추었다면, 왜 그 지점이 한계였는가를 설명할 수 있는가?
SFARP는 안전의 한계를 정하는 개념이 아니다. 그 한계를 어디에 두었는지를 입증하라는 요구다.
2026년 2월 6일 오후 7시경, 가상자산 거래소 빗썸에서 초유의 사고가 발생했다. ‘랜덤박스’ 이벤트 당첨자 약 695명에게 2,000원에서 50,000원 상당의 리워드를 지급하는 과정에서, 담당 직원이 지급 단위를 ‘원(KRW)’이 아닌 ‘비트코인(BTC)’으로 입력하는 실수를 저질렀다. 그 결과 약 62만 개의 비트코인이 사용자 계정에 전산상 반영되었고, 당시 시세 기준 약 60조 원 규모에 해당하는 수치가 순식간에 생성되었다.
일부 물량이 실제 시장에 매도되면서 빗썸 내 비트코인 가격은 일시적으로 10~15% 급락하는 플래시 크래시가 발생했다. 거래소는 사고 인지 후 약 35분 만에 관련 계정의 거래와 출금을 차단하고 회수에 착수했으며, 대부분의 물량은 회수되었지만 일부는 이미 현금화되거나 다른 자산 매수에 사용되어 미회수 상태로 남았다. 이후 내부 통제 미비와 보고 지연 문제로 감독 당국의 조사까지 이어지며 사건은 기술적 오류를 넘어 신뢰의 위기로 확장되었다.
표면적으로 보면 이는 전형적인 ‘팻 핑거(Fat Finger)’ 사고다. 인간의 단순 입력 실수가 직접적인 원인이었다. 그러나 시스템 안전의 관점에서 이 사건은 개인의 실수로 환원될 수 없다. 입력 오류는 언제든 발생할 수 있다. 문제는 그 실수가 아무런 제동 없이 시스템을 통과해, 거래소의 총 보유 자산 규모를 초과하는 수치가 생성되고 실제 거래에 반영되었다는 점이다.
이는 단일 입력이 곧 자산 이전으로 직결되는 구조였음을 의미한다. 대규모 자동 지급 프로세스에 대한 독립 검증이 없었고, 비정상적인 수량에 대한 실시간 차단 장치도 충분히 작동하지 않았다. 다시 말해, 사고는 사람의 손끝에서 시작되었지만, 그것을 증폭시킨 것은 설계된 시스템 구조였다.
“돈”을 다루는 시스템에서 단일 실패가 대규모 자산 손실로 이어질 수 있다면, 그 자체로 고위험 구조다. 이 지점에서 질문은 분명해진다. 우리는 입력 실수를 비난할 것인가, 아니면 그런 실수가 60조 원으로 확대될 수 있도록 허용한 설계를 성찰할 것인가. 그리고 그 위험은 과연 SFARP 수준까지 충분히 낮추어져 있었는가.
SFARP는 사고가 발생한 뒤 작성하는 해명 보고서가 아니다. 그것은 설계 단계에서부터 준비되어야 하는 논리적 방어선이다. 핵심은 위험을 가시화하고, 그 위에 계층적 통제 구조를 쌓아 올리며, 마지막으로 “이 정도면 합리적으로 충분하다”는 판단을 입증하는 것이다. 빗썸 사례에 이를 적용해 보면, SFARP는 다음과 같은 단계로 구축된다.
Step 1. Hazard 정의 – 무엇이 본질적 위험인가
먼저 위험을 명확히 정의해야 한다. Hazard는 단순한 “입력 실수”가 아니다. 정확한 정의는 다음과 같다.
시스템 오류 또는 입력 오류로 인해 가상자산이 비인가·과다 지급되는 위험
이 위험의 Consequence는 단순 금전 손실을 넘어선다. 직접적인 자산 손실, 시장 가격 왜곡, 사용자 신뢰 붕괴, 규제 리스크, 법적 분쟁, 그리고 장기적 평판 훼손까지 연결된다. 이는 명백히 High Severity에 해당한다.
Severity가 매우 높다면, 허용 가능한 위험 수준은 극히 낮아야 한다. 이 지점에서 SFARP의 방향이 정해진다. “적당한 통제”는 허용되지 않는다.
Step 2. Single Point of Failure 제거 – 구조적 취약성 차단
고위험 시스템에서의 기본 원칙은 명확하다.
Single Point of Failure는 제거한다.
빗썸 사례에서는 단일 단위 입력 오류가 곧바로 자산 생성 및 이전으로 이어졌다. 이는 구조적으로 취약한 설계다. 따라서 다음과 같은 통제가 필요하다.
지급 승인 로직의 이중화
독립 계산 모듈 간 결과 교차 검증
지급 전 금액 무결성 검증
지급 큐 분리
독립 프로세스 기반 사전 시뮬레이션
이 조치들의 비용은 거래소의 전체 리스크 규모에 비해 상대적으로 낮다. 따라서 SFARP 관점에서는 “합리적으로 실행 가능한 조치”에 해당할 가능성이 높다. 이 단계에서 우리는 첫 번째 방어층을 구축한다.
Step 3. 예방적 통제 설계 – 위험을 구조적으로 낮추기
다음은 Preventive Controls다. 사고를 발생시키지 않도록 설계 자체를 보강하는 단계다.
Two-Phase Commit 기반 지급 구조
지급 한도 상한 설정(Daily 및 Account 단위)
대규모 지급 발생 시 자동 동결 메커니즘
코드 배포 전 시뮬레이션 환경 강제 실행
이상 패턴 탐지 시스템의 실시간 트리거
여기서 SFARP의 핵심 작업이 시작된다. 각 통제에 대해 다음을 문서화해야 한다.
해당 통제가 감소시키는 위험의 크기
구현 비용 및 기술적 부담
미적용 시 그 사유와 정량적 근거
단순히 “적용하지 않았다”는 문장은 허용되지 않는다. “합리적으로 불가능했다”는 입증이 있어야만 한다. 이 과정이 바로 논의 근거(Evidence)를 형성한다.
Step 4. 탐지 및 확산 차단 통제 – 피해를 국소화하기
사고를 0으로 만드는 것은 현실적으로 불가능하다. 따라서 두 번째 방어층은 확산을 막는 구조다.
이상 지급 자동 알람
대규모 자산 이동 시 인출 지연
긴급 Kill Switch
지급 롤백 설계
이 단계의 목표는 사고를 제거하는 것이 아니라, 피해를 통제 가능한 범위 안에 가두는 것이다. SFARP는 “사고가 없었는가”를 묻지 않는다. “확산을 합리적으로 차단했는가”를 묻는다.
Step 5. Disproportionality Test – 마지막 검증
이제 SFARP의 핵심 질문에 도달한다. 각 통제의 비용은 잠재 손실에 비해 현저히 과도한가? 빗썸 사례에서 잠재 손실은 수십조 원 규모였다. 그렇다면 이중 검증 로직, 지급 상한 설정, 독립 시뮬레이션 환경 구축과 같은 조치의 비용이 그에 비해 “현저히 과도하다”고 주장하기는 어렵다. 여기서 논리의 구조가 완성된다.
Claim: 대규모 자산 오지급 위험은 SFARP 수준으로 통제되고 있다.
Evidence: 다중 승인 구조, 단위 검증 로직, 지급 상한, 실시간 차단 메커니즘 등 계층적 방어 체계.
Justification: 추가 통제 도입 비용은 잠재적 수십조 원 손실 및 시장 신뢰 붕괴 위험에 비해 현저히 낮으며, 따라서 합리적으로 실행 가능하다.
만약 이러한 구조와 논리가 사전에 정리되어 있지 않았다면, 사고 이후 “합리적으로 가능한 조치는 다 했다”는 문장은 설득력을 갖기 어렵다. SFARP는 문장이 아니라 구조다. 그 구조는 설계 단계에서부터 한 층씩 쌓아 올려야 한다.
Note.정리
사고를 방지하기 위한 SFARP의 핵심은 "위험의 가시화와 계층적 방어"다. 일반 사고에 적용해 본다면 다음과 같은 논리 구조를 가진다.
주장(Claim): "위험은 SFARP 수준으로 통제되고 있다."
근거(Evidence): 오류 방지 로직, 다중 절차, 특정 제한 등.
정당화(Justification): "추가적인 통제 장치 도입의 손실보다 현저히 낮으므로, 이 조치는 합리적으로 실행 가능"
가상자산의 비인가·과다 지급이라는 고위험 Hazard에 대해 우리는 단일 실패 제거 원칙을 적용하여 구조적 취약성을 제거하였고, 다중 승인 로직과 독립 검증 체계, 지급 상한 설정, 사전 시뮬레이션, 실시간 이상 탐지 및 긴급 차단 메커니즘을 포함한 계층적 통제 구조를 설계·구현하였다. 각 통제는 잠재적 수십조 원 규모의 재무적 손실, 시장 신뢰 붕괴, 규제 및 법적 리스크를 실질적으로 감소시키며, 그 구현 비용과 기술적 부담은 해당 위험의 규모에 비해 현저히 과도하지 않다. 따라서 추가 조치를 취하지 않은 영역에 대해서는 합리적 불균형(disproportion)이 존재함을 검토·기록하였으며, 현 설계는 위험을 합리적으로 실행 가능한 범위 내에서 충분히 낮춘 상태, 즉 SFARP 수준에 도달하였다고 판단한다.
SFARP 배치: 어디에 두어야 하는가
SFARP는 사고 보고서의 마지막 장에 붙이는 문장이 아니다. 그것은 설계와 운영, 그리고 경영 의사결정의 중심에 배치되어야 하는 의사결정 구조다. 도출된 SFARP가 문서 한편에 머무는 순간, 그것은 방어 논리가 되지만, 시스템에 내재화되는 순간 비로소 안전 철학이 된다.
첫 번째 배치는 시스템 아키텍처 내부다. 검증 논리는 운영 매뉴얼이 아니라 코드와 구조 안에 존재해야 한다. API 호출 단계에서 단위 검증, 수량 상한, 이중 승인 로직, 비정상 값 차단 메커니즘이 기본 동작으로 설계되어야 하며, 이는 선택적 옵션이 아니라 기본 설계 원칙이어야 한다. 다시 말해, SFARP는 “운영자가 주의한다”는 문장이 아니라 “시스템이 허용하지 않는다”는 구조로 구현되어야 한다. 이 단계에서 기술 조직은 Hazard Log를 기반으로 각 위험 항목에 대한 통제 논리를 설계에 연결하고, 그 연결 관계를 추적 가능하도록 관리해야 한다.
두 번째 배치는 공식적인 안전 케이스(Safety Case) 문서다. 여기에는 Risk Justification 섹션이 명확히 존재해야 하며, 각 중대 위험에 대해 어떤 통제를 적용했고, 왜 그 수준이 합리적으로 충분한지, 추가 조치를 배제한 근거는 무엇인지가 체계적으로 정리되어야 한다. 이 문서는 규제 기관이나 외부 이해관계자에게 제출하기 위한 형식적 자료가 아니라, 내부적으로도 동일하게 적용되는 판단 기준이어야 한다. “우리는 이만큼 노력했다”는 선언이 아니라, “이 지점에서 멈춘 이유는 이것이다”라는 근거의 기록이 되어야 한다.
세 번째는 변경 관리 프로세스다. 설계 변경 검토 회의, 기능 추가 승인, 릴리스 결정 과정에서 SFARP 검토는 필수 단계로 포함되어야 한다. 새로운 기능이 기존 Hazard에 어떤 영향을 미치는지, 기존 통제가 여전히 충분한지, 위험이 증가했다면 추가 통제가 필요한지에 대한 검토가 이루어지고 그 결과가 회의록과 승인 문서에 남아야 한다. Release 승인 문서에는 단순히 “테스트 완료”가 아니라 “위험이 SFARP 수준으로 유지됨을 검토함”이라는 판단이 포함되어야 한다. 이 기록이 누적될 때 조직은 사후 변명이 아닌 사전 판단의 이력을 갖게 된다.
네 번째는 경영 레벨이다. 이사회 및 리스크 위원회 보고 자료에는 중대 Hazard 목록과 그에 대한 SFARP 판단 상태가 포함되어야 한다. 특히 High Consequence Risk에 대해서는 현재 통제 수준, 잔여 위험, 추가 투자 필요성, 그리고 비용 대비 위험 감소 효과가 정기적으로 검토되어야 한다. 이 과정에서 “속도와 시장 점유율”이 아니라 “위험 허용 기준”이 의사결정의 상단에 놓여야 한다. SFARP는 기술 부서의 언어가 아니라 경영 판단의 언어가 되어야 한다.
결국 SFARP는 기술 문서가 아니라 책임 구조다. 그리고 반드시 기록으로 남아 있어야 한다. 왜 우리는 이 수준에서 멈추었는가, 왜 이 통제는 충분하다고 판단했는가, 왜 추가 조치는 불균형하다고 보았는가. 이 질문에 대한 답이 설계 문서, 변경 이력, 승인 기록, 경영 보고서에 일관되게 존재하지 않는다면, 그 조직은 아직 SFARP를 운영하고 있다고 말할 수 없다. SFARP는 존재한다고 선언하는 것이 아니라, 의사결정의 모든 층위에 배치될 때 비로소 존재한다.
빗썸 사고는 우리에게 분명한 경고를 남겼다. 시스템이 복잡해질수록, 속도가 빨라질수록, 다루는 가치가 커질수록 우리는 더 집요하게 질문해야 한다. 지금의 설계는 과연 합리적으로 실행 가능한 최선인가. 더 할 수 있었던 조치를 비용이나 일정, 편의라는 이유로 스스로 낮추어 잡지는 않았는가.
SFARP는 새로운 분석 기법이 아니다. 위험 행렬도 아니고, 계산식도 아니다. 그것은 설계자와 의사결정자에게 던지는 하나의 질문이다.
“정말 여기까지밖에 할 수 없었는가?”
빗썸 사고는 코드 오류에서 시작되었을지 모른다. 그러나 시스템 안전의 관점에서 보면 그것은 통제 구조의 철학적 실패였다. 돈을 다루는 시스템에서 단일 실패를 허용하는 것은 우연이 아니라 선택이다. 그리고 모든 설계 선택에는 반드시 책임이 따른다.
SFARP를 적용했다고 문서에 적는 일은 중요하지 않다. 중요한 것은 그 질문에 스스로 납득할 수 있는가다. 추가 통제를 하지 않은 이유를 정직하게 설명할 수 있는가, 그리고 그 판단이 위험의 무게와 균형을 이루고 있는가를 스스로 증명할 수 있는가다.
SFARP는 체크리스트를 채우는 절차가 아니다. 그것은 시스템이 언제든 실패할 수 있음을 인정하는 겸손이며, 그 실패의 결과를 감당하겠다는 엔지니어링적 책임 선언이다. 시스템 안전은 사고를 완벽히 예측하는 학문이 아니라, 사고 이후에도 고개를 들 수 있는 설계를 만드는 학문이다.
우리는 거대한 숫자를 통해 한 가지를 배웠다. 안전은 비용이 아니다. 그것은 시스템이 시장에 존재할 수 있는 이유이며, 신뢰를 유지할 수 있는 유일한 토대다. 그리고 SFARP는 그 토대가 충분한지 끊임없이 묻는 기준이다.