스테이징 데이터베이스에 현실적인 가짜 데이터 심기

스테이징 환경이 운영 환경과 닮아 있지 않으면, 그 환경에서 통과한 검증은 아무것도 보증하지 않습니다. 문제는 대부분 스키마가 아니라 데이터에서 시작됩니다. 테이블은 다 있는데 값이 비어 있거나, 값은 있는데 전부 같은 모양이거나, 모양은 그럴듯한데 서로 맞지 않는 상태입니다.

시드 데이터가 쓸 만하려면 무엇을 갖춰야 하나요?

세 가지 성질을 만족해야 합니다. 모양, 유일성, 그리고 참조 정합성입니다. 이 셋은 서로 다른 실패를 막고, 서로를 대신하지 못합니다.

모양이 맞는다는 것은 값의 종류와 길이와 범위가 실제 데이터와 같은 분포를 따른다는 뜻입니다. 그래야 문자열 길이 제한, 숫자 범위, 인코딩, 널 허용 여부 같은 조건이 스테이징에서도 실제로 시험됩니다. 값이 전부 짧고 ASCII라면 길이 초과와 다국어 문자 관련 결함은 운영에 배포된 뒤에야 드러납니다.

유일성이 있다는 것은 제약이 실제로 걸린다는 뜻입니다. 이메일과 계정 식별자 같은 열에 유니크 제약이 있는데 시드가 중복 값을 넣으면 적재 자체가 실패합니다. 반대로 유일해야 할 열이 시드에서는 우연히 겹치지 않아, 제약이 빠졌다는 사실을 아무도 모르는 채로 지나갈 수도 있습니다.

참조 정합성은 외래 키보다 넓은 개념입니다. 외래 키는 부모 행이 존재하는지만 확인하며, 두 테이블에 걸친 값이 서로 말이 되는지는 확인하지 않습니다.

채움용 문장이 버그를 숨기는 방식

가짜 데이터를 대충 만들면 지저분한 데이터가 아니라, 지저분한 데이터를 만들어 내는 코드의 결함을 가립니다. 전형적인 실패는 두 가지입니다.

첫째, 시드가 지나치게 균일합니다. 같은 이름이 수백 번 반복되고 주소가 한 종류뿐이면 페이지네이션이나 검색어 정렬을 시험할 수 없습니다. 정렬 기준 열이 모두 같은 값이면 순서는 우연히 맞고, 인덱스가 빠져 있어도 느린 쿼리는 드러나지 않습니다.

둘째, 시드가 지나치게 비현실적입니다. 문자열이 짧고 전부 영문이고 널이 거의 없으면, 실제 데이터에서만 나타나는 길이 초과, 공백과 결합 문자, 이모지, 누락된 선택 항목 같은 조건이 한 번도 실행되지 않습니다. 스테이징에서 초록불이었는데 운영에서 첫 페이지부터 터지는 전형적인 경로입니다.

또 하나 흔한 형태는 값은 그럴듯한데 서로 어긋나는 경우입니다. 사람의 나이와 가입 연도가 뒤집혀 있거나, 하위 행정 구역이 상위 행정 구역과 다른 나라에 속해 있는 식입니다. 이런 값은 조회 자체는 통과하지만, 화면과 보고서에서만 이상하게 보이기 때문에 발견이 늦습니다.

생성한 데이터와 마스킹한 운영 데이터는 어디에 쓰나요?

둘은 목적이 다릅니다. 생성한 데이터는 제약과 경로를 시험하는 데 강하고, 가린 운영 데이터는 실제 분포와 상관관계를 시험하는 데 강합니다. 한쪽만 있으면 나머지 절반의 결함이 보이지 않습니다.

가린 운영 데이터는 원본과의 연결을 끊는 작업이 다시 식별 가능성을 남기지 않을 때만 쓸 수 있습니다. 여러 열을 함께 보면 개인이 특정되는 조합이 남는 경우가 많고, 어떤 열은 가렸는데 다른 열이 사실상 식별자 역할을 하는 경우도 있습니다. 이 경계에 대한 판단은 시험용 합성 데이터와 익명화 데이터의 차이에서 더 자세히 다룹니다.

생성한 데이터 쪽에서는 값의 출처를 분명히 해 두는 것이 중요합니다. 어느 나라와 지역까지 다루는지, 어떤 필드가 서로 의존하는지는 국가별 자료를 확인해 정하되, 분포를 흉내 내려고 실제 통계를 그대로 옮길 필요는 없습니다. 스테이징에 필요한 것은 그럴듯한 분포이지 정확한 통계가 아닙니다.

같은 시드를 여러 번 돌려도 안전하게 만들려면?

시드는 여러 번 실행해도 결과가 같아야 합니다. 두 번 돌렸을 때 행이 두 배가 되면, 그 뒤의 모든 시험이 중복 데이터 위에서 돌아갑니다. 실무에서 쓰는 방법은 세 가지입니다.

• 전부 지우고 다시 넣기. 테이블별 삭제 순서를 정해야 하므로 외래 키가 많으면 관리가 어렵습니다.
• 자연 키 기준으로 덮어쓰기. 마이그레이션 도구가 자주 제공하는 방식이며, 자연 키 후보가 없으면 쓸 수 없습니다.
• 시드 변경을 버전으로 기록하기. 어떤 버전이 이미 적용됐는지 확인하고, 달라졌을 때만 적용합니다.

어느 방법을 쓰든 자연 키가 필요합니다. 자연 키는 업무적으로 고유한 값이고, 대리 키는 적재할 때마다 새로 생기므로 기준이 될 수 없습니다. 자연 키가 마땅치 않으면 시드가 만든 값에 고정 접두사를 붙여 시드 소유임을 표시하고, 그 접두사로 정리하는 편이 낫습니다.

시드가 만든 행을 표시해 두는 것은 다른 이유에서도 유용합니다. 스테이징에서 문제가 생겼을 때, 어떤 행이 시험용인지 즉시 구분할 수 있습니다.

볼륨과 배치 크기는 어떻게 정하나요?

정답은 환경의 목적에 따라 달라집니다. 다만 몇 가지 원칙은 일반적입니다.

첫째, 목록 화면을 시험한다면 목록이 두 페이지 이상 되어야 합니다. 한 페이지에 들어가는 양만 넣으면 페이지네이션 코드 경로가 한 번도 실행되지 않습니다. 정렬과 필터가 있다면 그 기준 열에도 값의 분포가 있어야 합니다.

둘째, 적재는 한 번에 밀어 넣기보다 묶음으로 나누는 편이 좋습니다. 묶음 크기를 정하는 기준은 트랜잭션 크기와 작업 시간입니다. 너무 크면 실패 시 되돌리는 비용이 커지고, 너무 작으면 전체 적재 시간이 길어집니다.

셋째, 어느 쪽이든 실행 시간이 예측 가능해야 합니다. 적재가 끝나는 시점을 알 수 없으면 배포 파이프라인에 넣을 수 없습니다.

외래 키만으로는 부족한 참조 정합성

외래 키는 부모 행의 존재를 확인합니다. 그런데 스테이징에서 실제로 문제를 일으키는 것은 존재하지 않는 부모가 아니라, 존재하지만 서로 맞지 않는 조합입니다.

대표적인 경우가 지역 정보입니다. 하위 행정 구역이 상위 행정 구역과 다른 나라에 속하거나, 국가 코드와 전화 국가 번호가 어긋나거나, 우편번호가 해당 도시에 존재하지 않는 식입니다. 데이터베이스는 이 모든 조합을 정상으로 받아들입니다.

이 문제를 막는 방법은 시드를 만들 때 부모에서 자식으로 내려가며 만드는 것입니다. 자식의 값을 따로 난수로 뽑지 않고 부모의 값에서 파생시키면, 애초에 어긋난 조합이 생길 수 없습니다. 이렇게 하면 검증을 사후에 하는 대신 생성 단계에서 구조적으로 막을 수 있습니다.

만들어 낸 데이터가 알려 주지 못하는 것

생성한 데이터에는 한계가 있습니다. 실제 사용자가 만드는 순서와 빈도, 오래된 계정에만 남아 있는 예외 값, 여러 해에 걸쳐 쌓인 마이그레이션의 흔적은 만들어 낼 수 없습니다. 스테이징이 아무리 현실적으로 보여도 이런 부분은 비어 있습니다.

그래서 시드가 초록불을 준 결과를 “운영에서도 안전하다”는 근거로 쓰면 안 됩니다. 시드가 보증하는 것은 스키마와 코드 경로가 그 값 조합에서 동작한다는 사실까지입니다. 회귀 시나리오와 데모 재현에 필요한 고정 표본을 어떻게 관리할지는 테스트 픽스처 안의 신원 데이터에서, 필드 사이의 의존 관계는 신원 데이터 일관성에서 이어서 볼 수 있습니다. 처음부터 훑으려면 테스트 신원 데이터란 무엇인가가 좋은 출발점이고, 가짜 데이터와 익명화 데이터의 경계는 합성 데이터와 익명화에서 이어서 볼 수 있습니다.

다음 단계

가장 먼저 할 일은 지금 스테이징에 들어 있는 데이터의 나이와 출처를 확인하는 것입니다. 출처를 모르는 값이 섞여 있다면 그 자체가 위험 신호입니다. 다음으로 시드를 두 번 연속 실행해 보고 행 수가 늘어나는지 확인하세요. 늘어난다면 자연 키를 정하는 일이 다음 작업이 됩니다. 값의 종류와 분포는 신원 데이터 도구에서 나라와 성별을 지정해 바로 만들어 볼 수 있으며, 같은 식별자를 쓰면 언제 실행해도 같은 값이 나오므로 고정 표본을 만들 때 편합니다. 주소 형식과 지역 정보를 함께 맞춰야 한다면 주소 도구도 참고하세요.

이 글은 스테이징 데이터베이스에 넣을 시드를 어떻게 설계하고 검증할지에 대한 실무 정리이며, 예시로 언급한 값과 식별자는 모두 설명을 위해 만들어진 가상의 것입니다. 실제 서비스의 데이터나 살아 있는 사람의 정보를 대신하지 않습니다.