아무도 원하지 않은 중복 인프라, 왜 쌓이는가
M&A(인수합병)와 반복되는 비즈니스·기술 이니셔티브는 조직 내에 예상치 못한 부산물을 남긴다. 바로 **중복 인프라(Duplicate Infrastructure)**다. 새로운 서비스를 도입할 때마다 기존 시스템을 완전히 대체하지 못하고 병존하게 되면서, 유지보수 비용은 늘고 일관성은 무너진다. 특히 Java 백엔드 시스템이 오랜 기간 운영된 조직일수록 이 문제는 더욱 심각하다. 레거시 Spring MVC 애플리케이션 위에 새로운 Spring Boot 마이크로서비스가 얹히고, 그 위에 또 다른 플랫폼이 추가되는 식이다.
플랫폼 팀 입장에서는 이 상황이 단순한 기술 부채를 넘어 조직적 마찰로 이어진다. 어떤 팀이 어떤 인프라를 소유하는지 불분명해지고, 장애 대응 시 책임 소재가 모호해진다. 현대화를 논의할 때 "그냥 다시 짜면 되지 않나요?(Just rewrite it)"라는 말이 나오는 배경도 여기에 있다.
"그냥 다시 짜자"가 위험한 이유
현장에서 리라이트(Rewrite) 전략은 매력적으로 들린다. 레거시 코드의 복잡성을 한 번에 털어낼 수 있다는 기대감 때문이다. 하지만 실제로 플랫폼 팀들이 경험하는 현실은 다르다.
- 비즈니스 로직 유실: 수년간 암묵적으로 쌓인 예외 처리와 도메인 규칙이 코드 어딘가에 숨어 있다. 완전 재작성은 이를 놓칠 위험이 크다.
- 이중 운영 비용: 새 시스템이 안정화될 때까지 구 시스템과 병행 운영해야 한다. 결국 중복 인프라 문제가 한시적으로 더 심화된다.
- 일정 과소 산정: "3개월이면 될 것 같다"는 예측이 1년 이상의 프로젝트로 이어지는 사례는 흔하다.
// 레거시 코드에서 흔히 발견되는 패턴 - 비즈니스 규칙이 유틸리티 메서드에 숨어 있음
public class LegacyOrderUtils {
public static boolean isEligibleForDiscount(Order order) {
// 10년간 쌓인 예외 케이스들...
if (order.getCustomerType() == null) return false;
if (order.getCreatedAt().isBefore(LEGACY_DATE)) return true;
// ...수십 줄의 암묵적 규칙
}
}
이런 코드는 리라이트 과정에서 누락되거나 잘못 해석되기 쉽다.
현대화의 현실적 접근: 점진적 전환
플랫폼 팀들이 실무에서 더 안정적이라고 느끼는 접근은 스트랭글러 피그 패턴(Strangler Fig Pattern) 기반의 점진적 전환이다. 전체를 한 번에 교체하는 대신, 기능 단위로 새 시스템으로 트래픽을 이전하면서 구 시스템을 서서히 고사시키는 방식이다.
// API Gateway 혹은 라우터 레벨에서 점진적 트래픽 전환 예시
@RestController
public class OrderController {
@GetMapping("/orders/{id}")
public ResponseEntity<Order> getOrder(@PathVariable Long id) {
if (featureFlag.isEnabled("new-order-service")) {
return newOrderService.findById(id);
}
return legacyOrderService.findById(id); // 구 시스템 유지
}
}
이 방식은 중복 인프라를 일시적으로 허용하되, 제거 시점과 기준을 명확히 정의한다는 점에서 통제 불가능한 중복과 구별된다. 현대화란 결국 새로운 것을 쌓는 게 아니라, 기존 것을 안전하게 제거하는 과정이기도 하다.
정리
- M&A와 반복적인 기술 이니셔티브는 의도하지 않은 중복 인프라를 만들어내며, 이는 조직적 마찰과 유지보수 비용 증가로 이어진다.
- "그냥 다시 짜자"는 접근은 비즈니스 로직 유실, 이중 운영 부담, 일정 초과라는 세 가지 리스크를 동반한다.
- 현실적인 현대화 전략은 완전 재작성보다 점진적 전환과 명확한 제거 계획을 병행하는 방향이 더 안전하다.