SQLD 주식별자 및 보조식별자 구분 기준과 시험 출제 패턴

데이터베이스 설계의 핵심인 식별자 이해하기

SQLD 시험을 준비하거나 데이터 모델링을 처음 접하는 분들이 가장 먼저 마주하는 난관 중 하나가 바로 식별자 개념입니다. 데이터베이스에서 식별자는 마치 사람의 주민등록번호처럼 각각의 데이터를 고유하게 구분해주는 아주 중요한 역할을 합니다. 식별자를 제대로 설계하지 않으면 데이터의 중복이 발생하거나, 원하는 정보를 정확하게 찾아내지 못하는 등 시스템 전체의 무결성이 깨질 수 있습니다.

식별자는 크게 주식별자와 보조식별자로 나뉩니다. 이 두 가지를 명확히 구분하는 것이야말로 실무 데이터 모델링의 시작이자 SQLD 합격을 위한 지름길이라고 할 수 있습니다. 이번 가이드에서는 이 둘의 차이점을 명확히 짚어보고, 시험에서 어떤 패턴으로 출제되는지 상세히 알아보겠습니다.

주식별자와 보조식별자의 정의와 차이점

주식별자는 엔터티 내에서 각 인스턴스를 유일하게 식별할 수 있는 대표적인 속성입니다. 흔히 ‘기본키(Primary Key)’라고 부르는 개념과 일맥상통합니다. 반면 보조식별자는 인스턴스를 식별할 수는 있지만, 대표성을 갖지 못하거나 물리적인 테이블 설계에서 기본키로 사용되지 않는 속성을 의미합니다. 이를 쉽게 이해하기 위해 아래의 비교 표를 참고해 보세요.

• 주식별자: 유일성, 최소성, 불변성, 존재성을 모두 만족해야 함. 데이터의 대표 주자.

• 보조식별자: 유일성은 만족하지만, 대표성을 갖지 않아 참조 관계나 인덱스 생성 등에 보조적으로 활용됨.

주식별자가 갖춰야 할 4가지 필수 요건

SQLD 시험에서는 주식별자의 요건을 묻는 문제가 자주 등장합니다. 이 4가지는 반드시 암기해야 합니다.

• 유일성: 주식별자에 의해 엔터티 내의 모든 인스턴스들이 유일하게 구분되어야 합니다.
• 최소성: 식별자를 구성하는 속성 수는 유일성을 만족하는 최소 개수여야 합니다. 불필요하게 많은 속성을 묶는 것은 좋지 않습니다.
• 불변성: 식별자의 값은 한 번 정해지면 자주 변하지 않아야 합니다. 값이 자주 바뀌면 참조 무결성에 문제가 생깁니다.
• 존재성: 주식별자가 지정되면 반드시 값이 들어와야 합니다(Not Null). 값이 없으면 식별 자체가 불가능하기 때문입니다.

SQLD 시험 출제 패턴 분석

SQLD 시험에서 식별자 관련 문제는 주로 이론적인 정의를 묻거나, 특정 상황에서 어떤 식별자가 가장 적절한지를 판단하는 유형으로 출제됩니다. 다음은 수험생들이 자주 틀리는 출제 포인트입니다.

주식별자 도출 과정 문제

시험에서는 엔터티의 업무 규칙을 나열한 뒤, ‘이 중에서 가장 적절한 주식별자는 무엇인가’를 묻습니다. 이때 주의할 점은 단순히 ‘유일하다’는 이유만으로 정답을 골라서는 안 된다는 것입니다. 위의 4가지 요건을 모두 만족하는지 끝까지 확인해야 합니다. 특히 ‘시간이 지나도 값이 변하지 않는가’라는 기준이 정답을 가르는 핵심이 되는 경우가 많습니다.

식별자 관계 vs 비식별자 관계

주식별자를 설명할 때 빠질 수 없는 것이 식별자 관계와 비식별자 관계입니다. 부모 엔터티의 주식별자가 자식 엔터티의 주식별자로 상속되면 ‘식별자 관계’, 일반 속성으로 상속되면 ‘비식별자 관계’입니다. 시험에서는 ‘식별자 관계를 사용해야 하는 경우’와 ‘비식별자 관계를 사용해야 하는 경우’를 구분하는 문제가 단골입니다.

• 식별자 관계 필수 상황: 부모 없이는 자식 존재가 불가능할 때(강한 의존 관계).
• 비식별자 관계 고려 상황: 부모와 자식의 생명 주기가 다르거나, 자식 엔터티의 주식별자가 너무 복잡해질 때.

실생활에서의 식별자 활용 예시

데이터 모델링은 결국 현실 세계의 정보를 구조화하는 작업입니다. 우리가 일상에서 사용하는 정보를 식별자 관점에서 바라보면 이해가 훨씬 빠릅니다. 예를 들어 ‘대학교 학생 관리 시스템’을 생각해 봅시다.

학생 엔터티를 설계할 때, ‘이름’은 동명이인이 있을 수 있으므로 주식별자가 될 수 없습니다. ‘주민등록번호’는 유일하지만 개인정보 보호 문제로 인해 시스템 내부적으로 사용하기 꺼려집니다. 따라서 학교는 ‘학번’이라는 인위적인 값을 만들어 주식별자로 사용합니다. 이때 ‘주민등록번호’나 ‘이메일 주소’는 유일성을 가지므로 ‘보조식별자’로 등록하여 검색 효율을 높이는 데 활용할 수 있습니다.

이처럼 주식별자는 시스템의 골격(구조)을 잡는 데 사용하고, 보조식별자는 사용자가 원하는 정보를 빠르게 찾기 위한 ‘인덱스’의 역할을 한다고 이해하면 실무 감각을 익히는 데 큰 도움이 됩니다.

흔한 오해와 사실 관계 바로잡기

많은 초보자가 ‘모든 유일한 속성은 주식별자로 써도 되지 않나?’라는 오해를 합니다. 하지만 이는 데이터베이스 성능과 유지보수 측면에서 큰 실수가 될 수 있습니다.

첫째, 주식별자가 너무 길면 안 됩니다. 여러 속성을 묶어 복합키(Composite Key)를 만들면, 자식 엔터티로 상속될 때마다 외래키(FK)의 크기가 커져 조인 연산 속도가 느려집니다. 그래서 실무에서는 인위적인 일련번호(대리키)를 주식별자로 선호하기도 합니다.

둘째, 보조식별자는 많을수록 좋은 것이 아닙니다. 보조식별자마다 인덱스를 생성하게 되는데, 인덱스가 너무 많으면 데이터 삽입, 수정, 삭제(DML) 성능이 현저히 떨어집니다. 꼭 필요한 경우에만 보조식별자를 정의하는 것이 비용 효율적인 설계입니다.

전문가가 제안하는 식별자 설계 팁

데이터 모델링 전문가들은 식별자를 설계할 때 ‘비즈니스 규칙’을 최우선으로 고려하라고 조언합니다. 기술적으로 완벽한 식별자라도 해당 업무를 제대로 설명하지 못하면 잘못된 설계입니다.

• 업무 규칙을 우선하라: 비즈니스 프로세스에서 무엇을 기준으로 데이터를 구분하는지 현업 담당자와 충분히 대화하세요.
• 대리키 사용을 두려워하지 마라: 자연키(학번, 사번 등)가 너무 복잡하다면 시스템 내부적인 일련번호(인조 식별자)를 도입하는 것이 시스템 안정성 면에서 훨씬 유리합니다.
• 이름은 명확하게 정의하라: 식별자 속성명은 그 의미가 직관적이어야 합니다. 모델링 문서만 보고도 어떤 식별자인지 알 수 있어야 합니다.

자주 묻는 질문과 답변

Q1. 주식별자를 변경해야 하는 상황이 오면 어떻게 하나요?

주식별자는 ‘불변성’이 원칙입니다. 하지만 업무가 변경되어 식별자를 바꿔야 한다면, 데이터 이관 작업과 함께 해당 엔터티를 참조하는 모든 외래키 관계를 수정해야 합니다. 이는 매우 위험한 작업이므로 설계 단계에서 미래의 확장성을 고려해 신중하게 결정해야 합니다.

Q2. 보조식별자는 물리 테이블에서 어떻게 구현되나요?

데이터베이스 수준에서는 주로 ‘유니크 인덱스(Unique Index)’로 구현됩니다. 보조식별자로 지정된 속성에 유니크 인덱스를 생성하면 해당 속성의 중복을 방지하고 조회 속도를 빠르게 할 수 있습니다.

Q3. 식별자 관계를 쓰면 무조건 성능이 안 좋아지나요?

반드시 그렇지는 않습니다. 식별자 관계를 쓰면 조인 없이 부모 속성을 가져올 수 있다는 장점도 있습니다. 다만, 복합키가 너무 길어질 때 성능 이슈가 발생하므로 상황에 맞는 적절한 타협점을 찾는 것이 중요합니다.

효율적인 학습 및 실무 적용 전략

SQLD 시험을 준비하는 독자라면, 이론을 공부한 뒤 반드시 ‘데이터 모델링 연습 문제’를 직접 풀어보기를 권장합니다. 단순히 정의를 외우는 것보다, 주어진 엔터티들 사이의 관계를 직접 그려보고 주식별자를 하나씩 지정해보는 과정이 훨씬 효과적입니다.

실무에서는 ‘데이터 모델링 툴’을 활용하는 경우가 많습니다. 툴에서 엔터티를 생성할 때 주식별자(PK)와 보조식별자(AK)를 구분하여 설정하는 연습을 해보세요. 이렇게 직접 도구를 활용해 보면 식별자가 물리적 테이블에서 어떻게 변환되는지 눈에 보이기 시작합니다. 또한, 기존에 운영 중인 시스템의 테이블 구조를 분석해보는 것도 좋습니다. 어떤 테이블이 식별자 관계를 맺고 있는지, 왜 저 속성을 식별자로 썼는지 고민해보는 시간은 여러분의 데이터 모델링 실력을 비약적으로 향상시켜 줄 것입니다.

식별자는 데이터베이스의 뼈대입니다. 뼈대가 튼튼해야 그 위에 올라가는 데이터와 애플리케이션 서비스가 안정적으로 유지될 수 있습니다. 오늘 배운 내용을 바탕으로 개념을 확실히 정리하고, 문제 풀이를 통해 자신의 것으로 만들어 보시기 바랍니다. 꾸준한 연습과 고민이 더해진다면 SQLD 합격은 물론, 실무에서도 인정받는 데이터 모델러로 성장할 수 있을 것입니다.