목업 데이터 생성기 — 테스트와 프로토타이핑을 위한 즉석 가짜 데이터

개발을 하다 보면 이런 상황이 반드시 옵니다. 새로운 기능을 만들었는데, 화면이 텅 빈 상태에서는 제대로 테스트할 수가 없습니다. 데이터베이스에 사용자 레코드가 있어야 페이지네이션이 동작하는지 알 수 있고, 다양한 이름 길이가 있어야 테이블이 깨지지 않는지 확인할 수 있습니다.

그래서 개발자들은 더미 데이터를 만들기 시작합니다. 처음엔 간단합니다. "홍길동", "hong@example.com", 이런 식으로 몇 개 입력하면 되니까요. 그런데 100개가 필요해지면? 1000개가 필요해지면? 스프레드시트를 켜서 손으로 채우거나, 반복문을 짜서 억지로 생성하거나, 팀 내에서 "누가 테스트 데이터 좀 만들어줄 수 없어요?"를 외치게 됩니다.

목업 데이터 생성기는 이 문제를 해결합니다. 원하는 필드와 레코드 수를 선택하면 수초 안에 현실적인 가짜 데이터셋을 만들어줍니다.

직접 더미 데이터를 만들 때의 문제점

"그냥 직접 만들면 되지 않나요?"라고 생각할 수 있습니다. 몇 가지 현실적인 문제가 있습니다.

시간 낭비: 10개는 금방이지만 50개만 넘어가도 지루한 작업이 됩니다. 특히 이름, 이메일, 전화번호, 주소가 모두 있어야 한다면 레코드 하나당 몇 분씩 걸립니다.

현실적이지 않은 데이터: "테스트", "asdf", "user1@test.com" 같은 데이터로는 진짜 엣지 케이스를 발견하기 어렵습니다. 실제 사용자들은 긴 이름을 쓰기도 하고, 특수문자가 포함된 주소를 갖기도 하고, 다양한 형식의 전화번호를 입력합니다.

반복 불가능한 패턴: 수동으로 만든 데이터는 테스트마다 일관성이 없습니다. 특정 버그를 재현하려면 그 버그를 유발했던 데이터를 정확히 기억해야 합니다.

개인정보 위험: 실제 데이터를 개발 환경에 가져다 쓰는 팀도 있습니다. 이는 개인정보 규정(GDPR, PIPA 등) 위반이 될 수 있고, 데이터 유출 사고로 이어질 수 있습니다.

좋은 목업 데이터의 조건

좋은 목업 데이터는 그냥 랜덤한 문자열이 아닙니다. 현실적이어야 하고, 다양해야 하며, 실제 사용 패턴을 반영해야 합니다.

현실적인 이름: 한 성씨에서 나온 다양한 이름 조합, 실제로 존재할 법한 이름들이 있어야 합니다. "User1", "User2"가 아닌 실제 이름처럼 보여야 UI 디자인 검토도 의미 있게 할 수 있습니다.

유효한 형식: 이메일 주소는 @와 도메인이 있어야 하고, 전화번호는 실제 번호 형식을 따라야 합니다. 형식이 맞지 않는 더미 데이터는 폼 유효성 검사에서 걸려서 아예 입력조차 안 됩니다.

다양한 길이와 패턴: 이름이 두 글자인 경우, 열 글자를 넘는 경우, 주소가 짧은 경우, 긴 경우 — 이 다양성이 있어야 레이아웃 버그를 찾아낼 수 있습니다.

충분한 양: 10개는 페이지네이션 테스트에 부족합니다. 최소 수십 개, 성능 테스트라면 수천 개가 필요합니다.

실제 사용 사례들

UI 프로토타이핑과 디자인 리뷰

피그마나 프로토타입 화면에 "이름"이라고만 써 있으면 실제 느낌을 알기 어렵습니다. 50명의 사용자 목록이 있는 화면을 검토할 때 실제 이름처럼 보이는 데이터가 들어가 있으면 이름이 잘리진 않는지, 아바타 영역은 충분한지, 긴 직책이 줄 바꿈 처리가 되는지를 바로 확인할 수 있습니다.

디자인 리뷰 미팅에서 실제 같아 보이는 데이터로 채워진 화면을 보여주면 이해관계자들이 훨씬 현실적인 피드백을 줍니다. "실제 이름이 들어가면 어떻게 보일까요?"라는 질문 없이 바로 논의할 수 있습니다.

단위 테스트와 통합 테스트

테스트 코드에서 const user = { name: 'test', email: 'test@test.com' } 같은 하드코딩된 데이터를 쓰는 것은 한계가 있습니다. 실제로 다양한 입력값으로 테스트하려면 픽스처 데이터가 필요하고, 목업 데이터 생성기에서 100개 레코드를 JSON으로 뽑아 fixtures 폴더에 넣는 것이 훨씬 현실적입니다.

특히 정렬, 필터링, 검색 기능 테스트에는 다양한 데이터가 필수입니다. 모든 이름이 'A'로 시작하는 데이터로 알파벳 정렬을 테스트하면 버그를 놓치게 됩니다.

API 개발과 문서화

백엔드 개발자가 API를 만들고 문서를 작성할 때 예시 응답이 필요합니다. Postman 컬렉션이나 Swagger 문서에 들어가는 예시 데이터를 목업 생성기에서 뽑아서 쓰면 훨씬 빠릅니다.

또한 프론트엔드 개발자에게 API가 아직 준비되지 않았지만 개발을 먼저 시작해야 할 때, JSON 파일을 목업 서버로 사용하는 방법이 많이 쓰입니다. json-server 같은 도구와 목업 데이터를 조합하면 빠르게 가짜 API 서버를 만들 수 있습니다.

데이터베이스 시딩

개발 환경이나 스테이징 환경의 데이터베이스에 초기 데이터를 넣는 작업입니다. SQL INSERT 형식으로 출력하면 바로 데이터베이스에 붙여넣을 수 있어서 seed 스크립트 작성 시간을 크게 줄여줍니다.

INSERT INTO users (id, name, email, phone, city) VALUES
(1, 'Mia Turner', 'mia.turner@example.net', '555-0142', 'Portland'),
(2, 'James Chen', 'j.chen@example.org', '555-0287', 'Seattle'),
...

이런 형태의 데이터를 수동으로 만드는 것은 끔찍한 일입니다.

발표와 데모

투자자나 고객에게 제품을 시연할 때 "홍길동", "테스트" 같은 명백한 더미 데이터가 화면에 보이는 것은 좋지 않습니다. 현실적인 이름과 데이터가 들어가 있으면 제품이 훨씬 완성도 있어 보입니다.

지원하는 필드와 출력 형식

좋은 목업 데이터 생성기는 다양한 필드를 지원해야 합니다. 목업 데이터 생성기에서 선택할 수 있는 주요 필드들입니다.

신원 관련: 이름(이름/성 구분), 이메일, 전화번호, 생년월일, 나이, 성별

위치 관련: 도시, 국가, 주소, 우편번호

직업 관련: 회사명, 직책

기술 관련: 사용자명, 비밀번호, UUID, IP 주소

기타: 색상 코드, URL, 신용카드 번호(테스트용), 가격

출력 형식

JSON: 객체 배열 형태로 출력됩니다. JavaScript, Python, 대부분의 웹 프레임워크에서 바로 사용할 수 있습니다.

[
  {
    "id": 1,
    "name": "Sarah Mitchell",
    "email": "sarah.m@example.com",
    "phone": "555-0193",
    "city": "Denver"
  }
]

CSV: 헤더 포함 쉼표 구분 형식입니다. 스프레드시트로 열거나 데이터 분석 도구에 바로 넣을 수 있습니다.

SQL: INSERT 구문 형태입니다. 테이블명을 지정하고 바로 데이터베이스에 붙여넣을 수 있습니다.

실용적인 워크플로우 팁

필요한 필드만 선택하세요. 모든 필드를 다 선택할 필요가 없습니다. 현재 테스트하려는 기능에 필요한 필드만 고르면 데이터가 훨씬 깔끔하고 사용하기 편합니다.

레코드 수는 상황에 맞게. UI 테스트에는 2050개, 페이지네이션 테스트에는 100200개, 성능 테스트에는 1,000개 이상이 필요합니다. 처음부터 많이 만들어두면 나중에 다시 생성할 필요가 없습니다.

JSON 파일로 저장해 두세요. 팀 저장소의 fixtures/ 또는 test-data/ 폴더에 저장해두면 팀원들이 같은 데이터로 테스트할 수 있습니다. 버전 관리도 됩니다.

프로덕션 데이터는 절대 개발 환경에 쓰지 마세요. 이것이 목업 데이터를 쓰는 가장 중요한 이유 중 하나입니다. 실제 사용자 데이터가 개발자 노트북이나 공유 개발 서버에 있다면 그것 자체가 보안 위험입니다.

CI/CD 파이프라인에서도 활용하세요. 자동화 테스트에서 매번 데이터를 생성하는 대신, 미리 만들어진 목업 데이터 파일을 fixtures로 사용하면 테스트 실행 속도도 빨라지고 재현성도 높아집니다.

마치며

개발 초기에 데이터 문제로 진행이 막히는 것은 생산성 낭비입니다. 목업 데이터 생성기는 개발 workflow에서 작지만 의미 있는 마찰을 제거해줍니다.

목업 데이터 생성기를 한 번 써보시면 "이걸 왜 이제야 알았지"라는 생각이 들 수도 있습니다. 설치 없이 브라우저에서 바로, 무료로, 데이터는 브라우저 밖으로 나가지 않습니다. 다음 번에 더미 데이터가 필요해지면 직접 만드는 대신 30초 안에 해결하세요.