Wrap Method (랩 메서드)

📌 Brief 리팩토링

Wrap Method(랩 메서드)는 레거시 코드를 리팩토링할 시간이 부족하거나 테스트를 작성하기 어려운 상황에서 기존 코드를 감싸(Wrap) 새로운 기능을 추가하는 기법입니다 [1, 2]. 기존 메서드의 이름을 변경하고 원래 이름과 동일한 새 메서드를 만들어 그 안에서 기존 메서드와 새로운 로직을 함께 호출하는 방식으로 동작합니다 [2]. 이 기법을 사용하면 기존 코드를 직접 수정하지 않으면서도 새로운 로직을 안전하게 추가하고 테스트할 수 있습니다 [2].

📖 Core Content

Wrap Method는 마이클 페더스(Michael Feathers)의 저서 "Working Effectively with Legacy Code"에서 테스트가 없는 레거시 코드에 안전하게 기능을 추가하기 위한 전략으로 소개되었습니다 [3, 4].

적용 목적 및 맥락: 기능 추가나 수정을 위해 기존 코드를 리팩토링해야 하지만, 시간적 여유가 없고 기존 코드가 거대하여 테스트 작성이 불가능할 때 우회책으로 사용됩니다 [1].
사용 조건: 추가해야 하는 새로운 변경 사항(로직)이 기존 코드의 실행 '전'이나 '후'에 발생해야 할 때 적합합니다 [2].
Wrap Method 실행 4단계 [2]:
1. 래핑(Wrap)하고자 하는 기존 메서드의 이름을 변경합니다.
2. 기존 메서드와 동일한 이름과 시그니처를 가진 새로운 메서드를 생성합니다.
3. 새로운 메서드 안에서 이름이 변경된 기존 메서드를 호출합니다.
4. 기존 메서드 호출 전이나 후에 새로운 로직을 추가합니다.
테스트 가능성 (Testability): 새로 추가된 로직은 격리되어 테스트가 가능해집니다. 이는 기존에 문제가 되던 구(old) 메서드가 테스트 시에 동작을 변경(alter)할 수 있는 '이음새(Seam)' 역할을 하기 때문입니다 [2].

⚖️ Trade-offs & Caveats

근본적 해결책의 부재: 이 기법은 코드를 추가하기 위한 임시적이고 실용적인 도구일 뿐, 이상적인 해결책은 아닙니다 [5]. 거대한 코드 덩어리(Big lumps of code)에 코드를 덧붙이려는 유혹에 빠지게 하여 장기적으로는 유지보수해야 할 클래스의 크기를 계속 키우는 부작용이 있습니다 [1].
잠재적 함정: 소스 코드에서는 Wrap Method 기법이 완벽하지 않으며 특유의 함정(pitfalls)이 있다고 지적합니다 [5]. (구체적으로 어떤 기술적인 함정이 발생하는지에 대해서는 소스에 관련 정보가 부족합니다.)
적용의 한계: 따라서 이 기법은 시간이 극도로 부족하여 안전한 단위 테스트 작성과 전면적인 리팩토링을 수행할 수 없는 상황에서만 제한적이고 전략적으로 사용되어야 합니다 [1].

🔗 Knowledge Connections

[레거시 코드 대응 기술]

Seams (이음새)
- 연결 이유: Wrap Method를 사용하면 기존 메서드가 이음새(Seam) 역할을 하여 테스트에서 프로그램의 동작을 변경할 수 있게 해줍니다 [2].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기존 소스 코드를 직접 수정하지 않고도 프로그램의 동작을 변경하거나 테스트를 용이하게 만드는 구조적 접근법 [6].
Sprout Method (스프라우트 메서드)
- 연결 이유: Wrap Method와 함께 테스트가 없는 레거시 코드에 시간이 부족할 때 안전하게 코드를 추가하는 대표적인 우회 기법으로 쌍을 이루어 소개됩니다 [1].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기존 코드 내 특정 삽입 지점(insertion point)에 새로운 로직의 호출을 넣는 방식(Sprout)과 기존 코드를 감싸는 방식(Wrap)의 차이 및 활용 상황 비교 [2, 7].

[리팩토링 대상 환경]

Legacy Code (레거시 코드)
- 연결 이유: Wrap Method 자체가 "테스트가 없는 코드"로 정의되는 레거시 코드 환경에서 안전한 변경을 하기 위해 고안된 방법론이기 때문입니다 [1, 3].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 왜 기존 코드를 바로 리팩토링하지 못하고 Wrap Method 같은 우회 기법을 써야 하는지에 대한 근본적인 배경 [8].

Deeper Research Questions

Wrap Method와 Sprout Method 중 어떤 상황에서 어느 기법을 선택하는 것이 시스템의 결합도를 낮추는 데 더 유리한가?
이음새(Seam)를 활용하여 Wrap Method를 테스트 가능하게 만드는 구체적인 객체지향 언어별 구현 패턴은 무엇인가?
Wrap Method의 남용이 클래스 설계(예: 단일 책임 원칙)에 미치는 장기적인 악영향은 무엇이며, 이를 다시 온전하게 리팩토링하는 절차는 무엇인가?
테스트가 없는 레거시 시스템에서 Wrap Method를 적용한 후, 추후 근본적인 '준비적 리팩토링(Preparatory Refactoring)'으로 전환하기 위한 기술 부채 상환 전략은 무엇인가?
소스 코드에서 언급된 Wrap Method의 "잠재적 함정(pitfalls)"은 구체적으로 시스템 구조나 실행 흐름 측면에서 어떻게 나타나는가?

Practical Application Contexts

Implementation: 거대하고 테스트되지 않은 레거시 메서드에 새로운 검증 로직이나 데이터 전처리 로직을 추가해야 할 때, 기존 코드 내부에 if 문을 무분별하게 추가하는 대신 메서드를 감싸서 구현합니다 [1, 2].
System Design: 설계가 복잡한 기존 시스템에 긴급한 비즈니스 요구사항을 반영할 때, 기존 로직과의 직접적인 결합을 피하면서 최소한의 모듈성을 유지하는 설계 우회로로 활용됩니다 [2].
Operation / Maintenance: 유지보수 시 시간이 촉박한 상황에서 테스트 커버리지를 점진적으로 확보하기 위해 사용되며, 기존 기능을 깨트릴 위험(Regression risk)을 최소화합니다 [1, 2].
Learning Path: 마이클 페더스(Michael Feathers)의 접근법을 통해 레거시 소프트웨어 환경을 다루는 방법과 테스트를 추가하는 실전 기법을 학습할 때 핵심 패턴으로 다뤄집니다 [3, 4].
My Project Relevance: 시간이 부족하고 전면 리팩토링이 불가능한 레거시 유지보수 태스크에서, 빠른 기능 추가와 단위 테스트 작성을 동시에 달성해야 할 때 즉각 도입할 수 있는 실용적 패턴입니다.

Adjacent Topics

Test-Driven Development (TDD)
- 확장 방향: 레거시 코드에 Wrap Method 등을 통해 기본 테스트를 확보한 이후, 향후 새로운 기능 개발 시 안전하게 테스트 주도 개발 원칙을 확장 적용해 나가는 방법 [9].
Code Smells (코드 스멜)
- 확장 방향: Wrap Method 적용 대상이 되는 길고 복잡한 메서드(Long Method)나 거대한 클래스 등 코드 내 잠재적 결함 지표를 식별하고 관리하는 방법론 [10, 11].

Last updated: 2026-05-03

7.1 KiB Raw Blame History