개발할 때 UUID 필요하면 여기서 바로 생성

데이터베이스 ID를 뭘로 할지 고민하다가

새 프로젝트를 시작할 때마다 고민되는 게 있다. 데이터베이스 레코드의 고유 식별자를 뭘로 할 것인가. auto increment 정수를 쓸 것인가, UUID를 쓸 것인가. 최근에는 분산 시스템이 많아지면서 UUID를 쓰는 경우가 점점 늘고 있다.

근데 개발 초기에 테스트 데이터를 만들거나, API 문서에 예시 ID를 넣어야 할 때 UUID를 직접 생성해야 하는 순간이 온다. 코드로 생성할 수도 있지만, 빠르게 하나만 필요할 때는 온라인 UUID 생성기가 훨씬 편하다. 접속해서 클릭 한 번이면 UUID가 뚝딱 나온다.

UUID가 뭔지 모르는 사람을 위한 초간단 설명

UUID는 Universally Unique Identifier의 약자로, 전 세계적으로 고유한 128비트 식별자다. 보통 "550e8400-e29b-41d4-a716-446655440000" 같은 형태로 생겼다. 하이픈으로 구분된 32개의 16진수 문자(8-4-4-4-12 구조)로 이루어져 있다.

UUID의 핵심 포인트는 중앙 관리 없이도 거의 100% 고유한 값을 생성할 수 있다는 거다. auto increment는 하나의 데이터베이스 안에서만 고유하지만, UUID는 서로 다른 서버, 다른 시스템에서 동시에 생성해도 충돌할 확률이 거의 0에 가깝다. 그래서 마이크로서비스 아키텍처에서 각 서비스가 독립적으로 ID를 생성할 수 있다.

한 번에 여러 개 생성할 수 있어서 편하다

이 도구의 좋은 점 중 하나는 한 번에 여러 개의 UUID를 생성할 수 있다는 거다. 테스트 데이터를 10개, 20개씩 만들어야 할 때 하나씩 생성하면 번거롭다. 개수를 지정하면 한꺼번에 원하는 만큼의 UUID가 나온다.

나는 보통 API 테스트 시나리오를 작성할 때 사용자 ID, 주문 ID, 상품 ID 등에 각각 다른 UUID가 필요해서 10개씩 뽑아놓고 쓴다. UUID 생성 사이트에서 생성한 값을 복사해서 테스트 코드에 바로 붙여넣으면 되니까 작업 속도가 훨씬 빨라진다.

v1, v4 차이를 여기서 직접 확인했다

UUID에도 버전이 있다는 걸 이 도구를 쓰면서 제대로 알게 됐다. 가장 많이 쓰이는 건 v4(랜덤 기반)와 v1(시간+MAC 주소 기반)이다. v4는 완전히 랜덤한 값으로 생성되어서 예측이 불가능하고, v1은 생성 시간과 기기 정보가 포함되어 있어서 정렬이 가능하다.

일반적인 용도에서는 v4를 쓰는 게 보편적이다. 보안 면에서도 v4가 낫다. v1은 MAC 주소가 포함되기 때문에 기기 정보가 노출될 수 있다. 나는 특별한 이유가 없으면 항상 v4를 쓴다. 이 도구에서 버전을 선택하고 각각 생성해보면 형태의 차이를 직접 눈으로 확인할 수 있다.

Postman에서 API 테스트할 때 매일 쓴다

Postman으로 REST API를 테스트할 때 요청 본문에 UUID 형식의 ID를 넣어야 하는 경우가 매일 같이 있다. POST /users 엔드포인트에 새 사용자를 생성할 때 user_id 필드에 UUID를 넣어야 한다든지, DELETE /orders/{orderId}에서 orderId에 UUID를 넣어야 한다든지.

Postman 자체에서도 {{$guid}} 같은 변수로 자동 생성할 수 있지만, 특정 UUID 값을 고정해서 여러 API에 걸쳐 테스트해야 할 때는 직접 생성한 UUID를 쓰는 게 낫다. 예를 들어 사용자를 생성하고, 그 사용자로 주문을 하고, 주문을 조회하는 시나리오에서는 같은 user_id를 계속 써야 하니까.

데이터베이스 성능 이슈도 알아두면 좋다

UUID를 데이터베이스의 기본 키(Primary Key)로 쓸 때 성능 이슈가 있다는 것도 알아두면 좋다. UUID v4는 완전 랜덤이라 인덱스 페이지에 순서 없이 삽입되면서 인덱스 분할(page split)이 자주 발생한다. 이것 때문에 INSERT 성능이 느려질 수 있다.

이 문제를 해결하기 위해 UUID v7이나 ULID 같은 시간순 정렬이 가능한 대안도 나왔다. MySQL 8에서는 BIN_TO_UUID(), UUID_TO_BIN() 함수와 함께 swap flag를 쓰면 성능을 개선할 수 있다. UUID를 쓸 때 이런 성능 특성을 이해하고 사용하는 게 중요하다.

UUID를 사람이 읽어야 할 때의 팁

UUID는 기계가 다루기에는 좋지만 사람이 읽기에는 좋지 않다. "550e8400-e29b-41d4-a716-446655440000"을 보고 기억하거나 구분하기란 거의 불가능하다. 그래서 사용자에게 보여줘야 하는 ID에는 UUID 대신 짧은 코드를 쓰는 게 낫다.

하지만 개발 과정에서 로그를 보거나 디버깅할 때는 UUID를 계속 마주치게 된다. 이럴 때 앞 4~8자리만 보고 구분하는 습관을 들이면 편하다. "550e로 시작하는 주문"과 "a7f3으로 시작하는 주문" 식으로. 완벽한 식별은 아니지만 대화할 때는 충분하다.

정리 – 개발자의 일상 도구 중 하나

UUID 생성기는 개발자가 매일 쓰는 소소하지만 필수적인 도구다. 데이터베이스 설계, API 테스트, 문서 작성, 목업 데이터 생성 등 UUID가 필요한 순간은 예상보다 자주 온다. UUID 생성기를 북마크에 넣어두면 클릭 한 번으로 고유한 식별자를 바로 얻을 수 있다. 작지만 없으면 불편한 도구, 개발자라면 꼭 알아두자.