팀 구조

TRUSCA는 권한을 하나의 조직, 다수의 팀, 세 가지 역할로 모델링합니다. 프로젝트는 팀에 귀속되고 역할은 팀별로 부여됩니다. 이 구조가 누가 무엇을 스캔하고, 누가 승인을 처리하고, 누가 어떤 프로젝트를 보는지를 결정하므로 우연히 자라게 두기보다 설계할 가치가 있습니다. 이 페이지는 엔지니어링 조직이 실제로 일하는 방식에 맞는 팀 배치를 고르도록 돕습니다.

대상 독자

설치 시점에 조직을 배치하는 super_admin, 그리고 자기 팀을 나눌지 결정하는 team_admin. RBAC 모델에 익숙하다고 가정합니다. RBAC(역할 기반 접근 제어)는 권한이 개인이 아니라 역할에 붙는 방식입니다.

한 그림으로 본 모델

Organization (배포당 하나)
├── Super Admin        — 시스템 전반: 모든 /admin 화면, 팀 생성·삭제, 모든 프로젝트 편집
├── Team A
│   ├── Team Admin     — Team A의 멤버십·설정·정책·API Key 관리, 승인 처리
│   └── Developer      — Team A 프로젝트의 스캔 실행, 결과 분류
└── Team B
    └── ...

배포당 정확히 하나의 조직이 존재합니다. 역할은 여러 팀에 걸쳐 누적되고 프로젝트 소속 팀 기준으로 평가되므로, 사용자는 팀마다 다른 역할을 가질 수 있습니다 — 한 팀에서 team_admin, 다른 팀에서 developer. 전체 역할 권한 표를 참고하십시오.

역할 고르기

각자가 자기 일을 할 수 있는 최소 역할을 부여하십시오.

역할	부여 대상	부적합
super_admin	배포를 운영하는 운영자 — 설치·업그레이드·백업·Trivy DB·조직 전반 정책.	일반 엔지니어. super-admin은 모든 팀 데이터를 읽습니다.
team_admin	팀의 기술 리드나 컴플라이언스 담당 — 멤버·팀 정책·API Key 관리와 승인 처리.	팀의 모든 엔지니어.
developer	스캔·분류하는 엔지니어.	보고서만 읽으면 되는 사람 — 읽기는 팀 멤버십으로 이미 됩니다.

super-admin을 최소 둘 유지하십시오

포털은 마지막 활성 super_admin의 강등·비활성화를 거부하지만, 그 가드는 하한선이지 계획이 아닙니다. 오프보딩이나 잊은 비밀번호가 /admin 접근을 막지 않도록 항상 두 번째 super-admin을 두십시오. 마지막 super-admin 보호를 참고하십시오.

super_admin은 아껴 부여하십시오 — 조직 전반이며 팀 경계를 넘습니다. 대부분의 컴플라이언스 담당은 자신이 소유한 팀의 team_admin만 있으면 됩니다.

프로젝트 가시성: team-only vs org-wide

각 팀은 자신이 만드는 프로젝트의 기본 가시성을 가지며, 팀 생성 시 설정합니다.

가시성	프로젝트를 볼 수 있는 사람	사용 시점
team_only(기본)	소유 팀의 멤버만	기본값. 프로젝트에는 팀이 넓게 노출하기 전에 분류해야 할 발견 항목이 있습니다.
org_wide	조직의 모든 사용자(읽기)	공유 플랫폼 라이브러리, 참조 SBOM, 또는 조직 전체가 리스크 태세를 봐야 하는 프로젝트.

가시성은 읽기 노출을 규율하며 쓰기는 아닙니다. 편집·스캔·승인 처리는 가시성과 무관하게 여전히 소유 팀의 역할을 요구합니다. team_only로 시작하고 프로젝트를 의도적으로 org_wide로 승격하십시오 — 넓히기는 쉽고, 팀의 진행 중인 분류를 기본값으로 조직 전체에 누출하는 일을 피합니다.

팀을 언제 나누는가

팀은 소유·가시성·정책의 단위입니다. 단지 인원이 늘어서가 아니라 이 셋이 갈라지려 할 때 나누십시오.

• 정책 요구가 다름. 한 그룹은 재배포 바이너리를 내보내고(카피레프트가 실제 리스크) 다른 그룹은 폐쇄형 SaaS를 배포합니다(카피레프트가 대개 무방). 팀별 라이선스 정책은 이들이 별도 팀일 때만 도움이 됩니다.
• 승인 권한이 다름. 승인은 소유 팀의 team_admin이 처리합니다. 그룹 A가 그룹 B의 조건부 라이선스 사용을 승인해서는 안 된다면 별도 팀이 필요합니다.
• 가시성 경계. 기밀 프로젝트를 무관한 엔지니어가 읽어서는 안 됩니다. 팀을 나누면 team_only가 의미를 유지합니다.
• 독립적인 멤버십 변동. 다른 주기로 온·오프보딩하는 계약직이나 파트너 팀은 자기 팀에 두어, 멤버십 변경이 핵심 팀을 건드리지 않게 하십시오.

나누지 않을 이유: 여러 팀이 소비하는 공유 컴포넌트(대신 그 프로젝트를 org_wide로), 또는 일시적 하위 그룹(팀보다 역할 부여가 가볍습니다). 팀이 하나 늘 때마다 관리할 멤버십 목록과 정책도 하나 늘어납니다 — 정돈을 위해서가 아니라 경계를 위해 나누십시오.

한 사람, 여러 팀

역할이 팀별이므로, 플랫폼 엔지니어는 계정 두 개 없이 공유 인프라 팀의 team_admin이면서 제품 팀의 developer일 수 있습니다. 팀을 나눠도 한 사람의 접근이 조각나지 않습니다 — 대신 알맞은 역할로 멤버십을 추가하십시오.

팀을 넘나드는 공유 컴포넌트

같은 의존성이 여러 팀의 프로젝트에 나타나면 각 프로젝트가 자체 승인 요청을 올립니다 — 같은 라이선스도 배포 모델에 따라 다른 의무를 지므로 판정이 전파되지 않습니다. 이는 의도된 것입니다(교차 프로젝트 승인 참고). 한 판정을 어디에나 적용하려면 각 프로젝트의 요청을 처리하며 원래 결정을 참조하거나, 그 판정을 조직 기본 정책의 라이선스 재정의로 담아 모든 팀이 상속하게 하십시오.

검증

고른 배치를 점검하십시오.

1. 모든 엔지니어가 일할 수 있는 최소 역할을 가집니다 — 멤버·정책·승인을 관리하지 않는 한 developer입니다.

2. 활성 super_admin 계정이 둘 이상 존재합니다.

3. 새 프로젝트는 team_only가 기본이며, org_wide 프로젝트는 기본값이 아니라 의도적 선택입니다.

4. 서로 다른 라이선스 정책이나 승인 권한이 필요한 팀은 실제로 별도 팀이고, 여러 팀 접근이 필요한 사람은 super_admin 승격 대신 각 팀에 알맞은 역할로 추가됩니다.

5. 공유 의존성의 승인 판정은 프로젝트별로 처리하거나 조직 기본 정책에 한 번 담깁니다 — 전파를 기대하지 않습니다.

함께 보기

• 사용자 및 팀 — 역할·멤버십·마지막 super-admin 보호·팀 생성
• 사용자 및 팀 — 역할 — 전체 권한 표
• 승인 — 교차 프로젝트 승인 — 판정이 전파되지 않는 이유
• 정책 설계 — 조직 기본 vs 팀별 정책