한 번에 다 쏟지 말고 나눠서

KRDS BP-040 — 긴 목록은 적절하게 단위를 나누어 구분하고, 한 번에 지나치게 많은 정보를 제공하고 있지 않다.

0. 들어가며 — 수백 개를 한 화면에 다 보여주면

이번 606편은 긴 목록을 적절하게 단위로 나누어 구분하고, 한 번에 지나치게 많은 정보를 제공하지 않게 하라는 규칙입니다.

목록 항목이 — 수백, 수천 개인데 한 화면에 다 쏟아내면, 로딩도 느리고 사용자가 압도되죠. BP-040은 긴 목록을 단위로 나누라고 규정합니다. 페이지네이션·무한 스크롤 등 분할의 원칙이죠. 이번 편을 풀어냅니다.

1. 원문 — 단위 분할 + 과다 정보 금지

BP-040 (기본 패턴 > 목록 탐색) “긴 목록은 적절하게 단위를 나누어 구분하고, 한 번에 지나치게 많은 정보를 제공하고 있지 않다.”

긴 목록을 적절한 단위로 나누어 구분하고, 한 번에 과도하게 많은 정보를 보여주지 말라는 뜻입니다.

정리: 긴 목록은 단위로 나눠 한 번에 과다 정보를 안 주게 하라. 이게 BP-040입니다.

2. 왜 긴 목록 분할인가

목록은 항목이 매우 많을 수 있습니다(게시글 수천 개, 검색 결과 수백 개). 이를 한 번에 다 보여주면 문제가 생기죠. BP-040은 긴 목록을 적절한 단위로 나누라고 합니다.

긴 목록을 한 번에 다 보여줄 때의 문제:

로딩 부담·느림 수백·수천 항목을 한 번에 불러와 렌더링하면, 로딩이 느리고 페이지가 무거워집니다. 특히 모바일·느린 네트워크에서 심하죠.

사용자 압도 — 끝없이 긴 목록을 — 한 화면에 다 쏟으면, 사용자가 압도됩니다. 어디까지 봤는지, 무엇을 찾는지 길을 잃죠.

스크롤 과다 — 모든 걸 한 화면에 두면 — 끝없는 스크롤이 됩니다. 원하는 항목을 찾기 어렵죠.

그래서 BP-040은 — 긴 목록을 적절한 단위로 나누라고 합니다:

페이지네이션 목록을 페이지 단위(한 페이지에 N개)로 나눕니다. 사용자가 페이지를 넘기며 봅니다(페이지 네이션 컴포넌트 CP-114~133). 한 페이지에 적절한 수(BP-041의 최소 10개 등)를 두고요.

무한 스크롤·더보기 또는 스크롤하면 다음 묶음을 불러오는 무한 스크롤, ‘더보기’ 버튼으로 점진적 로딩. 한 번에 다 안 불러오고 사용자가 더 볼 때 추가하죠.

그룹·카테고리 분할 카테고리·날짜·상태별로 나눠 보여주기(BP-037의 그룹핑). 사용자가 관심 그룹만 보게요.

‘지나치게 많은 정보’ 두 의미:

항목 수 — 한 번에 보여주는 항목 수를 적절히(과다 아님).

항목별 정보량 각 항목이 너무 많은 정보(제목+요약+여러 메타+이미지)를 담으면, 목록이 무거워지죠. 목록 에선 핵심 정보(제목·날짜 등)만, 상세는 상세 페이지로(상세 정보 확인 패턴). 항목별 정보도 절제합니다.

적절한 단위. 핵심은 — 한 번에 사용자가 — 부담 없이 보고, 시스템도 빠르게 처리할 만한 적절한 양입니다. 너무 적으면(페이지당 5개) 페이지 넘김이 잦고, 너무 많으면(한 번에 500개) 압도되죠. 목록 성격에 맞는 적정 단위를 정합니다(BP-041의 최소 10개 기본).

필터·검색 병행(BP-042). 긴 목록은 — 분할에 더해 필터·검색(BP-042)으로 원하는 항목을 좁히게 하면 더 좋죠. 분할(606) + 필터/검색(BP-042)이 함께 — 긴 목록 탐색을 돕습니다.

이 규칙은 목록 탐색의 ’분량 관리’를 담당합니다 — 긴 목록을 적절한 단위로 나눠(040), 로딩 부담·사용자 압도를 막고 탐색하기 쉽게 하죠.

정리하면 — 긴 목록을 한 번에 다 보여주면 로딩 부담·사용자 압도·스크롤 과다가 생기므로, 페이지네이션·점진적 로딩· 그룹 분할로 적절한 단위로 나누고 항목별 정보도 절제해야 합니다.

3. 점검 / 개선

무엇을 점검하나

단위 분할 — 긴 목록이 페이지네이션·점진적 로딩·그룹 등으로 나뉘는가.

항목 수 적절 — 한 번에 보여주는 항목 수가 과다하지 않은가.

항목별 정보 절제 — 각 항목이 핵심 정보만 담고 상세는 상세 페이지로 가는가.

개선 방향

긴 목록을 페이지네이션·무한 스크롤·더보기·그룹으로 분할(적정 단위).

항목별 핵심 정보만, 상세는 상세 페이지로. 필터·검색(BP-042) 병행.

4. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
기획/UX	목록 분할·정보량 설계
퍼블리셔/개발	페이지네이션·점진 로딩 구현

기관 유형	BP-040 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수 (긴 목록 사용 시)

긴 목록을 쓰는 모든 사이트가 해당됩니다.

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 긴 목록이 페이지네이션·점진적 로딩·그룹 등으로 나뉘나요?

□ 한 번에 보여주는 항목 수가 과다하지 않나요?

□ 각 항목이 핵심 정보만 담고 상세는 상세 페이지로 가나요?

❓ FAQ

Q1. 한 번에 다 보여주면 편하지 않나요? 로딩이 느리고 사용자가 압도되며 스크롤이 과합니다. 적절한 단위로 나눠 부담을 줄이죠. Q2. 페이지네이션과 무한 스크롤 중 뭐가 나아요? 목록 성격에 따라요. 정확히 찾는 목록은 페이지네이션, 탐색하며 보는 목록은 무한 스크롤·더보기가 맞을 수 있죠. Q3. 항목별 정보량도 줄이나요? 네. 목록엔 핵심(제목·날짜)만, 상세는 상세 페이지로요. 항목이 무거우면 목록이 무거워지죠.

6. 마무리

BP-040의 메시지:

한 번에 다 쏟지 말고 나눠서 — 긴 목록을 적절한 단위로 나누고 과다 정보를 피하라.

긴 목록을 한 번에 다 보여주면 로딩 부담·압도·스크롤 과다가 생깁니다. 페이지네이션·점진 로딩·그룹으로 나누고 항목 정보도 절제하는 게 핵심이죠. 다음 편은 목록 기본 표시 개수입니다.

다음 편 예고 ▶ 「607. (BP-041) 목록을 구분하는 경우 최소 10개 이상의 항목을 기본으로 표시하고 있다.」

ViewCheck는 긴 목록이 적절한 단위로 분할되는지를 진단합니다.

📚 참고 출처

KRDS 기본 패턴 — 목록 탐색 가이드 — https://www.krds.go.kr/html/site/pattern/pattern_04.html

KRDS #ViewCheck #공공웹사이트 #전자정부 #디지털정부 #웹접근성 #디자인시스템 #UIUX #UI컴포넌트 #웹표준

KRDS,ViewCheck,공공웹사이트,전자정부,디지털정부,웹접근성,디자인시스템,UIUX,UI컴포넌트,웹표준