Trigger 핸들러 패턴 – 왜 모두가 이 구조를 추천하는가

“코드가 길어도 욕 안 먹는 유일한 방법”

 

📝 도입 (인트로 예시)

Trigger는 Salesforce 개발자의 첫 관문이다.
처음엔 그냥 if문 넣어서 처리하면 다 되는 줄 알았다.
그러다 갑자기 10줄짜리 Trigger가 200줄이 되면서... 무언가 잘못됐다는 걸 느낀다.
그때 등장하는 게 바로 Trigger 핸들러 패턴이다.

---

⚙️ 1. 문제 정의: "Trigger가 왜 점점 괴물이 되는가"

• Trigger.new, Trigger.old, context check, if문, DML...
  다 Trigger 안에 몰아넣다 보면 코드가 산으로 감
• bulk-safe 처리 누락, 재사용성 0, Test class 지옥행
• 그리고 나중에 보면 자기 자신도 무슨 조건으로 돌아가는지 모름

---

✅ 2. 해결책: 핸들러 패턴 등장

• Trigger는 “신호만 보내는 역할”
• 실 로직은 TriggerHandler 클래스에 분리
• 일반 구조:

trigger AccountTrigger on Account (before insert, after update) {
    AccountTriggerHandler.handle(Trigger.new, Trigger.oldMap, Trigger.isBefore, Trigger.isInsert);
}

• 이 핸들러 안에서 context별로 로직 분기 처리
• Trigger → Dispatcher → 실제 처리 로직 흐름

---

🛠️ 3. 핸들러 구조 기본 템플릿 소개

• 클래스로 context 분리 예시:

public class AccountTriggerHandler {
    public static void handle(List<Account> newList, Map<Id, Account> oldMap, Boolean isBefore, Boolean isInsert) {
        if(isBefore && isInsert) {
            beforeInsert(newList);
        }
        // ... other context
    }

    private static void beforeInsert(List<Account> accs) {
        // your logic here
    }
}

• 추가 확장 패턴:
  • 여러 객체 공통처리 핸들러
  • metadata-driven handler dispatch

---

💡 4. 이 구조가 가지는 진짜 장점

 

이점	설명
✅ 가독성	Trigger가 10줄로 끝남. 개발자 행복도 급상승
🔁 재사용성	핸들러 내 로직은 다른 프로세스에서도 활용 가능
🔎 테스트 용이성	Trigger 테스트가 아니라 로직 단위 테스트 가능
🧱 대형 프로젝트 적합	수백 개의 Trigger도 체계적으로 관리 가능

 

---

⚠️ 5. 사용할 때 주의할 점

• static context 남발 주의
• 핸들러 내에 DML 묶음 처리 신경 쓸 것
• Handler 구조가 지나치게 복잡해지면 “클린해 보이는데 유지보수 헬”이 될 수 있음

---

🧭 결론

Trigger 핸들러 패턴은 Salesforce 개발에서 “기본 중의 기본이자 필수 생존 전략”이다.
아무리 간단한 Trigger라도 처음부터 구조를 잡고 시작하는 습관이
나중에 고통을 피하고 존중을 얻는 지름길이다.