AI 에이전트를 실제 프론트엔드 작업에 투입하기 시작하면 세 가지 현실 문제가 거의 동시에 터진다. 에이전트가 생성한 컴포넌트가 5만 개 아이템을 렌더링하다 브라우저를 멈추게 하거나, 어제 내린 아키텍처 결정을 오늘 세션에서 아무렇지 않게 되돌리거나, 자동화 스크립트가 픽셀 좌표를 못 찾아 허공을 클릭한다. 이 세 가지는 서로 별개의 이슈처럼 보이지만, 공통된 뿌리가 있다. '에이전트가 잘 동작하는 환경 자체를 우리가 설계하지 않았다'는 것이다.
1. 대규모 리스트 렌더링: 에이전트가 짠 코드가 실제로 버티는지 확인하는 법
dev.to의 실전 가이드(Rendering Large Lists on the UI — A Pragmatic Guide)는 FTP 파일 목록과 RAG 시스템 데이터를 카드로 표시하는 프로젝트에서 도출된 4단계 아키텍처를 공유한다. AI 에이전트는 items.map()으로 전체 목록을 렌더링하는 초안을 순식간에 만들어주지만, 아이템이 5만 개로 늘어나는 순간 DOM 노드 생성 비용이 UI를 수 초간 멈추게 한다. JSON 바디 한계 초과, 힙 오버플로, 탭 크래시까지 이어지는 건 시간문제다.
해법은 단계적 레이어 추가다. 먼저 react-window로 가상화를 적용하면 뷰포트에 보이는 10~15개 노드만 유지되어 렌더링이 즉각적으로 빨라진다. 다음은 데이터 자체를 줄이는 커서 페이지네이션이다. 오프셋 방식이 아닌 키셋 커서(createdAt, id 복합키)를 쓰면 삽입·삭제가 발생해도 페이지 경계가 흔들리지 않는다. 여기에 슬라이딩 윈도우(최대 3페이지·150개 아이템)를 얹으면 힙 점유량을 일정하게 통제할 수 있다. 마지막으로 IndexedDB 캐시 레이어를 추가해 퇴출된 페이지를 로컬에 보관하면, 사용자가 위아래로 스크롤을 반복해도 불필요한 백엔드 호출이 사라진다.
프론트엔드 개발자 관점에서 이 4단계의 진짜 의미는 성능 예산이다. 에이전트가 초안 코드를 빠르게 만들어줄수록, "이 코드가 Core Web Vitals 기준에서 실제로 버티는가"를 검증하는 기준선을 먼저 팀이 갖고 있어야 한다. 가상화·커서 페이지네이션·슬라이딩 윈도우는 그 기준선을 코드 레벨로 구체화한 설계 패턴이다.
2. 컨텍스트 지속성: 에이전트가 어제의 결정을 기억하게 만드는 구조
AI 모델은 세션 간에 완전히 무상태다. 새 채팅을 열거나 모델을 바꾸는 순간, 에이전트는 어제의 아키텍처 결정을 전혀 모르는 상태로 리셋된다. dev.to의 또 다른 글(I Stopped Re-Explaining My Codebase to AI Agents)은 이 문제를 '레포지토리 자체를 에이전트의 장기 기억으로 만들기'라는 발상으로 해결한다.
핵심은 두 가지 구조물이다. 루트에 두는 AGENTS.md는 에이전트가 자동으로 읽는 단일 진입점으로, 프로젝트 개요·황금 규칙·문서 맵을 담는다. 그 아래 agent-sitemap/ 폴더에는 아키텍처·데이터 모델·컨벤션·워크플로우·플레이북 등을 모듈 단위 마크다운으로 분리해 보관한다. 에이전트는 AGENTS.md를 먼저 읽고 현재 태스크에 필요한 파일만 선택적으로 로드해 컨텍스트 윈도우 낭비를 막는다.
이 구조가 살아있으려면 '문서 동기화 루프'가 필수다. 매 프롬프트마다 에이전트가 새 지식을 감지(DETECT)하고, 태스크를 수행(ACT)한 뒤, 같은 턴에 해당 문서를 업데이트(RECORD)하고, 어떤 파일을 수정했는지 명시적으로 보고(CONFIRM)하도록 규칙을 박는다. 중요한 건 WHAT이 아니라 WHY를 기록하는 것이다. "카드 레이아웃을 리스트로 되돌리지 말 것—이유: 모바일 뷰포트 스케일링 때문"처럼 결정 맥락이 남아야 다음 세션의 에이전트(혹은 새로 합류한 개발자)가 '의도된 동작'을 실수로 되돌리지 않는다.
이 패턴이 프론트엔드 팀에 주는 시사점은 명확하다. 디자인 시스템의 컴포넌트 결정, 상태 관리 선택의 이유, 성능 트레이드오프—이런 것들이 코드 안에만 묻혀 있으면 에이전트는 매번 처음부터 추론해야 한다. agent-sitemap/은 팀의 집단 기억을 에이전트가 읽을 수 있는 형식으로 외재화하는 인프라다.
3. 브라우저 자동화: 스크린샷이 아닌 접근성 트리로 클릭하기
Claude + Playwright MCP 조합(Browser Automation with Claude + Playwright MCP)은 AI 에이전트가 브라우저를 자동화하는 방식의 근본적인 접근을 바꾼다. 기존의 '비전 모델이 스크린샷을 보고 좌표를 추정해 클릭'하는 방식은 본질적으로 불안정하다. 픽셀 레이아웃이 조금만 바뀌어도 자동화가 깨진다.
Playwright MCP가 선택한 경로는 접근성 트리 스냅샷이다. 페이지의 모든 인터랙티브 요소에 안정적인 참조값(ref)이 부여되어, 에이전트는 좌표를 추정하지 않고 "이 버튼"을 명시적으로 타겟팅한다. 토큰 효율도 극적으로 차이난다. 접근성 스냅샷은 200~400토큰인 반면 스크린샷이나 풀 DOM 덤프는 수천 토큰을 소비한다. claude mcp add playwright npx @playwright/mcp@latest 한 줄이면 Claude Code에서 바로 로컬 Chromium과 연결된다.
프론트엔드 개발자에게 이건 단순한 자동화 도구 이상이다. E2E 테스트를 자연어로 기술하고, 반복적인 폼 플로우나 회귀 테스트를 에이전트에게 위임할 수 있다는 의미다. 다만 캔버스나 커스텀 위젯처럼 접근성 트리 밖에 있는 요소는 여전히 한계가 있고, 민감한 작업에는 사람이 루프 안에 있어야 한다. 접근성(a11y)을 잘 설계한 컴포넌트일수록 AI 자동화가 더 잘 동작한다는 점도 흥미로운 역설이다.
세 축이 가리키는 하나의 방향
렌더링 성능·컨텍스트 지속성·브라우저 자동화는 각각 독립된 기술 문제처럼 보이지만, 실제로는 같은 질문에 대한 세 가지 답이다. "AI 에이전트가 실제로 신뢰할 수 있는 결과물을 만들려면, 그 환경을 어떻게 설계해야 하는가?" 에이전트는 빠르지만 무상태이고, 강력하지만 맥락이 없으며, 자동화하지만 UI 구조에 종속된다. 이 세 가지 약점을 보완하는 설계를 팀이 먼저 갖추지 않으면, 에이전트의 속도는 오히려 기술 부채의 속도가 된다.
앞으로의 방향은 이 세 레이어가 점점 더 긴밀하게 연결되는 것이다. 접근성 트리 기반 자동화가 성숙해질수록 컴포넌트 설계 단계에서 a11y를 고려해야 하는 이유가 하나 더 생기고, 컨텍스트 문서화 구조가 정교해질수록 에이전트의 아키텍처 판단이 팀의 의도에 더 가까워진다. 성능 레이어 설계는 에이전트가 생성한 코드의 품질을 검증하는 기준선이 된다. 결국 AI 에이전트와 함께 일하는 프론트엔드 개발자의 핵심 역량은 '더 좋은 프롬프트 쓰기'가 아니라 '에이전트가 잘 동작할 수 있는 환경을 먼저 설계하기'로 이동하고 있다.