stored procedure란 무엇이며 언제 사용해야 하나요?

Question

Accepted Answer

**stored procedure**는 데이터베이스에 저장되어 이름으로 실행되는 SQL 문(과 절차적 로직)의 집합입니다. 애플리케이션 코드가 아니라 데이터베이스 *안에서* 로직을 실행합니다. 실질적 이점이 있지만 상당한 트레이드오프도 있으므로, 언제 사용할지는 진정한 설계 결정입니다.

## stored procedure

```sql
-- 데이터베이스에 로직을 캡슐화하는 procedure 정의
CREATE PROCEDURE transfer_funds(from_id INT, to_id INT, amount DECIMAL)
LANGUAGE plpgsql AS $$
BEGIN
  UPDATE accounts SET balance = balance - amount WHERE id = from_id;
  UPDATE accounts SET balance = balance + amount WHERE id = to_id;
  -- 로직 포함 가능: 조건문, 반복문, 오류 처리, transaction
END;
$$;

CALL transfer_funds(1, 2, 100);   -- 이름으로 실행
```

stored procedure는 SQL과 절차적 로직(변수, 조건문, 반복문, 오류 처리)을 이름 붙은 재사용 가능한 데이터베이스 루틴으로 묶습니다. function은 비슷하지만 값을 반환합니다.

## 잠재적 이점

```text
✓ 성능 — 데이터베이스 안에서 실행 (다단계 로직에 왕복 없음); 사전 컴파일됨
✓ 네트워크 트래픽 감소 — 앱에서 여러 쿼리 대신 한 번의 호출
✓ 재사용성 — 여러 애플리케이션/클라이언트에서 호출 가능한 공유 로직
✓ 보안 — 테이블 접근 없이 procedure에 EXECUTE 권한 부여; 주입 표면 감소
  (매개변수화)
✓ 일관성 — 중요한 로직을 중앙화해 모든 클라이언트가 같은 구현 사용
```

## 상당한 트레이드오프 (오늘날 많이 피하는 이유)

```text
✗ 비즈니스 로직이 데이터베이스에 → 버전 관리, 테스트, 유지보수가 어려움
  (로직이 앱 코드와 데이터베이스로 나뉨)
✗ 데이터베이스 특화 (PL/pgSQL vs T-SQL vs PL/SQL) → 이식성 낮음, 벤더 종속
✗ 애플리케이션 코드보다 디버깅 어려움; 도구 지원 약함
✗ 확장 — 데이터베이스는 종종 확장이 가장 어려운 계층; 거기에 로직을 밀어 넣으면
  부하가 늘 수 있음
✗ 현대 앱은 종종 애플리케이션 계층의 로직을 선호 (테스트 가능, 이식 가능, 버전 관리)
```

## 언제 사용하는가

```text
✓ 성능이 중요한 데이터 집약적 연산 (무거운 다단계 DB 로직, 배치 작업)
✓ 여러 클라이언트에 걸쳐 DB 수준에서 강제되어야 하는 로직
✓ 많은 쿼리를 포함하는 연산의 왕복 줄이기
✗ 기본적으로 일반 비즈니스 로직을 procedure에 두는 것은 회피 — 현대 관행은
  보통 애플리케이션 계층을 선호 (더 나은 테스트, 버전 관리, 이식성)
```

## 왜 중요한가

stored procedure를 — 트레이드오프 포함하여 — 이해하는 것은 가치 있는 지식입니다. 실질적 이점과 실질적 단점이 있는 진정한 아키텍처 선택을 나타내며, *언제* 사용할지(그리고 언제 사용하지 말지) 아는 것이 성숙한 판단을 반영하기 때문입니다.

stored procedure는 **성능 이점**(데이터베이스 안에서 다단계 로직을 실행해 네트워크 왕복을 피함), 네트워크 트래픽 감소, 클라이언트 간 재사용성, 보안(테이블 접근 없이 실행 권한 부여), 중앙화된 일관성을 제공할 수 있습니다 — 성능이 중요한 데이터 집약적 연산, 배치 처리, 여러 애플리케이션에 걸쳐 데이터베이스 수준에서 강제되어야 하는 로직에 적합합니다.

그러나 **상당한 트레이드오프**를 이해하는 것도 똑같이 중요하며 현대 관행을 반영합니다: 비즈니스 로직을 데이터베이스에 두면 버전 관리, 테스트, 유지보수가 어렵고(로직이 앱과 데이터베이스로 나뉨), 특정 데이터베이스의 절차적 언어에 묶이며(PL/pgSQL, T-SQL, PL/SQL — 이식성 감소), 디버깅이 어렵고, 데이터베이스 계층(종종 확장이 가장 어려움)에 부하를 더합니다.

이런 이유로 **현대 애플리케이션 개발은 비즈니스 로직을 stored procedure가 아니라 애플리케이션 계층에 두는 것을 종종 선호합니다**(테스트 가능, 이식 가능, 버전 관리).

핵심 통찰은 **언제 사용할지에 대한 판단**입니다 — 특정 성능 중요 또는 DB 수준 강제 요구에는 적합하지만, 일반적으로 비즈니스 로직의 기본값으로는 회피합니다.

stored procedure는 많은 시스템(특히 엔터프라이즈/레거시)에서 흔하고, 이점과 트레이드오프를(그리고 애플리케이션 계층 로직으로의 현대적 경향을) 이해하는 것이 건전한 아키텍처 결정을 가능하게 하므로, stored procedure를 이해하는 것은 데이터베이스 측 로직과 애플리케이션 측 로직을 저울질하는 능력을 보여주는 가치 있는 시니어 수준 지식입니다 — 의미 있는 설계 고려사항이자 아키텍처 성숙도를 반영하는 주제입니다.