AI 코딩 에이전트가 개발 워크플로에 깊숙이 들어오면서 새로운 문제가 생겼다. 에이전트가 테스트를 돌리기 위해 스스로 '적당한' 가짜 데이터를 만들어내면, 그 데이터는 실행할 때마다 달라진다. 랜덤하게 생성된 입력값은 회귀 테스트를 깨뜨리고, 감사 추적을 흐리며, 팀 간 재현성을 무너뜨린다. 오픈소스 프로젝트 Datamimic은 바로 이 지점을 겨냥한다. 원제가 말하는 '코딩 에이전트가 자기만의 테스트 세계를 지어내게 두지 말라'는 문장은, 테스트 데이터의 생성 자체를 통제 가능한 계약으로 바꾸자는 제안이다.
Datamimic Community Edition(CE)은 MIT 라이선스로 공개된 파이썬 네이티브 엔진이다. 핵심 가치는 '결정론(determinism)'이다. 시드(seed)를 고정하면 어떤 머신에서 몇 번을 실행하든 바이트 단위로 동일한 출력이 나온다. pip install datamimic-ce로 설치하며, 파이썬 API와 XML 파이프라인, 그리고 MCP 어댑터를 통해 IDE·에이전트 환경과 연동된다. 무작위 출력에 의존하던 기존 테스트 데이터 도구와 달리, 입력 데이터가 안정적이므로 회귀 테스트가 '데이터 때문에' 실패하는 상황을 줄일 수 있다는 것이 이 도구의 출발점이다.
에이전트를 위한 네 가지 계약
Datamimic이 에이전트 친화적이라고 말하는 근거는 CLI를 '기본 계약(baseline contract)'으로 삼는 설계에 있다. 저장소 안에서는 전역에 설치된 낡은 버전이 스키마나 명령을 바꾸지 못하도록 .venv/bin/datamimic를 쓰도록 권한다. 작업 흐름도 명확하다. 새 의도는 model.dm.json으로 보존하고, datamimic scaffold ... --format json으로 이른 초안을 제출한 뒤, 구조화된 검증 이슈를 보고 고쳐 나가며, 요구사항마다 기대값을 선언하고 verified=true에서 멈춘다. 실패한 호출을 그대로 반복하지 말라는 규칙, 성공한 scaffold 결과는 더 이상 lint나 dry-run 하지 말라는 규칙처럼, 에이전트가 헛도는 것을 막는 장치가 명시돼 있다.
MCP 어댑터(datamimic-ce[mcp])는 reference·scaffold·check·run이라는 네 개의 정규 연산만 노출한다. 이는 각각 CLI의 reference→scaffold→lint→dry-run에 대응한다. 흥미로운 점은 도메인 데이터 생성 자체는 MCP로 열지 않고 파이썬/CLI 역량으로 남겨 두었다는 것이다. 즉 에이전트에게는 '무엇을 만들지 설계하고 검증하는 경로'만 주고, 실제 대량 생성은 검증된 코드 경로로 흘려보낸다. 생성된 도메인 출력에는 determinism_proof.content_hash가 붙어, 나중에 재실행해 동일 데이터를 재구성하고 검증할 수 있다. 에이전트가 '봤던' 데이터를 사후에 복원해야 하는 회귀 테스트 시나리오에서 유용한 특성이다.
가명화, 두 개의 프라이버시 자세
실무에서 또 하나 눈여겨볼 부분은 스테이징·QA 익스포트의 가명화(pseudonymization)다. Datamimic은 두 가지 모드를 제공한다. rngSeed를 설정하면 같은 원본 레코드는 매번 같은 가명 출력으로 매핑돼 회귀 테스트에 안정적이다. 반대로 시드 없이 실행하면 필드 수준에서 되돌릴 매핑이 존재하지 않아, 일회성 전달처럼 프라이버시를 최대화해야 하는 상황에 맞는다. Mask, MiddleMask, Hash, DateFormat 등 13종의 컨버터로 값을 해시하거나 부분 마스킹할 수도 있다. 다만 CE에서는 PII 필드를 XML 파이프라인에서 수작업으로 식별하고 모델링해야 한다. 소스는 반드시 운영계 직결이 아니라 통제된 익스포트나 스테이징 입력이어야 한다는 점도 문서가 못 박고 있다.
여기서 한계를 정확히 이해하는 것이 중요하다. Datamimic은 GDPR상의 '완전 익명화'를 대신 주장하지 않는다. 익명화 성립 여부는 개별 필드 변환이 아니라, 모든 준식별자에 대한 완전한 커버리지와 전체 레코드 차원의 재식별 위험 평가에 달려 있으며, 그 판단 책임은 고객에게 있다. 도구는 재현 가능한 산출물과 프로버넌스 증거를 제공할 뿐, DPO나 CISO, 감사인을 대체하지 않는다는 선을 분명히 한다. 규제 문서 작성 시 이 경계를 그대로 인용해 두는 편이 안전하다.
CE와 엔터프라이즈, 그리고 도입 판단
CE와 Enterprise Platform(EE)은 '기능 플래그로 나뉜 같은 엔진'이 아니다. 둘은 DSL과 결정론 계약을 공유하지만, EE는 Rust 패스트패스와 분산 실행을 갖춘 별도 최적화 엔진으로 소개된다. EE는 라이브 스키마를 스캔해 PII 후보에 확률 점수를 매기는 DataWorkbench 스캐너, 역할 기반 접근제어, 감사 로깅, Kafka·SWIFT MT·HL7 FHIR 같은 추가 타깃, 그리고 규제 배포를 위한 다섯 개의 드리프트 게이트를 더한다. 다만 문서는 대부분의 팀이 CE를 채택하는 세 가지 이유—CI/CD용 재현 가능 테스트 데이터, AI 에이전트의 결정론적 데이터 백엔드, 스테이징·QA 익스포트의 가명화—어느 것에도 EE가 필수는 아니라고 명시한다.
국내 실무자 관점에서 Datamimic CE는 '테스트 데이터의 재현성'이라는, 그동안 각 팀이 임시방편으로 메우던 공백을 정면으로 다룬다는 점에서 검토할 가치가 있다. 특히 AI 에이전트가 코드와 테스트를 함께 생성하는 파이프라인이 늘어날수록, 데이터의 결정론과 사후 검증 가능성은 선택이 아니라 요건이 된다. 다만 CE 단계에서는 PII 식별이 수작업이고, 생성된 금융 메시지 등은 테스트·학습 용도로만 유효하며 실제 SWIFTNet·EDI 망으로 전송해서는 안 된다는 제약을 함께 안고 도입 범위를 정해야 한다. 화려한 자동화보다, 시드 하나로 결과가 고정된다는 단순한 보장이 이 도구의 실질적 무게중심이다.