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.8 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CONCEPT | bounded-and-unbounded-side-by-side | bounded 와 unbounded 오버로드를 나란히 둔 포트 | retention-and-unbounded-growth | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | concept:bounded-and-unbounded-side-by-side | 2026-09-01 |
|
|
|
bounded 와 unbounded 오버로드를 나란히 둔 포트
두 포트가 각각 정리 연산의 무제한 형태와 배치 제한 형태를 오버로드로 나란히 선언한다. 두 형태를 가르는 표시가 없어서 호출자가 인자가 적은 쪽을 골랐다.
관계
- 두 형태를 나란히 내놓는 포트는 이미 안전하지 않은 쪽을 고른 것이다 이 구조에서 나온 규칙이다.
- cleanup 이 스스로 막겠다고 적은 장애를 일으키는 형태로 호출된다 이 구조가 실제로 발현한 사례다.
- 같은 개념의 두 어휘가 공존하면 하나를 죽은 것으로 표시한다 같은 계열의 기존 규칙이다.
본문
두 포트가 각각 purge*Before(Instant) 와 purge*Before(Instant, int) 를 나란히 선언한다. 뒤쪽이 안전한 형태이고 그 이유가 javadoc 에 있다 — "The cleanup jobs describe themselves as bounded by batch size; this is the parameter that makes that true." 두 형태를 가르는 표시는 없다.
두 오버로드를 가르는 표시
:::evidence key="bounded-and-unbounded-side-by-side-diagram" alt="무제한 오버로드와 가르는 표시 없음이 왼쪽에, 배치 제한 오버로드와 javadoc 근거가 오른쪽에 같은 축으로 놓인다" caption="두 오버로드를 가르는 표시" zoom="false" :::
호출자가 인자가 적은 쪽을 고른다
@Deprecated 도, 이름 차이도, 호출을 막는 가시성 차이도 없다.
두 오버로드의 javadoc
:::evidence key="bounded-and-unbounded-side-by-side" alt="분석 문서 final/document.md#a19-messaging-reliability-api 에서 이 기록의 근거 절을 그대로 잘라낸 18줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="final/document.md#a19-messaging-reliability-api 발췌 — 18줄" zoom="true" :::
결함이 호출자에게 있지 않다
같은 리프가 다른 곳에서 같은 형태를 이미 기록했다 — 한 인터페이스가 같은 전이의 두 세대를 갖고 안전하지 않은 쪽에 표시가 없다. 포트의 형태가 오용을 가능하게 했고, 두 리프에서 같은 방향으로 발생했다.
:::note
없음 — 두 포트의 선언과 저장소 전역 호출 지점을 전수 확인했다
:::
두 형태
정리 연산은 기준 시각 이전의 행을 지운다. 무제한 형태는 시각만 받고, 배치 제한 형태는 시각과 최대 건수를 받는다.
두 형태의 차이는 SQL 에서 드러난다. 제한 형태는 건수 제한과 잠긴 행 건너뛰기를 함께 쓴다. 한 번에 지우는 양이 정해져 있으므로 락 보유 시간과 WAL 기록량이 백로그 크기와 무관해진다.
안전한 쪽이 무엇을 참으로 만드는가
배치 제한 오버로드의 javadoc 이 자기 존재 이유를 적는다.
The cleanup jobs describe themselves as bounded by batch size; this is the parameter that makes that true.
정리 잡이 자신을 배치 크기로 제한된다고 서술하는데, 그것을 참으로 만드는 것이 바로 이 파라미터라는 뜻이다.
표시가 없다
두 형태를 가르는 것이 인자 개수뿐이다. 폐기 표시도, 이름 차이도, 호출을 막는 가시성 차이도 없다.
그래서 호출자는 짧은 쪽을 고른다. 그것은 호출자의 부주의가 아니라 포트가 만든 기본값이다. 인자를 하나 더 넘기려면 그 값을 어디서 가져올지 정해야 하고, 그 결정을 미루는 것이 자연스러운 선택이 된다.
같은 리프가 같은 형태를 이미 기록했다
이 포트에는 같은 전이의 두 세대 메서드도 나란히 있다. 안전하지 않은 쪽에 폐기 표시가 없고, production 은 신세대만 쓰지만 그것을 강제하는 것은 없다.
두 사례가 한 인터페이스 안에 있다는 점이 이 개념의 요지다. 포트의 형태가 오용을 가능하게 했고, 같은 방향으로 두 번 발생했다.