Spring 입문 - 1

💡  오늘 학습 키워드

• Gradle
• 서버
• HTTP
• 테스트
• Spring MVC
• Jackson

 

🎯  학습 내용 정리

1. Gradle

빌드 자동화 시스템으로 Java 코드를 알맞게 자동으로 Build를 진행한다.

※ Build란?
소스코드를 실행 가능한 파일로 만드는 일련의 과정

 

Gradle을 알아야하는 이유는 build.gradle에 있다.

일반적으로 Project를 생성할 때 Gradle과 Maven 중 선택을 하게 된다.
Maven도 Gradle과 마찬가지로 빌드 자동화 시스템이지만 약간의 차이점이 존재한다.

더 자세한 차이점은 이곳에서 확인!

🍃 Maven & Gradle이란?

 

현재는 Gradle을 사용하여 빌드를 자동화하고 있고, 그 설정들은 build.gradle 파일에 담겨있다.

해당 내용들을 이해하고 있어야 추후 빌드 진행 시 문제가 발생해도 정확하게 해결할 수 있기 때문에 알고 있어야 한다!

 

 

2. 서버

백엔드 개발을 공부하다 보면 "서버를 개발한다"는 말을 자주 접하게 된다. 그렇다면 우리가 만드는 서버는 정확히 무엇일까?

 

서버(Server)는 네트워크를 통해 다른 시스템에게 서비스를 제공하는 프로그램 또는 시스템을 의미한다. 웹 서비스에서는 사용자의 요청(Request)을 받아 필요한 작업을 수행한 후 결과(Response)를 반환하는 역할을 담당한다. 예를 들어 사용자가 게시물 목록 조회 버튼을 클릭하면 서버는 데이터베이스에서 게시물 정보를 조회한 뒤 사용자에게 결과를 반환한다.

 

그렇다면 사용자의 요청은 어떤 과정을 거쳐 서버에 도착하고, 서버의 응답은 어떻게 다시 사용자에게 전달될까? 이 과정을 이해하기 위해서는 네트워크에 대한 기본적인 이해가 필요하다.

 

 

네트워크(Network)는 여러 대의 컴퓨터와 장비가 서로 연결되어 정보를 주고받을 수 있도록 하는 기술이다.

인터넷 역시 거대한 네트워크의 집합이며, 우리가 사용하는 웹 서비스는 모두 이러한 네트워크 위에서 동작한다.

웹 서비스에서는 주로 Client와 Server라는 두 가지 개념이 등장한다.

 

 

Client는 서버에게 요청을 보내는 주체를 의미한다.

대표적인 Client는 다음과 같다.

• 웹 브라우저
• 모바일 애플리케이션
• 다른 서버

예를 들어 사용자가 게시물 목록 페이지에 접속하는 경우 브라우저(Client)는 서버(Server)에게 게시물 목록을 요청한다.

Client → 게시물 목록 요청
Server → 게시물 목록 응답

이처럼 클라이언트와 서버는 요청과 응답을 주고받으며 통신한다.

 

 

클라이언트가 서버에게 요청을 보내기 위해서는 서버의 위치를 알아야 한다.

서버의 위치를 나타내는 정보를 IP 주소(IP Address)라고 한다. 하지만 사용자는 일반적으로 IP 주소를 직접 입력하지 않는다.

예를 들어 우리는 다음과 같은 도메인 주소를 사용한다.

www.google.com

 

브라우저는 DNS(Domain Name System)를 통해 도메인 주소를 실제 IP 주소로 변환한 뒤 서버와 통신한다.

사용자
↓
도메인 입력
↓
DNS 조회
↓
IP 주소 획득
↓
서버 연결

즉, 우리가 기억하기 쉬운 도메인을 사용하면 DNS가 실제 서버의 IP 주소를 찾아주는 것이다.

 

하지만 서버의 위치를 알기에는 IP 주소만으로는 충분하지 않다. 하나의 서버에서는 여러 애플리케이션이 동시에 실행될 수 있기 때문이다.

예를 들어 동일한 서버에서 다음과 같은 프로그램이 동작할 수 있다.

192.168.0.10:80    → Nginx
192.168.0.10:8080  → Spring Boot
192.168.0.10:3306  → MySQL

이때 포트 번호는 특정 애플리케이션을 식별하기 위한 번호 역할을 한다.

즉, 요청은 IP 주소로 서버를 찾고, 포트 번호로 해당 서버 내부의 특정 프로그램을 찾게 된다.

 

 

API는 Application Programming Interface의 약자로 소프트웨어 간 기능을 사용할 수 있도록 제공되는 인터페이스이다. 클라이언트는 API를 통해 서버의 기능을 호출하고 결과를 전달받는다. 예를 들어 게시물 목록 조회 API가 있다고 가정해보자.

GET /posts

클라이언트가 위 요청을 보내면 서버는 다음과 같은 데이터를 반환할 수 있다.

[
  {
    "id": 1,
    "title": "게시글"
  }
]

이처럼 API는 클라이언트와 서버가 소통하기 위한 창구 역할을 수행한다.

 

API에 대해 공부하다보면 REST API라는 용어를 자주 접할 수 있을 것이다.

REST는 Representational State Transfer의 약자로 웹 애플리케이션을 설계하기 위한 아키텍처 스타일이다. REST에서는 URI를 통해 자원(Resource)을 표현하고 HTTP Method를 통해 수행할 작업을 나타낸다.

예를 들어 게시물 기능은 다음과 같이 표현할 수 있다.

GET    /posts      → 게시물 목록 조회
POST   /posts      → 게시물 생성
GET    /posts/1    → 특정 게시물 조회
PUT    /posts/1    → 게시물 수정
DELETE /posts/1    → 게시물 삭제

이처럼 REST 원칙을 기반으로 설계된 API를 REST API라고 하며, REST의 특성을 잘 따르는 서비스를 RESTful하다고 표현한다.

 

 

웹 서비스 구조를 이해하기 위해서는 WS(Web Server)와 WAS(Web Application Server)의 차이도 알아야 한다.

 

WS는 Web Server의 약자로 정적인 콘텐츠를 제공하는 역할을 담당한다.

대표적으로 다음과 같은 파일들을 처리한다.

• HTML
• CSS
• JavaScript
• 이미지

또한 최근에는 단순히 정적 파일만 제공하는 것이 아니라 Reverse Proxy, SSL 처리, 로드 밸런싱 등의 역할도 수행한다.

대표적인 Web Server는 다음과 같다.

• Nginx
• Apache

 

WAS는 Web Application Server의 약자로 동적인 비즈니스 로직을 수행하는 서버이다.

사용자 요청에 따라 데이터를 조회하거나 저장하고, 필요한 계산을 수행한 뒤 결과를 반환한다.

대표적인 WAS는 다음과 같다.

• Tomcat
• JBoss

실제 서비스에서는 다음과 같은 구조를 많이 사용한다.

Client
↓
Nginx
↓
Spring Boot (Tomcat)
↓
MySQL

Nginx가 요청을 받아 적절한 Spring Boot 서버로 전달하고, Spring Boot는 비즈니스 로직을 처리한 뒤 결과를 반환한다.

 

 

기존 Spring Framework 기반 웹 애플리케이션은 WAR 파일을 생성한 뒤 외부 Tomcat 서버에 배포하는 방식이 일반적이었다.

반면 Spring Boot는 Embedded Tomcat(내장 Tomcat)을 제공하여, 별도의 WAS를 설치하거나 설정하지 않아도 애플리케이션을 실행할 수 있다.

java -jar application.jar

위 명령어만으로 웹 서버가 함께 실행된다.

이러한 편의성 덕분에 현재 대부분의 Spring 프로젝트는 Spring Boot를 기반으로 개발되고 있다.

 

 

3. HTTP

웹 브라우저에서 URL을 입력하고 엔터를 누르면 어떤 일이 발생할까?

브라우저는 서버에게 요청(Request)을 보내고, 서버는 요청을 처리한 뒤 응답(Response)을 반환한다. 이때 클라이언트와 서버가 서로 데이터를 주고받기 위해 사용하는 규칙을 HTTP라고 한다.

 

HTTP는 HyperText Transfer Protocol의 약자로 웹에서 클라이언트와 서버가 데이터를 주고받기 위한 애플리케이션 계층의 통신 프로토콜이다.

※ 프로토콜(Protocol)이란?
컴퓨터끼리 데이터를 주고받기 위해 미리 정해둔 약속

 

현재 우리가 사용하는 대부분의 웹 서비스는 HTTP를 기반으로 동작하며, 웹 브라우저와 웹 서버 역시 HTTP 규칙에 따라 통신한다.

초기에는 HTML 문서를 전송하기 위해 만들어졌지만, 현재는 JSON, 이미지, 동영상, 파일 등 다양한 형태의 데이터를 전달하는 데 사용된다.

 

 

HTTP는 Request(요청)와 Response(응답) 구조로 동작한다.

사용자가 웹사이트에 접속하면 브라우저는 서버에게 필요한 정보를 요청한다.

Client → Request
Server → Response

예를 들어 게시물 목록 페이지에 접속하는 경우 다음과 같은 흐름으로 동작한다.

사용자
↓
게시물 목록 클릭
↓
브라우저가 서버에 요청 전송
↓
서버가 게시물 조회
↓
응답 반환
↓
브라우저 화면 렌더링

서버는 요청을 처리한 결과를 응답하며, 브라우저는 응답받은 데이터를 기반으로 화면을 구성한다.

 

 

HTTP 요청과 응답은 모두 일정한 형식을 가진 메시지로 구성된다.

크게 다음과 같은 구조를 가진다.

Start Line
Headers
Body

 

 

Start Line은 요청의 목적과 방식을 나타낸다.

예를 들어 게시물 목록 조회 요청은 다음과 같이 표현된다.

GET /posts HTTP/1.1

여기서

• GET : 요청 방식(Method)
• /posts : 요청 URI
• HTTP/1.1 : HTTP 버전

을 의미한다.

 

Headers는 요청 또는 응답에 대한 부가 정보를 담는다.

예를 들어 다음과 같은 정보들이 포함될 수 있다.

Content-Type: application/json
Authorization: Bearer token
User-Agent: Chrome

헤더는 데이터를 설명하는 정보이므로 메타데이터(Metadata)라고도 부른다.

 

Body는 실제 데이터를 담는 영역이다.

예를 들어 회원가입 요청의 경우 다음과 같은 JSON 데이터가 Body에 포함될 수 있다.

{
  "name": "kim",
  "email": "kim@example.com"
}

 

즉,

• Header → 데이터를 설명하는 정보
• Body → 실제 데이터

라고 이해하면 된다.

 

 

HTTP는 요청의 목적을 표현하기 위해 Method를 사용한다.

대표적으로 다음과 같은 Method가 존재한다.

GET	데이터 조회
POST	데이터 생성
PUT	데이터 전체 수정
PATCH	데이터 일부 수정
DELETE	데이터 삭제

 

예를 들어 게시물을 조회하는 경우에는 다음과 같이 요청할 수 있다.

GET /posts

 

새로운 게시물을 생성하는 경우에는 다음과 같이 요청한다.

POST /posts

 

 

Method를 통해 서버에게 어떤 작업을 수행할 것인지 전달할 수 있다.

 

 

HTTP 통신은 브라우저의 개발자 도구에서 직접 확인할 수 있다.

Chrome 기준으로 F12를 누른 후 Network 탭을 선택하면 브라우저가 서버와 주고받는 모든 HTTP 요청과 응답을 확인할 수 있다.

여기서 다음과 같은 정보를 볼 수 있다.

• 요청 URL
• HTTP Method
• 요청 헤더(Request Headers)
• 요청 본문(Request Payload)
• 응답 상태 코드(Status Code)
• 응답 데이터(Response Body)

백엔드 개발을 공부한다면 Network 탭을 자주 확인하는 습관을 들이는 것이 좋다. 실제로 클라이언트와 서버가 어떤 데이터를 주고받는지 가장 쉽게 확인할 수 있는 도구이기 때문이다.

 

 

4. 테스트

소프트웨어를 개발하다 보면 의도한 대로 동작하지 않는 경우가 발생한다. 이러한 문제를 일반적으로 버그(Bug)라고 부른다.

버그는 소스 코드의 오류, 설계상의 문제, 요구사항에 대한 잘못된 이해 등 다양한 원인으로 발생할 수 있으며, 예상하지 못한 결과를 만들어낸다.

 

따라서 개발 과정에서는 기능이 올바르게 동작하는지 검증하는 과정이 반드시 필요하다. 이를 테스트(Test)라고 한다.

 

왜 테스트가 필요할까?

기능이 적은 초기 프로젝트에서는 직접 실행해 보며 확인할 수 있다. 하지만 프로젝트 규모가 커질수록 다음과 같은 문제가 발생한다.

• 수정한 코드가 기존 기능에 영향을 줄 수 있다.
• 모든 기능을 직접 테스트하기 어렵다.
• 배포 후 예상치 못한 장애가 발생할 수 있다.

예를 들어 회원가입 기능을 수정했는데 로그인 기능이 동작하지 않는 상황이 발생할 수 있다. 이러한 문제를 사전에 발견하기 위해 테스트를 수행한다.

테스트는 단순히 버그를 찾기 위한 과정이 아니라, 기존 기능이 정상적으로 동작함을 보장하는 안전장치 역할을 한다.

 

 

블랙박스 테스트(Black Box Testing)는 내부 구현을 알지 못하는 상태에서 사용자의 관점으로 기능을 검증하는 테스트 방법이다.

테스터는 코드의 구조나 구현 방식을 알 필요 없이 입력과 출력만을 확인한다.

 

예를 들어 회원가입 기능이 있다고 가정해보자.

입력
- 이메일
- 비밀번호

예상 결과
- 회원가입 성공

또는

입력
- 중복 이메일

예상 결과
- 중복 회원 예외 발생

과 같이 실제 사용자가 서비스를 사용하는 방식으로 테스트를 수행한다.

 

블랙박스 테스트의 장점은 사용자 관점에서 기능을 검증할 수 있다는 것이다. 반면 내부 로직을 알지 못하기 때문에 특정 예외 상황이나 숨겨진 버그를 발견하기 어려울 수 있으며, 테스트 수행자의 경험에 따라 테스트 품질이 달라질 수 있다.

QA(Quality Assurance) 직군에서는 이러한 블랙박스 테스트를 포함하여 소프트웨어 품질을 검증하는 업무를 수행한다.

 

 

개발자는 소스 코드를 직접 작성하기 때문에 내부 동작을 이해한 상태에서 테스트를 작성할 수 있다. 이를 통해 다양한 예외 상황까지 검증할 수 있으며 테스트를 자동화할 수 있다.

 

예를 들어 게시글 생성 기능이 있다고 가정해보자.

개발자는 다음과 같은 상황을 테스트할 수 있다.

• 정상적으로 게시글이 생성되는지
• 제목이 비어 있는 경우 예외가 발생하는지
• 작성자가 존재하지 않는 경우 예외가 발생하는지

이러한 테스트는 사람이 직접 확인하지 않아도 실행할 수 있으며, 코드 변경 시마다 반복적으로 검증할 수 있다.

 

개발자 테스트의 장점으로는

• 빠른 실행 속도
• 반복 실행 가능
• 테스트 자동화 가능
• 회귀 버그 방지
• 안정적인 리팩토링 가능

가 있으며, 개발자 테스트의 단점으로는

• 테스트 코드 작성 시간이 필요하다.
• 유지보수 비용이 발생한다.
• 잘못 작성된 테스트는 신뢰성을 떨어뜨릴 수 있다.

가 있다.

 

대부분의 실무 프로젝트에서는 안정성을 위해 테스트 코드 작성을 권장한다.

 

 

프로젝트 규모가 커질수록 사람이 모든 기능을 직접 확인하는 것은 현실적으로 어렵다.

예를 들어 100개의 기능이 있는 서비스에서 작은 수정이 발생할 때마다 모든 기능을 수동으로 검증해야 한다면 많은 시간이 소요된다.

테스트 자동화를 사용하면 코드 변경 시 테스트를 자동으로 실행하여 기존 기능이 정상 동작하는지 확인할 수 있다. 이를 통해 개발자는 변경 사항에 대한 자신감을 가지고 코드를 수정할 수 있다.

 

JUnit은 Java에서 가장 널리 사용되는 단위 테스트(Unit Test) 프레임워크이다.

단위 테스트란 애플리케이션의 가장 작은 단위인 메서드나 클래스를 독립적으로 검증하는 테스트를 의미한다.

 

예를 들어 두 숫자를 더하는 메서드가 있다고 가정해보자.

int result = calculator.add(1, 2);
assertEquals(3, result);

위 테스트는 add() 메서드가 정상적으로 동작하는지 검증한다.

 

JUnit은 다음과 같은 기능을 제공한다.

• 테스트 실행
• 결과 검증
• 테스트 그룹화
• 테스트 생명주기 관리
• 예외 검증

 

Spring Boot 프로젝트를 생성하면 기본적으로 테스트 환경이 함께 구성된다.

대표적으로 다음과 같은 라이브러리가 포함된다.

• JUnit 5
• Mockito
• AssertJ
• Spring Test

덕분에 별도의 설정 없이도 테스트 코드를 작성하고 실행할 수 있다.

 

실무에서는 비즈니스 로직을 검증하는 단위 테스트(Unit Test)와 Spring 환경을 함께 검증하는 통합 테스트(Integration Test)를 함께 사용하는 경우가 많다.

 

 

5. Spring MVC

웹 애플리케이션을 개발하다 보면 MVC(Model-View-Controller)라는 용어를 자주 접하게 된다.

Spring Framework 역시 MVC 패턴을 기반으로 웹 애플리케이션을 개발할 수 있도록 Spring MVC를 제공하고 있다.

 

MVC Pattern

 

MVC(Model-View-Controller)는 소프트웨어를 구성하는 요소를 역할에 따라 분리하는 디자인 패턴이다.

애플리케이션의 관심사를 분리하여 유지보수성과 확장성을 높이는 것을 목적으로 한다.

 

MVC는 다음 세 가지 구성 요소로 이루어진다.

 

Model

Model은 데이터와 비즈니스 로직을 담당한다.

주로 데이터베이스와 연동하여 데이터를 조회하거나 저장하는 역할을 수행한다.

예를 들어 회원 조회, 게시글 생성, 주문 처리 등의 로직이 Model 영역에 포함된다.

 

View

View는 사용자에게 보여지는 화면을 담당한다.

HTML, JSP, Thymeleaf 등의 템플릿을 통해 데이터를 화면에 출력한다.

즉, 사용자가 직접 확인하는 UI(User Interface)를 의미한다.

 

Controller

Controller는 사용자의 요청을 받아 적절한 비즈니스 로직을 수행하도록 연결하는 역할을 한다.

사용자의 요청을 처리한 후 Model의 결과를 View에 전달한다.

Client
 ↓
Controller
 ↓
Model
 ↓
Controller
 ↓
View
 ↓
Client

 

이처럼 각 구성 요소가 명확하게 역할을 분리함으로써 코드의 재사용성과 유지보수성을 높일 수 있다.

 

 

그렇다면 Spring MVC는 무엇일까?

 

Spring MVC는 Servlet API를 기반으로 구축된 웹 프레임워크이다.

Spring 공식 문서에서는 Spring MVC를 다음과 같이 설명한다.

Spring MVC는 DispatcherServlet을 중심으로 동작하는 Front Controller 패턴 기반의 웹 프레임워크이다.

 

즉, Spring MVC는 모든 HTTP 요청을 중앙에서 관리하는 DispatcherServlet을 통해 요청을 처리한다.

 

그렇다면 DispatcherServlet은 또 무엇일까?

DispatcherServlet을 이해하기 위해 먼저 Servlet이 무엇인지 알아보자.

 

 

Servlet(서블릿)은 Java를 사용하여 웹 요청을 처리하기 위한 서버 측 프로그램이다.

웹 서버는 클라이언트로부터 HTTP 요청을 받으면 Servlet을 실행하여 요청을 처리한다.

 

Servlet의 기본적인 동작 과정은 다음과 같다.

Client
 ↓
HTTP Request
 ↓
Servlet Container
 ↓
Servlet
 ↓
HTTP Response
 ↓
Client

구체적인 흐름은 다음과 같다.

1. 클라이언트가 HTTP 요청을 보낸다.
2. Servlet Container가 요청을 받는다.
3. HttpServletRequest 객체를 생성한다.
4. HttpServletResponse 객체를 생성한다.
5. 요청에 맞는 Servlet을 찾는다.
6. service() 메서드를 호출한다.
7. HTTP Method에 따라 doGet(), doPost() 등을 호출한다.
8. 응답을 생성하여 클라이언트에게 반환한다.
9. 요청 처리가 끝나면 객체를 정리한다.

 

만약 모든 API 요청을 직접 Servlet으로 구현한다면 어떻게 될까?

LoginServlet
SignupServlet
PostServlet
CommentServlet
OrderServlet
...

기능이 늘어날수록 수많은 Servlet 클래스를 만들어야 한다. 또한 공통적으로 처리해야 하는 로직도 반복된다.

 

예를 들면

• 인증 처리
• 예외 처리
• 로그 기록
• 요청 분석

등의 작업이 모든 Servlet에 중복될 수 있다.

이러한 문제를 해결하기 위해 등장한 것이 Front Controller 패턴이다.

 

 

Front Controller 패턴은 모든 요청을 하나의 진입점에서 처리하는 디자인 패턴이다.

클라이언트의 요청은 개별 Controller로 직접 전달되지 않고 먼저 Front Controller를 거치게 된다.

Client
 ↓
Front Controller
 ↓
Controller

공통 처리를 Front Controller에서 수행할 수 있기 때문에 코드 중복을 줄이고 유지보수성을 높일 수 있다.

Spring MVC에서는 DispatcherServlet이 Front Controller 역할을 수행한다.

 

 

Spring Boot 애플리케이션에서는 모든 HTTP 요청이 먼저 DispatcherServlet으로 전달된다.

DispatcherServlet은 요청 정보를 분석한 뒤 적절한 Controller를 찾아 요청을 위임한다.

 

동작 과정은 다음과 같다.

Client
 ↓
DispatcherServlet
 ↓
Handler Mapping
 ↓
Controller
 ↓
Service
 ↓
Controller
 ↓
DispatcherServlet
 ↓
Response

 

 

1. 요청 수신

클라이언트가 HTTP 요청을 보낸다.

GET /api/hello

 

2. Handler Mapping 조회

DispatcherServlet은 요청 URL을 기반으로 어떤 Controller가 처리해야 하는지 찾는다.

Handler Mapping에는 URL과 Controller 메서드의 정보가 저장되어 있다.

 

3. Controller 실행

예를 들어 다음과 같은 Controller가 있다고 가정해보자.

@RestController
public class HelloController {

    @GetMapping("/api/hello")
    public String hello() {
        return "Hello World!";
    }
}

DispatcherServlet은 /api/hello 요청을 hello() 메서드에 연결한다.

GET /api/hello
 ↓
HelloController.hello()

 

4. 응답 생성

Controller가 반환한 결과를 DispatcherServlet이 HTTP 응답으로 변환한다.

Hello World!

이후 클라이언트에게 응답을 전달한다.

 

 

전통적인 Spring MVC에서는 Controller가 View 이름을 반환한다.

@GetMapping("/home")
public String home() {
    return "home";
}

DispatcherServlet은 ViewResolver를 사용하여 실제 View를 찾는다.

home
 ↓
ViewResolver
 ↓
home.jsp

이후 Model 데이터를 View에 전달하여 화면을 생성한 뒤 사용자에게 응답한다.

 

다만 최근 Spring Boot에서는 REST API 기반 개발이 많아지면서 ViewResolver보다 JSON 응답을 반환하는 방식이 더 자주 사용된다.

 

 

6. Jackson

Spring Boot로 API를 개발하다 보면 별도의 JSON 변환 코드를 작성하지 않았음에도 객체가 자동으로 JSON으로 변환되거나, JSON 데이터가 객체로 변환되는 경험을 하게 된다.

이는 Spring이 내부적으로 Jackson 라이브러리를 사용하기 때문이다.

 

Jackson은 Java 객체와 JSON 데이터를 상호 변환하기 위한 라이브러리이다.

JSON은 JavaScript Object Notation의 약자로 현재 웹 API에서 가장 널리 사용되는 데이터 교환 형식이며, 클라이언트와 서버는 주로 JSON 형태로 데이터를 주고받는다.

 

Jackson은 이러한 JSON 데이터를 Java 객체로 변환하거나, Java 객체를 JSON 데이터로 변환하는 기능을 제공한다.

대표적으로 다음 두 가지 기능을 수행한다.

• Java Object → JSON (직렬화, Serialization)
• JSON → Java Object (역직렬화, Deserialization)

 

Spring Framework는 3.0 이후부터 Jackson을 공식적으로 지원하고 있으며, Spring Boot에서는 spring-boot-starter-web 의존성에 Jackson 관련 라이브러리가 기본 포함되어 있다.

 

따라서 개발자가 직접 JSON 변환 코드를 작성하지 않아도 Spring이 자동으로 처리해준다.

예를 들어 다음과 같은 Controller가 있다고 가정해보자.

@RestController
public class StudentController {

    @GetMapping("/student")
    public Student getStudent() {
        return new Student("Student", 26);
    }
}

Spring은 반환된 Student 객체를 자동으로 JSON으로 변환하여 응답한다.

{
  "name": "Student",
  "age": 26
}

반대로 클라이언트가 JSON 데이터를 전송하면 @RequestBody를 통해 자동으로 객체로 변환할 수 있다.

@PostMapping("/student")
public void createStudent(@RequestBody Student student) {
    System.out.println(student.getName());
}

이 과정 역시 내부적으로 Jackson이 수행한다.

 

 

Jackson의 핵심 클래스는 ObjectMapper이다.

ObjectMapper를 사용하면 JSON과 Java 객체를 직접 변환할 수 있다.

ObjectMapper objectMapper = new ObjectMapper();

 

 

 

Java 객체를 JSON 문자열로 변환하는 과정을 직렬화(Serialization)라고 한다.

예를 들어 다음과 같은 객체가 있다고 가정해보자.

public class Student {

    private String name;
    private int age;

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

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }
}

테스트 코드는 다음과 같다.

@Test
void objectToJson() throws JsonProcessingException {

    Student student = new Student("Student", 26);

    ObjectMapper objectMapper = new ObjectMapper();

    String json = objectMapper.writeValueAsString(student);

    System.out.println(json);
}

실행 결과

{"name":"Student","age":26}

writeValueAsString() 메서드는 객체를 JSON 문자열로 변환해준다.

 

 

JSON 문자열을 Java 객체로 변환하는 과정을 역직렬화(Deserialization)라고 한다.

@Test
void jsonToObject() throws JsonProcessingException {

    String json = "{\"name\":\"Student\",\"age\":26}";

    ObjectMapper objectMapper = new ObjectMapper();

    Student student = objectMapper.readValue(json, Student.class);

    System.out.println(student.getName());
}

실행 결과

Student

readValue() 메서드는 JSON 문자열을 지정한 클래스 타입의 객체로 변환해준다.

 

첫 번째 파라미터

json

은 JSON 문자열이고,

 

두 번째 파라미터

Student.class

는 변환할 객체 타입이다.

 

 

Jackson은 기본적으로 Java Bean 규약을 활용하여 객체를 변환한다.

예를 들어 다음과 같은 getter가 존재하면

public String getName() {
    return name;
}

Jackson은 이를 name 프로퍼티로 인식한다.

 

또한 객체 생성 시에는

• 기본 생성자
• 생성자 기반 역직렬화
• record
• @JsonCreator

등 다양한 방법을 지원한다.

 

따라서 과거처럼 "기본 생성자와 setter가 반드시 필요하다"기보다는 객체 구조에 따라 적절한 방식을 사용할 수 있다.

최근 Spring Boot 프로젝트에서는 Lombok과 record를 활용하는 경우도 많다.

 

 

📚  한줄 정리

1. Gradle은 프로젝트의 빌드, 테스트, 의존성 관리를 자동화하는 빌드 도구이다.
2. 서버는 네트워크를 통해 다른 시스템에 서비스를 제공하는 프로그램 또는 시스템이며, 백엔드 개발의 핵심 구성 요소이다.
3. HTTP는 클라이언트와 서버가 요청과 응답을 주고받기 위한 웹의 대표적인 통신 프로토콜이다.
4. 테스트는 버그를 발견하는 것을 넘어 안정적인 코드 변경과 서비스 품질을 보장하기 위한 핵심 개발 문화이다.
5. Spring MVC는 DispatcherServlet을 중심으로 동작하는 Front Controller 패턴 기반의 웹 프레임워크로, HTTP 요청을 효율적으로 처리할 수 있도록 지원한다.
6. Jackson은 Java 객체와 JSON 데이터를 상호 변환해주는 라이브러리이며, Spring Boot는 이를 활용해 HTTP 요청과 응답의 JSON 처리를 자동화한다.