60 lines
3.3 KiB
Markdown
60 lines
3.3 KiB
Markdown
---
|
|
title: "적대적 리뷰"
|
|
description: “괜찮아 보이네”라는 식의 대충 넘어가는 검토를 방지하는 논리적 추론 기법
|
|
sidebar:
|
|
order: 5
|
|
---
|
|
|
|
문제를 반드시 찾게 만들어 더 깊은 분석을 강제합니다.
|
|
|
|
## 적대적 리뷰란?
|
|
|
|
리뷰어가 *반드시* 이슈를 찾아야 하는 리뷰 기법입니다. "좋아 보입니다"는 허용되지 않습니다. 리뷰어는 문제가 존재한다고 가정하고, 냉정한 태도로 그것을 찾아냅니다.
|
|
|
|
부정적이 되자는 뜻이 아닙니다. 제출물을 도장 찍듯 승인하는 대충 훑기가 아니라 실제 분석을 강제하기 위한 것입니다.
|
|
|
|
**핵심 규칙:** 이슈를 찾아야 합니다. 발견 항목이 0개면 중단하고 다시 분석하거나 이유를 설명합니다.
|
|
|
|
## 왜 효과적인가
|
|
|
|
일반 리뷰는 확증 편향에 취약합니다. 작업을 훑고, 눈에 띄는 것이 없으면 승인합니다. "문제를 찾아라"라는 요구는 이 패턴을 끊습니다.
|
|
|
|
- **철저함을 강제** - 충분히 열심히 살펴 이슈를 찾기 전까지 승인할 수 없습니다
|
|
- **빠진 것을 잡아냄** - "여기에 없는 것은 무엇인가?"가 자연스러운 질문이 됩니다
|
|
- **신호 품질 향상** - 발견 사항이 막연한 우려가 아니라 구체적이고 실행 가능해집니다
|
|
- **정보 비대칭** - 원래 의사결정 과정을 보지 않은 새 컨텍스트에서 검토해 의도가 아니라 산출물을 평가합니다
|
|
|
|
## 사용 위치
|
|
|
|
적대적 리뷰는 코드 리뷰, 구현 준비 상태 점검, 사양 검증 등 BMad 워크플로 전반에 나타납니다. 어떤 때는 필수 단계이고, 어떤 때는 고급 도출이나 파티 모드처럼 선택 사항입니다. 검토가 필요한 산출물에 맞춰 패턴이 적응합니다.
|
|
|
|
## 사람의 필터링 필요
|
|
|
|
AI는 문제를 찾도록 *지시*받았으므로 문제를 찾습니다. 실제로는 존재하지 않을 때도 그렇습니다. 사소한 지적을 이슈처럼 포장하거나, 의도를 오해하거나, 아예 환각성 발견 사항을 낼 수 있습니다.
|
|
|
|
**무엇이 실제인지 사용자가 결정합니다.** 각 발견 사항을 검토하고 노이즈를 버리고 중요한 것을 고치세요.
|
|
|
|
## 예시
|
|
|
|
다음 대신:
|
|
|
|
> "인증 구현은 괜찮아 보입니다. 승인합니다."
|
|
|
|
적대적 리뷰는 다음처럼 나옵니다.
|
|
|
|
> 1. **HIGH** - `login.ts:47` - 실패한 로그인 시도에 속도 제한 없음
|
|
> 2. **HIGH** - 세션 토큰이 localStorage에 저장됨(XSS 취약)
|
|
> 3. **MEDIUM** - 비밀번호 검증이 클라이언트 측에서만 수행됨
|
|
> 4. **MEDIUM** - 실패한 로그인 시도에 대한 감사 로깅 없음
|
|
> 5. **LOW** - 매직 넘버 `3600`은 `SESSION_TIMEOUT_SECONDS`가 되어야 함
|
|
|
|
첫 번째 리뷰는 보안 취약점을 놓칠 수 있습니다. 두 번째는 네 가지를 잡았습니다.
|
|
|
|
## 반복과 수확 체감
|
|
|
|
발견 사항을 처리한 뒤 다시 실행하는 것도 고려하세요. 두 번째 실행은 대개 더 많은 것을 잡아냅니다. 세 번째도 항상 쓸모없지는 않습니다. 하지만 각 실행에는 시간이 들고, 언젠가는 사소한 지적과 거짓 발견 사항만 남는 수확 체감 구간에 들어갑니다.
|
|
|
|
:::tip[더 나은 리뷰]
|
|
문제가 존재한다고 가정하세요. 잘못된 것뿐 아니라 빠진 것을 찾으세요.
|
|
:::
|