여러 프로젝트를 점검하면서 잘 안
되는 프로젝트의 특징은 설계는 대충하고 구축은 훌륭하게 하려고 하는 것이었습니다.

특히 데이터 모델은
이전에 사용했던 모델의 일부만을 변경하고 애플리케이션에서 이것을 다 해결하려고 하는 특징이 있는 것이었습니다. 아키텍처
점검을 하나의 프로젝트에 대해 두 번 실 시하였는데 설계 단계 때 여러 가지를 지적하면 이해하지 못하는 부정적인 반응이 많이 나타났지만 구축이
완료되고 난 다음에 지적하고 가이드하면 아주 긍정적인 반응을 나타내는 경우가 많이 있었습니다. 그러나
문제해결의 난이도나 노력의 정도로 보았을 때, 점검을 통해 발견된 문제가 설계 단계 때 해결이 되면 10의 노력을 들여 해결할 수 있다면 구축 단계 이후에 해결이 되면 1000 이상의
노력으로 해결이 어려운 경우가 많이 있습니다. 그러한 특징을 단순 지식으로는 아는 것 같지만 설계된
내용을 수정했을 때 미치는 심각성을 정확하게 모르기 때문에 그런 현상이 나타나는 것입니다.

급한 것만을 중요하게 생각하는 조급
증이 자주 일을 망치게 됩니다.

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

필자가 분석한 프로젝트를 보면, 프로젝트는 오픈 위험요소 중 세 가지가 가장 많이 나타납니다.

첫 번째는 성능 문제고,

두 번째는 데이터 전환 문제,

세 번째는 데이터 무결성 문제이지요.

이 세 가지는 모두 데이터베이스와 관련된 항목이 됩니다. 성능 문제는
프로젝트를 오픈하자마자 당장 부딪히는 문제며 많은 프로젝트가 성능이 원활하게 나오질 않아 정상적으로 오픈하지 못하고 주저앉는 경우가 많이 있어
왔습니다. 그래서 성능 문제는 프로젝트에서 가장 긴급하게 생각하는 문제가 되고 있습니다. 데이터 전환 문제도 프로젝트가 오픈 할 때 이전 데이터를 새롭게 설계된 데이터베이스에 이관하는 작업이므로 반드시
정해진 시간 안에 정확하게 수행되어야 합니다. 그러므로 이 또한 급한 문제기도 합니다.

그러나 데이터 무결성 문제는 프로젝트를 오픈하고 난 이후에 당장 가시적으로 나타나지 않을 경우가 많이 있습니다. 시스템을 오랜 시간 동안 운영하다가 보면 데이터베이스의 데이터 무결성이 업무의 흐름에
맞게 논리적인 구조나 흐름이 맞아야 하는데 그렇지 않은 경우가 많이 나타날 수 있는 것입니다. 데이터
무결성을 가장 잘 유지하도록 하는 방법은 업무를 분석하고 설계할 때 업무적인 특징을 고려하여 데이터와 프로세스에 대한 모델링이 정확하게 이루어져야
합니다. 그러나 당장 눈에 보이지 않는다고 오픈 할 당시에 결과가 바로 밝혀지지 않는다고 이 부분에
대해서 쉽게 생각하고 정확하게 하지 않고 진행하는 경우가 있는 것입니다.

성능 문제나 데이터 전환 문제는 시스템을 오픈하였을 때 오픈을 성공적으로 할 수 있느냐에 대한 가시적인 관점인
반면 데이터 무결성은 업무가 정상적으로 처리가 되고 이후에 지속적으로 그렇게 처리되도록 하는 기반 역할을 합니다.
즉, 중요성은 데이터 무결성이 훨씬 높은 것이지요.

성수대교를 개교했을 때 많은 사람이
강을 횡단할 수 있는 또 다른 다리가 생겨서 무척 기뻤을 것입니다. 그러나 그 안에 부실한 부분에 부식이
생겨 무너질 위험이 있는 것을 간과하지 못하고 있다가 당시 세계 TOP 뉴스에 회자될 만큼 사고가 발생한
것처럼, 데이터 무결성이 지켜지지 않은 데이터베이스는 성공적으로 오픈을 했을지라도 그 데이터가 업무적
사고를 유발할 가능성이 높습니다.

그러나 막상 프로젝트를 진행하다가
보면 급한 문제에 대해서는 많은 시간을 투여하고 중요한 사항에 대해서는 나중에 하겠지라는 막연한 생각으로 묻어 둘 때가 많이 있는 것을 보았습니다.

중요한 점을 챙겨야 성공할 수 있는
것은 비단 데이터베이스 뿐만 아니라 사람이 살아가면서 생각해야 할 꼭 필요한 사상입니다.

다음은 프로젝트를 진행할 때 데이터베이스
측면에서 중요한 점 네 가 지를 정리한 것입니다.

첫째, 통합 데이터 모델의 완성도 향상이 필요합니다. 훌륭한 데이터베이스는
훌륭한 데이터 모델에 근거할 수 밖에 없습니다. 논리적인 설계도에 해당하기 때문에 그렇지요

둘째, 성능은 설계 시부터 고려하여 지속적인 성능 관리를 필요로 합니다.

셋째, 일관성 있고 협의된 데이터 모델 및 데이터베이스 변경 관리 적용이 필요합니다.

넷째, 분산 데이터베이스 또는 데이터베이스 인터페이스 아키텍처에 대한 성능 고려가 필요합니다.

당장 급한 일, 예를들어 프로그램 개발, 단순 SQL
성능 향상(성능 관리가 아님) 등에 대해서만
처리하다가 프로젝트가 근본적으로 위험해지는 경우가 많이 있습니다. 위의 네 가지에 대해서는 특히 데이터베이스와
관련되어 있으면서 중요한 문제이므로 프로젝트 초기부터 체계를 갖추어 접근한다면 훨씬 안정적이고 높은 수준의 프로젝트를 전개할 수 있습니다.