OZ-Group/AriWeb-Suite
8
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5da1f6fa374a7d20c996981d8ec9c50b493611cd
AriWeb-Suite/Ariweb-Suitle_Dev-Order.md
T
oz 5da1f6fa37 Add Ariweb Suite development order
2026-10-26 09:37:23 +00:00

69 KiB
Raw Blame History

Ariweb Suite 개발 지시 — Dev-Order

작성자: Neo
작성일: 2026-10-26 09:27:15 UTC
문서 종류: Ariweb Suite 전체 개발·통합·검증·배포 지시서
대상 저장소: https://source.ibit.kr/OZ-Group/AriWeb-Suite
기준 계획서: 2026-10-26_Ariweb_Suite_HAL_통합개발계획서_1차_완성본.md
문서 상태: 최초 개발 지시 v1.0

파일명 주의: Ariweb-Suitle_Dev-Order.md는 사용자가 지정한 문자열을 그대로 보존한 파일명이다. 공식 제품명은 문서 전체에서 Ariweb Suite로만 사용한다.

목적: HAL을 Ariweb Suite의 중앙 Control Plane으로 개발하고, 기존 AriMail·Webmaker·Gitea·백업·호스팅·관측 도구를 검증 가능한 기능 모듈로 통합한다. 고객은 단일 Portal에서 서비스를 이용하고, 운영자는 HAL에서 여러 서버와 모든 모듈을 배치·운영·감시·제한·복구·이전할 수 있어야 한다. 개발 산출물과 배포 정본은 모두 OZ-Group/AriWeb-Suite에 수렴시킨다.

요약: 먼저 OZ-Group의 관련 소스를 전수 조사하고 기준 commit과 재사용 범위를 고정한다. 이후 공통 계약, HAL Core, Identity, Agent/Registry/Secret, 상품·권리·사용량 원장, Customer Portal, Webmaker, Web Hosting, AriMail, Gitea Source, 유료 사이트 백업, 관측, DNS/TLS, 재배치, 소유권 이전과 보존 기능을 모듈 단위로 구현한다. 최초 부트스트랩에서는 HAL을 먼저 배포한다. HAL이 정상화된 뒤 HAL Node Agent를 통해 나머지 Suite 구성요소를 필요한 서버에 설치·업데이트·운영·관리한다. 운영 배포는 승인·백업·rollback·실제 read-back을 모두 통과한 경우에만 수행한다.

개정 이력

  • 2026-10-26 / v1.0: Ariweb Suite 1차 완성 계획서와 AriMail·Webmaker Dev-Order 형식을 반영해 최초 개발 지시 작성.
  • 2026-10-26 / v1.1: 구현 정합성 감사 반영. Commerce·allocation 반환·BFF·Object Storage·Internal DR·quota lease·relocation preflight·HAL bootstrap trust chain·break-glass·artifact 정본 규칙을 보강.

/goal

https://source.ibit.kr/OZ-Group/AriWeb-Suite를 기반으로 HAL 중심의 Ariweb Suite 통합 관리·운영 플랫폼을 개발한다.

Ariweb Suite는 다음 목표를 동시에 만족해야 한다.

  1. 여러 대의 Webmaker, 웹 호스팅, AriMail, Gitea, 백업, 관측 서버를 HAL 한 곳에서 등록·배치·설치·업데이트·중지·복구·이전·감사할 수 있어야 한다.
  2. 고객은 개별 서버에 로그인하지 않고 webmaker.ariweb.net Customer Portal 한 곳에서 사이트 제작, 배포, 도메인, 메일, 상품, 사용량, 백업 옵션과 복원 요청을 관리해야 한다.
  3. 운영자는 고객 Portal과 분리된 hal.ariweb.net에서 서버·서비스·용량·슬롯·장애·작업·secret reference·재배치를 관리해야 한다.
  4. Webmaker는 제작 도구, Web Hosting은 실행 Data Plane, AriMail은 메일 Data Plane, Gitea는 Source Data Plane으로 분리해야 한다.
  5. HAL 또는 Webmaker가 중단되어도 이미 배포된 웹·메일·Git 서비스는 계속 작동해야 한다.
  6. 상품 권리, 사이트별 보장 할당, 실제 사용량, 물리 서버 수용력을 서로 다른 원장으로 관리해야 한다.
  7. 관리형 서비스와 고객 외부 서버 배포를 명확히 분리해야 한다.
  8. 고객용 백업은 모든 서비스의 공통 기능이 아니라 유료 백업 Option을 구매한 관리형 Site에만 제공해야 한다.
  9. 개발 결과물, 배포 manifest, 운영 runbook, module source와 release artifact의 정본은 OZ-Group/AriWeb-Suite여야 한다.
  10. 최초에는 HAL을 먼저 부트스트랩하고, 이후 HAL이 나머지 모듈을 필요한 서버에 배포·운영·관리해야 한다.

0. 정본 저장소와 참조 소스 지시

0.1 최종 정본

개발·통합·배포의 최종 정본은 다음 저장소로 고정한다.

https://source.ibit.kr/OZ-Group/AriWeb-Suite

다음 산출물은 반드시 이 저장소에 저장한다.

  • HAL Control Plane 전체 소스
  • Customer Portal과 HAL Console 소스
  • 공통 API·event·policy contract
  • Node Agent와 External Pull Agent
  • Webmaker·AriMail·Gitea·Backup·Hosting adapter
  • 배포에 사용하는 Webmaker·AriMail 통합 component source 또는 재현 가능한 pinned import
  • DB schema와 migration
  • Infra-as-Code와 배포 manifest
  • test fixture와 수용 테스트
  • ADR, threat model, runbook, release note, CHANGELOG
  • module inventory와 upstream provenance
  • release artifact 생성·서명·검증 절차

운영 배포는 반드시 AriWeb-Suite 저장소의 tag 또는 immutable commit으로 재현할 수 있어야 한다.

0.2 반드시 참고할 기존 소스

개발 전에 다음 소스를 모두 조사한다.

  • AriMail: https://source.ibit.kr/OZ-Group/AriMail
  • Webmaker: https://source.ibit.kr/OZ-Group/WebHosting_AI_agent
  • 관련 전체 조직: https://source.ibit.kr/OZ-Group

OZ-Group 안에서 다음 기능을 제공하거나 관련성이 있는 저장소를 추가로 찾는다.

  • Gitea 설치·운영·연동
  • 웹 배포·nginx·TLS·DNS·도메인 관리
  • 백업·복구·원격 복제·보존
  • 모니터링·로그·알림·상태 페이지
  • 인증·OIDC·권한·조직 계정
  • 결제·청구·사용량·quota
  • 서버 Agent·원격 설치·업데이트
  • Secret Broker·Vault·PKI
  • object storage·artifact repository
  • 운영 자동화·deployment script

조사 시 사용자 credential로 접근 가능한 OZ-Group 저장소 목록을 programmatic하게 열거하고 중복을 제거한다. 저장소 이름만 보고 판단하지 말고 README, 현재 main, CHANGELOG, 배포 문서, 테스트와 핵심 코드를 확인한다.

0.3 기존 소스 사용 규칙

기존 소스에서 필요한 내용을 가져와 사용할 때 다음을 지킨다.

  1. 가져올 원본 저장소 URL, branch, commit SHA, 원본 path를 기록한다.
  2. 기능별로 REUSE_AS_IS, ADAPT, REWRITE, REJECT 중 하나를 결정한다.
  3. 보안 취약점, 단일 서버 가정, 파일 기반 상태, 직접 SSH, 평문 secret, 불완전 backup은 그대로 복사하지 않는다.
  4. 코드를 가져올 때 license와 provenance를 보존한다.
  5. 가능한 경우 Git history를 보존하는 subtree 또는 명시적 vendor/import 절차를 사용한다.
  6. 단순 copy인 경우 source commit과 checksum을 docs/provenance/에 기록한다.
  7. AriMail·Webmaker upstream이 이후 변경되더라도 운영 배포는 AriWeb-Suite에 승인·통합된 component revision만 사용한다.
  8. 통합 후 운영 hotfix를 AriMail·Webmaker 저장소에만 남겨두지 않는다. 최종 수정은 AriWeb-Suite 정본에도 반드시 반영한다.
  9. 외부 저장소를 production runtime에서 직접 pull해 배포하지 않는다.
  10. 배포 manifest는 AriWeb-Suite 내부 component digest만 참조한다.
  11. Git submodule, build-time remote import, mutable package URL처럼 clean checkout만으로 재현할 수 없는 외부 의존 방식을 사용하지 않는다.
  12. 필요한 upstream source는 AriWeb-Suite 안으로 history-preserving subtree 또는 immutable vendored snapshot으로 가져온다.
  13. history-preserving import는 source와 destination의 (path, mode, type, object-id) tree tuple을 비교하고 source HEAD가 destination history의 ancestor인지 검증한다.
  14. snapshot import는 archive hash와 최종 file tree hash를 provenance manifest에 기록한다.
  15. direct·transitive dependency lockfile, compiler/runtime toolchain version, base image digest를 고정한다.
  16. SPDX 식별자, license compatibility 판단, NOTICE·저작권 고지를 보존한다.

0.4 초기 기준

개발 시작 시 다음 과거 기준을 참고하되 현재 상태를 다시 확인한다.

  • Webmaker 조사 기준: v1.7.3, commit 3b10859884ef2fd0f2af11934ab6c16370fd64b8
  • AriMail 조사 기준: v1.0.11, commit a07f69f1ffb6667de6e66b3d1ec43c1c66fab924
  • Webmaker 과거 test 기준: 52/52
  • AriMail 과거 test 기준: 96/97
  • AriMail의 알려진 시간대 의존 usage test 실패는 통합 전에 고정 clock 기반으로 수정한다.

이 값은 현재 상태를 보장하지 않는다. 작업 시작 시 실제 main, version, test 결과와 dirty state를 다시 기록한다.

1. 개발 공통 지시

1.1 작업 방식

각 기능 모듈은 다음 순서로 개발한다.

  1. 요구사항과 선행 dependency 확인
  2. 현재 코드와 데이터 흐름 조사
  3. ADR 또는 module design 작성
  4. 실패하는 테스트 작성
  5. RED 원인 확인
  6. 최소 구현
  7. 해당 테스트 GREEN 확인
  8. module 전체 테스트
  9. contract·integration 테스트
  10. security·tenant isolation 검토
  11. 실제 상태 read-back
  12. 독립 코드 리뷰
  13. CHANGELOG와 완료 보고 갱신

구현 후 테스트를 붙이는 방식을 기본 절차로 사용하지 않는다.

1.2 코드 품질

  • 함수·클래스·모듈의 목적을 한국어 주석으로 설명한다.
  • parameter, return, side effect, 오류, 권한, idempotency, fencing, 보상 로직의 이유를 설명한다.
  • 코드가 그대로 말하는 내용을 반복하는 장식성 주석은 넣지 않는다.
  • API와 event schema는 machine-readable source에서 문서를 생성한다.
  • 코드·schema·문서가 불일치하면 완료 처리하지 않는다.
  • 모든 주요 상태는 enum과 상태기계로 명시하고 자유 문자열로 처리하지 않는다.
  • 변경 API는 idempotency key와 optimistic concurrency를 사용한다.
  • timeout을 성공 또는 명백한 실패로 추정하지 않는다.

1.3 비밀값과 개인정보

다음 위치에 password, token, API key, private key, .env 값, 고객 개인정보를 저장하지 않는다.

  • Git repository
  • Markdown
  • issue·PR
  • source comment
  • test fixture
  • log·trace·metric label
  • audit payload
  • backup manifest
  • deployment receipt
  • 완료 보고

HAL DB에는 secret 원문이 아니라 SecretRef만 저장한다. 실제 secret은 승인된 Secret Broker에서 lease 방식으로 가져온다.

1.4 오류 수정

  • 오류는 먼저 재현한다.
  • 재현되지 않은 추정 수정은 금지한다.
  • 환경 설정 오류와 코드 결함을 구분한다.
  • 코드 결함은 회귀 테스트를 추가한다.
  • 외부 provider 오류는 provider receipt와 correlation ID를 보존하되 secret을 제거한다.
  • 일시적 timeout 뒤 blind retry하지 말고 실제 상태를 reconcile한다.

1.5 완료 판정

다음만으로 완료 처리하지 않는다.

  • command exit code 0
  • process가 실행 중임
  • port가 열려 있음
  • Agent가 성공이라고 응답함
  • DB row가 ACTIVE임
  • backup 파일이 존재함

필요한 경우 실제 DNS, TLS, HTTPS content marker, mail 외부 왕복, Git clone, restore 결과까지 read-back한다.

2. 목표 repository 구조

다음 논리 구조를 기본으로 사용한다. Phase 0 ADR에서 build system에 맞게 조정할 수 있으나 모듈 경계를 합치지 않는다.

AriWeb-Suite/
├─ Ariweb-Suitle_Dev-Order.md
├─ README.md
├─ CHANGELOG.md
├─ apps/
│  ├─ customer-portal/
│  └─ hal-console/
├─ services/
│  ├─ hal-api/
│  ├─ identity-bff/
│  ├─ resource-graph/
│  ├─ commerce/
│  ├─ entitlement-ledger/
│  ├─ allocation-ledger/
│  ├─ usage-ledger/
│  ├─ placement-scheduler/
│  ├─ workflow-engine/
│  ├─ reconciler/
│  ├─ backup-orchestrator/
│  ├─ relocation-orchestrator/
│  ├─ notification/
│  ├─ audit-incident/
│  └─ status-page/
├─ components/
│  ├─ webmaker/
│  ├─ web-hosting/
│  ├─ arimail/
│  ├─ gitea/
│  └─ backup/
├─ packages/
│  ├─ contracts/
│  ├─ db/
│  ├─ authz/
│  ├─ policy/
│  ├─ idempotency/
│  ├─ fencing/
│  ├─ observability/
│  └─ test-fixtures/
├─ agents/
│  ├─ node-agent/
│  └─ external-pull-agent/
├─ adapters/
│  ├─ webmaker/
│  ├─ hosting/
│  ├─ arimail/
│  ├─ gitea/
│  ├─ backup/
│  ├─ dns/
│  ├─ registrar/
│  ├─ object-storage/
│  ├─ payment/
│  └─ secret-broker/
├─ migrations/
├─ deploy/
│  ├─ bootstrap-hal/
│  ├─ manifests/
│  ├─ policies/
│  └─ rollback/
├─ infra/
│  ├─ dev/
│  ├─ test/
│  ├─ staging/
│  └─ production/
├─ tests/
│  ├─ contract/
│  ├─ integration/
│  ├─ e2e/
│  ├─ security/
│  ├─ fault-injection/
│  ├─ relocation/
│  └─ restore-drill/
└─ docs/
   ├─ adr/
   ├─ provenance/
   ├─ threat-model/
   ├─ api/
   ├─ runbooks/
   ├─ releases/
   └─ reports/

3. 모듈 M00 — Source Inventory와 Baseline

목표

AriMail, Webmaker 및 OZ-Group 안의 관련 소스를 조사하고 재사용할 기능과 폐기할 기능을 결정한다.

개발 지시

  1. 접근 가능한 OZ-Group 저장소를 열거한다.
  2. 각 저장소의 default branch, HEAD SHA, version, 언어, license, 최근 변경일을 기록한다.
  3. AriMail과 Webmaker는 전체 test baseline을 실행한다.
  4. 백업, Gitea, 배포, DNS, TLS, 관측, 인증, Agent와 관련된 저장소를 분류한다.
  5. 중복 기능은 구현 성숙도·테스트·보안·운영 검증 수준을 비교한다.
  6. docs/provenance/SOURCE_INVENTORY.md를 만든다.
  7. 기능별 재사용 결정을 docs/adr/ADR-000-source-consolidation.md에 기록한다.
  8. 가져올 source tree와 history 보존 방식을 결정한다.
  9. 운영 배포의 모든 component가 AriWeb-Suite commit으로 재현되는지 확인한다.

필수 산출물

  • Source inventory
  • baseline test report
  • source-to-module mapping
  • provenance manifest
  • rejected component와 사유
  • migration 위험 목록

완료 조건

  • AriMail·Webmaker 현재 main SHA와 test 결과가 기록됨
  • 관련 source의 조사 범위와 접근 한계가 명시됨
  • 각 Suite 모듈의 source provenance가 결정됨
  • 출처를 알 수 없는 코드가 없음

4. 모듈 M01 — 공통 Contract와 Resource Model

목표

모든 Suite 모듈이 공유할 ID, API, event, 상태기계, 오류, capability 계약을 만든다.

필요한 기능

  1. UUID 기반 immutable resource ID
  2. Organization tenant scope
  3. resource version과 optimistic concurrency
  4. idempotency key
  5. operation ID, job ID, correlation ID
  6. desired generation과 observed generation
  7. fencing token과 assignment epoch
  8. typed error code, retryability, human message
  9. module capability와 NOT_SUPPORTED
  10. API·event schema versioning
  11. N/N-1 compatibility 선언
  12. OpenAPI와 event schema validation
  13. customer-facing BFF session과 operator session의 별도 contract
  14. Workspace와 Site ACL
  15. BillingAccount와 tenant-scoped billing ownership

핵심 resource

  • Organization
  • UserIdentity
  • Membership
  • RoleTemplate
  • CapabilityGrant
  • Site
  • WebmakerProject
  • SourceBinding
  • Build
  • Artifact
  • Release
  • DomainBinding
  • MailService
  • SiteMailBinding
  • Mailbox
  • ServiceAssignment
  • PhysicalServer
  • ModuleInstance
  • ServiceInstance
  • ProductVersion
  • Subscription
  • EntitlementGrant
  • QuotaAllocation
  • QuotaReservation
  • UsageEvent
  • Workflow
  • OperationReceipt
  • BackupSubscription
  • RestorePoint
  • RelocationJob
  • OwnershipTransfer
  • SecretRef
  • AuditEvent
  • Incident

수용 기준

  • 같은 resource를 모듈마다 서로 다른 ID로 재정의하지 않음
  • customer API와 HAL admin API schema가 분리됨
  • stale version update가 거부됨
  • 같은 idempotency key와 다른 body 사용 시 충돌 반환
  • N/N-1 contract test 통과

5. 모듈 M02 — HAL Core Control Plane

목표

HAL을 Ariweb Suite의 중앙 desired-state·workflow·운영 정본으로 만든다.

필요한 기능

5.1 Resource Graph

  • Organization→Site→Project→Artifact→Assignment→Instance 관계
  • Organization→MailService→Mailbox 관계
  • Site→Source→Gitea repository 관계
  • Site→BackupSubscription→RestorePoint 관계
  • physical server→module instance→service assignment 관계
  • 소유권과 lifecycle 조회
  • resource별 audit timeline

5.2 Desired/Observed Reconciliation

  • desired spec과 observed status 분리
  • reconcile queue
  • generation compare
  • stale observation 표시
  • drift detection
  • safe auto-remediation과 operator-required remediation 구분
  • timeout 후 UNKNOWN 또는 RECONCILING

5.3 Durable Workflow

  • workflow, job, step, attempt
  • retry·backoff·deadline
  • lease·fencing
  • transactional outbox/inbox
  • compensation과 finalizer
  • approval wait state
  • operation receipt
  • crash 후 resume
  • 중복 실행 방지

공통 상태는 다음을 기준으로 하고 module별로 필요한 상태만 명시적으로 확장한다.

REQUESTED
→ POLICY_CHECKED
→ ENTITLEMENT_RESERVED
→ CAPACITY_RESERVED
→ PLACED
→ PREPARING
→ EXECUTING
→ VERIFYING
→ ACTIVE

보조·실패 상태:

AWAITING_APPROVAL
WAITING_EXTERNAL
RECONCILING
PARTIAL_ACTIVE
UNKNOWN
PAUSED
ABORTED
FAILED
NEEDS_ATTENTION
ROLLING_BACK
ROLLED_BACK
CANCELLED

5.4 운영 콘솔

hal.ariweb.net에 다음 화면을 만든다.

  • 전체 서버·모듈 inventory
  • service placement와 assignment
  • capacity·slot·actual usage
  • workflow queue와 실패·reconcile
  • alert·incident
  • backup·restore 상태
  • relocation 상태
  • secret rotation 상태
  • audit·support access
  • version drift와 update ring

5.5 HAL 접근 통제

  • VPN 또는 사설망
  • 별도 비공개 gateway 경로
  • 사용자·기기 귀속 단기 gateway credential
  • 별도 HAL 관리자 계정
  • capability 검사
  • fresh reauthentication
  • 고객 token으로 HAL API 접근 금지
  • Customer Portal과 다른 OAuth client·audience·cookie·CORS·CSRF

MFA는 현재 결정에 따라 선택사항으로 제공하되 비의무화 위험을 threat model에 남긴다.

운영자 MFA 선택 정책은 확정된 사용자 결정이므로 이 지시서에서 임의로 뒤집지 않는다. 다만 phishing-resistant MFA를 권장 상태로 제공하고, 비의무화 잔여 위험·보완통제·사고 대응을 GA 보안 검토와 release acceptance에 명시한다.

고위험 작업

다음은 3단계 승인 없이는 실행하지 않는다.

  • 서버·instance 삭제
  • 대량 restore
  • secret·certificate 회전
  • mail relocation
  • purge
  • ownership transfer
  • 대규모 routing cutover

승인은 동일 버튼 3회가 아니라 영향 확인, immutable ID 확인, 최종 실행 확인으로 분리한다.

완료 조건

  • HAL DB가 desired state의 정본으로 동작
  • Agent read-back 없는 작업을 완료로 표시하지 않음
  • workflow worker crash 후 중복 side effect 없이 복구
  • 고객 계정으로 HAL 접근 불가
  • HAL 장애 중 기존 Data Plane serving 지속

6. 모듈 M03 — Identity, Organization, Membership, Authorization

목표

1인 사용자와 그룹 사용자를 하나의 Organization 모델로 지원한다.

필요한 기능

  1. 가입 시 1인 Organization과 Owner Membership 자동 생성
  2. 멤버 추가로 그룹 계정 전환
  3. user-01, user-02 형식의 표시 alias 자동 생성
  4. alias가 아닌 immutable identity·membership UUID로 권한 판정
  5. 구성원별 별도 password, session, audit actor
  6. 구성원 정지 시 해당 session·token·pending job만 차단
  7. Site, domain, subscription, allocation은 Organization에 유지
  8. 역할 template와 resource scope
  9. RBAC+ABAC 결합
  10. 외부 recovery email을 이용한 password reset
  11. JIT customer-support access
  12. membership 초대·만료·취소
  13. service account와 workload identity
  14. OIDC issuer·client·audience와 BFF session 계약
  15. Customer Portal BFF의 CSRF·cookie·session revocation
  16. Workspace와 Site ACL
  17. BillingAccount와 Organization의 1:N 또는 정책화된 관계
  18. 권한 변경 직후 queue·worker 실행 시 capability 재검사

기본 역할

  • Organization Owner
  • Organization Admin
  • Billing Admin
  • Workspace Admin
  • Site Builder
  • Content Editor
  • Deployment Approver
  • Domain/DNS Manager
  • Mail Manager
  • Backup Requester
  • Audit Viewer
  • Service Account
  • HAL System Operator

필수 테스트

  • 독립 계정이 자계정 없이 사용 가능
  • 멤버 추가 전후 Site ID와 subscription 불변
  • alias 변경이 권한에 영향 없음
  • cross-tenant ID 주입 거부
  • member 정지 후 다른 member 세션 유지
  • JIT support 만료 후 접근 거부
  • customer token으로 admin API 거부

7. 모듈 M04 — Physical Server Registry, Node Agent, Secret Broker

목표

HAL이 여러 서버를 안전하게 등록하고 제한된 명령만 실행하도록 한다.

필요한 기능

7.1 Registry

  • PhysicalServer
  • region과 network zone
  • ModuleInstance
  • ServiceInstance
  • software·schema version
  • capability
  • maintenance·drain·quarantine
  • heartbeat·clock skew
  • certificate 상태
  • volume·listener·runtime inventory

7.2 HAL Node Agent

  • 1회용 activation code
  • 서버 로컬 key pair 생성
  • outbound mTLS
  • stable instance ID
  • allowlist된 typed primitive
  • 임의 shell 문자열 실행 API 금지
  • signed update
  • canary update ring
  • previous version rollback
  • offline result buffer
  • desired/observed generation
  • operation receipt

7.3 CapacityVector

각 resource dimension에 다음을 저장한다.

  • physical total
  • system reserved
  • scheduler allocatable
  • placement reserved
  • allocated
  • actual usage
  • soft limit
  • hard limit
  • observed_at
  • freshness
  • exhaustion forecast

7.4 Secret Broker

  • HAL DB에는 SecretRef만 저장
  • short-lived credential lease
  • platform·organization·site·instance scope
  • internal PKI와 mTLS
  • key rotation·revocation
  • runtime key와 backup key 분리
  • secret access audit
  • UI에서 secret 원문 재표시 금지

7.5 Object Storage·Artifact Registry

  • Organization·Site·artifact별 namespace와 immutable object ID
  • workload identity 기반 최소권한 credential lease
  • signed manifest와 artifact digest 결속
  • server-side encryption과 key scope 분리
  • object lock·versioning·retention·purge receipt
  • upload 완료 후 size·checksum read-back
  • multi-part upload의 orphan cleanup
  • capacity·replication·integrity monitoring
  • release artifact는 content-addressed digest로 조회
  • AriWeb-Suite release manifest가 object digest를 참조하며 object storage 자체를 source 정본으로 간주하지 않음

완료 조건

  • 임의 shell 실행 거부
  • stale server 배치 제외
  • quarantine 즉시 command·lease·placement 차단
  • private key가 node 밖으로 나오지 않음
  • secret 원문이 DB·log·trace에 없음
  • 잘못된 tenant credential로 다른 artifact를 읽거나 덮어쓸 수 없음
  • manifest digest와 실제 object checksum이 다르면 배포 거부
  • Agent N/N-1 호환

8. 모듈 M05 — Product, Commerce, Entitlement, Allocation, Usage, Billing

목표

상품 구매 권리, 사이트별 보장 할당, 실제 사용량, 청구를 일관되게 연결한다.

필요한 기능

8.1 상품 Catalog

  • Product
  • immutable ProductVersion
  • Price
  • base product
  • Add-on
  • BillingAccount
  • Order·OrderItem
  • Subscription
  • SubscriptionItem
  • EntitlementGrant
  • AddonSubscription
  • Invoice·InvoiceLine
  • PaymentAttempt
  • CreditNote
  • OverageAuthorization
  • manual payment approval
  • 향후 PG webhook
  • refund·credit adjustment
  • PolicyVersion과 CoveragePolicy

상품명, 가격, 구체 용량이 확정되기 전에는 placeholder를 고객에게 판매하지 않는다.

Commerce 상태와 규칙:

  • 결제 전 Order는 PENDING_PAYMENT다.
  • payment 또는 승인 receipt가 확인되기 전 entitlement를 활성화하지 않는다.
  • payment webhook과 수동 승인 재시도는 같은 OrderItem에 grant 하나만 만든다.
  • Add-on은 SubscriptionItem과 유효기간을 가진다.
  • downgrade가 active allocation과 pending reservation을 침범하면 즉시 적용하지 않고 PENDING_DOWNGRADE로 둔다.
  • invoice와 credit는 기존 원장을 수정하지 않고 append-only ledger entry로 기록한다.
  • customer Portal에서 상품 비교→주문→결제 상태→subscription→invoice→credit까지 조회할 수 있어야 한다.

8.2 기본 entitlement 차원

  • 운영 Site 수
  • 관리형 웹 disk
  • 관리형 월간 web egress
  • 관리형 mail storage
  • 관리형 월간 mail send+receive 통수
  • mailbox 수

8.3 Add-on

  • Site slot
  • web disk
  • web egress
  • mail storage
  • mail message count
  • mailbox count
  • 독립 MailService domain
  • large attachment max size
  • Gitea Source/history
  • Paid Site Backup
  • monthly booster

8.4 별도 청구

  • AI Wallet/Cache
  • 외부 서버 배포 건별 비용
  • 도메인 등록·갱신
  • 고객 요청 region relocation
  • 고객 backup restore 요청

8.5 보장 Allocation

다음 불변식을 transaction race에서도 유지한다.

sum(active allocations) + sum(pending reservations)
<= active organization entitlement

active_site_slots + pending_publish_reservations
<= active_site_slot_entitlement

active_independent_mailservices + pending_mail_activation_reservations
<= active_mailservice_option_grants
  • 실제 사용량이 적어도 allocation을 자동 반환하지 않는다.
  • draft Site는 slot과 관리형 allocation을 요구하지 않는다.
  • 첫 public publish 전에 Site slot을 예약한다.
  • MANAGED assignment 활성화 전에 관리형 allocation과 physical capacity를 예약한다.
  • EXTERNAL_UNMANAGED WEB에는 관리형 disk·egress allocation을 만들지 않는다.
  • 독립 MailService 활성화 전에 Option과 mail allocation을 예약한다.
  • entitlement downgrade는 allocation과 pending reservation보다 작아질 수 없다.

Allocation 축소·반환 규칙:

  • web disk는 실제 제한 사용량보다 작게 축소하지 않는다.
  • monthly web egress와 mail message allocation은 현월 누적 usage보다 작게 축소하지 않는다.
  • mail storage는 실제 mail storage보다 작게 축소하지 않는다.
  • mailbox allocation은 active+suspended mailbox 수보다 작게 축소하지 않는다.
  • Site slot 반환 전 WEB serving 중지, public WEB DomainBinding 분리, 고객 영향 표시, 명시 확인, pending deploy·restore·relocation 부재를 검증한다.
  • HAL ledger와 Data Plane actual usage를 read-back한 뒤 allocation을 반환한다.
  • SITE_BOUND mail을 계속 운영하려면 Site slot 반환 전에 INDEPENDENT MailService로 전환하고 Option과 mail allocation을 확보한다.
  • Portal은 Site·MailService별 allocation 변경 요청, 축소 가능량, 반환 workflow와 차단 사유를 제공한다.

8.6 Usage Ledger

  • append-only event
  • global event ID
  • producer ID, stream epoch, sequence
  • assignment epoch
  • occurred_at과 received_at
  • KST monthly UsagePeriod
  • duplicate·out-of-order 처리
  • adjustment event
  • meter freshness
  • signed bounded quota lease

HAL 연결이 끊기거나 quota lease가 stale인 경우:

  • 기존 web serving, mail 읽기, 기존 content 조회, delete·export는 유지한다.
  • 사용량을 증가시키는 upload·DB write·deploy·SMTP submission·inbound acceptance는 fail-closed한다.
  • Data Plane은 stale lease를 unlimited 또는 0 usage로 해석하지 않는다.
  • 연결 복구 후 local reservation과 event를 reconcile한 뒤 증가 작업을 재개한다.

8.7 경고와 hard limit

  • 70% 정보
  • 85% 경고
  • 95% 긴급
  • 100% 제한
  • Portal inbox와 외부 email
  • automatic overage 기본 OFF
  • 고객 사전 동의 cap을 넘는 자동 과금 금지

완료 조건

  • 동시 allocation 경쟁에서 초과 판매 없음
  • 중복 payment·usage event 이중 반영 없음
  • 월 경계가 KST 기준과 일치
  • entitlement와 physical capacity가 분리됨
  • AI Wallet과 subscription ledger가 분리됨

9. 모듈 M06 — Customer Portal과 API Gateway

목표

고객이 webmaker.ariweb.net 한 곳에서 모든 서비스를 관리하게 한다.

필요한 기능

  1. Organization과 membership 관리
  2. Site 생성·편집·배포·중지
  3. domain 연결과 상태
  4. Webmaker project 연결
  5. 관리형 또는 외부 WEB deployment 선택
  6. Site-bound mail과 독립 MailService 관리
  7. mailbox 관리
  8. 상품·Add-on·Order·subscription 조회
  9. 상품 구매, Add-on 증설, 결제 대기·승인·실패, invoice·credit 조회
  10. Site·MailService별 보장 allocation 설정·축소·반환 요청
  11. 조직 총량, resource allocation, actual usage 분리 표시
  12. 70/85/95/100 경고
  13. Paid Site Backup 구매와 상태
  14. 유료 restore 요청·가격 확인·결제 상태
  15. Source Add-on과 repository 연결
  16. ownership transfer 요청
  17. notification inbox
  18. job 상태와 실패 사유
  19. 고객별 audit projection

정보 노출 제한

고객 API는 allowlist projection을 사용한다. 다음 정보를 노출하지 않는다.

  • physical server ID·hostname·IP
  • 다른 tenant 정보
  • 전체 server capacity
  • 내부 incident detail
  • provider credential reference
  • secret reference
  • 운영자용 placement 사유 원문

외부 배포에는 current uptime·healthy·managed usage·backup protected를 표시하지 않는다. 마지막 deploy receipt와 시각만 표시한다.

완료 조건

  • Portal에서 개별 서버 로그인 요구 없음
  • 고객이 자기 resource만 조회·변경
  • 물리 서버 정보 미노출
  • 제한된 동작과 유지되는 동작이 명확히 표시
  • job 상태가 backend와 불일치하지 않음

10. 모듈 M07 — Webmaker Integration Module

목표

기존 Webmaker의 제작·편집 기능을 재사용하되 중앙 Identity, Site, Entitlement와 연결한다.

재사용 기능

  • AI에게 맡기기, 내가 고르기
  • Site Brief
  • AI 생성·수정
  • module과 template
  • preview
  • domain·DNS·TLS 경험
  • Gitea source history 경험
  • deploy stage와 rollback 경험
  • AI Wallet/Cache

재구성할 기능

  1. 기존 local user를 HAL principal·membership에 mapping
  2. Site와 WebmakerProject 분리
  3. draft Site는 운영 Site slot 미소비
  4. build job을 durable workflow로 변경
  5. source revision, artifact digest, SBOM, signature 생성
  6. artifact를 object storage에 immutable하게 저장
  7. 관리형·외부 WEB assignment 선택
  8. publish 전에 entitlement와 allocation 검사
  9. AI Wallet과 hosting subscription 분리
  10. 중앙 audit·usage event 전송
  11. local secret을 SecretRef로 전환
  12. Webmaker 장애 중 deployed Site 영향 없음
  13. Project 삭제와 Site·Source·Deployment 삭제 분리
  14. 기존 파일 기반 상태를 shadow read→backfill→cutover 방식으로 이전
  15. management_mode를 Site가 아니라 WEB ServiceAssignment 속성으로 저장
  16. active assignment의 management_mode 직접 UPDATE를 금지하고 새 assignment를 만드는 reprovision·relocation workflow로만 변경

금지

  • user-01 문자열로 권한 판정
  • local users.json을 최종 identity 정본으로 사용
  • local credit JSON을 보장 allocation 원장으로 사용
  • root SSH deployment를 HAL 표준 계약으로 사용
  • 현재 통계를 billing-grade 원장으로 바로 사용
  • Webmaker project 삭제 시 운영 Site 자동 삭제

완료 조건

  • 기존 제작 기능 회귀 없음
  • Site와 Project lifecycle 분리
  • signed immutable artifact 생성
  • publish race에서 Site slot 중복 소비 없음
  • active assignment의 MANAGED↔EXTERNAL 직접 변경 거부
  • AI 비용과 hosting quota 분리
  • deployed Site가 Webmaker 중지 중에도 제공됨

11. 모듈 M08 — Managed Web Hosting과 External Pull Deployment

목표

Webmaker와 독립된 Web Hosting Data Plane을 만들고 관리형·외부 배포를 분리한다.

11.1 관리형 Hosting

필요한 기능:

  • HAL Deployment Agent
  • static runtime
  • dynamic runtime sandbox
  • Site별 persistent namespace
  • logical·physical disk meter
  • edge egress meter
  • signed artifact 검증
  • staged deploy
  • atomic activation
  • rollback
  • nginx·TLS·HTTPS read-back
  • quota limit page
  • bounded policy lease
  • backup adapter
  • relocation primitive

웹 disk 사용량은 다음 중 큰 값으로 계산한다.

max(logical persistent bytes, attributed filesystem bytes)

웹 egress는 최외곽 관리형 edge가 고객에게 실제 전달한 byte만 계산한다. health check, synthetic, origin fill, 내부 replication, backup, restore, relocation, deploy upload는 제외한다.

11.2 hard limit

Egress 100%

  • 즉시 Ariweb 제한 안내 페이지
  • 고객 content 삭제 금지
  • Portal·결제·Add-on 경로 유지
  • 다음 KST 월 시작 또는 Add-on 적용 후 복구

Disk 100%

  • 신규 upload·파일·DB 증가 차단
  • build activation·deploy 차단
  • 기존 Site 공개 serving 유지
  • delete·export 허용

11.3 External Pull Agent

  • 고객 외부 서버에 설치
  • signed artifact와 short lease만 pull
  • HAL에서 임의 root shell 실행 금지
  • 운영 Site slot 적용
  • 배포 건별 청구
  • AI Wallet 별도
  • Source Add-on 별도
  • 관리형 disk·traffic·monitoring·backup·restore·relocation·SLA 미적용
  • last deploy receipt만 Portal 표시
  • versioned 책임 고지 동의

1차 범위에서 외부 WEB은 지원하지만 외부 MAIL은 지원하지 않는다.

완료 조건

  • 관리형과 외부 책임 범위가 UI·API·billing에서 혼동되지 않음
  • 실제 disk·egress hard enforcement 작동
  • static·dynamic managed Site 배포 가능
  • external target 장애를 Ariweb healthy로 표시하지 않음
  • 같은 artifact 재배포가 idempotent
  • HAL quota lease가 stale이면 기존 serving은 유지되고 증가 작업은 거부됨

12. 모듈 M09 — AriMail Integration Module

목표

AriMail의 multi-domain·webmail·SMTP·IMAP·POP3 기능을 HAL의 Identity·Entitlement·Allocation·Placement·Workflow와 통합한다.

12.1 P0 선행 수정

통합 작업 전에 다음을 RED→GREEN으로 수정한다.

  1. usage.test.mjs의 KST/UTC 현재 시각 의존성
  2. provider 선택과 무관하게 특정 provider key를 선행 요구하는 오류가 현재 코드에 존재하는지 재검증하고, 존재하면 provider별 조건으로 수정
  3. 전체 AriMail test suite 통과
  4. P0 수정과 HAL adapter 작업을 별도 commit으로 유지
  5. P0 수정본은 반드시 AriWeb-Suite의 components/arimail 또는 동일한 정본 component history에 commit한다.
  6. AriMail upstream에도 반영할 경우 upstream commit을 다시 AriWeb-Suite로 import하고 tree hash를 검증한다.
  7. upstream 반영 여부와 무관하게 production 배포는 AriWeb-Suite에 포함된 revision만 사용한다.

12.2 MailService 모델

  • MailService.kind = SITE_BOUND | INDEPENDENT
  • Site마다 대표 SITE_BOUND mail domain 하나
  • 대표 domain 변경은 relocation workflow
  • 추가 mail-only domain은 INDEPENDENT MailService Option
  • 독립 MailService는 운영 Site 수 미소비
  • 한 domain 아래 여러 mailbox 허용
  • SITE_BOUND와 INDEPENDENT 모두 mail allocation 요구
  • 1차 MAIL assignment는 MANAGED만 허용
  • active와 suspended mailbox 모두 mailbox allocation을 소비
  • alias와 forwarding-only route의 account-count 규칙은 후속 정책으로 분리

12.3 HAL 관리 기능

  • stable instance·cluster ID
  • mTLS 관리 API
  • domain desired/observed reconcile
  • account·alias·route reconcile
  • placement
  • active-owner fencing
  • capacity·slot 보고
  • storage·message·mailbox allocation 집행
  • usage event
  • provider·DNS 상태
  • planned relocation
  • config-only DR export

12.4 통수 계측

  • 발신+수신 합산
  • 최종 수신자 1명당 1통
  • alias 확장 후 같은 최종 mailbox 중복 dedupe
  • 내부 mailbox 간 mail은 발신 1, 수신 1
  • retry와 webhook replay는 delivery ID로 dedupe
  • outbound는 SMTP 제출 수락 직전 예약, 수락 성공 시 usage 전환
  • inbound는 mailbox commit 직전 예약, commit 성공 시 usage 전환
  • 실패한 reservation 해제

12.5 저장량

포함:

  • message raw
  • 일반 첨부
  • inline 첨부
  • link 방식 대용량 object
  • 필수 mailbox metadata

제외:

  • backup·snapshot 복제본
  • temporary provider spool 중복
  • relocation 임시 복사본

12.6 제한

Storage 100%

  • 신규 수신 SMTP 4xx
  • 기존 읽기·삭제·export 허용
  • silent drop 금지

Message count 100%

  • 신규 발송 차단
  • 신규 수신 SMTP 4xx
  • 기존 mailbox 읽기·삭제 허용

안전 정책

  • 일반 첨부 최대는 ProductVersion 값
  • 더 높은 platform absolute cap
  • 수신자 수는 anti-abuse 정책
  • POP3·IMAP 개별 ON/OFF
  • 평문 인증 기본 차단, TLS 요구
  • 대용량 첨부는 별도 Option
  • 대용량 다운로드 횟수·보관기간은 무제한 금지
  • 구체 수치는 후속 상품정책
  • 초당 10건 이상의 SMTP 제출은 자동 제한·경고·abuse 판정
  • domain queue와 server queue의 실제 outbound delivery는 각각 초당 5건 이내

12.7 메일 백업 금지와 DR

고객용 message backup·restore 상품을 만들지 않는다.

  • Site 연결 mail 고객 backup 없음
  • 독립 MailService 고객 backup 없음
  • 내부 DR은 server/domain/account 설정만 export
  • EML, body, attachment, folder, flag, queue payload 제외
  • secret 원문 대신 SecretRef
  • relocation temporary copy는 operation-scoped, encrypted, TTL purge
  • relocation copy를 고객 restore catalog에 노출하지 않음

12.8 외부 검증

  • DNS MX·SPF·DKIM·DMARC
  • TLS
  • outbound provider accept
  • 외부 inbox 도착
  • reply 수신
  • IMAP·POP3·webmail

listener가 열렸다는 이유만으로 완료 처리하지 않는다.

완료 조건

  • Site-bound와 Independent MailService 분리
  • domain당 active writer 하나
  • 저장량·통수 hard limit 실제 동작
  • message usage 중복 없음
  • 고객 restore point에 Mail이 없음
  • config-only DR에 message content가 없음
  • 실제 외부 send→receive→reply 통과
  • HAL quota lease stale 상태에서 read·delete는 유지되고 신규 send·receive acceptance는 거부됨

13. 모듈 M10 — Gitea Source Module

목표

Gitea를 Site source/history Data Plane으로 연결하되 Identity·상품·배포 정본으로 사용하지 않는다.

필요한 기능

  1. OIDC SSO
  2. Gitea instance registry
  3. Organization·team·repository desired state
  4. immutable Site↔repository ID mapping
  5. repository-scoped credential
  6. branch protection
  7. webhook signature·timestamp·replay 검증
  8. source revision→artifact→deployment provenance
  9. repository·LFS·attachment 사용량
  10. Source Add-on quota
  11. Add-on 만료 시 read-only
  12. 30일 clone·export 보존
  13. 30일 후 purge workflow
  14. platform integrity backup
  15. ownership transfer 시 source 포함 여부와 권한 이전

완료 조건

  • repository 이름이 아니라 immutable ID로 연결
  • 고객 credential scope가 해당 repository로 제한
  • Source Add-on 미구매 고객에게 history 보장 표시 없음
  • Site Backup과 Gitea backup 혼동 없음
  • source revision과 release digest 추적 가능

14. 모듈 M11 — Paid Site Backup, Internal DR, Restore

목표

관리형 Site 구매자용 유료 백업과 플랫폼 내부 DR을 분리한다.

14.1 Paid Site Backup

대상:

  • Option을 구매한 관리형 Site

보호 범위:

  • 관리형 deployment
  • dynamic DB
  • upload·persistent data
  • active release와 복구 metadata
  • vhost·TLS·DNS desired-state reference

제외:

  • Webmaker project
  • Gitea Source/history
  • AriMail message content
  • external deployment
  • platform shared data

필요한 기능:

  • Site-scoped BackupSubscription
  • versioned fixed schedule·retention policy
  • full 또는 logical full
  • incremental·dedup
  • Daily·Weekly·Monthly rotation
  • signed immutable manifest
  • offsite encrypted copy
  • object lock 또는 append-only catalog
  • capacity-aware chain pruning
  • restore quote·payment·operator approval
  • isolated restore validation
  • pre-restore checkpoint
  • activation·verification·rollback
  • Option expiry 후 7일 purge
  • Site 공개 운영 중지 즉시 신규 backup 생성 중단
  • 기존 restore point는 Option 또는 service 만료 시점까지 유지
  • retained incremental child가 의존하는 base 삭제 금지
  • 새 정상 backup 없이 최소 retention set 삭제 금지
  • capacity 부족으로 최소 set을 유지할 수 없으면 신규 backup을 실패 처리하고 증설 안내
  • 자동 overage 또는 유효 backup의 무조건 삭제 금지

주기·보존 개수·가격은 후속 ProductVersion에서 확정한다.

14.2 Backup 종류 분리

  • PaidBackupRestorePoint: 고객이 요청 가능한 Site backup
  • InternalDRArchive: platform 전체 복구용, 고객 접근 금지
  • MigrationCheckpoint: 작업용 임시 보호점, 고객 접근 금지

세 종류는 catalog namespace, encryption key scope, authorization을 분리한다.

14.3 Restore workflow

REQUESTED
→ PRICED
→ CUSTOMER_CONFIRMED
→ PAYMENT_CONFIRMED
→ OPERATOR_REVIEWED
→ ARCHIVE_SELECTED
→ STAGED
→ STRUCTURE_VALIDATED
→ DATA_VALIDATED
→ PRE_RESTORE_POINT_CREATED
→ ACTIVATED
→ SERVICE_VERIFIED
→ COMMITTED

보조·실패 상태:

AWAITING_APPROVAL
WAITING_EXTERNAL
ROLLING_BACK
ROLLED_BACK
FAILED
NEEDS_ATTENTION

보안 검증

  • restore point Organization·Site·Subscription 결속
  • tenant scope가 다른 artifact 거부
  • path traversal 거부
  • escaping symlink 거부
  • secret file entry 거부
  • 서명·checksum 불일치 거부

완료 조건

  • Option 없는 Site에 customer restore point 없음
  • Mail customer restore point 없음
  • offsite copy 실제 검증
  • incremental child가 의존하는 base 삭제 금지
  • 격리 복원과 실제 HTTPS 확인
  • Internal DR과 MigrationCheckpoint가 customer API에서 조회되지 않음

14.4 Platform Internal DR

고객 상품과 별도로 다음 Control Plane 구성요소의 DR을 개발한다.

  • HAL database와 workflow state
  • Identity provider/BFF configuration
  • Secret Broker metadata·sealed recovery material
  • internal PKI와 certificate issuance state
  • Resource Graph·Entitlement·Allocation·Usage ledger
  • Webmaker project metadata
  • deployment manifest와 artifact catalog
  • audit·incident metadata

Internal DR 지시:

  1. component별 capture scope와 제외 대상을 schema allowlist로 정의한다.
  2. RPO/RTO 수치는 사전 약속하지 않고 restore drill로 측정한다.
  3. 암호화 key와 recovery key의 보관 주체를 분리한다.
  4. 별도 장애 영역에 immutable copy를 둔다.
  5. clean environment에서 HAL→IdP→Secret Broker→ledger→worker 순으로 복구한다.
  6. row count, ledger head, workflow lease, certificate chain, artifact digest를 read-back한다.
  7. restore drill 없이 archive 생성 성공만 보고하지 않는다.
  8. 고객은 InternalDRArchive를 조회·선택·복원할 수 없다.

15. 모듈 M12 — Observability, Alert, Incident, Status Page

목표

서버·서비스·고객 resource 상태와 용량을 시각적으로 확인하고 장애를 통지한다.

필요한 기능

운영자 화면

  • 전체 server heatmap
  • CPU·RAM·disk·inode·IO·network
  • total·reserved·allocatable·allocated·actual·hard limit
  • service slot
  • version drift
  • Agent heartbeat·clock skew·certificate
  • Site·Mail placement
  • quota pressure와 exhaustion forecast
  • backup repository capacity와 validation freshness
  • workflow queue·retry·dead-letter
  • relocation state
  • alert·incident timeline

고객 화면

  • 자기 Site·MailService 상태
  • MANAGED·EXTERNAL badge
  • entitlement·allocation·actual usage
  • 월 reset 시각
  • meter freshness
  • quota warning과 제한 상태
  • paid backup 보호 상태
  • external deploy 마지막 receipt

Synthetic

웹:

  • DNS
  • TLS
  • HTTPS
  • content marker
  • quota limit page

메일:

  • listener
  • provider accept
  • external inbox delivery
  • reply
  • IMAP·POP3·webmail

Gitea:

  • OIDC
  • repository read
  • sample clone
  • webhook

보존

  • 상세 운영 metric 90일
  • usage·billing ledger는 계약·회계·법정 기간
  • public status와 internal incident detail 분리

완료 조건

  • stale metric을 green으로 유지하지 않음
  • desired ACTIVE와 external availability 분리
  • 고객 화면에 물리 서버 정보 없음
  • alert에서 Portal과 외부 email 작동
  • correlation ID로 API→workflow→Agent→provider 추적 가능

16. 모듈 M13 — DNS, TLS, Registrar, Provider Integration

목표

domain 구매, DNS, TLS, mail provider 작업을 adapter로 분리하고 실제 반영을 검증한다.

필요한 기능

  1. Domain order와 registration state
  2. registrar adapter
  3. DNS provider adapter
  4. record desired/observed
  5. idempotent create·update·delete
  6. ownership marker
  7. propagation 확인
  8. TLS issue·renew·revoke
  9. MX·SPF·DKIM·DMARC
  10. provider domain verification
  11. provider receipt
  12. manual action required 상태
  13. rollback 또는 compensation

금지

  • provider timeout 후 blind create retry
  • 이름이 같다는 이유로 기존 record 자동 인수
  • API response에 secret 포함
  • DNS 변경 성공만으로 서비스 완료 판정

완료 조건

  • authoritative DNS read-back
  • TLS hostname·chain·expiry 검증
  • mail provider domain 실제 verified
  • provider API가 없을 때 정확한 manual instruction 제공
  • 외부 변경의 immutable receipt 보존

17. 모듈 M14 — Placement와 서비스 재배치

목표

HAL이 관리형 서비스를 자동 배치하고 안전하게 다른 서버로 이전한다.

17.1 Placement

필수 조건:

  • service capability 일치
  • instance ACTIVE
  • metric FRESH
  • software·schema 호환
  • 허용 region
  • disk·inode·CPU·RAM·network·slot 여유
  • entitlement와 resource allocation
  • provider·DNS·object storage 연결성
  • maintenance·drain·quarantine 아님

결정마다 후보, 제외 사유, capacity snapshot을 기록한다.

17.2 공통 relocation 상태

REQUESTED
→ AUTHORIZED
→ PREFLIGHTED
→ TARGET_RESERVED
→ INITIAL_COPY
→ CATCHING_UP
→ READY_TO_CUTOVER
→ FINAL_QUIESCE
→ FINAL_DELTA
→ ROUTING_CUTOVER
→ VERIFYING
→ ACTIVE_ON_TARGET
→ SOURCE_DRAINING
→ SOURCE_RELEASED
→ COMPLETED

보조·실패 상태:

AWAITING_APPROVAL
WAITING_EXTERNAL
PAUSED
ABORTED
FAILED
ROLLING_BACK
ROLLED_BACK
NEEDS_ATTENTION

모든 relocation은 시작과 cutover 직전에 다음을 검증한다.

  • source가 현재 active owner임
  • source와 target Agent heartbeat·metric이 fresh임
  • software·schema·contract가 호환됨
  • target capacity와 temporary copy space가 예약됨
  • backup·restore·relocation lock 충돌이 없음
  • DNS·TLS·provider·SecretRef 접근이 정상임
  • immutable manifest와 checksum이 일치함
  • assignment epoch와 fencing token이 최신임
  • 검증 중 조건이 바뀌면 cutover를 중단하고 preflight를 다시 수행함

17.3 정적 WEB

  • 1차 자동 relocation 대상
  • 고객 건별 승인 불필요
  • 사전·완료 통지
  • target에 같은 artifact digest
  • target 검증 전 routing 변경 금지
  • DNS cache 동안 source와 target 동일 content
  • 실제 source·target egress 모두 계측

17.4 동적 WEB

  • 운영자 승인
  • upload seed
  • DB replication 또는 dump/restore
  • maintenance/read-only
  • source writer fence
  • final delta
  • target 검증
  • target write 후 검증되지 않은 단순 rollback 금지

17.5 MAIL

  • 운영자 승인
  • domain당 active writer 하나
  • mailbox·EML·attachment·UID·flag·queue·ledger 일관 이동
  • source writer fence
  • target writer activation
  • source는 RELAY_ONLY로 drain
  • source에서 mailbox write·local delivery·outbound queue 금지
  • delivery ID 유지
  • target commit에서 usage 한 번만 기록
  • 외부 round trip 검증

17.6 과금과 임시 데이터

  • target은 MIGRATION_TEMP platform capacity 사용
  • copy·validation traffic은 고객 usage 제외
  • cutover 후 실제 serving traffic은 고객 usage 포함
  • assignment epoch로 이중 writer·이중 과금 방지
  • MigrationCheckpoint는 encrypted·TTL·purge receipt
  • platform 사유 relocation 무료
  • 고객 요청 region relocation 별도 청구

완료 조건

  • target capacity 예약 전 copy 없음
  • 양쪽 active writer 없음
  • target 검증 전 routing cutover 없음
  • 실패 후 데이터 유실·중복 과금 없음
  • source 보존기간 전 purge 없음

18. 모듈 M15 — Ownership Transfer, Retention, Purge

목표

에이전시 고객 Site 이전과 서비스 해지 후 보존·삭제를 안전하게 관리한다.

18.1 Ownership Transfer

필요 조건:

  • 에이전시 승인 또는 계약·domain proof
  • 운영자 검토
  • target Ariweb account와 Organization
  • target 상품·Add-on
  • target allocation 예약
  • pending deployment·restore·relocation 없음

기본 이전 대상:

  • Site
  • managed deployment
  • DomainBinding
  • SITE_BOUND MailService와 mailbox
  • Paid Backup Subscription과 restore point

자동 이전하지 않을 대상:

  • AI Wallet
  • 조직 공용 미할당 entitlement
  • invoice·payment history
  • 다른 Site와 공유하는 권리
  • 독립 MailService는 명시 선택 시만 포함

분쟁 중에는 serving을 유지하고 변경·삭제·이전을 동결한다.

18.2 Retention state

ACTIVE
→ CANCEL_SCHEDULED
→ RETAINED_READ_ONLY
→ PURGE_PENDING
→ PURGED

보조 상태:

  • HELD
  • REACTIVATING

RETAINED_READ_ONLY 데이터는 종료된 customer allocation이 아니라 내부 RETENTION_HOLD capacity로 관리한다.

18.3 보존기간

  • managed Web data: 해지 후 30일
  • Mail: 송수신 중지 후 30일 read·export
  • Gitea Source: read-only 30일 clone·export
  • Paid Backup: Option 만료 후 7일

legal·incident·dispute hold가 있으면 purge를 중지한다. 모든 purge는 finalizer와 receipt를 남긴다.

완료 조건

  • target entitlement 부족 시 transfer 거부
  • partial ownership이 고객에게 노출되지 않음
  • purge 전 hold와 immutable ID 재확인
  • 보존기간 중 물리 capacity가 추적됨
  • purge receipt와 audit 존재

19. 모듈 M16 — HAL First Bootstrap와 통합 배포 시스템

목표

모든 배포에서 AriWeb-Suite를 정본으로 사용하고, HAL을 먼저 배포한 뒤 HAL이 나머지 모듈을 배포·운영하게 한다.

19.1 부트스트랩 원칙

HAL은 자기 자신이 존재하기 전에 자신을 배포할 수 없으므로 최초 설치에만 최소 bootstrap 절차를 사용한다.

HAL 이전에 수동으로 준비할 수 있는 Bootstrap Foundation은 다음 폐쇄 목록뿐이다.

  1. HAL database
  2. durable workflow storage
  3. Secret Broker의 최소 bootstrap instance
  4. internal PKI root/intermediate의 초기 trust anchor
  5. initial operator identity를 확인할 bootstrap authentication path
  6. content-addressed artifact registry/object storage의 최소 instance
  7. HAL endpoint용 reverse proxy·TLS
  8. 첫 관리 node의 Node Agent bootstrap package

이 목록 밖의 Customer Portal, Identity service 본체, commerce·ledger, Webmaker, Hosting, AriMail, Gitea, Backup, DNS/TLS adapter, Observability, Status Page는 HAL 이후 HAL이 배포한다.

Bootstrap Foundation도 영구 수동 관리 대상으로 남기지 않는다. HAL 정상화 직후 각 component를 Registry에 등록하고 desired state, version, health, backup, update, certificate rotation을 HAL 관리로 인수한다. 인수 완료 전 production GA를 금지한다.

초기 trust chain:

  • 보호된 AriWeb-Suite commit과 서명된 release tag를 사용한다.
  • offline 또는 별도 보호된 release trust root로 manifest signature를 검증한다.
  • 실행 전 source commit, artifact digest, SBOM digest, signature를 검증한다.
  • bootstrap CA fingerprint를 out-of-band로 고정한다.
  • activation code는 짧은 TTL·1회 사용·instance scope를 가지며 사용 즉시 폐기한다.
  • initial operator bootstrap credential은 1회용으로 발급하고 정식 operator identity 등록 후 즉시 revoke한다.
  • bootstrap host에 남은 token·temporary file·installer credential을 삭제하고 purge receipt를 남긴다.

최초 순서:

  1. AriWeb-Suite의 승인된 release tag와 commit 고정
  2. release artifact·SBOM·signature 생성
  3. HAL DB, workflow storage, Secret Broker 연결 준비
  4. HAL API와 worker 배포
  5. HAL Console 배포
  6. HAL health, DB migration, authentication, audit 확인
  7. HAL Control Plane release digest read-back
  8. HAL에 최초 관리 server와 operator 등록
  9. Node Agent activation code 발급
  10. 대상 server에 Node Agent 설치·mTLS 등록
  11. Bootstrap Foundation을 HAL 관리 resource로 인수
  12. bootstrap credential·activation material 폐기
  13. HAL에서 나머지 Suite component 배포 시작

bootstrap script는 위 폐쇄 목록과 HAL만 설치한다. Webmaker·Hosting·AriMail·Gitea·Backup·Customer Portal·Identity 본체·Commerce·Ledger·DNS/TLS adapter·Observability·Status Page를 직접 운영 배포하지 않는다.

19.2 HAL 이후 배포

HAL은 다음을 수행한다.

  • node inventory와 capability 확인
  • target placement
  • capacity reservation
  • short-lived credential lease
  • signed artifact 전달
  • typed install/update primitive 실행
  • configuration desired state 적용
  • migration
  • process·listener read-back
  • external synthetic 검증
  • canary→ring 확대
  • 실패 시 rollback 또는 reconcile
  • operation receipt와 audit

19.3 배포 정본

배포 시 모든 module source와 manifest는 다음을 기준으로 한다.

https://source.ibit.kr/OZ-Group/AriWeb-Suite

금지:

  • 운영 server에서 AriMail 또는 Webmaker 저장소 최신 main 직접 pull
  • branch 이름만으로 배포
  • mutable latest image만 사용
  • source commit을 알 수 없는 binary 배포
  • HAL 외 수동 작업을 정상 배포 방식으로 유지

각 component는 AriWeb-Suite release manifest 안에서 다음을 가진다.

  • component name
  • version
  • AriWeb-Suite commit
  • upstream source URL·commit
  • artifact digest
  • SBOM digest
  • signature
  • schema compatibility
  • required capability
  • migration digest
  • rollback artifact

Git repository는 source·manifest·provenance의 정본이고, content-addressed Artifact Registry는 그 manifest가 가리키는 immutable build 결과 저장소다. Registry는 별도 source authority가 아니다.

  • artifact object는 digest 주소, immutable retention, encryption, offsite replication을 가진다.
  • release가 지원되는 동안 manifest가 참조하는 artifact를 보존한다.
  • manifest→registry fetch 후 실제 object digest를 다시 계산한다.
  • clean AriWeb-Suite checkout, lockfile, pinned toolchain·base image만으로 artifact를 재현할 수 있어야 한다.
  • reproducible build가 byte-identical하지 않은 구성은 원인을 기록하고 source-to-artifact attestation으로 보완한다.

19.4 HAL 자체 업데이트

HAL은 self-update를 일반 workload와 동일하게 무제한 수행하지 않는다.

  • 별도 release approval
  • standby 또는 canary HAL instance
  • DB expand migration 우선
  • N/N-1 worker compatibility
  • API compatibility
  • leader fencing
  • health·workflow resume 확인
  • rollback window

19.5 배포 완료 조건

  • HAL이 먼저 정상화됨
  • 이후 component가 HAL operation으로 배포됨
  • target 실제 version과 manifest digest 일치
  • migration 상태 일치
  • process·listener·external probe 통과
  • rollback artifact 존재
  • operation receipt와 audit 존재

실행 바이트 read-back 기준:

  • container: registry manifest digest와 runtime image ID
  • package/binary: 설치 package digest와 실행 binary hash
  • script/tree deployment: signed release tree hash
  • configuration: loaded config generation과 non-secret digest
  • database: schema migration version과 migration digest
  • self-reported version 문자열만으로 일치 판정하지 않음

19.6 Break-glass 복구

HAL이 동작하지 않아 HAL 자체 복구가 불가능할 때만 break-glass 절차를 사용한다.

  • 대상은 HAL, HAL DB, Secret Broker, PKI, Artifact Registry, initial Node Agent connectivity로 제한한다.
  • 별도 보관된 runbook과 최소권한 emergency credential을 사용한다.
  • 3단계 고위험 확인, incident ID, 작업 녹화 또는 immutable command log를 요구한다.
  • emergency credential은 시간 제한·대상 제한·1회성으로 발급한다.
  • 서비스 복구 직후 credential을 폐기한다.
  • HAL 정상화 후 실제 상태를 Registry와 reconcile한다.
  • break-glass로 변경된 내용은 desired state와 AriWeb-Suite source에 역반영한다.
  • 일반 workload 배포나 편의 목적 수동 변경에는 사용하지 않는다.

20. 모듈 M17 — Security, Audit, Supply Chain

목표

tenant isolation, secret 보호, software supply chain과 운영 감사 기능을 구축한다.

필요한 기능

  1. threat model
  2. data classification
  3. customer/admin trust boundary
  4. RBAC+ABAC policy decision point
  5. 모든 API·worker·queue·Agent에서 동일 정책 재검사
  6. CSRF·CORS·SSRF·XSS·injection 방어
  7. preview origin 격리
  8. artifact signing
  9. SBOM
  10. dependency audit
  11. secret scanning
  12. container·runtime sandbox
  13. network policy
  14. mTLS
  15. append-only audit
  16. support access audit
  17. destructive action approval
  18. backup encryption과 key scope 분리
  19. vulnerability response와 patch ring
  20. provenance verification

필수 보안 테스트

  • cross-tenant object ID 접근
  • customer token으로 admin API
  • stale fencing write
  • Agent arbitrary shell
  • SSRF target allowlist 우회
  • webhook replay
  • artifact signature 변조
  • restore archive path traversal
  • secret in log·trace·audit
  • expired credential lease
  • support grant scope와 expiry
  • preview script의 management session 접근

완료 조건

  • critical·high 미해결 취약점 없이 release gate 통과
  • secret 원문이 source와 telemetry에 없음
  • 모든 destructive action에 actor·scope·target·approval 기록
  • provenance 없는 artifact 배포 거부

21. 모듈 M18 — Test, QA, Fault Injection, Acceptance

목표

기능 구현뿐 아니라 장애·동시성·복구·실제 서비스 동작을 검증한다.

테스트 계층

  1. unit
  2. property-based
  3. contract
  4. migration
  5. integration
  6. end-to-end
  7. security
  8. fault injection
  9. load·rate limit
  10. backup restore drill
  11. relocation drill
  12. canary read-back

필수 fault mode

  • explicit failure
  • timeout before mutation
  • timeout after mutation
  • duplicate callback
  • out-of-order event
  • worker crash
  • stale generation
  • stale fencing token
  • network partition
  • partial read-back
  • malformed receipt
  • secret-bearing provider response
  • disk full
  • quota race
  • target capacity loss

핵심 수용 시나리오

  1. 독립 사용자가 가입하고 1인 Organization 생성
  2. 멤버 추가 후 기존 Site 유지
  3. draft Site는 slot 미소비
  4. publish 시 slot과 allocation atomic reservation
  5. HAL이 Hosting server 자동 배치
  6. 실제 HTTPS 검증
  7. 70·85·95·100 경고와 제한
  8. disk 100%에서도 기존 serving·delete 유지
  9. external Pull deploy와 건별 charge
  10. external runtime이 managed monitoring·backup에서 제외
  11. SITE_BOUND MailService 활성화
  12. INDEPENDENT MailService 활성화, Site 수 미증가
  13. 실제 mail send→receive→reply
  14. IMAP·POP3·webmail
  15. mail storage·message hard limit
  16. Paid Backup 구매 Site만 restore point 생성
  17. offsite backup과 실제 격리 restore
  18. 정적 Site 자동 relocation
  19. 동적 Site 승인 relocation
  20. Mail 승인 relocation과 단일 writer
  21. Site ownership transfer
  22. service cancellation과 retention
  23. legal hold 중 purge 거부
  24. HAL 장애 중 기존 Data Plane 지속
  25. Webmaker 장애 중 deployed Site 지속
  26. worker crash 후 중복 side effect 없음
  27. N/N-1 rolling update

GA 차단 조건

다음 중 하나라도 충족하지 못하면 production GA를 금지한다.

  • HAL·IdP·Secret Broker DR drill
  • 실제 Site restore
  • 실제 외부 mail 왕복
  • cross-tenant security test
  • quota concurrency test
  • relocation rollback·forward-fix test
  • secret scan
  • signed release provenance
  • production rollback rehearsal

22. 모듈 M19 — Documentation, CHANGELOG, Runbook, 완료 보고

목표

모든 구현과 운영 절차를 재현 가능하게 문서화한다.

필요한 문서

  • README
  • architecture overview
  • module map
  • ADR
  • OpenAPI·event docs
  • database schema
  • threat model
  • source provenance
  • deployment bootstrap
  • HAL operations runbook
  • Node Agent enrollment
  • secret rotation
  • incident response
  • backup·restore
  • relocation
  • ownership transfer
  • retention·purge
  • rollback
  • disaster recovery
  • release note
  • CHANGELOG

CHANGELOG 기록

각 release에 다음을 적는다.

  • 무엇을 변경했는가
  • 왜 변경했는가
  • 어떤 module인가
  • upstream source와 commit
  • migration 영향
  • compatibility 영향
  • security 영향
  • test 결과
  • 배포 여부
  • 남은 작업과 미확정 정책

배포하지 않았으면 배포 완료라고 쓰지 않는다.

완료 보고 형식

Release:
AriWeb-Suite commit/tag:
Component digest:
Upstream source revisions:
Changed modules:
Changed files:
DB migrations:
RED evidence:
GREEN evidence:
Full tests:
Security tests:
Fault tests:
Deployment environment:
HAL operation ID:
Read-back evidence:
External verification:
Rollback evidence:
Known limitations:
Deferred policy values:

23. 실제 개발 순서

다음 순서를 지킨다. 선행 Gate를 통과하지 않은 상태에서 후속 모듈을 production 권한과 연결하지 않는다.

Phase 0 — 조사와 안전 기반

  1. M00 Source Inventory
  2. AriMail·Webmaker baseline
  3. P0 오류 수정
  4. M01 공통 Contract
  5. architecture ADR
  6. threat model
  7. fake adapter harness

Gate: current source·test·schema·위협 모델이 확인되지 않으면 HAL worker에 실제 변경 권한을 주지 않는다.

Phase 1 — HAL·Identity 기초

  1. M02 HAL Core skeleton
  2. M03 Identity·Organization
  3. Customer/Admin trust boundary
  4. Audit와 JIT support
  5. high-risk approval

Gate: tenant isolation과 HAL 접근 통제 검증.

Phase 2 — Registry·Agent·Secret·Observability 기초

  1. M16 Bootstrap Foundation과 HAL-first test deployment
  2. M04 Registry
  3. Node Agent
  4. mTLS·PKI
  5. Secret Broker
  6. Artifact Registry·Object Storage
  7. CapacityVector
  8. M12 기본 dashboard·alert
  9. Bootstrap Foundation의 HAL 관리 인수

Gate: HAL이 먼저 기동되고 Foundation을 인수한 뒤 stale·quarantine·arbitrary shell·secret·artifact digest test를 통과한다.

Phase 3 — Product와 원장

  1. M05 ProductVersion
  2. Entitlement
  3. Guaranteed Allocation
  4. Usage Ledger
  5. Billing Ledger
  6. notification

Gate: fake meter로 동시성·월 경계·중복 event 불변식 통과.

Phase 4 — WEB vertical slice

  1. M06 Customer Portal 기본
  2. M07 Webmaker integration
  3. M08 Managed Hosting
  4. External Pull Agent
  5. Gitea Source catalog interface
  6. 실제 meter와 hard limit
  7. static relocation
  8. dynamic approved relocation

Gate: Site 생성→artifact→관리형/외부 배포→실제 HTTPS 전체 경로 통과.

Phase 0~1은 local process와 fake adapter만 사용할 수 있다. Phase 2부터 shared test, staging, production-like 환경의 component 배포는 HAL을 통해 수행한다. 개발자가 local unit test를 실행하는 것과 운영 형태의 service deployment를 구분하며, 수동 test deployment를 장기 운영 경로로 남기지 않는다.

Phase 5 — MAIL vertical slice

  1. M09 MailService
  2. AriMail HAL adapter
  3. domain·mailbox lifecycle
  4. allocation·meter·hard limit
  5. DNS·provider
  6. 외부 왕복
  7. planned relocation
  8. config-only DR

Gate: 실제 외부 send→receive→reply, IMAP·POP3·webmail, 단일 writer 통과.

Phase 6 — Backup vertical slice

  1. M11 Paid Backup
  2. offsite encrypted copy
  3. immutable catalog
  4. paid restore workflow
  5. 실제 격리 restore
  6. expiry·purge

Gate: backup 생성이 아니라 실제 restore와 HTTPS 검증 통과.

Phase 7 — Gitea·Lifecycle·Ownership

  1. M10 Gitea OIDC·quota
  2. Source retention
  3. M15 ownership transfer
  4. service retention·purge
  5. dispute hold

Gate: 부분 소유권 노출·cross-tenant source 접근·조기 purge 없음.

Phase 8 — Production 승격·HA·DR

  1. M16 production Bootstrap Foundation 재현과 인수 검증
  2. HAL HA
  3. IdP·Secret Broker DR
  4. Webmaker internal DR
  5. AriMail config-only DR
  6. load·failover·rolling update
  7. restore·relocation drill
  8. public status와 incident process
  9. SLA 측정

GA Gate: HAL·IdP·Secret Broker DR과 실제 복구 drill 전 production GA 금지.

24. 배포 지시

24.1 배포 전

  • AriWeb-Suite branch와 commit 고정
  • clean working tree
  • 모든 required check 통과
  • 보호된 branch의 승인된 commit
  • 강제 이동이 금지된 signed annotated release tag
  • release approver와 승인 기록
  • artifact digest
  • signature
  • SBOM
  • migration digest
  • target inventory
  • capacity 확인
  • backup·rollback point
  • abort condition
  • 사용자 승인 범위 확인

24.2 최초 배포

  1. HAL 필수 dependency와 HAL을 먼저 배포한다.
  2. HAL DB migration과 schema version을 확인한다.
  3. HAL API·worker·Console을 실제 read-back한다.
  4. HAL operator access와 audit를 확인한다.
  5. HAL에서 Node Agent activation을 시작한다.
  6. 이후 Customer Portal, Identity/BFF, Commerce·Entitlement·Allocation·Usage·Billing, Webmaker, Hosting, AriMail, Gitea, Backup·Internal DR, DNS·TLS·Registrar adapter, Object Storage adapter, Observability, Notification, Incident와 Status Page를 HAL 작업으로 배포한다.
  7. 각 배포는 target server의 실제 version과 artifact digest를 확인한다.
  8. 모든 외부 endpoint를 synthetic 검증한다.

24.3 업데이트

  • HAL이 desired release를 생성한다.
  • Scheduler가 canary target을 선택한다.
  • Agent가 signed artifact를 설치한다.
  • migration은 expand-first로 수행한다.
  • canary read-back 후 다음 ring으로 확대한다.
  • error budget이나 abort condition 위반 시 중지한다.
  • rollback도 Agent를 통해 실행하고 실제 상태를 재검증한다.

24.4 금지

  • 승인 없는 production deploy
  • 운영 DNS 무단 변경
  • 운영 secret 무단 회전
  • 운영 고객 데이터로 임의 테스트
  • AriMail·Webmaker upstream main 직접 production pull
  • 검증되지 않은 migration
  • backup 없는 destructive change
  • HAL을 건너뛴 수동 배포를 정상 운영 절차로 기록

25. 미확정 정책값 처리

다음 값은 이번 개발 지시에서 숫자로 임의 확정하지 않는다.

  • 상품명·등급·가격
  • Site 수와 resource 용량
  • Add-on 단위와 가격
  • Backup 주기와 Daily·Weekly·Monthly 개수
  • Backup 저장량과 restore 가격
  • mail 일반 첨부 최대 크기
  • mail 최대 수신자 수
  • 대용량 첨부 다운로드 횟수·보관기간
  • relocation source 보존기간
  • SLA
  • 내부 DR RPO/RTO
  • refund·proration·tax·currency
  • support response time

이 값은 코드 상수가 아니라 ProductVersion, PolicyVersion, CoveragePolicy data로 관리한다. UNSET, 0, UNLIMITED, NOT_APPLICABLE을 서로 다른 상태로 표현한다.

26. 전체 완료 정의

Ariweb Suite 최초 개발은 다음을 모두 만족해야 완료다.

  1. OZ-Group/AriWeb-Suite가 모든 배포 source와 manifest의 정본이다.
  2. AriMail·Webmaker·관련 OZ-Group source provenance가 기록되어 있다.
  3. HAL이 먼저 배포되고 정상 상태가 검증된다.
  4. HAL이 Node Agent를 통해 나머지 Suite module을 배포·업데이트·운영한다.
  5. 고객은 webmaker.ariweb.net 한 곳에서 서비스를 관리한다.
  6. 운영자는 제한된 hal.ariweb.net에서 전체 fleet을 관리한다.
  7. 독립 계정과 그룹 계정이 같은 Organization 모델로 동작한다.
  8. Webmaker project와 운영 Site lifecycle이 분리된다.
  9. 관리형과 외부 WEB deployment의 책임·quota·monitoring·billing이 분리된다.
  10. MAIL은 Site-bound와 Independent service를 지원한다.
  11. 독립 MailService가 운영 Site 수를 소비하지 않는다.
  12. 상품 entitlement와 Site별 보장 allocation이 원자적으로 집행된다.
  13. web disk·egress·mail storage·message count·mailbox count 제한이 실제 Data Plane에서 동작한다.
  14. 70·85·95·100% 경고와 hard-limit 동작이 일치한다.
  15. Paid Site Backup 구매자에게만 customer restore가 제공된다.
  16. Mail customer backup은 제공되지 않는다.
  17. offsite backup과 실제 Site restore가 검증된다.
  18. 서버·service·slot·capacity·allocation·actual usage가 시각화된다.
  19. 정적 Site는 정책 기반 자동 relocation, 동적 Site와 Mail은 승인형 relocation이 가능하다.
  20. relocation 중 이중 writer·이중 과금·데이터 유실이 없다.
  21. Agency Site ownership transfer가 검증된 절차로 가능하다.
  22. service retention과 purge가 hold·audit·receipt를 가진다.
  23. HAL·Webmaker 장애 중 기존 Data Plane serving이 지속된다.
  24. 실제 HTTPS와 실제 외부 mail 왕복을 완료 증거로 사용한다.
  25. 모든 secret·고위험 작업·지원 접근·삭제가 감사된다.
  26. DR·restore·rollback drill과 production release gate가 통과된다.

이 조건을 일부만 충족한 경우 전체 완료로 보고하지 않는다.

Reference in New Issue View Git Blame Copy Permalink