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에게 성능을 보장하기 위해서는 어떠한 것들을 알아야 하나?
- OS(Storage 포함)
- Database System
- SQL
하지만 내가 경험한 그리고 수많은 사람들과 이야기한 결과 DBA들은 3번만 하려고 한다. 이렇게 말하면 ‘적어도 2번은 해야지’ 할지도 모른다. 하지만 그것마져도 안할려고 하는 추세에 있다. 왜냐하면 Cloud 시스템이 나왔다는 이유로 2번을 제대로 하려하지 않는다.
성능보장을 위해서는 ‘융합적 사고체계’가 필요하다. 그래서 앞에서 1,2,3 세가지를 필수로 뽑은 것이다. TA의 경우에는 다음과 같다.
- OS
- WAS, WEB 서버
- Cloud Platform
- 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 인 것으로 구조가 바뀌고 있다.
포그리 설치/사용 방법 구경왔다가,
좋은 생각이 담긴 글을 읽고 가네요. 좋은 글 감사합니다.
덕분에 저도 한번 더 “생각”이란걸 해보게 되네요.
개인적으로는 특정 직군뿐만 아니라 IT 전반적인 특징이 되지 않았나 싶기도 합니다.
돌아가기만 하면 되는(결과만 나오면 되는) 그런 모습들.
언제 부턴가(물론 저도 많이 부족하지만)
why가 없어진거 같아요. 뭐든 이해 없이 실행만 하는 경우가 많은거 같아요~
(사회적 분위기가 시간적 여유를 주지 않는 것도 문제일 수 있겠네요)
DBA로 6년째 일하고 있습니다.
결과물만 잘 뽑으면 되는거아니냐라니..
개발만하다 DBA되신분들을 만나신건지는 몰라도,
OS 명령어조차 모르고, 물리적, 논리적 설계는 커녕 설치조차 안하고(못하는건지..) 업체를 부르는 DBA라니 신선한 충격이네요.
튜닝만해도 상황에 따라
시스템튜닝, DB파라미터 튜닝, 모델링 고려, SQL 튜닝, 어플리케이션 로직 변경 등 고려해야 할 사항이 많은데..
클라우드의 영향이 더 커지면서 역할이 줄어드는건 사실이나,
서비스에 대한 문제가 생기면 보통은 DB문제아니야? 하고 찾는 사람들이 많기 때문에
DB만이 아니더라도 OS, 네트워크, 보안, 미들웨어 여러분야에 걸쳐 두루 알아야 할텐데요.
아무튼 글쓰신 내용 보고 저런 DBA들도 있구나. 충격이었습니다.
개발 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업계 종사자로 드리고자하는 말씀은, 나 이외의 직군이나 인원이 미흡해 보인다면, 나도 비흡해 보일수 있다는것입니다.
두서 없는글 죄송합니다. 감사합니다.
제 글의 요지는,, 튜닝 방향성이 달라서, 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 라고 할 수 있습니까?
말씀하신것 처럼 Oracle 기준으로 비교해서 어찌저끼 할 수는 있겠지만
DBMS 는 제품별로 특성이 굉장히 심하게 차이가 나기 때문에 책임소지가 있는 발언은 쉽게 할 수 없습니다.
SQL 만을 봤을때는 ANSI 표준만 지키면 동작이야 하지만, 내부 동작 메커니즘이나 특별한 기능등은
DBMS 별로 완전히 다르기 때문에 해당 경력이 없으면 DBA가 사이드 이펙트를 예측할 수 없다는 문제가 있죠.
한마디로 옆에서 보기에는 아쉽고 이해가 안되지만, 어떤 일이든 그럴만한 이유가 있다고 생각합니다.
말하는데 모순이 있게 됩니다. 그러니 DBA가 그것을 할 경우에 사이드 이펙트가 커진다. 그러니 TA가 해야한다고 우기는 상황이라는 겁니다. TA는 MySQL, Oracle을 다 해봐서 설치, 유지보수를 해야하는줄 아십니까?
문제는 DBMS 의 제품별 특성이 굉장히 심해서 책임소지가 있어 쉽지 않다 인데, 다른 분야는 다른줄 아시나요? Oracle 을 다뤘다면 적어도 MySQL 을 모른다 한들 다른 직업군을 가진 사람보다는 출발점에 이미 앞서 있는 겁니다. 문제는 그것을 모르고 사이드 이펙트가 크니 ‘난 못해’ 하는 인간과.. 그래도 MySQL 은 디비니까 그래도 파보자, DBMS 이 다뤄본 그래서 접근방법을 알고 있는 경험을 살려서 남들 보다는 어떻게 해야할지를 어느정도 쉽게 파악할 능력이되니 해보자 하는 인간으로 나뉜다는 겁니다.
DBMS 만 특성을 타는게 아니라 인간사 모두가 다 그만한 특성이 다 있는데도 적어도 자신이 하는 분야의 한 카테고리라면 연구라도 할려는 노력이 있어야 하는데, ‘아~ 이거 손되면 좆된다. 그러니 아예하질 말아야지’ 하면서 DBA 가 DBMS 시스템을 안 만지는것이 정당하다고 주장하시는 모양이네요.
그게 능력없는 겁니다.
흠.. 이런 경우는 어떨까요.. db를 움직이는 시스템이니.. dba가 서버 ap, 보안 솔루션 모두 관리해야한다..
.. 실제로 있겠냐라고 생각하시는 분들이 있겠지만.. 실제로 있었던 일이었습니다 ^^.. 각 분야의 전문가를 모아놓고 서로 떠밀기식은 좀 아니라는 생각이 많이 들었습니다. ^^
지나가다 본 관련 직무의 엔지니어가 보기에는 SI 프로젝트의 저급화가 아닐까 싶습니다.
DB의 문제가 아니라 전체적으로 비슷할거라고 봅니다.
(근데 DBA 얘기에 왜 SQL 작성이 나오는지는 이해가 안가네요. 그건 확실히 개발자의 영역인데….)
그리고 원하는 결과에 비해 PAY 나 투입인력의 문제도 있을거구요.
이제 대가없는 열정을 갈아넣는건 아무도 안하니까요.
SQL 작성이 개발자의 영역이라구요? 놀랍군요.
개발자 영역이 맞습니다. 글을 읽어보니 지금까지 DBA로 둔갑한 개발자 또는 DBA로 둔갑한 튜너와 일을 많이 하신것 같네요. 어딜가나 저런 사람들이 꼭 있지요. 그 조직의 문제 같네요.
개발자의 영역이 아니라 DBA, DA 영역 입니다. Database 에서 실행되는 쿼리에 모든 것은 DBA, DA가 책임지는게 맞는 겁니다.
작성은 개발자영역 튜닝은 DBA 다만 다이나믹쿼리로 만드는 게 당연한데
대충 function로 다 따려박아놓고 성능안나온다고 DBA 한테 던지면
그개발자 패죽이고 싶음ㅋㅋ
DB가 문제가 생겨서 봤더니 SQL 쿼리에 문제가 있었다는게 나왔을때에 DBA가 “이거는 개발자가 짠거다” 라고 책임회피하면 그 DBA 패죽이고 싶다는건 아시는지. 대충 function 으로 다 때려박았다고 타박하기전에 이래저래 차라고 가이드라고 하라고 DBA, DA가 존재하는 겁니다. 그걸 다 할줄 알면 DBA가 필요 없겠죠.
거기다 Database System이 문제가 생기면 TA도 함께 봐야한다고 우길때 한대 쥐어박고 싶은것도 알고 계시는게 좋을 겁니다.
개인적으로 DBA랑 싸운걸 이렇게 말씀하시다니… 그냥 같이 일하셨던 DBA에게 쌓인 악감정 푸는 글이네요.
유능한 DBA도 많고 유능한 TA도 많고 같이 잘 일하는 곳이 더 많이 있습니다. 본인일이나 잘하세요
개인적으로 싸운것치고는 한 사업장에 있는 12명의 DBA 중에 10명이 저런식의 사고방식을 가지고 있다면, 거기다 그 10명이 15년차 이상의 사람들이였다면 문제가 없다고 볼수 있다고 보십니까?
그리고 악감정으로 치부하고 싶으신 모양이네요. 이런 댓글을 다시는분은 그렇게 유능한 사람입니까?
유능한 DBA와 유능한 TA는 별로 없습니다. 오히려 희소성이 있기 때문에 유능하다고 하는 거겠죠. 대부분의 사람들은 그렇게 유능하지도 않고 그져 반복적인 일에 적어 그것이 전부인냥 떠드는 사람들이 더 많다는 건 모르는 모양이네요.
너무 비판적인 사고를 가지고 계시는 듯 보입니다.
다른 사람이 보기에는 개소리네 님처럼 보이네요.
글쓴이와 싸우자는 것이 아니라 질이 떨어지는 무능한 TA를 상대하는 반대 입장도 생각해보시죠
무능함이라도 있으면 다행이지만,
DBA가 해야할 일을 시스템이라는 이유만으로 TA가 떠넘기며 자신은 오로지 SQL 만 하겠다고 우기는 사람보다야 무능함이 더 나을 수도 있다는 것은 생각 안해보신 모양이네요.
무능은 할수 있지요. 적어도 자신이 해야하는 일에 대해서 무능하다는 비판이라도 들을 수 있으니..
그런데, DBA에게 데이터베이스 시스템도 모르는 무능한사람이라고 한다면 ‘내가 왜 데이터베이스 시스템을 알아야 하나?” 나는 Oracle만 다뤄봐서 MySQL 시스템은 모른다,
DBA가 작업할때는 TA가 지원, 백업 해줘야한다는 개소리는 짓거리는 놈들에게 무능한 TA라는 비판을 받아야 할 입장은 아니지 않습니까?
업무 시스템을 설계/적용 그리고 기구축된 시스템을 분석하고 튜닝하는것이 참된 DBA입니다.
가상화/클라우드 확산속도를 보면 가면갈수록 SE 레벨의 DBA는 이제 불필요할겁니다.
AWS 의 DBA 문서는 보시고 이런 댓글 다시는지?
본인이 같이 일하는 DBA 들이 저렇다고 해서 너무 일반화 하시는건 아닌지… 회사 규모에따라 다르겠습니다만 보통 저희 회사 DBA들만해도 OS, 보안, 미들웨어까지 설치부터 시작해서 운영, Server 성능 최적화, SQL 튜닝, 시스템 개선 프로젝트에 함께 참여해서 조언하는 등 다양한 분야를 두루 알고 계시던데요.. 아시겠지만 일반적으로 시스템이 안된다, 느리다 하면 바로 DB 쪽 문제라고 생각해서 그쪽부터 찾기 마련이기 때문에 오히려 개발 소스까지 분석도 할 줄 알더라구요. 뭐 같은 IT분야에서도 저렇게 편가르기 하고싶으시면 하시는거지만 저런식으로 일반화해서 비판하는건 본인얼굴에 먹칠하는거밖에 안되는듯…..
글쓴분도 일반화를 하고 있네요… 내가 있는 곳에서는 이런분들도 있다. 그러면 그런분들이 모두 일반적으로 있는것이냐?? 에 대해서 답할 수 있어요?
내가 있는곳에 DBA는 이렇게 일하니까 원래 모든 DBA는 이런 사람들이라고 정의할 있냐구요?
글쎄님처럼 잘하는 DBA, DA도 많습니다. 적어도 저도 DBA나 DA 정도의 경력을 가지고 이런 글 쓰는 겁니다. 착각하시는게 TA가 감히 DBA을 비판해??
이런 생각 밖에 안들죠?? 꼴랑 여기에 적어놓은 게시물들이 DBA관련 내용이 없다고해서 제가 DBA가 아닐거라고 어떻게 확십니까?
대부분 제가 만났던 DBA들 중에 역량이 안되는 사람들도 있었는데, 그런 사람들 자신들이 역량이 안된다는걸 자각하거 노력하는 모습이라도 보이죠..
근데, 웃긴건 15년차나 됐다는 DA, DBA들이 나이도 먹었겠다.. 경력도 있겠다…. 한다는 소리가 ‘이나이에 이경력에 내가 시스템까지 만지랴??’ 이러고 있다는 겁니다.
사회생활이 커뮤니케이션 잘하고 인간관계 잘 맺어야 한다는걸 역이용해서 그걸 말빨로 해치울려는 쓰레기같은 놈들이 있어요. 당연히 어딜가나 잇습니다.
그러면 DBA 이 시스템을 만지기싫고 말빨로 어케해볼려고 한다면, 그걸 TA에게 와서 말하지 말아야죠. 다른 DBA나 DA에게 말을 해서 업무를 넘기던가…
근데,, 요즘 현장에서 추세가.. 시스템=TA꺼 라는 인식이 아주 공고히 넓어지고 있다는데 있습니다. Database 시스템을 TA가 관리하라고?? 그러면 니들은 뭐할건데??
ETL과 같은 여러 솔루션 다룬다… 그리고 쿼리도 짠다.. 그래서 제일 중요한 Database 시스템 관리는 TA가 해야한다? Replication 체크나 설정도 TA가 하라???
글쎄님이 있는 곳에 그런분들도 있겠죠.. 제 주변에도 그런 능력자들 많습니다. 하지만 그렇지 못한 인간들이 더 많아요. 적어도 직업적인 자기 책임영역은 다른 분야 사람에게
넘기는 안되는 겁니다. 더 웃긴건 AWS RDS 나왔다고 좋아라 하는 DBA들 아주 많죠. 그래서 요즘은 Parameter Group 관리도 이제는 AWS 엔지니어가 해야한다고 광광대는 사람들이 DBA 들이예요.
질적하락 절대적으로 있습니다. DBA, DA 분야에서는.
DA가 시스템을 왜 만지냐? ㅋㅋㅋㅋ
건축 설계하는 사람이 시멘 공그리 치는 거 뵜나?
분야가 완전히 다른데 지 기준의 색안경을 끼고 판단하네.
그리고 dba가 os 커널 최적화를 왜 하냐? 그
사람 영역도 아닌데. 그러는 너는 리눅스 위에서 dbms가 어땋게 돌아가는지 dbms 커널은 연구하냐?
상부단에서 설계를 개떡 같이 했거나
쿼리를 발로 짜서 cpu를 많이 쓰는데 그런 상부 구조의 문제에 대해 고민해봤냐?
건축 설계하는 사람이 시멘 공그리가 뭔지도 모른다고 생각하나?
거기다,, 요새는 건축 설계하는 사람들도 현장에 자주와.. 설계대로 잘 만들어지고 있나~~ 봐야지..
DA 가 시스템을 왜 만지냐고? ㅋㅋㅋㅋ SQL Developer 주제에… DA 깜도 아닌게.. 다 티나지…
DBA 가 OS 최적화르 왜햐나고?? SQL Developer 니까 왜 하냐고 말하지.. 병신아…
인덱스 아무리 걸어봐라?? 메모리 세팅 개차반이고 I/O 분산되도록 셋업 안되어 있으면 그게 잘 돌것냐?
오라클 25년 했다 그러는데, 니 오라클 파라메터 값도 모르지?
하드웨어 스펙 변경되면 외부 업체에 전화하지?
그게 뭔 전문가야? ㅋㅋㅋㅋㅋㅋㅋㅋ
세상에 정신병자 참 많아요.. 오래 일했다고 나 전문가요~~ 자가발전도 정도것해야지…
여러사람 앞에서 망신 안당한걸 다행이라고 여겨라… 요새 DBA 들 없어.. 다 SQL Developer 지..
너같은 인간이 DBA 전문가라고 답글 다는게, 전문가가 없다는 증거다. ㅋㅋㅋㅋㅋㅋㅋ
모든 댓글들을 그렇게 비비꼬면서 비판적으로 다 받아치는 거보니, 꼰대 TA이신가 봅니다.
역량이 안되고 배타적이며 말로만 일하려는 DBA, TA 다 같이 일해봤습니다만,
지나면 다 뭐… 아무것도 아니던데…
이렇게 인터넷에 주관적인 감정 글 남기고,
방문자들 댓글에 다 부정적인 대댓글 단 것을 부끄러워하는 날이 오기를…
“모든 댓글들을 그렇게 비비꼬면서 비판적으로 다 받아치는 거보니, 꼰대 TA이신가 봅니다”
이렇게 인터넷에 주관적인 감정 글 남기고, 남을 꼰대네 비비꼬였네하면서 남을 함부로 규정하시면서 ‘비판’ 이라고 ‘부끄러워해라’ 라고 하는 것도 우습지 않습니까?
저도 역량안되고 되는 사람 이래저래 다 겪어보고 지나면 다 뭐… 이러기도 합니다만은,,, 적어도 DBA 건 TA건 자기할을 남에게 미루는 짐승만도 못한짓은 안합니다.
요즘의 DBA들은 시스템자만 들어가면 ‘그건 우리가 할일이 아니다’ 미루거나 하는것을 비판한게 감정적이고 비비꼬였다고 보는 시각으로 주변사람들과 어울리시는 모양인데,
인간관계를 그렇게 엮어가는건 부끄럽지 않은 모양이네요.
나는 22년차 IT
개발로 시작해 서버관리 디비관리 등등 정규10년하고 10년넘게 프리만 하는 오라클 DBA.
물론 mysql 그외 디비들 dw나 로그서버용으로 만짐.
프리하면서 난 저런 dba는 못보았음. 다들 유닉스, 리눅스 명령 다 알고 설치 다함.
다만 대형망 stg나 운영서버시는 벤더가 와서 반드시 설치해야 함. 플젝 롤이므로..
요즘 dba는 관리만함. 롤 다르면 안 할려고 함.
돈 더주면 dba + 쿼리튜닝 다함. 돈더주면 dba+ 쿼리튜닝 + da (보조) 다함.
22년차면 정말 오랜세월인데, 요즘에는 안그런다는 겁니다.
벤더가 와서 설치를 해야하면 적어도 DA, DBA 들이 어떤 요구사항.. 그러니까 하다못해 메모리 용량, 파티션 크기, 혹은 레이드는 어떤게 필요하다정도는 벤더사에게 전달해서 원하는 시스템이 잘 나오도록해야하는데 그런거 없이 그냥 텅키로 ‘내 알바 아님’ 만 시전한다는 것도 문제라는 겁니다. 플젝 롤이 그렇다… 설치, 운영은 벤더사가 하니까 문제 생기면 전화거는게 내가 할일이다… 이렇게 경력쌓은 사람들이 이제는 ‘시스템’자만 나오면 TA가 해야하는일로 몰아가는 요즘 트렌드라는 겁니다. 거기에 AWS RDS 가 나오면서 ‘오예~ 이제는 시스템따위는 안해되는 거다’ 로 아주 자리를 잡을려는 태세에 있다죠.
저는 관리자님의 의견에 매우 동의합니다. 저도 이런 문제의 원인을 자본주의의 병폐, 직업의식 결여 및 한국 IT 산업의 문화적/구조적인 문제로 보고 있습니다. 모르는것에 대한 부끄러움을 느끼는것을 커녕 마치 모르는것이 자신에게 피해로 돌아올까봐 사실과는 다른것들로 핑계를 구구절절 대는 상황들을 너무나도 많이 목격해왔습니다. 알고보면 지식이라는 종이한장 차이인데 사고방식의 문제는 단순한 한 개인의 문제가 아니라고 생각합니다. 오히려 올바른 사고 방식을 가진 사람을 바보로 만드는 경우도 비일비재합니다.
db vender 엔지니어 입니다.
대부분의 dba 는 sql operator/tunner, vender contact point 입니다.
OS 를 직접적으로 보지 않습니다.
이미 밥그릇 관점으로 나눠져 있습니다.
밥그릇 관점에서 나눈거는 db vender 엔지니어만 그런거겠죠.
sql 튜닝을 하신다면 os에 파라메터 값은 안 보는 모양이네요. 데이터베이스가 요구하는 OS 의 튜닝 포인트는 안중에도 없는 모양이네요.
밥그릇은 대부분의 고객사의 dba 상태를 말한 것입니다.
“이미 고객사 dba 는 OS를 직접으로 보지 않도록 밥그릇이 정해져 있다” 라는 말씀이신데,
그 밥그릇 누가 정했는데요?
여기 누가 정했냐하는게 문제가 되는 것이 고객사 dba 가 OS를 안보도록 밥그릇이 정해놨으니 그건 이제 시스템 다루는 사람이 해야한다 라는 밥그릇이 정해진다고 보시나요?
이런 질문에, “내가 언제 그런말 했습니까..” 그냥 고객사 dba의 밥그릇이 그렇다는 거고,, 나머지 밥그릇은 내 알마 아니지요에 말씀 하실라고 하는건 아니지요? 설마요.. 그렇다면 글의 요지도 파악 못한건데.. ㅎㅎ
우리 밥그릇은 이만큼까지.. 난 몰라… 적어도 이렇게 하면 감사라도 하지.. 그 고객사 dba 의 밥그릇 새끼들이 우리 밥그릇은 여기까지고 나머진 저기~ 시스템 다루는사람이 해야 합니다 떠들고 다니는게 문제라는 겁니다.
밥그릇 챙겼으면 닥치고 있던가.. 이래저래 재네들 밥그릇에 이것도 가지고 가야한다고 떠들어대는놈들이 dba 라는 겁니다.
거기다.. SQL 튜닝?? OS 의 메모리 파라미터, 데이터베이스의 메모리 영역이 어떻게 되고 뭘 필요로하는지 대가리에 들어있지도 않은 상태에서 SQL 튜닝 해봤자 될리가요. 30만건 데이터 조회하는데 9분 걸리고 앉았고 좀 알아보라고 했더니 인덱스 잘타고 있고 데이터가 1억건이 넘어가서 오래걸린다고 답변하는 놈도 있어는데 튜닝? 이건 이거고 저건 저거니 내 영역만 튜닝? DB가 그렇게 만만한가. SQL 을 실행하면 어떤 메모리를 많이 필요로하는지도 모른채 튜닝? 그건 난 모른다… 그냥 튜닝?
TA 존나 위로 보는 글에 dba 1인 웃고갑니다 ㅋㅋ
dba뿐 아니라 업계전반적으로 그런것같습니다
한국 IT 산업 전체적으로 후려치기 단가로 인해 질이 떨어진다고 봅니다. 못하면 100원주는데 잘해도 110원밖에 안주면 누가 노력 하고 싶을까 생각드네요. 잘했을때 500원주면 다들 열심히 하겠죠.
ORACLE DBA에게 애초에 MYSQL 도 해달라고하는거자체가 웃기네요.
처음부터 뽑을때 둘다되는사람으로뽑으면 되는거고요 저런얘기는 논할가치도없습니다.
현장상황에따라 MYSQL도 할수있지않냐? 책임질 자신이 없는 상태에서 책임지려 하는 것이 더 무책임한겁니다. ORALE DBA, MYSQL DBA, ORACLE+MYSQL DBA 세가지유형이있고 ORACLE+MYSQL DBA 는 상대적으로 한분야만 파온DBA보다 깊이에서 차이가납니다.
얄팍한 본인경험을 가지고 DBA영역을 굉장히 우습게보고계시네요.
얼마나 작은시스템만 다루어왔는지 대충 보입니다. 일단는 프로젝트기간만 2년이상하는 대규모 프로젝트만 참여중인 DBA입니다. 작은시스템은요 프로젝트나가보면 한명이 AA, TA, SA 겸하는경우가 많습니다. 이런쪽위주로하신분들이랑 대화해보면 가관이더군요.. ORACLE DBA뽑아놓고 어쩌피 같은디비인데 금방하지않겠냐는식으로말합니다.
그러면서 고객이원하면 MYSQL PPAS ALTIBASE TIBERO 등을 필요시 디비추가해나갑니다.
제경험을 토대로말씀드리면.. 경우 ORACLE은 S등급이상 시스템에서만쓰고 ORACLE DBA 정,부로 최소 두명이상 붙습니다. 이기종DB는 그냥 하나로묶어서 한명이 관리합니다. 크리티컬하지않거든요..
4개이상되는 멀티노드 RAC에 80테라가넘는 스토리지 하루에 500기가이상씩늘어나는 데이타.. 템프만 6테라씁니다.
ㅋㅋ 싱글DB만 소소하게 여러디비 잡다하게 만지는 사람이 대단해보이셨다면.. 더이상 할말이없네요.
마에스터급 DBA 만다면 말도 제대로 못 하실거 같은데요. ㅡㅡ
그리고 SQL언급하셨는데요.. 진자 코탁지만한곳에나 DBA가 SQL씁니다.
DBA는 SQL검토 튜닝여부판단 튜닝가이드제공하는역활입니다. SQL튜닝만하는게아니라 파라미터튜닝으로 전역리소스를 조절하는 아키텍트의 깊이있는 이해도가있어야만 건들수있는 분야입니다..
이부분은 말씀하신 여러디비종류를 다루신분들은 많이취약한부분이죠 이부분을 못건드니 SQL에 집착하는거고요.
특히.. 대용량운영경험이없으신 프로젝트DBA들에게서 많이나타나는부분입니다.. 프로젝트DBA들은 보통 개발자에서 DBA전향하기때문에 다양한DB를 다루어보았고 SQL이 더익숙하고 더잘하십니다.
다양한디비종류를 파온사람은. 상대적으로 깊이가 덜어집니다. 어쩌피 사람이 투자하는시간은 한정되어있고 그것을 어디에 쏟아붇냐에따라 달라집니다.
각자 추구하는스타일과 영역이다릅니다. 편견을 버리고 DB쪽공부를 더해보시면 다르게보이실겁니다.
정리해드리면 고용을잘못한겁니다 고용자잘못입니다.
답답하네요. 참.
깊이를 말씀하시는데, Oracle 은 S등급 이상 시스템에서만 쓰고 정,부로 나뉘어서 운영한다는데서 님의 깊이가 얼마나 얕은지를 알고도 남음 입니다.
Oracle 을 쓰던 MySQL 을 쓰던 기본적인 데이터베이스 기본이론은 모두 동일 합니다. 물론 Oracle 만 하다가 갑자기 MySQL 을 하라고 하면 당연히
안되고 힘들겠지만, 데이터베이스는 다 똑같은 데이터베이스 이론을 기반으로 한다는걸 모르시는지…
MySQL 을 쓰던 PostgreSQL 을 쓰던 Oracle 을 쓰던 제대로 이론과 경력을 갖추 있다면 MySQL, PostgreSQL 을 가벼운 디비여서
인력 투입도 제대로 안갖추고 한다고 말하진 않는데 그렇게 말씀하시는 걸보니 확실히 DBA 의 질적 하락을 님께서 잘 보여주시는 거라 생각 되네요.
DBA 든 DB 는 메인 임무는 비지니스에 필요한 데이터를 안전하게 효율적으로 보관하는 것이고 경우에 따라서 재빠르게 조회도 가능해야함은 물론입니다.
어떤 DB를 쓰던간에 그러한 자세는 필요한데 Oracle 은 S급이니 정부로 나뉘어 인력 투입을 하고 MySQL 은 별거 없으니 대충 인력투입하자고 하는 것에서부터
마인드가 글렀다고 생각 듭니다. 적어도 Oracle, MySQL, PostgreSQL 등을 경력으로 갖고 있는 저로서는 님같은 저렬한 마인드를 가진분에게 경력이 어떻고
저렇게 들어야할 입장은 아닌거 같습니다만?
거기다 다양한 DB 를 다뤘다고 그 깊이가 깊지 않을거라는 대뇌망상으로 세상을 사시는거보니 DBA 의 질적하락은 확실하다는 생각마져 듭니다.
아.. 그리고 DBA가 OS 영역을 많이알아야되는 이유는 RAC 때문입니다. grid, asm 등 때문에 DBA, TA 영역이 모호해지기 때문에 알아야되는겁니다… 그냥 책에서본대로 TA에서 DBA가 분리된거다 이렇게 공부하지마시구요.. 답답하네요.. 그냥..
회의하다보면.. AA TA 랍시고 구글에서 얄팍하게 검색한 정보라던가 어디서 들은건있어갖고 타업무영역에대해 아는척하는거보면 정말 같잖으놈들 많더라구요.. 자기영역에서나 잘하시고.. 타인의 삶을 평가하지마세요
각자 자기영역을 확고히 하신분들이 모이고 그분들을 어우러지게할수있는 총책임자가있을때 최고의 효율이나옵니다. 정말 대단하신분들은 타업무영역에 대해 잘못됫다하더라도 함부로 말하지않습니다..
DBA 가 OS 영역을 알아야하는 이유는 간단합니다. 쿼리나 이런것들 아무리해봤자 프로파일에는 한계가 있기 때문입니다.
Oracle 을 깊게하신분이 Oracle 시스템을 꾸밀때에 하드웨어 스펙이나 스토리지에 대한 것을 고려하지 않는 모양이네요.
RAC 이니 뭐니 해봤자 하드웨어에서부터 그 하드웨어를 조정하는 OS 에서 튜닝을 Oracle 에 맞춰 할줄 모르면
당연히 그 데이터베이스 성능은 제대로 안나 올수밖에 없고 그러다보면 그냥 쿼리만 어떻게 바꿔서 시간만 줄일려는 프로파일밖에 더 남습니까?
얄팍하게 검색만 해서 썻다는 대뇌망상에 사로잡혀 있는 거 같으시니 가까운 정신병원부터 방문하시여 정신상태 점검이나 받으시기 바랍니다.
타인의 업무영역을 침범이 아니라 하드웨어, OS 튜닝따위는 DBA, DA 의 역할이 아니고 TA 가 해야한다고 제단하고 있는
현장에 많은 DBA, DA 들이나 어떻게 단속하고 서로 어우러저 잘 일해보자 하시던가요.
기본적인 하드웨어 구성이나 설치도 못하는 DBA가 있다니 무섭네 ㄷㄷㄷ
어떤분을 만나서 일을 하셨는지 모르겠으나,
지나가던 DA로써 제가 하는 일을 말하면…
– 모델링 : DB를 깡통처럼 쓰려는 사람들을 증오하며, 현분위기는 오히려 시대를 역행하며 수준이 떨어지고 있음을 느낍니다.
– SQL튜닝 : 모델을 아는 사람이 튜닝을 하는 것이 베스트지요.
– 표준화 : 이건 솔직히 하고 있기는 하나, 정말 실익이 있는지는??
– 품질 : BR 수준에 따라 효과가 극명하지요.
– 배포 : 배포를 하려면 트러블슈팅이 가능해야 할뿐더러, 문제시 롤백 여부를 판단할수 있을 정도의 업무에 깊게 관여 하고 있어야 합니다.
– 성능테스트 지원 : API기반의 현상황에서 트랜잭션 레벨로 분석할수 있는 뷰를 가지고 있어야 하며, 결국 DB성능을 확보하는 것이 중요합니다.
– 데이터지원 : 간혹 난이도 높은 데이터처리를 위해 Batch 쿼리, procedure등을 지원합니다.
등등의 일을 하고 있으며…
솔직히 제가 판을 이렇게 만들어놔서 하는것이지 대부분의 DA가 이렇게 일을 한다고 말할수는 없습니다.
여튼 각자 자신의 분야에서 정진하고 이런사람 저런사람들이 많겠으나 결국 자신의 가치는 자신이 정하는 것이기에 스트레스 받지 마셨으면 하네요.
요새 DBA, DA 의 ‘스스로 가치를 자신이 정한다’ 라는 기준은 SQL 튜닝 빼고는 나머지는 모두 TA 가 해야하는 일이라고 일을 떠넘기니까 쓴 글 입니다. 자신의 가치를 자신이 뭔들 정하든 내 알바 아닙니다만은 DBA, DA 들은 설계하고 SQL 튜닝만 하면 되는 거고, 나머지 데이터베이스 시스템은 그야말로 시스템이니까 TA가 해야한다고 버르장머리 없이 업무영역을 자기들이 마구마구 정해버리니까 하는 말이예요. 누가 DBA, DA 들이 업무구분을 하라는 권한을 준건지도 모르겠지만 DBA, DA가 데이터베이스 시스템은 TA가 해야 하는거다라고 하면 그게 무슨 불문율 입니까.. 언제부터 데이터베이스 시스템, 백업정책, 스토리지 증설, 교체등을 TA 가 해야한다고 업계에서 정한게 있나요?
더 웃긴건 요새 AWS 클라우드 쓰는 곳이 많아지니 DBA, DA 는 좋다고, 기회다 하면서 Managed RDS 의 경우에 아예 AWS 콘솔 접속 자체를 안하고 자신들은 원격으로 SQL 서버 접속만 되게 해달라,, 나머진 우리가 할 일 아니라고 우기는 방향으로 가고 있다는 겁니다.
AWS 뿐만 아니라 Azure 의 경우에도 Managed 데이터베이스가 있는데 이것은 여러 다른 서비스들, 예를들어 AWS S3 와 같은 것을 자주 이용하는데 요새 DBA, DA 들은 우리가 왜 AWS 를 알아야 하냐 하는 식이라는 겁니다. 이참에 귀찮은 것들 다 손털고,, 우리는 SQL 만 만지고 단가는 700 이상 받고 그래야지.. 하는게 업계 트랜드화 되고 있다는 겁니다. 자신들이 손터는걸 TA가 해야한다고 자기들 입으로 떠들고 있다는 겁니다. 그냥 닥치고 있던가…
TA 파트로 이제 막 입사 했는데 선배님들의 고충들을 읽어보니 어려운 길이 될 것 같네요..
큭…
dba 들한테.. 디인 모양이군요.
dba 질 떨어지는 것은 맞는데..
dba가 sql 튜닝하는 사람은 아니죠.
sql 튜닝은 sql 튜너가 합니다.
oracle 같은 경우 os 쪽이나… oracle 파라미터나.. 다 전문업체에서 나와서… 하는 경우가 많습니다.
dba가 그런 걸 하는 것은.. 체계가 없는 작은 회사죠.
어디서 뭘 해봤다고… 무슨 사례가 있다고.. 지 맘대로 고칩니까?
그런 dba는 책임감 0입니다.
일단 금융권에서는 절대 불가입니다.
DBA 가 SQL 튜닝하는 사람은 아닐지라도 문제해결을 위해서는 볼줄 알아야죠. 디비에서 뭔가 지연시간이 발생한다면 쿼리 아니면 데이터베이스 시스템쪽일텐데 SQL 을 모르고서는 못하겠지요. 글의 요지가 전달이 잘 안된 건지는 모르겠지만, DBA 가 뭘 하던 상관은 안 합니다. 그렇다고 DA, DBA가 뭔제 데이터베이스 시스템을 TA 가 다뤄야 한다고 강요하냐는 겁니다. 더군다나 AWS Cloud 로 넘어오면서 DBA 는 SQL 만 다룰려고 기를 씁니다. AWS 의 RDS 를 사용하게 될 경우에 백업, 복원, 설정등은 전부 AWS 를 하는 사람들이 해야 한다는 입장을 줄기차게 보이는 사람들이 DBA, DA 들이라는 겁니다.
DBA 가 SQL만 다룰려고 기를 쓴다?
끼리끼리 논다고 그런 사람만 만나나보네요.
제가 SQL만 하는 DBA 를 기를 쓰고 쫓아디니는 것도 아닌데 끼리끼리 논다고요? 말을 하실라면 문맥에 맞게 단어선택을 하는 연습을 좀 하세요. 개같은 DBA 랑 제발 안 엮였으면 하는게 TA 들이란 것도 좀 아시구요.
같이 일했던 TA분들은
아주 일을 잘 하던 사람들이었고,
업무 R/R 을 잘 아시는 분들이었습니다.
DB 세팅도 못하는 DBA만 만나고, 신세한탄이나 하는 것 보니
TA 수준이 보이는 거죠.
나 역시 개같은 TA 와는 만나고 싶지 않네요.
주말에 DB 서버 뻗는데,
모르겠다고 서버 꺼버린 TA 도 있긴 했죠.
주말에 DB 서버 벋었다고 TA 연락하는 무식함을 자랑이라도 하듯 댓글을 달아놓구
R/R 잘아는 TA ? 그래서 그렇게나 잘하던 TA분들이 DB 서버를 만지는걸로 R/R이 정해진 모양이네요.
DBA 수준 보이는 거죠. ㅋ
거기다 내가볼땐 DB 서버 벋은걸 TA 에게 전가하니 TA가 서버 꺼버리죠…
어짜피 벋은 서버, 전기세라도 아끼라는 거겠죠. R/R 을 잘아는건 서버를 꺼버린 TA 인거 같은데
아,, 그리고 DBA 를 잘못만나 신세한탄한다고 댓글 달지 말고 DBA 정도 되셨으면
벋은 DB 는 본인이 직접하실 만큼의 능력이나 갖출려고 노력하세요. DB 서버 벋은걸 TA에게 연락하는 무지함을 드러내지 말구요.
이곳에서 글쓴이님과 DBA분들 다투시는 글에서 많은걸 배워갑니다. 기본적인 소양은 갖추어야 사람이고, 어느곳에 가도 이기적인 사람들은 존재할겁니다. 대부분의 문제도 이런 부분에서 발생할것이라고 생각합니다.
논쟁속에서 배운다는게 이런건가..
DB죽는건 질낮은 개발자탓 아닌가 ㅋ
몇년전에 이 글을 봤었으나, 그 당시에는 제 개인이 살아남기 위해 바빠서 굳이 댓글을 남기지 않았습니다.
저는 중소기업에서 DB엔지니어로 일할 때는 글쓴이가 쓰신 2번의 수준까지 바라보기도 버거웠던 것 같습니다. 그 이후에 중견기업과 대기업에서 ORACLE DBA로 몇 년 일을 하다가,
MySQL을 시작하면서 지금은 네카라쿠배에 속하는 회사에서 DBA로 일하고 있습니다.
제가 이 이야기를 한 것은 그만큼 꽤 여러 환경들과 시각들을 경험했다는 점입니다.
제 결론은 다음과 같습니다.
보이는 만큼 보입니다.
많은 환경들 가운데서 고생하셨던 것 같고,
저도 비슷한 환경들이나 프리들 혹은 역량이 낮은 사람들을 보면서 한탄했던 적이 있었는데,
어려운 환경에서는 비슷한 수준 혹은 생각보다 낮은 역량의 엔지니어들 또는
DBA들을 경험 할 수 밖에 없습니다.
그게 그분들의 잘못이 아니라 각 환경의 차이라고 생각되어집니다.
이제 시간이 지나셨으니 조금은 좋은 환경에서
조금은 더 너그러운 안목을 가지고 IT업무를 하셨으면 좋겠습니다.
좋은 일이 생기시길 바랍니다.
보이는 만큼 보이는것도 있지만,
하는만큼 얻은 겁니다.
그런데,어려운 환경이니까, 환경이 그러니까 경험을 적게 할 수밖에 없다고 하지만 제가 경험한 바로는 어려운 환경보다도 최대한 일을 적게 할려는 꼼수만 난무했던게 전부 입니다.
어떻게 하면 내가 할일을 남에게 넘길까 하는 식 말입니다. DBA 라고 한다면 당연히 자신이 만지는 데이터베이스시스템에 대해서 알아야 하지만
프리를 하다보면 단지 ‘시스템’ 이라는 단어가 붙었다는 이유만으로 내가 왜 그걸 해야하느냐… 나는 오렌지만 설치하고 접속해서 쿼리만 본다 하는 DBA 들 많이 봅니다.
그러면 DBA 는 시스템도 다루어야 한다고 하면 누가 그런 기준을 정했냐고 부터 해서 최대한 안할려고 합니다.
자신들은 SQL 만 다루고 돈 많이 받길 바라는 사람들일 뿐이라는 겁니다.
이제는 클라우드에 Managed 로 데이터베이스 시스템을 많이 사용하는데, 그러다보니까 이제는 클라우드의 Managed 서비스라는 이유만으로 DBA 분들이
더 더욱 안할려고 합니다. 그건 클라우드 다루는 사람들이 세팅하고 하는거지, 우리는 SQL 만 다르면 된다 하는 식으로 우기는 상황이라는 겁니다.
클라우드 Managed 서비스를 이용한다고 하면 DBA 들도 이제는 클라우드를 알아야하고 데이터베이스 시스템에 대해서 클라우드를 활용한 백업정책이나
DR 설계등을 할 줄 알아야 함에도, 이제는 완전히 자신들과는 상관없는, 그래서 일거리 하나 줄었다,, 이제 우리 영역 아니다 하면서 환호하는 상황이라는 겁니다.
DBA 들 날이 날이 갈수록 능력 없는거 맞습니다. 네카라쿠베는 당연히 그런식으로 일했다가는 잘리겠죠. 프리 DBA 들
능력없는 건 맞고 시간이 갈수록 SQL 만 하면 된다하는 사람들만 더 늘어나고 있는 현실만 있을 뿐입니다.
성급한 일반화의 오류인거 같네요.
그런 환경에서는 비단 DBA 직군만이 문제는 아닐겁니다. IT 개발자들도 매한가지죠.
함께 일하는 환경이 중요합니다. 괜히 좋은 회사에서 사람 안뽑힌다고 할까요?
Gray Zone의 일들은 어디에나 있습니다.
그걸 얼마나 책임감을 갖고 깊게 접근하느냐의 차이인것이죠.
채용할 때 신중하게 잘 하시길 바랍니다.
– 지나가던 네카라쿠배 DBA
성급한 일반화가 아니라 대부분의 인간들의 행동이 어떻게 하면 내가하는 일을 줄이고 남에게 떠넘기나 하는걸 기반으로 하니 하는 말입니다.
함께 일하는 환경이 중요한게 아니라 개인들의 마인드가 중요한 겁니다. 환경이 아무리 좋아봤자, 마인드 자체가 남에게 일 넘기기를 기반으로 하면 답이 없는 겁니다.
전체 글을 읽고 한마디만 할께요.
본문에 “사람이 한번이나 두번정도는 상대방, 그러니까 나의 경우에는 DBA의 개인적인 일탈쯤으로 여길수도 있다. 하지만 프로젝트를 할때마다 DBA와 문제가 생긴다면 이거는 개인적인 일탈이 아니라 사회적인 제도와 같이 구조적인 문제로 봐야 한다” 이렇게 적어 놓으셨는데
==> 프로젝트 할 때 마다 DBA와 문제가 생긴다면, 이건 본인 자신을 한번 뒤돌아보셔야 하지 않을까 싶네요.
오픈마인드를 가지고 상황이나, 상대방을 서로 이해하려고 노력 해 보시면 훨씬 덜 손해 보는 느낌이 드실겁니다.
그 문제라는게 DBA 가 해야하는 일을 TA 에게 전가시키는 거라면 구조적 문제가 맞습니다.
대표적으로 AWS RDS 를 이용해 DB 를 구축할 경우에 현재 DBA 들은 AWS RDS 자체를 자신들이 하는일이 아니라고 우기는게 대표적 입니다. 그건 AWS SA 가 해야한다고 주장하는 거죠.
거기다 본인의 주장대로 라면 수많은 사회에서 발생되는 문제 대해서 피해자가 문제가 있다는 논리가 성립돼 허용 되지 않습니다.
대표적으로 직장내의 성희롱의 경우에 여러번 성희롱을 당한 사람에게 ‘그건 니도 문제가 있는거 아니냐?’ 하는 식의 논리 말 입니다.
주제를 한정해서 보면 DBA 들이 문제가 맞습니다. 요즘 DBA 의 직무 범위에서 DB 서버 관리 자체를 안하는게 맞다라고 우기고 있는 상황이니..
우와 TA가 못하면 DBA 탓, DBA가 못하면 DBA탓..^^
업무는 Gray 영역이 많은것이 사실이고, 내가 일을하면 불만, 상대가일을하면 그런가하고 넘어가는일들이 비일비재합니다.
관리자님도 얼마나 일을 잘하시는지 모르지만 놓치는 부분이 있을거구요.
위의 초등학생같은 논리를 당당하게 펼치시는 관리자님의 아집에 놀라고갑니다^^
제가 누군지도 모르고 놓치는부분?? ㅋㅋㅋ
DBA 를 제가 할줄 몰라서 이러는거 같아요? 개발?? 개발은 뭐 경력이 없는 줄 아시나보네.. ㅋ
초등학생같은 논리로 본걸 보니 본인시각이 초등학생밖에 안된다는 생각은 못하시나 보네요.
관리자님 경력은 궁금하지않구요. 현업에서는 아시다시피 경력보다 실력입니다
그리고 아무리 실력이 좋은사람도 완벽할 수 없기에 놓치는부분은 당연히 있는거구요.
인력 관리하다보면 실력 비슷비슷한거 금방 아실텐데요..
자신의 전문분야가 아닌 영역을, 심지어 전문분야라도 자신의 생각을 함부로 일반화하는건 겸손하지 못하다고 생각합니다. TA role이고 DBA role이고를 떠나서요.
재미있는 토론을 할줄알았는데, 댓글 상태가 영.. 더이상의 댓글은 쓰지 않겠습니다.
전문분야가 아닌지 그런지 글자 몇번 보고 겸손 운운하시는지… 뭐든 겸손해야 하는데 일반화 한다?
본인이 댓글은 뭔 전문가인지 뭔지 모르겠지만 경력보다 실력이다 뭐다 하면서 꼰대 짓을 하는 건 눈에 안보이는 모양이고
토론의 기본 자세가 남을 깔보면서 ‘니가 뭘 안다고?’ 식의 접근이 토론의 자세인가?
ㅋㅋㅋㅋ 본인은 얼마나 안다고 일반화 하네 마네 하는지… 세상엔 미친놈들도 많고
우월적 존재를 내세워야만 토론이 되는줄 아는 인간들이 정상인인척 하는 소시오패스같은 인간들이 넘쳐나는게 사실이지..
DBA라는 책임은 자료를 보니 전문영역이네요.
내용만봐도 이렇게 할사람은 극 소수고 기업이 아웃소싱이나 후려치기 할 가능성이 매우 높은 포지션으로 느껴집니다 (아쉽긴 하네요..)
데이터베이스 관리자(database administrator, DBA)는 한 조직 내에서 데이터베이스를 설치, 구성, 업그레이드, 관리 , 감시하는 일을 맡은 사람을 가리킨다.[1] 보통 다음의 역할을 수행한다.
자료 복구 – 백업
보전 – 데이터 보전(Database preservation)
보안 – 접근 제어
사용 가능
성능
솔루션 관리
개발 및 테스트 지원
데이터베이스 관리자의 역할은 데이터베이스 관리 시스템 (DBMS)의 기술, 데이터베이스 소유자의 요구에 따라 바뀌어 갔다. 이를테면, 로컬 및 물리 데이터베이스 설계가 전통적으로 데이터베이스 분석가나 데이터베이스 설계자의 의무라 할지라도, 데이터베이스 관리자에게는 이러한 의무가 주어진다.
의무
새로운 소프트웨어 설치
시스템 관리자의 하드웨어 및 소프트웨어 구성
보안 관리
자료 분석
데이터베이스 설계 (예비)
데이터 모델 제작 및 최적화
기존의 엔터프라이즈 데이터베이스의 관리, 새로운 데이터 베이스의 분석, 설계, 작성에 대한 책임
se인데 구구절절 맞는말씀
내 영역아니라고 나몰라라하고 월급만 받아가고 커리어커리어하면서 이직할라는 거품인력들이 너무 많습니다
dbms 엔지니어 = db 설치 , os parameter 최적화 및 스토리지 구성 요청
sql 튜너 = 개발자가 작성한 쿼리에 대해 성능 분석 및 튜닝, index 가이드
DA = 논리 모델링 및 표준화 담당
크게 이렇게 나눠져 있고요.
Dba는 말 그대로 dbms를 관리하는 사람입니다. 성능이 sql 문제면 전문 튜너를 불러서 해결하고요. 설치나 db 구성 및 os 커널 설정이 문제면 기술지원 엔지니어의 도움을 받아야 합니다.
물론 혼자서 엔지니어, dba, sql 튜닝, da 다 하는 사람도 극히 드물지만 존재는 합니다만. 이것저것 다 손대면 죽도 밥도 안됩니다.
DA 에 A는 Archtect 입니다. 설계자라는 뜻입니다. IT 용어는 많은 부분에서 건축에서 빌려왔는데, 그 용어를 그냥 빌려온 것이 아니라 IT의 개발이나 기타 여럿이 건출과 비교되기 때문에 거기에 맞춰서 가지고 온겁니다. DA = 논리 모델링 및 표준화 담당 이라고 하는 말은 한국 IT, 그것도 SI에서만 국한되는 말입니다. 건축에서 설계를 하는 사람은 설계만 합니다. 하지만 그런 설계를 하기 위해서는 콘크리트의 종류, 성질 건축골격을 어떻게 할 것이고 냉난방은 어떻게 고려해야하는지 등에 대해서 다 알아야 합니다. 그러한 이론과 경험이 없이 건축 설계를 해서 집을 지어봤자, 제대로 된 집이 되지 않습니다.
한국의 병폐가 바로 이런건데, DA 가 되었던 DBA 가 되었던 Database 에 대해 전반적인 것을 다 알고 있어야 합니다. 이러한 것은 Oracle 데이터베이스 자격증 시험 카테고리만 봐도 잘 나타납니다. 그 시험에 SQL만 가지고 문제를 내지도 않고 Oracle 데이터베이스 시스템에 대해, 그리고 각종 설정값이나 기본 구조 개념들도 모두 문제에 나옵니다. 데이터베이스 시스템이 있고 그 분야에서 역할이 DA, DBA 로 나뉘어 있다고 하더라도 Database 시스템과 SQL 두가지는 전반적으로 다 알고 있어야 하는 것이며, DA 가 되었건 DBA 가 되었건 이러한 전반적인 이론을 기반으로 실무적인 적용을 해내야하는게 맞는 겁니다.
DA 를 모델링과 표준화 담당이라고 했는데, 그건 결국에는 많은 시간 동안 많은 모델링을 해봤냐로 판가름되는 것이지 별도의 이론따위는 별로 안중요해 집니다. 표준화화라고 말하지만 정작 데이터베이스 시스템에 맞게 표준화 해놓는 사람도 별로 없다는 것도 문제입니다. Char, varChar 이나 int 나 unsigned 이런걸 고려하면서 테이블 설계하는 인간들 못봤고 더 나가 그걸 적용하는 데이터베이스 시스템이 PostgreSQL 인지 MySQL 인지 Oracle 인지에 따라서 약간의 차이가 존재하는데, 그것과는 아무런 상관없이 그냥 ‘표준’ 이라는 말로 대충 하는 인간들 차고도 넘칩니다.
ㅋㅋㅋ 내가 dbms만 25년 되어갑니다.
db 전문가도 아니면서 아는 척 심하시네요.
님이 말하는 전문가는 이데아 속에서나 존재합니다.
그걸 하나하나 파고 들면 밥막고 공부만 해야 합니다. 그렇게 내공을 쌓아도 연봉 1억 못 받아요.
남의 분야라고 멋대로 지껄이지 마세요.
원래 남이 하는 일이 쉬워 보입니다.
저는 어디가서 남의 분야는 물론이고 재분야도 함부로 이야기 안합니다. 어차피 제가 아무리 경력이 많아도 우물안 개구리라는 걸 잘 아니까요.
겸손해지시길.
지랄을 해라… 뭔놈의 이데아냐? ㅉㅉㅉ
남의 분야라고? DBA 아무나 다 하지.. 개발하다 DBA 한다고 하는 놈들이 널렸는데, 뭔 개소리를 운운해… 거기다 남의 분야? DBA 경력 없는걸로 보이나? 멍청하네..
dba도 개발자 출신이 있고,
아니면 기술지원 엔지니어 출신도 있습니다. 기술지원 엔지니어 출신이면 설치나 os storage network에 대해 어느 정도 이해가 있고요.
개발자 출신이면 그런 인프라 지식은 거의 없고 sql 및 운영 관리를 합니다.
아마 후자의 dba를 겪으신 듯 하고요. 보통 dba들은 특히 대기업은 거의 해당 파트는 외주업체 불러서 처리합니다.
Dba 구인이라고 해도 어디에 포커스를 두냐에 따라 인력풀은 다양합니다.
사람이 별로 없는 건 대우가 별로라서 그렇습니다.
장애 뒤치닥거리 하고 버그 때문에 장애나도 불려가서 욕받이하니까 다들 꺼리죠.
그렇다고 돈을 많이 주는 것도 아니고요.
일당백 dba는 단가가 좀 비싸요. 이런 분들은 인프라 엔지니어 부터 운영 dba, sql 튜닝까지 가능한 경우인데. 좀 비싸죠.
어리석은 댓글 달시간에 공부나 하시길 권합니다.
개발자 출신이 되었던, 엔지니어출신이 되었떤,, 더나가 대기업은 거의 외주업체 불러서 기술지원을 받는다고 하는데, 그러다 장애나면 전화만 해대고 문제해결은 정작 못하는 DBA가 DBA 라고 보십니까? 개발자 출신들은 SQL 과 운영 관리라는게 외주업체 전화해서 오라가라,, 서버 이상하니까 점검해라 정도이고 결국에는 SQL 만 한다는 것이고 그런 사람을 DBA 라고 하지 않고 SQL Developer 라고 불러야 적당한 것이며, 단가가 되었든 월급이 되었든 많이 줄 이유도 없는 겁니다. 예를들어, 외주 업체가 다 있다고 하더라도 그 외주 업체가 OS 설치는 차치하더라도 데이터베이스를 시스템에 맞게 잘 설치하고 있으며 어떠한 파일시스템 레이아웃으로 설치가 되었고 각종 파라메터가 어떻게 세팅되어 있으며 그것이 어떤 영향을 미치는지 알지 못하는 DBA 는 그냥 SQL Developer 이지 DBA가 아닙니다. 반쪽자리에게 비싼 돈 줄 이유는 없거니와,,, 되도 않는 소리로 여기까지 와서 DBA 라고 우겨데봤자 그냥 30년 SQL Developer 인 겁니다.
ㅋㅋㅋ 맛이 갔네 과대망상증이가나 주제 파악을 못하는 친구네. 가까운 정신병원 가봐라.
나 오라클 25년 경력이고 좀 있음 은퇴할 나이고
이 바닥 이름 석자 대면 그래도 인지도 있을 정도로 열심히했다.
요즘 애들은 주제 파악이 안되나?
주제파악를 못하네. 실력도 없는 것들이 말만 많아요.
니가 다니는 회사가 돈이 없어서 싸구려 프리나 데려다 일시키니 그런거 못하지.
돈을 제대로 줘바라. 대한민국에 사람이 없겠냐?
지랄을 해라.. 지랄을….
과대망상은 내가 더 우위에 있다라고 경력이 어쩌네.. 이름만 대면 다 아네.. 그게 정신병이야~
뭐 어쩌라고? ㅋㅋㅋ 능력이 없는 놈들이 말이 많아요..
관리자 및 전문 영역 분들이 한번씩 단 댓글을 보면서 본인도 반성하고, 더 정진해야 할 것 같습니다.
시스템 엔지니어로 보는 부분이지만 나름 다들 전문 영역에 맞게 특화된 부분을 이해하려고 노력하고, 또 그렇게 다들 고생이 하다가, 하얗게 나이를 먹나 봅니다.
하드웨어를 좋아하는 본인에겐, 오류 없이 잘 동작하는 서버를 보는 즐거움이 큰데, 다들 너무 고생이 많습니다.
예전에 슬락웨어 시절이 더 낭만 있지 않나 생각하면서….
문해력이 논란이라고 하더니만,, 여기 어디에 하드웨어를 좋아라 한다고 해요?
거기다 제가 말하는 논점이 하드웨어 특화된 겁니까?
OS 는 개발 아니요? 데이터베이스 시스템은 뭐 개발자 안 만들었나? 인프라네 뭐네 그런 거 없어요.
좀, 객관적으로 보고, 넓은 아량으로 좀 봐주면 좋겠네요. 인프라도 시스템 엔지니어/백엔드/프론트 다 함께 협업하는 세상입니다. 혼자 할 수 있어도 전문영역 부분은 존중해주고 그런 부분입니다. 하드웨어는 내가 좋아 한다는 말입니다!
시스템엔지니어도 다 할 수 있죠…그런데, 기본 잘지키고 구성한 뒤에 넘기는 것이 맞아요.
질문/답변 마음 이해하려고 단 댓글에 너무 맘쓰지 않기 바랍니다.
많이 배우고 갑니다..삶을 뒤돌아 봐야 할 듯 싶네요. 문장 이해력이 부족해서..!