UUID 테스트 데이터를 만들 때 가장 중요한 원칙은 그럴듯한 문자열을 만드는 일이 아니라 실제 고객 정보와 테스트 식별자를 완전히 분리하는 것입니다. 개발용 주문 fixture에 UUID 열 개를 넣는 상황이라면 생성 개수, 대소문자, 복사 형식, 재현 가능성, 저장 위치를 먼저 정해야 합니다. 랜덤 값이 만들어졌다고 해서 테스트 설계가 끝난 것은 아닙니다.
이 글은 브라우저에서 UUID v4를 생성해 개발용 예시를 준비하는 흐름을 설명합니다. 이 도구는 서버 데이터베이스를 조회하거나 고객 ID를 변환하지 않으며, 화면에서 새 값을 만들고 복사하는 용도입니다. 실제 시스템에서 고정된 ID가 필요한 테스트와 매번 새 값이 필요한 테스트를 구분한 뒤 사용하세요.
먼저 UUID가 맡을 역할을 정하기
UUID는 객체를 식별하기 위한 문자열입니다. 주문 테스트에서는 orderId, 사용자 테스트에서는 userId, 파일 테스트에서는 fixture 이름처럼 식별자 역할을 맡을 수 있습니다. 하지만 UUID가 상태, 권한, 결제 성공 여부를 설명해 주는 것은 아닙니다. 식별자를 만들기 전에 어떤 레코드에 붙고, 어디에서 비교되며, 언제 폐기되는지 한 줄로 적으세요.
| 테스트 목적 | 식별자 선택 | 생성기 사용 판단 |
|---|---|---|
| 형식 검증 | UUID처럼 생긴 값 | 사용 가능 |
| 목록·복사 UI | 여러 개의 서로 다른 값 | 사용 가능 |
| 특정 주문을 다시 찾기 | 항상 같은 고정 값 | 별도 fixture 권장 |
| 실제 고객 조회 | 운영 데이터 식별자 | 사용하지 않음 |
고정된 값이 필요한 snapshot이나 회귀 테스트에 매번 새 UUID를 넣으면 테스트 결과가 바뀔 수 있습니다. 반대로 충돌 처리, 목록 길이, 입력 검증을 시험하는 테스트에는 매 실행마다 다른 값이 더 적합할 수 있습니다. 같은 도구를 모든 테스트에 적용하지 말고 테스트의 재현성 요구를 기준으로 선택하세요.
UUID v4 문자열을 눈으로 검수하기
도구가 표시하는 UUID는 보통 8-4-4-4-12 형태입니다. 하이픈을 제외하면 16진수 32자리이고, 하이픈을 포함하면 36자입니다. UUID v4에서는 특정 비트가 버전과 변형을 나타내고 나머지 대부분이 무작위 값으로 채워집니다. 문자열 길이만 맞는다고 v4 형식이 모두 검증되는 것은 아니므로, 테스트 목적에 맞는 정규식이나 라이브러리 검증을 추가하세요.
브라우저에 `crypto.randomUUID`가 있으면 도구는 그 함수를 사용하고, 그렇지 않으면 16바이트 배열을 만든 뒤 Web Crypto의 난수와 버전·변형 비트를 조정해 문자열을 구성합니다. 이 동작은 화면에서 사람이 입력한 값을 변환하는 것이 아니라 새 식별자를 생성하는 것입니다. 생성 결과에 의미 있는 순번이나 날짜가 들어 있다고 해석하지 마세요.
한 개의 UUID가 128비트라는 설명은 저장 공간과 형식을 이해하는 데 도움이 됩니다. v4에서 무작위로 선택되는 비트는 버전·변형 표시를 제외한 약 122비트입니다. 따라서 값이 10개라고 해서 사람이 읽는 번호 10개처럼 순서가 정해지는 것이 아니며, 배열에 표시된 순서도 업무상 우선순위를 뜻하지 않습니다.
생성 개수와 복사 형식을 테스트 요구에 맞추기
화면의 개수 선택지는 1, 3, 5, 10개입니다. 처음 페이지를 열면 다섯 개가 생성되어 있고, 새로 생성 버튼을 누르면 현재 개수만큼 전부 새 값으로 교체됩니다. 개수를 바꾸는 순간에도 해당 개수만큼 새 값이 만들어지므로, 이미 복사해야 할 값이 있다면 먼저 저장해 두세요.
- 테스트에 필요한 최대 개수를 먼저 선택합니다.
- 결과가 모두 36자 형식인지 확인합니다.
- 개별 복사와 전체 복사 중 코드에 맞는 방식을 고릅니다.
- 붙여 넣은 파일에서 줄바꿈과 하이픈이 보존되는지 검토합니다.
- 같은 테스트를 다시 실행했을 때 새 값으로 바뀌는지 확인합니다.
개별 복사는 한 식별자를 특정 필드에 넣을 때 편리하고, 전체 복사는 줄마다 하나의 fixture를 만드는 데 적합합니다. 대문자 버튼은 화면에 표시되는 값을 대문자로 바꾸지만 UUID의 의미나 랜덤성 자체를 바꾸지는 않습니다. 저장 시스템이 대소문자를 구분하는지 모른다면 팀의 표기 규칙을 먼저 정하고 한 형식으로 고정하세요.
충돌 가능성을 숫자로 설명하기
서로 다른 UUID가 우연히 같아질 가능성은 생성량이 늘어날수록 커집니다. 생일 문제와 비슷하게 한 번의 쌍 비교가 아니라 모든 값의 쌍을 비교해야 하므로, 작은 확률을 단순히 10으로 나누어 이해하면 안 됩니다. 근사적으로 생성 수를 n이라고 할 때 충돌 확률은 `n(n-1) ÷ (2 × 2^122)` 형태로 생각할 수 있습니다.
예를 들어 이 화면에서 최대 선택 가능한 10개를 한 번 만들면 쌍은 `10×9÷2=45`개입니다. 45를 약 `2^122` 공간과 비교하면 충돌 확률은 대략 `4.2×10^-36` 수준으로 매우 작습니다. 100만 개를 만든다고 해도 근사값은 약 `9.4×10^-26`입니다. 이 계산은 우연한 충돌의 직관을 주지만, 특정 데이터베이스 제약이나 잘못된 저장 로직까지 안전하다고 보장하지는 않습니다.
실무에서 더 자주 발생하는 문제는 충돌보다 입력·복사·매핑 실수입니다. 같은 값을 두 레코드에 복사하거나, 앞뒤 공백을 포함하거나, 다른 필드에 붙여 넣는 과정에서 식별 관계가 틀어질 수 있습니다. 생성 후에는 값 자체뿐 아니라 어느 fixture의 어느 필드에 들어갔는지 확인하고, 데이터베이스의 고유 제약과 애플리케이션 검증도 별도로 실행하세요.
랜덤 fixture와 결정적 fixture를 나누기
화면에서 만드는 값은 새로 생성할 때마다 바뀝니다. 따라서 테스트 코드가 특정 UUID를 기대한다면 생성기 결과를 그대로 복사해 두는 것만으로는 의도가 분명하지 않을 수 있습니다. 고정 fixture 파일에는 사람이 알아볼 수 있는 목적과 함께 값을 명시하고, 무작위 테스트에서는 실행 시 새 값을 주입하는 두 경로를 분리하세요.
예를 들어 형식 검증은 생성된 UUID의 길이, 하이픈 위치, 버전 표시를 확인하면 됩니다. 주문 상세 화면의 회귀 테스트는 `order-fixture-basic`처럼 고정된 레코드와 고정 ID를 사용해야 특정 화면을 다시 재현할 수 있습니다. 중복 처리 테스트는 서로 다른 값 여러 개를 만들고 일부러 동일한 값을 넣는 경로를 별도로 구성해야 충돌 상황을 명확히 설명할 수 있습니다.
테스트 데이터가 실행 순서에 따라 달라지면 실패 원인을 찾기 어려워질 수 있습니다. 랜덤 값을 사용하는 테스트는 실패 시 생성된 값을 로그에 남기되, 실제 사용자 정보와 섞이지 않는 별도 로그를 사용하세요. 보안상 공개해도 되는 가상 값만 기록하고, 운영 토큰이나 세션 값은 UUID처럼 보인다고 해서 로그에 넣지 않습니다.
대소문자와 저장·비교 규칙을 고정하기
화면의 대문자 전환은 표현 방식의 편의 기능입니다. 한 팀은 소문자 UUID를 저장하고 다른 팀은 대문자를 API 응답에 기대하면 문자열 비교가 실패할 수 있습니다. 데이터베이스의 collation, API 스키마, 클라이언트 검증 라이브러리가 대소문자를 어떻게 처리하는지 확인하고, 저장값과 화면 표시값을 같은 규칙으로 운영하세요.
UUID를 URL 경로, 파일명, JSON 문자열에 넣을 때는 주변 문법도 확인해야 합니다. 하이픈이 URL에서 특별한 인코딩을 요구하지는 않지만, 따옴표·쉼표·줄바꿈이 빠지면 JSON이나 CSV가 깨질 수 있습니다. 전체 복사 결과를 붙여 넣은 뒤 줄 수와 마지막 줄의 개행 여부를 확인하면 단순한 fixture 오류를 줄일 수 있습니다.
UUID 앞뒤에 사람이 읽는 접두사를 붙이는 방식도 팀 규칙이 필요합니다. `order_` 같은 접두사가 필요하다면 식별자 필드 자체에 넣을지 별도 컬럼에 둘지 정하고, UUID 형식 검증을 접두사가 있는 값에 맞추어야 합니다. 생성기에서 출력된 문자열을 임의로 잘라 사람이 읽기 좋은 짧은 코드로 만들면 UUID의 형식과 충돌 특성을 그대로 유지하지 못합니다.
실제 고객 정보와 섞이지 않게 폐기하기
UUID는 개인정보처럼 보이지 않을 수 있지만, 운영 DB의 다른 값과 결합되면 개인이나 주문을 다시 찾는 키가 될 수 있습니다. fixture에 고객 이름, 전화번호, 이메일을 넣지 말고, 필요한 모양만 가진 가상 값을 사용하세요. 실제 ID를 복사해 일부만 바꾸는 방식도 안전한 익명화라고 보기 어렵습니다.
테스트가 끝나면 생성된 파일, 클립보드, 임시 로그, 화면 캡처를 어디까지 남길지 정합니다. 공개 저장소에 올릴 fixture라면 가상 값임을 파일 설명에 표시하고, 운영 환경에서 재사용될 수 있는 접속 정보와 함께 커밋하지 않습니다. 값의 형식이 같다는 이유로 인증 토큰이나 비밀번호를 UUID 생성기에서 만들어도 보안 설계가 완성되는 것은 아닙니다.
생성 전후 수용 체크리스트
- 이 값이 실제 운영 식별자가 아닌 가상 테스트 값인지 확인합니다.
- 테스트가 랜덤 값과 고정 값 중 어느 것을 요구하는지 결정합니다.
- 1·3·5·10개 중 필요한 개수를 선택하고 결과 수를 셉니다.
- 각 문자열의 8-4-4-4-12 형식과 저장 필드 매핑을 확인합니다.
- 대소문자, 접두사, URL·JSON·CSV 문법을 팀 규칙에 맞춥니다.
- 충돌보다 복사·중복·누락 가능성을 먼저 검사합니다.
- 테스트 종료 후 임시 파일과 민감한 로그의 보관 범위를 정합니다.
새 식별자를 만들려면 UUID 생성기에서 필요한 개수와 표시 형식을 선택하세요. 생성한 값을 JSON fixture에 넣은 뒤 문법과 중복 키를 확인하려면 JSON 포매터를 함께 사용할 수 있습니다. API 데이터에서 식별자가 어떤 역할을 하는지 기초부터 정리하려면 API와 JSON 설명을 이어서 읽어 보세요.