---
kind: REFERENCE
slug: analysis-finding-a03-f003
title: legacy compatibility surface의 제거 조건을 세 가지로 고정한다
topic: multitenancy-isolation
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: reference:analysis-finding-a03-f003
verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
---

# legacy compatibility surface의 제거 조건을 세 가지로 고정한다

## 목적

이름이 deprecated 이거나 legacy 라는 이유로 아직 배선되어 있는 호환 표면을 지워, 마이그레이션이 끝나기 전에 경로가 끊기는 것을 막는다.

## 규칙

1. 이름은 삭제 가능성의 증거가 아니다
   deprecated 표시는 방향을 말하지 그 시점을 말하지 않는다.

2. 세 조건이 함께 확인되어야 제거 후보가 된다
   외부 프로덕션 참조 0, 대체 경로의 특성화, 설정 경로 제거다.

3. 외부 참조 0 만으로는 부족하다
   대체 경로가 같은 동작을 증명하지 못하면 지우는 순간 동작이 바뀐다.

4. 설정 경로가 남아 있으면 운영자가 여전히 그것을 켤 수 있다
   코드에서 지워도 설정이 남아 있으면 기동 오류가 된다.

5. 실제 제거는 별도 결정 증거를 요구한다
   이 규칙은 후보를 고르는 기준이지 제거 자체를 승인하지 않는다.

## 적용 조건

deprecated 나 legacy 계약이 아직 프로덕션 어댑터나 런타임 배선에 연결된 마이그레이션 구간

## 예외

외부 호환 계약을 의도적으로 유지하는 경우와 대체 경로가 아직 동일 동작을 증명하지 못한 경우에는 제거하지 않는다.

## 예시

deprecated 계약이 프로덕션 배선에 여전히 사용된다. 이름만 보고 죽은 코드로 판단하면 어댑터와 런타임 마이그레이션이 끝나기 전에 경로가 끊긴다.

## 관계

- **notification admin atomic claim contract가 service에서 사용되지 않음**
  같은 리프에서 옛 경로가 남아 있는 사례다.
- **같은 개념의 두 어휘가 공존하면 하나를 죽은 것으로 표시한다**
  같은 계열의 짝 규칙이다.
- **중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다**
  제거 전에 확인해야 할 것을 다룬 규칙이다.