포트폴리오를 만들었는데 Lighthouse 점수가 62점이라면? 솔직히 말해서, 그게 제일 먼저 눈에 띕니다. dev.to의 포트폴리오 가이드 기사에서 "Lighthouse 감사를 실행하고 모든 지표에서 90점 이상을 목표로 하라"는 조언이 나오는 건 이유가 있어요. 채용담당자가 링크를 열기 전에, 브라우저가 이미 당신을 평가하고 있으니까요.
프론트엔드 개발자의 포트폴리오 사이트는 단순한 이력서가 아닙니다. 그 사이트 자체가 작업물입니다. 그런데 대부분의 포트폴리오가 놓치는 게 있어요. 내용은 신경 쓰는데, 구현 품질은 대충 넘어간다는 거예요. 컴포넌트 라이브러리 갖다 붙이고, any 타입 떡칠하고, 모바일에서 레이아웃 깨져도 일단 올리고 보는 식이죠. "Figma에서 볼 때는 괜찮았는데 실제 구현하면..." 이 괴리, 정작 본인 포트폴리오에서 그대로 드러나는 겁니다.
콘텐츠 전략: 3~5개 프로젝트, 그리고 '스토리'
dev.to 기사에서 200개 포트폴리오를 리뷰한 채용 담당자가 지적한 핵심은 명확합니다. 90%가 똑같은 실수를 반복한다는 것. Todo 앱, 날씨 앱, 계산기—이건 코딩을 할 줄 안다는 증명이지, 문제를 해결할 수 있다는 증명이 아닙니다. 프로젝트는 3~5개면 충분하고, 각각은 '왜 만들었고, 어떤 기술적 판단을 했고, 실제로 어떤 임팩트가 있었는지'를 케이스 스터디 형식으로 보여줘야 합니다. "200명이 매달 쓰는 태스크 매니저"와 "todo 앱"의 차이는 코드 품질이 아니라 서사의 밀도입니다.
그리고 기술 스택 나열할 때 스킬 프로그레스 바는 제발 없애주세요. JavaScript: 90%가 뭘 의미하는지 아무도 모릅니다. 차라리 "React (2년, 프로덕션 일상 사용)"처럼 컨텍스트를 붙이는 게 훨씬 낫습니다. 2026년 기준으로 프론트엔드라면 React 또는 Next.js, TypeScript, Tailwind의 실제 사용 경험을 구체적으로 보여주는 게 포인트예요.
구현 품질: 포트폴리오 사이트 그 자체를 잘 만들어야 한다
여기서부터가 진짜입니다. 포트폴리오 사이트를 React나 Next.js, Astro로 만든다면—그 사이트 자체에 프론트엔드 실력이 그대로 묻어납니다. 로딩 스켈레톤은 있나요? 이미지에 alt 텍스트는 붙어 있나요? 키보드로 탭 네비게이션 해봤나요? WCAG 기준 컬러 대비는 통과하나요? 접근성(a11y)을 신경 쓴다고 About 섹션에 써놓고 정작 본인 포트폴리오에서 <div>로 버튼 만들어놓으면... 그게 제일 치명적이에요.
Core Web Vitals도 당연히 챙겨야 합니다. LCP, CLS, INP—이 세 지표가 나쁘면 사용자 경험이 나쁜 거고, 사용자 경험이 나쁜 포트폴리오를 만든 프론트엔드 개발자를 채용하고 싶은 회사는 없습니다. 번들 사이즈도 마찬가지예요. 포트폴리오 사이트에 쓸데없는 라이브러리 잔뜩 임포트해서 First Load JS가 500KB 넘어가면... 그냥 vanilla CSS로 짰으면 어땠을까 싶은 거죠.
타입 안전성: 'any'가 없는 포트폴리오
TypeScript를 쓴다면, 제대로 써야 합니다. dev.to에 올라온 TypeScript CustomEvent 타입 안전성 관련 기사가 이 맥락에서 흥미롭습니다. 네이티브 EventTarget을 제네릭으로 감싸서 TypedEventTarget<M> 클래스를 만들면, addEventListener 시점부터 이벤트 페이로드 타입이 자동 추론됩니다. 런타임 오버헤드는 제로, 타입 안전성은 100%. 이런 패턴을 포트폴리오 사이트에 실제로 적용하면—예를 들어 프로젝트 필터링, 다크모드 토글, 애니메이션 트리거 같은 컴포넌트 간 이벤트 통신에—as any 없이도 깔끔하게 처리할 수 있어요. 코드 한 줄 한 줄이 보여주는 의도의 명확성, 그게 포트폴리오 리뷰어가 GitHub 레포를 열었을 때 느끼는 첫인상입니다.
구체적으로는 이렇게 생각해볼 수 있습니다. 포트폴리오에 프로젝트 카드 필터 기능을 만든다고 하면, Zustand나 Context API 대신 TypedEventTarget으로 경량 이벤트 버스를 구성하는 선택지도 있어요. 프레임워크에 종속되지 않고, 타입은 완벽하게 보장되면서요. "이 라이브러리 도입하면 bundle size가..." 하는 고민을 해본 사람이라면 이 접근의 매력을 바로 이해할 겁니다.
인터랙션과 반응형: 디테일이 차이를 만든다
애니메이션은 있으면 좋고, 과하면 역효과입니다. 페이지 전환에 framer-motion 쓰는 건 좋은데, CLS(Cumulative Layout Shift)를 유발하는 애니메이션은 오히려 감점 요인이에요. 마이크로 인터랙션—버튼 hover 상태, 카드 포커스 아웃라인, 링크 언더라인 애니메이션—이런 것들이 쌓여서 "이 사람은 디테일을 본다"는 인상을 줍니다. 모바일 퍼스트로 설계하고, 브레이크포인트마다 레이아웃이 자연스럽게 흘러야 해요. Container Queries 써보셨나요? 컴포넌트 단위 반응형이 필요한 프로젝트 카드 레이아웃에는 사실 grid보다 container query 조합이 더 우아하게 풀립니다.
결론: 포트폴리오는 당신의 가장 긴 코드 리뷰다
채용담당자가 링크를 열기 전에 Lighthouse가 먼저 봅니다. GitHub 레포를 열었을 때 any 타입과 eslint-disable 주석이 보이면, 케이스 스터디가 아무리 잘 써있어도 흔들립니다. 포트폴리오 사이트 자체가 Lighthouse 90점 이상, 접근성 통과, 타입 안전한 TypeScript, 깔끔한 컴포넌트 구조를 갖추고 있다면—그게 이미 "저 이 정도는 기본으로 챙깁니다"라는 선언입니다. 내용도 구현도, 둘 다 잡아야 2026년 프론트엔드 포트폴리오라고 할 수 있습니다.