GitHub와 Vercel로 시작하는 배포 완벽 가이드

코드를 작성했다면 이제 세상에 공개할 차례입니다. GitHub에 코드를 올리고 Vercel로 배포하는 전체 과정을 실무 상황 스토리로 풀어냅니다. 초급 개발자도 따라하면서 자연스럽게 배포 프로세스를 이해할 수 있습니다.

1. GitHub 리포지토리 생성 및 푸시

이제 막 첫 프로젝트를 완성한 김개발 씨는 들뜬 마음으로 선배에게 물었습니다. "제 프로젝트를 다른 사람들도 볼 수 있게 하고 싶은데, 어떻게 해야 하나요?" 선배 박시니어 씨는 미소를 지으며 대답했습니다.

"그럼 먼저 GitHub에 코드를 올려봐야겠네요."

GitHub 리포지토리는 코드를 저장하고 관리하는 온라인 저장소입니다. 마치 클라우드 드라이브에 파일을 올리는 것처럼, 개발자들은 Git을 사용해 코드를 GitHub에 업로드합니다.

이것은 배포의 첫 번째 단계이며, 협업과 버전 관리의 시작점이 됩니다.

다음 코드를 살펴봅시다.

# Git 초기화 및 원격 저장소 연결
git init
git add .
git commit -m "Initial commit: 프로젝트 첫 커밋"

# GitHub 리포지토리 생성 후 연결
git remote add origin https://github.com/username/my-project.git
git branch -M main
git push -u origin main

# 이후 변경사항 푸시
git add .
git commit -m "feat: 새로운 기능 추가"
git push

김개발 씨는 3개월 동안 열심히 만든 포트폴리오 웹사이트를 완성했습니다. 로컬에서는 완벽하게 작동하는데, 이제 친구들과 면접관들에게 보여주고 싶었습니다.

하지만 어떻게 해야 할지 막막했습니다. 선배 박시니어 씨가 다가와 물었습니다.

"혹시 GitHub 계정은 있어요?" 김개발 씨는 고개를 끄덕였습니다. "네, 회원가입은 했는데 한 번도 사용해본 적은 없어요." 코드 저장소의 필요성 왜 코드를 GitHub에 올려야 할까요?

쉽게 비유하자면, GitHub는 마치 개발자들의 도서관과 같습니다. 여러분이 작성한 코드라는 책을 이 도서관에 보관하면, 언제 어디서든 접근할 수 있고, 다른 사람들과 공유할 수도 있습니다.

더 중요한 것은, 이 도서관이 책의 모든 개정판을 자동으로 보관해준다는 점입니다. GitHub가 없던 시절에는 어땠을까요?

개발자들은 USB 메모리에 코드를 복사하거나, 이메일로 파일을 주고받았습니다. 프로젝트 폴더 이름에 날짜를 붙여가며 버전을 관리했죠.

"최종.zip", "진짜최종.zip", "진짜진짜최종.zip" 같은 파일명을 본 적이 있을 것입니다. 협업할 때는 더 큰 혼란이 일어났습니다.

Git과 GitHub의 차이 여기서 잠깐, Git과 GitHub를 구분해야 합니다. Git은 버전 관리 시스템입니다.

여러분의 컴퓨터에 설치되어, 코드의 변경사항을 추적하고 기록합니다. 마치 타임머신처럼 과거의 어느 시점으로든 돌아갈 수 있게 해줍니다.

GitHub는 Git으로 관리되는 코드를 온라인에 저장하는 플랫폼입니다. Git이 개인 노트라면, GitHub는 클라우드 노트 서비스인 셈입니다.

리포지토리 생성하기 박시니어 씨는 김개발 씨의 컴퓨터 앞에 앉아 하나씩 설명해주었습니다. "먼저 GitHub 웹사이트에 접속해서 새 리포지토리를 만들어요.

오른쪽 상단의 플러스 버튼을 누르고 'New repository'를 선택하면 됩니다. 리포지토리 이름은 프로젝트 이름과 같게 하는 게 좋아요." 김개발 씨는 화면을 보며 따라했습니다.

리포지토리 이름에 "my-portfolio"를 입력하고, Public으로 설정했습니다. README 파일은 나중에 추가하기로 했습니다.

로컬 Git 초기화 이제 컴퓨터의 프로젝트 폴더에서 작업할 차례입니다. 터미널을 열고 프로젝트 폴더로 이동한 후, git init 명령어를 실행합니다.

이 명령어는 현재 폴더를 Git이 관리하는 저장소로 만들어줍니다. 눈에 보이지 않지만, .git이라는 숨김 폴더가 생성되어 모든 버전 정보를 저장하게 됩니다.

다음으로 git add . 명령어를 실행합니다.

점(.)은 현재 폴더의 모든 파일을 의미합니다. 이 명령어는 변경된 파일들을 스테이징 영역에 올립니다.

마치 택배를 보내기 전에 박스에 물건을 담는 것과 같습니다. 첫 번째 커밋 git commit 명령어는 스테이징 영역의 파일들을 실제로 저장합니다.

-m 옵션 뒤에는 커밋 메시지를 작성합니다. "Initial commit: 프로젝트 첫 커밋"처럼 무엇을 했는지 명확하게 작성하는 것이 중요합니다.

나중에 커밋 히스토리를 볼 때 어떤 변경사항이 있었는지 쉽게 파악할 수 있기 때문입니다. 원격 저장소 연결 이제 로컬 저장소와 GitHub의 원격 저장소를 연결해야 합니다.

git remote add origin 명령어는 "origin"이라는 이름으로 원격 저장소를 등록합니다. origin은 관례적으로 사용하는 기본 원격 저장소 이름입니다.

URL은 GitHub에서 리포지토리를 만들 때 제공된 주소를 사용합니다. git branch -M main은 기본 브랜치 이름을 main으로 설정합니다.

예전에는 master라는 이름을 썼지만, 최근에는 main을 표준으로 사용합니다. 코드 푸시하기 드디어 마지막 단계입니다.

git push -u origin main을 실행하면 로컬의 코드가 GitHub로 업로드됩니다. -u 옵션은 upstream을 설정하는 것으로, 다음부터는 git push만 입력해도 자동으로 origin의 main 브랜치로 푸시됩니다.

처음에는 GitHub 로그인을 요구할 수 있습니다. 사용자명과 비밀번호(또는 토큰)를 입력하면 됩니다.

지속적인 업데이트 김개발 씨가 물었습니다. "그럼 코드를 수정할 때마다 이 과정을 다시 해야 하나요?" 박시니어 씨는 고개를 저었습니다.

"처음 설정은 한 번만 하면 돼요. 이후에는 세 가지 명령어만 기억하면 됩니다." 코드를 수정한 후에는 git add .로 변경사항을 스테이징하고, git commit -m "메시지"로 커밋한 다음, git push로 GitHub에 올리면 됩니다.

이 세 가지가 일상적인 작업 흐름입니다. 주의할 점 초보 개발자들이 흔히 하는 실수가 있습니다.

첫째, node_modules 폴더나 .env 파일처럼 GitHub에 올리면 안 되는 파일들을 실수로 푸시하는 경우입니다. 이를 방지하려면 .gitignore 파일을 만들어 제외할 파일 목록을 작성해야 합니다.

둘째, 커밋 메시지를 대충 작성하는 것입니다. "수정", "ㅇㅇ" 같은 메시지는 나중에 히스토리를 볼 때 전혀 도움이 되지 않습니다.

"feat: 로그인 기능 추가", "fix: 버튼 클릭 버그 수정"처럼 구체적으로 작성하세요. 완료 김개발 씨는 GitHub 리포지토리 페이지를 새로고침했습니다.

자신이 작성한 코드가 온라인에 올라와 있었습니다. "와, 진짜 올라갔네요!" 이제 코드를 안전하게 보관할 수 있게 되었고, 배포를 위한 준비도 끝났습니다.

다음 단계는 Vercel을 연결하는 것입니다.

실전 팁

💡 - .gitignore 파일을 프로젝트 시작부터 만들어 민감한 정보가 푸시되지 않도록 하세요

커밋 메시지는 "feat:", "fix:", "docs:" 같은 접두사를 사용해 일관성 있게 작성하세요
큰 파일(이미지, 동영상)은 Git LFS를 사용하거나 CDN에 별도로 업로드하는 것이 좋습니다

2. Vercel 계정 설정

GitHub에 코드를 올린 김개발 씨는 박시니어 씨에게 다시 물었습니다. "코드는 올렸는데, 이걸 어떻게 웹사이트로 만들죠?" 선배는 노트북을 열며 답했습니다.

"Vercel이라는 서비스를 사용하면 몇 번의 클릭만으로 배포할 수 있어요."

Vercel은 프론트엔드 애플리케이션을 자동으로 배포하고 호스팅해주는 플랫폼입니다. 마치 음식 배달 앱처럼, 여러분의 코드를 전 세계 사용자에게 빠르게 전달해줍니다.

GitHub와 연동되어 코드를 푸시할 때마다 자동으로 새 버전이 배포되는 것이 가장 큰 장점입니다.

다음 코드를 살펴봅시다.

// vercel.json 설정 파일 예시
{
  "buildCommand": "npm run build",
  "outputDirectory": "dist",
  "devCommand": "npm run dev",
  "installCommand": "npm install",
  "framework": "vite",
  "regions": ["icn1"],
  "rewrites": [
    { "source": "/(.*)", "destination": "/index.html" }
  ]
}

김개발 씨는 배포라는 단어가 어렵게 느껴졌습니다. 개발은 했지만, 그것을 인터넷에 올리는 과정은 완전히 다른 영역처럼 보였습니다.

박시니어 씨는 친절하게 설명을 시작했습니다. "예전에는 배포하려면 서버를 직접 설정하고, 도메인을 연결하고, SSL 인증서를 설치하는 등 복잡한 과정을 거쳐야 했어요.

하지만 지금은 Vercel 같은 플랫폼이 모든 것을 자동화해줍니다." Vercel이란 무엇인가 Vercel을 쉽게 비유하자면, 온라인 인쇄소와 같습니다. 여러분이 디자인 파일을 주면, 인쇄소가 알아서 인쇄하고 배송까지 해주는 것처럼, Vercel은 여러분의 코드를 받아서 빌드하고 전 세계 서버에 배포해줍니다.

심지어 파일을 수정하면 자동으로 다시 인쇄해서 보내주는 똑똑한 인쇄소입니다. Vercel은 특히 Next.js를 만든 회사이기도 합니다.

따라서 Next.js 프로젝트는 물론이고, React, Vue, Svelte 등 대부분의 프론트엔드 프레임워크를 지원합니다. 왜 Vercel을 선택할까 전통적인 방식으로 배포하려면 어떤 과정을 거쳐야 할까요?

먼저 AWS나 GCP 같은 클라우드 서비스에서 서버를 빌려야 합니다. 그리고 그 서버에 Node.js를 설치하고, Nginx를 설정하고, 방화벽을 구성하고, SSL 인증서를 발급받아야 합니다.

코드를 수정할 때마다 서버에 접속해서 파일을 업데이트하고 서비스를 재시작해야 하죠. 초보 개발자에게는 너무 어렵고 복잡한 과정입니다.

실수로 서버를 잘못 설정하면 보안 문제가 생길 수도 있습니다. Vercel의 강력한 기능들 Vercel을 사용하면 이 모든 과정이 자동화됩니다.

첫째, 자동 배포가 가능합니다. GitHub에 코드를 푸시하면 Vercel이 자동으로 감지하고 빌드를 시작합니다.

몇 분 안에 새 버전이 배포되고, 고유한 URL이 생성됩니다. 둘째, 프리뷰 배포를 제공합니다.

Pull Request를 만들면 본 사이트와는 별도로 미리보기 버전이 자동으로 배포됩니다. 팀원들이 실제로 작동하는 화면을 보면서 리뷰할 수 있어 매우 편리합니다.

셋째, 글로벌 CDN을 무료로 사용할 수 있습니다. 전 세계 곳곳에 있는 서버에 여러분의 사이트가 복제되어, 사용자가 어디에 있든 빠르게 접속할 수 있습니다.

계정 만들기 박시니어 씨는 Vercel 웹사이트를 열었습니다. "vercel.com에 접속해서 'Sign Up' 버튼을 누르세요." 가입 방법은 여러 가지가 있지만, GitHub 계정으로 로그인하는 것을 강력히 추천합니다.

그래야 GitHub 리포지토리와의 연동이 자동으로 설정되기 때문입니다. "Continue with GitHub" 버튼을 클릭하면 GitHub 인증 페이지로 이동합니다.

Vercel이 GitHub 계정에 접근할 수 있도록 권한을 승인해야 합니다. 걱정하지 마세요.

Vercel은 읽기 권한만 요청하며, 여러분의 코드를 함부로 수정할 수 없습니다. 팀과 개인 계정 계정을 만들 때 개인 계정과 팀 계정 중 선택할 수 있습니다.

개인 프로젝트라면 개인 계정으로 충분합니다. Hobby 플랜은 완전히 무료이며, 대부분의 기능을 제한 없이 사용할 수 있습니다.

상업적인 프로젝트가 아니라면 Hobby 플랜을 선택하세요. 팀 계정은 여러 명이 협업할 때 유용합니다.

팀원을 초대하고, 역할을 부여하고, 공동으로 프로젝트를 관리할 수 있습니다. 하지만 유료이므로, 처음에는 개인 계정으로 시작하는 것이 좋습니다.

대시보드 둘러보기 로그인하면 Vercel 대시보드가 나타납니다. 왼쪽에는 프로젝트 목록이 표시됩니다.

아직은 비어있을 것입니다. 오른쪽 상단의 "Add New" 버튼을 누르면 새 프로젝트를 추가할 수 있습니다.

대시보드에서는 배포 상태, 분석 데이터, 도메인 설정 등을 확인할 수 있습니다. 처음에는 복잡해 보일 수 있지만, 자주 사용하다 보면 직관적인 인터페이스라는 것을 알게 됩니다.

GitHub 연동 확인 Settings 메뉴로 이동하면 연동된 GitHub 계정을 확인할 수 있습니다. "Git Integration" 탭에서 어떤 리포지토리에 접근할 수 있는지 관리할 수 있습니다.

보안을 위해 필요한 리포지토리만 접근 권한을 주는 것이 좋습니다. 만약 GitHub 연동이 제대로 되지 않았다면, "Configure GitHub App" 버튼을 눌러 다시 설정할 수 있습니다.

무료 플랜의 한계 김개발 씨가 물었습니다. "무료로 계속 사용할 수 있나요?" 박시니어 씨는 고개를 끄덕였습니다.

"네, Hobby 플랜은 영구 무료예요. 하지만 몇 가지 제한이 있습니다." Hobby 플랜에서는 월 100GB의 대역폭과 100시간의 빌드 시간을 제공합니다.

개인 프로젝트나 포트폴리오 사이트에는 충분한 양입니다. 하지만 상업적으로 사용하거나, 팀 기능이 필요하거나, 더 많은 리소스가 필요하면 Pro 플랜으로 업그레이드해야 합니다.

완료 계정 설정이 완료되었습니다. 이제 실제로 프로젝트를 배포할 준비가 되었습니다.

김개발 씨는 Vercel 대시보드를 보며 설렜습니다. 곧 자신의 프로젝트가 실제 URL을 가지고 인터넷에 공개될 것이기 때문입니다.

실전 팁

💡 - GitHub 계정으로 가입하면 리포지토리 연동이 자동으로 설정되어 편리합니다

Hobby 플랜은 개인 프로젝트에 충분하며, 상업적 사용만 아니면 무료로 계속 쓸 수 있습니다
여러 프로젝트를 관리한다면 팀 계정을 만들기보다 개인 계정에서 프로젝트별로 분리하는 것이 비용 효율적입니다

3. Vercel 배포 설정

드디어 실제 배포를 할 시간입니다. 김개발 씨는 긴장된 마음으로 마우스를 움직였습니다.

"지금 클릭하면 진짜 배포되는 건가요?" 박시니어 씨는 여유롭게 답했습니다. "걱정하지 마세요.

잘못되어도 언제든 다시 배포할 수 있어요."

Vercel 배포는 GitHub 리포지토리를 선택하고 몇 가지 설정만 하면 자동으로 진행됩니다. 마치 자동 세탁기처럼, 빌드 명령어와 출력 디렉토리만 알려주면 Vercel이 알아서 코드를 빌드하고 배포합니다.

한 번 설정하면 이후에는 코드를 푸시할 때마다 자동으로 재배포됩니다.

다음 코드를 살펴봅시다.

// package.json의 scripts 설정 확인
{
  "name": "my-portfolio",
  "version": "1.0.0",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  },
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  }
}

김개발 씨는 Vercel 대시보드에서 "Add New Project" 버튼을 눌렀습니다. 화면이 바뀌면서 GitHub 리포지토리 목록이 나타났습니다.

박시니어 씨가 화면을 가리키며 설명했습니다. "여기서 아까 만든 리포지토리를 선택하면 돼요." 리포지토리 선택하기 Import Git Repository 페이지에서 연동된 GitHub 계정의 리포지토리들이 표시됩니다.

만약 리포지토리가 보이지 않는다면 "Adjust GitHub App Permissions" 링크를 클릭해서 권한을 확인해야 합니다. 때로는 특정 Organization의 리포지토리만 접근 권한이 있을 수 있습니다.

김개발 씨는 "my-portfolio" 리포지토리 옆의 "Import" 버튼을 클릭했습니다. 새로운 설정 페이지가 나타났습니다.

프로젝트 설정 이해하기 Configure Project 화면에서는 여러 설정 항목이 있습니다. 첫 번째는 프로젝트 이름입니다.

기본적으로 리포지토리 이름이 자동으로 입력됩니다. 이 이름은 Vercel URL의 일부가 되므로, 원한다면 수정할 수 있습니다.

예를 들어 "my-portfolio"라는 이름이면 배포 URL은 "my-portfolio.vercel.app"이 됩니다. 두 번째는 Framework Preset입니다.

Vercel은 똑똑하게도 리포지토리의 코드를 분석해서 어떤 프레임워크를 사용했는지 자동으로 감지합니다. React, Next.js, Vue, Svelte 등 대부분의 프레임워크를 인식할 수 있습니다.

빌드 설정 구성하기 Build and Output Settings 섹션이 가장 중요합니다. Build Command는 프로젝트를 빌드하는 명령어입니다.

package.json의 scripts 섹션에 정의된 명령어를 사용합니다. 보통 "npm run build" 또는 "yarn build"입니다.

Vercel이 자동으로 감지하지만, 확인하는 것이 좋습니다. Output Directory는 빌드 결과물이 생성되는 폴더입니다.

Vite를 사용한다면 "dist", Create React App이라면 "build", Next.js라면 ".next" 폴더가 기본값입니다. 이것도 자동으로 설정되지만, 프로젝트 설정에 따라 다를 수 있으니 확인이 필요합니다.

Install Command는 의존성 패키지를 설치하는 명령어입니다. "npm install", "yarn install", 또는 "pnpm install"이 될 수 있습니다.

package-lock.json이 있으면 npm을, yarn.lock이 있으면 yarn을 자동으로 선택합니다. 환경 변수가 필요한 경우 김개발 씨의 프로젝트는 API 키를 사용하고 있었습니다.

로컬에서는 .env 파일에 저장했는데, 이 파일은 .gitignore에 추가되어 GitHub에는 올라가지 않았습니다. 박시니어 씨가 설명했습니다.

"그럴 때는 Environment Variables 섹션에서 환경 변수를 추가하면 돼요." "Add" 버튼을 클릭하고, 변수 이름과 값을 입력합니다. 예를 들어 VITE_API_KEY라는 변수가 필요하다면, Name에 "VITE_API_KEY"를, Value에 실제 API 키를 입력합니다.

여러 개의 환경 변수를 추가할 수 있으며, Production, Preview, Development 환경별로 다른 값을 설정할 수도 있습니다. Root Directory 설정 대부분의 경우 프로젝트의 루트 디렉토리가 리포지토리의 최상위 폴더입니다.

하지만 모노레포를 사용하거나, 프로젝트가 하위 폴더에 있다면 Root Directory를 지정해야 합니다. 예를 들어 리포지토리 구조가 다음과 같다면: /my-repo /frontend /src package.json /backend Root Directory를 "frontend"로 설정해야 합니다.

배포 시작하기 모든 설정을 확인한 김개발 씨는 "Deploy" 버튼을 클릭했습니다. 화면이 바뀌면서 빌드 로그가 실시간으로 표시되기 시작했습니다.

마치 터미널에서 명령어를 실행하는 것처럼, 각 단계의 진행 상황을 볼 수 있었습니다. "Cloning repository..." "Installing dependencies..." "Building application..." "Deploying to edge network..." 김개발 씨는 화면을 뚫어지게 바라봤습니다.

몇 분이 지나지 않아, "Congratulations!" 메시지와 함께 배포가 완료되었습니다. 배포 결과 확인하기 배포가 완료되면 세 가지 URL이 제공됩니다.

첫째, Production URL입니다. 이것이 실제 사용자들이 접속할 주소입니다.

"https://my-portfolio.vercel.app" 같은 형식입니다. 둘째, Deployment URL입니다.

각 배포마다 고유한 URL이 생성됩니다. "https://my-portfolio-abc123.vercel.app" 같은 형식으로, 특정 버전을 공유할 때 유용합니다.

셋째, Git Branch URL입니다. 브랜치별로 고유한 URL이 있어, 여러 버전을 동시에 테스트할 수 있습니다.

배포 실패 시 대처법 모든 배포가 항상 성공하는 것은 아닙니다. 빌드 중에 에러가 발생하면 Vercel은 자세한 로그를 보여줍니다.

어느 단계에서 실패했는지, 어떤 에러 메시지가 나왔는지 확인할 수 있습니다. 대부분의 경우 의존성 패키지 누락, 환경 변수 미설정, 또는 코드 오류가 원인입니다.

로그를 차근차근 읽어보면 해결 방법을 찾을 수 있습니다. 에러를 수정한 후 GitHub에 푸시하면 Vercel이 자동으로 재배포를 시작합니다.

자동 재배포 가장 놀라운 기능은 자동 재배포입니다. 이제부터는 GitHub에 코드를 푸시할 때마다 Vercel이 자동으로 감지하고 새로 배포합니다.

수동으로 배포 버튼을 누를 필요가 없습니다. main 브랜치에 푸시하면 프로덕션 배포가, 다른 브랜치에 푸시하면 프리뷰 배포가 자동으로 생성됩니다.

완료 김개발 씨는 제공된 URL을 클릭했습니다. 브라우저가 열리면서 자신이 만든 포트폴리오 사이트가 나타났습니다.

인터넷에 연결된 누구나 이 주소로 접속할 수 있습니다. "와, 진짜 배포됐어요!" 김개발 씨는 감격스러워했습니다.

3개월 동안 만든 프로젝트가 드디어 세상에 공개되었습니다.

실전 팁

💡 - Framework Preset이 자동으로 잘못 감지되었다면 수동으로 변경할 수 있습니다

빌드 에러가 발생하면 로컬에서 npm run build를 실행해 먼저 테스트하세요
환경 변수는 절대 GitHub에 올리지 말고 Vercel 대시보드에서만 설정하세요

4. 환경 변수 및 빌드 최적화

배포는 성공했지만, 김개발 씨는 한 가지 문제를 발견했습니다. 사이트가 생각보다 느리게 로딩되었고, 일부 기능이 제대로 작동하지 않았습니다.

박시니어 씨는 모니터를 보며 말했습니다. "환경 변수 설정과 빌드 최적화가 필요하겠네요."

환경 변수는 코드에 하드코딩하지 않고 외부에서 주입하는 설정값입니다. API 키, 데이터베이스 URL 같은 민감한 정보를 안전하게 관리할 수 있습니다.

빌드 최적화는 번들 크기를 줄이고 로딩 속도를 개선하는 작업으로, 사용자 경험을 크게 향상시킵니다.

다음 코드를 살펴봅시다.

// .env.local (로컬 개발용)
VITE_API_KEY=your_api_key_here
VITE_API_URL=https://api.example.com
VITE_ENVIRONMENT=development

// vite.config.js (빌드 최적화 설정)
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          vendor: ['react', 'react-dom']
        }
      }
    },
    chunkSizeWarningLimit: 1000
  }
})

김개발 씨의 포트폴리오는 GitHub API를 사용해서 레포지토리 목록을 보여주는 기능이 있었습니다. 그런데 배포된 사이트에서는 이 기능이 작동하지 않았습니다.

박시니어 씨가 개발자 도구를 열어 콘솔을 확인했습니다. "API key is undefined"라는 에러 메시지가 보였습니다.

환경 변수란 무엇인가 환경 변수를 쉽게 비유하자면, 건물의 비밀번호와 같습니다. 집마다 현관문 비밀번호가 다르듯이, 개발 환경과 프로덕션 환경에서 사용하는 설정값이 다를 수 있습니다.

이런 값들을 코드에 직접 쓰면 보안 문제가 생기고, 환경을 바꿀 때마다 코드를 수정해야 합니다. 환경 변수를 사용하면 코드는 그대로 두고, 환경에 따라 다른 값을 주입할 수 있습니다.

환경 변수가 필요한 이유 환경 변수 없이 개발하던 시절에는 어떤 문제가 있었을까요? 개발자들은 API 키를 코드에 직접 작성했습니다.

그러다 실수로 GitHub에 올리면, 누구나 그 키를 볼 수 있었습니다. 악의적인 사람이 키를 훔쳐서 무단으로 사용할 수 있었죠.

또한 개발 서버와 프로덕션 서버의 설정이 달라야 하는데, 배포할 때마다 코드를 수정해야 했습니다. 실수로 개발용 API URL을 프로덕션에 배포하는 일도 잦았습니다.

Vercel에서 환경 변수 설정하기 박시니어 씨는 Vercel 대시보드로 돌아갔습니다. 프로젝트 페이지에서 "Settings" 탭을 클릭하고, 왼쪽 메뉴에서 "Environment Variables"를 선택했습니다.

여기서 환경 변수를 추가, 수정, 삭제할 수 있습니다. "Add" 버튼을 클릭하면 세 개의 입력 필드가 나타납니다.

Name에는 변수 이름을, Value에는 실제 값을 입력합니다. Environment에서는 이 변수를 어느 환경에서 사용할지 선택합니다.

Production, Preview, Development 세 가지 환경을 선택할 수 있습니다. Production은 실제 배포 환경, Preview는 Pull Request의 미리보기, Development는 로컬 개발 환경입니다.

환경 변수 명명 규칙 Vite를 사용하는 경우, 클라이언트에서 접근할 수 있는 환경 변수는 반드시 VITE_ 접두사로 시작해야 합니다. Next.js는 NEXT_PUBLIC_ 접두사를 사용합니다.

Create React App은 REACT_APP_을 사용하죠. 이것은 보안을 위한 설계입니다.

접두사가 없는 환경 변수는 서버 사이드에서만 접근할 수 있어, 민감한 정보가 클라이언트에 노출되는 것을 방지합니다. 환경별로 다른 값 사용하기 김개발 씨는 개발 환경에서는 테스트 API를, 프로덕션에서는 실제 API를 사용하고 싶었습니다.

같은 이름의 환경 변수를 추가하되, Environment 설정을 다르게 하면 됩니다. VITE_API_URL을 두 번 추가하는데, 하나는 Development로 설정하고 값은 "http://localhost:3000", 다른 하나는 Production으로 설정하고 값은 "https://api.production.com"으로 입력합니다.

이렇게 하면 로컬에서 개발할 때는 로컬 서버를, 배포된 사이트에서는 실제 API 서버를 자동으로 사용합니다. 민감한 정보 관리 API 키, 데이터베이스 비밀번호, OAuth 시크릿 같은 민감한 정보는 절대 코드에 포함시키면 안 됩니다.

심지어 Private 리포지토리라고 해도 마찬가지입니다. 나중에 리포지토리를 Public으로 전환하거나, 팀원이 실수로 공유할 수 있기 때문입니다.

모든 민감한 정보는 환경 변수로 관리하고, .env 파일은 .gitignore에 추가해야 합니다. 빌드 최적화의 중요성 환경 변수 설정을 마친 후, 박시니어 씨는 사이트의 로딩 속도를 분석했습니다.

Chrome DevTools의 Network 탭을 열어보니, JavaScript 번들 파일이 3MB나 되었습니다. 이것은 너무 큽니다.

사용자가 사이트에 처음 접속할 때 3MB를 다운로드해야 하면, 특히 모바일 네트워크에서는 매우 느리게 느껴집니다. Code Splitting 적용하기 Code Splitting은 큰 번들을 작은 조각으로 나누는 기술입니다.

마치 책을 챕터별로 나눠서 필요한 부분만 읽는 것과 같습니다. 사용자가 처음 접속할 때는 첫 페이지에 필요한 코드만 로드하고, 다른 페이지로 이동할 때 해당 페이지의 코드를 추가로 로드하는 방식입니다.

React에서는 React.lazy()와 Suspense를 사용해서 컴포넌트 단위로 코드를 분할할 수 있습니다. Vite와 같은 번들러는 dynamic import를 자동으로 감지해서 별도의 chunk 파일로 분리해줍니다.

의존성 최적화 김개발 씨는 lodash 라이브러리를 사용하고 있었는데, 실제로는 몇 가지 함수만 필요했습니다. 하지만 전체 라이브러리를 import하고 있어 불필요하게 번들 크기가 커졌습니다.

박시니어 씨가 조언했습니다. "lodash 대신 lodash-es를 사용하고, 필요한 함수만 import하세요." javascript // 나쁜 예 import _ from 'lodash' _.debounce(func, 300) // 좋은 예 import { debounce } from 'lodash-es' debounce(func, 300) 이렇게 하면 Tree Shaking이 작동해서 사용하지 않는 코드는 번들에 포함되지 않습니다.

이미지 최적화 사이트가 느린 또 다른 이유는 최적화되지 않은 이미지였습니다. 고해상도 PNG 파일을 그대로 사용하고 있어, 한 이미지가 2MB나 되었습니다.

박시니어 씨는 이미지를 WebP 형식으로 변환하고 적절한 크기로 리사이즈하도록 권했습니다. Vercel은 Image Optimization 기능을 제공합니다.

Next.js의 Image 컴포넌트를 사용하면 자동으로 이미지를 최적화하고, 디바이스에 맞는 크기로 제공합니다. 빌드 분석하기 변경사항을 적용한 후, 번들 크기가 어떻게 바뀌었는지 확인해야 합니다.

rollup-plugin-visualizer 같은 도구를 사용하면 번들의 구성을 시각적으로 볼 수 있습니다. 어떤 라이브러리가 얼마나 큰 공간을 차지하는지 한눈에 파악할 수 있어, 최적화 포인트를 찾기 쉽습니다.

재배포 및 확인 최적화를 마친 김개발 씨는 변경사항을 GitHub에 푸시했습니다. Vercel이 자동으로 재배포를 시작했고, 몇 분 후 새 버전이 배포되었습니다.

이번에는 JavaScript 번들이 800KB로 줄었고, 페이지 로딩 시간도 크게 개선되었습니다. Lighthouse 점수도 50점대에서 90점대로 상승했습니다.

완료 박시니어 씨는 만족스럽게 고개를 끄덕였습니다. "훨씬 나아졌네요.

환경 변수와 빌드 최적화는 배포의 필수 요소예요. 처음부터 신경 쓰면 나중에 고생하지 않아요." 김개발 씨는 이제 환경 변수의 중요성과 성능 최적화의 기초를 이해하게 되었습니다.

실전 팁

💡 - 환경 변수를 추가하거나 수정한 후에는 반드시 재배포해야 적용됩니다

.env 파일은 절대 Git에 커밋하지 말고, .env.example 파일로 변수 목록만 공유하세요
번들 크기는 500KB 이하로 유지하는 것을 목표로 하세요

5. 커스텀 도메인 연결

배포된 사이트를 친구에게 공유한 김개발 씨는 조금 아쉬웠습니다. "my-portfolio.vercel.app"이라는 URL이 전문적이지 않다고 느꼈기 때문입니다.

박시니어 씨가 물었습니다. "도메인을 사고 싶어요?" 김개발 씨는 고개를 끄덕였습니다.

커스텀 도메인은 여러분만의 고유한 웹 주소를 의미합니다. vercel.app 대신 myportfolio.com 같은 주소를 사용할 수 있어 더욱 전문적으로 보입니다.

Vercel은 도메인 연결을 매우 쉽게 만들어주며, SSL 인증서까지 자동으로 설정해줍니다.

다음 코드를 살펴봅시다.

// vercel.json에 도메인 리다이렉트 설정
{
  "redirects": [
    {
      "source": "/:path*",
      "has": [
        {
          "type": "host",
          "value": "www.myportfolio.com"
        }
      ],
      "destination": "https://myportfolio.com/:path*",
      "permanent": true
    }
  ],
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        {
          "key": "X-Content-Type-Options",
          "value": "nosniff"
        }
      ]
    }
  ]
}

김개발 씨는 도메인 구입이 복잡하고 비쌀 것이라고 생각했습니다. 하지만 박시니어 씨는 생각보다 간단하다고 설명했습니다.

"도메인은 연간 1만 원에서 2만 원 정도면 구입할 수 있어요. Namecheap, GoDaddy, 또는 국내 업체인 가비아 같은 곳에서 쉽게 살 수 있습니다." 도메인이란 무엇인가 도메인을 쉽게 비유하자면, 집 주소와 같습니다.

IP 주소는 192.168.0.1 같은 숫자 조합인데, 사람이 기억하기 어렵습니다. 도메인은 이것을 myportfolio.com처럼 기억하기 쉬운 이름으로 바꿔줍니다.

마치 "서울시 강남구 테헤란로 123"이라는 주소가 GPS 좌표보다 기억하기 쉬운 것과 같습니다. 도메인은 크게 **TLD(Top Level Domain)**와 **SLD(Second Level Domain)**로 나뉩니다.

myportfolio.com에서 .com이 TLD이고, myportfolio가 SLD입니다. 도메인 구입하기 박시니어 씨는 Namecheap 웹사이트를 열었습니다.

"먼저 원하는 도메인 이름을 검색해보세요. 이미 다른 사람이 사용 중이라면 구입할 수 없어요." 김개발 씨는 "kimdevportfolio"를 검색했습니다.

다행히 kimdevportfolio.com은 사용 가능했고, 가격은 연간 13달러였습니다. .com 도메인이 가장 일반적이지만, .dev, .io, .me 같은 TLD도 인기가 있습니다.

개발자 포트폴리오라면 .dev도 좋은 선택입니다. 다만 .dev는 조금 더 비쌀 수 있습니다.

도메인을 장바구니에 담고 결제를 진행합니다. 개인 정보 보호 기능(WHOIS Privacy)을 추가하는 것을 권장합니다.

이것이 없으면 도메인 소유자의 이메일과 전화번호가 공개될 수 있습니다. DNS 설정 이해하기 도메인을 구입했다고 바로 사용할 수 있는 것은 아닙니다.

DNS(Domain Name System) 설정이 필요합니다. DNS는 마치 전화번호부와 같습니다.

도메인 이름을 입력하면 어느 서버로 연결해야 하는지 알려주는 시스템입니다. 우리는 Vercel 서버로 연결되도록 설정해야 합니다.

Namecheap 대시보드에서 구입한 도메인을 클릭하고, "Advanced DNS" 탭으로 이동합니다. 여기서 DNS 레코드를 추가하거나 수정할 수 있습니다.

Vercel에 도메인 추가하기 먼저 Vercel 측에서 도메인을 추가해야 합니다. Vercel 프로젝트 대시보드에서 "Settings" 탭의 "Domains" 섹션으로 이동합니다.

입력 필드에 구입한 도메인(kimdevportfolio.com)을 입력하고 "Add" 버튼을 클릭합니다. Vercel은 도메인 소유권을 확인하기 위해 DNS 레코드 설정을 요구합니다.

화면에 어떤 레코드를 추가해야 하는지 친절하게 안내해줍니다. A 레코드와 CNAME 레코드 DNS 레코드에는 여러 종류가 있지만, 우리가 알아야 할 것은 A 레코드와 CNAME 레코드입니다.

A 레코드는 도메인을 특정 IP 주소로 연결합니다. Vercel은 76.76.21.21 같은 IP 주소를 제공합니다.

Type을 "A Record"로 선택하고, Host는 "@"(루트 도메인을 의미), Value는 Vercel이 제공한 IP 주소를 입력합니다. CNAME 레코드는 도메인을 다른 도메인으로 연결합니다.

www 서브도메인을 설정할 때 사용합니다. Type을 "CNAME Record"로 선택하고, Host는 "www", Value는 "cname.vercel-dns.com"을 입력합니다.

DNS 전파 대기 DNS 레코드를 저장했다고 바로 적용되는 것은 아닙니다. DNS 변경사항이 전 세계 DNS 서버에 전파되려면 시간이 걸립니다.

보통 몇 분에서 48시간까지 걸릴 수 있습니다. 대부분은 10~20분 이내에 완료되지만, 간혹 더 오래 걸리는 경우도 있습니다.

김개발 씨는 조바심이 났지만, 박시니어 씨는 여유롭게 말했습니다. "커피 한 잔 마시고 오면 대부분 완료되어 있을 거예요." DNS 전파 상태는 dnschecker.org 같은 웹사이트에서 확인할 수 있습니다.

도메인을 입력하면 전 세계 여러 지역에서 어떻게 해석되는지 보여줍니다. SSL 인증서 자동 발급 Vercel의 놀라운 점은 SSL 인증서를 자동으로 발급해준다는 것입니다.

SSL은 웹사이트와 사용자 간의 통신을 암호화하는 기술입니다. 브라우저 주소창에 자물쇠 아이콘이 표시되는 것을 본 적이 있을 것입니다.

이것이 SSL이 적용된 사이트라는 표시입니다. 예전에는 SSL 인증서를 직접 구입하고 설치해야 했습니다.

비용도 들고 설정도 복잡했죠. 하지만 Vercel은 Let's Encrypt를 사용해 무료로 자동 발급해줍니다.

도메인이 연결되면 몇 분 내에 HTTPS가 활성화됩니다. www와 non-www 리다이렉트 kimdevportfolio.com과 www.kimdevportfolio.com은 기술적으로 다른 주소입니다.

대부분의 웹사이트는 둘 중 하나를 기본으로 정하고, 나머지는 리다이렉트합니다. 예를 들어 www.google.com을 입력하면 google.com으로 리다이렉트되는 것을 볼 수 있습니다.

Vercel은 이것도 자동으로 처리해줍니다. Domains 설정에서 어느 것을 기본으로 할지 선택할 수 있습니다.

"Redirect www to apex domain"을 선택하면 www가 붙은 주소는 자동으로 루트 도메인으로 리다이렉트됩니다. 도메인 연결 확인 DNS 전파가 완료되면 Vercel 대시보드에서 도메인 상태가 "Valid Configuration"으로 바뀝니다.

김개발 씨는 브라우저에 kimdevportfolio.com을 입력했습니다. 자신의 포트폴리오 사이트가 새 주소로 정상적으로 표시되었습니다.

주소창에는 자물쇠 아이콘도 보였습니다. "와, 진짜 제 도메인으로 접속되네요!" 김개발 씨는 감탄했습니다.

이제 명함이나 이력서에 당당히 자신의 도메인을 적을 수 있게 되었습니다. 여러 도메인 연결하기 필요하다면 여러 개의 도메인을 같은 프로젝트에 연결할 수도 있습니다.

예를 들어 kimdevportfolio.com과 kimdevportfolio.dev를 모두 구입해서 같은 사이트로 연결할 수 있습니다. Vercel은 제한 없이 여러 도메인을 추가할 수 있으며, 어느 것을 기본 도메인으로 할지 선택할 수 있습니다.

완료 박시니어 씨는 마지막으로 조언했습니다. "도메인 갱신일을 잊지 마세요.

보통 1년 단위로 결제되는데, 갱신을 깜빡하면 도메인이 만료되어 다른 사람이 구입할 수 있어요." 김개발 씨는 달력에 갱신일을 표시해두었습니다. 이제 자신만의 고유한 웹 주소를 가지게 되었습니다.

실전 팁

💡 - 도메인은 짧고 기억하기 쉬운 것이 좋으며, 철자가 복잡하면 사람들이 잘못 입력할 수 있습니다

WHOIS Privacy 보호 기능을 반드시 활성화해서 개인 정보를 보호하세요
DNS 변경 후 24~48시간은 완전히 전파되는 데 걸리므로 인내심을 가지세요

6. 배포 후 디버깅 및 모니터링

사이트를 배포한 지 며칠 후, 김개발 씨는 사용자로부터 에러 제보를 받았습니다. "특정 페이지가 로딩되지 않아요." 하지만 자신의 컴퓨터에서는 정상적으로 작동했습니다.

박시니어 씨가 말했습니다. "배포 후 모니터링이 중요한 이유가 바로 이거예요."

배포 후 디버깅은 프로덕션 환경에서 발생하는 문제를 찾아 해결하는 과정입니다. 로컬에서는 보이지 않던 버그가 실제 사용자 환경에서 나타날 수 있습니다.

모니터링은 사이트의 성능과 에러를 지속적으로 관찰해서, 문제가 커지기 전에 발견하는 작업입니다.

다음 코드를 살펴봅시다.

// Vercel Analytics 설정 (Next.js)
// pages/_app.js
import { Analytics } from '@vercel/analytics/react'

function MyApp({ Component, pageProps }) {
  return (
    <>
      <Component {...pageProps} />
      <Analytics />
    </>
  )
}

export default MyApp

// 에러 추적을 위한 try-catch
async function fetchUserData() {
  try {
    const response = await fetch('/api/user')
    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`)
    }
    return await response.json()
  } catch (error) {
    console.error('Failed to fetch user data:', error)
    // 에러 리포팅 서비스로 전송
  }
}

김개발 씨는 당황했습니다. 자신의 브라우저에서는 모든 것이 완벽하게 작동하는데, 왜 다른 사용자는 에러를 경험하는 걸까요?

박시니어 씨는 차분하게 설명했습니다. "로컬 환경과 프로덕션 환경은 다릅니다.

브라우저 종류, 네트워크 상태, 디바이스 성능 등 수많은 변수가 있어요." 로컬과 프로덕션의 차이 개발할 때는 최신 Chrome 브라우저를 사용하고, 빠른 인터넷에 연결되어 있으며, 강력한 컴퓨터를 사용합니다. 하지만 실제 사용자는 오래된 Safari 브라우저를 쓸 수도 있고, 느린 모바일 네트워크를 사용할 수도 있으며, 저사양 스마트폰을 쓸 수도 있습니다.

이런 환경 차이 때문에 예상치 못한 문제가 발생할 수 있습니다. 또한 개발 모드에서는 자세한 에러 메시지가 표시되지만, 프로덕션 빌드에서는 보안을 위해 간략한 메시지만 표시됩니다.

따라서 문제를 진단하기가 더 어렵습니다. Vercel 로그 확인하기 박시니어 씨는 Vercel 대시보드의 "Deployments" 탭을 열었습니다.

최근 배포 목록이 표시되고, 각 배포를 클릭하면 상세 정보를 볼 수 있습니다. "Functions" 탭에서는 서버리스 함수의 실행 로그를, "Build Logs"에서는 빌드 과정의 로그를 확인할 수 있습니다.

김개발 씨의 경우, 특정 API 엔드포인트에서 500 에러가 발생하고 있었습니다. 로그를 보니 환경 변수가 제대로 설정되지 않아 데이터베이스 연결에 실패한 것이었습니다.

실시간 로그 모니터링 Vercel CLI를 설치하면 터미널에서 실시간으로 로그를 볼 수 있습니다. bash npm i -g vercel vercel login vercel logs 이 명령어를 실행하면 프로덕션 환경의 로그가 실시간으로 스트리밍됩니다.

마치 로컬에서 개발하는 것처럼 즉각적인 피드백을 받을 수 있어, 문제를 빠르게 파악할 수 있습니다. 에러 추적 서비스 연동 Vercel 로그만으로는 부족할 때가 있습니다.

특히 클라이언트 사이드에서 발생하는 JavaScript 에러는 Vercel 로그에 나타나지 않습니다. 이때 Sentry 같은 에러 추적 서비스가 유용합니다.

Sentry를 연동하면 사용자 브라우저에서 발생하는 모든 에러가 자동으로 수집되고, 어떤 환경에서 에러가 발생했는지 상세한 정보를 제공합니다. Sentry는 무료 플랜도 제공하며, Vercel과의 통합이 매우 쉽습니다.

Vercel Marketplace에서 "Add Integration" 버튼 하나로 설치할 수 있습니다. 성능 모니터링 에러만 추적하는 것으로는 충분하지 않습니다.

사이트의 성능도 지속적으로 모니터링해야 합니다. Vercel Analytics는 페이지 로딩 속도, Core Web Vitals, 지역별 성능 등을 측정해줍니다.

어느 페이지가 느린지, 어느 지역에서 문제가 있는지 한눈에 파악할 수 있습니다. Analytics는 Vercel 프로젝트에 쉽게 추가할 수 있습니다.

Next.js라면 컴포넌트 하나만 추가하면 되고, 다른 프레임워크도 간단한 스크립트 태그만 삽입하면 됩니다. Core Web Vitals 이해하기 Google은 Core Web Vitals라는 세 가지 핵심 성능 지표를 정의했습니다.

**LCP(Largest Contentful Paint)**는 가장 큰 콘텐츠가 화면에 표시되는 시간입니다. 2.5초 이내가 좋습니다.

**FID(First Input Delay)**는 사용자가 처음 상호작용할 때의 반응 속도입니다. 100ms 이내가 좋습니다.

**CLS(Cumulative Layout Shift)**는 레이아웃이 얼마나 불안정하게 변하는지 측정합니다. 0.1 이하가 좋습니다.

이 지표들은 SEO에도 영향을 미치므로, 개선하면 검색 순위도 올라갈 수 있습니다. A/B 테스트와 프리뷰 배포 새로운 기능을 배포하기 전에 테스트하고 싶을 때가 있습니다.

Vercel의 프리뷰 배포를 활용하면 본 사이트에 영향을 주지 않고 테스트할 수 있습니다. 새 브랜치를 만들어 푸시하면 자동으로 프리뷰 URL이 생성됩니다.

팀원들이나 일부 사용자에게만 이 URL을 공유해서 피드백을 받을 수 있습니다. 문제가 없다고 판단되면 main 브랜치에 merge하여 프로덕션 배포를 진행합니다.

롤백 기능 최악의 경우, 배포 후 치명적인 버그를 발견할 수 있습니다. Vercel은 즉시 롤백 기능을 제공합니다.

Deployments 탭에서 이전 버전을 선택하고 "Promote to Production" 버튼을 클릭하면, 몇 초 만에 이전 버전으로 되돌릴 수 있습니다. 롤백은 Git 히스토리를 변경하지 않으므로, 문제를 수정한 후 다시 배포하면 됩니다.

이것은 매우 강력한 안전장치입니다. 정기적인 건강 체크 박시니어 씨는 매주 월요일 아침마다 사이트 상태를 확인한다고 했습니다.

Vercel Analytics를 열어 지난주의 성능 지표를 리뷰하고, 에러 로그를 확인하며, 사용자 피드백을 점검합니다. 작은 문제들도 누적되면 큰 문제가 되므로, 정기적인 모니터링이 중요합니다.

UptimeRobot 같은 서비스를 사용하면 사이트가 다운되었을 때 즉시 알림을 받을 수도 있습니다. 무료 플랜으로도 5분마다 사이트를 체크할 수 있습니다.

사용자 피드백 수집 기술적인 모니터링 외에도 실제 사용자의 의견을 듣는 것이 중요합니다. 간단한 피드백 폼을 사이트에 추가하거나, Google Analytics로 사용자 행동을 분석할 수 있습니다.

어떤 페이지에서 사용자들이 많이 이탈하는지, 어떤 기능을 가장 많이 사용하는지 알 수 있습니다. 데이터 기반으로 의사결정을 내리면, 추측이 아닌 확실한 근거로 개선할 수 있습니다.

완료 김개발 씨는 에러를 수정하고 재배포했습니다. 이번에는 Sentry를 연동하고 Analytics도 활성화했습니다.

이제 문제가 발생하면 즉시 알 수 있을 것입니다. 박시니어 씨는 마지막으로 말했습니다.

"배포는 끝이 아니라 시작이에요. 지속적으로 관찰하고, 개선하고, 사용자의 피드백을 듣는 것이 진짜 개발자의 일입니다." 김개발 씨는 이제 배포의 전체 과정을 이해하게 되었습니다.

GitHub에서 코드를 관리하고, Vercel로 배포하고, 커스텀 도메인을 연결하고, 성능을 모니터링하는 모든 과정을 경험했습니다.

실전 팁

💡 - 에러가 발생하면 로컬에서 프로덕션 빌드를 먼저 테스트해보세요 (npm run build && npm run preview)

Sentry 같은 에러 추적 도구는 무료 플랜도 충분히 유용하니 반드시 설치하세요
Vercel Analytics의 Core Web Vitals를 주기적으로 확인하여 성능 저하를 조기에 발견하세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#Vercel#GitHub#Deployment#CI/CD#DevOps#Three.js,Blender,3D웹개발

GitHub와 Vercel로 시작하는 배포 완벽 가이드

# GitHub와 Vercel로 시작하는 배포 완벽 가이드 코드를 작성했다면 이제 세상에 공개할 차례입니다. GitHub에 코드를 올리고 Vercel로 배포하는 전체 과정을 실무 상황 스토리로 풀어냅니다. 초급 개발자도 따라하면서 자연스럽게 배포 프로세스를 이해할 수 있습니다. --- ## 목차 1. [GitHub_리포지토리_생성_및_푸시](#github-리포지토리-생성-및-푸시) 2. [Vercel_계정_설정](#vercel-계정-설정) 3. [Vercel_배포_설정](#vercel-배포-설정) 4. [환경_변수_및_빌드_최적화](#환경-변수-및-빌드-최적화) 5. [커스텀_도메인_연결](#커스텀-도메인-연결) 6. [배포_후_디버깅_및_모니터링](#배포-후-디버깅-및-모니터링) --- ## 1. GitHub_리포지토리_생성_및_푸시 이제 막 첫 프로젝트를 완성한 김개발 씨는 들뜬 마음으로 선배에게 물었습니다. "제 프로젝트를 다른 사람들도 볼 수 있게 하고 싶은데, 어떻게 해야 하나요?" 선배 박시니어 씨는 미소를 지으며 대답했습니다. "그럼 먼저 GitHub에 코드를 올려봐야겠네요." **GitHub 리포지토리**는 코드를 저장하고 관리하는 온라인 저장소입니다. 마치 클라우드 드라이브에 파일을 올리는 것처럼, 개발자들은 Git을 사용해 코드를 GitHub에 업로드합니다. 이것은 배포의 첫 번째 단계이며, 협업과 버전 관리의 시작점이 됩니다. 다음 코드를 살펴봅시다. ```javascript # Git 초기화 및 원격 저장소 연결 git init git add . git commit -m "Initial commit: 프로젝트 첫 커밋" # GitHub 리포지토리 생성 후 연결 git remote add origin https://github.com/username/my-project.git git branch -M main git push -u origin main # 이후 변경사항 푸시 git add . git commit -m "feat: 새로운 기능 추가" git push ``` 김개발 씨는 3개월 동안 열심히 만든 포트폴리오 웹사이트를 완성했습니다. 로컬에서는 완벽하게 작동하는데, 이제 친구들과 면접관들에게 보여주고 싶었습니다. 하지만 어떻게 해야 할지 막막했습니다. 선배 박시니어 씨가 다가와 물었습니다. "혹시 GitHub 계정은 있어요?" 김개발 씨는 고개를 끄덕였습니다. "네, 회원가입은 했는데 한 번도 사용해본 적은 없어요." **코드 저장소의 필요성** 왜 코드를 GitHub에 올려야 할까요? 쉽게 비유하자면, GitHub는 마치 개발자들의 도서관과 같습니다. 여러분이 작성한 코드라는 책을 이 도서관에 보관하면, 언제 어디서든 접근할 수 있고, 다른 사람들과 공유할 수도 있습니다. 더 중요한 것은, 이 도서관이 책의 모든 개정판을 자동으로 보관해준다는 점입니다. GitHub가 없던 시절에는 어땠을까요? 개발자들은 USB 메모리에 코드를 복사하거나, 이메일로 파일을 주고받았습니다. 프로젝트 폴더 이름에 날짜를 붙여가며 버전을 관리했죠. "최종.zip", "진짜최종.zip", "진짜진짜최종.zip" 같은 파일명을 본 적이 있을 것입니다. 협업할 때는 더 큰 혼란이 일어났습니다. **Git과 GitHub의 차이** 여기서 잠깐, **Git**과 **GitHub**를 구분해야 합니다. Git은 버전 관리 시스템입니다. 여러분의 컴퓨터에 설치되어, 코드의 변경사항을 추적하고 기록합니다. 마치 타임머신처럼 과거의 어느 시점으로든 돌아갈 수 있게 해줍니다. GitHub는 Git으로 관리되는 코드를 온라인에 저장하는 플랫폼입니다. Git이 개인 노트라면, GitHub는 클라우드 노트 서비스인 셈입니다. **리포지토리 생성하기** 박시니어 씨는 김개발 씨의 컴퓨터 앞에 앉아 하나씩 설명해주었습니다. "먼저 GitHub 웹사이트에 접속해서 새 리포지토리를 만들어요. 오른쪽 상단의 플러스 버튼을 누르고 'New repository'를 선택하면 됩니다. 리포지토리 이름은 프로젝트 이름과 같게 하는 게 좋아요." 김개발 씨는 화면을 보며 따라했습니다. 리포지토리 이름에 "my-portfolio"를 입력하고, Public으로 설정했습니다. README 파일은 나중에 추가하기로 했습니다. **로컬 Git 초기화** 이제 컴퓨터의 프로젝트 폴더에서 작업할 차례입니다. 터미널을 열고 프로젝트 폴더로 이동한 후, git init 명령어를 실행합니다. 이 명령어는 현재 폴더를 Git이 관리하는 저장소로 만들어줍니다. 눈에 보이지 않지만, .git이라는 숨김 폴더가 생성되어 모든 버전 정보를 저장하게 됩니다. 다음으로 git add . 명령어를 실행합니다. 점(.)은 현재 폴더의 모든 파일을 의미합니다. 이 명령어는 변경된 파일들을 **스테이징 영역**에 올립니다. 마치 택배를 보내기 전에 박스에 물건을 담는 것과 같습니다. **첫 번째 커밋** git commit 명령어는 스테이징 영역의 파일들을 실제로 저장합니다. -m 옵션 뒤에는 **커밋 메시지**를 작성합니다. "Initial commit: 프로젝트 첫 커밋"처럼 무엇을 했는지 명확하게 작성하는 것이 중요합니다. 나중에 커밋 히스토리를 볼 때 어떤 변경사항이 있었는지 쉽게 파악할 수 있기 때문입니다. **원격 저장소 연결** 이제 로컬 저장소와 GitHub의 원격 저장소를 연결해야 합니다. git remote add origin 명령어는 "origin"이라는 이름으로 원격 저장소를 등록합니다. origin은 관례적으로 사용하는 기본 원격 저장소 이름입니다. URL은 GitHub에서 리포지토리를 만들 때 제공된 주소를 사용합니다. git branch -M main은 기본 브랜치 이름을 main으로 설정합니다. 예전에는 master라는 이름을 썼지만, 최근에는 main을 표준으로 사용합니다. **코드 푸시하기** 드디어 마지막 단계입니다. git push -u origin main을 실행하면 로컬의 코드가 GitHub로 업로드됩니다. -u 옵션은 upstream을 설정하는 것으로, 다음부터는 git push만 입력해도 자동으로 origin의 main 브랜치로 푸시됩니다. 처음에는 GitHub 로그인을 요구할 수 있습니다. 사용자명과 비밀번호(또는 토큰)를 입력하면 됩니다. **지속적인 업데이트** 김개발 씨가 물었습니다. "그럼 코드를 수정할 때마다 이 과정을 다시 해야 하나요?" 박시니어 씨는 고개를 저었습니다. "처음 설정은 한 번만 하면 돼요. 이후에는 세 가지 명령어만 기억하면 됩니다." 코드를 수정한 후에는 git add .로 변경사항을 스테이징하고, git commit -m "메시지"로 커밋한 다음, git push로 GitHub에 올리면 됩니다. 이 세 가지가 일상적인 작업 흐름입니다. **주의할 점** 초보 개발자들이 흔히 하는 실수가 있습니다. 첫째, node_modules 폴더나 .env 파일처럼 GitHub에 올리면 안 되는 파일들을 실수로 푸시하는 경우입니다. 이를 방지하려면 **.gitignore** 파일을 만들어 제외할 파일 목록을 작성해야 합니다. 둘째, 커밋 메시지를 대충 작성하는 것입니다. "수정", "ㅇㅇ" 같은 메시지는 나중에 히스토리를 볼 때 전혀 도움이 되지 않습니다. "feat: 로그인 기능 추가", "fix: 버튼 클릭 버그 수정"처럼 구체적으로 작성하세요. **완료** 김개발 씨는 GitHub 리포지토리 페이지를 새로고침했습니다. 자신이 작성한 코드가 온라인에 올라와 있었습니다. "와, 진짜 올라갔네요!" 이제 코드를 안전하게 보관할 수 있게 되었고, 배포를 위한 준비도 끝났습니다. 다음 단계는 Vercel을 연결하는 것입니다. **실전 팁** 💡 - .gitignore 파일을 프로젝트 시작부터 만들어 민감한 정보가 푸시되지 않도록 하세요 - 커밋 메시지는 "feat:", "fix:", "docs:" 같은 접두사를 사용해 일관성 있게 작성하세요 - 큰 파일(이미지, 동영상)은 Git LFS를 사용하거나 CDN에 별도로 업로드하는 것이 좋습니다 --- ## 2. Vercel_계정_설정 GitHub에 코드를 올린 김개발 씨는 박시니어 씨에게 다시 물었습니다. "코드는 올렸는데, 이걸 어떻게 웹사이트로 만들죠?" 선배는 노트북을 열며 답했습니다. "Vercel이라는 서비스를 사용하면 몇 번의 클릭만으로 배포할 수 있어요." **Vercel**은 프론트엔드 애플리케이션을 자동으로 배포하고 호스팅해주는 플랫폼입니다. 마치 음식 배달 앱처럼, 여러분의 코드를 전 세계 사용자에게 빠르게 전달해줍니다. GitHub와 연동되어 코드를 푸시할 때마다 자동으로 새 버전이 배포되는 것이 가장 큰 장점입니다. 다음 코드를 살펴봅시다. ```javascript // vercel.json 설정 파일 예시 { "buildCommand": "npm run build", "outputDirectory": "dist", "devCommand": "npm run dev", "installCommand": "npm install", "framework": "vite", "regions": ["icn1"], "rewrites": [ { "source": "/(.*)", "destination": "/index.html" } ] } ``` 김개발 씨는 배포라는 단어가 어렵게 느껴졌습니다. 개발은 했지만, 그것을 인터넷에 올리는 과정은 완전히 다른 영역처럼 보였습니다. 박시니어 씨는 친절하게 설명을 시작했습니다. "예전에는 배포하려면 서버를 직접 설정하고, 도메인을 연결하고, SSL 인증서를 설치하는 등 복잡한 과정을 거쳐야 했어요. 하지만 지금은 Vercel 같은 플랫폼이 모든 것을 자동화해줍니다." **Vercel이란 무엇인가** Vercel을 쉽게 비유하자면, 온라인 인쇄소와 같습니다. 여러분이 디자인 파일을 주면, 인쇄소가 알아서 인쇄하고 배송까지 해주는 것처럼, Vercel은 여러분의 코드를 받아서 빌드하고 전 세계 서버에 배포해줍니다. 심지어 파일을 수정하면 자동으로 다시 인쇄해서 보내주는 똑똑한 인쇄소입니다. Vercel은 특히 **Next.js**를 만든 회사이기도 합니다. 따라서 Next.js 프로젝트는 물론이고, React, Vue, Svelte 등 대부분의 프론트엔드 프레임워크를 지원합니다. **왜 Vercel을 선택할까** 전통적인 방식으로 배포하려면 어떤 과정을 거쳐야 할까요? 먼저 AWS나 GCP 같은 클라우드 서비스에서 서버를 빌려야 합니다. 그리고 그 서버에 Node.js를 설치하고, Nginx를 설정하고, 방화벽을 구성하고, SSL 인증서를 발급받아야 합니다. 코드를 수정할 때마다 서버에 접속해서 파일을 업데이트하고 서비스를 재시작해야 하죠. 초보 개발자에게는 너무 어렵고 복잡한 과정입니다. 실수로 서버를 잘못 설정하면 보안 문제가 생길 수도 있습니다. **Vercel의 강력한 기능들** Vercel을 사용하면 이 모든 과정이 자동화됩니다. 첫째, **자동 배포**가 가능합니다. GitHub에 코드를 푸시하면 Vercel이 자동으로 감지하고 빌드를 시작합니다. 몇 분 안에 새 버전이 배포되고, 고유한 URL이 생성됩니다. 둘째, **프리뷰 배포**를 제공합니다. Pull Request를 만들면 본 사이트와는 별도로 미리보기 버전이 자동으로 배포됩니다. 팀원들이 실제로 작동하는 화면을 보면서 리뷰할 수 있어 매우 편리합니다. 셋째, **글로벌 CDN**을 무료로 사용할 수 있습니다. 전 세계 곳곳에 있는 서버에 여러분의 사이트가 복제되어, 사용자가 어디에 있든 빠르게 접속할 수 있습니다. **계정 만들기** 박시니어 씨는 Vercel 웹사이트를 열었습니다. "vercel.com에 접속해서 'Sign Up' 버튼을 누르세요." 가입 방법은 여러 가지가 있지만, **GitHub 계정으로 로그인**하는 것을 강력히 추천합니다. 그래야 GitHub 리포지토리와의 연동이 자동으로 설정되기 때문입니다. "Continue with GitHub" 버튼을 클릭하면 GitHub 인증 페이지로 이동합니다. Vercel이 GitHub 계정에 접근할 수 있도록 권한을 승인해야 합니다. 걱정하지 마세요. Vercel은 읽기 권한만 요청하며, 여러분의 코드를 함부로 수정할 수 없습니다. **팀과 개인 계정** 계정을 만들 때 **개인 계정**과 **팀 계정** 중 선택할 수 있습니다. 개인 프로젝트라면 개인 계정으로 충분합니다. Hobby 플랜은 완전히 무료이며, 대부분의 기능을 제한 없이 사용할 수 있습니다. 상업적인 프로젝트가 아니라면 Hobby 플랜을 선택하세요. 팀 계정은 여러 명이 협업할 때 유용합니다. 팀원을 초대하고, 역할을 부여하고, 공동으로 프로젝트를 관리할 수 있습니다. 하지만 유료이므로, 처음에는 개인 계정으로 시작하는 것이 좋습니다. **대시보드 둘러보기** 로그인하면 Vercel 대시보드가 나타납니다. 왼쪽에는 프로젝트 목록이 표시됩니다. 아직은 비어있을 것입니다. 오른쪽 상단의 "Add New" 버튼을 누르면 새 프로젝트를 추가할 수 있습니다. 대시보드에서는 배포 상태, 분석 데이터, 도메인 설정 등을 확인할 수 있습니다. 처음에는 복잡해 보일 수 있지만, 자주 사용하다 보면 직관적인 인터페이스라는 것을 알게 됩니다. **GitHub 연동 확인** Settings 메뉴로 이동하면 연동된 GitHub 계정을 확인할 수 있습니다. "Git Integration" 탭에서 어떤 리포지토리에 접근할 수 있는지 관리할 수 있습니다. 보안을 위해 필요한 리포지토리만 접근 권한을 주는 것이 좋습니다. 만약 GitHub 연동이 제대로 되지 않았다면, "Configure GitHub App" 버튼을 눌러 다시 설정할 수 있습니다. **무료 플랜의 한계** 김개발 씨가 물었습니다. "무료로 계속 사용할 수 있나요?" 박시니어 씨는 고개를 끄덕였습니다. "네, Hobby 플랜은 영구 무료예요. 하지만 몇 가지 제한이 있습니다." Hobby 플랜에서는 월 100GB의 대역폭과 100시간의 빌드 시간을 제공합니다. 개인 프로젝트나 포트폴리오 사이트에는 충분한 양입니다. 하지만 상업적으로 사용하거나, 팀 기능이 필요하거나, 더 많은 리소스가 필요하면 Pro 플랜으로 업그레이드해야 합니다. **완료** 계정 설정이 완료되었습니다. 이제 실제로 프로젝트를 배포할 준비가 되었습니다. 김개발 씨는 Vercel 대시보드를 보며 설렜습니다. 곧 자신의 프로젝트가 실제 URL을 가지고 인터넷에 공개될 것이기 때문입니다. **실전 팁** 💡 - GitHub 계정으로 가입하면 리포지토리 연동이 자동으로 설정되어 편리합니다 - Hobby 플랜은 개인 프로젝트에 충분하며, 상업적 사용만 아니면 무료로 계속 쓸 수 있습니다 - 여러 프로젝트를 관리한다면 팀 계정을 만들기보다 개인 계정에서 프로젝트별로 분리하는 것이 비용 효율적입니다 --- ## 3. Vercel_배포_설정 드디어 실제 배포를 할 시간입니다. 김개발 씨는 긴장된 마음으로 마우스를 움직였습니다. "지금 클릭하면 진짜 배포되는 건가요?" 박시니어 씨는 여유롭게 답했습니다. "걱정하지 마세요. 잘못되어도 언제든 다시 배포할 수 있어요." **Vercel 배포**는 GitHub 리포지토리를 선택하고 몇 가지 설정만 하면 자동으로 진행됩니다. 마치 자동 세탁기처럼, 빌드 명령어와 출력 디렉토리만 알려주면 Vercel이 알아서 코드를 빌드하고 배포합니다. 한 번 설정하면 이후에는 코드를 푸시할 때마다 자동으로 재배포됩니다. 다음 코드를 살펴봅시다. ```javascript // package.json의 scripts 설정 확인 { "name": "my-portfolio", "version": "1.0.0", "scripts": { "dev": "vite", "build": "vite build", "preview": "vite preview" }, "dependencies": { "react": "^18.2.0", "react-dom": "^18.2.0" } } ``` 김개발 씨는 Vercel 대시보드에서 "Add New Project" 버튼을 눌렀습니다. 화면이 바뀌면서 GitHub 리포지토리 목록이 나타났습니다. 박시니어 씨가 화면을 가리키며 설명했습니다. "여기서 아까 만든 리포지토리를 선택하면 돼요." **리포지토리 선택하기** Import Git Repository 페이지에서 연동된 GitHub 계정의 리포지토리들이 표시됩니다. 만약 리포지토리가 보이지 않는다면 "Adjust GitHub App Permissions" 링크를 클릭해서 권한을 확인해야 합니다. 때로는 특정 Organization의 리포지토리만 접근 권한이 있을 수 있습니다. 김개발 씨는 "my-portfolio" 리포지토리 옆의 "Import" 버튼을 클릭했습니다. 새로운 설정 페이지가 나타났습니다. **프로젝트 설정 이해하기** Configure Project 화면에서는 여러 설정 항목이 있습니다. 첫 번째는 **프로젝트 이름**입니다. 기본적으로 리포지토리 이름이 자동으로 입력됩니다. 이 이름은 Vercel URL의 일부가 되므로, 원한다면 수정할 수 있습니다. 예를 들어 "my-portfolio"라는 이름이면 배포 URL은 "my-portfolio.vercel.app"이 됩니다. 두 번째는 **Framework Preset**입니다. Vercel은 똑똑하게도 리포지토리의 코드를 분석해서 어떤 프레임워크를 사용했는지 자동으로 감지합니다. React, Next.js, Vue, Svelte 등 대부분의 프레임워크를 인식할 수 있습니다. **빌드 설정 구성하기** Build and Output Settings 섹션이 가장 중요합니다. **Build Command**는 프로젝트를 빌드하는 명령어입니다. package.json의 scripts 섹션에 정의된 명령어를 사용합니다. 보통 "npm run build" 또는 "yarn build"입니다. Vercel이 자동으로 감지하지만, 확인하는 것이 좋습니다. **Output Directory**는 빌드 결과물이 생성되는 폴더입니다. Vite를 사용한다면 "dist", Create React App이라면 "build", Next.js라면 ".next" 폴더가 기본값입니다. 이것도 자동으로 설정되지만, 프로젝트 설정에 따라 다를 수 있으니 확인이 필요합니다. **Install Command**는 의존성 패키지를 설치하는 명령어입니다. "npm install", "yarn install", 또는 "pnpm install"이 될 수 있습니다. package-lock.json이 있으면 npm을, yarn.lock이 있으면 yarn을 자동으로 선택합니다. **환경 변수가 필요한 경우** 김개발 씨의 프로젝트는 API 키를 사용하고 있었습니다. 로컬에서는 .env 파일에 저장했는데, 이 파일은 .gitignore에 추가되어 GitHub에는 올라가지 않았습니다. 박시니어 씨가 설명했습니다. "그럴 때는 Environment Variables 섹션에서 환경 변수를 추가하면 돼요." "Add" 버튼을 클릭하고, 변수 이름과 값을 입력합니다. 예를 들어 VITE_API_KEY라는 변수가 필요하다면, Name에 "VITE_API_KEY"를, Value에 실제 API 키를 입력합니다. 여러 개의 환경 변수를 추가할 수 있으며, Production, Preview, Development 환경별로 다른 값을 설정할 수도 있습니다. **Root Directory 설정** 대부분의 경우 프로젝트의 루트 디렉토리가 리포지토리의 최상위 폴더입니다. 하지만 **모노레포**를 사용하거나, 프로젝트가 하위 폴더에 있다면 Root Directory를 지정해야 합니다. 예를 들어 리포지토리 구조가 다음과 같다면: ``` /my-repo /frontend /src package.json /backend ``` Root Directory를 "frontend"로 설정해야 합니다. **배포 시작하기** 모든 설정을 확인한 김개발 씨는 "Deploy" 버튼을 클릭했습니다. 화면이 바뀌면서 빌드 로그가 실시간으로 표시되기 시작했습니다. 마치 터미널에서 명령어를 실행하는 것처럼, 각 단계의 진행 상황을 볼 수 있었습니다. "Cloning repository..." "Installing dependencies..." "Building application..." "Deploying to edge network..." 김개발 씨는 화면을 뚫어지게 바라봤습니다. 몇 분이 지나지 않아, "Congratulations!" 메시지와 함께 배포가 완료되었습니다. **배포 결과 확인하기** 배포가 완료되면 세 가지 URL이 제공됩니다. 첫째, **Production URL**입니다. 이것이 실제 사용자들이 접속할 주소입니다. "https://my-portfolio.vercel.app" 같은 형식입니다. 둘째, **Deployment URL**입니다. 각 배포마다 고유한 URL이 생성됩니다. "https://my-portfolio-abc123.vercel.app" 같은 형식으로, 특정 버전을 공유할 때 유용합니다. 셋째, **Git Branch URL**입니다. 브랜치별로 고유한 URL이 있어, 여러 버전을 동시에 테스트할 수 있습니다. **배포 실패 시 대처법** 모든 배포가 항상 성공하는 것은 아닙니다. 빌드 중에 에러가 발생하면 Vercel은 자세한 로그를 보여줍니다. 어느 단계에서 실패했는지, 어떤 에러 메시지가 나왔는지 확인할 수 있습니다. 대부분의 경우 의존성 패키지 누락, 환경 변수 미설정, 또는 코드 오류가 원인입니다. 로그를 차근차근 읽어보면 해결 방법을 찾을 수 있습니다. 에러를 수정한 후 GitHub에 푸시하면 Vercel이 자동으로 재배포를 시작합니다. **자동 재배포** 가장 놀라운 기능은 **자동 재배포**입니다. 이제부터는 GitHub에 코드를 푸시할 때마다 Vercel이 자동으로 감지하고 새로 배포합니다. 수동으로 배포 버튼을 누를 필요가 없습니다. main 브랜치에 푸시하면 프로덕션 배포가, 다른 브랜치에 푸시하면 프리뷰 배포가 자동으로 생성됩니다. **완료** 김개발 씨는 제공된 URL을 클릭했습니다. 브라우저가 열리면서 자신이 만든 포트폴리오 사이트가 나타났습니다. 인터넷에 연결된 누구나 이 주소로 접속할 수 있습니다. "와, 진짜 배포됐어요!" 김개발 씨는 감격스러워했습니다. 3개월 동안 만든 프로젝트가 드디어 세상에 공개되었습니다. **실전 팁** 💡 - Framework Preset이 자동으로 잘못 감지되었다면 수동으로 변경할 수 있습니다 - 빌드 에러가 발생하면 로컬에서 npm run build를 실행해 먼저 테스트하세요 - 환경 변수는 절대 GitHub에 올리지 말고 Vercel 대시보드에서만 설정하세요 --- ## 4. 환경_변수_및_빌드_최적화 배포는 성공했지만, 김개발 씨는 한 가지 문제를 발견했습니다. 사이트가 생각보다 느리게 로딩되었고, 일부 기능이 제대로 작동하지 않았습니다. 박시니어 씨는 모니터를 보며 말했습니다. "환경 변수 설정과 빌드 최적화가 필요하겠네요." **환경 변수**는 코드에 하드코딩하지 않고 외부에서 주입하는 설정값입니다. API 키, 데이터베이스 URL 같은 민감한 정보를 안전하게 관리할 수 있습니다. **빌드 최적화**는 번들 크기를 줄이고 로딩 속도를 개선하는 작업으로, 사용자 경험을 크게 향상시킵니다. 다음 코드를 살펴봅시다. ```javascript // .env.local (로컬 개발용) VITE_API_KEY=your_api_key_here VITE_API_URL=https://api.example.com VITE_ENVIRONMENT=development // vite.config.js (빌드 최적화 설정) import { defineConfig } from 'vite' import react from '@vitejs/plugin-react' export default defineConfig({ plugins: [react()], build: { rollupOptions: { output: { manualChunks: { vendor: ['react', 'react-dom'] } } }, chunkSizeWarningLimit: 1000 } }) ``` 김개발 씨의 포트폴리오는 GitHub API를 사용해서 레포지토리 목록을 보여주는 기능이 있었습니다. 그런데 배포된 사이트에서는 이 기능이 작동하지 않았습니다. 박시니어 씨가 개발자 도구를 열어 콘솔을 확인했습니다. "API key is undefined"라는 에러 메시지가 보였습니다. **환경 변수란 무엇인가** 환경 변수를 쉽게 비유하자면, 건물의 비밀번호와 같습니다. 집마다 현관문 비밀번호가 다르듯이, 개발 환경과 프로덕션 환경에서 사용하는 설정값이 다를 수 있습니다. 이런 값들을 코드에 직접 쓰면 보안 문제가 생기고, 환경을 바꿀 때마다 코드를 수정해야 합니다. 환경 변수를 사용하면 코드는 그대로 두고, 환경에 따라 다른 값을 주입할 수 있습니다. **환경 변수가 필요한 이유** 환경 변수 없이 개발하던 시절에는 어떤 문제가 있었을까요? 개발자들은 API 키를 코드에 직접 작성했습니다. 그러다 실수로 GitHub에 올리면, 누구나 그 키를 볼 수 있었습니다. 악의적인 사람이 키를 훔쳐서 무단으로 사용할 수 있었죠. 또한 개발 서버와 프로덕션 서버의 설정이 달라야 하는데, 배포할 때마다 코드를 수정해야 했습니다. 실수로 개발용 API URL을 프로덕션에 배포하는 일도 잦았습니다. **Vercel에서 환경 변수 설정하기** 박시니어 씨는 Vercel 대시보드로 돌아갔습니다. 프로젝트 페이지에서 "Settings" 탭을 클릭하고, 왼쪽 메뉴에서 "Environment Variables"를 선택했습니다. 여기서 환경 변수를 추가, 수정, 삭제할 수 있습니다. "Add" 버튼을 클릭하면 세 개의 입력 필드가 나타납니다. **Name**에는 변수 이름을, **Value**에는 실제 값을 입력합니다. **Environment**에서는 이 변수를 어느 환경에서 사용할지 선택합니다. Production, Preview, Development 세 가지 환경을 선택할 수 있습니다. Production은 실제 배포 환경, Preview는 Pull Request의 미리보기, Development는 로컬 개발 환경입니다. **환경 변수 명명 규칙** Vite를 사용하는 경우, 클라이언트에서 접근할 수 있는 환경 변수는 반드시 **VITE_** 접두사로 시작해야 합니다. Next.js는 **NEXT_PUBLIC_** 접두사를 사용합니다. Create React App은 **REACT_APP_**을 사용하죠. 이것은 보안을 위한 설계입니다. 접두사가 없는 환경 변수는 서버 사이드에서만 접근할 수 있어, 민감한 정보가 클라이언트에 노출되는 것을 방지합니다. **환경별로 다른 값 사용하기** 김개발 씨는 개발 환경에서는 테스트 API를, 프로덕션에서는 실제 API를 사용하고 싶었습니다. 같은 이름의 환경 변수를 추가하되, Environment 설정을 다르게 하면 됩니다. VITE_API_URL을 두 번 추가하는데, 하나는 Development로 설정하고 값은 "http://localhost:3000", 다른 하나는 Production으로 설정하고 값은 "https://api.production.com"으로 입력합니다. 이렇게 하면 로컬에서 개발할 때는 로컬 서버를, 배포된 사이트에서는 실제 API 서버를 자동으로 사용합니다. **민감한 정보 관리** API 키, 데이터베이스 비밀번호, OAuth 시크릿 같은 민감한 정보는 절대 코드에 포함시키면 안 됩니다. 심지어 Private 리포지토리라고 해도 마찬가지입니다. 나중에 리포지토리를 Public으로 전환하거나, 팀원이 실수로 공유할 수 있기 때문입니다. 모든 민감한 정보는 환경 변수로 관리하고, .env 파일은 .gitignore에 추가해야 합니다. **빌드 최적화의 중요성** 환경 변수 설정을 마친 후, 박시니어 씨는 사이트의 로딩 속도를 분석했습니다. Chrome DevTools의 Network 탭을 열어보니, JavaScript 번들 파일이 3MB나 되었습니다. 이것은 너무 큽니다. 사용자가 사이트에 처음 접속할 때 3MB를 다운로드해야 하면, 특히 모바일 네트워크에서는 매우 느리게 느껴집니다. **Code Splitting 적용하기** **Code Splitting**은 큰 번들을 작은 조각으로 나누는 기술입니다. 마치 책을 챕터별로 나눠서 필요한 부분만 읽는 것과 같습니다. 사용자가 처음 접속할 때는 첫 페이지에 필요한 코드만 로드하고, 다른 페이지로 이동할 때 해당 페이지의 코드를 추가로 로드하는 방식입니다. React에서는 React.lazy()와 Suspense를 사용해서 컴포넌트 단위로 코드를 분할할 수 있습니다. Vite와 같은 번들러는 dynamic import를 자동으로 감지해서 별도의 chunk 파일로 분리해줍니다. **의존성 최적화** 김개발 씨는 lodash 라이브러리를 사용하고 있었는데, 실제로는 몇 가지 함수만 필요했습니다. 하지만 전체 라이브러리를 import하고 있어 불필요하게 번들 크기가 커졌습니다. 박시니어 씨가 조언했습니다. "lodash 대신 lodash-es를 사용하고, 필요한 함수만 import하세요." ```javascript // 나쁜 예 import _ from 'lodash' _.debounce(func, 300) // 좋은 예 import { debounce } from 'lodash-es' debounce(func, 300) ``` 이렇게 하면 Tree Shaking이 작동해서 사용하지 않는 코드는 번들에 포함되지 않습니다. **이미지 최적화** 사이트가 느린 또 다른 이유는 최적화되지 않은 이미지였습니다. 고해상도 PNG 파일을 그대로 사용하고 있어, 한 이미지가 2MB나 되었습니다. 박시니어 씨는 이미지를 WebP 형식으로 변환하고 적절한 크기로 리사이즈하도록 권했습니다. Vercel은 Image Optimization 기능을 제공합니다. Next.js의 Image 컴포넌트를 사용하면 자동으로 이미지를 최적화하고, 디바이스에 맞는 크기로 제공합니다. **빌드 분석하기** 변경사항을 적용한 후, 번들 크기가 어떻게 바뀌었는지 확인해야 합니다. rollup-plugin-visualizer 같은 도구를 사용하면 번들의 구성을 시각적으로 볼 수 있습니다. 어떤 라이브러리가 얼마나 큰 공간을 차지하는지 한눈에 파악할 수 있어, 최적화 포인트를 찾기 쉽습니다. **재배포 및 확인** 최적화를 마친 김개발 씨는 변경사항을 GitHub에 푸시했습니다. Vercel이 자동으로 재배포를 시작했고, 몇 분 후 새 버전이 배포되었습니다. 이번에는 JavaScript 번들이 800KB로 줄었고, 페이지 로딩 시간도 크게 개선되었습니다. Lighthouse 점수도 50점대에서 90점대로 상승했습니다. **완료** 박시니어 씨는 만족스럽게 고개를 끄덕였습니다. "훨씬 나아졌네요. 환경 변수와 빌드 최적화는 배포의 필수 요소예요. 처음부터 신경 쓰면 나중에 고생하지 않아요." 김개발 씨는 이제 환경 변수의 중요성과 성능 최적화의 기초를 이해하게 되었습니다. **실전 팁** 💡 - 환경 변수를 추가하거나 수정한 후에는 반드시 재배포해야 적용됩니다 - .env 파일은 절대 Git에 커밋하지 말고, .env.example 파일로 변수 목록만 공유하세요 - 번들 크기는 500KB 이하로 유지하는 것을 목표로 하세요 --- ## 5. 커스텀_도메인_연결 배포된 사이트를 친구에게 공유한 김개발 씨는 조금 아쉬웠습니다. "my-portfolio.vercel.app"이라는 URL이 전문적이지 않다고 느꼈기 때문입니다. 박시니어 씨가 물었습니다. "도메인을 사고 싶어요?" 김개발 씨는 고개를 끄덕였습니다. **커스텀 도메인**은 여러분만의 고유한 웹 주소를 의미합니다. vercel.app 대신 myportfolio.com 같은 주소를 사용할 수 있어 더욱 전문적으로 보입니다. Vercel은 도메인 연결을 매우 쉽게 만들어주며, SSL 인증서까지 자동으로 설정해줍니다. 다음 코드를 살펴봅시다. ```javascript // vercel.json에 도메인 리다이렉트 설정 { "redirects": [ { "source": "/:path*", "has": [ { "type": "host", "value": "www.myportfolio.com" } ], "destination": "https://myportfolio.com/:path*", "permanent": true } ], "headers": [ { "source": "/(.*)", "headers": [ { "key": "X-Content-Type-Options", "value": "nosniff" } ] } ] } ``` 김개발 씨는 도메인 구입이 복잡하고 비쌀 것이라고 생각했습니다. 하지만 박시니어 씨는 생각보다 간단하다고 설명했습니다. "도메인은 연간 1만 원에서 2만 원 정도면 구입할 수 있어요. Namecheap, GoDaddy, 또는 국내 업체인 가비아 같은 곳에서 쉽게 살 수 있습니다." **도메인이란 무엇인가** 도메인을 쉽게 비유하자면, 집 주소와 같습니다. IP 주소는 192.168.0.1 같은 숫자 조합인데, 사람이 기억하기 어렵습니다. 도메인은 이것을 myportfolio.com처럼 기억하기 쉬운 이름으로 바꿔줍니다. 마치 "서울시 강남구 테헤란로 123"이라는 주소가 GPS 좌표보다 기억하기 쉬운 것과 같습니다. 도메인은 크게 **TLD(Top Level Domain)**와 **SLD(Second Level Domain)**로 나뉩니다. myportfolio.com에서 .com이 TLD이고, myportfolio가 SLD입니다. **도메인 구입하기** 박시니어 씨는 Namecheap 웹사이트를 열었습니다. "먼저 원하는 도메인 이름을 검색해보세요. 이미 다른 사람이 사용 중이라면 구입할 수 없어요." 김개발 씨는 "kimdevportfolio"를 검색했습니다. 다행히 kimdevportfolio.com은 사용 가능했고, 가격은 연간 13달러였습니다. .com 도메인이 가장 일반적이지만, .dev, .io, .me 같은 TLD도 인기가 있습니다. 개발자 포트폴리오라면 .dev도 좋은 선택입니다. 다만 .dev는 조금 더 비쌀 수 있습니다. 도메인을 장바구니에 담고 결제를 진행합니다. 개인 정보 보호 기능(WHOIS Privacy)을 추가하는 것을 권장합니다. 이것이 없으면 도메인 소유자의 이메일과 전화번호가 공개될 수 있습니다. **DNS 설정 이해하기** 도메인을 구입했다고 바로 사용할 수 있는 것은 아닙니다. **DNS(Domain Name System)** 설정이 필요합니다. DNS는 마치 전화번호부와 같습니다. 도메인 이름을 입력하면 어느 서버로 연결해야 하는지 알려주는 시스템입니다. 우리는 Vercel 서버로 연결되도록 설정해야 합니다. Namecheap 대시보드에서 구입한 도메인을 클릭하고, "Advanced DNS" 탭으로 이동합니다. 여기서 DNS 레코드를 추가하거나 수정할 수 있습니다. **Vercel에 도메인 추가하기** 먼저 Vercel 측에서 도메인을 추가해야 합니다. Vercel 프로젝트 대시보드에서 "Settings" 탭의 "Domains" 섹션으로 이동합니다. 입력 필드에 구입한 도메인(kimdevportfolio.com)을 입력하고 "Add" 버튼을 클릭합니다. Vercel은 도메인 소유권을 확인하기 위해 DNS 레코드 설정을 요구합니다. 화면에 어떤 레코드를 추가해야 하는지 친절하게 안내해줍니다. **A 레코드와 CNAME 레코드** DNS 레코드에는 여러 종류가 있지만, 우리가 알아야 할 것은 **A 레코드**와 **CNAME 레코드**입니다. A 레코드는 도메인을 특정 IP 주소로 연결합니다. Vercel은 76.76.21.21 같은 IP 주소를 제공합니다. Type을 "A Record"로 선택하고, Host는 "@"(루트 도메인을 의미), Value는 Vercel이 제공한 IP 주소를 입력합니다. CNAME 레코드는 도메인을 다른 도메인으로 연결합니다. www 서브도메인을 설정할 때 사용합니다. Type을 "CNAME Record"로 선택하고, Host는 "www", Value는 "cname.vercel-dns.com"을 입력합니다. **DNS 전파 대기** DNS 레코드를 저장했다고 바로 적용되는 것은 아닙니다. DNS 변경사항이 전 세계 DNS 서버에 전파되려면 시간이 걸립니다. 보통 몇 분에서 48시간까지 걸릴 수 있습니다. 대부분은 10~20분 이내에 완료되지만, 간혹 더 오래 걸리는 경우도 있습니다. 김개발 씨는 조바심이 났지만, 박시니어 씨는 여유롭게 말했습니다. "커피 한 잔 마시고 오면 대부분 완료되어 있을 거예요." DNS 전파 상태는 dnschecker.org 같은 웹사이트에서 확인할 수 있습니다. 도메인을 입력하면 전 세계 여러 지역에서 어떻게 해석되는지 보여줍니다. **SSL 인증서 자동 발급** Vercel의 놀라운 점은 **SSL 인증서**를 자동으로 발급해준다는 것입니다. SSL은 웹사이트와 사용자 간의 통신을 암호화하는 기술입니다. 브라우저 주소창에 자물쇠 아이콘이 표시되는 것을 본 적이 있을 것입니다. 이것이 SSL이 적용된 사이트라는 표시입니다. 예전에는 SSL 인증서를 직접 구입하고 설치해야 했습니다. 비용도 들고 설정도 복잡했죠. 하지만 Vercel은 Let's Encrypt를 사용해 무료로 자동 발급해줍니다. 도메인이 연결되면 몇 분 내에 HTTPS가 활성화됩니다. **www와 non-www 리다이렉트** kimdevportfolio.com과 www.kimdevportfolio.com은 기술적으로 다른 주소입니다. 대부분의 웹사이트는 둘 중 하나를 기본으로 정하고, 나머지는 리다이렉트합니다. 예를 들어 www.google.com을 입력하면 google.com으로 리다이렉트되는 것을 볼 수 있습니다. Vercel은 이것도 자동으로 처리해줍니다. Domains 설정에서 어느 것을 기본으로 할지 선택할 수 있습니다. "Redirect www to apex domain"을 선택하면 www가 붙은 주소는 자동으로 루트 도메인으로 리다이렉트됩니다. **도메인 연결 확인** DNS 전파가 완료되면 Vercel 대시보드에서 도메인 상태가 "Valid Configuration"으로 바뀝니다. 김개발 씨는 브라우저에 kimdevportfolio.com을 입력했습니다. 자신의 포트폴리오 사이트가 새 주소로 정상적으로 표시되었습니다. 주소창에는 자물쇠 아이콘도 보였습니다. "와, 진짜 제 도메인으로 접속되네요!" 김개발 씨는 감탄했습니다. 이제 명함이나 이력서에 당당히 자신의 도메인을 적을 수 있게 되었습니다. **여러 도메인 연결하기** 필요하다면 여러 개의 도메인을 같은 프로젝트에 연결할 수도 있습니다. 예를 들어 kimdevportfolio.com과 kimdevportfolio.dev를 모두 구입해서 같은 사이트로 연결할 수 있습니다. Vercel은 제한 없이 여러 도메인을 추가할 수 있으며, 어느 것을 기본 도메인으로 할지 선택할 수 있습니다. **완료** 박시니어 씨는 마지막으로 조언했습니다. "도메인 갱신일을 잊지 마세요. 보통 1년 단위로 결제되는데, 갱신을 깜빡하면 도메인이 만료되어 다른 사람이 구입할 수 있어요." 김개발 씨는 달력에 갱신일을 표시해두었습니다. 이제 자신만의 고유한 웹 주소를 가지게 되었습니다. **실전 팁** 💡 - 도메인은 짧고 기억하기 쉬운 것이 좋으며, 철자가 복잡하면 사람들이 잘못 입력할 수 있습니다 - WHOIS Privacy 보호 기능을 반드시 활성화해서 개인 정보를 보호하세요 - DNS 변경 후 24~48시간은 완전히 전파되는 데 걸리므로 인내심을 가지세요 --- ## 6. 배포_후_디버깅_및_모니터링 사이트를 배포한 지 며칠 후, 김개발 씨는 사용자로부터 에러 제보를 받았습니다. "특정 페이지가 로딩되지 않아요." 하지만 자신의 컴퓨터에서는 정상적으로 작동했습니다. 박시니어 씨가 말했습니다. "배포 후 모니터링이 중요한 이유가 바로 이거예요." **배포 후 디버깅**은 프로덕션 환경에서 발생하는 문제를 찾아 해결하는 과정입니다. 로컬에서는 보이지 않던 버그가 실제 사용자 환경에서 나타날 수 있습니다. **모니터링**은 사이트의 성능과 에러를 지속적으로 관찰해서, 문제가 커지기 전에 발견하는 작업입니다. 다음 코드를 살펴봅시다. ```javascript // Vercel Analytics 설정 (Next.js) // pages/_app.js import { Analytics } from '@vercel/analytics/react' function MyApp({ Component, pageProps }) { return ( ) } export default MyApp // 에러 추적을 위한 try-catch async function fetchUserData() { try { const response = await fetch('/api/user') if (!response.ok) { throw new Error(`HTTP error! status: ${response.status}`) } return await response.json() } catch (error) { console.error('Failed to fetch user data:', error) // 에러 리포팅 서비스로 전송 } } ``` 김개발 씨는 당황했습니다. 자신의 브라우저에서는 모든 것이 완벽하게 작동하는데, 왜 다른 사용자는 에러를 경험하는 걸까요? 박시니어 씨는 차분하게 설명했습니다. "로컬 환경과 프로덕션 환경은 다릅니다. 브라우저 종류, 네트워크 상태, 디바이스 성능 등 수많은 변수가 있어요." **로컬과 프로덕션의 차이** 개발할 때는 최신 Chrome 브라우저를 사용하고, 빠른 인터넷에 연결되어 있으며, 강력한 컴퓨터를 사용합니다. 하지만 실제 사용자는 오래된 Safari 브라우저를 쓸 수도 있고, 느린 모바일 네트워크를 사용할 수도 있으며, 저사양 스마트폰을 쓸 수도 있습니다. 이런 환경 차이 때문에 예상치 못한 문제가 발생할 수 있습니다. 또한 개발 모드에서는 자세한 에러 메시지가 표시되지만, 프로덕션 빌드에서는 보안을 위해 간략한 메시지만 표시됩니다. 따라서 문제를 진단하기가 더 어렵습니다. **Vercel 로그 확인하기** 박시니어 씨는 Vercel 대시보드의 "Deployments" 탭을 열었습니다. 최근 배포 목록이 표시되고, 각 배포를 클릭하면 상세 정보를 볼 수 있습니다. "Functions" 탭에서는 서버리스 함수의 실행 로그를, "Build Logs"에서는 빌드 과정의 로그를 확인할 수 있습니다. 김개발 씨의 경우, 특정 API 엔드포인트에서 500 에러가 발생하고 있었습니다. 로그를 보니 환경 변수가 제대로 설정되지 않아 데이터베이스 연결에 실패한 것이었습니다. **실시간 로그 모니터링** Vercel CLI를 설치하면 터미널에서 실시간으로 로그를 볼 수 있습니다. ```bash npm i -g vercel vercel login vercel logs ``` 이 명령어를 실행하면 프로덕션 환경의 로그가 실시간으로 스트리밍됩니다. 마치 로컬에서 개발하는 것처럼 즉각적인 피드백을 받을 수 있어, 문제를 빠르게 파악할 수 있습니다. **에러 추적 서비스 연동** Vercel 로그만으로는 부족할 때가 있습니다. 특히 클라이언트 사이드에서 발생하는 JavaScript 에러는 Vercel 로그에 나타나지 않습니다. 이때 **Sentry** 같은 에러 추적 서비스가 유용합니다. Sentry를 연동하면 사용자 브라우저에서 발생하는 모든 에러가 자동으로 수집되고, 어떤 환경에서 에러가 발생했는지 상세한 정보를 제공합니다. Sentry는 무료 플랜도 제공하며, Vercel과의 통합이 매우 쉽습니다. Vercel Marketplace에서 "Add Integration" 버튼 하나로 설치할 수 있습니다. **성능 모니터링** 에러만 추적하는 것으로는 충분하지 않습니다. 사이트의 성능도 지속적으로 모니터링해야 합니다. **Vercel Analytics**는 페이지 로딩 속도, Core Web Vitals, 지역별 성능 등을 측정해줍니다. 어느 페이지가 느린지, 어느 지역에서 문제가 있는지 한눈에 파악할 수 있습니다. Analytics는 Vercel 프로젝트에 쉽게 추가할 수 있습니다. Next.js라면 컴포넌트 하나만 추가하면 되고, 다른 프레임워크도 간단한 스크립트 태그만 삽입하면 됩니다. **Core Web Vitals 이해하기** Google은 **Core Web Vitals**라는 세 가지 핵심 성능 지표를 정의했습니다. **LCP(Largest Contentful Paint)**는 가장 큰 콘텐츠가 화면에 표시되는 시간입니다. 2.5초 이내가 좋습니다. **FID(First Input Delay)**는 사용자가 처음 상호작용할 때의 반응 속도입니다. 100ms 이내가 좋습니다. **CLS(Cumulative Layout Shift)**는 레이아웃이 얼마나 불안정하게 변하는지 측정합니다. 0.1 이하가 좋습니다. 이 지표들은 SEO에도 영향을 미치므로, 개선하면 검색 순위도 올라갈 수 있습니다. **A/B 테스트와 프리뷰 배포** 새로운 기능을 배포하기 전에 테스트하고 싶을 때가 있습니다. Vercel의 **프리뷰 배포**를 활용하면 본 사이트에 영향을 주지 않고 테스트할 수 있습니다. 새 브랜치를 만들어 푸시하면 자동으로 프리뷰 URL이 생성됩니다. 팀원들이나 일부 사용자에게만 이 URL을 공유해서 피드백을 받을 수 있습니다. 문제가 없다고 판단되면 main 브랜치에 merge하여 프로덕션 배포를 진행합니다. **롤백 기능** 최악의 경우, 배포 후 치명적인 버그를 발견할 수 있습니다. Vercel은 **즉시 롤백** 기능을 제공합니다. Deployments 탭에서 이전 버전을 선택하고 "Promote to Production" 버튼을 클릭하면, 몇 초 만에 이전 버전으로 되돌릴 수 있습니다. 롤백은 Git 히스토리를 변경하지 않으므로, 문제를 수정한 후 다시 배포하면 됩니다. 이것은 매우 강력한 안전장치입니다. **정기적인 건강 체크** 박시니어 씨는 매주 월요일 아침마다 사이트 상태를 확인한다고 했습니다. Vercel Analytics를 열어 지난주의 성능 지표를 리뷰하고, 에러 로그를 확인하며, 사용자 피드백을 점검합니다. 작은 문제들도 누적되면 큰 문제가 되므로, 정기적인 모니터링이 중요합니다. UptimeRobot 같은 서비스를 사용하면 사이트가 다운되었을 때 즉시 알림을 받을 수도 있습니다. 무료 플랜으로도 5분마다 사이트를 체크할 수 있습니다. **사용자 피드백 수집** 기술적인 모니터링 외에도 실제 사용자의 의견을 듣는 것이 중요합니다. 간단한 피드백 폼을 사이트에 추가하거나, Google Analytics로 사용자 행동을 분석할 수 있습니다. 어떤 페이지에서 사용자들이 많이 이탈하는지, 어떤 기능을 가장 많이 사용하는지 알 수 있습니다. 데이터 기반으로 의사결정을 내리면, 추측이 아닌 확실한 근거로 개선할 수 있습니다. **완료** 김개발 씨는 에러를 수정하고 재배포했습니다. 이번에는 Sentry를 연동하고 Analytics도 활성화했습니다. 이제 문제가 발생하면 즉시 알 수 있을 것입니다. 박시니어 씨는 마지막으로 말했습니다. "배포는 끝이 아니라 시작이에요. 지속적으로 관찰하고, 개선하고, 사용자의 피드백을 듣는 것이 진짜 개발자의 일입니다." 김개발 씨는 이제 배포의 전체 과정을 이해하게 되었습니다. GitHub에서 코드를 관리하고, Vercel로 배포하고, 커스텀 도메인을 연결하고, 성능을 모니터링하는 모든 과정을 경험했습니다. **실전 팁** 💡 - 에러가 발생하면 로컬에서 프로덕션 빌드를 먼저 테스트해보세요 (npm run build && npm run preview) - Sentry 같은 에러 추적 도구는 무료 플랜도 충분히 유용하니 반드시 설치하세요 - Vercel Analytics의 Core Web Vitals를 주기적으로 확인하여 성능 저하를 조기에 발견하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: Three.js,Blender,3D웹개발

언어: JavaScript

태그: Vercel, GitHub, Deployment, CI/CD, DevOps, Three.js,Blender,3D웹개발

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

GitHub와 Vercel로 시작하는 배포 완벽 가이드

목차

1. GitHub 리포지토리 생성 및 푸시

2. Vercel 계정 설정

3. Vercel 배포 설정

4. 환경 변수 및 빌드 최적화

5. 커스텀 도메인 연결

6. 배포 후 디버깅 및 모니터링

댓글 (0)

함께 보면 좋은 카드 뉴스

3D 포트폴리오 웹사이트 개발 완벽 가이드

Three.js 고급 코드 분석 완벽 가이드

Three.js 충돌 감지 완벽 가이드

Three.js Raycaster 상호작용 구현 완벽 가이드

GSAP 애니메이션 라이브러리 완벽 가이드