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