프론트엔드 개발자가 오랫동안 당연하게 여겨온 전제들이 조용히 흔들리고 있다. SSR과 클라이언트 렌더링 사이의 경계는 AI가 코드를 생성하면서 더 자주 깨지고, 코드 리뷰와 PR은 에이전트가 제출하는 양이 사람을 넘어서기 시작했으며, 웹사이트를 최적화하는 대상도 구글 봇에서 LLM으로 조용히 이동하는 중이다. 세 가지 소식이 각각 다른 층위에서 같은 방향을 가리키고 있다.
첫 번째: 하이드레이션 경계를 명시적으로 설계하라
Next.js App Router를 쓰다 보면 누구나 한 번쯤 마주치는 오류가 있다. Text content does not match server-rendered HTML. dev.to에 올라온 실전 디버깅 가이드는 이 오류의 뿌리를 정확하게 짚는다—서버에서 만든 HTML 트리와 클라이언트 첫 렌더 트리가 일치하지 않을 때 React 하이드레이션이 실패한다는 것. 원인은 언제나 같다. Date.now()나 localStorage, window 같은 브라우저 전용 API를 서버 렌더 사이클 안에서 건드렸을 때다.
흥미로운 건 이 문제가 AI 코드 생성과 맞물려 더 빈번해지고 있다는 점이다. AI가 컴포넌트를 뚝딱 만들어줄 때, 서버/클라이언트 경계에 대한 명시적 설계 없이 useState 초기값에 new Date()를 바로 꽂아버리는 패턴이 자주 등장한다. 결과는 로컬에서는 정상, 프로덕션에서는 깨지는 하이드레이션 오류다.
해법은 세 가지 규칙으로 정리된다. 클라이언트 전용 콘텐츠—날짜, 타이머, 랜덤 ID 등—는 suppressHydrationWarning을 해당 엘리먼트에만 좁게 적용하거나, useEffect 안으로 초기화 로직을 옮겨야 한다. window나 localStorage에 의존하는 컴포넌트 전체가 서버에서 렌더될 필요가 없다면 next/dynamic에 { ssr: false } 옵션을 달아 SSR 대상에서 아예 제외하는 게 깔끔하다. iOS 자동 감지 메타태그(format-detection)나 Cloudflare Auto Minify 같은 CDN 설정이 HTML을 건드려 하이드레이션을 깨는 경우도 있으니 layout.tsx 레벨에서 미리 막아두는 습관이 필요하다.
한 줄 규칙으로 정리하자면 이렇다. SSR과 첫 렌더 사이에 달라질 수 있는 모든 값은 반드시 명시적인 경계로 감싸야 한다. AI가 코드를 생성하는 속도가 빠를수록, 이 경계 설계를 사람이 더 의식적으로 잡아줘야 한다.
두 번째: 코드 인프라를 '에이전트 중심'으로 다시 설계하라
Cursor가 코드 호스팅 플랫폼 Origin을 베타 출시했다. AI타임스 보도에 따르면 핵심 메시지는 선명하다—"사람을 위한 코드 호스팅에서 에이전트를 위한 코드 호스팅으로." 코드 저장, PR 작성·리뷰·병합, 에이전트 작업을 하나의 작업 공간에서 처리할 수 있게 묶은 플랫폼이다.
이 발표가 단순한 GitHub 경쟁자 등장으로 읽히면 곤란하다. 핵심은 전제의 전환이다. GitHub은 사람이 코드를 쓰고, 사람이 리뷰하고, 사람이 병합하는 흐름을 기본으로 설계됐다. 그런데 Cursor 내부에서는 이미 병합되는 PR 중 상당 비율을 AI 에이전트가 자율적으로 생성하고 있다고 알려졌다. 에이전트가 PR을 제출하는 속도가 사람의 리뷰 속도를 초과하기 시작하면, 기존의 코드 인프라 자체가 병목이 된다.
Origin의 설계 전략도 실용적이다. GitHub을 당장 버리지 않아도 된다—GitHub 조직을 연결하면 원하는 저장소가 Origin에 동기화되고, GitHub은 계속 소스 오브 트루스로 유지된다. Origin에서 남긴 PR 댓글과 리뷰는 GitHub과 양방향 동기화된다. Vercel 연동으로 PR마다 미리보기 배포가 생성되고, Depot·Buildkite로 기존 GitHub Actions 워크플로를 그대로 실행할 수 있다. 점진적 전환 전략이다.
프론트엔드 개발자 입장에서 이 흐름이 의미하는 건 무엇인가. PR 리뷰의 성격이 달라진다는 것이다. 사람이 작성한 코드를 사람이 검토하는 구조에서, 에이전트가 제출한 코드를 사람이 선택적으로 검토하고 에이전트가 1차 검토를 돕는 구조로 이동한다. 리뷰 기준과 자동화 범위를 팀 차원에서 명시적으로 설계하지 않으면, 속도만 올라가고 품질 게이트는 사라지는 상황이 온다.
세 번째: 웹사이트를 AI가 '이해'할 수 있도록 설계하라
dev.to에 올라온 AIO(AI Optimization) 분석 글은 불편한 질문을 던진다. "Lighthouse 점수 만점, 사이트맵 완벽, 구조화 데이터까지 달린 웹사이트가 있다. 이제 ChatGPT에게 물어봐라—이 회사가 뭘 하는 곳이냐고." 답이 엉터리거나 불완전할 수 있다. 크롤 가능한 것과 이해 가능한 것은 다른 문제이기 때문이다.
검색엔진은 페이지를 발견하고 순위를 매기는 것이 목표다. AI 에이전트는 정보를 이해하고 질문에 답하거나 액션을 수행하는 것이 목표다. 이 두 목표는 요구하는 신호 체계가 다르다. 검색엔진 최적화가 키워드·백링크·Core Web Vitals를 쌓는 게임이었다면, AI 가독성은 콘텐츠 위계의 일관성, 구조화 데이터와 실제 콘텐츠의 일치, 페이지 간 관계의 명시성을 요구한다.
여기서 등장한 개념이 llms.txt다. 수천 페이지를 AI가 직접 크롤해 추론하게 하는 대신, 사이트의 핵심 구조와 중요 콘텐츠를 기계가 읽기 좋은 형태로 명시적으로 제공하는 진입점이다. sitemap.xml이 검색엔진에게 지도를 그려줬다면, llms.txt는 AI 에이전트에게 맥락 요약본을 건네는 것에 가깝다.
프론트엔드 개발자에게 이게 왜 중요한가. 앞으로 웹의 독자가 셋이 된다는 이야기이기 때문이다—사람, 검색엔진, 그리고 AI 에이전트. 세 번째 독자는 검색엔진보다 맥락을 더 깊이 요구하면서도, 사람처럼 시각적 단서를 활용하지 못한다. 헤딩 구조가 논리적인지, 메타데이터가 실제 콘텐츠와 일치하는지, 내부 링크가 관계를 드러내는지—이런 결정들이 단순한 SEO 체크리스트를 넘어 AI 시대의 정보 설계 기준이 된다.
세 흐름이 가리키는 하나의 방향
하이드레이션 경계 설계, 에이전트 중심 코드 인프라, AI 가독성 최적화—세 주제는 표면적으로 달라 보이지만 같은 압력에서 나온다. AI가 코드를 만들고, 코드를 관리하고, 콘텐츠를 소비하는 행위자로 부상하면서, 지금까지 암묵적으로 유지해온 '사람 중심' 전제들이 하나씩 명시적으로 설계돼야 하는 대상이 되고 있다.
명시적 설계라는 말이 핵심이다. 하이드레이션 경계도, PR 리뷰 기준도, 콘텐츠 구조도—AI가 개입하기 전에는 관행과 암묵적 이해로 돌아가던 것들이다. 에이전트가 그 사이사이를 채우기 시작하면서, 설계되지 않은 부분이 곧 취약점이 된다. 프론트엔드 개발자가 에이전트 시대에 새로 짊어지게 된 역할은, 더 많은 코드를 짜는 것이 아니라 더 정밀한 경계와 맥락을 설계하는 것이다.