39 lines
2.6 KiB
Markdown
39 lines
2.6 KiB
Markdown
---
|
|
id: P-REINFORCE-AUTO-WIKI-DEV-001
|
|
category: Unified
|
|
confidence_score: 0.95
|
|
tags: [development, code-review, checklist, quality-assurance, best-practices, p-reinforce]
|
|
last_reinforced: 2026-05-01
|
|
---
|
|
|
|
# [[Code Review Checklist|Code Review Checklist]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> "주관적인 코드 검토를 객관적이고 반복 가능한 품질 보증 프로세스로 전환하여, 인간의 실수를 방지하고 팀의 기술적 부채를 조기에 차단하는 체계적인 가이드라인."
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
코드 리뷰 체크리스트는 일관된 품질을 유지하기 위한 팀의 합의된 기준입니다.
|
|
|
|
1. **핵심 점검 영역**:
|
|
* **기능 및 논리**: 요구사항 충족 여부 및 엣지 케이스 처리 확인.
|
|
* **아키텍처**: [[SOLID Principles|SOLID Principles]] 준수 및 과도한 엔지니어링 방지.
|
|
* **보안**: [[OWASP Top 10|OWASP Top 10]] 기준 위반 및 민감 데이터 노출 여부 점검.
|
|
* **가독성**: 네이밍 컨벤션, 중복 코드 제거, 유지보수 용이성 확보.
|
|
* **테스트 및 문서화**: 유의미한 테스트 코드 포함 및 '왜'에 대한 주석/문서 업데이트.
|
|
2. **자동화와의 분업**:
|
|
* 스타일, 포맷팅, 단순 보안 패턴은 린터(Linter)와 SAST에 맡기고, 인간은 비즈니스 로직과 구조적 무결성에 집중합니다.
|
|
3. **현대적 확장 (AI 생성 코드)**:
|
|
* AI가 제안한 존재하지 않는 API(Hallucination)나 보안 권한 누락 등을 별도로 검증해야 합니다.
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **고무 도장(Rubber-stamping)의 위험**: 체크리스트가 너무 길어지면 기계적으로 체크만 하고 넘어가는 현상이 발생합니다. 필수 점검 항목을 정예화하고 운영 효율성을 고려한 유연한 적용 정책이 필요합니다.
|
|
- **살아있는 문서화**: 기술 스택과 팀의 성숙도에 따라 체크리스트는 주기적으로 업데이트되어야 하며, 불필요해진 항목은 과감히 자동화 로직으로 이관해야 합니다.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- [[SOLID Principles|SOLID Principles]]: 아키텍처 점검의 근간.
|
|
- [[OWASP Top 10|OWASP Top 10]]: 보안 점검의 표준.
|
|
- Pull Request Templates: 체크리스트를 워크플로우에 내장하는 도구.
|
|
- [[Automated Code Analysis (자동화된 코드 분석)|Automated Code Analysis]]: 수동 체크리스트의 부담을 줄이는 자동화 기법.
|
|
- [[Technical-Debt|Technical Debt]]: 체크리스트 부실 시 발생하는 비용.
|
|
---
|