정확해도 늦으면 실패다
사기 탐지의 답이 늦어지면 왜 정상 이체까지 멈출 수 있는지, 기다림을 끊고 고장을 가두며 대체 처리를 준비해야 하는 이유를 쉽게 설명합니다.
지난 글에서는 사기를 더 많이 잡으려고 의심 기준을 낮추면 정상 거래도 함께 더 많이 걸릴 수 있다는 문제를 살펴봤다.
그렇다면 은행이 정상 거래를 잘못 막는 오탐과 사기 거래를 놓치는 미탐 사이에서 적절한 기준을 찾으면 문제는 끝날까?
아직 한 가지가 남아 있다. 그 판단이 언제 도착하느냐다.
가상의 이체 시스템이 이상거래 판단을 1초까지만 기다릴 수 있다고 해보자. FDS(Fraud Detection System, 이상금융거래탐지시스템)가 사기 거래를 정확히 찾아냈지만 3초 뒤에 답했다면 어떨까?
판단은 맞았다. 하지만 이체를 결정해야 할 시간에는 도착하지 못했다.
사기 탐지는 정답을 맞히는 시험이 아니라, 마감시간 안에 결정을 내려야 하는 일이다.
2편이 “어느 거래부터 개입할 것인가”에 관한 이야기였다면, 3편은 “그 결정을 언제까지 끝낼 것인가”에 관한 이야기다.
이 글의 시간과 거래 수는 원리를 설명하기 위한 가상 값이다. 특정 금융회사의 실제 제한시간, 처리량, 내부 구조나 장애 사례를 의미하지 않는다.
이체는 FDS의 답만 기다리는 일이 아니다
고객이 이체 버튼을 누르면 여러 확인이 차례로 일어난다.
로그인한 사람이 본인인지 확인하고, 잔액과 이체 한도를 살피고, 계좌 상태를 확인한 뒤 실제로 돈을 옮겨야 한다. FDS의 위험 판단도 이 과정에 들어간다.
따라서 이체 전체가 1초 안에 끝나야 한다면 FDS가 1초를 모두 쓸 수는 없다. 다른 확인과 처리에도 시간이 필요하기 때문이다. FDS의 제한시간은 전체 이체 시간 안에서 따로 나눠 받아야 한다.
평균 응답시간만 봐도 안 된다.
가상 이체 1,000건 중 990건의 FDS 판단이 0.1초에 끝나고, 10건이 5초 걸렸다고 해보자. 평균은 약 0.15초다. 숫자만 보면 빠르다.
하지만 10명의 고객은 멈춘 화면을 5초 동안 보게 된다. 이체가 된 것인지 알 수 없어 버튼을 다시 누르거나 앱을 닫을 수도 있다.
그래서 운영에서는 평균뿐 아니라 가장 느린 고객들이 얼마나 기다렸는지도 따로 본다. 대부분이 빠르다는 사실이 일부 고객의 긴 기다림을 없애주지는 않기 때문이다.
늦은 요청은 뒤에 온 정상 거래까지 세운다
한 건이 늦다고 은행 전체가 바로 멈추는 것은 아니다. 문제는 느린 요청이 계속 쌓일 때 시작된다.
시스템은 FDS의 답을 기다리는 동안 처리 공간과 연결을 사용한다. 기다리는 거래가 많아지면 새로 들어온 거래가 사용할 자리가 줄어든다.
은행 창구 하나에서 오래 걸리는 업무가 계속 이어진다고 생각하면 쉽다. 처음에는 한 사람만 늦어진다. 곧 뒤에 줄이 생기고, 간단한 업무를 보러 온 사람도 기다리게 된다.
시스템에서도 같은 일이 벌어진다.
- 일부 FDS 요청의 응답이 늦어진다.
- 기다리는 거래가 처리 공간을 계속 차지한다.
- 정상적으로 끝날 거래까지 대기한다.
- 고객이나 앞단 시스템의 재요청이 부하를 더한다.
- FDS 일부의 느림이 이체 전체의 장애로 번진다.
이처럼 작은 문제가 다른 부분의 부담을 키우며 퍼지는 현상을 Cascading Failure(연쇄 장애)라고 한다.
중요한 점은 느림도 장애가 될 수 있다는 것이다. 오류 메시지가 없다고 계속 기다리는 것이 반드시 안전한 선택은 아니다.
세 가지를 미리 정해야 한다
연쇄 장애를 막으려면 세 질문에 먼저 답해야 한다.
| 질문 | 필요한 장치 | 쉬운 뜻 |
|---|---|---|
| 얼마 동안 기다릴 것인가? | Timeout(타임아웃·응답 제한시간) | 정한 시간이 지나면 기다림을 끝낸다 |
| 고장을 어디까지 퍼지게 둘 것인가? | 장애 격리 | 문제가 생긴 기능의 처리 공간을 따로 둔다 |
| 답을 받지 못하면 무엇을 할 것인가? | Fallback(폴백·대체 처리) | 다음 행동을 미리 정해둔다 |
타임아웃은 느린 기능을 빠르게 만드는 장치가 아니다. 이 시간 안에 답이 없으면 더 기다리지 않겠다는 경계선이다. 너무 길면 요청이 계속 쌓이고, 너무 짧으면 곧 끝날 정상 요청까지 실패로 처리한다. 실제 응답시간과 이체 전체의 시간 한도를 함께 측정해 정해야 한다.
장애 격리는 배의 선체를 여러 칸으로 나누는 것과 비슷하다. 한 칸에 물이 들어와도 배 전체가 가라앉지 않게 막는 것이다. 시스템에서도 FDS가 사용하는 처리 공간과 연결 수를 제한하면, FDS가 느려져도 다른 기능이 쓸 자리를 남길 수 있다.
폴백은 타임아웃 뒤의 행동이다. 답이 없을 때 거래를 허용할지, 추가 인증을 요구할지, 잠시 보류할지를 미리 정한다. 아무 계획 없이 기다림만 끊으면 고객에게 무엇을 알려주고 거래를 어떻게 처리할지 결정할 수 없다.
세 장치는 서로 대신할 수 없다. 기다림을 끊는 것, 고장을 가두는 것, 그다음 행동을 정하는 것은 서로 다른 문제다.
답이 없을 때 모두 허용하거나 모두 막을 수는 없다
FDS가 제시간에 답하지 못했을 때 모든 거래를 허용하면 서비스는 이어지지만 사기가 통과할 수 있다. 반대로 모든 거래를 막으면 사기는 막을 수 있지만 정상 고객도 이체할 수 없다.
어느 한쪽도 항상 정답은 아니다.
2편에서 의심 점수에 따라 조치를 나눴던 것처럼, 장애 상황에서도 거래의 위험에 따라 대응을 나눌 수 있다.
- 위험이 낮고 독립적인 최소 확인을 통과한 거래는 제한적으로 진행한다.
- 정보가 부족한 거래는 추가 인증으로 판단 근거를 보완한다.
- 위험 신호가 큰 거래는 잠시 보류하고 확인 대상으로 보낸다.
이것은 설명을 위한 예시이며 실제 적용 방식은 금융회사의 정책과 위험 한도에 따라 달라진다.
핵심은 장애가 난 순간에 즉흥적으로 결정하지 않는 것이다. 어떤 조건에서 어떤 대체 처리를 사용할지, 그 선택으로 감수하는 위험은 무엇인지, 나중에 누가 확인할지를 정상 상태에서 정해둬야 한다.
폴백 자체도 원래 기능과 함께 고장 나지 않도록 단순하고 독립적이어야 한다. 평소에는 사용하지 않다가 장애 때 처음 실행되는 복잡한 폴백은 안전장치가 아니라 새로운 위험이 될 수 있다.
SafeFDS가 보여줘야 할 것은 ‘느려졌을 때’다
개인 프로젝트 SafeFDS가 정상 상황에서 빠르게 응답하는 화면만 보여준다면 운영 능력의 증거로는 부족하다. 정상일 때는 대부분의 시스템이 잘 움직이기 때문이다.
진짜 확인해야 할 것은 일부 기능을 일부러 늦추거나 멈췄을 때다.
- 정한 시간이 지나면 요청을 끝내는가?
- 느린 요청이 쌓여도 다른 정상 거래는 계속 처리되는가?
- 거래의 위험에 맞는 대체 처리가 실행되는가?
- 언제, 왜 대체 처리가 작동했는지 기록되는가?
이 실험에서는 평균 응답시간만 보지 않고 가장 느린 거래의 대기시간, 타임아웃 비율, 폴백 실행 비율과 장애 중 정상 거래 성공률을 함께 확인해야 한다.
현재 이 글에는 SafeFDS의 측정 결과를 넣지 않는다. 같은 조건에서 반복할 수 있는 지연·장애 실험을 거치기 전의 숫자는 증거가 아니기 때문이다.
핵심은 한 문장으로 정리할 수 있다.
좋은 FDS는 정확한 답을 내는 데서 끝나지 않는다. 제시간에 답하고, 답하지 못할 때도 피해가 어디까지 번질지 통제해야 한다.
1편에서는 은행이 고객의 의도가 아닌 거래의 흔적으로 판단하는 이유를 살펴봤다. 2편에서는 그 불완전한 신호 위에 의심 기준을 어디에 둘지 살펴봤다. 이번 글에서는 그 판단에 마감시간과 실패 대책이 필요하다는 점을 확인했다.
다음 글에서는 이제 누가 그 판단을 맡아야 하는지 살펴본다. 규칙, 머신러닝, LLM(Large Language Model, 대규모 언어 모델)은 각각 무엇을 잘하고 어디서 실패할까? 그리고 SafeFDS는 왜 하나에 모든 판단을 맡기지 않았을까?
이 시리즈의 이전 글
2편 — 사기를 더 많이 잡으면 왜 정상 고객도 더 많이 막힐까?
오탐과 미탐, 탐지율과 임계값 사이의 피할 수 없는 선택을 설명한다.
이 시리즈의 다음 글
4편 — AI가 사기 거래를 판단하게 해도 될까?
규칙, ML, LLM 그리고 SafeFDS 실험을 통해 각 방식의 역할과 한계를 비교한다.