프로젝트와 역할

프로젝트는 관련 사람, 파일과 폴더를 모으는 협업 단위이며, 재량적 역할 부여의 기본 경계입니다. 같은 프로젝트에서 일하는 사용자는 대체로 같은 콘텐츠에 접근하되, 읽기와 편집처럼 수행할 작업은 역할에 따라 다르게 구성합니다. 조직, 보안 표지와 보안 분류 같은 강제적 접근 요건은 프로젝트 역할과 함께 적용됩니다.

로직과 결과를 같은 프로젝트에 배치

변환과 분석은 프로젝트 안에서 수행하고 결과도 로직과 같은 프로젝트에 둡니다. 예를 들어 코드 저장소와 그 저장소가 만드는 출력 데이터셋을 같은 프로젝트에 배치합니다.

프로젝트 수준에서 그룹에 역할을 부여하면 내부 리소스가 그 역할을 상속합니다. 모든 구성원에게 기본 Viewer를 주고 특정 유지보수 그룹에만 Editor를 부여하는 식으로 구성할 수 있습니다. 개별 파일마다 사용자를 추가하는 방식보다 권한의 목적과 적용 범위를 파악하기 쉽습니다.

프로젝트 역할은 해당 프로젝트의 리소스에 적용됩니다. 상류 프로젝트 데이터를 사용해 다른 프로젝트에 결과를 만들었을 때, 상류의 역할 부여가 결과로 전파되는 것은 아닙니다. 파생 결과에도 같은 자격 조건을 유지해야 한다면 보안 표지 등 강제적 접근 통제를 사용합니다.

프로젝트 생성

공간 안에 프로젝트를 만들려면 해당 공간의 Editor 또는 Owner 권한이 필요합니다. 공간 권한은 공간 설정에서 관리합니다. 프로젝트 생성 화면에서 이름과 위치, 접근 요건과 기본 역할을 확인합니다.

프로젝트 기본 역할은 접근 요건을 충족한 사용자에게 자동으로 부여하는 역할입니다. 프로젝트 생성 화면에서는 별도로 지정하지 않으면 Viewer를 사용하므로, 조직과 공간의 설정에 맞는 공개 범위인지 확인해야 합니다. 프로젝트 생성 API를 사용할 때는 기본 역할인 defaultRoles와 특정 주체에게 부여할 roleGrants를 구분하여 구성합니다.

프로젝트 접근 신청

접근이 필요한 사용자는 다음 위치에서 신청할 수 있습니다.

신청 창에서는 접근 사유, 권한을 받을 사용자와 그룹, 권한을 얻을 방법을 선택합니다. 다른 사람을 대신해 신청할 수도 있습니다. 신청은 프로젝트 역할뿐 아니라 접근에 필요한 보안 표지 변경도 포함할 수 있습니다.

프로젝트에 역할이 있는 그룹으로 가입하는 방식을 우선 사용합니다. Foundry 내부 그룹을 선택하면 그룹 관리자에게 승인 요청이 전달됩니다. 그룹별 맞춤 신청 양식을 구성해 적절한 그룹을 선택하도록 안내하거나, 특정 그룹을 신청 목록에서 숨길 수도 있습니다.

외부 시스템이 관리하는 그룹은 Foundry 안에서 직접 소속을 바꾸는 대신 안내 메시지와 외부 신청 URL을 표시합니다. 프로젝트에 지정된 그룹이 없으면 원하는 역할로 직접 추가해 달라고 신청할 수 있으며, 프로젝트의 Owner가 승인합니다.

신청이 접수되면 메시지의 View details에서 내용을 보거나, 작업 공간 사이드바의 Approvals 받은 편지함에서 My requests를 선택합니다. 접수 메시지는 신청이 만들어졌다는 뜻이며 승인이 끝났다는 뜻은 아닙니다.

파일이나 폴더에서 시작한 신청

프로젝트 안의 파일이나 폴더에서 Request access를 눌러도 신청 대상은 그 개별 파일이 아니라 프로젝트입니다. 검토 화면에는 어떤 파일이나 폴더에서 시작했는지 표시되므로 승인자가 사용 목적을 판단할 수 있습니다.

리소스 이동과 공유

협업할 리소스는 Your files에서 직접 공유하기보다 업무에 맞게 권한을 설정한 프로젝트로 옮기는 것이 좋습니다. 프로젝트의 접근 패널에서 어떤 사용자와 그룹이 역할을 갖는지 관리합니다.

프로젝트를 옮기면 목적지의 상속 권한과 요건이 적용됩니다. 목적지에서 파일별 역할 부여를 금지하는 경우에는 기존 직접 역할도 제거될 수 있으므로 이동 전 경고를 확인합니다.

다른 프로젝트의 데이터를 참조

Foundry 빌드는 입력과 출력을 같은 프로젝트 범위 안에서 다룹니다. 외부 프로젝트의 데이터셋을 입력으로 사용하려면 리소스 참조(Reference)를 추가해 현재 프로젝트 범위에 포함합니다. 참조는 원본을 복사하는 작업이 아닙니다.

일반적으로 원본 프로젝트의 Viewer와 목적지 프로젝트의 Editor가 참조 추가에 필요합니다. 참조는 Code Repositories, Code Workbook, Pipeline Builder, Fusion과 Contour 등에서 추가할 수 있습니다. Your files의 파일은 권한 문제가 생길 수 있으므로 직접 참조하지 못하며, 먼저 프로젝트로 옮깁니다.

가상의 Flight Control System [Datasource] 프로젝트의 flights를 Flight Delays [Transform] 프로젝트에서 참조해 delays를 만든다고 가정합니다.

변환 프로젝트의 사용자는 필요한 조직과 보안 표지 요건을 충족하면 그 프로젝트의 delays를 읽고 후속 변환을 만들 수 있습니다. 그러나 원본 flights를 직접 보거나 그 원본을 새 변환의 입력으로 쓰려면 상류 프로젝트의 Viewer가 여전히 필요합니다. 참조가 원본에 대한 접근 권한을 대신 부여하지는 않습니다.

모든 항공편 데이터 이용자가 별도 교육을 이수해야 한다면 원본에 보안 표지를 적용할 수 있습니다. 이 표지는 delays 같은 파생 데이터에도 전파되므로, 변환 프로젝트 소유자가 역할을 주더라도 표지 자격이 없는 사용자는 보호된 데이터에 접근할 수 없습니다.

역할의 기본 동작

기본 제공 역할은 기능 범위가 넓은 순서대로 Owner, Editor, Viewer, Discoverer입니다. 기본 정의에서는 사용자가 자신과 같거나 더 낮은 역할을 다른 사용자에게 부여할 수 있습니다. Owner는 네 역할을 모두, Discoverer는 Discoverer만 부여할 수 있습니다.

기본 역할의 구성을 바꾸려면 기본 역할 집합을 사용자 정의 역할 집합으로 복제한 뒤 그 안의 역할을 편집합니다. 역할 관리자는 새 역할을 추가하고 역할마다 허용할 작업을 정할 수도 있습니다. 역할은 독립적인 작업 집합이므로 사용자 지정 환경에서 이름상 더 높은 역할이 다른 역할의 모든 작업을 포함한다고 보장할 수는 없습니다. 실제 역할 정의와 역할 부여 가능 범위를 확인해야 합니다.

역할은 파일 계층으로 상속됩니다. 프로젝트나 폴더의 Viewer는 그 안의 리소스에도 Viewer를 제공합니다. 강제적 접근 요건은 여전히 적용되므로 Owner도 필요한 조직, 표지 또는 분류 조건을 우회할 수 없습니다.

파일과 폴더의 직접 역할 제한

프로젝트 Owner는 프로젝트의 Settings에서 파일과 폴더에 직접 역할을 부여할 수 있는지를 설정합니다. 이 기능을 끄면 역할은 프로젝트 수준에서만 부여할 수 있습니다.

설정을 끌 때 이미 내부 파일이나 폴더에 직접 부여한 역할이 있으면 그 역할을 제거합니다. 설정을 다시 켜기 전에는 같은 직접 역할을 추가할 수 없습니다. 직접 역할이 있는 리소스를 이 설정이 꺼진 프로젝트로 옮기는 경우에도 직접 역할을 제거합니다. 플랫폼은 설정 변경이나 이동 때 이 영향을 경고합니다.

파일이나 폴더 링크를 통한 공유도 수신자에게 직접 역할을 주는 방식이므로, 이 설정을 끄면 해당 링크 공유 기능을 사용할 수 없습니다. 프로젝트 설정 화면에서 파일과 폴더의 직접 역할 부여는 기본적으로 비활성화되어 있으며, 공간 관리자가 공간 수준의 기본 동작을 바꿀 수 있습니다. 일관된 프로젝트 권한을 유지하려면 비활성 상태를 유지하는 것이 권장됩니다.

Create Project API에서는 resourceLevelRoleGrantsAllowed를 생략하면 true를 사용합니다. API로 프로젝트를 만들면서 개별 리소스의 직접 역할 부여를 막으려면 이 필드에 false를 명시합니다.