왜 나는 DDL을 Data에 구축했는가

Source: Dev.to

문제

제가 계속 보던 상황은 이렇습니다:

경영진은 금요일까지 시연용 데모를 준비해야 합니다. 영업팀은 고객에게 “실제” 데이터를 사용한 제품을 보여주겠다고 약속했습니다. 그래서 누군가가 프로덕션 데이터를 가져오자고 제안합니다.

그때 DevOps는 화가 나고, 보안팀은 왜 프로덕션과 스테이징 사이에 VPC 피어링이 필요한지 묻습니다. 누군가는 PII를 마스킹하기 위해 급히 움직여야 합니다. DBA는 회의에 끌려 들어갑니다. “빠른 데모”는 세 팀과 네 개의 Slack 채널이 얽힌 2주짜리 프로젝트로 변합니다.

모두 현실적인 데이터를 필요로 했기 때문이었습니다.

데모뿐만 아니라, 새로운 개발자 온보딩마다 시드된 데이터베이스가 필요했고, QA 사이클마다 새로운 테스트 데이터가 필요했습니다. 스테이징 환경을 새로 고칠 때마다 프로덕션이 되었습니다.

답은 언제나 똑같았습니다: “프로덕션을 그냥 복사해도 될까요?”

아니요. 할 수 없습니다.

대안들은 형편없었다

Faker 라이브러리

시간이 충분해서 모든 컬럼을 연결하고, 보일러플레이트 코드를 작성하고, 스크립트를 유지 관리할 수 있다면 좋은 방법입니다. email을 faker.email()에, phone을 faker.phone()에, created_at을 faker.date()에 매핑해야 합니다. 모든 테이블에 대해, 스키마가 바뀔 때마다마다 말이죠.

데모가 목요일이라면 그런 시간을 아무도 갖지 못합니다.

LLM에 프롬프트?

물론 작동합니다—하지만 매번 포맷이 달라지고, 출력 구조가 바뀌면서 테스트가 깨지기 시작하고, CI 실행마다 토큰 비용을 지불해야 하며 파이프라인이 OpenAI 가동 시간에 의존하게 될 때까지는요.

프로덕션 데이터를 복사?

보안을 통과시키는 데 행운을 빕니다. 설령 통과한다 하더라도 개발 환경에 고객 PII가 남아 있게 되므로 책임이 따릅니다. 실수로 로그에 남기거나 버그 보고서에 스크린샷을 하나 찍는 것만으로도 컴플라이언스 사고가 발생합니다.

이러한 옵션들은 “프로덕션 데이터가 아닌 현실적인 데이터가 필요하다”는 간단한 요구에 전혀 맞지 않았습니다.

깨달음

스키마는 이미 데이터가 어떤 형태여야 하는지를 정의하고 있습니다.

• email VARCHAR(100) → 이메일
• phone VARCHAR(20) → 전화 번호
• created_at TIMESTAMP → 타임스탬프
• first_name VARCHAR(50) → 이름

구조는 DDL에 바로 명시돼 있습니다. 스키마가 이미 설명할 수 있는 데이터를 얻기 위해 보안을 싸우고, DevOps에 애원하고, 컴플라이언스를 위험에 빠뜨릴 필요가 있을까요?

나는 프로덕션 데이터를 필요로 한 것이 아니라 프로덕션 형태의 데이터가 필요했습니다.

내가 만든 것

DDL to Data는 CREATE TABLE 문을 받아 즉시 현실적인 데이터를 생성합니다.

1. 스키마를 붙여넣으세요.
2. JSON을 받아보세요.
3. 이메일은 이메일처럼, 전화번호는 전화번호처럼, 이름은 이름처럼—컬럼 이름을 자동으로 추론합니다.

• 프로덕션 접근 권한이 필요 없습니다.
• VPC 피어링이 필요 없습니다.
• PII(개인식별정보) 문제가 없습니다.
• 보안 검토가 필요 없습니다.
• 결정론적 패턴 매칭—동일한 스키마에 동일한 출력이 매번 제공됩니다.
• CI/CD에 충분히 빠릅니다(밀리초 단위, 초가 아님).

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  first_name VARCHAR(50),
  last_name VARCHAR(50),
  email VARCHAR(100),
  phone VARCHAR(20),
  created_at TIMESTAMP
);

[
  {
    "id": 1,
    "first_name": "Sarah",
    "last_name": "Chen",
    "email": "sarah.chen@techstartup.io",
    "phone": "+1-555-234-5678",
    "created_at": "2024-03-15T09:23:41"
  },
  {
    "id": 2,
    "first_name": "Marcus",
    "last_name": "Johnson",
    "email": "m.johnson@company.com",
    "phone": "+1-555-876-5432",
    "created_at": "2024-03-14T14:56:12"
  }
]

설정이 필요 없습니다. 구성도 필요 없습니다. 엔지니어에게 프롬프트도 필요 없습니다.

대상

• 보안 고민 없이 데모 데이터가 필요한 팀
• 프로덕션에 접근하면 안 되는 개발 환경
• test@test.com과 John Doe 같은 가짜 데이터가 아닌 현실적인 데이터가 필요한 QA 엔지니어
• 일관되고 빠른 데이터 생성을 필요로 하는 CI/CD 파이프라인
• 경영진이 “왜 프로덕션을 그대로 복사하지 못하나요?” 라고 물을 때 회의에 참석한 사람 모두

테스트 데이터를 얻는 데 실제 테스트보다 더 많은 시간을 보냈다면, 이것이 바로 당신을 위한 것입니다.

다음 단계

• 스토리 모드 – 원하는 시나리오를 설명하면 데이터가 그에 맞게 조정됩니다. 예시: “기업 고객을 보유한 성장 중인 B2B SaaS와 일부 이탈 계정” 또는 “계절별 휴일 트렌드가 있는 전자상거래 스토어”. 데이터가 무작위가 아니라 일관된 이야기를 전달합니다.
• 직접 데이터베이스 시딩 – 복사‑붙여넣기를 건너뛰세요. DDL을 데이터와 직접 연결해 PostgreSQL 데이터베이스에 한 번의 클릭으로 테이블을 채웁니다. 프로덕션에 손대지 않고 스테이징을 시드합니다.

사용해 보기

실제 같은 데이터가 필요하지만 프로덕션에 손대고 싶지 않을 때, 바로 이걸 위해 만들었습니다.

무료 티어. 신용카드 필요 없음. 스키마를 붙여넣기만 하면 결과를 확인할 수 있습니다.

DDL to Data 시도 →

Travis가 만들었습니다. 질문이나 피드백이 있나요? X에서 @DDLTODATA 로 연락 주세요.