프로시저 vs SQL

이전 글에도 쓴적이 있지만 없다면 할 수 없겠지만 있다면 가능하면 이용하자는 주의여서 DB의 프로시저도 적극적으로 활용한다. 물론 DB의 다른 기능들도 마찬가지로 주의깊게 살펴보면서 가능하면 사용하려고 노력하는 편이다.

보통의 경우 프로시저라 함은 IF ELSE나 FOR 등의 구문이 섞여서, 절차형 패러다임의  SQL 스파게티로 오해하는 경향이 있는데 여기서는 그냥 간단한 SQL이 프로시저 형태로 저장되는 것으로 한정해서 말하기로 한다.

프로시저가 일반 SQL에 비해서 가지는 장점은 여러가지가 있다.

가장 대표적으로 성능의 경우 저장프로시저는 쿼리 실행계획을 메모리에 저장하여 저장된 실행계획을 사용하기 때문에 구문 분석이나 최적화 과정을 반복하지 않기 때문에 빠른 실행을 할수 있고 설사 캐시에 없더라도 표준화 등의 작업을 하지 않기에 좀더 빠르다. 이 차이는 쿼리의 전체 속도의 부분이기 때문에 상황에 따라 조금 다르긴 하지만 대부분의 OLTP에서의 0.1s 미만의 쿼리의 경우 체감적으로는 50-100% 정도의 차이가 있다. (일반 Statement의 SQL이라도 자주 실행되는 구문이라면 역시 마찬가지로 실행계획의 재사용이 되지만 조금 차이가 있다.)

그밖에도 긴양의 SQL이나 2번 보내는 대신 프로시저명만 보내면 되기 때문에 네트워크 전송속도에도 미묘한 향상이 있다.

두번째의 이유로는 보안이 강화된다는 장점이 있다. 저장 프로시저를 사용하면 특정 종류의 SQL 인젝션 공격(특히 AND나 OR등의 연산자를 사용해 유효한 입력 매개 변수 값에 명령을 추가하는 공격)을 저지할 수 있고 프로그램이 사용하는 로그인 아이디에 테이블등에 직접 권한을 주지않고 프로시저 실행권한만을 주는 간접적인 보안계층을 관리할 수 있으므로서 생기는 프로그램 손상가능성을 줄여주는 장점도 있다.

그밖에도 몇가지 세세한 장점에 대해 얘기할 수 있지만 이는 인터넷 조금만 찾아보면 나오는 얘기이니 대충 생략하기로 하자. 사실 나는 이러한 장점이 중요하다고 생각하지 않는다. 정치학의 기본적인 원리중 하나는 아무리 변화가 필요하고 중요하다는 이성적 확신이 있더라도 개인과 조직의 문화는 변화를 거부하기 때문에 이러한 이유로 프로시저를 사용하는 이유에 대한 동의를 이끌어내기 힘들다는걸 여러번 절감해 왔다.


개인적으로 프로시저의 진정한 장점은 위와 같은 수치적인 측면이 아니라 다른 점에 있다고 생각한다.

그 이유중 하나로 컴파일의 문제를 들 수 있다. 초등학생 시절 베이직 언어를 배웠던 시절을 생각해보면 1000라인 이상의 프로그램을 짜는게 무척 힘들었었다. 물론 실력이 미숙하기도 하고 베이직의 구조적 한계의 문제도 있겠지만 되돌아보면 베이직이 컴파일이 되지 않는 인터프리터인 이유도 컸다고 생각한다. 컴파일 과정이 없이 매번 실행시켜서 그닥 도움이 되지 않는 에러 메시지로 버그의 원인을 찾는 과정은 고통스러웠고 찾았을때 기쁘기도 했지만 지금 생각해보면 시간낭비에 가깝다.

프로그램의 String이 아니라 저장 프로시저 형태로 저장되었을때 이러한 단순한 코딩 실수 방지 뿐 아니라 보다 장기적인 유지보수적인 장점이 있다. DB의 스키마 등은 변경되지 않는 것이 이상적이지만 현실적으로는 프로그램의 생명주기동안 계속 변경이 발생한다. 컬럼 정보같은 변경(추가/삭제/수정) 변경이 발생했을때 프로시저는 의존관계를 훨씬 더 정확하게 확인할 수 있고 동시에 검사와 테스트가 가능하다는 장점이 있다. 그리고 일반적으로 저장 프로시저를 변경하는 방법이 코드의 수정, 테스트, 배포를 다시하는 것보다는 시간과 노력을 절약할 수 있다.


두번째의 잘 알려지지 않는 장점중의 하나는 추상화에 있다. 다른 글에도 언급한적이 있지만 나는 SQL 구문자체가 비즈니스 로직이라고 생각하지 않는다. (아주 복잡한 로직이 결합된 프로시저는 앞에서 제외한다고 말하였다.) 오히려 클라이언트 로직 입장에서 본다면 viewArticle이라는 프로시저명만으로 충분하지 세세한 SQL이나 어떤 테이블을 참조하는 지에 대한 정보는 오히려 번거롭기만 하다.

예컨데 위의 viewArticle의 경우 조회수의 증가와 해당 Article의 정보 2가지의 결합이다. 하지만 클라이언트 로직 입장에서 본다면 viewArticle의 세부 과정이 2단계이든 3단계이든 굳이 알 필요가 없다고 생각하고 그럴경우 update문 하나와 select 문을 하나 던지는 로직보다 그냥 viewArticle이라는 프로시저를 실행하면 된다고 생각하는게 도움이 된다. 즉 좀더 추상화를 잘 활용하게 된다.



위의 장점에도 불구하고 저장 프로시저의 단점이 있다면 숙련된 전문가가 필요하다는 점이다. 개발자가 프로시저를 숙련되게 사용할 수 있다면 더할 나위 없지만 그렇지 않다면 일방적으로 DBA에게 위임하는 것보다 차라리 교육을 통해 개발자가 관련 지식을 습득하는 방법이 낫다고 생각한다. A분야의 전문가와 B분야의 전문가 협력하는 식의 방법이 겉으로 보이기에는 멋져보일지 모르지만 실제 커뮤니케이션에는 대부분의 엔트로피 손실로 오랫동안 팀을 이룬게 아니라면 오히려 부정적이다.