Entity 도출 실습-1

1.1 요구사항 문서는 정답지가 아니다

이제 도서 대여 관리 시스템의 RFP와 인터뷰 내용을 살펴볼 것이다.
하지만 그 전에 한 가지를 분명히 해야 한다.

RFP는 데이터 모델의 정답지가 아니다. 인터뷰 내용도 마찬가지다.

초보자는 요구사항 문서를 받으면 그 안에 있는 명사를 그대로 엔터티로 옮기려 한다. 문서에 “회원”이 나오면 회원 엔터티를 만들고, “도서”가 나오면 도서 엔터티를 만들고, “연체”가 나오면 연체 엔터티를 만든다. 마치 문서에 등장한 단어의 목록을 데이터 모델로 변환하면 되는 것처럼 생각한다.

하지만 실제 모델링은 그렇게 단순하지 않다.

요구사항 문서는 업무 담당자의 언어로 작성된며, 여기서 우리는 반드시 관리 대상인지 숙고해서 엔터티를 도출해야 한다.

업무 담당자는 “책”이라고 말할 수 있다.
하지만 모델러는 그 “책”이 책의 종류를 뜻하는지, 도서관에 실제로 꽂혀 있는 물리적인 한 권을 뜻하는지 구분해야 한다.

업무 담당자는 “회원이 책을 빌린다”고 말할 수 있다.
하지만 모델러는 그 문장에서 “회원”, “책”, “대여”라는 세 개의 데이터 단위를 분리해서 보아야 한다.

업무 담당자는 “연체자를 조회하고 싶다”고 말할 수 있다.
하지만 모델러는 연체자를 별도 엔터티로 만들지, 대여 데이터를 조건으로 조회할지 판단해야 한다.

같은 문장도 읽는 방식에 따라 완전히 다른 모델이 나온다.

1.2 요구사항을 그대로 믿으면 생기는 문제

예를 들어 RFP에 다음과 같은 문장이 있다고 하자.

회원은 도서를 대여할 수 있으며, 연체 중인 회원은 추가 대여가 제한된다.

이 문장만 보고 다음과 같은 엔터티를 떠올릴 수 있다.

처음 보기에는 자연스럽다. 문장에 회원이 나오고, 도서가 나오고, 대여가 나오고, 연체 중인 회원도 나온다. 그러니 연체회원이라는 엔터티를 만들고 싶어진다.

하지만 조금만 생각해보면 애매하다.

연체회원은 정말 독립적으로 등록되는 대상인가?
회원이 연체 상태가 되면 새로운 연체회원 데이터가 생성되는가?
연체 도서를 반납하면 연체회원 데이터는 삭제되는가?
한 회원이 여러 건의 대여 중 일부만 연체한 경우는 어떻게 표현할 것인가?

연체회원은 독립적인 사람의 종류가 아니다.
회원이 특정 조건에 놓인 상태에 가깝다.

그 조건은 대개 대여 데이터에서 계산된다.

현재일 > 반납예정일

그리고 실제반납일이 없음

이 조건을 만족하는 대여 건이 있으면, 해당 회원은 현재 연체 중인 회원으로 판단할 수 있다. 이 경우 연체회원은 엔터티라기보다 조회 결과에 가깝다.

물론 모든 경우에 연체 엔터티가 불필요한 것은 아니다.
연체료를 부과하고, 독촉장을 발송하고, 연체 제재 이력을 관리해야 한다면 별도 엔터티가 필요할 수 있다. 하지만 단순히 “연체 중인 회원을 조회한다”는 요구만으로는 연체회원 엔터티를 확정할 수 없다.

이것이 요구사항을 그대로 믿으면 안 되는 이유다.

요구사항 문장은 단서다.
정답은 아니다.

1.3 모델러는 문장 뒤의 구조를 읽어야 한다

데이터 모델러는 문장을 그대로 옮기는 사람이 아니다.
문장 뒤에 숨어 있는 구조를 읽는 사람이다.

다음 문장을 보자.

같은 책이 여러 권 있을 수 있으므로, 실제 도서 한 권마다 고유한 도서 번호를 부여하여 관리해야 한다.

이 문장은 짧지만 중요한 단서를 담고 있다.

첫째, “같은 책”이라는 표현이 나온다.
둘째, “여러 권”이라는 표현이 나온다.
셋째, “실제 도서 한 권마다”라는 표현이 나온다.
넷째, “고유한 도서 번호”라는 표현이 나온다.

이 문장을 대충 읽으면 “도서 엔터티가 필요하다” 정도로 끝난다.
하지만 모델러는 여기서 한 단계 더 들어가야 한다.

“같은 책”은 책의 종류를 말한다.
“실제 도서 한 권”은 도서관이 보유한 물리적 개체를 말한다.

즉, 이 문장은 하나의 도서 엔터티만으로 충분하지 않을 수 있다는 신호다.

이렇게 구분하면 같은 책을 여러 권 보유하는 상황을 자연스럽게 표현할 수 있다.
도서종은 책의 공통 정보를 담고, 도서는 실제 보유 중인 한 권을 나타낸다.

반대로 이 구분을 하지 않고 다음처럼 설계하면 문제가 생긴다.

이 모델은 재고 수량만 보는 업무라면 가능할 수도 있다.
하지만 도서관 대여 업무에는 부족하다.

어떤 책 한 권이 대여 중인지 알 수 없다.
어떤 책 한 권이 분실되었는지 알 수 없다.
특정 물리 도서의 상태를 추적할 수 없다.
대여 이력과 실제 도서 개체를 정확히 연결하기 어렵다.

따라서 “같은 책이 여러 권 있다”는 문장은 단순한 설명이 아니다.
엔터티를 분리해야 할 수도 있다는 강한 신호다.

1.4 RFP와 인터뷰에서 찾아야 할 것

이제부터 읽을 RFP와 인터뷰에서 독자가 찾아야 할 것은 단순한 명사 목록이 아니다.
다음 네 가지를 찾아야 한다.

첫째, 업무에서 계속 관리되는 대상이다.
등록되고, 수정되고, 조회되고, 상태가 바뀌는 대상은 엔터티 후보가 된다. 회원, 도서, 대여 같은 단어가 여기에 해당한다.

둘째, 여러 번 발생하는 사건이다.
대여, 주문, 결제, 예약, 신청, 승인처럼 시간이 지나며 반복적으로 발생하고 이력으로 남아야 하는 사건은 엔터티가 될 가능성이 높다.

셋째, 구분해야 하는 개념의 차이다.
책의 종류와 실제 책 한 권처럼, 같은 단어로 표현되지만 데이터 모델에서는 분리해야 하는 개념이 있다. 이런 차이를 놓치면 모델이 금방 한계에 부딪힌다.

넷째, 계산 가능한 결과와 저장해야 할 데이터의 차이다.
연체 여부, 대여 가능 여부, 보유 권수 같은 값은 다른 데이터에서 계산할 수 있는 경우가 많다. 계산할 수 있다고 해서 절대 저장하면 안 된다는 뜻은 아니다. 다만 저장하려면 이유가 있어야 한다.

이 네 가지 관점으로 요구사항을 읽으면, 문장이 다르게 보인다.

“회원은 도서를 대여할 수 있다”는 단순한 기능 설명이 아니다.
회원, 도서, 대여 사이의 관계를 암시하는 문장이다.

“회원 한 명은 동시에 최대 5권까지 대여할 수 있다”는 단순한 제한 조건이 아니다.
회원과 대여 사이에 1:N 관계가 있음을 알려주는 문장이다.

“반납이 완료된 대여 기록도 보관해야 한다”는 단순한 조회 요구가 아니다.
대여가 이력 엔터티로 남아야 한다는 신호다.

“정지 회원은 대여할 수 없다”는 단순한 예외 조건이 아니다.
회원 상태가 대여 가능 여부를 판단하는 업무 규칙에 사용된다는 뜻이다.

---

1.5 먼저 후보를 넓게 뽑고, 그다음 줄인다

엔터티 도출을 할 때 처음부터 정답만 골라내려고 하면 오히려 어렵다.
처음에는 후보를 넓게 뽑는 편이 낫다.

RFP와 인터뷰를 읽으면서 다음과 같은 단어를 모두 후보로 적어볼 수 있다.

도서관
도서
책
도서종
회원
직원
대여
반납
연체
저자
출판사
도서분류
도서상태
회원상태

이 단계에서는 너무 빨리 판단하지 않는다.
중요한 것은 후보를 빠뜨리지 않는 것이다.

그다음 각 후보를 하나씩 검토한다.

회원은 독립적으로 등록되고 관리되는가?
그렇다. 회원명, 연락처, 이메일, 가입일, 회원 상태를 가진다. 대여의 주체이기도 하다. 엔터티가 될 가능성이 높다.

대여는 독립적으로 관리되는가?
그렇다. 대여일, 반납 예정일, 실제 반납일을 가지며, 이력으로 보관된다. 회원과 도서를 연결하는 업무 사건이다. 엔터티가 될 가능성이 높다.

반납은 독립 엔터티인가?
아직은 확정하기 어렵다. 이번 요구사항에서는 실제 반납일을 기록하는 수준이다. 그렇다면 반납은 별도 엔터티가 아니라 대여의 속성으로 처리할 수 있다. 단, 반납 검수, 반납 담당자, 반납 상태, 손상 기록 등을 별도로 관리한다면 엔터티가 될 수 있다.

연체는 독립 엔터티인가?
현재 요구사항만 보면 계산 결과에 가깝다. 반납 예정일과 실제 반납일, 현재일을 기준으로 판단할 수 있다. 따라서 우선은 엔터티보다 파생 개념으로 보는 것이 자연스럽다.

저자와 출판사는 어떨까?
도서 정보의 단순 입력값이라면 속성으로 둘 수 있다. 하지만 저자별 검색, 출판사별 통계, 저자 정보 관리가 필요하다면 별도 엔터티가 될 수 있다.

이처럼 엔터티 도출은 “맞다/틀리다”의 문제가 아니다.
업무 범위와 관리 필요성에 따라 판단하는 과정이다.

---

1.6 이 장에서 사용할 판단 흐름

이 장에서는 다음 순서로 엔터티를 도출한다.

1. RFP와 인터뷰를 읽는다.
2. 문장에서 명사와 업무 사건을 넓게 표시한다.
3. 엔터티 후보 목록을 만든다.
4. 각 후보에 대해 관리 필요성을 검토한다.
5. 속성, 코드, 계산 결과, 화면 기능을 걸러낸다.
6. 핵심 엔터티를 확정한다.
7. 핵심 엔터티 사이의 관계를 간단히 확인한다.

여기서 중요한 단계는 4번과 5번이다.

후보를 뽑는 것은 어렵지 않다.
진짜 모델링은 후보를 검토하고 걸러내는 과정에서 시작된다.

어떤 후보는 살아남아 엔터티가 된다.
어떤 후보는 다른 엔터티의 속성으로 들어간다.
어떤 후보는 코드 테이블이 된다.
어떤 후보는 조회 조건이나 계산 결과로 남는다.
어떤 후보는 이번 시스템의 범위 밖으로 제외된다.

이 판단을 반복하면서 모델은 점점 선명해진다.

---

1.7 읽기 전에 기억할 것

이제 RFP와 인터뷰 내용을 읽을 준비가 되었다.
읽을 때는 다음 질문을 계속 던져야 한다.

이 단어는 정말 독립적으로 관리해야 하는가?
이 단어는 자기만의 속성을 가지는가?
이 단어는 다른 대상과 관계를 맺는가?
이 단어는 시간이 지나도 이력으로 남아야 하는가?
이 단어를 모델에서 제외하면 어떤 업무 질문에 답할 수 없게 되는가?

이 질문에 답할 수 있으면 엔터티 도출은 훨씬 쉬워진다.

데이터 모델링은 문서를 테이블로 번역하는 일이 아니다.
업무 문장 속에서 데이터의 구조를 찾아내는 일이다.

이제 실제 RFP와 인터뷰를 읽어보자.