개인 포트폴리오 제작 도구는 목적에 따라 골라야 오래 간다

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

작업물을 정리하려고 포트폴리오 제작 도구부터 검색하면 Framer, Webflow, Squarespace, GitHub Pages가 한꺼번에 등장합니다. 문제는 네 서비스 모두 그럴듯한 사이트를 만들 수 있지만, 제작 속도와 디자인 자유도, 유지 비용, 운영 방식은 전혀 다르다는 점입니다. 첫 화면이 예쁘다는 이유만으로 선택하면 프로젝트를 추가할 때마다 구조를 뜯어고치거나 사용하지 않는 기능에 매달 비용을 낼 수 있습니다.

좋은 도구는 기능이 가장 많은 서비스가 아니라 자신의 작업 방식과 잘 맞는 서비스입니다. 이 글에서는 디자이너, 개발자, 프리랜서, 글을 함께 발행하는 창작자라는 실제 상황을 기준으로 네 가지 도구를 비교합니다. Jim Samuels 같은 personal site를 구축하면서 작품, 글쓰기, 전문 경력을 한곳에 담고 싶은 독자라면 어느 기준에 우선순위를 둬야 하는지도 구체적으로 확인할 수 있습니다.

포트폴리오 도구를 고르기 전에 운영 방식을 먼저 정합니다

사이트의 역할이 달라지면 필요한 기능도 달라집니다

개인 포트폴리오가 채용 담당자에게 작업 사례 세 개를 보여주는 명함인지, 검색을 통해 꾸준히 독자를 모으는 전문 미디어인지부터 구분해야 합니다. 전자라면 빠른 로딩과 선명한 프로젝트 설명이 중요하고, 후자라면 CMS, 카테고리, 메타데이터, 글 예약 발행 같은 운영 기능의 가치가 커집니다. Portfolio의 용어적 배경도 참고할 수 있지만, 웹 포트폴리오는 완성 작품만 묶은 파일이 아니라 방문자가 역량을 탐색하는 동적인 경로에 가깝습니다.

업데이트 주기도 반드시 따져야 합니다. 1년에 두 번 프로젝트를 교체하는 사람은 정적 페이지로 충분하지만, 매주 글을 쓰거나 매달 사례를 추가한다면 콘텐츠 입력 화면이 편해야 합니다. 편집할 때마다 레이아웃과 코드를 건드려야 하는 구조에서는 처음에 절약한 비용보다 관리 시간이 더 크게 쌓입니다. 반대로 업데이트가 거의 없는데 복잡한 CMS 요금제를 선택하면 필요 이상의 고정비를 떠안게 됩니다.

또 하나의 기준은 사이트를 누가 관리하느냐입니다. 혼자 운영한다면 자신의 숙련도만 고려하면 되지만, 클라이언트나 동료가 글을 올릴 가능성이 있다면 편집 권한과 협업 기능까지 봐야 합니다. 도구 선택은 제작 시점의 나보다 6개월 뒤 운영자의 행동을 기준으로 해야 합니다. 템플릿 데모가 멋져 보여도 새 프로젝트 한 건을 추가하는 과정이 복잡하다면 장기적으로 좋은 선택이 아닙니다.

• 채용 중심: 대표 프로젝트, 역할, 성과, 연락처를 빠르게 전달할 수 있어야 합니다.
• 영업 중심: 서비스 소개, 사례 분류, 문의 양식과 신뢰 요소가 필요합니다.
• 콘텐츠 중심: CMS, 태그, 검색 노출 설정과 반복 발행 과정이 중요합니다.
• 개발 역량 증명: 코드 구조, 배포 이력, 저장소 연결 자체가 포트폴리오가 될 수 있습니다.

가격표보다 숨은 운영비를 함께 봅니다

서비스 요금만 비교하면 GitHub Pages가 가장 저렴하고 유료 빌더가 비싸 보입니다. 그러나 코딩에 익숙하지 않은 사람이 정적 사이트를 수정하느라 매달 여러 시간을 쓴다면 실질 비용은 달라집니다. 유료 도구도 기본 구독료 외에 사용자 좌석, 다국어, 고급 분석, 도메인 구입비가 붙을 수 있으므로 도메인 포함 여부와 협업 인원, 필요한 부가 기능을 같은 조건으로 계산해야 합니다.

1. 앞으로 12개월 동안 추가할 프로젝트와 글의 수를 적습니다.
2. 도메인, 호스팅, 편집자 좌석과 유료 템플릿 비용을 합산합니다.
3. 업데이트 한 번에 필요한 예상 시간을 자신의 시간당 가치로 환산합니다.
4. 다른 서비스로 옮길 때 콘텐츠와 코드를 내보낼 수 있는지 확인합니다.

도구를 고르는 가장 현실적인 질문은 이것입니다. “이 사이트를 만든 뒤 새 사례 한 건을 혼자 30분 안에 올릴 수 있는가?” 답이 아니라면 화려한 기능보다 운영 구조를 다시 살펴보는 편이 낫습니다.

네 가지 제작 서비스를 같은 조건에서 비교합니다

디자인과 콘텐츠 관리 능력에는 분명한 차이가 있습니다

아래 표는 작품 사례 5~10개, 소개 페이지, 글 목록, 개인 도메인을 갖춘 professional portfolio를 만든다는 조건으로 비교한 결과입니다. 가격은 2026년 8월 공개 정책을 바탕으로 한 대략적인 범위이며 결제 주기, 지역 세금, 환율, 추가 좌석에 따라 달라질 수 있습니다. 따라서 금액 자체보다 무료 공개 가능 여부와 개인 도메인 연결에 필요한 유료 단계, 관리 부담의 차이를 중심으로 읽는 것이 좋습니다.

Framer는 캔버스에서 요소를 배치하는 감각이 디자인 도구와 가까워 첫 결과물을 빠르게 만들기 좋습니다. Webflow는 HTML과 CSS의 구조를 시각 인터페이스로 다루는 성격이 강해 더 깊은 통제가 가능하지만, 클래스와 레이아웃 개념을 이해하지 않으면 수정할수록 구조가 복잡해질 수 있습니다. 두 서비스 모두 인터랙션을 만들기 편하지만 모션은 작품 설명을 돕는 범위에서만 사용해야 접근성과 속도를 지킬 수 있습니다.

Squarespace는 디자인 선택지를 일정 범위로 제한하는 대신 호스팅, 블로그, 기본 분석과 관리 화면을 한데 묶습니다. GitHub Pages는 정적 HTML이나 Jekyll 같은 생성기를 저장소에서 배포하므로 코드 변경 이력까지 드러낼 수 있지만, 문의 폼이나 관리자형 CMS는 외부 서비스를 조합해야 합니다. 포트폴리오의 일반적 의미와 활용 범위는 포트폴리오 지식백과 설명을 함께 참고하면 이해하기 쉽습니다.

• 가장 빠른 시각적 완성: Framer
• 레이아웃과 CMS의 정밀한 통제: Webflow
• 운영 기능을 한곳에서 처리: Squarespace
• 코드 소유권과 최소 호스팅 비용: GitHub Pages

SEO는 서비스 이름보다 페이지 설계가 좌우합니다

네 도구 모두 기본적인 제목과 설명, 소셜 공유 정보, 개인 도메인을 설정할 방법이 있으므로 특정 서비스를 쓰기만 하면 검색 상위에 오른다는 주장은 믿기 어렵습니다. 검색 노출은 프로젝트별 고유 URL, 의미가 분명한 제목, 실제 경험이 담긴 본문, 내부 링크와 로딩 성능이 함께 결정합니다. 템플릿 안의 의미 없는 영문 문구와 샘플 페이지를 그대로 남기는 실수가 도구의 미세한 성능 차이보다 더 큰 문제를 만듭니다.

• 프로젝트마다 하나의 독립 URL과 고유한 메타 설명을 부여합니다.
• 작품명만 쓰지 말고 해결한 문제와 직무 키워드를 제목에 포함합니다.
• 큰 영상과 폰트를 줄이고 모바일 첫 화면의 로딩을 확인합니다.
• 소개 글에서 관련 프로젝트로, 프로젝트에서 문의 페이지로 내부 링크를 연결합니다.

직무와 운영 상황에 따라 추천 서비스가 달라집니다

디자이너와 프리랜서는 수정 빈도로 선택합니다

브랜딩이나 UI 디자인을 하는 사람이 짧은 기간에 인상적인 개인 사이트를 공개해야 한다면 Framer가 유리합니다. 디자인 파일을 다루듯 화면을 구성할 수 있고 애니메이션 결과도 즉시 확인할 수 있어, 코드를 배우기 전에 시각적 방향을 검증하기 좋습니다. 다만 프로젝트 수가 빠르게 늘어난다면 각 카드를 수동으로 복제하지 말고 처음부터 CMS 컬렉션을 만들어 제목, 역할, 기간, 썸네일과 본문을 필드로 분리해야 합니다.

여러 업종의 사례를 쌓는 프리랜서나 소규모 스튜디오에는 Webflow가 더 잘 맞을 수 있습니다. 예를 들어 브랜딩, 웹 디자인, 캠페인 사례를 필터로 나누고 각 프로젝트에 같은 정보 구조를 적용한다면 CMS의 이점이 큽니다. 대신 한 페이지짜리 명함 사이트에 복잡한 Workspace와 고급 Site plan을 붙이는 것은 과합니다. 필요한 사이트 수와 실제 편집자 수를 구분해 요금 구조를 확인하는 과정이 반드시 필요합니다.

사진가, 작가, 코치처럼 작품과 글, 서비스 소개를 직접 관리하되 웹 제작 자체에는 시간을 적게 쓰고 싶다면 Squarespace가 편안합니다. 템플릿의 기본 간격과 타이포그래피가 안정적이고 관리 기능이 통합되어 있기 때문입니다. 완전히 독특한 인터랙션보다 꾸준한 글 발행과 문의 관리가 중요한 사람에게는 제한된 자유도가 오히려 운영 실수를 줄여 줍니다.

• 시각 디자이너: Framer로 핵심 프로젝트 4~6개를 강하게 보여줍니다.
• 사례가 계속 늘어나는 스튜디오: Webflow CMS로 분야와 서비스를 구조화합니다.
• 사진가·작가·컨설턴트: Squarespace에서 작품, 글, 소개를 함께 관리합니다.
• 짧은 캠페인용 포트폴리오: 무료 서브도메인에서 먼저 검증한 뒤 개인 도메인을 연결합니다.

개발자에게는 배포 과정도 전문성을 보여주는 자료가 됩니다

프론트엔드 개발자나 기술 작가라면 GitHub Pages가 단순히 비용을 아끼는 선택에 그치지 않습니다. 저장소 구조, 커밋 기록, 자동 배포, 접근성 개선 과정이 모두 전문성을 뒷받침할 수 있습니다. Astro, Eleventy 같은 정적 사이트 생성기를 활용하면 프로젝트 데이터와 글을 파일로 관리할 수 있고, 플랫폼을 옮기더라도 원본 콘텐츠를 비교적 쉽게 보존할 수 있습니다.

그렇다고 모든 개발자에게 GitHub Pages가 정답은 아닙니다. 취업 준비 기간에 사이트 프레임워크를 직접 만드는 데 며칠을 쓰느라 정작 사례 설명을 미룬다면 목적이 뒤집힌 것입니다. 이때는 Framer나 Squarespace 템플릿으로 먼저 공개한 다음, 코드 기반 사이트가 실제 역량을 더 잘 설명할 때 이전해도 늦지 않습니다. 채용 담당자가 먼저 보는 것은 빌드 도구보다 문제, 기여 범위, 판단 근거, 검증된 결과입니다.

Jim Samuels 같은 개인 사이트도 직함 하나에만 맞출 필요는 없습니다. 포트폴리오, writings, professional background를 상단 탐색에서 분리하되 프로젝트 글과 전문 글을 서로 연결하면 창의성과 사고 과정을 함께 보여줄 수 있습니다. 방문자가 글을 읽은 뒤 관련 작업 사례로 이동하고, 다시 경력과 연락 수단을 찾을 수 있다면 사이트 전체가 하나의 설득 흐름으로 작동합니다.

1. 개발 과정 자체가 평가 대상이면 GitHub Pages를 우선 검토합니다.
2. 마케팅 담당자와 함께 수정해야 한다면 시각형 CMS를 선택합니다.
3. 코드 데모는 저장소 링크만 던지지 말고 실행 화면과 자신의 기여를 설명합니다.
4. 분석 도구를 연결하기 전 개인정보 고지와 지역별 동의 요건을 확인합니다.

포트폴리오의 기술 수준은 사용한 플랫폼의 난도가 아니라 방문자가 원하는 정보를 방해 없이 찾게 만드는 완성도에서 드러납니다. 직접 코딩했다는 사실보다 왜 그 구조를 선택했는지 설명할 수 있어야 합니다.

오늘 40분짜리 시험 페이지로 후보를 한 개까지 줄입니다

같은 프로젝트를 올려 봐야 편집 차이가 보입니다

기능 소개만 읽고 서비스를 결정하지 말고 실제 대표 프로젝트 하나를 같은 재료로 시험해 보세요. 제목, 120자 요약, 이미지 세 장, 담당 역할, 문제 상황, 해결 과정, 수치가 포함된 결과를 미리 준비합니다. 그런 다음 가장 끌리는 두 서비스의 무료 단계나 체험판에서 동일한 페이지를 각각 20분 동안 만들어 봅니다. 이 짧은 실험만으로도 텍스트 입력, 이미지 교체, 모바일 수정과 발행 과정에서 어디가 막히는지 선명하게 드러납니다.

평가할 때는 데스크톱 화면의 첫인상만 보지 않아야 합니다. 휴대전화에서 제목이 두세 줄로 깨지지 않는지, 본문 글자가 편안한지, 이미지가 지나치게 늦게 뜨지 않는지 확인합니다. 키보드만으로 링크를 이동할 수 있는지, 색상 대비가 충분한지도 살펴보세요. 예쁜 템플릿을 고르는 시험이 아니라 반복 운영에 필요한 마찰을 측정하는 시험입니다.

두 페이지를 만든 뒤에는 느낌 대신 숫자로 판단합니다. 완성 시간, 모바일 수정 횟수, 프로젝트 추가 난이도, 월간 예상비용, 콘텐츠 이전 가능성을 각각 5점으로 평가하세요. 디자인 점수가 조금 높은 서비스보다 업데이트 난이도가 확실히 낮은 서비스가 장기적으로 더 나은 선택일 수 있습니다. 연간 결제는 시험 페이지를 외부인 두 명에게 보여 주고 탐색 문제를 고친 뒤 결정하면 성급한 구독을 피할 수 있습니다.

• 10분: 대표 프로젝트의 텍스트와 이미지를 한 폴더에 준비합니다.
• 20분: 후보 서비스에서 소개, 과정, 결과 블록을 배치합니다.
• 5분: 휴대전화에서 글자 크기, 메뉴, 이미지 로딩을 확인합니다.
• 5분: 새 프로젝트 복제 과정과 개인 도메인 비용을 기록합니다.

선택한 도구보다 먼저 콘텐츠 틀을 보존합니다

플랫폼 안에서 바로 글을 쓰기 시작하면 나중에 서비스를 바꿀 때 원문을 찾고 옮기는 일이 어려워집니다. 프로젝트 원고와 이미지 원본, 대체 텍스트, 메타 설명은 별도 폴더나 문서에 보관하세요. 파일명도 final-final-2.jpg처럼 모호하게 두지 말고 프로젝트명, 화면명, 순서를 식별할 수 있게 정하면 다음 업데이트가 빨라집니다.

이제 타이머를 40분으로 맞추고 가장 자신 있는 프로젝트 하나를 고르세요. 첫 10분 동안 제목, 역할, 문제, 행동, 결과를 각각 한 문단으로 작성한 뒤 Framer, Webflow, Squarespace, GitHub Pages 가운데 현재 역량에 맞는 후보 하나에서 시험 페이지를 공개합니다. 오늘 해야 할 행동은 전체 사이트를 완성하는 것이 아니라, 대표 사례 한 페이지의 모바일 공개 URL을 만드는 것입니다.

1. 대표 프로젝트 하나와 후보 서비스 하나를 선택합니다.
2. 프로젝트 내용을 문제·행동·결과 순서로 다섯 문단 이내에 작성합니다.
3. 이미지 세 장을 압축하고 의미가 드러나는 대체 텍스트를 붙입니다.
4. 모바일 공개 URL을 지인 한 명에게 보내 “무슨 일을 했는지 30초 안에 알 수 있는가”라고 묻습니다.