2nd/10_Wiki/Topic_Programming/Coding/Quality_Code_Ownership_CODEOWNERS.md

id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases

id	title	category	status	source_trust_level	verification_status	created_at	updated_at	tags	tech_stack	applied_in	aliases
quality-code-ownership-codeowners	Code Ownership — CODEOWNERS / reviewer rotation	Coding	draft	B	conceptual	2026-05-09	2026-05-09	quality ownership vibe-coding	language applicable_to process Engineering		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.

# .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

## 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