스트리머용 게임 키 유출·재판매 패턴 탐지 대시보드 구축 가이드
스트리머용 게임 키의 유출·재판매를 추적하는 대시보드 구축 가이드입니다. HMAC 키 지문과 활성화 이벤트를 결합해 위험 점수와 대응 흐름을 설계하고 Steam 퍼블리싱 운영에 적용하는 방법을 정리합니다.
핵심 요약
배포 키마다 batch_id, streamer_id, campaign_id를 연결하고 원본 키 대신 HMAC-SHA-256 지문을 저장하면 유출 경로를 추적할 수 있습니다. 활성화 속도, 지역 불일치, 반복 활성화, 동일 소스의 중복 패턴을 결합해 risk_score를 계산하되 점수는 유출 확정이 아니라 사람의 검토를 위한 신호로 사용해야 합니다.
스트리머용 게임 키 유출·재판매 패턴은 왜 발생하는가?
스트리머 캠페인에 제공한 게임 키는 방송 화면, 커뮤니티 게시물, 팀 채팅, 제휴 매니저의 스프레드시트 등 여러 경로를 거칩니다. 이 과정에서 키가 캡처되거나 제3자에게 전달되고 사용되지 않은 키가 재판매 목록에 올라갈 수 있습니다.
문제는 단순히 키가 다른 지역에서 활성화됐다는 사실만으로 유출을 단정하기 어렵다는 점입니다. 스트리머가 해외 시청자에게 키를 전달했을 수도 있고 사용자가 여행 중일 수도 있으며 VPN이나 플랫폼의 지역 정책 때문에 위치 정보가 다르게 기록될 수도 있습니다.
따라서 대시보드의 목표는 특정 사용자를 자동으로 처벌하는 것이 아니라 다음 세 가지를 빠르게 확인할 수 있도록 만드는 것입니다.
| 확인 항목 | 핵심 질문 | 활용 데이터 |
|---|---|---|
| 발급 경로 | 어떤 캠페인과 담당자가 키를 발급했는가? | campaign_id, batch_id, 발급 시각 |
| 사용 패턴 | 정상적인 시청자 배포와 다른 활성화 흐름인가? | 활성화 속도, 지역, 반복 시도 |
| 대응 근거 | 회수·재발급·파트너 문의가 필요한가? | 위험 점수, 검토 메모, 증거 수준 |
유출 추적은 키 자체에 식별 정보를 삽입하는 방식보다 키와 별도의 메타데이터를 연결하는 방식이 안전합니다. Steamworks 또는 기타 플랫폼에서 발급한 키는 변경하지 않고 내부 시스템에서 key_id와 캠페인 정보를 연결하는 사이드카 레코드를 관리합니다.
배포 키 추적 대시보드는 어떤 구조로 동작하는가?
전체 흐름은 발급 로그, 전달 로그, 활성화 이벤트, 검토 결과를 하나의 키 식별자로 연결하는 방식입니다.
flowchart LR
A[키 발급] --> B[추적 메타데이터 저장]
B --> C[스트리머 또는 캠페인 전달]
C --> D[활성화 이벤트 수집]
D --> E[패턴 점수 계산]
E --> F{임계값 초과?}
F -- 예 --> G[검토 큐와 알림]
F -- 아니오 --> H[정상 모니터링]키가 발급되는 순간 다음 메타데이터를 생성합니다.
key_id: 내부 UUIDkey_fingerprint: 원본 키를 노출하지 않는 HMAC 지문platform: Steam 등 플랫폼 식별자batch_id: 동일 목적과 조건으로 묶은 발급 배치campaign_id: 게임 출시, 리뷰 캠페인, 이벤트 등의 식별자recipient_type: 스트리머, 미디어, 파트너, 경품 등recipient_id_hash: 수신자 식별자를 비가역적으로 처리한 값issued_at: UTC 기준 발급 시각delivery_method: 포털, 이메일, 수동 전달 등
원본 키는 분석 데이터베이스나 대시보드에 저장하지 않는 것이 원칙입니다. 플랫폼의 보안 저장소나 접근 통제가 적용된 별도 보관 영역에 두고 분석 계층에는 key_fingerprint만 전달합니다.
어떤 데이터를 저장해야 하는가?
데이터 모델은 발급 정보와 활성화 정보를 분리하는 편이 좋습니다. 그래야 한 키에 여러 번의 활성화 시도나 오류 이벤트가 연결되어도 원본 발급 기록이 오염되지 않습니다.
발급 테이블과 활성화 이벤트 테이블
CREATE TABLE distribution_keys (
key_id UUID PRIMARY KEY,
platform TEXT NOT NULL,
key_fingerprint CHAR(64) NOT NULL UNIQUE,
batch_id TEXT NOT NULL,
campaign_id TEXT NOT NULL,
recipient_type TEXT NOT NULL,
recipient_id_hash CHAR(64),
delivery_method TEXT NOT NULL,
issued_at TIMESTAMPTZ NOT NULL,
status TEXT NOT NULL CHECK (status IN ('issued', 'activated', 'revoked', 'review'))
);
CREATE TABLE key_activation_events (
event_id BIGSERIAL PRIMARY KEY,
key_id UUID NOT NULL REFERENCES distribution_keys(key_id),
activated_at TIMESTAMPTZ NOT NULL,
region_code TEXT,
platform_user_hash CHAR(64),
source_context TEXT,
activation_result TEXT NOT NULL,
received_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_activation_key_time
ON key_activation_events (key_id, activated_at);region_code는 국가 또는 넓은 권역 정도로 제한하고 원본 IP 주소는 대시보드에 노출하지 않습니다. 네트워크 분석이 꼭 필요하다면 원본 IP 대신 짧은 보존 기간의 ip_hash나 ASN 수준의 집계값만 사용합니다.
활성화 이벤트는 플랫폼이 제공하는 공식 리포트, 합법적인 웹훅, 내부 발급 시스템의 결과 로그처럼 접근 권한이 있는 데이터만 사용해야 합니다. 비공개 엔드포인트를 추측하거나 플랫폼 정책을 우회하는 방식은 운영 데이터로 삼으면 안 됩니다.
게임 키 지문은 어떻게 안전하게 만들까?
일반 SHA-256 해시만 사용하면 키 형식이 제한적인 경우 대입 공격으로 원본 키를 추측할 가능성이 있습니다. 서버 측 비밀값을 사용하는 HMAC-SHA-256을 적용하면 같은 키라도 비밀값 없이는 동일한 지문을 재현하기 어렵습니다.
import { createHmac } from 'node:crypto';
export function keyFingerprint(rawKey: string, secret: string): string {
const normalized = rawKey.replace(/[\s-]/g, '').toUpperCase();
return createHmac('sha256', secret)
.update(normalized, 'utf8')
.digest('hex');
}운영 시에는 다음 원칙을 함께 적용합니다.
- 키 정규화 규칙을 고정합니다. 공백과 하이픈을 제거할지 여부가 발급·검증 시스템에서 같아야 합니다.
- HMAC 비밀값은 환경 변수나 비밀 관리 시스템에 보관합니다.
- 비밀값을 교체할 때는
fingerprint_version을 추가해 이전 지문과 새 지문을 구분합니다. - 로그, 오류 메시지, 분석 이벤트에 원본 키가 들어가지 않도록 마스킹 규칙을 적용합니다.
- 대시보드 사용자는 키를 조회하는 대신
key_id와 발급 메타데이터만 확인하게 합니다.
유출·재판매 위험 점수는 어떻게 계산할까?
위험 점수는 여러 약한 신호를 결합하는 방식으로 설계합니다. 아래 가중치는 출발점일 뿐이며 실제 캠페인의 정상 패턴을 관찰한 뒤 조정해야 합니다.
각 특성은 0에서 1 사이로 정규화합니다.
| 특성 | 계산 예시 | 해석 |
|---|---|---|
velocity | 1시간 내 활성화 수를 기준 임계값과 비교 | 짧은 시간에 대량 사용되는 패턴 |
geo_mismatch | 발급 대상 권역과 활성화 권역의 차이 | 지역 정책과 맞지 않을 가능성 |
repeat_activation | 동일 키의 성공·실패 활성화 시도 횟수 | 공유 또는 자동화 가능성 |
source_overlap | 동일 배치에서 같은 유입 출처가 반복되는 비율 | 특정 게시물이나 판매 채널과의 연관성 |
예를 들어 velocity는 다음과 같이 상한을 둘 수 있습니다.
대시보드에서는 점수만 보여주지 말고 점수를 만든 근거도 함께 표시해야 합니다.
- 0.00~0.49: 정상 모니터링
- 0.50~0.74: 운영자 검토
- 0.75~1.00: 우선 검토 및 배포 중지 후보
0.75 이상이라고 해서 유출이 확정되는 것은 아닙니다. 이동 중인 사용자, VPN, 가족·친구 간 정상 공유, 플랫폼의 지연된 지역 판정처럼 오탐을 만들 수 있는 요인을 검토 메모에 남겨야 합니다.
추적 대시보드는 어떻게 구현할까?
1단계: 추적 단위를 먼저 정의한다
가장 세밀한 단위는 개별 키입니다. 그러나 항상 개인 단위 추적이 필요한 것은 아닙니다.
- 공개 경품 이벤트:
campaign_id와batch_id중심 - 소수의 전문 스트리머:
recipient_id_hash까지 연결 - 대규모 제휴 배포: 파트너와 발급 배치 중심
- 리뷰어 배포: 수신자와 전달 시각을 함께 기록
필요 이상의 개인 식별 정보를 저장하면 개인정보와 계약상 위험이 커집니다. 캠페인 목적에 필요한 최소 수준부터 시작합니다.
2단계: 이벤트 계약을 고정한다
활성화 이벤트의 필드 이름과 시간 기준을 먼저 정해야 합니다. 모든 시간은 UTC로 저장하고 화면에서만 운영자의 시간대로 변환합니다.
type KeyActivationEvent = {
keyId: string;
activatedAt: string;
regionCode?: string;
platformUserHash?: string;
sourceContext?: string;
activationResult: 'success' | 'failed' | 'revoked';
};이벤트가 늦게 도착하거나 중복 수집될 수 있으므로 event_id 또는 플랫폼 이벤트 식별자를 기준으로 멱등성을 보장합니다. 동일 이벤트를 두 번 계산하지 않도록 UNIQUE 제약이나 스트리밍 집계의 중복 제거 단계를 둡니다.
3단계: 특징량과 점수를 집계한다
PostgreSQL을 사용한다면 시간 창별 집계는 materialized view 또는 배치 작업으로 시작할 수 있습니다. 데이터 규모가 커지면 Kafka와 스트리밍 처리 시스템을 추가하되 초기에는 하루 단위의 재계산으로도 많은 운영 문제를 확인할 수 있습니다.
점수 레코드에는 최종 점수뿐 아니라 계산 버전도 기록합니다.
CREATE TABLE key_risk_scores (
key_id UUID NOT NULL REFERENCES distribution_keys(key_id),
calculated_at TIMESTAMPTZ NOT NULL,
scoring_version TEXT NOT NULL,
velocity NUMERIC(5,4) NOT NULL,
geo_mismatch NUMERIC(5,4) NOT NULL,
repeat_activation NUMERIC(5,4) NOT NULL,
source_overlap NUMERIC(5,4) NOT NULL,
risk_score NUMERIC(5,4) NOT NULL,
review_status TEXT NOT NULL DEFAULT 'unreviewed',
PRIMARY KEY (key_id, scoring_version)
);점수 알고리즘이 바뀌었을 때 과거 판단을 재현하려면 scoring_version, 계산 시각, 각 특징량을 반드시 보존해야 합니다.
4단계: 대시보드를 운영자 업무에 맞춘다
대시보드는 다음 화면으로 나누면 실무에서 사용하기 쉽습니다.
| 화면 | 보여줄 지표 | 운영 목적 |
|---|---|---|
| 캠페인 개요 | 발급 수, 활성화율, 미사용 수, 검토 대상 수 | 캠페인 건강도 확인 |
| 배치 상세 | batch_id, 발급 대상, 활성화 시간 분포 | 특정 배치 비교 |
| 위험 검토 큐 | 위험 점수, 근거 특성, 최근 이벤트 | 우선순위가 높은 건 처리 |
| 수신자·파트너 보기 | 캠페인별 이상 비율, 검토 이력 | 반복 패턴 확인 |
| 감사 로그 | 상태 변경자, 변경 시각, 메모 | 계약·분쟁 대응 근거 보존 |
risk_score만 정렬하는 것보다 최근 활성화 이벤트, 동일 배치의 다른 키, 수신자별 정상 기준선을 함께 보여주는 편이 판단에 도움이 됩니다.
5단계: 알림과 조치를 분리한다
알림은 Slack, 이메일, 티켓 시스템 등으로 보낼 수 있지만 자동 회수는 별도 승인 단계로 두는 것이 안전합니다. 추천 운영 흐름은 다음과 같습니다.
- 임계값을 넘은 키를 검토 큐에 넣습니다.
- 운영자가 활성화 시간, 권역, 캠페인 조건, 전달 이력을 확인합니다.
false_positive,needs_partner_contact,confirmed_abuse같은 상태를 선택합니다.- 필요한 경우 해당 배치의 미사용 키를 일시 중지하거나 파트너에게 재확인을 요청합니다.
- 조치 결과와 담당자, 근거를 감사 로그에 기록합니다.
Steam 퍼블리싱과 스트리머 계약에 적용할 때의 주의점
Steam 키를 운영에 사용할 때는 Steamworks와 해당 플랫폼의 약관, 키 발급 조건, 지역 제한 정책을 확인해야 합니다. 특히 다음 항목은 기술 구현 전에 계약과 운영 문서에 명시하는 편이 좋습니다.
- 키는 지정된 캠페인과 수신자에게만 전달한다.
- 공개 게시, 제3자 양도, 재판매가 허용되는지 구분한다.
- 키가 노출됐을 때 신고와 대응에 필요한 정보를 공유한다.
- 캠페인 종료 후 보관할 로그와 삭제할 개인정보를 정의한다.
- 파트너가 보유한 배포 기록을 어느 범위까지 확인할 수 있는지 합의한다.
파트너마다 별도의 batch_id를 발급하면 문제가 발생했을 때 영향을 받은 범위를 좁힐 수 있습니다. 여러 스트리머에게 동일한 배치를 무작위로 섞어 배포하면 원인 분석이 어려워지므로 캠페인과 수신자 그룹별로 배치를 분리하는 것이 좋습니다.
또한 재판매 사이트의 게시물과 내부 키 기록이 일치하더라도 자동으로 공개 고발이나 계정 제재를 실행해서는 안 됩니다. 내부 검토, 플랫폼 신고 절차, 파트너 계약 조건을 순서대로 확인해야 합니다.
자주 묻는 질문 FAQ
개별 스트리머마다 전용 키 배치가 꼭 필요한가?
항상 필요한 것은 아닙니다. 대규모 경품 이벤트라면 캠페인 또는 파트너 단위 추적만으로 충분할 수 있습니다. 다만 유출 경로를 개인 수준에서 좁혀야 하는 캠페인이라면 스트리머별 배치가 가장 명확합니다.
다른 국가에서 활성화되면 유출로 판단해도 되는가?
아닙니다. 지역 불일치는 위험 신호 중 하나일 뿐입니다. 활성화 속도, 반복 시도, 전달 조건, VPN 가능성, 플랫폼 정책을 함께 확인해야 합니다.
Steam API가 없으면 대시보드를 만들 수 있는가?
가능합니다. 공식 활성화 리포트, 내부 발급 로그, 승인된 파트너 데이터로 시작할 수 있습니다. 다만 데이터가 제공하는 범위를 벗어난 자동 판정은 만들지 말고 수집 시각과 데이터 출처를 화면에 표시해야 합니다.
정리
스트리머용 게임 키 관리에서 중요한 것은 키를 감시하는 기술보다 발급과 전달의 맥락을 보존하는 데이터 구조입니다. key_id와 HMAC-SHA-256 지문으로 원본 키 노출을 줄이고 batch_id, campaign_id, 활성화 이벤트를 연결하면 유출·재판매 의심 패턴을 재현 가능한 방식으로 조사할 수 있습니다.
최종 판단은 자동 점수가 아니라 운영자의 검토와 계약 절차가 맡아야 합니다. 개인정보를 최소 수집하고 계산 버전과 감사 로그를 보존하며 파트너별 배포 단위를 분리하면 마케팅 효율을 유지하면서도 키 유출에 대응할 수 있는 퍼블리싱 운영 기반을 만들 수 있습니다.
