---
kind: CASE
slug: analysis-finding-a10-f003
title: SDK가 선언한 두 진입점에 구현이 없다
topic: caching-and-redis
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: case:analysis-finding-a10-f003
evidenceCapturedOn: 2026-09-01
body: case-analysis-finding-a10-f003.body.md
assets:
  - key: analysis-finding-a10-f003
    file: ../../../final/evidence/rendered/analysis-finding-a10-f003.svg
evidence:
  - ../../../final/evidence/raw/analysis-finding-a10-f003.txt
source:
  - 원본 분석 절은 final/document.md#a10#L251 이다.
---

# SDK가 선언한 두 진입점에 구현이 없다

동기와 반응형 진입점 인터페이스가 각각 열두 접근자를 선언한다. 개별 표면은 사십삼 종이 모두 구현되어 있는데 두 진입점을 구현하는 클래스는 하나도 없다. 대칭 테스트는 인터페이스끼리만 비교하므로 이것을 가리지 못한다.

## 관계

- **README readiness 표가 있는 것을 없다고 적는다**
  같은 리프의 반대 방향 사례이고 원인은 같다.
- **미배선 경계가 문서에만 있고 compile 경로에서 닫히지 않는다**
  같은 형태의 절반 조립이다.
- **인터페이스끼리 비교하는 test는 구현의 부재를 못 본다**
  이 사례가 그 규칙의 형태다.

## 문제

동기 진입점 인터페이스가 자신을 형 있는 API 로의 동기 진입점이라 소개하고, 반응형 인터페이스가 그 짝이다.

두 인터페이스는 각각 열두 접근자를 선언한다. 값과 해시와 리스트와 집합과 정렬 집합과 비트맵과 비트 필드와 확률적 집계와 지리와 스트림과 키와 배치다.

## 결론

둘 다 구현체가 없다.

리프 전체의 구현 선언을 전수 조사했다. 개별 표면은 전부 구현되어 있다. 동기 스물여섯 종과 반응형 열일곱 종이다.

그런데 두 진입점을 구현한다고 선언한 클래스는 0 건이다.

main 안에서 두 타입을 이름으로 부르는 곳도 없다. 유일한 참조가 반응형 인터페이스 자바독의 링크 하나와 대칭 테스트의 반사 두 줄이다.

결과적으로 이 SDK 를 쓰는 코드는 진입점을 얻을 수 없다.

열두 표면을 각각 어디선가 따로 받아야 하고, 진입점이 약속하는 하나의 객체에서 형 있는 표면 전체는 존재하지 않는다.

접근자를 추가하고 반응형 짝을 맞추는 규율은 실행되고 있다. 그 규율이 만드는 대상을 실제로 만드는 코드가 없다.

판정은 P2 다.

데이터 위험은 없다. 없는 타입은 잘못된 답을 주지 않는다.

위험은 API 계약의 신뢰다. 이 리프의 공개 표면 중 가장 먼저 읽히는 두 타입이 구현되지 않은 상태이고, 대칭 테스트가 그 사실을 가리지 못한다. 인터페이스끼리만 비교하기 때문이다.

같은 리프의 준비도 표 사례와 방향이 반대이면서 원인은 같다. 조립이 절반이다.

수정은 이미 존재하는 구현들을 묶는 두 클래스를 추가하고, 대칭 테스트에 두 진입점이 구현을 가진다는 검사를 더하는 것이다.

## 검증 환경

확인 방식 : 구현 선언 전수 조사와 이름 참조 검색
소스 수정 : x

## 재현 조건

원문은 final/evidence/raw/160 계열에 있다.

1. 두 진입점 인터페이스의 접근자 목록을 확인한다.
2. 리프 전체에서 구현 선언을 전수 조사한다.
3. 두 진입점을 구현하는 클래스가 있는지 센다.
4. main 안에서 두 타입 이름을 검색한다.
5. 대칭 테스트가 무엇과 무엇을 비교하는지 확인한다.

## 본문

<!-- body:start -->

SDK가 선언한 두 진입점에 구현이 없다.

## SDK 가 선언한 두 진입점

:::evidence key="analysis-finding-a10-f003" alt="분석 문서 final/document.md#a10 에서 이 기록의 근거 절을 그대로 잘라낸 15줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="final/document.md#a10 발췌 — 15줄" zoom="true"
:::

## 데이터 위험은 없다

없는 타입은 잘못된 답을 주지 않는다. P2.

## 위험은 API 계약의 신뢰다

이 leaf의 공개 표면 중 가장 먼저 읽히는 두 타입이 구현되지 않은 상태이고, 대칭 test가 그 사실을 가리지 못한다 — 인터페이스끼리만 비교하기 때문이다. sub-scope 01의 §5와 방향이 반대이면서 원인은 같다: 조립이 절반이다.

## 수정

이미 존재하는 26개 구현을 묶는 `LettuceRedisOperations` / `LettuceReactiveRedisOperations` 두 클래스를 추가하고, `ApiParityTest`에 "두 facade는 구현을 가진다"는 검사를 더하는 것이다.

## 확인하지 못한 것

두 진입점이 과거에 구현체를 가졌는지 이력에서 확인하지 않았다.

<!-- body:end -->