Antigravity Agent
6.8 KiB
6.8 KiB
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 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| productivity-knowledge-sharing | Knowledge Sharing — wiki / RFC / brown bag / pairing | Coding | draft | B | conceptual | 2026-05-09 | 2026-05-09 |
|
|
|
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)
# 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
# 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
## 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 항상 측정.