데이터베이스 및 데이터

웹 스택의 품질은 그 아래에 있는 데이터에 달려 있습니다. 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장)은 이를 통해 모델이 사용자의 문서에 접근할 수 있게 합니다. 분석 데이터베이스는 트랜잭션 읽기/쓰기가 아니라 대규모 데이터 세트에 대한 빠른 집계를 위해 만들어진 컬럼형 또는 시계열 엔진입니다.

순수하게 프로세스 내부에서 벡터 검색을 하려면 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로 설치합니다. 이 도구들은 애플리케이션 자체의 데이터 계층을 다루며, 그 아래에 기록되는 내용은 여전히 앞에서 설명한 덤프와 백업이 보호합니다.