Apple이 macOS Server.app을 단종하면서 Mac 사용자는 웹 사이트와 서비스를 클릭만으로 간단히 운영하던 방법을 잃었습니다. FrontierStack은 그 방법을 되살리고 훨씬 더 나아갑니다. Apache, PHP, MySQL, PostgreSQL, Nginx를 비롯한 천 개가 넘는 서비스를 눈앞의 Mac과 연결한 모든 서버에서 설치, 제어, 보안, 모니터링하며, 도구를 사용하는 AI 관리자에게 운영을 맡길 수 있습니다.

이 매뉴얼은 데스크톱 앱의 완전한 참조 문서입니다. iPhone 및 iPad 앱은 별도의 모바일 매뉴얼에서 다룹니다. 이 첫 장은 처음부터 끝까지 읽고, 그 후에는 필요한 부분을 골라 읽으십시오.

1.1FrontierStack이란

FrontierStack은 네이티브 macOS 애플리케이션입니다. 웹 패널도 아니고, 계속 돌봐야 하는 컨테이너도 아닙니다. Homebrew 포뮬러, launchd 및 systemd 유닛, Apache 및 Nginx 구성, 인증서, 방화벽, SSH 등 각 시스템에 이미 갖춰진 도구를 사용해 실제 머신의 실제 서비스를 관리합니다. FrontierStack은 다음 세 가지를 동시에 제공합니다.

• 제어판. 검증, 실시간 상태, 원클릭 수정 기능과 함께 서비스를 설치, 시작, 중지, 구성합니다. 현대화된 macOS Server 대체품입니다.
• 모니터링 및 알림 시스템. 지속적인 상태 점검이 서비스, 사이트, 인증서, 디스크, 플릿 전체를 감시하고, 문제의 첫 징후를 선택한 채널로 메시지를 보내 알립니다.
• AI 관리자. 안전장치를 갖추고 도구를 사용하는 어시스턴트로, 사용자의 환경을 실시간으로 정확하게 파악합니다. 무엇이 고장 났는지 진단하고, 승인할 수정안을 제안하고, 로컬 또는 플릿 전체에서 실행하며, 실제로 운영하는 서비스에 맞춰 앱을 재구성할 수 있습니다.

스크린샷 추가 예정

1.2AI 우선 설계

대부분의 앱은 채팅 창을 옆에 덧붙이는 데 그칩니다. FrontierStack은 반대로 만들어졌습니다. AI는 사용자가 쓰는 것과 같은 제어 기능을 다루는 일급 운영자입니다. AI는 로그 읽기, 진단 실행, 서비스 재시작, 인증서 발급, 파일 쓰기 등 감사되는 고정된 도구 세트를 통해서만 동작하므로, AI가 하는 모든 일은 사용자가 직접 할 수 있는 일이며, 시스템을 변경하는 모든 작업은 먼저 사용자에게 보여 주고 승인을 받습니다.

다음 세 가지 원칙 덕분에 운영 서버를 맡길 만큼 안전합니다.

• 기본적으로 읽기 전용. 처음 상태의 어시스턴트는 볼 수만 있고 손댈 수는 없습니다. 변경과 스크립트는 명시적인 토글로만 허용되며, 변경을 가하는 모든 작업은 실행 전에 승인 카드를 표시합니다.
• 비밀 값은 모델에 절대 전달되지 않습니다. 암호와 API 토큰은 로컬 .env 보관함에 저장됩니다. 스크립트는 이름으로 참조하고, 앱이 실행 시점에 로컬 또는 SSH를 통해 실제 값을 주입합니다. 클라우드 모델은 이름만 볼 뿐 값은 결코 보지 못합니다. 로그와 파일은 전송 전에 비밀 값이 가려집니다.
• AI는 직접 선택합니다. 클라우드 모델이나 로컬 모델(Ollama, LM Studio)을 지정할 수 있습니다. Claude Code나 Cursor처럼 이미 구독 중인 도구에서 MCP로 조작하면 토큰당 종량 요금이 전혀 발생하지 않습니다.

1.3대상 사용자

FrontierStack은 Mac에서 서버를 운영하는, 또는 운영하려는 모든 사람에게 적합합니다.

• MAMP나 XAMPP 대신 깔끔한 로컬 스택을 원하는 개발자.
• Mac mini에서 POS, CRM, 전자상거래, 메일, 헬프데스크를 자체 호스팅하는 소규모 기업.
• macOS Server를 실행하는 오래된 Xserve나 Mac mini를 원격으로 관리하며 계속 활용하려는 관리자.
• 종량제 SaaS에서 자체 호스팅으로 옮기려는 사람, 또는 Mac, Linux 머신, BSD 서버, Raspberry Pi로 이루어진 플릿을 하나의 윈도우에서 운영하려는 사람.

1.4핵심 개념과 용어

이 매뉴얼 전체에서 반복되는 용어가 몇 가지 있습니다. 여기서 한 번 정리해 둡니다.

용어	의미
서비스	FrontierStack이 설치, 실행, 모니터링할 수 있는 모든 것입니다. Apache, 데이터베이스, 메일 서버, 컨테이너, 라우터 연동 등이 해당합니다. 전체 목록이 카탈로그입니다(6장).
패널	사이드바에서 열 수 있는, 서비스나 도구 하나를 위한 앱의 화면입니다.
헬퍼	매번 암호를 묻지 않고 관리자 작업을 수행하는 작은 권한 있는 도구(SMAppService 데몬)입니다. 선택 사항이며, 처음 실행할 때 설치합니다.
위치	Mac이 현재 네트워크상 어디에 있는지(집, 사무실, 외부)를 나타냅니다. 위치를 사용하면 알림과 연결 가능성 판단이 네트워크를 인식하게 됩니다(8장).
연결된 서버	FrontierStack이 진단과 스크립트를 실행할 수 있도록 SSH로 연결한 다른 머신입니다. 이들 전체가 플릿입니다.
AI 관리자	도구를 사용하는 내장 어시스턴트입니다. AI 하네스라고도 합니다. 13장에서 자세히 다룹니다.
MCP	Model Context Protocol. 외부 AI 도구(Claude Code, Cursor)가 같은 안전장치가 적용된 도구를 통해 FrontierStack을 조작할 수 있게 해 주는 개방형 인터페이스입니다(14장).
비밀 값 / 보관함	로컬 .env 저장소에 이름을 붙여 저장한 자격 증명입니다. 스크립트는 $NAME으로 참조하며, 값은 Mac에 남습니다.

1.5이 매뉴얼의 구성

이 매뉴얼은 작업의 흐름을 따릅니다.

• 제1부 — 시작하기: 설치, 처음 실행, 인터페이스 둘러보기.
• 제2부 — 서비스 운영: 웹 스택, 데이터베이스, 전체 카탈로그, 사이트 및 도메인.
• 제3부 — 플릿, 네트워크 및 보안: 서버 연결, 네트워크와 경계 보안, 보안 강화, 모니터링 및 알림.
• 제4부 — 자동화 및 AI: 스크립트와 일정, AI 관리자 전체, MCP, AI 스택.
• 제5부 — 비즈니스 및 참조: 업종별 솔루션, 설정, 단축키, 라이선스, 문제 해결.

처음 사용한다면 2장, 설치 및 처음 실행으로 계속 진행하십시오. AI만 알고 싶다면 13장으로 바로 건너뛰어도 되지만, 그곳의 안전 모델은 위의 개념을 전제로 합니다.

FrontierStack은 다른 Mac 앱과 똑같이 설치합니다 — /Applications로 드래그한 다음 여십시오. 그다음은 사용자가 정합니다. macOS가 원래 표시하는 작업별 암호 입력만으로 모든 것을 실행할 수도 있고, 몇 가지 권한을 한 번만 허용하여 다시는 묻지 않게 할 수도 있습니다. 이 장에서는 첫 실행 전체를 차례대로 살펴본 다음, 기존 로컬 스택을 마이그레이션하여 사이트와 데이터베이스를 그대로 유지하는 방법을 설명합니다.

2.1시스템 요구 사항

FrontierStack은 서명된 네이티브 macOS 애플리케이션입니다. 다음이 필요합니다.

요구 사항	세부 정보
macOS	macOS 13(Ventura) 이상. 선택 사항인 헬퍼는 macOS 13 이상의 API인 SMAppService를 사용합니다.
아키텍처	Apple silicon 또는 Intel. 앱은 Apple silicon에서는 /opt/homebrew(Intel에서는 /usr/local)의 Homebrew 스택을 관리합니다.
Homebrew	권장하지만 앱 실행에 필수는 아닙니다. 대부분의 서비스는 Homebrew formula로 설치되며, FrontierStack이 Homebrew를 대신 설치해 줄 수 있습니다(아래 참조).
관리자 계정	Mac의 관리자 계정. 서비스를 설치하고 시스템 구성을 편집하려면 관리자 권한이 필요합니다 — 선택 사항인 헬퍼를 통하거나, macOS가 작업마다 표시하는 암호 입력을 통해 얻습니다.

이 목록에 특별한 것은 없습니다. 최신 macOS를 실행할 수 있을 만큼 새로운 Mac이라면 FrontierStack을 실행할 수 있습니다.

2.2다운로드와 첫 실행

앱을 다운로드하고 FrontierStack.app을 /Applications 폴더로 옮긴 다음 이중 클릭하십시오. 앱은 Enfour, Inc.(Apple Developer 팀 6Y87KNMALP)가 서명하고 공증을 받았으므로, macOS는 확인되지 않은 개발자 경고 없이 앱을 엽니다.

1. FrontierStack을 여십시오. 메인 윈도우가 나타나며 왼쪽에는 서비스 사이드바, 가운데에는 상태 개요가 표시됩니다 — 1장에서 본 레이아웃입니다.
2. 아직 Homebrew가 없으면 Homebrew가 필요한 패널에 그 사실이 표시되고 설치를 제안합니다. 지금 설치해도 되고 나중에 설치해도 됩니다.
3. FrontierStack은 한 번에 하나의 인스턴스만 실행되도록 합니다. 이미 열려 있는 상태에서 다시 실행하면 두 번째 사본이 시작되지 않고 기존 윈도우가 앞으로 나올 뿐입니다. 이렇게 하면 두 윈도우가 같은 서비스와 구성 파일을 두고 충돌하지 않습니다.

첫 실행에서는 시스템에 아무것도 변경하지 않습니다. 앱은 설치된 항목을 읽고 현재 상태를 보여 줄 뿐이며, 사용자가 요청하기 전에는 아무것도 시작, 중지 또는 재구성하지 않습니다.

스크린샷 추가 예정

2.3설정 지원

FrontierStack을 처음 열면 수백 개의 서비스가 나열된 사이드바에 바로 들어가는 대신 짧은 설정 지원을 제안합니다. 7페이지로 구성되어 있으며, 구성이 아니라 사용자에 대해 묻고, 묻는 내용 중 영구적인 것은 없습니다 — 모든 답변은 앱이 무엇을 먼저 보여 주고 제안할지만 결정합니다. 언제든지 중단할 수 있으며 서버 또는 기기 추가 ▸ 설정 지원에서 다시 열 수 있습니다.

페이지	묻는 내용
목표	비즈니스 운영, 개발, 서버 관리, 클라이언트 관리, 서비스 셀프 호스팅, 가정 네트워크 관리. 여러 개를 선택해도 됩니다. Mac에서 기존 MAMP 방식의 구성이 발견되면 마이그레이션 경로가 미리 선택됩니다.
환경	서버 관리 경험, 구성을 사용하는 인원 수, 관리하는 기기 수 — Mac 한 대부터 250대 초과까지.
스택	Apache, Nginx, PHP, Node.js, Python, MySQL, PostgreSQL, MongoDB, Redis, Git 등과, 없는 항목의 설치 제안.
AI	AI 관리자가 이미 비용을 지불하고 있는 AI 구독을 사용할지, API 키나 로컬 모델을 사용할지.
검토	무엇이 설치되고 무엇이 제안만 되는지를 실행 전에 보여 줍니다.
백업	이 Mac에 매시간 버전별 설정 기록을 보관할지(기본적으로 켜짐), 그리고 선택적으로 iCloud Drive나 Dropbox처럼 다른 곳과 동기화되는 폴더에 매일 사본을 보관할지 — 고정 항목, 셋업, 위치, 환경설정, Apache/PHP 구성이 OS 업그레이드나 초기화 후에도 유지되도록 합니다.
라이선스	현재 상황: 활성 라이선스가 있는지, 또는 라이선스 없이 사용할 수 있는 것은 무엇인지 — 이미 가지고 있는 라이선스 코드를 붙여넣는 필드도 있습니다.

완료하면 한 단계가 더 열립니다. 화면을 가득 채운 Services Manager로, 답변에 맞는 섹션이 이미 열려 있고 그 안의 모든 항목은 꺼져 있습니다. 사이드바에서 원하는 항목을 켜고 계속을 선택하십시오. 건너뛰기를 선택하거나 아무것도 켜지 않고 계속을 선택하면, 대신 권장 항목이 모두 켜집니다. 어느 쪽이든 AI 관리자와 AI 모델은 켜진 상태로 유지되며, AI 관리자에게는 이 단계가 닫힌 뒤에야 브리핑이 전달됩니다.

마지막 페이지는 라이선스에 관한 것이며, 판매를 위한 관문이 아니라 솔직한 안내입니다. FrontierStack은 라이선스 없이도 작동합니다 — 이 Mac을 모니터링하고, 서버를 연결하고, AI 관리자를 사용하고, 모든 진단 결과를 볼 수 있습니다. 방금 만든 계획 중 라이선스가 필요한 기능은 하나, 마이그레이션 실행뿐입니다. 스택을 옮기면 데이터베이스, 사이트, 구성을 대상에 복사하고 그곳에서 실행되는 것을 바꾸므로 라이선스가 필요합니다. 라이선스가 없어도 FrontierStack은 원본을 감지하고, 찾은 사이트와 데이터베이스를 나열하고, 마이그레이션이 무엇을 옮기게 될지 정확히 보여 줍니다 — AI 관리자도 전체 계획을 작성해 줍니다. 실제로 옮기는 작업만 제한되며, Migration 패널은 조용히 실패하는 대신 버튼에 그 사실을 표시합니다.

컨테이너, 백업 대상, 모니터링은 의도적으로 스택 페이지에서 설치하지 않습니다. 설정 지원이 사용자 대신 내려서는 안 되는 결정이 필요하므로, 대신 계획에 포함됩니다.

2.4권한 있는 헬퍼 — 그리고 macOS가 요청하는 권한

서비스를 시작 및 중지하고 시스템 구성(Apache, Nginx, MySQL, DNS, 방화벽)을 편집하는 것은 권한이 필요한 작업입니다. 기본적으로 FrontierStack은 각 작업을 표준 macOS 인증 대화상자를 통해 수행하므로, 매번 암호를 입력해야 합니다. 안전하지만 금방 번거로워집니다.

선택 사항인 헬퍼가 이 번거로움을 없애 줍니다. 헬퍼는 작은 권한 있는 도구 — SMAppService 데몬 — 로, 앱이 macOS에 등록하여 매번 암호를 다시 입력하지 않고도 관리자 작업을 수행할 수 있게 합니다. 헬퍼는 사용자가 직접 의도적으로 설치합니다. 사이드바 하단의 설치 항목을 사용하거나, 작업에 처음 헬퍼가 필요할 때 표시되는 안내를 수락하십시오.

1. 사이드바 하단의 헬퍼 행에서 설치를 클릭하십시오.
2. macOS가 로그인 항목 & 확장 프로그램 승인을 표시합니다(또는 시스템 설정 ▸ 일반 ▸ 로그인 항목에서 백그라운드 항목을 활성화하도록 요청합니다). 승인하십시오 — 이것은 macOS가 데몬 실행을 허용할지 묻는 것이지, 앱이 무언가를 무시하는 것이 아닙니다.
3. 사이드바 행이 바뀌어 헬퍼가 등록되어 실행 중임을 표시합니다. 이제부터 서비스 시작/중지와 구성 편집이 작업별 암호 입력 없이 진행됩니다.

헬퍼는 언제든지 제거할 수 있으며, 제거하면 FrontierStack은 작업별 관리자 암호 입력으로 돌아갑니다. 두 모드 모두 작동합니다 — 헬퍼는 순전히 편의를 위한 것입니다.

2.5Homebrew 설치

카탈로그의 대부분 — 웹 서버, 데이터베이스, 캐시, 메일, 수십 가지 CLI 도구 — 은 Homebrew formula로 설치됩니다. Homebrew는 FrontierStack이 이러한 서비스를 가져오고 업데이트하는 데 사용하는 패키지 관리자이므로, Mac에 아직 없다면 일찍 설치하는 것이 좋습니다.

사이드바에서 Homebrew 패널을 여십시오. Homebrew가 없으면 패널에 "Homebrew가 설치되어 있지 않습니다. 이 앱이 서비스를 설치하는 데 사용하는 패키지 관리자입니다,"라는 메시지와 함께 Homebrew 받기… 버튼이 표시됩니다. 설치는 앱의 인앱 콘솔에서 실행됩니다. 공식 Homebrew 설치 프로그램을 실행하며, 설치 프로그램에 관리자 권한이 필요한 시점에 사용자가 직접 콘솔에 암호를 입력합니다. FrontierStack은 암호를 가로채거나 저장하지 않습니다 — 이 입력 요청은 Homebrew 자체의 것입니다.

Homebrew가 설치되면 패널은 완전한 패키지 관리자가 됩니다. 설치된 formula와 cask를 버전과 함께 보여 주는 검색 가능한 표, formula 또는 cask 설치 필드, 남은 업데이트 수를 보여 주는 모두 업데이트 버튼, 행별 업데이트 / 제거 작업이 있습니다. AI 관리자도 install_homebrew 및 install_package 도구로 같은 흐름을 진행할 수 있으며, 이때도 사용자가 암호를 입력하는 인앱 콘솔을 거칩니다.

2.6Command-Line PATH 패널

FrontierStack은 셸과 같은 방식으로 경로를 찾아 설치된 도구를 감지합니다. 가끔 설치한 도구(pip, pipx, virtualenv 또는 비표준 접두사로 설치한 것)가 앱이 보는 PATH에 없어서 도구가 없다고 보고되는 경우가 있습니다. Command-Line PATH 패널이 이를 해결합니다.

• 셸 프로필(예: ~/.zprofile)을 선택하십시오. 추가한 디렉터리는 해당 파일의 명확하게 표시된 관리 블록에 기록되고 PATH 앞에 추가됩니다 — 변경 사항을 적용하려면 새 터미널을 여십시오.
• 추가할 디렉터리에서는 경로를 입력하거나 선택…으로 경로를 추가할 수 있으며, 맨 위 항목이 가장 먼저 검색됩니다. 현재 PATH(유효)는 로그인 셸의 PATH를 보여 주며, 앱이 관리하는 항목에는 태그가 붙습니다.
• PATH Doctor는 도구가 감지되지 않는 이유를 진단합니다. 명령(예: mlx_lm.server, gcloud)을 입력하면 앱이 찾는지, 셸에서만 찾는지, 아예 설치되지 않았는지를 보고하며 — 앱이 놓치고 있는 디렉터리는 원클릭 관리 PATH에 추가로 추가할 수 있습니다.

2.7Install Wizard

처음부터 시작한다면 사이드바의 Install Wizard가 작동하는 스택을 갖추는 가장 빠른 방법입니다. 대상 용도 — WordPress/PHP, 풀스택 JS, Python/Django, Rails, 정적 사이트, 데이터베이스, 리버스 프록시 — 를 선택하면 위저드가 그 목표에 권장되는 구성 요소(웹 서버, 데이터베이스, 캐시)를 미리 선택합니다. 원하는 대로 선택을 조정하면 모든 것을 Homebrew로 설치합니다.

같은 패널에는 네이티브 Apache + MySQL + PHP 스택의 상태가 한눈에 표시되며, Mac에 이미 있는 올인원 번들 — XAMPP, MAMP, AMPPS, Local — 도 감지합니다. 번들을 찾으면 병렬 스택을 설치하는 대신 Migrate Setups로 안내하므로, 모든 것을 두 개씩 실행하게 되는 일이 없습니다.

2.8기존 스택 마이그레이션

이미 MAMP, XAMPP 또는 Apple의 Server.app에서 로컬로 사이트를 실행하고 있다면 다시 구축할 필요가 없습니다. Migrate Setups 패널이 이러한 스택을 감지하고, 그 구성 요소 — 웹 파일, MySQL 데이터베이스, PHP 설정, 각 사이트를 정의하는 Apache 가상 호스트 — 를 FrontierStack의 네이티브 Homebrew 스택으로 가져옵니다.

1. Migrate Setups를 여십시오. 설치된 원본 — MAMP / MAMP Pro, XAMPP, Apple Server — 을 검색하고 찾은 것을 보고합니다. 사이트, 데이터베이스, PHP 감지 여부입니다. (AI 관리자의 detect_migration_sources 도구도 같은 읽기 전용 검색을 실행합니다.)
2. 가져올 사이트 목록을 검토하십시오. 각 후보에는 서버 이름과 수신 포트가 표시되며, 깔끔하게 가져올 수 없는 항목은 이유와 함께 건너뜀 아래에 표시됩니다.
3. 설정의 경우 모든 설정 가져오기 작업이 원본의 php.ini, my.cnf, nginx.conf를 대응하는 Homebrew 구성 위에 복사합니다. 각 파일의 .pre-mamp.bak 백업이 보관되므로 비교하거나 되돌릴 수 있습니다.
4. 선택 항목 가져오기를 선택하여 마이그레이션을 실행하십시오. 필요한 Homebrew 서비스를 설치하고, 웹 파일을 복사하고, MySQL 데이터베이스를 마이그레이션하고, 가상 호스트를 가져오는 동안 진행 상황이 패널에 실시간으로 표시됩니다.
5. 완료 후 검토하십시오. 원본 구성은 이전 도구의 경로와 포트(예: MAMP의 extension_dir, datadir, socket 또는 포트 8889)를 참조하는 경우가 많으므로, 가져온 설정을 사용하기 전에 확인하십시오.

AI 관리자는 run_migration으로 이 과정을 처음부터 끝까지 진행할 수 있지만, 원본을 감지하고 사용자에게 확인한 후에만 — 그리고 변경이 활성화된 경우에만 가능합니다.

2.9데이터 저장 위치

FrontierStack은 자체 상태를 예측 가능한 표준 위치에 보관하므로, 앱이 무엇을 건드리는지 항상 알 수 있고 백업할 수 있습니다.

항목	위치
앱 설정 & 데이터	~/Library/Application Support/FrontierStack/
비밀 값 & 토큰	macOS 키체인의 jp.co.enfour.frontierstack 서비스
앱이 관리하는 Apache 구성	/opt/homebrew/etc/httpd/frontierstack/ — 앱이 소유하는 전용 디렉터리로, 직접 편집한 Apache 구성과 분리되어 있습니다
앱 로그	~/Library/Logs/FrontierStack/

앱의 Apache 구성을 별도의 frontierstack/ 디렉터리에 보관하므로, FrontierStack은 사용자가 직접 관리하는 구성을 덮어쓰지 않고 안전하게 가상 호스트를 관리할 수 있습니다. 번들 식별자는 jp.co.enfour.frontierstack입니다(헬퍼와 DDNS 구성 요소는 .helper 및 .ddns 접미사를 사용합니다).

앱을 설치하고, 헬퍼 사용 여부를 정하고, Homebrew를 갖추고, 기존 스택을 마이그레이션했다면 이제 실제로 사용할 준비가 되었습니다. 3장, 인터페이스에서는 사이드바, 패널, 검색, 메뉴 막대, 그리고 매일 사용하게 될 컨트롤 등 윈도우를 자세히 둘러봅니다.

FrontierStack은 매우 다양한 서비스를 관리하지만, 이를 하나의 익숙한 macOS 윈도우로 보여 줍니다. 왼쪽에는 항목을 나열한 사이드바, 가운데에는 선택한 항목의 화면, 그리고 도구 막대에는 언제나 쓸 수 있는 도구가 한 줄로 놓여 있습니다. 이 레이아웃을 한 번만 익혀 두면 이 책에 나오는 모든 패널이 — Apache부터 Cloudflare 영역까지 — 예상한 바로 그 자리에 있습니다. 이 장에서는 인터페이스를 처음부터 끝까지 살펴봅니다. 그래야 이 매뉴얼의 나머지 부분에서 “사이트 패널을 여십시오”라고만 해도 여는 방법을 이미 알고 있다고 믿을 수 있기 때문입니다.

3.1메인 윈도우

윈도우는 세 영역으로 이루어진 표준 macOS NavigationSplitView입니다. 왼쪽에는 서비스 사이드바가 있습니다. 보기로 선택한 모든 서비스와 도구를 카테고리별로 묶어 스크롤하고 접을 수 있는 목록입니다. 가운데에는 활성 패널이 있습니다. 사이드바에서 선택한 항목의 화면으로, 자체 헤더, 탭, 컨트롤을 갖추고 있습니다. 위쪽을 가로지르는 것은 도구 막대이며, 그 버튼은 어느 패널에 있든 항상 사용할 수 있습니다.

도구 막대에는 오른쪽부터 왼쪽으로 다음이 있습니다. 검색(돋보기, ⌘F로도 열 수 있음), AI 어시스턴트(요술 지팡이, 플로팅 명령 팔레트를 엶), 현재 작업 디렉터리에서 터미널을 여는 Shell 버튼, macOS가 라이트 모드일 때도 다크 모드를 강제로 적용하는 다크 모드 토글, 그리고 선택한 패널을 띄울 수 있을 때는 이를 팔레트로 분리하는 분리 버튼입니다. 셋업에 저장하지 않은 변경 사항이 있으면 주황색 저장 안 됨 메뉴도 여기에 나타납니다. KeyRotate가 설치되어 있으면 열쇠 꾸러미 모양의 버튼이 맨 왼쪽에 별도의 그룹으로 놓입니다. 이 버튼은 KeyRotate를 열거나 앞으로 가져옵니다.

사이드바의 너비는 자유롭게 정할 수 있습니다. 구분선을 드래그하면 FrontierStack이 실행할 때마다 그 너비를 기억합니다. 앱을 다시 열면 마지막으로 선택한 패널이 복원되므로, 중단했던 곳으로 바로 돌아갑니다.

사이드바 그룹은 여러 사이트나 회사에 걸친 사이드바를 정리해 줍니다. 고정된 서버, 기기, Cloudflare 영역, Wi-Fi 네트워크 또는 클러스터를 오른쪽 클릭하여 그룹(“오사카 사무소”, “Acme Corp”)에 할당하십시오. 그러면 사이드바 맨 위의 그룹 행으로 세트를 전환할 수 있으며, 활성 그룹의 항목과 그룹에 속하지 않은 모든 항목이 표시됩니다. 그룹 지정은 선택 사항이며, 그룹에 속하지 않은 항목은 항상 표시됩니다. 활성 상태가 아닌 그룹에 빨간 숫자가 표시되면 그 안에 숨겨진 무언가에 문제가 있다는 경고입니다. 위치에 연결된 그룹은 해당 네트워크에 도착하면 스스로 활성화됩니다. iPhone 앱의 플릿 탭에도 같은 폴더가 그대로 반영됩니다.

3.2서비스 사이드바

사이드바는 두 단계로 구성됩니다. 맨 위에는 개요가 있습니다. 앱에 내장된 도구들로, 로컬 상태, 상태 페이지, 알림, 지출 및 청구, 도메인, 로그, 인증서, 메모, 스크립트, 셋업, 설정 등이 있습니다. 그 아래에는 서비스 카테고리마다 하나씩 섹션이 있습니다. 웹 서버, 데이터베이스, 캐싱, 메일, 네트워킹, 보안 도구, 컨테이너, AI 등 수십 가지가 있으며, 각 섹션에는 카탈로그(6장)에서 표시하기로 선택한 서비스가 나열됩니다. 각 섹션 헤더는 클릭하여 접을 수 있는 갈매기표이며, 앱은 어떤 그룹을 접어 두었는지 기억합니다.

각 서비스 행은 실행 중일 때 상태 점을 표시합니다. 서비스를 오른쪽 클릭하면 두 가지 빠른 동작을 쓸 수 있습니다. 섹션 맨 위에 고정은 자주 다루는 서비스를 카테고리의 맨 위에 둡니다. 숨기기는 서비스를 사이드바에서 제거합니다. 숨겨도 아무것도 제거되지 않습니다. 서비스는 계속 실행되고 검색으로 여전히 찾아갈 수 있으며, 단지 목록을 어지럽히지 않을 뿐입니다.

카테고리 아래에는 앱의 다른 곳에서 고정한 항목을 위한 섹션이 추가됩니다. 연결된 서버(각각 어떤 서비스를 실행하는지 보여 주는 작은 카테고리 아이콘이 붙음), 모니터링 중인 Wi-Fi 네트워크, Cloudflare 영역, Kubernetes 클러스터입니다. 사이드바 맨 위의 필터 필드에 입력하면 모든 섹션을 한꺼번에 좁힐 수 있습니다.

3.3프리셋과 셋업

사이드바에 무엇이 표시될지는 두 가지 기능이 결정합니다. 메뉴 막대의 프리셋 메뉴는 하나의 사용 사례 전체를 한 번에 불러오는 빠른 방법입니다. 기본 — 다음 용도의 서비스 표시… 섹션은 사이드바를 특정 시나리오(웹 스택, 메일 서버, 쇼핑몰)에 맞게 선별된 세트로 바꾸고, 현재 보기에 추가…는 이미 있는 것 위에 그룹을 하나 더 얹습니다. 모두 보기는 모든 것을 표시합니다. 무언가를 찾을 수 없을 때 쓰는 탈출구입니다.

셋업은 한 걸음 더 나아갑니다. 셋업은 작업 화면 전체에 이름을 붙인 스냅샷입니다. 어떤 서비스가 숨겨져 있고 어떤 서비스가 고정되어 있는지, 그리고 어떤 플로팅 팔레트가 어디에 열려 있는지까지 담습니다. 프리셋 ▸ 현재 상태를 셋업으로 저장…(또는 셋업 패널)에서 저장한 다음, 프리셋 메뉴 맨 위에서 셋업을 전환하십시오. 활성 셋업에는 체크 표시가 붙습니다. 윈도우를 옮기는 동안 팔레트 배치가 활성 셋업에 자동으로 저장되므로, 셋업은 언제나 실제 작업 방식을 그대로 반영합니다. 표시할 서비스를 바꾸면 셋업이 변경됨 상태가 되고, 도구 막대에 업데이트, 새로 저장, 되돌리기가 있는 주황색 저장 안 됨 배지가 나타납니다.

셋업은 위치에 연결할 수도 있습니다(8장). “사무실” 셋업을 사무실 네트워크에 연결해 두면, 도착했을 때 FrontierStack이 자동으로 그 셋업으로 전환합니다. 지금 있는 곳에 맞는 서비스와 팔레트가 준비됩니다.

3.4플로팅 팔레트와 미니 팔레트

다른 곳에서 작업하는 동안 어떤 화면 하나를 계속 띄워 두고 싶을 때가 있습니다. 모니터 형식의 패널은 어느 것이든 플로팅 팔레트로 분리할 수 있습니다. 플로팅 팔레트는 macOS NSPanel 기반의 작고 항상 위에 있는 유틸리티 윈도우로, 메인 윈도우와 다른 앱 위에 머뭅니다. 도구 막대의 분리 버튼을 사용하십시오(맨 앞의 팔레트를 닫으려면 ⌘⌥⇧W). 로컬 상태, 컨테이너, 클라우드 서버, Wi-Fi 분석기 등을 모두 띄울 수 있습니다.

더 가볍게 쓰고 싶다면 미니 팔레트가 있습니다. 전체 패널 대신 한눈에 볼 수 있는 간결한 요약입니다. 미니 팔레트는 로컬 상태, Cloudflare 영역, Wi-Fi, 프린터, 라우터 및 네트워크, 컨테이너, 스크립트, 메시지 전송, AWS용이 있습니다. 각 미니 팔레트 행에는 세부 정보가 필요할 때 메인 윈도우에서 해당 패널을 여는 버튼이 있습니다. 열려 있는 팔레트는 셋업의 일부이므로, 저장된 보기를 불러오면 플로팅 윈도우가 배치해 둔 그대로 복원됩니다.

3.5명령 및 AI 팔레트

도구 막대의 요술 지팡이 버튼은 AI 어시스턴트 팔레트를 엽니다. 무엇이든 물어볼 수 있는 입력 필드 하나(“사이트가 왜 다운됐지?”, “MySQL 튜닝”, “내가 쓰는 것만 보여 줘”)가 있는, 드래그할 수 있고 항상 위에 있는 NSPanel입니다. 13장에서 다루는 AI 관리자와 같은 것으로, 무엇을 하든 그 옆에 둘 수 있는 플로팅 윈도우로 꺼내 놓은 것입니다. 다른 플로팅 팔레트와 마찬가지로 메인 윈도우 위에 머물지만, 다른 팔레트와 달리 대답하고, 해결책을 제안하며, 승인을 받으면 직접 실행합니다. 자체 대화 기록과 변경을 가하는 모든 동작에 대한 승인 카드를 갖추고 있어, 여러분이 허락하기 전에는 아무것도 실행되지 않습니다.

3.6메뉴 막대 항목

FrontierStack은 macOS 메뉴 막대에 작은 항목을 둘 수 있습니다(메뉴 막대에 표시 토글). 윈도우 전체를 앞으로 가져오지 않고 작업하는 가장 빠른 방법입니다. 여기에서 시작 그룹을 시작하거나 중지하고, 핵심 서버(Apache, Nginx, PHP-FPM, MySQL, Postgres) 중 하나 또는 실행 중인 모든 것을 한꺼번에 재시작하고, 상태를 새로 고치고, 앱을 열거나 종료할 수 있습니다. 백그라운드만은 앱을 종료하되 백그라운드 서비스(MCP, CLI, 페어링된 기기, 모니터)는 계속 실행합니다. 필요하면 먼저 백그라운드 서비스를 켭니다. FrontierStack 아이콘은 이제 백그라운드 서비스가 제공하는 형태로 메뉴 막대에 남으며, FrontierStack 열기와 FrontierStack 종료가 있습니다. 여기서 종료하면 다음에 FrontierStack을 열거나 다시 로그인할 때까지 백그라운드 서비스가 중지됩니다. 백그라운드 실행이 유휴 상태로 종료된 뒤에도 아이콘은 남습니다. 로그인 시 실행 설정은 설정 › 일반에 있습니다.

Localhost 사이트 섹션에는 Localhost 패널의 모든 사이트가 이름별로 나열됩니다. 실행 중이면 채워진 원, 중지되어 있으면 빈 원으로 표시되며, 무엇이 사이트를 제공하는지와 그 버전(예: Apache 2.4.62 · PHP 8.3.14 또는 PHP 8.4.5)도 함께 표시됩니다. 각 사이트의 하위 메뉴에서 사이트를 시작, 중지, 재시작하거나 열 수 있습니다. 시작하고 브라우저에서 열기는 서버가 수신 대기할 때까지 기다린 다음 페이지를 엽니다.

3.7앱 내 검색

검색(돋보기, ⌘F)은 무엇에든 가장 빨리 도달하는 방법입니다. “서비스, 도구 및 동작 검색…”에 입력을 시작하면 입력하는 대로 팔레트가 패널, 도구, 서비스, 동작을 찾아 줍니다. 사이드바에서 숨긴 서비스도 포함됩니다. 결과를 선택하면 앱이 곧바로 그곳으로 이동합니다. 시맨틱 모드를 사용하면 정확한 이름 대신 의미(“IP 차단”, “디스크 공간 확보”)로 검색할 수 있으므로, FrontierStack이 그 기능을 무엇이라고 부르는지 몰라도 찾을 수 있습니다.

3.8도움말 윈도우

⌘?로 도움말을 열면 전용 FrontierStack 도움말 윈도우가 나타납니다. 앱의 구성을 그대로 따라 정리된, 진짜 책과 같은 앱 내 문서입니다. 도움말은 읽기만 하는 것이 아닙니다. 페이지에는 앱에서 열기 링크가 있습니다. 링크를 클릭하면 FrontierStack이 메인 윈도우를 바로 그 패널이나 서비스로 이동시킵니다. 도움말 윈도우는 그 옆에 열린 채로 남으므로, 절차를 읽으면서 단계별로 따라 할 수 있습니다. 많은 패널의 헤더에는 해당 주제의 도움말을 여는 작은 도움말 버튼이 있습니다.

3.9메모 패널

메모는 자격 증명, 운영 절차서(런북), 서비스별 지침을 보관하는 개인 공간입니다. 각 메모에는 제목, 서비스 태그, 본문이 있으며, 전체가 일반 파일이 아니라 macOS 키체인에 암호화되어 저장됩니다. 가장 중요한 특징은 메모별 잠금입니다. 모든 메모에는 AI 관리자와 공유 토글이 있으며 기본값은 꺼짐입니다. 메모가 잠겨 있는 동안에는 AI가 말 그대로 그 메모를 읽을 수 없습니다. 어시스턴트가 해당 자격 증명이나 절차를 사용하기를 원할 때만 메모 잠금을 해제하십시오. 그러면 메모가 AI의 list_notes에 나타나고 필요할 때 읽을 수 있게 됩니다.

3.10상태 페이지

상태 페이지 패널은 로컬 상태와 같은 가동/중단 데이터로 만든 정적 index.html을 게시하므로, 고객이나 동료가 앱에 접근하지 않고도 무엇이 실행 중인지 볼 수 있습니다. 대상 위치를 선택하십시오. Apache 사이트 중 하나의 DocumentRoot 안에 있는 폴더를 선택하면 /status/ 같은 경로로 제공됩니다. 그런 다음 페이지 제목을 정하고 항목 세부 정보 포함 여부를 결정하십시오(공개 페이지에서는 세부 정보 줄을 끄십시오. 내부 호스트와 포트가 드러날 수 있습니다). 페이지는 설정한 간격마다 다시 생성되며, 지금 생성으로 즉시 생성할 수도 있습니다. 제공 방식에서 Apache 또는 내장 서버(원하는 포트에서 localhost나 LAN으로 제공하는 번들 정적 파일 서버)를 선택하고, 실행으로 로그인 시 또는 시스템 시작 시 그 서버를 계속 실행하게 하면 앱을 닫은 뒤에도 페이지가 유지됩니다. 서버 섹션에는 모니터가 있는 고정된 서버를 나열할 수 있으며, 앱이 닫혀 있는 동안에도 실시간으로 유지됩니다. 인터넷 접근은 지속적인 경로(Cloudflare Tunnel, Tailscale, Dynamic DNS를 사용한 라우터 포트 포워딩)를 제공합니다. 자세한 내용은 11장을 참조하십시오.

3.11로컬 상태와 위치 한눈에 보기

두 개의 개요 패널이 일상적인 사용의 중심이 되며, 각각 별도의 장에서 자세히 다룹니다. 로컬 상태는 “모든 것이 정상인가?”에 답하는 보드입니다. 모니터링 중인 모든 서비스, 기기, 하위 시스템을 UP 또는 DOWN 상태와 한 줄 요약으로 보여 줍니다. 각 항목의 패널에서 중요 항목으로 표시하면 보드에 추가되며, 이 보드는 플로팅 팔레트와 미니 팔레트로도 쓸 수 있습니다. 상태 점검, 임계값, 알림을 구동하는 방식 등 전체 내용은 11장에서 다룹니다.

위치는 지금 Mac이 네트워크상 어디에 있는지 — 집, 사무실, VPN 연결 중 — 를 Wi-Fi 네트워크나 서브넷으로 판별하여 앱에 알려 줍니다. 위치 덕분에 모니터링이 네트워크를 인식합니다. 인식되지 않는 곳에 있는 동안 앱은 여러분을 외출 중으로 간주하고 위치 범위의 점검을 일시 중지하므로, 카페나 호텔 네트워크에서 잘못된 경보가 울리는 일이 없습니다. 위에서 본 것처럼 위치는 셋업과도 연결됩니다. 위치 정의, 알림과 도달 가능성의 범위 지정, 플릿 등 전체 모델은 8장에서 다룹니다.

레이아웃을 익혔으니 이제 실제로 활용할 준비가 되었습니다. 매뉴얼의 다음 부에서는 4장, 웹 스택부터 시작하여 패널 자체를 하나씩 열어 봅니다.

웹 서버는 대부분의 셀프 호스팅 환경에서 핵심이므로, FrontierStack은 웹 서버를 가장 중요한 요소로 다룹니다. Apache 패널은 Homebrew Apache를 설치, 시작, 검증하고 구성합니다. PHP, Localhost, Certificates, DNS 패널이 더해져 완전한 개발 및 호스팅 스택을 이루며 — 모든 변경은 검증을 거치므로 오타 하나로 사이트가 조용히 다운되는 일은 없습니다.

이 장에서는 지금 사용 중인 Mac에서 웹 사이트를 만들고 운영하는 패널을 다룹니다. 이 스택을 실제 도메인과 공용 인터넷에 연결하는 방법은 7장에서, 프로덕션용으로 보안을 강화하는 방법은 10장에서 설명합니다.

4.1Apache 패널

사이드바에서 Apache 패널을 열면 웹 서버의 상태(버전, 실행 여부, 수신 대기 중인 포트)를 한눈에 볼 수 있습니다. 상단의 버튼은 매일 사용하는 제어 기능인 시작, 중지, 재시작, 구성 검증입니다. 검증은 apachectl -t(실제 구문 검사)를 실행하고 결과를 마지막 결과에 표시하므로, 다시 로드하기 전에 변경 사항이 올바른지 확인할 수 있습니다.

FrontierStack은 macOS 시스템 Apache 대신 Homebrew Apache를 권장합니다. Homebrew 서버는 /opt/homebrew(Intel Mac에서는 /usr/local) 아래에 있으며, brew services를 통해 사용자 권한으로 실행되므로 작업할 때마다 root 암호를 묻지 않고, System Integrity Protection의 제한도 받지 않습니다 — 따라서 최신 mod_php가 문제없이 로드되고 스택 전체가 하나의 툴체인에 머뭅니다. /etc/apache2 아래의 시스템 Apache는 OS 업데이트 시 초기화되며, Apple이 번들로 제공하는 libphp에 묶이게 됩니다. Homebrew Apache가 설치되어 있지 않으면 패널에서 Homebrew Apache 설치…를 클릭 한 번으로 실행할 수 있습니다.

Homebrew 빌드, 레거시 로컬 빌드, 원격 서버의 빌드 등 여러 Apache 빌드를 함께 사용하는 경우, 바이너리 선택기(Homebrew Apache 추가 / 로컬 빌드 추가… 참조)로 각각을 등록하고 전환할 수 있으며, 각 빌드의 버전과 포트가 함께 표시됩니다.

4.2모듈, 포트, 관리형 구성

Apache 패널 아래쪽에는 가장 자주 편집하는 구성 부분이 파일이 아닌 컨트롤 형태로 제공됩니다.

섹션	기능
포트	HTTP 및 SSL 수신 대기 포트(기본값 80과 443)를 설정합니다. Nginx가 80/443을 사용 중이면 Apache를 다른 포트로 옮기십시오. 적용을 누르면 Listen 지시어를 다시 쓰고 다시 로드합니다.
Apache 모듈(모듈…)	로드된 모듈을 나열하고 활성화하거나 비활성화합니다. 사용하지 않는 모듈을 비활성화하는 것이 가장 간단한 보안 강화 방법입니다.
PHP 모듈	Apache가 웹 사이트용으로 로드할 mod_php(libphp.so)의 버전을 선택합니다 — 다음 섹션을 참조하십시오.
WebDAV	공유 폴더에 mod_dav를 활성화하고, 선택적으로 Basic 인증 사용자를 설정해 관리형 include에 기록합니다.
MIME 유형 편집…	FrontierStack이 관리하는 MIME 파일에서 AddType 매핑을 추가하거나 제거하며, 배포판의 mime.types는 건드리지 않습니다.

컨트롤로 제공되지 않는 항목은 구성 행의 관리형 구성 편집…(FrontierStack include)과 httpd.conf 편집…(주 파일)으로 직접 편집할 수 있습니다. 저장할 때마다 apachectl -t로 검증하고, 정상적으로(graceful) 다시 로드하며, 새 구성을 해석할 수 없으면 롤백합니다 — 따라서 잘못된 편집은 실행 중인 서버를 망가뜨리기 전에 걸러집니다.

모듈을 켜고 끄면 해당 LoadModule 줄을 다시 쓰고 재검증합니다. 변경 후 httpd -t가 실패하면 — 대표적인 예가 proxy 없이 proxy_fcgi를 활성화하는 경우로, 이제 앱이 자동으로 활성화해 줍니다 — 모듈 윈도우가 오류를 표시하고 조용히 닫히지 않습니다. 오류를 수정하거나 그래도 저장을 선택하십시오. Apache가 멈춰서 시작되지 않을 때(이미 로드된 서비스나, sudo brew services로 인해 일부 httpd 경로의 소유자가 root가 된 경우에 발생하는 전형적인 Homebrew 오류 Bootstrap failed: 5: Input/output error), 패널의 복구 및 재설정 섹션에서 단계별로 강도가 높아지는 세 가지 해결책을 제공합니다. 깨끗하게 재시작(사용자 및 시스템 launchd 도메인 양쪽에서 httpd를 중지한 다음 한 번 시작), 구성을 기본값으로 재설정(httpd.conf를 백업하고 Homebrew 기본 구성을 복원), 제거 후 재설치(root 소유 경로를 정리하고 formula를 재설치)입니다. 모두 앱 내 콘솔에서 실행되므로 sudo 프롬프트와 출력을 확인할 수 있습니다. Apache에 서비스 워치독의 keep-alive도 켜져 있으면 워치독이 httpd를 스스로 재시작할 수 있습니다 — 정상적인 동작이지만, 수동 복구와 충돌한다면 일시 중지하십시오.

4.3PHP 버전 선택

PHP 패널을 열어 Mac에 설치된 PHP 런타임을 관리합니다. Homebrew에서는 여러 메이저 버전(예: [email protected]부터 최신 릴리스까지)을 나란히 설치할 수 있으며, FrontierStack은 이를 하나의 전역 설치가 아니라 전환해 가며 사용하는 버전 묶음으로 다룹니다.

버전 ▸ 버전 추가…는 기존 버전과 나란히 다른 버전을 설치합니다 — 어떤 것도 교체되지 않으며, 사용 중인 버전도 바뀌지 않습니다. 목록은 두 부분으로 나뉩니다. Homebrew 자체 릴리스는 업스트림에서 아직 지원하는 버전입니다. 그 아래에는 지원 종료(EOL) 빌드 — PHP 8.0부터 5.6까지 — 가 있으며, 이들은 PHP에서 더 이상 패치하지 않고 Homebrew에서도 제외된 버전입니다. FrontierStack은 이 버전들을 커뮤니티 shivammathur/php tap에서 가져오며, tap에서 설치한다는 것은 해당 tap의 코드를 실행한다는 뜻이므로 각 버전마다 먼저 확인을 요청합니다. 지원 종료 PHP는 자신의 컴퓨터에서 레거시 사이트를 테스트하거나 유지 관리하는 용도로만 사용하고, 절대로 공용 인터넷에 노출하지 마십시오.

선택할 수 있는 항목은 두 가지입니다.

• Apache 모듈. Apache 패널의 PHP 모듈 섹션에 있는 웹 사이트용으로 로드 선택기에서 Apache가 로드할 libphp.so의 버전을 선택합니다. 변경하면 관리형 구성을 다시 쓰고 Apache를 다시 로드합니다.
• 사이트별 PHP. 로컬 개발 서버(아래의 Localhost 패널)에는 설치된 모든 버전을 나열하는 자체 PHP 버전 선택기가 있어, 컴퓨터의 다른 부분이 사용하는 버전을 바꾸지 않고도 한 프로젝트는 구버전 PHP로, 다른 프로젝트는 최신 버전으로 실행할 수 있습니다. 레거시 앱과 새 앱을 동시에 문제없이 운영하는 일반적인 방법입니다. 이 설정은 두 가지 로컬 런타임, 즉 PHP 내장 서버와 Apache 런타임 모두에 적용됩니다. mod_php로 서비스하는 Apache에는 한 가지 주의할 점이 있습니다. 해당 버전의 keg에 libphp.so가 포함되어 있어야만 사용할 수 있으며, 선택한 버전에 없으면 편집기가 알려 줍니다. 그런 경우 해당 사이트를 내장 서버에서 실행하거나 PHP-FPM으로 서비스하십시오.

런타임 상태 패널은 PHP와 함께 Python, Node.js, Java, Go, Rust, Ruby, Perl, .NET까지 더 넓은 범위를 보여 주며, 자체 점검 기능으로 누락되었거나 지원이 종료된 런타임을 문제가 생기기 전에 알려 줍니다.

런타임 섹션에는 프런트엔드 작업을 위한 React 패널도 있습니다. 새 앱(Vite, TanStack Start 또는 Next.js)의 기본 구조를 생성하고, 임의의 React 프로젝트를 지정할 수 있으며, 용도별로 정리된 엄선된 보조 라이브러리 목록을 제공합니다 — 상태 관리(Zustand, Jotai, Redux Toolkit), 데이터 페칭 및 서버 상태(TanStack Query — 예전 이름은 React Query — 와 SWR), 풀스택 프레임워크(TanStack Start, Next.js), 라우팅, 유효성 검사(ArkType, Zod), 폼, 인증(Clerk). 각 행에는 문서, 선택한 프로젝트에서 이미 사용 중인지 여부, 해당 프로젝트에 클릭 한 번으로 실행하는 npm install이 표시됩니다.

4.4사이트와 가상 호스트

Apache 패널의 웹 사이트 목록에서 가상 호스트를 관리합니다. 각 행에는 사이트 이름, 바인드 주소와 포트(예: :8080), 실시간 상태를 나타내는 실행 중 토글이 표시됩니다. 버튼으로 사이트 추가…, 편집, 복제, 비활성화, 서버로 푸시…(가상 호스트를 연결된 서버로 복사), 브라우저에서 사이트 열기를 할 수 있습니다. 사이트 가져오기…와 다음에서 복사…는 MAMP, XAMPP, Apple의 Server.app 또는 다른 Apache에서 기존 가상 호스트를 가져오며, 기본적으로 localhost에 바인드됩니다.

사이트를 추가하거나 편집할 때는 가상 호스트에 필요한 필수 항목을 설정합니다. ServerName(도메인), 문서 루트(선택…으로 폴더 지정), 바인드 주소와 포트입니다. 사이트를 활성화하면 실시간 상태 점과 함께 목록에 나타납니다. FrontierStack은 관리형 트리 아래의 .conf 파일에 가상 호스트를 기록하고, 검증한 뒤 다시 로드합니다. 가상 호스트, 인증서, Cloudflare DNS 레코드를 한꺼번에 만들려면 새 사이트 + DNS…를 사용하십시오 — 7장에서 설명하는 원스톱 마법사입니다.

스크린샷 추가 예정

4.5사이트용 TLS 인증서

Certificates 패널은 사이트에 자물쇠 아이콘을 표시해 주는 인증서를 발급하고 관리합니다. 용도에 따라 세 가지 방법을 제공합니다.

방법	용도
mkcert(인증서 받기(mkcert))	신뢰할 수 있는 로컬 HTTPS. mkcert는 Mac이 신뢰하는 로컬 인증 기관을 설치하므로 https://myapp.test가 브라우저 경고 없이 동작합니다 — 개발에 이상적입니다. 먼저 mkcert 설치로 설정하십시오.
Let’s Encrypt (ACME)	acme.sh 또는 certbot을 통해 실제 도메인용으로 브라우저가 신뢰하는 공개 인증서를 발급합니다. webroot(도메인이 이미 HTTP를 서비스하는 경우) 또는 Cloudflare를 통한 DNS-01(인바운드 HTTP 불필요) 방식으로 발급합니다. 지금 모두 갱신과 갱신 cron으로 최신 상태를 유지합니다.
자체 서명 인증서 생성	브라우저 경고를 감수할 수 있는 내부용 또는 테스트용의 간단한 인증서입니다.

발급한 후에는 Apache에 배포로 인증서를 사이트의 가상 호스트에 연결합니다. 만료 모니터링 섹션은 인증서(및 감시로 추가한 도메인)를 감시하고 만료되기 훨씬 전에 알림을 보냅니다 — HSTS와 최신 암호화 정책을 포함한 더 깊은 보안 강화 내용은 10장에서 다룹니다.

4.6이 Mac과 연결된 서버의 인증서 업데이트

설치된 인증서의 모든 인증서에는 발급자와 남은 일수가 표시됩니다. 행의 업데이트…는 인증서를 그 자리에서 갱신하며, 해당 인증서에 맞는 방법만 제공합니다. 자체 서명 재발급(기본적으로 같은 개인 키 사용, 최대 397일), certbot으로 갱신 또는 acme.sh(클라이언트 자체의 배포 훅이 실행됨), mkcert로 갱신, 또는 다른 곳에서 구입한 인증서의 경우 파일에서 교체…입니다. 이전 파일은 새 파일 옆에 .bak로 보관되며, 같은 단계에서 웹 서버를 다시 로드할 수 있습니다.

연결된 서버가 있으면 패널 상단에 호스트 선택기가 나타납니다. 서버를 선택하면 패널이 SSH를 통해 해당 서버의 인증서를 읽어 옵니다. Let’s Encrypt 계보, acme.sh, /etc/ssl, 그리고 nginx, Apache, Caddy, HAProxy 인증서 폴더가 대상입니다. 개인 키가 옆에 있는 인증서만 나열됩니다. 업데이트와 생성…도 그곳에서 동작하며, 변경은 서버에 저장된 sudo 암호를 사용해 root로 실행되므로 암호가 없으면 서버는 읽기 전용으로 표시됩니다.

설치된 인증서는 이 Mac과 연결된 서버 모두에서 자동으로 감시되므로, 별도 설정 없이 알림이 만료 전에 경고합니다. 각 행의 종 아이콘으로 감시를 켜거나 끌 수 있으며, 처음 발견했을 때 이미 만료된 인증서는 제외됩니다.

스크린샷 추가 예정

4.7.htaccess 편집기

디렉터리별 Apache 규칙 — 재작성, 리디렉션, 접근 제어 — 은 .htaccess 파일에 있으며, FrontierStack은 줄 번호와 구문 점검 기능을 갖춘 전용 편집기를 제공합니다. 사이트 루트 사용으로 사이트 문서 루트의 .htaccess를 열거나 사용자 지정 경로를 지정하십시오. 레시피 삽입은 흔히 쓰이는 올바른 스니펫(프런트 컨트롤러 재작성, HTTPS 강제 블록)을 넣어 주므로 기억에 의존하지 않고 동작하는 규칙에서 시작할 수 있으며, 편집기는 저장하기 전에 명백한 문제를 표시합니다. PHP 라우터 내보내기…는 .htaccess 재작성 규칙을 PHP 내장 개발 서버용 라우터 파일로 변환합니다 — 사이트를 Localhost 패널로 옮길 때 유용합니다.

4.8Nginx와 리버스 프록시

FrontierStack은 Nginx를 대체 웹 서버로, 또는 앱 앞단의 리버스 프록시로 관리합니다. 둘 다 설치되어 있으면 도메인 보기에서 사이트를 서버별로 묶어 Apache 가상 호스트와 Nginx server 블록을 나란히 보여 주며, 각 Nginx server 블록의 listen 포트, root, TLS 상태를 읽어 옵니다. 리버스 프록시는 높은 번호의 포트에서 HTTP로 동작하는 애플리케이션(Node, .NET 또는 Python 서비스)을 앞단에서 받아 주는 표준 패턴입니다. Nginx가 443에서 TLS를 종료하고 앱으로 전달합니다. Apache와 Nginx는 둘 다 기본적으로 80/443을 사용하려 하므로, 함께 실행한다면 Apache 패널의 포트 섹션에서 한쪽을 다른 포트로 옮기십시오.

4.9Localhost, DNS, 개발 스택

로컬 환경을 완성하는 패널이 세 가지 더 있습니다.

• Localhost — 임시 로컬 개발 서버 관리자입니다. 새 로컬 서버를 추가하고, 런타임(PHP, Python/Django, Node/Vite…)과 폴더를 선택한 다음, 포트와 선택적인 ServerName을 설정하고 시작하십시오 — 서버별 환경 전역 변수와 .test 리졸버가 있어 myapp.test가 로컬에서 해석됩니다. 빈 포트 도우미와 localhost를 점유한 프로세스 중지 작업으로 흔히 발생하는 충돌을 해결할 수 있습니다. Tailscale에서도 서비스를 체크하면 다른 Tailscale 기기에서 이 Mac의 tailnet 주소와 같은 포트로 서버에 접근할 수 있습니다 — 서버는 여전히 localhost에서만 수신 대기하고 FrontierStack이 tailnet 연결을 서버로 전달하므로, LAN에서는 접근할 수 없습니다. Django 서버의 경우 Tailscale 호스트 허용…이 변경 내용을 보여 준 뒤 프로젝트의 ALLOWED_HOSTS에 tailnet 주소를 추가합니다(설정이 환경 변수로 구성된 경우에는 추가할 줄을 알려 줍니다). AI 관리자(및 MCP를 통한 에이전트)도 debug_share 작업 serve로 같은 방식으로 폴더를 시작할 수 있습니다. 응답에는 localhost 호스트와 포트, 요청한 경우 Tailscale URL이 포함되므로 에이전트가 사이트가 실행 중인 위치를 보고할 수 있습니다.
• DNS — 로컬 이름 해석과 권한 있는(authoritative) 호스팅입니다. dnsmasq, unbound 또는 nsd를 실행하고, 영역 파일을 가져오거나 내보내며, 레코드가 바뀌면 리졸버 캐시를 비워 Mac이 오래된 응답을 반환하지 않게 합니다.
• LAMP / DevStacks — 원클릭 스택입니다. LAMP 패널은 서로 맞춰진 구성 요소 세트를 함께 설치하고 시작하는 프리셋(셋업 선택)을 제공합니다(설치 및 시작, 모두 시작, 모두 중지). DevStacks는 프로젝트 폴더의 프레임워크를 감지하고 실행에 필요한 명령과 npm 스크립트를 보여 줍니다.

Localhost 개요는 실행 중인 모든 로컬 서버를 나란히 보여 주므로, 터미널 윈도우를 잔뜩 띄워 놓고 일일이 지켜볼 필요 없이 여러 사이트를 동시에 실행할 수 있습니다.

4.10사이트를 온라인에 공개하고 에이전트에게 맡기기

모든 로컬 서버의 세부 정보에는 인터넷 접근 상자가 있습니다. Cloudflare 호스트 이름을 선택하고 내 영역 중 하나에 속한 이름(예: demo.example.com)을 입력하면, FrontierStack이 라우트와 DNS 레코드를 추가하고 cloudflared를 시스템 서비스로 실행하므로 앱을 닫아도, 재부팅한 후에도 주소가 유지됩니다. 첫 사이트에서는 관리자 암호를 한 번 묻습니다. 이후 사이트는 같은 터널을 공유하며 각자 고유한 호스트 이름을 가집니다. 다른 선택지로 임시 링크(trycloudflare.com)와 Tailscale Funnel이 있습니다. Vite와 Django는 보통 알 수 없는 호스트 이름을 거부하므로, Cloudflare 라우트는 대신 localhost를 전달하여 별도 수정 없이 동작하게 합니다.

같은 지구본 버튼이 Apache ▸ 웹 사이트 행(터널이 ServerName으로 Apache에 사이트를 요청)과 카탈로그 서비스, Docker 컨테이너, Vagrant 박스, Spin 앱에도 있습니다.

호스팅 환경설정…(Localhost 패널과 설정 ▸ 웹 사이트 및 호스팅에 있음)에서는 새 사이트를 어디에 둘지 지정합니다. 이 Mac, Apache 사이트, 내 서버 중 하나, here.now, Hostinger, Vercel 또는 ChatGPT Sites 중에서 고를 수 있고, 원한다면 사이트 종류별로 다른 위치를 지정할 수도 있습니다. 또한 새 사이트 이름에 사용할 도메인, 사이트를 만들 폴더, 누가 사이트를 빌드할지, 빌더가 따를 디자인 스킬(SKILL.md가 들어 있는 폴더)도 여기서 지정합니다.

그런 다음 AI 관리자에게 사이트를 요청하십시오(“빵집용 원페이지 사이트, 따뜻한 색감, 영업시간과 지도 포함”). AI 관리자는 한 번에 폴더를 만들고, 사이트 설정이 담긴 .env(암호는 절대 넣지 않음), BRIEF.md, 빌더용 규칙을 담은 AGENTS.md, .claude/skills의 디자인 스킬을 작성하고, 서버를 시작하고, 공개 주소를 부여하고, 첫 git 커밋을 만듭니다. 그런 다음 페이지를 직접 빌드하거나, 격리된 Sandcastle 컨테이너에서 실행되는 Claude Code 또는 Codex에게 작업을 넘깁니다. 이들이 작업을 마치면 파일이 폴더로 다시 복사되고 알림이 표시됩니다. MCP로 연결된 외부 에이전트도 같은 셋업을 요청하고 전달받은 폴더에서 빌드할 수 있습니다.

웹 스택의 품질은 그 아래에 있는 데이터에 달려 있습니다. FrontierStack은 데이터베이스를 일급 서비스로 다룹니다. 데이터베이스를 설치하고 실행하며, 내용을 살펴보고, AI 관리자가 일상 언어로 사이트의 데이터베이스를 점검하고 복구할 수 있게 합니다. 그리고 대부분의 구성에서 빠뜨리는 부분 — 실제로 복원할 수 있는 검증된 일정에 따라 모든 것을 백업합니다. 이 장에서는 관계형 엔진, 인메모리 캐시, 새로운 벡터 및 분석 저장소, 그리고 이 모두를 보호하는 백업 체계를 다룹니다.

5.1MySQL / MariaDB 패널

사이드바의 Databases 섹션에서 MySQL을 여십시오. 서버가 없으면 이 패널이 Homebrew로 설치한 다음, 예전에 Server.app이 제공하던 제어 기능을 보여 줍니다. Start, Stop과 실시간 상태 표시등, 수신 포트(기본값 3306), 그리고 서버에 있는 데이터베이스 목록입니다. MySQL과 호환되는 대체 포크인 MariaDB도 같은 방식으로 관리되며, 패널은 설치된 쪽을 자동으로 인식합니다.

로컬 개발에는 의도적인 규칙이 하나 있습니다. 로컬 root 계정에는 암호가 없습니다. 이는 MAMP/XAMPP의 관례이며, 원클릭 설정과 AI의 SQL 도구가 자격 증명 입력 없이 작동하는 이유이기도 합니다. Mac의 MySQL은 127.0.0.1에서만 수신하고 해당 기기에서만 접근할 수 있으므로 안전합니다. 데이터베이스에 다른 곳에서 접근해야 하는 순간 — 암호가 설정된 계정이나 연결된 서버의 데이터베이스 — 아래에서 설명하는 비밀 값 보관함으로 전환합니다.

5.2Database Ops와 SQL 실행

Database Ops 패널에서는 데이터베이스가 더 이상 블랙박스가 아닙니다. Replication 섹션은 구성된 서버가 MySQL 복제본인지 PostgreSQL 스탠바이인지 감지하고 지연을 표시합니다. MySQL은 SHOW REPLICA STATUS(IO 및 SQL 스레드, Seconds_Behind_Source)를 읽고, PostgreSQL은 pg_is_in_recovery()와 재생 타임스탬프를 사용합니다. 복제가 중지되거나 지연이 임계값을 넘으면 설정한 채널로 알림을 보냅니다. 이것이 Database Slave 모니터링 프리셋의 기반입니다.

데이터를 점검하거나 수정할 때를 위해 AI 관리자에는 run_sql 도구가 있습니다. “이 주문들의 합계가 왜 틀리게 표시됩니까?”, “원본보다 오래된 중복 사용자를 삭제하십시오”처럼 일상 언어로 요청하면, 로컬 서버에 SQL을 실행하고 결과를 표로 보여 줍니다. MAMP의 Claude 통합과 비슷합니다. 문은 데이터를 변경할 수 있으므로 run_sql에는 변경 허용이 필요합니다. 읽기 전용 쿼리는 어시스턴트를 켜는 즉시 작동합니다. 기본적으로 암호 없는 로컬 root를 사용하며 설계상 로컬 전용입니다.

5.3암호가 설정된 데이터베이스와 원격 데이터베이스

로컬 root 지름길은 네트워크가 시작되는 지점에서 정확히 멈춥니다. 암호가 필요한 데이터베이스나 원격 서버 또는 연결된 서버에 있는 데이터베이스의 경우, 암호를 프롬프트나 도구에 붙여넣지 않습니다. 대신 AI 관리자의 Script secrets (.env) 막대에 이름이 붙은 비밀 값(DB_PASSWORD 또는 MYSQL_PWD)으로 한 번 추가합니다. 그러면 어시스턴트가 run_script를 통해 mysql 클라이언트를 실행하면서 값을 $DB_PASSWORD로 참조하고, 지정한 서버에 SSH로 실행합니다. 실제 값은 Mac에 남아 실행 시점에 주입되며, 클라우드 모델은 이름만 볼 뿐 비밀 값은 보지 못합니다.

5.4PostgreSQL

고급 SQL, 풍부한 JSON, 전문 검색 또는 GIS가 필요한 프로젝트에는 Postgres를 여십시오. 이 패널은 PostgreSQL(기본 포트 5432)을 설치하고 실행하며, MySQL과 나란히 같은 시작/중지/상태 제어를 제공합니다. 애플리케이션이나 프레임워크가 PostgreSQL을 요구하면 PostgreSQL을 선택하고, 그렇지 않으면 MySQL/MariaDB가 손쉬운 기본 선택입니다. 두 엔진 모두 뒤에서 설명할 백업 작업과 AI 도구의 일급 대상이며, PostgreSQL은 아래의 여러 특수 저장소의 기반이기도 합니다 — 임베딩용 pgvector, 시계열용 TimescaleDB, Postgres 데이터베이스 위에 즉시 REST API를 제공하는 PostgREST.

5.5Supabase: 로컬 스택, 호스팅 프로젝트, Supabase MCP

Supabase 패널은 세 가지 수준에서 작동합니다. 로컬에서는 supabase CLI를 구동합니다. 프로젝트 폴더를 선택하고, 전체 스택(Postgres, Auth, Storage, Realtime, PostgREST, Edge Functions, Studio)을 Docker에서 Start하고, 서비스 URL과 키를 복사하고, 마이그레이션을 실행하고, SQL 콘솔을 열거나, 로컬 데이터베이스를 Database Ops 백업 작업으로 등록할 수 있습니다. 호스팅 프로젝트의 경우 Supabase 개인 액세스 토큰(Account ▸ Access Tokens)을 Supabase — connection에 저장하십시오. 그러면 FrontierStack이 각 프로젝트의 상태를 표시하고, 프로젝트당 최대 30분에 한 번 Supabase의 보안 및 성능 어드바이저를 실행합니다. 프로젝트 ref를 나열하면 해당 프로젝트만 감시합니다. Alert me when this needs attention을 켜면 프로젝트가 비정상이거나 보안 어드바이저가 ERROR 수준의 결과(예: 행 수준 보안이 없는 공개 테이블)를 보고할 때 알림을 받습니다.

AI Access (Supabase MCP)는 AI 관리자를 Supabase의 공식 MCP 서버에 연결합니다. hosted 대상은 같은 토큰을 사용합니다. 프로젝트 ref를 입력하면 하나의 프로젝트로 제한되고, Allow writes를 끈 상태로 두면 읽기 전용 모드가 유지되며(Supabase는 모든 쿼리를 읽기 전용 Postgres 사용자로 실행하고 무언가를 변경하는 도구를 숨깁니다), 원하는 도구 그룹만 선택하십시오. local 대상은 스택 자체의 /mcp 엔드포인트이며, 보통 http://127.0.0.1:54321/mcp입니다. “내 Supabase 프로젝트에서 RLS가 없는 테이블은 무엇입니까?” 또는 “지난 1시간 동안의 인증 오류를 보여 주십시오”처럼 질문하십시오. 읽기는 바로 실행되며, 마이그레이션, 배포, 프로젝트 변경에는 Allow changes가 필요하고 항상 승인 카드가 표시됩니다. Other MCP clients는 Claude, Cursor 및 유사한 앱용으로 미리 만들어진 구성을 복사하고, MCP Servers에 읽기 전용 Supabase 항목을 추가할 수 있습니다.

5.6Redis와 기타 캐시

세션, 큐, 속도 제한, 핫 패스 캐싱에는 보통 관계형 테이블보다 인메모리 저장소가 적합합니다. FrontierStack은 Caching 카탈로그의 두 가지 표준을 실행합니다. Redis Streams의 기반이기도 한 인메모리 키-값 저장소 Redis(포트 6379)와, 단순한 분산 캐시용 Memcached(포트 11211)입니다. 다른 서비스와 마찬가지로 설치, 시작, 모니터링하십시오. 대부분의 CMS 및 프레임워크 배포는 Redis를 MySQL 또는 PostgreSQL과 함께 사용합니다. 서비스 카탈로그(6장)에 모든 선택지가 나와 있습니다.

5.7벡터 및 분석 데이터베이스

새로운 두 계열의 저장소는 각각 별도의 카탈로그 카테고리를 갖습니다. 벡터 데이터베이스는 검색 증강 생성(RAG)과 시맨틱 검색을 위한 임베딩을 저장합니다. AI 스택(15장)은 이를 통해 모델이 사용자의 문서에 접근할 수 있게 합니다. 분석 데이터베이스는 트랜잭션 읽기/쓰기가 아니라 대규모 데이터 세트에 대한 빠른 집계를 위해 만들어진 컬럼형 또는 시계열 엔진입니다.

엔진	종류	포트
MySQL / MariaDB	관계형	3306
PostgreSQL	관계형	5432
Redis	인메모리 캐시 / 스트림	6379
Memcached	인메모리 캐시	11211
Qdrant	벡터(RAG / 임베딩)	6333
Chroma	벡터(임베딩)	8000
Weaviate	벡터(하이브리드 검색)	8080
Milvus	벡터(분산)	19530
pgvector	벡터(Postgres 확장)	5432
ClickHouse	컬럼형 OLAP 분석	8123
InfluxDB	시계열	8086
TimescaleDB	시계열(Postgres 확장)	5432
Apache Druid	실시간 OLAP	8888

순수하게 프로세스 내부에서 벡터 검색을 하려면 FAISS(라이브러리, 포트 없음)도 있습니다. 프레임워크가 요구하는 엔진을 선택하십시오. 각 패널은 같은 카탈로그 체계를 통해 엔진을 설치하고 실행합니다.

5.8데이터 파이프라인 & ETL

이러한 저장소 사이에서 데이터를 옮기고 재구성하는 일은 그 자체로 하나의 분야입니다. Data Pipelines & ETL 카탈로그 카테고리는 이를 개요 수준에서 다룹니다. 수백 개의 커넥터로 추출·적재를 수행하는 Airbyte와 Meltano, SQL 기반 변환과 모델링을 위한 dbt, 그리고 작업 일정을 관리하는 Dagster, Prefect, Kestra 같은 오케스트레이터가 있습니다. 이들은 완전한 플랫폼입니다. FrontierStack은 이를 설치·실행하고 웹 UI를 제공하지만, 파이프라인 로직은 각 도구 안에 있습니다. 프로그래밍 방식의 데이터 파이프라인 DAG를 위해서는 Workflow Orchestration 카테고리에 Apache Airflow도 있습니다.

5.9백업: 덤프, 개요 패널, CCC

검증된 백업이 없는 데이터베이스는 언젠가 일어날 장애입니다. FrontierStack은 이 문제에 두 방향으로 접근합니다. Database Ops에서 서버별로 검증된 덤프 일정을 정의합니다. 이름, 엔진(MySQL 또는 PostgreSQL), 호스트, 포트, 사용자, 데이터베이스(비워 두면 전체), 백업 디렉터리를 지정합니다. 기한이 된 작업은 앱이 열려 있는 동안 자동으로 실행되며, Run Now로 즉시 실행할 수 있습니다. 각 실행은 단순한 덤프 이상입니다 — mysqldump는 일관된 InnoDB 스냅숏을 위해 --single-transaction으로 실행되고, 이어서 Verify가 gzip 무결성과 덤프가 완료 표시로 끝나는지(잘리거나 절반만 쓰인 파일을 잡아냄)를 확인하고, .md5 사이드카 파일을 쓰고, 보존 개수에 맞춰 순환한 다음, 키 기반 SSH로 결과를 외부 저장소에 rsync합니다.

AI 관리자는 같은 작업을 도구로 제공합니다. db_dump는 데이터베이스를 대상의 .sql 파일로 덤프하고(mysqldump 또는 pg_dump 사용), backup_now는 구성, 사이트 또는 데이터 폴더의 타임스탬프가 붙은 tar.gz를 만듭니다. 둘 다 변경을 가하는 도구이므로 승인과 변경 허용이 필요하며, DB 암호는 붙여넣은 값이 아니라 $NAME 보관함 비밀 값을 참조합니다.

Backups 개요 패널은 모든 체계를 한데 모아 오래된 백업을 한눈에 알아볼 수 있게 합니다. Time Machine 상태, Carbon Copy Cloner 작업, 앱이 관리하는 Apache 구성 스냅숏, Git의 구성 버전 기록, 예약된 자동 내보내기가 표시됩니다. Carbon Copy Cloner 패널은 CCC의 ccc 명령줄 도구를 통해 작업과 기록을 읽고, 필요할 때 작업을 Run할 수 있게 합니다. Time Machine과 CCC는 모두 알림 엔진에 연결됩니다 — 임계값 안에 실행되지 않은 백업이나 실패한 CCC 작업이 있으면 설정한 채널로 알림을 보냅니다(11장).

앱 자체의 설정도 보호됩니다. 사이드바의 고정 항목과 숨긴 서비스, 저장된 셋업, 네트워크 Locations는 macOS 환경설정에만 두지 않고 앱 지원 폴더의 JSON 파일에 보관됩니다. 모든 Git 스냅숏에 환경설정 사본과 함께 포함되며, 환경설정의 시간별 섀도 사본 덕분에 환경설정 파일이 지워져도 다음 실행 시 자동으로 복구됩니다. Config version history의 Restore App Settings…를 사용하면 최신 스냅숏에서 수동으로 복원할 수 있습니다.

5.10복원 — 그리고 복원 안전성

백업은 복원하기 위해 존재하며, 위험한 쪽은 복원입니다. AI의 restore 도구는 .tar.gz 아카이브를 추출하거나 .sql 덤프를 데이터베이스로 가져옵니다. 덤프를 가져오면 운영 중인 데이터베이스를 덮어쓰고 아카이브를 추출하면 파일을 그 자리에서 덮어쓰므로, restore는 변경을 가하며 파괴적일 수 있는 도구입니다. 항상 변경 허용 상태에서 명시적 승인이 필요하며, SQL 가져오기는 DB 암호를 $NAME 보관함 비밀 값으로 참조합니다.

5.11손상된 데이터베이스 복구

데이터베이스가 단순히 중단된 것보다 더 나쁜 상황도 있습니다 — 시작되지 않거나 테이블이 손상된 경우입니다. FrontierStack은 AI 관리자(13장)에게 직접 손으로 사용할 것과 같은 도구를, 평소와 같은 승인 카드 뒤에 제공합니다. mysql_check_tables와 pg_check_tables는 mysqlcheck / pg_amcheck를 실행해 손상되거나 크래시된 테이블을 찾습니다. repair를 켜면 먼저 mysqldump/pg_dump 백업을 만든 다음 복구(--auto-repair / REINDEX)하므로 수정 사항을 되돌릴 수 있습니다. mysql_service_control과 pg_service_control은 systemd, launchd, Homebrew 또는 service(8)를 통해 로컬이나 SSH로 서버를 시작, 중지, 재시작하거나 상태를 확인합니다.

어려운 경우를 위해 안내형 스킬인 “Recover Broken MySQL”과 “Recover Broken PostgreSQL”이 있습니다. 이 스킬은 전체 런북을 단계별로 진행합니다. 오류 로그를 읽고, 결함을 진단하고, 읽을 수 있는 모든 데이터를 덤프하고, 새 데이터 디렉터리에 다시 구축하고, 손상된 테이블을 복구하거나 다시 만든 다음, 재시작합니다 — 기존 데이터 디렉터리는 삭제하지 않고 항상 이름을 바꿔 콜드 백업으로 남겨 두며, 파괴적인 단계마다 사전에 확인합니다. 원격 호스트에서 가장 빠르게 시작하는 방법은 서버 패널의 데이터베이스 행에 있는 빨간색 Emergency 버튼입니다. 해당 호스트에 맞는 복구 스킬이 미리 로드된 상태로 어시스턴트가 열립니다.

5.12ORM과 앱 네이티브 도구: Drizzle과 Convex

마지막으로, 애플리케이션이 스키마를 정의하는 곳에서 바로 작동하는 두 가지 도구가 있습니다. Drizzle ORM 패널은 Drizzle 프로젝트(테이블, 마이그레이션, 백엔드 방언)를 감지하고 drizzle-kit 작업을 대신 실행합니다 — 스키마에서 SQL을 Generate하고, Migrate하고, 스키마를 직접 Push하고, 기존 데이터베이스를 Pull(인트로스펙션)하며, Drizzle Studio를 열어 데이터를 살펴볼 수 있습니다. Convex 패널은 데이터베이스가 내장된 반응형 백엔드인 Convex를 관리합니다. npx convex dev를 실행해 함수를 감시하고 푸시하거나, Docker에서 자체 호스팅 백엔드를 구동할 수 있습니다. 둘 다 Node.js가 필요하며, 없으면 패널이 Homebrew로 설치합니다. 이 도구들은 애플리케이션 자체의 데이터 계층을 다루며, 그 아래에 기록되는 내용은 여전히 앞에서 설명한 덤프와 백업이 보호합니다.

FrontierStack은 114개 카테고리에 걸친 1795개 이상의 서비스 카탈로그를 제공합니다. 모든 항목은 앱에서 검색, 설치, 시작, 설정, 모니터링할 수 있으며, AI 관리자는 그중 어느 것이든 다룰 수 있습니다. 이 장은 현장 안내서입니다. 각 카테고리와 그 안의 서비스, 그리고 모든 서비스의 한 줄 설명을 담았습니다. 서비스 설명은 앱의 레이블과 일치하도록 영어로 두었습니다.

각 서비스에는 웹사이트의 frontierstack.app/services/에 포트, 기본 웹 UI, Homebrew 포뮬러를 담은 전용 페이지도 있습니다.

6.1Overview

6.2Setup & Migration

6.3Locations & Places

6.4Fleet & Remote

6.5Networking

6.6VPN

6.7Routers & Firewalls

6.8Web Servers

6.9DNS

6.10Runtimes

6.11Databases

6.12Vector Databases

6.13Analytics Databases

6.14Data Pipelines & ETL

6.15Caching

6.16Search

6.17Backup

6.18Storage & NAS

6.19Object Storage & S3-Compatible

6.20Mail

6.21Mailing Lists

6.22Email Deliverability & Reputation

6.23Message Queues & Streaming

6.24Push Services

6.25Chat & Collaboration

6.26SMS & iMessage Gateways

6.27Business Messaging

6.28Calendars

6.29Identity & Accounts

6.30Customer Identity

6.31Decentralized Identity

6.32Version Control

6.33CI/CD

6.34Build & Compile

6.35Internal Developer Portals

6.36Infrastructure as Code

6.37API Testing & Synthetic Monitoring

6.38Proxies & Load Balancers

6.39Proxy Gateways

6.40CDN & Edge

6.41Hosting

6.42AWS Control

6.43AI / LLMs

6.44AI Clusters

6.45Agent Platforms

6.46FinOps & Cloud Cost

6.47Containers

6.48Service Mesh (Kubernetes)

6.49Apps & CMS

6.50Knowledge & Memory

6.51E-Commerce

6.52QR & Link Management

6.53Student Information Systems

6.54Learning Management

6.55Digital Library

6.56Campus & School Ops

6.57Sourcing & Suppliers

6.58Print-on-Demand

6.59Shipping & Fulfilment

6.60Inventory Sync

6.61Profit Analytics

6.62Mesh Networking

6.63Anonymity Networks

6.64Secrets & Vaults

6.65Monitoring

6.66Security Tools

6.67SIEM & Security Data

6.68Secrets Scanning & Supply Chain Security

6.69Policy, Compliance & Governance

6.70MDM & Device Management

6.71Logging & Observability

6.72Incident Management & On-Call

6.73Status Pages

6.74Mining

6.75ML Workbench

6.76AI Governance & Safety

6.77GPU Infrastructure

6.78Speech AI

6.79Image & Video AI

6.80MCP

6.81Self-Hosted Apps

6.82Web3

6.83Crypto

6.84RPC Services

6.85Tools

6.86Home Automation

6.87Cameras

6.88IoT

6.89MQTT Brokers

6.90POS Systems

6.91CRM & Loyalty

6.92Helpdesk & Ticketing

6.93IT Assets

6.94Project Management

6.95PMS

6.96Meeting Rooms & Desk Booking

6.97Coworking & Shared Spaces

6.98Facilities & Maintenance

6.99Accounting & ERP

6.100E-Signature

6.101Healthcare

6.102Automation & Workflows

6.103Workflow Orchestration

6.104HRIS Integration

6.105VoIP & Telephony

6.106Contact Centre & IVR

6.107SEO & Marketing

6.108Conversion Rate Optimization

6.109Social Media

6.110Media Servers

6.111Download Automation

6.112AV & Stage

6.113Render Farm

6.114Tracking & Telematics

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

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

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

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

점검 항목	측정 방법	문제가 있을 때의 모습
DNS	호스트 이름에 대한 실제 리졸버 조회(host/dig)와 반환된 IP.	레코드가 없거나, 내 서버가 아닌 주소.
HTTP	상태 코드를 기록하는 실시간 요청(curl -w %{http_code}).	200–399 범위를 벗어난 모든 응답(404, 502, 리디렉션 루프 등).
SSL / TLS	TLS 핸드셰이크로 인증서 만료일을 읽습니다(openssl s_client → x509 -enddate). 배지에는 남은 일수가 표시됩니다.	만료됨, 곧 만료됨, 또는 이름 불일치.
HTTP/3	서버가 Alt-Svc 헤더로 HTTP/3를 알리면 청록색 배지가 표시됩니다. Apache에는 자체 HTTP/3 기능이 없으므로, Apache 사이트에서 이 배지를 얻는 일반적인 방법은 해당 도메인의 Cloudflare 영역 패널에 있는 HTTP/3 토글입니다(브라우저는 엣지와 QUIC으로 통신하고 오리진은 h1/h2를 유지합니다). HTTP/3는 UDP 443을 사용한다는 점을 기억하십시오. TCP만 허용하는 방화벽에서는 브라우저가 아무 표시 없이 HTTP/2로 대체합니다.	h3를 제공할 것으로 예상한 사이트에 배지가 없음. 엣지 설정이 꺼져 있거나 UDP 443이 차단된 경우입니다.
Cloudflare	토큰으로 가져온 영역 상태와 플랜. 예: active · Pro.	등록 기관에서 네임서버를 변경하지 않아 “pending” 상태인 영역.
서비스 호스트	응답한 IP와 Server 헤더로 판단합니다.	원격 서버를 예상했는데 “This Mac (Apache)”로 표시되거나, “Cloudflare”가 오리진을 가리고 있는 경우.

스크린샷 추가 예정

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일간 경험한 내용을 보고합니다:

지표	측정 대상	양호
LCP	Largest Contentful Paint — 주요 콘텐츠가 나타나는 시점	≤ 2.5 s
INP	Interaction to Next Paint — 페이지가 입력에 반응하는 속도	≤ 200 ms
CLS	Cumulative Layout Shift — 레이아웃이 얼마나 흔들리는지	≤ 0.1
FCP · TTFB	첫 렌더링과 서버 응답 시간(참고용으로 표시)	—

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

지금까지는 눈앞에 있는 Mac에 관한 내용이었습니다. 매뉴얼의 이 부분에서는 시야를 관리 대상 전체로 넓힙니다. 랙에 설치된 Linux 서버, 아직 macOS Server를 실행 중인 오래된 Xserve, 선반 위의 Raspberry Pi, 클라우드 VPS, 심지어 Windows 호스트까지 포함됩니다. 각 서버는 SSH로 한 번만 연결하면 되며, 그 이후 FrontierStack은 이들을 하나의 플릿으로 취급하여 진단을 실행하고, 명령을 여러 서버에 일괄 실행하고, 사이트를 배포하고, 상태를 감시합니다. 또한 이 Mac이 네트워크상 어디에 있는지도 추적하므로, 집과 사무실, 카페를 오가는 노트북이 지금 단지 보이지 않을 뿐인 서버에 대해 잘못된 경보를 울리지 않습니다.

이 장에서는 플릿의 연결과 운용을 다룹니다. 네트워크와 경계 보안은 9장, 보안 강화와 보안 감사는 10장, 지속적인 모니터링과 알림은 11장에서 더 자세히 다룹니다. AI 관리자는 같은 도구를 사용하여 여기 나오는 거의 모든 작업을 수행할 수 있습니다. 13장을 참조하십시오.

8.1위치 및 장소

위치 및 장소 ▸ 위치를 여십시오. 위치는 단순히 이름이 붙은 네트워크(집, 사무실, VPN 연결 중 등)이며, 여러 신호로 인식됩니다. Wi-Fi SSID, 라우터(게이트웨이) MAC 주소, Wi-Fi BSSID, IP 주소의 서브넷 접두사(예: 192.168.1.), 공인 IP 대역, 그리고 VPN 연결 여부입니다. 헤더에는 현재 위치(현재: 사무실)가 표시되고, 그 아래에 Wi-Fi 이름, IP, 게이트웨이, VPN 상태로 구성된 실시간 스냅샷이 표시됩니다. 감지는 30초마다 실행됩니다.

FrontierStack이 인식하지 못하는 네트워크를 발견하면 새 네트워크가 감지됨 배너를 표시합니다. 추가…를 클릭하여 저장하십시오. 현재 네트워크를 위치로 추가를 누른 다음 조건을 세부 조정할 수도 있습니다. 위치는 설정된 조건이 모두 충족될 때 일치하며(SSID와 라우터 MAC은 그중 하나만 일치하면 됨), 비워 둔 필드는 무시됩니다. 여러 위치가 일치하면 목록의 첫 번째 항목이 아니라 가장 구체적인 위치가 선택됩니다. 자동 감지 대신 위치를 수동으로 고정하려면 모드 선택기를 사용하십시오. 신호가 모호할 때 유용합니다.

모든 신호의 신뢰도가 같지는 않으며, 이는 생각보다 중요합니다. 서브넷 접두사는 식별자가 아닙니다. 가정용 라우터, 카페, 호텔은 어디서나 192.168.1.× 주소를 할당하므로, 서브넷만으로 정의된 위치는 전혀 다른 건물에서도 그대로 일치해 버립니다. 라우터 MAC은 가장 강력한 신호입니다. 하나의 하드웨어에 고유하며 특별한 권한 없이 읽을 수 있습니다. 그래서 라우터 일치 기능이 생기기 전에 저장된 위치는 현재 네트워크에서 모든 조건 업데이트를 클릭 한 번으로 바로잡을 수 있습니다.

8.18.1GPS로 장소 고정

두 장소가 실제로 같은 서브넷을 사용하고 MAC 주소를 일일이 다루고 싶지 않은 까다로운 경우에는 위치에 GPS 핀을 추가할 수도 있습니다. 해당 장소에서 위치를 열고 이 지점 고정(GPS)을 누르십시오. 반경 슬라이더로 어디까지를 “여기”로 볼지 설정합니다(기본값 150 m. 실내 측위는 정밀하지 않고, 장소는 점이 아니라 건물이기 때문입니다).

핀은 필수 조건이 아니라 교차 확인용입니다. 핀은 두 가지 역할을 합니다. 약한 일치를 확인해 주고, 더 유용하게는 잘못된 일치를 거부합니다. 따라서 집이 우연히 같은 서브넷을 쓰는 카페를 자기 위치라고 주장하지 않게 됩니다. 이 기능이 감지를 결코 악화시키지 않도록, 공유될 수 있는 조건(서브넷, VPN 연결 여부)만으로 식별된 위치는 현재 위치 정보가 있고 그것과 모순될 경우 더 이상 확인됨으로 보고되지 않습니다. 확신에 찬 잘못된 답 대신 외부 / 알 수 없음이 표시됩니다.

기기도 위치에 속합니다. 기기 검색에서 모니터링 중인 기기의 ⋯ 메뉴 ▸ 위치에 할당을 선택하면 특정 장소에 배치됩니다. 자동으로 두면 해당 서브넷을 소유한 위치에 자동으로 속하게 됩니다. 기기 자체의 패널에서도 설정할 수 있으며, 각 위치의 행에는 해당 위치에 할당된 기기가 나열됩니다. 사설 서브넷은 장소마다 반복되므로, 다른 곳에 고정된 기기가 서브넷에 의해 어떤 위치에 들어갈 수 있습니다. 그 목록에서 기기의 ×를 누르거나 위치 없음을 선택하면 제거되며, 일치하는 서브넷이 있어도 다시 추가되지 않습니다. Mac이 인식된 위치에 도착하면 FrontierStack은 해당 기기들을 확인하고(VPN 등을 통해 최근에 확인된 기기는 건너뜀) 각각의 상태를 표시합니다. 녹색은 연결 가능, 빨간색은 이곳에 있어야 하지만 응답이 없음, 주황색은 이 Mac이 도달할 수 없는 Wi-Fi 구간에 있음을 뜻합니다. 주황색은 대개 다른 액세스 포인트나 대역에 있는 경우로, 예를 들어 Mac은 5 GHz에 연결되어 있는데 센서는 2.4 GHz 전용인 경우입니다. 주황색은 “사라짐”이 아니라 “여기서는 확인할 수 없음”을 의미합니다.

이 모든 것의 목적은 위치 기반 모니터링 섹션입니다. 개요 ▸ 알림에서 기기, Wi-Fi 네트워크, Cloudflare 영역 또는 감시 항목을 중요 항목으로 표시한 다음, 여기에서 범위를 사무실에서만으로 지정하십시오. 그러면 그 검사는 다른 모든 곳에서 일시 중지됩니다. 호텔에 있을 때 NAS가 DOWN으로 울리지 않고, 회사에 있을 때 집 Wi-Fi가 끊겼다는 알림도 오지 않습니다. 일시 중지된 항목은 돌아오면 조용히 재개됩니다. 위치 자체가 바뀌면 FrontierStack은 로컬 알림을 게시하거나, 메시징 게이트웨이를 통해 “📍 현재 위치: 사무실” 알림을 보내거나, 둘 다 할 수 있습니다.

스크린샷 추가 예정

8.2SSH로 서버 연결

서버는 서버 연결 시트를 통해 플릿에 합류합니다. 이 시트는 기기 패널, 기기 검색, 또는 클라우드 서버 및 원격 도구 패널에서 열 수 있습니다. 이름, 호스트 또는 IP, 포트, SSH 사용자 이름(root, ubuntu, ec2-user…), 로그인 암호를 입력하십시오. 이 암호는 단 한 번만 사용됩니다. 앱은 이 Mac의 관리형 SSH 키를 서버의 authorized_keys에 설치하고, 그 이후로는 키로만 연결합니다. 서버 주소 외에는 아무것도 저장되지 않으며, 암호는 폐기됩니다.

암호 로그인이 없는 키 전용 서버의 경우 암호를 사용할 수 없습니까? 키를 수동으로 설치를 펼치고, 표시된 공개 키를 서버의 authorized_keys에 직접 복사한 다음 연결하십시오. 모니터링 헬퍼도 설치를 선택하면 같은 단계에서 호스트 모니터도 설정됩니다(아래에서 설명).

Windows 서버와 Tailscale 서버. OpenSSH를 실행하는 Windows PC도 같은 방법으로 연결됩니다. FrontierStack은 Windows 셸을 감지하고 PowerShell로 키를 설치합니다. 관리자 계정이면 C:\ProgramData\ssh\administrators_authorized_keys에(sshd가 요구하는 권한으로), 그렇지 않으면 사용자의 .ssh\authorized_keys에 설치합니다. 서버의 SSH 호스트 키는 FrontierStack 자체의 신뢰 저장소에 기록되므로, ~/.ssh/config가 일부 주소의 호스트 키를 버리도록 설정되어 있어도 연결할 수 있습니다(Tailscale용으로 UserKnownHostsFile /dev/null을 지정한 Host 100.* 규칙이 흔히 쓰입니다).

연결된 서버에는 연결 가능 여부를 나타내는 작은 녹색 또는 빨간색 상태 점이 표시됩니다. 서버를 재설치한 뒤나 키가 처음부터 설치되지 않은 경우처럼, 점이 빨간색으로 바뀌고 Permission denied (publickey)가 표시되면 AI 도구 repair_ssh_access가 오래된 호스트 키를 지우고 관리형 키를 다시 설치합니다. 이때 보관함 비밀 값으로 보관해 둔 일회용 로그인 암호를 사용합니다. 암호는 로컬에서 읽혀 키 접근을 다시 설치하는 데 쓰이며, 성공하면 점이 다시 녹색으로 바뀝니다.

호스트의 상태 섹션에는 연결 행도 표시됩니다. 서버의 기본 경로를 실제로 담당하는 연결을 보여 줍니다. 협상된 Ethernet 속도(10 GbE, 2.5 GbE, 1 GbE), 채널 폭을 포함한 Wi-Fi 세대(Wi-Fi 7 = 802.11be, Wi-Fi 6E/6/5), 또는 VPN 터널입니다. Linux, macOS, FreeBSD 호스트에서는 일반 상태 점검 중에 읽히고, 에이전트 전용 호스트에서는 호스트 모니터 에이전트(v1.17 이상)가 보고합니다. 이 Mac에도 같은 행이 표시되며, SNMP 기기에서는 인터페이스 조회 시 각 포트의 협상된 링크 속도가 나열됩니다.

각 서버에는 대화형 셸을 위한 연결 방식 설정(편집 시트에 있음)도 있습니다. 일반 SSH(기본값), mosh(SSH 설정으로 로그인한 다음 자체 UDP 전송으로 전환하므로, 잠자기, 네트워크 이동, 불안정한 연결에도 세션이 유지됩니다), 또는 실험적인 SSH3(QUIC/HTTP3 기반이며, 서버를 UDP 443의 비밀 URL 뒤에 숨길 수 있습니다) 중에서 선택할 수 있습니다. 셸 열기와 SSH 열기는 이 선택을 따르며, 상태 점검과 파일 전송은 항상 일반 SSH를 사용합니다. 두 클라이언트 모두 서비스 카탈로그에 있습니다(mosh는 Homebrew, SSH3는 Go로 설치).

8.3관리형 키와 저장된 sudo 암호

키 접근으로 앱은 서버에 연결할 수 있지만, /var/log 읽기, Apache 구성 편집, 방화벽 다시 로드 같은 유용한 작업의 상당수는 서버의 root 권한이 필요합니다. FrontierStack은 이를 호스트별 sudo 암호로 처리하며, 이 암호는 macOS 키체인에 저장됩니다(일반 파일에는 절대 저장되지 않음). 서버를 연결할 때 자동으로 저장되며, 나중에 호스트 패널이나 원격 도구의 대상 섹션(Sudo 암호 필드)에서 설정하거나 변경할 수 있습니다.

root 전용 명령이 실행되면 헬퍼는 SSH 세션을 통해 저장된 암호로 sudo의 자격 증명 캐시를 미리 채운 다음 명령을 실행합니다. 저장된 암호가 없으면 root 작업은 암호 없는 sudo -n으로 대체되며, 그것이 설정되어 있지 않으면 단순히 “sudo 필요”라고 보고합니다. 비밀 값은 이름으로 참조되므로 여러 개를 보관할 수 있습니다. 예를 들어 .env 보관함에 서버마다 다른 MySQL 암호를 둘 수 있습니다.

8.4플릿 실행: 모든 노드에서 명령 하나 실행

플릿 및 원격 ▸ 플릿 실행은 하나의 작업을 연결된 모든 서버 또는 선택한 일부 서버에 동시에 실행하고, 호스트별 결과를 실시간으로 보여 줍니다. 대상을 선택하고(호스트를 켜고 끄며, 연결 가능 여부 점으로 어느 호스트가 작동 중인지 확인), 작업을 고른 다음 N대 서버에서 실행을 누르십시오. 모든 작업이 SSH를 통해 동시에 실행되고, 각 호스트의 결과가 아래에 표시되며 펼치면 전체 출력을 볼 수 있습니다.

작업은 OS를 인식합니다. 패키지 업데이트는 호스트에 따라 apt, dnf, pacman, zypper, apk 또는 brew로 매핑되고, 서비스 재시작은 systemd를 먼저 시도한 다음 Homebrew를 시도합니다. OS별 명령을 직접 작성할 필요가 없습니다.

작업	플릿 전체에서 수행하는 일
모든 패키지 업데이트 / 업그레이드	호스트 패키지 관리자의 update + upgrade를 실행합니다. 일괄 실행 전에 확인을 거칩니다.
패키지 설치	지정한 패키지(예: htop)를 선택한 모든 호스트에 설치합니다.
서비스 재시작	지정한 유닛(예: nginx)을 systemd 또는 brew로 재시작합니다.
재부팅 필요 여부 확인	업데이트 후 재부팅을 기다리는 호스트를 보고합니다.
디스크 사용량(df)	플릿 전체에서 df를 한 번 실행하여 가득 차 가는 디스크를 찾아냅니다.
가동 시간 및 부하	호스트별 가동 시간과 평균 부하를 표시합니다.
저장소 git pull	각 호스트의 지정한 경로에서 저장소를 pull합니다. 간단한 배포 방법입니다.
사용자 지정 명령	선택한 모든 호스트에서 셸 명령을 그대로 실행합니다. 일괄 실행하기 전에 다시 확인하십시오.

플릿 실행은 구성 편차를 찾아내는 가장 빠른 방법입니다. 디스크 사용량이나 가동 시간 및 부하를 실행하여 호스트를 한눈에 비교하거나, 원격 도구(다음 절)의 파일 체크섬 및 상태 검사 도구를 사용하여 플릿 전체에서 달라진 구성을 찾으십시오.

8.5이 Mac 또는 서버에서 컨테이너 만들기

FrontierStack에서 컨테이너를 나열하는 곳에는 모두 Create Container… 버튼이 있으며, 어느 곳에서 누르든 같은 시트가 열립니다. 이 Mac의 Docker 패널, 호스트 선택기에서 연결된 서버를 고른 같은 패널, 그리고 서버 활동 윈도우의 Docker 탭이 그렇습니다. 만든 컨테이너는 시작한 곳의 대상에서 실행됩니다 — 로컬에서는 docker 바이너리를 통해, 서버에서는 이미 갖고 있는 SSH 연결을 통해 실행됩니다.

프리셋에서 시작하거나 빈 상태에서 시작하십시오. 프리셋에는 일반 이미지 — nginx, PostgreSQL, MySQL, Redis, 일회용 Ubuntu 셸 — 와 함께, n8n, Flowise, Langflow, Vaultwarden, Checkmk처럼 앱이 단일 컨테이너로 실행할 수 있는 모든 자체 호스팅 서비스가 포함됩니다. 하나를 선택하면 이미지, 포트, 볼륨, 환경 변수가 채워지며 모두 변경할 수 있습니다. docker-compose 스택이 필요한 서비스는 대신 이 Mac의 해당 서비스 패널에서 설치하며, 시트에 그 이름이 표시되므로 빠진 것처럼 보이지 않습니다.

필드	역할
Image	이미지 참조입니다. 대상에 이미 있는 이미지를 메뉴에서 고를 수 있습니다.
Name	선택 사항이며, 대상에서 이미 사용 중인 이름과 겹치는지 확인합니다.
Published ports	각 포트에는 127.0.0.1에 바인딩하는 This machine only 스위치가 있어, 명시하지 않는 한 포트가 네트워크에 노출되지 않습니다.
Volumes	일반 이름은 Docker가 관리하는 볼륨이고, /로 시작하는 경로는 대상의 폴더입니다.
Environment	어떤 변수든 비밀 값으로 표시할 수 있으며, 그러면 암호처럼 입력되고 미리 보기에서 숨겨집니다.
Advanced	재시작 정책, 네트워크, 명령 재정의, 추가 Docker 인수, 백그라운드 실행 여부입니다.

실제로 실행하기 전에 시트는 비밀 값을 점으로 가린 정확한 docker run 명령줄을 보여 주며, 이를 복사할 수 있습니다. 만들기를 실행하면 먼저 이미지를 가져온 다음(이 동작을 끄지 않은 경우) 실행하고, 출력을 시트에 실시간으로 표시합니다.

8.18.2모니터로서의 Containers 보드

Containers 패널은 단순한 목록이 아닙니다. 이 Mac의 모든 런타임을 하나의 판정으로 모은 상태 점이 있어, 사이드바를 한 번 보는 것만으로 주의가 필요한 것이 있는지 알 수 있습니다. 녹색은 설치된 모든 것이 정상이라는 뜻이고, 주황색은 무언가가 중지되었거나 아직 확인 중이라는 뜻이며, 빨간색은 설치된 엔진이 다운되었거나 컨테이너가 비정상, 재시작 반복 중이거나 오류로 종료되었다는 뜻입니다. 설치한 적이 없는 런타임은 문제로 보지 않습니다 — 따라서 녹색은 “모든 것이 실행 중”이 아니라 “존재하는 모든 것이 정상”이라는 의미입니다.

섹션은 서비스 목록과 같은 순서를 따릅니다. Apple Containers, Docker, Kubernetes, OrbStack, 컨테이너 머신, 그리고 Vagrant 순입니다. Kubernetes는 여기서 읽기 전용으로 표시되며, Kubernetes Clusters에서 고정한 클러스터를 보여 줍니다. 고정과 클러스터별 작업은 그 패널에서 하며, 그 패널은 이 Mac에 있는 것만이 아니라 어디서 실행되든 클러스터 전체를 감시합니다. 런타임이 설치되어 있지 않으면 버튼은 다운로드 페이지로 보내는 대신 해당 런타임을 설치하는 패널을 엽니다.

헤더의 고정 버튼은 작은 플로팅 팔레트를 엽니다. 전체 상태 점과 실행 중인 개수를 보여 주는 상태 막대 하나 아래에 실행 중인 항목의 짧은 목록이 있고, 설정되었지만 유휴 상태인 항목은 Waiting 아래에 묶입니다. 일부러 아주 작게 만들었습니다 — 다른 작업을 하는 동안 화면 구석에 놓아두기 위한 것입니다. 행을 클릭하면 메인 윈도우가 해당 항목으로 이동합니다.

8.18.3Docker Swarm

Swarm은 별도로 설치하는 제품이 아니라 Docker 엔진에 내장되어 있습니다. 그래서 FrontierStack은 Swarm에 별도의 패널을 두지 않고 Docker 패널에서 모니터링합니다. 보고 있는 엔진이 스웜에 속해 있으면 Docker Swarm 섹션이 나타나, 클러스터의 노드(준비 또는 다운, 드레인 중인지 여부, 어느 노드가 매니저인지)와 서비스 및 그 복제본 수를 나열합니다 — 서비스가 요청한 모든 태스크를 갖추면 3/3, 그렇지 않으면 1/3처럼 표시됩니다. 서버 활동 윈도우의 Docker 탭에도 같은 내용이 Swarm 세그먼트로 있어, 어느 연결된 서버에서든 클러스터를 확인할 수 있습니다.

상태는 docker info에서 가져옵니다. 패널이 엔진 상태 확인을 위해 이미 호출하는 명령이므로, 스웜에 속하지 않은 머신은 확인에 추가 비용이 들지 않습니다. Swarm의 규칙 하나가 표시되는 내용을 좌우합니다. 클러스터를 나열할 수 있는 것은 매니저뿐입니다. 워커에 요청하면 데몬이 거부하므로, 워커에서는 FrontierStack이 실패처럼 보이는 빈 표 대신 그 사실을 분명히 알려 줍니다.

8.18.4미리 구성된 스택

어떤 것은 컨테이너 하나가 아니라, 따로 떼어 놓으면 쓸모없는 여러 컨테이너로 이루어집니다. Containers 패널과 서버 활동 윈도우의 Docker 탭에 있는 Install Stack…은 그룹 전체를 한 번에 설정합니다. 앱에는 네 가지가 포함되어 있습니다. *arr 미디어 스택(다른 앱이 읽는 인덱서 목록을 보관하는 Prowlarr, 시리즈용 Sonarr, 영화용 Radarr, 음악용 Lidarr, 도서용 Readarr, 자막용 Bazarr, 그리고 다운로드 클라이언트), Monitoring(Prometheus, Grafana, node-exporter), Media server(Jellyfin, 요청 관리를 위한 Jellyseerr 선택 가능), 그리고 서버, 머신 러닝, Redis, PostgreSQL의 네 컨테이너가 실제로 필요한 자체 호스팅 사진 라이브러리 Immich입니다.

포함할 구성원, 설정 폴더와 미디어 폴더의 위치, 컨테이너가 파일을 기록할 때 사용할 사용자와 그룹, 그리고 이미 수신 대기 중인 것과 겹치지 않도록 스택 전체를 옮기는 포트 오프셋을 선택합니다. 공개 포트는 따로 지정하지 않는 한 127.0.0.1에 바인딩됩니다. 그런 다음 FrontierStack은 프로젝트 폴더에 docker-compose.yml을 작성하고 docker compose up -d를 실행합니다. 스택을 스택답게 만드는 것이 Compose입니다. 구성원들은 네트워크를 공유하고 서로를 이름으로 부르므로, Sonarr의 인덱서 설정을 그냥 http://prowlarr:9696으로 지정할 수 있습니다.

8.18.5Apple 컨테이너와 권장 GUI

Apple 실리콘에서는 macOS가 Apple의 자체 container 명령으로 Linux 컨테이너를 기본 실행할 수 있으며, 각 컨테이너는 하나의 큰 Linux VM을 공유하는 대신 자체 경량 가상 머신을 갖습니다. Containers 패널에는 이를 위한 Apple Containers 섹션이 있습니다. 실행 중인 항목을 나열하고, 컨테이너 시스템을 시작 및 중지하고, 이미지를 가져오고, 새 컨테이너를 만들며, 구성은 위의 Docker 섹션과 같습니다. Apple의 도구는 명령줄 프로그램이며, FrontierStack은 GitHub 릴리스에서 이를 설치합니다.

Apple 컨테이너를 일상적으로 다룰 때는 Davit을 권장합니다. 같은 container 명령에 제대로 된 그래픽 프런트엔드를 제공하는 독립 macOS 앱으로, 하위 명령을 기억하지 않고도 컨테이너와 이미지를 살펴보고, 시작 및 중지하고, 로그를 따라볼 수 있습니다. Apple Containers 섹션에서 Homebrew cask로 설치한 뒤 바로 열 수 있습니다. Davit에는 Apple 실리콘과 macOS 15 이상이 필요합니다.

8.6Remote Tools — 노드별 진단

Fleet & Remote ▸ Remote Tools는 실제 플릿 디버깅 작업에서 추려 낸 SSH 기반 진단 도구 모음입니다. 먼저 대상을 선택하십시오 — 고정된 서버, 또는 저장된 서버가 아닌 임시 주소를 위한 Other (IP / host)…(이 경우에도 sudo 암호가 키체인에 보존됩니다) — 그다음 도구와 매개변수를 선택합니다. 읽기 전용 검사는 root 권한이 필요 없고, 보호된 로그나 설정을 읽는 검사는 헬퍼를 통해 저장된 sudo 암호를 사용하며, 일부는 mutating(변경 작업)으로 표시됩니다.

도구	용도
Ping · Traceroute · Whois	기본 도달성, 경로, 등록 정보 조회를 선택한 노드에서 실행합니다.
Net Info · Netstat	인터페이스와 주소, 라우팅 테이블, 인터페이스/프로토콜 통계, 활성 소켓.
Port Scan · Port Check · Web Check	범위 스캔, 단일 포트 테스트, 또는 HTTP/HTTPS 엔드포인트를 가져와 상태를 보고합니다.
TLS Inspect · TLS Expiry	인증서를 검사하고, 선택한 여러 노드의 만료일을 한 번에 확인합니다.
System Resources · Listening Ports	노드의 부하, 메모리, 디스크, 그리고 수신 대기 중인 항목(선택적으로 sudo 사용).
Tail Log · Config Test	임의의 로그 경로를 tail하고, 웹 서버 설정을 검증합니다.
File Diff · Healthcheck	여러 노드 간 파일 내용을 비교하고(드리프트), 각 노드에서 루프백으로 가상 호스트의 경로에 요청을 보냅니다.
rsync Deploy	로컬 폴더를 원격 경로로 푸시합니다 — 드라이런 미리 보기와 선택적 --delete 포함.
Security · SSH · Exposure · Auth · User audits	임의의 노드나 임시 IP에 대한 읽기 전용 감사(10장 참조).
Flush DNS · Restart Backend	리졸버 캐시를 비우고, macOS Server 웹 백엔드를 재시작합니다(변경 작업 — 사이트가 잠시 끊깁니다).

일부 도구는 선택한 여러 노드에서 한 번에 동작합니다 — File Diff, Healthcheck, TLS Expiry, Serving Path Diagnosis(어느 노드가 살아 있는지, 각 노드가 어떤 공인 IP에 바인딩하는지, 프로세스별 CPU 포화 상태와 중지된 서비스를 고정된 모든 Cloudflare 영역의 오리진 IP와 대조)는 설계상 플릿 전체를 대상으로 합니다 — 모든 웹 노드가 유효한 인증서로 같은 콘텐츠를 제공하는지 확인하는 방법이 바로 이것입니다. 패널 하단에서는 /etc/hosts(헬퍼를 통한 root 권한)와 SSH 사용자의 ~/.ssh/known_hosts를 SSH로 안전하게 편집할 수도 있으며, 각각 먼저 .fsbak으로 백업됩니다.

8.7멈춘 서버 복구 — 그리고 SSH 없이 안전하게 전원 재설정하기

서버는 서비스는 계속 실행되는 상태에서 SSH에만 응답하지 않을 수 있습니다 — 다운된 것이 아니라 과부하 상태입니다. FrontierStack은 이를 표시합니다. SSH에는 연결할 수 없지만 서비스 포트(예: 3306의 MySQL)가 여전히 응답하면, 서버의 점은 빨간색이 아닌 주황색이 되고 패널에 "SSH가 멈췄지만 서버는 여전히 서비스 중입니다"라고 표시되며, 응답 중인 항목이 데이터베이스의 버전 배너와 함께 나열됩니다. 머신은 살아 있고 관리 채널만 멈춘 것이므로, 죽었다고 단정하거나 무작정 전원을 끊지 마십시오.

먼저 일반 Reboot를 시도하십시오. Reboot 후에는 FrontierStack이 유예 시간을 기다린 다음 폴링하는 동안 점이 깜박이며, 호스트가 돌아오는 즉시 새로 고침됩니다 — Refresh를 계속 누를 필요가 없습니다.

SSH 없이 전원 재설정을 안전하게 만드십시오. 데이터베이스가 여전히 응답하면 패널에 빨간 테두리의 EMERGENCY 상자, Prepare databases for a safe power reset이 표시됩니다. 각 단계는 데이터베이스 상태에 저장된 자격 증명을 사용해 데이터베이스 자체 연결(SSH 아님)로 위에서 아래로 실행됩니다. Stop accepting writes(읽기는 계속 가능, 되돌릴 수 있음), Quiesce & flush to disk, 그리고 Clean-shutdown입니다. 정상 종료 후에는 메모리에 손상될 수 있는 미기록 데이터가 남아 있지 않으므로 강제 전원 재투입이 안전합니다. 지원 범위는 엔진마다 다릅니다 — MySQL, Redis, MongoDB는 각 프로토콜로 정상 중지할 수 있고, PostgreSQL은 SQL로 정지 및 플러시할 수 있지만 중지할 수는 없으므로 플러시한 뒤 전원을 재투입합니다. 정상 종료 버튼은 빨간색이며 먼저 확인을 요청합니다.

전원을 재투입한 다음 되살리십시오. 하드웨어 전원 제어(SwitchBot 플러그, 스마트 멀티탭/PDU, KVM)는 각각 확인 단계에서 Shut Down Databases First를 제공하므로, 전원을 끊기 전에 데이터베이스를 플러시하고 중지할 수 있습니다. 그리고 종료로 부하가 해소되어 SSH가 복구되면 Start 버튼으로 SSH를 통해 데이터베이스를 다시 시작합니다 — 따라서 이상적인 순서는 대개 폭주한 데이터베이스를 정상 종료하고, 서버가 회복되게 둔 다음, Start로 다시 시작하는 것이며, 전원 재투입은 전혀 필요 없습니다.

8.8Host Monitor(원격 에이전트)

SSH 진단은 요청할 때만 실행됩니다. 지속적인 가시성이 필요하면 Host Monitor를 설치하십시오 — 서버에 상주하며 자체 상태를 보고하는 작은 읽기 전용 Go 헬퍼(fsagent)로, 주기마다 SSH를 사용하지 않습니다. 연결된 호스트의 패널에서 설치를 선택하거나 Link a Server에서 체크 상자를 선택하십시오. 앱은 기존 키를 통해 호스트의 OS와 아키텍처에 맞는 바이너리를 푸시하고, 플랫폼 서비스(systemd, launchd 또는 BSD rc.d)를 설정하고, TLS 인증서를 고정합니다. AI 도구 install_monitor도 요청에 따라 같은 작업을 수행합니다.

LAN과 Tailscale을 동시에. 모니터는 이 Mac이 설치에 사용한 주소, 그리고 서버 자체의 LAN 주소와 Tailscale 주소에서 수신 대기합니다 — 모든 인터페이스에서 수신 대기하지 않으며, 공인 주소나 컨테이너 브리지 주소에서도 수신 대기하지 않습니다. 한 주소에서 응답이 멈추면(예: 사무실을 떠나 이제 Tailscale로 서버에 접속하는 경우), FrontierStack은 같은 고정 인증서를 제시하는 다른 주소로 전환합니다. 버전 1.22 이전에 설치된 모니터는 한 주소에서만 응답합니다. Detect monitor는 모니터가 실행 중이지만 연결할 수 없을 때 이를 알려 주며, Install & Enroll로 업그레이드할 수 있습니다.

등록이 완료되면 모니터는 실시간 지표를 스트리밍합니다. CPU, 메모리, 마운트별 디스크, 활성 네트워크 인터페이스, 감지된 서비스, 방화벽 및 fail2ban 상태를 보내며, GPU 호스트에서는 GPU별 온도와 사용률도 보내므로 채굴 장비나 ML 장비의 발열 상태가 드러납니다. list_monitors는 플릿의 헬퍼와 그 버전, 최신 지표를 보고합니다. 무엇보다 모니터는 Mac 앱이 오프라인일 때도 계속 감시하며 알림을 보낼 수 있습니다. 자체 채널로 직접 알리고, 앱이 돌아오면 버퍼에 쌓인 내용을 재전송합니다. 로그 윈도우도 모니터를 우선 사용합니다 — 모니터는 서버에서 root로 실행되므로 sudo 암호 없이도 권한이 필요한 로그를 읽습니다.

등록된 호스트의 패널에는 Behavior & History 차트도 있습니다. CPU, 메모리, 디스크, 온도를 5분 단위로 최대 30일간 기록하며, 학습된 기준선과 비교해 비정상적인 동작을 표시합니다. 온도는 도 단위의 별도 눈금을 사용하므로 백분율 기반 리소스 사용량 옆에서도 읽기 쉽습니다. 세로선은 같은 타임라인에 사건을 표시합니다. 빨간 실선은 서버 재부팅(보고된 가동 시간에서 산출)이고, 주황 점선은 워치독 문제 — 서비스 강제 재시작, 데이터베이스 손상 경고, 재부팅 에스컬레이션 — 입니다. OS 충돌 리포터가 CPU를 사용하기 시작하면(프로세스가 반복해서 충돌하는 경우) 주황색 Crashes 곡선이 차트에 추가되므로, "어젯밤 MySQL이 두 번 강제 재시작되었고 무언가가 충돌을 반복하고 있었다"는 사실을 한눈에 알 수 있습니다.

모니터는 기본적으로 읽기 전용입니다. Host Monitor 패널에서 Allow actions를 켜면, 승인 절차를 거치는 monitor_action 도구로 실행되는 작고 고정된 제어 동작 집합이 열립니다 — 임의의 셸 명령은 절대 허용되지 않습니다. 허용 목록에 있는 서비스의 재시작/다시 로드/시작/중지, DNS 캐시 비우기, 방화벽 또는 fail2ban 다시 로드, 재부팅이 가능합니다. 각 작업은 서버에 기록됩니다. 지원 대상은 Linux(amd64/arm64/arm — 모든 Raspberry Pi 포함), macOS(OS X 10.11 El Capitan까지의 레거시 Intel 빌드 포함), FreeBSD(pfSense/OPNsense/TrueNAS), Windows입니다.

모니터를 장기간 건강하게 유지하는 일은 자동으로 처리됩니다. Rotate monitor credential은 베어러 자격 증명을 그 자리에서 교체합니다. 새 비밀 값은 Mac에서 생성되어 승인된 FS1 서명 키를 통해 전송되고, 화면에 표시되거나 AI에 전달되는 일 없이 서버에서 활성화됩니다. Allow self-update를 켜 두면 새 빌드 푸시는 구조적으로 안전합니다 — 후보 바이너리의 릴리스 서명을 검증하고, root 권한을 받기 전에 호환성 자체 테스트를 통과해야 하며, 이전 바이너리는 롤백용으로 보관됩니다. 새 바이너리가 상태 확인에 응답하지 않으면 FrontierStack이 자동으로 이전 바이너리를 복원합니다. 풀 방식 업데이트는 영구 토큰 대신 짧은 수명의 일회용 승인으로 바이너리를 가져옵니다. 모니터가 FS1 서명 요청을 검증하고 있으면 패널에 FS1 signed 배지가 표시됩니다.

8.9Cloud Servers, Server Clone 및 원격 Apache

컴퓨팅 패널과 함께 있는 AWS ▸ DynamoDB는 선택한 리전의 테이블을 상태, 항목 수, 크기, 파티션/정렬 키와 함께 나열합니다. 실제로 비용이 발생하는 두 가지에 초점을 맞춥니다. 용량 모드 캡슐은 사용 여부와 관계없이 읽기 및 쓰기 단위에 대해 계속 요금이 청구되는 프로비저닝 테이블과 요청당 요금이 청구되는 온디맨드 테이블을 구분합니다. 그리고 no PITR 플래그는 특정 시점 복구가 꺼진 테이블을 표시합니다. 특정 시점 복구는 모든 새 테이블에서 기본적으로 꺼져 있으며, 잘못된 쓰기 후 되돌릴 수 있는 유일한 방법입니다. 특정 시점 복구는 각 행의 메뉴에서 켜거나 끌 수 있습니다. DynamoDB에는 일괄 describe 호출이 없으므로 각 테이블을 개별적으로 조회하며, 목록은 리전당 40개로 제한됩니다.

Fleet & Remote ▸ Cloud Servers는 API 토큰이 설정된 모든 클라우드 제공업체 — DigitalOcean, Vultr, Linode, Hetzner, Sakura, Contabo — 와 AWS EC2, Lightsail, RDS의 인벤토리를 하나로 모읍니다. 읽기 전용 집계이며(전원 제어는 각 제공업체의 패널에 남아 있습니다), IP가 있는 실행 중인 인스턴스마다 수신 대기 중인 항목을 찾는 Services 버튼과, SSH로 인스턴스를 연결하고 모니터를 한 번에 설치하는 + Helper 버튼이 있습니다 — 시트에서 올바른 사용자 이름과 키만 지정하십시오.

Server Clone은 플릿 서버를 이 Mac과 같은 구성으로 세우는 안내형 마법사입니다. 감지된 Homebrew 스택을 설치하고, 설정과 사이트 파일을 원래 경로로 복사하고, 도메인 설정을 푸시하고 웹 서버를 다시 로드하며, MySQL 데이터베이스를 복제할 수도 있습니다(로컬 mysqldump를 SSH를 통해 대상의 mysql로 파이프). 모든 단계는 키 기반 SSH로 실행되고 다시 실행해도 안전하며, 기존 데이터는 삭제되지 않습니다.

하나의 사이트를 공개할 준비가 되면, 도메인의 컨텍스트 메뉴에서 Promote to Production 푸시를 사용하십시오. 가상 호스트 설정을 로컬과 같은 경로로 보내고, 선택적으로 문서 루트와 데이터베이스를 복사하고, Cloudflare를 통해 DNS를 대상으로 지정하며, certbot으로 실제 Let's Encrypt 인증서를 발급할 수 있습니다 — 파일, 데이터베이스, 가상 호스트, DNS, HTTPS를 한 번의 푸시로 처리합니다.

원격 서버의 Apache를 직접 관리할 수도 있습니다. 원격 호스트가 하나라도 있으면 Apache 패널에 호스트 선택기(This Mac / 각 연결된 서버)가 추가됩니다. 서버를 선택하면 FrontierStack이 SSH로 해당 서버의 Apache — 버전, 설정 구조, 실제 로그 경로를 포함한 모든 활성 가상 호스트 — 를 찾아내며, 가상 호스트, 모듈, MIME 유형, 포트, WebDAV를 편집할 수 있습니다. 각 변경 사항은 적용 전에 검증(httpd -t)되고 정상적으로 다시 로드되며, 설정이 유효하지 않으면 롤백됩니다. 레거시 macOS Server.app의 Apache 트리도 인식합니다. 사이트 목록의 Push to Server…는 로컬 사이트의 가상 호스트를 문서 루트를 바꿔 넣어 모니터가 연결된 서버에 생성합니다. 이 기능들이 대응하는 로컬 Apache 및 사이트 워크플로는 7장에서 다룹니다.

스크린샷 추가 예정

8.10호스트 화면 공유

각 서버의 패널은 프로브가 감지한 원격 접속 방법을 제공합니다 — Mac은 Apple 화면 공유 / VNC, Windows는 RDP, 그리고 클라이언트가 있으면 AnyDesk, TeamViewer, RustDesk, NoMachine입니다. 이 Mac에 Apple Remote Desktop이 설치되어 있으면 vnc:// 핸들러를 등록해 클릭을 가로채므로, 패널은 항상 Apple의 내장 화면 공유 클라이언트를 여는 별도의 Screen Sharing (macOS) 작업을 제공합니다. 호스트에 둘 이상의 주소로 연결할 수 있으면 — 예를 들어 LAN IP와 VPN 또는 Tailscale 주소 — 이 작업은 연결할 네트워크를 고르는 메뉴가 됩니다. 각 선택 항목은 숫자 IP로 직접 연결하므로, 호스트 이름이 확인되지 않을 때(mDNS, 분할 DNS, VPN 문제)에도 동작합니다. 패널이 확인되지 않을 수 있는 이름을 사용하게 되는 경우에는 VNC와 RDP에도 그에 맞는 “— by IP” 버튼이 나타납니다.

8.11KVM-over-IP: 콘솔과 전원, 원격 관리

SSH와 화면 공유는 머신이 켜져 있고 네트워크에 연결되어 있어야 합니다. 그렇지 않을 때 — 커널 패닉, BIOS/펌웨어 화면, 끝내 올라오지 않은 네트워크 스택 — 에는 대역 외 접근이 필요합니다. 운영 체제와 무관하게 실제 HDMI 출력을 캡처하고 USB 키보드/마우스 입력을 주입하는 KVM-over-IP 장치입니다. Remote KVM 패널에는 보유한 장치를 몇 대든 등록할 수 있습니다 — PiKVM, JetKVM, TinyPilot, NanoKVM, GL.iNet Comet, 또는 일반 장치 — 각각 고정할 수 있고, 클릭 한 번으로 BIOS까지 내려가는 웹 콘솔을 열 수 있습니다.

전원 제어가 있는 장치는 마지막 고리를 채웁니다. ATX 보드를 단 PiKVM, 네트워크 PDU, 또는 KVM이자 스마트 전원 플러그인 GL.iNet의 Comet Pro (GL-RM10)는 주전원을 전환할 수 있어, 완전히 멈춘 서버의 전원을 강제로 재투입할 수 있습니다. 이런 장치를 서버의 Power 섹션(SwitchBot, UPS, PDU 명령 옆)에서 전원 소스로 연결하면 On/Off/Cycle을 사용할 수 있습니다. AI 관리자도 이를 제어할 수 있습니다. list_kvms, kvm_power, server_power가 있으며, 마지막 도구는 호스트에 연결된 플러그/PDU/KVM을 통해 reboot_host에 응답하지 않는 멈춘 서버를 재시작합니다.

8.12콘솔 연결: 시리얼 및 콘솔 서버 접근

네트워크 설정을 잃은 라우터나 스위치는 SSH, 웹 UI, KVM으로 접근할 수 없지만 콘솔 포트는 여전히 동작합니다. Console Connections 패널(Fleet & Remote)은 FrontierStack에 내장된 시리얼 터미널입니다. USB-시리얼 어댑터(FTDI, Silicon Labs CP210x, WCH CH340/CH9102, Prolific)를 꽂거나 기기 자체의 USB 콘솔 포트(Cisco의 USB mini-B 또는 USB-C, Netgate 방화벽)를 연결하면, 몇 초 안에 Attached serial ports 아래에 어댑터의 칩 이름과 함께 나타납니다. Quick Connect는 아무것도 저장하지 않고 선택한 속도로 엽니다. Save as…는 제조사의 콘솔 설정으로 연결을 저장합니다. Cisco, Juniper, Arista, Aruba CX, ProCurve, Ruckus, Fortinet, Palo Alto, SonicWall, WatchGuard, pfSense/OPNsense, MikroTik, Ubiquiti, TP-Link Omada, Dell OS10, Allied Telesis, APC, Raspberry Pi, Linux, 그리고 OpenWrt 및 GL.iNet 라우터의 보드 레벨 UART를 지원합니다.

모든 설정은 편집할 수 있습니다. 속도(460800과 921600을 포함해 어댑터가 지원하는 모든 속도), 데이터 비트, 패리티, 정지 비트, 흐름 제어와 함께, Return 키가 보내는 값(CR, CR LF 또는 LF), ^H로 보내는 Backspace, 로컬 에코, 그리고 화면에 계단식으로 출력되는 기기를 위한 LF → CR LF 변환이 있습니다. 어댑터를 다른 USB 포트로 옮겨 macOS가 이름을 바꾸더라도 FrontierStack은 USB 일련 번호로 다시 찾아냅니다. 콘솔 서버(Lantronix, Opengear, Digi, Avocent ACS, Cisco 터미널 서버의 reverse telnet, 또는 Raspberry Pi의 ser2net)는 telnet, raw TCP 또는 SSH 연결로 추가합니다.

각 세션은 별도의 윈도우에서 열립니다. Break는 라인 브레이크를 보냅니다 — Cisco ROMMON, Juniper 및 대부분의 부트 로더가 암호 복구 중에 기다리는 신호입니다. DTR과 RTS를 켜고 끌 수 있습니다. 붙여넣기 지연은 붙여 넣은 설정을 한 줄씩 보내므로 9600보드 콘솔에서도 문자가 누락되지 않습니다. 세션 로그는 기기가 보낸 모든 내용을 ~/Library/Logs/FrontierStack/Console에 저장하며, Export로 화면을 저장하거나 이메일로 보낼 수 있습니다. 연결을 고정된 기기에 연결하면 해당 기기 페이지의 Console 섹션에 나타나며, 그곳에서 추가한 콘솔은 해당 플랫폼의 일반적인 설정으로 시작합니다. AI 관리자는 콘솔과 연결된 어댑터를 나열할 수 있지만(kvm, 작업 consoles), 세션을 열거나 세션에 입력하지는 않습니다.

스크린샷 추가 예정

8.13부트 미디어: 네트워크로 운영 체제 설치하기

예전에는 서버를 다시 설치하려면 USB 메모리를 들고 랙까지 가야 했습니다. Boot Media 패널(Fleet & Remote)이 그 USB 메모리를 대신합니다. 설치 이미지를 이 Mac의 라이브러리 한곳에 보관해 두면, 선택한 이미지를 FrontierStack이 대상 머신에 가상 CD로 제공합니다 — 서버의 관리 컨트롤러, PiKVM, Proxmox VE 가상 머신의 CD 드라이브 또는 네트워크 부트 메뉴를 통해서입니다. Mac은 Apple이 더 이상 그런 방식의 부팅을 허용하지 않으므로 다르게 처리합니다. 아래의 Mac을 참조하십시오.

스크린샷 추가 예정

8.18.6이미지 라이브러리

Add ISO or Disk Image…는 로컬 파일을 등록합니다. 파일은 원래 위치에 그대로 있으며 아무것도 복사되지 않습니다. Add Image URL…은 이미 웹 서버나 파일 서버(http, https, nfs 또는 cifs)에 있는 이미지를 등록합니다 — 원격 URL은 대상에 그대로 전달되므로 이 Mac이 데이터를 중계할 필요가 없습니다. Compute SHA-256은 파일의 체크섬을 기록하므로, 그 이미지로 무엇이든 설치하기 전에 제공업체가 공개한 체크섬과 비교할 수 있습니다. 각 항목은 이름 변경, Finder에서 보기, 라이브러리에서 제거가 가능하며, Copy Image URL로 제공 주소를 복사할 수 있습니다. 저장된 위치에 파일이 더 이상 없는 항목은 누락됨으로 표시됩니다.

8.18.7내장 미디어 서버

관리 컨트롤러는 설치가 진행되는 동안 ISO를 HTTP로 조금씩 읽어 들여 마운트합니다. 패널의 Media server는 바로 그 용도로 라이브러리의 로컬 이미지를 제공합니다. 가상 CD에 필요한 바이트 범위 요청과 keep-alive를 지원하며, 최근 요청 로그와 이미지별 전송 바이트 수를 보여 주므로 컨트롤러가 실제로 읽고 있는지 확인할 수 있습니다. 대상에 로컬 이미지가 필요하면 자동으로 시작되며, 직접 Start Serving을 눌러 시작할 수도 있습니다.

설정	기능
Stop serving after	1, 3, 6, 12 또는 24시간, 또는 Until I stop it. 읽기가 있을 때마다 타이머가 다시 시작되므로 느린 설치가 도중에 끊기지 않습니다. FrontierStack을 종료해도 제공이 중지됩니다.
Address in image URLs	Automatic은 이 Mac이 각 대상에 접근할 때 쓰는 주소를 사용하므로, 별도의 관리 VLAN에 있는 컨트롤러에도 실제로 접근 가능한 주소가 전달됩니다. 고정 주소 하나를 선택할 수도 있습니다.
Port	기본값은 8742입니다.
Open Port…	pf 또는 애플리케이션 방화벽이 켜져 있어 컨트롤러를 차단할 수 있을 때 표시됩니다. 관리자 확인 후 포트를 엽니다.

8.18.8서버 관리 컨트롤러(Redfish)

대부분의 랙 서버에는 이미지를 가상 CD로 제공할 수 있는 베이스보드 관리 컨트롤러가 탑재되어 있습니다. FrontierStack은 표준 DMTF Redfish API로 이를 제어합니다. 대상은 Dell iDRAC 8 및 9, HPE iLO 4, 5 및 6, Lenovo XClarity Controller(XCC), Supermicro X12 이상, 그리고 표준 Redfish 가상 미디어를 구현한 그 밖의 모든 컨트롤러입니다.

1. Add Controller를 누르고 주소, 포트, 사용자 이름, 암호를 입력하십시오. 암호는 키체인에 보관되며 컨트롤러에만 전송됩니다. 필요하면 컨트롤러를 플릿 서버에 연결하여 둘을 함께 표시할 수 있습니다. Virtual Media 및 Control 권한이 있는 계정을 사용하십시오.
2. Read Controller는 컨트롤러가 관리하는 대상을 검색합니다. 각 시스템의 모델과 전원 상태, 그리고 각 가상 CD 슬롯과 현재 마운트된 내용이 표시됩니다.
3. System, Virtual CD, Image를 선택하십시오. Boot from it once를 켜 두면 CD로 한 번만 부팅하고, 그 후에는 서버가 원래 부팅 순서로 돌아갑니다.
4. Then에서 Don't restart, Graceful restart 또는 Force restart를 선택하고 Mount(또는 먼저 확인을 요청하는 Mount and Restart)를 누르십시오.
5. 설치가 끝나면 가상 CD를 Eject하십시오.

컨트롤러	가상 미디어 참고 사항
Dell iDRAC 8 / 9	Enterprise 또는 Datacenter 라이선스가 필요합니다.
HPE iLO 4 / 5 / 6	iLO Advanced가 필요합니다.
Lenovo XClarity (XCC)	XCC Advanced 또는 Enterprise가 필요합니다.
Supermicro X12 이상	표준 Redfish 가상 미디어. X10 및 X11 보드는 자체 콘솔에서만 가상 미디어를 제공하므로, 복사한 URL을 사용해 그곳에서 이미지를 마운트하십시오.
기타 Redfish 컨트롤러	표준 VirtualMedia 삽입/꺼내기 동작을 구현한 모든 컨트롤러.

8.18.9IPMI 컨트롤러와 1회 네트워크 부팅

오래된 보드에는 Redfish가 없거나, Redfish는 있어도 가상 미디어가 없는 컨트롤러가 탑재되어 있습니다: Supermicro X10/X11, ASRock Rack, Gigabyte, Intel, iDRAC 7. 이러한 컨트롤러는 Protocol을 IPMI over LAN으로 설정하십시오. 그러면 FrontierStack이 ipmitool로 제어합니다(Install ipmitool은 앱 내 콘솔에서 Homebrew로 설치합니다). 암호는 키체인에 보관되며 명령줄이 아닌 환경 변수로 ipmitool에 전달됩니다. Read Controller는 전원 상태를 표시합니다. IPMI에는 표준 가상 미디어가 없으므로, IPMI로 OS를 설치하는 방법은 네트워크입니다. Network Boot Once는 다음 부팅을 PXE로 설정하고(chassis bootdev pxe, Legacy BIOS boot를 선택하지 않으면 UEFI 모드), 필요하면 하드 리셋을 보내거나 서버가 꺼져 있으면 전원을 켭니다. IPMI에는 정상 재시작이 없습니다.

Redfish 컨트롤러에도 Network Boot Once가 있습니다. 1회 Pxe 부팅 재정의 후 선택한 방식으로 재시작합니다. 아래의 내장 PXE 서버와 조합하면 가상 미디어 없이도 원격 서버를 이 Mac의 ISO 메뉴로 부팅할 수 있습니다.

8.18.10PiKVM 가상 미디어

PiKVM은 연결된 머신에 USB 드라이브를 에뮬레이트할 수 있습니다. Boot Media는 PiKVM의 문서화된 /api/msd 인터페이스를 사용하며, ATX 전원 제어와 같은 PiKVM API 계정을 씁니다(KVM-over-IP 참조). 먼저 이미지를 PiKVM 자체 저장소에 복사하십시오. 로컬 파일은 진행률 막대와 함께 업로드되며, 원격 URL은 PiKVM이 직접 다운로드합니다. 복사를 시작하기 전에 여유 공간을 확인합니다. 그런 다음 저장된 이미지를 As CD-ROM(ISO의 경우) 또는 As Flash(raw .img의 경우)로 연결하고, 머신의 부팅 메뉴에서 선택하거나 Power Cycle…(확인 후 수행하는 하드 ATX 전원 재투입)을 사용한 뒤, 콘솔을 열어 설치 과정을 지켜보십시오. 작업 후에는 Disconnect Drive와 삭제로 정리합니다.

8.18.11Proxmox VE 가상 머신

Proxmox VE의 가상 머신(아래 Proxmox VE에서 설명한 대로 연결)의 경우 Node, Virtual machine, ISO storage를 선택한 다음 Source를 선택하십시오. Image from the library는 Proxmox가 직접 이미지를 ISO 저장소로 다운로드하게 하므로(download-url 호출), 로컬 이미지는 이 Mac의 미디어 서버에서 가져옵니다. ISO already on Proxmox는 이미 그곳에 있는 ISO를 사용합니다. FrontierStack은 ISO를 VM의 CD 드라이브에 연결하고 부팅 순서에서 CD를 맨 앞에 둘 수 있습니다 — 원래 순서는 기억되었다가 꺼낼 때 복원됩니다. 마지막으로 VM을 그대로 둘지, 시작할지, 리셋할지(확인을 요청하는 하드 리셋) 선택하십시오.

API 토큰에는 다운로드를 위한 Datastore.AllocateTemplate과 Sys.AccessNetwork, 그리고 VM에 대한 VM.Config.CDROM, VM.Config.Options, VM.PowerMgmt 권한이 필요합니다. 패널은 컨트롤 옆에 이 목록을 표시합니다.

8.18.12네트워크 부팅(PXE / iPXE)

컨트롤러도 KVM도 없는 머신도 네트워크로 부팅할 수 있습니다. Serve an iPXE boot menu from this Mac을 켜면 미디어 서버가 iPXE 메뉴도 함께 공개합니다. 이 메뉴는 라이브러리의 모든 ISO를 HTTP로 SAN 부팅하고, 설치 프로그램 카탈로그가 있는 netboot.xyz로 체인하며, iPXE 셸과 boot from local disk를 제공합니다. Download iPXE Boot Loaders는 boot.ipxe.org에서 공식 로더(ipxe.efi, undionly.kpxe, arm64용 ipxe.efi)를 가져오므로 UEFI HTTP Boot 클라이언트가 이 Mac에서 직접 iPXE를 로드할 수 있습니다.

남은 일은 부팅하는 머신을 어디로 보낼지 DHCP 서버에 알려 주는 것입니다. 사용 중인 DHCP server를 선택하고 Copy Settings를 누르면 바로 쓸 수 있는 설정 조각이 복사됩니다.

DHCP 서버	사용하는 경우
dnsmasq	dnsmasq가 DHCP 서버인 경우. 내장 TFTP 서버도 있습니다.
dnsmasq (proxy-DHCP)	라우터가 계속 주소를 할당하고 dnsmasq는 PXE 클라이언트에만 응답하는 경우.
ISC dhcpd · Kea	직접 편집하는 Linux DHCP 서버인 경우.
OPNsense / pfSense	방화벽이 DHCP 서버인 경우. 설정 조각에 해당 네트워크 부팅 필드 이름이 표시됩니다.
UEFI HTTP Boot (no TFTP)	펌웨어가 TFTP 없이 이 Mac에서 HTTP로 iPXE를 다운로드하는 경우.

8.18.13내장 PXE 서버

네트워크에 dnsmasq가 없고 DHCP 서버도 변경하지 않으려면, 네트워크 부팅 설정에서 Answer PXE clients from this Mac을 켜십시오. 그러면 제공이 켜져 있는 동안 Mac이 두 가지 작은 서비스를 실행합니다.

• ProxyDHCP(UDP 67 및 4011)는 네트워크 부팅을 요청하는 머신(PXE 펌웨어, UEFI HTTP Boot, iPXE)에만, 그리고 부트 파일만 응답합니다. 주소는 절대 할당하지 않으므로 라우터의 DHCP는 이전과 똑같이 계속 작동합니다.
• TFTP(UDP 69, 읽기 전용)는 세 가지 iPXE 로더만 제공하고 그 밖에는 아무것도 제공하지 않습니다. BIOS 머신은 undionly.kpxe, UEFI x64 머신은 ipxe.efi, ARM64 머신은 ARM64용 ipxe.efi를 받습니다. UEFI HTTP Boot 클라이언트는 대신 HTTP로 로더를 받습니다. iPXE가 실행되면 다시 요청하여 메뉴를 받습니다.

응답할 Network를 선택하고(서비스는 그 인터페이스 하나에만 바인딩됩니다), 필요하면 응답할 머신의 MAC 주소만 나열하십시오. 각 요청과 전송은 스위치 아래에 표시됩니다. 로더는 처음에 자동으로 다운로드됩니다. pf 또는 애플리케이션 방화벽이 켜져 있으면, 서버 섹션의 방화벽 버튼이 이제 UDP 67, 69, 4011도 함께 엽니다.

8.18.14기타 KVM-over-IP 장치

JetKVM, GL.iNet Comet, NanoKVM, TinyPilot, Raritan, ATEN, Avocent, Lantronix, Adder 장치에는 가상 미디어용의 안정적인 공개 API가 없으므로, FrontierStack은 이를 제어하는 척하지 않습니다. 대신 Copy URL이 제공을 시작하고 KVM이 접근할 수 있는 이미지 주소를 복사하며, 패널은 해당 제공업체의 자체 콘솔에서 어디에 붙여넣어야 하는지 보여 줍니다.

8.18.15Mac

Mac은 설치 프로그램 ISO로 부팅할 수 없고 네트워크 부팅도 사라졌습니다. Apple silicon에는 네트워크 부팅이 없으며, Intel NetBoot는 macOS Server 5.7에서 서버 기능이 없어졌고 전체 보안 설정의 T2 Mac에서는 거부됩니다. 그래서 Mac의 경우 Boot Media는 Apple이 지원하는 방식으로 macOS를 설치합니다 — SSH로 Mac 자체에서 Apple의 전체 설치 프로그램을 다운로드해 실행하는 방식입니다. 플릿의 모든 원격 Mac에 카드가 표시됩니다(먼저 Remote Servers에서 Mac을 추가하십시오).

• Refresh는 macOS 버전, Apple silicon·Intel·T2 탑재 Intel 여부, 모델, 여유 공간, 이미 있는 설치 프로그램, 콘텐츠 캐싱 사용 여부를 읽어 옵니다.
• List는 사용 가능한 전체 설치 프로그램을 Apple에 조회하고(softwareupdate --list-full-installers), Download on 해당 Mac은 그중 하나를 백그라운드에서 진행률과 함께 가져옵니다(--fetch-full-installer).
• Install…은 startosinstall을 두 가지 모드 중 하나로 실행합니다: Upgrade / reinstall (keeps data) 또는 Erase and install. Apple silicon에서는 볼륨 소유자만 설치를 시작할 수 있으므로 관리자 사용자와 그 암호를 입력합니다. 암호는 표준 입력으로 startosinstall에 전달되며 저장되지 않습니다.
• Turn On Content Caching(이 Mac 또는 플릿의 아무 Mac에서)은 Apple의 업데이트와 설치 프로그램 사본을 LAN에 보관하므로, 다른 모든 Mac이 Apple 대신 그곳에서 다운로드합니다.
• KVM이 연결된 Intel Mac의 경우 Internet Recovery…는 확인 후 Apple 자체의 네트워크 복구로 재시작합니다. 복구 모드에는 화면 공유나 SSH가 없으므로 이를 조작하려면 KVM이 필요합니다.

8.18.16AI 관리자에서 사용하기

AI 관리자와 MCP 클라이언트는 기존 kvm 도구를 통해 Boot Media에 접근합니다. media_list(읽기 전용)는 라이브러리, 미디어 서버 상태, 각 컨트롤러의 전원과 마운트된 이미지, 각 PiKVM의 드라이브를 보고합니다. media_attach는 대상 — 이름으로 지정한 컨트롤러나 PiKVM, 또는 proxmox:<vmid> — 에 이미지를 마운트하며, boot=true를 지정하면 그 이미지로 재시작도 합니다. media_eject는 이미지를 제거합니다. 연결, 꺼내기, 재시작에는 Allow changes가 필요하며 항상 확인을 요청합니다(13장).

8.14Proxmox VE: 실시간 클러스터 상태와 게스트 전원

Proxmox VE 호스트는 서버로 가득 찬 서버이며, 노드에 SSH로 접속하는 것만으로는 게스트에 대해 알 수 있는 것이 많지 않습니다. 그래서 Proxmox VE 서비스 페이지(Containers 카테고리, 6장 참조)는 Proxmox 자체 API와 통신합니다. Add Connection을 누르고 클러스터 또는 단일 노드의 주소와 API 토큰을 입력하십시오 — 토큰 ID는 user@realm!name 형식이며, 그 비밀 값은 키체인에 보관되고 Authorization 헤더로만 전송됩니다. Proxmox의 자체 서명 인증서는 사설 주소에서만 허용됩니다. 상태 확인에는 PVEAuditor 역할의 토큰으로 충분하며, 전원 제어와 부트 미디어에는 위에 나열한 추가 권한이 필요합니다.

연결되면 페이지에 클러스터 이름, Proxmox 버전, 쿼럼이 표시되고, 노드별 CPU, 메모리, 루트 디스크, 가동 시간, 모든 VM과 컨테이너의 상태, 저장소별 사용량 막대가 표시됩니다. 각 게스트는 시작, 종료, 재부팅할 수 있으며, 확인 후 강제 중지나 리셋도 할 수 있습니다. Show in Server Activity와 Boot an ISO…는 Proxmox가 나타나는 다른 두 곳으로 이동합니다.

서버 활동 윈도우(11장)에서는 모든 노드가 All Servers, Cluster, Everything 레이아웃의 타일로 표시되며, CPU, 메모리, 디스크, 가동 시간 스파크라인과 “5/7 VMs · 2/3 containers running” 같은 줄이 함께 나타납니다. 노드 세부 정보에는 KPI, CPU 및 메모리 차트, 같은 전원 컨트롤이 있는 게스트 목록, 저장소와 클러스터 정보, 그리고 Open Web UI, Refresh, Boot an ISO…가 표시됩니다.

알림은 백그라운드에서 각 연결을 약 5분마다 새로 고치며 감시합니다: API 접근 가능 여부, 각 노드의 온라인 상태, 클러스터 쿼럼, 사용률이 90%를 넘은 저장소. AI 관리자는 kvm 도구의 proxmox_status 동작(읽기 전용)으로 같은 내용을 볼 수 있으며, proxmox_power로 게스트의 전원을 변경할 수 있습니다. 이때는 항상 확인을 요청합니다.

8.15오래된 Mac, Raspberry Pi & Windows 호스트

플릿의 의미 중 하나는 오래되었거나 특이한 하드웨어를 계속 쓸모 있게 유지하는 것입니다. 아직 macOS Server를 실행하는 구형 Xserve나 Mac mini도 다른 호스트와 똑같이 연결됩니다. Remote Apache 검색은 Server.app 고유의 Apache 트리와 내부 포트를 이해하므로 해당 웹 사이트가 표시되고 편집할 수 있으며, 모니터의 레거시 Intel 빌드는 OS X 10.11 El Capitan까지 거슬러 올라가 실행됩니다. 선반 가득한 Raspberry Pi도 일반 Linux 머신으로 연결됩니다 — 모니터의 arm 빌드가 Zero를 포함한 모든 Pi를 지원합니다 — 따라서 다른 모든 것과 나란히 CPU, 디스크, 서비스를 지켜볼 수 있습니다.

Windows 호스트는 Microsoft의 OpenSSH 서버를 통해 참여합니다. SSH 진단을 위해 Linux 머신처럼 연결하고, 모니터를 네이티브 Windows 서비스로 설치하십시오(Windows 서비스는 머신 환경 변수를 안정적으로 상속하지 않으므로 설정은 실행 파일 옆의 파일에서 읽습니다). Windows용 모니터는 자동으로 푸시되지 않으며, Host Monitor 패널에서 제공하는 PowerShell 설치 프로그램으로 수동 설치합니다.

진단을 넘어서는 대화형 제어를 위해 카탈로그에는 원격 접근 도구 — RustDesk, MeshCentral, Apache Guacamole, Windows 원격 데스크톱, WinRM — 도 들어 있지만, 이들은 직접 운영하는 서비스이지 SSH 플릿 자체는 아닙니다. 플릿의 강점은 모든 것을 하나의 윈도우에서 일관되고, 스크립트로 자동화할 수 있으며, 부담이 적게 관리한다는 점입니다 — 그리고 13장의 run_script로 어느 노드든 이름으로 지정할 수 있으므로, AI가 원격 서버를 두 단계씩 진단하고 수정할 수 있습니다: 읽기 전용 테스트, 그다음 최소한의 수정, 그리고 다시 실행하여 확인.

8.16OpenCore Legacy Patcher Mac: 업데이트해도 안전할까?

오래된 Intel Mac 중 일부는 OpenCore Legacy Patcher(OCLP) 덕분에 Apple이 해당 기종용으로 출시한 적이 없는 최신 macOS를 실행하고 있을 것입니다. 이 경우 재부팅의 의미가 달라집니다. 일반 서버 Mac은 전원 → macOS → FrontierStack 에이전트 순으로 부팅하지만, OCLP Mac은 전원 → 펌웨어 → EFI/OpenCore → macOS → OCLP 루트 패치 → FrontierStack 순으로 부팅합니다. 연결 고리가 하나 늘어날 때마다 무인 부팅이 멈출 수 있는 지점이 생깁니다. macOS 업데이트는 봉인된 시스템 볼륨을 교체하면서 루트 패치도 함께 없애 버리고(Wi-Fi, 그래픽 가속, Bluetooth가 다시 적용될 때까지 사라짐), 메이저 업그레이드에는 먼저 그에 맞는 OCLP 릴리스가 필요하며, 펌웨어의 시동 항목이 OpenCore를 가리키지 않게 되면 누군가 Option 키를 누른 채 “EFI Boot”를 선택할 때까지 머신이 부팅 선택 화면에 멈춰 있습니다 — 그 Mac이 다른 건물에 있다면 훨씬 더 번거로운 일입니다.

OpenCore Patcher 패널(Fleet & Remote)은 Update를 누르기 전에 이를 알 수 있도록 존재합니다. This Mac 또는 연결된 Mac을 선택하면 읽기 전용 검사를 실행합니다 — OCLP 앱 버전, OpenCore의 NVRAM 스탬프(Mac이 실제로 OpenCore를 거쳐 부팅했을 때만 존재), 루트 패치 영수증, bless --getBoot, SIP, 소프트웨어 업데이트 설정, OpenCore가 위장한 모델 뒤의 실제 모델 — 그리고 이를 Remote boot safety 목록으로 정리합니다: 펌웨어 부트 항목 → OpenCore, 기본 부팅 볼륨 설정, 무인 재부팅에 대한 FileVault의 영향, 루트 패치의 존재 및 최신 여부, OCLP 릴리스의 설치된 macOS 지원 여부(최신 GitHub 릴리스와 대조), 대기 중인 macOS 업데이트, macOS 자동 설치 꺼짐, EFI/OpenCore 백업. 그 위에 하나의 판정이 이유와 함께 표시됩니다: Safe to update macOS, Update with caution 또는 Not safe.

[[FIG id="oclp-pane" caption="OpenCore Patcher 패널: 판정, Remote boot safety 체크리스트, 세 가지 관리 동작." capture="대기 중인 업데이트와 루트 패치가 있는 OCLP MacBook Pro를 대상으로 한 OpenCore Patcher 패널."]]

이 패널은 의도적으로 OCLP를 관리하지 않습니다 — OpenCore 빌드와 루트 패치 적용은 OCLP 자체 앱에서 수행합니다. 대신 고정된, 되돌릴 수 있는 세 가지 관리 동작을 제공합니다: macOS 자동 설치 끄기(시스템 설정이 OCLP Mac을 무인으로 업데이트하지 않도록), EFI 백업(해당 Mac에 보관되는 EFI/OC 폴더의 아카이브), OpenCore 다시 bless(OCLP의 “Install to disk”가 실행하는 것과 같은 bless --setBoot, OpenCore.efi가 실제로 있지 않으면 거부). 플릿 상태 검사도 모든 고정된 Mac에서 OCLP를 감지합니다. 호스트 행과 서버 활동 윈도우에 표시되며, 루트 패치가 없거나 부트 항목이 OpenCore를 우회하면 알림이 보안 항목을 발생시킵니다.

8.17마이그레이션 마법사: 스택을 새 기기로 옮기기

오래된 서버를 퇴역시킨다고 해서 “모든 것을 손으로 다시 설치”해야 하는 경우는 드뭅니다. FrontierStack에는 레거시 머신에서 스택을 들어내 선택한 대상 — 이 Mac, 다른 Mac 또는 Linux 머신 — 에 다시 구축하는 안내형 마이그레이션 마법사가 포함되어 있습니다. 원본은 읽기만 하며, 모든 쓰기는 대상에 이루어집니다.

Migrate Setups 패널은 MAMP, XAMPP 또는 Apple Server.app 웹 스택을 처리합니다. 원본을 자동으로 감지한 다음, 옮길 항목을 정확히 선택할 수 있습니다: Homebrew 도구, 웹 파일, MySQL 데이터베이스, 사이트(가상 호스트), MIME 재정의, Apache 모듈, PHP 설정, WordPress wp-config.php 수정, Git 저장소. Set up on 선택기로 대상을 고릅니다. 전체 앱 내 마이그레이션을 하려면 This Mac으로 두고, 연결된 호스트를 선택하면 SSH를 통해 새 기기에 스택을 설치하면서 웹 파일(rsync)과 데이터베이스(SSH를 통한 덤프)를 복사합니다 — Homebrew 대신 apt/dnf를 사용하는 Linux 토글도 있습니다.

패널의 Servers 섹션에는 Import from a Repo…도 있습니다. SSH 설정, Ansible 인벤토리 또는 .env 파일이 들어 있는 폴더나 git 저장소를 지정하면, 검토를 거친 후 서버를 플릿에 추가하고 자격 증명을 Script Secrets 또는 해당 서비스에 추가합니다. FrontierStack AI는 값을 한 번도 보지 않고 다른 구성도 읽을 수 있습니다(13장).

Apple Server Migration 패널은 Server.app 머신 전체를 위한 원클릭 마법사입니다. 원본(이 Mac 또는 원격 Mac)을 지정하면 serveradmin으로 모든 서비스 — 웹 사이트, 메일, 캘린더 및 연락처, 메시지(XMPP), VPN, DNS, DHCP, NetInstall, Open Directory, 파일 공유, Time Machine, 프로파일 관리자 등 — 의 목록을 작성하며, 또한 git 서버, 데이터베이스, Docker, 독립 실행형 Nginx 등 실행 중인 그 밖의 항목도 찾아냅니다. 각 서비스에는 상태 배지와 최신 대체 서비스가 표시되며, 합리적인 대체 서비스가 둘 이상인 경우(캘린더 → Radicale / SOGo / Baïkal, VPN → WireGuard / strongSwan, DHCP → dnsmasq / Kea) 어느 것을 쓸지 선택합니다. 대상 머신과 OS를 선택하면 마법사가 대체 서비스를 설치하고 정확한 이전 체크리스트를 출력합니다. 전용 가져오기 기능이 있는 서비스 — 웹 사이트(가상 호스트 전체 + 파일 복사)와 Open Directory(사용자 및 그룹) — 는 각자의 패널로 넘겨지며, 감지된 git 서버는 Git Server 마이그레이션으로 넘겨집니다.

8.18Git Server: Gitea & 저장소 마이그레이션

Git Server 패널은 자체 호스팅 Gitea(자동 HTTPS를 위해 Caddy 뒤에 배치)를 어떤 대상 — 이 Mac, 연결된 서버, NAS, Docker 호스트 또는 Linux 머신 — 에든 구축하며, 플랫폼을 감지하여 알맞은 방법으로 설치합니다. 실행되면 액세스 토큰으로 연결하여 실시간 모니터를 사용할 수 있습니다: 버전, 저장소 수, 그리고 미러가 원본보다 뒤처지면 알리는 백업 지연 알림.

같은 패널은 다른 Git 서버를 Gitea로 마이그레이션하거나 미러링합니다. 디스크의 bare 저장소 — 레거시 macOS 앱 Simple Git Server, Xcode Server, Gitolite, 일반 git-daemon 또는 아무 폴더 — 를 지정하거나, git://, https:// 또는 ssh:// 클론 기본 주소로 실행 중인 원격 서버를 지정하십시오(저장소 이름은 SSH로 열거하거나 붙여넣기). Scan은 저장소를 나열하고, Migrate는 각 저장소를 전체 기록, 모든 브랜치와 태그와 함께 미러 클론한 뒤 Gitea로 푸시하며, 대상 저장소는 API로 생성합니다. 복사는 이 Mac에서 실행됩니다.