최근 이직을 준비하면서 DBA로 느낀 것들

 

최근 이직을 준비하면서 DBA로 느낀 것들

그리 거창한 얘기는 아닙니다. 그냥 최근 이직을 준비하면서 여기저기 도전해봤습니다. 결과는 뭐… 노 코멘트 ㅠ

데이터 쪽 포지션 JD를 보고 느낀 점들,  그리고 실제 면접에 들어가서 느낀 것들을 이야기 해보고자 합니다.

 

정말 DBA 뽑는거 맞아?

라는 느낌이 드는 JD가 많습니다. 물론 많은 기업이 인사팀에서 직접 공고를 올리니까 그럴수도 있지만, 요즘 보면 DBA가 예전 DBA가 아니라고 느끼는 경우가 많았습니다.

특히 DBA와 데이터 엔지니어를 구별 못하는 경우가 많은 것 같습니다.

DBA의 경우 운영의 영역이 80% 라면, 데이터 엔지니어는 개발의 영역이 80%입니다.

어떤곳은 DBA에게 데이터 분석도 같이 해주길 바라는 곳도 있습니다.

 

DBA 포지션이 하는 대한 전반적인 업무라 하면 다음과 같습니다.

• ORACLE, PostgreSQL, MySQL, MS-SQL등의 DBMS 스킬
• SQL 튜닝 및 검수 능력
• DB 운영, 백업 정책 수립, 접근 제어 정책 수립
• 성능 관리, 모니터링, 엔진 튜닝
• 신규 프로젝트시 비지니스 로직에 따른 DB 모델링
• 데이터 이관, (직접하는 경우도 있지만 대부분 업체를 부르죠)

네 전반적으로 운영의 영역입니다. MySQL을 사용하는 곳에서는 자체적으로 모니터링 개발도 하고, 자동화나 이런 부분에서 개발 역량을 요구하는 곳도 많습니다.

 

데이터 엔지니어 포지션이 하는 일은 다음과 같습니다.

• 데이터 분석의 기반을 만드는 일 (ETL) – 분석가는 아님
• 하둡 및 NoSQL 등 대규모 분산 저장 시스템에 대한 지식,
• 정규화된 테이블을 분석에 용이한 컬럼 기반으로 반정규화 할 수 있는 능력
• 스트리밍형 데이터 전송 구현을 위한 메시징 시스템 구현 (카프카, Fluentd, Logstash 등)
• 전처리를 위한 데이터프레임 워크에 대한 지식 (MPP 기반의 DB (DW), Presto, Hive, Spark 등)
• 시각화를 위한 데이터 마트 구성
• 데이터 레이크를 구축하고 필요한 데이터만 추출, 처리
• 간단히 BI 툴을 다룰수 있는 정도

 

간략히만 적어봤는데도 요구하는 능력이 완전히 다르죠?

이런 업무를 동시에 한 사람에게 요구하는 것처럼 JD를 작성해 놓은 회사가 종종 보입니다. JD만 보면 도전 자체가 쉽지 않아 보입니다.

 

코딩테스트?!

기존의 오라클 DBA 들에게는 코딩이라는게 개발자 출신이 아니고서야 좀 먼나라 얘기 입니다.

하지만 최근에는 클라우드 환경과 MySQL 같은 오픈소스DB들의 파이가 커져가면서 개발 역량을 요구하는 곳이 많아졌습니다.

• 자체적인 모니터링 개발 – AWS의 CloudWatch의 API등을 가져오거나, 프로메테우스등을 활용하는..
• 자동화 – 반복적인 작업을 자동화 하기 위한 능력인데 가장 많이 요구하는게 Python과 Bash 입니다.

개발자가 아닌 DBA들에게 JD에 코딩테스트를 본다 라고 되어 있는 경우는 정말 많은 생각이 들게 합니다. 왜냐하면 과목을 알려주지 않거든요.

SQL 코딩을 보는지, 파이썬이나 Bash를 보는지, 아니면 직접 직무 능력을 평가하는 서술형 테스트를 보는지 어떤 걸 하는지 알 수가 없어서 더 많은 준비를 해야 합니다.

SQL 코딩을 보는 곳도 있었고, 주관식 문제를 서술하는 곳도 있었고, 개발 언어쪽 (파이썬, 자바 등) 프로그래밍 코테를 보는 곳도 경험해 보았습니다.

코딩테스트를 들어가면 여러가지 언어중에 자신이 문제를 풀 언어를 선택 할 수 있는데, 최근의 개발 트렌드의 주 언어인 Java, Python, C 등이 많고 아직 Go나 SQL을 선택할 수 있는 경우는 못봤습니다.

특히나 JD의 필수 스킬 요건이 DBA에 국한되지 않는 기술이 나열된 경우 진짜 고민이 많이 될겁니다.

이런 개발적인 능력을 보는 것 때문에 기존의 많은 DBA들이 지원을 스킵하는 경우를 많이 봤습니다.

그런데 코딩테스트에 관하여 실제 인사팀이나 실무진들과 이야기를 해보면, 풀이 과정을 보는것이지 문제를 100% 맞히는걸 기대하진 않는다고 합니다. 코테 과정 중에 몇번 테스트를 했고 몇번 썼다 지웠고 기록에 다 남습니다.

결국 앞으로는 계속 개발 능력을 요구 할테고 살아 남으려면 해야지 라는 생각도 듭니다.

파이썬의 경우 입문이 쉽고 많은 분야에서 활용 할 수 있으니 파이썬을 해두시는 것을 추천드립니다.

 

NoSQL DBA?

국내에 NoSQL을 운영하는 DBA를 고용하는 업체는 정말 한 손으로 꼽습니다. NoSQL을 전문적으로 하는 DBA 업무를 하는 곳은 없다고 봐야하고, RDBMS업무와 겸업이 많죠.

대부분의 DBA가 RDBMS로 일을 시작하는 경우가 많으니 RDBMS에 대한 업무는 그렇다고 쳐도, NoSQL은 종류도 너무 많고 모든 NoSQL이 동작하는 아키텍처가 다르고 용도가 다릅니다. 혼자서 다하는 건 정말 어려운 일이죠.

MongoDB, Redis, ElasticSearch, HBASE, Cassandra, Neo4j 등의 오픈소스 뿐만 아니라 클라우드 밴더사에서 제공하는 각종 fork된 NoSQL들까지…

현재 많은 NoSQL 포지션은 클라우드 플랫폼의 상품 개발을 하는 포지션이 많고 이 부분은 DBA와 동떨어져 있습니다.

아직까지도 NoSQL을 운영하면서 DBA가 필요해! 하는 업체가 늘고는 있는데 정작 이게 DBA를 뽑는 JD인가 싶은 경우는 거의 못 본 것 같습니다.

MongoDB 포지션에 따라오는 옵션 같은게 바로 node.js입니다. 이건 백엔드 개발자에요. 물론 MongoDB를 다루는데 Javascript를 할 줄 알면 정말 좋습니다.

그런데 기업마다 요구사항은 기존의 RDBMS DBA + 개발도 좀 아는 수준입니다.

국내에 대규모 NoSQL을 운영해보거나 구축해본 회사가 외국처럼 많지 않기 때문에 인재풀도 한정적입니다.

DBA로 기회도 많지 않을 뿐더러, DBA보단 엔지니어링, 컨설턴트, 개발 쪽이 대부분입니다.

 

폭탄 처리반 또는 보릿자루가 되는 경우

오라클이 위주 였을때는 DB 설계에 있어 전문적인 DA를 통한 컨설팅부터 해서 신중하게 모델링 하는 경우가 많았습니다.

최근 개발자들 위주로 시작하는 스타트업의 경우 그냥 되는데로 모델링해서 시작하는 경우가 많습니다. 후에 물리적 구성이나, 정규화 되지 않은 데이터 모델링 때문에 성능적으로 관리적으로 한계를 느끼고 DBA를 뽑는 경우도 많습니다.

이건 개인적으로 봤을 때는 폭탄이 될 수도 있고 기회도 될 수 있다고 봅니다. 근데 정말 한정적인 기회입니다.

모델링, 물리적 구성 등 DB를 구조적으로 뜯어 고칠수 있는 모든 작업을 해볼 수 있는 기회라고 봅니다. 많은 DBA가 구성된 DB를 운영 관리 하는 반복적인 업무가 많고, 프로젝트 기회가 많지 않기 때문에 많은 걸 해볼 수 있는 기회기는 하죠.

다만 팀원 수에 따라 업무량은 엄청 날테고, 비지니스 로직 분석부터 기존 쌓인 데이터 분석을 하고 리버스 엔지니어링 후 신구 구성안, 이관 방안, 정규화 방안, 이관 후 무결성은 깨지지 않는지, 다른 이슈는 없는지 모두 체크해야하기 때문에 인내심을 가져야 하는 작업이며 실제 이관까지 많은 시간이 소요되기 때문에 회사차원의 전폭적인 지지가 필요하기도 합니다.

물론 면접때는 저런 이유로 DBA를 뽑는다 해놓고 새로운 시스템을 구축하는데 지원을 거의 안해주는 회사도 자주 있기 때문에 주의를 요합니다.

저런 대작업을 해야하는데 DBA 한명만 뽑는 경우도 있고, 실무진은 필요로 하는데 오너 입장에서 오픈소스 DB 그거 개발자들도 다 하던데 DBA 필요해? 개선에 시간도 돈도 많이 드네? 꼭 해야돼? 하면서 뽑아놓고 지원을 많이 안해주는 경우를 많이 봐서 진짜 주의해야 합니다.

 

요즘 IT업계들이 DBA를 뽑는 기준을 보면서 느낀점은 이 정도 입니다.

그래서 정말이제 다른 직무로 전향해야하나 고민도 많이합니다. 근데 경력직을 전향해서 받아주는데는 거의 없죠. 정말 어려운 문제에요.

DBA가 예전 같지 않구나를 많이 느꼈습니다.

여기까지 푸념이었습니다. 후…

DB 종사자 분들 화이팅입니다!!