지난 글에서는 텍스트 파일이나 엑셀 파일 형태로 데이터를 기록하던 원시적인 '파일 시스템'의 치명적 한계(데이터 중복, 일관성 붕괴, 동시성 갱신 분실 등)를 낱낱이 파헤쳤습니다. 그리고 이를 해결하여 '안전한 은행 금고'처럼 데이터를 무결하게 지켜주는 수호자, 데이터베이스 관리 시스템(DBMS)의 위대한 가치를 배웠지요.

오늘 공부할 포스팅은 RDBMS(관계형 데이터베이스 관리 시스템) 진영이 오랜 세월 엔터프라이즈 환경에서 절대적인 지배자로 군림할 수 있었던 진짜 비결을 학습하는 시간입니다.

RDBMS의 진짜 매력은 단순히 격자무늬의 표(Table)에 데이터를 저장하는 행위 자체에 있지 않습니다. RDBMS의 진짜 강력함은 "각 테이블 간에 한 치의 틈도 허용하지 않는 엄격하고 정교한 관계의 법방(Constraint)을 구축하는 것"에 있습니다. 오늘 포스팅을 통해 관계형 데이터베이스의 핵심 구조인 2차원 테이블 설계 원리와, 데이터의 연결 고리를 통제하는 기본키(PK), 외래키(FK), 그리고 참조 무결성(Referential Integrity)의 본질을 머릿속에 확실히 각인시켜 드리겠습니다!

1. RDBMS의 빌딩 블록: 2차원 테이블 구조와 키(Key)의 역할

관계형 데이터베이스는 수학의 '관계 대수(Relational Algebra)' 이론에 뿌리를 두고 있습니다. 데이터를 가로 행(Row)과 세로 열(Column)로 구성된 직관적인 2차원 테이블(Table 또는 Relation)의 형태로 조직화하죠.

① 테이블의 구성 요소

• 열 (Column / Attribute): 데이터의 '속성'을 나타냅니다. 예를 들어, 회원 테이블에서 '이메일', '이름', '휴대폰 번호' 등은 고유한 데이터 타입을 가진 열(Column)이 됩니다.
• 행 (Row / Record / Tuple): 열들의 값으로 채워진 하나의 실질적인 '데이터 단위'입니다. 회원 테이블에 가입한 '홍길동'이라는 특정 회원 한 명의 전체 정보 묶음이 하나의 행(Row)이 됩니다.

② 데이터 고유의 식별자: 기본키 (Primary Key, PK)

우리가 설계하는 쇼핑몰에는 수천 명의 동명이인 '홍길동'이 존재할 수 있습니다. 시스템이 이 수많은 홍길동을 구별해 내지 못한다면 주문 배송이 엉망진창이 되겠죠. 그래서 등장한 것이 기본키(Primary Key)입니다.

• 역할: 테이블 내의 수많은 레코드(Row) 중 "단 하나의 레코드를 유일하게 구별해 낼 수 있는 최소한의 고유 식별 열"입니다.
• 성질 1. 유일성 (Uniqueness): 기본키에 입력되는 값은 중복될 수 없습니다. 학번이나 군번, 이메일 주소처럼 고유해야 합니다.
• 성질 2. 최소성 (Minimality): 레코드를 식별하는 데 꼭 필요한 최소한의 열 조합이어야 합니다.
• 성질 3. Not Null (빈값 불가): 데이터의 기준선이 되는 기본키 값은 절대로 비어 있거나 누락(NULL)될 수 없습니다.

2. RDBMS의 꽃: 외래키(FK)와 참조 무결성(Referential Integrity)

RDBMS가 단순히 엑셀 표들의 묶음과 결정적으로 구별되는 지점은 바로 외래키(Foreign Key)를 통한 테이블 간의 관계 설정입니다.

① 관계의 다리: 외래키 (Foreign Key, FK)

• 역할: 한 테이블의 어떤 열이 "다른 테이블의 기본키(PK)를 가리켜 참조하는 연결 고리 고유 열"입니다.
• 의의: 외래키가 존재함으로써 우리는 중복 데이터를 일일이 모든 테이블에 저장하지 않고, 가벼운 키값 매핑만으로 수십 개의 테이블을 논리적으로 상호 연결할 수 있습니다.

② 데이터 붕괴 방지선: 참조 무결성 (Referential Integrity)

외래키로 두 테이블이 묶이는 순간, DBMS는 매우 엄격한 '참조 무결성 법칙'을 감시하기 시작합니다. 참조 무결성이란 "외래키 값은 반드시 참조하는 부모 테이블의 기본키 값으로 존재하는 데이터이거나, 혹은 Null(빈값)이어야 한다"는 무결성 제어 규칙입니다.

만약 참조 무결성 규칙이 존재하지 않는다면 어떤 비참한 버그가 발생할까요?

• 유령의 주문: 우리 사이트에 가입조차 하지 않은 유령 회원 ID(attacker@hack.com)로 수백만 원짜리 명품 패딩 주문서(Orders)가 버젓이 작성됩니다.
• 고아 데이터 (Orphan Data): 고객이 탈퇴하면서 고객 정보가 지워졌는데, 배송 부서의 주문 상세 파일에는 탈퇴한 고객의 주소나 주문 내역이 여전히 둥둥 떠다니게 됩니다. 부모는 사라졌는데 자식 데이터만 낙오되는 일명 '고아 데이터'의 파국입니다.

RDBMS는 외래키 제약조건을 강제하여, 존재하지 않는 부모 데이터를 자식 테이블이 억지로 참조하려는 시도나, 자식이 버젓이 참조하고 있는데 부모 데이터를 무단으로 지워버리는 파괴적인 행위를 데이터베이스 엔진 단에서 원천적으로 거부(Reject)합니다.

3. 실전 쇼핑몰 데이터 모델 분석 (ERD & Create Table)

우리 교재 5.2절에 구현된 의류 쇼핑몰 데이터베이스(shopping_db)의 실제 뼈대 테이블 관계도를 보며 기본키와 외래키의 실무 매핑 구조를 정교하게 뜯어보겠습니다.

① Customers(고객) [PK: cust_id]

• 가입하는 회원의 고유 식별자는 고객번호(cust_id)가 기본키(PK) 역할을 합니다. 1명의 고객은 유일한 cust_id로 식별됩니다.

② Orders(주문) [PK: ord_no, FK: cust_id]

• 주문 테이블은 각 주문을 고유하게 구분하는 번호인 ord_no를 기본키로 갖습니다.
• 동시에, 이 주문을 "누가 진행했는가"를 추적하기 위해 cust_id 컬럼을 외래키(FK)로 설정해 부모 테이블인 Customers(cust_id)를 엄격하게 참조하도록 묶습니다.
• 참조 무결성 효과: 만약 비정상적인 회원 ID로 주문 생성을 시도하면, MySQL은 즉각 FOREIGN KEY constraint fails 에러를 뱉어내며 삽입 연산을 전면 거부합니다.

③ Products(의류상품) [PK: prod_cd]

• 쇼핑몰 상품 카탈로그 테이블은 영문과 숫자로 조합된 고유한 상품 코드(prod_cd)를 기본키로 설정하여 상품을 유일하게 통제합니다.

④ Ord_items(주문내역) [PK: ord_item_no, FKs: ord_no, prod_cd]

• 하나의 주문(Orders)서 안에는 여러 종류의 티셔츠나 바지가 포함될 수 있습니다. 이를 관리하는 주문 상세 테이블이 바로 Ord_items입니다.
• 주문내역번호(ord_item_no)가 기본키이고, 부모인 Orders 테이블의 ord_no와 Products 테이블의 prod_cd를 각각 외래키(FK)로 강력하게 이중 참조합니다.
• 참조 무결성 효과: 이미 등록되어 정상 판매 중인 클래식 티셔츠(P0001)를 관리자가 실수로 데이터베이스에서 그냥 삭제(DELETE)하려 하면, 이 상품 코드를 주문내역에서 끈질기게 붙잡고 있기 때문에 데이터베이스 엔진이 차단벽을 가동해 삭제를 철저하게 무력화합니다.

4. 아키텍트의 깊이: 부모 데이터 조작 시 자식의 대응 옵션

실무에서 부모 데이터의 변화가 일어날 때(예: 회원 정보 수정이나 상품 단종 등), 부모를 바라보고 있는 외래키(FK) 컬럼들을 어떻게 관리할지 아키텍처적 대응 전략을 코드로 정의해 두어야 합니다. 대표적인 4대 제어 옵션입니다.

• RESTRICT / NO ACTION (제한): 기본 설정입니다. 자식 테이블에서 해당 부모 데이터를 하나라도 참조하고 있다면, 부모 데이터의 삭제나 수정을 원천적으로 불허합니다. (가장 안전한 지갑 사수 방어선)
• CASCADE (연쇄 반영): 부모 테이블의 데이터가 지워지거나 변경되면, 이를 외래키로 가리키고 있던 자식 테이블의 행들도 운명을 같이하여 함께 삭제되거나 자동으로 연쇄 수정됩니다. (예: 회원 탈퇴 시 해당 회원의 모든 주문 이력도 찌꺼기 없이 완벽하게 자동 일괄 삭제되도록 연동하는 기법)
• SET NULL (널값 전환): 부모 데이터가 삭제되면, 자식 테이블의 외래키 컬럼값을 그냥 빈값(NULL)으로 덮어씁니다. (예: 상품이 영구 단종되어 Products에서 삭제되어도, 주문 내역의 통계는 보존해야 하므로 상품 코드 필드만 빈값으로 돌려 이력을 남겨두는 방식)
• SET Default (기본값 전환): 부모 데이터가 삭제되면, 자식 테이블의 외래키 컬럼값을 미리 정의한 기본값(Default)으로 덮어씁니다. (예: 상품이 영구 단종되어 Products에서 삭제되어도, 주문 내역의 통계는 보존해야 하므로 상품 코드 필드만 기본값으로 돌려 이력을 남겨두는 방식)

마치며: 무결한 데이터 요새 속에서 편안하게 코딩하십시오

오늘 우리는 RDBMS가 단순 파일의 한계를 어떤 정교한 논리 구조로 극복해 냈는지, 그 정수(essence)에 해당하는 기본키와 외래키의 상호 연동성, 그리고 참조 무결성의 절대적 안보력을 완벽하게 체득했습니다.

"RDBMS의 정규화와 제약조건을 깊게 이해하는 것은, 데이터베이스 엔진 내부에 스스로 데이터를 지키는 똑똑한 인공지능 경비원을 고용해 세워두는 것과 같습니다."

데이터의 무결성이 데이터베이스 핵심 규칙으로 영구히 수호되기 때문에, 우리는 마음 편하게 백엔드 SQL 쿼리를 작성하고 멋지게 비즈니스 로직을 빌딩할 수 있는 거대한 자신감을 획득하게 된 것입니다.

하지만 현대의 클라우드 서비스 환경에서 이 엄격한 RDBMS 진영에 대항하여, 스키마를 던져버리고 무한대로 자유로운 영토를 개척한 또 하나의 초강력 데이터베이스 패러다임이 폭풍을 몰고 왔습니다.

다음 포스팅에서는 이 엄격한 RDBMS의 사슬을 끊고 수평적 확장의 자유를 선사한 NoSQL 진영의 숨 막히는 서막, '[NoSQL의 탄생] 대규모 트래픽 분산과 스키마리스(Schema-less) 유연성이 필요한 이유' 편으로 찾아뵙겠습니다. 오늘 배운 기본키와 외래키 설계 과정에서 궁금한 점이 있으시다면 언제든 운영자 메일로 편하게 질문해주세요. 오늘도 안전하고 지혜로운 클라우딩 라이프 하세요. 감사합니다! 😉

출처

• 이현호. 실무 프로젝트로 완성하는 클라우드 환경에서 DB 구축과 웹 개발. 길벗캠퍼스. 2026.04. (2장 '데이터와 데이터베이스' 및 5.2장 '의류 쇼핑 DB 구축', 041-042 및 134-137페이지 참조)
• 이현호. "02장. 데이터와 데이터베이스" 설명 오디오 가이드 스크립트 RDBMS 테이블 설계 기본키/외래키 매핑 관계성 비하인드 아키텍처 대화록 반영.
• MySQL Reference Manual - Foreign Key Constraints (https://dev.mysql.com/doc/refman/8.0/en/create-table-foreign-keys.html) 및 Relational Database Schema Design Best Practices.