반응형 표를 디자인하는 방법

반응형 표 디자인은 사용할 수 있는 폭이 달라져도 표의 유용한 관계를 유지하는 작업입니다. 모든 열을 한 화면에 맞추는 것은 가능한 해결책 중 하나일 뿐입니다. 비교해야 할 값을 흩어 놓는 깔끔한 카드 목록보다, 읽기 좋은 스크롤 표가 비교 과제에 더 적합할 수 있습니다.

사용자가 해야 할 일부터 살펴보세요. 여러 레코드를 비교해야 하나요, 하나를 찾아야 하나요, 세부 정보를 확인해야 하나요, 아니면 여러 항목을 한꺼번에 처리해야 하나요? 그 답에 따라 함께 있어야 할 정보와 컨트롤 뒤로 옮겨도 될 정보가 정해집니다. 이 판단이 없으면 반응형 조정은 글자를 줄이고, 열을 숨기고, 버튼을 점점 더 빽빽하게 배치하는 작업으로 흐르기 쉽습니다.

이 글에서는 프로젝트 이름, 담당자, 상태, 마감일, 미해결 댓글 수가 있는 가상의 검토 대기 목록을 예시로 사용합니다.

반드시 유지해야 할 관계를 찾으세요

표가 유용한 이유는 위치가 의미를 전달하기 때문입니다. 한 열을 아래로 훑으면 값을 비교할 수 있고, 한 행을 옆으로 따라가면 레코드와 속성을 연결할 수 있습니다. 반응형 변경이 한쪽 관계는 보존하면서 다른 쪽 관계는 약화할 수 있습니다.

프로젝트 검토 예시에서 관리자는 미해결 댓글이 있는 프로젝트 중 마감이 가장 빠른 것을 찾아야 할 수 있습니다. 그러려면 프로젝트를 식별할 정보와 함께 마감일과 댓글 수가 보여야 합니다. 댓글 수가 마지막 열이라는 이유로 숨기면 화면은 깔끔해져도 그 과제를 수행할 수 없게 됩니다.

자신에게 배정된 프로젝트를 여는 검토자의 필요는 다릅니다. 프로젝트 이름, 상태, 명확한 실행 버튼이 중요하고 나머지 세부 정보는 그 뒤에 확인해도 될 수 있습니다. 이때는 간단한 요약과 펼치기 기능이 잘 맞을 수 있습니다. 기초 데이터는 같아도 처음에 보여 줘야 할 정보는 다릅니다.

그다음 각 과제를 끝내는 데 필요한 정보를 표시하세요. 모든 과제에 쓰이는 열은 기본 화면에 있어야 합니다. 항목을 선택한 뒤에만 쓰이는 필드는 펼쳐서 보여 주는 후보가 될 수 있습니다. 이는 사용자의 업무를 고려해 정보의 제시 방식을 정하는 판단이지, 덜 중요한 데이터를 삭제하라는 뜻이 아닙니다.

표의 폭과 페이지의 폭을 분리하세요

표가 넓다고 페이지 전체를 좌우로 스크롤되게 할 필요는 없습니다. CSS에서 overflow-x: auto를 적용한 래퍼로 표에 자체 스크롤 영역을 주면 제목, 설명, 필터, 주변 본문은 뷰포트에 맞출 수 있습니다. 래퍼 자체도 페이지 레이아웃 안에서 줄어들 수 있어야 합니다. 유연하지 않은 그리드 열 안에 폭 100% 자식 요소를 넣으면 여전히 페이지 전체가 넓어질 수 있습니다. 이렇게 분리하면 가로와 세로 두 방향의 공간이 필요한 콘텐츠에만 해당 영역을 한정할 수 있습니다.

W3C의 리플로(Reflow) 기준 해설은 의미나 사용에 두 차원이 필요한 콘텐츠에 예외를 허용하며 데이터 표도 여기에 포함합니다. 동시에 표 자체와 개별 셀 안의 콘텐츠를 구분하며, 셀 안의 콘텐츠는 여전히 적절히 재배치되어야 한다고 설명합니다. 이 예외는 모든 라벨이나 주변 문단까지 영역 밖으로 넘쳐도 된다는 근거가 아닙니다. W3C의 리플로 기준 해설.

실제로는 긴 프로젝트 이름이 적절한 셀 폭 안에서 줄바꿈되도록 하세요. 데스크톱 디자인이 그랬다는 이유만으로 큰 빈 공간을 유지하지 마세요. 표는 열 사이의 관계를 보존하기 위해 가로 이동이 필요하면서도, 세심한 셀 크기 조정의 도움을 받을 수 있습니다.

컨테이너의 경계는 알아볼 수 있어야 합니다. 마지막으로 보이는 열이 화면 가장자리에서 딱 끝나고 뒤에 콘텐츠가 있다는 표시도 없으면 사용자는 표가 거기서 끝난다고 생각할 수 있습니다. 다음 열 일부, 환경이 지원하는 경우의 스크롤바, 짧은 안내 문구로 이어지는 내용을 더 분명히 알릴 수 있습니다. 장식적인 그라데이션만으로 모든 설명을 대신하지 마세요.

가능하다면 표 제목과 과제의 맥락은 스크롤 영역 밖에 두세요. ‘검토 대기 중인 프로젝트’ 같은 제목은 레코드들의 공통점을 설명합니다. 짧은 안내로 초기 정렬 기준이나 관련 시간대를 설명할 수도 있습니다. 이들은 방향을 알려 주는 정보이지, 다른 데이터와 공간을 두고 경쟁해야 할 추가 열이 아닙니다.

USWDS는 실제로 다른 두 반응형 패턴을 보여 줍니다

미국 웹 디자인 시스템의 표 구성 요소는 스크롤형과 세로 쌓기형을 제공합니다. 스크롤 예시는 행과 열의 격자를 유지하고, 세로 쌓기 예시는 좁은 화면에서 개별 레코드 안에 라벨과 값을 표시합니다. 작동하는 예시에서 이 차이를 직접 볼 수 있습니다.

구성 요소 이름보다 이 차이가 더 중요합니다. 격자형 표에서는 위치로 두 열 사이의 관계를 파악할 수 있습니다. 세로로 쌓인 레코드는 라벨을 반복해 항목 하나를 독립적으로 읽게 합니다. 데이터가 똑같아도 비교에 필요한 수고는 크게 달라질 수 있습니다.

검토 대기 목록에서 ‘댓글이 다섯 개를 초과하는 프로젝트 중 마감일이 가장 늦은 것’을 찾아보세요. 표에서는 댓글 수 열과 날짜 열을 함께 훑을 수 있습니다. 카드에서는 각 레코드를 차례로 보면서 앞서 찾은 후보를 기억해야 할 수 있습니다. 이제 과제를 ‘Cedar Lodge의 담당자와 마감일 읽기’로 바꿔 보세요. 비교가 중심이 아니므로 세로로 쌓인 버전이 편할 수 있습니다.

독자에게 드는 부담을 기준으로 변환 방식을 고르세요

구현을 인계할 때는 반드시 유지할 조건을 몇 가지 명시하세요. 행을 식별할 수 있어야 하고, 값에 단위가 붙어 있어야 하며, 정렬 기준 필드를 이해할 수 있어야 하고, 화면 크기를 바꿔도 선택 범위가 같아야 합니다. 이런 조건은 데스크톱의 모든 열을 휴대전화 화면에 넣어야 한다는 요구보다 오래 유효합니다. 구현 담당자가 사용자 과제를 몰래 바꾸지 않으면서 표현 방식을 조정할 수 있게 해 줍니다.

해당 패턴이 가장 불편해지는 조건도 테스트하세요. 행 라벨이 긴 상태에서 맨 오른쪽까지 스크롤해 보세요. 콘텐츠 길이가 다른 이웃 레코드들을 펼쳐 보세요. 항목을 선택한 다음 뷰포트를 바꾸고 같은 행동을 이어 가세요. 깔끔한 기본 스크린샷만으로는 갱신되지 않은 선택 수, 값을 가리는 고정 열, 잘못된 레코드에 붙은 상세 패널을 발견할 수 없습니다.

네 가지 반응형 패턴과 각각의 대가

1. 표를 유지하고 가로로 스크롤하세요

정렬된 값을 비교하는 것이 주요 과제이고 모든 열에 의미가 있다면 가로 스크롤은 유력한 선택입니다. 표를 다른 정보 구조로 바꾸지 않고 격자를 보존합니다. 다만 사용자가 가로로 이동해야 하므로 그 탐색 방식은 의도적으로 설계해야 합니다.

검토 표에서는 프로젝트 이름을 앞쪽에 놓고, 구현상 신뢰할 수 있는 고정 열을 제공할 수 있다면 계속 보이게 하세요. 그렇지 않으면 사용자가 마감일까지 스크롤했을 때 어느 행을 읽고 있는지 놓칠 수 있습니다. 이름을 고정하는 열은 나머지 데이터를 볼 유용한 공간이 남을 만큼 좁아야 합니다.

표의 절반을 고정하지 마세요. 좁은 화면에서 두세 열을 고정하면 뷰포트를 거의 다 차지하고 움직이는 콘텐츠에는 아주 작은 공간만 남을 수 있습니다. 맥락을 유지하는 데 필요한 최소한의 식별 정보부터 고르세요. 프로젝트 이름이 길다면 지나치게 넓은 블록을 고정하기보다 줄바꿈을 허용하거나 보조 식별자를 신중하게 활용하세요.

고정 영역이 교차하는 부분은 시각적 처리를 주의해야 합니다. 왼쪽 위 셀은 고정된 머리글 행과 첫 번째 열 위에 동시에 놓일 수 있습니다. 쌓임 순서가 명확하지 않거나 배경이 불투명하지 않으면 값이 비쳐 보이거나 겹칠 수 있습니다. 정지 이미지에서는 멀쩡해 보여도 스크롤할 때 문제가 생길 수 있는 대표적인 세부 사항입니다.

터치 제스처 이외의 조작도 확인하세요. 키보드 사용자가 필요할 때 영역에 도달해 조작할 수 있어야 하고, 상호작용 요소 주변의 포커스도 보여야 합니다. 관련 브라우저와 보조 기술에서 구현된 동작을 확인하세요. 목업에 외곽선을 그렸다고 키보드 접근이 입증되는 것은 아닙니다.

2. 우선순위가 높은 열을 보여 주고 나머지는 펼치게 하세요

일상적인 결정 대부분이 소수의 필드에 의존한다면 우선순위 열 방식이 잘 맞습니다. 그 필드들은 보이게 두고 추가 데이터를 확인하는 명확한 경로를 제공하세요. 주요 과제를 해치지 않으면서 폭을 줄일 수 있지만, 우선순위를 올바르게 정했을 때만 그렇습니다.

검토자에게는 프로젝트 이름, 상태, 마감일이 유용한 간략 보기일 수 있습니다. 담당자와 댓글 수는 펼친 행에 표시할 수 있습니다. 하지만 미해결 댓글이 남은 지연 업무를 찾는 관리자에게 댓글 수를 숨기는 것은 나쁜 선택입니다. 사용자의 과제와 무관하게 모든 상황에 맞는 ‘모바일용 열’ 목록은 없습니다.

펼쳐졌는지 분명히 알 수 있는 컨트롤을 쓰세요. 이웃 행들이 비슷하게 생겼더라도 펼친 콘텐츠가 어느 레코드에 속하는지 눈에 보여야 합니다. 상세 패널의 위치 때문에 연결이 불확실하다면 패널 안에 프로젝트 이름을 다시 표시하세요. 세부 정보, 메뉴, 새 페이지 중 무엇을 여는지 추측하게 하는 모호한 라벨은 피하세요.

거의 모든 레코드에서 필요한 행동을 하려고 매번 펼치게 하지 마세요. 검토 대기 목록이라면 검토를 여는 버튼은 기본 화면에 보일 가치가 있을 수 있습니다. 드물게 쓰는 메타데이터와 함께 묻어 두면 폭은 절약하지만 반복 작업이 늘어납니다. 어떤 필드가 공간을 차지하는지만 보지 말고, 어떤 상호작용이 자주 일어나는지 평가하세요.

생략한 열에 접근하는 방법을 분명히 하세요. 데스크톱 사용자가 기대하는 담당자 필드가 좁은 화면에서 사라진다면, 이를 찾는 이해 가능한 경로를 제공해야 합니다. 접근 가능한 상세 보기, 열 선택기, 펼친 요약 등이 그 역할을 할 수 있습니다. 설명 없이 없애면 사용자가 이용할 수 있는 정보 자체가 바뀝니다.

3. 각 레코드를 라벨이 있는 카드로 바꾸세요

세로로 쌓은 레코드는 사용자가 한 번에 항목 하나를 읽을 때 유용합니다. 각 값에 눈에 보이는 라벨을 붙이고 행을 작은 세로 요약으로 바꿉니다. 레코드 간 비교가 부차적인 주문 상세 목록이나 약속 목록에 잘 맞을 수 있습니다.

가상의 프로젝트 표라면 카드는 Cedar Lodge를 제목으로 보여 준 뒤 상태, 마감일, 담당자, 미해결 댓글을 표시할 수 있습니다. 레코드 하나로 읽기는 쉽습니다. 하지만 프로젝트 열 개의 댓글 수를 비교하려면 훨씬 길어진 페이지에서 같은 라벨을 반복해서 찾아야 합니다.

이 패턴을 고르기 전에 여러 레코드의 속성 하나를 비교해 달라고 해 보세요. 값을 기억하려고 앞뒤로 스크롤해야 한다면, 카드는 가로 이동을 더 큰 세로 탐색과 기억 부담으로 바꾼 것입니다. 그래도 허용할 수는 있지만, 그 대가는 의식적으로 선택해야 합니다.

카드마다 라벨과 값의 순서를 일관되게 유지하세요. 값 하나가 없다는 이유만으로 어떤 카드에서는 상태를 맨 위에, 다른 카드에서는 담당자 뒤에 두지 마세요. 누락 상태를 의미 있는 문구로 표시하면 구조를 예측 가능하게 유지할 수 있습니다.

접근성 결과를 확인하지 않은 채 장식용 생성 콘텐츠만으로 라벨을 넣지 마세요. 눈에 보이는 ‘마감일’ 라벨과 프로그램이 인식할 수 있는 관계는 별개의 문제입니다. 최종 마크업은 시각적 카드를 보지 않는 사람에게도 데이터를 일관되게 전달해야 합니다.

데스크톱 버전이 의미 구조를 갖춘 표이고 좁은 버전에서 시각적 표시 방식을 바꾼다면, 의도한 표의 관계가 계속 제공되는지 살펴보세요. 페이지에 별도 표시 버전들이 있다면 숨겨진 콘텐츠가 중복 컨트롤이나 반복 읽기를 만들지 않는지 확인하세요. 이런 변환은 반응형 스타일링뿐 아니라 구현 검토도 필요합니다.

4. 사용자가 비교 대상을 고르게 하세요

필요한 열이 많은 표라도 사용자가 그 전부를 한 번에 필요로 하는 경우는 드물 수 있습니다. 열 선택기는 자신에게 유용한 보기를 만드는 데 도움이 됩니다. 별도의 비교 모드에서는 소수의 레코드를 선택하고 관련 속성을 함께 살펴보게 할 수 있습니다.

이런 컨트롤도 자체적인 작업 부담을 만듭니다. 처음 온 사용자는 어떤 열이 중요한지 모르거나 기본 보기에 모든 정보가 있다고 생각할 수 있습니다. 합리적인 초기 보기를 제공하고 숨겨진 열이 있을 때 분명히 알리세요. 맞춤 설정은 숙련된 사용자를 도와야 하며, 기본 내용을 이해하려고 먼저 설정부터 해야 하게 만들어서는 안 됩니다.

검토 표의 기본 보기에는 프로젝트, 상태, 마감일, 댓글을 포함할 수 있습니다. 조정 담당자는 담당자 열을 추가하고, 개별 검토자는 그 열을 뺄 수 있습니다. 레코드들이 서로 연결되지 않은 숫자 행으로 변하지 않도록 프로젝트 식별 정보는 계속 제공해야 합니다.

비교 모드는 긴 대기 목록을 처리하기보다 몇 가지 대안 중에서 고르는 데 더 적합합니다. 제품 세 개를 선택해 비교하는 것은 합리적일 수 있습니다. 지연된 프로젝트가 무엇인지 알아내려고 모든 프로젝트를 선택하게 하는 것은 불필요한 우회입니다. 표가 넓다는 이유만으로 비교 컨트롤을 추가하지 마세요.

사용자가 보기를 저장할 수 있다면 무엇이 저장되는지 정의하세요. 열 표시 여부, 순서, 정렬, 필터는 서로 다른 설정입니다. 열 배치 저장이 예상치 않게 오래된 필터까지 유지해 새 레코드를 숨겨서는 안 됩니다. 시각적 프로토타입에서는 저장 버튼을 그렸다는 이유로 실제 저장이 된다는 인상을 주기보다 이런 동작을 요구 사항으로 기록하세요.

라벨, 숫자, 빈 셀의 의미를 보존하세요

반응형 변경은 불명확한 콘텐츠 표기 관행을 드러내는 경우가 많습니다. ‘04/05’ 같은 날짜는 큰 화면에서도 모호하지만, 주변에 설명을 둘 공간이 없으면 문제가 더 뚜렷해집니다. 대상 독자에게 적합한 형식을 쓰고, 과제에 영향을 준다면 시간대나 상대 날짜의 맥락도 제공하세요.

숫자 열에서는 단위를 일관되게 쓰세요. 머리글과 형식이 차이를 설명하지 않는다면 댓글 수와 텍스트 상태를 같은 필드에 섞어 넣어서는 안 됩니다. 비교 가능한 숫자는 일관되게 정렬해 차이를 쉽게 살펴볼 수 있게 하세요. 좁은 화면에서만 정밀도를 낮추거나 단위를 빼려면 값의 의미가 여전히 같은지 먼저 생각해야 합니다.

비어 있는 데이터를 어떻게 표현할지 정하세요. ‘담당자 미지정’, ‘댓글 없음’, ‘이용 불가’는 서로 다른 상태를 설명합니다. 빈 셀은 그렇지 못합니다. 검토 예시에서 담당자가 아직 배정되지 않은 상태와 필드 로드에 실패한 상태가 똑같아 보여서는 안 됩니다.

의미를 보존할 수 있다면 긴 라벨은 줄바꿈하세요. 툴팁은 보충 맥락을 줄 수 있지만, 꼭 필요한 라벨을 반복해서 찾아봐야 하게 만드는 대안으로는 약합니다. 열 제목이 어디에서도 쓰기 어려울 만큼 길다면 곧바로 잘라 내기보다 더 정확한 표현으로 고칠 수 있는지 생각하세요.

W3C의 표 튜토리얼은 머리글과 데이터 셀에 구조적 마크업과 적절한 연결이 필요하다고 설명합니다. 이는 시각적 정렬을 넘어 맥락을 유지한 탐색을 지원합니다. 선택한 패턴을 구현할 때, 특히 행 머리글과 열 머리글이 모두 의미에 기여할 때 이 안내를 활용하세요. W3C의 접근 가능한 표 튜토리얼.

컨트롤을 올바른 적용 범위와 연결하세요

정렬은 전체 목록에, 상세 열기는 레코드 하나에, 일괄 작업은 선택한 레코드들에 영향을 줍니다. 레이아웃이 좁아져도 이 범위들은 구분되어야 합니다. 모든 컨트롤을 같은 메뉴에 몰아넣으면 어떤 행동이 무엇을 바꾸는지 불분명해질 수 있습니다.

행별 행동은 해당 레코드와 시각적으로 연결되게 하세요. 넓은 표의 맨 오른쪽 메뉴는 가로 스크롤 중 화면 밖으로 나갈 수 있습니다. 프로젝트를 여는 것이 주요 과제라면 이름에 링크를 걸어 안정적인 경로를 제공하고, 메뉴에는 덜 자주 쓰는 행동을 넣을 수 있습니다. 어떤 행동에 즉시 접근해야 하는지에 따라 최적의 배치가 달라집니다.

선택 기능은 더 세심하게 다뤄야 합니다. 첫 번째 고정 열의 체크박스는 편리할 수 있지만 행을 식별하는 정보를 밀어내서는 안 됩니다. 여러 레코드를 선택했다면 개수를 보여 주고, 선택이 현재 페이지에만 적용되는지 필터된 전체 결과에 적용되는지 명확히 하세요. 반응형 버전에서 그 의미를 조용히 바꿔서는 안 됩니다.

정렬 컨트롤은 작은 화살표에만 전적으로 의존하지 않고 현재 방향을 설명해야 합니다. 해당 열이 숨겨져도 어떤 필드로 정렬했는지 이해할 수 있는지 확인하세요. 보이지 않는 머리글에 정렬을 붙여 두는 것보다 표 위에 라벨이 있는 컨트롤로 정렬 선택을 옮기는 편이 더 명확할 때도 있습니다.

좁은 화면에서는 필터와 페이지 이동도 확인하세요. 표는 읽을 수 있어도 필터 도구 모음이 페이지 밖으로 넘치거나 페이지 이동 컨트롤이 빽빽해질 수 있습니다. 이 컨트롤들은 격자 밖에 있어도 같은 과제의 일부입니다. 레코드를 찾는 단계부터 처리하는 단계까지 전체 경로를 테스트하세요.

까다로운 콘텐츠와 실제 과제로 검토하세요

레이아웃에 부담을 주는 콘텐츠를 쓰세요. 긴 프로젝트 이름, 미지정 담당자, 큰 댓글 수, 빠진 날짜, 줄바꿈되는 상태 라벨 등이 해당합니다. 해당 패턴이 지원하는 방향으로 이동해야 할 만큼 충분한 행을 넣으세요. 완전히 균일한 레코드 세 개만으로는 반응형 표에 관해 알 수 있는 것이 거의 없습니다.

스크롤 버전에서는 옆으로 이동한 뒤 늦은 마감일과 프로젝트 이름을 연결해 달라고 하세요. 펼치기 버전에서는 세부 정보를 찾고 다음 레코드로 돌아가게 하세요. 세로 카드에서는 여러 프로젝트의 값 하나를 비교하게 하세요. 이런 과제를 수행하면 보존한 관계가 사용자가 실제로 필요로 하는 관계인지 알 수 있습니다.

좁은 기기 폭뿐 아니라 브라우저 확대도 테스트하세요. 데스크톱 사용자가 콘텐츠를 확대하면 다른 이유로 같은 공간 제약을 겪을 수 있습니다. 텍스트가 계속 읽히는지, 컨트롤에 도달할 수 있는지, 고정 영역이 사용 가능한 공간 대부분을 덮지 않는지 확인하세요.

OpenDesign에서는 여러 뷰포트 프리셋으로 HTML 표 레이아웃을 미리 보고, 과밀한 영역에 댓글을 붙이고, 텍스트나 스타일을 다듬을 수 있습니다. 샘플 레코드와 선택한 과제를 디자인 맥락에 함께 유지하세요. 의미 구조를 갖춘 마크업, 키보드 스크롤, 정렬, 저장된 상태는 구현된 표에서 테스트하세요.