IT/모바일
저자: 이춘식 / LGCNS
IT의 개발방법론은 건축의 방법론으로부터 응용하여 만들었다. 다시 말하면, 건축과 IT 구축은 비슷하다고 할 수 있다. 건축방법론에서 가장 중요한 기초공사를 하는 부분을 바로 모델링이라고 비유할 수 있다. 아무리 좋은 프로그램도 기반이 부실하면 좋은 프로그램을 만들 수 없다. 이것은 마치 조선시대의 마차가 지나가는 길을 설계하고 21세기의 대형 버스와 수많은 자동차가 지나가며 고층빌딩들이 늘어서는 형태의 건물을 지으려고 하는 것과 마찬가지가 된다. 많이 개선은 되었지만 여전히 프로젝트에서 개발하는 많은 사람들은 촉박한 일정과 개발에 대한 부담감으로 인해 시스템의 근본인 모델링에 대해 간과하는 경우가 많이 있다. 프로젝트를 수행할 때 모델러와 DBA의 역할이 무엇인지 프로젝트를 수행하는 당사자도 정리가 안 되는 경우가 많이 있다.
다음은 필자가 모델링과 DBA 역할을 동시에 수행하면서 역할에 대해 정리한 것이다. 모델러와 DBA는 같이 수행할 수도 있지만 별개로 구분되어 수행될 수도 있다.
일반적으로 모델링을 한다는 것은 프로세스 모델링과 데이터 모델링 영역으로 크게 분류할 수 있다. 정보공학을 기반으로 할 때는 두 가지 모델링이 각각 진행되면서 보완하는 방법을 사용하고 객체지향 기반으로 모델링을 할 때는 같이 진행하게 된다. 모델링은 개발에 참여한 모든 사람이 수행하는 역할이다. 거기에 모델만을 담당하는 사람(즉, 모델러)은 전체적으로 모델링을 할 수 있도록 교육하고 가이드하며 통합 모델링 작업을 수행하는 등의 역할을 수행한다.
모델러는 통합 모델링을 수행하고 모델에 대한 검증 작업을 하며 전체 업무에 대한 커뮤니케이션 리더 역할을 수행하게 된다.
■ 모델러는 통합 모델링을 수행한다
모델링을 한다는 것은 결국 어떤 업무에 대해서 이해한 상태에서 그 내용을 정보 시스템으로 구축하기 위해 모형으로 만드는 것을 의미한다. 세부 업무간의 정보의 흐름을 파악하여 모델에 표현하는 일은 각 개발자가 수행한다. 모델러는 전체 업무의 구조와 흐름을 분석하여 적절한 표기법으로 표현해 내는 역할을 수행한다. 또한 세부 업무를 담당하는 사람이 효과적인 모델링을 진행할 수 있도록 교육하고 가이드하는 역할을 수행하게 된다.
■ 모델에 대한 검증 작업을 수행한다
업무 각각의 모델링은 업무를 분석하는 모든 사람들이 수행을 한다면 모델검증은 좀더 숙련되고 이해력이 높은 사람이 할 수 있어야 한다. 즉, 모델러는 세부 업무에서 수행한 모델에 대해 기술적으로나 업무적으로 오류사항이 있는지 확인하고 잘못을 지적하며 새로운 대안점을 제시하는 역할을 수행한다.
■ 커뮤니케이션 리더 역할을 한다
모델링은 혼자 하는 게 아니라 각 기업에 있는 여러 사람이 하는 것이므로 커뮤니케이션이 많이 발생한다. 특히 전체 업무에 대한 통합모델링 작업을 진행할 때는 세부 업무를 담당하는 모델러들은 모델링 회의를 소집하여 통합 모델링을 작업을 진행하게 된다. 이때 모델러는 모델링을 위해 질문하고 조정하고 중재하며 해결점을 제시하는 역할을 하게 된다.
DBA는 모델러와 함께 논리 모델을 물리 모델로 전환하고 데이터베이스 오브젝트를 설계, 구축, 관리 그리고 튜닝한다.
역시 모델링을 했던 사람이 DBA를 겸임하면 더 효과적인 데이터베이스 관리가 될 수 있다. DBA는 곧바로 업무를 모르는 상태에서 바로 데이터베이스만 구축하고 관리하는 업무를 할 수도 있지만 이와 같은 업무는 제한적이고 좋지 않은 업무영역이 된다. 데이터베이스를 담당하는 사람도 모델부터 이어져 데이터베이스를 관리할 수 있도록 해야 한다.
■ 논리 모델을 물리 모델로 전환한다
업무적인 관점에서 모델로 표기한 논리 모델을 데이터베이스관점(특정 DBMS, 용량 고려)에서 물리적인 모델로 전환하는 역할을 수행한다. 이때 모델러가 있으면 같이 수행하고 자신이 두 가지를 수행한다면 논리 모델에 대한 버전을 1.0으로 만들어 두고 물리모델을 생성하도록 해야 한다. 물리 모델을 만들 때 중요하게 고려해야 하는 점이 바로 데이터 무결성과 데이터베이스 성능을 고려한 모델로 반정규와 분산 모델이 같은 설계가 있을 수 있다.
■ 데이터베이스 오브젝트를 설계한다
먼저 데이터베이스에 발생하는 트랜잭션의 수를 파악하고, 전환되는 데이터의 양과 데이터의 보관주기를 고려하여 용량산정을 하도록 한다. 그리고 트랜잭션과 데이터량에 따라 테이블 스페이스, 데이터 파일, 테이블, 인덱스, 뷰 등을 설계하도록 한다.
■ 데이터베이스를 구축하고 관리한다
설계가 완료된 내용을 가지고 이용하여 DDL(Data Definition Language)스크립트를 이용하여 DBMS에 데이터베이스 인스턴스를 생성하고 거기에 설계된 오브젝트들을 생성한다. 또한 한 번 생성된 오브젝트들에 대해 개발하면서 변경되는 사항을 데이터 모델과 데이터베이스에 정확하게 일치시켜가면서 변경하는 역할을 수행한다.
또한 데이터에 대한 백업 및 복구 역할을 수행하고 장애가 발생하지 않도록 세션 모니터링이나 로그 모니터링을 지속적으로 수행하는 역할을 한다.
■ 데이터베이스를 튜닝한다
구축된 데이터베이스는 데이터량이 증가할 수 있도록 SQL 문장이 비효율적으로 작성될수록 데이터베이스 서버 파라미터가 잘못 지정되어 있거나, 파일시스템 설계를 잘못하는 경우 성능이 저하될 수 있다. 이때 DBA는 데이터베이스를 애플리케이션 관점에서 튜닝(SQL)하거나 데이터베이스 서버(파라미터, 파일시스템 등) 관점에서 튜닝하는 역할을 수행한다.
IT 개발자의 역할과 비전 세미나(2): 데이터 아키텍트 / SI / 기업 전산실
모델러와 DBA가 분리되었을 때 주의해야 할 점이 있다
모델링을 하지 않고 구축된 데이터베이스만 다루는 사람은 자신이 지도 위의 어느 지점에 위치해 있는지 모르는 길 잃은 자와 같고 데이터베이스의 원리를 모르고 모델링만 하는 사람은 목적지가 없이 지도만 가지고 길을 가는 사람과 같다.
모델링을 전개할 때는 먼저는 업무로부터 논리적인 모델을 만들어 내야 하고 두 번째는 논리적인 모델로부터 데이터베이스를 생성하기 위한 물리적인 모델을 만들어 내야 한다. 그래야 데이터의 무결성도 지키면서 성능을 향상시킬 수 있는 모델링을 전개하게 된다.
반대로 데이터베이스 담당자는 모델이 어떤 비즈니스로 생성되었는지 비즈니스 모델이 어떻게 데이터베이스 모델이 되었는지를 알고 있으면서 데이터베이스를 운영 및 관리해야 한다. 그래야 정확한 데이터 스키마 관리, 성능 관리 그리고 데이터의 무결성 관리가 가능해진다.
모델러는 데이터베이스를 모르고 모델링을 하고 DBA는 업무를 모르고 데이터베이스만 관리하는 경우 좋지 않다. 이는 가장 중요한 프로세스가 끊겨버리는 현상으로 잘못된 물리 모델이 생성되거나 구축 이후 데이터베이스가 변경이 될 때 이상한 모습으로 변경이 될 수 있는 위험이 많은 구조다. 모델러도 물리적인 데이터베이스의 모습을 이해한 상태에서 모델링을 진행해야 하고 DBA도 업무의 구조와 흐름을 이해한 상태에서 물리 모델로 전환하는 작업을 직접 수행하거나 이해해야 프로젝트가 효과적으로 진행된다.
많은 프로젝트에서 보면 모델링을 하는 사람은 데이터베이스에 대해 잘 모르는 경우가 많아 정확한 데이터 모델링을 수행하지 못하는 경우가 많이 있다. 그래서 데이터베이스에서는 이렇게 처리할 수밖에 없다고 다른 사람이 이야기하면 모델이 이상한 모습으로 변형이 된다고 할지라도 자기 안에 확실한 지식이 없기 때문에 이상한 방향으로 변형되는 것을 허용하게 된다. 반대로 DBA가 모델에 대한 지식이 없으면 데이터베이스 테이블이나 PK 등에 대한 변경 요청에 대해 데이터베이스만 고려하여 무조건 반영을 하게 되어 업무적인 특징이나 모델 내부의 흐름을 단절시키는 경우가 많이 발생한다.
정리하면 모델러는 커맨드 처리에 미숙하고 DBA는 업무를 이해하여 모델을 분석하는 데 미흡하면 아주 취약한 모델링과 데이터베이스가 되는 것이다. 이러한 사실을 바탕으로 시스템 구축 프로젝트를 진행할 때 모든 모델러에게는 데이터베이스에 대한 지식을 갖출 것을 교육하고 데이터베이스 관리자에게는 업무의 흐름에 따라 데이터 모델에 대해 이해하는 방법에 대해 강조하여 교육하곤 한다. 그리고 두 역할은 분리된 역할로 존재하는 것이 아니라 상호간의 중복된 영역을 있음을 인정하고 상호간에 교류를 많이 해야 한다.
본 컨텐츠는 IT 각 분야의 전문 프로그래머 7인의 경험적 철학을 담은 도서 [나는 프로그래머다] 중 이춘식님의 글에서 발췌한 것입니다.
IT의 개발방법론은 건축의 방법론으로부터 응용하여 만들었다. 다시 말하면, 건축과 IT 구축은 비슷하다고 할 수 있다. 건축방법론에서 가장 중요한 기초공사를 하는 부분을 바로 모델링이라고 비유할 수 있다. 아무리 좋은 프로그램도 기반이 부실하면 좋은 프로그램을 만들 수 없다. 이것은 마치 조선시대의 마차가 지나가는 길을 설계하고 21세기의 대형 버스와 수많은 자동차가 지나가며 고층빌딩들이 늘어서는 형태의 건물을 지으려고 하는 것과 마찬가지가 된다. 많이 개선은 되었지만 여전히 프로젝트에서 개발하는 많은 사람들은 촉박한 일정과 개발에 대한 부담감으로 인해 시스템의 근본인 모델링에 대해 간과하는 경우가 많이 있다. 프로젝트를 수행할 때 모델러와 DBA의 역할이 무엇인지 프로젝트를 수행하는 당사자도 정리가 안 되는 경우가 많이 있다.
다음은 필자가 모델링과 DBA 역할을 동시에 수행하면서 역할에 대해 정리한 것이다. 모델러와 DBA는 같이 수행할 수도 있지만 별개로 구분되어 수행될 수도 있다.
일반적으로 모델링을 한다는 것은 프로세스 모델링과 데이터 모델링 영역으로 크게 분류할 수 있다. 정보공학을 기반으로 할 때는 두 가지 모델링이 각각 진행되면서 보완하는 방법을 사용하고 객체지향 기반으로 모델링을 할 때는 같이 진행하게 된다. 모델링은 개발에 참여한 모든 사람이 수행하는 역할이다. 거기에 모델만을 담당하는 사람(즉, 모델러)은 전체적으로 모델링을 할 수 있도록 교육하고 가이드하며 통합 모델링 작업을 수행하는 등의 역할을 수행한다.
모델러는 통합 모델링을 수행하고 모델에 대한 검증 작업을 하며 전체 업무에 대한 커뮤니케이션 리더 역할을 수행하게 된다.
■ 모델러는 통합 모델링을 수행한다
모델링을 한다는 것은 결국 어떤 업무에 대해서 이해한 상태에서 그 내용을 정보 시스템으로 구축하기 위해 모형으로 만드는 것을 의미한다. 세부 업무간의 정보의 흐름을 파악하여 모델에 표현하는 일은 각 개발자가 수행한다. 모델러는 전체 업무의 구조와 흐름을 분석하여 적절한 표기법으로 표현해 내는 역할을 수행한다. 또한 세부 업무를 담당하는 사람이 효과적인 모델링을 진행할 수 있도록 교육하고 가이드하는 역할을 수행하게 된다.
■ 모델에 대한 검증 작업을 수행한다
업무 각각의 모델링은 업무를 분석하는 모든 사람들이 수행을 한다면 모델검증은 좀더 숙련되고 이해력이 높은 사람이 할 수 있어야 한다. 즉, 모델러는 세부 업무에서 수행한 모델에 대해 기술적으로나 업무적으로 오류사항이 있는지 확인하고 잘못을 지적하며 새로운 대안점을 제시하는 역할을 수행한다.
■ 커뮤니케이션 리더 역할을 한다
모델링은 혼자 하는 게 아니라 각 기업에 있는 여러 사람이 하는 것이므로 커뮤니케이션이 많이 발생한다. 특히 전체 업무에 대한 통합모델링 작업을 진행할 때는 세부 업무를 담당하는 모델러들은 모델링 회의를 소집하여 통합 모델링을 작업을 진행하게 된다. 이때 모델러는 모델링을 위해 질문하고 조정하고 중재하며 해결점을 제시하는 역할을 하게 된다.
DBA는 모델러와 함께 논리 모델을 물리 모델로 전환하고 데이터베이스 오브젝트를 설계, 구축, 관리 그리고 튜닝한다.
역시 모델링을 했던 사람이 DBA를 겸임하면 더 효과적인 데이터베이스 관리가 될 수 있다. DBA는 곧바로 업무를 모르는 상태에서 바로 데이터베이스만 구축하고 관리하는 업무를 할 수도 있지만 이와 같은 업무는 제한적이고 좋지 않은 업무영역이 된다. 데이터베이스를 담당하는 사람도 모델부터 이어져 데이터베이스를 관리할 수 있도록 해야 한다.
■ 논리 모델을 물리 모델로 전환한다
업무적인 관점에서 모델로 표기한 논리 모델을 데이터베이스관점(특정 DBMS, 용량 고려)에서 물리적인 모델로 전환하는 역할을 수행한다. 이때 모델러가 있으면 같이 수행하고 자신이 두 가지를 수행한다면 논리 모델에 대한 버전을 1.0으로 만들어 두고 물리모델을 생성하도록 해야 한다. 물리 모델을 만들 때 중요하게 고려해야 하는 점이 바로 데이터 무결성과 데이터베이스 성능을 고려한 모델로 반정규와 분산 모델이 같은 설계가 있을 수 있다.
■ 데이터베이스 오브젝트를 설계한다
먼저 데이터베이스에 발생하는 트랜잭션의 수를 파악하고, 전환되는 데이터의 양과 데이터의 보관주기를 고려하여 용량산정을 하도록 한다. 그리고 트랜잭션과 데이터량에 따라 테이블 스페이스, 데이터 파일, 테이블, 인덱스, 뷰 등을 설계하도록 한다.
■ 데이터베이스를 구축하고 관리한다
설계가 완료된 내용을 가지고 이용하여 DDL(Data Definition Language)스크립트를 이용하여 DBMS에 데이터베이스 인스턴스를 생성하고 거기에 설계된 오브젝트들을 생성한다. 또한 한 번 생성된 오브젝트들에 대해 개발하면서 변경되는 사항을 데이터 모델과 데이터베이스에 정확하게 일치시켜가면서 변경하는 역할을 수행한다.
또한 데이터에 대한 백업 및 복구 역할을 수행하고 장애가 발생하지 않도록 세션 모니터링이나 로그 모니터링을 지속적으로 수행하는 역할을 한다.
■ 데이터베이스를 튜닝한다
구축된 데이터베이스는 데이터량이 증가할 수 있도록 SQL 문장이 비효율적으로 작성될수록 데이터베이스 서버 파라미터가 잘못 지정되어 있거나, 파일시스템 설계를 잘못하는 경우 성능이 저하될 수 있다. 이때 DBA는 데이터베이스를 애플리케이션 관점에서 튜닝(SQL)하거나 데이터베이스 서버(파라미터, 파일시스템 등) 관점에서 튜닝하는 역할을 수행한다.
IT 개발자의 역할과 비전 세미나(2): 데이터 아키텍트 / SI / 기업 전산실
모델러와 DBA가 분리되었을 때 주의해야 할 점이 있다
모델링을 하지 않고 구축된 데이터베이스만 다루는 사람은 자신이 지도 위의 어느 지점에 위치해 있는지 모르는 길 잃은 자와 같고 데이터베이스의 원리를 모르고 모델링만 하는 사람은 목적지가 없이 지도만 가지고 길을 가는 사람과 같다.
모델링을 전개할 때는 먼저는 업무로부터 논리적인 모델을 만들어 내야 하고 두 번째는 논리적인 모델로부터 데이터베이스를 생성하기 위한 물리적인 모델을 만들어 내야 한다. 그래야 데이터의 무결성도 지키면서 성능을 향상시킬 수 있는 모델링을 전개하게 된다.
반대로 데이터베이스 담당자는 모델이 어떤 비즈니스로 생성되었는지 비즈니스 모델이 어떻게 데이터베이스 모델이 되었는지를 알고 있으면서 데이터베이스를 운영 및 관리해야 한다. 그래야 정확한 데이터 스키마 관리, 성능 관리 그리고 데이터의 무결성 관리가 가능해진다.
모델러는 데이터베이스를 모르고 모델링을 하고 DBA는 업무를 모르고 데이터베이스만 관리하는 경우 좋지 않다. 이는 가장 중요한 프로세스가 끊겨버리는 현상으로 잘못된 물리 모델이 생성되거나 구축 이후 데이터베이스가 변경이 될 때 이상한 모습으로 변경이 될 수 있는 위험이 많은 구조다. 모델러도 물리적인 데이터베이스의 모습을 이해한 상태에서 모델링을 진행해야 하고 DBA도 업무의 구조와 흐름을 이해한 상태에서 물리 모델로 전환하는 작업을 직접 수행하거나 이해해야 프로젝트가 효과적으로 진행된다.
많은 프로젝트에서 보면 모델링을 하는 사람은 데이터베이스에 대해 잘 모르는 경우가 많아 정확한 데이터 모델링을 수행하지 못하는 경우가 많이 있다. 그래서 데이터베이스에서는 이렇게 처리할 수밖에 없다고 다른 사람이 이야기하면 모델이 이상한 모습으로 변형이 된다고 할지라도 자기 안에 확실한 지식이 없기 때문에 이상한 방향으로 변형되는 것을 허용하게 된다. 반대로 DBA가 모델에 대한 지식이 없으면 데이터베이스 테이블이나 PK 등에 대한 변경 요청에 대해 데이터베이스만 고려하여 무조건 반영을 하게 되어 업무적인 특징이나 모델 내부의 흐름을 단절시키는 경우가 많이 발생한다.
정리하면 모델러는 커맨드 처리에 미숙하고 DBA는 업무를 이해하여 모델을 분석하는 데 미흡하면 아주 취약한 모델링과 데이터베이스가 되는 것이다. 이러한 사실을 바탕으로 시스템 구축 프로젝트를 진행할 때 모든 모델러에게는 데이터베이스에 대한 지식을 갖출 것을 교육하고 데이터베이스 관리자에게는 업무의 흐름에 따라 데이터 모델에 대해 이해하는 방법에 대해 강조하여 교육하곤 한다. 그리고 두 역할은 분리된 역할로 존재하는 것이 아니라 상호간의 중복된 영역을 있음을 인정하고 상호간에 교류를 많이 해야 한다.
본 컨텐츠는 IT 각 분야의 전문 프로그래머 7인의 경험적 철학을 담은 도서 [나는 프로그래머다] 중 이춘식님의 글에서 발췌한 것입니다.
TAG :
이전 글 : MVC 모델과 Observer 패턴
다음 글 : 임베디드 시스템을 위한 GNU dbm의 소개
최신 콘텐츠