단무지 시즌 IV: 단무지의 운영 DB 이야기

사람이 답이다, DB 일일점검의 실전(5)

[필자] 서윤식은 외환신용카드에서 DBA로 12년을, 현대하이카다이렉트에서 DA로 10년을 일했다. 금융권 데이터 분야에서 22년간을 보내며 DBMS 운영 및 튜닝, SQL 튜닝, 데이터 모델링, 데이터 품질관리 영역 등 DB의 전 영역을 고루 경험하였다. 이학사(전자계산학과)와 경영학 석사를 거쳐 2015년 8월 IT 정책경영학과 박사과정을 수료하였다. 2016년 3월부터 데이터와사람들의 대표로 있으며, 한국데이터진흥원의 산업체 전문 강사로서 데이터 모델링 및 SQL 튜닝 강의를 하고 있다. 또한 네이버의 ‘데이터와사람들(http://cafe.naver.com/dbstudydapsqlp)’ 카페를 운영하며, 데이터 영역에 지식이 필요한 사람들과 다양한 방법으로 소통하고 있다.

IT 본부의 향후 3년 비전 수립: 3마리 토끼 잡기

이번 달 초, 단무지가 근무하던 IT 부서가 IT 본부로 승격되었다. 그와 동시에 IT 기획팀, IT 운영팀, IT 개발팀도 부서로 자동 승격되었다. IT 기획팀장과 IT 운영팀장은 차장에서 부장으로 승진과 동시에 부서장이 되었으며, 단무지는 과장에서 차장으로 승진과 함께 IT 개발부장을 맡게 되었다.

단무지를 제외하고 2명의 부서장은 부장이라는 직급으로 부서장 역할을 수행하지만, 유일하게 단무지만은 차장으로 부서장 역할을 맡게 되었다. 따라서 직급은 차장이지만, 직책이 부서장인 만큼 자연스럽게 부장으로 불리게 되었다. 따라서 단무지는 직장생활 중 차장으로 불려지는 기간을 거치지 않았다. 단무지의 이러한 상황을 신임 본부장이 여간 놀려대는 것이 아니었다. 하지만 놀리는 사람도 놀림을 당하는 사람도 즐겁기만 한 이상한 상황이었다.

단무지는 IT 본부 안의 3개 부서장 회의에 참석하고 있다. 부서에서 IT 본부로 승격되었고, 회사도 설립된 지 1년이 경과했으므로 향후 3년간의 IT 본부 비전에 대한 방향성 수립을 위한 회의였다.

IT 기획부장: 본부장님, 저희 부서 입장에서는 금융당국의 정책에 맞추기 위해 구축해야
할 사항이 너무도 많습니다. 먼저 재해복구시스템을 구축하여야 합니다. 재해복구 시스템은
금융감독원에서 제시하는 필수 조건이기도 하지만, 비상시 우리 회사를 위해서도 반드시
구축해야 하는 시스템입니다. 이어 데이터 암호화, DB 접근제어 시스템, 애플리케이션
보안 강화, 문서보안, 네트워크 2중화 등 해야 할 일들이 산적해 있는 상황입니다.
IT 본부장: 그렇군. 대부분의 금융사들은 이미 구축한 시스템들을 우리는 이제부터 하나하나
해 나가야 하겠네. 어쨌든 금융당국의 정책뿐 아니라 요즘 문제시 되고 있는 개인정보보호를
위해서도 최대한 빠르게 진행해야겠군. 일단 추진 계획부터 수립해 보자고.
IT 기획부장: 네. 알겠습니다.
IT 운영부장: 저희 부서는 IT 기획팀에서 진행하는 것들을 수행부서로서 기획부와 협조 하에
추진할 예정입니다. 또한 현재는 각종 모니터링 툴이 부재한 상황입니다.
APM(Application Performance Monitor) 툴, DB 모니터링 툴 도입이 시급한 문제입니다.
모니터링 툴이 없으니, 시스템의 이슈상황을 늘 모니터링하여 장애로 연결되지 않도록
사전 조치해야 합니다. 현재로선 이것이 가장 어려운 상황입니다.
IT 본부장: 음~~~ 이것 또한 투자의 문제로군. 경영진들이 가장 어려워하는 일이
IT에 대한 투자인데. 이를 어떻게 이해를 시켜야 하나 고민이로군. 일단 IT 기획부장하고
잘 상의해서 기안문서를 작성해 보라고. 아, 그리고 DB 운영은 IT 개발부에서 하고 있으니,
DB 모니터링 툴에 대한 것은 단 부장도 자유롭지 못하겠네.
단무지 부장: 네. 맞습니다. 대신 DB 모니터링 툴은 상용제품을 도입하지 않고,
우리 회사에 딱 맞는 맞춤형 모니터링 툴을 자체 개발하여 사용해 보도록 하겠습니다.
현재 DBA 업무를 담당하는 머나먼 대리를 DBA로 키우고 있습니다. 현재 성장하는
속도가 매우 빠릅니다. 아마도 머지않아 근사한 모니터링 툴을 만들어 보겠습니다.
IT 본부장: 그래 오~~~ 이거 듣던 중 반가운 소리구만. 비용을 안 들이고 상용제품보다
더 우리회사에 꼭 맞는 툴을 만들겠다는 건데…. 그렇게만 된다면 구축비용 부담 해소와
툴 품질 확보는 물론, 직원들의 스킬까지 자동 업그레이드되겠구만.
이거 일석 삼조인데. 좋았어. 잘 만들어 봐.
단 부장: 네 알겠습니다.
IT 본부장: 그리고 이것 말고 IT 개발부에서 향후 3년간 해야 할 중요한 일이 무엇이 있을까
단 부장: 네. 저희 부서는 애플리케이션 개발 및 유지보수가 가장 중요한 업무입니다.
현업 부서에서 타사와 경쟁하기 위해 다양한 상품 개발을 할 것입니다.
이때 빠른 전산 개발과 사용자가 쉽게 사용할 수 있어야 하며, 정확하게 데이터를
보여줘야 하는 전산 품질 부문이 중요합니다. 이 두 가지를 모두 잡기 위해서는
먼저 직원들의 교육이 필수적이라 생각됩니다. 오랜 역사를 자랑하는 타사의 IT 인력들은 그 회사에 최적화한 인력으로 육성돼 있겠지만,
우리 회사는 이제 설립한 지 1년여 밖에 지나지 않았습니다. 따라서 교육을 통해 직원들을
보험회사에 최적화한 전산인력으로 키워 나가야 한다고 생각합니다.
교육은 다음 두 가지로 진행했으면 합니다. 첫째는 우리회사가 보험회사이다 보니 보험 업무에
대한 교육이 필요합니다. 보험 업무를 완전히 이해하지 못한 상황에서 프로그램을 개발하다 보면
자칫 현업에서 요구하는 사항을 잘못 이해하고, 엉뚱한 프로그램을 개발할 소지가 높습니다.
이렇게 되었을 경우 현업의 요구사항에 맞는 프로그램을 재개발해야 하며, 현업에서 요구하는
빠른 전산 개발이 이루어지지 못하는 문제로 연결될 확률이 매우 높아집니다.
이 교육은 현업 부서의 오랜 경험을 가진 직원들에게 요청할 생각입니다. 둘째는 SQL 튜닝 교육을 진행하고자 합니다. 현재는 데이터가 적어 조회속도가 빠르지만,
머지않아 프로그램 응답속도에 문제가 발생하기 시작할 겁니다. 프로그램 응답속도를 높이려면
SQL 튜닝이 필요합니다. DBA 한 명이 문제가 되는 모든 SQL을 튜닝하다 보면 한도 끝도
없을 겁니다. 또한 개발자들은 지속적으로 잘못된 SQL을 개발하고, DBA가 튜닝을 한다는 것은
비 생산적인 상황의 연속일 뿐이라 생각됩니다. 따라서 개발자들이 스스로 높은 품질의 SQL을
개발할 수 있도록 교육을 시키는 것이 좋은 해결 방법이라 생각합니다.하지만 개발자들은 SQL의 성능 부분은 본인의 영역이 아니라 생각합니다. 본인들은 업무에 맞는
SQL 작성까지만 책임지고, 성능은 DBA가 신경 써야 한다고 생각하는데요.
이를 바로 잡아, 개발자들의 스킬 향상 및 개발과 튜닝을 분리하지 않고, 개발과 동시에 튜닝이
필요 없는 높은 수준의 SQL 작성이 가능하도록 해 볼 생각입니다. 이는 SQL의 성능뿐 아니라
, 개발과 튜닝이 분리되지 않아서 개발 생산성 또한 높아지리라 생각됩니다.IT 본부장: 오~~~ 참 좋은 생각이야. 그리고 IT 개발부에 정말로 필요한 상황이라 생각해.
IT 개발부도 정말 바쁜 3년을 보내야 하겠네 그려. IT 기획부와 IT 운영부에서 진행하는 것은
반드시 개발부 지원이 필요할 것이고, 거기에다가 직원들 교육까지 신경을 써야 하니 말일세.
그뿐인가 신설 회사이다 보니 현업에서 요구하는 개발 사항이 엄청날 텐데…. 3마리 토끼를
모두 잡아야 하는 상황일세 그려. 하하 하지만 자네 말대로 직원 역량강화가 현실로만 된다면,
우리 IT 본부뿐만 아니라 우리 회사에서도 어떠한 시스템을 도입하는 것보다 더 좋은 무기를
갖게 되는 것인데 말이야.단 부장, 그런데 한 가지 우려되는 것이 있는데 말이야 경우가 많아서 그게 걱정이야. 그렇다고 구더기 무서워서
장 못 담글 수도 없고 하하하.단 부장: 네. 맞습니다. 항상 그것이 고민이긴 한데요. 그렇더라도 교육을 멈추는 것보다는
꾸준히 교육을 시키는 것이 회사에 도움이 된다고 생각합니다. IT 본부장: 맞아. 나도 자네 말에 공감해. 직원 역량강화와 이직에 대한 우려는 항상 공존하는
문제이지. 그래. 열심히 해봐. 진행되는 상황 나한테도 꾸준히 알려 달라고.단 부장: 네. 고맙습니다, 본부장님.

단무지 부장은 회의를 마치고 사무실로 돌아왔다. 직장 생활을 하며 느낀 것은 회사는 직원들의 역량 강화를 위해 많은 투자를 하지만, 정작 중요한 것은 관리자들의 마인드가 그렇게 형성되어 있지 않아 투자대비 효과가 그리 높지 않다는 점이었다. 직원들의 역량 강화는 회사의 투자와 동시에 팀장 및 부장 등 현장 관리자들의 관심도가 가장 중요하다. 하지만 교육 투자 대비 성과(업무 능률 향상)를 정량적으로 측정해 내기가 쉽지 않을뿐더러 관리자들의 업무 우선순위에서도 교육은 항상 낮은 등급을 차지할 수밖에 없다는 점이 가장 큰 문제였다. 단무지 부장은 부서원들의 교육을 살뜰히 챙기면서 교육 효과를 정량적으로 측정하는 방법을 찾아 봐야겠다고 생각했다.

전일자 CPU 사용률과 현재 CPU 사용률 비교

머나먼: 부장님…단무지: 왜 오늘은 어떤 걸 할 차례이지
머나먼: 부장님, 승진하시고 승진 턱 안 내셨는데요. 보통 부서원 같으면 승진 턱 내기 전까지는
이전 직급으로 부르는 것이 관례인데, 이거 부장님을 승진하기 전처럼 팀장님이라 부를 수도 없고
. 부장님을 부장님으로 부르지 못하는 제 심정을 좀 헤아려 주시면 고맙겠습니다.
단무지: 이 사람이…. 열공해서 더 질 높은 서비스를 회사에 제공할 생각은 안 하고
웬 아침부터 술타령이야
머나먼: 허~~~ 부장님, 이거 왜 이러십니까 전 항상 청출어람을 꿈꾸고 있습니다.
승진 턱은 사적인 일이고 업무는 공적인 일인데, 부장님께서는 공과 사를 구분하지 못하고 계십니다.
단무지: 허 이 친구!! 이젠 내 앞에서 능청을 다 떠는구먼. 너 죽고 잡냐
머나먼: 죽을 때 죽더라도 승진주는 한잔 올려 드리고 싶은 제 충정을 이해해 주십시오.
단무지: 얼씨구 이젠 스승님의 귀하디 귀한 말씀을 가지고 말장난까지 치는구먼. 하하 알았다.
하긴 승진자 회식은 해야지. 부서 고참들하고 이야기 해서 날짜 한번 잡아 보라고.
그런데 오늘 뭐 할 차례이지
머나먼: 넵. 전일자 CPU 사용률과 현재 CPU 사용률 비교하기입니다.
단무지: DBMS에 이상현상이 발생하였을 경우 가장 먼저 나타나는 것은 각종 Latch가 발생하는 거야.
그럴 땐 Latch의 발생 원인을 찾아서 해결해야 해. 사실 Latch보다도 더 확실한 것이 CPU 사용률이야.
CPU가 평소 대비 높다는 것은 내부적으로 배치 프로그램이 수행된다든가 비 정상적으로 세션이 증가해
불필요한 프로그램들이 수행된다든가, DB 내 경합이 발생하여 심각한 Latch 및 락(Lock)이 증가되는
경우이지. 즉 CPU가 평소보다 높을 땐 반드시 원인을 찾아야 해. 이슈인 것은 원인을 분석하여
해결해야 하며, 정상적인 배치 프로그램 때문이라면 끝날 때까지 긴장의 끈을 놓지 않고,
그 프로그램을 모니터링 해야 해. 갑자기 CPU에 부하를 주는 프로그램은 자주 수행되지 않는다는
이야기이고, 자주 사용되지 않는 프로그램은 장애 발생 확률이 일반 프로그램에 비해 높기 때문에
신경을 쓰고 봐줘야 해. 또한 DBA는 CPU 사용률을 보는 관점을 인프라 직원들이 보는 것과 달리해야 해. 인프라 직원들은
분 단위 평균 CPU 사용률을 보는 것이 일반적이거든. 다시 말해 CPU가 3초 동안 50%, 60%, 70%를
사용했다면 3초 평균은 60%가 되지. 즉 이런 방식으로 인프라 업무를 담당하는 직원들은 분 단위
평균치를 보는데, DBA라면 평균 사용률이 아닌 모니터링하는 포인트-포인트의 CPU 사용률을
중요하게 생각해야 해. 다시 말하여 3초간 모니터링을 했다면 평균 60%가 중요한 것이 아닌,
가장 높은 70%를 중요하게 생각해야 한다는 거야. 하지만 이걸 인프라 직원들과 이야기하면
한동안 누가 맞는지 논쟁을 해야 해. 피곤한 일이지. 차라리 별도로 DBA가 DB 서버의 CPU
사용률을 DB에 기록하고 관리하는 방법이 내가 해온 가장 편리한 방법이더군.내가 그동안 CPU 관리해온 방법은 다음과 같아. 1. Stored Procedure 개발동 프로시저를 호출한 프로그램이 CPU 사용률의 △user 사용률 △system 사용률 △Idle
세 가지 파라미터를 받아 단순히 일련번호, 일시와 함께 DB에 저장시키는 프로시저 2. OS 쉘 스크립트 작성vmstat 1 2 |tail -1 | awk '{print $20, $21, $22}' | read USR SYS IDLE
sqlplus -s "/as sysdba" < < EOF
execute P_DBMS_STATE.SP_DBMS_STAT_CPU($USR, $SYS, $IDLE);
EOF간단히 설명하면 CPU 사용률을 조회할 수 있는 OS 명령어인 vmstat를 이용하는 거야.
vmstat를 1초에 한 번씩 수행시키되, 2번째 수행된 CPU 사용률 값을 위에서 개발한
stored procedure를 호출해 파라미터로 넘겨주는 스크립트야. 자세한 것은
어려운 내용이 아니니 shell script 작성 방법을 통해 공부해 보라고.3. 2번의 shell script를 OS의 스케줄러인 cron table하면 끝이야. 아주 간단하지
이런 방식으로 CPU 사용률을 가지고 있으면, DBA는 시스템 운영에 있어
엄청난 힘을 갖게 되지. 굳이 인프라를 담당하는 직원에게 매번 CPU 사용률 데이터를
요청하지 않아도 될 뿐 아니라, 내 관점에서 데이터를 볼 수 있어. 물론 회사의 자원관리 방침에는
약간의 중복이 있을 수도 있겠지. CPU 사용률은 SMS(System Monitoring System)에
존재하는데 DBA가 별도로 중복하여 가지고 있는 거거든. 하지만 SMS에 존재하는 데이터는
CPU 사용률에 대한 관점이 DBA하고는 달라서 별도 관리하는 것이 좋아. 또한 CPU 사용률을
저장한다고 해서 디스크나 자원에 부하를 크지 주지도 않으므로 이 정도의 중복은 나쁘다
생각하지 않아. 즉 실보다는 득이 훨씬 높다는 이야기지. 이 다음은 CBO(Cost Base Optimizer) 운영의 꽃인 오브젝트 통계정보에 대한 이야기를
해야 하는데, 이 이야기는 Library Cache 이야기와 묶어서 다음에 이야기하는 것으로 하자고….
머나먼: 네. 감사합니다 부장님. 부장님 이야기만 듣고 있으면, 머리속이 너무 맑아 지는 것 같습니다.
단무지: 그건 자네가 내 말을 들을 준비가 되어 있어서 그래. 즉 예습 복습을 잘 해와서
그렇다는 이야기이기도 하고. 이제 일일 점검은 거의 완료되어 가는 것 같군 그래.
자 오늘 하루도 수고하고.

잠깐, PMS에 대해 알아봅시다

전산 프로그램에 대한 유지보수 프로세스를 전산화한 시스템으로, 사용자가 프로그램 수정을 IT 개발자에게 요청할 경우 동 시스템에 등록한다. 개발자는 SDLC(System Develop Life Cycle, 요구분석-설계-개발-테스트-적용) 전 과정을 동 시스템에 등록한다. 이 시스템을 갖출 경우 장점은 ①개발된 전산 프로그램의 품질이 매는 과정을 줄여 줌으로써 궁극적인 생산성이 올라간다(소프트웨어 공학자들의 이야기이지만, 사실 필자는 이 부분에 대한 공감하지 않는다. 하하). 또한 ③관리자를 위해 개발 과정의 가시화가 이루어지며, 이를 통해 관리자들은 조직 관산성에 대한 이슈가 있을 수 있다. SDLC 전 과정을 개발자들이 일일이 입력해야 하므로 여기서 오는 공수 손실 및 개발자들의 스트레스가 높아진다.

소프트웨어 공학자들은 PMS를 도입하면 생산성이 높아진다고 이야기하지만, PMS와 생산성의 문제는 긍정의 효과보다는 부정의 효과가 높아 보인다. 하지만 산출물(개발된 전산 프로그램)의 품질 측면과 SDLC 과정의 가시화는 높게 평가해 필요한 시스템이라는 말에는 공감한다.

에필로그: 역시 사람이 답이다!

필자는 지난 10여 년간 몸담았던 회사에서 부서 직원들의 교육에 많은 공을 들였습니다. 매년 보험업무, SQL 튜닝, 데이터 모델링 교육을 주기적으로 했습니다. 이것이 10년 동안 누적되다 보니 개발 생산성이 엄청 나더군요. 필자가 다녔던 회사는 전산 품질을 높이기 위해 PMS(Project Management System)를 도입하였고, 그것으로 인해 개발 생산성이 낮아질 수 있는 요인이 있었습니다. 하지만 그것은 직원들의 역량강화로 인해 PMS가 도입되지 않는 회사보다 훨씬 높은 생산성을 발휘하였을 뿐 아니라, 개발된 전산 프로그램의 품질 또한 매우 높아 현업직원들의 만족도가 높은 편이었습니다. 여기서 얻은 필자의 결론은 ‘그래!! 역시 사람이 답이다’였습니다. (끝)

출처 : 한국데이터진흥원

제공 : 데이터 전문가 지식포털 DBguide.net