[TIL | 2024-09-02] 라이브러리, 프레임워크, 제어의 역전, 스프링 기본 개념 및 특징, 스프링 개발 환경 세팅해보기

서론

구름톤 백엔드 과정을 시작한지 이제 3주차이다. 이전까지는 자바의 기본적인 문법부터 시작하여 객체지향 프로그래밍 까지 여러 내용을 다루었고 이제 본격적으로 스프링에 대해서 진도를 나가는거 같다. 다른분들은 어떻게 느낄지 모르겠지만 난 수업시간이 2시간으로 제한되어있어 강사님이 제한된 시간내에 많은것을 다루다 보니 깊이 있게 학습하지 못하는것 같아 아쉽다 라는 생각이 들었다. 지금까지는 쉬운 내용이라 따라갈 수 있었지만 갈 수록 어려운 내용을 학습할텐데 잘 따라갈 수 있을지 모르겠다.

 

여튼 오늘은 스프링에 대해 공부를 하였고 스프링 프레임워크를 공부하기 이전에 라이브러리와 프레임워크의 개념과 차이점을 공부하면 좋을거 같아 정리해보았고 스프링의 개념에 대해서 조금 더 찾아가며 나만의 언어로 정리해보았다.

본론

 

프레임워크

---

프레임워크는 소프트웨어 개발을 위한 구조와 기능을 제공해주는 도구나 환경을 말한다. 프레임워크를 사용하면 개발자는 소프트웨어나 애플리케이션을 빠르게 만들 수 있고 효율적으로 개발할 수 있도록 도와주는 역할을 한다.

 

예를 들어, 아트박스나, 다이소에 DIY 키트가 있을것이다. 이 DIY 키트를 프레임워크라고 비유할 수 있다. DIY 키트는 특정한 결과물을 만들기 위하여 필요한 재료와 도구를 미리 제공해주며 단계별로 설명서나 가이드도 포함되어 있다. 또한 키트에는 이미 기본적인 구조나 틀이 마련되어 있기 때문에 사용자가 쉽게 결과물을 만들 수 있도록 도와준다.

 

이와 비슷하게, 프레임워크는 소프트웨어 개발을 위한 기본적인 구성 요소와 지침을 제공하며 이미 기본적인 구조와 틀이 마련되어있다. 때문에 사용자는 이 구조에 맞춰 쉽고 빠르게 개발할 수 있게된다.

 

 

 

라이브러리

---

라이브러리는 특정한 기능을 수행하기 위해 미리 작성된 코드의 모음이다. 개발자는 필요에 따라 이 라이브러리를 가져와 사용할 수 있다. 라이브리는 원하는 기능만 선택적으로 활용할 수 있으므로 전체적인 구조와 틀을 강제하지 않는다.

 

DIY 키트를 예로 들었을 때, 아무런 가이드나 틀이 제공되지 않는 상황과 비슷하다. 제작자가 직접 원하는 부품을 만들거나, 이미 만들어진 부품을 가져와 조립하는 방식으로 생각할 수 있다. 라이브러리는 사용자가 처음부터 끝까지 필요한 도구와 재료를 직접 준비하고, 미리 만들어진 도구나 부품(라이브러리)을 활용하여 자신만의 완성품을 만드는 과정과 같다.

 

라이브러리를 사용하면 이미 만들어져 있는 기능을 가져와 사용할 수 있기 때문에, 개발자는 그 기능을 직접 구현할 필요가 없다. 이를 통해 개발 과정에서 시간과 노력을 절약할 수 있으며, 필요한 부분만 선택적으로 활용하여 자신의 프로젝트에 맞게 조합할 수 있다.

 

 

 

라이브러리와 프레임워크 차이점

---

라이브러리와 프레임워크의 차이점은 제어의 흐름이 누구한테 있냐에 달려있다.

DIY 키트를 예로 들었을때 프레임워크는 결과물을 만들기 위해 기본적인 구조와 틀을 제공한다고 이야기했었다.

사용자는 설명서에 적힌 방식에 따라 제공된 구조와 틀에 맞춰 결과물을 만들어야 한다. 반면, 라이브러리는 기본적인 구조와 틀을 제공하지 않고 사용자 본인이 도구와 필요한 재료를 선택하고 자신만의 방법으로 결과물을 만들어야 한다.

 

즉, DIY 키트를 이용해 결과물을 만들 때는 키트의 설명서와 구조대로 완성품을 만들어야 하므로, 제어권이 키트에 있다고 할 수 있다. 프레임워크도 마찬가지로, 개발자가 프레임워크가 제공하는 구조와 규칙에 따라 작업을 진행해야 하므로 제어권이 프레임워크에 있다고 말할 수 있다.

 

반면, DIY 키트를 사용하지 않고 사용자가 직접 완성품을 만들 경우, 필요한 도구와 재료를 스스로 준비하고 원하는 방식으로 제작한다. 따라서 사용자에게  제어권이 있다고 할 수 있다. 이와 유사하게, 라이브러리는 정해진 구조와 규칙이 없고 사용자가 직접 구조를 만들거나 필요한 라이브러리만 선택하여  결과물을 만들기 때문에 제어권이 사용자에게 있다고 말할 수 있다.

 

 

제어의 역전 (IOC)

이처럼 애플리케이션을 개발할 때, 제어의 흐름이 개발자에게 있는 것이 아니라 프레임워크나 외부 환경에 맡겨지는 것을 제어의 역전이라고 말한다. 프레임 워크가 제어의 흐름을 주도함으로써, 개발자는 필요한 부분만 구현하고 나머지는 프레임 워크가 관리하게 된다.

 

 

스프링이란?

---

스프링은 자바 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크로, 엔터프라이즈 애플리케이션 개발을 간편하게 만들어주는 도구이다.

 

자바 플랫폼

자바 플랫폼은 자바 언어을 사용하여 애플리케이션을 개발하거나 실행할 수 있는 환경을 말한다. 자바 플랫폼은 다양한 운영체제와 하드웨어에서 자바 애플리케이션이 실행될 수 있도록 지원하는 기능들을 포함하며, 자바 개발자들이 소프트웨어를 개발, 컴파일, 실행하는 데 필요한 모든 도구와 라이브러리를 제공하는 역할을 한다.

 

엔터프라이즈 애플리케이션

엔터프라이즈 애플리케이션은 대규모 조직의 복잡한 비즈니스 프로세스를 지원하기 위해 설계된 소프트웨어 애플리케이션이다.  쉽게 설명하여 큰 회사나 조직에서 사용하는 복잡한 컴퓨터 프로그램이라고 생각할 수 있을거 같다. 예를 들어, 학교에서는 선생님들이 학생들의 성적이나 출석 정보를 관리하는 시스템이 있다. 이 시스템이 더 큰 회사나 은행, 병원 같은 곳에서는 훨씬 더 복잡하고 큰 버전으로 사용된다. 이런 프로그램들은 여러 사람들이 동시에 사용할 수 있고, 중요한 정보를 안전하게 관리하며, 회사가 잘 운영되도록 도와주는 역할을 한다. 예를 들어, 직원들의 급여를 계산하거나, 상품을 주문하고 관리하는 일을 자동으로 처리해주는 시스템이 바로 이런 엔터프라이즈 애플리케이션이다.

 

즉, 스프링은 자바 언어를 사용하여 대규모 조직의 복잡한 비즈니스 프로세스를 지원하는 애플리케이션을 쉽게 개발할 수 있도록 만든 도구라고 요약할 수 있을거 같다.

 

 

스프링의 주요 특징

POJO (Plain Old Java Object)

POJO는 "Plain Old Java Object"의 약자로, 직역하면 "오래된 방식의 간단한 자바 객체"라는 뜻이다.

여기서 "오래된 방식"이라는 표현은, 특정한 규칙이나 프레임워크에 의존하지 않고, 순수한 자바 코드로 작성된 객체를 의미한다. 즉, POJO는 아주 기본적인 형태의 자바 객체로, 단순히 데이터를 저장하고 그 데이터를 다루는 메서드들만을 가지며, 프레임워크나 라이브러리에 종속되지 않는 객체를 말한다.

 

POJO를 지킬려면?

• 특정 프레임워크나 라이브러리에 의존하는가?
  • POJO 방식의 코드는 자바 언어와 꼭 필요한 표준 API 외에는 종속되지 않아야 한다. 특정 프레임워크나 라이브러리의 기능에 의존하는 경우, 해당 코드는 POJO의 범주에서 벗어날 수 있다.
• 특정 환경에 종속적이지 않은가?
  • POJO는 특정한 환경이나 설정 파일에 의존하지 않는다. 환경에 따라 동작이 달라지거나 설정파일에 따라 동작이 변경되는 경우 POJO의 범주에서 벗어난다.
• 데이터 저장 및 간단한 메서드만 포함하는가?
  • POJO는 주로 데이터를 저장하는 필드와 그 데이터를 다루는 기본적인 getter, setter 메서드만을 가진다. 복잡한 비즈니스 로직이나 특정 기능을 수행하는 메서드가 포함되지 않아야 합니다.

 

POJO 개념을 지킨 코드

예를 들어, 사람을 나타내는 Person이라는 클래스를 만든다고 해보자. 이 클래스는 사람의 이름과 나이 같은 정보를 저장하고, 그 정보를 가져오거나 바꾸는 간단한 메서드들을 가질 수 있다. 

public class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

이렇게 생긴 Person 클래스는 단순히 이름과 나이를 저장하는 간단한 객체이다. 기본적인 자바 언어만을 사용하고 있고 특정한 프레임워크나 라이브러리에 종속되는 코드가 없다. 또한 특정 환경에 종속적이지 않고 기본적인 데이터를 저장하고 접근하는 메서드만을 제공한다. 따라서 POJO의 개념을 잘지킨 순수한 자바 객체라고 설명할 수 있다.

 

 

POJO 개념을 지키지 않은 코드

public class MyServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    }

    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    }
}

이렇게 생긴 MyServlet 클래스는 다음과 같은 문제점이 존재하기 때문에 POJO의 개념을 지키지 않은 코드라고 말할 수 있다.

 

먼저, 특정한 라이브러리에 의존한다. 이 클래스는 HttpServlet 클래스를 상속받고 있는데, HttpServlet은 서블릿 API의 일부로, 웹 애플리케이션이 웹 서버와 통신할 수 있도록 도와준다. 이로 인해, MyServlet 클래스는 서블릿 API에 강하게 의존하게 되며, 특정한 웹 서버 환경에서만 동작할 수 있다.  또한 특정 환경에 종속적이다. MyServlet 클래스는 서블릿 컨테이너가 필요하며, 웹 서버 환경에서만 실행될 수 있기 때문에 POJO의 개념을 지키지 않은 코드라고 말할 수 있다.

 

스프링 프레임워크에서는?

스프링은 POJO의 특징을 잘살리는 프레임워크이라고 배웠는데. 스프링 프레임워크를 사용하다보면 JPA와 같은 ORM 기술에 의존하게되는걸 간략하게 알고 있다 그렇다면 POJO의 원칙을 지키지 않는것이 아닌가라는 생각이 들었고 여러 정보를 찾아보았다. 

특정 기술에 종속적이면 POJO가 아니라면서 스프링에서 하이버네이트 사용은 어떻게 가능한걸까요? 바로 스프링에서 정한 표준 인터페이스가 있기 때문입니다. 스프링 개발자들은 ORM이라는 기술을 사용하기 위해서 JPA라는 표준 인터페이스를 정해두었고, 여러 ORM 프레임워크들은 이 JPA라는 표준 인터페이스 아래에서 구현되어 실행됩니다. 이것이 바로 스프링이 새로운 엔터프라이즈 기술을 도입하면서도 POJO를 유지하는 방법입니다.

출처: https://dev-coco.tistory.com/82 [슬기로운 개발생활:티스토리]

 

그럼 스프링은 표준 인터페이스라는 공통 규칙을 만들었고. 여러 기술들이 이 표준 인터페이스의 규칙을 따라 구현되었기 때문에 개발자는 같은 방식으로 다양한 기술을 사용할 수 있게 되고 특정한 기술에 종속적이지 않게된다는 의미인건가?

 

나머지 주요 특징

• DI
• AOP
• IOC

나머지 주요 특징은 아직 이해가 잘되지 않아 나중에 본격적으로 스프링을 사용할때 더 알아봐야겠다.

 

스프링 개발 환경 세팅 해보기

목표 : 맥 환경에서 IntelliJ IDEA를 사용해 Maven과 Tomcat을 이용하여 "Hello World"를 출력하는 간단한 웹 애플리케이션 생성

 

1. 톰캣 설치

brew search tomcat

 

---

 

`brew install tomcat` 는 최신 버전의 톰캣을 설치한다. 그 아래 명령어는 버전을 명시하여 원하는 버전의 톰캣을 설치할 수 있다.

brew install tomcat
brew install tomcat@9

 

---



톰캣을 실행할때는 다음과 같은 명령어를 통해 실행 시킬 수 있다.

/opt/homebrew/opt/tomcat/bin/catalina run

 

2. IntelliJ에서 Maven 프로젝트 생성

 

결론

시간을 잘 사용하자.