DATOR


데이터 모델링 빠름~빠름~ . . . (주)엔코아 신승렬 이사 커버 스토리


coverstory201307.jpg

데이터 모델러는 여러 가지 재능이 필요하다요즘에는 필요한 능력 중에서 속도전이 매우 중요함을 실감하고 있다

 

어느 선전 문구에서 빠름 ~ 빠름을 강조하고 있듯이 데이터 관련 작업들에는 빠름이 필요한 상황이 많이 있다.  '빠름'하면 언뜻 떠오르는 데이터 분야가 SQL 튜닝일 것이다몇 초를 줄이기 위해서 다양한 DB기법, 인덱스, SQL 사용이 적용된다. 가끔은 SQL을 작성하거나 프로그램을 작성 할 때도 1인당 작업해야 할 본 수에 따라서 1일에 몇 개의 프로그램을 작성해야 하는 경우가 있다데이터 마이그레이션 작업 시에도 기계적으로 타이핑 하듯이 알고리즘이 떠오름과 동시에 이행 로직을 작성해야만 제한된 기간 내에 이행 소스를 모두 작성할 수가 있다.

 

마찬가지로 데이터 모델링 와중에도 빠름은 강조되곤 한다.

 

개인적으로 하루에 분석 가능한 엔티티(테이블) 2~3개로 산정하고 있다. 1 20일이면 40 ~ 60개 정도 분석 가능하다물론 복잡한 테이블은 1개 분석에 몇 일 걸리는 경우도 있으나 평균 3개 정도면 빡빡하게 나마 일정을 준수할 수 있을 것이다.  그 중엔 미사용, 임시 테이블도 섞여 있을 거라고 가정해 둔다또한 ASIS 리버스 분석 이후 논리모델, 물리모델을 진행할 때에도 보통 1일에 2~3개 테이블을 설계 한다고 가정하면 1달에 60개 테이블을 구축 할 수 있다이런 방식으로 계산하면 분석/설계 기간이 4달이라면 1인당 120개 정도의 테이블 분석 및 설계가 가능할 것이다. 여기에 환경 준비, 산출물, 회의, 워크샵 등의 1달을 더 포함하면 충분하지 않을까?

 

그러나 프로젝트 현실은 이보다 더 빠른 결과를 요구하는 것이 일반적이다. 짧은 일정뿐만 아니라 1인당 책임져야 할 테이블이 100개를 훌쩍 넘어서 300, 500개 심지어 1000개 정도되는 사이트들도 가끔은 존재한다

 

빠름을 강조하다 보면 자칫 품질이 저하되는 경우도 발생한다프로젝트의 제일 큰 과업인 납기 준수에 치우치다 보면 제한된 일정에 숫자를 맞추게 되고, 이렇게 되면 데이터 모델의 품질은 생각할 겨를이 없을 수 있다.

 

언젠가 OO프로젝트를 진행할 때, SI PM으로부터 이런 질문을 받은 적이 있다.

 "테이블 설계는 개발자가 직접 할 수 있는데전문 모델러가 투입하면 좀더 빠른 기간 내에 설계가 완료되어야 하는 것 아닌가요?"

  "개발자가 테이블 설계 할 때 1인당 100개 한다면, 전문 모델러는 1인당 300개 정도 담당해야 하는 것 아닌가요?"

나는 웃으면서 답변했다.

  "워드 속도가 독수리 타법이라서 빠르지는 않아요. 하지만 빠르게 처리 할 수 있는 무엇인가가 있지요. 물론 품질까지 보증할 수 있어요."

라고 대답하였다.

 

프로젝트에서는 납기와 품질이 항상 대두되곤 하는데, 이 두 마리 토끼를 모두 잡을 수 있으면 전문가라고 여기고 싶다. 제한된 일정도 지키고 품질 좋은 데이터 모델을 구축하기 위해서는 어떻게 작업해야 할까?

 

함께 일하고 있는 동료 후배가 이렇게 물어본 적이 있다.

 "어떻게 그렇게 빠르게 모델을 마무리 하는 건가요저보다 두 세배 빠른 비법이라도 있나요? "

이 질문을 받고서 나는 제한된 일정에 맞추어 빠르게 모델링 프로젝트를 진행하기 위해서는 무엇이 필요하고, 어떤 것들을 해야 하는지 정리해 보았다. 

 

 

1) 빠른 문서 작성 실력이 때로는 필요하다. 

머리 속에서 번개처럼 지나가는 아이디어나 개념을 놓치지 않고 모델에 녹여내기 위해서는 PPT문서나 XLS문서를 빠르게 작성할 줄 알아야 한다. 여러 가지 과제에 대하여 말로만 의논하는 것이 아니라 PPT를 만들면서 상황을 공유해 나가야 빠른 의사결정을 할 수가 있다.  

 

2) 그룹핑하고 분류하는 능력이 필요하다

수 백 개의 정리 안된 테이블들을 분석할 때 데이터적인 유사점, 공통점을 찾아서 빠르게 카테고리화 해야 한다. 이 능력이 부족하면 범위 조절에 실패 할 수 있고요약이나 상황 보고 시 엉뚱한 수치를 보고 할 수도 있다.

 

3) 테이블은 우선 순위를 잡아서 중요한 테이블에 많은 시간과 노력을 투자해야 한다

아마도 100개 테이블이라면 20개 정도에 50~60%의 시간을 할애 해야 한다. 주요 테이블이란 개체, 계정, 메인 트랜잭션 테이블들 일 것이다. 눈에 띄지 않는 변두리 테이블과 컬럼들에 너무 많은 고민과 시간을 소비하지 말자.

 

4) 모델링 방법론을 통달하고 있어야겠다

테이블 분석과 동시에 TOBE 테이블의 형상이 머리 속에서 자동적으로 그려 질 수 있도록 시간 날 때마다 공부하고 공부하고 또 공부해 두어야 한다데이터 모델 관련 지식이 축척 되어서 넘쳐 흘렀을 때 비로소 빠름의 경지에 한 걸음 가까이 다다를 수 있다.

 

5) 다양한 패턴들의 모델, 혹은 테이블을 기억해 두자. 

프로그램에서 Copy and Paste 하듯이 데이터 모델링에서도 모방이 필요할 때가 많다. 

 

6) 복잡한 업무나 프로그램을 설명 들을 때 개념화하는 습관을 들이자.  

~ 쳐서 큰 그림으로 이해하도록 한다. 이리저리 실타래처럼 엮인 프로그램 로직을 듣다 보면 머리가 멍해 진다. 개발자는 결코 모델러가 원하는 관점에서의 데이터 구조를 이야기 하지 않는 다말하고자 하는 내용을 이미지화 하고 단순화 해 나가는 연습을 해야 한다. 이미지화 한다는 것은 PPT로 상황을 정리한다는 것과 일맥상통한다.

 

7) 빠르고 정확하게 진단하고, 협의하여 결정해야 한다

모델링의 진도를 쭉쭉 빼지 못하는 대부분의 원인은 담당자, 개발자와의 회의 이후 어떤 조치를 취하지 못하여 무한정 대기 상태에 빠지는 경우가 대부분일 것이다. 이는 납기 준수의 가장 큰 적이다의사결정을 빠르고 정확하게 모두가 원하는 방법으로 진행 할 수 있도록 커뮤니케이션을 잘 해내는 것이 모델링 프로젝트에서의 빠름을 보장하는 가장 큰 핵심 문제 인 것 같다또한 전 문 모델러를 투입함으로써 데이터 모델뿐만 아니라 비즈니스, 개발 이슈들 까지도 실타래 풀리듯 자동적으로 해결될 때가 있다.

 

8) 가끔은 옆 동료를 살펴보라  

모델링 툴을 어떻게 조작하는지? 엑셀을 어떤 포맷으로 작성하는지?  PPT 문서를 만들 때 어떤 절차로 작성하는지 살펴보자. 그들만이 가진 노하우와 행동의 습관들을 보고 배우도록 한다.

 

9) 많은 우물을 파야 할 때를 알아 차리자

물을 찾기 위해서 깊게 1개 우물을 팔 것 인가조금 파 보고 물이 안 나오면 다른 장소에서 여러 우물을 파 볼 것인가수직과 수평문제 이다깊게 알 것인가많이 알 것인가?  100여 개의 테이블을 분석하는데 어떨 때는 1개의 꼬이고 꼬인 테이블에 목 메일 때가 있다.  왜 이럴까? 이건 무슨 집합일까? 어디에 쓰는 거지? 에 너무 몰두한 나머지 99개 테이블을 놓쳐버려서는 안 된다복잡한 테이블에 녹아 있는 개념만 파악하고 넘어가고 세부적인 것은 나중에 보완해도 늦지 않는다.  oo원장, oo마스터, oo기본, oo계정 테이블에 있는 수 백 개의 속성들이 무엇을 의미하는지, 어디에서 사용되는지 모두 파악하지 않아도 된다. 지금 내가 달려가고 있는 목적지가 어딘지 잃어버리지 말자데이터 구성과 역할적인 구조만 파악되었다면 skip할 수 있는 것도 빠름의 지혜이다.

 

10) 모델 분석 및 설계 시 1 3시간 정도는 완전 몰입을 한다

옆에서 무슨 일이 발생하는지 아랑곳하지 않고 삼매경에 빠질 수 있는 경지가 되면 3시간 일의 분량이 3일치를 넘어설 때가 있음을 알게 될 것이다.

 

11) 화면 UI를 보자 

모델링 프로젝트에서 업무 담당자와 비즈니스를 논의하면서 모델 분석 및 설계를 하는 것은 하늘의 별 따기인 것 같다특히 재구축, 고도화 프로젝트에서는 문서 서식 조차 제대로 보지 못할 수 있다업무 메뉴얼을 보면 이게 테이블이랑 무슨 상관이람? 이란 생각이 들 정도로 헷갈리기만 한다. 그럴 때는 프로그램 화면을 보라고급 모델러는 대부분 화면에서 테이블의 문제점과 개선점을 쉽게 찾고는 한다화면/프로그램은 개발자의 몫이라는 선입관에서 벗어나서 적극적으로 화면을 보면서 이야기 하라특히 화면에서의 필드명속성,컬럼명  다르게 불리는 것도 찾아서 보정 할 수 있다가능한 속성명과 필드명을 일치시킨다담당자에게 화면 조작법을 배우는 동안 친숙함과 의사소통의 길은 저절로 열릴게 될 것이다그런데 문제는 화면 볼 시간이 없다는 것~~.  빠름을 이미 진행하고 있는 모델러만이 화면 볼 여유와 침착성을 갖게 되는 것 같다 

 

12) 데이터모델(테이블) - 프로그램(화면) - SQL 의 삼각 관계를 이해하자

데이터 모델링은 DB 하나만으로 끝나는 것이 아니다시간 나는 대로 이 셋의 유사성과 관련도를 점검해 보도록 한다품질이 좋은 모델을 설계하는 모델러는 테이블 하나를 만들면서도 화면 UI를 짐작할 수 있고, 프로그램 로직을 예상할 수 있고, 데이터를 Insert 하는 방식과 Select SQL까지도 작성할 줄 알아야 한다. 데이블 분석 시 매우 복잡하여 진도가 나가지 않는다면 프로그램과 SQL을 보고 Data와 어떻게 연동되는지 파악하면 막힌 진도를 헤쳐 나갈 수 있으리라.

 

이것 저것 생각하였던 것을 정리하다 보니 결론적으로는 경험을 많이 깊게 쌓아라라는 것처럼 들린다

매일 매일을 한 수 배운다는 생각으로 조금씩 조금씩 앞으로 나아간다면 누구나 데이터 모델링 시 '빠름'을 실천 할 수 있을 것이다.

 

"매일 매일 조금씩 강해지자"

 

 

Tag :

Leave Comments