무슨 일이 있었나요
Claude Code나 Cursor 같은 코딩 에이전트에게 "이 기능 테스트 좀 짜줘" 하면 어떻게 되던가요? 테스트 코드와 함께 name: John Doe, email: john@example.com 같은 픽스처(테스트용 가짜 데이터)를 그 자리에서 지어내요. 파일마다 다른 John Doe가 생기고, 주문 테이블엔 존재하지 않는 고객 ID가 들어가고, 한국 주소 형식은 아예 없는 미국식 데이터가 쌓이죠. rapiddweller에서 만든 Datamimic은 이 문제를 겨냥한 오픈소스 테스트 데이터 생성 플랫폼이에요. 프로젝트 슬로건이 "코딩 에이전트가 자기만의 테스트 세계를 지어내지 못하게 하라"인데, 이 한 줄에 요즘 개발 현장의 고민이 다 들어 있어요.
지어낸 테스트 데이터, 뭐가 문제냐면
에이전트가 즉석에서 만드는 데이터는 네 가지 문제가 있어요. 첫째, 너무 착해요. 이름은 항상 영문이고, 나이는 항상 30이고, 결제 금액은 항상 딱 떨어져요. 실제 서비스에서 버그를 만드는 건 이름에 아포스트로피가 들어가거나 생년월일이 2월 29일인 경우인데, 그런 데이터는 안 만들어져요. 둘째, 서로 안 맞아요. 사용자 테스트에서 만든 ID와 주문 테스트에서 참조하는 ID가 다르면, 두 테스트를 합쳐 돌리는 순간 깨져요. 데이터베이스에서 말하는 참조 무결성(외래 키가 실제 존재하는 행을 가리키는 것)이 테스트 세계에서는 지켜지지 않는 거죠. 셋째, 매번 달라요. 에이전트를 다시 돌리면 또 다른 세계가 생기니까 "이 테스트가 왜 실패하지?"를 재현하기가 어려워요. 넷째, 가장 위험한 건데, 이런 게 귀찮으면 결국 운영 DB를 복사해서 쓰고 싶어져요. 개인정보가 개발 환경으로 흘러가는 사고는 대부분 여기서 시작돼요.
Datamimic이 하는 일
Datamimic의 접근은 "데이터의 모양을 먼저 선언하고, 데이터는 거기서 뽑아 쓰자"예요. 파이썬 기반이고, 엔티티(사용자, 주문, 상품 같은 것)와 각 필드의 규칙, 엔티티 사이의 관계를 모델로 정의해요. 그러면 엔진이 그 모델을 따라 원하는 수만큼 데이터를 생성해 주고요. 개념적으로는 이런 느낌이에요.
- Customer 1,000명: 이름은 한국어 로케일 사람 이름, 이메일은 이름에서 파생되고 유일해야 함, 생년월일은 만 19세 이상
- Order는 Customer당 0~5개: customer_id는 반드시 존재하는 Customer를 참조, 금액은 1,000원에서 500,000원 사이, 그중 5%는 환불 상태
에이전트와 엮는 방법은 단순해요. 프로젝트 규칙 파일(CLAUDE.md나 .cursorrules 같은 것)에 "테스트 데이터는 직접 만들지 말고 Datamimic 모델에서 생성해서 써라"고 적어두고, 모델 파일을 저장소에 함께 두는 거예요. 그러면 에이전트가 새 테스트를 짤 때 픽스처를 지어내는 대신 기존 모델을 호출하게 되고, 새 필드가 필요하면 모델에 추가하는 식으로 일하게 돼요. 테스트 데이터의 "단일 진실 공급원"이 생기는 거죠.
업계 흐름에서 보면
가짜 데이터 생성 자체는 새롭지 않아요. 파이썬의 Faker, 테스트 객체를 찍어내는 Factory Boy, 자바 진영의 Instancio 같은 도구가 오래전부터 있었어요. 다만 이 도구들은 "필드 하나에 그럴듯한 값 하나"를 만드는 데 강하고, 여러 테이블에 걸친 관계와 비즈니스 제약을 한꺼번에 지키는 건 개발자 몫이었어요. Datamimic을 만든 rapiddweller는 그 전에 Benerator라는 자바 기반 테스트 데이터 생성기를 오래 만들어 온 곳이라, 이 "모델 중심" 철학을 파이썬과 AI 에이전트 시대에 맞게 다시 낸 셈이에요. 한편 Tonic이나 Gretel처럼 운영 데이터를 통계적으로 흉내 내는 상용 합성 데이터 서비스도 있는데, 그쪽은 대규모 데이터 파이프라인 쪽에 가깝고 Datamimic은 개발자의 테스트 워크플로 쪽에 가까워요.
한국 개발자에게는
한국은 개인정보보호법 때문에 운영 데이터를 개발 환경으로 가져오는 게 특히 까다로워요. 금융이나 의료 도메인이면 더하고요. 그래서 "처음부터 가짜인데 진짜처럼 생긴" 데이터를 체계적으로 만드는 도구는 실무 가치가 커요. 다만 한국어 이름, 도로명 주소, 휴대폰 번호 형식 같은 로케일 지원이 어느 정도인지는 직접 확인해 보셔야 해요. 부족하면 커스텀 생성기를 하나 만들어 팀 내에서 공유하는 것만으로도 큰 차이가 나요.
시작은 작게 하는 게 좋아요. 에이전트가 가장 자주 건드리는 도메인 하나만 모델로 옮기고, 규칙 파일에 한 줄 추가한 뒤 에이전트가 정말 모델을 쓰는지 지켜보세요. 이것만으로도 "테스트마다 다른 John Doe"는 사라져요.
정리하면
Datamimic의 핵심은 도구 자체보다 "테스트 세계는 사람이 설계하고, 에이전트는 그 세계 안에서만 일하게 한다"는 원칙이에요. 코드 생성 속도가 빨라질수록 데이터의 일관성이 병목이 되는데, 그걸 미리 잡아두자는 얘기죠.
여러분 팀의 에이전트는 테스트 데이터를 어디서 가져오나요? 지어내게 두고 있다면, 그 데이터로 통과한 테스트를 얼마나 믿으시나요?
🔗 출처: Hacker News