태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

지난 글에서 모델링을 모델러가 하지 못하는 현실에 대해 썼습니다나름 전문 모델러로서 슬픈 현실이 아닐 수 없습니다. 하지만 달라질 거라 확신합니다.

 

이유는 여러 가지가 있는데요. 우선 10년 전과 비교해 지금의 환경이 낫다고 생각하기 때문입니다. 모델러를 찾는 데가 없진 않습니다. 숫자를 헤아리기 힘든 공공에서 필수인 EA 프로젝트에서도 모델러가 필요하고요. 좋아지고 있는 추세로 판단하면 앞으로도 좋아질 거 같습니다.

 

시스템의 기반 환경도 좋아졌다고 생각합니다. SI 산업이 불황이라고 하지만 시스템 없이는 기업이 존재할 수 없는 상황이라 낙관적이라고 생각합니다. 지나친 긍정일 수 있지만 지금이 시스템 선진국으로 넘어가는 과도기라는 생각이 듭니다.

 

게다가 DB도 소위 기초 체력이 튼튼해졌다고 생각하고요. 누구나 DB가 중요하다고 말하고 있습니다. 비록 엄한 비용 때문에 말과 행동이 다르긴 하지만, 어쨌든 과거에 비하면 DB에 대한 인식이 많이 바꿨습니다.

 

관계형 DB의 생명력도 의외로 끈질길 거라 생각합니다. 정규형 모델에 저장하지 않고는 데이터 품질을 보장할 방법이 없는 거 같습니다. 사실 획기적인 다른 DB가 나와도 설계는 해야 할 것입니다. 그리고 데이터 품질은 갈수록 중요해질 것입니다.

 

빅 데이터가 태풍처럼 거대한 바람을 일으켰지만, 그 저반에는 어쨌든 계정계 데이터가 자리하고 있습니다. 분석도 하지 못하고 크기만 한 영상 데이터나 음성 데이터를 앞세웠지만, 결국 수익을 창출하는 데이터는 양질의 텍스트 데이터가 될 것입니다. 빅 데이터의 환상에서 깨어나 기본으로 돌아갈 거라 생각합니다. 어쩌면 베리(Very) 빅 데이터가 나와 더 골치 아프게 만들 수도 있지만요.

 

모델링이 점점 활성화될 거라고 보는 진짜 이유는 따로 있습니다. DA의 등장입니다. 오늘 얘기 하고 싶은 건 DA(data architect)입니다.

 

현재 큰 시스템을 운영하는 곳은 DA가 있다고 생각합니다. 제가 거친 곳은 다 DA 역할을 하는 사람이 있었습니다. 차세대 개발을 한 곳이니 더 그럴 거라는 생각은 들지만, 왠만큼 큰 조직에는 DA가 있을 것입니다.

 

예전에는 DA가 모델러보다 없었습니다. 15년 전에는 못 들어봤고, 최소한 본 적은 없었으니까요. DA만 놓고 보면 세상이 바뀐 셈입니다.

 

DA의 역할은 다들 잘 아실 것입니다. 데이터와 관련된 일을 기획하거나 관리하는 사람입니다. 때론 데이터와 관련된 일을 다 직접 수행하기도 합니다. 그러고보니 예전에도 DA는 있었네요. 그 역할을 하는 DBA가 있으니까요. 그래도 지금은 꽤 체계적입니다. DA에 대한 역할은 기회가 되면 더 자세히 쓰겠습니다.

 

DA가 현재 가장 열심히 하는 분야는 표준화입니다. 표준화는 필수 과목이 됐습니다. 메이저 3사의 역할이 컸다고 생각합니다. 단순히 속성 표준화에 국한된 게 아니라 ERD 관리와도 연관되기 때문에 데이터 모델링 환경이 좋아진 것입니다. 모든 기업에 ERD가 관리된다면 모델러에게는 더 없이 좋은 환경이 될 것입니다.

 

DA 업무가 현재는 표준화에만 치중돼 있지만 표준화가 완료되면 DA가 모델링에도 관심을 가질 것입니다. 10년 전에는 활성화되지 않았던 표준화가 기본이 됐듯이 조만간 정규화도 기본이 될 것이라 생각합니다. DA의 궁극적인 역할은 데이터 품질을 높이는 것이기 때문에 모델에 관심을 가질 수밖에 없습니다. 아직은 엄두가 안 나지만요.

 

DA가 활성화된 원인에는 DAP 자격증도 큰 몫을 했습니다. 그렇게 보면, DB 분야에서 엔코아의 업적을 무시할 수 없습니다. 선구자 역할을 하신 분이 있어 여기까지 왔는데, DB인들이 더욱 투철한 직업관과 사명감을 가지고 분발했으면 좋겠습니다.

 

이 글을 읽으시는 분들은 최소한 DA에 관심이 있는 분일 거 같습니다. 저는 모델러의 전망도 밝다고 생각하지만, DA의 전망은 매우 밝다고 생각합니다. 많은 분들이 도전했으면 좋겠습니다. 쉽진 않겠지만 그리 어렵지도 않습니다. 노력이 문제죠. 결국은 또 노오력이네요.

 

대기업에서 개발 오래한 분들도 DA로의 전향에 대한 관심이 높습니다. 연령 제한도 없는 편이고 다른 인력으로 대체하기 쉽지 않죠. 조율을 해야 하기 때문에 여성에게도 좋은 직업이라 생각합니다. 실제로 현장에서 많이 활동하고 있죠. 준비 기간이 있다면 전업이 아주 어려운 것도 아닙니다.

 

모델링은 DA 업무 중에서 더 특화된 분야입니다. DA가 모델링을 모르면 안 되죠. DAP 시험도 그걸 허용치 않습니다. 하지만 DA가 직접 모델링은 못할 수도 있습니다. 분야가 넓기 때문에 특화된 일을 못하는 여건일 뿐입니다.

 

DA가 직접 모델링을 할 수 있으면 더 좋습니다. 표준화가 정착되면 다음 차례는 모델이라고 생각합니다. 실제로 모델을 관리하는 것이 DA의 주된 역할입니다. DA를 목표로 하시더라도 모델링을 직접 수행할 수 있을 정도의 스킬도 목표로 하시길 바랍니다.

 

모두 파이팅하세요.

 

'데이터 Story > 데이터 상념(想念)' 카테고리의 다른 글

모델러의 상처  (0) 2017.09.25
[worst practice 1] 잘못 설계된 모델  (1) 2017.09.24
DA 전망  (0) 2017.09.23
모델링을 수행하는 주체는?  (0) 2017.09.17
업무를 모르면 모델링을 할 수 있을까요?  (0) 2017.09.02
액셀과 사례 데이터  (1) 2017.08.26
블로그 이미지

블루퍼필

댓글을 달아 주세요

실무에서 모델링을 수행하는 주체는 누구일까요? 당연한 질문인데 답변하기 망설여지는 게 안타깝습니다.

 

개발 프로젝트에서 데이터 모델링을 개발자가 수행하는 경우가 많습니다. 운영 단계는 제외하고 개발 단계만 따져도 개발자가 모델을 설계하는 경우가 60~70%는 되지 않을까 싶습니다.

 

개발 프로젝트에서 전문 모델러가 모델링을 수행한 지는 얼마 되지 않을 거 같습니다. 아마 15년 전부터 일부 대형 프로젝트에서 전문 모델러가 모델링을 수행하지 않았나 싶습니다.

 

그렇지 않으면 개발자 중에 모델링을 잘 하는 사람이 모델링을 수행하는 경우가 대부분이었습니다. 저도 15년 전에 그렇게 모델링을 했습니다. 개발도 했지만 프로그래밍 언어보다 MS 액세스를 먼저 다루었고, 정규화를 알고 있었기 때문이었죠.

 

하지만 그때도 일반적이지 않았을 뿐이지 전문 모델러는 있었을 것이고, 전문 모델러가 모델링을 수행하고 있었을 것입니다. EA 아키텍처가 활성화돼서 DA를 전문 영역으로 인식하게 됐고, 몇몇 모델링 회사의 노력이 결과로 나타난 것일테지요.

 

그럼에도 아직까지 개발자가 모델링을 수행하는 개발 프로젝트가 많고, 규모가 큰 프로젝트도 그렇게 하는 경우가 많습니다. 개발자가 모델링을 수행하는 경우 그 모델을 검토하는 소수의 모델러가 존재하기도 하는데, 최소한의 안전 장치만 두는 것입니다.

 

사업에 대한 의사결정자가 아닌 입장에서 이유를 정확히 알 수는 없지만, 몇 가지 추측해 볼 수 있습니다. 자주 듣는 얘기지만 모델러는 업무를 모르기 때문에 모델링을 수행할 수 없다는 주장이 이유가 될 듯합니다.

 

이는 지난 글에서 자세히 설명했는데요. 업무 설명을 누구도 해주지 않는다면 모델링을 할 수 없지만 그게 아니라면 기우일 뿐입니다. 전문 모델러는 업무 설명을 듣고, 데이터 종속성을 따져서 설계할 뿐입니다. 통합과 확장 가능성까지 감안해서 설계하기 때문에 모델의 품질이 좋습니다.

 

또 다른 이유로, 전문 모델러가 부족하다는 점이 떠오릅니다. 큰 프로젝트는 6~7명의 전문 모델러가 필요한데, 전문 모델러를 구하기 쉽지 않습니다. 그래도 이 문제 때문에 개발자가 모델링을 수행하도록 하지는 않을 것입니다.

 

비용 문제가 현실적인 문제일 것입니다. 하지만 그 비용이 전체 비용에서 차지하는 부분은 매우 적고, 개발자가 모델링을 수행해도 그 만큼의 추가 비용은 발생합니다. 모델이 변경되거나 잘못 설계됐을 때의 시행착오나 유지보수 비용까지 고려하면 전문 모델러가 수행했을 때의 비용이 오히려 적게 드는 것이라 확신합니다. 시스템의 토대가 되는 데이터 모델은 당장의 조그만 비용 차이보다는 향후의 효율성까지 고려해야 합니다.

 

개발자가 모델링을 수행할 때의 가장 큰 문제점은 ASIS 모델과 유사하다는 것입니다. 확신이 없기 때문에 모델 구조를 변경하기는 힘듭니다. 겁이 날 수밖에 없습니다. 모델 구조를 바꾸는 것은 전문 모델러에게도 힘든 작업이니까요. 개발자가 모델링을 하면 ASIS와 유사해질 수밖에 없습니다.

 

이런 이유로 개발자가 모델링을 하면 통합 모델이 되지 않습니다. 통합 모델은 데이터를 효과적으로 관리하는 것 외에 중복 개발을 방지하기 위한 목적도 있죠. 통합 모델은 전문 모델러도 구축하기 힘든 모델이니 개발자가 구축하기는 매우 힘들 것입니다.

 

결국 개발자가 수행한 모델은 품질이 떨어지는 모델이 될 가능성이 큽니다. 개발자는 해당 업무를 잘 알고 있고, 개발 언어와 개발 방법론을 잘 알고 있는 전문가입니다. 테이블을 사용하는 데는 익숙하지만 테이블을 설계하는 능력은 부족할 수밖에 없습니다. 전문 모델러가 설계한 모델과 품질 차이가 많이 날 수밖에 없습니다.

 

그럼 어떻게 해야 할까요? 당연히 전문 모델러가 모델링을 수행해야 합니다. 그래야 통합 모델이 되고, ASIS 모델에서 정제될 부분이 정제된 모델이 됩니다. 당장의 비용은 조금 더 소비될 수는 있지만, 모델이 잘 설계되면 개발을 빨리 하는 데도 도움이 되며, 개발 중에 모델이 변경되는 것도 최소화되고 오류가 줄 수 있습니다. 유지보수 효율성까지 고려한다면 비용은 오히려 저렴할 것입니다.

 

만약 어쩔 수 없이 개발자가 모델링을 수행한다면, 모델링 가이드와 모델 검토를 할 수 있는 전문 모델러가 반드시 존재해야 합니다. 개발자는 어차피 개발 영역이 좁기 때문에 통합 모델이나 일관된 모델을 설계할 수 없습니다. 전문 모델러가 전사 차원에서 모델의 설계 방향성과 통합 여부 등을 판단해야 합니다.

 

또한 논리 모델의 토대가 되는 개념 모델은 전문 모델러가 수행하는 것이 바람직합니다. 이 개념 모델은 중요 엔터티로 구성된 토대가 되는 모델(ERD)이지 개념도가 아닙니다. 개발자가 논리 모델을 설계할 때 사용되는 실제 모델이어야 합니다. 개념 모델은 논리 모델을 수행할 수 있는 토대가 돼야 의미가 있습니다. 개념 모델이 개념도에 불과해서 논리 모델로 이어지지 않는 모델이라면 개념 모델 단계는 필요 없습니다.

 

그리고 전문 모델러의 권한을 강화해야 합니다. 확실하게 잘못된 부분에 대한 변경이나 다른 영역과의 통합 의견 등이 반영될 수 있어야 합니다. 모델 설계 오너십이 없다고, 모델러의 의견이 무시되는 형식이 되면 안 되는 것이죠. 이를 보완할 수 있는 게, 토대인 개념 모델을 전문 모델러가 설계하고 개발자가 이어서 논리 모델을 설계하는 것입니다.

 

물론 앞서 밝힌 대로 가장 좋은 방법은 전문 모델러에게 물리 모델까지 전적으로 맡기는 것입니다. 당연한 원칙입니다. 처방은 의사가 하고 제조는 약사가 하는 식으로 전문 분야의 일을 전문가가 해야 정상적인 것이죠.

 

저는 직접 모델링한 경험이 대부분인데요. 문제가 없진 않지만 개발자가 모델을 설계하는 것에 비할 바가 아니라고 생각합니다. 통합 모델과 모델 구조 설계, 표준화, 이슈 처리 등 어떤 부분에서도 모델러가 설계한 모델이 월등합니다. 개발자는 개발 전문가이지 모델을 설계하는 기술은 부족할 수밖에 없습니다.

 

간혹 모델러보다 모델 설계를 잘 할 수 있는 개발자를 보기도 합니다. 모델러로의 전향을 권유한 적도 여러 번 있습니다. 이런 개발자는 데이터에 관심을 가지고 오랫동안 공부한 사람이라 모델러라 해도 손색이 없습니다. 하지만 매우 드물고, 경험의 부족은 어쩔 수 없이 티가 납니다.

 

또한 프로젝트에서 이런 모델러 같은 개발자를 선별해서 배치하지는 않습니다. 개발을 잘하는 순수한 전문 개발자를 배치하죠. 역할에 맡게 배치하는 게 아니라는 것입니다. 이 때문에 자신 없는 모델 설게를 개발자에게 맡기는 것은 스트레스를 가중시키는 원인만 됩니다.

 

우선 수행사의 생각이 바뀌었으면 좋겠습니다. 어차피 모델링의 중요성을 피할 수 없다면, 모델 설계를 제대로 하겠다는 결정을 했으면 좋겠습니다. 수행사가 아니라면 고객사라도 그런 결정을 했으면 좋겠습니다.

 

각자의 분야에서 전문가가 제 역할을 해야 부작용이 줄 것입니다. 비전문가에게 전문적인 일을 맡기는 것은 사고로 이어질 확률도 커지며, 그 자체로 바람직하지 않습니다. 현재 우리 사회의 그릇된 모습이기도 합니다. 다음 세대에 물려줄 것은 아닙니다.

 

아마 개발자가 데이터 모델을 설계하지 않고 전문 모델러가 데이터 모델을 설계하는 현상은 가까운 시일 내에 오지 않을 수도 있습니다. 그래도 관련 전문가들이 끊임없이 주장하고, 그런 분위기가 되도록 노력해야 할 것입니다.

 

그리고 그런 시대가 올 것을 준비해야 합니다. DA를 준비하는 사람이 많아져서 때가 왔을 때 제대로 했으면 좋겠습니다. 모델러들도 더욱 노력했으면 좋겠고요. 모델링을 이끌었던 선구자적인 회사들도 초심으로 돌아가서, 힘들어도 다시 노력했으면 좋겠습니다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

최근 컨텐츠에 대한 압박을 받고 있습니다.

카페 글도 그렇지만, 디비가이드넷에 컬럼을 연재하고 있어서 고민이 많습니다.

그래서 다양한 생각을 하면서 글로 정리하고 있는데요.

개인적인 생각일지라도 도움 받을 분이 있을 수 있어 카페에 하나씩 올릴 생각입니다.

혹시 소재를 알려주시면 도움이 될 거 같습니다.

 

업무를 모르면 모델링을 할 수 있을까요?

정답은 아니오입니다.

 

업무에 의해서 데이터가 생기기 때문입니다.

데이터는 업무에 종속돼 있죠.

업무에서 필요한 데이터를 설계하는 게 모델링입니다.

 

그리고 결정적으로 데이터 사이의 종속성이 업무 요건에 의해서 결정됩니다.

다른 말로 표현하면, 정규화가 업무 요건을 기준으로 수행된다는 점입니다.

 

업무를 수행하려면 이런저런 데이터가 필요하고, 이런저런 데이터를 제대로 사용하기 위해 엔터티로 분리하는 기준이 업무 요건입니다.

 

업무를 모르고서는 제대로 모델링을 할 수 없습니다.

 

그럼 업무를 모르는 모델러는 해당 프로젝트에서 모델링을 할 수 있을까요?

짐작하셨겠지만, 이번에는 입니다.

보수적으로 봐도 못할지도입니다.

 

업무를 모르면 모델링을 할 수 없다고 했는데, 어떻게 업무를 모르는 모델러가 프로젝트에서 모델링을 할 수 있을까요?

업무를 알아가면서 모델링하면 됩니다.

정확히 말하면 데이터를 알아가면서 모델링하면 되는 것입니다.

 

이 의견에 동의하지 않는 분들이 많을 거라 생각합니다.

특히 기업의 개발 책임자나 데이터 담당자가 동의하지 못할 거 같습니다.

그렇다보니 모델러의 진입장벽이 더욱 높아졌습니다.

모델러로서의 경력은 기본이고, 해당 업무에 대한 모델링 경력까지 있어야 되니까요.

 

개인적으로 매우 안타깝게 생각합니다.

두 가지 이유가 있습니다.

 

기본적으로 업무를 많이 아는 것보다 모델링 자체를 잘 해야 좋은 모델을 설계할 수 있기 때문입니다.

자신 있게 말할 수 있습니다.

다만, 두 가지 조건이 있습니다.

모델링 이론을 정말 잘 알아야 하고, 모델링을 수행하면서 업무를 열심히 파악해야 합니다.

 

후자는 어떻게 할 수 있을까요?

대개는 ASIS 엔터티를 분석하면서 업무를 파악할 수 있습니다.

필수 단계는 아니지만 프로젝트 초반에 업무 설명회 단계가 있을 수도 있고요.

 

모델러 스스로 노력해야 할 부분도 있습니다.

해당 업무에서 사용하는 용어를 익혀야 합니다.

인터넷 검색이나 메타시스템 등의 도움으로 해결할 수 있습니다.

업무 매뉴얼도 열심히 익혀야 되고, 홈페이지 등에서도 업무를 익힐 수 있습니다.

ISP 산출물이나 개발 산출물을 통해서도 익힐 수 있고요.

 

모델러는 복잡한 프로세스나 로직을 알아야 하는 게 아니기 때문에 개발자보다 업무 지식이 깊지 않습니다.

어느 정도의 노력으로 모델링에 필요한 업무는 습득이 가능합니다.

어쨌든 업무 지식이 없는 상태라면 초반에 많은 노력이 필요합니다.

 

업무를 아는 모델러라고 크게 다르지 않습니다.

ASIS 엔터티를 분석해야 하고, 매뉴얼과 개발 산출물 열심히 봐야 됩니다.

조금 덜 부담스럽고, 시간을 조금 덜 투자할 수는 있지만 거의 비슷합니다.

 

저는 증권 업무를 여러 차례 모델링했지만, 횟수가 거듭될수록 확연히 쉬워지지 않았습니다.

통합의 범위나 데이터 사용 방법, 개발 방법이나 개발자의 성향, 특히 키맨의 성향에 따라 모델이 많이 다릅니다.

데이터 상단의 업무가 유사할 뿐 ERD 자체가 많이 다르고, 당연히 업무도 조금씩 다릅니다.

결국 미리 업무를 알든 모르든 ASIS 엔터티 분석이 필수가 되고, 이 단계가 시간이 가장 많이 소요됩니다.

 

업무를 모르는 상태에서 모델링하는 데 지장이 없지만 예외가 있습니다.

 

모델링 리더는 업무를 전반적으로 아는 게 좋습니다.

전반적인 업무를 모르면 초반에 주제영역을 검토하고, 규모를 산정하고 계획을 세우고 업무 분장을 하는 데 지장이 있습니다.

개발 영역이나 고객 쪽 리더와의 의사소통에도 지장이 있고요.

물론 이것도 금방 익숙해지지만 불편하기 때문에 업무를 전반적으로 아는 모델러가 모델링 리더가 되는 게 좋습니다.

 

그리고 원채 어려운 업무가 있습니다.

저는 선물옵션 업무가 어려웠고, 그때 업무를 잘 알아야 제대로 모델링할 수 있겠다라는 생각을 처음으로 했습니다.

어쨌든 15년 동안 한 번 느낀 거라서 일반적이지 않다고 봐야 될 거 같습니다.

일상적이지 않은 특수 업무라면, 그 시스템을 개발한 개발자가 모델링 이론을 익혀서 모델링하는 게 좋을 수 있습니다.

 

만약 업무는 매우 잘 아는데 모델링 기술이 없으면 어떤 현상이 발생할까요?

단언할 수 없지만, 모델이 ASIS와 유사해질 가능성이 높습니다.

모델링 기술이 없으면 데이터 통합이나 분리, 정규화 등을 제대로 할 수 없습니다.

업무를 잘 알면 오히려 데이터를 이해하는 데 방해가 될 수 있습니다.

 

여러가지 이유에서 모델링 기술이 뛰어나면 업무 경험과 무관하게 좋은 모델을 설계할 수 있습니다.

 

그럼 모델링 기술이 뛰어나고 업무도 잘 아는 모델러를 찾으면 좋을 거라고 생각할 수 있습니다.

하지만 그런 모델러는 흔치 않을 거 같습니다.

전문 모델러는 한 업무를 지속적으로 모델링하는 것보다는 다양한 업무를 모델링합니다.

전문 모델러 자체가 부족한데 업무에 특화된 전문 모델러가 흔할 수 없습니다.

 

저는 증권 업무만 다섯 번 모델링 했는데요.

한 업무를 많이 한 편이지만 매번 영역이 달랐고, 개발자만큼 상세하게 업무를 파악하지 않기 때문에 업무에 대한 자신감은 없습니다.

처음 접하게 되는 업무에 대한 강박감이 없을 뿐입니다.

 

개인적으로는 경험하지 못한 업무를 모델링하는 것을 선호합니다.

다양한 업무를 알면 실생활에도 도움이 되지만, 스스로 시험도 해보고 싶기 때문입니다.

부담감 같은 게 싫은 모델러라면 설계해 본 업무를 선택하는 게 좋습니다.

 

찾기 힘든, 업무도 잘 알고 모델링 경험도 많은 모델러를 찾다가 오히려 모델링 기술은 평범하고 업무만 잘 아는 모델러를 만날 수 있습니다.

 

두 번째 안타까운 점이 바로 이부분입니다.

 

기업 입장에서는 당연히 업무도 잘 알고 모델링 기술도 뛰어난 모델러를 원하겠죠.

하지만 모델링 기술에 대해서는 평가할 수 없습니다.

그러다보니 이력서에서 수행했던 회사명과 역할만을 보고 판단하게 되는데요.

전문 모델러가 아니라 모델링 할 줄 아는 개발자를 선택할 가능성이 높습니다.

 

진입장벽이 높을 수는 있지만, 의외로 활동하기 수월한 분야가 모델링입니다.

정규화나 엔터티, 관계 등은 왠만하면 대략은 알기 때문에 업무만 잘 알면 모델러로 활동하기 쉬워집니다.

기업에서 이렇게 선택한 측면이 있습니다.

 

검증된 모델러인데 해당 업무 경험이 없어서 프로젝트에 참여하지 못하는 경우를 많이 봤습니다.

충분히 잘 할 수 있기 때문에 참여하지 못하는 모델러도 안타깝지만, 선택하지 않은 기업도 안타까운 건 마찬가지입니다.

업무 경험에 가중치를 둔다면 업무 전문가를 선택할 가능성이 높은데, 전문 모델러가 설계한 모델과 차이가 많이 날 거라 확신합니다.

 

업무를 몰라도, 업무를 파악하면서 좋은 모델을 만들 수 있습니다.

개발자나 IT 현업 등 업무 전문가는 프로젝트에 많지만 데이터 전문가는 드물기 때문에 더욱 전문 모델러가 프로젝트에 필요합니다.

모델링을 조금 아는 업무 전문가가 모델링을 하는 건 바람직하지 않습니다.

 

초보 모델러일수록 업무 때문에 스트레스를 받는데, 자신감을 가지고 임하셨으면 좋겠습니다.

자신감을 가지고 모델링 이론에 정통한 진짜 모델러를 목표로 정진했으면 좋겠습니다.



'데이터 Story > 데이터 상념(想念)' 카테고리의 다른 글

DA 전망  (0) 2017.09.23
모델링을 수행하는 주체는?  (0) 2017.09.17
업무를 모르면 모델링을 할 수 있을까요?  (0) 2017.09.02
액셀과 사례 데이터  (1) 2017.08.26
모델링과 바둑 이야기  (0) 2017.08.12
개념 모델에 대한 논쟁  (0) 2017.07.18
블로그 이미지

블루퍼필

댓글을 달아 주세요

저는 바둑을 무척 좋아합니다. 대학 때 동호회가 기우회(棋友會)였어요. 동호회 얘기할 때마다 반복하는 해명인데, 비가 오라고 비는 곳이 아닙니다. 학교에 그런 동호회가 있을 리 없죠. 바둑 동호회입니다. 잠깐 옆으로 새면, 기우(祈雨)를 하면 반드시 비가 오는 부족이 있다고 합니다. 비결은, 비가 올 때까지 빈다고 합니다. 간단하죠.

 

제가 기우회에서 4급 정도를 두었는데요. 방황을 하던 때라서 바둑보다는 농구를 더 많이 한 탓에 바둑 실력이 좋지 않았습니다. 약간 후회가 됩니다. 선배들처럼 1~2급까지 갔으면 좋았을텐데요. 참고로 아마추어는 단()이 없고 최고가 1()입니다. 천차만별이지만 아마추어 1급을 아마추어 단으로 치면 3~6단 정도 되는 거 같아요.

 

이 글은 모델링에 대한 글이지만 잠깐 바둑 얘기를 해야겠습니다. 처음 동호회 방에 갔을 때 한 선배가 기력 테스트를 한다고 앉혔습니다. 몇 마디 물어보더니 9점을 깔라고 하는 겁니다. 주변 사람한테 별로 저본 적이 없어서 깜짝 놀랐습니다. 저도 상대한테 9점을 깔라고 하는 경우가 많았던 때라 더욱 그랬죠.

 

결과는 예상하시겠죠. 만방으로 졌습니다. 바둑을 좀 두는 상태라서 9점을 깔아주고 어떻게 둘런지 선배를 걱정했는데요. 제 생각은 완전 오판이었습니다. 신비한 경험이었어요. 실력차가 이렇게까지 심하게 날 수 있구나를 실감했죠. 그당시 그 선배는 3~4급이었던 거 같고, 그 선배가 졸업할 때는 1급이었던 거 같습니다.

 

아마추어 1급 중에서 고수가 프로와 둘 때는 보통 4~6점을 깐다고 합니다. 제가 4급이라고 하면 프로와 두려면 13점을 깔아야 하는데요. 사실 더 깐다면 어디다 깔아야 하는지 몰라서 13점입니다. 이미 13점이면 상대가 둘 곳이 없는 정도의 상태인데, 실전 결과는 제가 만방으로 지는 거겠죠.

 

프로 1단과 프로 9단은 서로 깔고 두지 않습니다. 그래서 실력이 동급일 거 같은데, 미세한 차이지만 결과는 상당히 큽니다. 이창고가 전성기일 때는 프로기사라도 이창호와 둬서 이길 확률이 10% 이내니까 차이가 많이 나는 것입니다.

 

바둑을 잘 모르시는 분들은 프로 바둑기사를 그냥 천재라고 생각하면 되는데요. 일례로 프로기사끼리는 흰색의 돌로만 바둑을 둘 수 있습니다. 내가 둔 수와 상대가 둔 수가 머릿 속에 있기 때문에 흰색 돌만 놓여있는 바둑판은 형식일 뿐이죠. 바둑을 모르시면 밥만 먹고 바둑을 두니 그 정도는 돼야 한다고 생각하실 수 있는데, 많은 돌이 얽혀있고 집 수를 계산하면서 매 수를 둔다는 걸 고려하면 엄청난 일입니다. 대개 한 수는 1분 내에 둬야 합니다.

 

바둑기사는 신()의 경지에 있다고 할 수 있습니다. 성경책을 몽땅 외운 신학생이나 지식의 깊이를 가늠할 수 없는 사람도 비할 바가 못 되는 거 같습니다.

 

바둑 얘기가 길어졌네요. 바둑 얘기를 하는 이유는 모델링과 매우 유사하기 때문입니다. 모델러 중에 바둑을 좋아하시는 분들은 공감하실 거에요.

 

우선 ERWin 툴에서 엔터티를 그리는 흰 판이 바둑판과 매우 흡사합니다. 줌으로 조절해서 전체를 보면 바둑판과 같습니다. R9 버전의 경우 의미가 없지만, R7 버전의 경우 저는 왼쪽 최상단 위치에서 엔터티를 설계하기 시작합니다. 가장 중요한 엔터티를 설계합니다. 실체 엔터티가 되겠죠. 바둑은 두는 사람 기준으로 오늘쪽 상단 귀퉁이에서 시작합니다.

 

바둑은 정석(定石)을 기반으로 두어집니다. 바둑에서 정석을 무시하고 두는 프로기사는 없을 것입니다. 간혹 한 수씩 비틀기는 하지만, 상대를 흔들기 위한 응용일 뿐이지 근저에는 정석이 있습니다. 간혹 정석대로 잘 두지 않는 프로기사가 있는데, 제 기억에 요다라는 일본 기사가 창의적인 바둑을 두었던 거 같아요. 외모와도 어울려서 나름 멋있었지만, 성적은 이창호 등에 비할 바가 못되었죠.

 

바둑은 정석을 모르면 제대로 두기 어렵습니다. 오랜 실전 역사가 쌓여서 생긴 정석은 무시할 대상이 아닌 것이죠. 모델링의 정석은 정규화를 기반으로 한 모델링 이론입니다. 1정규화, 2정규화 등의 정규화와 엔터티관계통합, 이력 설계 방법 등의 이론이 바둑에서의 정석에 해당합니다. 때로는 기계적으로 적용되기도 하는 정석과 같은 이론을 모르고서는 모델을 제대로 설계하기 어렵습니다.

 

네 개의 귀퉁이에서 정석을 기반으로 해서 두는 것을 초반 포석 단계라고 합니다. 모델링의 개념 모델 단계와 동일합니다. 첫수를 둘 때의 느낌이 첫 엔터티를 그릴 때의 느낌과 유사합니다. 판이 어떻게 짜일지를 기대하면서 첫수를 두죠. 최선을 다해 한 수씩 두면서 바둑의 포석이 정해지듯이 중요 엔터티를 하나씩 설계하면서 모델의 구조가 정해집니다. 초반 정석을 잘못 선택하거나 삐끗하면 판 전체가 엉망이 되듯이 처음에 핵심적인 엔터티를 제대로 설계하지 못하면 모델링이 전반적으로 힘들어진다.

 

초반 포석이 상당히 중요하지만, 당연히 중반이나 끝내기에서 승패가 갈리기도 합니다. 구조를 잡는 개념 모델이 상당히 중요하지만, 이후 단계에서 데이터 정합성이나 성능 등의 문제를 간과하면 모델에 심각한 하자가 생기는 것과 비슷합니다.

 

초반 포석 단계가 끝나면 중반전으로 넘어가면서 상대 집을 공격하기도 하고 내 집을 지키기도 하죠. 그러면서 집의 윤곽이 뚜렷해집니다. 핵심 엔터티의 구조를 설계한 후에 하위 엔터티로 확장해가면서 상세 논리 모델로 나아가는 것과 유사합니다.

 

바둑은 상대가 있는데, 모델링은 상대가 있을까요? 바둑 둘 때 내가 한 수를 두는 것은 상대에게 어떻게 둘래?‘라며 물어보는 것입니다. 모델링은 설계를 하기 전에 물어봐야 할 수 있습니다. 설계한 후에도 어떻게 사용하는지 설명하고 제대로 사용할 수 있는지 물어봐야 하고요.

 

정석이나 포석, 행마, 끝내기 등의 중요한 요소를 열심히 공부해도 프로 바둑기사가 되기는 하늘의 별따기와도 같습니다. 사실 모델러가 되는 것은 쉽습니다. 정규화나 통합, 엔터티, 관계 등의 이론도 쉽게 익힐 수 있지만, 문제는 직접 모델링을 하기가 쉽지 않다는 것입니다.

 

저는 바둑 중계를 볼 때 프로기사가 둔 수를 명확하게 이해할 수 있습니다. 방송 해설을 들으면 더욱 그렇지요. 상식적이고 자연스러운 위치여서 그자리에 둘 수밖에 없다고도 생각합니다. 하지만 실제로 저에게 두라고 하면 그 자리에 못 둔다는 것을 압니다.

 

어쩌다 프로처럼 멋진 수를 둘 수 있지만 항상 그렇게 두지는 못하죠. 모델링도 마찬가지로 전문 모델러가 설계한 모델을 보거나 설명을 들으면 이해가 되고 그런 구조가 맞는 것 같습니다. 하지만 이론만 아는 상태에서 실제로 그렇게 설계하는 게 쉽지 않습니다.

 

바둑에서 수 읽기가 중요하듯이 모델링을 수행하면서 데이터가 생성되는 것을 읽어야 합니다. 머릿속에서 사례 데이터가 생겼다 없어지고, 관계에 따라 데이터가 움직이기도 합니다. 바둑을 둘 때 머리속으로 집을 계산하듯이 머리속에서 조인(Join)한 결과를 보기도 합니다. 바둑기사가 한 수를 둘 때마다 반집의 집도 계산해 보듯이 모델링을 하면서 사례 데이터를 만들어 보는 것이 좋습니다.

 

정석을 꿰고 있는 것은 기본이고 창의적으로 응용할 수 있어야 하며, 반집을 소중하게 여길 정도로 최선을 다하고, 자신만의 철학을 가지고 바둑을 일관되게 두면 정상의 프로기사가 될 수 있다고 생각합니다.

 

이론을 꿔고 있고, 간혹 창의적으로 응용할 수 있으며, 속성 하나에도 최선을 다해 설계한다면 최고의 모델러가 될 수 있습니다. 모델러의 철학은 단순하다고 생각합니다. RDB의 존재 이유인 데이터 무결성을 지키는 것이고, 좋은 모델을 설계하는 데 집중하는 것입니다.

 

이미 경지에 올랐지만 정석을 공부하며, 끊임 없이 묘수를 연구하는 프로기사처럼 모든 모델러가 기본을 중시하고 더 좋은 모델을 연구하는 프로 모델러를 목료로 했으면 좋겠습니다. 모델러가 됐다고 그만인 게 아니라 그때부터 진정으로 시작이 됐으면 좋겠습니다. 저 역시 좋은 시스템을 만들어 국가 경쟁력을 높이는 데 조금이라도 이바지할 수 있도록 노력하겠습니다.

 

마지막으로 유명한 사진 한 장 첨부했습니다. 휠체어를 탄 사람은 조치훈 9단입니다. 대국 10일 전에 전치 25주의 교통사고를 당했지만 머리와 오른손이 문제가 없다면서 대국을 강행했죠. "목숨을 걸고 둔다"는 평소의 인생관을 그대로 보여주는 장면입니다.

 


 

PS. 바둑하면 떠오르는 갑갑한 현실도 있어요. 제가 쓴 모델링 노트 책에 기계가 사람을 이길 수 없다고 확신하는 내용이 있습니다. 알파고에 대해 할말은 많지만 어쨌든 책은 수정해야 할 판입니다.

 

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

“그 모델은 내가 모델링한 게 아니야!

 

제가 가끔 넋두리로 하는 말입니다.

 

누구나 다 제가 모델링한 것으로 알고 있는 A회사의 B영역 모델을 제가 모델링한 게 아니라고 말하면 어리둥절해합니다.

 

오늘은 ‘모델러의 주장(主張)’에 대한 얘기를 하려고 넋두리에 대한 일화를 꺼냈습니다. 본격적인 넋두리는 다음 기회에 하겠습니다. ㅎㅎ

 

저는 모델링을 하면 보통 제 주장의 70~80%를 관철하는 거 같습니다. 거의 100% 맞을 거 같은 사안 중에서요. 나머지 20~30%는 안타깝게도 상대방의 의견을 따릅니다.

 

위 문장은 많은 내용을 암시하고 있습니다. 어디서부터 설명해야 할지 모를 정도로 포괄적인 내용을요.

 

많은 암시 중에서 이 글에서는 '내가 생각하는 모델이 최선이 아닐 수 있다'는 것을 말하려고 합니다.

 

모델은 하나의 방향만 있는 것은 아닙니다. 모델로만 보면 내 주장이 80, 상대방 주장이 70점일 수 있지만 종합적으로 판단했을 때 상대방의 주장이 더 나을 수 있습니다. 내가 틀릴 수 있으므로 상대방의 의견도 존중해야 합니다.

 

더욱이 모델은 검증하기 힘들기 때문에 모델러가 자기 주장만 하면 독선적인 사람이 될 수 있습니다.

 

관계(엔터티간 관계 아님)와 커뮤니케이션은 언제나 중요합니다. 이게 깨지면 상대방이 신뢰하지 않습니다.

 

어떤 일이든 중요한 것은 사람과 어떻게 커뮤니케이션 하느냐입니다. 원칙만으로는 효과적인 커뮤니케이션을 할 수 없습니다.

 

먼저 경청해서 듣고, 설득하고, 설득이 안 되면 양보할 줄 알아야 모델링을 잘 수행할 수 있습니다. 내가 알고 있는 것이 반드시 옳다라고 주장하는 것은 다른 것과 마찬가지로 모델링을 수행할 때도 바람직하지 않은 태도입니다.

 

상대방을 존중하면서 실력을 키운다면, 모델러의 의견이 존중받고 결과적으로 좋은 모델을 구축할 수 있습니다.

 

실력은 있고, 맞는 말만 하지만 상대를 배려하지 않으면 효과적인 커뮤니케이션을 하기 어렵습니다.

 

경청하고 상대를 배려하는 것은 모델러가 갖추어야 할 중요한 덕목입니다(사실 모든 사람이 갖추어야 하죠).


블로그 이미지

블루퍼필

댓글을 달아 주세요

요구 사항은 프로젝트의 근간이 되는 대단히 중요한 요소입니다. 그리고 모델링과 밀접하게 연관돼 있죠(요구 사항은 함수 종속과 밀접하게 연관돼 있습니다).

 

프로젝트는 보통 아래와 같이 진행됩니다.



 

① 단계에서 개념 모델 또는 초기 논리 모델이 나오고요. ② 단계에서 물리 모델이 나옵니다. 딱 떨어지진 않지만요

 

요구 사항은 ①, ② 단계에서 대부분 도출돼야 하는데요. 실제로 ④ 단계에서 폭주합니다. 심리인 거 같아요.  ㅎㅎ

홈쇼핑 마감 전에 주문이 폭주하는 거 같이…

 

④ 단계에서 요구 사항이 폭주하는 원인이 있습니다.

 

요구 사항은 일정 부분 도출하는 것인데요. 요구 사항을 도출할 수 있는 분석·설계자가 드문 게 현실입니다. 또한 분석·설계자가 도출하는 게 한계가 있습니다.

 

요구 사항은 근본적으로 사용자(User)에게서 나옵니다. 사용자가 업무를 어떻게 하겠다는 것을 요구하는 것이니까요.

 

, ② 단계에서도 많은 요구 사항이 제시하지만 많은 부분 현행 업무와 유사하고요. 본격적으로는 ④ 단계에서 개발 화면을 보고 제시합니다. 사용자 입장에서도 부실한 문서만 보고 판단하기가 만만치 않습니다.

 

그래서 화면이 개발되고 버튼을 클릭하면서 데이터를 봐야 정확히 알게 됩니다. 잘못됐거나 빠진 것을요.

 

하지만 분명 개발된 것을 보고 요구 사항을 제시하는 것은 프로젝트 방법론상으로 잘못된 것입니다.

 

최소한 문서화된 화면을 보고 판단해야 할 거 같습니다. 사용자가 일찍 움직일 필요가 있습니다. 그리고 분석·설계 팀은 ② 단계까지 최소한 화면만은 철저하게 정제해야 합니다.

 

④ 단계에서 요구 사항이 폭주하면… 오픈이 연기됩니다.

 

데이터 모델부터 검토해야 하니 일정에 상당한 영향을 끼칩니다. ② 단계에서 변경하면 2의 수고(비용)가 더 들고요. ③ 단계에서 변경하면 6, ④ 단계에서는 조금 과장해서 40정도가 듭니다. ㅎㅎ

 

그리고 일반적으로 ④ 단계엔 전문 모델러가 없어 모델이 이상해지기 일쑤입니다. 간혹 구조가 틀어지기까지 하고요. 결과적으로 모델이 바꿔서 모델러로서 괜히 편치 않습니다.

 

역시 모델러가 프로젝트 끝까지 남아야 된다는 생각을 또 하게 되네요. 이게 프로젝트 비용을 줄이는 방법인데 개인적으로는 답답합니다.

 

아래와 같이 되지 않으려면 분석·설계자가 개발 전에 화면을 정제할 것을 권합니다. 사용자와 함께 심도있게요.

 

사용자는 개발된 것을 한번 보자는 생각보다는, 문서를 보고 요구 사항이 반영됐는지를 심도 있게 검토했으면 좋겠습니다.

 

다같이 노력하지 않는 한 현재와 같은 상황(분석·설계·개발을 허둥지둥 한꺼번에)은 계속 반복될 것입니다.



 

모델링 시 어려움 중 하나가 요구 사항이 나중에 나오는 것입니다. 이에 대한 근본적인 답은 없지만, 데이터를 통합하고 정규화하면 모델 변경을 그나마 최소화할 수 있습니다.

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

오늘은 다소 난해한 주제에 대해 쓰려고 합니다.
내용이 어려운 게 아니라 다양한 주장이 존재할 수 있는 얘기입니다.
 
모델러가 해당 업무를 잘 알아야 모델링을 잘 할 수 있을까요?
주장은 업무를 몰라도 모델링을 있다입니다.
 
이런 생각을 처음부터 했고 실무에서 경험했습니다.
잘 했는지는 모르겠지만 그다지 어려움을 느끼지 않았습니다(사실 초반에 약간 힘듭니다).
 
주변의 많은 사람들에게 얘기를 했는데요. 업무를 몰라도 모델링을 있다.
어쩌면 업무에만 치중하는 모델러가 많아 더 강조하게 됐는지도 모르겠습니다.
 
많은 모델러가 업무를 익히기 위해서 많은 노력을 하는데 모델링 기법을 익히기 위해서는 노력을 하지 않습니다.
업무 분석가를 목표로 한다면 이해가 되지만 모델러를 목표로 하면서요
 
전혀 모르는 증권 업무를 모델링 한다고 가정하고 제가 겪는 개략적인 시나리오입니다.
 
가장 먼저 떠오르는 생각은 물론 막막함입니다. 하지만 자신감은 항상 있습니다.
 
일을 시작하기 전에 해당 회사의 홈페이지를 공부합니다. 3~4시간만 집중해서 보면 업무 흐름은 얻을 수 있습니다.
저는 홈페이지를 보고 개략적인 개념 모델(엔터티)을 그리기도 합니다.
 
그리고 일을 시작하면 업무 담당자한테 고백을 합니다.
업무를 하나도 모른다고요. 자세한 설명을 부탁한다고요. 당당하게요.
창피할 필요 없습니다. 모델러가 모델링 기법과 주변 지식을 모르는 것을 창피하게 생각해야 합니다.
 
업무를 전혀 모른다고 말하면 싫어하는 기색을 보이기도 하지만 그 후에 어떻게 하냐에 따라 상대방의 태도도 달라집니다.
프로다운 기질을 보인다면 상대도 인정을 합니다.
 
제 책에도 중요하게 강조했지만 업무를 잘 알던 모르던 인터뷰는 중요합니다.
업무를 안다는 것과 엔터티를 안다는 것은 다른 차원입니다.
 
저는 업무를 잘 알아도 모른 척하고 최대한 많은 정보를 알아내려 애씁니다. 실제로 해당 엔터티는 모르니까요...
상대방과 원활한 커뮤니케이션을 하려면 많은 대화를 해야 합니다.
설명 듣고 물어보는 과정을 먼저 거친 후에 생각하고 분석하면서 모델을 만들고 리뷰하는 과정을 거칩니다.
 
그리고 인터뷰 외에 업무 매뉴얼을 구해서 많은 시간을 들여야 합니다.
이렇게 노력하면 업무에 대한 부담감은 생각보다 금방 벗어날 수 있습니다.
 
이틀 만에 부담이 없어진 적도 있습니다. 길면 한달 정도 초반 적응 기간이 힘들긴 합니다(수험생 같죠).
실제로 업무를 안다고 모델링을 잘 하는 건 아니지만 업무를 알면 여유롭습니다. 심리적인 차이가 크죠.
 
업무를 잘 알면 시간을 절약할 수 있는데 제 경험상 큰 차이는 아닙니다.
빠른 의사결정과 체계적인 진행이 시간을 더 단축시키니까요.
 
모델러에게 가장 중요한 것은 모델링 Skill 입니다.
모델링 Skill 없이 모델링 하는 것은 부끄럽게 생각해야 합니다.
 
모델러가 되고 싶은데 업무를 모른다고 고민하는 사람을 많이 보았는데요.
초반에 잠깐 겪게 될 부담감 이상은 아닙니다.
업무를 몰라도 모델링을 잘 할 수 있다는 말을 한번 믿고 모델링 이론부터 시작해 보세요.
 
사람은 뭐든 시작해야 한다고 합니다. ㅎㅎ

블로그 이미지

블루퍼필

댓글을 달아 주세요

데이터 모델링은 상식적입니다. 만약에 모델링이 상식적이지 않은 분야였다면 필자는 모델러로서 지금까지 일할 수 없었을 것입니다.

 

모델링과 관련된 내용을 크게 두 가지로 나누면 하나는 이론이고 다른 하나는 경험입니다. 그중에 모델링 이론은 지극히 상식적입니다. 모델링 이론이 다른 분야와 비교해서 어렵지 않다고 느껴지는 것은 상식적이기 때문일 것입니다.

 

정규화를 기초로 한 이론은 상식적이라고 생각합니다. 데이터 무결성을 최우선 과제로 삼는 데이터 모델링의 이론은 지극히 상식적입니다. 데이터를 제대로 관리하는 데 필요하므로 상식적일 수밖에 없습니다.

 

하지만 비록 이론은 상식적이지만 실제로 모델링을 하면 어렵게 느껴집니다. 상식적으로 알 수 있는 쉬운 이론으로 모델링을 수행해도 어려운 것이 모델링인데 이론을 모른다면 더욱 막막할 것입니다.

 

그리고 이론 이외에 경험을 통해 터득하는 부분이 존재합니다. 엔터티를 구성하는 데이터의 정체성에 대한 판단이나 데이터를 통합하는 기준은 개인마다 다를 수 있습니다. 그리고 많은 경험에 의해 단련됩니다.

 

정규화는 처음 경험하는 초보자든 경험이 많은 전문가든 이론을 정확히 알고 있다면 같은 결과가 나옵니다. 하지만 데이터 통합과 관련해서는 전문가 사이에서도 이견(異見)이 존재할 수 있습니다.

 

물론 전문가가 구축한 모델은 상세한 면에서 조금 다를 뿐 크게 보면 대단히 유사하다고 생각합니다. 이는 경험에 의해 자의적으로 모델링이 이루어지는 것 같지만, 이론이라는 상식을 기반으로 판단하기 때문입니다.

 

자신이 사용해 본 모델만을 고수하면 근거가 없으며 상식적이지 않은 것입니다. 경험이 상식이 되지 못하면 고집에 지나지 않습니다.

 

데이터 모델링은 상식적인 이론이 토대가 돼야 하며 상식을 기반으로 한 경험이 축적돼야 좋은 모델을 만들 수 있습니다. 상식이라는 근거가 없는 모델은 누구도 확신시킬 수 없으며 혼란을 일으킬 뿐입니다. 이론을 무시하면 또한 상식적이지 않은 것입니다. 이론을 바탕으로 통찰력과 분석력, 경험이 조화를 이룬다면 데이터 모델링은 어렵지 않으며 상식적인 것이 됩니다.

 

[이론과 실무를 겸비한 전략서 관계형 데이터 모데링 프리미엄 가이드] 中에서

블로그 이미지

블루퍼필

Tag 모델링

댓글을 달아 주세요

데이터 모델링은 어렵습니다. 모델링 이론이 어렵다는 말은 아닙니다. 이론은 다른 분야의 것과 비교해서 어렵지 않다고 생각합니다. 하지만 이론을 알고 있더라도 막상 시작하려면 무엇을 어떻게 해야 할지 막막해집니다. 또한 완료하고 나서는 모델링이 제대로 됐는지에 대한 확신이 없습니다. 시작하기 어렵고 결과를 확신할 수 없으니 어려운 분야임이 틀림없습니다.

 

이유는 여러 가지가 있을 것 같습니다. 우선 모델링 이론(理論) 외에 알아야 하는 분야의 폭이 넓습니다. 모델링은 데이터의 본질을 통찰해야 하는 추상적인 개념에서부터DBMS(데이터베이스)의 구체적인 특징과 기능까지 알아야 제대로 수행할 수 있습니다.

 

데이터의 집합을 정의하는 것은 쉽지 않습니다. 유사한 집합을 일반화(Generalization)하는 것도 쉬운 작업이 아닙니다. DBMS의 기본적인 특징을 알아야 하는 것은 기본이고 성능 관점의 구체적인 지식을 습득해야 합니다. 개발자보다SQL 작성 능력이 뛰어나야 하고PLAN을 분석해 효율적인 구조의 모델을 선택할 수 있어야 합니다.

 

그리고 사실상 정답이 없다는 점이 어렵습니다. 공식이나 틀에 맞추기보다는 상황에 따라 판단이 달라져서 정답이 없이 느껴집니다. 똑같은 요건도 상황에 따라 최적의 모델이 달라질 수 있습니다. 하지만 분명히 상황에 맞는 정답은 있습니다. 최소한 모범 답안은 존재합니다. 100점짜리 모델과0점짜리 모델은 존재하지 않을 수 있지만10점에 가까운 모델과90점에 가까운 모델은 존재합니다.

 

흔히 데이터 모델을 데이터 저장소와 같이 인식하고 사용합니다. 마치 블랙박스와 같은 엔터티에 무엇이 어떻게 들어 있는지는 상관없이 결과만 제대로 나오면 프로젝트는 이상 없이 진행됐습니다. 하지만 최근에는 데이터 모델에 대한 관심이 높아져서 블랙박스 안에 존재하는 모델을 공개해 더 좋은 모델이 될 수 있도록 노력합니다. 분명히90점에 가까운 모델은 있으며 어떻게든 그 모델을 지향해야 합니다.

 

또 다른 어려움은 어떤 모델이90점에 가까운 모델인지 확인할 수가 없다는 것입니다. 잘 된 모델을 확인하는 방법에 대한 연구가 절실하다고 생각합니다. 프로그램은 원하는 결과가 나오면 확인할 수 있고 튜닝은 원하는 수치나 현재보다 월등한 수치가 나오면 확인할 수 있지만 좋은 모델은 확인하기 쉽지 않습니다.

 

필자가 모델링을 수행하면서 가장 어려워하는 부분 중 하나는 구축된 모델을 관련자한테 설득하는 것입니다. 사실은 설명하는 것인데 결국 설득으로 이어지는 경우가 많습니다. 사용자를 설득해야 하고 개발자를 설득해야 합니다. 데이터 집합(주제)를 정의한 개념적인 내용을 설명하고 이해시키기는 쉽지 않습니다. 다양한 이해관계가 있는 사람을 설득하는 것 또한 쉽지 않습니다. 특히 실제로 모델을 사용해서 개발해야 하는 개발자를 설득하는 것은 힘들 때가 많습니다. 관련자를 설득할 때는 모델러 역시 객관적이고 구체적인 방법으로 설득해야 합니다. 이런 여러 가지 이유 때문에 데이터 모델링은 쉬운 분야가 아닙니다.

 

[이론과 실무를 겸비한 전략서 관계형 데이터 모데링 프리미엄 가이드] 中에서

 

 

하지만 데이터 모델링은 상식적입니다. 이는 쉽다는 것을 의미합니다.

블로그 이미지

블루퍼필

Tag 모델링

댓글을 달아 주세요