배포(Deployment)란? 내 컴퓨터에서 만든 웹사이트를 인터넷에 공개하는 과정
AI에게 “간단한 할 일 앱 만들어 줘”라고 부탁했더니, 그럴듯한 웹페이지가 완성됐다고 가정해 보겠습니다. 내 컴퓨터에서 파일을 열면 제목과 버튼도 보이고, 할 일도 추가할 수 있습니다. 그런데 친구에게 “이 앱 써 봐”라고 말했더니 친구는 어디로 접속해야 할지 모릅니다. 내 컴퓨터에서 잘 작동하는 프로그램과 다른 사람이 인터넷으로 사용할 수 있는 프로그램은 다르기 때문입니다. 이 둘을 연결하는 과정에서 자주 등장하는 말이 배포(Deployment)입니다. 배포는 만든 웹사이트나 앱의 파일·프로그램과 필요한 설정을 실제로 사용될 환경에 올려, 정해진 주소로 접근하거나 서비스를 실행할 수 있게 만드는 작업입니다. 이번 글에서는 AI를 잘 모르는 사람도 이해할 수 있도록 배포의 뜻 → 로컬 실행과의 차이 → 호스팅·도메인 → 공개/미리보기 배포 → 정적·동적 사이트 → 비용·보안·오류·되돌리기까지 차근차근 알아보겠습니다. 이 글은 2026년 10월 16일 기준 MDN·GitHub·Cloudflare 공식 문서를 검토해 작성했습니다. 아래 URL과 파일은 설명용 가상 예시이며, 글 작성자가 실제 사용자 사이트를 배포한 결과가 아닙니다.
이 글의 순서
- 1. 배포를 한 문장으로 설명하면?
- 2. 내 컴퓨터에서 작동하는데 왜 다른 사람은 못 보나요?
- 3. 배포와 호스팅은 어떻게 다르나요?
- 4. 도메인을 사면 배포도 자동으로 되나요?
- 5. 빌드(Build), 배포(Deploy), 공개 확인은 다릅니다
- 6. 정적 사이트와 동적 앱은 배포 방법이 다를 수 있어요
- 7. 인터넷에 공개할 파일은 어떤 모습인가요?
- 8. 어떤 방법으로 배포할 수 있나요?
- 9. 미리보기 배포와 실제 배포는 무엇이 다른가요?
- 10. GitHub 저장소가 비공개면 배포된 사이트도 비공개인가요?
- 11. 배포 전에 꼭 확인할 일곱 가지
- 12. 배포했다면 실제 주소로 확인하세요
- 13. 배포 후 자주 발생하는 오류
- 14. 잘못 배포했다면 이전 버전으로 되돌릴 수 있나요?
- 15. AI에게 배포 방법을 물을 때 좋은 질문 예시
- 자주 묻는 질문(FAQ)
- 마무리: 배포는 ‘완성’이 아니라 ‘실제 사용 환경에 올리는 과정’입니다
1. 배포를 한 문장으로 설명하면?
배포(Deployment)는 개발한 프로그램이나 웹사이트의 새로운 버전을 실제로 사용할 서버·호스팅 환경에 전달하고 실행·제공하도록 만드는 과정입니다.
예를 들어 내 컴퓨터에서 만든 index.html 파일을 다른 사람도 볼 수 있는 웹 호스팅에 올리고, 인터넷 주소를 통해 열리도록 설정하는 것도 기본적인 배포의 예입니다.
여기서 중요한 부분은 “파일을 만들었다”와 “인터넷에 공개됐다”는 같은 말이 아니라는 점입니다.
웹페이지 하나를 만드는 데 성공했더라도 그것을 인터넷에 게시하지 않았다면 다른 사람에게 보여 줄 주소가 없을 수 있습니다.
반대로 배포를 했더라도 주소를 잘못 연결하거나 필요한 파일이 빠져 있다면 방문자에게 오류 화면만 나타날 수 있습니다.
따라서 배포를 이해할 때는 다음 네 가지를 구분하세요.
만들기: HTML·CSS·JavaScript 또는 앱 코드를 작성합니다.
시험하기: 내 컴퓨터에서 동작·오류·디자인을 확인합니다.
배포하기: 다른 사용자가 접근하는 환경에 파일·프로그램을 올립니다.
공개 상태 확인하기: 실제 인터넷 주소에서 정상 작동하는지 확인합니다.
배포 버튼을 눌렀다는 사실만으로 마지막 단계까지 자동으로 확인됐다고 생각하면 안 됩니다.
2. 내 컴퓨터에서 작동하는데 왜 다른 사람은 못 보나요?
내 컴퓨터 안에만 있는 웹페이지 파일은 보통 다른 사람에게 자동으로 공개되지 않습니다. 웹브라우저에서 파일을 직접 열었다면 주소가 다음처럼 보일 수 있습니다.
로컬 파일 경로 예시: /Users/example/Desktop/index.html
위 주소는 사용자의 실제 컴퓨터 경로가 아닌 형식 예시입니다. 이것은 내 컴퓨터의 파일을 브라우저가 연 상태입니다. 친구의 컴퓨터에는 그 파일이 없으므로 같은 주소로 접속할 수 없습니다. 개발할 때 자주 보이는 다른 주소도 있습니다.
http://localhost:3000
localhost는 보통 현재 실행 중인 내 컴퓨터를 뜻합니다.
컴퓨터에서 개발용 서버를 실행하면 이런 주소로 페이지를 확인할 수 있습니다. 그러나 친구가 자기 컴퓨터에서 localhost:3000을 입력하면 친구 컴퓨터의 해당 주소를 찾습니다.
특수한 네트워크 설정이나 터널 서비스를 사용하면 외부 접근이 가능할 수도 있지만, localhost 주소를 알려 주는 것만으로 인터넷 공개가 되지는 않습니다.
마지막으로 실제 배포가 끝나면 다음과 같은 인터넷 주소가 제공될 수 있습니다.
https://example-project.pages.dev
이 주소도 형식 설명을 위한 예시이며 실제 프로젝트가 있다는 뜻은 아닙니다. 핵심은 컴퓨터에만 있는 주소 → 로컬 개발 주소 → 인터넷에서 접속할 수 있는 주소의 차이를 이해하는 것입니다.
3. 배포와 호스팅은 어떻게 다르나요?
자주 함께 나오는 말이 호스팅(Hosting)입니다. 두 용어는 비슷하지만 역할이 다릅니다. 호스팅: 다른 사람이 웹페이지에 접근할 수 있도록 파일이나 프로그램을 제공·실행하는 환경 또는 서비스입니다. 배포: 우리가 만든 새 파일이나 새 버전을 그 호스팅 환경에 올리고 적용하는 작업입니다. 비유해 보겠습니다. 호스팅은 가게를 운영할 장소이고, 배포는 만든 상품을 그 장소에 진열하는 과정과 비슷합니다. 가게 장소가 있다고 상품이 자동으로 진열되지는 않겠지요. 반대로 상품을 만들었다고 손님이 들어올 가게가 자동으로 마련되는 것도 아닙니다. 웹사이트에서도 마찬가지입니다. 호스팅 서비스가 있더라도 현재 사이트 파일을 올리지 않았다면 정상적인 페이지가 없을 수 있습니다. 파일을 새로 배포하면 호스팅 서비스가 그 버전을 방문자에게 보여 줍니다. 대표적인 웹 호스팅 방식에는 정적 웹사이트 파일을 제공하는 방식과 서버 프로그램을 실행하는 방식 등이 있습니다. 이 차이는 뒤에서 다루겠습니다.
4. 도메인을 사면 배포도 자동으로 되나요?
아닙니다.
도메인(Domain)은 인터넷에서 사람들이 접속할 때 사용하는 주소 이름입니다.
예를 들어 www.example.com처럼 기억하기 쉬운 이름을 붙이는 데 사용합니다.
반면 호스팅 서비스는 실제 웹페이지 파일이나 앱 프로그램을 제공하는 장소입니다.
도메인과 호스팅을 별도 업체에서 관리한다면 DNS 설정 등을 통해 도메인이 올바른 서비스로 연결되도록 설정해야 할 수 있습니다.
예를 들어 다음과 같은 과정입니다.
- 웹사이트 파일을 호스팅 서비스에 배포합니다.
- 서비스가 제공한 기본 주소로 사이트가 열리는지 확인합니다.
- 원하는 사용자 도메인을 호스팅 서비스에 등록합니다.
- 호스팅 안내에 맞춰 DNS 레코드나 네임서버를 설정합니다.
- 사용자 도메인으로도 실제 사이트가 열리는지 확인합니다. 여기서 알아둘 점이 있습니다. 도메인을 보유했다고 웹사이트가 만들어진 것은 아닙니다. 또한 배포가 끝났다고 내 도메인이 자동으로 연결되거나 HTTPS 설정이 항상 완료된 것은 아닙니다. 서비스마다 자동화 수준이 다르므로 실제 호스팅 서비스의 안내를 확인해야 합니다.
5. 빌드(Build), 배포(Deploy), 공개 확인은 다릅니다
AI 코딩 도구와 호스팅 서비스에서는 Build라는 용어도 자주 보입니다.
빌드는 웹사이트 코드를 실제 실행·게시할 수 있는 결과물로 만드는 과정입니다.
예를 들어 웹 프레임워크로 만든 앱은 원래 개발 파일을 그대로 올리는 대신 HTML·CSS·JavaScript 등의 빌드 결과물을 만들어 호스팅에 전달할 수 있습니다.
반면 간단한 index.html 하나만 있는 사이트는 별도의 복잡한 빌드 과정 없이도 배포할 수 있습니다.
| 단계 | 하는 일 | 완료 여부를 확인하는 방법 |
|---|---|---|
| 작성 | 웹페이지와 프로그램을 만듦 | 소스 파일·내용 확인 |
| 빌드 | 게시 가능한 산출물 생성 | 빌드 성공 로그와 파일 확인 |
| 테스트 | 기능과 오류 검증 | 실제 동작 점검 |
| 배포 | 호스팅에 새 버전 반영 | 배포 성공 상태·버전 확인 |
| 공개 확인 | 외부 주소에서 방문자 관점 검수 | 실제 URL·모바일·기능 확인 |
| 검색엔진 색인 | 검색서비스가 페이지 발견·평가 | 별도 검색 도구·색인 상태 확인 |
검색엔진 색인은 배포 자체에 포함되는 단계가 아닙니다. 사이트를 인터넷에 공개했다고 검색 결과에 즉시 표시되는 것은 아닙니다. 검색엔진이 사이트를 발견하고 색인할 수 있도록 별도 조건을 충족해야 합니다. 이 글은 배포의 의미와 검수 방법에 집중하고, 구체적인 색인 요청 방법은 별도 주제로 다루는 것이 적절합니다.
6. 정적 사이트와 동적 앱은 배포 방법이 다를 수 있어요
초보자에게 중요한 차이 중 하나는 정적 사이트(Static site)와 서버 기능이 필요한 동적 앱입니다. 정적 사이트는 HTML·CSS·JavaScript·이미지 같은 파일을 호스팅에서 브라우저로 전달하는 방식입니다. 예를 들어 단순 소개 페이지, 문서 사이트, JavaScript만으로 화면의 할 일을 추가하는 교육용 앱을 생각할 수 있습니다. 동적 서버 앱은 사용자 로그인 정보 저장, 서버에서의 데이터베이스 처리, 비공개 API 키를 사용하는 외부 요청 등의 기능에 서버 측 프로그램이나 백엔드 서비스가 필요할 수 있습니다.
| 종류 | 대표적인 역할 | 호스팅을 고를 때 볼 점 |
|---|---|---|
| 정적 사이트 | HTML·CSS·JS 파일 제공 | 정적 파일 게시·도메인·HTTPS |
| 서버 측 앱 | 서버에서 코드 실행·인증·DB 연동 | 백엔드 실행·데이터 저장·비밀값 관리 |
| 혼합 방식 | 정적 프런트엔드 + 별도 API 서버 | 프런트엔드·API 연결과 권한 검증 |
예를 들어 GitHub Pages는 정적 웹사이트를 제공할 수 있지만 PHP, Python, Ruby 같은 서버 측 언어를 직접 실행하는 호스팅 기능은 지원하지 않습니다. 그렇다고 브라우저에서 JavaScript가 전혀 실행되지 않는다는 뜻은 아닙니다. 브라우저가 실행하는 JavaScript와 호스팅 서버에서 실행할 백엔드 코드는 구별해야 합니다. AI가 “배포만 하면 사용자 로그인과 DB 저장도 됩니다”라고 말한다면 실제 사용할 호스팅에 그런 기능이 있는지 확인하세요.
7. 인터넷에 공개할 파일은 어떤 모습인가요?
아주 작은 사이트라면 폴더 안에 다음 파일들이 있을 수 있습니다.
my-first-site/
index.html
style.css
script.js
images/
logo.png
각 파일의 역할은 간단합니다.
index.html: 처음 열리는 웹페이지의 기본 문서.
style.css: 글꼴·색·간격 등 화면의 표현.
script.js: 클릭이나 입력에 따른 화면 동작.
images/: 필요한 이미지.
예를 들어 다음처럼 매우 간단한 index.html을 만들 수 있습니다.
<!doctype html>
<html lang="ko">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>나의 첫 공개 웹페이지</title>
</head>
<body>
<h1>안녕하세요!</h1>
<p>이 페이지는 배포 개념을 연습하기 위한 예시입니다.</p>
<button type="button" id="test-button">작동 확인</button>
<p id="result"></p>
<script>
document.querySelector("#test-button")
.addEventListener("click", () => {
document.querySelector("#result").textContent =
"버튼이 작동했습니다.";
});
</script>
</body>
</html>
이 코드는 로컬 화면에서 텍스트를 변경하는 가상 교육용 예제입니다. 별도의 서버·DB·API 키 없이 간단한 정적 페이지에 넣을 수 있는 형태입니다. 이 파일을 배포할 수 있는 호스팅 서비스에 올리고 실제 인터넷 주소에서 열리도록 만들면 친구도 같은 페이지를 볼 수 있습니다. 하지만 현재 글 작성 과정에서 실제로 파일을 업로드하거나 공개 사이트를 만들지는 않았습니다.
8. 어떤 방법으로 배포할 수 있나요?
초보자가 접할 수 있는 배포 방법은 여러 가지입니다. 대표적으로 파일을 직접 업로드하는 방법, GitHub 저장소를 연결하는 방법, 명령줄 도구를 사용하는 방법 등이 있습니다.
| 방법 | 개념 | 초보자가 확인할 점 |
|---|---|---|
| 직접 업로드 | 빌드 결과 파일을 호스팅에 올림 | 파일 구성·배포 대상·한도 |
| Git 연동 | 저장소의 변경을 가져와 자동 빌드·게시 | 어느 브랜치가 실제 공개 사이트에 반영되는지 |
| 명령줄 도구 | 터미널 명령으로 산출물을 게시 | 계정 로그인·프로젝트·환경 설정 |
| 웹사이트 빌더 | 서비스가 페이지 편집·게시 기능 제공 | 사용자 도메인·기능·공개 범위 |
예를 들어 GitHub Pages는 GitHub 저장소의 파일이나 빌드 결과를 기반으로 정적 웹사이트를 만들 수 있습니다. Cloudflare Pages는 준비된 파일을 Direct Upload로 올리거나, 프로젝트 생성 방식에 따라 Git 연동 자동 배포를 사용할 수 있습니다. 주의할 점은 Cloudflare Pages에서 Direct Upload 방식으로 프로젝트를 만들면 나중에 같은 프로젝트를 Git 통합 방식으로 그대로 전환할 수 없다는 공식 제한이 있다는 것입니다. 자동 배포가 필요하다면 프로젝트 생성 전 방식을 확인해야 합니다. 서비스의 요금제, 파일 제한, 배포 횟수 제한은 달라질 수 있으므로 “어떤 서비스든 무제한 무료”라고 생각하면 안 됩니다. 어느 회사를 선택할지보다 먼저 내 사이트가 단순 정적 파일인지, 서버 실행까지 필요한 앱인지 파악하세요.
9. 미리보기 배포와 실제 배포는 무엇이 다른가요?
배포를 공부할 때 자주 만나는 말은 Preview(미리보기)와 Production(실서비스)입니다. 미리보기 배포는 새로운 버전을 사용자에게 정식으로 반영하기 전에 확인하는 용도입니다. 실서비스 배포는 실제 이용자가 접속하는 기본 서비스 주소에 해당 버전을 반영하는 작업입니다. 예를 들어 온라인 쇼핑몰에서 버튼을 바꾸려 할 때 먼저 미리보기 주소에서 오타·클릭 오류를 확인한 뒤 실제 서비스 주소에 반영할 수 있습니다. 하지만 여기서 매우 중요한 보안 주의사항이 있습니다. 미리보기 배포는 무조건 비공개가 아닙니다. Cloudflare Pages 공식 문서에 따르면 미리보기 배포 URL은 기본적으로 공개 접근이 가능할 수 있습니다. 접근을 제한하려면 Cloudflare Access 같은 적절한 설정이 필요합니다. 따라서 출시되지 않은 서비스의 비밀번호, 회사 계약서, 고객 명단, 내부 문서를 “미리보기니까 괜찮겠지”라고 생각하고 업로드해서는 안 됩니다. 다음처럼 이해하면 됩니다. Preview = 정식 반영 전 점검용 환경. Private = 실제 접근 제어가 적용된 환경. 두 용어는 같은 뜻이 아닙니다.
10. GitHub 저장소가 비공개면 배포된 사이트도 비공개인가요?
그렇지 않을 수 있습니다. GitHub 공식 문서는 저장소가 비공개여도 GitHub Pages에 게시된 사이트 자체는 인터넷에서 공개될 수 있다고 명시합니다. 이 차이를 알아야 합니다. 소스코드 저장소 접근 권한: GitHub에서 누가 저장소 파일을 읽을 수 있는지. 웹사이트 공개 여부: 실제 배포된 웹페이지를 누가 열어 볼 수 있는지. 두 가지는 별도로 동작할 수 있습니다. 예를 들어 GitHub 저장소는 개인 계정만 열 수 있어도, 해당 저장소의 빌드 결과가 공개 GitHub Pages 주소로 게시됐다면 다른 사람이 웹사이트를 볼 수 있습니다. 또한 브라우저로 전달되는 JavaScript·HTML에는 방문자가 확인할 수 있는 정보가 포함됩니다. 따라서 “비공개 저장소 안에 있으니 웹에 배포해도 API 키는 비밀로 유지되겠지”라고 판단하면 위험합니다. 웹에서 실제로 제공되는 파일과 API 키·비밀정보는 반드시 별도로 검토해야 합니다.
11. 배포 전에 꼭 확인할 일곱 가지
AI가 만든 웹사이트를 실제로 공개하려면 기본적인 검수는 필요합니다. 1. 비밀정보 제거. API 키, 비밀번호, 인증 토큰, 사용자 개인정보가 HTML·JavaScript·이미지·환경설정에 포함되지 않았는지 확인하세요. 2. 사이트 기능. 버튼, 입력창, 링크, 이미지, 다운로드 기능이 예상대로 작동하는지 확인하세요. 3. 모바일 화면. 320px와 390px 같은 좁은 화면에서 가로로 튀어나오는 표·버튼·텍스트가 없는지 확인하세요. 4. 저작권과 라이선스. 사용하는 사진, 로고, 글꼴, 오디오, 오픈소스 코드에 사용 권리가 있는지 검토하세요. 5. 접속 권한. 사이트가 공개인지, 팀 구성원만 열 수 있는지, 미리보기도 외부에서 열리는지 확인하세요. 6. 되돌리기 방법. 이전 소스와 빌드 결과를 보관했고 문제가 생기면 이전 버전으로 복귀할 수 있는지 확인하세요. 7. 광고·운영 조건. 광고 수익형 블로그라면 광고 표시, 성능, 개인정보·쿠키 안내, 정책 준수 등을 함께 점검하세요. 점검표를 통과하지 못했다고 해서 반드시 배포 도구에 오류가 있는 것은 아닙니다. 배포 도구가 정상 동작하더라도 콘텐츠 품질·권리·보안은 별도의 문제입니다.
12. 배포했다면 실제 주소로 확인하세요
호스팅 서비스에 성공 메시지가 나타나면 인터넷 주소를 직접 열어 보는 작업이 남습니다. 확인할 때는 다음 순서가 도움이 됩니다. 첫째, 제공된 사이트 URL을 브라우저에서 엽니다. 둘째, 홈페이지뿐 아니라 개별 페이지와 버튼·링크를 확인합니다. 셋째, 모바일 화면에서 제목·이미지·표·입력창이 정상 표시되는지 확인합니다. 넷째, 주소가 HTTPS로 제공되는지, 브라우저가 보안 경고를 표시하는지 살펴봅니다. 다섯째, 이전 버전의 화면이 계속 보이면 캐시·빌드 결과·배포 대상 브랜치를 확인합니다. 여섯째, 실제 이용자가 사용하는 서비스라면 오류 로그·접속 현황·가용성 문제를 확인합니다. HTTPS는 통신을 보호하는 기술이지, 사이트가 안전하거나 내용이 사실이라는 보증은 아닙니다. 또한 화면이 열렸다고 바로 검색엔진에 노출되는 것도 아닙니다. 검색엔진이 해당 페이지를 색인했는지는 별도로 확인해야 합니다.
13. 배포 후 자주 발생하는 오류
사이트 주소를 열면 404 오류가 나타나요
요청한 페이지나 파일을 서버에서 찾지 못할 때 나타날 수 있습니다.
index.html 같은 시작 파일이 올바른 위치에 있는지, 빌드 결과 폴더를 잘못 선택하지 않았는지, 링크 경로·파일명 대소문자가 맞는지 확인하세요.
내 컴퓨터에서는 되는데 공개 사이트에서는 버튼이 안 돼요
브라우저의 개발자 도구 콘솔에서 JavaScript 오류를 확인해 보세요.
파일 경로가 파일 URL 형식 에서만 우연히 작동했거나, 배포 위치의 기본 경로가 달라졌을 수도 있습니다.
이미지를 올렸는데 깨져 보여요
이미지 경로·대소문자·빌드 결과물에 실제 이미지 파일이 포함됐는지 확인하세요. 또한 외부 이미지라면 사용 권리와 링크 제공 조건을 확인해야 합니다.
새 버전을 올렸는데 예전 화면이 보여요
실제로 배포가 완료됐는지, 운영 배포가 아닌 미리보기만 갱신된 것은 아닌지 확인하세요. 브라우저·CDN 캐시가 영향을 줄 수도 있습니다. 우선 배포 대상 버전과 서비스가 보여 주는 버전을 비교하는 것이 좋습니다.
사용자 도메인으로 접속할 수 없어요
호스팅의 기본 주소가 정상인지부터 확인하고, 이후 DNS와 사용자 도메인 설정·인증서 상태를 점검하세요. 배포된 파일이 잘못된 것과 도메인 연결이 잘못된 것은 서로 다른 문제일 수 있습니다.
14. 잘못 배포했다면 이전 버전으로 되돌릴 수 있나요?
가능한 서비스와 조건이 있습니다. 이 과정을 롤백(Rollback)이라고 부릅니다. 쉽게 말하면 문제가 생긴 새 버전 대신 이전에 정상 작동하던 버전으로 되돌리는 것입니다. 예를 들어 웹사이트 메뉴가 사라졌다면 이전에 정상 작동했던 파일이나 배포 버전을 다시 적용할 수 있습니다. 그러나 중요한 제한이 있습니다. 모든 호스팅에서 무조건 ‘원클릭 롤백’이 보장되는 것은 아닙니다. 이전 배포 기록, 소스 관리, 빌드 산출물 보관 방식과 사용 중인 서비스 기능에 따라 달라집니다. 또한 데이터베이스 구조나 저장된 사용자 데이터를 변경한 경우에는 웹 파일만 이전 버전으로 돌리는 것으로 완전히 복구되지 않을 수 있습니다. 배포 전에 기존 버전을 보관하고 되돌릴 방법을 미리 확인하는 것이 중요합니다. 이 점은 Git 커밋으로 코드의 변경을 기록하는 것과 실제 서비스의 파일·설정·데이터를 복원하는 일이 서로 다를 수 있다는 뜻이기도 합니다.
15. AI에게 배포 방법을 물을 때 좋은 질문 예시
AI 코딩 도구가 사이트를 만들어 줬다면 “배포해 줘”라고만 말하기보다 현재 앱의 구성·목적·공개 범위·비용을 알려 주세요. 예를 들어 다음처럼 요청할 수 있습니다.
나는 웹 개발을 처음 배우는 사람입니다.
현재 앱은 index.html, style.css, script.js로
만든 간단한 정적 웹페이지입니다.
서버, 로그인, 데이터베이스, 외부 유료 API는 없습니다.
실제 인터넷에 배포하기 전에 다음을 점검해 주세요.
1. 정적 호스팅으로 충분한지 판단
2. 공개되는 파일에 비밀키·개인정보가 없는지 확인
3. 배포와 빌드가 다른 이유를 설명
4. 미리보기 URL이 외부에 공개될 수 있는지 확인
5. 모바일 320px·390px 화면 검수 항목 제시
6. HTTPS·도메인 연결에 필요한 확인 항목 제시
7. 배포 후 실제 URL에서 검증할 항목 작성
8. 문제가 생겼을 때 되돌릴 방법 정리
아직 실제 계정에 로그인하거나
파일을 게시·배포·DNS 변경하지 마세요.
먼저 실행 계획과 위험을 설명해 주세요.
이렇게 질문하면 AI가 무조건 배포를 실행하는 것이 아니라, 사용자가 먼저 이해하고 판단할 수 있습니다. 배포는 외부 공개와 비용이 발생할 수 있는 작업이므로 승인 전 위험·공개 범위·비밀정보를 확인하는 흐름이 중요합니다.
자주 묻는 질문(FAQ)
Q1. 배포란 무엇인가요?
완성한 사이트나 프로그램의 파일·실행 환경을 실제 제공 서버에 적용해 다른 사용자나 서비스가 사용할 수 있도록 만드는 과정입니다.
Q2. 내 컴퓨터에서 실행되는 사이트도 배포한 건가요?
보통 개발 중 로컬 실행과 실제 인터넷 공개 배포는 구분합니다. 로컬 개발 서버만 실행했다고 자동으로 외부 공개된 것은 아닙니다.
Q3. 배포하려면 도메인을 꼭 구매해야 하나요?
반드시 그렇지는 않습니다. 일부 호스팅 서비스는 pages.dev나 github.io 같은 기본 주소를 제공할 수 있습니다. 사용자 도메인은 별도 선택 사항입니다.
Q4. 정적 웹사이트와 동적 앱의 배포는 같나요?
기본 개념은 비슷하지만 필요한 호스팅 기능이 다를 수 있습니다. 정적 사이트는 파일 제공 중심이고, 서버 기능·DB가 필요한 앱은 별도 백엔드 환경이 필요할 수 있습니다.
Q5. GitHub에 코드를 올리면 자동으로 웹사이트가 공개되나요?
반드시 그렇지는 않습니다. GitHub Pages 등의 게시 소스·설정·빌드·배포 과정이 있어야 공개 사이트가 만들어집니다. 또한 비공개 저장소와 공개된 사이트의 접근 권한은 별개일 수 있습니다.
Q6. 미리보기 배포는 비공개인가요?
그렇게 단정할 수 없습니다. Cloudflare Pages 등의 미리보기 URL은 기본적으로 공개 접근이 가능할 수 있습니다. 비공개 검수가 필요하면 실제 접근 제어를 설정해야 합니다.
Q7. 배포가 성공하면 Google 검색에 바로 표시되나요?
아닙니다. 배포와 검색엔진 색인은 서로 다른 과정입니다. 검색엔진이 URL을 발견·평가하고 색인하는 데 시간이 걸리거나 색인되지 않을 수도 있습니다.
Q8. 배포 후 404 오류가 나면 무엇부터 확인하나요?
파일이 실제로 올라갔는지, 시작 파일과 경로·대소문자가 맞는지, 올바른 배포 폴더와 브랜치를 선택했는지 확인하세요.
Q9. HTTPS가 붙어 있으면 안전한 사이트인가요?
HTTPS는 브라우저와 서버 사이 통신을 보호하는 기술입니다. 사이트 운영자의 신뢰성, 콘텐츠의 정확성, 개인정보 보호가 모두 보장되는 것은 아닙니다.
Q10. 배포 비용은 항상 무료인가요?
아닙니다. 무료 제공 범위가 있는 서비스도 있지만 방문량·빌드·저장소·백엔드·데이터 전송·도메인 등의 조건에 따라 비용이 발생할 수 있습니다. 실제 플랜과 한도를 확인해야 합니다.
마무리: 배포는 ‘완성’이 아니라 ‘실제 사용 환경에 올리는 과정’입니다
배포(Deployment)는 내 컴퓨터에서 만든 웹사이트나 프로그램을 실제 사용자가 접근할 수 있는 환경에 적용하는 과정입니다. 처음 배울 때는 다음 순서로 이해하면 충분합니다. ① 코드를 만든다 → ② 로컬에서 테스트한다 → ③ 배포할 환경을 선택한다 → ④ 비밀정보·기능·모바일을 점검한다 → ⑤ 배포한다 → ⑥ 실제 공개 주소에서 검수한다. 그리고 세 가지를 기억하세요. 내 컴퓨터에서 잘 작동한다고 인터넷에서 자동으로 보이는 것은 아닙니다. 미리보기 주소도 비공개라고 단정할 수 없습니다. 배포가 완료됐다고 검색엔진 색인·보안·모바일 품질까지 자동으로 보장되는 것은 아닙니다. AI가 사이트를 만들었더라도 마지막 배포 단계에서는 무엇이 어디에 공개되는지, 비용과 권한은 무엇인지, 문제가 생기면 어떻게 되돌릴지를 사람이 확인하는 습관이 중요합니다.
함께 읽으면 좋은 글
- CLI란? 명령어로 컴퓨터를 다루는 방법과 초보자 예시 — 관련 개념과 실전 점검 방법을 함께 확인합니다.
- AI로 홈페이지 만들고 무료 배포하기: GitHub Pages 초보자 가이드 — 관련 개념과 실전 점검 방법을 함께 확인합니다.