개념
왜 테스트 데이터가 문제가 되는가
테스트를 실행할 때마다 "이 계정에 주문 내역이 있어야 하는데 없다", "어제는 됐는데 오늘은 이 데이터가 사라졌다" 같은 문제를 겪어본 적이 있다면, 그건 테스트 로직이 아니라 테스트 데이터 관리의 문제다. 데이터가 불안정하면 그 위에서 도는 어떤 테스트도 신뢰할 수 없다.
접근 1 — 합성 데이터(Synthetic Data)
실제 운영 데이터를 쓰지 않고, 테스트 목적에 맞게 처음부터 만들어낸 데이터다. 장점은 개인정보 위험이 없고, 원하는 조건(예: "쿠폰이 3개 있고 등급이 VIP인 사용자")을 정확히 맞출 수 있다는 것이다. 단점은 실제 데이터의 지저분함(빈 값, 이상한 형식, 예상 못 한 조합)을 못 재현할 수 있다는 것이다.
접근 2 — 운영 데이터 마스킹(Data Masking)
실제 운영 데이터를 복사해오되, 이름·이메일·전화번호·주민번호 같은 민감정보를 가짜 값으로 치환해서 쓰는 방식이다. 실제 데이터의 지저분함을 그대로 재현할 수 있다는 장점이 있지만, 마스킹이 불완전하면 개인정보 유출 사고로 이어질 수 있어 각별히 주의해야 한다.
이름을 "홍길동"으로 일괄 치환해도, 주소나 결제 내역 같은 다른 필드에 개인을 특정할 수 있는 정보가 남아있다면 마스킹이 완전하지 않은 것이다.
접근 3 — 시딩(Seeding)과 리셋(Reset)
테스트를 실행하기 전에 필요한 데이터를 스크립트로 미리 넣어두는 것을 시딩이라 하고, 테스트가 끝난 후 데이터를 원래 상태로 되돌리는 것을 리셋이라 한다.
[리셋: 초기 상태로] → [시딩: 필요한 데이터 주입] → [테스트 실행] → [리셋]이 사이클이 안정적이어야 "어제는 됐는데 오늘은 안 된다"는 재현 불가능한 실패(모듈 5 레슨 12와 연결)를 줄일 수 있다. 시딩·리셋이 불안정하면 테스트 실패의 원인이 코드 결함인지 데이터 오염인지 구분하기 어려워진다.
데이터 격리(Isolation)
여러 사람 또는 여러 자동화 테스트가 동시에 같은 데이터베이스를 쓰면, 한쪽이 만든 데이터를 다른 쪽이 지우거나 바꿔서 서로 간섭할 수 있다. 테스트마다 독립된 데이터(별도 계정, 별도 스키마, 트랜잭션 롤백 등)를 쓰도록 격리하는 것이 안정적인 테스트의 전제조건이다.
실무에서 왜 필요한가
테스트 자동화(스테이지 4에서 본격적으로 다룬다)가 도입될수록 테스트 데이터 문제가 더 크게 드러난다 — 수동 테스트는 사람이 그때그때 데이터를 맞춰가며 진행할 수 있지만, 자동화된 테스트는 데이터가 항상 예측 가능한 상태여야 안정적으로 돈다. 테스트 데이터 관리가 부실하면 "자동화했더니 오히려 실패가 더 늘었다"는 흔한 실패 사례로 이어진다. 개인정보 마스킹 원칙을 모르고 운영 데이터를 그대로 테스트 환경에 복사하는 것은 실무에서 실제 보안 사고로 이어진 사례가 많은 지점이다.
실습 과제
과제 1 — 합성 데이터 vs 마스킹 판단하기 (10분)
다음 세 가지 테스트 상황에 합성 데이터와 마스킹된 운영 데이터 중 어느 쪽이 더 적합할지 판단하고 이유를 적는다.
- "VIP 등급이면서 쿠폰이 정확히 2개인 사용자"의 결제 화면을 테스트해야 한다
- 지난달 실제 사용자들이 겪었던 것과 비슷한, 다양하고 지저분한 주소 형식으로 배송 시스템을 테스트해야 한다
- 신규 기능이라 아직 운영 데이터 자체가 존재하지 않는다
과제 2 — 시딩·리셋 시나리오 설계 (10분)
"쿠폰 적용 후 주문" 기능을 테스트하기 위해 테스트 실행 전 시딩해야 할 데이터(사용자, 쿠폰, 상품 등)를 나열하고, 테스트 후 어떤 데이터를 리셋해야 다음 테스트에 영향을 안 주는지 적는다.
자가 체크리스트
- 합성 데이터와 마스킹된 운영 데이터의 장단점을 비교해 설명할 수 있다
- 마스킹이 불완전할 때 생기는 위험을 설명할 수 있다
- 시딩과 리셋이 왜 필요한지, 이 사이클이 불안정할 때 생기는 문제를 설명할 수 있다
- 데이터 격리가 왜 안정적인 테스트의 전제조건인지 설명할 수 있다
흔한 실수
- 운영 데이터를 마스킹 없이 그대로 테스트 환경에 복사한다. 개인정보 유출로 이어질 수 있는 심각한 보안 사고다.
- 시딩·리셋 없이 수동으로 데이터를 맞춰가며 테스트한다. 반복 실행할수록 데이터가 오염되고, 실패 원인 파악이 어려워진다.
- 여러 테스트가 같은 데이터를 공유해서 서로 간섭한다. 격리 없이는 테스트 결과 자체를 신뢰할 수 없다.
참고 자료
- ISTQB Glossary — Test Data — 테스트 데이터의 공식 정의
- OWASP — Data Masking 가이드 — 개인정보 마스킹의 실무 기준(보안 관점)