DATAMIMIC CE 공개로 코딩 에이전트 테스트 데이터 지어냄 막는다

규제 산업용 테스트 데이터를 다루는 오픈소스 엔진 DATAMIMIC의 커뮤니티 에디션(CE)이 공개됐다. MIT 라이선스에 파이썬 네이티브로 동작하며, 모델 정의를 바탕으로 결정론적 합성 데이터를 만들어내는 것이 핵심이다. 원본 데이터를 전혀 쓰지 않고도 데이터셋을 생성할 수 있고, CI 파이프라인이나 로컬 개발 환경, 에이전트 주도 워크플로 어디에나 붙일 수 있다. 제목 그대로, 코딩 에이전트가 검증되지 않은 자기만의 테스트 세계를 만들어내는 상황을 막는 데 초점이 맞춰져 있다.

생성과 익명화가 한 엔진 안에 있다. 완전 합성 데이터셋은 시드를 고정하면 같은 결과가 다시 나오고, 스테이징이나 QA에서 넘어온 데이터는 필드 단위로 가명처리할 수 있다. 이때 시드 기반 결정론 모드와 프라이버시를 최대화하는 비시드 모드를 선택할 수 있다. PII 필드는 XML 파이프라인에서 직접 식별하고 모델링하는 방식이다.

실행 대상도 넓다. PostgreSQL, MySQL, Oracle, MS SQL, SQLite, MongoDB는 물론 CSV, JSON, XML, XLSX, DbUnit, 고정폭(.fcw) 파일까지 단일 시스템 파이프라인으로 다룬다. 모델링 표현력도 단순 난수 생성을 넘어선다. 가중 상태 머신, 여러 필드를 묶은 복합 참조, `<while>`과 `<assert>` 같은 제어 흐름, 단계별 집계를 위한 스크립터블 memstore를 지원한다. 출력물마다 콘텐츠 해시를 남기고 실행 로그를 append-only로 쌓기 때문에, 감사 목적의 재실행이 가능하다.

이 프로젝트가 에이전트를 위해 마련한 계약이 눈에 띈다. 기준선은 CLI다. `pip install datamimic-ce`로 설치하고, 저장소를 직접 체크아웃한 경우에는 전역 설치본이 스키마를 바꿔버리지 않도록 `.venv/bin/datamimic`을 쓰도록 안내한다. 에이전트는 사용자의 의도를 `model.dm.json`으로 보존해야 하며 XML을 손으로 작성해서는 안 된다. 흐름은 scaffold 실행, 구조화된 이슈를 통한 수리, 요구사항별 기대 선언, `verified=true`에서의 종료로 이어진다. 기존 raw XML 자산에는 lint와 범위가 제한된 dry-run을 적용한다.

스키마 규칙도 명시돼 있다. 최상위 문서에는 version, seed, products, expectations만 올 수 있다. 제품 수준의 kind(generated/source/time_series)와 필드 수준의 kind(increment, values, weighted, int_range, decimal_range, pattern, constant, script)는 서로 다른 어휘다. 범위 필드는 min/max가 아니라 minimum/maximum을 쓴다. 문서에 따르면 이 두 규칙만 지켜도 대부분의 거부를 피할 수 있다.

MCP 어댑터도 같은 계약 위에 올라간다. `pip install "datamimic-ce[mcp]"`로 설치하며, reference는 `datamimic_reference`, scaffold는 `datamimic_scaffold`, lint는 `datamimic_check`, dry-run은 `datamimic_run`으로 매핑된다. 어댑터는 이 네 가지 정규 연산만 노출하고, 도메인 데이터 생성은 파이썬과 CLI의 몫으로 남겨 병렬적인 저작 경로가 생기지 않게 했다.

CE는 엔터프라이즈 플랫폼의 코어 엔진에 해당한다. 상용 버전에는 거버넌스 워크플로, 확률 점수 기반 필드 탐지와 임계값 설정이 가능한 PII 스캐너(DataWorkbench), 역할 기반 접근 제어, 감사 로깅, 스케줄링, 다중 시스템 실행이 추가된다. Oracle·MongoDB·Kafka를 참조 무결성을 유지한 채 하나의 워크플로로 묶는 구성이나, EDIFACT·SWIFT MT·HL7 v2.x·HL7 FHIR 같은 업계 메시지 템플릿 생성도 이 계층의 기능이다. 성능 코어에는 Rust fastpath와 복잡한 분포를 위한 ML/자기회귀 엔진, 키셋·매니페스트 빌딩, 분산 실행 최적화가 들어간다. 배포는 podman-compose나 Helm으로 온프레미스·에어갭 환경을 지원한다.

배경에는 규제 산업의 오래된 딜레마가 있다. 운영 데이터를 그대로 복사해 테스트에 쓰면 컴플라이언스 리스크가 생기고, 그렇다고 아무 값이나 채워 넣으면 장애 재현이 안 된다. 여기에 LLM 기반 코딩 에이전트가 끼어들면서 문제가 하나 더 늘었다. 에이전트가 즉석에서 만든 픽스처는 그럴듯해 보이지만 시드도 스키마도 없어서, 같은 테스트를 다시 돌렸을 때 같은 결과가 나온다는 보장이 없다. DATAMIMIC은 EU 은행권의 Oracle·MongoDB·Kafka 파이프라인에서 결정론적 테스트 데이터로 쓰인 사례가 있다고 밝히고 있다.

실무에서 확인할 지점은 몇 가지다. 먼저 CE만으로 충분한 범위인지, 아니면 거버넌스·스캐너·스케줄러가 필요한지 따져야 한다. 에이전트를 붙일 계획이라면 MCP 어댑터가 네 가지 연산만 노출한다는 점, 그리고 저작 성공 이후에는 생성된 XML을 다시 lint하거나 dry-run하지 말라는 규칙을 그대로 따라야 한다는 점을 기억해두는 게 좋다. 시드 관리 정책과 PII 필드 모델링은 여전히 사람이 결정할 몫이다.

한계도 분명하다. CE에는 거버넌스 계층과 PII 자동 스캐너가 없고, PII 필드는 XML 파이프라인에서 수동으로 식별해 모델링해야 한다. 다중 시스템 실행, 역할 기반 대시보드, 승인 흐름, 감사 추적 같은 운영 계층은 엔터프라이즈 플랫폼의 영역이다. 즉 CE는 결정론적 생성 엔진이지, 규제 대응을 자동으로 끝내주는 도구는 아니다.