--- kind: CASE slug: analysis-finding-a19-f004 title: 스키마 호환성 검증기는 출하 leaf에 있고, main 코드에서 호출되지 않는다 topic: messaging-and-outbox project: clean-architecture-backend-template status: 게시 전 sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 rootTreeNode: case:analysis-finding-a19-f004 evidenceCapturedOn: 2026-09-01 body: case-analysis-finding-a19-f004.body.md assets: - key: analysis-finding-a19-f004 file: ../../../final/evidence/rendered/analysis-finding-a19-f004.svg evidence: - ../../../final/evidence/raw/analysis-finding-a19-f004.txt source: - 원본 분석 절은 final/document.md#a19#L390 이다. --- # 스키마 호환성 검증기는 출하 leaf에 있고, main 코드에서 호출되지 않는다 검증기의 주 참조가 0 건이다. 그것이 거부하도록 만들어진 검사 없음 모드는 설정으로 켤 수 있고, 그 설정을 막는 다른 규칙도 없다. 게다가 검증기가 읽어야 할 이력의 출처 자체가 프로덕션에 없다. ## 관계 - **호환성 게이트를 가진 두 포맷은 build-only이고 출하되는 유일한 코덱에는 게이트가 없다** 같은 공백의 다른 면이다. - **8개 profile validator 중 조립에서 실행되는 것은 3개다** 같은 가족의 같은 형태다. - **검사하지 않는 모드는 설계 중에는 유용하고 보존 로그가 생긴 뒤에는 위험하다** 자바독이 적은 근거다. ## 문제 스키마 호환성 검증기가 출하 리프에 있다. 주 참조를 셌다. ## 결론 0 건이다. 테스트 하나뿐이다. 이 클래스가 하는 일은 둘이다. 하나는 호환성 모드에 따라 비교해야 할 후보 판본 목록을 돌려주는 것이다. 이행 모드면 전체 이력이고 짝 모드면 직전 하나다. 다른 하나는 검사 없음 실험 모드를 운영 목적지에서 거부하는 것이다. 두 번째의 근거가 클래스 자바독에 있다. 아무것도 검사하지 않는 모드는 메시지 타입을 설계하는 동안에는 유용하고 보존 로그가 생기면 능동적으로 위험하다는 것이다. 로그가 그것을 아직 읽을 수 있는 모든 소비자보다 오래 살기 때문이라는 것이다. 그리고 그 모드는 설정으로 켤 수 있다. 목적지 설정의 기본값이 안전한 값이지만, 설정으로 검사 없음 실험 모드를 쓰면 그대로 통과한다. 목적지 프로파일 검증기의 열여섯 규칙에 스키마 항목이 없고, 거부 메서드는 호출되지 않는다. 부수적으로 스키마 저장소에는 주 구현이 하나도 없다. 유일한 구현은 검증기 테스트 안의 고정 저장소다. 즉 검증기가 읽어야 할 스키마 이력의 출처 자체가 프로덕션에 존재하지 않는다. 호출하려 해도 넘길 저장소가 없다. 같은 가족에서 코덱 저장소가 겪었고 등록 목록 타입으로 해결된 것과 같은 모양이고, 이쪽은 아직 해결되지 않았다. 실패 시나리오는 이렇다. 운영자가 한 목적지에 검사 없음 모드를 설정한다. 설계 중이라는 정당한 이유다. 그 설정이 그대로 프로덕션으로 나간다. 보존 로그에 이전 판본으로 쓴 메시지가 남고, 이후 판본이 필드를 삭제하면 그 로그를 읽는 소비자가 깨진다. 판정은 P2 다. ## 검증 환경 확인 방식 : 참조 계수와 설정 경로 확인, 저장소 구현 검색 소스 수정 : x ## 재현 조건 원문은 final/evidence/raw/252 계열에 있다. 1. 검증기의 주 참조를 센다. 2. 두 메서드가 무엇을 하는지 읽는다. 3. 클래스 자바독의 거부 근거를 읽는다. 4. 목적지 설정에서 호환성 모드의 기본값과 설정 가능성을 확인한다. 5. 목적지 프로파일 검증기의 규칙에 스키마 항목이 있는지 확인한다. 6. 스키마 저장소의 주 구현을 검색한다. ## 본문 `SchemaCompatibilityValidator`(`messaging-schema-api`, **출하**)의 main 참조는 **0건**이다. 테스트 1개뿐. ## SchemaCompatibilityValidator 참조 위치 :::evidence key="analysis-finding-a19-f004" alt="코드베이스에서 SchemaCompatibilityValidator 를 검색한 출력 2줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="SchemaCompatibilityValidator 코드베이스 검색 — 2줄 · exit 0" zoom="true" ::: ## 이 클래스가 하는 일 둘 1. `versionsToCheck(subject)` — 호환성 모드에 따라 후보 스키마를 비교해야 할 버전 목록(transitive면 전체 이력, pairwise면 직전 하나)을 돌려준다. 2. `requireProductionMode(subject, destination)` — `NONE_EXPERIMENTAL`을 production destination에서 **거부**한다. 두 번째의 근거가 클래스 javadoc에 있다 — "`NONE_EXPERIMENTAL` is refused for production destinations. A mode that checks nothing is useful while a message type is being designed and **actively dangerous once a retained log exists, because the log outlives every consumer that could still read it.**" ## 그리고 그 모드는 설정으로 켤 수 있다 `DestinationSettings.Schema`의 `@DefaultValue("BACKWARD_TRANSITIVE")`가 안전한 값이지만, `app.messaging.destinations..schema.compatibility=NONE_EXPERIMENTAL`을 쓰면 그대로 통과한다 — `DestinationProfileValidator`의 16개 규칙에 스키마 항목이 없고(§3.5), `requireProductionMode`는 호출되지 않는다. ## 넘길 registry 자체가 없다 `SchemaRegistry`에는 main 구현이 하나도 없다. 유일한 구현은 `SchemaCompatibilityValidatorTest`의 `FixedRegistry`다. §3.5의 `MessageCodecRegistry`가 겪었고 `RegisteredMessageCodecs`로 해결된 것과 같은 모양이며, 이쪽은 아직 해결되지 않았다. P2. ## 확인하지 못한 것 검사 없음 모드를 설정하고 판본을 진화시켜 소비자가 깨지는 것을 재현하지 않았다. 호출 부재상 그 결과가 나온다.