경계를 긋는 일이 전부다
프론트엔드 개발자에게 가장 자주 돌아오는 질문이 있다. "이 컴포넌트, use client 붙여야 해요?" 대부분의 경우 정답은 '아니오'인데, 현실에서는 부모 레이아웃째로 클라이언트 번들에 빨려 들어가는 일이 반복된다. dev.to에 올라온 Safdar Ali의 RSC vs Client Components 가이드는 이 문제를 결정 트리 하나로 정리한다. 하지만 내가 이 글에서 더 주목하는 건 그 트리 자체가 아니라, '경계를 어디에 긋느냐'는 사고방식이 AI 도구 통합에도 동일하게 작동한다는 점이다.
RSC의 핵심은 규칙이 아니라 원칙
App Router에서 모든 파일은 기본이 서버 컴포넌트다. use client는 예외 선언이지, 기본값이 아니다. 이 단순한 사실을 놓치면 루트 레이아웃에 테마 토글 하나 때문에 use client를 달고, 결과적으로 전체 페이지가 클라이언트 번들로 빨려 들어간다. Safdar의 측정값은 냉정하다. 동일한 기능을 RSC + 클라이언트 아일랜드로 재설계하자 첫 로드 JS가 412KB에서 255KB로 38% 줄었고, 하이드레이션되는 컴포넌트 수는 24개에서 6개로 떨어졌다. LCP는 3.4초에서 2.0초로, TTI는 5.2초에서 3.1초로 개선됐다.
핵심 원칙은 하나다. 상태·이벤트·브라우저 API가 필요한 최소 단위만 클라이언트로 내리고, 나머지는 서버에 둔다. 데이터는 서버에서 fetch해 직렬화 가능한 props로 넘기고, 클라이언트 아일랜드는 그 데이터를 받아 인터랙션만 처리한다. 경계는 컴포넌트 트리 위쪽이 아니라 리프 노드에 가깝게 그을수록 좋다.
같은 원칙이 AI 메모리 앱 설계에 나타난다
Contextberg는 Windows 네이티브 AI 메모리 앱이다. Claude Code, Cursor, Codex, GitHub Copilot처럼 서로를 모르는 에이전트들 사이에서 컨텍스트를 중계하는 MCP 서버 역할을 한다. 개발자 Tiger가 이 앱을 만든 이유는 단순하다. 월요일 밤 Stack Overflow를 30분 읽고 내린 결정을 화요일 아침 Claude Code는 전혀 모른다. 에이전트 대화 로그만으로는 맥락이 잡히지 않는다는 것이다.
Contextberg의 설계를 들여다보면 RSC의 경계 원칙과 구조가 닮아 있다. 앱은 5가지 신호(앱/윈도우 사용, 브라우저 히스토리, 스크린샷, 키스트로크, 에이전트 대화 로그)를 로컬에서 수집한다. 처리는 세 단계로 나뉜다. 15분 단위 Activity, 시간 단위 Hourly Report, 일 단위 LTM. 원시 데이터는 로컬에 머물고, AI 처리를 위한 요약 프롬프트만 클라우드로 나간다. 오프라인 운용이 필요하면 LM Studio로 전환해 그마저도 로컬에 가둘 수 있다.
이걸 RSC 프레임으로 읽으면 명확해진다. 수집과 저장은 서버(로컬)가 담당하고, 에이전트에게 서빙하는 인터페이스만 MCP 경계 너머로 내보낸다. 클라이언트(에이전트)는 메모리 생성 로직을 알 필요가 없다. 직렬화된 컨텍스트 요약만 받아 쓰면 된다. 경계를 잘못 긋는 실수도 RSC와 같다. 에이전트에게 원시 데이터를 통째로 넘기면 토큰이 폭발하고, 관련 없는 신호가 컨텍스트를 오염시킨다.
AI 계약서 생성기가 보여주는 '최소 클라이언트' 전략
AI Contract Generator는 프리랜서가 자연어로 계약 조건을 설명하면 PDF 계약서를 1분 안에 만들어주는 Next.js 앱이다. "2개월 서비스 계약, net-15 결제, 상호 NDA, 30일 킬피 조항" 같은 문장을 입력하면 LLM이 적합한 템플릿을 고르고 조항을 생성한다. 인라인 에디터에서 수정 후 PDF로 내보낼 수 있다.
개발자가 가장 까다로웠다고 밝힌 부분은 모델 자체가 아니었다. 제약 인코딩 - 즉 "net-15 결제, 연체료 월 1.5%"라는 입력이 실제 법률 문서처럼 읽히는 조항으로 변환되도록 JSON 스키마를 강제하는 부분이었다. 여기서도 경계 설계가 핵심이다. LLM 오케스트레이션은 structured output으로 조항 JSON을 생성하고, PDF 렌더링은 서버사이드에서 처리해 레이아웃 일관성을 보장한다. 인라인 에디터만 클라이언트에서 동작하며 계약 JSON과 양방향 동기화된다. 클라이언트가 담당하는 건 편집 인터랙션뿐이고, 생성과 렌더링은 서버 영역이다.
시사점: 아키텍처 결정은 레이어를 바꿔도 같은 질문이다
세 사례를 겹쳐놓으면 패턴이 보인다. RSC 경계 설계, MCP 메모리 아키텍처, AI 생성 도구의 서버/클라이언트 분리 모두 같은 질문에서 출발한다. '이 연산이 여기 있어야 할 이유가 있는가?' 이유가 없으면 더 안쪽(서버, 로컬, 구조화된 레이어)으로 밀어넣는다. 이유가 생겼을 때만 경계를 열어 바깥으로 내보낸다.
AI 도구를 워크플로우에 통합할 때 자주 보이는 실수가 RSC의 흔한 실수와 겹친다. LLM 호출을 클라이언트에서 직접 날리거나, 에이전트에게 정제되지 않은 컨텍스트를 통째로 넘기거나, 생성 로직과 렌더링 로직을 같은 레이어에 뒤섞는 것. 결과는 비슷하다. 번들이 커지고, 토큰이 낭비되고, 경계가 무너지면서 유지보수 비용이 올라간다.
전망: 경계 설계 역량이 AI 워크플로우의 품질을 가른다
MCP 생태계가 빠르게 확장되고 AI 도구가 프론트엔드 개발 파이프라인 깊숙이 들어올수록, '어디서 무엇을 처리할 것인가'를 결정하는 아키텍처 감각이 더 중요해진다. v0.dev나 Claude로 빠르게 프로토타입을 뽑아내는 시대에 오히려 경계가 흐릿해지기 쉽다. AI가 생성한 컴포넌트에 무심코 use client가 붙어 있거나, LLM 호출이 잘못된 레이어에 박혀 있는 코드가 프로덕션에 올라가는 속도도 그만큼 빨라진다.
RSC 결정 트리가 유용한 이유는 규칙을 암기시키기 때문이 아니다. '이게 여기 있어야 하는가'를 매번 묻는 습관을 만들기 때문이다. 그 습관은 컴포넌트 경계에서만 통하는 게 아니다. MCP 서버 설계에서도, AI 생성 파이프라인의 레이어 분리에서도, 에이전트에게 넘길 컨텍스트의 범위를 정할 때도 동일하게 작동한다. 도구가 바뀌어도 설계 원칙은 이식된다.