합성 데이터: 익명성을 주장하지 않고 테스트 예시 만들기
합성 데이터는 실제 관측 결과를 수집한 데이터가 아니라, 예시를 표현하도록 만든 데이터입니다. 직접 작성하거나 규칙으로 생성하거나 모델로 만들 수 있습니다. 테스트에서의 가치는 명시적인 사례 범위와 알려진 기대 결과에서 나옵니다. 합성이라는 사실만으로 익명성이나 통계적 현실성이 입증되지는 않습니다.
완전히 지어낸 테스트 데이터로 개인 레코드를 복사하지 않고도 누락 필드와 충돌하는 값을 검사할 수 있습니다. 실제 레코드에 기반해 생성한 데이터셋에서는 생성 과정에 어떤 정보를 사용했는지라는 별도의 문제가 생깁니다. 생성된 모든 행을 서로 바꿔 써도 되는 것처럼 취급하지 말고 출처와 사용 목적을 명확히 하세요.
합성 데이터는 어떻게 만들어지나요?
검사할 동작부터 정한 다음, 그 동작이 드러나도록 값을 만드세요. 정상 예시는 예상 경로를, 빈 값이나 잘못된 유형의 값은 거부 동작을 검사할 수 있습니다. 각 행에는 존재하는 이유와 해당 테스트의 규약에 따른 기대 처리 결과가 명시되어야 합니다.
규칙 기반 생성은 필드를 체계적으로 바꿀 수 있습니다. 모델 기반 생성은 다양한 표현을 제안할 수 있지만, 라벨과 가정은 여전히 검토해야 합니다. 어느 방법도 신뢰할 수 있는 정답표를 자동으로 제공하지는 않습니다. 생성기가 테스트 대상 시스템과 같은 오해를 재현할 수 있습니다.
이 페이지는 현실적인 모집단이 아니라 경계 조건 검사가 목적이므로 직접 작성한 소규모 테스트 데이터를 사용합니다. 값은 의도적으로 단순하고 해석하기 쉽게 만들었습니다. 추가 동작이나 기존 규칙 간 의미 있는 상호작용을 드러내지 않는다면 행을 늘려도 얻는 것이 적습니다.
완전히 지어낸 6행 문의 테스트 데이터
아래의 모든 필드와 값은 합성입니다. 개인 레코드, 연락처, 실제 문의는 사용하지 않았습니다. 이 테스트 데이터의 가상 규약에는 비어 있지 않은 문자열 enquiry_ref, 비어 있지 않은 문자열 message, information 또는 change 중 하나인 requested_route가 필요합니다. 메시지 앞뒤 공백은 빈 값 검사에서만 제거합니다.
규약은 선택 필드인 declared_route도 허용합니다. 이 필드가 있으면 허용된 경로여야 하고 requested_route와 같아야 합니다. 일치하지 않으면 검토가 필요합니다. 필수 필드 또는 유형 오류는 경로 충돌보다 우선합니다. 이는 작성자가 정한 테스트 규칙이며, AI Flowi 엔드포인트를 설명하는 내용이 아닙니다.
{
"fixture_id": "enquiry-boundaries-v1",
"origin": "wholly invented",
"all_values_synthetic": true,
"personal_records_used": false,
"purpose": "input-boundary checks",
"population_claim": "none",
"observed_run": false
}[
{"enquiry_ref":"E01","message":"Which collection days are available?","requested_route":"information","declared_route":"information"},
{"enquiry_ref":"E02","message":"Move collection to Thursday.","requested_route":"change","declared_route":"change"},
{"enquiry_ref":"E03","message":" ","requested_route":"information"},
{"enquiry_ref":"E04","message":"Explain the collection window.","requested_route":"information","declared_route":"change"},
{"enquiry_ref":"E05","message":17,"requested_route":"information"},
{"enquiry_ref":"E06","requested_route":"change"}
]| 사례 | 검사 목적 | 기대 처리 결과 | 규칙 근거 |
|---|---|---|---|
| E01 | 정상적인 정보 문의입니다. | accept(수락) | 비어 있지 않은 텍스트이며, 허용된 경로가 일치합니다. |
| E02 | 정상적인 세부 사항 변경 문의입니다. | accept(수락) | 비어 있지 않은 텍스트이며, change 경로가 일치합니다. |
| E03 | 명시된 공백 검사 후 빈 값이 됩니다. | reject_empty(빈 값 거부) | 메시지에 공백만 있습니다. |
| E04 | 구조화된 경로가 충돌합니다. | review_conflict(충돌 검토) | information과 change가 서로 다릅니다. |
| E05 | JSON 자체는 유효하지만 필드 유형이 잘못되었습니다. | reject_type(유형 거부) | 메시지가 문자열이 아니라 숫자입니다. |
| E06 | 필수 필드가 없습니다. | reject_missing(누락 거부) | message 멤버가 없습니다. |
E05는 JSON 자체는 유효하지만 한 필드가 애플리케이션 규약을 위반합니다. JSON 구문 오류 사례가 아닙니다. E06은 E03과 다릅니다. 멤버를 생략한 경우와 빈 값을 명시적으로 제공한 경우는 서로 다른 검사를 수행합니다. 이 차이를 보존하면 어느 경계에서 실패했는지 식별하는 데 도움이 됩니다.
이 테스트 데이터는 의도적으로 여섯 사례만 다룹니다. 지원되지 않는 경로, 빈 참조 값, 반복 전달, 모든 오류 조합을 테스트하지는 않습니다. 실제 규약에 관련 규칙이 추가되면 사례를 추가하세요. 짧은 목록만으로 모든 경우를 다룬다고 주장하지 마세요.
합성 데이터에서 사례 범위와 대표성은 어떻게 다른가요?
사례 범위는 테스트 데이터가 특정 조건을 검사하는지를 묻습니다. 대표성은 데이터가 특정 추론을 할 수 있을 만큼 대상 모집단이나 프로세스를 잘 설명하는지를 묻습니다. 잘못된 행을 여러 개 의도적으로 포함하면 경계 테스트에는 유용하지만, 운영 환경에서 잘못된 문의가 얼마나 자주 발생하는지는 알려 주지 않습니다.
작성된 모든 사례를 통과하더라도 해당 예시에서의 동작만 보여 줍니다. 전반적인 모델 품질, 실제 고객 만족도, 동시 트래픽에서의 성능은 입증되지 않습니다. 엔드포인트 관찰과 부작용 검사는 API 테스트 가이드에서 다룹니다. 이 테스트 데이터는 서비스를 실행하기 전에 후보 입력을 제공합니다.
작성된 기대 결과와 관찰된 결과를 분리하세요. 후속 시험에서 E04가 수락되면 실행이 성공한 것처럼 보이도록 기대 결과를 고치지 말고, 원래 기대 결과와의 충돌을 기록하세요. 업무 규칙이 바뀌면 새 규약과 테스트 데이터 리비전이 필요합니다.
합성은 익명화를 뜻하지 않습니다
익명화는 해당 상황에서 정보를 사람과 연결할 수 있는지에 관한 문제입니다. 합성 데이터 생성은 데이터를 어떻게 만들었는지에 관한 문제입니다. 실제 예시를 사용하는 생성기는 식별에 도움이 되는 고유한 세부 정보를 남길 수 있습니다. 복사한 레코드의 이름만 바꿨다고 완전히 지어낸 데이터가 되는 것은 아닙니다.
이 테스트 데이터의 출처에 관한 설명은 제한된 사실만을 밝힙니다. 값을 작성하는 데 개인 소스 레코드를 사용하지 않았다는 뜻입니다. 합성이라고 불리는 다른 모든 데이터셋을 보증하는 선언은 아닙니다. 어떤 주장이 정당한지 판단하기 전에 소스 자료, 생성 방법, 공개 목적을 살펴보세요.
모델 생성을 도입하면 생성된 텍스트에 의도하지 않은 복사 내용이나 식별 가능한 세부 정보가 있는지 검토하고, 소스 사용 권한을 문서로 남기세요. 이 검토를 개인정보 보호 보장이라고 부르지 마세요. 테스트에는 유용한 데이터셋도 더 넓은 공개나 모집단 분석에는 부적합할 수 있습니다.
AI Flowi Workflow의 데이터 인터페이스
생성 규약과 정적 내보내기 제한은 Create Data 참조 문서에서 다룹니다. 이 컴포넌트는 카탈로그에 문서화되어 있지만, Ai Flowi가 운영 환경에서 테스트하지 않았습니다.
6행 테스트 데이터는 교육용 데이터이며, 가져올 수 있는 컴포넌트 구성이 아닙니다. 확장하려면 먼저 다루지 않은 규칙을 명시하세요. 빈 문의 참조 값은 E03과는 다른 빈 필드 경계를 검사합니다. 지원되지 않는 요청 경로는 허용 목록 검증을 검사하고, 지원되지 않는 선언 경로는 경로 비교 전에 선택 필드의 유효성을 검사합니다. 생성 과정이 평범한 문의만 많이 만들고 이런 경계를 놓치지 않도록 각 새 행의 목적을 명시하세요.
잘못된 값도 의도적으로 보존하세요. E05의 숫자 메시지를 텍스트로 바꾸면 유형 오류 사례가 사라집니다. E06에 누락된 메시지를 채우면 생략 사례가 사라집니다. 따라서 모든 행을 그럴듯하게 만들도록 지시받은 생성기는 테스트 데이터를 오히려 덜 유용하게 만들 수 있습니다. 카탈로그는 인터페이스를 다루며, 테스트 데이터의 사례 범위를 다루지는 않습니다. 직접 작성할 때는 모델 계정이 필요하지 않습니다. 선택적으로 제공업체의 생성 기능을 사용하려면 사용 권한이 있는 본인의 자격 증명이 필요하며, 제공업체에 별도로 비용을 지불해야 합니다.
흔한 실수와 관련 용어
민감한 소스 행을 복사한 뒤 지어낸 테스트 데이터라고 표시하거나, 평범한 입력만 테스트하거나, 생성된 라벨을 검증된 결과로 취급하지 마세요. 값 또는 수락 규칙이 바뀌면 테스트 데이터의 버전을 갱신하고, 비교를 위해 이전 기대 처리 결과를 유지하세요.
데이터 정제는 제공된 레코드의 결함을 다룹니다. ETL 테스트는 변환과 계보를 검사하고, 데이터 라벨링은 기준 라벨 검토를 설명합니다. 가상의 테스트 예시는 이런 검사를 지원하지만 실제 결과를 입증하지는 않습니다.
작성: Ai Flowi · 게시일