React Server Components(RSC)를 처음 마주한 개발자 대부분이 비슷한 실수를 한다. use client를 파일마다 붙이고, App Router를 Pages Router처럼 쓰고, 그러다 Lighthouse 번들 분석에서 Markdown 파서와 날짜 포매터가 브라우저에 통째로 실려 있는 걸 발견한다. dev.to의 한 개발자는 이 경험을 "뒤늦게 앉아서 RSC를 제대로 배우게 만든 계기"라고 회고했다. 문제는 이 실수를 이제 AI 코딩 에이전트가 훨씬 빠른 속도로, 훨씬 큰 규모로 반복하고 있다는 점이다.
RSC 오해의 지형도
RSC에 대한 가장 흔한 오개념은 "서버 컴포넌트는 그냥 SSR 컴포넌트"라는 착각이다. 기존 SSR은 서버에서 HTML을 만들고, 클라이언트에서 전체 트리를 하이드레이션한다. RSC는 다르다. 서버에서 렌더링된 뒤 RSC Payload로 직렬화되고, 거기서 끝난다. 클라이언트 JavaScript가 전혀 실행되지 않는다. 번들 비용 자체가 없다. SSR이 첫 페인트를 빠르게 만든다면, RSC는 JavaScript 번들을 구조적으로 줄인다.
두 번째 오해는 "서버와 클라이언트 중 하나를 선택해야 한다"는 것이다. 선택이 아니라 구성(composition)이다. 서버 컴포넌트가 클라이언트 컴포넌트를 렌더링할 수 있고, 두 환경은 하나의 React 트리 안에서 공존한다. use client는 경계선이지 배타적 선언이 아니다. 올바른 멘탈 모델은 "내 앱이 두 환경에 걸쳐 있다"는 것이다.
AI 에이전트가 RSC를 만날 때 벌어지는 일
문제는 AI 코딩 에이전트가 이 미묘한 경계를 이해하지 못한다는 데서 시작된다. dev.to에 게재된 AI 유지보수 비용 분석 글은 Copilot, Cursor, Claude Code를 동일한 유지보수 워크플로우에 돌린 결과를 냉정하게 기록한다. 결론은 불편하다. "90초 만에 800줄을 떨어뜨리는 에이전트가 생산적으로 보이지만, 6개월 뒤 새벽 2시 온콜 디버깅 상황에서 그 에이전트는 비싸 보인다."
RSC 맥락에서 이 문제는 더 구체적이다. AI 에이전트는 컨텍스트 없이 코드를 생성할 때 가장 안전한 방향, 즉 use client를 선택한다. 상태가 필요할 수도 있고, 이벤트 핸들러가 붙을 수도 있고, 브라우저 API가 쓰일 수도 있으니까. 결과적으로 DB 쿼리를 실행해도 되는 컴포넌트, 마크다운을 렌더링하기만 하는 컴포넌트, 세션을 읽기만 하는 Navbar까지 모두 클라이언트 컴포넌트가 된다. 번들이 부풀고, 서버 전용 환경변수가 노출될 위험이 생기고, RSC가 약속하는 성능 이득이 사라진다.
도구별로 다른 맥락 수집 방식
세 도구의 차이는 "쓰기 전에 얼마나 읽느냐"에서 갈린다. Copilot은 커서 주변의 즉각적인 이웃만 본다. 3개 폴더 떨어진 곳에 formatCurrency 헬퍼가 있어도 모른다. 새로 만든다. RSC 경계 판단에 필요한 트리 구조, 데이터 페칭 패턴, 기존 서버 컴포넌트 컨벤션을 파악하기엔 시야가 너무 좁다.
Cursor는 코드베이스 인덱싱으로 전체 레포 컨텍스트를 가져올 수 있다. @파일 참조나 에이전트 모드를 적극적으로 쓰면 기존 추상화를 재사용하는 경향이 있다. 단, 고스트 텍스트 수락 모드로 쓰면 Copilot과 동일한 한계로 돌아간다. 컨텍스트 기능을 의식적으로 활성화해야 한다.
Claude Code는 변경을 제안하기 전에 평균 12개 파일 내외를 먼저 읽는다고 관찰됐다. 출력이 더 보수적이고, 기존 스타일과 더 일치하며, 리뷰하기 쉽다. 속도와 비용이 더 드는 건 트레이드오프다. 하지만 RSC처럼 트리 전체 맥락이 중요한 환경에서는 이 보수성이 자산이 된다.
코드베이스 자체가 에이전트의 나침반이다
세 번째 소스 기사는 다른 각도에서 같은 문제를 가리킨다. utils.py가 11개 있는 레포에서 에이전트는 항상 틀린 파일을 로드한다. 파일 이름을 payment-webhook-handler.py로 바꾸자 문제가 사라졌다. RSC 프로젝트에서도 동일하다. components/Card.tsx가 서버 컴포넌트인지 클라이언트 컴포넌트인지 파일 이름만으로 알 수 없다면, 에이전트는 추측한다. 추측의 기본값은 use client다.
실용적인 처방은 명확하다. 서버 전용 컴포넌트임을 이름과 위치로 드러내라. app/dashboard/RevenueChart.server.tsx 같은 네이밍 컨벤션, 또는 app/(server)/ 같은 폴더 구조가 에이전트의 컨텍스트 윈도에 직접 신호를 준다. 좋은 코드 구조는 이제 다음 개발자뿐 아니라 에이전트를 위한 네비게이션이기도 하다.
시사점: RSC와 AI 에이전트, 함께 쓰려면
소프트웨어 유지보수 비용은 전체 생애주기 비용의 60~80%를 차지한다는 추정은 1970년대 Lehman의 법칙부터 2000년대 Glass의 연구까지 수십 년간 안정적으로 유지됐다. AI 에이전트가 이 비율을 바꾸지는 않는다. 오히려 잘못 쓰면 기술 부채를 기계 속도로 누적시킨다.
RSC와 AI 에이전트를 함께 쓰는 팀에게 지금 당장 적용할 수 있는 체크리스트는 세 가지다. 첫째, AI가 생성한 컴포넌트에 use client가 붙어 있다면 반드시 이유를 확인하라. 상태, 이벤트 핸들러, 브라우저 API 중 하나가 실제로 필요한가? 둘째, PR 리뷰에서 번들 분석을 루틴으로 만들어라. AI-assisted PR의 30일 내 버그율과 리뷰 이터레이션 수를 추적하면 도구 선택의 근거가 생긴다. 셋째, 코드베이스의 파일·폴더 네이밍을 정비하라. 에이전트가 올바른 컨텍스트를 수집하게 만드는 가장 저비용 투자다.
전망: 경계를 이해하는 에이전트가 온다
RSC가 Next.js만의 기능이 아니라 React 코어 스펙이라는 점을 기억할 필요가 있다. Remix, Gatsby 등 주요 프레임워크가 채택 중이고, React Compiler가 성숙할수록 서버-클라이언트 경계 최적화는 더 정교해진다. 에이전트 역시 진화한다. 전체 레포 컨텍스트를 기반으로 서버/클라이언트 경계를 추론하고, 기존 데이터 페칭 패턴을 학습해 일관된 코드를 생성하는 방향으로 나아갈 것이다.
하지만 지금 이 순간, 에이전트를 맹신하는 팀과 에이전트에게 명확한 컨텍스트를 설계해주는 팀 사이의 코드베이스 건강도는 이미 갈리고 있다. RSC는 '에이전트에게 의존하기 가장 위험한 영역'이 아니라, '컨텍스트를 제대로 설계하면 에이전트와 가장 잘 협업할 수 있는 영역'이다. 차이를 만드는 건 도구가 아니라 그 도구를 쓰는 방식이다.