그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Architecture
Architecture

템플릿 메서드 패턴은 무엇인가요?

실무3/5
설계4/5
인간4/5
기초2/5

면접관의 질문 의도

패턴 정의를 외웠는지가 아니라, 상속으로 흐름을 고정하는 선택의 비용을 이해하는지를 본다. 전략 패턴과의 선택 기준을 자기 언어로 끊어 말할 수 있느냐가 깊이의 분기점이다.

큐레이션 답변

학습 자료

템플릿 메서드 패턴은 상위 클래스가 알고리즘의 호출 순서를 final로 고정하고, 가변 단계를 추상 메서드나 훅으로 열어 하위 클래스가 채우게 하는 행위 패턴이다. 핵심은 흐름 자체는 한 곳에 묶어 두고 변경 축만 하위로 위임한다는 데 있다. 그래서 절차는 똑같은데 일부 단계만 다른 로직이 반복될 때 중복을 제거하면서 순서를 어기지 못하게 강제한다. 단 상위 변경이 모든 하위에 번지는 상속 결합도가 같이 따라온다.

좋은 답변 구조

  1. 01템플릿 메서드의 정의를 "흐름은 상위에서 고정, 단계는 하위에서 구현"으로 한 문장에 압축한다
  2. 02구체적 동작 — final 템플릿 메서드, 추상 단계, 훅 메서드의 역할 — 을 짧게 짚는다
  3. 03상속 결합도와 클래스 폭발이라는 비용을 정면으로 인정한다
  4. 04변경 축이 안정적일 때만 유리하다는 적용 기준으로 닫는다

자주 실수하는 포인트

패턴 구조만 외우고 "왜 상속을 골랐는가"라는 선택 근거를 설명하지 못한다
전략 패턴과의 차이를 "상속이냐 합성이냐" 표면에서 끝내고 변경 축 기준으로 가르지 못한다
훅 메서드를 무제한으로 열어 두고 LSP가 깨지는 위험을 인지하지 못한다
상위 클래스 변경이 모든 하위에 번지는 결합 비용을 트레이드오프로 인정하지 않는다

실무 맥락

  • 여러 배치/처리 파이프라인이 전·후처리는 같고 본 처리 로직만 다른 환경
  • 프레임워크가 라이프사이클 훅을 노출하고 사용자 코드가 일부 단계만 채우게 하는 환경
  • JdbcTemplate처럼 자원 획득·해제 순서를 라이브러리가 강제해야 하는 환경
  • 보고서 생성·파일 변환처럼 헤더·본문·푸터 순서를 건드릴 수 없는 포맷 처리 파이프라인

본인 경험에 녹이는 힌트

비슷한 흐름의 메서드가 여러 클래스에 흩어져 있던 코드를 상위로 끌어올렸던 경험이 있다면 "무엇을 final로 묶었고 무엇을 열어 뒀는지"로 연결할 수 있다

상위 클래스를 한 줄 바꿨다가 하위 전부가 깨졌던 경험이 있다면 상속 결합도 비용을 본인 사례로 풀어낼 수 있다

처음에 템플릿 메서드로 짰다가 전략 패턴으로 바꾼 경험이 있다면 "변경 축이 단계에서 조합으로 옮겨가는 신호"로 일반화할 수 있다

프레임워크 훅 메서드를 오버라이드하다 호출 순서를 헷갈렸던 경험이 있다면 훅 설계가 LSP에 주는 부담으로 묶어낼 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1템플릿 메서드와 전략 패턴 중 어느 쪽을 고를지 변경 축을 기준으로 어떻게 가르나요
Q2훅 메서드를 너무 많이 열면 어떤 문제가 생기고 어디까지 열어야 한다고 보나요
Q3상속 깊이가 깊어졌다는 신호를 어떻게 감지하고 무엇으로 리팩터링하나요
Q4스프링 JdbcTemplate은 왜 이 패턴을 골랐고 사용자 코드는 어느 단계를 채우나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문