---
kind: CONCEPT
slug: messaging-policy-c05
title: 배치 상한이 개수와 바이트 두 축인 이유
topic: admission-budget-and-backpressure
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: concept:messaging-policy-c05
evidenceCapturedOn: 2026-09-01
assets:
  - key: messaging-policy-c05
    file: ../../../final/evidence/rendered/messaging-policy-c05.svg
evidence:
  - ../../../final/evidence/raw/messaging-policy-c05.txt
source:
  - 원본 분석 절은 analysis/messaging/messaging-policy.md#L423 이다.
module: messaging-policy
---

# 배치 상한이 개수와 바이트 두 축인 이유

개수 상한만으로는 큰 메시지 몇 개가 브로커 프레임을 넘고, 바이트 상한만으로는 아주 많은 작은 메시지가 요청 타임아웃을 넘는다. `checkBatch`가 각 항목에 `checkPayload`도 부르므로 셋이 함께 적용된다.

## 관계

- **구성 오류는 한 예외 타입과 안정 코드로 보고한다**
  같은 분석 리프에서 끌어낸 규칙이다.
- **저장소 밖 문서를 절 번호로 인용하지 않는다**
  같은 분석 리프에서 끌어낸 규칙이다.
- **부팅 경로의 알고리즘 복잡도는 문서화한다**
  같은 분석 리프에서 끌어낸 규칙이다.

## 본문

<!-- body:start -->

**배치 상한이 두 축인 이유**가 적혀 있다.

```java
// PayloadLimitGuard.java:16-18
 * <p>Batches are limited by count <em>and</em> bytes. A count limit alone lets a handful of large
 * messages exceed the broker's frame; a byte limit alone lets a huge number of tiny messages exceed
 * its request timeout.
```

`checkBatch`가 각 항목에 대해 `checkPayload`도 부르므로 **개별 상한 · 개수 상한 · 총합 상한** 셋이 함께 적용된다.

## 이 기록이 다루는 파일 범위

:::evidence key="messaging-policy-c05" alt="코드베이스에서 파일 목록을 만든 출력 25줄. 이 기록이 다루는 범위가 그 목록이다." caption="코드베이스 파일 목록 — 25줄 · exit 0" zoom="true"
:::

## 프로파일 검증 실패가 MessagingException 밖인 이유

프로파일 검증 실패는 `IllegalArgumentException`이다 — `MessagingException` 계층 밖이다. 시작 시점의 구성 오류이지 메시지 실패가 아니므로 일관적이다. 다만 `MessagingConfigurationException`("Raised at startup wherever possible")이 존재하는데 쓰이지 않는다 — §17의 P3.

<!-- body:end -->