데이터베이스에 대해 아직도 많은 사람들은 간단하게 생각한다. 데이터베이스를 담당하는 사람이 무엇을 하는지를 모른다. 이는 매우 안타까운 일임에 틀림없다. 하지만 많은 곳에서 이러한 생각이 점차 변하고 있다는 것이 그마나 다행인 것 같다.

데이터베이스를 담당하는 사람이 모든 것을 다 하는 것은 아니다. 데이터베이스도 그 영역이 분리되어 있다. 그럼에도 불구하고 많은 사람들은 아직 그런 것을 모르는 것 같다.

데이터베이스 업무에는 DBA, 튜닝, 모델링, 데이터 품질 및 데이터 마이그레이션이라는 분야가 존재한다. 그럼에도 불구하고 한 명의 DBA가 모든 것을 다 해야 한다고 생각하는 사람들도 있다. 이러한 생각을 전환하는 것이야말로 데이터베이스를 최적화하는 지름길임을 이야기해 보자.

이번 강의부터는 데이터베이스에서 반드시 변해야 될 생각의 전환에 대해 기술적인 부분과 사고적인 부분을 다양하게 다뤄 본다. 그 첫 번째로 DBA에 대한 생각의 전환을 확인해 보자.

DBA란 무엇인가?

DBA가 무엇인지를 말하는 것은 매우 어려운 이야기이므로, 먼저 필자가 일했던 곳의 이야기로 시작해 보자. 필자가 일했던 곳 중 하나는 전문 DBA 그룹의 책임을 가지고 있다.

팀이다 보니 팀장도 있고 많은 팀원들도 있다. 개인별로 다르지만 담당자들은 인당 10대 이상의 데이터베이스를 관리했다. 또한, 데이터베이스 업무 외에 팀 기획 등의 업무를 수행했다. 물론 개인별로 작업이 많은 사람도 있고 적은 사람도 있다.

DBA로 수행하는 업무는 주로 담당 서버에 대한 모니터링, 장애 처리, 데이터베이스 작업이 주를 이뤘다. 모니터링, 장애 처리, 데이터베이스 작업은 주기적인 작업도 필요하지만 불규칙적으로 발생하는 작업이 더 많다.

문제는 DBA의 이런 작업들이 어느 정도 양인가라는 점이다. 이와 같은 작업들이 절대 적은 양은 아니다. 그렇다면 DBA는 구체적으로 어떤 일을 하는지 확인해 보자.

• - 모니터링 : 운영 시스템에 대한 로그 확인, 테이블스페이스 공간, 오브젝트 상태 및 백업 상태 확인
• - 장애 처리 : 운영 시스템에 여러 가지 이유로 문제 발생 시 문제에 대한 해결 방안 제시 및 처리
• - 정기 작업 : 파티션 테이블 작업 또는 백업 등을 수행하며 기타 정기 작업에 대한 수행
• - 요청 작업 : 테이블 생성, 인덱스 생성 등의 요청 작업에 대한 수행
• - 백업 및 복구 : 백업에 대한 전략 수립 및 장애 시 복구 수행

위와 같은 작업들을 생각해 본다면 당연히 DBA가 수행해야 하는 작업이라고 생각할 것이다. 물론 DBA가 수행해야 하는 작업임에 틀림없다. 그렇다면 과연 이와 같은 작업들이 어느 정도의 업무량이 되는 것일까?

과거 데이터베이스가 아닌 다른 쪽 일을 하다가 데이터베이스로 전향한 사람과 이야기했던 내용이다.

과거 다른 분야의 업무를 수행했을 때는 1년에 큰 작업이 몇 번 없었으며 작업 시에도 미리 많은 준비를 해서 큰 어려움이 없었단다. 또한 시스템을 정지시키고 충분한 시간을 가지고 작업을 수행했으므로 작업에 대한 부담은 적었다고 했다.

그러나 데이터베이스 업무를 수행하면서부터 작업 하나 하나에 너무 많은 신경이 쓰이고 작업이 많은 날에는 10개 이상의 긴급 작업이 요청되고 또한 문 제 발생 시 바로 해결하지 못하면 낭패를 당하기 쉽다고 이야기했다. 그러서인지 예전 하던 일을 다시 했으면 하는 바람도 있다는 말을 했었다.

이처럼 데이터베이스를 관리하는 DBA는 결코 쉬운 일이 아니다. 하지만 아직도 많은 사람들이 이와 같은 데이터베이스 관리자인 DBA가 무엇을 하느냐고 말하곤 한다.

사실 DBA는 데이터베이스의 장애를 사전에 방지하고 데이터베이스 장애 시 해당 문제를 해결하는 것만으로도 그 회사의 어떤 누구보다도 더 많을 일을 하는 것이라는 걸 이해해야 할 것이다.

DBA가 튜닝과 모델링도 해야 하는가?

많은 사람들은 데이터베이스 관리자인 DBA에게 튜닝 및 모델링도 당연히 하는 것 아니냐고 말한다. 이것은 본인에게 개발하고 DBA도 하고 시스템 관리자도 같이 하라는 의미와 마찬가지다.

이것은 한마디로 불가능한 것이다. 홀로 해당 시스템에서 DBA, 튜닝, 모델링을 모두 잘해낼 수 있는 사람은 없을 것이다.

왜 이와 같은 현상이 발생할까? 이는 튜닝이나 모델링은 데이터베이스 관리자인 DBA와는 또 다른 영역이기 때문이다. 물론 데이터베이스의 영역이지만 튜닝과 모델링은 DBA와 달리 다른 영역을 많이 이해해야만 가능하다.

그렇기 때문에 세 가지 영역을 모두 최적으로 수행하기는 힘들다. 그럼 각각의 영역은 무엇을 수행하는 업무인지를 확인해 보자.

• - DBA : 데이터베이스 관리자
• - 튜닝 : SQL 최적화를 중심으로 파라미터 최적화, I/O 최적화를 수행하며 애플리케이션 분석을 통해 최적화를 수행
• - 모델링 : 해당 시스템의 업무를 분석해 데이터를 관리하는 저장소를 업무에 맞게 구성하고 구현하는 업무

이와 같이만 언급하면 정확히 이해되지 않을 수 있다. 하지만중요한 것은 데이터베이스 관리자인 DBA와 튜닝 및 모델링은 다른 영역이라는 것이다. 이것을 정확히 이해해야만 프로젝트를 성공적으로 수행할 수 있다.

DBA의 존재 의미를 이해하라

어떤 사이트를 가보면 DBA가 없거나 DBA 혼자서 모든 것을 하는 경우가 많다. 또한, 데이터베이스 관리자인 DBA를 필요로 하는데 단지 비용만을 비교하는 사이트도 많다. 이와 같은 사이트는 언젠가는 큰 어려움을 경험하게 될 것이다.

얼마전 어떤 사이트에서 연락을 받았다. 해당 사이트는 데이터베이스 장애로 2일째 데이터베이스가 기동되지 않는 상황이었다. 해당 시스템의 장애로 하루 10억 원씩 손해가 발생한다고 했다.

해당 사이트는 작은 사이트임을 감안해 비용 절감 차원에서 개발자만 몇 명 채용하고 데이터베이스 관리자인 DBA는 별도로 채용하지 않았다. 단지 비용을 줄이기 위해 그렇게 했던 것이 결과적으로는 몇 십억 원의 손해를 발생시키게 되었다.

위와 같은 사이트는 지금 이 순간에도 매우 많이 있다. 조만간 발생할 문제를 인식하지 못하고 큰 재앙이 발생하게 될지도 모르는 상황에서 단지 눈 앞에 보이는 비용 절감으로 이와 같은 선택 을 했다는 것이 아쉬울 뿐이다.

해당 사이트들은 분명히 조만간 큰 어려움을 경험하게 될 것이며 이것은 소 잃고 외양간 고치는 격이 될 것이다.

DBA는 큰 장애에 대해 해당 장애를 처리하는 것만으로도 회사에 매우 큰 이득을 가져다 준다. 이것이 바로 DBA가 존재하는 이유일 것이다.

단지, 비용만을 가지고 DBA를 고용할지 안 할지를 고민하지 말길 바란다. 또한 DBA를 고용한다면 해당 사이트를 최적으로 관리할 수 있는 실력을 갖춘 사람을 선택해야 할 것이다.

생각의 전환은 바로 이것이다. 데이터베이스 관리자인 DBA가 무엇을 해야 하는지를 정확히 이해해야 하며 DBA가 하는 일이 얼마나 중요한지를 이해하길 바란다.

DBA가 존재해야 하는 이유를 이해하는 것은 해당 시스템을 최적으로 관리할 수 있는 바탕이 될 수 있다. 이제라도 늦지 않았다.

이와 같은 생각의 전환을 하지 못한 분들은 지금부터 이런 생각의 전환을 통해 해당 시스템을 최적으로 관리하길 바란다. 그것이야말로 해당 시스템을 책임지는 사람들이 해야 할 생각이 아닐까?