---
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]]: 엘리트 팀의 성과 기준.
---