방식 B - Organization

개념: 조직을 만들고 그 안에 저장소를 생성한다

Organization은 GitHub에서 제공하는 조직 계정입니다. 개인 계정과 별도로 존재하며, 여러 사람이 함께 소유하고 관리할 수 있습니다. Organization은 저장소와 팀, 권한을 담는 공동 작업용 공간에 가깝습니다.

Organization을 만든 사람은 자동으로 Owner 권한을 갖습니다. 개인 저장소에서는 Owner가 저장소를 만든 한 명으로 고정되지만, Organization에서는 Owner 역할을 여러 명에게 부여할 수 있어 소유권이 특정 한 사람에게 묶이지 않습니다.

  
    
  
  
    
  

GitHub Organization: "awesome-team"
  ├── 저장소 1: awesome-team/frontend
  ├── 저장소 2: awesome-team/backend
  ├── 저장소 3: awesome-team/docs
  │
  ├── Team: frontend-devs (저장소 1에 write 권한)
  ├── Team: backend-devs  (저장소 2에 write 권한)
  └── Team: everyone      (모든 저장소에 read 권한)

저장소가 특정 개인이 아닌 조직에 귀속되므로, 팀원이 바뀌어도 저장소 소유권에는 영향이 없습니다.

권한 구조: Owner / Member (역할)과 Team (구성원 그룹)

Team은 구성원을 그룹으로 묶는 단위입니다. Team별로 저장소에 대한 권한을 다르게 부여할 수 있습니다.

먼저 Team에 권한을 부여해서 기본 협업 구조를 만들 수 있습니다. 예를 들어 frontend-devs 팀에는 Write, everyone 팀에는 Read를 줄 수 있습니다.

필요하다면 특정 멤버 한 명에게만 예외적으로 더 높은 권한을 직접 부여할 수도 있습니다. 예를 들어 팀 전체는 Read인데, 그중 한 명만 해당 저장소에서 Write를 갖게 하는 식입니다.

장점

• 저장소가 조직에 귀속 - 특정 개인의 계정이 아닌 Organization에 저장소가 속하므로, 팀원 변동에 영향을 받지 않습니다.
• 세밀한 권한 관리 - Team 단위로 저장소별 권한을 다르게 설정할 수 있습니다.
• 여러 저장소 통합 관리 - Organization 안에서 여러 저장소를 한 곳에서 관리할 수 있습니다.
• 프로젝트 보드, 토론 등 부가 기능 - Organization 수준의 프로젝트 관리 도구를 활용할 수 있습니다.

단점

• 초기 설정 비용 - Organization 생성, Team 구성, 권한 설정 등 시작 전 해야 할 작업이 많습니다.
• 무료 플랜의 제약 - 무료 플랜에서는 public 저장소라면 기본적인 브랜치 보호 규칙을 사용할 수 있습니다. 하지만 private 저장소에서 같은 수준의 보호 규칙을 적용하려면 유료 플랜이 필요할 수 있습니다.
• 소규모 팀에는 다소 부담될 수 있음 - 2~4명이 하나의 저장소에서 작업하는 경우에는, Organization을 따로 만들었을 때 설정과 관리에 드는 노력에 비해 얻는 이점이 크지 않을 수 있습니다.

적합한 상황

• 프로젝트를 계속 유지하거나 확장할 계획이 있는 경우 - 이후 기능 추가나 팀 확장을 고려하는 경우
• 다수 저장소 - frontend, backend, docs 등 여러 저장소가 필요한 경우
• 역할이 나뉘는 팀 - frontend, backend, 디자인 등 역할별로 작업 범위가 구분되는 경우
• 같은 저장소를 유지하면서 팀원이 자주 바뀌는 경우 - 저장소 소유권이 조직에 있어 관리가 안정적

---

정리 - Organization은 조직 단위의 저장소 소유권과 Team 기반 세밀한 권한 관리가 장점이지만, 소규모 팀에는 설정 비용 대비 이점이 적을 수 있습니다.

다음 세션에서 두 방식을 나란히 비교하고, 어떤 상황에서 어떤 방식을 선택해야 하는지 정리합니다.