먼저, 역으로 하나 생각해보고 싶은 것이, 데이터 모델만 보고 비즈니스 로직을 얼마나 이해할 수 있을까 하는 질문입니다. 여기서 데이터 모델이란 말그대로 ERD만을 이야기합니다. 쉽게 생각해서 ERwin파일이나 DA# 파일만 있다고 가정하는 것입니다. DBMS에 접속해서 데이터를 못 본다고 할 때요.
저는 아무리 잘 관리된 데이터모델이라 할지라도 비즈니스 로직의 반도 이해하기 어렵다고 생각합니다.
일부 숙련된 데이터 모델러 분들은 일반 모델러보다 훨씬 빠르게 모델을 이해하기도 합니다만, 저는 이런 부분이 잘 관리된 데이터 모델에서 기인한다고 생각하지 않습니다. 제 생각에 그런 분들은 이미 비즈니스 로직에 대한 기본 지식을 통해 모델을 이해하시는 분이거나, 기존 비즈니스 로직에 대한 이해가 없어도, 비즈니스를 모델로 표현하는 방법에 익숙하기 때문에 적응이 빠른 것이라 봅니다. 또 모델링 숙련자는 익숙하지 않은 비즈니스도 빠르게 습득하는 능력이 있습니다. 하지만 어떤 이유도 좋은 모델에서 이해도를 높여주지 않는다고 생각합니다. (좋은 모델이 있으면 이 작업이 더 수월하긴 할 것입니다.)
DBA 입장에서 볼 때도 마찬가지라고 봅니다. ERwin같은 경우 DBMS를 선택할 수 있고, DBMS의 특성에 맞는 많은 속성들을 버전에 따라 최대한 지원할 수 있는 기능들은 만들어져있습니다. 하지만 이 기능들을 최대한 이용해서, 물리적인 속성까지 ERD에서 관리하는 곳은 아직 들어보지 못했습니다. 그건… 별도 스크립트나 DBMS에서 짂접 관리하는 것이 편하기 때문일 것입니다. ERD가 DBMS와 실시간으로 싱크되지 않는 이상 그런 부분은 어려울 것 같습니다.
위 두 가지 측면에서 ERD에 비즈니스로직이나 물리속성을 “꽤 높은 수준으로” 관리하기는 어렵다고 생각합니다. (여기서 말씀드리는 물리속성이란 테이블스페이스, 스토리지, 인덱스등의 좀 더 물리스러운 정보입니다.) 그럼 모델링에서 주로 집중해야 하는 관계적인 측면은 어떨까요.
이 부분도… 모델링에는 태생적인 한계가 있다고 생각합니다. 컬럼간의 관계, row간의 관계, 테이블간의 관계, 데이터 발생/변경/삭제 규칙 등을 표현하기에 ERD는 너무 제한적으로 보입니다. 아니, 그렇다기 보다는, 모델링은 만능 도구가 아니며 데이터 모델을 이해시키기 위한 생긴 프로토콜이라고 생각합니다.
개인적인 결론을 말씀드리면 그냥 적정하게 협의된 수준에서 정보만 표기하는게 가장 좋지 않을까 합니다. 비즈니스와 시스템의 난이도와 중요도에 따라 적당히의 수준은 달라질 것 같습니다. 가장 기초적인 식별관계만 보아도 그렇습니다. 고객은 너무 자주 쓰이니 관계선을 생략한다. 코드는 테이블로 퉁친다. 이런게 명시적/암묵적으로 존재하는 협의 수준이라고 생각합니다.
그래서 필수적인 사항에 대해서만 꼭 표기하자 정도의 생각이 있습니다. 뭐든지 관리가 되면 좋습니다. ERD에 비즈니스 로직부터 물리 레이어까지의 정보가 있으면 ERD만 보고 이해할 수 있는게 많으니 보는 입장에서는 편할 것 같습니다. 다만, 그렇게 관리하기 위해서 드는 에너지는 관리 항목 수에 비례합니다. 인덱스를 만드는 것 vs 쓰는 것과 비슷해 보입니다.
특히 요즘은 더욱 관리요건이 적어야 한다고 봅니다. 지금 주 52시간(MAX) 근무제가 이제 막 시행이 되었는데, 관리 항목이 많은 ERD라면… 주 80시간으로도 어려울 것 같습니다.