---
id: P-REINFORCE-WIKI-3576D819
category: "10_Wiki/💡 Topics/01_Process_Methodology"
confidence_score: 0.95
tags: ['refactoring', 'strangler-fig-pattern', 'ports-and-adapters-(hexagonal-architecture)', 'software-architecture-erosion', 'technical-debt', 'process-methodology']
last_reinforced: 2026-05-02
---

# [[Refactoring]]

## 📌 Brief 신Summary
리팩토링(Refactoring)은 변화하는 요구사항과 시스템 확장에 대응하고 기술 부채를 해결하기 위해, 소프트웨어의 기존 코드나 아키텍처를 점진적으로 재구조화하는 과정을 의미합니다 [1, 2]. 초기 MVP 개발을 위해 선택한 단순한 아키텍처(예: 계층형 아키텍처)가 시스템 규모가 커짐에 따라 한계에 부딪힐 때, 보다 모듈화되고 확장 가능한 아키텍처(예: 헥사고날, 마이크로서비스)로 전환하기 위한 필수적인 진화 단계로 활용됩니다 [2-4].

## 📖 Core Content
- **아키텍처 진화와 기술 부채 해소:** 스타트업이나 소규모 프로젝트는 빠른 출시를 위해 단순한 계층형 아키텍처(Layered Architecture)나 모놀리식(Monolithic) 구조로 시작하는 경우가 많습니다 [4, 5]. 하지만 시스템이 성장하고 프레임워크나 데이터베이스를 업그레이드해야 할 때, 이러한 구조는 심각한 기술 부채와 보안 부채를 유발할 수 있으므로 헥사고날(Hexagonal)이나 마이크로서비스 아키텍처로의 리팩토링이 불가피합니다 [1, 3].
- **점진적 마이그레이션(Incremental Refactoring):** 아키텍처 리팩토링은 위험성이 큰 "빅뱅(Big bang)" 방식의 전면 재구축을 피하고 점진적으로 이루어져야 합니다 [6]. 예를 들어, 새로운 기능을 위해 포트와 어댑터(Ports/Adapters)를 도입하여 기존 레거시 컴포넌트의 결합도를 서서히 낮추거나 [6, 7], 스트랭글러 피그 패턴(Strangler Fig Pattern)을 활용해 모놀리식 컴포넌트를 점진적으로 서버리스 서비스로 대체하는 방식이 권장됩니다 [8].
- **안전한 리팩토링을 위한 아키텍처 설계:** 클린 아키텍처(Clean Architecture)나 헥사고날 아키텍처와 같이 도메인 핵심 비즈니스 로직을 격리하는 구조는, 기술이나 프로토콜에 관계없이 내부 로직을 보호하므로 최소한의 위험으로 안전하게 테스트하고 리팩토링할 수 있는 환경을 제공합니다 [9].
- **아키텍처 침식(Architecture Erosion)에 대한 치료적 조치:** 소프트웨어 아키텍처는 시간이 지남에 따라 의도된 설계와 실제 구현 사이에 격차가 발생하는 '아키텍처 침식'을 겪게 됩니다 [10]. 기술 부채 누적 등으로 인해 발생하는 이러한 침식을 해결하고 시스템을 유지보수하기 위한 주요 치료적 조치(Remedial measures)로 리팩토링과 재설계(Redesign)가 수행됩니다 [11].

## ⚖️ Trade-offs & Caveats
- **개발 중·후반부의 높은 복잡성:** 아키텍처 패턴을 변경하거나 큰 규모의 리팩토링을 개발 중·후반부에 시도할 경우, 이미 구축된 의존성과 코드베이스의 복잡성으로 인해 상당한 고통과 막대한 노력이 수반될 수 있습니다 [2, 12].
- **강한 결합(Tight Coupling) 환경에서의 리팩토링 취약성:** 경계가 불분명해진 계층형 아키텍처나 구조가 엉킨 모놀리식 시스템에서는, 컴포넌트 간의 강한 결합으로 인해 리팩토링 시 통합 테스트가 깨지기 쉽고(brittle), 예측 불가능한 연쇄 오류가 발생할 위험이 큽니다 [13, 14].
- **비용과 시간의 제약:** 기술 부채를 상환하고 시스템 성능을 최적화하기 위해 리팩토링이 필요하지만, 초기부터 서비스 분리(예: 마이크로서비스)를 염두에 두지 않고 만들어진 모놀리식 시스템을 분해하는 것은 상당한 개발 기간과 운영 인프라 변경 비용을 요구합니다 [2, 15].

## 🔗 Knowledge Connections

### Related Concepts

#### [마이그레이션/전환 전략]
- [[Strangler Fig Pattern]]
  - 연결 이유: 기존 모놀리식 아키텍처에서 서버리스나 마이크로서비스로 리팩토링할 때 사용되는 대표적인 점진적 마이그레이션 패턴이기 때문입니다 [8].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 레거시 시스템의 가용성을 유지하면서 아키텍처 부채를 안전하게 분할 및 상환하는 실무적인 리팩토링 방법론을 이해할 수 있습니다.
- [[Ports and Adapters (Hexagonal Architecture)]]
  - 연결 이유: 레거시 코드를 리팩토링할 때, 새로운 기능에 대해 포트와 어댑터를 도입하여 점진적으로 시스템을 디커플링하는 데 활용됩니다 [6].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비즈니스 로직과 외부 인프라의 의존성을 역전시켜 리팩토링에 따른 부작용을 최소화하는 구조적 원리를 배울 수 있습니다.

#### [아키텍처 품질 및 부채]
- [[Software Architecture Erosion]]
  - 연결 이유: 아키텍처 침식은 리팩토링이 필요하게 되는 근본적인 원인 중 하나이며, 리팩토링은 이를 복구하기 위한 치료적 조치로 작용합니다 [10, 11].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 왜 초기에 잘 설계된 시스템이라도 지속적인 리팩토링 없이는 구조가 무너지고 유지보수 비용이 급증하는지 이해할 수 있습니다.
- [[Technical Debt]]
  - 연결 이유: 모놀리스나 단순 계층형 아키텍처가 확장을 맞이할 때 축적되는 부채이며, 이를 해소하기 위해 리팩토링이 수행됩니다 [1, 15].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처를 적시에 리팩토링하지 않을 경우 시스템 성능과 개발 속도에 미치는 악영향을 파악할 수 있습니다.

### Deeper Research Questions

- 계층형 아키텍처(Layered Architecture)가 강한 결합(Tight Coupling) 상태로 변질되었을 때, 이를 헥사고날 아키텍처로 안전하게 리팩토링하기 위한 포트와 어댑터 도입의 구체적인 단계는 무엇인가?
- 대규모 모놀리식 아키텍처를 마이크로서비스로 리팩토링할 때, 스트랭글러 피그 패턴(Strangler Fig Pattern)을 적용하여 데이터 일관성을 유지하는 방안은 무엇인가?
- 아키텍처 침식(Architecture Erosion)을 조기에 식별하여 대규모 리팩토링으로 이어지기 전에 예방할 수 있는 자동화된 아키텍처 적합성 검사(Architecture Conformance Check) 기법은 무엇이 있는가?
- 비즈니스 로직이 UI나 데이터베이스 계층에 분산되어 누수(Leak)된 기존 레거시 코드를, 도메인 중심 설계(DDD) 기반으로 리팩토링할 때 겪는 트레이드오프는 무엇인가?
- 리팩토링 과정 중 불가피한 마이그레이션이 진행되는 동안, 시스템의 무중단 배포 및 이전 기능과의 하위 호환성을 보장하기 위한 API 버저닝 및 라우팅 전략은 어떻게 구성해야 하는가?

### Practical Application Contexts

- **Implementation:** 모놀리식 시스템의 특정 모듈을 서버리스 함수로 전환하거나, 레거시 코드 내부에 인터페이스(포트)를 정의하여 외부 의존성(어댑터)을 분리하는 방식으로 코드를 점진적으로 개선할 때 적용됩니다.
- **System Design:** 초기 시스템은 빠른 속도를 위해 단순한 모듈러 모놀리스(Modular Monolith)로 설계하되, 향후 사용자가 폭증할 때 마이크로서비스로 쉽게 리팩토링할 수 있도록 도메인 간 결합도를 미리 낮추는 전략을 취할 때 활용됩니다.
- **Operation / Maintenance:** 코드 정적 분석이나 아키텍처 적합성 검사를 통해 아키텍처 침식 및 기술 부채를 식별하고, 유지보수 주기마다 이를 해결하기 위한 리팩토링 스프린트를 운영합니다.
- **Learning Path:** 기본 계층형 패턴 구축 -> 기술 부채 및 구조적 한계 체감 -> 의존성 역전 원칙(SOLID, Clean Architecture) 학습 -> 기존 프로젝트를 도메인 중심으로 리팩토링 해보는 과정으로 학습이 연결됩니다.
- **My Project Relevance:** 현재 구축 중인 MVP 프로젝트가 향후 클라우드 네이티브(Cloud-Native) 환경으로 스케일업될 것을 대비하여, 무리한 빅뱅 방식의 전환을 피하고 점진적인 리팩토링이 가능한 시스템 경계를 사전에 설계하는 데 기준이 됩니다.

### Adjacent Topics

- [[Domain-Driven Design (DDD)]]
  - 확장 방향: 아키텍처 리팩토링 시, 모놀리식 시스템을 분해하기 위한 경계(Bounded Context)를 식별하고 정의하는 기준점으로 학습을 확장할 수 있습니다.
- [[Microservices Decomposition]]
  - 확장 방향: 리팩토링을 통해 단일 데이터베이스를 서비스별 데이터베이스(Database per Service)로 분리하고, 사가(Saga) 패턴이나 CQRS를 도입하는 실무적인 마이그레이션 기법으로 탐구할 수 있습니다.

---
*Last updated: 2026-05-02*