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>
5.6 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-a16-f006 | 프로파일별 정책 매니페스트가 미배선이라, 자격에서 해석된 프로파일이 아무 예산도 선택하지 않는다 | graphql-surface | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:analysis-finding-a16-f006 | 2026-09-01 | case-analysis-finding-a16-f006.body.md |
|
|
|
프로파일별 정책 매니페스트가 미배선이라, 자격에서 해석된 프로파일이 아무 예산도 선택하지 않는다
클라이언트 프로파일은 검증된 주체에서 정확히 해석되고 요청 문맥에 실린다. 그 값이 선택하는 것은 캐시 키와 지표 태그뿐이다. 정책은 프로파일과 무관하게 단일 빈이다.
관계
- 연산 이름 정책의 두 구현 중 하나만 배선되고 미배선 쪽만 정책 객체를 쓴다 같은 리프의 정책 이원화 사례다.
- 설정으로 정한 파서 한계가 라이브러리에 설치되지 않는다 같은 리프의 다른 미배선 사례다.
- 값이 정확히 해석되어도 그것을 쓰는 조회가 없으면 효과가 없다 이 사례가 그 규칙의 형태다.
문제
이 리프는 클라이언트 프로파일별로 다른 예산을 줄 수 있도록 설계되어 있다.
프로파일이 실제로 예산을 선택하는지 확인했다.
결론
선택하지 않는다.
클라이언트 프로파일은 검증된 주체에서 정확히 해석되고 요청 문맥에 실린다.
그리고 그 값이 선택하는 것은 캐시 키와 지표 태그뿐이다.
정책은 프로파일과 무관하게 단일 빈이다.
설계가 이 구조를 명시적으로 거부한다.
성능 측정된 한계를 애플리케이션 코드가 아니라 환경 매니페스트에 둔다는 것이다.
지금은 코드 안의 기본 정책 하나다.
실패 시나리오는 이렇다.
배포가 내부 배치 클라이언트에는 큰 복잡도 예산을, 공개 이동 클라이언트에는 작은 예산을 주려 한다.
두 프로파일이 자격에서 정확히 구분되고, 두 요청 모두 같은 정책으로 평가된다.
프로파일을 나눈 목적이 달성되지 않으며, 그 사실은 어떤 오류로도 드러나지 않는다.
매니페스트가 약속한 성질도 성립할 기회가 없다.
알 수 없는 프로파일은 관대한 기본값으로 조용히 떨어지는 대신 시작이나 요청 실패가 된다는 것인데, 조회가 일어나지 않기 때문이다.
권고는 단일 정책 빈을 매니페스트 빈으로 바꾸고, 정책을 요구하는 여덟 지점이 요청 문맥의 프로파일로 조회하게 하는 것이다.
매니페스트는 중복 프로파일을 생성자에서 거부하므로 설정 오류가 부팅에서 드러난다.
판정은 P2 다.
검증 환경
확인 방식 : 프로파일 해석 경로와 정책 빈 구성 확인 소스 수정 : x
재현 조건
원문은 final/evidence/raw/182 계열에 있다.
- 클라이언트 프로파일이 어디서 해석되는지 확인한다.
- 그 값이 요청 문맥에 실리는지 확인한다.
- 그 값을 읽는 지점을 모두 센다.
- 정책 빈이 프로파일별인지 단일인지 확인한다.
- 매니페스트 타입의 생성자와 조회 메서드를 읽는다.
본문
클라이언트 프로파일은 검증된 principal에서 정확히 해석되고 요청 컨텍스트에 실린다(§15.2). 그리고 그 값이 선택하는 것은 캐시 키와 지표 태그뿐이다 — 정책은 프로파일과 무관하게 단일 빈이다.
프로파일이 실제로 고르는 것
:::evidence key="analysis-finding-a16-f006" alt="분석 문서 final/document.md#a16 에서 이 기록의 근거 절을 그대로 잘라낸 15줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="final/document.md#a16 발췌 — 15줄" zoom="true" :::
설계가 이 구조를 명시적으로 거부한다
"The design keeps benchmarked limits in an environment manifest rather than in application code." 지금은 코드 안의 GraphQlClientPolicy.defaults(properties) 하나다.
실패 시나리오
배포가 내부 배치 클라이언트에는 큰 복잡도 예산을, 공개 모바일 클라이언트에는 작은 예산을 주려 한다. 두 프로파일이 자격에서 정확히 구분되고, 두 요청 모두 같은 GraphQlClientPolicy로 평가된다. 프로파일을 나눈 목적이 달성되지 않으며, 그 사실은 어떤 오류로도 드러나지 않는다 — GraphQlClientPolicyManifest가 약속한 "An unknown profile is a startup or request failure rather than a silent fallback to a permissive default"는 조회가 일어나지 않으므로 성립할 기회가 없다. P2.
권고
GraphQlClientPolicy 단일 빈을 GraphQlClientPolicyManifest 빈으로 바꾸고, 정책을 요구하는 여덟 지점이 요청 컨텍스트의 프로파일로 조회하게 한다. 매니페스트는 중복 프로파일을 생성자에서 거부하므로 설정 오류가 부팅에서 드러난다.
확인하지 못한 것
두 프로파일로 요청을 보내 같은 예산이 적용되는 것을 재현하지 않았다. 단일 빈 구성상 그 결과가 나온다.