---
id: productivity-knowledge-sharing
title: Knowledge Sharing — wiki / RFC / brown bag / pairing
category: Coding
status: draft
source_trust_level: B
verification_status: conceptual
created_at: 2026-05-09
updated_at: 2026-05-09
tags: [productivity, knowledge, vibe-coding]
tech_stack: { language: "process", applicable_to: ["Engineering"] }
applied_in: []
aliases: [knowledge sharing, RFC, brown bag, lunch and learn, mob programming, internal blog]
---

# Knowledge Sharing

> 한 사람의 머리 = bus factor 1. **Wiki, RFC, brown bag, pair, mob, doc-as-code**. LLM 가 individual onboarding 의 속도 ↑ — 하지만 institutional knowledge 는 여전히 사람.

## 📖 핵심 개념
- Bus factor: 핵심 정보 가 한 사람만 알 = 위험.
- Tacit vs explicit: 머리 vs 문서.
- Push (publish) vs Pull (search).
- Decay: 안 쓰면 stale.

## 💻 코드 패턴

### 채널 종류
```
- Synchronous: meeting, call, pair
- Async: doc, RFC, comment, PR
- Push: announcement, brown bag
- Pull: wiki, search, RAG

→ Async + pull 가 scale.
```

### RFC (Request for Comments)
```markdown
# RFC-042: Migrate to Postgres pgvector

Author: @alice
Status: Draft / Review / Accepted / Rejected
Date: 2026-05-09
Reviewers: @bob, @carol

## Summary
1-2 sentences.

## Motivation
왜 이 변경 — pain, opportunity.

## Proposal
Detail of the design.

## Alternatives considered
1. ...
2. ...

## Risks / unknowns
- ...
- ...

## Migration / rollout
1. Phase 1
2. Phase 2

## Open questions
- ?
```

→ 결정 이전. 큰 변경 = RFC. ADR 가 결정 후.

### RFC vs ADR
```
RFC: "어떻게 할까" (open)
ADR: "X 했음" (closed)

RFC → 합의 → ADR + 구현.
```

### Brown bag / lunch & learn
```
주 / 격주 1회.
- 30 min 발표
- 점심 / 저녁 식사
- 기록 (slide / video)
- 제목: "X 의 inside", "Y 가 어떻게 동작"

기여:
- 내가 한 신기한 것
- 외부 conference 후기
- 새 도구 / 기술
```

### Pair programming
```
- Driver / Navigator
- 30 min - 90 min
- 새 가능 / 어려움 / 학습 OK
- 둘 다 머리 → bus factor ↑

도구: Tuple / VS Code Live Share / tmate.
```

### Mob programming
```
3+ 사람 한 화면.
- Driver 가 키보드, 나머지 navigate
- 5-10 min 마다 rotate
- 어려운 / 새 task 에 좋음

함정: 4명 = scalability 없음 (사람 수 만큼 시간 비용).
```

### Code review = 학습
```
Reviewer 도 배움.
- "왜 이 패턴?" 질문
- "다른 곳에 X 가 비슷한데" 연결
- 안 hot fix → 의도 가르치기

PR description 가 long-form context = doc.
```

### Internal blog / engineering blog
```
Public 보다 internal 만.
- 큰 architecture 결정
- Incident postmortem (sanitized)
- Migration 기록
- "I learned X this week"

→ 검색 가능 + tag.
```

### Onboarding doc
```markdown
# Engineering Onboarding

## Day 1
- 계정 / access
- 환경 setup
- 첫 PR (typo)

## Week 1
- 작은 feature task
- 1:1 with manager / TL
- Read top 5 ADR / RFC

## Month 1
- 큰 task ownership
- Brown bag 에 1회
- 새 사람 onboard 에 buddy
```

→ Buddy 가 물음표 1순위.

### Buddy system
```
새 사람 = buddy 1명 배정.
- 첫 2 주 매일 30 min 1:1
- "헛질문 OK"
- 코드 첫 PR review

→ Onboarding 기간 ↓ + 사회화.
```

### Documentation 다음 levels
```
Level 1: code + comment
Level 2: README per repo
Level 3: ADR / RFC
Level 4: Architecture overview
Level 5: System diagram + on-call playbook
Level 6: Public engineering blog
```

→ 작은 → 큰. Level 3 까지가 baseline.

### Wiki vs Notion vs git
```
Wiki (Confluence): WYSIWYG, 비engineer 친화
Notion: 모던, DB 기능
Git markdown: docs-as-code, version, review

→ 한 곳만. 둘 = drift.
Engineering 가 큰 = git.
Mixed team = Notion.
```

### Knowledge graph (LLM-friendly)
```
Wiki + tag + link → graph.
LLM RAG 가 question → 관련 doc 5 개 retrieve.

도구:
- Notion AI
- ChatGPT 가 enterprise
- Self-host: chatGPT + embeddings
```

→ "X 는 어떻게?" → instant answer.

### Tacit → explicit
```
"내가 매번 X 하는데" = doc.
"또 같은 질문" = FAQ.
"Slack 에서 검색" = doc 안 됨.

→ 매번 hot question → 한 번 doc 으로.
```

### DevRel / community engineer
```
큰 팀 (>50) = dedicated:
- Doc 가독성 / 일관성
- Onboarding 체계
- Brown bag 일정
- Engineering blog

→ Productivity 의 multiplier.
```

### Slack / Discord 검색
```
Channel 정리:
- #general — 사람
- #engineering — tech 토의
- #incidents — incident 만
- #help-{repo} — 질문
- #adrs — ADR 알림

→ 검색 가능 + bot index.
```

→ Slack 의 message 가 "doc" 의 절반. Search 친화 정리.

### Decision log
```markdown
## 2026-05-09 — DB 선정
- Postgres pgvector 결정
- Reasoning: ...
- Alternatives considered: Pinecone, Qdrant
- Owner: @alice
- ADR: 0042
```

→ 작은 결정 의 trail. 큰 결정 = ADR.

### Stale doc detection
```
- 6 month+ 안 변경 = review tag
- Code 가 변경 + doc 안 = PR comment
- 매년 doc audit (1 day)

자동:
- Linkrot bot (broken link)
- Outdated tag (last update > N month)
```

### LLM 활용
```
- README 자동 생성 (코드 → text)
- ADR 의 context 자동 (PR 변경 → why)
- Onboarding bot (RAG)
- Code → architecture diagram

→ LLM 가 explicit 의 가속기. Tacit → explicit 도 도움.
```

### "Don't repeat yourself" (knowledge)
```
같은 정보 두 곳 = drift.
- Schema in DB + duplicate in doc → schema.json 자동
- API + duplicate doc → OpenAPI spec
- README setup + Dockerfile → 실제 Dockerfile + link

→ Source of truth 1.
```

### Engineering Manager / TL 역할
```
- 1:1 weekly
- Knowledge gap 식별
- Pair / mob 권장
- Brown bag schedule
- Onboarding owner
- ADR / RFC review

→ Knowledge sharing 가 EM job.
```

### Bus factor 측정
```
"X 가 사라지면 Y 못함" 표:

| 영역 | bus factor |
|---|---|
| Auth system | 1 (Alice 만 알아) — RISK |
| Search | 3 (well shared) |
| Payment | 2 |
| Frontend | 4 |

→ bus factor 1 = pair / mob / doc.
```

## 🤔 의사결정 기준
| 상황 | 추천 |
|---|---|
| 큰 결정 | RFC → ADR |
| 새 사람 | Onboarding + buddy |
| 어려운 task | Pair / mob |
| Repeat 질문 | FAQ / wiki |
| Architecture | System diagram + ADR |
| Hot tip | Brown bag |
| Process | Wiki |
| Code | Comment + README |

## ❌ 안티패턴
- **Knowledge in head**: bus factor 1.
- **Doc 없이 회의**: 회의 끝 = 잃음.
- **Wiki + git + notion 모두 일부**: drift.
- **Stale doc**: 잘못된 정보 > 없음.
- **Onboarding 없음**: 새 사람 헛수고.
- **No code review**: 한 사람 만 알아.
- **"Search Slack"**: 검색 안 됨.

## 🤖 LLM 활용 힌트
- RFC + ADR + onboarding 3 종 baseline.
- Pair / mob 가 tacit 이전.
- LLM RAG 가 explicit 의 multiplier.
- Bus factor 항상 측정.

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