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

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

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

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

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

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

 

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

정답은 ‘아니오’입니다.

 

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

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

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

 

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

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

 

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

 

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

 

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

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

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

 

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

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

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

 

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

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

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

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

 

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

두 가지 이유가 있습니다.

 

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

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

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

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

 

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

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

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

 

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

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

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

 

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

 

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

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

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

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

 

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

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

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

 

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

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

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

 

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

 

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

 

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

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

 

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

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