AI 코딩 에이전트에게 "현실적인 테스트 데이터를 만들어 달라"고 맡기는 순간, 팀은 코드뿐 아니라 데이터 세계의 규칙까지 에이전트의 추측에 넘기게 된다. 이름·주소 형식은 그럴듯하지만 주문 상태 전이, 계좌 잔액 제약, 진료 기록의 참조 관계가 틀리면 테스트가 통과해도 운영 장애를 막지 못한다.
핵심은 개인정보를 지운 데이터가 아니라 재현 가능하고 업무 규칙을 설명할 수 있는 데이터다. 어떤 입력으로 어떤 데이터셋을 만들었고, 왜 그 값이 유효한지, 같은 변경을 다시 시험했을 때 같은 결과가 나오는지를 팀이 확인할 수 있어야 한다. AI 에이전트는 이 경계 안에서 테스트 코드와 데이터 모델을 수정하게 해야 한다.
먼저 정할 것은 데이터 방식이 아니라 테스트의 실패 조건이다
고정 fixture, 마스킹, 가명화, 합성 데이터는 서로 대체재가 아니다. 발견하려는 결함의 종류가 다르므로 한 프로젝트 안에서도 함께 쓴다.
| 테스트 목적 | 우선 방식 | 적합한 이유 | 주의할 점 |
|---|---|---|---|
| 함수·컴포넌트의 분기 검증 | 고정 fixture | 입력과 기대 결과를 코드 리뷰에서 바로 읽을 수 있다 | 업무 규칙이 바뀌면 fixture도 함께 갱신해야 한다 |
| API 계약, 오류 응답, 경계값 검증 | 고정 fixture + 합성 데이터 | 알려진 예외와 조합 폭발을 함께 다룬다 | 무작위 생성만으로 기대 결과를 판단하기 어렵다 |
| 주문·정산·권한처럼 관계가 복잡한 통합 테스트 | 도메인 모델 기반 합성 데이터 | 부모·자식 관계, 상태 전이, 금액 제약을 데이터 생성 단계에서 강제할 수 있다 | 스키마만 복사하고 업무 규칙을 빼면 현실성이 떨어진다 |
| 운영 데이터와 가까운 쿼리·마이그레이션 검증 | 가명화 또는 제한된 마스킹 데이터 | 실제 분포와 예외 패턴을 일부 보존할 수 있다 | 개인정보 재식별 위험과 접근 통제를 별도로 검토해야 한다 |
| 화면 시연, 개발용 샌드박스, 에이전트 반복 실행 | 합성 데이터 | 원본 데이터 없이 배포·공유·초기화를 반복할 수 있다 | 운영 분포를 그대로 재현한다고 가정하면 안 된다 |
고정 fixture는 작고 명확해야 한다. "환불 완료 주문에는 재환불을 요청할 수 없다"는 규칙은 몇 개의 주문 레코드와 기대 오류 코드로 표현하는 편이 낫다. 대량 데이터나 개인정보와 유사한 값은 도움보다 검토 비용을 늘린다.
반대로 월별 정산, 재고 예약, 다기관 권한처럼 여러 테이블과 이벤트가 연결된 기능은 fixture만으로 관리하기 어렵다. 고객·계약·주문·결제·취소·분개가 어떤 순서와 제약으로 연결되는지 데이터 모델로 선언하고, 그 모델에서 합성 데이터를 생성하는 방식이 더 잘 맞는다.
방식과 규제 수준을 교차해서 선택한다
고정 fixture, 마스킹, 가명화, 합성 데이터 중 무엇을 쓸지는 테스트 목적만큼이나 팀이 다루는 정보의 민감도와 규제 환경에 따라 달라진다. 아래 매트릭스는 각 방식을 어떤 환경에서 쓸 수 있고, 어떤 조건이 필요한지를 정리한 것이다.
| 방식 | 일반 내부 서비스 (개인정보 없음 또는 최소) | 개인정보 처리 서비스 (이름·연락처·행동 이력 등) | 민감정보 또는 강한 규제 환경 (의료·금융·공공) |
|---|---|---|---|
| 고정 fixture | 자유롭게 사용. 코드와 함께 저장소에 보관 가능 | 개인 유사값 제외하고 사용. 실제 값 혼입 금지 | 업무 규칙 검증용으로 최소 범위만 사용. 민감 필드 포함 금지 |
| 마스킹 | 필요성 낮음. 개인정보가 없으면 의미 없음 | 화면 확인·제한적 샘플 검토에 사용 가능. 다른 열과 결합한 재식별 위험을 별도 검토 | 제한적 허용. 조합 재식별 위험 평가 필수. 에이전트·외부 협업 환경 반입 금지 |
| 가명화 | 일반적으로 불필요 | 레코드 간 동일 고객 연결이 필요한 통합 테스트에 사용 가능. 변환 키 분리·접근 통제 필요 | 승인된 격리 환경에서만 허용. 변환 규칙·원본 키 보관 이력, 데이터 소유자 승인 필수 |
| 합성 데이터 | 자유롭게 사용. CI·에이전트 작업 공간에 기본 선택 | 기본 선택. 분포 모델이 실제 패턴을 과도하게 반영하지 않는지 검토 | 기본 선택이자 원칙. 운영 유사 검증이 꼭 필요한 범위에서만 가명화로 예외 허용 |
이 매트릭스는 규범이 아니라 팀 논의의 출발점이다. 실제 적용 가능 여부는 처리 데이터의 종류, 내부 정책, 법적 요건에 따라 달라지므로 보안·법무 담당자가 각 칸의 조건을 함께 검토해야 한다.
마스킹과 가명화는 "안전한 복사본"이라는 뜻이 아니다
마스킹은 원본 값의 일부를 가리거나 다른 값으로 치환한다. 이메일 일부를 감추거나 전화번호 끝자리를 바꾸는 방식이다. 값 노출을 줄이는 효과는 있지만, 직업·지역·날짜·거래 패턴처럼 다른 열과 결합하면 개인을 다시 추정할 가능성이 남는다. 마스킹한 식별자 하나만 보고 안전하다고 판단할 수 없는 이유다.
가명화는 개인을 직접 식별하는 값을 다른 일관된 값으로 바꾸되, 같은 사람의 여러 레코드를 계속 연결할 수 있게 유지한다. 예를 들어 고객 ID "kim-2931"이 모든 주문·이력 레코드에서 동일한 가명 "anon-5847"로 바뀌어야 조인 검증이나 구매 이력 집계를 테스트할 수 있다. 이 연결성이 마스킹과의 핵심 차이다.
따라서 레코드 간 동일 인물·고객의 연결성이 필요한 통합 테스트나 조인 검증에는 가명화가 맞고, 값 노출을 줄이는 화면 확인이나 제한적 샘플 검토에는 마스킹으로 충분할 수 있다. 그러나 어느 쪽도 개발 환경에 제약 없이 풀어놓을 수 있는 "정화된 데이터"는 아니다.
팀은 다음을 요구사항으로 문서화해야 한다.
- 어떤 필드가 직접 식별자, 민감 정보, 업무상 비밀인지 분류한다.
- 어떤 테스트가 원본의 분포·관계·예외값을 필요로 하는지 적는다.
- 변환 전 원본, 변환 규칙, 연결 키에 누가 접근하는지 분리한다.
- 테스트 종료 뒤 데이터셋을 언제 폐기하고, 백업과 로그에서 어떻게 제외하는지 정한다.
- 외부 AI 서비스나 개발 도구에 테스트 데이터가 전달되는 경로를 확인한다.
규제가 강하거나 민감정보를 다루는 서비스라면 가명화 데이터는 "허용된 통제 환경에서만 쓰는 제한 데이터"로 취급하는 편이 안전하다. 로컬 개발, 외부 협업, 에이전트 작업 공간, 공개 CI처럼 복제 경로가 넓은 환경에는 합성 데이터를 우선 검토한다. 이는 법적 판단이 아니라 노출 면적을 줄이기 위한 운영 선택이다.
데이터 모델을 AI 에이전트의 작업 계약으로 만든다
에이전트가 테스트 데이터를 만들 때 가장 흔한 실패는 스키마를 보고 필드를 채우는 데서 멈추는 일이다. status에 임의 문자열을 넣고, 외래 키(주문이 실제 고객을 가리키는 연결값)를 맞추지 못하고, 금액과 세금의 관계를 어기는 데이터가 생긴다. 테스트가 실패하면 에이전트는 제품 결함이 아니라 자신이 만든 데이터 결함을 고치느라 반복한다.
이를 막으려면 자연어 요구사항을 데이터 계약으로 바꿔야 한다. 계약에는 적어도 다음 요소가 들어간다.
- 엔터티와 관계: 고객 하나에 여러 주문이 연결되는지, 주문 취소 뒤 결제가 어떤 상태여야 하는지 정의한다.
- 유효 범위와 불변 조건: 수량이 음수가 될 수 없는지, 할인 합계가 주문 금액을 넘을 수 없는지 명시한다.
- 상태 전이: 결제 대기·승인·취소·환불처럼 가능한 전이와 금지 전이를 적는다.
- 결정성 규칙: 시드(seed, 난수의 시작값), 생성기 버전, 모델 버전을 고정해 같은 입력에서 같은 데이터가 나오게 한다.
- 기대 결과: 데이터 생성 성공만 확인하지 말고, 생성된 데이터로 어떤 API 응답·집계값·오류가 나와야 하는지 선언한다.
시드를 고정하면 CI에서 실패한 데이터셋을 개발자와 에이전트가 같은 형태로 다시 만들 수 있다. 다만 보안상 예측 불가능한 값이 필요한 테스트처럼 비결정성이 필요한 경우도 있다. 그런 테스트는 재현용 시드 테스트와 분리하고, 실패 시 입력 샘플과 생성 조건을 별도로 기록해야 한다.
에이전트에는 자유 형식의 데이터 생성 권한보다 좁은 인터페이스를 주는 편이 좋다. 에이전트가 데이터 모델 파일을 수정하고, 생성 도구가 구조 검증·제한된 샘플 실행·수용 조건 검사를 거친 뒤에만 데이터셋을 산출하게 만들 수 있다. 오류도 긴 로그 대신 "참조 무결성 위반", "허용되지 않은 상태값", "최소 생성 건수 미충족"처럼 구조화해 돌려주면 수정 범위가 줄어든다.
구현은 작은 경로부터 CI 게이트까지 이어 붙인다
첫 주기에 전사 테스트 데이터를 교체하려 하면 데이터 품질 논쟁만 길어진다. 개인정보 위험이 낮고 관계가 비교적 명확한 기능 하나를 골라 아래 순서로 시작하는 편이 낫다.
1단계: 데이터 사용 지도를 만든다
개발 리드와 보안·데이터 담당자가 테스트 환경, CI, 데모, 장애 재현, 분석용 샌드박스를 목록화한다. 각 환경마다 데이터 반입 경로, 외부 전송 가능성, 보관 기간, 접근 주체를 기록한다.
산출물: 환경별 데이터 흐름표, 필드 분류표, 테스트 목적 목록.
2단계: 대표 시나리오와 금지 시나리오를 고른다
정상 주문 한 건만 생성해서는 데이터 모델을 검증할 수 없다. 성공 흐름뿐 아니라 중복 요청, 부분 취소, 권한 없는 접근, 누락된 참조, 한도 초과처럼 제품이 거부해야 할 상태도 선택한다.
산출물: 시나리오 명세, 상태 전이표, 불변 조건 목록, 기대 오류 목록.
3단계: 방식별 데이터셋을 분리한다
단위 테스트에는 작고 읽기 쉬운 fixture를 둔다. 통합 테스트에는 시드가 고정된 합성 데이터셋을 생성한다. 운영 데이터와 가까운 검증이 꼭 필요할 때만 승인된 환경에서 가명화 또는 마스킹 데이터를 사용한다. 파일 이름과 저장소 위치만 나누는 것으로는 부족하다. 접근 권한, CI 실행 권한, 로그 출력 정책도 함께 분리해야 한다.
산출물: 데이터셋 카탈로그, 생성 설정, 접근 정책, 폐기 기준.
4단계: 생성 결과 자체를 테스트한다
합성 데이터 생성이 끝났다는 사실은 품질 보증이 아니다. 생성 후 다음 검사를 CI에 넣는다.
- 외래 키(주문이 실제 고객을 가리키는 연결값)와 복합 키(둘 이상의 열을 묶어 레코드를 식별하는 값)가 모두 연결되는가
- 상태 전이가 허용된 경로를 따르는가
- 금액·날짜·수량 등 불변 조건을 위반하지 않는가
- 민감 필드나 원본 식별자가 출력 파일과 로그에 남지 않는가
- 같은 시드와 모델 버전에서 콘텐츠 해시(생성 결과가 같은지 확인하는 지문값)가 일관되게 나오는가
- 애플리케이션의 핵심 API와 배치 작업이 기대 결과를 내는가
산출물: 데이터 검증 리포트, 실패 재현 정보, 생성물 식별자와 해시 기록.
5단계: 변경 승인과 예외 처리를 운영한다
업무 규칙이 바뀌면 데이터 모델도 코드와 같은 변경 대상으로 다뤄야 한다. PR에서 스키마 변경만 보는 대신, 어떤 시나리오가 추가·삭제됐는지와 기존 기대 결과가 왜 달라졌는지 검토한다. 운영 데이터를 가명화해 쓰는 예외 요청은 테스트 편의가 아니라 필요성, 접근 범위, 보관 기간, 대체 가능한 합성 모델 유무를 기준으로 승인해야 한다.
산출물: 데이터 모델 변경 이력, 예외 승인 기록, 릴리스별 재검토 목록.
잘못 설계됐다는 조기 신호를 놓치지 말아야 한다
에이전트가 테스트 실패 때마다 fixture 값을 바꾼다면 제품 규칙과 테스트 데이터 규칙이 분리되지 않은 상태일 수 있다. 데이터 값 수정이 허용되는 경우와 제품 코드 수정이 필요한 경우를 기대 결과로 구분해야 한다.
CI 실패를 로컬에서 재현할 수 없다면 난수, 시간, 외부 API 응답, 데이터 버전 중 하나가 통제되지 않았을 가능성이 크다. 실패 로그에 시드, 모델 버전, 생성 명령의 식별 정보, 실행 환경을 남겨 원인을 좁혀야 한다.
테스트 데이터가 현실적이라는 이유만으로 사람이 읽을 수 없게 커지면 리뷰 품질이 떨어진다. 모든 테스트에 대형 데이터셋을 쓸 필요는 없다. 코드 리뷰 단계에서는 최소 fixture, 야간 통합 검증에서는 큰 합성 데이터셋처럼 비용과 설명 가능성을 나누는 편이 낫다.
개인정보 스캔이 없거나 필드 분류가 수작업 목록에만 의존하면 새 컬럼과 로그 경로에서 누락이 생길 수 있다. 자동 탐지는 유용한 보조 수단이지만, 탐지 결과만으로 필드의 업무상 민감도나 반출 허용 여부를 결정할 수는 없다. 데이터 소유자가 분류와 예외를 검토하는 절차가 남아야 한다.
테스트 데이터 전략의 첫 산출물은 생성 도구가 아니다. 다음 스프린트에서 고칠 기능 하나를 골라, 그 기능의 상태 전이와 금지 조건을 열 줄 안팎의 명세로 적는 일부터 시작하면 된다. 그 명세를 fixture와 합성 모델 양쪽의 기준으로 쓰면 AI 에이전트도 추측 대신 검증 가능한 테스트 세계 안에서 일하게 된다.
