구글 순위 3~5페이지에 머물던 사이드 프로젝트가, 백링크 한 줄 없이 전체 세션의 65%를 ChatGPT에서 끌어왔다. dev.to에 공유된 이 사례는 단순한 성공담이 아니다. 프론트엔드 개발자라면 여기서 하나의 신호를 읽어야 한다. AI 답변 엔진은 도메인 권위가 아니라 기계가 얼마나 쉽게 읽을 수 있는가를 인용 기준으로 삼는다.
같은 시점, GitHub은 접근성 프로그램 5주년을 맞아 AI 기반 접근성 스캐너를 공개했다. GitHub Copilot 클라우드 에이전트가 WCAG 위반을 탐지하고, Figma 주석 툴킷이 설계 단계부터 접근성 문제를 잡아낸다. 두 소식은 출처도 맥락도 다르지만, 같은 방향을 가리킨다. AI가 읽고 평가하는 프론트엔드 품질 기준이 이미 바뀌고 있다는 것.
AI 인용 최적화: 기존 SEO와 무엇이 다른가
전통적인 SEO는 도메인 나이와 백링크 자산이 지배하는 게임이었다. 신규 도메인이 경쟁력 있는 키워드에서 상위 노출되려면 최소 6~12개월이 필요하다는 게 업계의 통설이다. 그런데 ChatGPT Search, Perplexity, Copilot 같은 AI 답변 엔진은 다른 룰을 적용한다. 열 개의 링크를 나열하는 대신, 가장 명확하게 질문에 답하는 페이지 한두 개를 인용한다. 도메인 권위보다 정보의 추출 가능성이 먼저다.
dev.to 사례의 개발자가 3개월 만에 AI 인용 트래픽을 만들어낸 방법은 놀랍도록 구체적이다. 핵심은 세 가지로 압축된다. 첫째, /llms.txt—브랜드 정보, 핵심 페이지, 인용 가이드를 담은 plain-text 파일로, AI 엔진에게 사이트 구조를 직접 전달하는 robots.txt의 LLM 버전이다. 둘째, FAQPage와 mainEntity Question 스키마—각 페이지가 어떤 질문에 답하는지를 기계가 읽을 수 있는 JSON-LD로 선언한다. 셋째, 서버사이드 렌더링—curl로 가져온 HTML에 답변 텍스트가 없다면, AI 크롤러에게도 그 페이지는 빈 페이지다.
Next.js App Router를 쓰는 프론트엔드 개발자라면 이 전략이 낯설지 않다. RSC(React Server Components)로 FAQ 블록을 서버에서 렌더링하고, generateMetadata에서 JSON-LD를 주입하고, middleware.ts에서 AI 봇 트래픽을 태깅하는 흐름은 기존 Next.js 아키텍처와 자연스럽게 맞물린다. 새로운 기술 스택이 아니라, 기존 스택의 의도적인 활용이다.
GitHub의 AI 접근성 스캐너가 보여주는 다른 차원의 '기계가 읽는 품질'
AI가 읽는 프론트엔드 품질에는 또 다른 층위가 있다. GitHub이 공개한 AI 기반 접근성 스캐너는 Copilot 에이전트와 Deque Systems의 오픈소스 axe-core 라이브러리를 결합해 WCAG 위반을 자동으로 탐지하고 수정 PR까지 생성한다. 접근성 감사 데이터를 분석한 결과 문제의 48%가 설계 단계에서 예방 가능했다는 사실도 함께 공개했다. 그래서 함께 내놓은 것이 Figma 주석 툴킷—제목 계층, 키보드 탐색 흐름, ARIA 시맨틱을 디자인 파일 안에 문서화하는 라이브러리다.
여기서 놓치면 안 되는 구조적 포인트가 있다. 이 스캐너는 GitHub Marketplace와 오픈소스 저장소 형태로 제공되며, 팀이 직접 포크해 CI/CD 파이프라인에 통합할 수 있다. WCAG 1.4.10 리플로 위반을 잡아내는 내장 플러그인도 최근 추가됐다. 즉, 접근성 검증이 배포 게이트에 들어오는 시대가 실제로 열리고 있다는 뜻이다. 스크린리더가 읽지 못하는 컴포넌트는 AI 검수 파이프라인도 통과하지 못하게 된다.
두 흐름이 수렴하는 지점: '기계 가독성'이 품질의 기본값
표면적으로 두 소식은 달라 보인다. 하나는 트래픽 최적화, 다른 하나는 접근성 자동화다. 그런데 한 발 물러서서 보면 같은 원리가 작동하고 있다. AI가 읽고, 판단하고, 인용하거나 통과시키는 기준이 명시적으로 설계된 시맨틱 구조와 추출 가능한 정보에 달려 있다는 것. 구조화된 데이터가 ChatGPT 인용을 만들고, 올바른 ARIA 시맨틱이 Copilot 접근성 스캐너를 통과시킨다. 기계 가독성은 더 이상 검색 엔진만을 위한 최적화가 아니다.
프론트엔드 개발자 입장에서 이 전환은 실무 체크리스트를 바꾼다. 컴포넌트를 만들 때 "스크린리더가 이걸 읽을 수 있나"와 "AI 크롤러가 이 페이지의 핵심 답변을 첫 문장에서 추출할 수 있나"는 이제 같은 질문의 두 형태다. 둘 다 마크업의 의도가 명확할 때 답이 '예스'가 된다.
지금 당장 할 수 있는 것
거창한 리팩토링 없이도 시작할 수 있다. /llms.txt를 추가하고, 핵심 FAQ 페이지에 FAQPage JSON-LD를 붙이고, curl로 서버 렌더링을 검증하고, robots.txt에서 GPTBot과 PerplexityBot 차단을 해제하는 것—여기까지는 반나절이면 된다. CI/CD에 axe-core 기반 접근성 검사를 붙이는 것도 GitHub의 오픈소스 스캐너를 포크하면 출발점이 이미 마련되어 있다.
더 중요한 건 관점의 전환이다. AI 답변 엔진 시대에 프론트엔드 품질의 심판관은 구글 봇만이 아니다. ChatGPT, Perplexity, Copilot이 우리가 만든 페이지를 읽고 인용할 가치가 있는지 판단한다. 동시에 GitHub의 AI 스캐너는 우리가 만든 컴포넌트가 모든 사용자에게 열려 있는지를 배포 전에 검사한다. '기계가 읽을 수 있는 코드'는 이제 접근성과 발견 가능성, 두 품질 축을 동시에 결정하는 기준이 됐다.