기존 GUID(UUID) 데이터베이스 Primary Key 사용: 특징과 고려사항

안녕하세요. 오늘은 이전에 흔히 사용되던 GUID(Globally Unique Identifier) 또는 UUID(Universally Unique Identifier)의 특징과 이를 데이터베이스의 Primary Key(PK)로 사용할 때 고려해야 할 점들에 대해 이야기해 보겠습니다.

1. GUID(UUID)란 무엇인가?

GUID는 128비트로 구성된 고유 식별자입니다. 기본적으로 랜덤하게 생성됩니다. 이는 여러 시스템에 걸쳐 충돌할 확률이 매우 낮은 고유한 값을 만들기 위해 고안되었습니다.

2. GUID의 사용 목적: 왜 랜덤한 ID가 필요했나?

GUID가 등장한 가장 큰 이유는 대규모 트래픽 환경 때문입니다. 일반적인 환경에서는 데이터베이스 서버가 자동으로 증가시켜주는 Int 기반의 Identity Column을 사용하면 중복 없이 Unique ID를 얻을 수 있고 효율적입니다. DB 서버 하나가 ID 생성을 책임지는 싱글턴 방식이기 때문이죠.

하지만 엄청난 트래픽이 몰리는 대규모 분산 시스템에서는 DB 서버 한 대가 Identity Column 생성을 담당하는 것 자체가 부하가 될 수 있습니다. 이런 환경에서는 각 시스템에서 확률적으로 충돌 가능성이 훨씬 적은 랜덤한 값을 각자 만들어서 사용하는 방식이 유리하며, 이를 위해 128비트의 GUID가 나오게 되었습니다. '128비트면 잘 안 생기겠지?' 하는 생각으로 랜덤하게 만든 것이 GUID입니다.

3. DB Primary Key로 사용 시 문제점

GUID를 데이터베이스의 PK로 사용할 때 문제가 발생할 수 있습니다. 특히 DB가 클러스터 인덱스(Cluster Index) 방식으로 인덱스를 잡을 경우, GUID의 무작위적인 생성 방식 때문에 클러스터 방식이 잘 안 됩니다. 이로 인해 DB의 인덱스 효율이 떨어져 성능 문제가 발생할 수 있으며, 때로는 클러스터를 끄기 위해 '이상한 짓'을 해야 할 수도 있다고 언급됩니다.

4. Int Identity Column과의 비교

대부분의 일반적인 상황에서는 DB에서 제공하는 Int 기반 Identity Column을 사용하는 것이 GUID보다 훨씬 낫고 효율적입니다.

장점:
- DB 서버가 중복 없이 유일한 ID 생성을 책임집니다.
- 저장 공간을 적게 사용합니다.
- 성능에 문제없다면 더 나은 방법입니다.
- '충돌 나지 않겠지' 하는 끈적함(불안함)이 없습니다.

5. GUID 사용의 '끈적함' (잠재적 충돌 불안감)

GUID는 128비트 랜덤성을 기반으로 충돌 확률이 매우 낮다고 '믿고' 사용하는 것입니다. 하지만 프로그래머 입장에서는 64비트에서도 충돌을 본 적은 없지만 (32비트에서는 많이 봤다고 합니다), 어딘가에 있는 '아주 작은 확률이라도 나올 수 있다'는 불안함, 즉 기분 나쁜 끈적거림을 느끼게 된다고 합니다.

6. 외부 노출

GUID로 Primary Key를 만든 경우, 일반적으로 해당 GUID를 외부에 그대로 노출하는 경우가 많습니다. API나 URL 등을 통해 노출되곤 합니다.

7. 결론

GUID는 대규모 분산 환경에서 ID 생성을 분산하기 위한 좋은 해결책이지만, DB의 클러스터 인덱스 효율을 떨어뜨릴 수 있으며, 확률적 방식이라 잠재적인 충돌에 대한 작은 불안감을 동반합니다.

대규모 스케일링이나 분산 시스템이 필수적이지 않은 환경이라면, DB의 Int Identity Column이 중복 없고 효율적인 더 나은 선택입니다. 저자 또한 이런 환경이 아니라면 Int DB ID를 훨씬 선호하며, 그것이 끈적함도 없고 저장 효율도 좋습니다.

저작자표시 비영리 변경금지 (새창열림)