P95 지연시간 16.9ms 달성, 사기 탐지 SLA를 충족한 중앙 집중형

Jumio는 사기 탐지 서비스 수준 협약(SLA, 서비스 제공자가 고객과 약속한 성능 지표) 요구사항인 100ms 미만 응답 시간을 달성하기 위해 시스템을 재설계했으며, 최종적으로 P95(전체 요청 중 상위 95%의 응답 시간) 지연시간 16.9ms를 기록했다. 이 수치는 실시간 사기 탐지 모델이 요청을 받은 즉시 판단에 필요한 최신 데이터를 공급받을 수 있는 상태임을 증명한다. 단순한 성능 개선이 아니라, 데이터 공급 속도가 모델의 판단 속도를 결정하는 제약 사항을 해결함으로써 서비스의 신뢰도를 높이는 선택을 한 것이다.

기존 시스템의 가장 큰 문제는 피처 엔지니어링(모델 학습과 추론에 필요한 변수를 생성하고 가공하는 과정) 체계가 여러 팀과 서비스에 파편화되어 있었다는 점이다. 동일한 성격의 데이터가 서로 다른 경로로 중복 생성되었고, 이로 인해 실시간 추론 시점과 학습 시점의 데이터가 서로 다른 피처 불일치 현상이 발생했다. 특히 새로운 피처를 추가하거나 변경할 때마다 수동 배포 과정을 거쳐야 했으며, 이는 운영 리소스를 과다하게 소모하게 만들었다. 이러한 구조적 한계는 데이터 처리 경로를 복잡하게 만들어 응답 지연 시간을 높이는 결정적인 원인이 되었다.

Jumio는 이러한 파편화를 해결하기 위해 Amazon SageMaker Feature Store(머신러닝 피처를 저장하고 관리하는 중앙 저장소), Apache Flink(실시간 데이터 스트림 처리 엔진), Amazon Kinesis(실시간 데이터 수집 및 전송 서비스)를 결합한 중앙 집중형 실시간 피처 스토어를 구축했다. 핵심은 데이터의 생성부터 저장까지의 흐름을 단일화하여 어떤 모델이든 동일한 피처를 즉시 가져다 쓸 수 있는 재사용성을 확보하는 것이었다. 이를 통해 데이터 중복을 원천적으로 차단하고, 실시간으로 업데이트되는 피처를 저지연으로 읽어올 수 있는 기반을 마련했다.

최종적으로 구축된 중앙 집중형 체계는 P95 지연시간 16.9ms라는 결과로 이어지며 100ms 미만이라는 엄격한 SLA 기준을 여유 있게 충족했다. 이는 수동 배포와 분산된 데이터 관리라는 기존의 비효율을 제거하고, 인프라 수준에서 데이터 일관성과 속도를 동시에 잡았을 때 나타나는 결과다. 실시간 사기 탐지와 같이 찰나의 순간에 정확한 판단을 내려야 하는 서비스에서, 중앙 집중형 피처 스토어는 데이터 가공 시간을 최소화하고 모델의 추론 효율을 극대화하는 실무적 대안이 된다.

Kinesis에서 SageMaker까지, 스트리밍

실시간 데이터는 Amazon Kinesis Data Streams를 통해 유입되어 Amazon Managed Service for Apache Flink에서 즉시 가공된다. 실시간 스트림 처리 엔진인 Flink는 유입되는 이벤트를 포착해 데이터가 이동하는 도중에 필요한 정보를 보강하고 가공하는 인플라이트(in-flight) 처리를 수행한다. 이는 원시 데이터에 실시간으로 맥락을 추가해 모델이 즉각 판단할 수 있는 형태로 만드는 과정이다. 이렇게 정제된 피처는 Amazon SageMaker Feature Store라는 중앙 집중식 저장소에 직접 기록되어 예측 모델이 즉각 사용할 수 있는 상태가 된다.

모델 학습을 위한 오프라인 경로는 이와 병렬로 작동하며 상대적으로 연산량이 많은 작업을 처리한다. Amazon Data Firehose라는 데이터 전송 서비스를 통해 이벤트가 Amazon S3 객체 스토리지로 전달되면, S3의 이벤트 알림이 Amazon EMR 빅데이터 처리 클러스터를 자동으로 작동시킨다. EMR은 실시간 경로에서 처리하기 어려운 복잡하고 무거운 변환 작업을 배치 단위로 수행한다. 처리된 결과물은 대규모 데이터셋을 효율적으로 관리하는 고성능 테이블 포맷인 Apache Iceberg 테이블에 저장되어 모델 학습의 기초 자료로 쓰인다. 이 과정에서 생성된 데이터는 SageMaker Feature Store에 콜드 데이터(Cold data, 접근 빈도가 낮은 과거 데이터) 형태로 저장되어 필요할 때 참조된다.

전체 아키텍처는 글로벌 서비스 대응을 위해 세 개의 AWS 리전으로 분산 배포했다. 미국 동부의 버지니아 북부(us-east-1), 유럽의 프랑크푸르트(eu-central-1), 그리고 아시아 태평양의 싱가포르(ap-southeast-1) 지역에 동일한 구조를 구축했다. 리전별 분산 배포는 사용자 접점에서의 지연 시간을 줄이고 데이터 거버넌스 요구사항을 충족하기 위한 선택이다. 실시간 예측을 위한 고속 경로와 모델 학습을 위한 대용량 경로를 분리 설계함으로써, 학습 데이터의 규모가 확장되더라도 실시간 예측 서비스의 응답 속도에는 영향을 주지 않는 독립적인 운영 환경을 구현했다.

인메모리 계층화와 지연 이벤트 처리로 푼 트레이드오프

인메모리 스토어와 표준 스토리지를 혼합해 운영하며 저지연 응답과 비용 효율이라는 상충하는 목표를 동시에 달성했다. 저지연이 필수적인 실시간 예측용 데이터는 메모리 기반의 인메모리 스토어에 배치하고, 상대적으로 접근 빈도가 낮거나 저장 용량이 큰 데이터는 표준 스토어에 저장하는 계층형 스토리지 전략을 사용했다. 모든 데이터를 고가의 메모리에 올릴 때 발생하는 비용 부담을 줄이면서도, 실제 모델이 예측을 수행하는 시점에는 필요한 피처를 밀리초 단위로 빠르게 읽어올 수 있게 설계했다. 단순히 성능만을 쫓아 모든 자원을 메모리에 할당하는 대신, 데이터의 생애주기와 활용 목적을 구분해 저장소를 분리한 점이 핵심이다. 데이터의 접근 빈도와 중요도에 따라 저장 위치를 나누는 방식은 인프라 운영 비용을 최적화하면서 성능을 유지하는 실무적인 판단 기준이 된다.

실시간 스트리밍 환경에서 빈번하게 발생하는 데이터 도착 지연 문제는 별도의 처리 로직을 구현해 해결했다. 네트워크 지연이나 시스템 부하로 인해 피처가 정해진 윈도우 시간보다 늦게 도착하는 경우, 이를 단순히 버리지 않고 보정하여 반영하는 지연 이벤트 처리 기법을 적용했다. 이 과정에서 데이터의 순서가 뒤바뀌거나 일부가 누락되어 모델의 예측 정확도가 떨어지는 현상을 방지하고 데이터의 정합성을 유지했다. 윈도우 처리란 특정 시간 범위 내의 데이터를 묶어 계산하는 방식이며, 지연 이벤트 처리는 이 범위를 벗어나 도착한 데이터를 기존 상태에 어떻게 병합할지 정의하는 세부 로직이다. 이는 실시간성과 정확도 사이의 트레이드오프를 해결하며 사기 탐지와 같은 정밀한 예측 환경에서 데이터 신뢰도를 높이는 핵심 장치로 작동한다.

시스템의 전체적인 건강 상태를 확보하기 위해 Flink 애플리케이션 상태와 SageMaker Feature Store 성능, Data Firehose 메트릭을 실시간으로 추적했다. Flink(분산 스트림 처리 프레임워크)의 상태를 모니터링해 데이터 가공 및 보강 단계에서 병목이 발생하는지 확인하고, SageMaker Feature Store(머신러닝 피처 저장소)의 읽기 및 쓰기 성능 지표를 통해 실제 서비스 응답 속도를 관리했다. 또한 Data Firehose(실시간 데이터 스트리밍 서비스)의 메트릭을 통해 데이터 유실 여부와 처리량을 상시 감시하며 파이프라인의 안정성을 검증했다. 이 세 가지 지표는 각각 가공, 저장, 전송이라는 서로 다른 단계를 담당하며, 통합 모니터링을 통해 장애 발생 시 원인 지점을 빠르게 특정하고 대응할 수 있는 기술적 근거가 된다.

연간 12만 달러 비용 절감과 배포 자동화의 실질적 효

인메모리 스토어 최적화만으로 기존 분산 스토어 대비 연간 약 120,000달러의 운영 비용을 줄였다. 이전에는 여러 팀이 개별적으로 피처 스토어를 운영하며 비용이 파편화되어 발생했다. 이를 Amazon SageMaker Feature Store의 인메모리 스토어로 통합하며 중복 지출을 제거했다. 인메모리 스토어는 데이터를 메모리에 상주시켜 빠르게 읽고 쓰는 저장 방식이다. 비용 절감은 단순히 도구를 바꾼 결과가 아니라 저장 구조를 최적화해 불필요한 자원 낭비를 막은 결과다.

수주(weeks)가 소요되던 수동 구현 방식을 자동화 및 통합 배포 체제로 전환했다. 과거에는 새로운 피처를 정의하고 모델에 적용하기 위해 데이터 엔지니어가 직접 스토리지 설정을 변경하고 배포 스크립트를 실행하는 수동 과정을 거쳐야 했다. 이 과정에서 팀 간의 조율과 검증 단계가 반복되며 실제 적용까지 수주가 걸리는 병목 현상이 발생했다. 현재는 통합 배포 프로세스를 통해 피처 정의부터 적용까지의 경로를 단축했다. 실무자는 이제 인프라 설정이라는 단순 반복 작업에서 벗어나 피처의 유효성을 검증하는 설계 작업에 더 많은 시간을 할애한다.

실제 성능 측정 결과 P50 읽기 지연 시간은 8.44ms, P50 쓰기 지연 시간은 18.6ms를 기록했다. P50은 전체 요청의 50%가 이 시간 안에 처리되었음을 의미하는 중앙값 지표다.

읽기 지연 시간이 10ms 미만으로 유지된다는 것은 실시간 판단이 필요한 서비스에서 데이터 조회 단계의 병목이 거의 없음을 뜻한다.

쓰기 지연 시간 역시 20ms 미만으로 관리되어 데이터 업데이트와 모델 추론 사이의 시차를 최소화했다. 이는 스트리밍 데이터가 생성되는 즉시 피처 스토어에 반영되어 모델이 항상 최신 상태의 정보를 바탕으로 추론할 수 있는 환경을 구축했음을 보여준다.

분산되어 있던 피처 정의 방식을 중앙 집중식으로 통합하며 운영 리소스 낭비를 막았다. 이전에는 조직 내 여러 팀이 동일한 피처를 각자의 방식으로 정의해 중복 계산과 저장 공간 낭비가 심했고, 이는 곧 비용 상승으로 이어졌다. 이를 재사용 가능한 중앙 저장소 형태로 통합하면서 데이터 파이프라인의 복잡도를 낮추고 일관성을 확보했다. 결과적으로 운영 인력이 수동 배포와 중복 관리에 쏟던 리소스를 고부가가치 모델 개선 작업으로 전환했다. 인프라 자동화와 스토리지 최적화는 단순한 비용 절감을 넘어 제품 출시 속도를 높이는 실무적 기반이 된다.

한국 ML 실무자를 위한 실시간 피처 스토어 도입 판단 기준

실시간 피처 스토어의 설계는 모델이 데이터를 즉각적으로 사용할 수 있게 만드는 스트리밍 우선 방식으로 시작한다. 중앙 집중식 피처 정의를 통해 서로 다른 팀이 동일한 피처를 일관되게 재사용하며 데이터 중복을 제거한다. 이는 데이터 정의가 파편화되어 학습 시점과 추론 시점의 데이터 값이 달라지는 학습-서빙 스큐 문제를 방지하는 실무적 장치가 된다. 공통의 피처 카탈로그를 운영하면 새로운 모델을 개발할 때 기존에 검증된 피처를 즉시 가져다 쓸 수 있어 개발 기간이 단축된다.

인메모리 스토어와 표준 스토어를 함께 사용하는 계층형 스토리지 전략으로 지연 시간과 비용의 상충 관계를 해결한다. 저지연이 필요한 추론용 데이터는 인메모리에, 대량의 학습용 데이터는 표준 스토어에 배치해 운영 효율을 높인다. 단일 스토리지 구조만 고집할 경우 비용이 급증하거나 응답 속도가 느려지는 병목 현상이 발생한다. 피처 스토어의 상태와 지연 시간을 실시간으로 모니터링하여 데이터 오염이 모델 예측 결과에 영향을 주는 무음 성능 저하 현상을 막는다. 운영 안정성은 도구의 기능보다 지표를 통해 데이터의 신선도를 상시 관리하는 체계를 갖췄는지에 따라 결정된다.

백엔드, ML, 데이터 엔지니어링 팀이 유기적으로 움직이는 교차 기능 협업 구조를 구축해 아이디어 단계에서 실제 배포까지의 마찰을 없앤다. 특정 팀이 데이터를 가공해 넘겨주는 핸드오프 방식은 피처 개발 주기를 늘리고 운영 단계의 소통 비용을 높인다. ML 엔지니어가 필요한 피처를 정의하면 데이터 엔지니어가 파이프라인을 구성하고 백엔드 팀이 이를 서비스에 통합하는 일련의 과정이 하나의 워크플로로 통합되어야 한다. 기술적 구현에 앞서 팀 간의 역할 분담과 피처 정의 프로세스를 먼저 정립해야 실제 프로덕션 환경에서의 배포 속도가 빨라진다.

사기 탐지나 추천 시스템처럼 밀리초 단위의 저지연 예측이 필수적인 ML 서비스에서 이러한 설계 원칙은 필수적이다. 세부적인 서비스 구성과 API 활용법은 Amazon SageMaker Feature Store 공식 문서에서 확인할 수 있다. 실시간 ML 예측 시스템 구축 시 P50 읽기 8.44ms 및 쓰기 18.6ms 지연 시간 벤치마크를 기준으로 현재 인프라의 운영 비용 절감 가능성을 먼저 검토하라.