RSC의 장점만 외워 왔는지, 아니면 서버/클라이언트 경계를 직접 그어 본 감각과 트레이드오프까지 같이 풀 수 있는지를 가른다.
서버 컴포넌트(RSC)는 렌더 결과만 클라이언트로 보내고 자기 자신은 클라이언트 번들에 포함되지 않는 컴포넌트다. 서버 내부에서 DB·파일 시스템·비밀 키 같은 자원에 바로 접근할 수 있고, 그 대신 useState·useEffect·이벤트 핸들러 같은 클라이언트 전용 기능은 쓸 수 없다. 인터랙션이 필요한 부분만 "use client"로 분리해 클라이언트 컴포넌트 경계를 새로 그어 줘야 한다. 핵심은 "전부 서버로"가 아니라 인터랙션 밀도에 따라 서버/클라이언트 책임을 다시 나누는 일이다.
Next.js App Router에서 "use client" 경계를 다시 그어 번들 사이즈가 줄어든 경험이 있다면 경계 설계의 실제 효과로 풀어낼 수 있다
RSC에서 서버 데이터를 props로 클라이언트 컴포넌트에 전달하며 직렬화 한계를 만난 경험이 있다면 "경계의 비용" 이야기로 이어갈 수 있다
비밀 키나 SQL 로직을 서버 컴포넌트로 옮겨 보안 표면을 줄여 본 경험이 있다면 "코드 위치가 신뢰 경계다"는 관점으로 풀 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.