Database Specialist or Generalist ?!

 

Database Specialist or Generalist ?!

서론

이런 글을 쓰게 된 이유는 최근 들어 많이 생각하게되고, 주변 DBA분들이나 비슷한 종사자 엔지니어들과 교류하면서 느낀점이 있기 때문입니다.

DBA라는 포지션은 지금까지 대부분 스페셜리스트였습니다. Oracle이 DBA의 대세였던 시절부터, Engineer – DBA – DA or Tuner 로 가는 테크트리를 타면서, 거의 Oracle이라는 데이터베이스 전체에 대한 스페셜리스트가 되어가는 과정이 커리어를 쌓는 과정이었습니다.

그 당시에는 오라클 하나만 잘하면 된다는 분위기가 강했고, ‘오라클 한다고 하면 밥은 굶지 않고 살겠다’, ‘IT 쪽 종사자들 중에서는 그래도 잘버는 포지션’ 이런 느낌이 있었습니다. 어디까지나 스페셜리스트로 인프라 가장 깊은 티어에서 성능을 관리하던 사람들이었으니까요.

 

요즘은 기술의 발전이 엄청나게 빠르고, 다양한 제품이 쏟아지고 있고, 어떤 제품이 떠올랐다가도 하루 아침에 사라져가기도 합니다.

이러한 기조는 클라우드 서비스가 IT의 기반이 되어, 레가시 서버들을 다루던 시대보다 빠르게 시스템을 구축하고, 유연하게 스케일 업, 아웃을 할 수 있게 되면서, 개발 속도가 빨라지고 다양한 아이디어를 구현하기 위한 다양한 솔루션이 필요해진 시대가 왔기 때문입니다.

사람들은 빠른 개발을 위해 좀 더 편한, 좀 더 쉬운 솔루션을 찾기 시작했고, 아무리 좋은 제품이라도 지속적인 업데이트와 문서 제공이 부족한 경우 쉽게 도태되는 환경이 만들어졌습니다.

많은 업계 종사자들이 파이썬이 좋은 언어라고 하는 이유는 정말 배우기 쉬우면서도 정말 다양한 것을 할 수 있기 때문입니다. 프론트, 백엔드, 분석, 스크레이핑, 크롤링, 임베디드 까지… 재주가 많은 언어이기 때문에 가장 많이 사용하게 된 언어입니다. 그리고 지속적인 업데이트와 성능 향상은 파이썬의 가장 큰 장점입니다.

이렇듯 많은 사람들로부터 선택 받고, 꾸준히 사랑 받는 제품은 최근 트렌드를 잘 반영하기도 하고 다양한 분야에 걸쳐 사용할 수 있다는 장점이 있습니다.

 

데이터베이스도 마찬가지 입니다.

돈이 많은 대기업, 그리고 안정성이 최우선인 금융권 등은 오라클을 여전히 메인으로 사용합니다. 하지만 스타트업으로 시작해 최근 잘나간다하는 IT 공룡 기업들과 많은 스타트업들이 오픈소스 진영을 택하고 있습니다.

클라우드에 서비스를 올리고, 매니지드 서비스를 사용합니다. 초기 구축단계에서 전문가의 필요성이 줄어들고 다양한 데이터베이스를 사용하고 있습니다. 그리고 스타트업 특유의 안정성 우선 보다는 한 번 해보자 하는 도전 정신도 한몫하고 있습니다.

MySQL, PostgreSQL, MongoDB, Redis, Elastic Search, Neo4j, HBASE, Cassandra 등등 무조건 데이터베이스는 RDBMS가 아닌, 원하는 서비스의 특성을 고려한 선택이 늘고 있습니다.

DBA가 모든 DB를 다 다룰수는 없고, 특정 기종의 데이터베이스 하나만 공부해도 해야 할 것들이 너무 많기 때문에 그동안 많은 DBA들이 자기가 다루지 않는 DB에 대해서는 적극적인 움직임을 보이 않은것도 사실입니다.

그동안 DBA의 문화는 폐쇄적이었고, 다른 IT 종사들에 비해 교류도 적은 편이었습니다.

하지만 오픈소스 DB들이 수면위로 떠오르면서, 자료가 부족하고, 원서를 번역해야 했고, 레퍼런스를 구하기 위해 서로 교류할 수 밖에 없는 환경으로 변화했다고 생각합니다.

 

그럼 우리는 Specialist 가 될 것인가? Generalist가 될 것인가?

여전히 DBA는 스페셜리스트라고 생각합니다. 저 역시 데이터베이스 커뮤니티를 운영하고 있지만 많은 고수분들의 대화의 깊이를 따라가지 못할때가 많습니다. 이런부분은 정말 심각한 장애를 처리한다거나, 대용량 트래픽을 처리하는 데이터베이스에서 성능관리에서 최고의 퍼포먼스를 내는 밑바탕이 됩니다.

DBA는 대부분 안정성에 기반을 두고 운영을 할 수 밖에 없었고, 새로운 버전이 나온다고 해도 안정화 되었다는 보장이 없으면 최신버전으로 버전업 같은건 쉽게 생각하지 못했습니다.

한정적인 자원, 비용 안에서 최적의 퍼포먼스를 낼 수 있어야 하는 포지션이었기 때문에 스페셜리스트가 되는 것이 당연했습니다.

그리고 Oracle에서 MySQL로 트랜드가 넘어오면서는 오라클에서 안되던 것들을 MySQL에서 구현해내기 위해 뜯어보고 고쳐보고 개선하는 작업을 많이 하다보니 다른 느낌으로 스페셜리스트가 되는 과정을 밟고 있는 것이죠.

 

이런 부분에 있어서 여전히 DBA를 하는 저는 정말 돌연변이 인지도 모르겠습니다.

제가 현업에서 다뤄본 DB만 해도 Oracle, PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Elastic Search 등이 있고, 호기심이 많고 새로운걸 해보는걸 좋아하다 보니, 하나 끝내놓으면 다른걸 찾습니다. 최근에는 GraphDB에 매우 관심이 많고, 다양한 NoSQL을 사용해보고 익혀가는걸 좋아합니다.

너무 많은걸 하다보니 당연히 하나에 대한 깊이가 비슷한 연차의 DBA분들 보다 깊지 않습니다.

대신 인프라 설계부터 SA업무를 할 수 있고, 네트워크 구성이나 서버단 구성 등 인프라 업무를 할 수 있고, 개발자는 아니지만 개발 스킬을 익히는 것에 열을 올리고 있고, 어디에 어떤 솔루션을 써야하는지 판단하는 업무까지…

그리고 DB에서 어떻게 데이터를 자산화 하여 ETL을 하고, 어떻게 DW나 Lake를 구성하여, 통계와 분석을 하기 위해 필요한 요소를 파악하고, BI 대시보드를 구성하고 통계나 분석 알고리즘을 적용하는 업무를 해보고 싶어서 통계학을 공부하고 있습니다.

데이터 마이닝과 머신러닝, AI 등.. 이렇게 쓰고보니 잡부네요.

 

앞으로는 스페셜리스트가 지고 제너럴리스트가 뜰것이다 이런 이야기가 아닙니다. 여전히 DB쪽은 높은 연차로 갈 수록 스페셜리스트들을 필요로 할 것이고, 반대로 저같은 잡부는 다른 포지션으로 전환이 유리할 것이라고는 생각합니다. 실제로 저는 SA로 전향할 생각이 있었거든요.

자신의 성향이 어떤가를 잘 파악하고, 저 같이 다양하고 새로운걸 하기 좋아하는 사람이라면 제너럴리스트로, 하나만 집요하게 파는 분이라면 스페셜리스트로 가는게 맞지 않나 생각합니다.

 

AWS나 GCP 등이 제공하는 매니지드 서비스들이 너무 쉽고 편하고 잘되어 있습니다. 예전처럼 깊이 파고 들면서 트러블 슈팅을 할 필요도 없습니다. SR 티켓으로 클라우드 밴더사에서 처리를 해주니까요.

몇번의 마우스 클릭만으로도 서비스가 생성되고, 기본적인 구성을 만들 수 있죠. GCP의 데이터플로우나 빅쿼리를 이용해서 DW나 LAKE를 만드는 과정은 너무 쉬워서 무언갈 설치하고 세팅하고 하는데 들이는 시간이 아까워지더군요.

그러다 보니 저는 스페셜리스트가 될 필요성을 잘 못느끼고 있습니다. 차라리 다양한 분야에서 회사가 요구하는 것을 빠르게 결정하고 판을 깔아주는 사람이 되자라고 생각했습니다.

그래서 좀 더 많은 걸 만져고보고 해보자 하는 마음가짐으로 살고 있습니다. 물론 DBA 업무를 하면서 SQL 튜닝이나 모델링 등 다 합니다만, 기왕이면 MongoDB에 데이터를 쌓고, GraphDB로 추천 시스템을 만들고 해보는게 더 재밌는것 같습니다.

 

결론

결국 날 원하는 회사가 있다면 필요한 곳에 능력을 발휘할 수 있는 사람이 되는 것이 좋다고 생각합니다.

다행인 점은 지금 회사의 리더분이 새로운 도전하는 것을 많이 밀어주시는 분이라서 정말 다행이라고 생각합니다. 해보고 싶은거 다해봐라고 말해주시는 분이 있다는게 참 행복하네요.

 

곁다리

최근에 오픈소스 DB를 하는 사람들은 운영 업무 뿐만아니라 엔지니어링 업무를 같이 하고 있으니 DBA가 아니라 DBE가 되어야 하는게 아니냐는 이야기를 들었습니다. 이것도 좋은것 같아요.

DB 엔지니어링 + 운영이 되니 요즘 유행하는 +ops 이런것도 가능할 지도요. DBEops ! 디비업스  ㅋㅋㅋ

 

 

 

 

 

 

You may also like...

1 Response

  1. 타락천사26 댓글:

    DBA 분들이 다들 고민하는
    참고 하기 좋은 글이네요
    좋은 아침 되세요 : – )

답글 남기기

이메일 주소는 공개되지 않습니다.