드래그 앤 드롭 목록 순서 변경 UX: 키보드와 저장 상태

목록의 순서를 바꿀 때 사용자가 확인해야 할 것은 두 가지입니다. 항목이 어디로 이동하는지, 그리고 바뀐 순서가 저장됐는지입니다. 네 번째 작업을 두 번째로 옮기는 상황이라면 손을 놓기 전에 삽입 위치를 보여주고, 이동 후에는 새 순서를 확인할 수 있어야 합니다. 드래그 애니메이션이 매끄럽더라도 저장 결과를 알 수 없다면 신뢰하기 어렵습니다. 드래그를 사용할 수 없는 사람도 같은 결과에 도달할 수 있어야 합니다.

여기서는 운영팀의 우선순위 작업 목록 하나를 처음부터 저장 실패까지 설계합니다. 구현 전에 마우스·키보드 조작과 확인 화면을 팀과 검토하려면 각 상태를 Pixso 프로토타입으로 연결할 수 있습니다. 다만 이는 실제 업무 앱의 동작을 설계하는 방법이지, 프로토타입만으로 운영 데이터의 순서가 저장된다는 뜻은 아닙니다.

드래그 핸들보다 먼저 순서의 의미를 정하기

목록에 ‘청구서 확인’, ‘공급업체 연락’, ‘재고 대조’, ‘계약 검토’, ‘공지 게시’가 차례로 있다고 가정해 봅시다. 담당자가 네 번째 ‘계약 검토’를 두 번째로 옮기면 결과는 ‘청구서 확인 → 계약 검토 → 공급업체 연락 → 재고 대조 → 공지 게시’가 됩니다. 디자인을 시작하기 전에 이 결과를 명시해 두면 화면과 구현을 같은 기준으로 평가할 수 있습니다.

바뀐 순서가 개인에게만 적용되는지, 팀 전체에 공유되는지, 아니면 현재 브라우저에서만 잠시 보이는 정렬인지 결정해야 합니다. 팀 공유 목록의 저장 안내와 개인 목록의 안내는 달라야 합니다. 항목을 움직일 때마다 자동 저장할지, 마지막에 ‘순서 저장’을 눌러야 할지도 정하세요. 화면에는 새 순서가 보이는데 새로고침하면 조용히 예전 순서로 돌아가는 상태는 피해야 합니다.

긴 작업명 때문에 위치를 읽기 어렵다면 짧은 우선순위 목록에는 번호를 붙일 수 있습니다. 긴 백로그라면 번호보다 그룹명이 중요할 수도 있습니다. 이동 결과를 색 변화에만 맡기지 말고 “계약 검토가 5개 중 2번째로 이동했습니다”처럼 말로도 알려주세요.

놓기 전에 정확한 삽입 위치 보여주기

드래그 핸들은 해당 행을 움직이는 컨트롤로 보이고, 모든 행에서 같은 자리에 있어야 합니다. 체크박스, 더보기 메뉴, 상세 페이지 링크와 잘못 누르지 않도록 간격도 확보합니다. ‘계약 검토’를 집으면 원래 자리에 빈자리 표시를 남기고, ‘청구서 확인’과 ‘공급업체 연락’ 사이에 삽입선을 표시합니다. ‘공급업체 연락’을 덮어쓰는 듯한 미리보기는 잘못된 기대를 줍니다.

다른 행을 지날 때는 놓았을 때의 순서를 계속 미리 보여줍니다. 큰 점프 애니메이션으로 삽입선이 포인터와 떨어지면 목표 지점을 놓치기 쉽습니다. 스크롤되는 목록에서는 목적지가 화면에서 사라지지 않도록 하고, 자동 스크롤도 쉽게 멈출 수 있어야 합니다. 휴대전화에서는 스크롤과 드래그가 충돌하므로 명확한 핸들이나 의도적인 시작 동작이 특히 중요합니다.

맨 위에 고정된 항목이나 권한 때문에 이동할 수 없는 항목이 있다면 가능한 범위를 미리 보여주세요. 실제로는 놓을 수 없는 자리에 삽입선을 그린 뒤 손을 놓았을 때 거부하지 않는 것이 좋습니다. 서버에서만 마지막에 확인할 수 있는 제한이라면, 실패 이유와 복구 경로를 곧바로 알려줘야 합니다.

키보드만으로도 같은 결과에 도달하기

드래그만으로 순서를 바꾸게 해서는 안 됩니다. 행마다 작업 메뉴에 ‘위로 이동’, ‘아래로 이동’을 두고, 목록이 길다면 ‘위치 지정’도 고려해 보세요. 키보드 사용자는 행에 초점을 맞추고 메뉴를 열어 이동한 뒤 예측 가능한 위치에서 작업을 이어갈 수 있습니다. 첫 항목의 ‘위로 이동’처럼 사용할 수 없는 명령은 일관되게 비활성화하거나 숨깁니다. 눌렀는데 아무 반응도 없는 상태는 만들지 않습니다.

변경 결과에는 항목명과 새 위치를 포함합니다. “계약 검토가 5개 중 2번째로 이동했습니다.” 아직 저장되지 않았다면 그 사실도 알려줘야 합니다. 화면의 DOM 순서만 바뀌어서는 스크린 리더 사용자에게 결과가 전달되지 않을 수 있습니다. 맞춤형 목록 위젯이라면 역할, 초점 이동, 명령 방식을 직접 정의하세요. W3C의 리스트박스 패턴은 키보드와 초점을 설계할 때 참고할 수 있지만, 모든 순서 변경 목록에 그대로 적용되는 완성된 해답은 아닙니다. 실제 키보드와 보조 기술로 테스트해야 합니다.

포인터와 키보드 경로는 최종적으로 같은 순서를 저장해야 합니다. 키보드 조작만 화면의 사본을 바꾸거나 숨겨진 추가 확인을 요구해서는 안 됩니다. Atlassian의 드래그 앤 드롭 접근성 지침도 포인터 이외의 경로를 검토할 때 참고할 만합니다. 실제 제품에서는 해당 작업 흐름에 맞춰 검증하세요.

새 순서를 확인하고 저장 실패에서 복구하기

이동을 마치면 새 순서를 보여주고 ‘계약 검토’ 또는 그 핸들에 초점을 유지합니다. 자동 저장 방식이라면 저장 중과 서버가 수락한 후를 구분해 표시하세요. 요청이 끝나기 전에는 ‘저장됨’이라고 하면 안 됩니다. 직접 저장하는 방식이라면 페이지를 떠나기 전에 미저장 상태와 ‘순서 저장’ 버튼을 쉽게 발견할 수 있어야 합니다.

실수로 여러 칸을 옮겼다면 ‘실행 취소’로 이전 순서를 복원할 수 있어야 합니다. 카드만 제자리로 움직이고 실제 저장된 순서는 그대로 두면 취소가 아닙니다. 공유 목록을 다른 팀원도 편집한 경우에는 현재 어느 순서가 기준인지 알려주세요. 충돌이 나면 최신 목록을 확인하고 자신이 의도한 이동을 다시 적용할 수 있어야 합니다. 다른 사람의 변경을 말없이 덮어써서는 안 됩니다.

저장에 실패했을 때는 두 가지 중 하나를 분명히 선택합니다. 제안한 순서를 미저장 상태로 유지하면서 ‘재시도’와 ‘버리기’를 제공하거나, 마지막으로 확인된 순서로 되돌리면서 이유를 설명하는 방식입니다. 잠깐 사라지는 알림만 띄우고 확정되지 않은 순서를 화면에 그대로 두면 혼란스럽습니다. 보이는 순서와 서버가 수락한 순서가 결국 일치해야 합니다.

애니메이션보다 상태 전이를 테스트하기

항상 같은 ‘네 번째 항목을 두 번째로’ 사례로 진행 전후뿐 아니라 실패 시점까지 확인하면 빈틈이 드러납니다.

마우스, 터치, 키보드, 스크린 리더, 좁은 화면에서 같은 결과를 확인합니다. 입력 방식은 달라도 이동 위치와 저장 상태를 이해할 수 있어야 합니다. 시각적 피드백을 설계할 때는 Atlassian의 디자인 지침을 참고하되, 최종 결정은 실제 제품 테스트에 맞춰 내리세요.

Pixso에서 이동과 복구 화면을 함께 검토하기

이동 전, 삽입 위치 미리보기, 이동했지만 미저장인 상태, 저장 완료, 저장 실패를 한 흐름으로 그립니다. 키보드용 메뉴도 다른 예시가 아니라 같은 다섯 작업에 적용합니다. 모든 화면에서 작업명과 ‘네 번째에서 두 번째’라는 조건을 유지하면 검토자가 화면 내용 차이에 헷갈리지 않습니다.

각 동작 전에 검토자에게 물어보세요. 어느 행이 어디로 이동할까요? 이미 저장됐을까요? 저장이 실패하면 어떻게 될까요? 디자이너의 설명을 듣고서야 답할 수 있다면 화면의 단서를 더 분명히 해야 합니다. 합의된 화면은 구현과 수용 테스트에도 기준이 됩니다.

화려한 움직임보다 믿을 수 있는 결과

목록 순서 변경의 핵심은 움직임 자체가 아니라 이전 순서에서 의도한 새 순서로 확실히 전환되는 것입니다. 드래그하지 않아도 같은 목적지에 도달하게 하고, 이동 전에는 삽입 위치를, 이동 후에는 확정된 저장 상태를 보여주세요. 그래야 애니메이션이 잘 작동할 때뿐 아니라 오류가 생겼을 때도 사용할 수 있는 우선순위 목록이 됩니다.