# 데이터 식별 (Data Identification)

## 1. 개요
**데이터 식별**이란 방대한 데이터 세트 내에서 특정 데이터 개체(Entity)를 다른 개체와 혼동 없이 고유하게 구분하여 찾아낼 수 있도록 정의하는 프로세스를 의미한다. 데이터 식별은 데이터베이스의 키 설정을 포함하여, 전사적 데이터 거버넌스 차원에서 데이터의 유일성을 보장하고 추적 가능성(Traceability)을 확보하는 전 과정을 포함한다.

현대의 데이터 관리 환경에서는 데이터의 양이 기하급수적으로 증가하고 여러 시스템에 분산 저장되기 때문에, 데이터의 무결성(Integrity)을 유지하고 정확한 참조를 가능하게 하는 고유 식별자의 설정이 필수적이다. 데이터 식별이 제대로 이루어지지 않을 경우 데이터 중복, 참조 오류, 데이터 유실 등의 심각한 품질 저하 문제가 발생할 수 있다.

*참고: 본 문서에서는 논리적 설계 단계의 '엔티티(Entity)'와 물리적 구현 단계의 '레코드(Record)'를 구분하여 사용한다.*

## 2. 데이터 식별의 기본 원리
데이터 식별의 핵심은 **식별자(Identifier)**를 설정하는 것이다. 식별자란 개체를 유일하게 구분할 수 있는 속성 또는 속성들의 집합을 말한다. 효과적인 식별자가 되기 위해서는 다음과 같은 필수 속성을 갖추어야 한다.

*   **고유성 (Uniqueness):** 동일한 도메인 내에서 서로 다른 두 개체는 반드시 서로 다른 식별자 값을 가져야 한다.
*   **불변성 (Immutability):** 한 번 부여된 식별자는 개체의 생명주기 동안 변경되지 않아야 한다. 식별자가 변경되면 이를 참조하는 모든 외부 데이터의 연결 고리가 끊어지기 때문이다.
*   **최소성 (Minimality):** 식별자를 구성하는 속성은 고유성을 보장하기 위한 최소한의 집합이어야 하며, 불필요한 정보가 포함되지 않아야 한다.
*   **존재성 (Existence):** 식별자 값은 `NULL`이 될 수 없으며, 반드시 값이 존재해야 한다.

### [표 1] 자연 키(Natural Key) vs 인조 키(Surrogate Key) 비교

| 구분 | 자연 키 (Natural Key) | 인조 키 (Surrogate Key) |
| :--- | :--- | :--- |
| **정의** | 비즈니스적으로 이미 존재하는 고유 속성 | 시스템에서 식별을 위해 인위적으로 생성한 값 |
| **예시** | 주민등록번호, 이메일, ISBN, 차량번호 | 일련번호(Sequence), UUID, Auto-increment ID |
| **장점** | 별도의 생성 로직 불필요, 데이터 의미 파악 용이 | 비즈니스 로직 변경에 영향 없음, 성능 최적화 유리 |
| **단점** | 비즈니스 규칙 변경 시 식별자 변경 위험 존재 | 데이터 자체로는 의미가 없으며 추가 조회 필요 |

## 3. 데이터 식별자의 종류 및 유형
데이터가 사용되는 환경과 목적에 따라 식별 방식은 다음과 같이 분류된다.

### 3.1 환경별 식별자 분류
*   **비즈니스 식별자 (Business Identifier):** 실제 업무 프로세스에서 사용되는 식별자로, 사용자가 인지할 수 있는 값이다. (예: 주문번호, 고객번호)
*   **시스템 식별자 (System Identifier):** 데이터베이스 내부 관리나 시스템 간 연동을 위해 생성된 값으로, 사용자에게는 노출되지 않는 경우가 많다. (예: DB Primary Key)
*   **글로벌 식별자 (Global Identifier):** 서로 다른 시스템이나 조직 간에 데이터를 교환할 때 충돌 없이 식별하기 위한 표준화된 값이다. (예: URI, DOI)

### 3.2 주요 식별자 생성 방식 비교

| 방식 | 특징 | 장점 | 단점 | 생성 예시 |
| :--- | :--- | :--- | :--- | :--- |
| **Auto-increment** | 정수형 값을 1씩 증가시키며 부여 | 저장 공간 효율적, 정렬 속도 빠름 | 분산 환경에서 중복 발생 가능, 예측 가능함 | `1`, `2`, `3` ... |
| **Sequence** | DB 객체로서 독립적인 번호 생성기 사용 | 여러 테이블에서 공유 가능, 동시성 제어 우수 | DB 종속적이며 네트워크 오버헤드 발생 가능 | `SEQ_USER_001`, `1001` ... |
| **UUID** | 128비트의 무작위 고유 식별자 생성 | 분산 시스템에서 충돌 가능성 극히 낮음 | 무작위성으로 인한 B-Tree 인덱스 파편화 발생 | `550e8400-e29b-41d4-a716-446655440000` |

> **Tip:** UUID의 인덱스 성능 저하를 해결하기 위해, 시간 순서가 포함되어 정렬 가능한 **ULID(Universally Unique Lexicographically Sortable Identifier)**나 **TSID** 등의 대안이 실무에서 사용된다.

## 4. 데이터 식별 프로세스 및 방법론
효과적인 데이터 식별을 위해서는 체계적인 절차와 표준화된 명명 규칙이 필요하다.

### 4.1 식별자 정의 단계 (RDBMS 기준)
1.  **대상 개체 분석:** 식별이 필요한 데이터 엔티티를 정의하고 속성을 분석한다.
2.  **후보 키(Candidate Key) 도출:** 고유성을 만족하는 속성들의 조합을 모두 찾아낸다.
3.  **기본 키(Primary Key) 선정:** 후보 키 중 불변성과 최소성이 가장 뛰어난 속성을 최종 식별자로 선정한다.
4.  **식별자 생성 전략 수립:** 자연 키를 사용할지, 인조 키를 생성할지 결정하고 생성 알고리즘을 정의한다.

### 4.2 명명 규칙 (Naming Convention)
데이터 표준화 가이드라인에 따라 식별자의 이름을 정의하여 가독성과 유지보수성을 높인다.
*   **형식:** `[엔티티명]_[식별자구분]` (예: `CUST_ID`, `ORD_NO`)
*   **일관성:** 동일한 의미의 식별자는 전사 시스템에서 동일한 용어를 사용한다.
*   **명확성:** `ID`, `NO`, `KEY` 등 식별자의 성격을 나타내는 접미사를 일관되게 부여한다.

### 4.3 식별자 생명주기 관리
식별자는 생성부터 폐기까지 다음과 같은 생명주기를 거치며 관리되어야 한다.

1.  **정의 및 생성 (Definition & Generation):** 데이터 모델링 단계에서 식별자 유형을 결정하고 생성 알고리즘을 구현하여 값을 부여한다.
2.  **할당 및 등록 (Allocation & Registration):** 데이터가 입력되는 시점에 고유한 값을 할당하고 메타데이터 저장소에 등록한다.
3.  **참조 및 활용 (Reference & Usage):** 다른 테이블이나 시스템에서 해당 식별자를 통해 데이터를 조회하고 관계를 맺는다.
4.  **변경 및 매핑 (Change & Mapping):** 시스템 통합이나 마이그레이션 시 식별자가 변경될 경우, 구 식별자와 신 식별자 간의 매핑 정보를 관리한다.
5.  **아카이빙 및 폐기 (Archiving & Disposal):** 데이터가 삭제되거나 보관 주기 만료 시, 해당 식별자와 연결된 모든 참조 데이터를 함께 처리하여 고립된 데이터(Orphan Data)가 남지 않도록 한다.

## 5. 데이터 식별의 활용 및 응용
식별자는 단순한 구분을 넘어 데이터 간의 관계를 형성하고 통합하는 기초가 된다.

### 5.1 관계형 데이터베이스(RDBMS) 적용
RDBMS에서는 기본키와 외래키를 통해 데이터 간의 관계를 정의하고 무결성을 유지한다.

| 구분 | 기본키 (Primary Key, PK) | 외래키 (Foreign Key, FK) |
| :--- | :--- | :--- |
| **역할** | 테이블 내 레코드를 유일하게 식별 | 다른 테이블의 PK를 참조하여 관계 형성 |
| **제약** | 중복 불가, NULL 불가 | 중복 가능, NULL 가능(설정에 따라) |
| **목적** | 개체 무결성 보장 | 참조 무결성 보장 |

```mermaid
erDiagram
    CUSTOMER ||--o{ ORDER : "places"
    CUSTOMER {
        string CUST_ID PK "고객 식별자"
        string NAME
    }
    ORDER {
        string ORD_NO PK "주문 식별자"
        string CUST_ID FK "고객 참조 식별자"
        date ORDER_DATE
    }
```

### 5.2 마스터 데이터 관리 (MDM) 및 통합
여러 시스템에 흩어져 있는 동일 개체의 데이터를 통합하기 위해 **골든 레코드(Golden Record)**를 생성한다. 이때 각 시스템의 서로 다른 식별자를 하나의 통합 식별자로 연결하는 **매핑 테이블(Mapping Table)**을 활용한다.

**매핑 테이블의 구조 및 역할:**
*   **구성:** `[통합 식별자(Global ID)] | [시스템 A 식별자] | [시스템 B 식별자] | [시스템 C 식별자]`
*   **역할:** 서로 다른 시스템에서 `CUST_001`(시스템 A)과 `USER_99`(시스템 B)가 동일 인물임을 정의함으로써, 전사적 관점에서 데이터 정합성을 유지하고 단일 뷰(Single View)를 제공한다.

## 6. 식별 관리 시 고려사항 및 한계
실무 적용 시 다음과 같은 기술적, 법적 제약 사항을 고려해야 한다.

*   **식별자 충돌 (Collision):** 특히 UUID나 해시 기반 식별자 사용 시, 이론적으로 동일한 값이 생성될 가능성이 존재한다. 이를 방지하기 위해 충분한 비트 길이를 확보해야 한다.
*   **비식별화 처리 (De-identification):** 개인정보 보호법에 따라 주민등록번호와 같은 민감한 식별자는 직접 저장하지 않는다.
    *   **마스킹(Masking):** `800101-1******`와 같이 일부를 가리는 방식.
    *   **토큰화(Tokenization):** 실제 값을 무작위 토큰으로 대체하고 별도의 보안 저장소에서 관리하는 방식.

## 7. 식별자 설계 체크리스트
설계 단계에서 다음 항목을 검토하여 식별자의 품질을 확보한다.

- [ ] **고유성:** 모든 레코드에 대해 중복 없는 값이 부여되는가?
- [ ] **불변성:** 비즈니스 로직 변경 시에도 이 값이 변하지 않는가?
- [ ] **최소성:** 식별자를 구성하는 속성이 불필요하게 많지 않은가?
- [ ] **성능:** 인덱스 생성 시 검색 및 정렬 성능에 최적화된 타입인가?
- [ ] **보안:** 식별자 값만으로 민감한 개인정보가 유출될 가능성은 없는가?
- [ ] **확장성:** 데이터 양이 급증해도 식별자 범위(Range)가 충분한가?

## 8. 적용 사례
### 사례: 이커머스 플랫폼의 주문 관리 시스템
*   **상황:** 고객이 주문을 하면 `주문` 테이블과 `주문상세` 테이블에 데이터가 저장됨.
*   **적용:**
    *   **고객 식별:** `CUST_ID` (인조 키, Sequence) $\rightarrow$ 고객의 이메일이 변경되어도 식별 유지.
    *   **주문 식별:** `ORD_NO` (비즈니스 식별자, `날짜+랜덤문자열`) $\rightarrow$ 고객 상담 시 확인 가능한 주문번호 제공.
    *   **주문상세 식별:** `ORD_DTL_ID` (인조 키, Auto-increment) $\rightarrow$ 하나의 주문 내 여러 상품을 구분하기 위한 고유 키.
*   **결과:** `ORD_NO`를 통해 주문을 찾고, `ORD_DTL_ID`를 통해 개별 상품의 배송 상태를 정확히 추적 가능.