Modern Review Workflow

📌 한 줄 통찰 (The Karpathy Summary)

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

현대적인 리뷰 워크플로우는 단순히 코드를 검사하는 단계를 넘어 배포의 안전성과 팀의 민첩성을 보장하는 핵심 프로세스입니다.

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

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