uuid 의 필요성과 효율적으로 사용하는 방법

k·2024년 9월 7일
0

TaskSprints 스터디를 진행하면서 백엔드 내부에서 uuid를 사용하는 것에서 의문이 들었습니다. 그래서 이에 대해서 찾아보고 공부한 내용에 대한 정리입니다.

서론

UUID 관련해서 제가 조금 알아본 걸 토대로 간단하게 소개해드리겠습니다.

저는 UUID가 성능을 감소 시키는 주된 원인이라고 생각하고, 많이 쓰는 이유를 이해하지 못했습니다. 또한, auto_increment에 비해서 극악의 확률이라 하더라도 중복이 될 수도 있다는 점에서 굳이 필요한가 라는 생각을 가졌습니다.

보안성 때문에 사용하는건가?

보안성을 지키기 위해서 사용한다는 말을 엄청 많이 들었는데, 실제로 pk를 특정해서 유저의 정보에 접속할 수 있다는 concept부터 말이 안된다고 생각했습니다.

서버 내부적인 보안처리, 토큰을 통한 접근 제어 등을 통해서도 충분히 방지가 될 것으로 보이는데 이것이 정말 보안에 중대한 상황 인지에 대해서 의문을 느꼈습니다.

그래서 여러 정보를 찾아보고 주변 사람들에게 물어보면서 알게 된 UUID 를 사용하는 목적은 숫자에 대한 추론을 불가하게 만드는 것에 있습니다. 생각을 해보면 "거래의 양, 유저의 수"등이 auto_increment의 경우에는 충분히 특정이 가능합니다. 하지만 특정 상황에서는 이러한 정보를 가리고 싶은 상황이 분명 존재합니다. 이러한 상황에서 UUID를 사용하게 됩니다. 그렇기에 민감한 데이터에 대한 접근을 막아주는 것이 주된 의미가 아니라, 해당 숫자를 통해서 어떠한 지표를 추론하는 것을 막기 위해 사용된다고 생각하면 좋을 것 같습니다.

보안 자체에 큰 메리트를 생각하는게 아닌, 추론에 대한 차단을 좀 더 메리트 있게 생각 할 수 있음.

성능에서 이점을 가지는 경우

UUID가 성능상으로 더 높은 효과를 만들어내는 경우는 일반 단일 서버에서는 딱히 없긴 합니다. 하지만 분산 환경에 있다고 하면 조금 다릅니다.

각 분산 서비스가 각각의 샤딩된 DB 를 가지게 된다면, 이는 하나의 DB로 묶어서 처리를 해야 합니다. 이 때, auto_increment 로 생성 된 pk는 필연적인 충돌이 일어날 수밖에 없습니다. 이 때, UUID를 사용하게 됩니다. UUID의 특정으로는 해당 값은 전역에서 Unique하다는 특징을 가지고 있습니다. 그렇기 때문에 샤딩된 DB가 합쳐질 때 충돌이 발생할 확률을 줄여주게 됩니다.

샤딩 관련 자료

UUID 가 유니크하지 않을 수 있음에도 사용하는 이유

UUID에서 중복된 값이 생성될 확률은 매우 극악에 확률입니다. 트레이드 오프를 했을 때, 해당 부분을 감안하면서 사용할만한 부분에서는 충분히 가치가 있습니다.
추가로 UUIDv4 라이브러리를 사용한다면, 라이브러리에서 어플리케이션 레벨에서 충돌 방지 로직을 가지고 있어서, 기존의 uuid을 통한 키 발행 시 극악의 조건으로 생기는 충돌을 막을 수 있습니다.

결론

확실히 무분별한 UUID 사용은 성능저하에서 문제가 생길 수 있습니다. 하지만 추론을 불가하고 싶게 조절하거나, 분산환경에 대한 계획이 있는 서비스라면 충분히 사용할만한 가치가 있습니다.

profile
You must do the things you think you cannot do

0개의 댓글