<SQL 개발 가이드 – 어떻게 지킬 것인가?>
SQL BOOSTER 본서 Chapter. 11에는 ‘SQL 개발 가이드’가 실려있다. Chapter. 11의 목차를 살펴보면 다음과 같다.
11.1 WHERE 절 가이드
11.1.1 WHERE 절의 컬럼은 변형하지 않는다
11.1.2 날짜 조건 처리하기
11.1.3 조건 값은 컬럼과 같은 자료형을 사용한다
11.1.4 NOT IN 보다는 IN을 사용한다
11.1.5 불필요한 LIKE는 제거하자
11.2 불필요한 부분 제거하기
11.2.1 불필요한 COUNT는 하지 않는다
11.2.2 COUNT에 불필요한 부분은 제거한다
11.2.3 불필요한 컬럼은 사용하지 않는다
11.2.4 동일 테이블의 반복 서브쿼리를 제거하자
11.3 생각의 전환
11.3.1 사용자 함수 사용의 최소화
11.3.2 작업량을 줄이자
11.3.3 집계 테이블을 고민하자
실제 프로젝트에서는 이 보다 더 많은 내용이 SQL 개발 가이드로 구성된다. (위 목차 중에 11.3.2와 11.3.3은 SQL 개발 가이드에 포함 할지 많은 고민이 있었다. 별도의 Chapter로 구성하기에는 내용이 짧고 가이드에 포함시켜도 큰 무리가 없다 생각되어 가이드에 포함했다.)
SQL BOOSTER 에 이어지는 이야기들입니다.~!
SQL BOOSTER 를 보신 분들께 좀 더 도움을 드리고자 추가로 작성한 내용입니다.
www.aladin.co.kr/shop/wproduct.aspx?ItemId=216383877
SQL BOOSTER
프로젝트 성공을 위한 SQL 필독서. 프로젝트를 진행하는 순서처럼 구성되어 있다. 프로젝트 투입을 위해 필요한 SQL 기술을 설명하고, 성능 테스트를 위해 필요한 기술을 설명한 뒤에 마지막으로
www.aladin.co.kr
설명의 편의상 반말체로 작성한 점 양해바랍니다. pdf 파일도 첨부드리니 다운 받아 보셔도 됩니다.
이와 같은 ‘SQL 개발 가이드’는 프로젝트에 따라 있기도 하고 없기도 하다. 이러한 가이드가 존재한다는 것은 개발 PM이나 운영 팀장이 SQL의 중요성을 인식하고 있다는 뜻으로 해석할 수 있다. 그리고 SQL 개발 가이드의 내용과 상세도에 따라 인식의 깊이도 다르다 해석할 수 있다.
필자 개인적으로는 ‘SQL 개발 가이드’는 매우 중요하다 생각한다. 개발의 품질을 높일 수 있으며, SQL 성능을 어느 정도 보장할 수 있기 때문이다.
오늘은 ‘SQL 개발 가이드’를 만들고 사용했던 필자의 경험을 이야기하려 한다.
(1) ‘SQL 개발 가이드’를 만드는 방법
SQL 개발 가이드는 쉽고 필수적인 내용부터 시작해서 작성한다. 필자는 보통 파워포인트를 이용해 SQL 개발 가이드를 만든다. 예를 들어 아래 그림과 같이 SQL 개발 가이드를 만든다.
왼쪽에는 잘 못된 방법, 오른쪽에는 올바른 방법을 담는다. 개발 초기에는 보통 10장 내외의 가이드를 작성한다. 자세하고 많은 내용을 담기보다는 꼭 필요하고 빠르게 개발자들에게 전달할 수 있는 내용을 담아서 작성한다.
개발 가이드에는 실제 프로젝트의 테이블을 사용하는 것이 좋다. 예를 들어, 병원 시스템 개발 프로젝트라면 진료, 접수 등의 테이블을 사용해 가이드를 작성하는 것이 효과적이다.
(2) 운영팀의 SQL 개발 가이드
필자는 중국에서 오랜 시간 운영팀으로 일을 해왔다. 운영팀이었지만 개발도 많이 하는 팀이었다. 대부분의 시스템을 우리 팀이 직접 설계하고 개발했다. 많은 사람들이 ‘운영팀이야? 개발팀이야?’ 말하기 일수였다. 2004년도에 우리 팀은 4명에 불과했다. 팀장겸 설계자 한 명, 자바 개발자 두 명, 디비를 담당하는 필자 한 명, 이렇게 4명이었다. 중국의 경제가 성장하면서 우리가 일했던 회사도 성장해 나갔으며 이에 따라 개발할 거리가 점점 늘어났다. 4명으로 시작한 우리 팀은 어느덧 28명까지 늘어났다. 팀원이 늘어나면서 SQL 작성 방법도 점점 다양해졌다. 뿐만 아니라, SQL로 인한 사고도 점점 늘어나게 되었다. 잘 못된 SQL을 반영해 시스템에 부하가 발생하거나, 잘 못된 데이터가 생성되거나 조회되기도 했다. 운영 업무 중에는 현업의 VOC(Voice of Customer)를 받아 데이터를 보정하는 일도 있다. VOC 처리 중에 SQL을 잘 못 작성해 데이터를 날리는 경우도 있었다.
이와 같은 사고와 SQL의 다양성을 방지하기 위해 SQL 개발 가이드를 만들고 개발자에게 공지했다. 하지만 가이드가 있다고 해서, 모두 가이드를 지키는 것은 아니다. 다양한 상황이 있기 때문에 가이드를 벗어나는 SQL들이 생기게 되어 있고, 개발 일정에 따라 가이드를 따르지 못하는 경우도 있다. 또한 가이드가 모든 상황을 제시해 줄 수도 없다. 실제 개발에서는 그만큼 다양한 SQL들이 만들어지기 때문이다.
가이드를 만들고 공지하는 것은 전혀 어려운 일이 아니다. 가이드를 지키는 것이 더욱 중요하고 어려운 일이다. 필자의 운영팀에서는 아래와 같은 프로세스로 가이드를 지키도록 했다.
개발자가 SQL을 개발한 후에 SQL 검수자에게 확인을 받은 후 반영하는 절차다. 검수 과정에서는 SQL 개발 가이드를 준수 했는지와 성능에 문제 없는지도 확인하도록 한다. 검수라는 말이 딱딱할 수 있다. 그냥 한 번 더 확인하는 절차 정도다. 필자의 운영팀에서는 필자가 SQL 검수를 맡아서 진행했다. 이러한 역할은 DA(Data Architecture)가 할 수도 있으며, DBA가 할 수도 있다. 또는 SQL을 제일 잘하는 개발자가 맡을 수도 있다. 팀의 상황에 따라 적절히 안배하면 된다. 위와 같은 프로세스는 개발할 양이 많지 않을 때는 큰 문제가 없다. 하지만 개발할 양이 많으면 SQL 검수 과정에 병목이 생겨 전체적으로 프로젝트를 지연 시킬 수 있다. 결과적으로 필자의 일거리가 너무 많아져 감당할 수 없는 상황이었다. 결국 아래와 같은 절차로 변경했다.
업무별로 작은 개발팀을 만들고, 그 안에서 SQL을 제일 잘 다루는 개발자를 선정해 SQL 검수를 진행하도록 했다. 상급 개발자들에게는 SQL 개발 가이드를 자세히 설명해주었다. 만약에 SQL에 성능에 이상이 있거나, 가이드 준수가 어렵다면 DA에게 검수를 추가 요청하도록 했다. 이외에도 분기별 개발자 평가에 SQL 개발 가이드에 대한 평가도 포함해서 진행했다.
운영팀의 특성상 개발 과정보다는 VOC 처리에서 더 많은 사고가 발생한다. VOC처리 SQL은 아래와 같은 절차를 사용했다.
운영 환경에서 SQL을 실행할 때는 개발자와 상급 개발자가 모두 참가해서 실행하도록 했다. 이 과정이 특히 중요하다. 대부분 VOC UPDATE, DELETE 사고는 조건절을 빼먹고 급하게 실행할 때 발생한다. 한 명이 단계별로 실행하고, 실행 과정을 누군가가 지켜보면서 조건절에 실수는 없는지 다시 한번 확인하도록 하는 것이다. 또한 DBMS나 DBMS 툴에 따라 AUTOCOMMIT을 사용하는 경우에는 각별한 주의가 필요하다. VOC UPDATE, DELETE는 무조건 AUTOCOMMIT을 OFF하고 사용하도록 해야 한다. 그러므로 필자가 운영팀에서 사용했던 SQL 가이드에는 아래와 같은 내용도 있었다. 참고하기 바란다.
대상을 백업 할 때는, VOC를 처리한 개발자 이름의 약자(LTW)와 VOC ID를 사용하도록 한다. 이 후 추적이 용이하다. 최종, COMMIT을 하기 전에는 백업한 건수와 UPDATE나 DELETE 된 건수가 같을 때만 UPDATE 처리하도록 한다.
(3) 개발팀의 SQL 개발 가이드
개발팀의 SQL 개발 가이드는 운영팀의 개발 가이드보다 좀 더 빠르게 만들어질 필요가 있다. 개발을 시작하기 전에 가이드가 만들어지고 공유되어야 한다. 개발 중간에 SQL 개발 가이드가 만들어지면 개발자들이 만들었던 SQL을 다시 손봐야 하는 공수가 추가된다.
SQL 개발 가이드를 만들 때부터 모든 내용을 담을 수는 없다. ‘SQL BOOSTER’ Chapter. 11의 목차 정도와 페이징 SQL 정도만 포함해도 된다. 그리고 프로젝트에서 중요하게 생각되는 부분 몇 가지를 추가하면 된다. 빨리 만들어 개발자들에게 공지하고 개발을 하면서 조금씩 확장해 나가도록 한다.
개발팀의 SQL 개발 가이드에는 프로젝트에서 실제 사용하는 테이블을 예제로 담는 것이 좋다. 가이드이해에도 도움이 되며, 개발자들이 잘 못된 방법과 맞는 방법을 직접 실행해보고 느낄 수 있기 때문이다.
개발 프로젝트에는 많은 인원들이 모여서, 많은 개발을 빠르게 진행하게 된다. 그러므로 SQL 가이드에 추가할 항목도 생각보다 빠르게 늘어난다. 이 때마다, 가이드를 꾸준히 업데이트하고 공지해야 한다.
개발 프로젝트에서 가장 큰 문제는 SQL 개발 가이드를 지키게 하는 것이다. 운영팀처럼 오랫동안 호흡을 맞춘 인원이 아닌, 새롭게 구성된 팀이기 때문이다. 그러므로 개발 프로젝트에서 SQL 개발 가이드를 지키게 하려면 개발 PM과 개발을 인수인계 받을 운영팀의 노력이 필요하다. 개발 PM은 SQL 개발 가이드를 꼭 준수하도록 강조를 하고, 개발 PL들을 통해 SQL 품질을 중간 중간 확인해야 한다. 그리고 운영팀은 가이드를 준수한 SQL들만 인수인계 받을 것을 처음부터 협의해 놓을 필요가 있다. 물론 모든 SQL을 표준화 시키고 가이드를 지킬 수는 없다. 최대한 지키도록 협의를 하는 것이다.
또 다른 문제는 ‘SQL 개발 가이드를 누가 만들 것인가?’이다. SQL 경험이 풍부한 사람이 만드는 것이 제일 좋다. 가능하면 튜닝을 아는 사람이 하는 것이 좋다. SQL 작성법은 성능과 밀접한 관련이 있기 때문이다. 만약에 SQL 개발 가이드를 작성할 사람이 없다면, 이 글을 읽고 있는 독자 자신이 ‘SQL BOOSTER’의 내용을 참고해서 정리해보기 바란다. 내용의 품질과 맞고 틀림보다는, SQL 개발 가이드 존재 자체가 개발 품질에 더 큰 도움이 되기 때문이다. 가이드의 품질은 점차 올리면 되고, 잘 못된 내용은 고쳐나가면 된다.
오늘 글은 여기까지입니다. 시간이 된다면, ‘SQL 개발 가이드’ PPT를 간단하게 만들어 올려보도록 하겠습니다. 작은 개발 사이트들에 도움이 되지 않을까 생각이 드네요. 감사합니다.