브라우저 IDE에서 Vercel 또는 Netlify로 배포하기

가장 분명한 사례는 CLI 설치가 번거롭거나 금지된 기기입니다. Chromebook, 학교 실습실 PC, 잠긴 회사 데스크톱은 브라우저 탭은 열 수 있지만 Node.js, Git, 프로바이더 CLI를 항상 설치할 수는 없습니다. 브라우저 IDE는 편집 단계에서 이미 그 요구를 없앱니다. 배포는 보통 개발자를 터미널로 되돌리는 마지막 단계입니다. 같은 탭에 두면 순환이 닫힙니다. 로컬 툴체인 없이 편집, 미리보기, 게시가 끝납니다. 두 번째는 속도입니다. 랜딩 페이지, 프로토타입, 고객 데모는 저장소나 CI 파이프라인보다 URL이 먼저 필요할 수 있습니다. 브라우저 패널은 현재 스냅샷을 게시하고 어디에 공개됐는지 알려줍니다. 편의에는 경계가 있습니다. 이것은 직접 업로드이지 배포 파이프라인이 아닙니다. 브랜치를 감시하지 않고, 테스트를 실행하지 않으며, 환경 사이에서 빌드를 승격하지 않습니다. 그 일은 프로바이더의 Git 연동이나 CI의 몫입니다. 브라우저 경로는 첫 URL을 위한 것이지 전체 릴리스 과정을 위한 것이 아닙니다.

Deploy 대화상자는 두 프로바이더 API 위의 얇은 제어면입니다. Deploy now를 누르면 GB Coder는 Download ZIP과 동일한 파일 번들을 만듭니다. 이 점이 중요합니다. 스타일시트를 빠뜨리거나 외부 라이브러리를 잊을 수 있는 두 번째 패키징 경로는 없습니다. 일반 프로젝트는 index.html, style.css, script.js, README가 됩니다. React 또는 Vue 프로젝트는 index.html, package.json, vite.config.js, .gitignore, README, src/ 아래 소스로 구성된 Vite 형태 트리가 됩니다. 대화상자의 번들 요약은 탭을 떠나기 전 정확한 파일 수와 비압축 크기를 보여줍니다. Vercel은 배포 엔드포인트로 파일을 인라인 JSON으로 받습니다. Netlify는 ZIP을 요청 본문 그대로 받습니다. Vercel은 프로젝트를 빌드하거나 제공하고, Netlify는 업로드된 파일을 수동 배포로 게시합니다. LadeStack 서버가 중간에 없고, 사용자 기기에서 CLI도 실행되지 않습니다. 브라우저가 클라이언트, 프로바이더가 호스트, 토큰이 유일한 자격 증명입니다. 원클릭은 인터페이스를 뜻하며 작업량을 뜻하지 않습니다. 패키징, 업로드, 원격 처리, TLS는 여전히 순서대로 일어납니다.

번들이 다른 이유는 두 프로젝트 유형의 처리가 다르기 때문입니다. 일반 HTML/CSS/JavaScript 프로젝트에는 package.json이 없습니다. Vercel에는 프레임워크를 쓰지 말라고 지정하고 파일을 정적 사이트로 제공합니다. Netlify는 ZIP을 그대로 게시하며, 이는 정적 파일에도 올바릅니다. 설치할 것도 컴파일할 것도 없어 첫 배포는 보통 빠릅니다. React 또는 Vue 프로젝트에는 생성된 package.json, Vite 설정, 소스 파일이 포함됩니다. Vercel에서는 프로바이더가 Vite를 감지하고 의존성을 설치한 뒤 프로덕션 빌드를 실행해 출력을 게시합니다. 브라우저 안의 시뮬레이션이 아니라 실제 클라우드 빌드이므로 1분 이상 걸릴 수 있습니다. Vercel은 편집기에 우연히 로드된 버전이 아니라 package.json에 기록된 버전을 사용합니다. Netlify의 수동 ZIP 배포는 빌드 명령을 실행하지 않으므로 같은 Vite 소스 트리가 업로드된 그대로, 컴파일되지 않은 채 게시됩니다. Netlify에서 React 또는 Vue를 쓰려면 프로바이더의 Git 통합을 사용하세요. Netlify 원클릭 경로는 정적 출력만 게시합니다. 외부 라이브러리와 주입 설정은 이미 번들에 반영되어 있습니다. Vercel 빌드가 비공개 패키지, 네이티브 바이너리, 빌드 이미지에서 닿을 수 없는 서비스에 의존하면 로컬 미리보기가 작동해도 빌드는 실패합니다. 어느 경우인지는 로그로 확인할 수 있습니다.

두 프로바이더 모두 개인 액세스 토큰으로 인증합니다. 프로바이더 비밀번호도, GB Coder 계정도 아닙니다. 대화상자는 선택한 프로바이더의 토큰 페이지로 연결하고 범위를 쉬운 말로 설명합니다. Vercel 토큰은 계정이나 팀이 닿을 수 있는 모든 프로젝트에 게시할 수 있습니다. 팀 범위 토큰이 있으면 그것을 사용하세요. Netlify 토큰은 계정이 접근할 수 있는 사이트 전체에 작용하므로 더 좁은 옵션이 없다면 계정 전체로 취급하세요. 이 용도로 토큰을 만들고, 필요한 만큼만 짧게 유지하고, 프로젝트가 더 이상 필요로 하지 않을 때 프로바이더에서 폐기하세요. GB Coder는 Deploy now를 활성화하기 전에 토큰이 있는지, 번들이 로컬 제한 안에 드는지 확인합니다. 토큰은 기본적으로 탭 메모리에만 보관됩니다. Remember on this device는 선택 사항입니다. 보안 컨텍스트에서는 localStorage에 쓰기 전에 AES-GCM으로 봉인하고, 그렇지 않으면 기억할 경우 평문으로 저장된다고 대화상자가 경고합니다. 범위와 폐기가 가장 중요한 통제입니다.

프로젝트를 열고 툴바에서 Deploy를 선택하세요. 좁은 화면에서는 오버플로 메뉴에 있습니다. 기본값은 Vercel이고 Netlify는 한 번 더 클릭하면 됩니다. 프로젝트 이름은 현재 프로젝트에서 미리 채워집니다. GB Coder는 이름을 소문자로 바꾸고 잘못된 문자를 하이픈으로 바꾸며 요청할 호스트 이름(예: your-project.vercel.app)을 보여줍니다. 토큰을 붙여 넣고 기억할지 정한 뒤 번들 요약을 확인하세요. 파일 수나 크기가 제한을 넘으면 대화상자가 이유를 설명하고 버튼을 비활성 상태로 둡니다. Deploy now를 누르세요. 프로바이더가 프로젝트나 사이트를 만들고 번들을 받아 배포 처리를 시작합니다. 배포가 준비되면 성공 화면에 공개 URL, 파일 수, 업로드 크기, 경과 시간, 휴대폰에서 열 수 있는 QR 코드가 표시됩니다. Copy URL과 Visit site는 전달용이고 Build logs는 프로바이더의 로그 화면을 엽니다. Netlify 사이트 이름은 전 세계 공용이므로 원하는 이름이 이미 사용 중일 수 있습니다. 그러면 다른 이름이 배정되고, GB Coder는 입력한 주소가 아니라 실제로 공개된 주소를 알려줍니다.

진행 표시줄은 패키징, 업로드, 빌드, 보안 설정, 완료 순으로 이동합니다. Netlify에서 빌드 표시는 프로바이더의 처리 과정을 뜻하며 빌드 명령을 의미하지 않습니다. 클라이언트의 보고일 뿐, 프로바이더의 예측이 아닙니다. 비율은 처음 두 단계에서 빠르게 오르고 프로바이더가 원격 작업을 끝내는 동안 100 아래에 머뭅니다. 의도된 동작입니다. 원격 작업 시간은 예측할 수 없고, 99%까지 질주하는 막대는 거짓말이 되기 때문입니다. GB Coder는 1.5초마다 프로바이더를 폴링하고 상태가 바뀌면 메시지를 갱신합니다. 업로드 요청에는 2분 제한 시간이 있습니다. 패널은 배포 폴링을 3분 후 중단하고 대시보드로 안내합니다. 브라우저가 보기를 멈춰도 배포는 끝날 수 있기 때문입니다. 취소, 대화상자 닫기, Escape 키는 진행 중인 요청과 폴링 루프를 중단합니다. 프로바이더가 이미 배포를 받아들였다면 그쪽에서 배포가 계속될 수 있습니다. 취소가 롤백을 뜻한다고 가정하지 말고 대시보드를 확인하세요. 배포가 실패하면 프로바이더의 로그가 신뢰할 수 있는 출처입니다.

Deploy again은 폼으로 돌아갈 뿐 마지막 번들을 즉시 다시 보내지 않습니다. 프로젝트가 바뀌었거나 이름을 조정해야 하거나 토큰이 만료됐을 때 유용합니다. 그다음 Vercel과 Netlify는 같은 주소로 다른 경로를 갑니다. Vercel은 지정된 프로젝트에 배포를 만들고 프로덕션을 대상으로 합니다. 같은 프로젝트 이름으로 반복 배포하면 그 프로젝트가 갱신되며, 배포별 URL보다 프로덕션 별칭이 우선하므로 공유하는 주소는 보통 안정적으로 유지됩니다. Netlify는 새 사이트를 만들지 않고 기존 사이트를 갱신하려면 사이트 ID가 필요합니다. GB Coder는 정리된 사이트 이름을 키로 그 ID를 localStorage에 기억합니다. 브라우저 저장소를 지우거나, 브라우저를 바꾸거나, 이름을 바꾸거나, Netlify에서 사이트를 삭제하면 다음 배포는 이전 사이트를 찾지 못하고 새로 만듭니다. 그래서 Netlify 프로젝트 이름을 바꾸면 이전 사이트가 계정에 남을 수 있습니다. 두 프로바이더 모두 배포 기록, 사용자 지정 도메인, 액세스 제어, 롤백을 대시보드에서 관리합니다. GB Coder 패널은 업로드와 공개 URL만 다룹니다. 여기서 하는 모든 배포는 프로덕션 배포이며 브랜치 미리보기나 환경 선택기는 없습니다.

요청이 탭을 떠나기 전에 두 가지 제한이 적용됩니다. 900개 파일과 비압축 64MB입니다. 프로바이더 자체 한도보다 낮게 두어 거대한 업로드가 브라우저 세션 중간에 실패하지 않게 합니다. 미디어가 많은 사이트는 큰 이미지와 동영상을 프로젝트 번들이 아니라 CDN이나 Git에 두는 편이 좋습니다. 오류는 원인별로 구분됩니다. 401은 토큰 거부, 403은 보통 계정이나 팀 권한 부족, 413 또는 429는 페이로드 과대나 프로바이더 속도 제한, 422는 프로젝트가 유효하지 않다고 거부된 경우, 5xx는 보통 일시적입니다. Vercel에서는 프레임워크 빌드 실패가 다릅니다. 업로드는 성공했고 빌드가 실패한 것이므로 새 토큰을 붙이지 말고 로그를 읽으세요. Vercel 빌드에 환경 변수가 필요하면 또 다른 경계입니다. 배포 대화상자에는 환경 변수 편집기가 없습니다. Vercel 프로젝트 설정에서 값을 지정하고 다시 배포하세요. 첫 빌드는 값을 설정할 프로젝트가 생기기 전에 실패할 수 있습니다. Netlify의 수동 ZIP 경로에는 빌드 단계가 없으므로 여기에는 해당하지 않습니다. 3분 폴링 제한은 배포 실패가 아니라 기다리기의 실패입니다.

배포 경로는 직접적입니다. 브라우저가 토큰을 사용해 api.vercel.com 또는 api.netlify.com을 호출합니다. 자격 증명을 저장하는 프록시가 없고 패널을 쓰는 데 LadeStack 계정도 필요 없습니다. 토큰은 기본적으로 세션에만 있고, 보안 컨텍스트에서 기억을 선택한 경우에만 AES-GCM으로 봉인됩니다. 이는 브라우저 프로필 백업이나 지원 번들에서 읽히는 토큰을 막지만, 탭이 열려 있는 동안 같은 출처에서 실행되는 악성 코드는 막지 못합니다. 가능한 가장 좁은 토큰을 사용하고 만료를 설정하고 작업이 끝나면 프로바이더에서 폐기하세요. 소유권은 토큰을 따릅니다. 프로젝트나 사이트는 그것을 소유한 프로바이더 계정에, 해당 약관, 할당량, 로그, 청구 아래 생성됩니다. GB Coder는 local-first를 유지하지만 배포는 프로젝트를 프로바이더로 명시적으로 내보내는 일입니다. 프로바이더는 사이트 소스를 받고 결과는 기본적으로 공개 HTTPS URL입니다. 비밀번호 보호, SSO, 사용자 지정 도메인은 프로바이더 기능입니다. 브라우저 프로필이 프로젝트의 유일한 다른 보관 장소가 되지 않도록 ZIP이나 GitHub 사본을 남기세요.

작은 사이트를 빠르게 공개할 때 이 경로를 쓰세요. 랜딩 페이지, 포트폴리오, 수업 데모, 고객 리뷰용 프로토타입, 정적 문서 페이지 등입니다. 프로젝트가 이미 GB Coder에 있고 대안이 ZIP을 내보내 터미널을 열고 내 것이 아닌 기기에서 CLI를 설정하는 일뿐일 때도 맞습니다. 모노레포, 데이터베이스가 있는 서버 렌더링 앱, 비공개 레지스트리 자격 증명이 필요한 빌드, 브랜치 미리보기와 승인으로 릴리스하는 팀, 업로드 제한을 넘는 자산에는 맞지 않습니다. 그 일은 프로바이더의 Git 연동, CI 파이프라인, 데스크톱 환경의 몫입니다. 두 접근은 공존할 수 있습니다. 브라우저에서 초안을 쓰고 반복하며, 이력이 필요해지면 소스를 GitHub에 push하고, 프로덕션 빌드는 CI가 게시하게 하세요. 실용적인 순서는 짧습니다. 휴대폰 너비에서 미리보기를 확인하고, 번들 요약을 보고, 배포하고, 다른 기기에서 공개 URL을 열고, 빌드 로그를 저장하세요. 시험하려면 /app/projects의 프로젝트 대시보드를 열고 프로젝트를 만들거나 연 뒤 Deploy를 선택하세요. 설정 참고 자료는 문서에 있습니다.