업무 도구 배포하기: GitHub Pages로 공유 주소 만들기

오늘 목표

이번 주에는 웹툴 기능을 추가하거나 코드를 수정하지 않습니다.
완성된 HTML 파일 하나를 GitHub에 올리고, GitHub Pages로 배포하는 과정만 진행합니다.

• GitHub 계정을 만들고 이메일 인증하기
• 배포할 HTML 복사본의 이름을 index.html로 바꾸기
• GitHub에 공개 저장소 만들기
• 웹화면에서 index.html 올리기
• GitHub Pages 배포 설정하기
• 생성된 웹주소에서 웹툴 열기
• 인증키가 저장되어 있지 않은지 확인한 뒤 실제 조회하기

오늘의 완료 기준

내가 만든 웹툴이 github.io 주소에서 열리면 완료입니다.
참고링크 : https://kyong-ho.github.io/g2b-viewer/

오늘 순서

배포할 HTML 확인
→ GitHub 가입
→ 저장소 만들기
→ index.html 올리기
→ GitHub Pages 켜기
→ 배포 주소에서 실행 확인

HTML 파일 하나를 웹주소로 여는 과정에만 집중합니다.

시작 전에 알아둘 세 가지 표현

Git의 원리나 명령어를 별도로 배우지 않습니다.
화면에서 위 표현을 만났을 때 무엇을 선택해야 하는지만 알면 됩니다.

가장 중요한 주의사항

이번 실습에서 만드는 저장소와 GitHub Pages 웹사이트는 인터넷에 공개됩니다. 실제 인증키·개인정보·회사 내부자료가 들어 있는 파일은 올리지 않습니다.

공공데이터포털 Decoding 인증키는 HTML에 미리 넣지 않습니다.
배포한 웹툴을 사용할 때 화면의 인증키 입력칸에 직접 입력합니다.

다음을 업로드하지 않습니다.

• 실제 Decoding 인증키가 들어 있는 HTML
• .env, config.js, 메모장 등에 저장한 인증키
• 회사 내부자료나 공개하면 안 되는 업무 데이터
• 개인정보가 들어 있는 테스트 파일

회사에서 GitHub 사용은 허용하지만 외부 공개 저장소나 GitHub Pages 사용이 허용되지 않았다면, 저장소를 만들기 전에 사내 담당자에게 확인합니다.

준비 - 배포할 HTML 만들기

1. 완성본을 복사합니다

9주차에서 완성한 다음 파일을 사용합니다.

나라장터통합조회기_v1.0.html

9주차 파일이 없다면 6주차나 8주차에 완성한 HTML 업무도구를 사용해도 됩니다.
이번 주의 목표는 기능 개발이 아니라 배포이므로, 브라우저에서 정상적으로 열리는 HTML 파일 하나면 됩니다.

원본을 그대로 바꾸지 말고 복사본을 만듭니다.

10주차_배포/
  나라장터통합조회기_v1.0.html  ← 원본 보관
  index.html               ← GitHub에 올릴 복사본

2. 복사본 이름을 바꿉니다

복사한 파일 이름을 정확히 다음과 같이 바꿉니다.

index.html

• 모두 영문 소문자입니다.
• 띄어쓰기가 없습니다.
• index.html.html이 되지 않았는지 확인합니다.
• index (1).html처럼 다른 글자가 붙어 있으면 안 됩니다.

GitHub Pages는 저장소 첫 화면의 index.html을 웹사이트의 시작 파일로 사용합니다.

3. 업로드 전에 마지막으로 확인합니다

1. index.html을 더블클릭해 브라우저에서 엽니다.
2. 웹툴 화면이 정상적으로 나타나는지 확인합니다.
3. 인증키 입력칸이 비어 있는지 확인합니다.
4. 새로고침한 뒤에도 인증키가 남아 있지 않은지 확인합니다.

실습 1 - GitHub 가입하기

1. 가입 페이지 열기

1. GitHub 가입 페이지를 엽니다.
2. 화면 안내에 따라 이메일, 비밀번호, 사용자 이름을 입력합니다.
3. 무료 계정으로 가입합니다.

사용자 이름은 나중에 배포 주소의 일부가 됩니다.

2. 이메일 인증하기

1. GitHub에서 보낸 이메일을 엽니다.
2. 이메일 인증 버튼이나 인증번호를 이용해 인증을 완료합니다.
3. GitHub에 로그인합니다.

이메일 인증을 마치지 않으면 저장소 만들기 등 일부 기능을 사용할 수 없습니다.

가입 중 2단계 인증 설정이 표시되면 화면의 안내에 따라 진행합니다.
복구코드가 제공되면 회사 보안정책에 맞는 안전한 위치에 보관합니다.

실습 1 완료 확인

• GitHub에 로그인했다.
• 이메일 인증을 완료했다.
• 오른쪽 위에 자신의 프로필 아이콘이 보인다.

실습 2 - 저장소(Repository) 만들기

저장소는 index.html을 올려둘 온라인 폴더입니다.

1. 새 저장소 화면 열기

다음 중 편한 방법을 사용합니다.

• 새 저장소 만들기를 바로 열기
• GitHub 오른쪽 위 + → New repository 선택

2. 저장소 설정하기

다음과 같이 설정합니다.

Repository name은 웹주소에 들어갑니다.
한글 대신 짧은 영문 소문자와 하이픈을 사용하는 것이 좋습니다.

설정을 확인한 뒤 Create repository를 누릅니다.

실습 2 완료 확인

• 저장소 이름이 g2b-viewer이다.
• Public으로 만들었다.
• 저장소 첫 화면이 열렸다.
• 파일 목록에 README.md가 보인다.

실습 3 - index.html 올리기

1. 파일 업로드 화면 열기

1. g2b-viewer 저장소의 첫 화면으로 이동합니다.
2. 파일 목록 위의 Add file을 누릅니다.
3. Upload files를 선택합니다.

2. 파일 선택하기

다음 중 편한 방법을 사용합니다.

• choose your files를 눌러 index.html 선택
• index.html을 점선 영역으로 끌어다 놓기

화면에 파일명이 정확히 index.html로 나타나는지 확인합니다.
(commit 내용은 입력하지 않아도 무방합니다)

3. GitHub에 저장하기

1. 선택지가 나타나면 Commit directly to the main branch를 선택합니다.
2. Commit changes를 누릅니다.

이번 실습에서 Commit changes는 업로드한 파일을 GitHub에 저장한다는 뜻으로만 이해하면 됩니다.

저장소 첫 화면으로 돌아왔을 때 index.html 이 보이면 완료입니다.

실습 3 완료 확인

• 파일명이 정확히 index.html이다.
• Commit changes까지 눌렀다.
• 저장소 첫 화면에 index.html이 보인다.

실습 4 - GitHub Pages 켜기

파일을 GitHub에 올린 것만으로는 아직 웹사이트 주소가 만들어지지 않습니다.
이제 GitHub Pages를 켭니다.

1. Pages 설정 열기

1. 저장소 위쪽의 Settings를 누릅니다.
2. 왼쪽 메뉴에서 Pages를 선택합니다.

화면 폭이 좁아 Settings가 보이지 않으면 저장소 위쪽의 … 메뉴를 확인합니다.

2. 배포 위치 선택하기

Build and deployment에서 다음과 같이 선택합니다.

마지막으로 Save를 누릅니다.

Settings
→ Pages
→ Source: Deploy from a branch
→ Branch: main
→ Folder: /(root)
→ Save

이번 실습에서는 GitHub Actions를 선택하지 않습니다.

실습 4 완료 확인

• Source가 Deploy from a branch이다.
• Branch가 main이다.
• 폴더가 /(root)이다.
• Save를 눌렀다.

실습 5 - 배포 주소에서 웹툴 열기

GitHub가 웹사이트를 만드는 데 시간이 필요합니다.
바로 열리지 않더라도 설정을 반복해서 바꾸지 말고 최대 10분 정도 기다립니다.

1. 배포 주소 열기

1. 잠시 기다린 뒤 Settings → Pages를 다시 엽니다.
2. Your site is live at 안내가 나타나는지 확인합니다.
3. Visit site를 누릅니다.

주소는 대체로 다음 형식입니다.

https://사용자이름.github.io/g2b-viewer/

2. 실제로 작동하는지 확인하기

1. 웹툴 화면이 정상적으로 나타나는지 확인합니다.
2. 인증키 입력칸이 비어 있는지 확인합니다.
3. 자신의 Decoding 인증키를 화면에 직접 입력합니다.
4. 공고 조회를 한 번 실행합니다.
5. 배포 주소를 즐겨찾기하거나 별도로 기록합니다.

가능하면 시크릿 창이나 다른 브라우저에서도 주소를 한 번 열어봅니다.
로그인하지 않은 브라우저에서 열리면 웹주소 배포가 완료된 것입니다.

실습 5 완료 확인

• github.io 주소에서 웹툴이 열린다.
• 인증키가 미리 입력되어 있지 않다.
• 화면에서 인증키를 입력한 뒤 실제 조회가 된다.
• 배포 주소를 기록했다.

잘되지 않을 때 확인할 것

1. main을 선택할 수 없습니다

먼저 저장소 첫 화면으로 돌아갑니다.

• index.html이 보이는지 확인합니다.
• 파일을 선택만 하고 Commit changes를 누르지 않은 것은 아닌지 확인합니다.
• 저장이 완료된 뒤 Settings → Pages를 다시 엽니다.

2. 주소를 열면 404가 나타납니다

다음 순서로 확인합니다.

1. 배포 설정 후 최대 10분 기다렸는가
2. 파일명이 정확히 소문자 index.html인가
3. index.html이 별도 폴더가 아니라 저장소 첫 화면에 있는가
4. Pages 설정이 main과 /(root)인가

index.html.html, Index.html, index (1).html은 index.html과 다른 이름입니다.

3. 화면은 열리지만 API 조회가 되지 않습니다

배포 성공과 API 조회 성공은 별개의 확인입니다.

• Decoding 인증키를 화면에 다시 입력했는지 확인합니다.
• 필요한 공공 API의 활용신청이 승인 상태인지 확인합니다.
• API 주소가 http://가 아니라 https://로 시작하는지 확인합니다.

4. 실제 인증키가 들어 있는 파일을 올렸습니다

파일만 지워도 GitHub의 변경기록에는 내용이 남을 수 있습니다.

1. 해당 웹사이트의 사용을 즉시 중단합니다.
2. 공공데이터포털에서 인증키를 재발급하고 기존 키 사용을 중단합니다.
3. 회사의 보안 담당자 또는 GitHub 담당자에게 알립니다.

GitHub에 올린 실제 인증키를 계속 사용하지 않습니다.

공개를 중단해야 할 때

저장소 전체를 삭제하지 않고 웹사이트 공개만 중단할 수 있습니다.

Settings
→ Pages
→ Your site is live at 오른쪽의 …
→ Unpublish site

Unpublish site는 웹사이트만 내리고 저장소의 파일은 남겨 둡니다.

오늘 완료 확인

• 배포할 원본 HTML을 별도로 보관했다.
• 업로드용 복사본 이름을 index.html로 바꿨다.
• 실제 인증키·개인정보·회사 내부자료가 없는지 확인했다.
• GitHub 계정을 만들고 이메일 인증을 완료했다.
• g2b-viewer 공개 저장소를 만들었다.
• 웹화면에서 index.html을 올리고 Commit changes를 눌렀다.
• Pages를 Deploy from a branch, main, /(root)로 설정했다.
• Visit site에서 배포된 웹툴을 열었다.
• 배포 화면의 인증키 입력칸이 비어 있다.
• 자신의 인증키를 화면에서 직접 입력해 조회했다.
• 배포 주소를 기록했다.

심화과정 - Vercel로 배포하고 API 키 입력 없애기

API 키를 Vercel에 한 번 등록하고, 웹툴을 열 때마다 인증키를 입력하지 않아도 조회할 수 있게 만듭니다.

기본과정을 마친 뒤 선택해서 진행합니다. 같은 저장소의 main은 GitHub Pages용으로 유지하고, vercel 브랜치에서 심화과정을 진행합니다. AI의 도움으로 HTML의 API 호출 부분을 수정하고, 서버에서 실행되는 파일을 추가합니다.

심화 목표

• GitHub Pages용 main을 유지하고 vercel 브랜치 만들기
• vercel 브랜치의 웹툴을 Vercel용으로 수정하기
• Vercel의 운영 배포 브랜치를 vercel로 지정하기
• API 키를 Vercel 환경 변수에 등록하기
• 인증키 입력 없이 공고·개찰결과 조회하기
• Vercel 웹툴의 브라우저로 API 키가 전달되지 않는지 확인하기
• GitHub Pages와 Vercel 두 주소에서 각각 조회하기

심화 완료기준

API키가 없이 동작하는 웹툴이 vercel.app 주소에서 열리면 완료입니다.
참고링크 : https://g2b-viewer.vercel.app/

1. 기본과정과 무엇이 달라지나요?

• 환경 변수(env)는 코드에 직접 쓰지 않고 실행 환경에 따로 등록하는 설정값입니다. 이 실습에서는 API 키를 보관하는 데 사용합니다.

서버 함수는 사용자가 조회 버튼을 누르면 Vercel에서 실행되는 코드입니다. API 키를 읽고 공공 API에 요청한 뒤 조회 결과를 돌려줍니다. Vercel Functions 공식 안내

사용자: 조회 버튼 클릭
→ index.html: 검색 조건을 /api/g2b로 전달
→ Vercel 서버 함수: 환경 변수에서 API 키 읽기
→ 공공데이터 API: 조회 요청 처리
→ 서버 함수: 조회 결과 반환
→ index.html: 표로 표시

HTML에 .env를 연결하거나 Vercel에 키만 등록하면 끝나는 것은 아닙니다. 브라우저에서 공공 API로 직접 요청하던 코드를 서버 함수로 옮겨야 합니다. GitHub Pages는 이 서버 함수를 실행할 수 없습니다.

브라우저에 공개되는 변수에 비밀 키를 넣지 않습니다. 이 실습의 변수 이름은 DATA_GO_KR_API_KEY로 통일합니다.

2. 같은 저장소에 vercel 브랜치 만들기

• 브랜치(Branch)는 같은 저장소 안에서 파일의 변경을 따로 관리하는 작업 갈래입니다. main에서 새 브랜치를 만들면 처음에는 파일 내용이 같지만, 이후 vercel에 저장한 수정은 main에 자동으로 반영되지 않습니다.

이번에는 저장소를 새로 만들지 않고, 기본과정의 g2b-viewer를 계속 사용합니다.

g2b-viewer 저장소
├─ main 브랜치   → GitHub Pages → 인증키를 직접 입력하는 기본 완성본
└─ vercel 브랜치 → Vercel       → 환경 변수로 인증키를 사용하는 심화 완성본

GitHub 웹화면에서 만들기

1. GitHub에서 g2b-viewer 저장소를 엽니다.
2. 파일 목록 위의 브랜치 선택 메뉴가 main인지 확인합니다.
3. main 메뉴를 누르고 검색칸에 vercel을 입력합니다.
4. Create branch: vercel from main 또는 같은 뜻의 브랜치 생성 버튼을 누릅니다.
5. 생성 후 브랜치 선택 메뉴가 vercel인지 확인합니다.
6. index.html 등 기본과정 파일이 그대로 보이는지 확인합니다.

브랜치 선택 메뉴에서 main과 vercel을 번갈아 선택하면 각각의 파일을 볼 수 있습니다. 앞으로 업로드하거나 수정하기 전에 현재 브랜치가 vercel인지 확인합니다. GitHub 웹화면에서 브랜치 만들기

GitHub Pages 설정 확인하기

저장소의 Settings → Pages는 다음 값으로 유지합니다.

Pages의 배포 브랜치는 파일 목록에서 선택한 브랜치와 별개입니다. vercel의 파일을 보고 있어도 Pages 설정이 main이면 기본과정 파일이 배포됩니다. Pages 배포 위치 설정

컴퓨터에서도 기본과정의 index.html을 10주차_Vercel_심화 폴더에 복사해 AI 수정용으로 사용합니다.

3. AI에게 Vercel용으로 수정 요청하기

AI 대화창에 실제 인증키가 없는 index.html을 첨부하고 다음 내용을 입력합니다.

첨부한 나라장터 통합조회 HTML을 Vercel 배포용으로 수정해줘.
목표는 웹툴을 사용할 때 API 키를 매번 입력하지 않고 조회하는 것이야.

같은 g2b-viewer 저장소의 main은 기존 GitHub Pages용으로 유지할 거야.
수정한 파일은 vercel 브랜치에만 올릴 거야. main이나 Pages 설정은 바꾸지 마.
두 브랜치의 파일을 합치는 Pull Request나 병합도 이번에는 하지 않을 거야.

기존 화면, 검색 조건, 공고·개찰결과 조회, 페이지 이동, 다운로드 기능은 유지해줘.
React로 바꾸지 말고, 기존 HTML과 Vercel Node.js 서버 함수로 구성해줘.

요구사항:
1. 먼저 첨부 HTML의 모든 API 호출 위치와 실제 사용 중인 API 주소·응답 형식을 확인해줘.
   파일에 없는 API 주소를 추측하지 말고, 정보가 부족하면 필요한 내용을 알려줘.
2. index.html은 같은 사이트의 /api/g2b로 검색 조건만 전달하게 바꿔줘.
3. api/g2b.js를 만들고, 서버에서만 process.env.DATA_GO_KR_API_KEY를 읽어줘.
4. 실제 인증키는 제공하지 않을 거야. 코드와 예시에는 실제 키를 넣지 마.
5. 브라우저의 인증키 입력칸과 필수 입력 검사, 키 저장·복원 코드를 제거해줘.
   localStorage나 쿠키에 API 키를 저장하지 마.
6. 브라우저가 공공 API를 직접 호출하거나, API 키를 요청·응답·HTML·로그로
   받는 경로가 남지 않게 해줘. 실패한 upstream URL도 그대로 노출하지 마.
7. 서버에서 허용한 공공 API 주소와 조회 기능만 호출하게 해줘.
   사용자가 전달한 임의 URL로 요청을 보내는 범용 프록시는 만들지 마.
   검색 조건, 날짜 범위, 페이지 번호, 페이지당 조회 건수를 검증하고 상한을 둬.
8. Decoding 인증키를 서버에서 요청 URL에 넣을 때 필요한 인코딩을 한 번만 적용해줘.
   기존 API의 JSON/XML 응답 형식을 확인하고 화면이 기대하는 형식으로 처리해줘.
9. 키 미설정, 잘못된 검색 조건, API 오류, 시간 초과를 구분해
   키가 포함되지 않은 사용자 안내를 반환해줘.
10. 순수 HTML + api 폴더를 Vercel에서 실행하는 최소 구성을 만들어줘.
    package.json이 필요하면 포함하고, 모듈 형식을 서버 함수 코드와 맞춰줘.
    .gitignore에는 .env, .env.*, .vercel/, node_modules/를 제외하도록 넣어줘.
11. 수정한 파일은 생략 없는 전체 내용으로 제공하고,
    파일별 저장 위치, Vercel 배포 설정, 확인 순서를 초보자용으로 알려줘.

실제 API 키는 내가 Vercel 환경 변수 설정 화면에서 직접 등록할 거야.

결과물의 기본 구조는 다음과 같습니다. AI가 추가 설정 파일을 제공했다면 함께 확인합니다.

g2b-viewer/         ← vercel 브랜치에서 보이는 파일 구조
  index.html       ← 사용자 화면
  api/
    g2b.js         ← API 키를 읽고 대신 조회하는 서버 함수
  package.json     ← 필요한 실행 설정
  .gitignore       ← 환경 변수 파일 등의 Git 저장 방지

.gitignore는 실수 방지를 돕는 파일입니다. GitHub 웹 업로드에서 비밀 파일이 자동 차단된다고 생각하면 안 됩니다. 업로드할 파일은 직접 확인하고, .env 파일과 실제 키가 들어 있는 파일은 선택하지 않습니다.

4. 수정 파일을 vercel 브랜치에 올리기

1. g2b-viewer 저장소에서 브랜치를 vercel로 선택한 뒤 Add file → Upload files를 엽니다.
2. 수정한 index.html과 나머지 파일을 올립니다.
3. api 폴더를 끌어다 놓아 api/g2b.js 경로가 유지되게 합니다.
4. 저장 대상이 vercel인지 확인합니다. 선택지가 보이면 Commit directly to the vercel branch를 선택하고 Commit changes를 누릅니다.
5. vercel 브랜치에 수정된 index.html이 있고, api 폴더 안에 g2b.js가 있는지 확인합니다.
6. main으로 잠시 전환해 기본과정 파일이 그대로인지 확인한 뒤 다시 vercel로 돌아옵니다.

폴더 업로드가 어렵다면 vercel 브랜치에서 Add file → Create new file을 열고, 파일 이름에 api/g2b.js를 입력해 AI가 준 서버 코드를 저장할 수 있습니다.

Compare & pull request 안내가 나와도 이번 실습에서는 누르지 않습니다. 기본과정과 심화과정을 따로 유지하므로 브랜치를 합치지 않습니다.

5. Vercel에 연결하고 vercel 브랜치 배포하기

① 기존 저장소 연결하기

1. Vercel에 접속해 GitHub 계정으로 가입하거나 로그인합니다.
2. 대시보드에서 Add New → Project를 선택합니다.
3. GitHub 연결 권한을 설정하고 기존 g2b-viewer 저장소를 선택해 Import합니다.
4. 순수 HTML 프로젝트라면 Framework Preset은 Other, Root Directory는 저장소 루트로 둡니다. Build Command와 Output Directory는 AI가 제공한 최소 구성 안내에 맞춥니다. React용 npm run build나 dist를 임의로 입력하지 않습니다.
5. Deploy를 눌러 프로젝트를 만듭니다.

처음에는 기본 브랜치인 main이 배포될 수 있습니다. 이때 Vercel 주소에 기존 인증키 입력창이 나오는 것은 중간 상태입니다. 다음 단계에서 운영 배포 브랜치를 바꿉니다.

② 운영 배포 브랜치를 vercel로 지정하기

Vercel 프로젝트에서 다음 메뉴를 엽니다.

Settings
→ Environments
→ Production
→ Branch Tracking 에서 vercel 직접 입력
→ Save

Production은 사용자에게 제공하는 정식 배포 환경입니다. Branch Tracking은 어느 브랜치의 변경을 정식 사이트에 반영할지 정하는 설정입니다.

설정을 저장하면 이후 vercel 브랜치에 저장한 변경으로 새 Production 배포가 만들어집니다. 기존 사이트가 즉시 새 코드로 바뀌는 것은 아니므로 아래 ④ 단계까지 진행합니다. Vercel 운영 배포 브랜치 변경

③ API 키를 환경 변수에 등록하기

프로젝트 → Settings → Environment Variables에서 다음 값을 등록합니다.

값에는 키만 넣습니다. DATA_GO_KR_API_KEY= 전체 문장이나 따옴표를 함께 넣지 않습니다. 민감한 값으로 저장하는 옵션이 제공되면 사용합니다. 환경 변수 설정 안내

환경 변수를 저장한 뒤 새 배포가 필요합니다. 등록하거나 변경한 값은 새 배포부터 적용됩니다. Vercel 환경 변수 안내

④ vercel의 새 변경을 저장해 배포하기

이전 main 배포에서 Redeploy만 누르면 이전 코드를 다시 배포할 수 있습니다. 이번에는 다음 방법으로 vercel 브랜치의 새 배포를 만듭니다.

1. GitHub의 g2b-viewer 저장소로 돌아갑니다.
2. 브랜치 선택 메뉴에서 vercel을 선택합니다.
3. README.md를 열고 편집 버튼을 눌러 다음 설명을 추가합니다. 파일이 없다면 Add file → Create new file에서 README.md를 만듭니다.

이 브랜치는 Vercel 심화과정용입니다.
API 키는 Vercel의 DATA_GO_KR_API_KEY 환경 변수로 설정합니다.

1. 저장 대상이 vercel인지 확인하고 Commit changes를 누릅니다.
2. Vercel의 Deployments에서 새 배포가 시작되는지 확인합니다.
3. 새 배포의 브랜치가 vercel, 환경이 Production, 상태가 Ready인지 확인합니다.
4. 프로젝트에 연결된 정식 vercel.app 주소를 엽니다. 이전 배포의 개별 주소와 혼동하지 않습니다.

⑤ 브랜치가 목록에 보이지 않거나 새 배포가 없을 때

GitHub에 브랜치가 있어도 Vercel의 배포 목록에는 해당 브랜치의 배포가 아직 없을 수 있습니다. 브랜치 설정과 현재 배포의 Source는 따로 확인합니다. Source가 main이고 Redeploy of …로 표시된다면 기존 main 배포를 다시 실행한 것일 수 있습니다.

이때는 새 커밋 없이 브랜치를 직접 지정해 배포할 수 있습니다.

1. GitHub에서 자신의 저장소 → vercel 브랜치를 선택하고 주소창의 URL을 복사합니다. 형식은 https://github.com/계정명/g2b-viewer/tree/vercel입니다.
2. Vercel 프로젝트의 Deployments로 이동합니다.
3. 제목 옆 … 메뉴(Deployments actions)에서 Create Deployment를 선택합니다. 화면에 버튼이 바로 보이면 해당 버튼을 누릅니다.
4. Branch, Commit, or URL 입력칸에 복사한 브랜치 URL을 붙여 넣습니다. 아래에 vercel 버튼이 보이면 눌러도 됩니다.
5. 검증이 끝나면 브랜치 vercel, 환경 Production, 원하는 최신 커밋이 표시되는지 확인합니다.
6. Deploy to Production을 누릅니다. Preview로 표시된다면 먼저 Production의 Branch Tracking 설정을 확인합니다.
7. 배포 상태가 Ready가 되면 정식 주소를 엽니다.

이는 기존 배포를 반복하는 Redeploy와 달리, 지정한 브랜치로 새 배포를 만드는 방법입니다. 같은 커밋이 여러 브랜치에 있어 선택창이 나오면 vercel을 선택합니다. Git 참조로 새 배포 만들기

이후 vercel에 코드를 수정해 저장하면 Vercel의 정식 배포가 갱신됩니다. 키만 바꿨다면 vercel의 최신 Production 배포를 확인한 뒤 Redeploy합니다.

Preview는 변경을 미리 확인하는 배포입니다. 다른 브랜치가 Vercel에 Preview로 배포될 수 있어도, 정식 사이트는 위에서 지정한 vercel을 기준으로 갱신됩니다. Preview에서도 서버 조회를 시험하려면 해당 환경에도 키를 등록하고 새로 배포해야 합니다.

메뉴 이름과 위치는 화면 업데이트에 따라 조금 달라질 수 있습니다.

6. 두 배포 주소에서 각각 확인하기

Vercel: 키 입력 없이 조회하기

1. Vercel 배포 주소를 새 시크릿 창에서 엽니다.
2. 인증키 입력칸 없이 공고를 조회합니다.
3. 개찰결과 조회, 페이지 이동, 다운로드도 확인합니다.
4. 새로고침하거나 창을 닫았다가 다시 열어도 키 입력 없이 조회되는지 확인합니다.
5. 브라우저 개발자 도구의 Network에서 조회 요청을 선택합니다.
6. 브라우저 요청이 같은 사이트의 /api/g2b로 향하고, 요청 URL·헤더·본문·응답에 실제 API 키가 없는지 확인합니다.
7. 페이지 소스와 브라우저 저장소에도 실제 키가 없는지 확인합니다.

키를 다시 발급받았을 때는 HTML을 수정하는 대신 Vercel 환경 변수 값을 바꾸고 재배포합니다.

GitHub Pages: 기존 방식으로 조회하기

1. 기본과정에서 기록한 github.io 주소를 새 시크릿 창에서 엽니다.
2. 인증키 입력칸이 남아 있고 비어 있는지 확인합니다.
3. 자신의 Decoding 인증키를 직접 입력해 공고·개찰결과를 조회합니다.
4. Settings → Pages의 배포 브랜치가 여전히 main인지 확인합니다.

두 주소를 다음처럼 구분해서 기록합니다.

위의 브라우저에 키가 전달되지 않는지 확인하는 절차는 Vercel 버전의 기준입니다. GitHub Pages 버전은 사용자가 입력한 키로 브라우저에서 직접 API를 요청합니다.

7. 잘되지 않을 때 확인할 것

AI에게 수정을 요청할 때는 오류 메시지와 관련 코드만 전달하고, 실제 키가 보이는 화면이나 로그는 보내지 않습니다.

8. 두 버전을 유지하며 수정하기

• 기본과정 파일을 수정할 때는 main을 선택합니다. Pages 배포가 완료되면 github.io 주소에서 확인합니다.
• 심화과정 파일을 수정할 때는 vercel을 선택합니다. Production 배포가 완료되면 정식 vercel.app 주소에서 확인합니다.
• 공통 화면이나 검색 기능을 개선한다면 필요한 변경을 두 브랜치에 각각 반영하고 두 주소에서 확인합니다. 한쪽 수정이 다른 쪽에 자동으로 반영되지는 않습니다.
• vercel을 통째로 main에 병합하지 않습니다. 서버 함수를 호출하는 HTML이 Pages에 올라가면 /api/g2b를 실행할 서버가 없어 조회가 실패합니다.

파일을 저장하기 전에는 브랜치 이름을, 동작을 확인할 때는 배포 주소를 확인합니다.

9. 공유 전에 알아둘 점

API 키가 숨겨져도, 공개된 조회 기능은 다른 사람이 호출할 수 있습니다. 이 구조에서는 방문자의 조회도 운영자가 등록한 키의 호출량을 사용합니다.

개인 실습으로 먼저 검증하고, 팀 업무용으로 공유할 때는 로그인·접근 제한과 서버의 요청 횟수 제한을 함께 검토합니다. 화면에만 비밀번호를 넣거나 CORS를 설정하는 것만으로 사용자 인증이 되지는 않습니다. Vercel의 사용량과 공공 API의 호출 한도도 확인합니다.

심화과정 완료 확인

• 같은 저장소에서 main을 기준으로 vercel 브랜치를 만들었다.
• vercel 브랜치에 수정한 index.html과 api/g2b.js를 올렸다.
• Pages 배포 설정은 main / /(root)로 유지했다.
• Vercel의 Production Branch Tracking을 vercel로 지정했다.
• 실제 API 키와 .env 파일은 GitHub에 올리지 않았다.
• Vercel에 DATA_GO_KR_API_KEY를 등록했다.
• 환경 변수 등록 후 vercel의 새 Production 배포가 Ready인지 확인했다.
• 시크릿 창에서도 키를 입력하지 않고 조회된다.
• Vercel 버전의 브라우저 요청과 응답에 실제 API 키가 없다.
• 기존 GitHub Pages에서도 키를 직접 입력하면 조회된다.
• 두 배포 주소를 기록하고 브랜치를 합치지 않은 상태로 유지했다.
• 공유받은 사람의 조회도 내 API 호출량을 사용한다는 점을 이해했다.

공식 참고자료

• GitHub 계정 만들기
• 새 저장소 만들기
• 웹화면에서 파일 올리기
• GitHub Pages 배포 위치 설정하기
• GitHub Pages 사이트 만들기
• GitHub Pages 공개 중단하기

오늘의 핵심

HTML 업무도구는 내 컴퓨터에만 보관할 수도 있지만, GitHub Pages에 배포하면 별도 프로그램 설치 없이 웹주소로 열 수 있습니다. 배포된 파일은 인터넷에 공개되므로 인증키와 내부자료를 넣지 않는 것이 가장 중요합니다.