[저자 인터뷰] 개발자를 위한 인덱스 생성과 SQL 작성 노하우

“블로그나 책에서 소개하는 방식을 제 방식으로 다시 이해하면서 인덱스를 파고 들었습니다. 그 접근 방식을 소개해 놓은 것이 이 책에서 나오는 ‘인덱스 생성도’와 ‘공정쿼리’입니다. … DBA 업무를 하면서 DB의 특성을 파악하고 나니까 이런 게 있었는데 왜 알려주지 않았을까? 하는 생각이 들더라고요. 노하우는 알고 나면 너무나 당연한 건데도 몰랐을 때는 사람을 옭아매는 존재이기도 하죠.”

 

이 책을 쓴 배경은.
개발자였을 때 DB 때문에 고생하다가 극복했던 경험과 노하우를 공유하기 위해서입니다
 

DBA로 일했던 것으로 알고 있습니다.
개발자로 10년 정도 일하다가 우연한 계기로 DBA 일을 하게 됐습니다.
 
어떤 계기로 DBA가 되었나요.
대형 SI 업체에서 일할 때 우연하게 DB 관리 업무가 주어지더군요. DBA 업무를 했던 선임자가 갑자기 회사를 떠나게 되면서 발생한 일이었습니다.
 
DB에 관심이 많았나 봅니다.
DB 분야는 솔직히 헷갈려할 때 였습니다개발 분야는 나름 자신이 있었지만, DB 운영 경험도 없었고 별도로 DB 교육을 받은 적이 없었습니다지금 생각해 보면 조금 무모했던 거 같기도 합니다만그때 도전했던 것이 매우 잘한 선택이었다고 생각합니다^^
 
무리 없이 DB를 운영할 수 있었나요.
처음에는 당혹스러웠지만곧 적응할 수 있었습니다. 200대가 넘는 전국 기초 지방자치단체의 DB 서버를 혼자서 관리하는 업무였습니다선임자가 수작업으로 관리했던 것을 프로그램을 개발해 자동화하면서 일이 크게 줄어들었습니다
 
어떻게 적응했는지 궁금한데요.
평소에 자신감 없던 인덱스부터 제대로 한 번 이해해야겠다는 생각이 들더라고요당시만 해도 인덱스 개념이 머릿속에 분명하게 정리되지 않았어요. ‘인덱스는 무언가를 쉽게 찾기 위한 색인’ 정도로 뜻만 보면 이해가 되지만그걸 어떻게 쿼리로 구현할지는 늘 헷갈렸을 때죠인덱스와 정면 대결할 수밖에 없었습니다그랬더니 의외로 제가 DB와 쿼리 작성을 어렵게 생각하고 있었다는 걸 알게 됐습니다혼란스러웠던 인덱스를 이해하고 났더니 나머지 것을 대할 때도 자신감이 붙었습니다.
 
인덱스를 접근했던 방식이 궁금한대요.
계속 고민하고 있었는데어느 순간 인덱스는 논리적 분류라는 생각이 떠오르더군요특별할 것 없는 그 생각이 인덱스를 풀어내는 실마리가 됐어요물리적 분류는 동시에 하나만 가능한 분류이지만인덱스처럼 논리적 분류는 다양한 분류가 가능한 거죠방송국에서 음반을 관리할 때를 한번 떠올려 보세요. PD마다 원하는 곡을 제각각 분류하기를 바랄 겁니다그걸 쉽게 가능하게 한 것이 인덱스즉 논리적 분류라고 볼 수 있어요
 
DB는 매우 정교하고 논리적이라서 부담스럽게 여겨집니다.
그럴 수도 있지요저도 아직 부족하지만개발을 할 때나 DB를 운영할 정도의 (DB) 실력을 목표로 한다면상식 선에서 접근할 필요가 있다고 봅니다공식이나 이론으로 접근하면 오히려 어려워질 수 있다는 걸 경험했습니다개발자들 대상의 사내 DB 교육을 할 때면처음에는 긴장하는 모습입니다이때 질문 하나를 합니다어머니가 시장에서 1kg짜리 밀가루 한 포와 두부 한 모를 사오라고 하면어떻게 하겠냐하고 질문합니다바로 가벼운 두부 한 모를 먼저 사고 무거운 밀가루를 나중에 사서 가져온다고 답합니다여기서부터 하나씩 쿼리 작성 노하우를 공유하면대부분 공감하더라고요
 
상식이라는 단어에 거부감이 들 사람도 있을 거 같습니다.
도움을 드리기 위해 드리는 경험담이니 이해주지 않을까요(웃음). 알수록 DB는 대부분 물리적 세상에 이뤄지는 일들을 논리적으로 구현한 거구나 하는 생각이 들었습니다그 과정은 쉽지 않은 게 사실이지만요적어도 받아들이는 입장에서는 경험과 상식을 동원해 받아들일 필요가 있다고 봤습니다
 
공감이라는 표현을 이해로 받아들이면 될까요.
머리로 받아들이면 금방 잊어버리거나 실제 코딩 시 헷갈립니다하지만 마음으로 받아 들이면 처음에는 조금 어렵더라도 나중에는 터득하게 된다고 봅니다.
 
그래서 첫 회에 개발자에게는 다소 낯설 수 있는 PCTREE 파라미터를 소개한 거군요.
질문한 그대로입니다이 책의 첫 회에 소개한 PCTFREE/ PCTUSED 파라미터를 봤더니 우리 생활 주변에서 볼 수 있는 물탱크 구조와 너무 닮았다는 생각이 들었습니다군대에서 경험했던 물탱크 원리가 바로 떠올랐습니다물이 넘치거나 부족하면 센서를 통해 자동으로 보충하기도 하고 잠그는 것처럼 DB도 작동합니다하지만 그게 말처럼 간단하지는 않아요중간에 센서 오류 등이 발생하죠. DB에도 마찬가지로 단순한 개념이지만다양한 변수가 있음을 염두에 두고 개발된 거죠이름만 들어도 금방 알 수 있는 유명 DBMS가 바로 다양한 상황을 염두에 둔 제품들이라고 할 수 있어요.
 

[그림 1] 물 탱크 구조 비유를 통한 PCTREE/PCTUSED 설명

책을 써야겠다고 생각했던 계기가 있었을 거 같습니다.
우연한 계기로 사내 개발자 한 분이 데이터 포털인 DBGuide.net에 연재해 보면 좋겠다고 추천한것이 계기가 됐습니다
 
그렇다면 사내에서 유명했다는 말인데요.
개발자로서 제가 고생했던 경험을 꾸밈없이 얘기했더니 공감을 얻었나 봅니다.
 
어디에서 일했나요.
생명보험사에서 DBA로서 IOA 업무를 주로 했습니다. IOA란 데이터 인풋/아웃풋 관리업무 정도로 이해할 수 있습니다.
 
DBA로 활동하면서 개발자로 일했을 때 경험을 자주 떠올렸을 거 같습니다.
저는 개발자 시절에 인덱스를 어렵게 생각했는데 다른 개발자들도 마찬가지더라고요큰 회사의 IT 조직에서 DBA로 일했으므로 수많은 개발자들과 만났죠얘기를 하다 보니 (인덱스를모르거나 알더라도 자신 없어 하는 개발자들이 의외로 많더라고요그래서 사내 개발자들을 대상으로 제 인덱스 접근 방법을 소개하는 자리를 가졌는데 반응이 꽤 좋았어요몇 회에 걸쳐 강의를 하면서 간단한 자료집으로 만들었는데 외부로 소문이 났나 봐요그게 계기가 돼 글까지 쓰게 됐습니다글을 써본 경험이 없어서 처음에는 망설여졌지만강의할 때처럼 있는 그대로 담담하게 소개했던 것이 좋게 받아들여졌나 봅니다.
 
개발자들은 DB 측면에서 어떤 고민을 갖고 있던가요.
우선 제 경우만 보더라도 개발 현장에서 10년 넘게 일했는데도 누가 쿼리 작성 노하우를 가르쳐 주는 경우가 별로 없었습니다그래서 습관적으로 쿼리 프로그래밍을 했습니다책도 사보고 여러 블로그를 참고하기도 했는데 실무와는 먼 이론 위주였던 게 아쉬웠습니다. 하지만 DBA 업무를 하면서 DB의 특성을 파악하고 나니까 이런 게 있었는데 왜 알려주지 않았을까? 하는 생각이 들더라고요. 노하우는 알고 나면 너무나 당연한 건데도 몰랐을 때는 사람을 위축시키기도 합니다.

하지만 DBA 업무를 하면서 DB의 특성을 파악하고 나니까 이런 게 있었는데 왜 알려주지 않았을까? 하는 생각이 들더라고요. 노하우는 알고 나면 너무나 당연한 건데도 몰랐을 때는 사람을 위축시키기도 합니다.

 
책에 매우 다양한 얘깃거리가 들어있다는 게 놀라웠습니다.
데이터 지식포털인 DBguide.net에 40회 정도 연재했는데 그때마다 글 시작 지점이 어려웠어요뭔가 공감이 갈 만한 얘깃거리를 제시했어야 했기 때문입니다그걸 찾으려고 몇 날 며칠 고민하기도 했습니다결국은 제가 지금까지 경험하고 느껴왔던 것을 얘기할 수밖에 없었습니다군대 얘기고향 얘기아이들 얘기가 그 겁니다글을 쓰다가 잘 모르는 분야예를 들면 마방진 등에 대해 소개할 때는 별도로 공부도 했고요.
 
이야기를 앞세운 이유라도 있었나요.
처음에는 한두 회 써서 반응이 없으면 글방 잘리지 않을까’ 생각했죠어렵게 결정한 일이니 한번 잘해보고 싶다는 욕심이 들더군요당연히 나름대로 전략을 세웠죠글의 시작 부분에서 독자들의 마음을 열어 놓아야겠다고 생각했죠첫 회가 나갔는데 반응이 괜찮았어요포털 담당자가 반응이 좋다고 격려해 줘서 계속 힘을 낼 수 있었습니다.
 
책 제목에서 노하우라는 단어가 눈길을 끌더군요.
이 책이 기반이 되는 첫 번째 글을 썼을 때부터 노하우라는 단어를 염두에 뒀습니다앞서 간단히 소개했지만나중에 알고 나면 아무것도 아닌데 몰랐을 때는 사람을 움츠러들게 하는 것이 노하우이기 때문이죠
 
개발자들 가운데는 쿼리 작성은 단순한 일이라고 생각하는 경우도 있었습니다.
SQL은 언어 측면에서 보면 단순한 편이죠단순하지만 잘 써야 원하는 DB 성능을 낼 수 있습니다원하는 만큼의 성능이 나오지 않거나 문제마저 야기한다면 당장 필요한 것은 무엇일까요이런 개발자에게는 DB의 원리와 개념은 아닐 것입니다. DB 성능을 좌우하는 인덱스와 분명한 실행계획(plan)을 적용하는 방법을 알아 둘 필요가 있습니다그래서 이론부터 강조하지 않았습니다우리 주변에서 흔히 접할 수 있는 일을 예로 들어서 설명하면서 상식선에서 DB를 잘 활용할 수 있고 나아가 성능까지 끌어올릴 수 있다고 봤습니다그래서 내용이 어렵지 않습니다하지만 다 읽고 나면데이터 모델링 이론에서 강조하는 엔터티 설계 개념까지 자신도 모르게 습득하게 될 겁니다.
 
 
 

쉽게 설명하지 못하는 이유는 그것에 대해 제대로 알고 있지 못하기 때문이다. _아인슈타인

 
 
 
DB 성능을 끌어올리는 튜닝 책이라고 볼 수 있네요
그럴 수도 있고 그렇지 않을 수도 있습니다튜닝이라는 말이 너무나 폭넓게 사용되는 거 같아서요튜닝은 개발 프로세스 단계로 보면 사후 접근 개념이라고 할 수 있는데요개발 생산성과 관리성을 높이려면 사전 튜닝즉 개발자 측면에서부터 튜닝을 해야 한다고 보기 때문에 튜닝이라는 말을 앞세우지 않았습니다물론 DBA나 DB 튜너 입장에서 보면 튜닝 책이라고 볼 수 있습니다분명한 것은 개발자를 포함해 DB 전문가들이 튜닝을 잘하게 하는 책입니다이 책은 튜닝이라는 말 대신에인덱스를 제대로 이해하여 공정쿼리’ 즉 쿼리를 제대로 짜면 저절로 성능과 관리성을 끌어올리는 노하우를 소개합니다. DB 튜닝이라는 말을 하지 않고도 튜닝을 한 셈이죠
 
개발자 입장에서 간절함이 묻어나더라고요.
누구나 유독 받아들이기 힘들었던 것들이 한두 개씩은 있었을 것입니다알고 나면 아무것도 아니었는데도요 하지만 골칫거리 같던 존재가 우연한 계기로 너무나 쉽게 풀렸던 경험 또한 갖고 있을 것입니다자신에게 딱 맞는 책을 만났거나 귀에 쏙쏙 들어오게 설명해주는 동료나 선생님이 그 역할을 했을 수도 있습니다이 책이 SQL DB를 제대로 배우고 싶은 개발자와 여러분에게 또 한번의 그런 해결의 경험을 드릴 수 있기를 바랍니다. ()

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다