DBA 혹은 DB팀의 R&R을 정의 할 때
대기업은 DBA 포지션이 오래전부터 유지된 경우가 많아 그 회사에 맞는 R&R이 이미 정의되어 있습니다. 반면 스타트업은 DBA가 없다가 생기면서 R&R과 정책을 직접 정의해야 하는 경우가 많습니다.
DBA의 업무 영역은 크게 운영관리 영역과 구축·설계 영역으로 나뉩니다.
클라우드 환경과 온프렘 환경, 어떤 데이터베이스를 주로 사용하느냐에 따라 역할이 달라집니다.
2000년대 오라클을 주로 사용하던 시기에는 DBA가 운영관리 업무만 담당하고, 설계는 DA(Data Architect)나 컨설턴트를 고용하며, 유지보수와 트러블 슈팅, 엔진 설치 같은 엔지니어링 업무는 유지보수 업체에 맡기는 경우가 있었습니다. 백업은 정책만 수립하고 백업 솔루션을 도입하거나 유지보수 업체에 맡기기도 했습니다.
클라우드 환경에서 AWS 같은 매니지드 서비스를 사용하는 조직은 엔진 설치, 패치, 백업 같은 인프라 계층 작업이 벤더에 위임되어, 비즈니스 로직에 따른 설계, 구축, 개선 업무에 집중하게 됩니다.
SRE(Site Reliability Engineer)처럼 DBRE(Database Reliability Engineer)로 DB 인프라와 모니터링, 자동화를 위한 개발 업무를 함께 수행하는 경우도 있습니다. DBRE의 역할과 DBA와의 차이는 데이터베이스 신뢰성 엔지니어(DBRE)를 참고하세요.
하나의 기종에 특화되기보다 다양한 기종의 데이터베이스를 다룰 수 있는 편이 유리해졌습니다.
풀 매니지드 데이터베이스는 벤더가 많은 부분을 관리하므로 운영과 유지관리 부담이 줄어들고, 비즈니스 로직에 집중할 수 있는 환경입니다. DBA 업무보다 DA 업무가 주를 이루는 경우도 있습니다.
신규 서비스 개발에서 DBA의 역할
신규 서비스를 런칭할 때는 여러 데이터베이스 기종을 고려할 수 있지만, 신기종 도입에 따른 부담이나 책임을 감당하기 어렵다면 조직에서 이미 운영 중인 데이터베이스를 선택하게 됩니다.
데이터베이스를 선택할 때는 회사의 인력풀, 매니지드 서비스와 설치형 오픈소스 중 어느 것을 쓸지, 다른 부서의 학습 부담 등을 고려해야 합니다.
개발팀과 새로운 기술을 시도할 의지가 있다면 선택의 폭이 넓어집니다.
기종 선택과 데이터 모델링은 서비스의 성능과 확장성을 결정합니다. 데이터 모델링은 사용하려는 DB 엔진이 어떻게 동작하는지 정확히 알아야 가능합니다.
RDBMS는 데이터 중복을 줄이고 데이터 무결성을 지키면서, 비즈니스 로직에서 과도한 JOIN이 발생하지 않도록 절충하는 것이 중요합니다. MongoDB 같은 도큐먼트 기반 NoSQL은 어떤 요소를 임베디드시킬지 릴레이션으로 구성할지, 배열로 처리할지, 서브도큐먼트를 어떻게 사용할지, 하나의 도큐먼트에 어떤 데이터를 얼마만큼 담을지 결정해야 합니다. 이러한 판단은 모두 DB 아키텍처를 잘 알아야 내릴 수 있습니다.
계정 권한 관리, 데이터 표준화를 위한 네이밍 규칙, 개발 가이드, DB 가이드를 초기 설계 단계부터 제공하면 기본이 튼튼한 서비스를 만들 수 있습니다.
정책이나 R&R이 명확하지 않은 조직이 있습니다. 정책서 작성과 부서 간 R&R을 정의할 때 관련 자료를 참고하여 모두가 납득할 수 있는 방향을 설정하는 것이 중요합니다. 회사가 원하는 업무를 수행하면서도 서로 윈-윈할 수 있는 결과물을 만들어야 합니다.
DB 업무를 하는 모든 분이 커리어를 잘 관리하시길 바랍니다.