AWS CONTROL PLANE · DEVELOPMENT FIRST

코드에서 안전한 URL까지,
팀에 맞춘 배포 시스템

저장소와 기존 Dockerfile을 분석해 서비스별 배포 계획을 제안하고, 승인된 계획에 따라 빌드·배포·라우팅·상태 확인·감사 기록을 하나로 연결합니다.

PoC 요청하기 동작 방식 보기
  • 01기존 Dockerfile을 실행 계약으로 사용
  • 02외부 HTTPS 접속으로 완료 판정
  • 03요청부터 복구까지 하나의 Correlation ID
DEPLOYMENT PROOFCORR 7F3A-91D2

승인된 계약이 외부 HTTPS와 감사 기록으로 닫힐 때 배포가 완료됩니다.

04접속 정상

외부 검증

컨테이너 시작이 아니라 실제 외부 HTTPS 응답으로 성공을 판정합니다.

200 · route healthy

01 THE GAP

배포를 자동화한 뒤에도
남는 여섯 가지

파이프라인은 돌아가는데, 매번 다시 맞추고 매번 다시 확인합니다.

01

설정의 재구성

프로젝트마다 CI/CD와 서버 설정을 처음부터 다시 맞춥니다.

연결 흐름 보기 →
02

자격증명의 분산

개인 토큰, 장기 AWS 키, 환경 변수가 여러 시스템에 흩어집니다.

권한 분리 보기 →
03

성공의 기준 차이

빌드 성공이 실제 외부 접속 성공을 보장하지 않습니다.

VERIFY 보기 →
04

흩어진 운영 화면

자원, 컨테이너, 도메인, 배포 이력을 각각 다른 곳에서 찾습니다.

운영·관측 보기 →
05

임의로 바뀌는 실행 계약

자동 추론이 실행 방식을 바꾸면 재현성과 책임 경계가 흐려집니다.

AI 플래너 경계 보기 →
06

불확실한 복구 상태

실패 시 이전 정상 버전과 라우팅이 유지되는지 즉시 알기 어렵습니다.

감사·복구 보기 →

02 ONE CONTROL PLANE · THREE PROMISES

자동화보다 먼저,
실행 계약을 고정합니다

승인된 계획대로 빌드·배포·라우팅·상태 확인·감사 기록을 하나로 연결합니다.

CONTRACT

기존 Dockerfile 기준

Dockerfile을 생성하거나 수정하지 않고 실행 계약으로 사용합니다.

VERIFY

외부 HTTPS까지 확인

접수나 컨테이너 시작이 아니라 실제 접속 상태로 완료를 판단합니다.

RECORD

하나의 운영 장부

요청·실행·실패·복구를 동일한 Correlation ID로 연결해 기록합니다.

03 WHAT CHANGES

도입하면 무엇이
달라지는가

새 도구를 하나 더 추가하는 대신, 배포의 계약과 검증 기준을 한 경로로 맞춥니다.

01

맞춤형 배포 계획

앱 루트, build context, 포트, health path, 리소스를 제안합니다.

02

간편한 시작

저장소 URL 하나로 Development 환경과 도메인을 구성합니다.

03

안전한 자동화

사람은 SSO, CI는 단기 OIDC, 배포는 immutable digest만 사용합니다.

04

끝까지 확인하는 배포

접수, 빌드, 할당, 라우팅, 내부·외부 health를 단계별로 확인합니다.

05

운영 사실의 가시화

인벤토리, 배포, Route, Status, Audit을 한 콘솔에서 연결합니다.

06

복구 가능한 변경

이전 정상 revision과 route를 보존하고 보상 결과를 기록합니다.

04 HOW IT WORKS

연결에서 감사 기록까지,
하나의 경로

01

연결·분석

GitHub 저장소 URL 또는 Project ZIP을 등록하고 안전한 정적 분석으로 Dockerfile 후보를 찾습니다.

02사람의 승인 지점

계획·승인

앱 루트, 포트, health path, 리소스와 도메인을 제안하고 사용자가 검토해 승인합니다.

03

빌드·배포

격리 환경에서 이미지를 만들고 immutable digest를 Operation → Jobs → Agent로 전달합니다.

04

검증·기록

컨테이너, Router, 외부 HTTPS를 확인하고 요청부터 복구까지 Correlation ID로 기록합니다.

HUMAN사람

Alpha SSO로 계획을 승인

CIGitHub Actions

단기 OIDC로 배포를 요청

05 IDENTITY BOUNDARIES

권한은 쪼개고,
비밀은 남기지 않습니다

행위자마다 다른 단기 권한을 사용하고, 실행 호스트에는 승인된 이미지 digest만 전달합니다.

01 / HUMAN

사람

Alpha SSO와 Team role로 콘솔·CLI에 접근합니다.

02 / CI·CD

CI/CD

실행마다 발급되는 단기 OIDC JWT만 사용합니다.

03 / GITHUB APP

GitHub App

저장소 분석과 관리 파일 구성에만 단기 installation token을 씁니다.

04 / AWS

AWS 작업

전용 실행 주체가 필요한 시점에 제한된 역할을 assume합니다.

NOT STORED

GitHub Actions에 저장하지 않는 것

  • SSO 쿠키
  • 개인 PAT
  • 장기 AWS Access Key
  • 데이터베이스 접속 정보

실행 호스트는 프로젝트 소스를 받지 않고 승인된 이미지 digest만 수신합니다.

06 CONNECT & DEPLOY

저장소를 잇는
세 가지 방법

PRIMARY

GitHub URL 온보딩

  • 조직에 GitHub App을 한 번 설치한 뒤 저장소 URL로 프로젝트를 연결합니다.
  • 모노레포를 포함한 구조에서 Dockerfile 후보를 탐지합니다.
  • 기본 브랜치 push 시 Actions가 빌드하고 OIDC로 배포를 요청합니다.
DEVELOPMENT · 검증 단계

Project ZIP 배포

  • 브라우저에서 private 스토리지로 직접 업로드하며 Web 서버는 파일 본문을 보관하지 않습니다.
  • 경로 이동, symlink, 비정상 압축률 등을 차단하고 SHA-256을 재검증합니다.
EXPLAIN, NOT EXECUTE

AI 배포 플래너

  • 정적 분석기가 유효한 후보를 만들고 AI는 순위와 설명만 보조합니다.
  • 파일 경로와 검증된 후보 metadata만 전달하고 설정 내용과 소스는 제외합니다.
  • 비정상 응답 시 정적 분석 결과로 fallback합니다.

07 OPERATE & OBSERVE

배포 이후를
같은 화면에서 봅니다

인프라, 환경, Route, Audit을 Correlation ID로 연결해 실패 단계와 보존 상태를 함께 확인합니다.

INFRA / COMPUTE

AWS 인프라·Compute

계정 연결과 인벤토리 동기화, 자원 상태와 예상 기본 비용, 전체 용량과 실제 가용 용량의 분리, Agent heartbeat 확인.

ENV / REVISION

자동 배포·환경 관리

Development 환경 생성·변경·정지, immutable digest 강제, idempotency key로 중복 실행 제어, 환경별 revision 이력 관리.

ROUTE / HEALTH

도메인·TLS·Health

wildcard 도메인 자동 연결과 별도 도메인 Route 등록, 실행 중인 Route에만 허용하는 On-Demand TLS, 내부·Router·외부 상태 구분.

AUDIT / RECOVERY

Audit·장애 조사

행위자·대상·시각·결과와 Correlation ID 기록, Secret redaction과 역할 기반 조회, 마지막 정상 revision과 실패 단계 확인.

08 CURRENT SCOPE

지금 제공하는 범위를
먼저 밝힙니다

도입 판단에 필요한 경계를 그대로 공개합니다.

Alpha Stage 현재 제공 범위
구분현재 범위
클라우드현재 범위 아님AWS 중심 · 멀티클라우드는 현재 범위 아님
기본 배포 대상Development workload
소스 연결Private/Internal GitHub 저장소 URL, Project ZIP(검증 단계)
실행 계약프로젝트가 소유한 기존 Dockerfile 필수
자동화GitHub App, Actions OIDC, GHCR immutable image
운영 화면AWS, Resource, Compute, Projects, Environments, Deployments, Router, Status, Audit
Production workload조건부별도 도메인·보호 정책·승격 검증 후 활성화

FIT CHECK우리 환경이 현재 범위에 맞는지 먼저 확인하세요.

PoC 요청하기

09 ADOPTION

다섯 단계로 시작합니다

  1. 01

    요구사항 확인

    저장소 구조, AWS 계정·리전, 도메인, 운영 역할을 확인합니다.

  2. 02

    연결 구성

    SSO Team 권한, AWS 실행 역할, GitHub App을 최소 권한으로 연결합니다.

  3. 03

    프로젝트 생성

    저장소를 등록하고 제안된 Dockerfile, port, health path를 검토합니다.

  4. 04

    첫 배포 검증

    작은 workload로 digest, Route, 외부 health, Audit을 함께 확인합니다.

  5. 05

    운영 정책 확장

    팀 권한, Secret Reference, 복구 절차와 승격 조건을 정의합니다.

10 PROOF OF CONCEPT

저장소 한 개와 기존
Dockerfile이면 시작할 수 있습니다

Development 환경, 도메인, 자동 배포 Workflow까지 한 번에 구성해 드립니다.

BEFORE WE START

PoC 준비 항목

아래 항목은 첫 배포 검증 계획을 정리하기 위한 기준입니다. 폼에서 모두 필수로 받지는 않습니다.

  • 01대상 GitHub 조직과 저장소
  • 02Dockerfile 경로와 build context
  • 03서비스 port와 health path
  • 04AWS 계정, 리전, 기존 Compute
  • 05Development 도메인 계획
  • 06필요 CPU·메모리와 예상 트래픽
  • 07환경 변수와 Secret 구분
  • 08승인자·운영자·조회자 역할
REQUEST FORM

PoC 요청

필수 표시 항목만 먼저 알려 주세요.

대상 조직과 대략적인 저장소 수
0 / 1200
실제 운영 전 개인정보 수집·이용 문구와 처리방침 URL 확정이 필요합니다.

현재 접수 경로는 메일입니다. 보내기를 누르면 입력한 내용이 메일 초안으로 열리며, 이 페이지는 어떤 값도 서버에 저장하지 않습니다.

11 FAQ

도입 전에 자주
확인하는 경계

01AWS 외 다른 클라우드도 되나요?

현재 범위는 AWS 중심이며 멀티클라우드는 포함되지 않습니다.

02Dockerfile이 없어도 되나요?

프로젝트가 소유한 기존 Dockerfile이 필수입니다. Alpha Stage는 Dockerfile을 생성하거나 수정하지 않고 실행 계약으로만 사용합니다.

03AI가 배포 방식을 바꾸나요?

아닙니다. 유효한 후보는 정적 분석기가 만들고 AI는 순위와 설명만 보조하며, 비정상 응답이면 정적 분석 결과로 fallback합니다.

04소스 코드가 실행 호스트에 저장되나요?

실행 호스트는 프로젝트 소스를 받지 않고 승인된 이미지 digest만 수신합니다. GitHub Actions에는 SSO 쿠키·개인 PAT·장기 AWS Access Key·DB 접속 정보를 저장하지 않습니다.

05Production 워크로드도 올릴 수 있나요?

기본 배포 대상은 Development workload이며, Production은 별도 도메인·보호 정책·승격 검증 후 활성화합니다.