DBA - 데이터베이스 관리자(DataBase Administrator)

Intro

안녕하세요.

초보 DBA 다뉴입니다.

 

Database 관련 글을 쓸 때면, 초보 DBA 라는 말로 저를 소개하곤 하는데요.

관련 직무에 종사한지 5년이 넘었지만, 이제야 본격적으로 DBA 직무를 맡게 되어 그렇게 소개하곤 합니다.

DBA 라는 직무는 학부생 때 부터 꿈으로 가지고 있었는데, 꿈을 이루어 이렇게 소개할 수 있게 되어 너무 행복하네요.

 

저는 DBA 라는 직무에 엄청난 자부심을 가지고 있는데요. (저희 팀장님도 DBA 라는 단어를 매우 좋아하십니다.)

근데 주변에 저를 소개 할 때 면, IT업계 종사자가 아니고서는 DBA 라는 직무를 잘 모르더라구요.

그래서 보통 다들 알아 들을 수 있는 'IT업계 종사자' 또는 요즘 핫한 단어인 '개발자' 라고 소개합니다. 틀린 말은 아니지만 그래도 제가 가지고 있는 자부심에 대해 다 설명하지 못 하는거 같아 조금 아쉬운 마음이 드네요.

 

DBA 란 무엇이며, 왜 DBA 가 되고 싶었는지 저의 생각에 대해서 글을 좀 써볼까 합니다.

DBA가 무엇일까...? 막상 적으려하니 조금 막막하기도 합니다.

시대가 바뀌며 DBA 의 업무도 변하기도 하고, 사실 어디까지 DBA 의 업무라고 나누기는 쉽지 않은 것 같습니다.

그럼에도 한번 쯤 제 업무에 대해 한번 이야기 해보며, 혹여나 다른 분들의 의견도 한번 들어보고자 글을 남겨볼까 합니다.

 

그럼 DBA 가 무엇인지, 왜 DBA 가 되고 싶었는지에 대해서 한번 이야기 나누어 보도록 하죠.

 

전문적인 글이라기 보다는 저에 대한 소개와 생각을 적은 글로 봐주시면 감사하겠습니다.

---

DBA 란?

DBA (DataBase Administrator)는 단어에 뜻 그대로 데이터베이스를 관리하는 사람입니다.

이 DBA 글자 속, '관리자' 이 한 단어에 많은 책임과 임무를 담고 있습니다.

 

간혹 '데이터를 관리한다' 라고 생각을 하는 분들도 있을 건데요.

물론 데이터도 관리하지만 직무의 주 목적은 '데이터베이스 관리' 입니다.

 

데이터베이스 (DataBase)는 데이터를 저장하고 관리하는 프로그램입니다.

'그냥 저장만 하면 되는것 아니야?' 라고 생각 할 수 있겠지만,

데이터를 저장하고 사용하는데 있어서 수 많은 노력과 관리가 필요합니다.

 

DBA (DataBase Administrator) 라고 하면, 데이터베이스 자체의 관리자를 말하는데요.

기본적으로는 데이터베이스 운영에 대한 업무가 DBA의 주 업무입니다.

• 운영 / 관리
• 모니터링
• 백업 / 복구
• 장애 예방 / 대응

데이터베이스 운영에 대한 모니터링, 장애 대응/예방, 백업/복구 등이 주 업무라고 볼 수 있겠네요.

하지만 시대에 발전으로 오픈소스 툴, 하드웨어 사양, 데이터의 중요도와 복잡성으로 인해 데이터베이스에 관련된 추가적인 업무를 전반으로 하는 느낌입니다.

• 비용절감을 위한 오픈소스 툴 활용 / 개발
• 업무 효율을 위한 개발 및 OS활용 / 설정
• 데이터에 구성에 대한 데이터 아키텍쳐 (DA - Data Architecture)
• 서비스 안정화 및 성능 향상을 위한 쿼리 튜닝, 하드웨어 / 소프트웨어 튜닝
• 복잡해져가는 서비스에 대한 영향을 최소화 하기위한 서비스 / 데이터 이해
• 회사의 방향성과 업무 효율을 위한 데이터 통계 및 분석

위 업무를 '최근 DBA 업무가 되었다' 라고 말하는 것도 어렵다고 생각은 드는데요.

DBA의 범위가 어디까지인지 저도 명확하게 말하기가 쉽지 않은 것 같습니다. (시키면 다하는...?)

이렇게 보면 '데이터 아키텍터', '데이터 엔지니어', '시스템 엔지니어', '디벨로퍼' 등의 업무도 간략하게나마 함께 수행하고 있습니다. 

사실 생각해보면... 위에 나열한 직무들도 다른 직무의 업무도 같이 진행하는거 같은데...

하지만 DB관리에 있어서는 DBA 고유 권한이라는거! 다시한번 강조합니다 :)

 

또한, 예전에는 주로 Oracle을 사용했기에 Oracle만 알면 크게 문제가 없었습니다. (그런데 전 지금에서야 오라클을 배우네요)

하지만 갈수록 비싸지는 Oracle의 라이센스 비용과 상황에 맞는 DBMS를 선택하다보니 오픈소스 데이터베이스의 비중이 많이 늘게 되었습니다.

주로 MySQL/MariaDB, PostgreSQL등을 많이들 사용하며, 역시나 비용이 저렴하거나 무료인 만큼 운영관련 세팅을 직접하고 관리 해줘야 하는 추가적인 업무 덕에 OS와 하드웨어에 대한 이해도가 많이 필요하게 된 것 같네요.

 

결과적으로 이런저런 이야기를 다 요약하자면, DBA는

'클라이언트가 필요로 하는 데이터를 운영/관리하기 위해 데이터베이스와 관련된 모든 것을 관리하는 것'

이라고 생각이 들기도 합니다. 

---

이런저런 설명이 어려울때에는 데이터베이스를 설명 할 때 물류창고라고 비유,

DBA는 그 물류창고를 관리하는 사람이라고 비유하여 설명해주고는 합니다.

 

물건만 쌓으면 되는게 아니고 

어디에 어떤 물건이 얼만큼 있고, 그 물건을 얼마나 빨리 찾을 수 있는지

물건을 이동시키는 트럭들이 지나가는 길목은 잘 정비되어 있는지, 도로가 막히지는 않는지

물건에 이상한게 포함되어 있지는 않는지, 위험물품이 있지는 않나 확인하고

만약에 사태가 발생했을 때 어떤 과정으로 그 사태를 해결할지 훈련하고, 문제 해결을 책임지는

반응형

이렇게 또 비유해보니 좀 비슷한거같네요!

---

왜 DBA가 되고 싶었는가?

컴퓨터공학과를 다니며, 컴퓨터와 개발에 관련 된 여러 과목을 배웠습니다.

데이터베이스는 컴퓨터공학과의 여러 과목 중 하나였는데, 그때 부터 데이터베이스가 좋았던 것 같습니다.

사실 너무 오래전부터 막연한 꿈이였어서 크게 기억나진 않습니다. 그래도 몇 가지 기억나는 것 들을 적어볼까 합니다.

 

데이터베이스는 대학교 강의에서 배울 때 부터 저에게 가장 많이 와닿았는데요.

나름 정리를 좋아하는 편이라서 그런지, 데이터를 특정 포멧으로 정의하여 규칙적으로 쌓고 정리한다는 것이 매우 마음에 들었습니다.

이렇게 모인 데이터들은 서로의 규칙과 관계에 의해 섞이고 영향을 주며, 조합하여 새로운 결과를 만들어 내기도 하는데요. 이러한 내용을 보고 무언가 신기하고 세상은 다 데이터로 이루어져 있다는 생각이 들곤 하였습니다.

이렇게 데이터베이스에 관심을 가지게 되어 DBA 라는 직무를 알게 되고, 막연히 DBA 가 될거야 라고 생각했었네요.

 

근데 졸업 할 쯤 알게 된 사실은... DBA는 신입을 거의 안뽑는 다는 사실이였습니다.

덕분에 구직중에 많은 좌절을 겪었네요.

졸업 후 조금 방황 하다가 DBA 는 아니지만 데이터를 다루고 데이터베이스를 관리하는 팀에 합류하게 되었습니다.

 

첫 번째 회사에 취직하여 데이터 엔지니어? + DBA 일도 할 수 있는 포지션이 되었고, 그렇게 데이터를 관리하는 데이터베이스를 사용하는 사람이 되었습니다.

이때 데이터의 흐름과 관계, 구성에 대해서 많은 것을 배운거 같습니다.

좋은 팀장님과 팀원분들을 만나서 쉽고 편하게 많은 것을 배웠고, 그때의 팀장님도 항상 저에게 DBA 가 되게 공부하라고, 여기서 해보고 싶은 것이 있으면 다 해보라고 말씀해주셨었습니다.

 

두 번째 회사인 지금은 수 많은 면접과 실패 속에 운 좋게 붙어 DBA 직무로 전향하여 이직하게 되었습니다.

이직한 지금의 회사에서도 좋은 팀장님과 팀원들을 만났는데요.

이직 할 때 가장 걱정했던 점이 사람이였는데, 너무나 다행입니다.

지금의 팀장님은 무엇라도 하나 더 가르쳐 주려하시고, 새로운 것을 찾아 도전하는 분이신것 같습니다.

팀 회의 하다보면 팀장님의 강의시간이 되곤합니다.

그래서 놓치지 않고 배울게 너무 많아 요즘 녹음을 하면서 회의에 참여합니다.

강의를 놓치기엔 너무 아깝거든요.

 

어떻게 DBA 라는 문까지는 어떻게 열었는데요.

지금부터가 너무나 막막하고 어렵네요. 그 동안 정말 아무것도 모르고 일을 했다는 것이 느껴집니다.

이제는 정말 자세히 알고 확신을 가지고 일을 해야하는데, 모르는게 많다보니 하나를 알아보려 해도 파고들어가면 더 자세한 내용을 알아야하고, 이러다 보면 깊게 깊게 파고들고 있는 제 모습을 보고있네요.

 

---

DBA 의 업무

DBA의 업무가 무엇일까 많은 고민을 해봤습니다. 여러가지 영역의 업무를 하고 있는거 같은데요.

제가 하고있는 업무, 앞으로 해야 할 업무, 보고 들은 업무 등에 대해서 나열할까 합니다.

 

정답은 아닐지라도 완전한 오답은 아닐테니 참고해주세요!

목록

• 분석 단계
  • 클라이언트 요구 분석
  • 시스템 분석
  • 데이터 분석
  • ERD 분석 및 검토
• 설계 단계
  • 데이터베이스 설계 및 세팅
  • 오브젝트 설계
  • 데이터 모델링
  • 데이터 정의 / 코드 정의
  • 사용자 정의
  • 표준화 (명명규칙, 용어사전, 도메인 등 정의)
  • SQL 가이드 작성
• 개발 단계
  • 오브젝트 개발
  • 배치성 작업 개발
  • 운영에 필요한 툴 개발 및 세팅
• 운영 단계
  • 데이터베이스 운영
  • 데이터베이스 백업 / 복구
  • 이중화(HA) 구성 / 재해복구(DR) 구성
  • 리소스 관리 및 모니터링
  • 인덱스 리빌딩
  • 데이터 파일 관리
  • 데이터 보안 관리
  • 각종 트러블 슈팅
• 그 외 기타 업무들

분석 단계

분석 단계는 말 그대로 클라이언트의 요구사항에 대한 분석을 진행합니다.

어떤 시스템이 만들어 질 것인지 그에 따라 서비스에 필요한 데이터, 적재될 데이터 등을 분석하여 데이터들의 관계 도식을 만들어 가는 과정이라고 볼 수 있을 것 같습니다.

 

이 단계에서 분석 한 데이터를 기준으로 ERD를 작성하여, 서비스에 사용될 물리적인 데이터와 데이터들의 관계를 정의합니다.

서비스 개발 진행시 어떠한 데이터를 서비스에서 주고 받으며, 쌓고 사용할지 뼈대를 잡는 중요한 작업이라고 할 수 있을 것 같네요.

설계 단계

분석 단계에서 분석된 요구사항과 시스템에 대해 필요로한 물리적인 데이터들이 분석되고 정의되었는데요.

분석되고 정의된 시스템과 물리적 데이터들을 이제 논리적으로 설계하는 단계입니다.

 

분석된 시스템에 맞는 데이터베이스를 설계합니다.

서비스에 맞는 어떤 데이터베이스를 쓸지 비용은 어느정도 예상하는지 등이 매우 중요한 고려사항 일 것 같네요.

그 다음은 데이터베이스에서 사용될 각종 오브젝트 들을 정의합니다.

테이블, 테이블의 PK와 Index, 각종 스케쥴 등을 설계하며, 해당 오브젝트들을 설계함에 명명규칙을 작성하여 표준화 작업을 진행합니다.

개발 단계

분석과 설계된 오브젝트들을 개발하는 단계입니다.

설계된 테이블과 index등을 개발하며, 각종 프로시저, 배치작업 등을 개발하고 유저 룰 등을 설정합니다.

또한, 앞으로의 모니터링 및 운영에 필요한 툴들을 개발합니다.

운영  단계

가장 중요하고 DBA 다운? 일을 하는 부분인데요.

데이터베이스를 운영하는 단계입니다. 

데이터베이스에 무리가 가지않도록 항상 모니터링하며, 유지관리를 해줍니다.

또한, 어떠한 돌발상황이 발생하더래도 데이터를 무사히 지켜야 하므로 백업과 복구에 대한 철저한 준비가 필요하며,

이를 위해 이중화 혹은 재해복구 시스템을 구성해둡니다.

서비스 제공에 있어 미처 분석되지 못하여 슬로우 쿼리 발생시 해당 쿼리에 대한 분석 및 슈팅을 해줘야하며,

데드락과 같은 데이터베이스상에서의 문제를 주의해야합니다.

서비스가 제공되며 시간이 지날수록 데이터가 변경됨에 따라 인덱스에 파편화, 데이터파일의 크기 변화 등에 대한 모니터링 및 예방점검이 필요합니다.

그 외 기타 업무들

음...

가끔 대용량 데이터에 대한 추가, 변경이 필요 할 경우 데이터베이스 내에서 해결해야할 때가 있습니다.

이러한 업무에 대한 지원을 주로 많이하는 것 같네요.

혹은 각종 데이터의 조합으로 어떠한 통계가 필요할때, 해당 쿼리를 개발하여 통계를 전달하는 등의

대용량 데이터 조회 및 분석에 대한 지원도 하게 됩니다.

---

현실적인 DBA 의 업무

위에서 DBA 의 업무에 대해 각 단계별로 나누어 나열하여 설명하였는데요.

사실 저렇게 업무를 진행 하기란 쉽지 않다고 생각되네요.

처음부터 DBA 가 함께 포함되어 작업한다면 저런 단계의 저런 업무를 맡아서 할 수 있을것 같지만,

현실은 나중에 충원으로 합류한 DBA 분들이 주 일겁니다.

 

이미 구성되어있는 시스템에 대해 영향을 최소한으로 주는 쪽으로 업무를 진행하게됩니다. 서비스에 문제가 생기면 안되니까요.

그러다보니 사업의 성장으로 인해 새롭게 추가/변경되어야할 데이터나 오브젝트가 있을 경우 이미 만들어진 모든 오브젝트들에 대해 영향력을 한번씩 확인하고 추가/변경 하게 됩니다. 간단한 업무가 간단해지지 않는 과정이죠.

 

또한, 그동안 이렇게 추가된 데이터들과 오브젝트들이 얼마나 많을까요. 점점 관계들이 꼬이면서, 슬로우 쿼리나 데드락 등이 발생하게 될 것 입니다. 이런 부분들을 찾아 튜닝하는 것 쉽지않네요.

 

누군가가 만들고 남겨둔 프로시저나 스케줄, 작게는 뷰나 테이블 이것들을 보며 어디에 사용되는 것인지 지금 영향이 있는

것인지 분석하는 업무도 많은 것 같습니다. 새롭게 추가되는 것에 영향이 있는지 확인하다 보면 끝이 없으니까요.

 

또한 파편적으로 나눠져있거나, 하나로 너무 뭉처있는 시스템들을 적절하게 분산하여 적절한 리소스를 유지하도록 전체를 아우르는 분석도 필요할 것입니다.

 

이렇게 간략하게 업무를 적어봤습니다.

이렇게 적고보니 물론 이런저런 업무를 다 진행하지만, 역시 제일 중요한건 서비스에 영향이 얼마나 가느냐 인 것 같습니다.

 

그리고 관리적으로 중요한 것은 역시 규칙적인 문서화 혹은 표준화인 것 같네요. 그래야 다른 누군가가 한번에 알기 쉬우니까요.

---

Outro

업무에 대해 너무나 두서없게 글을 썼는데요.

DBA 업무란게 무엇인가 쓰려보니 느낀 것 이지만, 아는 것을 말로 풀어쓰기가 정말 어려운 것 같습니다.

그리고 이론적인 내용과 현실은 다르니까요.

제가 더 발전하고 글을 잘 정리할 수 있다면, 글을 다시 수정하여 업무에 대해 좀 더 자세히 적어보고 싶네요.

지금 써둔 것을 보니 마음에 들지 않습니다. 잘 전달하기 어렵네요.

---

이러니 저러니 해도 글을 마무리 해야할 것 같습니다.

저에 대해 다른분들에게 설명하고 싶어 쓰기 시작한 글인데요.

잘 전달이 될지 모르겠습니다. 

저 나름 DBA 에 엄청난 자부심을 가지는데 DBA 라는 업무를 제가 설명 못하는 것도 좀 많이 이상하네요.

아직 직접적으로 겪어본 것이 적어서 그런걸까요? 앞으로 많이 배우고 많이 느껴보며, 발전해 보도록 하겠습니다.

 

이상으로,

초보 DBA 다뉴였습니다.

감사합니다.