English · 简体中文 · 日本語 · 한국어 · Español · Português (Brasil) · Deutsch

에이전트가 만든 제품을 실제 서비스로 올리세요: 호스팅, 데이터베이스, 인증, 도메인, 이메일, 결제까지 — 전부 당신의 계정에서. 그다음 인계하거나, 전부 철거하면 됩니다.

코딩 에이전트는 앱을 몇 분 만에 만들어 냅니다. 하지만 실제 사용자에게 도달하려면 계정, 호스팅, 데이터베이스, 도메인, 시크릿, 그리고 연결해야 할 서비스가 남아 있습니다. GoLive는 그 작업을 위한 오픈소스 Agent Skill입니다. 앱에 무엇이 필요한지 감지하고, 정확한 변경 사항을 계획하고, 당신의 승인을 요청하고, 당신의 로그인으로 실행하고, 실제로 동작하는지 검증합니다 — 그런 다음 만든 것을 기록하고, 요청하면 드리프트를 다시 점검하고, 다시 제거할 수도 있습니다.

프로바이더가 열어 둔 부분은 자동화합니다. 사람이 필요한 부분은 안내합니다. 관찰할 수 있는 것은 검증하고, 끝나지 않은 작업은 분명히 드러냅니다. GoLive 계정도, 호스팅 백엔드도, 제품 텔레메트리도 없습니다.

초기 alpha · 0.1.0-alpha.9 이제 일회용 live 테스트가 여섯 가지 경로를 다룹니다. 호스팅(Vercel, Netlify), 데이터베이스 (Supabase, Neon), 사용자 지정 도메인 DNS(Porkbun, GoDaddy), 트랜잭션 이메일(Resend), 테스트 모드 결제(Stripe), Supabase 인증이며, 여기에 teardown 제거 경로도 포함됩니다. 소유권 문서와 요청 시 실행하는 golive status 드리프트 점검은 테스트 커버리지와 함께 구현되어 있고(golive status는 live 검증에서 읽기 전용으로 실행되기도 했습니다), 더 넓은 로드맵은 우리가 나아갈 방향일 뿐, 그것이 전부 만들어졌다는 주장이 아닙니다.

에이전트에게 프로바이더 계정을 맡길지는 결국 네 가지 질문으로 좁혀집니다. 아래는 이 프로젝트가 내놓는 답이며, 한계가 있는 곳에는 한계를 함께 밝힙니다.

• 모든 쓰기는 여전히 당신이 승인합니다. 당신이 보고 승인한 계획 없이는 실제 계정에 아무것도 닿지 않습니다. apply는 그 계획의 id와 --yes가 없으면 거부하고, 쓰기 전에 계획의 동일성을 다시 확인합니다. 그래서 release나 설정이 바뀌면 이전 승인은 무효가 됩니다. DNS 쓰기에는 --confirm-dns, 삭제에는 --confirm-destroy, live 모드 단계 — live 결제, 프로덕션 데이터, 실제 계정 — 에는 --confirm-live가 필요하며, 여기에는 이제 프로젝트의 최초 프로덕션 배포도 포함됩니다. 예전에는 계획을 승인하는 것만으로 처음 프로덕션에 쓰기에 충분했기 때문입니다. 자격 증명 값은 프로세스 안에서만 읽히고 절대 출력되지 않으며, 인자·계획·state·리포트에도 들어가지 않습니다. golive가 이 값을 저장하는 파일은 저장소 밖에 있는 평문 파일(모드 0600)이며 키체인이 아닙니다. 짚고 넘어갈 한계가 하나 있습니다. 이 플래그들은 에이전트가 당신을 대신해 넘기는 인자이고, 이미 당신의 프로바이더에 로그인한 에이전트라면 golive 계획이 전혀 없어도 거기에 쓸 수 있습니다. 신뢰, 접근, 통제는 코드가 강제하는 것과 에이전트가 따르도록 요청받은 지침에 불과한 것을 구분합니다.
• 실행은 밀어붙이지 않고 멈춥니다. apply는 첫 번째 실패한 검사, 빠진 확인, 빠진 전제 조건, 또는 계획과 모순되는 프로바이더에서 멈춥니다. 이후 단계는 실행되지 않고, 다음 apply가 그 단계부터 재개합니다. 복구에서 실패를 읽는 법, 어느 단계가 재개되는지, 먼저 검토된 결정이 필요한 경우가 무엇인지 다룹니다.
• 롤백은 좁고, 선택적이며, 결코 자동이 아닙니다. 검사가 실패해도 롤백이 일어나지 않습니다. release.rollback: true는 golive 자신이 기록해 둔 이전 배포로 프로덕션을 다시 가리키는 단계 하나를 계획합니다. 대시보드나 Git push, 풀 리퀘스트로 만들어진 배포는 대상이 아니고, 데이터·DNS·결제·이메일 리소스는 건드리지 않습니다. 현재 이 재지정을 지원하는 호스트는 Netlify뿐입니다. Vercel에서는 대시보드에서 프로덕션을 바로잡아야 합니다(Vercel 어댑터에는 프로덕션이 무엇을 서비스하는지 읽는 방법이 없습니다). 프로모션과 롤백은 구현되어 있고 mock으로 커버되지만 live 검증은 되지 않았습니다.
• 무엇이든 조용히 남겨지지는 않습니다 — '아무것도 남지 않는다'와 같은 말은 아닙니다. golive teardown은 자신이 만들었다고 증명할 수 있는 리소스만 제거하고, 삭제한 뒤에 DNS 존과 호스트 프로젝트를 다시 읽고, 지울 수 없는 남은 것은 하나도 빠뜨리지 않고 — Supabase·Neon 프로젝트, Resend 발신 도메인, 읽을 수 없는 존이나 호스트 프로젝트 — 무엇이 남았고 손으로 어떻게 지우는지 적은 handoff로 명시합니다. 제거하면 그 리소스에 대해 golive가 기록해 둔 기준선도 함께 사라지므로, golive status가 golive 자신의 teardown을 드리프트로 보고하지 않습니다.

이 답의 전문은 신뢰, 접근, 통제와 복구에 있습니다. 아키텍처는 제품 계약이고, 프로바이더 범위는 각 프로바이더가 오늘 무엇을 할 수 있는지 말하며, 검증 기록은 live로 실행해 본 것과 mock으로만 커버된 것을 구분하고, 배포와 업데이트는 설치와 업데이트를 다룹니다. gstack으로 빌드할 때의 배포 경로는 GoLive와 gstack 함께 쓰기에서 다룹니다.

설치 · GoLive 사용하기 · 실행 과정 보기 · alpha 범위 · 로드맵 · 기여하기

Node.js 20+, npm/npx, Git, 그리고 skill을 불러오고 명령을 실행할 수 있는 코딩 에이전트가 필요합니다. 설치는 Codex와 Claude Code에서 확인했고, 다른 클라이언트는 검증되지 않았습니다.

모든 프로젝트에 한 번만 설치하세요. 어느 디렉터리에서든 다음을 실행하면 됩니다:

npx skills add https://github.com/mikehasa/golive-skill --skill golive --global

안내가 나오면 에이전트를 선택합니다. 방향키로 이동하고, Space로 선택하고, Enter로 확정합니다. 그 화면은 입력을 기다리는 상태이며, 확정한 뒤에 설치가 계속됩니다.

에이전트 선택을 건너뛰려면 사용하는 에이전트에 맞는 명령을 쓰면 됩니다:

# Codex
npx skills add https://github.com/mikehasa/golive-skill --skill golive --global --agent codex --yes

# Claude Code
npx skills add https://github.com/mikehasa/golive-skill --skill golive --global --agent claude-code --yes

프로젝트 하나에만 설치하려면 그 프로젝트 저장소에서 실행하고 --global을 빼면 됩니다.

또는 다음을 코딩 에이전트에 붙여 넣으세요:

Install the GoLive skill globally so I can use it across projects:
npx skills add https://github.com/mikehasa/golive-skill --skill golive --global

Target the agent I'm using: add --agent codex --yes for Codex, or
--agent claude-code --yes for Claude Code. Keep --global.
If the agent isn't clear, ask me which one.

Verify the installation with:
node <installed-skill-dir>/scripts/golive.mjs version --json
Tell me if I need to reload skills or start a new session.
Stop after installation; don't connect accounts or deploy yet.

설치에는 지침, 프로바이더 참고 자료, 미리 빌드된 런타임이 포함됩니다. 계정을 연결하거나 무언가를 배포하지는 않습니다. 비대화형으로 쓰는 에이전트 플래그, 런타임 검증, 선택적인 자체 설치 프로그램은 배포와 업데이트를 보세요.

같은 skill이 npm에 golive@0.1.0-alpha.9으로도 게시되어 있습니다(dist-tag alpha와 latest). Git이나 Skills CLI 없이 오프라인으로 설치할 수 있습니다:

# Codex
npx golive@alpha install --agent codex

# Claude Code
npx golive@alpha install --agent claude

--global을 붙이면 현재 프로젝트 대신 홈 디렉터리(~/.agents/skills/golive 또는 ~/.claude/skills/golive)에 설치합니다. --agent claude-code도 받아들입니다. Skills CLI 채널이 사용하는 표기입니다. 설치 프로그램은 패키지에 들어 있는 완전한 skill을 복사하고, 이미 있는 설치 대상은 거부하며, 프로바이더 계정에 연결하는 일은 절대 하지 않습니다.

두 채널은 같은 release를 배포합니다. npm 패키지는 이 저장소의 버전을 그대로 게시하며 독립 실행형 설치 도우미도 포함하므로, npm으로 설치한 사본은 제자리에서 업데이트되는 자기 소유의 사본입니다. 이전 0.1.0-alpha.0 스냅샷에는 업데이터가 없습니다. 그 사본을 지우고 다시 설치하거나, 자체적으로 설치를 관리하는 GitHub 채널을 쓰세요. npm 패키지는 터미널 CLI도 제공합니다. golive 명령은 npx golive@alpha help, version, update-check, credentials, detect, menu, init, doctor, plan, teardown, apply, verify, status, handoff이고(apply에는 승인된 plan ID와 명시적 확인이 필요합니다), 자기가 관리하는 사본을 위한 설치 프로그램 명령은 install, install-status, update, rollback, update-policy, recover-lock입니다. 이 채널의 정확한 한계는 배포와 업데이트를 보세요.

OpenClaw를 쓴다면 같은 skill이 그 공개 레지스트리 ClawHub에도 올라와 있습니다:

npx clawhub@latest install golive     # into ./skills, recorded in .clawhub/lock.json
npx clawhub@latest update golive      # later updates stay with ClawHub

ClawHub는 agent의 전역 skills 디렉터리가 아니라 현재 디렉터리의 skills/에 설치하므로 OpenClaw 작업 공간에 어울립니다. 이 프로젝트가 검증한 클라이언트는 위 두 채널을 쓰는 Codex와 Claude Code입니다. 레지스트리는 자기 메타데이터(_meta.json, skill-card.md, .clawhub/)를 번들 옆에 두지만, golive 자체 무결성 검사는 이를 무시합니다. 이 채널의 한계는 배포와 업데이트를 보세요.

코딩 에이전트에서 앱 저장소를 엽니다. 설치 후에도 GoLive가 보이지 않으면 skill을 다시 불러오거나 새 세션을 시작하세요. skill의 이름은 golive 입니다. 위의 독립 실행형 설치를 했다면 에이전트 채팅창에 다음 중 하나를 입력합니다:

평범한 문장으로 요청해도 됩니다:

Use the golive skill to take this app live. Keep the providers it already uses.
Show me the destination accounts and plan before changing anything.

GoLive는 앱을 살펴보고, 빠진 프로바이더를 물어보고, 프로바이더를 변경하기 전에 대상 계정과 계획을 승인받을 수 있게 제시합니다.

이것들은 채팅 프롬프트입니다. golive skill은 명령이 아닙니다. npx skills add로 설치해도 터미널에 golive 명령이 생기지 않습니다. 포함된 CLI는 에이전트가 설치된 skill 디렉터리에서 실행합니다. npm 패키지로도 skill을 오프라인으로 설치할 수 있고, 그 CLI를 npx golive@alpha <command>로 쓸 수 있습니다. 다만 이 터미널 명령들은 대화형 skill 워크플로가 아니라 개별 작업을 실행합니다.

이미 Supabase를 쓰는 앱을 예로 든 대화입니다:

당신: golive로 이 앱을 실제 서비스로 올려 주세요. 지금은 테스트용 리소스를 써 주세요.

에이전트: 이 앱은 Supabase를 씁니다. 어디에 호스팅하고 싶으신가요?

1. Vercel — 내장 호스팅 워크플로. Supabase와 조합해 live 테스트를 마쳤습니다.
2. Netlify — 내장 호스팅 워크플로. live 테스트를 마친 조합은 Netlify + Neon입니다.
3. 기타 — 프로바이더를 알려 주세요. 공식 도구와 문서로 안내형 설정을 시도해 보겠습니다.

당신: Vercel.

에이전트: Supabase는 그대로 씁니다. 이 앱에 이미 Supabase 프로젝트가 있나요, 아니면 새 테스트 프로젝트를 만들까요?

당신: 새로 만들어 주세요.

에이전트: 별도의 터미널 창에서 vercel login과 supabase login을 실행해 주세요. 끝나면 어느 계정과 조직이 연결됐는지 확인하겠습니다.

당신: 끝났습니다.

에이전트: 계획은 이렇습니다. 선택한 Vercel 팀에 새 테스트 프런트엔드 프로젝트를 만들고, 선택한 Supabase 조직에 그 데이터베이스를 만들고, 필요한 환경 변수 값을 옮기고, 배포합니다. 실제 대상 이름과 ID, 리소스 설정, 비용 정보를 계획과 함께 보여 드리겠습니다. 적용 전에 승인해 주세요.

당신: 승인합니다.

에이전트: 배포가 live 상태입니다. URL, 검증 리포트, 아직 검증되지 않은 항목을 여기 정리했습니다. 다음으로 앱 자체의 가입과 데이터 흐름을 테스트하겠습니다. 이 테스트 프로젝트가 끝나면 golive teardown이 삭제 전에 승인받을 수 있도록 제거 계획을 세웁니다.

GoLive는 앱이 이미 쓰고 있는 프로바이더 선택을 그대로 유지하고, 빠진 부분만 물어봅니다. 가입, 브라우저 로그인, 본인 확인, 구매는 당신이 처리합니다. macOS에서 API 키가 필요하면 네이티브 숨김 입력 대화 상자가 왜 필요한지, 키가 어디에 저장되는지 설명합니다. 입력한 값은 곧바로 로컬 자격 증명 파일로 들어가고, 채팅이나 명령 출력으로는 절대 나가지 않습니다. 다른 플랫폼에서는 사용하는 에디터를 대체 수단으로 씁니다. 나중에 계획을 바꾸려면 승인을 다시 받아야 하고, 인증이나 도메인 연결은 첫 배포 이후에 후속 작업이 필요할 수 있습니다.

다른 프로바이더를 쓰나요? skill에는 일반적인 안내 흐름이 있습니다. 프로바이더의 공식 CLI, 사용할 수 있는 공식 MCP 연동이나 API를 확인하고, 필요하면 대시보드 조작을 안내합니다. 에이전트는 여전히 승인을 요청하기 전에 대상, 변경 사항, 비용을 보여 주고, 그다음 할 수 있는 범위에서 확인합니다. 이것은 최선을 다한 안내이며, 완료를 보장하지도 않고 내장 어댑터와 같은 검증 범위를 제공하지도 않습니다. 단계를 끝내거나 검증할 수 없으면 구체적인 장애 원인과 다음 행동을 알려 줍니다. 안내형 프로바이더 범위를 보세요.

호스팅은 Vercel과 Netlify 두 가지. 데이터베이스는 Supabase와 Neon 두 가지.

이것들은 기존 계정에서 승인받아 진행한 일회용 실행입니다. 끝난 테스트 리소스는 이후 삭제했고, 최근 실행의 일회용 프로젝트와 레코드도 같은 감독 아래 정리합니다. 교차 조합은 mock 커버리지가 있을 뿐 동등한 live 증거는 없습니다. Supabase CLI 로그인 재사용은 별도로 읽기 전용 검증을 통과했고, 전체 배포 테스트는 명시적 토큰을 사용했습니다. 신규 사용자의 최초 계정 설정과 모든 애플리케이션 프레임워크는 검증되지 않았습니다.

수명 주기 명령에도 각자의 증거가 있습니다. golive teardown은 일회용 Netlify 프로젝트에서 live로 실행했습니다(--confirm-destroy 없이는 차단되고, 그다음 제거됨. 계정의 사이트 목록은 그 프로젝트 외에는 달라진 것이 없음). 이전 실행에서는 golive가 쓴 GoDaddy·Porkbun 레코드를 제거하고, 발급한 Resend 발신 키를 폐기하고, 등록한 Stripe 테스트 모드 엔드포인트를 삭제했습니다. golive status는 live 프로젝트를 상대로 읽기 전용으로 실행했습니다. golive handoff --write는 Vercel만 쓰는 일회용 픽스처에서 실행했습니다. 두 산출물 모두 작성하고 감사했습니다(모든 주장 행에 출처 태그, 소유권 증명과 teardown 게이트 명시, 문서와 그에 대응하는 JSON 파일·state·설정 어디에도 자격 증명 형태의 값 없음). 프로젝트는 이후 승인된 teardown 흐름으로 제거했습니다. 스택이 호스트뿐이었으므로 문서의 다른 프로바이더 행은 여전히 mock 커버리지입니다. 증거는 검증 범위를 보세요.

실험적 어댑터도 있습니다. Supabase Auth 설정, Supabase Auth 가입 경로, 비밀번호 재설정과 계정 격리, 그리고 Cloudflare DNS용입니다. Supabase Auth 설정 — 가입, 이메일 확인, 최소 비밀번호 길이, 사용하는 메일러, 그리고 사이트 URL과 리다이렉트 허용 목록 — 은 승인된 계획을 통해 자동화되고 증거를 위해 다시 읽으며, 이 경로는 일회용 live 실행을 통과했습니다. 정책 쓰기는 다시 읽은 값에서 그대로 유지됐고(password minimum length: 6 → 12), auth-policy는 내장 메일러 관련 권고를 유일한 발견 사항으로 남기고 끝났습니다. 선택적으로 켜는 가입 경로(auth.e2e)도 같은 실행에서 통과했습니다. 승인된 단계 하나가 실제 테스트 계정을 시드했고(auth:test-user, --confirm-live 필요), 그 주소는 확인 전에는 로그인할 수 없었으며(email_not_confirmed), auth-signup/auth-session 검사가 가입 이메일, 강제된 확인, 확인 후 로그인, 세션 토큰, 익명 요청 거부를 증명했습니다. 한계는 두 가지가 남습니다. 확인은 시드된 계정이 자기 이메일을 클릭한 것이 아니라 Auth admin API를 통해 적용했고, 받은편지함 전달은 설계상 사람이 확인합니다. golive는 받은편지함을 절대 보지 않습니다. 이후 일회용 픽스처에서 진행한 승인된 실행(배포된 Vercel 사이트에서 선언된 경로가 세션 없이는 401을 반환하고, RLS로 보호된 테이블이 하나 있는 구성)은 앱 쪽 두 갈래를 모두 실행했습니다. auth.protectedPath에 대한 익명 GET은 401을 반환했고, 로그인한 프로브는 인증된 사용자로 그 테이블을 읽었습니다. 따라서 프로브의 bearer 수정은 더 이상 mock 커버리지가 아닙니다. 이 증거가 보여 주지 못하는 것도 있습니다. 그 실행의 테이블 항목은 테이블 이름이 아니라 개수였고, 401은 무엇이든 보호된 것으로 셌습니다. WAF나 점검 페이지도 같은 응답을 냅니다. 둘 다 이후에 수정했습니다(이슈 #30: 프로브가 읽은 테이블 이름을 밝히고, 거부된 보호 경로는 공개 루트와 대조해 교차 확인합니다. mock 커버리지는 있지만 live 재실행은 아직 없습니다). 비밀번호 재설정은 같은 프로바이더에서 live 검증을 마쳤습니다. 같은 2026-09-24 실행에 auth.smtp: resend(사용자 지정 SMTP 쓰기와 올린 인증 이메일 rate limit, 둘 다 다시 읽어 확인)와 auth.recovery: true가 있었습니다. 그 승인된 단계 하나(auth:recovery, --confirm-live 필요)가 기록된 테스트 계정의 비밀번호를 프로바이더 자체의 재설정 호출로 회전시켰습니다 — 이메일 요청, admin API로 링크 생성, 세션으로 교환, 그 세션으로 새 비밀번호 설정 — 그리고 auth-recovery 검사는 모든 갈래를 통과했습니다. 요청은 수락됐고, 계정이 없는 주소도 같은 응답을 받았으며(계정 열거 불가), 사용한 토큰은 재사용 시 거부됐고, 새 비밀번호는 로그인되고 대체된 비밀번호는 거부됐습니다. 받은편지함 클릭과 캡차는 사람 몫으로 남습니다(auth:recovery-email handoff에 그렇게 적혀 있습니다). SMTP 비밀번호는 쓰기 전용입니다(프로바이더가 해시를 돌려주므로, 다시 읽은 값은 설정을 증명할 뿐 발송을 증명하지 않습니다). 계정은 소유자가 클릭한 것이 아니라 Auth admin API를 통해 확인했습니다. 계정 격리도 같은 프로바이더에 구현되어 있습니다. auth.isolation: true에 auth.identityPath와 auth.isolationPath를 함께 쓰면 승인된 단계 하나(auth:isolation, --confirm-live 필요)가 두 번째 실제 테스트 계정을 시드하고 — 주소는 auth.testEmail에서 파생하고, 비밀번호는 이번에도 그 실행의 메모리에만 있습니다 — 프로바이더의 admin API로 확인합니다(두 번째 받은편지함 클릭은 없습니다. 이 경로는 발송이 아니라 앱의 데이터에 관한 것이기 때문입니다). 그다음 auth-isolation 검사가 두 계정으로 각각 로그인해 프로덕션 URL에서 앱이 선언한 두 경로를 읽습니다. 두 경로 모두 익명 호출자를 거부해야 하고(200이 나오면 치명적 발견), 각 계정의 identity 경로는 자기 user id로만 답해야 하며 상대 계정의 id로 답해서는 안 됩니다. rows 경로는 호출자 자신의 행만 돌려줘야 합니다 — 계정마다 고유한 마커 행 하나를 그 계정의 세션으로 그 경로를 통해 쓰고 다시 읽어서 확인하므로, 응답에 다른 계정의 마커가 있으면 교차 계정 읽기이고 치명적으로 실패합니다. 경로를 선언하지 않았으면 비차단 auth:isolation-routes handoff가 앱 코드 작업을 넘깁니다. 404나 거부된 세션은 그 작업을 명시한 skip으로 처리되고, 통과로 처리되는 일은 없습니다. 계정 격리는 구현되어 있고 mock으로 커버되지만 아직 live 검증은 되지 않았습니다. live 실행은 따로 진행됩니다. 그 재설정 실행의 출력 자체에도 결함이 두 개 있었고, 둘 다 여기서 mock 회귀 테스트와 함께 수정했습니다. teardown이 소유자가 가져온(adopted) 발신 도메인을 golive가 만든 것으로 보고했고(생성 마커 목록이 비어 있으면 [].every()가 참이 되어, 기록된 모든 도메인이 golive의 것으로 읽혔습니다), auth:recovery-email handoff는 state에는 그 단계가 완료로 기록되어 있는데도 근거로 독립 실행한 verify의 skip을 보여 줬습니다. 세 번째 발견 — Resend가 그 도메인을 계속 검증됨으로 보고했지만 Resend가 나열한 레코드는 그 존의 권한 있는 네임서버에 없었던 문제 — 은 #52로 수정했습니다. 이제 email-verified는 통과시키기 전에 프로바이더 자신이 그 도메인에 대해 나열한 레코드를 실제로 조회합니다(검증됨으로 표시된 도메인의 레코드가 사라졌으면 실패, golive가 전파 시간 안에 쓴 레코드는 경고에 그침, 레코드를 나열할 수 없는 프로바이더는 통과가 아니라 skip). 이메일 계획은 해석되지 않는 레코드에 대해 email:dns 단계나 handoff를 유지하므로, 낡은 플래그가 그 레코드를 숨길 수 없습니다. mock으로 커버했으며 live로 다시 실행하지는 않았습니다. 위에 나열한 DNS, 이메일, 테스트 모드 결제 경로가 테스트를 마친 경로이며, 사용자 지정 도메인 실행은 Porkbun과 GoDaddy 레코드 쓰기를 사용했습니다. 특히 Cloudflare DNS는 아직 검증된 alpha 경로가 아닙니다. 다른 인증 프로바이더는 안내형으로 남습니다. 프로바이더 범위와 검증 범위를 보세요.

동작하는 URL은 시작일 뿐입니다. 앱에 따라 서비스 출시(go-live)는 다음 전부를 뜻할 수 있습니다. GoLive는 어떤 항목이 해당하는지 판단하고, 끝내도록 돕고, 그 결과에 대한 증거를 제시해야 합니다. 정적 사이트에 데이터베이스를 만들라고 요구해서는 안 되고, 유료 SaaS가 배포된 홈페이지에서 멈춰서도 안 됩니다.

이것은 출시 체크리스트 형태로 정리한 제품 로드맵입니다. 체크 표시와 취소선은 live 테스트를 마친 특정 마일스톤을 뜻할 뿐, 그 범주가 완성됐다거나 당신 앱의 체크리스트가 완료됐다는 뜻이 아닙니다.

✅ live 테스트 완료 · 🚧 진행 중 / 실험적 (코드는 있으나 전체 경로는 아직) · 🗺️ 계획됨

• ✅ 프런트엔드 호스팅: Vercel과 Netlify에서 배포를 증명한다. 테스트를 마친 두 경로에서 의도한 프로젝트를 빌드하고, 배포하고, 검증합니다.
• ✅ 데이터베이스: Supabase와 Neon에서 프로비저닝과 연결을 증명한다. 테스트를 마친 경로에 환경 연결과 애플리케이션 CRUD 점검이 포함됩니다.
• ✅ 환경 연결: 테스트를 마친 두 경로에서 호스팅과 데이터베이스 자격 증명을 연결한다. 더 넓은 범위의 시크릿 회전과 환경 수명 주기 관리는 아직 계획 단계입니다.
• 🗺️ 백엔드 / 서버: 전용 API 서비스, 컨테이너, 상시 서버, 런타임 설정, 헬스 체크. 앱 라우트는 이미 지원 호스트를 통해 배포됩니다.
• 🗺️ 스키마와 데이터: 검토된 마이그레이션, 안전한 롤아웃, 환경 분리, 앱 데이터 점검. live 테스트에서는 별도로 감독해 진행했지만, 재사용할 수 있는 워크플로는 아직 계획 단계입니다.
• 🗺️ 파일·오브젝트 스토리지: 버킷, 업로드, 접근 규칙, 서명된 URL, 수명 주기 정책.

• 🚧 인증: 가입, 로그인, 세션, 비밀번호 재설정, 계정 격리. Supabase 인증 정책(가입, 이메일 확인, 최소 비밀번호 길이, 메일러)과 사이트 URL/리다이렉트 허용 목록은 승인된 계획을 통해 쓰이고, 증거를 위해 다시 읽고, auth-policy/auth-redirects 검사로 검증됩니다 — 승인된 일회용 실행에서 확인했으며, 그때 정책 쓰기는 최소 12자 설정까지 그대로 유지됐습니다. 선택적으로 켜는 경로 (auth.e2e: true)도 같은 실행에서 통과했습니다. auth:test-user 단계가 실제 테스트 계정을 시드했고, 그 주소는 확인 전에는 로그인할 수 없었으며, auth-signup/auth-session 검사가 가입 이메일, 강제된 확인, 확인 후 로그인, 세션 토큰을 증명했습니다 — Supabase에서는 일회용 프로젝트 여러 개에 걸쳐 live 검증을 마쳤습니다. 다만 확인은 시드된 이메일 클릭이 아니라 Auth admin API를 통해 이뤄졌고, 받은편지함 전달은 사람이 확인하는 방식으로 남았으며, 이후 실행에서는 선언된 보호 경로(익명 401)와 RLS로 보호된 테이블의 로그인 상태 읽기를 증명했고 그 결과는 테이블 이름이 아니라 개수로 보고됩니다. 비밀번호 재설정도 같은 프로바이더에서 live 검증을 마쳤습니다 (auth.recovery: true가 auth:recovery 단계와 auth-recovery 검사를 추가하며, 이 검사는 일회용 프로젝트에서 계정 열거 불가, 일회용 토큰, 교체된 비밀번호를 증명했습니다. 확인은 Auth admin API를 통해 이뤄졌고, 받은편지함 클릭은 사람이 확인하는 방식으로 남았으며, 그 실행이 찾아낸 출력 결함 두 가지 — 'golive가 만들었다'는 잘못된 소유권 주장과 기록된 단계와 모순되는 handoff 근거 문구 — 은 mock 회귀 테스트와 함께 수정했습니다). 계정 격리는 — 나머지 절반이고 이전 실행들이 실행하지 못했던 부분인데 — 같은 방식으로 구현되어 있고 mock으로 커버됩니다. auth.isolation: true에 auth.identityPath와 auth.isolationPath를 함께 쓰면 auth:isolation 단계(두 번째 실제 테스트 계정. 프로바이더의 admin API로 확인하고 id와 주소를 기록합니다)와 auth-isolation 검사가 추가되고, 이 검사는 두 계정으로 로그인해 앱 자체의 라우트에서 서로의 identity나 행을 읽을 수 없음을 증명합니다(교차 계정 읽기는 치명적으로 실패하고, 선언되지 않았거나 404인 라우트는 앱 코드 작업과 함께 skip합니다). 이 경로의 live 실행도 따로 진행됩니다. 다른 인증 프로바이더는 안내형으로 남습니다.
• 🗺️ OAuth / 소셜 로그인 / SSO: 클라이언트 등록, 동의 화면, 스코프, 콜백 URL, 프로바이더 심사. 현재 인증 프로바이더 설정은 안내형입니다.
• ✅ 결제와 구독: Stripe로 테스트 모드 결제와 webhook 수락을 증명한다. 실제 테스트 카드 결제가 서명이 검증된 checkout.session.completed 이벤트로 전달됐습니다. 새로운 읽기 전용 stripe-live-payment 검사는 가장 최근에 성공한 live PaymentIntent, 이를 수신할 live webhook 엔드포인트와 일치하는 전달 이벤트를 읽고 환불이 있으면 보고합니다. 구현과 mock 커버리지는 끝났지만 아직 live 검증은 되지 않았습니다. live 모드 준비 상태, 권한 부여(entitlements), 환불, 구독 이벤트는 아직 검증이 필요합니다.
• ✅ 트랜잭션 이메일: Resend로 발신 도메인 설정, 검증, 실제 전달을 증명한다. 앱 자체의 환경 키를 통한 발송이 전달됐습니다(새 서브도메인이라 스팸함으로, DMARC는 아직 없음). auth.smtp: resend를 쓰면 auth:smtp 단계가 인증 프로젝트의 사용자 지정 SMTP도 함께 씁니다 — Resend의 호스트/포트/사용자, 앱이 이미 쓰는 발신자, 그리고 golive가 발급한 발신 키에서 가져온 SMTP 비밀번호(이메일 경로의 키, 또는 SMTP만을 위해 새로 발급한 키) — 그리고 같은 쓰기에서 프로젝트 자체의 인증 이메일 rate limit(rate_limit_email_sent)을 시간당 30으로 올립니다 (auth.emailRateLimitPerHour로 지정할 수 있습니다). 프로바이더가 사용자 지정 SMTP를 쓸 때 그 한도를 함께 보관하기 때문입니다. 그러면 auth-policy는 내장 메일러에 대한 경고 대신 custom SMTP via Resend를 보고합니다. 비밀번호는 쓰기 전용이라(프로바이더가 해시를 돌려줍니다) 다시 읽은 값은 설정을 확인할 뿐이고, 실제 인증 이메일 한 통만이 완전한 증명입니다. 일회용 프로젝트에서 live 검증을 마쳤습니다(2026-09-24): 같은 실행에서 사용자 지정 SMTP를 쓰고 다시 읽었으며 (smtp.resend.com, 포트 465, 사용자 resend, 발신자 auth@mail.trytofu.xyz), auth email rate limit: 2 → 30 per hour도 함께 확인했습니다. SMTP 키는 golive가 스스로 발급했고 teardown에서 폐기했으며, 이후 auth-policy는 시간당 인증 이메일 30건과 함께 custom SMTP via Resend를 읽었습니다 — 설정과 rate limit만입니다. 비밀번호 자체는 다시 읽을 수 없기 때문입니다. 반송 처리, 더 풍부한 메시지 내용, 실제 받은편지함 전달은 아직 검증이 필요합니다(설계상 사람이 확인하며, 그 실행의 도메인에서는 의심스러운 상태입니다 — 이슈 #52 참고).
• ✅ 도메인 / DNS / HTTPS: 호스트+DNS 조합에서 도메인 연결, DNS 구성, HTTPS 서비스를 증명한다. 테스트 완료: --confirm-dns 아래 Porkbun과 GoDaddy 레코드 쓰기를 통한 Vercel 연결, 소유권 검증, 일회용 서브도메인에서의 HTTPS 200. Cloudflare DNS 어댑터, 리다이렉트, 추가 호스트 조합은 아직 live 검증이 필요합니다.
• 🗺️ SMS와 푸시 알림: 발신자 등록, 자격 증명, 권한, 전달 확인.
• 🗺️ 서드파티 및 AI 서비스: API 접근, 스코프, 콜백, 할당량, 기능 테스트. 빠진 환경 변수는 오늘도 감지합니다. 서비스별 워크플로는 계획 단계입니다.
• 🗺️ 백그라운드 작업: cron 스케줄, 큐, 워커, 재시도, 실패한 작업 복구.
• 🗺️ 캐시, 검색, 실시간: 필요할 때의 캐시, 검색/벡터 인덱스, 실시간 서비스.

• 🗺️ 보안과 악용 방지: 접근 정책, 노출된 자격 증명, 보안 헤더, rate limit, 봇 차단. 범위가 한정된 RLS/advisor 및 자격 증명 패턴 검사는 오늘도 있습니다.
• 🗺️ 모니터링과 알림: 오류 추적, 로그, 업타임, 조치 가능한 알림. 프로바이더 제안은 오늘 안내형으로 제공하고, 검증된 설정은 계획 단계입니다. 요청 시 실행하는 드리프트 점검은 있습니다(아래 golive status) — 지속적인 모니터링과 알림은 없습니다. Sentry는 자동화된 모니터링 프로바이더로 구현되어 있습니다 — 어댑터, 호스트 환경 변수 기록, sentry-ingest 검사 — mock 커버리지만 있고 live 실행은 아직 없습니다. UptimeRobot의 업타임 모니터도 구현되어 있습니다 — uptimerobot:monitor와 읽기 전용 uptime-monitor 검사 — mock 커버리지만 있고 live 실행은 아직 없습니다.
• 🚧 제품 분석: 이벤트 검증과 동의/데이터 설정. 오늘의 안내형 프로바이더 제안을 넘어서는 범위입니다. PostHog 분석은 승인된 계획을 통해 연결됩니다 — 앱의 분석 프로젝트를 채택하거나 선택하며(일치하는 것이 없으면 생성이 계획됩니다), posthog-ingest 검사가 합성 이벤트 하나를 보내고 PostHog 자체 쿼리 API로 다시 읽어 수집을 증명합니다 — 일회용 프로젝트에서 live 검증을 마쳤습니다 (2026-09-30). 호스트 환경 변수 쓰기, 동의 설정, 앱 자체의 이벤트 흐름은 아직 열려 있고, golive가 만든 프로젝트의 생성/삭제 경로는 mock 커버리지뿐입니다.
• 🚧 CI/CD와 안전한 릴리스: 프리뷰, 릴리스 검사, 프로모션, 롤백, 드리프트 감지. 오늘의 승인된 CLI 배포를 토대로 합니다. 배포 식별 정보 — 구현됨, live 검증은 안 됨: 배포에 성공할 때마다 그 배포에 대해 프로바이더 자신의 식별자를 기록합니다(deployed:<target>:id = <provider>|<deployment id>|<url>|<time>, .golive/state.json에 저장, mock 커버리지. 식별자를 보고하지 않는 프로바이더는 아무것도 기록하지 않습니다). 그래야 이후 기능이 정확히 그 배포 하나를 지목할 수 있습니다. 선택적 프리뷰 배포와 릴리스 검사 — 구현됨, live 검증은 안 됨: golive.yaml에 release.preview: true를(그리고 targets에 preview를) 두면 plan이 preview:deploy를 추가합니다. 이것은 현재 작업 트리를 호스트의 프리뷰 대상에 배포하는 create 단계로, 프로바이더·프로젝트·환경 대상과 이 프리뷰가 프로덕션과 공유하는 소스 프로젝트를 밝히고, live 모드 값이 프리뷰 환경 변수 이름을 채우면 --confirm-live가 필요하며, 프로바이더 자신의 식별자를 deployed:preview:id로 기록합니다. 그리고 release:check를 추가합니다. 이것은 아무것도 쓰지 않고, preview:deploy를 전제 조건으로 선언하며, 프로바이더가 그 배포를 읽는 데 실패하거나 그 번들의 자격 증명 스캔이 실패하면 계획을 실패시킵니다. 릴리스 후보를 만드는 계획에서 이 검사는 마지막 단계이므로, 검사가 게이트하는 것은 프로모션입니다(프로모션 자체의 계획이 프로덕션을 바꾸기 전에 그 검사를 다시 실행합니다). 같은 계획이 그보다 앞서 이미 실행한 프로덕션 배포를 막는 것이 아닙니다. 프로모션과 롤백 — 구현됨, live 검증은 안 됨: release.promote: true를(프리뷰 옵트인 위에) 두면 계획이 프로모션으로 릴리스를 요청하고, release.rollback: true를 두면 golive 자신이 만들고 기록한 이전 배포로 프로덕션을 다시 가리키도록 요청합니다. promote:production은 프로덕션으로 만들 배포 id를 정확히 지목합니다 — 프로바이더는 배포가 실제로 존재한 뒤에야 그 배포의 id를 알려주므로, 후보를 만드는 일과 프로모션하는 일은 두 개의 계획이고, 당신이 승인하는 계획이 둘 중 어느 것인지 밝힙니다 — 이 단계는 같은 계획 안에서 release:check가 그 배포를 다시 읽어 게이트하며, 추가 확인 플래그가 필요 없습니다. 계획 id, 지목된 배포, 새로 실행한 게이트가 곧 승인입니다. 두 단계 모두 쓰기 전에 대상 배포와 프로덕션이 서비스하는 것을 다시 읽고, 이후 프로덕션이 서비스하는 것을 증명합니다. 둘 다 릴리스 간 중단(cross-release stop)을 유지하며(어느 쪽도 replayable이 아니고 삭제도 아닙니다), 어느 쪽도 자동이 아닙니다. 검사 실패가 롤백을 일으키지 않고, 대시보드나 Git push, 풀 리퀘스트로 만들어진 배포는 프로모션 대상도 롤백 대상도 되지 않습니다(그것은 handoff이며, 그렇게 명시됩니다). 호스트마다 지원하는 범위가 다르고, golive는 추측하지 않고 거부합니다. Netlify는 게시된 배포를 다시 읽을 수 있고 이전 배포를 복원할 수 있어 두 단계 모두 동작합니다. Vercel은 프로덕션이 무엇을 서비스하는지 읽는 방법도, golive가 실행해 본 프로모션/롤백 호출도 제공하지 않으므로 Vercel에서는 아무것도 프로모션하거나 롤백하지 않고, 그 이유를 경고로 알려 줍니다. production-release는 프로덕션이 서비스하는 것을 증명하고, 이전에 무엇을 서비스했는지 밝히고, golive가 기록한 적 없는 배포는 handoff로 보고합니다. 이 단계 id들이 추가되면 계획의 id가 바뀌므로, 적용하지 않은 승인은 다시 계획해야 합니다. 배포별 읽기를 제공하지 않는 호스트(Vercel)에서는 프리뷰 검사가(따라서 프로모션도) skip하며, 추측하는 대신 그 사실을 보고합니다. 드리프트 감지는 아래의 읽기 전용 golive status 명령으로 존재합니다(인증 검증에서 읽기 전용으로 실행됐고 그 경로가 통과한 뒤에는 조치할 것이 없었습니다. 다만 이 명령이 비교하는 DNS, 환경, webhook, 배포 기준선은 아직 live 증거가 없습니다). 그리고 프리뷰 배포는 아직 이 명령이 비교하는 대상에 포함되지 않습니다.
• 🗺️ 백업과 복구: 보존 기간, 복원 훈련, 장애 대응 절차, 승인된 정리. 승인된 teardown은 golive가 만든 것을 제거합니다. 백업과 복원은 계속 사람이 감독하는 수동 작업입니다.
• ✅ 제거 / teardown: golive가 만든 리소스의 승인된 목록화와 제거. golive teardown은 제거를 계획하고, golive가 만들었다고 증명할 수 있는 것만 삭제하며(소유권 증명과 --confirm-destroy), 삭제한 뒤 DNS 존에서 golive 소유 레코드 목록과 호스트 자체의 프로젝트 읽기를 다시 확인합니다. 지울 수 없는 것을 조용히 흘려보내지 않습니다. 남은 것 — 읽을 수 없는 존, 제거할 수 없는 호스트 프로젝트, 로그인하지 않은 프로바이더 — 은 무엇이 남았고 정확히 어떻게 고칠지 밝히는 handoff가 되고, Supabase/Neon 프로젝트와 Resend 발신 도메인은 계속 수동 handoff로 남습니다 (#9). 제거하면 그 리소스에 대해 golive가 기록한 기준선도 사라지므로 golive status가 golive 자신의 teardown을 드리프트로 보고하지 않고, golive가 폐기한 발신 키는 프로바이더가 확인할 읽기 방법을 제공하지 않으므로 통과가 아니라 경고로 보고됩니다.
• 🗺️ 비용과 할당량: 요금제 선택, 예산, 알림, 용량 점검. 범위가 한정된 무료 요금제 보호 장치는 오늘도 있습니다. 지속적인 비용 관리는 계획 단계입니다.
• 🚧 출시 필수 요소: 메타데이터, 공유 미리보기, 색인, 접근성, 지원 링크, 소유자가 검토한 정책 페이지. 읽기 전용 site-metadata 검사는 프로덕션 페이지 자체의 <head>를 한 번 읽고 title, description, canonical 링크, Open Graph/Twitter 공유 태그를 보고합니다(title, description, 공유 태그가 없거나 og:image/og:url이 절대 URL이 아니면 경고만 하고 실패하지 않습니다. golive는 앱 코드를 수정하지 않으므로 고칠 곳은 당신의 저장소입니다). 아직 mock으로만 커버되며 live 실행은 없습니다. 공유 미리보기, 색인, 접근성, 지원 링크, 정책 페이지는 계획 단계로 남아 있습니다.
• 🚧 소유권과 인계: 계정, 리소스, 접근 권한, 갱신 책임, 유지 관리 지침. golive handoff --write는 로그인 경로, 소유권 증명, 반복 작업, 제거 게이트를 GOLIVE_HANDOVER.md에 기록하고 모든 행에 검증됨·기록됨·검증 불가·알 수 없음 중 하나를 표시합니다. golive status는 그 항목들을 요청 시 다시 읽습니다. golive가 기록한 기준선과 지금의 프로바이더 상태를 비교하고, 읽지 못한 것은 무엇인지 밝힙니다. 드리프트 기준선 재설정은 계속 수동이며 승인이 필요합니다 — 명령은 구현되어 있고 인증 검증에서 읽기 전용으로 실행됐지만, 모든 드리프트 대상에 대한 live 검증은 아직 남아 있습니다.

사람이 반드시 필요한 단계도 있습니다. 약관 동의, 본인 확인, 구매, 요금 선택, 프로바이더가 요구하는 심사가 그렇습니다. 그래도 “안내형”은 다음 행동이 분명하고, 봐야 할 페이지와 필요한 권한이 정확하고, 이후 확인이 있고, 같은 워크플로로 돌아오는 것이어야 합니다. 앱 자체에 코드 변경이 필요하면 GoLive는 코딩 에이전트에게 구체적인 작업을 주고 결과를 다시 확인해야 합니다. 서로 단절된 설정 대화 열두 개를 당신이 조율하게 만들어서는 안 됩니다.

다음 순서: 남은 출시 경로를 완성하고 live 테스트합니다 — 계정 격리의 live 실행(Supabase에 구현되어 있고 mock으로 커버되지만 실제 프로젝트에서는 아직 실행하지 않았습니다), live 모드 결제 흐름, Cloudflare DNS 어댑터 — 그다음 앱 아키텍처와 지속 운영 범위를 넓힙니다.

이것들은 방향이지 출시 일정이 아닙니다. 어떤 기능이 실험 단계를 벗어나려면 계정 설정, 연결, 검증, 복구를 모두 실제로 실행해 봐야 합니다. 이 체크리스트의 어느 항목이든 기여를 환영하며, 특히 실제 출시가 어디에서 막히는지 알려 주는 증거가 도움이 됩니다.

리포트에는 pass, fail, warning, skipped 결과와 사람이 해야 할 남은 단계가 기록됩니다. 검사 항목에는 계정 접근, 환경 변수 이름, 프로바이더가 확인한 배포 URL, 공개 JavaScript에서의 시크릿 패턴, 데이터베이스 접근, 지원되는 인증/webhook/DNS 설정, 그리고 호스트가 답할 수 있는 경우 프로바이더가 말하는 프로덕션 서비스 배포가 포함됩니다.

배포가 준비됐다는 것이 앱이 동작한다는 증거는 아닙니다. 환경 변수 이름은 값이 틀려도 존재할 수 있습니다. 이메일 도메인이 검증됐다는 것이 받은편지함 전달을 증명하지도 않습니다. 서명된 결제 이벤트, 가입, 앱의 비즈니스 흐름에는 기능 테스트가 필요합니다. skip은 통과가 아닙니다.

앱에는 golive.yaml, .golive/state.json, .golive/report.json, GOLIVE_REPORT.md가 생깁니다. state는 복구를 위해 리소스 ID와 단계 증거를 보존하며, 자격 증명 저장소가 아닙니다. golive teardown은 자체 승인과 --confirm-destroy를 거쳐 golive가 만든 것을 제거합니다. 그 리소스들에 대한 프로바이더 간 롤백, 복원, 일반적인 정합성 조정 명령은 없습니다 — release:rollback(선택적)은 golive 자신이 기록한 이전 배포로 프로덕션을 다시 가리킬 뿐이고, 데이터·DNS·결제·이메일 리소스는 건드리지 않습니다.

golive handoff --write는 소유권 문서를 추가합니다. 저장소 루트의 GOLIVE_HANDOVER.md와 그 JSON 원본인 .golive/handover.json입니다. 여기에는 계정과 로그인 경로, golive가 만든 모든 리소스와 그것이 golive의 것이라는 증거, 아직 수동인 항목, 반복되는 작업, 제거 방법, 각 항목을 다시 확인하는 명령이 담깁니다. 각 행은 그 실행에서 검증됐는지, 이전에 기록됐는지, golive가 검증할 수 없는지, 알 수 없는지를 밝힙니다. golive는 청구 데이터를 읽지 않으므로 비용 수치는 적지 않습니다. 이 파일들에는 시크릿 값이 없지만, 시크릿이 아닌 메타데이터만으로도 비공개 리소스를 특정할 수 있으니 공유하기 전에 검토하세요. --write는 golive가 생성하지 않은 파일을 --force 없이는 절대 덮어쓰지 않습니다.

golive status는 다음 질문을 던집니다. golive가 한 일을 기록한 뒤로 golive 몰래 바뀐 것이 있는가? 이 명령은 기록된 기준선 — golive가 쓴 DNS 레코드, golive가 전달한 환경 변수 이름, 등록된 webhook 엔드포인트, 도메인 연결, 데이터베이스 프로젝트와 그 연결 선택자, 발신 도메인, 앱의 키 뒤에 있는 결제 계정, 호스트 프로젝트 — 을 지금 읽은 값과 비교하고, 양쪽에 이름표를 붙입니다. expected (recorded by golive <time>)와 observed (read now)입니다. 각 항목은 누가 조치할 수 있는지 말해 줍니다. 검사를 다시 실행하거나, 계획을 다시 세우고 승인된 변경을 적용하거나, 사람만 내릴 수 있는 결정입니다. 읽기 전용이므로 리포트 파일도, 프로바이더 쓰기도, state 변경도 없고, 조치할 것이 있으면 종료 코드 2로 끝납니다. 읽을 수 없는 프로바이더는 검증 불가로 보고합니다 — '깨끗함'도, 실패도 아닙니다 — 그리고 스스로 기준선을 다시 잡는 일은 없습니다. 드리프트는 의도적으로 게이트가 아닙니다. plan, apply, verify는 이 명령을 참조하지 않습니다. status는 구현되어 있고 Supabase 인증 검증 중 읽기 전용으로 실행됐지만(실패한 단계가 조치 가능 항목으로 드러났고, 완료된 뒤에는 빈 목록이었습니다), 남은 드리프트 대상에 대한 live 검증은 아직 남아 있습니다.

• 계정을 바꾸기 전에 승인부터 받습니다. 계획은 대상과 의도한 쓰기를 명시하고, apply는 승인된 계획 id와 --yes가 없으면 거부합니다. 설치된 release가 바뀌면 이전 승인은 무효가 됩니다. DNS, live 결제, 삭제 단계에는 추가 게이트(--confirm-dns, --confirm-live, --confirm-destroy)가 있고, 프로젝트의 최초 프로덕션 배포에도 --confirm-live가 필요합니다. 예전에는 계획을 승인하는 것만으로 처음 프로덕션에 쓰기에 충분했기 때문입니다. 신뢰, 접근, 통제에서 각 게이트를 하나씩 짚습니다.
• 시크릿은 채팅 밖에 둡니다. 지원되는 벤더 로그인은 재사용합니다. macOS에서는 네이티브 숨김 입력 대화 상자가 필요한 API 키를 저장할 수 있고, 그렇지 않으면 사용하는 에디터가 대체 수단입니다. 키는 앱 저장소 밖의 로컬 평문 파일 ~/.config/golive/credentials(모드 0600)에 있습니다 — OS 키체인이 아니므로 당신 사용자 권한으로 실행되는 무엇이든 읽을 수 있습니다. 실행 코드는 값을 argv, 계획, state, 리포트, 명령 출력에 남기지 않고 값 대신 지문(fingerprint)을 저장합니다. golive credentials --remove NAME --yes는 저장된 항목 하나를 되돌릴 수 없이 삭제합니다. 실제로 접근을 끝내는 것은 프로바이더에서 토큰을 폐기하는 일입니다. Mac 로그인 비밀번호는 macOS/벤더 인증 프롬프트에 남습니다. GoLive는 키 대화 상자에 비밀번호를 입력하라고 요청하지 않습니다. 전체 경계는 신뢰, 접근, 통제에 있습니다.
• 업데이트에는 주인이 있습니다. Skills CLI가 자기 설치를 관리합니다. 선택적인 자체 설치 프로그램은 번들 전체 업데이트와 로컬 롤백을 지원하며, 자동 교체는 기본적으로 꺼져 있습니다. 업데이트는 배포 실행 사이에 하세요. 계획과 그 적용 사이에는 절대 하지 마세요. 클라우드 리소스는 롤백의 영향을 받지 않습니다.
• 계정은 계속 당신의 것입니다. GoLive는 서비스를 구매하거나 청구 계정을 만들지 않습니다. 코딩 에이전트, 프로바이더, 설치 프로그램은 각자의 데이터 처리 방침을 따릅니다.

🤝 아직 초기 단계이고, GoLive를 함께 다듬어 갈 분들을 찾고 있습니다. 버그 리포트, 기능 아이디어, 문서 수정, 풀 리퀘스트 모두 환영합니다. 기여하려고 어댑터를 만들 필요는 없습니다. 이해하기 어려운 로그인 안내나 실제 출시에서 막힌 지점도 유용한 피드백입니다.

문제를 알리거나 아이디어를 논의하려면 이슈를 열고, 범위가 좁은 PR은 바로 보내 주세요. 프로바이더나 워크플로를 크게 추가하는 작업이라면 먼저 이슈를 열어 범위를 함께 맞추는 편이 좋습니다. 리포트에 시크릿이나 원본 인증 응답을 절대 포함하지 마세요.

로컬 설정, 테스트, 첫 기여는 **CONTRIBUTING.md**를 보세요. 아키텍처, 신뢰, 접근, 통제, 복구, 프로바이더 범위, 검증 기록에서 무엇이 있고 어디에 도움이 필요한지 설명합니다.

MIT 라이선스. 함께 포함된 서드파티 고지는 THIRD_PARTY_NOTICES.md에 있습니다.