[기본] #7 의존관계 자동 주입 (@Autowired)

본 포스팅은 인프런 - 스프링 핵심 원리(기본편)을 강의를 바탕으로 공부하고 정리한 글입니다.

 

의존관계 자동 주입 방법

의존관계 자동 주입은 크게 4가지 방법이 있다.

• 생성자 주입
• 수정자 주입 (setter 주입)
• 필드 주입
• 일반 메소드 주입

 

생성자 주입

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    
    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

• 생성자를 통해 의존 관계를 주입 받는 방법이다.
• 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다.
• 생성자 호출 방식은 불변, 필수 의존 관계에서 자주 사용된다.
  • 생성자를 private final 필드에 넣어줘 값을 필수적으로 가지도록 한다.
  • setter를 두지 않아 값이 변경되지 않도록 한다.

+ 중요! 생성자가 딱 1개만 있다면 @Autowired를 생략해도 자동 주입된다. (스프링 빈에만 해당)

 

setter 주입

@Component
public class OrderServiceImpl implements OrderService {
    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;
    
    @Autowired
    public void setMemberRepository(MemberRepository memberRepository) {
    	this.memberRepository = memberRepository;
    }
    
    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy) {
    	this.discountPolicy = discountPolicy;
    }
}

• 필드의 값을 변경하는 setter를 통해 의존관계를 주입하는 방법이다.
• setter 주입 방식은 선택, 변경 가능성이 있는 의존관계에 사용된다.
• 기존에 final을 제외하고, 자바빈 프로퍼티 규약에 따라 메소드를 만들면 @Autowired가 달린 setter메소드를 통해 의존관계를 주입해준다.

@Autowired는 기본적으로 주입할 대상이 없으면 오류가 발생한다.
주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false)로 지정하면 된다.

자바빈 프로퍼티 규약
• 자바에서 필드의 값을 직접 변경하지 않고, setXxx, getXxx라는 메소드를 통해 값을 읽거나 변경하는 규칙이다.

 

필드 주입

@Component
public class OrderServiceImpl implements OrderService {
    @Autowired private MemberRepository memberRepository;    
    @Autowired private DiscountPolicy discountPolicy;
}

• 클래스 필드에 @Autowired를 명시해 바로 주입하는 방법이다.
• 코드가 간결하지만 외부에서 변경이 불가능해 테스트하기 힘들다는 치명적인 단점이 있기 때문에 사용을 지양해야 한다.
• 필드 주입 방식은 DI 프레임워크(스프링)가 없으면 아무것도 할 수 없다. (순수 자바 코드로 테스트를 작성하기 어려움)
• 단, 간단한 테스트나 특수한 목적으로는 사용할 수 있다.
  • 어플리케이션의 실제 코드와 관계 없는 테스트 코드에서 사용
  • 스프링 설정을 목적으로 하는 @Configuration 같은 곳에서 특별한 목적으로 사용

순수한 자바 테스트 코드에서는 @Autowired가 동작하지 않으며, @SpringBootTest처럼 스프링 컨테이너를 테스트에 통합한 경우에만 가능하다.

 

일반 메소드 주입

@Component
public class OrderServiceImpl implements OrderService {
    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;
    
    @Autowired
    public void init(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }   
}

• 일반 메소드를 통해 주입 받는 방법이다.
• 한번에 여러 필드를 주입 받을 수 있다.
• setter 주입으로 해결되기 때문에 일반적으로는 잘 사용하지 않는 방법이다.

@Autowired를 통한 의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작한다.
스프링 빈이 아닌 Member 같은 일반 자바 클래스에서는 의존관계 자동 주입이 적용되지 않는다!

 

 

의존관계 자동 주입 옵션 처리

@Autowired를 사용하면 required 옵션의 기본값이 true로 되어 있어 자동 주입 대상이 없을 경우 오류가 발생한다.

주입 할 스프링 빈이 없어도 오류 없이 동작하도록 하기 위한 옵션 처리를  알아보자.

 

💡 옵션 처리의 3가지 방법

• @Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메소드 자체가 호출되지 않음
• org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력된다.
• Optional<> : 자동 주입할 대상이 없으면 Optional.empty가 입력된다.

 

📁 test/autowired/AutoWiredTest

public class AutoWiredTest {
    @Test
    void AutoWiredOption() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class);
    }

    static class TestBean {
        // 호출 안됨
        @Autowired(required = false)
        public void setNoBean1(Member noBean1) {
            System.out.println("noBean1 = " + noBean1);
        }
        
        // null 호출
        @Autowired
        public void setNoBean2(@Nullable Member noBean2) {
            System.out.println("noBean2 = " + noBean2);
        }
        
        // Optional.empty 호출
        @Autowired
        public void setNoBean3(Optional<Member> noBean3) {
            System.out.println("noBean3 = " + noBean3);
        }
    }
}

• Member는 자바 클래스로 스프링 빈이 아니기 때문에 @Autowired를 통해 자동 주입이 적용되지 않는다. 즉, 주입 할 스프링 빈이 존재하지 않는 것이다.
• 3가지 옵션 처리를 사용해 오류가 처리된 것을 확인할 수있다.
  • required=faulse : 주입 대상이 없어 메소드 자체가 호출되지 않아 noBean1이 아예 출력되지 않음
  • @Nullable : 주입 대상이 없어 호출은 되지만 null로 출력됨
  • Optional<> : 주입 대상이 없어 호출은 되지만 Optional.empty로 출력됨

 

 

생성자 주입을 지향하자❗️

다양한 의존관계 주입 방법 중에서 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 사용을 권장한다.

그 이유는 다음과 같다.

• 불변
  • 대부분의 의존관계는 어플리케이션 종료 전까지 변하면 안된다.
  • 수정자 주입을 사용할 경우 setXxx 메소드를 public으로 열어두는데, 변경하면 안되는 메소드를 열어두는 것은 좋은 설계 방법이 아니다.
  • 생성자 주입 방식은 객체를 생성할 때 딱 1번만 호출되므로, 의존관계를 불변하게 설계할 수 있다.
• 누락
  • 생성자 주입을 사용하면 주입 데이터를 누락했을 경우 컴파일 오류가 발생한다.
  • 또한 IDE에서 바로 어떤 값을 필수로 주입해야 하는지 알 수 있다.
• final 키워드
  • 생성자 주입을 사용하면 필드에 final 키워드를 사용할 수 있어, 생성자에 혹시라도 값이 설정되지 않았을 경우 컴파일 오류가 발생한다.

 

생성자 주입 방식을 권장하는 이유는 여러가지가 있지만, 프레임워크에 의존하지 않고 순수 자바 언어의 특징을 잘 살리는 방법이라는 점이 중요하다.

따라서 기본적으로 항상 생성자 주입을 사용하고, 가끔 옵션이 필요할 경우 수정자 주입 방식을 선택하도록 하자. (생성자 주입과 수정자 주입 동시 사용 가능)

 

 

롬복(Lombok) 사용

생성자 주입 방식을 사용하면 private final 필드를 만들어 생성자를 통해 주입 받도록 설정하는데 이는 귀찮은 작업일 수 있다.

이때 롬복이라는 라이브러리를 사용하면 좀 더 편리하게 사용할 수 있다.

롬복 라이브러리 추가

📁 build.gradle

plugins {
    ...
}

group = 
version = 
sourceCompatibility =

// lombok 설정 추가 시작
configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}
// lombok 설정 추가 끝

repositories {
    ...
}

dependencies {
    ...

    // lombok 라이브러리 추가 시작
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    testCompileOnly 'org.projectlombok:lombok'
    testAnnotationProcessor 'org.projectlombok:lombok'
    // lombok 라이브러리 추가 끝
}

+ 인텔리제이 환경 설정

• Enable annotation processing 체크 박스 표시

 

@RequiredArgsConstructor

final 붙은 필드를 모아 자동으로 생성자를 만들어 준다.

 

👉🏻 적용 전

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    // 생성자 주입
    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

👉🏻 적용 후

@Component
@RequiredArgsConstructor // 롬복이 생성자 자동 생성
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
}

• 롬복이 자바의 애노테이션 프로세서라는 기능을 이용해 컴파일 시점에 생성자 코드를 자동으로 생성해줘 코드가 훨씬 간결해진 것을 확인할 수 있다.

+ 롬복 라이브러리가 제공하는 기능

• @Getter, @Setter : getter, setter 메소드를 자동 생성

@Getter
@Setter
@ToString
public class HellLombok {
    private String name;
    private int age;

    public static void main(String[] args) {
        HellLombok hellLombok = new HellLombok();

        // setter
        hellLombok.setName("anne");
        hellLombok.setAge(26);

        // getter
        System.out.println("name = " + hellLombok.getName());
        System.out.println("age = " + hellLombok.getAge());
        
        // toString
        System.out.println("hellLombok = " + hellLombok);
    }
}

 

 

조회 빈이 2개 이상일 때 의존관계 자동 주입 방법

@Autowired는 타입으로 빈을 조회한다고 했다.

때문에 해당 타입의 빈이 2개 이상일 경우, NoUniqueBeanDefinitionException 오류가 발생한다. 

• 예) DiscountPolicy - FixDiscountPolicy, RateDiscountPolicy → ac.getBean(DiscountPolicy.class)시 2개의 빈이 존재해 오류 발생

 

👉🏻 같은 타입의 스프링 빈 2개 등록

@Component
public class FixDiscountPolicy implements DiscountPolicy { ... }

@Component
public class RateDiscountPolicy implements DiscountPolicy { ... }

👉🏻 의존관계 자동 주입 실행

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }    
}

스프링 컨테이너가 DiscountPolicy의 의존관계를 주입하려고 하는데, 타입 조회를 해보니 2개의 빈이 있어 무엇을 사용해야할지 몰라 오류(NoUniqueBeanDefinitionException)를 발생시킨 것이다.

• 오류 메세지 : expected single matching bean but found 2 : fixDiscountPolicy, rateDiscountPolicy

 

해당 오류를 해결하기 위해서는 자동 의존 관계 주입에서 2개 이상의 빈이 등록되었을 때 하나만 연결되도록 추가적인 설정이 필요하다.

• @Autowired 필드명 매칭
• Qualifier → @Qualifier끼리 매칭 → 빈 이름 매칭
• @Primary 사용

 

@Autowired 필드명 매칭

@Autowired는 우선 타입 매칭을 시도하고, 그 결과 여러 개의 빈이 있으면 필드 이름이나 파라미터 이름을 기준으로 추가 매칭한다.

1. 타입 매칭 진행
2. 필드명, 파라미터 명으로 빈 이름 매칭

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy rateDiscountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = rateDiscountPolicy;
    }
}

스프링은 DiscountPolicy의 파라미터 이름인 rateDiscountPolicy을 가지고 추가 매칭을 진행해 RateDiscountPolicy 빈을 주입해준다.

 

@Qualifier 사용

@Qualifier는 추가 구분자를 붙여주는 방법이다. 

• @Qualifier끼리 매칭
• 없으면, 빈 이름 매칭
• 없으면 NoSuchBeanDefinitionException 예외 발생

👉🏻 추가 구분자 지정

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy { ... }

@Component
@Qualifier("fixDiscountPolicy")
public class FixDiscountPolicy implements DiscountPolicy{ ... }

👉🏻 @Qualifier 매칭

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, @Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

• @Qualifier("mainDiscountPolicy")을 기준으로 매칭 → RateDiscountPolicy
• 이때 @Qualifier("mainDiscountPolicy")을 찾지 못하면 MainDiscountPolicy 이름의 스프링 빈을 찾고, 그것도 없으면 예외가 발생한다.
• @Qualifier는 @Qualifier끼리 찾는 용도로만 사용하는 것이 명확하고 좋다.

 

@Primary 사용

• @Primary는 우선순위를 정하는 방법이다.
• @Autowired 결과 여러 빈이 매칭되면 @Primary가 붙은 빈을 우선적으로 주입한다.

@Primary
@Component
public class RateDiscountPolicy implements DiscountPolicy { ... }

@Component
public class FixDiscountPolicy implements DiscountPolicy { ... }

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    } 
}

• @Primary를 통해 우선권을 가지는 RateDiscountPolicy가 주입된다.

@Primary vs @Qualifier
• @Qualifier를 사용하면 주입 받을 때 모든 코드에 @Qualifier를 붙여줘야 하지만, @Primary를 사용하면 붙일 필요가 없다.
• @Qualifier와 @Primary를 동시에 사용했을 경우에 스프링은 자동보다는 수동이, 넓은 범위보다는 좁은 범위의 우선순위가
   더 높기 때문에 @Qualifier의 우선권이 더 높다.
• 실무에서 이 둘을 활용한다면 메인 데이터베이스의 커넥션을 획득하는 스프링 빈은 @Primary를 적용하고, 서브 데이터베이스
   커넥션 빈을 획득할 때는 @Qualifier를 지정하여 명시적으로 빈을 획득하는 방식을 사용하면 코드를 깔끔하게 유지할 수 있다.

 

애노테이션 직접 만들기

@Qualifier("mainDiscountPolicy")와 같이 문자를 적으면 컴파일시 타입 체크가 되지 않는다. (이렇게 되면 오류 발생 시 찾기 힘듬)

따라서 애노테이션을 만들어 타입 체크가 이뤄질 수 있도록 하는 것이 좋다.

 

👉🏻 애노테이션 생성

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy  {

}

👉🏻 애노테이션 적용

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy { ... }

@Autowired
public OrderServiceImpl(MemberRepository memberRepository, @MainDiscountPolicy DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

• @Qualifier("mainDiscountPolicy")를 어노테이션으로 생성해 @MainDiscountPolicy의 스펠링이 틀릴 경우 컴파일 오류가 발생하는 등의 타입체크가 가능하게 되었다.

이렇게 여러 애노테이션을 조합해 사용하는 기능은 스프링이 지원해주는 기능이다.
@Qulifier 뿐만 아니라 다른 애노테이션들도 함께 조합해서 사용할 수 있다.
극단적으로 @Autowired도 재정의 할 수 있다. 하지만 스프링이 제공하는 기능을 뚜렷한 목적 없이 무분별하게 재정의하는 것은 유지보수에 더 혼란만 가중할 수 있기 때문에 유의하자.

 

 

조회한 빈이 모두 필요할 때 의존관계 자동 주입 방법

의도적으로 해당 타입의 스프링 빈이 다 필요한 경우도 있다.

예를 들어 할인 서비스를 제공하는데, 클라이언트가 할인의 종류(rate, fix)를 선택할 수 있다고 가정해보자.

 

스프링을 사용하면 전략 패턴을 매우 간단하게 구현할 수 있다.

Map과 List로 받기

📁 test/autowired/AllBeanTest

public class AllBeanTest {

    @Test
    void findAllBean() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
        DiscountService discountService = ac.getBean(DiscountService.class);
        Member member = new Member(1L, "userA", Grade.VIP);
        
        int discountPrice = discountService.discount(member, 10000, "fixDiscountPolicy");
        int rateDiscountPrice = discountService.discount(member, 20000, "rateDiscountPolicy");

        assertThat(discountService).isInstanceOf(DiscountService.class);
        assertThat(discountPrice).isEqualTo(1000);
        assertThat(rateDiscountPrice).isEqualTo(2000);

    }

    static class DiscountService {
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;

        @Autowired
        public DiscountService(Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> policies) {
            this.policyMap = policyMap;
            this.policies = policies;
            System.out.println("policyMap = " + policyMap);
            System.out.println("policies = " + policies);
        }

        public int discount(Member member, int price, String discountCode) {
            DiscountPolicy discountPolicy = policyMap.get(discountCode);
            return discountPolicy.discount(member, price);
        }        
    }
}

• 생성자 주입
  • Map<String, DisocuntPolicy>
    • DiscountPolicy 타입으로 조회된 모든 스프링 빈을 key(스프링 빈의 이름) - value(스프링 빈) 형태로 담는다.
    • 이때 FixDiscountPolicy, RateDiscountPolicy가 주입된다.
  • List<DiscountPolicy>
    
    • DiscountPolicy 타입으로 조회된 모든 스프링 빈을 담는다.
    • 만약 해당하는 타입의 스프링 빈이 없으면 빈 컬렉션이나 Map을 주입한다.

• discount() 메소드
  • discountCode로 "fixDiscountPolicy"가 넘어오면 Map에서 fixDiscountPolicy 스프링 빈을 찾아서 실행하고,
  • "rateDiscountPolicy"가 넘어오면 rateDiscountPolicy 스프링 빈을 찾아서 실행한다.
• 스프링 컨테이너 생성하면서 스프링 빈 등록
  • new AnnotationConfigApplicationContext()를 통해 스프링 컨테이너 생성
  • AutoAppConfig.class, DiscountService.class를 파라미터로 넘기면서 해당 클래스를 스프링 빈으로 자동 등록한다.

 

 

자동 vs 수동 주입 선택 기준

어떤 경우에 컴포넌트 스캔을 통한 자동 주입을 사용하고, 어떤 경우에 설정 정보를 통한 수동 주입을 사용해야 할까?

 

우선 스프링이 나오고 수동보다 자동을 선호하는 추세이다.

스프링은 @Component 뿐만 아니라 @Controller, @Service, @Repository처럼 계층에 맞춰 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다. 또한 최근 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고, 스프링 부트의 다양한 스프링 빈들도 조건이 맞으면 자동으로 등록하도록 설계되었다.

 

설정 정보를 기반으로 애플리케이션을 구성하는 부분과 실제 동작하는 부분을 명확하게 나누는 것이 이상적이지만, 스프링 빈을 등록 할 때 @Component 하나만 붙이면 끝나는 일을 @Configuration 설정 정보에 가서 @Bean을 적고, 객체를 생성하고, 주입할 대상을 일일이 적어주는 과정은 상당히 번거로운 일이다.

 

따라서 @Configuration 설정 정보에서 @Bean을 통한 빈 등록과 주입할 대상을 일일이 적어주는 수동 주입보다

@Component와 @Autowired를 적극 활용해 OCP, DIP등 SOLID 기본원칙을 잘 지키는 자동 주입 구현을 하는 것이 좋다.

 

수동 빈 등록을 사용하는 경우

1. 기술 지원 로직 빈의 경우
   1. 애플리케이션은 크게 업무 로직과 기술 지원 로직으로 나눌 수 있다.
      1. 업무 로직 빈 : 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층 로직을 처리하는 레포지토리 등이 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.
      2. 기술 지원 빈 : 기술적인 문제나 공통 관심사(AOP), 데이터베이스 연결, 공통 로그 처리 등의 업무 로직을 지원하기 위한 하부기술이나 공통 기술들이다.
   2. 업무 로직은 숫자도 많고, 컨트롤러, 서비스, 레포지토리 처럼 어느정도 패턴이 있으며, 보통 문제가 발생해도 어떤 곳에서 문제가 발생했는지 명확하게 파악하기 쉽다. 이런 경우는 자동 등록 기능을 적극 사용하는 것이 좋다.
   3. 기술 지원 빈은 애플리케이션 전반에 걸쳐 광범위하게 영향을 미치기 때문에 가급적 수동 빈으로 등록해서 설정 정보에 바로 나타나도록 관리하는 것이 유지보수에 더 좋다.
2. 비즈니스 로직에서 다형성을 적극 활용하는 경우
   • 위에서 다뤘던 할인 정책 빈과 같이 인터페이스(DiscountPolicy)를 활용해 다형성을 가지는 빈(fix, rate)을 관리할 경우
     아래와 같이 수동 빈 등록으로 따로 관리해주는 것이 한눈에 어떤 빈들이 주입되는지 파악할 수 있어 좋다.
   • 이때 자동 빈 등록을 사용한다면 파악이 쉽도록 인터페이스(DiscountPolicy)의 구현 빈들만 따로 특정 패키지에 모아두는 것이 좋다.

@Configuration
public class DiscountPolicyConfig {
    @Bean
    public DiscountPolicy rateDiscountPolicy() {
        return new RateDiscountPolicy();
    }
    
    @Bean
    public DiscountPolicy fixDiscountPolicy() {
        return new FixDiscountPolicy();
    }
}

스프링과 스프링 부트가 자동으로 등록하는 빈들은 예외이다. 이런 부분들은 스프링 자체를 잘 이해하고 스프링의 의도대로 편리하게 잘 사용하면 된다.

 

💡 정리

• 편리한 자동 기능을 기본으로 사용하자
• 직접 등록하는 기술 지원 객체는 수동 등록을 통해 설정 정보에서 바로 나타나게 관리하자
• 다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자