[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_32일차_"스프링 프레임워크"

🦁멋쟁이사자처럼 백엔드 부트캠프 13기 🦁
TIL 회고 - [32]일차

🚀32일차에는 스프링과 스프링부트에 대해 배워보고, 프레임워크/라이브러리 등의 차이점에 대해서 토론해볼 수 있었다.

회고를 통해 개인적으로 이해한 부분을 좀 더 정리해봐야겠다.

 

---

스프링 프레임워크

• 자바 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크
• 동적 웹 사이트 개발을 위한 서비스 제공

package com.example.hellospring.controller;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {
    @GetMapping("/hello")
    public String hi(){
        return "Hello Spring!";
    }
}

• HelloController 객체만 생성되었는데 @RestController가 hi()메소드의 실행을 도와준다.
  ➡️프레임워크가 기본적인 틀을 제공하여 @RestController (RestController 어노테이션)으로 인해 실행 가능
  
  
• @RestController
  ➡️ (@Controller + @ResponseBody)
  ➡️JSON형태로 “객체 데이터를 반환”
  ➡️@RestController 사용으로 Controller클래스 하위 메소드에 @ResponseBody를 붙이지 않아도
  문자열과 JSON등을 전송이 가능 
  
  
• @GetMapping
  ➡️Get 방식 메소드로 RequestMapping함 (=요청을 매핑함)
  ➡️HTTP Get Method의 단축표현으로 "서버 리소스 조회"하는 기능
  ➡️localhost:8080/hello 로 접속 (@GetMapping의 "/hello")

@GetMapping("/")
public String index(){
    return "Init 페이지 보여주기";
}

• @GetMapping으로 별도 URL을 지정하지 않으면 localhost:8080 으로 접속 가능

---

스프링부트

• Spring Boot : Spring프레임워크를 기반으로 만들어진 도구
• 스프링부트는 내부적으로 스프링프레임워크 동작 
  
  
• 등장 배경 :
  - 스프링 프레임워크의 단점인 “복잡한 초기설정” (XML 구성, Java Config 구성, 의존성 관리, 템플릿 설정) 등
  - "복잡한 초기설정"을 스프링 부트가 자동화하여 스프링 어플리케이션을 더 쉽게 개발할 수 있도록 함
  
  
• 장점 :
  - 자체적으로 웹 어플리케이션 서버를 포함 ➡️내장 서버 지원(Tomcat, Jetty, Undertow 등)
  - 복잡한 스프링 프레임워크의 설정, 구성을 단순화 (자동 구성 = Auto Configuration)
  - 의존성 관리 : Maven이나 Gradle 구성파일에서 필요한 라이브러리 선언
  
  
• 단점 :
  - 과도한 자동구성 : 어플리케이션 시작시간이 길어지거나 예상치못한 동작
  - 리소스 사용량 : 내장 서버와 자동구성 기능으로 인해 상대적으로 많은 메모리와 리소스 사용

정리하자면
스프링부트는 기존 스프링 프레임워크의 기능을유지하면서 개발자가 더욱 쉽게 접근할 수 있도록 만들어진 프레임워크
대규모 프로젝트와 마이크로서비스 아키텍처에서 많이 쓰임

---

build.gradle

• 스프링에 대한 설정 가능
  
  
• dependencies : testImplementation / testRuntimeOnly
  ➡️기본으로 생성되는 것
  ➡️기능별로 테스트하는 것을 도와줌 (=단위 테스트)
  ➡️테스트 시에만 쓰임
  
  
• dependencies : implementation spring-boot-starter-web
  ➡️스프링부트에 대한 의존성 관리

---

단위테스트

• Unit Test : 각 개발자가 개발한 기능이 제대로 동작하는지 확인하는 과정
• 스프링에서 "테스트"는 중요
  ➡️별도의 디렉토리(test)로 관리되고 있음

---

application.properties

• resources디렉토리 안에 위치한 application은 애플리케이션의 설정을 해줄 수 있음
• properties 확장명 보다 yml 방식 확장명이 많이 쓰임
  ➡️오타를 잡아주지 못하는 properties와 달리 yml은 오타를 잡아주는 장점

yaml 형태

spring:
  application:
    name: hellospring

server:
  port: 8888

• 이렇게 서버설정에서 port를 직접 설정해주면 port번호를 바꿀 수 있음 (기본값 : 8080)

---

스프링 실행 구문 수정

• resources > banner.txt 생성 후 아스키코드 등을 사용

---

WAS와 웹서버

• 웹서버 : HTTP의 기본 프로토콜은 80번 (포트번호를 생략해도 서버 접속 가능)
  - 정적 콘텐츠(HTML, CSS, JavaScript 등)을 사용자에게 전달
  - 요청을 받으면 단순히 전송하거나 다른 서버(WAS 등)로 전달
  - 즉 HTML, CSS 등 정적인 자원들 처리에 최적화
  
  
• WAS(웹 어플리케이션 서버)
  - 동적 콘텐츠를 생성하는 서버사용자 요청에 따라 비즈니스 로직 처리 및 결과 생성
  - 어플리케이션을 동작하는 서버이기때문에 웹서버보다 WAS서버의 비용이 비쌈
  - 데이터베이스와 통신하여 사용자 요청에 맞는 데이터를 가져오기도 함
  - Servlet/JSP와 같은 동적 웹 기술을 실행 (ex. Tomcat)

 

정리하자면

스프링 프레임워크에서 작동하는 서버는 내부적으로는 자바의 HTTP Servlet이 작동되고 있는 것
➡️자바는 HTTP Servlet 이라는 서버를 제공 (웹 요청을 처리함)

스프링 - HTTP Servlet 사용의 예

일반적으로

웹서버 + WAS를 결합하여 사용

• 클라이언트 → 웹서버 → WAS → 데이터베이스
• 정적 요청은 웹서버가 직접 처리하고, 동적 요청은 WAS로 전달
• 보안, 성능 및 확장성 측면에서 유리

---

API, 라이브러리, 프레임워크 비교

 

API

• 라이브러리와 비교

• API (Application Programming Interface) : 애플리케이션 간 상호작용을 위한 규칙과 인터페이스를 제공
  ➡️ex. Java의 JDBC API 
  - 제어 : 개발자가 제어함
  
  
• API와 라이브러리 (Library)는 상호보완적
• API는 인터페이스이므로 틀을 정의해놓고 이 API를 구현한 것이 라이브러리
  
  
• ex. JDBC API는 Connection 인터페이스를 정의
  ➡️JDBC API는 데이터베이스와 상호작용하는 인터페이스를 정의하고
  실제 동작은 DB벤더가 제공하는 드라이버가 수행
  
  
• 유사한 점 :
  API(기능사용을 위한 인터페이스 제공),  라이브러리 (개발자에게 제공되는 도구)
  ➡️ex. Java의 List는 인터페이스(API), ArrayList는 그 구현체(라이브러리)
  
  
• 다른 점:
  API (인터페이스 제공, 구현체는 필요하지 않을 수도 있음), 라이브러리 (실제 구현체로 바로 사용 가능한 코드)

 

---

라이브러리

• 프레임워크와 비교
  
  
• 라이브러리 : 요리 재료, 요리는 개발자가 직접
  - 제어 : 개발자가 필요할때 호출, 애플리케이션 흐름을 스스로 설계
  - 의존성 : 특정 기능만 수행하므로 다른 기술로의 전환이 쉬움
  - 불필요한 기능까지 불러져 성능에 부담이 될 수 있음
  - 활용 : 작은 규모의 프로젝트, 학습 목적, ex. 파이썬의 Pandas
  
  - 대표적인 예시 : 리액트
  ➡️사용자 인터페이스 구성에 초점, View만 처리
  ➡️개발자는 상태관리, 라우팅 등을 직접 구현
  
  
• 프레임워크 : 요리 키트, 요리를 할 필요 없이 조리만 해도됨. 개발자는 추가 요리만 더 만들면 됨|
  - 제어 : 프레임워크가 애플리케이션 흐름을 제어
  - 의존성 : 유지보수가 어렵고 다른 기술로의 전환이 어려움
  - 필요기능만 사용하므로 프레임워크에 비해 상대적으로 가벼움
  - 활용 : 대규모 프로젝트, 기업 프로젝트
  
  - 대표적인 예시 : 스프링, Angular, Vue
  ➡️Angular : 애플리케이션에 필요한 모든 기능 (라우팅, 상태관리, HTTP 요청 등)을 포함
  ➡️Vue : 비교적 가벼운 프레임워크지만 리액트보다 더 많은 기본 기능을 제공

---

프레임워크

• 장점 :
  - 이미 만들어진 상태이기때문에 개발자가 바뀌어도 결과물의 일관성이 유지되므로 품질이 보장됨
  - 빠른 구현 시간 : 기본 틀을 참고해서 만들기때문에 구현이 빠름 (=반복 작업 감소)
  - 관리의 용이성
  
  
• 단점 : 
  - 애플리케이션의 구조와 개발흐름을 강제 (규칙을 지켜야함)
  ➡️ex. Angular 프레임워크는 엄격한 컴포넌트 기반 구조
  
  - 자신만의 방식으로 구현이 어려움

---

정리

	API	라이브러리	프레임워크
제공 형태	인터페이스/명세	구현된 코드	아키텍처와 규칙을 포함한 틀
제어	개발자가 직접 제어	개발자가 호출하여 사용	프레임워크가 제어, 개발자는 필요한 부분만 작성
비유	요리 메뉴	요리 도구	주방 시스템
활용	JDBC API	React	Spring, Angular

---

🚀 회고를 통해 항상 헷갈렸던 개념인 API, 라이브러리, 프레임워크를 찾아보며 정리할 수 있었다.

스프링을 접할때마다 부족했던 기본 개념을 다시 쌓아가는 느낌이어서 회고를 진행하면서 다양한 자료를 찾아보기도 했다.

스프링부트의 장단점, 스프링과의 차이점을 명확히 구분해낼 수 있었던 회고였다.