[Spring Boot] Spring Initializr: 완벽한 프로젝트 뼈대와 실무 의존성 설계 가이드

집을 지을 때 가장 중요한 것은 화려한 인테리어가 아니라 탄탄한 설계도와 뼈대(Foundation)입니다. 스프링 부트(Spring Boot) 개발 역시 마찬가지입니다. 처음에 프로젝트 뼈대를 어떻게 잡고, 빌드 도구를 무엇으로 선택하며, 어떤 라이브러리(Dependencies)들을 담고 시작하느냐에 따라 1년 뒤 프로젝트의 유지보수 난이도가 천차만별로 갈라집니다. 다행히도 스프링 진영은 개발자들이 손쉽게 뼈대를 짤 수 있도록 Spring Initializr(start.spring.io)라는 강력한 웹 기반의 제너레이터를 제공합니다.

이번 시리즈의 두 번째 포스팅에서는 수많은 옵션들 앞에서 헤매는 주니어 개발자들을 위해, 실무에서 100% 통용되는 프로젝트 구조 설계와 필수 의존성(Dependencies) 세팅 노하우에 대하여 다뤄보겠습니다.

🛠️ 1. Project, Language, Boot Version의 실무적 선택

Spring Initializr 웹사이트에 접속하면 가장 먼저 선택해야 할 커다란 분류들이 나타납니다.

• Project (빌드 도구): Gradle - Groovy (강력 권장)
  과거에는 XML 기반의 Maven을 많이 썼지만, 최근 국내 실무 표준은 압도적으로 Gradle입니다. 가독성이 좋고, 빌드 속도가 Maven보다 훨씬 빠르며(캐싱 및 증분 빌드 지원), 커스텀 빌드 스크립트 작성이 용이하기 때문입니다. Kotlin DSL도 떠오르고 있지만 아직은 Groovy DSL이 가장 무난한 선택입니다.
• Language: Java
  국내 백엔드 채용 시장의 90% 이상은 자바(Java) 기반입니다. 최근 Kotlin이 무섭게 치고 올라오고 있지만, 생태계의 압도적 크기와 레퍼런스를 고려할 때 입문자나 일반적인 실무 프로젝트는 여전히 Java 17을 권장합니다.
• Spring Boot Version: 3.x.x (최신 안정화 버전)
  버전 옆에 (SNAPSHOT)이나 (M2) 같은 글자가 안 붙어 있는 순수한 숫자(예: 3.2.3)를 선택해야 합니다. 앞서 01단계에서 강조했듯 3.x 버전은 Java 17 이상을 강제합니다.

📦 2. 절대 빠질 수 없는 실무 5대 필수 의존성 (Dependencies)

우측의 [ADD DEPENDENCIES] 버튼을 눌러 프로젝트에 담을 무기들을 선택할 차례입니다. 실무에서 가장 흔히 쓰이는 웹/DB API 서버를 기준으로 반드시 추가해야 할 5가지를 소개합니다.

1. Spring Web (핵심)
웹 애플리케이션을 만들기 위한 알파이자 오메가입니다. 이것을 추가하면 내장 톰캣(Tomcat) 서버, Spring MVC, RESTful API를 만들기 위한 핵심 어노테이션(@RestController, @GetMapping 등), JSON 직렬화를 위한 Jackson 라이브러리가 한 번에 싹 딸려옵니다.

2. Lombok (롬복)
자바의 고질적인 단점인 길고 장황한 Getter, Setter, 생성자 코드를 단 한 줄의 어노테이션(@Getter, @RequiredArgsConstructor)으로 끝내버리는 마법의 플러그인입니다. 실무 프로젝트 100곳 중 99곳이 사용합니다.

3. Spring Data JPA (데이터베이스 연결)
과거 MyBatis로 쿼리를 한 땀 한 땀 짜던 시절을 끝내버린 혁신적인 ORM 기술입니다. 자바 객체(Entity)를 만들면 JPA가 알아서 SQL로 변환하여 DB에 날려줍니다. 쿼리를 짜는 시간을 비즈니스 로직 고민하는 시간으로 바꿔줍니다.

4. H2 Database (개발/테스트용)
메모리(In-Memory) 기반의 초경량 관계형 데이터베이스입니다. 무거운 MySQL을 깔지 않아도 스프링 부트가 구동될 때 메모리에 임시 DB를 띄우고, 서버가 꺼지면 데이터가 날아갑니다. 초기 개발이나 단위 테스트(Unit Test)를 할 때 없어서는 안 될 소중한 도구입니다.

5. Validation (유효성 검증)
클라이언트가 API로 넘긴 이메일 형식이 맞는지, 패스워드가 8자리 이상인지 일일이 if(email == null) 코드로 검증하는 것은 하수입니다. @NotBlank, @Email 어노테이션으로 우아하게 입력값을 검증(Validation)하기 위한 필수 의존성입니다.

📁 3. 실무 디렉토리 패키지(Package) 구조 설계 전략

생성된 프로젝트를 인텔리제이(IntelliJ)로 열면 src/main/java 하위에 기본 패키지가 생깁니다. 실무에서는 이 패키지 구조를 어떻게 짤까요? 크게 두 가지 진영으로 나뉩니다.

1. 계층형 아키텍처 (Layered Architecture):
패키지 이름을 controller, service, repository, domain 등으로 나누고, 그 안에 모든 기능의 클래스들을 다 때려 넣는 방식입니다. 초보자가 이해하기 쉽지만, 프로젝트가 커져서 controller 패키지 안에 파일이 100개가 넘어가면 원하는 파일을 찾기 힘들어지는 지옥이 펼쳐집니다.

2. 도메인형 아키텍처 (Domain-driven Architecture) - 🌟 실무 권장:
기능(도메인)별로 패키지를 묶는 방식입니다. user, product, order라는 큰 패키지를 만들고, user 패키지 안에 UserController, UserService, UserEntity를 응집시켜 놓습니다. 내가 회원(User) 관련 코드를 수정해야 할 때 user 패키지만 열어보면 되므로 유지보수성이 극대화됩니다.

// 🌟 실무에서 가장 사랑받는 도메인 중심의 패키지 구조 예시
com.company.project
├── global              // 도메인과 무관한 전역 설정 (예외 처리, 시큐리티, 공통 유틸)
│   ├── config
│   ├── error
│   └── util
└── domain              // 각 비즈니스 로직을 도메인별로 완벽히 격리
    ├── member
    │   ├── api         // MemberController
    │   ├── application // MemberService
    │   └── domain      // MemberEntity, MemberRepository
    └── order
        ├── api
        ├── application
        └── domain

🎯 4. 마무리 및 다음 단계

지금까지 Spring Initializr를 통해 Gradle 빌드 환경을 구축하고, 실무에서 숨 쉬듯 쓰이는 5대 필수 의존성(Lombok, JPA 등)을 챙기며, 유지보수의 꽃이라 불리는 도메인 주도 패키지 디렉토리 설계법에 대해 3,000자 분량으로 아주 치밀하게 다루어 보았습니다. 이제 집을 짓기 위한 완벽한 뼈대와 도구 상자가 완성되었습니다.

뼈대가 만들어졌으니 이제 브라우저의 요청(Request)을 받아 처리하고 응답(Response)을 내려주는 웹 서버의 심장을 만들어야 합니다. 백엔드 개발자라면 자다가도 벌떡 일어나서 설명할 수 있어야 하는 절대적인 패턴이 있습니다. 이어지는 03단계 포스팅에서는 "클라이언트의 요청이 들어와서 DB를 거쳐 응답으로 나갈 때까지의 완벽한 흐름!" Spring Boot MVC 패턴 완벽 해부 (Controller, Service, Repository의 명확한 역할 분담)에 대해 아주 꼼꼼하게 파헤쳐 보겠습니다!