현재의 내가 미래의 나에게

인터페이스와 추상 클래스 비교

k9want — Mon, 3 Feb 2025 23:34:53 +0900

실무 관점에서 본 인터페이스 vs. 추상 클래스 비교

인터페이스와 추상 클래스는 객체지향 설계에서 핵심적인 개념이며, 실무에서는 상황에 따라 적절히 선택해야 합니다. 아래에서는 언제 인터페이스를 사용하고, 언제 추상 클래스를 사용하는지, 그리고 실제로 더 자주 사용하는 개념과 그 이유를 정리해 보겠습니다.

인터페이스 vs. 추상 클래스 실무 비교

비교 요소 인터페이스 (Interface) 추상 클래스 (Abstract Class)

상속 구조	다중 구현 가능 (클래스는 여러 개의 인터페이스를 구현 가능)	단일 상속만 가능 (다른 클래스를 동시에 상속받을 수 없음)
상태(State) 유지	불가능 (멤버 변수 선언 불가, Java 8 이후 default 메서드로 일부 구현 가능)	가능 (멤버 변수 선언 및 상태 유지 가능)
기본 구현	기본적으로 없음, Java 8 이후 default 메서드 사용 가능	일부 메서드를 구현 가능 (공통된 기능 제공)
사용 목적	특정 기능을 강제하는 용도로 사용 (Comparable, Runnable)	공통된 기능을 제공하면서 일부 메서드를 구현 강제 (Animal → Dog, Cat)
유연성	높은 확장성 (다양한 클래스에서 같은 동작을 구현 가능)	공통 기능을 포함한 특정 계열의 클래스 설계에 적합
성능	인터페이스는 기본적으로 가상 호출이 많아 성능 오버헤드가 발생할 수 있음	직접적인 상속 구조로 인해 성능이 조금 더 유리

✅ 실무에서의 선택 기준

상황 인터페이스 선택 추상 클래스 선택


상황	인터페이스 선택	추상 클래스 선택
여러 클래스가 공통된 동작(기능)을 가져야 하나, 계층 구조가 아닐 때	✅	❌
여러 클래스가 공통된 속성(필드)과 행동(메서드)을 공유해야 할 때	❌	✅
특정 동작을 강제하고, 다양한 구현이 필요할 때 (예: Comparable, Serializable)	✅	❌
동일한 동작을 하는 다양한 클래스가 있고, 기본 구현을 제공해야 할 때	❌	✅
다중 상속이 필요한 경우 (여러 개의 기능을 조합)	✅	❌
프레임워크나 라이브러리에서 기능을 확장할 때 (예: Spring의 BeanPostProcessor)	✅	❌
특정 클래스를 기반으로 몇 개의 서브클래스를 만들고 싶을 때	❌	✅

실무에서 더 자주 사용하는 것은?

인터페이스가 실무에서 더 자주 사용됩니다.

이유 1: 다중 상속 지원

Java는 클래스의 다중 상속을 지원하지 않지만, 인터페이스는 다중 구현 가능
예를 들어, Runnable, Serializable, Cloneable과 같은 동작을 동시에 가질 수 있음
Spring, JPA 등 주요 프레임워크에서도 인터페이스 기반 설계가 많음

이유 2: 유연한 설계

인터페이스를 사용하면 서로 다른 클래스에서도 공통 기능을 강제할 수 있어 확장성이 뛰어남
실무에서는 비즈니스 로직이 확장될 가능성이 높기 때문에 인터페이스 중심의 설계가 선호됨

이유 3: SOLID 원칙 준수

OCP(Open-Closed Principle, 개방-폐쇄 원칙): 인터페이스를 사용하면 새로운 기능을 추가할 때 기존 클래스를 변경하지 않고 확장 가능
DIP(Dependency Inversion Principle, 의존 역전 원칙): 고수준 모듈이 저수준 모듈에 직접 의존하지 않고, 인터페이스를 통해 의존성을 분리

인터페이스 vs. 추상 클래스 장단점 정리

인터페이스의 장점

✅ 1. 유연성과 확장성 (OCP: 개방-폐쇄 원칙 준수)

인터페이스를 사용하면 새로운 기능을 추가할 때 기존 코드를 수정할 필요가 없음

✅ 2. 다중 구현 가능 (다중 상속 대체)

자바는 클래스의 다중 상속을 지원하지 않지만, 인터페이스는 여러 개를 구현할 수 있음

✅ 3. 객체 간의 결합도를 낮춤 (DIP: 의존 역전 원칙 적용)

인터페이스를 활용하면 특정 구현체에 의존하지 않으므로, 코드 유지보수가 용이

인터페이스의 단점

❌ 1. 구현 강제성 (불필요한 메서드 구현 발생)

인터페이스를 구현하는 모든 클래스는 정의된 메서드를 반드시 구현해야 함
만약 일부 클래스에서 필요하지 않은 메서드가 있을 경우, 빈 구현을 해야 하는 경우가 발생
해결 방법: 인터페이스를 분리하여 ISP(인터페이스 분리 원칙) 적용

❌ 2. 코드 중복 가능성 (기본 구현이 없음)

인터페이스는 기본적으로 메서드 구현을 제공하지 않기 때문에,동일한 기능이 여러 구현체에서 필요할 경우 중복 코드가 발생할 수 있음
(Java 8 이후 default 메서드를 지원하여 일부 해결 가능)

추상 클래스의 장점

✅ 1. 기본 동작 제공 (코드 재사용 가능)

공통 기능을 제공하여 중복 코드 감소

✅ 2. 상태(필드) 유지 가능

인터페이스는 멤버 변수를 가질 수 없지만, 추상 클래스는 상태를 유지할 수 있음

추상 클래스의 단점

❌ 1. 단일 상속의 한계

자바에서는 하나의 클래스만 상속 가능
만약 여러 개의 부모 클래스를 상속하고 싶다면, 추상 클래스를 사용할 수 없음

❌ 2. 확장성이 떨어짐 (OCP 원칙 위반)

새로운 기능을 추가하려면 기존 추상 클래스를 수정해야 함
인터페이스 기반 설계보다 유연성이 낮음

❌ 3. 구현 클래스 간 결합도가 높아짐

추상 클래스를 변경하면, 이를 상속하는 모든 클래스가 영향을 받음

실무에서는 어떻게 선택해야 할까?

비교 요소 인터페이스 추상 클래스

유연성	✅ 높음 (OCP 준수, 변경 용이)	❌ 낮음 (추가 시 기존 클래스 수정 필요)
코드 재사용	❌ 없음 (중복 가능성 존재)	✅ 있음 (기본 구현 제공)
상태 유지	❌ 불가능	✅ 가능 (멤버 변수 포함 가능)
다중 상속	✅ 가능 (여러 인터페이스 구현 가능)	❌ 불가능 (단일 상속 제한)
결합도	✅ 낮음 (느슨한 결합)	❌ 높음 (변경 시 전체 영향)
구현 강제성	✅ 필요 (모든 메서드 구현)	✅ 필요 (추상 메서드 구현)

실무 예제: 인터페이스 vs. 추상 클래스 적용 사례

인터페이스 사용 예 (Spring에서 Repository 패턴 적용)

Spring 프레임워크에서는 Repository 계층을 인터페이스로 설계하여, 다양한 데이터베이스 구현체를 쉽게 교체할 수 있도록 합니다.

// 인터페이스 정의 (다양한 DB 구현체를 만들 수 있음)
public interface UserRepository {
    User findById(Long id);
    void save(User user);
}

// MySQL 구현체
public class MySQLUserRepository implements UserRepository {
    @Override
    public User findById(Long id) {
        System.out.println("Fetching user from MySQL...");
        return new User(id, "MySQL User");
    }

    @Override
    public void save(User user) {
        System.out.println("Saving user to MySQL...");
    }
}

// MongoDB 구현체
public class MongoUserRepository implements UserRepository {
    @Override
    public User findById(Long id) {
        System.out.println("Fetching user from MongoDB...");
        return new User(id, "MongoDB User");
    }

    @Override
    public void save(User user) {
        System.out.println("Saving user to MongoDB...");
    }
}

// 서비스 계층 (인터페이스를 통해 종속성 주입)
public class UserService {
    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public void processUser(Long id) {
        User user = userRepository.findById(id);
        System.out.println("Processing user: " + user.getName());
    }
}

✅ 장점:

MySQL, MongoDB 등의 구현을 쉽게 교체 가능
확장성이 뛰어나며, 새로운 DB 지원이 필요할 경우 기존 코드를 수정하지 않고 확장 가능

추상 클래스 사용 예 (공통 동작을 가지는 동물 클래스)

java
복사편집
// 추상 클래스: 공통 속성과 메서드 제공
abstract class Animal {
    protected String name;

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

    public void sleep() {
        System.out.println(name + " is sleeping...");
    }

    // 추상 메서드 (각 동물이 다르게 구현해야 함)
    public abstract void makeSound();
}

// 하위 클래스
class Dog extends Animal {
    public Dog(String name) {
        super(name);
    }

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

class Cat extends Animal {
    public Cat(String name) {
        super(name);
    }

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

// 실행 코드
public class Main {
    public static void main(String[] args) {
        Animal dog = new Dog("Buddy");
        dog.sleep();
        dog.makeSound();

        Animal cat = new Cat("Kitty");
        cat.sleep();
        cat.makeSound();
    }
}

✅ 장점:

Animal 클래스에서 공통된 동작(sleep())을 제공하고, 하위 클래스에서 makeSound()를 반드시 구현하도록 강제
공통 속성(name)을 관리할 수 있어 중복 코드 감소

결론

✅ 실무에서는 인터페이스를 더 많이 사용!

유연성이 뛰어나고 유지보수성이 높음
다중 구현 가능하여 확장성 증가
Spring, JPA, REST API 등 대부분의 프레임워크에서 인터페이스 기반 설계 적용

✅ 추상 클래스는 특정한 경우에만 사용

공통된 상태(필드)와 기본 동작을 제공할 때 적합
인터페이스만으로 해결하기 어려운 경우 보완적으로 활용

즉, 기본적으로 인터페이스를 사용하고, 필요한 경우에만 추상 클래스를 활용하는 것이 실무에서 가장 효과적인 방식!

인터페이스에 대한 생각 정리

k9want — Mon, 3 Feb 2025 23:21:19 +0900

1. 인터페이스란 무엇인가?

인터페이스(Interface)는 자바의 핵심 개념 중 하나로, 클래스가 구현해야 하는 메서드의 명세를 정의하는 추상적인 타입이다. 인터페이스는 다음과 같은 특징을 갖는다.

메서드의 시그니처만 정의하고, 구체적인 구현은 제공하지 않는다.
- 메서드의 시그니처 : 메서드의 이름과 그 메서드가 받을 파라미터의 종류 및 개수를 의미
다중 구현(multiple inheritance)을 가능하게 한다.
- 다중 구현 : 한 클래스가 두 개 이상의 부모 클래스를 상속받는 개념
구현 클래스의 계약(Contract) 역할을 수행하여 코드의 유연성과 확장성을 높인다.
- 계약 : 특정 규칙을 지켜야 한다는 약속을 의미
- 인터페이스를 구현한 클래스는 반드시 메서드들을 구체적으로 구현해야 한다는 규칙(계약)을 지켜야 한다.

2. 인터페이스의 주요 목적

인터페이스는 여러 측면에서 중요한 역할을 한다.

설계 원칙 준수: SOLID 원칙 중 ISP(Interface Segregation Principle, 인터페이스 분리 원칙) 및 **DIP(Dependency Inversion Principle, 의존 역전 원칙)**을 준수하는 데 필수적이다.
- ISP : 클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않도록 해야한다는 원칙
  - 필요한 기능만을 제공하는 작은 인터페이스로 분리하라는 의미
  - 큰 인터페이스는 다양한 기능을 제공하지만, 이를 구현해야 하는 클래스가 필요 없는 메서드까지 강제로 구현해야하는 상황이 발생 → 클래스가 불필요한 코드까지 작성하게 하여, 유지 보수성을 떨어뜨리고 확장성을 제한한다.
- DIP : 고수준 모듈은 저수준 모듈에 의존해서는 안 되고, 둘 다 추상화에 의존해야 한다는 원칙 [추상화는 세부 사항에 의존해서는 안 되고, 세부 사항은 추상화에 의존해야 한다.]
  - 상위 모듈(고수준 모듈)이 하위 모듈(저수준 모듈)에 직접 의존하면 두 모듈 간 결합도가 높아져서 유연성과 확장성이 떨어지게 된다. 이 문제를 해결하기 위해, 의존 관계를 추상화(인터페이스 또는 추상 클래스)하여 결합도를 낮추는 방법이 DIP이다.
  - DIP 적용하면 테스트 코드 작성도 용이해진다. → 실제 구현이 아닌 인터페이스를 기반으로 의존성을 주입하면, 테스트 시 Mock 객체를 활용할 수 있어 독립적인 단위 테스트가 가능해진다.
유지보수성 향상: 구체적인 구현을 숨기고 계약을 정의함으로써, 코드의 변경이 인터페이스에 의존하는 다른 부분에 영향을 최소화한다.
다형성(Polymorphism) 활용: 인터페이스를 통해 다양한 구현을 하나의 타입으로 다룰 수 있다.
- 역할(Role)과 책임(Responsibility) 분리 : 클래스의 역할(무엇을 하는가?)과 구현(어떻게 하는가?)을 분리할 수 있으며, 결합도를 낮추고 유연한 설계를 가능하게 한다.

3. 기본적인 사용 예시

public interface PaymentGateway {
    void processPayment(double amount);
}

public class CreditCardPayment implements PaymentGateway {
    @Override
    public void processPayment(double amount) {
        System.out.println("Processing credit card payment: " + amount);
    }
}

public class PayPalPayment implements PaymentGateway {
    @Override
    public void processPayment(double amount) {
        System.out.println("Processing PayPal payment: " + amount);
    }
}

이러한 방식으로 인터페이스를 활용하면 결합도를 낮추고, 새로운 결제 방식을 추가할 때 기존 코드를 수정하지 않고 확장할 수 있다.

4. 실무에서 인터페이스를 활용하는 방식

의존성 주입(DI, Dependency Injection)과 스프링 빈 관리

인터페이스를 활용하면 런타임에 다양한 구현체를 주입할 수 있어 유지보수성이 향상된다.

@Service
public class PaymentService {
    private final PaymentGateway paymentGateway;

    public PaymentService(PaymentGateway paymentGateway) {
        this.paymentGateway = paymentGateway;
    }

    public void executePayment(double amount) {
        paymentGateway.processPayment(amount);
    }
}

전략 패턴(Strategy Pattern) 적용
- 전략 패턴 : 행동을 캡슐화하여, 실행 중에 동적으로 변경할 수 있도록 하는 디자인 패턴 즉, 실행 중에 특정 동작을 유연하게 변경할 수 있게 만들어 준다.
  - 핵심 개념
    - 동일한 문제를 해결하는 여러 개의 알고리즘(전략)을 인터페이스로 추상화
    - 실행 중에 적절한 전략을 선택하여 사용할 수 있음
    - OCP(개방-폐쇄 원칙) 준수: 새로운 전략을 추가해도 기존 코드를 수정할 필요 없음
    - DIP(의존 역전 원칙) 준수: 특정 구현체가 아닌 인터페이스에 의존
API 설계 시 인터페이스 중심 개발(Interface-Based Development, IBD)
- 인터페이스 중심 개발 : 비즈니스 로직을 인터페이스로 추상화하여 구현체를 유연하게 변경할 수 있도록 유도하는 개발 방식
- REST API 설계 시 서비스 레이어에 인터페이스를 두어 구현체를 쉽게 변경할 수 있도록 해준다.
  - 주요 개념
    - 구현체(Service Implementation)와 분리된 인터페이스를 통해 느슨한 결합(Loose Coupling)을 유지
    - 특정 기술(JPA, MyBatis, MongoDB 등)에 의존하지 않고 쉽게 교체 가능
    - Mock 객체를 활용한 단위 테스트 용이
    - SOLID 원칙 준수 (특히 DIP(의존 역전 원칙), OCP(개방-폐쇄 원칙) 적용

5. 인터페이스의 단점은 무엇인가?

코드 중복 가능성: 여러 구현체에서 동일한 로직이 필요할 경우, 인터페이스에서는 메서드 구현이 불가능하므로 중복된 코드가 발생할 수 있다.
변경 시 영향도가 클 수 있음: 인터페이스 변경은 이를 구현한 모든 클래스에 영향을 미치므로 신중한 설계가 필요하다.

6. 인터페이스와 람다 표현식은 어떤 관계가 있는가?

자바 8부터 인터페이스는 람다 표현식과 함께 활용될 수 있게 되었다.

특히, 함수형 인터페이스(Functional Interface)는 하나의 추상 메서드만 가지는 인터페이스로, @FunctionalInterface 어노테이션을 활용할 수 있다.

@FunctionalInterface
public interface Calculator {
    int calculate(int a, int b);
}

public class LambdaExample {
    public static void main(String[] args) {
        Calculator add = (a, b) -> a + b;
        System.out.println(add.calculate(5, 3));
    }
}

람다 표현식을 활용하면 코드가 간결해지고 유지보수성이 높아진다.

7. 인터페이스를 너무 많이 사용하면 발생하는 문제는?

인터페이스를 과도하게 사용하면 복잡성이 증가할 수 있다.

인터페이스가 많아지면 구현 클래스와의 관계가 복잡해지고, 관리 비용이 증가할 수 있다.

따라서 적절한 수준에서 인터페이스를 설계하고 유지하는 것이 중요하다.

결론: 인터페이스의 중요성 강조

마지막으로, 인터페이스를 단순한 문법 요소가 아니라 객체 지향 프로그래밍(OOP)과 SOLID 원칙을 준수하는 핵심 도구로 설명하며 마무리하려고 한다.

"인터페이스는 단순히 추상 메서드를 선언하는 것이 아니라, 설계의 유연성과 확장성을 극대화하는 수단이다. 실무에서는 이를 기반으로 느슨한 결합(loose coupling)을 유지하며, 다양한 패턴과 원칙을 적용하여 유지보수성이 높은 코드를 작성하는 것이 중요하다고 생각한다."

[외주] 트래블록 프로젝트 리팩토링 회고

k9want — Fri, 23 Aug 2024 02:16:39 +0900

앞서 세웠던 리팩토링 방향성에 대해

직접 리팩토링하면서 배운 점과 느꼈던 점에 대해 작성해보려고 한다.

리팩토링을 통해 해당 프로젝트에서 얻고자 했던 것들이 몇 가지 있었다.

도메인 계층을 분리하여 비즈니스 로직을 보다 명확히 이동시키기
데이터(DB)에 의존적인 코드가 아닌, 비즈니스 로직 중심의 코드로 변경하기
의존성 역전 원칙(DIP)을 적용하여, 의존성을 낮추고 테스트에 용이한 코드로 변경하기

왜 리팩토링이 필요한가?

이전에 작성했던 글에서는 리팩토링의 방향성만 정의하고,

왜 그 방향성을 선택했는지에 대한 설명이 부족했던 것 같다.

이번 글에서는 그 이유를 먼저 언급하고자 한다.

의존성 역전 원칙(DIP)을 적용하여, 의존성을 낮추고 테스트에 용이한 코드로 변경하기

리팩토링 방향성을 설정할 때, 가장 먼저 고민한 것은 왜 리팩토링이 필요한가?였다.

프로젝트를 진행하면서 일관된 방식(레이어드 아키텍처)으로 코드를 구현하려고 노력했고,

스프링으로 개발하는 것은 처음이었기에, 팀원과 의논 후,

보편적으로 사용되는 Controller-Service-Repository 형태의 레이어드 아키텍처를 선택하게 되었다.

부끄럽게도 이번 외주 프로젝트를 진행하기 전에는 이것이 정답이라고 생각했다.

그렇다고 레이어드 아키텍처가 잘못되었다고 비판하는 것도 아니고 틀렸다는 건 절대 아니다.

후에 언급하겠지만,

토이프로젝트의 경우 굳이 복잡성을 늘리면서까지 개발을 할 필요가 있을까?라는 의문이 들었기 때문이다.

따라서 어떤 아키텍처가 정답이라는 건 존재하지 않는다.

레이어드 아키텍처를 사용하면서 점차 JpaRepository에 강하게 의존하므로서

트랜잭션 스크립트 형태의 서비스 코드가 보여졌고,

그로 인해 서비스 코드의 대다수가 JPA에 의존적인 코드가 되었다.

트랜잭션 스크립트

서비스 컴포넌트의 구현이 사실상 어떤 트랜잭션이 걸려있는 스크립트를 실행하는 것처럼 보일 때를 말한다.

→ 스마트 서비스 라고 부를 수 있다.

→ 절차지향에 가깝기에 변경에 취약하고 확장에 취약하며 업무가 병렬 처리되기 어렵다.

→ 서비스에 대한 올바른 정의가 필요

토이프로젝트를 진행함에 있어, JPA 외에 다른 기술을 사용하지 않을 예정이었지만

당시에 나는 이 부분이 크게 신경쓰였다.

이는 곧 리팩토링의 방향성으로 이어졌다.

도메인 계층을 분리하여 비즈니스 로직을 보다 명확히 이동시키기

더불어 서비스 계층에 많은 책임이 집중되면서 서비스 계층에 정의가 모호해졌고,

이에 대해 조치가 필요함을 느꼈다.

그렇기에 서비스 계층을 애플리케이션 계층과 도메인 계층으로 나눔으로써 이를 해소하고자 했다.

추가로 테스트 코드 작성에 대한 막연한 두려움과 경험 부족으로 인해,

초기에는 테스트 코드를 작성하지 않고 단순히 API 개발에만 집중하게 되었다.

-> 단순, 포스트맨으로만 인수테스트를 진행할 뿐 더 이상의 테스트는 하지 않았다.. 지금와서 생각해보면 무섭다...

클래스를 작성하고 정의할 때, 행위에 대해 먼저 생각하고 그에 따라 상태를 결정하는 원칙을 나름대로 따랐다.

그러나 개발이 진행되면서 서비스 로직이 점점 비대해졌고, 그 결과 여러 레포지토리에 의존하는 서비스들이 생겨났다.

이런 구조는 테스트를 작성하는 데 어려움을 주었고,

특히 의존하고 있는 모든 레포지토리를 모킹하는 데 많은 복잡성이 따랐다.

이 상황에서 "어떻게 하면 테스트를 더 용이하게 할 수 있을까?"라는 고민을 하게 되었다.

프로젝트 코드를 분석하면서 서비스의 로직을 분리하여

조회 작업과 쓰기 작업에 사용되는 레포지토리를 분리하여 불필요한 의존성을 제거한다면

테스트 작성에 보다 용이할 수 있겠다라고 생각했다.

그렇기에 조회용 서비스와 그 외에 쓰기용 서비스를

각각 Reader와 Writer로 나누어, 불필요한 의존성을 제거하는 방향으로 리팩토링 계획을 세웠다.

더불어, 각 클래스를 살펴보면서 책임을 보다 명확히 정의하고,

서비스를 분리함과 동시에 필요시에는 추가로 서비스를 나눔으로써

단일 책임 원칙(SRP)을 최우선으로 지키는 방향으로 리팩토링을 진행하기로 했다.

이를 통해 서비스 로직이 간결해지고, 테스트 시에도 필요한 부분만 모킹하거나 대체할 수 있어,

테스트가 더 용이해질 것으로 기대했다.

결과적으로, 이 리팩토링의 주된 목적은 불필요한 의존성을 제거하고, 코드의 책임을 명확히 분리하여 유지보수성과 테스트 가능성을 향상시키는 것이었다.

리팩토링을 하면서 느낀 점

도메인 계층을 분리하여 비즈니스 로직을 보다 명확히 이동시키기

서비스 계층을 애플리케이션 계층과 도메인 계층으로 분리하면서 얻을 수 있었던 장점을 나름대로 생각해봤다.

1. 책임의 명확한 분리

애플리케이션 계층은 사용자 요청을 처리하고, 도메인 계층과 협력하여 필요한 작업을 수행하는 역할을 담당하도록 했다.

이 계층은 도메인 계층과 레포지토리가 협력할 수 있는 무대를 제공하며, 애플리케이션의 유스케이스(Use Case)를 구현하는 데 집중했다.

도메인 계층은 비즈니스 도메인을 표현하는 클래스들로, 비즈니스 문제를 해결하는 핵심 로직을 담도록 했다.

도메인 객체들끼리만 협력하도록 함으로써, 비즈니스 로직이 외부의 변화에 영향을 받지 않도록 하고, 도메인의 순수성을 유지할 수 있었다.

프로젝트가 복잡한 도메인을 다루지는 않았지만, 서비스 계층을 분리한 덕분에 코드가 더 단순하고 명확해졌음을 느낄 수 있었다.

2. 도메인 계층의 독립성 및 순수성 유지

도메인 계층을 다른 계층으로부터 분리함으로써,

도메인 객체들이 외부 라이브러리나 인프라스트럭처 계층에 의존하지 않도록 했다.

이로 인해 도메인 로직은 외부 변화에 흔들리지 않고, 오직 비즈니스 문제 해결에만 집중할 수 있었다.

또한, 도메인 계층의 코드가 다른 계층의 변화에 영향을 받지 않게 되어 유지보수가 더욱 용이해지고, 코드의 일관성을 유지할 수 있었다.

3. 테스트 용이성 향상

각 계층이 명확히 분리됨에 따라, 테스트도 훨씬 더 쉽게 수행할 수 있었다.

도메인 계층은 순수한 비즈니스 로직만을 담고 있기 때문에 외부 의존성이 없고, 단위 테스트가 훨씬 간편해졌다.

이를 통해, 테스트 코드 작성이 용이해졌다.

4. 유연한 확장성

애플리케이션 계층에서 새로운 유스케이스가 추가되더라도 도메인 계층을 수정할 필요가 없었고, 반대로 비즈니스 로직이 변화하더라도 애플리케이션 계층에 최소한의 영향만 미치게 되었다. 이러한 유연성 덕분에, 시스템을 더 쉽게 확장할 수 있게 되었다.

5. 유지보수성 향상

각 계층의 책임이 명확히 분리되어 있기 때문에, 특정 기능이나 로직을 찾고 수정하는 과정이 훨씬 간단해졌다. 이를 통해 시스템의 복잡성이 줄어들고, 유지보수가 용이해졌다.

이렇게 나름대로 느꼈던 것과 생각한 장점들을 나열해보았다.

결론적으로, 서비스 계층을 애플리케이션 계층과 도메인 계층으로 분리함으로써,

책임 분리와 테스트 용이성, 도메인의 순수성 유지라는 여러 가지 장점을 얻을 수 있었다.

하지만! 오버엔지니어링이라는 생각이 들었다!

위에서 나열한 것처럼 장점만 있는 것은 아니었다.

오히려 단점을 통해 스스로 깨달은 게 더 많았다...ㅠㅠ

이제는 서비스 계층을 애플리케이션 계층과 도메인 계층으로 분리하면서 몇 가지 단점을 끄적여보려고 한다.

1. 도메인 객체 변환의 추가 작업

서비스 계층에서는 도메인 객체를 사용하기 위해,

레포지토리에서 반환되는 엔티티를 도메인 객체로 변환하는 작업을 신경 써야 했다.

이 과정에서 매핑 메서드를 만드는 변환 로직이 추가되면서 개발 속도가 느려질 수 있었다.

특히, 이 변환 작업이 반복되면서 실수로 특정 변수를 변환하지 않았던 적이 생겨서 제대로 된 응답을 내리지 못할 뻔 했다.

2. 구조의 복잡성 증가

애플리케이션 계층과 도메인 계층을 추가로 분리하면서, 전체 코드 구조가 복잡해졌다.

계층 간의 책임이 명확히 분리된다는 장점이 있지만, 그만큼 각 계층 간의 상호작용을 이해하고 관리하는 데 시간이 더 필요했다. 작은 프로젝트나 단순한 도메인을 다루는 경우에는 이 복잡성이 오히려 부담으로 작용할 수 있었다.

3. 오버엔지니어링의 우려

리팩토링을 진행하면서 가장 크게 느낀 점은, 현재 프로젝트가 복잡한 도메인을 다루지 않기 때문에, 이 정도로 계층을 분리할 필요가 있었을까 하는 고민이었다. 결과적으로, 이번 리팩토링이 오버엔지니어링에 가까웠다는 생각이 들었다. 복잡성이 낮은 도메인과 작은 규모의 애플리케이션에서는 이러한 계층 분리가 오히려 불필요하다는 점을 직접 경험하게 되었다.

배운 점

이번 리팩토링을 통해 몇 가지 배운 점이 있었다.

서비스 계층에 대한 이해도가 한층 높아졌고, 어떻게 하면 도메인에 집중할 수 있는 코드를 작성할 수 있을지에 대한 해답을 찾을 수 있었다.

또한, 복잡한 도메인을 다루는 경우에는 이런 식의 계층 분리가 유효한 해결책이 될 수 있다는 점도 배웠다.

결국, 이번 리팩토링은 오버엔지니어링이었다고 판단되지만,

이를 통해 복잡한 도메인 구조를 어떻게 다룰지에 대한 깊이 있는 이해와 소중한 경험을 얻었다는 점에서 큰 의미가 있었다. 이러한 경험을 바탕으로, 앞으로 더 나은 설계 결정을 내릴 수 있을 것이라 생각한다.

의존성 역전 원칙(DIP)을 적용하여, 의존성을 낮추고 테스트에 용이한 코드로 변경하기

이번에는 의존성 역전 원칙(DIP)을 적용하여 얻은 장점과 단점을 정리해보면 다음과 같다.

대표적인 장점은 앞서 리팩토링 방향성에 대해 언급하면서 나왔던 내용이다.

장점

JPA에 대한 의존성 제거

의존성 역전 원칙(DIP)을 적용함으로써, 서비스(즉, 애플리케이션 계층)에서 JPA에 대한 직접적인 의존성을 제거할 수 있었다. 이를 통해 서비스 계층은 특정 기술 스택 (현재는 JPA)에 종속되지 않게 되었고, 코드의 유연성과 유지보수성이 향상되었다.

단점

오버엔지니어링의 우려

현재 프로젝트에서는 JPA가 아닌 다른 기술 스택을 사용할 계획이 없었기 때문에, 이러한 의존성 제거가 실질적인 필요성에 부합하지 않았다. 결과적으로, 이는 오버엔지니어링에 가까운 접근이 되었고, 추가적인 복잡성을 불필요하게 초래했다. 구조적으로 복잡성이 증가함에 따라, 작은 규모의 프로젝트인 지금의 프로젝트에서는 오히려 관리가 더 어려워졌다고 생각된다.

배운 점

DIP를 적용하여 얻은 장점은 분명 존재하지만, 프로젝트의 실제 요구사항과 규모를 고려하지 않은 채 적용하면 오버엔지니어링의 위험이 있다는 점을 깨닫게 되었다. 이러한 경험을 통해, 앞으로는 기술적 선택이 실제 필요와 적절히 맞아떨어지는지를 더 신중히 고려해야 한다는 교훈을 얻었다.

그럼에도 이번 리팩토링을 통해 DIP에 대한 이해도가 크게 높아졌고, 이러한 구조에 대한 깊이 있는 고민과 실제 적용 경험을 쌓을 수 있었다. 만약 이 리팩토링을 하지 않았다면, DIP를 실제로 프로젝트에 어떻게 적용해야 하는지에 대한 감각을 익히기 어려웠을 것이다. 이 경험은 향후 더 복잡한 도메인을 다루거나 유연성이 요구되는 프로젝트에서 큰 도움이 될 것이라 생각한다.

정리

아키텍처를 변경하는 코드 구조의 리팩토링에 있어서 신중한 결정이 필요하다는 점을 이번 경험을 통해 더욱 깊이 깨닫게 되었다. 흔히들 "아키텍처에는 상황에 따른 적절한 판단이 필요하다"고 말하지만, 실제로 리팩토링을 진행하면서 이 말의 진정한 의미를 몸소 체감했다.

비교적 간단한 프로젝트에서도 구조를 개선하는 데 많은 시간이 소요된다는 점을 실감했으며,

이는 아키텍처 변경이 단순히 기술적 선택에 그치는 것이 아니라, 프로젝트의 전체적인 방향성을 재검토하는 과정임을 깨닫게 해주었다.

물론, 내가 이를 직접 적용하면서 겪었던 시행착오도 없지 않았지만, 이러한 경험이 오히려 더 큰 배움으로 다가왔다.

리팩토링을 통해 코드 구조를 보는 관점이 넓어졌고, 어떤 아키텍처가 "좋다" 또는 "나쁘다"는 단순한 이분법적인 판단이 아닌, 상황에 맞는 적절한 선택이 중요하다는 점을 알게 되었다.

리팩토링의 방향성을 설정하는 과정에서도 많은 고민이 있었지만, 이를 실제로 적용하면서 매 순간 더 많은 고민이 필요했다. 그럼에도 불구하고 직접 리팩토링하고 코드를 개선해 나가는 과정에서 느낀 점이 훨씬 컸다고 생각한다.

의존성을 줄이고, 각 클래스의 단일 책임 원칙을 지키는 방향으로 리팩토링을 진행하면서, 단순히 글이나 책, 강의를 통해 얻을 수 없는 실질적인 경험과 인사이트를 얻을 수 있었다.

지금 이 블로그 글을 작성하는 시점이 리팩토링을 완료한 지 약 2주가 지난 시점이지만,

그 과정에서 얻은 인사이트와 성장에 대한 자신감은 여전히 크게 남아 있다. 비록 장단점에 대해 나열하는 글이 되긴 했지만, 이번 리팩토링을 통해 얻은 경험이 나에게는 소중한 자산이 되었다고 자부할 수 있다.

긴 글을 읽어주셔서 감사드리며, 만약 추가로 의견이 있으시다면 언제든지 댓글로 남겨주세요.

감사합니다!

[외주] 리팩토링 방향성

k9want — Wed, 10 Jul 2024 02:57:32 +0900

이전 글에서 주저리 주저리 일대기까지 쓰면서

마지막에 외주 프로젝트 관련 느꼈던 고민거리나 문제들을 해결하고자,

우선 리팩토링부터을 진행하고자 한다.

일단 리팩토링을 하려고 하는 이유

현재 구현에 급급해서 객체지향적인 코드보단 절차지향적인 코드로 구현되어있다.

(이는 책을 통해서도 많이 깨달았는데.)

그 때문인지 테스트 작성를 짜는데에 있어서 의존성 및 여러 역할과 책임이 제대로 분리되지 않아서 어려움이 있다.

테스트 작성 시 의존성 관련해서 어려움을 겪고 있다면,

설계에 대한 문제의 가능성이 있다고 알려주는 경우가 많다고 한다.

그렇기에 객체지향적이면서 SOLID한 코드로 이번에 리팩토링하려고 한다.

리팩토링으로 얻고자 하는 것

- 객체지향적 + SOLID한 코드를 만들어 유지보수가 수월하도록 하기 위함

- 데이터에 의존적인 코드가 아닌 코드로 변경

- 불필요한 의존성을 끊거나 약하게 함으로써 보다 테스트에 용이한 코드로 만들기 위해

리팩토링 방향성

https://foregoing-bit-2cc.notion.site/09ee785d5f604b9fb60b1e5b5bfdfbed

리팩토링 구체화 | Notion

일단 내가 리팩토링을 하는 이유

foregoing-bit-2cc.notion.site

구체적인 리팩토링 방향은 해당 노션을 통해 정리했습니다.

[외주] 외주 같지 않은 외주 작업 - 제대로 된 스프링 프로젝트 경험하기 (feat. 그 동안의 나를 되돌아보기)

k9want — Wed, 10 Jul 2024 01:28:23 +0900

뜬금없이 뿜뿜해버렸따!

원래는 외주프로젝트에 대한 리팩토링을 적으려고 했는데

갑자기 그동안의 나에 대해 적어보고 리마인드하고 싶은 욕구가 뿜뿜해버렸따!! 으아악!!!

아무도 궁금해하지 않을 수 있지만,

지금까지 살아온 나의 행적?!들을 되돌아보고

앞으로의 방향도 구체적으로 잡아가고 이렇게 생각나는대로 글을 적어본다.

그동안의 나를 돌아보며,

그동안 블로그에 나에 대한 걸 적은 기억이 거의 없는 듯하여

오늘은 지금까지 살아온? 나를 돌이켜보고

어떻게 하다가 Semi 외주를 맡았는지까지 적어보려고 합니다.ㅎㅎ

처음 개발을 하게 된 건 3학년 2학기 어느 날이었죠..

때는 대학교 3학년 2학기

개발 경험이 아예 없던 저는

대외활동을 하고 싶어서

여러 동아리나 프로젝트에 "나도 할래요" 라면서 수많은 지원서를 냈었다.

그러다가 최종 면접까지 합격했던

서울시 산업진흥원?SBA에서 진행하는 개발자 양성 교육을 받는 기회가 왔고,

곧바로 시작했다.

안드로이드 개발자를 1순위로 하였으나,

생각치도 못했던 백엔드 과정을 들어야 한다는 소식에

불안하고 막연하고 무섭기만 했으나,

여러 밤샘과 구글링 (이 때부터 왜 개발자는 구글이 없으면 살지 못하는가를 뼈저리게 느꼇다. 지금 챗GPT....)

으로 개발이란 거에 아주 쪼금은 느낌 정도 잡았던 것 같다.

그러고 협업 프로젝트를 하면서 잠깐이나마 서비스 출시까지 했다.

허나 4학년이 되고 어떤 걸 더 해야하는지 몰랐던 저는 졸업프로젝트만 하고,

흐지부지 어영부영 공부 조금씩하면서 졸업을 했다.

본격적인 취업 스트레스... 허나 금방 탈출했다.

취업 스트레스는 4학년 2학기가 되면서 시작되었고,

졸업 전부터 이미 많은 곳에 지원서를 넣고 코테도 보고 면접도 보면서

많은 탈락과 쓴맛을 봐야했으나,

아주 고맙게도 나를 불러주는 곳은 있었다.

채용연계형 인턴으로 6개월 인턴활동 후 정규직 채용을 하는 M사였고,

바로 감사합니다. 하면서 바로 가지는 않았다... ;;;

첫 회사기에 섣불리 판단하고 싶지 않았는데...

나의 불안한 마음 끝내

3일 뒤에 다니겠다는 의사를 표했고

그곳에서는 나를 좋게 봐주셨는지 기다리고 있었다면서 바로 ㅇㅋ해주었다.

스프링 너를 첨 본 순간 나의 머리는 하얘졌다.

비록 졸업하기 전까지 Node.js 백엔드 개발자로 희망했으나,

졸업 전 취업한 곳은 우연치 않게도 코프링이었고,

그 뒤로 인턴으로 6개월간 일하면서

왜 다들 스프링 스프링 할까?라는 의문이 조금씩 이해해질 때쯤

인턴 기간은 끝나게 되었고, 정규직 오퍼를 받았으나,

일하면서 공허한 느낌이 나에게는 너무나 크게 느껴져서였던걸까?!

공허함은 점차 미래의 불안함으로 느껴지고,

이대로 가다가는 기초공사가 부실한 건물마냥

어느 순간에 와르르 무너져 내릴 것 같다는 생각이 들었다.

스프링에 대한 기초적인 공부 및 객체지향적인 사고 부족, 자바언어와 코틀린 언어의 미숙함

이런 것들을 극복하면서 6개월간 주어진 업무를 해냈지만,

하면서도 단순 처리만 할 뿐

정작 내가 왜 그런 생각을 통해 왜 이런 코드를 짰는지에 대한 확신이 많이 없었다.

(그럴 수 밖에 없었던게 잘 모르고 썼던 게 가장 큰 이유같다.)

그렇게 거절의사를 밝히고 퇴사를 했다.

6개월 간의 경험

다녔던 회사는 인턴이라고 사내 프로젝트와는 무관한 프로젝트를 하지 않았다.

사내 프로젝트 개발에 투입되어서

처음에는 QA 담당으로 테스트 코드를 작성하고,

여러 기능목록, 기획 회의, DB 설계(ERD) 회의,

API 명세서 등 많은 경험할 수 있게 해주셨다.

지금와서 생각해보면

채용연계형이고, 사내의 모든 개발자님들과 소통하고 협업하여

같이 일할지 판단하는 걸 모든 분들이 정하기에

인턴이라도 프로젝트에 참여하도록 하셨던 것 같다고 추측....

종종 대표님께서는 가끔 인턴 3인방(저 포함 2명의 한 달 먼저 입사한 동기들)들을

불러서 많은 인사이트를 얻을 수 있도록 교육을 해주셨는데,

이 때 개발에 관한 여러 인사이트들을 얻을 수 있었다.

그 중에서도 도메인에 대한 이해를 가장 많이 강조하셨었다.

당시에는 그렇게 도메인에 대한 이해가 중요할까? 싶었지만,

퇴사 후 여러 책들을 읽어보면서

도메인의 중요성을 깨달았다...

(그 때로 돌아간다면 사내 프로젝트 관련 도메인(feat.복잡한 물류체인 관련) 마스터하고 개발했을거에요.. 죄송합니다..)

그렇게 퇴사 후

퇴사 후 몇 달동안 리프레시도 하고 <- 허허 한것도 없으면서 리프레시...ㅋㅋ

다시 마음을 다잡고 초심으로 돌아가서 공부를 시작했다.

6개월간의 나름 현업에서 일하면서 스프링에 대해 공부해보고 싶었고,

NodeJS(ExpressJs)에서 Spring으로 기술스택을 바꾸기로 했다.

이 선택으로 다시 재취업이 늦어지는 걸수도 있지만,

덕분에 많은 걸 배웠기에 후회하지는 않는다.

대학교 2학년 객체지향 수업 이후 자바는 보지도 않았기에...

자바부터 객체지향, 인프런 김영한님의 강의까지 보고

오브젝트, 객체지향의 사실과 오해(토끼책), 개구리책, JPA 관련 책, 관련 여러 강의들 등등.

책과 강의 공부만 주먹구구식으로 했던 것 같다...

지금 와서 돌이켜보면

더 빨리 프로젝트를 해볼껄이라고 생각이 든다.

프로젝트에 내가 그동안의 공부한 걸 즉각적으로 녹이면서

응용하면서 했어야 했는데 미루기만 했던 건 조금 후회된다...

앞으로는 그러지 말자!!

이러한 경험을 통해 나쁜 습관은 없애면서

점차 내가 앞으로 개발자로서 성장하기에 좋은 습관만 남겨서 더 빨리 성장하는 계기가 된다고 믿고

앞으로를 살아가면 된다! ㅎㅎ

아!! 2023년도에 가장 아쉬웠던 건

예비군으로 인해 듣고 싶었던 교육의 코테 날짜와 겹치면서 못하게 되었을 때였다.

이 때는 예비군을 미룰 수 있다는 걸 몰랐다... 바보... ㅠㅠ

나의 생각과는 조금은 다른 교육과정...(feat.하지만 생명연장은 가능)

그렇게 시간은 2024년이 된다.

2024년도 여전히 혼자서 공부하고 있었다.

근데 시간이 지나면서 조금은 나태해짐이 생겼고,

환경을 바꿔야 겠다는 생각이 많이 들었다.

올해 초 아무래도 취준하면서 겪는 힘든 부분은

심적인 부분도 있지만, 금전적인 부분도 존재한다.

알바를 하고 싶지는 않고, 나의 미래를 위해 투자하는 시간을 가급적이면 놓고 싶지않아서

여러 방법을 생각하다가

F사 주관하는 국비교육을 신청했다.

해당 교육을 신청한 가장 큰 이유는 온라인 + 기업의 비즈니스 문제를 함께 해결하는 기회인 FINAL 프로젝트였다.

그것만 바라보고 지원했다.

글을 쓰고 있는 지금도 다달이 겨우겨우 30만원정도 주는 교육비로 생명을 연명중이다.

교육을 듣는 중간 중간 많은 여러가지 프로젝트를 진행하고자 했으나,

계속 무산되는 경우가 다반사였다.

더불어 해당 국비교육 특성상 개발을 처음하는 분들도 다수였기에

템포가 달라서 나는 다름 템포로 진행하고자 하는 마음이 계속 컸다.

파이널까지는 기간이 오래 남았고,

마음은 초조해져갔기에

매주 한번 씩 인프런, Hola, 링커리어 등등 들어가면서

프로젝트 경험을 계속 모색했다.

우연치 않게 본 외주 공지

그러다가 문득

코xx에서 FE 개발자 양성 과정 중에 FINAL 프로젝트를 위해

백엔드개발자와 디자이너를 뽑는 공지를 보게 되었다.

그동안 프로젝트는 하지 않고 단순히 공부만 했기에...

그렇게 이제는 더 이상 뒤로 미루기!! 그만!!! 이라는 마음으로 지원했다.

무엇보다도 내 스스로가 포트폴리오에도 넣고 싶은 프로젝트를 해야겠다는 마음도 겹쳤기에

무작정 지원하고 면접까지 보게 되었다.

면접 때는 스프링에 대한 경험이 없는 것이 조금은 흠이 되었으나,

3학년 때 어렴풋이나마 출시했던 서비스

(이제와서 말하지만, 많이 부족했으나 현직 디자이너님의 캐리로 디스콰이엇 실시간 2등까지 올랐었다.)

6개월간의 인턴 경험을 높이 사셨는지 통과해서 할 수 있게 되었다.

공지에서는 엄청 많은 걸 바라는 듯하면서도 아닌 듯해서

잘 몰랐는데 이제와서 돌이켜보면 생각보다 많은 걸 바라지는 않았던 것 같다.

단순히 개발만 가능하다면 다 되었던 것 같다.

그렇게 시작된 외주 같지 않은 외주 프로젝트

5명의 FE 교육생과 나 포함 2명의 백엔드 마지막으로 디자이너 한 분해서

총 8명이서 6주간 프로젝트를 기획부터 완료까지 하는 외주 같지 않은 외주프로젝트를 시작하게 되었다.

(나름 소소한 용돈벌이는 되었다.)

기획을 모두 다 같이 해야하지만,

나는 최대한 FE 교육생들이 원하는 걸 들어주고 싶었기에 기획을 맡기고

추후 점검하는 방향으로 진행했다.

나는 다른 한분과 같이

CI/CD 구축과 배포 서버를 구축을 우선으로 진행했고,

그 동안 기획이 fix되는 걸 기다렸다.

하지만 계속 기획이 변경되었기에

같이 기획회의에 참여하고 좀 더 프로젝트를 이해하는데에 집중했다면,

더 좋았을텐데 라는 생각이 들었다.

실제로 개발자에게 중요한 건 해당 도메인에 대한 이해인데...이를 당시엔 조금 망각했던 것 같다.

그래서 그랬는지 마지막 주에는 이 선택에 대한 아쉬움과 FE 분들께 미안함 마음이 들었다.

3주간의 기획과 3주간의 개발

그렇게 3주만에 겨우겨우 기획은 fix되었고,

그 사이에 나와 다른 백엔드분은 여러 컨벤션과 방향성을 다 잡은 상태였기에 바로 개발에 들어갔다.

나는 문서화에 대한 중요성을 알기에

무작정 개발하기 보다는 추후 테스트 작성도 고려하여

API 명세서와

용어를 어떻게 하면 좋을지 모르겠으나. API Design?! 세부 명세서?! 기능명세서?라고 해야하나

그걸 우선시 적고 작업했다.

이는 추후 프론트분들에게 상당히 많은 도움이 되었다기에 뿌듯했다.

더불어 이 글을 쓰고 난 후 진행할 리팩토링 후에

진행할 테스트에서도 많은 도움이 될 거라고 확신한다. ㅎㅎ (다행, 기특)

생각보다 도메인은 그렇게 복잡하지는 않았다.

단순하게 생각하면 여행 계획 커뮤니티라고 할 수 있는 기획이 덮여있는 CRUD 구현?!이라고 할 수도 있다.

그렇기에 이 프로젝트뿐만 아니라

혼자서 REST API를 보내는 프로젝트를 진행할 예정이다.

(feat. 예매, 동시성 이슈가 있을 만한 프로젝트 혹은 기능을 혼자서 개발해보고 겪을 필요가 있다고 판단되기에)

그래도 API명세서를 보면 40개의 API가 나왔다.

깨알 모자이크 허허 혹시 몰라서?! ㅎㅎ

프론트분들이 백엔드와 같이 협업해본 경험이 없기에

문서를 작성했고, 이를 바탕으로 의논하고 설명해줬다.

나중에 프론트분들이 이해하는데 많은 도움이 되었다고 한다. ㅎㅎ

아쉬웠던 건 프론트분들이 다들 바쁘셔서 문서 최신화를 조금은 신경쓰지 않았던 점인데..

왜 일했을 때 최신화를 자주 하라고 다들 그러셨는지 알 것 같다. ㅎㅎ

개발하면서 테이블 구조를 JOIN 테이블로 바꾼 것과

N+1을 막기 위해 FETCH JOIN을 사용하고

이 FETCH JOIN 사용 시점을 미리 땡겨서 메서드가 시작할 때 한 번에 조회하도록 하는 등

조회 관련된 부분에 많은 신경을 썼다.

하지만 확실한 지표나 수치가 없어서 나중에 서비스화된다면 어떻게 될까 라는 의문들었다.

그렇기에 성능, 부하 테스트를 하는 듯 하다. (아직은 둘을 경험하지 않았기에 일단은 같이 적는다.)

그 필요성을 느끼기엔 적합했던 프로젝트였다.

- 좀더 자세히 설명하면 단순하게 테이블을 select할 때와 join해서 한번에 긁어올때 어떤게 좋을까?

- 이는 직접 지표를 통해 알고 싶었다.

3주간의 일정도 끝나고 개발은 완료했다.

그리고 정산까지.. (그 와중에... 10% 세그므...ㅠㅠ)

하지만 시작은 지금부터

해당 프로젝트가 끝나고

개발 일정에 쫓겨서 포스트맨으로 밖에 테스트하지 못했다.

즉, 가장 중요한 테스트를 작성하지 않았다.

더불어 구현에만 급급한 나머지 코드들도 많은 걸 놓친게 보였다.
(유지보수 관련 좋지 않은 코드의 냄새가 풀풀 난다.)

그렇게 끝내고 일주일 간

자바/스프링 개발자를 위한 실용주의 프로그래밍 이라는 책을 다 읽고

3장 테스트는 노션에 요약하지 않았지만, 다른 부분까지는 다시 한번 읽으면서

요약하고 프로젝트에 적용할 만한 걸 간추렸다.

지금까지 읽었던 책들의 내용이 저 책에 녹아있는 듯하다.

더불어 부족했던 무언가를 긁어주는 느낌이 들었다.

책을 읽으면서 너무 좋아서 피식 웃었던 것 같다.

(이 책을 왜 이제야 읽을까 하면서...)

무튼 그래서 지금부터가 시작이라고 생각한다.

전에는 개발하고 끝!!

이랬지만, 이 또한 나의 나쁜 습관 중에 하나라고 생각한다.

내가 꼭 회사의 취업을 위해서가 아닌 회사에서 최소 1인분은 하는 개발자가 되기 위해서는

여기서 끝내는게 아니란걸 잘 알기에

이제부터 리팩토링부터 테스트 더 나아가 앞서 필요성을 느꼈던 성능테스트, 부하테스트까지 해서

프로젝트를 점차 디벨롭할 예정이며 그 사이에 생기는 여러 일들을 블로그에 이렇게 주저리주저리 적어보려고 한다.

앞부분을 너무 많이 적느라 정작 중요했던 외주 관련 내용이 많이 안 써진듯 하지만,

간략하게나마 있었던 일들을 적었던 것 같다.

마지막으로 긴글 읽어주셔서 감사합니다. ㅎㅎ

[강의메모] 스프링 DB 2편 -데이터 접근 활용 기술 - ch10. 스프링 트랜잭션 전파 1 - 기본

k9want — Sat, 27 Apr 2024 21:13:58 +0900

(복습) 스프링 트랜잭션 전파 - 트랜잭션 (각각) 두 번 사용

트랜잭션이 각각 따로 사용되는 경우 :

하나의 트랜잭션이 완전히 끝나고 나서 다음 트랜잭션을 수행한다.

예시 코드

@Test
void double_commit() {
    log.info("트랜잭션1 시작");
    TransactionStatus tx1 = txManager.getTransaction(new DefaultTransactionAttribute());
    log.info("트랜잭션1 커밋");
    txManager.commit(tx1);
	
    log.info("트랜잭션2 시작");
    TransactionStatus tx2 = txManager.getTransaction(newDefaultTransactionAttribute());
    log.info("트랜잭션2 커밋");
    txManager.commit(tx2);
}

로그를 보면 트랜잭션1과 트랜잭션2가 같은 conn0 커넥션을 사용중이다.

이것은 중간에 커넥션 풀 때문에 그런 것이다.

트랜잭션1은 conn0 커넥션을 모두 사용하고 커넥션 풀에 반납까지 완료했다.

이후에 트랜잭션2가 conn0 를 커넥션 풀에서 획득한 것이다.

따라서 둘은 완전히 다른 커넥션으로 인지하는 것이 맞다.

HikariProxyConnection@XXXX wrapping conn0:

히카리 커넥션 풀에서 커넥션을 획득하면 실제 커넥션을 그대로 반환하는 것이 아니라 내부 관리를 위해 히카리 프록시 커넥션이라는 객체를 생성해서 반환한다.

물론 내부에는 실제 커넥션이 포함되어 있다.

이 객체의 주소를 확인하면 커넥션 풀에서 획득한 커넥션을 구분할 수 있다.

트랜잭션이 각자 관리된다. (커밋, 롤백)

트랜잭션이 각각 수행되기에 사용되는 DB 커넥션도 각각 다르다.

따라서 이런 경우에는 트랜잭션을 각자 관리하기 때문에 전체 트랜잭션을 묶을 수 없다.

(지금부터 시작) 스프링 트랜잭션 전파 - 기본옵션 (REQUIRED)

트랜잭션을 각각 사용하는 것이 아니라, 트랜잭션이 이미 진행중인데, 여기에 추가로 트랜잭션을 수행하면 어떻게 될까?

기존 트랜잭션과 별도의 트랜잭션을 진행해야 할까?

아니면 기존 트랜잭션을 그대로 이어 받아서 트랜잭션을 수행해야 할까?

이런 경우 어떻게 동작할지 결정하는 것을 트랜잭션 전파(propagation)라 한다.

(예제) 외부 트랜잭션이 수행중인데, 내부 트랜잭션이 추가로 수행됨

외부 트랜잭션이 수행중이고, 아직 끝나지 않았는데, 내부 트랜잭션이 수행된다.
외부 트랜잭션이라고 이름 붙인 것은 둘 중 상대적으로 밖에 있기 때문에 외부 트랜잭션이라 한다. 처음 시작된 트랜잭션으로 이해하면 된다.
내부 트랜잭션은 외부에 트랜잭션이 수행되고 있는 도중에 호출되기 때문에 마치 내부에 있는 것 처럼 보여서 내부 트랜잭션이라 한다.

스프링에서 이 경우 외부 트랜잭션과 내부 트랜잭션을 묶어서 하나의 트랜잭션을 만들어준다.
내부 트랜잭션이 외부 트랜잭션에 참여하는 것이다. 이것이 기본 동작이고, 옵션을 통해 다른 동작방식도 선택할 수 있다.

물리 트랜잭션, 논리 트랜잭션이란?

스프링은 이해를 돕기 위해 논리 트랜잭션과 물리 트랜잭션이라는 개념을 나눈다.
논리 트랜잭션들은 하나의 물리 트랜잭션으로 묶인다.
물리 트랜잭션은 우리가 이해하는 실제 데이터베이스에 적용되는 트랜잭션을 뜻한다.
실제 커넥션을 통해서 트랜잭션을 시작(setAutoCommit(false)) 하고, 실제 커넥션을 통해서 커밋, 롤백하는 단위이다.
논리 트랜잭션은 트랜잭션 매니저를 통해 트랜잭션을 사용하는 단위이다.
이러한 논리 트랜잭션 개념은 트랜잭션이 진행되는 중에 내부에 추가로 트랜잭션을 사용하는 경우에 나타난다.
단순히 트랜잭션이 하나인 경우 둘을 구분하지는 않는다.

왜 논리, 물리 트랜잭션을 나누어 설명하는 걸까?

트랜잭션이 사용중일 때 또 다른 트랜잭션이 내부에 사용되면 여러가지 복잡한 상황이 발생한다. 이때 논리 트랜잭션 개념을 도입하면 다음과 같은 단순한 원칙을 만들 수 있다.

원칙

모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션이 커밋된다.
하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션은 롤백된다.

모든 트랜잭션 매니저를 커밋해야 물리 트랜잭션이 커밋된다.

하나의 트랜잭션 매니저라도 롤백하면 물리 트랜잭션은 롤백된다.

스프링 트랜잭션 전파 - 전파 (외부,내부[물리,논리] 트랜잭션이 전부 커밋일 경우)

@Test
void inner_commit() {
    log.info("외부 트랜잭션 시작");
    TransactionStatus outer = txManager.getTransaction(new DefaultTransactionAttribute());
    log.info("outer.isNewTransaction()={}", outer.isNewTransaction());
    
    log.info("내부 트랜잭션 시작");
    TransactionStatus inner = txManager.getTransaction(new DefaultTransactionAttribute());
    log.info("inner.isNewTransaction()={}", inner.isNewTransaction());
    
    log.info("내부 트랜잭션 커밋");
    txManager.commit(inner);
    
    log.info("외부 트랜잭션 커밋");
    txManager.commit(outer);
}

앞에 나온 트랜잭션 1,2 코드와 다른 부분은 처음 트랜잭션을 commit하기 전에 다른 트랜잭션이 시작한다는 점이다.

내부 트랜잭션을 시작할 때 Participating in existing transaction 이라는 메시지를 확인할 수 있다. 이 메시지는 내부 트랜잭션이 기존에 존재하는 외부 트랜잭션에 참여한다는 뜻이다.
실행 결과를 보면 외부 트랜잭션을 시작하거나 커밋할 때는 DB 커넥션을 통한 물리 트랜잭션을 시작(manual commit )하고, DB 커넥션을 통해 커밋 하는 것을 확인할 수 있다. 그런데 내부 트랜잭션을 시작하거나 커밋할 때는 DB 커넥션을 통해 커밋하는 로그를 전혀 확인할 수 없다.
정리하면 외부 트랜잭션만 물리 트랜잭션을 시작하고, 커밋한다.
만약 내부 트랜잭션이 실제 물리 트랜잭션을 커밋하면 트랜잭션이 끝나버리기 때문에, 트랜잭션을 처음 시작한 외부 트랜잭션까지 이어갈 수 없다. 따라서 내부 트랜잭션은 DB 커넥션을 통한 물리 트랜잭션을 커밋하면 안된다.
스프링은 이렇게 여러 트랜잭션이 함께 사용되는 경우, 처음 트랜잭션을 시작한 외부 트랜잭션이 실제 물리 트랜
잭션을 관리하도록 한다. 이를 통해 트랜잭션 중복 커밋 문제를 해결한다.

트랜잭션 전파 동작 흐름(이미지)

요청 흐름 - 외부 트랜잭션

1. txManager.getTransaction() 를 호출해서 외부 트랜잭션을 시작한다.
2. 트랜잭션 매니저는 데이터소스를 통해 커넥션을 생성한다.
3. 생성한 커넥션을 수동 커밋 모드( setAutoCommit(false) )로 설정한다. - 물리 트랜잭션 시작
4. 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다.
5. 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus 에 담아서 반환하는데, 여기에 신규 트랜잭션의 여부가
담겨 있다. isNewTransaction 를 통해 신규 트랜잭션 여부를 확인할 수 있다. 트랜잭션을 처음 시작했으므로 신규 트랜잭션이다.( true )
6. 로직1이 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 트랜잭션이 적용된 커넥션을 획득해서 사용한다.

요청 흐름 - 내부 트랜잭션

7. txManager.getTransaction() 를 호출해서 내부 트랜잭션을 시작한다.
8. 트랜잭션 매니저는 트랜잭션 동기화 매니저를 통해서 기존 트랜잭션이 존재하는지 확인한다.
9. 기존 트랜잭션이 존재하므로 기존 트랜잭션에 참여한다. 기존 트랜잭션에 참여한다는 뜻은 사실 아무것도 하지 않는다는 뜻이다. (그냥 기존 트랜잭션에 버스 타겠다는 뜻)

이미 기존 트랜잭션인 외부 트랜잭션에서 물리 트랜잭션을 시작했다. 그리고 물리 트랜잭션이 시작된 커넥션을 트랜잭션 동기화 매니저에 담아두었다.
따라서 이미 물리 트랜잭션이 진행중이므로 그냥 두면 이후 로직이 기존에 시작된 트랜잭션을 자연스럽게 사용하게 되는 것이다.
이후 로직은 자연스럽게 트랜잭션 동기화 매니저에 보관된 기존 커넥션을 사용하게 된다.

10. 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus 에 담아서 반환하는데, 여기엔 isNewTransaction를 통해 신규 트랜잭션 여부를 확인할 수 있다. 여기서는 기존 트랜잭션에 참여했기때문에 신규 트랜잭션이 아니다. ( false )
11. 로직2가 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 외부 트랜잭션이 보관한 커넥션을 획득해서 사용한다.

응답 흐름 - 내부 트랜잭션

12. 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋한다.
13. 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 이 경우 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않는다. 왜냐하면 실제 커넥션에 커밋이나 롤백을 호출하면 물리 트랜잭션이 끝나버린다. 아직 트랜잭션이 끝난 것이 아니기 때문에 실제 커밋을 호출하면 안된다. 물리 트랜잭션은 외부 트랜잭션을 종료할 때 까지 이어져야한다.

응답 흐름 - 외부 트랜잭션

14. 로직1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋한다.
15. 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 외부 트랜잭션은 신규 트랜잭션이다. 따라서 DB 커넥션에 실제 커밋을 호출한다.
16. 트랜잭션 매니저에 커밋하는 것이 논리적인 커밋이라면, 실제 커넥션에 커밋하는 것을 물리 커밋이라 할 수 있다. 실제 데이터베이스에 커밋이 반영되고, 물리 트랜잭션도 끝난다.

핵심 정리

핵심은 트랜잭션 매니저에 커밋을 호출한다고해서 항상 실제 커넥션에 물리 커밋이 발생하지는 않는다는 점이다.
신규 트랜잭션인 경우에만 실제 커넥션을 사용해서 물리 커밋과 롤백을 수행한다. 신규 트랜잭션이 아니면 실제물리 커넥션을 사용하지 않는다.
트랜잭션이 내부에서 추가로 사용되면, 트랜잭션 매니저를 통해 논리 트랜잭션을 관리하고, 모든 논리 트랜잭션이 커밋되면 물리 트랜잭션이 커밋된다고 이해하면 된다.

스프링 트랜잭션 전파 - 외부 롤백(내부 트랜잭션은 커밋되는데, 외부 트랜잭션이 롤백되는 경우)

논리 트랜잭션이 하나라도 롤백되면 전체 물리 트랜잭션은 롤백된다.

따라서 이 경우 내부 트랜잭션이 커밋했어도, 내부 트랜잭션 안에서 저장한 데이터도 모두 함께 롤백된다.

@Test
void outer_rollback() {
    log.info("외부 트랜잭션 시작");
    TransactionStatus outer = txManager.getTransaction(new DefaultTransactionAttribute());
    log.info("outer.isNewTransaction()={}", outer.isNewTransaction());
    
    log.info("내부 트랜잭션 시작");
    TransactionStatus inner = txManager.getTransaction(new DefaultTransactionAttribute());
    log.info("inner.isNewTransaction()={}", inner.isNewTransaction());
    
    log.info("내부 트랜잭션 커밋");
    txManager.commit(inner);
    
    log.info("외부 트랜잭션 롤백");
    txManager.rollback(outer);
}

외부 트랜잭션이 물리 트랜잭션을 시작하고 롤백하는 것을 확인할 수 있다.
내부 트랜잭션은 앞서 배운대로 직접 물리 트랜잭션에 관여하지 않는다.
결과적으로 외부 트랜잭션에서 시작한 물리 트랜잭션의 범위가 내부 트랜잭션까지 사용된다. 이후 외부 트랜잭션이 롤백되면서 전체 내용은 모두 롤백된다.

스프링 트랜잭션 전파 - 외부 롤백 흐름 (이미지)

(중요) 스프링 트랜잭션 전파 - 내부 롤백(내부 트랜잭션은 롤백인데, 외부 트랜잭션은 커밋되는 경우) UnexpectedRollbackException 발생

@Test
void inner_rollback() {
    log.info("외부 트랜잭션 시작");
    TransactionStatus outer = txManager.getTransaction(new DefaultTransactionAttribute());
    log.info("outer.isNewTransaction()={}", outer.isNewTransaction());

    log.info("내부 트랜잭션 시작");
    TransactionStatus inner = txManager.getTransaction(new DefaultTransactionAttribute());
    log.info("inner.isNewTransaction()={}", inner.isNewTransaction());

    log.info("내부 트랜잭션 롤백");
    txManager.rollback(inner);

    log.info("외부 트랜잭션 커밋 - 예외 발생");
    Assertions.assertThatThrownBy(() -> txManager.commit(outer))
         .isInstanceOf(UnexpectedRollbackException.class);
}

마지막에 외부 트랜잭션을 커밋할 때 UnexpectedRollbackException.class 이 발생하는 것을 확인할 수 있다.

내부 트랜잭션 시작

Participating in existing transaction
기존 트랜잭션에 참여한다.

내부 트랜잭션 롤백

Participating transaction failed - marking existing transaction as rollback-only
내부 트랜잭션을 롤백하면 실제 물리 트랜잭션은 롤백하지 않는다. 대신에 기존 트랜잭션을 롤백 전용으로 표시한다.

외부 트랜잭션 커밋

Global transaction is marked as rollback-only
커밋을 호출했지만, 전체 트랜잭션이 롤백 전용으로 표시되어 있다. 따라서 물리 트랜잭션을 롤백한다. 그러고는 커밋했지만 예기치 못한 롤백이 일어났다는 예외를 터트린다.

스프링 트랜잭션 전파 - 내부 롤백 (이미지)

응답 흐름 - 내부 트랜잭션

1. 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백한다. (로직2에 문제가 있어서 롤백한다고 가
정한다.)

2. 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 이 경우 신규 트랜잭션이 아니기 때문에 실제 롤백을 호출하지 않는다.
3. 내부 트랜잭션은 물리 트랜잭션을 롤백하지 않는 대신에 트랜잭션 동기화 매니저에rollbackOnly=true 라는 표시를 해둔다.

응답 흐름 - 외부 트랜잭션

4. 로직1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋한다.

5. 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 외부 트랜잭션은 신규 트랜잭션이다. 따라서 DB 커넥션에 실제 커밋을 호출해야 한다. 이때 먼저 트랜잭션 동기화 매니저에 롤백 전용 ( rollbackOnly=true ) 표시가 있는지 확인한다. 롤백 전용 표시가 있으면 물리 트랜잭션을 커밋하는 것이 아니라 롤백한다.
6. 실제 데이터베이스에 롤백이 반영되고, 물리 트랜잭션도 끝난다.

7. 트랜잭션 매니저에 커밋을 호출한 개발자 입장에서는 분명 커밋을 기대했는데 롤백 전용 표시로 인해 실제로는 롤백이 되어버렸다. ( 스프링은 이 경우 UnexpectedRollbackException 런타임 예외를 던진다. )

이것은 조용히 넘어갈 수 있는 문제가 아니다.

시스템 입장에서는 커밋을 호출했지만 롤백이 되었다는 것은 분명하게 알려주어야 한다.

예를 들어서 고객은 주문이 성공했다고 생각했는데, 실제로는 롤백이 되어서 주문이 생성되지 않은 것이다.

스프링은 이 경우 UnexpectedRollbackException 런타임 예외를 던진다.

그래서 커밋을 시도했지 만, 기대하지 않은 롤백이 발생했다는 것을 명확하게 알려준다.

정리

논리 트랜잭션이 하나라도 롤백되면 물리 트랜잭션은 롤백된다.
내부 논리 트랜잭션이 롤백되면 롤백 전용 마크를 표시한다.
외부 트랜잭션을 커밋할 때 롤백 전용 마크를 확인한다. 롤백 전용 마크가 표시되어 있으면 물리 트랜잭션을 롤백하고, UnexpectedRollbackException 예외를 던진다.

스프링 트랜잭션 전파 - REQUIRES_NEW (외부 트랜잭션과 내부 트랜잭션을 완전히 분리해서 사용)

외부 트랜잭션과 내부 트랜잭션을 완전히 분리해서 각각 별도의 물리 트랜잭션을 사용하는 방법이다.

그래서 커밋과 롤백도 각각 별도로 이루어지게 된다.

이 방법은 내부 트랜잭션에 문제가 발생해서 롤백해도, 외부 트랜잭션에는 영향을 주지 않는다. 반대로 외부 트랜잭션에 문제가 발생해도 내부 트랜잭션에 영향을 주지 않는다.

이렇게 물리 트랜잭션을 분리하려면 내부 트랜잭션을 시작할 때 REQUIRES_NEW 옵션을 사용하면 된다.
외부 트랜잭션과 내부 트랜잭션이 각각 별도의 물리 트랜잭션을 가진다.
별도의 물리 트랜잭션을 가진다는 뜻은 DB 커넥션을 따로 사용한다는 뜻이다.
이 경우 내부 트랜잭션이 롤백되면서 로직 2가 롤백되어도 로직 1에서 저장한 데이터에는 영향을 주지 않는다.
최종적으로 로직2는 롤백되고, 로직1은 커밋된다.

@Test
void inner_rollback_requires_new() {
    log.info("외부 트랜잭션 시작");
    TransactionStatus outer = txManager.getTransaction(new DefaultTransactionAttribute());
    log.info("outer.isNewTransaction()={}", outer.isNewTransaction());
    
    log.info("내부 트랜잭션 시작");
    DefaultTransactionAttribute definition = new DefaultTransactionAttribute();
    definition.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
    TransactionStatus inner = txManager.getTransaction(definition);
    log.info("inner.isNewTransaction()={}", inner.isNewTransaction());
    
    log.info("내부 트랜잭션 롤백");
    txManager.rollback(inner); // 롤백
    
    log.info("외부 트랜잭션 커밋");
    txManager.commit(outer); // 커밋
}

내부 트랜잭션을 시작할 때 전파 옵션인 propagationBehavior 에 PROPAGATION_REQUIRES_NEW 옵션을 주었다.
이 전파 옵션을 사용하면 내부 트랜잭션을 시작할 때 기존 트랜잭션에 참여하는 것이 아니라 새로운 물리 트랜잭션을 만들어서 시작하게 된다.

스프링 트랜잭션 전파 - REQUIRES_NEW(이미지)

요청 흐름 - 외부 트랜잭션

1. txManager.getTransaction() 를 호출해서 외부 트랜잭션을 시작한다.

2. 트랜잭션 매니저는 데이터소스를 통해 커넥션을 생성한다.

3. 생성한 커넥션을 수동 커밋 모드( setAutoCommit(false) )로 설정한다. - 물리 트랜잭션 시작

4. 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다.

5. 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus 에 담아서 반환하는데, 여기에 신규 트랜잭션의 여부가 담겨 있다. isNewTransaction 를 통해 신규 트랜잭션 여부를 확인할 수 있다. 트랜잭션을 처음 시작했으므로 신규 트랜잭션이다.( true )

6. 로직1이 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 트랜잭션이 적용된 커넥션을 획득
해서 사용한다.

요청 흐름 - 내부 트랜잭션

7. REQUIRES_NEW 옵션과 함께 txManager.getTransaction() 를 호출해서 내부 트랜잭션을 시작한다. 트랜잭션 매니저는 REQUIRES_NEW 옵션을 확인하고, 기존 트랜잭션에 참여하는 것이 아니라 새로운 트랜잭션을 시작한다.

8. 트랜잭션 매니저는 데이터소스를 통해 커넥션을 생성한다.

9. 생성한 커넥션을 수동 커밋 모드( setAutoCommit(false) )로 설정한다. - 물리 트랜잭션 시작

10. 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다. 이때 con1 은 잠시 보류되고, 지금부터는 con2 가 사용된다. (내부 트랜잭션을 완료할 때 까지 con2가 사용된다.) (보류되고 내부 트랜잭션으로 흐름이 넘어간다는게 중요!)

11. 트랜잭션 매니저는 신규 트랜잭션의 생성한 결과를 반환한다. isNewTransaction == true

12. 로직2가 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저에 있는 con2 커넥션을 획득해서 사용한다.

응답 흐름 - 내부 트랜잭션

1. 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백한다. (로직2에 문제가 있어서 롤백한다고 가정한다.)

2. 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 현재 내부 트랜잭션은 신규 트랜잭션이다. 따라서 실제 롤백을 호출한다.

3. 내부 트랜잭션이 con2 물리 트랜잭션을 롤백한다. 트랜잭션이 종료되고, con2 는 종료되거나, 커넥션 풀에 반납된다.

이후에 con1 의 보류가 끝나고, 다시 con1 을 사용한다. (보류가 끝난다는 부분이 중요!)

응답 흐름 - 외부 트랜잭션

4. 외부 트랜잭션에 커밋을 요청한다.

5. 외부 트랜잭션은 신규 트랜잭션이기 때문에 물리 트랜잭션을 커밋한다.

6. 이때 rollbackOnly 설정을 체크한다. rollbackOnly 설정이 없으므로 커밋한다. (다른 물리 트랜잭션이기에)

7. 본인이 만든 con1 커넥션을 통해 물리 트랜잭션을 커밋한다. 트랜잭션이 종료되고, con1 은 종료되거나, 커넥션 풀에 반납된다.

정리

REQUIRES_NEW 옵션을 사용하면 물리 트랜잭션이 명확하게 분리된다.
REQUIRES_NEW 를 사용하면 데이터베이스 커넥션이 동시에 2개 사용된다는 점을 주의해야 한다.

REQUIRED vs REQUIRES_NEW

REQUIRED

가장 많이 사용하는 기본 설정이다. 기존 트랜잭션이 없으면 생성하고, 있으면 참여한다.

트랜잭션이 필수라는 의미로 이해하면 된다. (필수이기 때문에 없으면 만들고, 있으면 참여한다.)

기존 트랜잭션 없음: 새로운 트랜잭션을 생성한다.
기존 트랜잭션 있음: 기존 트랜잭션에 참여한다.

REQUIRES_NEW

항상 새로운 트랜잭션을 생성한다.

기존 트랜잭션 없음: 새로운 트랜잭션을 생성한다.
기존 트랜잭션 있음: 새로운 트랜잭션을 생성한다.

[강의메모] 스프링 DB 2편 -데이터 접근 활용 기술 - ch9. 스프링 트랜잭션 이해(feat. 트랜잭션 AOP 사용시 주의 사항)

k9want — Sat, 27 Apr 2024 03:36:49 +0900

트랜잭션 적용 확인

@Transactional 을 통해 선언적 트랜잭션 방식을 사용하면 단순히 애노테이션 하나로 트랜잭션을 적용할 수 있다.

이 기능은 트랜잭션 관련 코드가 눈에 보이지 않고, AOP를 기반으로 동작하기 때문에, 실제 트랜잭션이 적용되고 있는지 아닌지를 확인하기가 어렵다.

확인하는 방법을 알아보자

@Slf4j
@SpringBootTest
public class TxBasicTest {

    @Autowired
    BasicService basicService;

    @Test
    void proxyCheck() {
        //BasicService$$EnhancerBySpringCGLIB...
        log.info("aop class={}", basicService.getClass());
        assertThat(AopUtils.isAopProxy(basicService)).isTrue();
    }

    @Test
    void txTest() {
        basicService.tx();
        basicService.nonTx();
    }

    @TestConfiguration
    static class TxApplyBasicConfig {

        @Bean
        BasicService basicService() {
            return new BasicService();
        }
    }

    @Slf4j
    static class BasicService {

        @Transactional
        public void tx() {
            log.info("call tx");
            boolean txActive =
                TransactionSynchronizationManager.isActualTransactionActive();
            log.info("tx active={}", txActive);
        }

        public void nonTx() {
            log.info("call nonTx");
            boolean txActive =
                TransactionSynchronizationManager.isActualTransactionActive();
            log.info("tx active={}", txActive);
        }
    }
}

proxyCheck() - 실행

AopUtils.isAopProxy() : 선언적 트랜잭션 방식에서 스프링 트랜잭션은 AOP를 기반으로 동작한다.
@Transactional을 메서드나 클래스에 붙이면 해당 객체는 트랜잭션 AOP 적용의 대상이 되고, 결과적으로 실제 객체 대신에 트랜잭션을 처리해주는 프록시 객체가 스프링 빈에 등록된다. 그리고 주입을 받을 때도 실제 객체 대신에 프록시 객체가 주입된다.
클래스 이름을 출력해보면 basicService$$EnhancerBySpringCGLIB... 라고 프록시 클래스의 이름이
출력되는 것을 확인할 수 있다.

스프링 컨테이너에 트랜잭션 프록시 등록

@Transactional 애노테이션이 특정 클래스나 메서드에 하나라도 있으면 트랜잭션 AOP는 프록시를 만들어서 스프링 컨테이너에 등록한다.

실제 basicService 객체 대신에 프록시인 basicService$$CGLIB 를 스프링 빈에 등록한다.

그리고 프록시는 내부에 실제 basicService 를 참조하게 된다.

여기서 핵심은 실제 객체 대신에 프록시가 스프링 컨테이너에 등록되었다는 점이다.

프록시는 BasicService 를 상속해서 만들어지기 때문에 다형성을 활용할 수 있다.

로그 추가

logging.level.org.springframework.transaction.interceptor=TRACE

이 로그를 추가하면 트랜잭션 프록시가 호출하는 트랜잭션의 시작과 종료를 명확하게 로그로 확인할 수 있다.

TransactionSynchronizationManager.isActualTransactionActive()

@Transactional
public void tx() {
   log.info("call tx");
    boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
  log.info("tx active={}", txActive);
}

현재 쓰레드에 트랜잭션이 적용되어 있는지 확인할 수 있는 기능이다.

결과가 true 면 트랜잭션이 적용되어 있는것이다. 트랜잭션의 적용 여부를 가장 확실하게 확인할 수 있다.

트랜잭션 적용 위치

스프링에서 우선순위는 항상 더 구체적이고 자세한 것이 높은 우선순위를 가진다.

메서드 > 클래스

인터페이스를 구현한 클래스 > 인터페이스

스프링의 @Transactional 은 다음 두 가지 규칙이 있다.
1. 우선순위 규칙 (클래스보다 메서드가 더 구체적이므로 우선순위)
2. 클래스에 적용하면 메서드는 자동 적용

TransactionSynchronizationManager.isCurrentTransactionReadOnly

현재 트랜잭션에 적용된 readOnly 옵션의 값을 반환한다.

readOnly=false 는 기본 옵션이기 때문에 보통 생략한다.

@Transactional == @Transactional(readOnly=false) 와 같다

인터페이스에 @Transactional 적용

1.   클래스의 메서드 (우선순위가 가장 높다.)
2.   클래스의 타입
3.   인터페이스의 메서드
4.   인터페이스의 타입 (우선순위가 가장 낮다.)

그런데 인터페이스에 @Transactional 사용하는 것은 스프링 공식 메뉴얼에서 권장하지 않는 방법이다.

AOP를 적 용하는 방식에 따라서 인터페이스에 애노테이션을 두면 AOP가 적용이 되지 않는 경우도 있기 때문이다.

가급적 구체 클래스에 @Transactional 을 사용하자.

(매우 중요)트랜잭션 AOP 주의 사항 - 프록시 내부 호출

앞서 언급했듯이 @Transactional 을 적용하면 프록시 객체가 요청을 먼저 받아서 트랜잭션을 처리하고, 실제 객체를 호출해준다.

따라서 트랜잭션을 적용하려면 항상 프록시를 통해서 대상 객체(Target)을 호출해야 한다.

이렇게 해야 프록시에서 먼저 트랜잭션을 적용하고, 이후에 대상 객체를 호출하게 된다.
만약 프록시를 거치지 않고 대상 객체를 직접 호출하게 되면 AOP가 적용되지 않고, 트랜잭션도 적용되지 않는다.

프록시 객체가 주입되기 때문에 대상 객체를 직접 호출하는 문제는 일반적으로 발생하지 않는다.

문제는 대상 객체의 내부에서 메서드 호출이 발생하면 프록시를 거치지 않고 대상 객체를 직접 호출하는 문제가 발생한다.

예시 코드

@Slf4j
static class CallService {

    public void external() {
        log.info("call external");
        printTxInfo();
        internal();
    }

    @Transactional
    public void internal() {
        log.info("call internal");
        printTxInfo();
    }

    private void printTxInfo() {
        boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
        log.info("tx active={}", txActive);
    }
}

CallService

external() 은 트랜잭션이 없다.
internal() 은 @Transactional 을 통해 트랜잭션을 적용한다.

@Transactional 이 하나라도 있으면 트랜잭션 프록시 객체가 만들어진다. 그리고 callService 빈을 주입 받으면 트랜잭션 프록시 객체가 대신 주입된다.

callService.internal(); (문제 없음)

callService.external(); (이게 문제임)

external() 은 @Transactional 애노테이션이 없다. 따라서 트랜잭션 없이 시작한다.

그런데 내부에서 @Transactional 이 있는 internal() 을 호출하는 것을 확인할 수 있다.

external() 메서든 @Transactional이 없기에 트랜잭션 프록시는 트랜잭션을 적용하지 않고,

실제 callService 객체의 인스턴스의 external()을 호출한다.

그리고 external() 은 내부에서 internal() 메서드를 호출한다. <- 여기서 문제가 발생한다.

문제 원인

자바 언어에서 메서드 앞에 별도의 참조가 없으면 this 라는 뜻으로 자기 자신의 인스턴스를 가리킨다.

결과적으로 자기 자신의 내부 메서드를 호출하는 this.internal() 이 되는데,

여기서 this 는 자기 자신을 가리키므로, 실제 대상 객체( target )의 인스턴스를 뜻한다.

결과적으로 이러한 내부 호출은 프록시를 거치지 않는다.

따라서 트랜잭션을 적용할 수 없다. 결과적으로 target 에 있는 internal() 을 직접 호출하게 된 것이다.

프록시 방식의 AOP 한계

@Transactional 를 사용하는 트랜잭션 AOP는 프록시를 사용한다.

프록시를 사용하면 메서드 내부 호출에 프록시를 적용할 수 없다.

해결 방법 - 단순한 방법 : 별도의 클래스로 분리

어떻게 해결할 수 있을까?

가장 단순한 방법은 내부 호출을 피하기 위해 internal() 메서드를 별도의 클래스로 분리하는 것이다.

여러가지 다른 방법이 있지만, 실무에선 주로 별도의 클래스로 분리하는 방법을 사용한다.

(중요) 트랜잭션 AOP 주의 사항 - public 메서드만 트랜잭션 적용

스프링의 트랜잭션 AOP 기능은 public 메서드에만 트랜잭션을 적용하도록 기본 설정이 되어있다.

스프링에서 그렇게 정했다.

이유는 알고 가자 (만약 public 외에 다른 데에도 가능하다면?)

@Transactional
public class Hello { 
  public method1(); 
  method2(): 
  protected method3(); 
  private method4();
}

이렇게 클래스 레벨에 트랜잭션을 적용하면 모든 메서드에 트랜잭션이 걸릴 수 있다.

그러면 트랜잭션을 의도하지 않는 곳 까지 트랜잭션이 과도하게 적용된다.

트랜잭션은 주로 비즈니스 로직의 시작점에 걸기 때문에 대부분 외부에 열어준 곳을 시작점으로 사용한다.

이런 이유로 public 메서드에만 트랜잭션을 적용하도록 설정되어 있다.

참고로 public 이 아닌곳에 @Transactional 이 붙어 있으면 예외가 발생하지는 않고, 트랜잭션 적용만 무시된다.

(중요) 트랜잭션 AOP 주의 사항 - 초기화 시점

스프링 초기화 시점에는 트랜잭션 AOP가 적용되지 않을 수 있다.

초기화 코드(예: @PostConstruct )와 @Transactional 을 함께 사용하면 트랜잭션이 적용되지 않는다.

@PostConstruct
@Transactional
public void initV1() {
    log.info("Hello init @PostConstruct"); 
}

왜냐하면 초기화 코드가 먼저 호출되고, 그 다음에 트랜잭션 AOP가 적용되기 때문이다.

따라서 초기화 시점에는 해당 메서드에서 트랜잭션을 획득할 수 없다.

해결 방법 - ApplicatonReadyEvent 를 사용

가장 확실한 대안은 ApplicationReadyEvent 이벤트를 사용하는 것이다.

@EventListener(value = ApplicationReadyEvent.class) 
@Transactional
public void init2() {
    log.info("Hello init ApplicationReadyEvent"); 
}

이 이벤트는 트랜잭션 AOP를 포함한 스프링이 컨테이너가 완전히 생성되고 난 다음에 이벤트가 붙은 메서드를 호출해준다. 따라서 init2() 는 트랜잭션이 적용된 것을 확인할 수 있다.

트랜잭션 옵션 소개

스프링 트랜잭션은 다양한 옵션을 제공한다.

public @interface Transactional {
    
    @AliasFor("transactionManager")
    String value() default "";
    @AliasFor("value")
    String transactionManager() default "";
    
    String[] label() default {};
    Propagation propagation() default Propagation.REQUIRED;
    Isolation isolation() default Isolation.DEFAULT;
    int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;
    String timeoutString() default "";
    boolean readOnly() default false;
    
    Class<? extends Throwable>[] rollbackFor() default {};   
    String[] rollbackForClassName() default {};   
    
    Class<? extends Throwable>[] noRollbackFor() default {}; 
    String[] noRollbackForClassName() default {};

}

value, transactionManager - 기본으로 등록된 걸 사용해서 보통 생략

트랜잭션을 사용하려면 먼저 스프링 빈에 등록된 어떤 트랜잭션 매니저를 사용할지 알아야 한다.

생각해보면 코드로 직접 트랜잭션을 사용할 때 분명 트랜잭션 매니저를 주입 받아서 사용했다.

@Transactional 에서도 트랜잭션 프록시가 사용할 트랜잭션 매니저를 지정해주어야 한다.

사용할 트랜잭션 매니저를 지정할 때는 value , transactionManager 둘 중 하나에

트랜잭션 매니저의 스프링 빈의 이름을 적어주면 된다.

이 값을 생략하면 기본으로 등록된 트랜잭션 매니저를 사용하기 때문에 대부분 생략한다.

그런데 사용하는 트랜잭션 매니저가 둘 이상이라면 다음과 같이 트랜잭션 매니저의 이름을 지정해서 구분하면 된다.

public class TxService {

    @Transactional("memberTxManager") 
public void member() {...}

    @Transactional("orderTxManager") 
public void order() {...}
}

rollbackFor

예외 발생시 스프링 트랜잭션의 기본 정책은 다음과 같다.

언체크 예외인 RuntimeException , Error 와 그 하위 예외가 발생하면 롤백한다.
체크 예외인 Exception 과 그 하위 예외들은 커밋한다.

이 옵션을 사용하면 기본 정책에 추가로 어떤 예외가 발생할 때 롤백할 지 지정할 수 있다.

@Transactional(rollbackFor = Exception.class)

이렇게 지정하면 체크 예외인 Exception 이 발생해도 롤백하게 된다. (하위 예외들도 대상에 포함된다.)

rollbackForClassName 도 있는데, rollbackFor 는 예외 클래스를 직접 지정하고,
rollbackForClassName 는 예외 이름을 문자로 넣으면 된다.

noRollbackFor

rollbackFor 와 반대이다.

propagation

트랜잭션 전파에 대한 옵션이다.

isolation

트랜잭션 격리 수준을 지정할 수 있다.

기본 값은 데이터베이스에서 설정한 트랜잭션 격리 수준을 사용하는 DEFAULT이다.

대부분 데이터베이스에서 설정한 기준을 따른다. 애플리케이션 개발자가 트랜잭션 격리 수준을 직접 지정하는 경우는 드물다.

DEFAULT : 데이터베이스에서 설정한 격리 수준을 따른다.
READ_UNCOMMITTED : 커밋되지 않은 읽기
READ_COMMITTED : 커밋된 읽기
REPEATABLE_READ : 반복 가능한 읽기
SERIALIZABLE : 직렬화 가능

timeout

트랜잭션 수행 시간에 대한 타임아웃을 초 단위로 지정한다. 기본 값은 트랜잭션 시스템의 타임아웃을 사용한다.

운영 환경에 따라 동작하는 경우도 있고 그렇지 않은 경우도 있기 때문에 꼭 확인하고 사용해야 한다.
timeoutString 도 있는데, 숫자 대신 문자 값으로 지정할 수 있다.

label

트랜잭션 애노테이션에 있는 값을 직접 읽어서 어떤 동작을 하고 싶을 때 사용할 수 있다. 일반적으로 사용하지 않는다.

readOnly

트랜잭션은 기본적으로 읽기 쓰기가 모두 가능한 트랜잭션이 생성된다.

readOnly=true 옵션을 사용하면 읽기 전용 트랜잭션이 생성된다. 이 경우 등록, 수정, 삭제가 안되고 읽기 기능만 작동한다. (드라이버나 데이터베이스에 따라 정상 동작하지 않는 경우도 있다.)

그리고 readOnly 옵션을 사용하면 읽기에서 다양한 성능 최적화가 발생할 수 있다.

프레임워크

JdbcTemplate은 읽기 전용 트랜잭션 안에서 변경 기능을 실행하면 예외를 던진다.
JPA(하이버네이트)는 읽기 전용 트랜잭션의 경우 커밋 시점에 플러시를 호출하지 않는다. 읽기 전용이니 변경에 사용되는 플러시를 호출할 필요가 없다. 추가로 변경이 필요 없으니 변경 감지를 위한 스냅샷 객체도 생성하지 않는다. 이렇게 JPA에서는 다양한 최적화가 발생한다.

데이터베이스

데이터베이스에 따라 읽기 전용 트랜잭션의 경우 읽기만 하면 되므로, 내부에서 성능 최적화가 발생한다

예외와 트랜잭션 커밋, 롤백 - 기본

예외가 발생했는데, 내부에서 예외를 처리하지 못하고, 트랜잭션 범위( @Transactional가 적용된 AOP ) 밖으로

예외를 던지면 어떻게 될까?

예외 발생시 스프링 트랜잭션 AOP는 예외의 종류에 따라 트랜잭션을 커밋하거나 롤백한다.

언체크 예외인 RuntimeException , Error 와 그 하위 예외가 발생하면 트랜잭션을 롤백한다.
체크 예외인 Exception 과 그 하위 예외가 발생하면 트랜잭션을 커밋한다.
물론 정상 응답(리턴)하면 트랜잭션을 커밋한다.

로그 확인 - 트랜잭션이 커밋, 롤백 되었는지 확인

logging.level.org.springframework.transaction.interceptor=TRACE
logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManager=DEBUG

#JPA 
loglogging.level.org.springframework.orm.jpa.JpaTransactionManager=DEBUG 
logging.level.org.hibernate.resource.transaction=DEBUG

JPA를 사용하므로 트랜잭션 매니저로 JpaTransactionManager 가 실행되고, 여기의 로그를 출력하게 된다.

예외와 트랜잭션 커밋, 롤백 - 활용

스프링은 왜 체크 예외는 커밋하고, 언체크(런타임) 예외는 롤백할까?

스프링 기본적으로 체크 예외는 비즈니스 의미가 있을 때 사용하고,

런타임(언체크) 예외는 복구 불가능한 예외로 가정한다.

체크 예외: 비즈니스 의미가 있을 때 사용 <- 필수는 아님 (rollbackFor 옵션으로 체크예외도 롤백가능)
언체크 예외: 복구 불가능한 예외

런타임 예외는 항상 롤백된다.

체크 예외의 경우 rollbackFor 옵션을 사용해서 비즈니스 상황에 따라서 커밋과 롤백을 선택하면 된다.

로그 - JPA 실행하는 SQL 확인

logging.level.org.hibernate.SQL=DEBUG

참고자료 및 출처

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-2/dashboard

[강의메모] 스프링 DB 2편 -데이터 접근 활용 기술 - ch3. 테스트 (feat. 임베디드 모드 쓰고 싶다면? build.gradle에 우선 h2 설정부터!!)

k9want — Sat, 27 Apr 2024 01:34:37 +0900

@SpringBootTest

@SpringBootTest는 @SpringBootApplicatoin를 찾아서 설정으로 사용한다.

테스트 - 데이터베이스 분리

컬에서 사용하는 애플리케이션 서버와 테스트에서 같은 데이터베이스를 사용하고 있으니 테스트에서 문제가 발생한다.

이런 문제를 해결하려면 테스트를 다른 환경과 철저하게 분리해야 한다.

가장 간단한 방법은 테스트 전용 데이터베이스를 별도로 운영하는 것이다.

테스트에서 매우 중요한 원칙은 다음과 같다.

테스트는 다른 테스트와 격리해야 한다.
테스트는 반복해서 실행할 수 있어야 한다.

DELETE SQL을 사용하면 되는 거 아냐?

테스트가 끝날 때 마다 추가한 데이터에 DELETE SQL 을 사용해도 되겠지만, 이 방법도 궁극적인 해결책은 아니다.

만약 테스트 과정에서 데이터를 이미 추가했는데, 테스트가 실행되는 도중에 예외가 발생하거나 애플리케이션이 종료되어 버려서 테스트 종료 시점에 DELETE SQL 을 호출하지 못할 수 도 있다!

그러면 결국 데이터가 남아있게 된다.

우리에겐 데이터 롤백이 가능한 트랜잭션이 있다.

테스트 - 데이터 롤백

트랜잭션과 롤백 전략

테스트가 끝나고 나서 트랜잭션을 강제로 롤백해버리면 데이터가 깔끔하게 제거된다.

테스트를 하면서 데이터를 이미 저장했는데, 중간에 테스트가 실패해서 롤백을 호출하지 못해도 괜찮다.

트랜잭션을 커밋하지 않았기 때문에 데이터베이스에 해당 데이터가 반영되지 않는다.

이렇게 트랜잭션을 활용하면 테스트가 끝나고 나서 데이터를 깔끔하게 원래 상태로 되돌릴 수 있다.

테스트에 직접 트랜잭션 추가

@SpringBootTest
class ItemRepositoryTest {
    @Autowired
    ItemRepository itemRepository;
    
    //트랜잭션 관련 코드
    @Autowired
    PlatformTransactionManager transactionManager;
    TransactionStatus status;

    @BeforeEach
    void beforeEach() {
    //트랜잭션 시작
        status = transactionManager.getTransaction(new
            DefaultTransactionDefinition());
    }

    @AfterEach
    void afterEach() {
    //MemoryItemRepository 의 경우 제한적으로 사용
        if (itemRepository instanceof MemoryItemRepository) {
            ((MemoryItemRepository) itemRepository).clearStore();
        }
        //트랜잭션 롤백
        transactionManager.rollback(status);
    }
//...
}

트랜잭션 관리자는 PlatformTransactionManager 를 주입 받아서 사용하면 된다.

참고로 스프링 부트는 자동으로 적절한 트랜잭션 매니저를 스프링 빈으로 등록해준다.

테스트 - @Transactional (이것만 쓰면 됨)

스프링은 테스트 데이터 초기화를 위해 트랜잭션을 적용하고 롤백하는 방식을 @Transactional 애노테이션 하나로 깔끔하게 해결해준다.

@Transactional
@SpringBootTest
class ItemRepositoryTest {}

@Transactional 원리

스프링이 제공하는 @Transactional 애노테이션은 로직이 성공적으로 수행되면 커밋하도록 동작한다.

그런데 @Transactional 애노테이션을 테스트에서 사용하면 아주 특별하게 동작한다.

@Transactional이 테스트에 있으면 스프링은 테스트를 트랜잭션 안에서 실행하고, 테스트가 끝나면 트랜잭션을
자동으로 롤백시켜 버린다!

@Transactional이 적용된 테스트 동작 방식

트랜잭션을 테스트에서 시작하기 때문에 서비스, 리포지토리에 있는 @Transactional 도 테스트에서 시작한 트랜잭션에 참여한다. (트랜잭션 전파)

강제로 커밋하기 @Commit

@Transactional 을 테스트에서 사용하면 테스트가 끝나면 바로 롤백되기 때문에 테스트 과정에서 저장한 모든 데이터가 사라진다.

당연히 이렇게 되어야 하지만, 정말 가끔은 데이터베이스에 데이터가 잘 보관되었는지 최종 결과를 눈으로 확인하고 싶을 때도 있다.

이럴 때는 다음과 같이 @Commit 을 클래스 또는 메서드에 붙이면 테스트 종료후 롤백
대신 커밋이 호출된다. 참고로 @Rollback(value = false) 를 사용해도 된다.

예시

@Commit
@Transactional 
@SpringBootTest
class ItemRepositoryTest {}

정리

테스트가 끝난 후 개발자가 직접 데이터를 삭제하지 않아도 되는 편리함을 제공한다.
테스트 실행 중에 데이터를 등록하고 중간에 테스트가 강제로 종료되어도 걱정이 없다. 이 경우 트랜잭션을 커밋
하지 않기 때문에, 데이터는 자동으로 롤백된다. (보통 데이터베이스 커넥션이 끊어지면 자동으로 롤백되어 버린
다.)
트랜잭션 범위 안에서 테스트를 진행하기 때문에 동시에 다른 테스트가 진행되어도 서로 영향을 주지 않는 장점이
있다.
@Transactional 덕분에 아주 편리하게 다음 원칙을 지킬수 있게 되었다.
- 테스트는 다른 테스트와 격리해야 한다.
- 테스트는 반복해서 실행할 수 있어야 한다.

테스트 - 임베디드 모드 DB (build.gradle - h2 설정부터!!)

build.gradle에 일단 h2를 사용한다고부터 명시

testRuntimeOnly 'com.h2database:h2:2.1.214'

임베디드 모드

H2 데이터베이스는 자바로 개발되어 있고, JVM안에서 메모리 모드로 동작하는 특별한 기능을 제공한다.

그래서 애플리케이션을 실행할 때 H2 데이터베이스도 해당 JVM 메모리에 포함해서 함께 실행할 수 있다.

DB를 애플리케이션에 내장해서 함께 실행한다고 해서 임베디드 모드(Embedded mode)라 한다.

종료 시 함께 종료되고, 데이터도 모두 사라진다. (자바 메모리를 함께 사용하는 라이브러리처럼 동작)

조심해야할 부분, 애플리케이션과 함게 실행하기에 아무 테이블도 없는 상태이다.

스프링 부트 - 기본 SQL 스크립트를 사용해서 데이터베이스를 초기화하는 기능 (feat. src/test/resources/schema.sql)

메모리 DB는 애플리케이션이 종료될 때 함께 사라지기 때문에,

애플리케이션 실행 시점에 데이터베이스 테이블도 새로 만들어주어야 한다.

스프링 부트는 SQL 스크립트를 실행해서 애플리케이션 로딩 시점에 데이터베이스를 초기화하는 기능을 제공한다.

src/test/resources/schema.sql

이름은 schema.sql 로 해야하고, 파일은 src/test/resources 하위에 생성한다.

예시

src/test/resources/schema.sql

drop table if exists item CASCADE; 
create table item
(
    id        bigint generated by default as identity, 
    item_name varchar(10),
    price integer, 
    quantity integer,
primary key (id) 
);

로그 확인

기본 SQL 스크립트가 잘 실행되는지 로그로 확인하려면 다음이 추가되어 있는지 확인하자.

src/test/resources/application.properteis

#schema.sql
logging.level.org.springframework.jdbc=debug

..init.ScriptUtils     : 0 returned as update count for SQL: create table item 
( id bigint generated by default as identity, item_name varchar(10), price 
integer, quantity integer, primary key (id) )

테스트 - 스프링 부트와 임베디드 모드

스프링 부트는 개발자에게 정말 많은 편리함을 제공하는데, 임베디드 데이터베이스에 대한 설정도 기본으로 제공한다.

test - application.properties에 별다른 정보가 없으면 스프링 부트는 임베디드 모드로 접근하는 데이터소스( DataSource )를 만들어서 제공한다.

conn0: url=jdbc:h2:mem:d8fb3a29-caf7-4b37-9b6c-b0eed9985454

로그를 보면 jdbc:h2:mem 뒤에 임의의 데이터베이스 이름이 들어가 있다. 이것은 혹시라도 여러 데이터소스가 사용될 때 같은 데이터베이스를 사용하면서 발생하는 충돌을 방지하기 위해 스프링 부트가 임의의 이름을 부여한 것이다.

임베디드 데이터베이스 이름을 스프링 부트가 기본으로 제공하는 jdbc:h2:mem:testdb 로 고정하고 싶으면

spring.datasource.generate-unique-name=false 추가

결론

@Transactional을 사용하면 데스트의 중요한 원칙 2가지를 지킬 수 있다.

- 테스트는 다른 테스트와 격리해야한다.

- 테스트는 반복해서 실행할 수 있어야 한다.

스프링부트는 test - application.properties에 아무 설정이 없다면? 임베디드 DB를 자동으로 실행시켜준다.

참고자료 및 출처

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-2/dashboard

[강의메모] 스프링 DB 2편 -데이터 접근 활용 기술 - ch2. 스프링 JdbcTemplate

k9want — Sat, 27 Apr 2024 00:51:36 +0900

인프런 김영한님 스프링 DB 2편 - 데이터 접근 활용 기술

강의 중 2장을 보고 핵심 내용을 정리했습니다.

JdbcTemplate 소개 및 장단점

SQL을 직접 사용하는 경우에 스프링이 제공하는 JdbcTemplate은 아주 좋은 선택지다. JdbcTemplate은 JDBC를 매우 편리하게 사용할 수 있게 도와준다.

장점

설정의 편리함

JdbcTemplate은 spring-jdbc 라이브러리에 포함되어 있는데, 이 라이브러리는 스프링으로 JDBC를 사용할 때 기본으로 사용되는 라이브러리이다. 그리고 별도의 복잡한 설정 없이 바로 사용할 수 있다.

반복 문제 해결

JdbcTemplate은 템플릿 콜백 패턴을 사용해서, JDBC를 직접 사용할 때 발생하는 대부분의 반복 작업을 대신 처리해준다.

개발자는 SQL을 작성하고, 전달할 파리미터를 정의하고, 응답 값을 매핑하기만 하면 된다.

대부분의 반복 작업을 대신 처리해준다.

커넥션 획득
statement 를 준비하고 실행
결과를 반복하도록 루프를 실행
커넥션 종료, statement , resultset 종료 트랜잭션 다루기 위한 커넥션 동기화
예외 발생시 스프링 예외 변환기 실행

단점

동적 SQL을 해결하기 어렵다.
ORM과 비교 시 SQL Mapper 특성상 개발자가 직접 SQL을 작성해야한다.

JdbcTemplate 기능 정리

주요 기능

JdbcTemplate이 제공하는 주요 기능은 다음과 같다.

JdbcTemplate : 순서 기반 파라미터 바인딩을 지원한다.
NamedParameterJdbcTemplate : 이름 기반 파라미터 바인딩을 지원한다. (권장)
SimpleJdbcInsert : INSERT SQL을 편리하게 사용할 수 있다.
SimpleJdbcCall : 스토어드 프로시저를 편리하게 호출할 수 있다.

JdbcTemplate 사용법 정리

스프링 JdbcTemplate 사용 방법 공식 메뉴얼

https://docs.spring.io/spring-framework/reference/data-access/jdbc/core.html#jdbc-JdbcTemplate

Using the JDBC Core Classes to Control Basic JDBC Processing and Error Handling :: Spring Framework

Some query methods return a single value. To retrieve a count or a specific value from one row, use queryForObject(..). The latter converts the returned JDBC Type to the Java class that is passed in as an argument. If the type conversion is invalid, an Inv

docs.spring.io

조회

단건 조회 - 숫자 조회

int rowCount = jdbcTemplate.queryForObject("select count(*) from t_actor", 
Integer.class);

하나의 로우를 조회할 때는 queryForObject() 를 사용하면 된다.

조회 대상이 객체가 아니라 단순 데이터 하나라면 타입을 Integer.class , String.class 와 같이 지정해주면 된다.

단건 조회 - 숫자 조회, 파라미터 바인딩

int countOfActorsNamedJoe = jdbcTemplate.queryForObject(
"select count(*) from t_actor where first_name = ?", Integer.class, "Joe");

숫자 하나와 파라미터 바인딩 예시이다.

단건 조회 - 문자 조회

String lastName = jdbcTemplate.queryForObject(
	"select last_name from t_actor where id = ?", 
	String.class, 1212L);

문자 하나와 파라미터 바인딩 예시이다.

단건 조회 - 객체 조회(1)

Actor actor = jdbcTemplate.queryForObject(
        "select first_name, last_name from t_actor where id = ?",
        (resultSet, rowNum) -> {
            Actor newActor = new Actor();
            newActor.setFirstName(resultSet.getString("first_name")); 
            newActor.setLastName(resultSet.getString("last_name"));
            return newActor;
        },
        1212L);

객체 하나를 조회한다. 결과를 객체로 매핑해야 하므로 RowMapper 를 사용해야 한다. 여기서는 람다를 사용했다.

목록 조회 - 객체(2)

List<Actor> actors = jdbcTemplate.query(
        "select first_name, last_name from t_actor",
        (resultSet, rowNum) -> {
            Actor actor = new Actor();
            actor.setFirstName(resultSet.getString("first_name")); 
            actor.setLastName(resultSet.getString("last_name"));
            return actor;
        });

여러 로우를 조회할 때는 query() 를 사용하면 된다. 결과를 리스트로 반환한다.

결과를 객체로 매핑해야 하므로 RowMapper 를 사용해야 한다. 여기서는 람다를 사용했다.

목록 조회 - 객체(3)

private final RowMapper<Actor> actorRowMapper = (resultSet, rowNum) -> { 
    Actor actor = new Actor();
    actor.setFirstName(resultSet.getString("first_name")); 
    actor.setLastName(resultSet.getString("last_name"));
    return actor; 
};
public List<Actor> findAllActors() {
    return this.jdbcTemplate.query("select first_name, last_name from t_actor", actorRowMapper);
}

여러 로우를 조회할 때는 query() 를 사용하면 된다. 결과를 리스트로 반환한다.

여기서는 RowMapper 를 분리했다. 이렇게 하면 여러 곳에서 재사용 할 수 있다.

변경(INSERT, UPDATE, DELETE)

데이터를 변경할 때는 jdbcTemplate.update() 를 사용하면 된다. 참고로 int 반환값을 반환하는데, SQL 실행 결과에 영향받은 로우 수를 반환한다.

등록

jdbcTemplate.update(
	"insert into t_actor (first_name, last_name) values (?, ?)", 
	"Leonor", "Watling");

수정

jdbcTemplate.update(
	"update t_actor set last_name = ? where id = ?", 
	"Banjo", 5276L);

삭제

jdbcTemplate.update(
	"delete from t_actor where id = ?", 
	Long.valueOf(actorId));

기타 기능

임의의 SQL을 실행할 때는 execute() 를 사용하면 된다. 테이블을 생성하는 DDL에 사용할 수 있다.

DDL

jdbcTemplate.execute("create table mytable (id integer, name varchar(100))");

스토어드 프로시저 호출

jdbcTemplate.update(
	"call SUPPORT.REFRESH_ACTORS_SUMMARY(?)", 
	Long.valueOf(unionId));

정리

실무에서 가장 간단하고 실용적인 방법으로 SQL을 사용하려면 JdbcTemplate을 사용하면 된다.

JPA와 같은 ORM 기술을 사용하면서 동시에 SQL을 직접 작성해야 할 때가 있는데, 그때도 JdbcTemplate을 함께 사용하면 된다.

그런데 JdbcTemplate의 최대 단점이 있는데, 바로 동적 쿼리 문제를 해결하지 못한다는 점이다.

그리고 SQL을 자바 코드로 작성하기 때문에 SQL 라인이 코드를 넘어갈 때 마다 문자 더하기를 해주어야 하는 단점도 있다.

동적 쿼리 문제를 해결하면서 동시에 SQL도 편리하게 작성할 수 있게 도와주는 기술이 바로 MyBatis 이다.

참고자료 및 출처

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-2/dashboard

스프링 DB 2편 - 데이터 접근 활용 기술 | 김영한 - 인프런

김영한 | 백엔드 개발에 필요한 DB 데이터 접근 기술을 활용하고, 완성할 수 있습니다. 스프링 DB 접근 기술의 원리와 구조를 이해하고, 더 깊이있는 백엔드 개발자로 성장할 수 있습니다., 백엔드

www.inflearn.com

[강의메모] 스프링 DB 2편 -데이터 접근 활용 기술 - ch1. 시작 (feat.@EventListener(ApplicationReadyEvent.class),Import, Profile)

k9want — Sat, 27 Apr 2024 00:34:14 +0900

인프런 김영한님 스프링 DB 2편 - 데이터 접근 활용 기술

강의 중 1장을 보고 핵심 내용을 정리했습니다.

@EventListener(ApplicationReadyEvent.class)

@Slf4j
@RequiredArgsConstructor 
public class TestDataInit {
  private final ItemRepository itemRepository; 
    /**
     * 확인용 초기 데이터 추가 
     */
    @EventListener(ApplicationReadyEvent.class) 
  public void initData() {
        log.info("test data init");
        itemRepository.save(new Item("itemA", 10000, 10)); 
        itemRepository.save(new Item("itemB", 20000, 20)); 
    }
}

스프링 컨테이너가 완전히 초기화를 다 끝내고, 실행 준비가 되었을 때 발생하는 이벤트이다.

스프링이 이 시점에 해당 애노테이션이 붙은 메서드(위에선 initData)를 호출해준다.

@PostContstruct와의 차이

참고로 이 기능 대신 @PostConstruct 를 사용할 경우 AOP 같은 부분이 아직 다 처리되지 않은 시점에 호출될 수 있기 때문에, 간혹 문제가 발생할 수 있다.

예를 들어서 @Transactional 과 관련된 AOP가 적 용되지 않은 상태로 호출될 수 있다.

@EventListener(ApplicationReadyEvent.class) 는 AOP를 포함한 스프링 컨테이너가 완전
히 초기화 된 이후에 호출되기 때문에 이런 문제가 발생하지 않는다.

@Import

@Import(MemoryConfig.class)
@SpringBootApplication(scanBasePackages = "hello.itemservice.web")
public class ItemServiceApplication {

    public static void main(String[] args) {
        SpringApplication.run(ItemServiceApplication.class, args);
    }

    @Bean
    @Profile("local")
    public TestDataInit testDataInit(ItemRepository itemRepository) {
        return new TestDataInit(itemRepository);
    }
}

@Import(MemoryConfig.class) : 앞서 설정한 MemoryConfig 를 설정 파일로 사용한다.
scanBasePackages = "hello.itemservice.web" : 여기서는 컨트롤러만 컴포넌트 스캔을 사용하고, 나머지는 직접 수동 등록한다. 그래서 컴포넌트 스캔 경로를 hello.itemservice.web 하위로 지정했다.
@Profile("local") : 특정 프로필의 경우에만 해당 스프링 빈을 등록한다.
여기서는 local 이라는 이름의 프로필이 사용되는 경우에만 testDataInit 이라는 스프링 빈을 등록한다. 이 빈은 앞서 본 것인데, 편의상 초기 데이터를 만들어서 저장하는 빈이다.

프로필

스프링은 로딩 시점에 application.properties 의 spring.profiles.active 속성을 읽어서 프로필로 사용한다.

이 프로필은 로컬(나의 PC), 운영 환경, 테스트 실행 등등 다양한 환경에 따라서 다른 설정을 할 때 사용하는 정보이다.

예를 들어서 로컬PC에서는 로컬 PC에 설치된 데이터베이스에 접근해야 하고, 운영 환경에서는 운영 데이터베이스에 접근해야 한다면 서로 설정 정보가 달라야 한다. 심지어 환경에 따라서 다른 스프링 빈을 등록해야 할 수 도 있다. 프로필을 사용하면 이런 문제를 깔끔하게 해결할 수 있다.

main 프로필

/src/main/resources 하위의 application.properties

spring.profiles.active=local

이 위치의 application.properties 는 /src/main 하위의 자바 객체를 실행할 때 (주로 main() ) 동작하는 스프링 설정이다.

spring.profiles.active=local 이라고 하면 스프링은 local 이라는 프로필로 동작한다.

참고로 프로필을 지정하지 않으면 디폴트( default ) 프로필이 실행된다.

test 프로필

/src/test/resources 하위의 application.properties

spring.profiles.active=test

이 위치의 application.properties 는 /src/test 하위의 자바 객체를 실행할 때 동작하는 스프링 설정이다.
주로 테스트 케이스를 실행할 때 동작한다.

spring.profiles.active=test 로 설정하면 스프링은 test 라는 프로필로 동작한다.

참고자료 및 출처

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-2/dashboard