포스트

[GitHub 100일 챌린지] Day 79 - GitHub 팀 협업 워크플로우

게시
Day 79 - 팀 협업
Day 79 - 팀 협업
By YonYonWare
25 분읽는 시간
[GitHub 100일 챌린지] Day 79 - GitHub 팀 협업 워크플로우

100일 챌린지 Day 79 - Organization과 Team 구조로 체계적인 팀 협업 워크플로우를 구축합니다.

⏱️ 예상 학습 시간: 50분 📚 난이도: ⭐⭐⭐⭐ (고급)

배울 내용

  1. Organization과 Team 구조 이해하기
  2. 권한 관리 시스템 (Read, Triage, Write, Maintain, Admin)
  3. CODEOWNERS로 코드 책임 명확화하기
  4. 브랜치 보호 규칙 상세 설정
  5. 팀 협업 워크플로우 설계
  6. 알림과 커뮤니케이션 관리

시작하기 전에

이 내용은 다음 개념을 알고 있다면 더 쉽게 이해할 수 있습니다:

  • ✅ [Day 71-78 - Issues, Projects, Discussions 사용 경험]
  • ✅ Pull Request 워크플로우 이해
  • ✅ 팀 프로젝트 경험 (학교, 회사 등)
  • ✅ Git 브랜치 전략 기본 이해

Organization은 개인 계정의 확장입니다. 팀 프로젝트를 해봤다면 왜 필요한지 금방 이해할 수 있어요!

1. Organization과 Team 구조

Organization이란?

정의: 여러 저장소와 팀을 관리하는 최상위 단위

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

개인 계정:
user/
├─ repo1
├─ repo2
└─ repo3

Organization:
company/
├─ Teams
│  ├─ Frontend Team
│  ├─ Backend Team
│  └─ DevOps Team
└─ Repositories
   ├─ web-app
   ├─ api-server
   └─ mobile-app

Organization 생성하기

1
2
3
4
5
6
7
8
9
10
11
12
13

1. GitHub 우측 상단 프로필 → Your organizations
2. New organization
3. Plan 선택:
   - Free: Public 저장소 무제한
   - Team: $4/user/month
   - Enterprise: 고급 기능

4. 정보 입력:
   - Organization name: mycompany
   - Contact email: admin@mycompany.com
   - This organization belongs to: My personal account / A business

5. 멤버 초대

Team 구조 설계

기본 구조:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Organization: TechCorp
├─ Engineering
│  ├─ Frontend Team
│  │  ├─ React Team
│  │  └─ Vue Team
│  ├─ Backend Team
│  │  ├─ API Team
│  │  └─ Database Team
│  └─ Mobile Team
│     ├─ iOS Team
│     └─ Android Team
├─ Design Team
├─ Product Team
└─ DevOps Team

Team 생성:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Organization → Teams → New team

Team 정보:
이름: Frontend Team
설명: Frontend development team
Parent team: Engineering (선택 사항)
Visibility:
  ○ Visible (모두 볼 수 있음)
  ● Secret (멤버만 볼 수 있음)

멤버 추가:
- @alice (Maintainer)
- @bob (Member)
- @charlie (Member)

중첩 Team (Parent/Child)

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Engineering (부모 팀)
├─ Frontend Team (자식 팀)
│  - 부모 권한 상속
│  - 추가 저장소 접근 가능
└─ Backend Team (자식 팀)

설정:
Frontend Team → Settings → Parent team
→ Engineering 선택

효과:
- Engineering의 권한 자동 상속
- @engineering/frontend 형식으로 멘션
- 계층적 조직 구조

2. 권한 관리 시스템

권한 레벨

레벨 권한 적합한 역할
Read 저장소 보기, Issue 생성 외부 기여자, 인턴
Triage Issue/PR 관리, 라벨 편집 Support 팀, PM
Write 코드 푸시, PR 생성 개발자
Maintain 저장소 설정 일부 관리 팀 리더, Tech Lead
Admin 모든 권한, 멤버 관리 CTO, Engineering Manager

세부 권한표

Read:

1
2
3
4
5
6
7

✅ 저장소 복제 및 pull
✅ Issue 생성 및 댓글
✅ PR 댓글
✅ Discussion 참여
❌ 푸시
❌ PR 생성
❌ 설정 변경

Triage:

1
2
3
4
5
6
7
8

Read 권한 +
✅ Issue/PR 닫기
✅ 라벨 추가/제거
✅ 담당자 할당
✅ 마일스톤 설정
✅ Issue 고정/잠금
❌ 푸시
❌ PR 병합

Write:

1
2
3
4
5
6
7

Triage 권한 +
✅ 브랜치 푸시
✅ PR 생성
✅ PR 리뷰
✅ Wiki 편집
❌ PR 병합 (보호된 브랜치)
❌ 저장소 설정

Maintain:

1
2
3
4
5
6
7
8

Write 권한 +
✅ PR 병합
✅ 릴리스 관리
✅ 브랜치 관리
✅ GitHub Pages 설정
✅ Webhooks 관리
❌ 멤버 관리
❌ 저장소 삭제

Admin:

1
2
3
4
5
6

Maintain 권한 +
✅ 멤버 권한 변경
✅ 모든 설정 변경
✅ 저장소 삭제
✅ 보안 설정
✅ Secrets 관리

팀 권한 설정

저장소에 팀 추가:

1
2
3
4
5
6
7
8
9

Repository → Settings → Collaborators and teams
→ Add teams

예시:
- Frontend Team: Write
- Backend Team: Write
- DevOps Team: Maintain
- Design Team: Read
- QA Team: Triage

실전 예시:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

web-app 저장소:
┌────────────────┬──────────┐
│ Team           │ 권한     │
├────────────────┼──────────┤
│ Frontend Team  │ Maintain │
│ Backend Team   │ Write    │
│ DevOps Team    │ Admin    │
│ Design Team    │ Read     │
│ QA Team        │ Triage   │
└────────────────┴──────────┘

api-server 저장소:
┌────────────────┬──────────┐
│ Team           │ 권한     │
├────────────────┼──────────┤
│ Backend Team   │ Maintain │
│ Frontend Team  │ Write    │
│ DevOps Team    │ Admin    │
│ QA Team        │ Triage   │
└────────────────┴──────────┘

3. CODEOWNERS로 코드 책임 명확화

CODEOWNERS란?

정의: 파일이나 디렉토리의 담당자를 지정하는 기능

1
2
3
4
5

목적:
✅ 코드 소유권 명확화
✅ 자동 리뷰어 지정
✅ PR 승인 요구사항 강제
✅ 팀 책임 분산

CODEOWNERS 파일 생성

위치:

1
2
3
4
5
6

# 루트 디렉토리 (권장)
.github/CODEOWNERS

# 또는
CODEOWNERS
docs/CODEOWNERS

기본 문법

사용자 지정:

1
2
3
4
5
6
7
8
9
10
11
12
13

# 기본 소유자 (모든 파일)
* @default-owner

# 특정 파일
README.md @docs-team

# 특정 확장자
*.js @frontend-team
*.py @backend-team

# 디렉토리
/src/ @developers
/docs/ @docs-team

팀 지정:

1
2
3
4
5
6
7
8
9
10

# Organization 팀 (@org/team)
*.js @myorg/frontend-team
*.css @myorg/frontend-team

# 복수 소유자
*.ts @myorg/frontend-team @alice @bob

# 하위 디렉토리 우선
/src/components/ @myorg/react-team
/src/api/ @myorg/backend-team

실전 예시

풀스택 프로젝트:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

# .github/CODEOWNERS

# 기본 소유자
* @myorg/developers

# Frontend
/frontend/ @myorg/frontend-team
/frontend/src/components/ @myorg/react-team
*.jsx @myorg/frontend-team
*.tsx @myorg/frontend-team
*.css @myorg/frontend-team @myorg/design-team

# Backend
/backend/ @myorg/backend-team
/backend/api/ @myorg/api-team
*.py @myorg/backend-team
/backend/database/ @myorg/database-team

# Infrastructure
/infrastructure/ @myorg/devops-team
Dockerfile @myorg/devops-team
docker-compose.yml @myorg/devops-team
.github/workflows/ @myorg/devops-team

# Configuration
.env.example @myorg/devops-team @lead-developer
package.json @frontend-lead @backend-lead

# Documentation
/docs/ @myorg/docs-team
README.md @myorg/docs-team
*.md @myorg/docs-team

# Security
SECURITY.md @security-team @cto
/secrets/ @security-team

# CI/CD
.github/workflows/ @myorg/devops-team
.circleci/ @myorg/devops-team

# Tests
/tests/ @myorg/qa-team @myorg/developers

마이크로서비스 아키텍처:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# .github/CODEOWNERS

# Service ownership
/services/auth/ @myorg/auth-team
/services/payment/ @myorg/payment-team
/services/notification/ @myorg/notification-team

# Shared libraries
/lib/ @myorg/platform-team
/shared/ @myorg/platform-team

# API Gateway
/gateway/ @myorg/api-team @myorg/devops-team

# Database migrations
/migrations/ @myorg/database-team @dba

# Monitoring
/monitoring/ @myorg/sre-team

CODEOWNERS와 브랜치 보호 통합

1
2
3
4
5
6
7
8
9
10
11

Settings → Branches → Branch protection rules
→ main 브랜치

☑ Require pull request reviews before merging
  ☑ Require review from Code Owners

→ CODEOWNERS에 지정된 사람의 승인 필수!

예시:
/frontend/src/App.tsx 수정 → @myorg/frontend-team 승인 필요
/backend/api/auth.py 수정 → @myorg/backend-team 승인 필요

4. 브랜치 보호 규칙

기본 보호 규칙

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Settings → Branches → Add rule

Branch name pattern: main

기본 설정:
☑ Require a pull request before merging
  Number of required approvals: 2
  ☑ Dismiss stale pull request approvals
  ☑ Require review from Code Owners

☑ Require status checks to pass before merging
  ☑ Require branches to be up to date
  Status checks:
    - CI / build
    - CI / test
    - Lint

☑ Require conversation resolution before merging

☐ Require signed commits

☑ Include administrators

상세 설정 가이드

1. PR 승인 요구:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

☑ Require a pull request before merging

옵션:
- Required approvals: 1-6명
  ✅ 소규모 팀: 1명
  ✅ 중규모 팀: 2명
  ✅ 대규모/중요 저장소: 3명+

- Dismiss stale approvals:
  ☑ 코드 변경 시 기존 승인 무효화

- Require review from Code Owners:
  ☑ CODEOWNERS 파일 기반 승인 필수

- Restrict who can dismiss reviews:
  ☑ Admin만 리뷰 무효화 가능

2. 상태 체크 요구:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

☑ Require status checks to pass

필수 체크:
- CI/CD 빌드 성공
- 모든 테스트 통과
- Lint 통과
- 코드 커버리지 80% 이상
- 보안 스캔 통과

예시:
Status checks found:
☑ CI / build-and-test
☑ CI / lint
☑ CodeQL
☑ coverage/codecov

3. 최신 상태 요구:

1
2
3
4
5
6

☑ Require branches to be up to date

효과:
- PR 브랜치가 base 브랜치(main)보다 뒤처지면 병합 불가
- "Update branch" 버튼으로 최신화 필요
- 충돌 방지

4. 대화 해결 요구:

1
2
3
4
5
6

☑ Require conversation resolution before merging

효과:
- 모든 리뷰 코멘트 해결 필수
- "Resolve conversation" 버튼 클릭 필요
- 미해결 코멘트 있으면 병합 불가

5. 푸시 제한:

1
2
3
4
5
6
7

☑ Restrict who can push to matching branches

허용 대상:
- 특정 팀만
- 예: DevOps Team, Release Team

→ 다른 사람은 PR을 통해서만 변경 가능

6. Force Push 금지:

1
2
3
4

☑ Do not allow force pushes

→ git push --force 금지
→ 히스토리 보호

7. 삭제 금지:

1
2
3

☑ Do not allow deletions

→ main 브랜치 삭제 방지

환경별 보호 규칙

Production (main):

1
2
3
4
5
6
7

main 브랜치:
- 승인 3명 필수
- CODEOWNERS 승인 필수
- 모든 CI 통과 필수
- 최신 상태 필수
- Signed commits 필수
- 관리자 포함

Staging (develop):

1
2
3
4
5

develop 브랜치:
- 승인 2명 필수
- CI 통과 필수
- CODEOWNERS 승인
- 최신 상태 필수

Feature 브랜치:

1
2
3
4

feature/* 브랜치:
- 승인 1명 필수
- CI 통과 필수
- 자유로운 force push 허용

5. 팀 협업 워크플로우

GitFlow 기반 워크플로우

1
2
3
4
5
6
7
8
9
10
11
12
13
14

main (production)
  ↑
develop (staging)
  ↑
feature/* (개발)


워크플로우:
1. develop에서 feature 브랜치 생성
2. 기능 개발
3. PR → develop
4. 코드 리뷰 (2명 승인)
5. CI 통과 후 병합
6. develop → main (릴리스)

실전 예시:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# 1. Feature 브랜치 생성
git checkout develop
git pull origin develop
git checkout -b feature/user-authentication

# 2. 개발
git add .
git commit -m "feat: Add user authentication"

# 3. 푸시
git push origin feature/user-authentication

# 4. PR 생성 (develop ← feature/user-authentication)
gh pr create --base develop \
  --title "Add user authentication" \
  --body "Implements JWT-based authentication"

# 5. 리뷰 대기
# - @backend-team 리뷰 요청
# - CI 통과 대기
# - 2명 승인 대기

# 6. 피드백 반영
git add .
git commit -m "fix: Address review comments"
git push origin feature/user-authentication

# 7. 승인 후 병합 (Squash and merge)

# 8. 로컬 브랜치 정리
git checkout develop
git pull origin develop
git branch -d feature/user-authentication

Trunk-Based Development

1
2
3
4
5
6
7
8
9
10

main
  ├─ feature/quick-fix
  ├─ feature/new-feature
  └─ feature/bug-fix

특징:
- main 브랜치에서 직접 분기
- 짧은 생명주기 (1-2일)
- 빠른 통합
- Feature Flag 활용

팀별 워크플로우

Frontend Team:

1
2
3
4
5
6
7
8
9

워크플로우:
1. Figma 디자인 확인
2. feature 브랜치 생성
3. 컴포넌트 개발
4. Storybook 작성
5. PR 생성 (@frontend-team 리뷰 요청)
6. 디자인 QA (@design-team 확인)
7. 승인 후 병합
8. Staging 배포 및 테스트

Backend Team:

1
2
3
4
5
6
7
8
9
10

워크플로우:
1. API 스펙 문서 작성
2. feature 브랜치 생성
3. API 구현
4. 단위 테스트 작성
5. 통합 테스트 작성
6. PR 생성 (@backend-team 리뷰 요청)
7. Code coverage 80% 이상 확인
8. 승인 후 병합
9. Swagger 문서 업데이트

DevOps Team:

1
2
3
4
5
6
7
8
9

워크플로우:
1. 인프라 변경 계획
2. feature 브랜치 생성
3. Terraform/Helm 코드 작성
4. terraform plan 확인
5. PR 생성 (@devops-team 리뷰 요청)
6. Staging 환경 테스트
7. 승인 후 병합
8. Production 배포 (릴리스 시간)

6. 알림과 커뮤니케이션

GitHub 알림 설정

개인 알림 설정:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Settings → Notifications

Watching:
- Automatically watch repositories (자동 Watch)
- Automatically watch teams (팀 Watch)

Participating:
☑ 내가 참여한 conversation
☑ @mention
☑ 할당된 Issue/PR
☑ 리뷰 요청

Subscriptions:
- Email
- Web
- Mobile (GitHub Mobile 앱)

저장소별 알림:

1
2
3
4
5
6
7
8
9
10
11

Repository → Watch 버튼

옵션:
- All activity (모든 활동)
- Ignore (알림 없음)
- Releases only (릴리스만)
- Custom:
  ☑ Issues
  ☑ Pull requests
  ☑ Releases
  ☐ Discussions

팀 멘션

1
2
3
4
5
6
7
8

@myorg/frontend-team 리뷰 부탁드립니다.
→ Frontend 팀 전체에 알림

@myorg/backend-team/api-team 의견 주세요.
→ Backend 팀의 API 팀에 알림

cc @alice @bob
→ 개별 멘션

Slack 통합

GitHub + Slack:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Slack에서:
/github subscribe owner/repo

알림 설정:
/github subscribe owner/repo reviews comments

받을 알림:
- 새 PR
- PR 승인/변경 요청
- PR 코멘트
- Issue 생성/닫힘
- Releases
- Deployments

채널별 구독:
#frontend → frontend-app 저장소
#backend → api-server 저장소
#devops → infrastructure 저장소

7. 실전 가이드

신입 개발자 온보딩

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

1. Organization 초대
   - Email 초대 발송
   - 2FA 활성화 요구

2. Team 추가
   - 적절한 팀에 배정
   - 초기 권한: Write

3. 저장소 접근 확인
   - 필요한 저장소 clone
   - SSH 키 설정

4. 첫 Issue 할당
   - label:"good-first-issue"
   - 멘토 지정

5. 첫 PR 제출
   - 상세한 리뷰 제공
   - 칭찬과 건설적 피드백

정기 팀 리뷰

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

주간 리뷰 체크리스트:

1. Open PR 현황
   - 오래된 PR 확인 (7일+)
   - 블로커 확인

2. Issue 관리
   - 우선순위 재조정
   - 마일스톤 진행률

3. Code Owner 분석
   - 과부하 팀 확인
   - 리뷰 시간 개선

4. 브랜치 정리
   - 머지된 브랜치 삭제
   - 오래된 feature 브랜치

💡 초보자 팁 Organization은 무료로 만들 수 있습니다! 혼자 연습용으로도 만들어보세요. CODEOWNERS는 처음엔 간단하게 시작하세요. 너무 세세하게 나누면 관리가 어려워요. 브랜치 보호 규칙은 필수입니다. 최소한 리뷰 1개는 꼭 요구하세요!

직접 해보기 (30-35분)

실습을 통해 배운 내용을 체화해봅시다!

📝 실습 1: Organization 만들기 (5분)

1
2
3
4

- [ ] 1. GitHub에서 새 Organization 생성
- [ ] 2. 조직 이름과 연락처 설정
- [ ] 3. 조직 프로필 페이지 확인
- [ ] 4. 연습용 리포지토리 생성

📝 실습 2: Team 구조 만들기 (10분)

1
2
3
4
5

- [ ] 1. "Backend" 팀 생성
- [ ] 2. "Frontend" 팀 생성
- [ ] 3. 각 팀에 멤버 추가 (혼자면 본인만)
- [ ] 4. 각 팀에 리포지토리 권한 할당
- [ ] 5. 팀 설명과 아이콘 설정

📝 실습 3: CODEOWNERS 파일 만들기 (10분)

1
2
3
4
5

- [ ] 1. .github/CODEOWNERS 파일 생성
- [ ] 2. 전체 코드 소유자 지정
- [ ] 3. 디렉토리별 소유자 지정 (src/, docs/ 등)
- [ ] 4. 특정 파일 소유자 지정
- [ ] 5. PR 생성하여 자동 리뷰어 추가 확인

📝 실습 4: 브랜치 보호 규칙 설정 (10분)

1
2
3
4
5

- [ ] 1. main 브랜치 보호 활성화
- [ ] 2. PR 필수로 설정
- [ ] 3. 리뷰 1개 이상 필수로 설정
- [ ] 4. Status check 추가 (CI가 있다면)
- [ ] 5. 강제 푸시 금지 설정

실습 완료 후: 이제 전문적인 팀 협업 환경을 갖추게 되었습니다!

😰 어려우시다면

이 내용이 어렵게 느껴진다면:

  1. Organization이 필요한지 모르겠는 경우
    • 혼자 프로젝트: 개인 계정으로 충분
    • 2-3명 팀: 개인 계정 + Collaborators로 시작
    • 5명 이상 or 여러 프로젝트: Organization 추천
  2. 권한 레벨이 복잡한 경우
    • 처음엔 Read와 Write만 사용하세요
    • Read: 읽기만 (외부 기여자)
    • Write: 커밋 가능 (팀 멤버)
    • 나중에 필요하면 세분화
  3. CODEOWNERS 문법이 어려운 경우
    • 간단한 패턴부터 시작 (* @username)
    • 예제를 복사해서 수정하세요
    • 너무 세세하게 나누지 마세요
  4. 브랜치 보호 규칙이 엄격해서 불편한 경우
    • 개발 중: 느슨하게 (리뷰만 필수)
    • 프로덕션: 엄격하게 (모든 체크 필수)
    • 상황에 맞게 조절하세요
  5. 팀 구조를 어떻게 나눌지 모르겠는 경우
    • 역할별: Frontend, Backend, DevOps
    • 기능별: Auth, Payment, Analytics
    • 팀 규모가 작으면 하나의 팀으로 시작
  6. 복습이 필요하다면
    • Day 71-78 복습
    • Git 브랜치 전략 학습
    • 다른 오픈소스 프로젝트의 Organization 구조 참고

꼭 기억하세요: 팀 협업 도구는 팀이 성장하면서 점진적으로 추가하세요. 처음부터 모든 규칙을 완벽하게 만들 필요 없습니다!

정리

완료 체크:

  • Organization과 Team 구조를 이해했다
  • 권한 레벨을 적절히 설정할 수 있다
  • CODEOWNERS 파일을 작성할 수 있다
  • 브랜치 보호 규칙을 설정할 수 있다
  • 팀 협업 워크플로우를 설계할 수 있다
  • 알림을 효과적으로 관리할 수 있다
  • 직접 실습을 완료했다

핵심 요약:

  • Organization: 팀과 저장소를 관리하는 최상위 단위
  • 권한: Read < Triage < Write < Maintain < Admin
  • CODEOWNERS: 파일/디렉토리 담당자 지정 및 자동 리뷰어 할당
  • 브랜치 보호: PR 승인, CI 통과, Code Owners 승인 요구
  • 워크플로우: GitFlow 또는 Trunk-Based Development
  • 커뮤니케이션: 팀 멘션, Slack 통합, 알림 설정

실전 팁:

  • ✅ 팀 구조는 실제 조직도와 동기화
  • ✅ main 브랜치는 항상 배포 가능한 상태 유지
  • ✅ CODEOWNERS로 리뷰 부담 분산
  • ✅ 브랜치 보호는 환경별로 차등 적용
  • ✅ PR 승인은 2명 이상 권장
  • ✅ CI/CD는 모든 브랜치에서 실행
  • ✅ 정기적으로 팀 권한 감사
  • ✅ Slack 통합으로 실시간 알림
  • ✅ Watch 설정을 개인별로 조정

다음: Day 80 - 코드 리뷰 문화 →

← Day 78 전체 커리큘럼 Day 80 →
GitHub100일챌린지, Phase08
github 100days day79 team collaboration
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.