Feature Store와 민감정보 처리

둘째 섹션의 나머지 절반은 「만든 데이터를 여럿이 안전하게 나눠 쓰는 일」입니다. 앞 노트가 전처리 도구를 골랐다면 여기서는 그 결과물인 피처를 어디에 두고 어떻게 내주는지, 그리고 그 안에 개인정보가 섞여 있을 때 무엇을 하는지를 봅니다. 시험은 이 둘을 자주 한 문항에 섞습니다 — 「피처를 공유하되 주민 식별 정보는 모델에 들어가면 안 된다」는 식입니다.

피처 생성과 통합

피처

피처는 모델이 입력으로 받는 값 하나입니다. 「최근 30일 구매 횟수」·「평균 장바구니 금액」처럼 원본 컬럼을 가공해 만들고, 만드는 순간 그 정의가 생깁니다 — 30일을 며칠로 세는지, 취소된 주문을 빼는지.

팀마다 그 정의를 각자 SQL로 다시 쓰면 값이 조금씩 어긋나고, 어긋난 값으로 학습한 모델은 서빙에서 다른 값을 받습니다. Feature Store는 그 정의를 한 벌만 두고 여러 모델과 여러 팀이 같은 값을 읽게 하는 저장소입니다.

피처 그룹

지금의 Feature Store는 BigQuery를 원천으로 씁니다. 피처를 계산해 BigQuery 테이블이나 뷰로 만들어 두고, 그 위에 피처 그룹을 얹어 어떤 컬럼이 피처인지 등록합니다. 데이터를 다른 저장소로 복사해 옮기는 것이 아니라 이미 있는 테이블에 이름표를 붙이는 것에 가깝습니다.

원천 테이블에 반드시 있어야 하는 컬럼이 둘입니다 — 값의 주인을 가리키는 엔티티 ID와, 그 값이 유효해진 시각을 적은 피처 타임스탬프입니다. 뒤엣것이 다음 절과 그다음 절을 모두 떠받칩니다.

피처 뷰

피처 뷰는 여러 피처 그룹에서 실제로 서빙할 피처를 골라 묶은 것이고, 온라인 스토어에 동기화 일정을 걸어 둡니다. 일정이 돌면 BigQuery의 최신 값이 온라인 쪽으로 복사됩니다. 그래서 온라인 값은 마지막 동기화 시점의 값이고, 동기화 주기가 곧 온라인 피처의 신선도입니다. 「추천에 쓰는 피처가 몇 시간 전 값이라 문제」라는 시나리오의 손잡이가 여기입니다.

온라인 서빙과 오프라인 저장

오프라인 저장

학습은 과거 전체를 한꺼번에 읽습니다. 수백만 행에 대해 각각의 시점 피처가 필요하고, 응답 속도는 중요하지 않습니다. 이 읽기는 BigQuery에서 그대로 일어납니다.

온라인 서빙

추론은 반대입니다. 사용자 한 명의 최신 피처를 밀리초 안에 읽어야 하고, 그것도 초당 수천 번입니다. 그래서 같은 값을 온라인 스토어에 따로 두고 키로 조회합니다.

온라인 스토어는 성격이 다른 둘 중에서 고릅니다 — 아주 큰 엔티티 수를 싸게 감당하는 쪽과, 지연 시간을 최소로 깎는 쪽입니다. 「엔티티가 수억 개」와 「응답이 한 자릿수 밀리초여야 한다」 중 어느 말이 조건으로 적혀 있는지가 고르는 근거입니다.

학습-서빙 스큐

두 경로가 같은 정의에서 갈라져 나온다는 것이 이 제품의 존재 이유입니다. 학습용 피처는 SQL로 만들고 서빙용 피처는 애플리케이션 코드가 따로 계산하면, 그 둘이 어긋난 만큼이 학습-서빙 스큐가 됩니다.

시점 정합 조회

라벨 시각

학습 행에는 라벨이 붙고, 그 라벨에는 언제 일어난 일인가가 함께 있습니다. 2월 1일에 이탈한 고객의 행에 붙어야 하는 피처는 2월 1일 시점의 값입니다. 지금 값을 붙이면 이탈 이후에 만들어진 정보가 입력에 섞여 들어가고, 이것이 데이터 누수입니다. 평가 점수만 좋고 운영에서 무너지는 전형적인 자리입니다.

조인

BigQuery에서는 라벨 시각 이하의 피처 중 가장 최근 것을 고르는 조인으로 풉니다.

SELECT
  l.user_id, l.label_ts, l.churned,
  f.orders_30d, f.avg_basket
FROM `shop.labels` AS l
LEFT JOIN `shop.user_features` AS f
  ON f.user_id = l.user_id
 AND f.feature_timestamp <= l.label_ts
QUALIFY ROW_NUMBER() OVER (
  PARTITION BY l.user_id, l.label_ts
  ORDER BY f.feature_timestamp DESC
) = 1;

f.feature_timestamp <= l.label_ts가 미래를 잘라 내고, QUALIFY로 남은 것 중 가장 최근 한 행만 남깁니다. 이 조건을 빼고 user_id로만 조인하면 한 사용자의 모든 시점 피처가 곱해져 행 수부터 틀어집니다.

민감정보 식별

Sensitive Data Protection

Sensitive Data Protection은 데이터 안에서 개인정보를 찾아내고 지우거나 바꾸는 서비스입니다. 하는 일이 둘로 나뉩니다 — 검사(어디에 무엇이 있는지 찾기)와 비식별(찾은 것을 바꾸기).

infoType

찾을 대상은 infoType이라는 이름의 탐지기로 지정합니다. EMAIL_ADDRESS·PHONE_NUMBER·CREDIT_CARD_NUMBER·PERSON_NAME처럼 미리 정의된 것이 많고, 직접 만든 사전이나 정규식도 쓸 수 있습니다. 탐지 결과에는 얼마나 확실한가가 등급으로 함께 붙으므로, 오탐이 많으면 낮은 등급을 걸러 내는 식으로 조입니다.

Cloud Storage 버킷이나 BigQuery 테이블에 검사 작업을 걸어 두면 어느 컬럼에 어떤 infoType이 몇 건 있는지가 나옵니다. 「우리 데이터 레이크에 개인정보가 어디 있는지 모르겠다」는 시나리오의 첫걸음이 이것입니다.

비식별 변환

변환의 갈래

바꾸는 방법이 여럿이고, 되돌릴 수 있는가와 형식이 유지되는가로 갈립니다.

from google.cloud import dlp_v2

dlp = dlp_v2.DlpServiceClient()
resp = dlp.deidentify_content(request={
    "parent": "projects/my-proj/locations/us-central1",
    "inspect_config": {"info_types": [{"name": "EMAIL_ADDRESS"}, {"name": "PHONE_NUMBER"}]},
    "deidentify_config": {"info_type_transformations": {"transformations": [{
        "primitive_transformation": {
            "character_mask_config": {"masking_character": "*", "number_to_mask": 0}
        }
    }]}},
    "item": {"value": "문의는 hong@example.com 또는 010-1234-5678"},
})
print(resp.item.value)

고르는 기준

고르는 기준은 그 값으로 이후에 무엇을 할 것인가입니다. 같은 사람을 같은 사람으로 묶어 집계해야 하면 해시나 결정적 암호화가 남고, 나중에 원래 값이 필요하면 되돌릴 수 있는 쪽이어야 하며, 시계열 간격이 분석에 중요하면 날짜를 지우는 대신 시프트합니다.

경계와 키

CMEK

저장된 데이터는 기본으로도 암호화되지만 키를 Google이 관리합니다. CMEK는 그 키를 Cloud KMS에 두고 고객이 쥐는 방식입니다. 키를 비활성화하면 데이터를 읽을 수 없게 되므로 접근을 키 하나로 끊을 수 있고, 키 교체 주기도 직접 정합니다. 다만 CMEK는 누가 접근할 수 있는지를 정하지 않습니다 — 그것은 IAM의 일입니다.

VPC Service Controls

VPC Service Controls는 프로젝트와 서비스 묶음 둘레에 경계를 쳐서 그 안의 데이터가 밖으로 나가지 못하게 합니다. 핵심은 정당한 자격 증명을 가진 사람도 경계 밖으로는 복사하지 못한다는 것입니다. 유출된 키로 데이터를 개인 버킷에 옮기는 시나리오를 IAM만으로는 막을 수 없고, 여기서 막습니다.

셋의 자리가 서로 다릅니다 — IAM은 누가 할 수 있는가, VPC Service Controls는 어디에서 어디로 나갈 수 있는가, CMEK는 그 데이터를 여는 열쇠를 누가 쥐는가입니다. 한 문항의 보기로 셋이 함께 나오면 조건 문장이 이 중 어느 질문을 하고 있는지 보면 됩니다.

연습 문제

1. 다음 조인에서 AND f.feature_timestamp <= l.label_ts를 빼면 생기는 일로 옳은 것은?

   LEFT JOIN `shop.user_features` AS f
     ON f.user_id = l.user_id
    AND f.feature_timestamp <= l.label_ts

   ① 결과 행 수가 줄어든다
   ② 라벨 시각 이후의 피처가 섞이고 한 라벨에 여러 시점 행이 붙는다
   ③ 온라인 서빙 지연이 늘어난다
   ④ 아무 차이가 없다

   ②. 미래 값이 입력에 들어가 데이터 누수가 되고, 시점 조건이 없으니 그 사용자의 모든 피처 행과 곱해져 행 수도 늘어납니다.
2. 추천 API가 반환하는 피처가 몇 시간 전 값이라는 지적을 받았습니다. 먼저 볼 것은?
   ① 피처 뷰의 동기화 일정
   ② 모델의 학습률
   ③ 엔드포인트 복제본 수
   ④ BigQuery 슬롯 예약

   ①. 온라인 값의 신선도는 동기화 주기가 정합니다. ③은 처리량 이야기라 값의 나이와 무관합니다.
3. 분석팀이 고객 ID를 가린 채로도 같은 고객의 행을 하나로 묶어 집계해야 합니다. 알맞은 변환은?
   ① 값을 전부 삭제한다
   ② 결정적 암호화나 해시로 같은 값이 늘 같은 결과가 되게 한다
   ③ 무작위 문자열로 매번 새로 바꾼다
   ④ 나이처럼 버킷으로 넓힌다

   ②. 같은 입력이 같은 출력이 되어야 묶을 수 있습니다. ③은 같은 고객이 매번 다른 값이 되어 집계가 깨집니다.
4. 정당한 IAM 권한을 가진 계정의 키가 유출돼 데이터가 외부 프로젝트로 복사되는 것을 막아야 합니다. 알맞은 것은?
   ① CMEK를 켠다
   ② VPC Service Controls 경계를 만든다
   ③ 감사 로그를 켠다
   ④ 균일한 버킷 수준 액세스를 켠다

   ②. 권한이 있는데도 경계 밖으로 못 나가게 하는 것이 이 제품의 정의입니다. ③은 일어난 뒤에 알려 줄 뿐 막지 않습니다.
5. Feature Store의 온라인 스토어와 오프라인 저장의 차이로 옳은 것은?
   ① 오프라인은 엔티티 한둘의 최신 값을 밀리초에 읽는다
   ② 온라인은 과거 전체를 한꺼번에 읽어 학습에 쓴다
   ③ 오프라인은 학습·배치에 쓰이고 온라인은 실시간 추론에 쓰인다
   ④ 둘은 서로 다른 피처 정의를 쓴다

   ③. ①과 ②는 설명이 서로 바뀌었고, ④는 같은 정의에서 갈라지는 것이 이 제품의 존재 이유라 반대입니다.
6. 데이터 레이크 어디에 개인정보가 있는지 모르는 상태입니다. 첫 단계로 알맞은 것은?
   ① 모든 컬럼을 마스킹한다
   ② infoType을 지정해 검사 작업을 돌려 위치와 건수를 파악한다
   ③ CMEK로 다시 암호화한다
   ④ 버킷을 비공개로 바꾼다

   ②. 비식별은 무엇이 어디 있는지 안 다음의 일입니다. ①은 분석 가치를 통째로 버립니다.
7. 진료 기록에서 날짜를 가리되 같은 환자의 방문 간격은 분석에 남겨야 합니다. 알맞은 변환은?
   ① 날짜를 삭제한다
   ② 날짜를 연도만 남긴다
   ③ 환자마다 같은 폭으로 미는 날짜 시프트
   ④ 날짜를 무작위 값으로 바꾼다

   ③. 같은 폭으로 밀면 절대 날짜는 가려지고 간격은 그대로 남습니다. ④는 간격이 무너집니다.
8. CMEK에 대한 설명으로 옳은 것은?
   ① CMEK를 켜야 비로소 저장 데이터가 암호화된다
   ② 키를 Cloud KMS에서 고객이 관리하고, 키를 비활성화하면 데이터를 읽을 수 없다
   ③ 누가 리소스에 접근할 수 있는지를 정한다
   ④ 데이터가 경계 밖으로 나가는 것을 막는다

   ②. ①은 기본 상태에서도 암호화되므로 틀리고, ③은 IAM, ④는 VPC Service Controls의 일입니다.