---
id: P-REINFORCE-AUTO-WIKI-DEV-007
category: "10_Wiki/💡 Topics/Development"
confidence_score: 0.95
tags: [development, pull-request, review-workflow, pr-size-limits, architecture-review, agile, p-reinforce]
last_reinforced: 2026-05-01
---

# [[Modern Review Workflow|Modern Review Workflow]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> "작고 집중된 변경(Small Batches)을 통해 인지 부하를 줄이고, 사전 설계 검토와 자동화 게이트를 결합하여 개발 속도와 아키텍처 무결성을 동시에 확보하는 협업 프로세스."

## 📖 구조화된 지식 (Synthesized Content)
현대적인 리뷰 워크플로우는 단순히 코드를 검사하는 단계를 넘어 배포의 안전성과 팀의 민첩성을 보장하는 핵심 프로세스입니다.

1.  **풀 리퀘스트 (Pull Request / Merge Request)**:
    *   코드 변경 사항을 메인 브랜치에 병합하기 전, 동료들의 검토와 자동화 테스트를 거치는 공식적인 관문입니다.
    *   **단일 목적 지향**: 하나의 PR은 기능 추가, 버그 수정, 리팩토링 중 단 하나의 명확한 목적만 가져야 합니다.
2.  **PR Size Limits (작은 PR의 원칙)**:
    *   **인지적 한계**: 리뷰어는 200~400 LOC(Lines of Code) 사이에서 가장 높은 결함 발견율을 보입니다. 400줄을 초과하면 집중력이 급격히 저하되어 '고무 도장(Rubber-stamping)' 리뷰가 될 위험이 큽니다.
    *   **분할 전략**: 거대 기능은 **기능 플래그(Feature Flags)**나 **누적 PR(Stacked PRs)**을 활용하여 작은 단위로 나누어 병합합니다.
3.  **[[Architecture Review (아키텍처 및 설계 리뷰)|Architecture Review]] (Shift-Left)**:
    *   코드를 작성하기 전, 설계 문서나 ADR(Architecture Decision Record)을 통해 방향성을 먼저 합의합니다. 이는 대규모 리팩토링 비용을 사전에 차단하는 가장 효율적인 전략입니다.
4.  **애자일 개발과의 조화**:
    *   지속적 통합(CI)과 빈번한 병합을 통해 코드 노후화(Stale)를 방지하고 피드백 루프를 극단적으로 단축합니다.

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **전체 맥락의 상실**: PR을 너무 작게 쪼개면 시스템의 '큰 그림'을 놓칠 수 있습니다. 이를 보완하기 위해 PR 설명에 상위 목표와의 연결성을 명시하거나, 사전 설계 리뷰를 병행해야 합니다.
- **분할 오버헤드**: 작은 PR로 나누는 작업 자체가 개발자에게 추가적인 부담이 될 수 있습니다. 이는 시스템을 느슨하게 결합(Loosely Coupled)된 모듈로 설계하여 자연스럽게 작은 변경이 가능하도록 아키텍처 수준에서 해결해야 합니다.

## 🔗 지식 연결 (Graph)
- [[Effective Code Review Feedback|Effective Code Review Feedback]]: 워크플로우 내에서의 구체적 소통법.
- [[Automated Quality & Review|Automated Quality & Review]]: 인간의 리뷰 전 수행되는 자동화 관문.
- [[Engineering Metrics (DORA)|Engineering Metrics (DORA]]: 워크플로우 효율성을 측정하는 지표.
- [[Feature-Flags|Feature Flags]]: 큰 기능을 안전하게 나누어 배포하는 기술.
- [[Technical-Debt|Technical Debt]]: 비대해진 PR이 유발하는 잠재적 위험.
---