---
title: Resilience4j vs Spring Retry — retry/circuit breaker library 비교
source_type: official-doc
status: raw
confidence: high
url: https://resilience4j.readme.io/docs/getting-started
archive_url:
related_branches: [feature-outbound-http-client-baseline, feature-background-job-async-contract, feature-metrics-alerting-contract]
related_projects: [ca-tmpl]
tags: [ca-outbound-http, resilience4j, spring-retry, hystrix, circuit-breaker, retry]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# Resilience4j vs Spring Retry — retry/circuit breaker library 비교

> Layer: `raw/official-docs/` — Resilience4j Getting Started 페이지의 정의/모듈 발췌 + Spring Retry / Hystrix 상태에 대한 별도 출처 참조. ca-tmpl outbound Group G-C 의 resilience tool 비교 (Resilience4j 채택 + Spring Retry 좁은 예외 + Hystrix 배제) 근거.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-outbound-http-client-baseline]] | outbound retry/circuit breaker library 채택 (Resilience4j default) 근거 |
| [[raw/branch-notes/feature-background-job-async-contract]] | background job retry 정책에서 Resilience4j Retry vs Spring Retry `@Retryable` 의 분리 사용 결정 |
| [[raw/branch-notes/feature-metrics-alerting-contract]] | circuit breaker metric (`dependency.name`, `outcome` 등) 의 Resilience4j Micrometer 통합 의존 결정 |

## 컨텍스트

ca-tmpl 결정 **"retry/circuit breaker 는 Resilience4j, Spring Retry 는 simple blocking 에만"** 의 근거. Hystrix 가 maintenance 인 이유까지 묶음.

## 출처 / Source

- Resilience4j Getting Started: https://resilience4j.readme.io/docs/getting-started
- Spring Retry GitHub README: https://github.com/spring-projects/spring-retry
- Netflix Hystrix README: https://github.com/Netflix/Hystrix (maintenance-mode 안내)
- 아카이브 URL: (미수집)
- 저자 / 조직: Resilience4j community (Robert Winkler 등) / Spring (Pivotal/Broadcom) / Netflix OSS
- 발행일: rolling docs
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

> [§Resilience4j Getting Started — Introduction] "Resilience4j is a lightweight fault tolerance library designed for functional programming."

> [§Resilience4j Getting Started — Introduction] "Resilience4j provides higher-order functions (decorators) to enhance any functional interface, lambda expression or method reference with a Circuit Breaker, Rate Limiter, Retry or Bulkhead."

> [§Resilience4j Getting Started — NOTE] "NOTE: Resilience4j 2 requires Java 17."

> [§Resilience4j Getting Started — Modules] "resilience4j-circuitbreaker: Circuit breaking" / "resilience4j-ratelimiter: Rate limiting" / "resilience4j-bulkhead: Bulkheading" / "resilience4j-retry: Automatic retrying (sync and async)" / "resilience4j-cache: Result caching" / "resilience4j-timelimiter: Timeout handling"

> [§Resilience4j Getting Started — Vavr] (Vavr `Try` monad 예시) "Vavr's `Try` monad to recover from an exception and invoke another lambda expression as a fallback, when all retries have failed."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| R4J-C1 | Resilience4j 는 **functional programming 을 위해 설계된 lightweight fault tolerance library** | [§Getting Started — Introduction] "Resilience4j is a lightweight fault tolerance library designed for functional programming." | `official-vendor-doc` | Java 17+ 환경에서 Resilience4j 2 사용 | "lightweight" 가 특정 메모리/jar 크기 임계값을 의미한다는 뜻 아님 — 정성적 표현 |
| R4J-C2 | Resilience4j 는 functional interface / lambda / method reference 를 **decorator** 로 감싸 CircuitBreaker / RateLimiter / Retry / Bulkhead 를 부착하는 higher-order function 모델 | [§Getting Started] "Resilience4j provides higher-order functions (decorators) to enhance any functional interface, lambda expression or method reference with a Circuit Breaker, Rate Limiter, Retry or Bulkhead." | `official-vendor-doc` | 함수형 호출 site 에 decorator 부착하는 사용 패턴 | Spring AOP `@CircuitBreaker` annotation 사용이 항상 가능한 것은 아님 — 별도 `resilience4j-spring-boot3` starter 필요 |
| R4J-C3 | Resilience4j core 모듈 6종 — circuitbreaker / ratelimiter / bulkhead / retry / cache / timelimiter | [§Getting Started — Modules] "resilience4j-circuitbreaker" / "resilience4j-ratelimiter" / "resilience4j-bulkhead" / "resilience4j-retry: Automatic retrying (sync and async)" / "resilience4j-cache" / "resilience4j-timelimiter" | `official-vendor-doc` | Resilience4j 2.x core 모듈 채택 시 | 각 모듈이 동일한 default 정책 / 동일한 thread model 을 쓴다는 뜻 아님 — Bulkhead 는 semaphore vs threadpool 두 변종 |
| R4J-C4 | Resilience4j 2.x 는 **Java 17** 을 요구 | [§Getting Started — NOTE] "NOTE: Resilience4j 2 requires Java 17." | `official-vendor-doc` | Resilience4j 2.x 도입 결정 | Resilience4j 1.x 가 여전히 active maintained 라는 뜻 아님 — 별도 확인 필요 |
| R4J-C5 | Resilience4j 는 retry 모두 소진 후 fallback 으로 다른 lambda 를 호출할 수 있도록 Vavr `Try` monad 와 연동 | [§Getting Started — Vavr] "Vavr's `Try` monad to recover from an exception and invoke another lambda expression as a fallback, when all retries have failed." | `official-vendor-doc` | Vavr 의존성을 함께 사용하는 경우 | Vavr 없이도 동일 fallback 표현이 가능하다는 뜻 아님 — 별도 API 확인 필요 |
| R4J-C6 | Spring Retry README (별도 출처) 및 Hystrix README (별도 출처) 의 상태 인용은 본 WebFetch 범위 밖. **본 raw 만으로는 Spring Retry 의 "circuit breaker 미포함" 또는 Hystrix 의 "maintenance" 상태가 증명되지 않음** | (negative finding — Resilience4j Getting Started 페이지에 Spring Retry / Hystrix 비교 없음) | `needs-confirmation` | Resilience4j vs Spring Retry vs Hystrix 비교 표 작성 시 | 이 부정 확인은 비교 결론이 **거짓** 이라는 뜻이 아니라 **별도 출처 보강 필요** 라는 뜻 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `R4J-C1` ~ `C5`: Resilience4j 의 정의, decorator 모델, 6 core 모듈, Java 17 요구사항, Vavr `Try` fallback 연동
- **이 자료가 증명하지 않는 것**:
  - Spring Retry 의 `@Retryable` 지원 / circuit breaker 미포함 — 본 Resilience4j 페이지에 없음 (`R4J-C6`). Spring Retry GitHub README 별도 출처 필요
  - Netflix Hystrix 의 maintenance 상태 — 본 페이지에 없음 (`R4J-C6`). Hystrix GitHub README 별도 출처 필요
  - "Lightweight because the library only uses Vavr, which does not have any other external dependencies" — 본 WebFetch 결과에 없음. 이전 인용은 다른 페이지 (또는 archived) 출처 — needs-confirmation
  - Micrometer integration "내장" 여부 — 본 페이지에 없음 (`micrometer` 모듈은 별도 artifact 일 가능성, 별도 확인 필요)
  - circuit breaker state machine 의 정확한 상태 (CLOSED/OPEN/HALF_OPEN/DISABLED/FORCED_OPEN) — 본 페이지에 없음
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - ca-tmpl 의 circuit breaker metric tag scope (`dependency.name`, `dependency.type`, `outcome`) 가 Resilience4j default tag 와 어떻게 매핑되는지 — `resilience4j-micrometer` 모듈 별도 확인
  - retry-after header honor 가 Resilience4j Retry default 가 아니라는 점 — 본 페이지 미언급, 별도 검증 필요
  - `resilience4j-spring-boot3` starter 의 정확한 artifact 좌표 + auto-configuration 동작

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- 비교 표 (별도 출처 보강 필요한 항목 다수):

| 항목 | Resilience4j | Spring Retry | Hystrix |
|---|---|---|---|
| status | active (`R4J-C1`,`C4`) | active (needs-confirmation, 별도 출처) | **maintenance** (needs-confirmation, Hystrix README 별도 출처) |
| circuit breaker | yes (`R4J-C3`) | no (needs-confirmation) | yes (needs-confirmation) |
| retry | yes (`R4J-C3`) | yes — declarative `@Retryable` (needs-confirmation) | no (needs-confirmation) |
| rate limiter | yes (`R4J-C3`) | no (needs-confirmation) | no (needs-confirmation) |
| bulkhead | yes (semaphore + threadpool, `R4J-C3` + 변종은 미확인) | no (needs-confirmation) | yes — threadpool (needs-confirmation) |
| time limiter | yes (`R4J-C3`) | no (needs-confirmation) | yes (needs-confirmation) |
| metric | `resilience4j-micrometer` 모듈 (needs-confirmation) | Spring Boot Actuator (needs-confirmation) | Hystrix dashboard (needs-confirmation) |
| reactive | yes (Reactor / RxJava) — 본 페이지 미언급 | no (needs-confirmation) | RxJava (needs-confirmation) |
| spring boot starter | `resilience4j-spring-boot3` (needs-confirmation, 정확한 좌표) | `spring-retry` + `spring-aspects` (needs-confirmation) | `spring-cloud-starter-netflix-hystrix` deprecated (needs-confirmation) |

- ca-tmpl 결정 정당성 (해석):
  - **Resilience4j default** — circuit breaker 가 필요한 시점이 retry 와 분리되지 않음. 두 module 이 같은 library 에 있어야 metric/operations 이 일관 (해석 — `R4J-C3` 의 모듈 list 가 부분 근거).
  - **Spring Retry 예외 허용** — circuit breaker 불필요 + reactive 아닌 simple blocking retry 만 필요한 좁은 케이스 (예: idempotent admin job 한 군데). over-engineering 방지 (해석).
  - **Hystrix 배제** — 공식 maintenance 상태 가정 (needs-confirmation, Hystrix README 별도 출처 필요).
- ca-tmpl test 계약 매핑 (해석):
  - "retry/circuit breaker enabled 인데 Resilience4j metric 과 retryable classification 이 없으면 실패" ← 라이브러리 선택을 강제하고 metric/registry 등록을 강제.
  - circuit breaker metric tag scope `dependency.name`, `dependency.type`, `outcome` 만 허용 — Resilience4j 기본 tag (state, kind 등) 를 그대로 노출하면 high cardinality 위험. tag 재맵 필요 (해석).
- 시사점: ca-tmpl Resilience4j 선택은 **module 통합성 + 공식 maintenance status 가정** 기반. 비교 표의 다수 항목이 별도 출처로 보강되어야 wiki 승급 가능.

## Related / 관련

- 같은 주제 다른 official-doc:
  - [[raw/official-docs/outbound-spring-restclient-baseline]]
  - [[raw/official-docs/outbound-webclient-vs-restclient-spring]]
  - [[raw/official-docs/outbound-openfeign-declarative-client]]
- 같은 주제 company-tech-blog:
  - [[raw/company-tech-blogs/outbound-stripe-rate-limit-retry-engineering]] — Stripe retry/backoff/idempotency 사례
- 인용하는 branch:
  - [[raw/branch-notes/feature-outbound-http-client-baseline]]
  - [[raw/branch-notes/feature-background-job-async-contract]]
  - [[raw/branch-notes/feature-metrics-alerting-contract]]
- 인용하는 wiki: (미작성)