일괄 상태 변경 UX: 선택 범위, 미리 보기와 부분 성공

여러 항목의 상태를 한꺼번에 바꾸는 화면이라면 확정 전에 선택 범위, 변경 후 상태, 변경할 수 없는 항목을 보여 줘야 합니다. 실행 후에는 실제로 바뀐 항목과 그대로 남은 항목을 따로 알려야 합니다. 표 자체를 만드는 단계라면 먼저 데이터 테이블 컴포넌트 제작 가이드를 참고하세요. 이 글은 표에서 여러 행을 선택한 다음의 판단과 결과에 집중합니다.

하나의 검토 대기열로 문제를 구체화하기

에셋 검토 대기열을 예로 들어 보겠습니다. 담당자가 ‘조치 필요’ 조건으로 추린 47개 중 두 페이지에 걸쳐 12개를 선택하고 ‘상태를 게시됨으로 변경’을 누릅니다. 이 중 10개는 변경할 수 있습니다. 선택한 뒤 동료가 1개를 이미 게시했고, 다른 1개는 다른 담당자가 잠가 둔 상태입니다. 화면은 ‘선택한 12개’가 지정한 항목인지 필터에 맞는 47개 전체인지, 변경 불가 항목 두 개가 전체 작업을 막는지, 열 개만 바뀌면 무엇을 성공으로 볼지 답해야 합니다.

확인 대화상자 하나로 끝내지 말고 선택, 변경 미리 보기, 처리 중, 결과를 이어서 설계하세요. 처음부터 이미 게시된 항목과 잠긴 항목을 포함해야 마지막에 오류 문구만 덧붙여서는 해결되지 않는 문제가 드러납니다.

선택 범위를 문장으로 명확히 표시하기

표 머리글의 체크박스는 현재 페이지에 보이는 행만 선택할 수 있습니다. 별도 동작으로 현재 필터에 맞는 모든 결과를 선택하는 제품도 있습니다. 두 집합은 다릅니다. 사용자가 직접 지정한 경우에는 ‘두 페이지에서 12개 선택’이라고 표시하고, 범위를 명시적으로 넓힌 경우에만 ‘조치 필요 조건에 맞는 47개 전체’라고 표시하세요. 페이지를 넘겼다는 이유로 ‘선택 항목 게시’ 버튼의 의미가 바뀌어서는 안 됩니다.

작업 표시줄에는 개수와 범위를 함께 둡니다. 필터가 바뀌면 선택한 항목 ID를 그대로 유지하고 이를 알리거나, 이유를 설명한 뒤 선택을 해제합니다. 표에는 다른 항목이 보이는데 ‘12개 선택’ 배지만 남는 상태는 피해야 합니다. 여러 페이지를 선택했다면 실행 전에 대상 목록을 다시 확인할 수 있어야 합니다. IBM Carbon의 데이터 테이블 지침도 행 선택 뒤의 일괄 작업을 개별 행 작업과 구별합니다. 여기서 핵심은 그 작업 모드에 어떤 항목이 포함되는지입니다.

명령이 아니라 변경 결과를 미리 보여 주기

‘12개를 게시할까요?’만으로는 잘못 고른 항목을 찾기 어렵습니다. 미리 보기에는 목표 상태를 표시하고 결과별로 항목을 나누세요. 이 사례는 다음처럼 보여 줄 수 있습니다.

잘못된 목표 상태, 예상하지 못한 항목, 제외 이유를 확정 전에 알아볼 수 있어야 합니다. 영향이 작은 소수 항목이라면 간단한 요약으로 충분할 수 있습니다. 항목이 많거나 결과가 중요하다면 행과 변경 전후의 값을 살펴볼 수 있게 하세요. Basis Design System의 일괄 편집 패턴도 선택 개수와 복잡한 변경의 미리 보기를 권장합니다.

변경할 수 없는 행의 처리 규칙 정하기

처리 규칙이 정해지지 않았다면 좋은 문구로도 문제를 덮을 수 없습니다. 제품·개발팀은 먼저 다음 중 어떤 동작을 보장할지 결정해야 합니다.

• 전부 적용하거나 전부 중단: 변경 불가 항목이 하나라도 있으면 아무것도 바꾸지 않습니다. 미리 보기에서 문제 항목을 보여 주고 선택에서 뺄 수 있게 합니다.
• 가능한 항목만 적용: 열 개를 업데이트하고 나머지 두 개는 그대로 둡니다. 확정 전과 결과 화면 양쪽에서 이 규칙을 밝힙니다.
• 백그라운드 작업: 작업을 접수하고 상태를 추적합니다. ‘요청 접수’와 ‘항목 업데이트 완료’를 서로 다른 결과로 표시합니다.

실제 제품의 데이터 계약에 맞는 규칙을 선택하고 화면마다 다르게 적용하지 마세요. 이 사례는 ‘가능한 항목만 적용’을 가정합니다. 기본 버튼을 ‘10개 게시’로 표시하고 옆에 제외된 두 개를 보여 줄 수 있습니다. 업무상 전부 함께 처리해야 한다면 변경 불가 항목을 제외하기 전에는 버튼을 활성화하지 않아야 합니다. 알림 발송 같은 부수 효과까지 되돌릴 수 없다면 ‘실행 취소’를 제공한다고 약속해서는 안 됩니다.

처리 상태와 부분 성공을 정확히 알리기

확정한 뒤에는 선택 집합을 고정하고 첫 요청의 결과가 불분명할 때 다시 제출하지 못하게 합니다. 짧은 작업에는 진행 중 상태와 비활성화된 제출 버튼이면 충분할 수 있습니다. 오래 걸린다면 ‘변경 가능한 10개 업데이트 중’처럼 실제 상태를 표시하고 나중에 결과로 돌아올 수 있게 합니다. 실제 진행률과 무관하게 움직이는 막대보다 명확한 작업 상태가 낫습니다.

열 개가 바뀌고 두 개가 그대로라면 ‘12개 모두 게시 완료’라고 쓰지 않습니다. ‘10개 게시, 2개 변경 없음’이라고 표시하고, 하나는 이미 게시되었으며 하나는 잠겨 있다는 이유를 열어 볼 수 있게 합니다. 잠긴 항목에는 항목 열기, 권한 요청, 잠금 해제 후 재시도처럼 상황에 맞는 다음 동작을 연결합니다. 처리 도중 변경 가능하던 항목 하나가 실패했다면, 미리 알던 제외 항목 두 개와는 별도로 보고해야 합니다. 사전 제외와 실행 중 실패는 해결 방법이 다릅니다.

재시도를 지원한다면 원래의 12개가 아니라 실패한 항목 ID만 다시 전달합니다. 이미 변경된 항목에 같은 요청을 반복하지 않기 위해서입니다. 결과 화면은 곧 사라지는 토스트가 아니라 예외를 해결하는 작업의 일부입니다.

확정 전에 달라진 데이터를 다시 확인하기

선택과 확정 사이에 다른 사람이 항목을 게시하거나 소유자·권한을 바꿀 수 있습니다. 자격에 영향을 준다면 확정 직전에 미리 보기를 다시 계산하거나 오래된 요청을 중단하고 달라진 행을 알려야 합니다. 처음 선택했던 ID를 유지하면 개수가 12에서 11로 바뀐 이유도 설명할 수 있습니다.

미리 보기를 열어 둔 채 다른 세션에서 항목 하나를 바꾼 뒤 다시 확정해 보세요. 최종 결과는 제품의 동시 수정 정책에 따라 다르지만, 방금 확인한 내용과 다른 작업을 조용히 적용해서는 안 됩니다. 어떤 필드를 재검증하고 어떤 오류 화면을 보여 줄지 개발 인계 자료에 적어 둡니다.

좁은 화면과 키보드에서도 사용 가능하게 하기

선택 여부를 색상만으로 구분하지 말고 개수를 글로 표시합니다. 행 체크박스는 키보드로 접근할 수 있어야 하고 첫 선택 뒤 일괄 작업 표시줄이 발견 가능해야 합니다. 좁은 화면에서는 중요도가 낮은 작업을 더보기 메뉴로 옮기더라도 현재 선택 범위와 기본 작업의 의미는 남겨 두세요. 긴 항목 이름은 줄바꿈하고 변경 전후 상태를 읽을 수 있게 하며, 표 때문에 페이지 전체가 가로로 밀리지 않도록 합니다.

포커스 이동도 정해야 합니다. 미리 보기를 열면 제목이나 첫 유효 컨트롤로, 완료 후에는 결과 안내로 이동합니다. 선택을 해제해 미리 보기가 닫히면 표의 예상 가능한 위치로 돌아오게 합니다. 이는 완성된 서비스에서 검증해야 할 구현 요건이며 정적 화면만으로 확인되지는 않습니다.

Pixso에서 결정 흐름을 프로토타입으로 검토하기

Pixso에서 편집 가능한 표 하나를 만들고 12개 선택, 열 개와 두 개를 나눈 미리 보기, 처리 중, 혼합 결과를 각각 프레임으로 구성합니다. 행과 상태 컴포넌트를 재사용해 같은 항목의 이름과 상태가 화면 사이에서 달라지지 않게 합니다. 프레임을 연결해 이미 게시된 항목과 잠긴 항목을 포함한 채 흐름을 검토합니다. 이 일괄 변경 화면은 Pixso 캔버스에서 디자인하는 앱의 화면이며 Pixso 자체가 실제 데이터 대기열을 수정하는 기능은 아닙니다.

검토자에게 어떤 항목이 선택됐는지, 변경되지 않을 두 개는 어떻게 되는지, 확정 후 어디서 찾을 수 있는지 물어보세요. 화면만 보고 답하기 어렵다면 색을 다듬기 전에 라벨과 묶는 방식을 바꿉니다. ‘전부 중단’과 ‘가능한 항목만 적용’ 중 선택한 규칙도 프레임 곁에 남겨 개발자가 그림만 보고 추측하지 않게 합니다. 구현 후에는 실제 데이터로 선택 범위, 동시 수정, 화면 읽기 안내, 재시도를 확인합니다.

화면 뒤에 있는 규칙까지 인계하기

이 대기열의 핵심 사양은 간단합니다. 선택 집합은 두 페이지에 걸쳐 명시적으로 고른 항목 ID이고, 미리 보기에는 변경 가능한 열 개, 이미 게시된 한 개, 잠긴 한 개가 구분됩니다. 확정 시 가능한 항목만 업데이트하며 결과에는 변경·사전 제외·실행 중 실패를 따로 표시합니다. 필터가 바뀌어도 선택 ID를 유지한다면 그 사실을 알리고, 확정 전 자격이 바뀌면 미리 보기를 갱신합니다. 이 규칙이 있어야 보기 좋은 ‘게시’ 버튼의 실제 동작을 테스트할 수 있습니다.