Spring Boot 기초

AngJ·2025년 3월 21일

Backend Spring boot 백엔드

Spring-Boot

목록 보기

1/1

핵심

1️⃣ Spring과 Spring Boot의 차이!

2️⃣ MVC 패턴 개념!

3️⃣ DTO를 활용해 데이터를 다룸

1. Spring과 Spring Boot의 차이

참고) 둘 다 Java 기반 웹 애플리케이션 프레임워크

비교 항목	Spring Framework	Spring Boot
설정 방식	XML, Java Config 필요	자동 설정 (`@SpringBootApplication`)
웹 서버	수동 설정 필요	내장 Tomcat 자동 제공
의존성 관리	수동 설정 필요	`spring-boot-starter-*` 제공
프로젝트 구조	복잡한 설정 필요	간단한 구조
목적	확장성과 유연성 중점	빠른 개발과 설정 최소화

🔥 Spring Boot는 Spring을 더 쉽게 사용할 수 있도록 만든 버전

참고) Spring 프레임워크 : Servlet과 JSP의 복잡한 설정, 코드 중복, 유지보수 어려움 등의 문제로 탄생

1-1. Spring의 핵심 기능

→ OOP의 원칙을 따르며 객체 간의 의존성을 줄이고, 유지보수를 쉽게 할 수 있도록 도움

OOP solid
→ 객체지향 설계에서 지켜줘야할 5개의 소프트웨어 개발 원칙!

SRP(Single Responsibility Principle) : 단일 책임 원칙

OCP(Open Closed Principle) : 개방 폐쇄 원칙

LSP(Liskov Substitution Principle) : 리스코프 치환 원칙

ISP(Interface Segregation Principle) : 인터페이스 분리 원칙

DIP(Dependency Inversion Principle) : 의존 역전 원칙

⇒ 여러 디자인 패턴들이 SOLID 설계 원칙에 입각해 만들어짐

DI(의존성 주입)
→ 객체가 직접 다른 객체를 생성하지 않고, 외부에서 주입받는 방식(Spring에서는 의존성을 자동으로 주입해줌)
➡️ 객체 간의 결합도를 낮추고 유지보수를 쉽게 만듦

new 키워드로 직접 객체 생성 시 의존성이 발생 → 생성자를 이용해 의존성을 주입

    class B {
        public void print() {
            System.out.println("B 클래스의 메서드 실행");
        }
    }

    class A {
        private B b;

        public A(B b) { // 생성자를 이용해 B 객체를 주입
            this.b = b;
        }

        public void execute() {
            b.print();
        }
    }

A 클래스는 B를 직접 생성하지 않는다!

B의 구현이 바뀌더라도 A는 영향을 받지 않음!

AOP(관점 지향 프로그래밍)

→ 공통적으로 적용해야 하는 기능을 분리해 코드 중복을 줄이고 유지보수를 쉽게하는 프로그래밍 기법

➡️ 중복된 코드를 하나의 공통 기능으로 분리해 유지보수성을 높이기 위해 AOP 사용!
Spring MVC

→ 웹 애플리케이션에서 Model-View-Control 구조를 지원
Spring Security

→ Spring 기반 애플리케이션의 보안을 담당하는 프레임워크

➡️ 로그인, 로그아웃, 권한 부여, 요청 보호 등의 기능을 쉽게 구현할 수 있도록 도와줌

참고) Django의 django.contrib.auth 가 제공하는 기능과 비슷한 역할
Spring Data JPA

→ Spring에서 JPA(Java Persistence API)를 더 쉽게 사용할 수 있도록 도와주는 라이브러리

➡️ SQL을 직접 작성하지 않아도 자동으로 데이터베이스와 연결하고, CRUD를 수행 가능!

1-2. Spring의 단점

초기 설정(XML 설정)이 복잡
초기 학습 난이도 ⬆️
- DI, AOP, MVC 등 많은 개념이 있어 처음 배우는 사람이 이해하기 어려움
초기 부팅이 오래 걸림
- Spring은 애플리케이션이 시작될 때 모든 객체(Bean)를 미리 생성하고 설정하는 과정이 존재
  
  ⇒ Java 프로젝트보다 부팅 속도가 느릴 수 있음

2. Spring Boot

2-1. Spring Boot

🔨 Spring 프레임워크를 더 쉽고 빠르게 사용할 수 있도록 도와주는 도구

→ Spring의 복잡한 설정을 최소화

2-2 Spring Boot의 특징

자동 설정

___Application.java: @SpringBootApplication 한 줄로 설정 가능

build.gradle: spring-boot-starter-* 의존성을 추가하면 자동으로 관련 설정이 적용됨
내장 웹 서버 제공(Built-in Web Server)
- 웹 서버를 내장하고 있어 따로 설정하지 않아도 됨
  ➡️ Spring Boot는 실행하면 자동으로 서버가 실행됨
의존성 자동 관리

build.gradle: spring-boot-starter-* : 의존성 관리를 쉽게 할 수 있도록 패키지를 제공
독립 실행 가능

JAR 파일로 패키징하면 실행 파일처럼 동작할 수 있음

→ AWS 서버에 올려 실행시킬 때, JAR 파일로 패키징해 서버를 실행!
환경설정의 유연함

application.properties 또는 application.yml 을 사용해 설정 가능

2-3. Spring Boot의 주요 기능

내장 웹 서버 지원

Tomcat, Jetty, Undertow와 같은 웹 서버를 내장하고 있어 따로 설정할 필요 x
REST API 개발(Spring MVC)

간단한 컨트롤러만 만들어도 API가 동작
Spring Boot + JPA 사용(DB 연동)

Spring Data JPA와 함께 사용하면 데이터베이스 연동이 간단함

Spring Boot 실습

Spring Initialzr 접속

https://start.spring.io/
Project Type 선택

Java 프로젝트에서는 라이브러리(의존성) 관리, 빌드, 테스트, 배포를 자동화 하는 도구가 필요

⇒ Maven, Gradle
- Maven
  - XML(pom.xml) 기반의 전통적인 빌드 도구
  - pom.xml 을 사용해 프로젝트를 빌드하고, 의존성을 관리
    
    XML 형식 : 가독성이 낮고, 길어질수록 설정이 복잡
- Gradle
  - build.gradle 을 사용해 Maven에 비해 더 빠르고 유연함!
  - Gradle이 속도 면에서 Maven보다 빠름
    
    Maven에 비해 작관적이고, 읽기 쉬움
Spring Boot Version 선택

정식 버전을 주로 사용
SNAPSHOT 버전: 개발 중인 미완성 버전, 불안정
M 버전(Milestone Release) : 정식 릴리즈 전 중요한 기능을 테스트하는 중간 단계(베타 버전과 유사, But 정식 출시가 아니므로 주의가 필요)

Project Metadata 입력

Group: 패키지의 그룹 ID ➡️ 회사, 조직, 프로젝트 단위를 나타냄
Artifact: 프로젝트의 고유한 이름(JAR 파일의 기본 이름이 됨)
Name: 프로젝트의 기본 이름(기본적으로 Artifact와 동일하게 설정됨)
Description: 프로젝트에 대한 간단한 설명
pom.xml or build.gradle 파일에 포함
Package name: 프로젝트의 기본 패키지 이름(Group + Artifact 조합)
Packaging: 프로젝트를 빌드할 때 생성되는 최종 실행 파일의 형식을 결정
- Jar(Java Archive) - 하나의 독립 실행 가능한 .jar 파일 생성
- War(Web Application Archive) - 기존의 애플리케이션 서버에 .war 파일을 생성해 배포 가능

Dependencies(의존성) 주입

프로젝트가 정상적으로 실행되기 위해 필요한 라이브러리들 모음
Maven or Gradle을 사용해 필요한 라이브러리를 자동으로 다운로드하고 관리할 수 있도록 도움
```
        
```

🌟 Spring Boot 웹 프로젝트 Dependencies

Spring Web

가장 기본적인 의존성, 내장 Tomcat 서버와 함께 RESTful API를 쉽게 만들 수 있도록 지원

➡️ 컨트롤러를 만들어 HTTP 요청 처리 가능

Lombok

Getter, Setter, 생성자, toString 등의 메서드를 자동으로 생성해주는 라이브러리

➡️ DTO와 Entity 클래스를 만들 때 불필요한 코드 작성을 줄임

Spring Boot Validation

사용자 입력값을 검증하는 라이브러리(잘못된 입력 시 오류 반환)

➡️ @Valid or @NotNull 등을 사용해 REST API의 요청 데이터를 검증 가능

Spring Data JPA

MySQL과 같은 관계형 데이터베이스를 쉽게 다룰 수 있도록 JPA 지원

MySQL JDBC Driver

Spring Boot에서 MySQL과 연동하기 위해 필요한 JDBC 드라이버

💡 본인이 사용하는 DB에 맞는 JDBC Driver 추가

3. MVC 패턴

🔥 애플리케이션을 Model, View, Controller로 나누어 구성하는 방식
→ 유지보수성과 확장성 ⬆️, 코드의 역할을 명확히 구분❗️

3-1. MVC 패턴의 구성요소

Model

📌 애플리케이션의 핵심 데이터와 비즈니스 로직을 처리
- 구성요소
1. Entity : 데이터베이스 테이블과 연결되는 객체 (파일명: User.java)
  
  → Getter, Setter 필수
2. Repository : 데이터 엑세스를 담당하는 계층 (파일명: UserRepository.java)
3. Service : 비즈니스 로직을 처리하는 계층 (파일명: UserService.java)
Controller

📌 사용자의 요청을 받아 Model(Service)과 View(JSON, HTML)사이에서 데이터를 주고받는 역할

Model과 View의 중간다리 역할!

👉 사용자의 요청을 받고 응답을 반환하는 역할

👉 비즈니스 로직을 직접 수행하지 않고, Service에 요청을 전달
- Controller와 Service
Controller 는 HTTP 요청 처리
Service 는 실제 비즈니스 로직 담당
View

📌 사용자가 볼 수 있는 화면 또는 응답 데이터(JSON)
- Thymeleaf 또는 JSON 응답 방식으로 구현
  - Thymeleaf: HTML 기반 View → 프론트엔드가 없는 프로젝트에서 사용
  - JSON 응답: 프론트엔드와 통신할 때 사용

├── src
│   ├── main
│   │   ├── java
│   │   │   └── com.companyname.projectname
│   │   │       ├── post
│   │   │       │   ├── controller
│   │   │       │   │   └── PostController.java
│   │   │       │   ├── dto
│   │   │       │   │   ├── PostRequestDto.java
│   │   │       │   │   ├── PostResponseDto.java
│   │   │       │   │   ├── PostListResponseDto.java
│   │   │       │   │   ├── PostSaveRequestDto.java
│   │   │       │   │   └── PostUpdateRequestDto.java
│   │   │       │   ├── model
│   │   │       │   │   └── Post.java
│   │   │       │   ├── repository
│   │   │       │   │   └── PostRepository.java
│   │   │       │   └── service
│   │   │       │       └── PostService.java
│   │   │       └── ProjectNameApplication.java
│   │   └── resources
│   └── test

3-2. Spring Boot에서 MVC 흐름

Client가 GET 요청을 보냄
Controller가 요청을 받아 Service 호출
Service가 Repository를 통해 데이터베이스에서 데이터를 조회
- Service
  👉 비즈니스 로직을 담당하는 계층
  👉 Controller에서 받은 데이터를 가공하거나 데이터베이스에 저장
조회된 데이터를 Controller로 반환
Controller가 JSON 데이터를 Client에게 응답

3-3. MVC 패턴 실습

데이터 모델(DTO) 구축
데이터 저장소(Service) 구축

→ 회원 데이터를 모델에 저장하는 서비스 클래스 생성
Controller 생성(JSON 응답 반환)

@RestController : HTML 대신 JSON 응답 반환

@GetMapping : 모든 회원 데이터를 JSON으로 반환

@PostMapping + @RequestBody : JSON 데이터를 받아 처리

4. DTO 개념 및 활용

4-1. DTO의 개념

🔥 Data Transfer Object
데이터를 객체로 변환하여 전송하는 객체
주로 Controller ↔ Service ↔ Repository 사이에서 데이터를 주고받을 때 사용

Entity를 직접 사용하지 않고, DTO를 통해 데이터를 가공 후 API 응답으로 변환
→ DTO는 Entity를 보호하면서 API에 필요한 데이터만 전달할 수 있도록 설계됨
매우 민감한 password 와 같은 정보를 선택적으로 주고받을 수 있음!

4-2 DTO를 사용하는 이유

보안 강화
Entity와 요청/응답 데이터를 분리해 유지보수성 ⬆️
여러 개의 Entity 데이터를 조합해 응답 가능(데이터 가공)
쉬운 유효성 검사( @Valid )
불필요한 데이터 노출 방지

4-3. DTO vs Entity

항목	DTO	Entity
역할	데이터 전달 전용	데이터베이스와 직접 연결
목적	Controller ↔ Service ↔ Repository 사이에서 데이터 교환	데이터베이스 테이블과 매핑
비즈니스 로직 포함 여부	X (데이터만 포함)	O (비즈니스 로직 포함 가능)
DB 테이블과 연결 여부	X	O (JPA `@Entity` 사용)
보안성	필요 없는 데이터 필터링 가능	모든 데이터가 노출될 가능성 존재
유지보수성	DTO만 변경 가능(Entity와 독립적인 관계)	Entity 변경 시 API 전체 수정 필요
사용 위치	API 요청/응답, 데이터 가공용	데이터 저장 및 조회용
사용 방식	JSON ↔ DTO 변환	Entity ↔ DTO 변환 후 사용

→ Entity: 데이터베이스에 저장될 데이터 구조

→ DTO: Entity에서 필요한 데이터만 “선별”하여 클라이언트에 저장

🚨 Entity를 직접 사용 X

Entity 리스트

[
    User{id=1, username="Alice", email="alice@example.com"},
    User{id=2, username="Bob", email="bob@example.com"}
]

DTO 사용 후 변환된 리스트

[
    UserResponseDto{username="Alice", email="alice@example.com"},
    UserResponseDto{username="Bob", email="bob@example.com"}
]

AngJ

항상 왜?를 생각하는 개발자