모델링을 수행하는 주체는?

데이터 Story/데이터 상념(想念) 2017.09.17 23:05

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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



저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0

도메인 개념과 대표 속성

데이터 Story/데이터 상념(想念) 2017.09.09 15:07

표준화 관련된 글을 간혹 올릴 생각입니다.

티가 안 나서 그렇지 제 책에 표준화에 대한 내용이 다소 있습니다.

 

표준화에 대한 언급을 자제한 이유가 있는데요.

그렇지 않아도 속성 표준화 위주로 모델링을 하는 실정이라 더 그렇게 될까 우려되기 때문입니다.

 

하지만 어차피 표준화는 모델링에서 빠질 수 없는 부분입니다.

잘 하면 본전이고, 제대로 못 하면 타격을 받을 수 있는 부분이라 중요합니다.

표준화에만 매달리는 것도 문제지만, 표준화를 가볍게 보는 것도 문제입니다.

 

사설이 길어지고 있는데, 표준화는 속성 명을 정하는 것과 연관되기 때문에 숙고해야 하니다.

댱연히 모델러도 양질의 표준 컨텐츠를 만들기 위해 노력해야 합니다.

 

표준화는 메타시스템과 연관될 수밖에 없어 매타시스템 기능을 일부 언급했지만, 모델러가개념을 이해하고 잘 사용했으면 하는 게 목적입니다.

분야가 다소 달라서 표준화에 대한 언급을 자제한 면도 있지만, 연관될 수밖에 없네요.

 

오늘은 도메인 개념에 대해 잠시 설명하겠습니다.

 

우선 메타시스템의 도메인 개념이 광범위한 거 같습니다.

대표적으로 ‘~코드속성을 도메인으로 분류하는데, 일반 속성(용어)으로 분류하는 게 좋습니다.

‘~코드속성은 일반 도메인과 성격이 많이 다릅니다.

코드 인스턴스도 관리해야 하고요. 오너십도 관리하는 게 좋습니다.

무엇보다 속성 자체니까요.

 

도메인이라 용어 자체가 애매하기도 합니다.

타입과 자릿수, 포멧 등이 동일한 것을 의미하는데요.

넓게 보면 모든 속성은 도메인이 될 수 있죠.

다소 포괄적인 개념이라 ‘~코드속성이나 계좌번호같은 주 식별자 속성도 도메인에 포함된 거 같아요.

 

하지만 도메인은 용어의 뒤에 붙는 단어로 보는 게 명확합니다.

가격, 금액, 내용, , , 일자 등이 도메인인 것이죠.

그리고 이는 단어를 의미합니다.

단어 중에서 속성(용어)의 뒤에 붙는 단어가 도메인입니다.

 

도메인을 사용하는 목적은 데이터 품질을 향상시키기 위함입니다.

간단히 타입과 길이를 맞추는 역할을 합니다.

일자라는 도메인을 사용하면서 어떤 속성에는 ‘30’을 의미하고, 다른 속성에서는 년월일을 의미하고, 또 다른 곳에서는 년월일시분초를 의미하는 등으로 사용하지 못하도록 하는 것이죠.

도메인은 데이터의 성질을 일치시키는 역할을 합니다.

 

계좌번호고객번호와 같은 주 식별자 속성도 도메인이 아닙니다.

저는 이를 대표 속성이라고 구분하는데요.

일반 속성인데, 대표로 사용될 수 있는 속성이죠.

대표로 사용되는 성격 때문에 도메인으로 구분되는 거 같습니다.

속성(용어)과 도메인(단어)은 구분하는 게 좋습니다.

 

대표 속성에는 크게 두 가지가 있습니다.

단독 주 식별자 속성은 모두 대표 속성입니다.

‘~번호’, ‘~ID’가 대표적이죠.

 

그리고 속성 앞에 이전, 이후, 최종 등의 접두어를 붙일 때, 원천 속성도 대표 속성이 됩니다.

예를 들어 주문금액이란 속성 앞에 변경전을 붙여 변경전주문금액속성을 만들 때, 주문금액 속성은 대표 속성이 됩니다.

앞에 수식어가 붙었지만 원천 속성과 같은 의미를 나타내면, 그 원천 속성은 대표 속성이 됩니다.

의미가 동일하니 데이터의 타입이나 길이, 포멧 등도 같아지겠죠.

 

도메인을 사용하는 목적이 데이터 타입이나 길이를 일치시는 것인 반면에, 대표 속성을 사용하는 이유는 몇 가지가 있습니다.

원론적으로는 같은 의미를 나타내는 역할을 합니다.

계좌번호입금+계좌번호속성은 같은 것을 의미합니다.

만약 전자가 우리의 수신 계좌를 나타내는 계좌번호라면 후자도 우리 수신 계좌를 나타내는 계좌번호입니다.

우리의 외환 계좌번호도 아니며 다른 은행의 수신 계좌번호도 아닙니다.

우리의 수신 계좌번호인데 입금할 때 사용한다는 걸 의미할 뿐이죠.

 

따라서 입금계좌번호속성을 등록할 때 대표 속성으로 계좌번호를 지정하면 위와 같이 의미가 같아지는 것입니다.

데이터의 타입과 길이가 일치되는 것은 기본이고요.

 

위와 같이 대표 속성을 지정하면 또 다른 효과가 있습니다.

계좌번호에 대한 컬럼 명이 달라지지 않습니다.

계좌번호의 컬럼 명이 ‘ACNO’라면, ‘입금+계좌번호의 컬럼 명은 ‘DP_ACNO’가 됩니다.

 

만약 대표 속성으로 지정하지 않으면 ‘DP_AC_NO’가 될 수 있습니다.

그렇게 되면 다른 것을 의미한다고 생각할 수 있게 됩니다.

데이터 타입이나 길이가 달라질 수도 있고요.

같은 것을 의미하는데도 컬럼 명이 달라졌다면 표준을 위배한 것이 되고요.

 

대표 속성을 사용해야 하는 이유는 영문이 달라지지 않도록 하는 게 큽니다.

입금계좌번호송신계좌번호수수료이체계좌번호든 우리 수신 계좌를 의미하면 대표 속성으로 계좌번호를 지정해야 컬럼 명의 뒷 부분이 동일해집니다.

 

대표 속성을 등록할 때 주의해야 할 점이 있습니다.

우선 주 식별자를 의미하는 대표 속성의 영문 명, 즉 컬럼 명은 단어의 조합이 아니라 ‘_’가 없는 약어로 만드는 게 바람직합니다.

 

매우 자주 쓰이고 다양한 역할로 쓰일 것이기 때문에 영문을 간략하게 만드는 게 좋습니다.

부가가치세‘VL_AD_TX’로 하지 않고 ‘VAT’로 하는 것과 같습니다.

계좌번호를 단어의 조합인 ‘AC_NO’로 하지 않고 ‘ACNO’ 또는 ‘ACN’으로 만드는 것입니다. ‘고객번호‘CT_NO’가 아닌 ‘CTN’으로 만드는 것이죠. 컬럼 명을 줄이는 효과가 있습니다.

 

오라클은 컬럼 명을 30자리까지 만들 수 있는데, 30자를 초과하는 컬럼 명이 생각보다 많이 나옵니다.

비율로는 1%도 안 될 것이지만 개수로는 수십 개가 되는데, 생각보다 처리하기 골치 아픕니다.

길이 제한이 없어도 가능한 짧은 게 좋습니다.

 

단독 주 식별자와 같이 생성 시점부터 알 수 있는 대표 속성은 “_”없이 컬럼 명을 정할 수 있는데요.

변경전+주문금액처럼 생성 시점에는 대표 속성이 아니었지만, 수식어가 붙을 때 대표 속성이 되는 경우에는 위와 같이 미리 정할 수가 없습니다.

이 때는 당연히 주문금액‘OD_SM’으로 쓰이고 있을 것이기 때문에, ‘변경전주문금액‘BC_OD_SM’이 될 것입니다.

 

단독 주 식별자 대표 속성은 모델러가 해당 엔터티를 설계한 후에 등록하는 게 특징입니다. 일반 속성 중에 의미가 명확하다면 모델링 전에 미리 등록할 수 있지만, 주 식별자 대표 속성은 모델링이 끝난 후에 등록하는 게 바람직합니다.

의미 파악이 정확히 끝난 후에 속성 명을 메타시스템에 등록하는 게 원칙입니다.

 

표준화도 내용이 많아서 정리가 안 되네요.

정리하면서 가끔씩 올리겠습니다.

 

저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0

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

데이터 Story/데이터 상념(想念) 2017.09.02 09:21

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

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

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

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

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

 

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

정답은 아니오입니다.

 

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

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

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

 

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

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

 

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

 

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

 

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

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

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

 

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

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

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

 

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

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

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

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

 

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

두 가지 이유가 있습니다.

 

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

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

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

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

 

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

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

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

 

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

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

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

 

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

 

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

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

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

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

 

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

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

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

 

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

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

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

 

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

 

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

 

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

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

 

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

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



저작자 표시 비영리 변경 금지
신고
Trackback 0 : Comment 0

티스토리 툴바