[개발 일기] 2025.03.28 - Auto Increment Long PK vs UUID

💡 개요

 

나는 보통 테이블에 인덱스용 Auto Increment Long 형태의 기본 키(PK)를 반드시 두는 편이다.

 

 

그런데 이 PK를 그대로 응답 데이터로 사용하는 것이 좋을까? 아니면 고유성을 보장하는 UUID 컬럼을 추가하여 응답용으로 활용하는 것이 나을까?

 

 

테이블의 PK를 그대로 반환하여 클라이언트에서 사용하도록 하는 것은 보안적인 문제가 발생할 수 있지 않을까?

 

 

 

📕 Auto Increment Long PK

 

데이터를 조회할 때 PK를 사용하는 것은 여러 가지 장점이 있다.

 

 

대표적으로 가독성이 뛰어나다. Auto Increment를 사용하는 Long 타입의 PK는 자동으로 1씩 증가하므로 관리가 편리하고, 코드에서 활용하기도 쉽다.

 

 

또한, 성능 측면에서도 유리하다. 일반적인 String 형태의 PK보다 저장 공간을 적게 차지하고, 인덱스를 효과적으로 활용할 수 있어 조회 속도가 빠르다.

 

 

하지만 단점도 있다.

 

 

예를 들어, 클라이언트에 PK를 그대로 반환하는 경우를 생각해보자.

 

 

내가 게시글을 작성하고 해당 게시글을 조회했을 때, URL이 다음과 같다고 가정하자.

 

 

http://hyeongseok.com/board/detail?boardId=40

 

 

이 URL을 보면 현재 게시글의 PK가 40이라는 것을 쉽게 알 수 있다.

 

 

그렇다면 내가 직전에 작성한 게시글의 PK는 39일 가능성이 높다.

 

 

만약 악의적인 사용자가 이러한 패턴을 파악하고 특정 게시글을 조회하거나, 심지어 수정 요청을 시도한다면 보안적인 문제가 발생할 수 있다. (물론 일반적으로 수정이나 삭제 요청 시 게시글 작성자와 요청자의 일치 여부를 확인하기 때문에 이러한 문제가 실제로 발생할 가능성은 낮다.)

 

 

 

📕 UUID

 

UUID를 활용하는 방식도 고려할 수 있다.

 

 

테이블의 PK를 Auto Increment Long으로 유지하면서도, 별도의 UUID 컬럼을 추가하는 방식이다.

 

 

UUID를 테이블의 PK로 사용하는 것은 효율적이지 않다.

 

 

인덱스는 빠른 조회 성능을 목적으로 하는데, UUID는 Long 타입보다 크기가 크고 정렬도 어렵기 때문이다.

 

 

즉, 조회 성능이 저하될 가능성이 높다.

 

 

따라서, PK는 Auto Increment Long을 유지하고, UUID를 별도 컬럼으로 두는 것이 더 적절하다.

 

 

UUID의 가장 큰 장점은 고유성이다.

 

 

 

UUID는 이론적으로 340,282,366,920,938,463,463,374,607,431,768,211,456개의 조합이 가능하다. (뭔 숫자고 저건)

 

 

이는 사실상 중복이 발생할 가능성이 없는 수준이다.

 

 

따라서, 클라이언트에게 응답해야 하는 고유한 식별자라면 PK 대신 UUID를 사용하는 것이 더 안전하다.