더미 데이터 생성기 (한국형)

운영 DB를 복사해 개발 DB에 넣으면 안 되는 이유

테스트 데이터가 급할 때 가장 손쉬운 방법은 운영 DB를 덤프해서 개발 서버에 넣는 것입니다. 그리고 이것이 개인정보 유출 사고의 단골 경로입니다. 운영 서버는 접근 제어·암호화·감사 로그가 걸려 있지만, 개발 서버는 대개 그렇지 않습니다. 개발자 노트북, 사내 위키에 붙인 스크린샷, 스테이징 API 응답으로 같은 데이터가 계속 번져 나갑니다.

법으로도 간단하지 않습니다. 개인정보는 수집할 때 밝힌 목적 범위에서만 쓸 수 있고(개인정보 보호법 제18조), "개발 테스트"는 회원가입 때 동의받은 목적에 들어 있지 않은 것이 보통입니다. 가명정보 특례도 통계 작성·과학적 연구·공익적 기록보존 목적으로 한정되어 있어, 테스트 용도가 여기 해당하는지는 다툼의 여지가 있습니다. 애초에 실제 데이터를 안 쓰면 이 논쟁 자체가 없어집니다.

• 이름·연락처를 마스킹만 해서 넣는 것도 안전하지 않습니다 — 주문 내역·주소·결제 시각이 남아 있으면 재식별이 됩니다.
• "개발 DB는 어차피 내부망"이라는 전제는 대개 오래 못 갑니다. 편의를 위해 열어 둔 포트, 백업 파일, 로컬 복제본이 반드시 생깁니다.
• 이 도구가 만드는 값은 어휘 풀과 난수의 조합이라 실존 인물·기업과 무관합니다. 유출돼도 사고가 아닙니다.

가짜 데이터가 "현실적"이어야 하는 이유

홍길동 100건으로 채운 목록 화면은 잘 돌아가는 것처럼 보입니다. 문제는 배포 후에 드러납니다. 데이터의 모양이 단조로우면 코드가 감춰 둔 버그를 못 건드리기 때문입니다.

• 길이 — 한글 이름 3자와 "남궁민수" 4자, 도로명 주소 40자가 섞여 있어야 컬럼 길이(VARCHAR)와 CSS 줄바꿈이 검증됩니다. utf8mb4에서 한글 한 글자는 3바이트라, VARCHAR(10)이 한글 10자를 담는지 아닌지는 DB 설정에 달려 있습니다.
• 중복 — 이 도구는 흔한 성씨가 더 자주 뽑히도록 가중치를 뒀습니다. "김민준"이 두 명 나오는 게 정상이고, 그래야 이름으로 사람을 식별하는 잘못된 코드가 드러납니다.
• 정렬 — 한글 이름 정렬은 DB 콜레이션에 따라 결과가 달라집니다. 다양한 성씨가 섞여 있어야 확인이 됩니다.
• 분포 — 금액이 전부 10000원이면 합계 오버플로우도, 천단위 콤마 렌더링도 확인되지 않습니다. 이 도구의 금액은 1,000원~500만원 범위에서 100원 단위로 흩어집니다.

CSV 한글이 깨질 때 · 헤더를 한글로 둘 때

엑셀은 UTF-8 CSV를 열 때 BOM(파일 맨 앞의 보이지 않는 3바이트)이 없으면 시스템 기본 인코딩으로 읽으려 해서 한글이 깨집니다. "엑셀용 BOM 넣기"는 기본으로 켜져 있고, 저장 버튼으로 받은 파일에만 적용됩니다.

반대로 그 CSV를 파이썬 pandas나 다른 파서에 먹일 거라면, BOM이 첫 컬럼명 앞에 붙어 컬럼 이름을 못 찾는 일이 생깁니다. 개발용이면 BOM을 끄거나 파서 쪽에서 encoding="utf-8-sig"로 읽으세요.

• "CSV/TSV 헤더를 한글 이름으로" — 사람이 볼 자료용입니다. 코드로 파싱할 파일이라면 꺼 두고 영문 키를 쓰세요.
• JSON·SQL의 키·컬럼명은 항상 영문 키(id, name, biz_no…)로 고정입니다. 한글 헤더 옵션의 영향을 받지 않습니다.
• TSV는 값 안의 탭·줄바꿈을 공백으로 바꿔서 내보냅니다. 열이 밀리지 않게 하기 위해서인데, 원문 그대로가 필요하면 CSV를 쓰세요.
• SQL 출력의 컬럼명은 백틱으로 감싼 MySQL 표기입니다. PostgreSQL에 넣을 때는 백틱을 큰따옴표로 바꾸거나 지우세요.

사고를 막는 두 가지 장치

"이메일을 예약 도메인(example.com)으로"는 기본으로 켜져 있습니다. 테스트 데이터를 넣은 DB에 실수로 발송 배치가 돌아 실제 주소로 메일이 나가는 사고가 드물지 않기 때문입니다. example.com·example.net·example.org는 RFC 2606이 문서·예제 용도로 예약해 둔 도메인이라 실제 메일함이 존재하지 않습니다.

이 옵션을 끄면 gmail.com·naver.com 같은 실제 도메인이 붙습니다. 도메인별 정규식 검증이나 UI 표시를 확인해야 할 때만 잠깐 끄고, 발송 로직이 붙은 환경에는 넣지 마세요.

사업자등록번호는 국세청 검증식(가중치 1,3,7,1,3,7,1,3,5)을 통과하도록 만듭니다. 그래서 "체크섬 검증 통과 → 국세청 API 조회 → 미등록"까지의 흐름을 실제로 태워 볼 수 있습니다. 체크섬만 보고 조회를 안 하는 코드의 허점이 이때 드러납니다.

이 도구로 안 되는 것

레코드는 서로 독립적으로 생성됩니다. 즉 참조 무결성이 없습니다. users와 orders를 각각 뽑아도 orders.user_id가 users.id를 가리키지는 않습니다. 관계가 필요하면 users를 먼저 넣은 뒤, 주문 데이터는 실제 id 범위에 맞춰 스크립트로 만드는 편이 빠릅니다.

한 번에 최대 1,000건입니다. 수십만 건짜리 부하 테스트용 데이터가 필요하면, 여기서 1,000건을 SQL로 뽑아 형태를 확정한 뒤 서버에서 반복 생성하는 스크립트(Faker 계열 라이브러리 등)를 쓰는 것이 맞습니다.

시간 흐름이 있는 데이터(가입 후 첫 주문, 이탈 코호트)도 만들지 않습니다. 날짜 필드는 최근 2년 안에서 무작위로 흩어질 뿐이라, 퍼널·리텐션 분석 화면을 검증하기에는 부족합니다.