Livelock이란? 계속 움직이는데도 작업이 끝나지 않는 이유 쉽게 이해하기

복도에서 계속 비켜주기

좁은 복도에서 A와 B가 둘 다 오른쪽·왼쪽으로만 같이 비키면 계속 움직이지만 아무도 통과하지 못합니다. 컴퓨터에서도 충돌을 피하려고 상태를 바꾸고 재시도하지만 실제 결과가 나오지 않는 상태를 Livelock(라이브락)이라고 합니다. Live는 「멈춘 것처럼 보이지 않는다」는 뜻에 가깝습니다. Deadlock은 서로 기다려 멈춤, Starvation은 특정 작업만 기회를 못 얻고, Livelock은 관련 작업이 계속 실행되지만 진전이 없음입니다.

Deadlock = 멈춰서 진행 못함
Starvation = 일부만 계속 굶음
Livelock = 움직이지만 진행 못함

같은 시각 Retry · Hotspot · Progress

충돌 후 모두가 「즉시 같은 규칙으로 재시도」하면 다시 동시에 부딪힐 수 있습니다. Retry 자체는 유용하지만 대칭적인 즉시 Retry는 Livelock·과도한 재시도를 키웁니다. 로그는 쏟아지는데 완료가 없으면 Deadlock보다 발견이 어렵습니다 — CPU·요청이 「일하는 것처럼」 보이기 때문입니다. Optimistic Lock Hotspot(인기 재고 등)에서 충돌→즉시 재시도가 반복되면 Race Condition·Lock Contention과 겹치며 처리 효율이 급락합니다. Queue로 경쟁을 줄이거나 Worker 중복 집기를 막는 것이 도움이 됩니다. 모니터링에서는 Retry·실패율과 함께 완료 건수(Progress)를 봅니다.

CPU 높음 · Retry 많음 · 완료 ≈ 0
→ Progress Metric을 본다

Backoff · Jitter · 비대칭 · 안전장치

Exponential Backoff로 대기 시간을 늘리고, Jitter로 시각을 흩뿌리면 동시 재충돌을 줄입니다. ID·선착 같은 Tie Breaker로 「모두가 동시에 양보」를 깨뜨립니다. Retry 횟수 제한·Dead Letter Queue·Timeout은 무한 루프 안전장치입니다. 외부 API 장애에 끝없이 때리면 Circuit Breaker로 잠시 요청을 끊을 수 있습니다. HTTP 상태만으로 무조건 Retry하지 말고 — 잘못된 입력(400류)은 재시도해도 소용없는 경우가 많습니다. 동시성이 높은 Queue·결제·재고·분산 Worker에서 특히 주의합니다.

Backoff + Jitter + Retry Limit
Tie Breaker · Queue · 중복 작업 방지

자주 묻는 질문

정리

Livelock = 멈추진 않았지만 계속 반응·재시도만 하며 실제 진전이 없는 상태입니다. Deadlock은 아무도 못 움직이고, Starvation은 특정 작업만 굶고, Livelock은 모두 움직이는데 앞으로 못 갑니다. 로그가 바쁘면 Progress(완료 수)를 함께 보세요. Backoff·Jitter·Retry Limit으로 대칭 즉시 재시도를 깨뜨립니다. 그런데 Retry는 복구에 필수이지만, 수천 클라이언트가 장애 직후 같은 시각에 다시 때리면 서버가 회복하기도 전에 또 과부하될 수 있습니다. 실패가 늘수록 재시도 간격을 점점 늘리는 방식이 Exponential Backoff(지수 백오프)입니다.