diff --git a/Ariweb-Suitle_Dev-Order.md b/Ariweb-Suitle_Dev-Order.md index 6dc763b..d2e86f1 100644 --- a/Ariweb-Suitle_Dev-Order.md +++ b/Ariweb-Suitle_Dev-Order.md @@ -1,2198 +1,1088 @@ -# Ariweb Suite 개발 지시 — Dev-Order +/goal Based on https://source.ibit.kr/OZ-Group/AriWeb-Suite, implement the requirements listed at the end of this message. +After development, push all changes to https://source.ibit.kr/OZ-Group/AriWeb-Suite and merge them into main. Deploy HAL first from the protected main release, then use HAL to deploy, operate, monitor, update, and recover every remaining Ariweb Suite service on the required servers. -**작성자:** 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 +This release is version 0.1.0. -> **파일명 주의:** `Ariweb-Suitle_Dev-Order.md`는 사용자가 지정한 문자열을 그대로 보존한 파일명이다. 공식 제품명은 문서 전체에서 **Ariweb Suite**로만 사용한다. +Describe all changes in `VERSION_HISTORY.md`, grouped by customer screens, operator screens, site creation and deployment, hosting, mail, domains and certificates, commerce, backup and restore, relocation, monitoring, HAL/Node Agent operation, imported source, known limitations, and deferred policy values. +Write detailed code comments in Korean, explaining the purpose of each function, class, and module, the meaning of key variables and parameters, and the reasoning behind non-obvious logic. -**목적:** HAL을 Ariweb Suite의 중앙 Control Plane으로 개발하고, 기존 AriMail·Webmaker·Gitea·백업·호스팅·관측 도구를 검증 가능한 기능 모듈로 통합한다. 고객은 단일 Portal에서 서비스를 이용하고, 운영자는 HAL에서 여러 서버와 모든 모듈을 배치·운영·감시·제한·복구·이전할 수 있어야 한다. 개발 산출물과 배포 정본은 모두 `OZ-Group/AriWeb-Suite`에 수렴시킨다. +Use `https://source.ibit.kr/OZ-Group/AriWeb-Suite` as the only canonical source and deployment repository. Review `https://source.ibit.kr/OZ-Group/AriMail`, `https://source.ibit.kr/OZ-Group/WebHosting_AI_agent`, and other relevant repositories under `https://source.ibit.kr/OZ-Group`; selectively bring in only the code and behavior required for this release. Do not deploy those reference repositories directly. Record the source repository, commit, original path, destination path, modification status, and license review result for every imported component. -**요약:** 먼저 `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을 모두 통과한 경우에만 수행한다. +Requirements: -## 개정 이력 +# 1. Ariweb Suite의 전체 사용자 흐름 -- **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 정본 규칙을 보강. +Ariweb Suite는 고객이 회원가입 또는 로그인한 뒤 상품을 선택하고, 사이트를 만들고, 콘텐츠를 제작하고, 배포 방식과 도메인을 설정하고, 필요한 경우 메일과 백업을 추가하여 실제 서비스를 운영하는 하나의 연결된 서비스로 제공되어야 합니다. ---- +사용자는 Webmaker, 웹호스팅, 메일, 도메인, 백업, 사용량, 결제가 서로 다른 시스템이라는 느낌을 받지 않아야 합니다. 모든 기능은 동일한 로그인 상태와 공통 화면 구성, 상태 용어, 알림 방식으로 이어져야 합니다. -# /goal +기본 고객 흐름은 다음과 같습니다. -`https://source.ibit.kr/OZ-Group/AriWeb-Suite`를 기반으로 **HAL 중심의 Ariweb Suite 통합 관리·운영 플랫폼**을 개발한다. +1. 회원가입 또는 로그인 +2. 개인 계정 또는 사용자 그룹 선택 +3. 상품 선택과 주문 +4. 사이트 생성 +5. Webmaker에서 사이트 제작 +6. 배포 방식 선택 +7. 관리형 서버 또는 외부 서버로 배포 +8. 도메인 연결과 HTTPS 확인 +9. 필요한 경우 사이트 대표 메일 활성화 +10. 필요한 경우 추가 메일함 또는 독립 메일 서비스 생성 +11. 필요한 경우 관리형 사이트 백업 옵션 구매 +12. 대시보드에서 상태, 사용량, 알림, 비용 확인 +13. 운영 중 재배포, 복원, 서버 이전, 소유권 이전, 중지와 해지 수행 -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이 나머지 모듈을 필요한 서버에 배포·운영·관리해야 한다. +# 2. 공통 화면 구성과 상태 표시 ---- +## 2.1 전체 화면 -# 0. 정본 저장소와 참조 소스 지시 +로그인 후 고객 화면은 다음 공통 구조를 사용합니다. -## 0.1 최종 정본 +- 상단에는 현재 사용자 그룹, 알림, 도움말, 사용자 메뉴를 표시합니다. +- 왼쪽 메뉴에는 대시보드, 사이트, 메일, 도메인, 백업, 상품 및 결제, 사용량, 사용자 그룹 설정을 표시합니다. +- 화면 제목 아래에는 현재 위치와 주요 작업 버튼을 표시합니다. +- 결제 대기, 장애, 사용량 초과, 설정 오류, 사용자 확인 필요 항목은 화면 상단에 우선 표시합니다. +- 긴 작업은 다른 화면으로 이동해도 계속 진행하며, 알림 센터와 해당 서비스 화면에서 다시 확인할 수 있어야 합니다. -개발·통합·배포의 최종 정본은 다음 저장소로 고정한다. +## 2.2 작업 상태 -```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` 안에서 다음 기능을 제공하거나 관련성이 있는 저장소를 추가로 찾는다. +동일 작업의 상태는 서비스 상세, 알림 센터, 운영자 작업 화면에서 서로 다르게 보이면 안 됩니다. 새로 고침, 로그아웃 후 재로그인, HAL 재시작 뒤에도 같은 작업을 이어서 확인할 수 있어야 합니다. -- Gitea 설치·운영·연동 -- 웹 배포·nginx·TLS·DNS·도메인 관리 -- 백업·복구·원격 복제·보존 -- 모니터링·로그·알림·상태 페이지 -- 인증·OIDC·권한·조직 계정 -- 결제·청구·사용량·quota -- 서버 Agent·원격 설치·업데이트 -- Secret Broker·Vault·PKI -- object storage·artifact repository -- 운영 자동화·deployment script +## 2.3 사용성 -조사 시 사용자 credential로 접근 가능한 `OZ-Group` 저장소 목록을 programmatic하게 열거하고 중복을 제거한다. 저장소 이름만 보고 판단하지 말고 README, 현재 `main`, CHANGELOG, 배포 문서, 테스트와 핵심 코드를 확인한다. +- PC, 태블릿, 모바일에서 핵심 조회, 승인, 중지, 재시도를 사용할 수 있어야 합니다. +- 색상만으로 정상과 오류를 구분하지 않습니다. +- 입력 항목마다 이름, 도움말, 오류 이유를 제공합니다. +- 파괴적인 작업은 대상과 영향을 다시 보여주고 명시적 확인을 받습니다. -## 0.3 기존 소스 사용 규칙 +모든 고객·운영자 화면은 정상 데이터뿐 아니라 `불러오는 중`, `비어 있음`, `정보 지연`, `부분 실패`, `전체 실패`, `권한 없음` 상태를 제공합니다. 각 역할이 볼 수 있는 버튼과 거부되는 작업을 화면별로 확인하고, 알림의 링크는 사용자가 조치할 정확한 화면과 대상으로 이동해야 합니다. -기존 소스에서 필요한 내용을 가져와 사용할 때 다음을 지킨다. +모바일 검증은 최소 360px 너비에서 조회, 승인, 중지, 재시도, 알림 확인, 파괴적 작업 확인을 수행할 수 있는지 확인합니다. 표의 핵심 값과 작업 버튼이 가려지지 않아야 합니다. -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·저작권 고지를 보존한다. +# 3. 회원가입, 로그인과 계정 복구 -## 0.4 초기 기준 +## 3.1 회원가입 -개발 시작 시 다음 과거 기준을 참고하되 현재 상태를 다시 확인한다. - -- 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 자동 삭제 +이메일 주소, 표시 이름, 비밀번호, 필수 약관 동의를 입력받습니다. -## 완료 조건 +- 이메일 확인 전에는 유료 상품 구매와 운영 서비스 생성을 허용하지 않습니다. +- 이미 등록된 이메일이면 새 계정을 만들지 말고 로그인 또는 계정 복구를 안내합니다. +- 가입 완료 후 개인 계정 형태의 기본 사용자 그룹을 준비하고 대시보드로 이동합니다. +- 약관, 개인정보 처리방침, 마케팅 동의는 각각 구분합니다. +- 가격, SLA, 환불, 개인정보, DPA, 백업, AUP, 정지 및 해지 정책은 승인된 문구만 표시합니다. -- 기존 제작 기능 회귀 없음 -- 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은 유지되고 증가 작업은 거부됨 - ---- +## 3.2 로그인과 세션 -# 12. 모듈 M09 — AriMail Integration Module +- 이메일과 비밀번호로 로그인할 수 있어야 합니다. +- 잘못된 인증 정보는 이메일 존재 여부를 노출하지 않는 방식으로 안내합니다. +- 반복 실패 시 일정 시간 추가 시도를 제한하고 해제 시각을 표시합니다. +- 로그인된 기기와 세션 목록에서 개별 세션 또는 다른 모든 세션을 종료할 수 있어야 합니다. +- 운영자 로그인 화면은 고객 로그인 화면과 분리합니다. -## 목표 +## 3.3 계정 복구와 다중 인증 -AriMail의 multi-domain·webmail·SMTP·IMAP·POP3 기능을 HAL의 Identity·Entitlement·Allocation·Placement·Workflow와 통합한다. +- 외부 복구 이메일을 이용해 비밀번호를 재설정할 수 있어야 합니다. +- 재설정 링크의 만료와 사용 완료 여부를 안내합니다. +- 다중 인증은 선택 기능으로 등록, 확인, 해제할 수 있어야 합니다. +- 복구 수단을 제공하고 복구 코드는 한 번만 표시합니다. +- 운영자 계정에는 더 강한 인증을 권장하고 현재 보안 수준을 표시합니다. -## 12.1 P0 선행 수정 +# 4. 사용자 그룹과 권한 -통합 작업 전에 다음을 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만 사용한다. +## 4.1 사용자 그룹 전환 -## 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 +## 4.2 구성원 관리 -## 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% +각 구성원에게 `user-01`, `user-02`와 같은 그룹 내 표시 별칭을 자동으로 부여하고 변경할 수 있게 합니다. 별칭은 화면 표시용이며 로그인과 권한의 기준으로 사용하지 않습니다. -- 신규 발송 차단 -- 신규 수신 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건 이내 +## 4.3 사이트별 권한 -## 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 +변경 기록은 감사 기록에서 확인할 수 있어야 합니다. -### 고객 화면 +# 5. 고객 대시보드 -- 자기 Site·MailService 상태 -- MANAGED·EXTERNAL badge -- entitlement·allocation·actual usage -- 월 reset 시각 -- meter freshness -- quota warning과 제한 상태 -- paid backup 보호 상태 -- external deploy 마지막 receipt - -### Synthetic +## 5.1 요약 -웹: +다음 정보를 한눈에 보여주세요. -- 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 검증 +## 5.2 주의 항목과 최근 활동 -## 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 없음 +최근 배포, 설정 변경, 주문, 결제, 백업, 복원, 이전, 구성원 변경을 시간순으로 보여주고 사용자 작업과 자동 작업을 구분합니다. ---- +# 6. 상품 조회, 주문과 결제 -# 18. 모듈 M15 — Ownership Transfer, Retention, Purge - -## 목표 - -에이전시 고객 Site 이전과 서비스 해지 후 보존·삭제를 안전하게 관리한다. - -## 18.1 Ownership Transfer +## 6.1 상품 목록 -필요 조건: +기본 상품과 추가 옵션에 다음을 표시합니다. -- 에이전시 승인 또는 계약·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 +## 6.2 주문 흐름 -자동 이전하지 않을 대상: +1. 상품과 옵션 선택 +2. 적용 대상 그룹 또는 사이트 선택 +3. 가격과 청구 주기 확인 +4. 약관과 제한 확인 +5. 결제 방식 선택 +6. 주문 제출 +7. 결제와 승인 상태 확인 +8. 권리 활성화 -- AI Wallet -- 조직 공용 미할당 entitlement -- invoice·payment history -- 다른 Site와 공유하는 권리 -- 독립 MailService는 명시 선택 시만 포함 +결제 또는 운영자 승인 전에는 사이트 수, 용량, 메일함, 백업 권리를 사용할 수 없어야 합니다. 새로 고침하거나 같은 버튼을 다시 눌러도 중복 주문, 결제, 권리 활성화가 발생하지 않아야 합니다. -분쟁 중에는 serving을 유지하고 변경·삭제·이전을 동결한다. +버전 0.1.0의 기본 결제 흐름은 수동 결제 확인 방식입니다. -## 18.2 Retention state +1. 주문 제출 후 입금 안내와 주문 번호를 표시합니다. +2. 고객은 결제 대기 상태와 안내된 금액·통화·세금·기한을 확인합니다. +3. 운영자가 실제 입금을 확인한 뒤 주문을 승인하거나 거절합니다. +4. 승인 완료 후에만 권리가 활성화됩니다. +5. 거절 또는 기한 만료 시 사유, 재주문 또는 문의 방법을 표시합니다. -```text -ACTIVE -→ CANCEL_SCHEDULED -→ RETAINED_READ_ONLY -→ PURGE_PENDING -→ PURGED -``` +자동 결제수단을 추가하기 전에는 지원하는 것처럼 표시하지 않습니다. 갱신, 미납, 환불, 크레딧의 적용일과 서비스 영향 시점은 고객과 운영자 화면에 동일하게 표시합니다. -보조 상태: +갱신 전에는 청구 예정일과 금액을 알리고, 수동 결제가 확인될 때까지 `갱신 결제 대기`로 표시합니다. 결제 기한과 서비스 제한 예정 시각은 활성 상품정책에서 가져와 사전에 알리며, 미납 즉시 고객 데이터를 삭제하지 않습니다. -- HELD -- REACTIVATING +## 6.3 결제 화면 -`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일 +## 6.4 상품 축소와 해지 -legal·incident·dispute hold가 있으면 purge를 중지한다. 모든 purge는 finalizer와 receipt를 남긴다. +축소 전에 현재 사용량과 할당량을 보여주세요. -## 완료 조건 +- 변경 후 범위 안에 들어올 때만 즉시 축소합니다. +- 현재 사용량이 더 크면 줄여야 할 사이트, 용량, 메일함, 백업을 구체적으로 표시합니다. +- 정리 완료 후 다시 검증하여 적용합니다. +- 사용 중인 권리를 경고 없이 자동 회수하지 않습니다. -- target entitlement 부족 시 transfer 거부 -- partial ownership이 고객에게 노출되지 않음 -- purge 전 hold와 immutable ID 재확인 -- 보존기간 중 물리 capacity가 추적됨 -- purge receipt와 audit 존재 +## 6.5 AI Wallet, 초과 사용과 도메인 주문 ---- +- AI Wallet의 잔액, 충전, 사용 이력, 작업별 차감과 실패 시 환급 여부를 호스팅 사용량과 분리해 표시합니다. +- 자동 초과 사용과 자동 추가 과금은 기본으로 끕니다. +- 고객이 초과 사용을 허용할 때 항목별 최대 금액 또는 최대 사용량, 적용 기간, 철회 결과를 명시적으로 확인합니다. +- 도메인 등록과 갱신이 가능한 경우 검색, 가격, 등록 기간, 갱신일, 소유자 정보 확인, 결제, 등록·갱신 결과를 제공합니다. +- 도메인 등록 기능을 제공하지 않는 환경에서는 외부 등록기관을 사용해야 한다는 안내만 표시하고 구매 가능한 것처럼 보이지 않게 합니다. -# 19. 모듈 M16 — HAL First Bootstrap와 통합 배포 시스템 +# 7. 사이트 목록과 생성 -## 목표 +## 7.1 사이트 목록 -모든 배포에서 AriWeb-Suite를 정본으로 사용하고, HAL을 먼저 배포한 뒤 HAL이 나머지 모듈을 배포·운영하게 한다. +다음 정보를 표시합니다. -## 19.1 부트스트랩 원칙 +- 사이트 이름과 대표 웹 도메인 +- 제작 및 배포 상태 +- 관리형 또는 외부 배포 여부 +- 메일과 백업 옵션 여부 +- 최근 배포 시각 +- 건강 상태와 사용자 조치 필요 여부 -HAL은 자기 자신이 존재하기 전에 자신을 배포할 수 없으므로 최초 설치에만 최소 bootstrap 절차를 사용한다. +초안, 제작 중, 배포 중, 운영 중, 중지, 해지 대기로 필터링할 수 있어야 합니다. -HAL 이전에 수동으로 준비할 수 있는 Bootstrap Foundation은 다음 폐쇄 목록뿐이다. +## 7.2 사이트 생성 -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이 배포한다. +- 사이트 이름과 용도 +- 새 Webmaker 프로젝트 또는 기존 프로젝트 +- 시작 템플릿 +- 기본 언어와 시간대 +- 배포 방식을 지금 선택하거나 나중에 선택 -Bootstrap Foundation도 영구 수동 관리 대상으로 남기지 않는다. HAL 정상화 직후 각 component를 Registry에 등록하고 desired state, version, health, backup, update, certificate rotation을 HAL 관리로 인수한다. 인수 완료 전 production GA를 금지한다. +초안 사이트 생성만으로 운영 사이트 수를 소비하지 않습니다. 최초 공개 배포 직전에 사이트 수를 확보하며, 확보할 수 없으면 상품 구매 또는 기존 사이트 정리를 안내합니다. -초기 trust chain: +생성 후에는 Webmaker 제작, 콘텐츠 가져오기, 도메인 연결, 배포 방식, 구성원 권한 설정을 다음 단계로 안내합니다. -- 보호된 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를 남긴다. +# 8. 사이트 상세와 사이트 정보 -최초 순서: +사이트 상세는 개요, 제작, Source, 배포, 도메인, 메일, 백업, 사용량 및 통계, 활동 기록, 설정 탭으로 구성합니다. -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 배포 시작 +## 8.1 사이트 정보 표시 -bootstrap script는 위 폐쇄 목록과 HAL만 설치한다. Webmaker·Hosting·AriMail·Gitea·Backup·Customer Portal·Identity 본체·Commerce·Ledger·DNS/TLS adapter·Observability·Status Page를 직접 운영 배포하지 않는다. +정상적으로 배포된 사이트에는 다음을 표시합니다. -## 19.2 HAL 이후 배포 +- 대표 도메인과 접속 버튼 +- 현재 배포 버전과 시각 +- 관리형 또는 외부 배포 여부 +- 현재 정상 여부 +- 최근 24시간 접속 수 +- 최근 7일과 30일 접속 추이 +- 디스크와 데이터베이스 현재 사용량 및 한도 +- 네트워크 인바운드와 아웃바운드의 일일, 월간, 누적 사용량 +- 최근 오류와 성능 경고 +- 다음 예정 작업 -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 +위 운영 상태와 사용량은 관리형 사이트에 적용합니다. 외부 배포 사이트에는 Ariweb가 현재 상태를 직접 보장하는 것처럼 정상·uptime·관리형 디스크·트래픽·백업 보호 상태를 표시하지 않습니다. 외부 사이트에는 External Pull Agent 연결 상태, 마지막 배포 결과와 시각, 배포된 버전, 마지막 외부 확인 결과, 고객 책임 범위를 표시하고 확인할 수 없는 값은 `제공되지 않음`으로 명시합니다. -## 19.3 배포 정본 +## 8.2 사이트 설정 -배포 시 모든 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가 통과된다. - -이 조건을 일부만 충족한 경우 전체 완료로 보고하지 않는다. +## 8.3 Source + +Source 옵션을 구매한 사이트에는 다음을 제공합니다. + +- 연결된 Gitea 저장소와 기본 브랜치 +- 현재 선택한 source revision과 마지막 배포 revision +- 브랜치와 변경 이력 조회 +- 저장소, LFS와 첨부파일 사용량 및 한도 +- 저장소 열기, clone 정보, export +- 저장소 연결 변경과 해제 +- 배포 revision과 실제 배포 버전의 연결 표시 + +Source 옵션이 만료되면 push와 새 변경을 막고 30일 동안 read-only 조회, clone, export를 제공합니다. 만료일, 삭제 예정일과 재활성화 방법을 표시하며, 삭제 완료 후에는 복구 가능한 것처럼 표시하지 않습니다. + +# 9. Webmaker 제작 기능 + +## 9.1 제작 화면 + +사이트 상세에서 별도 재로그인 없이 Webmaker로 이동합니다. 현재 편집 중인 사이트와 사용자 그룹을 항상 표시합니다. + +- 새 프로젝트 생성과 기존 프로젝트 연결 +- 템플릿 선택 +- 페이지 추가, 복제, 삭제 +- 콘텐츠와 디자인 편집 +- 미리보기와 저장 +- 이전 저장본 조회 +- 배포할 저장본 선택 + +Webmaker 프로젝트와 운영 사이트를 같은 것으로 취급하지 않습니다. 프로젝트 삭제 시 운영 사이트, 배포본, 도메인에 어떤 영향이 있는지 보여주며 자동으로 함께 삭제하지 않습니다. + +## 9.2 AI 제작 기능 + +사용 전 수행 작업, 기능 유형, 예상 크레딧 또는 비용, 전송되는 콘텐츠 범위, 자동 배포되지 않는다는 점을 표시합니다. + +AI 결과는 미리보기 후 사용자가 적용해야 반영합니다. 실패 시 과금 여부와 재시도 가능 여부를 표시합니다. AI 사용량은 호스팅 디스크와 트래픽 사용량과 분리합니다. + +## 9.3 버전 0.1.0의 최소 제작 결과 + +첫 릴리스에서는 최소한 다음 결과를 실제로 제작하고 배포할 수 있어야 합니다. + +- 홈 페이지와 추가 페이지 +- 제목, 본문, 이미지, 버튼, 링크, 메뉴 +- 데스크톱과 모바일 미리보기 +- 저장, 이전 저장본 선택, 선택한 저장본 배포 +- 미리보기와 배포 결과의 핵심 콘텐츠 일치 +- 저장하지 않은 변경의 이탈 경고 + +여러 사용자가 같은 프로젝트를 편집해 충돌한 경우 마지막 저장으로 조용히 덮어쓰지 말고 충돌과 선택 가능한 결과를 표시합니다. 지원하지 않는 콘텐츠 가져오기나 AI 기능은 메뉴에 노출하지 않거나 `이번 버전에서 지원하지 않음`으로 명시합니다. + +# 10. 웹 배포 방식 선택 + +## 10.1 관리형 배포 + +다음을 보여주세요. + +- Ariweb가 서버 배치와 운영을 관리한다는 설명 +- 모니터링 범위 +- 용량과 트래픽 한도 +- 백업 옵션 가능 여부 +- 자동 또는 승인형 서버 이전 가능성 +- 예상 배포 시간과 승인된 비용 + +버전 0.1.0의 관리형 배포는 정적 사이트와 Ariweb가 승인한 동적 사이트 실행 형태를 최소 대상으로 합니다. 선택 화면에서 현재 사이트가 지원 대상인지, 필요한 데이터베이스와 저장 공간이 무엇인지, 지원되지 않는 기능이 무엇인지 배포 전에 알려줍니다. + +## 10.2 외부 배포 + +- 지원하는 외부 대상 +- 사용자가 준비할 접속 정보 +- 건별 배포 비용 +- 제공하지 않는 관리형 모니터링, 백업, 이전, SLA +- 외부 환경 장애는 Ariweb 정상 상태와 분리된다는 안내 + +외부 배포도 공개된 사이트라면 운영 사이트 수를 소비합니다. 관리형 디스크, 트래픽, 메일, 백업 권리를 자동 할당하지 않습니다. + +버전 0.1.0의 외부 배포 대상은 External Pull Agent를 설치할 수 있는 지원 Linux 서버입니다. 화면에서 Agent 설치 안내, 일회용 연결, 연결 확인, 배포, 재배포, 배포 제거와 마지막 외부 확인 결과를 제공합니다. 실패한 배포의 남은 파일과 실행 상태를 알려주고 다시 시도하거나 제거할 수 있어야 합니다. + +외부 배포를 시작하기 전에 고객 책임, 제공되지 않는 기능, 건별 비용을 버전이 기록되는 확인 화면에서 동의받습니다. 버전 0.1.0에서는 외부 메일 배포를 지원하지 않습니다. + +## 10.3 배포 방식 변경 + +운영 중 설정값만 즉시 바꾸지 말고 새 위치 준비, 별도 배포, 검증, 도메인 전환, 이전 위치 정리 순서로 진행합니다. 완료 전 현재 위치를 유지하고 실패하면 되돌립니다. + +# 11. 사이트 배포 + +## 11.1 배포 전 확인 + +- 배포할 저장본 +- 운영 사이트 수 +- 배포 위치의 사용 가능 여부 +- 디스크와 데이터베이스 용량 +- 도메인 상태 +- 필수 설정 +- 다른 배포, 복원, 이전 작업과의 충돌 + +통과와 차단 항목을 구분하고 문제 해결 화면으로 연결합니다. + +## 11.2 진행 표시 + +1. 요청 접수 +2. 저장본 준비 +3. 배포 위치 준비 +4. 파일과 설정 적용 +5. 데이터베이스와 업로드 데이터 확인 +6. 서비스 시작 +7. 내부 확인 +8. 외부 접속 확인 +9. 도메인과 HTTPS 확인 +10. 완료 + +화면을 닫아도 작업을 계속하고 완료 또는 실패 알림을 제공합니다. + +배포 완료 상태는 다음과 같이 구분합니다. + +- `배포 검증 완료`: 플랫폼 또는 대상 확인 주소에서 새 버전이 정상 동작함 +- `도메인 설정 필요`: 배포는 정상이나 대표 도메인 또는 HTTPS가 아직 완료되지 않음 +- `공개 운영 중`: 대표 도메인과 HTTPS까지 실제 외부 확인 완료 + +최초 공개 배포를 시작할 때 사이트 수를 `예약됨`으로 표시합니다. 배포와 대표 도메인 확인이 끝나면 `사용 중`으로 전환합니다. 사용자가 배포를 취소하거나 실패 결과를 정리하면 예약을 반환합니다. 정리하지 않은 중간 결과에는 반환 예정 시각과 `지금 정리하고 반환` 기능을 제공합니다. + +## 11.3 완료, 실패와 되돌리기 + +완료 후 배포 버전, 시각, 접속 주소, 건강 상태, 이전 버전, 되돌리기 조건을 표시합니다. + +실패 시 실패 단계, 안전한 오류 설명, 문의용 작업 번호, 기존 버전 유지 여부, 재시도와 되돌리기 방법을 제공합니다. 되돌리기 전 데이터 영향을 안내하고 실제 외부 확인 후 완료합니다. + +# 12. 도메인과 HTTPS + +## 12.1 도메인 목록 + +도메인 이름, 연결 사이트 또는 메일, 사용 목적, 소유 확인, DNS, HTTPS 인증서, 메일 보안 레코드, 마지막 확인 시각을 표시합니다. + +## 12.2 연결 흐름 + +1. 도메인 입력 +2. 웹, 메일 또는 둘 다 선택 +3. 소유 확인 +4. 필요한 DNS 값 안내 +5. DNS 반영 확인 +6. HTTPS 인증서 발급 +7. 외부 접속 확인 +8. 대표 도메인 지정 + +사용자가 직접 DNS를 관리하면 복사 가능한 값을 제공하고 미반영과 잘못된 값을 구분합니다. + +## 12.3 대표 도메인과 인증서 + +- 한 사이트에 여러 웹 도메인을 연결해도 운영 사이트 수는 하나만 소비합니다. +- 대표 웹 도메인을 하나 지정합니다. +- 대표 도메인이 정상 연결되어야 사이트를 정상 운영 상태로 표시합니다. +- 대표 도메인 변경 시 기존 주소의 이동 처리 여부를 선택합니다. +- 인증서 발급, 갱신, 만료 임박, 실패 상태를 표시합니다. +- 유효하지 않은 인증서를 정상 HTTPS로 표시하지 않습니다. + +# 13. 사용량, 접속 통계와 한도 + +## 13.1 사이트별 사용량 + +- 디스크와 데이터베이스 현재 사용량 및 할당량 +- 네트워크 인바운드와 아웃바운드의 일간, 월간, 누적 사용량 +- 최근 24시간, 7일, 30일 방문과 요청 추이 +- 오류율과 응답 시간 추이 +- 마지막 수집 시각 + +정상 배포되지 않은 사이트에는 운영 사용량을 표시하지 않습니다. + +## 13.2 사용자 그룹 전체 사용량 + +구매 총량, 사이트별 배정량, 실제 사용량, 미배정 잔여량, 진행 중 작업에 예약된 양을 구분해 표시합니다. 총 구매량보다 많이 배정할 수 없으며 동시에 여러 화면에서 변경해도 초과 배정이 발생하지 않아야 합니다. + +## 13.3 서비스별 보장량 배정 + +고객은 구매한 총량 안에서 사이트와 메일 서비스별로 다음을 배정하거나 줄일 수 있어야 합니다. + +- 웹 디스크 +- 월간 웹 아웃바운드 +- 메일 저장 공간 +- 월간 메일 송신·수신 통수 +- 메일함 수 + +변경 화면에는 구매 총량, 사용 중, 다른 서비스 배정량, 진행 중 작업 예약량, 미배정량, 변경 후 값을 표시합니다. + +- 실제 사용량보다 작게 줄이는 요청은 거부하고 정리해야 할 양을 안내합니다. +- 월간 사용량 항목은 현재 KST 월 누적 사용량보다 작게 줄일 수 없습니다. +- 마지막 남은 단위를 두 작업이 동시에 예약하면 하나만 성공하고 다른 작업에는 부족 사유를 표시합니다. +- 배정 상태를 `사용 가능`, `예약됨`, `사용 중`, `반환 중`, `반환됨`으로 표시합니다. +- 실패·취소·되돌리기 후 남은 예약과 반환 예정 시각을 표시하고 중복 소비가 없어야 합니다. + +## 13.4 경고와 제한 + +기본 경고 구간은 70%, 85%, 95%, 100%입니다. + +- 70%: 화면 사전 안내 +- 85%: 화면과 이메일 경고 +- 95%: 증설 또는 정리 방법 강조 +- 100%: 항목별 제한과 이유 표시 + +한도 종류별 동작은 다음과 같이 구분합니다. + +- 웹 아웃바운드 100%: 사이트 대신 제한 안내 화면을 표시하고 다음 KST 월 시작 또는 추가 용량 적용 후 복구합니다. +- 웹 디스크 100%: 기존 사이트 조회와 삭제·내보내기는 유지하고 새 업로드, 데이터베이스 증가, 새 배포를 제한합니다. +- 메일 저장 공간 100%: 기존 메일 조회와 삭제는 유지하고 새 수신은 임시 실패로 응답하여 발신 서버가 재시도할 수 있게 합니다. +- 월간 메일 통수 100%: 새 발신을 막고 새 수신은 임시 실패로 응답합니다. 다음 KST 월 시작 또는 추가 용량 적용 후 복구합니다. +- 메일함 수 100%: 기존 메일함은 유지하고 새 메일함 생성을 막습니다. + +고객 데이터를 자동 삭제하지 않습니다. 사용량 화면에 적용 상품·정책 버전, 다음 KST 월 초기화 시각, 마지막 계측 시각을 표시합니다. + +사용량 정보가 오래되거나 중앙 관리 기능과 연결되지 않은 경우 오래된 정보로 신규 증가를 허용하지 않습니다. 기존 서비스, 조회, 삭제와 내보내기는 최대한 유지하고 연결 복구 후 다시 확인합니다. + +# 14. 운영 사이트 수 반환 + +운영 사이트 수를 다른 사이트에 사용하려면 다음 조건을 화면에서 확인합니다. + +1. 공개 서비스 중지 +2. 대표 도메인을 포함한 모든 웹 도메인의 공개 라우팅 해제 +3. 진행 중인 배포, 복원, 이전 종료 +4. 사이트 대표 메일의 유지 또는 종료 선택 +5. 유지할 대표 메일을 독립 메일 서비스로 전환 +6. 데이터와 보존 기한 확인 +7. 사용자 최종 확인 +8. 사이트 수 반환 + +메일을 유지하려는데 독립 메일 권리가 부족하면 반환하지 말고 필요한 옵션을 안내합니다. + +사이트 대표 메일을 독립 메일로 전환할 때 기존 메일 주소, 메일함 데이터, 별칭, 전달 설정, 사용자 비밀번호와 DNS 설정의 유지 여부를 확인 화면에 항목별로 표시합니다. 전환 전후 실제 송수신을 확인하고 누락된 항목이 있으면 사이트 수를 반환하지 않습니다. + +# 15. 메일 서비스 개요와 생성 + +## 15.1 메일 서비스 종류 + +- 사이트 대표 메일: 사이트 하나에 대표 메일 도메인 하나, 여러 메일함을 제공하며 추가 운영 사이트 수를 소비하지 않습니다. +- 독립 메일 서비스: 사이트 없이 메일만 사용하고 대표 도메인 하나를 가지며 독립 메일 옵션을 소비하지만 운영 사이트 수는 소비하지 않습니다. +- 사이트 대표 메일을 사이트와 분리해 독립 메일로 전환할 수 있어야 합니다. + +## 15.2 메일 목록 + +서비스 이름, 사이트 연결 여부, 대표 메일 도메인, 상태, 메일함 수와 한도, 저장 공간, 송수신 상태, DNS 보안 상태, 최근 경고를 표시합니다. + +## 15.3 생성 흐름 + +1. 사이트 대표 또는 독립 메일 선택 +2. 도메인 선택 +3. 상품 또는 옵션 확인 +4. 메일함 수, 저장 공간, 월간 송신·수신 통수 배정 +5. DNS 값 확인 +6. 도메인과 DNS 확인 +7. 서비스 준비 +8. 실제 외부 송수신 확인 +9. 활성화 + +결제와 승인 전에는 활성화하지 않습니다. 내부 준비 상태만으로 완료하지 말고 외부 발신, 수신, 회신을 확인합니다. + +# 16. 메일함과 메일 설정 + +## 16.1 메일함 목록과 생성 + +메일 주소, 표시 이름, 활성·정지·용량 초과 상태, 현재 공간과 한도, 마지막 로그인, 자동 응답, 전달 설정, 비밀번호 변경 필요 여부를 표시합니다. + +새 메일함에서는 주소, 표시 이름, 저장 공간, 초기 비밀번호 또는 초대 방식, 웹메일, POP3·IMAP 안내를 제공합니다. 생성 전에 남은 메일함 수와 공간을 확인합니다. + +초기 비밀번호를 사용하는 경우 한 번만 표시하고 첫 로그인에서 변경하게 합니다. 초대 방식을 사용하는 경우 링크 만료, 재발송과 사용 완료 상태를 표시합니다. + +정지된 메일함도 삭제 전까지 메일함 수와 저장 공간을 소비한다는 점을 표시합니다. + +## 16.2 메일함 설정 + +- 표시 이름과 비밀번호 재설정 +- 저장 공간 변경 +- 자동 응답과 전달 +- 별칭과 전달 전용 주소 +- POP3·IMAP 안내 +- 모든 세션 종료 +- 정지와 삭제 + +별칭과 전달 전용 주소의 계산 방식은 최신 상품정책을 표시하며 미확정이면 무제한 제공하지 않습니다. + +메일 서비스 설정에서 POP3와 IMAP을 각각 켜거나 끌 수 있어야 합니다. 변경 전에 영향을 받는 메일 프로그램과 현재 연결 상태를 안내하고, 적용 후 실제 접속 가능 여부를 확인하여 결과를 표시합니다. + +## 16.3 웹메일과 외부 프로그램 + +웹메일 진입 버튼을 제공하고 가능한 경우 현재 로그인 상태로 안전하게 연결합니다. 외부 프로그램 설정에는 서버 주소, 포트, 암호화 방식, 사용자 이름을 제공하되 비밀번호를 재표시하지 않습니다. + +# 17. 메일 사용량과 제한 + +## 17.1 저장 공간 + +메일 서비스 전체와 메일함별 사용량을 표시하고 70%, 85%, 95%, 100% 경고를 적용합니다. 100%에서는 기존 메일 조회와 삭제를 유지하고 새 수신과 저장을 제한합니다. 오래된 메일을 자동 삭제하지 않습니다. + +## 17.2 발송 제한 + +- 초당 10건 이상의 SMTP 제출은 자동 제한, 경고, 악용 여부 확인 대상으로 처리합니다. +- 실제 외부 전달은 도메인과 서버 각각 초당 5건을 넘지 않게 합니다. +- 제한 이유, 해제 예상 시각, 문의 방법을 표시합니다. +- 정상적인 대량 발송 상품으로 오해하지 않도록 범위를 안내합니다. + +제한 판단에 사용하는 시간 구간과 현재 제출량을 운영자가 확인할 수 있게 하고, 제한 해제 후 실제 발신이 정상화되었는지 확인합니다. + +메일 사용량 화면에는 월간 송신과 수신의 합계, 최종 수신자 기준 계산이라는 설명, 현재 누적 통수, 할당 통수, 다음 KST 월 초기화 시각과 마지막 계측 시각을 표시합니다. + +## 17.3 대용량 첨부 + +대용량 첨부는 다운로드 링크 방식으로 제공할 수 있어야 합니다. 업로드 전 허용 크기, 다운로드 횟수, 보관 기한을 표시하고 만료 후 다운로드를 차단합니다. + +첨부 크기, 다운로드 횟수, 보관기간의 구체 수치는 후속 상품정책에서 정하며 임의로 고정하지 않습니다. 시스템 안전 상한과 악용 방지 제한은 상품보다 우선합니다. + +일반 첨부 최대 크기와 메일당 최대 최종 수신자 수를 작성 화면에 사전 표시합니다. 대용량 첨부는 별도 옵션임을 표시하고, 저장된 대용량 첨부가 메일 저장 공간을 소비하는 경우 예상 사용량을 업로드 전에 보여줍니다. + +## 17.4 고객용 메일 백업 제외 + +메일 원문은 고객용 백업이나 고객 복원 기능에 포함하지 않으며 메일 백업을 제공하는 것처럼 표시하지 않습니다. + +# 18. 메일 도메인 보안 + +송신 도메인 확인, 수신 설정, SPF, DKIM, DMARC, 인증서, 외부 송수신 시험을 정상·권장 개선·오류로 표시합니다. 사용자가 DNS를 변경해야 하면 정확한 값을 복사할 수 있게 합니다. + +# 19. 관리형 사이트 백업 옵션 + +## 19.1 구매와 범위 + +백업은 관리형 사이트 단위 유료 옵션입니다. + +- 백업 가능한 사이트에서만 구매 버튼을 표시합니다. +- 외부 배포 사이트에는 제공하지 않습니다. +- 1차 출시에서는 사이트당 옵션 하나만 활성화합니다. + +구매 화면에서 저장 한도, 현재 사용량, 정기 실행 일정, Daily·Weekly·Monthly 보존 개수, 첫 백업 예정 시각, 원격 사본 검증 방식과 추가 저장 옵션을 표시합니다. 실제 값은 활성 ProductVersion에서 가져오며 버전 0.1.0 출시 검증 환경에서는 모두 설정되어 있어야 합니다. + +포함 대상은 현재 배포본, 데이터베이스, 업로드 데이터, 복원에 필요한 사이트 설정입니다. + +메일 원문, 소스 저장소, Webmaker 프로젝트 이력, 외부 배포 데이터, 플랫폼 내부 복구 사본은 제외합니다. + +## 19.2 백업 화면과 동작 + +옵션 활성 여부, 최근 성공·실패 백업, 다음 예정 백업, 보관 목록, 생성 시각, 대상 범위, 검증 상태, 만료일, 복원 요청을 표시합니다. + +백업은 운영 서버와 분리된 위치에 저장하고 생성 후 읽을 수 있는지 확인합니다. 실패가 계속되면 고객과 운영자에게 알립니다. 사이트 공개 운영이 중지되면 신규 정기 백업을 중지하고 기존 백업은 정책에 따라 유지합니다. + +- 옵션 활성화 후 첫 백업 완료 기한과 현재 진행 상태를 표시합니다. +- 반복 실패 알림 기준과 다음 재시도 시각을 표시합니다. +- 저장 공간이 부족하면 최소 보존 세트를 삭제하지 말고 다음 백업을 중지하여 필요한 추가 용량 또는 오래된 복구점 정리를 안내합니다. +- 사이트 재개 후 백업이 자동으로 다시 시작되는지 사용자 확인이 필요한지를 표시합니다. + +# 20. 사이트 복원 + +## 20.1 요청 + +백업 생성 시각, 포함 데이터, 서비스 영향, 예상 중단 시간, 복원 비용, 되돌리기 범위를 보여주세요. 요청 후 필요한 경우 비용 확인, 결제, 운영자 승인, 작업 시간 확인을 거칩니다. + +## 20.2 진행 + +1. 요청 접수 +2. 비용과 승인 확인 +3. 현재 상태 보호 +4. 격리된 환경에서 백업 확인 +5. 데이터 복원 +6. 사이트 기능 확인 +7. 외부 접속 확인 +8. 사용자 확인 또는 자동 완료 +9. 이전 상태 정리 + +대상 사용자 그룹, 사이트, 도메인을 최종 확인 화면에 표시합니다. + +## 20.3 실패와 만료 + +실패하면 기존 운영 상태를 유지하거나 되돌립니다. 자동 복구가 불가능하면 사용자 확인 필요 상태와 운영자 연락 상황을 표시합니다. + +복원 전에 만든 보호 시점의 유지 기간, 되돌릴 수 있는 마지막 시각, 자동 완료 또는 고객 확인 중 이번 작업에 적용되는 방식을 복원 시작 전에 보여줍니다. + +옵션 만료 후 백업은 7일 동안 보관한 뒤 삭제합니다. 종료 예정일, 삭제일, 보존 중 복원 가능 여부와 비용을 표시합니다. + +# 21. 서버 이전 + +## 21.1 종류와 안내 + +- 정적 사이트는 조건이 맞으면 자동 이전할 수 있습니다. +- 동적 사이트와 메일은 운영자 승인과 작업 시간 확인 후 이전합니다. +- 장애 회피 또는 용량 조정 이전과 고객 요청 유료 이전을 구분합니다. + +대상, 이유, 출발·도착 위치의 사용자용 설명, 예상 시간, 서비스 영향, 변경 제한 시간, 비용, 사용자 행동을 사전에 안내합니다. + +## 21.2 진행 + +1. 조건 확인 +2. 새 위치 준비 +3. 데이터 사전 복사 +4. 복사 결과 확인 +5. 최종 변경분 반영 +6. 새 위치 확인 +7. 연결 전환 +8. 외부 접속 또는 송수신 확인 +9. 이전 위치 정리 +10. 완료 + +시작 전과 실제 전환 직전에 현재 운영 위치, 양쪽 서버 상태, 임시 공간, 다른 백업·복원·이전과의 충돌, 도메인·인증서 접근, 파일과 데이터 일치를 다시 확인합니다. + +같은 사이트나 메일이 두 서버에서 동시에 운영 상태가 되지 않아야 합니다. 실패, 일시 중지, 취소, 되돌리는 중, 되돌림 완료를 구분합니다. + +이전 화면에는 다음 경계를 명시합니다. + +- 전환 전 사용자가 취소할 수 있는 마지막 단계 +- 동적 사이트와 메일에서 쓰기 제한이 시작되고 끝나는 시각 +- 정책에 설정된 목표 중단 시간 +- 새 위치가 유일한 운영 위치가 되는 시점 +- 전환 후 되돌릴 수 있는 기간 +- 이전 위치의 보존 종료와 삭제 예정 시각 +- DNS와 인증서 반영 대기 중의 접속 처리 + +정적 사이트 자동 이전은 사전 통지와 완료 통지를 제공하고 플랫폼 사유 이전은 고객에게 과금하지 않습니다. 최종 확인에 실패하면 새 위치를 운영 위치로 확정하지 않습니다. + +# 22. 사이트와 서비스 소유권 이전 + +이전 화면에 사이트, 도메인, 사이트 대표 메일, 독립 전환 항목, 백업, 배정 용량, 진행 작업, 미납 항목을 보여주세요. + +보내는 그룹이 요청하고 받는 그룹이 수락해야 합니다. 받는 쪽 상품과 잔여 권리가 부족하면 필요한 상품을 안내하고 보류합니다. 양쪽 확인 전에는 변경하지 않습니다. + +양쪽 동의 뒤 운영자가 소유 증빙과 도메인 확인 결과를 심사합니다. 진행 중인 배포, 복원, 이전이 있으면 완료 또는 취소 전까지 소유권 이전을 시작하지 않습니다. 요청 만료일과 양쪽의 취소 가능 시점을 표시합니다. + +이전 대상과 제외 대상을 나누어 보여주세요. 사이트와 선택된 연결 서비스는 이전할 수 있지만 AI Wallet, 사용자 그룹 공용 미배정 용량, 기존 청구·결제 이력은 이전하지 않습니다. 독립 메일 서비스는 사용자가 명시적으로 선택한 경우에만 포함합니다. + +분쟁 상태에서는 기존 서비스를 유지하고 설정 변경, 삭제와 추가 이전을 동결하며 양쪽 화면에 보류 상태와 문의 경로를 표시합니다. + +완료 후 양쪽 대시보드, 사용량, 결제, 권한, 감사 기록이 새 소유관계와 일치하고 이전 사용자는 더 이상 접근할 수 없어야 합니다. + +이전 완료 시점의 양쪽 청구 책임 종료·시작 시각과 다음 청구 반영 결과를 표시합니다. 이전은 전체 대상이 한 번에 새 소유자로 보이거나 실패해야 하며 일부만 이전된 상태를 고객에게 완료로 노출하지 않습니다. + +# 23. 중지, 해지와 보존 + +## 23.1 중지와 해지 + +중지 전 공개 접속, 관리자 접근, 메일 송수신, 신규 백업, 사용량과 비용, 재개 조건을 표시합니다. + +해지 전 대상과 연결 서비스, 즉시 중지 기능, 남는 데이터, 보존 종료일, 내보내기, 미결제와 환불, 되돌릴 수 없는 시점을 보여주세요. + +## 23.2 기본 보존 기간 + +별도 승인 정책이 없으면 다음을 표시합니다. + +- 해지된 사이트 데이터: 30일 +- 해지된 메일: 송수신을 즉시 중지하고 기존 메일 읽기와 내보내기를 30일 제공 +- 연결 해제된 소스 저장소: 30일 +- 만료된 고객용 사이트 백업: 7일 + +법적 보존이나 분쟁으로 삭제가 보류되면 삭제 보류 상태와 문의 경로만 표시합니다. 실제 삭제 완료 후에는 복구 가능한 것처럼 표시하지 않습니다. + +## 23.3 고객에게 표시할 생명주기 + +사이트와 메일의 각 상태에서 다음을 한 화면에 표시합니다. + +- 공개 서비스와 관리자 접근 가능 여부 +- 운영 사이트 수와 용량 권리 소비 여부 +- 청구 지속 또는 종료 시점 +- 도메인, 메일, 백업의 동작 +- 데이터 내보내기와 재개 가능 여부 +- 되돌릴 수 없는 시점 +- 보존 종료와 삭제 예정일 +- 다음 알림 예정 시각 + +`일시 중지`, `해지 예약`, `읽기 전용 보존`, `삭제 대기`, `삭제 완료`를 구분합니다. 일시 중지 사이트는 운영 사이트 수를 계속 소비합니다. 실제 사이트 수 반환은 14절 조건을 모두 충족한 경우에만 적용합니다. + +# 24. 알림 센터와 감사 기록 + +## 24.1 알림 + +결제와 주문, 사이트와 배포, 도메인과 인증서, 메일, 사용량, 백업과 복원, 서버 이전, 보안, 장애와 유지보수로 분류합니다. + +각 알림에는 발생 시각, 영향 대상, 현재 상태, 필요한 행동, 관련 화면 링크를 제공합니다. 중요 알림은 화면과 이메일로 보냅니다. 서비스 중단, 보안, 결제, 데이터 삭제 예정은 필수 알림으로 구분합니다. + +같은 원인의 반복 알림은 하나의 사건으로 묶어 최신 상태를 갱신합니다. + +## 24.2 활동과 감사 기록 + +누가, 언제, 어떤 그룹과 서비스에서, 무엇을 변경했는지, 자동 또는 사용자 작업인지, 성공·실패·취소 결과를 조회합니다. + +비밀번호, 토큰, 인증 키와 개인정보 원문은 표시하지 않습니다. 권한, 소유권, 배포, 해지, 복원, 이전, 결제 승인은 삭제할 수 없는 기록으로 남깁니다. + +# 25. 운영자 콘솔 + +고객 화면과 분리된 운영자 콘솔에 다음 메뉴를 제공합니다. + +- 운영 현황 +- 고객과 사용자 그룹 +- 주문과 결제 승인 +- 상품과 정책 +- 사이트와 배포 +- 메일 서비스 +- 도메인과 인증서 +- 서버와 용량 +- 백업과 복원 +- 서버 이전 +- 배포 릴리스 +- 장애와 알림 +- 감사 기록 +- 플랫폼 복구 + +고객 지원용 일시 접근은 대상, 이유, 만료 시각, 승인 기록을 남기며 허용 범위만 보여줍니다. + +운영자 콘솔은 `hal.ariweb.net`의 제한된 경로에서 제공하고 VPN 또는 승인된 사설망과 사용자·기기에 귀속된 짧은 수명의 접근 권한 없이는 로그인 화면에도 접근할 수 없게 합니다. 고객 세션으로 운영자 화면을 열 수 없어야 합니다. + +운영자는 별도 관리자 계정으로 로그인합니다. 서버 삭제, 대량 복원, 인증 키·인증서 변경, 메일 이전, 고객 데이터 삭제와 같은 고위험 작업은 최근 재인증 후 다음 3단계 확인을 거칩니다. + +1. 영향 범위 확인 +2. 변경되지 않는 대상 식별정보 재확인 +3. 최종 실행과 되돌리기 가능 여부 확인 + +접근 권한 만료, 재인증 필요, 승인 대기와 거부 이유를 운영자에게 표시합니다. + +# 26. 운영 현황과 고객 지원 + +## 26.1 운영 현황 + +HAL, Customer Portal, Webmaker, 웹호스팅, AriMail, Source/Gitea, 백업, 관측 시스템의 상태를 표시합니다. + +등록 서버, 비정상 서버, 진행 중 배포·복원·이전, 처리 대기 승인, 전체 용량 경고, 장애와 유지보수를 함께 보여주세요. 오래된 상태는 정상으로 표시하지 말고 정보 지연과 마지막 확인 시각을 표시합니다. + +## 26.2 고객 조회 + +운영자는 고객과 사용자 그룹을 검색하고 활성 상품, 사이트, 메일, 도메인, 백업, 사용량, 주문, 결제, 정지, 보존 상태와 고객 화면의 오류를 확인합니다. + +고객 대신 변경할 경우 변경 전후 값, 사유, 승인자를 기록하고 고객 화면에도 반영합니다. + +HAL 또는 Webmaker에 장애가 발생해도 이미 배포된 웹, 메일과 Git 서비스는 가능한 한 계속 제공되어야 합니다. 고객 화면에는 `기존 서비스 제공 중`, `신규 배포·설정 변경 제한`, `중앙 상태 확인 지연`을 구분해 표시합니다. 연결 복구 후 실제 상태를 다시 확인하고 자동 조정 결과를 고객과 운영자에게 보여줍니다. + +# 27. 주문, 결제와 상품 운영 + +## 27.1 주문 승인 + +운영자는 수동 결제 확인, 주문 승인·거절, 환불, 크레딧, 초과 사용 승인, 축소 보류, 결제 실패 재처리를 수행합니다. + +승인 전에 대상, 금액, 권리 변화, 현재 사용량을 확인합니다. 같은 승인을 반복해도 권리가 중복 생성되지 않아야 하며 결과는 고객 주문 화면과 알림에 반영합니다. + +## 27.2 상품 관리 + +운영자는 코드 변경 없이 상품 이름, 설명, 공개 여부, 가격, 청구 주기, 포함 사이트 수, 웹 용량과 트래픽, 메일 범위, 백업과 추가 옵션, 경고 구간, 승인 방식, 적용 시작일을 관리할 수 있어야 합니다. + +이미 판매된 조건은 조용히 바꾸지 말고 새 버전으로 만들며 기존 고객 적용 조건을 구분합니다. 미확정 정책을 확정된 약속처럼 공개하지 않습니다. + +# 28. 서버 등록과 용량 운영 + +## 28.1 서버 목록 + +서버 이름과 역할, 위치, 연결 상태, 마지막 확인, CPU·메모리·디스크·inode·I/O·네트워크, 배치 서비스 수, 예약과 실제 사용량, 유지보수, 신규 배치 허용 여부, 격리 여부, 최근 오류를 표시합니다. + +Node Agent heartbeat, 서버 시계 차이, 인증서 만료, 실제 실행 버전과 목표 버전 차이, 용량 고갈 예상 시점, 백업 저장소 용량과 최근 검증, 작업 대기열과 반복 실패 항목을 함께 표시합니다. 상세 운영 지표는 최소 90일 조회할 수 있어야 합니다. + +## 28.2 서버 등록 + +1. 서버 역할과 위치 입력 +2. 일회용 등록 정보 발급 +3. 해당 서버에서 Node Agent 설치 +4. 연결과 신원 확인 +5. 기능과 용량 확인 +6. 운영자 승인 +7. 배치 가능 상태 전환 + +등록 정보는 짧은 시간만 유효하고 다시 표시하지 않습니다. + +## 28.3 유지보수와 용량 + +신규 배치 중지, 기존 서비스 영향 확인, 필요한 서비스 이전, 유지보수 시작과 종료, 신규 배치 재개 흐름을 제공합니다. + +고객 상품 보장량, 서비스별 배정량, 작업 예약량, 실제 사용량, 서버 안전 여유, 배치 불가 이유를 보여주세요. 총 보장량이나 실제 용량을 초과하는 배치를 허용하지 않습니다. + +# 29. 운영 작업 화면 + +모든 긴 작업에서 작업 번호, 종류, 고객과 대상, 시작 주체, 현재 단계, 진행률, 시작과 갱신 시각, 외부 대기, 재시도, 되돌리기, 오류 요약을 표시합니다. + +HAL이나 작업 실행 기능이 재시작되어도 이어서 진행하거나 안전하게 되돌려야 합니다. 완료되지 않은 작업을 실패로 숨기지 않습니다. + +Node Agent가 응답하지 않거나 일부 서버만 실패한 경우 전체 성공으로 묶지 말고 대상별 성공·실패·대기 결과를 보여주세요. 운영자는 각 모듈에 대해 현재 버전, 업데이트, 되돌리기, 복구와 다시 맞추기 결과를 확인할 수 있어야 합니다. + +# 30. 도메인, 메일, 백업과 이전 운영 + +## 30.1 도메인과 인증서 + +전체 도메인의 소유 확인, DNS, 인증서 발급과 갱신, 메일 보안 레코드, 최근 외부 확인, 만료와 반복 실패를 표시합니다. 같은 도메인이 여러 고객에게 잘못 연결되면 활성화를 막습니다. + +## 30.2 메일 운영 + +메일 서비스와 도메인, 메일함과 공간, 발송 제한, 수신 지연, 발송 대기, 외부 송수신 시험, DNS 보안, 정지·재개, 이전 요청을 확인합니다. + +메일 원문은 일반 운영 화면에서 열람하지 않습니다. 진단 시에도 최소 정보만 제공하고 접근 사유를 기록합니다. + +## 30.3 백업과 복원 + +활성 옵션, 예정·완료·실패 백업, 재시도, 검증, 만료, 복원 비용과 결제, 승인, 진행, 외부 확인, 되돌리기를 표시합니다. 승인 시 고객, 그룹, 사이트, 도메인, 백업 시각을 최종 확인합니다. + +## 30.4 서버 이전 + +이전 이유, 고객 영향, 출발과 도착, 사전 점검, 임시 공간과 용량 예약, 데이터 복사와 검증, 전환 시각, 고객 통지, 현재 단계와 되돌리기를 표시합니다. 전환 직전 조건이 달라지면 자동으로 중지하고 알립니다. + +## 30.5 Source/Gitea 운영 + +운영자는 사이트별 저장소 연결, 사용량과 한도, Source 옵션 상태, 읽기 전용 전환, 만료와 삭제 예정, clone·export 가능 기간, 연결 오류와 최근 배포 revision을 확인할 수 있어야 합니다. 다른 고객 저장소의 내용은 일반 조회 화면에 표시하지 않습니다. + +# 31. 모니터링, 장애와 공개 상태 + +## 31.1 고객 화면 + +고객은 자신의 서비스에 대해서만 정상, 성능 저하, 일부 장애, 중단 상태와 영향 기능, 시작 시각, 대응 상태, 다음 안내, 복구 시각을 볼 수 있어야 합니다. 내부 서버 이름과 다른 고객 정보는 노출하지 않습니다. + +## 31.2 운영자 화면 + +전체 서비스와 서버 상태, 고객 영향, 최근 배포, 관련 경고, 대응 작업, 담당자, 고객 공지, 복구 확인을 표시합니다. 같은 원인의 경고는 하나의 사건으로 묶고 실제 사용자 경로 확인 후 종료합니다. + +## 31.3 공개 상태 페이지 + +로그인 없이 주요 서비스 상태와 계획된 유지보수를 볼 수 있게 합니다. 개인정보와 내부 위치를 표시하지 않습니다. 고객 영향이 없는 내부 경고를 공개 장애로 자동 표시하지 않고, 실제 외부 확인 후 복구 완료를 게시합니다. + +# 32. 릴리스와 HAL 우선 배포 + +## 32.1 릴리스 화면 + +릴리스 버전, 기준 main 커밋, 빌드 시각, 승인 상태, 변경 이력, 검사 결과, HAL 배포 여부, 모듈별 배포 상태, 이전 릴리스를 표시합니다. + +## 32.2 배포 순서 + +최초 설치에서만 다음 범위의 부트스트랩 작업을 허용합니다. + +- 승인된 main 릴리스와 고정된 artifact 선택 +- HAL이 사용할 최소 저장 기능, 비밀정보 관리, 인증서 기반과 접근 경로 준비 +- HAL 설치 +- 첫 관리 서버에 Node Agent 등록 + +운영 화면에는 릴리스 버전, main 커밋, artifact 식별값, HAL 실제 실행 버전, 최초 Agent 등록 상태를 표시합니다. 첫 Agent 등록까지 끝나면 일반 모듈을 수동으로 설치할 수 없게 하고 HAL 전용 운영으로 전환합니다. + +정상 배포 순서는 다음과 같습니다. + +1. main에 병합된 승인 릴리스 선택 +2. 릴리스 파일과 검사 결과 확인 +3. HAL 먼저 배포 +4. HAL 자체 건강 상태와 실제 실행 버전 확인 +5. 첫 Node Agent 등록 또는 기존 Agent 연결 확인 +6. HAL이 나머지 Node Agent와 모듈 배포 +7. 모듈별 건강 상태와 실제 버전 확인 +8. 실제 고객 경로 확인 +9. 완료 또는 되돌리기 + +HAL 확인이 실패하면 나머지를 배포하지 않습니다. + +HAL 이후 HAL에서 배포, 갱신, 상태 확인, 되돌리기, 복구할 대상은 Customer Portal, Webmaker, Web Hosting, AriMail, Source/Gitea 연동 구성요소, Backup, Observability, Node Agent와 관련 작업 기능입니다. + +개별 서버에 임의 접속해 일반 배포하는 방식을 정상 운영 경로로 제공하지 않습니다. 명령 성공만으로 완료하지 말고 실제 실행 버전, 적용 설정, 건강 상태, 외부 사용자 경로와 주요 기능을 확인합니다. + +각 모듈은 최초 배포뿐 아니라 업데이트, 응답하지 않는 서버, 목표 버전과 실제 버전 차이, 일부 대상 실패, 되돌리기와 복구 결과를 대상별로 표시합니다. 일부 실패를 전체 성공으로 표시하지 않습니다. + +# 33. 긴급 복구 + +HAL의 정상 작업 기능을 사용할 수 없는 실제 장애에만 긴급 복구를 허용합니다. + +- 복구 이유와 사건 번호 +- 대상과 허용 작업 제한 +- 짧은 유효 시간 +- 두 명 승인 또는 동등한 독립 통제 +- 모든 작업 기록 +- 일반 배포 우회 금지 +- HAL 정상화 후 실제 상태와 원하는 상태 비교 +- 차이 수정과 최종 확인 + +긴급 자격정보는 다시 표시하지 않고 정상화 후 만료합니다. + +긴급 복구 요청자와 승인자는 원칙적으로 서로 다른 자격을 사용합니다. 동일인이 수행해야 하는 비상상황은 별도 독립 확인 절차와 시간 지연, 외부 감사 알림을 요구합니다. 허용 대상은 HAL, HAL 저장 정보, 비밀정보 관리, 인증서 기반, artifact 저장소와 최초 Node Agent 연결 복구로 제한하며 일반 고객 서비스 배포는 금지합니다. + +긴급 복구 화면은 선언, 승인, 자격 발급, 수행, 실제 결과 확인, 자격 폐기, HAL 상태 조정, 사건 종료 단계를 표시합니다. 승인 부족, 만료 자격, 허용 범위 밖 작업은 명확히 거부합니다. + +# 34. 플랫폼 재해복구 + +고객용 사이트 백업과 별도로 HAL 운영 정보, 진행 중 작업, 로그인과 권한 설정, 비밀정보 관리 설정, 인증서 기반, Webmaker 운영 상태, 서비스 배치와 서버 등록 정보를 복구할 수 있어야 합니다. + +운영 화면에서 최근 복구 사본, 외부 보관, 검증 결과, 최근 복구 훈련, 다음 훈련, 실패와 조치 항목을 표시합니다. + +복구 후 실제 서버, 사이트, 메일, 도메인, 백업 상태와 비교하여 차이를 보여주고 수정합니다. HAL, 로그인, 비밀정보 관리, 인증서 기반의 실제 복구 훈련이 성공하기 전에는 정식 운영 준비 완료로 표시하지 않습니다. + +운영자는 승인된 복구 목표 시간, 허용 가능한 데이터 시점, 복구 사본 생성 주기와 보존 개수를 설정하고 최근 훈련의 실제 측정값과 비교할 수 있어야 합니다. 버전 0.1.0 출시 검증에서는 이 값들이 비어 있으면 안 됩니다. + +복구 시작에는 별도의 승인과 기존 제어 위치의 중지 확인이 필요합니다. 복구 후에는 하나의 HAL만 운영 상태여야 하고, 진행 중이던 작업이 중복 실행되지 않아야 합니다. 실제 운영자 로그인, HAL 제어, HTTPS와 최소 한 개 고객 서비스의 외부 확인을 수행합니다. + +메일 플랫폼 복구는 서버, 도메인과 계정 설정만 대상으로 하며 메일 원문, 첨부파일, mailbox 내용은 포함하지 않습니다. 고객 화면에 메일 원문을 복구할 수 있는 것으로 표시하지 않습니다. + +# 35. 자동화와 사용자 선택의 연결 + +다음 작업은 사용자의 선택 또는 승인 정책에 따라 이어져야 합니다. + +- 상품 승인 후 권리 활성화 +- 최초 공개 배포 전 사이트 수 확보 +- 관리형 배포 전 서버와 용량 확보 +- 도메인 확인 후 인증서 발급 +- 메일 DNS 확인 후 송수신 시험 +- 백업 옵션 활성화 후 첫 백업과 검증 +- 복원 승인 후 격리 확인과 실제 복원 +- 이전 승인 후 사전 복사와 전환 +- 사이트 중지 후 신규 백업 중단 +- 옵션 만료 후 보존 안내와 삭제 +- 사용량 경고 후 알림과 증설 안내 + +자동화가 멈추면 조용히 넘어가지 말고 서비스 화면, 알림 센터, 운영 작업 화면에 동일한 상태와 필요한 조치를 표시합니다. + +# 36. 오류, 재시도와 중복 방지 + +- 같은 버튼을 반복해도 주문, 배포, 메일, 백업, 복원, 이전이 중복 생성되지 않아야 합니다. +- 새로 고침하거나 재로그인해도 진행 작업을 이어서 볼 수 있어야 합니다. +- 일시 오류는 안전한 범위에서 자동 재시도하고 횟수와 다음 시각을 표시합니다. +- 자동 재시도가 위험한 작업은 운영자 또는 사용자 확인을 기다립니다. +- 일부 결과가 남으면 남은 항목과 정리 상태를 보여주세요. +- 확인할 수 없는 상태를 완료로 표시하지 않습니다. + +# 37. 데이터 보호와 화면 제한 + +- 자격증명, 토큰, 비밀번호, API 키와 `.env` 값은 화면, 로그, 알림, 변경 이력에 표시하지 않습니다. +- 개인정보는 필요한 역할과 화면에서만 표시합니다. +- 비밀값은 저장 후 다시 읽어볼 수 없고 변경 또는 재발급만 제공합니다. +- 다른 사용자 그룹의 사이트, 도메인, 메일, 사용량, 주문이 검색과 자동완성에 노출되지 않아야 합니다. +- 내보내기 파일에도 현재 사용자가 볼 수 있는 정보만 포함합니다. +- 삭제와 보존 중인 데이터의 상태와 예정일을 정확히 표시합니다. + +# 38. 참고 소스의 사용자 경험 통합 + +AriMail, Webmaker와 기타 `OZ-Group` 소스에서 기능을 가져오더라도 Ariweb Suite의 공통 화면, 권한, 상태, 알림 체계에 맞게 통합합니다. + +기존 제품 화면을 그대로 복사하여 별도 시스템처럼 보이게 하지 않습니다. 중복 로그인, 서로 다른 상태 용어, 별도 고객 식별, 별도 결제와 권한 화면이 생기지 않아야 합니다. + + +/verification + +# Release 0.1.0 완료 조건 + +출시 검증 환경에는 최소 한 개의 구매 가능한 기본 상품과 사이트 수, 웹 용량, 월간 웹 아웃바운드, 메일 저장 공간, 월간 메일 통수, 메일함, 독립 메일, Source, 백업 옵션을 포함하는 버전 고정 검증 Catalog를 준비합니다. 가격, 통화, 세금, 수동 승인 방식, 권리, 한도, 백업 일정·보존, 복원 비용과 생명주기 결과가 비어 있으면 안 됩니다. 이 값은 출시 시험용이며 운영자가 관리하는 상품정책을 코드에 고정하지 않습니다. + +다음 흐름을 실제 배포 환경에서 처음부터 끝까지 확인해야 합니다. + +1. 신규 고객 가입과 이메일 확인 +2. 개인 사용자 그룹 생성과 다른 사용자 초대 +3. 상품 주문, 결제 확인, 권리 활성화 +4. 초안 사이트 생성 +5. Webmaker에서 페이지 제작 +6. 관리형 배포 +7. 도메인 연결과 HTTPS 발급 +8. 외부 주소에서 사이트 확인 +9. 사이트 정보와 접속·사용량 통계 확인 +10. 사이트 대표 메일과 메일함 생성 +11. 외부 송신, 수신, 회신 확인 +12. 독립 메일 서비스 생성 +13. 백업 옵션 구매와 첫 백업 확인 +14. 백업 복원과 외부 사이트 확인 +15. 관리형 사이트 서버 이전과 외부 확인 +16. 외부 배포 사이트 생성과 배포 +17. 사용량 경고와 한도 동작 확인 +18. 상품 축소 보류와 정리 후 적용 +19. 사이트 수 반환과 대표 메일의 독립 전환 +20. 사이트 소유권 이전 +21. 중지, 해지, 보존 예정일 표시 +22. HAL 우선 배포 후 HAL을 통한 전체 모듈 배포 +23. 실패 작업의 재시도와 되돌리기 +24. 운영자 승인, 감사 기록, 고객 알림의 일치 +25. HAL, 로그인, 비밀정보 관리, 인증서 기반의 재해복구 훈련 +26. 새로 고침, 재로그인, HAL 재시작 후 진행 작업 상태 유지 +27. 마지막 사이트 수, 용량 또는 메일함을 두 작업이 동시에 요청했을 때 하나만 성공 +28. 외부 Linux 서버의 Agent 연결, 배포, 재배포, 제거와 실패 정리 +29. HAL 장애 중 기존 웹·메일·Git 유지와 신규 변경 제한 표시 +30. 각 모듈의 업데이트, 일부 서버 실패, 대상별 되돌리기와 상태 조정 +31. 긴급 복구의 승인 부족·만료 자격·허용 범위 밖 작업 거부와 정상 복구 +32. Source 옵션 만료 후 30일 read-only, clone·export와 삭제 완료 +33. 메일 서비스의 사이트 대표→독립 전환 후 주소, 메일함, 별칭, 설정과 DNS 유지 +34. 일시 중지·해지 예약·보존·삭제 단계의 서비스, 청구, 권리, 내보내기 표시 일치 + +각 흐름은 버튼이나 명령의 성공이 아니라 최종 화면, 외부 접속, 실제 메일 왕복, 실제 사용량, 실제 배포 버전을 확인한 결과로 판정합니다. + +위 조건을 충족하지 못한 기능을 완료로 표시하거나 버전 `0.1.0` 출시 완료로 선언하지 않습니다.