Code Reviewer
보안 이슈, 품질 지표, 성능 문제 및 모범 사례 준수 여부를 체계적으로 분석하는 포괄적인 자동화 코드 리뷰 SKILL입니다.
Purpose
이 SKILL은 자동화된 분석 도구와 전문가 가이드를 결합하여 보안, 품질, 성능 및 유지보수성 측면에서 이슈를 식별하는 구조화된 코드 리뷰 워크플로우를 제공합니다.
When to Use This Skill
이 SKILL은 다음과 같은 경우에 사용하세요:
- Pull request 또는 코드 제출을 리뷰할 때
- 기존 코드베이스에 대한 보안 감사를 수행할 때
- 배포 전 코드 품질을 평가할 때
- 기술 부채 및 리팩토링 기회를 식별할 때
- 팀을 위한 코드 리뷰 표준을 수립할 때
- 코드 리뷰에서 무엇을 살펴봐야 하는지 학습할 때
Core Review Workflow
Phase 1: Initial Analysis
1.1 Context 이해하기
- PR 설명 또는 변경 요약을 읽습니다.
- 변경 유형(기능, 버그 수정, 리팩토링, 보안 패치)을 식별합니다.
- 범위와 영향을 받는 컴포넌트를 결정합니다.
- 관련된 이슈나 티켓이 있는지 확인합니다.
1.2 코드 개요 파악
- 파일 변경 사항과 추가/삭제된 내용을 검토합니다.
- 변경된 모듈과 그 관계를 식별합니다.
- 예상치 못한 변경이나 범위 확장(Scope creep)을 찾습니다.
- Breaking change가 있는지 확인합니다.
Phase 2: Security Review
2.1 일반적인 취약점 패턴
다음과 같은 중요한 보안 이슈를 확인합니다:
Input Validation
- 검증되지 않은 사용자 입력이 민감한 작업에 도달하는지 확인
- SQL injection 취약점
- Command injection 가능성
- Path traversal 공격
- XML/XXE injection 포인트
Authentication & Authorization
- 인증 체크 누락
- Broken access control
- 안전하지 않은 비밀번호 저장
- 취약한 세션 관리
- CSRF 보호 누락
Data Exposure
- 하드코딩된 자격 증명(Credential) 또는 API key
- 로그 내 민감한 데이터 포함 여부
- 부적절한 암호화
- 에러 메시지를 통한 정보 노출
- 노출된 설정 파일
Code Injection
- 안전하지 않은 Deserialization
- Template injection
- 사용자 입력에 의한 코드 실행(Code evaluation)
- 안전하지 않은 Reflection 사용
2.2 자동화 보안 스캔
보안 분석 도구를 사용합니다:
Python:
# 보안 이슈를 위해 bandit 실행
python scripts/review_helper.py --security-scan path/to/code
# 알려진 취약점에 대해 종속성 체크
safety check
pip-audit
JavaScript/Node.js:
# 취약점 체크
npm audit
yarn audit
# ESLint 보안 플러그인 사용
eslint --plugin security path/to/code
Go:
# 보안 스캐닝
gosec ./...
상세한 취약점 패턴은 references/security_patterns.md를 참조하세요.
Phase 3: Code Quality Analysis
3.1 코드 구조
Modularity & Organization
- Single Responsibility Principle 준수 여부
- 적절한 Separation of concerns
- 적절한 추상화 수준
- 명확한 모듈 경계
- 논리적인 파일 구성
Complexity Metrics
- Cyclomatic complexity (목표: 함수당 < 10)
- 함수 길이 (목표: < 50 라인)
- 클래스 크기 (목표: < 300 라인)
- Nesting depth (목표: < 4 단계)
- 파라미터 개수 (목표: < 5개)
Code Smells
- 중복 코드
- 너무 긴 메서드 또는 God class
- Feature envy (메서드가 다른 클래스를 더 많이 사용함)
- Data clumps (반복되는 파라미터 그룹)
- Primitive obsession
- 클래스 간의 부적절한 관계(Inappropriate intimacy)
3.2 명명(Naming) 및 가독성
Naming Conventions
- 의도를 드러내는 서술적인 이름
- 일관된 명명 패턴
- 적절한 길이 (너무 짧거나 길지 않게)
- 표준이 아닌 경우 약어 사용 지양
- Boolean 이름은 is/has/should/can으로 시작
Code Clarity
- 명확한 Control flow
- 인지 부하 최소화
- Self-documenting code
- 적절한 주석 (What이 아닌 Why에 집중)
- 일관된 포맷팅
3.3 Error Handling
Robustness
- 적절한 Exception handling
- 빈 except/catch 블록 지양
- 적절한 에러 메시지
- 리소스 정리 (File handles, connections)
- Graceful degradation
Edge Cases
- Null/None 체크
- 빈 컬렉션 처리
- Boundary conditions
- 동시 액세스 이슈
- Race condition 방지
Phase 4: Performance Review
4.1 일반적인 성능 이슈
Algorithm Efficiency
- 더 나은 대안이 있음에도 O(n²) 이상의 알고리즘 사용
- 불필요한 루프 또는 반복
- 비효율적인 데이터 구조 사용
- Memoization/caching 기회 누락
Resource Management
- Memory leaks
- 닫히지 않은 File handles 또는 connections
- 과도한 메모리 할당
- Thread/process pool 고갈
Database Operations
- N+1 query 문제
- 인덱스 누락
- SELECT * 사용
- 비효율적인 JOIN 작업
- 쿼리 최적화 누락
Network Calls
- 동기적 Blocking calls
- Timeout 설정 누락
- 재시도(Retry) 로직 부재
- 과도한 API 호출
- Connection pooling 누락
최적화 전략은 references/performance_guide.md를 참조하세요.
Phase 5: Testing Assessment
5.1 Test Coverage
Coverage Metrics
- Line coverage (목표: > 80%)
- Branch coverage (목표: > 75%)
- Function coverage (목표: > 90%)
- Critical path coverage (목표: 100%)
Test Quality
- 테스트가 실제로 의미 있는 동작을 검증(Assert)하는지 확인
- 테스트가 독립적이고 격리되어 있는지 확인
- 테스트 이름이 테스트 대상을 명확히 설명하는지 확인
- Mock 및 Stub의 적절한 사용
- 테스트 간 상호 의존성 부재
5.2 Test Completeness
필수 테스트 유형
- 비즈니스 로직을 위한 Unit tests
- 컴포넌트 상호작용을 위한 Integration tests
- Edge case 및 boundary 테스트
- 에러 조건 테스트
- 보안 관련 테스트
누락된 테스트
- 테스트되지 않은 에러 경로
- 부정적(Negative) 테스트 케이스 누락
- 커버되지 않은 edge condition
- 버그 수정을 위한 Regression tests 부재
Phase 6: Documentation Review
6.1 코드 문서화
함수/메서드 문서화
- 목적 및 동작 설명
- 타입을 포함한 파라미터 설명
- 리턴값 문서화
- Exception 문서화
- 복잡한 API를 위한 사용 예시
모듈/클래스 문서화
- 상위 수준의 목적
- 아키텍처 개요
- 설계 결정 사항
- 종속성(Dependencies)
- Public API contracts
6.2 외부 문서화
README 업데이트
- 설치 방법
- 설정 변경 사항
- 새로운 기능 문서화
- Breaking change 공지
- Migration 가이드
API Documentation
- 엔드포인트 설명
- Request/response 형식
- 인증 요구 사항
- 에러 응답
- Rate limiting
Review Checklist
포괄적인 리뷰를 위해 이 체크리스트를 사용하세요:
Security
Code Quality
Performance
Testing
Documentation
Using the Review Helper Script
scripts/review_helper.py는 자동화된 분석을 제공합니다:
# 전체 코드 리뷰 분석
python scripts/review_helper.py --file path/to/file.py --report full
# 보안 중심 스캔
python scripts/review_helper.py --security-scan path/to/directory
# 복잡도 분석
python scripts/review_helper.py --complexity path/to/file.py
# 리뷰 보고서 생성
python scripts/review_helper.py --file path/to/file.py --output report.md
Best Practices
리뷰어를 위한 조언 (For Reviewers)
건설적인 태도 (Be Constructive)
- 비판이 아닌 개선에 집중하세요.
- 제안 뒤에 숨겨진 "Why"를 설명하세요.
- 대안이나 해결책을 제시하세요.
- 좋은 코드와 패턴은 칭찬하세요.
철저하지만 효율적인 리뷰 (Be Thorough but Efficient)
- 반복적인 체크에는 자동화 도구를 사용하세요.
- 사람의 리뷰는 로직과 설계에 집중하세요.
- 스타일에 너무 집착하지 마세요 (Linter 사용).
- 스타일보다 보안과 정확성을 우선시하세요.
일관성 유지 (Be Consistent)
- 모든 코드에 동일한 표준을 적용하세요.
- 팀 코딩 표준을 참조하세요.
- 재사용 가능한 리뷰 템플릿을 만드세요.
- 공통된 피드백 패턴을 문서화하세요.
코드 작성자를 위한 조언 (For Code Authors)
리뷰 준비
- 리뷰를 요청하기 전에 스스로 리뷰(Self-review)하세요.
- Linter와 포맷터를 실행하세요.
- 테스트 슈트를 실행하세요.
- PR 설명에 컨텍스트를 추가하세요.
- 변경 사항을 작고 집중된 단위로 유지하세요.
피드백 대응
- 모든 코멘트에 대응하세요.
- 불명확한 경우 질문하세요.
- 피드백을 개인적으로 받아들이지 마세요.
- 완료된 대화는 해결됨(Resolved)으로 표시하세요.
Common Review Feedback Patterns
보안 이슈
❌ Security: 하드코딩된 API key 발견
→ 환경 변수 또는 secret management로 이동하세요.
→ 참고: references/security_patterns.md#secrets-management
❌ Security: SQL injection 취약점
→ 문자열 연결 대신 파라미터화된 쿼리를 사용하세요.
→ 예시: cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
품질 이슈
❌ Quality: 함수의 복잡도가 너무 높음 (complexity: 15)
→ 더 작고 집중된 기능의 함수들로 나누세요.
→ 목표: < 10 cyclomatic complexity
❌ Quality: 3개 위치에서 중복 코드 발견
→ 공통 로직을 공유 함수로 추출하세요.
→ DRY 원칙 위반
성능 이슈
❌ Performance: N+1 query 문제 탐지됨
→ JOIN 또는 eager loading을 사용하세요.
→ 참고: references/performance_guide.md#database-optimization
❌ Performance: 비효율적인 O(n²) 알고리즘
→ O(1) 조회를 위해 set/hash 사용을 고려하세요.
→ 현재: 중첩 루프, 권장: set intersection
Additional Resources
- Security Patterns:
references/security_patterns.md - 일반적인 취약점 및 해결 방법
- Performance Guide:
references/performance_guide.md - 최적화 전략
- Review Checklist:
examples/review_checklist.md - 포괄적인 리뷰 템플릿
- Helper Scripts:
scripts/review_helper.py - 자동화된 분석 도구
Language-Specific Considerations
Python
- Context managers(with 문)의 적절한 사용 확인
- List comprehension이 과도하게 복잡하지 않은지 확인
- Generator 사용 기회 탐색
- Mutable default arguments 확인
JavaScript/TypeScript
- async/await의 적절한 사용 확인
- Callback hell 확인
- Event listener에서의 메모리 누수 확인
- TypeScript에서의 적절한 Typing 확인
Java
- 적절한 Exception handling 확인
- 리소스 정리 확인 (try-with-resources)
- Immutability의 적절한 사용 확인
- Thread safety 이슈 확인
Go
- 적절한 Error handling 확인 (에러 무시 금지)
- Goroutine leak 방지 여부 확인
- Race conditions 확인
- 적절한 Context 사용 확인
Conclusion
효과적인 코드 리뷰는 자동화된 툴과 사람의 전문성을 결합할 때 이루어집니다. 기계적인 체크(보안, 스타일, 복잡도)에는 자동화 도구를 사용하고, 사람의 리뷰는 로직, 설계 및 유지보수성에 집중하세요. 항상 건설적이고 철저하며 일관성 있는 리뷰를 지향하십시오.