엔터프라이즈 내 조직 모범 사례 정보
엔터프라이즈 내에서 조직을 구조화하기 위한 방법은 여러 가지입니다. 각 접근 방식마다 장단점이 있으며 엔터프라이즈에 가장 적합한 구조는 규모 및 보안 제약 조건 등 비즈니스의 특성과 요구 사항에 따라 달라집니다.
그러나 현재의 문화 대신, 만들려는 문화에 전략을 맞추는 것이 좋습니다. 협업 및 내부 소싱 측면을 발전시키려면 이에 따라 도구를 구성하세요. 그러면 도구가 차단기로서 기능하는 대신, 문화적으로 변화하는 데 유용할 수 있습니다.
조직 구성 수 정보
일반적으로 GitHub 에서는 조직의 수를 최소화하여 만들 것을 권장합니다. 조직이 적으면 협업과 내부 소싱이 강화되어 효율성이 높아집니다. 실제로 하나의 조직일 때 서비스를 가장 잘 제공하는 비즈니스가 많은데, 그 이유는 다음과 같습니다.
- 조직이 하나면 검색할 위치가 하나뿐이기 때문에 리소스를 더 쉽게 찾을 수 있습니다.
- @-mentions은(는) 같은 조직의 구성원 간에만 작동하므로, 조직이 하나일 때 소통하기가 더 쉽습니다.
- 누구나 액세스할 수 있는 하나의 대규모 조직에 속하면 협업과 충성도가 높아지지만, 소규모 조직으로 나누면 팀이 더욱 고립될 수 있습니다.
조직 소유자는 항상 조직 소유의 모든 리포지토리에 액세스할 수 있습니다. 하나의 소유자로는 모든 리포지토리에 액세스할 수 없을 정도로 회사가 큰 경우에는 여러 조직을 만드는 것이 좋습니다.
여러 조직을 만들 때 기본적인 혜택은 각각 별도의 정책, 설정, 요구 사항을 구성할 수 있다는 것입니다. 예를 들어 각 조직의 SAML 구성을 다르게 할 수 있습니다.
조직과 회사의 구조 체제 (예: 개별 팀 또는 사업부) 간에 일 대 일 관계를 만들지 마세요. 그러는 대신 정책, 설정, 요구 사항을 하나의 조직으로 공유할 수 있는 구조 체제를 그룹으로 묶으세요. 이렇게 하면 규정 요구 사항을 충족하는 과정에서 협업을 극대화할 수 있습니다.
언제나 조직을 없애기보다는 추가하기가 더 쉬우므로, 적은 수의 조직으로 시작하는 것이 좋습니다. 그러면 이후 유연성이 더 많아집니다. 비즈니스에 적합한 환경을 더 개발한 이후 필요하다면 조직을 추가로 만들 수 있습니다.
조직을 없애기란 훨씬 더 어렵고, 마이그레이션이 필요할 때도 많으며 팀에서 적응했던 유연성을 줄여야 합니다. 수를 줄이느라 까다롭고 시간이 많이 걸리는 과정을 겪은 후, 조직을 많이 만든 것을 후회하는 고객이 많습니다.
엔터프라이즈에 새 조직을 만드는 데 고정적이고 투명한 규칙을 만들어 시행하는 것이 좋습니다. 그러면 모든 사용자가 각 조직의 목적과 자산의 위치를 더 쉽게 이해할 수 있습니다.
조직 구조 정보
조직 구조에는 기본적인 5가지 원형이 있습니다. 다음 두 가지 결정으로 원형이 정해집니다.
- 하나의 조직, 또는 여러 개의 조직을 사용할지 여부
- 모든 구성원에게 모든 리포지토리에 액세스할 권한을 부여할지, 또는 팀을 사용하여 리포지토리 액세스를 더 세분화하여 관리할지 여부
팀에 대한 자세한 내용은 "팀 정보"을 참조하세요.
직접적인 리포지토리 액세스 권한이 있는 하나의 조직
가장 간단한 조직 구조는 조직 구성원 자격을 통해 구성원에게 모든 리포지토리에 액세스할 권한을 직접 부여하는 하나의 조직입니다. 조정하고 소통하는 데 Teams를 이용할 수 있지만 해당 앱을 리포지토리 액세스 관리에 사용할 수 없습니다.
이 구조는 모든 사람이 모든 일에 협업하는 신생 기업과 같은 중소기업에 가장 적합합니다. 신뢰도가 높다면 중간 규모 기업에도 적합할 수 있습니다.
이 원형을 사용하려면 조직 기본 권한을 "쓰기" 또는 "읽기"로 설정하세요. 자세한 내용은 "조직에 대한 기본 권한 설정"을(를) 참조하세요.
리포지토리 액세스 권한에 팀을 적용한 하나의 조직
회사에서 리포지토리 액세스를 더 세밀하게 제어해야 하는 경우, 조직 기본 권한을 "없음"으로 설정한 다음 각 팀에게 특정 리포지토리에 액세스할 권한만을 부여할 수 있습니다.
이 구조는 중간 규모의 회사나 신뢰도가 낮은 중소기업에 가장 적합합니다. 모든 사람이 모든 일에 협력하며 신뢰도가 높은 소규모 회사일 경우 팀을 관리하는 데 시간을 투자하는 것은 적합하지 않을 수 있습니다.
직접적인 리포지토리 액세스 권한이 있는 여러 개의 조직
대기업일 경우, 팀을 이용하더라도 하나의 조직 내에서 리포지토리 액세스를 관리하는 것은 어려울 수 있습니다. 그러는 대신 이 원형은 여러 조직을 활용하여 리포지토리 액세스를 관리합니다. 각 조직 구성원은 해당 조직의 모든 리포지토리에 액세스할 수 있습니다.
이 구조는 협력할 필요가 없는 여러 그룹을 두어도 될 만큼 큰 회사에 가장 적합합니다. 사업부 간 협업이 중요한 경우에는 이 구조가 적합하지 않습니다.
이 원형을 사용하려면 위에서 설명한 대로 정책, 설정, 요구 사항을 공유할 수 있는 각 그룹마다 하나의 조직을 만든 다음 각 조직의 기본 권한을 "쓰기" 또는 "읽기"로 설정합니다.
리포지토리 액세스 권한에 팀을 적용한 여러 개의 조직
매우 큰 회사라면 여러 조직 내에서도 리포지토리 액세스를 더 세부적으로 제어해야 할 수 있습니다. 이 경우 팀을 사용하여 각 그룹마다 특정 리포지토리에 대한 액세스 권한만을 부여할 수 있습니다.
이 원형을 사용하려면 위에서 설명한 대로 정책, 설정, 요구 사항을 공유할 수 있는 각 그룹마다 하나의 조직을 만든 다음 각 조직의 기본 권한을 "없음"으로 설정하고, 특정한 리포지토리에만 팀 액세스를 부여합니다.
여러 액세스 방법이 있는 여러 조직
직접 리포지토리 액세스가 있는 하나의 조직에서 협업할 때 누릴 수 있는 장점이 필요하지만, 리포지토리 수가 적어 전역 액세스에 너무 민감한 경우 액세스 방법을 섞어 조직을 여러 개 사용하면 좋습니다.
이 원형을 사용하려면 모든 직원과 대부분의 리포지토리에 조직 하나를 만듭니다. 이 조직의 기본 권한을 "쓰기" 또는 "읽기"로 설정하여, 이 조직의 모든 리포지토리에 액세스할 권한을 모든 구성원에게 부여합니다.
그런 다음 더 중요한 리포지토리에 특정한 두 번째 조직을 만듭니다. 이 조직에서는 기본 권한을 "없음"으로 설정하고, 중요한 리포지토리에 액세스해야 하는 사용자만 추가한 후 팀 구성원 자격을 통해 리포지토리 액세스를 관리합니다.
추가 참고 자료
- GitHub 블로그에서 임시 팀으로 전문가 구성
- "조직에 대한 모범 사례"