코드를 작성하다 보면 전체 흐름은 거의 같은데, 특정 단계만 상황에 따라 달라지는 경우가 많습니다. 이때 모든 흐름을 매번 복사해서 수정하면 중복이 커지고, 공통 구조를 지나치게 일반화하면 읽기 어려워질 수 있습니다. 템플릿 메서드 패턴은 이런 상황에서 자주 등장하는 객체 지향 패턴입니다.
이 글에서는 아래 내용을 정리합니다.
- 템플릿 메서드 패턴이 무엇인지
- 어떤 상황에서 잘 맞는지
- 왜 공통 흐름과 가변 단계를 분리하는 데 도움이 되는지
- 전략 패턴과는 어떤 차이로 이해하면 좋은지
핵심은 템플릿 메서드 패턴은 알고리즘의 큰 흐름은 부모 쪽에서 고정하고, 일부 단계만 하위 타입이 바꾸도록 해서 중복을 줄이면서 구조를 유지하는 방식이라는 점입니다.
템플릿 메서드 패턴이란 무엇인가
템플릿 메서드 패턴은 전체 처리 순서를 상위 클래스에 두고, 세부 단계 일부를 하위 클래스가 구현하거나 재정의하게 하는 방식입니다.
즉:
- 큰 흐름은 공통으로 유지하고
- 달라지는 단계만 분리합니다
예를 들어 데이터 처리 흐름이:
- 입력 검증
- 데이터 변환
- 저장
- 후처리
라면, 전체 순서는 유지하면서 변환이나 후처리 단계만 다르게 만들 수 있습니다.
왜 필요한가
이 패턴이 없으면 비슷한 흐름이 여러 클래스에 복사되기 쉽습니다.
그러면:
- 공통 로직이 중복되고
- 수정 포인트가 여러 곳으로 늘어나며
- 전체 구조를 한눈에 보기 어려워집니다
템플릿 메서드 패턴은 “공통 흐름은 한곳에 두고 싶다”는 문제를 풀어줍니다.
어떤 상황에서 잘 맞을까
- 처리 순서는 거의 같은데 일부 단계만 달라지는 경우
- 공통 규칙을 강하게 유지하고 싶은 경우
- 하위 타입마다 세부 동작만 바뀌는 경우
즉, 변형은 있지만 전체 절차 자체는 안정적인 문제에서 잘 맞습니다.
전략 패턴과는 어떻게 다를까
둘 다 행동 변화를 다루지만 초점이 다릅니다.
- 전략 패턴: 행동 자체를 교체 가능한 객체로 분리
- 템플릿 메서드: 공통 절차는 상위에서 유지하고 일부 단계만 변경
즉, 템플릿 메서드는 상속 기반 흐름 제어에 더 가깝고, 전략 패턴은 조합 기반 행동 교체에 더 가깝습니다.
자주 하는 오해
1. 공통 코드가 있으면 무조건 템플릿 메서드다
단순 공통 메서드 추출과는 다릅니다. 핵심은 알고리즘 순서를 상위에서 잡는다는 점입니다.
2. 템플릿 메서드는 상속이니 항상 나쁘다
과한 상속은 문제일 수 있지만, 절차가 안정적으로 공유되는 구조에서는 꽤 자연스러울 수 있습니다.
3. 전략 패턴보다 항상 단순하다
상황에 따라 다릅니다. 변화 지점이 많고 조합이 중요하면 전략이 더 나을 수 있습니다.
Simple Example
abstract class DataProcessor {
process(): void {
this.validate();
this.transform();
this.save();
}
protected validate(): void {
console.log('validate input');
}
protected abstract transform(): void;
protected save(): void {
console.log('save result');
}
}
class CsvProcessor extends DataProcessor {
protected transform(): void {
console.log('transform csv data');
}
}
new CsvProcessor().process();
The full flow stays fixed in process(), while only the variable step transform() changes in the subclass.
FAQ
Q. 입문자는 어디서 떠올리면 좋을까
비슷한 처리 흐름 코드가 여러 클래스에 반복될 때 떠올리기 좋습니다.
Q. 템플릿 메서드와 훅 메서드는 같은가
훅 메서드는 템플릿 메서드 안에서 선택적으로 재정의할 수 있는 지점으로 함께 언급되는 경우가 많습니다.
Q. 전략 패턴과 중 무엇을 선택해야 하나
절차 자체를 상속 기반으로 공유할지, 행동을 외부 객체로 교체할지가 기준이 됩니다.
Read Next
- 행동 교체 중심 구조는 전략 패턴 가이드와 비교해서 보면 좋습니다.
- 상속과 조합의 선택 기준은 상속 vs 조합 가이드와 자연스럽게 이어집니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.