Pixso 데이터 테이블 컴포넌트: Auto Layout으로 만들기

Pixso에서 데이터 테이블 컴포넌트를 만들려면 먼저 열의 값과 사용자가 실행할 동작을 정한 뒤, 셀·행·헤더·도구 모음을 재사용 가능한 Auto Layout 컴포넌트로 조립합니다. 이 튜토리얼은 청구서 표 하나로 정렬, 선택, 행 밀도, 로딩, 빈 결과, 오류와 좁은 화면을 설계합니다. 결과물은 보기 좋은 데이터 표 이미지가 아니라 수정할 수 있는 컴포넌트 체계와 개발 전달 자료입니다.

청구서 표의 데이터와 동작 규칙 정하기

예제는 회계 담당자가 청구서를 검토하는 화면입니다. 각 행에는 청구서 번호, 고객, 상태, 금액, 결제 기한, 담당자와 작업 메뉴가 있습니다. 사용자는 검색하고 상태로 필터링하며, 결제 기한이나 금액으로 정렬하고 여러 청구서를 선택할 수 있습니다. 청구서 하나를 열거나 권한이 허용하는 선택 항목을 내보내는 동작도 포함합니다.

열마다 데이터 유형, 표시 형식, 우선순위, 의미를 읽을 수 있는 최소 폭, 정렬 방향, 말줄임 규칙, 빈 값, 정렬 기준과 좁은 화면의 처리 방식을 기록합니다. 금액은 통화를 함께 표시하고 숫자의 정렬을 일정하게 유지합니다. 날짜는 합의한 형식을 사용하며 시각이 포함될 때는 시간대도 정합니다. 상태는 색상 외에 텍스트로 설명하고, 행 작업에는 화면에서 보이거나 보조 기술로 읽을 수 있는 이름을 제공합니다.

사진 중심의 카드를 비교하거나 단순 목록을 읽거나 휴대전화에서 항목마다 동작 하나를 실행하는 일이 주목적이라면 표가 가장 적합하지 않을 수 있습니다. 많은 정보를 한곳에 넣는 이유가 실제 비교·관리 작업에서 나와야 합니다.

가장 작은 재사용 셀부터 만들기

Pixso 디자인 파일에서 전체 행보다 셀 컴포넌트를 먼저 만듭니다. 텍스트 셀, 숫자 셀, 상태 셀, 체크박스 셀과 작업 셀을 나누세요. 셀 내부에 Auto Layout을 적용해 안쪽 여백과 정렬을 제어합니다. 긴 고객명과 큰 금액을 넣고 실제 텍스트 제약을 정하면 빈 셀만으로는 드러나지 않는 문제가 보입니다. 이것이 테이블 컴포넌트의 첫 계층입니다.

구조가 달라질 때만 셀 변형을 추가합니다. 상태 값마다 행 전체를 새로 만들기보다 중첩된 배지 컴포넌트를 쓰고, 선택은 체크박스 컴포넌트에서, 정렬 방향은 헤더 셀에서 관리하세요. 서로 독립적인 상태를 행 전체의 변형으로 조합하면 경우의 수가 지나치게 늘어납니다.

Table/Cell/Text, Table/Header/Sortable처럼 역할을 드러내는 이름을 붙입니다. Pixso의 컴포넌트와 변형으로 반복 구조를 정리하고 Auto Layout으로 내용에 따른 간격을 관리할 수 있습니다. 라이브러리를 구성할 때는 Pixso 컴포넌트 안내(영문)를 참고하세요.

행과 헤더 컴포넌트 조립하기

셀 인스턴스를 가로 Auto Layout 행에 배치합니다. 컨트롤과 상태에는 일정한 폭을 주고 고객명에는 유연한 공간을 배정하며 금액은 숫자의 정렬을 유지합니다. 행에는 기본, 마우스 오버, 키보드 포커스, 선택 상태를 만들고, 업무 규칙상 필요한 경우에만 사용 불가 상태를 추가합니다.

헤더에는 열 이름, 정렬할 수 있다는 단서, 전체 선택 동작이 필요합니다. 제품이 열 크기 조절을 지원할 때만 조절 핸들을 넣습니다. 현재 정렬 방향은 시각적으로도 구현의 의미 정보로도 전달해야 합니다. 현재 순서를 알아야 하는 표에서 마우스를 올릴 때만 나타나는 장식용 화살표에 의존하지 마세요.

고객명이 한 글자인 경우와 70자인 경우, 금액이 0인 경우와 큰 경우, 담당자 미지정, 연체, 결제 기한 누락을 넣어 봅니다. Auto Layout은 넘침과 줄바꿈을 살펴보는 데 도움이 되지만 어떤 값을 줄바꿈하고 말줄임하며 상세로 옮길지는 팀이 결정해야 합니다.

가독성을 유지하며 행 밀도 조절하기

사용자의 필요가 다를 때 간격이 좁은 보기와 여유 있는 보기를 제공합니다. 좁은 행은 숙련된 담당자가 여러 청구서를 훑는 데 도움이 되고, 여유 있는 행은 누를 영역과 읽기 공간을 확보합니다. 밀도 변경은 주로 세로 여백과 보조 텍스트를 조정하는 방식이어야 하며 중요한 정보를 알리지 않고 숨겨서는 안 됩니다.

표나 행 컴포넌트에 밀도 속성을 만들고 선택, 오류와 줄바꿈된 내용에서도 시험합니다. 고객명이 두 줄이 되는 순간 깨지는 좁은 행은 완성된 변형이 아닙니다. 최소 행 높이와 세로 정렬 규칙을 기록해 구현에서도 같은 기준을 사용하게 하세요.

밀도는 정보의 우선순위를 정하는 일을 대신하지 않습니다. 열 열두 개가 모두 필수라고 한다면 실제 작업을 다시 살펴보세요. 사용자별 열 설정, 상세 패널, 역할별로 분리된 표가 더 적합할 수 있습니다.

정렬, 필터와 일괄 선택 설계하기

도구 모음에는 검색, 상태 필터, 밀도 선택, 내보내기와 선택 개수를 배치합니다. 표 전체의 동작과 행 하나의 동작은 구분하세요. 행을 선택하면 일괄 작업 영역에 선택 개수와 적용 범위를 보여 줍니다. ‘내보내기’보다 ‘청구서 12건 내보내기’가 무엇이 대상인지 분명하게 전달합니다.

페이지나 필터를 넘을 때 선택이 어떻게 이어지는지 정합니다. ‘전체 선택’이 현재 페이지인지, 필터에 맞는 모든 결과인지, 모든 청구서인지 구분하세요. 필터를 바꾸면 선택을 지우는 설계라면 작업을 잃기 전에 알립니다. 선택한 청구서 중 내보낼 수 없는 항목이 있다면 실행 전에 제외 개수와 이유를 보여 줍니다.

예를 들어 청구서 INV-1001, INV-1002, INV-1003을 선택하고 ‘선택한 3건만’을 대상으로 내보낸다고 합시다. 처리 결과가 완료 2건, 실패 1건, 제외 0건이라면 결과 목록도 정확히 그 세 항목을 설명해야 합니다. 내려받는 파일에 성공한 두 건만 들어간다면 파일의 행 수 역시 두 건입니다. 처리한 항목 수와 파일에 담긴 항목 수를 같은 숫자로 쓰지 마세요.

서버에서 데이터를 가져온다면 정렬과 필터에도 로딩 안내가 필요합니다. 적용 중인 검색 조건을 보존하고 같은 요청이 불필요하게 중복되지 않게 하며, 오래된 결과나 일부 결과만 보이는 상태를 구분하세요. 실제 처리는 애플리케이션에서 구현하더라도 디자인 파일에는 사용자가 보게 될 상태를 넣어야 합니다.

고객 레코드를 다루는 표에서 중복 레코드를 병합할 때는 확정 전에 필드별 충돌과 병합 후 남을 레코드를 확인할 수 있어야 합니다.

로딩, 빈 결과, 오류와 부분 데이터 구분하기

표 구조를 알고 있다면 초기 로딩에 스켈레톤을 사용할 수 있습니다. 다만 실제 데이터와 너무 비슷해 사용자가 내용으로 오해해서는 안 됩니다. 새로고침할 때는 모든 행을 없애는 것보다 기존 행과 진행 표시를 함께 남겨 맥락을 유지하는 편이 나을 수 있습니다.

비어 보이는 화면도 원인에 따라 나눕니다.

• 아직 청구서가 없음: 첫 청구서를 만들거나 가져오는 방법을 안내합니다.
• 필터에 맞는 결과가 없음: 현재 필터와 조건 초기화 경로를 보여 줍니다.
• 권한이 없음: 데이터가 존재하지 않는다는 뜻으로 보이지 않게 접근 범위를 설명합니다.
• 불러오기 실패: 검색 조건을 보존하고 재시도를 제공하며 캐시된 값과 현재 값을 구분합니다.
• 일부 데이터만 있음: 어느 범위나 출처를 가져오지 못했으며 어떤 데이터는 사용할 수 있는지 알립니다.

성공에도 확인할 근거가 필요합니다. 내보내기를 마쳤다면 선택 행을 초록색으로 바꾸는 데 그치지 말고 생성된 파일이나 다운로드 상태를 보여 주세요. 여러 행의 상태를 바꾸었다면 완료·제외·실패 개수와 상세를 확인할 경로를 제공합니다. 감사 로그를 표시하는 표에서는 기록된 사건의 결과와 그 상세 정보를 불러왔는지를 따로 구분합니다.

페이지 이동과 대량 결과의 동작 정하기

한 페이지에 모두 표시할 수 없는 청구서를 어떻게 탐색할지 설계합니다. 페이지 크기, 전체 결과 수의 문구, 이전·다음 동작, 필요한 경우 직접 페이지로 이동하는 경로를 정하세요. 필터 적용 후 현재 페이지 번호가 새 결과 범위를 벗어날 때의 처리도 필요합니다. 청구서를 열었다 돌아오면 검색과 정렬 상태가 유지되어야 합니다.

매우 크거나 계속 바뀌는 데이터에서는 개발팀이 서버 페이지 처리나 가상화를 사용할 수 있습니다. 이때 모든 행이 브라우저에 이미 들어 있다고 가정하지 마세요. 개수가 정확한 값인지, 추정치인지, 아직 알 수 없는지 정하고 불러오지 않은 행까지 선택 범위에 포함할 수 있는지도 기록합니다. 다음 페이지를 가져오는 중인지 현재 행을 갱신하는 중인지 구분해 안내합니다.

현실적인 페이지 문구와 시작·끝 경계의 비활성 상태를 넣습니다. 한 페이지뿐인 경우, 첫 페이지와 마지막 페이지, 결과 수 변경과 페이지 요청 실패를 시험하세요. 성능은 구현에서 해결할 부분이지만, 화면은 현재 위치와 복구 경로를 이해할 수 있게 해야 합니다.

좁은 화면에서 정보를 다시 배치하기

반응형 표를 무조건 축소할 수는 없습니다. 중간 폭에서는 우선순위가 높은 열을 고정하고 표 영역 안에서 가로로 스크롤하게 할 수 있습니다. 옆에 더 많은 열이 있다는 단서도 줍니다. 휴대전화에서는 청구서 번호·고객·상태·금액을 행 요약으로 쌓고, 보조 필드를 펼칠 수 있는 상세 영역에 넣는 방법을 검토하세요.

프레임 하나를 좁히는 데 그치지 말고 Pixso에서 반응형 예제를 따로 만듭니다. 선택과 행 작업에 계속 접근할 수 있는지, 긴 번역 레이블과 200% 확대에서 어떤 일이 생기는지 확인하세요. 고정 헤더, 가로 스크롤과 페이지 스크롤이 함께 작동하는 방식도 살펴봅니다.

어떤 정보가 숨겨지고 이동하고 축약되는지 문서화합니다. 우연히 맞아떨어지는 CSS 규칙이 열 우선순위를 정하게 두지 마세요. 편집 가능한 Auto Layout 표는 설계 자료이며 구현에서는 요구되는 인터랙션에 맞는 의미 구조를 선택해야 합니다. WAI 표 패턴(영문)은 일반 표 안에도 개별 버튼이나 링크가 들어갈 수 있음을 설명합니다. 셀 사이의 방향키 이동 같은 복합 상호작용을 제공한다면 그리드 패턴(영문)의 포커스 관리까지 별도로 설계해야 합니다.

전체 체계를 검토하고 개발팀에 전달하기

이름과 사용 규칙을 검토한 뒤 승인된 테이블 컴포넌트를 팀 라이브러리에 게시합니다. 댓글로 정렬, 권한, 선택 범위와 반응형 동작에 남은 질문을 해결하세요. Pixso의 공동 디자인과 개발 전달 기능을 활용하면 검토 메모와 확인 가능한 명세를 표 가까이에 둘 수 있습니다.

개발을 시작하기 전에 필드 정의와 예시 데이터, 행 상태, 키보드 동작, 보이는 포커스, 접근 가능한 이름, 정렬 알림, 선택 의미, 로딩·빈 결과·실패·완료와 좁은 화면을 확인합니다. 자동 생성한 명세나 코드가 데이터 정확성, 성능, 의미 구조와 접근성을 검증해 주지는 않습니다. 완성된 제품에서 따로 시험해야 합니다.

열 규칙, 권한 또는 일괄 작업이 바뀌면 공용 테이블 컴포넌트도 검토합니다. 공통 컴포넌트의 수정은 일관성을 높일 수 있지만 영향을 받는 인스턴스마다 실제 내용과 재정의된 속성이 맞는지 확인해야 합니다.

데이터 테이블 컴포넌트 확인 항목

• 모든 열에 유형, 형식, 우선순위, 폭, 빈 값과 반응형 규칙이 있습니다.
• 헤더가 현재 정렬과 가능한 동작을 전달합니다.
• 전체 선택의 범위를 페이지, 필터 결과, 전체 레코드 중 하나로 명확히 정합니다.
• 일괄 작업에서 개수, 권한, 진행, 실패와 완료 근거를 보여 줍니다.
• 좁은 행과 여유 있는 행 모두 실제 긴 내용에서 작동합니다.
• 초기 로딩, 새로고침, 데이터 없음, 결과 없음, 권한 없음, 실패와 부분 데이터를 구분합니다.
• 좁은 레이아웃에서도 중요한 비교와 동작이 남고 페이지 전체가 불필요하게 넘치지 않습니다.
• 구현 시험에 의미 구조, 키보드, 포커스, 상태 알림, 확대와 성능을 포함합니다.

데이터 규칙에서 실제 작업까지 이어지는 표

청구서 표를 데이터 규칙, 셀, 헤더, 행, 도구 모음과 상태 영역 순서로 만들고 반응형 대안을 추가하세요. Auto Layout과 재사용 컴포넌트로 수정 가능한 체계를 만들되, 현실적인 청구서 값을 넣어 약한 규칙을 찾아야 합니다. 선택 범위, 실패 복구와 완료 근거까지 연결하면 이상적인 데이터가 들어간 화면을 넘어 실제 업무를 지원하는 표가 됩니다.