SQLD 대비 - 엔터티(Entity) — "테이블이랑 뭐가 다른데?" 에 대한 정확한 답

 

데이터베이스를 다루다 보면 한 번쯤 이런 의문이 생깁니다.

 

"엔터티가 뭔데? 그냥 테이블 아니야?"

 

사실 이 질문은 SQLD 수험생뿐만 아니라 실무에서 수년간 SQL을 써온 개발자도 정확히 답하기 어려운 부분입니다. 매일 CREATE TABLE을 쓰면서도 '엔터티'라는 단어가 나오면 갑자기 모호해지는 경험, 많은 분이 공감하실 것입니다.

 

그런데 SQLD 1과목 '데이터 모델링의 이해'에서 엔터티는 가장 기본이 되는 개념입니다. 여기서 흔들리면 속성, 관계, 식별자까지 전부 불안해집니다. 오늘 이 글에서 엔터티의 정의부터 분류, 특징, 그리고 시험에 나오는 포인트까지 한 번에 정리하겠습니다.

엔터티란 무엇인가 — 교과서적 정의 너머의 이해

한국데이터산업진흥원에서 발간한 'SQL 전문가 가이드'에 따르면, 엔터티란 "업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Thing)"이라고 정의합니다.

 

좀 더 직관적으로 표현하면 이렇습니다. 현실 세계에서 우리가 관리해야 하는 '무언가'를 데이터로 표현한 집합입니다. '사원', '고객', '주문', '상품' 같은 것들이 전부 엔터티입니다.

 

여기서 핵심은 "집합"이라는 단어입니다. 엔터티는 개별 건(건건이)이 아니라, 같은 성격을 가진 데이터들의 묶음을 말합니다. '홍길동'이라는 한 사람은 엔터티가 아니라 '사원'이라는 엔터티의 인스턴스(Instance)입니다.

 

객체지향 프로그래밍에 익숙하신 분이라면 이렇게 대응시켜 보시면 됩니다. 클래스(Class)가 엔터티이고, 오브젝트(Object)가 인스턴스입니다. 이 비유는 SQLD 공식 교재에서도 언급하고 있는 내용입니다.

엔터티와 테이블, 정말 같은 것인가

결론부터 말하면, 엔터티와 테이블은 같지 않습니다. 관련은 깊지만 존재하는 차원이 다릅니다.

구분 엔터티(Entity) 테이블(Table)

소속 단계	논리적 데이터 모델링	물리적 데이터 모델링
표현 도구	ERD(개체-관계 다이어그램)	DDL(CREATE TABLE)
구성 요소	속성(Attribute), 인스턴스	컬럼(Column), 로우(Row)
관심사	업무 규칙, 데이터 요구사항	저장 구조, 성능 최적화
1:1 대응?	반드시 1:1은 아님	엔터티로부터 변환됨

 

데이터 모델링은 개념 → 논리 → 물리, 이 세 단계를 거칩니다. 엔터티는 논리적 단계에서 정의되고, 테이블은 물리적 단계에서 구현됩니다.

 

하나의 엔터티가 반드시 하나의 테이블이 되는 것은 아닙니다. 슈퍼타입/서브타입 구조에서는 하나의 엔터티가 여러 테이블로 쪼개질 수도 있고, 반대로 여러 엔터티가 하나의 테이블로 통합될 수도 있습니다.

 

실무에서 "엔터티 = 테이블"이라고 부르는 것은 편의상의 표현입니다. 하지만 SQLD 시험에서는 이 차이를 정확히 묻습니다. 헷갈리지 않도록 주의가 필요합니다.

반드시 외워야 할 엔터티의 6가지 특징

SQLD 시험에서 엔터티 관련 문제가 나오면 거의 대부분 이 6가지 특징에서 출제됩니다. 하나라도 빠지면 적절한 엔터티로 볼 수 없습니다.

 

첫째, 해당 업무에서 필요하고 관리하고자 하는 정보여야 합니다. '환자'라는 엔터티는 병원 시스템에서는 필수이지만, 일반 회사의 인사 시스템에서는 필요하지 않습니다. 업무 범위에 따라 엔터티의 적절성이 달라진다는 뜻입니다.

 

둘째, 유일한 식별자(Unique Identifier)에 의해 식별이 가능해야 합니다. 사원번호, 주문번호처럼 각 인스턴스를 고유하게 구분할 수 있는 속성이 반드시 존재해야 합니다.

 

셋째, 영속적으로 존재하는 인스턴스의 집합이어야 합니다. 여기서 '두 개 이상'이라는 조건이 매우 중요합니다. 인스턴스가 단 하나뿐인 것은 엔터티로 적절하지 않습니다. 예를 들어 'S병원'이라는 엔터티는, 그 병원이 단 하나만 존재한다면 엔터티로 성립되지 않습니다.

 

넷째, 업무 프로세스에 의해 이용되어야 합니다. 정의만 해놓고 아무 업무에서도 사용하지 않는 엔터티는 존재 의미가 없습니다.

 

다섯째, 반드시 속성(Attribute)이 있어야 합니다. 속성 없이 이름만 있는 엔터티는 아직 정의가 완료되지 않은 것입니다. 최소 2개 이상의 속성을 가져야 합니다.

 

여섯째, 다른 엔터티와 최소 한 개 이상의 관계가 있어야 합니다. 다만 예외가 있습니다. 통계성 엔터티, 코드성 엔터티, 시스템 내부 처리용 엔터티(예: 트랜잭션 로그 테이블)는 관계를 생략할 수 있습니다. 이 예외 조건도 시험에 자주 등장합니다.

 

엔터티의 분류 — 두 가지 축으로 나눈다

엔터티는 크게 두 가지 기준으로 분류합니다. 유무형에 따른 분류와 발생 시점에 따른 분류입니다. 두 축 모두 SQLD에서 자주 출제되는 영역입니다.

유무형에 따른 분류

분류 설명 예시

유형 엔터티	물리적 형태가 있고 안정적이며 지속적으로 활용됨. 업무에서 구분하기가 가장 용이함	사원, 물품, 강사
개념 엔터티	물리적 형태는 없지만 관리해야 할 개념적 정보를 포함	조직, 보험상품
사건 엔터티	업무 수행에 따라 발생되며, 발생량이 많고 통계자료에 활용 가능	주문, 청구, 미납

 

시험에서 자주 나오는 함정이 있습니다. '부서'를 유형 엔터티로 착각하는 경우입니다. 부서는 물리적 형태가 없는 개념적 구분이므로 개념 엔터티에 해당합니다. '주문'은 업무 행위의 결과이므로 사건 엔터티입니다. 이런 분류 판단을 묻는 문제가 빈번하게 출제됩니다.

발생 시점에 따른 분류

분류 설명 예시

기본(키) 엔터티	업무에 원래 존재하며, 독립적으로 생성됨. 다른 엔터티의 부모 역할. 고유한 주식별자를 가짐	사원, 부서, 고객, 상품
중심 엔터티	기본 엔터티로부터 발생. 업무의 중심 역할. 데이터량이 많고 많은 행위 엔터티를 생성함	계약, 예금원장, 주문
행위 엔터티	두 개 이상의 부모 엔터티로부터 발생. 내용이 자주 변경되거나 데이터량이 증가함	주문상세, 접수이력

 

기본 엔터티는 다른 엔터티로부터 주식별자를 상속받지 않는다는 점이 핵심입니다. 반면 중심 엔터티와 행위 엔터티는 기본 엔터티의 식별자를 상속받아 관계를 형성합니다. 행위 엔터티는 분석 초기 단계보다는 상세 설계 단계나 프로세스와 상관모델링을 진행하면서 주로 도출됩니다.

ERD에서 엔터티는 어떻게 표현되는가

ERD(Entity-Relationship Diagram)를 작성하는 순서는 정해져 있습니다. 엔터티 도출 → 엔터티 배치 → 관계 설정 → 관계명 기술 → 참여도 기술 → 필수 여부 기술의 흐름으로 진행합니다.

 

배치 원칙도 있습니다. 가장 중요한 엔터티를 왼쪽 상단에 배치하고, 추가로 발생되는 엔터티들을 오른쪽과 하단에 배치하는 것이 원칙입니다. 이 순서와 원칙을 묻는 문제도 간간이 출제됩니다.

 

엔터티 하나가 성립하려면 최소한 2개 이상의 속성과 2개 이상의 인스턴스를 가져야 합니다. 이것을 '면적으로 표현될 수 있어야 한다'고 표현합니다. 점(인스턴스 1개)이나 선(속성 1개)이 아니라 면적이 되어야 비로소 엔터티 자격을 갖춘다는 뜻입니다.

실무에서 엔터티 개념이 왜 중요한가

"시험용 개념 아닌가?" 라고 생각하실 수 있습니다. 하지만 엔터티를 제대로 이해하지 못하면 실무에서도 문제가 생깁니다.

가장 흔한 실수는 테이블 설계를 할 때 논리적 모델링을 건너뛰고 바로 물리적 테이블을 만드는 것입니다. 이렇게 하면 나중에 요구사항이 변경되었을 때 테이블 구조를 통째로 뜯어고쳐야 하는 상황이 발생합니다. 엔터티 단위로 먼저 설계하면 변경에 유연하게 대응할 수 있습니다.

또한 팀 내에서 데이터 구조를 논의할 때, "이 엔터티의 주식별자는 뭔가요?"라고 물었을 때 정확히 대답할 수 있는 것과 없는 것은 커뮤니케이션 효율에 큰 차이를 만듭니다.

 

반응형

 

SQLD 시험 준비를 하다 보면 개념은 이해했는데 실전 문제에서 자꾸 헷갈리는 경우가 있습니다. 최근에는 엔터티, 정규화 같은 데이터 모델링 개념을 실습형으로 학습할 수 있는 온라인 강의 플랫폼도 나와 있습니다. 영상으로 보면 ERD 그리는 과정을 눈으로 따라가면서 익힐 수 있어서, 독학이 답답하신 분이라면 한번 살펴보시는 것도 방법이 될 수 있습니다.

엔터티 명명 규칙 — 시험에서 간과하기 쉬운 포인트

엔터티에는 이름을 붙이는 규칙이 있습니다. 시험에서 직접적으로 묻기도 하고, 보기를 판별하는 단서가 되기도 합니다.

해당 업무에서 실제로 사용하는 이름을 부여해야 합니다. 약어 사용은 금지합니다. 서술식(문장형) 엔터티명도 사용하지 않습니다. 가능하면 전체 데이터 모델에서 유일한 이름이어야 합니다. 예를 들어 '주문정보를관리하는테이블'이 아니라 '주문'이라고 명명하는 것이 올바릅니다.

실전 기출 유형 문제로 확인하기

지금까지 정리한 내용을 기출 유형 문제로 점검해 보겠습니다. SQLD 시험에서 실제로 출제된 유형과 동일한 형태로 구성했습니다.

---

【문제 1】 다음 중 엔터티의 특징으로 적절하지 않은 것은?

(1) 엔터티는 업무에서 필요로 하는 정보여야 한다.

(2) 엔터티는 유일한 식별자에 의해 식별이 가능해야 한다.

(3) 엔터티에는 반드시 하나 이상의 인스턴스가 존재해야 한다.

(4) 엔터티는 반드시 속성(Attribute)을 가져야 한다.

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

정답: (3) 엔터티는 '두 개 이상'의 인스턴스 집합이어야 합니다. '하나 이상'이 아니라 '두 개 이상'이라는 점이 핵심입니다. 이 조건은 엔터티를 면적으로 표현할 수 있어야 한다는 것과 같은 맥락입니다. 인스턴스가 하나뿐인 것은 엔터티로서 적절하지 않습니다.

---

【문제 2】 다음 중 유형 엔터티(Tangible Entity)의 예로 가장 적절한 것은?

(1) 주문

(2) 사원

(3) 부서

(4) 보험상품

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

정답: (2) 유형 엔터티는 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티입니다. '사원'은 물리적으로 존재하는 사람이므로 유형 엔터티에 해당합니다. '주문'은 업무 행위의 결과이므로 사건 엔터티, '부서'와 '보험상품'은 물리적 형태가 없는 개념 엔터티입니다. 이 분류를 헷갈리면 반복해서 틀리게 되므로 표로 외워두는 것이 좋습니다.

---

【문제 3】 다음 중 엔터티 간 관계를 생략할 수 있는 경우로 적절하지 않은 것은?

(1) 통계를 위한 엔터티를 도출하는 경우

(2) 코드성 엔터티를 도출하는 경우

(3) 시스템 내부 처리를 위한 엔터티(트랜잭션 로그 등)를 도출하는 경우

(4) 기본(키) 엔터티로부터 중심 엔터티를 도출하는 경우

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

정답: (4) 기본 엔터티로부터 중심 엔터티를 도출하는 경우는 관계가 반드시 존재해야 합니다. 중심 엔터티는 기본 엔터티로부터 발생하며 주식별자를 상속받는 구조이기 때문입니다. 관계를 생략할 수 있는 예외는 통계성 엔터티, 코드성 엔터티, 시스템 내부 처리용 엔터티에 한정됩니다. 이 세 가지 예외를 정확히 기억해 두시기 바랍니다.

---

정리하겠습니다

엔터티는 테이블과 비슷해 보이지만 존재하는 차원이 다릅니다.

엔터티는 논리적 설계의 산물이고, 테이블은 물리적 구현의 결과입니다.

SQLD 시험에서는 이 차이를 정확히 인지하고 있는지를 반복적으로 묻습니다.

 

핵심만 다시 한번 정리합니다.

엔터티의 6가지 특징(업무 필요, 식별 가능, 2개 이상 인스턴스, 업무 프로세스 이용, 속성 보유, 관계 존재), 유무형 분류(유형/개념/사건), 발생 시점 분류(기본/중심/행위), 그리고 관계 생략 가능한 3가지 예외(통계성/코드성/시스템 내부용).

이 네 가지만 확실히 잡아두면 엔터티 관련 문제는 대부분 대응할 수 있습니다.

 

다음 글에서는 엔터티의 구성요소인 '속성(Attribute)'과 '도메인(Domain)'에 대해 다루겠습니다. 컬럼 하나에도 설계 철학이 담겨 있다는 이야기, 기대해 주십시오.

 

SQLD 시험 일정과 접수는 한국데이터산업진흥원 데이터자격검정 홈페이지(dataq.or.kr)에서 확인하실 수 있습니다. 올해 안에 한 번 도전해 보세요.