document-haness/docs/clean-architecture-backend-template/tech-log-studio/messaging-and-outbox/case/case-analysis-finding-a19-f002.md

kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, body, assets, evidence, source

kind	slug	title	topic	project	status	sourceRevision	rootTreeNode	evidenceCapturedOn	body	assets	evidence	source
CASE	analysis-finding-a19-f002	8개 profile validator 중 조립에서 실행되는 것은 3개	messaging-and-outbox	clean-architecture-backend-template	게시 전	21234e38cdb9a926cbc92bb97a2aee2e4a7d2916	case:analysis-finding-a19-f002	2026-09-01	case-analysis-finding-a19-f002.body.md	key file analysis-finding-a19-f002 ../../../final/evidence/rendered/analysis-finding-a19-f002.svg	../../../final/evidence/raw/analysis-finding-a19-f002.txt	원본 분석 절은 final/document.md#a19#L288 이다.

8개 profile validator 중 조립에서 실행되는 것은 3개

시작 검증 도우미의 자바독이 이미 한 번 고쳐진 같은 결함을 서술한다. 검증기들이 전부 빈이었는데 아무 데도 주입되지 않아 아무것도 검증하지 않았다는 것이다. 그 수정이 적용된 것은 둘이고, 주 소스의 검증기 여덟 중 실행되는 것은 셋이다.

관계

• capability 12개 중 main 코드가 읽는 것은 3개이고 거부하는 것은 1개다 같은 가족의 같은 형태다.
• 브로커 권한 매니페스트의 자기 점검이 존재하지 않는다 같은 계열의 시작 검증 부재다.
• 같은 결함이 이미 한 번 고쳐졌는데 나머지에는 적용되지 않았다 이 사례가 그 규칙의 형태다.

문제

시작 검증 도우미의 자바독이 이미 고쳐진 결함을 서술한다.

브로커 두 종과 보안 검증기가 전부 빈이었는데 아무 데도 주입되지 않았다는 것이다. 컨텍스트가 브로커마다 검증기를 발행하고 아무것도 검증하지 않았다는 것이다.

브로커가 줄 수 없는 보증을 약속하는 프로파일이 깨끗하게 부팅하고 그것에 의존하는 첫 메시지에서 실패한다는 것이다.

수정 방식도 정확하다.

초기화 콜백으로 돌려서 컨텍스트가 아직 만들어지는 중에 실패하고 원인이 된 프로파일 빈이 스택에 이름으로 남게 한다.

그리고 프로파일을 공급자로 받는다. 애플리케이션이 선언한 빈과 설정에서 컴파일된 프로파일 두 출처를 모두 보기 위해서다.

결론

그 수정이 적용된 것은 둘이다.

주 소스에 존재하는 프로파일 검증기 여덟 전체의 도달성을 확인했다.

목적지 검증기는 핵심 자동 설정이 검증 메서드를 직접 부른다. 실행된다.

브로커 두 종의 검증기는 각자의 자동 설정이 시작 검증 도우미로 감싼다. 실행된다.

브로커 트랜잭션 검증기는 출하 리프에 있고 자동 설정이 빈으로 선언만 한다. 주입처가 없다. 실행되지 않는다.

나머지는 빌드 전용 리프이거나 조립 지점이 없다.

즉 여덟 중 셋만 실행된다.

그리고 실행되지 않는 것 중 하나는 출하 리프의 것이다.

판정은 P2 다.

검증 환경

Spring Boot : 4.0.8 확인 방식 : 검증기별 조립 지점과 주입처 확인 소스 수정 : x

재현 조건

원문은 final/evidence/raw/252 계열에 있다.

1. 시작 검증 도우미의 자바독을 읽는다.
2. 주 소스의 프로파일 검증기를 모두 나열한다.
3. 각각의 리프와 출하 여부를 확인한다.
4. 각각의 조립 지점을 찾는다.
5. 빈 선언만 있고 주입처가 없는 것을 가려낸다.

본문

StartupProfileValidation의 javadoc이 이미 한 번 고쳐진 같은 결함을 서술한다.

"The Kafka, RabbitMQ and security validators were all beans and none of them was injected anywhere: the context published a validator per broker and validated nothing. A profile that promises a guarantee its broker cannot give — an exactly-once claim on a non-transactional producer, a quorum ack on a single replica, a plaintext credential on a production listener — then boots cleanly and fails on the first message that depends on it."

StartupProfileValidation 참조 위치

:::evidence key="analysis-finding-a19-f002" alt="코드베이스에서 StartupProfileValidation 를 검색한 출력 4줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="StartupProfileValidation 코드베이스 검색 — 4줄 · exit 0" zoom="true" :::

수정 방식도 정확하다

InitializingBean.afterPropertiesSet으로 돌려서 "컨텍스트가 아직 만들어지는 중에 실패하고 원인이 된 프로파일 bean이 스택에 이름으로 남게" 한다. 그리고 프로파일을 ObjectProvider가 아니라 Supplier로 받는다 — 애플리케이션이 선언한 bean과 app.messaging에서 컴파일된 프로파일 두 출처를 모두 보기 위해서다.

여덟 validator의 도달성

validator	leaf	출하?	조립 지점	실행되는가
DestinationProfileValidator	policy	출하	MessagingCoreAutoConfiguration:134	✔
KafkaProfileValidator	kafka	출하	KafkaMessagingAutoConfiguration:58 → StartupProfileValidation	✔
RabbitProfileValidator	rabbit	출하	RabbitMessagingAutoConfiguration:54 → StartupProfileValidation	✔
KafkaTransactionProfileValidator	kafka	출하	KafkaMessagingAutoConfiguration:74 — @Bean 선언만, 주입처 없음	✘
KafkaShareProfileValidator	kafka-share	build-only	registrar가 보유, 테스트에서만 생성	✘ (등급 일치)
NatsJetStreamProfileValidator	nats	build-only	참조가 javadoc 문장 하나	✘ (등급 일치)
PulsarProfileValidator	pulsar	build-only	참조 0건 — 테스트조차 없다	✘ (등급 일치)
BindingProfileValidator	scs-bridge	build-only	테스트에서만 생성	✘ (등급 일치)

build-only 넷은 등급과 일치한다

어떤 런타임에도 오르지 않으므로 조립 지점이 없는 것이 등급과 일치한다 — 오늘의 사고가 아니라 채택 시점의 부채다. 다만 PulsarProfileValidator는 테스트조차 없어서 다른 셋과도 다르다. P2.

확인하지 못한 것

잘못된 프로파일로 띄워 검증되지 않는 것을 재현하지 않았다. 주입처 부재상 그 결과가 나온다.