Brain186. 스토어드 프로시저 (Stored Procedure) / 트리거 (Trigger)
핵심 인사이트: Java나 파이썬 서버에서 수백 번 DB에 SQL을 던지고 결과를 받는 건 네트워크 왕복(Network RTT) 낭비가 심하다. 아예 복잡한 비즈니스 로직(반복문, 조건문)을 DB 서버 내부(저장소)에 쑤셔 넣고, "이거 실행해!" 버튼 한 번만 눌러서 DB 안에서 모든 연산을 끝내게 하는 강력한 무기가 프로시저다.
Ⅰ. 스토어드 프로시저 (Stored Procedure)
개발자가 작성한 복잡한 쿼리문(SQL)과 제어문(IF, WHILE 등)을 하나의 덩어리(모듈)로 묶어, 데이터베이스 서버 내부에 미리 컴파일하여 저장(Store) 해 둔 절차적 프로그램입니다.
프로시저의 장점과 단점
| 구분 | 설명 |
|---|---|
| 성능 향상 | 수천 줄의 복잡한 쿼리를 애플리케이션(WAS)과 DB 간에 매번 전송할 필요 없이, CALL 프로시저명() 한 줄만 보내면 되므로 네트워크 트래픽이 획기적으로 줄어듭니다. 또한, DB 엔진이 미리 컴파일해 두므로 파싱(Parsing) 비용이 절약됩니다. |
| 보안 및 은닉 | 테이블에 대한 직접적인 접근(SELECT, UPDATE) 권한을 막고, 오직 프로시저 실행 권한만 부여하여 보안을 극대화할 수 있습니다. |
| 치명적 단점 | DB 서버의 CPU를 혹사시킵니다. (WAS를 늘리기는 쉬워도 DB 서버를 스케일 아웃하기는 매우 어렵습니다). 또한, 벤더 종속적(Oracle PL/SQL 등)이라 나중에 오픈소스 DB로 마이그레이션할 때 엄청난 재앙이 됩니다. |
Ⅱ. 트리거 (Trigger)
스토어드 프로시저의 일종이지만, 사용자가 수동으로 호출(CALL)하는 것이 아니라 특정 테이블에 이벤트(INSERT, UPDATE, DELETE)가 발생했을 때 데이터베이스가 알아서(자동으로) 방아쇠를 당겨 실행시키는 특수한 프로시저입니다.
트리거의 주요 용도
- 감사(Audit) 및 로그 남기기:
직원테이블의 급여가UPDATE되면, 트리거가 발동하여급여_변경_이력테이블에 자동으로 과거 급여와 변경 시간을 씁니다. - 무결성 강제 유지:
주문테이블에INSERT가 일어나면, 트리거가 발동하여재고테이블의 수량을 자동으로-1깎습니다. (개발자가 앱 단에서 재고 차감 로직을 짜는 것을 깜빡해도 DB가 무조건 강제 실행함)
트리거의 부작용 (Hidden Logic)
눈에 보이지 않게 자동으로 뒤에서 실행되기 때문에, 로직이 복잡해지면 장애 추적(디버깅)이 매우 어렵습니다. (예: 주문 하나 넣었을 뿐인데 뒤에서 트리거 10개가 연쇄 폭발하며 DB가 뻗어버림)
📢 섹션 요약 비유: 프로시저는 식당 홀(WAS)과 주방(DB) 사이를 왔다 갔다 하며 재료를 나르는 대신, 주방장에게 아예 레시피(로직)를 줘서 주방 안에서 요리를 다 끝내고 완성된 접시만 홀로 내보내는 효율적인 시스템입니다. 반면 트리거는 손님이 식당 문을 열고 들어오면(이벤트), 주방장이 묻지도 따지지도 않고 자동으로 웰컴 드링크를 만들어 내보내는(자동 실행) 숨겨진 센서와 같습니다.