--- kind: CONCEPT slug: bounded-and-unbounded-side-by-side title: bounded 와 unbounded 오버로드를 나란히 둔 포트 topic: retention-and-unbounded-growth project: clean-architecture-backend-template status: 게시 전 sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 rootTreeNode: concept:bounded-and-unbounded-side-by-side evidenceCapturedOn: 2026-09-01 assets: - key: bounded-and-unbounded-side-by-side file: ../../../final/evidence/rendered/bounded-and-unbounded-side-by-side.svg - key: bounded-and-unbounded-side-by-side-diagram file: ../../../final/assets/diagrams/bounded-and-unbounded-side-by-side.svg evidence: - ../../../final/evidence/raw/bounded-and-unbounded-side-by-side.txt source: - 원본 분석 절은 analysis/messaging/messaging-reliability-api.md §17 · analysis/messaging/messaging-inbox-jdbc-postgresql.md §17 이다. --- # 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="분석 문서 analysis/messaging/messaging-reliability-api.md 에서 이 기록의 근거 절을 그대로 잘라낸 18줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="analysis/messaging/messaging-reliability-api.md 발췌 — 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 은 신세대만 쓰지만 그것을 강제하는 것은 없다. 두 사례가 한 인터페이스 안에 있다는 점이 이 개념의 요지다. 포트의 형태가 오용을 가능하게 했고, 같은 방향으로 두 번 발생했다.