Spring Boot와 Firebase 연동: 인증 키 관리부터 배포 전략까지 실전 가이드 ~ Dev.

오늘날 많은 웹 애플리케이션과 모바일 서비스 백엔드는 다양한 외부 서비스와 긴밀하게 연동됩니다. 그중 구글의 Firebase는 강력한 인증(Authentication), 실시간 데이터베이스(Realtime Database, Firestore), 클라우드 스토리지(Cloud Storage), 푸시 알림(FCM), 서버리스 함수(Cloud Functions) 등 다채로운 기능을 제공하며 개발자들에게 큰 사랑을 받고 있습니다. 특히 Java와 Spring Boot 생태계에서 Firebase의 기능을 활용하면, 복잡한 인프라 구축 없이도 강력하고 확장성 있는 백엔드 서비스를 신속하게 개발할 수 있습니다.

Spring Boot 프로젝트에 Firebase Admin SDK를 연동하는 과정 자체는 어렵지 않습니다. 필요한 의존성을 추가하고, Firebase 프로젝트에서 발급받은 서비스 계정 키(JSON 파일)를 사용하여 초기화 코드를 작성하면 됩니다. 하지만 바로 이 '서비스 계정 키 관리'에서 많은 개발자들이 초기에 혼란을 겪거나, 장기적인 관점에서 좋지 않은 선택을 하곤 합니다. 로컬 개발 환경에서는 잘 동작하던 코드가 테스트 서버나 운영 서버에 배포했을 때 파일을 찾지 못해 오류를 뿜어내는 경험은 누구나 한 번쯤 겪어봤을 법한 일입니다.

이 글에서는 단순히 Firebase를 연동하는 방법을 넘어, Spring Boot 환경에서 서비스 계정 키를 안전하고 효율적으로 관리하는 다양한 방법을 심층적으로 다루고자 합니다. 로컬 개발의 편의성을 위한 방법부터, 실제 운영 환경의 보안과 확장성을 고려한 최상의 방법까지, 각 방식의 장단점과 구체적인 구현 코드를 통해 여러분의 프로젝트를 한 단계 더 높은 수준으로 이끌어 줄 실전적인 지식을 공유합니다.

1. Firebase 연동을 위한 사전 준비

본격적인 연동에 앞서 몇 가지 준비가 필요합니다. 이미 Firebase 프로젝트와 Spring Boot 프로젝트가 준비된 상태라면 이 단계를 건너뛰어도 좋습니다.

1.1. Firebase 프로젝트 생성 및 서비스 계정 키 발급

가장 먼저 Firebase 프로젝트가 필요합니다. 구글 계정으로 Firebase 콘솔에 접속하여 새 프로젝트를 생성합니다.

Firebase 콘솔에서 '프로젝트 추가'를 클릭하여 프로젝트 이름을 지정하고 안내에 따라 생성을 완료합니다.
프로젝트가 생성되면, 좌측 상단의 톱니바퀴 아이콘을 클릭하고 '프로젝트 설정'으로 이동합니다.
상단 탭에서 '서비스 계정'을 선택합니다.
'Firebase Admin SDK' 섹션에서 사용 언어로 'Java'가 선택되어 있는지 확인합니다.
하단의 '새 비공개 키 생성' 버튼을 클릭합니다. 경고 팝업이 나타나면 '키 생성'을 클릭하여 JSON 파일을 다운로드합니다.

⚠️ 중요: 이 JSON 파일은 여러분의 Firebase 프로젝트에 대한 모든 관리자 권한을 담고 있습니다. 데이터베이스 읽기/쓰기, 사용자 정보 관리 등 모든 작업을 수행할 수 있는 마스터키와 같습니다. 따라서 이 파일은 절대 외부에 노출되어서는 안 되며, 특히 GitHub과 같은 공개적인 버전 관리 시스템에 절대로 커밋해서는 안 됩니다.

1.2. Spring Boot 프로젝트에 Firebase Admin SDK 의존성 추가

이제 Spring Boot 프로젝트에서 Firebase Admin SDK를 사용할 수 있도록 의존성을 추가해야 합니다. Maven 또는 Gradle 프로젝트에 맞춰 아래 내용을 `pom.xml` 또는 `build.gradle` 파일에 추가합니다.

Maven (`pom.xml`)


<dependency>
    <groupId>com.google.firebase</groupId>
    <artifactId>firebase-admin</artifactId>
    <version>9.2.0</version> 
</dependency>

Gradle (`build.gradle` 또는 `build.gradle.kts`)


// Groovy DSL
implementation 'com.google.firebase:firebase-admin:9.2.0' // 최신 버전은 Maven Central에서 확인하세요

// Kotlin DSL
// implementation("com.google.firebase:firebase-admin:9.2.0")

의존성 추가 후 프로젝트를 다시 빌드하여 라이브러리를 다운로드합니다. 이제 Firebase 연동을 위한 모든 준비가 끝났습니다.

2. Firebase 초기화 설정: @Configuration과 @Bean 활용

Spring Boot의 핵심 철학 중 하나는 IoC(Inversion of Control)와 DI(Dependency Injection)입니다. Firebase 관련 설정을 애플리케이션의 생명주기와 함께 관리하고, 필요한 곳에 손쉽게 주입하여 사용하기 위해 Spring의 설정 클래스(`@Configuration`)와 빈(`@Bean`)을 활용하는 것이 가장 이상적입니다.

먼저, Firebase 설정을 전담할 클래스를 하나 생성합니다.


package com.example.myproject.config;

import com.google.auth.oauth2.GoogleCredentials;
import com.google.firebase.FirebaseApp;
import com.google.firebase.FirebaseOptions;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import java.io.FileInputStream;
import java.io.IOException;

@Configuration
public class FirebaseConfig {

    // FirebaseApp 빈을 여기에 정의할 것입니다.
    
}

이 `FirebaseConfig` 클래스 내에 `FirebaseApp` 객체를 생성하여 Spring 컨테이너에 빈으로 등록하는 코드를 작성할 것입니다. `FirebaseApp` 객체는 한번 초기화되면 애플리케이션 전역에서 사용되므로, 싱글톤(Singleton) 스코프로 관리되는 빈으로 등록하는 것이 매우 적절합니다. `initializeApp` 메소드는 내부적으로 이미 초기화되었는지 확인하므로 여러 번 호출해도 안전하지만, 애플리케이션 시작 시점에 딱 한 번만 실행되도록 구성하는 것이 좋습니다.

이제부터 핵심 과제인 "JSON 키 파일을 어떻게 읽어올 것인가"에 대한 다양한 방법을 살펴보겠습니다.

3. 서비스 계정 키 로딩 전략: 장단점 비교 분석

서비스 계정 키를 로딩하는 방법은 크게 세 가지로 나눌 수 있으며, 각각은 개발 편의성, 보안, 배포 유연성 측면에서 뚜렷한 장단점을 가집니다.

전략 1: Classpath 리소스 활용 (로컬 개발에 최적화)

가장 간단하고 직관적인 방법입니다. Spring Boot 프로젝트의 `src/main/resources` 디렉터리에 다운로드한 JSON 파일을 위치시키는 방식입니다. 이 디렉터리는 빌드 시점에 클래스패스(classpath)의 루트로 포함되므로, 코드 내에서 쉽게 접근할 수 있습니다.

1. 파일 위치: `src/main/resources/firebase-service-account-key.json` (파일 이름은 자유롭게 지정)

2. 구현 코드: Spring의 `Resource`와 `@Value` 애너테이션을 활용하면 훨씬 더 Spring다운 방식으로 구현할 수 있습니다. `ResourceUtils.getFile()`은 압축된 JAR 파일 내부의 리소스를 파일 시스템 경로로 가져올 수 없는 치명적인 단점이 있으므로, `Resource` 객체에서 직접 `InputStream`을 얻는 방식을 사용해야 합니다.


package com.example.myproject.config;

import com.google.auth.oauth2.GoogleCredentials;
import com.google.firebase.FirebaseApp;
import com.google.firebase.FirebaseOptions;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.io.Resource;

import javax.annotation.PostConstruct;
import java.io.IOException;
import java.io.InputStream;
import java.util.List;

@Configuration
public class FirebaseConfig {

    private static final Logger logger = LoggerFactory.getLogger(FirebaseConfig.class);

    @Value("classpath:firebase-service-account-key.json")
    private Resource resource;
    
    // @PostConstruct를 사용하여 Bean이 생성된 후 초기화 로직을 수행
    @PostConstruct
    public void initFirebase() throws IOException {
        // FirebaseApp이 이미 초기화되었는지 확인
        if (FirebaseApp.getApps().isEmpty()) {
            try (InputStream serviceAccount = resource.getInputStream()) {
                FirebaseOptions options = FirebaseOptions.builder()
                        .setCredentials(GoogleCredentials.fromStream(serviceAccount))
                        .build();

                FirebaseApp.initializeApp(options);
                logger.info("Firebase has been initialized.");
            }
        }
    }
    
    // 필요에 따라 FirebaseApp 또는 관련 서비스(FirebaseAuth, FirebaseMessaging 등)를 Bean으로 등록할 수 있음
    // 예: 
    // @Bean
    // public FirebaseMessaging firebaseMessaging() throws IOException {
    //    return FirebaseMessaging.getInstance(FirebaseApp.getInstance());
    // }
}

위 코드에서는 `@PostConstruct`를 사용하여 `FirebaseConfig` 빈이 생성되고 의존성(`resource`)이 주입된 직후에 Firebase를 초기화합니다. `FirebaseApp.getApps().isEmpty()` 체크를 통해 중복 초기화를 방지하여 안정성을 높였습니다.

장점:
- 설정이 매우 간단하고 직관적입니다.
- 프로젝트 내부에 파일이 있어 어디서든 동일하게 동작합니다.
- 로컬 개발 및 빠른 프로토타이핑에 매우 유용합니다.
단점:
- 치명적인 보안 위협: 서비스 계정 키가 소스 코드와 함께 버전 관리 시스템(Git 등)에 포함될 가능성이 매우 높습니다. 실수로 private 저장소가 public으로 전환되거나, 접근 권한이 없는 사람에게 소스 코드가 노출되면 프로젝트 전체가 위험에 빠집니다.
- 유연성 부족: 개발, 테스트, 운영 환경마다 다른 Firebase 프로젝트를 사용해야 할 경우, 매번 빌드 시점에 다른 키 파일을 포함시켜야 하는 번거로움이 있습니다.
- .gitignore 설정 필수: 이 방법을 사용하려면 반드시 `.gitignore` 파일에 키 파일 이름을 추가하여 Git 추적에서 제외해야 합니다. 하지만 이는 근본적인 해결책이 아닙니다.

결론: 이 방법은 개인 프로젝트나 학습 목적으로는 훌륭하지만, 팀 단위 협업이나 실제 서비스 운영 환경에서는 절대 권장되지 않습니다.

전략 2: 외부 파일 경로 사용 (환경 분리 및 보안 강화)

두 번째 전략은 서비스 계정 키 파일을 프로젝트 외부, 즉 서버의 특정 파일 시스템 경로에 보관하고, 애플리케이션이 실행될 때 이 경로를 읽어오도록 설정하는 것입니다. 이 방법은 키 파일을 소스 코드로부터 완전히 분리하여 보안을 강화하고 환경별 설정을 유연하게 만듭니다.

1. 파일 위치: 서버의 안전한 경로 (예: `/etc/config/my-app/firebase-key.json` 또는 `C:\config\my-app\firebase-key.json`)

2. 구현 코드: `application.properties` 또는 `application.yml` 파일에 파일 경로를 설정하고, `@Value` 애너테이션으로 이 값을 주입받아 사용합니다.

`src/main/resources/application.yml`


firebase:
  key:
    # 'file:' 접두사를 사용해야 외부 파일 시스템 경로로 인식합니다.
    path: file:/path/to/your/firebase-key.json

`FirebaseConfig.java` 수정


package com.example.myproject.config;

// ... imports

@Configuration
public class FirebaseConfig {

    private static final Logger logger = LoggerFactory.getLogger(FirebaseConfig.class);
    
    // application.yml에 정의된 프로퍼티 값을 주입받습니다.
    @Value("${firebase.key.path}")
    private Resource resource;

    @PostConstruct
    public void initFirebase() throws IOException {
        if (FirebaseApp.getApps().isEmpty()) {
            try (InputStream serviceAccount = resource.getInputStream()) {
                FirebaseOptions options = FirebaseOptions.builder()
                        .setCredentials(GoogleCredentials.fromStream(serviceAccount))
                        .build();

                FirebaseApp.initializeApp(options);
                logger.info("Firebase has been initialized using external file: {}", resource.getFilename());
            } catch (IOException e) {
                logger.error("Error initializing Firebase from path: " + resource.getDescription(), e);
                // 애플리케이션을 시작하지 못하게 하려면 예외를 다시 던지는 것을 고려할 수 있습니다.
                throw new RuntimeException("Failed to initialize Firebase", e); 
            }
        }
    }
}

이제 개발 환경에서는 로컬 경로를, 운영 서버에서는 서버의 실제 경로를 `application.yml` 파일이나 실행 시점의 인자(`-Dfirebase.key.path=...`)로 전달하여 손쉽게 환경을 분리할 수 있습니다.

장점:
- 보안 향상: 민감한 키 파일이 소스 코드와 완전히 분리됩니다.
- 환경 분리의 유연성: `application-dev.yml`, `application-prod.yml` 등 Spring Profile을 활용하여 환경별로 다른 키 파일을 손쉽게 지정할 수 있습니다.
- 운영/배포 팀이 소스 코드를 건드리지 않고도 키 파일을 관리할 수 있습니다.
단점:
- 배포 시 서버에 키 파일을 미리 배치해야 하는 추가적인 작업이 필요합니다.
- 파일 경로가 하드코딩되지는 않지만, 여전히 파일 시스템에 대한 의존성이 존재합니다.

결론: 이 방법은 전략 1에 비해 훨씬 안전하고 유연하여, 많은 전통적인 서버 환경에서 선호되는 방식입니다.

전략 3: 환경 변수 활용 (클라우드 네이티브 및 MSA 환경의 표준)

가장 진보되고 안전하며, 현대적인 클라우드 및 컨테이너 환경(Docker, Kubernetes 등)에 최적화된 방법입니다. 이 전략은 서비스 계정 키 JSON 파일의 내용 전체를 하나의 환경 변수에 문자열로 저장하고, 애플리케이션이 실행될 때 이 환경 변수를 읽어와 사용하는 방식입니다. 파일 시스템에 대한 의존성이 완전히 사라집니다.

1. 환경 변수 설정: JSON 파일의 모든 내용을 복사하여 `FIREBASE_CREDENTIALS` 와 같은 이름의 환경 변수에 값으로 설정합니다. JSON 형식 때문에 줄 바꿈과 따옴표 처리에 유의해야 합니다. (보통 Base64로 인코딩하여 저장하기도 합니다.)

Linux/macOS Shell:


# JSON 내용을 직접 붙여넣기
export FIREBASE_CREDENTIALS='{ "type": "service_account", "project_id": "...", ... }'

# 파일 내용을 읽어서 설정 (권장)
export FIREBASE_CREDENTIALS=$(cat /path/to/your/firebase-key.json)

Docker-compose.yml:


services:
  my-spring-app:
    image: my-app-image
    environment:
      - FIREBASE_CREDENTIALS=${FIREBASE_CREDENTIALS_CONTENT} 
      # .env 파일 등을 통해 주입하는 것이 일반적

Kubernetes Secret & Deployment:

Kubernetes에서는 Secret 객체를 사용하여 민감한 정보를 안전하게 관리하고, 이를 환경 변수로 Pod에 주입하는 것이 표준 방식입니다.

2. 구현 코드: 환경 변수를 읽어 `String`으로 받은 뒤, `ByteArrayInputStream`을 사용하여 `InputStream`으로 변환해 `GoogleCredentials`에 전달합니다.


package com.example.myproject.config;

// ... imports
import java.io.ByteArrayInputStream;
import java.nio.charset.StandardCharsets;

@Configuration
public class FirebaseConfig {

    private static final Logger logger = LoggerFactory.getLogger(FirebaseConfig.class);

    // 환경 변수 FIREBASE_CREDENTIALS 값을 주입받습니다.
    @Value("${firebase.credentials}")
    private String firebaseCredentials;

    @PostConstruct
    public void initFirebase() throws IOException {
        if (FirebaseApp.getApps().isEmpty()) {
            try {
                // 환경 변수에서 읽어온 문자열을 InputStream으로 변환
                InputStream serviceAccountStream = new ByteArrayInputStream(firebaseCredentials.getBytes(StandardCharsets.UTF_8));
                
                FirebaseOptions options = FirebaseOptions.builder()
                        .setCredentials(GoogleCredentials.fromStream(serviceAccountStream))
                        .build();

                FirebaseApp.initializeApp(options);
                logger.info("Firebase has been initialized from environment variable.");
            } catch (IOException e) {
                logger.error("Error initializing Firebase from environment variable.", e);
                throw new RuntimeException("Failed to initialize Firebase", e);
            }
        }
    }
}

`src/main/resources/application.yml`


firebase:
  # Spring이 환경 변수를 읽어서 주입하도록 설정합니다.
  # ${FIREBASE_CREDENTIALS}는 시스템의 환경 변수 'FIREBASE_CREDENTIALS'를 참조합니다.
  credentials: ${FIREBASE_CREDENTIALS}

장점:
- 최고 수준의 보안: 파일이 존재하지 않으므로 파일 노출의 위험이 원천적으로 차단됩니다. 클라우드 플랫폼의 Secret 관리 시스템(AWS Secrets Manager, GCP Secret Manager, K8s Secrets 등)과 완벽하게 통합됩니다.
- 이식성과 확장성: 파일 시스템에 대한 의존이 없으므로, 어떤 환경(Docker, K8s, 서버리스)으로든 애플리케이션을 쉽게 이식하고 확장할 수 있습니다.
- 12-Factor App 원칙 준수: The Twelve-Factor App의 '설정(Config)' 원칙을 가장 잘 따르는 방식입니다.
단점:
- 로컬 개발 환경에서 긴 JSON 문자열을 환경 변수로 설정하는 것이 다소 번거로울 수 있습니다. (IDE의 실행 설정이나 쉘 스크립트를 활용하면 해결 가능)

결론: 현대적인 클라우드 기반 애플리케이션을 개발한다면 단연코 전략 3이 가장 권장되는 표준 방식입니다. CI/CD 파이프라인과의 통합도 가장 매끄럽습니다.

4. 실전 적용: Spring Profile을 활용한 동적 설정

실제 프로젝트에서는 로컬 개발 환경의 편의성(`classpath` 방식)과 운영 환경의 보안(`환경 변수` 방식)을 모두 가져가고 싶을 수 있습니다. 이때 Spring Profile을 활용하면 완벽한 해결책이 됩니다.

`application.yml` 파일을 분리하고 Profile에 따라 다른 빈을 생성하도록 `FirebaseConfig`를 수정해 봅시다.

`src/main/resources/application.yml` (공통 설정)


spring:
  profiles:
    active: local # 기본 프로파일을 local로 설정

`src/main/resources/application-local.yml` (로컬 환경용)


firebase:
  key:
    path: classpath:firebase-service-account-key.json

`src/main/resources/application-prod.yml` (운영 환경용)


firebase:
  key:
    # 운영 환경에서는 외부 파일 경로를 사용하거나
    # path: file:/etc/config/my-app/firebase-key.json
    
    # 또는 환경 변수를 사용 (더 권장됨)
    credentials: ${FIREBASE_CREDENTIALS}

그리고 `FirebaseConfig`를 Profile에 따라 분리하여 구성합니다. 혹은 하나의 클래스에서 `@Profile` 애너테이션을 사용하여 조건부로 빈을 생성할 수 있습니다.


package com.example.myproject.config;

import com.google.auth.oauth2.GoogleCredentials;
import com.google.firebase.FirebaseApp;
import com.google.firebase.FirebaseOptions;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;
import org.springframework.core.io.Resource;

import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.nio.charset.StandardCharsets;

@Configuration
public class FirebaseConfig {

    private static final Logger logger = LoggerFactory.getLogger(FirebaseConfig.class);

    // 공통 초기화 로직
    private void initializeFirebase(InputStream serviceAccountStream) throws IOException {
        if (FirebaseApp.getApps().isEmpty()) {
            FirebaseOptions options = FirebaseOptions.builder()
                    .setCredentials(GoogleCredentials.fromStream(serviceAccountStream))
                    .build();
            FirebaseApp.initializeApp(options);
            logger.info("Firebase has been initialized successfully.");
        }
    }

    // "local" 프로파일이 활성화될 때 이 빈을 생성
    @Bean
    @Profile("local")
    public void initFirebaseLocal(@Value("${firebase.key.path}") Resource resource) throws IOException {
        logger.info("Initializing Firebase for [local] profile from classpath: {}", resource.getFilename());
        initializeFirebase(resource.getInputStream());
    }

    // "prod" 프로파일이 활성화될 때 이 빈을 생성
    @Bean
    @Profile("prod")
    public void initFirebaseProd(@Value("${firebase.key.credentials}") String firebaseCredentials) throws IOException {
        logger.info("Initializing Firebase for [prod] profile from environment variable.");
        InputStream serviceAccountStream = new ByteArrayInputStream(firebaseCredentials.getBytes(StandardCharsets.UTF_8));
        initializeFirebase(serviceAccountStream);
    }
}

이렇게 구성하면, 로컬에서 실행할 때는 `application-local.yml`이 활성화되어 `classpath`의 키 파일을 사용하고, 배포 서버에서 `-Dspring.profiles.active=prod` 옵션을 주고 실행하면 `application-prod.yml`이 활성화되어 환경 변수에서 키 정보를 읽어오게 됩니다. 개발과 운영의 요구사항을 모두 충족하는 매우 깔끔하고 전문적인 설정 방식입니다.

5. 결론 및 요약

Spring Boot와 Firebase Admin SDK를 연동하는 작업의 핵심은 서비스 계정 키를 어떻게 '관리'하고 '로딩'할 것인지에 달려 있습니다.

Classpath 리소스 방식 (전략 1): 가장 간단하지만 심각한 보안 위험이 있어 개인적인 학습이나 프로토타이핑 용도로만 제한적으로 사용해야 합니다.
외부 파일 경로 방식 (전략 2): 보안과 유연성 측면에서 큰 개선을 이루며, 많은 전통적인 서버 환경에서 유효한 방식입니다.
환경 변수 방식 (전략 3): 파일 시스템 의존성을 제거하고 최고 수준의 보안과 이식성을 제공합니다. Docker, Kubernetes와 같은 현대적인 클라우드 네이티브 환경의 표준이자 가장 권장되는 방식입니다.

실제 프로젝트에서는 Spring Profile을 활용하여 개발 환경의 편의성과 운영 환경의 안정성/보안성을 모두 만족시키는 하이브리드 전략을 채택하는 것이 현명합니다. 민감한 정보는 소스 코드와 철저히 분리하고, 환경에 따라 설정을 유연하게 변경할 수 있는 구조를 처음부터 설계하는 습관은 장기적으로 유지보수 비용을 줄이고 애플리케이션의 안정성을 높이는 데 결정적인 역할을 합니다. 이 글이 여러분의 Spring Boot와 Firebase 여정에 든든한 초석이 되기를 바랍니다.

Wednesday, January 23, 2019

Spring Boot와 Firebase 연동: 인증 키 관리부터 배포 전략까지 실전 가이드

1. Firebase 연동을 위한 사전 준비

1.1. Firebase 프로젝트 생성 및 서비스 계정 키 발급

1.2. Spring Boot 프로젝트에 Firebase Admin SDK 의존성 추가

Maven (`pom.xml`)

Gradle (`build.gradle` 또는 `build.gradle.kts`)

2. Firebase 초기화 설정: @Configuration과 @Bean 활용

3. 서비스 계정 키 로딩 전략: 장단점 비교 분석

전략 1: Classpath 리소스 활용 (로컬 개발에 최적화)

전략 2: 외부 파일 경로 사용 (환경 분리 및 보안 강화)

`src/main/resources/application.yml`

`FirebaseConfig.java` 수정

전략 3: 환경 변수 활용 (클라우드 네이티브 및 MSA 환경의 표준)

Linux/macOS Shell:

Docker-compose.yml:

Kubernetes Secret & Deployment:

`src/main/resources/application.yml`

4. 실전 적용: Spring Profile을 활용한 동적 설정

`src/main/resources/application.yml` (공통 설정)

`src/main/resources/application-local.yml` (로컬 환경용)

`src/main/resources/application-prod.yml` (운영 환경용)

5. 결론 및 요약

0 개의 댓글:

Post a Comment

Popular Posts

Recent Posts

Comments

Visitor

Followers