이 글은 누구를 위한 것인가
- 취업이나 프리랜서 활동을 위해 포트폴리오 사이트를 만들거나 개선하려는 개발자
- 포트폴리오 사이트가 있지만 검색에 잘 노출되지 않아 고민인 분
- 디자인은 잘하는데 SEO는 처음인 프론트엔드 개발자
들어가며
포트폴리오 사이트를 만들고 나서 "왜 구글에서 내 이름을 검색해도 안 나오지?"라고 생각한 적 있을 것이다. 아무리 멋진 디자인이어도, 검색 결과에 나타나지 않으면 채용 담당자나 잠재 클라이언트의 눈에 들어올 기회 자체가 없다.
더 큰 문제는 많은 개발자 포트폴리오 사이트가 SEO의 기초조차 갖추지 않고 있다는 것이다. 구조화 데이터가 없고, 페이지 속도는 느리고, 메타 태그는 기본값 그대로다.
디자이너로서 우리가 주목해야 할 것은 "SEO와 좋은 디자인은 충돌하지 않는다"는 사실이다. 오히려 사용자 경험을 위한 좋은 디자인 결정이 SEO에도 긍정적으로 작용한다. 이 글에서는 포트폴리오 사이트의 디자인과 SEO를 동시에 잡는 방법을 다룬다.
이 글은 bluefoxdev.kr의 개발자 SEO 완전 가이드 포스트를 참고하고, 디자인 관점에서 확장하여 작성했습니다.
1. SEO의 시작은 구조: 디자인과 HTML 시맨틱의 관계
포트폴리오 사이트의 SEO는 화려한 기술보다 기초 구조에서 갈린다.
시맨틱 HTML이 디자인 언어가 돼야 한다
시각적으로 멋진 포트폴리오를 만들다 보면 div와 span으로 모든 것을 구성하기 쉽다. 하지만 검색 엔진은 HTML 구조를 통해 콘텐츠의 의미를 파악한다.
<!-- SEO 관점에서 좋지 않은 구조 -->
<div class="hero">
<div class="name">김철수</div>
<div class="role">프론트엔드 개발자</div>
</div>
<!-- SEO 관점에서 좋은 구조 -->
<header>
<h1>김철수 — 프론트엔드 개발자</h1>
<p>React와 TypeScript를 주로 다루는 5년차 개발자입니다.</p>
</header>
디자인 결과는 동일하게 만들 수 있다. 하지만 검색 엔진이 읽는 정보의 질은 완전히 다르다. h1은 페이지에서 가장 중요한 텍스트임을 알려주고, header는 사이트 헤더 영역임을 알려준다.
헤딩 계층 구조를 디자인 컴포넌트에 맞춰라
포트폴리오 사이트의 섹션 구조와 헤딩 계층을 일치시켜야 한다.
h1: 이름 + 직함 (한 페이지에 하나)
h2: 주요 섹션 (About, Projects, Skills, Contact)
h3: 프로젝트 이름, 기술 카테고리
h4: 세부 항목 (필요한 경우)
이 계층은 시각적 타이포그래피 스케일과 일치해야 한다. h2가 시각적으로 가장 크고 눈에 띄어야 하고, 하위로 갈수록 작아지는 것이 자연스럽다.
2. 메타 태그 최적화: 검색 결과에서 첫인상을 결정한다
검색 결과 페이지(SERP)에서 당신의 포트폴리오가 어떻게 보이는지는 메타 태그가 결정한다.
Title 태그: 50~60자의 황금 법칙
<!-- 나쁜 예: 너무 짧고 정보가 없음 -->
<title>포트폴리오</title>
<!-- 나쁜 예: 너무 길어서 잘림 -->
<title>김철수 - 5년차 프론트엔드 개발자 React TypeScript Next.js 전문가 포트폴리오</title>
<!-- 좋은 예: 50~60자, 핵심 정보 포함 -->
<title>김철수 — React 전문 프론트엔드 개발자 포트폴리오</title>
50~60자 제한을 디자인 제약으로 받아들여야 한다. 검색 결과에서 잘리는 제목은 브랜딩 실패다.
Meta Description: 150~160자의 광고 문구
<meta name="description" content="5년차 프론트엔드 개발자 김철수입니다.
React, TypeScript, Next.js로 사용자 경험을 만듭니다.
스타트업부터 대기업까지 다양한 프로젝트 경험을 보유하고 있습니다.">
Description은 검색 결과에서 클릭을 유도하는 광고 문구다. 무엇을 잘하는지, 어떤 경험이 있는지, 왜 연락해야 하는지를 150~160자 안에 담아야 한다.
포트폴리오 페이지마다 고유한 메타 태그: 메인 페이지, 프로젝트 상세 페이지, 블로그 글 각각 고유한 title과 description이 있어야 한다.
3. sitemap.xml과 robots.txt: 검색 엔진과의 소통 채널
sitemap.xml
검색 엔진 크롤러에게 "이 사이트에 이런 페이지들이 있다"고 알려주는 파일이다.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://yourname.dev/</loc>
<lastmod>2026-04-01</lastmod>
<priority>1.0</priority>
</url>
<url>
<loc>https://yourname.dev/projects</loc>
<lastmod>2026-04-01</lastmod>
<priority>0.8</priority>
</url>
<url>
<loc>https://yourname.dev/projects/my-awesome-project</loc>
<lastmod>2026-03-15</lastmod>
<priority>0.6</priority>
</url>
</urlset>
Next.js나 Gatsby로 만든 사이트라면 sitemap 자동 생성 플러그인이 있다. 직접 관리하지 않아도 된다.
robots.txt
User-agent: *
Allow: /
Sitemap: https://yourname.dev/sitemap.xml
대부분의 경우 모든 페이지를 크롤링하도록 허용하면 된다. 관리자 페이지나 내부 스테이징 경로가 있다면 그것만 Disallow로 처리한다.
4. 구조화 데이터: 검색 결과를 더 풍부하게
구조화 데이터(Structured Data)는 검색 엔진이 콘텐츠를 더 잘 이해하도록 돕는다. 잘 적용하면 검색 결과에 리치 스니펫이 표시된다.
개인 포트폴리오에 적용할 JSON-LD
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Person",
"name": "김철수",
"jobTitle": "프론트엔드 개발자",
"url": "https://yourname.dev",
"sameAs": [
"https://github.com/yourname",
"https://linkedin.com/in/yourname"
],
"knowsAbout": ["React", "TypeScript", "Next.js", "웹 성능 최적화"],
"description": "사용자 경험을 중심으로 생각하는 5년차 프론트엔드 개발자"
}
</script>
블로그 포스트가 있다면 각 포스트에 BlogPosting 스키마를 추가한다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "포스트 제목",
"datePublished": "2026-04-01",
"author": {
"@type": "Person",
"name": "김철수"
},
"description": "포스트 요약"
}
</script>
5. Core Web Vitals: 성능이 곧 디자인 품질이다
구글은 페이지 경험을 검색 순위 요소로 사용한다. 특히 Core Web Vitals 세 가지가 핵심이다.
LCP (Largest Contentful Paint): 가장 큰 콘텐츠 요소가 로드되는 시간. 2.5초 이내가 목표.
포트폴리오의 히어로 섹션 이미지가 LCP를 결정하는 경우가 많다. 고해상도 사진 한 장이 LCP를 망친다.
<!-- LCP 개선: 히어로 이미지에 priority 지정 (Next.js) -->
<Image
src="/hero-photo.jpg"
alt="김철수 프로필 사진"
width={400}
height={400}
priority <!-- 이 속성 하나가 LCP를 크게 개선한다 -->
/>
CLS (Cumulative Layout Shift): 콘텐츠가 갑자기 이동하는 정도. 0.1 이하가 목표.
폰트 로딩 중 텍스트가 밀리는 현상, 이미지 크기 미지정으로 인한 레이아웃 점프가 CLS의 주요 원인이다. 이미지에는 항상 width와 height를 명시하고, 폰트는 font-display: swap을 사용한다.
INP (Interaction to Next Paint): 사용자 상호작용에 대한 반응 속도. 200ms 이하가 목표.
불필요하게 무거운 JavaScript, 렌더링을 블로킹하는 서드파티 스크립트가 INP를 악화시킨다.
[Core Web Vitals 목표값]
LCP: 2.5초 이내 (Good)
CLS: 0.1 이하 (Good)
INP: 200ms 이하 (Good)
6. 디자인 시스템 관점에서의 SEO 체크리스트
좋은 포트폴리오 디자인 시스템은 SEO 친화적이어야 한다.
콘텐츠 구조
□ h1은 페이지당 하나, 이름 + 직함 포함
□ 헤딩 계층이 논리적 (h1 → h2 → h3)
□ 이미지에 의미 있는 alt 텍스트
메타 정보
□ 각 페이지 고유한 title (50~60자)
□ 각 페이지 고유한 description (150~160자)
□ Open Graph 태그 (SNS 공유 시 미리보기)
기술 SEO
□ sitemap.xml 존재 및 Google Search Console 등록
□ robots.txt 설정
□ HTTPS 적용
□ JSON-LD 구조화 데이터
성능
□ LCP < 2.5초 (PageSpeed Insights로 확인)
□ CLS < 0.1
□ INP < 200ms
□ 모바일 친화성 테스트 통과
맺으며
포트폴리오 사이트는 당신을 대신해 24시간 일하는 영업 사원이다. 멋진 디자인은 방문자를 설득하지만, SEO는 방문자가 당신을 찾을 수 있게 한다.
좋은 소식은 SEO를 위한 노력이 대부분 좋은 디자인 관행과 일치한다는 것이다. 의미 있는 HTML 구조, 빠른 로딩 속도, 명확한 콘텐츠 계층 — 이것들은 SEO를 위한 것이기도 하지만, 사용자 경험을 위한 것이기도 하다.
처음부터 완벽하게 하려 하지 말자. 메타 태그 정리, sitemap 추가, 이미지 최적화 — 이 세 가지만 해도 검색 가시성이 눈에 띄게 달라진다. 오늘 PageSpeed Insights에서 내 포트폴리오를 한번 측정해보는 것이 시작이다.
출처 및 참고 자료