226 lines
7.0 KiB
Markdown
226 lines
7.0 KiB
Markdown
# 게시판 글 ID 설계 방식
|
|
|
|
게시판 글 ID(Primary Key 및 식별자)는 조회 성능, 보안, 분산 환경 지원 여부, URL 가독성 등에 따라 여러 방식으로 설계할 수 있음.
|
|
|
|
## 1. 자동 증가 정수형
|
|
|
|
### Auto Increment / Sequence
|
|
|
|
MySQL의 `AUTO_INCREMENT`, PostgreSQL의 `BIGSERIAL` 또는 `IDENTITY`를 사용하는 전통적인 방식.
|
|
|
|
| 구분 | 내용 |
|
|
|---|---|
|
|
| 형태 | `1`, `2`, `3`, `4`, ... |
|
|
| 저장 방식 | `INT` 또는 `BIGINT` |
|
|
| 구현 난이도 | 가장 낮음 |
|
|
| 인덱스 성능 | 매우 좋음 |
|
|
|
|
### 장점
|
|
|
|
- 구현이 가장 쉽고 직관적임
|
|
- 저장 용량이 적음
|
|
- B-Tree 인덱스 정렬 성능이 좋음
|
|
- 최신 글 순서대로 자동 정렬하기 쉬움
|
|
|
|
### 단점
|
|
|
|
- 다음 글 번호를 쉽게 추측할 수 있음
|
|
- 크롤링이나 글 수량 파악에 취약할 수 있음
|
|
- 분산 DB 또는 멀티 마스터 환경에서 충돌 없이 발급하기 어려움
|
|
|
|
### 적합한 사용처
|
|
|
|
- 사내 인트라넷
|
|
- 관리자 전용 게시판
|
|
- 단일 DB 인스턴스 환경
|
|
|
|
## 2. UUID v4
|
|
|
|
### 완전 랜덤 128비트 식별자
|
|
|
|
전 세계에서 고유한 값을 무작위로 생성하는 표준 방식.
|
|
|
|
| 구분 | 내용 |
|
|
|---|---|
|
|
| 형태 | `c9a646d3-9c61-4cc9-bc19-482386a37365` |
|
|
| 저장 방식 | UUID 또는 `CHAR(36)` 등 |
|
|
| 생성 방식 | 완전 랜덤 |
|
|
| 분산 환경 | 지원 |
|
|
|
|
### 장점
|
|
|
|
- 중복 가능성이 매우 낮음
|
|
- 중앙 조율 없이 생성 가능함
|
|
- 다음 ID를 추측하기 어려움
|
|
- 분산 서버 환경에 적합함
|
|
|
|
### 단점
|
|
|
|
- 36자 문자열이라 URL이 길고 복잡함
|
|
- 완전 랜덤 값이라 B-Tree 인덱스 페이지 분할이 자주 발생할 수 있음
|
|
- 대량 입력 환경에서 정수형보다 쓰기 성능이 낮을 수 있음
|
|
|
|
### 적합한 사용처
|
|
|
|
- 외부 API 통신 식별자
|
|
- 추측 방지가 중요한 비즈니스 데이터
|
|
- 분산 시스템
|
|
|
|
## 3. 시간 순 정렬 가능 고유 식별자
|
|
|
|
### UUID v7 / ULID
|
|
|
|
UUID의 고유성과 Auto Increment의 시간 정렬 장점을 결합한 방식.
|
|
|
|
| 방식 | 예시 |
|
|
|---|---|
|
|
| UUID v7 | `018d3b2f-7a54-7c3a-8b1e-9d2a4e5b6c7d` |
|
|
| ULID | `01ARZ3NDEKTSV4RRFFQ69G5FAV` |
|
|
|
|
### 장점
|
|
|
|
- 생성된 시간 순으로 정렬 가능함
|
|
- B-Tree 인덱스에 순차적으로 적재되어 쓰기 성능이 좋음
|
|
- 분산 환경에서 충돌 없이 생성 가능함
|
|
- 다음 ID를 추측하기 어려움
|
|
|
|
### 단점
|
|
|
|
- 정수형보다 저장 공간을 많이 사용함
|
|
- UUID v4보다 생성 규칙이 복잡함
|
|
- ID만 보고 생성 시점을 일부 추정할 수 있음
|
|
|
|
### 적합한 사용처
|
|
|
|
- 대용량 트래픽 게시판
|
|
- 분산 서비스
|
|
- 최신 웹 애플리케이션
|
|
|
|
## 4. 트위터 스노우플레이크
|
|
|
|
### Snowflake
|
|
|
|
대량의 데이터를 분산 환경에서 생성하기 위해 고안된 64비트 정수 기반 방식.
|
|
|
|
### 기본 구조
|
|
|
|
```text
|
|
타임스탬프 41비트 + 데이터센터/머신 ID 10비트 + 시퀀스 번호 12비트
|
|
```
|
|
|
|
### 예시
|
|
|
|
```text
|
|
1542893478912349184
|
|
```
|
|
|
|
### 장점
|
|
|
|
- 64비트 정수라 인덱싱 성능이 좋음
|
|
- 시간 순 정렬이 가능함
|
|
- 분산 서버 간 ID 충돌을 방지할 수 있음
|
|
- 대규모 시스템에서 높은 처리량을 지원함
|
|
|
|
### 단점
|
|
|
|
- 별도의 ID 생성기 또는 Worker 관리가 필요함
|
|
- 데이터센터 및 머신 ID 관리가 필요함
|
|
- JavaScript에서 일반 숫자로 처리하면 정밀도 손실이 발생할 수 있음
|
|
- Auto Increment보다 운영 복잡도가 높음
|
|
|
|
### 적합한 사용처
|
|
|
|
- 대규모 분산 SNS
|
|
- 초대형 커뮤니티
|
|
- 초당 수천 건 이상의 글이 등록되는 서비스
|
|
|
|
## 5. 해시 기반 난독화
|
|
|
|
### Sqids / Hashids
|
|
|
|
DB에는 정수형 ID를 저장하고, URL이나 외부 화면에서는 별도의 문자열로 변환하여 표시하는 방식.
|
|
|
|
| 구분 | 예시 |
|
|
|---|---|
|
|
| 내부 DB ID | `1204` |
|
|
| 외부 URL ID | `b9Xq` |
|
|
|
|
### 장점
|
|
|
|
- DB에서는 정수형 인덱스 성능을 유지할 수 있음
|
|
- 짧고 깔끔한 URL을 만들 수 있음
|
|
- 외부에서 원래 순번을 바로 유추하기 어려움
|
|
- 기존 정수형 DB 구조를 유지하면서 URL만 변경할 수 있음
|
|
|
|
### 단점
|
|
|
|
- 내부 ID와 외부 표시 ID가 달라짐
|
|
- 암호화가 아니라 인코딩에 가까움
|
|
- 시크릿 솔트가 노출되면 원래 정수값을 역산할 수 있음
|
|
- 운영자가 같은 글을 서로 다른 ID로 인식할 수 있음
|
|
|
|
### 적합한 사용처
|
|
|
|
- 외부 URL을 짧게 만들고 싶은 서비스
|
|
- 기존 정수형 DB를 유지하면서 외부 노출만 바꾸려는 서비스
|
|
- YouTube와 같은 짧은 식별자가 필요한 서비스
|
|
|
|
## 6. 비즈니스 접두사 결합형
|
|
|
|
### Stripe 스타일 ID
|
|
|
|
글의 종류나 도메인을 식별할 수 있도록 ID 앞에 접두사를 붙이는 방식.
|
|
|
|
### 예시
|
|
|
|
```text
|
|
post_01ARZ3NDEKTSV4RRFFQ69G5FAV
|
|
qna_01ARZ3NDEKTSV4RRFFQ69G5FAV
|
|
fb_202609_a8f3d
|
|
```
|
|
|
|
### 장점
|
|
|
|
- ID만 보고도 데이터 종류를 구분할 수 있음
|
|
- 로그나 알림에서 식별이 쉬움
|
|
- API 중심 서비스에 적합함
|
|
- 디버깅과 모니터링이 편리함
|
|
|
|
### 단점
|
|
|
|
- 숫자만 사용하는 방식보다 ID가 길어짐
|
|
- 글 종류가 변경되면 접두사 정책도 고려해야 함
|
|
- 단순한 게시판에서는 다소 복잡할 수 있음
|
|
|
|
### 적합한 사용처
|
|
|
|
- API 중심 B2B SaaS
|
|
- 여러 유형의 게시물이 함께 존재하는 시스템
|
|
- 로그와 웹훅에서 데이터 유형을 즉시 구분해야 하는 서비스
|
|
|
|
## 방식별 비교
|
|
|
|
| 방식 | 저장 타입 | URL 길이 | 분산 환경 | 인덱스 성능 | 추측 방지 | 적합한 상황 |
|
|
|---|---|---:|:---:|:---:|:---:|---|
|
|
| Auto Increment | `INT` / `BIGINT` | 매우 짧음 | 낮음 | 매우 좋음 | 낮음 | 내부 관리용, 소규모 서비스 |
|
|
| UUID v4 | UUID / `CHAR` | 김 | 높음 | 보통 | 높음 | 보안이 중요한 데이터 |
|
|
| UUID v7 / ULID | UUID / 16바이트 등 | 중간 | 높음 | 좋음 | 높음 | 대용량·분산 웹 서비스 |
|
|
| Snowflake | `BIGINT` | 짧음 | 높음 | 매우 좋음 | 보통 | 대규모 분산 시스템 |
|
|
| Sqids / Hashids | DB는 정수형 | 외부는 짧음 | 낮음 | 매우 좋음 | 보통 | URL 난독화가 필요한 경우 |
|
|
| 접두사 결합형 | 문자열 또는 조합형 | 중간~김 | 방식에 따라 다름 | 방식에 따라 다름 | 방식에 따라 다름 | API·로그 식별이 중요한 경우 |
|
|
|
|
## 검토할 때 확인할 기준
|
|
|
|
ID 방식을 선택할 때는 다음 항목을 함께 확인해야 함.
|
|
|
|
1. 화면에 표시되는 ID와 DB의 실제 ID를 같게 유지할 것인지
|
|
2. 프로젝트마다 번호를 새로 시작할 것인지
|
|
3. 프로젝트를 넘어선 전체 글 번호가 필요한지
|
|
4. 피드백과 이슈가 같은 번호 체계를 사용할 것인지
|
|
5. 외부 Q&A 원본 ID와 관리페이지 ID를 어떻게 연결할 것인지
|
|
6. URL에서 ID를 직접 노출할 것인지
|
|
7. 단일 서버인지 분산 서버인지
|
|
8. 향후 글 수가 얼마나 증가할지
|
|
|
|
특히 내부 DB ID와 화면 표시 ID를 별도로 운영하면, 운영자가 같은 글을 서로 다른 번호로 인식할 수 있으므로 표시 정책을 먼저 확정해야 함.
|