| name | aidlc-receiving-code-review |
| description | 코드 리뷰 피드백, PR 코멘트, 인라인 제안, 또는 작성한 코드에 대한 비평을 받아 응답이나 조치가 필요할 때 사용.
Use when receiving code review feedback, PR comments, inline suggestions, or any critique of written code that requires a response or action.
|
| metadata | {"version":"0.1.0","author":"Jay","category":"ai-dlc-workflow","invoke_mode":"user-invocable","return_behavior":"stop-no-gate","skill_nature":"hybrid","lifecycle":"active","model_dependency":"모델이 피드백에 sycophancy로 맹목적 동의함","amplification_notes":"Accept/Rebut 프로토콜 + 금지 응답 목록"} |
aidlc-receiving-code-review
Trigger
다음 상황에서 이 스킬을 실행한다:
- PR에 리뷰 코멘트가 달렸을 때
- 코드 인라인 제안을 받았을 때
- "이 코드 어떻게 생각하냐"는 피드백 요청을 받았을 때
- 페어 프로그래밍 중 파트너가 코드를 지적할 때
- AI가 작성한 코드에 대한 사람 리뷰어의 피드백을 처리할 때
Purpose
리뷰 피드백을 감정 없이 기술적으로 평가하고, 수락할 것은 수락하고, 반박할 것은 근거로 반박한다.
맹목적 동의와 방어적 거부 둘 다 피한다.
금지 응답 목록
다음 표현은 절대 사용하지 않는다. 아첨성 응답은 실제 기술 판단을 흐린다:
| 금지 표현 | 이유 |
|---|
| "You're absolutely right!" | 기술적 검토 없는 즉각 동의 |
| "Great point!" | 피드백의 유효성을 미리 확정 |
| "Thanks for catching that!" | 실제로 버그인지 확인 전 인정 |
| "I should have thought of that!" | 자기 비하 — 판단을 흐림 |
| "That's a much better approach!" | 실제로 더 나은지 검증 없이 동의 |
| "Of course, my mistake!" | 본인 코드가 틀렸다고 검증 전에 인정 |
올바른 응답 형식:
- "이 피드백을 검토했습니다. [기술적 분석] 이유로 [수락/거부/토론]합니다."
- "코드를 확인한 결과 [구체적 관찰 내용]입니다."
처리 프로세스
1단계: READ — 전체 피드백 읽기
DO NOT proceed to 2단계 until all feedback is read and listed. 부분만 읽고 반응하지 않는다.
모든 피드백을 한 번에 읽는다. 아직 동의하거나 반박하지 않는다.
- PR의 모든 코멘트를 목록화한다
- 각 이슈의 위치(파일, 줄)를 기록한다
- 반응하기 전에 전체 컨텍스트를 파악한다
2단계: UNDERSTAND — 실제 우려사항 파악
각 이슈에 대해 다음을 파악한다:
- 리뷰어가 실제로 걱정하는 것은 무엇인가?
- 표면적 제안 뒤에 숨은 근본 우려는 무엇인가?
- 예시: "변수명을 바꾸라"는 표면 제안 → 실제 우려는 가독성
이슈 목록 작성:
| # | 이슈 위치 | 표면 제안 | 실제 우려 |
|---|---------|---------|---------|
| 1 | api.py:42 | ... | ... |
| 2 | models.py:15 | ... | ... |
3단계: VERIFY — 코드에서 직접 확인
DO NOT proceed to 4단계 until each claim is verified against actual code. 확인 없이 동의/거부하지 않는다.
리뷰어의 주장을 코드에서 직접 확인한다:
확인 없이 "맞아요" 또는 "틀려요"를 말하지 않는다.
4단계: EVALUATE — 기술적 타당성 평가
각 이슈를 다음 기준으로 평가한다:
YAGNI (You Aren't Gonna Need It) 검증:
- 이 변경이 현재 요구사항에 실제로 필요한가?
- 미래 확장성을 위한 추가라면 해당 미래가 실제로 올 가능성이 높은가?
현재 코드베이스 맥락 검증:
- 이 패턴이 프로젝트의 다른 곳에서도 쓰이는가?
- 기존 컨벤션과 충돌하지 않는가?
- 이 변경이 의존성 있는 다른 코드를 깨뜨리지 않는가?
외부 리뷰어 피드백 처리 (코드베이스를 잘 모르는 리뷰어):
- 의심적 접근: 제안이 이 코드베이스 맥락에서 맞는지 검증한다
- 범용 조언이 이 프로젝트에 맞지 않을 수 있다
- 예시: "항상 인터페이스를 써라" → 이 프로젝트가 Go인지, 소규모인지 확인
5단계: RESPOND — 근거 있는 응답
DO NOT respond until 4단계 evaluation is complete for all issues. 평가 없는 응답은 아첨이거나 방어적 거부다.
각 이슈에 대해 세 가지 중 하나로 응답한다:
수락 (Accept):
[이슈 #1] 수락
확인 결과: [구체적 관찰 내용]
이유: [왜 이 변경이 개선인가]
거부 (Reject):
[이슈 #2] 거부
현재 코드 동작: [실제 코드 동작 설명]
거부 이유: [YAGNI / 기존 컨벤션 / 불필요한 복잡성]
대안 (필요시): [대안 제안]
토론 필요 (Discuss):
[이슈 #3] 토론 필요
이해한 우려: [리뷰어의 실제 우려]
내 관점: [내 기술적 판단]
추가 확인 필요: [어떤 정보가 더 필요한가]
6단계: IMPLEMENT — 수락된 항목 구현
수락된 항목만 구현한다. 하나씩 처리한다:
- 항목 하나 구현
- 테스트 실행하여 회귀 없음 확인 (
aidlc-verification-before-completion 적용)
- 다음 항목으로 이동
여러 항목을 한꺼번에 수정하지 않는다 — 무엇이 무엇을 깨뜨렸는지 알 수 없게 된다.
이슈 분류표
| 분류 | 정의 | 처리 방법 |
|---|
| Critical | 보안 취약점, 데이터 손실 위험, 명백한 버그 | 즉시 수정 — 다음 단계 진행 전에 처리 |
| Important | 성능 문제, 설계 결함, 테스트 부족 | 진행 전 수정 — 이번 PR에서 처리 |
| Minor | 스타일, 변수명, 주석 | 나중에 처리 가능 — 별도 이슈 생성 |
분류 기준:
- Critical: 프로덕션에서 지금 당장 문제를 일으킬 수 있는가?
- Important: 이 PR이 머지된 후 다음 PR에서 문제가 될 수 있는가?
- Minor: 기능에는 영향 없고 품질만의 문제인가?
Examples
Example 1: 정당한 피드백 수락
리뷰 코멘트:
api.py:67: 이 함수는 예외를 잡지만 로깅을 안 하네요.
프로덕션에서 오류를 추적하기 어려울 것 같아요.
처리:
1단계-3단계: api.py:67 확인
try:
result = process_payment(data)
except PaymentError:
return {"error": "Payment failed"}
4단계 평가: Critical에 해당 — 프로덕션 디버깅 불가
5단계 응답:
[이슈 #1] 수락
확인 결과: api.py:67에서 예외를 catch하지만 logger.error() 호출이 없습니다
이유: 프로덕션 장애 추적을 위해 로깅이 필요합니다
분류: Critical — 즉시 수정
6단계 구현:
except PaymentError as e:
logger.error("결제 처리 실패: %s", str(e), exc_info=True)
return {"error": "Payment failed"}
Example 2: 부당한 피드백 거부
리뷰 코멘트:
UserRepository 클래스는 인터페이스로 분리해야 합니다.
IUserRepository와 UserRepositoryImpl로 나누세요.
처리:
1단계-3단계: 프로젝트 확인
- 이 프로젝트는 소규모 FastAPI 앱
- 현재 구현체가 1개, 테스트용 Mock도 pytest fixtures로 처리 중
- 인터페이스 분리 시 파일 2배 증가, Mock 작성 복잡화
4단계 평가: YAGNI — 현재 구현체가 1개뿐이고 추가 구현체 계획 없음
5단계 응답:
[이슈 #1] 거부
현재 코드 동작: UserRepository 구현체가 1개이며, 테스트는 pytest fixtures로 처리합니다
거부 이유: YAGNI — 현재 요구사항에서 다형성이 필요 없습니다.
인터페이스 분리는 구현체가 2개 이상 필요할 때 도입할 예정입니다.
기존 컨벤션: 프로젝트의 다른 Repository 클래스들도 동일 패턴을 사용합니다
Troubleshooting
리뷰어와 기술적 의견이 계속 충돌할 때
증상: 거부 응답을 했는데 리뷰어가 다시 같은 이슈를 제기함
처리 방법:
- 리뷰어의 우려를 다시 한 번 더 깊게 파악한다 — 내가 놓친 부분이 있을 수 있다
- 구체적인 코드 예시를 들어 내 관점을 설명한다
- "이런 경우에는 동의하지만, 이 케이스에서는 [이유] 때문에 다릅니다"로 범위를 좁힌다
- 합의가 안 되면 제3자(시니어 개발자, 다른 리뷰어)의 의견을 구한다
- 여전히 합의 불가라면 팀 기술 결정 프로세스를 따른다 (ADR 등)
리뷰어가 코드베이스를 잘 모르는 외부인일 때
증상: 피드백이 일반적으로는 맞지만 이 프로젝트에 맞지 않는 경우
처리 방법:
- 피드백의 일반적 타당성은 인정한다
- 이 코드베이스의 맥락을 설명한다:
"일반적으로는 좋은 접근이지만, 이 프로젝트에서는 [맥락] 때문에
[현재 방식]을 사용하고 있습니다. [근거]"
- 코드베이스 제약 (기술 부채, 레거시 호환성, 팀 컨벤션)을 투명하게 공유한다
- 리뷰어의 우려가 타당하다면 별도 이슈로 등록하여 나중에 처리한다
