바이브코딩 9편: 만든 할 일 앱을 인터넷에 직접 올려보기

작은 프로젝트를 하나 끝까지 만들었다면, 그다음에는 꼭 한 번 해봐야 하는 일이 있습니다. 바로 내 컴퓨터 밖에서 열어보는 것입니다. 로컬 브라우저에서 잘 돌아가는 것과, 실제 주소를 통해 열리는 건 느낌이 꽤 다릅니다. 여기서부터는 "코드를 쳐봤다"를 넘어서, 하나의 결과물을 정리해서 보여줄 수 있는 상태로 넘어가기 시작합니다.

특히 초보자에게는 이 단계가 중요합니다. 왜 파일 이름을 정확히 맞춰야 하는지, 왜 구조를 단순하게 유지하는 게 좋은지, 왜 기능을 더 넣기 전에 현재 상태를 먼저 고정해야 하는지 같은 것들이 배포 단계에서 훨씬 또렷하게 보이기 때문입니다.

이번 글에서는 지난 편에서 만든 할 일 앱을 기준으로, 가장 가볍게 공개할 수 있는 흐름을 따라가보겠습니다. 목표는 복잡한 서비스 운영이 아니라, HTML, CSS, JavaScript로 만든 작은 프로젝트를 실제 웹 주소로 열 수 있게 만드는 것입니다.

이번 글에서 먼저 잡아둘 핵심

겉으로 보이는 목표	실제로 해야 하는 일	가장 먼저 봐야 할 것
할 일 앱을 인터넷에 올린다	저장소에 올리고 Pages를 켠다	프로젝트 구조와 첫 화면 파일이 맞는지 본다
주소를 만들었다고 끝난 것처럼 느껴진다	배포 후 직접 눌러보며 기능을 다시 점검해야 한다	추가, 체크, 삭제, 새로고침 유지까지 다시 확인한다
로컬 데이터가 왜 배포 주소에서는 안 보이는지 헷갈린다	localStorage가 주소 기준으로 나뉘는 걸 이해해야 한다	저장 데이터는 "앱 파일"이 아니라 "현재 주소 기준 저장소"라는 점을 본다

이번 글의 핵심 한 줄
첫 배포의 핵심은 세상에 크게 공개하는 데 있지 않습니다. 내 프로젝트를 한 번 더 정리해서 실제 결과물처럼 다뤄보는 데 더 가깝습니다.

---

왜 이제는 배포를 해봐야 하는가

초보자가 프로젝트를 만들 때 자주 생기는 오해가 하나 있습니다. 브라우저에서 열어봤고 기능도 돌아가니까, 이제 완성이라고 느끼는 겁니다. 물론 그 상태도 중요합니다. 하지만 실제로는 한 단계가 더 남아 있습니다. 내 환경이 아니라도 열리고, 같은 동작이 나오는지 확인하는 단계입니다.

배포를 한 번 해보면 프로젝트를 바라보는 기준이 달라집니다. 지금까지는 "내 PC에서 되느냐"가 기준이었다면, 이제부터는 "정리된 파일 구조로 외부에서도 열리느냐"가 기준이 됩니다. 이 차이가 생각보다 큽니다.

• 프로젝트를 실제 주소로 열어볼 수 있습니다.
• 파일 구조와 연결 경로가 제대로 정리되어 있는지 확인할 수 있습니다.
• 나중에 다시 꺼내 보거나 다른 사람에게 보여주기 쉬워집니다.
• "만들었다"에서 끝나지 않고 "공개 가능한 결과물"까지 가보는 경험이 생깁니다.

핵심 포인트
첫 배포의 의미는 "웹에 올렸다"보다 내 프로젝트를 한 번 더 정리하고 검증했다는 데 더 가깝습니다.

---

이번 편에서는 GitHub Pages로 간다

처음 배포 방법은 여러 가지가 있을 수 있지만, 지금까지의 연재 흐름을 생각하면 GitHub Pages가 가장 자연스럽습니다. 이미 Git 체크포인트를 익혔고, 지금 프로젝트도 정적인 파일 중심이기 때문입니다. 이런 상황에서는 굳이 서버를 따로 세우기보다, 저장소에 있는 파일을 바로 웹으로 공개하는 방식이 훨씬 가볍습니다.

이번 편의 목표도 단순합니다.

• 프로젝트 파일을 GitHub 저장소에 올립니다.
• Pages 설정을 켭니다.
• 생성된 주소를 열어봅니다.
• 배포된 상태에서 기능을 다시 점검합니다.

즉, 이번 글은 배포 이론을 길게 배우는 글이 아닙니다. 처음 만든 작은 프로젝트를 실제 웹 주소로 띄워보는 글이라고 생각하면 됩니다.

---

배포 전에 꼭 정리할 것

배포 버튼을 누르기 전에 먼저 확인해야 할 게 있습니다. 초보자는 여기서 기능을 하나 더 넣고 싶어지는 경우가 많은데, 그건 보통 좋은 흐름이 아닙니다. 배포 직전에는 새 기능 추가보다 현재 상태를 정리하는 것이 더 중요합니다.

1) 폴더 구조를 단순하게 둡니다

이번 프로젝트 정도면 아래 구조면 충분합니다.

mini-todo/
  index.html
  style.css
  script.js

이 구조가 좋은 이유는 단순해서입니다. 지금 단계에서는 복잡한 폴더 분리보다, 첫 화면 파일이 무엇인지 바로 보이고, 연결되는 파일도 한눈에 들어오는 상태가 훨씬 낫습니다.

2) 로컬에서 마지막으로 한 번 더 확인합니다

배포 전에 최소한 아래 항목은 다시 눌러보는 편이 좋습니다.

• 할 일 추가가 되는가
• 완료 체크가 되는가
• 삭제가 되는가
• 새로고침 후에도 목록이 유지되는가

여기서 문제가 있으면, 배포 뒤에는 더 헷갈리기 쉽습니다. 그래서 로컬 기준으로 안정 상태를 먼저 확인해두는 편이 좋습니다.

3) Git 체크포인트를 남겨둡니다

지금 상태가 배포 전 안정 버전이라면, 먼저 기록을 하나 남겨두는 편이 좋습니다.

git status
git add .
git commit -m "배포 전 기본 할 일 앱 안정 버전 저장"

이렇게 해두면 배포 과정에서 뭔가를 다시 손보게 되더라도, 돌아갈 기준점이 남습니다.

4) 첫 화면 파일과 연결 경로를 다시 봅니다

작아 보이지만 가장 자주 놓치는 부분입니다. 첫 화면 파일은 index.html이어야 하고, CSS와 JavaScript 연결도 실제 파일명과 정확히 맞아야 합니다.

<link rel="stylesheet" href="style.css">
<script defer src="script.js"></script>

핵심 포인트
배포 직전에는 기능 확장보다 현재 구조와 연결이 정확한지 확인하는 것이 훨씬 중요합니다.

---

실제로 10분 안에 배포해보기

이제부터는 실제로 손을 움직여보는 구간입니다. 아래 순서대로만 하면, GitHub Pages 첫 배포는 생각보다 길지 않습니다.

1) GitHub에서 새 저장소를 만듭니다

저장소 이름은 지금 프로젝트가 바로 떠오르는 정도면 충분합니다. 예를 들어 mini-todo처럼 간단한 이름이면 됩니다.

2) 로컬 프로젝트와 저장소를 연결합니다

git branch -M main
git remote add origin https://github.com/사용자이름/mini-todo.git
git push -u origin main

이미 원격 저장소가 연결되어 있으면 중간 줄은 생략해도 됩니다. 헷갈리면 먼저 아래 명령으로 현재 상태를 봅니다.

git remote -v

3) GitHub 저장소에서 Settings로 들어갑니다

저장소 화면 상단에서 Settings를 누른 뒤, 왼쪽 메뉴에서 Pages로 이동합니다.

4) Pages를 켭니다

Source를 Deploy from a branch로 두고, 브랜치는 main, 폴더는 /(root)를 고릅니다. 지금 프로젝트처럼 파일이 저장소 최상단에 있다면 이 구성이 가장 단순합니다.

5) 잠깐 기다린 뒤 공개 주소를 엽니다

설정을 저장한 직후 바로 안 뜰 수도 있습니다. 이때는 설정을 여러 번 다시 바꾸기보다, 조금 기다렸다가 공개 주소를 다시 보는 편이 좋습니다.

실습 체크리스트

단계	끝났는지 확인할 것
저장소 생성	GitHub에 빈 저장소가 하나 생겼는가
push 완료	index.html, style.css, script.js가 저장소에 보이는가
Pages 설정	main / root 기준으로 설정됐는가
주소 확인	공개 주소에서 첫 화면이 실제로 열리는가

핵심 포인트
첫 배포에서는 멋진 설정을 많이 넣는 것보다, push -> Pages 설정 -> 주소 확인 이 세 단계만 정확히 끝내는 편이 훨씬 좋습니다.

---

GitHub Pages 켜서 공개 주소 만들기

프로젝트가 저장소에 올라갔다면, 이제 그 저장소를 실제 웹사이트로 공개하는 단계가 남습니다. 초보자가 여기서 가장 많이 헷갈리는 건 브랜치와 폴더입니다. 그런데 지금 프로젝트처럼 구조가 단순하면 오히려 판단도 단순합니다.

지금 구조는 아래와 같습니다.

mini-todo/
  index.html
  style.css
  script.js

즉, 첫 화면 파일이 저장소 최상단에 있는 구조입니다. 이 경우에는 보통 main 브랜치의 /(root)를 고르면 됩니다. 괜히 docs 폴더를 만들거나 경로를 한 번 더 꼬는 것보다, 지금 정리된 상태 그대로 배포하는 쪽이 훨씬 안전합니다.

이 단계에서 자주 헷갈리는 지점

헷갈리는 지점	실제로 확인할 것
브랜치는 맞는 것 같은데 페이지가 안 뜬다	선택한 브랜치의 최상단에 index.html이 실제로 있는지 본다
root와 docs 중 뭘 골라야 할지 모르겠다	프로젝트 파일이 실제로 있는 위치를 기준으로 고른다
바로 안 뜬다	설정을 다시 건드리기보다 잠시 기다렸다가 공개 주소를 다시 본다

핵심 포인트
처음 배포에서는 이것저것 많이 건드리는 것보다 브랜치와 폴더를 정확히 고르는 것이 거의 전부라고 봐도 됩니다.

---

배포 뒤에 꼭 확인할 것

공개 주소가 생겼다고 바로 끝난 건 아닙니다. 이제부터가 실제 확인 단계입니다. 로컬에서는 잘 되던 것도, 공개 주소에서는 다르게 보일 수 있기 때문입니다.

배포 직후에는 아래 항목을 직접 눌러보는 편이 좋습니다.

• 첫 화면이 정상적으로 열리는가
• 할 일 추가가 되는가
• 완료 체크가 되는가
• 삭제가 되는가
• 새로고침 뒤에도 상태가 유지되는가
• 모바일 폭에서도 입력창과 버튼이 너무 답답하지 않은가

이 단계에서 중요한 건 "사이트가 열렸는가"만 보는 게 아니라, JavaScript 동작과 저장 기능까지 실제로 눌러보는 것입니다. 화면은 떠도 연결이 어긋나 있으면 기능은 안 될 수 있기 때문입니다.

핵심 포인트
배포 직후 확인은 "주소가 나왔는가"보다 내가 만든 기능이 실제 배포 주소에서도 그대로 도는가를 보는 쪽이 훨씬 중요합니다.

---

로컬에서는 있던 데이터가 왜 배포 주소에서는 안 보일까

여기서 초보자가 한 번쯤 당황하는 지점이 있습니다. 로컬에서 브라우저에 저장해두었던 할 일 목록이, 배포 주소를 열었더니 비어 보이는 경우입니다. 이건 고장이 아니라, 저장이 나뉘어 있기 때문입니다.

이번 할 일 앱은 브라우저 저장 공간을 씁니다. 그런데 이 저장은 "내 컴퓨터 전체에서 공통으로 하나"가 아니라, 어느 주소에서 열었는가를 기준으로 나뉩니다. 그래서 로컬 파일이나 로컬 주소에서 저장된 내용과, GitHub Pages로 열리는 실제 사이트 주소의 저장 내용은 서로 따로 보일 수 있습니다.

왜 저장 데이터가 달라 보일까

어디서 열었나	보이는 저장 데이터
로컬 파일 또는 로컬 주소	로컬 기준으로 저장된 데이터
GitHub Pages 주소	배포 주소 기준으로 따로 저장된 데이터

즉, 아래처럼 이해하면 됩니다.

• 로컬에서 테스트하며 쌓은 목록은 로컬 기준 저장입니다.
• 배포 주소에서 새로 만든 목록은 배포 주소 기준 저장입니다.
• 둘은 같은 앱처럼 보여도 저장 위치가 자동으로 합쳐지지 않습니다.

이 부분을 미리 알고 있으면 덜 당황합니다. 오히려 "배포가 잘못된 건가?"라고 오해하지 않게 되기 때문입니다.

핵심 포인트
배포 뒤에 목록이 비어 보여도 바로 오류라고 단정할 필요는 없습니다. localStorage는 주소 기준으로 따로 저장될 수 있다는 점을 먼저 떠올리는 편이 좋습니다.

---

자주 막히는 포인트 4가지

배포 단계에서 초보자가 자주 막히는 건 대체로 비슷합니다. 아래 네 가지는 특히 자주 반복됩니다.

겉으로 보이는 문제	실제로 먼저 볼 것
주소는 나왔는데 첫 화면이 안 열린다	선택한 배포 위치의 최상단에 index.html이 있는지 본다
로컬에서는 보이던 스타일이 배포 주소에서는 안 먹는다	style.css 파일명과 link 경로가 정확히 맞는지 본다
JavaScript가 안 되는 것 같다	script.js 연결 줄과 실제 파일명이 맞는지 먼저 본다
배포 주소에서는 목록이 비어 있다	localStorage가 로컬 주소와 배포 주소에서 따로 보일 수 있다는 점을 먼저 확인한다

이런 문제는 대부분 프로젝트가 망가져서라기보다, 배포 위치와 파일 연결, 저장 위치 기준을 아직 섞어 보고 있기 때문인 경우가 많습니다. 그래서 막힐 때는 "코드 전체가 틀렸다"보다 "배포 기준으로 어느 연결이 어긋났지?"부터 보는 편이 훨씬 빠릅니다.

---

마무리

이번 편에서 중요한 건 "GitHub Pages를 썼다"는 사실 자체가 아닙니다. 더 중요한 건, 작은 프로젝트를 만들고, 점검하고, 기록을 남기고, 실제 주소로 열어봤다는 흐름을 한 번 완주했다는 점입니다. 초보자에게는 이 경험이 생각보다 큽니다.

이제부터는 결과물을 보는 기준도 조금 달라집니다. 코드가 돌아가기만 하면 끝이 아니라, 구조를 정리하고, 배포 전에 현재 상태를 고정하고, 공개된 상태에서도 다시 테스트하는 흐름이 생기기 때문입니다. 그 흐름이 잡히면 다음 프로젝트도 훨씬 덜 막막해집니다.

특히 이번 배포를 거치고 나면 localStorage가 왜 편했는지, 또 왜 한계가 있는지도 같이 보이기 시작합니다. 로컬에서는 잘 돌아가던 앱이 실제 주소를 가지는 순간, 저장 기준과 연결 경로, 구조 정리까지 같이 의식하게 되기 때문입니다. 바로 그 지점부터 앱을 보는 시야가 조금 달라집니다.