Auto Increment와 UUID, 기본 개념부터 이해하기
데이터베이스에서 각 행(row)을 구분하려면 고유한 식별자, 즉 Primary Key가 필요하다. 이때 가장 흔히 쓰이는 두 가지 전략이 Auto Increment와 UUID다. Auto Increment는 데이터가 추가될 때마다 1, 2, 3… 순서대로 번호를 매기는 방식이고, UUID(Universally Unique Identifier)는 128비트 크기의 무작위성 높은 문자열(예: 550e8400-e29b-41d4-a716-446655440000)을 생성해 식별자로 사용하는 방식이다.
번호표 vs 지문, 동작 원리의 차이
이 둘의 차이는 은행 창구의 번호표와 사람의 지문에 비유할 수 있다. 번호표(Auto Increment)는 순서대로 발급되기 때문에 누가 먼저 왔는지 한눈에 알 수 있고 저장 공간도 작다. 하지만 번호표 발급기가 하나뿐이라면, 여러 창구(서버)에서 동시에 번호를 발급할 때 충돌이 날 수 있다. 반면 지문(UUID)은 누가 언제 왔는지와 상관없이 전 세계 어디서 생성하든 겹칠 확률이 극히 낮다. 그래서 여러 서버나 클라이언트에서 동시에 ID를 만들어도 별도의 조율 없이 안전하게 사용할 수 있다. 대신 지문 데이터는 번호표보다 훨씬 길고 복잡해서 저장 공간을 더 차지하고, 정렬이나 인덱싱 성능에서 손해를 볼 수 있다.
실무에서는 무엇을 선택해야 할까
선택 기준은 결국 ‘분산 환경 여부’와 ‘성능 우선순위’에 달려 있다.
- 단일 서버, 단순 서비스: Auto Increment가 적합하다. 정수형이라 저장 효율이 좋고, 조인·정렬 성능이 뛰어나다.
- MSA나 다중 서버 환경: 여러 서비스가 동시에 데이터를 생성해도 충돌 없이 ID를 만들어야 하므로 UUID가 유리하다.
- 보안이 중요한 경우: Auto Increment는 순차적이라 다음 값이 예측되어 URL에 노출 시 정보가 유추될 수 있다. UUID는 예측이 거의 불가능해 이런 위험을 줄인다.
- 성능이 중요한 대용량 트래픽 서비스: UUID는 인덱스 크기가 커지고 랜덤 삽입으로 인덱스 단편화가 발생할 수 있어, 최근에는 시간 정보를 포함해 정렬 가능한
UUID v7이나ULID같은 대안도 많이 쓰인다.
결국 정답은 하나가 아니다. 서비스 규모가 작고 단일 데이터베이스로 충분하다면 Auto Increment로 시작하는 것이 실용적이고, 확장성과 분산 환경, 보안을 고려해야 한다면 UUID 계열을 검토하는 것이 좋다. 중요한 것은 프로젝트 초기에 어떤 방식이 서비스의 성장 방향과 맞는지 충분히 고민하고 결정하는 것이다.