---
id: quality-code-ownership-codeowners
title: Code Ownership — CODEOWNERS / reviewer rotation
category: Coding
status: draft
source_trust_level: B
verification_status: conceptual
created_at: 2026-05-09
updated_at: 2026-05-09
tags: [quality, ownership, vibe-coding]
tech_stack: { language: "process", applicable_to: ["Engineering"] }
applied_in: []
aliases: [CODEOWNERS, code ownership, reviewer rotation, area expert, no owner]
---

# Code Ownership

> "이 file 가 변경 시 누가 review?". **CODEOWNERS file + 자동 reviewer assign**. Bus factor + accountability.

## 📖 핵심 개념
- 매 file 의 owner (team or person).
- PR 가 자동 review request.
- Bus factor 가 명확.
- "Orphan" code 가 없어야.

## 💻 코드 패턴

### CODEOWNERS (GitHub / GitLab)
```
# .github/CODEOWNERS

# 모든 file
*                              @org/all-engineers

# Frontend
/src/frontend/**               @org/frontend-team
/src/components/**             @alice @bob

# Backend
/src/backend/**                @org/backend-team
/src/backend/payment/**        @org/payment-team

# Infrastructure
/terraform/**                  @org/devops
/.github/**                    @org/devops

# Docs
/docs/**                       @org/tech-writers

# Specific file
/CRITICAL.md                   @ceo
```

→ 매 PR 가 path 따라 reviewer 자동.

### GitHub branch protection
```
Settings → Branches → Branch protection rule:
- Require pull request reviews.
- Require review from code owners.
- Dismiss stale reviews.
- Require status checks.
```

→ Owner approval 없이 merge X.

### File 의 owner 가 우선
```
*                  @general
/src/api/**        @api-team
/src/api/auth.ts   @security-team
```

→ `auth.ts` = security-team only.
Most specific 가 win.

### Team vs individual
```
Team:
✓ Bus factor.
✓ Vacation OK.
✓ Round-robin review.
✗ Less personal.

Individual:
✓ Direct accountability.
✗ Bottleneck (vacation, sick).

→ Team 가 default. Specific (architect) 가 individual.
```

### Auto-merge
```
- 매 owner 가 approve.
- All checks pass.
- Auto-merge enabled.

→ Self-service deploy.
```

### Reviewer rotation (round-robin)
```
GitHub: team review request 가 1 member 만.
- Team 의 setting: round-robin / load balance.
```

```yaml
# .github/team-reviewers.yml
team-reviewers:
  team-name:
    rotation: round-robin
    avoid:
      - on-vacation
```

### Required reviewer
```
Specific path 의 specific reviewer:
/security/**     @ciso
/billing/**      @cfo
```

→ Compliance / legal.

### Tech debt 의 ownership
```
"이 file 가 누구도 안 알아" = orphan.
→ Bug fix / refactor 가 어려움.
→ Bus factor 1.

해결:
- 매 file 가 owner (CODEOWNERS).
- Quarterly audit (orphan detect).
- Pair / mob 가 knowledge transfer.
```

### Inverse: too many owner
```
*    @all-engineers
```

→ "모든 사람 가 review" = 아무도.

→ Specific path 별 owner 가 좋음.

### Module ownership
```
Module = team 의 area:
- Auth → Security team.
- Search → Search team.
- Billing → Payments team.

매 team 가 own roadmap + on-call.
```

### Ownership doc
```markdown
## Module: Search

Owner: @search-team
Tech lead: @alice
Slack: #search

## Responsibility
- Search relevance.
- Index pipeline.
- Search UI.

## Architecture
[link to ADR]

## Runbook
[link]
```

→ 매 module 의 README 식.

### Reviewer guideline
```
@org/code-reviews 의 wiki:

When to approve:
- 의도 가 clear.
- Test 가 적절.
- Edge case 다.
- 성능 / security OK.

When to request changes:
- Logic bug.
- Style 가 inconsistent.
- Test 부족.
- Doc 안 update.

When NOT block:
- Opinion (변경 가 같은 정도).
- Out of scope.
- Future improvement (별 PR).
```

### Big org / multi-repo
```
GitHub 가 monorepo CODEOWNERS 가 자동.
Multi-repo:
- 매 repo 의 자체 CODEOWNERS.
- Centralized doc 가 매 repo → owner.
- Cross-repo dependency 가 explicit.
```

### Approval matrix
```
PR size:
- < 100 LOC: 1 approver.
- 100-1000: 2 approver.
- 1000+: tech lead + team.

Critical change:
- DB migration: DBA + on-call.
- Security: security team.
- Public API: API team + technical writer.
```

### Code freeze (예외)
```
Production freeze:
- Owner approval + CTO override.
- Audit log.

→ Critical bug 가 fix 만.
```

### Dependency freeze
```
package.json:
- Specific dep 가 owner.
- Version bump = owner approve.

CODEOWNERS:
/package.json  @platform-team
```

### Onboarding 의 ownership
```
새 사람 = team 가 임시 owner.
점진:
- Pair on PR.
- Solo PR (review).
- Become co-owner (3-6 month).
```

### Ownership 의 transfer
```
Engineer leave:
- 1 month 전 announce.
- Pair on critical area.
- Transfer ownership in CODEOWNERS.
- Knowledge dump (Loom video, ADR).
```

### Audit
```
Quarterly:
- Orphan file (no owner).
- Single-owner file (bus factor 1).
- Stale owner (left company).

→ Update CODEOWNERS.
```

### CODEOWNERS의 함정
```
- 매 file 가 wildcard owner: 의미 X.
- Owner 가 left: PR stuck.
- Manual update 만: drift.
- No protection: review skip 가능.
- Round-robin 없음: 1 사람 burnout.
```

### 함정: Strict ownership
```
"Code 가 mine" 식 = silo.
- 다른 team 가 못 변경.
- Refactor 가 어려움.

→ Ownership = responsibility, not permission.
다른 team 도 PR OK (owner approve).
```

### Open vs closed source 의 ownership
```
Open source:
- Maintainer (hierarchy).
- 매 PR 가 review.
- BDFL 또는 committee.

Internal:
- Team / module.
- 자체 process.
```

### Tools
```
- GitHub CODEOWNERS (native).
- GitLab CODEOWNERS.
- Bitbucket reviewers.
- Reviewable / Pull Reviewers (3rd party).
- Sourcegraph (code intelligence).
```

### Sourcegraph (code intelligence)
```
"이 function 가 누가 작성?".
"매 file 의 last commit 가 누구?".

→ Auto-suggest owner.
```

→ Big codebase 친화.

## 🤔 의사결정 기준
| 작업 | 추천 |
|---|---|
| Module owner | Team (round-robin) |
| Critical path | Team + on-call |
| Specific architect | Individual |
| Open source | Maintainer hierarchy |
| 작은 팀 | Skip (모두 review) |
| 큰 팀 | CODEOWNERS strict |

## ❌ 안티패턴
- **No CODEOWNERS**: bus factor 1.
- **모두 wildcard**: 의미 X.
- **Strict ownership = silo**: refactor 어려움.
- **Owner 가 leave + 안 transfer**: stuck.
- **Round-robin 없음**: 1 사람 burnout.
- **No audit**: drift.

## 🤖 LLM 활용 힌트
- CODEOWNERS file 가 source of truth.
- Team > individual (bus factor).
- Branch protection + required review.
- Quarterly audit 가 orphan detect.

## 🔗 관련 문서
- [[Productivity_Code_Review]]
- [[Productivity_Knowledge_Sharing]]
- [[Quality_Mentoring]]