프로그래밍 언어에서 프레임워크란 무엇일까?

- C, C , java, python, javascript... -
위에 나열된 단어들은 개발자라면 한번 쯤 접해봤을 법한 프로그래밍 언어들일 것이다. 전 세계 개발자들은 다양한 프로그래밍 언어를 활용해 코드를 작성하고, 원하는 프로그램을 만들어낸다. 하지만 그 과정은 수많은 고민의 연속이었을 것이고, 팀원 간의 수많은 대화가 오고 갔을 것이다. 즉, 모든 프로그램은 협업을 통해 만들어지는 결과물이라는 것이다. 그렇다면 개발자로서의 중요한 협업 요소는 무엇일까? 소통, 아이디어, 리더쉽 그리고 바로 프레임워크 일 것이다. 오늘은 협업에서도 중요하게 이야기되는 프레임워크 중 ‘Spring framework’에 대해 이야기 해보려 한다.

프레임워크의 사전적 의미는 ‘뼈대. 틀’ 정도로 이해할 수 있다.
즉, 소프트웨어에서의 프레임워크는 곧 ‘프로그램 개발에 대한 방법론을 제시하는 것’으로 설명 된다. 좀 더 풀어보자면 ‘소프트웨어 개발에 있어 공통으로 사용하는 개발 기능(인터페이스)’ 라는 것이다. 일종의 소프트웨어 플랫폼이라고 설명할 수 있다.
예를 들어 집을 짓는다고 생각해보자. 사용자가 집을 직접 짓기 위해 설계도를 직접 그리고, 전기공사 수도공사 등 각각의 기초 작업들을 일일이 하는 것 보다, 전문 작업인들의 도움을 받아 청사진을 받고 기초공사를 끝낸 모델하우스를 기반으로 인테리어를 하면 더욱더 쉽고 효율적으로 집을 지을 수 있을 것이다.
이처럼 개발을 할 때, 프레임워크를 도입한다면 제공하는 여러 공통 기능들을 사용해서 빠르고 효율적으로 프로그램을 구축할 수 있을 것이다.
이러한 이점 때문에 Spring, Django, Flask와 같은 웹 프레임워크가 탄생하게 되었다. 그렇다면 대한민국의 표준화된 개발 프레임워크는 뭘까? 바로 전자정부 표준 프레임워크 이다. 공공기관에서 특수한 경우가 아니라면 웹으로 요청하는 프로젝트는 주로 전자정부 표준 프레임워크를 사용할 가능성이 높다. 이러한 추세로 민간기업에서도 전자정부 표준 프레임워크를 사용하고 있다. 이 프레임워크는 스프링 프레임워크를 기반으로 동작한다. 스프링 프레임워크가 무엇인지 아래에 소개해 보려 한다.

스프링 프레임워크는 2004년 3월에 처음 세상에 알려졌다.
하지만 탄생 이전에 EJB(엔터프라이즈급 자바 어플리케이션)라는 일반적인 개발스펙이 존재해왔다. 당시 개발의 복잡도를 줄이기 위한 하나의 노력으로 발표된 스펙이였지만, 불필요한 메서드(기존 EJB컨테이너에서 제공하는 API를 상속받거나 구현함)의 생성과 특정 개발도구의 종속성 이슈는 해결해야 할 또 하나의 문제였다. 때문에 EJB의 기능을 유지하면서 단순하고 가벼운(경량급) 개발도구로 나타난 것이 바로 스프링 프레임워크였다.
참고로 스프링의 의미는 자바 언어 생태계의 긴 겨울을 끝내고 봄을 맞이한다는 것에서 탄생 하였다고 한다. 즉, EJB 를 대체하는 새로운 자바 기반 프레임워크라는 것이다.

스프링은 여전히 웹 프레임워크에서 상위권을 유지할 만큼 많은 인기를 얻고 있다.
그 이유에는 다음과 같은 스프링만의 이점이 존재하기 때문이다.
1. 단위테스팅 : EJB 시절 EJB 컨테이너 외부에서는 단위 실행이 어려워 테스트를 위해서는 반드시 컨테이너에 배포가 되어 있었야 했다. 하지만 의존성주입(DI)이 도입되고 나서는 단위테스트가 가능해 졌다. ex) junit
2. 코드의 단순화 : 스프링은 설정과 같은 소스의 복잡도를 줄이고, 단일화하여 소스의 가독성을 높여 준다. 예를 들어 트랜잭션 측면에서 spring jdbc를 지원하기 때문에 많은 줄의 DB 연동 소스를 단순화 시키는 효과를 볼 수 있다.

3. 관점지향 프로그래밍(AOP) 지원 : 스프링은 AOP를 통해 반복적인 코드를 줄이고 개발자가 핵심 비즈니스 로직에만 집중 할 수 있도록 지원한다. 예를 들어 3개의 다른 페이지에 로그인 기능이 존재하는 사이트가 있다면 이 로그인 기능은 공통 관심사로 볼 수 있을 것이며, 이를 AOP로직으로 정의하여 관리 할 수 있다. 그렇게 된다면, 로그인 로직의 변경이 일어나더라도 하나의 공통관심사(로그인)만 수정해주면 되는 일인 것이다.

 

스프링의 특징을 이야기 할 때 많은 특징들이 존재하는데 그 중 가장 많이 언급되는 것이 바로 IoC/DI 개념이다. 주요 구성 모듈을 보면 ‘Spring Core’에 포함되어 있는 모듈 중 하나이다. 스프링에서 얼마나 중요한 개념인지 알 수 있다.

 

-IoC/DI 개념
시작에 앞서 IoC(Inversion of Control)라 하면 대부분의 사람들은 스프링에서 시작된 개념으로 알고 있는 경우가 많은데, 이전 EJB 스펙에서도 IoC의 개념은 존재하고 있었다. EJB 컨테이너가 그러하다. 우선 IoC를 직역하면 "제어의 역전"이라는 뜻으로, 달리 해석하면 "제어의 주체가 바뀌었다"라는 의미이고, 스프링의 입장에서 얘기하자면, 메소드나 객체의 호출이 개발자가 아닌 외부(컨테이너)에서 결정되는 것이다. 예를들어 서블릿과 같은 서버사이드에서 동작하는 모듈은 배포가 끝나고 나면 제어권한을 가질 수 없게 된다. 때문에 컨테이너가 적절한 시점에 서블릿을 제어하고, 메서드를 호출하게 되는 것이다. 스프링에서도 마찬가지로 IoC 컨테이너가 존재하며, 방금 이야기했듯이 컨테이너 스스로가 적절한 시점에 객체의 생명주기를 제어할 수 있게 된다.

 

그렇다면 이어서 DI의 역할을 이야기해보자
IoC가 객체의 생명주기를 정한다면, DI(Dependency Injection)는 ‘의존성주입’ 즉, 컨테이너로부터 생성된 객체를 주입시켜 주는 역할을 한다.

 

기존의 객체 생성이 new 키워드로 생성됐었다면, DI에서는 외부에서 생성된 객체를 원하는 시점에 주입시켜 준다는 개념으로 이해하면 될 것이다.

 

그렇다면 IoC/DI의 이점은 무엇일까
1. 클래스들간의 의존 관계를 최소화 할 수 있다.
2. 프로젝트 유지보수가 용이하다.
3. 개발자의 의한 객체처리를 IoC컨테이너로 위임함으로서 비즈니스 로직에 집중 할 수 있다.

다시말해 아래 코드는 A가 B,C에 의존하고 있다고 볼 수 있다. 왜냐하면 B와C의 내용이 변경 되면 A객체는 직접적인 영향을 받게 된다.

 

이것을 결합도라 하는데, 좋은 프로그램일수록 결합도는 낮게 설계 되어야 한다.
지금까지 우리는 결합도를 낮추는데 인터페이스라는 추상화 개념을 활용해 왔다.

DI의 조건을 보면 “클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다. 그러기 위해서는 인터페이스만 의존하고 있어야 한다.” 즉, DI 또한 인터페이스를 기반으로 종속성을 낮추는 기능을 하고 있는 것이다.

이처럼 다양한 측면에서 프레임워크의 활용은 개발자들 간의 소스 일관성 및 개발 속도(모듈기반)에도 긍정적인 영향을 미치는 아주 중요한 도구임에 분명해 보인다.

*마치며
스프링은 매우 광범위한 이론과 개념이 집약된 프레임워크이다. 우리는 이 모든 특징과 기술들을 이해하고, 사용하기에는 벅찰 수 있다. 하지만 프로젝트의 기반이라 할 수 있는 스프링에 대한 이해와 꾸준한 관심은 우리 개발자들에게는 반드시 필요한 행동일 것이다.
우리가 스프링을 이해하고 있는 깊이에 따라 프로젝트의 퀄리티는 정해져 있다 해도 과언이 아닐 것이다.