[기고] 데이터 중복 메커니즘과 활용

1. 들어가며

얼마 전 오픈한 바 있는 모 차세대 정보시스템 구축 사업의 후반부에 데이터 베이스 성능 문제 해소 방안으로서 '데이터 중복'이 이슈화 된 적이 있었다. 성능 문제들 중에서 데이터 중복 외에는 해소 방법이 없는 경우가 있다. 데이터 중복을 허용하자니 해당 테이블을 대상으로 데이터를 처리하는 응용 프로그램 수정과 데이터를 다시 전환해야 하는 부담이 따랐으므로 관련 담당자들 간 갈등으로 비화되는 상황을 맞이하기도 했다.

앞으로 두 차례에 걸쳐 데이터 중복이 왜 필요하고 데이터 모델러들이 어떻게 대응해야 하는지 살펴보고자 한다. 더불어 데이터의 구조적 의미 또는 업무적 의미에 의해 데이터 중복이 제한되는 특성을 제시하고자 한다.

2. 데이터 중복의 필요성과 대응

최근에 필자는 한 정보시스템 구축 프로젝트에서 데이터 모델링 리더 역할을 수행했다. 이 프로젝트에서 설계 단계 직후, 응용 프로그램 개발조직에서 시스템 성능 문제 해소를 위해 필요하다고 판단될 경우 역정규화(Denormalization) 요청 대장을 작성해 데이터 모델러들에게 통보하여 데이터 중복 필요를 검토할 수 있도록 상호 협의해 진행했다.

역정규화란 정규형(Normal Form)을 만족하는 중복이 배제된 데이터 모델에 대해 성능저하 등의 문제를 해소하기 위해 의도적으로 중복을 허용함을 의미한다. 데이터 모델러들이 견지해야 할 자세 중 하나가 중복 배제 내지는 최소화일 것이다. 그러나 정보 서비스는 중복을 최소화한 데이터 모델 또는 데이터 품질 확보뿐만 아니라, 적정 성능을 확보하는 것도 빼놓을 수 없는 핵심 요소다. 따라서 성능 요건을 만족하지 못하는 응용 서비스가 존재하고, 이 문제를 해결하기 위한 유일한 방법이 데이터 중복이라면 데이터 모델러들이 적극적으로 개입해 해소방법을 모색해야 한다.

데이터 중복을 허용하는 역정규화의 주요 사유를 조금 더 구체적으로 살펴보면 다음과 같다.

응용 프로그램 단순화를 위해

성능 개선을 위해

2.1 응용 프로그램 단순화 요구 대응

개발자 또는 개발 리더로부터 역정규화 요건을 수용하다 보면 개발단계 초기부터 중기까지는 성능 개선보다 응용 프로그램 단순화를 위한 역정규화 요구가 주를 이룬다.

개발자들 입장에서는 테스트에 필요한 최소한의 데이터만으로 개발과정을 진행하므로 당장의 성능 문제를 해소할 필요성을 못 느끼고 본인이 작성한 응용 프로그램의 성능에 어떤 문제가 있을 것인지 충분히 고민할 여력도 없다. 또한 기술적인 부분에 있어서도 성능 문제가 발생할 개연성이 있는지 판단할 능력도 부족한 것이 보편적 현실이다.

한편 데이터 중복을 최소화하다 보면 응용 프로그램에서 필요로 하는 데이터가 여러 테이블에 분리-수용될 가능성도 올라간다. 응용 프로그램 작성 시 여러 테이블을 이용함에 따라 로직의 복잡도가 증가하므로 이를 단순화하기 위해 역정규화 요청을 하는 경우가 발생한다.

응용 프로그램 단순화를 위한 역정규화 요청에 대해 데이터 모델러들은 어떻게 판단해야 할까? 무조건 수용하는 것이 답일까? 거부해야 할까?

다음에 몇 가지 기준을 제시하고자 한다.

응용 프로그램 단순화 만을 위한 역정규화 요청은 수용하지 않는 것을 원칙으로 하며, 이를 사전에 응용 프로그램 개발 조직에 통보한다.

데이터 중복을 허용하면 응용 프로그램 복잡도가 감소되는 경우는 대체로 성능적인 측면에서의 검토 필요성도 수반될 수 있으므로 성능 관점에서 다시 점검하고 대응한다.

성능 관점에서 별다른 문제가 없더라도 다음과 같은 경우에는 예외적으로 데이터 중복을 허용할 수 있다. 하지만 데이터 중복에 따른 반대급부, 즉 중복 데이터의 정합성 유지를 위한 Insert, Update 응용 프로그램 로직 수정과 성능 저하 수준에 대한 예측과 대응이 선행되어야 한다.
- 데이터 중복에 의해 복잡도가 현격하게 줄어드는 경우
- 복잡한 로직이 매우 빈번하게 실행되는 경우
- 매우 많은 응용 프로그램에 해당 로직을 적용할 필요가 있는 경우

2.2 성능 개선 요구 대응

서두에 언급한 바와 같이 데이터 모델링을 하는 설계 단계를 지나 개발 단계에 접어들면 데이터 모델러들도 응용 프로그램 개발조직으로부터 역정규화 요청을 받아 처리하는 일련의 업무 프로세스를 규정해 운영할 필요가 있다. 이는 응용 프로그램 개발조직에서 성능 문제를 사전에 인지하고 필요에 따라 역정규화 요청을 통해 성능 문제 해소를 위해 적극적이고 선제적인 대응이 가능하도록 길을 열어두기 위함이자, 다른 한편으로는 성능 문제 해소를 위한 역정규화의 책임이 응용 프로그램 개발조직으로부터 시작됨을 인식시키기 위함이다.

개발 단계 초기부터 이러한 역정규화 요청 프로세스를 열어두고 대응하고자 함에도 역정규화에 대한 진지한 고민과 요청을 대체로 개발 단계 후기 또는 통합 테스트 단계에서 본격화 된다. 이 시기에는 AS-IS 데이터를 TO-BE 데이터베이스에 이관해 많은 데이터가 적재된 상황에서 개발되거나 테스트가 시행됨으로써 성능 저하가 프로젝트 진행에 직접적인 영향을 미치기 때문이다. 대규모의 차세대 정보시스템 구축 사업에서는 보편적으로 성능 개선을 위한 전문 조직을 운영하며, 개발 후기 또는 통합 테스트 시기에 집중 투입되는 것을 볼 수 있다. 역정규화도 이런 전문 조직이 성능 개선 작업 과정에서 데이터 중복 외에는 성능 문제 해소 방법이 없다고 판단될 때에야 비로소 요청된다.

개발 단계 후기 또는 통합 테스트 단계에서의 역정규화 요청은 다음과 같은 문제 또는 고려사항이 있으므로 주의하여 의사 결정해야 한다.

데이터 정합성 유지를 위해 기존에 개발했던 Insert, Update, Delete 관련 응용 프로그램을 찾아 개선해야 하는 부담이 따름

기존에 개발했던 조회 프로그램들 중에서도 데이터 중복 환경에서 성능이 더 좋아질 수 있는 경우가 있다면 개선하는 것이 타당하나 납기 등의 문제로 부담을 느낌

AS-IS 데이터를 TO-BE 데이터베이스로 전환하는 응용 프로그램의 개선 및 데이터 재전환 작업이 수반됨

성능 측면에서 인덱스 구성을 달리할 수도 있으므로 검토가 필요함

이와 같은 점들을 고려한다면 역정규화는 최소화해야 하고, 필요 시 설계 단계에서 인식하거나 혹은 개발 단계 초기에 인식하고 대응하는 것이 무엇보다 중요하다.

2.3 데이터 중복 조기 대응 방안

조금이나마 데이터 중복을 위한 역정규화 검토를 시기적으로 앞당길 수 있는 방안으로는 AS-IS 데이터베이스의 데이터 중복 요소로부터 필요성을 인식하는 것으로써 다음과 같은 방법으로 진행할 수 있다. 본 과정은 설계 단계 혹은 개발 단계 초기에 진행할 수 있으며, AS-IS 운영 담당자의 도움이 필요하다.

이 방법을 프로젝트에 적용하기 위해서는 설계 단계 등에 위 과정을 위한 Activity나 Task를 미리 정의해두는 것이 좋다. AS-IS의 데이터 중복 사유가 성능 개선이며 성능 개선을 위해 중복을 필수 불가결한 요소 였는지를 판단할 수 있는 경험과 기술력이 요구된다.

또한 AS-IS 데이터베이스의 데이터 중복 필요 기능이 TO-BE에서도 여전히 유요한 것인지에 대한 확인이 필요하다.

데이터 중복은 그 필요가 인정된다 하더라도 데이터 구조적 특성과 업무적 의미에 따라 중복이 불가능한 경우가 있다. 이와 관련해서는 다음 기고를 통해 소개하고자 한다.

출처: 한국데이터진흥원 데이터 전문가 지식포털 DBguide.net

▶ 데이터 품질 보장과 애플리케이션 성능 확보 사이에서 (下)