DBA 직업군의 질이 떨어지고 있다.

내가 이러한 글을 쓰는 건 순전히 내 경험에 바탕을 둔 것이다. 나는 현재 SI 분야에서 프리랜서로 일하고 있다. 나의 임무는 TA이다. 인프라 담당이 주요한 업무이긴 하지만 단순하게 인프라를 담당하는 것을 넘어 설계분야까지가 나의 직업적인 업무의 영역이다.

인프라를 담당해서인지 개발자보다도 DBA와 부딪히는 일이 많았다. 별탈이 없었으면 좋았겠지만 문제가 지금도 지속되는 걸보면 내 개인적인 부분이라고 치부하기에는 뭔가 이상했다.

사람이 한번이나 두번정도는 상대방, 그러니까 나의 경우에는 DBA의 개인적인 일탈쯤으로 여길수도 있다. 하지만 프로젝트를 할때마다 DBA와 문제가 생긴다면 이거는 개인적인 일탈이 아니라 사회적인 제도와 같이 구조적인 문제로 봐야 한다.

제목이 너무 자극적인가? 이 구조적인 문제에 대한 결론이 바로 ‘DBA 직업군의 질이 떨어지고 있다’ 다. 사실이다. 그리고 DBA로서 직업을 가시는 사람들 대부분이라고 하고 싶지는 않다. 하지만 그들의 마인드가 과연 DBA로서의 직업윤리 의식이 있느냐하는 생각마져 드는게 사실이다.

인터넷을 검색하다 보면 DA와 DBA의 역할에 대한 글을 심심치 않게 보게 된다. 그리고 이 둘사이에서도 분쟁이 잦은 것을 볼수 있었다. 예를들어 다음과 같은 것이다.

SQL 튜닝은 누가 해야 하나?

이 질문이 DA, DBA 사이에 논쟁으로만 끝나면 좋은데, 이 결론으로 인해서 TA까지 피곤해지는 수가 있다는게 문제다.

사회생활을 하다보면 종종 듣게되는 소리가 있다.

가만이 있다고 해서 너에게 문제가 없다는 건 아니다. 뭔가 내게 부당한게 발생하지 않도록 끊임없이 주위를 살펴야 한다.

하지만 뒤집어서 생각해봐야 한다. 가만이 있는데, 누군가 자꾸 나를 걸고 넘어진다면  그건 그 사람만의 문제가 아니 구조적인 문제라는 걸 말이다.

DBA는 애시당초 TA 였다. IT가 크게 발달되지 않았던 과거에는 TA가 그야말로 인프라를 모두 관리했다. OS 부터해서 Web 서버, WAS 서버, Database 서버까지… 초창기 IT에서는 그져 개발자와 인프라만 구분이 되어 있었을 뿐이다.

하지만 IT산업이 크게 발전하면서 TA 라는 직업군에도 분화가 발생하게 된다. 특히나 Database 의 경우에는 그 중요성으로 인해서 분리 작업이 먼저 이루어진다. 예를들어, Web이나 WAS 는 최악의 상황이라고 하더라도 문제될거는 없다. 하지만 Database 의 경우 최악의 상황일 경우, 데이터가 삭제 된다거나 시스템 저장장치가 고장이 난다거나, 할 경우에는 사업을 접어야 한다.

또, 데이터를 다루는 분야이다보니까 개인정보와 같은 법적인 문제도 생겨났다. 아무나 시스템을 만지게 되면 그만큼 개인정보 보호가 되질 않는다.

그래서 Database 를 전담으로 할 엔지니어가 필요해졌고 TA에 분리해 DBA 가 생겨난다. 결국 DBA도 TA다.

Database 를 잘 운영하기 위한 지식은 아주 방대하다. 아무리 좋은 하드웨어를 가지고 있다고 하더라도 이 시스템을 어떻게 구성하느냐에 따라서 성능을 천차만별이다. 과거도 그렇고 현재도 그렇듯이 전체 애플리케이션의 병목구간을 체크해보면 Database 이 대부분이다.

성능.. 아주 중요한 지표다. TA의 경우에도 시스템을 설계할때에 성능부분을 고려한다. IT라는 것이 적은비용으로 많은 일을 처리하도록 하는게 목표이기 때문에 DBA도 마찬가지다. 문제는 이러한 성능을 보장하기 위한 노력에 어떤것들이 필요할까?

시스템 설계는 어려운 분야다. 뭐든 설계치고 쉬운게 있겠냐만은 시스템을 대상으로 할때에 어떤 것이 과연 좋은 설계인지에 대한 지표가 있을까? 이것도 사람마다, 그리고 어떤 시스템이냐에 따라서 다르다고 하는 원론적인 답변이 대부분일거다. 하지만 나의 오랜경험상.. 그리고 TA로서 일을 해온 경험을 비춰보면 다음과 같다고 할 수 있다.

유연하면서도 성능을 보장할 수 있는 설계

성능을 보장하기 위한 설계로 무엇이 필요할까? 이러한 고민을 끊임없이 하는 사람이 진정으로 IT를 하는 사람이다. 성능을 보장하기 위해서 라는 명제는 개발자, 엔지니어 모두에게 해당되는 명제다.

DBA의 질이 떨어진다고 진단하는 기준이기도 하다. 혹자는 ‘성능보장’ 이 기타 다른 것과 맞지 않는다고 할지도 모른다. 하지만 일을 해보면 알겠지만 한두가지만 가지고는 되질 않는다.

DBA에게 성능을 보장하기 위해서는 어떠한 것들을 알아야 하나?

  1. OS(Storage 포함)
  2. Database System
  3. SQL

하지만 내가 경험한 그리고 수많은 사람들과 이야기한 결과 DBA들은 3번만 하려고 한다. 이렇게 말하면 ‘적어도 2번은 해야지’ 할지도 모른다. 하지만 그것마져도 안할려고 하는 추세에 있다. 왜냐하면 Cloud 시스템이 나왔다는 이유로 2번을 제대로 하려하지 않는다.

성능보장을 위해서는 ‘융합적 사고체계’가 필요하다. 그래서 앞에서 1,2,3 세가지를 필수로 뽑은 것이다. TA의 경우에는 다음과 같다.

  1. OS
  2. WAS, WEB 서버
  3. Cloud Platform
  4. Java programming (한국의 SI 는 대부분 Java다)

예를들어 DBA 가 Database 시스템을 새로이 구축한다고 해보자. 이럴경우에 현장에서 어떤 일이 벌어지는가?

대부분 DBA는 TA 들에게 ‘업무협조’를 요청한다. 자신들은 OS를 전문으로 한 사람들이 아니니 TA에게 업무협조를 하는 것이다.

그리곤, Database 시스템을 설치할때즘 되면 자신들을 도와달라고 한다. OS 명령어에 익숙치않아서 설치할때만 도와달라는 거다. 하지만 도와줄게 있나… 이렇게 되면 DBA는 어디론가 전화를 건다. Database 시스템을 관리해주는 업체에 설치를 의뢰하는 것이다.

Database 설치가 어찌 잘되었다 하면 그때부터 이것저것 일을 하기 시작하는데, 과연 이 사람이 Database 성능을 보장할 수 있는 일을 한 것인가?

외부 업체에 Database 설치를 의뢰할 수는 있다. 하지만 그 의뢰할때에 요구사항들을 세밀히 작성해 건네주는 것을 단 한번도 본적이 없다. Disk I/O 는 어느정도이다, Memory 는 어느정도가 적당하다, Storage 크기는 어느정도 필요하고, 설치 Directory 구조는 이러했으면 좋겠다.. 하는 요구사항들이 너무나 많지만 절대로 그들은 그러한 요구사항을 요청하지 않는다.

대부분이 다 이러했다. 나 같은 경우에는 Database 설치조차도 TA가 해야했다. TA 의 경우에 Database 설치할 줄 모른다고, 설사 안다고 해서 TA 경력에 아무런 도움이 안된다. DBA라는 전문적인 직업을 가진 사람들이 존재하는데 TA가 그러한 경력을 가지고 있어봤자다.

하지만 DBA는 SQL 만 작성하는게 아주 중요한 일이고 그게 전부인냥 했다. SQL 작성이 중요하지 않다는게 아니다. 하지만 Database 시스템을 알려고도 하지 않았다. 어짜피 SQL 을 실행할때에 Index 를 잘 타는지 Join이 잘되고 있는지 정도만 따지면 되었지 Database 시스템이 그러한 SQL 문을 어떻게 처리하는지에는 아무런 관심이 없었다.

대표적인것이 Oracle 을 다뤘던 사람이 MySQL 을 다룰때다. Oracle 을 다뤘다고 해서 자존심을 치켜 세우지만 MySQL 을 다루라고 하면 그런 중소형 DB를 왜 만져야하는지 불만부터 나타낸다. 더 중요한 것은 MySQL 시스템에 대해서 절대로 공부를 하지 않는다. Oracle 을 다룰때부터가 외부 인력들에게 시스템 관리를 위임해온터라 MySQL 시스템에 문제가 발생하면 TA를 찾는다.

Oracle이던 MySQL 이든 OS 설치에서부터 튜닝이 필요하다. Kernel 파라메터 수정은 기본이고 Disk Raid 를 무엇으로 할건지, 백업과 복원을 고려한 디렉토리 구성등등이 전부 설치단계에서 결정된다.

그리고 운영을하게될 경우에는 Database 버전에 맞는 SQL을 작성해야 한다. MySQL 이나 Oracle 이나 독자적인 기능과 함수들을 제공한다. 거기다 Index 를 어떻게 구성하고 어떻게 동작하는지에 대해 모두 다르다.

하지만 대부분의 DBA 들은 시스템을 다뤄본 경험이 없다. 특히나 설치를 해본 사람을 찾기도 힘들지경이다. 최근에 Cloud 가 활성화되면서 OS가 필요없어지는 시대다. 그러다보니 SQL 만 작성할려고 든다.

SQL 를 작성하면 뭐하나… 그게 시스템에서 제대로 동작하는지 모르는데… 아아.. 결과물을 잘 뽑아내면 그게 잘 동작하는거다? 이런 DBA들이 넘쳐난다. MySQL 을 다루면서 InnoDB 에 대한 특징이 뭔지도 모르는 사람들이 SQL문을 작성하고 앉았고… MySQL 버전 패치작업을 TA와 공동으로 추진한다. 왜 TA를 걸고 넘어지나?

DBA도 TA다. Database 를 다룰려면 당연히 시스템을 알아야 한다. 단순하게 Database System 이라고 하면 Oracle, MySQL만을 지칭하는게 아니라 그것을 운영하기 위한 제반사항 전체를 말한다. 하지만 심지여 Oracle, MySQL 과 같은 Database 자체조차도 안 다루려고 한다.

구조적인 문제가 있다고 했다. 이러한 현상이 개개인의 생각만으로 끝나면 문제가 안될거지만 DBA들도 인간이다. 모든 인간은 이기심, 물욕이 있다. 될수 있으면 일을 적게하면서도 월급 받기를 원한다. 많은 일을 하게되면 여러사람과 또 인간관계도 형성해야하고 관리를 해줘야한다.

현재 DBA 라는 직업의 영역이 좁아지고 있다. 이것은 DBA들에게는 더 없이 좋은 일이다. 최근에 Database 설치조차 이제는 DBA가 할일 아니라고 말한다. 문제는 그러한 주장이 현장에서 그대로 반영이 되고 있다는 거다.

SQL을 잘 작성해서 원하는 결과를 뽑아주면 그만인 직업이 DBA 인 것으로 구조가 바뀌고 있다.

4 comments

  1. trying ppas_install

    포그리 설치/사용 방법 구경왔다가,
    좋은 생각이 담긴 글을 읽고 가네요. 좋은 글 감사합니다.
    덕분에 저도 한번 더 “생각”이란걸 해보게 되네요.

    개인적으로는 특정 직군뿐만 아니라 IT 전반적인 특징이 되지 않았나 싶기도 합니다.
    돌아가기만 하면 되는(결과만 나오면 되는) 그런 모습들.
    언제 부턴가(물론 저도 많이 부족하지만)
    why가 없어진거 같아요. 뭐든 이해 없이 실행만 하는 경우가 많은거 같아요~
    (사회적 분위기가 시간적 여유를 주지 않는 것도 문제일 수 있겠네요)

  2. 나그네

    DBA로 6년째 일하고 있습니다.

    결과물만 잘 뽑으면 되는거아니냐라니..

    개발만하다 DBA되신분들을 만나신건지는 몰라도,

    OS 명령어조차 모르고, 물리적, 논리적 설계는 커녕 설치조차 안하고(못하는건지..) 업체를 부르는 DBA라니 신선한 충격이네요.

    튜닝만해도 상황에 따라

    시스템튜닝, DB파라미터 튜닝, 모델링 고려, SQL 튜닝, 어플리케이션 로직 변경 등 고려해야 할 사항이 많은데..

    클라우드의 영향이 더 커지면서 역할이 줄어드는건 사실이나,

    서비스에 대한 문제가 생기면 보통은 DB문제아니야? 하고 찾는 사람들이 많기 때문에

    DB만이 아니더라도 OS, 네트워크, 보안, 미들웨어 여러분야에 걸쳐 두루 알아야 할텐데요.

    아무튼 글쓰신 내용 보고 저런 DBA들도 있구나. 충격이었습니다.

  3. ox8441

    개발 25년쯤하고 요즘은 DBA 프리랜서하고 있습니다.
    말씀처럼 DBA직군의 품질이 떨어질수 있습니다.
    다만, TA와 DBA가 다르듯 DBA와 DA는 다르고, DBA에게 DBMS가 다른것은 다른세상의 이야기가 됩니다. 오라클하다 MySQL을 하면 다른 세상으로 건너가는것입니다.
    물론 세상이 달라도 기본 법칙은 같겠지만, 세부적인것은 천양지차입니다. DBMS버전만 달라도 튜닝 방향성이 달라지는 경우가 많기 때문입니다.

    실제 프로젝트를 진행하면 DB에서의 성능저하가 많이 있습니다. 그런데 DB성능 저하의 60% 이상은 SQL을 비효율적으로 만들었기 때문입니다. 때문에 SQL튜닝에 집중하지요, 만약 DBMS자체를 튜닝하거나 변경하는 경우에 그 DBMS에서 동작하는 모든 SQL과 프로세스에 영향을 주게되고 이것이 어떤 악영향으로 돌아올지 모르게 됩니다. 단연히 상당한 심사숙고따라야 합니다. 이럴바에는 SQL을 튜닝하는것이 안정성, 성능 개선, 대응 시간 단축에 더 유리하게 됩니다.

    저는 SI PM을 하면서 오히려 AA직군에 불만이 있었습니다.
    고객요구사항과 성능에 맞는 아키텍쳐 설계가 미흡합니다. 아키텍쳐가 틀리면 그 위에 있는 어떤 구성요소(WEB, WAS, DB등)도 본연의 성능과 기능을 발휘할수 없습니다.
    실례로 IoT 단말에서 유입된 데이터를 DB에 저장후 조회하여 분석 및 통계를 구조로, 이런 경우 분석/통계를 spark같은 실시간 분석 모듈에 넘겨야하지 DBMS나 SQL을 튜닝한다고 해결되지 않습니다.

    약 30년 가까운 IT업계 종사자로 드리고자하는 말씀은, 나 이외의 직군이나 인원이 미흡해 보인다면, 나도 비흡해 보일수 있다는것입니다.

    두서 없는글 죄송합니다. 감사합니다.

    • admin

      제 글의 요지는,, 튜닝 방향성이 달라서, Oracle 과 MySQL이 달라서 그래서 그것이 뭐가 문제가 되냐하는 겁니다. 정확하게 말하면, 무슨 일을 하던간에 자기가 하는 분야에서 30년동안 같은 것만할 수는 없습니다. 설사 같은것을 다루더라도 요구사항에 따라서 해야하는 일이 달라지고 그것이 경험이 되기도 합니다.

      하고자 하는 의식, 의욕도 안 보인다는 겁니다. Oracle 만 다뤄서 MySQL은 모르겠습니다. 어찌보면 그것이 당연하고 합당한 것일지도 모릅니다. 하지만 한편으로는 DB를 모른다고 평가할 수도 있지요. 그래서 일단 시켜봅니다. 그러면 두 사람으로 나뉘는데, 한분은 안해봐도 자신이 DB를 다뤘던 경험과 Oracle 을 달뤘던 경험을 토대로 MySQL을 매칭시키면서 해나갑니다. 다른 분은 ‘내가 Oracle 로 다른 사람에게 칭찬받으면서 살았는데, DB같지도 않은 MySQL을 다뤄야 하나?’ 그래서 그사람은 ‘저는 Oracle 만 다룬다 했지 MySQL은 다룬다고 한적없다’ 하면서 안하죠.

      이거는 직군, 나이와는 아무 관계도 없는 겁니다. 그냥 꼰대냐 아니냐죠.

      또, 언제부터 DA 가 DBA 가 아니니 그건 TA가 다뤄야한다고 DA가 업무 룰을 정하는 권한을 줬냐는 겁니다. 어째서 DBA는 시스템을 몰라도 된다는것이 당연하게 되고 그래서 TA가 해야하는 걸로 룰을 누가 정한 겁니까? 애시당초에 DBA나 DA라도 시스템을 다뤄보지 않았다면 DA, DBA라 볼수도 없습니다. SQL이 엉망이라서 튜닝을 많이 한다고 하는데, 그 튜닝한 SQL이 DB 시스템에서 어떻게 작동될지 판단도 못하는 사람들이 DA, DBA 라고 할 수 있습니까?

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">