이상거래탐지시스템(FDS)은 어떻게 만들어지나요
핵심 요약: FDS는 단순 룰 엔진이 아니라 실시간 스트리밍 파이프라인 + 규칙 엔진 + ML 서빙이 결합된 복합 시스템이에요. Condition → Rule → Policy 계층 구조로 탐지 로직을 유연하게 관리하고, Kafka → Flink → Feature Store → Redis 파이프라인으로 실시간 거래를 처리해요. 망분리 환경에서 AI를 적용하려면 혁신금융서비스 지정이 필요해요.
결제 서비스를 운영하다 보면, 정상 거래와 사기 거래의 경계가 생각보다 모호하다는 걸 알게 돼요. 새벽 3시에 100만원을 송금하는 게 사기일 수도 있고, 해외 출장 중인 직원의 정상 거래일 수도 있어요. 이 판단을 실시간으로, 수백만 건의 거래에 대해 내려야 하는 게 FDS의 역할이에요.
FDS는 공항 보안 검색대와 비슷해요. 모든 승객(거래)이 통과해야 하지만, 정상 승객을 너무 오래 잡아두면 비행기가 지연되는 거예요. 탐지율을 높이면 오탐이 늘어나고, 오탐을 줄이면 실제 사기를 놓치게 돼요. 이 균형을 잡는 게 FDS 설계의 핵심 과제예요.
이전 글에서 전자금융감독규정의 기술 요건을 다뤘어요. 이번에는 그 요건 중 하나인 이상거래탐지시스템을 실제로 어떻게 설계하고 구축하는지 살펴볼게요.
FDS란 무엇이고, 왜 금융 서비스에 필수인가요
FDS(Fraud Detection System)는 전자금융거래에 사용되는 단말기 정보, 접속 정보, 거래 내용 등을 종합적으로 분석하여 의심거래를 탐지하고 이상금융거래를 차단하는 시스템이에요.
전자금융거래법 제21조의3은 금융회사와 전자금융업자에게 이상금융거래 탐지·분석·차단 체계를 갖출 것을 의무화하고 있어요. 단순히 "있으면 좋은" 시스템이 아니라, 법적 의무 사항이에요.
금융보안원이 2023년에 발표한 FDS 운영 가이드라인에 따르면, FDS는 51개 이상의 탐지 시나리오를 운영해야 해요. 대포폰 개통 후 ARS/SMS 본인확인 우회, 악성앱 설치 단말기 거래, 비정상적 고액/반복 결제 등이 포함돼요.
운영하면서 계속 느낀 건, FDS는 한 번 만들고 끝나는 시스템이 아니라는 거예요. 사기 수법은 계속 진화하고, 탐지 로직도 그에 맞춰 빠르게 변해야 해요. 2026년 4월 기준으로 국내 금융권 FDS의 평균 예방률은 95.4%이지만, 보이스피싱 수법이 고도화되면서 FDS 요원의 고객 응대 시간은 2022년 대비 263.3% 증가했어요.
FDS의 4대 기능은 어떻게 구성되나요
FDS는 정보수집, 분석·탐지, 대응, 모니터링·감사 4가지 기능으로 구성돼요.
각 기능이 파이프라인처럼 연결되어 거래가 발생한 시점부터 사후 감사까지 전체 생명주기를 관리해요.
| 기능 | 역할 | 수집/처리 대상 |
|---|---|---|
| 정보수집 | 거래 발생 시점의 모든 컨텍스트 수집 | 단말기 정보, IP, 위치, 거래 금액, 시간, 수취인 정보 |
| 분석·탐지 | 규칙 검사 + ML 추론으로 위험도 산출 | 이용자별/거래별 상관관계, 과거 패턴 비교 |
| 대응 | 위험도에 따른 실시간 조치 | 거래 차단, 추가 인증 요구, 한도 제한, 알림 발송 |
| 모니터링·감사 | 탐지 결과 검토 및 규칙 개선 | 오탐/미탐 분석, 탐지율 추적, 감사 로그 |
실무에서 자주 놓치는 부분이 4번째 기능이에요. 모니터링·감사 없이는 탐지 규칙이 실제로 효과가 있는지 알 수 없어요. 오탐이 급증하면 CS 부하가 커지고, 미탐이 늘면 실제 피해가 발생해요. 이 피드백 루프가 FDS의 지속적 개선을 가능하게 해요.
규칙 엔진은 어떻게 설계하나요
규칙 엔진은 Condition(조건), Rule(규칙), Policy(정책) 3계층 구조로 설계해요.
당근페이가 2025년 11월에 공개한 FDS 기술블로그에 따르면, 이 구조는 "레고 블록처럼 조건들을 조립해 탐지 규칙을 만들고, 정책 단위로 묶어 운영할 수 있는 구조"예요. 변화하는 사기 트렌드에 맞춰 탐지 로직을 빠르게 조정할 수 있다는 게 핵심 장점이에요.
각 계층의 역할을 정리하면 이래요.
| 계층 | 역할 | 예시 | 관리 주체 |
|---|---|---|---|
| Condition | 단일 판단 기준 | 거래금액 > 100만원, IP 변경 여부 | 개발팀 |
| Rule | 조건 조합으로 만든 탐지 규칙 | (고액 AND 신규단말) = 의심거래 | FDS 운영팀 |
| Policy | 규칙을 목적별로 묶은 운영 단위 | "보이스피싱 방지", "명의도용 방지" | FDS 운영팀 |
처음엔 규칙을 하드코딩으로 시작했는데, 사기 패턴이 빠르게 변하면서 배포 없이 규칙을 변경할 수 있는 구조가 필요해졌어요. 당근페이의 경우 정책 단위에서 각 규칙별 설정(활성화 여부, 임계값, 대응 액션)을 독립적으로 관리할 수 있도록 설계했어요.
이벤트 처리 방식도 두 가지로 나뉘어요. 즉시 차단이 필요한 이벤트는 동기 API로, 후속 처리가 가능한 이벤트는 비동기 스트림으로 처리해요. 동일한 룰 구조 안에서 두 방식이 공존하도록 설계하는 게 실무에서 중요한 포인트예요.
실시간 이벤트 파이프라인 아키텍처
규칙 엔진이 판단을 내리려면, 거래 데이터가 실시간으로 흘러들어와야 해요. 이 데이터 흐름을 담당하는 게 실시간 이벤트 파이프라인이에요.
카카오뱅크의 FDS 파이프라인 아키텍처를 보면, 은행 거래 데이터가 SDA(Stream Data Adapter)를 거쳐 Kafka로 전달되고, Flink가 이벤트를 전처리한 뒤 Feature Store(Redis)에 저장하는 구조예요.
각 컴포넌트의 역할을 정리하면 이래요.
| 컴포넌트 | 역할 | 기술 선택 이유 |
|---|---|---|
| Kafka | 이벤트 스트리밍 | 높은 처리량, 내결함성, exactly-once 보장 |
| Flink | 실시간 전처리 | Native stream 처리, Java/Python 교차 지원 |
| Redis | 온라인 Feature Store | 5ms 미만 조회 속도, TTL 지원 |
| HBase | 오프라인 Feature Store | 대용량 이력 데이터 영속화 |
카카오뱅크가 Flink를 선택한 이유가 있어요. Kafka Streams는 가볍지만 복잡한 윈도우 연산에 한계가 있고, Spark Streaming은 마이크로배치 방식이라 진정한 실시간 처리가 어려워요. Flink는 네이티브 스트림 처리 엔진이라 이벤트 단위로 처리할 수 있고, 체크포인트 기반 장애 복구도 지원해요.
실무에서 주의할 점은 Flink 배포 모드 선택이에요. Session Cluster 모드는 여러 Job이 하나의 클러스터를 공유해서 리소스 효율이 좋지만, 한 Job의 장애가 다른 Job에 전파될 수 있어요. Application Cluster 모드는 Job별로 독립 클러스터를 사용해서 격리성이 좋지만, 관리 복잡도가 올라가요.
카카오뱅크는 자체 개발한 flink-dachery 라이브러리로 Kafka 발행/구독을 간편화하고, 설정 파일을 글로벌로 관리하고 있어요. 이런 내부 추상화 레이어가 있어야 데이터 사이언티스트가 전처리 로직에만 집중할 수 있어요.
Feature Store 설계도 중요해요. 실시간 데이터(직전 결제 금액, 최근 N분 거래 횟수)는 Redis에, 배치 데이터(고객 프로파일, 과거 사고 이력)는 HBase에 저장해요. Redis 키 설계 규칙은 CSTNO:{고객번호}:XF_EPE_H 형태로, 고객번호 기반으로 빠르게 조회할 수 있도록 구성해요.
배치 처리도 빠뜨릴 수 없어요. 고객 정보처럼 자주 바뀌지 않는 데이터는 Apache Airflow를 통해 24시간 주기로 데이터웨어하우스에서 Redis로 적재해요. 실시간 파이프라인과 배치 파이프라인이 하나의 Feature Store에서 만나는 구조예요.
ML 모델은 FDS에서 어떤 역할을 하나요
규칙 엔진만으로는 새로운 유형의 사기를 탐지하기 어려워요. 규칙은 "이미 알려진 패턴"을 잡는 데 강하지만, 처음 보는 패턴에는 무력해요. ML 모델은 이 한계를 보완해요.
카카오뱅크의 ML 서빙 아키텍처는 Spring Cloud 기반 분산 시스템으로 구성돼 있어요.
ML 서빙의 핵심 요건은 200ms 미만 응답이에요. 거래 승인/차단 판단이 지연되면 고객 경험이 나빠지거든요. 카카오뱅크는 DJL(Deep Java Library)을 사용해서 JVM 환경에서 10ms 수준의 추론 속도를 달성했어요.
| 서빙 요건 | 기술 선택 | 달성 수준 |
|---|---|---|
| 200ms 미만 응답 | gRPC + DJL | 10ms 추론 |
| 분산 환경 | Spring Cloud (Gateway + Discovery) | Kubernetes + AWS |
| 모델 배포 | Canary 배포 (Gateway 라우팅) | 무중단 전환 |
| 모니터링 | Prometheus + Grafana + Zipkin | 실시간 메트릭 |
카카오페이는 여기서 한 발 더 나아가 "적응형 ML(Adaptive ML)" 전략을 적용했어요. 정적 ML은 고정된 데이터셋으로 학습한 모델을 계속 사용하는 반면, 적응형 ML은 최신 데이터로 지속적으로 재학습해요.
적응형 ML의 핵심은 "자가 적응 피처(Self-Adaptive Feature)"예요. 예를 들어 "결제 아이템 종류별 최근 사고 비율"이라는 피처가 있으면, 새로운 게임이 출시되고 관련 사기가 발생했을 때 이 피처 값이 자동으로 올라가요. 모델을 재학습하기 전에도 새로운 패턴을 부분적으로 탐지할 수 있는 거예요.
카카오페이의 실측 결과에 따르면, 신규 사고 유형 발생 후 적응형 ML은 정적 ML 대비 약 30%의 탐지율 개선을 보여줬어요. D+0에 새로운 사고가 발생하면 D+3 시점부터 탐지율이 회복되기 시작해요.
학습 파이프라인은 Airflow가 정해진 주기로 최근 데이터를 수집하고, 모델을 학습한 뒤 MLflow에 등록해요. 기존 운영 모델과 성능(Recall, Precision, FP)을 비교해서 개선된 경우에만 Triton Inference Server에 배포하는 구조예요.
배치 프로파일링도 ML 기반 FDS에서 빠뜨릴 수 없는 요소예요. 고객 프로파일(평균 거래 금액, 주 이용 시간대, 자주 사용하는 가맹점 유형)은 실시간으로 계산하기엔 비용이 크고, 자주 바뀌지도 않아요. 카카오뱅크는 데이터웨어하우스에서 Airflow를 통해 24시간 주기로 고객 프로파일을 산출하고, 결과를 Redis에 적재해요. ML 모델이 추론할 때 실시간 피처(직전 거래 금액, 최근 5분 거래 횟수)와 배치 피처(고객 프로파일)를 결합해서 판단하는 구조예요. 이렇게 실시간과 배치를 분리하면 파이프라인 복잡도를 낮추면서도 풍부한 컨텍스트를 모델에 제공할 수 있어요.
망분리 환경에서 AI를 적용하는 방법
금융권에서 AI를 적용할 때 가장 큰 장벽은 망분리 규제예요. 전자금융감독규정은 내부망과 외부망을 물리적으로 분리하도록 요구하고 있어서, 클라우드 기반 생성형 AI 서비스를 직접 호출하는 게 원칙적으로 불가능해요.
2024년 8월 금융위원회가 발표한 "망분리 개선 로드맵"은 이 문제를 3단계로 풀어가고 있어요.
| 단계 | 시기 | 허용 범위 |
|---|---|---|
| 1단계 | 2024년~ | 혁신금융서비스 지정을 통해 생성형 AI 제한적 허용 |
| 2단계 | 2025년~ | 보안 검증 전제로 금융 데이터 SaaS 처리 허용 |
| 3단계 | 2026년~ | 디지털 금융보안법 제정, 자율보안-결과책임 원칙 |
당근페이가 FDS에 LLM을 적용한 방법이 좋은 사례예요. AWS Bedrock 서비스를 통해 Claude Sonnet 3.5 모델을 사용하되, 혁신금융서비스 지정을 받아서 규제 요건을 충족했어요.
혁신금융서비스 지정 절차는 이래요.
| 단계 | 내용 | 소요 기간 |
|---|---|---|
| 컨설팅 신청 | 금융규제 샌드박스 홈페이지에서 법률·기술·회계 전문가 지원 (무료) | 수시 |
| 신청서 제출 | 온라인 접수 (서비스 설명, 보안 대책, 이용자 보호 방안 포함) | 수시 |
| 심사 | 혁신금융심사위원회 심의 | 최대 120일 |
| 지정 결정 | 금융위원회 정례회의 의결 | 심사 후 |
2024년 11월에 첫 생성형 AI 혁신금융서비스가 지정됐고, 2026년 4월 기준으로 누적 169건이 지정됐어요. 당근페이도 이 절차를 통해 AWS Bedrock 기반 FDS를 운영하고 있어요.
AWS Bedrock 서울 리전(ap-northeast-2)은 2024년 10월에 개설됐어요. 이전에는 싱가포르 리전을 경유해야 해서 데이터 주권 우려와 높은 지연시간 문제가 있었지만, 서울 리전 개설 이후 국내 데이터 저장 의무를 충족하면서 저지연 서비스가 가능해졌어요.
여기서 주의할 점이 있어요. 혁신금융서비스 지정은 특정 모델에 대해 받는 거예요. 당근페이의 경우 Claude Sonnet 3.5로 지정을 받았는데, 더 좋은 모델이 나와도 바로 교체할 수 없었어요. 2026년 4월에 금융위원회가 "보안 영향도 3단계 분류" 제도를 도입하면서 이 문제가 완화됐어요. 경미한 변경(마이너 버전 업데이트)은 서면 확인만으로 가능하고, 보통 수준의 변경은 금융보안원 평가를 거치면 돼요.
당근페이의 LLM 적용 구조는 3단계로 진화했어요.
| 단계 | 구성 | 효과 |
|---|---|---|
| 1단계 | Prompt + ConverseAPI | 거래 정보를 LLM에 전달해서 사기 여부 평가 |
| 2단계 | RAG 도입 | AWS Bedrock Knowledge Base로 유사 사기 사례 검색, 평가 정확도 향상 |
| 3단계 | Retrieve + Prompt + Converse 통합 | 거래 데이터 → 유사 사례 검색 → LLM 평가 → 위험 점수 산출 |
RAG 시스템은 S3에 저장된 과거 사기 이력을 벡터 임베딩으로 변환하고, 현재 거래와 유사도가 높은 사례를 검색해서 LLM의 컨텍스트로 제공해요. 이렇게 하면 LLM이 "이 거래는 과거 X 사기 패턴과 유사하다"는 근거를 가지고 판단할 수 있어요.
오탐율을 줄이면서 탐지율을 높이는 운영 전략
FDS 운영에서 가장 어려운 문제는 탐지율(Recall)과 정밀도(Precision)의 균형이에요. 탐지율을 높이면 오탐(False Positive)이 늘어나서 정상 고객이 차단당하고, 정밀도를 높이면 미탐(False Negative)이 늘어나서 실제 사기를 놓치게 돼요.
실무에서 이 균형을 잡는 전략은 여러 가지예요.
첫 번째는 다단계 대응 체계예요. 위험 점수에 따라 대응 수준을 세분화하면 오탐으로 인한 고객 불편을 최소화할 수 있어요.
| 위험 점수 | 대응 수준 | 고객 경험 |
|---|---|---|
| 0–30 | 정상 승인 | 영향 없음 |
| 31–60 | 추가 인증 요구 (SMS/생체) | 10초 지연 |
| 61–80 | 거래 보류 + 고객 확인 전화 | 수 분 지연 |
| 81–100 | 즉시 차단 + 계정 잠금 | 거래 불가 |
두 번째는 규칙과 ML의 앙상블이에요. 규칙 엔진은 "확실한 사기"를 빠르게 차단하고, ML 모델은 "애매한 거래"의 위험도를 정밀하게 산출해요. 두 시스템의 판단을 결합해서 최종 점수를 내면, 단독 사용 대비 오탐율을 낮추면서 탐지율을 유지할 수 있어요.
세 번째는 피드백 루프 자동화예요. 오탐으로 판정된 거래 데이터를 자동으로 수집해서 모델 재학습에 반영하면, 시간이 지날수록 오탐이 줄어들어요. 카카오페이의 적응형 ML이 바로 이 접근이에요. 사고 데이터가 쌓이면 피처 값이 자동으로 업데이트되고, 정해진 주기로 모델이 재학습돼요.
운영하면서 계속 느낀 건, 오탐율 관리는 기술 문제이면서 동시에 조직 문제라는 거예요. FDS 운영팀, CS팀, 리스크관리팀이 같은 대시보드를 보면서 오탐 패턴을 분석하고, 규칙 임계값을 조정하는 프로세스가 있어야 해요. 기술만으로는 풀 수 없는 부분이에요.
FDS 구축 시 고려해야 할 인프라 설계 포인트
FDS를 실제로 구축할 때 놓치기 쉬운 인프라 설계 포인트를 정리해 볼게요.
| 설계 포인트 | 핵심 요건 | 실무 기준 |
|---|---|---|
| Kafka 클러스터 | 이중화 필수 | 최소 3 브로커, 리플리케이션 팩터 3 |
| Feature Store | 온라인/오프라인 분리 | Redis(실시간) + HBase(이력) |
| 모델 배포 | Canary 배포 | 5–10% 트래픽으로 시작, 점진 확대 |
| 감사 로그 | 5년 보관 | 판단 근거 전체 로깅 (규칙 + ML 입출력) |
Kafka가 장애나면 모든 거래 모니터링이 중단되기 때문에, 브로커 1대가 죽어도 데이터 유실 없이 운영할 수 있는 구성이 기본이에요.
Feature Store는 실시간 추론용 피처(Redis)와 모델 학습용 이력 데이터(HBase/BigQuery)를 분리하되, 두 저장소 간 데이터 일관성을 보장하는 동기화 메커니즘이 필요해요.
모델 Canary 배포는 새 모델을 전체 트래픽에 바로 적용하지 않고, Gateway에서 소량의 트래픽만 새 모델로 라우팅해서 성능 지표를 확인한 뒤 점진적으로 비율을 높이는 방식이에요.
감사 로그는 금융감독원 IT 검사 대응을 위해 필수예요. 모든 탐지 판단의 근거(어떤 규칙이 트리거됐는지, ML 모델의 입력/출력, 최종 대응 액션)를 5년간 보관해야 하거든요.
핵심 요약
- FDS는 정보수집 → 분석·탐지 → 대응 → 모니터링·감사 4단계 파이프라인으로 구성돼요
- 규칙 엔진은 Condition → Rule → Policy 3계층 구조로, 배포 없이 탐지 로직을 유연하게 변경할 수 있어요
- 실시간 파이프라인은 Kafka → Flink → Feature Store(Redis) → ML Serving 구조가 업계 표준이에요
- ML 서빙은 200ms 미만 응답이 필수이고, 적응형 ML로 신규 사기 유형에 30% 빠르게 대응할 수 있어요
- 망분리 환경에서 생성형 AI를 적용하려면 혁신금융서비스 지정이 필요하고, AWS Bedrock 서울 리전 개설로 데이터 주권 문제가 해소됐어요
- 오탐율과 탐지율의 균형은 다단계 대응 체계 + 규칙/ML 앙상블 + 피드백 루프 자동화로 풀어요
FAQ
Q. FDS의 4대 기능은 무엇인가요?
FDS는 정보수집, 분석·탐지, 대응, 모니터링·감사 4가지 기능으로 구성돼요. 정보수집은 거래 발생 시점의 단말기·접속·거래 정보를 실시간으로 수집하고, 분석·탐지는 규칙 엔진과 ML 모델로 위험도를 산출해요. 대응은 위험 수준에 따라 승인/추가인증/보류/차단 중 하나를 선택하고, 모니터링·감사는 탐지 결과를 사후 검증해서 규칙과 모델을 개선하는 피드백 루프를 형성해요.
Q. 금융권 FDS에 AI/ML을 적용할 때 망분리 규제는 어떻게 해결하나요?
2024년 8월 금융위원회가 발표한 망분리 개선 로드맵에 따라, 혁신금융서비스 지정을 통해 생성형 AI를 제한적으로 허용하고 있어요. 당근페이는 이 절차를 통해 AWS Bedrock 기반 LLM(Claude Sonnet 3.5)을 FDS에 적용했어요. 2024년 10월 AWS Bedrock 서울 리전 개설로 데이터 주권 문제도 해소됐고, 2026년 4월부터는 모델 변경 절차도 간소화됐어요.
Q. 규칙 엔진 기반 FDS와 ML 기반 FDS의 차이는 무엇인가요?
규칙 엔진은 "이미 알려진 사기 패턴"을 빠르게 탐지하는 데 강해요. 새로운 규칙을 즉시 추가할 수 있고, 판단 근거가 명확해서 감사 대응이 쉬워요. 반면 ML 모델은 "처음 보는 패턴"을 탐지할 수 있고, 복잡한 상관관계를 학습할 수 있어요. 실무에서는 둘을 결합해서 사용해요. 규칙 엔진이 확실한 사기를 빠르게 차단하고, ML 모델이 애매한 거래의 위험도를 정밀하게 산출하는 구조예요.
Q. FDS 구축 시 최소한으로 필요한 인프라 구성은 무엇인가요?
최소 구성은 이벤트 수집(Kafka 3노드), 실시간 처리(Flink), 피처 저장(Redis), 규칙 엔진, 모니터링 대시보드예요. ML 서빙은 초기에는 없어도 규칙 엔진만으로 운영 가능하지만, 거래 규모가 커지면 ML 모델 추가가 필수예요. 금융감독원 검사 대응을 위한 감사 로그 시스템(5년 보관)도 처음부터 설계에 포함해야 해요.
Q. 혁신금융서비스 지정 없이 FDS에 생성형 AI를 적용할 수 있나요?
2026년 5월 현재, 금융권에서 생성형 AI를 업무에 적용하려면 여전히 혁신금융서비스 지정이 필요해요. 다만 2026년 1월부터 사무·협업용 SaaS는 원칙적으로 허용됐고, R&D 환경에서는 인터넷 활용과 가명정보 사용이 가능해졌어요. 운영 환경에서 실제 고객 데이터를 처리하는 FDS에 생성형 AI를 적용하려면 혁신금융서비스 지정이 필수예요.