software

SQL Stored Procedures: 하드코딩된 로직에서 재사용 가능한 SQL로

발행: (2026년 2월 2일 오전 08:04 GMT+9)
6 min read
원문: Dev.to

Source: Dev.to

결국 깨달은 점: 저장 프로시저는 단순히 재사용 가능한 로직일 뿐

초기에 제가 저지른 실수는 저장 프로시저를 뭔가 이색적인 것으로 생각한 것이었습니다.
그렇지 않아요.

저장 프로시저는 데이터베이스 안에 존재하고 입력값을 받을 수 있는 이름이 붙은 SQL 로직일 뿐입니다. 그게 전부죠.

이미 다음을 이해하고 있다면:

  • 함수
  • 매개변수
  • if / else 로직

저장 프로시저는 새로운 개념이 아니라, 새로운 환경에서 쓰이는 새로운 이름일 뿐입니다.

왜 일반 SQL이 제한적으로 느껴졌는가

아주 흔한 요구사항을 상상해 보세요:

“특정 금액 이상인 모든 주문을 보여 주세요.”

일반 SQL이라면 이렇게 작성할 수 있습니다:

select *
from orders
where total_amount > 1000;

동작은 하지만 하드코딩된 것이죠.
규칙이 1500으로 바뀌면 쿼리를 수정해야 합니다.
다른 보고서가 500을 원한다면 쿼리를 복사해야 합니다.
이런 반복이 바로 저장 프로시저가 의미를 갖게 되는 지점입니다.

내가 만든 첫 번째 유용한 저장 프로시저

create or replace procedure high_value_orders
as
begin
  select *
  from orders
  where total_amount > 1000;
end;

이제 이렇게 실행하면 됩니다:

exec high_value_orders;

로직은 동작하지만 규칙은 여전히 하드코딩돼 있습니다.

진짜 업그레이드: 매개변수

프로시저 안에 값을 고정하는 대신, 값을 외부에서 전달합니다:

create or replace procedure high_value_orders (
  p_min_amount number
)
as
begin
  select *
  from orders
  where total_amount > p_min_amount;
end;

이제 같은 로직을 다른 임계값으로 재사용할 수 있습니다:

exec high_value_orders(500);
exec high_value_orders(1500);

프로시저가 설정 가능한 동작으로 바뀝니다.

CASE가 등장한 이유

CASE는 처음에 추상적으로 설명되는 것을 보면서 헷갈렸습니다.
비즈니스 규칙을 구현하는 데 사용하면서 이해가 되었습니다.

예시 요구사항: “고객이 얼마나 소비했는지에 따라 분류한다.”

select
  customer_id,
  total_spent,
  case
    when total_spent >= 5000 then 'VIP'
    when total_spent >= 2000 then 'Regular'
    else 'Occasional'
  end as customer_type
from customers;

CASE는 SQL에서 if / else와 같은 역할을 하며, 조건을 위에서 아래로 평가합니다.

CASE와 저장 프로시저 결합하기

비즈니스에서 다음과 같은 요구가 있다고 가정해 보겠습니다:

“고객을 보여 주되, 내가 관심 있는 임계값에 따라 라벨을 다르게 붙인다.”

create or replace procedure customer_segments (
  p_vip_threshold number
)
as
begin
  select
    customer_id,
    total_spent,
    case
      when total_spent >= p_vip_threshold then 'VIP'
      else 'Non-VIP'
    end as segment
  from customers;
end;

이제 로직이 상황에 맞게 조정됩니다:

exec customer_segments(5000);
exec customer_segments(3000);

같은 프로시저지만 동작은 달라집니다.

이전에 내가 잘못하고 있던 점

  • 저장 프로시저를 고급 SQL 문법처럼 다룸
  • 매개변수를 피하고 모든 것을 하드코딩함
  • CASE를 트릭으로 여기고 로직으로 인식하지 못함

이를 다음과 같이 재구성했을 때 모든 것이 클릭되었습니다:

  • 재사용 가능한 로직
  • 설정 가능한 입력값
  • 조건부 규칙

구문을 넘어 왜 중요한가

SQL은 단순히 데이터를 조회하는 것이 아니라:

  • 규칙을 강제하고
  • 로직을 중앙 집중화하며
  • 중복을 줄이고
  • 동작을 명시적으로 만든다

저장 프로시저가 항상 정답은 아니지만, 이를 이해하면 데이터베이스에 대한 사고 방식이 바뀝니다.

마무리

저장 프로시저나 CASE가 무겁거나 불필요하게 느껴졌다면 이해합니다.
다음과 같은 생각을 멈추면 의미가 생깁니다:

“이 쿼리를 어떻게 작성하지?”

그리고 이렇게 생각하게 됩니다:

“이 로직을 어떻게 재사용할 수 있을까?”

이 전환에는 시간이 걸렸지만, 한 번 이루어지면 SQL이 얕게 느껴지지 않게 됩니다.

Back to Blog

관련 글

더 보기 »