AI 테스트 데이터 시드

AI에게 기능 구현을 맡기면 화면과 API는 빠르게 생깁니다. 하지만 테스트 데이터가 매번 즉흥적으로 만들어지면 같은 버그를 두 번 확인할 수 없습니다. 오늘은 "김철수 한 명", 내일은 "테스트 유저 여러 명", 모레는 운영 데이터 일부를 복사한 샘플로 검증하면, 실패가 코드 문제인지 데이터 문제인지 판단하기 어려워집니다. VIBE 코딩에서 테스트 데이터는 부록이 아니라 AI가 만든 변경을 믿을 수 있게 만드는 실행 기반입니다.

초보자는 시드 데이터를 "테스트를 시작할 때 미리 깔아 두는 연습용 데이터"라고 이해하면 됩니다. 실무자에게는 더 구체적입니다. 고정 난수로 같은 데이터를 다시 만들고, 개인정보는 익명화하고, fixture와 팩토리로 케이스를 재사용하며, 권한 조합·경계값·상태 전이를 데이터 계약으로 고정해야 합니다. 그래야 AI 에이전트가 만든 코드가 어느 조건에서 통과했고 어느 조건에서 깨졌는지 반복 검증할 수 있습니다.

핵심 결론

AI 테스트 데이터 시드 루프의 목표는 "많은 더미 데이터"가 아니라 "재현 가능한 실패와 검증 가능한 성공"입니다. AI에게 기능을 만들게 하기 전에, 이번 기능이 반드시 통과해야 하는 데이터 모양을 먼저 정합니다. 정상 케이스 하나, 경계값 두세 개, 권한 조합, 실패 상태, 오래된 데이터, 비어 있는 데이터, 정리 단계까지 포함한 작은 데이터 세트를 만듭니다. 이 데이터는 매번 같은 입력에서 같은 결과가 나오도록 고정 난수와 명시적 ID를 사용하고, 실제 사용자 정보처럼 보이는 값은 익명화된 가짜 값으로만 둡니다.

좋은 시드 루프는 네 가지 질문에 답합니다. 첫째, 이 기능이 어떤 데이터 계약을 기대하는가. 둘째, AI가 만든 코드가 어떤 fixture에서 성공해야 하는가. 셋째, 어떤 경계값과 권한 조합에서 실패하거나 차단되어야 하는가. 넷째, 테스트가 끝난 뒤 데이터가 어떻게 정리되어 다음 실행을 오염시키지 않는가. 이 네 질문을 AI 작업 지시서에 넣으면 에이전트는 구현만 하는 것이 아니라 검증 가능한 환경까지 함께 설계하게 됩니다.

실무에서는 시드 데이터를 세 층으로 나누면 안전합니다. 첫 번째는 단위 테스트용 팩토리입니다. 객체 하나를 빠르게 만들고 필요한 필드만 덮어씁니다. 두 번째는 통합 테스트용 fixture입니다. 사용자, 프로젝트, 권한, 결제 상태, 알림 상태처럼 여러 엔티티가 연결된 장면을 한 번에 만듭니다. 세 번째는 브라우저 또는 E2E 스모크용 공개 시나리오입니다. 실제 사용자가 보는 흐름을 따라갈 수 있도록 로그인 전후, 빈 상태, 오류 상태, 완료 상태를 대표 데이터로 구성합니다.

왜 중요한가

AI 코드는 데이터가 바뀌면 다른 코드처럼 보인다

AI 에이전트는 주어진 예시를 강하게 따라갑니다. 예시 데이터가 항상 정상 사용자 한 명뿐이면 권한 없는 사용자, 삭제된 항목, 만료된 초대, 빈 목록, 너무 긴 제목, 다국어 입력, 시간대 차이를 놓치기 쉽습니다. 테스트가 통과해도 실제 서비스에서 바로 깨지는 이유가 여기에 있습니다. 코드가 나빠서만이 아니라 검증 데이터가 너무 착해서 문제가 숨는 것입니다.

시드 데이터는 AI에게 "이런 조건까지 책임져야 한다"고 알려 주는 구체적인 언어입니다. 요구사항을 긴 문장으로 쓰는 것보다, 권한 없는 사용자 fixture와 만료된 초대 fixture를 두는 편이 더 명확할 때가 많습니다. AI가 코드를 수정할 때도 테스트 데이터가 있으면 추측이 줄어듭니다. 실패한 fixture 이름이 "expired-invitation-cannot-join"처럼 되어 있으면, 에이전트는 어디를 봐야 하는지 바로 알 수 있습니다.

재현 가능한 실패가 없으면 디버깅이 대화 싸움이 된다

AI에게 "아까는 됐는데 지금은 안 돼"라고 말하면 대화는 길어집니다. 에이전트는 로그를 추측하고, 사용자는 화면을 다시 설명하고, 중간에 다른 파일이 바뀌면서 원인이 흐려집니다. 반대로 시드 데이터와 회귀 테스트가 있으면 대화가 짧아집니다. "이 fixture에서 이 테스트가 실패한다"가 되기 때문입니다. 재현 가능한 실패는 사람과 AI가 같은 화면을 보게 만드는 최소 단위입니다.

특히 상태 전이가 있는 기능에서 효과가 큽니다. 예를 들어 문의가 접수됨, 처리 중, 답변 완료, 숨김, 재시도 필요 같은 상태를 가진다면 각 상태별 데이터가 있어야 합니다. AI가 새 버튼을 만들거나 목록 필터를 고칠 때 모든 상태를 직접 클릭해 보지 않아도 테스트가 상태별 기대 결과를 알려 줍니다. 이때 상태명은 내부 구현명을 그대로 노출하기보다 테스트와 서비스 언어를 분리해 관리해야 합니다.

운영 데이터 복사는 빠르지만 위험하다

실제 데이터를 복사해 테스트하면 그럴듯해 보입니다. 하지만 개인정보, 결제 정보, 민감한 메모, 내부 식별자가 섞일 수 있고, 데이터 크기가 커져 테스트가 느려지며, 특정 시점의 우연한 상태에 테스트가 묶입니다. VIBE 코딩에서는 AI에게 운영 데이터 덤프를 던지는 습관을 피해야 합니다. 필요한 것은 실제 데이터가 아니라 실제 조건을 닮은 익명화된 최소 데이터입니다.

익명화는 이름만 바꾸는 일이 아닙니다. 이메일, 전화번호, 주소, 토큰처럼 보이는 문자열, 외부 계정 ID, 결제 참조값, 고객 메모, 파일명, 이미지 URL까지 확인해야 합니다. 또한 실제 데이터 분포를 흉내 내더라도 개인을 재식별할 수 있는 조합을 남기면 안 됩니다. 테스트 데이터는 독자가 봐도 안전한 샘플이어야 하고, AI가 결과 보고에 붙여도 문제가 없어야 합니다.

실제 작업 순서

1단계: 기능보다 데이터 계약을 먼저 적는다

AI 작업 지시서의 첫 줄을 "이 기능을 만들어줘"로 시작하지 말고 "이 기능은 다음 데이터 계약에서 동작해야 한다"로 시작합니다. 데이터 계약에는 필수 필드, 선택 필드, 권한, 상태, 시간 조건, 정렬 기준, 비어 있는 상태, 오류 상태를 넣습니다. 예를 들어 팀 초대 기능이라면 사용자 역할, 초대 만료 시간, 이미 가입한 이메일, 초대 취소 상태, 초대 가능한 팀 한도, 화면에 보여야 하는 안내 문구가 계약입니다.

이 단계에서 중요한 것은 모든 경우를 만들려 하지 않는 것입니다. 처음부터 100개 케이스를 만들면 AI도 사람도 핵심을 잃습니다. 대표 정상 케이스 1개, 가장 위험한 실패 케이스 2개, 경계값 2개, 권한 조합 2개 정도로 시작합니다. 이후 버그가 발견될 때마다 해당 버그를 재현하는 fixture를 하나씩 추가합니다. 시드 데이터는 백과사전이 아니라 살아 있는 회귀 방지 장치입니다.

2단계: 팩토리와 fixture의 역할을 나눈다

팩토리는 작은 부품을 만드는 도구입니다. 사용자 하나, 프로젝트 하나, 주문 하나처럼 기본값이 있는 객체를 만들고 필요한 값만 덮어씁니다. fixture는 실제 장면을 만드는 묶음입니다. 예를 들어 "팀 소유자 1명, 편집자 2명, 읽기 전용 사용자 1명, 만료된 초대 1개, 최근 활동 3개"처럼 여러 팩토리를 조합합니다. AI에게 이 차이를 알려 주면 테스트 데이터가 덜 중복되고 유지보수가 쉬워집니다.

좋은 팩토리는 기본값이 안전합니다. 이름은 가짜이고, 날짜는 고정되어 있으며, ID는 읽기 쉽고, 외부 서비스 호출은 포함하지 않습니다. 좋은 fixture는 의도가 이름에 드러납니다. "empty-project-dashboard", "viewer-cannot-edit-billing", "expired-trial-shows-upgrade"처럼 실패 조건과 기대 행동을 함께 담습니다. 이름이 명확하면 AI가 실패 로그를 읽고 잘못된 기능을 더 빨리 찾습니다.

3단계: 고정 난수와 명시적 시간을 사용한다

테스트 데이터가 실행할 때마다 달라지면 회귀 테스트가 불안정해집니다. 오늘 통과한 정렬 테스트가 내일 실패하거나, 무작위 제목 길이 때문에 스냅샷이 흔들릴 수 있습니다. 그래서 난수가 필요하다면 고정 난수를 쓰고, 시간은 현재 시간이 아니라 명시적 기준 시간을 사용합니다. "2026년 4월 28일 09:00 UTC를 기준으로 7일 전, 1시간 후"처럼 계산하면 테스트가 언제 실행되어도 같은 의미를 유지합니다.

시간 관련 기능은 특히 조심해야 합니다. 만료, 예약, 알림, 리포트 집계, 구독 갱신은 시간대와 날짜 경계에서 자주 깨집니다. AI에게 "현재 시간으로 처리"라고 맡기면 로컬과 배포 환경의 시간대 차이를 놓칠 수 있습니다. 작업 지시서에는 기준 시간, 사용자 시간대, 서버 저장 형식, 화면 표시 형식, 경계 시나리오를 명시합니다.

4단계: 권한 조합과 상태 전이를 먼저 고정한다

AI가 만든 기능은 관리자 또는 정상 사용자 흐름에서만 테스트되기 쉽습니다. 하지만 실제 장애는 권한이 낮은 사용자, 초대만 받은 사용자, 결제가 만료된 사용자, 삭제 직전의 항목, 처리 중인 작업처럼 애매한 상태에서 발생합니다. 따라서 시드 데이터에는 권한 조합과 상태 전이를 반드시 넣습니다. 권한 조합은 "볼 수 있음", "수정 가능", "요청 가능하지만 승인 필요", "아예 접근 불가"처럼 사용자 언어로 설명합니다.

상태 전이는 현재 상태뿐 아니라 이동 가능한 다음 상태를 포함해야 합니다. 주문은 생성됨에서 결제됨으로 갈 수 있지만 취소됨에서 결제됨으로 가면 안 됩니다. 문의는 답변 완료 후 다시 열릴 수 있는지, 숨김 처리된 항목이 공개 목록에 나오는지, 실패한 작업을 다시 시도할 수 있는지 정책이 필요합니다. 이 정책이 데이터와 테스트에 없으면 AI는 화면에서 보이는 버튼만 보고 잘못된 전이를 허용할 수 있습니다.

5단계: 회귀 테스트와 브라우저 스모크를 연결한다

시드 데이터는 테스트 코드 안에서만 의미가 있으면 반쪽입니다. 사용자에게 보이는 기능이라면 브라우저 스모크에서도 같은 대표 데이터를 볼 수 있어야 합니다. 예를 들어 목록 페이지는 빈 상태, 1개 상태, 여러 페이지 상태를 확인하고, 상세 페이지는 권한 있는 사용자와 권한 없는 사용자의 차이를 확인합니다. API만 있는 기능도 최소한 요청과 응답의 데이터 계약을 확인해야 합니다.

스냅샷은 신중하게 씁니다. 화면 전체 스냅샷을 무조건 저장하면 작은 문구 변화에도 테스트가 깨져 유지보수 비용이 커집니다. 대신 중요한 마커, 상태 라벨, 버튼 존재 여부, 접근 불가 메시지, 정렬 순서처럼 사용자가 실제로 의존하는 결과를 검증합니다. AI에게는 "스냅샷을 늘리지 말고 사용자 결정에 영향을 주는 마커를 검증하라"고 지시합니다.

6단계: 정리 단계를 자동화한다

테스트 격리가 없으면 한 테스트가 만든 데이터가 다음 테스트를 오염시킵니다. 특히 데이터베이스나 파일 저장소를 쓰는 통합 테스트에서 흔합니다. 정리 단계는 테스트 끝에 남은 레코드, 업로드 파일, 캐시, 큐 작업, 알림 기록을 지웁니다. 더 안전한 방식은 테스트마다 독립된 네임스페이스나 트랜잭션을 쓰고, 실패해도 다음 실행이 같은 출발점에서 시작되게 만드는 것입니다.

AI에게 테스트를 만들게 할 때는 "정리 단계까지 포함하라"고 명시해야 합니다. 에이전트는 통과만 보고 임시 데이터를 남길 수 있습니다. 이런 데이터가 쌓이면 로컬에서는 우연히 통과하지만 CI나 배포 전 검증에서는 실패합니다. 정리 단계는 눈에 띄지 않지만, VIBE 코딩에서 반복 가능한 자동화의 핵심입니다.

상황별 예시

새 기능을 만드는 경우

예를 들어 프로젝트 초대 기능을 만든다고 가정합니다. AI에게 바로 초대 API와 화면을 만들게 하지 않습니다. 먼저 시드 데이터로 팀 소유자, 편집자, 읽기 전용 사용자, 이미 초대된 이메일, 만료된 초대, 팀 정원 초과 상태를 만듭니다. 그다음 테스트는 소유자가 새 초대를 보낼 수 있는지, 읽기 전용 사용자는 보낼 수 없는지, 만료된 초대는 다시 요청해야 하는지, 이미 가입한 이메일은 중복 초대가 막히는지 확인합니다.

이 방식은 개발 속도를 늦추지 않습니다. 오히려 AI가 어떤 조건을 구현해야 하는지 정확히 알게 되어 재작업이 줄어듭니다. 화면 문구도 데이터에 맞춰 자연스럽게 정리됩니다. 빈 상태에는 "초대된 멤버가 없습니다"가 나오고, 권한 부족에는 "소유자에게 요청하세요"가 나오며, 만료 상태에는 "새 초대를 요청하세요"가 나옵니다. 테스트 데이터가 곧 UX 요구사항이 됩니다.

기존 버그를 고치는 경우

버그 수정에서는 재현 가능한 실패를 먼저 만듭니다. 예를 들어 결제 만료 사용자가 대시보드에서 일부 카드만 봐야 하는데 전체 카드가 보이는 문제가 있다면, 만료 사용자 fixture와 활성 사용자 fixture를 분리합니다. 테스트는 만료 사용자에게 업그레이드 안내는 보이고 결제 카드 수정 버튼은 보이지 않아야 한다고 고정합니다. 이 실패를 본 뒤 AI에게 수정하게 하면 변경 범위가 좁아집니다.

중요한 점은 버그를 설명하는 스크린샷만으로 끝내지 않는 것입니다. 스크린샷은 증거지만 회귀 방지 장치는 아닙니다. 시드 데이터와 테스트가 있어야 같은 버그가 다시 들어왔을 때 자동으로 잡힙니다. AI가 비슷한 컴포넌트를 리팩터링하거나 권한 로직을 정리할 때도 이 fixture가 안전망이 됩니다.

데이터가 많은 목록을 다루는 경우

검색, 필터, 페이지네이션, 정렬은 테스트 데이터 품질의 영향을 크게 받습니다. 항목이 3개뿐이면 페이지네이션 버그가 보이지 않고, 모두 같은 날짜면 정렬 버그가 보이지 않으며, 같은 권한 사용자만 있으면 필터 누락이 보이지 않습니다. 이때는 작지만 의도적인 데이터 분포가 필요합니다. 날짜가 다른 항목, 동일한 제목 일부, 숨김 상태, 완료 상태, 긴 제목, 특수문자 제목, 권한별 노출 차이를 넣습니다.

AI에게 목록 기능을 맡길 때는 "많은 데이터"가 아니라 "검증하려는 차이를 드러내는 데이터"를 요구합니다. 1,000개 더미보다 12개의 의도적 fixture가 더 강합니다. 페이지 경계가 10개라면 11개 항목을 만들고, 정렬이 중요하면 같은 날짜와 다른 날짜를 섞으며, 검색이 중요하면 한글·영문·숫자 조합을 넣습니다. 이런 데이터는 테스트를 읽는 사람에게도 기능 의도를 설명합니다.

외부 API 연동을 다루는 경우

외부 API를 테스트할 때 실제 서비스를 계속 호출하면 느리고 불안정합니다. 대신 응답 fixture를 만듭니다. 성공 응답, 인증 실패, 속도 제한, 빈 결과, 부분 실패, 오래된 스키마 응답을 분리합니다. 이때 응답 fixture에는 실제 토큰이나 고객 식별자가 들어가면 안 됩니다. AI에게 응답 예시를 만들게 할 때도 공개 가능한 가짜 값만 사용하도록 제한합니다.

실무에서는 외부 API 응답이 바뀌는 순간을 놓치지 않기 위해 계약 테스트를 둡니다. 우리가 기대하는 필드와 타입을 확인하고, 필드가 없어졌을 때 사용자에게 어떤 메시지를 보여줄지 정합니다. AI가 연동 코드를 수정할 때 이 계약 테스트가 있으면, 공식 예제만 보고 낙관적으로 구현하는 일을 줄일 수 있습니다.

실수와 주의점

첫 번째 실수는 운영 데이터를 그대로 테스트에 가져오는 것입니다. 빠르게 재현하려는 마음은 이해되지만 위험합니다. 실제 이메일, 전화번호, 주소, 결제 참조, 내부 메모, 파일 URL, 외부 계정 ID가 섞이면 공개 저장소나 테스트 로그에 남을 수 있습니다. 필요한 조건만 추출해 익명화된 fixture로 바꾸고, 원본을 보관하지 않는 습관이 필요합니다.

두 번째 실수는 무작위 데이터를 많이 만들면 검증이 강해진다고 믿는 것입니다. 무작위는 탐색에는 도움이 될 수 있지만 기본 회귀 테스트에는 불안정성을 만듭니다. 무작위를 쓰더라도 고정 난수와 실패 시 seed 값 기록이 있어야 합니다. 평소 테스트는 의도적인 경계값을 중심으로 만들고, 별도의 탐색 테스트에서만 넓은 무작위를 사용합니다.

세 번째 실수는 fixture를 너무 현실처럼 크게 만드는 것입니다. 실제 서비스처럼 많은 엔티티를 다 넣으면 테스트가 느려지고 실패 원인이 흐려집니다. 좋은 fixture는 작지만 날카롭습니다. 버그를 드러내는 필드만 남기고 나머지는 팩토리 기본값에 맡깁니다. 한 테스트가 여러 정책을 동시에 검증한다면 fixture를 나누는 편이 낫습니다.

네 번째 실수는 테스트 정리를 사람 기억에 맡기는 것입니다. 로컬에서 한 번 실행하고 남은 데이터가 다음 테스트를 통과시키는 경우가 있습니다. 이런 테스트는 CI에서 실패하거나, 다른 개발자 환경에서 깨집니다. 테스트 격리와 정리 단계는 구현만큼 중요합니다. 데이터베이스를 쓴다면 테스트 전후 상태를 명확히 하고, 파일이나 캐시를 쓴다면 네임스페이스를 분리합니다.

다섯 번째 실수는 시드 데이터 이름을 내부 구현 중심으로 짓는 것입니다. "status-3-user-2" 같은 이름은 실패 로그를 읽는 데 도움이 되지 않습니다. "viewer-cannot-delete-project"처럼 사용자 행동과 기대 결과가 드러나야 합니다. 그래야 AI도 실패를 보고 의도를 이해합니다. 좋은 이름은 테스트 문서의 절반입니다.

검증 체크리스트

AI에게 테스트 데이터 시드 루프를 맡긴 뒤에는 다음 항목을 확인합니다.

• 이번 기능의 데이터 계약이 사용자 역할, 상태, 시간, 경계값, 오류 상태를 포함하는가.
• 시드 데이터가 운영 데이터 복사가 아니라 익명화된 가짜 값으로 구성되어 있는가.
• 고정 난수와 명시적 기준 시간을 사용해 실행할 때마다 같은 결과가 나오는가.
• 팩토리와 fixture가 분리되어 중복 없이 의도를 표현하는가.
• 권한 조합과 상태 전이가 테스트 이름과 데이터 이름에 드러나는가.
• 회귀 테스트가 재현 가능한 실패를 먼저 보여 주고, 수정 후 같은 데이터로 통과하는가.
• 브라우저 스모크가 사용자가 보는 핵심 마커를 확인하는가.
• 스냅샷이 화면 전체가 아니라 사용자 결정에 중요한 결과를 검증하는가.
• 테스트 격리와 정리 단계가 자동화되어 다음 실행을 오염시키지 않는가.
• AI 작업 지시서에 금지 데이터, 검증 명령, 실패 시 보고 형식이 포함되어 있는가.

이 체크리스트는 모든 프로젝트에 같은 도구를 쓰라는 뜻이 아닙니다. 어떤 팀은 단순 JSON fixture로 충분하고, 어떤 팀은 데이터베이스 트랜잭션과 브라우저 테스트가 필요합니다. 중요한 것은 도구가 아니라 반복성입니다. 같은 입력, 같은 기준 시간, 같은 권한 조합에서 같은 결과가 나와야 AI 코딩의 속도가 신뢰로 바뀝니다.

다음 단계

첫 실행은 작게 시작합니다. 이번 주에 가장 자주 깨지는 기능 하나를 고르고, 그 기능을 설명하는 fixture 3개를 만듭니다. 정상 케이스, 가장 위험한 권한 실패, 날짜나 수량의 경계값을 고릅니다. 그런 다음 AI에게 구현을 바꾸기 전에 이 fixture로 실패하는 테스트를 만들게 합니다. 실패를 확인한 뒤 최소 수정으로 통과시키고, 테스트 데이터 이름과 정리 단계를 리뷰합니다.

두 번째 단계는 팀의 공통 언어를 만드는 것입니다. "fixture", "팩토리", "시드 데이터", "경계값", "권한 조합", "상태 전이", "정리 단계"라는 단어가 작업 지시서와 리뷰 코멘트에 반복되게 합니다. AI에게도 같은 표현을 사용합니다. 표현이 통일되면 에이전트가 만든 테스트를 사람이 더 빨리 검토하고, 사람의 피드백도 다음 작업에 재사용하기 쉬워집니다.

세 번째 단계는 실패한 버그를 시드 라이브러리로 승격하는 것입니다. 운영에서 발견된 버그를 고칠 때마다 "이 버그를 다시 만들 수 있는 최소 fixture는 무엇인가"를 묻습니다. 버그가 재현 가능한 데이터가 되면 다음부터는 같은 유형의 변경을 AI에게 더 안전하게 맡길 수 있습니다. VIBE 코딩의 성숙도는 얼마나 멋진 프롬프트를 쓰는지가 아니라, 실패를 얼마나 빠르게 재현 가능한 자산으로 바꾸는지에서 드러납니다.