내가 만든 악성 쿼리가 발견되는 바람에 오랜만에 데이터베이스를 만져볼 기회가 생겼다. 서비스 오픈 전엔 데이터가 그리 많지 않아 놓쳤던 것이 오픈베타를 거치면서 문제가 드러나게 됐다. 데이터베이스를 공부해보면 알겠지만, 데이터의 양과 질(또는 통계 및 분포)에 따라 그때그때 튜닝을 해야 한다. 그래서 이 정도면 되겠지?
하고 안심해선 안 되고 자주 들여다보고 이상이 없는지 확인해야 한다. 프로그래머가 새로운 프로그래밍 언어와 기술에 열광할 때, 데이터베이스 관리자는 어쩌면 지루해지기 쉬운 그런 일을 묵묵히 해나가야 한다. 그렇게 훈련과 규율이 요구되는 직종이기 때문에 데이터베이스 관리자는 전산 분야에서 평균 연봉이 가장 높은 직책 중 하나다.
그러나 데이터베이스 관리자 또는 데이터베이스 팀은 보통 사내에서 가장 보수적이며 의견교환이 힘든 조직으로 손꼽힌다. 적어도 소프트웨어 개발사라면 그렇다. 이는 업무의 성격이 반영된 것이기도 하다. 일반적으로 프로그램 하나가 오작동을 일으키면 그 파급이 멀리 가진 않는다. 하지만 여러 대의 프로그램이 보통 하나의 데이터베이스를 공유하기 때문에, 데이터베이스가 느려지거나 먹통이 되면 문제는 심각해지기 마련이다. 그런 까닭에 데이터베이스의 관리를 책임지는 조직은 신중해질 수밖에 없다. 오히려 그렇지 않다면 문제가 클 것이다.
하지만 이 모든 점을 고려하더라도 데이터베이스 팀과 일하려면 답답할 때가 많은 것이 사실이다. 특히 데이터베이스의 세계엔 미신이 많아서(프로그래밍 분야도 그리 다르진 않겠지만), 특정 기술은 무조건 안 된다는 답변을 들을 때가 많다. 뷰는 안 되요. 분산 쿼리는 안 되요. 복제는 안 되요. 이 외에도 헤아릴 수 없이 많은 미신이 있고, 아마도 내가 들은 것은 극히 일부에 불과할 것이다.
사실 이런 미신은 저마다 연유가 있다. 이를테면 분산 쿼리가 느리다는 말을 여러 차례 들었는데, 해당 데이터베이스 관리자에게 물어보니 각자 한번씩은 분산 쿼리를 시도해본 적 있었다. 하지만 알고 보면 대부분 관리자의 실수가 원인이었다. 제일 흔한 실수는 데이터 정렬 속성값을 엉뚱하게 구성한 경우였다. 특정 데이터베이스의 특정 테이블의 특정 칼럼에만 인덱스가 빠진 경우도 있었다. 심지어 분산 쿼리를 구성하는 데이터베이스 중 하나가 지방에 있어서 응답이 느렸던 사례도 있었다.
사람은 누구나 실수한다. 내가 하루에 양산해내는 버그 수를 정확히 계산해본 적은 없지만 분명 적진 않으리라 확신한다. 신중하게 생각하고 테스트까지 만들어도 이슈 보고는 끊이지 않는다. 하지만 문제가 있으면 원인은 알아야 하지 않을까? 분산 쿼리가 느리다면 왜 느릴까?
라고 고민은 해봐야 한다. 구글링만 했어도 무지는 오래가지 않을 것이다.
그런데 이런 기본적인 확인 작업을 게을리 하는 DB 조직이 의외로 많다. 데이터베이스의 특성을 고려할 때, DB 팀이 프로그래밍 팀만큼 역동적으로 움직이기는 힘들다. 하지만 왜 안 되는지 이유를 알고 싶습니다
라고 프로그래머가 물어보면 타당한 사유를 제시할 수는 있어야 하지 않을까? 팀장님이 무조건 안 된다고 하십니다
같은 건 답변이 아니다. 그런 말을 내뱉을 때 당신은 공학이 아닌 정치를 하는 것이다. 적어도 기술로 생계를 이어가는 데이터베이스 관리자라면 정원혁씨의 태도를 본받야 한다. 입보단 숫자가 앞서야 신뢰를 얻을 수 있다.
이런 조직의 폐해는 참 말도 못한다. 쿼리 타임아웃 값을 짧게 해놔서 성능 문제를 사전에 예방했다라고 착각하는 사람도 많은데, 만약 건전한 비판 정신이 살아있는 조직이라면 일시적인 문제에 불과할테지만, 그렇지 않으면 언젠가 한번 쓴맛을 보게 될지 모른다.
이러한 폐쇄성의 진정한 무서움은 그 댓가를 소프트웨어 개발 조직 전체가 짊어져야 한다는 점이다. 어떤 지침을 맹목적으로 따르고, 행여나 문제가 생기면 그 책임을 떠맡을까 전전긍긍하는 바람에 프로젝트의 성공이나 사업의 성공은 뒤로 밀려난다. 전체 최적화보단 부분 최적화에 앞장서는 전형적인 태도다. 하지만 서로 지식을 공유하고 토론하기 보단 기존 정책을 통보하고 마는 태도로는 자신들이 받는 월급이나 권위를 도저히 정당화할 수 없다는 사실을 알아야 한다.
제목을 자극적으로 짓긴 했지만, 이런 비판이 비단 데이터베이스 조직에만 해당하는 건 절대 아니다. 이야기가 안 통하는 개발자나 기획자는 세상에 널렸다. 과거의 성공을 무기로 내세우거나 ~카더라라며 신뢰하기 힘든 권위를 빌리는 경우가 숱하게 목격된다. 톰 디마르코와 티모시 리스터가 오래 전에 제시한 통계에 따르면 자기가 일하는 분야의 책을 단 한권도 사지도, 읽지도 않는 개발자가 널린 세상이니 말이다.
정치적인 측면에서 봤을 때 꼴통이란 표현은 더이상 타협을 허용하지 않는 극단적인 말이다. 누가 꼴통과 말을 섞으려 하겠는가? 그래서 이 말이 여러 사람의 입에서 자주 오르내리는 현상이 불안하다. 하지만 기술 분야에서, 많은 사람이 믿고 의지하는 그런 일을 하는 이라면 당연히 스스로 꼴통되어 가는 건 아닌지 심각히 고민해볼 일이다.
프로그래머와 DB팀 사이에 그런 역학관계가 있군요. 재밌네요. 컴퓨터 업계는 아는 게 없는 데 덕분에 많이 배웁니다.
사실 프로그래머 팀와 DB 팀 사이엔 이런 일이 비일비재 하지요. 한데 따지고 보면 경직된 조직이라면 다 그런 것 같습니다. 영업이든, 기술이든.
좋은 글 항상 감사히 읽고 있습니다. 댓글은 잘 안 남기는 편인데 고마운 마음은 전해야 겠어서 남겨요. 도움이 많이 되고 있어요.
까칠한 글인데 긍정적으로 받아들여주시니 감사합니다.
글쵸? 외국 회사도 마찬가지예용. 워낙에 다루는 데이타들이 많다보니 디비팀이 좀 까칠하지요. ^^ 처음엔 이해가 좀 안갔는데, 그게 맞는것 같긴 해용.
그래도 아예 무조건 안된다기 보다는 이러이러한 폴리시 때문에 된다/안된다를 결정해 주니까, 관련해서 새로운 논의사항도 생기고 해서 그런건 좋은 것 같음.
DB 성격상 까칠한 건 어쩔 수 없겠지요. 저라도 다르지 않을 것 같습니다. 큭.
사실, “무조건” 안 된다는 사람은 “왜” 안 되는지 몰라서 그렇게 대답하는 것이예요. 한두번 겪은 것도 아니라서 되려 제가 설명해주고 권한을 따낼 때가 많았습니다. 누가 DBA인지 원……
이 글의 요지는 이를테면 ‘규칙이 있다고 무조건 따르지 말고 이유나 알고 따르자’가 되겠습니다.
완전 공감합니다. 비단 DBA만의 문제는 아닌거 같습니다. 잘못된 경험으로 인한 사실을 근거로 xx는 느려서 안된다라던가 하는 프로그래머들도 있으니까요. 하여간 내가 열심히 공부하는 수 밖에 없는 것 같아요.
넵. 미신이 난무하는 세상이니, 속지 않으려면 항상 정진해야겠습니다. ^^
컴퓨터와 인간사이의 차이 때문이라도
미신은 난무 하는 것 같습니다.
둘의 차이가 개발자 개인의 책임이라도
하나의 미신이 존재하면 마음은 편하기 때문에라도 말이져..^^;;
글 잘읽었습니다.
음… 제가 한참 신경질낼 때 쓴 글이라 까칠합니다.