Spring Boot profile은 같은 코드를 local, dev, prod 같은 다른 환경에서 실행할 때 설정을 나누는 기능입니다. 하지만 profile을 너무 빨리, 너무 많이 나누면 오히려 설정을 추적하기 어려워집니다.
핵심은 환경마다 달라지는 값과 모든 환경에서 같아야 하는 값을 분리하는 것입니다. 이 글은 Spring Boot 공식 external config와 Spring Framework profile 문서를 기준으로 profile 분리 기준을 정리합니다.
Spring Boot profile을 먼저 한 줄로 정리하면
Spring profile은 실행 환경에 따라 다른 bean이나 설정 값을 적용하기 위한 이름표입니다. local에서는 로컬 DB를 쓰고, prod에서는 운영 DB와 운영 로그 정책을 쓰는 식입니다.
# application.yml
spring:
profiles:
active: local
---
spring:
config:
activate:
on-profile: local
datasource:
url: jdbc:h2:mem:testdb중요한 점은 profile이 코드를 나누는 도구가 아니라 설정과 일부 bean 구성을 나누는 도구라는 점입니다.
언제 local, dev, prod를 나누면 좋을까
환경마다 실제로 달라지는 값이 생겼을 때 profile을 나누는 편이 자연스럽습니다. 단순히 이름을 예쁘게 나누기 위해 profile을 늘리면 설정 파일만 많아지고 실수 지점이 늘어납니다.
- 데이터베이스 주소와 계정이 다르다
- 외부 API endpoint가 sandbox와 production으로 나뉜다
- 로그 수준이나 observability 설정이 다르다
- 개발 환경에서만 켜야 하는 테스트용 bean이 있다
- 운영 환경에서는 절대 켜면 안 되는 debug 옵션이 있다
공통 설정과 환경별 설정을 나누자
모든 환경에서 같은 값은 공통 application.yml에 두고, 달라지는 값만 profile별 설정으로 override하는 편이 관리하기 쉽습니다.
# application.yml
app:
page-size: 20
# application-prod.yml
logging:
level:
root: INFO공통값을 profile마다 복사하면 나중에 한 환경만 수정되고 다른 환경은 낡은 값으로 남는 문제가 생깁니다.
secret은 profile 파일에 넣지 않는 편이 안전하다
profile은 환경별 설정을 나누는 기능이지 비밀값을 안전하게 보관하는 기능이 아닙니다. DB password, API token, private key처럼 노출되면 안 되는 값은 git에 들어가는 설정 파일에 직접 적지 않는 편이 좋습니다.
운영에서는 환경 변수, CI/CD secret, cloud secret manager 같은 별도 저장 방식을 검토해야 합니다. profile 파일에는 secret의 이름이나 연결 구조만 남기는 편이 안전합니다.
실무 체크리스트
- 환경마다 실제로 달라지는 값인지 먼저 확인한다
- 공통 설정을 중복 복사하지 않는다
- profile 활성화 방식을 배포 환경에서 명확히 관리한다
- 비밀값은 profile 파일이 아니라 secret 경로로 분리한다
- prod profile을 local에서 잘못 켜지 않도록 실행 스크립트와 문서를 정리한다
정리
Spring Boot profile를 이해할 때는 문법이나 기능 이름보다 문제가 생기는 경계를 먼저 보는 편이 좋습니다. 오늘 글의 기준은 ‘언제 다시 실행되고, 어디까지 공개되고, 어떤 권한이 남는가’처럼 실수 지점을 분리하는 것입니다.
함께 보면 좋은 내부 글은 Spring Boot 의존성 주입은 왜 필요할까, Spring Boot @Transactional은 어디에 붙여야 할까, Spring Security 401과 403 차이입니다. 외부 기준은 Spring Boot Docs – Externalized Configuration, Spring Boot Docs – Profiles, Spring Framework Docs – Bean Definition Profiles를 확인했습니다.
