Three-tier Architecture와 Stored Function 활용법

Three-tier Architecture란?

Three-tier architecture는 현대적인 애플리케이션 개발에서 많이 채택하는 3계층 구조 아키텍처로, 시스템을 기능적으로 분리하여 확장성과 유지보수성을 높이는 구조입니다.

1. Presentation Tier (프론트엔드)

사용자에게 보이는 UI를 담당하는 계층
브라우저, 앱, HTML, JavaScript, CSS 등
예시: React, Vue, Angular, Native App

2. Logic Tier (애플리케이션 로직)

비즈니스 로직을 담당하는 계층
서비스의 정책, 기능 등이 이곳에서 동작
예시: Java(Spring), Python(Django), Node.js, .NET

3. Data Tier (데이터베이스)

데이터를 저장하고, 조회하고, 가공 및 제공하는 계층
예시: Oracle, MySQL, PostgreSQL, MongoDB

핵심은 각 계층의 역할을 명확히 분리하여,
비즈니스 로직은 Logic Tier에, 데이터 접근은 Data Tier에 위임하는 것이 이상적인 구조입니다.

Stored Function이란?

정의

사용자가 정의한 SQL 기반 함수
DBMS에 영구 저장되어 필요시 호출 가능
SELECT, INSERT, UPDATE, DELETE 등 모든 SQL문에서 사용 가능
보통 계산, 포맷 변환, 반복적인 SQL 처리 등에 사용

Stored Function 예제 (Oracle 기준)

-- 1. 함수 생성
CREATE OR REPLACE FUNCTION get_tax (
    p_salary IN NUMBER
) RETURN NUMBER
IS
    v_tax NUMBER;
BEGIN
    v_tax := p_salary * 0.1;
    RETURN v_tax;
END;
/

-- 2. 사용 예시
SELECT ename, sal, get_tax(sal) AS tax
FROM emp;

Oracle에서 Stored Function 조회

-- 현재 유저의 함수 목록 조회
SELECT object_name
FROM user_objects
WHERE object_type = 'FUNCTION';

-- 함수 소스코드 보기
SELECT text
FROM user_source
WHERE name = 'GET_TAX'
ORDER BY line;

Stored Function, 언제 사용하는 것이 좋을까?

사용하기 좋은 경우

단순한 계산 로직 (예: 세금 계산, 할인율 적용 등)
재사용 가능한 유틸 함수
데이터 정제, 문자열 변환 등

예시:

전화번호 하이픈 포맷 변환
날짜 형식 처리
포인트 계산 등

피해야 할 경우

비즈니스 정책이 자주 바뀌는 경우
복잡한 서비스 흐름을 포함한 로직 (조건 분기, 외부 API 연동 등)
외부 시스템과의 연동이 필요한 처리

이유:

로직 추적이 어려움 → 유지보수 비용 증가
계층 분리 원칙 위반 → 아키텍처 혼란 유발
버전 관리 및 테스트 어려움 → CI/CD와 충돌 가능성

실무 관점에서의 저장 함수 위치

위치	장점	단점
Logic Tier (Spring, Django 등)	가독성 좋고 테스트 편리, 유연한 변경 가능	DB 부하 증가
Data Tier (Stored Function)	속도 빠름 (DB 내부 연산), 네트워크 비용 절감	추적 어렵고 유지보수 비용 높음

따라서 Stored Function은 데이터 중심 유틸 함수 정도로 제한하는 것이 좋고,
복잡한 정책이나 흐름 제어는 Logic Tier에서 처리하는 것이 이상적입니다.

정리

Stored Function은 Data Tier에서 실행되는 SQL 기반 함수
단순 계산 또는 반복되는 로직에는 적합
비즈니스 로직은 반드시 Logic Tier에 구현하는 것이 원칙
Three-tier 구조는 각 계층의 책임을 지켜야 성능과 유지보수성이 보장됨
실무에서는 아키텍처 원칙 + 성능 고려 + 유지보수성을 종합적으로 판단해야 함