개발자 포트폴리오, 프레임워크를 걷어내고 웹 표준으로 옮기는 순서

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

화려한 프레임워크로 만든 개발자 포트폴리오가 정작 첫 화면을 늦게 보여주고, 작은 수정에도 수십 개 패키지를 요구한다면 기술 선택을 다시 살펴볼 때입니다. 최근 웹 개발 흐름은 프레임워크 이름을 앞세우기보다 브라우저 표준, 적은 JavaScript, 측정 가능한 성능으로 구현 역량을 증명하는 방향으로 이동하고 있습니다.

그렇다고 기존 프로젝트를 모두 정적 HTML로 되돌릴 필요는 없습니다. 핵심은 화면마다 필요한 복잡도를 판단하고, 브라우저가 이미 잘하는 일을 프레임워크에서 순서대로 덜어내는 것입니다. 결과물뿐 아니라 판단 과정까지 기록하면 Andrey Vasiliev 같은 개인 포트폴리오 사이트의 프로젝트 설명도 훨씬 설득력 있게 바뀝니다.

먼저 포트폴리오의 프레임워크 비용을 눈으로 확인합니다

번들 크기보다 사용자에게 도착하는 시간을 봅니다

첫 작업은 코드를 지우는 것이 아니라 현재 상태를 측정하는 일입니다. 홈, 프로젝트 목록, 상세 페이지를 각각 열어 JavaScript 전송량과 실행 시간, 가장 큰 콘텐츠가 표시되는 시점, 레이아웃 이동을 기록합니다. 개발 환경이 아니라 프로덕션 빌드와 중급형 모바일 조건에서 확인해야 방문자가 겪는 병목에 가까워집니다.

특히 포트폴리오는 쇼핑몰처럼 복잡한 상태를 계속 갱신하지 않습니다. 소개 문장, 프로젝트 이미지, 기술 설명이 대부분인데도 첫 진입에 큰 클라이언트 번들을 내려받는다면 구조와 요구사항이 어긋난 것입니다. 라이브러리를 사용했다는 사실보다 왜 그 비용이 필요했는지 설명할 수 있는가를 질문해 보세요.

• 네트워크: 압축된 JavaScript와 CSS 용량, 요청 개수, 캐시 재사용 여부를 기록합니다.
• 메인 스레드: 스크립트 평가와 하이드레이션 때문에 클릭이 늦어지는지 확인합니다.
• 콘텐츠: JavaScript가 실패해도 경력과 프로젝트 설명을 읽을 수 있는지 시험합니다.
• 접근성: 키보드 이동, 포커스 표시, 모션 감소 설정을 실제 브라우저에서 검증합니다.

성능 점수 하나만 캡처하지 말고 측정 조건과 변경 전후 수치를 함께 남기세요. 재현 가능한 기록이 포트폴리오의 기술적 신뢰도를 만듭니다.

포트폴리오라는 말 자체도 단순 작품 모음보다 선별과 표현의 맥락을 포함합니다. 포트폴리오의 용어적 배경을 참고하면 프로젝트 수를 늘리는 것보다 대표 작업의 의도와 성과를 구조화하는 편이 왜 중요한지 이해하기 쉽습니다.

다음으로 정적 콘텐츠와 상호작용의 경계를 다시 그립니다

HTML을 기본값으로 두고 필요한 곳만 활성화합니다

측정이 끝나면 페이지를 콘텐츠 영역과 상호작용 영역으로 나눕니다. 자기소개, 경력, 기술 스택, 프로젝트 본문은 서버나 빌드 시점에 완성된 HTML로 보내고, 필터·검색·코드 데모처럼 입력에 반응하는 부분에만 JavaScript를 적용합니다. 이 방식은 자바스크립트를 배제하는 유행이 아니라 실패해도 핵심 정보가 남는 점진적 향상에 가깝습니다.

예를 들어 프로젝트 목록의 기술 태그 필터는 작은 독립 모듈로 충분합니다. 카드 전체를 클라이언트에서 다시 렌더링하기보다 HTML에 의미 있는 목록을 먼저 출력하고, 선택된 태그에 따라 숨김 상태와 결과 개수만 갱신할 수 있습니다. 상세 페이지 이동도 기본 링크를 유지하면 검색 엔진, 키보드 사용자, 느린 네트워크 모두에게 안정적입니다.

1. 페이지별로 JavaScript가 꺼졌을 때 사라지는 정보를 표시합니다.
2. 콘텐츠 출력과 사용자 입력 처리를 별도 컴포넌트로 분리합니다.
3. 탭, 대화상자, 펼침 영역은 네이티브 요소로 대체 가능한지 검토합니다.
4. 필요한 상호작용만 지연 로딩하고 오류 발생 시 기본 링크로 돌아가게 합니다.

브라우저 기능도 빠르게 성숙하고 있습니다. View Transition API는 문서와 화면 상태 사이의 전환을 구현할 수 있으며 일부 기능은 최신 브라우저 범위에서 넓게 사용할 수 있게 됐습니다. 다만 MDN의 호환성 정보를 기준으로 확인하고, 지원되지 않는 환경에서는 애니메이션 없이 이동하도록 설계해야 합니다.

디자인 효과는 기능과 분리해 적용합니다

부드러운 화면 전환이나 스크롤 효과는 인상적이지만 콘텐츠 접근의 전제 조건이 되어서는 안 됩니다. CSS와 웹 표준 API로 효과를 추가하되 prefers-reduced-motion 설정을 존중하고, 애니메이션이 실행되지 않아도 동일한 정보와 탐색 순서를 제공하세요. 이런 세부 설계가 디자인 감각과 소프트웨어 품질을 함께 보여줍니다.

그다음 최신 런타임은 기능 자랑보다 유지보수 증거로 씁니다

JavaScript와 PHP의 변화는 작은 실험으로 검증합니다

최신 기술을 포트폴리오에 넣는 목적은 새 문법을 진열하는 데 있지 않습니다. 현재 Node.js 24 계열은 장기 운영에 적합한 릴리스 흐름 안에서 사용되고 있으며, 공식 Node.js 24 아카이브에는 버전별 런타임과 npm 정보가 제공됩니다. 프로젝트에는 사용 버전을 고정하고 설치부터 테스트까지 같은 결과가 나오는지 보여주는 편이 좋습니다.

PHP 프로젝트도 같은 원칙으로 접근합니다. PHP 8.5에는 URI 확장, 파이프 연산자, 반환값 누락을 경고하는 속성 등 유지보수성을 높이는 기능이 포함됐습니다. PHP 8.5 공식 변경 내용을 확인한 뒤, 레거시 Zend Framework 프로젝트 전체를 성급하게 바꾸기보다 URL 처리나 데이터 변환처럼 경계가 분명한 코드부터 호환성 테스트를 만드는 것이 안전합니다.

• 런타임 고정: 프로젝트 파일과 CI에서 Node.js·PHP 버전을 일치시킵니다.
• 의존성 감사: 직접 쓰지 않는 패키지와 중복 기능을 찾아 제거 후보로 분류합니다.
• 작은 현대화: 한 모듈을 선택해 새 API 적용 전후의 코드량과 테스트 결과를 비교합니다.
• 회귀 방지: 정적 분석, 단위 테스트, 브라우저 테스트를 자동 실행합니다.
• 지원 범위: 최신 기능을 쓰는 이유와 폴백 정책을 README에 명시합니다.

새 버전 적용은 그 자체로 성과가 아닙니다. 배포 실패율, 취약한 의존성 수, 테스트 시간처럼 유지보수 지표가 좋아졌을 때 프로젝트 사례로 가치가 생깁니다.

앞으로의 개발자 포트폴리오는 사용한 도구 목록보다 선택의 근거를 더 엄격하게 평가받을 가능성이 큽니다. 생성형 도구가 기본 코드를 빠르게 만드는 환경에서는 어떤 기능을 채택했고 무엇을 제외했는지, 오류와 호환성을 어떻게 검증했는지가 개인의 판단력을 드러냅니다. 포트폴리오의 구성 의미처럼 선별된 결과와 맥락을 함께 제시해야 기술 이력도 하나의 이야기로 읽힙니다.

마지막으로 한 페이지를 교체해 변화의 기록을 남깁니다

프로젝트 상세 페이지 하나로 일주일 실험을 시작합니다

전체 사이트 개편은 범위가 커서 전후 차이를 판단하기 어렵습니다. 방문이 잦거나 설명이 중요한 프로젝트 상세 페이지 하나를 골라 작은 실험을 진행하세요. 기존 화면을 보존한 브랜치를 만든 뒤 제목, 역할, 문제, 해결 과정, 수치로 확인된 결과가 서버 렌더링 HTML에 먼저 나타나도록 구조를 바꿉니다.

그다음 갤러리 전환, 코드 복사, 데모 옵션처럼 실제 입력이 필요한 부분만 독립 JavaScript로 붙입니다. 전환 효과는 지원 브라우저에서만 강화하고 기본 탐색은 링크로 남깁니다. 변경 전후에 같은 기기와 네트워크 조건을 사용하면 번들 감소가 로딩 시간과 조작 반응에 어떤 영향을 주었는지 솔직하게 설명할 수 있습니다.

1. 첫날: 현재 페이지의 스크린샷, 번들 용량, 주요 성능 수치를 저장합니다.
2. 둘째 날: 핵심 콘텐츠를 시맨틱 HTML로 옮기고 제목 계층과 링크 문맥을 다듬습니다.
3. 셋째 날: 필수 상호작용만 모듈로 분리하고 JavaScript 실패 상태를 시험합니다.
4. 넷째 날: 키보드, 작은 화면, 느린 네트워크, 모션 감소 환경을 검사합니다.
5. 다섯째 날: 변경 이유와 포기한 대안, 측정 결과를 프로젝트 설명에 추가합니다.

설명에는 “가벼워졌다”는 표현만 쓰지 말고 초기 JavaScript가 몇 KB 줄었는지, 상호작용 가능 시점이 어떻게 달라졌는지, 어떤 브라우저까지 확인했는지를 적습니다. 수치가 기대만큼 좋아지지 않았다면 이미지 용량이나 외부 폰트 등 다음 병목도 함께 공개하세요. 완벽해 보이는 사례보다 측정하고 수정할 줄 아는 개발자라는 인상을 줍니다.

지금 바로 할 행동은 프로젝트 상세 페이지 하나에서 JavaScript를 차단한 채 새로고침하는 것입니다. 읽을 수 없는 핵심 문장과 작동하지 않는 기본 링크를 세 개만 메모하고, 그중 첫 번째 항목을 HTML 기본 기능으로 바꾸는 커밋을 오늘 남겨보세요.