Template Method

비슷한 알고리즘을 여러 곳에서 약간씩 다르게 구현하는 상황은 흔합니다. 데이터를 읽어서 변환하고 저장하는 흐름이 같은데, CSV를 처리하는 코드와 JSON을 처리하는 코드가 각각 전체 흐름을 복사해서 쓰고 있다면 문제가 두 가지 생깁니다. 하나는 공통 흐름에 버그가 발견됐을 때 모든 복사본을 찾아서 고쳐야 한다는 것이고, 다른 하나는 새로운 형식이 추가될 때마다 같은 골격 코드가 다시 복제된다는 것입니다. 핵심 로직의 중복은 변경 비용을 선형이 아니라 곱으로 키웁니다.

소프트웨어 재사용의 초기 접근은 공통 코드를 라이브러리 함수로 뽑는 것이었습니다. 하지만 실행 흐름의 골격 자체를 재사용해야 하는 상황에서는 함수 수준 추출이 부족했습니다. 호출 순서, 전후 처리, 예외 복구 같은 제어 흐름까지 포함해서 재사용하려면 '뼈대를 고정하고 구멍만 열어 두는' 구조가 필요했습니다. Template Method가 GoF 패턴에서 가장 기본적인 상속 기반 재사용 패턴으로 자리 잡은 이유가 여기에 있습니다. 오늘날 프레임워크의 라이프사이클 훅, 테스트 프레임워크의 setUp/tearDown, 빌드 시스템의 단계별 확장점이 모두 이 구조의 변형입니다.

Template Method의 핵심은 부모 클래스에 있는 하나의 메서드(templateMethod)가 알고리즘의 전체 순서를 정의한다는 점입니다. 이 메서드 안에서 step1(), step2(), hook() 같은 단계를 순서대로 호출합니다. 단계는 세 종류로 나뉩니다. 첫째, 부모 클래스에서 구현까지 완료한 고정 단계입니다. 이 단계는 서브클래스가 건드릴 수 없습니다. 둘째, abstract로 선언된 추상 단계입니다. 서브클래스가 반드시 구현해야 하며, 이 부분이 알고리즘의 가변 지점입니다. 셋째, 기본 구현이 있지만 오버라이드할 수 있는 훅(hook)입니다. 확장이 필요하면 쓰고, 아니면 기본값 그대로 둡니다. 중요한 점은 제어의 방향입니다. 서브클래스가 부모를 호출하는 것이 아니라, 부모의 templateMethod()가 서브클래스의 메서드를 호출합니다. 이 역전된 제어 흐름(Hollywood Principle — "Don't call us, we'll call you") 덕분에 실행 순서가 흩어지지 않고 한 곳에 고정됩니다.

Template Method와 Strategy는 둘 다 알고리즘의 가변 부분을 교체 가능하게 만들지만 접근 방식이 다릅니다. Template Method는 상속을 쓰고, 부모 클래스가 골격을 쥐고 서브클래스가 단계를 채웁니다. Strategy는 합성(composition)을 쓰고, 알고리즘 전체를 별도 객체로 빼서 런타임에 교체합니다. Template Method가 알고리즘의 일부 단계만 바꾸는 것이라면, Strategy는 알고리즘 전체를 바꾸는 것입니다. 상속 기반이기 때문에 클래스 계층이 깊어지면 유연성이 떨어질 수 있습니다. 교체해야 할 변동 지점이 하나뿐이고 골격이 안정적이라면 Template Method가 간결하고, 변동 지점이 여러 개이거나 런타임에 전략을 바꿔야 한다면 Strategy가 더 유연합니다.

Template Method는 프레임워크에서 가장 자주 만납니다. 프레임워크가 실행 흐름을 쥐고, 개발자는 특정 단계만 채우는 구조가 전형적인 Template Method입니다. 예를 들어 테스트 프레임워크에서 setUp → 테스트 실행 → tearDown 순서는 프레임워크가 정하고, 개발자는 각 테스트 메서드만 작성합니다. 웹 프레임워크의 요청 처리에서 인증 → 권한 확인 → 비즈니스 로직 → 응답 포맷팅 순서를 정해두고, 비즈니스 로직만 컨트롤러에서 구현하는 것도 같은 원리입니다. 데이터 마이그레이션 스크립트에서 연결 → 추출 → 변환 → 적재 → 검증 순서를 고정하고 변환 단계만 교체하는 것도 Template Method입니다. 패턴이 맞지 않는 경우도 있습니다. 골격 자체가 자주 바뀌는 상황에서는 상속 계층이 부담이 됩니다. 또 단계 간 순서가 고정이 아니라 조건에 따라 달라져야 한다면 Template Method의 전제가 무너지므로 다른 접근이 필요합니다.