유능한 데이터 아키텍트 되기 위한「5가지 제언」

출처 : http://www.zdnet.co.kr/builder/dev/db/0,39031604,39134267,00.htm

일반적으로 벽돌 올리는 사람을 아키텍트라고 부르지 않는다. 건물을 종합적으로 아름답게 완성하기 위해 계획을 수립하고 설계하는 사람을 건축에 있어 아키텍트라고 부른다.

마찬가지로 단순하게 테이블을 생성하는 스크립트를 실행하고 정기적으로 데이터베이스를 백업하고 관리하는 정도의 단순 엔지니어가 아니라 데이터, 데이터베이스에 대해 종합적인 상황을 고려하여 최상의 데이터 관리 체계 수립과 기반을 마련해내는 전문성이 높은 데이터 아키텍트가 되도록 노력해야 한다.

데이터베이스 관리자(DBA)는 그저 시스템 운영 중에 정기적으로 모니터하고 데이터를 백업, 복구하는 사람 정도로 생각하는 경우가 많다. 그러나 실무 프로젝트에서 이른바 데이터베이스 관리자는 업무를 분석하고, 데이터 관리 전략(ITA, EA)을 수립하고 데이터 모델링을 수행하며 데이터베이스 구조 설계 및 구축, 튜닝, 관리를 수행하므로 단순 데이터베이스 관리자라기보다는 데이터에 대해 종합적으로 구상하고 설계하고 다루는 데이터 아키텍트(data architect)로 정의하는 것이 올바르다.

일반적으로 경력이 적을수록 구축과 관리 업무를 수행하고 경험이 많아질수록 분석, 설계, 튜닝, 전략 수립의 업무를 수행한다. 데이터 아키텍트로서 효과적으로 업무를 수행하기 위해서는 다음 다섯 가지 정도가 필요하다(일부는 『나는 프로그래머다』(한빛미디어)에서 소개한 내용이기도 하다).

◆ 자신만의 사고의 전환점을 가지고 있어야 한다.

◆ 설계(데이터 모델)의 중요성을 인식해야 한다(급한 것만을 중요하게 여기면 안 된다).

◆ 논리 모델과 물리 모델 전환 노하우를 읽혀야 한다.

◆ 데이터베이스 표준에 대해 중요하게 인식한다.

◆ 정규화/반정규화를 정확하게 설명하고 적용할 수 있어야 한다.

자신만의 사고의 전환점을 가지고 있어야 한다
어떤 사람은 ‘전문적인 데이터 아키텍트는 학습이나 경험만으로는 될 수 없고 타고난 분석력이나 사물을 바라보는 눈이 있어야 한다’고 이야기한다. 그만큼 데이터 아키텍트라는 영역에는 어렵기도 하고 학습만으로는 달성할 수 없는 영역이 있기 때문에 그렇게 표현하는 것이다.

그러나 필자는 ‘누구나 데이터 아키텍트가 될 수 있다’고 이야기한다. 단, 19칸×19칸의 바둑판에 누구나 바둑을 두지만 최저 18급부터 최고 9단까지 구분하는 기력이 존재하듯이 데이터 아키텍트도 전문성에 따라 능력을 분류할 수 있다. 그럼 어떻게 해야 전문성이 높은 데이터 아키텍트가 될 수 있을까?

그것은 바로 자신만이 가질 수 있는 사고의 전환점을 찾는 것이다. 사고의 전환점은 다른 사람의 경험이 자신의 경험이 될 수 없으므로 무엇이 됐든 자신만이 이해하고 극복할 수 있는 사고의 전환점을 가져가는 것이다. 정보 기술에서 ‘어렵다’고 이야기하는 데이터 모델과 데이터베이스 영역에 훌륭한 전문가가 되기 위해서는 바로 다음과 같은 사고의 전환 그래프 원리를 활용하는 것이다.

<그림 1> 사고의 전환에 의한 성장 효과 그래프

그래프를 보면 일반적 노력에 의해 성장 효과가 초기에는 명확하게 나타나지만 시간이 지남에 따라 성장 속도가 둔화되고 더 이상 발전이 되지 않는 상태에 도달하게 된다. 그러다가 어떤 사고의 전환점을 만나는 순간 성장 속도가 급격하게 빨라지게 되는 그래프다.

일반적인 데이터 아키텍트로서 역할 수행은 첫 번째 노력에 의해 얼마든지 할 수 있으므로 첫 번째 노력도 무척 중요한 과정이라 할 수 있다. 그러나 그러한 노력만으로는 전문적이고 훌륭한 데이터 아키텍트가 될 수 없다. 바로 이 때 사고의 전환점이 있어야 한다는 것이다.

어떤 사람은 이 한계를 그 사람의 능력의 최고점이라고 이야기하고 이 한계점을 넘은 사람을 타고난 자질이라고 표현한 사람도 있다. 그러나 필자는 그렇게 생각하지 않는다. 사람은 누구나 능력을 소유하고 있으며 그 상태에서 사고의 전환을 통해 무한히 성장할 수 있다고 생각한다.

문제는 개인이 그 사실을 인정하고 받아들이는 것이라고 생각한다. 그러므로 먼저 첫 번째 성장 노력을 충분하게 하면서 사고의 전환점을 통과하여 최고의 데이터 아키텍트가 될 수 있다는 생각과 노력이 필요하다.

사고의 전환점을 돌파하려면 자신을 규정하는 잘못된 자아관을 버려야 한다. ‘나는 여기까지가 한계야’, ‘저 부분은 다른 전문가가 하는 영역이야’, ‘내가 어떻게 저 영역까지’라고 생각하는 자아관을 버려야 한다.

우리가 알고 있는 이른바 전문가라는 사람은 자신으로부터 나오는 이러한 생각을 버리고 최고의 전문가가 될 수 있다는 자신감이 있어서 된 사람들이다. 자신을 규정하는 자신으로부터 생성된 잘못된 자아의 틀을 벗어버리고 자신감을 가지고 나아갈 때 최고의 전문가 영역에 도달할 수 있다.

프로그래밍을 할 때 ‘이 문제는 내가 도대체 해결할 수 없는 문제야. 내 힘으로는 안 되기 때문에 도움을 요청해야 겠어’라고 하거나 업무적인 요구사항에 대해 데이터 모델링을 할 때 ‘내가 하는 일에 대해 자신이 없어 이전 데이터 모델을 참조하여 조금 변형해서 사용해야겠어’라고 한다면 자신의 능력을 자꾸 스스로 규정하고 발전 가능성을 차단하게 되는 결과를 초래한다. 사고의 전환점은 적극적인 사고에 의해 얻어질 수 있으며 이 단계를 넘어서면 다양한 SI의 어떤 영역에 대해서도 어렵지 않게 극복해 나갈 수 있게 된다.

데이터 아키텍트의 사고의 전환점은 데이터 관점에서 업무를 분석하는 눈, 완벽한 데이터 모델의 이해, 데이터 관리 체계 수립, 데이터베이스 튜닝·관리 등의 영역에 적용할 수 있다. 마치 고단수의 바둑 기사는 바둑판 귀퉁이에 한 수를 착점해도 귀퉁이 집만을 획득하기 위해 착점하지 않고 이후에 전개될 세력, 상대방의 돌의 상황 등을 고려한 종합적인 판단에 의해 착점을 하듯이 데이터 아키텍트도 내가 알고 있는 특정 지식에 묻혀 있지 않고 전체를 바라보면서 사고하고 판단할 수 있는 최상의 전문성을 확보하게 하는 것이 바로 사고의 전환점을 가지는 것이다.

비유가 좀 이상할 수 있지만 음악에서도 음악의 아름다움을 느낀 사람은 계속 그 아름다움을 느낀다. 미술에서도, 영화, 연극, 뮤지컬, 오페라 등도 마찬가지다. 아름다움을 표현하거나 느낀다는 것은 마치 일정한 도(道)에 도달한 것처럼 어떤 한계를 극복하여 나타난 현상들이다.

많은 노력을 해야 하는 SI에서도 프로그래밍이나 모델링, 데이터베이스에 대해 성장을 위한 사고의 전환점을 일단 한 번 돌파하면 그 이후에 훌륭한 전문가의 영역으로 나아가는 데 큰 문제가 없게 되는 것이다.

데이터 아키텍트 영역에서 자신이 가지고 있는 한계점을 극복해 보자. 이 한계점을 경험을 통해 극복하든, 학습을 통해 극복하든, 데이터베이스에 대해 생각하면서 길거리를 가다가 극복하든 그것은 자기에게 가장 적합한 형태를 취하면 된다.

설계(데이터 모델)의 중요성을 인식해야 한다
프로젝트를 탐방하여 데이터베이스에 대해 점검하다 보면 많은 프로젝트에서 설계는 대충 하고, 열매는 훌륭하게 맺으려 하는 모순을 보게 된다. 특히 데이터 모델은 이전에 사용했던(품질이 좋지 않은) 모델의 일부만을 변경하고 데이터 모델의 단점을 응용 프로그램에서 모두 해결하려는 경우가 많다.

필자는 요즈음 프로젝트의 데이터 아키텍처 부분을 점검(진단)하는 업무를 수행하는데, 하나의 프로젝트에 대해 설계 단계와 테스트 단계 때 점검을 두 번 실시한다. 설계 단계 때 여러 가지 설계 오류사항을 지적하면 프로젝트 팀에서 부정적인 반응이 많이 나타나지만 구축이 완료되고 난 다음에 지적하고 가이드하면 아주 긍정적인 반응을 나타내는 경우가 많이 있다.

그러나 문제 해결의 난이도나 노력의 정도로 보았을 때, 설계 단계 때 10의 노력을 들여 해결할 수 있다면, 구축 단계 이후에는 1000 이상의 노력으로도 해결이 어려운 경우가 많이 있다. 설계 단계 때 잘못된 사항에 대해서는 긴급하지 않고 눈에 잘 드러나지 않으므로 심각하게 여겨지지 않고, 구축 이후에는 잘못된 내용에 대한 심각성이 구축된 시스템에 의해 곧바로 드러나기 때문에 그렇다.

<그림 2>는 구축이 완료된 프로젝트에서 테이블 TAB_FACTOR라는 테이블에서 데이터 처리를 한 예다. 오른쪽 SQL 구문을 보면 최신의 값을 가져오기 위해 SQL 문장의 인라인뷰에서 GROUP BY와 MAX를 이용하여 먼저 최신의 GET_TIME을 가져와서 다시 메인 질의에서 데이터를 처리하는 모습이다. 대량의 데이터가 TAB_FACTOR에 들어가는데 이 테이블에 설계된 모든 SQL 문장은 이와 같이 처리되고 있었던 것이다.

<그림 2> 대용량 이력 테이블의 복잡한 처리

이와 같이 처리하여 성능이 저하되어 나타나고 있었는데 데이터 모델에 최신을 나타내는 기능성 컬럼을 추가하여 <그림 3>과 같이 처리하도록 했다. <그림 3>의 오른쪽에 나타난 것처럼 SQL 구문이 간단하게 되면서 성능이 향상된다.

<그림 3> 대용량 이력 테이블의 단순한 처리

원래 시스템 구축 프로젝트에서는 분석·설계 단계에서 데이터 모델을 완성하고 완성된 데이터 모델을 이용하여 프로그램을 개발하게 된다. 그런데 분석·설계 단계에서, 즉 데이터 모델에 대해 앞에서와 같은 사항의 불합리성을 지적하면 그 심각성에 공감하지 못하는 경우가 많이 있지만 구축이 완료되고 성능이 나오지 않은 시점에 같은 사항을 이야기하면 무척 고마워하는 경우가 많이 있다.

하지만 이미 개발이 완료된 시점에서 수정하려고 하면 사안에 따라 굉장히 많은 시간과 노력이 필요하게 되는 것이다. 앞의 예는 개발된 50%의 프로그램 소스가 이 로직과 관련이 있어서 실제로 많은 노력이 투입되어 변경됐다. 분석 설계 단계 때부터 데이터 무결성과 성능을 고려한 종합적인 데이터 모델링이 필요하다는 사실을 확신하게 하는 여러 가지 사실이 앞의 예와 같이 많이 발견된다.

여러 가지 여건상 시간과 인원에 제한적인 시스템 개발 프로젝트에서는 급한 것만을 중심으로 프로젝트를 전개하려는 특징이 있다. 중요한 것을 여유를 가지고 충분히 추진할 내용에 대해 간과하고 잊어버리는 경우가 발생하는 것이다.

프로젝트는 오픈 위험요소 중 가장 많이 나타나는 세 가지 이슈가 존재한다. 첫 번째가 성능 문제, 두 번째는 데이터 전환 문제, 세 번째는 데이터 무결성 문제다. 이 세 가지는 모두 데이터베이스와 연관되는 항목이다. 성능 문제는 프로젝트를 오픈하자마자 당장 부딪히는 문제이며 많은 프로젝트가 성능이 원활하게 나오질 않아 정상적으로 오픈하지 못하고 주저앉는다.

그래서 성능 문제는 프로젝트에서 가장 긴급하게 생각하는 문제가 되고 있다. 데이터 전환 문제도 프로젝트가 오픈할 때 이전 데이터를 새롭게 설계된 데이터베이스에 이관하는 작업이므로 반드시 정해진 시간 안에 정확하게 수행되어야 한다. 그러므로 이 또한 급한 문제이다.

데이터 무결성 문제는 프로젝트를 오픈하고 난 이후에 당장 가시적으로 나타나지 않는 경우가 많다. 그런데 시스템을 오랜 시간 동안 운영하다 보면 데이터 무결성이 업무의 흐름에 맞게 논리적인 구조나 흐름이 맞아야 하는데 그렇지 않은 경우가 많이 나타날 수 있는 것이다.

데이터 무결성을 가장 잘 유지하는 방법은 업무를 분석하고 설계할 때 업무 특징을 고려하여 데이터와 프로세스에 대한 모델링이 정확하게 수행되도록 하는 것이다. 당장 눈에 보이지 않는다고, 오픈할 당시에 결과가 바로 밝혀지지 않는다고 이 부분에 대해 쉽게 생각하고 정확하게 하지 않으면 장기적으로 오류를 유발하게 되는 것이다.

성능 문제나 데이터 전환 문제는 시스템 오픈을 성공적으로 할 수 있느냐에 대한 가시적인 관점인 반면 데이터 무결성은 업무가 정상적으로 처리되고 이후에 지속적으로 그렇게 처리되도록 하는 기반이다. 즉 성능과 데이터 무결성 두 항목의 중요도를 비교하자면 당연히 데이터 무결성이 훨씬 높은 것이다.

인간은 삶 자체에 의미가 있듯이 데이터베이스는 데이터의 무결성을 유지할 수 있을 때 의미가 있다. 농부든 대통령이든 장관이든 CEO든 아무리 우수한 사람들이라도 죽어버리면 의미가 없듯이 아무리 성능이 빠르고 효과가 좋은 데이터베이스라도 데이터 무결성이 깨져버리고 업무적으로 이상한 데이터를 출력한다면 그 데이터베이스는 죽은 데이터베이스다.

데이터 무결성을 올바로 유지하게 하기 위해서는 분석, 설계 단계 때부터 잘 정규화되고 엔티티 타입간의 관계가 모두 도출되도록 데이터 모델을 설계해야 한다. 즉 데이터 관리의 핵심 기반을 마련하고 훌륭한 데이터베이스를 구축하기를 원한다면 설계가 중요함을 인식하고 특히 데이터 모델링에 전문가가 되기를 바란다.

논리 모델과 물리 모델 전환 노하우를 읽혀야 한다
데이터 모델링을 전개할 때 프로젝트에서 업무를 분석하는 초기 단계부터 시스템 분석가는 데이베이스 테이블을 설계하려고 한다. 업무를 가장 효율적으로 표현해 내는 것이 일차적인 데이터 모델링의 목적임에도 불구하고 분석가는 시스템으로 어떻게 구현할 것인지를 먼저 생각하고 분석하는 현상이 발견된다. 그리고 설계 단계에서는 분석 단계에서 했던 일과 별로 차이 없이 물리적 모델링을 진행한다.

그러다 보니 업무도 완벽하게 분석되지 않을 뿐만 아니라 논리적인 모델과 물리적인 모델이 구분이 안 되고 물리적인 모델의 기준도 흔들리게 된다. 필자는 데이터 모델링과 데이터베이스 설계·구축에 두 가지 중요한 부분이 있고 많은 프로젝트에서 이 두 가지 포인트를 간과하고 있음을 여러 프로젝트를 분석하면서 알게 됐다.

논리적인 단계에서는 비정형화된 업무를 논리적인 모델로 만들어 내는데 그 중심 사상은 바로 ‘업무를 어떻게 하면 가장 잘 모델로 표현할까’가 되어야 한다. 설계 단계에서는 ‘업무적으로 잘 표현된 논리 모델을 실제로 구축할 데이터베이스의 특징을 중심으로 데이터의 무결성과 성능을 고려한 모습으로 어떻게 표현해 내도록 할까’가 중심이 되어야 한다.

<그림 4> 프로젝트의 논리/물리 모델에 대한 현상

그러나 실제 많은 프로젝트에서는 <그림 4>와 같이 논리 모델에 대한 인식 부족으로 인해 바로 물리적인 모델을 만들어버려 업무로부터 정확한 모델을 만들어 내지 못하는 경우가 있거나 물리적인 모델에 대한 노하우가 부족해 완벽한 물리 모델을 만들지 못하는 경우가 많이 나타난다. <그림 5>와 같이 논리적인 데이터 모델과 물리적인 데이터 모델의 역할을 명확하게 분리하여 데이터 모델을 설계해야 한다.

<그림 5> 분석 단계와 설계 단계 때 중점적인 설계의 역할

<그림 5>와 같이 분석 단계 때는 업무 중심 모델링이 필요하고 설계 단계 때는 데이터베이스 중심 모델링이 필요하다. 분석 단계 때는 최대한 정규화를 적용하여 데이터 값이 원자성을 확보하여 저장될 수 있도록 논리적인 데이터 모델을 만들어내고 설계 단계에서는 데이터베이스 성능을 고려하여 엔티티 타입, 속성, 관계에 대해 반정규화를 고려하고 인덱스 특징을 고려하여 PK 속성과 FK 속성의 순서를 적절하게 조정하도록 한다. 또한 데이터베이스 분산 구조를 고려하고 뷰와 같은 오브젝트 사용에 대해 설계하도록 한다.

잘 설계된 논리적인 데이터 모델은 확장성이 우수하여 재사용성이 높은 특징을 가지고 있다. 확장성이 우수하다는 것은 업무 변경이나 추가에 쉽게 대응할 수 있는 구조가 되고 비슷한 다른 업무에서도 다시 사용할 수 있는 훌륭한 특징을 가지고 있다.

데이터베이스 표준에 대해 중요하게 인식한다.
개집을 만들거나 간단한 구조물을 만드는 작업은 특별한 표준이나 기술을 가지고 있지 않아도 어렵지 않게 만들 수 있다. 그러나 개집을 만드는 기술로 수많은 사람이 사는 아파트를 건축할 수는 없다. 개집을 짓는 것과 아파트를 건축하는 것의 차이는 규모가 크다는 것만 다를 뿐 건축한다는 것은 동일하다고 할 수 있다. 그러나 규모가 다르므로 인해 정확한 표준과 프로세스가 없으면 아파트를 지을 수 없다는 것은 누구나 알 수 있는 사실이다.

정보 시스템도 마찬가지로 자신의 경험만으로 훌륭한 시스템을 만들어낼 수는 없다. 우리는 개집과 같은 작은 규모의 시스템을 만드는 것이 아니라 기업이나 공공 기관의 업무에 대한 시스템을 만들므로 표준이나 프로세스가 무엇보다 중요한 역할을 하게 된다. 데이터베이스를 구축하는 작업은 건물의 기초 공사에 해당하는 중요한 작업이므로 반드시 표준과 정해진 절차를 준수하며 작업해야 한다.

데이터 아키텍처에도 반드시 표준을 먼저 정의해야 한다. 특히 데이터 모델과 데이터베이스에 직접 연관이 있는 용어 사전(컬럼 사전, 데이터 사전)과 도메인 정의서(속성의 데이터 타입과 길이, 제약사항을 표준화)는 반드시 정의하도록 하고 테이블 스페이스명, 데이터 파일명, 로그 파일명 등 데이터베이스에 관련된 명명 규칙 등을 반드시 정의하여 준수하도록 해야 한다.

필자가 H 프로젝트에서 모델링을 수행할 때의 일이다. 프로젝트 분석이 어느 정도 진행되어 논리적인 데이터 모델이 거의 완성됐는데 엔티티 타입의 속성의 이름을 부여할 수 있는 기준이 존재하지 않았다. 그래서 당시 통합 모델링을 진행하던 사람 중 두 명이 할당되어 용어 사전과 도메인을 정의하는 일을 수행했다.

두 명의 대리가 두 달 동안 전체 시간을 할당하여 관련 일을 수행했고 한 명의 리더가 내부에서 검토했고 고객 측도 한 명이 검토를 했다. 두 달 동안 일을 수행하여 두 개의 엑셀 파일을 만들어 냈는데 나중에 엑셀 파일의 가치를 계산해 보니 대략 두 개의 간단한 엑셀 파일이 5000만원 정도가 되는 것이었다(한 달에 800만원 정도 하는 대리의 공수를 계산하면 3200만원에, 검토자 파트 타임 지원 대략 1200만원).

5000만원짜리 두 개의 엑셀 파일을 가지고 개발팀에 배포하여 모든 데이터 모델에 대해 일관성 있게 수정하는데 꼬박 한 달이 걸려 관련 일을 수행했으므로 비싼 표준을 가지고 다른 개발자의 일까지 정지하며 적용했으므로 상당히 많은 비용이 소진된 셈인 것이다.

그러나 이렇게 값비싸게 데이터 모델의 일관성을 유지함으로써 이후에 데이터베이스 용어와 데이터 타입과 길이에 대한 혼란을 최소화할 수 있었다. 데이터베이스 용어에 대한 일관성이 결여되어 데이터 무결성이 깨지고 데이터 타입과 길이가 맞지 않아 데이터베이스 성능이 무척 떨어져 심각한 장애 현상까지 발생했다는 이야기들을 주변에서 종종 들어봤을 것이다.

정규화/반정규화에 대해 정확하게 설명할 수 있어야 한다.
필자가 H 프로젝트에서 미국 컨설팅 업체와 일을 하면서 미국 컨설턴트를 통해 들은 이야기다.

여러 사람이 같이 산에 올라가는데 각자 맡은 짐을 가지고 가기로 했습니다. 그런데 어떤 사람이 자신이 맡은 짐 이외에 다른 사람이 등산 가방에 챙겼음에도 불구하고 다른 사람이 맡은 짐까지 다 자기 배낭에 다시 챙겨 넣으면 어떻겠습니까? 이 사람이 불필요하게 등산 가방을 무겁게 지고 산에 올라가는 것을 어렵지 않게 상상할 수 있을 것입니다.

만약 등산 가방에 들어가 있는 무거운 물건들이 한 사람의 배낭에만 있어도 되는데 이렇게 불필요하게 다른 사람의 짐까지 중복해 가져간다면 당신은 어떤 말을 해줄 것입니까?

그 컨설턴트는 어떤 시스템에 설계된 데이터 모델에 너무나 많은 반정규화가 적용되어 테이블이 쓸데없이 무거워 졌다는 표현을 이렇게 한 것이다. 당시 미국 컨설턴트가 컨설팅을 받는 모델링 담당 개발팀의 모델러와 시스템 주관사인 고객에게 중복해서 존재하는 데이터 모델의 부작용(과도하게 반정규화된 데이터 모델의 부작용)에 대해 설명했지만 잘 이해하지 못하자 이 비유를 한 것이다.

등산 가방을 여러 명이 메고 산에 올라갈 경우 필요한 내용은 한 사람만 가지고 가도 되는데 여러 명이 다 같이 메고 가기 때문에 모두 다 무겁게 산에 올라가고 있다는 그런 의미에서 한 말이다. 이 비유를 듣던 고객은 고개를 끄덕이며 ‘아 정말 그렇군요’ 하면서 맞장구를 쳤다. 그리고 그 고객이 등산 가방을 매는 시늉을 하면서 불필요하게 반정규화된 데이터 모델을 반드시 정규화하라고 개발팀의 모델러에게 지시했다.

데이터베이스에서 제일 중요한 정규화의 이론은 무엇인가? 역시 특정 테이블에서 반복적으로 나타나는 속성을 분리하여 속성의 원자성을 가지게 하는 것이 목적이다. 그래서 각 속성을 처리할 때 중복 처리를 배제하여 입력·수정·삭제의 에러 유발 가능성을 없애야 한다.

정규화에 대한 이론은 E.F Code 박사를 중심으로 몇몇 학자들에 의해 정립됐다. 프로젝트를 진행하다 보면 정규화에 대한 정의와 정규화이 필요성을 의외로 인식하지 못하는 경우가 많이 있다. 데이터 아키텍트는 정규화 이론 1차, 2차, 3차, BCNF, 4차, 5차 정규화에 대해 이해하고 프로젝트에 적용할 수 있어야 한다.

<표 1> 정규화 이론

전문성이 높은 데이터 아키텍트가 되자
흔히 시스템 개발을 할 때 개발자라고 하면 항상 컴퓨터 앞에 앉아 키보드로 명령어만 입력하는 사람이라고 오해하는 경우가 많이 있다. 그러나 기술이 성장할수록 키보드를 두들기는 시간보다 내용을 분석하고 협의, 회의하고 설계하는 시간이 늘어나게 된다.

아름다운 건물, 기능이 우수한 건물은 벽돌을 하나하나 올리는 것만으로는 절대로 완성될 수 없다. 주위의 집, 나무, 공원, 환경 등을 고려하여 구조와 색을 선택하여 설계하고 사람이 살아갈 때 편리성을 고려한 기능을 설계해야 한다.

일반적으로 벽돌 올리는 사람을 아키텍트라고 부르지 않는다. 건물을 종합적으로 아름답게 완성하기 위해 계획을 수립하고 설계하는 사람을 건축에 있어 아키텍트라고 부른다. 마찬가지로 단순하게 테이블을 생성하는 스크립트를 실행하고 정기적으로 데이터베이스를 백업하고 관리하는 정도의 단순 엔지니어가 아니라 데이터, 데이터베이스에 대해 종합적인 상황을 고려하여 최상의 데이터 관리 체계 수립과 기반을 마련해내는 전문성이 높은 데이터 아키텍트가 되도록 노력해야 한다.@