Java on kastori

OOP와 SOLID — Spring이 왜 이렇게 설계됐는지 이해하는 열쇠

Thu, 18 Jun 2026 00:00:00 +0900

SOLID를 외우지 말고 이해하자

SOLID는 면접에서 “SRP는 단일 책임 원칙이고…“로 외워서 답하는 것이 아니다. 실제로 코드에 적용해서 “왜 이렇게 짰는지"를 설명할 수 있어야 한다.

좋은 소식이 있다. Spring을 쓰면서 이미 SOLID를 적용하고 있다.

OOP 4대 원칙 — 한 줄 정리

앞 시리즈에서 다룬 내용의 요약이다.

원칙	한 줄	코드 키워드
캡슐화	내부를 숨기고 인터페이스만 노출	`private` 필드, getter/setter
상속	부모의 속성을 물려받음	`extends`, `super`
다형성	같은 타입으로 다양한 구현	인터페이스, 업캐스팅
추상화	복잡한 내부를 숨기고 핵심만 노출	`interface`, `abstract`

S — 단일 책임 원칙 (SRP)

“클래스는 하나의 이유로만 변경되어야 한다.”

// ❌ SRP 위반 — 주문 처리와 이메일 발송이 한 클래스에
public class OrderService {
 public void createOrder(Order order) { ... }
 public void sendConfirmationEmail(Order order) { ... } // 이메일 책임이 왜 여기?
}

// ✅ SRP 준수 — 책임 분리
public class OrderService {
 public void createOrder(Order order) { ... }
}

public class EmailService {
 public void sendConfirmationEmail(Order order) { ... }
}

“이 클래스가 변경되는 이유가 몇 가지인가?“로 체크한다. 이메일 템플릿이 바뀌어도 OrderService가 수정된다면 SRP를 위반하고 있다.

O — 개방-폐쇄 원칙 (OCP)

“확장에는 열려있고, 수정에는 닫혀있어야 한다.”

// ❌ OCP 위반 — 결제 수단 추가할 때마다 기존 코드 수정
public void pay(String type, int amount) {
 if (type.equals("kakao")) { ... }
 else if (type.equals("naver")) { ... }
 else if (type.equals("toss")) { ... } // 추가할 때마다 여기 수정
}

// ✅ OCP 준수 — 새 구현체만 추가하면 됨
public interface PaymentStrategy {
 void pay(int amount);
}

public class KakaoPay implements PaymentStrategy { ... }
public class NaverPay implements PaymentStrategy { ... }
// Toss 추가 = TossPay 클래스만 추가. 기존 코드 수정 없음

Spring DI가 OCP를 지원하는 방식이다. OrderService는 PaymentStrategy 인터페이스만 알고, 어떤 구현체가 주입될지는 신경 쓰지 않는다.

L — 리스코프 치환 원칙 (LSP)

“자식 클래스는 부모 클래스를 대체할 수 있어야 한다.”

// ❌ LSP 위반
public class Rectangle {
 int width, height;
 public int area() { return width * height; }
}

public class Square extends Rectangle {
 @Override
 public void setWidth(int w) {
 this.width = w;
 this.height = w; // 정사각형이라 높이도 같이 바꿈
 }
}

Rectangle r = new Square();
r.setWidth(5);
r.setHeight(3);
System.out.println(r.area()); // 예상: 15, 실제: 9 (Square의 setWidth가 height도 바꿨으므로)

부모 자리에 자식을 넣었을 때 예상대로 동작하지 않으면 LSP 위반이다. 해결책: 상속 대신 별도 클래스로 분리하거나 인터페이스로.

I — 인터페이스 분리 원칙 (ISP)

“클라이언트가 사용하지 않는 메서드에 의존하지 않아야 한다.”

// ❌ ISP 위반 — 너무 큰 인터페이스
public interface Worker {
 void work();
 void eat();
 void sleep();
}

// Robot은 eat, sleep이 필요 없지만 구현 강제됨
public class Robot implements Worker {
 public void work() { ... }
 public void eat() { throw new UnsupportedOperationException(); } // 억지로
 public void sleep() { throw new UnsupportedOperationException(); }
}

// ✅ ISP 준수 — 인터페이스 분리
public interface Workable { void work(); }
public interface Eatable { void eat(); }

public class Human implements Workable, Eatable { ... }
public class Robot implements Workable { ... } // 필요한 것만

D — 의존성 역전 원칙 (DIP)

“고수준 모듈이 저수준 모듈에 의존하면 안 된다. 둘 다 추상화에 의존해야 한다.”

// ❌ DIP 위반 — 구체 클래스에 직접 의존
public class OrderService {
 private KakaopayService kakaopay = new KakaopayService(); // 이 구현체에 묶임
}

// ✅ DIP 준수 — 추상화(인터페이스)에 의존
public class OrderService {
 private final PaymentService paymentService; // 인터페이스에 의존

 public OrderService(PaymentService paymentService) { // 외부에서 주입
 this.paymentService = paymentService;
 }
}

이게 Spring DI다. OrderService는 PaymentService 인터페이스만 알고, 실제 구현체(KakaopayService, NaverPayService)는 Spring이 주입한다.

SOLID가 Spring에서 어떻게 쓰이는가

SOLID	Spring 적용 사례
SRP	`@Service`, `@Repository` — 계층별로 책임 분리
OCP	인터페이스 기반 Bean — 구현체 교체해도 코드 수정 불필요
LSP	Spring AOP 프록시 — 원본 Bean 대신 프록시가 들어가도 정상 동작
ISP	`JpaRepository`의 세분화된 인터페이스 상속 구조
DIP	`@Autowired` DI — 구체 클래스 대신 인터페이스에 의존

@Transactional도 OCP의 사례다. 트랜잭션 로직을 모든 서비스 메서드에 직접 쓰지 않고, AOP로 분리해서 적용한다. 서비스 코드는 수정하지 않고 기능을 추가하는 것이다.

제네릭과 어노테이션은 부록

제네릭 — 컴파일 타임 타입 안전성

// 제네릭 없이 — 런타임에 ClassCastException 위험
List list = new ArrayList();
list.add("hello");
String s = (String) list.get(0); // 캐스팅 필요, 틀리면 런타임 오류

// 제네릭 사용 — 컴파일 타임에 타입 체크
List<String> list = new ArrayList<>();
list.add(123); // 컴파일 오류 — 미리 잡힘

Spring에서 ResponseEntity<T>, List<UserDto>, Optional<User> 등을 쓸 때 항상 제네릭이 등장한다.

어노테이션 — 붙이는 것만으로는 아무 일도 없다

@Service // 이걸 붙이는 것만으로 Bean이 되지 않는다
public class UserService { ... }

Spring이 시작될 때 리플렉션으로 @Service를 읽고, Bean으로 등록하는 것이다. 어노테이션은 “이 클래스를 Bean으로 등록해줘"라는 표시일 뿐, 실제 동작은 Spring의 ApplicationContext가 한다.

시리즈를 마치며

Java 핵심 개념 7편을 통해 다룬 것들:

#1 클래스와 객체 — 캡슐화, 불변 객체, 방어적 복사
#2 상속과 다형성 — 동적 바인딩, 컴포지션 vs 상속
#3 인터페이스 — 계약, 다중 구현, 함수형 인터페이스
#4 JVM 메모리 — Heap/Stack, GC, OOM 원인
#5 컬렉션 — ArrayList/HashMap 내부 구조, ConcurrentHashMap
#6 동시성 — synchronized, volatile, ThreadLocal
#7 OOP & SOLID — Spring 설계의 기반

이 개념들은 Spring을 쓰면서 매일 마주치는 것들이다. 코드를 쓸 때 “이게 왜 이렇게 됐지?“라는 질문이 생기면, 이 시리즈가 출발점이 되길 바란다.

Java 동시성 — synchronized, volatile, ThreadLocal, 그리고 Spring과의 관계

Wed, 17 Jun 2026 00:00:00 +0900

Spring은 멀티스레드 환경이다

Tomcat은 HTTP 요청이 올 때마다 스레드를 할당한다. 기본 설정에서 200개의 스레드가 동시에 돌 수 있다. 그 말은 OrderService 하나가 200개의 스레드에서 동시에 호출될 수 있다는 뜻이다.

이게 왜 문제가 되는지, 어떻게 안전하게 만드는지 살펴보자.

동시성 문제 3가지

1. 경쟁 조건 (Race Condition)

public class Counter {
 private int count = 0;

 public void increment() {
 count++; // 사실 3단계: 읽기 → 더하기 → 쓰기
 }
}

두 스레드가 동시에 count = 0을 읽으면, 둘 다 count = 1을 쓴다. 결과는 2가 아닌 1이 된다.

2. 가시성 문제 (Visibility)

각 스레드는 성능을 위해 값을 CPU 캐시에 저장한다. Thread B가 변경한 값이 Thread A의 캐시에 바로 반영되지 않을 수 있다.

boolean running = true;

// Thread A — 캐시의 running을 계속 읽으면 변경을 감지 못할 수 있다
while (running) { ... }

// Thread B
running = false; // 메인 메모리에 썼지만 Thread A 캐시엔 아직 true

3. 데드락

두 스레드가 서로의 락을 기다려 영원히 멈추는 상황이다.

// Thread A: lock1 획득 → lock2 대기
// Thread B: lock2 획득 → lock1 대기
// → 영원히 대기

예방법: 락 획득 순서를 항상 일관되게 유지한다.

synchronized — 한 번에 하나씩

synchronized는 블록에 한 번에 하나의 스레드만 진입하게 막는다.

public class SafeCounter {
 private int count = 0;

 public synchronized void increment() { // this를 락으로 사용
 count++;
 }
}

락이 필요한 부분만 동기화하면 성능이 낫다.

public class SafeCounter {
 private int count = 0;
 private final Object lock = new Object();

 public void increment() {
 synchronized (lock) {
 count++;
 }
 // 나머지 코드는 동시 실행 가능
 }
}

synchronized의 한계: 락을 얻기 위해 다른 스레드는 블로킹된다. 동시성이 높은 환경에서는 병목이 생길 수 있다.

volatile — 가시성 보장

volatile 변수는 항상 메인 메모리에서 읽고 쓴다. CPU 캐시를 거치지 않는다.

volatile boolean running = true;

// Thread A — 항상 메인 메모리에서 읽으므로 변경을 바로 감지
while (running) { ... }

// Thread B
running = false; // 메인 메모리에 즉시 반영 → Thread A가 감지

하지만 volatile은 가시성만 보장한다. 원자성은 보장하지 않는다.

volatile int count = 0;
count++; // 읽기 → 더하기 → 쓰기가 원자적이지 않음 → 여전히 Race Condition

count++를 안전하게 하려면 synchronized 또는 AtomicInteger가 필요하다.

AtomicInteger — 락 없는 원자적 연산

java.util.concurrent.atomic 패키지는 락 없이 원자적 연산을 제공한다.

AtomicInteger count = new AtomicInteger(0);

count.incrementAndGet(); // 원자적 ++ 
count.addAndGet(5); // 원자적 += 5
count.compareAndSet(10, 20); // 현재 값이 10이면 20으로 변경 (CAS)

내부적으로 CAS(Compare-And-Swap) 하드웨어 명령어를 사용해서 락 없이 원자성을 보장한다. synchronized보다 성능이 좋다.

ThreadLocal — 스레드마다 독립적인 저장소

ThreadLocal은 같은 변수지만 스레드마다 다른 값을 가진다.

public class RequestContext {
 private static final ThreadLocal<String> userId = new ThreadLocal<>();

 public static void set(String id) { userId.set(id); }
 public static String get() { return userId.get(); }
 public static void clear() { userId.remove(); } // 반드시 호출
}

// Thread A에서: RequestContext.set("user1");
// Thread B에서: RequestContext.set("user2");
// 각 스레드에서 RequestContext.get() → 자기 스레드의 값만 반환

Spring이 내부적으로 ThreadLocal을 많이 쓴다.

Spring Security SecurityContextHolder: HTTP 요청 스레드에 인증 정보 저장
Spring Transaction: 트랜잭션 정보를 스레드에 바인딩

ThreadLocal 메모리 누수 주의

Tomcat은 스레드 풀로 스레드를 재사용한다. 요청 처리 후 remove()를 하지 않으면 다음 요청에서 이전 데이터가 남아있다.

// Filter 또는 Interceptor에서
try {
 RequestContext.set(extractUserId(request));
 chain.doFilter(request, response);
} finally {
 RequestContext.clear(); // finally에서 반드시 제거
}

Singleton Bean의 스레드 안전성

Spring의 Singleton Bean은 여러 스레드가 공유한다. 인스턴스 변수에 상태를 저장하면 위험하다.

@Service
public class OrderService {
 // ❌ 스레드 안전하지 않음 — 여러 스레드가 동시에 수정
 private int requestCount = 0;

 // ✅ 지역변수는 각 스레드의 Stack에 있어 안전
 public void process(Order order) {
 int localCount = 0; // 안전
 ...
 }

 // ✅ final 불변 값은 안전
 private final String serviceName = "OrderService";
}

Bean을 스레드 안전하게 만드는 방법:

1. 무상태(stateless) 설계 — 인스턴스 변수에 상태 저장하지 않음 (가장 권장)
2. ThreadLocal 사용 — 스레드별 독립 저장
3. AtomicInteger / synchronized — 공유 상태가 불가피할 때

CompletableFuture — 비동기 작업 체이닝

Spring @Async와 함께 자주 쓰이는 패턴이다.

CompletableFuture.supplyAsync(() -> fetchUser(userId))
 .thenApply(user -> enrichWithOrders(user))
 .thenAccept(result -> saveToCache(result))
 .exceptionally(ex -> { log.error("실패", ex); return null; });

@Async 어노테이션은 내부적으로 AOP 프록시로 동작한다. 같은 클래스 내 자기 호출은 동작하지 않는다는 점을 주의해야 한다.

마치며

동시성 문제는 “발생하면 재현하기 어려운” 버그 중 하나다. 예방이 최선이다.

핵심 원칙 하나만 기억하면 된다: Bean은 무상태로 설계한다. 상태가 없으면 동기화 고민도 없다.

다음 편에서는 “코드를 왜 이렇게 짰나요?“에 대한 언어인 OOP와 SOLID 원칙으로 시리즈를 마무리한다.

Java 컬렉션 내부 구조 — ArrayList, HashMap이 실제로 어떻게 동작하는가

Tue, 16 Jun 2026 00:00:00 +0900

“어떤 컬렉션을 써야 하나요?”

이 질문에 제대로 답하려면 내부 구조를 알아야 한다. ArrayList가 LinkedList보다 빠른 이유, HashMap이 평균 O(1)인 이유, ConcurrentHashMap이 필요한 이유. 전부 내부 구조에서 나오는 답이다.

ArrayList — 배열 위의 리스트

ArrayList는 내부적으로 배열로 구현된다.

// 실제 OpenJDK 코드 (단순화)
public class ArrayList<E> {
 private Object[] elementData; // 저장 배열
 private int size; // 실제 원소 수
 // 기본 초기 용량: 10
 // 꽉 차면 1.5배 크기 배열 생성 후 복사
}

배열이라는 특성 때문에:

연산	시간복잡도	이유
`get(index)`	O(1)	배열 인덱스 직접 접근
`add(마지막)`	O(1) 평균	배열 끝에 추가
`add(중간)`	O(n)	뒤 원소들을 한 칸씩 이동
`remove(중간)`	O(n)	뒤 원소들을 한 칸씩 이동

언제 LinkedList를 쓸까? 거의 안 쓴다. get(index)가 O(n)이라 전체적으로 느리다. Queue/Deque 용도라면 ArrayDeque가 훨씬 빠르다.

조회가 많다 → ArrayList
첫/마지막 삽입/삭제가 많다 → ArrayDeque
Queue/Stack → ArrayDeque
대부분의 경우 → ArrayList

HashMap — 버킷 배열 + 해시

HashMap이 평균 O(1)인 이유는 구조에 있다.

버킷 배열 (기본 크기 16)
 index 0: null
 index 1: [Entry("key1", val1)] → [Entry("key5", val5)] ← 해시 충돌
 index 2: [Entry("key2", val2)]
 ...

키를 저장할 때:

int hash = key.hashCode(); // 1. 해시코드 계산
int index = hash & (n - 1); // 2. 버킷 인덱스 결정
buckets[index].add(entry); // 3. 해당 버킷에 저장

get(key)도 같은 방식으로 버킷을 바로 찾기 때문에 평균 O(1)이다.

해시 충돌이 생기면?

같은 버킷에 여러 키가 들어오는 게 해시 충돌이다.

Java 8 이전: 연결 리스트 (충돌 많으면 O(n))
Java 8 이후: 버킷 내 원소가 8개 초과하면 Red-Black Tree로 변환 (O(log n))

Resize

버킷 배열이 75% 이상 차면 2배로 늘리고 전체를 재배치한다. 이 과정이 O(n)이라 미리 예상 크기를 알면 초기 용량을 지정하는 게 좋다.

// 10,000개 원소를 넣을 거라면
Map<String, Integer> map = new HashMap<>(10000 / 0.75 + 1);

equals와 hashCode를 같이 오버라이드해야 하는 이유

HashMap은 키를 찾을 때 두 단계를 거친다: hashCode()로 버킷을 찾고, equals()로 정확한 키를 찾는다.

// hashCode만 오버라이드하면 → 버킷은 찾아도 equals가 항상 false → 못 찾음
// equals만 오버라이드하면 → 버킷 자체를 못 찾음

// 반드시 함께 오버라이드
@Override
public boolean equals(Object o) { ... }

@Override
public int hashCode() {
 return Objects.hash(id);
}

HashMap은 스레드 안전하지 않다

// 멀티스레드 환경에서 HashMap 사용 → 데이터 손실, 무한루프 가능
Map<String, Integer> map = new HashMap<>();

// 해결 방법 1: Collections.synchronizedMap (모든 메서드 동기화 → 느림)
Map<String, Integer> sync = Collections.synchronizedMap(new HashMap<>());

// 해결 방법 2: ConcurrentHashMap (권장)
Map<String, Integer> concurrent = new ConcurrentHashMap<>();

ConcurrentHashMap은 전체 맵을 잠그지 않고 버킷 단위로 락을 건다. 다른 버킷에는 여러 스레드가 동시 접근할 수 있어서 synchronized보다 훨씬 빠르다.

HashMap : 빠름, 스레드 비안전
HashTable : 모든 메서드 synchronized → 느림, 거의 사용 안 함
ConcurrentHashMap : 버킷 단위 락 → 빠름, 멀티스레드 표준

Map 종류 한눈에

	HashMap	LinkedHashMap	TreeMap	ConcurrentHashMap
순서	없음	삽입 순서	키 정렬	없음
null 키	허용	허용	❌	❌
스레드 안전	❌	❌	❌	✅
성능	O(1)	O(1)	O(log n)	O(1)

LinkedHashMap은 조회 순서로도 정렬할 수 있어서 LRU 캐시 구현에 자주 쓰인다.

HashSet은 사실 HashMap이다

// HashSet 내부 구현
private transient HashMap<E, Object> map;
private static final Object PRESENT = new Object(); // 더미 값

public boolean add(E e) {
 return map.put(e, PRESENT) == null;
}

HashSet은 HashMap의 key만 쓰고 value에는 더미 객체를 넣는다. 중복 판단도 equals + hashCode로 한다.

마치며

컬렉션 선택은 단순하다. 대부분은 ArrayList와 HashMap이면 된다. 멀티스레드 환경이라면 ConcurrentHashMap. 정렬이 필요하면 TreeMap 또는 TreeSet. 이 판단 기준을 내부 구조와 연결해서 이해하면 면접 질문에도 자연스럽게 답할 수 있다.

다음 편에서는 멀티스레드 환경에서 발생하는 문제와 해결책인 Java 동시성을 다룬다.

JVM 메모리 구조와 GC — OOM이 왜 발생하고 어떻게 막는가

Mon, 15 Jun 2026 00:00:00 +0900

Java 코드가 실행되는 환경

Java 코드를 작성하면 javac가 .class 바이트코드로 컴파일하고, JVM이 그것을 실행한다. “Write Once, Run Anywhere"가 가능한 이유가 여기 있다. 운영체제마다 다른 JVM이 바이트코드를 해석하기 때문이다.

JVM 내부를 간단히 표현하면:

[ .class 바이트코드 ]
 ↓
[ JVM ]
 ├─ ClassLoader : 클래스 파일 로드
 ├─ Execution Engine: 바이트코드 실행 (인터프리터 + JIT)
 ├─ Garbage Collector: 불필요한 객체 메모리 회수
 └─ Runtime Data Areas: 메모리 영역

Heap vs Stack — 면접 단골 질문

JVM 메모리에서 가장 중요한 두 영역이다.

public void method() {
 int x = 10; // x → Stack
 User user = new User(); // user 참조 → Stack, User 인스턴스 → Heap
 String s = "hello"; // s 참조 → Stack, "hello" 객체 → Heap
}
// 메서드 종료 → x, user, s 참조는 Stack에서 자동 제거
// Heap의 객체는 GC가 나중에 처리

구분	Heap	Stack
저장 내용	객체 인스턴스 (`new`)	지역변수, 메서드 호출 정보
공유 여부	모든 스레드 공유	스레드마다 독립
GC 대상	✅	❌ (자동 제거)
오류	`OutOfMemoryError`	`StackOverflowError`

StackOverflowError는 주로 무한 재귀 호출 때 발생한다.

GC — 메모리를 자동으로 정리한다

Java가 C/C++과 다른 결정적인 차이 중 하나가 GC다. 개발자가 직접 메모리를 해제하지 않아도 된다.

약한 세대 가설

GC 설계의 핵심 전제다.

“대부분의 객체는 생성 직후 짧은 시간 내에 죽는다.”

HTTP 요청 하나를 처리할 때 생각해보자. 요청 파라미터, DTO, 응답 객체 등 대부분은 요청이 끝나면 더 이상 필요 없다. 반면 서비스 객체, 캐시 데이터는 오래 살아남는다.

이를 기반으로 Heap을 Young / Old 영역으로 나눈다.

GC 동작 과정

Eden (새 객체 생성)
 ↓ Minor GC (Eden 꽉 참)
Survivor 0/1 (살아남은 객체, age +1)
 ↓ age가 15 초과
Old Generation (오래 살아남은 객체)
 ↓ Old 영역 꽉 참
Full GC (전체 정리 — 오래 걸림)

Minor GC는 Young 영역만 청소해서 빠르다. Full GC는 전체를 다 보기 때문에 느리다.

Stop-the-World

GC가 실행되는 동안 애플리케이션의 모든 스레드가 멈춘다. 메모리를 정리하는 중에 객체 참조가 바뀌면 안 되기 때문이다.

Spring 애플리케이션에서 갑자기 응답이 느려지거나 타임아웃이 발생하는 원인 중 하나가 Full GC의 긴 STW다.

GC 종류 — 지금은 G1GC가 기본

GC	특징	사용 환경
Serial GC	단일 스레드	소형 앱
Parallel GC	멀티 스레드, 처리량 우선	배치 작업
G1 GC	Region 기반, 예측 가능한 STW	Java 9+ 기본
ZGC	STW 10ms 미만, 초저지연	대용량 Heap

G1 GC는 Heap을 고정 크기 Region으로 나누고 가비지가 많은 Region부터 수집한다. JVM 옵션으로 STW 목표 시간을 설정할 수 있다.

-XX:+UseG1GC
-XX:MaxGCPauseMillis=200 # 목표 STW 200ms
-Xms2g -Xmx4g # 최소/최대 Heap 크기

OOM, 왜 발생하나

OutOfMemoryError가 발생하면 로그에 이유가 나온다.

java.lang.OutOfMemoryError: Java heap space
 → Heap 부족. 객체가 너무 많거나 메모리 누수.

java.lang.OutOfMemoryError: Metaspace
 → 클래스가 너무 많이 로드됨.

java.lang.OutOfMemoryError: GC overhead limit exceeded
 → GC가 열심히 해도 회수되는 메모리가 너무 적음.

가장 흔한 메모리 누수 패턴:

// 1. static 컬렉션에 계속 추가 — GC가 회수 못함
static List<Object> cache = new ArrayList<>();
// 이 cache를 지우는 코드가 없으면 계속 쌓임

// 2. ThreadLocal을 제거하지 않음 (스레드 풀 환경)
threadLocal.set(value);
// 반드시: threadLocal.remove();

// 3. 이벤트 리스너 미해제
button.addListener(listener);
// 해제하지 않으면 listener 객체가 계속 참조됨

JIT 컴파일러 — 왜 JVM은 “워밍업"이 필요한가

JVM은 처음에는 바이트코드를 인터프리터로 실행하다가, 자주 실행되는 코드(핫스팟)를 감지하면 네이티브 코드로 컴파일해서 캐시한다.

초기 실행: 인터프리터 (느림)
워밍업 후: JIT 컴파일된 네이티브 코드 (빠름)

Spring Boot 앱을 배포했을 때 처음 몇 분간 응답이 느린 이유가 여기 있다. GraalVM Native Image는 이 워밍업 문제를 해결하기 위해 빌드 시점에 미리 컴파일한다.

마치며

JVM 메모리 구조를 이해하면 “왜 이 에러가 났는지"를 추론할 수 있다. StackOverflowError면 무한 재귀를 의심하고, OutOfMemoryError: Java heap space면 메모리 누수나 객체 생성 패턴을 살펴봐야 한다.

다음 편에서는 자주 쓰는 컬렉션 내부가 어떻게 동작하는지 살펴본다.

인터페이스 vs 추상 클래스 — 면접 단골 질문, 제대로 이해하기

Sun, 14 Jun 2026 00:00:00 +0900

표를 외우는 것보다 중요한 것

인터페이스와 추상 클래스의 차이를 묻는 면접 질문에 많은 사람이 표를 외워서 답한다. 다중 구현 가능 여부, 생성자 유무, 필드 허용 여부…

하지만 진짜 중요한 건 왜 그렇게 설계됐는지다. 이걸 이해하면 표를 외우지 않아도 언제 무엇을 써야 할지 판단할 수 있다.

인터페이스 — “무엇을 할 수 있는가"의 계약

인터페이스는 구현 클래스가 “어떤 기능을 제공하겠다"는 약속이다.

public interface PaymentService {
 void process(int amount);
 boolean cancel(String orderId);
}

public class KakaopayService implements PaymentService {
 @Override
 public void process(int amount) { /* 카카오페이 결제 로직 */ }

 @Override
 public boolean cancel(String orderId) { /* 취소 로직 */ }
}

public class NaverPayService implements PaymentService {
 @Override
 public void process(int amount) { /* 네이버페이 결제 로직 */ }

 @Override
 public boolean cancel(String orderId) { /* 취소 로직 */ }
}

PaymentService 인터페이스 하나로 카카오페이, 네이버페이를 동일하게 다룰 수 있다. Spring DI에서 이 패턴을 그대로 쓴다.

@Service
public class OrderService {
 private final PaymentService paymentService; // 구현체가 아닌 인터페이스에 의존

 // Spring이 KakaopayService 또는 NaverPayService를 주입
 public OrderService(PaymentService paymentService) {
 this.paymentService = paymentService;
 }
}

다중 구현이 가능한 이유

Java는 클래스 단일 상속만 허용하지만 인터페이스는 여러 개 구현할 수 있다.

// 오리는 날 수도, 헤엄칠 수도 있다
public class Duck extends Animal implements Flyable, Swimmable {
 @Override public void fly() { ... }
 @Override public void swim() { ... }
}

Java 8+ default 메서드

인터페이스에 구현을 추가할 수 있게 됐다. 기존 인터페이스에 메서드를 추가해도 구현 클래스들이 깨지지 않는 장점이 있다.

public interface PaymentService {
 void process(int amount);

 default void processWithLog(int amount) {
 System.out.println("결제 시작: " + amount);
 process(amount);
 System.out.println("결제 완료");
 }
}
// 기존 KakaopayService, NaverPayService는 수정 없이 processWithLog() 사용 가능

추상 클래스 — “공통 구현을 공유”

추상 클래스는 “is-a” 관계에서 공통 로직을 여러 자식이 공유할 때 쓴다.

public abstract class BaseService<T, ID> {
 protected final Logger log = LoggerFactory.getLogger(getClass());

 // 공통 구현 — 모든 자식이 동일하게 사용
 public T findById(ID id) {
 log.debug("조회: {}", id);
 return doFindById(id); // 실제 구현은 자식에게 위임
 }

 // 추상 메서드 — 자식이 반드시 구현
 protected abstract T doFindById(ID id);
}

public class UserService extends BaseService<User, Long> {
 @Override
 protected User doFindById(Long id) {
 return userRepository.findById(id).orElseThrow();
 }
}

이것이 Template Method 패턴이다. 알고리즘 골격(로그 출력 → 조회 → 반환)은 부모가 정의하고, 세부 구현만 자식이 담당한다.

추상 클래스는 생성자와 인스턴스 변수를 가질 수 있어서 상태를 공유할 때도 유리하다.

public abstract class AbstractRepository<T> {
 protected final EntityManager em; // 모든 Repository가 공유

 public AbstractRepository(EntityManager em) {
 this.em = em;
 }
}

언제 무엇을 선택하는가

한 문장으로 정리하면:

인터페이스 → "무엇을 할 수 있는가 (can-do)" — 계약, 다형성
추상 클래스 → "무엇인가 (is-a)" — 공통 구현, 상태 공유

인터페이스를 선택할 때:

1. 관련 없는 클래스들이 같은 기능을 가져야 할 때
 → Serializable, Comparable — Dog, Integer, String 모두 구현 가능

2. 다중 구현이 필요할 때
 → Flyable + Swimmable 동시에

3. Spring DI에서 구현체를 교체할 수 있게 할 때
 → 테스트 시 MockPaymentService로 교체

추상 클래스를 선택할 때:

1. 관련 클래스들이 공통 코드를 공유해야 할 때
 → BaseController, AbstractEntity

2. 상태(필드)를 공유해야 할 때
 → EntityManager, Logger 공유

3. Template Method 패턴 — 알고리즘 골격 고정

함수형 인터페이스와 람다

추상 메서드가 딱 1개인 인터페이스를 함수형 인터페이스라 한다. 람다 표현식으로 구현할 수 있다.

// 익명 클래스로 구현 (Java 8 이전)
Comparator<String> comp = new Comparator<String>() {
 @Override
 public int compare(String a, String b) {
 return a.compareTo(b);
 }
};

// 람다로 구현 (Java 8+)
Comparator<String> comp = (a, b) -> a.compareTo(b);

// 메서드 레퍼런스로 더 간결하게
Comparator<String> comp = String::compareTo;

자주 쓰는 함수형 인터페이스:

Predicate<String> notEmpty = s -> !s.isEmpty(); // 조건 검사
Function<String, Integer> length = String::length; // 변환
Consumer<String> print = System.out::println; // 소비 (반환 없음)
Supplier<String> uuid = () -> UUID.randomUUID().toString(); // 공급

default 메서드 충돌

두 인터페이스가 같은 이름의 default 메서드를 가지면 구현 클래스에서 직접 해결해야 한다.

interface A { default void hello() { System.out.println("A"); } }
interface B { default void hello() { System.out.println("B"); } }

class C implements A, B {
 @Override
 public void hello() {
 A.super.hello(); // A의 default 명시적 선택
 }
}

마치며

인터페이스와 추상 클래스의 차이를 외우는 것보다, “이 설계가 계약(can-do)인가, 공통 구현 공유(is-a)인가"를 생각하는 습관이 더 중요하다.

실무에서는 Spring DI 덕분에 인터페이스를 훨씬 더 많이 쓰게 된다. 다음 편에서는 코드가 실행되는 환경인 JVM 메모리 구조와 GC를 살펴본다.

Java 상속과 다형성 — 언제 쓰고 언제 피해야 하나

Sat, 13 Jun 2026 00:00:00 +0900

상속을 쓰는 이유, 그리고 조심해야 하는 이유

상속은 부모 클래스의 코드를 자식이 물려받는 기능이다. “공통 로직을 한 곳에 모은다"는 장점이 있지만, 무분별하게 쓰면 오히려 코드가 더 복잡해진다.

이펙티브 자바에서는 “상속보다 컴포지션을 사용하라"고 강조한다. 왜 그런지 직접 코드로 살펴보자.

상속 기본

public class Animal {
 protected String name;

 public Animal(String name) {
 this.name = name;
 }

 public void makeSound() {
 System.out.println(name + ": ...");
 }
}

public class Dog extends Animal {
 private String breed;

 public Dog(String name, String breed) {
 super(name); // 부모 생성자 호출 — 첫 줄에 와야 함
 this.breed = breed;
 }

 @Override
 public void makeSound() {
 System.out.println(name + ": 멍멍!");
 }
}

@Override는 반드시 붙이자. 컴파일러가 “진짜 오버라이딩인지” 검증해준다. 없으면 메서드명 오타 같은 실수를 잡지 못한다.

오버라이딩 vs 오버로딩

자주 혼동되는 두 개념이다.

구분	오버라이딩	오버로딩
위치	자식 클래스	같은 클래스
목적	부모 동작 재정의	같은 기능, 다른 입력
매개변수	동일	다름

// 오버라이딩 — 부모와 시그니처 동일, 다른 클래스
public class Cat extends Animal {
 @Override
 public void makeSound() {
 System.out.println(name + ": 야옹");
 }
}

// 오버로딩 — 같은 클래스, 매개변수 다름
public class Calculator {
 public int add(int a, int b) { return a + b; }
 public double add(double a, double b) { return a + b; }
}

다형성 — 상속의 핵심 가치

다형성은 “같은 타입으로 여러 구현을 다루는 것"이다.

// 업캐스팅 — 자식 → 부모 타입으로, 자동 변환
Animal animal = new Dog("바둑이", "진돗개");
animal.makeSound(); // "바둑이: 멍멍!" — Dog의 makeSound() 실행

// 같은 타입으로 여러 구현체를 다룰 수 있다
List<Animal> animals = new ArrayList<>();
animals.add(new Dog("바둑이", "진돗개"));
animals.add(new Cat("나비"));

for (Animal a : animals) {
 a.makeSound(); // 각자 자신의 구현 실행
}

animal.makeSound()를 호출할 때 컴파일 타임에는 Animal.makeSound()를 부르는 것처럼 보이지만, 런타임에는 실제 객체 타입(Dog)의 메서드가 실행된다. 이것을 동적 바인딩이라 한다.

다운캐스팅은 조심해서

Animal animal = new Dog("바둑이", "진돗개");

// Dog에만 있는 메서드를 쓰려면 다운캐스팅 필요
if (animal instanceof Dog dog) { // Java 16+ 패턴 매칭
 dog.fetch();
}

// instanceof 없이 바로 캐스팅하면 ClassCastException 위험
Dog dog = (Dog) new Cat("나비"); // 런타임 오류!

상속의 문제 — 캡슐화가 깨진다

상속을 쓰면 자식 클래스가 부모 내부 구현에 의존하게 된다. 부모가 바뀌면 자식도 영향을 받는다.

실제 Java 표준 라이브러리에서도 이 문제가 있었다.

// HashSet을 상속해서 "몇 번 추가됐는지" 세는 클래스
public class MyHashSet<E> extends HashSet<E> {
 private int addCount = 0;

 @Override
 public boolean add(E e) {
 addCount++;
 return super.add(e);
 }

 @Override
 public boolean addAll(Collection<? extends E> c) {
 addCount += c.size();
 return super.addAll(c); // 문제: HashSet의 addAll은 내부적으로 add()를 호출
 // → addCount가 이중으로 카운트됨!
 }
}

MyHashSet<String> set = new MyHashSet<>();
set.addAll(List.of("a", "b", "c"));
System.out.println(set.addCount); // 예상: 3, 실제: 6

HashSet의 addAll 내부 구현이 add()를 호출한다는 사실에 의존하고 있어서 생기는 문제다. 부모 클래스를 직접 만든 게 아니라면 내부 구현을 믿을 수 없다.

컴포지션 — 상속의 안전한 대안

상속 대신 포함(has-a) 관계로 설계하면 이 문제를 피할 수 있다.

public class MyHashSet<E> {
 private final HashSet<E> set = new HashSet<>(); // 상속 대신 포함
 private int addCount = 0;

 public boolean add(E e) {
 addCount++;
 return set.add(e); // HashSet에 위임
 }

 public boolean addAll(Collection<? extends E> c) {
 addCount += c.size();
 return set.addAll(c); // HashSet 내부 구현에 의존하지 않음
 }
}

언제 상속, 언제 컴포지션?

상속을 쓸 때:
 - "is-a" 관계가 명확할 때 (Dog is an Animal)
 - 부모 클래스를 내가 직접 만들고 제어할 때
 - 다형성이 필요할 때

컴포지션을 쓸 때:
 - 코드 재사용만이 목적일 때
 - 외부 라이브러리 클래스를 확장할 때
 - 여러 클래스의 기능을 조합할 때

final — 상속을 막을 때

public final class String { } // 상속 불가 — Java String이 final인 이유

public class Parent {
 public final void fixedMethod() { } // 오버라이딩 불가
}

String이 final인 이유는 누군가 String을 상속해서 equals() 동작을 바꿔버리면 Java 전체가 무너지기 때문이다.

마치며

상속은 강력하지만 남용하면 오히려 코드가 취약해진다. “is-a 관계가 명확하고, 부모 클래스를 직접 제어할 수 있을 때"만 상속을 쓰고, 그 외에는 컴포지션을 고려하는 게 좋다.

다음 편에서는 다형성을 더 유연하게 활용하는 방법인 인터페이스와 추상 클래스를 다룬다.

Java 클래스와 객체 — 접근 제어자, static, 불변 객체까지

Fri, 12 Jun 2026 00:00:00 +0900

클래스는 설계도, 객체는 실체다

Java를 처음 배울 때 “클래스는 설계도고 객체는 그 설계도로 찍어낸 결과물"이라는 설명을 들었을 것이다. 맞는 말이지만 그게 실무에서 어떤 의미인지는 코드를 좀 써봐야 느낀다.

클래스를 잘 설계한다는 건 세 가지를 잘 결정하는 것이다. 무엇을 숨기고, 어떻게 초기화하며, 무엇을 공유할지.

접근 제어자 — 무엇을 숨길 것인가

Java에는 4가지 접근 제어자가 있다.

제어자	같은 클래스	같은 패키지	자식 클래스	외부
`public`	✅	✅	✅	✅
`protected`	✅	✅	✅	❌
(없음)	✅	✅	❌	❌
`private`	✅	❌	❌	❌

실무에서 지키는 원칙은 단순하다.

// ❌ 필드를 public으로 열어두면 외부에서 제약 없이 수정 가능
public class BankAccount {
 public int balance = 1000;
}
account.balance = -9999; // 막을 방법이 없다

// ✅ private으로 숨기고, 메서드로 검증
public class BankAccount {
 private int balance;

 public void deposit(int amount) {
 if (amount <= 0) throw new IllegalArgumentException("금액은 0보다 커야 합니다");
 balance += amount;
 }

 public int getBalance() { return balance; }
}

필드는 private, 외부에 노출할 메서드만 public으로 선언하는 게 기본이다.

생성자 — 어떻게 초기화할 것인가

생성자는 객체가 만들어지는 순간 실행된다. 잘못된 상태로 객체가 만들어지는 걸 막는 첫 번째 방어선이다.

public class Order {
 private final Long id;
 private String status;
 private final LocalDateTime createdAt;

 public Order(Long id) {
 if (id == null) throw new IllegalArgumentException("id는 필수입니다");
 this.id = id;
 this.status = "PENDING";
 this.createdAt = LocalDateTime.now();
 }
}

필드가 많아지면 생성자 인자가 길어져 가독성이 떨어진다. 이럴 때 빌더 패턴을 쓴다.

// 인자 순서를 외워야 하는 생성자
new User(1L, "홍길동", 30, "서울", "개발자", true);

// 빌더 — 무엇을 세팅하는지 명확
User user = User.builder()
 .id(1L)
 .name("홍길동")
 .age(30)
 .build();

Lombok의 @Builder를 쓰면 직접 구현할 필요 없이 쓸 수 있다.

static — 무엇을 공유할 것인가

static은 인스턴스 없이 클래스에 붙어있는 것들이다.

public class Counter {
 private static int total = 0; // 모든 인스턴스가 공유
 private int count = 0; // 인스턴스마다 독립

 public void increment() {
 count++;
 total++;
 }
}

Counter a = new Counter();
Counter b = new Counter();
a.increment(); a.increment();
b.increment();

System.out.println(Counter.total); // 3
System.out.println(a.count); // 2
System.out.println(b.count); // 1

static을 쓰기 적합한 경우는 명확하다.

✅ 유틸리티 메서드: Math.abs(), Collections.sort()
✅ 상수: static final MAX_SIZE = 100
✅ 팩토리 메서드: LocalDate.of(2026, 6, 13)

❌ 상태(가변 필드)를 static으로 → 멀티스레드 위험
❌ 서비스 로직을 static으로 → 테스트 어렵고 DI 불가

불변 객체 — 한번 만들면 바뀌지 않는다

불변 객체(Immutable Object)는 한번 생성하면 상태가 바뀌지 않는 객체다. 만드는 방법은 간단하다.

public final class Money { // 1. 상속 막기 (final class)
 private final int amount; // 2. 필드를 final로
 private final String currency;

 public Money(int amount, String currency) {
 if (amount < 0) throw new IllegalArgumentException();
 this.amount = amount;
 this.currency = currency;
 }

 // 3. setter 없음
 // 4. 변경 필요시 새 객체 반환
 public Money add(Money other) {
 return new Money(this.amount + other.amount, this.currency);
 }
}

불변 객체가 왜 좋은가?

스레드 안전 → 상태가 안 바뀌니 동기화 불필요
부작용 없음 → 메서드 호출이 외부에 영향을 안 줌
추론 쉬움 → 값이 바뀌지 않으니 버그 추적이 단순해짐

컬렉션 필드가 있을 때는 방어적 복사를 해야 한다.

public class Team {
 private final List<String> members;

 public Team(List<String> members) {
 this.members = new ArrayList<>(members); // 외부 리스트와 분리
 }

 public List<String> getMembers() {
 return Collections.unmodifiableList(members); // 읽기 전용으로 반환
 }
}

equals와 hashCode는 항상 함께

HashMap, HashSet에서 객체를 키로 쓰려면 equals와 hashCode를 둘 다 오버라이드해야 한다.

@Override
public boolean equals(Object o) {
 if (this == o) return true;
 if (!(o instanceof Money)) return false;
 Money other = (Money) o;
 return amount == other.amount && currency.equals(other.currency);
}

@Override
public int hashCode() {
 return Objects.hash(amount, currency);
}

규칙: equals()가 true이면 hashCode()도 같아야 한다. 하나만 오버라이드하면 HashMap에서 오동작한다.

마치며

클래스 설계에서 기억할 것 세 가지: 필드는 private으로 숨기고, 생성자에서 유효성을 검증하며, 변경 필요 없는 객체는 불변으로 만든다. 이 세 가지를 지키는 것만으로도 버그가 줄고 코드가 읽기 쉬워진다.

다음 편에서는 클래스 간의 관계, 상속과 다형성을 다룬다.

[Java 객체지향 실전 #6] 이 코드, 어느 계층에 있어야 할까? — Spring 계층별 책임 분리

Wed, 27 May 2026 00:00:00 +0900

이런 코드 본 적 있지 않나요?

코드 리뷰를 하다 보면 자주 마주치는 장면이 있다.

OrderController에 잔액 검증 로직이 있고, OrderService에 JPQL 쿼리가 직접 박혀있고, Order 엔티티는 @Getter @Setter만 있는 데이터 덩어리다.

각각 따로 보면 “뭐, 작동은 하잖아"라고 넘어갈 수 있다. 그런데 프로젝트가 6개월, 1년 지나면 이 결정들의 대가를 치르게 된다. 할인 로직을 바꾸려는데 Controller 3개를 열어야 하고, Service 테스트를 짜려는데 Mock이 5개 필요하다.

계층별 책임 한눈에 보기

Spring의 레이어드 아키텍처에서 각 계층이 가져야 할 책임과 가지면 안 되는 것들이 있다.

┌───────────────────────────────────────────────────────┐
│ Controller │ 요청/응답 직렬화, 인증/인가 확인 │
│ │ ❌ 비즈니스 로직 절대 금지 │
├───────────────────────────────────────────────────────┤
│ Service │ 유스케이스 조율, 트랜잭션 경계 │
│ │ ❌ DB 쿼리 직접 작성 금지 │
├───────────────────────────────────────────────────────┤
│ Domain │ 핵심 비즈니스 규칙, 상태 변경, 불변식 │
│ (Entity) │ ❌ 인프라/외부 의존 절대 금지 │
├───────────────────────────────────────────────────────┤
│ Repository │ 영속성 관심사만 │
│ │ ❌ 비즈니스 로직 금지 │
└───────────────────────────────────────────────────────┘

하나씩 살펴보자.

Controller 계층

책임

HTTP 요청을 도메인 객체/커맨드로 변환
서비스 호출 결과를 HTTP 응답으로 직렬화
@PreAuthorize 등으로 인증/인가 확인
입력값 기본 검증 (@Valid)

나쁜 코드: 비즈니스 로직이 Controller에 있다

@RestController
@RequiredArgsConstructor
public class OrderController {

 private final OrderRepository orderRepository; // ❌ Repository 직접 접근
 private final UserRepository userRepository;

 @PostMapping("/orders")
 public ResponseEntity<OrderResponse> createOrder(
 @RequestBody OrderCreateRequest request,
 @AuthenticationPrincipal UserPrincipal principal
 ) {
 User user = userRepository.findById(principal.getId()).orElseThrow();

 // ❌ 비즈니스 로직이 Controller에 있음
 if (user.getBalance() < request.getTotalAmount()) {
 throw new InsufficientBalanceException("잔액 부족");
 }

 Order order = new Order(user, request.getItems(), request.getTotalAmount());
 orderRepository.save(order);

 user.setBalance(user.getBalance() - request.getTotalAmount()); // ❌ 잔액 차감 로직
 userRepository.save(user);

 return ResponseEntity.ok(OrderResponse.from(order));
 }
}

이 잔액 검증 로직을 나중에 모바일 API에서도 써야 한다면? 복사해야 한다. 검증 기준이 바뀌면 두 곳을 찾아야 한다.

좋은 코드: Controller는 변환과 위임만

@RestController
@RequiredArgsConstructor
public class OrderController {

 private final OrderService orderService;

 @PostMapping("/orders")
 @PreAuthorize("isAuthenticated()") // 인가는 Controller 책임
 public ResponseEntity<OrderResponse> createOrder(
 @RequestBody @Valid OrderCreateRequest request,
 @AuthenticationPrincipal UserPrincipal principal
 ) {
 // 요청 역직렬화 → 서비스 호출 → 응답 직렬화만 담당
 OrderCreateCommand command = request.toCommand(principal.getId());
 Order order = orderService.createOrder(command);
 return ResponseEntity.ok(OrderResponse.from(order));
 }
}

DTO에 변환 책임을 주면 Controller 코드가 더 간결해진다.

public record OrderCreateRequest(
 @NotNull Long productId,
 @Min(1) Integer quantity,
 Long couponId
) {
 // DTO → Command 변환 책임을 DTO 자체에 위임
 public OrderCreateCommand toCommand(Long userId) {
 return new OrderCreateCommand(userId, productId, quantity, couponId);
 }
}

public record OrderResponse(
 Long orderId,
 String status,
 Long totalAmount,
 LocalDateTime createdAt
) {
 public static OrderResponse from(Order order) {
 return new OrderResponse(
 order.getId(),
 order.getStatus().name(),
 order.getTotalAmount(),
 order.getCreatedAt()
 );
 }
}

Service 계층

책임

유스케이스 조율: 도메인 객체와 Repository를 조합해 비즈니스 흐름 구성
트랜잭션 경계 선언 (@Transactional)
이벤트 발행

나쁜 코드: SQL 로직이 Service에 있다

@Service
@RequiredArgsConstructor
@Transactional
public class OrderService {

 private final EntityManager em;

 public List<Order> getRecentOrders(Long userId) {
 // ❌ JPQL 쿼리가 Service에 직접 있음
 return em.createQuery(
 "SELECT o FROM Order o WHERE o.userId = :userId " +
 "AND o.createdAt >= :since " +
 "ORDER BY o.createdAt DESC",
 Order.class
 )
 .setParameter("userId", userId)
 .setParameter("since", LocalDateTime.now().minusDays(30))
 .getResultList();
 }

 public void completeOrder(Long orderId) {
 Order order = em.find(Order.class, orderId);

 // ❌ 비즈니스 규칙이 Service에 있음 (도메인 객체가 처리해야 함)
 if (!order.getStatus().equals(OrderStatus.PAYMENT_COMPLETED)) {
 throw new InvalidOrderStatusException("결제 완료 상태에서만 주문 확정 가능");
 }
 order.setStatus(OrderStatus.CONFIRMED);
 order.setConfirmedAt(LocalDateTime.now());
 }
}

좋은 코드: Service는 흐름만 조율한다

@Service
@RequiredArgsConstructor
@Transactional
public class OrderService {

 private final OrderRepository orderRepository;
 private final UserRepository userRepository;
 private final ApplicationEventPublisher eventPublisher;

 // 유스케이스: 주문 생성 흐름 조율
 public Order createOrder(OrderCreateCommand command) {
 User user = userRepository.findById(command.userId())
 .orElseThrow(() -> new UserNotFoundException(command.userId()));

 Product product = productRepository.findById(command.productId())
 .orElseThrow(() -> new ProductNotFoundException(command.productId()));

 // 비즈니스 로직은 도메인 객체에게 위임
 Order order = Order.create(user, product, command.quantity());

 orderRepository.save(order);

 eventPublisher.publishEvent(OrderCreatedEvent.from(order));

 return order;
 }

 // 유스케이스: 주문 확정
 public Order confirmOrder(Long orderId) {
 Order order = orderRepository.findById(orderId)
 .orElseThrow(() -> new OrderNotFoundException(orderId));

 // 상태 전이 규칙은 도메인 객체가 안다
 order.confirm();

 return order; // JPA dirty checking으로 자동 저장
 }

 // 쿼리는 Repository에 위임
 @Transactional(readOnly = true)
 public List<Order> getRecentOrders(Long userId) {
 return orderRepository.findRecentByUserId(userId, LocalDateTime.now().minusDays(30));
 }
}

Domain/Entity 계층

책임

핵심 비즈니스 규칙 (“주문은 결제 완료 상태에서만 확정 가능하다”)
불변식 유지 (도메인 객체가 항상 유효한 상태임을 보장)
값 계산 (총 금액, 할인 금액 등)

나쁜 코드: 엔티티가 데이터 덩어리에 불과하다

@Entity
@Getter
@Setter // ❌ setter 전부 공개 — 불변식 보장 불가
public class Order {
 @Id @GeneratedValue
 private Long id;
 private Long userId;
 private OrderStatus status;
 private Long totalAmount;
 // ❌ 비즈니스 메서드 없음 — 로직이 Service로 흘러나감
}

이 엔티티는 상태를 바꾸는 규칙을 하나도 모른다. setStatus(OrderStatus.CONFIRMED)를 결제 전에 호출해도 막을 방법이 없다.

좋은 코드: 도메인 객체가 규칙을 수행한다

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED) // JPA용 기본 생성자만 허용
public class Order {

 @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
 private Long id;

 @Enumerated(EnumType.STRING)
 private OrderStatus status;

 private Long totalAmount;
 private LocalDateTime confirmedAt;

 // 팩토리 메서드: 유효한 초기 상태 보장
 public static Order create(User user, Product product, int quantity) {
 product.validateStock(quantity); // 재고 확인도 도메인 규칙

 Order order = new Order();
 order.status = OrderStatus.CREATED;
 order.totalAmount = product.calculatePrice(quantity);
 return order;
 }

 // 상태 전이: 비즈니스 규칙을 도메인 객체가 직접 수행
 public void confirm() {
 validateStatusIs(OrderStatus.PAYMENT_COMPLETED, "결제 완료 상태에서만 주문 확정 가능");
 this.status = OrderStatus.CONFIRMED;
 this.confirmedAt = LocalDateTime.now();
 }

 public void cancel() {
 if (this.status == OrderStatus.SHIPPED || this.status == OrderStatus.DELIVERED) {
 throw new OrderCancellationException("배송 후에는 취소 불가");
 }
 this.status = OrderStatus.CANCELLED;
 }

 // 값 계산: 도메인 객체 내부에서 처리
 public long calculateDiscountedAmount(Coupon coupon) {
 return coupon.apply(this.totalAmount);
 }

 private void validateStatusIs(OrderStatus expected, String message) {
 if (this.status != expected) {
 throw new InvalidOrderStatusException(message + " (현재: " + this.status + ")");
 }
 }
}

order.confirm()을 호출하면, 상태가 맞지 않으면 스스로 예외를 던진다. Service가 알 필요 없다.

Repository 계층

책임

영속성 관심사만 (DB 저장/조회/삭제)
복잡한 쿼리를 메서드 뒤로 캡슐화
도메인 언어로 메서드 이름 표현

나쁜 코드: 비즈니스 판단이 Repository에 있다

@Repository
public class OrderRepository {

 // ❌ 배송 자격 비즈니스 규칙이 Repository에 하드코딩
 public List<Order> findOrdersEligibleForShipping() {
 return em.createQuery(
 "SELECT o FROM Order o WHERE o.status = 'CONFIRMED' " +
 "AND o.totalAmount >= 50000 " + // 무료배송 기준이 Repository에 있음
 "AND o.user.grade = 'VIP'", // VIP 조건이 Repository에 있음
 Order.class
 ).getResultList();
 }
}

무료배송 기준이 50,000원에서 30,000원으로 바뀌면 Repository를 찾아가야 한다. 비즈니스 기준이 왜 DB 접근 코드 안에 있는 걸까?

좋은 코드: Repository는 조회만, 기준값은 파라미터로

public interface OrderRepository extends JpaRepository<Order, Long> {

 List<Order> findByUserIdAndStatus(Long userId, OrderStatus status);

 // 비즈니스 기준값은 파라미터로 받음 — 기준 결정은 Service/Domain 책임
 @Query("SELECT o FROM Order o WHERE o.userId = :userId AND o.createdAt >= :since")
 List<Order> findRecentByUserId(
 @Param("userId") Long userId,
 @Param("since") LocalDateTime since
 );

 Page<Order> findByUserIdOrderByCreatedAtDesc(Long userId, Pageable pageable);
}

// 복잡한 동적 쿼리는 QueryDSL로 분리
@Repository
@RequiredArgsConstructor
public class OrderQueryRepository {

 private final JPAQueryFactory queryFactory;

 public List<Order> findOrdersForShipping(OrderShippingCondition condition) {
 // 배송 대상 조건은 Service가 결정해서 파라미터로 전달
 return queryFactory
 .selectFrom(order)
 .where(
 order.status.eq(OrderStatus.CONFIRMED),
 condition.getMinAmount() != null
 ? order.totalAmount.goe(condition.getMinAmount())
 : null
 )
 .fetch();
 }
}

“이 코드 어디에 넣어야 하지?” 판단 기준

코드를 작성할 때 이 질문을 순서대로 던져보면 계층이 명확해진다.

1. HTTP, JSON과 관련 있는가?
 → YES: Controller

2. 도메인 규칙인가? (불변식, 상태 전이, 값 계산)
 "이 규칙이 DB나 프레임워크 없이도 성립하는가?"
 → YES: Domain/Entity

3. DB에 저장하거나 조회하는 코드인가?
 → YES: Repository

4. 여러 도메인 객체/Repository를 조합하는 흐름인가?
 → YES: Service

질문	속하는 계층
이 사용자가 이 요청을 할 수 있나?	Controller
주문 총 금액은 어떻게 계산하나?	Domain
결제 완료된 주문만 확정 가능하다	Domain
최근 30일 주문을 가져온다	Repository
주문 생성 시 포인트를 적립한다	Service
트랜잭션 경계를 어디에 둘까?	Service

흔한 계층 위반 패턴 세 가지

안티패턴 1: Fat Controller — 비즈니스 로직이 Controller에

// ❌ 할인 조건이 Controller에
@PostMapping("/discount")
public ResponseEntity<OrderResponse> applyDiscount(...) {
 if (order.getTotalAmount() > 100000) {
 order.setDiscountAmount(order.getTotalAmount() * 0.1);
 }
}

// ✅ Domain 메서드로 이동
order.applyVolumeDiscount();

안티패턴 2: Anemic Domain Model — 엔티티가 setter만 가진 데이터 구조체

// ❌ 상태 변경 규칙이 없음
order.setStatus(OrderStatus.CONFIRMED);
order.setConfirmedAt(LocalDateTime.now());

// ✅ 도메인 메서드로 상태 전이
order.confirm();

안티패턴 3: Smart Repository — 비즈니스 규칙이 Repository에

// ❌ 비즈니스 기준이 Repository에
List<Order> eligibleOrders = orderRepository.findEligibleForVipDiscount();

// ✅ Service에서 조건 결정, Repository는 조회만
List<Order> confirmedOrders = orderRepository.findByStatus(OrderStatus.CONFIRMED);
List<Order> eligibleOrders = confirmedOrders.stream()
 .filter(Order::isEligibleForVipDiscount) // 도메인 메서드
 .collect(toList());

언제부터 리팩토링해야 할까?

계층 책임 분리는 처음엔 “이 정도 프로젝트에 이게 필요한가?” 싶을 수 있다. 하지만 징후가 보이기 시작하면 미루면 안 된다.

Service 메서드가 100줄을 넘기 시작하면 → Domain 계층으로 로직을 내려야 한다는 신호
Controller에서 여러 Repository를 직접 접근하면 → Service 계층으로 올려야 한다는 신호
단위 테스트에 Mock이 5개 이상 필요하면 → 계층 분리가 안 된 것

계층 책임 분리가 없는 코드베이스는 프로젝트가 커질수록 변경 비용이 기하급수적으로 늘어난다. 이 규칙은 “좋은 코드를 위해” 지키는 게 아니라, “미래의 내가 편하게 일하기 위해” 지키는 것이다.

마치며

계층 분리의 핵심은 단 하나 — 각 계층이 자신의 관심사만 가질 때, 변경이 한 곳에만 영향을 준다.

[Java 객체지향 실전 #5] 주문 완료 후 해야 할 일이 자꾸 늘어난다면 — Spring 이벤트로 의존성 끊기

Mon, 25 May 2026 00:00:00 +0900

이런 코드 본 적 있지 않나요?

주문 완료 기능을 처음 만들 땐 단순했다. 주문 저장하고 끝.

그런데 시간이 지나면서 이렇게 변한다.

public Order completeOrder(Long orderId) {
 order.complete();
 orderRepository.save(order);

 notificationService.sendOrderCompleteNotification(order); // 기획: 알림 추가
 pointService.addPoints(order.getUserId(), order.getAmount()); // 기획: 포인트 적립
 couponService.useOrderCoupon(order.getCouponId()); // 기획: 쿠폰 처리
 inventoryService.decreaseStock(order.getItems()); // 기획: 재고 차감

 return order;
}

다음 주에 “배송 예약도 여기서 해주세요"라는 요청이 오면, OrderService를 다시 열고 한 줄 더 추가해야 한다.

OrderService가 알아야 할 다른 서비스들이 끝없이 늘어난다. 이게 문제다.

나쁜 코드: 강결합의 전형

@Service
@RequiredArgsConstructor
@Transactional
public class OrderService {

 private final OrderRepository orderRepository;
 private final NotificationService notificationService; // 직접 의존
 private final PointService pointService; // 직접 의존
 private final CouponService couponService; // 직접 의존
 private final InventoryService inventoryService; // 직접 의존

 public Order completeOrder(Long orderId) {
 Order order = orderRepository.findById(orderId)
 .orElseThrow(() -> new OrderNotFoundException(orderId));

 order.complete();
 orderRepository.save(order);

 // 주문 완료 후 해야 할 일들 — 비즈니스가 커질수록 여기에 계속 추가됨
 notificationService.sendOrderCompleteNotification(order);
 pointService.addPoints(order.getUserId(), order.getAmount());
 couponService.useOrderCoupon(order.getCouponId());
 inventoryService.decreaseStock(order.getItems());

 return order;
 }
}

이 코드의 문제는 세 가지다.

첫째, OCP 위반. 새 기능이 추가될 때마다 OrderService를 수정해야 한다. “주문 완료"라는 개념이 변하지 않았는데도.

둘째, 테스트 어려움. OrderService 단위 테스트를 작성하려면 NotificationService, PointService, CouponService, InventoryService를 전부 Mock으로 만들어야 한다.

셋째, 트랜잭션 오염. 알림 서비스에서 예외가 나면 주문 저장까지 롤백된다. 알림 실패 때문에 주문 자체가 취소되는 황당한 상황이 생길 수 있다.

Spring Event로 의존성을 역전한다

핵심 아이디어는 이렇다.

OrderService는 “주문이 완료됐다"는 사실만 발행한다. 그 이후에 무슨 일이 일어나는지는 관심 없다.

1단계: 이벤트 클래스 정의

이벤트는 발생한 사실을 담는 불변 값 객체다.

// Java record로 불변 이벤트 정의
public record OrderCompletedEvent(
 Long orderId,
 Long userId,
 Long amount,
 Long couponId,
 List<OrderItem> items,
 LocalDateTime completedAt
) {
 public static OrderCompletedEvent from(Order order) {
 return new OrderCompletedEvent(
 order.getId(),
 order.getUserId(),
 order.getTotalAmount(),
 order.getCouponId(),
 order.getItems(),
 order.getCompletedAt()
 );
 }
}

2단계: OrderService는 이벤트만 발행

@Service
@RequiredArgsConstructor
@Transactional
public class OrderService {

 private final OrderRepository orderRepository;
 private final ApplicationEventPublisher eventPublisher; // 유일한 의존성

 public Order completeOrder(Long orderId) {
 Order order = orderRepository.findById(orderId)
 .orElseThrow(() -> new OrderNotFoundException(orderId));

 order.complete();
 orderRepository.save(order);

 // 이벤트 발행 — 누가 처리할지 전혀 모름
 eventPublisher.publishEvent(OrderCompletedEvent.from(order));

 return order;
 }
}

NotificationService도 없고, PointService도 없다. ApplicationEventPublisher 하나만 주입받는다.

3단계: 각 서비스가 독립적으로 구독

// 알림 핸들러 — OrderService를 전혀 모른다
@Component
@RequiredArgsConstructor
public class OrderNotificationHandler {

 private final NotificationService notificationService;

 @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
 public void handleOrderCompleted(OrderCompletedEvent event) {
 notificationService.sendOrderCompleteNotification(event.userId(), event.orderId());
 }
}

// 포인트 핸들러 — OrderService를 전혀 모른다
@Component
@RequiredArgsConstructor
public class PointEventHandler {

 private final PointService pointService;

 @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
 public void handleOrderCompleted(OrderCompletedEvent event) {
 pointService.addPoints(event.userId(), event.amount());
 }
}

// 쿠폰 핸들러
@Component
@RequiredArgsConstructor
public class CouponEventHandler {

 private final CouponService couponService;

 @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
 public void handleOrderCompleted(OrderCompletedEvent event) {
 if (event.couponId() != null) {
 couponService.markAsUsed(event.couponId());
 }
 }
}

이제 배송 예약 기능을 추가해야 한다면? OrderService 코드는 한 줄도 바꾸지 않고 ShippingEventHandler를 새로 만들기만 하면 된다.

@EventListener vs @TransactionalEventListener

처음 이벤트를 도입할 때 가장 먼저 부딪히는 선택이다.

// @EventListener: 이벤트 발행 즉시 실행
// 주문 트랜잭션이 아직 열려 있는 상태에서 핸들러가 실행됨
// → 핸들러에서 예외 발생 시 주문 트랜잭션도 함께 롤백됨
@EventListener
public void handleOrderCompleted(OrderCompletedEvent event) {
 pointService.addPoints(event.userId(), event.amount());
}

// @TransactionalEventListener: 트랜잭션 커밋 후 실행
// 주문 완료가 DB에 영구 반영된 후에 핸들러 실행
// → 핸들러 실패가 주문 트랜잭션에 영향 없음
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handleOrderCompleted(OrderCompletedEvent event) {
 pointService.addPoints(event.userId(), event.amount());
}

구분	@EventListener	@TransactionalEventListener
실행 시점	이벤트 발행 즉시	트랜잭션 커밋 후
트랜잭션 참여	발행자 트랜잭션에 참여	새 트랜잭션(기본)
핸들러 예외 영향	발행자 트랜잭션 롤백	발행자 트랜잭션 영향 없음
주 용도	같은 트랜잭션 내 처리	외부 연동, 알림, 통계

대부분의 경우 @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)이 정답이다. 주문이 DB에 커밋된 후에 포인트를 적립해야 의미 있다.

TransactionPhase는 네 가지가 있다.

// AFTER_COMMIT: 커밋 성공 후 (가장 많이 사용)
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)

// AFTER_ROLLBACK: 롤백 후 (실패 알림, 보상 트랜잭션 등)
@TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)

// AFTER_COMPLETION: 커밋/롤백 모두 후 (리소스 정리 등)
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMPLETION)

// BEFORE_COMMIT: 커밋 직전 (감사 로그 등)
@TransactionalEventListener(phase = TransactionPhase.BEFORE_COMMIT)

알림 발송은 비동기로

알림 발송이나 외부 API 호출은 시간이 걸린다. 이런 작업을 동기로 처리하면 주문 완료 API의 응답 시간이 늘어난다. @Async를 조합하면 된다.

// 비동기 활성화
@SpringBootApplication
@EnableAsync
public class Application { ... }

// 전용 스레드풀 설정 (기본 SimpleAsyncTaskExecutor는 프로덕션 부적합)
@Configuration
public class AsyncConfig {

 @Bean(name = "eventTaskExecutor")
 public Executor eventTaskExecutor() {
 ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
 executor.setCorePoolSize(5);
 executor.setMaxPoolSize(20);
 executor.setQueueCapacity(100);
 executor.setThreadNamePrefix("event-");
 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
 executor.initialize();
 return executor;
 }
}

// 비동기 핸들러
@Component
@RequiredArgsConstructor
@Slf4j
public class OrderNotificationHandler {

 private final NotificationService notificationService;

 @Async("eventTaskExecutor")
 @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
 public void handleOrderCompleted(OrderCompletedEvent event) {
 try {
 notificationService.sendOrderCompleteNotification(event.userId(), event.orderId());
 } catch (Exception e) {
 // @Async 사용 시 예외가 호출자에게 전파되지 않으므로 명시적 로깅 필수
 log.error("주문 완료 알림 발송 실패. orderId={}", event.orderId(), e);
 }
 }
}

@Async를 쓸 때 주의할 점이 있다. 예외가 호출 스레드로 전파되지 않기 때문에, 핸들러 내부에서 반드시 예외를 잡아 로그를 남겨야 한다. 그렇지 않으면 알림 발송 실패가 조용히 묻혀버린다.

이 구조가 동작하는 방식

OrderService Spring Event Bus
(발행자) (중간 브로커)
 │ │
 │─── publishEvent(event) ──────>│
 │ │──> OrderNotificationHandler
 │ │──> PointEventHandler
 │ │──> CouponEventHandler
 │ │──> (미래에 추가될 핸들러들...)

OrderService는 OrderCompletedEvent만 발행하면 된다. 누가 구독하는지 알 필요가 없다.

한계: 이 방법이 맞지 않는 경우

Spring 기본 이벤트는 같은 JVM 안에서만 동작한다. 마이크로서비스 간 통신에는 Kafka나 RabbitMQ 같은 메시지 브로커가 필요하다.

그리고 이벤트 핸들러 간 실행 순서는 보장되지 않는다. 포인트 적립이 쿠폰 처리보다 반드시 먼저 돼야 한다는 순서 의존성이 있다면, 이벤트 방식보다는 다른 방법을 고려해야 한다.

마치며

Spring 이벤트의 핵심은 발행자는 구독자를 모른다 — OrderService가 달라지지 않아도 새 기능을 추가할 수 있다면, 그게 진짜 OCP다.

[Java 객체지향 실전 #4] 카카오, 네이버, 구글... API 클라이언트 코드가 계속 늘어난다면

Sat, 23 May 2026 00:00:00 +0900

이런 코드 본 적 있지 않나요?

소셜 로그인을 붙이다 보면 어느 순간 이런 상황이 온다.

KakaoApiClient에 인증 헤더 붙이고, 요청 실행하고, 에러 처리하고, 응답 파싱하는 코드를 짜고 나서 — NaverApiClient를 만들 차례가 됐는데 Ctrl+C, Ctrl+V가 손에서 멈추지 않는다.

엔드포인트만 다르고, 파싱 방식만 살짝 다를 뿐인데, 나머지 코드는 거의 동일하다.

문제는 내일 구글 로그인을 추가해야 할 때다. 또 같은 코드를 복사해야 한다.

나쁜 코드: 흐름이 복사된다

// 카카오 API 클라이언트
public class KakaoApiClient {

 public KakaoUserInfo fetchUserInfo(String accessToken) {
 // 중복 1: 인증 헤더 추가
 HttpHeaders headers = new HttpHeaders();
 headers.setBearerAuth(accessToken);
 headers.setContentType(MediaType.APPLICATION_JSON);

 HttpEntity<Void> request = new HttpEntity<>(headers);

 // 중복 2: 요청 실행
 ResponseEntity<String> response;
 try {
 response = restTemplate.exchange(
 "https://kapi.kakao.com/v2/user/me",
 HttpMethod.GET,
 request,
 String.class
 );
 } catch (HttpClientErrorException e) {
 // 중복 3: 에러 처리
 if (e.getStatusCode() == HttpStatus.UNAUTHORIZED) {
 throw new TokenExpiredException("카카오 토큰 만료");
 }
 throw new ExternalApiException("카카오 API 오류: " + e.getMessage());
 }

 // 중복 4: 응답 파싱 (카카오 전용)
 return objectMapper.readValue(response.getBody(), KakaoUserInfo.class);
 }
}

// 네이버 API 클라이언트 — 거의 동일한 코드가 반복됨
public class NaverApiClient {

 public NaverUserInfo fetchUserInfo(String accessToken) {
 HttpHeaders headers = new HttpHeaders();
 headers.setBearerAuth(accessToken);
 headers.setContentType(MediaType.APPLICATION_JSON);

 HttpEntity<Void> request = new HttpEntity<>(headers);

 ResponseEntity<String> response;
 try {
 response = restTemplate.exchange(
 "https://openapi.naver.com/v1/nid/me", // 엔드포인트만 다름
 HttpMethod.GET,
 request,
 String.class
 );
 } catch (HttpClientErrorException e) {
 if (e.getStatusCode() == HttpStatus.UNAUTHORIZED) {
 throw new TokenExpiredException("네이버 토큰 만료");
 }
 throw new ExternalApiException("네이버 API 오류: " + e.getMessage());
 }

 // 파싱 방식만 다름
 NaverApiResponse rawResponse = objectMapper.readValue(response.getBody(), NaverApiResponse.class);
 return rawResponse.getResponse();
 }
}

무엇이 문제일까?

인증 헤더 추가 방식이 바뀌면 KakaoApiClient, NaverApiClient, GoogleApiClient 전부 찾아다니며 수정해야 한다.
에러 처리 정책이 바뀌어도 마찬가지다.
새 OAuth 제공자가 생길 때마다 이 200줄짜리 파일이 그대로 복사된다.

템플릿 메서드 패턴이란?

핵심 아이디어는 간단하다.

“흐름(뼈대)은 상위 클래스에 고정하고, 달라지는 부분만 하위 클래스에 위임한다.”

인증 헤더 추가 → 요청 실행 → 에러 처리 → 응답 파싱, 이 4단계 흐름은 모든 API 클라이언트가 동일하다. 달라지는 건 엔드포인트와 파싱 방식뿐이다.

좋은 코드: AbstractApiClient로 흐름 고정

// 템플릿 메서드를 정의하는 추상 클래스
public abstract class AbstractApiClient {

 private final RestTemplate restTemplate;
 private final ObjectMapper objectMapper;

 protected AbstractApiClient(RestTemplate restTemplate, ObjectMapper objectMapper) {
 this.restTemplate = restTemplate;
 this.objectMapper = objectMapper;
 }

 // 템플릿 메서드: 흐름이 고정됨 (final로 오버라이드 방지)
 public final <T> T fetch(String accessToken, Class<T> responseType) {
 // 흐름 1: 인증 헤더 추가 (공통)
 HttpHeaders headers = buildAuthHeaders(accessToken);
 HttpEntity<Void> request = new HttpEntity<>(headers);

 // 흐름 2: 요청 실행 (공통)
 ResponseEntity<String> response = executeRequest(request);

 // 흐름 3: 에러 처리 (공통)
 validateResponse(response);

 // 흐름 4: 응답 파싱 (하위 클래스가 결정)
 return parseResponse(response.getBody(), responseType);
 }

 // 훅 메서드: 기본 구현 있음, 필요시 오버라이드 가능
 protected HttpHeaders buildAuthHeaders(String accessToken) {
 HttpHeaders headers = new HttpHeaders();
 headers.setBearerAuth(accessToken);
 headers.setContentType(MediaType.APPLICATION_JSON);
 return headers;
 }

 protected void validateResponse(ResponseEntity<String> response) {
 if (response.getStatusCode() == HttpStatus.UNAUTHORIZED) {
 throw new TokenExpiredException(getProviderName() + " 토큰 만료");
 }
 if (!response.getStatusCode().is2xxSuccessful()) {
 throw new ExternalApiException(getProviderName() + " API 오류: " + response.getStatusCode());
 }
 }

 // 추상 메서드: 하위 클래스가 반드시 구현
 protected abstract String getEndpoint();
 protected abstract String getProviderName();

 // 훅 메서드: 기본 파싱, 필요시 오버라이드
 protected <T> T parseResponse(String body, Class<T> responseType) {
 try {
 return objectMapper.readValue(body, responseType);
 } catch (JsonProcessingException e) {
 throw new ExternalApiException("응답 파싱 실패: " + e.getMessage());
 }
 }

 private ResponseEntity<String> executeRequest(HttpEntity<Void> request) {
 try {
 return restTemplate.exchange(
 getEndpoint(),
 HttpMethod.GET,
 request,
 String.class
 );
 } catch (HttpClientErrorException e) {
 validateResponse(ResponseEntity.status(e.getStatusCode()).body(e.getResponseBodyAsString()));
 throw e;
 }
 }
}

이제 각 클라이언트는 “나만 다른 부분"만 구현하면 된다.

// 카카오: 엔드포인트와 이름만 반환
@Component
public class KakaoApiClient extends AbstractApiClient {

 public KakaoApiClient(RestTemplate restTemplate, ObjectMapper objectMapper) {
 super(restTemplate, objectMapper);
 }

 @Override
 protected String getEndpoint() {
 return "https://kapi.kakao.com/v2/user/me";
 }

 @Override
 protected String getProviderName() {
 return "카카오";
 }

 public KakaoUserInfo fetchUserInfo(String accessToken) {
 return fetch(accessToken, KakaoUserInfo.class);
 }
}

// 네이버: 응답 구조가 다르니 parseResponse만 오버라이드
@Component
public class NaverApiClient extends AbstractApiClient {

 @Override
 protected String getEndpoint() {
 return "https://openapi.naver.com/v1/nid/me";
 }

 @Override
 protected String getProviderName() {
 return "네이버";
 }

 // 네이버는 {"resultcode": "00", "response": {...}} 구조라 래퍼 벗기기 필요
 @Override
 protected <T> T parseResponse(String body, Class<T> responseType) {
 NaverApiResponse wrapper = super.parseResponse(body, NaverApiResponse.class);
 return objectMapper.convertValue(wrapper.getResponse(), responseType);
 }

 public NaverUserInfo fetchUserInfo(String accessToken) {
 return fetch(accessToken, NaverUserInfo.class);
 }
}

구글을 추가해야 한다면? AbstractApiClient를 상속받아 getEndpoint()와 getProviderName()만 구현하면 된다. 기존 파일은 손댈 필요가 없다.

추상 메서드 vs 훅 메서드

이 패턴을 쓸 때 구분해야 할 개념이 있다.

// 추상 메서드: 하위 클래스가 반드시 구현 (구현 안 하면 컴파일 오류)
protected abstract String getEndpoint();

// 훅 메서드: 기본 구현이 있어 오버라이드는 선택
protected void preProcess() {} // 기본: 아무것도 안 함
protected boolean shouldNotify() { // 기본: 항상 알림
 return true;
}

구분	추상 메서드	훅 메서드
구현 강제	O (컴파일 오류)	X (선택적)
기본값	없음	있음
용도	반드시 달라야 하는 부분	대부분 같지만 가끔 달라야 하는 부분

실무 예시: 배치 작업에도 똑같이 쓴다

API 클라이언트뿐 아니라 배치 작업도 흐름이 고정된 경우가 많다.

전처리 → 핵심 처리 → 후처리 → 알림 — 이 흐름을 AbstractBatchJob으로 고정하면, 개별 배치는 핵심 처리 로직에만 집중할 수 있다.

public abstract class AbstractBatchJob {

 // 템플릿 메서드: 배치 실행 흐름 고정
 public final BatchResult execute() {
 logger.start(getJobName());
 try {
 preProcess(); // 훅: 선택적
 BatchResult result = process(); // 추상: 반드시 구현
 postProcess(result); // 훅: 선택적
 if (shouldNotify()) {
 slackNotifier.sendSuccess(getJobName(), result.getSummary());
 }
 return result;
 } catch (Exception e) {
 slackNotifier.sendFailure(getJobName(), e.getMessage());
 throw new BatchJobException(getJobName() + " 실패", e);
 }
 }

 protected abstract String getJobName();
 protected abstract BatchResult process();

 protected void preProcess() {}
 protected void postProcess(BatchResult result) {}
 protected boolean shouldNotify() { return true; }
}

// 만료 쿠폰 정리 배치: 핵심 로직만 작성
@Component
public class ExpiredCouponCleanupJob extends AbstractBatchJob {

 @Override
 protected String getJobName() { return "만료-쿠폰-정리"; }

 @Override
 protected BatchResult process() {
 List<Coupon> expiredCoupons = couponRepository.findExpiredCoupons(LocalDate.now());
 couponRepository.deleteAll(expiredCoupons);
 return BatchResult.of(expiredCoupons.size() + "개 삭제 완료");
 }

 @Override
 protected void preProcess() {
 distributedLock.acquire("expired-coupon-cleanup");
 }

 @Override
 protected void postProcess(BatchResult result) {
 distributedLock.release("expired-coupon-cleanup");
 }
}

슬랙 알림 형식이 바뀌면? AbstractBatchJob만 수정하면 모든 배치에 반영된다.

이 패턴을 써도 되는지 판단하는 기준

템플릿 메서드는 상속을 사용하기 때문에 남용하면 계층이 깊어진다. 언제 써야 하는지 기준을 명확히 해두는 게 좋다.

상속(템플릿 메서드)이 맞는 경우

알고리즘의 흐름이 완전히 동일하고 세부 구현만 다를 때
변형 가능한 지점이 2~3개 이하로 한정될 때

컴포지션(전략 패턴)이 맞는 경우

런타임에 동작을 교체해야 할 때
변형 지점이 많아 상속 계층이 폭발적으로 증가할 것 같을 때
인증 방식 × 파싱 방식처럼 다중 조합이 필요할 때

외부 API 클라이언트처럼 “흐름은 같고 엔드포인트·파싱만 다른” 경우는 템플릿 메서드가 깔끔하다. 반면 결제 수단처럼 완전히 다른 알고리즘을 교체해야 하는 경우는 전략 패턴 쪽이 낫다.

마치며

템플릿 메서드 패턴의 핵심은 “공통 흐름은 한 곳에, 변하는 부분만 오버라이드” — 새 구현체를 추가해도 기존 코드를 건드리지 않아야 진짜 OCP다.

참고: 템플릿 메서드 패턴(Template Method Pattern)은 GoF(Gang of Four)의 Design Patterns: Elements of Reusable Object-Oriented Software (Gamma et al., 1994)에서 정의한 행동 패턴이다. 이 글의 예시는 그 원형을 Spring 외부 API 클라이언트 구조에 맞게 응용한 것이다.

[Java 객체지향 실전 #3] 엔티티에 setter가 있다면 — 빈약한 도메인 모델을 풍부하게 만드는 법

Fri, 22 May 2026 00:00:00 +0900

이런 코드, 불안하지 않나요?

주문 취소 API를 만들었다. Service 코드는 이렇다.

public void cancelOrder(Long orderId) {
 Order order = orderRepository.findById(orderId)
 .orElseThrow(() -> new EntityNotFoundException("주문을 찾을 수 없습니다."));

 if (order.getStatus() == OrderStatus.SHIPPED) {
 throw new IllegalStateException("배송 중인 주문은 취소할 수 없습니다.");
 }
 if (order.getStatus() == OrderStatus.CANCELLED) {
 throw new IllegalStateException("이미 취소된 주문입니다.");
 }

 order.setStatus(OrderStatus.CANCELLED);
 order.setCancelledAt(LocalDateTime.now());
 orderRepository.save(order);
}

여기서 질문 하나. 나중에 배치 처리에서도 주문을 취소해야 한다면? 관리자 기능에서도 취소를 해야 한다면? 그때마다 저 if 블록을 복붙해야 한다. 그리고 언젠가 취소 규칙이 바뀌면, 모든 복붙 지점을 찾아서 고쳐야 한다.

이것이 **빈약한 도메인 모델(Anemic Domain Model)**의 문제다. Martin Fowler는 이를 안티패턴이라고 불렀다.

빈약한 도메인 모델이란?

엔티티는 데이터 컨테이너(getter/setter만 있음)이고, 비즈니스 로직은 전부 Service에 집중된 구조다.

// Order.java — 빈약한 도메인 (Anemic)
@Entity
@Getter @Setter // setter가 열려 있어 어디서든 상태 변경 가능
@NoArgsConstructor
public class Order {

 @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
 private Long id;

 private Long userId;

 @Enumerated(EnumType.STRING)
 private OrderStatus status; // PENDING, PAID, CANCELLED, SHIPPED

 private long totalAmount;

 @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
 private List<OrderItem> items = new ArrayList<>();

 private LocalDateTime orderedAt;
 private LocalDateTime cancelledAt;
 // 비즈니스 메서드 없음. 그냥 데이터 덩어리.
}

@Setter가 열려 있으면 어디서든 order.setStatus(OrderStatus.CANCELLED)를 호출할 수 있다. 취소 가능 여부를 검증하지 않고도. 이것이 캡슐화가 깨진 상태다.

풍부한 도메인 모델로 전환하기

풍부한 도메인 모델은 간단한 원칙을 따른다. “객체 자신의 상태는 객체 스스로가 변경한다.”

setter를 없애고 커맨드 메서드를 만든다

// Order.java — 풍부한 도메인 (Rich)
@Entity
@Table(name = "orders")
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED) // JPA 전용, 외부에서 new Order() 불가
public class Order extends BaseEntity {

 @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
 private Long id;

 private Long userId;

 @Enumerated(EnumType.STRING)
 private OrderStatus status;

 private long totalAmount;

 @OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true)
 private List<OrderItem> items = new ArrayList<>();

 private LocalDateTime orderedAt;
 private LocalDateTime cancelledAt;

 // ── 생성 ─────────────────────────────────────────────
 // 정적 팩토리 메서드 — 생성 시점의 불변식 보장
 public static Order place(Long userId) {
 Order order = new Order();
 order.userId = userId;
 order.status = OrderStatus.PENDING;
 order.totalAmount = 0L;
 order.orderedAt = LocalDateTime.now();
 return order;
 }

 // ── 커맨드 메서드 ────────────────────────────────────

 /**
 * 주문 취소.
 * 비즈니스 규칙: SHIPPED, CANCELLED 상태에서는 취소 불가.
 */
 public void cancel() {
 validateCancellable();
 this.status = OrderStatus.CANCELLED;
 this.cancelledAt = LocalDateTime.now();
 }

 /**
 * 주문 아이템 추가.
 * 비즈니스 규칙: PENDING 상태에서만 추가 가능.
 */
 public void addItem(Long productId, String productName, long price, int quantity) {
 validatePending();
 if (quantity <= 0) {
 throw new IllegalArgumentException("수량은 1개 이상이어야 합니다.");
 }
 OrderItem item = OrderItem.of(this, productId, productName, price, quantity);
 this.items.add(item);
 this.totalAmount += price * quantity;
 }

 /**
 * 결제 완료 처리.
 */
 public void pay() {
 if (this.status != OrderStatus.PENDING) {
 throw new IllegalStateException("대기 중인 주문만 결제할 수 있습니다.");
 }
 if (this.items.isEmpty()) {
 throw new IllegalStateException("주문 항목이 없습니다.");
 }
 this.status = OrderStatus.PAID;
 }

 // ── 내부 검증 (private) ──────────────────────────────

 private void validateCancellable() {
 if (this.status == OrderStatus.SHIPPED) {
 throw new IllegalStateException("배송 중인 주문은 취소할 수 없습니다.");
 }
 if (this.status == OrderStatus.CANCELLED) {
 throw new IllegalStateException("이미 취소된 주문입니다.");
 }
 }

 private void validatePending() {
 if (this.status != OrderStatus.PENDING) {
 throw new IllegalStateException("대기 중인 주문에만 상품을 추가할 수 있습니다.");
 }
 }
}

취소 가능 여부 검증이 Order.cancel() 내부에 있다. 배치에서 취소하든, 관리자 API에서 취소하든, 어디서 order.cancel()을 호출해도 규칙은 반드시 거친다.

Service는 흐름만 담당한다

@Service
@RequiredArgsConstructor
@Transactional
public class OrderService {

 private final OrderRepository orderRepository;
 private final ProductRepository productRepository;

 public Order placeOrder(Long userId, List<OrderItemRequest> itemRequests) {
 Order order = Order.place(userId); // 생성 책임은 Order에게

 for (OrderItemRequest req : itemRequests) {
 Product product = productRepository.findById(req.getProductId())
 .orElseThrow(() -> new EntityNotFoundException("상품 없음: " + req.getProductId()));

 order.addItem(product.getId(), product.getName(),
 product.getPrice(), req.getQuantity());
 }

 return orderRepository.save(order);
 }

 public void cancelOrder(Long orderId) {
 Order order = orderRepository.findById(orderId)
 .orElseThrow(() -> new EntityNotFoundException("주문 없음: " + orderId));

 order.cancel(); // 취소 가능 여부 판단은 Order가 담당
 // @Transactional + 영속성 컨텍스트 변경 감지로 save() 불필요
 }

 public void payOrder(Long orderId) {
 Order order = orderRepository.findById(orderId)
 .orElseThrow(() -> new EntityNotFoundException("주문 없음: " + orderId));

 order.pay(); // 결제 가능 여부 판단은 Order가 담당
 }
}

Service 코드가 거짓말처럼 짧아졌다. if 블록이 없다. Service는 “어떤 순서로 무엇을 호출할지"만 결정한다.

테스트가 엄청나게 쉬워진다

빈약한 도메인 모델에서는 OrderService를 테스트하려면 OrderRepository, ProductRepository를 모두 Mock으로 세팅해야 했다. 풍부한 도메인 모델에서는 도메인 객체만 단독으로 테스트할 수 있다.

class OrderTest {

 @Test
 void 주문_생성_후_아이템_추가() {
 Order order = Order.place(1L);
 order.addItem(10L, "티셔츠", 30_000L, 2);

 assertThat(order.getTotalAmount()).isEqualTo(60_000L);
 assertThat(order.getItems()).hasSize(1);
 }

 @Test
 void 배송중_주문_취소_불가() {
 Order order = Order.place(1L);
 order.addItem(10L, "티셔츠", 30_000L, 1);
 order.pay();
 ReflectionTestUtils.setField(order, "status", OrderStatus.SHIPPED);

 assertThatThrownBy(order::cancel)
 .isInstanceOf(IllegalStateException.class)
 .hasMessageContaining("배송 중인 주문은 취소할 수 없습니다");
 }

 @Test
 void 결제완료_주문에_아이템_추가_불가() {
 Order order = Order.place(1L);
 order.addItem(10L, "티셔츠", 30_000L, 1);
 order.pay();

 assertThatThrownBy(() -> order.addItem(20L, "바지", 50_000L, 1))
 .isInstanceOf(IllegalStateException.class);
 }
}

Spring Context 없이, Mock 없이, 순수 Java로 비즈니스 규칙을 테스트한다.

한 단계 더: Value Object로 원시 타입 집착 해소

원시 타입 long price는 타입 시스템이 도메인 개념을 표현하지 못한다. pay(long price, long discount, long shippingFee)처럼 파라미터가 늘어나면 순서 실수가 생긴다.

Value Object는 **불변(immutable)**이고 값 기반 동등성을 가진다.

@Getter
@EqualsAndHashCode
public final class Money {

 private final long amount;
 private final Currency currency;

 private Money(long amount, Currency currency) {
 if (amount < 0) {
 throw new IllegalArgumentException("금액은 0 이상이어야 합니다: " + amount);
 }
 this.amount = amount;
 this.currency = currency;
 }

 public static Money krw(long amount) {
 return new Money(amount, Currency.KRW);
 }

 public Money add(Money other) {
 validateSameCurrency(other);
 return new Money(this.amount + other.amount, this.currency);
 }

 public Money subtract(Money other) {
 validateSameCurrency(other);
 long result = this.amount - other.amount;
 if (result < 0) {
 throw new IllegalStateException("금액이 부족합니다.");
 }
 return new Money(result, this.currency);
 }

 public Money multiply(int multiplier) {
 return new Money(this.amount * multiplier, this.currency);
 }

 private void validateSameCurrency(Money other) {
 if (this.currency != other.currency) {
 throw new IllegalArgumentException("통화가 다릅니다.");
 }
 }
}

Money.krw(30_000).add(Money.krw(5_000))는 30000 + 5000 보다 훨씬 의도가 명확하다. 검증 로직도 Money 생성자 안에 있어서 음수 금액이 만들어질 수 없다.

JPA 엔티티에 쓸 때는 @Embeddable을 붙이면 된다.

@Embeddable
@Getter
@EqualsAndHashCode
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public final class Address {
 private String zipCode;
 private String street;
 private String detail;

 public Address(String zipCode, String street, String detail) {
 if (zipCode == null || !zipCode.matches("\\d{5}")) {
 throw new IllegalArgumentException("올바른 우편번호 형식이 아닙니다: " + zipCode);
 }
 this.zipCode = Objects.requireNonNull(zipCode);
 this.street = Objects.requireNonNull(street, "도로명주소는 필수입니다.");
 this.detail = detail;
 }
}

@Entity
public class User extends BaseEntity {

 @Embedded
 private Address address; // 테이블에는 zip_code, street, detail 컬럼으로 펼쳐짐

 public void changeAddress(Address newAddress) {
 this.address = Objects.requireNonNull(newAddress);
 }
}

빈약한 도메인 vs 풍부한 도메인 비교

항목	빈약한 도메인	풍부한 도메인
비즈니스 규칙 위치	Service (여러 곳에 흩어짐)	엔티티 메서드 내부
setter	열려 있음 (누구나 상태 변경)	없음, 커맨드 메서드만
단위 테스트	Service + Mock 세팅 필요	도메인 객체 단독 테스트
규칙 중복	여러 Service에서 같은 검증 반복	엔티티에 단 한 번
가독성	`orderService.cancel()` → 내부 로직 추적 필요	`order.cancel()` → 의도 명확

마치며

비즈니스 규칙은 그 규칙의 주인인 도메인 객체 안에 있어야 한다. setter를 닫고, 커맨드 메서드를 열고, Service는 흐름을 조율하는 데에만 집중하자. 규칙을 찾으러 Service 여러 개를 뒤질 필요가 없어진다.

[Java 객체지향 실전 #2] 엔티티마다 반복되는 코드를 제네릭으로 한 번에 — BaseEntity, GenericService, ApiResponse

Thu, 21 May 2026 00:00:00 +0900

이런 코드, 복붙하고 있지 않나요?

Spring + JPA 프로젝트를 막 시작하면 이런 일이 생긴다. User 엔티티를 만들고, Product 엔티티를 만들고, Order 엔티티를 만들다 보면, 어느 순간 createdAt, updatedAt, createdBy, updatedBy를 모든 파일에 복붙하고 있다.

// User.java
@Entity
public class User {
 @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
 private Long id;
 private String name;

 // 모든 엔티티에 아래 4개 필드가 반복
 private LocalDateTime createdAt;
 private LocalDateTime updatedAt;
 private String createdBy;
 private String updatedBy;
}

// Product.java
@Entity
public class Product {
 @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
 private Long id;
 private String name;
 private long price;

 // 또 반복
 private LocalDateTime createdAt;
 private LocalDateTime updatedAt;
 private String createdBy;
 private String updatedBy;
}

서비스 레이어도 마찬가지다. UserService의 findById, save, delete를 ProductService에 그대로 가져다 쓴다. 컨트롤러의 응답 구조도 사람마다 제각각이다.

반복 코드는 단순히 귀찮은 게 아니다. 버그 수정 지점이 여러 곳이 된다는 게 진짜 문제다.

해결 1: BaseEntity로 Auditing 필드 공통화

Spring JPA Auditing 활성화

먼저 Auditing을 쓰려면 설정이 필요하다.

@Configuration
@EnableJpaAuditing(auditorAwareRef = "auditorProvider")
public class AuditingConfig {

 @Bean
 public AuditorAware<String> auditorProvider() {
 // SecurityContext에서 현재 로그인 사용자 이름을 가져옴
 return () -> Optional.ofNullable(SecurityContextHolder.getContext())
 .map(SecurityContext::getAuthentication)
 .filter(Authentication::isAuthenticated)
 .map(Authentication::getName);
 }
}

BaseEntity 추상 클래스 하나로 정리

@Getter
@MappedSuperclass // 이 클래스 자체는 테이블 없음
@EntityListeners(AuditingEntityListener.class) // Auditing 이벤트 수신
public abstract class BaseEntity {

 @CreatedDate
 @Column(updatable = false) // 최초 생성 후 변경 불가
 private LocalDateTime createdAt;

 @LastModifiedDate
 private LocalDateTime updatedAt;

 @CreatedBy
 @Column(updatable = false)
 private String createdBy;

 @LastModifiedBy
 private String updatedBy;
}

@MappedSuperclass가 핵심이다. JPA에게 “이 클래스 자체는 테이블을 만들지 말고, 상속받는 엔티티의 테이블에 컬럼을 추가하라"고 지시한다.

엔티티에 적용하면

@Entity
@Table(name = "users")
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class User extends BaseEntity {

 @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
 private Long id;

 private String name;
 private String email;
 // createdAt, updatedAt, createdBy, updatedBy — 4개가 사라졌다
}

@Entity
@Table(name = "products")
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Product extends BaseEntity {

 @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
 private Long id;

 private String name;
 private long price;
}

4개 필드가 extends BaseEntity 한 줄로 교체됐다.

해결 2: GenericService로 CRUD 공통화

서비스 레이어도 제네릭으로 추상화할 수 있다. 타입 파라미터를 세 개 쓰는 것이 처음엔 낯설 수 있지만, 논리는 단순하다.

/**
 * T : 엔티티 타입
 * ID : PK 타입 (Long, String 등)
 * R : 사용할 JpaRepository 구현체 타입
 */
public abstract class GenericService<T, ID, R extends JpaRepository<T, ID>> {

 protected final R repository;

 protected GenericService(R repository) {
 this.repository = repository;
 }

 public T findById(ID id) {
 return repository.findById(id)
 .orElseThrow(() -> new EntityNotFoundException(
 getEntityName() + " not found: " + id));
 }

 public List<T> findAll() {
 return repository.findAll();
 }

 public T save(T entity) {
 return repository.save(entity);
 }

 public void delete(ID id) {
 if (!repository.existsById(id)) {
 throw new EntityNotFoundException(getEntityName() + " not found: " + id);
 }
 repository.deleteById(id);
 }

 // 예외 메시지에 쓸 엔티티 이름. 하위 클래스에서 오버라이드.
 protected String getEntityName() {
 return "Entity";
 }
}

구체 서비스는 공통 CRUD를 상속받고, 도메인 특화 메서드만 추가하면 된다.

@Service
public class UserService extends GenericService<User, Long, UserRepository> {

 public UserService(UserRepository userRepository) {
 super(userRepository);
 }

 @Override
 protected String getEntityName() { return "User"; }

 // 도메인 특화 메서드만 여기 추가
 public Optional<User> findByEmail(String email) {
 return repository.findByEmail(email);
 }

 public boolean existsByEmail(String email) {
 return repository.existsByEmail(email);
 }
}

@Service
public class ProductService extends GenericService<Product, Long, ProductRepository> {

 public ProductService(ProductRepository productRepository) {
 super(productRepository);
 }

 @Override
 protected String getEntityName() { return "Product"; }

 public List<Product> findByPriceLessThan(long maxPrice) {
 return repository.findByPriceLessThan(maxPrice);
 }
}

findById, save, delete가 사라지고, 각 서비스가 가진 고유한 로직만 남았다.

해결 3: ApiResponse<T>로 응답 구조 통일

컨트롤러마다 응답 형태가 다르면 프론트 팀은 힘들다.

// 어떤 컨트롤러
return ResponseEntity.ok(Map.of("data", user, "success", true));

// 다른 컨트롤러
return ResponseEntity.ok(product); // 래퍼 없이 바로 반환

// 또 다른 컨트롤러
return ResponseEntity.ok(Map.of("result", order, "code", 200, "message", "OK"));

제네릭 응답 래퍼 하나로 전 프로젝트의 응답 구조를 통일한다.

@Getter
@NoArgsConstructor(access = AccessLevel.PRIVATE)
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class ApiResponse<T> {

 private int code;
 private String message;
 private T data;

 public static <T> ApiResponse<T> success(T data) {
 return new ApiResponse<>(200, "OK", data);
 }

 public static <T> ApiResponse<T> success() {
 return new ApiResponse<>(200, "OK", null);
 }

 public static <T> ApiResponse<T> success(int code, String message, T data) {
 return new ApiResponse<>(code, message, data);
 }

 public static <T> ApiResponse<T> error(int code, String message) {
 return new ApiResponse<>(code, message, null);
 }
}

컨트롤러는 이렇게 쓴다.

@RestController
@RequiredArgsConstructor
@RequestMapping("/users")
public class UserController {

 private final UserService userService;

 @GetMapping("/{id}")
 public ResponseEntity<ApiResponse<UserResponse>> getUser(@PathVariable Long id) {
 User user = userService.findById(id);
 return ResponseEntity.ok(ApiResponse.success(UserResponse.from(user)));
 }

 @PostMapping
 public ResponseEntity<ApiResponse<UserResponse>> createUser(
 @RequestBody @Valid CreateUserRequest request) {
 User saved = userService.save(request.toEntity());
 return ResponseEntity.status(HttpStatus.CREATED)
 .body(ApiResponse.success(201, "Created", UserResponse.from(saved)));
 }

 @DeleteMapping("/{id}")
 public ResponseEntity<ApiResponse<Void>> deleteUser(@PathVariable Long id) {
 userService.delete(id);
 return ResponseEntity.ok(ApiResponse.success());
 }
}

GlobalExceptionHandler에서도 같은 래퍼를 쓰면 성공 응답과 오류 응답이 같은 구조를 갖는다.

@RestControllerAdvice
public class GlobalExceptionHandler {

 @ExceptionHandler(EntityNotFoundException.class)
 public ResponseEntity<ApiResponse<Void>> handleNotFound(EntityNotFoundException e) {
 return ResponseEntity.status(HttpStatus.NOT_FOUND)
 .body(ApiResponse.error(404, e.getMessage()));
 }

 @ExceptionHandler(IllegalArgumentException.class)
 public ResponseEntity<ApiResponse<Void>> handleBadRequest(IllegalArgumentException e) {
 return ResponseEntity.badRequest()
 .body(ApiResponse.error(400, e.getMessage()));
 }
}

적용 전후 비교

항목	적용 전	적용 후
Auditing 필드	엔티티마다 4개 반복	`extends BaseEntity` 1줄
CRUD 메서드	Service마다 findById/save/delete 반복	`GenericService` 상속, 도메인 메서드만 추가
API 응답 구조	Controller마다 제각각	`ApiResponse<T>` 통일
타입 안전성	`Map<String, Object>` 등 타입 소실	컴파일 타임에 타입 검증

마치며

반복 코드는 복붙의 문제가 아니라 버그 수정 지점이 여러 곳이라는 문제다. 제네릭 추상화로 공통 로직을 한 곳에 모으면, 고칠 게 생겼을 때 한 파일만 수정하면 된다.

[Java 객체지향 실전 #1] if/else 지옥에서 탈출하기 — 전략 패턴 + Spring Bean 자동 주입

Wed, 20 May 2026 00:00:00 +0900

이런 코드, 본 적 있지 않나요?

public void pay(String method, long amount) {
 if ("CARD".equals(method)) {
 // 카드 결제 로직
 } else if ("KAKAO_PAY".equals(method)) {
 // 카카오페이 로직
 } else if ("NAVER_PAY".equals(method)) {
 // 네이버페이 로직
 } else {
 throw new IllegalArgumentException("지원하지 않는 결제 수단: " + method);
 }
}

처음 만들 때는 두 개였던 분기가, 어느 날 기획자가 “토스페이도 붙여주세요"라고 하면 세 개가 되고, “삼성페이도요"가 따라오면 네 개가 된다. 수백 줄짜리 서비스 클래스의 탄생이다.

새로운 결제 수단이 추가될 때마다 PaymentService를 열어야 한다는 것, 그리고 이미 잘 돌아가고 있는 코드를 건드려야 한다는 긴장감. 이것이 OCP(개방-폐쇄 원칙) 위반이다.

전략 패턴으로 분기를 없애보자

전략 패턴의 핵심은 단순하다. “같은 역할을 하는 것들을 인터페이스로 묶는다.” 카드 결제, 카카오페이, 네이버페이는 모두 “결제"라는 같은 역할을 한다. 이걸 인터페이스 하나로 추상화하면 된다.

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

public interface PaymentStrategy {
 String getMethod(); // "CARD", "KAKAO_PAY" 등 구분 키
 void pay(long amount);
}

2단계: 전략 구현체를 각각 @Component로 등록

@Component
public class CardPaymentStrategy implements PaymentStrategy {

 @Override
 public String getMethod() {
 return "CARD";
 }

 @Override
 public void pay(long amount) {
 // 실제 카드사 API 호출 로직
 System.out.println("카드 결제 처리: " + amount + "원");
 }
}

@Component
public class KakaoPayStrategy implements PaymentStrategy {

 @Override
 public String getMethod() {
 return "KAKAO_PAY";
 }

 @Override
 public void pay(long amount) {
 // 카카오페이 API 호출 로직
 System.out.println("카카오페이 결제 처리: " + amount + "원");
 }
}

3단계: Service에서 List로 주입받아 Map으로 변환

Spring의 강력한 기능 중 하나는 특정 인터페이스의 모든 구현체를 List로 자동 주입해 준다는 것이다.

@Service
public class PaymentService {

 private final Map<String, PaymentStrategy> strategyMap;

 // Spring이 PaymentStrategy 구현체 전부를 List로 수집해 줌
 public PaymentService(List<PaymentStrategy> strategies) {
 this.strategyMap = strategies.stream()
 .collect(Collectors.toMap(PaymentStrategy::getMethod, Function.identity()));
 }

 public void pay(String method, long amount) {
 PaymentStrategy strategy = strategyMap.get(method);
 if (strategy == null) {
 throw new IllegalArgumentException("지원하지 않는 결제 수단: " + method);
 }
 strategy.pay(amount);
 }
}

if/else가 사라졌다. strategyMap.get(method) 한 줄이 모든 분기를 대신한다.

토스페이를 추가하고 싶다면?

// 이 파일 하나만 추가하면 끝
@Component
public class TossPayStrategy implements PaymentStrategy {

 @Override
 public String getMethod() {
 return "TOSS_PAY";
 }

 @Override
 public void pay(long amount) {
 System.out.println("토스페이 결제 처리: " + amount + "원");
 }
}

PaymentService는 단 한 줄도 수정하지 않는다. Spring이 애플리케이션 기동 시 TossPayStrategy를 자동으로 수집해 strategyMap에 등록한다. 이것이 OCP다.

같은 패턴, 다른 도메인에도 그대로

결제뿐 아니라 알림 채널(이메일, SMS, 슬랙)에도 완전히 같은 구조를 쓸 수 있다.

public interface NotificationStrategy {
 String getChannel(); // "EMAIL", "SMS", "SLACK"
 void send(String recipient, String message);
}

@Component
public class EmailNotificationStrategy implements NotificationStrategy {
 @Override
 public String getChannel() { return "EMAIL"; }

 @Override
 public void send(String recipient, String message) {
 // JavaMailSender 등 이메일 발송 로직
 }
}

@Service
public class NotificationService {

 private final Map<String, NotificationStrategy> strategyMap;

 public NotificationService(List<NotificationStrategy> strategies) {
 this.strategyMap = strategies.stream()
 .collect(Collectors.toMap(NotificationStrategy::getChannel, Function.identity()));
 }

 public void send(String channel, String recipient, String message) {
 NotificationStrategy strategy = strategyMap.get(channel);
 if (strategy == null) {
 throw new IllegalArgumentException("지원하지 않는 알림 채널: " + channel);
 }
 strategy.send(recipient, message);
 }
}

테스트도 훨씬 쉬워진다

전략 패턴의 또 다른 장점은 테스트 가능성이다. 각 전략을 독립적으로 테스트할 수 있고, PaymentService 테스트도 필요한 전략만 골라서 넣을 수 있다.

@Test
void 카드_결제_전략이_정상_호출된다() {
 CardPaymentStrategy cardStrategy = new CardPaymentStrategy();
 KakaoPayStrategy kakaoStrategy = new KakaoPayStrategy();
 PaymentService service = new PaymentService(List.of(cardStrategy, kakaoStrategy));

 // if/else 전체를 거칠 필요 없이 해당 케이스만 테스트
 assertDoesNotThrow(() -> service.pay("CARD", 10000L));
}

@Test
void 지원하지_않는_결제수단_예외() {
 PaymentService service = new PaymentService(List.of(new CardPaymentStrategy()));

 assertThatThrownBy(() -> service.pay("BITCOIN", 10000L))
 .isInstanceOf(IllegalArgumentException.class);
}

핵심 정리

항목	내용
OCP 달성	새 전략 추가 = 새 `@Component` 클래스 하나, 기존 코드 수정 없음
Spring 자동화	`List<인터페이스>` 주입 → 구현체 전부 자동 수집
테스트 용이성	전략별 독립 단위 테스트 가능

마치며: 분기가 늘어날 것 같다는 예감이 들 때, @Component + List<인터페이스> 조합을 떠올려 보자. if/else가 들어갈 자리를 인터페이스가 대신한다.

참고: 전략 패턴(Strategy Pattern)은 GoF(Gang of Four)의 Design Patterns: Elements of Reusable Object-Oriented Software (Gamma et al., 1994)에서 정의한 행동 패턴이다. 이 글의 결제 예시는 그 원형을 Spring 생태계에 맞게 응용한 것으로, List<인터페이스> 자동 주입 방식은 Spring 커뮤니티에서 광범위하게 사용되는 관용 표현이다.