DBA 혹은 DB팀의 R&R을 정의 할 때

DBA 혹은 DB팀의 R&R을 정의 할 때

대기업의 경우는 DBA 포지션이 오래전부터 유지된 경우가 많아 그 회사에 맞는 R&R이 이미 정의 되어 있는 경우가 많습니다. 반면 스타트업의 경우 DBA가 없다가 생기는 경우에는 R&R과 정책을 직접 정의해야 하는 경우가 많습니다.

일반적인 DBA의 업무 영역은 다음과 같습니다.

일반적인 DBA 업무

크게 운영관리 영역과 구축, 설계 영역이 있습니다.

클라우드 환경과 온프렘 환경, 그리고 어떤 데이터베이스를 주로 사용하느냐에 따라 롤이 축소되기도, 늘어나기도 합니다.

예전에 오라클이 주로 사용하던 시기에 DBA는 운영관리 업무만 담당하고, 설계는 DA나 컨설턴트를 고용하고, 유지보수 및 트러블 슈팅, 엔진 설치 같은 엔지니어링 업무는 유지보수 업체에 맏긴다거나, 백업의 경우 정책만 잡고 백업 솔루션을 도입하거나 유지보수 업체에 맡기는 경우가 많았습니다.

지금은 클라우드 환경이 많고 AWS 같은 클라우드 밴더를 사용하는 스타트업의 경우는 엔지니어링 측면에서 많은 부분이 밴더사의 매니지드 서비스를 종속 되기 때문에, 대부분 비지니스 로직에 따른 설계, 구축, 개선 업무에 집중되게 됩니다.

요즘은 SRE 처럼 DBRE로 DB 인프라나, 엔지니어링 측면에서의 모니터링 또는 자동화를 위해 개발 업무를 같이 하거나 하는 경우도 많습니다.

그리고 하나의 기종에 특화 되어 있으면 좋지만 다양한 기종의 데이터베이스를 다룰수 있는 편이 더 유리 해졌습니다.

풀 매니지드 되는 데이터베이스의 경우 엄청난 수준의 튜닝을 적용하거나 딥하게 지식을 보유하고 있지 않아도 어느정도 운영과 유지관리가 되기 때문에 오히려 비지니스 로직에 집중할 수 있는 환경이기도 하죠. DBA 업무도 하지만 DA 업무가 주를 이루는 경우가 많습니다.

신규 서비스를 개발하는데 있어서 DBA의 역할

신규 서비스를 런칭 해야 할 때 이것 저것 해보고 싶은게 많을 수 있습니다. 그렇다고 내가 잘하는 DB가 최적의 DB가 아닐수도 있고, 신기종 도입에 따른 부담이나 책임을 스스로 가져갈 수 없다면 일반적으로 사용하던 DB를 사용하는 경우가 많습니다. 그래서 현재 시장에 MySQL이 그렇게 많은가 봅니다.

데이터베이스를 선택하는 과정에서도 회사의 인력풀을 고려해서, 매니지드 서비스를 선택할 것인지, 설치형 오픈소스를 선택할 것인지, 또 다른 부서에서 발생하는 DB에 대한 러닝커브나 기타 요소들을 고려 해야합니다.

같이 일하는 개발팀과 성향이 맞아서 ‘새로운거 해보자’ 같이 으샤으샤  할 수 있다면 선택의 폭이 넓어지긴 합니다.

기종 선택과 데이터 모델링이 중요한데, 데이터 모델링이라는 건 사용하려는 DB의 엔진 어떻게 동작 하는지 정확히 알아야 그에 맞는 설계가 가능해집니다.

RDBMS는 데이터 중복을 줄이고, 데이터 무결성을 지키며, 비지니스 로직에서 너무 많은 JOIN이 발생하지 않게 절충하는게 중요하고, MongoDB 같은 도큐먼트 베이스의 NoSQL은 어떤 요소를 임베디드 시킬 것인지 릴레이션으로 꾸릴 것인지, 배열로 처리할 것인지, 서브도큐먼트는 어떻게 사용할 것인지, 하나의 도큐먼트에 어떤, 그리고 얼마 만큼의 데이터를 담을 지 결정하는 것도 DB의 아키텍처를 잘 알아야 결정할 수 있는 문제입니다.

그리고 계정의 권한이나 데이터 표준화를 위환 네이밍 규칙 및 개발 가이드, DB 가이드를 잘 제공해야 초기 설계 단계부터 기본이 튼튼한 서비스가 나올수 있게 됩니다.

DBA로 입사해서 정책이나 R&R이 명확하지 않은 곳이 많았습니다.

정책서 작성과 부서간 R&R을 정의할 때 참고 할 수 있는 자료들 잘 참고해서, 모두가 납득할 수 있고, 자신이 회사에서 원하는 방향, 스스로 직무에서 원하는 방향을 잘 설정하고  나아가는 것이 중요합니다. 회사가 원하는 업무를 하는 것도 중요한데, 서로가 윈-윈 할 수 있는 결과물을 만드는 것이 중요합니다.

DB업무하시는 모든 분들이 커리어를 잘 챙기시길 바랍니다.