팀 도구의 권한 UX: 역할·요청·복구 설계하기

권한 UX는 누가 리소스를 볼 수 있고 수정할 수 있는지, 접근 권한이 바뀌면 무엇이 달라지는지를 설명합니다. 프로젝트 읽기, 파일에 댓글 달기, 팀원 초대, 업데이트 게시처럼 사용자가 하려는 행동부터 살펴보세요. 역할에 따라 어떤 결과가 생기는지 분명해야 역할 이름도 유용해집니다.

유용한 권한 흐름은 대상 선택, 역할 이해, 변경 확인, 변경 후 접근 권한 확인까지 전체 작업을 다룹니다. 접근 요청에도 실제 상황을 정확히 알리는 보류 상태가 필요합니다. 인터페이스는 애플리케이션이 내린 권한 부여 결정을 반영해야 합니다. 컨트롤을 숨기는 것만으로 그 결정을 강제할 수는 없습니다.

여기서는 공유, 접근 요청, 상속된 역할, 협업 중 복구에 집중합니다. 더 넓은 팀 작업 흐름은 원격 팀을 위한 UI 디자인 협업 도구(영문)를 참고하세요.

역할 이름보다 사용자의 행동부터 정의하기

“편집자”, “뷰어”, “관리자”는 구현상의 역할 이름이며, 항상 사용자의 목표와 일치하는 것은 아닙니다. 사용자는 프로토타입 수정, 팀원 초대, 파일 내보내기, 링크 게시가 가능한지를 알고 싶어 합니다. 현재 리소스에서 중요한 행동부터 설계하고, 그 행동을 역할과 정책에 연결하세요.

객체, 행동, 대상, 결과를 포함한 권한 매트릭스를 만듭니다.

이 매트릭스는 설계의 입력 자료이며 사용자에게 그대로 보여 줄 문구는 아닙니다. 하나의 역할 이름 안에 여러 기능이 숨겨진 지점과, 되돌리기 어려운 행동에 확인이나 감사 기록이 필요한 지점을 드러냅니다.

사용자가 제한에 부딪히기 전에 경계 알려 주기

사용자가 제한을 마주하는 위치에서 설명하세요. 이유 없이 비활성화된 버튼보다 “프로젝트 소유자만 게시할 수 있습니다”라는 안내가 더 많은 것을 알려 줍니다. 설명을 화면에 보이게 하거나 키보드로 접근할 수 있게 하세요. 마우스를 올릴 때만 보이는 툴팁은 충분하지 않습니다. 실제로 존재하는 경우에만 요청이나 문의 경로를 제공합니다. 현재 맥락에서 절대 사용할 수 없고 설명할 가치도 없는 행동은 비활성 컨트롤을 잔뜩 나열하는 것보다 숨기는 편이 명확할 수 있습니다.

리소스의 존재 자체를 알 권한이 없는 사람에게 비공개 리소스 이름을 보여 주지 마세요. 숨겨진 프로젝트의 제목이나 멤버를 확인해 주지 않으면서 “이 프로젝트에 접근할 수 없습니다”라고 안내할 수 있습니다. 인터페이스가 어디까지 공개해도 되는지는 보안 담당자와 함께 정합니다.

역할 요약은 짧고 행동 중심이어야 합니다. 정책 문단을 길게 보여 주기보다 가장 중요한 기능을 먼저 표시하고, 필요할 때 상세 정보를 열 수 있게 합니다. 멤버 목록, 공유 대화상자, 설정에서 같은 순서를 유지해 사용자가 권한 구조를 다시 배우지 않게 하세요.

공유 후 달라질 일을 미리 보여 주기

공유는 다른 사람이 앞으로 할 수 있는 행동을 바꿉니다. 확인 전에 리소스, 의도한 대상, 접근 수준, 해당하는 경우 만료 시점, 알림 방식을 보여 주세요. 링크를 전달할 수 있다면 그 사실을 알립니다. 역할에 다운로드나 복제가 포함된다면 툴팁에 숨기지 말고 눈에 띄게 표시합니다.

유용한 확인 안내에는 세 가지가 들어갑니다.

1. 누가: 개인, 팀, 그룹 또는 링크를 가진 모든 사람
2. 할 수 있는 일: 보기, 댓글, 편집, 게시 또는 접근 권한 관리
3. 기간: 영구, 예정된 만료 시점까지 또는 수동으로 제거할 때까지

선택한 대상과 역할이 버튼 옆에 명확히 표시된다면 마지막 행동의 라벨은 “공유”여도 됩니다. 특정 팀원에서 “링크를 가진 모든 사람”으로 바꿀 때는 확인 전에 요약을 갱신하고, 로그인하지 않은 방문자도 리소스를 열 수 있는지 포함하세요. 이 전환과 실패 상태를 디자인-코드 핸드오프(영문)에 기록합니다.

역할 변경 결과를 보여 주고 복원 경로 제공하기

역할 변경은 즉시 적용될 수 있지만 변경한 사람에게는 피드백이 필요합니다. 확인 후 무엇이 바뀌었는지, 목록의 어디에 해당 멤버가 있는지 보여 주세요. 정책 검토나 초대 수락을 기다리고 있다면 완료된 것처럼 표시하지 말고 대기 중이라고 알립니다.

정책이 허용한다면 실행 취소하거나 이전 역할을 복원하는 방법을 제공합니다. 실행 취소 메시지에는 단순히 “실행 취소됨”이라고 쓰지 말고 영향을 받는 사람과 리소스를 명시합니다. 관리자가 복원을 승인해야 한다면 다음 단계를 설명하고, 권한이 있는 사람이 변경 이력을 볼 수 있게 보존합니다.

편집 중 접근 권한이 회수되면 새 정책에서 더 이상 허용하지 않는 행동을 중단하고 상황을 설명합니다. 저장하지 않은 작업은 허가된 복구 경로로만 보존해야 합니다. 예를 들어 제품이 소유자용 복구 초안을 보관하되, 권한을 잃은 멤버에게 제한된 자료의 다운로드는 허용하지 않을 수 있습니다. “사본 저장” 버튼을 설계하기 전에 이 동작에 합의하세요.

접근 요청에 꼭 필요한 내용만 받는 양식 설계하기

접근 요청 흐름에서는 승인자에게 필요한 정보만 받습니다. 리소스, 요청하는 행동이나 역할, 선택적으로 입력하는 이유, 관련 기한이 해당합니다. 요청자는 누가 요청을 받고 제출 후 무엇이 일어나는지 알아야 합니다. 시스템이 이미 파일과 팀을 알고 있다면 사용자에게 프로젝트 전체를 다시 설명하게 하지 마세요.

제출 후에는 보류, 승인, 거절, 만료, 취소를 구분합니다. 보류는 요청이 기록되었다는 뜻이지 접근 권한이 부여되었다는 뜻이 아닙니다. 같은 링크로 다시 돌아올 수 있도록 리소스 페이지에 지속적인 상태 표시를 둡니다. 취소나 새 요청이 허용되면 해당 행동을 보여 주되, 모든 상태에 반드시 추가 행동을 넣을 필요는 없습니다.

요청을 보낸 뒤에도 접근 제한이 유지되고 있음을 보여 주세요. “요청을 보냈습니다”라는 토스트 알림은 너무 빨리 사라져 지금 작업을 시작할 수 있는지도 알 수 없습니다. 리소스 페이지에 기존 맥락을 유지한 작은 상태 패널과 요청 상세 링크를 둘 수 있습니다.

제출 실패는 보류 중인 요청과 따로 처리합니다. 응답이 불확실하면 다시 제출하도록 안내하기 전에 같은 요청이 이미 존재하는지 확인하세요. 개발에 전달할 때 요청 식별자, 상태 갱신 방식, 결정 권한자, 리소스나 승인자가 바뀌었을 때의 처리를 명시합니다. 그래야 잘 다듬어진 양식이 중복 요청이나 추적할 수 없는 요청을 만들지 않습니다.

상속 권한과 직접 부여한 권한 구분하기

팀 도구에서는 워크스페이스, 프로젝트, 폴더, 그룹에서 상속된 접근 권한과 개별 파일에 직접 부여된 권한이 함께 적용되는 경우가 많습니다. UI에는 실제로 적용되는 권한의 출처를 표시해야 합니다. “뷰어”만 표시하는 것보다 “디자인 팀을 통해 부여된 뷰어 권한”이 더 유용합니다. 어디에서 변경해야 하는지를 설명하기 때문입니다.

사용자가 상속된 역할을 바꾸려 하면 적용 경계를 설명하고 유효한 경로를 안내합니다. 예를 들어 “이 접근 권한은 프로젝트에서 상속됩니다. 변경하려면 프로젝트 멤버의 역할을 수정하세요”라고 알릴 수 있습니다. 편집할 수 있어 보이지만 실제 효과가 없는 컨트롤은 보여 주지 마세요.

여러 출처가 접근에 영향을 준다면 제품 정책이 계산한 실제 적용 권한과 관련 출처를 설명합니다. 가장 넓은 허용이 항상 우선한다고 가정하지 마세요. 명시적 제한, 조직 정책, 리소스 규칙에 따라 결과가 달라질 수 있습니다. 예를 들어 직접 부여한 뷰어 권한을 제거해도 프로젝트 그룹을 통한 접근은 남을 수 있습니다. “접근 권한 제거”라고 설명하기 전에 실제로 달라질 결과를 미리 보여 주세요.

게스트·외부 링크·그룹을 서로 다른 대상으로 다루기

외부 게스트와 내부 팀 구성원은 현재 가능한 행동이 같더라도 계정과 권한의 수명, 위험 수준은 다를 수 있습니다. 대상을 명확히 표시하고 만료, 도메인 제한, 다운로드 규칙이 적용되면 이를 보여 주세요. “모든 사람”에게 공유된 링크가 조직 내부로 제한된 링크와 똑같아 보여서는 안 됩니다.

그룹의 구성원을 확인하는 과정에서도 사용자가 볼 수 없는 정보를 노출하지 않아야 합니다. 그룹 이름과 실제 적용 역할을 보여 주고, 권한이 허용되는 경로에서 구성원 상세 정보를 확인하게 합니다. 여러 그룹을 통해 접근 권한을 받은 멤버에게는 숨겨진 그룹 이름을 공개하지 않고 적용 결과를 설명하세요.

이러한 구분은 여러 지역에 걸쳐 일하거나 규제가 적용되는 환경의 팀에 특히 중요합니다. 규제 산업을 위한 온프레미스 UI 디자인 도구(영문)는 배포 제약의 맥락을 설명합니다. 다만 권한 인터페이스에서는 개별 행동 수준의 쉬운 설명이 여전히 필요합니다.

작업 중 접근 권한이 바뀌었을 때 복구하기

프로젝트 이동, 초대 만료, 소유자의 역할 변경, 정책 업데이트 적용으로 접근 권한을 잃을 수 있습니다. 전체 화면을 일반적인 오류 메시지로 바꾸지 마세요. 마지막으로 확인된 맥락을 유지하고, 더 이상 할 수 없는 일을 설명하며, 가장 안전한 다음 행동을 제공합니다.

정책이 허용하는 로컬 초안 저장, 접근 가능한 상위 위치로 이동, 접근 권한 다시 요청, 담당 소유자에게 문의 등의 복구 행동을 제공할 수 있습니다. 시스템이 콘텐츠를 보존할 수 없다면 사용자가 페이지를 닫기 전에 알려 주세요. 실제 역할이 바뀐 상황에서 다시 시도하면 접근이 복원되는 것처럼 암시해서는 안 됩니다.

협업 세션에서는 “다른 버전을 게시 중이어서 읽기 전용”인 경우와 “내 역할이 바뀌어서 읽기 전용”인 경우를 구분합니다. 같은 컨트롤이 비활성화되더라도 설명과 지원 경로는 달라질 수 있습니다. 팀 협업 도구 안내(영문)처럼 워크스페이스의 협업 지침을 연결하되, 현재 상태를 설명하는 문구를 링크로 대신하지 않습니다.

감사 기록과 알림 동작을 이해할 수 있게 설명하기

권한 변경은 설정 페이지를 보고 있지 않은 사람에게도 영향을 줄 수 있습니다. 누가 어떤 알림을 받는지, 활동 로그에 변경이 기록되는지 알리세요. 제품이 실제로 이메일이나 알림을 보내지 않는다면 발송을 약속하지 않습니다. 대량 변경에서 알림을 보내지 않는 경우에는 확인 화면의 상세 정보에 설명합니다.

활동 기록에는 수행자, 행동, 리소스, 대상, 시간이 포함되어야 합니다. 사용자가 열람할 권한이 있는 경우에만 리소스 링크를 제공합니다. 영향이 큰 행동에는 확인이나 재인증이 적절할 수 있지만, 이유 없는 방해가 아니라 안전을 위한 확인 절차임을 설명해야 합니다. 감사 로그의 목록과 상세 화면에서는 기록된 사건과 불러오기 상태도 구분하세요.

개별 화면보다 전체 과업으로 권한 테스트하기

소유자, 편집자, 댓글 작성자, 뷰어, 게스트, 권한이 없는 방문자의 전체 시나리오를 만듭니다. 접근 권한을 상속받고, 요청하고, 변경하고, 회수하고, 복원하는 순간을 포함하세요. 직접 링크와 공유 링크는 제품 내 탐색과 별도로 테스트합니다.

검토자에게 다음과 같은 과업을 수행하게 합니다.

1. 편집은 할 수 없고 댓글만 달아야 하는 팀원에게 파일 공유하기
2. 게시 기능을 사용할 수 없는 이유 찾기
3. 제한된 프로젝트에 접근을 요청하고 요청 상태 확인하기
4. 게스트를 제거하고 그 사람이 열어 둔 세션이 어떻게 되는지 확인하기
5. 그룹 역할을 바꾸고 변경 사항을 상속받는 파일 찾기

사용자가 어느 지점에서 권한의 경계를 이해하고, 어느 지점에서 추측해야 하는지 기록합니다. 공유 대화상자가 잘 다듬어져 있어도 변경 후 상태가 혼란스러우면 이를 만회할 수 없습니다.

Pixso에서 접근 제한 화면, 요청 양식, 지속적으로 표시되는 보류 상태의 세 화면을 연결해 접근 여정을 만듭니다. 흐름을 이동하는 동안 리소스 맥락을 유지하세요. 프로토타입 리뷰에서는 요청을 제출하면 즉시 접근할 수 있는지, 상태는 어디서 확인하는지 물어봅니다. 세 번째 화면이 사라지는 토스트 알림에 기대지 않고 답을 명확히 보여 줘야 합니다. 디자인 파일 자체를 공유할 때도 상황에 맞는 뷰어 또는 편집자 권한을 선택하세요.

Pixso에서 접근 요청 흐름 프로토타입 만들기 →

요청자와 승인자 양쪽에서 결과 확인하기

요청자와 승인자의 입장에서 같은 접근 요청을 검토합니다. 승인 전에는 요청자가 지속적인 보류 상태를 볼 수 있어야 하고 제한된 콘텐츠는 계속 열 수 없어야 합니다. 승인 후에는 부여된 역할이 결정 내용과 일치하는지 확인합니다. 이어서 상속 권한은 유지한 채 직접 부여한 권한을 제거하고, 인터페이스가 남아 있는 접근 권한을 정확히 표시하는지 확인하세요. 마지막 화면은 클릭한 버튼 이름을 반복하는 대신 실제 적용 결과를 설명해야 합니다.

추가 읽을거리

• OWASP: 권한 부여 치트시트(영문)
• W3C: 보안 및 개인정보 보호 질문서(영문)
• NIST: 접근 제어 개요(영문)