# Ariweb Suite 개발 지시 — 작성자: Neo · v0.1.4 **작성자:** Neo **작성일:** 2026-10-27 **목적:** 기존 v0.1.1 통합 개발 지시를 유지하면서 미반영 오류 수정, HAL AI 대시보드, 다중 AI 공동 작업창을 v0.1.4 개발 범위로 지정합니다. **요약:** v0.1.1의 기존 기능·안전·배포·검증 지시를 보존하고, 독립 개선 항목 수만큼 patch 버전을 자동 증가시키는 규칙을 추가합니다. 이번 개정은 세 가지 추가 개선을 반영하므로 v0.1.4입니다. HAL 운영자 화면에 모델 연결·선택·다중 탭 AI 대시보드를 제공하고, 첫 탭에는 모델별 1회 의견과 1회 반론 뒤 최종안을 만드는 공동 작업창을 둡니다. 비밀정보는 Vault에만 저장하고, 변경·커밋·push·배포·복구는 기존 HAL 승인·감사·검증 경계를 그대로 적용합니다. ## 개정 이력 - **v0.1.1 · Hera · 2026-10-26:** Ariweb Suite 최초 통합 개발 지시, 기존 Webmaker·AriMail 재사용 원칙, 사용량 경고 70%·80%·90%·95% 반영. - **v0.1.4 · Neo · 2026-10-27:** 세 가지 추가 개선 항목에 따라 patch 버전을 3 증가. 미반영 오류 수정의 전수 반영, HAL AI 대시보드, 제한된 라운드의 다중 AI 공동 작업창 요구와 검증 조건 추가. /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. This release is version 0.1.4. When Oz does not explicitly specify a release version, increase only the final numeric component by the number of independently improved items in the approved development order. For example, three improvements applied to 0.1.1 produce 0.1.4. Apply this rule automatically to the development-order filename and document version, package/runtime version, release metadata, artifact names, operator-screen version display, `VERSION_HISTORY.md`, release notes, and deployment/read-back evidence. This revision adds three independently improved items to the 0.1.1 baseline, so its release version is 0.1.4. Describe this v0.1.4 revision in `VERSION_HISTORY.md`, including the author, previous version 0.1.1, the automatic version-increment calculation, warning-threshold change, reused existing functions, modified existing functions, resolved previously known errors, and all other changes 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, AI dashboard, AI collaboration, 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. Do not include passwords, API keys, tokens, private keys, recovery codes, customer mail contents, or other secret values in source code, documents, logs, tests, commits, or completion reports. 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. Requirements: # Ariweb Suite 개발 요구사항 — v0.1.4 **문서 버전:** v0.1.4 **작성자:** Neo **이전 버전:** v0.1.1 **통합 검토:** Hera v0.1.0 작성본, Neo v0.1.0 작성본, Hera v0.1.1 작성본, Ariweb Suite 1차 개발계획서 **이번 개정:** v0.1.1의 모든 핵심 지시를 유지하고 세 가지 추가 개선 항목을 반영해 v0.1.4로 업그레이드함 아래 기존 본문에 남아 있는 `버전 0.1.1` 표기는 삭제되거나 폐기된 요구가 아니라 v0.1.4에서도 계속 충족해야 하는 최초 릴리스 기준과 역사적 출처를 뜻합니다. 새로 추가된 39~42절과 충돌하지 않는 한 모두 필수이며, v0.1.4 구현이 그 기준을 낮추거나 누락해서는 안 됩니다. # 0. 기존 Webmaker·AriMail 기능 도입 원칙 Ariweb Suite를 개발할 때 기존 Webmaker와 AriMail에서 이미 정상 제공하는 기능을 새로 만들지 않습니다. 현재 `main`의 실제 기능과 테스트 결과를 먼저 확인하고, 사용할 수 있는 기능은 기존 동작과 사용자 경험을 유지한 채 Ariweb Suite에 그대로 도입합니다. 기존 기능을 가져왔다는 이유만으로 화면·동작·데이터를 임의로 다시 설계하지 않습니다. 이 문서에서 별도로 개선·수정하도록 지시한 부분과 Ariweb Suite의 공통 로그인·권한·상품·상태·알림 흐름에 연결하는 데 필요한 부분만 변경합니다. 기존 기능별로 다음 결과를 개발 이력에 기록합니다. - 그대로 도입 - Ariweb Suite 공통 화면에 연결하기 위한 최소 변경 - 오류 수정 - 정책 적용을 위한 기능 개선 - 사용하지 않음과 그 이유 기존 기능을 그대로 도입하는 경우에도 실제 화면과 기능을 확인하고 회귀 테스트를 수행합니다. 기존 기능이라고 추정하여 미검증 상태로 완료 처리하지 않습니다. ## 0.1 Webmaker에서 그대로 도입할 기능 현재 Webmaker에서 정상 작동하는 다음 기능은 우선 그대로 사용합니다. - `AI에게 맡기기`와 `내가 고르기` 방식의 Site 제작 - Site Brief 작성과 확인 - Template과 기존 제작 Module - Page 생성·편집·미리보기·저장 - AI 생성·수정과 Wallet/Cache 차감 - 이전 저장본과 배포할 저장본 선택 - Domain·DNS·TLS 관리 기능 - Gitea Source 연결과 변경 이력 - 관리형 또는 외부 대상 배포에 이미 사용할 수 있는 기능 - 배포 결과 확인과 이전 Version 복구 기능 - AriMail Server 연결과 Mail 사용량 표시 기능 - 사용자·관리자 화면에서 이미 제공되는 설정·상태·통계 기능 위 기능은 기존 화면과 동작을 실제로 확인한 뒤 사용합니다. 정상 기능을 같은 이름의 새 기능으로 중복 개발하지 않습니다. ## 0.2 Webmaker에서 별도로 수정·개선할 기능 Webmaker에는 다음 부분만 Ariweb Suite 사용에 맞게 수정합니다. - 별도 로그인 없이 Ariweb Suite의 현재 사용자와 사용자 그룹으로 이용 - Webmaker Project와 실제 운영 Site를 화면에서 명확히 구분 - Draft Site가 운영 Site 수를 사용하지 않도록 표시 - 관리형 배포와 외부 자가 배포의 비용·책임·상태를 구분 - Organization의 상품 권리와 Site별 보장량을 배포 전에 확인 - AI Wallet 사용량과 Hosting·Mail 사용량을 분리 - 기존 Site를 수정할 때 운영 Version을 바로 덮어쓰지 않고 Preview 후 배포 - 배포·Domain·Mail·Source의 진행 상태를 Ariweb Suite 공통 상태와 알림에 표시 - Project 삭제가 운영 Site·Domain·Source를 자동 삭제하지 않도록 영향 확인 - 여러 사용자의 동시 편집 충돌을 조용히 덮어쓰지 않고 사용자에게 표시 - 기존 기능의 오류가 확인된 경우 재현 후 회귀 테스트와 함께 수정 ## 0.3 AriMail에서 그대로 도입할 기능 현재 AriMail에서 정상 작동하는 다음 기능은 우선 그대로 사용합니다. - Multi-domain Mail Service - Webmail의 수신함·발신함·작성·회신·전달·검색 기능 - SMTP 발신과 Mail 수신 - IMAP·POP3 접속 - Resend, Haraka, External SMTP 등 현재 사용할 수 있는 발송 방식 - Mail Domain과 Mail Account 관리 - Mailbox 용량 관리 - 자동 응답과 Mail 전달 - 일반 첨부와 링크 방식 대용량 첨부 - POP3·IMAP 사용 설정 - DNS 설정과 Mail Domain 확인 - Mail 사용량과 Account별 사용량 확인 - Webmaker 연동 기능 - 초기 설정·관리자 설정·진단 기능 기존 Webmail과 Mail Protocol 기능은 Ariweb Suite 안에서 다시 개발하지 않습니다. Ariweb Suite는 기존 기능으로 이동할 수 있는 통합 진입점과 상태·상품·제한 화면을 제공합니다. ## 0.4 AriMail에서 별도로 수정·개선할 기능 AriMail에는 다음 부분만 Ariweb Suite 사용에 맞게 수정합니다. - `usage.test.mjs`의 KST·UTC 월 경계 오류를 고정 시각 기준으로 수정 - Haraka 또는 External SMTP 사용 시 Resend Key를 잘못 요구하는 발신 오류 수정 - Site 대표 Mail과 독립 MailService를 구분하여 표시 - Site마다 대표 Mail Domain 하나만 활성화 - 독립 MailService가 운영 Site 수를 사용하지 않도록 처리 - Mail Storage·월간 통수·Mail Account 수의 Site·MailService별 보장량 적용 - 월간 Mail 통수를 송신과 수신 합계로 표시 - 최종 수신자 한 명당 한 통으로 계산 - Mail Storage에 원문·일반 첨부·Inline 첨부·대용량 첨부를 포함 - Storage 100%에서 새 수신을 임시 거부하고 기존 읽기·삭제 유지 - 월간 통수 100%에서 새 발신을 막고 새 수신을 임시 거부 - 70%·80%·90%·95% 경고와 100% 제한 표시 - Domain·Server별 발송 Queue와 안전 발송 속도 적용 - Mail Domain 이전 중 두 Server에서 동시에 Mail을 처리하지 않도록 운영 상태 표시 - Site-bound Mail을 독립 MailService로 전환하는 기능 - 고객용 Mail Backup과 Mail 복원 기능을 제공하지 않음을 명확히 표시 - Mail Service 해지 후 30일 읽기·Export와 삭제 예정일 표시 ## 0.5 기존 기능 적용 확인 개발 완료 보고에는 Webmaker와 AriMail의 기능별로 `그대로 도입`, `최소 연결 변경`, `오류 수정`, `정책 개선`, `미사용`을 구분한 목록을 포함합니다. 그대로 도입한 기능은 원본 Source Revision, 실제 실행 화면, 회귀 테스트 결과와 Ariweb Suite에서 접근하는 위치를 기록합니다. 수정한 기능은 기존 동작, 변경 이유, 변경 후 사용자 화면과 검증 결과를 기록합니다. # 1. Ariweb Suite의 전체 사용자 흐름 Ariweb Suite는 고객이 회원가입 또는 로그인한 뒤 상품을 선택하고, 사이트를 만들고, 콘텐츠를 제작하고, 배포 방식과 도메인을 설정하고, 필요한 경우 메일과 백업을 추가하여 실제 서비스를 운영하는 하나의 연결된 서비스로 제공되어야 합니다. 사용자는 Webmaker, 웹호스팅, 메일, 도메인, 백업, 사용량, 결제가 서로 다른 시스템이라는 느낌을 받지 않아야 합니다. 모든 기능은 동일한 로그인 상태와 공통 화면 구성, 상태 용어, 알림 방식으로 이어져야 합니다. 기본 고객 흐름은 다음과 같습니다. 1. 회원가입 또는 로그인 2. 개인 계정 또는 사용자 그룹 선택 3. 상품 선택과 주문 4. 사이트 생성 5. Webmaker에서 사이트 제작 6. 배포 방식 선택 7. 관리형 서버 또는 외부 서버로 배포 8. 도메인 연결과 HTTPS 확인 9. 필요한 경우 사이트 대표 메일 활성화 10. 필요한 경우 추가 메일함 또는 독립 메일 서비스 생성 11. 필요한 경우 관리형 사이트 백업 옵션 구매 12. 대시보드에서 상태, 사용량, 알림, 비용 확인 13. 운영 중 재배포, 복원, 서버 이전, 소유권 이전, 중지와 해지 수행 선행 단계가 완료되지 않았으면 다음 단계로 무조건 넘기지 말고 필요한 입력, 대기 사유, 해결 방법을 해당 화면에 표시합니다. # 2. 공통 화면 구성과 상태 표시 ## 2.1 전체 화면 로그인 후 고객 화면은 다음 공통 구조를 사용합니다. - 상단에는 현재 사용자 그룹, 알림, 도움말, 사용자 메뉴를 표시합니다. - 왼쪽 메뉴에는 대시보드, 사이트, 메일, 도메인, 백업, 상품 및 결제, 사용량, 사용자 그룹 설정을 표시합니다. - 화면 제목 아래에는 현재 위치와 주요 작업 버튼을 표시합니다. - 결제 대기, 장애, 사용량 초과, 설정 오류, 사용자 확인 필요 항목은 화면 상단에 우선 표시합니다. - 긴 작업은 다른 화면으로 이동해도 계속 진행하며, 알림 센터와 해당 서비스 화면에서 다시 확인할 수 있어야 합니다. ## 2.2 작업 상태 사이트, 배포, 도메인, 인증서, 메일, 백업, 복원, 이전 작업은 다음 사용자용 상태를 일관되게 사용합니다. - 준비 전 - 설정 필요 - 승인 대기 - 결제 대기 - 처리 대기 - 진행 중 - 외부 작업 대기 - 검증 중 - 일시 중지 - 완료 - 실패 - 되돌리는 중 - 되돌림 완료 - 사용자 확인 필요 각 상태에는 현재 단계, 완료 단계, 다음 단계, 사용자가 해야 할 일, 예상 완료 시각 또는 산정할 수 없는 이유, 마지막 갱신 시각, 가능한 재시도·취소·문의 행동을 함께 표시합니다. 완료 메시지만 띄우지 말고 실제 외부 결과를 확인한 후 완료로 표시합니다. 비밀번호, 토큰, 인증 키, 내부 접속 정보, 개인정보는 상태와 작업 기록에 표시하지 않습니다. 서비스 상태, 작업 진행 상태, 외부 건강 상태를 하나의 상태로 합치지 않습니다. 예를 들어 사이트가 `운영 중`이더라도 새 배포 작업은 `실패`일 수 있고, 외부 접속은 `성능 저하`일 수 있습니다. 세 상태를 같은 화면에서 구분합니다. 주문, 배포, 도메인, 인증서, 메일 활성화, 백업, 복원, 이전, 되돌리기 화면에는 다음을 각각 표시합니다. - 허용되는 다음 단계 - 취소할 수 있는 마지막 단계 - 자동 재시도 횟수와 다음 시각 - 재시도 종료 후 필요한 사용자 또는 운영자 행동 - 완료·실패·취소 후 남는 서비스와 데이터 - 상태 정보가 오래된 경우의 `정보 확인 지연` 표시 동일 작업의 상태는 서비스 상세, 알림 센터, 운영자 작업 화면에서 서로 다르게 보이면 안 됩니다. 새로 고침, 로그아웃 후 재로그인, HAL 재시작 뒤에도 같은 작업을 이어서 확인할 수 있어야 합니다. ## 2.3 사용성 - PC, 태블릿, 모바일에서 핵심 조회, 승인, 중지, 재시도를 사용할 수 있어야 합니다. - 색상만으로 정상과 오류를 구분하지 않습니다. - 입력 항목마다 이름, 도움말, 오류 이유를 제공합니다. - 파괴적인 작업은 대상과 영향을 다시 보여주고 명시적 확인을 받습니다. 모든 고객·운영자 화면은 정상 데이터뿐 아니라 `불러오는 중`, `비어 있음`, `정보 지연`, `부분 실패`, `전체 실패`, `권한 없음` 상태를 제공합니다. 각 역할이 볼 수 있는 버튼과 거부되는 작업을 화면별로 확인하고, 알림의 링크는 사용자가 조치할 정확한 화면과 대상으로 이동해야 합니다. 모바일 검증은 최소 360px 너비에서 조회, 승인, 중지, 재시도, 알림 확인, 파괴적 작업 확인을 수행할 수 있는지 확인합니다. 표의 핵심 값과 작업 버튼이 가려지지 않아야 합니다. # 3. 회원가입, 로그인과 계정 복구 ## 3.1 회원가입 이메일 주소, 표시 이름, 비밀번호, 필수 약관 동의를 입력받습니다. - 이메일 확인 전에는 유료 상품 구매와 운영 서비스 생성을 허용하지 않습니다. - 이미 등록된 이메일이면 새 계정을 만들지 말고 로그인 또는 계정 복구를 안내합니다. - 가입 완료 후 개인 계정 형태의 기본 사용자 그룹을 준비하고 대시보드로 이동합니다. - 약관, 개인정보 처리방침, 마케팅 동의는 각각 구분합니다. - 가격, SLA, 환불, 개인정보, DPA, 백업, AUP, 정지 및 해지 정책은 승인된 문구만 표시합니다. ## 3.2 로그인과 세션 - 이메일과 비밀번호로 로그인할 수 있어야 합니다. - 잘못된 인증 정보는 이메일 존재 여부를 노출하지 않는 방식으로 안내합니다. - 반복 실패 시 일정 시간 추가 시도를 제한하고 해제 시각을 표시합니다. - 로그인된 기기와 세션 목록에서 개별 세션 또는 다른 모든 세션을 종료할 수 있어야 합니다. - 운영자 로그인 화면은 고객 로그인 화면과 분리합니다. ## 3.3 계정 복구와 다중 인증 - 외부 복구 이메일을 이용해 비밀번호를 재설정할 수 있어야 합니다. - 재설정 링크의 만료와 사용 완료 여부를 안내합니다. - 다중 인증은 선택 기능으로 등록, 확인, 해제할 수 있어야 합니다. - 복구 수단을 제공하고 복구 코드는 한 번만 표시합니다. - 운영자 계정에는 더 강한 인증을 권장하고 현재 보안 수준을 표시합니다. # 4. 사용자 그룹과 권한 개인과 여러 사람이 함께 사용하는 계정을 동일한 사용자 그룹 방식으로 제공합니다. ## 4.1 사용자 그룹 전환 - 사용자가 속한 그룹 목록을 상단 메뉴에서 전환할 수 있어야 합니다. - 그룹을 바꾸면 사이트, 메일, 도메인, 결제, 사용량이 즉시 해당 그룹 기준으로 바뀌어야 합니다. - 다른 그룹의 정보가 잠깐이라도 섞여 보이지 않아야 합니다. ## 4.2 구성원 관리 사용자 그룹 설정에서 다음을 제공합니다. - 그룹 이름과 연락처 변경 - 결제 담당자와 기술 담당자 지정 - 구성원 목록과 초대 대기 목록 - 이메일 초대, 재발송, 취소, 만료 표시 - 역할 변경과 구성원 제거 - 그룹 탈퇴와 그룹 소유권 이전 각 구성원에게 `user-01`, `user-02`와 같은 그룹 내 표시 별칭을 자동으로 부여하고 변경할 수 있게 합니다. 별칭은 화면 표시용이며 로그인과 권한의 기준으로 사용하지 않습니다. 각 구성원은 자신의 비밀번호와 세션을 사용합니다. 그룹 소유자도 다른 구성원의 비밀번호를 보거나 대신 로그인할 수 없습니다. 구성원을 정지하면 그 구성원의 세션과 아직 실행되지 않은 작업만 중지하고, 그룹의 상품·사이트·도메인과 다른 구성원의 작업은 유지합니다. 정지 전 영향 범위를 화면에 표시합니다. 권한이 부족하면 메뉴를 숨기는 것만으로 끝내지 말고 직접 주소로 접근해도 거부하고 필요한 역할을 안내합니다. ## 4.3 사이트별 권한 사이트마다 다음 권한을 지정할 수 있어야 합니다. - 조회 - 콘텐츠 편집 - 배포 - 도메인과 메일 설정 - 결제와 해지 - 전체 관리 변경 기록은 감사 기록에서 확인할 수 있어야 합니다. # 5. 고객 대시보드 ## 5.1 요약 다음 정보를 한눈에 보여주세요. - 운영 중인 사이트 수와 구매한 사이트 수 - 초안 또는 제작 중인 사이트 수 - 정상, 경고, 장애 상태의 사이트 수 - 관리형 배포와 외부 배포 수 - 연결된 도메인과 조치가 필요한 도메인 수 - 메일 서비스와 사용 중인 메일함 수 - 백업 옵션이 활성화된 사이트 수 - 처리 중인 주문, 배포, 복원, 이전 작업 수 - 이번 달 예상 비용과 결제 대기 금액 운영 사이트 수 요약에는 정상적으로 공개 배포되고 대표 웹 도메인이 연결된 사이트를 표시합니다. 초안과 제작 중 사이트는 포함하지 않습니다. 최초 공개 배포가 시작되면 사이트 수는 `예약됨`으로 별도 표시하고, 배포와 대표 도메인 확인이 끝나면 `사용 중`으로 전환합니다. 이미 운영 사이트 수를 소비한 사이트는 유지보수 또는 일시 중지 상태여도 계속 `사용 중`으로 표시합니다. ## 5.2 주의 항목과 최근 활동 결제 또는 승인 대기, 도메인 확인, 인증서 실패, 사용량 경고, 배포 실패, 메일 오류, 백업 실패, 이전 승인, 정지와 보존 만료, 현재 장애를 중요도 순으로 표시합니다. 항목을 선택하면 해결할 화면으로 이동합니다. 최근 배포, 설정 변경, 주문, 결제, 백업, 복원, 이전, 구성원 변경을 시간순으로 보여주고 사용자 작업과 자동 작업을 구분합니다. # 6. 상품 조회, 주문과 결제 ## 6.1 상품 목록 기본 상품과 추가 옵션에 다음을 표시합니다. - 상품 이름과 대상 사용자 - 포함된 사이트 수 - 웹호스팅 용량과 트래픽 - 메일 서비스, 메일함과 저장 공간 범위 - 추가 가능한 옵션 - 청구 주기, 승인된 가격과 세금 - 제공 범위와 제외 범위 - 미확정 정책 안내 가격과 한도는 화면에 고정하지 말고 운영자가 활성화한 최신 상품 조건을 표시합니다. ## 6.2 주문 흐름 1. 상품과 옵션 선택 2. 적용 대상 그룹 또는 사이트 선택 3. 가격과 청구 주기 확인 4. 약관과 제한 확인 5. 결제 방식 선택 6. 주문 제출 7. 결제와 승인 상태 확인 8. 권리 활성화 결제 또는 운영자 승인 전에는 사이트 수, 용량, 메일함, 백업 권리를 사용할 수 없어야 합니다. 새로 고침하거나 같은 버튼을 다시 눌러도 중복 주문, 결제, 권리 활성화가 발생하지 않아야 합니다. 버전 0.1.1의 기본 결제 흐름은 수동 결제 확인 방식입니다. 1. 주문 제출 후 입금 안내와 주문 번호를 표시합니다. 2. 고객은 결제 대기 상태와 안내된 금액·통화·세금·기한을 확인합니다. 3. 운영자가 실제 입금을 확인한 뒤 주문을 승인하거나 거절합니다. 4. 승인 완료 후에만 권리가 활성화됩니다. 5. 거절 또는 기한 만료 시 사유, 재주문 또는 문의 방법을 표시합니다. 자동 결제수단을 추가하기 전에는 지원하는 것처럼 표시하지 않습니다. 갱신, 미납, 환불, 크레딧의 적용일과 서비스 영향 시점은 고객과 운영자 화면에 동일하게 표시합니다. 갱신 전에는 청구 예정일과 금액을 알리고, 수동 결제가 확인될 때까지 `갱신 결제 대기`로 표시합니다. 결제 기한과 서비스 제한 예정 시각은 활성 상품정책에서 가져와 사전에 알리며, 미납 즉시 고객 데이터를 삭제하지 않습니다. ## 6.3 결제 화면 - 활성 상품과 추가 옵션 - 다음 청구일과 이번 달 예상 금액 - 미납 또는 결제 대기 금액 - 주문 항목, 수량, 적용 대상, 단가, 세금, 합계 - 결제와 운영자 승인 상태 - 활성화된 권리 - 청구서, 영수증, 환불, 크레딧 결제 실패 시 서비스 영향 시점과 해결 방법을 안내합니다. ## 6.4 상품 축소와 해지 축소 전에 현재 사용량과 할당량을 보여주세요. - 변경 후 범위 안에 들어올 때만 즉시 축소합니다. - 현재 사용량이 더 크면 줄여야 할 사이트, 용량, 메일함, 백업을 구체적으로 표시합니다. - 정리 완료 후 다시 검증하여 적용합니다. - 사용 중인 권리를 경고 없이 자동 회수하지 않습니다. ## 6.5 AI Wallet, 초과 사용과 도메인 주문 - AI Wallet의 잔액, 충전, 사용 이력, 작업별 차감과 실패 시 환급 여부를 호스팅 사용량과 분리해 표시합니다. - 자동 초과 사용과 자동 추가 과금은 기본으로 끕니다. - 고객이 초과 사용을 허용할 때 항목별 최대 금액 또는 최대 사용량, 적용 기간, 철회 결과를 명시적으로 확인합니다. - 도메인 등록과 갱신이 가능한 경우 검색, 가격, 등록 기간, 갱신일, 소유자 정보 확인, 결제, 등록·갱신 결과를 제공합니다. - 도메인 등록 기능을 제공하지 않는 환경에서는 외부 등록기관을 사용해야 한다는 안내만 표시하고 구매 가능한 것처럼 보이지 않게 합니다. # 7. 사이트 목록과 생성 ## 7.1 사이트 목록 다음 정보를 표시합니다. - 사이트 이름과 대표 웹 도메인 - 제작 및 배포 상태 - 관리형 또는 외부 배포 여부 - 메일과 백업 옵션 여부 - 최근 배포 시각 - 건강 상태와 사용자 조치 필요 여부 초안, 제작 중, 배포 중, 운영 중, 중지, 해지 대기로 필터링할 수 있어야 합니다. ## 7.2 사이트 생성 다음을 입력하거나 선택합니다. - 사이트 이름과 용도 - 새 Webmaker 프로젝트 또는 기존 프로젝트 - 시작 템플릿 - 기본 언어와 시간대 - 배포 방식을 지금 선택하거나 나중에 선택 초안 사이트 생성만으로 운영 사이트 수를 소비하지 않습니다. 최초 공개 배포 직전에 사이트 수를 확보하며, 확보할 수 없으면 상품 구매 또는 기존 사이트 정리를 안내합니다. 생성 후에는 Webmaker 제작, 콘텐츠 가져오기, 도메인 연결, 배포 방식, 구성원 권한 설정을 다음 단계로 안내합니다. # 8. 사이트 상세와 사이트 정보 사이트 상세는 개요, 제작, Source, 배포, 도메인, 메일, 백업, 사용량 및 통계, 활동 기록, 설정 탭으로 구성합니다. ## 8.1 사이트 정보 표시 정상적으로 배포된 사이트에는 다음을 표시합니다. - 대표 도메인과 접속 버튼 - 현재 배포 버전과 시각 - 관리형 또는 외부 배포 여부 - 현재 정상 여부 - 최근 24시간 접속 수 - 최근 7일과 30일 접속 추이 - 디스크와 데이터베이스 현재 사용량 및 한도 - 네트워크 인바운드와 아웃바운드의 일일, 월간, 누적 사용량 - 최근 오류와 성능 경고 - 다음 예정 작업 접속과 사용량 통계는 실제로 확보된 정보를 사용합니다. 생성 중이거나 정상 배포되지 않은 사이트에는 통계를 표시하지 않고 현재 준비 단계와 다음 작업을 보여주세요. 위 운영 상태와 사용량은 관리형 사이트에 적용합니다. 외부 배포 사이트에는 Ariweb가 현재 상태를 직접 보장하는 것처럼 정상·uptime·관리형 디스크·트래픽·백업 보호 상태를 표시하지 않습니다. 외부 사이트에는 External Pull Agent 연결 상태, 마지막 배포 결과와 시각, 배포된 버전, 마지막 외부 확인 결과, 고객 책임 범위를 표시하고 확인할 수 없는 값은 `제공되지 않음`으로 명시합니다. ## 8.2 사이트 설정 - 사이트 이름과 설명 - 대표 웹 도메인 - 기본 언어와 시간대 - 유지보수 모드 - 검색 엔진 공개 여부 - 사이트별 접근 권한 - 사이트 중지, 소유권 이전, 해지 서비스 중단이 예상되면 영향과 예상 시간을 적용 전에 보여줍니다. ## 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.1의 최소 제작 결과 첫 릴리스에서는 최소한 다음 결과를 실제로 제작하고 배포할 수 있어야 합니다. - 홈 페이지와 추가 페이지 - 제목, 본문, 이미지, 버튼, 링크, 메뉴 - 데스크톱과 모바일 미리보기 - 저장, 이전 저장본 선택, 선택한 저장본 배포 - 미리보기와 배포 결과의 핵심 콘텐츠 일치 - 저장하지 않은 변경의 이탈 경고 여러 사용자가 같은 프로젝트를 편집해 충돌한 경우 마지막 저장으로 조용히 덮어쓰지 말고 충돌과 선택 가능한 결과를 표시합니다. 지원하지 않는 콘텐츠 가져오기나 AI 기능은 메뉴에 노출하지 않거나 `이번 버전에서 지원하지 않음`으로 명시합니다. # 10. 웹 배포 방식 선택 ## 10.1 관리형 배포 다음을 보여주세요. - Ariweb가 서버 배치와 운영을 관리한다는 설명 - 모니터링 범위 - 용량과 트래픽 한도 - 백업 옵션 가능 여부 - 자동 또는 승인형 서버 이전 가능성 - 예상 배포 시간과 승인된 비용 버전 0.1.1의 관리형 배포는 정적 사이트와 Ariweb가 승인한 동적 사이트 실행 형태를 최소 대상으로 합니다. 선택 화면에서 현재 사이트가 지원 대상인지, 필요한 데이터베이스와 저장 공간이 무엇인지, 지원되지 않는 기능이 무엇인지 배포 전에 알려줍니다. ## 10.2 외부 배포 - 지원하는 외부 대상 - 사용자가 준비할 접속 정보 - 건별 배포 비용 - 제공하지 않는 관리형 모니터링, 백업, 이전, SLA - 외부 환경 장애는 Ariweb 정상 상태와 분리된다는 안내 외부 배포도 공개된 사이트라면 운영 사이트 수를 소비합니다. 관리형 디스크, 트래픽, 메일, 백업 권리를 자동 할당하지 않습니다. 버전 0.1.1의 외부 배포 대상은 External Pull Agent를 설치할 수 있는 지원 Linux 서버입니다. 화면에서 Agent 설치 안내, 일회용 연결, 연결 확인, 배포, 재배포, 배포 제거와 마지막 외부 확인 결과를 제공합니다. 실패한 배포의 남은 파일과 실행 상태를 알려주고 다시 시도하거나 제거할 수 있어야 합니다. 외부 배포를 시작하기 전에 고객 책임, 제공되지 않는 기능, 건별 비용을 버전이 기록되는 확인 화면에서 동의받습니다. 버전 0.1.1에서는 외부 메일 배포를 지원하지 않습니다. ## 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%, 80%, 90%, 95%이며 100%에서는 자원별 제한을 적용합니다. - 70%: Portal 사전 안내 - 80%: Portal과 외부 이메일 경고 - 90%: 예상 소진과 증설·정리 방법을 강조하는 긴급 경고 - 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%, 80%, 90%, 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.1 출시 검증 환경에서는 모두 설정되어 있어야 합니다. 포함 대상은 현재 배포본, 데이터베이스, 업로드 데이터, 복원에 필요한 사이트 설정입니다. 메일 원문, 소스 저장소, 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의 정상 작업 기능을 사용할 수 없는 실제 장애에만 긴급 복구를 허용합니다. - 복구 이유와 사건 번호 - 대상과 허용 작업 제한 - 짧은 유효 시간 - 운영자 재인증과 서로 다른 내용을 확인하는 3단계 반복 승인 - 모든 작업 기록 - 일반 배포 우회 금지 - HAL 정상화 후 실제 상태와 원하는 상태 비교 - 차이 수정과 최종 확인 긴급 자격정보는 다시 표시하지 않고 정상화 후 만료합니다. 운영자가 한 명일 수 있으므로 두 명 승인을 의무화하지 않습니다. 한 명이 수행하는 경우에도 영향 범위, 변경되지 않는 대상 식별정보, 최종 실행과 복구 가능 여부를 서로 다른 세 단계에서 확인하고 각 단계의 시각과 결과를 기록합니다. 허용 대상은 HAL, HAL 저장 정보, 비밀정보 관리, 인증서 기반, artifact 저장소와 최초 Node Agent 연결 복구로 제한하며 일반 고객 서비스 배포는 금지합니다. 긴급 복구 화면은 선언, 승인, 자격 발급, 수행, 실제 결과 확인, 자격 폐기, HAL 상태 조정, 사건 종료 단계를 표시합니다. 승인 부족, 만료 자격, 허용 범위 밖 작업은 명확히 거부합니다. # 34. 플랫폼 재해복구 고객용 사이트 백업과 별도로 HAL 운영 정보, 진행 중 작업, 로그인과 권한 설정, 비밀정보 관리 설정, 인증서 기반, Webmaker 운영 상태, 서비스 배치와 서버 등록 정보를 복구할 수 있어야 합니다. 운영 화면에서 최근 복구 사본, 외부 보관, 검증 결과, 최근 복구 훈련, 다음 훈련, 실패와 조치 항목을 표시합니다. 복구 후 실제 서버, 사이트, 메일, 도메인, 백업 상태와 비교하여 차이를 보여주고 수정합니다. HAL, 로그인, 비밀정보 관리, 인증서 기반의 실제 복구 훈련이 성공하기 전에는 정식 운영 준비 완료로 표시하지 않습니다. 운영자는 승인된 복구 목표 시간, 허용 가능한 데이터 시점, 복구 사본 생성 주기와 보존 개수를 설정하고 최근 훈련의 실제 측정값과 비교할 수 있어야 합니다. 버전 0.1.1 출시 검증에서는 이 값들이 비어 있으면 안 됩니다. 복구 시작에는 별도의 승인과 기존 제어 위치의 중지 확인이 필요합니다. 복구 후에는 하나의 HAL만 운영 상태여야 하고, 진행 중이던 작업이 중복 실행되지 않아야 합니다. 실제 운영자 로그인, HAL 제어, HTTPS와 최소 한 개 고객 서비스의 외부 확인을 수행합니다. 메일 플랫폼 복구는 서버, 도메인과 계정 설정만 대상으로 하며 메일 원문, 첨부파일, mailbox 내용은 포함하지 않습니다. 고객 화면에 메일 원문을 복구할 수 있는 것으로 표시하지 않습니다. # 35. 자동화와 사용자 선택의 연결 다음 작업은 사용자의 선택 또는 승인 정책에 따라 이어져야 합니다. - 상품 승인 후 권리 활성화 - 최초 공개 배포 전 사이트 수 확보 - 관리형 배포 전 서버와 용량 확보 - 도메인 확인 후 인증서 발급 - 메일 DNS 확인 후 송수신 시험 - 백업 옵션 활성화 후 첫 백업과 검증 - 복원 승인 후 격리 확인과 실제 복원 - 이전 승인 후 사전 복사와 전환 - 사이트 중지 후 신규 백업 중단 - 옵션 만료 후 보존 안내와 삭제 - 사용량 경고 후 알림과 증설 안내 자동화가 멈추면 조용히 넘어가지 말고 서비스 화면, 알림 센터, 운영 작업 화면에 동일한 상태와 필요한 조치를 표시합니다. # 36. 오류, 재시도와 중복 방지 - 같은 버튼을 반복해도 주문, 배포, 메일, 백업, 복원, 이전이 중복 생성되지 않아야 합니다. - 새로 고침하거나 재로그인해도 진행 작업을 이어서 볼 수 있어야 합니다. - 일시 오류는 안전한 범위에서 자동 재시도하고 횟수와 다음 시각을 표시합니다. - 자동 재시도가 위험한 작업은 운영자 또는 사용자 확인을 기다립니다. - 일부 결과가 남으면 남은 항목과 정리 상태를 보여주세요. - 확인할 수 없는 상태를 완료로 표시하지 않습니다. # 37. 데이터 보호와 화면 제한 - 자격증명, 토큰, 비밀번호, API 키와 `.env` 값은 화면, 로그, 알림, 변경 이력에 표시하지 않습니다. - 개인정보는 필요한 역할과 화면에서만 표시합니다. - 비밀값은 저장 후 다시 읽어볼 수 없고 변경 또는 재발급만 제공합니다. - 다른 사용자 그룹의 사이트, 도메인, 메일, 사용량, 주문이 검색과 자동완성에 노출되지 않아야 합니다. - 내보내기 파일에도 현재 사용자가 볼 수 있는 정보만 포함합니다. - 삭제와 보존 중인 데이터의 상태와 예정일을 정확히 표시합니다. # 38. 기존 기능의 Ariweb Suite 적용 AriMail, Webmaker와 기타 `OZ-Group` 소스에서 이미 정상 제공하는 기능은 기존 기능과 화면 동작을 우선 유지하여 도입합니다. 기존 기능을 같은 목적으로 다시 개발하지 않습니다. Ariweb Suite 공통 로그인, 사용자 그룹, 상품, 권한, 상태, 알림과 메뉴에 연결하는 데 필요한 최소 변경만 수행합니다. 이 문서에서 수정·개선을 별도로 지시하지 않은 기능은 임의로 재설계하지 않습니다. 고객에게는 하나의 Ariweb Suite 안에서 이용하는 것처럼 공통 메뉴와 이동 경로를 제공합니다. 중복 로그인, 별도 고객 식별, 별도 결제와 별도 권한 설정이 생기지 않게 하되, 기존 Webmaker 제작 기능과 AriMail Webmail 기능 자체는 정상 동작을 보존합니다. # 39. 버전 자동 업그레이드와 릴리스 반영 명시적인 버전 지시가 없으면 직전 승인 버전의 마지막 숫자만 이번 개발 지시에서 독립적으로 개선하는 항목 수만큼 증가시킵니다. 예를 들어 `0.1.1`에 세 가지 개선 항목을 반영하면 `0.1.4`가 됩니다. major·minor 숫자는 명시적 지시 없이 변경하지 않습니다. 버전 계산 결과는 개발 지시서 파일명과 문서 버전, 실행 패키지와 화면 버전, 릴리스 등록부, artifact 이름과 manifest, `VERSION_HISTORY.md`, 운영자 릴리스 화면, 배포 및 되돌리기 증거에 자동으로 동일하게 반영합니다. 어느 한 위치라도 다른 버전을 표시하면 릴리스를 승인하거나 배포하지 않습니다. 이번 개정은 다음 세 가지 독립 개선 항목을 추가하므로 `0.1.1`에서 `0.1.4`로 올립니다. 1. 기존 오류와 수정 사항 중 미반영 항목의 전수 반영 2. HAL AI 대시보드 3. 다중 AI 공동 작업창 버전 증가 수를 계산할 때 하나의 개선 항목을 하위 작업 수만큼 중복 계산하지 않습니다. 반대로 서로 독립된 사용자 기능을 하나로 묶어 증가 수를 줄이지 않습니다. 버전 계산 근거와 직전 버전은 `VERSION_HISTORY.md`에 기록합니다. # 40. 기존 오류와 수정 사항의 완전 반영 기존 개발, 검토, 테스트, 운영 배포, 장애 조사, 검증 문서와 `VERSION_HISTORY.md`에서 발견되었지만 현재 정본 `main`에 아직 반영되지 않은 오류와 수정 사항을 모두 다시 조사합니다. 구현을 시작하기 전에 `docs/known-fixes-v0.1.4.md`와 기계 판독 가능한 `docs/known-fixes-v0.1.4.json`을 정본 저장소에 먼저 추가합니다. 조사 범위에는 AriWeb-Suite 정본과 참조 저장소, 현재 열려 있거나 과거에 사용된 개발·검토 브랜치, `VERSION_HISTORY.md`, 오류·검증·배포·장애 문서, 저장소 issue·PR export, 운영 배포 기록을 포함합니다. 각 소스는 저장소 URL, branch 또는 문서 경로, 불변 commit·snapshot 식별자, 조사 기준 시각과 포함·제외 사유를 기록합니다. `현재 main에서 확인 가능한 전부`처럼 경계가 없는 표현으로 범위를 대신하지 않습니다. 각 발견 사항에는 안정적인 ID, 출처와 불변 revision, 증상, 영향, 현재 담당 영역, 아래 분류, 회귀 증거, 배포 여부와 실제 read-back 증거를 기록합니다. 구현 전 inventory에 없는 발견 사항이 나오면 먼저 inventory에 ID를 추가하고 분류한 뒤 작업합니다. 조사 범위의 소스 또는 발견 사항이 누락되거나 분류되지 않은 항목이 하나라도 남으면 릴리스를 차단합니다. 각 항목은 다음 상태 중 하나로 분류하고 근거를 남깁니다. - 현재 `main`에서 재현되며 이번 릴리스에서 수정 - 이미 수정되어 현재 테스트와 실제 동작으로 확인됨 - 현재 구조에서는 해당하지 않음 - 외부 조건이나 정책 결정이 필요하여 미반영이며 완료로 표시할 수 없음 - 보안 또는 데이터 보존 위험 때문에 제안된 방식 대신 안전한 대체 방식으로 수정 오류가 재현되면 실패하는 회귀 테스트를 먼저 만들고 실제 실패를 확인한 뒤 수정합니다. 과거 보고서의 해결 주장만으로 반영 완료로 판정하지 않습니다. 현재 코드, 데이터 마이그레이션, release artifact, 운영 설정, 실제 화면과 외부 경로를 각각 확인합니다. 기존 사용자, 사이트, 프로젝트, 배포본, 도메인, 인증서, 메일, Source/Gitea, 백업, 작업, 감사 기록과 서버 등록 정보는 보존합니다. 수정 과정에서 운영 데이터를 초기화하거나 기존 서비스를 불필요하게 재설치하지 않습니다. 마이그레이션 전 검증 가능한 백업과 되돌리기 경로를 준비하고, 수정 후 데이터 수·식별자·체크섬과 주요 서비스 경로를 다시 확인합니다. 완료 보고에는 조사한 전체 항목, 재현 결과, 수정 또는 제외 근거, 추가한 테스트, 배포 여부, 실제 read-back 결과와 남은 제한을 포함합니다. 미확인 또는 외부 조건 대기 항목은 `완료`가 아니라 정확한 대기 상태로 표시합니다. # 41. HAL AI 대시보드 ## 41.1 위치와 기본 동작 HAL 운영자 화면에 AI 대시보드를 추가합니다. 넓은 화면에서는 화면 오른쪽에 고정하거나 접을 수 있는 패널로 표시하고, 좁은 화면과 모바일에서는 화면 하단 패널로 전환합니다. 기존 HAL 메뉴와 작업 화면을 가리거나 중요한 승인 버튼을 덮지 않아야 합니다. 운영자는 패널 폭 또는 높이를 조절할 수 있어야 하며, 최소·최대 크기를 적용해 본문과 승인 동작을 사용할 수 없는 상태가 되지 않게 합니다. 접힘 상태, 선택 탭과 조절한 크기는 운영자별로 저장하고 새로 고침 뒤 복원하되, 화면 크기가 달라지면 안전한 범위로 다시 맞춥니다. AI 대시보드는 Webmaker의 AI 지시창처럼 운영자의 자연어 지시를 받아 작업합니다. 운영자는 현재 보고 있는 HAL 화면, 선택한 서버·모듈·작업·릴리스 정보를 AI 문맥에 포함할지 명확히 선택할 수 있어야 합니다. 전송되는 범위는 실행 전에 표시하며, 고객 개인정보·메일 원문·비밀값은 기본적으로 포함하지 않습니다. 패널에는 다음을 표시합니다. - 현재 선택한 연결과 모델 - 연결 상태, 인증 방식, 마지막 확인, 만료 또는 재로그인 필요 여부 - 현재 대화와 작업 상태 - AI가 이해한 목표, 계획, 영향 대상과 위험 - 실행 전 필요한 운영자 승인 - 실행 단계, 테스트, 커밋, push, 배포, 검증과 되돌리기 상태 - 실제 결과와 확인하지 못한 항목 - 중지, 다시 시도, 새 대화, 기록 보기 화면을 이동하거나 새로 고침해도 대화와 실행 중인 작업을 잃지 않습니다. HAL 재시작 뒤에도 중복 실행하지 않고 이전 작업 상태를 다시 읽어 이어서 표시합니다. ## 41.2 모델 연결과 선택 AI 모델은 다음 방식으로 연결할 수 있어야 합니다. - 서비스 로그인 또는 이미 승인된 로컬 로그인 세션 - OAuth - API 키 지원하는 공급자와 모델은 코드에 고정된 한 종류로 제한하지 않고 운영자가 연결을 추가, 확인, 비활성화, 재인증, 삭제할 수 있게 합니다. 연결마다 표시 이름, 공급자, 인증 방식, 사용 가능한 모델, 기본 모델, 권한 범위, 마지막 성공 시각과 오류를 표시합니다. 로그인·OAuth·API 키의 실제 비밀값은 HAL Vault 또는 승인된 외부 비밀정보 보관소에만 저장합니다. 저장 후 다시 표시하지 않고 변경 또는 폐기만 허용합니다. 비밀값은 브라우저 저장소, URL, 로그, 프롬프트, 대화 기록, 감사 상세, 작업 payload, 테스트 fixture, 소스, 커밋과 보고서에 남기지 않습니다. OAuth의 state·PKCE·redirect 대상과 만료를 검증하고 다른 연결이나 운영자 계정에 토큰을 잘못 연결하지 않습니다. 로컬 로그인 세션을 사용하는 연결은 실제 실행 계정과 세션 상태를 확인하고, 세션 파일이나 자격정보를 AI 대화에 노출하지 않습니다. API 키 연결은 서버 측에서만 모델 공급자에게 전달하며 브라우저에 다시 반환하지 않습니다. 모델 목록은 실제 공급자 응답 또는 승인된 운영 설정을 기준으로 갱신합니다. 사용할 수 없는 모델을 선택하면 조용히 다른 모델로 바꾸지 말고 선택 불가 이유와 다시 연결할 방법을 표시합니다. ## 41.3 모델별 탭과 동시 작업 공동 작업 탭 다음에 연결된 모델별 탭을 만듭니다. 운영자는 탭마다 연결과 모델을 선택하고 서로 다른 지시, 문맥, 작업을 동시에 진행할 수 있어야 합니다. 각 탭은 다음을 독립적으로 유지합니다. - 대화 기록과 첨부된 HAL 문맥 - 작업 목표와 계획 - 승인 상태 - 실행 중인 HAL 작업과 코드 작업 - 테스트·검증 결과 - 비용 또는 사용량 정보가 제공되는 경우 해당 값 - 오류, 재시도와 취소 상태 한 탭의 응답, 취소, 승인, 모델 변경 또는 오류가 다른 탭의 대화와 작업을 덮어쓰지 않아야 합니다. 같은 저장소, 서버 또는 서비스를 여러 탭이 동시에 변경하려 하면 대상 잠금과 충돌 가능성을 표시하고, 안전한 순서가 정해질 때까지 변경 실행을 막습니다. 조회와 분석은 동시에 할 수 있지만 상충하는 변경은 조용히 병렬 실행하지 않습니다. 변경 잠금은 브라우저 표시가 아니라 HAL 서버에서 원자적으로 획득합니다. 잠금 범위는 최소한 정본 저장소, worktree, branch, 서버, 서비스·모듈과 릴리스를 구분하는 정규 key로 정의합니다. 각 잠금에는 소유 대화·작업·운영자, 획득 시각, lease 만료, 단조 증가 fencing token과 idempotency key를 기록합니다. 작업 heartbeat가 끊기거나 HAL이 재시작되면 lease와 실제 작업 상태를 대조해 안전하게 회수하며, 이전 소유자의 늦은 결과는 fencing token으로 거부합니다. 파일 변경·commit·push·병합은 시작 base commit과 현재 원격 commit을 compare-and-swap 방식으로 확인하고, 배포·되돌리기·복구는 승인 당시의 desired state와 실행 직전 실제 state가 같을 때만 진행합니다. stale base, 만료 lease, 다른 fencing token, 중복 idempotency key 또는 승인 뒤 대상 변경은 실행을 거부하고 새 계획과 승인을 요구합니다. 잠금 획득·갱신·해제·강제 회수·충돌 거부는 감사 기록에 남깁니다. 서로 겹치지 않는 잠금 key의 작업은 병렬 실행 가능함을, 같은 범위 또는 stale 작업은 실제 변경 전에 차단됨을 동시성 테스트로 확인합니다. ## 41.4 HAL 작업 수행 범위 AI는 단순 설명에 그치지 않고 HAL의 승인된 기능을 이용해 다음 작업을 수행할 수 있어야 합니다. - HAL과 등록 서버·모듈·작업·릴리스·건강·사용량·사건·감사 기록 조회 - 오류 재현, 로그와 상태 분석, 수정안과 영향 범위 제시 - 격리된 작업공간에서 HAL 기능 추가·수정과 회귀 테스트 작성 - 전체 테스트, 빌드, secret scan과 독립 검토 실행 - 변경 diff와 파일 목록 제시 - 승인된 브랜치에 커밋하고 정본 저장소에 push - 승인된 변경을 `main`에 병합하고 원격 commit을 다시 읽어 확인 - 보호된 `main`에서 릴리스 artifact 생성·검증·등록 - HAL 우선 배포, 건강·실행 버전 확인, 필요한 모듈 배포 - 배포 후 실제 내부·외부 경로, 상태, 버전과 데이터 보존 확인 - 실패 시 중지, 재시도, 되돌리기와 복구 AI가 수행하는 작업도 기존 HAL 권한·재인증·3단계 확인·부트스트랩·릴리스 승인·Node Agent·감사·데이터 보호 규칙을 우회할 수 없습니다. AI의 요청은 운영자 신원, 선택한 연결과 모델, 대화, 승인, 실제 HAL 작업 번호와 연결해 기록합니다. 조회와 제안은 허용 범위에서 바로 수행할 수 있지만, 파일 변경, 커밋, push, `main` 병합, 릴리스 승인, 배포, 되돌리기, 복구, 서버 격리·삭제와 데이터 변경은 실행 전 정확한 대상과 영향, 검증 및 되돌리기 방법을 운영자에게 보여주고 기존 위험 등급에 맞는 승인을 받아야 합니다. 사용자의 자연어 지시를 승인 단계 생략으로 해석하지 않습니다. 모델이 임의 명령 문자열을 운영 서버 셸에 직접 전달하지 않게 합니다. 저장소 작업은 격리된 branch/worktree와 제한된 개발 실행기를 사용하고, 운영 작업은 HAL의 형식화된 작업과 Node Agent 허용 기능으로 실행합니다. 허용되지 않은 명령, 경로, 저장소, 서버, 비밀 접근과 네트워크 대상은 거부하고 이유를 표시합니다. 저장소 파일, 로그, 웹 문서, 고객 데이터, 첨부파일과 다른 모델의 응답은 모두 신뢰할 수 없는 입력으로 취급합니다. 그 안에 포함된 지시문은 운영자 승인, 시스템 정책, 허용 도구와 대상 범위를 변경할 수 없습니다. 모델의 문장이나 공동 작업의 합의를 승인으로 사용하지 않으며, 도구 인자는 HAL이 schema·권한·경로·네트워크 allowlist로 다시 검증합니다. prompt injection, 승인 위조, 도구 인자 확장, 비밀 유출과 범위 밖 네트워크 접근을 재현하는 적대적 테스트를 통과해야 합니다. AI가 생성한 결과만으로 완료를 선언하지 않습니다. 테스트 종료 코드, 원격 commit read-back, artifact checksum, 실행 버전, 건강 상태와 실제 사용자 경로 등 작업 종류에 필요한 증거를 HAL이 독립적으로 확인해야 합니다. ## 41.5 기록, 비용과 실패 처리 모든 AI 요청과 응답에는 시각, 운영자, 연결, 공급자, 모델, 탭, 대화, 작업 번호와 결과를 연결합니다. 감사 기록에는 비밀값과 전체 프롬프트 원문 대신 안전한 요약과 식별자를 저장하고, 필요한 운영 기록은 보존 정책에 따라 조회할 수 있게 합니다. 공급자가 제공하는 입력·출력 토큰, 비용, 제한과 오류를 탭별·모델별로 표시합니다. 제공되지 않는 값은 `제공되지 않음`으로 표시하고 추정값을 실제 비용처럼 표시하지 않습니다. 모델 연결 실패, 인증 만료, rate limit, timeout, 잘못된 응답, 도구 실행 실패, 테스트 실패, push 충돌, 배포 실패를 구분합니다. 자동 재시도는 읽기와 안전한 멱등 작업에만 적용하고, 변경 작업은 중복 실행 가능성을 먼저 확인합니다. 중지 요청 후 새 변경을 시작하지 않고 이미 시작된 외부 작업과 남은 영향을 표시합니다. # 42. AI 공동 작업창 ## 42.1 첫 번째 고정 탭 AI 대시보드의 가장 첫 번째 탭은 `공동 작업`으로 고정합니다. 모델별 탭보다 앞에 표시하고 삭제하거나 순서를 바꿀 수 없게 합니다. 운영자는 공동 작업에 참여할 연결과 모델을 둘 이상 선택하고 하나의 목표, HAL 문맥, 제약과 원하는 결과를 입력할 수 있어야 합니다. 각 모델의 이름, 연결 상태, 역할, 응답 상태와 실패를 구분해 표시합니다. 한 모델의 실패를 다른 모델의 합의로 숨기지 않고, 실패한 모델과 포함되지 못한 의견을 결과에 명시합니다. ## 42.2 제한된 합의 절차 한 공동 작업은 다음 순서로만 진행합니다. 1. 운영자가 목표, 참여 모델, 문맥과 제약을 확정합니다. 2. 각 모델이 다른 모델의 첫 의견을 보지 않은 상태에서 최초 의견을 정확히 한 번 제출합니다. 3. 모든 최초 의견을 공개한 뒤 각 모델이 다른 의견에 대한 반론 또는 보완 의견을 정확히 한 번 제출합니다. 이 응답은 합의한 부분, 남은 차이와 선호안을 구조화해 포함합니다. 4. 최초 의견을 가장 먼저 제출한 모델이 전체 의견과 반론을 바탕으로 최종안을 한 번 작성합니다. 5. HAL은 저장된 최초 의견, 반론과 최종안을 비교해 합의된 부분과 남은 차이를 결정론적으로 정리합니다. 이 단계와 그 이후에는 어떤 모델도 다시 호출하지 않습니다. 6. 남은 차이가 없으면 최종안을 사용자에게 제시하고, 실행이 필요한 경우 별도의 승인 단계로 이동합니다. 7. 최종 결과가 다르면 합의된 부분, 모델별 차이, 선택에 따른 영향과 각 선택안을 명확히 표시하고 사용자 판단을 기다립니다. 모델마다 `최초 의견 1회 + 반론 1회`를 초과하는 자동 대화를 허용하지 않습니다. 최초 제출 모델만 이 두 호출에 더해 최종안 작성 호출을 정확히 한 번 수행합니다. 그 밖의 모델은 최종안 뒤에 동의 확인, 재반론 또는 새 공동 작업을 위해 다시 호출하지 않습니다. timeout, 빈 응답과 모델 실패도 해당 차례를 소비한 것으로 기록하고 정해진 종료 상태로 이동합니다. 최초 의견 제출 순서가 동시에 보이는 경우 HAL이 접수한 순번으로 최초 제출자를 결정합니다. 최초 제출 모델이 최종안을 만들 수 없으면 다른 모델에게 최종안 작성을 넘기지 않고 공동 작업을 `FINAL_AUTHOR_FAILED`로 종료합니다. 수집된 의견과 반론, 실패 원인을 사용자에게 표시하고 명시적 사용자 판단 또는 사용자가 시작한 새 공동 작업을 기다립니다. ## 42.3 결과와 실행 공동 작업 화면은 다음을 구분해 보여줍니다. - 사용자 목표와 제약 - 참여 모델과 선택한 버전 - 모델별 최초 의견 - 모델별 반론 또는 보완 - 최종안 작성 모델과 최종안 - 합의된 사항 - 남은 차이와 모델별 선택안 - 사용자 결정 대기 여부 - 사용자가 선택한 최종 결정 - 실행 계획, 승인, 작업 번호, 실제 결과와 검증 공동 작업의 합의는 실행 승인이 아닙니다. 최종안이 나와도 파일 변경, commit, push, 병합, 배포, 되돌리기와 복구는 41.4절과 기존 HAL 승인 규칙을 거칩니다. 사용자가 선택한 안과 다르게 모델이 임의로 절충하거나 실행하지 않습니다. 동일한 공동 작업을 새로 고침하거나 재시도해도 이미 제출된 의견 수를 늘리지 않습니다. 각 단계는 멱등하게 저장하고 HAL 재시작 뒤 정확한 다음 단계에서 이어갑니다. 취소된 공동 작업은 새 모델 호출과 변경 실행을 중지하고 기존 응답과 실행된 영향만 읽기 전용으로 남깁니다. /verification # Release 0.1.4 완료 조건 출시 검증 환경에는 최소 한 개의 구매 가능한 기본 상품과 사이트 수, 웹 용량, 월간 웹 아웃바운드, 메일 저장 공간, 월간 메일 통수, 메일함, 독립 메일, 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. 일시 중지·해지 예약·보존·삭제 단계의 서비스, 청구, 권리, 내보내기 표시 일치 35. 버전 자동 계산: 직전 버전 0.1.1과 독립 개선 항목 3개로 0.1.4가 계산되고 문서·package/runtime·artifact·manifest·릴리스 화면·`VERSION_HISTORY.md`·배포 read-back이 모두 같은 버전을 표시 36. `docs/known-fixes-v0.1.4.md`·`.json`이 조사 대상별 불변 revision과 cutoff를 기록하고, 모든 발견 사항이 안정 ID·분류·회귀·배포·read-back 증거를 가지며 누락 또는 미분류 항목이 0건임 37. HAL AI 대시보드가 넓은 화면 오른쪽과 좁은 화면 하단에서 기존 운영 화면을 가리지 않고 열림·접힘·크기 변경·새로 고침 복원을 지원 38. 로그인 세션·OAuth·API 키 방식의 모델 연결을 추가·확인·재인증·비활성화·삭제하고, 비밀값이 Vault 밖 응답·로그·감사·대화·작업·소스·테스트에 남지 않음 39. 연결별 실제 모델 목록과 사용 가능 상태를 확인하고, 선택 불가 모델을 임의 대체하지 않음 40. 공동 작업 탭이 항상 첫 번째이며 모델별 여러 탭의 대화·문맥·작업·오류·취소·모델 선택이 서로 격리됨 41. 같은 저장소·서버·서비스의 상충 변경을 여러 탭에서 동시에 실행하려 할 때 잠금과 충돌 안내로 차단하고 조회 작업은 안전하게 병행 42. AI가 격리 작업공간에서 오류 재현·코드 수정·테스트·검토를 수행하고, 승인 뒤 commit·push·main 병합·원격 read-back·릴리스 생성·HAL 우선 배포·검증·되돌리기까지 HAL 작업 번호와 감사 기록으로 연결 43. 모델이 임의 셸 명령, 허용되지 않은 경로·저장소·서버·네트워크, 비밀 접근 또는 기존 재인증·3단계 확인·릴리스 승인·Node Agent 경계를 우회하지 못함 44. AI가 완료라고 응답해도 테스트 종료 코드, 원격 commit, artifact checksum, 실행 버전, 건강 상태와 실제 사용자 경로가 확인되지 않으면 완료로 표시하지 않음 45. 공동 작업 provider 호출 수가 모델마다 최초 의견 1회·반론 1회이고 최초 제출 모델만 최종안 1회를 추가하며, 최종안 이후 provider 호출이 0회임을 요청 식별자와 테스트로 확인 46. 최초 제출 모델이 최종안 작성에 실패하면 다른 모델로 넘기지 않고 `FINAL_AUTHOR_FAILED`로 종료하며, 수집 결과와 실패 원인을 표시하고 사용자 결정 또는 사용자가 시작한 새 공동 작업 전에는 재호출하지 않음 47. 최종 결과가 다르면 합의된 부분, 모델별 차이, 선택 영향과 선택안을 사용자에게 제시하고 사용자 결정 전에는 실행하지 않음 48. 공동 작업의 새로 고침·재시도·HAL 재시작에서 의견 횟수와 단계가 중복되지 않고, 취소 뒤 새 모델 호출과 변경 실행이 시작되지 않음 49. 원자적 server-side lock, 정규 lock key, lease·crash recovery, fencing token, base commit·desired state compare-and-swap와 idempotency가 겹치지 않는 작업의 안전한 병렬 실행 및 stale·충돌 변경의 사전 거부로 검증됨 50. 저장소 파일·로그·웹 문서·고객 데이터·첨부파일·모델 응답에 포함된 prompt injection이 승인·권한·도구 schema·경로·네트워크 범위를 바꾸거나 비밀을 노출하지 못함 51. 기존 본문의 v0.1.1 최초 릴리스 기준 1~34가 v0.1.4에서도 모두 유지되고 새 기능 추가로 회귀하지 않음 각 흐름은 버튼이나 명령의 성공이 아니라 최종 화면, 외부 접속, 실제 메일 왕복, 실제 사용량, 실제 배포 버전을 확인한 결과로 판정합니다. 위 조건을 충족하지 못한 기능을 완료로 표시하거나 버전 `0.1.4` 출시 완료로 선언하지 않습니다.