첫 원리를 이용한 sync vs async 실패 클래스 대비

발행: (2026년 1월 13일 오후 02:15 GMT+9)
7 min read
원문: Dev.to

Source: Dev.to

1. 기본 원리부터 시작하기: “Failure Class”란 무엇인가?

A failure class is not:

  • a bug
  • a timeout
  • an outage

A failure class is:

책임, 시간, 상태가 구조화된 방식 때문에 발생할 수 있는 문제들의 범주

So we ask:

  • What must be true for correctness?
  • What assumptions does the model silently make?
  • What breaks when those assumptions are false?

2. 핵심 차이 (한 문장)

  • Synchronous systemsblockingcascading으로 실패한다.
  • Asynchronous systemsduplication, reordering, 그리고 invisibility로 실패한다.

그 외 모든 것은 그 결과이다.

Source:

3. Synchronous Systems — Failure Classes

Definition (First Principles)

동기식 시스템은 다음을 전제로 합니다:

“호출자는 피호출자가 작업을 마칠 때까지 기다린다.”

이는 시간, 가용성, 그리고 정확성을 결합합니다.

Failure Class 1: Blocking Amplification

Question: 시스템이 대기하는 동안 어떤 일이 발생합니까?

Reality:

  • 스레드가 차단됨
  • 연결이 유지됨
  • 메모리가 유지됨

Failure mode: 부하 ↑ → 지연 ↑ → 처리량 붕괴.
이는 비선형 실패이며 단순히 “느리다”는 수준이 아닙니다.

Failure Class 2: Cascading Failure

Question: 의존성이 느려지면 어떻게 됩니까?

모든 것이 대기하고 있기 때문에:

  • 에이전트가 느려짐 → 백엔드가 느려짐
  • 백엔드가 느려짐 → 프론트엔드가 재시도
  • 재시도가 부하를 증폭시킴

Failure mode: 하나의 느린 의존성이 전체 시스템을 다운시킬 수 있습니다.

Failure Class 3: Availability Coupling

Question: 의존성이 다운돼도 시스템이 동작할 수 있습니까?

Answer (sync): 아니오.

Failure mode: 부분 장애가 전체 장애로 전이됩니다.

Summary: Sync Failure Classes

CategoryRoot Cause
BlockingTime is coupled
CascadesDependencies are inline
Global outageAvailability is transitive

4. 비동기 시스템 — 실패 클래스

정의 (기본 원칙)

“작업은 나중에 완료될 수 있으며, 여러 번 수행될 수도 있고, 순서가 뒤바뀔 수도 있습니다.”

이는 시간을 분리하지만 보장을 제거합니다.

실패 클래스 1: 중복 실행

질문: 작업을 재시도하면 어떻게 되나요?

현실:

  • 최소 한 번 전달
  • 워커가 충돌
  • 메시지가 재처리

실패 모드: 동일한 논리적 작업이 여러 번 발생하여 정확히 한 번 실행 보장 및 멱등성 가정을 깨뜨립니다.

실패 클래스 2: 순서 위반

질문: 순서는 무엇에 의해 정의되나요?

현실:

  • 큐는 비즈니스 순서를 알지 못함
  • 워커가 독립적으로 처리

실패 모드: 효과가 논리적 순서와 다르게 나타납니다.
예시 (채팅 시스템): 미래 메시지를 기반으로 한 응답 → 컨텍스트 손상.

실패 클래스 3: 완료 가시성 부재

질문: 사용자는 작업이 언제 완료됐는지 어떻게 알 수 있나요?

현실:

  • 직접적인 신호가 없음
  • 폴링하거나 추측

실패 모드: 사용자는 눈감고 기다리거나 오래된 상태를 보게 됩니다.

실패 클래스 4: 고아 작업

질문: 사용자가 사라지면 어떻게 되나요?

현실:

  • 작업이 계속 실행됨
  • 응답이 저장되지만 소비되지 않음

실패 모드: 낭비된 연산과 누수된 상태.

요약: 비동기 실패 클래스

카테고리근본 원인
중복재시도
재정렬분리된 실행
가시성 부재직접적인 완료 경로 없음
고아분리된 수명 주기

5. Side‑by‑Side Contrast (Mental Model)

차원동기식비동기식
시간CoupledDecoupled
실패 유형Blocking, cascadesDuplication, disorder
가용성All‑or‑nothingPartial
정확성 위험Latency‑basedLogic‑based
디버깅EasierHarder

6. Deep Insight (Interview Gold)

  • 동기식 시스템크게 그리고 즉시 실패한다 (타임아웃, 오류).
  • 비동기식 시스템조용히 그리고 나중에 실패한다 (이중 쓰기, 순서 오류).

7. 왜 어느 쪽도 “더 낫다”고 할 수 없는가

From first principles:

  • Sync systems인과관계를 보호하지만 가용성을 희생한다.
  • Async systems가용성을 보호하지만 인과관계를 희생한다.

Real systems re‑introduce the lost property:

  • Async systems멱등성, 정렬, 상태 머신을 추가한다.
  • Sync systems타임아웃, 서킷 브레이커, 폴백을 추가한다.

8. 기억해야 할 한 줄 규칙

  • Sync breaks under load.
    부하가 걸리면 Sync가 깨집니다.

  • Async breaks under ambiguity.
    불확실성 하에서는 Async가 깨집니다.

Next steps:

  • 이 실패 유형들을 실제 장애에 매핑합니다.
  • 스트리밍이 두 실패 유형을 어떻게 결합하는지 보여줍니다.
  • 새 시스템에서 실패 유형을 식별하는 연습을 합니다.
Back to Blog

관련 글

더 보기 »

프로덕션 급 마켓플레이스 백엔드

왜 marketplace 백엔드는 출시 후에 실패하고, 정확성을 위한 설계는 어떻게 해야 하는가 대부분의 marketplace 백엔드는 기능이 부족해서 실패하지 않는다. 그들은 … 때문에 실패한다.

Go의 비밀스러운 삶: Concurrency

경쟁 조건(race condition)의 혼란에 질서를 부여한다. Chapter 15: Sharing by Communicating 아카이브는 그 화요일에 유난히 시끄러웠다. 목소리 때문이 아니라 t...