커뮤니케이션 컨텐츠 - 데이터 모델링
“데이터 모델링, 알면 알수록 더 어려워요”
데이터베이스 개발자 및 관리자라면 한번쯤은 데이터 모델링에 관심을 가졌을 것이다. 복잡한 업무 규칙을 데이터 구조의 정합성, 유연성, 확장성에 부합하도록 설계하는 데이터 모델링은 ‘정답이 없다’는 점 때문에 특히 더 어렵다. 한창 데이터모델링을 공부하면서 실전에 적용 중인 초보 모델러와 5년 이상의 모델러 경력을 가진 전문가가 한 자리에 모였다. 이들의 대화를 통해 데이터 모델링에 대한 실무에서의 고민을 담아봤다.
◇ 전문가(Expert) : 엔코아정보컨설팅 수석 컨설턴트 장희식 이사
◇ 대상자(User) : 오라클사용자모임 데이터모델링 1기 회원들
◇ 작성자 : 기묘 컨텐츠 제작팀 류한주
논리 모델 vs. 물리 모델
User 1 : 프로젝트에서 논리적 모델링을 하면서 느끼는 것 중에 하나가 현업의 실무자들이 원하는 사용 편이성을 논리적 모델에선 수용하기 어렵다는 점이다. 그러다 보니 논리적 모델 작성시 물리적 모델에 치우치게 되는데, 어떻게 해야 할지 모르겠다.
Expert : 이 부분은 모델링 하는 사람마다 의견이 틀릴 수도 있다. 물리적이건, 논리적이건 그리고 물리적인 DBMS가 오라클이건 사이베이스이건 상관없이 가장 중요한 것은 비즈니스 규칙을 얼마나 잘 반영했느냐이다. 업무가 돌아가야 하는 것이기 때문에 데이터가 갖는 업무 규칙을 잘 찾아내서 다이어그램 기법을 이용해서 표현해 놓는 것이다. 이 측면에서 보면 물리적 모델링과 논리적 모델링의 맥락은 통한다. 어떻게 하는 것이 유연하고, 확장성 있고, 데이터 값도 정확하게 할 수 있는지가 중요한 것이다.
User 2 : 그런데 어떤 화학 회사의 물류시스템과 관련된 프로젝트 나간 적이 있었는데, 발주사가 이미 물리 모델은 구축돼 있었고, 이를 보다 편리하고 정형화되게 만드는 논리 모델 구축을 원했었다. 그런데 이 새로운 부분은 발주사 관계자들이나 프로젝트 참여자 모두가 모르는 상황이다 보니, 어느 하나 결정하기도 힘들고 논의가 지지부진해지는 경향이 있었다. 물리 모델과 논리 모델에 대한 명확한 정의가 있었다면 좀 더 용이하게 수행할 수 있었을 것 같은데.
Expert : 내공이 약한 사람들끼리 싸워봐야 결론이 안 나기 때문에 생기는 문제다. 특히 프로젝트에서 만나는 현업의 사람들은 모델링을 공부한 사람들이 아니기 때문에 이들과 토론해서 결정하긴 더욱 힘들다. 특히 해당 업무에 대해선 현업의 사람이 더 많이 알기 때문에 자칫 주눅들 염려도 있다. 따라서 모델러는 해당 업무 환경에 대해 관계형 DBMS의 이론에 맞게끔 장단점을 분석해, 보여줌으로써 이들을 제압해야 한다. 그런 점에서 모델러에게는 분석력, 논리적 사고력, 프리젠테이션 기술이 구체적인 모델 산출 능력보다 더 중요하다. 물론 그러려면 많은 경험이 필요하다.
릴레이션쉽 매트릭스의 산출물로서의 가치
User 3 : 모델링의 산출물이 논리 모델링만은 아니라고 생각된다. 생명주기 분석서나 렐레이션쉽 매트릭스 같은 것을 해보면 엔터티와 속성에 대한 정의, 모델 검증에 있어서 도움이 될 것 같다. 또 엑셀이나 워드 형태로 현업에게 이해시킬 수 있는 양식을 만드는 방법도 연습을 해봐야 할 것 같다.
Expert : 릴레이션쉽 매트릭스는 머리에서 지웠으면 한다. 왜냐? 우리는 자식과 부모의 이항관계 모델링을 하지, 중복되는 모델링이나 삼항 모델링을 하지 않는다. <그림 1 참조> 레이션쉽 매트릭스를 그리고 엔터티의 관계 여부를 표시하다 보면 대부분의 엔터티가 ‘관계있음’으로 표시된다. 직접 관계 뿐 아니라 간접 관계까지 모두 표시되기 때문이다. 따라서 기업의 몇 백개, 몇 천개 수준의 엔터티에 대해 릴레이션을 표기하는 것은 효율성 면에서 의미가 없는 작업이다. 오히려 ERD를 직접 그리면서, 관계를 고민하고 검증하는 것이 더 효율적이다.
<그림 1>
User 2 : 그럼 릴레이션쉽 매트릭스에서 직접 관계만 표시할 수는 없는 건가?
Expert : 릴레이션쉽 매트릭스를 그릴 때는 엔터티만 도출된 상태기 때문에 엔터티 간 관계가 명확하게 머릿속에 있지 않다. 따라서 엔터티 간 관계가 직접 관계인지, 간접 관계인지 눈에 보이지 않기 때문에, 오히려 ERD를 직접 그리면서 엔터티 간 관계를 정의하고, 검증하는 것보다 효율성이 떨어진다는 것이다. 앞서 말한 것처럼 우리는 이항관계 모델링을 하기 때문에 엔터티에 대해 n-1개의 관계가 도출될 수밖에 없다. 머릿속으로 업무 정의와 엔터티 정의, 엔터티 간 디펜던시 정의가 완전하게 이뤄지지 않은 상태라면 릴레이션쉽 매트릭스만으론 산출물 도출이 안 된다.
업무 규칙 파악 중요성
User 4 : 모델링을 할 때 가장 어려운 점은 업무를 몰라서 깊이 있는 정의가 안 되고, 그로 인해 오류발생률이 높아지는데 있는 것 같다. 업무를 어느 정도 사전에 파악해야 제대로 모델링을 할 수 있을지 궁금하다.
Expert : 상당히 중요한 얘기다. 모델러는 업무를 몰라도 된다는 잘못된 편견이 있는데, 업무 파악은 데이터 모델의 기본이다. 예전엔 모델러가 없었기 때문에 발주사 관계자들이 상세히 설명을 해주고 파악하는데 시간도 많이 줬지만, 지금은 그렇지가 않다. 이제는 1년 이상 그 분야의 관련 업무를 해봤던 컨설턴트를 고객이 원하기 때문이다. 제대로 모델링을 하려면 그 회사의 업무를 거의 100% 파악하고 진행하는 것이 좋다. 그래야 프로그램과 애플리케이션에 업무 규칙에 녹아들 수 있고 그것을 기반으로 해야 데이터도 완성도가 높기 때문이다.
논리 모델링에서 논리가 약하다!?
User 1 : 논리가 가장 중요한 것 같다. 본인의 논리를 어떻게 펴서 상대방을 설득, 생각이 반영된 모델을 최종적으로 완성하느냐가 중요한데, 이 부분이 가장 힘들다.
Expert : 논리가 약하다. 논리 모델링을 하는데 논리가 약하다는 것은 정말 생각해 볼 문제인 것 같다.(웃음) 흔히들 모델링에서 Top Down 방식의 진행에 Bottom Up 검증이라는 얘길 한다. 데이터 모델을 볼 때 절대 숙지해야 하는 것은 전사적 고찰이다. 즉 업무적 정확도와 완성도, 구문적 정확도와 완성도를 전사적 입장에서 도찰해라. 이 컨셉을 가지고 거꾸로 모델링을 들여다보면 논리가 맞느냐 안 맞느냐를 검증할 수 있다. 특히 이때 활용하는 방법이 바로 인스턴스 차트를 만들어 보는 것이다. 항상 “1,2,3의 고객이 있고 a,b,c의 제품이 있다면”이라고 예를 들어 생각해보면 데이터의 정합성과 중복 여부 등을 쉽게 판단할 수 있다.
User 3 : 정말 그런 것 같다. 현재 투입된 프로젝트에서 보험 관련 업무를 수행하는데 보험에 대해 전혀 모르는 상황임에도 모델의 잘못된 부분을 찾아낼 수 있었다. 속성이 186개에 이르는데, 처음엔 A3 종이에 꽉 차는 모델을 보면서 두렵기만 했는데 며칠을 째려보고 나니 정규화 되지 못한 것과 중복되는 속성들, 빠져야 하는 엔터티, 잘못된 릴레이션 같은 기본적인 수준의 에러 체크가 가능했다. 그때 머릿속으로 생각한 것은 바로 'what if' 였다.
교차 엔터티의 오류 발견
Expert : 일반적인 모델링에 대한 얘기가 너무 길어졌는데, 직접 모델링 했던 내용이나 이번에 공모전 준비한 모델 중에서 의아한 부분이나 궁금했던 사항이 있으면 얘기해보자. 결론을 내려줄 것이라고 단언하진 못해도, 어떤 문제점이 있는지 이럴 경우 어떻게 할 수 있는지에 대한 조언은 가능하다.
User 2 : 공모전의 문제 2 중 상담과 견적 부분에서 ‘한 건의 상담이 여러 건의 견적을 도출할 수 있고, 여러 건의 상담이 한 건의 견적으로 정리될 수 있다’는 측면에서 교차엔터티를 한번 생각해 봤다. <그림 2 참조> 그런데 이렇게 그리고 보니, 한 고객에 대한 여러 개의 상담이 견적으로 모아지는 것의 표현이 미약해서 고객과 견적도 연결하면 어떨까 생각했는데, 이게 가능한 것인지.
<그림 2>
Expert : 이 모델을 보고 어떤 업무 흐름이 떠오르나?
User : 글쎄, 별개의 상담을 모아서 하나의 견적으로 만들거나 혹은 견적은 여러 개인데 상담은 한 개일 경우를 표현한 것 같은 생각은 드는데, 일반적인 모델의 모습은 아닌 것 같다.
Expert : 그런 배경에 대한 설명 없이 모델 자체로 봤을 때, 가장 문제가 되는 것은 상담과 견적 간의 업무 디펜던시가 전혀 안 보인다는 점이다. 상담 후 견적으로 연결되는구나, 견적 후 상담으로 연결되는구나를 모두 생각할 수 있는 중복된 모델이다. 즉 ‘가’라는 고객이 상담 쪽으로, ‘나’라는 고객이 견적 쪽으로 프로세스가 진행된 후 견적상담에서 충돌할 가능성까지 있는 것이다. 그럼 상담이 여러 건 일어났는데 마지막에 견적을 받은 형태라면, 이 상담에 의해서 견적이 일어났다는 것을 남겨야 할 필요가 있느냐는 측면에서 다:다가 적합할지, 리쿼시브가 나을지 생각해보자.
User 3 : 리쿼시브로 표현하면 이전에 이런 상담이 있었네 라는 정도는 알 수 있을 것 같고, 다:다는 이전의 상담 내역을 모두 찾아야 하는 불편함이 있을 것 같다.
Expert : 이런 오류 때문에 일반적으로 교차 엔터티는 잘 사용하지 않는다. 마지막에 견적이 일어난 내용을 최종으로 하고 그 이전의 것을 취합해야 하는 모델은 이력관리를 하는 것이 더 효율적이라고 얘기할 수 있다. 이 업무 규칙처럼 특이한 상황에 대해 고려를 하다 보니, 눈에 쉽게 보일 수 있는 오류를 놓치게 된다. 그래서 모델링을 할 때는 일반적인 사항을 먼저 고려해서 모델을 그리고, 여기에 특이한 만약의 상황을 고려해 수정하는 방식으로 해야 한다.
양쪽 옵셔너리 일 때, 서브 타입을 사용하라고?
User 1 : 공모전 준비를 하면서 내용 중 고객과 상담과 제품 간의 관계에서 논란이 많았다. 상담시 제품을 제품으로 볼 것인지, 모델로 볼 것인지 부터 상담시 제품이 없을 경우 어떻게 해야 하는지 등 의견 충돌이 많았는데, 상담시 제품이 없을 경우 일단 상담을 하고 추후 제품으로 등록하는 형태로 결론을 냈다. 이런 모델이 잘 된 것인지 궁금하다.
<그림 3>
Expert : 일단 모델을 보면 상담과 제품 간의 관계가 옵셔너리이고, 상담시 제품이 없으면 상담 이후에 제품을 등록한 후 다시 상담 내용을 불러와서 연결을 해야 하도록 되어 있다. 프로세스 상 완전히 불가능한 것은 아니지만, 상담 내역 등록 이후 제품 쪽으로 데이터를 새로 입력하는 과정은 현실적이진 못하다.
Expert : 이 부분보다 더 문제가 되는 부분은 상담과 고객 부분인 것 같다. 이 모델로 봤을 땐 상담시 고객의 정보를 먼저 입력하고, 상담이 이뤄지도록 되어 있는데 통상 이렇게 무례한(!) 고객 상담이 이뤄지긴 힘들다.
<그림 4>
User 2 : 고객 정보가 확실히 파악 됐을 때, 그러니까 단순히 전화가 온 모든 것을 상담으로 등록하기보다 견적을 염두하고 구체적인 상담을 원하는 고객을 대상으로 한다고 판단했다. 그럴 경우엔 고객의 정보 입력이 어렵지 않다고 생각했는데.
Expert : 상담이 그렇게 이뤄진다고 생각하나? 마케팅 측면에서 생각할 때 상식적으로 잠재 고객이 더 중요하지, 이미 제품을 사려고 마음을 먹고 알아서 접촉해온 고객을 더 중요하게 판단하진 않을 것이다. 도대체 어떤 기업의 상담이 물건을 사려고 마음먹은 고객 위주로 이뤄지고, 또 상담도 들어가기 전에 고객 정보를 먼저 받는 형태로 이뤄질까? 이런 상식 차원의 판단은 어떤 모델에서든 반드시 적용이 되어야 한다. 상식적으로 이해되지 않는 모델이란 있을 수 없다.
User 3 : 그럼 이럴 경우엔 어떻게 표현을 해야 하나.
Expert : 어떻게 표현해야 할까. 일단 상담과 고객 간의 멘데이토리를 옵셔너리로 변경해서 탄력성을 가져가야 할 것이다. 그런데 양쪽 모두 옵셔너리가 됐을 때 문제가 생길 수 있다. 어떤 문제일까?
User 3 : null 가능성이 있지 않나?
Expert : null이 아니라, 양쪽 옵셔너리면 데이터 디펜던시가 없어져서 ‘당신 맘대로 하세요’가 될 소지가 있다. 이럴 경우엔 데이터 디펜던시를 확보하기 위해 서브 타입을 생성하는 것이 좋다. 고객 정보가 있는 즉 고객의 담당자가 등록된 상담 그리고 담당자가 등록 안 된(anonymous) 상담으로 나눠서 상담 내역을 저장하는 형태로 말이다. 이렇게 상담이 있는데, 담당자가 있는 상담이 있고, 없는 상담이 있다는 식으로 해 놓으면 유연한 모델이 된다.
User 4 : 서브타입은 어떨 때 사용하는 것인가? 주로 엔터티를 나누기 애매할 때 쓰는 경우가 많은데.
Expert : 실질적으로 서브 타입은 양족 옵셔너리일 때 한쪽을 멘데이토리를 만들어 의미를 명확하게 해주기 위해 그리고 말한 것처럼 엔터티 속성이 다를 때 활용한다. 모델러마다 틀리지만, 서브 타입을 생성하면 모델별로 추후 조인하기가 쉽고 물리적으로 디자인하기가 쉽기 때문에 이를 남용하는 경우들이 많다. 그런데 데이터 밸리데이션 측면에서 데이터 정합성과 무결성이 깨질 우려가 있기 때문에, 엔터티 속성 정의서를 구체적으로 잘 쓰는 것이 서브 타입 생성보다 바람직하다고 생각하는 입장이다.