TaskSprints
스터디를 진행하면서 백엔드 내부에서 uuid
를 사용하는 것에서 의문이 들었습니다. 그래서 이에 대해서 찾아보고 공부한 내용에 대한 정리입니다.
UUID
관련해서 제가 조금 알아본 걸 토대로 간단하게 소개해드리겠습니다.
저는 UUID
가 성능을 감소 시키는 주된 원인이라고 생각하고, 많이 쓰는 이유를 이해하지 못했습니다. 또한, auto_increment
에 비해서 극악의 확률이라 하더라도 중복이 될 수도 있다는 점에서 굳이 필요한가 라는 생각을 가졌습니다.
보안성을 지키기 위해서 사용한다는 말을 엄청 많이 들었는데, 실제로 pk를 특정해서 유저의 정보에 접속할 수 있다는 concept
부터 말이 안된다고 생각했습니다.
서버 내부적인 보안처리, 토큰을 통한 접근 제어 등을 통해서도 충분히 방지가 될 것으로 보이는데 이것이 정말 보안에 중대한 상황 인지에 대해서 의문을 느꼈습니다.
그래서 여러 정보를 찾아보고 주변 사람들에게 물어보면서 알게 된 UUID 를 사용하는 목적은 숫자에 대한 추론을 불가하게 만드는 것에 있습니다. 생각을 해보면 "거래의 양, 유저의 수"등이 auto_increment
의 경우에는 충분히 특정이 가능합니다. 하지만 특정 상황에서는 이러한 정보를 가리고 싶은 상황이 분명 존재합니다. 이러한 상황에서 UUID
를 사용하게 됩니다. 그렇기에 민감한 데이터에 대한 접근을 막아주는 것이 주된 의미가 아니라, 해당 숫자를 통해서 어떠한 지표를 추론하는 것을 막기 위해 사용
된다고 생각하면 좋을 것 같습니다.
보안 자체에 큰 메리트를 생각하는게 아닌, 추론에 대한 차단을 좀 더 메리트 있게 생각 할 수 있음.
UUID
가 성능상으로 더 높은 효과를 만들어내는 경우는 일반 단일 서버에서는 딱히 없긴 합니다. 하지만 분산 환경에 있다고 하면 조금 다릅니다.
각 분산 서비스가 각각의 샤딩된 DB 를 가지게 된다면, 이는 하나의 DB로 묶어서 처리를 해야 합니다. 이 때, auto_increment 로 생성 된 pk
는 필연적인 충돌이 일어날 수밖에 없습니다. 이 때, UUID
를 사용하게 됩니다. UUID
의 특정으로는 해당 값은 전역에서 Unique
하다는 특징을 가지고 있습니다. 그렇기 때문에 샤딩된 DB가 합쳐질 때 충돌이 발생할 확률을 줄여주게 됩니다.
샤딩 관련 자료
UUID
에서 중복된 값이 생성될 확률은 매우 극악에 확률입니다. 트레이드 오프
를 했을 때, 해당 부분을 감안하면서 사용할만한 부분에서는 충분히 가치가 있습니다.
추가로 UUIDv4
라이브러리를 사용한다면, 라이브러리에서 어플리케이션 레벨에서 충돌 방지 로직을 가지고 있어서, 기존의 uuid
을 통한 키 발행 시 극악의 조건으로 생기는 충돌을 막을 수 있습니다.
확실히 무분별한 UUID
사용은 성능저하에서 문제가 생길 수 있습니다. 하지만 추론을 불가하고 싶게 조절하거나, 분산환경에 대한 계획이 있는 서비스라면 충분히 사용할만한 가치가 있습니다.