지식 베이스

역할 및 권한 수준

역할은 무엇을 할 수 있는지를, 주소 부여는 그것을 어떤 대상에 할 수 있는지를 정합니다.

세부 사항

사람마다 부여가 두 가지 있고, 둘이 일치해야 무언가가 일어납니다. Settings → Members에서 설정하는 역할(ROLE)은 워크스페이스에서 무엇을 할 수 있는지를 정합니다. 메일 읽기, 보내기, 템플릿 편집, 도메인 추가, API 키 발급 같은 것입니다. 주소 행의 Share 컨트롤에서 설정하는 주소 부여(GRANT)는 그것을 어떤 주소에 할 수 있는지를 읽기 전용 또는 읽기 및 발송으로 정합니다. 발송 권한이 있는 역할을 가졌지만 주소가 하나도 없는 사람은 어디에서도 보낼 수 없고, 워크스페이스의 모든 주소를 읽기 전용으로 받은 사람 역시 어느 주소로도 보낼 수 없습니다.
여섯 가지 역할은 아무도 만들지 않아도 존재하며 모든 워크스페이스가 동일한 여섯 가지를 가지므로, “Admin”은 문서에서든 API에서든 여기서와 같은 뜻입니다. Owner, Admin, Member, Viewer는 사다리를 이룹니다. 각 역할이 그다음 역할의 권한을 모두 포함하므로, 강등은 권한을 다른 조각으로 바꾸는 것이 아니라 닿을 수 있는 범위를 좁히는 일입니다. Developer와 Billing은 그 사다리의 단이 아닙니다. Developer는 API 키, 웹훅, 템플릿, 발송을 다루며 통합을 만들지만 워크스페이스의 메일은 전혀 읽지 않고, Billing은 요금제와 청구서를 보고 요금제와 결제 수단을 변경할 수 있으며 메일함 설정을 읽을 수는 있지만 쓸 수는 없습니다. 이들의 권한은 편집할 수 있습니다. 구성원이 템플릿을 쓰지 않기를 바라는 워크스페이스는 해당 항목의 체크를 해제하면 되고, 변경은 그 역할을 명시적으로 보유한 사람이 보내는 다음 요청부터 적용됩니다. 역할이 생기기 전의 주소 부여로 역할이 암묵적으로 추론되는 사람은 역할을 직접 받기 전까지 기본값을 유지합니다. 이름도 마찬가지입니다. Ops와 On-call로 굴러가는 워크스페이스가 역할 이름을 그렇게 바꾼다면 그것은 스스로를 설명하는 일이며, 바로 그것이 목적입니다.
Owner는 모든 면에서 예외입니다. 편집할 수 없고, 삭제할 수 없고, 다른 사람에게 부여할 수도 없습니다. 워크스페이스가 귀속된 계정을 가리키며, 이후 릴리스에서 추가되는 권한까지 포함해 모든 권한을 가집니다. 그 목록이 저장되지 않고 계산되는 이유입니다. 워크스페이스를 다른 사람에게 넘기는 것은 역할 변경이 아니라 이전이며, 여기에는 그 일을 하는 기능이 없습니다.
그 밖의 역할은 워크스페이스가 같은 그룹형 권한 표에서 항목을 체크해 직접 만들며, 최대 24개까지 가능합니다. 체크는 함의를 가집니다. “edit templates”를 체크하면 “read templates”도 함께 저장되는데, 열어 볼 수도 없는 템플릿을 편집할 수 있는 역할은 정책이 아니라 누군가 빠뜨린 체크박스이기 때문입니다. 사람이나 API 키가 보유한 역할을 삭제할 때는 어디로 옮길지 묻고, 추측하지 않고 거부합니다. 역할이 사라진 키는 상한이 아예 없는 상태로 돌아가게 되는데, 이는 방금 사라진 역할보다 더 넓기 때문입니다.
API 키는 역할을 지정해 발급할 수 있으며, 역할은 두 번째 부여가 아니라 상한입니다. 키가 할 수 있는 일은 키 자신의 스코프와 역할 권한의 교집합이며, 요청마다 다시 계산됩니다. 발송 권한을 넣어 만들었더라도 Viewer로 상한이 걸린 키는 보낼 수 없고, 역할을 좁히면 키를 재발급하지 않아도 즉시 권한이 회수됩니다. 어시스턴트도 같은 목록의 제약을 받으며, MCP 서버는 호출자의 권한을 바탕으로 클라이언트의 도구를 구성합니다. 그래서 Viewer의 클라이언트에는 발송 도구가 아예 없고, 목록이 만들어진 뒤에도 세션이 메일함을 전환할 수 있으므로 제한이 걸린 모든 도구는 진입 시 다시 확인합니다.