18강. 협업 준비: 코드 리뷰, 이슈, 커밋 전 점검의 목적

?1. 이번 강의에서 해결할 문제

코드만 전달하면 왜 바꿨는지, 어디를 검토해야 하는지, 무엇을 확인했는지 알기 어렵습니다. 팀 작업 전에 혼자서도 변경 범위와 검증 증거를 설명하는 습관이 필요합니다.

✓2. 학습 목표

✓이번 강의를 마치면

• 이슈와 리뷰 설명에 문제, 범위, 검증을 기록합니다.
• 커밋 전에 diff, 빌드·테스트, 민감 정보와 불필요 파일을 확인합니다.
• 리뷰를 사람 비판이 아닌 코드 위험 확인 과정으로 이해합니다.

◇3. 핵심 개념

이슈는 해결할 문제와 완료 기준을 공유하고, 코드 리뷰는 변경이 요구사항을 충족하면서 새 위험을 만들지 않는지 확인합니다. 좋은 변경 설명은 왜, 무엇을, 어떻게 검증했는가를 짧게 보여 줍니다.

Git 명령 자체와 GitHub Pull Request 절차는 기존 Git · GitHub 기초집에서 자세히 다룹니다. 여기서는 생산성 점검에 연결하는 데 집중합니다.

✎4. 단계별 실습

Markdown · 파일 경로: docs/review-template.md

docs/review-template.md

# 변경 설명

## 문제
- 어떤 사용자 문제를 해결하는가?

## 변경 범위
- 바꾼 파일과 핵심 동작
- 이번 변경에서 다루지 않은 것

## 검증
- [ ] 빌드 또는 실행 성공
- [ ] 자동 테스트 통과
- [ ] 수동 체크리스트 확인
- [ ] 민감 정보 없음
- [ ] 생성물·로그·불필요 파일 없음

## 리뷰가 필요한 부분
- 가장 위험하거나 판단이 필요한 코드

PowerShell · 실행 위치: 프로젝트 루트

git status --short
git diff --check
git diff --stat
npm.cmd run check

예상 결과: 변경 파일과 크기를 확인하고, 공백 오류가 없으면 git diff --check 출력이 비어 있으며, 검사 명령이 성공합니다. 프로젝트에 npm이 없다면 그 프로젝트의 실제 빌드·테스트 명령으로 바꿉니다.

→5. 도구와 설정이 동작하는 이유

status는 추적·미추적 변경을, diff --stat은 변경 범위를, diff --check는 흔한 공백 오류를 보여 줍니다. 여기에 실제 빌드·테스트 증거를 더하면 리뷰어가 추측보다 위험한 부분에 집중할 수 있습니다.

!6. 자주 하는 실수와 해결법

!자주 하는 실수

• 변경 설명에 파일명만 나열: 해결한 문제와 사용자 결과를 먼저 적습니다.
• 테스트했다고만 씀: 실행한 명령과 결과를 구체적으로 기록합니다.
• 리뷰 전에 생성물·로그 포함: 상태를 확인하고 저장소 규칙에 맞게 제외합니다.
• 리뷰 의견을 개인 평가로 해석: 코드의 정확성, 보안, 유지보수 위험에 초점을 맞춥니다.

✎7. 직접 실습

✎직접 실습

현재 변경에 대해 위 템플릿을 채우고 네 명령을 실행하세요. 민감 정보, 빌드·테스트, 불필요 파일, 문서 갱신을 모두 확인한 뒤 스스로 1차 리뷰를 작성합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 변경 설명에서 ‘왜’를 먼저 적으면 리뷰에 어떤 도움이 되나요?
2. git diff --stat과 실제 테스트 결과는 서로 무엇을 보완하나요?
3. 커밋 전에 민감 정보와 생성물을 확인해야 하는 이유는 무엇인가요?

■9. 핵심 요약

■핵심 요약

협업 준비는 문제, 변경 범위, 검증 증거를 다른 사람이 재확인할 수 있게 만드는 일입니다. 커밋 전에 상태, diff, 검사, 민감 정보와 불필요 파일을 점검합니다.