프론트엔드 개발은 백엔드가 실제 데이터를 제공할 준비가 되기 전에 시작되는 경우가 많습니다. 작동하는 API를 기다리는 대신, 올바른 형태의 현실적인 테스트용 JSON 데이터를 생성해 바로 작업을 시작할 수 있습니다.
목 데이터란 무엇인가
목(mock) JSON은 생성되었지만 구조적으로 그럴듯한 데이터입니다: 진짜 이름처럼 보이는 이름, 올바른 형식의 날짜, 그럴듯해 보이는 ID 등입니다. "test123" 같은 플레이스홀더 값과 달리, 현실적인 목은 UI가 긴 이름, 빈 필드, 특정 날짜 형식을 제대로 처리하는지 바로 보여줍니다.
왜 필요한가
- 백엔드 팀이 API를 완성하기 전에 UI 개발을 시작할 때.
- 실제 데이터베이스를 채우지 않고도 UI가 많은 레코드를 어떻게 처리하는지 테스트할 때.
- 실제 사용자 데이터를 노출하지 않고 데모나 프로토타입을 만들 때.
- 외부 서비스나 데이터베이스의 상태에 의존하지 않는 자동화된 테스트를 작성할 때.
2014년에 바뀐 한국 주소 체계
한국은 2014년부터 지번 주소 대신 도로명주소 체계를 공식으로 사용한다 — "OO동 123-45" 같은 지번 표기 대신 "OO로 12길 34"처럼 도로 이름과 건물 번호를 쓰는 방식이다. 우편번호도 예전 6자리 지번 기반 코드에서 5자리 도로명 기반 코드로 바뀌었다. 오래된 목 데이터 생성기나 예제가 여전히 구식 지번 주소 형식이나 6자리 우편번호를 생성한다면, 실제로는 이미 10년 넘게 쓰이지 않는 체계를 재현하는 셈이다. 전화번호는 국가 코드 +82 뒤에 지역 번호에서 앞자리 0을 뺀 형태로 쓴다(010...이 +82 10...이 되는 식).
주의할 점
목 데이터는 실제 데이터의 형태와 타입은 잘 재현하지만, 비즈니스 로직이나 레코드 간의 관계는 재현하지 못합니다. 프로덕션에 배포하기 전에는 여전히 실제 API로 코드를 테스트해야 합니다 — 목은 개발 초기 단계를 앞당길 뿐입니다.
목 데이터의 현실적인 edge case
좋은 목 데이터 생성기는 의도적으로 "까다로운" 값을 포함합니다 — 매우 긴 이름, 빈 문자열, 한글과 로마자가 섞인 문자열, 0이나 음수, 범위 경계에 걸친 날짜 등입니다. "John Doe"처럼 "편안한" 데이터로만 테스트된 화면이나 로직을 가장 자주 무너뜨리는 것이 바로 이런 값들입니다 — 그래서 매번 똑같은 테스트 예시보다 무작위성이 있는 목 데이터가 더 유용합니다.