기술면접 스터디 - 2일차 (DI, Index)

목차

• 1. DI(Dependency Injection)에 대한 설명과 해당 기술의 장점에 대해서 설명해주세요.
• 2. DB에서 인덱스를 잘 사용하면 어떤 장점이 있을까요?

---

1. DI(Dependency Injection, DI)에 대한 설명과 해당 기술의 장점에 대해서 설명해주세요.

DI(Dependency Injection, DI)란?

DI는 (dependency injection)의 약어로 의존관계 주입 또는 의존성 주입이라고 불립니다. 객체를 직접 생성하는 방식이 아닌 외부에서 생성 후 주입 시키는 방식을 말하는데, 스프링에서는 Bean 정보를 바탕으로 의존관계를 컨테이너가 자동으로 연결해주는 것입니다.  여기서 말하는 의존은 한 클래스의 변경이 다른 클래스에 영향을 미친다면, 이 관계는 의존 관계가 있다를 의미합니다.

이 DI를 활용하는 방법은 3가지가 있습니다.

• 생성자를 이용한 주입 방식
  • 필요한 의존성을 포함하는 생성자를 만들고, 만든 생성자를 이용해 의존성을 주입하는 방식입니다.
• Setter를 이용한 주입 방식
  • 의존성을 주입받은 setter 메서드를 만들고, 이 메서드들을 호출해서 의존성을 주입하는 방식입니다.
• Interface를 이용한 주입 방식
  • 의존성을 주입 메서드를 포함하는 인터페이스를 만들고, 이를 가지고 와서 구현하도록 함으로써 실행시에 이를 이용해 의존성을 주입하는 방식인데, setter 방식과 마찬가지로 외부에서 이 메서드를 호출해야합니다. 하지만 setter와 다르게 interface를 이용하면 override를 강제로 할 수 있다는 점이 있습니다. 

이렇게 DI를 사용하면 어떤 장점이 있나요?

1. 코드의 분리를 통해 다른곳에서도 재사용이 가능하기에, 재사용성이 높아집니다.
2. 코드간 의존성의 분리로 인해 의존성이 높을 때, 변경하게 되는 발생 비용보다 비용을 감소할 수 있으며, 주입받는 대상이 변하더라도 구현 자체를 수정할 일이 없거나 줄어드는 장점이 있습니다. ( 의존성이 줄어듭니다. )
3. 각 기능들을 별도로 분리하게되면 자연스레 가독성이 높아집니다.

 

스프링에서는 DI를 이렇게 해결합니다!

스프링 내부에서는 Bean을 이용해 의존관계를 컨테이너가 자동으로 연결시켜주는데요, 스프링에서는 이를 @Autowired라는 어노테이션을 이용해서 해결합니다. 이 어노테이션이 붙게되면 bean의 관리 대상이 되어서 스프링이 의존성을 주입해줍니다. (이때 주입받아야 할 대상도, 주입해주는 대상도 bean의 관리 대상이어야 합니다.)

 

이 @Autowired를 통해 의존성을 주입받는 방법은 3가지가 있습니다.

• 필드 주입
  • 주입받고자 하는 필드위에 @Autowired 어노테이션만 기입하면 된다. 하지만 인텔리제이 내부에서 이 방식을 추천하지 않는데, 그 이유는 의존성이 강하게 프레임워크에 전속되는 문제점이 있습니다.
• Setter 주입
  • setter 메서드에 @Authwired 어노테이션을 사용하면 되는데, 이 때 빈 생성자 또는 정적 팩토리 메서드가 필요합니다. final 필드를 만들 수 없고, 불변성을 유지할 수 없는 단점이 있습니다. 그래서 선택적 의존성에 사용해야 합니다. 이유는 생성자 주입된 컴포넌트들은 완전히 초기화 된 상태로 클라이언트에 반환되기 때문입니다. 
• 생성자 주입
  • 객체의 최초 생성 시점에 스프링에서 의존성을 만들어 주는데, 스프링에서 추천하는 방식입니다. 

 

과거에 따로 정리한 글이 있어 새로 정리하지는 않겠습니다.

• 참고 자료 : https://jipang9-greedy-pot.tistory.com/117

Day.32 JDBC -> JPA까지 확장 -> 그 속에서 DI, IoC

• 참고 자료 2 : https://youtu.be/8lp_nHicYd4

---

2. DB에서 인덱스를 잘 사용하면 어떤 장점이 있을까요?

 

인덱스는 테이블에 관한 동작의 속도를 높여주는 자료구조입니다. 여기서 동작의 속도라고 하면 검색 속도를 의미합니다.  테이블의 특정 컬럼에 인덱스를 생성하면, 컬럼의 값과 물리적 주소 값을 한 쌍으로 저장하게 되고, 해당 컬럼의 데이터를 정렬 후 별도의 메모리 공간에 저장하게 됩니다. 

여기서 중요한 점은 정렬된 데이터의 저장입니다. 일반적으로 데이터가 저장될 때, 정렬이 된 상태로 저장되지 않으며, 우리가 특정 조건의 데이터를 찾을 때 테이블 전체를 조건과 비교해서 찾는 Full Table Scan의 작업이 필요합니다. 그러나 인덱스에서는 데이터가 정렬된 상태이기에 빠르게 수행할 수 있다는 점 입니다. 그래서 인덱스는 값의 범위가 넓은 데이터나, 조회가 잦거나, 정렬된 상태에서 이점을 얻을 수 있는 테이블에 사용하면 빠른 속도로 데이터를 검색할 수 있습니다.

 

그러나 인덱스를 잘못 사용하는 경우엔 오히려 검색 속도의 저하를 야기할 수 있으며, 추가적인 저장 공간이 필요합니다. 또 인덱스를 관리하기 위해서 추가적인 작업이 필요한데,  인덱스로 만들었는데 수정이나 삭제 업데이트가 잦은 테이블이면 DB에서는 인덱스를 제거하는 것이 아닌 사용하지 않음으로 처리해버리기에 실제 데이터에 비해 인덱스가 계속 커지고, 메모리 공간에 사용하지 않는 인덱스가 저장될 것입니다. 그래서 공간의 낭비가 발생하게 됩니다. 

---

• 참고 레퍼런스 : https://mangkyu.tistory.com/96

[Database] 인덱스(index)란?