지금도 등 뒤가 서늘해지는 기억이 하나 있습니다. 금융권 차세대 프로젝트 막바지였을 겁니다. 테스트할 데이터가 부족하다는 이유로, 운영 서버의 DB 덤프를 떠서 개발 서버에 그대로 부어버린 적이 있습니다.
"주민번호랑 전화번호만 마스킹하면 되겠지."
그 안일한 생각이 화근이었습니다. 주소 컬럼에 고객의 상세 주소가 그대로 남아있었고, 특이 사항을 적는 비고란에 상담원이 적어둔 고객의 민감한 가족 관계가 텍스트로 박혀 있었습니다. 다음 날 아침, 보안 감사팀에서 호출이 왔습니다. 불려 가서 경위서를 쓰고, 데이터 파기 확인서를 작성하고, 팀장님께 깨지는 동안 저는 개발자로서의 자존감이 바닥을 치는 걸 느꼈습니다.
그날 이후로 저는 후배들에게 입이 닳도록 말합니다. "운영 데이터는 쳐다보지도 마라."
하지만 딜레마는 여전합니다. 로직을 검증하려면 '리얼한' 데이터가 필요합니다. 그렇다고 `test1`, `test2` 같은 더미 데이터만 넣고 돌리면, 꼭 오픈 당일에 예상치 못한 엣지 케이스(Edge Case)가 터져서 장애가 납니다. 그렇다고 시드(Seed) 스크립트를 한 땀 한 땀 짜자니, 스키마가 바뀔 때마다 유지보수하는 게 지옥입니다. 코드는 자산이 아니라 부채라고 누누이 말하지만, 테스트 데이터 관리 스크립트야말로 악성 부채 중의 악성 부채입니다.
최근 해커뉴스에서 흥미로운 도구를 하나 봤습니다. 'DDL to Data'라는 녀석입니다.
이 도구의 접근 방식은 단순하지만, 우리가 겪는 고통의 본질을 정확히 찌르고 있습니다. SQL 스키마(CREATE TABLE 문)를 던져주면, 그걸 파싱해서 현실적인 테스트 데이터를 만들어줍니다.
단순히 랜덤 문자열을 채우는 게 아닙니다. 이메일 컬럼은 이메일 형식으로, 타임스탬프는 합리적인 시간 범위 내에서, 무엇보다 중요한 외래 키(Foreign Key) 관계를 깨뜨리지 않고 데이터를 생성해 줍니다.
우리가 테스트 데이터를 만들 때 가장 골치 아픈 게 바로 관계형 데이터의 무결성입니다. Users 테이블을 만들고 Orders 테이블을 만들었는데, Orders에 없는 user_id가 들어가면 테스트는 시작도 하기 전에 터집니다. 수작업으로 스크립트를 짜다 보면 이런 참조 무결성을 맞추느라 밤을 새우기 일쑤죠.
이 도구는 PII(개인식별정보) 스크러빙이나 보안 심사 같은 골치 아픈 절차를 기술적으로 우회합니다. 애초에 리얼 데이터를 쓰지 않고, 리얼해 '보이는' 데이터를 생성해 버리니까요. PostgreSQL과 MySQL을 지원한다는 점에서 실무 활용도도 높아 보입니다.
물론, 누군가는 이렇게 말할 수도 있습니다. "그거 그냥 오픈소스 Faker 라이브러리 적당히 래핑한 거 아니에요? 굳이 돈 내고 쓸 필요 있나요?"
실제로 해커뉴스 댓글에도 비슷한 의견이 있었습니다. 하지만 제 생각은 다릅니다.
여러분이 Faker 라이브러리를 가져와서, DB 스키마 변경될 때마다 터지지 않게 파싱 로직을 짜고, 외래 키 순서 맞춰서 데이터 주입하는 스크립트를 만드는 데 며칠이 걸릴까요? 그 3일의 인건비가 도구 구독료보다 비싸다면, 도구를 쓰는 게 맞습니다. 바퀴를 재발명하는 건 주니어 때나 하는 실수로 족합니다.
비즈니스 로직을 짜는 시간보다 테스트 환경 구축에 더 많은 시간을 쓰고 있다면, 그건 뭔가 잘못된 겁니다.
결국 중요한 건 '안전'과 '효율' 사이의 줄타기입니다. 운영 데이터를 쓰는 건 위험하고, 수작업 데이터는 비효율적입니다. 스키마 기반의 자동 생성 도구는 그 사이에서 꽤 합리적인 타협점을 제시합니다.
저처럼 시말서 쓰고 싶지 않다면, 제발 운영 DB 덤프 뜰 생각은 하지 마세요. 여러분의 코드는 버그를 낼 수 있지만, 여러분의 데이터 실수는 범죄가 될 수도 있습니다.
테스트 데이터, 어떻게 관리하고 계십니까? 혹시 아직도 INSERT INTO users VALUES ('test', 'test');를 치고 있진 않나요?
