Spring 키워드

Spring Framework

자바 개발을 편리하게 해주는 오픈소스 프레임워크로 경량 컨테이너로서 자바 객체를 직접 관리할 수 있으며 제어의 역전 기술을 통해 어플리케이션의 느슨한 결합을 도모합니다. 또한 의존성 주입과 관점 지향 프로그래밍을 지원합니다.

Spring 특징

POJO 방식의 프레임워크로 , 경량 컨테이너로 자바 객체를 직접 관리합니다. 또한 제어의 역전( IoC )과 의존성 주입 ( DI ) , 관점 지향 프로그래밍 ( AOP ) 를 지원하며 , 영속성과 관련된 다양한 서비스를 지원합니다. 또한 스프링은 확장성이 높습니다.

Spring , Spring Boot 차이

가장 큰 차이는 Auto Configuration의 차이로 , Spring은 프로젝트 초기에 다양한 환경설정을 해야 하지만 Spring Boot는 설정의 많은 부분을 자동화하여 개발자가 개발에만 집중할 수 있게 돕습니다. 또한 내장된 톰캣이 있어 jar파일로 간단하게 배포할 수 있습니다.

Spring MVC 패턴

MVC는 모델 , 뷰 , 컨트롤러의 약자이며 모델은 데이터 관리 및 비즈니스 로직을 처리하는 부분이며 , 뷰는 비즈니스 로직의 처리 결과를 유저 인터페이스로 표현하는 부분입니다. 컨트롤러는 사용자의 요청을 처리하고 Model과 View를 중개하는 역할을 합니다.

MVC 흐름

먼저 클라이언트의 요청이 들어오면, 디스패처 서블릿은 핸들러 매핑을 통해 어떤 컨트롤러의 요청인지 찾습니다. 그 다음 핸들러 어댑터에게 요청을 전달하고 핸들러 어댑터는 해당 컨트롤러에 요청을 전달합니다. 컨트롤러는 비즈니스 로직을 처리한 후에 뷰의 이름을 반환하며, 디스패처 서블릿은 뷰 리졸버를 통해 반환할 뷰를 찾고 렌더링하여 반환합니다.

디스패처 서블릿

HTTP 프로토콜로 들어오는 요청을 가장 먼저 받아서 적합한 컨트롤러에게 전달해주는 프론트 컨트롤러입니다. 디스패처 서블릿을 사용하면 공통작업을 코드 중복없이 처리할 수 있습니다.

IoC , Inversion of Control

제어의 역전은 모든 객체에 대한 제어권을 개발자가 아닌 IoC 컨테이너에게 넘기는 것을 말합니다. 스프링에서 IoC 컨테이너에 객체들을 생성하면 객체끼리 의존성을 주입하는 역할을 하고 컨테이너에 등록한 객체들을 빈 이라고 합니다.

IoC Container ( Spring Container )

프레임워크 안에서 객체의 생성과 관계설정과 생명주기를 관리하며, 생성된 인스턴스들에게 추가적인 기능을 부여합니다. 인스턴스 생성부터 소멸까지 인스턴스 생명주기 관리를 개발자가 아닌 컨테이너가 대신 해주며, 객체관리 주체가 프레임워크가 되기 때문에 개발자는 로직에 집줄 할 수 있습니다.

IoC 종류

Bean Factory

DI의 기본사항을 제공하는 컨테이너로 Bean을 생성하고 분해하는 작업을 하며, 처음 getBean()이 호출된 시점에 빈을 생성합니다.

ApplicationContext

BeanFactory와 유사하지만 더 많은 기능을 가지고 있으며, 싱글톤 패턴을 기반으로 미리 빈을 생성해 놓아 빈이 필요할 때 즉시 사용할 수 있게 보장합니다.

IoC의 분류

DL ( Dependency Lookup )

저장소에 저장되어 있는 Bean에 접근하기 위해 컨테이너가 제공하는 API를 이용해 Bean을 Lockup 하는것을 말합니다.

DI ( Dependency Injection )

각 클래스간의 의존관계를 빈 설정 정보를 바탕으로 컨테이너가 자동으로 연결해 주며, setter , 생성자 , 필트 주입을 할 수 있습니다. DL 사용시 컨테이너 종속이 증가하기 때문에 주로 DI 를 씁니다.

Servlet

자바를 기반으로 하는 동적인 웹페이지를 만들어주는 프로그래밍 기술입니다. 서블릿을 통해 클라이언트의 요청과 응답의 흐름을 메서드 호출만으로 체계적으로 다룰 수 있으며 , 요청을 처리한 후에 결과를 반환합니다.

Spring filter , interceptor의 차이

필터는 J2EE(자바 기술) 표준 스펙 기능으로 디스패처 서블릿에 요청이 전달되기 전/후에 url 패턴에 맞는 모든 요청에 대해 부가작업을 처리하는 기능입니다.
인터셉터는 스프링이 제공하는 기술로, 디스패처 서블릿이 컨트롤러를 호출하기 전과 후에 요청과 응답을 참조해 가공할 수 있는 기능을 제공합니다.
둘다 Controller가 호출되기 전에 실행되지만 , 필터는 웹 컨테이너가 관리하며 보안 , 로깅 , 문자열 인코딩 등 쓰이며 , 인터셉터는 스프링 컨테이너가 관리하며 인증/인가 , API호출에 대한 로깅 , Controller로 넘겨주는 정보를 가공할 때 사용합니다.

Spring Security

스프링 기반으로 애플리케이션의 보안을 담당하는 스프링 하위 프레임워크입니다. 해당 사용자가 본인이 맞는지 확인하는 인증과 , 인증된 사용자가 요청한 자원에 접근 가능한지 결정하는 인가를 담당하는 프레임워크를 말합니다.

Annotation

코드 사이에 주석처럼 쓰이며 , 특별한 의미, 기능을 수행하는 기술로 프로그램에게 추가적인 정보를 제공해주는 메타데이터를 말합니다.

@Controller , @RestController 차이

@Controller는 View를 반환하기 위해 사용되며 , 뷰리졸버를 통해 View를 찾아 렌더링합니다. 데이터를 반환하고 싶으면 @ResponseBody 어노테이션을 활용해 Json 형태로 데이터를 반환할 수 있습니다. @RestController는 2개의 어노테이션을 합친 것으로, json 형태로 객체 데이터를 반환합니다.

@SpringBootApplication

스프링 부트로 프로젝트를 실행할때 Application 클래스에 쓰는 어노테이션입니다. @ComponentScan을 통해 프로젝트 내부에 @Component 와 @Bean을 읽어 자동으로 등록합니다. 단 해당 어노테이션을 선언한 클래스를 기준으로 탐색을 하기 때문에 항상 프로젝트의 최상단에 위치해야합니다.

@Service , @Controller , @Repository

세 개의 특수주석은 응용 프로그램에서 레이어를 분리하는 데 사용합니다. @Controller는 디스패치 , 전달 , 서비스 메서드 호출을 하고 , @Service는 비즈니스 로직 , 계산등을 하며 , @Repository는 DAO로 데이터베이스에 직접 엑세스합니다.
@Component를 사용하여 구성 요소 클래스를 표시 할 수 있지만, 해당 특수 주석을 사용하여 예상되는 기능에 더 적합하도록하고 높은 연관성을 가질 수 있습니다.

@Transactional 동작 원리

메서드 또는 클래스에 명시하면, AOP를 통해 Target이 상속하고 있는 인터페이스나 Target 객체를 상속한 Proxy 객체가 생성되며, Proxy 객체의 메서드를 호출하면 Target 메서드 전 후로 트랜잭션 처리를 수행합니다.

Spring Bean

자바에서의 POJO로 , XML 설정파일을 통한 생명주기, 종속성 등의 메타데이터를 가지고 스프링 컨테이너에서 생성된 객체로, 컨테이너에서 생성되었다는 점을 제외하면 일반 객체와 같습니다.

Bean 등록 방법

xml 설정파일을 이용해 Bean을 등록하거나, 어노테이션을 통해 Bean을 등록하는 방법이 있습니다. 다만 어노테이션으로 Bean을 등록할 때 Component Scan이 필요한데 SpringBoot 같은 경우에는 자동으로 구성해줍니다.

Bean Scope

빈이 존재할 수 있는 범위를 말하며 , 스프링은 기본적으로 모든 bean을 싱글톤으로 생성하여 관리합니다. 생성된 bean은 single beans cache에 저장되고 해당 bean에 대한 요청과 참조가 있으면 캐시된 객체를 반환합니다. 프로토타입 빈은 모든 요청에서 새로운 객체를 생성하는 것을 말하며, bean이 주입될 때 새로운 객체를 생성하여 주입합니다.

Bean 주입 방법

먼저 @Autowired 에노테이션을 통해 주입할 수 있습니다. 만약 같은 타입의 빈이 존재한다면 @Primary 애노테이션으로 우선순위를 설정할 수 있고, @Qulifier 에너테이션으로 Bean 을 선택해서 주입할 수 있습니다. 이 외에 생성자를 통해 주입할 수 있고, setter를 통해 주입할 수 있습니다.

Bean 생명 주기

먼저 스프링 컨테이너를 생성 후 어노테이션이나 xml을 통해 스프링 빈을 생성합니다. 그 다음 의존성을 주입하고 초기화 콜백 메소드를 호출한 뒤 사용합니다. 스프링컨테이너가 종료되면 소멸 전 콜백을 실행 후 종료합니다. 스프링은 크게 3가지 방법으로 빈 생명주기의 콜백을 관리하는데 우선 인터페이스와 설정 정보에 초기화 메소드, 종료 메소드를 지정하거나, @PostConstruct 와 @PreDestroy를 사용합니다.

MVC1 , MVC2

MVC1은 클라이언트의 요청을 jsp 페이지가 받아서 처리합니다. 즉 jsp가 컨트롤러와 뷰의 역할을 했습니다. jsp 페이지 내에 비즈니스 처리를 위한 코드와 브라우저에게 결과를 보여주기 위한 출력 코드가 섞여있습니다.
MVC2에서는 클라이언트의 요청을 서블릿이 받습니다. 서블릿이 해당 요청에 알맞게 처리한 후 그 결과를 jsp에 전달합니다. 즉 서블릿이 컨트롤러 역할 , jsp가 뷰역할을 담당하여 명료한 구조를 갖게됩니다.

Spring 의존성 주입 ( DI )

필요한 객체를 직접 주입하는게 아닌 외부로 객체를 받아 사용하는 것으로 객체간의 결합도를 줄이고 코드의 재사용성을 높일 수 있습니다. Spring에서는 생성자 , 필드 , 세터를 이용해 의존성 주입을 할 수 있는데 Spring에서는 생성자를 통한 주입을 가장 권장하고 있습니다. 그 이유는 순환 참조를 방지하고 불변성을 가지며 테스트에 용이하기 때문입니다.

AOP , Aspect Oriented Programming

관점 지향 프로그래밍은 핵심 비즈니스 로직에 있는 공통 관심사항을 분리하여 모듈화 하는 것을 의미하며 공통 모듈인 인증 , 로깅 , 트랜잭션 처리에 용이합니다. 핵심 비즈니스 로직에 부가기능을 하는 모듈이 중복되어 분포되어 있을 경우 사용할 수 있으며 , 중복 코드 제거, 재활용성의 극대화, 변화수용에 용이합니다.

프록시

타겟을 감싸서 타겟의 요청을 대신 받아주는 랩핑 오브젝트이며, 업무를 대신하여 처리하는 대리인입니다. 함수 호출자는 주요 업무가 아닌 보조 업무를 프록시에게 맡기고 , 프록시는 내부적으로 이러한 보조 업무를 처리합니다.

VO , BO , DAO , DTO

DAO는 DB의 데이터에 접근하기 위한 객체를 말합니다. ( Mapper )
BO는 여러 DAO를 활용해 비즈니스 로직을 처리하는 객체입니다. ( Service )
DTO는 각 계층간의 데이터 교환을 위한 객체입니다. ( Controller -> Service )
VO는 실제 데이터를 저장하는 객체입니다. 비즈니스 값을 가져올 때 사용하며, 값을 수정할 수 없습니다.

DTO 사용 이유

순환 참조를 예방할 수 있으며 , JPA로 개발할 때 양방향 참조를 사용했다면 주의해야 합니다. 또한 엔티티 내부 구현을 캡슐화 할 수 있으며, DB 와 View 사이의 역할을 분리합니다.

POJO

Pojo는 프레임워크 인터페이스로, 클래스를 구현하거나 확장하지 않은 단순한 클래스로 Java에서 제공하는 API 외에 종속되지 않습니다. 특정 환경에 종속되지 않아 코드가 간결하고 테스트 자동화에 유리합니다.

Gradle vs Maven

Gradle과 Maven은 빌드 툴로 라이브러리의 Dependency를 관리합니다. XML 기반의 Maven 빌드 설정보다 Gradle의 빌드 설정이 가독성이 더 좋으며, 빌드 성능이 Gradle이 더 뛰어납니다. 또한 Groovy 기반의 DSL 로 Gradle의 빌드 스크립트를 직접 작성할 수 있습니다.

WAS 과 WS 차이

WAS는 비즈니스 로직을 넣을 수 있고 대표적으로 Tomcat , PHP , ASP 가 있습니다. 반대로 WS 는 비즈니스 로직을 넣을 수 없으며 Nginx , Apache 등이 있습니다.

@RequestBody , @RequestParam , @ModelAttribute

@RequestBody는 클라이언트가 전송한 JSON 형태의 Http Body 내용을 MessageConverter를 통해 Java Object로 변환시켜 주는 역할을 하며, Reflection을 이용해 할당하기 때문에 생성자와 Getter Setter가 없어도 됩니다.
@RequestParam은 1개의 HTTP 요청 파라미터를 받기 위해 사용되며, 초기 필수 여부가 true 값이기 때문에, 기본적으로 해당 파라미터를 전송해야 하며 전송되지 않으면 400 에러를 유발할 수 있습니다.
@ModelAttribute는 Http Body 내용과 Http 파라미터의 값들을 생성자와 Getter Setter 를 통해 주입합니다. 값 변환이 아닌 값을 주입하므로 생성자와 , Getter Setter 가 없다면 저장되지 않습니다.

대용량 트래픽에서 장애 발생 시 대응 방법

Scale-Up을 통해 하드웨어 스펙을 향상시키거나 , Scale-Out을 통해 서버를 여러대 추가해 시스템을 증가시키는 방법이 있습니다.