사이트, 도메인 및 웹

제대로 동작하는 웹사이트는 Apache가 실행되고 있다는 것만으로 완성되지 않습니다. 도메인이 해석되어야 하고, 인증서가 유효해야 하며, 올바른 머신이 응답해야 하고, 그 앞에 CDN이 있어야 하며, 검색 엔진이 사이트의 존재를 알아야 합니다. FrontierStack은 이 모든 것을 사이트 패널과 몇 가지 보조 도구에 모아, 등록 기관, DNS, TLS, CDN, 호스트, SEO로 이어지는 전체 체인을 한 윈도우에서 확인하고 고칠 수 있게 합니다. 이 장에서는 스택 위의 웹 영역을 다룹니다. 가상 호스트와 인증서 자체는 4장을 참조하십시오.

7.1사이트 패널과 도메인 상태

사이드바에서 사이트를 여십시오. 맨 위에는 도메인 상태 섹션이 있습니다. 이 섹션은 FrontierStack이 알고 있는 모든 호스트 이름을 모아 보여 주는 실시간 대시보드로, 직접 정의한 로컬 Apache 및 Nginx 가상 호스트, 연결된 서버의 가상 호스트, 토큰에 포함된 모든 Cloudflare 영역, 등록 기관 모니터에 있는 모든 도메인이 포함됩니다. 각 도메인은 상태 배지가 붙은 한 행으로 표시됩니다. 행의 확인이나 머리글의 모두 확인을 누르면 앱이 도메인을 처음부터 끝까지 점검하고 배지를 녹색 또는 주황색으로 표시합니다.

이 대시보드의 목적은 이 도메인이 실제로 서비스되고 있는가, 그리고 어디에서 서비스되고 있는가?라는 한 가지 질문에 확실하게 답하는 것입니다. 점검은 공용 인터넷을 대상으로 실행되므로(실제 DNS 조회, 실제 HTTP 요청, 실제 TLS 핸드셰이크), 로컬 설정 점검으로는 결코 발견할 수 없는 장애를 잡아냅니다. 잘못된 IP를 가리키는 레코드, 만료된 인증서, “pending” 상태에 머물러 있는 Cloudflare 영역, 해석은 되지만 502를 반환하는 사이트 등이 그 예입니다.

7.2사이트별 Search Console, Analytics, Ahrefs

도메인 상태의 각 행에는 상태 배지 아래에 Search Console, GA4, Ahrefs 세 개의 칩이 있는 짧은 줄이 있습니다. 회색은 해당 사이트에 그 서비스가 설정되지 않았음을, 녹색은 서비스가 켜져 있고 문제가 없음을, 노란색은 살펴볼 만한 사항이 있음을, 주황색은 알림도 발생시키는 문제가 있음을 뜻합니다. 칩 위에 포인터를 올리면 발견된 내용을 볼 수 있고, 클릭하면 해당 서비스의 패널이 열립니다. 이 줄은 각 제공업체의 콘솔을 복제하지 않습니다. 사이트마다 두 가지 질문, 즉 서비스가 켜져 있는가, 그리고 소유자가 알아야 할 사항이 있는가에 답합니다.

점검 항목은 연결한 서비스에 따라 늘어납니다.

• 키가 전혀 없으면 FrontierStack은 실제 홈페이지, robots.txt, 도메인의 TXT 레코드를 읽습니다. Google Analytics와 Tag Manager 태그, Ahrefs Web Analytics 스크립트, Google과 Ahrefs의 인증 토큰을 찾아냅니다. 홈페이지에 noindex가 있거나(meta 태그 또는 X-Robots-Tag 헤더), robots.txt가 사이트 전체에서 Googlebot, AhrefsBot, AhrefsSiteAudit를 차단하면 경고합니다. 오래된 Universal Analytics(UA-) 태그도 더 이상 데이터를 수집하지 않으므로 지적합니다.
• Google에 로그인하면(Search Console 패널의 Sign in with Google 또는 서비스 계정 키) 각 사이트를 Search Console 속성과 대응시킵니다. 그런 다음 FrontierStack은 다음을 점검합니다.
  • 해당 속성에 대한 소유권 인증이 아직 유효한지
  • 제출한 사이트맵에 오류가 보고되는지
  • 홈페이지에 대한 Google URL 검사 결과: 가져올 수 있었는지, robots.txt나 noindex로 차단되는지, 색인이 생성되었는지
  • 검색 노출수가 전주 대비 급감했는지
  같은 로그인으로 사이트를 GA4 속성과도 대응시킵니다. 웹 스트림의 URL 또는 페이지가 실제로 데이터를 보내는 측정 ID를 기준으로 합니다. 속성이 데이터 수신을 멈추거나, 페이지가 속성이 기대하는 것과 다른 측정 ID로 데이터를 보내면 경고합니다.
• Cloudflare 토큰이 있으면 영역의 방화벽 이벤트를 읽어, 지난 하루 동안 WAF, 속도 제한, 봇 규칙에 의해 차단된 Googlebot, AhrefsBot, AhrefsSiteAudit 요청을 찾고 원인이 된 규칙을 알려 줍니다. Google과 Ahrefs 자체 네트워크에서 온 요청만 집계합니다. Googlebot을 사칭하는 가짜 봇을 Cloudflare가 차단하는 것은 정상적인 동작이므로 보고하지 않습니다.

모든 항목은 6시간마다, 그리고 확인이나 모두 확인을 누를 때마다 다시 점검됩니다. 문제는 사이트와 서비스별로 하나씩 Search & Analytics 그룹 아래의 알림으로 전송되므로, 문제가 해결되면 복구 알림이 전송됩니다. Ahrefs 문제는 실제로 Ahrefs를 사용하는 사이트에서만 발생시킵니다. 사용하지 않는 크롤러를 차단하는 것은 결함이 아니라 선택이기 때문입니다.

7.3ChatGPT Sites: 모니터링, 내 도메인 사용, 자체 호스팅

ChatGPT Sites 섹션은 FrontierStack 안에서 이 섹션이 나타나는 모든 곳에서 하나의 공유 레지스트리를 사용합니다. 공개 name.openai.chatgpt.site URL을 붙여넣으면 다른 사이트와 마찬가지로 도메인 상태, SEO, 알림에 추가됩니다. 워크스페이스 전용 또는 소유자 전용 Site를 비공개로 표시하면 외부 점검이 일시 중지됩니다. 그 로그인 페이지는 서비스 중단이 아니기 때문입니다.

Import or Move는 소유자가 승인한 두 가지 경로를 제공합니다. Use my domain은 Site를 ChatGPT에 그대로 둡니다. 먼저 Site의 ChatGPT 설정에서 도메인을 추가한 다음, ChatGPT가 제공하는 DNS 레코드를 그대로 복사하십시오. FrontierStack은 모든 레코드가 선택한 Cloudflare 영역에 속하는지 검증한 뒤 DNS 전용으로 게시합니다. 다른 DNS 제공업체를 사용한다면 그곳에 레코드를 추가하고 Save Domain을 사용하십시오. 두 경로 모두 원래의 Sites 주소와 사용자 지정 도메인을 레지스트리에 유지합니다. DNS가 전파된 후 ChatGPT로 돌아가 도메인 상태를 새로 고치십시오.

Self-host는 Site의 로컬 프로젝트 폴더에서 시작합니다. FrontierStack은 .openai/hosting.json과 package.json을 읽어 프레임워크와 빌드 완료된 출력 폴더를 식별하고, D1/R2 바인딩과 예시 환경 변수의 이름을 보여 준 뒤, 검토한 웹 출력을 관리되는 Apache 도메인으로 복사합니다. 가져오기 도구는 패키지 스크립트를 실행하지 않고, 비밀 값을 읽지 않으며, 링크와 소스 관리 메타데이터를 건너뛰고, 복사량을 50,000개 파일 또는 5 GB로 제한하며, 교체에 실패하면 되돌릴 수 있도록 스테이징 폴더를 사용합니다. 먼저 프로젝트를 빌드한 다음 dist, build, out, public 또는 index.html이 들어 있는 다른 폴더를 가져오십시오.

7.4도메인 소유권 증명

제공업체는 소유자만 만들 수 있는 DNS TXT 레코드를 게시하도록 요청하여 도메인이 내 것인지 확인합니다. ACME의 DNS-01 챌린지와 같은 DNS 기반 증명 방식이지만, 레코드 형식은 제공업체마다 다릅니다. 도메인 상태 행의 Verify 버튼은 이러한 형식을 한곳에 모아 둡니다. 서비스(Google(Search Console / Workspace), Microsoft 365, Meta, Apple Business Manager, Atlassian, OpenAI, Stripe, GitHub 조직 또는 사용자 지정 레코드)를 선택하고 제공업체 콘솔의 토큰을 붙여넣으면, FrontierStack이 TXT 레코드를 해당 도메인의 Cloudflare 영역에 바로 게시합니다. 도메인이 내 Cloudflare 토큰에 포함되어 있지 않으면, 대신 DNS 호스트에 추가할 정확한 레코드를 알려 줍니다. 토큰만 입력하면 자동으로 완성됩니다(Google의 경우 abc123을 붙여넣으면 레코드가 google-site-verification=abc123이 됩니다).

시트에는 apex에 이미 게시된 인증 레코드도 표시되므로, 이 도메인이 현재 누구에게 증명되어 있는지 빠르게 점검할 수 있습니다. Check DNS는 공용 DNS(1.1.1.1)에서 새 레코드를 조회하므로, 제공업체 쪽에서 “Verify”를 누르기 전에 증명이 보이는지 확인할 수 있습니다.

인증서의 경우 Let's Encrypt 서비스 패널(Security & Secrets 카테고리)이 또 다른 종류의 도메인 증명을 상시 점검합니다. ACME API, Let's Encrypt 상태 페이지, 도메인의 실제 인증서를 감시하며, ACME 클라이언트는 30일이 남았을 때 갱신하므로 인증서가 갱신 기한을 넘기면 알림을 보냅니다. 이를 통해 망가진 certbot/acme.sh 자동화를 방문자가 만료 경고를 보기 몇 주 전에 잡아낼 수 있습니다.

7.5AI SEO와 “Fix My Site”

도메인 행의 배지 중 두 개는 단순한 진단 표시가 아니라, 문제를 AI 관리자에게 넘기는 버튼입니다. Fix My Site는 망가졌거나 이상하게 동작하는 사이트를 받아 정해진 절차대로 어시스턴트를 실행합니다. Host 헤더를 붙여 로컬에서 사이트에 curl을 실행하여 장애를 재현하고, 관련 로그를 읽고, Apache, PHP, 데이터베이스가 실행 중인지 확인한 다음, 가장 가능성이 높은 근본 원인 하나와 구체적인 다음 단계를 제시합니다. Allow changes가 꺼져 있으면 조언만 하고, 켜져 있으면 되돌릴 수 있는 수정(서비스 재시작, 설정 파일의 잘못된 값 수정, 데이터베이스 복구)을 적용할 수 있습니다. 전형적인 흰 화면, “Error establishing a database connection”, 망가진 고유 링크, 유지 관리 모드에서 빠져나오지 못하는 문제를 처리하는 WordPress 전용 변형도 있습니다.

SEO 작업은 기기 내에서 읽기 전용 감사를 실행합니다. 어시스턴트가 홈페이지, robots.txt, 사이트맵을 가져와 사이트를 100점 만점으로 채점하고 짧은 보고서(제목, 메타 설명, 머리글, 크롤링 가능성, 구조화된 데이터)를 작성합니다. 결과는 SEO 보고서 시트로 열리므로 발견 사항을 읽고 조치할 수 있습니다.

7.6원클릭 CMS 설치(Apps & CMS)

WordPress에는 새 사이트를 설치하는 일과 이미 있는 사이트를 운영하는 일을 모두 맡는 단일 패널이 있으며, 이 Mac과 모든 플릿 서버에서 사용할 수 있습니다. 이 통합은 중요합니다. 예전 설치 패널은 This Mac에만 쓸 수 있었지만, 이 패널의 모든 작업은 선택한 호스트에서 WP-CLI로 실행되므로 원격 서버도 새 설치의 대상으로 동등하게 다룰 수 있습니다. 패널 하단의 Install a new WordPress site는 선택한 호스트에 WordPress를 다운로드하고, wp-config.php를 작성하고, 데이터베이스를 만든 다음, 지정한 관리자 계정으로 설정을 완료합니다. Mac에서 업로드되는 것은 없으며, 해당 경로에 이미 설치본이 있으면 덮어쓰지 않고 거부합니다. 새 폴더를 서비스하려면 여전히 가상 호스트가 필요합니다. 로컬 사이트라면 사이트 패널에서, 원격이라면 서버 자체의 웹 서버에서 만드십시오. CMS 설치는 그 수명의 첫날일 뿐이며, 이후의 일도 같은 패널이 맡습니다. 호스트(This Mac 또는 플릿 서버)를 선택하고 일반적인 웹 루트 아래에서 wp-config.php를 검색하면, 그 머신의 모든 WordPress 설치본이 코어, 플러그인, 테마 버전 및 대기 중인 업데이트와 함께 표시됩니다. Update all은 무엇이든 건드리기 전에 데이터베이스를 내보냅니다. 잘못된 플러그인 업데이트는 복구할 수 있지만 잃어버린 데이터베이스는 복구할 수 없기 때문입니다. Check integrity는 코어 파일을 WordPress.org가 게시하는 체크섬과 비교하므로, 변조되었거나 백도어가 심어진 설치본을 찾는 가장 빠른 방법입니다. 무료 WPScan 토큰을 추가하면 설치된 플러그인과 코어를 취약점 데이터베이스와 대조하여, 수정 사항이 게시되지 않은 항목을 표시합니다. 멀티사이트 네트워크는 하위 사이트를 나열합니다. 각 사이트에는 Add a plugin 목록도 있습니다. 예약, 커머스, 메일 전송, 백업, 캐싱, 보안을 다루는 엄선된 카탈로그로, 로컬이든 원격이든 해당 사이트에 바로 설치되며 설치 후 활성화하는 옵션도 있습니다. 이 목록은 의도적으로 WordPress.org 디렉터리를 그대로 옮겨 오지 않았습니다. 모든 항목은 고장 나면 눈에 띄게 실패하거나, FrontierStack이 이미 다른 곳에서 모니터링하는 결과물을 만들어 내며, 각 항목에는 실행 후 앱이 무엇을 알려 줄 수 있는지가 적혀 있습니다. 따라서 설치했다고 해서 존재하지 않는 모니터링이 있는 것처럼 보이는 일은 없습니다. 사이트에 이미 있는 항목은 두 번 제안되지 않고 설치됨으로 표시되며, WordPress.org 슬러그가 없는 프리미엄 플러그인은 대신 자체 페이지로 연결됩니다. 아직 WordPress 사이트가 없거나 WP-CLI가 없는 호스트에서도 카탈로그는 회색으로 비활성화되어 선택할 수 없는 상태로 표시되므로, 빈 패널 대신 어떤 항목이 제공될지 미리 볼 수 있습니다. 나머지 작업은 원래라면 SSH 세션과 가물가물한 명령이 필요한 일들입니다. 잠긴 관리자 계정의 암호 재설정, 사이트를 다른 도메인으로 옮기는 search-replace(WP-CLI는 직렬화된 PHP 안에 묻힌 URL까지 다시 쓰지만, 단순 SQL 치환은 이를 손상시킵니다. 따라서 항상 먼저 시험 실행하십시오), 스테이징으로 사이트 복제, 데이터베이스 내보내기 및 최적화가 그것입니다. 복제는 파일을 복사하고, 복사본에 별도의 데이터베이스를 주고, 그 안의 URL을 다시 쓰고, 검색 엔진의 색인을 막도록 설정하므로, 스테이징이 프로덕션에 쓰거나 검색 순위에서 프로덕션을 앞지르는 일은 결코 없습니다. 모든 작업은 SSH를 통해 WP-CLI로 실행되며, WP-CLI가 없는 호스트에는 패널이 설치를 제안합니다. 사이트를 고정하면 대기 중인 업데이트, 무결성 점검 실패, 새 취약점을 알림으로 알려 줍니다.

WordPress가 자체 머신이 아닌 관리형 호스팅에 있다면, 호스팅 패널에서도 이제 해당 사이트를 나열합니다. WP Engine, Kinsta, Cloudways, Pressable은 각각 API를 통해 설치본(환경, 기본 도메인, 상태)을 가져오며, 이는 VPS 인스턴스와 함께 Cloud Servers로 집계되므로 하나의 인벤토리로 운영 중인 모든 것을 파악할 수 있습니다. 이들은 머신이 아니라 사이트이므로 전원 제어는 없습니다.

Apps & CMS 섹션은 그 밖의 자체 호스팅 CMS를 Apache/PHP/MySQL 스택에 한 번의 흐름으로 설치하며, 각 CMS에는 전용 패널이 있습니다: Drupal, Joomla, Statamic, Grav, Kirby, Craft CMS, FreshRSS. 설치 프로그램은 앱을 다운로드하고(Composer 기반인 Statamic과 Craft는 composer create-project를 실행), 문서 루트에 압축을 풀고, 데이터베이스가 필요한 앱(Drupal, Joomla, Craft)의 경우 데이터베이스와 사용자를 만들고 앱이 기대하는 위치에 설정을 작성합니다. 플랫 파일 CMS(Grav, Kirby, Statamic)는 데이터베이스가 전혀 필요하지 않습니다. 그런 다음 계정을 만들 수 있도록 앱의 설정 페이지나 관리 페이지(/admin, /panel, /cp, /admin/install…)를 열고, 그동안 FrontierStack이 가상 호스트, PHP, 신뢰할 수 있는 HTTPS를 구성합니다. 설치 폴더로는 Apache가 이미 관리하는 사이트를 선택하거나(메뉴에서 도메인, 문서 루트, 포트가 미리 채워집니다), Choose…로 비어 있는 새 폴더를 선택할 수 있습니다. 새 폴더에는 대응하는 Apache 가상 호스트가 생성되고, 도메인이 기존 사이트라면 업데이트됩니다. 설치가 제대로 동작하지 않으면 위에서 설명한 Fix My Site (AI)로 디버깅하십시오.

FreshRSS는 작업을 끝까지 마무리하는 예외입니다. FreshRSS는 자체 호스팅 RSS 및 Atom 리더로, 위의 CMS와 달리 설정 마법사가 전혀 남지 않습니다. 패널에서 계정 이름과 암호를 지정하면 설치 프로그램이 릴리스를 다운로드하고, 데이터베이스를 만들고, FreshRSS 자체의 명령줄 설치 프로그램을 실행하여 설정을 작성하고 스키마를 구축한 다음, 그 계정을 만들고, p/를 가리키는 가상 호스트를 등록합니다. 이 폴더는 FreshRSS가 실제로 서비스하는 하위 폴더이며, 나머지 코드는 원래 있어야 할 웹 루트 바깥에 남겨 둡니다. 그러면 브라우저는 설치의 첫 단계가 아니라 동작하는 리더의 로그인 화면에서 열립니다. API가 Google Reader와 호환되므로, 외부에 공개하면 Reeder나 NetNewsWire 같은 모바일 클라이언트가 동기화할 수 있습니다. 이 때문에 이 책의 다른 곳에서 다루는 HTTPS 및 원격 접근 작업과 자연스럽게 짝을 이룹니다.

7.7도메인 등록 기관 모니터

사이트 패널은 도메인이 오늘 동작하는지를 알려 주고, Domain Registrars 패널(DNS 카테고리)은 앞으로도 계속 동작할지를 알려 줍니다. 도메인을 추가하면 FrontierStack이 세 가지를 일정에 따라 감시하고, 그중 하나라도 어긋나면 알림을 발생시킵니다.

• 만료 — 등록 종료일, 등록 기관, 네임서버를 RDAP로 가져옵니다(whois로 대체 가능). 등록 기관에 관계없이 모든 도메인에서 동작합니다.
• DNS — 도메인이 여전히 해석되는지 확인합니다(dig).
• SSL — 인증서 만료일을 openssl로 직접 확인합니다.

만료일이 알림 기간 안에 들어오거나, 이미 지났거나, 자동 갱신이 꺼져 있으면 갱신 경고가 발생합니다. 지원되는 등록 기관에서는 패널이 API로 도메인 목록과 자동 갱신 상태를 가져올 수 있습니다. GoDaddy, Porkbun, Gandi, Value Domain, Route 53(AWS CLI 사용), Cloudflare(Cloudflare 토큰 재사용. Cloudflare Registrar는 계정 소유 cfat_ 토큰을 받지 않으므로 사용자 API 토큰이 필요합니다)가 해당합니다. 쓸 만한 목록 API가 없는 등록 기관(Namecheap, Squarespace, Onamae, Muumuu Domain)은 직접 추가하십시오. 이 경우에도 RDAP로 계속 모니터링합니다.

7.13.1도메인 업체: 등록 기관 가동 상태

Cloudflare 영역만으로는 등록을 누가 보유하고 있는지 알 수 없습니다. FrontierStack은 고정된 각 영역을 RDAP로 조회하여 등록 기관과 실제 네임서버를 영역 패널의 Domain Company 섹션에 표시합니다. Cloudflare 패널에서 각 영역의 줄은 예를 들어 active · Pro · registered at GoDaddy처럼 표시됩니다. 도메인 뒤에 있는 모든 등록 기관과 DNS 호스트(GoDaddy, Namecheap, Porkbun, Gandi, Squarespace, DNSimple, Route 53, Value Domain, Onamae, Name.com, Hover, Dynadot, IONOS, OVHcloud, Sakura, 그리고 Cloudflare 자체)를 5분마다 세 가지 신호로 점검합니다.

• 공식 상태 — 업체의 상태 페이지(Statuspage 또는 Instatus JSON, AWS Route 53은 RSS). 페이지에 나열되어 있다면 도메인, DNS, 이메일, 호스팅, SSL, 웹사이트 빌더 등 각 서비스도 포함합니다.
• 도달 가능성 — 웹사이트와 API 호스트가 응답하는지.
• 네임서버 — 여전히 해당 업체에 위임된 도메인에 대해 네임서버가 응답하는지.

사이드바에서 영역 옆에 노란색 건물 아이콘이 있으면 등록 기관이나 DNS 호스트의 성능이 저하되었다는 뜻이고, 빨간색이면 중단되었다는 뜻입니다. 업체를 고정하면(영역 패널, 영역의 컨텍스트 메뉴 또는 Domain Registrars의 Domain Companies 목록에서) 전용 사이드바 행이 생기며, 중단 시 점이 깜박입니다. 업체가 중단되면 Domain company 알림이 발생합니다. 상태 페이지가 없는 업체는 도달 가능성만으로 판단하며, 이 Mac이 어느 업체에도 도달할 수 없으면 거짓 장애 대신 offline으로 보고합니다.

7.13.2도메인을 Cloudflare로 옮기기

Cloudflare 토큰이 설정되어 있으면, 등록 기관에 API가 있는 경우 두 가지 이전을 클릭 한 번으로 할 수 있습니다.

• DNS만 — 아직 Cloudflare에 없는 도메인은 Domain Registrars의 Add to Cloudflare DNS…로 영역을 만들고, 현재 공개 레코드를 복사해 넣고, 고정합니다. 레코드를 검토한 다음 영역의 Domain Company 섹션에서 Switch Nameservers를 사용하십시오. FrontierStack이 GoDaddy, Porkbun, Gandi, DNSimple 또는 Route 53에 Cloudflare의 네임서버 두 개를 설정하고, Cloudflare에 활성화를 다시 확인하도록 요청합니다. 다른 등록 기관의 경우 복사할 네임서버 두 개를 보여 줍니다.
• 등록 자체 — Transfer to Cloudflare…는 도메인의 현재 상태를 읽는 체크리스트를 엽니다. Cloudflare에서 DNS 활성화, 60일 잠금 기간 경과, 이전 잠금 해제(GoDaddy, DNSimple, Route 53은 Unlock 사용), 인증 코드(Route 53이나 Gandi에서 가져오거나 DNSimple이 이메일로 발송)를 확인합니다. 마지막 단계에서는 Cloudflare의 이전 페이지가 열리며, 그곳에서 확인하고 1년 갱신 비용을 결제합니다. Cloudflare에는 이전을 시작하는 API가 없습니다.

7.8Cloudflare: 영역, DNS, 캐시, 터널, 보호

Cloudflare 패널에서는 API 토큰을 붙여넣고 사이드바에 표시할 영역을 선택합니다. Pin to sidebar로 고정한 각 영역은 별도의 패널이 되며, 그 영역의 Cloudflare/DNS/HTTP/SSL 상태, DDoS 및 봇 보호, WAF 규칙, Workers, CDN 분석, 개발 모드, 캐시 삭제(전체, URL 목록 또는 접두사 기준)를 제공합니다. 토큰의 범위는 신중하게 정하십시오. 읽기 전용 토큰으로 영역을 나열할 수는 있지만, DNS 편집, 인증서 DNS-01 검증, Dev Mode, 캐시 삭제, 영역 생성에는 각각 별도의 권한이 필요하며, 완전히 새로운 영역을 만들려면 계정 수준의 Zone · Zone · Edit 권한이 필요합니다. Create Token… 버튼은 앱이 사용하는 모든 권한이 미리 채워진 Cloudflare 토큰 양식을 엽니다(선택 사항인 계정 수준 영역 생성 행만 직접 추가해야 합니다). Test Token 버튼은 실제 API를 점검하여 토큰에 이러한 기능 중 무엇이 있고 무엇이 없는지 정확히 나열합니다(읽기는 직접 실행하고, 쓰기는 일부러 잘못된 요청으로 점검하므로 아무것도 변경되지 않습니다). Dashboard 버튼은 현재 영역의 Cloudflare 웹 콘솔로 바로 연결합니다.

고정된 영역에 경고가 표시되거나 HTTP 점검이 응답을 멈추면, 패널의 Diagnose 버튼이 색깔 점만 남기는 대신 원인을 찾아냅니다. 서비스 경로의 각 계층을 순서대로 점검합니다. Cloudflare에서의 영역 상태, 공개 네임서버, DNS 해석, 엣지를 통한 HTTPS(Cloudflare의 52x 오류 해석: 521 오리진 중단, 522 시간 초과, 524 앱이나 데이터베이스 멈춤, 525/526 오리진 TLS), 오리진 서버의 80번 및 443번 포트 직접 점검, 그리고 마지막으로 FrontierStack이 알고 있는 해당 도메인의 서비스 머신입니다. 그 머신이 이 Mac이면 로컬 웹 서버를, 연결된 서버라면 호스트 내 모니터의 서비스 상태를 확인합니다(중지된 mysql이 보고서에 바로 드러납니다). 공개 경로가 망가졌을 때는 플릿 전체도 살펴봅니다. 어떤 연결된 서버가 동작 중인지, 어떤 서버가 오리진 IP를 바인딩하고 있는지, 어떤 서버가 이미 이 도메인의 가상 호스트를 서비스하는지 확인하므로, 오프라인이 되면서 사이트의 정문 IP까지 함께 가져간 호스트를 이를 대신할 수 있는 서버와 함께 바로 지목합니다. 각 계층은 통과/실패로 표시되며, 마지막에는 어느 계층이 망가졌고 어떻게 해야 하는지를 쉬운 말로 정리한 결론이 나옵니다.

Cloudflare는 앱 곳곳에 등장합니다. AI의 dns_record 도구는 관리하는 영역에 레코드를 쓰고 기존 레코드를 그 자리에서 업데이트하며, 하위 도메인을 proxied(주황색 구름)와 DNS-only 사이에서 전환하는 일도 포함합니다. issue_certificate는 Cloudflare DNS-01로 검증할 수 있고, email_auth_dns는 SPF/DMARC를 대신 게시할 수 있습니다(13장 참조). 같은 계정은 로컬 사이트를 공개하기 위한 Cloudflare DDNS와 Cloudflare Tunnel에도 사용되며, 둘 다 9장에서 다룹니다.

7.13.3사이트가 공격받을 때: Under Attack 모드

고정된 모든 영역의 패널 맨 위에는 공격받는 중 버튼이 있습니다. 이 버튼은 영역을 Cloudflare의 Under Attack 모드(보안 수준 under_attack)로 전환합니다. 모든 방문자는 오리진에 도달하기 전에 몇 초간 브라우저 검사를 받게 되며, 이것으로 대부분의 요청 폭주를 막을 수 있습니다. 켜기 전에 확인을 거치는데, 켜져 있는 동안에는 JavaScript를 실행할 수 없는 모든 것 — API 클라이언트, 웹훅, 모바일 앱, 가동 시간 모니터 — 도 함께 차단되기 때문입니다. 같은 명령이 사이드바에서 영역을 오른쪽 클릭했을 때의 메뉴(공격받는 중…)와 Cloudflare Zones 미니 팔레트에도 있으므로, 패널을 찾아다니지 않고도 바로 실행할 수 있습니다. 이 모드인 영역은 사이드바에 빨간 방패, 팔레트에 ATTACK 배지로 표시됩니다. 해제를 누르면 확인 없이 모드가 꺼지고, 영역의 이전 보안 수준이 복원됩니다(FrontierStack 밖에서 모드를 켠 경우에는 medium). 토큰에는 Zone · Zone Settings · Edit 권한이 필요합니다. AI 관리자도 cloudflare_dev_mode action=under_attack으로 같은 작업을 할 수 있습니다.

7.13.4Email Routing과 Email Service

영역 패널의 이메일 섹션에는 Email Routing이 켜져 있고 준비되었는지, 라우팅 규칙과 catch-all, 아직 확인되지 않은 대상 주소(확인될 때까지 그 주소로 전달된 메일은 버려집니다), 실패 항목을 강조한 최근 7일간의 Email Service 이벤트, 영역의 MX 대상이 표시됩니다. 메일 호스트 이름이 주황색 구름(프록시) 상태이면 경고도 표시합니다. Cloudflare 프록시는 웹 트래픽만 전달하므로 프록시된 호스트로의 SMTP와 IMAP은 실패합니다 — DNS 전용으로 설정하십시오. 이메일 전송 모니터에도 이에 대응하는 Cloudflare Email Service 섹션이 있으며, 같은 토큰으로 읽은 모든 고정된 영역을 나열합니다. 토큰에는 Zone · Email Routing Rules · Read 권한(대상 주소를 보려면 Account · Email Routing Addresses · Read도)이 필요합니다. AI는 cloudflare_dev_mode action=email_status로 같은 정보를 읽습니다.

7.13.5Core Web Vitals

영역 패널의 Core Web Vitals 섹션은 Cloudflare의 무료 Web Analytics를 바탕으로, 봇을 제외한 실제 방문자가 최근 7일간 경험한 내용을 보고합니다:

각 값은 75번째 백분위수이며, “양호”였던 페이지 로드의 비율과 녹색·주황색·빨간색 등급이 함께 표시됩니다. 사이트에서 Web Analytics가 켜져 있어야 하며, 토큰에는 Account · Account Analytics · Read 권한이 필요합니다 — 이제 토큰 생성… 버튼에 미리 채워져 있습니다. AI: cloudflare_dev_mode action=web_vitals.

7.13.6속도 제한 및 WAF 규칙

영역 패널의 규칙 섹션은 영역의 속도 제한 규칙과 사용자 정의 WAF 규칙을 나열하며, 각 규칙의 동작, 한도(예: “차단, IP당 10초에 20회 초과 요청”), 표현식을 보여 줍니다. 스위치로 규칙을 끄고 켭니다. 편집으로 이름, 표현식, 동작, 한도를 변경합니다. … 메뉴에는 이전 버전으로 되돌리기 — FrontierStack은 마지막 편집 이전 버전을 보관합니다 — 와 앱에서 되돌릴 수 없는 규칙 삭제가 있습니다. 변경 사항은 적용하는 즉시 Cloudflare에 반영되며, Cloudflare가 구문을 분석할 수 없는 표현식은 아무것도 변경하지 않고 거부합니다.

주황색 경고에 주의하십시오. 호스트 이름 조건이 없는 규칙은 웹사이트뿐 아니라 영역의 모든 호스트 이름에 적용됩니다. /djs/ 같은 URL 경로에 일치하는 규칙은 경로에 같은 세그먼트가 들어 있는 미디어나 이미지 호스트에도 일치하므로, 한 페이지를 불러오던 방문자가 이미지를 받는 도중 오류 1015(HTTP 429)로 차단될 수 있습니다 — 속도 제한은 캐시보다 먼저 실행되므로 캐시된 이미지도 소용이 없습니다. 편집기에는 표현식을 (http.host ne "host") and (…)로 감싸는 원클릭 <host> 제외 버튼이 있습니다.

새 규칙…은 속도 제한, 사용자 정의 WAF 규칙, 캐시 규칙(정해진 시간 동안 캐시하거나 캐시를 우회), 리디렉션을 만듭니다. 경로만 받는 대신 호스트 이름(경로 접두사는 선택 사항)을 묻기 때문에, 새 규칙이 모르는 사이에 모든 호스트를 덮는 일이 없습니다. 직접 작성한 표현식에도 같은 경고가 표시됩니다. 관리형 WAF, URL 재작성, 요청/응답 헤더 규칙은 영역에 있으면 목록에 표시됩니다. 이 규칙들은 켜고 끄기, 이름 변경, 삭제가 가능하지만 매개변수(캐시 TTL, 리디렉션 대상, 헤더)는 편집할 수 없고 표시만 됩니다 — 변경하려면 규칙을 다시 만드십시오.

규칙 종류마다 별도의 토큰 권한 — Zone WAF, Cache Rules, Single Redirect, Transform Rules — 이 필요하며, 보려면 Read, 변경하려면 Edit 권한이 있어야 합니다. 빠진 권한은 패널에 표시됩니다. Cloudflare에서 규칙 보기는 대시보드를 엽니다. AI: cloudflare_dev_mode action=rules는 규칙을 나열하고, action=rule_create는 규칙을 추가하며, action=rule_update는 규칙을 변경합니다(각각 변경 허용과 사용자의 확인이 필요합니다). AI는 규칙을 비활성화할 수는 있지만 삭제할 수는 없습니다.

7.13.7보안 이벤트와 Bot Fight Mode

영역 패널의 보안 이벤트 섹션은 최근 24시간 동안 Cloudflare가 영역에서 차단하거나 챌린지하거나 기록한 내용을 출처(속도 제한, 사용자 정의 규칙, 관리형 규칙, DDoS, 브라우저 무결성 검사…), 규칙, 호스트 이름별로 묶어 보여 줍니다. 사용자 정의 규칙과 속도 제한 규칙의 ID는 이름으로 표시됩니다. 주황색 삼각형은 주 사이트가 아닌 호스트 이름에서 방문자가 차단되었다는 뜻입니다 — 대개 페이지용으로 만든 규칙에 미디어나 이미지 호스트가 걸린 경우입니다. 이미지가 사라지거나 방문자가 오류 1015 또는 429를 보고하면 여기서부터 확인한 다음 규칙에서 해당 규칙을 수정하십시오.

목록 아래의 Bot Fight Mode는 Cloudflare의 무료 봇 챌린지를 표시하고 전환합니다. 켜기 전에 확인을 거칩니다: 정상적인 봇, 피드, 웹훅, 모니터까지 차단할 수 있으며, 무료 플랜에서는 규칙으로 이들을 예외 처리할 수 없기 때문입니다. Zone · Analytics · Read 권한이 필요합니다. AI: action=security_events 및 action=bot_fight.

7.13.8호스트 이름별 캐시

영역 패널의 호스트 이름별 캐시 섹션은 최근 24시간 동안 각 호스트 이름의 요청 수와 캐시 가능한 요청 중 Cloudflare 캐시에서 제공된 비율(HTML과 API 응답은 제외)을 보여 주며, 캐시에서 제공되지 않은 상위 파일도 함께 표시합니다. 영역 전체 적중률로는 전혀 캐시되지 않는 이미지 호스트가 가려지지만, 이 섹션에서는 드러납니다. 100%에 크게 못 미치는 호스트는 대개 캐시 규칙이 없거나, 오리진이 Set-Cookie 또는 Cache-Control: no-store를 보내거나, 요청이 캐시에 도달하기 전에 규칙이 차단하고 있는 경우입니다. AI: action=cache_hosts.

7.13.9Workers

계정 패널의 Workers 섹션은 모든 Worker를 그 Worker를 가리키는 라우트, 최근 하루의 요청 수, 오류 수, 99번째 백분위수 CPU 시간과 함께 나열하고, 플랜에 공시된 허용량 — Workers Paid는 월 1,000만 요청, Free는 하루 100,000 요청 — 대비 사용량을 막대로 보여 줍니다. 막대는 70%에서 주황색, 90%에서 빨간색으로 바뀝니다. Account · Workers Scripts · Read, Workers Routes · Read, Account Analytics · Read 권한이 필요하며, 모두 토큰 생성…에 미리 채워져 있습니다. AI: action=workers.

7.13.10플랜 및 알림

계정 패널의 플랜 및 알림 섹션은 계정의 구독(플랜, 가격, 상태, 갱신일)과 알림 정책을 나열하며, 알림 정책이 하나도 없으면 경고합니다 — 그런 경우 장애, 만료가 다가오는 인증서, Workers 사용량을 알려 줄 수단이 없기 때문입니다. 이 섹션은 읽기 전용이며, 청구와 알림은 대시보드를 엽니다. Account · Billing · Read(미리 채워짐)와 Account · Notifications · Read 권한이 필요하며, 후자는 토큰 템플릿 단축 방법이 없어 직접 추가해야 합니다. AI: action=plan_usage.

7.13.11Turnstile 위젯

Turnstile은 가입, 로그인, 문의 양식을 위한 Cloudflare의 무료 CAPTCHA 대체 서비스입니다. Cloudflare 패널의 Turnstile 섹션은 위젯을 나열하며, 각 위젯에 사이트 키 복사 버튼이 있습니다. 새 위젯…은 이름, 최대 10개의 호스트 이름, 모드(Managed(권장), Non-interactive, Invisible)를 묻습니다. 위젯의 비밀 값은 한 번만 표시됩니다: 복사하거나 스크립트 비밀 값에 저장을 눌러 스크립트에서 쓸 수 있도록 $TURNSTILE_SECRET_<NAME>으로 저장하십시오. 사이트 키는 페이지에 넣고, 비밀 값은 서버에 둡니다. 서버는 Cloudflare의 siteverify 엔드포인트로 각 방문자의 토큰을 확인합니다. 위젯 삭제…는 각 행의 메뉴에 있습니다.

7.13.12이름 있는 터널: 상태, 알림, Access

이름 있는 터널의 각 행(9장 참조)에는 상태 줄이 있습니다: Cloudflare가 보는 커넥터 상태 — healthy, degraded, down, inactive — 와, 이 Mac이 실행하는 터널이라면 로컬 포트가 응답하는지 여부입니다. 터널이 정상이어도 뒤의 서비스가 중지되어 있으면 결국 실패하기 때문입니다. 종 아이콘을 누르면 해당 터널이나 그 서비스가 다운될 때 알림을 받도록 설정됩니다(알림 그룹 네트워크 및 라우팅). 보호…는 호스트 이름 앞에 Cloudflare Access 로그인을 둡니다: 이메일 주소 및/또는 @domains를 나열하고 로그인 유지 기간(1시간~30일)을 선택하면, 방문자는 이메일로 받은 일회용 PIN이나 사용 중인 ID 제공업체를 통해 로그인합니다. FrontierStack은 재사용 가능한 허용 정책과 자체 호스팅 Access 애플리케이션을 만듭니다. 보호된 터널에는 파란 자물쇠가 표시되며, Access 제거로 보호를 해제합니다. Access를 쓰려면 계정에서 Zero Trust를 한 번 설정해야 하며(무료 플랜으로 사용자 50명까지), Account · Access: Apps and Policies · Edit 권한이 필요합니다.

7.13.13Cloudflare MCP를 통한 AI 접근

AI 접근(Cloudflare MCP) 섹션을 사용하면 AI 관리자가 이미 저장한 토큰으로 mcp.cloudflare.com의 Cloudflare 공식 MCP 서버를 이용할 수 있습니다 — FrontierStack에 패널이 없는 제품(WAF 규칙, Workers, R2, KV, D1, Access)에 유용합니다. AI 관리자가 Cloudflare MCP 사용을 켜고 연결 테스트를 누르십시오. 기본 상태에서는 읽기 전용이어서, AI는 Cloudflare 문서와 전체 API 사양을 검색할 수 있습니다. 기본적으로 꺼져 있는 API 호출 허용(execute)을 켜면 AI가 실제 API에 대해 JavaScript를 실행할 수 있으며, 매 실행에 변경 허용과 사용자의 승인이 필요합니다. FrontierStack에 연결된 MCP 클라이언트는 hosted_mcp 도구에 provider=cloudflare를 지정해 같은 서버에 접근합니다(13장의 도구 표 참조). 다른 MCP 클라이언트 ▸ 구성 복사는 Claude, Cursor 등의 앱을 위한 토큰 없는 항목을 제공하며, 이런 앱은 OAuth로 직접 Cloudflare에 로그인합니다.

7.13.14Cloudflare 개발자 도구

Cloudflare 패널의 개발자 도구 섹션은 Cloudflare의 에이전트 설정 가이드에 따라 Cloudflare 자체 도구를 설치합니다. 설치는 앱 내 콘솔에서 npm으로 Cloudflare CLI(cf, 베타)를 추가하며, 필요하면 먼저 Homebrew로 Node를 추가합니다. 로그인…은 cf auth login을 실행하고 브라우저를 열어 계정을 승인하게 합니다(저장된 API 토큰은 사용하지 않습니다). Claude Code 플러그인 행은 cloudflare/skills 마켓플레이스를 추가하고 cloudflare 플러그인을 설치합니다. 이 플러그인에는 Cloudflare의 스킬과 함께 API, 문서, 바인딩, 빌드, 관측성 MCP 서버가 들어 있습니다. 서드파티 플러그인 코드를 설치하는 것이므로, 설치 후 Claude Code에서 /reload-plugins를 실행하십시오. 이 Mac에 Claude Code가 있어야 합니다.

7.9호스팅 제공업체

운영하는 모든 것이 Mac에 있는 것은 아닙니다. 호스팅 카테고리는 VPS와 관리형 제공업체를 같은 윈도우로 가져옵니다. VPS 제공업체 — DigitalOcean, Vultr, Linode, Hetzner, Sakura 등 — 는 API 토큰으로 서버를 제공합니다: 토큰을 붙여 넣으면 패널이 각 서버를 플랜, 위치, 상태, IP와 함께 나열하고, 확인을 거쳐 서버를 켜고 끄거나 재시작할 수 있게 합니다. 대시보드형 제공업체는 토큰을 저장하고 제어판, 문서, 가입 페이지로 가는 빠른 링크를 표시합니다. Hostinger는 한층 더 나아갑니다: hPanel ▸ Account ▸ API에서 발급한 API 토큰으로 패널이 VPS를 나열하고 전원을 제어하며, VPS 스냅숏을 만들고(Hostinger는 VPS당 하나만 보관하므로 새 스냅숏이 기존 것을 대체합니다), 만료일이 포함된 보유 도메인 목록과 호스팅 웹사이트를 보여 줍니다. 또한 AI 관리자가 dns_record(provider=hostinger)로 DNS 레코드를 읽고 설정할 수 있습니다. AI 접근(Hostinger MCP) 섹션은 같은 토큰으로 AI를 Hostinger 공식 MCP 서버에 연결합니다 — 쓰기 허용을 켜기 전까지는 읽기 도구만 사용할 수 있습니다. 어느 경우든 자격 증명은 키체인에 보관되며, SSH로 접근할 수 있는 서버는 플릿의 일부가 됩니다(8장). ConoHa는 컨트롤 패널 API 페이지의 세 값(API 사용자, 그 암호, 테넌트 ID)으로 로그인하여 VPS 3.0(또는 이전 2.0) 서버를 나열하고 전원을 제어하며, ConoHa DNS 영역을 다루는 DNS 섹션을 추가합니다. 레코드는 여기서 추가, 편집, 삭제하거나 AI가 dns_record(provider=conoha)로 처리하게 할 수 있습니다. ConoHa DNS는 ConoHa 고객에게 무료이며, 자체 DNS API가 없는 Onamae.com에 등록한 도메인을 API로 관리하는 일반적인 위치입니다.

7.10IndexNow: 검색 엔진에 즉시 제출

페이지가 바뀌었을 때 크롤러가 알아차리기를 기다릴 필요가 없습니다. IndexNow Manager(SEO 및 마케팅)는 참여 검색 엔진 — Bing, Yandex, Seznam, Naver 등 — 에 즉시 알립니다. 관리 중인 사이트 하나를 고르고 키 파일 설치를 누르면, FrontierStack이 사이트의 문서 루트에 <key>.txt 파일을 기록하여 검색 엔진이 키 소유를 확인할 수 있게 합니다. 확인은 파일이 제공되고 있는지 검사합니다. 그런 다음 URL 하나를 제출하거나, 대기 중 대기열을 한꺼번에 보내거나, 사이트맵에서 URL을 공급할 수 있으며, 일정에 따라 자동 제출할 수도 있습니다. 모든 제출은 api.indexnow.org로 전송되고, 여기서 모든 참여 검색 엔진으로 전달됩니다. URL의 호스트는 선택한 사이트 및 그 키와 일치해야 합니다.

7.11OpenSEO와 DataForSEO: 나만의 SEO 도구 모음

OpenSEO(SEO 및 마케팅)는 Semrush와 Ahrefs를 대체하는 오픈 소스 도구로 — 키워드 조사, 순위 추적, 경쟁사 분석, 백링크, 사이트 감사, AI 가시성 — MCP 서버를 갖추고 있어 AI 에이전트도 같은 데이터를 사용할 수 있습니다. 패널은 한 가지 질문으로 시작합니다: 어디에서 실행합니까?

• 호스팅 — app.openseo.so. 무료로 사용해 볼 수 있으며, 프로젝트를 후원하려면 월 $10입니다. SEO 데이터는 OpenSEO 크레딧(DataForSEO 가격에 28% 추가)으로 청구되므로 별도의 DataForSEO 계정이 필요 없습니다.
• 이 Mac의 Docker — 설정 및 시작은 ghcr.io/every-app/open-seo를 가져와 http://localhost:3001에서 시작합니다. 프로젝트는 open_seo_data 볼륨에 저장되므로, 설정 적용 및 재시작(키나 포트를 변경한 후)과 업데이트(최신 이미지)를 해도 그대로 유지됩니다. OpenSEO의 원격 측정은 기본적으로 꺼져 있으며, OpenRouter 키를 공유하면 SAM 에이전트를 사용할 수 있습니다.
• 다른 곳에 자체 호스팅 — 기존 인스턴스의 URL을 입력하거나 Cloudflare에 배포…를 누르십시오. FrontierStack은 저장소를 복제하고, DataForSEO 키와 Cloudflare Access를 통과할 수 있는 이메일 주소를 담은 소유자 전용 .env.selfhost를 작성한 다음, 앱 내 콘솔에서 pnpm deploy:selfhost를 실행합니다. 처음 실행할 때 Cloudflare에 로그인하게 됩니다. OAuth 범위를 사용자 지정할지 묻는 질문에 yes로 답하고 access:write를 활성화하십시오. 출력된 Worker URL을 인스턴스 URL에 붙여 넣으십시오.

라이브 모니터는 인스턴스의 /api/health 엔드포인트를 읽습니다. 이 엔드포인트는 DataForSEO 키, 데이터베이스, 인증 모드, AI, Search Console에 대한 설정 검사 결과를 나열합니다. 알림 받기를 고정하면 검사가 실패할 때 알림이 발생합니다. oseo_ API 키를 붙여 넣으면 MCP 엔드포인트에 대해 확인하므로, 폐기된 키도 표시됩니다. AI 에이전트 섹션은 MCP URL, claude mcp add 명령, Claude Desktop/Cursor 구성을 복사합니다. API 키 방식은 셸에서 $OPENSEO_API_KEY를 읽으므로, FrontierStack은 키를 클립보드에 넣지 않습니다.

DataForSEO는 OpenSEO의 데이터 소스이며, 자체 라이브 모니터가 있고 OpenSEO 패널에 포함되어 있습니다. app.dataforseo.com ▸ API Access에서 확인한 API 로그인과 암호(대시보드 암호가 아닙니다)를 입력하거나, 로그인을 비워 두고 더 긴 Base64 자격 증명을 붙여 넣으십시오. 모니터에는 선불 잔액, 오늘의 지출과 API 호출 수가 표시되며, 오늘의 지출이 임계값을 넘거나 잔액이 설정한 하한 아래로 떨어지면 알림을 보낼 수 있습니다. 자체 호스팅 OpenSEO 설치도 같은 자격 증명을 사용하므로 한 번만 입력하면 됩니다.

7.12사이트 전송: 머신 간 사이트 복사

두 가지 도구를 쓰면 수동으로 rsync를 이리저리 돌리지 않고도 사이트를 옮길 수 있습니다. Apache 간 웹사이트 복사는 로컬의 경우를 처리합니다: Mac에 Apache가 둘 이상 설치되어 있을 때(예: Homebrew 버전과 오래된 Server.app 버전), 원본 설치를 선택하고 원하는 사이트에 체크하면 FrontierStack이 해당 사이트의 문서 루트와 가상 호스트 정의를 현재 선택된 Apache로 복사합니다. 같은 도메인의 사이트는 덮어쓰므로, 마이그레이션 후 다시 가져올 때도 이 방법을 씁니다.

사이트를 다른 머신으로 옮기려면, AI의 promote_site 도구가 로컬 사이트를 지정한 플릿 호스트 하나로 복제합니다: 문서 루트를 업로드하고, 원격 측에 가상 호스트(Apache 또는 Nginx)를 작성하고, 웹 서버를 다시 로드하며, 새 호스트를 가리키는 Cloudflare A 레코드를 추가할 수도 있습니다 — 수동 플릿 푸시와 같은 단계를 한 번의 호출로 처리합니다.

7.13새 웹 프로젝트 프로비저닝

위의 요소들을 결합하면, 프로젝트의 인프라를 처음부터 구축하는 하나의 흐름이 됩니다. 핵심은 명확한 역할 분담입니다: AI 도구(MCP 경유)는 코드를 담당하고, FrontierStack은 인프라를 담당합니다. 내장된 Provision Web Project 스킬은 어시스턴트가 다음 절차를 순서대로 진행하도록 안내합니다:

1. 탐색 — 대상과 그 권한 접근, 설치된 Apache/Nginx, 연결된 DNS 제공업체를 조사하고, 공개적인 변경을 하기 전에 빠진 전제 조건을 확인하거나 설치합니다.
2. 영역 — cloudflare_zone_create가 Cloudflare 영역을 만들고 등록 기관에 설정할 네임서버를 반환합니다(토큰에 계정 수준의 영역 생성 권한이 없으면 그 사실을 분명히 알려 줍니다).
3. 가상 호스트 + 폴더 — vhost_create가 Apache/Nginx 사이트를 정의합니다. 문서 루트를 지정하지 않았으면 FrontierStack이 플랫폼에 맞는 빈 폴더를 만들고 그 경로를 알려 줍니다. 사이트 콘텐츠를 디자인하거나 생성하지는 않습니다.
4. DNS — dns_record가 이름이 호스트를 가리키도록 합니다.
5. TLS — issue_certificate가 Let's Encrypt 인증서를 발급합니다.
6. 미리 보기 — localhost 테스트 지점을 위한 임시 공유(9장).
7. 승격 — 필요하면 promote_site가 플릿 호스트로 복제합니다.

도메인 등록도 domain_register를 통해 이 절차의 맨 앞에 추가할 수 있으므로, 원칙적으로 에이전트가 이름을 구입하고, 영역을 만들고, 가상 호스트를 세우고, 인증서를 발급하고, 플릿으로 복제하는 데까지 모두 할 수 있습니다 — 비용이 들거나 시스템을 변경하는 모든 단계는 먼저 미리 보기로 표시되어 사용자의 승인을 받습니다.