태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

'데이터 Story/데이터 상념(想念)'에 해당되는 글 36건

오늘은 비전에 대한 글을 짧게 써보려고 합니다.

저의 비전이니 데이터인들의 비전일 수 있다고 생각합니다.

 

차세대 등의 개발 프로젝트에서 소프트웨어를 분리 발주하듯이, 데이터 분야도 분리 발주해야 한다는 것이 제 생각입니다.

발주사 입장에서 모델링, 표준화, 이행, 튜닝 등의 DA 영역은 별도로 계약하는 것입니다.

 

데이터 분리 발주를 주장하는 이유는 바로 아시겠죠?

시스템의 토대가 되는 데이터 구조를 제대로 구축하기 위함이고, 사업의 근간이 되는 데이터를 제대로 관리하기 위함입니다.

 

현재는 수행사가 발주사와 전체 계약을 하고, 필요 시 데이터 분야에 대해서는 수행사가 데이터 전문 업체와 계약을 합니다.

 

이런 방식으로라도 데이터 전문 업체를 참여시키면 좋을 텐데 현실은 그렇지 않은 경우가 많습니다.

수행사에는 코디네이터 역할을 할 데이터 아키텍트만 있고, 개발자가 모델링, 표준화, 튜닝을 다 하는 게 현실입니다.

 

개발자는 자신이 개발할 영역에 대해서 모델링부터 개발, 튜닝까지 모든 부분을 다 해야 하니 기술적으로 벅찰 수밖에 없습니다.

수많은 개발자가 각자의 방식으로 하니 일관성도 떨어지고, 품질이 떨어집니다.

 

데이터 영역을 분리 발주했을 때, 발주사 측이 얻게 될 가장 커다란 장점은 데이터 산출물에 대한 품질입니다.

모델 구조가 제대로 설계되고, 그에 맞게 데이터가 제대로 관리돼 사업하기 좋은 데이터를 확보하게 되는 것입니다.

좋은 모델을 운영하면 여러 가지로 효율적입니다.

 

수행사 입장에서의 장점은 중복 개발을 방지하고 개발을 효과적으로 할 수 있다는 점입니다.

모델의 잦은 변경으로 인한 개발 비효율이 많이 개선됩니다.

매번 느끼는 것이지만 이 부분이 가장 큰 거 같습니다.

지출하지 않아도 되는 비용을 소비해 적자가 되는 것을 방지할 수 있습니다.

 

또한 골치 아픈 데이터 영역은 신경 쓰지 않을 수 있다는 점도 장점입니다.

잘 아는 부분이 아니라서 간혹 큰 곤혹을 당하기고 하고요.

전문가 집단이 고객을 상대하니 일이 수월해지기도 합니다.

 

데이터 영역이 이슈도 많아서 처음부터 전문 업체와 계약하는 수행사도 많은 편입니다.

이슈가 생긴 후에 전문 업체를 찾는 경우도 많지만요.

수행사 입장에서는 거추장스러운 혹을 떼고, 우왕좌왕하지 않을 수 있다는 점이 장점입니다.

 

데이터 분리 발주를 하면 발주사 측이 느낄 가장 큰 불편함은 관리일 것입니다.

 

계약을 나눠서 하는 것이니 행정적으로 불편할 것이고요.

프로젝트 수행 시에는 애플리케이션과 데이터 양쪽을 관리한다고 생각할 수 있습니다.

 

수행사 측의 단점은 생각하기 나름일 거 같지만, 몫이 줄어든다는 점일 거 같습니다.

 

관리하기 힘들 수 있다는 발주사 측의 단점은 크지 않을 수 있습니다.

 

분리 계약이 돼도 어차피 수행사가 전체 프로젝트를 이끄는 것입니다.

사업관리나 QA도 역할을 해야 하고요.

PMO나 감리도 있기 때문에 관리 차원에서 우려할 것은 크지 않을 것입니다.

 

발주사가 수행사와 계약할 때, 데이터 분야에 대한 관리를 일임하게 될 것입니다.

데이터 영역을 분리 발주한다고 데이터 영역 내에 사업관리나 QA 등이 있는 건 아니니까요.

데이터 전문 업체는 산출물을 만드는 역할만 하게 됩니다.

프로젝트 관리에 대한 계약은 수행사가 하는 것이니, 데이터 영역 관리는 자연스럽게 포함됩니다.

 

또한 계약이 어떤 형식이든, 발주사 내에도 DA가 있기 때문에 데이터 영역에 대한 관리는 유사하게 이루어집니다.

수행사 내에서도 관리나 코디네이터 역할을 하는 DA는 필요하고요.

 

데이터 분리 발주가 법으로 정해진다면, 위에서 언급한 대로 가장 중요하고 어려운 데이터를 전문가에게 맡기는 것이니 시스템이 제대로 구축되는 기반이 생기는 것입니다.

 

전문적인 일은 전문가에게 맡겨야 자잘한 사고도 급격히 줄어듭니다.

준전문가나 비전문가에게 전문적인 일을 맡기는 방식은 이제 지양해야 합니다.

대형 사고 발생 확률은 높지 않고, 발생 시 땜질하면 된다는 사고는 후진적입니다.

 

그리고 현재처럼 데이터 전문 업체가 수행사에 종속된 형태로 일을 하면 생존 자체를 보장할 수 없습니다.

30~40년 전부터 한 번도 중요하지 않은 적이 없었던 데이터이지만 데이터 전문 업체의 성장은 한계가 있었는데, 데이터 분리 발주 법이 제정된다면 데이터 전문 업체도 성장하고 시스템도 한 단계 성장할 것이라고 생각합니다.

 

지금도 데이터를 중시하는 고객은 분리 발주와 유사한 방식으로 데이터 전문 업체에게 데이터 영역을 맡기고 있습니다.

최소한 수행사에 데이터 전문 업체 참여를 필수 조건으로 제시하고 있죠.

 

하지만 미약합니다.

법으로 정해져야 진정한 효과가 생길 것입니다.

시스템에 혁명이 이루어진다고 확신하고 있습니다.

 

데이터 업체들과 데이터인들이 합심하면 이런 꿈을 이룰 수 있다고 생각합니다.

최소한 데이터를 근간으로 이루어지는 시스템 구축에 데이터 전문가가 참여하는 것이 상식인 시대가 될 것입니다.

후대에라도 이룰 수 있었으면 좋겠습니다.

 

부족한 글이지만, 이 글이 제대로 된 데이터 여건을 만드는 마중물 역할을 했으면 좋겠습니다.


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

데이터에 대한 개인적인 비전  (0) 2018.06.23
데이터 아키텍트 프레임웍  (0) 2018.03.31
[worst practice 4]  (0) 2017.11.04
worst practice  (0) 2017.10.28
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
블로그 이미지

블루퍼필

댓글을 달아 주세요

아래 그림은 데이터 아키텍트가 해야 할 일에 대한 프레임웍입니다. 프레임웍(Framework)이란 전체가 어떻게 구성됐는지를 보여주는 논리적인 틀입니다.



데이터 아키텍트가 해야 할 일은 크게 표준, 구조, 품질 영역으로 구분할 수 있습니다. 각 영역은 업무의 종류에 따라 원칙, 설계, 관리, 시스템으로 구분할 수 있습니다.

 

표준 영역은 데이터에 대한 표준화를 의미합니다. 표준 지침서가 있어야 하고, 표준 단어와 표준 용어와 같은 표준 컨텐츠가 있어야 합니다. 그리고 이런 컨텐츠를 관리하는 메타 시스템이 필요합니다.

 

구조 영역은 데이터 모델을 의미합니다. 마찬가지로 모델링 지침서가 있고, 데이터 주제 영역, 개념 모델, 논리 모델 등이 있습니다. 모델링은 표준 데이터를 이용해서 수행합니다. 모델은 저장소에 저장돼 메타 시스템과 연동되고요.

 

품질 영역은 표준과 구조, 데이터 값에 대한 품질 관리를 의미합니다. 품질을 높일 수 있는다양한 기준(지표)을 관리해서 잘못된 부분을 개선해서 표준, 구조, 값에 대한 품질을 높이기 위한 활동을 하게 됩니다. 이런 활동을 원활하게 하기 위해서는 DQ시스템을 사용하게 됩니다.

 

세로 축인 원칙과 설계, 관리, 시스템은 서로 유기적으로 엮여 있습니다. 원칙에 따라 설계를 해야 하고, 설계 결과를 시스템에 반영해야 합니다. 또한 설계된 결과물은 검토나 승인 과정이 필요하며, 지속적으로 관리돼야 합니다.

 

가로 축인 영역 또한 서로 엮여 있습니다. 데이터 표준에 맞게 데이터 구조를 설계하게 되고, 데이터 구조를 구현한 DB에 저장된 데이터 값과 표준 콘텐츠, 모델 구조 자체에 대한 품질을 높이기 위한 활동을 하게 됩니다.

 

위의 데이터 아키텍트 프레임웍은 DA가 수행해야 할 핵심 요소만을 포함시켰습니다. 데이터 아키텍트는 위에 표현된 일 외에도 많은 역할을 하게 됩니다. 이해 관계자 사이의 의견을 조율하고 DA 조직을 관리하는 일도 하게 됩니다. 데이터와 관련된 각종 이슈를 해결해야 하는 것은 당연한 업무입니다.

 

데이터와 관련된 모든 지식을 총괄하는 사람이 데이터 아키텍트며, 총괄해야 하는 지식을 간단하게 표현한 것이 위의 표입니다.



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

데이터에 대한 개인적인 비전  (0) 2018.06.23
데이터 아키텍트 프레임웍  (0) 2018.03.31
[worst practice 4]  (0) 2017.11.04
worst practice  (0) 2017.10.28
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
블로그 이미지

블루퍼필

댓글을 달아 주세요

요건은 아래와 같습니다.

 

-부서명, 전화번호, 부서장 등의 부서에 대한 기본 정보를 관리한다.

-전화번호, 부서장 등의 데이터는 변경될 수 있어 이력 관리한다.

 

위의 요건을 설계한 모델이 아래와 같습니다.

잘못된 부분을 생각해 보세요.

 

 


[그림 1]

 

 

--

 

이력 데이터를 어떻게 설계할지에 대한 문제입니다.

 

이력 데이터를 원천 엔터티에 통합해서 관리하면 좋을 때가 있고 그렇지 않을 때가 있습니다. [그림 1]은 그렇지 않을 때에 해당돼서 아래와 같이 관리하는 게 바람직합니다.

 


[그림 2]

 

실체를 관리하는 엔터티나 기본 정보를 관리하는 엔터티, 기준 정보를 관리하는 엔터티는 이력 데이터를 원천 데이터와 같이 관리하지 않는 것이 좋습니다.

 

실체 데이터는 한 번 생기면 그대로 존재하는 것이어서, 특성(속성)이 바뀐다고 새로운 인스턴스로 생성하면 데이터 성격을 반영하지 못 한 것이라 하나의 인스턴스로 존재해야 하고요. 기본 정보나 기준 정보 또한 실체 성격을 포함하고 있기도 하고, 참조하기 좋아야 하기 때문에 그렇습니다.

 

행위 엔터티가 아닌데 일자 속성이 주 식별자에 존재하면 한번 더 고민하셔야 됩니다. 대개 이력 데이터를 포함시켜서 그렇게 되는데 바람직하지 않습니다.

 

쉽게 생각해서 참조되는 엔터티는 관계선을 표현할 수 있도록 설계해야 합니다. 조인해서 사용한다는 의미니까요. [그림 1]이라면 다른 엔터티와 조인해서 사용하기 매우 어려운 상태입니다. 약간씩 다르지만 [그림 3]도 역시 마찬가지로 모두 바람직하지 않습니다.

 

   

  

[그림 3]

 

일부 기본 정보를 관리하는 엔터티는 [그림 1]처럼 원천 데이터와 이력 데이터를 같이 관리할 수 있습니다. 굳이 나눠서 관리하면 엔터티 개수만 늘어나서 같이 관리할 수 있는데, 조인해서 사용하지 않을 때만 가능합니다.

 

[그림 4] 모델도 간혹 보는데, 많이 참조되는 주요 엔터티가 이렇게 설계되면 매우 난감해집니다. 어떻하든 사용은 가능하지만요.

 


[그림 4]



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

데이터에 대한 개인적인 비전  (0) 2018.06.23
데이터 아키텍트 프레임웍  (0) 2018.03.31
[worst practice 4]  (0) 2017.11.04
worst practice  (0) 2017.10.28
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
블로그 이미지

블루퍼필

댓글을 달아 주세요

이번 요건은 다소 까다롭습니다.

 

-한 계좌에는 관리 사원, 실적 사원 등 여러 역할 사원이 존재한다.

-한 사원은 여러 계좌의 관리 사원이 될 수 있고, 여러 계좌의 실적 사원이 될 수 있다.

-동일 사원이 동일 계좌에 대해 여러 역할을 할 수는 없다.

-계좌에 대한 역할 사원은 한 번 정해지면 바뀌지 않는다.

 

위 요건을 설계한 모델이 [그림 1]입니다.

잘못된 부분을 생각해 보세요.

 

[그림 1]

 

역할유형코드의 인스턴스는 관리사원, 실적사원입니다.

 

--

 

식별자밖에 없으니 식별자에 대한 문제죠.

 

우선, 역할이 한 번 정해지면 바뀌지 않는다고 했습니다. 즉 한 번만 지정되는 것이니 역할지정일자 속성은 식별자가 아닙니다.

 

그리고 동일 사원이 동일 계좌에 대해 여러 역할을 할 수 없다고 했습니다. 이 요건 때문에 역할유형코드 속성이 식별자에서 제외됩니다.

 

따라서 정제된 모델은 [그림 2]와 같습니다.

 

[그림 2]

 

릴레이션은 아래와 같습니다.

 

[계좌역할사원]

#계좌번호

#사원번호

역할유형코드

역할지정일자

10001

500(홍길동)

관리사원

2045-01-01

10001

100(강길동)

실적사원

2045-01-01

40001

100(강길동)

관리사원

2045-03-31

80001

500(홍길동)

관리사원

2045-05-01

80001

300(이길동)

실적사원

2045-05-01

50001

500(홍길동)

실적사원

2045-05-31

 [그림 3]

 

항상 사례 데이터를 만들어서 요건을 확인해 보시길 바랍니다.

설계할 때부터 그렇게 하는 게 좋습니다.

특히 기준 정보, 관계 정보, 기본 정보 등의 데이터는 필수라고 생각합니다.

 

코드 속성이 식별자에 포함될 때는 주의해야 합니다.

코드 속성이 식별자에 포함된다는 것은, 코드 별로 관리하려는 대상이 여러 개라는 것을 의미하죠.

 

[그림 3]을 예로 들면, ‘10001’번 계좌에 대해서 관리 사원이 홍길동강길동이 될 수 있거나, ‘홍길동이 관리 사원과 실적 사원이 동시에 될 수 있을 때 역할유형코드 속성이 식별자에 포함됩니다.

 

위의 요건 중 첫 번째, 두 번째 요건은 관계비(까마귀발)를 나타냅니다.

즉 첫 번째 요건은 해당 엔터티와 계좌 엔터티에 대한 관계비를 나타내고, 두 번째 요건은 해당 엔터티와 사원 엔터티의 관계비를 나타냅니다.

 

세 번째 요건은 관계가 없으니 관계비와는 무관하고, 해당 엔터티에서의 식별자와 연관됩니다.

네 번째도 마찬가지로 해당 엔터티에서의 식별자와 연관됩니다.

 

위와 같이 요건 중에는 관계비를 의미하는 게 있고요. 관계 속성이죠.

일반 속성을 의미하며 식별자와 연관되는 요건이 있습니다.

둘을 구분하면 주 식별자 설계에 도움이 됩니다.

관계비가 일대다라고 꼭 식별자에 포함되는 것은 아닙니다.

 

두 개념이 복잡하게 엮인 요건은 주 식별자 설계가 까다롭습니다.

인터뷰 시에도 담당자가 정확히 설명하지 못할 수 있습니다.

사례 데이터를 만들어 보면서 많이 연습하는 게 중요합니다.


참고로 [그림 1]처럼 일반 속성이 식별자에 포함된 것을 슈퍼 식별자라고 합니다.

이미 식별이 되는데 다른 속성을 추가했으니 식별자 역할은 합니다.

슈퍼 식별자면 요건 자체도 흔들릴 수 있고, 데이터가 잘못 쌓이면 요건이 망가집니다.

데이터 무결성을 저해하는 가장 심한 것 중의 하나가 슈퍼 식별자입니다.

 

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

데이터 아키텍트 프레임웍  (0) 2018.03.31
[worst practice 4]  (0) 2017.11.04
worst practice  (0) 2017.10.28
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
[worst practice 1] 잘못 설계된 모델  (1) 2017.09.24
블로그 이미지

블루퍼필

댓글을 달아 주세요

요건이 아래와 같습니다.

 

-고객이 발급 받아서 사용하는 보안카드를 관리한다.

-폐기한 보안카드 데이터를 관리하는데, 일자별로 폐기된 보안카드를 조회할 수 있도록 관리한다.

 

이 요건을 아래와 같이 설계했습니다.

잘못된 부분을 생각해 보세요.

 

[그림 1]

 

--

 

고객보안카드페기 엔터티의 주 식별자가 잘못됐습니다.

쉽게 찾으셨을 거 같아요.

 

하나의 보안카드가 여러 번 폐기될 때 [그림 1] 고객보안카드페기 엔터티와 같이 설계할 수 있습니다.

발급된 보안카드는 한 번 폐기되면 끝이기 때문에 [그림 2]와 같이 설계해야 적절합니다.

 

[그림 2]

 

일자별로 폐기된 보안카드를 조회한다는 이유 때문에 폐기일자 속성이 주 식별자에 포함된 사례로, 역시 슈퍼 식별자입니다.

폐기일자+보안카드번호는 인덱스를 나타내죠.

 

[그림 2] 정도도 좋지만, 고객보안카드폐기 엔터티 명은 행위를 나타내는 반면에, 데이터 성격은 보안카드라는 실체를 나타내기 때문에 [그림 3]이 더 명확할 거 같습니다.

 

[그림 3]

 

덧붙이면, 고객보안카드 엔터티에 보안카드상태구분코드 속성이 필요해 보이고, 폐기사유구분코드 속성 명은 일반적이라서 보안카드페기사유구분코드 정도가 명확합니다. 이 부분을 지적하셨다면 매우 치밀하신 것입니다.

 

코드 속성 명은 매우 신경써야 합니다.

코드 인스턴스가 있기 때문에 구체적이어야 오너십도 분명해지고 제대로 사용할 수 있습니다.

 

폐기일자 속성은, 그 정도로 충분하다고 생각합니다.

구체적으로 정해도 좋고요.

 

정제된 모델은 [그림 4]와 같습니다.

 

[그림 4]

 

마지막으로, 폐기에 대한 요건이 많지 않거나 폐기에 대한 속성이 별로 없다면, [그림 5]와 같이 설계해도 됩니다.

 

[그림 5]

 

요건이 자세하진 않지만, [그림 5]처럼 설계하셨다면 데이터 성격을 명확히 파악하신 것입니다.

원래는 하나의 데이터인데, 필요에 의해 일대일(1:1)로 분리해서 [그림 4]와 같이 되는 것이니까요.



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

[worst practice 4]  (0) 2017.11.04
worst practice  (0) 2017.10.28
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
[worst practice 1] 잘못 설계된 모델  (1) 2017.09.24
DA 전망  (0) 2017.09.23
블로그 이미지

블루퍼필

댓글을 달아 주세요

  • jack 2017.11.09 16:19  댓글주소  수정/삭제  댓글쓰기

    기창님 매번 좋은 글 올려 주셔서 감사합니다.
    모델링 노트, 일이 막힐 때마다 찾아서 읽고 있습니다.
    다름 아니라 게시글에 한 가지 궁금한 점이 있어서 그런데요..
    보안카드상태구분코드 속성은 없어도 되지 않을까요? 폐기일자 속성이 null이 아닐 경우 폐기됐다라고 간주함 충분할 거 같습니다.

    • 블루퍼필 2017.11.11 19:41 신고  댓글주소  수정/삭제

      예.. 맞습니다.
      폐기 여부는 말씀하신대로 하면 판단 가능해서 굳이 상태구분코드가 필요 없는데요.
      요건이 복잡해지면 정상, 정지, 폐지 등으로 늘어날 수 있고.. 집계에 사용될 수도 있고..
      아시다시피 요건에 따라 달라지겠네요.
      예제 모델에서는 굳이 필요 없습니다. ㅎ
      의견 감사합니다.

  • jack 2017.11.15 15:58  댓글주소  수정/삭제  댓글쓰기

    며칠 동안 고민했는데 말씀주신거처럼 요건이 복잡해지면 구분코드가 필요하겠네요^^

자기 일에 애정을 가진 진지한 모델러일수록 상처받기 쉬운 법이다.

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

worst practice  (0) 2017.10.28
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
[worst practice 1] 잘못 설계된 모델  (1) 2017.09.24
DA 전망  (0) 2017.09.23
모델링을 수행하는 주체는?  (0) 2017.09.17
블로그 이미지

블루퍼필

댓글을 달아 주세요

잘못 설계한 사례 모델을 간혹 올릴 생각입니다.

궁금하신 점이나 다른 아이디어 있으면 댓글로 남겨주세요.

 

--

 

요건은 아래와 같습니다.

 

-회원은 주민등록번호 별로 한 번만 가입이 가능하다.

-회원은 고유한 회원아이디가 있으며, 한 회원이 여러 개의 회원아이디를 가질 수 있다.

 

[그림 1]은 위의 요건을 설계한 모델입니다.

 


[그림 1]

 

어디가 잘못 설계됐는지 잠깐 생각해 보세요.

그런데 모델이 너무 간단해서 잘못될 부분이 한 군데 밖에는 없네요.

 

잘못된 부분은 답글에 올렸습니다.

답글 보시기 전에 많이 생각해 보세요.

 

--

 

회원아이디 엔터티의 주 식별자가 잘못 설계됐습니다.

 

회원아이디 속성 값이 고유하기 때문에 회원아이디 엔터티의 주 식별자는 [그림 2]와 같이 회원아이디 단독 속성이어야 합니다.

 


[그림 2]

 

회원이 아이디를 여러 개 가질 수 있어서 [그림 1]처럼 설계됐고요.

인덱스를 생각하다 설계하면 [그림 1]과 같이 될 거 같습니다.

 

이미 식별자 역할을 하는 주 식별자에 다른 속성을 추가해서 만든 것을 슈퍼 식별자라고 합니다.

실무에서 슈퍼 식별자는 광범위하게 사용되는데 찾기가 쉽지 않다는 게 또 다른 문제입니다.

업무 식별자를 충실하게 분석하는 방법 밖에 없습니다.

 

슈퍼 식별자가 사용되면 엔터티 본질이 흐려지고요.

실제 업무 식별자가 중복 발생될 수 있습니다.

슈퍼 식별자가 하위 엔터티로 상속되면 위의 문제가 배가 되고요.

계속 상속될수록 모델은 난해해집니다.

 

모델을 이해할 수 없게 만드는 주범 중의 하나가 슈퍼 식별자로 절대로 사용하지 않아야 합니다.

 

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

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

블루퍼필

댓글을 달아 주세요

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

 

이유는 여러 가지가 있는데요. 우선 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
블로그 이미지

블루퍼필

댓글을 달아 주세요