[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,36 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-GOV-001
|
||||
category: "10_Wiki/💡 Topics/04_Governance_Reliability"
|
||||
confidence_score: 0.95
|
||||
tags: [governance, code-quality, code-health, simplicity, maintainability, readability, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Code Quality & Health]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드베이스의 장기적 생존성과 팀의 개발 속도를 결정하는 핵심 자산: 인지적 부하를 최소화하는 단순성(Simplicity)과 미래의 변화를 수용하는 유지보수성(Maintainability)의 조화로운 상태."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
코드 품질 관리는 단순히 버그를 찾는 것을 넘어 시스템의 '건강한 상태'를 지속적으로 유지하는 활동입니다.
|
||||
|
||||
1. **코드 단순성 (Code Simplicity)**:
|
||||
* **과도한 엔지니어링 방지**: '미래에 필요할지도 모르는 문제'가 아닌 '지금 당장 해결해야 하는 문제'에 집중합니다. 불필요한 추상화와 계층을 제거하여 직관적인 구조를 유지합니다.
|
||||
* **함수 및 로직 분해**: 중첩된 조건문이나 거대한 함수(예: 200줄 이상)를 작고 테스트 가능한 원자적 단위로 분리합니다.
|
||||
2. **가독성 및 유지보수성 (Readability & Maintainability)**:
|
||||
* **Self-documenting Code**: 장황한 주석 없이도 코드 자체로 의도가 전달되어야 합니다. 명확한 네이밍과 일관된 컨벤션이 필수적입니다.
|
||||
* **중복 제거 (DRY)**: 코드 중복을 최소화하여 수정 시 발생할 수 있는 부작용을 원천 차단합니다.
|
||||
3. **지속적인 건강 관리 (Code Health)**:
|
||||
* 리뷰의 기준은 '완벽함'이 아니라 '변경 사항이 기존보다 코드 건강을 개선했는가'가 되어야 합니다. 기술 부채가 누적되지 않도록 매 PR마다 조금씩 코드를 정제합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **추상화의 트레이드오프**: 추상화가 부족하면 중복이 발생하고, 과하면 오버엔지니어링이 됩니다. 시스템의 현재 규모와 비즈니스 복잡도에 맞는 적정 수준의 추상화 정책을 수시로 점검해야 합니다.
|
||||
- **가독성 vs 성능**: 간결하고 읽기 쉬운 코드가 때로는 마이크로 최적화 관점에서 성능을 희생할 수 있습니다. 성능이 크리티컬한 영역이 아니라면 유지보수성을 우선하는 것이 장기적으로 유리합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Single Responsibility Principle (SRP)]]: 코드를 단순하게 만드는 구조적 원칙.
|
||||
- [[Refactoring]]: 코드 건강을 회복시키는 실천적 행위.
|
||||
- [[Technical Debt]]: 코드 품질 저하 시 발생하는 잠재적 비용.
|
||||
- [[Over-engineering]]: 단순성을 해치는 가장 큰 위협.
|
||||
- [[Testability]]: 단순한 코드가 가져오는 부가적 이득.
|
||||
---
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-GOV-002
|
||||
category: "10_Wiki/💡 Topics/04_Governance_Reliability"
|
||||
confidence_score: 0.95
|
||||
tags: [governance, dora-metrics, engineering-metrics, performance, devops, cycle-time, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Engineering Metrics (DORA)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터에 기반하여 소프트웨어 인도 성과(Delivery Performance)를 정량화하고, 엘리트 팀의 벤치마크를 통해 개발 프로세스의 병목과 개선 방향을 제시하는 엔지니어링 표준 지표."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
DORA 지표는 데브옵스(DevOps) 연구를 통해 입증된 고성과 팀의 핵심 지표입니다.
|
||||
|
||||
1. **4대 핵심 지표**:
|
||||
* **Deployment Frequency (DF)**: 배포 빈도.
|
||||
* **Lead Time for Changes (MLT)**: 코드 커밋부터 배포까지 걸리는 시간.
|
||||
* **Change Failure Rate (CFR)**: 배포 후 실패율.
|
||||
* **Failed Service Recovery Time (MTTR)**: 장애 발생 시 복구까지 걸리는 시간.
|
||||
2. **엘리트 성과자 (Elite Performers)의 특징**:
|
||||
* **PR 사이즈 제한**: 코드 변경량을 400 LOC 이하로 유지하여 인지 부하를 줄입니다.
|
||||
* **빠른 리뷰 응답**: 첫 리뷰 응답 시간(TTR)을 1시간 이내로, 전체 완료를 6시간 이내로 유지합니다.
|
||||
* **자동화 최적화**: 스타일 및 단순 검증을 자동화하여 인간 리뷰어가 아키텍처와 지식 공유에 집중하게 합니다.
|
||||
3. **성과와 리뷰의 상관관계**:
|
||||
* 효율적인 코드 리뷰 프로세스를 갖춘 팀은 그렇지 않은 팀보다 인도 성과가 50% 이상 높게 나타납니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **속도 vs 안정성**: 지표 개선을 위해 속도에만 집착하면 실패율(CFR)이 올라갈 수 있습니다. 4대 지표는 서로 견제하며 균형을 이루어야 진정한 성과 개선으로 이어집니다.
|
||||
- **데이터의 맥락**: 단순 수치만으로 팀을 평가하기보다, 지표의 변화 추이를 통해 팀의 프로세스 건전성을 진단하고 병목을 해결하는 도구로 활용해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Review Performance & Flow]]: DORA 지표를 달성하기 위한 구체적 운영 전략.
|
||||
- [[Small Pull Requests (작은 PR)]]: Lead Time을 단축하는 가장 강력한 수단.
|
||||
- [[Automated Quality & Review]]: 인간의 시간을 절약하여 성과를 극대화하는 기반.
|
||||
- [[CI-CD Pipeline]]: 지표 수집과 자동화가 이루어지는 인프라.
|
||||
- [[DORA Metrics]]: 원본 개념 정의.
|
||||
---
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-COMM-002
|
||||
category: "10_Wiki/💡 Topics/04_Governance_Reliability"
|
||||
confidence_score: 0.95
|
||||
tags: [management, review-performance, cycle-time, context-switching, asynchronous-review, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Review Performance & Flow]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "팀 전체의 배포 속도(Velocity)와 개별 엔지니어의 몰입(Flow) 사이의 균형을 최적화하여, 기술적 병목을 제거하고 작업의 연속성을 보장하는 운영 전략."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
리뷰 성능 관리는 배포 성과와 개발자 만족도를 결정짓는 핵심 운영 지표입니다.
|
||||
|
||||
1. **리뷰 소요 시간 (Cycle Time)**:
|
||||
* **Time-to-First-Review (TTR)**: 엘리트 팀은 1시간 이내, 일반적인 경우 24시간 이내 응답을 지향합니다.
|
||||
* **Time-to-Merge**: PR 오픈부터 최종 병합까지의 시간을 단축하여 코드 노후화(Stale)와 작업 차단을 방지합니다.
|
||||
2. **인지적 부하 및 세션 관리**:
|
||||
* **200~400 LOC**: 한 번의 리뷰 세션(60~90분)에서 가장 효율적으로 결함을 발견할 수 있는 코드 크기입니다.
|
||||
* **컨텍스트 스위칭 방지**: 실시간 알림에 즉각 반응하기보다, 자연스러운 업무 중단점(Break point)에 리뷰를 모아서 처리(Batching)하여 개인의 몰입도를 보호합니다.
|
||||
3. **[[Asynchronous Code Review]]**:
|
||||
* 문서화와 비동기 피드백을 통해 시간대(Time zone)가 다른 팀원들과도 효율적으로 협업하며, 각자의 일정에 맞춰 고품질의 검토를 수행합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **속도 vs 깊이**: 빠른 완료에만 집착하면 'LGTM'만 남발하는 무의미한 리뷰가 될 위험이 있습니다. 품질 기준(Code Health)을 타협하지 않는 범위 내에서의 속도 향상 정책이 필요합니다.
|
||||
- **SLA의 유연성**: 모든 작업에 동일한 잣대를 대기보다, 긴급 핫픽스와 일반 기능 배포의 리뷰 우선순위와 SLA를 차등화하여 운영 효율성을 높여야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Small Pull Requests (작은 PR)]]: 리뷰 속도를 높이는 가장 근본적인 해결책.
|
||||
- [[Context Switching (컨텍스트 스위칭)]]: 리뷰 활동이 개인 생산성에 미치는 비용.
|
||||
- [[Time-to-Merge (Cycle Time)]]: 배포 성과를 측정하는 상위 지표.
|
||||
- [[Automated Code Analysis]]: 인간의 리뷰 시간을 아껴주는 자동화 엔진.
|
||||
- [[DORA Metrics]]: 엘리트 팀의 성과 기준.
|
||||
---
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-DEV-008
|
||||
category: "10_Wiki/💡 Topics/Development"
|
||||
confidence_score: 0.95
|
||||
tags: [development, testing-strategy, testability, tdd, automated-testing, quality-assurance, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Testing Strategy]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드의 의도를 명세화(Documentation)하고, 변경에 대한 즉각적인 회귀(Regression) 방지망을 구축하여 지속적인 배포와 리팩토링을 가능하게 하는 품질의 초석."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
테스트 전략은 단순한 버그 탐지를 넘어 설계의 무결성과 개발 속도를 보장하는 핵심 활동입니다.
|
||||
|
||||
1. **테스트 가능성 (Testability)**:
|
||||
* **설계적 접근**: 코드가 쉽게 테스트될 수 있도록 의존성을 주입(DI)받고, 인터페이스를 통해 외부 모듈을 격리(Mocking)합니다. 정적 메서드나 싱글톤의 남용은 테스트 가능성을 저해합니다.
|
||||
* **결정론적 테스트**: 테스트는 환경이나 실행 순서에 영향을 받지 않고 항상 동일한 결과를 내야 합니다.
|
||||
2. **[[Test-Driven Development (TDD)]]**:
|
||||
* 실패하는 테스트를 먼저 작성(Red) -> 기능을 구현(Green) -> 코드를 개선(Refactor)하는 사이클을 통해 테스트가 코드의 설계를 주도하게 만듭니다.
|
||||
3. **리뷰 단계에서의 테스트**:
|
||||
* **테스트 코드 우선 리뷰**: 테스트를 먼저 읽으면 해당 기능의 유즈케이스와 의도를 더 명확히 파악할 수 있습니다.
|
||||
* **병합 차단 원칙**: 새로운 기능이나 버그 수정은 반드시 관련 테스트를 포함해야 하며, 테스트 부재는 머지를 차단하는 중대한 사유입니다.
|
||||
4. **엣지 케이스 및 실패 경로**:
|
||||
* 정상 동작뿐만 아니라 Null 입력, 빈 배열, 유효하지 않은 데이터 타입 등 다양한 실패 시나리오를 포괄적으로 검증합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **커버리지의 함정**: 100% 테스트 커버리지라는 수치에 매몰되면 의미 없는 테스트 작성에 시간을 낭비하게 됩니다. 수치보다 '중요한 비즈니스 로직이 충분히 보호되고 있는가'라는 질적 지표가 우선되어야 합니다.
|
||||
- **유지보수 비용**: 테스트 코드 역시 관리 대상인 부채입니다. 과도하게 복잡한 테스트 로직이나 불필요한 구현 세부 사항에 결합된 테스트는 리팩토링을 방해할 수 있으므로, 테스트 자체의 품질과 단순성도 유지해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Automated Quality & Review]]: 테스트가 자동으로 실행되는 환경.
|
||||
- [[Dependency Injection (DI)]]: 테스트 가능성을 높이는 핵심 기술.
|
||||
- [[CI-CD Pipeline]]: 테스트 결과에 따라 병합 여부를 결정하는 시스템.
|
||||
- [[Refactoring]]: 테스트라는 안전망이 있을 때 비로소 가능해지는 활동.
|
||||
- [[Mocking and Test Doubles]]: 외부 의존성 격리 기법.
|
||||
---
|
||||
Reference in New Issue
Block a user