[G1-Sync] Manual knowledge update
This commit is contained in:
@@ -0,0 +1,36 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-COMM-001
|
||||
category: "10_Wiki/💡 Topics/Communication & Tech"
|
||||
confidence_score: 0.95
|
||||
tags: [communication, code-review, feedback, constructive-feedback, psychological-safety, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Effective Code Review Feedback]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드를 비판하되 작성자를 존중하며, 감정적 마찰을 줄이고 기술적 합의를 가속화하기 위해 구조화된 메시지(OIR)와 표준화된 라벨(Conventional Comments)을 활용하는 지능적 소통 전략."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
효과적인 피드백은 코드 품질 향상과 팀의 성장을 동시에 이끄는 핵심 동력입니다.
|
||||
|
||||
1. **건설적 피드백의 원칙**:
|
||||
* **코드 중심**: 사람이 아닌 '코드'의 논리와 구조에 집중합니다. "네 코드는 틀렸다" 대신 "이 로직은 엣지 케이스에서 오류를 낼 수 있다"고 표현합니다.
|
||||
* **I-Message & 질문**: "나"를 주어로 삼아 의견을 전달하고, 단정적 지시보다 "이 방법은 어떨까요?"라는 질문으로 작성자의 사고를 자극합니다.
|
||||
* **OIR 룰 (Observation, Impact, Request)**: 객관적 관찰, 그것이 미치는 영향, 그리고 구체적인 개선 요청으로 피드백을 구조화합니다.
|
||||
2. **[[Development Communication Standards (Conventional Commits & Comments)]]**:
|
||||
* `suggestion:`, `issue:`, `nit:` 등의 라벨과 `(blocking)`, `(non-blocking)` 데코레이터를 사용하여 피드백의 의도와 수정 필수 여부를 투명하게 전달합니다.
|
||||
3. **심리적 안전감 (Psychological Safety)**:
|
||||
* 칭찬(Praise)을 아끼지 않으며, 리뷰 과정을 '게이트키핑'이 아닌 '공동 학습'의 장으로 인식하는 문화를 구축합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **친절함 vs 명확성**: 감정 상함을 우려해 완곡하게 표현하다 보면 문제의 심각성이 희석될 수 있습니다. 중대한 결함은 정중하되 타협 없이 명확하게 지적하는 정책이 필요합니다.
|
||||
- **운영 오버헤드**: 모든 코멘트를 정교하게 작성하는 것은 리뷰어의 시간을 많이 소모합니다. 사소한 스타일 지적은 자동화 도구에 맡기고, 인간은 복잡한 맥락이 필요한 피드백에만 정성을 들이는 '선택과 집중'이 중요합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Development Communication Standards (Conventional Commits & Comments)]]: 피드백의 물리적 포맷팅.
|
||||
- [[Non-violent Communication]]: 커뮤니케이션의 철학적 기반.
|
||||
- [[Knowledge Management in Engineering]]: 피드백을 통한 지식 전파.
|
||||
- [[Psychological Safety]]: 건강한 리뷰 문화의 토대.
|
||||
- [[OIR 룰 (Observation, Impact, Request)]]: 피드백 작성 프레임워크.
|
||||
---
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-COMM-003
|
||||
category: "10_Wiki/💡 Topics/Communication & Tech"
|
||||
confidence_score: 0.95
|
||||
tags: [communication, knowledge-management, knowledge-sharing, engineering-culture, mentoring, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Knowledge Management in Engineering]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드 리뷰를 단순한 버그 탐지를 넘어 팀의 암묵지를 형식지로 전환하고, 지식 사일로를 타파하여 조직 전체의 기술적 탄력성(Resilience)을 강화하는 지식 전파의 엔진."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
엔지니어링 조직에서 지식은 공유될 때 비로소 가치가 증폭되며 시스템의 유지보수성을 보장합니다.
|
||||
|
||||
1. **지식 사일로(Knowledge Silos) 방지**:
|
||||
* 특정 개인에게만 지식이 집중되는 '버스 지수(Bus Factor)' 리스크를 줄이기 위해, 다양한 배경의 팀원을 리뷰어에 포함시켜 도메인 지식을 확산합니다.
|
||||
2. **멘토링과 상호 학습**:
|
||||
* 시니어의 아키텍처 철학 전수와 주니어의 신선한 시각이 교차하는 지점입니다. 질문과 제안을 통해 팀의 코딩 표준과 베스트 프랙티스를 상향 평준화합니다.
|
||||
3. **히스토리 자산화 (Living Documentation)**:
|
||||
* PR 스레드에 남겨진 설계 결정 배경과 논의 과정은 미래의 개발자가 코드가 '왜(Why)' 그렇게 작성되었는지 이해하게 돕는 영구적인 지식 기반이 됩니다.
|
||||
4. **다양한 관점의 융합**:
|
||||
* 작성자가 빠지기 쉬운 '전문가의 맹점(Expert blind spot)'을 타인의 시각으로 보완하여 더 혁신적이고 견고한 해결책을 도출합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **방관자 효과 (Bystander Apathy)**: 지식 공유를 위해 너무 많은 리뷰어를 지정하면 책임감이 분산되어 오히려 리뷰 품질이 떨어지고 알림 피로가 발생합니다. 핵심 리뷰어와 참관 리뷰어의 역할을 명확히 하는 정책이 필요합니다.
|
||||
- **속도 vs 교육**: 모든 리뷰에서 심층적인 멘토링을 시도하면 배포 속도가 저하됩니다. 변경 사항의 리스크와 복잡도에 따라 리뷰의 깊이와 교육적 비중을 조절하는 유연한 운영이 필수적입니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Effective Code Review Feedback]]: 지식 전파의 구체적 소통 수단.
|
||||
- [[Psychological Safety]]: 솔직한 질문과 지식 공유가 가능한 문화적 토대.
|
||||
- [[Pair Programming]]: 가장 높은 밀도의 실시간 지식 동기화 기법.
|
||||
- [[Code Review Checklist]]: 팀의 암묵지를 명시적 표준으로 변환한 도구.
|
||||
- [[Technical Debt]]: 지식 공유 부재 시 발생하는 장기적 비용.
|
||||
---
|
||||
Reference in New Issue
Block a user