기본키는 왜 필요할까? 수많은 행 가운데 하나를 구별하는 방법

회사에 같은 이름을 가진 사람이 두 명 있다고 해보자. 부서까지 다르면 사람은 문맥을 보고 어느 김민수인지 대개 알아차린다. 그러나 데이터베이스는 눈치로 판단하지 않는다. 이름과 부서, 입사일처럼 저장된 값만 보고 기록을 구분해야 한다.

문제는 이름이 같을 수 있고, 부서가 바뀔 수도 있으며, 입사일마저 우연히 겹칠 수 있다는 데 있다. 이름을 잘못 골라 전화번호를 고치면 엉뚱한 사람의 정보가 바뀐다. 한 행을 삭제하려다가 같은 이름을 가진 다른 사람의 기록까지 지워질 수도 있다.

앞선 글에서는 데이터가 행과 열로 나뉘어 저장되는 이유를 살펴보았다. 열은 어떤 정보를 담을지 정하고, 행은 한 사람이나 한 상품처럼 하나의 대상을 기록한다. 표의 모양을 갖추었다고 해서 각 행이 저절로 구별되는 것은 아니다. 수천, 수백만 개의 행 가운데 정확히 하나를 가리키는 별도의 기준이 필요하다.

한줄 요약
기본키는 데이터베이스의 각 행에 겹치지 않는 식별값을 부여해 하나의 기록을 정확히 찾게 한다. 같은 값이 반복될 수 없고 비워둘 수도 없기 때문에 조회뿐 아니라 수정, 삭제, 데이터 연결의 기준이 된다.

사람에게 익숙한 이름이 기계에는 불확실한 값이 된다

종이에 적힌 명단이 열 명 정도라면 이름만으로도 사람을 찾을 수 있다. 동명이인이 나타나면 생년월일이나 주소를 곁들여 확인하면 된다. 이 방법은 사람이 기록을 읽고 판단할 때에는 별문제 없어 보인다.

데이터의 규모가 커지면 상황이 달라진다. 쇼핑몰에는 같은 이름의 고객이 여러 명 있을 수 있고, 같은 고객이 주소를 두 개 이상 등록하기도 한다. 병원에는 이름과 생년월일이 같은 환자가 올 수 있다. 창고에는 같은 제품명이 붙었지만 생산 시기와 규격이 다른 부품이 함께 보관된다.

이름이나 주소를 행의 기준으로 삼으면 값이 바뀔 때마다 식별 기준도 흔들린다. 전화번호는 번호 이동이나 해지로 달라질 수 있고, 이메일 주소도 새로 만들 수 있다. 주민등록번호처럼 고유해 보이는 값도 모든 서비스가 수집하고 저장해도 되는 값은 아니다. 개인정보 보호와 업무 목적을 함께 고려해야 한다.

그래서 많은 시스템은 고객번호, 주문번호, 장비번호처럼 업무에서 사용할 고유한 값을 따로 만든다. 사람에게는 숫자 한 줄에 불과하지만 데이터베이스에는 ‘바로 이 행’이라고 지정하는 표지가 된다. 이름이 바뀌고 주소가 수정되어도 그 표지는 그대로 남는다.

기본키에는 같은 값도 빈자리도 허용되지 않는다

데이터베이스에서는 이런 식별 기준을 기본키, 영어로 Primary Key라고 부른다. 기본키는 한 개의 열로 만들 수도 있고 여러 열을 묶어 만들 수도 있다. 형태보다 중요한 것은 그 값으로 하나의 행만 가리킬 수 있어야 한다는 점이다.

고객 테이블에 고객번호 1007이 이미 있다면 다른 고객에게 같은 번호를 줄 수 없다. 두 행에 같은 기본키가 들어가면 시스템은 어느 쪽이 진짜 1007번 고객인지 결정할 수 없기 때문이다. 데이터베이스는 이를 사용자의 주의력에 맡기지 않고 중복 입력 자체를 막는다.

기본키를 비워두는 것도 허용되지 않는다. 아직 번호가 정해지지 않았다는 뜻으로 빈값을 넣어두면 그 행을 확실하게 부를 방법이 사라진다. PostgreSQL 문서가 기본키에 유일성과 NOT NULL, 즉 빈값 금지를 함께 요구하는 이유도 여기에 있다.

표 안에 번호 열을 하나 만들었다고 모두 기본키가 되는 것은 아니다. 사용자가 번호를 중복해서 적을 수 있고 빈칸도 남길 수 있다면 그것은 평범한 열에 가깝다. 기본키는 데이터베이스가 규칙을 직접 검사하고 지킨다는 점에서 단순한 일련번호와 다르다.

한 테이블에는 기본키가 하나만 지정된다. 다만 그 하나가 반드시 한 열이어야 한다는 뜻은 아니다. 강좌번호와 수강생번호를 함께 묶어 ‘어느 강좌를 누가 듣는가’를 구별하듯 두 개 이상의 열을 한 벌로 사용할 수 있다. 이를 복합키라고 한다. 각각의 값은 반복되어도 두 값의 조합이 겹치지 않으면 하나의 행을 식별할 수 있다.

이름을 쓸지 새 번호를 만들지는 생각보다 어려운 선택이다

현실에 이미 존재하는 값을 기본키로 삼을 수도 있다. 책의 ISBN이나 정해진 자산번호처럼 대상 자체가 가진 고유값을 이용하는 방식이다. 이런 키를 자연키라고 한다. 별도의 번호를 만들지 않아도 의미를 알아보기 쉽다는 장점이 있다.

그러나 자연키는 업무 규칙이 달라지면 함께 흔들릴 수 있다. 어느 시점에는 절대로 바뀌지 않는 값처럼 보였는데 제도가 개편되거나 외부 기관의 번호 체계가 바뀌면서 수정이 필요해질 수 있다. 값이 길면 다른 테이블에서 반복해 참조할 때 저장과 관리가 불편해지기도 한다.

이 때문에 시스템 내부에서만 사용하는 짧은 번호를 새로 만들어 기본키로 삼는 경우가 많다. 데이터 자체의 뜻과 관계없이 식별만 담당하는 대체키다. 고객에게 보이는 회원번호와 데이터베이스 내부의 기본키가 반드시 같을 필요도 없다.

대체키가 있다고 해서 업무상 중복 검사를 생략해도 된다는 뜻은 아니다. 주문행 번호가 서로 달라도 같은 결제가 두 번 저장되면 실제 업무에서는 중복이다. 기본키는 두 행을 기술적으로 구별할 뿐, 그 데이터가 현실에서 올바른지까지 모두 판단하지는 않는다. 주문번호와 상품번호의 조합, 거래 승인번호처럼 업무 규칙에 맞는 별도의 유일성 조건이 필요할 수 있다.

좋은 기본키를 고르는 일은 번호 열 하나를 추가하는 작업으로 끝나지 않는다. 무엇이 바뀔 수 있는 값인지, 외부에 노출해도 되는지, 여러 시스템이 같은 대상을 어떤 기준으로 알아볼지를 함께 따져야 한다. 테이블 설계가 업무를 이해하는 과정과 떨어질 수 없는 이유다.

정확한 수정과 삭제는 하나를 가리키는 데서 시작한다

고객이 주소 변경을 요청했다고 해보자. 시스템은 먼저 고객번호로 해당 행을 찾은 뒤 주소 열만 고친다. 이름으로 검색하면 동명이인의 기록까지 후보에 들어오지만 기본키를 사용하면 수정할 행이 하나로 좁혀진다.

삭제도 마찬가지다. ‘김민수라는 이름을 가진 행을 지워라’는 명령은 위험하다. 같은 이름의 고객이 여러 명이면 필요하지 않은 기록까지 사라질 수 있다. ‘고객번호 1007의 행을 지워라’는 명령은 대상이 분명하다. 데이터베이스 작업에서 정확성은 복잡한 계산보다 먼저 정확한 대상을 고르는 데서 출발한다.

기본키는 다른 테이블과의 연결점도 된다. 고객 테이블과 주문 테이블을 따로 보관하더라도 주문 기록에 고객번호를 남기면 어느 고객의 주문인지 연결할 수 있다. 주문 테이블에 저장된 고객번호는 고객 테이블의 기본키를 가리키며, 다음 단계에서 다룰 외래키의 역할로 이어진다.

에드거 F. 커드가 1970년에 제시한 관계형 모델은 데이터를 관련 있는 표들로 나누고, 공통된 값을 통해 다시 연결할 수 있는 길을 열었다. 이 구조에서 기본키는 한 행의 이름표이면서 다른 표가 그 행을 찾아오는 기준점이 된다. 표를 나누어도 정보의 관계가 끊어지지 않는 까닭이다.

정보가 급하게 오갈수록 식별은 더 엄격해야 한다

정보체계를 오래 들여다보면 화려한 화면보다 식별자가 더 중요한 순간을 자주 만나게 된다. 장비명만으로 정비 이력을 관리하면 같은 종류의 장비가 수십 대 배치되었을 때 어느 장비의 고장인지 구별하기 어렵다. 부대명과 장비명이 같아도 설치 위치와 자산번호가 다르면 서로 다른 대상이다.

상황정보도 비슷하다. 같은 시각에 여러 센서가 비슷한 위치의 대상을 탐지할 수 있고, 하나의 대상이 시간에 따라 이동하면서 여러 건의 관측 기록을 남긴다. 각 기록과 대상을 구별하는 기준이 없다면 새로운 정보가 들어올 때 기존 기록을 갱신해야 하는지, 별개의 대상으로 추가해야 하는지 판단하기 어렵다.

일반 행정 시스템에서는 잘못 연결된 기록을 나중에 찾아 고칠 여지가 있다. 운용 속도가 중요한 정보체계에서는 잘못된 식별이 뒤의 처리 과정 전체에 빠르게 퍼질 수 있다. 데이터의 양보다 ‘무엇에 관한 데이터인가’를 일관되게 가리키는 능력이 먼저 갖추어져야 한다.

그렇다고 기본키 하나가 센서 융합이나 지휘통제의 모든 문제를 해결하는 것은 아니다. 서로 다른 체계가 같은 대상을 서로 다른 번호로 관리하면 번호가 고유해도 체계 사이에서는 바로 통하지 않는다. 식별 규칙과 데이터 표준, 시간과 위치 정보, 체계 간 매핑이 함께 필요하다. 기본키는 그 긴 과정에서 가장 작은 출발점이다.

짧은 생각
정보체계의 오류는 데이터가 없어서만 생기지 않는다. 데이터는 충분한데 서로 다른 대상을 같은 것으로 보거나, 같은 대상을 서로 다른 것으로 다루면서 문제가 커지기도 한다. 현장에서 화면에 표시된 한 줄의 정보가 믿을 만하려면 그 뒤에서는 대상을 식별하는 규칙부터 흔들리지 않아야 한다.

한 행의 이름표가 표와 표를 연결한다

기본키는 눈에 잘 띄는 기능이 아니다. 사용자는 화면에서 이름과 사진, 주문 내용이나 장비 상태를 보지만 데이터베이스는 보이지 않는 식별값을 따라 정확한 행을 찾는다. 이 값이 안정되어야 수정과 삭제가 엉뚱한 기록을 건드리지 않고, 다른 표의 정보도 제자리를 찾아간다.

행과 열이 데이터를 정리하는 틀이라면 기본키는 그 안의 각 행을 잃어버리지 않게 붙인 이름표다. 사람이 보기 좋은 표를 컴퓨터가 믿고 처리할 수 있는 구조로 바꾸는 데에는 이 작은 이름표가 필요하다.

그리고 기본키가 자신의 표 안에서 한 행을 구별하는 값이라면, 다른 표에는 그 값을 가져와 관계를 표시하는 열이 있다. 고객과 주문, 장비와 정비 이력, 센서와 관측 기록을 연결하는 이 열을 외래키라고 한다. 다음 글에서는 표를 나누어 저장하면서도 정보가 흩어지지 않게 만드는 기본키와 외래키의 관계를 이어서 살펴보려 한다.