개인 포트폴리오 & 기술 블로그

만든 이유

프론트엔드 개발자인데 본인을 소개하는 웹사이트가 없었습니다. 노션 링크를 공유하는 것도 불편했고, 해결한 문제들을 기록하지 않아 나중에 기억하지 못하는 악순환도 반복됐습니다. 미뤄두고만 있던 기술들을 실제로 적용해볼 기회도 필요했습니다.

세 가지를 한 번에 해결하기 위해 만들었습니다. 포트폴리오 공간, 트러블슈팅 기록 공간, 새로운 기술 적용 실습.

주요 기능

Hero

화면에 딱 들어온 순간 사용자의 시선을 잡아야 한다고 생각했습니다. 3초 안에 흥미를 못 끌면 그냥 뒤로가기니까요.

화면을 좌우로 갈랐습니다. 왼쪽엔 내가 무엇을 추구하는지를 큼직하게 박아두고, 오른쪽엔 Matter.js 물리 엔진으로 키워드 필이 하늘에서 뚝뚝 떨어져 중력에 따라 쌓이도록 했습니다. 경력이란 결국 그렇게 하나씩 쌓이는 거니까요.

왼쪽과 오른쪽은 하나로 엮여 있습니다. 오른쪽 필에 마우스를 호버하면 왼쪽 설명 글씨가 그 키워드에 맞게 바뀌고, 필을 클릭하면 해당 섹션으로 스르륵 이동합니다. 사용자는 첫 화면에서 손가락 몇 번으로 내 전부를 훑을 수 있습니다. 스크롤을 강요하지 않아도, 궁금한 필만 누르면 원하는 곳으로 데려다주는 구조입니다. 거기에 헤드라인 3줄이 10초 간격으로 슬라이드 업되며 바뀝니다.

About

Hero가 시선을 끄는 자리라면, About은 내가 어떤 개발자인지 솔직하게 말하는 자리입니다. 화려한 수식어 대신, 실제로 어떤 사람인지를 담았습니다.

나는 “이 정도는 원래 참고 하는 거야”를 잘 못 견딥니다. 반복되는 불편을 마주하면 손이 근질거려 구조나 자동화로 바꿔버립니다. 고등학생 때 첫 회사에서 실사용자에게 나가는 제품을 만들어왔고, 잘 짠 코드보다 실제로 문제를 해결하고 누군가 진짜로 쓰는 것이 먼저라는 걸 배웠습니다.

그 아래엔 경력과 학력을 타임라인으로 뒀습니다. Hero에서 필이 쌓이던 은유를, About에선 시간순으로 펼쳐 보이는 셈입니다.

Skills

숙련도를 별점이나 퍼센트 바로 표현하는 방식은 관뒀습니다. “React 90%” 같은 숫자가 대체 무슨 의미인지 설명하기 어렵더라고요. 그동안 다뤄온 기술을 카테고리별로 묶어 한눈에 보이게 하는 데만 집중했습니다. 과장 없이, 있는 그대로입니다.

Projects

제일 신경 쓴 건 예쁜 결과 스크린샷이 아니라 “무슨 문제를 어떻게 풀었나”입니다. 카드에는 어떤 문제가 있었고 어떻게 접근했는지가 드러나게 했습니다. 카드를 클릭하면 세부 페이지로 넘어가고, 거기엔 트러블슈팅 기록이 아코디언으로 접혀 있습니다. 결과만 자랑하는 포트폴리오는 많지만, 과정을 보여주는 쪽이 더 나답다고 생각했습니다.

Blog — 카테고리 필터, 키워드 검색, 클라이언트 사이드 페이지네이션을 갖춘 기술 블로그입니다. 포스트는 MDX로 작성하고 파일명이 URL slug가 됩니다.

공통 — .animate-in 클래스만 추가하면 IntersectionObserver가 스크롤 진입 시 자동으로 등장 애니메이션을 적용합니다.

Astro를 고른 이유

문제 포트폴리오 사이트는 소개·프로젝트·블로그 포스트가 전부 빌드 타임에 확정되는 정적 콘텐츠인데, 이 특성에 맞지 않는 프레임워크를 쓰면 불필요한 서버 비용과 복잡도가 생길 위험이 있었습니다.

분석 Next.js, Gatsby, Astro를 검토했습니다. 데이터가 실시간으로 바뀌지 않아 서버가 필요한 이유가 없었고, 기본이 SSG면서 JavaScript를 필요한 곳에만 끼워 넣는 Astro가 가장 적합하다고 판단했습니다.

실행 프론트매터 값이 잘못돼도 런타임까지 발견되지 않을 수 있다는 제약 속에서, Content Collections로 프론트매터를 Zod 스키마로 타입 검증해 잘못된 값이 빌드 단계에서 바로 드러나도록 구성했습니다.

결과 MDX를 빌드 타임에 HTML로 변환하는 구조로 정상 동작을 확인했습니다.

CI/CD — GitHub Actions → S3 + CloudFront

문제 정적 사이트 배포를 위한 CI/CD가 필요했는데, Vercel 같은 관리형 서비스는 편리하지만 구성 경험을 얻기는 어려웠습니다.

분석 Vercel 같은 관리형 배포와 GitHub Actions + S3 + CloudFront 직접 구성을 비교했습니다. 이 프로젝트의 목적 중 하나가 새로운 기술을 직접 적용해보는 것이라, 직접 구성 경험을 얻을 수 있는 쪽을 선택했습니다.

실행 관리형 서비스 대비 늘어나는 설정 복잡도라는 트레이드오프를 감수하며, main 브랜치에 push하면 GitHub Actions가 빌드 → aws s3 sync --delete로 바뀐 파일만 업로드 → CloudFront invalidation으로 CDN 캐시를 강제 갱신하는 파이프라인을 직접 구성했습니다.

결과 push 시 자동으로 빌드·배포·캐시 무효화까지 이어지는 파이프라인 동작을 확인했습니다.