200. 책임 연쇄 패턴 장단점 (Chain of Responsibility Pros and Cons)

핵심 인사이트 (3줄 요약)

본질: 책임 연쇄 패턴의 장점은 '느슨한 결합'과 '동적 체인 구성'이며, 단점은 '처리 보장 없음'과 '성능 오버헤드(긴 체인)'이다. 실무에서는 이 트레이드오프를 인식하고 패턴을 적절히 적용해야 한다.

가치: 책임 연쇄 패턴은 미들웨어 파이프라인, 이벤트 버블링, 서블릿 필터 등에서 광범위하게 사용되며, 특히 AOP(관점 지향 프로그래밍)의 인터셉터 메커니즘이 책임 연쇄 패턴의 확장된 구현이다.

판단 포인트: 책임 연쇄 패턴 적용이 적합한 경우: ① 처리자가 런타임에 결정되어야 할 때, ② 처리자를 동적으로 추가·재배열해야 할 때, ③ 하나의 요청을 여러 핸들러 중 하나만 처리해야 할 때. 부적합한 경우: ① 처리 보장이 필수일 때, ② 처리자가 고정되어 단순한 조건 분기로 충분할 때.

Ⅰ. 개요 및 필요성

책임 연쇄 패턴의 장점과 단점을 균형 있게 이해해야 적절한 상황에 적용할 수 있다. 패턴 남용은 불필요한 복잡성을 추가하고, 패턴 미사용은 조건 분기 폭발을 초래한다.

실무 적용 전 체크: 핸들러 수가 3개 이상인가? 처리자가 동적으로 바뀌는가? 체인 순서가 바뀔 수 있는가? → 하나라도 Yes라면 책임 연쇄 패턴을 검토하라.

┌─────────────────────────────────────────────────────────────┐
│          책임 연쇄 패턴 장단점 정리                           │
├─────────────────────────────────────────────────────────────┤
│  장점                         단점                          │
│  ✅ 발신자-수신자 분리         ⚠ 처리 보장 없음             │
│  ✅ 핸들러 동적 추가·재배열    ⚠ 긴 체인 → 성능 오버헤드   │
│  ✅ OCP 달성 (핸들러 독립)     ⚠ 디버깅 어려움             │
│  ✅ SRP (각 핸들러 단일 책임)  ⚠ 처리자 추적 어려움        │
│  ✅ 재사용 가능한 핸들러       ⚠ 체인 설정 복잡성          │
└─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 공문서 결재 체인은 빠른 처리(장점)를 가능하게 하지만, 어느 부서에서 멈췄는지 추적(단점)이 어려울 수 있다.

Ⅱ. 아키텍처 및 핵심 원리

AOP의 인터셉터가 책임 연쇄 패턴의 확장이다. 스프링 AOP에서 MethodInterceptor 체인이 메서드 실행 전·후에 처리를 추가한다. ProceedingJoinPoint.proceed()가 다음 인터셉터(핸들러)로 전달하는 역할이다.

항목	설명	포인트
처리 결정	핸들러가 결정	모두 통과 (선택적 제어)
구성 방법	코드에서 체인 연결	어노테이션·설정으로 선언
메커니즘	next.handle()	proceed()
범용성	일반 패턴	크로스 컷팅 관심사

┌─────────────────────────────────────────────────────────────┐
│       스프링 AOP 인터셉터 체인 (책임 연쇄 확장)              │
├─────────────────────────────────────────────────────────────┤
│  메서드 호출                                                 │
│  → @Transactional 인터셉터                                  │
│  → @Cacheable 인터셉터                                       │
│  → @Async 인터셉터                                          │
│  → 실제 메서드 실행                                          │
│  ← 결과 역순 반환                                            │
└─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 스프링 AOP 인터셉터는 공문서에 여러 부서(트랜잭션·캐시·비동기)의 도장을 순서대로 찍고, 결재 후 역순으로 처리 결과를 돌려보내는 것이다.

Ⅲ. 비교 및 연결

이벤트 버블링(Event Bubbling)도 책임 연쇄 패턴의 구현이다. DOM 이벤트가 자식 요소에서 부모 요소로 버블링하며 각 요소가 처리 여부를 결정한다. event.stopPropagation()이 체인을 끊는 역할이다.

비교 축	A	B
체인 방향	요청: 하향, 응답: 상향	자식 → 부모
체인 중단	filterChain 미호출	stopPropagation()
적용 영역	서버 사이드	클라이언트 사이드

📢 섹션 요약 비유: 이벤트 버블링은 돌을 연못에 던지면 파문이 퍼지듯, 이벤트가 자식 요소에서 부모 요소로 전파되는 것이다.

Ⅳ. 실무 적용 및 기술사 판단

Node.js Express의 미들웨어가 책임 연쇄 패턴의 간결한 구현이다. app.use((req, res, next) => { ... next(); })에서 next()가 다음 미들웨어로 전달하는 역할이다. 에러 핸들러는 (err, req, res, next) => {} 시그니처로 체인 끝에 배치한다.

판단 체크리스트

긴 체인에서 성능 문제가 발생하지 않도록 경량 핸들러를 우선 배치했는가?
처리 보장이 필요한 경우 기본 핸들러(Default Handler)를 체인 끝에 배치했는가?
책임 연쇄 패턴과 파이프-필터 패턴의 차이(조건부 중단 vs 항상 통과)를 인식하는가?
핸들러 수가 2~3개의 단순한 경우 조건 분기가 더 적합하지 않은지 검토했는가?
디버깅을 위해 각 핸들러에서 로깅·추적(Trace ID)을 구현하는가?

📢 섹션 요약 비유: 체인이 길어지면 어느 단계에서 처리됐는지 추적이 어려우므로, 각 핸들러에 로그(도장)를 찍어 흐름을 추적해야 한다.

Ⅴ. 기대효과 및 결론

책임 연쇄 패턴의 장단점을 이해하고 적절한 상황에 적용하면 유연하고 확장 가능한 처리 흐름을 구현할 수 있다. 서블릿 필터 체인, 스프링 AOP, Node.js 미들웨어 등 현대 웹 프레임워크의 핵심 메커니즘이 이 패턴을 기반으로 한다.

결론: 책임 연쇄 패턴은 처리자가 동적이고 유연해야 할 때 강력하지만, 처리 보장과 디버깅 어려움을 인식하고 설계해야 한다. 파이프-필터 패턴, AOP, 데코레이터와 조합하면 더 강력한 설계가 가능하다.

📢 섹션 요약 비유: 공항 보안 체계는 책임 연쇄 패턴의 장점(유연한 추가·재배열)을 활용하고, 비상구 직원(기본 핸들러)을 마지막에 배치하여 처리 보장을 달성한다.

📌 관련 개념 맵

[책임 연쇄 패턴 심화] → [AOP 인터셉터 체인] → [서블릿 필터 체인] → [이벤트 버블링] → [API Gateway 미들웨어 체인]

개념	연결 포인트
AOP 인터셉터	책임 연쇄 패턴의 선언적 확장
파이프-필터 패턴	책임 연쇄의 '모두 통과' 변형
이벤트 버블링	책임 연쇄의 클라이언트 사이드 구현
Node.js 미들웨어	책임 연쇄의 함수형 구현

📈 관련 키워드 및 발전 흐름도

[GoF Chain of Responsibility 장단점] → [AOP 인터셉터 체인] → [클라우드 미들웨어] → [서비스 메시 필터 정책]

👶 어린이를 위한 3줄 비유 설명

책임 연쇄의 장점: 새 보안 검사(핸들러)를 언제든 추가할 수 있어요.
단점: 체인이 너무 길어지면 어디서 문제가 생겼는지 찾기 어려워요.
스프링 AOP, Node.js 미들웨어가 모두 이 패턴을 사용해요!