김코딩

[Spring Batch] 4편. 실전 코드 패턴과 Reader/Processor/Writer

김코딩딩 — Sat, 18 Apr 2026 20:30:37 +0900

들어가며

시리즈 마지막 편이다. 3편까지 읽었으면 Spring Batch의 기본 구조는 모두 정리한 셈이다. 이번 편에서는 3편의 간단한 예제보다 한 걸음 더 실무에 가까운 코드를 다루면서, 운영에서 마주치는 대표적인 고민들을 정리한다.

이번 편에서 다룰 내용은 네 가지다.

Processor가 포함된 실전 시나리오 코드
Processor의 역할 (변환 vs 필터링)
JPA Writer의 함정과 JdbcBatchItemWriter와의 비교
실제로 배치를 실행하는 방법

나의 생각
배치를 학습하면서 느낀 건, 프레임워크의 추상화를 맹목적으로 쓰면 오히려 성능 문제를 만들 수 있다는 점이다. 특히 Writer 쪽이 그렇다. "saveAll 한 줄이면 끝이네"라고 생각하면 나중에 운영에서 크게 당할 수 있다. 그 지점을 이번 편에서 풀어본다.

3편 예제 vs 4편 예제

3편에서는 탈퇴 회원의 이메일을 익명화하는 배치를 만들었다. 단순 수정 작업이었기 때문에 Reader와 Writer만으로 충분했다.

이번 편에서는 한 단계 더 복잡한 시나리오를 다룬다.

어제 구매 금액이 10만원 이상인 회원의 등급을 VIP로 변경한다. 단, 이미 VIP 회원이라면 건너뛴다.

이 시나리오는 조건 필터링과 상태 변경이 함께 필요하다. Reader가 조회한 회원 중 일부만 저장해야 하고, 각 회원마다 도메인 로직(등급 변경)이 적용되어야 한다. 이럴 때 Processor가 등장한다.

3편 예제는 단순 수정이라 Reader → Writer만으로 충분했다. 4편 예제는 도메인 로직과 필터링이 필요하므로 Processor가 중간에 들어간다. 이 차이를 염두에 두고 코드를 보자.

Processor의 두 가지 역할

Processor는 두 가지 역할을 한다. 각각을 이해하면 언제 Processor를 넣고 언제 뺄지 감이 잡힌다.

역할 1. 변환 (Transform)

Reader가 준 데이터를 가공해서 반환한다. 같은 타입으로 상태만 변경할 수도 있고, 완전히 다른 타입으로 바꿀 수도 있다.

// Member의 등급을 VIP로 변경해서 같은 타입으로 반환
ItemProcessor<Member, Member> processor = member -> {
    member.upgradeToVip();
    return member;
};

// Member를 MemberGradeHistory DTO로 변환
ItemProcessor<Member, MemberGradeHistory> processor = member ->
    new MemberGradeHistory(member.getId(), OLD, VIP, now());

역할 2. 필터링 (Filter)

조건을 만족하지 않는 데이터는 null을 반환한다. null이 반환된 건은 Writer로 전달되지 않는다.

If, while processing the item, it is determined that the item is not valid, returning null indicates that the item should not be written out.
— Spring Batch Reference: The Domain Language of Batch

ItemProcessor<Member, Member> processor = member -> {
    // 이미 VIP면 건너뜀
    if (member.isVip()) {
        return null;
    }
    member.upgradeToVip();
    return member;
};

실무 팁: 언제 Processor를 넣나

Reader와 Writer 사이에 비즈니스 로직이나 필터링이 필요하면 Processor를 추가한다. 반대로 "DB에서 읽은 걸 그대로 다른 곳에 쓴다" 같은 단순 이동 작업은 Processor 없이도 충분하다.

나의 생각
처음에는 "Processor를 쓰면 뭐가 좋지?"라고 생각했다. Writer 안에서 if로 걸러내도 되잖아? 하지만 관점을 바꿔보면 명확하다. Reader는 "데이터 가져오기", Processor는 "비즈니스 로직", Writer는 "저장"이라는 단일 책임을 지킬 수 있다. 덕분에 각 Bean을 독립적으로 테스트하기도 쉬워진다. 결국 객체지향 설계 원칙을 Spring Batch 레벨로 확장한 것이라고 이해했다.

실전 코드: VIP 등급 변경 배치

이제 실제 코드를 보자. 3편 예제와 구조가 거의 같지만 Processor가 추가되어 있다.

@Configuration
@RequiredArgsConstructor
public class MemberVipBatchConfig {

    private final JobRepository jobRepository;
    private final PlatformTransactionManager transactionManager;
    private final MemberRepository memberRepository;

    // ① Job 정의
    @Bean
    public Job memberVipJob() {
        return new JobBuilder("memberVipJob", jobRepository)
                .start(upgradeVipStep())
                .build();
    }

    // ② Step 정의 (Processor 포함)
    @Bean
    public Step upgradeVipStep() {
        return new StepBuilder("upgradeVipStep", jobRepository)
                .<Member, Member>chunk(1000, transactionManager)
                .reader(yesterdayBuyerReader())
                .processor(vipUpgradeProcessor())  // Processor 추가
                .writer(memberWriter())
                .build();
    }

    // ③ Reader - 어제 구매 금액 10만원 이상 회원 조회
    @Bean
    public ItemReader<Member> yesterdayBuyerReader() {
        return new RepositoryItemReaderBuilder<Member>()
                .name("yesterdayBuyerReader")
                .repository(memberRepository)
                .methodName("findByYesterdayPurchaseOver")
                .arguments(List.of(100_000))
                .pageSize(1000)
                .sorts(Map.of("id", Sort.Direction.ASC))
                .build();
    }

    // ④ Processor - 이미 VIP면 필터링, 아니면 등급 변경
    @Bean
    public ItemProcessor<Member, Member> vipUpgradeProcessor() {
        return member -> {
            if (member.isVip()) {
                return null;  // 필터링: Writer로 전달 안 됨
            }
            member.upgradeToVip();  // 변환: 상태 변경
            return member;
        };
    }

    // ⑤ Writer - JPA saveAll
    @Bean
    public ItemWriter<Member> memberWriter() {
        return items -> memberRepository.saveAll(items);
    }
}

3편 코드와 거의 같은 구조에, vipUpgradeProcessor() 하나만 추가되었을 뿐이다. Step 빌더에 .processor(...) 한 줄이 추가되었고, Processor 내부에서 필터링과 변환이 함께 일어난다.

JPA Writer의 함정

여기서 주의할 점이 있다. 위 코드의 Writer는 memberRepository.saveAll(items) 이지만, 이게 생각보다 느릴 수 있다.

saveAll(items)는 이름만 보면 한 번에 전부 저장하는 Bulk Insert처럼 보이지만, 실제로는 그렇지 않다.

JPA는 영속성 컨텍스트 안에서 각 엔티티의 변경 여부를 추적한다 (Dirty Checking). 1,000건을 saveAll에 넘기면 JPA는 각 엔티티를 하나씩 순회하면서 변경된 필드를 감지하고, 변경된 것에 대해 개별 UPDATE 쿼리를 생성한다. 결과적으로 1,000번의 UPDATE 쿼리가 DB로 날아간다.

UPDATE member SET grade = 'VIP' WHERE id = 1;
UPDATE member SET grade = 'VIP' WHERE id = 2;
UPDATE member SET grade = 'VIP' WHERE id = 3;
-- ... (1,000번 반복)

이게 JPA Writer의 함정이다. 코드 한 줄로 끝나는 것처럼 보이지만 내부에서는 개별 쿼리가 반복 실행된다.

나의 생각
Flash Deal 프로젝트에서 TPS 최적화를 할 때도 비슷한 경험이 있었다. "한 줄 코드"라고 해서 "한 번의 DB 작업"이 되는 건 아니다. 특히 ORM을 쓸 때는 추상화 뒤에서 실제로 어떤 쿼리가 나가는지 반드시 확인해야 한다. show_sql=true 설정이나 p6spy 같은 도구가 필수인 이유가 여기에 있다.

해결책: JdbcBatchItemWriter

대량 insert/update가 필요할 때는 JdbcBatchItemWriter를 쓴다. JPA를 우회하고 JDBC 배치 업데이트로 한 번에 여러 건을 처리한다.

@Bean
public ItemWriter<Member> jdbcMemberWriter(DataSource dataSource) {
    return new JdbcBatchItemWriterBuilder<Member>()
            .dataSource(dataSource)
            .sql("UPDATE member SET grade = :grade WHERE id = :id")
            .beanMapped()
            .build();
}

이렇게 하면 JDBC 배치 업데이트가 적용되어, 1,000건을 처리하는 데 드는 쿼리 횟수가 획기적으로 줄어든다.

어떤 Writer를 써야 할까

두 Writer는 트레이드 오프 관계에 있다.

JPA Writer (saveAll)를 쓰는 경우

데이터 양이 적고 성능이 크리티컬하지 않을 때
엔티티의 라이프사이클(영속성 컨텍스트, 이벤트, 캐스케이드)이 중요할 때
도메인 로직을 엔티티 메서드로 활용해야 할 때

JdbcBatchItemWriter를 쓰는 경우

대량 insert/update로 성능이 크리티컬할 때
단순 데이터 이동 작업이라 엔티티 라이프사이클이 필요 없을 때
메모리 사용량을 최소화해야 할 때

나의 생각
이번 예제 코드에서는 편의상 saveAll을 썼지만, 실제 100만 건 처리 배치라면 JdbcBatchItemWriter를 쓰는 게 맞다. 실무에서는 "간결한 코드"와 "실행 시간"을 저울질해야 하는 상황이 많다. 특히 SLA가 있는 배치라면 더더욱.

배치 실행하는 방법

지금까지는 Job을 Bean으로 정의하는 것까지만 다뤘다. 실제로 이 배치를 어떻게 실행하는지는 다루지 않았는데, 이 부분으로 시리즈를 마무리한다.

방법 1. 스케줄러에서 실행

가장 흔한 방법은 @Scheduled로 정해진 시간에 JobLauncher를 호출하는 것이다.

@Component
@RequiredArgsConstructor
public class MemberVipScheduler {

    private final JobLauncher jobLauncher;
    private final Job memberVipJob;

    @Scheduled(cron = "0 0 3 * * *")  // 매일 새벽 3시
    public void runVipJob() throws Exception {
        JobParameters params = new JobParametersBuilder()
                .addString("date", LocalDate.now().minusDays(1).toString())
                .addLong("timestamp", System.currentTimeMillis())
                .toJobParameters();

        jobLauncher.run(memberVipJob, params);
    }
}

2편에서 다룬 내용이 여기서 등장한다.

date 파라미터로 의미 있는 JobInstance 구분 (어제 날짜 기준)
timestamp 파라미터는 강제로 매번 다른 Instance를 만들기 위한 값. 개발/테스트 단계에서 유용하지만 운영에서는 주의해서 사용해야 한다 (중복 실행 방지 기능이 무력화되기 때문에)

방법 2. 수동 실행 (REST API 등)

운영 중 수동으로 실행해야 할 때는 REST 컨트롤러를 열어두기도 한다.

@RestController
@RequiredArgsConstructor
public class BatchController {

    private final JobLauncher jobLauncher;
    private final Job memberVipJob;

    @PostMapping("/admin/batch/vip")
    public ResponseEntity<String> runVipJob(@RequestParam String date) throws Exception {
        JobParameters params = new JobParametersBuilder()
                .addString("date", date)
                .addLong("timestamp", System.currentTimeMillis())
                .toJobParameters();

        JobExecution execution = jobLauncher.run(memberVipJob, params);
        return ResponseEntity.ok("실행됨: " + execution.getStatus());
    }
}

실행 결과 확인하기

배치가 끝나면 메타데이터 테이블에 결과가 기록된다. 2편에서 다룬 그 테이블들이다.

-- 이 Job의 최근 실행 이력
SELECT JOB_EXECUTION_ID, START_TIME, END_TIME, STATUS, EXIT_CODE
FROM BATCH_JOB_EXECUTION je
JOIN BATCH_JOB_INSTANCE ji ON je.JOB_INSTANCE_ID = ji.JOB_INSTANCE_ID
WHERE ji.JOB_NAME = 'memberVipJob'
ORDER BY START_TIME DESC
LIMIT 10;

-- 특정 실행의 Step별 처리 건수
SELECT STEP_NAME, STATUS, READ_COUNT, WRITE_COUNT, FILTER_COUNT, ROLLBACK_COUNT
FROM BATCH_STEP_EXECUTION
WHERE JOB_EXECUTION_ID = ?;

여기서 FILTER_COUNT가 주목할 만한 지표다. Processor가 null을 반환해서 걸러낸 건수가 이 컬럼에 기록된다. VIP 배치라면 "이미 VIP였던 회원"이 몇 명이었는지를 이 값으로 확인할 수 있다.

나의 생각
메타데이터 테이블의 위력이 이 지점에서 실감난다. 운영 중 "어제 VIP 배치에서 얼마나 걸렀어?"라는 질문에 쿼리 한 번으로 답할 수 있다. 로그를 뒤지는 것보다 훨씬 빠르다. 2편에서 메타데이터 테이블의 존재 이유를 다뤘을 때는 감이 잘 안 왔는데, 4편에서 실제 운영 쿼리를 써보니 왜 이 테이블들이 자동으로 만들어지는지 이해가 됐다.

시리즈 마무리

4편의 여정이 끝났다. 시리즈 전체에서 다룬 내용을 정리하면 다음과 같다.

1편: Spring Batch가 해결하는 5가지 문제
2편: Job, JobInstance, JobExecution의 관계와 메타데이터
3편: Chunk 기반 처리의 원리, Job/Step 구조, Processor 없는 예제
4편: Processor가 포함된 실전 코드, JPA Writer의 함정, 실행 방법

이 시리즈는 Spring Batch 전체를 다루는 가이드가 아니라, 실무 투입 전에 반드시 알아야 할 기초를 정리한 것이다. 이 위에 쌓아야 할 주제는 아직 많다.

Retry / Skip 전략의 실전 활용
JobParameters 검증과 @JobScope, @StepScope
Reader 종류별 성능 비교 (JpaPagingItemReader vs JdbcCursorItemReader)
Chunk size 튜닝, JDBC Writer 최적화
조건부 Step Flow 제어
Listener를 통한 모니터링 및 알림
대용량 파티셔닝과 병렬 처리

나의 생각
여기서 일단 멈추기로 했다. 위 주제들을 지금 다 정리하려면 분량도 방대하고, 아직 실무에서 부딪혀보지 않은 내용이 많아서 깊이가 부족해진다. 현업에서 실제로 Spring Batch를 돌려보고, 장애를 겪어보고, 성능 이슈를 마주친 뒤에 그 경험을 글로 정리하는 것이 나한테도 독자한테도 더 가치 있을 것이다.

웨이트리프팅에서도 똑같다. 100kg 들어본 적 없는 사람이 150kg 스쿼트 팁을 정리할 수는 없다. 배운 만큼, 해본 만큼 기록한다.

다음 주부터 실무에서 Spring Batch를 실제로 돌려보고, 거기서 나오는 문제와 해결 과정을 또 글로 남기려 한다. 시리즈는 여기서 마무리하지만, Spring Batch 학습은 계속된다.

참고 자료

[Spring Batch] 3편. Chunk 기반 처리의 원리와 Job/Step 구조

김코딩딩 — Sat, 18 Apr 2026 20:12:25 +0900

들어가며

1편에서는 Spring Batch가 왜 필요한지, 2편에서는 Job/JobInstance/JobExecution의 관계를 다뤘다. 여기까지는 "무엇을 위한 프레임워크인가"에 대한 이야기였다.

이번 편부터는 드디어 실제 구조와 코드를 본다. 이 글에서는 Spring Batch의 실행 단위인 Step이 어떻게 생겼는지, 그리고 Chunk 기반 처리가 내부에서 어떻게 돌아가는지 정리한다.

나의 생각
개념을 탄탄히 다진 뒤에 코드를 보니 이해 속도가 확실히 달랐다. 웨이트리프팅을 할 때도 기본 자세가 잡혀있으면 새로운 종목을 배울 때 훨씬 빠르게 익혀지는 것과 같은 감각이다.

Job은 Step의 묶음이다

1편에서 Job이라는 단어를 여러 번 썼지만, 실제로 Job 안에는 하나 이상의 Step이 들어있다. Job 자체가 데이터를 처리하는 게 아니라, Step들이 순서대로 실행되면서 실제 작업을 수행한다.

일상 비유로 이해해보자.

"저녁 준비"라는 Job은 세 가지 Step으로 나뉜다. 장보기, 요리하기, 설거지. 만약 요리하기 단계에서 실수가 있었다면 장보기를 다시 할 필요는 없다. 이미 완료된 단계는 건너뛰고 실패한 단계부터 다시 하면 된다.

Spring Batch도 똑같다. 일일 정산 Job을 "거래 조회 → 정산 계산 → 결과 저장" 같은 Step으로 나눠두면, 정산 계산에서 실패했을 때 거래 조회를 다시 하지 않고 정산 계산부터 이어서 실행할 수 있다. 이 상태는 2편에서 다룬 BATCH_STEP_EXECUTION 테이블에 기록된다.

나의 생각
처음 이 구조를 봤을 때는 "그냥 하나의 Step으로 다 하면 안 되나?"라고 생각했다. 하지만 운영 중 장애를 떠올려보면 답이 나온다. 1시간짜리 배치에서 거의 끝날 때쯤 실패했는데 처음부터 다시 돌려야 한다면? 실패 포인트가 명확하게 구분되어 있을수록 운영 비용이 줄어든다. Step 분리는 "언제든 장애가 날 수 있다"는 전제 위에서 설계된 것이다.

Step의 두 가지 종류

Step을 구현하는 방식에는 두 가지가 있다. 이 구분이 중요한 이유는, 실무에서 어떤 방식을 선택할지 고민하는 첫 번째 지점이기 때문이다.

Chunk 기반 Step

데이터를 일정 단위로 읽고, 가공하고, 저장하는 과정을 반복하는 방식이다. Spring Batch를 쓰는 이유 대부분이 여기에 해당한다.

Spring Batch uses a "chunk-oriented" processing style in its most common implementation.
— Spring Batch Reference: Chunk-oriented Processing

회원 100만 명의 등급을 재계산하거나, 거래 내역을 일괄 정산하거나, 로그 파일을 DB로 적재하는 등 대량 데이터를 반복 처리해야 할 때 사용한다.

Tasklet 기반 Step

데이터 반복 없이 한 번 실행하고 끝나는 단순 작업에 쓴다.

오래된 파일 삭제
배치 시작 전 디렉토리 초기화
외부 API 한 번만 호출

이런 단발성 작업을 억지로 Chunk 방식으로 만들면 오히려 코드가 어색해진다.

나의 생각
실무에서 마주칠 일의 대부분은 Chunk 기반일 것이다. Tasklet은 "이런 것도 있구나" 정도로 알아두고, 실제로 뭔가 준비/정리 성격의 전후 작업을 할 때 떠올리는 정도면 충분하다고 느꼈다.

Chunk 기반 Step의 3요소

Chunk 기반 Step은 세 가지 구성 요소로 이루어진다. ItemReader, ItemProcessor, ItemWriter다.

각 요소의 역할은 다음과 같다.

ItemReader - 1건씩 읽는다

데이터 소스(DB, 파일, API 등)에서 데이터를 가져오는 책임
내부적으로는 페이징이나 커서로 조회하지만, 반환은 1건씩 한다
이 덕분에 100만 건을 한 번에 메모리에 올리지 않는다 (OOM 방지)

ItemProcessor - 1건씩 가공한다 (선택 사항)

Reader가 준 데이터를 변환하거나 필터링한다
변환: 입력 타입과 다른 타입으로 바꿔서 반환 가능
필터: null을 반환하면 해당 건은 Writer로 전달되지 않는다
필요 없으면 생략할 수 있다

ItemWriter - Chunk 단위로 저장한다

Processor가 준 결과를 모아서 한 번에 저장한다
Chunk size가 1,000이면 1,000건짜리 List를 받아서 saveAll이나 bulk insert 수행
여기가 성능 최적화의 핵심 포인트다

나의 생각
이 설계가 정말 영리하다고 느꼈다. 읽기는 1건씩(메모리 안정성), 쓰기는 모아서(성능). 혼자서는 절대 한 번에 이런 구조로 설계하지 못했을 것이다. 현업에서 대용량 배치를 짜본 사람들의 노하우가 프레임워크 레벨로 녹아있는 느낌이다.

Chunk 처리 사이클

이제 위 3요소가 어떻게 돌아가는지 전체 흐름을 보자.

Chunk size가 1,000이라면 한 사이클은 다음과 같이 돌아간다.

1. Read 단계 - Reader가 1건씩 1,000번 호출되어 1,000건을 모은다

2. Process 단계 - Processor가 1건씩 1,000번 호출되어 1,000건을 가공한다

3. Write 단계 - Writer가 1,000건짜리 List를 받아서 한 번에 저장한다

4. Commit - 트랜잭션을 커밋한다

이 네 단계가 하나의 Chunk를 이루고, 전체 데이터가 다 처리될 때까지 반복된다. 공식 문서의 의사 코드로 보면 이 흐름이 더 명확하다.

List items = new ArrayList();
for (int i = 0; i < commitInterval; i++) {
    Object item = itemReader.read();
    if (item != null) {
        items.add(item);
    }
}

List processedItems = new ArrayList();
for (Object item : items) {
    Object processedItem = itemProcessor.process(item);
    if (processedItem != null) {
        processedItems.add(processedItem);
    }
}

itemWriter.write(processedItems);

위 코드 블록 전체가 하나의 트랜잭션 안에서 실행된다. 즉 Chunk size = 트랜잭션 단위라는 말이 여기서 확인된다. 1편에서 "Chunk는 메모리 단위이자 트랜잭션 단위"라고 했던 이야기가 바로 이 구조에서 나온 것이다.

전체 코드 구조 미리보기

여기까지 이해했으면, Spring Batch 코드가 대략 어떻게 생겼는지 그림으로 그릴 수 있다. 구체적인 코드는 잠시 뒤에 보고, 먼저 Bean들이 어떻게 연결되는지 구조부터 확인하자.

하나의 @Configuration 클래스 안에 네 개의 @Bean이 있다.

@Bean Job: 어떤 Step들을 순서대로 실행할지 정의
@Bean Step: Chunk size와 Reader, Writer를 연결
@Bean ItemReader: DB에서 1건씩 읽어오는 역할
@Bean ItemWriter: Chunk 단위로 저장하는 역할

(간단한 예제라 Processor는 생략했다. 필요하면 @Bean ItemProcessor를 추가하면 된다.)

이 구조가 Spring Batch 코드의 90%이다. 어떤 배치든 이 뼈대에서 Reader/Processor/Writer 부분의 내용만 달라진다.

간단한 코드 예제

이제 실제 코드를 보자. 가능한 한 가장 단순한 예제로 시작한다.

시나리오

매일 새벽, 탈퇴한 회원의 이메일을 익명화한다. 탈퇴 시 개인정보를 즉시 삭제할 수 없는 법적 보관 기간이 있지만, 이메일은 바로 마스킹 처리해야 한다.

이 배치는 Processor가 필요 없다. DB에서 탈퇴 회원을 조회해서, 이메일을 deleted-{id}@masked.local 같은 형식으로 바꿔서 저장하면 끝이다. Reader와 Writer만으로 구현할 수 있다.

코드

@Configuration
@RequiredArgsConstructor
public class MemberAnonymizeBatchConfig {

    private final JobRepository jobRepository;
    private final PlatformTransactionManager transactionManager;
    private final MemberRepository memberRepository;

    // ① Job 정의
    @Bean
    public Job memberAnonymizeJob() {
        return new JobBuilder("memberAnonymizeJob", jobRepository)
                .start(anonymizeStep())
                .build();
    }

    // ② Step 정의 (Chunk 기반)
    @Bean
    public Step anonymizeStep() {
        return new StepBuilder("anonymizeStep", jobRepository)
                .<Member, Member>chunk(1000, transactionManager)
                .reader(withdrawnMemberReader())
                .writer(anonymizeWriter())
                .build();
    }

    // ③ Reader - 탈퇴한 회원 조회
    @Bean
    public ItemReader<Member> withdrawnMemberReader() {
        return new RepositoryItemReaderBuilder<Member>()
                .name("withdrawnMemberReader")
                .repository(memberRepository)
                .methodName("findByStatus")
                .arguments(List.of(MemberStatus.WITHDRAWN))
                .pageSize(1000)
                .sorts(Map.of("id", Sort.Direction.ASC))
                .build();
    }

    // ④ Writer - 이메일 마스킹 후 저장
    @Bean
    public ItemWriter<Member> anonymizeWriter() {
        return items -> {
            items.forEach(member -> member.anonymizeEmail());
            memberRepository.saveAll(items);
        };
    }
}

코드 한 줄씩 해석

① Job 정의

new JobBuilder("memberAnonymizeJob", jobRepository)
    .start(anonymizeStep())
    .build();

2편에서 다뤘듯이 "memberAnonymizeJob"이 Job 이름이고, 이 이름 + 파라미터 조합이 JobInstance의 유일성을 결정한다. .start()로 첫 Step을 연결하고, 여러 Step이 있다면 .next(step2()).next(step3()) 식으로 체이닝한다.

② Step 정의

.<Member, Member>chunk(1000, transactionManager)

여기서 많은 게 설정된다.

<Member, Member>: Reader가 주는 타입 → Writer가 받는 타입. (Processor가 있으면 Processor 입출력 타입이 중간에 들어간다.)
1000: Chunk size. 1,000건마다 커밋된다.
transactionManager: Chunk 단위로 이 트랜잭션 매니저가 커밋을 담당한다.

③ Reader

RepositoryItemReaderBuilder
    .methodName("findByStatus")
    .arguments(List.of(MemberStatus.WITHDRAWN))
    .pageSize(1000)

RepositoryItemReader는 Spring Data JPA Repository를 Reader로 감싸주는 구현체다. 내부적으로 findByStatus(WITHDRAWN, PageRequest.of(0, 1000)) 같은 페이징 쿼리를 반복 호출해서 1,000건씩 조회한다.

pageSize와 chunkSize는 보통 같은 값으로 맞춘다. 다르게 해도 동작은 하지만, 쿼리 호출 횟수와 커밋 주기가 어긋나서 성능 측면에서 손해를 볼 수 있다.

Reader 종류(JpaPagingItemReader, JdbcCursorItemReader 등)별 차이점은 4편에서 다룬다.

④ Writer

items -> {
    items.forEach(member -> member.anonymizeEmail());
    memberRepository.saveAll(items);
};

Writer는 ItemWriter<Member> 함수형 인터페이스를 람다로 구현한 것이다. 여기서 items는 Reader가 읽어온 1,000건짜리 List다. 각 회원의 이메일을 마스킹하고, saveAll로 일괄 저장한다.

실행 흐름 정리

위 배치가 실제로 돌아가는 흐름은 이렇다.

withdrawnMemberReader가 탈퇴 회원 1번을 읽는다
1,000건이 모일 때까지 Reader를 반복 호출
anonymizeWriter가 1,000건짜리 List를 받아 이메일 마스킹 + saveAll
트랜잭션 커밋
다음 1,000건(1,001~2,000) 처리 → 또 커밋
탈퇴 회원이 더 없을 때까지 반복

나의 생각
실제 코드를 보니 개념 공부한 게 하나하나 연결되는 느낌이었다. "Chunk size가 1,000이면 1,000건마다 커밋된다"는 문장이 추상적이었는데, chunk(1000, transactionManager) 한 줄에 다 담겨있는 걸 보고 명확해졌다. 프레임워크가 좋은 추상화를 제공한다는 게 이런 뜻이구나 싶었다.

정리

이번 편에서 정리한 내용은 다음과 같다.

Job은 Step의 묶음이고, Step 단위로 성공/실패가 기록된다
Chunk 기반 Step은 Read → Process → Write → Commit 사이클을 반복한다
Chunk size = 트랜잭션 단위다
Reader는 1건씩 읽고, Writer는 모아서 저장해서 메모리 안정성과 성능을 동시에 잡는다
Spring Batch 코드의 기본 구조는 @Configuration 안의 Job/Step/Reader/Writer Bean 구성이다

다음 편에서는 이번 편의 간단한 예제보다 더 실무에 가까운 코드를 본다. Processor가 포함된 구조와, 두 예제의 차이를 비교하면서 "Processor가 왜 필요한가"와 "Writer 선택이 성능에 어떤 영향을 주는가"를 정리할 예정이다.

다음 편 예고

4편에서는 어제 구매 금액 10만원 이상 회원의 등급을 VIP로 변경하는 배치를 만들어본다. 3편의 익명화 배치와 비교하면서 Processor의 역할, JPA Writer의 함정, 실행 방법까지 다룬다.

참고 자료

[Spring Batch] 2편. Job, JobInstance, JobExecution의 관계

김코딩딩 — Sat, 18 Apr 2026 16:36:04 +0900

들어가며

1편에서 Spring Batch가 왜 필요한지 알아보았다. 그중 "실패 시 어디까지 처리했는지 기억하고 재시작할 수 있다"는 장점이 있었는데, 이게 어떻게 가능한지 내부를 들여다보면 Job, JobInstance, JobExecution이라는 세 가지 개념이 등장한다.

이 세 용어는 이름이 비슷해서 처음엔 굉장히 헷갈린다. 하지만 한 번 제대로 정리해두면 Spring Batch의 재시작 메커니즘, 중복 실행 방지, 메타데이터 관리가 전부 한 줄기로 꿰어진다.

이 글에서는 내가 학습하면서 가장 헷갈렸던 이 세 개념을 정리한다.

Job이 곧 JobInstance일까?

처음 공식 문서를 봤을 때 가장 먼저 든 생각은 이거였다.

"Job과 JobInstance가 이름도 비슷한데, 같은 거 아닌가?"

결론부터 말하면 다르다. 그리고 이 둘의 관계는 Java의 클래스-객체 관계와 거의 동일하다.

// Java에서 클래스는 설계도, 객체는 그 설계도에서 찍어낸 실체
class Member { ... }
Member m1 = new Member("철수", 28);  // 객체 1
Member m2 = new Member("영희", 27);  // 객체 2

Spring Batch도 똑같다. Job은 코드로 정의하는 "설계도"이고, 실행할 때마다 JobParameters와 조합되어 "JobInstance"라는 실체가 만들어진다.

A Job defines what a job is and how it is to be executed, and a JobInstance is a purely organizational object to group executions together, primarily to enable correct restart semantics.
— Spring Batch Reference: The Domain Language of Batch

나의 생각
이 비유를 스스로 찾아냈을 때 막혔던 퍼즐이 풀리는 느낌이었다. 공식 문서에서도 "Job과 JobInstance는 다르다"라고는 명확히 나와 있지만, 왜 나눴는지에 대한 직관적인 설명은 부족했다. Java 개발자에게는 클래스-객체 비유가 가장 빠른 이해 경로인 것 같다.

JobInstance의 유일성은 어떻게 결정될까

Job이 클래스고 JobInstance가 객체라면, 하나의 Job으로 여러 JobInstance를 만들 수 있다는 뜻이다. 그렇다면 무엇이 각 JobInstance를 구분 짓는가?

답은 JobParameters다. 공식 문서의 표현을 빌리면:

Thus, the contract can be defined as: JobInstance = Job + identifying JobParameters.
— Spring Batch Reference: The Domain Language of Batch

예를 들어 dailySettlementJob이라는 Job을 매일 다른 날짜 파라미터로 실행하면, 매일 다른 JobInstance가 생성된다.

// 4/18 실행 - 4/17 데이터 정산
JobParameters params1 = new JobParametersBuilder()
    .addString("date", "2026-04-17")
    .toJobParameters();

// 4/19 실행 - 4/18 데이터 정산
JobParameters params2 = new JobParametersBuilder()
    .addString("date", "2026-04-18")
    .toJobParameters();

Job 이름은 dailySettlementJob으로 동일하지만 date 파라미터 값이 다르므로, 두 실행은 서로 다른 JobInstance로 취급된다.

나의 생각
"파라미터 이름"이 아니라 "파라미터 값"이 유일성을 결정한다는 점이 중요하다. 두 번 모두 date라는 동일한 키를 쓰지만, 값(2026-04-17 vs 2026-04-18)이 다르기 때문에 다른 JobInstance가 된다. 처음에는 이걸 잘못 이해해서 "같은 파라미터 이름을 쓰면 같은 Instance인가?" 라고 생각했다.

JobExecution은 또 뭘까

JobInstance가 "해야 할 작업 1건"이라면, JobExecution은 그 작업을 실제로 돌린 시도다.

A JobExecution refers to the technical concept of a single attempt to run a Job.
— Spring Batch Reference: The Domain Language of Batch

왜 이렇게 둘로 나눴을까? 바로 재시작 때문이다.

실무에서 배치는 실패할 수 있다. 네트워크가 끊기거나, DB가 순간 포화되거나, 예상하지 못한 데이터가 들어올 수 있다. 그런 일이 일어났을 때 "어떤 작업의 몇 번째 시도였는지"를 추적할 구조가 필요하다.

위 그림을 보면 이해가 쉽다:

Job: dailySettlementJob 하나
JobInstance: 날짜별로 3개 (4/17, 4/18, 4/19)
JobExecution:
- Instance A (4/17): 첫 시도에 성공 → Execution 1개
- Instance B (4/18): 첫 시도 실패, 두 번째 시도에 성공 → Execution 2개
- Instance C (4/19): 첫 시도에 성공 → Execution 1개

중요한 건 Instance B의 경우, 같은 JobInstance 아래에 두 개의 JobExecution이 쌓였다는 점이다. 첫 실패가 기록으로 남아있기 때문에 두 번째 시도에서 "30만 건 처리 완료된 상태였지" 하고 이어서 갈 수 있는 것이다.

나의 생각
이 구조는 장애 복구 관점에서 굉장히 잘 설계되어 있다. 운영 중 장애가 나면 실패한 Execution의 이력을 보고 원인을 파악하고, 같은 Instance로 재실행하면 이어서 처리된다. 결제나 정산처럼 절대 중복 처리되면 안 되는 도메인에서 Spring Batch를 쓰는 이유가 여기에 있다.

같은 파라미터로 재실행하면 어떻게 될까

위 그림에서 Instance B가 "실패 → 재시도"로 Execution 2개를 가진 것을 보면, 이런 의문이 생긴다.

"그럼 이미 성공한 Instance A(4/17)를 실수로 또 실행하면 Execution이 2개 생기는 건가?"

답은 아니다. Spring Batch는 이런 경우 아예 실행 자체를 차단한다.

규칙을 정리하면:

이전 실행 상태	재실행 시도 결과
COMPLETED (성공)	JobInstanceAlreadyCompleteException 발생, 실행 차단
FAILED (실패)	같은 JobInstance에 새 JobExecution 생성, 이어서 실행

공식 문서의 표현은 다음과 같다.

If it is run again with the same identifying job parameters as the first run, a new JobExecution is created. However, there is still only one JobInstance.
— Spring Batch Reference: The Domain Language of Batch

(위 문장은 실패 후 재실행 시나리오에 대한 설명이다. 성공한 Instance를 재실행하려 하면 예외가 발생한다.)

실무에서 만날 수 있는 상황

이 규칙이 왜 중요한지 실무 관점에서 생각해보자.

새벽에 정산 배치가 성공적으로 끝났는데, 코드에 버그가 있어서 정산 금액이 잘못 계산됐다는 게 오전에 발견됐다. CTO가 "어제 날짜로 다시 정산 돌려!"라고 지시한다. 같은 파라미터로 재실행 버튼을 누르면?

답: JobInstanceAlreadyCompleteException이 발생하며 실행이 차단된다.

이럴 때는 파라미터에 식별자를 추가하여 새로운 JobInstance로 만들거나, 별도의 보정 Job을 작성해서 실행하는 방식으로 해결한다.

// 방법 1: 파라미터에 식별자 추가
JobParameters params = new JobParametersBuilder()
    .addString("date", "2026-04-17")
    .addString("reason", "bugfix-2026-04-18")  // 새 Instance가 됨
    .toJobParameters();

나의 생각
처음엔 "왜 성공한 걸 다시 못 돌리게 막아놨지?"라고 의아했다. 하지만 정산, 결제, 포인트 지급 같은 도메인을 생각해보면 당연한 설계다. 실수로 한 번 더 돌렸다가는 돈이 두 번 빠져나가는 사고가 날 수 있다. Spring Batch는 "프레임워크가 개발자의 실수를 막아주는" 사례라고 느꼈다. Saga 패턴에서 보상 트랜잭션(Compensating Transaction)을 별도로 설계하는 철학과도 비슷한 결이다.

이 모든 상태는 어디에 저장될까

Job, JobInstance, JobExecution의 상태 정보는 어디엔가 영구적으로 저장되어야 한다. 메모리에만 있으면 프로세스가 죽는 순간 날아가서 재시작이 불가능하다.

Spring Batch는 이를 위해 9개의 메타데이터 테이블을 자동으로 생성한다.

각 테이블의 역할은 다음과 같다.

Job 레벨

BATCH_JOB_INSTANCE: JobInstance 정보 (Job 이름, 파라미터 해시)
BATCH_JOB_EXECUTION: JobExecution 정보 (시작/종료 시간, 상태)
BATCH_JOB_EXECUTION_PARAMS: 전달받은 JobParameters의 실제 값
BATCH_JOB_EXECUTION_CONTEXT: Job 단위 상태 저장소 (재시작용)

Step 레벨

BATCH_STEP_EXECUTION: Step 실행 정보 (read/write/skip/commit 카운트)
BATCH_STEP_EXECUTION_CONTEXT: Step 단위 상태 저장소 (재시작용, 예: 마지막 처리 ID)

시퀀스

BATCH_JOB_INSTANCE_SEQ, BATCH_JOB_EXECUTION_SEQ, BATCH_STEP_EXECUTION_SEQ: 각 테이블의 PK 생성용 시퀀스

실무에서 유용한 쿼리

배치 운영 중 이 테이블들은 가장 먼저 조회하게 된다.

-- 최근 실행된 Job 이력 확인
SELECT
    ji.JOB_NAME,
    je.JOB_EXECUTION_ID,
    je.START_TIME,
    je.END_TIME,
    je.STATUS,
    je.EXIT_CODE
FROM BATCH_JOB_INSTANCE ji
JOIN BATCH_JOB_EXECUTION je ON ji.JOB_INSTANCE_ID = je.JOB_INSTANCE_ID
ORDER BY je.START_TIME DESC
LIMIT 20;

-- 특정 실행의 Step별 처리 건수 확인
SELECT
    STEP_NAME,
    STATUS,
    READ_COUNT,
    WRITE_COUNT,
    COMMIT_COUNT,
    ROLLBACK_COUNT,
    READ_SKIP_COUNT,
    WRITE_SKIP_COUNT
FROM BATCH_STEP_EXECUTION
WHERE JOB_EXECUTION_ID = ?;

나의 생각
장애 대응 시 가장 먼저 이 테이블을 뒤진다고 한다. 로그보다 빠를 때가 많다는 얘기를 여러 곳에서 봤는데, 실제 구조를 보니 그럴 만하다고 느꼈다. "read_count = 300,000, write_count = 299,998" 같은 숫자만 보면 "어디서 2건이 날아갔는지" 즉시 파악할 수 있는 구조다.

정리

이번 편에서 정리한 내용을 한 문장으로 요약하면 다음과 같다.

Job은 작업의 설계도, JobInstance는 파라미터로 구체화된 작업 1건, JobExecution은 그 작업의 실제 시도다.

그리고 이 세 개념의 상태는 모두 메타데이터 테이블 9개에 자동으로 기록된다. 이 기록이 Spring Batch의 재시작, 중복 실행 방지, 실행 이력 관리를 가능하게 한다.

나의 생각
1편을 쓸 때 "Spring Batch는 대용량 데이터를 안전하고 재시작 가능하게 처리하는 프레임워크"라고 정리했었다. 2편을 쓰면서 보니 "안전성"과 "재시작성"이 전부 Job-Instance-Execution 구조와 메타데이터 테이블에서 나온다는 걸 명확히 알게 됐다. 다음 편에서는 이제 드디어 실제 코드로 들어가서, Chunk 기반 처리와 Reader/Processor/Writer를 다룬다.

다음 편 예고

다음 편에서는 Spring Batch 실무에서 가장 많이 쓰는 Chunk 기반 처리 구조를 다룬다. ItemReader, ItemProcessor, ItemWriter 세 요소가 각각 어떤 역할을 하고, 실제 코드가 어떻게 생겼는지 회원 등급 재계산 배치 예제로 알아본다.

참고 자료

[Spring Batch] 1편. Spring Batch는 왜 필요할까?

김코딩딩 — Sat, 18 Apr 2026 15:59:20 +0900

들어가며

다음 주부터 실무에서 Spring Batch 작업을 진행하게 되었다. 이름만 들어봤을 뿐 실제로 써본 적은 없어서, 실무 투입 전에 개념부터 차근차근 정리하기로 했다.

이 시리즈는 내가 Spring Batch를 학습하며 정리한 기록이다. 단순히 "이렇게 쓰세요"가 아니라, 왜 이 프레임워크가 필요한지부터 이해하고 싶었다. 그래야 나중에 실무에서 문제가 생겼을 때 원인을 제대로 파악할 수 있을 것 같았기 때문이다.

나의 생각
새로운 기술을 배울 때 "어떻게 쓰는지"보다 "왜 만들어졌는지"를 먼저 이해하는 습관은 웨이트리프팅 루틴에서 배운 것 같다. 어떤 동작을 하든 근본 원리를 모르면 부상으로 이어지듯, 기술도 원리를 모르면 예상치 못한 지점에서 장애로 이어진다.

단순 스케줄러로는 왜 부족한가

다음과 같은 요구사항이 들어왔다고 가정해보자.

매일 새벽 3시에 어제 가입한 회원 100만 명에게 환영 이메일을 발송하고, 발송 결과를 DB에 저장해주세요.

Spring Boot에 익숙한 개발자라면 @Scheduled 어노테이션으로 이렇게 작성할 수 있다.

@Scheduled(cron = "0 0 3 * * *")
public void sendWelcomeEmails() {
    List<Member> members = memberRepository.findYesterdayJoined();
    for (Member member : members) {
        emailService.send(member);
        logRepository.save(new EmailLog(member.getId(), "SUCCESS"));
    }
}

겉보기엔 문제없어 보인다. 하지만 실무에서 이 코드는 최소 5가지 문제를 안고 있다. 하나씩 살펴보자.

문제 1. 대용량 데이터를 한 번에 메모리에 올림 (OOM)

findYesterdayJoined()는 100만 건의 Member 객체를 한 번에 List로 반환한다. 이 데이터가 그대로 JVM 힙 메모리에 올라가는데, 회원 한 명당 1KB만 잡아도 1GB 이상이다. 실제 운영 환경에서는 회원 객체가 훨씬 무거우니 OOM(OutOfMemoryError) 으로 배치 프로세스가 죽는다.

나의 생각
개발 환경에서 1만 건으로 테스트하면 문제없이 통과한다. 문제는 운영 배포 후 실제 트래픽이 들어왔을 때 터진다는 것이다. Flash Deal 프로젝트에서 TPS 튜닝하던 시절에도 비슷한 경험이 있었다. 부하 테스트 없이 "잘 되겠지" 하고 배포하면 꼭 터진다.

Spring Batch의 해결책: Chunk 단위로 데이터를 나눠서 처리한다. 예를 들어 Chunk size를 1,000으로 설정하면, 한 번에 1,000건만 읽고 처리하고 저장하고 → 다음 1,000건을 처리하는 식으로 반복한다. 메모리 사용량이 일정하게 유지된다.

Spring Batch uses a "chunk-oriented" processing style in its most common implementation. Chunk oriented processing refers to reading the data one at a time and creating 'chunks' that are written out within a transaction boundary.
— Spring Batch Reference: Chunk-oriented Processing

문제 2. 실패 시 어디서 실패했는지 모름

100만 건 중 30만 번째에서 에러가 터져 프로세스가 죽었다고 하자. 위 코드는 어디까지 처리했는지에 대한 정보를 아무 데도 남기지 않는다.

결과적으로 재실행하면 1번부터 다시 시작한다. 이 경우:

이미 메일 받은 30만 명에게 중복 발송 (사용자 컴플레인)
시간 2배 소요
외부 API(이메일 서비스) 비용 2배

Spring Batch의 해결책: JobRepository라는 메타데이터 저장소가 있다. DB의 BATCH_JOB_EXECUTION, BATCH_STEP_EXECUTION 테이블에 언제, 몇 건까지, 어떤 상태로 처리했는지를 자동으로 기록한다. 덕분에 실패한 지점부터 이어서 재시작할 수 있다.

이 개념(JobInstance, JobExecution)은 2편에서 자세히 다룰 예정이다.

문제 3. 실패 처리 전략이 없음

중간에 실패가 나면 for 루프는 그냥 예외가 터지고 끝난다. 하지만 실무에서 실패는 두 가지 성격으로 나뉜다.

(1) 일시적 실패 (Transient Failure)

네트워크 일시 끊김, DB 커넥션 순간 포화
다시 시도하면 성공할 가능성이 높음 → 재시도(Retry)가 답

(2) 영구적 실패 (Permanent Failure)

이메일 주소 형식 오류, 탈퇴한 회원
몇 번을 다시 해도 실패 → 건너뛰기(Skip)가 답

단순 for + try-catch로 이 로직을 구현하려면 코드가 지저분해진다. 또한 재시도 횟수 추적, 스킵된 건수 집계 같은 부가 로직도 직접 다 만들어야 한다.

Spring Batch의 해결책: 선언적으로 설정할 수 있다.

.faultTolerant()
.retry(NetworkException.class).retryLimit(3)
.skip(InvalidEmailException.class).skipLimit(100)

If a FlatFileParseException is encountered while reading, it is always thrown for that record. Resetting the ItemReader does not help. However, for other exceptions (such as a DeadlockLoserDataAccessException, which indicates that the current process has attempted to update a record that another process holds a lock on), waiting and trying again might result in success.
— Spring Batch Reference: Configuring Retry Logic

나의 생각
재시도와 건너뛰기를 구분하는 관점이 흥미롭다. 기존에 API 개발할 때는 "실패하면 예외 던지고 끝"이었는데, 배치는 "어떤 실패는 참고 넘어가고, 어떤 실패는 다시 해봐야 한다"는 더 섬세한 제어가 필요하다. Circuit Breaker 패턴을 공부했을 때와 비슷한 결의 철학이라고 느꼈다.

문제 4. 트랜잭션 경계가 극단적

트랜잭션을 어떻게 설정하느냐에 따라 두 가지 극단이 생긴다.

(1) 전체를 하나의 트랜잭션으로 묶는 경우: 999,999번째에서 실패 시 100만 건 전부 롤백. 2시간 돌린 게 날아간다.

(2) 트랜잭션 없이 건별로 커밋하는 경우: 중간에 서버가 죽으면 어디까지 반영됐는지 알 수 없고 정합성이 깨진다.

Spring Batch의 해결책: Chunk 단위가 곧 트랜잭션 단위다. Chunk size가 1,000이면 1,000건마다 커밋된다. 중간에 실패해도 이전에 커밋된 건은 안전하게 보존되고, 현재 Chunk만 롤백된다.

Once the number of items read equals the commit interval, the entire chunk is written out by the ItemWriter, and then the transaction is committed.
— Spring Batch Reference: The Commit Interval

문제 5. 실행 이력이 남지 않음

"어제 새벽 배치 잘 돌았나요?", "얼마나 걸렸죠?", "몇 건 실패했나요?"

단순 스케줄러 방식에서는 이 질문에 답하려면 애플리케이션 로그를 뒤져야 한다. 로그 레벨을 제대로 설정해두지 않았거나, 로그 롤링으로 이미 삭제되었다면 답할 방법이 없다.

Spring Batch의 해결책: 모든 실행 이력이 메타데이터 테이블에 자동 저장된다.

Spring Batch를 적용하면 다음 9개의 테이블이 자동으로 생성된다.

BATCH_JOB_INSTANCE
BATCH_JOB_EXECUTION
BATCH_JOB_EXECUTION_PARAMS
BATCH_JOB_EXECUTION_CONTEXT
BATCH_STEP_EXECUTION
BATCH_STEP_EXECUTION_CONTEXT
BATCH_JOB_INSTANCE_SEQ
BATCH_JOB_EXECUTION_SEQ
BATCH_STEP_EXECUTION_SEQ

각 테이블에 언제 실행했는지, 몇 건 처리했는지, 어느 단계에서 실패했는지가 기록된다. SQL 한 번이면 이력 조회가 끝난다.

SELECT JOB_NAME, START_TIME, END_TIME, STATUS, EXIT_CODE
FROM BATCH_JOB_EXECUTION je
JOIN BATCH_JOB_INSTANCE ji ON je.JOB_INSTANCE_ID = ji.JOB_INSTANCE_ID
ORDER BY START_TIME DESC;

각 테이블의 역할은 2편에서 자세히 다룰 예정이다.

정리: Spring Batch가 필요한 5가지 이유

한 줄로 정리하면:

Spring Batch는 대용량 데이터를 안전하고 재시작 가능하게 처리하기 위한 프레임워크다.

어떤 기능을 배우든 "이 기능이 안전성, 재시작성, 관찰 가능성 중 어디에 기여하는가?"로 연결해서 이해하면 머리에 잘 들어온다.

나의 생각
처음에는 "그냥 for 루프로 해도 되지 않나?"라고 생각했다. 실제로 소규모 데이터나 단발성 작업은 그게 맞을 수도 있다. 하지만 데이터가 100만 건 이상, 외부 API 호출이 섞이고, 실패 시 금전적 손해가 생길 수 있는 환경이라면 이야기가 달라진다. 프레임워크의 존재 이유는 "개발자가 이 모든 엣지 케이스를 매번 다시 짜지 않게" 하는 것이다.

다음 편 예고

다음 편에서는 Spring Batch의 핵심 개념인 Job, JobInstance, JobExecution의 관계를 정리한다. 특히 "같은 배치를 두 번 실행하면 어떻게 될까?"라는 질문에 대한 답을 찾아가 볼 예정이다.

참고 자료

옵저버 패턴(Observer Pattern)

김코딩딩 — Wed, 14 Jan 2026 13:02:04 +0900

디자인 패턴 시리즈의 마지막 주제는 옵저버 패턴(Observer Pattern)이다.

템플릿 메서드 패턴이 "알고리즘의 흐름을 정의"하는 거였다면, 옵저버 패턴은 "변화를 알려주는" 것이다.

예를 들어, 유튜브를 생각해보자. 좋아하는 채널을 구독하면, 그 채널에 새 영상이 올라올 때마다 알림이 온다. 채널은 구독자들에게 "새 영상 올렸어요!"라고 자동으로 알려준다.

옵저버 패턴은 이처럼 한 객체의 상태가 변하면, 그것을 지켜보던(Observe) 다른 객체들에게 자동으로 알려주는 패턴이다.

이번 글에서는 옵저버 패턴이 무엇인지, 왜 필요한지, 어떻게 구현하는지 알아보자.

옵저버 패턴의 정의

옵저버 패턴(Observer Pattern)은 객체의 상태 변화를 관찰하는 관찰자(Observer)들의 목록을 객체에 등록하여, 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 관찰자에게 통지하도록 하는 패턴이다.

핵심 특징:

일대다 의존성을 정의한다
주체(Subject)와 관찰자(Observer)로 구성된다
느슨한 결합(Loose Coupling)을 유지한다
발행-구독(Publish-Subscribe) 모델이다

현실 비유:

유튜브 구독 (채널이 새 영상 올리면 구독자들에게 알림)
신문 구독 (신문사가 신문 발행하면 구독자들에게 배달)
날씨 앱 (기상청이 날씨 변경하면 앱들에게 알림)

왜 옵저버 패턴이 필요할까?

날씨 정보를 제공하는 시스템을 개발한다고 가정해보자.

// 문제가 있는 코드

// 날씨 데이터
public class WeatherData {
    private float temperature;
    private float humidity;
    
    // 날씨 변경 시 모든 디스플레이를 직접 업데이트
    public void setMeasurements(float temperature, float humidity) {
        this.temperature = temperature;
        this.humidity = humidity;
        
        // 문제: 디스플레이가 추가될 때마다 코드 수정 필요
        CurrentConditionsDisplay display1 = new CurrentConditionsDisplay();
        display1.update(temperature, humidity);
        
        StatisticsDisplay display2 = new StatisticsDisplay();
        display2.update(temperature, humidity);
        
        ForecastDisplay display3 = new ForecastDisplay();
        display3.update(temperature, humidity);
        
        // 새로운 디스플레이 추가하려면? 또 코드 수정...
    }
}

// 현재 날씨 디스플레이
public class CurrentConditionsDisplay {
    public void update(float temperature, float humidity) {
        System.out.println("현재 날씨: " + temperature + "도, 습도 " + humidity + "%");
    }
}

// 통계 디스플레이
public class StatisticsDisplay {
    public void update(float temperature, float humidity) {
        System.out.println("평균 온도: " + temperature + "도");
    }
}

문제점:

강한 결합: WeatherData가 모든 디스플레이 클래스를 알아야 함
OCP 위반: 새로운 디스플레이 추가 시 WeatherData 수정 필요
유연성 부족: 런타임에 디스플레이를 추가/제거할 수 없음
확장 어려움: 디스플레이가 100개면? 코드가 엄청 길어짐

옵저버 패턴은 "관찰자들을 등록하고, 변화 시 자동으로 알림을 보내자"로 이 문제를 해결한다.

순수 Java로 구현하기

1단계: 인터페이스 정의

// 주체(Subject) 인터페이스
public interface Subject {
    void registerObserver(Observer observer);    // 관찰자 등록
    void removeObserver(Observer observer);      // 관찰자 제거
    void notifyObservers();                      // 관찰자들에게 알림
}

// 관찰자(Observer) 인터페이스
public interface Observer {
    void update(float temperature, float humidity);
}

2단계: 주체(Subject) 구현

// 날씨 데이터 (주체)
public class WeatherData implements Subject {
    private List<Observer> observers;
    private float temperature;
    private float humidity;
    
    public WeatherData() {
        this.observers = new ArrayList<>();
    }
    
    @Override
    public void registerObserver(Observer observer) {
        observers.add(observer);
        System.out.println("관찰자 등록됨");
    }
    
    @Override
    public void removeObserver(Observer observer) {
        observers.remove(observer);
        System.out.println("관찰자 제거됨");
    }
    
    @Override
    public void notifyObservers() {
        for (Observer observer : observers) {
            observer.update(temperature, humidity);
        }
    }
    
    // 날씨 데이터 변경
    public void setMeasurements(float temperature, float humidity) {
        this.temperature = temperature;
        this.humidity = humidity;
        notifyObservers();  // 자동으로 모든 관찰자에게 알림!
    }
}

3단계: 관찰자(Observer) 구현

// 현재 날씨 디스플레이
public class CurrentConditionsDisplay implements Observer {
    private String name;
    
    public CurrentConditionsDisplay(String name) {
        this.name = name;
    }
    
    @Override
    public void update(float temperature, float humidity) {
        System.out.println("[" + name + "] 현재 날씨: " + temperature + "도, 습도 " + humidity + "%");
    }
}

// 통계 디스플레이
public class StatisticsDisplay implements Observer {
    private float totalTemperature = 0;
    private int count = 0;
    
    @Override
    public void update(float temperature, float humidity) {
        totalTemperature += temperature;
        count++;
        float avg = totalTemperature / count;
        System.out.println("[통계] 평균 온도: " + avg + "도");
    }
}

// 예보 디스플레이
public class ForecastDisplay implements Observer {
    @Override
    public void update(float temperature, float humidity) {
        if (temperature > 25) {
            System.out.println("[예보] 날씨가 더워질 것 같습니다");
        } else {
            System.out.println("[예보] 날씨가 선선할 것 같습니다");
        }
    }
}

4단계: 사용 예시

public class Main {
    public static void main(String[] args) {
        // 주체 생성
        WeatherData weatherData = new WeatherData();
        
        // 관찰자 생성 및 등록
        Observer display1 = new CurrentConditionsDisplay("디스플레이1");
        Observer display2 = new StatisticsDisplay();
        Observer display3 = new ForecastDisplay();
        
        weatherData.registerObserver(display1);
        weatherData.registerObserver(display2);
        weatherData.registerObserver(display3);
        
        System.out.println("\n=== 첫 번째 날씨 업데이트 ===");
        weatherData.setMeasurements(25.5f, 65f);
        
        System.out.println("\n=== 두 번째 날씨 업데이트 ===");
        weatherData.setMeasurements(28.0f, 70f);
        
        System.out.println("\n=== 관찰자 하나 제거 ===");
        weatherData.removeObserver(display3);
        
        System.out.println("\n=== 세 번째 날씨 업데이트 ===");
        weatherData.setMeasurements(22.0f, 60f);
        
        System.out.println("\n=== 새로운 관찰자 추가 ===");
        Observer display4 = new CurrentConditionsDisplay("디스플레이4");
        weatherData.registerObserver(display4);
        
        System.out.println("\n=== 네 번째 날씨 업데이트 ===");
        weatherData.setMeasurements(30.0f, 75f);
    }
}

장점:

WeatherData는 구체적인 디스플레이 클래스를 몰라도 됨
런타임에 관찰자 추가/제거 가능
새로운 디스플레이 추가해도 WeatherData 수정 불필요

실전 예제: 주식 가격 알림

// 주식 (주체)
public class Stock implements Subject {
    private List<Observer> observers;
    private String stockName;
    private int price;
    
    public Stock(String stockName, int initialPrice) {
        this.stockName = stockName;
        this.price = initialPrice;
        this.observers = new ArrayList<>();
    }
    
    @Override
    public void registerObserver(Observer observer) {
        observers.add(observer);
    }
    
    @Override
    public void removeObserver(Observer observer) {
        observers.remove(observer);
    }
    
    @Override
    public void notifyObservers() {
        for (Observer observer : observers) {
            observer.update(stockName, price);
        }
    }
    
    public void setPrice(int price) {
        System.out.println("\n  " + stockName + " 가격 변동: " + this.price + "원 → " + price + "원");
        this.price = price;
        notifyObservers();
    }
}

// 투자자 (관찰자)
public class Investor implements Observer {
    private String name;
    private int targetPrice;
    
    public Investor(String name, int targetPrice) {
        this.name = name;
        this.targetPrice = targetPrice;
    }
    
    @Override
    public void update(String stockName, int price) {
        if (price >= targetPrice) {
            System.out.println("  [" + name + "] " + stockName + "이(가) 목표가(" + targetPrice + "원) 도달! 현재가: " + price + "원");
        } else {
            System.out.println("  [" + name + "] " + stockName + " 관찰 중... 현재가: " + price + "원");
        }
    }
}

// 알림 봇 (관찰자)
public class NotificationBot implements Observer {
    @Override
    public void update(String stockName, int price) {
        System.out.println("  [알림봇] " + stockName + " 가격 알림: " + price + "원");
    }
}

// 사용
public class Main {
    public static void main(String[] args) {
        // 삼성전자 주식
        Stock samsung = new Stock("삼성전자", 70000);
        
        // 투자자들 등록
        Investor investor1 = new Investor("김투자", 75000);
        Investor investor2 = new Investor("이부자", 80000);
        NotificationBot bot = new NotificationBot();
        
        samsung.registerObserver(investor1);
        samsung.registerObserver(investor2);
        samsung.registerObserver(bot);
        
        // 가격 변동
        samsung.setPrice(72000);
        samsung.setPrice(76000);
        samsung.setPrice(81000);
    }
}

실전 예제: 채팅방

// 채팅방 (주체)
public class ChatRoom implements Subject {
    private List<Observer> users;
    private String roomName;
    
    public ChatRoom(String roomName) {
        this.roomName = roomName;
        this.users = new ArrayList<>();
    }
    
    @Override
    public void registerObserver(Observer observer) {
        users.add(observer);
        System.out.println("  새로운 사용자가 [" + roomName + "]에 입장했습니다.");
    }
    
    @Override
    public void removeObserver(Observer observer) {
        users.remove(observer);
        System.out.println("  사용자가 [" + roomName + "]에서 퇴장했습니다.");
    }
    
    @Override
    public void notifyObservers(String message) {
        for (Observer observer : users) {
            observer.update(message);
        }
    }
    
    public void sendMessage(String sender, String message) {
        String fullMessage = "[" + sender + "] " + message;
        System.out.println("\n  메시지 전송: " + fullMessage);
        notifyObservers(fullMessage);
    }
}

// 인터페이스 수정
interface Subject {
    void registerObserver(Observer observer);
    void removeObserver(Observer observer);
    void notifyObservers(String message);
}

interface Observer {
    void update(String message);
}

// 사용자 (관찰자)
public class User implements Observer {
    private String name;
    
    public User(String name) {
        this.name = name;
    }
    
    @Override
    public void update(String message) {
        System.out.println("  → " + name + "님이 수신: " + message);
    }
    
    public String getName() {
        return name;
    }
}

// 사용
public class Main {
    public static void main(String[] args) {
        // 채팅방 생성
        ChatRoom chatRoom = new ChatRoom("디자인패턴 스터디");
        
        // 사용자들
        User user1 = new User("김도균");
        User user2 = new User("이철수");
        User user3 = new User("박영희");
        
        // 입장
        chatRoom.registerObserver(user1);
        chatRoom.registerObserver(user2);
        chatRoom.registerObserver(user3);
        
        // 메시지 전송
        chatRoom.sendMessage("김도균", "안녕하세요!");
        chatRoom.sendMessage("이철수", "반갑습니다~");
        
        // 퇴장
        chatRoom.removeObserver(user3);
        
        // 메시지 전송
        chatRoom.sendMessage("김도균", "오늘 스터디 열심히 해봐요!");
    }
}

Java의 내장 옵저버 (Deprecated)

Java에는 Observer 인터페이스와 Observable 클래스가 있었지만, Java 9부터 Deprecated 되었다.

// 예전 방식 (사용 비추천)
import java.util.Observable;
import java.util.Observer;

public class WeatherData extends Observable {
    private float temperature;
    
    public void setTemperature(float temperature) {
        this.temperature = temperature;
        setChanged();  // 변경 표시
        notifyObservers(temperature);  // 알림
    }
}

Deprecated 이유:

Observable이 클래스라서 상속 제한
스레드 안전하지 않음
이벤트 모델이 제한적

대신 사용:

직접 구현 (위 예시처럼)
Spring의 ApplicationEvent
RxJava, Flow API

옵저버 패턴의 장점

느슨한 결합: 주체와 관찰자가 독립적
OCP 준수: 새로운 관찰자 추가 시 주체 수정 불필요
동적 구독: 런타임에 관찰자 추가/제거 가능
브로드캐스트: 한 번에 여러 객체에게 알림

옵저버 패턴의 단점

알림 순서: 관찰자들의 알림 순서를 보장할 수 없음
메모리 누수: 관찰자를 제거하지 않으면 메모리 누수 발생 가능
예상치 못한 업데이트: 관찰자가 많으면 성능 저하
순환 의존성: 관찰자가 주체를 업데이트하면 무한 루프

Spring에서의 옵저버 패턴

Spring의 이벤트 시스템이 옵저버 패턴을 사용한다.

// 이벤트 정의
public class OrderCreatedEvent {
    private Long orderId;
    private int amount;
    
    public OrderCreatedEvent(Long orderId, int amount) {
        this.orderId = orderId;
        this.amount = amount;
    }
    
    public Long getOrderId() { return orderId; }
    public int getAmount() { return amount; }
}

// 이벤트 발행자 (주체)
@Service
public class OrderService {
    private final ApplicationEventPublisher eventPublisher;
    
    public OrderService(ApplicationEventPublisher eventPublisher) {
        this.eventPublisher = eventPublisher;
    }
    
    public void createOrder(Long orderId, int amount) {
        // 주문 생성 로직
        System.out.println("주문 생성: " + orderId);
        
        // 이벤트 발행
        eventPublisher.publishEvent(new OrderCreatedEvent(orderId, amount));
    }
}

// 이벤트 리스너 (관찰자)
@Component
public class EmailNotificationListener {
    @EventListener
    public void handleOrderCreated(OrderCreatedEvent event) {
        System.out.println("  이메일 발송: 주문번호 " + event.getOrderId());
    }
}

@Component
public class SmsNotificationListener {
    @EventListener
    public void handleOrderCreated(OrderCreatedEvent event) {
        System.out.println("  SMS 발송: 주문번호 " + event.getOrderId());
    }
}

@Component
public class PointRewardListener {
    @EventListener
    public void handleOrderCreated(OrderCreatedEvent event) {
        int points = event.getAmount() / 100;
        System.out.println("⭐ 포인트 적립: " + points + "점");
    }
}

사용:

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        ApplicationContext context = SpringApplication.run(Application.class, args);
        OrderService orderService = context.getBean(OrderService.class);
        
        orderService.createOrder(1L, 50000);
    }
}

실무에서 언제 사용할까?

사용하면 좋은 경우:

한 객체의 변경이 다른 객체들에게 영향을 줄 때
어떤 객체들이 영향을 받을지 미리 알 수 없을 때
이벤트 기반 시스템을 만들 때
GUI 프로그래밍 (버튼 클릭 이벤트 등)

사용하지 않아도 되는 경우:

관찰자가 하나뿐일 때
실시간 알림이 필요 없을 때
강한 결합이 문제되지 않을 때

핵심 원칙:

"한 객체의 변화를 여러 객체에게 자동으로 알려야 한다면 옵저버 패턴을 고려하라"

결론

옵저버 패턴은 객체 간의 느슨한 결합을 유지하면서 상태 변화를 자동으로 알려주는 패턴이다.

기억해야 할 포인트:

일대다 관계를 정의한다
느슨한 결합을 유지한다
발행-구독 모델이다
Spring의 이벤트 시스템이 대표적
런타임에 구독/해지 가능

이것으로 디자인 패턴 시리즈를 마무리한다. 지금까지 배운 11가지 패턴은 실무에서 가장 많이 사용되는 핵심 패턴들이다. 모든 패턴을 외울 필요는 없지만, 각 패턴이 어떤 문제를 해결하는지 이해하고, 적절한 상황에서 사용할 수 있다면 훨씬 더 나은 코드를 작성할 수 있을 것이다.

디자인 패턴 학습의 핵심:

패턴을 암기하지 말고 이해하라
무조건 사용하지 말고 필요할 때만 사용하라
간단한 문제에 복잡한 패턴을 쓰지 마라 (오버엔지니어링 주의)
실제 프로젝트에 적용하며 배워라

템플릿 메서드 패턴(Template Method Pattern)

김코딩딩 — Wed, 14 Jan 2026 12:46:47 +0900

디자인 패턴 시리즈의 열 번째 주제는 템플릿 메서드 패턴(Template Method Pattern)이다.

전략 패턴이 "알고리즘 전체를 교체"하는 거였다면, 템플릿 메서드 패턴은 "알고리즘의 일부만 변경"하는 것이다.

예를 들어, 라면을 끓이는 과정을 생각해보자. 물을 끓이고 → 스프를 넣고 → 면을 넣고 → 끓이는 순서는 똑같다. 하지만 신라면은 매운 스프, 안성탕면은 짠 스프를 넣는다. 전체 흐름은 같지만 일부만 다른 것이다. 템플릿 메서드 패턴은 이처럼 알고리즘의 "뼈대(Template)"는 정의하고, 세부 단계는 하위 클래스에서 구현하는 패턴이다

이번 글에서는 템플릿 메서드 패턴이 무엇인지, 왜 필요한지, 어떻게 구현하는지 알아보자.

템플릿 메서드 패턴의 정의

템플릿 메서드 패턴(Template Method Pattern)은 알고리즘의 골격을 정의하고, 일부 단계를 서브클래스에서 구현하도록 하는 패턴이다. 알고리즘의 구조는 변경하지 않으면서, 특정 단계만 재정의할 수 있다.

핵심 특징:

알고리즘의 골격을 정의한다
일부 단계를 서브클래스에 위임한다
상속을 사용한다
코드 중복을 제거한다

현실 비유:

라면 끓이기 (전체 과정은 같지만 스프만 다름)
문서 작성 (헤더/본문/푸터 구조는 같지만 내용만 다름)
시험 보기 (입실→시험→퇴실은 같지만 과목만 다름)

왜 템플릿 메서드 패턴이 필요할까?

음료를 만드는 카페 시스템을 개발한다고 가정해보자.

// 문제가 있는 코드

// 커피 만들기
public class Coffee {
    public void make() {
        System.out.println("1. 물을 끓인다");
        System.out.println("2. 커피를 우려낸다");
        System.out.println("3. 컵에 따른다");
        System.out.println("4. 설탕과 우유를 추가한다");
    }
}

// 홍차 만들기
public class Tea {
    public void make() {
        System.out.println("1. 물을 끓인다");      // 중복!
        System.out.println("2. 차를 우려낸다");
        System.out.println("3. 컵에 따른다");      // 중복!
        System.out.println("4. 레몬을 추가한다");
}

// 핫초코 만들기
public class HotChocolate {
    public void make() {
        System.out.println("1. 물을 끓인다");      // 중복!
        System.out.println("2. 초코를 녹인다");
        System.out.println("3. 컵에 따른다");      // 중복!
        System.out.println("4. 마시멜로를 추가한다");
    }
}

문제점:

코드 중복: "물을 끓인다", "컵에 따른다"가 반복됨
유지보수 어려움: 순서 변경 시 모든 클래스 수정 필요
일관성 없음: 각 클래스가 독립적으로 동작
확장 어려움: 새로운 음료 추가 시 또 중복 코드 작성

템플릿 메서드 패턴은 "공통 부분은 부모 클래스에, 다른 부분만 자식 클래스에"로 이 문제를 해결한다.

순수 Java로 구현하기

1단계: 추상 클래스 정의 (템플릿 메서드)

// 음료 만들기의 템플릿
public abstract class Beverage {
    
    // 템플릿 메서드: 알고리즘의 골격
    public final void make() {
        boilWater();        // 공통: 물 끓이기
        brew();             // 다름: 서브클래스에서 구현
        pourInCup();        // 공통: 컵에 따르기
        addCondiments();    // 다름: 서브클래스에서 구현
    }
    
    // 공통 메서드
    private void boilWater() {
        System.out.println("물을 끓인다");
    }
    
    private void pourInCup() {
        System.out.println("컵에 따른다");
    }
    
    // 추상 메서드: 서브클래스가 구현해야 함
    protected abstract void brew();
    protected abstract void addCondiments();
}

2단계: 구체적인 클래스 구현

// 커피
public class Coffee extends Beverage {
    @Override
    protected void brew() {
        System.out.println("커피를 우려낸다");
    }
    
    @Override
    protected void addCondiments() {
        System.out.println("설탕과 우유를 추가한다");
    }
}

// 홍차
public class Tea extends Beverage {
    @Override
    protected void brew() {
        System.out.println("차를 우려낸다");
    }
    
    @Override
    protected void addCondiments() {
        System.out.println("레몬을 추가한다");
    }
}

// 핫초코
public class HotChocolate extends Beverage {
    @Override
    protected void brew() {
        System.out.println("초코를 녹인다");
    }
    
    @Override
    protected void addCondiments() {
        System.out.println("마시멜로를 추가한다");
    }
}

3단계: 사용 예시

public class Main {
    public static void main(String[] args) {
        System.out.println("=== 커피 만들기 ===");
        Beverage coffee = new Coffee();
        coffee.make();
        
        System.out.println("\n=== 홍차 만들기 ===");
        Beverage tea = new Tea();
        tea.make();
        
        System.out.println("\n=== 핫초코 만들기 ===");
        Beverage hotChocolate = new HotChocolate();
        hotChocolate.make();
    }
}

장점:

중복 코드 제거됨
알고리즘 구조를 한 곳에서 관리
새로운 음료 추가 쉬움
일관성 보장

Hook 메서드 (선택적 단계)

템플릿 메서드에 선택적 단계를 추가할 수 있다.

public abstract class Beverage {
    
    // 템플릿 메서드
    public final void make() {
        boilWater();
        brew();
        pourInCup();
        
        // Hook: 원하면 추가 재료를 넣을 수 있음
        if (wantsCondiments()) {
            addCondiments();
        }
    }
    
    private void boilWater() {
        System.out.println("물을 끓인다");
    }
    
    private void pourInCup() {
        System.out.println("컵에 따른다");
    }
    
    protected abstract void brew();
    protected abstract void addCondiments();
    
    // Hook 메서드: 기본 구현 제공, 필요시 오버라이드
    protected boolean wantsCondiments() {
        return true;  // 기본값
    }
}

// 블랙커피 (추가 재료 없음)
public class BlackCoffee extends Beverage {
    @Override
    protected void brew() {
        System.out.println("커피를 우려낸다");
    }
    
    @Override
    protected void addCondiments() {
        System.out.println("아무것도 추가하지 않는다");
    }
    
    @Override
    protected boolean wantsCondiments() {
        return false;  // 추가 재료 안 넣음
    }
}

// 사용
public class Main {
    public static void main(String[] args) {
        System.out.println("=== 블랙커피 만들기 ===");
        Beverage blackCoffee = new BlackCoffee();
        blackCoffee.make();
    }
}
```

**실행 결과:**
```
=== 블랙커피 만들기 ===
물을 끓인다
커피를 우려낸다
컵에 따른다
(추가 재료 단계 생략됨)

실전 예제: 게임 캐릭터

// 게임 캐릭터 템플릿
public abstract class GameCharacter {
    
    // 템플릿 메서드: 게임 플레이 흐름
    public final void play() {
        initialize();
        startPlaying();
        
        if (hasSpecialSkill()) {
            useSpecialSkill();
        }
        
        endPlaying();
    }
    
    // 공통 단계
    private void initialize() {
        System.out.println("  게임 시작");
    }
    
    private void endPlaying() {
        System.out.println("  게임 종료\n");
    }
    
    // 서브클래스가 구현
    protected abstract void startPlaying();
    
    // Hook 메서드
    protected boolean hasSpecialSkill() {
        return false;
    }
    
    protected void useSpecialSkill() {
        // 기본 구현 없음
    }
}

// 전사
public class Warrior extends GameCharacter {
    @Override
    protected void startPlaying() {
        System.out.println("⚔️ 전사: 근접 공격!");
    }
    
    @Override
    protected boolean hasSpecialSkill() {
        return true;
    }
    
    @Override
    protected void useSpecialSkill() {
        System.out.println("  전사 특수기: 광폭화!");
    }
}

// 마법사
public class Mage extends GameCharacter {
    @Override
    protected void startPlaying() {
        System.out.println("  마법사: 마법 공격!");
    }
    
    @Override
    protected boolean hasSpecialSkill() {
        return true;
    }
    
    @Override
    protected void useSpecialSkill() {
        System.out.println("✨ 마법사 특수기: 메테오!");
    }
}

// 궁수
public class Archer extends GameCharacter {
    @Override
    protected void startPlaying() {
        System.out.println("  궁수: 원거리 공격!");
    }
    
    // 특수기 없음 (기본값 사용)
}

// 사용
public class Main {
    public static void main(String[] args) {
        System.out.println("=== 전사 플레이 ===");
        GameCharacter warrior = new Warrior();
        warrior.play();
        
        System.out.println("=== 마법사 플레이 ===");
        GameCharacter mage = new Mage();
        mage.play();
        
        System.out.println("=== 궁수 플레이 ===");
        GameCharacter archer = new Archer();
        archer.play();
    }
}

템플릿 메서드 패턴의 장점

코드 재사용: 공통 로직을 한 곳에 모음
일관성: 알고리즘 구조를 강제
확장 용이: 새로운 구현 추가가 쉬움
유지보수: 공통 부분만 수정하면 전체 반영
제어 반전: 프레임워크가 흐름을 제어

템플릿 메서드 패턴의 단점

상속 의존: 상속을 강제함
유연성 제한: 알고리즘 구조를 바꿀 수 없음
리스코프 치환 원칙 위반 가능: 잘못 설계하면 문제 발생
템플릿 메서드 복잡도: 단계가 많으면 이해하기 어려움

Spring에서의 템플릿 메서드 패턴

Spring의 많은 클래스가 템플릿 메서드 패턴을 사용한다.

JdbcTemplate

// Spring의 JdbcTemplate가 템플릿 메서드 패턴 사용
@Repository
public class UserRepository {
    private final JdbcTemplate jdbcTemplate;
    
    public UserRepository(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }
    
    public List<User> findAll() {
        // JdbcTemplate이 공통 로직 처리:
        // 1. Connection 열기
        // 2. PreparedStatement 생성
        // 3. ResultSet 처리
        // 4. Exception 처리
        // 5. Connection 닫기
        
        return jdbcTemplate.query(
            "SELECT * FROM users",
            (rs, rowNum) -> new User(  // 개발자는 이 부분만 구현
                rs.getLong("id"),
                rs.getString("name")
            )
        );
    }
}

RestTemplate

// RestTemplate도 템플릿 메서드 패턴
@Service
public class ApiService {
    private final RestTemplate restTemplate;
    
    public String callApi() {
        // RestTemplate이 공통 로직 처리:
        // 1. HTTP Connection 생성
        // 2. Request 전송
        // 3. Response 수신
        // 4. Exception 처리
        // 5. Connection 닫기
        
        return restTemplate.getForObject(
            "https://api.example.com/data",
            String.class
        );
    }
}

TransactionTemplate

// TransactionTemplate도 템플릿 메서드 패턴
@Service
public class OrderService {
    private final TransactionTemplate transactionTemplate;
    
    public void createOrder() {
        transactionTemplate.execute(status -> {
            // TransactionTemplate이 공통 로직 처리:
            // 1. Transaction 시작
            // 2. 비즈니스 로직 실행
            // 3. Commit/Rollback
            
            // 개발자는 비즈니스 로직만 작성
            saveOrder();
            updateStock();
            return null;
        });
    }
}

실무에서 언제 사용할까?

사용하면 좋은 경우:

여러 클래스가 비슷한 흐름을 가질 때
알고리즘의 일부만 다를 때
코드 중복이 많을 때
프레임워크 개발 시

사용하지 않아도 되는 경우:

알고리즘이 완전히 다를 때
상속을 피하고 싶을 때
유연한 구조가 필요할 때

핵심 원칙:

"알고리즘의 골격은 같고 일부만 다르다면 템플릿 메서드 패턴을 고려하라"

전략 패턴 vs 템플릿 메서드 패턴

구분	전략 패턴	템플릿 메서드 패턴
사용 방법	합성(Composition)	상속(Inheritance)
변경 범위	알고리즘 전체 교체	알고리즘 일부만 변경
유연성	높음 (런타임 변경)	낮음 (컴파일 시 결정)
클래스 수	많음	적음
사용 시점	알고리즘이 완전히 다를 때	알고리즘 구조는 같을 때

예시:

// 전략 패턴: 결제 방법 전체를 바꿈
service.setPaymentStrategy(new CardStrategy());  // 카드 결제
service.setPaymentStrategy(new CashStrategy());  // 현금 결제

// 템플릿 메서드: 음료 만드는 일부만 바꿈
Beverage coffee = new Coffee();  // 커피 우려내기
Beverage tea = new Tea();        // 차 우려내기
// 둘 다 "물 끓이기 → 우리기 → 따르기" 흐름은 동일

결론

템플릿 메서드 패턴은 알고리즘의 골격을 정의하고 일부만 변경할 수 있게 하는 패턴이다.

기억해야 할 포인트:

알고리즘의 골격을 정의한다
상속을 사용한다
코드 중복을 제거한다
Spring의 핵심 패턴 중 하나
전략 패턴보다 덜 유연하지만 간단하다

다음 글에서는 객체 간의 의존성을 느슨하게 만드는 옵저버 패턴을 알아볼 것이다.

다음 글 예고: 옵저버 패턴 - 객체의 상태 변화를 관찰하라

전략 패턴(Strategy Pattern)

김코딩딩 — Wed, 14 Jan 2026 10:57:21 +0900

디자인 패턴 시리즈의 아홉 번째 주제는 전략 패턴(Strategy Pattern)이다. 이번부터는 행위 패턴으로 넘어간다.

구조 패턴이 "객체들을 어떻게 조합할까?"였다면, 행위 패턴은 "객체들이 어떻게 협력하고 책임을 분담할까?"에 대한 해답이다.

예를 들어, 내비게이션 앱을 생각해보자. 목적지까지 가는 방법은 여러 가지다.

자동차로 갈 수도 있고
대중교통을 이용할 수도 있고
도보로 갈 수도 있다.

상황에 따라 최적의 경로 찾기 전략을 선택해야 한다. 전략 패턴은 이처럼 여러 알고리즘 중 하나를 상황에 맞게 선택할 수 있게 해주는 패턴이다.

이번 글에서는 전략 패턴이 무엇인지, 왜 필요한지, 어떻게 구현하는지 알아보자.

전략 패턴의 정의

전략 패턴(Strategy Pattern)은 알고리즘군을 정의하고 각각을 캡슐화하여, 이들을 상호 교환 가능하게 만드는 패턴이다.

전략 패턴을 사용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다.

핵심 특징:

알고리즘을 캡슐화한다
실행 중에 알고리즘을 선택할 수 있다
알고리즘 사용 코드와 분리된다
if-else 지옥을 제거한다

현실 비유:

내비게이션 경로 찾기 (자동차/대중교통/도보)
결제 수단 선택 (카드/현금/포인트)
압축 방식 선택 (ZIP/RAR/7Z)

왜 전략 패턴이 필요할까?

온라인 쇼핑몰에서 결제 시스템을 개발한다고 가정해보자.

// 문제가 있는 코드
public class PaymentService {
    public void processPayment(String paymentType, int amount) {
        if (paymentType.equals("CARD")) {
            System.out.println("신용카드로 " + amount + "원 결제");
            System.out.println("카드 승인 요청...");
            System.out.println("영수증 발행");
        } else if (paymentType.equals("CASH")) {
            System.out.println("현금으로 " + amount + "원 결제");
            System.out.println("현금 영수증 발행");
        } else if (paymentType.equals("POINT")) {
            System.out.println("포인트로 " + amount + "원 결제");
            System.out.println("포인트 차감");
            System.out.println("포인트 내역 저장");
        } else if (paymentType.equals("KAKAO")) {
            System.out.println("카카오페이로 " + amount + "원 결제");
            System.out.println("카카오 API 호출...");
            System.out.println("결제 승인");
        } else if (paymentType.equals("NAVER")) {
            System.out.println("네이버페이로 " + amount + "원 결제");
            System.out.println("네이버 API 호출...");
            System.out.println("결제 승인");
        }
        // 새로운 결제 수단이 추가될 때마다 if-else 추가...
    }
}

// 사용
public class Main {
    public static void main(String[] args) {
        PaymentService service = new PaymentService();
        service.processPayment("CARD", 10000);
        service.processPayment("KAKAO", 20000);
    }
}

문제점:

if-else 지옥: 결제 수단이 늘어날수록 코드가 길어짐
OCP 위반: 새로운 결제 수단 추가 시 기존 코드 수정 필요
SRP 위반: 하나의 클래스가 모든 결제 로직을 처리
테스트 어려움: 특정 결제 수단만 테스트하기 어려움
유지보수 악몽: 결제 로직 변경 시 전체 메서드 수정

전략 패턴은 "각 결제 방법을 독립적인 전략으로 분리하자"로 이 문제를 해결한다.

순수 Java로 구현하기

1단계: 전략 인터페이스 정의

// 결제 전략 인터페이스
public interface PaymentStrategy {
    void pay(int amount);
}

2단계: 구체적인 전략 구현

// 신용카드 결제 전략
public class CardPaymentStrategy implements PaymentStrategy {
    private String cardNumber;
    
    public CardPaymentStrategy(String cardNumber) {
        this.cardNumber = cardNumber;
    }
    
    @Override
    public void pay(int amount) {
        System.out.println("  신용카드로 " + amount + "원 결제");
        System.out.println("카드번호: " + cardNumber);
        System.out.println("카드 승인 완료\n");
    }
}

// 현금 결제 전략
public class CashPaymentStrategy implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("  현금으로 " + amount + "원 결제");
        System.out.println("현금 영수증 발행\n");
    }
}

// 포인트 결제 전략
public class PointPaymentStrategy implements PaymentStrategy {
    private String memberId;
    
    public PointPaymentStrategy(String memberId) {
        this.memberId = memberId;
    }
    
    @Override
    public void pay(int amount) {
        System.out.println("⭐ 포인트로 " + amount + "원 결제");
        System.out.println("회원ID: " + memberId);
        System.out.println("포인트 차감 완료\n");
    }
}

// 카카오페이 결제 전략
public class KakaoPayStrategy implements PaymentStrategy {
    private String kakaoId;
    
    public KakaoPayStrategy(String kakaoId) {
        this.kakaoId = kakaoId;
    }
    
    @Override
    public void pay(int amount) {
        System.out.println("  카카오페이로 " + amount + "원 결제");
        System.out.println("카카오ID: " + kakaoId);
        System.out.println("카카오 API 호출 완료\n");
    }
}

3단계: 컨텍스트 클래스 (전략 사용)

// 결제 처리 클래스 (컨텍스트)
public class PaymentService {
    private PaymentStrategy paymentStrategy;
    
    // 전략을 선택할 수 있음
    public void setPaymentStrategy(PaymentStrategy paymentStrategy) {
        this.paymentStrategy = paymentStrategy;
    }
    
    // 선택된 전략으로 결제 처리
    public void processPayment(int amount) {
        if (paymentStrategy == null) {
            throw new IllegalStateException("결제 수단을 선택해주세요");
        }
        paymentStrategy.pay(amount);
    }
}

4단계: 사용 예시

public class Main {
    public static void main(String[] args) {
        PaymentService paymentService = new PaymentService();
        
        // 신용카드로 결제
        System.out.println("=== 고객 1 ===");
        paymentService.setPaymentStrategy(new CardPaymentStrategy("1234-5678-9012"));
        paymentService.processPayment(15000);
        
        // 포인트로 결제
        System.out.println("=== 고객 2 ===");
        paymentService.setPaymentStrategy(new PointPaymentStrategy("user123"));
        paymentService.processPayment(5000);
        
        // 카카오페이로 결제
        System.out.println("=== 고객 3 ===");
        paymentService.setPaymentStrategy(new KakaoPayStrategy("kakao_user"));
        paymentService.processPayment(25000);
        
        // 런타임에 전략 변경 가능
        System.out.println("=== 고객 3 결제 수단 변경 ===");
        paymentService.setPaymentStrategy(new CashPaymentStrategy());
        paymentService.processPayment(10000);
    }
}

장점:

if-else 제거됨
새로운 결제 수단 추가 시 기존 코드 수정 불필요
각 전략을 독립적으로 테스트 가능
런타임에 전략 변경 가능

실전 예제: 할인 정책

// 할인 전략 인터페이스
public interface DiscountStrategy {
    int calculateDiscount(int price);
}

// 정액 할인
public class FixedDiscountStrategy implements DiscountStrategy {
    private int discountAmount;
    
    public FixedDiscountStrategy(int discountAmount) {
        this.discountAmount = discountAmount;
    }
    
    @Override
    public int calculateDiscount(int price) {
        return Math.max(0, price - discountAmount);
    }
}

// 정률 할인
public class PercentDiscountStrategy implements DiscountStrategy {
    private int discountPercent;
    
    public PercentDiscountStrategy(int discountPercent) {
        this.discountPercent = discountPercent;
    }
    
    @Override
    public int calculateDiscount(int price) {
        return price * (100 - discountPercent) / 100;
    }
}

// 할인 없음
public class NoDiscountStrategy implements DiscountStrategy {
    @Override
    public int calculateDiscount(int price) {
        return price;
    }
}

// VIP 할인 (정률 + 추가 할인)
public class VIPDiscountStrategy implements DiscountStrategy {
    @Override
    public int calculateDiscount(int price) {
        int percentDiscount = price * 80 / 100;  // 20% 할인
        return Math.max(0, percentDiscount - 5000);  // 추가 5000원 할인
    }
}

// 주문 처리
public class Order {
    private int price;
    private DiscountStrategy discountStrategy;
    
    public Order(int price) {
        this.price = price;
        this.discountStrategy = new NoDiscountStrategy();  // 기본값
    }
    
    public void setDiscountStrategy(DiscountStrategy discountStrategy) {
        this.discountStrategy = discountStrategy;
    }
    
    public int calculateFinalPrice() {
        return discountStrategy.calculateDiscount(price);
    }
    
    public void printOrder() {
        System.out.println("원가: " + price + "원");
        System.out.println("최종가: " + calculateFinalPrice() + "원\n");
    }
}

// 사용
public class Main {
    public static void main(String[] args) {
        // 일반 고객
        Order order1 = new Order(50000);
        order1.setDiscountStrategy(new NoDiscountStrategy());
        System.out.println("=== 일반 고객 ===");
        order1.printOrder();
        
        // 신규 고객 (10% 할인)
        Order order2 = new Order(50000);
        order2.setDiscountStrategy(new PercentDiscountStrategy(10));
        System.out.println("=== 신규 고객 (10% 할인) ===");
        order2.printOrder();
        
        // 프로모션 (5000원 할인)
        Order order3 = new Order(50000);
        order3.setDiscountStrategy(new FixedDiscountStrategy(5000));
        System.out.println("=== 프로모션 (5000원 할인) ===");
        order3.printOrder();
        
        // VIP 고객
        Order order4 = new Order(50000);
        order4.setDiscountStrategy(new VIPDiscountStrategy());
        System.out.println("=== VIP 고객 ===");
        order4.printOrder();
    }
}

전략 패턴의 장점

OCP 준수: 새로운 전략 추가 시 기존 코드 수정 불필요
SRP 준수: 각 전략이 독립적인 책임
if-else 제거: 깔끔한 코드
테스트 용이: 각 전략을 독립적으로 테스트
유연성: 런타임에 전략 변경 가능
재사용성: 전략을 여러 곳에서 재사용

전략 패턴의 단점

클래스 증가: 전략마다 클래스 생성 필요
클라이언트 인지: 클라이언트가 전략의 차이를 알아야 함
컨텍스트 복잡도: 전략이 많아지면 선택 로직이 복잡해질 수 있음

Spring에서의 전략 패턴

Spring에서 전략 패턴은 매우 자주 사용된다.

// 결제 전략 인터페이스
public interface PaymentStrategy {
    boolean pay(int amount);
    String getPaymentType();
}

// 구체적인 전략들
@Component
public class CardPaymentStrategy implements PaymentStrategy {
    @Override
    public boolean pay(int amount) {
        System.out.println("카드 결제: " + amount);
        return true;
    }
    
    @Override
    public String getPaymentType() {
        return "CARD";
    }
}

@Component
public class KakaoPayStrategy implements PaymentStrategy {
    @Override
    public boolean pay(int amount) {
        System.out.println("카카오페이 결제: " + amount);
        return true;
    }
    
    @Override
    public String getPaymentType() {
        return "KAKAO";
    }
}

// 전략 팩토리 (전략 선택)
@Component
public class PaymentStrategyFactory {
    private final Map<String, PaymentStrategy> strategies;
    
    // Spring이 모든 PaymentStrategy 구현체를 주입
    public PaymentStrategyFactory(List<PaymentStrategy> strategyList) {
        this.strategies = strategyList.stream()
            .collect(Collectors.toMap(
                PaymentStrategy::getPaymentType,
                strategy -> strategy
            ));
    }
    
    public PaymentStrategy getStrategy(String paymentType) {
        PaymentStrategy strategy = strategies.get(paymentType);
        if (strategy == null) {
            throw new IllegalArgumentException("지원하지 않는 결제 수단: " + paymentType);
        }
        return strategy;
    }
}

// 서비스에서 사용
@Service
public class OrderService {
    private final PaymentStrategyFactory strategyFactory;
    
    public OrderService(PaymentStrategyFactory strategyFactory) {
        this.strategyFactory = strategyFactory;
    }
    
    public void processOrder(String paymentType, int amount) {
        PaymentStrategy strategy = strategyFactory.getStrategy(paymentType);
        boolean success = strategy.pay(amount);
        
        if (success) {
            System.out.println("주문 완료!");
        }
    }
}

실무에서 언제 사용할까?

사용하면 좋은 경우:

같은 목적의 여러 알고리즘이 있을 때
if-else나 switch-case가 많을 때
런타임에 알고리즘을 선택해야 할 때
알고리즘이 자주 변경되거나 추가될 때

사용하지 않아도 되는 경우:

알고리즘이 하나뿐일 때
알고리즘이 거의 변하지 않을 때
간단한 if-else로 충분할 때

핵심 원칙:

"여러 알고리즘 중 하나를 선택해야 한다면 전략 패턴을 고려하라"

전략 패턴 vs 팩토리 메서드 패턴

둘 다 런타임에 선택한다는 공통점이 있지만, 목적이 다르다.

구분	전략 패턴	팩토리 메서드 패턴
패턴 분류	행위 패턴	생성 패턴
목적	알고리즘(행동) 실행 방법을 선택	객체 생성 방법을 선택
초점	“어떻게 할까?”	“무엇을 만들까?”
변경 가능성	언제든지 전략(알고리즘) 교체 가능	생성 후에는 객체 타입이 고정
사용 시점	알고리즘 선택이 중요할 때	객체 생성이 복잡할 때
핵심 역할	여러 알고리즘을 캡슐화하여 교체 가능	객체 생성을 서브클래스에 위임

코드로 비교

팩토리 메서드 패턴:

// 목적: 어떤 결제 객체를 생성할까?
public class PaymentFactory {
    public Payment createPayment(String type) {
        if (type.equals("CARD")) {
            return new CardPayment();  // 객체 생성
        } else if (type.equals("KAKAO")) {
            return new KakaoPayment();  // 객체 생성
        }
        return null;
    }
}

// 사용
Payment payment = factory.createPayment("CARD");
payment.pay(10000);
// payment는 한 번 생성되면 타입 변경 불가

전략 패턴:

// 목적: 어떤 결제 방식으로 처리할까?
public class PaymentService {
    private PaymentStrategy strategy;
    
    public void setStrategy(PaymentStrategy strategy) {
        this.strategy = strategy;  // 전략 교체
    }
    
    public void pay(int amount) {
        strategy.pay(amount);  // 전략 실행
    }
}

// 사용
PaymentService service = new PaymentService();
service.setStrategy(new CardStrategy());
service.pay(10000);

// 같은 객체로 전략 변경 가능
service.setStrategy(new KakaoStrategy());
service.pay(20000);

실무에서는 함께 사용

두 패턴을 조합하면 더욱 강력하다.

// 팩토리로 전략 객체를 생성
@Component
public class PaymentStrategyFactory {
    public PaymentStrategy createStrategy(String type) {
        // 팩토리 메서드로 전략 생성
        switch (type) {
            case "CARD": return new CardPaymentStrategy();
            case "KAKAO": return new KakaoPaymentStrategy();
            case "POINT": return new PointPaymentStrategy();
            default: throw new IllegalArgumentException("Unknown type");
        }
    }
}

// 서비스에서 사용
@Service
public class OrderService {
    private final PaymentStrategyFactory factory;
    private final PaymentService paymentService;
    
    public void checkout(String paymentType, int amount) {
        // 1. 팩토리로 전략 생성
        PaymentStrategy strategy = factory.createStrategy(paymentType);
        
        // 2. 전략 패턴으로 실행
        paymentService.setStrategy(strategy);
        paymentService.process(amount);
    }
}

핵심:

팩토리: 객체를 어떻게 만들까?
전략: 알고리즘을 어떻게 실행할까?

결론

전략 패턴은 알고리즘을 캡슐화하여 유연하게 교체할 수 있게 하는 패턴이다.

기억해야 할 포인트:

알고리즘을 캡슐화한다
if-else 지옥을 제거한다
런타임에 전략 변경 가능
Spring에서 매우 자주 사용된다
새로운 전략 추가가 쉽다

다음 글에서는 알고리즘의 골격을 정의하는 템플릿 메서드 패턴을 알아볼 것이다.

다음 글 예고: 템플릿 메서드 패턴 - 알고리즘의 뼈대를 정의하라

프록시 패턴(Proxy Pattern)

김코딩딩 — Tue, 13 Jan 2026 22:54:17 +0900

디자인 패턴 시리즈의 여덟 번째 주제는 프록시 패턴(Proxy Pattern)이다.

데코레이터 패턴이 "기능을 추가"하는 거였다면, 프록시 패턴은 "접근을 제어"하는 것이다.

예를 들어, 회사에 중요한 서버가 있다고 생각해보자. 모든 사람이 직접 서버에 접근하면 위험하다. 그래서 보안 담당자가 중간에서 신원을 확인하고, 권한이 있는 사람만 서버에 접근하게 한다.

프록시 패턴은 이처럼 실제 객체 앞에 "대리인(Proxy)"을 두어 접근을 제어하는 패턴이다.

이번 글에서는 프록시 패턴이 무엇인지, 왜 필요한지, 어떻게 구현하는지 알아보자.

프록시 패턴의 정의

프록시 패턴(Proxy Pattern)은 다른 객체에 대한 접근을 제어하기 위해 대리자(Proxy)를 제공하는 패턴이다.

실제 객체를 직접 호출하는 대신, 프록시를 통해 간접적으로 호출한다.

핵심 특징:

실제 객체 앞에 대리인을 둔다
실제 객체와 동일한 인터페이스를 제공한다
접근을 제어하거나 추가 작업을 수행한다
클라이언트는 프록시인지 구분하지 못한다

현실 비유:

연예인의 매니저 (팬이 연예인에게 직접 접근 못함)
부동산 중개인 (집주인과 구매자 사이)
VPN (실제 서버와 사용자 사이)

왜 프록시 패턴이 필요할까?

스프링 부트 애플리케이션을 개발한다고 가정해보자. 여러 서비스 클래스가 있고, 각각 데이터베이스 연결이 필요하다.

// 데이터베이스 연결 클래스
public class DatabaseConnection {
    private String host;
    private int port;
    
    public DatabaseConnection(String host, int port) {
        this.host = host;
        this.port = port;
        connect();  // 생성 즉시 연결
    }
    
    private void connect() {
        System.out.println("  " + host + ":" + port + " DB 연결 중...");
        try {
            Thread.sleep(2000);  // 연결 시간 시뮬레이션
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("✅ DB 연결 완료!");
    }
    
    public String query(String sql) {
        System.out.println("  쿼리 실행: " + sql);
        return "결과 데이터";
    }
}

// 사용자 서비스
public class UserService {
    private DatabaseConnection connection;
    
    public UserService() {
        connection = new DatabaseConnection("localhost", 5432);
    }
    
    public String getUser(Long id) {
        return connection.query("SELECT * FROM users WHERE id = " + id);
    }
}

// 상품 서비스
public class ProductService {
    private DatabaseConnection connection;
    
    public ProductService() {
        connection = new DatabaseConnection("localhost", 5432);
    }
    
    public String getProduct(Long id) {
        return connection.query("SELECT * FROM products WHERE id = " + id);
    }
}

// 주문 서비스
public class OrderService {
    private DatabaseConnection connection;
    
    public OrderService() {
        connection = new DatabaseConnection("localhost", 5432);
    }
    
    public String getOrder(Long id) {
        return connection.query("SELECT * FROM orders WHERE id = " + id);
    }
}

// 애플리케이션 시작
public class Application {
    public static void main(String[] args) {
        System.out.println("  애플리케이션 시작\n");
        
        // 모든 서비스 초기화
        UserService userService = new UserService();
        ProductService productService = new ProductService();
        OrderService orderService = new OrderService();
        
        System.out.println("\n✨ 애플리케이션 준비 완료\n");
        
        // 실제로는 UserService만 사용
        System.out.println("--- 사용자 조회 ---");
        userService.getUser(1L);
    }
}

문제점:

앱 시작하는 데 6초나 걸림 (DB 연결 3개 * 2초)
ProductService, OrderService는 사용하지 않는데도 DB 연결됨
DB 커넥션 풀 리소스 낭비
서비스가 100개라면? 200초 대기...

프록시 패턴은 "실제로 필요할 때만 연결하자 (Lazy Loading)"로 이 문제를 해결한다.

순수 Java로 구현하기

1단계: 공통 인터페이스 정의

public interface Image {
    void display();
}

2단계: 실제 객체 (Real Subject)

public class RealImage implements Image {
    private String fileName;
    
    public RealImage(String fileName) {
        this.fileName = fileName;
        loadFromDisk();
    }
    
    private void loadFromDisk() {
        System.out.println(fileName + " 디스크에서 로딩 중...");
        try {
            Thread.sleep(2000);  // 로딩 시뮬레이션
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(fileName + " 로딩 완료!");
    }
    
    @Override
    public void display() {
        System.out.println(fileName + " 화면에 표시\n");
    }
}

3단계: 프록시 객체

public class ImageProxy implements Image {
    private String fileName;
    private RealImage realImage;  // 실제 객체 (처음엔 null)
    
    public ImageProxy(String fileName) {
        this.fileName = fileName;
        // 실제 이미지는 생성하지 않음!
    }
    
    @Override
    public void display() {
        // 실제로 필요할 때만 로딩 (Lazy Loading)
        if (realImage == null) {
            realImage = new RealImage(fileName);
        }
        realImage.display();
    }
}

4단계: 사용 예시

public class Main {
    public static void main(String[] args) {
        System.out.println("=== 프록시 사용 ===");
        System.out.println("앱 시작");
        
        // 프록시 객체 생성 (즉시 로딩 안 함)
        Image image1 = new ImageProxy("사진1.jpg");
        Image image2 = new ImageProxy("사진2.jpg");
        Image image3 = new ImageProxy("사진3.jpg");
        
        System.out.println("앱 준비 완료 (즉시!)\n");
        
        // 실제로 사용할 때만 로딩
        System.out.println("--- 사진1 보기 ---");
        image1.display();
        
        System.out.println("--- 사진1 다시 보기 ---");
        image1.display();  // 이미 로딩됨, 즉시 표시
        
        System.out.println("--- 사진3 보기 ---");
        image3.display();
        
        // 사진2는 끝까지 로딩 안 됨!
    }
}

장점:

앱이 즉시 시작됨
필요한 이미지만 로딩됨
한 번 로딩한 이미지는 재사용

프록시 패턴의 종류

1. 가상 프록시 (Virtual Proxy)

위 예시처럼 무거운 객체의 생성을 지연시킨다.

// 비용이 큰 객체
public class ExpensiveObject implements Service {
    public ExpensiveObject() {
        System.out.println("무거운 객체 생성 중... (시간 소요)");
        // 복잡한 초기화 작업
    }
    
    @Override
    public void process() {
        System.out.println("작업 처리");
    }
}

// 가상 프록시
public class VirtualProxy implements Service {
    private ExpensiveObject expensiveObject;
    
    @Override
    public void process() {
        if (expensiveObject == null) {
            expensiveObject = new ExpensiveObject();  // 처음 사용 시 생성
        }
        expensiveObject.process();
    }
}

2. 보호 프록시 (Protection Proxy)

접근 권한을 제어한다.

// 문서 인터페이스
public interface Document {
    void read();
    void write(String content);
}

// 실제 문서
public class SecretDocument implements Document {
    private String content = "극비 문서 내용";
    
    @Override
    public void read() {
        System.out.println("문서 읽기: " + content);
    }
    
    @Override
    public void write(String content) {
        this.content = content;
        System.out.println("문서 수정 완료");
    }
}

// 보호 프록시
public class DocumentProxy implements Document {
    private SecretDocument document;
    private String userRole;
    
    public DocumentProxy(String userRole) {
        this.userRole = userRole;
        this.document = new SecretDocument();
    }
    
    @Override
    public void read() {
        // 모든 사용자가 읽기 가능
        document.read();
    }
    
    @Override
    public void write(String content) {
        // 관리자만 쓰기 가능
        if (userRole.equals("ADMIN")) {
            document.write(content);
        } else {
            System.out.println("❌ 권한 없음: 관리자만 수정 가능합니다");
        }
    }
}

// 사용
public class Main {
    public static void main(String[] args) {
        // 일반 사용자
        Document userDoc = new DocumentProxy("USER");
        userDoc.read();
        userDoc.write("변경 시도");
        
        System.out.println();
        
        // 관리자
        Document adminDoc = new DocumentProxy("ADMIN");
        adminDoc.read();
        adminDoc.write("관리자가 수정한 내용");
    }
}

3. 원격 프록시 (Remote Proxy)

다른 서버에 있는 객체를 로컬처럼 사용한다.

// 서비스 인터페이스
public interface PaymentService {
    boolean pay(int amount);
}

// 실제 원격 서비스 (다른 서버에 있다고 가정)
public class RemotePaymentService implements PaymentService {
    @Override
    public boolean pay(int amount) {
        System.out.println("원격 서버에서 " + amount + "원 결제 처리");
        return true;
    }
}

// 원격 프록시
public class PaymentServiceProxy implements PaymentService {
    private RemotePaymentService remoteService;
    
    @Override
    public boolean pay(int amount) {
        System.out.println("네트워크 연결 중...");
        
        if (remoteService == null) {
            remoteService = new RemotePaymentService();
        }
        
        // 원격 호출
        boolean result = remoteService.pay(amount);
        
        System.out.println("연결 종료");
        return result;
    }
}

4. 캐싱 프록시 (Caching Proxy)

결과를 캐싱하여 성능을 개선한다.

// 데이터베이스 서비스
public interface Database {
    String query(String sql);
}

// 실제 데이터베이스
public class RealDatabase implements Database {
    @Override
    public String query(String sql) {
        System.out.println("  DB 쿼리 실행: " + sql + " (느림)");
        try {
            Thread.sleep(1000);  // DB 조회 시간
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "결과 데이터";
    }
}

// 캐싱 프록시
public class CachingDatabaseProxy implements Database {
    private RealDatabase database;
    private Map<String, String> cache;
    
    public CachingDatabaseProxy() {
        this.database = new RealDatabase();
        this.cache = new HashMap<>();
    }
    
    @Override
    public String query(String sql) {
        // 캐시에 있으면 즉시 반환
        if (cache.containsKey(sql)) {
            System.out.println("✨ 캐시에서 반환: " + sql + " (빠름)");
            return cache.get(sql);
        }
        
        // 없으면 DB 조회 후 캐싱
        String result = database.query(sql);
        cache.put(sql, result);
        return result;
    }
}

// 사용
public class Main {
    public static void main(String[] args) {
        Database db = new CachingDatabaseProxy();
        
        System.out.println("첫 번째 조회:");
        db.query("SELECT * FROM users");
        
        System.out.println("\n두 번째 조회 (같은 쿼리):");
        db.query("SELECT * FROM users");
        
        System.out.println("\n세 번째 조회 (다른 쿼리):");
        db.query("SELECT * FROM products");
    }
}

실전 예제: 로깅 프록시

// 사용자 서비스 인터페이스
public interface UserService {
    void createUser(String name);
    void deleteUser(String name);
}

// 실제 사용자 서비스
public class UserServiceImpl implements UserService {
    @Override
    public void createUser(String name) {
        System.out.println("✅ 사용자 생성: " + name);
    }
    
    @Override
    public void deleteUser(String name) {
        System.out.println(" ️ 사용자 삭제: " + name);
    }
}

// 로깅 프록시
public class LoggingUserServiceProxy implements UserService {
    private UserService userService;
    
    public LoggingUserServiceProxy(UserService userService) {
        this.userService = userService;
    }
    
    @Override
    public void createUser(String name) {
        System.out.println("  [로그] createUser 호출됨");
        long startTime = System.currentTimeMillis();
        
        userService.createUser(name);
        
        long endTime = System.currentTimeMillis();
        System.out.println("⏱️ [로그] 실행 시간: " + (endTime - startTime) + "ms\n");
    }
    
    @Override
    public void deleteUser(String name) {
        System.out.println("  [로그] deleteUser 호출됨");
        long startTime = System.currentTimeMillis();
        
        userService.deleteUser(name);
        
        long endTime = System.currentTimeMillis();
        System.out.println("⏱️ [로그] 실행 시간: " + (endTime - startTime) + "ms\n");
    }
}

// 사용
public class Main {
    public static void main(String[] args) {
        UserService userService = new UserServiceImpl();
        UserService proxy = new LoggingUserServiceProxy(userService);
        
        proxy.createUser("김도균");
        proxy.deleteUser("이철수");
    }
}

프록시 패턴의 장점

개방-폐쇄 원칙: 실제 객체를 수정하지 않고 제어 로직 추가
단일 책임 원칙: 접근 제어를 별도 클래스로 분리
성능 향상: Lazy Loading, 캐싱으로 성능 개선
보안: 접근 권한 제어
로깅/모니터링: 추가 작업 수행 가능

프록시 패턴의 단점

복잡도 증가: 새로운 클래스가 추가됨
응답 지연: 프록시를 거치면서 약간의 지연 발생
코드 복잡: 프록시 체인이 길어질 수 있음

Spring에서의 프록시 패턴

Spring에서 프록시 패턴이 가장 많이 사용되는 곳은 바로 JPA다.

JPA의 지연 로딩 (Lazy Loading)

// 엔티티
@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    private String name;
    
    // 지연 로딩 설정
    @OneToMany(mappedBy = "user", fetch = FetchType.LAZY)
    private List<Order> orders;  // 프록시 객체!
}

@Entity
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    private String productName;
    private int price;
    
    @ManyToOne
    @JoinColumn(name = "user_id")
    private User user;
}

// 서비스
@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;
    
    public void printUser(Long userId) {
        // User 조회 시 orders는 프록시 객체로 들어옴
        User user = userRepository.findById(userId).orElseThrow();
        
        System.out.println("사용자: " + user.getName());
        // 여기까지는 orders 테이블 조회 안 함!
        
        // 실제로 사용할 때 쿼리 실행
        System.out.println("주문 개수: " + user.getOrders().size());
        // 이 시점에 SELECT * FROM orders WHERE user_id = ? 실행
    }
}

실행 로그:

-- User 조회
SELECT * FROM user WHERE id = 1

-- user.getName() 호출 (orders는 아직 조회 안 함)

-- user.getOrders().size() 호출 시점에 쿼리 실행
SELECT * FROM orders WHERE user_id = 1

장점:

User만 필요하면 Order 조회 안 함 (성능 향상)
필요할 때만 쿼리 실행 (Lazy Loading)

즉시 로딩 vs 지연 로딩

@Entity
public class User {
    @Id
    private Long id;
    private String name;
    
    // 즉시 로딩 - User 조회 시 Order도 함께 조회
    @OneToMany(fetch = FetchType.EAGER)
    private List<Order> orders;
}

@Entity
public class User {
    @Id
    private Long id;
    private String name;
    
    // 지연 로딩 - 프록시 패턴 사용!
    @OneToMany(fetch = FetchType.LAZY)  
    private List<Order> orders;  // HibernateProxy 객체
}

// 테스트
@SpringBootTest
public class LazyLoadingTest {
    @Autowired
    private UserRepository userRepository;
    
    @Test
    void lazyLoadingTest() {
        User user = userRepository.findById(1L).orElseThrow();
        
        // orders는 실제 List가 아닌 프록시 객체
        System.out.println(user.getOrders().getClass());
        // 출력: class org.hibernate.collection.internal.PersistentBag
        
        // 실제로 사용할 때 쿼리 실행
        for (Order order : user.getOrders()) {
            System.out.println(order.getProductName());
        }
    }
}

N+1 문제와 프록시

// N+1 문제가 발생하는 코드
@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;
    
    public void printAllUsersOrders() {
        // 1. User 전체 조회 (1번 쿼리)
        List<User> users = userRepository.findAll();
        
        // 2. 각 User마다 orders 조회 (N번 쿼리)
        for (User user : users) {
            System.out.println(user.getName());
            System.out.println("주문 개수: " + user.getOrders().size());
            // User가 100명이면 100번의 추가 쿼리 발생!
        }
    }
}

해결책: Fetch Join, @EntityGraph, batch size 조절하기

// Repository
public interface UserRepository extends JpaRepository<User, Long> {
    // Fetch Join으로 한 번에 조회
    @Query("SELECT u FROM User u JOIN FETCH u.orders")
    List<User> findAllWithOrders();
}

Spring의 프록시 종류

1. JDK Dynamic Proxy (인터페이스 기반)

public interface UserService {
    void createUser(String name);
}

@Service
public class UserServiceImpl implements UserService {
    @Override
    public void createUser(String name) {
        System.out.println("사용자 생성: " + name);
    }
}

// Spring이 JDK Dynamic Proxy 생성
// UserService(인터페이스) → Proxy → UserServiceImpl

2. CGLIB Proxy (클래스 기반)

@Service
public class ProductService {  // 인터페이스 없이 바로 클래스
    public void createProduct(String name) {
        System.out.println("상품 생성: " + name);
    }
}

// Spring이 CGLIB Proxy 생성
// ProductService → CGLIBProxy → 실제 ProductService

// 프록시 확인
@SpringBootTest
public class ProxyTest {
    @Autowired
    private UserRepository userRepository;
    
    @Test
    void checkProxy() {
        User user = userRepository.findById(1L).orElseThrow();
        
        // orders는 프록시 객체
        System.out.println("Orders 타입: " + user.getOrders().getClass());
        // 출력: class org.hibernate.collection.internal.PersistentBag
        
        // 프록시 여부 확인
        System.out.println("프록시인가? " + 
            Hibernate.isInitialized(user.getOrders()));  // false
        
        // 사용 후
        user.getOrders().size();
        System.out.println("프록시인가? " + 
            Hibernate.isInitialized(user.getOrders()));  // true
    }
}

실무에서 언제 사용할까?

사용하면 좋은 경우:

무거운 객체의 생성을 지연시킬 때
접근 권한을 제어해야 할 때
원격 객체를 로컬처럼 사용할 때
캐싱이 필요할 때
로깅, 모니터링이 필요할 때

사용하지 않아도 되는 경우:

객체가 가벼울 때
추가 제어가 필요 없을 때
성능이 중요하고 오버헤드를 피해야 할 때

핵심 원칙:

"객체 접근을 제어하거나 추가 작업이 필요하다면 프록시 패턴을 고려하라"

데코레이터 vs 프록시

구분	데코레이터	프록시
목적	기능 추가	접근 제어
생성 시점	클라이언트가 조합	프록시가 생성 관리
개수	여러 개 조합 가능	보통 하나
초점	무엇을 할까?	언제 할까?

예시:

데코레이터: 커피에 토핑 추가 (기능 추가)
프록시: 이미지 필요할 때만 로딩 (접근 제어)

결론

프록시 패턴은 실제 객체에 대한 접근을 제어하는 패턴이다.

기억해야 할 포인트:

실제 객체 앞에 대리인을 둔다
Lazy Loading으로 성능 개선
접근 제어로 보안 강화
캐싱으로 효율성 향상
Spring AOP의 핵심 기술
데코레이터와 비슷하지만 목적이 다르다

다음 글에서는 알고리즘을 캡슐화하는 전략 패턴을 알아볼 것이다.

다음 글 예고: 전략 패턴 - 알고리즘을 캡슐화하라

데코레이터 패턴(Decorator Pattern)

김코딩딩 — Tue, 13 Jan 2026 21:52:38 +0900

디자인 패턴 시리즈의 일곱 번째 주제는 데코레이터 패턴(Decorator Pattern)이다.

어댑터 패턴이 "인터페이스를 변환"하는 거였다면, 데코레이터 패턴은 "기능을 추가"하는 것이다.

예를 들어, 커피숍에서 아메리카노를 주문한다고 생각해보자. 기본 아메리카노에 샷 추가, 휘핑크림 추가, 시럽 추가... 이렇게 옵션을 덧붙이면 가격도 올라가고 기능도 추가된다. 데코레이터 패턴은 이처럼 객체에 기능을 장식(Decorate)하듯이 추가하는 패턴이다.

이번 글에서는 데코레이터 패턴이 무엇인지, 왜 필요한지, 어떻게 구현하는지 알아보자.

데코레이터 패턴의 정의

데코레이터 패턴(Decorator Pattern)은 객체에 추가적인 기능을 동적으로 첨가하는 패턴이다.

기존 코드를 수정하지 않고, 객체를 감싸서 새로운 기능을 추가할 수 있다.

핵심 특징:

객체에 동적으로 기능을 추가한다
기존 코드를 수정하지 않는다
기능을 조합할 수 있다
래퍼(Wrapper)처럼 객체를 감싼다

현실 비유:

커피에 토핑 추가하기
피자에 토핑 추가하기
선물 포장하기

왜 데코레이터 패턴이 필요할까?

커피숍 주문 시스템을 개발한다고 가정해보자.

방법 1: 상속 사용 (문제가 많음)

// 기본 커피
public class Coffee {
    public int getCost() {
        return 3000;
    }
    
    public String getDescription() {
        return "아메리카노";
    }
}

// 샷 추가 커피
public class CoffeeWithShot extends Coffee {
    @Override
    public int getCost() {
        return 3000 + 500;
    }
    
    @Override
    public String getDescription() {
        return "아메리카노 + 샷";
    }
}

// 휘핑 추가 커피
public class CoffeeWithWhip extends Coffee {
    @Override
    public int getCost() {
        return 3000 + 700;
    }
    
    @Override
    public String getDescription() {
        return "아메리카노 + 휘핑";
    }
}

// 샷 + 휘핑 추가 커피
public class CoffeeWithShotAndWhip extends Coffee {
    @Override
    public int getCost() {
        return 3000 + 500 + 700;
    }
    
    @Override
    public String getDescription() {
        return "아메리카노 + 샷 + 휘핑";
    }
}

// 샷 + 시럽 추가 커피...
// 휘핑 + 시럽 추가 커피...
// 샷 + 휘핑 + 시럽 추가 커피...
// 끝이 없다!!!

문제점:

조합이 늘어날수록 클래스가 폭발적으로 증가 (클래스 폭발)
동적으로 기능을 추가/제거할 수 없음
코드 중복이 심함
유지보수가 불가능

데코레이터 패턴은 "객체를 감싸서 기능을 추가하자"로 이 문제를 해결한다.

순수 Java로 구현하기

1단계: 컴포넌트 인터페이스 정의

// 커피 인터페이스
public interface Coffee {
    int getCost();
    String getDescription();
}

2단계: 구체적인 컴포넌트 (기본 커피)

// 기본 아메리카노
public class Americano implements Coffee {
    @Override
    public int getCost() {
        return 3000;
    }
    
    @Override
    public String getDescription() {
        return "아메리카노";
    }
}

// 기본 라떼
public class Latte implements Coffee {
    @Override
    public int getCost() {
        return 4000;
    }
    
    @Override
    public String getDescription() {
        return "라떼";
    }
}

3단계: 데코레이터 추상 클래스

// 추가 옵션의 기본 클래스
public abstract class CoffeeDecorator implements Coffee {
    protected Coffee coffee;  // 감쌀 객체
    
    public CoffeeDecorator(Coffee coffee) {
        this.coffee = coffee;
    }
    
    @Override
    public int getCost() {
        return coffee.getCost();
    }
    
    @Override
    public String getDescription() {
        return coffee.getDescription();
    }
}

4단계: 구체적인 데코레이터들

// 샷 추가
public class ShotDecorator extends CoffeeDecorator {
    public ShotDecorator(Coffee coffee) {
        super(coffee);
    }
    
    @Override
    public int getCost() {
        return coffee.getCost() + 500;  // 기존 가격 + 샷 가격
    }
    
    @Override
    public String getDescription() {
        return coffee.getDescription() + " + 샷";
    }
}

// 휘핑크림 추가
public class WhipDecorator extends CoffeeDecorator {
    public WhipDecorator(Coffee coffee) {
        super(coffee);
    }
    
    @Override
    public int getCost() {
        return coffee.getCost() + 700;
    }
    
    @Override
    public String getDescription() {
        return coffee.getDescription() + " + 휘핑";
    }
}

// 시럽 추가
public class SyrupDecorator extends CoffeeDecorator {
    public SyrupDecorator(Coffee coffee) {
        super(coffee);
    }
    
    @Override
    public int getCost() {
        return coffee.getCost() + 300;
    }
    
    @Override
    public String getDescription() {
        return coffee.getDescription() + " + 시럽";
    }
}

// 우유 추가
public class MilkDecorator extends CoffeeDecorator {
    public MilkDecorator(Coffee coffee) {
        super(coffee);
    }
    
    @Override
    public int getCost() {
        return coffee.getCost() + 500;
    }
    
    @Override
    public String getDescription() {
        return coffee.getDescription() + " + 우유";
    }
}

5단계: 사용 예시

public class Main {
    public static void main(String[] args) {
        // 기본 아메리카노
        Coffee coffee1 = new Americano();
        System.out.println(coffee1.getDescription() + " = " + coffee1.getCost() + "원");
        
        // 아메리카노 + 샷
        Coffee coffee2 = new ShotDecorator(new Americano());
        System.out.println(coffee2.getDescription() + " = " + coffee2.getCost() + "원");
        
        // 아메리카노 + 샷 + 휘핑
        Coffee coffee3 = new WhipDecorator(new ShotDecorator(new Americano()));
        System.out.println(coffee3.getDescription() + " = " + coffee3.getCost() + "원");
        
        // 라떼 + 샷 + 시럽 + 휘핑
        Coffee coffee4 = new Latte();
        coffee4 = new ShotDecorator(coffee4);
        coffee4 = new SyrupDecorator(coffee4);
        coffee4 = new WhipDecorator(coffee4);
        System.out.println(coffee4.getDescription() + " = " + coffee4.getCost() + "원");
        
        // 아메리카노 + 샷 2번 + 우유
        Coffee coffee5 = new Americano();
        coffee5 = new ShotDecorator(coffee5);
        coffee5 = new ShotDecorator(coffee5);  // 샷을 2번 추가!
        coffee5 = new MilkDecorator(coffee5);
        System.out.println(coffee5.getDescription() + " = " + coffee5.getCost() + "원");
    }
}

장점:

새로운 조합을 만들 때 클래스를 추가할 필요 없음
동적으로 기능을 추가/제거 가능
같은 데코레이터를 여러 번 적용 가능 (샷 2번)
단일 책임 원칙 준수

실전 예제: 텍스트 에디터

더 실무적인 예시를 보자.

// 텍스트 인터페이스
public interface Text {
    String getContent();
}

// 기본 텍스트
public class PlainText implements Text {
    private String content;
    
    public PlainText(String content) {
        this.content = content;
    }
    
    @Override
    public String getContent() {
        return content;
    }
}

// 텍스트 데코레이터
public abstract class TextDecorator implements Text {
    protected Text text;
    
    public TextDecorator(Text text) {
        this.text = text;
    }
    
    @Override
    public String getContent() {
        return text.getContent();
    }
}

// 볼드 데코레이터
public class BoldDecorator extends TextDecorator {
    public BoldDecorator(Text text) {
        super(text);
    }
    
    @Override
    public String getContent() {
        return "<b>" + text.getContent() + "</b>";
    }
}

// 이탤릭 데코레이터
public class ItalicDecorator extends TextDecorator {
    public ItalicDecorator(Text text) {
        super(text);
    }
    
    @Override
    public String getContent() {
        return "<i>" + text.getContent() + "</i>";
    }
}

// 밑줄 데코레이터
public class UnderlineDecorator extends TextDecorator {
    public UnderlineDecorator(Text text) {
        super(text);
    }
    
    @Override
    public String getContent() {
        return "<u>" + text.getContent() + "</u>";
    }
}

// 색상 데코레이터
public class ColorDecorator extends TextDecorator {
    private String color;
    
    public ColorDecorator(Text text, String color) {
        super(text);
        this.color = color;
    }
    
    @Override
    public String getContent() {
        return "<color=" + color + ">" + text.getContent() + "</color>";
    }
}

// 사용
public class Main {
    public static void main(String[] args) {
        // 기본 텍스트
        Text text1 = new PlainText("Hello World");
        System.out.println(text1.getContent());
        
        // 볼드 텍스트
        Text text2 = new BoldDecorator(new PlainText("Hello World"));
        System.out.println(text2.getContent());
        
        // 볼드 + 이탤릭
        Text text3 = new ItalicDecorator(new BoldDecorator(new PlainText("Hello World")));
        System.out.println(text3.getContent());
        
        // 볼드 + 이탤릭 + 밑줄 + 색상
        Text text4 = new PlainText("Hello World");
        text4 = new BoldDecorator(text4);
        text4 = new ItalicDecorator(text4);
        text4 = new UnderlineDecorator(text4);
        text4 = new ColorDecorator(text4, "red");
        System.out.println(text4.getContent());
    }
}

실전 예제: 알림 시스템

// 알림 인터페이스
public interface Notifier {
    void send(String message);
}

// 기본 이메일 알림
public class EmailNotifier implements Notifier {
    @Override
    public void send(String message) {
        System.out.println("  이메일 전송: " + message);
    }
}

// 알림 데코레이터
public abstract class NotifierDecorator implements Notifier {
    protected Notifier notifier;
    
    public NotifierDecorator(Notifier notifier) {
        this.notifier = notifier;
    }
    
    @Override
    public void send(String message) {
        notifier.send(message);
    }
}

// SMS 알림 추가
public class SMSDecorator extends NotifierDecorator {
    public SMSDecorator(Notifier notifier) {
        super(notifier);
    }
    
    @Override
    public void send(String message) {
        super.send(message);  // 기존 알림도 보냄
        System.out.println("  SMS 전송: " + message);
    }
}

// 카카오톡 알림 추가
public class KakaoDecorator extends NotifierDecorator {
    public KakaoDecorator(Notifier notifier) {
        super(notifier);
    }
    
    @Override
    public void send(String message) {
        super.send(message);
        System.out.println("  카카오톡 전송: " + message);
    }
}

// 슬랙 알림 추가
public class SlackDecorator extends NotifierDecorator {
    public SlackDecorator(Notifier notifier) {
        super(notifier);
    }
    
    @Override
    public void send(String message) {
        super.send(message);
        System.out.println("  슬랙 전송: " + message);
    }
}

// 사용
public class Main {
    public static void main(String[] args) {
        // 이메일만
        Notifier notifier1 = new EmailNotifier();
        notifier1.send("회원가입 완료");
        
        System.out.println("\n--- VIP 고객 ---");
        // 이메일 + SMS
        Notifier notifier2 = new SMSDecorator(new EmailNotifier());
        notifier2.send("특별 할인 안내");
        
        System.out.println("\n--- 임직원 ---");
        // 이메일 + 카카오톡 + 슬랙
        Notifier notifier3 = new EmailNotifier();
        notifier3 = new KakaoDecorator(notifier3);
        notifier3 = new SlackDecorator(notifier3);
        notifier3.send("긴급 공지사항");
    }
}

데코레이터 패턴의 장점

개방-폐쇄 원칙: 새로운 기능 추가 시 기존 코드 수정 없음
단일 책임 원칙: 각 데코레이터는 하나의 기능만 담당
유연성: 런타임에 동적으로 기능 추가/제거
조합 가능: 여러 데코레이터를 자유롭게 조합
상속의 대안: 클래스 폭발 문제 해결

데코레이터 패턴의 단점

복잡도 증가: 작은 객체들이 많이 생성됨
순서 의존성: 데코레이터 적용 순서가 중요할 수 있음
디버깅 어려움: 여러 겹으로 감싸져 있어 추적이 어려움
특정 데코레이터 제거 어려움: 중간 데코레이터만 제거하기 힘듦

Java에서의 데코레이터 패턴

Java의 I/O 클래스가 대표적인 데코레이터 패턴 예시다.

// Java I/O의 데코레이터 패턴
import java.io.*;

public class Main {
    public static void main(String[] args) throws IOException {
        // 기본 파일 입력
        FileInputStream fis = new FileInputStream("file.txt");
        
        // 버퍼링 기능 추가
        BufferedInputStream bis = new BufferedInputStream(fis);
        
        // 데이터 타입 변환 기능 추가
        DataInputStream dis = new DataInputStream(bis);
        
        // 모두 InputStream을 구현하지만 각자 다른 기능을 추가!
    }
}

Spring에서의 데코레이터 패턴

// Spring의 TransactionTemplate 등이 데코레이터 패턴 활용
@Service
public class UserService {
    private final UserRepository userRepository;
    
    // 트랜잭션 데코레이터처럼 동작
    @Transactional  
    public void createUser(User user) {
        userRepository.save(user);
    }
}

// 캐싱 데코레이터
@Cacheable("users")
public User getUser(Long id) {
    return userRepository.findById(id);
}

// 로깅 데코레이터 (AOP)
@Aspect
@Component
public class LoggingAspect {
    @Around("execution(* com.example.service.*.*(..))")
    public Object logAround(ProceedingJoinPoint joinPoint) throws Throwable {
        System.out.println("메서드 실행 전");
        Object result = joinPoint.proceed();  // 원본 메서드 실행
        System.out.println("메서드 실행 후");
        return result;
    }
}

실무에서 언제 사용할까?

사용하면 좋은 경우:

객체에 동적으로 기능을 추가/제거해야 할 때
기능의 조합이 많을 때
상속으로 인한 클래스 폭발을 피하고 싶을 때
런타임에 기능을 선택해야 할 때

사용하지 않아도 되는 경우:

기능 조합이 고정되어 있을 때
간단한 기능 추가만 필요할 때
데코레이터 순서가 중요하지 않을 때

핵심 원칙:

"기능을 동적으로 조합해야 한다면 데코레이터 패턴을 고려하라"

데코레이터 vs 어댑터 vs 프록시

패턴	목적	인터페이스	기능
데코레이터	기능 추가	동일	원본 + 추가 기능
어댑터	인터페이스 변환	다름	인터페이스만 변환
프록시	접근 제어	동일	제어 + 원본 기능

결론

데코레이터 패턴은 객체에 동적으로 기능을 추가하는 유연한 패턴이다.

기억해야 할 포인트:

객체를 감싸서 기능을 추가한다
기존 코드를 수정하지 않는다
기능을 자유롭게 조합할 수 있다
상속의 좋은 대안이다
Java I/O, Spring AOP 등에서 활발히 사용된다

다음 글에서는 객체에 대한 접근을 제어하는 프록시 패턴을 알아볼 것이다.

다음 글 예고: 프록시 패턴 - 객체 접근을 제어하라

어댑터 패턴(Adapter Pattern)

김코딩딩 — Tue, 13 Jan 2026 21:12:29 +0900

디자인 패턴 시리즈의 여섯 번째 주제는 어댑터 패턴(Adapter Pattern)이다. 이번부터는 생성 패턴에서 구조 패턴으로 넘어간다.

생성 패턴이 "객체를 어떻게 만들까?"였다면, 구조 패턴은 "객체들을 어떻게 조합할까?"에 대한 해답이다.

예를 들어, 한국에서 쓰던 220V 전자기기를 미국에 가져가면 110V라서 사용할 수 없다. 이때 필요한 게 바로 '변압기(어댑터)'다.

어댑터 패턴도 마찬가지다. 서로 맞지 않는 인터페이스를 중간에서 연결해주는 역할을 한다.

이번 글에서는 어댑터 패턴이 무엇인지, 왜 필요한지, 어떻게 구현하는지 알아보자.

어댑터 패턴의 정의

어댑터 패턴(Adapter Pattern)은 호환되지 않는 인터페이스를 가진 객체들이 함께 동작할 수 있도록 중간에서 변환해주는 패턴이다.

핵심 특징:

기존 클래스를 수정하지 않고 재사용한다
서로 다른 인터페이스를 중간에서 변환한다
클라이언트와 서비스 사이의 호환성을 제공한다
래퍼(Wrapper) 역할을 한다

현실 비유:

220V → 110V 변압기
USB-C → USB-A 변환 젠더
멀티탭 (여러 플러그를 한 곳에)

왜 어댑터 패턴이 필요할까?

음악 플레이어를 만드는데, 기존에 MP3만 재생하는 라이브러리가 있다. 그런데 고객이 MP4, VLC 파일도 재생하고 싶다고 한다.

// 기존 MP3 플레이어 (이미 만들어져 있어서 수정할 수 없음)
public class MP3Player {
    public void playMP3(String fileName) {
        System.out.println("MP3 재생: " + fileName);
    }
}

// 새로운 요구사항: MP4, VLC도 재생해야 함
// 하지만 기존 코드는 MP3만 지원...

// 클라이언트 코드
public class MusicPlayer {
    public void play(String fileType, String fileName) {
        if (fileType.equals("mp3")) {
            MP3Player player = new MP3Player();
            player.playMP3(fileName);
        } else if (fileType.equals("mp4")) {
            // MP4는 어떻게 재생하지?
        } else if (fileType.equals("vlc")) {
            // VLC는 어떻게 재생하지?
        }
    }
}

문제점:

기존 MP3Player는 수정할 수 없다 (라이브러리나 레거시 코드)
MP4Player, VLCPlayer는 다른 인터페이스를 가지고 있다
매번 새로운 플레이어를 추가하면 클라이언트 코드를 수정해야 한다

어댑터 패턴은 "중간에서 변환해주는 어댑터를 만들자"로 이 문제를 해결한다.

순수 Java로 구현하기

1단계: 타겟 인터페이스 정의

클라이언트가 사용할 통일된 인터페이스를 만든다.

// 미디어 플레이어 인터페이스 (타겟 인터페이스)
public interface MediaPlayer {
    void play(String fileType, String fileName);
}

2단계: 어댑티(Adaptee) - 적응시킬 클래스들

이미 존재하는 클래스들 (수정 불가능하다고 가정)

// MP4 전용 플레이어 (어댑티)
public class MP4Player {
    public void playMP4(String fileName) {
        System.out.println("MP4 재생: " + fileName);
    }
}

// VLC 전용 플레이어 (어댑티)
public class VLCPlayer {
    public void playVLC(String fileName) {
        System.out.println("VLC 재생: " + fileName);
    }
}

3단계: 어댑터 생성

어댑티를 타겟 인터페이스에 맞게 변환한다.

// 미디어 어댑터
public class MediaAdapter implements MediaPlayer {
    private MP4Player mp4Player;
    private VLCPlayer vlcPlayer;
    
    public MediaAdapter(String fileType) {
        if (fileType.equals("mp4")) {
            mp4Player = new MP4Player();
        } else if (fileType.equals("vlc")) {
            vlcPlayer = new VLCPlayer();
        }
    }
    
    @Override
    public void play(String fileType, String fileName) {
        if (fileType.equals("mp4")) {
            mp4Player.playMP4(fileName);
        } else if (fileType.equals("vlc")) {
            vlcPlayer.playVLC(fileName);
        }
    }
}

4단계: 클라이언트 코드

// 오디오 플레이어 (클라이언트)
public class AudioPlayer implements MediaPlayer {
    private MediaAdapter mediaAdapter;
    
    @Override
    public void play(String fileType, String fileName) {
        // MP3는 기본 지원
        if (fileType.equals("mp3")) {
            System.out.println("MP3 재생: " + fileName);
        }
        // MP4, VLC는 어댑터를 통해 재생
        else if (fileType.equals("mp4") || fileType.equals("vlc")) {
            mediaAdapter = new MediaAdapter(fileType);
            mediaAdapter.play(fileType, fileName);
        }
        else {
            System.out.println("지원하지 않는 형식: " + fileType);
        }
    }
}

// 사용 예시
public class Main {
    public static void main(String[] args) {
        AudioPlayer player = new AudioPlayer();
        
        player.play("mp3", "노래.mp3");
        player.play("mp4", "뮤직비디오.mp4");
        player.play("vlc", "영화.vlc");
        player.play("avi", "비디오.avi");
    }
}

장점:

기존 MP4Player, VLCPlayer를 수정하지 않음
클라이언트는 통일된 인터페이스만 사용
새로운 플레이어 추가도 쉬움

실전 예제: 결제 시스템 통합

더 실무적인 예시를 보자. 여러 결제 시스템을 하나의 인터페이스로 통합하는 경우다.

// 우리가 사용할 통일된 결제 인터페이스
public interface PaymentProcessor {
    boolean processPayment(int amount);
    String getPaymentStatus();
}

// 기존 토스페이 라이브러리 (수정 불가)
public class TossPaymentService {
    public void sendPayment(int won) {
        System.out.println("토스페이로 " + won + "원 결제 요청");
    }
    
    public String checkStatus() {
        return "토스 결제 완료";
    }
}

// 기존 카카오페이 라이브러리 (수정 불가)
public class KakaoPayService {
    public boolean pay(int amount) {
        System.out.println("카카오페이로 " + amount + "원 결제");
        return true;
    }
    
    public String status() {
        return "카카오 결제 성공";
    }
}

// 토스페이 어댑터
public class TossPaymentAdapter implements PaymentProcessor {
    private TossPaymentService tossService;
    
    public TossPaymentAdapter() {
        this.tossService = new TossPaymentService();
    }
    
    @Override
    public boolean processPayment(int amount) {
        tossService.sendPayment(amount);
        return true;
    }
    
    @Override
    public String getPaymentStatus() {
        return tossService.checkStatus();
    }
}

// 카카오페이 어댑터
public class KakaoPaymentAdapter implements PaymentProcessor {
    private KakaoPayService kakaoService;
    
    public KakaoPaymentAdapter() {
        this.kakaoService = new KakaoPayService();
    }
    
    @Override
    public boolean processPayment(int amount) {
        return kakaoService.pay(amount);
    }
    
    @Override
    public String getPaymentStatus() {
        return kakaoService.status();
    }
}

// 주문 서비스 (클라이언트)
public class OrderService {
    private PaymentProcessor paymentProcessor;
    
    public OrderService(PaymentProcessor paymentProcessor) {
        this.paymentProcessor = paymentProcessor;
    }
    
    public void checkout(int amount) {
        System.out.println("=== 결제 시작 ===");
        boolean success = paymentProcessor.processPayment(amount);
        
        if (success) {
            System.out.println("상태: " + paymentProcessor.getPaymentStatus());
            System.out.println("=== 주문 완료 ===\n");
        }
    }
}

// 사용
public class Main {
    public static void main(String[] args) {
        // 토스페이로 결제
        OrderService orderService1 = new OrderService(new TossPaymentAdapter());
        orderService1.checkout(15000);
        
        // 카카오페이로 결제
        OrderService orderService2 = new OrderService(new KakaoPaymentAdapter());
        orderService2.checkout(25000);
    }
}

장점:

각 결제 라이브러리의 다른 메서드명을 통일된 인터페이스로 사용
새로운 결제 수단 추가 시 어댑터만 만들면 됨
클라이언트 코드(OrderService)는 변경 없음

클래스 어댑터 vs 객체 어댑터

어댑터 패턴에는 두 가지 방식이 있다.

객체 어댑터 (권장)

지금까지 본 방식. 어댑티 객체를 합성(Composition)으로 사용한다.

public class MediaAdapter implements MediaPlayer {
    private MP4Player mp4Player;  // 객체를 가지고 있음
    
    @Override
    public void play(String fileType, String fileName) {
        mp4Player.playMP4(fileName);  // 위임
    }
}

장점:

유연하다
여러 어댑티를 동시에 사용 가능
Java에서 권장되는 방식

클래스 어댑터

다중 상속을 사용한다. (Java는 인터페이스로만 가능)

// Java에서는 인터페이스로만 가능
public interface MP4Playable {
    void playMP4(String fileName);
}

public class MediaAdapter implements MediaPlayer, MP4Playable {
    @Override
    public void play(String fileType, String fileName) {
        playMP4(fileName);  // 직접 호출
    }
    
    @Override
    public void playMP4(String fileName) {
        System.out.println("MP4 재생: " + fileName);
    }
}

단점:

Java는 다중 상속이 안 됨 (인터페이스만 가능)
덜 유연함

어댑터 패턴의 장점

개방-폐쇄 원칙: 기존 코드를 수정하지 않고 새로운 어댑터 추가
단일 책임 원칙: 인터페이스 변환 로직을 분리
재사용성: 기존 클래스를 그대로 재사용
호환성: 서로 다른 인터페이스를 함께 사용 가능

어댑터 패턴의 단점

복잡도 증가: 새로운 클래스들이 추가됨
간접 호출: 어댑터를 거쳐서 호출하므로 약간의 오버헤드
과도한 사용: 간단한 경우 오히려 복잡해질 수 있음

Spring에서의 어댑터 패턴

Spring에서도 어댑터 패턴이 많이 사용된다.

// Spring의 HandlerAdapter가 대표적인 예시
public interface HandlerAdapter {
    boolean supports(Object handler);
    ModelAndView handle(HttpServletRequest request, 
                       HttpServletResponse response, 
                       Object handler);
}

// 우리 프로젝트에서 사용 예시
public interface NotificationService {
    void send(String message);
}

// 기존 이메일 서비스 (수정 불가)
@Component
public class EmailService {
    public void sendEmail(String to, String subject, String body) {
        System.out.println("이메일 발송: " + body);
    }
}

// 기존 SMS 서비스 (수정 불가)
@Component
public class SMSService {
    public boolean sendSMS(String phoneNumber, String text) {
        System.out.println("SMS 발송: " + text);
        return true;
    }
}

// 이메일 어댑터
@Component
public class EmailNotificationAdapter implements NotificationService {
    private final EmailService emailService;
    
    public EmailNotificationAdapter(EmailService emailService) {
        this.emailService = emailService;
    }
    
    @Override
    public void send(String message) {
        emailService.sendEmail("user@email.com", "알림", message);
    }
}

// SMS 어댑터
@Component
public class SMSNotificationAdapter implements NotificationService {
    private final SMSService smsService;
    
    public SMSNotificationAdapter(SMSService smsService) {
        this.smsService = smsService;
    }
    
    @Override
    public void send(String message) {
        smsService.sendSMS("010-1234-5678", message);
    }
}

// 사용
@Service
public class NotificationManager {
    private final List<NotificationService> notificationServices;
    
    public NotificationManager(List<NotificationService> notificationServices) {
        this.notificationServices = notificationServices;
    }
    
    public void notifyAll(String message) {
        for (NotificationService service : notificationServices) {
            service.send(message);
        }
    }
}

실무에서 언제 사용할까?

사용하면 좋은 경우:

기존 클래스를 수정할 수 없을 때
서로 다른 인터페이스를 가진 클래스들을 통합할 때
레거시 시스템과 새 시스템을 연결할 때
외부 라이브러리나 API를 통합할 때

사용하지 않아도 되는 경우:

인터페이스를 직접 수정할 수 있을 때
변환 로직이 매우 간단할 때
한 번만 사용할 때

핵심 원칙:

"호환되지 않는 인터페이스를 연결해야 한다면 어댑터 패턴을 고려하라"

어댑터 vs 다른 패턴

패턴	목적	차이점
어댑터	인터페이스 변환	기존 인터페이스를 다른 인터페이스로 변환
데코레이터	기능 추가	인터페이스는 같고 기능만 추가
프록시	접근 제어	인터페이스는 같고 접근을 제어
퍼사드	단순화	복잡한 시스템을 간단한 인터페이스로

결론

어댑터 패턴은 호환되지 않는 인터페이스를 연결하는 패턴이다.

기억해야 할 포인트:

변압기처럼 인터페이스를 변환한다
기존 코드를 수정하지 않고 재사용한다
서로 다른 시스템을 통합할 때 유용하다
객체 어댑터(합성)를 주로 사용한다
레거시 시스템 통합에 필수적이다

다음 글에서는 기존 객체에 새로운 기능을 추가하는 데코레이터 패턴을 알아볼 것이다.

다음 글 예고: 데코레이터 패턴 - 객체에 동적으로 기능을 추가하라