식별자 설계 - 4

좋은 식별자를 선택하는 방법

지난 글에서는 좋은 식별자가 갖춰야 하는 조건에 대해 알아봤다.

그런데 실제 모델링을 하다 보면 한 가지 궁금증이 생긴다.

“후보 식별자가 여러 개라면 뭘 기본 식별자로 선택해야 하지?”

이번에는 이 이야기를 해보려고 한다.

회원(Entity)을 하나 만들어 보자.

회원을 구분할 수 있는 값은 생각보다 많다.

• 회원번호
• 이메일
• 휴대폰번호
• 아이디

모두 중복되지 않는다고 가정하면 모두 후보 식별자가 될 수 있다.

그런데 실제 시스템에서는 대부분 회원번호를 기본 식별자로 사용한다.

왜 그럴까?

---

변경되지 않는 것이 가장 중요하다.

좋은 식별자의 조건 중에서 가장 중요한 것을 하나만 꼽으라고 하면 나는 변경되지 않는 것이라고 말하고 싶다.

이메일은 바뀔 수 있다.

휴대폰 번호도 바뀔 수 있다.

아이디도 정책에 따라 변경을 허용하는 서비스가 있다.

하지만 회원번호는?

대부분의 시스템에서 한 번 생성되면 절대 바뀌지 않는다.

데이터베이스는 수많은 테이블이 서로 연결되어 있다.

만약 기본 식별자가 변경된다면 그 값을 참조하는 모든 데이터도 함께 변경해야 한다.

규모가 커질수록 이런 작업은 생각보다 위험하다.

그래서 실무에서는 변경 가능성이 있는 값을 기본 식별자로 선택하지 않는다.

---

의미를 담지 않는 것이 오히려 좋다.

초보 모델러들은 종종 이런 질문을 한다.

“회원번호는 아무 의미도 없는데 굳이 왜 쓰나요?”

오히려 의미가 없기 때문에 사용하는 것이다.

예를 들어 주문번호에 날짜를 넣는 경우가 있다.

20260731000001

처음에는 보기 편하다.

하지만 시간이 지나면 문제가 생긴다.

번호 체계를 바꿔야 할 수도 있고,

해외 서비스를 시작할 수도 있고,

여러 서버에서 동시에 번호를 생성해야 할 수도 있다.

식별자 안에 의미를 많이 담을수록 나중에 수정해야 할 가능성도 커진다.

식별자는 식별만 하면 된다.

업무적인 의미는 다른 속성으로 관리하는 것이 훨씬 유연하다.

---

짧을수록 좋다.

식별자는 데이터베이스에서 가장 많이 사용되는 컬럼이다.

외래키가 되고,

JOIN 조건이 되고,

인덱스에도 계속 사용된다.

즉, 거의 모든 테이블이 기본 식별자를 참조한다고 봐도 된다.

그래서 특별한 이유가 없다면 식별자는 가능한 짧게 설계하는 것이 좋다.

---

실무에서는 이렇게 생각하면 된다.

후보 식별자가 여러 개 있다면 나는 항상 아래 순서대로 판단한다.

1. 유일한가?
2. 절대 변경되지 않는가?
3. NULL이 발생하지 않는가?
4. 길이가 짧은가?
5. 업무 규칙이 바뀌어도 그대로 사용할 수 있는가?

이 다섯 가지를 만족한다면 좋은 기본 식별자가 될 가능성이 높다.

---

마무리

이번까지 식별자에 대해 꽤 많은 이야기를 했다.

식별자는 단순히 데이터를 구분하기 위한 컬럼 하나가 아니다.

한 번 잘못 선택하면 시스템 전체에 영향을 주고, 반대로 처음부터 잘 설계하면 오랫동안 안정적인 모델을 유지할 수 있다.

실제로 좋은 데이터 모델과 그렇지 않은 데이터 모델의 차이는 거창한 곳에서 시작되지 않는다.

어떤 식별자를 선택했는가.

의외로 이런 작은 선택 하나가 프로젝트의 유지보수성을 크게 좌우한다.

다음 글부터는 엔터티와 엔터티를 연결하는 관계(Relationship) 에 대해 알아보려고 한다.

식별자가 엔터티를 구분하는 기준이었다면, 관계는 엔터티들이 어떻게 연결되고 어떤 의미를 가지는지를 정의하는 핵심 요소다.

좋은 모델링은 복잡한 기술에서 시작되지 않는다. 기본 원칙을 얼마나 충실하게 지켰는가에서 시작된다. 식별자는 그 첫 번째 원칙이다.