테이블 행 편집 UX: 입력 오류, 저장 상태, 충돌 복구

테이블에서 행 하나를 바로 수정할 때는 입력 중인 값과 저장된 값을 분명히 구분해야 합니다. 행의 위치를 유지하고, 수정 중인 필드와 오류 이유를 알려 주며, 저장이 진행 중인지 완료됐는지 보여 주세요. 다른 사람이 같은 레코드를 먼저 바꿨을 때 되돌아갈 경로도 필요합니다. 이 글에서는 구매 담당자가 공급업체 가격표의 단가 $24.00를 바꾸는 작업을 따라갑니다.

열 구성, 밀도, 정렬, 빈 상태부터 정해야 한다면 Pixso 데이터 테이블 컴포넌트 가이드를 먼저 보세요. 여기서는 이미 표가 있고, 전체 편집 화면으로 이동하지 않으면서 한 행의 가격을 안전하게 바꾸는 문제에 집중합니다.

입력란을 그리기 전에 저장 경계를 정하기

한 행에는 공급업체 이름, 품목 코드, 단가, 통화, 마지막 수정 시간이 있습니다. 구매 담당자는 이웃한 공급업체의 가격과 비교하면서 단가만 고치려 합니다. 별도 전체 화면을 열면 비교하던 맥락이 끊깁니다. 행 안에서 고치면 맥락은 남지만, 입력란을 떠날 때 저장되는지, 행의 저장 버튼을 눌러야 하는지 명확해야 합니다.

가격처럼 결과에 영향을 주는 값은 행 단위의 저장·취소 버튼을 두면 확정 시점이 분명해집니다. 서버가 저장을 승인하기 전까지 원래의 $24.00가 저장된 값입니다. 입력 중인 초안은 합계나 다른 사람의 화면에 반영하지 않습니다. 자동 저장을 쓰더라도 대기·완료·실패 상태를 분명히 표시해야 합니다. 입력란이 사라졌다는 사실만으로 저장을 증명할 수는 없습니다.

수정하는 동안 행의 정체성을 잃지 않게 하세요. 정렬이나 필터 때문에 행이 이동할 수 있다면 저장까지 위치를 고정하거나, 확정 후 현재 필터에서 사라진다는 사실을 알려 줍니다. 고정된 작업 막대를 사용한다면 어느 행에 적용되는지도 표시해야 합니다.

보기 좋은 입력란 하나가 아니라 여섯 상태 설계하기

평상시 행과 그다음에 실제로 나타날 상태를 함께 그립니다. 아래 표는 동일한 공급업체 레코드에 적용되는 간단한 상태 명세입니다.

이 가격표에 -5를 입력하면 오류입니다. 이 예시의 가격표는 음수 단가를 허용하지 않기 때문입니다. 단순히 “잘못된 입력”이라고 하지 말고 “$0.00 이상의 가격을 입력하세요”라고 안내합니다. 입력값을 지우지 않으면 바로 고칠 수 있습니다. 이는 예시의 업무 규칙이지 모든 가격 시스템이 0을 허용한다는 뜻은 아닙니다.

Atlassian의 인라인 편집 가이드는 조회와 편집 상태를 구분하고 저장, 취소, 검증을 명확히 합니다. 이 구분을 참고하되 실제 컨트롤은 가격 변경의 위험도와 제품의 데이터 규칙에 맞춰 결정하세요.

즉시 검증과 서버의 저장 거부 구분하기

검증에는 두 층이 있습니다. 빈 값, 잘못된 금액 형식, 음수는 전송 전에 화면에서 잡을 수 있습니다. 하지만 해당 공급업체를 수정할 권한이 없는지, 통화가 고정돼 있는지, 허용 범위가 바뀌었는지는 서버가 최종 판단해야 합니다. 화면의 검증을 통과했을 뿐인데 “저장 완료”라고 표시하지 마세요.

로컬 오류는 단가 입력란 가까이에 두고 보조 기술에서도 해당 입력과 연결합니다. 빨간 테두리만으로 설명하지 마세요. 저장 후 서버가 거부하면 입력을 보존하고 행을 열린 상태로 둔 채, 서버가 알려 준 구체적 이유를 표시합니다. “문제가 발생했습니다”는 대체 문구일 수 있지만 권한이나 버전 문제처럼 조치할 수 있는 이유를 가려서는 안 됩니다.

금액 형식도 신중히 다룹니다. 담당자가 24, 24.0, 24.00 중 어느 형태로 입력하든 승인 후 표시는 일관되게 정리합니다. 통화를 입력란 이름이나 값 옆에 두어 “24”를 수량과 혼동하지 않게 합니다. 소수점에 쉼표를 쓰는 지역에서는 그 지역 방식대로 읽고 표시해야 합니다. “24,50”을 묵시적으로 2,450이나 24,500으로 해석하면 안 됩니다.

저장과 충돌 복구를 실제 상태대로 보여 주기

담당자가 $25.00를 입력하는 동안 동료가 같은 레코드를 $26.00로 먼저 저장했다고 가정해 보겠습니다. 버전 확인을 하면 오래된 편집이 새 값을 조용히 덮어쓰는 일을 막을 수 있습니다. 복구 화면에는 대상 행과 “내 초안: $25.00”, “현재 저장된 값: $26.00”을 함께 보여 주고 차이를 확인한 뒤 결정하게 합니다. 입력란에 $25.00가 남아 있어도 그것을 저장된 값이라고 부르면 안 됩니다.

해결 선택지는 시스템 규칙에 달려 있습니다. 덮어쓰기를 허용한다면 결과를 명시하고 사용자가 선택하게 합니다. 허용하지 않는다면 현재 값을 보며 계속 편집하거나, 결정을 내릴 때까지 초안을 잃지 않고 취소할 수 있게 합니다. 실제 작업을 되돌릴 수 없는데 목업에 되돌리기 기능을 약속하지 마세요. 네트워크 시간 초과는 확인된 버전 충돌과도 다릅니다. 시간 초과 뒤에는 서버가 이미 저장했는지 모를 수 있으므로, 현재 값이나 요청 상태를 확인한 후 재시도를 권해야 합니다.

여러 사람이 함께 쓰는 제품이라면 동시 편집 규칙을 개발 전달 문서에 적습니다. 저장 요청에 어떤 버전 식별자를 보내는지, 어떤 필드를 비교하는지, 어떤 응답이 충돌을 뜻하는지 정해야 오래된 편집의 거부와 일반 장애를 화면에서 구분할 수 있습니다. 보기 좋은 토스트만으로 이 계약을 대신할 수는 없습니다.

키보드로도 같은 행을 수정할 수 있게 하기

마우스 없이 수정 동작에 도달할 수 있어야 합니다. 편집을 시작하면 포커스는 단가 입력란으로 이동합니다. Escape로 취소하려면 제품 전체의 규칙으로 정하고, 여러 필드를 고치는 중 Enter가 예상치 못한 제출을 일으키지 않게 합니다. 저장과 취소에는 명확한 이름과 눈에 보이는 포커스가 필요하며, 조회 상태로 돌아간 후 포커스 위치도 정해야 합니다. 오류가 발생하면 해당 필드와 이유를 찾거나 안내받을 수 있어야 합니다.

상호작용이 많은 데이터 표는 그리드 키보드 모델을 쓸 수 있지만, 그리드는 클릭 가능한 셀을 모아 놓은 표가 아닙니다. W3C 그리드 패턴은 그리드 내부의 포커스 이동을 설명합니다. 예시는 학습 자료이며 완성된 구현을 시험하는 일을 대신하지 않습니다. 이 제품에 그리드가 꼭 필요한지 먼저 판단하세요. 각 행에 이름이 명확한 수정 버튼을 둔 일반 시맨틱 표가 더 쉽고 안정적일 수 있습니다.

좁은 화면에서는 공급업체 이름, 수정 중인 단가, 통화, 오류, 저장 버튼을 한데 묶습니다. 부차적인 열을 행 상세 보기로 옮겨도 현재 수정 중인 값은 감추지 않습니다. 모바일 폭뿐 아니라 화면 확대도 시험하세요. 100%에서는 보이던 행 동작이 200%에서는 이름 없는 아이콘이나 가로 넘침이 될 수 있습니다.

Pixso에서 의사결정 흐름 프로토타이핑하기

Pixso에서 가격표 행의 조회, 편집, 입력 오류, 저장 중, 완료, 충돌 변형을 만듭니다. 모든 화면에 같은 공급업체와 품목 코드를 사용하면 검토자가 서로 다른 예시 여섯 개가 아니라 한 레코드의 변화를 추적할 수 있습니다. 편집 및 저장 경로를 프로토타입으로 연결합니다. 가격표는 캔버스에서 설계하는 애플리케이션이며, Pixso 자체가 데이터베이스의 가격을 확정하는 것은 아닙니다.

검토자에게 초안이 열린 동안 저장된 값을 찾고, 음수 입력을 고치고, 동료의 $26.00가 나타났을 때 다음 행동을 고르게 해 보세요. $25.00가 확정됐는지 구분하지 못한다면 시각적 장식을 다듬기 전에 상태 이름이나 비교 방식을 바꿉니다. 이어 프로토타입과 짧은 상태 명세로 검증, 버전 확인, 포커스 이동, 오류 응답을 개발자에게 전달합니다. Pixso에서 행 상태 설계하기.

구현 과정에서 지켜야 할 결정 정리하기

핵심은 새로운 가격 입력란이 아닙니다. 사용자가 입력 중인 값, 처리 중인 저장, 서버가 승인한 값, 서버가 거부한 편집을 확실히 구분하는 것입니다. 이 공급업체 행에 대해서는 저장을 시작하는 동작, 화면과 서버의 각각의 규칙, 정렬·필터 처리, 버전 충돌과 시간 초과에서 돌아오는 방법, 결과별 포커스 위치를 함께 정해야 합니다. 이런 결정이 화면과 명세에 드러나면 개발자가 정지 화면을 보고 동작을 추측할 필요가 없습니다.