더미 데이터 생성기
브라우저에서 생성되며 어디에도 전송되지 않습니다. 이름은 가상이고 전화번호는 예약된 555-01xx 대역, IP 주소는 RFC 5737 문서용 블록을 사용합니다. 실제 사람이나 호스트의 정보는 포함되지 않습니다.
입력한 내용은 저장, 기록, 공유되지 않습니다.
필요한 필드를 정의하고 현실적인 더미 데이터를 최대 1,000행까지 JSON, CSV 또는 SQL INSERT 문으로 생성합니다. 모든 처리가 브라우저에서 이루어지므로 아무것도 업로드되지 않고 실제 개인정보도 사용하지 않습니다.
사용 방법
- 각 필드에 이름을 지정하고 값의 종류를 고릅니다.
- 필요한 행 수와 JSON, CSV, SQL 중 하나를 선택합니다.
- 생성을 누른 뒤 결과를 복사합니다.
예약된 범위가 중요한 이유
생성되는 모든 값은 가상 용도로 공식 지정된 범위에서 가져옵니다. 이는 사소한 집착이 아니라, 안전하게 실행할 수 있는 테스트와 그렇지 않은 테스트를 가르는 차이입니다.
전화번호는 북미 번호 계획(NANP)이 가상 용도로 예약한 100개 번호 블록인 +1-555-01xx를 사용합니다. 555의 나머지 번호는 수년 전에 실제 할당용으로 풀렸기 때문에, 아무 555 번호나 쓰던 옛 습관은 더 이상 안전하지 않습니다. 이메일 주소와 URL에는 RFC 2606이 예약하여 누구도 등록할 수 없도록 보장된 example.com, example.org, example.net을 씁니다. IP 주소는 라우팅되지 않는 RFC 5737 문서용 블록에서 가져옵니다.
이것이 막아 주는 사고는 잘 알려져 있고 지금도 계속 일어납니다. 그럴듯한 주소로 가득한 픽스처로 테스트를 돌려 실제 사람에게 진짜 메일을 보내거나, 부하 테스트가 실제 전화번호로 전화를 걸거나, 시드 데이터를 넣은 스테이징 데이터베이스가 운영 SMTP 릴레이에 연결되는 일입니다. 누구에게도 닿을 수 없는 픽스처는 절차가 아니라 구조로 이 문제를 해결합니다.
실제로 버그를 찾아내는 픽스처
하나같이 무난한 데이터는 다루기 편하지만 별로 쓸모가 없습니다. 이름은 모두 6~10글자, 문자열은 모두 ASCII, 선택 필드는 모두 채워져 있는 식이죠. 이런 데이터로 만든 테스트는 통과하지만 운영 환경에서 무슨 일이 일어날지는 아무것도 알려 주지 않습니다.
기본 데이터를 만든 뒤 직접 추가할 만한 경우는 다음과 같습니다. null이 허용되는 모든 열에 빈 문자열과 null 넣기(처리 경로가 다르기 때문입니다). 아포스트로피, 하이픈, 한글 같은 비라틴 문자가 들어간 이름(인코딩 버그와 허술한 이스케이프가 드러나는 곳입니다). 열 길이에 딱 맞는 값과 한 글자 넘치는 값. 월말, 연말, 2월 29일, 서머타임 전환일 같은 경계 날짜. 고유하다고 가정한 필드의 중복 값. 작은 레코드들 사이에 섞인 매우 큰 레코드 하나.
생성 데이터는 양과 형태를 빠르게 제공하며, 페이지네이션, 정렬, 인덱스 동작, 화면 렌더링에 필요한 것이 바로 그것입니다. 정확성을 검증하는 데 필요한 것은 까다로운 행들이며, 생성기가 우연히 만들어 주기를 기대하기보다 의도적으로 작성하는 편이 대개 낫습니다.
세 가지 출력 형식
데이터가 코드로 들어간다면 JSON을 쓰세요. API 픽스처, 목 서버, 시드 스크립트, 테스트가 시작할 때 읽는 파일 등입니다. 레코드는 지정한 필드 이름을 키로 하는 객체 배열로 출력됩니다.
CSV는 스프레드시트, 데이터베이스 COPY, 관리자 업로드 폼 같은 대량 가져오기 경로에 알맞으며, 불러오기 전에 표로 데이터를 눈으로 확인하고 싶을 때도 좋습니다. 받는 쪽에서는 CSV의 일반적인 주의 사항이 적용됩니다. 타입을 추측하는 프로그램은 숫자처럼 보이는 것을 제멋대로 해석합니다.
SQL은 지정한 테이블 이름에 대해 행마다 하나씩 일반 INSERT 문을 출력하므로, 드라이버나 스크립트 없이 어떤 클라이언트에서든 실행할 수 있습니다. 문자열 값은 따옴표를 두 번 써서 이스케이프하고, 숫자는 그대로, 불리언은 TRUE와 FALSE로 쓰며, 단순한 단어가 아닌 식별자는 큰따옴표로 감쌉니다. 시드 데이터가 많다면 출력을 트랜잭션으로 감싸는 것이 좋습니다. 트랜잭션 밖에서 개별 문 1,000개를 실행하면 대부분의 엔진에서 느리기 때문입니다.
운영 데이터를 익명화해서 대신 쓰지 말 것
현실적인 테스트 데이터가 필요할 때 운영 데이터베이스를 복사해 개인정보 필드를 지우는 지름길은 매력적입니다. 이 방법이 왜 계속 문제를 일으키는지 이해해 둘 가치가 있습니다.
이름과 이메일 주소를 지운다고 데이터가 비식별화되지는 않습니다. 우편번호, 생년월일, 성별 같은 평범한 속성의 조합이나 몇 개의 타임스탬프와 위치의 조합은 한 사람을 특정하는 경우가 많으며, 익명이라던 데이터를 재식별하는 연구는 방대하고 결론도 일관됩니다. 게다가 정리된 복사본은 접근 통제가 약하고 개발자 접근 범위가 넓으며 아무도 추적하지 않는 백업이 있는 환경에 놓인, 운영 데이터 그대로의 데이터셋입니다.
스키마에서 생성하면 이런 문제 전체를 피할 수 있습니다. 데이터는 올바른 형태를 갖추었지만 출처가 없으므로, 스테이징에서 유출되더라도 실제로는 아무것도 새지 않은 사건이 됩니다. 운영과 비슷한 분포가 정말 필요하다면, 레코드를 변환하기보다 통계를 모델링하고 그 모델에서 생성하는 것이 설득력 있는 방법입니다.
칸을 채우는 대신 데이터셋을 설계하기
현실적인 테스트 데이터는 무작위 데이터가 아니라 모양이 운영 환경과 같은 데이터입니다. 실제 테이블은 치우쳐 있습니다. 대부분의 고객은 주문이 한 건이고 소수만 수천 건을 갖고 있으며, 대부분의 문서는 짧고 하나만 거대하고, 대부분의 세션은 1분이지만 몇몇은 하루 종일 이어집니다. 모든 고객이 정확히 세 건씩 주문을 가진 픽스처에서는, 주문이 사천 건인 고객에게서 무너지는 쿼리가 결코 드러나지 않습니다.
분량이 중요한 이유도 같습니다. 페이지네이션, 정렬, 인덱스 동작은 50행에서는 보이지 않다가 5만 행에서는 분명해지고, 짧은 목록으로는 즉시 그려지던 페이지가 현실적인 데이터에서는 몇 초씩 걸릴 수 있습니다. 예상보다 한 자릿수 더 많은 데이터를 만들어 보는 것이 가장 값싼 부하 테스트입니다.
세 번째 조각은 참조 무결성입니다. 주문에는 실제로 존재하는 고객이, 댓글에는 게시글이 필요하고, 자식 레코드에는 날짜가 그럴듯한 부모가 필요합니다. 고객이 가입하기 전에 들어온 주문은 나중에 그 위에 세운 모든 리포트를 혼란스럽게 만드는 한 줄이 됩니다.
시드, 결정성, 그리고 반복 가능성
실행할 때마다 새 난수 데이터를 만들어 내는 테스트는 간헐적으로 실패하고, 간헐적 실패는 일관된 실패보다 나쁩니다. 아무도 재현할 수 없기 때문입니다. 흔한 규율은 고정된 시드를 쓰는 것입니다. 매번 같은 순서가 나오므로 실패를 되풀이해 볼 수 있고 bisect도 의미를 갖습니다.
이는 다양한 데이터를 원하는 마음과 충돌하는데, 많은 팀이 자리 잡는 절충안은 시드를 테스트 출력에 찍어 주는 시드 기반 생성기입니다. 필요할 때는 재현할 수 있고 시간이 흐르면서 다양해지며, 드문 조합이 무언가를 망가뜨렸을 때는 로그에 남은 시드가 그 상황을 그대로 복원해 줍니다.
시드 스크립트는 멱등해야 하기도 합니다. 시드를 두 번 돌려도 모든 테이블이 두 배가 되는 대신 데이터베이스가 같은 상태로 남아야 하며, 실무에서는 먼저 테이블을 비우거나 자연 키로 upsert한다는 뜻입니다. 다시 시드하려고 데이터베이스를 통째로 지워야 하는 개발자는 아예 다시 시드하지 않게 되고, 낡은 로컬 데이터는 그 자체로 하나의 버그 범주입니다.
픽스처, 팩토리, 스냅샷
세 가지 패턴이 주류이며 각각 다른 문제를 풉니다. 픽스처는 테스트 전에 불러오는 정적 파일로, 예측 가능하고 읽기 쉽지만 스키마가 바뀌면 모든 파일을 고쳐야 해서 관리가 성가십니다. 팩토리는 합리적인 기본값과 테스트별 덮어쓰기로 코드에서 객체를 만들어 내므로, 테스트는 자신이 신경 쓰는 필드만 적으면 됩니다. 요즘 테스트 스위트에서 가장 널리 쓰이는 방식입니다.
스냅샷은 함수의 출력을 붙잡아 두고 그것이 바뀌지 않았음을 단언합니다. 렌더링과 직렬화에는 훌륭하지만, 아무도 차이를 들여다보지 않을 때는 위험합니다. 버그를 그대로 굳혀 버린 갱신된 스냅샷은 큰 스위트에서 흔한 실패 유형입니다.
이 도구가 만들어 내는 종류의 생성 데이터는 그 셋 모두의 아래에 깔립니다. 성능과 페이지네이션을 현실적으로 만드는 수천 줄이라는 부피를 채워 주고, 유난히 까다로운 개별 레코드는 손으로 씁니다. 지난달에 운영을 무너뜨린 그 사례는 생성기가 재현해 주기를 바라기보다 명시적으로 적어 두는 편이 낫기 때문입니다.
운영 데이터를 복사하는 방식이 자꾸 어긋나는 이유
운영 덤프를 떠서 이름만 지우는 것은 현실적인 데이터에 이르는 가장 빠른 길처럼 느껴지지만, 절차가 아니라 구조 때문에 실패합니다. 직접 식별자를 없앤다고 데이터셋이 비식별화되지는 않습니다. 우편번호, 생년월일, 성별 같은 평범한 속성들의 조합은 한 사람에게만 해당하는 경우가 잦고, 익명이라던 데이터셋의 재식별에 관한 연구는 방대하고 결론도 한결같습니다.
운영상의 문제는 그것과 별개이면서 똑같이 심각합니다. 세척한 사본은 접근 통제가 더 약하고 개발자 접근 범위가 더 넓으며 아무도 추적하지 않는 백업이 쌓이는 환경에 놓인, 원본 그대로의 운영 데이터셋입니다. GDPR에서 가명 처리된 데이터는 여전히 개인정보이며 여전히 규제 대상입니다. 이는 법률 자문이 아니라 일반적인 관찰이며, 세부는 관할 지역과 여러분의 개인정보 보호 책임자에 따라 달라집니다.
스키마에서 생성하면 이 범주 전체를 피해 갈 수 있습니다. 데이터는 모양은 맞지만 출처가 전혀 없으므로, 스테이징에서 유출이 나도 아무것도 아닌 일에 대한 사고가 됩니다. 운영과 비슷한 분포가 정말로 필요하다면, 변명이 서는 방법은 실제 레코드를 변형하는 것이 아니라 통계를 모델링하고 그 모델에서 생성하는 것입니다.
만든 데이터를 필요한 곳으로 넣기
데이터베이스라면 SQL 출력이 드라이버 없이 어떤 클라이언트에서도 실행되고, 트랜잭션으로 감싸면 큰 시드가 극적으로 빨라집니다. 트랜잭션 밖에서 개별 구문 천 개를 실행하는 것은 거의 모든 엔진에서 느립니다. PostgreSQL이라면 행 수가 수천을 넘는 순간부터 CSV를 이용한 COPY가 INSERT 구문을 큰 차이로 앞섭니다.
애플리케이션이라면 보통 JSON이 알맞은 대상입니다. 테스트가 시작할 때 읽는 픽스처 파일, 목 서버의 응답, ORM이 소비하는 시드 스크립트 같은 것들이죠. 필드 이름은 설정한 그대로 나오므로 모델의 속성 이름에 맞춰 두면 매핑 단계를 아낄 수 있습니다.
CSV는 사람이 개입하는 경로를 위한 형식입니다. 가져오기 전에 눈으로 훑어볼 스프레드시트, 관리자용 업로드 양식, 대량 가져오기 도구 같은 곳이죠. 다만 받는 쪽에서 늘 따라붙는 CSV의 주의사항을 기억하십시오. 타입을 추측하는 소비자는 숫자처럼 보이는 것에 대해 제멋대로 판단하고, 참조 번호 앞의 0이 늘 그 희생양입니다.
자주 묻는 질문
- 생성된 데이터를 저장소에 커밋해도 안전한가요?
- 안전하며, 그렇게 되도록 설계했습니다. 이름은 가상의 목록에서 뽑고, 전화번호는 북미번호계획이 허구용으로 예약한 +1-555-01xx 대역, 이메일과 URL은 RFC 2606이 예약한 example.com 계열, IP 주소는 RFC 5737 문서용 블록을 사용합니다. 여기서 생성된 값은 실제 호스트로 연결되거나 실제 번호로 전화가 걸리지 않습니다.
- AI 어시스턴트에게 테스트 데이터를 요청하면 안 되나요?
- 세 행이면 그렇게 하세요. 하지만 스키마가 고정된 500행이 필요하다면 재현성과 정확한 열 이름이 필요하고, 그건 생성기의 몫이지 대화창의 몫이 아닙니다. 필드 유형 하나를 바꿔 다시 생성하는 편이 프롬프트를 다시 쓰는 것보다 빠르고, 결과가 기기를 벗어나지도 않습니다.
- 더미 데이터, 테스트 데이터, 모의 데이터는 어떻게 다른가요?
- 실무에서는 차이가 없고 세 표현 모두 같은 것을 가리키며, 이 페이지는 그 전부를 다룹니다. 중요한 것은 형태입니다. 이름과 타입을 가진 구조화된 레코드이며, 레이아웃만 채울 뿐 데이터베이스나 API에 적재할 수 없는 Lorem ipsum 같은 자리표시 문구와는 역할이 다릅니다.
- SQL 출력은 어떻게 사용하나요?
- 입력한 테이블 이름에 대한 순수 INSERT 문이 한 행에 하나씩 출력되므로 어떤 SQL 클라이언트에서도 그대로 실행됩니다. 문자열은 따옴표를 두 번 써서 이스케이프하고, 숫자에는 따옴표를 붙이지 않으며, 불리언은 TRUE와 FALSE로 씁니다. 일반 식별자가 아닌 열 이름이나 테이블 이름은 큰따옴표로 감쌉니다.
- 왜 1,000행이 한도인가요?
- JSON 1,000행이면 이미 약 100KB의 텍스트이고, 텍스트 영역에서 다루기 시작하면 느려지는 지점입니다. 더 필요하면 여러 번 나눠 생성하세요. ID 열은 매번 1부터 다시 시작하므로 한 테이블에 적재한다면 조정이 필요합니다.
- 무작위성은 믿을 만한가요?
- crypto.getRandomValues와 거부 샘플링을 사용하며, 이 사이트의 비밀번호 생성기와 UUID 생성기가 쓰는 것과 같은 편향 없는 난수원입니다. 가상의 도시 이름에 그 정도 수준이 필요하지는 않지만, 난수 구현을 하나로 유지하면 제대로 만들어야 할 곳도 하나뿐입니다.
마지막 업데이트:
진행 단계, 예상 결과, 실제 결과를 적어 주세요. 비밀 정보와 개인 정보는 삭제해 주세요.