길리랩blog

PaaS 위에서 개발한다는 것 — 12-Factor부터 SLO 기반 릴리스까지

PaaS 전제조건 위에서 12-Factor 설계, DevSecOps 파이프라인, 무중단 배포 전략, SLO 기반 운영을 실제 사례와 코드로 정리한 개발방법론 가이드.

2026-08-13 · 최초 발행 2025-12-03

클라우드가 확산되면서 애플리케이션을 어떻게 전달하고 운영할지에 대한 표준화 요구가 커졌다. PaaS 기반 개발방법론은 런타임/빌드팩 또는 컨테이너 런타임, 서비스 바인딩(데이터베이스·메시징·캐시), 오토스케일링, 로깅/메트릭/트레이싱 수집, 릴리스/롤백 API를 전제로 애플리케이션을 설계·개발·테스트·배포·운영하는 절차 표준이다. Cloud Foundry, Heroku, Google App Engine, Azure App Service, OpenShift 등이 이런 전제조건을 충족하는 대표 기술이며, 12-Factor App, DevSecOps, 지속적 전달, 무중단 배포, 관측성 내재화 같은 클라우드 네이티브 원칙을 실무에 적용하는 지침이 이 방법론의 본체다.

12-Factor로 애플리케이션을 짠다

설정은 코드에서 분리해 환경변수로 관리하고, 프로세스는 상태를 갖지 않게(stateless) 만든다. 포트를 바인딩해 서비스로 노출하고, 빌드·릴리스·실행 단계를 분리한다. 데이터베이스·큐·스토리지 같은 외부 서비스는 백킹 서비스로 취급하며, 수평 확장을 기본 가정으로 설계한다.

DevSecOps 파이프라인에 공급망 보안을 내재화한다

코드 저장소에서 빌드팩·컨테이너 빌드, SCA/SAST/컨테이너 스캔, 테스트, 배포까지 자동화하고 SBOM을 생성·서명하며 정책 게이트를 적용한다. 비밀정보는 PaaS의 시크릿·바인딩 기능으로 주입하고, 서드파티 의존성 취약점은 CVSS 임계치 같은 정책 기준으로 파이프라인을 막는다.

무중단 배포 전략을 고른다

Blue/Green, Canary, Rolling 배포는 서비스 특성·트래픽 패턴·상태 관리 방식에 따라 선택한다. 헬스체크, 준비/종료 훅, 커넥션 드레인, 그리고 SLO 위반·에러율·지연을 기준으로 한 자동 롤백 조건을 함께 정의해야 한다.

배포 전략 성능(무중단) 확장성 일관성 안정성 운영 편의
Blue/Green 높음 중간 높음 높음 중간
Canary 높음 높음 중간 높음 중간
Rolling 중간 높음 중간 중간 높음

SLO·트래픽 성격·상태 관리 방식에 따라 이 가중치는 조정이 필요하다.

데이터와 트랜잭션을 안전하게 바꾼다

스키마 변경은 Expand-Contract(이중 호환) 패턴과 온라인 마이그레이션으로 처리하고, 장시간 락은 피하고 배치·이벤트 기반으로 보완한다. 분산 트랜잭션을 대체하기 위해 아웃박스·사가 패턴을 도입하고, 멱등성 키·리트라이·데드레터 큐를 표준화한다.

관측성과 SLO로 운영을 자동화한다

로그는 JSON 같은 표준 구조로 남기고 trace/span id로 트레이스를 상관시켜, 비즈니스 KPI와 기술 지표를 결합한 SLO를 정의한다. CPU/메모리/응답지연/큐 적체를 기준으로 자동 스케일링 정책을 두고, 장애를 예측해 알림을 보내며 기능 플래그로 점진적으로 릴리스한다.

계획부터 운영까지 이어지는 절차

계획·설계 단계에서는 도메인을 분해하고 경계를 정한 뒤 외부 서비스 카탈로그를 매핑하고 SLO·에러 예산을 정의한다. 데이터 민감도에 따른 보안 분류와 접근 제어·키 관리 설계도 이 단계에서 함께 한다. 구현·테스트 단계는 규약 기반 프로젝트 스캐폴딩, 헬스 엔드포인트, 구조적 로깅, 피처 플래그를 내장하고 유닛→계약→통합→E2E로 이어지는 테스트 피라미드와 테스트 데이터 격리·시드 파이프라인을 갖춘다.

빌드·배포 단계에서는 빌드팩·컨테이너로 재현 가능한 빌드를 만들고 SBOM·서명을 붙여 Dev→Staging→Prod로 불변 아티팩트를 승격하며, Blue/Green 또는 Canary로 점진 배포하면서 자동 롤백 룰을 적용한다. 운영·개선 단계에서는 SLO 위반을 분석하고 에러 버짓이 소진되면 기능 개발을 동결하고 안정화 스프린트로 전환하며, 인스턴스 크기·수·런타임 옵션의 비용·성능을 튜닝하고 용량 계획을 자동화한다.

CI/CD 파이프라인이 실제로 도는 방식

⤢✕Git 'push'빌드팩/컨테이너 '이미지 생성'테스트 '유닛/계약/통합'예아니오Staging '배포'SLO '모니터링 10분'예아니오사후 '근본 원인 분석(RCA)'릴리스 '태깅/공지'개발자 'commit'CI '트리거'보안 스캔'SCA/SAST/컨테이너''품질 게이트' 통과 여부아티팩트 '서명/SBOM' 저장파이프라인 '중단' 및 '알림'카나리 '트래픽 10% 전환''SLO' 위반 여부자동 '롤백' 및 '에러 버짓' 차감프로덕션 '100% 전환'개선 '백로그' 등록운영 '관측/오토스케일'

실무에 적용한 사례

금융권 모바일 백엔드 현대화에서는 모놀리스를 도메인 기준 마이크로서비스로 분해하고 Cloud Foundry 기반 Blue/Green을 도입했다. 스키마를 Expand-Contract 패턴으로 17회 무중단 변경했고, 배포 실패율은 60%에서 10%로 줄었다.

이커머스 프로모션 트래픽 대응에서는 큐·캐시를 백킹 서비스로 표준화하고 큐 적체·지연 시간에 연동한 오토스케일 정책을 붙였다. 피크 시간대에는 인스턴스를 자동으로 3배 확장하면서도 예약 인스턴스·스케줄링으로 비용을 22% 절감했다.

공공기관 데이터 수집 플랫폼에서는 계약 테스트와 소비자 주도 계약(CDC)으로 상호 연동을 안정화했다. SBOM·서명·서드파티 라이선스 정책을 자동화해 보안 심사 리드타임을 50% 단축했다.

GitHub Actions로 Cloud Foundry에 배포하기

전제조건: cf CLI 8.x, Cloud Foundry API 엔드포인트·조직·스페이스 접근 권한, GitHub Secrets(CF_API, CF_USERNAME, CF_PASSWORD, CF_ORG, CF_SPACE).

name: cf-deploy
on:
  push:
    branches: ["main"]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Java
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "21"

      - name: Build with Gradle
        run: ./gradlew clean build -x test

      - name: Run Unit Tests
        run: ./gradlew test

      - name: Install cf CLI
        run: |
          curl -L "https://packages.cloudfoundry.org/stable?release=linux64-binary&version=v8&source=github" -o cf.tgz
          tar -xzf cf.tgz
          sudo mv cf /usr/local/bin/

      - name: CF Login
        run: |
          cf api "$CF_API"
          cf auth "$CF_USERNAME" "$CF_PASSWORD"
          cf target -o "$CF_ORG" -s "$CF_SPACE"
        env:
          CF_API: ${{ secrets.CF_API }}
          CF_USERNAME: ${{ secrets.CF_USERNAME }}
          CF_PASSWORD: ${{ secrets.CF_PASSWORD }}
          CF_ORG: ${{ secrets.CF_ORG }}
          CF_SPACE: ${{ secrets.CF_SPACE }}

      - name: Push with rolling deploy
        run: |
          cf push myapp -p build/libs/myapp.jar --strategy rolling --no-start
          cf set-env myapp SPRING_PROFILES_ACTIVE prod
          cf start myapp

컨테이너 기반 PaaS(OpenShift 등)를 쓸 때는 이미지 빌드·서명 후 DeploymentConfig/Rollout으로 배포를 대체하고, 보안 스캔(SCA/SAST/컨테이너)과 SBOM 생성 단계를 추가하는 편이 좋다.

무엇이 바뀌는가

변경 리드타임은 3060% 단축되고 배포 빈도는 25배 늘어나며, 실패율은 DORA 지표 기준으로 50% 이상 감소한다. 평균 복구 시간(MTTR)은 40~70% 개선되고 인프라 운영 작업은 60% 이상 자동화된다. 정성적으로는 표준화된 릴리스·관측·보안 체계로 서비스 신뢰성이 높아지고, 팀 간 협업 비용이 줄고 감사·라이선스 같은 규제 대응도 쉬워진다.

핵심은 인프라 추상화 역량을 최대한 활용해 개발 속도와 운영 신뢰성을 동시에 달성하는 것이다. 도메인 경계와 SLO 정의부터 시작해 파이프라인·배포 전략·운영 정책을 코드로 고정하고, 자동화 범위를 점진적으로 넓혀가는 순서를 권한다.

PaaS12-FactorDevSecOpsCI/CDSLO