DongHyeonkaandClaude Fable 5.1
b25357c48a
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다 - 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5 (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를 techviz 로 만들었다 - 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs 돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다. Concept 이 인용한 코드가 SSOT 에 없어 뺐다 - candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
4.6 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source, module
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | module | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CONCEPT | messaging-spring-cloud-stream-bridge-c03 | 보장에 의존하는 순간 브리지를 거절한다 | admission-budget-and-backpressure | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | concept:messaging-spring-cloud-stream-bridge-c03 | 2026-09-01 |
|
|
|
messaging-spring-cloud-stream-bridge |
보장에 의존하는 순간 브리지를 거절한다
브리지는 상호운용을 위해 존재하고 그 위험은 구체적이다 — Stream이 자기 binder 설정을 소유하므로 목적지 프로파일이 모르는 직렬화기·오류 처리·확인 모드를 바인딩이 조용히 얻을 수 있다. 그래서 플랫폼의 보장에 의존하지 않는 목적지만 허용한다.
관계
- 허용 의존 목록은 상한이므로 미사용을 잡지 않는다 같은 분석 리프에서 끌어낸 규칙이다.
- 등록을 받는 컴포넌트는 해제도 제공한다 같은 분석 리프에서 끌어낸 규칙이다.
- 함께 읽히는 두 맵은 한 값으로 묶는다 같은 분석 리프에서 끌어낸 규칙이다.
- 에러 메시지가 지시하는 설정은 그 설정을 읽는 코드와 함께 존재해야 한다 같은 분석 리프에서 끌어낸 규칙이다.
- 한 개념의 등록 상태를 두 객체가 나눠 갖지 않는다 같은 분석 리프에서 끌어낸 규칙이다.
본문
브리지의 위험이 무엇인지 javadoc이 먼저 적는다.
"The bridge exists for interoperability with existing Spring Cloud Stream bindings, and its risk is specific: Stream owns its own binder configuration, so a binding can quietly acquire its own serializer, its own error handling, and its own acknowledgement mode — none of which the destination profile knows about."
세 거절이 DestinationProfile의 세 필드를 직접 본다.
| 조건 | 코드 |
|---|---|
profile.isOrdered() — orderingScope != NONE |
STREAM_BRIDGE_ORDERING_UNSUPPORTED |
profile.retry().mode() != RetryMode.NONE |
STREAM_BRIDGE_RETRY_UNSUPPORTED |
profile.deadLetter().enabled() |
STREAM_BRIDGE_DLQ_UNSUPPORTED |
브리지가 허용되는 범위
:::evidence key="messaging-spring-cloud-stream-bridge-c03-diagram" alt="가드 경계 안에 순서 없음과 재시도 없음과 DLQ 없음 세 조건이 들어 있고 production 목적지가 경계 밖 점선 상자로 놓인 구조" caption="브리지가 허용되는 범위" zoom="false" :::
세 코드 전부 MessagingConfigurationException이고 안정 코드를 갖는다 — messaging-kafka-share-experimental이 두 거절에 다른 예외 타입을 쓴 것(그쪽 §17)과 대비된다. !enabled도 같은 예외 타입이다. 에러 메시지가 두 선택지를 명시한다 — "remove it from the binding or move the destination to the native adapter". 무엇을 하라고만 하지 않고 어느 쪽을 포기할지를 준다.
DestinationProfile 참조 위치
:::evidence key="messaging-spring-cloud-stream-bridge-c03" alt="코드베이스에서 DestinationProfile 를 검색한 출력 8줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="DestinationProfile 코드베이스 검색 — 8줄 · exit 0" zoom="true" :::
네 번째 게이트
production 목적지는 무조건 거절한다. guard의 세 조건을 통과한 목적지(순서 없음·재시도 없음·DLQ 없음)라도 production이면 막는다. 바인딩 이름 패턴 [a-zA-Z][a-zA-Z0-9-]{0,63} — 언더스코어와 점을 배제한다.
gaps()가 플래그가 아니라 문장을 만드는 이유
**"nothing at runtime will show it"**이 이 record가 존재하는 이유다. 네 boolean과 두 factory: gaps()가 각 false마다 문장 하나를 만든다. 각 문장이 결과까지 적는다 — "indistinguishable", "loses the message". 상태 플래그가 아니라 운영자가 읽는 진술이다. isFullyGuaranteed()가 gaps().isEmpty()다 — 매 호출마다 네 문장을 다시 만든다. 성능 문제는 아니지만 순수 조회가 문자열을 할당한다.