렌더링 전략을 고를 때 우리는 늘 같은 질문으로 돌아온다. "HTML이 언제, 어디서 만들어지는가?" SSR은 요청마다 서버가 HTML을 생성하고, CSR은 브라우저가 JS를 실행한 뒤 DOM을 그린다. SSG는 빌드 타임에 모든 페이지를 찍어두고, ISR은 SSG의 속도를 유지하면서 특정 페이지만 백그라운드에서 갱신한다. dev.to의 렌더링 전략 가이드가 정리하듯, 이 네 가지 선택지는 결국 성능·SEO·비용의 트레이드오프를 가르는 단 하나의 결정에서 출발한다.
그런데 여기서 잘 다루지 않는 질문이 하나 있다. AI 에이전트는 이 렌더링 결과를 어떻게 이해하는가? 에이전트가 프론트엔드 코드를 생성하거나, 레이아웃을 수정하거나, 시각적 버그를 잡는 작업을 한다고 상상해보자. 에이전트가 쥐고 있는 정보는 보통 JSON이나 DOM 트리 같은 '문서 모델'이다. 요소의 위치, 크기, z-order, 텍스트 내용—좌표 기반의 가구 목록. 하지만 그 텍스트가 실제 폰트 메트릭과 CSS overflow 규칙을 거쳐 화면에서 잘리는지는, 그 목록에 적혀 있지 않다.
이 문제를 정면으로 파고든 사례가 캔버스 에이전트 프로젝트 Easel의 사례다. dev.to에 공유된 구현 노트에 따르면, 에이전트는 오전 5시 53분 세션에서 보드 위 이미지에 대한 질문을 받고 솔직하게 고백했다. "파일 참조는 볼 수 있지만 픽셀 자체는 볼 수 없습니다." 같은 에이전트, 같은 모델이 세 시간 뒤 스크린샷 기능을 갖춘 세션에서는 시각적으로 잘린 제목을 스스로 발견하고 텍스트 박스를 넓혔다. JSON 문서에는 아무 이상이 없었다. 요소도 존재했고, 너비 값도 양수였고, 텍스트도 온전했다. 그러나 실제 CSS가 실제 글리프를 실제 너비에서 감쌌을 때 잘렸다는 사실은, 오직 렌더 타임에만 픽셀로 존재했다.
이 지점이 렌더링 전략과 AI 에이전트가 만나는 교차점이다. SSR이라면 서버가 HTML을 완성해 내려보내므로 에이전트가 응답 HTML을 파싱하면 어느 정도 최종 구조를 읽을 수 있다. SSG나 ISR이라면 빌드된 HTML 파일이 존재하므로 정적 분석이 가능하다. 반면 CSR은 브라우저가 JS를 실행한 뒤에야 DOM이 완성되므로, 에이전트가 소스 HTML만 보면 <div id="app"></div> 하나만 보인다—아무것도 없는 것과 같다. 렌더링 전략의 선택이 에이전트의 '가시성'을 근본적으로 결정하는 것이다.
Easel 팀이 내린 해법은 구조적으로 명쾌하다. 에이전트에게 두 채널을 준다. 문서 모델은 변이(mutation)를 위해, 픽셀은 판단(judgment)을 위해. 구현은 의도적으로 단순하다. 사이트는 보드를 JS 없이 동일한 CSS로 렌더링하는 읽기 전용 라우트를 노출한다. 에이전트 세션마다 board id를 HMAC으로 서명한 토큰을 발급해 해당 라우트에만 접근하게 하고, Playwright가 실제 브라우저로 그 라우트를 열어 JPEG 스크린샷을 찍어 모델에 전달한다. 세션당 다섯 장. 비용은 서른 센트. 작업 리듬은 '보고, 수정하고, 다시 본다'로 자연스럽게 수렴했다.
여기서 핵심 설계 원칙 하나가 도출된다. 브라우저가 유일한 정직한 증인이다. 서버에서 JSON을 래스터라이즈하거나 레이아웃을 텍스트로 묘사해 모델에 넘기는 지름길은, 결국 두 번째 렌더러를 만드는 것과 같다. 두 번째 렌더러는 첫 번째 렌더러에서 표류한다. Easel에서 잡힌 클리핑 버그는 정확히 실제 CSS가 실제 글리프를 실제 너비에 감쌌기 때문에 발생했다. 자체 래스터라이저는 그 버그를 버그-포-버그로 재현해야만 의미가 있다. 실제 브라우저를 쓰는 이유는 사용자가 보는 것과 에이전트가 보는 것이 같은 화면이 되기 때문이다.
프론트엔드 개발자 입장에서 이 흐름이 가리키는 시사점은 분명하다. 렌더링 전략을 고를 때 우리는 늘 "사용자가 언제 콘텐츠를 보는가"를 기준으로 삼아왔다. 이제는 질문 하나가 더 붙는다. "에이전트가 렌더링 결과를 얼마나 관찰할 수 있는가." CSR 중심의 SPA는 에이전트에게 빈 껍데기를 보여준다. SSR이나 SSG 기반 구조는 에이전트가 실제 HTML을 읽을 수 있는 진입점을 자연스럽게 제공한다. ISR의 on-demand revalidation은 에이전트가 데이터 변경을 감지하고 페이지 재생성을 직접 트리거하는 워크플로우와도 연결된다. 렌더링 전략이 단순히 성능과 SEO의 문제가 아니라 에이전트 아키텍처의 설계 조건이 되는 시대가 오고 있다.
빠른 프로토타이핑→검증→고도화의 흐름을 중요하게 생각하는 팀이라면, 이 관점을 일찍 내재화할수록 유리하다. 에이전트에게 스크린샷 채널을 주는 것은 서른 센트짜리 기능 추가가 아니다. 에이전트가 시각적 판단을 내릴 수 있는 구조를 설계하는 것이다. 그리고 그 구조의 전제조건은 렌더링 결과가 에이전트에게 관찰 가능한 형태로 존재하는 것—즉, 렌더링 전략의 선택으로부터 시작한다.