2026년의 합성 테스트 데이터: 시드 기반, 안전, 재현 가능

합성 데이터는 사람에게서 표본을 뽑는 것이 아니라 규칙에서 생성됩니다. 이름 목록에서 조립한 이름, 국가 픽스처에서 조립한 주소, 예약된 블록에서 가져온 전화번호, 예약된 도메인의 이메일: 모두 제조된 것이며 어느 것도 실제 주체를 가리키지 않습니다. 재현성이야말로 이를 무작위 노이즈와 구분하는 요소입니다. 시드 없는 출력은 검토하거나 diff하거나 재생할 수 없기 때문입니다.

익명화된 프로덕션 데이터는 합성 데이터가 아닙니다. 실제 행을 마스킹하면 동일한 분포가 남고 종종 동일한 재식별 위험도 남습니다. 도메인을 유지한 채 마스킹한 EMAIL 열은 여전히 고용주를 노출합니다. 테스트에 프로덕션 형태의 데이터가 필요하다면 그것은 집계와 접근 권한에 관한 별도의 논의이며, 생성기가 정직하게 제공할 수 있는 것이 아닙니다.

커밋된 픽스처 파일에는 한 가지 장점이 있습니다: 검사하기 쉽다는 것입니다. 그러나 여러 문제도 있습니다. 스키마가 바뀌어도 아무도 업데이트하지 않아 드리프트가 생깁니다. 저장소를 비대하게 만듭니다. 어느 버전이 최신인지 아무도 모를 때까지 프로젝트 간에 복사됩니다. 그리고 조용히 모든 사람이 테스트하는 유일한 데이터가 되어, 스위트는 누군가 2021년에 입력한 값만 정확히 커버하게 됩니다.

시드 기반 생성은 입력은 작게, 출력은 크게 유지합니다. 시드와 생성기 버전이 곧 픽스처입니다. 필요할 때 다시 생성하고, 검토를 위해 첫 번째와 마지막 레코드만 스냅샷하며, 생성기 출력의 모든 변경은 재기준화가 필요한 의도적 변경으로 취급하십시오. 한 가지 요구 사항은 생성기가 고정되어야 한다는 것입니다. 알고리즘이 바뀐 업그레이드된 생성기는 같은 시드에서도 새로운 데이터 세트이기 때문입니다.

여러 표준이 문서화와 테스트를 위해 값을 예약해 두었습니다. 이를 사용하는 것은 스타일 선호가 아니라, 무해함이 보장된 픽스처와 누군가의 것일 수도 있는 픽스처 사이의 차이입니다. 예약된 블록은 안정적이고 널리 문서화되어 있으며 대부분의 검증기에서 구문상 정상으로 받아들여집니다.

이메일에는 등록할 수 없는 예약 도메인인 example.test처럼 .test 아래의 도메인을 사용하십시오. 북미 번호 계획의 전화번호에는 555-0100부터 555-0199 블록이 허구 사용을 위해 예약되어 있습니다. IP 주소에는 IPv4의 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24와 IPv6의 2001:db8::/32가 문서화 범위입니다. MAC 주소에는 00-00-5E-00-53-00부터 00-00-5E-00-53-FF가 문서화 범위이며, U/L 비트가 설정된 로컬 관리 주소도 픽스처에 안전합니다.

대부분의 시스템에는 하나 이상의 엔터티가 필요합니다. 주문에는 고객, 배송 주소, 청구 주소가 있으며, 이 셋은 스키마가 강제하는 방식으로 일치해야 합니다. 청구 주소가 미국에 있고 배송 주소가 일본에 있다면 세금 계산과 운송사 선택이 그 조합을 받아들여야 하며, 그렇지 않으면 테스트는 테스트 대상 동작과 무관한 이유로 실패합니다.

행이 아니라 관계를 생성하십시오. 자식 시드를 부모 시드에서 파생시켜 주문과 그 주소들이 하나의 단위로 재현되게 하십시오. 어떤 필드가 일치해야 하는지 의도적으로 결정하십시오: 배송과 청구 간 국가는 보통 동일하고, 우편번호는 픽스처의 도시와 일치해야 하며, 통화는 국가와 일치해야 합니다. 이러한 제약을 팩토리에 인코딩하여 깨진 픽스처가 세 계층 아래의 어서션에서가 아니라 생성 시점에 실패하게 하십시오.

이 사이트는 Social Security number, 결제 카드 번호, IMEI 또는 IMSI 값, Bluetooth 장치 주소, 일련번호를 생성하지 않습니다. 각 거부에는 이유가 있습니다. SSN은 미국에서 법적으로 제한된 식별자입니다. 카드 번호에는 Luhn 체크섬이 있어 그럴듯한 번호가 순진한 검증기를 통과한 뒤 지원 티켓에 붙여넣어질 수 있습니다. IMEI에는 검사 숫자와 할당 레지스트리가 있습니다. Bluetooth 주소는 MAC 형식을 공유하지만 벤더 의미가 없으며, 생성된 주소는 MAC 도구가 피하도록 설계된 바로 그 혼란을 초래합니다.

같은 논리가 체크섬이나 레지스트리가 있는 모든 식별자에 적용됩니다. 테스트에 정말로 하나가 필요하다면 생성기가 아니라 프로세서나 발급 기관이 공식적으로 공개한 테스트 값을 사용하십시오. 그러면 테스트 패턴을 아는 사람에게는 그 값이 분명히 가짜로 보이며, 스크린샷이 컴플라이언스 검토에 들어가는 일도 막을 수 있습니다.

테스트 시점에 100개 레코드를 생성하는 것은 저렴합니다. 1,000만 개를 생성하는 것은 그렇지 않으며, 테스트 설정 안에서 하면 런타임을 지배하게 됩니다. 대용량은 매니페스트에 시드를 기록한 채 격리된 저장소로 한 번 미리 계산하고, 생성기를 핫 패스에서 빼두십시오. 중간 볼륨은 행마다가 아니라 단일 배치로 생성하십시오. 행별 설정이 보통 실제 비용이기 때문입니다.

결정성에는 성능 차원도 있습니다. 병렬 워커는 단일 순차 생성기를 공유해서는 안 됩니다. 인터리빙이 어느 워커가 어느 레코드를 받는지 바꾸기 때문입니다. 각 워커에 실행 시드와 워커 인덱스에서 파생된 자체 시드를 주어 스케줄링과 무관하게 데이터 세트가 안정되게 하십시오. 그러면 전체 스위트를 다시 실행하지 않고도 워커 3의 실패를 재현할 수 있습니다.

좋은 합성 데이터의 위험은 실제처럼 보인다는 것입니다. 모든 생성 레코드에 표식을 붙이십시오: 픽스처 플래그, 전용 테넌트, example.test의 이메일, 555-01xx 범위의 전화번호. 해당 레코드가 메일을 보내거나 결제를 잡거나 분석에 들어가는 것을 차단하십시오. 프로덕션 CRM에 도달한 데모 고객은 영업 담당자가 알아차리기를 기다리는 지원 사건입니다.

또한 생성된 데이터를 컴플라이언스를 위해 보존되는 로그와 게시될 스크린샷 밖에 두십시오. 값이 누구도 묘사하지 않더라도 독자는 이미지에서 그것을 알 수 없으며, 나중에 설명하는 것이 지금 라벨을 붙이는 것보다 비쌉니다. 스크린샷에 현실적인 주소를 보여줘야 한다면 문서화 범위 값을 사용하고 눈에 보이는 "샘플 데이터" 캡션을 추가하십시오.

생성된 데이터 세트를 공유 환경에서 사용하기 전에 네 가지 질문에 답해야 합니다. 어디서 왔으며 다시 생성할 수 있는가? 모든 값이 예약된 범위 또는 로컬 관리 범위에 있는가? 스키마 제약과 참조 규칙을 만족하는가? 그리고 사람이 고객으로 오인할 수 없도록 라벨이 붙어 있는가?

어느 하나라도 아니요라면 데이터 세트는 준비되지 않은 것입니다. 이는 의도적으로 엄격한데, 잘못된 답의 비용이 비대칭이기 때문입니다: 다시 생성하는 데는 몇 분이 걸리지만, 매출 보고서에 들어간 합성 고객은 한 분기 동안 의사 결정을 왜곡할 수 있습니다. 체크리스트를 위키의 주석이 아니라 검토의 일부로 실행하십시오.