23. DA, DBA가 되기 위한 자격
데이터 아키텍트와 운영자에게 필요한 기술
데이터가 돈 되는 세상이라 한다. 기업들은 어떻게 해서라도 데이터를 모으려고 안달이다. (카드사가 아닌 삼성이 삼성 페이를 통한 결제정보, 구글의 위치정보, KT지니의 음성정보 등) 사람들이 흘리고 다닌 데이터를 모아 분석해 사람들 행동을 예하려 한다. 데이터는 디스크나 반도체에 저장된 디지털 금광이 되고 있다.
데이터를 다루는 IT 직업으 데이터 아키텍트(DA)와 데이터베이스관리자(DBA)가 있다. 최근 빅데이터 기술이 발전하면서 전통적인 데이터를 다루는 DA와 DBA의 매력은 좀 떨어진 감이 있지만, 정형적인 데이터는 금융, 국가행정 같은 업무 처리를 위해 여전히 중요하다. 매력이 떨어진다고 중요성이 떨어지는 것은 아니다. DB라는 데이터를 관리하는 체계 보다 더 우월한 체계가 나오기 전까지는 여전히 중요하다.
데이터 아키텍트(Data Acrhitect, DA)
데이터아키텍트는 전반적인 데이터 컨설팅을 하는 데이터 전문가라 할 수 있다. 컨설팅이라 함은 업무의 범위나 틀이 명확하게 정해진 것이 아니고, 기업이나 조직에서 요구하는 데이터에 대한 전반적인 문제를 해결한다는 의미다.
기업의 자산으로 데이터는 소중하다. 업무관점에서 데이터를 살펴보자. 고객 기본정보, 고객과 기업이 서로 상호작용하는 거래정보와 같은 원천적으로 발생하는 데이터가 있고, 또 외부에서 유입되는 데이터가 있다. 이러한 원천 데이터를 분석. 가공해서 발생하는 2차 데이터가 있다.
고객의 거래정보와 같은 세부적인 데이터에서부터, 월 매출 정보, 연간 회계 정보와 같은 데이터에 의지해서 기업은 의사결정을 하게 마련이다. 곧 기업이나 조직내부에 있는 데이터를 얼마나 잘 관리하느냐에 따라 기업의 운명이 좌우될 수 있다는 뜻이기도 하다.(약간 비약^^)
데이터만 있다고 해서 유의미한 결과를 도출할 수 없다. 데이터는 서로 연결되고 엮어야 의미를 가진다. 데이터를 모으는데서부터 활용 방법에 이르는 전략이 필요하다. 조직의 데이터 정책, 관리 방안과 같은 전략의 수립이 필요하다.(영어로 '데이터 거버넌스'라 한다.)
｜DA의 직무｜
전사적인 데이터 전략 수립
DA는 앞서 말했듯이 조직의 데이터 정책과 같은 데이터 거버넌스 방안 및 데이터 품질관리 방안 수립과 같은 전사적인 데이터 관리 체계를 수립한다.
데이터 요구사항 분석
전사적 데이터 관리 방안 수립 이외에 실질적으로 DA의 주된 직무는 시스템 구축 시 데이터 요구사항을 분석하는 것이다. 업무 시스템을 구축하기 위해 업무 분석과 데이터 관리에 대한 요구사항을 분석하여 시스템에서 데이터 관리 방안을 설계한다.
데이터 표준화
데이터 표준화는 조직에서 통용되는 데이터를 표준화하는 것이다. 조직 내에서도 동일한 용어를 약간씩 다르게 표현하는 경우가 많다.(예:월잔액, 월말잔액, 월잔고 등) 이런 경우 하나의 표준 용어를 만들어서 혼란을 없애야 한다. 데이터 관리를 제대로 하는 조직은 반드시 데이터 표준 원칙을 수립에 따른 데이터의 표준화와 표준을 지키도록 하는 규정과 절차가 있어야 한다.
데이터 모델링
앞의 글에서 살펴본 데이터 베이스 구축과정에서 살펴본 개념적 설계, 논리적 설계, 물리적 설계 모델링을 통해 ERD를 작성한다. 구체적인 데이터 베이스 설계를 하여 DBA가 물리적으로 데이터 베이스를 만들 수 있도록 한다.
｜DA의 기술적 요건｜
DA는 데이터에 대한 상위 레벨의 전문가다. 따라서 데이터 베이스에 대한 기술적인 지식과 데이터 관리에 대한 논리적 사고력을 기본적으로 갖추어야 한다. 이런 기본 지식과 더불어 반드시 특정 인더스트리의 업무 지식과 경험을 갖추어야 제대로 된 DA역할을 할 수 있다.
데이터 아키텍처에 대한 이해, 데이터 표준화, 데이터 모델링, 데이터 베이스 구축에 대한 전반적인 지식
인더스트리 도메인 지식
전문가로서 DA가 되기 위해서는 반드시 특정 인더스트리에 대한 도메인 지식이 필요하다. 단순히 DA의 기술적인 지식만 가지고 올바른 데이터 아키텍처를 수립할 수 없다. DA의 가장 핵심적인 역량이 담당자를 인터뷰하여 업무를 분석하고 현장에서 담당자에게 어떤 데이터가 중요한가를 알아내는 것이다. 따라서 업무를 잘 알아야 한다. 그런 업무 경험이 쌓이다 보면 특정 도메인에 특화된 데이터 전문가가 될 수 있다.
데이터 베이스 관리자(Data Base Administrator, DBA)
DBA는 DA의 하위 직무를 수행한다.(하위직무는 업무의 순서상 뒤, 아래를 말하는 것으로 열등한 일을 의미하는 것이 아님^^)
물리적 데이터 베이스 생성
DA가 설계한 데이터 베이스를 DBMS에 명령어를 실행하여 물리적으로 만든다. DA가 굳이 DBMS SW에 대해 상관하지 않지만 DBA는 실행되는 DBMS SW를 잘 알아야 한다. (쉽게 말한다면 DA가 손으로 스케치를 해서 내려주면, DBA는 스케치를 컴퓨터로 이미지 파일을 만들어야 한다. 따라서 포토샵이나 일러스터로 작업을 한다면 해당 SW를 다룰 줄 알아야 한다.)
개발자 지원
시스템 개발과정에 DB관련 변경 작업은 수시로 일어난다. 또한 DB에 대한 개발자의 문의도 많다. DBA는 DB의 운영자로서 개발자의 개발 작업을 지원해야 한다. 또 개발자가 필요한 데이터를 테이블에 넣어 줌으로써 개발자의 테스트를 지원하여야 한다.
SQL튜닝
SQL은 데이터 베이스를 실행하는 명령문이다. 시스템 성능에 있어 가장 영향을 미치는 것이 DB에서 데이터를 조작하는 것이다. 특히 관계형 데이터 베이스는 가능하면 테이블을 분리하다 보니 테이블의 수가 늘기 마련이다. 이는 하나의 온전한 데이터를 조회하려면 많은 테이블이 필요하다는 말이다. 테이블이 많아질수록 조회시간이 길어진다. 화면에서 데이터 몇 건 보는데 수초가 걸린다면 문제다.
데이터 베이스 SQL실행문의 속도를 개선하는 것이 SQL튜닝이다. 일반적으로 SQL에 대한 실력은 개발자보다 DA/DBA가 한 수 위다. 개발자들이 무분별하게 만든 SQL문을 검토해서 실행 속도를 높이는 것이 SQL튜닝이다.
｜DBA의 기술적 요건｜
데이터 베이스 모델링 이해
데이터 베이스 모델링의 주체는 DA지만 이를 실행하는 자는 DBA이므로 DB 모델링을 이해할 수 있어야 한다. 또한 DA가 없는 현장이 많은데, 이런 경우 DBA가 DB모델링을 해야 한다.
DBMS 제품에 대한 전문 기술
적어도 하나의 DBMS를 다룰 줄 알아야 한다. DB를 구축하고, 인덱스를 만드는 등 DB를 다룰 수 있는 기술이 있어야 한다.
SQL 및 튜닝 툴
개발자보다 더 차원 높은 SQL에 대한 지식과 SQL튜닝을 지원하는 툴을 다룰 수 있어야 한다.
｜개발 DBA과 운영 DBA｜
일반적인 DBA는 시스템 개발에서 보다 운영 중인 시스템의 DB관리자로서의 역할이 더 많다. 따라서 기업에서 DBA는 대부분 운영 중인 시스템 DB 관리자인 경우가 많다. 프로젝트 규모가 클 경우 개발 DBA를 두지만, 규모가 작은 개발은 개발자 또는 기존 시스템의 운영 DBA가 DB를 설계한다.
DBMS(Data Base Management System)의 종류
DBMS(줄여서 그냥 DB라고도 한다.)는 말 그대로 데이터 베이스를 관리하는 시스템 즉 SW이다. DB는 개발자가 자바로 개발하는 응용 SW가 아니고 워드, 한글과 같이 만들어진 SW이다. 시스템 구축에 있어 개발 인건비 외와 HW 외에 가장 비용이 많이 차지하는 것이 DB이다.
DB에 있어서 가장 중요한 것은 안정성이다. 세상이 두 쪽 나더라도 데이터는 문제가 없어야 한다. 다음으로는 성능이다. 초당 수백 수천 건씩 거래 데이터를 빨리 처리할 수 있는 능력이 있어야 한다. 제대로 된 DBMS라면 이 두 가지가 보장되어야 한다. 그래서 그만큼 DB는 고가의 SW이다. 그리고 대부분 외국산이다.
우리나라가 IT강국이라 하지만 HW 및 중요 SW는 대부분 외국산이다.
반도체만 빼면 아마 거의 외국산이지 않나 싶다.
DBMS의 종류를 알아 둘 필요가 있다. 현장에서 어떤 DBMS가 쓰이고 있는지 알아둘 필요가 있다. DBMS에 따라 기능이 다르고 다루는 방법도 다르다.(같은 워드프로세서라도 워드와 한글이 다르듯) 특히 DBA는 주요 DBMS에 대해 잘 알고 있어야 한다.
｜상(업)용 DBMS｜
상업 제품 DBMS이다. 중요한 시스템은 대부분 상용 DBMS를 사용한다. 아무래도 안전성 및 성능에서 우수하다. 또 문제가 발생한다면 DB제조사의 기술 지원을 받을 수 있다. 운영 DBA 입장에서는 문제가 발생할 경우를 대비해 이러한 기술 지원 체계가 매우 중요하다. 위험을 혼자 감당하기는 힘들다.
상용 DBMS는 시스템 개발 시 SW를 구매해야 하고, 구매 후 시스템 운영 시에는 유지보수 계약을 맺어야 기술지원과 SW업데이터가 가능하다. 일반적으로 유지보수 계약은 구매 금액의 20%~30% 수준으로 매우 높다.
상용 DB의 선두 주자 오라클관계형 DBMS의 대표주자는 오라클이다. DB회사로 출발해서 최근 HW, 타 SW를 인수하여 종합 IT기업이 되었다. DB 하면 오라클, DB표준이 시대가 있었다(아직도 여전함). 성능, 안정성 면에서는 가장 앞선다. 그만큼 비용이 높다. 높은 유지보수 비용으로 최근 탈 오라클 바람이 불고 있다. 그러나 금융과 같은 중요 시스템은 여전히 오라클을 기본 DBMS로 사용한다.
그 외 주요 외산 DBMS로는 DB2(IBM), SQL Server(Microsoft) 등이 있고, 국산으로는 Tibero가 오라클 대체 DB로 최근 각광을 받고 있다.
｜오픈소스 DBMS｜
오픈소스 DB로 가장 많이 사용되는 MySQL오픈소스 SW는 소스 코드를 공개해 누구나 특별한 제한 없이 사용할 수 있는 SW이다. 오픈소스 DBMS는 무료로 사용할 수 있는 DBMS이다. 오라클과 같은 상용 DBMS의 가격, 유지보수 비용이 너무 올라 기업들은 오픈소스 DBMS를 사용하기 시작했다.
안정성, 성능 면에서 아무래도 상용 DB에 비해 불안한 오픈소스 DBMS지만, 대형 시스템에서의 성공적인 구축 사례가 늘어나면서 많은 기업에서 오픈소스 DB로 시스템을 구축하는 사례가 늘고 있다. 최근에는 중요한 시스템에도 도입이 되고 있다.
오픈소스 DB로는 MySQL, PostgreSQL, MariaDB 등이 있다.
개발자 vs DBA
개발자는 프로그램을 개발하는 직무이고 DBA는 DB를 다루는 직업이다. 시스템 개발에 있어 두 직무는 떼려야 뗄 수가 없다. DB를 모르고서는 개발을 할 수 없으므로 개발자라도 DB에 대한 지식이 있어야 하고, 개발자들이 사용하는 DB를 관리하는 입장에서 DBA는 개발에 일정한 부분을 이해해야 한다.
DBA의 숫자는 개발자에 비해 매우 적다. 그러나 개발자로서 적성이 그렇게 맞지 않고, 분석적이고 체계적인 일을 좋아한다면 데이터를 다루는 DBA 직무를 고려해 보는 것도 좋을 것이다.
이들 직무의 특성을 필자 나름대로 정리해 보면,
개발자는 요건의 변화에 따라 코딩이 자주 바뀌나, DB는 한번 정해지면 크게 바뀌는 일이 없다. 따라서 처음부터 체계적인 분석이 중요하고, DB변경의 과정도 체계적으로 진행된다.
개발이 요건을 워드 프로세서에 글로 쓰는 것이라면, DBA는 요건을 정리해서 표로 만드는 일을 체계화 작업이다. 따라서 DB를 만드는 작업은 개발자에 비해 더 규범적이고 체계적인 사고가 필요하다.
개발은 코드가 동작하고 기능하는 것에 중점을 두는 작업이라면, DBA는 움직이지 않는 데이터를 보면서 데이터의 움직임과 의미를 머릿속에 그릴 수 있어야 한다.
개발자는 테스트 결과가 바로 나오지만 DBA는 대량의 데이터 작업이 많아 결과를 보기 위해 오래 참고 기다려야 한다. 또 잘 못되면 다시 처음부터 긴 작업을 해야 하는 경우가 많다.
두 직무 성격의 차이를 말하고 싶은데 뭔가 시원치 않다. 어떤 사람은 데이터를 잘 다룬다. 어떤 데이터가 어디 테이블에 있고, 데이터를 쭉 보면서 어떤 데이터가 문제가 있는지 잘 밝혀낸다. 이런 사람들에게는 DBA가 적성에 맞을 것이다.(제가 현장에 있을 때는 데이터 업무에 여성분들이 많았다는 것이 특징이었음)
｜ DBA로의 진로｜
DBA는 개발자에 비해 자리가 적다. 그러나 최근 빅데이터가 부상되면서 데이터 관련 전문가의 수요가 늘고 있다. 단박에 빅데이터 전문가가 되기 어려우므로 DBA → DA, 빅데이터 전문가로 커리어 패스를 정하는 것도 나쁘지 않다. 데이터를 다루는 일은 기술은 조금씩 변해도 기본 원리는 다르지 않다.
그러면 DBA가 되기 위해 어떻게 접근하면 될까?
개발자로서 시작하여 개발경력을 쌓으면서 데이터에 대한 전문화를 하면서 DBA로 이전하는 방법
: 개발자로서 DBA에 필요한 자격증을 취득하면서 특정 DBMS의 경험을 현장에서 쌓는다.
처음부터 DBA로 목표로 하고 DB관련 전문회사를 두드린다.
: 학부 및 취업 준비 때 DBA관련 자격증을 취득하고 DB전문회사에서 커리어를 시작
와 같은 방법을 생각할 수 있다.
어떤 방법을 쓰던 지간에 IT 개발에 대한 기본 이해를 가지는 것은 중요하다고 본다. 또한 DBA로서 실력을 가지기 위해서 필요한 자격증을 따는 것도 중요하다.
｜ DBA를 준비하기 위한 자격증｜
DBA를 준비하기 위한 자격증은 다양하지만 그중에서 필수라고 생각하는 것들이다. 물론 자격증만큼 현장의 경험이 중요하다. 개발자로서 DBA가 되던, 처음부터 DBA가 되던지 간에 빠른 시간에 현장에서 DB를 다루는 경험을 가지는 것이 무엇보다 중요하다. DB의 특성상 교육시스템이나 샘플로 현장과 같은 대량의 데이터를 접하기는 어렵다.
OCP(Oracle Certified Professional)
오라클에서 주관하는 자격증으로 오라클에 대한 기본 자격증이다. 개발자도 많이 취득하는 자격증으로 실력증명보다 DB에 관한 기본으로 갖추어야 할 성격의 자격증인 것 같다.
참고로 오라클에서 주관하는 자격증의 등급은 OCA < OCP < OCM 순서이다.
SQLP(SQL Professional)
국가 자격증으로 데이터베이스와 데이터 모델링에 대한 지식을 바탕으로 데이터를 조작하고 추출하는 데 있어서 정확하고 최적의 성능을 발휘하는 SQL을 작성할 수 있고, 이를 토대로 SQL을 내포하는 데이터베이스 프로그램이나 응용 소프트웨어의 성능을 최적화하거나, 이러한 성능 최적화를 지원할 수 있는 데이터베이스 개체(뷰, 인덱스 등)의 설계와 구현 등 DBA에 필요한 난도가 있는 자격증이다.
DBA로서 경력이 쌓인 후 데이터 전반을 관리하는 DA로서 역량을 갖추기 위해 DA 자격증을 검토할 수 있을 것이다.
체계적이고 보완된 내용으로 브런치 글과 같은 이름으로 출간을 하게되었습니다. 아래의 링크를 통해 자세한 내용을 확인할 수 있습니다.
교보문고
나에게 맞는 IT 직업 찾기
예스24
나에게 맞는 IT 직업 찾기
알라딘
나에게 맞는 IT 직업 찾기
개발환경 못지않게 DB의 환경도 많이 변했다. DBA라 함은 오라클 하나만 잘 다루어도 예전에는 유능한 DBA였다. 또 DA도 데이터 업무분석, 모델링을 잘하면 되었다. 하지만 오라클 중심이든 DB가 다양해지면서 DBA는 오라클 이외에 MySQL과 오픈소스 DB 뿐만 아니라, 관계형 데이터 DB가 아닌 다른 체계의 DB도 다루어야 하는 환경으로 변했다.
DA도 마찬가지다. 이제 모델링만 하는 DA로 살아남기 힘들다. 빅데이터 분석과 같은 데이터 분석, 데이터 사이언스와 연결되지 않으면 현장에서 가치를 발하기 쉽지 않다.
DA/DBA의 환경이 예전만 하지 못하지만, 기술과 요구사항이 다양해지고 있다는 것은 다른 말로 새로운 기회가 있다는 것이다. 오라클뿐만 아니라 오픈소스 DB와 이기종 DB를 잘 다루는 DBA는 구하기 쉽지 않다. 관계형 DB와 모델링 지식을 갖춘 빅데이터 분석가를 찾기도 쉽지 않다.
기본기와 새롭게 변화하는 기술을 적극 갖춘다면 데이터 관련 직무에서 가치를 만들 수 있는 기회는 더 많이 있을 것이라 생각한다.
