---
title: "접근성 측면에서 분석한 무한 스크롤과 그 대안"
description: "사용자를 붙잡는 무한 스크롤, 정말 모두에게 좋은 UX일까요? 접근성 측면에서 무한 스크롤을 분석하고 ⏱️째깍악어🐊의 사례에서 인클루시브한 대안을 고민해 봅니다."
date: 2026-02-14
tags: [a11y, ux, design-system]
sections: [human]
draft: false
---

> 많은 웹서비스에서 ‘무한 스크롤’은 이제 당연한 기능으로 자리잡은 듯합니다. 이 글에서는 접근성 측면에서 무한 스크롤 기능을 분석해보고, 보완된 형태의 대안을 제시하려 합니다. 인클루시브한 디자인의 무한 스크롤을 고민하시는 개발자분들, 디자이너분들께 많은 도움이 되길 바라며 글을 정리합니다.

얼마전 EU에서 틱톡의 무한 스크롤이 **중독적인 디자인**이며, 법적인 조치를 취할 것임을 암시하는 결정을 내렸습니다([기사](https://www.nytimes.com/2026/02/06/business/tiktok-addictive-design-europe.html)). 무한 스크롤의 디자인 자체의 결함을 전제하는 것은 아니겠지만 이미 많은 서비스에서 관습적으로 사용되는 무한 스크롤을 지적했다는 점에서 큰 파장이 있을 것이라고 예상하고 있습니다. 

다만 제가 주목한 지점은 무한 스크롤 패턴의 중독성보다는 **취약한 접근성**이었는데요, 서비스를 개발, 운영하는 입장에서 무한 스크롤을 도입하며 고민했던 지점들과 타협점을 다시 정리해보려 합니다.

## 모바일 시대, 당연한 무한 스크롤

모바일 환경에서 무한 스크롤은 이제 업계 표준처럼 자리잡았습니다. 이러한 디자인이 당연한 표준으로 자리 잡은 가장 큰 이유는 **사용자의 인지 부담을 획기적으로 낮추기 때문**이라고 볼 수 있습니다. 모바일 기기의 기본 탐색 제스처인 스와이프를 그대로 활용하기에 사용자는 별도의 클릭이나 페이지 전환 없이도 손가락 하나만으로 끝없이 정보를 탐색할 수 있습니다. 제스처의 변화를 주지 않아도 된다는 이 단순함은 사용자에게 심리적 편안함을 제공하며 탐색의 몰입도를 극대화합니다.

이러한 매끄러운 경험은 **비즈니스 지표 측면에서도 강력한 힘을 발휘**합니다. 페이지 체류 시간과 콘텐츠 노출 수를 크게 증가시키기 때문입니다. 이 때문에 SNS나 이커머스처럼 아이템의 탐색과 발견이 중요한 서비스에서 무한 스크롤은 특히 당연한 디자인으로 활용됩니다. 최근 네이버가 모바일 홈 화면을 피드형으로 재구성하며 그 근거로 사용자 체류 시간의 비약적 증가를 꼽은 것은 무한 스크롤이 성공을 보장하는 디자인으로 통용되고 있음을 단적으로 보여주는 대표적인 사례입니다([기사](https://www.joongang.co.kr/article/25377566)).

| 네이버의 피드형 홈 개편 |
| :-: |
| ![네이버의 피드형 홈 개편](https://velog.velcdn.com/images/ksr20612/post/9c8d1a09-077a-4160-a4a2-72e56cf791a0/image.gif) |

하지만 이러한 이점 이면에는 간과하기 쉬운 함정이 숨어 있습니다. 무한 스크롤이 사용자를 붙잡아두는 좋은 디자인이라는 패턴으로 받아들여지면서 오히려 그 전제 조건이 되는 **탐색성과 접근성에 대한 논의는 상대적으로 충분히 다뤄지지 못한 경우도 많다**는 것입니다. 데이터 탐색을 용이하게 하려고 도입한 기능이 아이러니하게도 실제 결과물에서는 특정 사용자 층의 탐색을 가로막는 장벽이 되고 마는 것입니다.


## WCAG로 무한 스크롤 바라보기

WCAG의 POUR 원칙에서 무한 스크롤을 해석해보려 합니다. POUR 원칙을 통해 무한 스크롤의 구조적인 결함을 확인하는 동시에 개선 방향성도 포착할 수 있을 것입니다.

### Perceivable

**무한 스크롤의 동작 전부를 인지하기 쉽지 않습니다.** 새로운 콘텐츠를 불러오고 있는지, 새로운 콘텐츠가 로드 되었는지, 로드되었다면 얼마나 많은 콘텐츠가 새로 아래에 추가되었는지 비시각 사용자가 파악하기 쉽지 않습니다. 비시각 사용자는 더구나 이 리스트가 ‘무한 스크롤’ 패턴인지조차 이해하기 쉽지 않을 수 있습니다.

`role=feed` 와 관련 `aria` 속성을 제공하여 무한 스크롤 패턴임을 명시적으로 알리고, `role=status` 등을 통해 무한 스크롤의 동작을 사용자가 충분히 인지할 수 있게 해야 합니다. 

### Operable

**보조 도구(키보드나 스위치 등) 사용자들은 무한 스크롤 패턴에서 제스처 동작을 수행하기 어렵습니다.** 보조 도구만으로 항목을 탐색하기 어렵기 때문입니다. 특히 운동성 장애를 가지고 있는 사용자는 이러한 제스처 동작이 쉽지 않을 수 있습니다. 

스크롤이라는 제스처에 의존하지 않은 상황에서도 무한 스크롤 패턴이 충분히 조작 가능해야 합니다. 키보드만으로도 충분히 조작이 가능한 상황을 만들거나, 더 나아가 무한 스크롤 외의 다른 옵션을 제공해야할 수도 있습니다.

### Understandable

**무한 스크롤은 콘텐츠의 끝이 어디인지 쉽게 예측하기 어렵습니다.** 물론 전체 콘텐츠의 개수를 같이 노출하여 이를 보완할 수는 있긴 합니다. 다만 얼마나 더 내려야 콘텐츠의 끝에 도달하는지 사용자는 알 방법이 없습니다. 더구나 휘발적인 제스처 동작에 의해 현재 보고 있는 콘텐츠가 전체 콘텐츠 중 어느 지점에 도달했는지 정확하게 알 수 없기 때문에 페이지의 구조는 더욱 예측 불가능합니다.

콘텐츠의 내용과 무한 스크롤 구조를 다양한 사용자에게 정확하게 전달할 수 있어야 합니다. 또한 주된 콘텐츠인 무한 스크롤 구조 밖에 있는 정보들에도 사용자가 쉽게 접근하고 이해할 수 있어야 합니다. 특히 무한 스크롤 하단에 위치한 푸터 등도 쉽게 인지 가능해야 합니다.

### Robust

WCAG에서 접근적인 무한스크롤 패턴을 구현하기 위한 `role=feed` 활용 예제([참고](https://www.w3.org/WAI/ARIA/apg/patterns/feed/))를 제공하긴 하지만, 현실적으로 **아직 여러 보조 도구에서 이 기능을 안정적으로 지원하지 않는 경우가 많습니다.** 심지어 브라우저/보조 도구별 `aria` 지원 여부를 제공하는 [a11ysupport.io](http://a11ysupport.io)에서 `role=feed` 는 여전히 명확하게 찾을 수 없는 정보입니다.

| a11ysupport는 아직 `feed role` 설명을 지원하지 않는다 |
| :-: |
| ![a11ysupport는 아직 `feed role`을 지원하지 않는다](https://velog.velcdn.com/images/ksr20612/post/15246954-045e-4d5c-ab51-645e0cefdbc9/image.png) |

여러 도구에서 안정적으로 호환될 수 없는 기능이라면 다른 옵션을 제공하는 것이 현실적인 대안일 수 있습니다.


## 째깍악어에서 보완한 무한 스크롤

앞서 살펴본 것처럼 무한 스크롤은 WCAG의 POUR 원칙 전반에서 구조적인 한계를 드러냅니다. 하지만 탐색 효율과 비즈니스 지표라는 현실적인 이유로 무한 스크롤을 완전히 배제하기도 어려운 상황입니다. 

그래서 째깍악어에서는 **무한 스크롤을 사용하지 말자**는 결론보다는 **무한 스크롤을 전제로 하되 접근성 리스크를 최소화하는 방향**을 선택했습니다. 즉, WCAG의 POUR 원칙에서 추출한 두 가지 전제를 기반으로 무한 스크롤 패턴을 설계한 것입니다.

- 무한 스크롤 패턴 자체를 보조기기 사용자에게 최대한 **투명하게 드러낼 것**
- 무한 스크롤이라는 상호작용 모델이 맞지 않는 사용자를 위해 **대체 탐색 경로를 제공할 것**

### 기본 장치: `feed` 패턴과 상태 전달의 명시

보조 도구에 무한 스크롤 패턴을 명확하게 전달하기 위해 ARIA의 `feed` 패턴을 적용했습니다. 리스트 컨테이너에는 `role="feed"`, 각 아이템에는 `role="article"`을 부여해 구조를 드러내고, 현재 로딩 상태는 `aria-busy`와 `aria-live` 영역을 통해 사용자에게 전달했습니다.

```jsx
// @dotss/ui의 컴포넌트를 사용합니다. 각 컴포넌트가 궁금하신 분은 ui.tictoccroc.com을 참고해주세요.

const handleClickNextPage = async () => {
 const { data: { pages = [] } = {} } = await fetchNextPage();
 if (pages.length > 0) {
 const amount = pages[pages.length - 1].data?.size || 0;
 setAnnounce(`리뷰 ${amount}개 추가 로드됨`);
 }
};

<Flexbox
 role="feed"
 aria-busy={isPending || isFetchingNextPage}
>
 {items.map((item, index) => (
 <Card
 wrapperProps={{
 role: 'article',
 tabIndex: 0,
 'aria-posinset': index + 1,
 'aria-setsize': items.length,
 }}
 >
 {/* 콘텐츠 */}
 
 ))}
 

 
 {announce}
 
```

이러한 피드 패턴을 통해 다음과 같은 개선 효과를 기대했습니다.

- 사용자는 현재 리스트가 단순한 나열이 아니라 **피드 구조**임을 인지할 수 있다.
- 새로운 콘텐츠가 로드될 때 시각에 의존하지 않고도 **콘텐츠를 로드하고 있는지**, **콘텐츠가 로드되었는지**, **몇 개의 항목이 추가되었는지** 인지 가능하다.
- `article + tabIndex` 를 활용해 키보드 사용자도 콘텐츠를 **아이템 단위로 탐색할 수 있다.**

특히 `aria-posinset`, `aria-setsize`를 함께 제공함으로써, 지금 보고 있는 콘텐츠가 전체 중 어느 위치인지를 어느 정도 파악할 수 있도록 했습니다. 무한 스크롤 구조상 전체 개수는 유동적이지만 **적어도 현재 로드된 범위 내의 맥락은 유지**하고자 한 것입니다.

### 확장: 무한 스크롤을 대체하는 옵션 제공

ARIA를 아무리 잘 적용해도, 무한 스크롤이라는 상호작용 모델 자체가 모든 사용자에게 적합하지는 않습니다. 더구나 피드 패턴이 모든 환경, 모든 기기에서 안정적으로 동작하지 않습니다. 그래서 째깍악어에서는 무한 스크롤을 **강제하지 않는 구조**를 함께 제공했습니다.

| 째깍악어의 무한 스크롤 대체 경로 |
| :-: |
| ![째깍악어의 무한 스크롤 대체 경로](https://velog.velcdn.com/images/ksr20612/post/81443a6a-3e2a-4d92-b9f5-59082ab7c6e3/image.gif) |
| ​❗​ 화면에 노출되는 데이터는 실제 데이터가 아닌 더미 데이터입니다. |


우선 기본 UI에는 노출되지 않지만 키보드 탐색 흐름에서는 접근 가능한 옵션을 두었습니다. 포커스를 받으면 화면에 나타나는 영역을 통해 **무한 스크롤 사용 여부**를 토글할 수 있도록 구성한 것입니다. 이때 해당 영역은 콘텐츠가 노출되는 피드 영역 바로 위쪽에 표시되어 사용자의 자연스러운 시선 이동을 방해하지 않도록 했습니다.

```jsx
 // 포커스를 받으면 해당 영역이 화면에 표시됩니다.
 <Switch
 selected={isInfiniteScrollable}
 onChange={handleChangeInfiniteScrollable}
 />
 무한 스크롤 사용 
 
```

그리고 무한 스크롤 비활성화 시에만 표시되는 [리뷰 더 불러오기] 버튼을 통해 **사용자가 의도적으로 다음 콘텐츠를 로드**할 수 있도록 했습니다. 키보드나 스위치 사용자에게 명확한 조작 경로를 제공한 것입니다.

```jsx
{!isInfiniteScrollable && !isFetchingNextPage && (
 리뷰 더 불러오기 
)}
```

해당 버튼 클릭시 버튼이 사라지기 때문에 포커스 미아 상태가 되긴 하지만 DOM 구조와 브라우저의 자동적인 보간 처리에 의해 다음 포커스 대상은 자동적으로 다음 아티클(콘텐츠)입니다. 물론 브라우저마다 이 포커스의 보간 방식이 조금씩 다르긴 합니다만 구현 복잡도를 줄이는 대신 브라우저와 보조기기 조합에 따른 UX 편차를 감수한 결정이었습니다(이 지점은 접근성 관점에서 이상적인 설계는 아니기 때문에 개선의 여지가 있긴 합니다).

째깍악어의 무한 스크롤 패턴은 완벽하게 접근성을 챙긴 무한 스크롤을 만들었다는 의미보다는 **무한 스크롤이 가진 구조적 한계를 인정한 상태에서 사용자가 탐색 방식을 선택할 수 있도록 한 사례**에 가깝다고 말할 수 있을 것 같습니다. 

| 스크린리더로 읽은 무한 스크롤 |
| :-: |
| ![스크린리더로 읽은 무한 스크롤](https://velog.velcdn.com/images/ksr20612/post/b0410ebc-439f-493b-a790-a2740252d4e4/image.gif) |
| ​❗​ VoiceOver(Tahoe 26)으로 청취한 내용입니다. 기기와 버전에 따라 내용이 상이할 수 있습니다. |


## 마무리하며

지금까지 접근성 측면에서 무한 스크롤 패턴의 취약점을 정리하고 째깍악어에서는 어떤 방식으로 기존의 무한 스크롤 패턴을 보완했는지 살펴보았습니다. 

**이번 리서치를 진행하면서 다시금 접근성에 대한 인식이 많이 부족하다고 느꼈습니다.** 무한 스크롤의 접근성 이슈는 2010년대 후반부터 꾸준히 제기되어 왔지만 5년이 지난 지금도 국내에서의 논의는 더디기만 합니다. 여전히 접근성을 넓은 개발 도메인 중 부차적인 사치 정도로 여기는 시선이 존재하기 때문일 것입니다.

접근성에는 정해진 정답이 없습니다. 하지만 **서비스의 구조와 상황에 맞춰 최선의 대안을 고민하는 과정 자체가 인클루시브 디자인의 시작이라고 믿습니다.** 저 또한 여전히 부족하지만 앞으로도 이런 고민들을 공유하며 접근성이 사치가 아닌 기본이 되는 문화를 만드는 데 기여하고 싶습니다. 긴 글 읽어주셔서 감사합니다.