269. 템플릿 메서드 (Template Method) - 상위 클래스는 뼈대, 하위 클래스는 세부 구현

핵심 인사이트 (3줄 요약)

본질: 템플릿 메서드(Template Method) 패턴은 전체적인 알고리즘의 뼈대(골격)는 상위 클래스(부모)에 정의하고, 알고리즘의 특정 단계별 세부 구현은 하위 클래스(자식)로 미루어(Override) 유연하게 대처하는 행동(Behavioral) 패턴이다.

가치: 전체적인 실행 흐름(제어 구조)을 한 곳에서 중앙 집중식으로 통제하면서도, 부분적인 기능 확장이나 변경은 기존 코드를 훼손하지 않고 자식 클래스를 통해 안전하게 수행할 수 있어 코드 중복 방지와 재사용성 향상에 탁월하다.

융합: 객체 지향 프로그래밍에서 상속(Inheritance)의 이점을 가장 직관적으로 살린 패턴이며, 프레임워크(Framework) 설계 시 제어의 역전(IoC, Inversion of Control)을 구현하는 가장 고전적이고 핵심적인 메커니즘으로 활용된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 템플릿 메서드 패턴은 부모 클래스에 전체 작업의 순서를 결정하는 '템플릿 메서드'를 두고, 그 안에서 호출되는 추상 메서드들의 실제 구현을 자식 클래스에게 위임하여, 자식이 전체 흐름은 건드리지 못한 채 특정 단계의 내용만 재정의하도록 강제하는 패턴이다.
필요성: 커피와 홍차를 만드는 프로그램을 만든다고 가정하자. 두 음료 모두 "1) 물을 끓인다 → 2) 무언가를 우려낸다 → 3) 컵에 따른다 → 4) 첨가물을 넣는다"라는 동일한 작업 순서를 갖는다. 만약 커피 클래스와 홍차 클래스를 각각 따로 만들면, '물을 끓인다'와 '컵에 따른다'는 완전히 똑같은 코드가 중복된다. 버그 수정 시 양쪽을 다 고쳐야 하는 불상사가 발생한다.
💡 비유: 프랜차이즈 샌드위치 가게(예: 써브웨이)의 '주문 순서'와 같습니다. "1. 빵 선택 → 2. 고기 선택 → 3. 야채 추가 → 4. 소스 뿌리기"라는 전체적인 뼈대(템플릿)는 본사가 정해서 절대 바꿀 수 없지만, 각 단계에서 어떤 재료를 고를지(세부 구현)는 손님(자식 클래스)이 마음대로 정할 수 있습니다.
등장 배경 및 발전 과정:
1. 절차적 프로그래밍의 코드 중복: 과거에는 비슷한 여러 개의 함수들이 복사-붙여넣기 되어 프로젝트 전체에 산재했고, 하나를 고치면 나머지도 다 찾아 고쳐야 하는 '산탄총 수술(Shotgun Surgery)' 냄새가 났다.
2. 상속과 다형성의 도입: 객체 지향 언어의 등장으로 공통된 부분은 부모가 흡수(Pull Up)하고, 달라지는 부분만 자식에게 남기는 추상화 기법이 고안되었다.
3. 헐리우드 원칙(Hollywood Principle): "먼저 연락하지 마세요, 우리가 연락하겠습니다(Don't call us, we'll call you)"라는 프레임워크의 근본 철학이 이 패턴을 통해 완성되었다. 개발자(자식)는 그저 메서드 하나만 오버라이딩해 두면, 프레임워크(부모)가 알아서 적절한 시점에 그 메서드를 호출해준다.
📢 섹션 요약 비유: 이력서나 자기소개서의 빈칸 채우기 양식(템플릿)을 생각하면 됩니다. 목차의 순서나 질문(뼈대)은 회사(부모)가 정해서 바꿀 수 없지만, 그 빈칸을 채우는 내용(세부 구현)은 지원자(자식)마다 다르게 쓰는 것과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

구성 요소 (클래스 다이어그램)

요소명	역할	비유
AbstractClass (추상 클래스)	템플릿 메서드와 여기에 포함된 추상 메서드들을 선언. 알고리즘의 뼈대를 고정한다.	프랜차이즈 본사 매뉴얼 (전체 순서 강제)
Template Method (템플릿 메서드)	`AbstractClass` 내부에 구현된 메서드로, 전체 알고리즘의 순서를 정의한다. 자식이 함부로 변경하지 못하도록 보통 `final`로 선언된다.	샌드위치 만드는 순서 (순서 변경 불가)
ConcreteClass (구현 클래스)	`AbstractClass`를 상속받아 추상 메서드들의 구체적인 내용을 작성하는 클래스.	실제 손님의 샌드위치 레시피 (빵은 플랫브래드, 소스는 스위트어니언 등)
Hook (훅 메서드)	`AbstractClass`에 내용이 비어 있거나 기본값만 제공되어 구현된 메서드. 자식이 선택적으로 재정의(Override)하여 알고리즘의 중간 단계나 특정 옵션을 조작할 수 있게 해주는 확장점.	"치즈 데워드릴까요?" (선택사항)

동작 메커니즘 (코드 뼈대 구조)

템플릿 메서드 패턴의 핵심은 부모 클래스의 templateMethod() 안에서 자식들이 구현할 abstract 메서드들을 미리 순서대로 호출해 둔다는 점이다.

  ┌─────────────────────────────────────────────────────────────┐
  │                 템플릿 메서드 패턴의 작동 원리                │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │  [AbstractClass : CaffeineBeverage]                         │
  │                                                             │
  │  + final prepareRecipe() {        ◀── 템플릿 메서드           │
  │      boilWater();                      (뼈대, 순서 강제)       │
  │      brew();                                                │
  │      pourInCup();                                           │
  │      if (customerWantsCondiments()) { ◀── Hook(훅) 메서드    │
  │          addCondiments();             (선택적 오버라이드 가능) │
  │      }                                                      │
  │  }                                                          │
  │                                                             │
  │  - boilWater() { ... }            ◀── 공통 메서드 (구현됨)   │
  │  - pourInCup() { ... }                                      │
  │  - abstract brew();               ◀── 추상 메서드           │
  │  - abstract addCondiments();           (자식에게 구현 위임)   │
  │                                                             │
  │            △ (상속)                             △ (상속)      │
  │            │                                  │             │
  │  [ConcreteClass A : Coffee]       [ConcreteClass B : Tea]   │
  │  + brew() { 필터로 커피 내리기 }     + brew() { 찻잎 우리기 }  │
  │  + addCondiments() { 설탕/우유 }    + addCondiments() { 레몬 }│
  └─────────────────────────────────────────────────────────────┘

[다이어그램 해설] prepareRecipe()는 음료를 만드는 전체 순서를 제어하며, 이 메서드 자체는 final이므로 자식이 순서를 바꿀 수 없다. boilWater()와 pourInCup()은 커피나 홍차나 동일하므로 부모가 직접 구현해 코드 중복을 제거한다. 반면 brew()와 addCondiments()는 음료마다 다르므로 abstract로 선언하여 자식 클래스가 반드시 오버라이딩하도록 강제한다. 이렇게 하면 공통 코드는 부모로 올려 재사용성을 높이고, 다른 코드는 자식으로 내려 다형성을 확보하게 된다.

제어의 역전 (IoC, Inversion of Control)과 헐리우드 원칙

일반적인 객체 지향 프로그래밍에서는 개발자가 작성한 메인 로직이 외부 라이브러리나 클래스를 가져다(Call) 쓴다. 즉 제어권이 개발자에게 있다. 그러나 템플릿 메서드 패턴에서는 부모 클래스(또는 프레임워크)가 메인 흐름을 통제하고, 개발자가 작성한 자식 클래스의 메서드를 적절한 타이밍에 가져다 쓴다(Called by framework). 제어의 흐름이 완전히 뒤바뀐 것이다. 이것을 '헐리우드 원칙(먼저 연락하지 마세요, 우리가 연락하겠습니다)'이라 부르며, 현대 모든 웹 프레임워크(Spring, React의 생명주기 등)를 관통하는 핵심 아키텍처 사상이다.

📢 섹션 요약 비유: 내가 필요할 때마다 부모님께 여쭤보는 것(일반적인 호출)이 아니라, 부모님이 스케줄러(템플릿 메서드)를 짜놓고 "너는 3시에 학원(추상 메서드)만 가렴" 하고 나를 조종하는 것(제어의 역전)과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 템플릿 메서드 패턴 vs 전략 패턴 (Strategy Pattern)

두 패턴은 모두 '알고리즘의 캡슐화와 변경'을 목적으로 하지만, 접근 방식(상속 vs 위임)에서 극명한 차이를 보인다.

비교 항목	템플릿 메서드 (Template Method)	전략 패턴 (Strategy)
설계 기반	상속 (Inheritance, Is-A) 기반	위임 (Composition, Has-A) 기반
변경의 범위	알고리즘의 '일부 단계'만 변경	알고리즘 '전체'를 통째로 교체
결합도	부모 클래스에 강하게 결합됨 (Tight Coupling)	인터페이스에 의존하므로 느슨하게 결합됨 (Loose Coupling)
변경 시점	컴파일 타임에 정적으로 결정됨	런타임에 동적으로 변경 가능
주 사용처	프레임워크 내부의 라이프사이클 관리	로깅, 정렬, 결제, 압축 등 다양한 알고리즘의 동적 교체

  ┌─────────────────────────────────────────────────────────────┐
  │        Template Method (상속) vs Strategy (위임) 비교        │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │  [Template Method]                [Strategy]                │
  │                                                             │
  │  ┌────────────┐ (뼈대)            ┌────────────┐ (위임)     │
  │  │   Parent   │                   │  Context   │─────┐      │
  │  └────────────┘                   └────────────┘     │      │
  │        △ (상속)                                        ▼      │
  │        │                                        ┌────────┐  │
  │  ┌────────────┐ (세부구현)                      │Strategy│  │
  │  │   Child    │                             └────────┘  │
  │  └────────────┘                                    △      │
  │                                                    │ 상속   │
  │                                               ┌────┴────┐   │
  │                                               │ Concrete│   │
  │                                               └─────────┘   │
  │                                                             │
  │ "뼈대 속 빈칸 채우기"               "부품 전체를 통째로 갈아 끼우기" │
  └─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 템플릿 메서드는 부모라는 거대한 틀 안에서 자식이 아주 일부분(메서드 단위)만 재정의하는 화이트박스(White-box) 재사용이다. 부모의 구현 세부 사항을 자식이 알아야 하므로 결합도가 높다. 반면 전략 패턴은 인터페이스 뒤에 캡슐화된 객체 전체를 끼워 넣는 블랙박스(Black-box) 재사용으로, 훨씬 독립적이고 유연하다. 현대 객체 지향에서는 강결합의 부작용을 피해 템플릿 메서드보다 전략 패턴을 더 권장하는 추세지만, 프레임워크의 큰 뼈대를 강제해야 할 때는 여전히 템플릿 메서드가 필수적이다.

과목 융합 관점

소프트웨어 공학 (SE): Spring 프레임워크의 수많은 ~Template 클래스들(예: JdbcTemplate, RestTemplate)이나 안드로이드/React의 컴포넌트 생명주기(onCreate(), onStart() / componentDidMount())가 모두 템플릿 메서드 패턴의 변형이다. 프레임워크가 전체 라이프사이클을 통제하고, 개발자는 빈칸(Hook 메서드)만 채워 넣게 만든다.
알고리즘 (Algorithm): 머신러닝의 파이프라인(데이터 전처리 → 모델 학습 → 평가)을 구축할 때 전체 파이프라인 흐름은 템플릿 메서드로 고정하고, 전처리 방식이나 학습 알고리즘을 하위 클래스에서 오버라이드하여 실험 환경의 코드 중복을 최소화한다.
📢 섹션 요약 비유: 템플릿 메서드는 집의 철골조와 기둥은 그대로 두고 인테리어 벽지만 바꾸는 것이라면, 전략 패턴은 집 자체를 통째로 모듈형 컨테이너 하우스로 바꿔버리는 것과 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 중복 코드로 점철된 배치(Batch) 스케줄러: 은행 시스템에서 매일 밤 '대출 이자 계산', '예금 이자 계산', '연체료 계산' 3가지 배치 프로그램이 돌아간다. 각 배치 프로그램에는 "1. DB 연결 → 2. 대상 데이터 Fetch → 3. (각자 다른 비즈니스 계산) → 4. 계산 결과 DB 업데이트 → 5. 로깅 및 연결 종료"라는 동일한 코드가 매번 수백 줄씩 복사-붙여넣기 되어 있다. DB 연결 정책이 바뀔 때마다 3곳을 모두 찾아 수정해야 한다.
- 아키텍트의 해결책: 전형적인 템플릿 메서드 패턴 적용 사례다. AbstractBatchProcessor 추상 클래스를 만들고 executeBatch() 템플릿 메서드 내에 1, 2, 4, 5번 과정을 구현한다. 그리고 3번 계산 로직만 abstract void processBusinessLogic(Data data);로 뚫어 놓는다. 세 개의 배치 클래스는 이 부모를 상속받아 오직 3번 계산 로직만 구현하면, 향후 DB 연동 정책이 바뀌어도 부모 클래스 한 곳만 수정하면 된다.
시나리오 — 프레임워크의 선택적 확장 지점(Hook) 제공: 자체 개발한 사내 웹 프레임워크가 있다. 모든 HTTP 요청에 대해 "권한 확인 → 요청 처리 → JSON 응답 변환"을 수행한다. 그런데 특정 서비스(예: 결제 API)에서만 요청 처리 직후에 '사내 메신저 알림'을 보내고 싶어 한다.
- 아키텍트의 해결책: 템플릿 메서드 패턴에 Hook(훅) 메서드 개념을 도입한다. 부모 클래스에 protected void afterRequestProcessed() { } (아무 내용이 없는 빈 메서드)를 만들어 두고 템플릿 메서드 사이사이에 끼워 넣는다. 결제 API 서비스 클래스는 이 Hook 메서드를 오버라이딩(Override)하여 메신저 알림 로직을 추가하면 되고, 다른 서비스들은 굳이 구현하지 않아도 기본 빈 메서드가 실행되므로 안전하게 확장이 가능하다.

도입 체크리스트

기술적: 자식이 템플릿 메서드 자체(전체 제어 흐름)를 오버라이딩하여 프레임워크의 근간을 무너뜨리는 것을 방지하기 위해, 템플릿 메서드에 final 예약어를 명시적으로 선언했는가?
설계적: 부모 클래스에서 요구하는 추상 메서드가 너무 많지 않은가? (추상 메서드가 5개, 10개로 늘어나면 하위 클래스는 이를 일일이 구현하다 지쳐버린다. 템플릿 메서드 패턴은 뼈대가 단순할 때만 강력하다.)

안티패턴

부모 클래스의 비대화 (God Class): 템플릿 메서드 패턴을 남용하다 보면, 자식 클래스 간의 공통 로직을 무조건 부모로 끌어올리게(Pull Up) 되어 결국 부모 클래스가 수천 줄이 넘는 신(God) 클래스로 비대해지고, 이 부모를 상속받는 모든 자식 클래스가 옴짝달싹 못 하게 결합되어 버리는 최악의 유지보수성 저하를 겪게 된다. (상속의 저주)
자식에서 뼈대 로직 파괴: 템플릿 메서드에 final을 걸어두지 않아, 주니어 개발자가 부모의 execute() 전체를 오버라이딩하여 자신만의 완전히 다른 흐름을 만들어버리는 경우. 패턴 도입의 목적이 붕괴된다.
📢 섹션 요약 비유: 훅(Hook) 메서드는 라면을 끓일 때 "기호에 따라 파나 계란을 넣으세요"라는 매뉴얼과 같습니다. 안 넣어도 기본 라면은 완성되고, 넣고 싶으면 자유롭게 넣을 수 있는 선택적 확장점입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	무분별한 복붙 구현 (AS-IS)	템플릿 메서드 도입 (TO-BE)	개선 효과
정량	공통 로직(DB 연결 등) 수정 시 10개 클래스 타격	부모 클래스 1개만 수정 시 10개 자식 일괄 적용	버그 수정 공수 90% 이상 절감
정량	새 배치 잡 추가 시 500줄 작성 필요	핵심 로직 50줄만 작성하여 구현 완료	개발 속도 향상 및 코드량 90% 감축
정성	개발자마다 작업 순서(트랜잭션, 로깅 등)가 제각각	프레임워크 단에서 실행 순서 완벽 통제	팀 전체의 코드 규격화 및 아키텍처 안정성 달성

미래 전망

상속에서 위임으로의 이동 가속화: 현대 아키텍처 트렌드는 상속의 짙은 결합도를 피하기 위해 템플릿 메서드(상속) 대신 템플릿 콜백 패턴(Template Callback Pattern - 전략 패턴에 익명 내부 클래스나 람다를 결합한 방식)으로 빠르게 이동하고 있다. Spring의 JdbcTemplate이 대표적인 템플릿 콜백 패턴의 예시이며, 함수형 프로그래밍의 확산으로 이러한 '람다 주입' 방식이 더욱 각광받을 것이다.
Default Method 활용: Java 8 이후 인터페이스에 default 메서드가 도입되면서, 굳이 부모 '추상 클래스'를 만들지 않고도 인터페이스 단에서 템플릿 메서드를 구현하여 다중 상속의 이점을 부분적으로 취하는 설계 기법이 활발해지고 있다.

참고 표준

GoF (Gang of Four): Behavioral Patterns - Template Method
Java Abstract Collection: java.util.AbstractList의 addAll(), clear() 등 핵심 뼈대 구현.
Spring Framework: DispatcherServlet.doDispatch() 내의 요청 처리 생명주기 통제 매커니즘.

템플릿 메서드 패턴은 **"바뀌지 않는 것은 묶어두고, 바뀌는 것만 열어둔다"**는 소프트웨어 설계의 제1원칙을 가장 쉽고 명확하게 체현한 패턴이다. 기술사는 단순히 '상속을 이용한 코드 재사용'에 그치지 않고, 이 패턴을 통해 개발자들이 프레임워크가 깔아놓은 탄탄한 레일(뼈대) 위에서 안전하고 통제된 방식(Hook)으로만 확장을 시도하도록 돕는 '아키텍처의 가드레일'을 세우는 안목을 가져야 한다.

📢 섹션 요약 비유: 템플릿 메서드는 찰흙으로 도자기를 빚을 때 사용하는 단단한 '철사 뼈대'와 같습니다. 뼈대(전체 흐름)가 튼튼하게 중심을 잡아주기에, 겉에 찰흙(세부 로직)을 마음껏 붙여도 절대 무너지지 않는 예술 작품(안정된 소프트웨어)을 만들 수 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
제어의 역전 (IoC, Inversion of Control)	템플릿 메서드 패턴이 탄생시킨 철학으로, 개발자의 코드가 프레임워크의 뼈대에 의해 호출당하는 아키텍처의 핵심 원리.
전략 패턴 (Strategy Pattern)	알고리즘 교체라는 목적은 같으나 상속이 아닌 위임(인터페이스)을 사용하여 결합도를 낮춘 대체 가능/경쟁 패턴.
팩토리 메서드 (Factory Method)	객체 생성의 '과정(뼈대)'은 부모가 정의하고, '어떤 객체를 만들지(세부)'는 자식이 정하는 '생성판 템플릿 메서드' 패턴.
템플릿 콜백 패턴 (Template Callback)	템플릿 메서드의 상속 한계를 극복하기 위해, 뼈대(메서드) 안에 익명 클래스나 람다 함수(콜백)를 파라미터로 밀어 넣는 현대적 진화형.
DRY 원칙 (Don't Repeat Yourself)	코드를 중복 작성하지 말라는 원칙으로, 템플릿 메서드가 공통 코드를 부모로 올리면서 이를 완벽히 달성한다.

👶 어린이를 위한 3줄 비유 설명

학교 미술 시간에 선생님이 "오늘은 '동물 그리기'를 할 거예요. 1. 스케치하기 → 2. 색칠하기 → 3. 이름 적기 순서로 하세요!"라고 순서(뼈대)를 칠판에 적어주셨어요.
어떤 동물(사자, 토끼)을 그릴지, 무슨 색으로 칠할지(세부 내용)는 친구들(자식 클래스) 마음대로 정할 수 있어요.
이렇게 전체적인 진행 순서는 미리 단단하게 정해놓고, 그 안의 알맹이만 각자 다르게 채우는 방법을 **'템플릿 메서드 패턴'**이라고 부른답니다!