Db엔지니어 현실 - dbenjinieo hyeonsil

DBA 입장에서 바라보는 최근 데이터베이스 직군 이야기

SE3년, Oracle DBA 및 엔지니어 8년, PostgreSQL, MySQL 1년, 현재 MongoDB DBA를 하고 있습니다.

아래 글은 어디까지나 제 개인적인 견해임을 밝힙니다. 누구에게는 공감할 수 있는 내용일수도 있고 누구에게는 공감할 수 없는 이야기 일수도 있습니다.

IT 인력 시장의 현재

IT 산업이 가파르게 성장하면서 IT 기업들이 대기업 수준으로 치고 나가기 시작했고, 그에 상응하는 IT 기술직들에 대한 급여 역시 근래 대폭 상승하게 되었습니다. ‘네카라쿠배’에 추가로 ‘당토’ 라고 불리면서 현재 국내 IT 시장을 선두해 나가는 IT 기업들이 있습니다. 그리고 많은 게임 회사들이 근래들어 앞다투어 자사의 인력을 빼앗기지 않기 위해 개발자들의 연봉을 1000만원 전후로 대폭 상승하겠다는 기사들이 쏟아졌습니다. 많은 개발자들이 소위 잘나간다는 IT기업들, 게임사에 눈을 돌렸고, 기존의 IT 전문이 아닌다른 분야의 대기업들, 그리고 자본이 충분하지 못한 중소기업들은 덩달아 인력난에 빠져 있습니다. 개발자들의 눈은 높아졌고, 급여를 많이 주는데를 찾고 있는데, 대기업들은 직원수도 많은데 기존 직원들과 형평성을 고려해 IT분야만 천만원 가까이 더 올려줄수 있는 상황도 아니고, 기존에 IT를 중시하지 않았던 물류, 유통, 제조쪽의 회사들은 IT 분야만 더 올려주는 것에 어려워 하겠지요. 그리고 돈이 없는 중소기업들은 실력있는 개발자들에 맞춰줄 돈이 부족하니 또 어렵습니다.

개발자들의 눈이 높아진것도 한 몫 합니다. 정말 실력있는 사람들은 돈을 많이 주거나 좋은 회사들로 가게 됩니다. 하지만 근래 언론들이 어디는 얼마를 올려주니 하고 쏟아낸 기사들로 비전공자들도 개발에 뛰어들기 시작했고, 개발자면 누구나 그렇게 받을거란 헛된 기대감을 가지는 것도 적지 않습니다. 연봉이 쎈 IT 회사들의 면접관들의 눈은 굉장히 높기 때문에 학원에서 다룬 프로젝트 가지고 도전하는건 엄청난 경쟁률을 뚫어야 하기도 하고, 실력적으로나 요구사항이 꽤 높아 여러모로 꽤나 어려운 일입니다.

잘나간다는 IT기업들이 인력난이라고 말하는건 즉 자기눈에 차는 수준의 인력이 없다는 것이고, 중소기업들은 자신들이 제시 할 수있는 연봉에 일하려는 인력이 없다는 뜻이되며, 대기업들은 IT기업들에게 고급인력을 빼앗긴 상황에서도 실력이 있어도 대졸이 아니거나, 비슷한 수준에 대기업에서 일 하지않았던 사람들에게 자기네 연봉 테이블 수준으로 맞쳐주긴 꺼려하니 인력난이라고 말하는 거라 보시면 됩니다. 실제 대기업들은 중소기업 출신들의 경력 2년을 제하는 경우가 종종 있습니다.

데이터베이스 분야는?

우선 데이터베이스 분야는 업무 별로 나눌수 있습니다.

• 데이터베이스 엔지니어
• 데이터베이스 관리자 (DBA)
• 데이터베이스 아키텍트 (DA)
• 데이터베이스 튜너

데이터베이스 엔지니어는 여러가지 데이터베이스 중에 자신이 전공한 특정 데이터베이스(예: 오라클, MySQL 등)에 대한 기술지원 업무가 일차적입니다. 설치, 구성, 이관, 백업 구축, 장애지원 등 밴더사나 SI 업체에서 주로 일을 하게 됩니다.

데이터베이스 관리자는 일하는 회사에서 사용하는 데이터베이스에 대한 운영, 관리, 모니터링, 백업 정책 수립, 쿼리 튜닝, 성능 개선 등의 프로젝트를 위주로 하게 되며 실제 운영 업무가 주로 이룹니다.

데이터베이스 아키텍트는 서비스를 하는데 있어 데이터베이스의 효율이나 성능 최대한으로 끌어내기 위해 사전 구축 단계에서부터 스키마 모델링이나 물리적인 서버 모델링 등 전반적인 아키텍처 업무가 주를 이룹니다. 데이터베이스의 아키텍처를 완벽하게 이해하고 있어야 하며 도메인 지식이 풍부해야 합니다.

데이터베이스 튜너는 SQL 튜닝을 하는 인력들을 말하는데, 예전에 오라클이 주를 이뤘을때는 튜너들이 많았지만, 근래에는 DBA들이 튜너의 업무를 같이하기도 하고, 장비나 소프트웨어가 발달함에 따라 전문 튜너들의 필요성이 줄어들게 되었습니다.

그리고 많은 분들이 물어보시는 것중 하나가 데이터 엔지니어도 데이터베이스 분야가 아니냐는 것인데, 기존에 DBA들이 하던 업무랑은 많이 다르기 때문에 데이터베이스 분야에 잘 포함하지 않는 걸로 알고 있습니다.  빅데이터 시스템이나 ETL 등 OLAP 성 데이터 분석 시스템을 구축하고, 파이프라인을 만들고 데이터를 전처리해서 대용량 OLAP 또는 DW 시스템에 저장하는 역할을 합니다. 주 역할이 데이터 전처리 입니다.

DBMS에 따라 크게 RDBMS와 NoSQL로 나뉘어 있고, 거기에서도 Oracle, MySQL(또는 MariaDB), MSSQL, PostgreSQL, MongoDB, 카산드라, 최근에는 클라우드 밴더사에서 제공하는 DBMS서비스 등 세부적인 데이터베이스의 종류로 나눌수 있습니다. IT종사자가 아니거나, 기업 임원들 중에서는 DBA면 다 다룰수 있어야 하는거 아니냐라고 착각하시는 분들도 있는데 두세가지 이상의 데이터베이스의 아키텍처를 이해하고 완벽히 다룰수 있는 사람은 시장에 많지 않습니다.

물론 비슷한 RDBMS 계열의 DB를 다뤄 봤으면 다른 데이터베이스에 적응하고 익히는데 빠를순 있습니다. NoSQL은 기존의 RDBMS와 아키텍처가 전혀 달라서 익히고 숙달되는데는 시간이 필요합니다.

데이터베이스 직군의 트렌드 변화는?

예전에 “데이터베이스를 한다 = Oracle 을 한다” 였습니다. Oracle의 점유율은 독보적이었고, 지금도 안정성이나 중요도 높은 DB들은 Oracle을 많이 사용하기도 합니다. 다만 Oracle의 라이선스가 매우매우 비싸고, 폐쇄된 정책을 가지고 있기 때문에, 근래에는 오픈소스 DB를 많이 사용하기 시작했습니다. 또, 오픈소스 DB들의 성능이나 안정성이 Oracle 못지 않게 올라온 것도 한 몫을 하고 있으며 기업 입장에서는 단가를 줄일 수 있다라는 장점이 가장 크게 다가왔을 것 입니다. 물론 아직도 “돈 많으면 오라클”이라고 농담을 던질 정도로, 오라클이 제공하는 기능들의 강력함은 누구나 인정하는 것이죠. 하지만 IT로 떠버린 카카오나 네이버 같은 기업들에서도 오픈소스 데이터베이스를 적극적으로 활용하면서 세간의 인식이 변했습니다.

어쨌든 기업들은 IT 분야에 들어가는 단가를 줄이기 위해 탈 오라클을 선언하기 시작했고, 국내는 MySQL, 일본이나 유럽은 PostgreSQL을 필두로 RDBMS 시장이 급격히 변화하고 있습니다. 또 RDBMS로 커버하기 힘들거나, 대규모 클러스터링 시스템을 위해 NoSQL을 선택하는 경우도 늘고 있습니다.

기존의 Oracle DBA들은 오라클을 운영 할 줄알면 되었고, SQL를 다루거나 정책적인 부분, 프로젝트등에 많이 시간을 할애 하고, 장애나 기술적인 부분은 SI업체나 밴더사를 통해 기술지원을 받는 경우가 대부분이었습니다. 하지만 오픈소스DB를 사용하는 업체들은 DBA가 개발을 어느정도 할줄 알아야 하고, 직접 모니터링을 개발한다거나, 클라우드를 접목하는 경우가 많기 때문에 클라우드 인프라 환경등에 대한 특성을 알아야 한다거나 하는 엔지니어링 측면이 보다 중요해 졌습니다. 그래서 기존의 ORACLE만 하던 DBA분들이 오픈소스 쪽으로 쉽게 넘어오지 못하는 경우도 많고, 또 Oracle 처럼 강력한 기능들이 없으니 개발을 통해 구현해야하는 부분은 직접 개발을 배우지 않고는 도전하기 힘든 부분이어서 경력이 찬 후에는 상당한 고민거리 중 하나입니다.

그리고 오픈소스 데이터베이스는 특정 데이터베이스 하나만 가지고 사용하는 경우도 있지만, 여러 데이터베이스를 혼합해서 사용하는 경우도 있습니다. 예를 들면 MongoDB의 Full Text Search는 n-gram도 지원하지 않고 한국어도 지원하지 않으니, 엘라스틱 서치를 같이 도입해서 검색엔진으로 사용하기도 합니다. 특히나 Redis의 경우 분야를 가리지 않고 다양한 영역에서 사용됩니다. Key-Value 스토어로 사용되는 경우도 있고, 웹이나 DB 캐시로, 또는 Queue로 사용되는 경우도 있습니다.

하지만 결국, 금융권을 제외하고는 계속 탈 오라클 추세가 이어질 것으로 보이고, 새로 데이터베이스 분야에 도전하는 사람이라면 수많은 오픈소스 DBMS 중에 이것저것 손대는 것 보다는 자신이 특기로 내세울수 있는 DB를 하나 집중적으로 만들고 나서 분야를 넓혀가는 것을 추천드립니다. 우선적으로 오라클을 공부하는 것은 많은 RDBMS 오픈소스들이 오라클의 아키텍처를 따라가고 있으니 RDBMS를 이해하는데 있어 좋은 방법이기도 합니다. 트렌드를 잘 읽고 남들이 하지 않는 것을 해서 유니크한 사람이 될 것인지, 대세를 따라 많이 필요로 하는 분야를 택할 것인지는 잘 고민해보시기 바랍니다.

데이터베이스 업무가 중요한 이유

DBA를 보유한 기업들은 대부분 이미 알고 있습니다. 하지만 DBA가 없이 개발자들로만 시작한 프로젝트들의 경우 사용자가 많아지고 시스템 규모가 커지면서 데이터베이스에 대한 구조적인 문제가 눈에 보이기 시작합니다. 데이터베이스의 이해도 없이 DB를 구축한 경우, 데이터가 없고 사용자가 많지 않은 서비스 초반에는 잘 느끼지 못하는데, 사용자가 늘고 서비스가 커진 이후에 이건 설계부터가 잘못 되었다고 느낀 순간이오면 이미 돌이킬 수 없는 상황일 수도 있습니다. 정말 데이터베이스를 처음부터 재구성하고 이관을 해야하는 경우가 생길 수도 있습니다. 초기 데이터베이스 모델링 없이 서비스 구축에 의한 사용자 증가 후 성능 이슈 발생은 실제로 많은 스타트업들에서 겪는 일입니다. 업계가 워낙 좁으니 한다리만 건너면 그 회사가 어떤 상황인지 대부분 알수 있습니다. 실제 엄청 잘나가는 회사인데 데이터베이스 부분 인력공고가 나서 물어보면, “거기 DB 개판이야 손댈수가 없는 지경이야”, “똥 치우러 가야하는 걸 수도 있어” 라는 대답을 들어본적도 있습니다.

실제로 서비스를 위한 애플리케이션을 설계할 때 데이터베이스 모델링이 계획한 서비스에 맞게 제대로 진행되어야 하는 부분이 매우 중요합니다. 실제로 DBA 없는 업체의 MariaDB에서 한 테이블에 20개가 넘는 컬럼값을 가진 테이블들이 많다거나, ERD 없이 데이터 저장되는 것에 따라 설계 해버린 데이터베이스, MongoDB를 사용하면서 관계형으로’만’ 설계한 데이터베이스 등 잘못된 초기 아키텍처를 많이 봤습니다.

사용하고자하는 DB의 아키텍처 및 특성을 고려하지 않고 DB를 설계해버리면 나중에 처음부터 재구축을 해야하는 경우도 발생하고, DB의 버전이 업그레이드 해야 되는 시점까지 겹치게 되면 애플리케이션이나 다른 부분도 개발을 다시해야하는 경우도 발생합니다. 그러니 장기적으로 보고 데이터베이스 설계부터 단단히 하는 것이 비용적으로 시간적으로 모두 중요한 부분입니다.

데이터베이스’만’ 해서는 안되는 시대

오라클이 DBA들의 주 타겟이었을 때는 데이터베이스’만’ 해도 괜찮았습니다. 다른 IT 직군 보다 높은 연봉, 희소성 등 모든게 좋았죠. 하지만 오픈소스 데이터베이스, 클라우드 환경, MSA 환경으로 서비스 환경 자체가 변화되면서 DBA들의 역할도 변하고 있습니다. 하지만 그때도 데이터베이스’만’ 할줄 아는 사람과 인프라, 즉 네트워크, OS, 스토리지 등을 이해하고 있는 DBA 하고는 차이가 존재 했었습니다. 지금은 새로운 환경에 대해서 아느냐 모르느냐에 따라 극심한 차이가 납니다.

기업이 신규 서비스에 MSA를 도입하기로 했습니다. 심지어 DB도 도커라이즈 하길 원합니다. 그럼 DBA입장에서는 도커가 뭔지 알아야하고, 도커라이즈 했을때 발생할 수 있는 문제점, 도커라이즈 하는 법에 대해 알아야합니다. 개발의 영역에 들어선 겁니다. 또 다른 예로, MySQL을 도입했습니다. 하나의 Master로는 도저히 쓰기 작업을 감당하기 힘듭니다. 샤딩을 도입해야 할 것 같습니다. DB 자체는 스파이더 엔진을 통한 샤드밖에 지원되지 않으니 앞단(Was나 애플리케이션)에서 샤딩 처리를 구현해야 할거 같습니다. 이런 경우로 DBA가 개발에 참여 할 수 밖에 없습니다.

오픈소스 데이터베이스를 도입하고 신규 모니터링을 도입하고자 합니다. 오픈소스로 구축하다보니 상용 모니터링 툴을 도입하기 기업이 꺼려합니다. 모니터링도 개발로 해결하자고 합니다. 그럼 어떤 것을 모니터링 할 것인지 결정하는 것도 DBA 몫으로 돌아옵니다. 개발자들과 협업도 잘 이루어 져야하고, 어떤 툴을 이용할 것인지, 선택한 오픈소스 모니터링툴들이 DB에 부하를 주지는 않는지, 어떤 방식으로 모니터링 하는지 알아야 하죠. 자빅스, 프로메테우스, 그라파나, 플루언트디, 엘라스틱서치, 키바나 등 모니터링에 사용되는 오픈소스들도 굉장히 많습니다.

특히 이런거는 대기업에서 많이 접하는 사례인데, 우선 엔지니어에서 DBA로 전향한 분들이 겪는 어려움이기도 합니다. 내 분야의 일이 아닌것도 많이 시키고, 문서 작성이 많습니다. 엔지니어때는 내 할일만 하면 됐는데, 그 역할로 기업에 입사했는데, 정말 이것 저것 시킵니다. 그런 부분이 싫어서 퇴사하는 사람도 봤습니다. 그게 대기업이구요. 그 대기업에 오라클 DBA로 입사 했습니다. 단가를 낮추기 위해 신규 서비스는 MySQL로 도입한다고 합니다. 그럼 그 몫은 DBA에게 갑니다. MySQL 공부 해야죠. AWS에 올린답니다. RDS를 사용한다고 합니다. 그럼 RDS에 대해 알아야 할테고, 오로라랑 비교도 해봐야 할테고, EC2에 올려서 설치하는것도 고민을 해야 할테구요. 그러기 위해서는 AWS가 뭔지도 조금은 알아야 하겠죠.

다른 분야를 어느정도 알아두게 되면, 물리적인 아키텍처를 그리거나 트러블 슈팅 할 때도 좋습니다. 적어도 DB 이외의 것을 몰라서 처리를 못하는 상황을 겪는거 보단 내 분야가 아니더라도 빠르게 원인 파악을 할 수 있는 편이 회사로부터 더 자신의 가치를 높이는 일이겠죠. 나중에가면 직급이 오르고 CTO 같은거 할 수도 있잖아요.

어디까지나 위의 내용들은 제 개인적인 견해일 뿐입니다.

하지만 자신의 위치를 정확히 알고, 너무나 빨리 변해가는 IT 기술의 흐름에 맞게 자신의 능력을 키우는 것도 중요한 일이하고 생각합니다. 많은 개발자들이 충원된 만큼 시간이 지나면 DBA를 충당하려는 기업들도 많아질 겁니다.

데이터베이스를 다루는 직군은 여전히 매력적이며 다양한 분야로 업그레이드 할 수 있는 직군이라 저는 아직은 좋다고 생각합니다.

Post Views: 7,256