[스프링 핵심 원리와 활용] 섹션 7. 외부 설정과 프로필 (1)

[seyeop03]

프로젝트 설정

1. external-start의 폴더 이름을 external로 변경하자.
2. 프로젝트 임포트

File → Open → 해당 프로젝트 build.gradle 선택 → Open as Project 선택

• build.gradle 확인

  plugins {
  	  id 'java'
  	  id 'org.springframework.boot' version '3.0.2'
  	  id 'io.spring.dependency-management' version '1.1.0'
  }
  
  group = 'hello'
  version = '0.0.1-SNAPSHOT'
  sourceCompatibility = '17'
  
  configurations {
  		compileOnly {
  				extendsFrom annotationProcessor
  		}
  }
  
  repositories {
  		mavenCentral()
  }
   
  dependencies {
  		implementation 'org.springframework.boot:spring-boot-starter'
  		compileOnly 'org.projectlombok:lombok'
  		annotationProcessor 'org.projectlombok:lombok'
  		testImplementation 'org.springframework.boot:spring-boot-starter-test'
  		
  		//test lombok 사용
  		testCompileOnly 'org.projectlombok:lombok'
  		testAnnotationProcessor 'org.projectlombok:lombok'
  }
  
  tasks.named('test') {
  		useJUnitPlatform()
  }

• 스프링 부트에서 다음 라이브러리를 선택했다.

  • Lombok → 웹 애플리케이션이 아님

• 테스트 코드에서 lombok을 사용할 수 있도록 설정을 추가했다.

동작 확인

• 기본 메인 클래스 실행(ExternalApplication.main())
• 해당 메인 메서드가 실행되고, 정상 종료되면 성공이다.

0x01. 외부 설정

1.1. 외부 설정이란?

(1) 빌드 2번

하나의 애플리케이션을 여러 다른 환경에서 사용해야 할 때가 있다. 대표적으로 개발이 잘 진행되고 있는지 내부에서 확인하는 용도의 개발 환경, 그리고 실제 고객에게 서비스하는 운영 환경이 있다.

• 개발 환경: 개발 서버, 개발 DB 사용
• 운영 환경: 운영 서버, 운영 DB 사용

문제는 각각의 환경에 따라서 서로 다른 설정값이 존재한다는 점이다. 예를 들어서 애플리케이션이 개발DB에 접근하려면 [dev.db.com](http://dev.db.com) 이라는 url 정보가 필요한데, 운영DB에 접근하려면 [prod.db.com](http://prod.db.com) 이라는 서로 다른 url을 사용해야 한다.

이 문제를 해결하는 가장 단순한 방법은 다음과 같이 각각의 환경에 맞게 애플리케이션을 빌드하는 것이다.

• 개발 환경에는 [dev.db.com](http://dev.db.com) 이 필요하므로 이 값을 애플리케이션 코드에 넣은 다음에 빌드해서
  개발app.jar 를 만든다.
• 운영 환경에서는 [prod.db.com](http://prod.db.com) 이 필요하므로 이 값을 애플리케이션 코드에 넣은 다음에 빌드해서
  운영app.jar 를 만든다.

이렇게 하면 각각의 환경에 맞는 개발app.jar , 운영app.jar 가 만들어지므로 해당 파일들을 각 환경별로 배포하면 된다.

(2) 빌드 1번

하지만 이것은 다음과 이유로 좋은 방법이 아니다.

• 환경에 따라서 빌드를 여러번 해야 한다.
• 개발 버전과 운영 버전의 빌드 결과물이 다르다. 따라서 개발 환경에서 검증이 되더라도 운영 환경에서 다른 빌드 결과를 사용하기 때문에 예상치 못한 문제가 발생할 수 있다. 개발용 빌드가 끝나고 검증한 다음에 운영용 빌드를 해야 하는데 그 사이에 누군가 다른 코드를 변경할 수도 있다. 한마디로 진짜 같은 소스코드에서 나온 결과물인지 검증하기가 어렵다.
  • 설정값만 바꿨다고 해도..
• 각 환경에 맞추어 최종 빌드가 되어 나온 빌드 결과물은 다른 환경에서 사용할 수 없어서 유연성이 떨어진
  다. 향후 다른 환경(ex.스테이징)이 필요하면 그곳에 맞도록 또 빌드를 해야 한다.

그래서 보통 다음과 같이 빌드는 한번만 하고 각 환경에 맞추어 실행 시점에 외부 설정값을 주입한다.

• 배포 환경과 무관하게 하나의 빌드 결과물을 만든다. 여기서는 app.jar 를 빌드한다. 이 안에는 설정값을 두지 않는다. → 개발/운영 서버에다 둠
• 설정값은 실행 시점에 각 환경에 따라 외부에서 주입한다.
  • 개발 서버: app.jar를 실행할 때 [dev.db.com](http://dev.db.com/) 값을 외부 설정으로 주입한다.
  • 운영 서버: app.jar를 실행할 때 [prod.db.com](http://prod.db.com) 값을 외부 설정으로 주입한다.

이렇게 하면 빌드도 한번만 하면 되고, 개발 버전과 운영 버전의 빌드 결과물이 같기 때문에 개발환경에서 검증되면 운영 환경에서도 믿고 사용할 수 있다. 그리고 이후에 새로운 환경이 추가되어도 별도의 빌드 과정 없이 기존 app.jar를 사용해서 손쉽게 새로운 환경을 추가할 수 있다.

유지보수하기 좋은 애플리케이션 개발의 가장 기본 원칙은 변하는 것과 변하지 않는 것을 분리하는 것이다.
유지보수하기 좋은 애플리케이션을 개발하는 단순하면서도 중요한 원칙은 변하는 것과 변하지 않는 것을 분리하는 것이다. 각 환경에 따라 변하는 외부 설정값은 분리하고, 변하지 않는 코드와 빌드 결과물은 유지했다. 덕분에 빌드 과정을 줄이고, 환경에 따른 유연성을 확보하게 되었다.

(3) 외부 설정

애플리케이션을 실행할 때 필요한 설정값을 외부에서 어떻게 불러와서 애플리케이션에 전달할 수 있을까?

외부 설정은 일반적으로 다음 4가지 방법이 있다.

1. OS 환경 변수: OS에서 지원하는 외부 설정, 해당 OS를 사용하는 모든 프로세스에서 사용
   • ex) JAVA_HOME
2. 자바 시스템 속성: 자바에서 지원하는 외부 설정, 해당 JVM안에서 사용
3. 자바 커맨드 라인 인수: 커맨드 라인에서 전달하는 외부 설정, 실행시 main(args) 메서드에서 사용
4. 외부 파일(설정 데이터): 프로그램에서 외부 파일을 직접 읽어서 사용
   • 애플리케이션에서 특정 위치의 파일을 읽도록 해둔다. 예) data/hello.txt
   • 그리고 각 서버마다 해당 파일안에 다른 설정 정보를 남겨둔다.
     • 개발 서버 hello.txt: url=dev.db.com
     • 운영 서버 hello.txt: url=prod.db.com