데이터베이스 키(Key) 완전 정복 핸드북 테이블의 주민등록증, 그 모든 것

2025-08-11 03:37

Tags:

데이터베이스 키(Key) 완전 정복 핸드북: 테이블의 주민등록증, 그 모든 것

데이터베이스라는 거대한 정보의 도시에서, 우리는 어떻게 수많은 데이터(시민) 중 원하는 단 한 명을 정확하게 찾아낼 수 있을까요? 바로 모든 시민이 고유한 ‘주민등록번호’를 가지고 있기 때문입니다. 데이터베이스의 **‘키(Key)’ 또는 ‘식별자(Identifier)‘**가 바로 이 주민등록번호와 같은 역할을 수행합니다.

이 핸드북은 데이터베이스 키의 탄생 배경부터 종류, 그리고 현명한 사용법까지, 키에 대한 모든 것을 깊이 있게 탐구합니다.

Part 1: 데이터베이스 키, 왜 만들어졌을까? (The “Why”)

데이터의 바다에서 ‘나’를 찾는 방법

만약 대한민국에 동명이인이 수만 명인데 주민등록번호가 없다면, 특정 ‘김민준’을 찾아내기란 거의 불가능에 가까울 것입니다. 세금을 부과하거나, 복지 혜택을 주거나, 범죄 기록을 관리하는 모든 행정 시스템이 마비될 것입니다.

데이터베이스도 마찬가지입니다. 수백만, 수천만 개의 데이터 행(Row) 속에서 각 행을 유일하게 식별할 수 있는 장치가 없다면, 데이터를 정확하게 조회, 수정, 삭제하는 것이 불가능해집니다. 키는 이처럼 데이터의 바다에서 특정 데이터를 가리키는 유일한 등대 역할을 하기 위해 탄생했습니다.

관계형 데이터베이스의 약속: 무결성

데이터베이스 키는 단순히 데이터를 식별하는 것을 넘어, **‘데이터 무결성(Data Integrity)‘**이라는 중요한 약속을 지키는 핵심 도구입니다.

개체 무결성 (Entity Integrity):
- “모든 시민은 주민등록번호를 반드시, 그리고 유일하게 가져야 한다.”
- 테이블의 모든 행은 **절대 NULL 값이 될 수 없으며, 항상 유일한 값을 갖는 기본 키(Primary Key)**를 가져야 한다는 원칙. 이를 통해 데이터의 신뢰도를 보장.
참조 무결성 (Referential Integrity):
- “출생신고를 하지 않은 아이를 학교에 입학시킬 수 없다.”
- 한 테이블의 키(외래 키)가 다른 테이블의 키(기본 키)를 참조할 때, 참조하는 키의 값은 반드시 참조되는 테이블에 존재해야 한다는 원칙. 이는 테이블 간의 논리적 관계가 깨지지 않도록 보호하는 역할을 수행.

Part 2: 키의 종류와 계층 구조: 무엇이 다른가? (The “What”)

데이터베이스 키는 그 역할과 특성에 따라 여러 종류로 나뉩니다. 제공해주신 이미지의 분류를 기반으로 더 깊이 있게 살펴보겠습니다.

대표 여부에 따른 분류 (유일성 보장 그룹)

이 그룹의 키들은 모두 각 행의 유일성을 보장하는 공통된 임무를 가집니다.

슈퍼 키 (Super Key):
- 정의: 테이블의 행을 유일하게 식별할 수 있는 하나 이상의 속성(Attribute) 집합.
- 비유: 학생 테이블에서 (학번), (주민번호), (학번, 이름), (주민번호, 이름)은 모두 학생을 유일하게 구분할 수 있으므로 슈퍼 키. 즉, 유일성을 만족하는 모든 조합.
- 특징: 최소성을 만족하지는 않음. (학번, 이름)에서 이름은 사실상 불필요.
후보 키 (Candidate Key) / 보조식별자:
- 정의: 슈퍼 키 중에서 최소한의 속성만으로 유일성을 만족하는 키. 즉, 최소성을 만족하는 슈퍼 키.
- 비유: 슈퍼 키 중에서 불필요한 속성을 모두 제거한 ‘주연 배우 후보들’. 위 예시에서 (학번)과 (주민번호)가 후보 키.
- 특징: 하나의 테이블에 여러 개의 후보 키가 존재할 수 있음. 모두 기본 키가 될 자격이 있음.
기본 키 (Primary Key) / 주식별자:
- 정의: 후보 키 중에서 개발자나 설계자가 선택한 단 하나의 대표 키.
- 비유: 수많은 주연 배우 후보들 중 최종적으로 선택된 ‘주인공’.
- 선택 기준: NULL 값을 가질 수 없고, 값이 변할 가능성이 적으며, 단순할수록 좋음. (예: 주민번호보다 학번이 더 나은 기본 키일 수 있음)
- 특징: NOT NULL, UNIQUE 제약 조건이 자동으로 부여되며, 테이블 당 단 하나만 존재.
대체 키 (Alternate Key):
- 정의: 후보 키 중에서 기본 키로 선택되지 못한 나머지 키들.
- 비유: 최종 오디션에서 아쉽게 탈락했지만, 여전히 주연급 연기력을 갖춘 배우들.
- 특징: 여전히 UNIQUE 제약 조건을 통해 유일성을 보장하는 역할을 수행.

스스로 생성 여부에 따른 분류 (관계 형성 및 태생 그룹)

외래 키 (Foreign Key) / 외부식별자:
- 정의: 한 테이블에 있으면서, 다른 테이블의 기본 키를 참조하는 속성.
- 비유: ‘수강신청’ 테이블의 학번은 ‘학생’ 테이블의 학번(기본 키)을 바라보는 ‘연결고리’.
- 역할: 테이블 간의 관계를 맺고, 참조 무결성을 보장하는 핵심적인 역할.
내부식별자:
- ‘내부식별자’는 일반적으로 테이블 내에서 스스로 만들어지는 기본 키(Primary Key)를 지칭하는 넓은 의미로 사용될 수 있으며, 아래 설명할 인조 식별자와 비슷한 맥락으로 이해할 수 있습니다.

속성 수에 따른 분류 (구성 요소 그룹)

단일 키 (Simple Key) / 단일식별자:
- 정의: 하나의 속성으로만 구성된 키. (예: 학번)
복합 키 (Composite Key) / 복합식별자:
- 정의: 두 개 이상의 속성을 조합해야만 유일성을 만족하는 키.
- 예시: ‘수강신청’ 테이블에서는 (학번, 과목코드) 두 가지를 합쳐야만 특정 수강 기록 하나를 식별할 수 있음. 이 조합이 복합 기본 키가 됨.

대체 여부에 따른 분류 (태생적 배경 그룹)

본질 식별자 (Natural Key) / 본질식별자:
- 정의: 주민번호, 사번, ISBN(국제표준도서번호)처럼 실제 업무나 비즈니스 로직에 이미 존재하고 사용되는 속성으로 만들어진 키.
- 장점: 그 자체로 의미를 가지므로 데이터 파악이 용이함.
- 단점: 만약 해당 비즈니스 로직이 변경되면(예: 주민번호 체계 개편) 키 값 자체가 변경되어야 하는 큰 혼란이 발생할 수 있음.
인조 식별자 (Artificial/Surrogate Key) / 인조식별자:
- 정의: 본질 식별자가 없거나, 있더라도 기본 키로 사용하기에 부적절할 때, 데이터베이스 시스템에서 인위적으로 부여하는 키.
- 예시: AUTO_INCREMENT 속성을 가진 숫자 ID, UUID(범용 고유 식별자) 등.
- 장점: 비즈니스 로직과 무관하므로 절대 변하지 않으며, 보통 단순한 숫자나 짧은 문자열이라 성능에 유리함.
- 단점: 키 값 자체에는 아무런 의미가 없음. ID=13 이라는 값만 봐서는 어떤 데이터인지 알 수 없음.

Part 3: 키는 어떻게 사용하는가? (The “How”)

최고의 기본 키(Primary Key)를 고르는 방법

좋은 기본 키는 다음 조건을 만족해야 합니다.

유일성 (Uniqueness): 모든 행에 대해 유일한 값을 가져야 함. (필수)
최소성 (Minimality): 유일성을 만족하는 최소한의 속성으로 구성되어야 함. (필수, 후보 키의 조건)
불변성 (Stability): 키 값은 한번 정해지면 절대 변하지 않아야 함. (매우 중요)
단순성 (Simplicity): 가능한 한 짧고, 데이터 타입이 단순(예: 숫자)해야 함. (성능에 영향)

💡 실무자의 고민: 자연 키 vs. 인조 키 많은 경우, 개발자들은 **인조 식별자(Surrogate Key)**를 기본 키로 선호합니다. 비즈니스 규칙은 언제든 변할 수 있지만, 시스템이 부여한 ID는 절대 변하지 않아 안정성이 매우 높기 때문입니다. 자연 키는 대체 키(Alternate Key)로 지정하여 데이터의 의미를 살리고 유일성을 보장하는 방식으로 절충안을 찾기도 합니다.

실전 예제: 학생과 수강신청 테이블

SQL

-- 학생 정보를 담는 테이블
CREATE TABLE Students (
    student_id INT AUTO_INCREMENT, -- 인조 식별자 (기본 키)
    student_number VARCHAR(10) NOT NULL UNIQUE, -- 자연 식별자 (대체 키)
    ssn VARCHAR(13) NOT NULL UNIQUE, -- 자연 식별자 (대체 키)
    name VARCHAR(50) NOT NULL,
    PRIMARY KEY (student_id) -- student_id를 기본 키로 지정
);

-- 수강신청 정보를 담는 테이블
CREATE TABLE Enrollments (
    enrollment_id INT AUTO_INCREMENT, -- 기본 키
    student_id INT NOT NULL, -- 외래 키
    course_code VARCHAR(10) NOT NULL,
    grade VARCHAR(2),
    PRIMARY KEY (enrollment_id),
    FOREIGN KEY (student_id) REFERENCES Students(student_id), -- 외래 키 관계 설정
    UNIQUE (student_id, course_code) -- 한 학생은 같은 과목을 한번만 신청 가능 (복합 대체 키)
);

위 예제에서 Students 테이블의 기본 키 student_id는 Enrollments 테이블에서 외래 키로 참조되어 두 테이블 간의 관계를 형성합니다. 만약 Students에 없는 student_id를 Enrollments에 넣으려고 하면, 참조 무결성 원칙에 의해 데이터베이스가 오류를 발생시켜 잘못된 데이터 입력을 막아줍니다.

Part 4: 심화 탐구: 키에 대한 더 깊은 이야기

인덱스(Index)는 키가 아니다?: 키(특히 기본 키와 고유 키)는 데이터의 무결성을 위한 ‘논리적’ 제약 조건입니다. 인덱스는 데이터 검색 속도를 높이기 위한 ‘물리적’ 자료구조입니다. 대부분의 DBMS는 기본 키에 자동으로 인덱스를 생성해주지만, 모든 인덱스가 키인 것은 아닙니다. (예: 중복을 허용하는 일반 인덱스)
키와 데이터베이스 성능: 기본 키와 외래 키에 인덱스를 생성하는 것은 테이블 조인(JOIN) 성능을 극적으로 향상시킵니다. 따라서 관계 설정 시 인덱스 전략을 함께 고려하는 것이 매우 중요합니다.

데이터베이스 키는 단순히 데이터를 구분하는 표식을 넘어, 데이터의 신뢰성과 안정성을 지탱하는 뼈대와 같습니다. 각 키의 특징과 역할을 정확히 이해하고 상황에 맞게 사용하는 것이 견고한 데이터베이스 시스템을 설계하는 첫걸음입니다.

이 핸드북을 통해 키의 세계를 더 명확하게 이해하셨기를 바랍니다. 혹시 데이터베이스를 설계하며 어떤 종류의 키를 선택할지 고민해 본 경험이 있으신가요?

References

속성

시스매

탐색기