[기술 면접] 1. Spring을 쓰는 이유가 뭐에요?

Spring Framework는 한국에서 광범위하게 사용되며, 신입 개발자들 사이에서도 매우 인기가 많습니다. 그러나 많은 사람이 Spring을 선택하는 이유에 대해 심층적으로 생각해보지 않으며, 면접에서 이에 관한 질문에 제대로 대답하지 못하는 경우가 종종 있습니다. 이는 면접관의 관점에서 면접자가 사용하는 도구에 대한 충분한 이해가 없이 사용한다고 생각될 수 있습니다. 따라서 이 글에서는 Spring을 사용하는 이유를 짚어보고, 그 중요성에 대해 알아보고자 합니다.

Table of Contents

Q: Spring을 쓰는 이유가 뭐에요?

Spring은 자바 언어 기반의 프레임워크로 객체지향의 핵심인 다형성을 극대화합니다. DI와 DI 컨테이너를 제공하여, 다형성과 OCP, DIP를 가능하도록 지원합니다.

마치 부품을 교체하듯이, 클라이언트 코드의 변경 없이 기능을 확장할 수 있습니다.

Q: DI란 무엇인가요?

Dependency Injection(의존성 주입, 의존 관계)으로 의존 관계 주입 기능입니다. 객체를 직접 생성하는 게 아니라, 외부에서 생성한 후 주입 시켜주는 방식으로, 모듈 간의 결합도가 낮아지고 유연성이 높아지게 합니다.

Q: DI 방법에는 무엇이 있나요?

Field Injection, 필드 주입

Setter Injection, 세터 주입, 수정자 주입

Constructor Injection

Q: DI, 제어 역전을 위해 스프링에서 제공하는 것은 무엇인가요?

Runtime 환경에서 스프링이 instance를 생성하고, 해당 instance를 필요로 하는 Client에게 연결시켜줌으로써 각각의 저수준과 분리를 해줍니다.

Q: 스프링이 해주는 주입 말고, new로 생성하는 것은 DI가 아닐까요?

직접 인스턴스를 생성하여 연결하기 때문에 아닙니다.

Q: IoC란 무엇인가요? (== DI 컨테이너 == 스프링 컨테이너)

Inversion of Control로 제어의 역전입니다. 클라이언트 구현 객체가 스스로 서버 구현 객체를 생성/연결/실행 함으로써, 프로그램의 제어 흐름을 스스로 정의하는 것이 아니라, 외부에서 관리합니다.

Q: Spring의 DI와 DI 컨테이너 대해서 설명해보세요.

Spring은 DI 와 DI 컨테이너를 제공하여 다형성과 OCP, DIP를 가능하도록 지원합니다. 상세하게 설명하자면, 클라이언트 코드의 변경 없이 기능을 확장할 수 있으며, 마치 부품을 교체하듯이 개발할 수 있음을 의미합니다.

클린아키텍처 관점에서 말씀드리면, 클린아키텍처는 관심사를 Layer 별로 구분하고, 고수준부터 저수준으로 관리하는 아키텍처인데, 저수준이 고수준을 의존하도록 함으로써 저수준에 있는 Layer를 변경할 때 고수준에 있는 Layer에 영향을 끼치지 않도록 합니다.

MVC 관점으로 말씀드리면, 컨트롤러 Layer에서 Service Layer를 의존할 때, Controller의 변경이 Service Layer에 영향을 끼치지 않는 것입니다.

추가로, 모든 설계에 인터페이스를 부여하는 것이 권장 되지만, 도입 시 추상화라는 비용이 발생하는 것을 인지해야 합니다.

객체지향의 핵심인 다형성을 극대화
- 역할과 구현으로 구분하기 때문에 유연하고 변경이 용이합니다.
- 클라이언트에게 영향을 주지 않고 서버를 변경 할 수 있습니다. 자동차가 바뀌어도 운전자는 운전 가능
  - 클라이언트는 대상의 역할(인터페이스)만 알면 됩니다.
  - 클라이언트는 구현 대상의 내부 구조를 몰라도 됩니다.
  - 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않습니다.
  - 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않습니다.
    1. 역할 == 인터페이스
    2. 구현 == 인터페이스를 구현한 클래스, 구현 객체
- 구현에 변화가 있어도 인터페이스가 최대한 흔들리지 않도록 합니다.
- 하지만, 다형성 만으로는 OCP, DIP를 지킬 수 없습니다.

IoC컨테이너 == DI컨테이너 == 스프링 컨테이너

Q: 일반적인 객체 생성과 스프링에서의 객체 생성은 무슨 차이가 있나요?

기존 Java에서는

객체 생성
의존성 객체 생성 클래스의 내부에서 생성
의존성 객체 메서드 호출

의 순서로 실행되었지만, 스프링에서는

객체 생성
스프링에 의한 의존성 객체 주입
의존성 객체 메서드 호출

하는 방법으로 실행됩니다.

Q: MVC의 한계는 없나요?

우선, MVC 패턴은 컨트롤러의 역할과 뷰를 렌더링 하는 역할을 명확하게 구분할 수 있습니다. 뷰는 화면 출력 역할에 충실한 덕분에 코드가 직관적이고 깔끔하며, 단순하게 모델에서 필요한 데이터를 꺼내고 화면을 만든다고 할 수 있습니다. 하지만, 컨트롤러는 중복이 많고 필요하지 않은 코드들도 많습니다.

예시로, view로 이동하는 포워드가 중복됩니다. 물론 해당 부분을 메서드로 공통화해도 되지만, 해당 메서드도 항상 직접 호출해야합니다. 기능이 복잡해질 수록 컨트롤러에서 공통으로 처리해야할 부분이 더욱 증가할 것이기 때문에 FrontController가 필요하게 됩니다.

Q: FrontController가 무엇인가요?

서블릿 하나로 클라이언트 요청을 모두 받고, 요청에 맞는 컨트롤러를 찾아서 호출하는 구조입니다. 입구를 하나로 모아서 공통으로 처리하여 프론트컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됩니다.

마치며

Spring을 사용하는 이유와 특성, 그에 따르는 부가 개념들에 대해 알아봤습니다. 개념을 익히고도 직관적으로 무엇이 강점인지 느껴지지 않을 수 있다고 생각합니다. 선례로 주어진 방법들을 지향하며 개발하는 과정에서 조금씩 느껴지며 발전할 수 있는 것이 아닐까 생각합니다. Best Practice를 완벽히 구현하긴 어렵겠지만 의식하고 있다면 좀 더 가까워질 수 있을 것입니다.

다음 시간에는, Spring AOP에 대한 면접 질문들을 알아보겠습니다.

※ 위 질문에 대한 답변은 필자의 의견이며 개발자에 따라 대답이 달라질 수 있는 점 참고해주시길 바랍니다.