From 5da1f6fa374a7d20c996981d8ec9c50b493611cd Mon Sep 17 00:00:00 2001 From: "Agent.Hermes" Date: Mon, 26 Oct 2026 09:37:23 +0000 Subject: [PATCH] Add Ariweb Suite development order --- Ariweb-Suitle_Dev-Order.md | 2198 ++++++++++++++++++++++++++++++++++++ 1 file changed, 2198 insertions(+) create mode 100644 Ariweb-Suitle_Dev-Order.md diff --git a/Ariweb-Suitle_Dev-Order.md b/Ariweb-Suitle_Dev-Order.md new file mode 100644 index 0000000..6dc763b --- /dev/null +++ b/Ariweb-Suitle_Dev-Order.md @@ -0,0 +1,2198 @@ +# 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 최종 정본 + +개발·통합·배포의 최종 정본은 다음 저장소로 고정한다. + +```text +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에 맞게 조정할 수 있으나 모듈 경계를 합치지 않는다. + +```text +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별로 필요한 상태만 명시적으로 확장한다. + +```text +REQUESTED +→ POLICY_CHECKED +→ ENTITLEMENT_RESERVED +→ CAPACITY_RESERVED +→ PLACED +→ PREPARING +→ EXECUTING +→ VERIFYING +→ ACTIVE +``` + +보조·실패 상태: + +```text +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에서도 유지한다. + +```text +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 사용량은 다음 중 큰 값으로 계산한다. + +```text +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 + +```text +REQUESTED +→ PRICED +→ CUSTOMER_CONFIRMED +→ PAYMENT_CONFIRMED +→ OPERATOR_REVIEWED +→ ARCHIVE_SELECTED +→ STAGED +→ STRUCTURE_VALIDATED +→ DATA_VALIDATED +→ PRE_RESTORE_POINT_CREATED +→ ACTIVATED +→ SERVICE_VERIFIED +→ COMMITTED +``` + +보조·실패 상태: + +```text +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 상태 + +```text +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 +``` + +보조·실패 상태: + +```text +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 + +```text +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는 다음을 기준으로 한다. + +```text +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 결과 +- 배포 여부 +- 남은 작업과 미확정 정책 + +배포하지 않았으면 배포 완료라고 쓰지 않는다. + +## 완료 보고 형식 + +```text +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가 통과된다. + +이 조건을 일부만 충족한 경우 전체 완료로 보고하지 않는다.