파스-타(PaaS-TA) 5.0, 공공 PaaS가 CF와 쿠버네티스를 함께 쓰는 이유

국내 공공부문 표준 PaaS로 자리잡은 파스-타(PaaS-TA)는 5.0에서 Cloud Foundry(CF)와 Kubernetes를 함께 제공하는 멀티 런타임 구조를 택했다. 오픈소스 기반 애플리케이션 플랫폼으로 공공·금융 등 규제 산업이 요구하는 민첩성·안정성·보안을 충족하는 데 목적이 있으며, BOSH/타일 기반 설치·업그레이드 체계와 Open Service Broker API 기반 서비스 프로비저닝·바인딩을 표준 인터페이스로 쓴다. OpenStack, VMware vSphere, 공용 클라우드 등 IaaS를 추상화해 멀티클라우드를 지원하지만, 세부 컴포넌트 버전과 지원 서비스 타입, 보안 가이드라인은 기관 가이드와 릴리스 노트에서 최신 정보를 확인해야 한다.

멀티 런타임: CF와 K8s를 나란히 둔다

Cloud Foundry 런타임은 cf push 추상화를 제공하고 빌드팩을 통해 소스를 런타임 이미지로 자동 변환한다. 여기에 Kubernetes 기반 컨테이너 런타임을 병행 운용해 매니페스트·헬스체크·롤아웃 전략을 표준화한다. 어느 쪽을 쓸지는 워크로드 특성에 달렸다 — 표준 웹/API는 CF의 배포 편의를, 잡·배치나 세밀한 커스터마이징이 필요한 워크로드는 K8s의 유연성을 택하는 식이다.

서비스 마켓플레이스와 운영 자동화

Open Service Broker API를 준수해 데이터베이스, 메시지 브로커, 캐시, 오브젝트 스토리지 등을 서비스 카탈로그로 제공하고, 조직·공간 단위로 서비스를 할당·비용 추적·수명주기 관리한다. 운영은 BOSH 기반 릴리스, 스템셀, 선언적 매니페스트로 관리되며 롤링 업데이트로 무중단 배포를 지원한다. 여기에 오토스케일링·수평 확장 정책을 적용해 트래픽 급증에 탄력적으로 대응한다.

보안·거버넌스와 관측

UAA 기반 인증·권한·SSO·OAuth2 토큰 관리로 조직·공간을 격리하고 리소스 쿼터를 통제한다. 네트워크 정책과 앱 간 통신 화이트리스트, TLS 종단간 암호화도 이 계층에서 적용한다. 관측은 Loggregator/EFK/Prometheus 기반으로 로그·메트릭을 수집해 대시보드·알림 플로우를 구성하고, 배포·권한·서비스 변경 감사 로그를 보존해 규제 준수 대응을 쉽게 만든다.

실무에서는 이렇게 쓴다

공공 민원·업무 포털을 현대화할 때는 모놀리식 WAS 기반 웹 포털을 대상으로 CF 런타임과 RDBMS 서비스, 오토스케일러를 구성한다. 모놀리스 기능을 단일 앱으로 컨테이너화해 cf push로 전환하고, 세션리스·외부 캐시를 적용한 뒤 오토스케일 정책을 설정하는 순서를 밟는다.

금융권 내부 API 게이트웨이는 내부 API 서비스와 이벤트 처리를 대상으로 K8s 런타임과 메시지 브로커 서비스, 서비스 메시로 구성한다. 마이크로서비스를 컨테이너화하고 GitOps 파이프라인을 구성한 뒤 OSB 기반 브로커 서비스를 바인딩하고 네트워크 정책을 강화하는 순서다.

교육·연구 데이터 처리는 배치·스트리밍이 섞인 워크로드를 대상으로 CF 런타임(웹/API)과 K8s 런타임(잡/배치), 오브젝트 스토리지를 함께 구성한다. 웹/API는 빌드팩 자동화로, 데이터 파이프라인은 K8s 잡/크론잡으로 분리하고 공통 모니터링·알림을 통합하는 식이다.

배포 파이프라인이 도는 방식

⤢✕

도입 절차

요구사항·아키텍처 수립 단계에서는 서비스 수준 목표(SLO), 보안 등급, 데이터 주권, 지역·가용영역을 설계하고 CF 우선·혼합·K8s 우선 중 런타임 선택 전략과 표준 패턴을 정한다. 인프라 준비 단계에서는 IaaS 네트워크·스토리지·로드밸런서를 설계하고 멀티 AZ·DR 토폴로지와 조직/공간 네임스페이스·쿼터 계획을 세운다.

플랫폼 설치·구성 단계는 BOSH 디렉터를 배포하고 인증서·크레덴셜을 하드닝한 뒤 CF/K8s 런타임과 UAA/CredHub를 구성하고 서비스 타일을 설치해 마켓플레이스 카탈로그와 서비스 플랜을 표준화한다. CI/CD 구축 단계에서는 브랜치 전략, 품질 게이트, 컨테이너 서명·스캔 체계를 갖추고 블루-그린·카나리 배포 전략과 롤백·릴리스 캘린더를 운영한다. 마지막 운영·거버넌스 단계에서는 RBAC·조직/공간 운영 규정, 비용·용량 관리, 백업·DR 절차를 수립하고 패치·업그레이드 창구를 일원화하며 취약점 대응 SLA를 정한다.

CF 런타임과 K8s 런타임, 무엇을 고를 것인가

런타임 선택은 CF의 단순한 배포·운영 편의성과 K8s의 유연성·에코시스템 확장성 사이의 트레이드오프다. 격리 수준도 강한 네임스페이스/조직 격리와 네트워크 정책 강화 쪽으로 갈수록 노드 자원 효율성이 떨어진다. 서비스 모델은 규제·성능에 유리한 전용 인스턴스와 비용·속도에 유리한 공유 풀 중에서, 시크릿 관리는 통합·간편한 CredHub와 고급 정책·광범위 통합이 가능한 Vault 중에서 고른다. 멀티 AZ·DR은 고가용성·복원력을 높이지만 비용·복잡성이 함께 늘어난다.

항목	CF 런타임	K8s 런타임
성능	빌드팩 기반 표준 런타임 최적화. 오토스케일 정책 간편	커스텀 베이스이미지·사이드카로 세밀 최적화 가능
확장성	앱 단위 수평 확장·블루그린 기본 지원	대규모 워크로드·잡·오퍼레이터 패턴 확장 용이
일관성	조직·공간·카탈로그 표준화 높음	매니페스트·헬름 차트 표준, 팀 자율성 높음
안정성	롤링 업데이트·헬스체크 기본. 무중단 배포 용이	컨트롤러 기반 복구·셀프힐링 강점
운영 편의	cf CLI와 추상화로 쉬운 배포·운영	유연성 높으나 오브젝트 복잡성 관리 필요

Node.js 앱을 CF 런타임에 배포하기

전제조건: PaaS-TA 5.0 환경, 조직/공간 발급, cf CLI v8 이상, Node.js 18 LTS, 마켓플레이스에 MySQL 호환 서비스가 가용해야 한다.

# 로그인
cf login -a https://api.example-paasta domain --sso

# 공간 선택
cf target -o my-org -s dev

# 서비스 인스턴스 생성(플랜 이름은 환경별 상이)
cf create-service mysql small my-mysql

# 앱 매니페스트 작성
cat > manifest.yml <<'YAML'
applications:
  - name: sample-node
    memory: 512M
    instances: 2
    buildpacks:
      - nodejs_buildpack
    env:
      NODE_ENV: production
YAML

# 배포
cf push -f manifest.yml

# 서비스 바인딩 및 재시작 없이 환경 반영
cf bind-service sample-node my-mysql
cf restage sample-node

# 로그 확인
cf logs sample-node --recent

Kubernetes 런타임을 쓸 때는 Helm 차트 또는 Kustomize로 배포하고, ServiceBinding CRD나 시크릿/컨피그맵 기반으로 서비스를 연결한다.

무엇을 얻고 어디까지 확장할 것인가

배포 리드타임은 수일에서 수분 수준으로 70~~90% 단축되고, 릴리스 빈도는 월 1~~2회에서 주 단위 이상으로 3~~5배 늘어날 수 있다. 오토힐링·롤백으로 장애 복구 시간(MTTR)은 30~~60% 개선되고, 밀도·오토스케일로 인프라 비용은 15~30% 절감 가능하다. 표준화된 감사 로그·권한 모델은 규제 준수·감사 대응 시간도 줄여준다. 다만 이 수치는 조직 성숙도·워크로드 특성·운영 체계에 따라 변동 가능하다.

핵심 가치는 표준화된 배포·운영 자동화, 공공·엔터프라이즈 요건에 맞는 보안·거버넌스, 멀티 런타임 유연성이다. 초기에는 CF 우선 도입으로 빠르게 성과를 내고, 점진적으로 K8s를 확장해 팀 역량과 업무 특성에 맞는 운영 모델을 갖추는 편이 안전하다. 세부 컴포넌트와 호환성은 릴리스 노트와 기관 가이드로 최신 정보를 확인해야 한다.