똑똑하게 데이터 11탄 : 기본키
기본키는 유일하게 그러면서 가볍게, 안전하게
카카오톡 이모티콘 | 김이박최 (필자와 무관합니다)'배고파', '어디야', '졸려' 등등 자주 사용하는 말을 이모티콘으로 대신하는 지인이 있습니다. 맨날 하는 말인데도 귀여운 동물이나 우스꽝스러운 표정의 사람이 하면 유쾌하고, 공감을 이끌어낼 때가 많습니다. 하지만 위 이모티콘은 달랐습니다. '지은이는 조아~'라고 보낸 순간 잠깐 정적이 흘렀습니다.
응? 아니 벌써 이모티콘이 이렇게 개인 맞춤형이 가능한 시대가 왔다고? AI야?
알고 보니 이 '김이박최'라는 필명의 작가는 대한민국에 흔한 이름을 3개씩 묶어서 이모티콘을 제작하고 있었습니다. 위의 "전국의 지은, 지연, 은정이 모여라", "전국의 지영, 지혜, 지현이 모여라" 등등 2030에서 많이 보이는 이름들만 어찌 쏙쏙 뽑아서 만들었는지요. 초등학교 교실에서 선생님 마음대로 '작은 지영', '안경 쓴 민정' 이렇게 불리면서 마음 한편에 상처를 받아본 사람도 있습니다 (저요!)
이름도 고유명사라지만
고유 번호가 필요한 이유
외자 이름이나 성씨가 희소하지 않은 이상, 이름 석 자로는 워낙 동명이인이 많아서, 개인정보를 이름 기준으로 조회했다가는 큰일 납니다. 그래서 매번 번거롭지만 주민등록번호를 입력하고, 공동인증서 확인 절차를 거치는 것이겠지요?
출처 : 구글 검색 '주민등록번호 동일'
그런데 주민등록번호도 딱히 안전한 방식은 아닐 수도 있겠습니다. 워낙 개인정보 유출 사태가 잦기도 했고, 올해 2월에만 해도 같은 읍/면에서 태어난, 같은 성씨의 두 명에게 몇 십 년 전 똑같은 주민등록번호가 발급되었었고, 그것이 시정되지 않아서 한 사람이 막대한 금융 피해를 입었다는 소식도 있었습니다. 바로 아래 조회되는 미국 연방정부의 사례도 서로 다른 사람에게 같은 번호를 발급한 것이 문제였습니다.
계좌 정보, 소득 정보나 범죄 경력 같은 중대한 내용을 정확히 해당하는 그 사람의 데이터에만 업데이트를 하거나 조회하는 권한이 주어져야 하는 상황이었습니다. 그럼 시스템 상으로 어떻게 각 사람마다 고유한 번호를 매길 수 있을까요?
데이터베이스의 기본,
기본 키의 중요성
고유한 번호 또는 식별자를 정의하는 목적이 회원 정보, 계좌 정보 등이 연결된 데이터베이스에서 특정 사람을 가리키기 위한 상황이니 기본 키(Primary Key)라는 개념을 가져오겠습니다.
기본 키(primary key)는 주 키 또는 프라이머리 키라고 하며, 관계형 데이터베이스에서며, 조(레코드)의 식별자로 이용하기에 가장 적합한 것을 관계 (테이블)마다 단 한 설계자에 의해 선택, 정의된 후보 키를 말한다. 유일 키는 0~1개 이상의 속성의 집합으로 볼 수 있다. 즉, 관계에 저장된 레코드를 고유하게 식별하는 후보 키 (=속성 또는 속성의 집합) 가운데, 설계자가 일반적으로 이용되어야 한다고 정해 놓은 것을 가리킨다. (...) 그러나 기본 키는 NULL의 존재가 허용되지 않지만, 후보 키에 허용이 되는 차이가 있다. (레코드 추가, 업데이트할 때 제약 조건으로 기본 키를 생각한다면, 고유 제약 조건에 NOT NULL 제약을 가한 것이 기본 키 제약 조건이라고 생각할 수 있다).
'고유하게 식별하는 속성 또는 속성의 집합'이란 뜻은, 단일 값도 사용할 수 있지만, 해당 데이터를 구성하는 여러 정보(속성)의 집합 중 하나를 선택하기도 한다는 것입니다. 예컨대 상품이라면 처음 상품 정보에 추가된 시간(시간도장) + 판매채널 코드번호를 조합할 수도 있습니다. 주민등록번호는 태어난(정확히는 출생신고가 된) 시간과 지역 코드번호를 조합한 경우입니다.
기본 키를 정의할 때 주의해야 할
3가지 원칙
문제는 조합이 길어지면 길어질수록, 중복 가능성은 희박해지지만 그만큼 기본키의 길이가 길어지면 모든 데이터 조회, 수정, 삭제 과정에서 로딩 속도가 길어질 수 있습니다. 그 데이터를 저장하는 데도 용량이 더 들겠고요. 예를 들어 주민등록번호 앞 8자리가 생년월일에서 끝나지 않고 생년월일시분초까지 해서 10자리가 넘어갔다면? 거기에다 뒤의 출생신고 지역도 시/도 단위가 아니라 읍/면/동까지 들어갔다면 중복 발생은 희박하지만 엄청 길어지면서 사람도 시스템도 힘들어지겠죠?
그럼 가장 단순한 기본키 생성 로직은 무엇이 있을까요? 테이블에 추가될 때마다 자동으로 1씩 증가시키는 로직입니다 (auto-increment). 이 경우 1, 2, 3... 순증 하기 때문에 아예 PK를 저장할 필요가 없을 수 있습니다. 단, 한 개만 보안이 뚫려도 그 기본키가 단순하니 모든 데이터가 해킹의 위험이 있습니다. 그리고 데이터가 분산되어 저장되고 처리되는 상황이면, 각각에 1,2,3이 존재하므로 오히려 충돌의 위험도 있습니다. iCloud에서 같이 확인해야 하는데, 아이폰과 맥북 각각 저장공간에서 77번째로 저장된 것이 '77' 호출 시 동시에 조회되거나 수정되면 데이터 오류가 발생할 수 있습니다.
그러면서도 해당 기본키를 시스템에서만 처리할 것이 아니라, 사용자도 해당 번호를 직접 검색하고 조회하는 필요가 발생한다면 어느 정도 가독성도 있어야 합니다. 주문한 상품이 여러 개인데, 하나만 도착이 늦어져서 배송 조회를 특정하려고 했더니, 외워지지도 않고 주문번호를 복사하지 않고서는 외우지 못하겠더라고요.
기본키를 정의할 때 주의해야 할 3가지 원칙
1. 유일하게 존재해야 한다. (분산된 곳에 저장된 경우도 고려해야)
2. 복잡성을 주의해야 한다. (너무 길면 시스템도 사람도 지친다)
3. 보안에 주의해야 한다. (도미노로 해킹당하면 큰일 난다!)
사진: Unsplash의 Markus Winkler
