대메뉴 바로가기 본문 바로가기

데이터 기술 자료

데이터 기술 자료 상세보기
제목 데이터베이스의 생과 사 / 데이터베이스를 안정화시켜라
등록일 조회수 6714
첨부파일  

데이터베이스의 생과 사

연재 순 서

1회 | 2004.1 | 데이터베이스를 안정화시켜라
2회 | DBMS의 통제 관리 능력을 어떻게 키울 것인가

미션 1, 데이터베이스를 안정화시켜라

기업 정보화의 저변에는 정보시스템의 핵심이라 할 수 있는 데이터베이스 시스템이 있다. 본지에서는 신년기획으로 ‘데이터베이스의 생과 사’란 주제로 개발 시점의 DB 생성부터 시스템 오픈, 안정화, 운영, 그리고 폐기까지 각 시기마다 데이터베이스 측면에서 해야할 일과 관리 요소를 다루고자 한다. 이번 원고에서는 데이터베이스의 생성, 오픈, 안정화로 구축시 가장 중점적으로 고려할 사항들에 대해 알아보자.

장희식 | changheesik@hotmail.com

무슨 일이든 제대로 올바로 하자는 가치관을 가지고 자연의 법칙(원칙)이 통하는 사회를 꿈꾸며, 현업의 정보요구를 어떻게 정확히 파악할 것인가에 노력을 기울여 왔다. 현재는 엔코아정보컨설팅 모델링 솔루션팀의 수석컨설턴트로서 프로젝트 산출물을 통한 논리 모델과 물리 설계의 연결성에 대한 일반적인 원리를 정리하며 많은 프로젝트에서 데이터 모델링 컨설팅을 수행하고 있다.

왜데이터베이스 관리 시스템(이하 DBMS)을 도입하는가? 현재의 데이터베이스는 어떤 문제점이 있어 재구축을 하게 되는가? 가장 핵심적인 사항은 정확한 정보를 적기(適期)에 제공받지 못한다는 데 있을 것이다. 이 글에서는 데이터베이스의 생성을 위해 가장 심혈을 기울여야 할 부분인 데이터 모델링의 전반적인 절차, 업무 규칙이 정의된 논리적인 데이터 모델을 물리적인 DBMS에 맞춰 생성할 때 고려해야 할 점, 기존 시스템을 목표 시스템으로 전환하는 데 있어서의 이행(migration) 절차, 오픈 후 데이터베이스 내지는 시스템의 성능에 영향을 미치는 요소의 파악 및 해결, 마지막으로 안정화를 위해 노력해야 할 부분에 대해 소개한다.

왜 DBMS를 사용하는가?

왜 DBMS를 사용하는가? 무슨 장점이 있는가? 이 질문에 대한 답은 어느 정도까지는 시스템이 단일 사용자 시스템(Single User System)인가 또는 다중 사용자 시스템(Multi User System)인가에 달려 있다.

우리는 종이에 기록하는 전통적인 방법 또는 파일(file) 시스템에 비해서 DBMS의 장점이 무엇인지를 먼저 살펴보고, 왜 DBMS를 도입해야 하며 DBMS 도입시 데이터베이스를 어떻게 생성하며 DBMS의 안정화를 위해서 노력할 부분은 무엇인지 살펴보자.

DBMS의 장점을 살펴보면 그 해답은 쉽게 나온다. 먼저 DBMS를 통해 데이터의 공유가 가능하다는 점이다. 이는 각각의 사용자들이 서로 다른 목적으로 데이터베이스 내의 같은 데이터에 접근(access)할 수 있다는 의미이다. 하지만 공유를 할 수 있다는 전제 조건은 데이터베이스가 통합되어 있어야 한다는 것이다. 통합되어 있지 못한 데이터베이스는 데이터의 중복을 초래해 데이터를 공유하는 데 있어 정보의 불일치라는 심각한 문제를 야기할 수 있다.

다음으로 중복성(redundancy)의 감소를 들 수 있다. 데이터베이스를 갖고 있지 않는 경우 각 응용 시스템은 각각의 개별적인 파일을 갖는다. 이 경우 데이터는 상당한 중복성을 갖게 되며 많은 양의 디스크가 낭비된다. 그렇지만 모든 중복성을 제거해야 한다는 것은 아니다. 때때로 동일한 저장 데이터를 여러 개 유지하는 것이 업무나 기술적인 측면에서 타당한 경우도 있다.

또한 압축성(compactness)과 생산성(productivity)도 DBMS의 장점 중 하나다. 이것은 DBMS의 장점이라기보다는 정보를 종이에 기록하는 것보다 컴퓨터를 이용해 정보를 저장하는 것이 많은 양의 종이 파일을 필요로 하지 않는 이점이 있다고 할 수 있다. 특히 생산성의 경우 기계는 인간보다 훨씬 빨리 데이터를 검색하고 변환시킬 수 있다는 특징 때문에 즉석의 질의(ad-hoc query)를(예 : 개인 고객인 법인 고객보다 많은가?) 수작업에 의한 시간을 낭비하지 않고 신속히 처리할 수 있다.

이런 장점들은 데이터베이스가 단일 사용자의 경우보다 훨씬 크고 복잡한 다중 사용자 시스템의 경우에 훨씬 엄격하게 적용된다. DBMS를 갖지 않는 파일 시스템은 각 응용 프로그램마다 별개의 파일을 테이프나 디스크로 유지하며 데이터가 광범위하게 분산되어 있어 체계적인 방법으로 데이터를 제어하기가 어렵다. 즉, DBMS는 데이터의 중앙집중 제어(centralized control)를 기업체에 제공한다.

너도나도 데이터베이스 구축?

그렇다면 데이터베이스 구축은 어떻게 진행이 되는 것일까? 다음에서 예로 든 XX대학의 경우를 살펴보며 과연 자사의 경우는 어떠한지 생각해보도록 하자.

XX대학 내 그 대학 조직의 하나로써 전산부서가 있다고 하자. 학생과 교직원, 교직원이 가르치고 학생이 배우는 교과과정의 관리, 대학 내 도서관에서 도서와 도서대여에 관한 관리, 그리고 학생들의 동아리에 대한 관리 등이 그 부서의 업무이다. 이러한 대학 내 정보 시스템은 한 번에 구축된 것이 아니라 여러 해 걸쳐서 구축되었다고 가정한다.

◆ 학사 관리 시스템 : 첫 번째 시스템으로 학생의 정보를 기록하는 시스템을 1976년에 개발하였다. 이 시스템은 프로그래머들이 COBOL을 잘 알고 있는 관계로 모든 프로그램이 COBOL로 구축되었다. 학생 마스터 파일은 학번, 성명, 주소, 전화번호, 학과, 출신고교, 입학점수, 성별 등을 포함하고 있으며, 교직원 마스터 파일, 교과목 마스터 파일, 학생의 수강 성적 등을 관리하고 있다.

◆ 도서 관리 시스템 : 두 번째 시스템으로 도서관의 모든 정보를 기록하는 시스템을 1986년에 개발하였다. 이 시스템은 프로그래머들이 C를 잘 알고 있는 관계로 모든 프로그램이 C로 구축되었다. 이 부서에서도 도서를 빌리는 학생을 관리하기 위해 학생 마스터 파일을 만들면서 학번, 성명, 계열, 학과, 전공, 전화번호 등을 포함하고 있으며, 도서관직원 마스터 파일, 도서 마스터 파일 등을 관리하고 있다.

◆ 동아리 관리 시스템 : 세 번째 시스템으로 동아리에 대한 모든 정보를 기록하는 시스템을 1996년에 개발하였다. 이 시스템은 인터넷의 발달과 사용자들의 편리성을 위해 프로그래머들이 ASP(Active Server Page)를 이용해 모든 프로그램을 구축하였다. 이 부서에서도 동아리 관리를 위해 학생 마스터 파일을 만들면서 학번, 성명, 계열, 학과, 전공, 전화번호 등을 포함하고 있으며, 담당교수 마스터 파일, 동아리 마스터 파일 등을 관리하고 있다.

학생 명단 가나다순으로 제출?

세월이 흐르면서 이 시스템은 XX대학을 위한 업무 요구 사항을 그런대로 잘 수행해 왔다. 그러던 어느 날 대학 총장이 이사회로부터 다음과 같은 전화를 받았다. “AA고교 출신으로, 동아리 활동을 하며, 여성 교수에게 수강한 학생의 명단을 가나다순으로 제출하시오. 이러한 명단을 2시간 이내에 제출하면 S협회로부터 50억의 기부금을 받을 수 있습니다.”

흥분된 대학 총장은 정보시스템 실장에게 이러한 요구 사항을 전달하였다. 이러한 요구 사항을 전달 받은 정보시스템 실장은 곰곰이 생각하다가 대학 총장에게 다시 전화를 걸어 이러한 요구사항을 2시간 내에 제출하지 못하는 이유를 설명하기 시작하였다.

정보시스템 실장의 비통한 설명은 대학 정보시스템 내에 이러한 요구 사항을 만족시키는 정보가 모두 저장되어 있지만 그렇게 빠른 시간 내에 그런 정보를 찾아내는?이터의 물리적인 저장 방식이 틀리고, 결정적으로 여러 개의 파일들을 하나로 묶어서 정보를 추출해 낼 수가 없다는 것이다. 그 이유에 대해 정보시스템 실장은 데이터의 구조와 포인터에 대한 개념을 설명하였다. 이러한 설명에 대해 총장은 분노하면서 말하기를 “우리가 이렇게 고가의 컴퓨터를 도입하였고, 원하는 정보가 컴퓨터 내에 존재하고 있는데, 어째서 내가 그 정보를 얻을 수 없단 말이요?” 이런 일이 있은 후 정보시스템 실장과 대학 총장은 책임을 통감하며 그 대학을 떠나고 말았다.

정보시스템 실장과 대학 총장이 그 대학을 떠난 후, 많은 부서의 관리자들은 그들의 정보요구사항이 다른 부서의 정보요구사항과 다르다는 이유로 자기 부서만의 마스터 파일들을 요구하기 시작하였다. 그리하여 각 부서의 사무관들은 누가 대학에 입학하고 졸업했는지에 대한 이력을 알기 위해 마스터 파일들을 만들었다. 사무관들은 학생에 관해 학생 마스터 파일에 현재 유지되고 있는 정보에 추가적인 정보를 관리하기를 원했다. 전산부서는 이러한 문제에 직면하였으며, 사무관들은 학생 마스터 파일에 출신고교, 고교성적, 선발되는 학생의 상담교사 등의 항목을 포함하게 되었다.

도서관 직원은 대학 내 모든 관계자(학생, 교수, 직원 등)들의 도서 대여에 관한 업무를 위해 학생, 교수, 직원 마스터 파일을 요구하였다. 그는 현재 도서 대여 권수, 과거 도서 대여 권수, 총 과태료 등의 항목을 추가하기를 원했다. 또한 그들은 레코드의 첫 번째 항목으로 학생의 이름, 그 뒤에 주소, 학번, 과태료, 현재 도서 대여 권수, 과거 도서 대여 권수를 원했다. 하지만 그들은 성별, 입학점수 같은 항목은 필요가 없었다.

장학과나 기숙사에서도 그들만의 학생 마스터 파일을 갖기를 원했다. 그래서 학생의 마스터 파일은 각 부서에 따라서 여러 개를 가지게 되었다. 여러분이 보는 바와 같이 각각의 부서의 요구에 의해 자신만의 학생 마스터 파일이 4개(도서관, 동아리, 장학과, 기숙사)가 생겼으며, 4개의 부서에서 각각 학생 마스터 파일을 수정하는 일이 발생하게 되었다.

XX 대학의 문제는 무엇인가?

그렇다면 XX 대학의 문제는 무엇이었을까? 첫째 각각의 시스템마다 프로그램들이 다른 언어로 생성되면서 데이터 필드의 형태(format)가 다른 것이 문제를 가중시키고 있다. 어떤 레코드의 형태는 사용자의 요구에 의해 재조정되어야 할 것이 있고, 어떤 데이터 필드는 재설계가 되어야만 한다. 도서관 마스터 파일의 또 다른 중요한 문제점을 보면 학생이 현재나 과거에 한 권 이상의 책을 빌려갈 수 있다. 이러한 것을 표현하기 위해서는 각각의 레코드가 입력될 수 있는 데이터 필드가 필요할 것이다(각각의 책의 제목이 입력될 수 있는 배열(array)의 데이터 필드를 생각해 볼 수 있다). 명백한 것은 이러한 파일의 형태가 이상적인 시스템을 만드는 좋은 방법은 아니라는 것이다. 접근의 유연성(flexible accessibility)은 DBMS가 추구하는 목표 중 하나이다.

둘째 앞의 예에서 나타나는 문제는 데이터 무결성(integrity)에 관한 것이다. 각자의 마스터 파일에 같은 데이터가 저장되어 있다면 공통의 성격을 갖는 데이터를 공유해 사용할 가능성은 거의 제로이다. 보는 바와 같이 각 부서가 자신만의 마스터 파일을 보유해야 하는 이유는 각 사용자들이 이용하는 데이터가 조금씩 다르다고 느끼기 때문이다. 즉, 그들의 기능에 적합한 데이터에 접근할 수 있도록 해달라는 이유뿐이다. 중복 데이터의 제거와 부서 중심의 마스터 파일(personal master file)의 제거가 DBMS가 추구하는 또 하나의 목표다.

셋째 문제는 프로그래머가 여러 가지의 프로그램 언어로 프로그램을 작성하기를 원한다 하더라도 각 파일에 내재된 데이터에 접근하는 데 있어서 프로그램 언어에 따라 프로그램 작성이 틀려지면 안 된다. 이러한 목표를 데이터 독립성(data independence)이라고 하는데, 이는 프로그램 언어, 운영체계(operating system), 처리환경(batch or online)에 종속되어서는 안 된다는 것이다.

왜 DBMS를 재구축해야 하는가?

앞의 시나리오가 DBMS를 도입하기 위한 단순한 시나리오라고 생각한다면 그건 커다란 오산이다. 필자는 R-DBMS 이전부터 파일이나 계층형 DBMS를 사용해 시스템을 구축했다. 80년대 후반이나 지금이나 시스템 개발에 있어서 발생하는 문제는 거의 대동소이한 것 같다.

가장 근본적인 문제는 기업 정보시스템의 핵심이 되는 업무를 제대로 파악하지 않고 시스템을 구축하는 데 원인이 있다고 본다. 특히 데이터 중심의 접근 방법이 아니라 처리 중심의 접근 방법에 익숙한 사람들이 분석·설계·개발을 전담하다 보니, 이러한 문제가 해결되지 않고 계속해 많은 문제점을 양산하고 있다.

대부분의 기업에 있어서 정보시스템 구축시 데이터베이스 내의 데이터 구조가 사용자에게는 숨겨진 형태로 구축되어 왔다. 이런 식의 시스템 구축은 많은 문제점을 발생시키는 원인이 되었는 데, 사용자와의 의사소통 문제를 야기하고 가장 중요한 데이터의 중복 문제를 야기했으며, 이로 인한 데이터의 일관성과 정확성을 깨트리는 데이터 무결성(integrity) 문제를 야기했다. 또한 비즈니스 요구에 상당히 비탄력적인 문제를 야기해 낮은 생산성으로 사용자의 정보 요구를 만족시킬 수 없는 상태에 이르고 있는 것이다. 앞의 시나리오는 이러한 문제를 다 가지고 있는 것인데, 현재 진행하고 있는 프로젝트나 현재 사용하고 있는 시스템에 대해 재고해 본다면 필자가 얘기한 이러한 문제들을 상당히 안고 있을 것이다.

여기에 한 가지 더 얘기한다면 운영시스템의 성능(performance) 문제이다. 이 문제 또한 관계형 데이터베이스 이전의 처리 방식인 레코드 처리 방식(한 번에 한 건의 레코드를 처리하는 방식)으로 처리하고 있어 발생하는 문제이며, 관계형 데이터베이스의 특징인 Set 처리와 인덱스 및 Join 방식 등 옵티마이저의 원리를 모르고 관계형 데이터베이스를 사용하고 있어 DBMS 성능에 많은 문제점을 야기하고 있는 것이다.

데이터베이스의 생성

순 공학(forward engineering)이든 역 공학(reverse engineering)이든 앞에서 얘기한 데이터베이스를 재구축하는 핵심 원인에 대해서는 깊이 생각해 봐야 한다. 이러한 문제점이 계속 증가해 우리가 원하는 정확한 정보를 적기에 공급받을 수 없는 경우 데이터베이스 재구축을 심각히 고려해야 하는 것이 데이터베이스 재구축의 핵심 원인이라 할 수 있다.

일단 DBMS가 기본으로 제공하는 특성을 고려하면서 데이터베이스를 생성하기 이전에 우리가 원하는 논리적인 데이터 구조와 기존의 DBMS에는 없고 관계형 데이터베이스에만 있는 개념인 무결성(integrity, 업무규칙)을 어떻게 보장하느냐를 논리적으로 분석해 놓는 것이 데이터베이스 생성에 있어서 가장 먼저 선행되어야 할 일이다. 이는 좋은 데이터베이스를 생성하는 가장 중요한 일이며 이러한 과정이 곧 논리적 데이터 모델링(Logical Data Modeling)이다.

논리적 데이터 모델링

논리적 데이터 모델링이란 기업의 업무에 대한 종합적인 이해를 바탕으로 데이터에 존재하는 업무규칙에 대해 참(true) 또는 거짓(false)을 판별할 수 있는 사실을 어떻게(how), 누가(who) 접근하는지, 또한 전산화와는 별개로 인식해 이를 명확하게 표현하는 추상화 기법이다. 다음의 사항들은 논리적 데이터 모델에 표현될 수 있는 비즈니스 사실들이다.

◆ 사원은 부서에 소속되어 있다.
◆고객이 상품을 주문한다.
◆ 어떤 사람은 대출금을 제때에 상환하지 못한다.

또한 우리가 굳이 보고서를 만들어 내지 않더라도 혹은 질의(query)에 대한 답을 제공하지 않더라도 이러한 사실들은 참이다. 이러한 사실들을 이해하고 사용자 비즈니스의 중요한 부분을 인식해 좀더 훌륭한 데이터 모델을 만든다면 또한 데이터베이스 기술을 이용해 사용자의 정보요구를 충족시키는 데 유리한 고지를 점령할 수 있을 것이다. 비록 이러한 사실이 데이터베이스로 구현되지 않더라도 논리적 데이터 모델은 비즈니스를 이해하는 데 많은 도움을 줄 것이다.

논리적 데이터 모델링 절차

이 글에서는 데이터베이스의 생성, 오픈, 안정화라는 주제 하에서 너무 상세한 데이터 모델링의 내용은 피하기로 하겠다. 차후 지면이 할애된다면 그 때 좀더 상세한 내용을 다루기로 하고, 주제영역, 엔티티, 속성, 관계 및 업무규칙 정의에 대해서만 간략하게 설명하겠다.

주제 영역 정의

주제 영역은 기업이 관심을 가지는 데이터의 자연스러운 집합이다. 제조업체 경우를 예로 들면, 구매 분야, 생산 분야, 판매 분야, 인사 분야, 회계 분야 등의 주제 영역이 있을 수 있으며, 은행의 경우는 수신 분야, 여신 분야, 외환 분야, 인사 분야, 회계 분야 등의 주제 영역이 있을 수 있다.

데이터는 기본적으로 관계구조로 표현되는 데, 관계구조는 데이터들 간의 관계가 복수 개로 표현되면서 서로 연결되어 있기 때문에 하향식(top-down) 분석이 용이하지 않다. 계획수립 단계는 하향식 분석을 원칙으로 하고, 검증을 위해서 부분적으로 상향식(bottom-up) 분석을 사용한다. 데이터를 하향식으로 분석하기 위한 개념으로 유용한 것이 주제 영역이며, 주제 영역은 데이터를 계층적으로 표현할 수 있는 기법이다.

좋은 모델링을 위한 하나의 기준은 분할 후 정복(divide and conquer)이라는 개념을 적용시킨다는 것이다. 전체 업무를 점차적으로 세분화해 나가면서 정해진 규칙을 이용해 모델링을 해 나간다. 세분화 과정을 분해(decomposition)라 부른다. 분해는 일정한 기준에 의해 대상을 구분하는 과정으로 여러 방법이 가능하다. 예를 들어 한 회사의 고객들을 나누는 방법은 성별, 지역, 고객 구분 등 여러 방법이 있을 수 있다. 어떤 기준을 적용하는 것이 가장 좋은 분해인가에 대해서 생각해야 되는 데, 그것은 분해의 목적에 적합한 기준을 선택하는 것이다.

엔티티 정의

엔티티는 기업이 관심을 가지는 의미 있는 유용한 정보를 제공하기 위해 동일한 사실을 보관하는 인스턴스들의 집합이다. 인스턴스는 기업에 의미 있는 데이터 단위를 뜻한다. 예를 들어 “이영희”, “김철수”, “홍길동” 등이 우리 회사에 근무하는 사람이라면, 이 세 사람을 일반화(generalization)하고, 추상화(abstraction)해 표현할 수 있는 하나의 단어가 “사원”이라는 엔티티가 되는 것이고, 이 세 사람은 “사원” 엔티티의 인스턴스가 되는 것이다. 어떤 책에서는 “엔티티 타입”과 “엔티티”라고 표현하고, 어떤 책에서는 “엔티티”와 “인스턴스”로 표현하고 있다. 필자는 “엔티티”와 “인스턴스”로 표현하고자 한다. 즉, 엔티티는 인스턴스들의 추상화된 집합인 것이다.

이러한 엔티티는 우리가 기업의 비즈니스를 파악해 시스템화하는 데 있어 우리가 관심을 가지고 관리하려는 대상인 것이다. 이러한 엔티티는 다음과 같은 특성을 가진다.

첫째 가로(tuple, row)와 세로(attribute, column)에 의한 면적을 갖는다. 즉, 엔티티는 집합이라는 것이다.
둘째 다른 엔티티와 구별할 수 있는 독립성을 갖는다. 마지막으로 엔티티 내 인스턴스들은 동질성을 갖는다는 것이다.

속성 정의

속성 또한 기업이 관심을 가지는 의미 있는 유용한 정보를 제공하기 위해 중요한 사실을 내포하고 있는 것으로, 엔티티를 묘사, 서술, 양의 계수화, 자격 부여, 분류를 하는 등 엔티티를 구체화하는 정보 항목이다. 예를 들어, “사원”이라는 엔티티는 “성명”을 갖고 있으며, 또한 “주소”, “전화번호” 등의 특성을 가지고 있으며, “사원”에 속하는 모든 인스턴스들이 가지는 이러한 각각의 특성을 속성(attribute)이라고 부르며, 각 엔티티는 일련의 속성들에 의해 상세화되는 것이다. 속성에서 가장 중요한 개념은 속성의 원자성(atomic)이다.

속성의 원자성 개념

E.F.Codd 박사의 12가지 관계형 규칙 중 보장된 접근 규칙(Guaranteed Access Rule, 관계형 데이터베이스의 모든 자료(더 이상 분리되지 않는 단위 값)는 테이블 명, 프라이머리 키 값, 그리고 열 이름을 조합함으로써 논리적으로 접근이 보장되어야 한다)을 보면 더 이상 분리되지 않는 단위 값으로 정의하고 있다. 다시 말하면 테이블 내 모든 속성은 원자 속성으로 업무에 대한 단일 사실(single fact)을 나타내며 그 안에 의미가 있지만 모델 사용자들에게 숨겨져 있을지도 모르는 어떠한 다른 사실들을 포함해서는 안 된다.

이렇게 컬럼이 원자 값(atomic value)으로 분리되지 않으면 무엇이 문제인가? 계좌번호(14) = 지점코드(3) + 상품코드(2) + 고객번호(6) + 일련번호(3)로 구성되어 있는 예를 가지고 설명해 보겠다.

첫째 속성은 단일 사실, 단일 개념을 나타내야 한다는 정의를 어기고 있다. 명백히 계좌번호에 많은 사실을 기록하고 있다. 둘째 회사가 계속 성장해 지점이나 상품의 개수가 늘어난다면 이 자릿수만으로는 만족을 못 시킬 것이고, 또한 은행의 지점은 수시로 통폐합이 발생한다면 이 계좌번호가 여기서는 프라이머리 키로 역할을 하며 분명 다른 테이블과 관계를 맺고 있을 것인데 그 하위 테이블에 나타나는 참조 값들의 변경은 어떻게 감당할 것인가?

셋째 구성 요소(지점코드, 상품코드, …)의 특성들을 숨기거나 모호하게 해 계좌번호만 보고는 업무적으로 계좌번호가 구성된 업무 규칙을 못 보여주며, 모델의 다른 요소들에 대한 여러 종속성(예, 지점, 상품, 고객과의 관계)을 모호하게 하고 있는 것이다.

넷째 원자 값이 아닌 속성은 접근 경로(access path)를 잃어버린다는 것이다. 이러한 경우 SQL 구현시 원자 값으로 컬럼이 구성되어 있지 않으면 접근 경로를 잃어버릴 것이다. 예를 들어 SQL의 WHERE 조건에 substr(계좌번호, 4, 2) = 상품코드 식으로 SQL을 구사하는 경우를 가끔 볼 텐데, WHERE 조건의 좌변이 가공되면 인덱스 사용을 못하고 FULL TABLE SCAN을 하게 된다. 물론 오라클의 경우 FBI(Function Based Index)를 사용하면 접근경로를 잃어버리지 않지만 이는 어디까지나 특정 제품에 한정된 것이고, 이를 사용하려면 정기적으로 분석을 해줘야 하는 부담이 있다. 이렇게 접근 경로를 잃어버리게 설계가 되어 있다 보니 이 접근 경로를 잃어버리지 않기 위해 각각의 원자 속성으로 중복관리를 하고 있는 것이다.

관계형 데이터베이스 내 컬럼의 원자단위 속성 규칙이 현실에서 위배되는 경우는 이 외에도 제조회사의 제품코드 등 각종 식별자, 그리고 텍스트 블럭(예를 들어 취미 컬럼)이나 주석 속성들 등에서 많이 볼 수 있다.

관계 정의

앞에서 “사원”이라는 엔티티를 예를 들었는데, “부서”와 같이 이제 사원을 생각해 보자. 한 사람의 사원은 하나의 부서에 소속되어 있을 것이다. 즉, 하나의 “부서”에는 여러 명의 “사원”이 속해 있다. 이때 “부서”와 “사원”이 연관되는 비즈니스상의 이유인 “속해 있다”가 관계(relationship)가 되는 것이다. 다시 설명하면 “부서” 엔티티에는 “인사부”, “생산부”, “영업부” 등의 “부서” 인스턴스가 존재할 것이며, “사원” 엔티티에는 “홍길동”, “김길동”, “박길동” 등의 “사원”의 인스턴스가 존재할 것이다. 이때 “홍길동”은 “인사부”, “김길동”은 “생산부”, “박길동”은 “영업부”에 소속되어 있다고 할 때, “부서” 하나의 인스턴스(예:인사부)와 “사원” 하나의 인스턴스(예:홍길동)와 연관되어 있는 사실(속해있다)을 페어링(pairing, 짝)이라고 한다.

여기서 이러한 페어링을 모아서 일반화하고 추상화해 표현한 것을 관계라고 하는 것이다. 즉, 관계는 페어링(짝)의 집합이다. 관계가 갖는 주요한 업무 사실을 나타내는 특성은 관계의 기수성(cardinality, degree)과 선택성(optional)이다.

◆ 기수성

- (1:m) : one to many relationship
- (1:1) : one to one relationship
- (m:m) : many to many relationship

◆ 선택성

- 필수(실선) : 다른 실체에 어떤 row를 입력하기 전에 이 실체에 적어도 한 건의 row가 반드시 있어야만 하는 경우
- 선택(점선) : 다른 실체에 어떤 row를 입력하기 전에 이 실체에 어떤 row가 존재할 필요가 없는 경우

◆ 관계형태 정의 

1:다 1:1 다:다

업무 규칙 정의

업무규칙 정의는 논리 데이터 모델링의 핵심이라 할 수 있다. 우리가 구축하고자 하는 시스템의 입력 또는 수정 프로그램의 70~80%, 심지어 90%가 정확한 데이터를 입력받기 위해 데이터를 검증하는 로직(logic)인 것이다. 이러한 로직(정확한 데이터를 입력받기 위한 검증 작업)이 대부분의 사람들은 프로세스 로직이라고 생각하는 경향이 많은데, 이는 다소 잘못된 생각이다. 데이터가 갖는 업무 규칙이 논리 데이터 모델링 단계에 다 파악이 되어야 하는 업무 규칙인 것이며, 이러한 개념을 DBMS 내에 구축하고자 노력한 산물이 무결성이라는 개념이다. 그러나 이러한 무결성 개념은 DBMS 내에 구축할 수도 있고, 프로그램으로도 처리할 수 있는 것으로 논리적으로는 데이터 모델링 과정에서 다 파악되어야 할 업무 규칙이다.

데이터 무결성

사용자가 관계연산자(select, join 등)를 수행할 때 데이터 값을 관장하는 업무규칙을 말한다(set of business rules that govern how relational data values behave when users perform relational operations).

◆ 실체 무결성 규칙(entity integrity rule) : 주 식별자(PK: 특정 행을 유일하게 인식하는 하나 이상의 열)는 Null 값을 포함하지 않는다.

◆ 참조 무결성 규칙(referential integrity rule) : 관계 테이블의 모든 외부 식별자(FK) 값은 연관되어 있는 관계 테이블에 주 식별자(PK) 값이 존재해야 한다.

◆ 영역 무결성 규칙(domain integrity rule) : 테이블 내의 모든 열(column)에 관한 무결성 규칙으로 데이터 타입, 길이, 허용 값, 기본 값, 유일성, Null 여부 등에 관한 제한이다.

◆ 연쇄 작용(triggering operation) : 입력, 삭제, 수정, 조회 등의 작업이 동일 엔티티 혹은 다른 엔티티의 속성에 미치는 영향을 정의하는 것으로 업무 규칙에 관련된 데이터 무결성의 마지막 형태이다.

앞에서 간단하게 모델링의 절차에 해당되는 것들에 대해서 설명했는 데, 이러한 사항들은 데이터베이스를 설계하기 이전에 논리적(logical)으로 우리가 업무를 파악해야만 하는 대상인 것이며 질 좋은 데이터베이스를 만들기 위해 기본으로 파악해야 할 중요한 사항이다. 다음으로 데이터베이스의 설계 부분에 대해서 살펴보자.

데이터베이스 설계시 고려사항

설계 단계에서는 DBMS의 종류를 결정한 상태에서 가장 DBMS에 적합한 설계를 해야 한다. DBMS가 결정된 상태에서 설계가 진행되므로 설계자는 관련된 제품의 특성을 정확하게 알고 있어야 성능도 우수하고 관리도 편한 효과적인 데이터베이스 설계를 할 수 있다. 여기서는 일반적으로 고려해야 할 사항인 명명 표준 정의, 논리 구조 전환, 논리 무결성 전환, 그리고 인덱스 전략에 대해서만 간략히 알아보겠다.

명명 표준 정의

명명 표준 정의는 테이블, 컬럼, 인덱스, 테이블 스페이스, 각종 Constraint 등 DBMS의 모든 오브젝트 명칭에 관한 표준을 정하는 것이다. 논리적 데이터 모델링 단계에서도 명명 규칙은 상당히 중요하며, 마찬가지로 설계 단계에서도 좋은 명명 규칙은 좋은 시스템의 기본이다. 부실한 명명 규칙은 프로젝트 전 기간에 걸쳐서 의사소통에 문제를 일으키며, 많은 시간을 잡아먹는 나쁜 요소이다. 이러한 것을 잘 관리하기 위해 데이터 딕셔너리(Data Dictionary)를 잘 만드는 것이 중요하다.

논리 구조 전환

앞에서도 서술한 바와 같이 설계 부분은 특히 DBMS에 종속적인 부분이 상당해 일반적으로 체크해야 할 사항에 대해서만 간략하게 정리하고자 한다.

◆ 테이블 및 컬럼 설계

- 테이블/컬럼의 명칭은 표준 명명 규칙을 준수해 작성한다.
- 컬럼 명칭에 SQL의 예약어(Reserved Word)는 사용하지 않는다.
- 필수입력 속성은 NOT NULL로 지정한다.

◆ 도메인 설계

- 표준에 의해 데이터 타입 및 길이를 결정한다.
- 날짜인 경우 DATE 또는 문자 타입으로 장단점을 파악해 결정한다.
- 숫자인 경우 최대 길이 및 소숫점을 조사해 결정한다.

논리 무결성 전환

논리 단계에서 결정한 엔티티 무결성, 참조 무결성, 영역(domain) 무결성에 대해 DBMS의 특성을 고려해 설정한다.

◆ 엔티티 무결성 전환

- 엔티티의 UID에 속하는 모든 속성이 PK로 구성한다.
- PK로 구성된 컬럼은 NOT NULL과 UNIQUE하게 설정한다.

◆ 참조 무결성 전환

- UID BAR를 받은 경우 테이블에 외부 키 컬럼을 포함하도록 한다.
- FK 명칭은 표준 명명 규칙을 준수한다.
- 참조 무결성을 정의한다.

◆ 속성 무결성 전환

- 속성이 갖는 각종 업무 규칙(허용 값, 기본 값 등)을 반영한다.
- 연쇄 작용(triggering operation) 결정 : 논리적으로 정의한 연쇄작용에 대해 DBMS로 해결할 것인가? 프로그램으로 해결할 것인가를 결정해 반영한다.

액세스 패턴 설계

데이터베이스 내 자료에 접근하는 방법은 첫째 인덱스를 통한 접근 방법이고, 둘째는 모든 데이터를 읽는 방법(full table scan)으로, 크게 이 두 가지 방법 밖에는 없다. 온라인 환경(OLTP : Online Transaction Processing)에서 모든 데이터를 읽는다면 이는 DBMS의 성능에 엄청난 부하를 줄 것이다.

관계형 데이터베이스에서 속도에 영향을 미치는 가장 중요한 요소는 디스크(disk) IO와 DBMS Call이다. 성능에 문제가 있는 시스템을 진단해보면 대부분이 인덱스 전략의 부재와 잘못 구사한 SQL 문장으로 인해 엄청난 양의 데이터를 메모리로 불러들이고 있고, 또 하나의 SQL 문장에서는 비효율이 없다 하더라도, 이러한 SQL을 레코드 건수만큼 읽어 이것이 시스템과 네트워크 등 모든 부분의 성능에 영향을 미치고 있는 것이다.

<그림 5>의 예를 가지고 인덱스 전략 최적화란 어떤 것을 말하는지를 살펴보겠다. 튜닝을 하기 전에 액세스 패스(access path)와 기존 인덱스 전략이 Idx1~Idx3으로 되어 있다.

?번 SQL은 Idx1을 사용하면 된다. ?번 SQL은 Idx2를 사용하면 된다. ?번 SQL은 Idx3를 사용하면 된다. ?번 SQL은 접수일자(rcpt_dt)가 오늘 날짜보다 늦거나 같고, 판매일자가 null인 데이터를 찾는 것인데, 이를 업무적으로 살펴보면 접수된 것 중에 아직 판매되지 않은 데이터를 찾는 SQL이다. Sale_dt is null로 물어봤기 때문에 이는 인덱스를 타지 못하고, rcpt_dt <= sysdate에 의해서 Idx1을 탈 것이다.

여기서의 문제는 접수일자가 오늘보다 늦거나 같다면 거의 모든 데이터를 읽는다는 점이다. 이 테이블의 전체 데이터가 몇 천만 건이라면 몇 천만 건을 다 읽은 다음, 이것도 인덱스를 타고서 테이블의 데이터를 랜덤으로 액세스한 다음 sale_dt is null인 데이터를 보내줄 것이다. 실질적으로 여기서 원하는 데이터는 몇 건 안 될 것이다. 그런데 이 몇 건 안 되는 것을 모든 테이블의 데이터를 읽어 메모리로 읽어온 다음 판매일자가 null인 데이터를 찾으니 성능상에 문제를 일으키는 것이다.

?번 SQL은 접수일자가 입력받은 날짜와 같고, 취소일자는 null인 데이터를 찾는 것이다. 이것은 Idx3을 사용하면 문제가 없다. ?번 SQL은 접수일자가 입력받은 날짜 사이이고, 어느 월에 취소한 데이터인가를 찾는 것이다. 여기에서 두 가지 조건 모두 범위를 찾는 것이기 때문에 DBMS의 옵티마이저가 어느 인덱스를 이용해 데이터를 찾는지에 따라 성능에 영향을 미칠 것이다. 인덱스 Idx1으로 접근한다면 입력일자의 모든 데이터를 인덱스 액세스한 다음 랜덤으로 테이블을 읽고 그 중에 취소일자가 입력된 데이터를 찾을 것이다. 인덱스 Idx3로 접근한다면 취소가 된 데이터를 먼저 인덱스를 이용해 찾은 뒤, 접수일자가 입력된 범위 내에 있는 데이터를 찾아줄 것이다. 업무적으로 접수된 후 취소되는 자료는 별로 없을 것이다. 이러한 자료가 많다면 영업이 잘 이루어지지 않는다는 것이다. 입력 값의 범위가 넓은데 운이 좋아서 Idx3을 타면 빠르고 운이 없어서 Idx1을 타면 성능이 느릴 것이다.

앞의 모든 조건을 만족하기 위해서 인덱스를 재조정하고 SQL을 튜닝해보면 인덱스를 3개에서 2개의 결합 인덱스만 만들고, 접수되고 판매되지 않은 데이터나 접수되고 취소되지 않은 데이터를 위해 판매일자와 취소일자에 기본 값으로 ‘99991231’을 셋팅한다.

?, ?번 SQL은 적절한 인덱스를 경유해 문제가 없다. ?번 SQL은 취소 날짜가 있다면, 판매일자는 ‘99991231’일로 그대로 있을 것이며, null이 아니므로 Idx2를 타며, ‘99991231’ 일자를 가지고 있는 데이터는 별로 없어 효율이 상당히 좋을 것이므로 조건에 “and sale_dt = ‘99991231’”을 첨가하는 것이 좋다.

?번 SQL은 Idx1을 타면 대부분의 데이터를 읽으므로 이를 못 타게 하고, 기본 값으로 sale_dt에 ‘99991231’을 주었으므로, 즉 접수만 되고 판매된 데이터는 별로 되지 않으므로 변별력이 좋은 Idx2를 타게 해 성능이 상당히 좋아질 것이다. ?번 SQL은 취소일자에 기본 값을 주었으므로 SQL에서 기본 값만 바꾸어 주면 문제가 없다.

?번 SQL도 업무적으로 접수받고 취소된 데이터보다 판매가 안 된 데이터의 변별력이 좋으므로, 접수일자로 시작하는 인덱스 Idx1을 못 타게 하고, 인덱스 Idx2를 타게 하면 언제나 성능이 좋아질 것이다.

이처럼 인덱스 전략이란 최소의 결합 인덱스를 사용해 데이터의 변별력을 증가시키면서 모든 SQL을 만족시킬 수 있도록 전략적으로 접근하는 것을 말한다. 

앞에서도 말한 바와 같이 관계형 데이터베이스를 사용하면서 가장 중요한 것은 디스크 I/O를 어떻게 줄이며, DBMS Call을 어떻게 최소화하느냐가 관건이다. 소량의 데이터를 읽어야 하는 환경에서 인덱스를 전략적으로 만들지 않아 인덱스를 경유하지 않는 SQL(메모리로 대량의 데이터를 읽어 들이는 SQL)이 하나라도 있다거나, 아니면 대량의 데이터를 읽는 배치(Batch) 프로그램에서 인덱스를 경유해 데이터를 읽어 낸다면, 이미 성능은 보장할 수 없는 것이다. 그러므로 인덱스 전략과 성능을 보장받을 수 있는 SQL의 구현 능력은 RDBMS를 사용하면서 아무리 강조를 하더라도 지나침이 없다.

필자가 RDBMS에 성능상의 문제가 있어 진단 내지 튜닝 컨설팅을 나가보면, 대부분의 경우가 CPU나 메모리, 네트워크에 문제가 있어 성능에 문제가 있는 것이 아니라 인덱스 전략의 부재와 SQL 문장의 비효율적인 문제, 그리고 집합(Set) 처리가 아닌 절차 처리에 의한 DBMS Call에 의해 나타나는 문제가 시스템의 성능에 영향을 미치고 있는 것이 99%라고 할 수 있다. 이러한 개념은 RDBMS를 사용하는 사람들이 기본적으로 익혀야만 하는 기술이고, 시스템 오픈 전이나 오픈 후 반드시 체크할 사항들이다.

그런데 시스템 오픈 전에 인덱스 전략을 가져가는 것은 현실적으로 상당히 어려운 부분이 존재한다. 데이터를 접근하는 형태가 다 밝혀져야 하는데, 다시 말해 데이터를 접근하는 SQL의 유형이 다 나온다는 것이다. 즉, 개발을 진행하며 전략적으로 인덱스를 가져가기는 어려운 부분이 있다. 그러므로 현실적으로 기본적인 인덱스를 생성하고 시스템 오픈 전에 데이터 이관을 수행한 후 SQL*TRACE 유틸리티를 이용해 SQL의 문제점을 진단해 비효율적인 SQL을 파악해 한번에 인덱스를 전략적으로 재조정하는 방법을 이용하는 것이 가장 효율적이라 할 수 있다.

데이터베이스 오픈

앞에서 저장 공간 사용량 계획은 각각의 RDBMS에 종속적인 요소가 많아 생략했으니 이해해 주기 바란다. 데이터베이스 오픈 전에 우리가 고려해야 할 사항이 아직 남아 있는데, 기존 데이터의 이행(migration)에 관한 것이다. 기존 데이터의 이행은 첫째 실제로 과거 데이터를 입력하는 방식과 둘째, 이행 프로그램으로 이행하는 방법이 있을 수 있다. 물론 실제 데이터의 입력도 이행 방법 중 하나의 방법이지만 여기서는 이행 프로그램을 이용해 과거 시스템의 데이터 이행에 대해서 간략히 살펴보고자 한다.

데이터베이스 이행

데이터 이행은 새로운 시스템을 구축함에 있어 기존 시스템에 저장된 데이터를 새로운 개념으로 구성된 모델에 담을 수 있도록 맵핑, 변경, 가공 처리를 해 신규 모델에서도 기존 시스템이 지니고 있던 정보를 손실 없이 보존하고 새로운 모델에서 생성되는 데이터와 정보의 연속성을 유지하기 위한 작업이다.

데이터베이스 이행 작업 수행범위

통상 데이터 이행 작업은 기존 시스템의 자료를 새로운 시스템으로 이행하는 과정에서 발생하는 이행 환경 구축, 자료 이행, 이행 자료 검증 및 최종적으로 시스템 오픈에 관련된 모든 작업 내용을 포함하고 있다. 이행을 수행하는 방법을 전략적으로 보면 대개 다음의 3가지 정도로 요약할 수 있다.

첫 번째 일시 이행은 한 번에 모든 자료를 이행하는 것을 말하며, 이의 장점은 작업이 단순하며, 단기간에 이행을 할 수 있다는 것이다. 이것의 단점은 일정기간 동안 업무중단이 필요하고, 장애발생시 기존 시스템으로 복귀가 불가능한 경우가 발생한다.

일시 이행+점진 이행은 일단 기존 자료의 전부를 일시에 이행한 후, 전환 작업기간 중에 발생한 변동 자료에 대해 추가적으로 갱신 및 이행해 기존 시스템과 새로운 시스템을 점진적으로 일치시키는 방법으로, 이의 장점은 장시간 이행 작업시간이 소요되는 데이터베이스에 적합하고, 기존 시스템의 변경이나 업무의 제한이 최소화할 수 있다. 단점은 작업 내용이 복잡하다는 것이다.

부분 이행+점진 이행 방식은 전체 시스템을 서브 시스템별로 세분화해 가동 자체를 서브 시스템별로 단계적으로 진행하며 자료 이행도 서브 시스템별로 별도 진행한다. 이것의 장점은 시스템의 결합도가 낮은 시스템에 적합하다. 이에 대한 단점은 서브 시스템이 여러 번 가동되므로 사용자의 혼란을 야기할 수 있으며, 시스템 통합시점에 예상치 못한 문제가 발생할 가능성이 있다.

    

이행에 따른 문제점과 대책

기존 데이터의 변환시 가장 우선으로 고려해야 할 사항은 데이터 정제(cleansing) 작업이다. 오류가 없는 데이터만이 정확하게 이행될 수 있기 때문이다. 다음으로 고려해야 할 것은 새로운 업무 규칙에 의해 데이터를 새로 생성해야 할 경우를 정의하는 것이다.

◆ 각종 코드성 데이터가 중복되어져 관리되어 왔는지 검사한다.

◆ 날짜 등의 자료가 규정된 도메인 안에 들어 있는지를 검사한다.

◆ 검사한 값에 오류가 있을 경우에 오류가 수정할 수 있는 것인지를 확인한다.

◆ 검사한 값의 오류가 현업의 결정 없이는 수정할 수 없는 경우에는 현업이 결정을 의뢰한다.

◆ 이러한 오류들이 현재 동작하고 있는 프로그램에 의해서 발생하는 것인지를 검사하고 프로그램을 수정한다.

◆ 이행 작업에 가장 기준이 되는 것으로 현업에서 정의를 하여야 한다.

이행에 대한 내용을 간략히 살펴봤지만 실제의 프로젝트에서는 이행이라는 것이 또 하나의 프로젝트로 할 수 있을 만큼 복잡하고도 큰 규모로 일어날 수도 있다.

분석·설계가 끝나고 데이터베이스의 과거 데이터를 이행하고 나면 이제 데이터베이스를 오픈할 수 있는 준비가 됐다고 할 수 있다. 다시 한번 얘기하지만 RDBMS의 성능에 영향을 미치는 요소는 인덱스 전략의 부재와 잘못된 SQL 문장의 구현, 그리고 절차적인 로직의 DBMS Call이라고 말했다. 물론 메모리 문제, 저장공간 사용계획의 문제 등 성능에 영향을 미치는 요소가 있지만, 잘못된 SQL 문장의 구현이나 절차적인 로직의 DBMS Call에 비해서는 성능에 미치는 요소가 미미하다고 할 수 있다. 이러한 성능 개선을 위한 부분은 본지 2003년 12월호 특집 기사 중 “데이터베이스 성능을 좌우하는 것은 I/O이다”라는 글을 참고하기 바란다.

데이터베이스 운영

데이터베이스의 원활한 운영을 위해 데이터베이스 관리자는 정기적으로 데이터베이스를 점검하는 작업을 수행해야 한다. 데이터베이스에는 데이터베이스 엔진 자체에 대한 조회와 설계되어 구축된 오브젝트들에 대해 정기적으로 체크하는 작업이 필요하다. 여기서는 인덱스의 조정과 SQL 문장의 튜닝으로 어느 정도 안정화된 이후에 데이터베이스에 대해 정기적으로 점검해야 할 사항에 대해서만 간략히 정리해 보고자 한다.

◆ 매일 점검해야 할 항목

- 모든 데이터베이스가 가동되었는지 확인한다.

- 모든 데이터베이스가 이용 가능한지를 확인한다. 데이터베이스가 정상적으로 기동되고 있는지 로그 파일이나 테스트 스크립트를 만들어 확인해 본다.

- Alert Log를 확인한다.

- 파일의 최신 상태의 로그를 확인한다.

- 데이터베이스가 성공적으로 백업되었는지 확인한다.

- 테이프나 디스크로 백업을 수행한 각각의 방법에 따라 백업이 성공적으로 수행되었는지 체크하도록 한다.

- 데이터베이스 성능을 위해 충분한 리소스가 존재하는지 확인한다.

- 테이블 스페이스에 충분한 공간이 존재하는지 확인한다.

◆ 주 단위로 점검해야 할 항목

- 잘못된 규칙에 의해 오브젝트가 존재하는지 확인한다.

- 데이터베이스 설계에서 명시한 명명규칙과 스토리지 파라미터 등이 정해진 규칙에 따라 정확하게 생성되었는지를 확인한다.

- 보안관리가 잘 유지되고 있는지 확인한다.

- 모든 Alert Log 파일을 보관한다.

◆ 월 단위로 점검해야 할 항목

- 데이터베이스의 비정상적인 현상이 발생하는지 확인한다.

- 튜닝해야 할 부분이 있는지 확인한다.

- I/O Contention이 존재하는지 확인한다.

데이터베이스의 안정화

데이터베이스의 안정화란 데이터베이스를 구축하고 가동을 위한 준비부터 대부분의 운영 작업이 주기적인 작업으로 전환되어 위험 요소가 최소화되었을 때까지의 과정이다. 이 과정을 단축하기 위해서 관련자가 고려해야 할 점을 알아보자. 이해를 돕기 위해서 프로젝트나 사이트에서 나타난 현상, 원인 및 해결 과정을 예로 들겠다. 이 과정에서 혼돈의 시간을 최소화하고 개발자나 DBA에게 주어지는 고통을 줄이고자 한다.

양질전화

안정화 과정에 나타나는 임팩트

시스템 혹은 데이터베이스 생명 주기에서 표면적으로 나타나지 않지만 ‘절망의 계곡’ 같은 어려운 시기가 있다. 정도의 차이에 따라 관련자 모두가 홍역을 하기도 하고 아주 드물지만 몇 사람이 일상적인 오류 해결 과정 같이 쉽게 지나기도 한다. 후자는 능력보다 운이 좋은 사람들이다.

나타나는 현상은 불신과 혼돈 그 자체이다. 시스템이 다운되거나 서비스가 불가능할 정도의 성능 저하 현상이 발생한다. 실행되는 프로그램은 잘못된 연산으로 업무가 불가능하다. 또한 해결을 위해 모든 부분에 보고서를 요구한다. 해결은 둘째고 현상 파악도 어렵다. 보고서를 써야 하는 위치에 있는 사람들은 문제 해결에는 관심이 없고 문책을 피하기 위한 보고서 자체에만 집중을 한다. 문제 프로그램을 작성한 개발자는 문제 해결에 집중할 시간이나 정열도 사라진다. 프로그램이 문제인지 시스템이 문제인지 해결이 불가능한 것인지 판단을 해줄 사람도 없고 책임질 사람도 없다. 이런 과정을 통해서 안정화는 이루어진다.

“빠져 나오지 못하면 아무것도 아니다”

프로젝트를 진행하면서 느꼈던 어려움을 어떻게 표현할 수 있을까 고민하던 중 알게 된 말이 양질전화(良質轉化)이다. “물을 가열하면 섭씨 100도까지는 뜨거워도 여전히 액체다. 하지만 비등점을 넘는 순간 기체로 성질이 변한다”라는 뜻이다. 반드시 거쳐 가야만 하고 결과에 도달하지 못하면 성과가 없다는 의미이다. 새로운 시스템으로 가기 위해서는 반드시 안정화 과정을 거친다. 프로젝트 관련자들이 많은 밤을 새우고도 안정화에 실패하면 과정의 노력은 좋은 평가를 받을 수 없다. 실패의 미학이나 실패 속에서 새로운 가치를 찾는다 등의 이야기는 직접 관련자에게 아무런 위로가 되지 못한다. 안정화는 혼돈을 최소화할 수는 있지만 피할 수 없는 시기이므로 돌파해야 한다.

예측 가능한 vs. 불가능한 요소, 통제 가능한 vs. 불가능한 현상

“어떻게 극복할 수 있습니까?” 또는 “어떻게 문제를 해결했나요?” 성능 개선, 시스템 고도화, 시스템 안정화 등의 이름으로 프로젝트를 진행한 필자는 고객으로부터 이런 질문을 받았다. 문제를 해결하면서 안정화되어 신뢰가 쌓이면 안정화 방법을 알기 위한 질문이다. “죽도록 한다”라고 답변을 한다. 복잡한 상황을 설명할 수 없는 이유 때문이기도 하지만 안정화를 위해서는 최선을 다해야 한다는 메시지를 전하기 위한 답변이다. 하지만 ‘열심히 한다’만 가지고는 되지 않는다. 갈수록 시스템은 복잡해지고 시스템이 수행할 비즈니스도 복잡해졌다. 한 사람이 혹은 하나의 조직이 모두 이해한다는 것이 불가능하다.

필자가 접근하는 방법은 예측 불가능한 요소를 예측 가능하게 하고 통제 불가능한 요소를 통제 가능하게 하는 것을 출발점으로 삼는다. 예측과 통제가 가능하려면 필요한 지식과 필요한 지식을 알고 있는 사람들과 일하는 방법을 알아야 한다.

80/20 원리로 생각하는 안정화 대상

부분적인 문제가 전체 시스템의 생존을 위협한다

80/20 원리(파레토 법칙)는 이탈리아의 경제학자 파레토가 주장한 것으로 ‘전체 결과의 80%는 전체 원인 중 20%에서 비롯됐다’는 법칙을 뜻한다. 고객 관리, 마케팅, 경영 전략 등에 자주 등장한다. IBM에서도 80%의 컴퓨터 사용시간 중 20%의 프로그램 코드가 가장 많이 사용되는 것을 발견했다. 여기에서 80, 20이라는 숫자의 정확도는 중요하지 않다.

무엇이 문제인지 모를 경우 이것저것 가리지 않고 해보기도 하고 처음부터 똑같은 무게로 하나씩 검증하려는 경우가 있다. 하지만 시스템이 서비스가 중단되더라도 모든 프로그램이 문제가 되는 경우는 없다. 데이터베이스 입장에서 보면 모든 SQL이나 오브젝트가 문제가 있지는 않다. 그러면 영향도가 가장 높은 요소별로 순위를 정하고 해당 프로그램을 개선하므로 안정화를 도모할 수 있다. 문제 요소를 해소하면 새로운 악성 요소가 나타나기 마련이다.

사례를 통해서 현상을 확인해 보자. 특정 리포트 해석이 목적이 아니기에 상세한 설명은 하지 않겠다. 오라클 데이터베이스를 사용한 보험사 시스템으로 오픈을 앞두고 시험 중 STATSPACK 리포트 일부를 정리한 결과이다. 시스템에서 사용된 SQL은 2만개가 넘는다.

<표 1>은 데이터베이스의 Buffer Gets으로 정렬했다. Buffer Gets은 SQL문 연산에 필요한 데이터 블럭 수를 의미한다. %Totall은 전체 Buffer Gets에 대한 SQL이 사용한 Buffer Gets 비율이다. 5개의 SQL이 40%를 차지하고 있다.

<표 2>는 Physical Reads로 정렬했다. 데이터베이스는 연산에 필요한 데이터가 메모리에 존재해야 한다. 메모리에 없다면 하드디스크를 읽어야 한다. DISK I/O 속도는 디스크 헤드가 물리적으로 이동을 해야 하므로 전자적인 처리로 이루어지는 메모리 액세스 속도보다 현저하게 느릴 수밖에 없다. 대부분의 액세스 병목은 디스크 I/O에서 일어난다. 5개의 SQL이 24%를 물리적 I/O를 유발했다.

설명에서와 같이 데이터베이스 성능에 결정적인 역할을 하는 2가지 영역에서 각각의 Top 5 SQL문이 미치는 영향은 절대적이다. 이 절대적인 요소부터 해결해야 한다.

제약 이론

제약 이론이란 시스템 내부에서 전체 성과를 결정하는 데 있어서 가장 결정적인 제약 조건(constraints)이 무엇인지를 찾아서 시스템의 나머지 부분을 그 제약에 맞추는 거나 제약을 제거하는 것을 통해 전체적인 성과 향상을 달성한다는 것을 의미한다. 안정화로 가는 방법도 동일하다고 필자는 생각한다. 유사한 의미로 다른 시각에서 표현되는 예를 들어 보겠다.

“어두운 골목에서 열쇠를 잃어버리고는, 사람들은 종종 밝은 다른 골목에서 잃어버린 열쇠를 찾고자 한다.” (파킨슨의 법칙 중에서)

올바른 데이터베이스 성능 개선

데이터베이스 성능에 결정 요소는 SQL이다. 하지만 데이터베이스 서버 튜닝에서 출발해 하드웨어 증설로 결론나는 경우를 많이 보았다. 잘못된 접근이다. 비효율적인 SQL이 실행되는 환경에서 DBMS 파라미터 조정만으로는 만족한 결과를 얻지 못한다. 개별적인 SQL이 일정 수준으로 튜닝되었을 때 서버 성능의 왜곡 현상이 없어진다. 그때 서버를 튜닝을 해야 효과가 있다.

예를 들면 SQL이 많은 소트를 유발해 swapping이 발생된다고 메모리가 모자란다는 결론이 나서는 안 된다. 불필요한 소트를 없애는 것이 바른 접근일 것이다.

안정화의 가장 영향력이 큰 데이터 이행과 클린징

시스템 가동 초기에 데이터베이스 품질을 결정하는 요소는 데이터 이행과 데이터 클린징이다. 데이터 이행은 신규 시스템을 오픈하기 위한 1회성이라는 특성 때문에 중요성을 인식하지 못하고 클린징은 불필요한 추가 작업으로만 생각을 한다.

많은 프로젝트에서 이행 작업과 클린징의 난해함을 걱정해 과거와 유사한 신규 데이터 모델을 작성하고 클린징하지 않은 데이터를 옮겨 놓는다. 예전 시스템에서는 잘못된 데이터를 보정하기 위해 예외 처리를 프로그램으로 중무장해 두었다. 중무장된 프로그램 로직은 해석이 불가능해 아무도 수정하지 않으려고 했던 부분이다. 이런 악성 영역을 재구축하면서 혁신하지 않는다면 또 다시 안정화라는 명분으로 예외 사항을 만들고 프로그램 로직으로 중무장해야 된다. 어떻게 보면 안정화가 과거로의 회귀하는 과정 같이 보인다. 단기간에 시스템을 안정화하고자 한다면 데이터 이행과 클린징에 더 많은 노력으로 완성도를 높여야 한다.

추가 요구 사항의 접근

안정화 단계에서 추가 요구 사항이라는 것이 발생한다. 개선을 위한 작업이든 보완을 위한 작업이든 프로그램적으로 해결하려고 한다. 이때 ERD(Entity Relationship Diagram)를 보면서 고민하는 사람을 보지를 못했다. 프로그램으로 해결하려다 보니 임시방편 테이블이 생기고 컬럼이 늘어난다. 중복 데이터가 늘어나고 전용하는 컬럼이 증가한다. 안정화되면서 데이터베이스는 누더기가 되어간다. 이 과정에서 반드시 데이터를 모델 관점에서 검토하고 데이터베이스에 반영해야 한다. 데이터 모델을 이해하면 쉽게 해결될 문제를 모델러 의도(설계자의 의도)를 무시하고 프로그램으로만 해결하려 한다면 안정화 과정이 장래에 다른 문제를 만들어 가는 과정이 될 수 있다.

소 잃기 전에 외양간 고치기

안정화 과정은 사전에 만반의 준비가 되었더라도 예측하지 못한 요소에 의해서 불행이 발생한다. 하지만 다른 시각으로는 소 잃고 외양간 고치는 작업이다. 따라서 소 잃기 전에 외양간을 고쳐 놓아야 한다.

우리가 무엇(WHAT-데이터)을 할 것인지를 정확하게 모르기 때문에 어떻게(HOW-프로그램)라는 시행착오를 한다. 무엇(WHAT-데이터)을 할 것인지를 정확히 하는 것과 어떻게(HOW-프로그램)를 바르게 바꾸는 과정이 안정화이다. 무엇을 할 것인가는 정의하는 과정이 데이터 모델링이다. 데이터 모델은 비즈니스에서 사용될 모든 데이터를 정의하고 정의한 데이터는 무결성을 보장해야 한다. 데이터 모델은 그 결과로 끝나는 것이 아니라 설계, 구현, 시험, 운영에 사용될 기준인 것이다. 데이터 모델링을 바르게 하고 데이터 모델의 얼라이먼트(alignment, 일관성)를 계속 지켜가는 것이 안정화 과정을 단축하고 위험을 최소화하는 방법이다.

다음 호에서는 데이터베이스를 안정적으로 운영·유지하기 위해서 가장 중요한 ‘적절한 통제 관리 절차’에 대해 알아볼 것이다. 이러한 통제 관리 절차의 1차 목적은 데이터베이스 운영의 안정성 확보와 보안의 유지라 할 수 있다. 이제부터 이러한 통제 관리 업무와 함께 데이터베이스 폐기에 이르기까지 일반적으로 수행되는 여러 가지 업무 절차 등을 살펴보도록 하자.

정리 | 조규형 | jokyu@korea.cnet.com


출처 : 마이크로소프트웨어 1월호