sbt

빌드 정의 파일인 build.sbt는 sbt 프로젝트의 핵심 구성 요소이다. 이 파일은 스칼라 문법의 일부를 사용하여 작성되며, 프로젝트의 이름, 버전, 사용하는 스칼라 버전, 라이브러리 의존성 등 프로젝트의 메타데이터와 빌드 설정을 정의한다. build.sbt 파일은 일반적으로 프로젝트 루트 디렉토리에 위치하며, sbt는 이 파일을 읽어 빌드 과정을 구성하고 실행한다.

build.sbt 파일의 기본 구조는 키-값 쌍의 설정 표현식으로 이루어져 있다. 주요 설정 키로는 name(프로젝트 이름), version(프로젝트 버전), scalaVersion(사용할 스칼라 컴파일러 버전), libraryDependencies(프로젝트가 필요로 하는 외부 라이브러리 목록) 등이 있다. 각 설정은 := 연산자를 사용하여 값을 할당하며, 여러 설정은 빈 줄로 구분하여 나열한다. 예를 들어, 아파치 스파크나 플레이 프레임워크와 같은 라이브러리를 추가할 때 libraryDependencies 키에 의존성을 명시한다.

sbt는 빌드 자동화를 위해 이 파일을 기반으로 의존성 그래프를 해석하고, 필요한 JAR 파일을 메이븐이나 아이비 같은 저장소에서 자동으로 다운로드한다. 또한 build.sbt는 멀티 프로젝트 빌드를 구성하는 데에도 사용될 수 있으며, 서브 프로젝트마다 별도의 설정을 가질 수 있다. 이 파일의 내용이 변경되면 sbt는 관련된 설정을 자동으로 다시 로드하여 변경 사항을 반영한다.

sbt 프로젝트의 기본 구조는 Maven과 Gradle과 같은 다른 빌드 도구와 유사한 관례를 따르며, 스칼라 프로젝트에 특화된 몇 가지 특징을 가지고 있다. 표준 프로젝트 레이아웃은 src/main/scala 디렉터리에 주요 소스 코드를, src/test/scala 디렉터리에 단위 테스트 코드를 위치시킨다. 또한 자바 코드를 함께 사용하는 경우를 위해 src/main/java와 src/test/java 디렉터리도 지원한다. 프로젝트 루트에는 빌드 정의를 담은 build.sbt 파일과 프로젝트 메타데이터를 포함하는 project 디렉터리가 필수적으로 존재한다.

project 디렉터리는 sbt 자체의 빌드를 정의하는 공간으로, 여기에 위치한 .scala 파일이나 .sbt 파일은 메인 빌드 정의를 보조하거나 확장하는 역할을 한다. 대표적으로 project/plugins.sbt 파일을 통해 sbt 플러그인을 추가하고, project/build.properties 파일을 통해 사용할 sbt 버전을 고정할 수 있다. 이 디렉터리 내부의 코드는 메인 프로젝트의 클래스패스에 자동으로 포함되지 않으며, 오직 빌드 정의 과정에서만 사용된다.

빌드 결과물은 기본적으로 target 디렉터리에 생성된다. 이 디렉터리에는 컴파일된 클래스 파일, 의존성으로 다운로드한 라이브러리(아이비 캐시), 생성된 패키지 파일(예: JAR 파일), 그리고 테스트 리포트 등이 저장된다. sbt는 증분 컴파일을 지원하여 이전 빌드 결과를 target 디렉터리 내에 보관하고, 변경된 소스 파일만 다시 컴파일함으로써 빌드 시간을 단축한다.

sbt의 핵심 동작 원리는 태스크와 설정이라는 두 가지 기본 개념을 중심으로 이루어진다. 이들은 빌드의 모든 측면을 정의하고 제어하는 구성 요소이다.

태스크는 빌드 과정에서 수행되는 작업 단위이다. 예를 들어, 소스 코드를 컴파일하거나(compile), 테스트를 실행하거나(test), 프로젝트를 패키징하는(package) 작업이 태스크에 해당한다. 각 태스크는 실행될 때 특정 값을 산출하며, 이 값은 다른 태스크의 입력으로 사용될 수 있다. 태스크는 순수 함수의 특성을 가지며, 입력이 동일하면 항상 동일한 결과를 반환하고 부작용이 없다는 점이 특징이다. 사용자는 sbt shell에서 직접 태스크 이름을 입력하여 실행하거나, 다른 태스크나 설정에 의존하도록 정의할 수 있다.

반면, 설정은 빌드의 정적인 속성이나 값을 정의한다. 프로젝트의 이름(name), 버전(version), 사용하는 스칼라 버전(scalaVersion), 외부 라이브러리 의존성(libraryDependencies) 등이 대표적인 설정 키이다. 설정은 빌드가 시작될 때 한 번 평가되며, 태스크와 달리 실행 시점에 매번 재평가되지 않는다. 설정 키는 sbt에 의해 미리 정의된 것도 있고, 사용자가 필요에 따라 새로 정의할 수도 있다.

태스크와 설정은 모두 키-값 쌍의 형태로 관리되며, 빌드 정의 파일인 build.sbt나 project/ 디렉토리의 스칼라 파일을 통해 정의되고 조작된다. 이들 간의 관계는 의존성 그래프로 표현되는데, 하나의 태스크가 실행되기 위해서는 먼저 그 태스크가 의존하는 다른 태스크나 설정이 먼저 평가되어야 한다. sbt는 이 의존성 그래프를 분석하여 작업을 최적화하고, 변경되지 않은 부분은 재실행하지 않는 등의 증분 컴파일 및 증분 실행 기능을 제공하여 빌드 성능을 높인다.

sbt를 사용한 프로젝트 생성은 sbt new 명령어를 통해 이루어진다. 이 명령은 Giter8이라는 템플릿 시스템을 사용하여 미리 정의된 프로젝트 구조를 생성한다. 사용자는 다양한 공식 및 커뮤니티 템플릿 중 하나를 선택할 수 있으며, 가장 일반적인 것은 Lightbend에서 제공하는 Scala 애플리케이션용 scala/hello-world.g8 템플릿이다. 명령어를 실행하면 템플릿에 필요한 몇 가지 변수(예: 프로젝트 이름)를 입력받은 후, 표준 디렉토리 구조와 기본 build.sbt 파일을 포함한 프로젝트를 생성한다.

생성된 프로젝트 디렉토리 내에서 sbt 명령을 실행하면 대화형 셸 모드로 진입한다. 이 셸에서 compile을 입력하면 소스 코드를 컴파일하고, run을 입력하면 메인 클래스를 찾아 애플리케이션을 실행한다. test 명령은 src/test/scala 디렉토리에 작성된 단위 테스트를 실행하여 코드의 정확성을 검증한다. 또한 package 명령을 실행하면 컴파일된 클래스 파일과 리소스를 JAR 파일로 패키징하여 배포 준비를 완료한다.

이러한 기본 작업들은 build.sbt 파일에 정의된 프로젝트 설정에 따라 수행된다. 사용자는 이 파일에서 프로젝트 이름, 버전, 사용할 스칼라 버전, 외부 라이브러리 의존성 등을 선언적으로 관리할 수 있다. sbt는 Apache Ivy를 기반으로 한 강력한 의존성 해결 메커니즘을 갖추고 있어, 선언된 의존성과 그 전이적 의존성들을 자동으로 다운로드하고 관리한다.

sbt는 의존성 관리를 위해 Apache Ivy를 내부적으로 활용한다. 이를 통해 Maven 중앙 저장소를 비롯한 다양한 원격 저장소와 로컬 저장소에서 라이브러리를 자동으로 해결하고 다운로드할 수 있다. 빌드 정의 파일인 build.sbt에서는 libraryDependencies 설정 키를 사용하여 프로젝트가 필요로 하는 의존성을 선언한다.

의존성은 Maven의 좌표 체계를 따르며, "그룹ID" % "아티팩트ID" % "버전" 형식으로 지정한다. 스칼라 라이브러리의 경우, 특정 스칼라 버전에 컴파일된 바이너리를 명시하기 위해 %% 연산자를 사용한다. 예를 들어, "org.scalatest" %% "scalatest" % "3.2.18"과 같이 선언하면 sbt는 프로젝트의 스칼라 버전에 맞는 적절한 JAR 파일을 가져온다. 의존성의 범위는 % 뒤에 "test", "provided"와 같은 설정을 추가하여 지정할 수 있다.

sbt는 전이적 의존성도 자동으로 관리한다. 즉, 프로젝트에 직접 추가한 라이브러리가 필요로 하는 다른 라이브러리들까지 재귀적으로 분석하여 함께 다운로드한다. 이를 통해 의존성 지옥 문제를 효과적으로 피할 수 있다. 의존성 목록은 sbt update 명령을 실행하거나 sbt 셸에서 update 태스크를 실행하여 실제로 해결하고 다운로드할 수 있으며, 다운로드된 라이브러리는 기본적으로 사용자의 홈 디렉토리 아래 .ivy2/cache에 저장된다.

sbt는 대화형 셸을 제공하여, 사용자가 명령줄 인터페이스에서 직접 빌드 작업을 실행하고 프로젝트 상태를 탐색할 수 있게 한다. 이 셸은 단순히 명령을 실행하는 것을 넘어, 프로젝트의 설정을 실시간으로 확인하고 수정하는 데에도 활용된다. 사용자는 sbt 명령어만 입력하면 프로젝트 디렉토리에서 이 대화형 환경에 진입할 수 있다.

sbt 셸 내에서는 다양한 내장 명령어를 사용할 수 있다. 예를 들어, compile 명령은 소스 코드를 컴파일하고, run 명령은 메인 클래스를 실행하며, test 명령은 작성된 단위 테스트를 수행한다. 또한 console 명령을 통해 스칼라 REPL 환경을 프로젝트의 클래스패스와 함께 바로 시작할 수 있어, 코드 조각을 빠르게 테스트하는 데 유용하다. reload 명령은 빌드 정의 파일의 변경 사항을 반영하기 위해 sbt를 재시작한다.

이 대화형 모드는 빌드 자동화 작업의 반복성을 줄여주는 데 큰 장점이 있다. 사용자는 한 번 sbt 셸을 시작한 후, 코드를 수정하고 ~compile 같은 접두사 명령을 사용하여 파일이 변경될 때마다 자동으로 컴파일을 트리거하는 식으로 효율적으로 작업할 수 있다. 또한, projects 명령으로 멀티 프로젝트 빌드 환경에서의 모든 하위 프로젝트를 나열하거나, project <프로젝트명> 명령으로 작업 중인 프로젝트를 전환할 수 있다.

sbt 셸은 탭 완성 기능을 지원하여 명령어나 설정 키를 쉽게 입력할 수 있도록 돕는다. 또한, help 명령을 통해 사용 가능한 모든 명령어에 대한 설명을 확인할 수 있어, 사용자 친화적인 환경을 제공한다. 이처럼 sbt의 대화형 셸은 프로젝트 개발과 빌드 과정을 통합적으로 관리하는 핵심 인터페이스 역할을 한다.

멀티 프로젝트 빌드는 하나의 빌드 정의 내에서 여러 개의 상호 연결된 프로젝트를 관리하는 sbt의 핵심 기능이다. 이 방식을 통해 대규모 코드베이스를 논리적으로 분리된 모듈로 구성하고, 모듈 간의 의존성을 명확히 정의하며, 전체 또는 일부 모듈만을 선택적으로 빌드할 수 있다. 이는 특히 마이크로서비스 아키텍처나 라이브러리와 이를 사용하는 애플리케이션을 함께 관리할 때 유용하다.

멀티 프로젝트 빌드는 주로 루트 디렉토리의 build.sbt 파일에서 lazy val로 각 프로젝트를 정의하고, project 디렉토리의 .scala 파일에서 더 복잡한 구성을 작성하는 방식으로 설정된다. 각 하위 프로젝트는 독립적인 소스 디렉토리(src/main/scala), 의존성, 빌드 설정을 가질 수 있다. 프로젝트 간의 의존성은 dependsOn 메서드를 사용하여 선언하며, 이를 통해 컴파일 타임과 런타임 클래스패스가 자동으로 관리된다.

sbt 셸에서 projects 명령어를 실행하면 정의된 모든 프로젝트 목록을 확인할 수 있으며, project [프로젝트명] 명령으로 작업할 프로젝트를 전환하거나, [프로젝트명]/compile과 같은 방식으로 특정 프로젝트의 태스크를 실행할 수 있다. 이 구조는 의존성 주입과 모듈화 원칙을 빌드 과정에 적용하여 소프트웨어의 복잡성을 체계적으로 관리하는 데 기여한다.

sbt의 기능은 플러그인을 통해 크게 확장된다. 플러그인은 빌드 자동화 과정에서 반복적으로 필요한 작업을 캡슐화한 재사용 가능한 모듈이다. 이를 통해 사용자는 의존성 관리, 코드 품질 검사, 패키징, 다양한 프레임워크 통합 등 복잡한 빌드 로직을 쉽게 프로젝트에 추가할 수 있다. sbt 생태계에는 공식적으로 제공되는 핵심 플러그인과 커뮤니티에서 개발한 수많은 서드파티 플러그인이 존재한다.

플러그인을 사용하려면 프로젝트의 project/plugins.sbt 파일에 해당 플러그인의 의존성을 선언하기만 하면 된다. 예를 들어, 스칼라 프로젝트를 Eclipse 통합 개발 환경에서 사용할 수 있게 해주는 sbt-eclipse 플러그인이나, sbt-native-packager를 통해 다양한 형식(DEB, RPM, Docker 이미지 등)으로 애플리케이션을 패키징하는 것이 대표적이다. 일부 플러그인은 전역 설정을 통해 사용자의 모든 프로젝트에 적용되도록 구성할 수도 있다.

사용자는 필요에 따라 자신만의 커스텀 플러그인을 개발할 수도 있다. sbt는 플러그인 개발을 위한 명확한 API를 제공하며, 플러그인은 태스크, 설정, 명령어 등을 정의하여 sbt의 빌드 정의에 새로운 기능을 주입한다. 이는 특히 대규모 조직이나 특정 기술 스택을 공유하는 여러 프로젝트에서 빌드 표준화와 생산성 향상에 기여한다.

sbt에서는 사용자가 자신의 필요에 맞게 빌드 과정을 확장하고 제어하기 위해 커스텀 태스크와 커스텀 설정을 정의할 수 있다. 이는 표준 빌드 라이프사이클에 포함되지 않은 특정 작업을 자동화하거나, 프로젝트 고유의 설정 키를 만들어 빌드 로직을 더욱 유연하게 구성하는 데 사용된다. 이러한 기능은 sbt의 강력한 표현력과 도메인 특화 언어의 이점을 활용하여 복잡한 빌드 요구사항을 충족시키는 핵심 메커니즘이다.

커스텀 태스크는 taskKey를 사용하여 정의하며, 태스크의 구현은 스칼라 코드로 작성된다. 예를 들어, 특정 디렉토리를 정리하거나 사용자 정의 보고서를 생성하는 태스크를 만들 수 있다. 태스크는 다른 태스크나 설정의 값을 입력으로 받아 계산을 수행하고 결과를 반환할 수 있으며, :=, +=, ++= 같은 연산자를 통해 의존성과 실행 순서를 정의한다. 반면, 커스텀 설정은 settingKey로 정의되며, 주로 빌드 중에 한 번 계산되어 프로젝트 전반에 사용될 값을 저장하는 데 적합하다.

이러한 커스텀 정의는 주로 프로젝트 루트의 build.sbt 파일이나 프로젝트의 project/ 디렉토리 내부의 .scala 파일에 작성된다. 특히 복잡한 로직이나 재사용 가능한 모듈을 만들 때는 sbt 플러그인 형태로 패키징하는 것이 일반적이다. 플러그인을 작성하면 여러 프로젝트에서 동일한 커스텀 태스크와 설정을 쉽게 공유하고 적용할 수 있어 빌드 인프라의 일관성을 유지하는 데 도움이 된다.

sbt의 빌드 정의는 키와 값의 맵으로 구성된 지속적 평가 모델을 기반으로 하므로, 커스텀 태스크와 설정도 이 모델에 완전히 통합된다. 이는 태스크 간의 의존성과 자동화된 증분 컴파일 및 파일 감시 기능을 활용할 수 있게 해준다. 결과적으로, 개발자는 표준화된 컴파일, 테스트, 패키징 작업 외에도 프로젝트 특화된 자동화 워크플로우를 구축하여 개발 생산성을 크게 향상시킬 수 있다.