JSON 포매터가 복잡한 데이터를 한눈에 볼 수 있게 정리해 주는 도구였다면, UUID 생성기는 그 데이터들을 서로 구분해 줄 '고유 식별자'를 만들어 주는 도구입니다. 시스템이 커질수록 중복 없는 ID의 중요성이 커지기 때문에, 개발 현장에서 자주 등장하죠.
UUID가 자리 잡은 이유
UUID는 128비트 길이의 문자열로, 일반적으로 36자리 형태로 쓰입니다. 예: 550e8400-e29b-41d4-a716-446655440000. 전 세계에서 동시에 만들어도 사실상 중복이 없다는 전제가 있기 때문에, 분산 시스템에서 특히 유용합니다.
한 번에 뽑는 도구
코드 바깥에서도 UUID 하나가 필요한 순간이 자주 생깁니다. UUID 생성기는 버튼 한 번이면 값이 바로 만들어지고, 한꺼번에 여러 개를 뽑는 옵션도 있어서 테스트 데이터 준비에 편리합니다.
DB 기본키로
자동 증가 숫자 대신 UUID를 기본키로 쓰면 분산 환경에서의 충돌이 없고, 기본키 예측 공격도 어렵게 만듭니다. 새 마이크로서비스를 설계할 때 UUID 채택을 고려하는 경우가 많습니다.
요청 추적
여러 서비스가 얽힌 시스템에서 요청 하나에 UUID를 부여해 로그에 남기면, 나중에 그 요청의 흐름을 쉽게 되짚을 수 있습니다. 디버깅·장애 대응 속도를 크게 높여 주는 간단한 장치죠. UUID v4 생성을 통해 trace ID를 즉석에서 만들어 쓰는 케이스도 자주 있습니다.
파일명 충돌 방지
여러 사용자가 동시에 파일을 업로드하는 서비스에서는 원본 파일명을 그대로 저장하면 사고가 생기기 쉽습니다. UUID를 파일명 앞에 붙이면 이런 충돌이 사라지고, 파일 URL을 예측 공격하기도 어려워집니다.
API 키·토큰
초대 코드, 일회성 토큰, API 키처럼 '유일해야 하는 문자열'이 필요한 자리에 UUID가 자주 쓰입니다. 보안이 중요한 곳에서는 UUID에 서명·해시 처리를 더해 사용하지만, 기본 값으로서의 고유성만으로도 쓰임이 많습니다.
이벤트 중복 처리 방지
같은 이벤트가 두 번 처리되지 않도록 각 메시지에 UUID를 부여하는 패턴이 이벤트 기반 아키텍처에서 널리 쓰입니다. 수신 측은 이미 처리한 ID를 건너뛰면 되기 때문에 로직이 단순해집니다.
버전 차이
- v1 — 타임스탬프+MAC 기반. 순서 추적이 가능해 개인정보 관점에서 조심스러움.
- v4 — 무작위 기반. 가장 많이 쓰이는 버전.
- v5 — 네임스페이스+이름 해시. 같은 입력에 같은 UUID가 필요할 때.
일반적인 경우라면 v4를 기본으로 삼으면 됩니다. GUID 생성이 필요한 자리에도 같은 형태로 쓸 수 있어요.
주의할 점
UUID는 길이가 길어서 DB 인덱스 성능에 영향을 줄 수 있습니다. 성능이 중요한 환경에서는 바이너리 16바이트 저장이나 ULID·Snowflake 같은 대안을 함께 검토합니다. 일반 용도에서는 v4 UUID로도 무리가 없습니다.
마무리
UUID는 '작은 식별자 하나로 시스템의 복잡성을 줄여 주는' 도구입니다. 한 번 도구를 손에 익히면 설계·개발·운영 어느 단계에서든 바로 꺼내 쓸 수 있습니다.