[인프런 워밍업 스터디 클럽] 0기 두번째 발자국 (2 week)

[인프런 워밍업 스터디 클럽] 0기 두번째 발자국 (2 week)

양성빈 8개월 전

발자국

어느덧 인프런 워밍업 스터디 클럽을 시작한지도 2주째가 시작된다. 그리고 이번주 1주에 대한 회고를 시작해보려고 한다.

이번주도 여러가지를 배우고 많은 경험이 된 한 주였다. 그럼 회고를 시작하겠다. 완주 및 우수러너를 위해 오늘도 달려본다.

강의 요약

Day 6. 스프링 컨테이너의 의미와 사용방법

📖 UserController와 스프링 컨테이너

상식적으로 static이 아닌 코드를 사용하려면 객체화(인스턴스화)가 필수적이다. 하지만 이전 학습의 UserController부분을 확인해보면 의아한 부분이 존재한다.

private final UserService userService;

public UserController(JdbcTemplate jdbcTemplate) {
   this.userService = new UserService(jdbcTemplate);
}

이렇게 UserService는 UserController 생성자 부분에서 인스턴스화를 하였지만, 정작 UserController부분은 인스턴스화를 해주지 않았지만 잘 작동하는 것을 알 수 있었다. 이로 인해 아래의 의문점이 남아진다.

🙋🏻 그럼 누가 UserController부분을 인스턴스화 시켜준다는건데 누가 그런 걸 해주나요?

또한 위의 코드에서 또 하나의 의문점이 남는다.

🙋🏻 그리고 나는 JdbcTemplate 클래스를 따로 만져준 적이 없는데 UserController 클래스는 어떻게 이 클래스를 가져올 수 있을까요?

바로 @RestController라는 어노테이션때문이다. 우리는 앞전에 @RestController라는 어노테이션이 API 진입점이라고 배웠다. 하지만 이 @RestController는 진입점의 역할과 더불어 UserController 클래스를 스프링 빈으로 등록을 시켜준다.

🙋🏻 그럼 스프링 빈이 뭐에요? 빈은 영어니까 번역하면 콩인것 같은데 그럼 스프링 콩인가요?

위의 질문이 나는 자연스럽게 떠올랐다. 그럼 정확히 스프링 빈이 무엇인지 알아보자.

🫛 스프링 빈

우리가 스프링 부트로 만든 프로젝트를 동작시키면, 우리가 만든 서버가 동작을 하는 것이다. 그러면 이 서버 내부에 거대한 컨테이너를 만들어준다. 그리고 컨테이너 안에는 빈으로 등록시킨 클래스 정보(이름, 타입)가 들어간다. 그리고 이 클래스를 인스턴스화 시켜준다. 이 때, 들어간 클래스를 스프링 빈이라고 부른다.

🙋🏻 그런데 여기서 위의 코드를 보면 UserController를 인스턴스화할려면 JdbcTemplate가 필요하지 않나요?

요놈은 어디서 가져오는 거에요?

사실, JdbcTemplate 클래스도 빈으로 등록된 클래스이다.

🙋🏻 그럼, 누가 JdbcTempalte을 인스턴스화 시켜줬어요?

바로 build.gradle에 dependencies에 등록한 spring boot starter data jpa라는 것이 JdbcTemplate을 등록시켜줬다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
}

그래서 인텔리제이로 UserController 생성자 부분을 보면 책모양으로 아이콘이 있는데 이것이 빈으로 등록되었다는 의미이다.

image

즉, 결론을 내보면 우리가 가져온 Dependency가 JdbcTemplate을 빈으로 등록시켜준다는 의미이다.

그러면 여기서 또 하나 결론이 나온다. 스프링 컨테이너 안에 우리가 작성한 스프링 빈으로 등록한 클래스는 이 컨테이너 안에 들어가게 된다. 또한 필요한 의존성이 자동 설정된다.

그럼 여기서 의문점이 든다. 우리가 이전에 작성한 UserRepository 클래스와 UserService 클래스도 JdbcTemplate의 의존성이 필요하고 이 JdbcTemplate을 가져오려면 이 두개의 클래스도 빈으로 등록이 되어있어야 한다. 하지만 이 2개의 클래스는 빈으로 등록되지 않았다. 인텔리제이 화면만 봐도 책 모양 아이콘이 존재하지 않는다. 그럼 2개의 클래스를 빈으로 등록시키자!

 

🫛 Repository와 Service 빈 등록시키기 & Controller 클래스 변경

두개의 클래스를 빈으로 등록시키는 방법은 정말 간단하다. Repository 클래스는 @Repository 어노테이션을 클래스 위에 붙여주고, Service 클래스는 @Service 어노테이션을 클래스 위에 붙여주면 빈으로 등록이 된다. 그리고 Controller부분을 수정해본다. 그럼 아래와 같이 변경될 것이다. 코드는 일부만 표기하겠다.

UserController.java
@RestController
public class UserController {

    private final UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }
...

 

UserService.java
@Service
public class UserService {

    private final UserRepository userRepository;

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

 

UserRepository.java
@Repository
public class UserRepository {

    private final JdbcTemplate jdbcTemplate;

    public UserRepository(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }
...

 

📚 정리

그러면 한번 정리해보자. 스프링 서버가 시작이 되면 의존성에 의해 빈으로 등록된 JdbcTemplate이 스프링 컨테이너로 들어간다. 그리고 이 JdbcTemplate의 의존성을 가진 UserRepository가 빈으로 등록된다. 그러면 UserRepository를 의존하는 UserService가 빈으로 등록된다. 그리고 UserService를 의존하는 UserController가 빈으로 등록된다.

그런데 아래의 의문점이 든다.

🤔 아니 뭐가 좋아진거야? 그냥 new 연산자로 객체생성하면 안되는건가? 스프링 컨테이너 왜 쓰는데?

이 의문점은 다음 강의에서 해소가 되었다.

📖 스프링 컨테이너를 왜 사용할까?

만약 아래의 요구사항이 있다고 하자.

책 이름을 저장하는 API를 구현하라. 단, 이름 저장은 메모리에 저장시킨다.

우리는 그럼 열심히 비즈니스 로직을 만들 것이다. 먼저 Book 객체부터 만들고, BookController, BookService, BookMemoryRepository를 만들 것이다. 그리고 BookMemoryRepository를 BookService는 아래와 같이 객체를 생성할 것이다.

그런데 이렇게 열심히 만들고나니 추가 요구사항이 생겼다.

public class BookService {
  private final BookMemoryRepository repository = new BookMemoryRepository();
}

 

생각해보니, 메모리가 아닌 MySQL과 같은 RDB에 저장시켜야해! 그리고 JdbcTemplate은 Repository가 바로 설정할 수 있다 하자.

그러면 BookMySQLRepository를 만들고 BookService에 BookMemoryRepository가 아닌 BookMySQLRepository를 인스턴스화 해줘야 한다.

public class BookService {
  private final BookMySQLRepository repository = new BookMySQLRepository();
}

이런 과정을 하면서 우리는 불편함을 느꼈을 것이다. 우리는 repository의 기능적인 역할만 변경하였는데 서비스 코드까지 변경해야하는 경우가 생긴 것이다. 지금은 몇개 안되지만, 이 repository를 쓰는 서비스 코드가 수백개 클래스에 있다면 바로 오늘 야근을 해야하고 야근 신청서를 올려야 한다.🥲

그러면 이런 야근을 피하기 위해서 repository를 변경하더라도 서비스 클래스는 변경을 안하는 방법은 없을까? 그래서 생각을 한 것이 java의 interface를 이용하는 방법이다. BookRepository라는 인터페이스를 만들고 BookMemoryRepository와 BookMySQLRepository를 구현하면 되는 것이다. 그러면 서비스 코드는 이런 식으로 변경 될 것이다.

public class BookService {
  private final BookRepository repository = new BookMySQLRepository();
}

하지만 그래도 서비스 코드는 repository 역할 변경에 다라 수정이 되긴 해야한다. 바로 new 연산자의 부분을 전부 변경해야 하기 때문이다. 또 야근 당첨이다 🥲 그러면 이걸 또 해결할 수 있는 방법은 없을까? 바로 스프링 컨테이너가 그래서 등장하였다.

스프링 컨테이너가 BookService 대신 repository를 인스턴스화 해주고 그때 그때 알아서 어떤 repository 클래스를 쓸지 결정을 해줄 수 있다. 이런 방식을 제어의 역전(IoC, Inversion of Control)이라고 한다. 그리고 컨테이너가 repository 클래스를 선택해서 서브스 레이어에 넣어주는 과정의 의존성 주입(DI, Dependency Injection)라고 한다.

그러면 어떤 Repository를 주입시켜줄까? 그것은 우리가 @Primary 어노테이션을 활용해 조절할 수 있다.

@Primary: 우선권을 결정하는 어노테이션

📖 스프링 컨테이너를 다루는 방법

@Configuration: 클래스에 붙여주는 어노테이션, @Bean 어노테이션과 같이 사용

@Bean: 보통은 메서드 위에 붙으며, 해당 메서드에서 반환되는 객체를 스프링 빈으로 등록시켜준다.

그리고 아래의 의문사항이 든다. 그러면 우리가 이전에 @Service, @Repository 어노테이션을 붙여줬는데 이 어노테이션은 언제 사용해야할까? 위의 @Configuration + @Bean 어노테이션을 쓰면 안될까?

요약하자면 다음과 같다.

@Service나 @Repository 어노테이션은 개발자가 직접 만든 클래스를 빈으로 등록시키고 싶을 때 사용하며,

@Configuration + @Bean 어노테이션은 외부 라이브러리나 프레임워크에서 만든 클래스를 등록시킬때 사용한다.

다음으로 살펴 볼 어노테이션은 @Component 어노테이션이다.

@Component: 주어진 클래스를 컴포넌트로 간주하며, 이 클래스들은 스프링 서버가 시작할 때 자동감지한다.

@Component 어노테이션 덕분에 우리가 사용했던 어노테이션들이 감지가 된것이다.

Service.java
package org.springframework.stereotype;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import org.springframework.core.annotation.AliasFor;

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Service {
    @AliasFor(
        annotation = Component.class
    )
    String value() default "";
}
Repository.java
package org.springframework.stereotype;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import org.springframework.core.annotation.AliasFor;

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Repository {
    @AliasFor(
        annotation = Component.class
    )
    String value() default "";
}

이렇게 각 어노테이션들의 내부구조를 보면 이렇게 @Component 어노테이션이 들어가져 있다.

그럼 @Component 어노테이션은 언제 사용할까?

컨트롤러, 서비스, 리포지토리가 모두 아니고 개발자가 직접 작성한 클래스를 스프링 빈으로 등록할 때 사용한다.

🫛 빈 주입 받는 방법

빈을 주입받는 방법은 3가지가 존재한다.

  1. 생성자를 이용한 주입방법 (권장)

  2. setter와 @Autowired -> 누군가 setter를 사용하면서 오작동 가능성이 존재

private final JdbcTemplate jdbcTemplate;

@Autowired
public void setJdbcTemplate(JdbcTemplate jdbcTemplate) {
  this.jdbcTemplate = jdbcTemplate;
}

  1. 필드에 직접 @Autowired 사용 -> 테스트 어려움

@Autowired
private JdbcTemplate jdbcTemplate;

마지막으로 @Qualifier 어노테이션을 알아보자. @Primary와 유사하다.

스프링 빈을 사용하는 쪽, 스프링 빈을 등록하는 쪽 모두 @Qualifier를 사용할 수 있다!

스프링 빈을 사용하는 쪽에서만 쓰면, 빈의 이름을 적어주어야 한다. 양쪽 모두 사용하면, @Qualifier 끼리 연결된다!

@Service
@Qualifier("main")
public class BananaService implements FruitService {
}
@RestController
public class UserController {

 private final UserService userService;

 private final FruitService fruitService;

 public UserController(UserService userService, @Qualifier("main") FruitService fruitService) {
   this.userService = userService;
   this.fruitService = fruitService;
}

그러면 @Qualifier와 @Primary 어노테이션중에 누가 우선순위가 높을까?

사용하는 쪽에서 직접 적어준 @Qualifier가 이긴다!

📚섹션3 정리

클린코드가 무엇이고, 우리의 코드를 레이어 아키텍쳐로 분리도 해보며, 스프링 컨테이너가 무엇이고 스프링 빈이 무엇인지 이해를 하며 어떤 어노테이션을 통해 주입을 받고 빈으로 등록할 수 있는지 알아보았다.

 

Day7. Spring Data JPA를 사용한 데이터베이스 조작

📖 문자열 SQL을 직접 사용하는 것이 너무 어렵다!!

우리는 현재 레이어드 아키텍쳐로 코드를 작성하였고, 해당 빈들을 스프링 컨테이너가 관리를 하였고 포스트맨을 통하여 API를 호출하였다. 또한 repository 레이어로 mysql과 통신을 하였다. 그런데 repository 레이어에서는 DB 쿼리를 문자열로 작성하였다. 하지만 이렇게 문자열로 작성하면 아래와 같은 문제가 있을 수 있다.

  1. 문자열로 작성 시, 오타가 날 수 있는 실수가 있다. 하지만 이 실수는 컴파일 타임에 발견되지 않고 런타임에 발견되는 안 좋은 점이 있다. 그래서 어플리케이션 운영 시점에 해당 API를 사용 시, 에러를 확인할 수 있기에 엄청 치명적이다.

  2. 특정 DB에 종속적이다. 만약 우리가 MySQL을 쓰다가 어느 이유로 DB를 변경하게 된다면 해당 쿼리들을 변경하는 DB 쿼리 문법에 맞게 수정해줘야한다. 마이그레이션도 일이지만 해당 쿼리를 다 고쳐야한다면 야근 당첨일 것이다. 🥲

  3. 반복 작업이 많아진다. 보통 테이블당 기본적으로 CRUD 쿼리를 작성해줘야 하는데, 단순 반복작업들이 이어질 수 있다.

  4. 데이터베이스 테이블과 객체의 패러다임이 다르다. 쉽게 생각해서 연관관계 매칭을 할 때 양방향 매핑을 할 때 연관관계 갖는 테이블 A는 B를 가리키고 B또한 A클래스를 가리킬 수 있지만 실제 테이블은 한쪽만 가리키게 된다. 또한 상속개념은 자바는 존재하지만 DB는 상속개념을 구현하기 매우 힘들다.

     


    그래서 JPA라는 것이 등장하였다. JPA는 ORM의 일종인데 이 두 용어를 살펴보면 아래와 같다.

JPA(Java Persistence API) : 자바 영속성 API

그럼 영속성은 무엇일까? 우리는 이전에 메모리에 회원 정보를 저장하는 코드를 작성했지만 이런 코드는 서버를 재부팅하면 데이터는 날라간다. 그 이유는 RAM에 데이터가 저장되기 때문이다. 그런데 영속성은 서버가 재부팅되어도 데이터는 영구적으로 저장되는 속성을 의미한다.

그리고 API는 일종의 규칙이다. 그래서 이것을 풀어써보면 아래와 같다.

JPA란, 데이터를 영구적으로 보관하기 위해 자바 진영에서 정해진 규칙을 뜻한다.

그러면 ORM은 무엇일까? 자바코드와 DB의 테이블을 짝 지어준다는 의미이다.

📚 요약 (JPA란?)

객체와 관계형 DB의 테이블을 짝지어 데이터를 영구적으로 저장할 수 있도록 정해진 자바 진영의 규칙을 뜻한다.

그런데 JPA를 검색해보면 연관검색으로 Hibernate가 나온다. 이 Hibernate란 무엇일까?

JPA는 쉽게 규칙이라고 하였다. 이 규칙을 구현한 구현체가 Hibernate이다. 또한 Hibernate은 내부적으로 JDBC를 사용한다.

 

📖 유저 테이블에 대응되는 Entity Class 만들기

이제 실제로 유저 테이블과 유저 클래스를 매핑시켜보자. 이를 위해선 어노테이션 @Entity를 붙여줘야 한다.

🙋🏻 Entity란?

저장되고 관리되어야 하는 데이터를 의미한다.

image

유저 테이블은 위와 같이 구성되어 있다. 먼저, id를 primary key로 설정되어 있고 auto_increment가 적용되어 있다. 이것을 자바 코드에 적용하려면 @Id와 @GeneratedValue(strategy=GenerationType.IDENTY)를 설정해줘야 한다. 그렇게 적용한 코드는 아래와 같다.

@Entity
public class User {

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

 

DB의 종류마다 자동 생성 전략이 다르다!

우리는 MySQL의 auto_increment를 사용했고, 이는 IDENTITY 전략과 매칭된다.

 

JPA를 사용하기 위해 기본 생성자가 반드시 필요하다.

다음으로 name 부분을 짝 지어줘야 한다.

이를 위해서 @Column 어노테이션을 통해 매핑해줘야 한다.

@Column(nullable = false, length = 20, name = "name")
private String name;

여기서 nullable = false는 이 속성은 null이 불가능하다는 의미이며, length = 20은 DB로 보면 varchar(20)을 의미한다.

또한 name = "name"은 이 속성은 테이블의 name 필드와 매핑시키겠다는 의미이다.

⚠ 참고

참고로 name은 필드이름과 동일할 경우 생략이 가능하다.

그리고 이런 nullable, length등 이런 속성을 기본으로 쓸 때 @Column 어노테이션 자체를 생략이 가능하다.

이제 application.yml로 JPA 설정을 해줘야 한다.

  jpa:
    hibernate:
      ddl-auto: none
    properties:
      hibernate:
        show_sql: true
        format_sql: true
        dialect: org.hibernate.dialect.MySQLDialect

  • ddl-auto: 스프링이 시작할 때 DB에 있는 테이블을 어떻게 처리할지

    • create : 기존 테이블이 있다면 삭제 후 다시 생성

    • create-drop : 스프링이 종료될 때 테이블을 모두 제거

    • update : 객체와 테이블이 다른 부분만 변경

    • validate : 객체와 테이블이 동일한지 확인

    • none : 별다른 조치를 하지 않는다.

  • show_sql: JPA를 사용해 DB에 SQL을 날릴 때 SQL을 보여줄 것인가

  • format_sql: SQL을 보여줄 때 예쁘게 포맷팅 할 것인가, 여기서 예쁘게는 뭔가를 꾸미는게 아니라 우리가 쉽게 볼 수 있게 포맷팅을 해준다는 것이다.

  • dialect: 방언(사투리), 이 옵션으로 DB를 특정하면 조금씩 다른 SQL을 수정해준다.

⚠ 주의

강좌에서는 방언 설정을 할 때 org.hibernate.dialect.MySQLDialect를 org.hibernate.dialect.MySQL8Dialect로 하셨다. 하지만 최근에 org.hibernate.dialect.MySQL8Dialect가 deprecated가 되었다는 warning이 발생한다. 그리고 org.hibernate.dialect.MySQLDialect로 변경하라고 써져있다.

📖 Spring Data JPA를 이용해 자동으로 쿼리 날리기

우리는 이제 직접 sql을 작성해주지 않고 JPA를 이용하여 유저의 생성/조회/업데이트 기능을 리팩토링할 것이다.

먼저 아래와 같이 Repository 인터페이스를 만들어준다.

public interface UserRepository extends JpaRepository<User, Long> {
}

그리고 서비스 코드에서 해당 UserRepository로 의존성 주입을 한다.

다음으로 생성 부분 메서드를 만들어보자.

public void saveUser(UserCreateRequest request) {
   this.userRepository.save(new User(request.getName(), request.getAge()));
}

여기서 save 메서드는 JpaRepository를 상속받은 Repository에 정의되어 있지 않지만 사용이 가능하다. 그 이유는 Spring Data JPA에서 기본으로 제공해주는 저장 로직이 담긴 로직이다. 해당 메서드를 실행하면 insert 쿼리가 날라간다.

다음으로 조회 부분 메서드를 보자.

public List<UserResponse> getUsers() {
  return this.userRepository.findAll()
          .stream().map(UserResponse::new)
          .collect(Collectors.toList());
}

여기서 findAll 메서드도 기본으로 제공한다. 이 메서드의 반환은 List형태이다. 이 메서드를 실행하면 select * ~ 쿼리가 날라간다.

다음으로 업데이트 기능으로 보자. 업데이트는 유저가 존재하는지 확인하고 있다면 update쿼리를 아니면 예외를 날린다.

public void updateUser(UserUpdateRequest request) {
  User user = this.userRepository.findById(request.getId()).orElseThrow(IllegalArgumentException::new);
  user.updateName(request.getName());

  this.userRepository.save(user);
}

먼저 findById라는 메서드를 호출한다. 이 메서드는 기본으로 제공해주는 메서드로 해당 메서드는 select * from user where id = ?의 쿼리를 날려준다. 이 메서드의 반환타입은 1개의 데이터를 가져오기 때문에 객체 단일 타입으로 반환된다. 여기선 User가 반환된다. 그리고 updateName이라는 메서드를 엔티티에 만들어준다. 이 메서드는 단순 setter의 역할이다. 마지막으로 setter로 속성 변경을 한 후 save로 저장을 시킨다.

그럼 여기서 이렇게 메서드를 통해 쿼리 작성없이 쿼리가 날라갈 수 있는 이유는 JPA가 아닌 Spring Data JPA 때문이다.

Spring Data JPA: 복잡한 JPA 코드를 스프링과 함께 쉽게 사용할 수 있도록 도와주는 라이브러리

즉, 전체적인 구조를 보면 Spring Data JPA가 JPA라는 규칙을 사용하는데 이 규칙은 Hibernate가 이 규칙을 구현했고 Hibernate는 구현할때 JDBC를 사용한다고 볼 수 있다.

 

📖 Spring Data JPA를 이용해 다양한 쿼리 작성하기

이제 삭제 기능을 Spring Data JPA로 변경해보자. 먼저 삭제는 요청으로 들어온 유저의 이름이 존재하는지 확인하고 있다면 삭제쿼리를 날리고 아니면 예외를 날린다.

public void deleteUser(String name) {
  User user = this.userRepository.findByName(name).orElseThrow(IllegalArgumentException::new);

  this.userRepository.delete(user);
}

여기서 나온게 findByName과 delete 메서드이다. findByName은 기본으로 제공해준 메서드가 아니고 우리가 인터페이스에 정의를 해야한다.

public interface UserRepository extends JpaRepository<User, Long> {

   Optional<User> findByName(String name);
}

이런식으로 정의를 하면 이 메서드를 사용할때 select * from user where name = ? 쿼리가 나간다.

다음으로 delete 메서드는 기본으로 제공해주는 메서드이다. 이 메서드를 사용하면 delete SQL이 나간다.

이제 구체적으로 findByName처럼 우리가 일정 규칙에 맞게 인터페이스에 정의를 하면 쿼리들을 제공해주는데 그 규칙들을 살펴보자.

find : 1건을 가져온다. 반환 타입은 객체가 될 수도 있고, Optional<타입>이 될 수도 있다.

findAll : 쿼리의 결과물이 N개인 경우 사용. List<타입> 반환.

exists : 쿼리 결과가 존재하는지 확인. 반환 타입은

boolean count : SQL의 결과 개수를 센다. 반환 타입은 long이다.

이제 By뒤에 규칙을 알아볼 텐데 By뒤에는 where 조건을 적어주는 것처럼 적어주면 된다. 조건이 여러개일 경우 And 혹은 or 조건을 통해 규칙을 정해준다.

🏛 예시

List<User> findAllByNameAndAge() : select * from user where name = ? and age = ?

그외에 아래와 같이 다양한 조건들을 붙일 수 있다.

📚 By 뒤에 조건

GreaterThan : 초과

GreaterThanEqual : 이상

LessThan : 미만

LessThanEqual : 이하

Between : 사이에

StartsWith : ~로 시작하는

EndsWith : ~로 끝나는

 

Day8. 트랜잭션과 영속성 컨텍스트

📖 트랜잭션 이론편

트랜잭션이란 무엇일까? 트랜잭션 말만 들어봤지 이게 정확히 무슨 의미인지 알지 못했다. 트랜잭션은 아래와 같이 말한다.

트랜잭션: 쪼갤 수 없는 업무의 최소 단위 = 모두 성공시키거나, 모두 실패시킨다.

상황을 살펴보자.

쇼핑몰이 있다고 하자. 어떤 회원이 주문을 하는 상황을 생각해보자. 주문을 하면 주문내역이 저장되고 포인트가 저장되고 결제기록이 저장될 것이다. 이 비즈니스 로직은 하나의 메서드로 묶여 있다. 그러다가 어떠한 이유로 결제기록의 비즈니스 로직에서 에러가 발생했다고 하자. 그러면 주문내역과 포인트는 있는데 결제되었다는 사실이 없을 것이다. 이런 경우 특정 비즈니스 로직에 에러가 발생할 경우 모든 SQL을 실패시켜야 할 것이다. 물론 모두 성공할 경우 성공시켜야 할 것이다. 이것을 트랜잭션이 해결해준다.

DB 쿼리로 트랜잭션 시작을 알리는 쿼리는 아래와 같다.

start transaction;

트랜잭션 정상 종료는 아래와 같다.

commit;

트랜잭션 실패 처리는 아래와 같다.

rollback;

이 실습을 통해 알게 된 점은 트랜잭션 안에 저장/업데이트/삭제 쿼리가 발생해도 commit 전까지 반영이 안 된다는 점이다.

 

📖트랜잭션 적용과 영속성 컨텍스트

Spring Data JPA에서 트랜잭션 적용은 @Transactional 어노테이션으로 해결할 수 있다. 이 어노테이션은 서비스 레이어의 저장/업데이트/삭제 로직에 붙일 수 있다. 조회로직에는 @Transactional(readOnly = true)로 쓸 수 있다.

그리고 강좌에서 아래와 같이 말씀하셨다.

⚠ 주의

CheckedException은 롤백이 일어나지 않는다.

하지만 이 점이 궁금해서 알아본 결과 아래와 같다.

RuntimeException이든 CheckedException이든 rollback을 할지 말지는 우리가 결정할 수 있다. 바로 @Transactional의 rollbackFor이라는 옵션을 통해서다. 다만, 기본적으로는 CheckedExcpetion은 rollback을 하지 않고 RuntimeExcpetion은 rollback을 해준다. 이점을 명심하자.

영속성 컨텍스트는 테이블과 매핑된 Entity 객체를 관리/보관하는 역할을 한다. 즉, 쉽게 말해서 스프링에서는 트랜잭션을 사용하면 영속성 컨텍스트가 생겨나고, 트랜잭션이 종료되면 영속성 컨텍스트가 종료된다.

영속성 컨텍스트에는 마치 초능력자처럼 능력을 몇가지 가지고 있다.

  1. 변경감지(Dirty Check): 영속성 컨텍스트 안에서 불러와진 Entity는 명시적으로 save하지 않더라도, 변경을 감지해 자동으로 저장된다. 그래서 이전에 업데이트 로직에서 마지막에 save로직으로 저장을 했는데 @Transactional 어노테이션이 붙으면 아래와 같이 작성이 가능하다.

@Transactional
public void updateUser(UserUpdateRequest request) {
  User user = this.userRepository.findById(request.getId()).orElseThrow(IllegalArgumentException::new);
  user.updateName(request.getName());
}

  1. 쓰기 지연: DB의 INSERT / UPDATE / DELETE SQL을 바로 날리는 것이 아니라, 트랜잭션이 commit될 때 모아서 한 번만 날린다. 이런 기능이 없다면 save 메서드가 3개가 있을 때 insert 쿼리를 일일이 3번 날리는게 아니라 일단 영속성 컨텍스트가 기억하고 한번에 날려준다.

  2. 1차 캐싱: 똑같은 객체를 조회하는 로직이 있을 때 조회하는 만큼 일일이 조회쿼리를 날려주는게 아니라 처음에 영속성 컨텍스트가 해당 객체를 캐싱하고 다음 같은 객체 조회를 할때 이를 기억하고 한번의 쿼리만 날라간다.

Day9. 조금 더 복잡한 기능을 API로 구성하기

이번에는 실전으로 책을 생성하고 대출하고 반납하는 기능을 만들었다. 여기서 이제까지 배운 개념들을 적용했다. 물론 코치님께서 알려주시긴 하지만 나는 강좌를 멈추고 내 스스로 코드를 작성해본 다음에 코치님 설명과 비교를 했다. 여기서 대출기능을 할 때 나는 연관관계를 매핑해서 처리를 할려고 했지만 코치님께서는 일단은 대출관련 테이블을 만든 뒤에 그에 대한 엔티티, repository, service를 만드셨다. 그래서 나는 여기서 조금 깨달은 부분이 있었다. 무조건 연관관계를 짓는게 아니라 만약 실무에서 연관관계를 짓는게 불가하다면 이런 경우로 풀수도 있다는 사실을 깨달았다.

미션 해결과정

Day6

이번 미션은 과제4에서 만들었던 Fruit관련 API를 3단분리하고, FruitRepository를 인터페이스로 만들고 해당 인터페이스를 구현한 FruitMemoryRepository와 FruitMysqlRepository를 만들어 @Primary 어노테이션을 통해 repository의 역할을 바꿔가며 해보는 과제였다.

나는 먼저 기존 컨트롤러에 모여있는 비즈니스 로직을 저장, 수정, 조회기능은 repository레이어에 그리고 예외처리관련은 서비스 레이어에 분리하였다. 그리고 컨트롤러는 순수 HTTP 통신 관련만 구현해두었다. 그런 다음에 DB로직 관련 repository 클래스를 FruitMysqlRepository로 변경하고 FruitRepository 인터페이스를 생성 후 구현하고 나머지 FruitMemoryRepository를 생성하여 메모리 관련 로직을 작성해두었다. 다음 각각 클래스에 @Primary 어노테이션을 붙이고 각각 메서드에 Logback을 이용해 로그를 찍으면서 확인을 했다. 이를 통해 학습의 효과를 느낄 수 있었다. 학(강의 시청)으로 개념을 배우고 습(실습을 통한 체득)으로 체득을 함으로 좀 더 익숙하게 쓸 수 있게 되는 계기가 된 것 같다. 자세한 것은 아래 블로그를 통해 보시면 자세한 과정을 알 수 있다.

https://inf.run/3EWwN

피드백

피드백 전까지 테스트코드도 나름 잘 작성하고 validation부분까지 잘 작성해서 나름 이번은 성공적이라고 느꼈다. 하지만 코치님께서 피드백을 주셨다. 서비스의 비즈니스 로직이 복잡할 때는 다른 내부 서비스 로직을 호출하기도 하지만 DTO와 도메인에 계산로직과 비즈니스 로직을 나눠서 넣기도 한다고 하였다. 내 코드를 보니 뭔가 DTO에도 처리할만한 부분이 있지 않았을 까 반성하게 되는 계기 된 것같다.

 

Day7

이번 미션은 과제6에서 만든 기능들을 JPA로 변경하는 부분이 있었다. 또한 다양한 쿼리메서드를 연습해볼 기회로 문제를 몇개 주셨다. 먼저 문제1에서 Spring Data JPA로 바꾸는 것은 그리 어려운 작업은 아니었던 것 같았다. 단순히 repository 인터페이스를 JpaRepository에 상속받고 엔티티를 연습했던것처럼 바꿔주면 되기 때문이다. 하지만 나는 여기서 더 나아갔다. 집계함수 부분을 Spring Data JPA로 변경할 때 좀 고민이 있었다. 집계함수를 제공해주는 쿼리메서드는 없었던 것 같았다. 그래서 집계함수를 이용하지 않고 select 쿼리를 이용해서 List<엔티티> 타입으로 반환해야하나 생각을 하던 결과 문듯 아이디어가 떠올랐다. 바로 @Query와 jpql이다. 그래서 나는 여기서 @Query 어노테이션을 이용하여 JPQL로 쿼리를 작성해보았다. 그리고 반환을 엔티티타입이 아닌 DTO로 반환해보았다. 그러니 서비스 레이어도 간단해졌다.

그렇게 쉽게 바꿔서 문제1은 가볍게 해결했다. 그리고 문제2를 풀면서 다양한 쿼리 메서드를 테스트할 수 있었다. 먼저 count~로 시작하는 메서드를 만들어 count 쿼리를 작성할 수 있었다.

마지막 문제3도 GreaterThanEqual, LessThanEqual의 조건을 이용하는 쿼리메서드를 작성하는 거였다.

이번 미션도 테스트를 작성해보고 이번엔 진짜 잘했다고 느꼈다. JPQL을 통해 DTO로 직접 반환하는 부분까지 완벽했다고 자만했다. 하지만 피드백을 듣고 아직 많이 부족하다는 것을 느꼈다.

피드백

마지막 문제의 parameter GTE, LTE 부분을 enum 클래스로 관리할 수 있다고 하셨다. 이 말을 본 순간 "앗~"이라는 말이 절로 나왔다. enum을 아예 몰랐던것도 아니고 조금 반성하게 된 계기였다. 금방 과제가 끝났다고 끝까지 고민을 못해본 결과였다.

 

Day8 ~

Day8부터 미니프로젝트 과제이다. 아직은 미니프로젝트 미완성이므로, 해당 프로젝트가 단계별 완성시, 새로운 포스트로 남기겠다.

회고

오늘까지 나는 학습을 하면서 많은 것을 깨달았다. 물론 지식도 지식이지만 하나의 문제를 풀 때 수학처럼 다양한 방식으로 푸는 방법에 대해 깨달음을 얼었다. 무조건 좋은 방법으로 풀 수 없는 경우 우회를 해서 푸는 방식으로도 할 수 있다는 것을 알고 나 자신 스스로 반성하는 부분을 가졌다. 마음속으로 "이렇게 해서 우수러너가 될 수 있으며 원하는 기업으로 이직을 할 수 있을까?"라는 반성의 시간을 가지고 다른 열심히 하시는 러너분들을 생각해 더욱 자극을 받아서 우수러너가 되기까지 노력해보기로 생각을 하였다.

 

댓글을 작성해보세요.

채널톡 아이콘