스토어드 프로시저
Stored Procedure
DB에 저장된 실행 가능한 코드. 비즈니스 로직.
Stored Procedure
DB에 저장된 실행 가능한 코드. 비즈니스 로직.
스토어드 프로시저(Stored Procedure)는 데이터베이스 서버에 저장되어 실행되는 SQL 문과 프로그래밍 로직의 집합입니다. 한 번 컴파일되면 재사용되므로 매번 SQL을 파싱하고 실행 계획을 세우는 오버헤드가 없습니다.
주요 장점으로는 네트워크 트래픽 감소(한 번 호출로 복잡한 작업 수행), 코드 재사용성, 보안 강화(직접 테이블 접근 대신 프로시저 권한 부여)가 있습니다. 또한 트랜잭션 처리와 에러 핸들링을 DB 레벨에서 구현할 수 있습니다.
반면 버전 관리가 어렵고, 애플리케이션 로직이 DB에 종속되며, 디버깅이 불편하다는 단점도 있습니다. 최근에는 ORM과 마이크로서비스 아키텍처의 등장으로 사용이 줄었지만, 배치 처리나 복잡한 데이터 변환에서는 여전히 유용합니다.
-- MySQL 스토어드 프로시저 생성
DELIMITER //
CREATE PROCEDURE GetEmployeesByDept(
IN dept_id INT,
OUT employee_count INT
)
BEGIN
-- 직원 목록 조회
SELECT id, name, salary
FROM employees
WHERE department_id = dept_id;
-- 직원 수 반환
SELECT COUNT(*) INTO employee_count
FROM employees
WHERE department_id = dept_id;
END //
DELIMITER ;
-- 프로시저 호출
CALL GetEmployeesByDept(10, @count);
SELECT @count AS total_employees;
-- 조건문과 반복문 포함 프로시저
DELIMITER //
CREATE PROCEDURE UpdateSalaries()
BEGIN
DECLARE done INT DEFAULT FALSE;
DECLARE emp_id INT;
DECLARE emp_salary DECIMAL(10,2);
DECLARE cur CURSOR FOR SELECT id, salary FROM employees;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
START TRANSACTION;
OPEN cur;
read_loop: LOOP
FETCH cur INTO emp_id, emp_salary;
IF done THEN
LEAVE read_loop;
END IF;
IF emp_salary < 3000000 THEN
UPDATE employees SET salary = salary * 1.1 WHERE id = emp_id;
END IF;
END LOOP;
CLOSE cur;
COMMIT;
END //
DELIMITER ;
PM: 월말 정산 배치가 4시간 넘게 걸리는데 개선할 방법이 있나요?
DBA: 지금은 애플리케이션에서 레코드마다 쿼리를 보내고 있어요. 스토어드 프로시저로 옮기면 네트워크 왕복이 줄어서 빨라질 거예요.
백엔드 개발자: 그런데 프로시저는 버전 관리가 어렵지 않나요?
DBA: 맞아요. 프로시저 DDL을 Git에 포함시키고, 마이그레이션 도구로 관리하면 됩니다.
면접관: 스토어드 프로시저의 장단점을 설명해주세요.
지원자: 장점은 한 번 컴파일 후 재사용으로 성능 향상, 네트워크 트래픽 감소, 세밀한 권한 관리가 있습니다. 단점은 버전 관리와 디버깅의 어려움, DB 벤더 종속성, 애플리케이션 로직 파편화입니다.
면접관: 언제 프로시저를 쓰는 게 적절할까요?
지원자: 대량 데이터 배치 처리, 복잡한 트랜잭션, 그리고 보안상 직접 테이블 접근을 막아야 할 때 유용합니다.
시니어: 이 프로시저 에러 핸들링이 없네요. 실패하면 어떻게 되죠?
주니어: 아, 그냥 에러가 나겠네요.
시니어: DECLARE HANDLER로 예외 처리하고, 에러 시 ROLLBACK하도록 추가하세요. 프로덕션에서 중간에 실패하면 데이터 정합성이 깨집니다.