웹 서비스의 '품질'을 이야기할 때 SEO와 접근성은 보통 따로 다뤄진다. SEO는 마케팅 팀의 요구사항이고, 접근성은 컴플라이언스 체크리스트처럼 여겨지는 경우가 많다. 하지만 이 둘은 근본적으로 같은 질문에서 출발한다. "이 콘텐츠가 올바른 맥락에서 올바른 사람에게 제대로 전달되는가?" 최근 dev.to에 공개된 두 편의 글이 이 관점을 실무 코드 수준에서 구체화해줬다.
ISR과 구조화 데이터로 SEO를 설계한다는 것
Nathan Denier가 공개한 Pick an Agency 디렉토리 구축기는 Next.js App Router로 수천 개 페이지의 SEO를 어떻게 설계했는지를 보여준다. 핵심은 세 가지다.
첫째, ISR(Incremental Static Regeneration)을 캐싱 전략의 중심으로 삼은 것. 리스팅 페이지에 revalidate = 3600을 적용하고, DB 쿼리 레이어에는 unstable_cache로 태그 기반 무효화를 더했다. 결과적으로 엣지 캐시 덕분에 TTFB는 빠르고, 데이터는 최대 1시간 주기로 갱신되며, 풀 리빌드 없이 특정 캐시만 날릴 수 있다. SSR 대비 인프라 비용과 응답 속도 양쪽에서 이득을 챙긴 구조다.
둘째, Schema.org 마크업을 페이지 타입별로 세분화한 점이다. 에이전시 개별 페이지에는 LocalBusiness + ProfessionalService + AggregateRating을, 리스팅 페이지에는 ItemList를, 지역 페이지에는 도시→국가 계층을 표현하는 Place + containedInPlace를 얹었다. 모든 페이지에는 BreadcrumbList가 공통 적용된다. 단순히 메타 태그를 채우는 수준이 아니라, 검색엔진이 콘텐츠의 관계와 맥락을 이해할 수 있도록 데이터 모델링을 한 셈이다.
셋째, 수천 페이지의 중복 콘텐츠 문제를 해시 기반 문장 풀로 해결한 것. 페이지 고유 콘텐츠(서비스명 등)를 시드로 삼아 opener·middle·closer 문장을 조합하면, 두 페이지가 동일한 인트로 텍스트를 갖는 경우가 구조적으로 발생하지 않는다. LLM으로 페이지마다 텍스트를 생성하는 방법도 있지만, 비용과 지연 없이 결정론적으로 유니크함을 보장하는 이 접근은 디렉토리 규모의 사이트에서 실용적인 선택이다.
RGAA 자동화가 던지는 진짜 질문
두 번째 글은 접근성 측면에서 유럽 시장을 겨냥한 도전을 다룬다. 2025년 6월 유럽 접근성 법(EAA)이 시행되면서, EU에서 디지털 서비스를 판매하는 기업은 접근성 준수가 법적 의무가 됐다. 문제는 Axe, WAVE, Lighthouse 같은 기존 도구들이 모두 WCAG 기준으로 작동한다는 점이다. 프랑스의 RGAA 4.1은 WCAG 2.1 AA를 기반으로 하되 106개 기준과 13개 테마로 구성된 독자적인 체계다. 두 기준은 겹치지만 동일하지 않다.
Chabane Lemared가 만든 도구의 핵심 인사이트는 62%의 자동화 가능 지점을 '어떻게 알려주느냐'에 있다. axe-core를 감지 엔진으로 쓰되, 그 위에 RGAA 매핑 레이어와 패턴 감지 레이어를 얹었다. 패턴 감지가 결정적이다. "50개 페이지에 걸쳐 287개 이미지에 alt 속성 누락"이라고 나열하는 대신, "이 하나의 컴포넌트를 수정하면 287개 위반이 해결됩니다"라고 알려준다. 같은 CSS 셀렉터, 같은 컴포넌트 계층, 같은 위반 유형을 하나의 패턴으로 묶는 DOM 비교 방식이다.
두 흐름이 만나는 지점
두 사례를 나란히 놓으면 공통 구조가 보인다. 자동화 가능한 영역을 먼저 최대한 기계에 맡기고, 사람의 판단이 필요한 영역에 집중력을 몰아준다는 원칙이다.
SEO 관점에서는 ISR과 캐싱 전략이 반복적인 렌더링 비용을 흡수하고, 구조화 데이터 컴포넌트가 마크업 일관성을 보장한다. 개발자는 데이터 모델과 비즈니스 로직에 집중할 수 있다. 접근성 관점에서는 자동화가 62%의 반복 검사를 커버하고, 남은 38%—시맨틱 적절성, 키보드 내비게이션 품질, 스크린 리더 경험—는 전문가 판단 영역으로 남긴다. CI/CD에 RGAA 임계값 체크를 걸어 점수가 떨어지면 PR을 블로킹하는 구조는, 접근성을 릴리즈 게이트로 만드는 실질적인 방법이다.
프로토타이핑 이후의 진짜 고도화
AI 도구로 빠르게 컴포넌트를 뽑아내는 시대일수록, 이 두 축의 중요성은 오히려 커진다. 생성된 코드가 Schema.org를 올바르게 품고 있는지, ARIA 속성이 맥락에 맞게 붙어 있는지는 프롬프트가 자동으로 보장해주지 않는다. 이전 글에서도 다뤘듯, ARIA 오류의 상당수가 AI 생성 코드에서 반복적으로 발견된다.
실용적인 접근은 명확하다. Next.js App Router 프로젝트라면 ISR 전략과 타입별 구조화 데이터를 초기 아키텍처 결정 시점에 포함시켜라. 접근성 자동화 도구(axe-core 기반이든, RGAA 매핑 레이어든)를 CI에 붙여 회귀를 방지하라. 그리고 자동화가 커버하지 못하는 영역—콘텐츠의 의미, 인터랙션의 흐름—에 리뷰 에너지를 집중하라.
전망: 로컬 표준이 새로운 기술 부채가 된다
RGAA 자동화 도구를 만든 개발자의 관찰 중 가장 날카로운 지점은 따로 있다. "모든 글로벌 도구는 WCAG를 말한다. 유럽에는 27개 국가가 있고, 각자의 접근성 표준이 있다." 한국도 예외가 아니다. KWCAG(한국형 웹 콘텐츠 접근성 지침)는 WCAG와 겹치지만 동일하지 않으며, 공공기관 대상 서비스는 별도 기준을 따른다.
글로벌 서비스를 만드는 팀이라면, SEO와 접근성 모두에서 '국제 표준 준수'만으로는 충분하지 않은 시장이 빠르게 늘고 있다는 점을 설계 초기부터 고려해야 할 시점이다. 로컬 표준은 새로운 형태의 기술 부채가 될 수 있다—대응하지 않으면 쌓이고, 나중에 한꺼번에 갚아야 한다.