고유 번호(기본키)

쉽게 말하면

컴퓨터는 사람보다 훨씬 융통성이 없어요. 사람은 "아, 지난주에 오셨던 그 김민준 님" 하고 문맥으로 알아보지만, 컴퓨터에게 이름은 그냥 글자예요. 같은 글자가 두 줄 있으면 컴퓨터는 둘을 구분할 방법이 없어요. 그래서 데이터베이스의 모든 표에는 줄마다 절대 겹치지 않는 번호를 붙이는 게 철칙이에요.

엑셀로 옮겨 보면

데이터베이스가 낯설면 엑셀을 떠올리면 돼요. 데이터베이스의 표는 엑셀 시트, 행은 시트의 한 줄, 열은 칸이에요. 머리글을 정하는 게 표의 설계고요. 기본키는 여기서 첫 번째 칸에 붙는 번호 열이에요.

다만 엑셀과 결정적으로 다른 점이 하나 있어요. 엑셀의 행 번호(왼쪽의 1, 2, 3)는 줄을 지우면 아래 줄이 밀려 올라오면서 번호가 바뀌어요. 기본키는 절대 안 바뀌어요. 1047번 손님이 탈퇴해도 그 번호는 비워 둘 뿐, 다른 손님에게 다시 주지 않는 게 원칙이에요. 번호가 바뀌거나 재활용되면 "1047번"이라는 말 자체를 믿을 수 없게 되니까요.

이름으로 구분하면 반드시 꼬이는 이유

"우리 가게에 동명이인이 어디 있어" 싶을 수 있어요. 그런데 이름이 꼬이는 길은 동명이인 말고도 많아요. 손님이 100명만 넘어도 아래 중 하나는 반드시 일어나요.

1. 1동명이인. 김민준, 이서연 같은 흔한 이름은 손님 수백 명 규모면 거의 확실히 겹쳐요.
2. 2표기 흔들림. 같은 사람이 "김 민준", "김민준", "kim minjun"으로 세 번 가입해요. 컴퓨터에게 이 셋은 남남이에요.
3. 3개명과 오타. 손님이 이름을 바꾸거나, 등록할 때 한 글자 잘못 치면, 이름으로 이어 둔 기록이 전부 끊겨요.
4. 4이름을 걸어 둔 다른 기록까지 연쇄로 꼬여요. 예약·주문·포인트가 전부 이름으로 손님을 가리키고 있었다면, 이름 하나 바뀌는 순간 그 손님의 과거 기록이 통째로 미아가 돼요.

그래서 정석은 이래요. 이름·전화번호는 사람이 보는 정보로만 쓰고, 컴퓨터끼리는 오직 고유 번호로만 가리키게 해요. 이름이 바뀌든 오타가 나든, 번호만 그대로면 기록은 안 끊겨요. 종이 명부 시절에도 똑같았어요. 은행이 통장에 이름 대신 계좌번호를 크게 찍는 것도, 병원이 접수할 때 이름과 생년월일을 같이 묻는 것도, 전부 "이름만으로는 사람을 못 가른다"는 같은 문제를 푸는 방법이에요.

실제로 보게 될 모습

AI가 만들어 준 표를 들여다보면 id라는 열이 맨 앞에 있을 거예요. 그게 기본키예요. 값의 생김새는 보통 두 갈래예요.

하나 더, 데이터를 직접 들여다보다가 id 열을 손으로 고치거나 지우고 싶어져도 참으세요. 그 번호를 다른 표의 기록들이 붙잡고 있어요. 이름이나 전화번호 칸은 얼마든지 고쳐도 되지만, id 칸만은 컴퓨터의 영역으로 남겨 두는 게 안전해요.

사장님이 실제로 겪는 장면

증상이 보이면 이렇게 말하세요

기본키 문제는 "기본키가 이상해요"라는 얼굴로 안 나타나요. 전혀 다른 증상으로 나타나요. 아래 증상이 보이면 그대로 복사해서 AI에게 말하면 돼요.

공통점이 보이죠. 전부 "무엇으로 찾고 있는지 확인하고, 고유 번호로 찾게 바꿔 줘"예요. 이 한 문장이 이 문서의 핵심 주문이에요. 원인을 사장님이 짚어 줄 필요도 없어요. 증상을 그대로 말하고 이 주문을 붙이면, 무엇이 잘못됐는지 찾는 건 AI의 일이에요. 사장님의 일은 이 증상들이 "앱 고장"이 아니라 "찾는 기준의 문제"라는 걸 알아보는 것까지예요.

지금은 신경 쓰지 않아도 되는 때

다행인 소식부터요. 바이브캠퍼스에서 AI로 앱을 만들면 기본키는 거의 항상 자동으로 들어가요. 요즘 도구들은 표를 만들 때 id 열부터 깔고 시작하는 게 기본이거든요. 그러니 앱을 만드는 단계에서 "기본키를 넣어 주세요"라고 따로 챙길 필요는 보통 없어요.

사장님이 이 문서를 다시 꺼내 볼 때는 세 경우예요. 첫째, 위 표의 증상이 실제로 보일 때. 둘째, 엑셀에 적어 두던 손님 명단을 앱으로 옮겨 넣을 때예요. 엑셀에는 고유 번호가 없었으니, 옮기면서 번호를 새로 받게 되고, 이때 같은 사람이 두 줄로 들어가지 않게 확인이 필요해요. 셋째, 외주 개발자가 PK, 기본키, 식별자 같은 말을 꺼낼 때요. 그때 이 문서 하나면 대화가 통해요.

헷갈리기 쉬운 것

기본키와 [[db-index|인덱스]]는 뭐가 달라요? 기본키는 "이 줄이 누구인가"를 정하는 신분증이고, 인덱스는 "빨리 찾기 위한 색인"이에요. 역할이 달라요. 기본키에는 인덱스가 자동으로 따라붙어서 번호로 찾는 건 항상 빠르지만, 그렇다고 인덱스가 곧 기본키인 건 아니에요. 전화번호 칸에 인덱스를 걸어 검색을 빠르게 할 수는 있어도, 그 칸이 신분증이 되는 건 아니거든요.

주문번호·회원번호와도 달라요? 손님에게 보여 주는 번호는 예쁘게 짓는 경우가 많아요. "20260823-004" 같은 식으로요. 이런 번호는 보여 주기용이고, 컴퓨터 내부에서는 여전히 기본키로 기록을 가리켜요. 작은 서비스에서는 둘을 겸용해도 되지만, 보여 주는 번호의 규칙을 나중에 바꾸고 싶어질 수 있다는 점을 생각하면 처음부터 따로 두는 쪽이 편해요.

자주 묻는 것

Q. 고유 번호는 제가 직접 붙여야 하나요?

아니요, 컴퓨터가 알아서 붙여요. 새 손님이 등록되는 순간 자동으로 다음 번호가 나가요. 사장님이 번호를 짓거나 관리할 일은 없어요.

Q. 손님한테 이 번호를 보여 줘도 되나요?

보여 줘도 되지만 보통은 안 보여 줘요. 기본키는 컴퓨터 내부용이에요. 손님에게 보여 줄 번호(주문번호, 회원번호)가 필요하면 보기 좋은 번호를 따로 만드는 경우가 많아요. 그 번호와 기본키를 겸용해도 작은 가게에서는 문제없어요.

Q. 번호가 1, 3, 4처럼 중간이 비어 있어요. 고장인가요?

정상이에요. 2번 손님이 탈퇴했거나, 등록이 중간에 취소되면 번호가 건너뛰어요. 빈 번호를 메우려고 하면 오히려 사고가 나요. 번호는 겹치지만 않으면 돼요.

Q. 이메일로 로그인하는데, 그럼 이메일이 기본키 아닌가요?

이메일은 로그인용 열쇠고, 기본키는 따로 있는 게 보통이에요. 이메일에는 "중복 금지" 규칙만 걸어요. 이렇게 해 두면 손님이 이메일을 바꿔도 고유 번호는 그대로라 기록이 안 끊겨요. 로그인 문서에서 이어져요.

Q. 표가 여러 개면 번호도 표마다 따로인가요?

네, 표마다 자기 번호가 따로 돌아요. 손님 표의 7번과 주문 표의 7번은 아무 관계가 없어요. 그래서 주문 표에는 "이 주문의 손님은 손님 표 몇 번"이라고 적는 칸을 따로 둬요.

Q. 지금 이름으로 관리하는 엑셀 명단이 있는데, 옮기면 큰일 나나요?

큰일까지는 아니에요. 옮겨 넣는 순간 줄마다 새 번호를 받으니까요. 단 옮기기 전에 같은 사람이 두 줄로 적혀 있지 않은지만 정리하세요. 두 줄인 채 옮기면 그 손님은 앱에서도 영원히 두 명이에요.

Q. 번호가 지저분한데, 1번부터 예쁘게 다시 매기면 안 되나요?

안 돼요. 이게 기본키에서 가장 위험한 충동이에요. 다른 표의 기록들이 지금 번호를 보고 손님을 가리키고 있어서, 번호를 다시 매기는 순간 예약과 주문이 전부 엉뚱한 손님에게 붙어요. 번호는 보기용이 아니라 연결용이라 지저분해 보여도 그대로 두는 게 맞아요.

Q. 표는 AI가 다 만들어 주는데, 제가 이걸 왜 알아야 하나요?

만들 때가 아니라 고칠 때 필요해요. "한 건만 지웠는데 두 건이 사라졌어요"라는 증상을 보고 "고유 번호로 찾게 바꿔 줘"라는 주문을 꺼낼 수 있는 사람과 없는 사람은, 같은 사고 앞에서 복구 시간이 하늘과 땅 차이예요.