이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
테스트 데이터 생성 전략에서 가장 먼저 고민한 것은 어떤 경계값과 엣지 케이스를 빠짐없이 포함해야 하는가였습니다. 단순한 정상 케이스만으로는 실제 사용자가 만드는 예외 상황을 검증할 수 없기 때문에, 빈 값·최대값·특수문자 입력 같은 케이스를 체계적으로 정의했습니다.
팩토리 패턴을 활용해 테스트 데이터를 코드로 생성했습니다. 하드코딩된 픽스처보다 필요한 값만 오버라이드하고 나머지는 기본값을 쓰는 구조가 테스트 코드를 간결하게 유지했고, 스키마가 바뀌면 팩토리 한 곳만 수정하면 됐습니다.
민감한 데이터가 포함된 경우는 프로덕션 데이터를 마스킹하거나 합성 데이터를 생성하는 방법을 사용했습니다. 실제 패턴을 유지하면서도 개인정보가 포함되지 않는 데이터로 테스트 환경을 구성했습니다.
테스트 데이터를 각 테스트 파일에 직접 하드코딩으로 관리하다가 스키마가 바뀌었을 때 수십 개의 테스트 파일을 하나씩 수정해야 했던 경험이 있습니다. 처음에는 각 테스트에 필요한 데이터를 그때그때 직접 넣는 방식이 간단해 보였는데, 데이터 구조가 바뀌는 시점에 수정해야 할 곳이 많아서 유지보수 비용이 크다는 것을 알게 됐습니다. 팩토리 함수를 도입해서 테스트 데이터를 한 곳에서 생성하고 테스트에서는 필요한 필드만 오버라이드하는 방식으로 바꾸니, 스키마 변경 시 팩토리 하나만 수정하면 됐습니다. 같은 문제를 두 번 경험하지 않으려고 새 프로젝트를 시작할 때는 테스트 데이터 생성 방식을 처음부터 팩토리 패턴으로 잡는 것을 기본으로 가져가게 됐습니다. 테스트 코드의 유지보수 비용은 프로덕션 코드와 마찬가지로 처음 구조를 어떻게 잡느냐에 따라 크게 달라진다는 것을 이 경험에서 배웠습니다.
개인정보가 포함된 실 데이터를 마스킹해서 테스트 환경에 사용했는데, 마스킹 과정에서 데이터의 특성이 바뀌어서 테스트가 잡지 못한 케이스가 운영에서 발생한 경험이 있습니다. 이름 필드를 마스킹하면서 원래 데이터에 있던 특수문자 조합이 제거됐는데, 그 조합이 포함된 입력을 처리하는 부분이 검증되지 않은 상태로 남았습니다. 마스킹이 개인정보를 보호하는 데는 효과적이지만, 원본 데이터의 다양한 패턴을 유지하지 못하면 테스트 커버리지에 빈틈이 생긴다는 것을 알게 됐습니다. 이후에는 마스킹과 함께 원본에서 발견된 특수한 패턴을 합성 데이터로 별도 생성해 테스트 케이스에 포함하는 방식을 추가했습니다. 테스트 데이터 전략에서 민감 정보 보호와 현실적인 테스트 커버리지 확보는 별개로 다뤄야 한다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.