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>
7.7 KiB
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-a14-f006 | 용량 보호 계층 전체(41 main files)가 자기 테스트 픽스처 안에서만 실행된다 | web-inbound-and-http-surface | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:analysis-finding-a14-f006 | 2026-09-01 | case-analysis-finding-a14-f006.body.md |
|
|
|
용량 보호 계층 전체(41 main files)가 자기 테스트 픽스처 안에서만 실행된다
바이트 상한과 마감과 부하 차단과 반응형 속도 제한을 구현한 마흔한 파일 중 프로덕션 컨텍스트에 등록되는 것이 없다. 이 플랫폼을 그대로 배포하면 요청 본문 상한도 응답 상한도 마감도 동시성 상한도 대기열 상한도 없다.
관계
- 멱등 실행 계층과 durable-operation 표면이 픽스처에서만 조립된다 같은 형태의 반복이다.
- 플랫폼 요청 컨텍스트가 서블릿에는 생산자가 없고 리액티브에는 익명 액터로 고정되어 있다 같은 리프의 다른 P1 이다.
- 레인은 게이트가 올바른가를 증명하고 플랫폼이 게이트를 설치하는가는 묻지 않는다 이 사례가 그 규칙의 형태다.
문제
이 리프는 용량 보호 계층을 갖추고 있다.
바이트 경계와 마감, 부하 차단, 속도 제한, 예산 초과 문제 문서다.
각 능력이 프로덕션 배포에서 실제로 설치되는지 확인했다.
결론
대부분 설치되지 않는다.
바이트 경계와 마감을 구현한 일곱 타입이 등록되지 않는다.
부하 차단의 네 타입도 등록되지 않는다.
두 전송의 조절 필터도 등록되지 않는다.
속도 제한은 인터셉터 경로 하나만 있다. 그것은 등록되지만 기본이 비활성이다.
예산 초과 문제 문서 처리기는 기본이 꺼짐이고 의존 빈도 선언되지 않는다.
즉 이 플랫폼을 그대로 배포하면 요청 본문 크기 상한도, 응답 크기 상한도, 요청 마감도, 동시성 상한도, 대기열 상한도 없다.
표준 예산이 정의하고 예산 목록이 담고 있는 값들은 아무도 읽지 않는다.
실패 시나리오는 이렇다.
배포된 API 에 무제한 조각 본문이 도착한다.
예산 필터가 필터 사슬에 없으므로 유계 요청 래퍼가 스트림을 감싸지 않고 예산 계량기가 바이트를 세지 않는다.
컨테이너 기본값 외에 상한이 없다. 그 기본값은 다중 파트와 폼 인코딩에만 적용되고 임의 본문에는 적용되지 않는다.
같은 요청에 대해 동시성 상한도 없으므로 승인 제어기가 내기로 되어 있던 과부하 응답도 나오지 않는다.
왜 드러나지 않는가가 이 모듈의 핵심 형태다.
이 리프는 교차 스택 게이트를 갖고 있다. 세 런타임의 유선 계약을 비교하는 레인과 개별 런타임 계약 레인들이다.
그 레인들은 게이트가 올바른가를 증명한다. 플랫폼이 게이트를 설치하는가는 묻지 않는다.
픽스처 애플리케이션이 필요한 것을 손수 배선해 레인을 돌리기 때문이다.
판정은 P1 이다.
검증 환경
Spring Boot : 4.0.8 확인 방식 : 능력별 구현과 프로덕션 등록 대조 소스 수정 : x
재현 조건
원문은 final/evidence/raw/176 계열에 있다.
- 용량 보호 능력 목록을 만든다.
- 각 능력의 구현 타입을 확인한다.
- 각 타입이 프로덕션 컨텍스트에 등록되는지 확인한다.
- 표준 예산 값을 읽는 코드를 검색한다.
- 계약 레인의 픽스처가 무엇을 손수 배선하는지 확인한다.
본문
프로덕션 배포에서 실제로 설치되는 것과 설치되지 않는 것이 갈린다.
| 능력 | 구현 | 프로덕션 등록 |
|---|---|---|
| 요청/응답 바이트 바운드 · 데드라인 | WebMvcBudgetFilter(122) · WebFluxBudgetFilter(122) · BoundedHttpServletRequest(115) · BoundedHttpServletResponse(151) · BoundedServerWebExchange(79) · WebBudgetMeter(89) · WebRequestBudget(141) |
없음 |
| 부하 차단(제한된 동시성 + 제한된 큐 + 503) | SemaphoreAdmissionController(118) · AdmissionProfile(80) · AdmissionDecision(59) · AdmissionPermit(21) |
없음 |
429 속도 제한 (WebRateLimiter 경로) |
WebMvcThrottleFilter(136) · WebFluxThrottleFilter(142) |
없음 |
| 429 속도 제한 (인터셉터 경로) | RateLimitInterceptor ← RateLimitWebConfig |
있음, 기본 비활성(APP_RATE_LIMIT_ENABLED:false) |
| 예산 초과 문제 문서 | WebMvcBudgetExceptionHandler(84) |
기본 꺼짐 + 의존 빈 미선언 |
WebBudgetCatalog 참조 위치
:::evidence key="analysis-finding-a14-f006" alt="코드베이스에서 WebBudgetCatalog 를 검색한 출력 5줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="WebBudgetCatalog 코드베이스 검색 — 5줄 · exit 0" zoom="true" :::
그대로 배포하면 상한이 하나도 없다
요청 본문 크기 상한도, 응답 크기 상한도, 요청 데드라인도, 동시성 상한도, 큐 상한도 없다. WebRequestBudget.standard()가 정의하고 WebBudgetCatalog가 담고 있는 값들은 아무도 읽지 않는다(§15.3). P1.
왜 드러나지 않는가
이 leaf는 크로스 스택 게이트를 갖고 있다. webCrossStackParityTest가 Tomcat·Jetty·Reactor Netty 세 런타임의 와이어 계약을 비교하고, JettyWebBudgetIT · ReactiveWebBudgetIT · JettyWebThrottleIT · ReactiveWebThrottleIT가 예산과 스로틀을 실제로 검증한다. 그런데 그 IT들이 띄우는 것은 BudgetFixtureApplication 계열이고, 그 픽스처들이 FilterRegistrationBean으로 필터를 손수 등록한다. 레인은 "필터가 올바르게 동작하는가"를 세 런타임에서 증명하고, "플랫폼이 필터를 설치하는가"는 어디서도 묻지 않는다.
이 저장소가 이미 이름 붙인 형태다
EndpointGuardCallSiteTest(notification)의 javadoc이 그 문장을 갖고 있다 — "A green test on a control nothing invokes is the shape this repository keeps finding, and testing the helper again would not have caught it." 여기서는 그 형태가 41개 파일 규모로 반복된다.
권고
WebMvcPlatformAutoConfiguration·WebFluxPlatformAutoConfiguration이 이미 WebBudgetCatalog를 등록하므로 자리는 있다. 네 필터와 SemaphoreAdmissionController, BudgetProblemMapper를 같은 자동설정에서 backend.web.budgets.enabled 게이트 아래 등록하고, 픽스처가 아니라 자동설정이 세운 컨텍스트에서 하나 이상의 IT를 돌린다.
확인하지 못한 것
배포해서 큰 본문을 보내 상한 부재를 재현하지 않았다. 등록 부재상 그 결과가 나온다.
실패 시나리오 — 배포된 API에 무제한 청크 본문이 도착한다. WebMvcBudgetFilter가 필터 체인에 없으므로 BoundedHttpServletRequest가 스트림을 감싸지 않고, WebBudgetMeter가 바이트를 세지 않는다. 컨테이너 기본값(Tomcat maxPostSize는 multipart/form-data와 폼 인코딩에만 적용되고 임의 본문에는 적용되지 않는다) 외에 상한이 없다. 같은 요청에 대해 동시성 상한도 없으므로 SemaphoreAdmissionController가 내기로 되어 있던 503도 나오지 않는다.