[Primary Key 생성 전략] #2. DB Auto Increment (자동 증가 번호)

 

 

 

---

 

# 0. 들어가며

DB Auto Increment는 가장 단순하고 직관적인 Primary Key 생성 방식 중 하나입니다. 하지만 분산 환경에서는 문제가 발생할 수 있으며, 보안 취약점도 존재합니다.

 

 

---

 

# 1. DB Auto Increment의 기본적인 작동 방식

 

Auto Increment는 기본 키(Primary Key)로 숫자를 자동 증가시키는 기능입니다. 즉, 새로운 데이터가 추가될 때마다 기존 값보다 1 증가된 숫자가 자동으로 입력됩니다.

 

📌 예제 코드 (MySQL)

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,  -- 자동 증가하는 ID
    name VARCHAR(255) NOT NULL
);

 

📌 DBMS별 Auto Increment 지원 방식

DBMS	Auto Increment 기능
MySQL	AUTO_INCREMENT
Oracle	SEQUENCE
PostgreSQL	SERIAL 또는 BIGSERIAL
SQL Server	IDENTITY(1,1)

 

 

---

 

# 2. DB Auto Increment의 장점과 단점

 

장점 

✔ 간단하고 직관적입니다.

• 특별한 로직 없이, 기본 키를 자동으로 증가시켜줍니다.
• 개발자가 따로 관리할 필요가 없습니다.

 

✔ 숫자로 정렬되어 있어서 검색 속도가 빠릅니다

• Primary Key가 순차적으로 증가하기 때문에 인덱스 관리가 효율적입니다.
• 범위 검색(BETWEEN 연산)도 빠르게 처리할 수 있어요.

 

✔ 저장 공간이 적게 듭니다

• INT(4바이트)나 BIGINT(8바이트)를 사용하면, UUID(16바이트)보다 훨씬 작아서 DB 용량이 절약됩니다.

 

 

단점

✔ 분산 환경에서는 중복 문제가 발생할 수 있습니다.

• Auto Increment는 한 개의 데이터베이스에서 동작할 때는 문제가 없습니다. 하지만 여러 개의 서버(Sharding 환경)를 사용하면, 서버마다 ID가 1부터 시작할 수도 있어서 중복 문제가 발생할 수 있습니다.

 

✔ 보안 문제 : 사용자가 데이터 개수를 예측할 수 있습니다.

• 사용자가 자신의 ID를 보면, 사이트의 데이터 개수를 유추할 수 있습니다.
  • 예: 회원 가입 후 id=1000이라면, "1000명이 가입했겠다" 유추할 수 있습니다. 
• 해커가 id=999, id=998 이런 식으로 입력해 다른 사용자의 정보를 조회하려고 시도할 수도 있습니다.

 

✔  삭제 후 재사용 문제

• 데이터를 삭제하면 ID가 다시 채워지지 않고 계속 증가합니다.
  • 예: id=1, id=2, id=3 → id=2를 삭제하면, 다음 ID는 id=4가 됩니다

• 중간 번호가 비는 경우가 발생하여, 개발자가 신경 써야 합니다.

 

 

---

 

# 3. 분산 환경에서 발생하는 문제 : 충돌

 

샤딩(Sharding)이란, 데이터베이스 성능을 향상시키기 위해 데이터를 여러 개의 서버(DB 인스턴스)로 분산 저장하는 방식입니다.  즉, 한 개의 데이터베이스가 처리할 수 있는 용량을 초과할 경우, 데이터를 여러 개의 노드(서버)로 분할하여 저장하면 성능이 향상될 수 있습니다. 단일 서버에서는 Auto Increment가 문제없지만, 샤딩 환경에서는 같은 ID가 여러 서버에서 생성될 수 있습니다.

 

📌 예제 상황 ➡️ 서버마다 ID가 중복될 수 있어서 문제 발생!

• 서버 A: id = 1, 2, 3...
• 서버 B: id = 1, 2, 3... (충돌 발생)

 

서버 A와 서버 B가 동시에 새로운 데이터를 삽입하면, 서버마다 같은 ID가 생성될 가능성이 있습니다. 결국, ID가 고유하지 않으면 데이터 충돌이 발생하여 중복된 레코드가 저장될 위험이 있습니다. 이러한 데이터 충돌은 Join 및 검색 오류를 발생시키기도 하며, 트랜잭션 충돌 가능성을 높여 특정 데이터를 업데이트 하거나 삭제할 때 잘못된 데이터가 처리될 수도 있습니다. 

 

---

 

# 4. 보안 문제 : 데이터 개수 예측 가능

 

Auto Increment는 예측 가능한 값(순차적 증가 숫자)을 생성하기 때문에, 해커나 악의적인 사용자가 ID를 예측하여 공격할 수 있는 취약점이 존재합니다.

 

📌 예제 상황 ➡️ ID를 예측하여 공격할 수 있는 취약점 발생! 

• id=1000인 사용자가 새로 가입함
• 그는 "이 사이트엔 1000명의 사용자가 있겠군!" 하고 예측 가능
• id=999, id=998을 입력해 이전 회원들의 정보를 추출하려는 시도를 할 수도 있음

 

만약 API에서 적절한 인증 및 권한 검증이 이루어지지 않는다면, 다른 사용자의 정보를 쉽게 접근할 수 있는 위험이 있습니다.

 

 

---

 

# 5. 해결 방법

 

✅  해결 방법 1: Sharding Key 추가 (서버마다 다른 범위 설정)

서버마다 다른 범위에서 Auto Increment를 시작하면 중복을 방지할 수 있습니다.

 

📌 예제 상황 ➡️ 서버마다 ID가 중복될 수 있어서 문제 발생!

• 서버 A: id = 1, 2, 3...
• 서버 B: id = 1001, 1002, 1003...

 

✅  해결 방법 2: 내부 식별자와 외부 식별자 분리

DB 내부에서는 Auto Increment 사용, 외부에서는 UUID 사용하는 식으로 해서 사용자는 내부 ID에 접근할 수 없게 만들어 데이터의 개수를 추측할 수 없게 만듭니다. 이렇게 분리하여 사용하면 보안성을 높일 수 있습니다. 

 

📌 예제 상황 ➡️ 내부로 Auto Increment 사용하고 외부로 UUID 사용

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,  
    uuid CHAR(36) UNIQUE NOT NULL,  
    name VARCHAR(255) NOT NULL
);

 

 

---

 

# 6. 결론

 

✅ 단일 서버 환경에서 간단한 서비스라면 Auto Increment를 그대로 사용해도 좋습니다.
✅ 분산 환경이라면 Sharding Key를 적용하거나 다른 Primary Key 생성 전략을 이용하는 것이 좋습니다.
✅ 보안이 중요한 서비스에서는 외부 식별자와 내부 식별자를 구분하여 사용하면 데이터 보호가 가능합니다.