왜 React를 쓸까: 순수 JavaScript와 다른 선택지까지 포함해 다시 보는 trade-off

React는 이제 너무 익숙한 선택지처럼 보입니다.

새 프로젝트를 시작할 때도
채용 공고를 볼 때도
프론트엔드 스택을 논의할 때도

자연스럽게 전제처럼 등장하는 경우가 많습니다.

그래서 오히려 중요한 질문이 흐려질 때가 있습니다.

"우리는 왜 React를 쓰는가?"

이 질문은 생각보다 중요합니다. 어떤 기술이 널리 쓰인다는 사실과, 지금 우리 팀과 제품에 적합하다는 사실은 같은 말이 아니기 때문입니다.

실무에서 기술을 선택할 때는 단순히 "유명한가", "사람이 많이 쓰는가"만 보지 않습니다.

지금 해결하려는 문제는 무엇인가
순수 JavaScript로도 충분한가
다른 프레임워크가 더 단순한가
팀이 감당해야 할 학습 비용은 어느 정도인가
장기 유지보수와 채용 확장성은 어떤가

즉, React를 선택한다는 것은 단순히 UI 라이브러리 하나를 고르는 것이 아니라, 상태를 다루는 방식, 컴포넌트를 조합하는 방식, 생태계와 운영 방식을 함께 선택하는 일에 가깝습니다.

이 글에서는 아래 흐름으로 정리해보겠습니다.

순수 JavaScript로 만드는 방식은 어떤 장점이 있는지
React는 어떤 문제를 잘 푸는지
Vue, Svelte 같은 다른 선택지는 어떤 차이가 있는지
React를 쓸 때 감수해야 하는 비용은 무엇인지
결국 어떤 기준으로 기술을 선택하면 좋을지

한눈에 보면

먼저 짧게 정리하면 이렇습니다.

React는 UI를 컴포넌트와 상태 변화 중심으로 조직화하기 좋은 선택지입니다.
특히 화면 복잡도, 상태 공유, 팀 규모, 생태계 활용도가 커질수록 강점이 드러납니다.
반면 초반에는 학습해야 할 개념이 많고, 상태 관리나 렌더링 최적화 같은 책임을 팀이 직접 이해해야 한다는 비용도 있습니다.
작은 프로젝트나 단순 인터랙션이라면 순수 JavaScript나 더 작은 선택지가 더 단순할 수 있습니다.

즉, React는 "무조건 더 좋은 기술"이라기보다, 일정 수준 이상의 복잡도를 컴포넌트와 상태 중심으로 다루려는 팀에 특히 잘 맞는 선택지에 가깝습니다.

먼저, 순수 `JavaScript`로 만드는 방식은 왜 여전히 유효할까?

이 질문부터 꼭 봐야 합니다.

React를 설명할 때 자주 놓치는 점이 하나 있는데, 사실 많은 UI는 순수 JavaScript로도 충분히 만들 수 있다는 점입니다.

예를 들어:

작은 랜딩 페이지
인터랙션이 적은 마케팅 페이지
간단한 탭, 아코디언, 모달
내부 위젯 하나만 붙이는 경우

이런 경우라면 브라우저 API와 약간의 DOM 조작만으로도 충분할 수 있습니다.

const button = document.querySelector('#toggle-button');
const panel = document.querySelector('#panel');
 
button.addEventListener('click', () => {
  panel.classList.toggle('is-open');
});

이 방식의 장점은 분명합니다.

번들 크기가 작을 수 있고
러닝 커브가 낮고
추상화가 적어서 동작이 직접적으로 보이며
작은 요구사항에는 오히려 가장 단순할 수 있습니다

즉, React를 쓰지 않는 것이 곧 낡은 선택이라는 뜻은 아닙니다. 오히려 작은 문제에 더 직접적이고 효율적인 선택일 수도 있습니다.

그런데 왜 순수 `JavaScript`만으로는 점점 버거워질까?

문제는 화면과 상태가 커질 때입니다.

예를 들어 아래 요구가 붙기 시작하면 상황이 달라집니다.

여러 컴포넌트가 같은 상태를 공유해야 한다
리스트와 필터와 정렬과 폼 검증이 얽힌다
사용자 이벤트마다 서로 다른 UI가 연쇄적으로 바뀐다
화면이 커지면서 DOM 업데이트 흐름이 복잡해진다
팀원이 늘어나고 코드 수정 범위를 예측하기 어려워진다

이 시점부터는 단순 DOM 조작 코드가 점점 아래 형태로 바뀌기 쉽습니다.

어느 요소를 직접 바꾸는 코드가 여기저기 흩어지고
상태의 진짜 기준이 어디인지 흐려지고
한 기능 수정이 다른 UI에 어떤 영향을 줄지 예측하기 어려워집니다

즉, 순수 JavaScript의 문제는 기능 구현이 불가능하다는 게 아니라, 복잡한 UI를 구조적으로 유지하기가 점점 어려워진다는 점에 더 가깝습니다.

React는 정확히 어떤 문제를 푸는 걸까?

많은 사람이 React를 "컴포넌트 라이브러리"라고 설명합니다. 맞는 말이지만 충분하지는 않습니다.

내가 보기엔 React의 핵심은 아래 쪽에 더 가깝습니다.

UI를 상태의 결과로 보게 만들고
화면을 작은 컴포넌트 단위로 나누고
변화 이후의 UI를 다시 계산하는 방식으로 다루게 해주는 것

즉, React는 DOM을 직접 조작하는 코드 스타일보다, 지금 상태라면 UI는 어떤 모습이어야 하는가를 중심으로 사고하게 만듭니다.

예를 들어 체크박스 목록을 순수 JavaScript로 짜면:

클릭 이벤트를 연결하고
해당 DOM을 찾아 class를 바꾸고
카운트를 다시 계산하고
버튼 활성화 여부를 다시 바꾸는 흐름이 퍼질 수 있습니다

반면 React는 보통 이렇게 봅니다.

function TodoItem({ todo, onToggle }: Props) {
  return (
    <label>
      <input type="checkbox" checked={todo.completed} onChange={() => onToggle(todo.id)} />
      <span>{todo.text}</span>
    </label>
  );
}

이 방식에서는 핵심 질문이 바뀝니다.

DOM을 어떻게 바꿀까? 가 아니라
todo.completed가 true면 UI는 어떤 모습이어야 할까?

즉, React의 장점은 자동화 마법 그 자체보다, UI를 상태 중심으로 일관되게 조직하게 해주는 사고 모델에 더 가깝습니다.

React를 쓸 때 얻는 실질적인 장점

1. 상태와 UI의 관계를 더 예측 가능하게 만들기 쉽다

복잡한 화면일수록 "지금 이 화면이 왜 이런 상태인가?"를 추적하기 쉬워야 합니다.

React는 보통:

state
props
렌더링 결과

의 관계로 UI를 설명하게 만듭니다.

즉, 변경의 이유를 코드 상에서 더 추적하기 쉬운 편입니다.

2. 컴포넌트 단위로 역할을 나누기 좋다

화면이 커질수록 한 파일에 모든 DOM 조작을 적는 방식은 유지보수가 어려워집니다.

반면 React는:

버튼
리스트
카드
폼
모달

같은 UI를 컴포넌트 단위로 분리하고 조합하기 좋습니다.

이건 단순 재사용만의 문제가 아닙니다. 책임 분리와 변경 범위 제어에 더 가깝습니다.

3. 생태계가 매우 넓다

실무에서는 프레임워크 코어보다 그 주변이 더 중요할 때가 많습니다.

라우팅
서버 상태 관리
폼
데이터 패칭
서버 렌더링
테스트
디자인 시스템

React는 이 영역의 선택지가 매우 넓고, 레퍼런스도 많습니다.

즉, React를 쓴다는 것은 코어 하나만 쓰는 것이 아니라, 문제를 풀 수 있는 생태계 전체를 함께 활용할 수 있다는 뜻이기도 합니다.

4. 조직 확장과 채용 측면에서 설명하기 쉽다

기술 선택은 코드만의 문제가 아닙니다.

신규 인력이 구하기 쉬운가
참고 자료가 많은가
외부 라이브러리와 궁합이 좋은가
팀 내 공통 언어를 만들기 쉬운가

이런 질문까지 포함됩니다.

이 관점에서 React는 조직 운영 측면에서도 비교적 설명하기 쉬운 선택지입니다.

그렇다면 React의 단점은 무엇일까?

이제 중요한 부분입니다.

React는 강력하지만 공짜는 아닙니다.

1. 학습할 개념이 생각보다 많다

처음엔 단순히 컴포넌트만 배우면 될 것 같지만, 실제로는 점점 아래 개념이 따라옵니다.

state와 props
effect
리렌더링
memoization
controlled/uncontrolled
context
상태관리 라이브러리

즉, React는 단순 DOM 조작보다 초기에 머릿속에 넣어야 할 모델이 더 많습니다.

2. 선택지가 많아서 오히려 기준이 필요하다

이건 장점이자 단점입니다.

상태관리는 무엇을 쓸지
라우팅은 어떻게 할지
서버 상태는 무엇으로 다룰지
폴더 구조는 어떻게 가져갈지

선택지가 많다는 것은 유연하다는 뜻이지만, 동시에 팀이 기준 없이 들어가면 코드베이스가 쉽게 흔들릴 수 있다는 뜻이기도 합니다.

3. 렌더링 모델을 이해하지 않으면 오히려 더 헷갈릴 수 있다

React는 선언적이라서 쉬워 보이지만, 실제로는 내부 동작을 어느 정도 이해해야 안정적으로 쓸 수 있습니다.

예를 들어:

왜 리렌더링이 일어나는가
왜 memo가 필요할 때가 있는가
왜 effect가 꼬이는가

이걸 모르고 쓰면 오히려 "자동으로 해주겠지"라는 기대 때문에 더 헷갈릴 수 있습니다.

즉, React는 단순히 예쁜 문법이 아니라 그 나름의 실행 모델을 이해해야 제대로 활용할 수 있는 도구입니다.

4. 작은 문제에는 과할 수 있다

정말 작은 위젯 하나, 정적인 페이지 하나, 가벼운 인터랙션 하나만 필요한데도 React를 올리면:

빌드 환경
번들
상태 흐름
컴포넌트 구조

까지 함께 가져오게 됩니다.

즉, 문제 크기에 비해 도구가 과할 수 있습니다.

Vue나 Svelte 같은 다른 선택지는 어떤 차이가 있을까?

여기서 중요한 것은 "React vs 나머지"로 단순화하지 않는 것입니다.

Vue

Vue는 비교적 친절한 기본 구조와 템플릿 기반 문법이 강점입니다.

장점:

초반 진입이 비교적 부드럽고
템플릿이 직관적이며
반응성 모델이 꽤 명확합니다

단점 혹은 trade-off:

조직 확장성과 채용 시장을 크게 볼 때는 React보다 풀이 좁게 느껴질 수 있고
장기적으로는 팀이 어떤 추상화 스타일을 가져갈지 별도 기준이 필요합니다

즉, Vue는 "친절하게 정리된 기본기"가 장점이고, React는 "유연한 조합과 넓은 생태계"가 장점이라고 보는 편이 더 자연스럽습니다.

Svelte

Svelte는 더 가볍고 직관적인 경험을 줄 때가 많습니다.

장점:

문법이 비교적 간결하고
작은 프로젝트에서 생산성이 좋고
런타임 비용이 적게 느껴질 수 있습니다

단점 혹은 trade-off:

조직 차원의 레퍼런스와 채용 풀, 라이브러리 선택 폭은 React보다 제한적일 수 있고
팀 전체가 장기적으로 유지할 기준을 만들 때는 더 신중한 판단이 필요할 수 있습니다

즉, Svelte는 작은 팀과 빠른 개발에서 매력적일 수 있지만, 조직 확장과 생태계 활용도까지 같이 보면 React와는 다른 장단점 구조를 가집니다.

React vs 순수 JavaScript를 더 실무적으로 보면

이 비교는 보통 이렇게 요약할 수 있습니다.

순수 JavaScript가 더 나은 경우

문제 범위가 작을 때
상호작용이 단순할 때
빌드 환경 없이 빠르게 붙여야 할 때
장기적으로 커질 가능성이 낮을 때

React가 더 나은 경우

상태가 복잡하게 얽힐 때
여러 UI 조각이 함께 반응해야 할 때
팀 단위로 유지보수해야 할 때
공통 컴포넌트와 설계 자산을 축적해야 할 때
다른 도구와 생태계를 적극적으로 활용해야 할 때

즉, React는 "DOM을 더 잘 다루는 도구"라기보다, 복잡한 UI를 구조적으로 유지하려는 팀에게 더 적합한 도구라고 보는 편이 맞습니다.

결국 React를 선택할 때 무엇을 기준으로 봐야 할까?

내가 중요하다고 느끼는 질문은 아래와 같습니다.

이 제품은 상태와 인터랙션 복잡도가 얼마나 큰가?
지금은 작아도 장기적으로 구조가 커질 가능성이 있는가?
팀은 생태계의 선택지를 활용할 준비가 되어 있는가?
팀이 감당할 수 있는 학습 비용은 어느 정도인가?
채용, 온보딩, 협업까지 포함했을 때 어떤 선택이 더 현실적인가?

예를 들어:

작은 마케팅 페이지라면 순수 JavaScript나 더 가벼운 방식이 더 나을 수 있습니다
중간 규모의 서비스형 제품이라면 React가 점점 유리해질 가능성이 큽니다
팀이 친절한 기본 구조를 더 선호한다면 Vue가 더 잘 맞을 수 있습니다
작은 팀이 빠르게 실험한다면 Svelte도 좋은 선택이 될 수 있습니다

즉, 기술 선택은 결국 문제 크기, 조직 방향, 유지보수 전략을 함께 보는 일입니다.

그래서 나는 왜 React를 쓰는가

내 기준에서 React를 선택하게 되는 가장 큰 이유는 세 가지에 가깝습니다.

1. 상태와 UI 관계를 구조적으로 설명하기 좋다

UI가 복잡해질수록 "지금 왜 이런 상태인가"를 설명할 수 있어야 합니다. React는 이걸 state와 props 흐름으로 비교적 일관되게 설명하기 좋습니다.

2. 조합 가능한 설계를 만들기 좋다

컴포넌트 분리, 훅, 패턴, 프레임워크 조합까지 포함하면 장기적으로 구조를 성장시키기 좋은 편입니다.

3. 조직과 생태계까지 함께 보기 좋다

기술 자체만이 아니라:

인력 수급
참고 자료
도구 선택 폭
운영 모델

까지 포함하면, React는 실무적으로 꽤 설명하기 쉬운 선택지입니다.

물론 이것이 "React가 무조건 최고"라는 뜻은 아닙니다. 오히려 이 장점이 필요한 조건일 때 React가 더 빛난다고 보는 편이 맞습니다.

같이 보면 좋은 글

결론

React를 쓴다는 것은 단순히 인기 있는 라이브러리를 선택하는 일이 아니라, 복잡한 UI를 상태와 컴포넌트 중심으로 조직하고, 그 위에 넓은 생태계를 얹어가겠다는 선택에 가깝습니다.

짧게 정리하면:

작은 문제에는 순수 JavaScript나 더 가벼운 선택지가 더 적절할 수 있고
친절한 기본 구조를 원하면 다른 프레임워크가 더 잘 맞을 수도 있으며
React는 복잡도, 확장성, 생태계 활용도가 커질수록 강점이 커집니다

결국 중요한 것은 "React가 더 좋은가?"가 아니라, 지금 우리 문제와 조직 조건에서 React의 장점이 그 비용을 감수할 만큼 의미 있는가를 따지는 일이라고 생각합니다.

카테고리

자주쓰는 태그

왜 React를 쓸까: 순수 JavaScript와 다른 선택지까지 포함해 다시 보는 trade-off

한눈에 보면

먼저, 순수 `JavaScript`로 만드는 방식은 왜 여전히 유효할까?

그런데 왜 순수 `JavaScript`만으로는 점점 버거워질까?

React는 정확히 어떤 문제를 푸는 걸까?

React를 쓸 때 얻는 실질적인 장점

1. 상태와 UI의 관계를 더 예측 가능하게 만들기 쉽다

2. 컴포넌트 단위로 역할을 나누기 좋다

3. 생태계가 매우 넓다

4. 조직 확장과 채용 측면에서 설명하기 쉽다

그렇다면 React의 단점은 무엇일까?

1. 학습할 개념이 생각보다 많다

2. 선택지가 많아서 오히려 기준이 필요하다

3. 렌더링 모델을 이해하지 않으면 오히려 더 헷갈릴 수 있다

4. 작은 문제에는 과할 수 있다

Vue나 Svelte 같은 다른 선택지는 어떤 차이가 있을까?

Vue

Svelte

React vs 순수 JavaScript를 더 실무적으로 보면

순수 JavaScript가 더 나은 경우

React가 더 나은 경우

결국 React를 선택할 때 무엇을 기준으로 봐야 할까?

그래서 나는 왜 React를 쓰는가

1. 상태와 UI 관계를 구조적으로 설명하기 좋다

2. 조합 가능한 설계를 만들기 좋다

3. 조직과 생태계까지 함께 보기 좋다

같이 보면 좋은 글

결론

Marco Lee@beta1360

태그

댓글

한눈에 보면

먼저, 순수 JavaScript로 만드는 방식은 왜 여전히 유효할까?

그런데 왜 순수 JavaScript만으로는 점점 버거워질까?

React는 정확히 어떤 문제를 푸는 걸까?

React를 쓸 때 얻는 실질적인 장점

1. 상태와 UI의 관계를 더 예측 가능하게 만들기 쉽다

2. 컴포넌트 단위로 역할을 나누기 좋다

3. 생태계가 매우 넓다

4. 조직 확장과 채용 측면에서 설명하기 쉽다

그렇다면 React의 단점은 무엇일까?

1. 학습할 개념이 생각보다 많다

2. 선택지가 많아서 오히려 기준이 필요하다

3. 렌더링 모델을 이해하지 않으면 오히려 더 헷갈릴 수 있다

4. 작은 문제에는 과할 수 있다

Vue나 Svelte 같은 다른 선택지는 어떤 차이가 있을까?

Vue

Svelte

React vs 순수 JavaScript를 더 실무적으로 보면

순수 JavaScript가 더 나은 경우

React가 더 나은 경우

결국 React를 선택할 때 무엇을 기준으로 봐야 할까?

그래서 나는 왜 React를 쓰는가

1. 상태와 UI 관계를 구조적으로 설명하기 좋다

2. 조합 가능한 설계를 만들기 좋다

3. 조직과 생태계까지 함께 보기 좋다

같이 보면 좋은 글

결론

Marco Lee@beta1360

태그

댓글

먼저, 순수 `JavaScript`로 만드는 방식은 왜 여전히 유효할까?

그런데 왜 순수 `JavaScript`만으로는 점점 버거워질까?