▲

2025년의 React vs. Backbone

 (backbonenotbad.hyperclay.com)
3P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • 2010년대 초의 Backbone과 2025년의 React를 비교하며, 15년간의 프런트엔드 발전이 실제로 얼마나 진전되었는지를 되짚는 논의
  • React는 겉보기에는 간결하고 현대적이지만, 내부적으로는 복잡한 추상화 계층을 통해 단순함을 가장함
  • Backbone은 코드가 장황하지만, 이벤트 흐름과 DOM 조작이 명시적이어서 초급 개발자도 동작을 쉽게 추적 가능
  • React는 상태 관리, 의존성 배열, 클로저 문제 등으로 인해 내부 동작을 이해하지 않으면 디버깅이 어려운 구조
  • 결국 “이벤트 + 상태 = UI”라는 본질을 되새기며, 단순성과 해커블(hackable)한 구조를 갖춘 새로운 모델의 필요성을 제기

15년간의 진보

  • 하나는 2010년대 프레임워크(Backbone) , 다른 하나는 10년 넘게 발전한 React로 작성된 패스워드 입력창 예시
    • 두 코드 구현은 길이도 비슷하고 기능도 동일
    • React는 수많은 개발자 시간과 방대한 생태계의 지원을 받았음
    • 그러나 저자는 “React가 얼마나 나아졌는가”보다 “얼마나 적게 발전했는가”가 더 흥미롭다고 지적
  • React는 겉보기 단순성의 환상을 제공하지만, 실제로는 복잡한 추상화로 인해 이해 난이도가 높음
    • Backbone은 이벤트 발생 → 핸들러 실행 → HTML 생성 → DOM 삽입이라는 단순한 흐름을 명시적으로 표현
    • 반면 React는 내부 동작을 숨기며, 단순 예제를 넘어가면 내부 메커니즘을 이해해야만 해결 가능한 문제가 발생

단순함의 환상 (The Illusion of Simplicity)

  • React는 코드가 깔끔해 보이지만, 이는 명시적 단순성 대신 추상적 복잡성을 택한 결과
    • Backbone은 장황하지만 “무슨 일이 언제 일어나는지”를 명확히 보여줌
    • 초급 개발자도 코드 흐름을 쉽게 추적 가능
  • React에서는 내부 상태와 렌더링 로직이 감춰져 있어, 예상치 못한 버그가 자주 발생
    • 예: 리스트 항목의 key를 인덱스로 바꾸면 React가 다른 컴포넌트로 인식해 상태를 초기화
    • value가 undefined로 바뀌면 비제어 → 제어 컴포넌트 전환으로 입력값이 리셋되는 현상 발생
  • useEffect 사용 시 무한 루프가 생기는 문제도 흔함
    • 의존성 배열에 매 렌더마다 새로 생성되는 객체가 포함되면 React가 변경으로 인식
    • 이를 막기 위해 useMemo, useCallback으로 식별 안정화(stabilize identities) 필요
    • 과거에는 고려하지 않아도 됐던 개념을 신경 써야 하는 부담 발생
  • 클릭 핸들러가 오래된 상태(stale state) 를 참조하는 문제도 존재
    • 함수가 생성 시점의 상태를 캡처하기 때문
    • 해결책은 상태를 의존성 배열에 넣거나, setState(x => x + 1) 같은 함수형 업데이트 사용
    • 그러나 두 방법 모두 임시방편(workaround) 처럼 느껴짐

마법의 대가 (Magic Has a High Price)

  • 이러한 문제들은 예외적 상황이 아니라, 중간 규모 이상의 앱에서 흔히 발생하는 일반적 문제
    • 디버깅을 위해서는 재조정 알고리듬(reconciliation algorithm) , 렌더 단계(render phase) , 스케줄러(batch update) 이해가 필요
    • React는 “왜 작동하는지 몰라도 작동하는” 구조지만, 문제가 생기면 내부를 알아야만 해결 가능
  • “React를 진정 이해하려면 직접 만들어봐야 한다”는 말이 있을 정도로 복잡함
    • “Build your own React” 같은 튜토리얼이 존재
    • 그러나 단순한 비밀번호 검증기를 만들기 위해 가상 DOM, 스케줄링 우선순위, 동시 렌더링을 이해해야 한다는 점은 비판적 시사점
  • Backbone과 jQuery는 정직하고 해커블한 구조를 가짐
    • 소스코드를 직접 보고 수정 가능
    • DOM 메서드 기반이라 이해와 확장이 쉬움
    • 반면 React의 추상화 계층은 내부 접근과 수정이 어렵게 만듦

다음 단계는 무엇인가 (So, What's Next?)

  • 결국 React와 Backbone 모두 “이벤트 + 상태 = UI” 라는 동일한 문제를 해결하려는 시도임
  • 대규모 앱에서는 React의 복잡성이 정당화될 수 있으나, 대부분의 중소형 앱에는 과도한 부담임
  • 단순함과 투명성을 갖춘 새로운 UI 모델이 필요함
    • DOM처럼 견고하지만 직관적인 시스템
    • Backbone이나 jQuery처럼 즉시 이해 가능하고 수정 가능한 구조를 지향
▲
GN⁺ 6시간전  [-]
Hacker News 의견

  • Backbone, Angular 1, Ember, React까지 모두 써봤음
    React가 인기를 얻은 이유를 간과하면 안 됨. 컴포넌트 합성, 이벤트 처리, 상태 관리, 효율적인 DOM 업데이트 등에서 React는 기존 프레임워크의 고질적인 문제를 해결했음
    Backbone은 DOM 생명주기 관리가 복잡하고, 이벤트 핸들러를 문자열로 지정해야 해서 유지보수가 어려웠음. React는 단방향 상태 흐름과 가상 DOM으로 이런 문제를 단순화했음
    지금이라면 순수 JS를 쓰고 싶을 때는 Backbone보다 lit-html 같은 템플릿 솔루션이 훨씬 낫다고 생각함

    • 예시가 현실적이지 않다고 느낌. 비교하려면 TodoMVC가 대표적임. Backbone 버전은 이 코드를 보면 유지보수 악몽 수준임. React 버전(링크)은 훨씬 명확함
      프론트엔드는 예전에도 복잡했고 지금도 복잡하지만, 지금은 훨씬 덜 고통스러움
    • 동의함. React도 완벽하진 않지만 결국 타협의 문제임. 어떤 도구를 쓰든 개발자가 그 복잡성을 감당해야 함. 중요한 건 우리가 올바른 타협점을 선택하고 있는가 하는 점임
    • 요즘은 React 말고도 이런 기능을 제공하는 프레임워크가 많음. React만의 특권은 아님

  • 앱의 복잡도는 컴포넌트 수가 아니라 상태 관리에서 비롯됨
    Backbone Store의 양방향 데이터 흐름 때문에 UI가 멈추는 문제를 자주 겪었음. React의 혁신은 단방향 데이터 흐름을 중심으로 한 Flux 아키텍처였음
    좋은 프레임워크는 “성공의 함정(Pit of Success)”으로 자연스럽게 이끌어주는 도구라고 생각함. React는 그 역할을 잘 해왔음

    • React/Flux/Redux 이전의 프론트엔드 개발은 정말 혼돈이었음. 1000줄도 안 되는 코드에서도 상태 관리 문제가 터졌음
    • 글쓴이임. 단방향 데이터 흐름이 문제를 해결한 건 맞지만, React도 새로운 복잡성을 가져왔음
      예를 들어 stale closure, 무한 useEffect 루프, 키 변경으로 인한 입력 초기화 같은 문제는 Backbone에는 없었음
      Backbone의 문제는 눈에 보였고 디버깅이 쉬웠지만, React의 문제는 추상화 뒤에 숨어 있음
      대부분의 앱은 Facebook 규모가 아니므로, 명시적이고 단순한 접근이 오히려 더 나을 수도 있음
    • Angular를 오래 하다가 React로 돌아왔는데, 완벽하진 않아도 React는 개발자가 올바른 방향으로 코딩하게 유도함
    • 컴포넌트 자체가 또 다른 복잡성임. 마크업, 이벤트, 비즈니스 로직, 접근성까지 한데 묶여 거대한 구조가 됨. 결국 편안함을 위한 복잡성일 뿐 단순함은 공짜가 아님
    • “단방향 데이터 흐름”은 사실 DOM의 기본 동작과 비슷하지 않나? React 팀이 만든 건 Flux, Flow가 아님

  • 인기 있는 기술을 “나쁘다”고 단정하는 건 일종의 순진한 오만함 같음
    물론 인기가 품질을 보장하진 않지만, 전 세계의 뛰어난 엔지니어들이 모두 속았다고 보는 건 과함

    • 인기 기술이 항상 옳은 건 아님. MongoDB, Kafka, Microservice 유행을 떠올려보면 됨
      대기업과 마케팅이 밀면 CTO들이 채택하고, 커리어가 걸리면 아무도 “이건 별로”라고 말하지 않음. 인기 ≠ 적합성임
    • 글쓴이임. “팔레오 인플루언서” 비유는 흥미롭지만, 새롭다고 무조건 좋은 것도 아님
      React는 기술적 우수성만으로 승리한 게 아니라 Facebook의 마케팅과 생태계 자기강화 덕분이었음
      15년이 지난 지금도 코드 길이나 복잡도는 크게 줄지 않았음. 단지 다른 방식으로 복잡해졌을 뿐임
      과거를 돌아보는 건 향수 때문이 아니라, 우리가 비례하지 않는 복잡성을 추가했는지 점검하기 위함임
    • React나 Tailwind는 채용 친화성이 강점임. 기술적 완벽함보다는 온보딩 용이성이 이유임
      웹은 여전히 디자인 패턴의 서부 개척지 같음. 그걸 받아들이고 나니 마음이 편해졌음
    • React를 “어리석다”고 단정하는 건 오만과 무지의 혼합처럼 보임. 수백만 개발자가 쓰는 이유가 있음. 완전한 부정은 Chesterton’s Fence를 무시하는 태도임
    • 오만이라기보다 다른 관점의 경험일 수도 있음. React의 생태계를 좋아하는 사람도 있고, JS 양이 많아 싫어하는 사람도 있음
      결국 프로젝트마다 트레이드오프를 재평가해야 함

  • “간단한 일엔 React가 필요 없다”는 주장은 흔한 React 오류(React fallacy) 임
    단순한 예제로 React를 평가하는 건 “Hello World 길이로 언어를 평가”하는 것과 같음
    간단한 일에도 React를 쓰는 이유는, 복잡한 일에도 React를 쓰기 때문임. 일관된 도구 세트가 유지보수에 유리함

    • “복잡한 일에도 쓰니까 단순한 일에도 쓴다”는 건 마치 트럭으로 장보러 가는 것 같음. 결국 적절한 도구 선택이 핵심임

  • Backbone은 “프레임워크처럼 보이지만 실제론 접착 코드 덩어리”였음
    React의 진짜 승리는 DOM 직접 조작이 필요 없고, 반응형 상태 관리가 가능해진 점임. 이 두 가지가 개발 생산성을 크게 높였음

    • 예전 Backbone 튜토리얼을 많이 썼던 사람으로서 약간 향수가 있음
      예전 튜토리얼 링크, https://backbonetutorials.com/organizing-backbone-using-modules/?a">아카이브 버전
      요즘은 LLM이 코드를 어떻게 이해하느냐에 더 관심이 있음. JSX 같은 선언적 문법은 LLM 친화적임
      하지만 useEffect 이후의 React는 표현력과 명시성 면에서 오히려 흐려진 느낌임
    • Marionette가 Backbone의 보일러플레이트를 많이 줄여줬음
    • React에 내장된 상태 관리가 있냐는 질문이 나옴

  • React가 인기 많아진 이유가 잘 드러남
    React 코드는 대부분 순수 JS와 HTML이고, 핵심은 useState 하나뿐임. 직관적이라 문서 없이도 이해 가능함
    Backbone은 .space-y-2 같은 문자열 셀렉터에 의존해 유지보수가 지옥이었음. 클래스명 하나 바꾸면 앱 절반이 깨짐
    React는 이런 문제를 구조적으로 해결했음

    • “그 글은 직접 쓴 게 아니라 Claude에게 시켜 쓴 것 같다”는 농담이 나옴

  • Backbone 코드는 “무슨 일이 언제 일어나는지” 명확하지만, React는 내부 동작을 이해해야 함
    나도 React의 동작 시점을 이해하려고 Dan Abramov의 useEffect 가이드와 Mark Erikson의 블로그를 여러 번 읽었음
    Backbone 코드는 10년 만에 봐도 바로 이해됐음

  • 6년 전 팀을 Backbone에서 Angular로 옮겼음
    Backbone은 직관적이고 마법이 없는 구조라 주니어에게 좋았지만, 결국 TypeScript와 Angular가 더 체계적이었음
    지금은 NG20을 쓰고 있고 만족함. 언젠가 브라우저가 더 많은 기능을 기본 제공하면, 다시 단순한 방식으로 돌아갈 수도 있을 것 같음

  • 우리는 항상 추상화 위에서 프로그래밍하고 있음
    중요한 건 그 추상화가 복잡성 대비 생산성 이득을 주는지, 그리고 신뢰할 수 있는지임
    최악의 경우라도 디버깅 가능해야 함

  • React의 입력 필드가 Backbone보다 Undo 동작을 더 자연스럽게 처리함
    Backbone은 한 글자씩 되돌리지만 React는 단어 단위로 되돌림

    • 왜 브라우저 기본 동작을 덮어쓰는 게 더 낫다는 건지 이해가 안 됨. 오히려 자연스러운 스크롤을 망치는 JS 라이브러리 같음
    • 흥미롭게도 Chrome에서는 다르지만 Firefox에서는 두 프레임워크 모두 동일하게 동작함
    • Backbone의 방식이 더 좋다고 생각함
    • 어떤 동작이 “정답”인지는 결국 개인 취향의 문제임
답변달기