CNU SW 아카데미라는 교육의 교육생으로 참가하였을 때, 팀 프로젝트로 웹 서비스를 제작했었다.
이때 DB 스키마를 첫 설계할 때 데이터의 ID를 명시하는 UUID에 대해 처음 접하게 되었고, 이때 정리해 놓은 UUID에 대한 정보들을 포스팅 해볼까 한다.
📔UUID란 무엇일까?
UUID란 범용 고유 식별자로, 네트워크 상에서 서로 모르는 개체들을 구별하기 위해 만들어진 방법!
나는 처음에 UUID가 그러면 '다른 세상 속 어떤 다른 개체 데이터와 중복되지 않을까?' 하는 생각을 했었다.
하지만 그런 걱정은 필요 없다.
이는 UUID의 장점이기도 하기에 걱정하지 않아도 되며, 그게 바로 UUID의 장점 중 하나이다.
📔UUID 규칙
36개의 문자 (32개 문자 , 4개의 하이픈)로 된 8 - 4 - 4 - 4 - 12 라는 5개의 그룹을 하이픈으로 구분
📔중복 가능성 ?
UUID 표준에 따라 이름을 부여하면 고유성을 완벽하게 보장 할 수는 없지만, 실제 사용 상에서 중복될 가능성이 거의 없다고 인정되었다.
++ 실제 확률을 계산하였을 때, 곂치는 UUID가 생성될 확률은 약 '10의 23제곱 분의 1' 이라고 한다.
📔 그럼 UUID, 언제 사용해야 하는가?
UUID를 언제 사용해야 하는지를 확인하기 위해서, UUID의 장/단점을 확인해보고 이를 토대로 판단하는 것이 옳다고 생각했다.
😎 UUID 장점
- 세계적으로 고유한 키를 제작해 준다.
- 즉석에서 생성이 가능하다.
- 쉽게 추적이 불가능하다.
장점은 우리가 예상한 바와 비슷하다. 그러면 단점을 살펴보자.
🤔 UUID 단점
- ID의 연속성이 없다.
- ID 속 내제된 의미가 없다.
- DB 탐색속도 저하
- DB 용량 소모량 증가
나는 당시 3,4번째 단점이 신경쓰여 UUID가 굳이 필요하지 않아 보이는 테이블에 UUID를 사용 여부를 고민했었다.
🤔그러면 Auto Increment(자동으로 넘버링을 하는 ID 생성법)를 사용해도 전혀 지장이 없을 것만 같은데 도대체 왜? UUID를 사용하는 거지?
내가 이때, 장/단점을 공부하면서 든 결론은 이것이다.
UUID를 사용하는 경우엔 두가지 케이스가 있다.
- 보호하려는 데이터가 있을 경우
만약 나의 데이터가 회원 정보처럼 타인에 의해 노출되지 않아야 한다면 UUID를 Primary Key로 사용하는 것을 권장한다.
회원에 관한 정보가 기본 정수로 ID가 매겨져 있다면 URL를 간단히 변경하여 특정 회원의 정보를 염탐할 가능성이 있기 때문이다.
2. 식별자로 사용할 경우
'당연히 PK니까 식별자로 사용하지 이게 무슨 뚱딴지 같은 소리냐?' 라고 할 수 있지만 UUID의 기능은 테이블 안에서만 유효한 것이 아니다. 말그대로 세계 고유의 PK이므로, UUID를 할당하고 싶은 데이터라면 그 데이터 고유가 개체로 식별되어야 하는지를 판단하는 것이 중요하다.
예를 들면 쇼핑 웹 서비스의 회원 데이터, 상품 데이터 등이 UUID로 사용될 수 있다. 하지만 문서 형식과 같은 카테고리 테이블은 Auto Increment를 사용하는 것이 더 효율적인 방법이다.
첫 블로그 포스팅 후기 )
개발일지 첫 포스팅인만큼 디자인에 많은 신경을 썼는데,, 생각보다 조금 힘이 드는 것 같다. 이걸 꾸준히 작성하는.. 많은 개발자분들 존경합니다 ㅠ.ㅠ 앞으로 많은 포스팅 예정이니 많관부 !
++) 해당 포스팅은 저의 개인적인 학습 정보입니다. 오해의 소지가 될 만한 정보, 잘못된 정보가 포스팅 내에 있다면 댓글로 알려주시면 감사하겠습니다.