책임 연쇄 vs 데코레이터 — 헷갈리는 두 패턴, 결정적 차이를 콕 짚다

1. 큰그림

두 패턴 모두 객체를 일렬로 연결해 요청을 전달하는 “재귀적 합성(체이닝)” 구조를 쓴다. 그래서 UML만 보면 “거의 같은데?” 싶지만, 의도와 결과가 완전히 다르다.

---

2. 공통점 ― 왜 비슷해 보일까?

• 재귀 합성: 객체가 자기 안에 같은 타입을 보관하고 다음 객체로 위임한다.
• 런타임 조립: 체인 순서를 코드를 수정하지 않고 동적으로 바꿀 수 있다.
• 결합도 ↓: 클라이언트는 “얼마나 많은 객체가 연결돼 있는지” 모른다.

---

3. 결정적 차이점

포인트	책임 연쇄(CoR)	데코레이터(Decorator)
목적	“누가 요청을 처리할지 찾는다” – 책임 위임	“객체에 기능을 덧붙인다” – 행위 확장
흐름 제어	핸들러가 처리를 중단할 수 있음 (다음으로 패스 여부 결정)	데코레이터는 반드시 내부 객체를 호출해 흐름을 이어감
반환값/사이드이펙트	주로 하나만 결과를 만든다 (ex. 인증 실패 → 401)	호출마다 누적 효과가 생긴다 (ex. 로그 + 캐싱 + 인코딩)
Undo/Redo	거의 사용하지 않음	래퍼를 벗겨 원상복구 가능
대표 사례	Spring Security Filter Chain, Exception Resolver	Java I/O BufferedInputStream, 로깅 인터셉터

 

---

4. 언제 어떤 패턴을 쓰면 좋을까?

• 요청이 한 번만 처리되면 끝 👉 책임 연쇄
  예) 인증 → 승인된 첫 핸들러만 200 OK 반환, 이후 체인은 멈춤.
• 여러 기능을 겹겹이 추가 👉 데코레이터
  예) 리스너에 로그 → 캐시 → 암호화 → 전송을 차례로 포장.

TIP: 체인 중 일부 단계에서 흐름을 끊어야 한다면 데코레이터가 아니라 책임 연쇄를 선택하라

---

5. 현업 적용 팁

1. 스프링 필터 작성: doFilter 안에서 return으로 체인을 끊을지(CoR) 꼭 확인.
2. 관점이 바뀌어 혼동될 때: “이 단계가 일을 끝내야 하나, 추가 행동만 해야 하나?”를 자문해 보면 패턴이 자연스럽게 갈린다.
3. 혼합 금물: 기능 확장용 데코레이터를 CoR에 끼워 넣으면 디버깅 지옥. 체인과 데코레이터는 각각의 레이어로 명확히 분리하자.