2024-05-07 [Kotlin+Spring 입문 Spring 보다 자세하게 이해하고 공부하자]

Spring 개념을 뜯어보자

Spring은 JAVA / Kotlin 기반의 개발을 편하게 할 수 있게 해주는 오픈소스 경량급 Application Framework 입니다.

해당 정의만 보면 이해가 잘 가지 않아, 뜯어보며 정의를 조금 더 깊숙하게 이해해보려 합니다.

 

"JAVA / Kotlin 기반의 개발을 편하게 할 수 있게 해주는"

기업에서 운영하는 웹 서비스에는 비즈니스 로직이라는 것이 있습니다. 비즈니스 로직이란 기업이 제공하는 서비스를 코드로 구현한 것으로, 사용자의 요구사항을 해결하기 위한 실질적인 코드들을 의미합니다.

스프링이 등장하기 이전에는 비즈니스 로직을 구현하기 위해 기술 자체에 대한 공부를 추가적으로 해야만 했습니다. 비즈니스 로직을 구현하는 기술 자체가 복잡하고 어려웠기 때문입니다.

그러나, 스프링은 이전 기술에 비해 사용 방법이 상대적으로 덜 복잡합니다. 따라서, 개발 초기에 기본적인 설정과 적용시킬 기술들만 잘 선택을 해준다면, 기술보다는 애플리케이션의 로직 자체에 더 집중하여 비즈니스 로직을 구현할 수 있습니다.

 

"오픈소스"

스프링은 모든 사용자에게 무료로 열려 있습니다. 즉, 어떤 개인 및 기업도 스프링을 사용하여 웹 애플리케이션을 개발을 할 수 있으며, 필요하다면 스프링의 코드를 일부 수정하여 사용하여도 무관합니다. 이처럼 오픈소스로 프로젝트를 공개해 놓으면 여러 사람이 프로젝트의 코드를 사용해봄으로써 다양한 검증 과정을 거칠 수 있다는 장점이 있습니다.

하지만, 뚜렷하게 정해진 인원이 프로젝트의 개발과 관리를 맡는 것이 아니기 때문에, 프로젝트의 개발과 개선이 안정적이지 못하다는 단점 또한 가질 수밖에 없습니다. 기업에서 사용하는 프레임워크는 반드시 안정적이어야 합니다. 프레임워크의 불안정성은 서비스 제공의 불안정성으로 이어지고, 결국 기업의 수익 감소로 이어질 수 있기 때문입니다.

그러나, 스프링은 오픈소스 프레임워크이지만, 안정적인 개발과 개선이 보장됩니다. 현재 스프링은 오픈소스로 배포되어 누구나 이용할 수 있지만, 스프링소스(SpringSource)라는 IT기업에서 관리하고 있으며 스프링의 소스 코드를 수정하거나 개선하는 일에는 스프링소스의 한정적인 인원만 참여할 수 있어 안정적인 개발과 개선이 보장될 수 있습니다.

 

"경량급"

스프링은 수십개의 세부 모듈 및 수십만줄의 방대한 코드로 이루어진 프레임워크입니다. 그러면 어떻게 스프링을 정의할 때 경량급이라는 수식어를 사용할 수 있는 것일까요?

스프링을 정의함에 있어 경량급이라 함은 기존에 스프링 대신 사용하던 기술들과 비교하여, 스프링을 사용했을 때에 개발자가 작성해야 할 코드가 상대적으로 단순하다는 것을 표현하기 위함입니다.

스프링이 등장하기 이전에는 EJB(Enterprise Java Bean)라는 기술이 주로 사용되었습니다. EJB 또한 EJB 이전에 사용되던 기술의 단점을 보완하여 이전 기술을 대체하기 위해 등장했지만, 그럼에도 여전히 불필요하게 복잡한 코드를 작성해야만 했습니다. 이에 따라, 개발자들이 불필요한 코드들을 어떻게 걷어낼지, 어떻게 코드의 복잡성을 줄일 수 있을지 고민했고, 그 결과 탄생한 것이 스프링입니다.

 

"Application Framework"

Application Framework가 무엇인지 이해하기 위해서는 Framework 에 대해서 알아야 합니다.

여러분이 자동차를 만든다고 가정해봅시다. 이 때 처음부터 끝까지 자동차의 모든 것을 손수 만드는 것보다는, 자동차 회사에서 자동차의 차체를 사와서 차체에 각 부품을 만들어 붙이는 것이 훨씬 더 편리할 것입니다.

즉, 자동차 회사에서는 미리 자동차의 차체를 만들어뒀고, 여러분은 그것을 가져다가 사용하기만 하면 되는 것입니다. 여기에서 자동차의 차체에 해당되는 것이 바로 프레임워크입니다. 웹 개발에 있어 프레임워크란, 어떠한 목적을 쉽게 달성할 수 있도록 해당 목적과 관련된 코드의 뼈대를 미리 만들어둔 것을 의미합니다.

그렇다면 애플리케이션 프레임워크는 무슨 의미일까요? 일반적으로 프레임워크는 특정 업무 분야 혹은 하나의 기술에 집중합니다. 즉, 어떠한 특화된 목적을 편리하게 달성할 수 있게 하기 위해 만들어집니다. 반면, 애플리케이션 프레임워크는 특정 업무 분야 및 특정 기술이 아니라, 애플리케이션 개발에 필요한 모든 과정에 집중합니다. 다시 말해, 애플리케이션 프레임워크는 애플리케이션을 개발하는 데에 있어 필요한 모든 업무 분야 및 모든 기술과 관련된 코드들의 뼈대를 제공합니다.

 

개념을 뜯어 보았으니 다시 한번 내용을 짚어보자면,

Spring Framework는 최신 Java 기반 엔터프라이즈 애플리케이션을 위한 프로그래밍 및 구성 모델을 제공합니다. Spring의 핵심 요소는 애플리케이션 레벨의 인프라 지원입니다. Spring은 개발자가 (비즈니스 로직을 구현하기 위한 기술들이 아닌)비즈니스 로직에 집중할 수 있도록 엔터프라이즈 애플리케이션의 Plumbing(직역하자면 '배관'으로, 해당 개념은 아래에서 추가 설명)에 중점을 둡니다.

 

Library VS Framework

Framework

개발자가 소프트웨어를 개발함에 있어 코드를 구현하는 개발 시간을 줄이고,  코드의 재사용성을  증가 시키기 위해 일련의 클래스 묶음이나 뼈대, 틀을 라이브러리 형태로 제공되는 것을 말합니다 (위의 자동차 회사 예시를 떠올리면서 이해하면 쉽습니다.)

프레임워크는 다음과 같은 특징이 있습니다.

• 개발자가 따라야 하는 가이드를 제공합니다.
• 개발할 수 있는 범위가 정해져 있습니다.
• 개발자를 위한 다양한 도구 , 플로그인들을 지원합니다.

Library

Application 개발시 활용가능한 도구(코드)의 집합을 의미하는데, 그러면 "Framework 와 같은 것 아니야?" 라고 생각할 수 있습니다.

 

Framework / Library 비교

라이브러리와 프레임워크의 차이는 제어 흐름에 대한 주도성이 누구에게 / 어디에게 있는가에 있습니다. 즉 애플리케이션의 Flow(흐름)을 누가 쥐고 있느냐에 달려있습니다.

 

• 프레임워크는 그 스스로 제어 흐름의 주도성을 갖는 반면 라이브러리는 개발자가 가지고 있습니다.
• 프레임워크는 집이고, 라이브러리는 그 집 안의 가구로 생각하면 쉽습니다.
• 라이브러리와 달리 프레임워크는 이미 프로그래밍에 대한 규칙을 가지고 있습니다. 예를 들면 설정 파일의 태그설정이나, DB연동 방법등에 대한 규칙을 가지고 있고 개발자는 이를 주도성을 가지고 있는 프레임워크의 규칙을 따라야합니다.

 

강의에서 caller, callee의 차이로 설명한 내용을 추가하자면

• 애플리케이션을 기준으로 'Application을 호출하는지', '호출을 당하는지' 여부로 구분을 할 수 있습니다. 즉 Caller 와 Callee의 차이라고 말할 수 있습니다.
• Framework는 Application을 호출하는 Caller 역할을하고, Library는 반대로 Application이 호출을 하는 Callee의 역할을 한다고 할 수 있습니다.
• 결국, Framework은 우리가 Application 관련 코드를 작성하면 이를 알아서 호출해주는 역할을 하고, Library는 우리가 Application 코드를 작성할 때 활용하는 도구라고 보시면 됩니다.

(** 해당 차이점을 잘 설명한 비유가 있어 하단에 내용을 추가합니다!)

프레임워크

집을 짓기 위한 과정을 라이브러리와 프레임워크에 비유해보면, 프레임워크는 모델하우스를 짓는것에 비유할 수 있습니다. 모델하우스의 소파의 위치, 의자와 책상의 위치, 방의 용도 등. 우리가 수정할 수 있는 범위는 제한적이며,

주방의 위치, 기둥의 개수, 방의 개수 등 집을 이루고있는 굵직한 뼈대는 수정할 수 없습니다.

사용자는 모델하우스가 제공하는 청사진 안에서"만" 움직일 수 있다. 프레임워크가 제공하는 틀에 따라 코드를 작성해야 하는것이다. 즉, 통제권은 사용자가 아닌 프레임워크가 쥐고 있습니다.

 

라이브러리

하지만 라이브러리는 이케아에서 산 재료로 가구를 조립하는것에 비유할 수 있습니다. 집에서 사용할 가구를 조립하거나 만들기 위해 벌목부터 시작해서 목공을 하거나, 가죽을 얻기위해 사냥을 하고싶은 사람은 거의 없을 것입니다.

그래서 이케아 혹은 가구점에 가서 기본적인 재료를 사서 입맛대로 조립하고 배치할 수 있습니다. 재료의 선택권이나 통제권은 개발자에게 있습니다.

 

웹 생태계의 변화, 생태계의 변화에 따른 Spring 용도의 변화

개요 : 1960년 인터넷이 등장한지 30년 후인 1990년, 웹의 개념이 처음으로 등장했습니다. 이때 이후로 웹은 많은 변화를 거쳤는데요, 아래 그림들을 통해 웹 생태계가 어떻게 변화해 갔는지 살펴보고, 이에 따른 Spring 의 용도 변화를 학습해보려 합니다.

 

[1세대]

서버를 통해 완성된 HTML / CSS를 로드하였습니다. 페이지별 완성된 화면을 서버에서 불러오기 때문에, 페이지 이동 시 마다 화면이 깜빡였습니다. (깜빡인다는 것은 페이지 이동 시 마다 재부팅이 되었다는 것을 의미합니다.)

쉽게 설명해 Client가 Web Server에 컨텐츠를 요청하면 Web Server에서는 정적 컨텐츠만 제공할 수 있었습니다.

 

 

[2세대]

동적인 웹사이트를 구현하기 위해 Ajax 라는 동적인 웹 페이지를 만들기 위한 개발 기법이 등장하였습니다. 이를 통해 이동 시 마다 페이지를 받아오지 않고, 서버에서 받아온 HTML위에 필요한 데이터만을 서버에 재요청하여 변경하는 것이 가능해졌습니다.

(이전 Ajax 개념을 정리한 글이 있어, 하단에 블로그링크를 첨부합니다. 참고하여 확인 시 이해하는데 도움이 될 것 같습니다!)

2024.04.04 - [스파르타 코딩클럽/CS 개념 정리] - 2024-04-04 [AJAX]

2024-04-04 [AJAX]

 

 

[3세대]

React, Angular, Vue 등의 라이브러리 및 프레임워크가 등장하면서 HTML, CSS 자체를 Javascript를 통해 동적으로 생성하는 SPA(Single Page Application)이 주를 이루게 되었습니다.

이때부터 Frontend와 Backend의 역할 구분이 명확해졌고, Frontend Server와 Backend Server 또한 차츰 나뉘어 가게 되었습니다. 이렇게 브라우저에서 Javascript를 읽어 페이지를 렌더링(생성)하는 방식을 CSR(Client Side Rendering) 이라 부릅니다.

 

[4세대]

3세대의 CSR(Client Side Rendering) 방식과는 반대로 HTML 내용을 모두 채워서 Client에 전송해 주는 방식을 SSR (Server Side Rendering)이라 하는데요, CSR과 SSR은 모두 장단점이 있습니다.

CSR은 Javscript를 통해 페이지를 불러와야 하기에 첫 페이지의 로딩 시간이 느리고, 반대로 SSR은 빠른 대신, 변경사항 혹은 나머지 페이지를 불러오는 시간은 SSR은 처음부터 HTML을 다시 만들어 줘야하기 때문에 느립니다.

결정적으로 CSR의 경우 동적으로 HTML의 내용을 채워주기 때문에 SEO(Search Engine Optimization)에 취약합니다. 최근 이러한 CSR과 SSR의 장점을 모두 사용할 수 있는 형태의 Framework 들이 등장했고, 대표적인 Framework로 Next.js 가 있습니다.



그림을 순서대로 살펴보면,

1. 클라이언트(브라우저)가 Frontend server에 요청을 보냅니다.

2. 아래 선택지 중 선택

• SEO가 필요 없는 경우 Backend Server에서 데이터를 미리 가져오지 않습니다.
• SEO 가 필요할 경우 Frontend Server 는 필요한 데이터를 Backend Server 에서 미리 가져옵니다.

3. Frontend Server에서 클라이언트(브라우저)에게 HTML / CSS / JS를 전송합니다.

 

그래서 Spring의 용도가 어떻게 바뀌었을까요?

정답은 위 1-4세대의 Server, Backend Server에 연결된 화살표를 보시면 됩니다.

이전에는 HTML / CSS와 같은 리소스를 응답해주는 역할도 하였지만 현재에는 Data를 주로 응답해주는 역할을 합니다. (여기서 Data는 여러 형태가 될 수 있지만, 현재에는 대부분 JSON 포맷을 사용합니다.)

 

JSON은 Key, Value 형태로 이루어진 포맷이라 할 수 있으며 Key는 문자열(String), Value로는 수(Number), 문자열(String), 참/거짓(Boolean), 배열 (Array), 객체 (Object), null 값이 올 수 있습니다.

 

결론적으로, 현재의 Spring은 Client, Frontend Server의 요청에 따라 적절한 JSON Data를 응답해주는 역할을 주로 수행한다고 볼 수 있습니다.