Oop 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 객체지향 실전 #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 커뮤니티에서 광범위하게 사용되는 관용 표현이다.