자바스크립트 프레임워크와 바닐라 JS, 개발자 포트폴리오의 새 기준

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

채용 담당자가 개발자 포트폴리오를 열었는데 첫 화면이 뜨기까지 오래 걸리고, 프로젝트 설명보다 로딩 애니메이션을 먼저 보게 된다면 어떤 인상을 받을까요? 화려한 프레임워크를 썼다는 사실보다 빠르게 핵심을 전달하고 실제 문제를 해결하는 능력이 더 중요해지고 있습니다.

최근 자바스크립트 생태계에서는 프레임워크 중심 개발과 함께 바닐라 JS, 웹 컴포넌트, 점진적 향상이 다시 주목받고 있습니다. 이것은 단순한 복고 유행이 아니라 성능 비용, 유지보수 난도, 인공지능 검색과 접근성까지 고려한 변화입니다. 개발자 포트폴리오 역시 기술 이름을 전시하는 공간에서 선택의 근거를 증명하는 프로젝트로 이동하고 있습니다.

프레임워크를 많이 쓸수록 뛰어나 보인다는 공식의 변화

기술 목록보다 설계 판단을 읽는 포트폴리오

React, Vue, Angular 같은 자바스크립트 프레임워크는 복잡한 상태 관리와 컴포넌트 재사용에 강합니다. 여러 화면이 같은 데이터를 공유하거나 사용자 입력에 따라 인터페이스가 계속 바뀌는 프로젝트라면 프레임워크가 개발 속도와 일관성을 높여 줍니다. 문제는 작은 개인 소개 페이지에도 동일한 구조를 적용하면서 발생합니다.

텍스트와 프로젝트 카드가 중심인 개발자 포트폴리오에 대규모 상태 관리 도구와 무거운 클라이언트 실행 코드를 넣으면 방문자가 얻는 가치보다 기술적 비용이 커질 수 있습니다. 이제는 “무엇을 사용했는가”만큼 왜 그 도구가 이 규모에 적합했는가가 평가 포인트가 됩니다. 포트폴리오의 기본 개념은 지식백과의 Portfolio 정의에서도 확인할 수 있듯 결과물을 모아 역량을 보여 주는 데 있습니다. 도구 자체가 결과물을 가려서는 곤란합니다.

예를 들어 날씨 대시보드는 필터, 비동기 데이터, 오류 상태와 캐싱 전략을 설명하기 좋아 프레임워크 프로젝트로 적합합니다. 반면 이력과 작업물 몇 개를 보여 주는 사이트는 서버에서 완성된 HTML이나 바닐라 JS만으로도 충분할 수 있습니다. 서로 다른 규모의 두 프로젝트를 제시하고 선택 이유를 설명하면 한 가지 도구만 반복해서 사용한 포트폴리오보다 판단력이 선명하게 드러납니다.

• 프레임워크가 유리한 경우: 복잡한 상태, 반복되는 UI, 팀 단위 확장, 실시간 상호작용이 핵심일 때
• 바닐라 JS가 유리한 경우: 콘텐츠 전달, 빠른 초기 표시, 적은 의존성, 긴 유지 기간이 중요할 때
• 평가자가 확인하는 지점: 유행을 따라갔는지보다 요구사항과 비용을 비교했는지
• 포트폴리오에 남길 기록: 선택한 기술뿐 아니라 검토 후 제외한 대안과 그 이유

프로젝트 설명에 “React로 제작”이라고만 쓰지 말고, 상태의 종류와 화면 간 데이터 흐름 때문에 React를 선택했다고 적어 보세요. 한 문장의 근거가 긴 기술 배지 목록보다 강한 신뢰를 만듭니다.

바닐라 JS의 재평가와 웹 플랫폼의 성장

라이브러리가 맡던 일을 브라우저가 직접 처리한다

바닐라 JS가 다시 언급되는 배경에는 브라우저 기본 기능의 성숙이 있습니다. 사용자 정의 요소를 만드는 웹 컴포넌트, 지연 로딩, 관찰자 API, 모듈 시스템, CSS의 향상된 레이아웃과 애니메이션 기능 덕분에 예전에는 외부 라이브러리가 필요했던 작업을 표준 기술만으로 구현할 수 있습니다. 의존성이 줄어들면 설치와 업데이트에 드는 시간도 함께 줄어듭니다.

특히 개발자 포트폴리오는 몇 년 동안 온라인에 남아 있을 가능성이 큽니다. 프레임워크의 주요 버전이 바뀌거나 플러그인의 지원이 종료되면 작은 문구 하나를 수정하기 위해 전체 빌드 환경부터 손봐야 할 수 있습니다. 반면 HTML, CSS, 자바스크립트 표준을 중심에 두면 새로운 도구로 이전하기 쉽고 코드가 어떤 원리로 작동하는지도 직접 보여 줄 수 있습니다.

그렇다고 바닐라 JS가 언제나 코드가 적고 간단하다는 뜻은 아닙니다. 상태가 복잡해지면 직접 만든 이벤트 규칙과 DOM 갱신 코드가 사실상 미완성 프레임워크처럼 변할 수 있습니다. 여러분의 프로젝트에서 모달 하나와 필터 두 개만 필요한가요, 아니면 로그인 상태와 권한별 화면, 실시간 데이터까지 다뤄야 하나요? 이 질문에 대한 답이 기술 선택의 출발점입니다.

웹 컴포넌트가 만드는 중간 지대

웹 컴포넌트는 프레임워크와 바닐라 JS 사이의 실용적인 선택지입니다. 프로젝트 카드, 경력 타임라인, 코드 예제 같은 요소를 재사용 가능한 사용자 정의 태그로 만들면서 특정 프레임워크에 대한 결합을 낮출 수 있습니다. 디자인 시스템이나 여러 사이트에서 공유할 UI가 있다면 작은 단위부터 적용해 보는 방식이 효과적입니다.

1. 먼저 자바스크립트가 없어도 읽을 수 있는 HTML 구조를 작성합니다.
2. 필터링이나 펼치기처럼 실제 가치가 있는 상호작용만 자바스크립트로 추가합니다.
3. 두 번 이상 반복되는 UI는 함수 또는 웹 컴포넌트로 분리합니다.
4. 상태 흐름이 복잡해지는 시점에 프레임워크 도입 비용을 다시 계산합니다.
5. 완성 후 자바스크립트를 끈 상태와 느린 네트워크 환경에서도 핵심 콘텐츠가 보이는지 확인합니다.

이 과정을 프로젝트 문서에 기록하면 단순히 작은 사이트를 만든 것이 아니라 점진적 향상과 유지보수성을 고려한 소프트웨어 설계를 했다는 메시지를 전달할 수 있습니다. 결과물을 체계적으로 선별하고 제시한다는 의미는 포트폴리오 용어 설명과도 맞닿아 있습니다. 모든 코드를 보여 주기보다 판단을 대표하는 코드와 결과를 골라야 합니다.

AI 검색과 성능 지표가 바꾸는 프로젝트 공개 방식

사람과 기계가 함께 읽을 수 있는 구조

포트폴리오의 방문자는 더 이상 사람만이 아닙니다. 검색 엔진과 자동화된 분석 도구가 제목, 프로젝트 역할, 사용 기술, 성과를 먼저 읽고 요약할 수 있습니다. 첫 화면이 자바스크립트 실행 뒤에야 완성되거나 중요한 설명이 캔버스와 애니메이션 안에만 존재하면 검색과 접근성 양쪽에서 불리해질 가능성이 있습니다.

따라서 핵심 경력과 프로젝트 설명은 의미가 분명한 HTML로 제공하고, 동적인 효과는 그 위에 얹는 편이 좋습니다. 프로젝트 이름에는 제목 태그를 사용하고, 담당 역할과 성과는 문장으로 명시하며, 링크 텍스트도 “자세히 보기”보다 “재고 관리 프로젝트 기술 문서”처럼 목적을 드러내야 합니다. 이것은 SEO 장식이 아니라 정보를 해석하기 쉽게 만드는 기본 설계입니다.

성능 역시 단순한 점수 경쟁에서 사용자 경험의 증거로 바뀌고 있습니다. 큰 자바스크립트 번들, 사용하지 않는 패키지, 고해상도 영상이 초기 화면을 막으면 방문자는 대표 프로젝트를 보기 전에 이탈할 수 있습니다. 반대로 빠른 초기 표시와 안정적인 레이아웃을 구현하고 측정 전후 수치를 제시하면 성능 개선 능력 자체가 하나의 포트폴리오 프로젝트가 됩니다.

기술 선택을 수치와 사례로 증명하는 방법

“바닐라 JS라서 빠르다” 또는 “프레임워크라서 생산성이 높다”는 표현만으로는 부족합니다. 같은 페이지의 구현 전후 번들 크기, 초기 표시 시간, 상호작용 준비 시간, 의존성 개수처럼 확인 가능한 항목을 함께 제시해야 합니다. 팀 프로젝트라면 개발 기간과 재사용한 컴포넌트 수, 오류 감소 사례도 중요한 근거가 됩니다.

• 초기 로딩: 첫 화면에 필요하지 않은 코드를 지연시키고 폰트와 이미지 용량을 관리합니다.
• 상호작용 품질: 버튼을 눌렀을 때 즉시 반응하는지, 키보드만으로 기능을 사용할 수 있는지 확인합니다.
• 콘텐츠 구조: 프로젝트별 문제, 역할, 해결 방법, 결과가 HTML 본문에 명확히 존재하도록 작성합니다.
• 유지보수 비용: 패키지 수, 업데이트 빈도, 빌드 절차를 문서로 남깁니다.
• 실험 기록: 프레임워크 버전과 바닐라 버전을 작은 기능으로 구현해 차이를 측정합니다.

포트폴리오에서 가장 설득력 있는 성능 수치는 최고 점수가 아니라 변화의 폭입니다. 무엇을 제거하거나 바꿨고 사용자의 대기 시간이 어떻게 달라졌는지 함께 제시하세요.

한 가지 유용한 구성은 프로젝트 상세 페이지에 “기술 결정 기록”을 넣는 것입니다. 요구사항, 후보 기술, 선택 기준, 예상 비용, 실제 결과를 짧은 표로 공개하면 평가자는 완성 화면 뒤의 사고 과정을 볼 수 있습니다. 포트폴리오가 작품과 자료를 목적에 맞게 구성하는 매체라는 점은 관련 지식백과 설명에서도 참고할 수 있습니다.

콘텐츠형 포트폴리오와 앱형 포트폴리오는 선택이 달라야 한다

현재 프로젝트에 맞는 경계선을 찾는 질문

앞으로의 개발자 포트폴리오는 특정 프레임워크를 사용했느냐보다 필요한 만큼만 복잡하게 만들었느냐로 평가받을 가능성이 큽니다. 프레임워크를 능숙하게 사용하는 역량과 웹 표준을 깊이 이해하는 역량은 서로 대립하지 않습니다. 좋은 포트폴리오는 두 능력을 프로젝트 성격에 맞춰 배치합니다.

선택이 어렵다면 기능을 화면 수가 아니라 상태의 수로 세어 보세요. 열림과 닫힘 정도의 지역 상태만 있다면 바닐라 JS가 충분할 수 있지만, 여러 화면에서 공유하는 사용자 정보와 비동기 데이터, 낙관적 업데이트가 있다면 프레임워크가 안전합니다. 채용 공고의 기술 스택도 고려해야 하지만, 단지 키워드를 넣기 위해 불필요한 구조를 추가하면 코드 검토 과정에서 오히려 약점이 드러날 수 있습니다.

또한 하나의 포트폴리오 안에서 모든 프로젝트가 같은 방식일 필요는 없습니다. 메인 페이지는 정적인 HTML 중심으로 빠르게 제공하고, 별도의 데모 앱에서는 React나 Vue로 복잡한 상태와 테스트 전략을 보여 줄 수 있습니다. 이 조합은 방문자에게 빠른 탐색 경험을 제공하면서 지원 직무에 필요한 프레임워크 역량도 증명합니다.

1. 콘텐츠 비중을 확인합니다. 경력과 글, 작업 설명이 중심이라면 서버에서 완성된 HTML과 최소한의 자바스크립트를 우선합니다.
2. 상태 복잡도를 그립니다. 데이터가 어디에서 생성되고 어떤 화면으로 이동하는지 선으로 연결해 봅니다.
3. 6개월 뒤 수정 비용을 예상합니다. 빌드 도구와 패키지를 잊은 상태에서도 작은 변경을 안전하게 할 수 있는지 따집니다.
4. 채용 직무와 연결합니다. 프론트엔드 앱 직무라면 테스트와 상태 관리가 드러나는 데모를, 풀스택 직무라면 API와 데이터 흐름을 강조합니다.
5. 결정 근거를 공개합니다. 선택하지 않은 기술의 단점까지 기록하면 과장되지 않은 전문성이 생깁니다.

두 유형의 개발자에게 권하는 서로 다른 구성

글, 오픈소스 활동, 소규모 도구와 경력을 빠르게 보여 주려는 개발자라면 바닐라 JS 또는 정적 HTML 중심의 콘텐츠형 포트폴리오가 잘 맞습니다. 기본 화면은 자바스크립트 없이 읽히게 만들고 검색, 테마 전환, 프로젝트 필터처럼 가치가 분명한 기능만 추가하세요. 남은 시간은 프로젝트 설명과 코드 문서, 접근성 개선에 투자하는 편이 효과적입니다.

반대로 대시보드, 협업 서비스, 실시간 편집기처럼 복잡한 제품 경험을 증명해야 하는 개발자라면 프레임워크 기반의 앱형 포트폴리오 프로젝트를 선택하세요. 상태 관리와 오류 처리, 테스트, 캐싱, 컴포넌트 경계를 상세 페이지에서 보여 주되 소개 화면까지 무겁게 만들 필요는 없습니다. 콘텐츠를 전달하려는 개발자에게는 바닐라 JS 중심 구성을, 제품형 인터페이스 역량을 채용 담당자에게 보여 주려는 개발자에게는 프레임워크 데모와 가벼운 소개 사이트의 조합을 권합니다.