"이 로직을 애플리케이션에 둘까, 데이터베이스에 둘까?" 같은 검증·집계를 여러 서비스가 반복하다 보면 이런 고민이 생깁니다. 저장 프로시저(Stored Procedure)는 여러 SQL문을 하나의 이름 붙은 루틴으로 데이터베이스 안에 저장해 두고, 호출 한 번으로 실행하는 기능입니다. 로직을 앱이 아니라 DB 서버에 둔다는 점이 핵심 결정 지점입니다.
저장 프로시저란
| 구분 | 애플리케이션 코드 | 저장 프로시저 |
|---|---|---|
| 실행 위치 | 앱 서버 | 데이터베이스 서버 |
| 네트워크 왕복 | 쿼리마다 발생 | 호출 1회로 묶음 |
| 버전 관리 | Git 등으로 쉬움 | DB 안이라 추적 어려움 |
| 언어 | 앱 언어(Java 등) | DB 절차 언어(PL/pgSQL 등) |
가장 큰 장점은 네트워크 왕복 감소입니다. 앱에서 쿼리 다섯 번을 따로 보내면 왕복도 다섯 번이지만, 프로시저로 묶으면 호출 한 번으로 끝납니다. DB 가까이에서 도는 만큼 대량 처리에 유리합니다.
예시로 보는 저장 프로시저
재고를 차감하고 주문을 기록하는 절차를 프로시저로 묶어 봅니다.
SQL
CREATE PROCEDURE place_order(p_user INT, p_item INT, p_qty INT)
LANGUAGE plpgsql AS $$
BEGIN
UPDATE inventory SET stock = stock - p_qty
WHERE item_id = p_item AND stock >= p_qty;
IF NOT FOUND THEN
RAISE EXCEPTION '재고 부족';
END IF;
INSERT INTO orders(user_id, item_id, qty)
VALUES (p_user, p_item, p_qty);
END;
$$;
앱에서는 한 줄로 호출합니다.
SQL
CALL place_order(101, 55, 2);
재고 확인과 주문 기록이 DB 안에서 하나로 실행되니 왕복이 줄고, 여러 서비스가 같은 규칙(재고 부족 시 거부)을 공유합니다.
장단점과 판단 기준
장점은 성능(왕복 감소), 로직 중앙화, 권한을 프로시저 단위로 주는 보안입니다. 단점도 분명합니다. 비즈니스 로직이 DB로 흩어지면 Git 버전 관리와 테스트가 어렵고, DB 절차 언어는 디버깅 도구가 빈약하며, 특정 DB에 종속(이식성 저하)됩니다.
| 상황 | 권장 |
|---|---|
| 대량 행을 DB 안에서 일괄 처리 | 저장 프로시저 |
| 네트워크 왕복이 병목인 배치 작업 | 저장 프로시저 |
| 자주 바뀌는 비즈니스 규칙 | 애플리케이션 코드 |
| 단위 테스트·코드 리뷰가 중요 | 애플리케이션 코드 |
원칙은 "데이터에 밀착한 무거운 처리는 DB로, 자주 바뀌는 도메인 규칙은 앱으로"입니다. 핵심 로직 전부를 프로시저로 옮기면 유지보수가 빠르게 어려워집니다.
요점 정리
- 저장 프로시저는 여러 SQL을 DB에 저장해 호출 한 번으로 실행하는 루틴이다.
- 네트워크 왕복 감소·로직 중앙화가 강점, 버전 관리·테스트·이식성이 약점이다.
- 무거운 일괄 처리는 프로시저, 자주 바뀌는 규칙은 앱 코드로 나눈다.
저장 프로시저를 직접 만들어 트랜잭션·예외 처리를 실행해 보는 실습은 데이터베이스 트랙에서 회원가입 없이 무료로 할 수 있습니다.