구성 우선 개발

대상: 개발자와 관리자

Backstage를 오래 운영하기 쉽게 만들어 주는 것 중 하나는, 애플리케이션 동작을 제어하는 기본 수단으로 구성을 쓰는 거예요. 모든 변경에 맞춰 커스텀 코드를 작성하는 대신, 많은 동작을 설정 파일을 통해 켜고 끄거나 조정하고 확장할 수 있어요.

출처: 문서

본문

요약

Backstage를 시간이 지나도 운영하기 쉽게 만드는 요소 중 하나는 구성을 애플리케이션 동작을 제어하는 주된 수단으로 다루는 거예요. 매번 변경할 때마다 커스텀 코드를 쓰는 대신, 많은 동작을 설정 파일을 통해 토글하거나 조정하거나 확장할 수 있어요.

이 페이지를 끝까지 읽으면 Backstage 구성 레이어가 어떻게 동작하고, 환경별로 어떻게 관리하는지 이해하게 될 거예요.

구성 레이어가 동작하는 방식

Backstage는 여러 app-config*.yaml 파일에서 구성을 불러와 그것들을 병합해요. 나중에 불러온 파일이 앞선 파일의 값을 덮어써요. 첫 번째 단계에서 만든 Docker 이미지는 다음 명령으로 시작돼요.

node packages/backend --config app-config.yaml --config app-config.production.yaml

즉 app-config.production.yaml이 app-config.yaml에 설정된 값을 덮어써요. 이 패턴을 사용해 로컬 개발용 기본 구성을 유지하면서 프로덕션에서 바뀌는 부분만 덮어쓸 수 있어요.

일반적인 구성 분리

구성에서의 환경 변수

${VAR_NAME} 문법을 사용해 환경 변수를 참조해요. 이는 비밀(secret)이나 환경마다 다른 값에 권장되는 방식이에요.

backend:
  database:
    client: pg
    connection:
      host: ${POSTGRES_HOST}
      port: ${POSTGRES_PORT}
      user: ${POSTGRES_USER}
      password: ${POSTGRES_PASSWORD}

이렇게 하면 비밀을 저장소 밖으로 빼낼 수 있고, 배포 시점에 변수만 바꿔 같은 Docker 이미지를 여러 환경에서 쓸 수 있어요.

무엇을 구성으로 할지 vs. 무엇을 코드로 할지

좋은 기준이 있어요. 변경이 무언가가 어디에 연결되는지, 어떻게 인증하는지, 어떤 기능이 활성화되는지에 영향을 준다면 구성에 넣어요. 기능이 무엇을 하는지 바꾼다면 코드에 넣는 거죠.

구성 주도 동작의 예시:

• 데이터베이스 연결 정보.
• 인증 공급자 선택과 자격 증명.
• 카탈로그 위치와 엔티티 제공자.
• 통합 토큰(GitHub, GitLab 등).
• TechDocs 스토리지 백엔드(로컬, S3, GCS, Azure).
• 외부 서비스용 프록시 엔드포인트.

구성을 환경 차이의 주된 수단으로 삼으면 CI/CD 파이프라인이 단순해져요. Docker 이미지를 하나만 빌드해서 어디에나 배포하고, 구성 파일과 환경 변수만 달리하면 되거든요.

더 읽어보기

전체 구성 참조 문서는 Configuration 문서를 보세요.

다음 단계

배포가 실행되고 구성을 관리할 수 있게 됐다면, 상태를 유지하도록 모니터링을 설정해야 해요.

• 배포 모니터링