그러나 이후 '데이터베이스 스키마(Schema)의 오류'라는 또 다른 문제가 대두됐다. 데이터베이스가 등장하기 이전에는 프로세싱 절차상 오류가 발생할 경우 그 영향 범위는 해당 모듈에만 국한됐었다. 하지만 데이터베이스 스키마 오류는 시스템의 모든 프로그램에 영향을 미친다. 이는 데이터베이스 내의 데이터는 모두 공유가 이뤄지기 때문에 데이터가 불량인 경우 온 마을 사람들이 독이 든 우물을 함께 나누어 마시는 것과 같은 효과를 발생시키기 때문이다.
데이터 스키마의 오류
그럼 불량 스키마는 왜 생길까? 가장 큰 이유 중 하나는 불량 스키마를 만드는 것이 매우 쉽기 때문이다. 좋은 스키마는 모든 비즈니스 룰을 고려한 설계, 내적 일관성, 외적 일관성, 그리고 유지 가능성 등을 필요로 하며, 고난이도의 작업으로 분류된다. 그러나 한번 데이터베이스 내에 구현되면, 스키마와 연관되어 작동하는 수백 개의 애플리케이션을 구축할 때마다 그 과정을 계속 반복할 필요가 없어진다.
프로그램의 경우 작동 실패를 통해 오류가 있음을 알려준다. 프로그램 언어들은 예외에 대한 처리를 포함하고 있으며, 프로그래머들은 비정상적인 데이터 값을 보고하는 코드를 추가할 수 있다. 그러나 불량 스키마는 아무리 데이터가 옳지 않아도 그 데이터를 리턴하므로 종종 결과세트만 보고는 그 데이터가 옳은지 그른지 구분할 수가 없게 된다. 이에 전체 데이터에 대한 감사(Audit)를 수행하기 전까지는 존재하는 문제들을 발견하기 힘들다. 시스템 감사를 통해 문제점을 발견하게 될 경우, 지금까지 사용해 온 불량 데이터로 처리한 모든 작업들을 모두 재정리해야만 한다. 이 전의 리포트들을 정정한다거나, 불량 데이터로 인해 현재 시스템들이 작동하지 않게 되는 일들을 막기 위한 모든 일들이 이에 해당된다.
설계자들이 이런 상황을 미리 예방하지 못하는 이유는 설계자 스스로 자신의 작업을 검사하고 오류를 완전히 제거하는 것이 불가능하기 때문이다. 이는 설계자들이 사악 또는 게으르거나 멍청해서가 아니라 어떤 문제가 특정 수준 이상으로 복잡해지고 그 규모가 커지면, 설계자가 직접 검사를 통해 오류를 발견하는 비율은 최고 80%-85% 수준에 그치기 때문이다.
검증의 한계 : 데이터 스키마와 애플리케이션 프로그램의 차이
프로그래밍의 경우 프로그래머는 자신이 작성한 코드를 동료에게 검사를 목적으로 제공한다. 동료들은 프로그래머에게 피드백을 주며 프로그래머 스스로 검사할 때 부딪히는 80% 법칙의 한계를 극복할 수 있게 된다. 이 방식은 여느 테스팅 도구를 사용하는 것보다 코드의 품질을 높여준다.
소프트웨어 엔지니어링 연구의 선구자 중 하나인 Caper Jones는 그의 1997년 논문에서 테스트 형태의 오류 제거는 효율성이 30% 수준에 머물렀으나 동료들을 통한 코드 검사 방식으로 오류 제거의 효율성이 65%로 향상됐다고 보고했다. 동일한 맥락에서 미국 전기 전자 학회 IEEE(Institute of Electrical and Electronics Engineers)는 동료들의 소프트웨어 검사가 오류의 60%를 잡아냈다는 조사결과를 보고했다.
물론 이런 검사를 적용하기 위해서는 팀 멤버들 간의 충돌을 방지하기 위한 조직 문화 정립이 선행돼야 한다. 하지만 이러한 조직 문화 정립은 말처럼 쉬운 일이 아니라 상당한 현실적인 어려움이 수반되기 때문에 검사의 일정 부분을 자동화된 소프트웨어 측정 도구를 통해 수행되게 된 것이다.
실제로 SQL의 영역에서는 이러한 문화가 아직 세워지지 않았다. 데이터 모델링 도구를 이용해 스키마를 설계한다면, 이후의 설계 절차에 대해 검사와 리뷰를 누가 해 줄 수 있을까?
프로그래머는 좋은 선택이 아니다. 프로그래머들은 하나의 과제를 어떻게 수행하는가에 초점을 맞춰 생각을 하는 반면 데이터베이스 설계자들은 현재와 미래의 모든 가능한 과제들을 고려하여 논리적인 데이터 모델을 세우는 것에 초점을 맞추기 때문이다.
그러므로 효과적인 리뷰를 위해서는 큰 그림을 그리고 추상적인 수준에서부터 실질적인 구현까지를 모두 감당할 수 있는 전문가가 요구되며 이런 전문가는 쉽게 얻을 수 있는 자원이 아니다.
또 다른 문제는 SQL 스키마는 그 규모가 크고 복잡한 경우가 많기 때문에 아무리 전문가라도 한 개인이 수많은 테이블과 테이블간 상관관계를 일일이 추적한다는 것은 불가능하다.
결국 설계자들은 데이터 모델링 도구가 모든 것을 적합하게 처리해 줄 것이라는 불가능한 기대밖에 할 수 없게 된다. 최고의 데이터 모델링 도구는 내적 일관성이 보장되는 스키마와 간단한 SQL 스테이트먼트 생성까지 제공하기 때문이다. 또한 3NF 이상의 것을 제공하는 것은 아주 어렵고, 모든 비즈니스 룰을 SQL 제약 조건으로 자동으로 적용시켜 주는 것도 불가능하다.
자동화된 검증 솔루션 : Not Everything, but Something!
불량 데이터 스키마는 물이 새는 파이프에 비유할 수 있다. 파이프의 경우 손상된 부분을 그대로 방치하면 물이 끊임없이 흘러 넘쳐 다른 작업마저 방해하게 된다. 불량 데이터 스키마도 마찬가지다. 패치라는 이름으로 애플리케이션 단에 해결책을 적용하더라도 이런 방식으로는 애플리케이션의 데이터를 정상으로 유지한다는 것은 장기적으로 불가능하다. 프로그래머들이 수백에서 수천 개의 코드들을 수정하는 작업을 하다 보면 오류는 끊임없이 발생되게 될 것이기 때문이다.
SQL 제약 조건과 비즈니스 룰들은 스키마 수준에서 작업이 이루어져야 한다. 그러나 이 작업을 완벽하게 진행할 수 있는 전문가는 실제로 부족하며, 설사 존재한다 하더라도 날로 증가하는 시스템의 복잡성은 인간 처리 능력의 범위를 벗어나고 있다는 또 다른 어려움이 생겨나고 있다는 점을 염두에 두어야 할 필요가 있다.
만약 데이터 아키텍트 전문가를 찾는 것이 어렵고 스키마의 복잡성이 한두명의 전문가로는 감당할 수준을 넘어선다면 자동화된 솔루션이 해답이 될 수 있다. 명백한 오류들은 사람이 아닌 자동화 솔루션을 통해 훨씬 쉽게 찾아진다. 워드프로세서에서 맞춤법 검사를 생각하면 이해에 도움이 될 것이다. 자동화 솔루션을 통해 발견 가능한 몇 가지 오류들은 다음과 같다.
● 중복된 인덱스
● 중복되거나 비일관적인 CHECK 제약 조건
● 비일관적인 DEFAULT 값
● 상관관계가 빠진 경우
● 그 밖의 수정 가능한 부분들
결국 인간의 지식을 모두 솔루션으로 바꿔치기 할 수는 없지만 상당부분은 자동화하는 것이 가능하다는 의미다.
단순한 작업 속도 향상? 그 이상이다!
이러한 자동화를 통해 얻을 수 있는 이익은 단지 스키마에 대한 검사를 보다 신속하고 경제적으로 해결할 수 있다는 것만을 의미하지는 않는다. 물론 미국표준기술연구소(National Institute of Standards and Technology)의 주장처럼 개발 비용의 80%가 오류의 규명 및 수정에 투입된다고 봤을 때 데이터베이스 개발 비용 절감 효과가 눈에 띄는 일차적인 이득임에는 분명하다.
하지만 이는 설계 단계에서의 오류를 잡아 낼 경우 향후 그 데이터 스키마와 연관된 모든 개발 프로젝트 비용과 효율성을 극적으로 상승시킬 수 있는 성과와 비교한다면 매우 작은 부분이다. 데이터 스키마의 품질이 좋다는 것은 전체 시스템 차원에서 큰 이득을 가져다 줄 것이기 때문이다.
또한 자동화의 이득은 컴플라이언스와도 연관된다. 바젤II나 SOX와 같은 관련 규정들이 계속 늘어나면서 데이터 품질이 이들 규정에 포함되어 있기 때문이다. 감사과정에서 조직의 데이터 스키마가 적합하게 검사되고 있다는 것을 보여줌으로써 감사의 체크리스트에 'Good' 표시를 추가하는 것이 가능해진다.
그 외에도 자동화된 솔루션은 설계자가 자신이 직접 작업한 스키마를 스스로 검사하는 것을 가능하게 해주며 80% 룰을 극복하는데 도움이 된다. 설계자는 언제라도 원하는 시기에 솔루션을 이용한 검사를 진행할 수 있으며, 개발 단계에서 오류를 찾아내고 수정을 가능하게 함으로써 프로덕션 환경에 적용 후 일어날 재난을 미리 방지할 수 있게 한다.
또한 즉각적인 피드백을 설계자에게 제공하여 설계자 자신의 능력도 향상시킨다. 맞춤법 검사를 하는 워드 프로세서를 사용하면 이용자는 동일한 실수를 반복하지 않고 올바른 맞춤법을 자연스럽게 체득하게 되는 것과 같은 원리다.
요약컨대 IT 인프라 내에서 유비쿼터스라고 불릴 수 있는 부문은 역시 데이터베이스이다. 따라서 데이터의 품질은 시스템 전체에 영향을 미친다. 그러나 그 크기와 복잡성은 전문가의 처리 능력을 벗어나 있기에 자동화된 데이터 스키마 검사 도구가 요구된다.