저장한 테이블 뷰 UX: 필터·공유·오래된 조건 다루기

저장된 테이블 뷰를 열기 전에도 사용자는 세 가지를 알 수 있어야 한다. 어떤 조건이 적용되는지, 누가 그 조건을 바꿀 수 있는지, 실제로 볼 수 있는 데이터는 어디까지인지다. 뷰는 필터·정렬·표시 열을 다시 불러오는 설정이지 데이터의 별도 복사본이 아니다. 설정이 바뀌거나 일부 조건이 무효가 됐다면, 결과 목록만 조용히 바꾸지 말고 그 이유를 보여줘야 한다.

행과 열, 선택 상태 같은 표의 기본 구조부터 설계해야 한다면 데이터 테이블 컴포넌트 가이드를 먼저 살펴보자. 이 글은 그다음 단계에 집중한다. 운영 담당자 지민은 주문표를 원하는 조건으로 좁힌 뒤, 내일 같은 작업으로 돌아오고 팀원과 일부 설정을 공유하려 한다. 이때 다른 사람의 목록이 예상 밖으로 바뀌지 않게 하려면 무엇을 설계해야 할까?

이름을 붙이기 전에 무엇을 저장할지 정한다

상태, 담당자, 요청일, 주문 금액, 고객 열이 있는 주문표를 생각해 보자. 지민은 상태를 ‘검토 필요’, 담당자를 본인, 요청일을 최근 7일로 좁히고 최신순으로 정렬한다. 자주 쓰지 않는 열도 숨긴다. ‘뷰 저장’ 버튼을 만들기 전에 필터·정렬·열 배치 중 무엇이 저장되는지 결정해야 한다. 필터만 저장한다면 저장 화면에서 그렇게 알려야 한다. 그렇지 않으면 지민은 내일도 표가 지금과 똑같이 열릴 거라고 생각한다.

주문 데이터는 계속 한 곳에 있다. 저장된 뷰는 오늘의 행을 복제하는 스냅샷이 아니라 그 행을 보여주는 규칙이다. 내일 새로 들어온 주문도 조건에 맞으면 같은 뷰에 나타날 수 있다. 따라서 ‘내 검토 대기열’처럼 작업을 설명하는 이름이 ‘주문 12건’처럼 고정된 건수를 암시하는 이름보다 낫다. 현재 뷰 이름 옆에 ‘검토 필요 · 내 담당 · 최근 7일’과 같은 짧은 조건 요약을 두면 필터 패널을 다시 열지 않아도 목록을 이해할 수 있다.

‘내 담당’은 공유할 때 뜻이 모호해진다. 여기서 ‘나’는 만든 사람 지민인가, 지금 뷰를 여는 사람인가? 팀원마다 자기 업무를 보는 뷰라면 열람자를 기준으로 조건을 평가하고 그렇게 표시해야 한다. 지민이 자신의 주문을 인계하려는 것이라면 공유 전에 동적 조건을 지민의 이름으로 바꿔야 한다. 같은 공유 링크가 사람마다 다른 의미로 작동한다면 결과 건수만 보여줘서는 원인을 파악하기 어렵다.

임시 변경과 저장된 정의를 구분한다

지민이 ‘최근 7일’을 ‘최근 30일’로 바꾸면 표의 행은 즉시 달라질 수 있지만 저장된 뷰까지 바로 바뀔 필요는 없다. 화면은 저장된 설정을 보는 상태와 저장되지 않은 변경을 시험하는 상태를 구분해야 한다. 후자에는 ‘저장되지 않은 변경’이라고 표시하고, 기존 뷰 업데이트·새 뷰로 저장·변경 취소 중 가능한 선택지를 제시한다. 필터 칩 하나를 눌렀다는 이유만으로 개인적인 탐색을 팀 전체의 기본 설정으로 만들지 않는다.

버튼 이름에도 영향 범위가 드러나야 한다. ‘공유 뷰 업데이트’는 동료가 다음에 열 때 보는 설정을 바꾸고, ‘개인 뷰로 저장’은 공용 설정을 그대로 둔다. 공유 뷰를 수정할 권한이 없는 사람도 일시적으로 다른 조건을 적용해 볼 수 있다면, 제품 정책이 허용하는 범위에서 개인 사본을 저장할 길을 준다. 편집 컨트롤을 모두 숨기면 사용자는 다른 결과가 필요할 뿐인데 뷰 자체가 고장 났다고 느낄 수 있다.

정확한 권한 체계는 각 제품의 데이터 모델에 달려 있다. Microsoft의 개인 뷰 설명은 열·정렬·필터를 묶는 사례를 보여주고, Airtable의 뷰 문서는 공동 작업용·개인용·잠긴 설정을 구분한다. 설계 질문을 찾는 데 참고하되 다른 제품의 접근 권한을 그대로 복제하지는 말자.

뷰 공유와 원본 데이터 접근을 혼동하지 않는다

뷰 선택 목록에는 실제 정책에 맞춰 ‘개인용’, ‘팀용’ 또는 소유자를 표시한다. 팀 뷰라면 누가 설정을 편집할 수 있는지도 알려준다. 지민이 ‘검토할 주문’ 뷰를 동료 민수에게 공유할 때는 확정 전에 받는 사람과 부여되는 권한을 보여줘야 한다. 링크를 복사했다는 사실만으로 민수가 열 수 있다는 뜻은 아니다.

특히 뷰의 정의를 공유하는 일이 원본 주문에 대한 접근 권한을 자동으로 부여해서는 안 된다. 민수는 뷰를 볼 권한이 있어도 조건에 맞는 주문 중 일부만 볼 수도 있고, 한 건도 못 볼 수도 있다. 이때 ‘이 뷰는 사용할 수 있지만 조건에 맞는 주문을 볼 권한이 없습니다’와 ‘조건에 맞는 주문이 없습니다’는 다른 메시지여야 한다. 데이터 권한이 없는 사람에게 미리보기로 숨겨진 고객 이름이나 건수를 노출하지 않는다.

기본 뷰에도 적용 범위가 있다. 개인 기본 뷰는 지민의 시작 화면만 바꾸지만 팀 기본 뷰는 모두의 시작 화면을 바꾼다. 명령을 분리하거나 이름에서 범위를 명확히 밝힌다. 소유자가 공유 뷰를 잠글 수 있다면 팀원이 자기 세션에서 임시 필터를 바꿀 수 있는지도 설명해야 한다. 공유 설정을 잠그는 것과 데이터 행을 고정하는 것은 다르다.

삭제된 필드와 오래된 조건·링크를 다룬다

저장된 뷰는 표 구조가 바뀐 뒤에도 남는다. 관리자가 ‘검토 필요’를 ‘승인 대기’로 바꾸거나 요청일 필드를 삭제했다고 하자. 이전 필터를 조용히 제거하면 지민이 예상한 것보다 훨씬 넓은 목록이 나타날 수 있다. 반대로 아무 설명 없이 0건을 보여주면 실제 주문이 있는데도 업무가 끝났다고 오해할 수 있다. 무효가 된 규칙을 감지하면 뷰 이름을 유지하고 ‘상태 “검토 필요”를 더 이상 사용할 수 없습니다’처럼 문제가 된 조건을 짚는다. 대체 값을 제안하더라도 적용 전에 확인할 수 있어야 한다.

표시 이름만 바뀐 경우와 값 자체가 삭제된 경우를 구별한다. 시스템이 안정적인 필드 식별자를 유지한다면 이름이 바뀌어도 필터의 의미는 그대로일 수 있다. 필드나 선택지가 실제로 삭제됐다면 새 조건을 선택해야 한다. 그동안 일부 결과를 표시할지, 안전하게 비워 둘지, 소유자의 조치를 기다릴지는 보안과 업무 흐름을 함께 고려해 제품에서 정할 문제다.

오래된 공유 링크에도 별도 상태가 필요하다. 팀 뷰가 삭제됐다면 아무 설명 없이 관련 없는 기본 뷰로 보내지 않는다. 사용할 수 없다는 이유를 밝히고 주문표나 접근 가능한 다른 뷰로 안내한다. 역할 변경으로 지민의 권한이 사라진 경우도 ‘필터 오류’가 아니라 접근 문제로 설명해야 한다.

상태 변화를 작은 명세로 검토한다

보기 좋은 뷰 선택 메뉴 하나만으로는 충분하지 않다. 목록에 대한 기대가 달라지는 순간을 함께 설계하자.

팀 뷰 저장에도 데이터 편집과 비슷한 충돌이 생긴다. 지민이 조건을 시험하는 동안 민수가 공유 필터를 바꿨다면 양쪽 설정을 보여주고 권한 있는 사람이 공유 뷰를 업데이트할지 개인 사본으로 남길지 결정하게 한다. 민수의 변경을 덮어쓴 뒤 ‘저장됨’ 알림만 띄우면 팀이 내려야 했던 선택이 가려진다.

Pixso에서 뷰를 고르는 흐름을 시제품으로 만든다

Pixso에 주문표 하나와 연결된 화면 세 개를 만든다. 지민의 ‘내 검토 대기열’, 저장되지 않은 30일 버전, 오래된 상태 조건을 포함한 팀 뷰다. 화면마다 같은 주문·용어·건수를 사용해야 무엇이 달라졌는지 검토자가 추적할 수 있다. 뷰 선택 메뉴는 범위 표시와 활성 조건 요약을 포함한 재사용 가능한 컴포넌트로 만들고, 업데이트·새로 저장·취소·조건 확인을 해당 화면에 연결한다.

설명 없이 검토자에게 물어보자. 30일 범위가 이미 팀에 저장됐는가? 민수가 링크를 열면 ‘내 담당’은 누구를 뜻하는가? ‘검토 필요’ 값이 사라지면 어떻게 되는가? 답을 찾을 수 없다면 색을 다듬기 전에 이름과 상태 피드백을 고쳐야 한다. Pixso 시제품은 이 판단 흐름을 시험하는 곳이지, 주문을 저장하거나 접근 권한을 실제로 강제하는 시스템은 아니다.

개발팀에는 시제품과 함께 짧은 상태 명세를 건넨다. 어떤 설정을 저장하는지, 변경 이력을 어떻게 구분하는지, 뷰 정의와 데이터 행에 각각 어떤 권한이 적용되는지, 동적 조건과 무효 조건을 어떻게 처리하는지 기록한다. Pixso에서 저장 뷰 흐름 설계하기.

다시 열었을 때의 결과까지 예측할 수 있게 한다

좋은 저장 뷰는 작업으로 돌아가는 믿을 만한 경로다. 지민은 무엇이 저장됐는지, 무엇을 잠깐 바꿨는지, 누가 공유 설정을 수정할 수 있는지, 어제와 결과가 왜 다른지 알아야 한다. 첫 번째 ‘저장’ 클릭뿐 아니라 다음 방문을 설계하면, 뷰는 예상 밖의 표 위에 붙은 이름이 아니라 팀이 신뢰할 수 있는 도구가 된다.