본문으로 건너뛰기

Jumio의 AWS 실시간 Feature Store 구축

Jumio가 AWS 기반 실시간 Feature Store로 사기 탐지 지연과 운영 비용을 함께 낮춘 구조를 구축했습니다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Jumio는 팀별로 분산된 Feature 정의와 수동 배포, 지연 이벤트 처리 문제를 해결하기 위해 Amazon Kinesis Data Streams와 Apache Flink를 중심으로 한 streaming-first Feature Store를 구축했습니다. 실시간 이벤트는 Flink에서 변환된 뒤 Amazon SageMaker Feature Store의 인메모리 저장소로 전달되고, 같은 데이터는 Amazon S3·Amazon EMR·Apache Iceberg를 거쳐 모델 학습과 분석에 쓰이는 오프라인 저장소로도 축적됩니다. 95번째 백분위 응답 시간은 16.9밀리초, 읽기 P50은 8.44밀리초, 쓰기 P50은 18.6밀리초였으며, 인메모리 저장소 최적화로 연간 약 120,000달러의 운영 비용을 줄였습니다. 중앙화된 Feature 정의와 자동화된 배포는 학습·추론 불일치를 낮추지만, 여러 AWS 서비스의 통합과 비용 관리를 위해 전문성이 필요합니다.

섹션별 상세

01
Jumio의 사기 탐지 모델은 신원 확인 과정에서 최신 Feature를 빠르게 읽어야 했지만, 팀별 오프라인 저장소와 수작업 배포가 Feature 정의의 불일치와 운영 버그를 만들었습니다. 이벤트가 불규칙하게 늦게 도착하는 경우까지 처리해야 했기 때문에 단순한 배치 저장소로는 충분하지 않았습니다. 중앙화된 재사용 Feature Store는 동일한 Feature를 학습과 추론에 제공하면서 100밀리초 미만의 응답 목표를 뒷받침하는 핵심 구성으로 자리 잡았습니다.
02
Jumio의 구조는 Amazon Kinesis Data Streams에서 들어온 이벤트를 Apache Flink가 실시간으로 변환·보강하고 Amazon SageMaker Feature Store에 기록하는 streaming-first 방식입니다. 병렬 경로에서는 Amazon Data Firehose가 이벤트를 Amazon S3로 전달하고, Amazon EMR이 무거운 변환을 수행한 뒤 처리 결과를 표준 Feature Store와 Apache Iceberg 테이블에 적재합니다. 이 입력·처리·저장 분리는 실시간 추론과 모델 학습용 과거 데이터라는 서로 다른 요구를 한 아키텍처 안에서 처리하게 합니다.
Kinesis와 Amazon Managed Service for Apache Flink가 실시간 Feature를 처리해 Amazon SageMaker Feature Store로 보내고, 별도 경로가 Amazon S3·Amazon EMR·Apache Iceberg 기반 오프라인 저장소를 구성하는 AWS 아키텍처 다이어그램입니다.
Diagram이미지는 실시간 경로와 오프라인 경로가 Kinesis에서 갈라지는 streaming-first 구조를 보여줍니다. 실시간 Feature는 인메모리 저장소에서 모델 추론으로 전달되고, 오프라인 데이터는 S3와 EMR을 거쳐 Iceberg 및 학습 경로로 이동해 낮은 추론 지연과 과거 데이터 활용을 동시에 지원합니다.
03
실시간 저장소는 최근에 자주 읽는 Feature를 Amazon ElastiCache for Valkey 기반 인메모리 저장소에 두고, 덜 자주 접근하는 값은 확장성과 내구성을 갖춘 표준 저장소에 보관합니다. 모델은 먼저 온라인 저장소에서 Feature를 읽어 추론하고, 오프라인 데이터는 Amazon Athena와 Amazon EMR 노트북·작업 및 내부 데이터셋 준비 도구에서 활용합니다. 인메모리와 표준 저장소를 나누는 계층형 전략은 읽기 지연 시간과 저장 비용 사이의 균형을 맞추는 역할을 합니다.
04
지연 도착 이벤트는 Feature Store 운영에서 별도의 정합성 문제를 일으키며, 사건 직후뿐 아니라 장기간의 검토 뒤 몇 주 후에도 들어올 수 있습니다. 온라인 저장소는 이벤트가 도착한 시점마다 키별 레코드를 갱신하므로 아직 관측되지 않은 Feature는 비어 있고, 후속 이벤트가 도착하면 해당 키의 값과 업데이트 시간이 추가됩니다. 이러한 처리 방식은 늦게 들어온 정보가 기존 레코드를 무작정 덮어쓰지 않고 이벤트 흐름에 따라 누적되도록 만듭니다.
시간 T1, T2, T5에 도착한 이벤트가 Feature Store 레코드에 순차적으로 반영되는 과정과 지연 도착 이벤트 처리 결과를 나타낸 다이어그램입니다.
Diagram이미지는 이벤트가 도착한 시점에 이용 가능한 Feature만 레코드에 기록되고, 이후 같은 키에 대한 이벤트가 들어오면 새로운 Feature와 업데이트 시간이 추가되는 흐름을 보여줍니다. 이를 통해 늦게 도착한 이벤트가 실시간 Feature의 부분적 상태와 이후 보정 과정을 어떻게 만드는지 확인할 수 있습니다.
05
운영팀은 실시간 경로에서 Kinesis 소비부터 Flink Sink, Amazon SageMaker Feature Store 기록까지 각 구간의 지연 시간을 측정하고, Apache Flink의 Busy time, Kinesis Processing Unit 사용량, 체크포인트 시간, CPU·메모리 사용량과 Backpressure를 추적합니다. Feature Store에서는 GET·PUT 요청량, 읽기·쓰기 지연, 타임아웃, 레코드 출력 크기를 확인하며, 오프라인 경로에서는 Firehose의 유입량과 Amazon S3 전달 지연·성공률을 관찰합니다. 이런 지표 조합은 모델 예측을 조용히 훼손할 수 있는 스트리밍 장애와 지연 증가를 조기에 포착하는 데 쓰입니다.
06
측정 결과 95번째 백분위 응답 시간은 16.9밀리초로 사기 탐지의 100밀리초 미만 SLA를 충족했습니다. 읽기 지연 시간의 P50은 8.44밀리초, 쓰기 지연 시간의 P50은 18.6밀리초로 나타나 실시간 Feature 제공과 기록 모두 밀리초 단위에서 처리됐습니다. 기존 팀별 저장소를 통합하고 Amazon SageMaker Feature Store의 인메모리 저장소를 최적화한 결과 Jumio는 연간 약 120,000달러의 운영 비용을 절감했습니다.
07
이전에는 조직 내 팀들이 각자 Feature를 정의하고 오프라인 학습 결과를 Java 또는 Python 코드로 수동 재구현했기 때문에 배포까지 수주가 걸리고 학습·추론 불일치 위험이 컸습니다. 현재 구조는 중앙화된 Feature 정의와 자동화된 배포를 사용하고, upstream model output에도 실시간으로 접근하며 늦게 도착한 Feature를 처리합니다. AWS 관리형 서비스는 인프라 운영 부담을 줄이지만 여러 서비스를 통합하는 복잡성과 비용 최적화를 위해 높은 AWS 전문성이 필요하다는 절충점이 남습니다.
08
구축 원칙은 streaming-first 처리, 중앙화된 Feature 정의, 인메모리와 표준 저장소를 결합한 계층형 보관, 지연·건강 상태 모니터링, 그리고 backend·ML·data engineering 팀의 협업으로 정리됩니다. 이벤트를 실시간으로 Feature로 바꾸고 동일한 정의를 여러 팀이 재사용하면 새 모델과 Feature를 개발할 때 반복 구현과 인수인계가 줄어듭니다. 이 패턴은 사기 탐지뿐 아니라 추천 등 낮은 지연 시간의 예측이 필요한 ML 업무에도 적용할 수 있습니다.

용어 해설

Feature Store
머신러닝 모델이 사용하는 Feature를 저장하고 제공하는 시스템입니다. 온라인 저장소는 추론 요청에 맞춰 짧은 지연 시간으로 최신 값을 반환하고, 오프라인 저장소는 학습·평가·디버깅에 필요한 과거 데이터를 보관합니다. 두 저장소의 Feature 정의를 통일하면 학습과 추론 사이의 불일치를 줄일 수 있습니다.
스트림 처리(Stream Processing)
데이터가 대량으로 쌓일 때까지 기다리지 않고 이벤트가 도착하는 즉시 처리하는 방식입니다. 이 글에서는 Amazon Kinesis Data Streams로 유입된 이벤트를 Apache Flink가 변환·보강한 뒤 Feature로 만들고 온라인 저장소에 기록합니다. 사기 탐지처럼 최신 정보가 필요한 추론에서 지연 시간을 낮추는 기반입니다.
Apache Iceberg 테이블(Apache Iceberg Table)
대규모 분석 데이터를 테이블 형태로 관리하는 오픈 테이블 포맷입니다. 이 아키텍처에서는 Amazon S3에 저장된 처리 결과를 Iceberg 테이블로 적재해 오프라인 Feature Store 역할을 맡깁니다. Amazon Athena와 Amazon EMR에서 학습·분석용 과거 Feature를 조회할 수 있습니다.
지연 도착 이벤트(Late-Arriving Events)
실제 사건이 발생한 시점보다 늦게 데이터 파이프라인에 도착하는 이벤트입니다. 장기간의 검토 절차 때문에 초기 활동 직후 또는 몇 주 뒤에 들어올 수 있으며, 이미 기록된 Feature와 별도로 처리해야 합니다. Feature Store는 이벤트 시간과 키를 기준으로 기존 레코드와 새 값을 조정해야 합니다.
과거 데이터 백필(Backfill)
새로운 Feature 정의나 수정된 처리 로직을 과거 데이터에 다시 적용해 학습·평가용 기록을 채우는 작업입니다. 실시간 추론만으로는 과거 시점의 상태를 재현하기 어렵기 때문에 오프라인 Feature Store가 필요합니다. 이 글의 구조에서는 Amazon S3와 Apache Iceberg가 백필과 모델 재학습을 지원합니다.

기술

  • Amazon SageMaker Feature Store
  • Amazon Managed Service for Apache Flink
  • Amazon Kinesis Data Streams
  • Amazon Data Firehose
  • Amazon S3
  • Amazon EMR
  • Amazon EMR Serverless
  • Amazon ElastiCache for Valkey
  • Apache Iceberg
  • Amazon Athena
  • AWS Lambda
  • AWS Glue Data Catalog
  • AWS Lake Formation
  • Java
  • Python

활용 사례

  • 실시간 사기 탐지
  • 신원 확인
  • 추천 시스템
  • 낮은 지연 시간의 실시간 ML 예측
  • 모델 재학습과 과거 데이터 백필
  • ML 모델 디버깅·평가·모니터링
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 08. 19.수집 2026. 08. 19.출처 타입 RSS

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.