“무료 호스팅은 다 똑같다” 포트폴리오 배포는 다릅니다

profile_image
작성자 배포경험 설계자 최로안
댓글 0건 조회 7회

포트폴리오 사이트를 완성하고도 어디에 배포할지 결정하지 못해 공개를 미루는 사람이 많습니다. GitHub Pages, Vercel, Netlify, Cloudflare Pages 모두 무료로 시작할 수 있지만, 지원하는 기술과 배포 과정, 사용 제한, 협업 방식은 분명히 다릅니다.

예쁜 화면만 보여 주는 것이 아니라 프로젝트의 배경과 역할, 성과를 증명해야 한다면 호스팅도 표현 방식에 맞춰 골라야 합니다. 포트폴리오의 기본 개념은 네이버 지식백과의 포트폴리오 설명에서도 확인할 수 있듯, 작업 결과를 목적에 맞게 선별해 제시하는 데 있습니다. 배포 서비스는 그 선별된 결과를 방문자에게 안정적으로 전달하는 무대입니다.

네 가지 무료 호스팅, 이름보다 운영 방식이 중요합니다

GitHub Pages·Vercel·Netlify·Cloudflare Pages 비교

아래 비교는 2026년 8월 각 서비스의 공식 안내를 기준으로, 개인 포트폴리오에서 체감하기 쉬운 차이를 추린 것입니다. 무료 플랜의 세부 한도와 상업적 이용 조건은 바뀔 수 있으므로 실제 개설 전 공식 요금 페이지를 다시 확인해야 합니다.

서비스잘 맞는 포트폴리오강점주의할 점
GitHub PagesHTML·CSS·JavaScript 정적 사이트, 개발 기록저장소와 배포 이력이 한곳에 남고 구조가 단순함서버 실행이 필요한 기능은 별도 서비스가 필요함
VercelNext.js·React 기반 인터랙티브 포트폴리오프레임워크 연동과 미리보기 배포가 편리함Hobby는 개인·비상업 용도 조건과 사용량 한도를 살펴야 함
Netlify정적 사이트, 간단한 폼이 필요한 디자이너·기획자 페이지Git 연동이 쉽고 배포 설정과 부가 기능이 직관적임폼 제출량과 빌드·대역폭 등 플랜별 한도를 확인해야 함
Cloudflare Pages이미지가 많거나 해외 접속을 고려한 정적 포트폴리오글로벌 네트워크와 넉넉한 정적 배포 환경이 장점루트 도메인 연결 시 네임서버 설정이 낯설 수 있음

GitHub Pages는 이력서에 GitHub 주소를 함께 제출하는 개발자에게 특히 자연스럽습니다. 저장소의 커밋 기록이 수정 과정을 보여 주기 때문에 결과물뿐 아니라 관리 습관도 전달할 수 있습니다. 다만 문의 폼 처리, 데이터베이스 조회, 로그인처럼 서버가 필요한 기능은 외부 API나 별도 백엔드를 연결해야 합니다.

Vercel은 Next.js 프로젝트를 저장소에 연결하면 브랜치와 풀 리퀘스트별 미리보기 주소를 만들기 편합니다. 프로젝트 상세 페이지에 동적 필터나 애니메이션, 서버리스 기능을 넣고 싶을 때 강합니다. 반면 무료 Hobby 플랜은 개인 프로젝트 중심이므로 프리랜서 영업이나 회사 서비스처럼 상업성이 뚜렷한 용도라면 플랜 조건부터 확인하는 편이 안전합니다.

  • 코드 공개와 단순성 우선: GitHub Pages
  • Next.js 기능과 빠른 미리보기 우선: Vercel
  • 폼과 쉬운 관리 화면 우선: Netlify
  • 정적 자산 전송과 글로벌 접속 우선: Cloudflare Pages

무료라는 이유만으로 결정하지 마세요. 채용 담당자가 링크를 여는 순간부터 수정본을 다시 배포하는 과정까지가 실제 포트폴리오 운영 경험입니다.

직무와 프로젝트 구조에 따라 추천이 달라집니다

개발자는 프레임워크보다 보여 줄 증거부터 고릅니다

프론트엔드 개발자가 React나 Next.js 활용 능력을 직접 보여 주고 싶다면 Vercel이 가장 매끄러운 선택입니다. 프로젝트별 미리보기 주소를 활용하면 진행 중인 개선안도 안전하게 공유할 수 있습니다. 그러나 포트폴리오가 순수 HTML과 CSS로 구성되고 업데이트도 월 1회 정도라면 GitHub Pages가 더 단순하고 유지비도 예측하기 쉽습니다.

백엔드 개발자는 화면보다 아키텍처 설명, API 문서, 테스트 결과와 장애 대응 기록이 핵심일 수 있습니다. 이때 정적 페이지는 GitHub Pages나 Cloudflare Pages에 두고, 실행 데모는 별도의 제한된 환경으로 분리하는 방식이 좋습니다. 공개 데모에 실제 고객 데이터나 운영용 API 키를 넣는 실수는 절대 피해야 합니다.

  1. 채용 공고에서 자주 요구하는 기술 세 가지를 표시합니다.
  2. 그 기술을 증명할 프로젝트 상세 페이지가 정적 문서인지 실행형 앱인지 나눕니다.
  3. 실행형 기능이 없다면 관리가 단순한 GitHub Pages를 먼저 검토합니다.
  4. Next.js 기능과 브랜치 미리보기가 중요하면 Vercel을, 전송 성능과 정적 자산 비중이 크면 Cloudflare Pages를 검토합니다.

디자이너와 기획자는 문의 흐름과 수정 난도를 봅니다

디자이너 포트폴리오는 고해상도 이미지가 많아 첫 화면이 느려지기 쉽습니다. 플랫폼을 바꾸기 전에 WebP·AVIF 변환, 화면 크기별 이미지 제공, 지연 로딩을 적용해야 합니다. 호스팅이 빨라도 원본 PNG 수십 장을 한 페이지에서 한꺼번에 불러오면 방문자는 프로젝트 내용을 읽기 전에 이탈합니다.

기획자나 마케터라면 코드를 얼마나 정교하게 썼는지보다 사례를 얼마나 빠르게 수정할 수 있는지가 중요합니다. Netlify는 정적 사이트 배포와 폼 기능을 한 흐름에서 다루기 편하지만, 제출 건수와 스팸 방지 조건은 플랜별로 확인해야 합니다. 코드를 거의 다루지 않는다면 먼저 문서형 도구에서 콘텐츠 구조를 검증하고, 최종 공개본만 정적 사이트로 옮기는 방법도 현실적입니다.

같은 결과물을 모아도 지원 목적에 따라 선택과 배열은 달라집니다. 또 다른 포트폴리오 용어 설명을 참고하면 교육·평가 맥락에서도 결과물의 축적과 변화 과정이 중요하다는 점을 이해할 수 있습니다. 따라서 완성 화면만 올리기보다 문제 정의, 본인의 기여, 판단 근거, 개선 전후를 함께 배치해야 합니다.

  • UI 디자이너: 이미지 최적화와 모바일 레이아웃을 먼저 시험합니다.
  • UX 기획자: 리서치에서 의사결정으로 이어지는 문서 흐름을 점검합니다.
  • 프리랜서: 문의 폼의 수신 확인, 개인정보 안내, 스팸 차단을 확인합니다.
  • 취업 준비생: 채용 담당자가 로그인 없이 핵심 사례를 열 수 있게 만듭니다.
  • 글로벌 지원자: 해외 지역 접속 속도와 영문 페이지 경로를 함께 시험합니다.

상황별 추천의 기준은 기능 개수가 아니라 증거 전달에 필요한 최소 기능입니다. 사용하지 않을 서버 기능보다 빠른 첫 화면과 끊기지 않는 프로젝트 동선이 더 큰 점수를 만듭니다.

“개인 도메인이 있으면 호스팅은 언제든 바꿔도 되나요?”

주소는 유지할 수 있지만 이전 준비가 없으면 흔적이 끊깁니다

가장 자주 받는 질문의 짧은 답은 “가능하지만 자동으로 해결되지는 않습니다”입니다. davidlee.kr 같은 개인 도메인은 배포 서비스를 바꾸더라도 유지할 수 있습니다. 새 플랫폼에 사이트를 먼저 배포하고 정상 작동을 확인한 뒤 DNS 레코드를 변경하면 방문자가 기억하는 주소는 그대로 유지됩니다.

문제는 검색엔진과 공유 링크가 도메인만 보는 것이 아니라 개별 페이지 경로까지 기억한다는 점입니다. 기존 주소가 /projects/mobile-bank였는데 이전 후 /work/banking-app으로 바뀌면, 예전에 제출한 지원서와 메신저 속 링크는 오류 페이지로 연결될 수 있습니다. 플랫폼 이전 전에 기존 URL 목록을 만들고 같은 경로를 유지하거나 301 리디렉션을 설정해야 합니다.

또한 DNS 변경 직전에 기존 배포를 삭제하면 전파 시간 동안 사이트가 보이지 않을 수 있습니다. 새 호스팅에서 사용자 도메인 인증, HTTPS 인증서 발급, 대표 URL 설정, 모바일 점검을 끝낸 다음 DNS를 전환하세요. 이후에도 기존 서비스는 며칠간 유지하며 오류 로그와 문의 수신 여부를 확인하는 편이 안전합니다.

  1. 이전 주소 수집: 홈, 프로필, 프로젝트 상세, 이력서 다운로드 주소를 기록합니다.
  2. 새 배포 선확인: 플랫폼이 제공하는 임시 주소에서 글꼴, 이미지, 애니메이션과 폼을 시험합니다.
  3. 비밀값 재설정: 환경 변수와 API 키는 저장소에 복사하지 말고 새 플랫폼 설정에 등록합니다.
  4. 도메인 연결: DNS 레코드를 바꾸고 루트 도메인과 www 주소가 한 대표 주소로 모이는지 봅니다.
  5. 검색 흔적 보호: 바뀐 경로에는 301 리디렉션을 두고 사이트맵과 canonical 주소를 갱신합니다.
  6. 실제 기기 검증: 와이파이와 모바일 데이터에서 각각 접속하고 이력서 파일과 문의 버튼을 눌러 봅니다.

서비스를 자주 옮길 가능성이 있다면 콘텐츠와 배포 설정을 분리해 두는 것이 좋습니다. 프로젝트 설명과 이미지 원본은 저장소에서 일정한 폴더 규칙으로 관리하고, 리디렉션 목록과 환경 변수 이름은 별도 문서에 기록하세요. 그러면 GitHub Pages에서 Cloudflare Pages로, 또는 Netlify에서 Vercel로 이동해도 David Lee의 프로필과 프로젝트 주소가 끊기지 않는 포트폴리오를 유지할 수 있습니다.

  • 배포 직후에는 홈 화면만 보지 말고 오래된 프로젝트 링크를 직접 엽니다.
  • PDF 이력서의 파일명과 다운로드 권한이 유지되는지 확인합니다.
  • 문의 폼을 본인 이메일로 실제 전송해 성공 화면과 수신 결과를 함께 확인합니다.
  • 무료 플랜 정책과 사용량 알림을 분기마다 확인해 예기치 않은 중단을 예방합니다.

“무료 호스팅은 다 똑같다” 포트폴리오 배포는 다릅니다

댓글목록

등록된 댓글이 없습니다.