GitHub Pages부터 Vercel까지 개발자 포트폴리오 배포 순서

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

배포 도구를 고르기 전에 포트폴리오의 역할부터 정합니다

보여줄 작품과 실행할 기능은 다른 문제입니다

개발자 포트폴리오를 완성했는데도 배포 단계에서 멈추는 이유는 기술이 부족해서가 아닙니다. 정적 페이지, 서버 기능, 데이터베이스, 방문자 분석을 한꺼번에 고려하다 보니 어떤 호스팅 서비스가 적합한지 판단하기 어려워지는 것입니다. 먼저 방문자가 무엇을 보고 무엇을 직접 실행해야 하는지를 한 문장으로 정의하면 선택지가 빠르게 줄어듭니다.

HTML·CSS·JavaScript로 만든 소개 페이지와 프로젝트 문서가 중심이라면 정적 호스팅으로 충분합니다. 반면 문의 폼, 인증, API 호출, 서버 렌더링이 포함된 소프트웨어 프로젝트라면 함수 실행과 환경 변수 관리가 가능한 서비스가 편합니다. 포트폴리오라는 용어의 범위가 궁금하다면 지식백과의 Portfolio 정의도 참고할 만합니다. 단순한 작품 모음이 아니라 역량과 작업 과정을 증명하는 구성물이라는 관점이 배포 방식에도 영향을 줍니다.

서비스를 비교하기 전에 현재 저장소를 열어 아래 항목을 표시해 보세요. 이 짧은 점검만으로도 GitHub Pages처럼 단순한 도구가 필요한지, Vercel이나 Netlify처럼 빌드와 서버 기능을 지원하는 플랫폼이 필요한지 드러납니다.

• 정적 자산: HTML, CSS, 이미지, PDF, 빌드된 JavaScript만 제공하는지 확인합니다.
• 프레임워크: React, Vue, Astro, Next.js 등 별도의 빌드 명령이 필요한지 적습니다.
• 동적 기능: 문의 폼, 인증, 서버리스 함수, 데이터베이스 연결 여부를 구분합니다.
• 운영 목적: 개인 채용용인지, 프리랜서 영업이나 유료 서비스 홍보에도 쓰는지 결정합니다.

선택 기준은 기능의 개수가 아니라 증명할 경험입니다. 백엔드 역량을 보여줄 필요가 없다면 서버 기능을 억지로 추가하는 것보다 빠르고 안정적인 정적 배포가 더 설득력 있습니다.

네 가지 배포 서비스를 비용과 작업 흐름으로 비교합니다

무료라는 표현보다 제한 조건을 읽어야 합니다

개인 개발자 포트폴리오에 자주 쓰이는 후보는 GitHub Pages, Cloudflare Pages, Netlify, Vercel입니다. 네 서비스 모두 작은 프로젝트를 무료로 시작할 수 있지만 지원하는 빌드 방식과 상업적 이용 조건, 서버 기능, 미리보기 배포 경험은 서로 다릅니다. 아래 표의 비용은 개인용 무료 플랜을 출발점으로 삼은 상대적인 범위이며, 요금과 한도는 변경될 수 있으므로 실제 공개 직전에는 각 서비스의 공식 요금표를 다시 확인해야 합니다.

2026년 9월 시점의 공개 문서를 기준으로 Cloudflare Pages 무료 플랜은 월간 빌드 횟수와 파일 수 같은 한도를 두고 있으며, Vercel Hobby도 프로젝트·배포·함수·전송량 등에 포함 사용량을 적용합니다. 숫자 하나만 보고 서비스를 고르면 안 되는 이유입니다. 예를 들어 업데이트가 월 두 번인 정적 포트폴리오는 빌드 한도를 거의 의식하지 않지만, 콘텐츠를 자주 자동 생성하거나 브랜치마다 프리뷰를 만드는 저장소는 같은 무료 플랜을 전혀 다르게 체감합니다.

취업용 개인 사이트라면 무료 범위에서 시작하고, 방문량보다 배포 실패율과 유지관리 시간을 비교하는 편이 합리적입니다. 반대로 고객 문의를 받고 유료 개발 서비스를 홍보한다면 상업적 이용 조건과 초과 과금 정책을 우선 확인하세요. 월 비용이 0원인 것보다 예측할 수 있는 운영비가 더 안전할 때도 있습니다.

• 순수 정적 사이트이며 Git 사용 기록을 강조한다면 GitHub Pages가 간결합니다.
• 세계 여러 지역의 접속 속도와 정적 자산 전송을 중시한다면 Cloudflare Pages가 유리합니다.
• 백엔드를 따로 만들지 않고 문의 접수 흐름을 구성하려면 Netlify를 검토합니다.
• Next.js 프로젝트의 프리뷰와 배포 경험을 보여주려면 Vercel이 자연스럽습니다.

저장소를 연결하고 첫 공개 주소까지 차례로 진행합니다

빌드 명령과 출력 폴더를 먼저 고정합니다

서비스를 정했다면 배포 버튼부터 누르기보다 로컬 빌드를 재현하는 것이 먼저입니다. 새 환경에서 의존성을 설치한 뒤 동일한 명령으로 결과물이 만들어져야 호스팅 플랫폼에서도 안정적으로 배포됩니다. JavaScript 프로젝트라면 패키지 매니저, 런타임 버전, 빌드 명령, 출력 디렉터리를 README와 설정 파일에 명시하세요.

1. 저장소에서 불필요한 비밀 키와 대용량 원본 파일을 제거하고 공개 범위를 확인합니다.
2. Node.js 버전과 패키지 매니저를 고정한 뒤 깨끗한 환경에서 의존성을 다시 설치합니다.
3. npm run build 등 실제 빌드 명령을 실행하고 dist, build, out 중 어느 폴더가 생성되는지 확인합니다.
4. 선택한 서비스에 Git 저장소를 연결하고 프레임워크 프리셋, 빌드 명령, 출력 폴더를 입력합니다.
5. 첫 배포 URL에서 새로고침, 하위 경로 이동, 모바일 화면, 외부 링크를 직접 검사합니다.

GitHub Pages에서 단일 페이지 애플리케이션을 공개하면 하위 경로를 새로고침할 때 404가 발생할 수 있습니다. 저장소 이름이 URL 경로에 포함되는 방식이라면 자산의 기본 경로도 맞춰야 합니다. Vercel과 Netlify는 프레임워크 설정을 자동 감지하는 경우가 많지만, 자동 감지가 항상 프로젝트 의도와 일치하는 것은 아닙니다. 설정 화면에 표시된 명령과 실제 package.json을 한 줄씩 대조해 보세요.

환경 변수는 공개 코드와 완전히 분리합니다

API 키가 필요한 프로젝트라면 저장소에 값을 넣지 말고 플랫폼의 환경 변수 설정을 사용해야 합니다. 특히 브라우저 번들에 포함되는 변수는 이름만 숨긴다고 비밀이 되지 않습니다. 클라이언트에서 호출해야 하는 공개 식별자와 서버에서만 읽어야 하는 비밀 키를 구분하고, 비밀 키는 서버리스 함수나 별도 API 계층에서 사용합니다.

• Production: 실제 도메인에서 사용할 값만 등록합니다.
• Preview: 테스트 데이터와 제한된 권한의 키를 사용합니다.
• Local: 예시 파일에는 변수 이름만 남기고 실제 값은 버전 관리에서 제외합니다.
• 검증: 배포 후 브라우저 개발자 도구의 소스와 네트워크 응답에 비밀 값이 노출되지 않았는지 확인합니다.

첫 배포의 목표는 화려한 주소가 아니라 누구나 같은 커밋을 다시 배포할 수 있는 상태입니다. 수동으로만 복구할 수 있는 설정은 포트폴리오의 신뢰도를 떨어뜨립니다.

사용자 정의 도메인과 품질 신호를 이어 붙입니다

DNS 변경은 이전 주소를 보존한 채 진행합니다

기본 배포 주소에서 모든 경로가 정상 작동하면 andrey-vasiliev.com 같은 사용자 정의 도메인을 연결할 차례입니다. 도메인 구매 비용은 최상위 도메인과 등록 업체에 따라 달라지며, 일반적인 개인 포트폴리오는 연 단위 갱신 비용을 예상하면 됩니다. 저렴한 첫해 가격만 보지 말고 갱신 가격, 개인정보 보호 옵션, DNS 관리 편의성을 함께 비교하세요.

DNS 레코드를 수정하기 전에 기존 사이트의 레코드와 이메일용 MX 레코드를 저장해 두는 것이 안전합니다. 호스팅 서비스가 안내하는 A, AAAA 또는 CNAME 값을 정확히 입력하고, 루트 도메인과 www 중 어느 주소를 대표 주소로 쓸지도 결정합니다. 인증서가 발급되기 전까지 기존 배포 주소를 삭제하지 않으면 전환 과정에서 확인할 통로가 남습니다.

• 대표 주소 하나를 정하고 다른 주소는 301 리디렉션으로 통일합니다.
• HTTPS 인증서가 활성화된 뒤 HTTP 주소가 자동으로 보안 연결로 이동하는지 확인합니다.
• 소개, 프로젝트 상세, 이력서 등 모든 핵심 경로를 새 도메인에서 다시 엽니다.
• 페이지 제목과 설명, 대표 URL 설정이 임시 배포 주소를 가리키지 않는지 검사합니다.
• 404 페이지에는 홈과 프로젝트 목록으로 돌아가는 링크를 제공합니다.

속도보다 먼저 평가자가 찾는 근거를 배치합니다

포트폴리오의 개념은 분야에 따라 작품 모음, 경력 증빙, 성과 기록으로 조금씩 달라집니다. 포트폴리오의 의미와 활용 맥락을 살펴보면 결과물만 나열하는 방식이 왜 부족한지 이해하기 쉽습니다. 개발자 사이트에서는 프로젝트마다 문제, 제약, 선택한 기술, 본인의 기여, 검증 결과를 연결해야 방문자가 역량을 판단할 수 있습니다.

그다음 성능을 다듬습니다. 첫 화면의 대형 이미지 용량을 줄이고, 사용하지 않는 JavaScript를 제거하며, 웹폰트 종류를 제한하세요. 애니메이션은 작품을 이해시키는 데 필요한 경우에만 남깁니다. 평가자가 모바일 데이터 환경에서 접속한다고 가정하면 빠른 첫 화면과 읽기 쉬운 프로젝트 설명이 화려한 전환 효과보다 더 강한 품질 신호가 됩니다.

1. 프로젝트 카드에서 역할과 핵심 성과를 한 문장으로 읽을 수 있게 합니다.
2. 라이브 데모가 중단될 가능성에 대비해 화면 기록과 README 링크를 함께 둡니다.
3. 버튼과 링크를 키보드만으로 이동할 수 있는지 검사합니다.
4. 분석 도구를 붙일 때는 최소한의 이벤트만 수집하고 개인정보 안내를 검토합니다.

작은 JavaScript 프로젝트 하나를 공개 주소로 완성합니다

검색 도구 프로젝트의 배포 과정을 끝까지 따라갑니다

가상의 사례로 Andrey가 만든 ‘Project Finder’를 살펴보겠습니다. 이 프로젝트는 여러 소프트웨어 작업을 기술 스택과 역할로 필터링하는 JavaScript 애플리케이션입니다. 데이터는 저장소 안의 JSON 파일에서 읽고, 로그인과 데이터베이스는 없습니다. 목표는 채용 담당자가 1분 안에 관련 프로젝트를 찾고 Git 저장소와 상세 설명으로 이동하게 만드는 것입니다.

첫 번째 선택지는 GitHub Pages입니다. 서버 기능이 없고 저장소 활동을 함께 보여주기 좋다는 장점이 있지만, 라우팅 설정을 별도로 신경 써야 합니다. 두 번째는 Cloudflare Pages이며 정적 배포와 브랜치 미리보기가 잘 맞습니다. Vercel도 충분히 가능하지만 이 사례에는 서버 렌더링이나 함수가 필요하지 않습니다. Andrey는 필요한 기능에 비해 운영 구조가 단순한 Cloudflare Pages를 선택합니다.

1. 오전 10시: 저장소를 복제한 깨끗한 폴더에서 의존성을 설치하고 빌드를 실행합니다. 생성된 dist 폴더를 로컬 서버로 열어 필터와 링크를 검사합니다.
2. 오전 11시: 배포 서비스에 Git 저장소를 연결하고 빌드 명령과 출력 폴더를 등록합니다. 메인 브랜치는 운영용, 기능 브랜치는 미리보기용으로 구분합니다.
3. 오후 1시: 첫 프리뷰 URL을 휴대전화로 열어 긴 프로젝트명이 카드 밖으로 넘치는 문제를 발견합니다. CSS 줄바꿈 규칙을 수정하고 새 커밋으로 프리뷰가 갱신되는지 확인합니다.
4. 오후 3시: 사용자 정의 도메인을 연결하고 HTTPS 발급을 기다리는 동안 기존 기본 주소에서 회귀 테스트를 수행합니다.
5. 오후 5시: 대표 도메인 리디렉션, 404 화면, 메타 설명, 키보드 탐색을 검사한 뒤 운영 배포를 확정합니다.

공개 후에는 ‘배포 완료’라는 문장만 README에 추가하지 않습니다. Andrey는 왜 네 가지 후보 중 이 서비스를 선택했는지, 정적 JSON 구조가 현재 요구에 충분한 이유는 무엇인지, 방문량이 늘거나 관리자 기능이 필요해질 때 어떤 구조로 이전할지를 기록합니다. 이렇게 하면 단순한 링크가 소프트웨어 설계 판단을 보여주는 개발자 포트폴리오로 바뀝니다.

일주일 뒤에는 방문자가 필터 버튼을 사용했는지보다 더 직접적인 품질 신호를 확인합니다. 깨진 외부 링크가 없는지, 프로젝트 상세 페이지까지 두 번 이내의 클릭으로 도달하는지, 모바일에서 이력서가 제대로 열리는지를 살핍니다. 작품 선별과 제시 방식에 관한 또 다른 설명은 포트폴리오 관련 지식백과 항목에서도 확인할 수 있습니다.

• 문의 폼이 새로 필요해지면 Netlify 기능 또는 별도 폼 서비스를 작은 브랜치에서 시험합니다.
• 서버 렌더링이 필요한 상세 페이지가 늘어나면 Vercel과 현재 구조의 이전 비용을 다시 비교합니다.
• 정적 파일과 배포 횟수가 무료 한도에 가까워지면 사용량 화면을 기록하고 유료 전환 또는 구조 단순화를 판단합니다.
• 매달 첫째 주에 링크, 인증서, 의존성, 모바일 화면을 점검하는 이슈를 자동 생성합니다.

세 달 뒤 Project Finder에는 여전히 불필요한 서버가 없습니다. 대신 배포 이력, 선택 근거, 복구 가능한 설정, 정기 점검 기록이 남아 있습니다. 면접에서 Andrey는 주소를 보여주는 데서 멈추지 않고, 요구사항을 분리하고 네 서비스를 비교한 뒤 가장 작은 운영 구조를 선택한 과정을 실제 커밋과 프리뷰 기록으로 설명합니다.