Spring Framework

프레임워크?

 

프레임워크란 특정한 목적에 맞게 프로그래밍을 하기 위한 약속이다.

 

요리를 예시로 들면, 어느 요리던 비록 사람에 따라 다르게 조리되겠지만 반드시 필요한 재료는 존재한다.

예를 들어 김치찌개에는 김치와 돼지고기 정도는 반드시 필요하다.

프레임워크는 이렇게 특정한 목적에 맞는 어플리케이션을 개발하기 위해, 필수적인 것들을 모아놓은 것이다.

 

 

프레임워크와 라이브러리

 

내가 직접 면접에서 받은 질문은 아니고, 잡플래닛의 면접 후기 중에서 해당 질문이 나왔었다는 글이 기억났다.

 

앞서 설명했듯, 프레임워크는 말 그대로 특정한 목적에 맞는 어플리케이션을 개발하기 위해 필수적인 것들을 모아놓은, 일종의 틀 혹은 뼈대이다.

 

그에 반해 라이브러리는 단순히 활용 가능한 도구들의 집합으로 볼 수 있다.

 

쉬운 설명을 위해 프레임워크를 종종 퍼즐에 비유한다.

프레임워크는 이미 특정한 어플리케이션을 개발하기 위해 퍼즐판을 준비해놓고, 개발자는 자신이 개발하려는 프로그램의 요구사항에 맞춰 퍼즐 조각들을 맞춰가며 퍼즐을 맞춰나간다.

 

그리고 여기서 사용되는 퍼즐 조각은, 개발자가 직접 구현하여 사용할 수도 있지만, 이미 구현되어 제공되는 경우는 그럴 필요가 없다. 그리고 여기서 이미 구현된 퍼즐 조각이 바로 라이브러리이다.

 

---

 

스프링 프레임워크?

 

포괄적인 인프라를 제공하는 오픈 소스의 자바 플랫폼이다.

 

웹에서 많이 사용되기는 하지만, 그렇다고 반드시 웹에서만 사용되는 것이 아니라, 범용적으로 자바 어플리케이션을 개발할 수 있도록 지원한다.

 

 

 

스프링 프레임워크의 특징?

 

1) 경량 컨테이너

평범한 프로그램은 개발자가 코드를 통해 자바 객체의 생성과 소멸을 관리하게 된다.

하지만 스프링은 객체를 담고 있는 컨테이너로써, 자바 객체의 생성과 소멸 같은 라이프 사이클을 관리한다. 그리고 언제든 필요한 객체를 가져와 사용할 수 있도록 지원한다.

 

 

2) POJO(Plain Old Java Object)

단순한 자바 오브젝트이다.

 

이전에는 비즈니스 로직에 대해서만 직접 구현을 하고, 그 외의 Low-level의 기능들은 EJB(Enterprise JavaBeans)를 사용해서 구현했다. EJB는 개발자로 하여금 비즈니스 로직에만 집중할 수 있도록 간편한 구현을 도와주었으나, 여러 문제가 있었다.

 

대표적인 문제는 과도한 상속이 발생하여 의존성이 매우 높아 테스트가 불편하고 복잡성이 너무 높아졌다는 점이다.

 

이러한 단점을 극복하기 위해 스프링은 POJO를 채택했다. 복잡한 EJB 대신 기본적인 클래스를 사용하는 것이다.

 

그냥 별로 특별한 개념은 아니고, 자바를 처음 배울 때 만드는, 많은 인터페이스가 상속되어 있지 않은 간단한 클래스들이다.

 

이러한 POJO 방식은 객체간 의존성을 낮추게 되어 모듈화와 재사용이 용이해고, 테스트가 쉬워지게 된다.

 

POJO 방식은 사전정의된 클래스나 인터페이스의 상속을 최대한 지양하며, 사전정의된 annotations를 가지는 것도 지양한다.

 

 

3) DI(Dependency Injection, 의존성 주입)

기존의 어플리케이션을 소스 코드의 수정 없이 업데이트 하기 위해 의존성을 최대한 작게 줘야 했다.

 

만약 클래스 A가 변수로 클래스 B를 가지고 있으며 B의 함수들을 사용하게 된다면 이는 의존 관계가 된다.

 

DI는 이러한 의존성을 없애기 위해 특정한 타입을 가져오는 것이 아니라, 범용적인 인터페이스를 사용함으로써 변수의 타입을 개방시키고, 또한 내부에서 선언하는 것이 아니라, 외부에서 선언한 클래스를 set 함수로 가져온다.

 

아래처럼 바꾸는 것인데, 이렇게 하면 B가 아닌 F를 상속받는 클래스라면 무엇이든 들어올 수 있도록 범용성을 갖기 때문에 의존성이 많이 낮아진다.

하지만 위와 같은 방법은 마찬가지로 코드를 수정해야만 한다. 스프링에서는 이렇게 사용하지 않고, 대신 XML을 활용하여 수정을 한다.

XML을 활용한 DI : 예시를 위해 Spring이 아닌 일반 자바에서 만들어서 조금 이상할 수 있음.

 

4) IoC (Inversion of Control, 제어 역행)

서블릿이나 빈 등을 개발자가 코드에서 생성하지 않고 프레임워크가 직접 수행하는 방법이다.

사실 대부분의 프레임워크에서 사용하는 방법이다.

 

프레임워크를 사용하지 않을 때, 개발자는 명시적으로 각 클래스가 다른 클래스를 생성하고 호출하는 부분을 전부 코드로 구현해야 했고, 이렇게 객체의 생명주기는 전부 코드 내에서 관리되었다.

 

하지만 스프링 같은 컨테이너는 그렇지 않다. 애초에 객체의 생명주기를 코드가 아닌 프레임워크 자체에서 관리하기 때문에, 이러한 객체의 생성과 소멸을 xml 내에서 관리하게 된다. 이 개념 자체가 IoC이다.

 

언틋 보면 DI와 설명이 겹친다고 느낄 수 있는데, 당연하다. DI가 IoC의 한 종류라고 볼 수 있으니까. 그래서 구글에 IoC를 검색하면 IoC는 잘 안알려주고 DI만 알려준다.

 

 

5) AOP(Aspect-oriented programming, 관점 지향 프로그래밍)

어느 프로그램 종류나 공통적으로 구현해야 하는 기능들은 존재한다.

웹을 예로 들자면, 로깅과 보안, 알림 같은 것들이 있다.

 

하지만 로깅과 보안을 모든 기능에 일일히 코드로 넣어주게 되면, 비즈니스 로직의 기능보다 공통 기능을 보다 많이 사용하게 되는 경우가 발생할 수 있다.

 

AOP는 이러한 문제를 해결하기 위해 중복하여 사용하는 기능들을 별도로 분리하여 활용하는 기술이다.

 

AOP는 메소드 안의 주기능과 보조기능을 분리한다. 그리고 이를 선택적으로 메서드에 적용해서 사용한다.

 

마찬가지로 공통 기능들을 분리하여 클래스로 만든 후, xml을 활용하여 빈을 생성하고 코드 내에서는 그 빈을 사용하여 호출하는 형식이다.