저장 프로시저 vs 인라인 쿼리

 프로젝트를 뛰다보면 인라인 쿼리를 쓰는 사람도 있고, 저장 프로시저를 쓰는 사람이 있는데, 저는 SQL서버를 많이 사용하며, 저장 프로시저를 선호하는 편입니다. 물론 저장 프로시저는 소스 관리(SVN, GIT) 같은 소스 관리를 하지 못한다는 단점이 있긴하나, 이것을 보안하는 부분은 백업 및 2중 관리(귀찮긴하나 회사에서는 대부분 이렇게 쓰고 있습니다.)로 보완 할 수 있는 부분입니다. 아래는 SQL Sever에서 저장 프로시저를 사용하였을 때 장점을 적어보았습니다.

1. 미리 구분 분석 - 인라인 쿼리는 실행을 하면 틀린 구문을 찾아주지만, 저장 프로시저는 실행하기 전 구문분석을 해줍니다.

2. 쿼리 실행 계획 - 프로시저가 실행 될 때 SQL Server는 재사용을 위해 캐시되는 "실행 계획"을 만듭니다. 즉 자주쓰는 쿼리 같은 경우에는 속도가 더 빠릅니다. 하지만, 이 부분은 너무 복잡한 쿼리에는 속도가 더 저하될 수 있다는 점 참고하셔야합니다. 단순하고 JOIN 이 적은 쿼리에는 더 효과적입니다.

3. 네트워크 트래픽 감소 - 네트워크를 통해 SQL문을 보내기 때문에 저장 프로시저를 사용하면 SQL을 일괄적으로 실행할 수 있어서 비교적 네트워크 트래픽이 감소 합니다.

4. 권한 - 따로 각각의 저장 프로시저마다 권한을 줄 수 있습니다. 프로젝트를 하다가보면 인터페이스를 할 경우가 있는데, 대부분REST API로 할 것 같지만, 뷰를 열어주거나 특정 쿼리만 열어주는 경우도 간혹 있습니다. 이럴때 계정을 따로 생성하여, 권한을 따로 주는 작업을 하는 경우가 있습니다.

5. 재 컴파일 없이 편집 가능 - 소스는 수정하려면 재 배포가 필요해서 모든 기능에 다시 시작이 필요 할 수 있지만, 저장 프로시저는 일부분만 수정이 가능합니다. 빠르게 수정이 필요할 경우 많이 쓰입니다.

6. 최적화 - 앞에서 말했던 쿼리 실행계획이 누락된 인덱스를 찾아 주기도 합니다. 물론 완벽하지는 않은 기능이지만 마이너한 쿼리는 잘 찾아주는 편 입니다.

7. SQL Injection attacks - 적절하게 작성된 인라인 쿼리는 공격을 방어할 수 있지만 이러한 보호에는 저장 프로시저가 더 좋습니다. 사실 보안때문에 저장 프로시저를 쓰는 것도 있다. 파라미터로 받아야하기 때문에 보안에 더욱 적절하게 방어가 된다.