Entity 도출

데이터 모델링은 ERD를 그리는 일이 아니다.

많은 프로젝트에서 데이터 모델링은 테이블을 설계하고, 컬럼을 정의하고, 관계선을 긋는 작업처럼 취급된다. 그래서 모델링 회의가 시작되면 사람들은 곧바로 이런 질문을 던진다.

“회원 테이블에는 어떤 컬럼이 들어가야 하지?”
“주문 테이블과 결제 테이블은 1:1인가, 1:N인가?”
“상태값은 코드 테이블로 뺄까, 그냥 컬럼으로 둘까?”

물론 이런 질문은 중요하다.
하지만 이 질문들은 모두 한 단계 뒤의 질문이다.

데이터 모델링이 실패하는 이유는 대개 컬럼명을 잘못 지었기 때문이 아니다. 데이터 타입을 잘못 골랐기 때문도 아니다. 관계선을 반대로 그렸기 때문도 아니다.

더 근본적인 이유는 따로 있다.

처음부터 잘못된 대상을 모델링했기 때문이다.

시스템이 기억해야 할 대상을 빠뜨리거나, 반대로 기억하지 않아도 될 대상을 엔터티로 만들어버리면 모델은 처음부터 흔들린다. 이후에 아무리 정규화를 하고, 인덱스를 만들고, 컬럼명을 다듬어도 근본적인 문제가 사라지지 않는다.

---

잘못된 시작

도서 대여 시스템을 만든다고 해보자.

처음에는 누구나 “회원”과 “도서”를 떠올린다.
회원이 있고, 도서가 있고, 회원이 도서를 빌린다. 여기까지는 쉽다.

그래서 초보자는 다음과 같은 모델을 만들기도 한다.

겉으로 보면 큰 문제가 없어 보인다.
회원 테이블에 현재 빌린 도서와 대여일, 반납 예정일, 반납일이 있으니 대여 업무를 처리할 수 있을 것처럼 보인다.

하지만 이 모델은 곧바로 막힌다.

회원 한 명이 도서를 두 권 이상 빌리면 어떻게 할 것인가?
회원이 과거에 빌렸던 도서 이력은 어디에 남길 것인가?
한 회원이 같은 도서를 여러 번 빌리면 어떻게 구분할 것인가?
반납이 완료된 뒤 도서일련번호를 지우면 과거 대여 기록은 어떻게 조회할 것인가?

이 문제는 컬럼이 부족해서 생긴 것이 아니다.
대여라는 엔터티를 놓쳤기 때문에 생긴 문제다.

대여는 회원의 속성이 아니다.
도서의 속성도 아니다.
회원과 도서 사이에서 발생하는 업무 사건이다.

따라서 다음과 같이 모델의 중심을 바꿔야 한다.

이렇게 하면 질문에 답할 수 있다.

회원 한 명은 여러 번 대여할 수 있다.
도서 한 권도 시간이 지나며 여러 번 대여될 수 있다.
반납이 끝난 대여도 이력으로 남길 수 있다.
연체 여부도 대여 데이터를 기준으로 판단할 수 있다.

같은 업무를 다루더라도, 엔터티를 어떻게 잡느냐에 따라 모델의 설명력이 완전히 달라진다.

---

도서 엔터티에 대여 정보가 있는 경우

도서 엔터티에 대여 정보를 넣는 경우를 보자. 드물게 이렇게 설계하는 사람도 많다. 실제로 더 많을지도 모른다. 

이 모델은 “도서 한 권은 한 번에 한 명에게만 대여된다”는 규칙만 보면 그럴듯해 보인다. 실제로 현재 대여 상태만 확인하는 화면이라면 당장 구현도 가능하다.

하지만 이 모델 역시 오래가지 못한다.

도서가 과거에 누구에게 대여되었는지 알 수 없다.
반납이 완료되면 현재대여회원일련번호를 비워야 하므로 이력이 사라진다.
대여 횟수, 회원별 대여 이력, 연체 이력 같은 질문에 답하기 어렵다.
도서의 고유 정보와 대여 사건의 정보가 한 테이블에 섞인다.

이 설계의 문제는 도서가 무엇인지 잘못 이해한 데 있다.

도서는 관리 대상이다.
대여는 도서에 발생한 사건이다.

관리 대상과 사건을 한 테이블에 섞으면, 시간이 흐르는 업무를 표현하기 어렵다. 현재 상태만 남고 과거가 사라진다. 데이터 모델이 업무의 시간을 잃어버리는 것이다.

---

엔터티 도출은 모델링의 첫 번째 분기점이다

엔터티는 데이터 모델의 중심축이다.
속성은 엔터티에 붙고, 관계는 엔터티 사이에 생긴다.
따라서 엔터티를 잘못 잡으면 그 뒤의 모든 설계가 영향을 받는다.

좋은 모델은 대개 좋은 엔터티 도출에서 시작된다.
반대로 나쁜 모델은 불분명한 엔터티에서 시작된다.

엔터티가 불분명하면 이런 일이 생긴다.

업무에서는 분명히 중요한 사건인데 모델에는 남아 있지 않다.
하나의 엔터티가 서로 다른 두 개념을 억지로 함께 담고 있다.
단순한 상태값에 불과한 것을 독립 엔터티로 만들어 구조가 불필요하게 복잡해진다.
반대로 이력으로 남겨야 할 업무 사건을 단순 컬럼 하나로 처리해서 나중에 추적할 수 없게 된다.

데이터 모델링에서 가장 위험한 실수는 틀린 답을 쓰는 것이 아니다.
질문 자체를 잘못 잡는 것이다.

“회원 테이블에 어떤 컬럼이 필요한가?”라고 묻기 전에 먼저 물어야 한다.

“도서는 책의 종류를 말하는가, 실제 보유 중인 책 한 권을 말하는가?”
“대여는 단순한 행위인가, 이력으로 남겨야 할 업무 사건인가?”
“연체는 저장해야 하는 데이터인가, 계산 가능한 결과인가?”

이 질문들이 엔터티 도출의 질문이다.

---

같은 책 여러 권을 하나의 도서로 보면 어떻게 될까

도서 대여 시스템에서 자주 놓치는 문제가 하나 더 있다.
바로 “도서”라는 말이 두 가지 의미로 쓰인다는 점이다.

예를 들어 도서관에 『데이터베이스 입문』이 3권 있다고 하자.
이때 “도서”는 무엇을 뜻할까?

책의 종류를 뜻할 수도 있다.

하지만 대여 업무에서는 실제 책 한 권 한 권도 구분해야 한다.
같은 제목의 책이 3권이면, 그중 1권은 대여 중이고 2권은 대여 가능할 수 있다. 또 한 권은 분실되고 다른 한 권은 폐기될 수도 있다.

그런데 도서 종류만 관리하면 다음 문제가 생긴다.

이 모델은 단순 재고 관리처럼 보인다. 하지만 실제 대여 업무에는 충분하지 않다.

어떤 물리적 책이 대여되었는지 알 수 없다.
분실된 책이 몇 번째 책인지 알 수 없다.
특정 책 한 권의 상태 변경 이력을 추적하기 어렵다.
반납된 책이 어느 개체인지 확인할 수 없다.

따라서 도서관 업무에서는 "도서”와 “도서실체”를 구분해야 한다.

이 구분은 매우 중요하다.

도서는 책의 서지 정보를 나타낸다.
도서실체는 도서관이 실제로 보유한 물리적 책 한 권을 나타낸다.

이 둘을 구분하지 않으면 “같은 책이 여러 권 있다”는 단순한 문장 하나 때문에 모델 전체가 흔들릴 수 있다.

---

엔터티는 명사가 아니라, 업무가 기억해야 하는 대상이다

엔터티를 처음 배울 때 흔히 “명사를 찾으라”고 말한다.
이 방법은 초보자에게 출발점은 될 수 있다. 하지만 충분하지는 않다.

RFP나 인터뷰 문장을 보면 많은 명사가 나온다.

회원, 도서, 대여, 반납, 연체, 직원, 저자, 출판사, 도서 상태, 회원 상태.

이 명사들을 모두 엔터티로 만들면 모델은 금방 비대해진다. 반대로 익숙한 명사만 엔터티로 만들면 중요한 업무 사건이 빠진다.

엔터티는 단순히 문장에 등장하는 명사가 아니다.
엔터티는 업무적으로 식별할 수 있고, 속성을 가지며, 관계를 맺고, 시간이 지나도 관리해야 하는 데이터의 단위다.

따라서 엔터티를 도출할 때는 최소한 다음 질문을 던져야 한다.

첫째, 이것은 업무에서 독립적으로 식별해야 하는 대상인가?
둘째, 이 대상에 대해 관리해야 할 속성이 있는가?
셋째, 이 대상은 다른 대상과 관계를 맺는가?
넷째, 이 대상의 발생이나 변경 이력을 남겨야 하는가?
다섯째, 이것을 엔터티로 만들지 않으면 나중에 업무 질문에 답할 수 없는가?

이 질문을 통과하는 대상은 엔터티가 될 가능성이 높다.
반대로 이 질문에 답하지 못하는 대상은 속성, 코드, 계산 결과, 화면 기능, 또는 시스템 범위 밖의 개념일 수 있다.

---

잘못된 시작: 연체를 무조건 엔터티로 만들면 어떻게 될까

반대로, 모든 중요한 업무 단어를 엔터티로 만드는 것도 문제다.

도서 대여 시스템에는 “연체”라는 중요한 개념이 있다.
연체 회원을 조회해야 하고, 연체 도서도 확인해야 하며, 연체 중인 회원은 추가 대여가 제한된다.

그렇다면 연체는 엔터티일까?

초보자는 다음과 같이 만들 수 있다.

이 모델이 항상 틀렸다고 말할 수는 없다. 연체료를 부과하고, 연체 통지를 발송하고, 연체 제재 이력을 별도로 관리해야 한다면 연체 엔터티가 필요할 수 있다.

하지만 이번 예제처럼 단순히 “반납 예정일이 지났지만 아직 반납되지 않은 도서”를 조회하는 수준이라면 이야기가 다르다.

연체 여부는 대여 데이터만으로 계산할 수 있다.

오늘 날짜가 반납 예정일보다 늦고, 실제 반납일이 없다면 연체 중이다.
실제 반납일이 반납 예정일보다 늦다면 연체 반납이다.

이 경우 연체는 독립적으로 발생한 데이터라기보다, 대여 데이터를 해석한 결과다. 그런데 이를 별도 엔터티로 만들면 중복과 불일치가 생길 수 있다.

예를 들어 대여 테이블에는 아직 반납되지 않은 것으로 되어 있는데, 연체 테이블에는 연체상태가 종료로 되어 있을 수 있다.
또 반납 예정일이 수정되었는데 연체일수가 갱신되지 않을 수도 있다.

계산 가능한 결과를 저장하면, 모델은 편리해지는 것이 아니라 불일치 가능성을 품게 된다.

따라서 “중요한 업무 개념”과 “독립 엔터티”는 구분해야 한다.
연체는 중요하지만, 반드시 엔터티일 필요는 없다.

---

엔터티 도출의 핵심 원칙

이 장에서는 엔터티를 도출할 때 다음 원칙을 사용한다.

첫째, 업무가 지속적으로 관리하는 대상을 찾는다.
한 번 언급되고 사라지는 단어가 아니라, 등록되고 조회되고 변경되고 추적되는 대상을 찾는다. 회원, 도서, 대여처럼 시스템 안에서 계속 관리되는 대상이 여기에 해당한다.

둘째, 속성을 가질 수 있는 대상을 찾는다.
엔터티는 자기 자신의 정보를 가진다. 회원은 이름, 연락처, 가입일, 상태를 가진다. 도서는 도서명, ISBN, 상태를 가진다. 대여는 대여일, 반납 예정일, 실제 반납일을 가진다.

셋째, 관계의 중심이 되는 대상을 찾는다.
엔터티는 다른 엔터티와 관계를 맺는다. 회원은 대여를 하고, 도서는 대여의 대상이 된다. 이때 대여는 회원과 도서를 연결하는 단순 연결선이 아니라, 자체 속성을 가진 업무 사건이다.

넷째, 이력으로 남아야 하는 사건을 놓치지 않는다.
업무 사건은 초보자가 가장 자주 놓치는 엔터티다. 주문, 결제, 배송, 예약, 신청, 승인, 대여 같은 단어는 행위처럼 보이지만 실제로는 중요한 이력 데이터인 경우가 많다.

다섯째, 계산 가능한 결과를 성급하게 엔터티로 만들지 않는다.
연체, 재고 부족, 이용 가능 여부처럼 다른 데이터로부터 계산할 수 있는 개념은 독립 엔터티가 아닐 수 있다. 물론 업무상 별도 관리가 필요하다면 엔터티가 될 수도 있지만, 그 판단에는 근거가 필요하다.

여섯째, 코드와 엔터티를 구분한다.
도서 상태, 회원 상태, 분류처럼 값의 목록을 관리하는 개념은 코드성 데이터일 수 있다. 모든 코드를 엔터티처럼 다루면 모델이 복잡해지고, 반대로 중요한 기준 데이터를 단순 문자열로 처리하면 관리가 어려워질 수 있다.

이 원칙들은 외워야 할 공식이 아니다.
RFP와 인터뷰 내용을 읽을 때 계속 되물어야 하는 판단 기준이다.

---

이제 문장에서 모델을 끌어낸다

실제 프로젝트에서 데이터 모델러가 처음 마주하는 것은 완성된 요구사항 목록이 아니다.
대개는 모호한 RFP, 담당자의 설명, 기존 엑셀 파일, 회의 중 나온 말들이다.

그 안에는 모델링에 필요한 단서가 숨어 있다.

“같은 책이 여러 권 있다.”
이 문장은 단순한 설명이 아니다. 도서의 종류와 실제 보유 도서를 구분해야 할 수 있다는 신호다.

“회원 한 명은 최대 5권까지 대여할 수 있다.”
이 문장은 회원과 대여 사이에 반복 관계가 있다는 신호다.

“반납이 끝난 뒤에도 대여 이력을 조회해야 한다.”
이 문장은 대여를 단순 상태값으로 처리해서는 안 된다는 신호다.

“연체 중인 회원은 추가 대여가 제한된다.”
이 문장은 연체 여부가 대여 가능 여부 판단에 사용되는 중요한 업무 규칙이라는 신호다.

데이터 모델링은 이런 문장을 해석하는 일이다.
문장을 읽고, 그 안에서 엔터티 후보를 찾고, 후보를 검토하고, 업무적으로 살아남는 개념만 모델에 남기는 일이다.

이 장에서는 도서 대여 관리 시스템을 예제로 사용한다.
먼저 간단한 RFP와 인터뷰 내용을 읽는다. 그런 다음 문장 속에서 엔터티 후보를 추출하고, 각 후보가 실제 엔터티인지 판단한다. 마지막으로 핵심 엔터티를 중심으로 초기 모델을 구성한다.

중요한 것은 처음부터 정답을 맞히는 것이 아니다.
어떤 단어를 왜 엔터티로 선택했는지, 어떤 단어를 왜 제외했는지 설명할 수 있어야 한다.

좋은 데이터 모델은 그림을 잘 그린 결과가 아니다.
업무를 정확히 읽은 결과다.

이제 RFP와 인터뷰 내용을 통해, 데이터 모델링의 첫 번째 분기점인 엔터티 도출을 시작해보자.