PK값을 increment PK vs UUID (커스텀ID), 어떤 것을 사용해야할까?

[taeGnues]

현상 및 문제점

주문번호(merchantUid), 반품ID(refundId), 교환ID(exchangeId)는 외부에 반드시 노출되는 pk값이다.
이런 경우 auto increment를 쓰는게 맞을까?

시도

https://americanopeople.tistory.com/378

• UUID는 안전하지만, 용량이 매우 크다.
• 즉, PK가 외부에 노출되지 않는다면 increment PK를 쓰고 외부에 노출된다면, UUID를 권장한다.

최종해결책

• PK 전략을 UUID 대신 무신사에서 쓰이는 번호 양식으로 선정했다.
• 주문번호는 String으로 설정하고, 'yymmddhhss + 무작위숫자8자리' 로 설정
• 반품ID는 String으로 설정하고, 'R + yymmddhhss + 무작위숫자8자리' 로 설정
• 교환ID는 String으로 설정하고, 'E + yymmddhhss + 무작위숫자8자리' 로 설정

참고자료

https://cl8d.tistory.com/115
https://0soo.tistory.com/177

[jskim2x]

그럼 https://americanopeople.tistory.com/378 <- 이 내용에 따르면, 상품 조회 API를 만들때, 각 Product들의 id값(PK)들을 응답 바디로 보내는 행위도 위험한 것일까요?

[taeGnues]

@kim-ji-seop 넵 제 생각에는 애초에 네트워크타서 외부로 노출되는 PK들은 위험할꺼같아요 .. 사실 프론트 부분을 자세히 알진 몰라서 그렇지만, 일단은 외부에서 통신할 때 사용되는데, 유추 가능한형태의 PK들(auto increment 등)은 사용을 자제하는 편이 좋지않을까 하는 생각입니다!

그리고 사실 응답바디에 넣는다고 보안이 좋은건 아니여서 ,,ㅎㅎ

지금 또 생각이 든건 만약 pk값을 넣는다면 저희 jwt 저장하는 것처럼 암호화해서 주고받는게 좋지 않을까 하는 생각이 듭니다