감 1도 없는 개발자

감 1도 없는 개발자

여행을 꿈꾸는 개발자

인터뷰 질문 대비

Updated:

인터뷰

1. 스프링 프레임워크란

  • 자바 EE 개발을 편하게 해주는 경량급 오픈소스 애플리케이션 프레임워크
  • 목표 : POJO 기반의 Enterprise 애플리케이션 개발을 쉽고 편하게 할 수 있도록 한다.
  • 자바 어플리케이션을 개발하는데 필요한 하부구조를 포괄적으로 제공한다.
  • 스프링이 하부구조를 처리하기 때문에 개발자는 애플리케이션 개발에 집중할 수 있다.

2. 특징

2.1 POJO (Plain Old Java Object)

  • 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 재활용될 수 있게 설계된 오브젝트
  • 즉, 프레임워크 인터페이스나 클래스를 구현하거나 확장하지 않는 단순한 클래스
2.1.1 EJB (엔터프라이즈 자바빈)
  • 기업 업무 처리가 IT 시스템에 대한 의존도가 높아지면서 시스템이 다뤄야 하는 비즈니스 로직 자체가 복잡해지고, 많은 사용자의 처리요구를 빠르게 안정적이며 확장 가능한 형태로 유지하기위해 필요한 로우 레벨의 기술적인 처리가 요구 됐다. (트랜잭션 처리, 리소스 풀, 멀티 쓰레딩 등)
  • EJB의 목표는 개발자가 애플리케이션 개발을 쉽게 만들주기 위해 로우레벨에 관심을 가질 필요가 없도록 도와주는 것이었다.
  • 그러나 결과적으로는 과도한 엔지니어링으로 실패했다.
  • 왜냐하면 EJB 스펙을 따르는 비즈니스 오브젝트들은 객체지향적인 특징과 장점을 잃었기 때문이다.
    • 상속이나 다형성 등의 특징이 사라짐
  • 그래서 객체 지향 원리에 따라 만들어진 자바 언어의 기본에 충실하게 비즈니스 로직을 구현하는 POJO 방식으로 돌아서야 한다.

2.2 IOC (Inversion of Control : 제어의 역전)

  • POJO의 생성과 생명주기 관리까지 모든 객체에 대한 제어권이 바뀐 것을 의미
  • 또는 제어 권한을 자신이 아닌 다른 대상에게 위임하는 것이다.
  • 개발자는 프레임워크에 필요한 부품을 개발하고 조립하는 방식의 개발을 하게 된다.
  • 이렇게 조립된 코드의 최종 호출은 개발자가 제어하지 않고 프레임워크 내부에서 정해진대로 이뤄진다.

2.3 DI (의존성 주입)

2.3.1 의존성이란
  • 현재 객체가 다른 객체와 상호작용(참조)하고 있다면 다른 객체들을 현재 객체의 의존이라 한다.
2.3.2 의존성이 위험한 이유
  • 하나의 모듈이 바뀌면 다른 모듈까지 변경되야 한다.
  • 유닛테스트 목적은 다른 모듈로부터 독립적으로 테스트하는 것인데 DI는 이를 어렵게 한다.
  • 자바 클래스가 new 연산자를 통해 다른 클래스의 인스턴스를 생성하면 해당 클래스와 독립적으로 테스트하고 사용할 수 없으며 이를 하드 종속성이라고 한다.
  • Mock 객체로 대체 가능
2.3.3 의존성 주입이란 (필요한 이유)

  • 클래스(객체) 간의 의존 관계를 빈 설정 정보를 바탕으로 컨테이너가 자동적으로 연결해주는 일

  • new 를 사용해 모듈 내에서 다른 모듈을 초기화하지 않으려면 객체 생성은 다른 곳에서 하고, 생성된 객체를 참조하면 된다.
  • DI는 IOC 개념을 바탕으로 한다. 클래스가 외부로부터 의존성을 가져야한다.
  • 클래스는 다른 클래스를 인스턴스화해야 하지만, 구성 클래스에서 인스턴스를 가져와야 한다.
2.3.4 DI가 필요한 이유
  • 클래스를 재사용을 높이고 결합도가 낮아져 객체 지향적임
  • 다른 클래스와 독립적으로 클래스를 테스트 할 수 있다.
2.3.5 DI 세가지 방법
  • 생성자 삽입
  • 메서드 매개 변수 삽입
  • 맴버 변수 삽입

2.4 AOP

  • 애플리케이션 전체에 걸쳐 사용되는 기능을 재사용하도록 지원하는 것

  • 예를 들어 로그, 권한체크, 인증, 예외 처리 등이 핵심은 아니지만 중요한 것들이 생겨남.
  • 이들을 하나의 클래스로 만들어 놓아도 핵심 기능에서 매번 객체를 생성하고 메서드를 호출했어야 함.
  • AOP는 이를 여러 코드에 쉽게 적용할 수 있게 관점이라는 개념을 통해서 해결

3. Spring boot

  • spring boot는 spring의 구성을 간편하게 설정할 수 있는 서브 프로젝트

  • 독립 컨테이너에서 동작할 수 있기 때문에 embeded tomcat이 자동으로 실행됩니다.

  • embeded container에서 어플리케이션을 실행시키기에는 다소 불안전하기 때문에 큰 프로젝트에서는 사용하지 않는 것이 좋다.

4. 컨테이너

  • 보통 인스턴스의 생명주기를 관리하며 생성된 인스턴스들에게 추가적인 기능을 제공하는 역할
  • 스프링 프레임워크는 다른 프레임워크들과 달리 컨테이너 기능을 제공한다.
  • 컨테이너 기능을 제공하는 것이 가능한 이유는 IOC 패턴이다.

5. MVC란?

  • MVC 패턴은 사용자 인터페이스와 응용 프로그램 개발에 소요되는 시간을 줄여주는 설계 방식
  • 모델
    • 핵심 비즈니스 로직. 데이터베이스 관리
  • 뷰
    • 사용자에게 보여주는 화면
  • 컨트롤러
    • 모델과 뷰 사이에서 정보 교환을 할 수 있게 연결

6. MVC 프레임워크 작동방식

  • 디스패처 서블릿이 클라이언트에게 요청을 받으면 핸들러 맵핑에게 어느 핸들러에게 요청할지 물어봄
  • 핸들러맵핑은 요청 URL을 보고 핸들러 이름을 디스패처 서블릿에게 알려준다.
  • 이때 핸들러를 실행하기 전/후 처리할 것들을 인터셉터로 만들어 준다.
  • 디스패처 서블릿은 해당 핸들러에게 제어권을 넘겨준다.
  • 핸들러는 요청에 필요한 서비스를 호출하고 랜더링해야 하는 뷰 이름을 판단하여 디스패처 서블릿에게 전송
  • 디스패처 서블릿은 받은 뷰 이름을 뷰 리졸버에게 전달해 응답에 필요한 뷰를 요청
  • 해당 뷰는 디스패처 서블릿에 받은 모델과 컨트롤러를 활용해 원하는 응답을 생성해 보냄
  • 디스패처 서블릿은 뷰로 받은 것을 다시 클라이언트에게 응답
  1. DispatcherServlet : 어플리케이션으로 들어오는 모든 Request를 받는 관문이다. Request를 실제로 처리할 Controller 에게 전달하고 그 결과값을 받아서 View에게 전달하여 적절한 응답등 생성할 수 있도록 흐름을 제어한다.
  2. HandlerMapping : Request URL 각각을 어떤 Controller 가 실제로 처리할 것인지 찾아주는 역할을 한다.
  3. Controller : Request를 직접 처리한 후 그 결과를 다시 DispatcherServlet 에게 돌려준다.
  4. ModelAndView : Controller가 처리한 결과와 그 결과를 보여줄 View에 관한 정보를 담고 있는 객체이다.
  5. ViewResolver : View 관련 정보를 갖고 실제 View를 찾아주는 역할을 한다.
  6. View : Controller가 처리한 결과값을 보여줄 View를 생성한다.

7. MVC1과 MVC2의 차이

  • 1은 JSP 페이지 안에서 로직 처리를 위해 자바 코드가 사용. 직접 자바빈이나 클래스를 이용해 처리. 그러다보니 유지 보수가 어려움
  • 2는 서블릿을 만들어 서블릿이 로칙 처리마다 역할에 맞는 비즈니스 로직(컨트롤러)에 분배. 뷰만 JSP가 담당. 유지보수가 쉬워지나 구조가 복잡하고 설계가 어려움

8. 필터와 인터셉터의 차이

  • Filter와 Interceptor는 실행되는 시점이 다르다.
  • Filter는 Dispatcher servlet의 앞단에서 정보를 처리
  • Interceptor는 Dispatcher servlet에서 Handler(Controller)로 가기 전에 정보를 처리한다.

9. 서블릿과 JSP 비교

  • 서블릿은 자바 언어로 웹 개발을 하기 위해 만들어진 것. 컨테이너가 이해할 수 있도록 순수 자바 코드로 이루어짐
  • JSP는 html 기반에 자바 코드를 블록화하여 삽입한 것으로 서블릿을 좀 더 쉽게 접근할 수 있도록 만들어짐

10. 프레임워크 vs 라이브러리

  • 둘 다 재사용 목적, 남이 작성한 코드는 같다.
  • IOC 개념이 적용되었나의 차이
  • 라이브러리
    • 라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다.
    • 단지 동작하는중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다.
  • 프레임워크
    • 애플리케이션 코드가 프레임워크에 의해 사용된다.
    • 보통 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식

118. JDBC

  • 자바 언어를 통해 데이터 베이스에 접근 할 수 있는 프로그래밍

12. context

  • context
    • 필요한 정보를 포함하고 있는 설정 파일
  • 어플리케이션 context
    • 스프링에서 만든 인터페이스
    • 애플리케이션에 필요한 context

  • root 웹 어플리케이션 context

    • 서비스, 레포지토리스, DB 연결, 로깅
    • 주로 뷰 자원을 구성

  • 서블릿 웹 어플리케이션 context (= 웹 어플리케이션 context)

    • Web Application 최상단에 위치하고 있는 Context

    • root 컨텍스트를 상속 받음
    • 디스패처 서블릿이 직접 사용하는 컨트롤러, 뷰리졸버, 핸들러 맵핑 설정
    • root 서블릿과 공통된 것이 있다면 서블릿 컨텍스트 빈이 우선

13. web.xml

  • 서블릿 설정.
  • 필터 활용(ex: 한글)
  • 에러코드
  • 시작파일 지정

You may also enjoy