급여 시스템의 데이터베이스를 설계할 때, 기본키(Primary Key)를 어떻게 정할지 고민이 많았다. AUTO_INCREMENT vs UUID. UUID 생성기를 보면서 UUID의 장단점을 분석해봤다.
AUTO_INCREMENT의 문제
AUTO_INCREMENT는 간단하지만 몇 가지 문제가 있다.
- ID 추측 가능: 1, 2, 3... 순서라 다른 사람 급여를 추측 가능
- 분산 환경 충돌: 여러 서버에서 동시 INSERT 시 충돌
- 데이터 규모 노출: ID가 100만이면 100만 건 있다는 뜻
UUID의 장점
UUID는 128비트 고유 식별자로, 충돌 확률이 사실상 0이다.
const { v4: uuidv4 } = require("uuid"); const id = uuidv4(); // 550e8400-e29b-41d4-a716-446655440000
comusin.kr/uuid-generator에서 UUID를 생성해볼 수 있다.
UUID의 단점
UUID도 완벽하지 않다.
- 36자로 길어서 저장 공간 차지
- 사람이 읽기 어려움
- 인덱스 성능 이슈 (무작위라 B-tree 분산)
ULID, Snowflake ID
UUID의 단점을 보완한 대안들이 있다. ULID는 시간순 정렬이 가능한 UUID 호환 ID다. Snowflake ID는 64비트로 짧으면서 시간순이다.
UUID 생성을 기본으로 하되, 성능이 중요하면 ULID나 Snowflake를 검토한다.
급여 시스템 적용
급여 시스템에서는 보안이 중요하니 UUID를 기본으로 쓰는 게 좋다. 직원ID, 급여ID, 명세서ID 등을 UUID로 생성한다. 로그에서 ID가 노출되어도 다른 데이터를 추측할 수 없다.
마이그레이션
기존 AUTO_INCREMENT 시스템을 UUID로 마이그레이션하는 건 까다롭다. 새 UUID 컬럼을 추가하고, 외래키 관계를 모두 업데이트해야 한다. 신규 테이블부터 UUID를 적용하는 게 현실적이다.
결론
보안과 분산 환경을 고려하면 UUID가 좋은 선택이다. 생성이 필요할 때 온라인 UUID 생성기를 활용해보자.