# 자연 키를 사용하는 것을 후회하게 될 꺼에요

> Clean Markdown view of GeekNews topic #15198. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=15198](https://news.hada.io/topic?id=15198)
- GeekNews Markdown: [https://news.hada.io/topic/15198.md](https://news.hada.io/topic/15198.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-06-06T09:45:08+09:00
- Updated: 2024-06-06T09:45:08+09:00
- Original source: [blog.ploeh.dk](https://blog.ploeh.dk/2024/06/03/youll-regret-using-natural-keys/)
- Points: 5
- Comments: 2

## Topic Body

- 자연(Natural) 키는 데이터베이스에서 고유성을 보장하기 위해 사용되는 키임  
- 자연 키는 이름, 도시, 연도 등과 같은 실제 데이터를 기반으로 함  
- 예를 들어, 세계 최고의 50개 레스토랑 데이터베이스에서 `restaurantName`, `cityName`, `year`를 자연 키로 사용할 수 있음  
- 그러나 자연 키는 고유성을 보장하지 못할 수 있음. 예를 들어, 같은 이름의 레스토랑이 여러 도시에 있을 수 있음  
  
#### 정체성  
  
- 자연 키는 고유성을 보장하는 것 외에도 정체성을 보장해야 함  
- 예를 들어, 자동차의 차대 번호나 개인 식별 번호(CPR 번호)를 자연 키로 사용할 수 있음  
- 그러나 동일한 사람이 여러 개의 식별 번호를 가질 수 있음. 예를 들어, 덴마크에서는 성전환자가 새로운 CPR 번호를 받을 수 있음  
  
#### 서류 오류  
  
- 자연 키는 서류 오류에 취약함  
- 데이터 입력 오류, 사용자 오타, 데이터 변환 오류 등이 발생할 수 있음  
- 시스템은 이러한 오류를 수정할 수 있어야 함. 따라서 외부 키를 데이터베이스 키로 사용하는 것은 적절하지 않음  
  
#### 결론  
  
- 자연 키를 데이터베이스 설계에서 사용하는 것은 좋은 아이디어가 아님  
- 데이터 오류가 발생할 수 있으며, 이러한 오류를 수정할 수 있어야 함  
- 따라서 데이터베이스 테이블에는 항상 인공 키를 사용하는 것이 좋음  
  
### GN⁺의 의견  
  
- **자연 키의 문제점**: 자연 키는 고유성과 정체성을 보장하지 못할 수 있으며, 데이터 입력 오류에 취약함.  
- **인공 키의 장점**: 인공 키는 고유성과 정체성을 보장하며, 데이터 오류를 쉽게 수정할 수 있음.  
- **ORM 사용 시 고려사항**: ORM 라이브러리를 사용할 때는 인공 키를 사용하는 것이 더 쉬움. ORM은 데이터베이스 구조를 일정 부분 결정하기 때문에, 인공 키를 사용하는 것이 더 효율적임.  
- **비슷한 기능의 제품**: 다른 데이터베이스 설계 도구나 ORM 라이브러리도 인공 키 사용을 권장함. 예를 들어, Hibernate, Entity Framework 등이 있음.  
- **기술 도입 시 고려사항**: 새로운 데이터베이스 설계를 도입할 때는 자연 키의 단점을 고려하고, 인공 키를 사용하는 것이 좋음. 인공 키는 데이터 무결성을 보장하고, 오류를 쉽게 수정할 수 있음.

## Comments



### Comment 25969

- Author: neo
- Created: 2024-06-06T09:45:09+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=40580549) 
- **고유하고 짧으며 사람이 읽기 쉬운 ID**: Stripe에서 사용하는 `cus_MJA953cFzEuO1z` 같은 ID를 선호함. JavaScript/TypeScript로 생성하는 방법도 있음.
- **개인 식별 번호**: 덴마크의 CPR 번호와 미국의 SSN을 비교. SSN은 고유하지 않으며, 변경될 수 있고, 미국 시민이 아니어도 발급 가능함. 데이터베이스 키로 사용하지 말 것을 권장.
- **별칭과 감사 로그**: 덴마크 CPR 번호와 같은 자연 키를 사용할 때, 변경 사항을 기록하는 별도의 테이블이 필요함. URL도 자연 키로 사용 가능하지만 변경 시 리디렉션 테이블을 만들어야 함.
- **자연 키의 한계**: 고유 식별자가 변경되면, 모든 관련 정보를 추적해야 함. 인위적인 키를 추가하면 추적해야 할 정보가 더 많아짐. 데이터 모델링은 현실 세계를 반영해야 함.
- **자연 키와 개인정보 보호**: 자연 키에 개인 정보가 포함되면, 외래 키를 통해 다른 테이블에도 전파될 수 있음.
- **게임 태그 예시**: PlayStation Network의 게임 태그를 자연 키로 사용하는 예시. 게임 태그가 변경되지 않으면 고유 식별자로 사용 가능함.
- **의료 분야 예시**: 등록 직원이 잘못된 개인 건강 번호(PHN)를 입력하면 문제가 발생함. 인위적인 키를 사용하면 나중에 정정 가능함.
- **자연 키의 통제 불가능성**: 이름, 주소, 공식 등록 번호 등은 통제할 수 없기 때문에 신뢰할 수 없음. 고유 키 시스템을 사용해야 함.
- **인위적인 키 사용**: 모든 테이블에 고유 ID 필드를 사용하면 문제 해결이 쉬워짐. 데이터와 관계가 자주 변경되기 때문에 자연 키를 믿기 어려움.
- **변경 가능성과 고유 ID**: 변경 가능성은 시간에 걸쳐 공통된 식별자를 필요로 함. 데이터베이스는 명시적인 대리 키를 스키마에 포함해야 함.

### Comment 25991

- Author: jsonobject
- Created: 2024-06-07T08:53:56+09:00
- Points: 2
- Parent comment: 25969
- Depth: 1

인공키도 글로벌 리전 등에 대응하는 분산 환경에 대응 준비가 되어 있는 TSID를 사용하는 것을 추천합니다. 저는 MySQL, DynamoDB에서 PK로 TSID를 사용합니다.  
  
https://jsonobject.hashnode.dev/using-tsid-as-database-pk