자바 백엔드 입문 10편 — Maven·Gradle 의존성 관리

이 글은 자바 백엔드 입문 시리즈 59편 중 10편이에요. Phase 0 자바 기초의 마지막 글이고, 4편에서 어노테이션을 잡았다면, 이번 10편은 "Spring을 도대체 어떻게 프로젝트에 끌어오는가" 의 답인 의존성 관리 도구 — Maven과 Gradle을 잡습니다. 6편부터 본격적으로 Spring을 다룰 때 필요한 마지막 퍼즐이에요.

의존성 관리가 어렵게 들리는 이유

처음 자바 프로젝트 코드를 받으면 pom.xml 이나 build.gradle 이라는 파일이 박혀 있어요. 이게 뭔가 했더니 "의존성" 이라는 단어가 매번 등장해요. 두 가지가 헷갈립니다.

첫째, "의존성"이라는 단어 자체가 추상적이에요. "무엇이 무엇에 의존한다" 가 코드에서 어떤 그림으로 나타나는지 안 잡혀요.

둘째, Maven과 Gradle이라는 두 도구가 비슷하면서 다른 게 있어요. 어느 걸 골라야 하나? 둘 다 알아야 하나? 입문자가 자주 막히는 부분입니다.

이 글에서는 의존성 관리 = 자바 라이브러리 쇼핑 카트 비유로 풀어 갑니다. 끝까지 따라오시면 pom.xml·build.gradle 파일이 단순한 "쇼핑 목록" 으로 보이게 됩니다.

의존성이 뭔가 — 한 줄 정의

의존성(Dependency) 은 "내 프로젝트가 동작하려면 이 외부 코드가 필요하다" 는 관계예요. Spring으로 백엔드를 만들려면 Spring 코드를 가져와야 하고, JSON을 다루려면 Jackson 라이브러리가 필요하고, DB에 접속하려면 PostgreSQL JDBC 드라이버가 필요해요. 이 "내 프로젝트가 의존하는 외부 라이브러리들" 이 의존성이에요.

옛날엔 어떻게 했나? 라이브러리 사이트에 들어가서 .jar 파일을 직접 다운로드 → 프로젝트 폴더에 복사 → 또 그 라이브러리가 다른 라이브러리를 필요로 하면 그것도 다운로드 → ... 이게 정말 끔찍한 작업이었어요. 한 프로젝트에 라이브러리 50개가 박힌다면 50번 사이트 들어가서 다운로드해야 했죠. 게다가 라이브러리 A 1.2 버전이 라이브러리 B 0.9 버전을 필요로 하는데, 다른 라이브러리 C는 B 1.1 버전을 요구하면 — 버전 충돌 지옥이 펼쳐졌어요.

이걸 자동으로 해주는 게 의존성 관리 도구예요. Maven·Gradle은 "내가 필요한 라이브러리 이름만 적어두면, 알아서 인터넷에서 다운로드하고, 그 라이브러리가 필요한 다른 라이브러리도 자동으로 끌어오고, 버전 충돌도 가능한 한 자동으로 해결해 주는" 도구예요.

한 줄 정리 — 의존성 관리 도구 = 자바 라이브러리 자동 쇼핑·설치 시스템. 쇼핑 목록만 적으면 알아서 카트에 다 담아 줌.

Maven — 가장 오래된 표준

Maven은 2004년에 등장한 가장 오래된 자바 의존성 관리 도구예요. 설정 파일은 pom.xml 이고 XML 형식이에요. "Project Object Model" 의 약자.

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.smartlifen4n</groupId>
    <artifactId>my-app</artifactId>
    <version>1.0.0</version>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>3.2.0</version>
        </dependency>
        <dependency>
            <groupId>org.postgresql</groupId>
            <artifactId>postgresql</artifactId>
            <version>42.7.0</version>
        </dependency>
    </dependencies>
</project>

이 파일이 "쇼핑 목록" 이에요. "Spring Boot Web 3.2.0 한 박스, PostgreSQL 드라이버 42.7.0 한 박스" 라고 적어두면, mvn install 명령 한 번에 Maven이 인터넷(Maven Central 저장소)에서 알아서 다 받아와요. 그 라이브러리들이 필요한 또 다른 라이브러리(예: Spring Web이 필요로 하는 Jackson)도 자동으로 함께 받아옵니다.

Maven은 컨벤션이 강한 도구예요. "소스 코드는 src/main/java, 테스트 코드는 src/test/java, 리소스는 src/main/resources" 같은 폴더 구조가 정해져 있어요. 이 컨벤션을 따라야 Maven이 알아서 처리합니다.

Gradle — 더 빠른 차세대 도구

Gradle은 2007년에 등장한 더 새로운 도구예요. 설정 파일은 build.gradle (또는 Kotlin DSL로 build.gradle.kts) 이고, XML이 아니라 Groovy/Kotlin 스크립트 형식이에요.

plugins {
    id 'org.springframework.boot' version '3.2.0'
    id 'java'
}

group = 'com.smartlifen4n'
version = '1.0.0'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.postgresql:postgresql:42.7.0'
}

같은 의존성을 적어도 Maven 대비 줄 수가 훨씬 짧아요. 또 빌드 속도가 Maven보다 훨씬 빠릅니다(증분 빌드·캐싱 최적화 덕분).

Gradle은 유연성이 강한 도구예요. 빌드 스크립트가 그냥 텍스트가 아니라 "실행 가능한 코드" 라서 "조건에 따라 다른 라이브러리 끌어오기", "커스텀 빌드 단계 만들기" 같은 게 가능해요.

여기서 시험 함정 하나 있어요. "Maven과 Gradle 중 무엇이 더 좋은가?" 가 면접 단골인데, 답은 "상황에 따라 다르다" 가 정답이에요. 정확히 말하면 신규 프로젝트는 Gradle, 레거시·전통적 회사는 Maven 이 일반적인 흐름입니다. Spring Boot 공식 가이드도 Gradle을 더 권장하는 분위기예요.

Maven vs Gradle 비교표

구분	Maven	Gradle
등장	2004	2007
설정 파일	pom.xml	build.gradle 또는 .kts
형식	XML (선언적)	Groovy/Kotlin 스크립트 (실행 가능 코드)
줄 수	길고 verbose	짧고 간결
빌드 속도	느림 (전체 재빌드)	빠름 (증분 빌드 + 캐싱)
유연성	컨벤션 강제, 유연성 낮음	코드라 유연성 매우 높음
학습 곡선	완만 (XML만 알면 됨)	약간 가파름 (Groovy 또는 Kotlin 지식 필요)
한국 회사 비율	레거시·은행·통신사 강세	스타트업·신규 프로젝트 강세

start.spring.io — 의존성 관리의 가장 친숙한 입구

자바 백엔드 입문자가 가장 자주 만나는 도구는 start.spring.io 예요. Spring 공식 사이트인데, Spring Boot 프로젝트의 초기 골격을 자동으로 만들어 줍니다.

들어가서 "Maven vs Gradle", "Java 17 vs 21", "필요한 의존성(Spring Web·JPA·PostgreSQL Driver...)" 을 체크하면 — 그 모든 설정이 박힌 프로젝트 zip 파일을 한 방에 받을 수 있어요. 처음 자바 백엔드 만들 때 "맨바닥부터 pom.xml 짜야 하나" 걱정 안 해도 돼요. start.spring.io에서 받은 골격으로 시작하면 됩니다.

6편이 바로 그 "start.spring.io로 첫 프로젝트 만들기" 글이에요. Phase 0이 끝나고 Phase 1 Spring 시작으로 넘어가는 다리.

의존성 스코프 — 짧게 미리보기

의존성 스코프(Scope) 라는 개념이 한 번 등장하는데, 짧게만 짚고 넘어갈게요. "이 라이브러리가 언제 필요한가" 를 명시하는 거예요.

JUnit 같은 테스트 라이브러리를 test 스코프로 박아두면, 실제 배포되는 .jar 파일에 테스트 코드가 안 들어가요. 가볍게 만들 수 있는 거죠. 입문 단계에서는 "이런 게 있다" 정도면 충분해요.

한 줄 정리 — Maven·Gradle은 "라이브러리 쇼핑 카트" + "빌드 자동화" 두 가지 일을 같이 함. 입문은 Gradle 추천, 레거시는 Maven.

시험 직전 한 번 더 — Maven·Gradle 입문자가 매번 헷갈리는 것

• 의존성(Dependency) = 내 프로젝트가 동작하기 위해 필요한 외부 라이브러리
• 의존성 관리 도구 = 라이브러리 자동 다운로드·버전 관리·빌드 자동화
• 자바 양대 도구 = Maven(2004, XML) + Gradle(2007, Groovy/Kotlin 스크립트)
• Maven 설정 파일 = pom.xml
• Gradle 설정 파일 = build.gradle (Groovy) 또는 build.gradle.kts (Kotlin DSL)
• 둘 다 Maven Central 같은 중앙 저장소에서 라이브러리 받아옴
• 라이브러리는 groupId:artifactId:version 3개 좌표로 식별 (예: org.springframework.boot:spring-boot-starter-web:3.2.0)
• "의존성의 의존성" 도 자동으로 끌어옴 (transitive dependency)
• 같은 라이브러리 여러 버전 충돌 시 Maven·Gradle이 자동으로 한 버전 선택
• Maven 빌드 명령 = mvn install·mvn package·mvn test
• Gradle 빌드 명령 = gradle build·gradlew build (wrapper 사용)
• gradlew/mvnw = wrapper. 시스템에 Gradle·Maven 안 깔려 있어도 동작
• Gradle이 Maven보다 빌드 속도 빠름 — 증분 빌드 + 캐싱 덕분
• Maven은 컨벤션 강제 (소스 src/main/java), Gradle은 유연
• start.spring.io = Spring Boot 프로젝트 골격 자동 생성. 입문자가 가장 먼저 만나는 사이트
• Spring Boot 공식은 Gradle을 더 권장
• 한국 회사 — 레거시·은행·통신사 = Maven 강세, 스타트업·신규 프로젝트 = Gradle 강세
• 둘 다 알면 좋지만, 한 도구 먼저 마스터 후 다른 도구 적응이 효율적
• 의존성 스코프 — compile(기본)·runtime·test·provided 네 가지
• IntelliJ·Eclipse는 pom.xml·build.gradle 자동 인식 — 손으로 라이브러리 추가 안 해도 됨

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

• 5편 — 자바 컬렉션 List Set Map
• 6편 — 자바 제네릭
• 7편 — 자바 예외 처리
• 8편 — 자바 Optional null 안전
• 9편 — 자바 Stream API 람다

다음 글:

• 11편 — Spring Framework란
• 12편 — start.spring.io 첫 프로젝트
• 13편 — application.yml Spring Profiles
• 14편 — 첫 Bean 만들기 Hello Spring
• 15편 — 의존성 주입이 왜 필요한가