Devin.KR
데빈의 AI 기술 뉴스룸

Amazon SageMaker Feature Store, UpdateRecord API로 피처 수준 쓰기 지원

Amazon SageMaker Feature Store가 UpdateRecord API를 도입하여 전체 레코드를 읽고 수정 후 다시 쓰는 방식 대신 개별 피처 값만 업데이트할 수 있게 되었다. 이로써 지연 시간을 줄이고, 비용을 절감하며, 동시 업데이트 시 데이터 손실 위험을 최소화한다.

데빈 · AI 기술 에디터 · 9분 읽기

AI 추론의 일반 흐름: 입력 데이터, 모델 계산, 출력 검토
Devin.KR 제작 · 주제 이해를 돕는 개념도. 이 기사의 실제 제품·구성이나 취재 사진을 나타내지 않습니다.

Amazon SageMaker Feature Store가 `UpdateRecord` API를 도입하여 피처 수준(feature-level) 쓰기 기능을 지원한다. 기존에는 피처 그룹 내 단일 피처 값을 변경하더라도 `PutRecord` API를 사용하여 전체 레코드를 읽고, 애플리케이션 코드에서 새 값을 병합한 후, 다시 전체 레코드를 쓰는 '읽기-수정-쓰기(read-modify-write)' 주기가 필요했다. 이제 `UpdateRecord` API를 사용하면 변경하려는 피처 값만 제공하여 기존 레코드에 원자적으로(atomically) 업데이트를 적용할 수 있다. 요청에 포함되지 않은 피처는 그대로 유지된다. 이 기능은 Standard (Amazon DynamoDB 기반) 및 In-Memory (Amazon ElastiCache 기반) 온라인 스토어 계층 모두에서 사용할 수 있다.

이전의 전체 레코드 쓰기 방식은 여러 가지 문제를 야기했다. 첫째, 업데이트당 추가적인 지연 시간을 발생시켰다. 둘째, 불필요한 읽기 용량을 소비하여 비용을 증가시켰다. 특히 대규모 피처 그룹과 높은 업데이트 빈도를 가진 고객의 경우 이러한 비용 부담이 컸다. 셋째, 여러 파이프라인이 동일한 레코드의 다른 피처를 동시에 업데이트할 때 경합 조건(race condition)을 유발하여 한 파이프라인의 쓰기가 다른 파이프라인의 변경 사항을 덮어쓰는 '손실된 업데이트(lost-update)' 문제가 발생할 수 있었다. `UpdateRecord` API는 이러한 읽기-수정-쓰기 주기를 제거함으로써 지연 시간, 비용, 데이터 일관성 문제를 해결하고, 여러 파이프라인이 독립적으로 피처를 업데이트할 수 있도록 지원한다.

`UpdateRecord` API 호출 시 클라이언트 애플리케이션은 변경된 피처만 전달한다. Feature Store 서비스는 AWS Identity and Access Management (IAM) 권한을 검증하고, `EventTime` 순서를 확인하여 오래된 쓰기를 거부하며, 원자적 병합을 수행한다. 변경된 피처만 온라인 스토어에 기록되며, 동시에 전체 레코드 스냅샷이 오프라인 스토어에 자동으로 복제되어 훈련 데이터셋의 정확성을 유지한다.

API 요청 형식은 `POST /FeatureGroup/{FeatureGroupName}/Record`이며, 본문에는 `RecordIdentifierValueAsString` (업데이트할 레코드의 기본 키), `Features` (설정할 하나 이상의 피처 값 목록, 호출당 최대 100개), 그리고 선택적으로 `TtlDuration` (레코드별 TTL 설정 또는 재정의)을 포함한다. `TtlDuration`을 제공하는 경우 `EventTime`도 함께 제공해야 한다. `EventTime`을 업데이트하려면 `Features` 파라미터 목록에 새 값을 제공해야 한다. 이 `EventTime`은 레코드에 저장된 기존 `EventTime`보다 최신(더 늦은 타임스탬프)이어야 하며, 그렇지 않으면 HTTP 409 오류와 함께 업데이트 요청이 거부된다. `EventTime`이 생략되면 기존 레코드의 `EventTime`은 변경되지 않고 새 피처 변경 사항만 적용된다. 이는 서로 다른 파이프라인이 고유한 피처를 소유하고 단일 이벤트 클록을 공유하지 않는 다중 파이프라인 아키텍처에 적합하다.

Standard Tier의 경우, 피처 수준 쓰기를 사용하려면 새로운 `Standard_V2` 스토리지 형식이 필요하다. 이 형식은 피처 수준 쓰기와 같은 추가 기능을 지원하는 다른 직렬화 형식이다. 피처 그룹 생성 시 `OnlineStoreConfig`에 `"StorageType": "Standard_V2"`를 지정하여 옵트인할 수 있다. In-Memory Tier를 사용하는 경우 별도의 스토리지 유형이 필요 없으며, 모든 기존 In-Memory 피처 그룹에서 피처 수준 쓰기가 즉시 작동한다.

기존 Standard 스토리지 유형의 피처 그룹을 `Standard_V2`로 마이그레이션하는 두 가지 전략이 있다. 첫 번째는 Feature Processor SDK를 사용하여 기존 Standard 피처 그룹에서 레코드를 읽어 새 `Standard_V2` 피처 그룹으로 다시 수집하는 '대량 마이그레이션'이다. 이 방식은 마이그레이션 타이밍을 제어하고, 원본 피처 그룹을 유지하며, 롤백이 용이하다는 장점이 있다. 그러나 관리형 마이그레이션 작업이 필요하고, 전체 데이터셋에 대한 읽기 및 쓰기 비용을 선불로 지불해야 하며, 애플리케이션 클라이언트를 새 피처 그룹 이름으로 업데이트해야 하는 단점이 있다.

두 번째 전략은 `UpdateFeatureGroup` API를 호출하여 `OnlineStoreConfig.StorageType`을 `"Standard_V2"`로 설정하여 피처 그룹의 스토리지 형식을 인플레이스(in-place)로 변경하는 '인플레이스 전환'이다. 이 방식은 제로 다운타임을 제공하고, 실제로 변경되는 레코드에 대해서만 마이그레이션 비용이 발생하며, 피처 그룹 이름과 API 엔드포인트가 변경되지 않아 기존 애플리케이션 코드를 보존할 수 있다. 그러나 `Standard_V2`로의 전환은 되돌릴 수 없으며, 한 번도 쓰여지지 않은 오래된 레코드는 변경될 때까지 레거시 형식으로 남아있게 된다. 대부분의 고객에게는 제로 다운타임과 사용량 기반 비용 효율성 때문에 인플레이스 전환 전략이 권장된다. 완전히 되돌릴 수 있는 마이그레이션 경로가 필요하거나 피처 그룹의 이름을 변경하거나 재구성해야 하는 경우에만 대량 마이그레이션 전략을 사용한다.

`UpdateRecord` API는 개발자와 사용자에게 여러 가지 긍정적인 영향을 미친다. 불필요한 전체 레코드 읽기 및 쓰기 작업을 제거하여 업데이트당 지연 시간을 줄이고, `GetRecord` 호출에 필요한 읽기 용량 단위(RCU) 비용을 절감한다. Standard Tier의 경우, DynamoDB 쓰기 용량 단위(WCU) 요금은 업데이트 후 항목 크기를 기준으로 하지만, 기존 읽기-수정-쓰기 패턴에 필요했던 읽기 용량 비용을 절약할 수 있다. 또한, 여러 파이프라인이 동일한 레코드의 다른 피처를 동시에 업데이트할 때 발생할 수 있는 손실된 업데이트 위험을 최소화하여 데이터 일관성 및 신뢰성을 증대시킨다.

이 API는 스트리밍 피처 하이드레이션, 새로운 피처 백필, 대규모 오류 수정, 고속 피처 업데이트, 엔터프라이즈 엔티티를 위한 다중 생산자 피처 그룹과 같은 다양한 피처 엔지니어링 워크플로우를 간소화한다. 예를 들어, 실시간 클릭스트림 데이터와 야간 배치 데이터와 같이 다른 빈도로 발생하는 여러 스트림의 데이터를 효율적으로 통합할 수 있으며, 각 파이프라인은 조정이나 데이터 손실 위험 없이 자신이 소유한 피처만 핵심 레코드에 제출한다. 또한, 기존 피처 그룹에 새로운 피처를 추가할 때 모든 레코드를 다시 작성하는 대신 새 필드 값만 업데이트할 수 있다.

세분화된 접근 제어도 가능하다. `UpdateRecord`는 IAM과 통합되어 누가 어떤 피처를 업데이트할 수 있는지 정확하게 제어할 수 있다. `sagemaker:IsUpdateRecord` (부분 업데이트 작업과 전체 `PutRecord` 쓰기를 구분) 및 `sagemaker:UpdatableFeatures` (주체가 업데이트할 수 있는 피처 이름 제한) 두 가지 새로운 IAM 조건 키를 사용할 수 있다. 예를 들어, 특정 비민감성 피처(`age`, `score`, `last_activity`)에 대한 `UpdateRecord` 호출만 허용하고 다른 피처에 대한 업데이트나 직접적인 `PutRecord` 호출을 차단하는 정책을 설정할 수 있다. 기존 `sagemaker:PutRecord`를 거부하는 IAM 정책은 `UpdateRecord`도 자동으로 차단하므로 보안 제어를 위해 고객 마이그레이션이 필요하지 않다.

`UpdateRecord` API 사용에는 몇 가지 조건과 제약 사항이 있다. `UpdateRecord`는 엄격하게 수정 작업이므로, 레코드가 이미 존재해야 하며, 새 레코드를 생성하려면 먼저 `PutRecord`를 호출해야 한다. 업데이트하려는 피처 이름은 피처 그룹의 스키마에 정의되어 있어야 하며, 스키마에 없는 피처를 추가할 수는 없다. 레코드 식별자(기본 키)는 `UpdateRecord`를 사용하여 수정할 수 없으며, `TtlDuration`을 지정하는 경우 요청에 `EventTime`도 반드시 포함해야 한다. Standard Tier에서 피처 수준 쓰기를 사용하려면 피처 그룹 생성 시 `Standard_V2` 스토리지 형식을 선택해야 한다. `UpdateRecord`를 통해 이루어진 업데이트는 `PutRecord`와 동일한 복제 파이프라인을 통해 오프라인 스토어로 자동으로 전달되며, 각 업데이트는 오프라인 스토어에 완전한 레코드 스냅샷을 내보낸다.

`UpdateRecord`는 Amazon SageMaker Feature Store가 제공되는 모든 AWS 리전에서 즉시 사용할 수 있다. 시작하려면 `StorageType: Standard_V2`로 피처 그룹을 생성하거나 기존 In-Memory 피처 그룹을 사용하고, `PutRecord`로 레코드를 수집한 다음, `UpdateRecord`를 호출하여 개별 피처를 업데이트하면 된다.

데빈은 실제 기자가 아닌 AI 기술 에디터입니다. 출처의 공개 기사 본문 또는 RSS 제공 정보에서 사실을 추려 배경과 기술적 영향을 독립적인 한국어 기사로 재구성합니다. 직접 취재한 기사나 원문 전문의 번역·재게시가 아닙니다.

출처 · 원문 확인

AWS Machine Learning Blog · Mona Mona

Amazon SageMaker Feature Store introduces UpdateRecord for feature-level writes

원문 발행: 2026-09-09 03:29:15

원문과 이미지의 권리는 해당 권리자에게 있습니다. 정정·게재 중단 요청은 문의 안내를 이용해 주세요.

댓글 0

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

댓글을 남기려면 로그인이 필요합니다.

← 전체 소식 개발 도구 둘러보기