태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

현재 EA 관련 프로젝트를 하고 있습니다. 관련 논문도 쓰고, 컨설팅도 여러 번 수행했지만 EA는 여전히 쉽지 않네요. 정해진 게 없어서 그럴 것입니다.

 

오늘은 EA가 무엇인지 중심 잡는 데 도움이 될만한 얘기들을 두서없이 쓰겠습니다.

 

EA는 우선 ISP와 다소 헷갈립니다.

하나는 업무(Business) 위주고 하나는 기술(Technology) 위주인데요.

 

고객측의 참여 주체가 다르다는 게 핵심일 거 같습니다.

ISP는 고객의 업무 현업이 주도적인 역할을 합니다.

반면에 EA는 고객의 IT 현업이 주도적인 역할을 하고요.

물론 핵심 주체가 분명하지 않을 때도 많습니다. 경험상 이럴수록 프로젝트가 힘들어집니다.

 

EA라는 용어를 사용하기 전의 공식 용어가 ITA(Information Technology Architecture)였는데요(ITAEA로 바뀜). 이 용어가 더 와닿습니다. Enterprise 아키텍처는 왠지 모호합니다.

 

EA 타스크는 크게 현행 아키텍처 분석과 향후 아키텍처 구축으로 나눌 수 있습니다.

개인적으로 현행 아키텍처 분석만을 수행하는 것도 좋다고 생각합니다. 이것만 제대로 있어도 위력을 발휘하기 때문인데요. 특히 DA가 그렇습니다.

 

현행 아키텍처 분석 단계에서는 상세한 수준의 현행 실체를 분석해야 합니다. 예를 들어 DA는 테이블을 분석하는 것이죠.

차세대 프로젝트에서 모델링을 하는 것과 크게 다르지 않습니다. 다만 상세화 수준이 다를뿐입니다.

어프리케이션/메뉴, ERD/테이블, 장비/소프트웨어 등 실체를 들여다보고 그대로 그리는 것이 중요합니다.

 

그리고 향후 아키텍처 구축 단계에서는 제안/개선 등 TOBE에 대한 내용이 들어갑니다.

이 제안이나 진단은 근거가 있어야 합니다.

선진사례나 원칙 등의 기준이 있고 그것과 비교해서 어떻게 해야한다는 내용이 있어야 합니다.

근거없이 결론이 나오면 안 되고, 논리의 비약이 있어도 안 됩니다.

여기에 전문가다운 통찰력(Insight)이 근거에 더해져야 합니다.

 

EA에서는 상세한 실체를 들여다보면서도 큰 틀을 유지해야 합니다.

큰 틀을 프레임웍(Framework)이라고 부르는데 DA 프레임웍는 [그림1] 같습니다.

 

요소

Standards

Structures

Interfaces

Manage-

ments

Contextual

Planner

(경영자)

데이터표준화 지침서

주제영역 정의서

업무흐름지침서

DA관리지침서

Conceptual

Owner

(책임자)

모델링지침서

DB표준화지침서

데이터참조모델

  (DRM)

개념모델

데이터흐름지침서

서비스&주제영역관계정의서

DA조직R&R

Logical

Designer

(설계자)

단어정의서

용어정의서

논리모델

업무&엔터티관계정의서

데이터공유정의서

DA프로세스

Physical

Builder

(구축자)

도메인정의서

코드정의서

물리모델

DB스키마정의서

테이블&어플리케이션 관계정의서

데이터품질

System

Enterprise Data Architecture Management System

[그림1] EDADF 프레임웍1)

 

데이터 아키텍처를 수행하려면 위와 같이 표준(Standards)과 구조(Structures), 인터페이스(Interfaces), 관리(Management)라는 큰 틀 내에서 검토해야 합니다. 상세 항목은 변할 수 있지만 어떻게 수행하는지, 어떤 산출물이 나오는지를 알면 혼란은 없을 것입니다. 큰 그림과 결과 그림을 알면 EA를 수행하기 수월합니다.

 

컨설팅 프로젝트는 다양한 참여자들의 다양한 의견 때문에 힘이 드는데 정답이 없는 것도 힘든 요소 중 하나입니다.

모델링도 정답이 없다는 점 때문에 힘들 때가 있지만 EA는 모델링보다 더 추상적이니까요.

수행하기 힘들더라도 중심을 잡고 있는 것과 그렇지 않은 것은 차이가 많이 납니다.

 

개인적으로 EA 프로젝트의 핵심은 주제영역이라고 생각합니다.

EA 프로젝트는 시스템을 구축하기 전 단계라고 볼 수 있습니다.

현행을 분석해서 방향을 정하는 것으로만 끝내기엔 부족하고 차세대 시스템 구축에 사용해야 합니다.

 

차세대 프로젝트에서 초반에 혼란을 겪는 것이 주제영역입니다. EA에서 주제영역만 명확하게 정의하면 이어지는 차세대에서 유용하게 사용할 수 있습니다.

 

그리고 주제영역을 도출하기 위해서는 개념 모델이 필요합니다. 주제영역에는 데이터 통합이 주요 관점이고 이는 개념 모델에서 보일 수 있습니다.

 

EA 프로젝트와 구축 프로젝트는 연속성이 있어야 합니다. 구축 프로젝트에서 이어서 사용할 수 있는 EA 산출물을 만드는 게 바람직합니다.

 

 

1) 김기창, “전사적 데이터 아키텍처 프레임웍에 대한 개념모델 개발”, 2007




블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 정유성 2012.10.15 17:28  댓글주소  수정/삭제  댓글쓰기

    오랜만에 들렀습니다. 새로운 프로젝트를 하고 계시나 봅니다. 작년에 EA관련 공부를 잠깐 하던 때가 생각나네요. 좋은 가을 되시고, 행복한 프로젝트 기간 되세요 ^^

    • 블루퍼필 2012.10.15 23:39 신고  댓글주소  수정/삭제

      감사합니다.

      그런데 행복한 프로젝트가 있을까요... ㅎㅎ
      좀 재밌는 프로젝트는 있지만요..

      많이 읽고 많이 생각하는 행복한 가을 되세요.

  • 허민석 2014.01.28 08:19  댓글주소  수정/삭제  댓글쓰기

    구구절절 옳은 말씀이시네요.

    일전 프로젝트시
    AS-IS EA 현행화 과정이 쉽지 않았으나,
    TO-BE 모델링, 시스템 설계시 무척 도움되었고, 또한 누락없이 잘 마무리 지었습니다.

    하여,

    말씀처럼 주제영역에 대한 중요성과
    AS-IS 현행화는 무척이나 주요한 과정이라 동의에 동의 합니다..^^

돌이켜보면 언제 썼나 하는 생각이 듭니다.

 

출판은 2010 11월이었지만 책을 완성한 건 사실상 6월경이었으니까 1년이 넘었네요.

 

제가 2004년에 생애 처음으로 책을 냈습니다. SQL Server 책인데요.

아마 절판돼서 구하실 수가 없을 거에요. 다행이죠.

 

그때는 SQL Server를 열심히 했고, 멘토였던 정원혁씨보다 더 최고가 될 자신이 있었습니다. 저 혼자서만 라이벌로 생각하던 때였습니다.

 

그런데 1년도 안 돼 오라클로 넘어온 후로 다시 돌아가지 못했습니다.


SQL Server
는 책을 출판하게 만든 고마운 존재입니다.

 

그리고 작년에 두 번째 책을 냈습니다.

 

첫 번째 책은 경력에 보탬이 됐으면 하는 생각밖에 없던 책이었습니다. 멘토에 대응(?)할 생각은 전혀 없었고요.
내용도 별다른 건 없는 요약본이었고 출판 후 관리도 제대로 안 했습니다.

 

두 번째 책에는 몇 가지 의미를 담았습니다.

 

이 책으로 우리나라 최고의 모델러가 돼야겠다고 생각했고요. 당장이 아니라 10~20년 후에라도요.
2030
년에도 읽히도록 예제 연도를 그때쯤으로 썼습니다.

 

그리고 교육과 연관되는데요. 애를 키우다보니 많은 것들이 교육과 연결되네요.

 

주변에서 책을 싫어하고 무시하는 사람들을 보는데 애들이 이런 우를 범하지 않도록 하기 위해, 책을 읽는 아이가 되길 바라는 마음으로 썼습니다.

아빠가 쓴 책이 애들에게 영향을 미칠 거라 믿기 때문에요. 지금은 어리지만 커서라도.

 

금전적인 것은 경험을 해 봐서 기대를 안 했지만 이왕이면... ㅎㅎ

 

의도한 바가 앞으로 어떻게 될지는 알 수 없지만 긍정적으로 생각하고 있습니다.

 

80%는 만족하고 있습니다.

부족한 2%가 만족되면 다시 출판할 생각입니다.

 

사설이 길었네요.

 

보통 서문과 함께 각 장에 대한 간략한 설명, 책을 읽는 방법 등 독자가 읽기 쉽도록 가이드해주는 내용이 나오는데 책만 두껍게 하는 거 같아 생략했습니다.

 

사설이 긴 걸 좋아하지 않아서 뺐지만 도움이 될 수도 있어 블로그에 정리했습니다. 약간의 가이드가 될 것입니다.

 

책의 정식 제목은 『이론과 실무를 겸비한 전략서-관계형 데이터 모델링 프리미엄 가이드』입니다.

 

서문에 밝혔듯이 멋스럽지 않은 촌스러운 제목입니다.

 

하지만 이 책을 대표할 수 있는 단어로 정하는 게 좋을 거라 생각하고 정했습니다.

 

이론, 실무, 전략서, 관계형, 데이터 모델링, 최고의 가이드

 

맨 마지막 단어가 좀 걸리지만 희망할 수는 있으니까요. ㅎㅎ

 

 

01 데이터 모델링에 대한 상념(想念)

 1.1. 데이터 모델링이 왜 어려운가?

 1.2. 데이터 모델링의 매력

 1.3. 모델링은 상식적이다

 1.4. 모델러와 바둑 프로기사

 1.5. 좋은 모델은?

 1.6. 모델링이 왜 필요한가?

 1.7. 좋은 모델러란?

 1.8. 모델링 목표

 

1장은 모델링에 대해 평소에 하던 생각을 자유롭게 썼습니다.

 

바둑을 좋아하시는 분은 모델링이 바둑과 닮았다는 것에 동의하실 것입니다.

 

동네에선 나름 잘 둔다고 자부했는데, 선배에게 9점을 깔고 만방으로 지던 신입생 때가 가끔 생각납니다.

 

바둑은 인생과 닮았다고들 하는데 그럼 모델링이 인생과 닮은 건가요?

 

그건 아닌 거 같아요. 하지만 최소한 논리적으로 살아가는 데 조금은 도움이 될 거 같습니다.

창의력을 키우기엔 부족하지만 보편성과 논리성을 키우기엔 좋다고 생각합니다.

수학과 연관이 많습니다.

 

모델링이 예술과 유사하다는 것은 객관적이지 않은 사실이라 책에는 쓰지 않았지만 저는 그렇게 생각합니다.

 

영감, 통찰(Insight)이라는 게 크게 작용하는 분야입니다. 설명하기 힘든...

 

 

02 데이터 모델링 기본 개념

 2.1. 관계형 데이터 모델링(Relational Data Modeling)

 2.2. 무결성(Integrity)

 2.3. 데이터베이스 라이프 사이클

 2.4. 주제 영역(Subject Area)

 2.5. 데이터 표준화

 2.6. ERD(Entity Relationship Diagram)

 

2장은 모델링과 연관된 내용을 다뤘습니다.

 

관계형 데이터베이스 기반에서 운영되는 모델에 대한 책이라는 걸 강조했고요.

과연 관계형 데이터베이스가 지금 같은 지위를 계속 유지할까요?

 

주제 영역은 책 한 권이 될 정도의 내용인데 간략하게 적었습니다.

 

조만간 데이터 성격 위주의 영역으로 모델링을 할 것이며(현재는 업무 담당자, 즉 사람 위주로 하죠), 데이터 주제 영역 위주로 조직이 정비될 것입니다.

 

제가 조직에 대한 전문가는 아니지만 데이터와 조직은 연관성이 크고, 효과적인 조직은 경영 혁신의 시발점이기 때문입니다.

 

대학원 전공이 지식경영이었는데 제대로 공부하지 않은 걸 후회할 때가 많습니다.

데이터와 지식경영이 연관됐다고 판단하고 선택했는데 소홀히 했습니다.

 

표준화 관련해서는 메타 시스템에 대한 얘기를 많이 하고 싶었지만, 실무에서 모델링 영역과 메타 영역이 어느 정도 구별이 돼 있어 언급을 자제했습니다.

 

현재 대표적인 메타시스템들이 간결하지 않은 것은 언급하고 싶습니다.

 

모델러가 속성 표준화하는 사람이 아니라는 것도 여러 번 강조했습니다.

 

 

03 개념 모델 & 논리 모델 & 물리 모델

 3.1. 개념 모델(Conceptual Model)

 3.2. 논리 모델(Logical Model)

 3.3. 물리 모델(Physical Model)

 

만약 책의 분량이 한정돼 있어 어느 장인가 빼야 했다면 3장이었을 겁니다.

11장과 연관돼 있고, 실무에서 궁금한 부분 중 하나라 포함시켰지만요.

 

개념 모델과 논리 모델, 물리 모델은 상세화 정도가 다른 연결된 모델입니다.

전혀 다른 모델이라고 생각하면 혼란스러울 것입니다.

 

파일 자체를 달리 관리하는 케이스 툴이 있는데, 아마 모델 자체가 다르다고 생각해서인 거 같습니다.

하지만 관리 문제도 있어 하나의 파일로 상세화 정도만 달리해 관리하는 게 효과적이라고 생각합니다.

 

 

04 정규화(Normalization)

 4.1. 정규화(Normalization)?

 4.2. 정규화의 목적

 4.3. 아노말리(Anomaly)

 4.4. 함수 종속(Functional Dependency)

 4.5. 정규형의 종류

 4.6. 정규형과 성능

 

4장 정규화는 데이터 통합을 다룬 5장·6, 이력을 다룬 12, 방법론을 다룬 11장과 함께 제가 가장 신경 쓴 부분입니다.

 

모델링의 꽃은 데이터 통합(Generalization)과 정규화(Normalization)인데요.

그중에 정규화는 관계형 데이터 모델링의 이론 자체입니다.

 

기본이기 때문에 정규화를 모르고서는 관계형 데이터 모델링을 할 수 없습니다.

 

4장은 꼭 읽어볼 것을 권합니다.

 

 

05 데이터 통합(Generalization)

 5.1. 데이터 통합(Generalization)

 5.2. 데이터 통합의 장•단점

 5.3. 엔터티 통합 대상

 5.4. 데이터 오너십

 

5장 데이터 통합과 6장 슈퍼타입·서브타입은 밀접하게 연관돼 있습니다.

 

데이터를 통합하면 슈퍼타입·서브타입이 발생하죠.

행위와 그 결과라고 할까요.

 

정규화에 대해서는 이론에 대한 이견은 거의 없고, 다만 적용 여부에 대한 논란이 많은데요.

데이터 통합은 모델러마다 이견이 생길 수 있는 부분입니다.

모델러에 따라 차이가 많은 부분이기도 하고요.

 

데이터를 어떻게 통합했느냐에 따라 모델은 상당히 달라집니다.

 

물론 데이터 통합이 정규화를 기반으로 이루어져야 하는 것은 당연하고요.

 

정규화가 기반이 되지 않은 통합과, 통합을 위한 통합은 지양해야 합니다.

 

 

06 슈퍼타입(Supertypes)과 서브타입(Subtypes)

 6.1. 슈퍼타입 & 서브타입 정의

 6.2. 슈퍼타입과 서브타입의 사용 방법

 6.3. 서브타입의 종류

 6.4. 서브타입의 물리모델 변환

 

최근에 많은 사람들이 서브타입을 얘기하고 있습니다. 모델러라면 반드시 알아야 하는 내용이고요.

 

6.3장 서브타입의 종류는 많은 모델러가 제대로 모르는 부분입니다.

4가지 종류를 정확히 알아야 서브타입을 제대로 도출할 수 있습니다.

 

정규화와 함께 중요한 장입니다.

 

 

07 엔터티(Entity)

 7.1. 엔터티란?

 7.2. 자립(Independent) 엔터티 & 종속(Dependent) 엔터티

 7.3. 엔터티 종류

 7.4. 엔터티 도출 원칙

 7.5. 엔터티명

 7.6. 엔터티 검증

 

모델링의 3요소는 엔터티, 속성, 관계죠.

이중에 제일은 엔터티입니다.

 

저는 엔터티를 가장 중요하게 생각합니다.

이게 제대로 안 되면 뒷 단계는 한마디로 허당입니다.

 

실전에서 엔터티를 올바르게 도출했느냐는 대체로 표면 아래에 숨어 있습니다.

그래서 언급이 안 되고, 잘 보이는 관계에 치중하는데요.

 

관계는 많이 오해하고 있다는 점에서 오히려 중요하게 강조되고요.

엔터티는 모델링의 기초이며 시발점이고, 제대로 도출하기 힘들다는 점에서 중요합니다.

 

관계를 포함한 다른 요소들을 잘 설계하는 사람은 간혹 보는데, 엔터티를 정확하게 도출하는 사람은 상대적으로 드물게 봅니다.

 

모델러의 진정한 자신감은 엔터티 정의에서 출발합니다.

점점 더 차별화가 생기는 부분이라고 생각합니다.

 

 

08 식별자(Unique Identifier)

 8.1. 업무 식별자(Business Identifiers)?

 8.2. 식별자(UID)/(PK) 종류

 8.3. 주 식별자 선정 원칙

 8.4. 주 식별자 선정 절차

 8.5. 주 식별자 상속

 8.6. PK 제약과 유니크 인덱스

 8.7. 인조 식별자 채번

 8.8. 복잡한 주 식별자

 8.9. 식별자 검증

 

책 전반적으로 강조한 것은 식별자와 엔터티는 별개가 아니라는 겁니다.

식별자는 단지 속성의 한 종류가 아니라 엔터티를 정의하는 중요한 요소입니다.

 

업무 식별자는 확실히 분별할 수 있어야 합니다.

 

업무 식별자를 모든 엔터티에서 도출하기는 힘들 수 있습니다. 하지만 핵심 엔터티는 반드시 업무 식별자를 분석해야 합니다.

 

 

09 속성(Attributes)

 9.1. 속성이란?

 9.2. 속성 종류

 9.3. 도메인(Domain)

 9.4. 복합 속성 & 다가 속성

 9.5. 속성명

 9.6. 코드에 관해서

 9.7. (Null)에 관해서

 9.8. 데이터 타입

 9.9. 속성 검증

 

속성과 연관된 여러 요소들을 포함시켰습니다.

 

9.6장 코드는 별도로 읽어보시면 좋습니다.

 

더 나은 방법을 찾으려고 애쓰지 않고, 이전처럼 하려는 부분 중 하나가 코드 관리입니다.

여러 방법을 시도해 볼만한 가치가 있는 부분입니다.

 

 

10 관계(Relationships)

 10.1. 관계(Relationships)?

 10.2. 관계와 속성 그리고 엔터티

 10.3. 관계 구성 요소

 10.4. 관계 표현

 10.5. 관계 종류

 10.6. 참조 무결성(Referential Integrity)

 10.7. 관계 검증

 

관계는 모델링 시 가장 많이 언급되는 부분입니다.

모든 사람이 관계를 얘기하기 때문에 가장 중요해 보이기도 하고요.

 

하지만 잘못된 엔터티들 사이의 관계가 잘됐는지, 잘못됐는지를 논하는 것은 의미가 없습니다.

일단 엔터티가 올바른지를 논한 후에 관계를 논해야 합니다.

 

관계는 업무에서 필요한 RI 관계가 있는, 1촌 관계만을 도출해야 합니다.

 

두 엔터티 간에는 어떤 식으로든 관계가 있도록 할 수 있습니다. 조인하는 요건이 없더라도 관계를 관리하면 그만이니까요.

다대다 관계라도 대표 관계(인스턴스)만 관리하면 되니까요.

 

두 엔터티를 같이 보려는 요건이 있을 때 관계를 관리하고, 바로 위의 관계만을 관리해야 합니다.

 

 

11 모델링 방법론(Modeling Methodology)

 11.1. 하향식(Top-Down)과 상향식(Bottom-Up)

 11.2. 리버스(Reverse) 모델링

 11.3. 모델링 프로젝트 WBS(Work Breakdown Structure)

 

책의 제목을 결정한 계기로 삼은 장이 11장인데요. 이론과 실무를 겸비한 전략서 부분이요.

 

최근의 프로젝트 WBS 하에서 모델링을 잘 할 수 있는 방법을 설명했습니다.

 

만약에 요구사항 정의서에서 엔터티 후보부터 도출하는, 즉 과거에 많이 하던 정통 모델링 방법을 사용하는 프로젝트라면 리버스 모델링 방법을 적용하기 적절치 않을 수 있습니다.

 

저도 정통 모델링을 좋아하지만 제가 일한 경험으로는 현재 거의 모든 프로젝트에서 리버스 모델링을 사용하는 것이 가장 효율적입니다.

 

따라서 하향식(Top-Down) 방법에 대한 자세한 설명은 생략했습니다.

여러 책에, 문장에서 엔터티 후보를 도출하는 것으로 시작하는 설명이 있습니다.

 

단위 업무가 새로 생기면 문장으로부터 엔터티를 도출하고 관계를 도출해야 할 때가 있으므로 정통 모델링 방법도 연습해야 합니다.

 

아마 프로젝트가 지금처럼 계속 진행돼 상향식만 사용하다 보면 하항식으로는 모델링을 못하는 모델러가 많아질 것 같습니다.

 

 

12 이력관리

 12.1. 이력 데이터란?

 12.2. 선분 이력

 12.3. 이력 엔터티 선정 절차

 12.4. 이력 관리 모델 유형

 12.5. 이력 엔터티의 주 식별자

 12.6. 정정 데이터

 

이력은 제가 오랫동안 연구한 분야입니다.

 

정규화는 다른 사람의 이론을 정리한 것이지만, 이력 관리는 많이 고민하고 제 나름의 방법을 일부 찾은 분야입니다.

나름대로 확고하지만 여전히 아쉬운 분야라 더 연구할 생각입니다.

 

우선 발생하는 데이터인 내역 데이터와 변경되는 데이터인 이력 데이터를 구분하는 것이 중요합니다.

이걸 구분하지 못하면 헷갈리고 겉돌게 됩니다.

 

원천 데이터를 확고히 해야 이력 데이터를 설계할 수 있습니다.

즉 엔터티를 확실히 도출해야 그 변경 데이터에 대한 설계도 튼튼해질 수 있습니다.

 

흔히 목격할 수 있고, 당황스러운 것이 이력 엔터티를 얘기하는데 원천 엔터티 자체가 잘못됐을 때입니다. 어디서부터 얘기해야 될지 난감해집니다.

 

또 난감해지는 게 이력 데이터를 설계할 때 원천 엔터티가 흔들리는 것입니다.

이 역시 원천 엔터티 설계가 잘못됐다는 얘기입니다.

 

 

13 비정규화(Denormalization)

 13.1. 비정규화란?

 13.2. 비정규화 과정

 13.3. 비정규형의 단점

 13.4. 비정규화 방법

 

비정규형을 적재적소에 사용하면 최고의 모델이 될 수 있습니다.

 

실제 성능이 심각하게 문제되는 경우는 많지 않습니다.

오히려 습관적으로 성능 얘기를 할 때가 많은데요.

크게 고생한 과거의 1~2 요건 때문에 전체 요건에 대한 성능 문제로 확대된 경우가 많습니다.

 

성능 문제가 발생했을 때, 데이터 무결성 저해를 최소화하는 범위에서 비정규화를 해야 합니다.

이때 비정규화는 반드시 정규화를 한 후에 이루어져야 하고요.

 

정규화를 안 하고 비정규화 한다는 것은 마치 산의 정상에 올라가지 않고 하산하는 것과 같습니다.

그건 산을 오른 것이 아닌 거와 같이 모델링을 한 것이 아닌 것입니다.

 

비록 결과가 모델링 하기 전과 모델링 한 후가 같다고 할지라도 정상에 오르지 않고 정상에 갔다 왔다고 하는 것은 잘못입니다.

 

이런 문제 때문에 모델러의 도덕성 얘기가 나오게 되죠.

결과적으로 향후(tobe) 모델이 현행(asis) 모델과 유사할 때, 모델러가 얼마나 많은 고민을 하고 일을 했는지는 잘 모릅니다.

 

이런 면에서도 정규화가 모델링의 원칙이 돼야 합니다.

더 이상 삭제할 게 없을 때까지 삭제한 후(정상에 오른 후) 꼭 필요한 걸 추가해야 합니다(하산해야 합니다).

 

 

14 물리적(DBMS) 요소

 14.1. 테이블 타입

 14.2. 파티션

 14.3. 인덱스

 14.4.

 

14장은 별도로 책 한권으로 쓸 정도의 내용입니다.

 

13장까지 내용과는 달리 요약한 내용입니다.

 

13장까지 읽으면서 말이 많다고, 한 얘기 또 한다고 생각했던 분은 14장이 깔끔하다고 생각하실 것입니다.

 

사실 상세하게 쓸 정도가 못 돼서 개략적으로 쓴 것입니다.

 

모델러라면 알아야 할 내용입니다.

 

자세한 내용을 다룬 전문책으로 공부하셔야 될 내용입니다.

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

현재 파견나와 있는 사이트에서 물리 모델링 단계에 들었습니다.

그동안 했던 고민을 다시 하게 되네요.

 

논리 모델링까지는 업무를 중심으로, 물리 모델링에서는 성능을 중심으로 설계하는 게 정설이지만 다른 분들은 고민이 없는지 모르겠습니다.

저는 통합을 해야 하는지에 대한 고민 등과는 다른, 원초적인 고민을 하게 됩니다.

 

기간상 모든 테이블에 대해 성능을 고려하는 것은 힘들다는 등의 현실적인 사실은 차치하고라도 업무와 성능을 나눠서 생각할 수 있는지도 의문입니다.

만약 나눠서 생각할 수 있다면, 과연 업무와 성능을 나눠서 생각하는 게 효과적인지요?

 

업무가 없는 상태에서 요건을 분석해서 모델링 하는 경우, 과연 물리 모델링 단계가 필요할까요?

데이터가 없는데 어떤 기준에서 성능을 판단할까요?

 

리버스 모델링이라면 이미 데이터를 계속 경험했기 때문에 성능이 업무의 일부분이 되니, 오히려 따로 나눠서 생각하기 힘들지 않을까요?

 

많이 고민한 부분이고, 제 책에도 그 고민을 살짝 썼는데요.

모델링은 종합적으로 생각해야 잘 할 수 있는 분야이지 기계적으로 실행해서 잘 할 수 있는 분야는 아니라고 생각합니다.

나눠서 생각하는 타스크 중 일부는 효과적이지 않습니다.

 

데이터와 쿼리가 존재해서 실험해볼 수 없는 한(이는 사실 모순입니다) 물리 모델링 단계에서 성능을 고려할 수 없습니다. 그것이 추측이거나 경험을 그대로 반영한 것이 아니라면요.

 

그리고 그것이 추측이거나 경험을 그대로 반영한 것이라면 이전 단계에서 한 번에 반영하는 것이 효과적이라는 생각이 듭니다.

 

제가 경험한 게 대부분 마지막 1개월이 물리 모델링 기간이었기에 이런 생각이 드네요.

 

만약 업무만을 반영한 논리 모델로 DB를 생성한 후에 개발을 시작한다면.

그래서 개발 중에 성능 문제와 관리 비효율이 생겨 그걸 해결하는 과정을 물리 모델링으로 본다면 물리 모델링이 재미있을 거 같아요.

실제로 성능 중심으로 설계한 물리 모델링이니까요. 영문 위주의 작업이 아니니까요.

 

최근 몇 가지 한계 때문에 모델링이 재미없다고 생각한 적이 있지만, 모델링은 즐거운 작업입니다.

 

실제 데이터와 화면(SQL)을 보고 문제를 해결해 나가는 과정(물론 인덱스 설계가 기반이 돼야 하고요).

조만간 이런 프로세스가 생길 거라고 기대해도 될까요.

 

물리 모델링 단계에서 어떤 일을 해야 하는지요?

전체의 6분의 1 정도나 되는 기간에 해야 할 일이 있는지요?


물리 모델링 단계가 제일 바쁘다는 등의 의견 말고요
. ㅎㅎ


블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 혈기린 2011.08.16 16:05  댓글주소  수정/삭제  댓글쓰기

    화면UI 조회조건을 보고 적절한 인덱스전략을 세우는것도 한부분이 아닐까 하네요 이제까지 개발 경험상 대개 PK인덱스외는 안만들어주더군요 개발 막바지에 요청을 하면 만들어주더군요

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

      물리 모델링 단계에서 화면UI가 그나마 나오면 다행인데요.. 없었던 거 같아요. ㅎ
      있다면 기존 화면 캡처한 게 있는데...
      어쨌든 화면을 보면서 인덱스를 정해 보는 것도 차라리 의미있는 일인 거 같습니다.

  • 핫신 2011.09.09 13:14  댓글주소  수정/삭제  댓글쓰기

    티스토리에 가입하지 않은 구경꾼임다.
    DA를 하고있는데, 사실 물리모델링은 표준화에 맞추어 테이블, 컬럼, 타입 등을 생성만 하기 때문에 2~3주 걸리죠. SI프로제트에서는 논리2달/물리3달 이런 일정도 있는데 --> 논리4달/물리1달이 DA측면에서는 맞아보임. 허나 APP일정과 DA일정이 꼬이다 보이...사실 힘들죠. 암튼 물리모델기간에는 할일 별로 없다. 모든것은 논리모델기간에 이루어진다에 한표 던집니다.

  • 핫신 2011.09.09 13:17  댓글주소  수정/삭제  댓글쓰기

    최근 프로젝트에서 테스트 기간에 데이터검증하는 롤이 있었는데. 이때 모델 = 데이터 = 화면 = 성능을 함께 검토했는데..참 좋았어요. DA입장에서는 개발-테스트기간에 검증롤이 있으면 좋겠는데... SI에서는 인력배치를 하지 않는것이 대부분이라 이런 프로세스가 없는게 사실이죠. 품질이 좋아야 하는데 돈들어가는 일은 안하고 app 코딩만 죽어라 신경쓰는것 같아요.

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

      좋은 경험을 하셨네요.
      성능을 검토하고 데이터 품질을 신경쓰는 프로젝트가 진짜죠. ㅎ
      코딩에만 몰입하는 프로젝트는 이젠 없어졌으면 좋겠습니다.

  • 김용환 2011.09.27 10:41  댓글주소  수정/삭제  댓글쓰기

    물리모델링 단계에서 AA 쪽에서는 화면설계가 다 나와야 하고 데이터 건수도 어느정도 예측이 가능하고 그에 맞는 물리모델을 구성하는것이 중요한 일이라 생각합니다.

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

 

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

 

제가 일을 시작한 건 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 신고  댓글주소  수정/삭제

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

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

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

용어에 대해 잠깐 얘기하려 합니다.

심도있게 논의하고 싶지만 아직 역량이 안 돼 간략하게요.

 

용어를 얼마나 중요하게 인식하는지 개인차는 있겠지만, 중요하다는 것에는 모든 사람이 동의할 것입니다.

 

저는 대단히 중요하게 생각합니다.

 

간혹 설명으로 이해 못 했던 게 용어를 보고 이해하는 경우가 많고요.

설명으로 이해한 것과 용어로 받아들인 게 달라지면 뒤죽박죽돼 결국 이해하지 못한 게 되기도 하고요.

 

용어는 대개 약속이라 정하면 그만일 듯 하지만 딱 맞지 않는 약속은 정하지 않는 게 좋다고 생각합니다.

 

개인적으로 새로운 용어를 만들어내는 걸 별로 좋아하진 않는데요.

책임이 따르는 일이기 때문에 매우 신중하고, 사실은 경계하는 것 중의 하나입니다.

특별히 과시용으로 만드는 것을 스스로 경계하고요.

 

하지만 기존에 용어가 없거나, 있어도 혼돈스럽다고 생각할 때가 있습니다.

이 용어면 이해를 잘하겠다 싶은 건 과감하게(?) 만들어서 사용합니다.

비난받을 각오를 하고요.

 

제 책에서 사용한 용어는 대부분 기존에 사용되던 용어입니다.

제 책을 너무 많이 읽어서 이젠 제가 만든 용어인지 아닌지 분별이 안 되지만 많은 용어는 원서에서 차용했습니다.

굳이 용어라고 할 수 없는, 고유명사가 아닌 구형태의 영문도 용어로 사용했고요.

 

이전 글에 사용한 종테이블(Vertical Table)이란 용어도 마찬가지인데요. 횡테이블(Horizontal Table)과 함께 이미 원서에서 사용되는 용어입니다.

 

용어에 대해 저만의 특이한 점이 있는데요. 영문 발음을 그대로 한글로 사용하는 것입니다.

예를 들면 카디널러티(Cardinality)처럼요.

 

적절한 한글이 없으면 한글로 번역하지 않고 영문 발음을 그대로 한글화해서 사용합니다.

영어는 모두 우리말로 만들어야 한다는 주장에 반대해서요(제가 가장 존경하는 세종대왕이 싫어하실지도).

 

이런 개인적인 성향을 제 책에도 그대로 적용했습니다.

 

모델링을 수행할 때도 용어는 대단히 중요합니다.

적절한 용어를 사용할수록 모델은 깔끔해집니다.

 

간혹 용어 하나 바꾸는데 정말 목숨 걸어야 하는 상황이 발생하기도 하고요(이해가 안 돼요. ).

간혹 모델 구조나 모델링 이론은 뒷전에고 오직 용어에만 신경쓰는 사이비 모델러도 있지만요.

 

모델링은 정의와 밀접한 관련이 있어서 용어를 신경 안 쓰고 모델링을 하는 것은 사실상 어렵습니다.

 

모델링이 아니라도 용어는 중요하니 적절한 용어를 사용하려 노력하는 것이 좋습니다.


블로그 이미지

블루퍼필

Tag 용어

댓글을 달아 주세요

  • 2011.06.01 13:20  댓글주소  수정/삭제  댓글쓰기

    모델링에서 용어의 중요성은 두 말하면 잔소리죠^^
    모델은 커뮤니케이션의 도구로서의 역할도 상당히 중요한 부분인데, 용어에 대한 확실한 정의가 없다면 그 모델은 이미 커뮤니케이션의 도구로서 자격을 상실하게 되니 좋은 모델이 될 수 없다고 생각합니다.

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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


블로그 이미지

블루퍼필

댓글을 달아 주세요

요구 사항은 프로젝트의 근간이 되는 대단히 중요한 요소입니다. 그리고 모델링과 밀접하게 연관돼 있죠(요구 사항은 함수 종속과 밀접하게 연관돼 있습니다).

 

프로젝트는 보통 아래와 같이 진행됩니다.



 

① 단계에서 개념 모델 또는 초기 논리 모델이 나오고요. ② 단계에서 물리 모델이 나옵니다. 딱 떨어지진 않지만요

 

요구 사항은 ①, ② 단계에서 대부분 도출돼야 하는데요. 실제로 ④ 단계에서 폭주합니다. 심리인 거 같아요.  ㅎㅎ

홈쇼핑 마감 전에 주문이 폭주하는 거 같이…

 

④ 단계에서 요구 사항이 폭주하는 원인이 있습니다.

 

요구 사항은 일정 부분 도출하는 것인데요. 요구 사항을 도출할 수 있는 분석·설계자가 드문 게 현실입니다. 또한 분석·설계자가 도출하는 게 한계가 있습니다.

 

요구 사항은 근본적으로 사용자(User)에게서 나옵니다. 사용자가 업무를 어떻게 하겠다는 것을 요구하는 것이니까요.

 

, ② 단계에서도 많은 요구 사항이 제시하지만 많은 부분 현행 업무와 유사하고요. 본격적으로는 ④ 단계에서 개발 화면을 보고 제시합니다. 사용자 입장에서도 부실한 문서만 보고 판단하기가 만만치 않습니다.

 

그래서 화면이 개발되고 버튼을 클릭하면서 데이터를 봐야 정확히 알게 됩니다. 잘못됐거나 빠진 것을요.

 

하지만 분명 개발된 것을 보고 요구 사항을 제시하는 것은 프로젝트 방법론상으로 잘못된 것입니다.

 

최소한 문서화된 화면을 보고 판단해야 할 거 같습니다. 사용자가 일찍 움직일 필요가 있습니다. 그리고 분석·설계 팀은 ② 단계까지 최소한 화면만은 철저하게 정제해야 합니다.

 

④ 단계에서 요구 사항이 폭주하면… 오픈이 연기됩니다.

 

데이터 모델부터 검토해야 하니 일정에 상당한 영향을 끼칩니다. ② 단계에서 변경하면 2의 수고(비용)가 더 들고요. ③ 단계에서 변경하면 6, ④ 단계에서는 조금 과장해서 40정도가 듭니다. ㅎㅎ

 

그리고 일반적으로 ④ 단계엔 전문 모델러가 없어 모델이 이상해지기 일쑤입니다. 간혹 구조가 틀어지기까지 하고요. 결과적으로 모델이 바꿔서 모델러로서 괜히 편치 않습니다.

 

역시 모델러가 프로젝트 끝까지 남아야 된다는 생각을 또 하게 되네요. 이게 프로젝트 비용을 줄이는 방법인데 개인적으로는 답답합니다.

 

아래와 같이 되지 않으려면 분석·설계자가 개발 전에 화면을 정제할 것을 권합니다. 사용자와 함께 심도있게요.

 

사용자는 개발된 것을 한번 보자는 생각보다는, 문서를 보고 요구 사항이 반영됐는지를 심도 있게 검토했으면 좋겠습니다.

 

다같이 노력하지 않는 한 현재와 같은 상황(분석·설계·개발을 허둥지둥 한꺼번에)은 계속 반복될 것입니다.



 

모델링 시 어려움 중 하나가 요구 사항이 나중에 나오는 것입니다. 이에 대한 근본적인 답은 없지만, 데이터를 통합하고 정규화하면 모델 변경을 그나마 최소화할 수 있습니다.

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

오늘날 데이터를 정보로서 활용하는 사용자의 불만과 불신은 널리 퍼져 있습니다.

 

모델러로서 간혹 현업 사용자와 인터뷰를 하는데 IT에 대한 불만이 심합니다. 물론 IT의 불만도 많습니다. 사실 데이터 품질 문제는 IT의 문제만은 아닙니다.

 

사용자의 불만을 간단하게 요약하면 아래와 같습니다. 수시로 요청하는 데이터, 화면에서 보여지는 데이터, 리포트 등을 망라해서요.

 

§   요청한 데이터를 선별적으로 받는다

§   요청한 데이터를 늦게 받는다

§   요청해서 받은 데이터가 정확하지 않다

§   필요한 데이터를 관리하지 않는다

 

사용자 생각에는 만들 수 있는 데이터 같은데 IT 부서에 요청하면 어떤 건 안되고, 어떤 건 된다는 거죠. 지금은 그렇지 않겠지만 예전엔 저도 상대에 따라 후순위로 미뤘던 기억이 납니다. ㅎㅎ

 

IT 입장에서는 너무 오래 걸리거나 연관 관계가 없어서 곤란할 수가 있습니다. 요건이 미리 결정되고 그에 맞게 데이터를 관리해야 결과를 뽑을 수 있죠.

 

데이터를 요청하면 결과가 너무 늦다는 것도 큰 불만입니다. 과거에는 성능과 관련된 불만이 큰 편이었는데요. 최근에는 데이터가 맞지 않는다는 불만이 많습니다.

 

대부분 사용자는 데이터가 늦게 나오는 것은 대략 이해합니다. 데이터량이 많다는 것을 아니까요. 반면에 데이터가 틀린 것은 이해하지 못합니다. 특히 본인이 엑셀로 뽑았을 때와 결과가 달라지면 IT를 더 이상 신뢰하지 않게 됩니다.

 

데이터가 틀려지는 것으로 인해 많은 문제점이 생깁니다. 사용자도 마음 놓고 결과를 사용하지 못하고요. 데이터 품질 저하로 인한 비용도 만만치 않은데 대부분 모른 척 합니다.

 

마지막으로 어떤 데이터를 관리해야 한다고 요청했는데, 요건을 냈는데도 데이터를 관리하지 않았다는 얘기를 가끔 합니다. 미스 커뮤니케이션이 더 큰 문제인 거 같지만 이런 예를 자주 목격합니다. 결국 필요할 때 데이터를 요구하면 뽑을 수 없다는 답변을 듣게 되죠.

 

최근에 전산을 사용하지 않고는 업무 자체가 불가능하게 됐습니다. 업무의 근원인 데이터를 제대로 관리해야 하는 건 이미 불변의 사실입니다.

 

결국 잘못된 데이터 구조가 데이터 품질을 떨어트립니다. 중복 데이터도 사용을 최대한 자제해야 좋은 품질의 데이터가 됨을 유념해야 합니다.

 

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

아시안컵이 아쉽게 끝났습니다. 인도전에서 한 골만 더 넣었어도, 기라드가 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 개발쪽에 있지만, 머지 않아 데이터와 동등해질 것이고 데이터의 가치를 아는 사람들이 제 역할을 할 때가 올 것입니다.




블로그 이미지

블루퍼필

댓글을 달아 주세요

오늘은 다소 난해한 주제에 대해 쓰려고 합니다.
내용이 어려운 게 아니라 다양한 주장이 존재할 수 있는 얘기입니다.
 
모델러가 해당 업무를 잘 알아야 모델링을 잘 할 수 있을까요?
주장은 업무를 몰라도 모델링을 있다입니다.
 
이런 생각을 처음부터 했고 실무에서 경험했습니다.
잘 했는지는 모르겠지만 그다지 어려움을 느끼지 않았습니다(사실 초반에 약간 힘듭니다).
 
주변의 많은 사람들에게 얘기를 했는데요. 업무를 몰라도 모델링을 있다.
어쩌면 업무에만 치중하는 모델러가 많아 더 강조하게 됐는지도 모르겠습니다.
 
많은 모델러가 업무를 익히기 위해서 많은 노력을 하는데 모델링 기법을 익히기 위해서는 노력을 하지 않습니다.
업무 분석가를 목표로 한다면 이해가 되지만 모델러를 목표로 하면서요
 
전혀 모르는 증권 업무를 모델링 한다고 가정하고 제가 겪는 개략적인 시나리오입니다.
 
가장 먼저 떠오르는 생각은 물론 막막함입니다. 하지만 자신감은 항상 있습니다.
 
일을 시작하기 전에 해당 회사의 홈페이지를 공부합니다. 3~4시간만 집중해서 보면 업무 흐름은 얻을 수 있습니다.
저는 홈페이지를 보고 개략적인 개념 모델(엔터티)을 그리기도 합니다.
 
그리고 일을 시작하면 업무 담당자한테 고백을 합니다.
업무를 하나도 모른다고요. 자세한 설명을 부탁한다고요. 당당하게요.
창피할 필요 없습니다. 모델러가 모델링 기법과 주변 지식을 모르는 것을 창피하게 생각해야 합니다.
 
업무를 전혀 모른다고 말하면 싫어하는 기색을 보이기도 하지만 그 후에 어떻게 하냐에 따라 상대방의 태도도 달라집니다.
프로다운 기질을 보인다면 상대도 인정을 합니다.
 
제 책에도 중요하게 강조했지만 업무를 잘 알던 모르던 인터뷰는 중요합니다.
업무를 안다는 것과 엔터티를 안다는 것은 다른 차원입니다.
 
저는 업무를 잘 알아도 모른 척하고 최대한 많은 정보를 알아내려 애씁니다. 실제로 해당 엔터티는 모르니까요...
상대방과 원활한 커뮤니케이션을 하려면 많은 대화를 해야 합니다.
설명 듣고 물어보는 과정을 먼저 거친 후에 생각하고 분석하면서 모델을 만들고 리뷰하는 과정을 거칩니다.
 
그리고 인터뷰 외에 업무 매뉴얼을 구해서 많은 시간을 들여야 합니다.
이렇게 노력하면 업무에 대한 부담감은 생각보다 금방 벗어날 수 있습니다.
 
이틀 만에 부담이 없어진 적도 있습니다. 길면 한달 정도 초반 적응 기간이 힘들긴 합니다(수험생 같죠).
실제로 업무를 안다고 모델링을 잘 하는 건 아니지만 업무를 알면 여유롭습니다. 심리적인 차이가 크죠.
 
업무를 잘 알면 시간을 절약할 수 있는데 제 경험상 큰 차이는 아닙니다.
빠른 의사결정과 체계적인 진행이 시간을 더 단축시키니까요.
 
모델러에게 가장 중요한 것은 모델링 Skill 입니다.
모델링 Skill 없이 모델링 하는 것은 부끄럽게 생각해야 합니다.
 
모델러가 되고 싶은데 업무를 모른다고 고민하는 사람을 많이 보았는데요.
초반에 잠깐 겪게 될 부담감 이상은 아닙니다.
업무를 몰라도 모델링을 잘 할 수 있다는 말을 한번 믿고 모델링 이론부터 시작해 보세요.
 
사람은 뭐든 시작해야 한다고 합니다. ㅎㅎ

블로그 이미지

블루퍼필

댓글을 달아 주세요