레거시 리팩터링 전략

            비즈니스 임팩트 높음
                    │
         Q2         │         Q1
    (전략적 부채)     │    (지금 당장!)
    ─ 장기 플랜 수립   │    ─ 즉시 착수
    ─ 아키텍처 로드맵   │    ─ 안전망 + 점진 개선
                    │
  ──────────────────┼──────────────────
                    │
         Q4         │         Q3
    (무시해도 됨)     │    (기회 비용 고려)
    ─ 건드리지 않기    │    ─ 자주 건드릴 때만
    ─ 에너지 낭비     │    ─ Boy Scout Rule
                    │
            변경 빈도/장애 빈도 높음

// 레거시 주문 금액 계산 — 로직이 복잡하고 문서가 없음
// Characterization test: 현재 동작을 스냅샷으로 고정
@Test
void 기존_할인_로직_동작_고정() {
    LegacyOrderCalculator calc = new LegacyOrderCalculator();

    // 현재 동작 그대로 기록 (맞든 틀리든)
    assertThat(calc.calculate(1000, "VIP", 3))
        .isEqualTo(2550);  // 1000 * 3 * 0.85 = 2550

    assertThat(calc.calculate(500, "NORMAL", 1))
        .isEqualTo(500);   // 할인 없음

    assertThat(calc.calculate(1000, "VIP", 0))
        .isEqualTo(0);     // 수량 0일 때 동작 확인

    // 엣지 케이스: 음수 수량 — 현재 동작이 무엇인지 기록
    assertThat(calc.calculate(1000, "VIP", -1))
        .isEqualTo(-850);  // 버그일 수 있지만, 지금은 고정만
}

@Test
void 월간_리포트_출력_Golden_Master() {
    ReportGenerator generator = new ReportGenerator();
    String actual = generator.generate(testData);

    // 최초 실행: 결과를 golden master로 저장
    // 이후 실행: 저장된 결과와 비교
    assertThat(actual).isEqualToNormalizingNewlines(
        Files.readString(Path.of("src/test/resources/golden/monthly-report.txt"))
    );
}

// 레거시 메서드에 관측성 추가 (로직 변경 없이)
public OrderResult processOrder(OrderRequest request) {
    Timer.Sample sample = Timer.start(meterRegistry);
    try {
        OrderResult result = legacyProcessOrder(request);
        sample.stop(Timer.builder("legacy.order.process")
            .tag("status", "success")
            .register(meterRegistry));
        return result;
    } catch (Exception e) {
        sample.stop(Timer.builder("legacy.order.process")
            .tag("status", "error")
            .tag("error_type", e.getClass().getSimpleName())
            .register(meterRegistry));
        throw e;
    }
}

1단계: 관측성 (로그/메트릭/트레이스)
   ↓   "어디서 무엇이 깨지는지" 빨리 파악
2단계: Characterization test
   ↓   핫 패스의 현재 동작을 고정
3단계: Golden master
   ↓   배치/리포트 등 복잡한 출력 고정
4단계: 통합/E2E 테스트
       외부 의존성 포함 전체 플로우 검증

[클라이언트]
     │
     ▼
[라우터/프록시] ──── 비율 제어 (10% → 50% → 100%)
     │         │
     ▼         ▼
  [새 서비스]  [레거시]
     │         │
     ▼         ▼
  [새 DB]    [레거시 DB] ← 동기화 (초기 단계)

// Spring에서 피처 플래그 기반 Strangler 구현
@Service
public class OrderRouter {
    private final LegacyOrderService legacy;
    private final NewOrderService newService;
    private final FeatureFlagService flags;

    public OrderResult processOrder(OrderRequest request) {
        if (flags.isEnabled("new-order-service", request.getUserId())) {
            try {
                OrderResult result = newService.process(request);
                // Shadow 검증: 레거시 결과와 비교 (초기 단계)
                if (flags.isEnabled("shadow-verify")) {
                    OrderResult legacyResult = legacy.process(request);
                    if (!result.equals(legacyResult)) {
                        log.warn("결과 불일치: new={}, legacy={}",
                            result, legacyResult);
                        // 메트릭으로 불일치율 추적
                        meterRegistry.counter("strangler.mismatch").increment();
                    }
                }
                return result;
            } catch (Exception e) {
                log.error("새 서비스 실패, 레거시 폴백", e);
                return legacy.process(request); // 폴백
            }
        }
        return legacy.process(request);
    }
}

// Step 1: 인터페이스 추출 (기존 코드 변경 최소화)
public interface PaymentGateway {
    PaymentResult charge(PaymentRequest request);
    PaymentResult refund(String transactionId, BigDecimal amount);
}

// Step 2: 레거시 구현을 인터페이스로 감싸기
@Component
@Profile("legacy")
public class LegacyPaymentGateway implements PaymentGateway {
    private final OldPaymentModule oldModule; // 기존 코드

    @Override
    public PaymentResult charge(PaymentRequest request) {
        // 레거시 호출을 새 인터페이스에 맞게 어댑팅
        OldPaymentResponse response = oldModule.doPayment(
            request.getAmount().intValue(),
            request.getCardNumber()
        );
        return PaymentResult.from(response);
    }
}

// Step 3: 새 구현 (나중에 교체)
@Component
@Profile("new")
public class StripePaymentGateway implements PaymentGateway {
    @Override
    public PaymentResult charge(PaymentRequest request) {
        // 새로운 Stripe API 사용
        return stripeClient.charge(request);
    }
}

// Before: 직접 의존 — 테스트/교체 불가능
public class ReportService {
    public Report generate() {
        Connection conn = DriverManager.getConnection(DB_URL); // 하드코딩
        SmtpClient smtp = new SmtpClient("mail.company.com");  // 하드코딩
        // ...
    }
}

// After: Seam 생성 — 의존성을 주입 가능하게
public class ReportService {
    private final DataSource dataSource;     // Seam
    private final MailSender mailSender;     // Seam

    public ReportService(DataSource ds, MailSender ms) {
        this.dataSource = ds;
        this.mailSender = ms;
    }
    // 이제 테스트에서 Mock 주입 가능
}

// 코드는 배포되었지만, 기능은 꺼진 상태
@Service
public class SearchService {
    @Autowired private FeatureFlagService flags;

    public SearchResult search(String query) {
        if (flags.isEnabled("elasticsearch-migration")) {
            return elasticSearch(query);  // 새 구현
        }
        return legacyDbSearch(query);     // 기존 구현
    }
}

-- Phase 1: Expand (기존 호환 유지)
ALTER TABLE users ADD COLUMN email_new VARCHAR(320);

-- 배포: 새 컬럼에 쓰기 시작 (읽기는 여전히 old)
-- 백필: UPDATE users SET email_new = email WHERE email_new IS NULL;
-- 검증: 새 컬럼 데이터 정합성 확인

-- Phase 2: Contract (충분한 검증 후)
ALTER TABLE users DROP COLUMN email;
ALTER TABLE users RENAME COLUMN email_new TO email;

1. 동작 변경 없는 구조 개선 (rename, extract method) → PR #1
2. 인터페이스 추출 / Seam 생성                      → PR #2
3. 새 구현 추가 (피처 플래그로 비활성)                → PR #3
4. 피처 플래그 ON + 모니터링                         → PR #4
5. 레거시 코드 제거                                  → PR #5

## 리팩터링 Before/After 기록
- [ ] 해당 모듈 P99 latency: ___ms → 목표 ___ms
- [ ] 월간 인시던트 수: ___건 → 목표 ___건
- [ ] 테스트 커버리지: __% → 목표 __%
- [ ] 평균 PR 리드타임(이 모듈): ___일 → 목표 ___일
- [ ] 변경 시 장애 발생률: __% → 목표 __%

## 착수 전 점검
- [ ] 대상 모듈의 비즈니스 임팩트/장애 빈도/변경 빈도 측정
- [ ] 이해관계자(PM/팀)와 우선순위 합의
- [ ] Before 지표 기록 (latency, error rate, coverage)
- [ ] 안전망 수준 결정 (관측성만? Characterization test까지?)

## 실행 중 점검
- [ ] PR 크기: 파일 5개 이하, 리뷰 30분 이내
- [ ] 각 PR은 독립 롤백 가능
- [ ] 피처 플래그/Shadow 검증 활용
- [ ] 주간 회고에서 불일치율/장애 리뷰

## 완료 후 점검
- [ ] After 지표 기록 및 Before와 비교
- [ ] 레거시 코드/피처 플래그 정리 (기술 부채 잔존 방지)
- [ ] 학습 내용 ADR/위키에 기록