10회차(2024.12.29)

1. 스프링 프레임워크에서 IoC 와 DI 의 차이점은 무엇인가요?

IoC(Inversion of Control) - "객체를 누가 관리하는가"에 대한 철학

• IoC 는 객체의 생성과 그 객체의 생명주기 관리 책임을 개발자가 아닌 컨테이너(Spring Container) 가 담당하도록 제어의 흐름을 뒤집는 설계 원칙이다.

• ex) 일반적인 객체 생성 방식에서는 개발자가 직접 new 키워드로 객체를 생성하고, 다른 객체에 주입한다. 하지만 IoC 에서는 객체 생성 및 의존성 설정 작업을 Spring 컨테이너가 맡아 처리한다.

• 핵심 포인트

  • IoC 는 객체 생성, 의존성 관리, 생명주기 제어를 포함하는 큰 개념이다.

  • IoC 는 애플리케이션의 유연성과 확장성을 높이는 데 기여한다.

  • 대표적인 구현체 : BeanFactory, ApplicationContext

DI(Dependency Injection) - "객체를 어떻게 연결하는가"에 대한 방법론

• DI 는 IoC 를 구현하는 한 가지 방법으로, 객체 간의 의존성을 외부에서 주입하는 것을 의미한다.

• 동작방식) Spring 컨테이너가 의존성을 가진 객체를 생성한 후, 필요로 하는 곳에 자동으로 주입해 준다.

• DI 는 필드, 생성자, 세터 주입을 사용할 수 있다.

• DI 를 통해서 결합도를 줄이고, 테스트 가능성과 유지보수 성을 높을 수 있다.

DI 를 사용하지 않았을 때 단점

1. 직접 의존성 생성

   1. 객체가 자신의 의존성을 직접 생성하거나 관리한다. (결합도가 상승한다)

   2. 예 :

public class MyService {
    private final Dependency dependency;

    public MyService() {
        this.dependency = new Dependency(); // 직접 생성
    }

    public void performService() {
        dependency.performTask();
    }
}

1. 높은 결합도

   1. 객체가 특정 클래스 구현체에 강하게 의존한다. (위 코드는 의존성을 변경할 수 없는 결합도가 상당히 높은 코드이다)

   2. 예를 들어, MyService 는 항상 Dependency 의 구체적인 구현체를 사용해야 하므로, 다른 구현체로 교체하거나, Mock 객체를 사용하는 것이 어렵다.

2. 테스트 어려움

   1. 테스트 중 Dependency 객체를 교체하거나, Mocking 할 수 없기 때문에, 의존성에 따라 테스트가 제한된다. (의존성을 변경해주려면 테스트 코드가 아닌, 기존 코드도 수정해주어야 한다)

   2. 모든 테스트가 실제 객체를 사용해야 하므로, 테스트 실행 속도가 느려지고, 외부 리스소 의존성이 추가될 가능성이 있다.

public class MyServiceTest {
    @Test
    void testExecute() {
        MyService service = new MyService();

        // 실제 Dependency의 작업이 실행됨
        service.execute();

        // 결과를 검증할 방법이 제한적
    }
}

1. 유지보수성 문제

   1. 클래스 내부에서 의존성을 관리하기 때문에, 의존성 변경 시 클래스 코드도 수정해야 한다.

DI 를 사용했을 때 장점

1. 의존성 주입

   1. 의존성을 스프링 컨테이너가 관리하며, 필요할 때 객체를 주입한다.

   2. 예 :

@Component
public class MyService {
    private final Dependency dependency;

    @Autowired
    public MyService(Dependency dependency) {
        this.dependency = dependency;
    }

    public void performService() {
        dependency.performTask();
    }
}

1. 낮은 결합도

   1. 객체가 인터페이스, 추상 클래스에 의존하도록 설계할 수 있다.

   2. 스프링 컨테이너가 실제 의존성을 넣어주기 주입하기 때문에 인터페이스, 추상 클래스를 의존하는 설계가 가능하다.

2. 테스트 용의성

   1. 테스트 시 의존성을 Mock 객체로 대체 가능

   2. 예 :

@Test
void testMyService() {
    Dependency mockDependency = Mockito.mock(Dependency.class);
    MyService myService = new MyService(mockDependency);

    myService.performService();

    Mockito.verify(mockDependency).performTask();
}

1. 유지보수성 향상

   1. 클래스 내부 코드 수정 없이 의존성을 변경할 수 있다.

   2. 새로운 의존성 구현체를 추가하거나 교체하는 작업의 비용이 적어진다.

라이브러리

• 특정 기능을 구현하기 위해 제공하는 코드 집합으로, 개발자가 직접 호출해서 사용하는 도구

  • 개발자가 필요한 부분만 골라 사용하며, 호출의 주체는 개발자이다.

  • 개발자가 전체 애플리케이션의 흐름을 통제한다.

프레임워크

• 프레임워크는 애플리케이션의 구조와 흐름을 미리 정의해 둔 틀이다.

  • IoC 를 통해, 프레임워크가 애플리케이션 흐름을 제어한다.

  • 개발자는 프레임워크가 요구하는 방식대로 코드를 작성하며, 특정 부분만 확장하거나 구현한다.

프레임워크가 애플리케이션의 흐름을 강제하는 이유?

• 프레임워크가 애플리케이션 흐름을 강제하는 이유는 IoC(Inversion of Control) 원칙을 통해 개발자가 비즈니스 로직에 집중할 수 있도록 지원하기 위해서이다.

• 이를 통해 공통 작업은 프레임워크가 관리하고, 개발자는 핵심 로직만 구현할 수 있다.

• 예를 들어, Spring MVC 에서는 요청 처리 흐름을 프레임워크가 담당하므로, 개발자는 컨트롤러와 서비스 계층의 구현에만 집중하면 된다.

• 때문에, 각 프레임워크가 강제하는 내용들에 대해 생각해보다보면, 프레임워크의 철학을 알아갈 수 있다.

1-1. IoC 컨테이너 내부 동작 원리를 설명해주세요.

1. 설정 파일 / 애노테이션 분석

• IoC 컨테이너는 애플리케이션의 설정 정보를 읽어 어떤 객체를 관리할지 결정한다.

• 설정 소스

  • XML 설정 (applicationContext.xml)

  • Java Config 클래스 (@Configuration 및 @Bean)

  • Component Scanning(@Component, @Controller, @Service, @Repository)

2. BeanDefinition 생성 및 저장

• 컨테이너는 설정 파일이나 애노테이션 정보를 통해 BeanDefinition 객체를 생성한다.

  • BeanDefinition : 각 Bean 에 대한 메타데이터(이름, 클래스, 의존성, 라이프사이클 등) 를 포함하는 객체

• 모든 BeanDefinition 은 컨테이너의 BeanFactory 에 등록된다.

3. Bean 생성 (Lazy vs Eager Instantiation)

• 기본적으로 싱글톤(Singleton) 스코프의 Bean 은 컨테이너 초기화 시점에 즉시 생성(Eager Instantiation) 된다.

• 단, @Lazy 애노테이션이 분은 Bean 은 필요할 떄까지 지연 생성된다.

• 기본적으로 Bean 생성 후 Spring Container 에서 관리되며, 필요할 때마다 Container 에서 Bean 을 반환한다.

4. 의존성 주입(Dependency Injection)

• 필드 주입, 생성자 주입, 세터 주입을 통해 의존성을 주입할 수 있다.

5. 콜백 호출

• 생성 콜백 :@PostConstruct

• 소멸 콜백 :@PreDestroy

1-2. DI 를 구현하는 방법 중 필드 주입, 생성자 주입, 세터 주입의 차이점과 장단점을 설명해주세요.

1. 필드 주입(Field injection)

@Component
public class MyService {
    @Autowired
    private Dependency dependency;

    public void performService() {
        dependency.performTask();
    }
}

• 장점

  • 코드가 간결하고, 의존성을 주입할 떄 setter 나 생성자 메서드를 작성할 필요가 없어서 편리하다.

• 단점

  • 테스트 어려움 :

    • 필드는 private 로 선언되므로, 의존성을 Mock 객체로 교체하기 어려움

    • 리플렉션을 사용해야 Mocking 가능 (리팰랙션 공부 필요)

  • 불변성 보장 어려움 :

    • 의존성이 final 로 선언될 수 없어서 불변 객체를 만들기 어렵다.

2. 생성자 주입

@Component
public class MyService {
    private final Dependency dependency;

    @Autowired
    public MyService(Dependency dependency) {
        this.dependency = dependency;
    }

    public void performService() {
        dependency.performTask();
    }
}

• 장점

  • 의존성 강제:

    • 의존성이 없으면 객체 생성 자체가 불가능하므로 필수 의존성을 강제할 수 있음.

  • 불변성 보장:

    • 의존성을 final로 선언 가능하여 객체의 상태를 변경하지 않도록 보장.

  • 테스트 용이성:

    • 생성자를 통해 Mock 객체를 쉽게 주입할 수 있음.

  • 가독성 및 명시성:

    • 의존성을 명확하게 드러내어 코드의 가독성과 유지보수성을 향상.

• 단점

  • 코드가 길어질 수 있음:

    • 의존성이 많아질 경우 생성자가 길어지고 가독성이 떨어질 수 있음.

    • 때문에 Lombok 과 같은 라이브러리 사용을 통해, 최적화.

3. 세터 주입

@Component
public class MyService {
    private Dependency dependency;

    @Autowired
    public void setDependency(Dependency dependency) {
        this.dependency = dependency;
    }

    public void performService() {
        dependency.performTask();
    }
}

• 장점

  • 선택적 의존성:

    • 의존성이 필수가 아닐 경우 사용하기 적합.

    • Bean을 생성한 후 나중에 의존성을 주입할 수 있음.

  • 유연성:

    • 런타임에 의존성을 변경할 필요가 있을 때 유리.

• 단점

  • 의존성 누락 가능성:

    • 의존성을 주입하지 않아도 객체가 생성되므로 런타임 에러로 이어질 가능성이 있음.

  • 객체 상태 변경 가능성:

    • 의존성이 나중에 변경될 수 있어 불변성을 보장하지 못함.

    • 외부에 public setter 를 제공하면, 누군가 꼭 사용해 문제를 일으킨다.

1-3. 스프링의 ApplicationContext, BeanFactory 의 차이점은 무엇인가요?

• ApplicationContext와 BeanFactory는 스프링 프레임워크의 두 가지 주요 IoC 컨테이너로, 각각 Bean 관리와 의존성 주입을 담당합니다. 둘은 공통적인 역할도 있지만, 기능과 사용 목적에서 중요한 차이점이 있습니다.

• 일반적으로 @Autowired 를 사용하면 ApplicationContext 를 기본적으로 사용한다.

• BeanFactory 는 직접 인스턴스를 생성해 사용해야 한다.

차이점

1. 초기화 시점

   1. BeanFactory:

      • Lazy Initialization 방식으로 동작합니다. 즉, 요청이 있을 때 Bean을 초기화하고 생성합니다.

      • 초기화가 느리지만, 메모리 사용이 효율적입니다.

      • Bean 생성 비용이 높은 환경에서 유리합니다.

   2. ApplicationContext:

      • Eager Initialization 방식으로 동작합니다. 컨테이너 초기화 시점에 모든 Singleton Bean을 미리 생성합니다.

      • 초기화가 빠르고 런타임 성능이 향상되지만, 메모리 사용량이 상대적으로 많아질 수 있습니다.

2. 기능 확장성

   1. BeanFactory:

      • DI와 Bean 생명주기 관리 같은 기본 IoC 기능만 제공합니다.

      • 국제화, 이벤트 처리, AOP, 환경 프로파일 등의 고급 기능은 제공하지 않습니다.

   2. ApplicationContext(BeanFactory의 모든 기능을 포함하면서, 추가적인 고급 기능을 제공합니다):

      1. 국제화 지원: 다국어 메시지를 처리할 수 있는 MessageSource를 제공합니다.

      2. 이벤트 처리: ApplicationEventPublisher를 통해 이벤트를 발행하고, 리스너를 처리합니다.

      3. AOP 지원: BeanPostProcessor 및 관련 컴포넌트를 자동 등록하여 AOP를 쉽게 설정할 수 있습니다.

      4. 환경 설정: Environment 객체를 통해 프로파일과 속성을 관리합니다.

3. 사용사례

   • BeanFactory:

     • 메모리가 제한적인 환경(예: IoT 디바이스)에서 경량 애플리케이션을 구축할 때 사용됩니다.

     • 하지만 스프링 3.0 이후로 ApplicationContext 사용이 더 일반적이며, BeanFactory는 거의 사용되지 않습니다.

   • ApplicationContext:

     • 대규모 애플리케이션에서 표준으로 사용됩니다.

     • 대부분의 스프링 프로젝트에서 권장됩니다.

1-4. 스프링에서 의존성 주입을 통해 순환 참조를 방지하는 방법은 무엇인가요?

답변

• 순환 참조는 설계 개선으로 해결하는 것이 가장 바람직합니다.

  • 직접 참조를 하는 방향이 아닌, 중간의 계층 (예를 들어, 서비스 레이어) 을 추가해 의존성 방향을 양방향이 아닌 단방향으로 유지해야 한다.

  • 이렇게 되면 객체가 직접 참조하는 구조가 개선된다.

  • 협력 관계는 중간 계층에서 관리한다.

• 필요 시 @Lazy나 ObjectProvider를 사용하여 순환 의존성을 완화할 수 있습니다.

• 스프링 5.3 이후로는 기본적으로 생성자 주입에서 순환 참조가 금지되므로, 순환 참조가 발생하지 않도록 설계에 신경 써야 합니다.

2. POJO 와 스프링 프레임워크의 관계를 설명해주세요.

스프링 이전, EJB 의 문제

• 스프링이 등장하기 이전에 자바 애플리케이션 개발 시장을 독점하고 있었다.

• EJB 에는 치명적인 단점이 있었는데, 바로 코드들이 EJB 기술에 지나치게 종속되어야 한다는 점이다.

• 아래 코드는 EJB 기반으로 작성된 것으로, 특정 서비스 계층에 EJB 라는 기술이 마구 침투하는 모습을 확인할 수 있다. (import 선언문, implements, 인스턴스 변수 등.. )

• 이 문제를 해결하기 위해 스프링이 등장했다.

import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;

public class OrdersService implements SessionBean {

    private SessionContext ctx;

    public Orders placeOrder(String menuName) {
        Orders orders = new Orders(menuName);
        orders.init()
        return orders;
    }

    @Override
    public void setSessionContext(SessionContext ctx) throws EJBException {
        this.ctx = ctx;
    }

    @Override
    public void ejbRemove() throws EJBException {

    }

    @Override
    public void ejbActivate() throws EJBException {

    }

    @Override
    public void ejbPassivate() throws EJBException {

    }
}

스프링 프레임워크의 목표 : 비침투적인 해결책

• 스프링은 기술적인 복잡함을 애플리케이션 핵심 로직에서 제거하는데 목표를 뒀다.

  • 비침투적인 지술은 기술의 적용 사실이 코드에 반영되지 않는다는 특징이 있다.

  • 어딘가에서는 기술의 적용에 따라 필요한 작업을 해줘야 하겠지만, 애플리케이션 코드 여기저기에 불쑥 등장하거나, 코드의 설계와 구현 방식을 제한하지는 않는다.

• 스프링을 이용하면 기술적인 복잡함과 비즈니스 로직을 다루는 코드를 깔끔하게 분리할 수 있다.

• 그리고 이런 문제를 해결하는데 스프링이 공통적으로 사용하는 도구가 객체지향이다.

  • 기술적인 복잡함을 효과적으로 다루게 해주는 기법은 모두 DI 를 바탕으로 한다.

  • 서비스 추상화, 템플릿/콜백, AOP 와 같은 스프링의 기술은 DI 없이 존재할 수 없다.

POJO 프로그래밍과 스프링 프레임워크

• "스프링의 정수는 엔터프라이즈 서비스 기능을 POJO 에 제공하는 것" 이라고 한다.

• 엔터프라이즈 서비스라고 하는 것은 보안, 트랜잭션과 같은 엔터프라이즈 시스템에서 요구되는 기술들을 말한다.

  • 이런 기술을 POJO 에 제공한다는 말은 엔터프라이즈 서비스 기술과 POJO 애플리케이션 로직을 담은 코드를 분리했다는 뜻이다.

  • "분리되었지만 반드시 필요한 엔터프라이즈 서비스 기술을 POJO 방식으로 개발된 애플리케이션 핵심 로직을 담은 코드에 제공한다" 는 것은 스프링의 가장 강력한 특징과 목표이다.

2-1. POJO를 사용하는 것이 테스트 코드 작성에 어떤 이점을 제공하나요?

장점1. 프레임워크 종속성 제거

• POJO 는 특정 프레임워크나 라이브러리에 의존하지 않으므로, 테스트 코드에서도 해당 프레임워크를 설정하거나 초기화할 필요가 없다.

• 이는 테스트 작성과 실행을 가볍게 만들어준다.

// POJO를 사용하는 경우
User user = new User("John", 30);
assertEquals("John", user.getName());
assertEquals(30, user.getAge());

// 프레임워크에 종속된 경우 (Spring Context 필요)
ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
UserService userService = context.getBean(UserService.class);
User user = userService.createUser("John", 30);
assertEquals("John", user.getName());

장점2. 단위 테스트 작성 용이

• POJO 는 복잡한 의존성 없이 순수하게 동작하기 때문에, 단위 테스트를 작성하기 쉽다.

• Mocking 없이 독립적으로 테스트가 가능하다.

@Test
void testUser() {
    User user = new User("Alice", 25);
    user.setAge(26);
    
    assertEquals("Alice", user.getName());
    assertEquals(26, user.getAge());
}

장점3. Mocking 이 간단

• POJO 는 외부 의존성을 가지지 않으므로, Mocking 프레임워크(예 : Mockito) 와 쉽게 통합할 수 있다.

• 외부 시스템과의 상호작용 없이 테스트를 수행할 수 있다.

@Test
void testUserService() {
    // Mock Repository
    UserRepository userRepository = Mockito.mock(UserRepository.class);
    Mockito.when(userRepository.findById(1L))
           .thenReturn(Optional.of(new User("Bob", 28)));
    
    // Service Layer Test
    UserService userService = new UserService(userRepository);
    User user = userService.findUserById(1L);
    
    assertEquals("Bob", user.getName());
    assertEquals(28, user.getAge());
}

2-2. 스프링에서 POJO를 활용한 AOP(Aspect-Oriented Programming) 구현 방법을 설명해주세요.

2-3. POJO를 기반으로 한 스프링의 트랜잭션 관리 방식은 무엇인가요?

2-4. POJO와 JPA 엔티티의 차이점은 무엇인가요?

2-5. POJO를 활용한 스프링의 REST API 설계 원칙을 설명해주세요.

3. DDD 에서 도메인 계층과 애플리케이션 계층의 차이점은 무엇인가요?

3-1. 도메인 계층에서 비즈니스 로직을 구현할 때의 장점과 단점을 설명해주세요.

3-2. 애플리케이션 계층에서 도메인 계층을 호출하는 방식의 설계 원칙은 무엇인가요?

3-3. 도메인 계층에서 발생하는 이벤트를 애플리케이션 계층에서 처리하는 방법은 무엇인가요?

3-4. 도메인 계층과 인프라스트럭처 계층 간의 의존성을 최소화하는 방법은 무엇인가요?

3-5. DDD에서 애그리게이트(Aggregate)의 역할과 설계 원칙을 설명해주세요.

4. 스프링 MVC 패턴에서 컨트롤러와 서비스 계층의 역할을 구분하여 설명해주세요.

4-1. 컨트롤러에서 비즈니스 로직을 처리하지 않는 이유는 무엇인가요?

4-2. 서비스 계층에서 트랜잭션 관리를 구현하는 방법은 무엇인가요?

4-3. 컨트롤러에서 요청 데이터를 검증하는 방법과 서비스 계층에서 검증하는 방법의 차이점은 무엇인가요?

4-4. 서비스 계층에서 발생하는 예외를 컨트롤러에서 처리하는 방법은 무엇인가요?

4-5. 컨트롤러와 서비스 계층 간의 의존성을 줄이기 위한 설계 방법은 무엇인가요?

5. 테스트 코드 작성 시 통합 테스트와 단위 테스트의 차이점은 무엇인가요?

5-1. 통합 테스트에서 목 객체(Mock Object)를 사용하는 이유는 무엇인가요?

5-2. 단위 테스트에서 의존성을 최소화하기 위한 방법은 무엇인가요?

5-3. 통합 테스트에서 데이터베이스 상태를 초기화하는 방법은 무엇인가요?

5-4. 단위 테스트와 통합 테스트의 실행 속도 차이를 줄이기 위한 방법은 무엇인가요?

5-5. 테스트 코드 작성 시 TDD(Test-Driven Development)의 장점과 단점을 설명해주세요.