[DB][MSSQL] 저장 프로시저(Stored Procedure)란?

운영 업무를 하며 '프로시저'라는 단어를 많이 접하게 되었다.

최근까지 그것을 다룰 일이 없다가,
프로시저를 수정해야 할 요청이 들어와서 본격적으로 공부하고 글을 남긴다.

SQL이 무엇인지, 쿼리는 무엇인지 등
DB에 관해 어느 정도 기초 지식이 갖춰진 상태로 읽는 것을 추천한다.

 

---

 

저장 프로시저(Stored Procedure)란?

CREATE PROCEDURE procedure_name(IN parameter) BEGIN SQL1; SQL2; END; EXECUTE procedure_name(parameter); CALL procedure_name(parameter);

위 코드의 CREATE 부터 END 까지가 저장 프로시저를 구성하는 코드이고,
하단 부의 EXECUTE 혹은 CALL 문장으로 해당 프로시저를 실행할 수 있다.

위키백과의 저장 프로시저에서는 저장 프로시저에 대해 다음과 같이 설명하고 있다.

"저장 프로시저 또는 스토어드 프로시저(stored procedure)는
일련의 쿼리를 마치 하나의 함수처럼 실행하기 위한 쿼리의 집합이다."

"데이터베이스에 대한 일련의 작업을 정리한 절차를 관계형 데이터베이스 관리 시스템에 저장한(지속성) 것으로,
영구저장모듈(Persistent Storage Module)이라고도 불린다."

간단히 말하자면, 여러 쿼리를 하나의 함수로 묶은 것이다.

(저장 프로시저의 예시도 위의 위키백과 링크에 있으므로 한 번씩 보는 것을 권장한다)

 

함수?

프로그래밍에서 함수의 의미를 정확히 알면 저장 프로시저에 대한 개념도 어느 정도 잡힐 듯 싶다.

 

위키백과의 함수(프로그래밍)에서는 함수를 아래와 같이 정의한다.

"함수(function), 서브루틴(subroutine), 루틴(routine), 메서드(method), 프로시저(procedue)는
소프트웨어에서 특정 동작을 수행하는 일정 코드 부분을 의미한다."

"하나의 큰 프로그램을 여러 부분으로 나누어주기 때문에

같은 함수를 여러 상황에서 여러 차례 호출할 수 있으며, 일부분을 수정하기 쉽다는 장점을 가진다."

어떠한 특정 기능을 수행하는 코드를 한 곳에 모아두어 원하는 때에, 원하는 횟수만큼 호출이 가능한 것이다.

 

저장 프로시저 - 장점

그럼 저장 프로시저를 사용함으로 얻게 되는 이점은 무엇일까?

 

1. 네트워크 부하 감소

보통 쿼리는 네트워크를 타고 DB에 전달된다.

 

저장 프로시저를 쓰게 된다면 단 한 번의 요청으로 여러 SQL문을 실행할 수 있으므로,

네트워크에 대한 부하를 줄일 수 있다.

 

2. 처리 시간 감소

미리 구문 분석 및 내부 중간 코드로 변환을 끝내야 하므로 처리 시간이 줄어들게 된다.

 

출처) https://itability.tistory.com/51

위의 사진을 보며 좀 더 설명을 해보자면,
저장 프로시저는 최초 실행될 때 최적화된 상태로 컴파일이 되고 이후에 DB에 캐쉬되어 저장된다.

캐쉬에 저장되었단 말은 최적화와 컴파일 작업을 다시 하지 않는다는 이야기이므로,
한 저장 프로시저가 여러 번 쓰이면 성능 향상에 도움이 된다.

 

3. 데이터 무결성 유지

애플리케이션 측에서 특정 작업을 해주지 않아도,
저장 프로시저를 수행하게 되면 DB의 데이터 앞뒤가 맞게 될 수 있다.

 

4. 편리한 유지보수 및 개발 업무와의 구분

프로그램을 개발한 사람이 운영까지 하게 된다면,
DB 관련 작업이 필요한 일이 있을 때 해당 저장 프로시저를 수정하거나 교체만 해주면 된다.

그리고 그러한 수정과 교체를 통해 DB 업데이트가 이루어지면,
WAS를 껐다 키거나 등의 추가적인 조치 없이 바로 서버에 반영되어 편리하다.

또한, 저장 프로시저는 DB 서버에 저장되어 API처럼 제공되므로 애플리케이션을 구성하는 소스 코드와 구분될 수 있다.

 

5. 절차적 기능 구현 가능

SQL 문에 IF나 While과 같은 제어문장을 사용할 수 있어서 애플리케이션 소스 코드를 줄일 수 있다.

 

저장 프로시저 - 단점

저장 프로시저를 사용함으로 얻게 되는 단점도 분명 있다.

 

1. 불편한 유지보수

방금 장점에서 유지보수가 편리하다고 했지만,

프로그램을 개발한 사람과 운영하는 사람이 다르다면 이야기가 달라진다.

 

아무래도 많은 SQL 문이 모여있고, 여러 곳에서 하나의 저장 프로시저를 사용하는 경우가 많을테니,

 

운영을 하기 위해 들어온 인력 입장에서는 한 번에 파악하기도 어렵고,

저장 프로시저를 수행하며 발생하는 데이터를 분석 하기도 어렵다.

 

2. DB 확장 어려움

서비스 사용자가 많아지면 늘어난 트래픽을 처리하기 위해 서버의 수를 늘려야 한다.

 

하지만 저장 프로시저를 주로 사용하여 프로그램을 만들면 그러한 DB의 수를 늘리는 것이 어려워지고,

DB 교체는 더 힘들어진다.

 

만약 수를 늘리지 않고 과도한 트래픽이 발생하게 된다면,

트래픽의 부하를 DB에서 다 받기 때문에 분산해주지 못해 DB 서버가 죽을 위험도 있다.

 

3. 단가 상승

애플리케이션 개발을 주로 Java로 한다면,

자바보다는 DB를 더 잘 아는 개발자를 뽑아야 해서 개발 단가가 상승한다.

 

또한 예전이나 지금이나 DB 자체가 비싼 자원이기 때문에

부하는 WAS에 주고 간단한 프로세스만 DB 쪽으로 주는 것이 경제적으로 이득이다.

 

---

여러 블로그와 커뮤니티의 글들을 보며 최근에는 저장 프로시저를 점점 줄여나가는 추세인 것을 알 수 있었다.

그래도 아예 쓰지 않는 것은 아니고, 적재적소에 사용할 줄 알아야 하는 것 같다.


끝!