[Spring Boot 번역] Developer Tools

출처: https://docs.spring.io/spring-boot/4.0-SNAPSHOT/reference/using/devtools.html

이 버전은 아직 개발 중이며 안정적인 것으로 간주되지 않습니다. 최신 안정 버전은 Spring Boot 3.5.6을 사용하세요!

Developer Tools

Spring Boot는 애플리케이션 개발 경험을 좀 더 쾌적하게 만들 수 있는 추가 도구 세트를 포함하고 있습니다. spring-boot-devtools 모듈은 추가 개발 시간 기능을 제공하기 위해 모든 프로젝트에 포함될 수 있습니다. devtools 지원을 포함하려면 다음 Maven 및 Gradle 목록에 표시된 대로 빌드에 모듈 의존성을 추가하세요:

Maven

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-devtools</artifactId>
        <optional>true</optional>
    </dependency>
</dependencies>

Gradle

dependencies {
    developmentOnly("org.springframework.boot:spring-boot-devtools")
}

Devtools는 특히 다중 모듈 프로젝트에서 클래스 로딩 문제를 일으킬 수 있습니다. Diagnosing Classloading Issues에서 진단 및 해결 방법을 설명합니다.

개발자 도구는 완전히 패키징된 애플리케이션을 실행할 때 자동으로 비활성화됩니다. 애플리케이션이 java -jar에서 시작되거나 특수 클래스로더에서 시작되면 "프로덕션 애플리케이션"으로 간주됩니다. spring.devtools.restart.enabled 시스템 속성을 사용하여 이 동작을 제어할 수 있습니다. 애플리케이션을 시작하는 데 사용되는 클래스로더에 관계없이 devtools를 활성화하려면 -Dspring.devtools.restart.enabled=true 시스템 속성을 설정하세요. devtools 실행이 보안 위험인 프로덕션 환경에서는 이 작업을 수행하면 안 됩니다. devtools를 비활성화하려면 의존성을 제외하거나 -Dspring.devtools.restart.enabled=false 시스템 속성을 설정하세요.

Maven에서 의존성을 optional로 플래그 지정하거나 Gradle에서 developmentOnly 구성을 사용하면(위에 표시된 대로) devtools가 프로젝트를 사용하는 다른 모듈에 전이적으로 적용되는 것을 방지합니다.

재패키징된 아카이브에는 기본적으로 devtools가 포함되어 있지 않습니다. 특정 원격 devtools 기능을 사용하려면 포함해야 합니다. Maven 플러그인을 사용할 때는 excludeDevtools 속성을 false로 설정하세요. Gradle 플러그인을 사용할 때는 developmentOnly 구성을 포함하도록 작업의 클래스 경로를 구성하세요.

Diagnosing Classloading Issues

Restart vs Reload 섹션에서 설명한 대로 재시작 기능은 두 개의 클래스로더를 사용하여 구현됩니다. 대부분의 애플리케이션에서 이 접근 방식은 잘 작동합니다. 그러나 특히 다중 모듈 프로젝트에서 때때로 클래스 로딩 문제를 일으킬 수 있습니다.

클래스 로딩 문제가 실제로 devtools와 두 개의 클래스로더로 인해 발생하는지 진단하려면 재시작을 비활성화해 보세요. 이것이 문제를 해결한다면 전체 프로젝트를 포함하도록 재시작 클래스로더를 사용자 정의하세요.

Property Defaults

Spring Boot에서 지원하는 여러 라이브러리는 성능 향상을 위해 캐시를 사용합니다. 예를 들어, 템플릿 엔진은 템플릿 파일을 반복적으로 구문 분석하지 않도록 컴파일된 템플릿을 캐시합니다. 또한 Spring MVC는 정적 리소스를 제공할 때 응답에 HTTP 캐싱 헤더를 추가할 수 있습니다.

캐싱은 프로덕션에서 매우 유익하지만 개발 중에는 역효과를 낳을 수 있으며 애플리케이션에서 방금 변경한 내용을 볼 수 없게 할 수 있습니다. 이러한 이유로 spring-boot-devtools는 기본적으로 캐싱 옵션을 비활성화합니다.

캐시 옵션은 일반적으로 application.properties 파일의 설정으로 구성됩니다. 예를 들어, Thymeleaf는 spring.thymeleaf.cache 속성을 제공합니다. 이러한 속성을 수동으로 설정할 필요 없이 spring-boot-devtools 모듈은 합리적인 개발 시간 구성을 자동으로 적용합니다.

다음 표는 적용되는 모든 속성을 나열합니다:

Name	Default Value
server.error.include-binding-errors	always
server.error.include-message	always
server.error.include-stacktrace	always
server.servlet.jsp.init-parameters.development	true
server.servlet.session.persistent	true
spring.docker.compose.readiness.wait	only-if-started
spring.freemarker.cache	false
spring.graphql.graphiql.enabled	true
spring.groovy.template.cache	false
spring.h2.console.enabled	true
spring.mustache.servlet.cache	false
spring.mvc.log-resolved-exception	true
spring.reactor.netty.shutdown-quiet-period	0s
spring.template.provider.cache	false
spring.thymeleaf.cache	false
spring.web.resources.cache.period	0
spring.web.resources.chain.cache	false

속성 기본값을 적용하지 않으려면 application.properties에서 spring.devtools.add-properties를 false로 설정할 수 있습니다.

Spring MVC 및 Spring WebFlux 애플리케이션을 개발하는 동안 웹 요청에 대한 더 많은 정보가 필요하기 때문에 개발자 도구는 web 로깅 그룹에 대해 DEBUG 로깅을 활성화할 것을 제안합니다. 이렇게 하면 들어오는 요청, 처리하는 핸들러, 응답 결과 및 기타 세부 정보에 대한 정보를 얻을 수 있습니다. 모든 요청 세부 정보(잠재적으로 민감한 정보 포함)를 로깅하려면 spring.mvc.log-request-details 또는 spring.http.codecs.log-request-details 구성 속성을 켤 수 있습니다.

Automatic Restart

spring-boot-devtools를 사용하는 애플리케이션은 클래스 경로의 파일이 변경될 때마다 자동으로 재시작됩니다. 이는 IDE에서 작업할 때 코드 변경에 대한 매우 빠른 피드백 루프를 제공하므로 유용한 기능일 수 있습니다. 기본적으로 디렉토리를 가리키는 클래스 경로의 모든 항목은 변경 사항이 모니터링됩니다. 정적 자산 및 뷰 템플릿과 같은 특정 리소스는 애플리케이션을 재시작할 필요가 없습니다.

Triggering a restart

DevTools는 클래스 경로 리소스를 모니터링하므로 재시작을 트리거하는 유일한 방법은 클래스 경로를 업데이트하는 것입니다. IDE 또는 빌드 플러그인 중 하나를 사용하든 수정된 파일을 재컴파일하여 재시작을 트리거해야 합니다. 클래스 경로를 업데이트하는 방법은 사용 중인 도구에 따라 다릅니다:

Eclipse에서는 수정된 파일을 저장하면 클래스 경로가 업데이트되고 재시작이 트리거됩니다.
IntelliJ IDEA에서는 프로젝트를 빌드(Build -> Build Project)하면 동일한 효과가 있습니다.
빌드 플러그인을 사용하는 경우 Maven의 경우 mvn compile을 실행하거나 Gradle의 경우 gradle build를 실행하면 재시작이 트리거됩니다.

빌드 플러그인을 사용하여 Maven 또는 Gradle로 재시작하는 경우 forking을 enabled로 설정해야 합니다. forking을 비활성화하면 devtools에서 사용하는 격리된 애플리케이션 클래스로더가 생성되지 않으며 재시작이 제대로 작동하지 않습니다.

자동 재시작은 LiveReload와 함께 사용하면 매우 잘 작동합니다. 자세한 내용은 LiveReload 섹션을 참조하세요. JRebel을 사용하는 경우 동적 클래스 리로딩을 위해 자동 재시작이 비활성화됩니다. 다른 devtools 기능(예: LiveReload 및 속성 재정의)은 계속 사용할 수 있습니다.

DevTools는 재시작 중에 애플리케이션 컨텍스트의 종료 후크를 사용하여 닫습니다. 종료 후크를 비활성화한 경우(SpringApplication.setRegisterShutdownHook(false)) 제대로 작동하지 않습니다.

DevTools는 ApplicationContext에서 사용하는 ResourceLoader를 사용자 정의해야 합니다. 애플리케이션이 이미 제공하는 경우 래핑됩니다. ApplicationContext에서 getResource 메서드의 직접 재정의는 지원되지 않습니다.

AspectJ 위빙을 사용할 때는 자동 재시작이 지원되지 않습니다.

Restart vs Reload

Spring Boot에서 제공하는 재시작 기술은 두 개의 클래스로더를 사용하여 작동합니다. 변경되지 않는 클래스(예: 타사 jar의 클래스)는 base 클래스로더에 로드됩니다. 적극적으로 개발 중인 클래스는 restart 클래스로더에 로드됩니다. 애플리케이션이 재시작되면 restart 클래스로더가 삭제되고 새로운 클래스로더가 생성됩니다. 이 접근 방식은 base 클래스로더가 이미 사용 가능하고 채워져 있으므로 애플리케이션 재시작이 일반적으로 "콜드 스타트"보다 훨씬 빠르다는 것을 의미합니다.

재시작이 애플리케이션에 충분히 빠르지 않거나 클래스 로딩 문제가 발생하는 경우 ZeroTurnaround의 JRebel과 같은 리로딩 기술을 고려할 수 있습니다. 이들은 로드될 때 클래스를 다시 작성하여 리로딩에 더 적합하게 만듭니다.

Logging Changes in Condition Evaluation

기본적으로 애플리케이션이 재시작될 때마다 조건 평가 델타를 보여주는 보고서가 기록됩니다. 이 보고서는 Bean을 추가 또는 제거하고 구성 속성을 설정하는 등의 변경을 수행할 때 애플리케이션의 자동 구성 변경 사항을 보여줍니다.

보고서 로깅을 비활성화하려면 다음 속성을 설정하세요:

Properties

spring.devtools.restart.log-condition-evaluation-delta=false

YAML

spring:
  devtools:
    restart:
      log-condition-evaluation-delta: false

Excluding Resources

특정 리소스는 변경될 때 반드시 재시작을 트리거할 필요가 없습니다. 예를 들어, Thymeleaf 템플릿은 제자리에서 편집할 수 있습니다. 기본적으로 /META-INF/maven, /META-INF/resources, /resources, /static, /public 또는 /templates의 리소스를 변경해도 재시작이 트리거되지 않지만 live reload는 트리거됩니다. 이러한 제외를 사용자 정의하려면 spring.devtools.restart.exclude 속성을 사용할 수 있습니다. 예를 들어, /static 및 /public만 제외하려면 다음 속성을 설정합니다:

Properties

spring.devtools.restart.exclude=static/**,public/**

YAML

spring:
  devtools:
    restart:
      exclude: "static/**,public/**"

이러한 기본값을 유지하고 추가 제외를 추가하려면 대신 spring.devtools.restart.additional-exclude 속성을 사용하세요.

Watching Additional Paths

클래스 경로에 없는 파일을 변경할 때 애플리케이션을 재시작하거나 리로드하고 싶을 수 있습니다. 그렇게 하려면 spring.devtools.restart.additional-paths 속성을 사용하여 변경 사항을 감시할 추가 경로를 구성하세요. 앞에서 설명한 spring.devtools.restart.exclude 속성을 사용하여 추가 경로 아래의 변경 사항이 전체 재시작을 트리거할지 아니면 live reload를 트리거할지 제어할 수 있습니다.

Disabling Restart

재시작 기능을 사용하지 않으려면 spring.devtools.restart.enabled 속성을 사용하여 비활성화할 수 있습니다. 대부분의 경우 application.properties에서 이 속성을 설정할 수 있습니다(그렇게 하면 여전히 재시작 클래스로더를 초기화하지만 파일 변경을 감시하지 않습니다).

재시작 지원을 완전히 비활성화해야 하는 경우(예: 특정 라이브러리와 작동하지 않기 때문에) 다음 예제와 같이 SpringApplication.run(…)을 호출하기 전에 spring.devtools.restart.enabled System 속성을 false로 설정해야 합니다:

Java

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class MyApplication {

    public static void main(String[] args) {
        System.setProperty("spring.devtools.restart.enabled", "false");
        SpringApplication.run(MyApplication.class, args);
    }

}

Kotlin

import org.springframework.boot.SpringApplication
import org.springframework.boot.autoconfigure.SpringBootApplication

@SpringBootApplication
object MyApplication {
    @JvmStatic
    fun main(args: Array<String>) {
        System.setProperty("spring.devtools.restart.enabled", "false")
        SpringApplication.run(MyApplication::class.java, *args)
    }

}

Using a Trigger File

변경된 파일을 지속적으로 컴파일하는 IDE로 작업하는 경우 특정 시간에만 재시작을 트리거하는 것을 선호할 수 있습니다. 그렇게 하려면 "트리거 파일"을 사용할 수 있습니다. 이는 실제로 재시작 검사를 트리거하려고 할 때 수정해야 하는 특수 파일입니다.

파일에 대한 모든 업데이트는 검사를 트리거하지만 Devtools가 수행할 작업이 있음을 감지한 경우에만 재시작이 실제로 발생합니다.

트리거 파일을 사용하려면 spring.devtools.restart.trigger-file 속성을 트리거 파일의 이름(경로 제외)으로 설정하세요. 트리거 파일은 클래스 경로의 어딘가에 나타나야 합니다.

예를 들어, 다음 구조의 프로젝트가 있는 경우:

src
+- main
   +- resources
      +- .reloadtrigger

그러면 trigger-file 속성은 다음과 같습니다:

Properties

spring.devtools.restart.trigger-file=.reloadtrigger

YAML

spring:
  devtools:
    restart:
      trigger-file: ".reloadtrigger"

이제 src/main/resources/.reloadtrigger가 업데이트될 때만 재시작이 발생합니다.

모든 프로젝트가 동일한 방식으로 동작하도록 spring.devtools.restart.trigger-file을 전역 설정으로 설정할 수 있습니다.

일부 IDE에는 트리거 파일을 수동으로 업데이트할 필요가 없도록 하는 기능이 있습니다. Spring Tools for Eclipse 및 IntelliJ IDEA(Ultimate Edition)는 모두 그러한 지원이 있습니다. Spring Tools를 사용하면 콘솔 뷰에서 "reload" 버튼을 사용할 수 있습니다(trigger-file이 .reloadtrigger로 명명된 경우). IntelliJ IDEA의 경우 문서의 지침을 따를 수 있습니다.

Customizing the Restart Classloader

앞서 Restart vs Reload 섹션에서 설명한 대로 재시작 기능은 두 개의 클래스로더를 사용하여 구현됩니다. 이로 인해 문제가 발생하는 경우 spring.devtools.restart.enabled 시스템 속성을 사용하여 문제를 진단할 수 있으며, 재시작이 꺼진 상태에서 앱이 작동하는 경우 어떤 클래스로더가 무엇을 로드하는지 사용자 정의해야 할 수 있습니다.

기본적으로 IDE에서 열린 모든 프로젝트는 "restart" 클래스로더로 로드되고 일반 .jar 파일은 "base" 클래스로더로 로드됩니다. mvn spring-boot:run 또는 gradle bootRun을 사용하는 경우에도 마찬가지입니다: @SpringBootApplication을 포함하는 프로젝트는 "restart" 클래스로더로 로드되고 다른 모든 것은 "base" 클래스로더로 로드됩니다. 앱을 시작할 때 클래스 경로가 콘솔에 출력되어 문제가 있는 항목을 식별하는 데 도움이 될 수 있습니다. 특히 어노테이션과 같이 리플렉션으로 사용되는 클래스는 이를 사용하는 애플리케이션 클래스보다 먼저 시작 시 부모(고정) 클래스로더에 로드될 수 있으며, 이는 Spring에서 감지되지 않을 수 있습니다.

META-INF/spring-devtools.properties 파일을 생성하여 프로젝트의 일부를 다른 클래스로더로 로드하도록 Spring Boot에 지시할 수 있습니다. spring-devtools.properties 파일에는 restart.exclude 및 restart.include 접두사가 붙은 속성이 포함될 수 있습니다. include 요소는 "restart" 클래스로더로 끌어올려야 하는 항목이고, exclude 요소는 "base" 클래스로더로 밀어 넣어야 하는 항목입니다. 속성의 값은 시작 시 JVM에 전달된 클래스 경로에 적용되는 정규식 패턴입니다. 다음은 일부 로컬 클래스 파일이 제외되고 일부 추가 라이브러리가 restart 클래스 로더에 포함되는 예입니다:

restart:
  exclude:
    companycommonlibs: "/mycorp-common-[\\w\\d-\\.]/(build|bin|out|target)/"
  include:
    projectcommon: "/mycorp-myproj-[\\w\\d-\\.]+\\.jar"

모든 속성 키는 고유해야 합니다. 속성이 restart.include. 또는 restart.exclude.로 시작하는 한 고려됩니다.

클래스 경로의 모든 META-INF/spring-devtools.properties가 로드됩니다. 프로젝트 내부 또는 프로젝트가 사용하는 라이브러리에 파일을 패키징할 수 있습니다. 시스템 속성은 사용할 수 없으며 속성 파일만 사용할 수 있습니다.

Known Limitations

재시작 기능은 표준 ObjectInputStream을 사용하여 역직렬화된 객체와 잘 작동하지 않습니다. 데이터를 역직렬화해야 하는 경우 Thread.currentThread().getContextClassLoader()와 함께 Spring의 ConfigurableObjectInputStream을 사용해야 할 수 있습니다.

불행히도 여러 타사 라이브러리는 컨텍스트 클래스로더를 고려하지 않고 역직렬화합니다. 그러한 문제를 발견하면 원래 작성자에게 수정을 요청해야 합니다.

LiveReload

spring-boot-devtools 모듈에는 리소스가 변경될 때 브라우저 새로 고침을 트리거하는 데 사용할 수 있는 내장 LiveReload 서버가 포함되어 있습니다. LiveReload 브라우저 확장은 Chrome, Firefox 및 Safari에서 무료로 사용할 수 있습니다. 선택한 브라우저의 마켓플레이스 또는 스토어에서 'LiveReload'를 검색하여 이러한 확장을 찾을 수 있습니다.

애플리케이션이 실행될 때 LiveReload 서버를 시작하지 않으려면 spring.devtools.livereload.enabled 속성을 false로 설정할 수 있습니다.

한 번에 하나의 LiveReload 서버만 실행할 수 있습니다. 애플리케이션을 시작하기 전에 다른 LiveReload 서버가 실행되고 있지 않은지 확인하세요. IDE에서 여러 애플리케이션을 시작하는 경우 첫 번째 애플리케이션만 LiveReload 지원을 받습니다.

파일이 변경될 때 LiveReload를 트리거하려면 Automatic Restart가 활성화되어야 합니다.

Global Settings

다음 파일 중 하나를 $HOME/.config/spring-boot 디렉토리에 추가하여 전역 devtools 설정을 구성할 수 있습니다:

spring-boot-devtools.properties
spring-boot-devtools.yaml
spring-boot-devtools.yml

이러한 파일에 추가된 모든 속성은 devtools를 사용하는 시스템의 모든 Spring Boot 애플리케이션에 적용됩니다. 예를 들어, 항상 트리거 파일을 사용하도록 재시작을 구성하려면 spring-boot-devtools 파일에 다음 속성을 추가합니다:

Properties

spring.devtools.restart.trigger-file=.reloadtrigger

YAML

spring:
  devtools:
    restart:
      trigger-file: ".reloadtrigger"

기본적으로 $HOME은 사용자의 홈 디렉토리입니다. 이 위치를 사용자 정의하려면 SPRING_DEVTOOLS_HOME 환경 변수 또는 spring.devtools.home 시스템 속성을 설정하세요.

devtools 구성 파일이 $HOME/.config/spring-boot에서 발견되지 않으면 .spring-boot-devtools.properties 파일의 존재 여부에 대해 $HOME 디렉토리의 루트가 검색됩니다. 이를 통해 $HOME/.config/spring-boot 위치를 지원하지 않는 이전 버전의 Spring Boot를 사용하는 애플리케이션과 devtools 전역 구성을 공유할 수 있습니다.

프로파일은 devtools properties/yaml 파일에서 지원되지 않습니다.

.spring-boot-devtools.properties에서 활성화된 모든 프로파일은 프로파일별 구성 파일 로딩에 영향을 미치지 않습니다. spring-boot-devtools-<profile>.properties 형식의 프로파일별 파일 이름과 YAML 및 Properties 파일의 spring.config.activate.on-profile 문서는 지원되지 않습니다.

Configuring File System Watcher

FileSystemWatcher는 특정 시간 간격으로 클래스 변경을 폴링한 다음 미리 정의된 quiet period를 기다려 더 이상 변경 사항이 없는지 확인합니다. Spring Boot는 전적으로 IDE에 의존하여 파일을 컴파일하고 Spring Boot가 읽을 수 있는 위치로 복사하기 때문에 devtools가 애플리케이션을 재시작할 때 특정 변경 사항이 반영되지 않는 경우가 있을 수 있습니다. 이러한 문제를 지속적으로 관찰하는 경우 개발 환경에 맞는 값으로 spring.devtools.restart.poll-interval 및 spring.devtools.restart.quiet-period 매개변수를 늘려보세요:

Properties

spring.devtools.restart.poll-interval=2s
spring.devtools.restart.quiet-period=1s

YAML

spring:
  devtools:
    restart:
      poll-interval: 2s
      quiet-period: 1s

모니터링되는 클래스 경로 디렉토리는 이제 2초마다 변경 사항을 폴링하며 추가 클래스 변경이 없는지 확인하기 위해 1초의 quiet period가 유지됩니다.

Remote Applications

Spring Boot 개발자 도구는 로컬 개발에만 국한되지 않습니다. 원격으로 애플리케이션을 실행할 때도 여러 기능을 사용할 수 있습니다. 원격 지원은 활성화하는 것이 보안 위험이 될 수 있으므로 opt-in입니다. 신뢰할 수 있는 네트워크에서 실행하거나 SSL로 보호할 때만 활성화해야 합니다. 이러한 옵션 중 어느 것도 사용할 수 없는 경우 DevTools의 원격 지원을 사용해서는 안 됩니다. 프로덕션 배포에서는 절대 지원을 활성화해서는 안 됩니다.

이를 활성화하려면 다음 목록과 같이 devtools가 재패키징된 아카이브에 포함되어 있는지 확인해야 합니다:

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <excludeDevtools>false</excludeDevtools>
            </configuration>
        </plugin>
    </plugins>
</build>

그런 다음 spring.devtools.remote.secret 속성을 설정해야 합니다. 중요한 비밀번호나 시크릿과 마찬가지로 값은 추측하거나 무차별 대입 공격을 할 수 없도록 고유하고 강력해야 합니다.

원격 devtools 지원은 두 부분으로 제공됩니다: 연결을 수락하는 서버 측 엔드포인트와 IDE에서 실행하는 클라이언트 애플리케이션입니다. 서버 컴포넌트는 spring.devtools.remote.secret 속성이 설정되면 자동으로 활성화됩니다. 클라이언트 컴포넌트는 수동으로 시작해야 합니다.

원격 devtools는 Spring WebFlux 애플리케이션에 대해 지원되지 않습니다.

Running the Remote Client Application

원격 클라이언트 애플리케이션은 IDE 내에서 실행되도록 설계되었습니다. 연결하는 원격 프로젝트와 동일한 클래스 경로로 RemoteSpringApplication을 실행해야 합니다. 애플리케이션의 단일 필수 인수는 연결할 원격 URL입니다.

예를 들어, Eclipse 또는 Spring Tools를 사용하고 Cloud Foundry에 배포한 my-app이라는 프로젝트가 있는 경우 다음을 수행합니다:

Run 메뉴에서 Run Configurations…를 선택합니다.
새로운 Java Application "launch configuration"을 생성합니다.
my-app 프로젝트를 찾아봅니다.
RemoteSpringApplication을 메인 클래스로 사용합니다.
https://myapp.cfapps.io를 Program arguments에 추가합니다(또는 원격 URL이 무엇이든).

실행 중인 원격 클라이언트는 다음 목록과 유사할 수 있습니다:

  .   ____          _                                              __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _          ___               _      \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` |        | _ \___ _ __  ___| |_ ___ \ \ \ \
 \\/  ___)| |_)| | | | | || (_| []::::::[]   / -_) '  \/ _ \  _/ -_) ) ) ) )
  '  |____| .__|_| |_|_| |_\__, |        |_|_\___|_|_|_\___/\__\___/ / / /
 =========|_|==============|___/===================================/_/_/_/
 :: Spring Boot Remote ::  (v4.0.0-SNAPSHOT)

2025-10-08T09:04:32.044Z  INFO 114345 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Starting RemoteSpringApplication v4.0.0-SNAPSHOT using Java 24.0.2 with PID 114345 (/Users/myuser/.m2/repository/org/springframework/boot/spring-boot-devtools/4.0.0-SNAPSHOT/spring-boot-devtools-4.0.0-SNAPSHOT.jar started by myuser in /opt/apps/)
2025-10-08T09:04:32.055Z  INFO 114345 --- [           main] o.s.b.devtools.RemoteSpringApplication   : No active profile set, falling back to 1 default profile: "default"
2025-10-08T09:04:32.944Z  INFO 114345 --- [           main] o.s.b.d.a.OptionalLiveReloadServer       : LiveReload server is running on port 35729
2025-10-08T09:04:33.043Z  INFO 114345 --- [           main] o.s.b.devtools.RemoteSpringApplication   : Started RemoteSpringApplication in 2.353 seconds (process running for 3.373)

원격 클라이언트는 실제 애플리케이션과 동일한 클래스 경로를 사용하기 때문에 애플리케이션 속성을 직접 읽을 수 있습니다. 이것이 spring.devtools.remote.secret 속성을 읽고 인증을 위해 서버에 전달하는 방법입니다.

트래픽이 암호화되고 비밀번호가 가로채지지 않도록 https://를 연결 프로토콜로 사용하는 것이 항상 권장됩니다.

원격 애플리케이션에 액세스하기 위해 프록시를 사용해야 하는 경우 spring.devtools.remote.proxy.host 및 spring.devtools.remote.proxy.port 속성을 구성하세요.

Remote Update

원격 클라이언트는 로컬 재시작과 동일한 방식으로 애플리케이션 클래스 경로의 변경 사항을 모니터링합니다. 업데이트된 리소스는 원격 애플리케이션으로 푸시되고 (필요한 경우) 재시작을 트리거합니다. 로컬에 없는 클라우드 서비스를 사용하는 기능을 반복하는 경우 도움이 될 수 있습니다. 일반적으로 원격 업데이트 및 재시작은 전체 재빌드 및 배포 주기보다 훨씬 빠릅니다.

느린 개발 환경에서는 quiet period가 충분하지 않을 수 있으며 클래스의 변경 사항이 배치로 분할될 수 있습니다. 첫 번째 클래스 변경 배치가 업로드된 후 서버가 재시작됩니다. 서버가 재시작 중이므로 다음 배치를 애플리케이션에 보낼 수 없습니다.

이는 일반적으로 RemoteSpringApplication 로그에서 일부 클래스 업로드 실패에 대한 경고와 후속 재시도로 나타납니다. 그러나 애플리케이션 코드 불일치 및 첫 번째 변경 배치가 업로드된 후 재시작 실패로 이어질 수도 있습니다. 이러한 문제를 지속적으로 관찰하는 경우 개발 환경에 맞는 값으로 spring.devtools.restart.poll-interval 및 spring.devtools.restart.quiet-period 매개변수를 늘려보세요. 이러한 속성을 구성하려면 Configuring File System Watcher 섹션을 참조하세요.

파일은 원격 클라이언트가 실행 중일 때만 모니터링됩니다. 원격 클라이언트를 시작하기 전에 파일을 변경하면 원격 서버로 푸시되지 않습니다.

저작자표시 (새창열림)

Developer Tools

Diagnosing Classloading Issues

Property Defaults

Automatic Restart

Triggering a restart

Restart vs Reload

Logging Changes in Condition Evaluation

Excluding Resources

Watching Additional Paths

Disabling Restart

Using a Trigger File

Customizing the Restart Classloader

Known Limitations

LiveReload

Global Settings

Configuring File System Watcher

Remote Applications

Running the Remote Client Application

Remote Update

티스토리툴바