김기창의 데이터 모델링 강의(23회)

데이터 모델러에 대한 사색(상): 데이터 모델러와 프로 기사

[필자 소개]
김기창은 데이터 분야에서 15년 이상 일하고 있으며, 현재는 위즈덤마인드 (www.wisdom-mind.co.kr)의 대표 컨설턴트로서 데이터 모델링(Data Modeling)과 DA(Data Architecture) 컨설팅을 하고 있다. 특별히 풍부한 실전을 바탕으로 데이터 모델링을 직접 수행하며, 실무에 적절한 DA 컨설팅을 하는 것이 강점이다. 저서로는 [데이터베이스 활용을 위한 SQL Server 2000], [관계형 데이터 모델링 프리미엄 가이드], [관계형 데이터 모델링 노트]가 있으며, 역서로는 [데이터 모델링 리소스 북]이 있다. 2007년에는 [전사적 데이터 아키텍처 프레임웍에 대한 개념 모델 개발] 논문을 발표했다. 모델러가 기업에게 제공할 최고의 가치는 좋은 모델을 제공하는 것이라고 생각하고 있다. 소명을 갖고 많은 기업에서 진짜 모델이 운영되는 것을 꿈꾸고 있으며, 그런 모델을 설계하는 진짜 모델러가 많아질 수 있도록 노력하고 있다.

어느덧 강의 마무리 단계에 이르렀습니다. 데이터 모델러에 대한 사색을 2회에 걸쳐 소개하고 이 강의를 마무리할까 합니다. 사실 처음에 강의를 연재하기 전에 이번 강의를 1강으로 소개할 것을 고민했었습니다. 모델링에 대한 강의를 시작하기 전에 모델링을 업으로 하는 데이터 모델러를 먼저 소개하는 게 순서일 거 같다는 생각에서였지요. 하지만 이번 강의를 읽어보면 아시겠지만, 다분히 제 주관적인 생각이 포함돼 있습니다. 이번 강의를 가장 마지막에 소개하기로 결정한 이유입니다.


‘어떻게 하면 모델러가 될 수 있는지요’ 제가 많이 듣는 질문 중에 하나입니다. 난감한 질문입니다. 그래서 ‘수학을 잘 하냐’, ‘바둑을 좋아하냐’ 등 동문서답을 하게 됩니다. 10강에서 설명한 적이 있지만 바둑과 모델링은 닮은 점이 많습니다. 책이나 다른 강의에서 자주 언급한 내용입니다.

바둑과 모델링

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


제가 졸업할 때 4급 정도를 두었는데요. 방황을 하던 때라서 바둑보다는 농구를 더 많이 한 탓에 바둑 실력이 좋지 않았습니다. 선배들처럼 1~2급까지 갔으면 좋았을 텐데요. 약간 후회가 됩니다. 그래도 농구와 바둑 때문에 학점이 엉망이 된 것에는 후회가 없습니다.


입학하고 처음 동호회 방에 갔을 때, 한 선배가 기력 테스트를 한다고 불러 앉혔습니다. 몇 마디 물어보더니 9점을 깔라고 하는 겁니다. 주변에서 별로 져 본 적이 없어서 깜짝 놀랐습니다. 제가 상대방에게 9점을 깔라고 하는 경우가 많았던 때라 더욱 그랬죠.


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


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


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


데이터 모델러도 프로 기사만큼 큰 차이가 난다고 생각합니다. 관계를 잘 파악하는 모델러, 통합을 잘 하는 모델러, 정규화를 잘 하는 모델러 등도 뛰어난 모델러이지만, 엔터티를 제대로 도출하는 모델러가 가장 뛰어난 모델러라고 생각합니다. 엔터티를 어떻게 도출하느냐에 따라 모델러의 차이가 커집니다. 엔터티를 잘 도출하는, 전성기의 이창호와 같은 모델러를 목표로 공부하시길 바랍니다.


바둑은 정석(定石)을 기반으로 두어집니다. 정석을 무시하고 두는 프로기사는 없을 것입니다. 간혹 한 수씩 비틀기는 하지만, 상대를 흔들기 위한 응용일 뿐이지 근저에는 정석이 있습니다.


정석대로 잘 두지 않는 프로기사가 있는데, 제 기억에 요다라는 일본 기사가 창의적인 바둑을 두었던 거 같아요. 외모와도 어울려서 나름 멋있었지만, 성적은 이창호 등에 비할 바가 못되었습니다. 정석만의 문제는 아니지만 정석의 영향을 무시할 수 없다고 생각합니다.


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


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


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


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

좋은 데이터 모델러가 되기 위해서는

그럼 좋은 모델을 설계하는 좋은 모델러는 어떻게 하면 될 수 있을까요


무엇보다 모델링 이론을 완전하게 익혀야 합니다. 함수 종속을 기반으로 한 정규화는 필수 이론입니다. 데이터 통합과 관계 도출, 변경 이력 설계 등의 이론도 정확히 습득해야 합니다.
무엇보다 엔터티를 정의(도출)하는 힘이 중요합니다. 이 능력이 모델러의 수준을 가름하는 요소라고 생각합니다. 프로기사 사이에도 승률 차이가 70~80%까지 날 수 있는데요. 모델러도 마찬가지입니다. 데이터를 보고 엔터티를 정확하게 정의할 수 있다면 다른 이론이 부족해도 좋은 모델러가 될 수 있습니다.


반면에 다른 이론은 모두 뛰어난데, 엔터티를 제대로 정의하지 못하는 모델러가 있습니다. 아무리 연습해도 엔터티 도출 능력이 나아지지 않습니다. 이런 경험 때문에 개인적인 생각에는 데이터를 정의하는 것은 생각하는 방식과 연관돼 있는, 타고난 것이 아닌가 하는 생각을 하게 됩니다.

물론 엔터티를 정확하게 도출하지 못하더라도 다른 부분을 잘 한다면 모델러로 충분히고, 제대로 정의해야 하는 엔터티는 소수이기 때문입니다. 또한 엔터티가 조금 잘못 정의돼도 다른 부분이 명확하면 사용할 수는 있습니다. 모델링 자체를 안 한, 대강의 테이블을 사용하는 대다수의 시스템과는 비교가 되지 않죠.


두 번째로 강조하고 싶은 것은 분석력입니다. 하향식 모델링 방법을 사용한다면 주로 화면을 보고 설계를 할 것입니다. 이는 명확하게 보이는 것이기 때문에 분석하기 수월합니다. 모든 사람이 다 같은 방식으로 이해할 수 있어 서로 논의하기도 쉽습니다.


하지만 최근에는 하향식 모델링 방법을 사용하지 않고 대개 상향식 모델링 방법을 사용합니다. 제대로 관리하고 있는 시스템이라면 ERD를 보고 분석해야 하고요. 대부분을 차지할 ERD조차 없는 시스템이라면 테이블 스키마를 보고 분석해야 합니다.


ERD든 스키마든 제대로 분석하기 위해서는 데이터까지 분석해야 합니다. 하지만 현행 데이터가 제대로 설계된 ERD에 저장된 데이터가 아니기 때문에 분석하기 여간 어려운 것이 아닙니다. 가끔 암호를 분석하는 느낌이 들 때가 많습니다. 어려운 분석은 맞췄을 때는 희열을 느끼기까지 합니다.
현행 시스템이 있는 상황에서 데이터 분석력은 모델러에게 필수적인 요소입니다. 물론 이 분석은 모델링 이론에 기반한 분석입니다. 모델 설계 없이 데이터만 저장한 상태를 보고 이해하는 것은 분석이 아닙니다. 어떤 부분 때문에 데이터 정합성이 깨지고, 데이터 간의 무결성이 깨졌는지 모델링 이론을 기반으로 분석해야 하는 것이죠.


어떻게 하면 분석력을 키울 수 있냐는 질문도 자주 받습니다. 이론을 꿰고 있어야 하며, 속성에 저장된 데이터 값 하나도 숙고해서 분석하다보면 데이터 분석력이 향상될 거 같습니다. 일반적으로는 논리적인 책을 많이 읽으면 분석력이 향상된다고 생각합니다. 아래에서도 언급할 것이지만 책을 많이 읽는 것은 컨설턴트의 기본이라고 생각하는 부분입니다.


모델링 이론과 분석력은 좋은 모델러가 되기 위한 필수 조건이라고 생각합니다. 물론 직접연관된 것만을 의미하는 것이고, 예를 들어 대인관계나 발표력 등은 기본이라고 가정하는 것입니다. 노력했는데도 불구하고 모델링 이론과 분석력 중 어느 한 가지라도 많이 부족하다면 고단한 모델러의 길을 가야 할 거 같습니다.

인덱스

필수적이지는 않지만, 능숙했으면 하는 게 있습니다. RDB를 잘 알았으면 하는 것입니다. 종류는 무관하지만 그래도 오라클에 능숙한 것이 좋습니다. 특히 인덱스는 제대로 알았으면 좋겠습니다. 튜닝을 전문적으로 할 정도는 아니더라도 인덱스를 알아야 성능을 고려한 설계를 할 수 있습니다. 자연히 SQL 작성 능력도 기본 이상이면 좋을 것입니다.

튜닝

가능하다면 튜닝을 할 수 있다면 좋습니다. 간혹 모델러에게 튜닝 능력을 지나치게 강조해서 튜닝을 잘 하면 모델링을 잘 하는 것으로 오해하기도 하는데, 사실 튜닝을 전혀 몰라도 모델링을 할 수 있습니다. 중복, 추출 속성 등을 사용하는 비정규화는 튜닝을 모르고도 할 수 있기 때문입니다.
그래도 모델러가 튜닝을 할 수 있으면 여러모로 유리합니다. 성능 문제를 대처할 때 자신감이 있을 것이고요. 개발자를 설득할 때도 유용합니다.

업무 지식

업무를 알아야 한다는 의견도 많은데요. 이에 대해서는 더 자세히 소개할 기회가 있겠지만, 간단하게 설명하면 업무를 모르고도 모델링을 하는 데는 지장이 없습니다. 개발과 다르게 업무에 대한 깊은 이해가 없어도 모델링은 가능합니다. 데이터를 분석하는 과정에서 모델을 설계할 정도의 업무 지식은 알 수 있게 됩니다.


업무와 연관돼 한 가지만 언급하고 넘어가겠습니다. 업무를 지나치게 강조해서 모델러를 선택할 때 업무에 대한 경험을 우선으로 하는 경우가 많은데요. 이는 결국 업무를 잘 아는 개발자를 선택하는 결과를 낳게 됩니다. 테이블, 관계 등은 웬만한 개발자도 대강은 알고 있기 때문에 업무를 잘 알면 모델링을 하는 데 지장이 없다고 생각하기 때문인데요. 이는 오목 고수가 바둑을 잘 둔다고 생각하는 것과 마찬가지입니다.


기업 실무자들이 모델링에 대한 이해가 부족한 게 현실입니다. 모델링 자체도 깊이 알 수 없고, 모델링이 잘못 됐을 때의 폐단도 알기 힘듭니다. 이 글을 통해 모델링은 전문 모델러에게 맡겨달라고 부탁하고 싶습니다.

의사소통 능력

그밖에 설득하는 능력이 필요합니다. IT 종사자들이 대체로 논리적이기 때문에 논리력이 없다면 상대를 설득하기 힘듭니다. 발표력도 중요합니다. 어쩌다 강의도 열심히 하게 됐지만, 저로서는 멋지게 발표하는 능력을 가진 분들이 부럽습니다.
의사소통 능력도 모델러에게 필요합니다. 많은 인터뷰와 리뷰 과정을 거치기 때문에 상대의 말을 잘 이해하고 상대를 잘 이해시키는 것은 중요합니다. 의외로 이 부분이 많이 부족해서 모델러를 못하는 경우도 볼 수 있습니다.


위와 같은 능력은 모델러가 아니라도 도움이 되는 것들인데요. 엑셀을 잘 다루는 것, PPT 문서를 잘 작성하는 것 등도 매우 도움이 됩니다. 실제로 모델링은 CASE 툴과 엑셀을 사용해서 수행하기 때문에 엑셀을 잘 사용하면 실질적인 도움이 됩니다. 발표를 많이 해야 하고, 모델링이 컨설팅에 속하기도 하기 때문에 PPT 문서를 잘 만들면 좋습니다.


좋은 모델러가 되기 위해 갖추어야 할 것들이 너무 많네요. 하지만 모델링 이론을 빼고는 전부 필수적으로 갖춰야 되는 것은 아닙니다. 마지막으로 가장 중요한 것을 언급하고 다음 주제로 넘어가겠습니다. 모델러는 좋은 모델을 설계하겠다는 사명감이 있어야 합니다. 더 이상 덧붙여 말 할 게 없을 정도로 중요한 요소입니다.

전문 모델러가 되는 과정

어떻게 하면 전문 모델러가 될 수 있느냐는 질문에 대해 간단하게 답변한다면, 모델링 이론을 익히면 전문 모델러가 될 수 있다고 하겠습니다. 위에서도 몇 차례 강조한 것이지만 모델링 이론을 모르고서는 다른 모든 것을 갖췄어도 모델러가 될 수 없습니다. 단언할 수 있습니다.
따라서 모델러가 되려면 우선 모델링 이론을 제대로 익혀야 합니다. 현재 자신의 위치에서 모델링을 꾸준히 공부하면 됩니다. 이 글을 읽는 대부분의 독자는 개발자, 튜너, DBA 등 연관 업무에 종사하고 있기 때문에 모델링 공부를 하는 것은 마음먹기에 달려 있을 것입니다.


이 부분이 안 되면 모델러가 될 수 없지만, 모델링 이론을 섭렵했다고 모델러가 될 수 있는 것은 아닌 게 현실입니다. 흔히 모델러로의 진입장벽이 높다고 합니다. 경험이 없으면 모델러로 일하기 힘들기 때문입니다.
모델러의 진입장벽이 높지만 방법이 없지 않습니다. 이번 강의에서 모델러가 될 수 있는 몇 가지 과정을 소개할 것입니다. 제가 권장하는 방법은 간단합니다. 개발자로 일하면서 모델링과 연관된 일을 병행하는 것입니다.


예를 들면, 개발이 주된 업무이지만 자신이 맡은 분야의 엔터티를 설계한다는지, 모델러가 존재한다면 속성 표준화를 포함한 모델 초안을 설계해서 모델러와 논의한다든지 하는 것입니다.
이런 식으로 일을 하면 모델링 이론도 익힐 수 있으며, 경험도 할 수 있게 됩니다. 모델러의 역할은 아니더라도 모델링 업무도 한 것이 됩니다. 이렇게 자신이 속한 조직 내에서 DB가 부 업무가 되도록 하는 게 중요합니다.


물론 개발 업무가 대부분일 테니 DB 분야는 개인적으로 꾸준히 공부해야 합니다. 오라클에 대한 공부, 모델링 이론에 대한 공부를 지속적으로 하면 기회가 주어졌을 때 바로 적용할 수 있습니다.
개발 경험을 하는 것은 모델러에게 도움이 되기 때문에 저는 모델러가 목표처음부터 모델러를 하기는 힘들기 때문에 개발을 하면서 모델러로 전환하는 것은 좋은 방법입니다.


많은 사람들이 결국 이런 비슷한 과정을 거쳐서 모델러로 일하고 있습니다. 개발을 하면서도 DB 분야에 대한 공부를 끊임 없이 하면서 기회를 기다리고요. 기회가 오면 과감하게 전향해서 모델러의 경력을 쌓는 것입니다.
개발자가 아니더라도 모델러로 되는 방법이 있습니다. 데이터 표준화를 수행하거나 메타 시스템을 운영하는 등의 데이터 아키텍트(DA) 역할을 하면 모델러로 전환하기 수월합니다.


가장 흔한 방법 중의 하나는 DB 관련 업무를 하다가 모델러로 전환하는 경우입니다. DBA나 튜너를 하는 경우가 대표적입니다. DBA를 하더라도 설치나 백업 등의 엔지니어링 업무가 아니라 테이블 관리, 프로시저 개발 등의 업무를 하는 게 유리합니다.
마지막으로 매우 드물지만, 처음부터 초보 모델러로서 일을 하는 것입니다. 모델링에 대한 경험이 없다면 진입할 수 없을 테지만 간혹 초보 모델러를 필요로 하는 프로젝트가 있을 수도 있습니다. 프로젝트에서 보조 역할을 할 신입 사원이 필요한 경우가 있습니다.


사실 모델러가 된 후가 더 중요합니다. 모델러가 된 후에는 모델링에 대한 노력을 멈추는 경우를 주변에서 많이 보는데요. 이전에 하던 대로 일해도 크게 문제가 없기 때문에 어떻게 보면 노력을 하지 않아도 일하는 데 지장이 없을 수도 있습니다. 물론 고객에게 최고의 서비스는 제공하지 못하고, 최고의 모델러가 될 수는 없을 테지만요.
주변 모델러에게 강조하는 것은 모델러가 된 후에, 모델러가 되기 전의 간절함을 지속적으로 유지하라는 것입니다. 여유로운 간절함을 간직한 채 경험을 쌓아간다면 전문 모델러, 나아가서는 최고의 모델러가 될 수 있습니다. (다음 회에 계속)