본문 바로가기
2주차

Vanilla JS와 React (Vanilla JS는 언제 쓰는건가?)

by cpor 2025. 4. 25.

 

 

 

 

안녕하세요! ! 36기 YB 한승우입니다 😄  

React, Vue와 같은 프레임워크가 대세인 지금, 여전히 Vanilla JS로 웹 서비스를 개발하는 기업이 존재합니다.

단순히 기술이 오래되었기 때문이 아니라, 지금도 상황에 따라 Vanilla JS가 더 합리적인 선택이 되는 경우가 있기 때문입니다.

이 글에서는 Vanilla JS와 React의 구조적 차이부터 실제 적용 맥락까지 짚어보며, 왜 어떤 팀은 여전히 React 대신 순수 JavaScript를 선택하는가에 대한 이야기를 다뤄보려 합니다!! 🔥🔥

 

 

 

 

1. Vanilla JS는 뭘까?

  a. 정의와 개념

Vanilla JS는 아무런 프레임워크나 라이브러리를 사용하지 않고 브라우저가 기본적으로 제공하는 API만을 사용하는 순수한 JavaScript를 의미합니다.
<!-- 버튼 클릭 시 텍스트 변경 예시 -->
<button id="myBtn">클릭하세요</button>
<p id="text">Hello!</p>
<script>
  document.getElementById("myBtn").addEventListener("click", function() {
    document.getElementById("text").textContent = "안녕하세요!";
  });
</script>

 

 

"Vanilla JS is not a framework. It's just plain JavaScript."


    • DOM API 직접 제어: document.querySelector(), addEventListener(), classList.add() 등 브라우저 내장 객체와 메서드를 통해 UI 조작
    • 브라우저 렌더링과 밀접: React의 Virtual DOM 없이 실제 DOM에서 직접 변경 작업을 수행하므로, 렌더링 트리거 방식이나 reflow/repaint 같은 브라우저 동작에 대한 이해가 중요함
    • 불필요한 추상화 없음: 프로젝트 구조나 상태 관리를 프레임워크가 대신해주지 않기 때문에, 로직의 흐름이 명확히 드러남
    • 브라우저 환경에 최적화: 라이브러리 의존 없이 브라우저 성능 그대로 사용 가능

 

 

2. 그 뒤에 있었던 jQuery…

  a. 등장 배경

jQuery는 2006년 등장한 DOM 조작 라이브러리입니다.

 

당시에는 브라우저마다 DOM API 차이가 컸고, 이벤트 처리 방식도 제각각이었습니다. jQuery는 이러한 문제를 크로스 브라우징 통일성이라는 강력한 무기로 해결했습니다. 또한 당시 브라우저 간 호환 문제를 해결하고 간결한 문법을 제공하며 웹 개발의 표준처럼 사용되었습니다.

// jQuery 버전
$('#myBtn').click(function() {
  $('#text').text('안녕하세요!');
});

 

  b. 현재의 위치

    • ES6 이후 문법(화살표 함수, 클래스, 모듈 등)의 도입과 브라우저 호환성 개선으로 jQuery의 역할이 줄어듬
    • React, Vue 같은 컴포넌트 기반 프레임워크의 등장으로 인기 하락
    • document.querySelector, fetch, classList 등 네이티브 API가 풍부해져 jQuery 의존도가 낮아짐
    • 모듈 단위 구성과 컴포넌트 기반 아키텍처의 부재로, 대형 SPA 구조에는 부적합

그러나 레거시 프로젝트나 단일 기능 웹페이지에서는 여전히 강력한 도구로 남아 있습니다.

 

 

3. React의 탄생 배경

  a. 복잡한 UI 상태 관리의 필요성

2010년대 초반 Facebook은 News Feed나 채팅 같은 컴포넌트를 효율적으로 업데이트할 수 있는 구조가 필요했습니다.

기존 방식은 데이터가 바뀔 때마다 DOM을 수동으로 업데이트해야 하므로, 상태 관리가 점점 복잡해졌습니다.

React는 이 문제를 해결하기 위해 등장했습니다. 핵심은 다음과 같습니다.

UI = f(state) 라는 함수형 선언적 패러다임
상태(state)가 바뀌면 컴포넌트가 다시 렌더링됨

  b. Virtual DOM과 선언적 렌더링

React의 핵심은 Virtual DOM입니다. 상태가 변경되면 가상의 DOM 트리를 구성하고, 이전 트리와 비교하여 실제 DOM에 최소한의 변경만 적용합니다.

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <p>{count}번 클릭함</p>
      <button onClick={() => setCount(count + 1)}>+1</button>
    </div>
  );
}

 

React는 위 코드를 바탕으로 UI를 재렌더링하지만, 실제 DOM 조작은 최소화합니다.

 

 

4. React의 장점과 단점 

 

React는 문제를 잘 정의하고, 해결하는 프레임워크다. 하지만 모든 문제에 적합하지는 않다.


React는 컴포넌트 단위 구조, Virtual DOM, 상태 관리 등의 특성을 바탕으로 대규모 프로젝트나 협업에 유리합니다.

또한 UI를 재사용 가능하게 구성할 수 있고, 선언형 렌더링 방식 덕분에 코드 가독성도 높습니다. React 생태계(Redux, Next.js 등)가 잘 갖춰져 있어 확장성도 좋습니다.

 

그러나 초기 세팅이 복잡하고, 간단한 프로젝트에는 과한 선택이 될 수 있습니다.

useMemo, useCallback 등을 잘못 사용하면 오히려 성능이 저하되기도 합니다. 또한 프레임워크가 아니라 라이브러리이므로 구조에 대한 책임은 개발자에게 있습니다.

 

반면, Vanilla JS는 가볍고 빠르며 초기 설정 없이 바로 개발할 수 있는 장점이 있습니다. 특히 정적 페이지나 단순한 인터랙션이 필요한 서비스에서는 오히려 React보다 적합할 수 있습니다.

 

하지만 구조적 한계가 분명합니다. 상태 관리와 뷰의 연결이 분리되지 않아 코드가 쉽게 엉킬 수 있으며, 재사용성이나 협업 효율성 면에서는 React에 미치지 못합니다.

 

 

  a. 장점

  • 컴포넌트화: UI를 재사용 가능한 단위로 나눠 유지보수성, 테스트 용이성 증가
  • Virtual DOM: DOM diffing 알고리즘으로 성능 개선
  • Hooks API: 상태관리(useState), 생명주기 관리(useEffect), 커스텀 로직 분리(useCustomHook) 가능
  • 생태계: TypeScript, Redux, Next.js, Vite 등과 궁합이 좋음

 

  b. 단점

  • 렌더링 최적화 필요: 불필요한 렌더링 방지를 위한 React.memo, useCallback 최적화 필요
  • SSR/CSR 복잡성: SEO 문제를 해결하기 위해 Next.js 등의 도구를 함께 사용해야 함
  • 설정 복잡성: 프로젝트 세팅(Webpack, Babel, ESLint 등) 이 복잡할 수 있음
// 불필요한 재렌더링 방지를 위한 최적화
const Button = React.memo(({ onClick }) => {
  return <button onClick={onClick}>클릭</button>;
});

 

 

 

5. Vanilla JS의 장점과 단점

 

Vanilla JS는 빠르고 강력하지만, 설계 철학이 없으면 유지보수가 어렵다.


 

Vanilla JS는 가볍고 빠르며, 추가 도구 없이 바로 사용 가능하다는 점이 가장 큰 강점입니다. 단일 페이지 콘텐츠, 저사양 환경, 빠른 배포가 필요한 경우 매우 유리합니다. 디버깅도 간단하고, 브라우저 API만으로도 대부분의 기능을 구현할 수 있습니다.

 

하지만 구조적 설계가 어려워, 프로젝트가 커지면 유지보수가 힘들어집니다. 상태와 UI의 분리가 명확하지 않아 버그 발생 가능성이 높고, 재사용성과 일관성 확보가 어렵습니다. 협업 시에도 코드 관리가 불편할 수 있습니다.

 

즉, Vanilla JS는 작고 단순한 프로젝트에 적합하지만, 복잡하고 장기적인 서비스에는 구조화된 프레임워크가 더 효과적입니다.

 

 

 

a. 장점

  • 빠른 로딩: 초기 렌더에 React보다 훨씬 가볍고 빠름 (HTML + JS만 로드됨)
  • 브라우저 친화적: 브라우저 API에 직접 접근하므로, 제어력이 높고 디버깅도 간편
  • 도구 불필요: Babel, Webpack 없이 순수한 JS 파일 하나로 끝남

 

b. 단점

  • 상태-뷰 분리 미약: 데이터와 UI 로직이 섞이기 쉬움
  • 규모 확장 어려움: 상태 분리, 모듈 관리, 테스트 체계 등 프레임워크의 구조적 지원 부족
  • 코드 중복: 유사한 UI 구성 시 재사용 어려움
// 상태와 뷰 로직이 섞인 예
let count = 0;
const p = document.querySelector('#count');
const btn = document.querySelector('#plus');
btn.addEventListener('click', () => {
  count++;
  p.textContent = `${count}번 클릭함`;
});

 

 

 

6. 그럼에도 어떤 회사 / 어떤 프로젝트에서는 Vanilla JS를 사용할 때가 있다!

 

네.. 바로 제가 단기 인턴 근무중인 회사의 이야기인데요..!

React가 대세인 시대지만, 현재 인턴으로 참여하여 사내 초/중/고 AIDT 교과서를 만드는 프로젝트에서는 여전히 Vanilla JS로 프로젝트를 진행 중 이었습니다.

 

간단하게 프로젝트를 말씀드리면, 이 프로젝트는 약 수백 개의 교과서 페이지를 다루며, 각 페이지가 서로 독립된 정적 HTML 파일로 구성되어 있습니다. 프로젝트 상 SPA 구조나 라우팅이 불필요하고, 오히려 그런 구조가 관리와 배포에 있어 부담이 되기 때문입니다.

 

또한 사용 환경을 고려했을 때, 초중고 학생들이 사용하는 저사양 교육용 디바이스에서는 React의 초기 번들 크기와 hydration 비용이 상당한 부하로 작용할 수 있습니다. 이처럼 제한된 환경에서는 최대한 가볍게, 빠르게 로드되는 구조가 필요하며, Vanilla JS가 가장 잘 맞다고 판단한 것 같습니다.

 

개발 및 배포 측면에서도 Vanilla JS는 React보다 효율적이라고 생각이 드는데요!

Vanilla JS는 별도의 빌드나 패키징 없이 HTML + JS 파일만으로 빠르게 수정하고 배포할 수 있기 때문에, 콘텐츠가 자주 변경되거나 빠르게 적용되어야 하는 프로젝트에 이상적이라고 생각이 듭니다.

 

AIDT 교과서는 단순한 인터랙션(예: 입력 필드 저장, 체크박스 상태 유지 등)만 구현하면 되는 페이지가 대부분이기 때문에, 굳이 React를 도입하지 않아도 충분한 요구 사항을 만족할 수 있었습니다.

 

즉, 이 프로젝트는 복잡한 프레임워크보다 단순하고 직관적인 구조, 가벼운 성능, 빠른 피드백 루프가 더 중요한 상황이었고, 그에 가장 잘 맞는 도구가 바로 Vanilla JS였습니다.

 

 

a. 편한 React를 놔두고 왜 Vanilla JS를 사용하는지?

 

AIDT 교과서 프로젝트는 약 수천 개 페이지에 달하는 콘텐츠가 정적 구조로 배포됩니다.

결국 사내에서는 다음과 같은 이유로 React 대신 Vanilla JS를 채택하게 되었습니다.

  • 페이지 간 독립성: 각각의 페이지는 SPA처럼 라우팅되지 않고, 독립된 HTML 파일로 존재합니다.
  • 학습 환경 제약: 초중고용 교육 장비(저사양 태블릿, 키오스크 등)에서는 React의 초기 번들링, Hydration 비용이 부담이 됩니다.
  • 개발/배포 속도: 번들러 없이 HTML + JS 파일만으로 즉시 배포 가능하다는 장점이 매우 큽니다.

 

  b. 때때로는 React보다 Vanilla JS가 낫다

1. 단순한 인터랙션 (입력 확인, 체크박스, 단답 저장 등)만으로 구성된 콘텐츠
2. 프레임워크를 도입하기 어려운 조건 (서버 설정, CI/CD 제한 등)
3. 콘텐츠 수정 주기가 짧고 많을 때 → 빠르게 JS만 고치면 되는 Vanilla JS가 유리

 

 

7. 마지막으로 한마디,,,,

  a. 다들 상황에 맞는 스택을 사용하면 좋을 것 같아요👍👍 

다른 개발자 분들과 함께 사내 프로젝트를 진행하면서 기술 스택을 고를 때는 유행보다는 문제 해결에 적합한 도구인지를 먼저 고민해야 한다는 것을 깨달았습니다,,

 

또한 서비스의 목적, 개발 리소스, 유지보수 기간, 사용자 환경 등을 기준으로 상황에 맞는 스택을 판단하는 것이 프로젝트의 핵심을 깨닫게 되었습니다!

 

React는 구조화와 협업에 강하고, Vanilla JS는 빠른 실행과 단순성에 강합니다!

 

간단하게 위 한줄만 알아간다면 언젠가 써먹을 일이 있지 않을까요?!

 

  b. 혹시라도 내가 간 회사에서 Vanilla JS를 사용 중이라면…

여러분도 어느 회사든 어떤 프로젝트든 어디선가 Vanilla JS를 사용하게 될 수도 있습니다..! 

특히 정부기관, 교육 콘텐츠, 공공 프로젝트 등에서는 보안성, 가벼움, 환경 제약 등으로 인해 여전히 Vanilla JS가 실전 무기로 쓰이고 있다고 하는데요!

 

이 글을 통해, 여러분이 기술 선택에 대한 관점을 넓히고, React와 Vanilla JS의 장단점을 깊이 있게 이해하는 데 도움이 되었기를 바랍니다 😄

 

 

📚 참고자료

'2주차' 카테고리의 다른 글

React 전역 상태 관리: Context API vs Recoil, Zustand, Jotai  (0) 2025.04.25
반응형 프로그래밍이 무엇일까요?  (1) 2025.04.25
JavaScript 이벤트 전파  (0) 2025.04.24
브라우저 저장소 ( WebStorage, cookie )  (0) 2025.04.24
협업과 정확성을 위한 주석 JSDoc  (0) 2025.04.23

관련글

티스토리툴바