태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

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

 

이유는 여러 가지가 있는데요. 우선 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를 준비하는 사람이 많아져서 때가 왔을 때 제대로 했으면 좋겠습니다. 모델러들도 더욱 노력했으면 좋겠고요. 모델링을 이끌었던 선구자적인 회사들도 초심으로 돌아가서, 힘들어도 다시 노력했으면 좋겠습니다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

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

 

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

 

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

또 다시 새해를 맞았습니다.

자꾸 새해가 밀려오네요.

 

모델링의 가치가 무엇인지는 최근 2~3년 동안 스스로에게 많이 했던 질문입니다.

 

한참 전에는 모델링이 재미있어서 했습니다.

바둑 둘 때나 농구할 때와 같이 모델링을 하면 시간 가는 줄을 몰랐어요.

아무리 많은 일을 맡아도 힘들지 않고 재미있게 했습니다.

몰두하면 머리도 맑아지고재미있는데 돈까지 벌 수 있으니 좋았어요.

 

그러다 체력이 떨어지고 건강이 나빠지기 시작하니까 모델링이 힘들어지기 시작했어요.

여전히 재미는 있었지만, 힘든 상황에서 무엇을 위해 모델링을 해야 하는지를 자주 생각하게 됐습니다.

 

사설이 걸어졌네요.

 

결국, 모델링을 하는 목적은 좋은 모델을 만들기 위함이라고 생각합니다.

좋은 모델을 간단하게 설명할 수 없지만데이터 자체를 있는 그대로설계하고변화에 대처하기 쉽게 설계된 모델이 좋은 모델이 될 수 있어요.

 

많은 모델러가 좋은 모델을 만드는 것을 최고로 가치 있는 것으로 여겼으면 좋겠습니다.

모델링 환경이 생각보다 더디게 나아지고 있지만진심으로 모델 자체에가치를 두는 모델러가 많아진다면 더디지만 계속 좋아질 거라 생각합니다.

 

타스크가 있기 때문에 그저 하는 모델링이 아닌개발을 하기 위해어쩔 수 없이 하는 모델링이 아닌 좋은 모델을 만들기 위해 하는 모델링이 됐으면 좋겠습니다.

 

그러기 위해서는 좋은 모델을 설계할 수 있어야 합니다.

모델러로서의 역할을 수행할 수 있는 것만으로 만족하는 것이 아닌좋은모델을 설계할 수 있는 실력을 쌓기 위해 다같이 노력했으면 좋겠습니다.

 

모델러는 고객에게 좋은 모델을 제공하고좋은 모델을 보유한 고객은국민에게 좋은 서비스를 제공했으면 하는 바람입니다.

 

힘들게 일하고 계신 모델러분들 힘내시고 즐모하세요.

DAP를 위해 힘들게 공부하고 계신 분들도 끝까지 힘내시고,

무엇보다 건강한 2017년이 되시길 바라겠습니다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

블로그에 서브타입에 대한 글을 쓰고 있는데요.

변화를 위해 다양한 주제의 글을 올리겠습니다.

 

나이를 먹을수록 확실히 체력의 부담을 느낍니다.

일주일에 하나씩은 올리려는 생각이 한 달에 두 개로 줄고... 실제는 하나만 올라가기도 하고요.

 

최근에 정규화에 대해 다시 생각하고 있습니다.

 

지나치게 사적인 얘기지만 저는 모델링이 자신 있는데요. 남들이 뭐라하든... ㅎㅎ

오래 전부터 해 오던 훈련 때문입니다.

 

속성의 종속 관계를 파악해서 엔터티를 도출하는 훈련인데요. 쉽게 말해 속성이 엔터티에 속하는 게 옳은지를 판단하는 것입니다. 이 훈련의 핵심은 식별자와 종속성입니다.

 

엔터티를 대표하는 속성(업무 식별자)을 찾아야 하고요. 그 속성을 기준으로 대상 속성이 종속됐는지 여부를 판단합니다. 종속성이 없다면 다른 엔터티를 찾고요.

 

이 훈련을 거듭하면 전문 모델러가 될 수 있습니다. 정규화를 제대로 아는 전문 모델러가요.

 

정규화를 꼭 해야 하는지 묻는 사람들이 많습니다. 원론적인 얘기들은 이후에 많이 하겠지만 모델러라면 정규화를 꼭 해야 한다고 단언합니다.

 

정규화를 별로 고려치 않으면서 모델링하는 사람을 보는데요. 결과와 무관하게 전문 모델러로 여기지 않습니다.

 

사실 정규화를 모르고 화면 위주로 설계해도 대강은 맞게 돼 있습니다. 어떤 화면이라도 본질적으로 유사한 정보(종속성으로 묶인 정보)와 참고로 보여주는 정보(다른 화면에도 존재하는 중복 정보)를 한 화면에 보여주니까요.

 

하지만 이렇게 설계하면 뭔가를 변경하고 추가할 때 문제가 발생합니다. 그 문제가 그때그때 견딜만 해서 버텼던 것인데요. 이젠 전문가 집단이 생기고, 더 이상 주먹구구식으로 설계해선 안 되겠다는 인식이 생겨 마냥 버틸 수는 없게 됐습니다.

 

제대로 설계하기 위한 근본적인 해결책은 정규화입니다. 시스템에 따라 정규화가 필요 없을 수 있지만 그건 필요에 따른 선택일 뿐입니다. 이마저도 원칙에 바탕을 둔 선택입니다. ()와 객()을 혼돈하면 안 됩니다.

 

정규화는 엔터티 정의 자체이기 때문에, 즉 근본적인 것이기 때문에 아무리 강조해도 부족함이 없습니다. 선택 사항이 아니라는 사실을 염두에 둬야 합니다.

 

정규화에는 여러 종류가 있는데요. 정규화 이론에 대한 이견은 크지 않습니다. 학문으로 연구하는 사람은 약간씩 다른 주장을 하지만 모델러에게 큰 영향은 없을 거 같습니다.

 

일반적으로 정규화는 순서대로 수행하지 않습니다. 상향식이면 속성을 제거하면서 정규화가 수행되고, 하향식이면 생각하는 과정을 거쳐 이미 3~4정규화가 수행됩니다. 제가 초보일 때를 생각해봐도 순서대로 수행하지 않았던 거 같습니다.

 

물론 1정규화부터 차례대로 수행해도 됩니다. 현실적이진 않지만 더 체계적일 수는 있습니다. 2정규형이면 1정규화도 만족해야 되니까요.

 

RDB의 핵심은 조인(Join)입니다. 모든 속성은 주인이 되는 하나의 엔터티에만 속하고, PK만이 다른 엔터티에 존재할 수 있습니다. 다른 엔터티에 있는 속성이 필요하면 PK를 통해 조인을 해서 얻는 것이 RDB 개념 자체입니다.

 

속성의 주인(엔터티)을 찾는 과정이 정규화입니다.




블로그 이미지

블루퍼필

댓글을 달아 주세요

책을 읽지 않는 사람들이 의외로 많습니다.

 

편의를 위해 모델러로 제한하고 쓰겠습니다(모델러만 비판하는 글은 아님).

그리고 책도 소설책이나 교양책 등은 제외하고 모델링 관련 서적으로 제한하겠습니다.

 

모델러는 전문 지식이 없으면 시작조차 못하는 직업이라 전문 지식이 있어야 합니다.

그래서 모델러가 되기 위해서 관련 책을 많이 봅니다.

 

그런데 모델러가 된 후에는 책을 안 보는 경향이 있습니다.

즉 업무에 진입하려 노력하지만 진입하면 노력하지 않는다는 거죠.

 

몇 가지 이유가 있을텐데요.

 

우선 책 자체를 싫어하는 성향입니다.

이건 근본적인 문제인데, 쉽지 않겠지만 책과 친해지도록 노력해야 할 거 같습니다.

책을 읽어야 한다는 것은 아무리 강조해도 지나치지 않습니다.

 

그리고 너무 바쁘고 고단합니다.

안타까운 일인데 시간이 갈수록 여유가 없어집니다.

하지만 이게 책을 읽지 않는 면책 사유는 되지 않을 거 같습니다.

 

저도 가끔 하는 말이지만 바쁘다는 말은 스스로 믿지 않습니다.

더군다나 바쁘게 일하는 것과 효과적으로 일하는 것은 별개입니다.

 

책을 읽으면서 많이 사고(思考)하지 않는 한 슬프게도 계속 바쁠 것입니다. 더욱 슬프게도 성과와는 무관하게요.

 

책을 안 보는 또 다른 이유는 굳이 공부를 하지 않아도 업무를 할 수 있다는 것입니다.

 

어떤 일이든 한번만 하면 다음부터는 전에 했던 대로 하면 대개 문제가 없습니다.

안타깝게도 잘 하는 게 목표가 아니라 문제가 없도록 하는 게 목표인 경우가 많습니다.

 

일하면서 답답할 때가 있는데요. 어떤 것을 결정할 때 그걸 선택한 이유가 이전에 그렇게 했기 때문이라는 답변을 들을 때입니다.

이전 결정이 지금 결정을 좌우한다면 아무런 논리가 없는 것이라고 생각합니다.

 

이전에 했던 대로 해도 이상이 없으니 공부하지 않아도 업무에 지장이 없게 됩니다. 게다가 피곤하고 바쁘니 자연히 책에서 멀어집니다.

 

공부하지 않으면 모델러로써 생명력은 짧아집니다.

화려한 언변이나 사교성으로 롱런하기도 하지만 실력이 떨어지면 표가 납니다.

 

모델러가 되기 위해 노력했던 초심으로 계속 정진했으면 합니다.

 

그저 이전처럼만 하는 사람은 진화할 수 없습니다.


'일상 Story > 일상' 카테고리의 다른 글

무엇을 하며 죽음을 준비할 것인가?  (3) 2012.03.04
2012년 1월 1일입니다  (2) 2012.01.01
책을 읽지 않는 사람들에게  (0) 2011.09.22
아인슈타인이 출제한 문제  (1) 2011.09.18
책을 읽지 않는 아이  (0) 2011.06.01
1995년 황당 에피소드  (4) 2011.04.09
블로그 이미지

블루퍼필

댓글을 달아 주세요

오늘은 모델러인 저에게 영향을 미친 사람들을 소개하려 합니다.

 

연대순으로 소개해드리겠습니다.

 

제가 일을 시작한 건 99년이고요.

HTML만 조금 알 때 운명적으로(?) 엑세스를 다루게 됐습니다.

곧바로 SQL Sever에 관심을 가지게 됐고요.

 

데이터베이스가 신기했고 동시에 데이터가 핵심이라는 것을 직감하고 주 분야로 정했습니다.

 

99년부터 정규화에 관심이 많았고요.

외국 사이트나 원서에서 조금씩 도움을 받았습니다.

 

그러다 2002년이었던 거 같은데요.

수원으로 출퇴근하게 됐는데 버스에서 읽은 책이 있습니다.

 

-손호성, Practical Database Design, 삼각형프레스

 

책을 읽으면 공감하는 내용과 그렇지 않은 내용이 있을텐데, 공감하는 부분이 평소 중요하게 생각하는 부분이면 생각이 통한다는 느낌을 받게 됩니다.

 

이 책은 저와 생각이 통하는 책이었어요.

물론 다른 생각이 더 많았지만 생각이 통한다는 느낌을 받았던 책입니다.

저를 생각하게 만든 책이었습니다(어떤 책은 생각조차 하기 싫게 만드는 책이 있는데요).

 

저자에 대한 정보는 지금까지 전무하지만 그 후로도 여러 번 읽었어요.

읽을 때마다 첫인상이 남아 있는 책이라 소개해드립니다.

 

그다음으로 소개해드릴 분은 숭실대학교 최용락 교수님입니다.

2003년 제가 정보과학대학원을 다닐 때 강의를 들어서 알게 됐습니다.

 

정말 열정적인 강의를 하십니다.

위트도 넘치시고요.

자유와 여유가 느껴져 좋았습니다.

 

제 책을 보내드리고 싶은 분 중 한분인데 그러질 못했어요.

교수님도 2010년에 모델링 책을 내셨고... 용기가 없었던 거 같아요.

 

2010년 책은 전에 쓰신 책에 내용을 추가한 책입니다.

튜닝 등 물리 관련 내용이 많은 책이고요.

데이터베이스와 관련된 다양한 지식을 얻을 수 있는 책입니다.

 

-최용락, 데이터 모델링 실무 사례, 문운당

 

다음 분은 엔코아 이화식 대표님입니다.

2005년 즈음에 교육(엔코아교육센터)을 받았는데 인상적이었어요.

데이터 아키텍처 솔루션 책을 몇 번 본 거 같습니다.

 

-이화식, 데이터 아키텍처 솔루션, 엔코아컨설팅

 

얼마전까지 모델링 책 소개해달라고 하면 1순위로 소개했던 책입니다.

물론 지금은 제 책입니다. ㅎㅎ

 

마지막 분은 오픈메이드컨설팅 최영철 사장님입니다.

역시 강의가 열정적입니다.

기업에서 2~3시간 정도의 강의를 주로 하셔서 상위 개념 위주로 설명하시는데 강추입니다.

 

특별히 정보공학 방법론에 밝으시고요.

현실적인 맥을 잘 짚으시고요.

경험 못지 않은 많은 사고를 하셔서 직관력이 뛰어나다고 생각합니다.


책을 내시긴 어려운 상황이라 쓰신 책은 없고요.

가끔 듣는 강의와 평소의 대화로 교감을 하고 있습니다.

 

대표적인 분만 소개드렸는데요.

 

가장 중요한 영향은 스스로 하는 사고인 거 같습니다.

어떤 강의든, 어떤 책이든 사고를 많이 해야 합니다.

사고를 많이 하면 일정한 길이 보인다고 생각합니다.

 

많이 읽고 많이 생각하세요.


블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 혈기린 2011.06.10 08:58  댓글주소  수정/삭제  댓글쓰기

    저도 이화식씨 강의를 듣고 모델링에 눈을뜨고 정말 어렵고도 힘들고 책임이 막중한 일이란걸 깨달았습니다. ㅎㅎ
    김기창님 책을 보고 그동안 헤매거나 잘못알고있던것을 많이 알게 되었죠 다시한번 감사 드려요 ^^
    기회가 닿으면 오픈메이드 사장님 강의도 듣고 싶어지네요 회사에 교육사업은 없나 보죠?

  • 소라소라 2011.06.10 11:10  댓글주소  수정/삭제  댓글쓰기

    좋은글 잘 읽었습니다~ 저자님의 책도 이번주면 다 읽을것 같네요 ^^*
    책을 읽다보면서 공감하는 내용이 어찌나 많던지 참 즐겁게 읽었던 것 같습니다.
    이제 저도 모델링 책을 소개해 달라고 하면 꼭 추천드리고 싶네요 !!!
    앞으로도 좋은글 많이 부탁드리구요, 세미나나 스터디등의 기회가 되면 한번 뵙고싶네요..ㅎㅎ 좋은 하루 되세요!!!

  • 나우리너 2011.06.10 11:19  댓글주소  수정/삭제  댓글쓰기

    회사 직원이 사둔 책을 읽기 시작했습니다.
    현재 프롤로그만 본 상태인데도 책의 내용이 기대가 될 정도로
    글을 재미있게 쓰시는것 같습니다.
    아니다 다를까, 블로그에 들어와서 보니, 재미없다면 재미없을 수 있는 모델링에 대해서
    재미있게 풀어나가시네요.
    그럼 책 열심히 읽고 syncclip에 올리도록 하겠습니다~!

    • 블루퍼필 2011.06.10 22:17 신고  댓글주소  수정/삭제

      감사합니다.
      글을 재미있게 쓴다는 건 찬사인데요.. 지금 순간에는 모델링 잘한다는 것보다 더 듣기 좋은데요.

      근데 블로그는 그럴려고 약간 노력했는데, 책은 다릅니다. 가능한 건조하게 썼습니다. ㅎㅎ
      그래도 찬찬히 읽어보시면 재미는 없어도 도움은 조금이라도 될 거라 생각합니다.

      많이 생각하면서 읽어보세요.
      자주 뵙겠습니다.

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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


블로그 이미지

블루퍼필

댓글을 달아 주세요

아시안컵이 아쉽게 끝났습니다. 인도전에서 한 골만 더 넣었어도, 기라드가 1번 키커였다면 하는 아쉬움이 있네요. 오늘은 축구와 약간 연관된 글을 쓰려고 합니다.

 

모델러로서 많이 보아온 시스템 구축 프로젝트에 대한 얘기인데요. 특히 차세대와 같은 대형 프로젝트에서의 모델러 역할이 포함된 개인적인 의견입니다.

 

축구에서 사용하는 전술은 여러 가지가 있는데 그 중에 대표적인 것이 4-4-2 포메이션입니다(지금은 좀 구식이 됐지만요). 4-4-2 포메이션에서 2에 해당하는 것이 투톱입니다. 다들 아시겠지만 공격수입니다. 빅선수와 스몰선수의 조합이 최상이라고 하는데요.

 

최근 차세대 프로젝트에서의 모델러의 역할은 미미하다는 것이 제 생각입니다. 물론 이전보다는 모델러에게 나름 역할을 부여하고 있습니다. 5년 전만 해도 전문 모델러가 투입되는 프로젝트는 드물었던 거 같아요.

 

하지만 최근에 데이터에 대한 관심이 매우 높아졌습니다. 이제는 주먹구구식으로 데이터 모델링을 할 수 없을 정도로 분위기가 형성돼 제대로 데이터 모델을 구축하려고 시도합니다. 여전히 생생내기 용으로 진행되는 경향이 있지만요…

 

어쨌든 최근 차세대는 전문 모델러가 투입되어 분석설계 단계에서 모델링을 직접 수행하거나 가이드를 합니다. 그리고 개발이 본격적으로 시작될 즈음에 철수하게 됩니다.

 

그런데 전문 모델러가 관여하는 것은 바람직한 현상인데 중간까지만 관여한다는 것이 문제입니다. 개발하면서 바뀌는 부분이 많을수록 문제는 커지게 됩니다. 모델러의 원칙(사상)이 단절되니 모델이 흔들리게 되기도 하고, 허둥대기도 하고... 모델을 가장 잘 아는 모델러가 없다는 것은 어쨌든 문제입니다.

 

차세대 프로젝트를 경험하면서 모델러로써 느낀 이런 문제를 해결한 것이 4-4-2 포메이션입니다. 핵심은 모델러가 프로젝트 끝까지 남아서(비용 문제 발생) 개발을 효율적으로 하자는(비용 절감) 것입니다.


 

[그림1]

 

위의 그림과 같이 a 분석설계자와 a 모델러가 투톱입니다. 투톱이 프로세스와 데이터를 담당합니다. a 분석설계자는 해당 업무 전체에 대한 분석설계와 일정 관리, 데이터 모델을 리뷰합니다. a 분석설계자는 업무 전문가에 가깝고 a 모델러는 데이터 전문가입니다.

 

투톱은 업무와 데이터 모델링을 항상 상호 검증하면서 데이터 모델이 모든 업무를 반영하고 있는지를 리뷰합니다. 축구의 투톱이 빅선수와 스몰선수의 조합이 최상이듯이 성격이 다른 분석설계자와 모델러의 조합은 시너지 효과가 있습니다. 현재 대부분의 프로젝트에서는 단절이 많이 돼 있습니다. 그 원인 중에 하나는 모델러의 이른 철수입니다. 이른 철수(비용 절감 목적)와 늦은 오픈(비용 추가)은 유관합니다.

 

미드필더 자리의 b 분석설계자는 서브 업무를 상세 분석설계합니다. 주된 산출물은 화면정의서가 될 것입니다. 포백 위치의 c 개발자는 상세 업무를 개발합니다. c 개발자는 화면이 도출되고 모델이 완료된 즈음에 투입되기 때문에 비용 절감 효과가 있습니다. 때에 따라서 b 분석설계자도 늦게 투입될 수 있습니다.

 

비용 절감 효과는 아시겠지만 일부 인력을 늦게 투입시켜서 얻는 것 보다는 개발 후 변경 타스크(?)를 없애면서 얻게 됩니다. 투톱인 분석설계자와 모델러가 업무와 모델을 꿰차고 상호 검증한다면, 개발해보고 변경해보는 반복되는 일, 소위 닭짓이 현저히 줄어들어 비용이 절감됩니다.

 

서브 업무에서 중요한 어플리케이션은 b 분석설계자가 개발합니다. b 분석설계자는 화면정의서를 작성하고 설계한 기능 중에 주요 기능을 개발하고 개발된 어플리케이션을 단위 테스트합니다. 해당 업무를 통합 테스트하는 것은 투톱이 하게 됩니다.

 

a 모델러는 프로젝트 전체 기간 중에 다음과 같은 일을 주로 하게 됩니다.

 

- 데이터 모델(논리/물리) 구축

- 매핑정의서(테이블/코드/컬럼). 컬럼매핑정의서는 asis기준과 tobe기준 둘 다 작성

- 튜닝 요소 점검 및 검토

 

현재 차세대 프로젝트에서도 위와 유사한 R&R이 있지만 모델러의 R&R과는 차이가 납니다. 프로젝트 단계대로 분석/설계 기간에만 역할을 하고 빠지는 것이 아니라 개발/테스트 기간에도 역할을 해야 합니다.

 

투톱은 혼합되기 어려워 보이지만 융합한다면 시너지 효과가 클 것입니다. 투톱은 기본적으로 소속이 다른 것이 좋습니다. 서로 견제하면서 협업해야 하기 때문이고요. 여러 업무별로 존재하는 모델러는 소속이 같은 것이 좋습니다. 표준화나 모델링 전략 등을 통일시키려면 같은 팀이어야 할 것입니다.

 

업무 규모에 따라 4-4-2 3-3-2 같이 축소될 수도 있고, 8-4-2, 6-3-2와 같이 삼각형 구조가 될 수도 있습니다. 어떤 경우에도 투톱은 필요하며 역할은 비슷합니다.

 

4-4-2 포메이션과 같은 전술의 특징은 분업입니다. 능력이 뛰어난 선수는 여기 저기 포함될 수 있지만 기본적으로 선수의 장점은 고유한 자리에서 극대화되기 마련입니다. 시스템 구축 프로젝트 인력 구성도 전문성이 중요합니다. 데이터 전문가, 업무 분석 전문가, 개발 전문가 등이 자신의 역량을 최대한 발휘할 수 있도록 해야 합니다.

 

비용을 절감한다는 명목 하에 모델러의 프로젝트 투입·잔류를 망설이고 있지만 결국은 비용이 증가하게 된다는 것은 사실입니다. 4-4-2 포메이션을 시도해 보면 왜 비용이 절감되는지 알 수 있다고 생각합니다.


아직은 SI 인식이 코딩베이스(Coding-Base)라 헤게모니가 AP 개발쪽에 있지만, 머지 않아 데이터와 동등해질 것이고 데이터의 가치를 아는 사람들이 제 역할을 할 때가 올 것입니다.




블로그 이미지

블루퍼필

댓글을 달아 주세요

이전 글에서 사명감이 없는 모델러는 좋은 모델러가 아니라고 했습니다.

하지만 시간이 절대적으로 부족하면 분석을 제대로 할 수 없기 때문에 사명을 가지고 의욕적으로 모델링을 수행할 수 없습니다.

 

최근의 대형 프로젝트에서 모델러의 역할을 제대로 할 수 없을 정도로 자원(인력과 시간)이 주어지는 것은 안타까운 일입니다.

 

이런 프로젝트에서는 모델러가 보통 두 가지 정도의 역할을 해야 한다고 생각합니다. 하나는 프로젝트 초반을 주도하며 끌고가는 선봉대와 같은 역할입니다.

 

업무에 대한 충분한 분석은 말 할 것도 없고 데이터에 대한 충분한 분석 없이 모델링을 수행하면서 산출물을 만들고 다른 사람들한테 데이터와 관련된 자료를 제공합니다.

 

상향식(Bottom-Up) 방법으로 모델링을 수행하면 충분하게 분석하지 않고도 제공할만한 모델이 나올 수 있습니다. 바람직하지 않지만 어쩔 수 없을 때가 있습니다.

 

두 번째 역할은 데이터 구조를 잡는 것이고 중복 속성을 제거하는 것입니다. 속성 하나 하나를 분석할 시간이 없기 때문에 데이터 구조만 잘 잡아도 모델러의 역할은 충분히 한 것이 됩니다.

 

물론 데이터 구조를 잡는 것은 쉬운 일은 아닙니다. 데이터에 대한 분석력과 관계형 모델링 이론을 모르고서는 할 수 없는 일입니다.

따라서 데이터 구조를 제대로 잡고 중복 데이터까지 제거한다면 성공적이라고 생각합니다.

 

현실적으로 자원이 부족하다면 데이터 구조에 집중하는 것이 바람직합니다. 데이터 구조야말로 모델링을 하면서 포기할 수 없는 중요한 부분이며 모델러가 해야 할 역할입니다. 뼈대가 튼튼하며 확장성이 좋은 모델을 구축하는 모델러가 좋은 모델러입니다.

블로그 이미지

블루퍼필

Tag 모델러

댓글을 달아 주세요