Hacker News 의견들

• React Server Components(RSC)는 항상 불편하게 느껴졌음
  자바스크립트 코드만 봐서는 클라이언트에서 실행되는 부분과 서버에서 실행되는 부분을 구분하기 어렵기 때문임
  게다가 이를 구현하려면 깊은 직렬화 RPC 메커니즘이 필요하고, 이는 개발자에게 불투명하며 보안 취약점의 위험을 높이는 지점이 됨

  • 예전 NextJS pages router 시절엔 서버와 클라이언트 코드의 경계가 명확해서 좋았음
    하지만 app router로 바꾸자 혼란스러웠음. 코드가 양쪽에서 실행될 수 있다 보니 Headers 같은 객체가 항상 존재하지 않아 무엇이 어디서 실행되는지 알기 어려웠음
  • 새로 합류한 팀에서 Next를 쓰는 걸 보고 “이거 어떻게 동작하는지 아는 사람 있나요?”라고 물었는데, 아무도 명확히 설명하지 못했음
    React+Next가 잘 작동할 땐 마법처럼 느껴지지만, 팀 단위로 일할 때는 예측 가능성이 점점 사라지는 게 문제라고 느낌
  • 그래서 나는 Inertia.js의 팬임. Inertia.js는 Laravel, Rails, Django 같은 전통적 MVC 백엔드와 React, Vue, Svelte 같은 프론트엔드 툴을 자연스럽게 연결해줌
    역할이 명확하고, 작업이 단순하며, 대부분의 프로젝트에서 가장 안전한 선택이라고 생각함
  • RSC와 SSR이 과도하게 채택된 것 같음
    랜딩 페이지나 마케팅 페이지라면 SSR이 유용하지만, 일반 SaaS 대시보드 같은 앱에서는 복잡성에 비해 이득이 거의 없음
  • 다른 프레임워크(Angular, SvelteKit, Nuxt)는 이런 취약점에 얼마나 노출되어 있을지 궁금함
    React가 단지 인기가 많아서 더 주목받는 걸까, 아니면 구조적으로 더 위험한 걸까 하는 의문이 있음

• 지난주 RSC를 살펴봤는데, 복잡성이 너무 높고 문서도 거의 없었음
  React는 아직 실험적 기능이라고 하지만 NextJS는 이미 광범위하게 배포했음
  앞으로 더 많은 보안 이슈가 나올 것 같고, Next의 빌드 시스템은 지나치게 복잡해서 디버깅조차 어려웠음
  얻는 이점에 비해 비용이 너무 큼

  • 예전부터 Next가 “아직 프로덕션 준비가 안 된 React 기능”을 최신 기능처럼 포장한다는 불만이 있었음
    그래서 나도 Next를 떠났음. 인지 부하가 너무 커서 얻는 게 별로 없었음
  • React는 오랫동안 문서 부족 문제가 있었음
    RSC뿐 아니라 전반적으로 명확한 가이드가 늦게 나왔고, CRA 같은 도구도 공식적으로 인정하지 않음
    이제 와서야 useEffect 문서가 좋아졌지만 너무 늦었음
    2025년이 된 지금도 실무에서 쓰고 있는데, 여전히 명확한 문서화가 부족함

• SPA의 핵심은 “앱 전체를 클라이언트로 보내고 서버와는 데이터만 주고받는 것”이었음

  • 그런데 지금 C# 진영에서는 Blazor Server가 유행임
    예전 .aspx Web Forms처럼 모든 클릭과 입력이 서버로 전송되고, 변경된 DOM이 다시 내려옴
    사실상 예전 방식으로 돌아간 셈이라 좀 황당함
  • 결국 많은 개발자들이 다시 서버 사이드 렌더링의 이유를 깨닫고 PHP, Rails, Spring 같은 풀스택 프레임워크로 회귀했음
  • 하지만 요즘은 React 같은 라이브러리로 정적 사이트를 만드는 경우가 많아졌고, 단순한 템플릿 엔진 + JS 조합보다 느리고 복잡함
    “적절한 도구를 고르는 감각”이 사라진 게 아쉬움
  • 물론 RSC는 순수 SPA용은 아님. 다른 목적을 가진 접근임

• 이번 보안 공지에서 “중대한 CVE가 발견되면 후속 취약점이 흔히 드러난다”는 문구가 가장 눈에 띄었음
  문제의 범위나 영향, 완화 방법을 설명하기도 전에 CVE를 정당화하려는 듯 보여서 불안했음

  • 하지만 어떤 사람은 “그건 정당화가 아니라, 사람들이 가장 먼저 궁금해할 부분에 대한 설명일 뿐”이라고 봄
  • 피드백을 반영해 문구를 수정했다고 함 → 수정된 PR 링크
  • 누군가는 이걸 인식 관리(perception management) 라고 표현함
    관련 위키 문서
  • 이 사안에는 커리어적 이해관계가 얽혀 있다고 보는 시각도 있음
  • 어떤 이는 “이건 Vercel 마케팅팀이 쓴 글처럼 보인다”고 말함

• 15년 전 Opa에서 이미 비슷한 시도를 했었음
  클라이언트와 서버 코드를 자동으로 분리하고 JSX와 유사한 문법을 도입했음
  하지만 보안 분석을 강화하다 보니 컴파일러가 거대해졌고, 결국 단일 앱 개념보다는 명확한 분리의 중요성을 깨달았음
  언젠가 LLM이 이런 코드를 자동 생성할 수도 있겠지만, 지금은 단순한 구조가 낫다고 생각함

  • 실제로 RSC의 취약점은 코드 분할보다는 직렬화/역직렬화 과정의 동적 특성 때문임
    JS의 프로토타입 오염, 함수 toString, Promise 오버라이드 같은 문제를 막기 위한 패치가 진행 중임
    RSC는 import "server-only"나 import "client-only" 같은 정적 검증으로 환경을 구분하기 때문에 구조적으로는 안전한 접근임
  • 비슷한 아이디어로 Electric Clojure라는 프로젝트도 있음 → 링크
  • 참고로 Ocsigen Eliom이 Opa보다 먼저 이런 개념을 시도했음

• React는 원래 MVC의 View 역할로 작고 단순했을 때가 좋았음
  지금은 너무 많은 기능이 들어가서 비대해진 느낌임

  • 하지만 RSC는 별도 라이브러리라 기본 React 설치에는 포함되지 않음
  • 예전 버전으로 돌아가려면 git checkout v15.0.0이면 됨

• RSC는 애초에 존재하지 말았어야 함
  대부분의 앱은 서버에서 HTML을 렌더링하면 충분하고, SPA가 필요한 경우는 극히 일부임
  RSC는 복잡성과 보안 취약점만 늘렸을 뿐임

  • 동의함. 하지만 부트캠프나 VC 자금이 밀어주는 생태계가 이 방향을 계속 밀고 있음
    Bun, Vercel 같은 프로젝트가 “모든 게 완벽히 돌아가는 JS 유토피아”라는 환상을 팔고 있어서 이 흐름이 쉽게 사라지지 않을 것 같음

• 예전에 Dan Abramov와 X에서 RSC에 대해 논쟁했었음
  그는 혁신적인 기능이라 했지만, 나는 “자기 발을 쏘는 총”이라고 했음. 결국 현실이 그렇게 됨

  • 개인적으로 RSC로 앱을 만들어봤는데 여전히 이 방식이 마음에 듦
    다만 프로토콜 수준의 버그 가능성을 과소평가했음. 이번 취약점은 직렬화 프로토콜에 집중되어 있음
    보안 커뮤니티가 이제야 깊이 들여다보는 중이라, 팀이 더 일찍 대응했으면 좋았을 것 같음
  • 성공한 시스템은 결국 과도한 확장으로 괴물이 되기 쉬움
    React도 단순 렌더링 라이브러리에서 런타임으로 변하면서 복잡도가 폭발했음
  • 개인적으로 Dan의 접근이 그리 뛰어나다고 느끼지 않음
    반면 Vue와 Vite는 훨씬 세련된 설계라고 생각함 → Evan You 개인 사이트
  • 물론 대부분의 아이디어는 실패하기 마련이라, 비판만 하는 태도도 경계해야 함
    가끔은 대담한 시도가 홈런이 되기도 함
  • “당신이 더 뛰어난 걸지도 모른다”는 응원의 댓글도 있었음

• RSC는 프론트엔드가 백엔드를 삼키려는 시도라면, HTMX는 그 반대임
  HTMX는 클라이언트–서버 경계를 유지해 백엔드 쪽은 안전하지만, 프론트엔드에선 XSS 위험이 있음

  • 하지만 HTMX는 이미 템플릿 엔진의 자동 이스케이프로 XSS 문제를 해결했음
    관련 글

• Next 팀이 새로운 보안 업데이트를 발표했음 → NextJS Security Update 2025-12-11
  14.x, 15.x, 16.x 버전에 영향을 미침