[SpringBoot] 스프링부트 시작

본 게시글은 도서 <스프링 부트 3 백엔드 개발자 되기: 자바 편>을 읽고 작성되었습니다.

대표적인 백엔드 환경으로는 자바/코틀린을 사용하는 스프링과 스프링 부트, 파이썬을 사용하는 장고/플라스크, Go 언어를 쓰는 gin, C#을 쓰는 .NET 프레임워크, 자바스크립트를 쓰는 Node.js(NestJS/익스프레스) 가 있다.

한국에서는 스프링 프레임워크가 오랜 기간 공공기관, 금융권, 대기업 SI에서 표준 프레임워크처럼 자리 잡았다.
XML 설정이 복잡했던 스프링의 단점을 보완하고, 빠르게 개발할 수 있는 스프링 부트가 등장하면서 사실상 업계 표준으로 굳어졌다.

SpringBoot 기초

스프링 부트는 자바 기반 프레임워크이다.
따라서 자바 언어에 대한 기초 지식은 필수이며, 데이터베이스와 SQL 관련 지식도 함께 요구된다.

자바 백엔드 개발에서 주로 다루게 되는 개념은 다음과 같다. 이는 앞으로 더 학습하면서 실제 코드로 구체화할 것이다.

• JPA : 객체와 데이터베이스를 매핑하여 SQL을 직접 작성하지 않고도 데이터에 접근 가능
• 인증/인가 : 로그인, 세션, JWT 토큰 기반 인증 구현 (Spring Security 활용)
• AWS 배포 : EC2, RDS, S3 같은 인프라를 활용해 실제 서비스 배포
• CI/CD: GitHub Actions, Jenkins 등을 활용해 코드 자동 빌드/배포

스프링 부트 프로젝트에는 항상 실행 진입점 역할을 하는 @SpringBootApplication 클래스가 있다. 이 클래스의 main() 메소드를 실행하면 내장 톰캣 서버가 8080 포트에서 자동으로 실행된다.
(*톰캣 : Apache Tomcat은 자바 기반 웹 애플리케이션을 실행하기 위한 서버이다. 예전에는 톰캣을 별도로 설치하고, 스프링 애플리케이션을 war 파일로 배포해야 했다. 하지만 스프링 부트는 톰캣을 내장하고 있어, 별도의 서버 설치 과정 없이 java -jar 명령어만으로 바로 서버를 실행할 수 있다. 즉, 스프링 부트는 “애플리케이션 + 서버”가 하나로 묶여 있어서 개발자가 훨씬 쉽게 실행하고 배포할 수 있다.)

모바일 개발할때 MVC, MVVM 등 여러 구조를 적용하여 개발을 했던 것처럼 스프링 부트도 MVC 패턴으로 계층을 나눠서 유지보수성과 확장성을 확보할 수 있다.
Controller 는 API 요청을 받는 입구, Service는 비즈니스 로직 처리, Repository는 JPA 기반 DB 접근 담당, Domain/Entity는 데이터 모델 정의를 담당한다.

Spring Boot 특징 정리

1. 톰캣, 제티와 같은 웹 애플리케이션 서버(WAS)가 내장되어 있어 따로 설치하지 않아도 독립적으로 서버 실행 가능하다.
2. 빌드 구성을 단순화하는 스프링 부트 스타터가 있다.
3. XML 설정 없이 자바 코드로 모두 작성 가능
4. JAR을 이용하여 자바 옵션만으로 배포 가능

Spring Boot 핵심 철학 4가지

1. IoC (Inversion of Control, 제어의 역전)
   보통 객체를 만들고 의존성을 연결하는 제어권은 개발자 코드에 있지만, 스프링 컨테이너(ApplicationContext)가 객체 생성과 생명주기 관리 제어권을 가져가는 것을 말한다.

2. DI (Dependency Injection, 의존성 주입)
   IoC의 한 형태이다. 예를 들어 UserService가 UserRepository를 필요로 하면, 개발자가 new UserRepository()로 직접 생성하지 않고, 스프링이 알아서 넣어준다(@Autowired, 생성자 주입).

3. AOP (Aspect Oriented Programming, 관점 지향 프로그래밍)
   반복되는 공통 로직(로깅, 트랜잭션, 보안 검사 등)을 흩뿌리지 않고 횡단 관심사(cross-cutting concern) 로 분리한다. 횡단 관심사란 비즈니스 로직(핵심 기능)과는 직접적 관련이 없지만, 여러 모듈에서 공통으로 필요한 기능이다. 예를 들어 결제 서비스, 회원 서비스, 주문 서비스 같은 주요 기능(Service)들이 있다고 하면, 각각의 로직은 다르지만 공통적으로 로그 남기기, 트랜잭션 열고 닫기, 보안 체크 등은 공통이다. 이런 공통된 기능이 횡단해서 모든 서비스 코드에 걸쳐 흩뿌려진다.
   👉 예: @Transactional만 붙이면 트랜잭션 처리 자동 적용. 덕분에 비즈니스 로직(Service) 코드가 깔끔해진다.

• 횡단 관심사를 코드에 직접 넣었을 때 (문제)

public class OrderService {
    public void createOrder() {
        System.out.println("트랜잭션 시작");
        // 주문 생성 로직
        System.out.println("주문 저장 완료");
        System.out.println("트랜잭션 종료");
    }
}

• AOP 활용 (해결)

@Service
public class OrderService {
    @Transactional   // 횡단 관심사 분리
    public void createOrder() {
        // 주문 생성 로직만 남김
        System.out.println("주문 저장 완료");
    }
}

4. PSA (Portable Service Abstraction, 일관된 추상화)
   스프링이 다양한 기술을 추상화해, 개발자가 일관된 코드로 다른 구현체를 쓸 수 있게 해주는 것이다.
   👉 예: DB 접근 시 JPA/Hibernate/MyBatis 등 어떤 기술이든 Repository 인터페이스로 동일하게 사용, 웹 클라이언트도 RestTemplate, WebClient 등으로 일관된 방식 제공

개발 환경 구축

스프링 부트 프로젝트 작성에 앞서 IDE 를 선택하면 되는데 많은 개발자들이 사용하는 인텔리제이를 사용하려고 한다.

인텔리제이에서 New Project를 누르고, JDK 버전을 선택한다. 만약 없다면 Download JDK를 눌러 설치가 필요하다. 나는 이미 설치가 되어있어서 따로 설치하지는 않았다. 해당 도서에서는 JDK 17을 사용하였다.

프로젝트의 이름을 설정하고, 언어를 Java로 선택하고 빌드 시스템은 Gradle로 선택하려고 한다. DSL는 Groovy로 선택한다.

그 이유는 다음과 같다.

Gradle vs Maven

• Gradle 과 Maven 은 둘 다 자바에서 사용되는 빌드 관리 도구이다. 우리가 작성하는 코드는 사용자가 바로 사용할 수 없는 형태여서 사용자가 사용할 수 있는 모습을 갖추려면 빌드(의존성 내려받기, 코드 패키징, 컴파일, 테스트 실행 등)를 거쳐야한다.
• Maven은 오래전부터 표준처럼 사용되던 빌드 시스템이다. 하지만 XML 기반 설정은 다소 장황하고 확장성이 부족하다. 반면, Gradle 은 빌드 속도가 빠르고 유연한 DSL을 제공하여 최근에는 Gradle 사용 비중이 늘고 있다.
• 예를 들어, Maven은 새로운 의존성을 추가하고 빌드할 때 전체를 다시 컴파일하는 경우가 많지만, Gradle은 증분 빌드를 지원해서 수정된 부분만 빌드한다. 이는 대규모 프로젝트일수록 빌드 시간 차이가 크게 난다.
• 특히 안드로이드 개발에서도 Gradle을 사용하기 때문에, 모바일 개발 경험이 있는 사람이라면 Gradle이 더 익숙할 수 있다.
• *DSL : 특정 분야(도메인)에 특화된 간단하고 읽기 쉬운 언어로 범용 언어(Java, Python)처럼 뭐든 다 할 수 있는 건 아니지만, 특정 목적을 위해 효율적이게 설계됨

Groovy vs Kotlin DSL

• Gradle은 두 가지 방식으로 스크립트를 작성할 수 있다.
• Groovy DSL: 전통적인 방식, 인터넷 자료가 많아 학습 난이도가 낮다.
• Kotlin DSL: 타입 안전성이 좋아 IDE 자동완성이 강력하다. 하지만 레퍼런스가 아직 적고, 초기 설정이 까다롭다.
• 따라서 입문 단계에서는 스프링 공식 문서나 블로그 예제 대부분이 아직 Groovy DSL로 작성되어 있기 때문에, Groovy DSL을 선택하는 것이 따라 하기 편하다.

여기까지 해서 프로젝트를 생성하면, 그레이들 프로젝트를 생성한 것이다. 이제 스프링 부트3 프로젝트로 바꿔보자. 그레이들 프로젝트를 스프링 부트 프로젝트로 바꾸려면 build.gradle 을 수정하면 된다.

나는 이렇게 수정하였다.

plugins {
    id 'java'
    id 'org.springframework.boot' version '3.2.0'
    id 'io.spring.dependency-management' version '1.1.0'
}

group = 'org.example'
version = '1.0'
sourceCompatibility = '17'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

test {
    useJUnitPlatform()
}

수정 후 우측 상단의 코끼리 아이콘을누르고 메뉴바의 새로고침을 누른다.

빌드가 완료되면, org.example (본인 패키지 네임) 아래에 우클릭 -> new -> packages 를 클릭하여 springbootdeveloper 라는 패키지를 새롭게 생성해보았고, 그 밑에 우클릭 -> new -> Class -> SpringBootDeveloperApplication 입력 후 클래스를 생성해보았다.

모든 프로젝트엔 메인 클래스가 필요하다. 이 클래스를 메인 클래스로 사용하려면 다음처럼 @SpringBootApplication 어노테이션과 main 함수를 입력한다.

package org.example.springbootdeveloper;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class SpringBootDeveloperApplication {
    public static void main(String[] args) {
        SpringApplication.run(SpringBootDeveloperApplication.class, args);
    }
}

그 후, 해당 메인 클래스를 우클릭하여 Run SpringBoot .. main() 클릭하여 실행한다.
다음처럼 스프링 애플리케이션이 실행되었음을 알 수 있는 메시지를 콘솔에서 확인할 수 있다.

포스트맨 설치하기

이제 환경 세팅이 끝났다면 포스트맨을 설치해야한다. 필자는 이미 설치되어 있지만, 포스트맨은 이 사이트에서 운영체제에 맞는 버전의 [다운로드]를 눌러 설치할 수 있다.

포스트맨은 HTTP 요청을 보낼 수 있는 클라이언트 프로그램이다.
즉, 우리가 만든 서버(API)가 제대로 동작하는지 직접 호출해보고, 응답을 확인할 수 있는 툴이다.

포스트맨 사용 이유
1. 테스트가 편리함 : 브라우저는 보통 GET 요청만 쉽게 확인하고, POST/PUT/DELETE 요청은 브라우저만으로 테스트하기 어려운 경우가 존재한다. 포스트맨을 쓰면 모든 HTTP 메소드를 쉽게 테스트할 수 있다.
2. 요청 구성 가능 : Header, Body, Authorization, Cookie 등을 직접 세팅 가능해서, JWT 토큰을 헤더에 넣어서 직접 인증된 API 요청을 테스트하거나 할 수 있다.
3. 반복적인 테스트 자동화 가능 : 테스트를 일일이 하면 많은 시간이 소요된다. 이때 여러 요청을 모아 "컬렉션"으로 관리하면 필요할때마다 한번에 테스트가 가능하다.

실무에서는 프론트엔드 개발자와 백엔드 개발자가 포스트맨 컬렉션을 공유하면서 API 스펙을 맞추기도 한다.
QA 팀도 포스트맨으로 기능 검증을 하기 때문에, 포스트맨은 단순 테스트 도구를 넘어 팀 협업 도구로도 활용된다.