← Back to NOTES 🌰 ← 프론트가 서버까지 확장될 때 생기는 비용 (RSC 이슈를 보며)

← 1. SSR과 닮았지만, RSC는 구조가 한 단계 더 간다

이슈가 발생하면 종종 이런 공지가 나온다.

그런 공지는 서비스 사용자 입장에선 도움이 된다. 다만 이번에는 공지의 톤보다도, 프론트가 서버 기능을 다루게 되면서 따라오는 운영/보안 비용이 더 먼저 떠올랐다.

여기서 내가 말하고 싶은 건 책임 공방이 아니라, 서버 처리 구간을 함께 다루기 시작하는 순간부터 업데이트, 모니터링, 권한 설계 같은 것들이 ‘부가 작업’이 아니라 ‘기능의 일부’가 된다는 점이다. 즉, 선택의 옳고 그름보다 “운영 가능한 형태로 가져갈 준비가 되어 있나”가 먼저 남는다.

메모: “무관”이라는 문장은 사실이고, 그래도 비용은 남는다

오해를 막기 위해 “React/Next를 쓰면 다 취약한가?”라는 질문에 먼저 선을 그어 둔다. 이번 이슈는 React를 사용한다는 사실만으로 자동 노출되는 유형이라기보다, 서버에서 RSC/Server Actions 요청을 처리하는 구성에서 영향을 받는 쪽에 가깝다. 따라서 순수 CSR(서버에서 React 실행 경로가 없는 형태)이라면 영향이 제한적일 수 있다.

그런데도 내가 이 이슈를 보면서 비용을 떠올린 이유는 단순하다. 어떤 기능을 쓰든, 서버 처리 구간을 함께 다루는 선택을 하는 순간부터는 “업데이트/모니터링/롤백”이 선택이 아니라 기본값이 되기 때문이다.

→ 3. 내가 더 예민(😉)해지는 구간: attack surface와 trust boundary