db pk autoincrement vs uuid

[yoonminsang]

처음에 공부할때는 보통 db pk로 autoincrement를 사용한다. 근데 어느순간 autoincrement의 문제점을 깨닫는다. 유저에게 노출되지 않는다면 상관없지만 유저에게 id가 노출되는 경우 현재 몇개의 데이터가 생성되었는지 알게되고 이는 경쟁사에서 데이터 분석을 할 수도 있고 무단 접근도 더 쉬워진다. 그래서 uuid를 사용하는 경우도 있다. 과거에는 시간정렬이 어려웠지만 uuid v7부터는 시간정렬도 가능하다. 이로인해 b-tree 인덱스접근 속도 차이도 거의 없어졌다.

그러면 이제 유저에게 노출되는 id가 필요한 db는 무조건 uuid로 변경하는게 좋은걸까? 하나 걸리는건 저장공간이 더 길어지고 url도 길어진다는 것이다.(약간이지만 성능문제도 존재)

그래서 claude에게 100만 MAU, 100만 유저정도로 가정하고 성능비교를 해달라고 했다. 결론은 그냥 uuid를 사용하라고 한다. 여전히 autoincrement 많이 사용하는 것 같은데.. 음.. 잘 모르겠다. 나중에 백엔드 개발자에게 물어봐야겠다.

저장 공간

• INT (4 bytes): 4MB (1M users)
• BIGINT (8 bytes): 8MB
• UUID (16 bytes): 16MB
• 인덱스 포함해도 수십~수백 MB 수준. 요즘 스토리지 가격 고려하면 완전히 무시 가능한 수준.

성능 차이

• UUID v7은 timestamp 프리픽스 때문에 auto-increment와 성능 차이가 거의 없어:

삽입 성능:

• Auto-increment: 순차 삽입 → B-tree 리프 노드 끝에 계속 추가 (최적)
• UUID v7: 타임스탬프 순이라 거의 순차 삽입 → 성능 차이 5~10% 정도
• UUID v4: 완전 랜덤 → 인덱스 페이지 분할 많이 발생, 30~50% 느림

조회 성능:

• PK 조회는 둘 다 O(log n), 차이 거의 없음
• 100만 건이면 인덱스 깊이 3~4 레벨 정도, 실질적 차이 무시 가능

100만 MAU 규모에서:

• TPS(초당 트랜잭션) 1000~5000 정도로 예상
• 최신 DB 하드웨어면 UUID v7 써도 전혀 병목 안 됨
• 10억 건 이상 가거나 초당 수만 건 insert 되는 수준이 아니면 체감 불가

실무 경험상

~1000만 레코드: 차이 없음
1억~10억: UUID v7이면 문제 없음, v4는 좀 느려짐
10억+: 진지하게 샤딩/파티셔닝 고민할 시점, ID 방식보다 아키텍처가 중요

결론: 네 규모에서는 UUID v7 써도 성능상 전혀 문제없어. 오히려 보안, 분산 생성, 마이그레이션 용이성 등의 장점이 미미한 성능 차이를 압도해. 저장 공간 12MB 더 쓰는 건 2024년 기준으로는 고민할 가치도 없는 수준이고.
진짜 성능 병목은 보통 복잡한 조인, 인덱스 설계 미스, N+1 쿼리 이런 데서 나와. PK 타입은 거의 영향 없어.